PM → Dev 全流程
AI 协作经验分享
从产品定义到代码合入，一个人 + AI 的完整实践
Troy · 2026 年 3 月
按 → 或 Space 开始

今天聊什么

整体流程
我用 AI 独立完成一个 feature 的端到端流程总览
PM 篇
产品调研、PRD 撰写、踩过的坑与最佳实践
工程师篇
技术调研、代码实现、调试上线中的经验
协作建议
推荐的文档结构和 PM↔Dev 交接方式

背景

Sprint 260320 期间，我独立完成了「导出健康报告给 AI」功能的完整开发：
PM 定义 → Design → 开发实现 → QA → 合入发布

因为我同时担任 PM 和开发的角色，所以有机会端到端体验 AI 辅助的完整工作流——从产品思考到代码落地。

今天的分享基于这次完整经历，总结出的流程、问题和建议。
希望能帮助大家在各自的角色中更高效地使用 AI。

01
PART 1
整体流程

一个 Feature 从 0 到 1 的 AI 协作全流程

八步走完一个 Feature

STEP 1
PM 调研
用 AI 了解现有功能：手动测试 + Claude Code 阅读代码
STEP 2
产品定义
与 AI 讨论并输出 PRD：目标、用户故事、逻辑、验收标准
STEP 3
技术调研
AI 分析代码库：入口、流程、需改动的文件和组件
STEP 4
定义 Analytics
与数据同事对齐埋点事件和参数
STEP 5
多轮 Review
AI 交叉审查产品文档和技术文档的一致性
STEP 6
代码实现
Coding agent 基于产品文档 + 技术文档实现功能
STEP 7
QA & Debug
手动验证 + AI 辅助调试
STEP 8
合入发布
代码 review → Merge → Release

文档是核心因素

AI 在每个环节都能帮上忙，但 「文档质量」 才是决定 AI 能否高效工作的核心因素。

输入给 AI 的上下文越准确、越精练，输出质量越高。
问题大多出在：文档缺失、文档不准确、文档之间不一致、上下文太冗余。
→ →
好的文档 = 好的 AI 输出
→ →
差的文档 = 反复返工
02
PART 2 · 面向 PM
PM 篇

产品调研、PRD 撰写、交接给开发

PM 调研阶段

用 AI 做产品调研

我的做法

1. 手动测试现有功能
亲自使用 app 内的健康报告功能，了解当前用户体验
2. AI 阅读代码库
用 Claude Code 理解现有业务逻辑、数据流、edge cases
3. 交叉验证
将手动测试结果与 AI 读码结果比对，找出差异

为什么要这样做

我发现该功能没有已有的产品文档，而数据同事维护的 analytics 文档和代码里的实际实现不一致。

如果直接用不准确的文档让 AI 写 PRD，后面所有步骤都会建立在错误的基础上。

先做调研，才能确保 AI 的输入是准确的。
PRD 撰写阶段

用 AI 写 PRD

方法：把调研结果 + 你的思考喂给 AI，逐步迭代
不要指望一次生成完美 PRD。先让 AI 给出初稿，然后多轮对话——质疑它、补充你的想法、让它挑战你的假设。
Goal / Why
清晰定义目标和业务价值
User Stories
用户场景 + 验收标准
User Flow
现有流程 vs 改动后的流程
Scope
明确做什么、不做什么
Acceptance Criteria
可验证的具体条件
QA Test Cases
直接可用于测试的场景
PM 常见问题

坑 ① 现有文档缺失或不准确

⚠️ 问题
现有功能没有产品文档，已有文档和代码实现不一致，甚至团队成员脑中对现状的理解也可能和实际不一致。
如果 AI 基于错误信息生成 PRD，后续所有环节都会偏离。所以更需要在动手前对现状进行检查和确认。
✅ 解决方案（根据实际情况选择）
  1. PM 用 AI 对照代码库验证 PRD——在写 PRD 时就让 Claude Code 检查现有逻辑是否和你的理解一致
    ⚠️ 对 PM 要求较高，需要了解代码库结构
  2. Dev 的 AI 审查 PRD——开发侧用 AI 阅读代码后，回过来 review PM 文档
  3. Dev 先生成现状摘要给 PM——开发让 AI 生成一份「系统现状」文档，PM 以此为基础撰写 PRD
    ⚠️ 需要 PM 和 Dev 之间有充分沟通
方案 1 和 3 目标相同（确保 PM 了解真实现状），选择取决于 PM 的技术熟悉度和 PM-Dev 协作模式。
PM 常见问题

坑 ② PRD 与代码实际状态不一致

⚠️ 问题
PM 写的产品逻辑和代码库中的实际逻辑有出入，或者 PRD 内部存在自相矛盾的地方。
Coding agent 拿到矛盾的文档会产生不可预期的行为。
✅ 解决方案
  1. 让 AI 自查文档内部一致性——直接让 Claude 检查 PRD 中是否有矛盾
  2. 让 AI 对比文档与代码库——让 Claude Code 交叉验证文档描述和实际代码，识别 risks 和 edge cases
💡 Tip：多用不同 AI / 不同 session 做 review
一个 session 的上下文积累太多后，AI 可能会「顺着你说」。开一个新的 session 或换一个模型来审查，往往能发现不同问题。
PM 常见问题

坑 ③ PRD 中的业务上下文对开发是噪音

⚠️ 问题
PRD 中通常包含业务目标、前期数据分析、竞品分析等。这些对 PM 和管理层很重要，但对 coding agent 而言是无关上下文——过多冗余信息会降低代码生成质量。
✅ 解决方案：把 PRD 和 Dev Handoff 分开
  1. PRD——完整版，包含业务背景，用于 PM 自己和管理层 review
  2. PM → Dev Handoff——精简版，只保留「要做什么」，去掉业务背景，专门用于交给开发/coding agent
实用 TIPS

PM 使用 AI 的建议

💡 让 AI 主动向你「提问」——反转模式
不要自己想着要提供哪些背景信息，而是把任务反过来给 AI：
你的任务是采访我，获取你完成 [任务] 所需的所有信息。
AI 会主动引导你，逐步问出它真正需要的内容。这个「反转模式」同样适用于自定义 Skill 的设计——与其把所有细节塞进 Skill，不如让 Skill 驱动 AI 来问你问题。
💡 用 Claude Cowork 的 Skill 来生成 PRD
Cowork 自带 product management PRD skill，但它更多是提供结构模板。建议自定义 Skill，让 AI 更主动地向你询问背景、edge cases、用户场景等——通过问答来补充信息，而不只是填模板。
💡 用独立的 Sub-agent 来质疑和 Review PRD
可以定义一个专门「挑刺」的 Sub-agent 来 review PRD——独立的 Agent 拥有独立上下文，避免主对话中的 context 污染，能更客观地发现问题。也可以直接在写 PRD 时主动问 AI：「这个方案有什么漏洞？」「有什么 edge case 我没考虑到？」
💡 Acceptance Criteria 要写得「可测试」
不要写模糊的描述，而是写成「Given X, When Y, Then Z」的格式。这样 AI 可以直接基于此生成测试用例甚至测试代码。
💡 复用 AI 生成的 QA Test Cases
PRD 中让 AI 生成的 test cases 可以直接用于 QA 阶段，减少重复工作。
03
PART 3 · 面向工程师
工程师篇

技术调研、代码实现、踩坑与调试

技术调研阶段

用 AI 做 Dev Research

拿到 PM 文档后，先别急着写代码。让 AI 帮你做一次技术调研，产出一份 Pre-implementation Doc：

代码入口分析
让 AI 找出当前功能的代码入口点，理清调用链路
现有代码流程
AI 梳理当前 code flow 和核心逻辑
需要改动的文件
列出需要新增/修改的文件和组件
已有测试覆盖
确认现有测试覆盖情况，评估改动风险
💡 为什么要先做 Dev Research
直接让 coding agent 开始实现容易导致大面积代码改动。先做技术调研，能让 AI 有更精准的上下文，生成更少、更准确的改动。
工程师常见问题

坑 ① 缺少 UI/设计上下文

⚠️ 问题
即使用了 Figma MCP，AI 生成的 UI 仍然不够精准。因为设计稿通常基于单一屏幕尺寸，缺少布局信息（如绝对定位、Auto Layout 等）。
✅ 解决方案
  1. 开发者写明确的 prompt——补充布局描述：「这是一个垂直滚动列表，item 高度固定 64pt」
  2. 设计师添加 Figma annotations——标注间距、尺寸、布局方式
  3. 设计师尽量在所有 component 使用 Auto Layout + Constraints——两者同时使用，结构信息能更好地传达给 coding agent
  4. 长期方案：建设 Design System——代码和设计共享 design tokens，AI 可直接引用（可参考 Google Stitch 的 Design.md）
工程师常见问题

坑 ② 等待终稿 UI 阻塞开发

⚠️ 问题
设计终稿还没定，开发无法开始——在传统流程中很常见。但在 AI 辅助开发中，这个等待的代价更大，因为 AI 可以快速产出代码，人力等待变成了瓶颈。
✅ 解决方案（根据实际情况选择）
  1. 先用线框图 + design tokens 开发——有了 Design System 后，开发可以基于 wireframe 先写功能，后续由设计师精调 UI
    类似 Anthropic 设计师推荐的做法
  2. PM / Design / Dev 持续同步——缩短等待时间
    ⚠️ 实现较难，主要限制在于不同 role 之间的协调成本
工程师常见问题

坑 ③ 需求变更导致文档与代码不同步

⚠️ 问题
开发过程中需求发生变化（新增字段、改交互、砍功能等），但文档没有同步更新。Coding agent 再次运行时可能基于过时文档产出错误代码。
✅ 解决方案
  1. 文档和代码同步更新——需求变更时，第一步是更新文档，第二步才是改代码。Commit 的时候同时 commit 文档和代码的修改，方便相互对照。
  2. 推荐流程：Prompt → 更新文档 → Agent Review → 修改代码——告诉 AI 变更内容，先让它修改 PRD / Handoff / Implementation Doc，然后让 Agent review 文档变更，最后再根据修改后的文档更新代码。
💡 Tip：通过文档驱动代码修改，而非直接改代码
尽量避免直接通过 prompt 修改代码，而是通过 prompt 修改文档，再根据文档修改代码。除非是特别小的改动（比如改 string、小的 UI 偏移）。在 AI 协作模式下，文档不再只是沟通工具，而是 coding agent 的输入源——文档不准 = 代码不对。
工程师常见问题

坑 ④ Analytics 事件阻塞开发

⚠️ 问题
Analytics 事件和参数没有提前定义好，开发在实现功能时因缺少埋点规范而被阻塞。
✅ 解决方案（根据实际情况选择）
  1. 提前定义 analytics events——在 sprint 开始前就与数据团队对齐埋点方案
    张礞已经开始尝试提前定义 analytics events 了
  2. 先开发功能，后加埋点——功能和埋点可以解耦，先完成核心功能再补充 analytics
    ⚠️ 注意：需要明确告诉 AI 在初始开发阶段不要自作主张添加/修改埋点
实用 TIPS

工程师使用 AI 的建议

💡 让 AI 主动向你「提问」——反转模式
不要自己想着要提供哪些背景信息，而是把任务反过来给 AI：
你的任务是采访我，获取你完成 [任务] 所需的所有信息。
AI 会主动引导你逐步补充它真正需要的内容，而不是靠你记住所有要提供的细节。这个「反转模式」同样适用于自定义 Skill——让 Skill 驱动 AI 向用户提问，而不是让用户记住要输入什么。
💡 为 Repo 精心维护 CLAUDE.md / AGENTS.md
在 repo 中建立 CLAUDE.md 或 AGENTS.md，记录非显而易见的规则和约定，帮助 coding agent 理解项目上下文。建议团队共用同一份规则文件，避免各自为政。（我已经和帅哥同步并共享了 iOS client 的 AGENTS.md。）
💡 先调研，人工/AI Review，再实现
让 AI 先生成 pre-implementation doc（入口、代码流、影响范围），经过人工或 AI review 确认后，再开始写代码。这能显著减少 AI 产出的无效改动。
💡 用 Claude Code Hooks 自动化流程
Hooks 的三大用途：
① 自动化质量流程——代码提交前自动 lint、跑测试；
② 任务完成提示——Claude Code 完成任务后自动通知，工程师不需要一直盯着等待，也避免回来发现 AI 已经空等很久；
③ 强制 review 流程——代码修改后自动触发 Agent review，或检测是否有匹配的文档修改。
💡 让不同的 AI review AI 的代码
可以开新的 session 或使用独立上下文的 Sub-agent 来审查。更建议的做法：使用完全不同的 agent，比如用 Codex review Claude Code 的产出，或者反过来——不同模型的「视角」差异往往能发现更多问题。
💡 拆分任务给 AI
不要让 AI 一次做太多事。把一个大 feature 拆成小 task（如：先改 data model，再改 UI，再加 tests），逐步完成效果更好。
💡 对照 PRD 验收代码
完成后让 AI 对比 PRD 中的 acceptance criteria 逐条检查代码实现，确保没有遗漏。
04
PART 4 · 面向所有人
协作建议

推荐的文档结构和团队协作方式

推荐做法

三份文档，各司其职

📋 PM 的 PRD
业务上下文 · PM & 管理层
  • Background / Problem
  • 当前数据
  • Goals / Non-goals
  • 目标用户
  • 用户场景 & 验收标准
  • 当前 vs 改后的用户流
  • 功能 & 非功能需求
  • Risks & 开放问题
  • 成功指标 & 度量
🤝 PM → Dev Handoff
精简交接 · 告诉开发做什么
  • Summary
  • Problem & Why
  • In-scope / Out-of-scope
  • 当前产品逻辑
  • 目标产品逻辑
  • User Stories + AC
  • Edge Cases
  • Requirements
  • A/B Test & Analytics
💻 Dev Implementation
技术实现 · 开发者 & Coding Agent
  • Background & 技术设计
  • Technical Goals / Non-goals
  • 当前技术状态
  • 相关组件 / 接口
  • 数据存储 & 数据流
  • 技术约束
  • 计划改动
  • 关键决策 & 理由
  • 测试 & 可观测性
推荐做法

AI 时代的 PM ↔ Dev 工作流

PM 调研
AI + 手动验证 → 写 PRD
AI 迭代生成 → AI Review
一致性检查 → 产出 Handoff
精简交接文档 → Dev 调研
AI 分析代码库 → 实现
Coding Agent → QA & Merge
AI Review + 手动
🔄 需求变更时：先更新文档 → 再改代码 → 保持同步

关键 Takeaways

01
文档是 AI 的燃料
文档质量直接决定 AI 输出质量。投资在文档上的时间会在开发阶段回报数倍。
02
PRD ≠ Dev Handoff
业务上下文是给人看的，coding agent 需要的是精练的「做什么」和「怎么验收」。
03
先调研，再实现
不管是 PM 还是 Dev，让 AI 先帮你理解现状，然后再让它帮你创建新东西。
04
让 AI review AI
用不同 session / 不同角色的 AI 交叉审查，比单一 session 效果好得多。
05
文档和代码要同步
需求变更时第一步更新文档。在 AI 时代，文档就是代码的 source of truth。
06
善用 AI 工具的高级功能
Hooks、Skills、多 session review —— 探索并利用这些功能能大幅提升效率。
谢谢
Q & A
「用 AI 工作的关键不在于 AI 多强，而在于你给它的上下文有多好。」