大家好，我来自阿里云的一个产品团队，我叫求至。目前我们这个团队大概有将近40人，今年我们希望能够转变成一个AI Native的团队组织，所以我们做了很多AI的实践。今天我以一个产品经理的视角来看一下，如何借助QoderWork这样的Agent产品，重新定义产品经理的实际工作流。
产品经理AI使用现状：9大应用场景
这张图来自于我们团队三十多个人日常使用AI这些工具，分析总结提炼出来的。我们核心用的两个工具，一个是Qoder，一个是QoderWork。主要覆盖场景：
日常文档和产品方案。包含文档报告调研、生产方案产出、对竞对的调研、行业趋势、日常产品所有相关类的文档、深度分析，还有售前的各种产品方案——比如解决方案、销售数据、招标参数、定价等等。
产出原型。从设计到研发，完全能够由产品经理基于Qoder和QoderWork产出交互稿，最终产出原型，然后跟前端协同开发。目前我们已经实现了2到3天之内产出一个系统化的所有菜单功能页面，半个月发一个版本，一个月发一个大版本，同步产出所有产品功能的Release Note、产品介绍以及用户指南等各种文档。
自动化任务。包括日常定时任务提取、技术方案定时追踪、友商信息推送等等，都会通过自动化和日常任务去协同。
需求和任务的跟踪。将来源于各个渠道的需求，比如客户提的需求，通过QoderWork去做分析总结，自动体验完，自动去实现整个产品流程，然后转给研发。
定时的行业分析和交互PRD。将过程当中协同用到的能力都沉淀成Skills，然后团队内共享、复用，来提升整个产品的AI化程度。
各岗位AI使用成熟度对比
我们团队主要有三个角色：一是产品经理，二是产品文档工程师，三是产品运营。产品经理这个岗位是成熟度最高的，也是我们团队目前使用AI程度最深的一个岗位。
一个完整的产品经理工作流实践
以我的工作视角出发的完整工作流实践。主要有九个阶段。第一点是产品构思，举一个我现实中的例子：今年三月份开始，因为Agent特别火，我们突然发现在某一个垂直领域缺少一个类似的产品。从我们有这个产品想法之后，就开始去用Qoder构建整个产品的后台管理能力。我们大概在一个周末、两天就把这个产品所有的功能原型直接手搓出来了——通过协同AI手搓出来的。
阶段1：产品构思——3天产出可运行原型
产品经理以前那种传统方式，可能自己手搓原型，或者用Axure等各种工具去画图。当需要改一个功能或者改某个下拉框的时候，很多东西都要跟设计师沟通。中间的沟通成本特别高。而且整个迭代中间会有大量的信息损耗。以前要画一个非常复杂的、可能涉及到二十几个界面的功能时，可能要花2到3周，迭代周期非常长。
现在有了Qoder和QoderWork，我们可以直接在IDE里面用自然语言描述需求。它会把整个页面生成出来，你在这个基础上不断调整优化。基本上产出的整个前端代码仓库可以直接在后续的研发阶段复用。
阶段2：设计师介入——UI组件规范化重构
第二部分是和设计师的协同。我们会统一把代码提交到Git上面。设计师和我们PD同样有一个代码分支。设计师会基于QoderWork里面生成的代码进行UI的重构。
主要重构哪些呢？第一，把所有前端组件进行统一。我们这边用的是shadcn/ui组件，设计师会把设计Skills也同步到工程里面。比如对所有系统里面的颜色、间距、字体、圆角各个组件的设计，都会通过一个Skills直接集成在工程里面，然后做一键优化。最终我们会在上面做走查，觉得哪里有问题就直接修改。我不需要线下口述跟设计师沟通，都互相在一个代码分支上协同，实现了快速的产品终稿交互原型交付。
这是我的几个系统的产出截图。你看左侧可能有将近十几到二十个菜单。这里面每个菜单里面的所有功能全都是基于QoderWork直接出来的。包括运维看板、后台管理系统都可以很快产出。像最后这个系统里面可能就五个菜单，我花了一个大半天就直接搓出来了。
阶段3：产品开发前——前端代码质检
第三个阶段是在产品开发前，前端会有一个React Code质检的Skills。通过QoderWork直接写出来的，会做整个工程的前端代码质量检测。最终给我生成一个报告，并且帮我优化整个工程。因为用AI写的很多组件，可维护性都是非常差的。所以需要有一个统一标准，能够检测性能瓶颈。在真正用到生产或做商业化产品交付给客户的时候，会有很多潜在的隐患。所以我们用这个质检Skills去做相应的国际化、性能、组件可维护性的整体分析和质检。这是在真正产品开发前做的工作。
阶段4：PRD生产
第四阶段就是写PRD。我自己也是在QoderWork里面，通过创建技能页面，写了一个PRD Writing的技能。里面包含具体的写作要求——因为每个人对PRD都有不同格式要求，不同行业的产品区分度很大。从我这边来说，因为我们是偏技术平台的产品，所以对章节要求、必备模块、业务流程都有特殊要求。我没有用现成的PRD模板，而是把团队目前写得比较优秀的、或者我之前写过比较详细的PRD扔到QoderWork里面，直接让它分析总结，帮我生成了一个写作PRD的Skills。
用QoderWork生成PRD的心得：一定要给它特定的角色定位，同步要给它足够的知识源清单。包括前面在线网页Demo地址——它会自动调浏览器把所有界面都点一遍。还有前面的背景知识，比如Wiki知识点、冲突解决原则。最终生成一份不需要花太多时间微调的PRD。最终你可以在里面补业务细节，修复逻辑漏洞。通过MCP连接器直接发到内部钉钉文档上，交付给研发。
这是我的Skills的截图。虽然没有展示完整功能，但大家可以自己去尝试写一个。它有一个核心文件SKILL.md，里面包含核心原则、必须包含的模块章节。同时也会有一个reference文件夹，你可以放PRD模板——比如第一章节是什么、第二章是什么、第三章是什么。这样在写PRD时真正事半功倍。
阶段5：前后端协同功能还原
第五阶段是前后端协同，实现整个产品功能的还原。左侧是我们目前采用的研发、设计师、前端、后端共用分支的协同策略。我们会统一在design分支上协作。
最终真正要开发时，可能前端和设计师都会进来微调。真正开发时会让研发基于这个分支切出一个DEV分支，在这个DEV分支上把后端设计的API文档直接灌给它。前端根据API文档和界面，直接就能生成带业务逻辑的产品功能和界面，然后持续更新。如果发布上线，就把研发分支合到master主干分支。这样的方式可以快速帮前端不遗漏产品经理关注的功能点和细节，只需要补充API逻辑就能实现功能的快速上线。
阶段6：市场分析、收入预测与定价策略
第六阶段是用QoderWork做产品领域的竞品市场分析，包括收入预测。前提是要给它足够多的数据，比如类似产品在全国或全球的市场规模是多大，中国市场是多大，去年类似产品的销售数据。给到它后会通过深度分析，最终推测出产品大概的收入预测模型。目前给出的结果非常精准。包括产品的定价模式、折扣分析都可以通过QoderWork来实现。
阶段7：产品文档体系产出
第七部分就是产品经理要写各种文档：用户指南、开发指南、技术白皮书、Release Note、API文档、产品简介，很多很多。我们目前也是基于QoderWork的Skills，能批量把这些文档生产出来。比如用户指南里面每一个功能，从新建、删除到列表，包括详情页，它都可以一步步去访问、截图，然后帮你写出这个功能。最终你可能只需要让研发和PD一起评审一下文档就可以直接发布上线对客了。
阶段8：招标参数编写与解决方案PPT生产
第八个阶段是产品的售前招标环节的生产。比如我们新产品所有的技术招标参数都来自功能清单，让它基于前面生成的功能清单，一键能生成技术招标参数。同时包括写PPT功能，很多解决方案都是基于QoderWork里面幻灯片功能（目前是Beta版本）写出来的。当然今天我这个演讲PPT也是通过QoderWork写出来的，但有几页是单独微调过的。
你可以通过销售数据的上升或下降，来潜在分析一些问题，包括资源评估。这里的点比较多。比如左上角第一张图是各种文档，每一个文档里面可能都是十几万字，基本全都是用QoderWork去写出来的。包括商品定价分析、右侧的招标参数，以及我写的产品新功能介绍PPT，都是真实的——利用QoderWork现有的能力产出来的。
阶段9：客户需求分析与跟进
第九阶段是客户需求分析。我们的产品客户特别多，每次收到上百条需求，光靠人肉处理非常慢。所以我们一般用QoderWork处理客户的原始需求。有些前线或SA提出来的需求写得非常笼统，通过QoderWork去分析的话，它会把需求所考虑到的点详细分析出来，实现批量总结，产出真正的需求清单，并提交拆解任务。最终实现对客户整个需求分析的跟进、分发和完整的产品迭代自动化流程。
效率提升：传统方式 vs QoderWork协同方式
最终我们比较一下传统方式跟QoderWork协同的区别：
首先在技能沉淀方面，如果没有AI工具，我们可能偶尔写一些总结文档放在共享知识库里。目前我们可以把技能一次性沉淀，然后持续复用到整个大团队，尤其像我们这种三四十人都是产品经理，可以长期复用。
第二是素材收集。无论你通过搜索引擎去搜各个竞品动向，或者它新发布了哪些功能，去收集整理这些素材并形成分析报告，可能至少需要两三个小时。目前用QoderWork直接告诉它你要研究什么领域，让它去总结技术演进路线、产品迭代路线，基本上半小时之内就能产出一个非常详细的报告。
第三、第四点主要是文档编写。以前文档工程师在每次产品功能上线，涉及十几二十几个功能时，写整个产品文档可能需要3到4个小时，这还是单个产品。像我们团队负责将近100款产品，每隔几个月就发布新功能，每个产品可能都要3到5小时。目前用QoderWork加上Skills形式，基本上半小时到45分钟。像Release Note可能十分钟就能写出来。所以给产品经理整体工作带来很大提升。
当然使用这些软件也会带来一些问题，还是要有保障机制。可能最终效果没有那么好，是因为中间没有交叉验证的机制。所以我们目前无论产出的界面还是文档，都需要通过技能验证的Skills做交叉验证。其次最终发布给客户之前，都是人再审一遍。对文档中的措辞或写法都需要着重看一下，防止出现易错性的漏洞，还是要有完整的保障机制。
总结与展望
目前我们团队产品经理岗的AI化程度已经达到85%的比例，是我们整个专有云团队里面使用深度和广度最深的岗位。
其次我们现在很多产品迭代工作，为了加速整个产品演进路线，可以使用QoderWork加Qoder形成一个完整的工具链，大大加速整个产品新功能或产品迭代到商业化的完整交付周期。
第三部分就是很多文档性或PPT的工作，都可以通过QoderWork目前的产品能力实现整体效率提升。同时可以把写PPT或写文档的过程沉淀成Skills，分享或复用到整个大团队里面。所以我们目前产品经理团队也在建立团队级Skills，并且希望能够把整个过程当中的度量体系给建立起来。
