一位阿里产品经理的AI全流程提效实践：从需求到上线全覆盖

这张图来自于我们团队三十多个人日常使用AI这些工具，分析总结提炼出来的。我们核心用的两个工具，一个是Qoder，一个是QoderWork。主要覆盖场景：

• 日常文档和产品方案。包含文档报告调研、生产方案产出、对竞对的调研、行业趋势、日常产品所有相关类的文档、深度分析，还有售前的各种产品方案——比如解决方案、销售数据、招标参数、定价等等。

• 产出原型。从设计到研发，完全能够由产品经理基于Qoder和QoderWork产出交互稿，最终产出原型，然后跟前端协同开发。目前我们已经实现了2到3天之内产出一个系统化的所有菜单功能页面，半个月发一个版本，一个月发一个大版本，同步产出所有产品功能的Release Note、产品介绍以及用户指南等各种文档。

• 自动化任务。包括日常定时任务提取、技术方案定时追踪、友商信息推送等等，都会通过自动化和日常任务去协同。

• 需求和任务的跟踪。将来源于各个渠道的需求，比如客户提的需求，通过QoderWork去做分析总结，自动体验完，自动去实现整个产品流程，然后转给研发。

• 定时的行业分析和交互PRD。将过程当中协同用到的能力都沉淀成Skills，然后团队内共享、复用，来提升整个产品的AI化程度。

产品经理以前那种传统方式，可能自己手搓原型，或者用Axure等各种工具去画图。当需要改一个功能或者改某个下拉框的时候，很多东西都要跟设计师沟通。中间的沟通成本特别高。而且整个迭代中间会有大量的信息损耗。以前要画一个非常复杂的、可能涉及到二十几个界面的功能时，可能要花2到3周，迭代周期非常长。

现在有了Qoder和QoderWork，我们可以直接在IDE里面用自然语言描述需求。它会把整个页面生成出来，你在这个基础上不断调整优化。基本上产出的整个前端代码仓库可以直接在后续的研发阶段复用。

第二部分是和设计师的协同。我们会统一把代码提交到Git上面。设计师和我们PD同样有一个代码分支。设计师会基于QoderWork里面生成的代码进行UI的重构。

主要重构哪些呢？第一，把所有前端组件进行统一。我们这边用的是shadcn/ui组件，设计师会把设计Skills也同步到工程里面。比如对所有系统里面的颜色、间距、字体、圆角各个组件的设计，都会通过一个Skills直接集成在工程里面，然后做一键优化。最终我们会在上面做走查，觉得哪里有问题就直接修改。我不需要线下口述跟设计师沟通，都互相在一个代码分支上协同，实现了快速的产品终稿交互原型交付。

第四阶段就是写PRD。我自己也是在QoderWork里面，通过创建技能页面，写了一个PRD Writing的技能。里面包含具体的写作要求——因为每个人对PRD都有不同格式要求，不同行业的产品区分度很大。从我这边来说，因为我们是偏技术平台的产品，所以对章节要求、必备模块、业务流程都有特殊要求。我没有用现成的PRD模板，而是把团队目前写得比较优秀的、或者我之前写过比较详细的PRD扔到QoderWork里面，直接让它分析总结，帮我生成了一个写作PRD的Skills。

用QoderWork生成PRD的心得：一定要给它特定的角色定位，同步要给它足够的知识源清单。包括前面在线网页Demo地址——它会自动调浏览器把所有界面都点一遍。还有前面的背景知识，比如Wiki知识点、冲突解决原则。最终生成一份不需要花太多时间微调的PRD。最终你可以在里面补业务细节，修复逻辑漏洞。通过MCP连接器直接发到内部钉钉文档上，交付给研发。

第五阶段是前后端协同，实现整个产品功能的还原。左侧是我们目前采用的研发、设计师、前端、后端共用分支的协同策略。我们会统一在design分支上协作。

最终真正要开发时，可能前端和设计师都会进来微调。真正开发时会让研发基于这个分支切出一个DEV分支，在这个DEV分支上把后端设计的API文档直接灌给它。前端根据API文档和界面，直接就能生成带业务逻辑的产品功能和界面，然后持续更新。如果发布上线，就把研发分支合到master主干分支。这样的方式可以快速帮前端不遗漏产品经理关注的功能点和细节，只需要补充API逻辑就能实现功能的快速上线。

第六阶段是用QoderWork做产品领域的竞品市场分析，包括收入预测。前提是要给它足够多的数据，比如类似产品在全国或全球的市场规模是多大，中国市场是多大，去年类似产品的销售数据。给到它后会通过深度分析，最终推测出产品大概的收入预测模型。目前给出的结果非常精准。包括产品的定价模式、折扣分析都可以通过QoderWork来实现。

第七部分就是产品经理要写各种文档：用户指南、开发指南、技术白皮书、Release Note、API文档、产品简介，很多很多。我们目前也是基于QoderWork的Skills，能批量把这些文档生产出来。比如用户指南里面每一个功能，从新建、删除到列表，包括详情页，它都可以一步步去访问、截图，然后帮你写出这个功能。最终你可能只需要让研发和PD一起评审一下文档就可以直接发布上线对客了。

第八个阶段是产品的售前招标环节的生产。比如我们新产品所有的技术招标参数都来自功能清单，让它基于前面生成的功能清单，一键能生成技术招标参数。同时包括写PPT功能，很多解决方案都是基于QoderWork里面幻灯片功能（目前是Beta版本）写出来的。当然今天我这个演讲PPT也是通过QoderWork写出来的，但有几页是单独微调过的。

你可以通过销售数据的上升或下降，来潜在分析一些问题，包括资源评估。这里的点比较多。比如左上角第一张图是各种文档，每一个文档里面可能都是十几万字，基本全都是用QoderWork去写出来的。包括商品定价分析、右侧的招标参数，以及我写的产品新功能介绍PPT，都是真实的——利用QoderWork现有的能力产出来的。

最终我们比较一下传统方式跟QoderWork协同的区别：

首先在技能沉淀方面，如果没有AI工具，我们可能偶尔写一些总结文档放在共享知识库里。目前我们可以把技能一次性沉淀，然后持续复用到整个大团队，尤其像我们这种三四十人都是产品经理，可以长期复用。

第二是素材收集。无论你通过搜索引擎去搜各个竞品动向，或者它新发布了哪些功能，去收集整理这些素材并形成分析报告，可能至少需要两三个小时。目前用QoderWork直接告诉它你要研究什么领域，让它去总结技术演进路线、产品迭代路线，基本上半小时之内就能产出一个非常详细的报告。

第三、第四点主要是文档编写。以前文档工程师在每次产品功能上线，涉及十几二十几个功能时，写整个产品文档可能需要3到4个小时，这还是单个产品。像我们团队负责将近100款产品，每隔几个月就发布新功能，每个产品可能都要3到5小时。目前用QoderWork加上Skills形式，基本上半小时到45分钟。像Release Note可能十分钟就能写出来。所以给产品经理整体工作带来很大提升。

当然使用这些软件也会带来一些问题，还是要有保障机制。可能最终效果没有那么好，是因为中间没有交叉验证的机制。所以我们目前无论产出的界面还是文档，都需要通过技能验证的Skills做交叉验证。其次最终发布给客户之前，都是人再审一遍。对文档中的措辞或写法都需要着重看一下，防止出现易错性的漏洞，还是要有完整的保障机制。

目前我们团队产品经理岗的AI化程度已经达到85%的比例，是我们整个专有云团队里面使用深度和广度最深的岗位。

其次我们现在很多产品迭代工作，为了加速整个产品演进路线，可以使用QoderWork加Qoder形成一个完整的工具链，大大加速整个产品新功能或产品迭代到商业化的完整交付周期。

第三部分就是很多文档性或PPT的工作，都可以通过QoderWork目前的产品能力实现整体效率提升。同时可以把写PPT或写文档的过程沉淀成Skills，分享或复用到整个大团队里面。所以我们目前产品经理团队也在建立团队级Skills，并且希望能够把整个过程当中的度量体系给建立起来。