转生到 AI 研发时代，我不再迷信一键生成代码
省流
先说结论。
AI 现在写代码确实快，但如果需求没理清、边界没问透、测试和文档都没准备好，就急着让它开写，最后很容易得到一份“看起来能跑，接手时很难改”的代码。
所以我现在更愿意把 AI 放进整条研发链路里：
- 先收集需求和项目上下文
- 梳理需求，暴露没确认的地方
- 拷问边界、权限和风险
- 出一份够用的轻量实现说明
- 用 TDD 收住核心逻辑
- 补测试、做 review、本地走查
- 输出测试用例，再把最终实现沉淀回文档
这套流程看起来比“把需求贴进去，等 AI 出代码”慢一点。
但真实项目里，快的不只是生成速度。返工少一点，后面的人能看懂一点，才是真的快。
建议阅读时间：10 min
为什么我不再直接让 AI 开写
很多人用 AI 写代码，第一步都是把需求丢进去，然后说一句：帮我实现。
刚开始确实很爽。
页面出来了，接口也接上了，速度快得像白捡了一段开发时间。但一放进真实项目里，问题也会跟着出来：
- 写法和仓库现有模式不一致
- 权限和数据范围漏了
- 异常流程没处理
- 测试只覆盖了看起来最顺的那条路
- 文档还停在需求阶段，代码已经跑到另一个方向去了
最麻烦的还不是它报错。
而是它不一定马上报错。它可能“看起来能用”，等你继续改、让别人接、或者下一个需求压上来时，才发现前面的上下文没给够，很多实现其实都是 AI 猜出来的。
需求没讲清，它只能猜。
项目限制没给够，它就按自己的默认习惯写。
我们以为自己省掉了前面的整理，实际上只是把这些问题挪到了后面。结果通常就是一句话：
生成越快，返工也越快。
我现在怎么把 AI 放进研发链路？
先看整体流程。
我的主流程大概是这 10 步：
- 收集需求和项目上下文
- 用
/requirement-analysis梳理需求 - 用
/grill-with-docs拷问需求、边界和风险 - 输出轻量技术实现说明
- 用
/tdd实现核心逻辑 - 用
/testing-vue-vitest补齐单元测试和组件测试 - 用
/code-review做代码审查 - 本地运行，人工走查核心流程
- 用
/testcase-excel输出测试用例 Excel - 用
/feature-doc-maintainer更新功能文档
这里容易误会一点：这不是一条从 1 走到 10 就不许回头的流水线。
需求阶段问出漏洞，要回去补上下文；review 发现方向不对，要回去改实现；本地走查点出问题，也不能因为已经走到第八步就硬往后推。
改得越早，成本越低。
1. 先把上下文收齐，再让 AI 工作
做正确的事，比正确做事更重要
不要一上来就让 AI 写需求、写方案、写代码。
AI 很擅长在已有材料上做整理和推进，但材料本身如果是空的，它也只能把空白补成一份看起来完整的答案。
所以第一步我会先收这些东西：
- 原始需求
- 历史文档
- 相似功能
- 接口说明
- 权限规则
- 现有项目里的实现方式
这里我会特别重视“相似功能”。
因为真实仓库里往往已经有自己的接口封装、权限判断、表单写法、状态管理方式。把这些给到 AI，它才有机会沿着项目本来的路走，而不是重新发明一套看着很新、落地很别扭的实现。
上下文准备得越清楚，后面每一步越省心。
反过来，如果第一批信息就错了，后面需求、方案、测试都会跟着偏。
2. 先梳理需求，没确认的地方就标出来
上下文有了以后，我不会马上切到开发。
先用 /requirement-analysis 把需求过一遍，把零散信息整理成能继续讨论的东西，比如：
- 功能背景是什么
- 这个功能给谁用
- 核心流程怎么走
- 涉及哪些字段和状态
- 哪些地方现在还没有结论
最后这一项很重要。
有些问题确实还没确认，这时候硬猜没有意义。直接写 TODO，后面找产品、测试或者负责人确认，反而更稳。
这一步结束以后，手里应该是一份能继续被追问、被修正、被拿来做方案的需求材料。“AI 已经理解了需求”这种说法听着顺，真往下推方案时用处不大。
如果这一步用 Plan 模式，会更适合把问题一轮一轮问清楚。
3. 别急着信需求文档，再拷问一遍
需求文档整理出来以后，最容易发生的事就是松一口气：好了，终于可以写代码了。
我现在会在这里多停一下。
用 /grill-with-docs 再问一轮，重点在专门找漏洞，别把已有内容换个说法就当成过关：
- 边界到底在哪
- 哪些场景这次不做
- 权限和数据范围会不会受影响
- 异常时用户看到什么
- 有没有前后端约定还没落下
很多问题正常阅读时看不出来，因为我们会自动把缺失的信息脑补上。
但只要换成追问视角，漏洞就会露出来。这个 Skill 对我比较有价值的地方也在这儿：决定还得我自己做，它主要是把那些本来可能到开发中途才暴露的问题，先摆到桌面上。
4. 复杂需求出一份轻量实现说明
到这一步，也不一定非要写一份厚重的技术方案。
文档太重，写的时候累，看的人也累。后面没人维护，它还会变成另一份过期上下文。
我更常用的是轻量实现说明，把真正会影响开发的东西说清楚：
- 准备怎么实现
- 会改哪些模块
- 数据流怎么走
- 有没有新增字段、状态和接口
- 哪些地方风险高
如果需求很简单，或者仓库里已经有非常成熟的同类写法，这一步可以省。
但只要改动开始跨模块，或者需要多人协作，有这样一份说明，后面写代码、补测试、做 review 都会少很多来回解释。
5. 用 TDD 收住核心逻辑
方案方向定下来后，才轮到代码。
这里我一般会先把 /tdd 用在核心逻辑上。原因也很直接：先把预期行为钉住，AI 后面的实现空间就会收窄很多。
像这些地方就很适合先测：
- 状态流转
- 工具函数
- 关键业务规则
- 复杂输入下的输出结果
但 TDD 也不是流程勋章。
如果只是纯样式、很轻的展示逻辑，或者一眼就能确认的页面拼装，就没必要为了“看起来规范”硬套一轮。该轻就轻，流程是为了控制风险，不是为了把每一步都做满。
6. TDD 之后，测试还没结束
/tdd 更偏向把核心逻辑走稳，不代表真实场景就都覆盖了。
前端功能里还有一堆很容易漏的东西：
- 页面交互
- 组件行为
- 异常流程
- 权限显隐
- 边界输入
所以代码完成后，我还会再用 /testing-vue-vitest 补一轮单元测试和组件测试。
这里我不会只把需求文档扔给 AI，让它自由生成测试。测试要结合最终代码看，不然很容易出现一种熟悉的场面：测试文件写了不少，真正容易出问题的路径没测到。
7. Review 先让 AI 过一遍，人再做判断
代码和测试有了以后，可以用 /code-review 再扫一遍。
它很适合提前挑出这些问题：
- 重复逻辑
- 边界处理不完整
- 测试没有覆盖关键场景
- 改动范围和原项目习惯不一致
但这里不要偷懒。
AI review 更像提前检查，不是合并许可。这个实现是不是符合项目现状，改动成本能不能接受，最后还是要人判断。
8. 本地走查这一步，跳不过去
Review 做完以后，我一定会自己把功能跑一遍。
特别是前端页面，光看代码和测试远远不够。页面能不能正常打开、搜索分页有没有问题、新增编辑删除能不能走通、弹窗回显对不对、错误提示合不合理、权限按钮显不显示，这些都得实际点。
这一步确实偏体力活。
但它也是最接近用户使用的那一步。AI 可以帮我们写代码、补测试、做 review，真正把功能跑起来验收，还是得人来。
如果本地走查发现问题，就回前面修。都走到第八步了还不回头，后面只会更难收拾。
9. 把测试用例接进协作流程
本地走查没问题后，我会用 /testcase-excel 整理测试用例。
这一步不能只看一句需求。生成用例时，最好把这些材料一起给到：
- 需求文档
- 技术实现说明
- 最终代码改动
- 已有测试点
- 本地走查结果
这样出来的用例会更贴近真实功能，而不是一份泛泛的表格。
我们当前会把 Excel 导入 Transcend 项目管理平台，或者交给测试继续评估。
10. 最后把最终实现写回文档
最后一步我会用 /feature-doc-maintainer 更新仓库内和功能强相关的文档。
这里通常补的是后面维护这个功能真正会用到的信息，不必凑成一篇很正式的长文：
- 功能说明
- 权限规则
- 接口变化
- 操作流程
- 已知限制
- 测试说明
很多文档只停在需求阶段。后面代码改了、实现收敛了、限制也变了，文档却没跟上。等下次再改这个功能，人和 AI 都得重新猜一遍。
所以文档我会放到链路最后更新，基于最终实现补回去。
这次工作的结果，不能只留在代码里。
哪些判断不能交给 AI
这套链路用了不少 Skill，但它的核心并不是“让 Skill 把人踢出流程”。
恰好相反。
越是让 AI 参与得深，越要知道哪些地方必须由人拍板。
需求阶段，人要判断方向是不是成立，哪些范围做，哪些先不做，哪些问题必须找产品或者负责人确认。AI 可以把问题列出来，但不能替我们做取舍。
代码和测试阶段，人要判断实现是不是贴合项目现状，改动成本是否可接受，测试有没有覆盖关键风险。代码能不能合进去、用例有没有价值，也不能只看 AI 给出的结论。
所以我更愿意把它理解成分工：
- AI 负责整理材料、生成候选实现、补检查
- 人负责取舍、验收和最终判断
前者能省掉很多重复劳动，后者不能省。
这套链路带来的变化
这套做法最大的变化，是整个过程更稳了。某一步突然快很多，未必每次都碰上。
需求问题暴露得更早
/requirement-analysis 和 /grill-with-docs 会把边界、权限、异常场景提前拎出来。能在开发前问清楚的问题，就别等代码写完再补。
AI 输出更容易检查
每一步都有输入和输出。需求、方案、代码、测试、文档可以串起来看，不再是让 AI 凭一段 Prompt 自由发挥。
测试更有依据
测试不再只是临门一脚补文件，而是跟着需求、实现、代码改动和本地走查一起收敛。它更接近风险本身。
文档不再只写在需求阶段
最终实现、权限规则、接口变化和已知限制会补回仓库。下次再改这个功能，不至于从头考古。
人能把注意力放回判断上
确认方向、筛选结果、决定能不能合，这些才是人真正不能让出去的部分。
实践时我会注意这几件事
-
需求阶段先用 Plan 模式
先问问题、拆边界、列 TODO。这个阶段的目标是把事情想明白，不是尽快把代码写出来。
-
复杂改动先做计划，再让执行模型落地
我习惯先用 Opus 4.7 做方案和拆解，再用 Composer 2.5 执行。
-
测试先抓核心路径，再补边界
用例也要人工筛。没有价值的测试，不要因为 AI 已经生成了就硬留。
-
文档基于最终实现更新
需求、代码、测试中途都可能调整。等本地走查和 review 过完，再把真正落地的东西补回文档。
最后
回到最开始的问题：为什么我不再迷信一键生成代码？
因为单纯让 AI 写代码，只能解决一小段效率问题。
真实研发里，拖慢我们的往往不是那几行代码敲得不够快，而是需求没说清、边界没想全、测试补得太晚、文档没有跟上。代码只是最后露出来的结果，前面的信息一乱，后面每一步都在补坑。
所以这条链路真正想守住的，是可控。
需求有依据，方案有约束，测试有反馈，文档有沉淀。AI 可以参与得很深，但每一步都要让人看得见、接得住、必要时退得回去。
这样提效才不会只停在某一次任务里。
本文用到的 Skill
| Skill | 作用 |
|---|---|
requirement-analysis | 梳理需求，把零散信息整理成可执行需求文档 |
grill-with-docs | 拷问需求边界、异常场景、权限和风险 |
tdd | 用测试先行的方式实现核心逻辑 |
testing-vue-vitest | 补齐 Vue 3 + Vitest 单元测试和组件测试 |
code-review | 做代码审查，提前发现质量和风险问题 |
diagnose | 遇到复杂 bug 或性能问题时，按复现、假设、验证、修复、回归的流程定位问题 |
testcase-excel | 生成测试用例 Excel，方便导入测试管理平台 |
feature-doc-maintainer | 根据最终实现更新功能文档 |
如果你也想把这些 Skill 放到自己的项目里，可以参考我整理的仓库：
Git 地址：github.com/535803710/a…
这些 Skill 不是固定答案，更像一套可以继续调整的流程模板。真正落地时，还是要结合自己团队的项目结构、测试规范和文档习惯再改一轮。
