产品经理 AI 工作流：如何让知识库、技能与复盘形成“工作大脑”
知识库提供完整项目上下文，工作流负责具体执行。产品工作并不是零散地写一份 PRD、画几个页面，而是一条持续推进的链路：从立项开始，经历材料入库、竞品调研、需求梳理、页面规格、原型设计、评审修改、研发交付，再到版本复盘。
其中，知识库负责保存项目背景、历史材料、会议结论、模板规范、命名规则，以及哪些内容已经确认、哪些内容仍待确认；工作流负责判断下一步该做什么、调用什么技能、产出写到哪里；AGENTS.md则承担调度职责，把规则、目录、索引和执行流程连接起来。
每完成一次工作，复盘又会把踩过的坑、暴露的规则漏洞、缺失的技能能力，反向补回知识库和 AGENTS.md。这样，项目经验不会随着一次交付结束而消失，而会逐渐沉淀为可复用的工作资产。
一、工作流地图：AGENTS.md 如何判断当前该做什么？
AGENTS.md 不只是管理目录、规则和索引的文件，还可以预置一张工作流地图。这张地图明确规定：不同阶段由什么条件触发、调用哪个技能、与前后环节如何衔接。
| 工作阶段 | 触发条件 | 对应技能或动作 |
|---|---|---|
| 新版本启动 | 明确声明“开始 V1.0.X 迭代” | project-iteration |
| 材料入库 | 项目新增文件或会议记录 | project-intake-pm |
| 竞品调研 | 需要调研竞品或比较方案 | competitor-analysis-pm |
| 需求撰写 | 开始写 PRD | prd-writer |
| 页面规格 | 修改原型前或新建页面规格时 | proto-spec-generator |
| 原型设计 | 需要画原型或修改原型 | prototype-html-pin |
| 评审回写 | 评审会结论需要落地 | 写入变更记录，并在文档中标注修改来源 |
| 文档站发布 | 原型修改完成后必须同步 | vitepress-deploy |
| TAPD 上传 | 需求需要进入 TAPD | tapd-requirement-upload |
| 版本收尾 | 版本结项 | project-iteration |
| 项目复盘 | 版本或需求收尾后 | project-retrospective-pm |
这张映射表的价值，在于让 AI 能够理解当前一句话属于哪个工作阶段。例如，说“帮我入库”，AI 应该读取材料入库规则；说“画这个页面”，AI 应该先寻找对应的页面规格文档；说“同步到服务器”，AI 应该进入文档站发布流程。
流程仍然由产品经理推动。人走到哪个阶段，AI 就调用对应技能执行；同时，AI 还能结合当前项目状态、历史决策以及前后步骤的衔接要求，避免每次工作都从零开始理解。
二、第一步：如何建立项目，让 AI 拥有固定的上下文容器？
新项目进入后，第一件事是在知识库中创建对应的项目文件夹。创建时，可以直接说明项目名称、背景目标、相关材料，文件也可以一并交给 AI 整理。
在规则明确的情况下，AI 可以初始化项目骨架，并建立以下基础文件：
- 项目总览：记录项目基础信息、涉及哪些端、当前所处阶段。
- 关键决策文件：沉淀已经确认的重要判断，避免后续反复推翻。
- 需求池：收集暂未整理、尚未进入正式需求文档的输入。
- 索引文件：为后续检索、引用和追溯提供入口。
项目骨架建立后，还可以查询知识库中的工作案例库，确认是否存在相同领域的历史案例。若有可参考案例，应先阅读，再开始新的工作，避免重复走已经走过的弯路。
项目建立起来以后，AI 才拥有一个稳定的上下文容器。后续的材料、决策、需求文档和原型，都应围绕这个容器持续流动。
三、第二步：材料入库，如何把散落信息变成可引用资产？
一个项目刚开始，往往会有大量背景材料：标准、政策、招投标文档、会议纪要、聊天记录、评审记录等。如果这些资料只是散落在本地文件夹中，AI 实际上无法稳定读取和使用。
AI 读不到材料，就只能猜。而产品工作里最容易出问题的，恰恰是依据不完整时的猜测。
使用 project-intake-pm 技能时，可以提供文件或链接，说明材料的作用，再提出“帮我入库”。AI 会按照项目规则处理内容，例如将 PDF、Word、Excel 等文件转换为 Markdown，存入对应目录，并同步更新索引文件。
会议纪要入库后，关键决策如何被保存？
以会议纪要为例，先将音频转换为文字稿，再交给 AI 处理。AI 会将会议纪要存入当前项目的会议记录目录，同时把关键决策提炼出来，按照 #D001、#D002 这样的编号写入关键决策文件。
这些决策默认标记为“待确认”，需要人工审核后，再改为“已确认”。这样做是为了避免会议中尚未定论的讨论，被错误地当成正式规则。
决策编号不是形式上的标记。后续写 PRD 时，可以直接引用，例如某个功能设计依据是 #D003。当有人追问“为什么这样设计”时，也能够顺着编号追溯到对应会议记录，找到原始讨论依据。
材料入库的核心，不是单纯存文件，而是把项目上下文整理成 AI 可以长期读取、持续引用的工作资产。
四、第三步：竞品调研，如何避免只看几个页面就下结论？
项目内部材料入库后，还需要了解外部信息。许多产品方案的问题，不是没有想法，而是看得太少：只看一个竞品、只截几个页面，就急着得出结论。这种调研方式很容易出现偏差。
通过 competitor-analysis-pm 技能进行竞品调研时，工作可以拆分为以下几个阶段：
- 假设确认：先明确调研给谁看、目标客户是谁、对应什么使用场景。方向没有问清楚，后面写得越多，偏差也可能越大。
- 竞品分层：对竞品进行分层，每一层选择若干代表对象，避免只盯着头部产品就下结论。
- 数据采集：按照统一维度收集资料，优先使用官方文档，并标注来源和时效。
- 对比分析：形成对比表。在准备说“别人都没有”之前，先强制寻找反例。
- 选型判断：判断哪些能力是真正优势，哪些能力只是行业标配。
- 报告输出：给出明确的推荐或不推荐结论，不留下含糊不清的尾巴。
竞品调研结论经过评审后，应反馈到知识库，更新关键决策文件和需求池。这样，后续 AI 撰写需求时，既能引用内部会议输入，也能引用外部竞品判断。
项目内部材料解决“我们知道什么”，竞品调研解决“外面已经做到什么”。两部分内容都进入知识库后，AI 后续的判断才不容易脱离实际。
五、第四步：PRD 怎么写，才能不脱离项目上下文？
调研完成、需求方向明确后，可以先把领导交代的需求原话交给 AI，让 AI 先规划思路。思路得到确认后，再输出正式 PRD。
使用 prd-writer 技能写需求文档时，关键不在于让 AI 立刻生成长文，而在于让它先完成必要判断。
1. 写 PRD 前，先强制读取项目上下文
AI 在写作前，应先读取项目总览、关键决策文件和最新会议记录，并沿着知识库关联内容进行梳理。
- 项目总览说明项目处于什么阶段。
- 关键决策说明哪些方向已经确定。
- 会议记录反映近期新增了哪些输入和变化。
不读上下文就开始写 PRD，方向很容易跑偏。
2. 先区分需求是改造，还是从零新建
AI 应根据输入判断需求属于改造类需求，还是新建类需求。两者都可能被称为 PRD，但实际关注点并不相同。
改造类需求要重点关注现有系统边界、历史数据和兼容逻辑；新建类需求则需要先建立角色、流程、范围和核心场景。
3. 先给出候选方案，再由人做取舍
对于背景、角色、核心功能、边界条件等内容，AI 可以基于项目上下文给出 2 到 3 个候选方案。产品经理先判断方向，确认后再进入下一轮细化。
AI 协作不能把人的判断关掉。AI 适合快速展开可能性、补充视角；产品经理仍然需要负责判断优先级、选择取舍和最终拍板。
4. 方向确定后，再输出完整 PRD
方案确认后，再一次性输出完整 PRD。需求文档可以按照六个部分组织：
- 背景
- 范围
- 流程图
- 功能详述
- 跨部门配合
- 待确认问题
后续，PRD 可以转换成 Word，也可以上传到腾讯文档继续微调。需求和功能范围确认后，在绘制原型前，还需要完成一份更细的页面设计材料，即原型规格文档。
六、第五步：为什么画原型前必须先写原型规格文档？
PRD 定稿后，如果直接让 AI 绘制原型，字段、模块和交互都可能出现遗漏或变形。原型规格文档的作用，就是在需求与原型之间增加一层控制。
使用 proto-spec-generator 技能时，AI 会把 PRD 中的功能点按页面逐项拆解，明确每个页面的模块、字段、筛选条件、操作按钮和状态规则，最终形成一组按照页面编号管理的规格文档。
该技能开始执行前，会先确认端侧划分，再分配对应的编号前缀。例如：
- PT：门户。
- AD：管理后台。
- MP：小程序。
同时，AI 还会从设计库加载对应端的 UI 基线参数，包括主色、圆角和画板宽度等。
规格文档不是为了多写一份材料，而是为了在画原型前检查字段、筛选条件、业务逻辑和页面边界。需求写得清楚，原型才不容易乱画。
七、第六步：HTML 原型如何成为需求、评审与研发的共同界面？
规格文档确认后，可以使用 prototype-html-pin 开始绘制原型。提出“画原型”或“画这个页面”后，AI 会读取对应规格文档，输出可交互的 HTML 原型。
1. 后台原型如何更接近真实开发效果？
后台原型可以对齐 Ant Design v5 的视觉基线，表格、表单、标签、详情页等常用组件已有固定规范。这样输出的后台页面会更接近真实开发效果，不会像传统低保真原型那样显得过于抽象。
2. 不同端的页面为什么不能混用一套样式？
管理后台、门户、C 端和移动 H5 应使用不同模板。AI 会根据页面类型选择相应视觉方案，避免把后台页面画成移动端，也避免把门户页面画成管理台。
3. 公共样式如何避免每个页面重复维护？
导航栏、菜单、侧边栏等公共内容，不需要在每个页面中分别维护。通过scaffold 源文件加 build 构建的方式，可以集中维护公共资源，最后再生成各页面文件。
这样，后期需要修改公共样式时，只需要修改一处。
4. 原型中的功能说明如何让研发快速看懂？
原型右侧可以保留功能说明区，关键元素通过红色圆点标注。研发查看原型时，可以直接找到对应模块的说明，而不需要翻找散落在不同地方的补充文档。
5. 评审修改后，如何保证 PRD、规格与原型一致？
评审发现问题后，可以直接修改原型；修改完成后，再由 AI 将差异同步回规格文档和需求文档，确保三份材料保持一致。
原型不能孤立存在。它应当成为需求确认、评审沟通和研发协作的共同界面。
八、第七步：如何把需求与原型交付给研发？
1. 文档站发布：让研发在线查看最新需求与原型
由于原型本身已经是 HTML，可以部署到内部文档站，供研发直接访问。需求文档和原型页面部署到服务器后，可以形成带密码登录的内部站点。
研发和前端输入密码后，即可在线查看需求和原型，不需要反复发送文件，也不需要导入某个原型工具。原型修改完成后，只需执行“同步到服务器”，线上版本即可更新为最新版本；每条需求附带对应原型链接，点击即可查看。
文档站不仅供人阅读，也可以供研发侧 AI 使用。原型是原始 HTML 文件，需求文档也可以通过 URL 访问。研发使用 Claude Code 或 Codex 时，可以将需求和原型链接交给自己的 AI，使其更快理解要做什么、页面长什么样。
这一步把产品侧 AI 工作流连接到了研发侧 AI 编码流程。
2. 上传 TAPD：如何让项目管理工具中的需求不再断链？
多数研发团队会使用禅道、TAPD、Jira 等项目管理工具。以 TAPD 为例，使用 tapd-requirement-upload 技能后，AI 会读取当前版本的需求文档和规格文档，判断需要上传哪些需求，为每条需求生成描述，并附上文档站中的需求文档链接和原型链接。
研发在 TAPD 中查看一条需求时，可以直接打开链接，看到对应原型和完整文档。
需求、原型、项目管理工具三边能够对应，交付就不容易散。其他项目管理工具也可以按类似逻辑接入，核心是让研发入口中的每一条需求，都能追溯到完整的产品说明和原型。
九、版本迭代：为什么新版本不是从零开始？
项目不会停在 1.0。使用 project-iteration 技能，提出“开始 V1.1 版本”后，AI 会在知识库中创建新的版本文件夹。
新版本建立时，需要遵循两条规则：
- 同步原型文件：新版本通常需要在上一版本原型基础上继续修改，因此原型需要继承。
- 不同步需求和规格文档：每个版本的需求相对独立，新版本只记录本版本新增或变更的内容。
有些团队习惯先做原型 Demo，确认没有问题后再补需求文档。对于知识库而言，这种工作方式同样可以兼容。
工作流不应强行规定每个人必须如何工作。它真正解决的是：每一次工作都要有明确入口、明确产物和明确回写。
新版本创建完成后，可以从材料入库重新切入，进入下一轮循环。
十、项目复盘：工作流如何在一次次踩坑中进化？
工作流跑完后，比“做完”更重要的事情，是回头检查哪里还可以改进。提出“复盘下当前的工作”后，可以调用 project-retrospective-pm。
复盘重点不只是评价项目做得好不好，而是检查工作体系本身：
- AI 这次在哪些地方出错？
- 现有规则是否存在漏洞？
- 知识库缺少了哪些关键内容？
- 当前技能还有哪些能力不足？
这些问题不能只停留在总结里，而要转化为具体改进建议，再写回知识库和 AGENTS.md。
每一条规则，都是从真实踩坑中换来的。规则逐渐积累，AI 会越来越顺手，整个体系也会在持续使用中逐步进化。
十一、工具环境：模型、上下文与人的判断分别承担什么角色？
这套流程对模型能力和桌面智能体有一定要求。实际使用条件包括：
重点并不在于某一个具体模型，而在于模型决定下限，上下文决定上限。
模型需要充分理解项目背景、模板规范、产出要求和历史决策，才有可能稳定完成任务，并在部分环节补足人的盲区。但无论工具能力如何变化，产品方向、优先级和最终判断仍然需要由人掌握。
AI 负责执行，你负责掌舵。不要让 AI 替你做产品，而要让它按照你的标准做产品。
结语：把产品经验留在体系里，而不是留在记忆里
从建项目、材料入库、竞品调研，到 PRD、页面规格、HTML 原型、研发交付、版本迭代和项目复盘，这套工作流的重点并不是简单增加几个 AI 技能，而是让每个步骤都有清晰的输入、产出、规则和回写位置。
知识库让 AI 知道项目过去发生了什么，工作流让 AI 知道现在应该做什么，复盘则让系统知道下一次应该改进什么。这样，项目资料不再散落，需求依据可以追溯，原型与文档可以同步，研发交付也能保持连接。
我认为：人做产品，最怕的并非工作多，而是事情做过以后没有留下可以复用的痕迹。会议开完便散，方案改完便忘，问题解决了也不追问缘由，久而久之，经验只藏在少数人的脑子里，项目却仍要一次次从头摸索。AI 若只用来写几段文字，不过是快一点；若能让材料、决策、规范和复盘都留下来，才可能真正成为工作中的助力。机器可以执行，人仍须判断；工具可以铺路，方向终究要握在人手里。
#项目复盘
© 版权声明
文章版权归作者所有，未经允许请勿转载。
