夜雨聆风
AI 时代的软件流水线,99% 的人都做错了
TL;DR
让 AI 裸奔写代码 = 让 AI 加速返工。
真正的 AI 时代研发流程是：AI 生成、人类决策、文档承载上下文、MVP 渐进交付。
本文给你一套 「7 个文件 + 5 个 Gate」的最小可行流程，附完整示例，今天就能落地。
📑 阅读路线图
建议从头读到尾。如果时间紧，可以直接跳到 第四节方法和 第十节速查表。
一、🎬 症状：一个熟悉的场景
周一上午，产品同学走过来：
“我们要做一个订单导出功能，你看一下，这周能上吗？”
你打开 Cursor / Claude Code，敲下：
“帮我实现订单导出功能。”
AI 飞快地生成了 300 行代码。然后，真实世界开始反击：
字段对不上
权限漏了
大数据超时
破坏老功能
📝 产品一句话需求
💻 直接丢给 AI
⚡ AI 生成大量代码
🔌 开始联调
出问题
回去问产品
让 AI 改
人工救火
继续救火
最终，你得出一个反直觉的结论：
AI 写得越快，返工来得越早。
二、🩺 诊断：为什么 AI 会失控？
问题不在于 AI 不会写代码。问题在于：我们经常让 AI 在缺少上下文、缺少边界、缺少验收标准的情况下直接开工。
来看一下「裸奔模式」和「流水线模式」的关键差异：
|
|
|
|
|---|---|---|
| 输入 |
|
|
| 范围 |
|
|
| 验收 |
|
|
| 过程 |
|
|
| 沉淀 |
|
|
| 结果 |
|
|
换一个角度看：AI 时代，开发者时间会被怎样重新分配？
写代码不再是开发者最值钱的能力，「把问题说清楚、把边界框清楚、把验收标准定清楚」才是。
AI 时代的软件开发要做到 4 件事：
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
三、💡 理念：AI 不是替代流程，而是进入流程
过去我们对 AI 的理解是这样的：
输入 prompt ──► 输出代码在真实软件工程里，这远远不够。更合理的方式是：
📥 需求
Intake定义问题
Research调研证据
Requirements需求分析
MVP Design最小版本设计
➡️ 继续
➡️ 接上
Prompt Spec编码任务书
Plan First先计划
Code生成代码
Review对齐验收
🔁 Next MVP继续迭代
核心理念用一句话概括
AI 生成、人类决策、文档承载上下文、MVP 渐进交付。
把这四个关键词展开：
|
|
|
|
|---|---|---|
| AI 生成 |
|
|
| 人类决策 |
|
|
| 文档承载 |
|
|
| MVP 渐进 |
|
|
四、🎭 角色化：把 AI 工具看成角色，不是绑死的产品
👤HumanReviewer
🔍 Research AgentGemini Deep Research
📋 Requirement AgentClaude
⚙️ Coding AgentCodex / Cursor
✅ Review AgentClaude / Codex
📁 docs/项目上下文
角色职责清单
|
|
|
|
|
|---|---|---|---|
| Research Agent |
|
|
|
| Requirement Agent |
|
|
|
| Coding Agent |
|
|
|
| Review Agent |
|
|
|
| Human Reviewer |
|
|
|
🔑 关键原则
流程绑定的是职责，不是工具。
今天可以是 Gemini + Claude + Codex，明天工具变了，只替换角色，不推翻流程。
五、🧰 方法：7 文件 + 5 Gate 的最小可行流程
很多团队做流程失败，不是因为流程不对，而是因为一开始就做得太重。
5.1 最小目录结构
docs/
└── order-export/
├── 00-intake.md # 定义问题
├── 01-deep-research.md # 调研证据
├── 02-requirements.md # 正式需求
├── 03-mvp-1.md # MVP 范围
├── 04-mvp-1-prompt.md # 编码任务书
├── 05-mvp-1-review.md # 验收记录
└── open-questions.md # 未决问题5.2 七文件工作流
持续更新
持续更新
持续更新
00-intake.md📝 定义问题
01-deep-research.md🔍 记录调研
02-requirements.md📋 正式需求
03-mvp-1.md🎯 MVP 范围与设计
04-mvp-1-prompt.md⚙️ 编码任务书
💻 代码实现Plan + Code
05-mvp-1-review.md✅ 验收与复盘
open-questions.md❓ 未决问题
|
|
|
|
|---|---|---|
00-intake.md |
|
|
01-deep-research.md |
|
|
02-requirements.md |
|
|
03-mvp-1.md |
|
|
04-mvp-1-prompt.md |
|
|
05-mvp-1-review.md |
|
|
open-questions.md |
|
|
5.3 五个 Gate：流程可控但不繁重
整个流程压缩到 5 个检查点，每个都是 1–2 个问题：
🚪 Intake Gate问题清楚?
🚪 Requirement Gate验收明确?
🚪 MVP Gate范围够小?
🚪 Plan Gate计划合理?
🚪 Review Gate满足需求?
|
|
|
|---|---|
| 🚪 Intake Gate |
|
| 🚪 Requirement Gate |
|
| 🚪 MVP Gate |
|
| 🚪 Plan Gate |
|
| 🚪 Review Gate |
|
5 个 Gate 已经足够防住绝大多数 AI 编码失控的问题。
六、🛠 实战演练：订单导出功能
需求一句话：“后台系统需要支持订单导出。”
这句话其实暗藏着至少 8 个问题：
导出哪些字段？谁可以导出？CSV 还是 Excel？数据量大怎么办？
是否需要异步？是否需要操作日志？是否允许导出手机号？失败后怎么提示？
所以我们不要直接进入编码。下面一步步走完整套流程。
Step 1 · Intake：先把问题说清楚
Intake 的目标不是写完整需求，而是先把问题边界框住。
📥 需求来了
先问 5 个问题
解决什么问题?
谁会使用?
什么算成功?
这次不做什么?
哪些问题需要研究?
📝 00-intake.md
💡 Intake 一页就够，不要写成大文档。
Step 2 · Deep Research：研究是证据库，不是需求
接下来用 Research Agent 进行调研。但要记住一个原则：
Research 是证据库，不是最终需求。AI 研究结果只是输入，不能直接变成产品决策。
调研得到的方案对比（直接放在文章里方便阅读）：
|
|
|
|
|
|---|---|---|---|
| 同步 CSV 导出 |
|
|
|
| 异步导出任务 |
|
|
|
| 报表系统 |
|
|
|
聚焦三个问题就够了：
-
• 🔍 这个需求有什么常见方案？ -
• ⚖️ 每种方案有什么优缺点？ -
• ⚠️ MVP 应该避开什么坑？
Step 3 · 需求分析：重点是收敛，不是发散
需求分析不是让 AI 继续发散，而是让 AI 帮我们 收敛到：
需求分析收敛而非发散
👥 用户故事
📐 范围边界
✅ 验收标准
⚙️ 非功能需求
❓ 未决问题
验收标准必须显式列出
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
open-questions.md始终在更新
|
|
|
|
|
|
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Requirement Gate 检查
否
是
否
是
否
是
🔁 继续澄清
✅ 进入 MVP 设计
Step 4 · 抽取 MVP：控制范围是核心
AI 很容易把功能做大。”订单导出”如果不控制，可能会被 AI 主动设计出：
异步任务 + 导出历史 + 字段配置 + 报表模板 + 邮件通知 + 权限矩阵 + 报表中心…
这些功能不一定错，但它们不属于 MVP。
📦 订单导出
MVP-1 ✅
同步 CSV
当前筛选条件
权限控制
5000 条限制
操作日志
MVP-2 ⏸
异步导出
导出历史
Excel 支持
暂不考虑 ❌
定时报表
自定义模板
报表中心
03-mvp-1.md必须包含三件事
03-mvp-1.md
✅ 范围内
❌ 范围外
🎯 Done Definition
🚨 没有「范围外」，AI 很容易过度发挥。
🚨 没有「Done Definition」，就很难判断是否真的完成。
Step 5 · Prompt 当成正式任务书
很多人对 AI 编程的理解还停留在”帮我实现这个功能”。这太模糊了。
更好的方式是把 prompt 写成一份正式任务书，并单独成文档：
需求文档
📜 Prompt 任务书
MVP 文档
open-questions
项目规则AGENTS.md
代码上下文
🤖 Coding Agent 理解任务
📋 先输出实现计划
Prompt 单独成文档的好处
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Step 6 · 编码前必须先 Plan
这是整个流程中最重要的一步。不要让 AI 拿到 prompt 就直接改代码。
Plan Review 能提前拦截的常见问题
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
💣 AI 写错一行代码不可怕，可怕的是它理解错任务后，写了一堆看似合理的代码。
Step 7 · 代码生成后，对照需求验收
AI 写完代码后，不要只问”能不能跑”，还要问：
-
• ✅ 它是不是实现了需求？ -
• 📐 有没有超出范围？ -
• 🔍 有没有漏掉验收标准？ -
• 🧹 有没有引入技术债？
建议让另一个 AI 做一次 交叉 review：
💾 代码 diff
🔍 Review Agent
02-requirements.md
03-mvp-1.md
🧪 测试结果
📄 05-mvp-1-review.md
验收记录直接做成对照表
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
结论：✅ Accept with follow-up。MVP-1 可以上线，MVP-2 评估异步导出和导出历史。
七、🚀 进阶：流程要匹配复杂度
不要所有需求都套完整流程。流程要和复杂度匹配。
用「T 恤尺码」匹配流程
|
|
|
|
|
|---|---|---|---|
| S |
|
requirements + prompt + review |
|
| M |
|
|
|
| L |
|
design + adr + 多 MVP + release |
|
📏 一句话：小需求不要流程过载，大需求不要裸奔开发。
八、⚠️ 避坑：5 个最常见的误区
|
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
九、📚 沉淀：两个长期上下文文件
除了每个需求的 docs/需求名/，建议在项目根目录维护两个长期文件：
约束
📗 CLAUDE.md
需求分析原则
文档规范
Review 检查项
Open Questions 规则
🤖 Requirement / Review Agent
约束
📘 AGENTS.md
项目结构
运行命令
代码规范
Done Definition
🤖 Coding Agent
💡 这两个文件的作用是把每次都要重复提醒 AI 的规则，沉淀成长期上下文。
十、📋 一页速查表（建议截图保存）
|
|
|
|
|
|---|---|---|---|
|
|
00-intake.md |
|
|
|
|
01-deep-research.md |
|
|
|
|
02-requirements.md |
|
|
|
|
03-mvp-1.md |
|
|
|
|
04-mvp-1-prompt.md |
|
|
|
|
diff + tests |
|
|
|
|
05-mvp-1-review.md |
|
|
十一、🎯 结语：AI 时代，真正重要的是上下文工程
过去软件开发最难的事情是写代码。
现在 AI 能写很多代码，于是最难的事情变成了：
把问题定义清楚，把上下文组织清楚，把边界约束清楚，把验收标准写清楚，把迭代过程记录清楚。
这就是 AI 时代软件开发的核心能力。它不只是 Prompt Engineering，而是更大的东西——三个工程能力的组合：
🧠 Context Engineering把业务、约束、债务交给 AI
⚙️ Workflow Engineering让 AI 按规矩工作
🔍 Review Engineering让人类的判断介入到正确的位置
AI 不会自动知道你的业务目标、系统约束、团队习惯和技术债。你需要通过 文档、流程和 review，把这些上下文传递给它。
最终目标很简单：
少返工、少跑偏、少猜测；多复用、多沉淀；更稳定地交付。
当 AI 负责生成、人类负责判断、文档负责承载上下文，你的团队就能从——
❌ “用 AI 写代码”
升级为——
✅ “用 AI 交付软件“
🚀 如果这篇文章对你有帮助，欢迎转发给身边正在被 AI “加速返工”的同事。