转生到 AI 时代，我不再相信一键生成代码的传说

省流（ TL;DR ）

• 核心问题：不是 AI 不会写代码，而是需求、边界、测试、文档没准备好就让它开写，代码「看起来能用、后面难改」。
• 做法：用一串 Skill 把 AI 放进完整研发链路 先收集上下文，再梳理需求、拷问边界、出轻量方案，然后 TDD 实现、补测试、做 review 、本地走查、导出用例、更新文档。
• 流程特点：10 步有顺序，但可在需求、方案、审查、走查、文档等环节回退修正，越早改成本越低。
• 人的角色：AI 负责整理和生成，取舍、验收、能不能合仍要人判断；目标是可控、可复用，不是一次性提速。

建议阅读时间: 10min

转生到 AI 研发时代，我不再迷信“许愿式编程”，而是把 AI 放进需求、开发、测试和文档这一整条研发链路里。

一、为什么 AI 的代码总是很难维护？

很多人用 AI 写代码，第一步就是把需求丢进去，让它直接生成。

刚开始确实很爽，速度快，效果也像那么回事。但接到真实项目里，问题就来了：写法和项目不一致、权限漏了、边界没处理、异常场景没考虑，测试也跟不上。

这些代码最麻烦的地方是“看起来能用，但后面难改”。因为它不是基于完整上下文写出来的，而是基于一段临时描述生成的。需求没说清，AI 就只能猜；项目约束没给够，AI 就按自己的习惯写。

所以很多时候，不是 AI 写代码不行，而是我们让它太早开始写代码了。需求、边界、方案、测试点都没准备好，就让 AI 开始实现，最后生成得越快，返工也越快。

二、我的整体链路

1. 收集需求和项目上下文

2. 使用 /requirement skill 梳理需求

1. 使用 /grillwithdoc skill 拷问需求、边界和风险

2. 输出轻量技术实现说明

1. 使用 /TDD skill 实现核心逻辑

2. 使用 /testing skill 补齐单元测试/组件测试

1. 使用 /code review skill 做代码审查

2. 本地运行，人工走查核心流程

1. 使用 /testcase skill 输出 Excel ，用于导入 Transcend 项目管理平台

2. 使用 /feature-doc-maintainer 更新文档

这条链路不是只能从 1 走到 10 的直线流程。

主流程顺序推进，但在需求拷问、技术方案、代码审查、本地走查和文档更新阶段，都可能回退到前面的步骤。发现问题就回到前面修正，越早改，成本越低。

第一步：先收集上下文，再让 AI 工作

不要一上来就让 AI 写需求、写方案或者写代码。因为在上下文不完整的情况下，AI 很容易给出看起来完整、但实际一坨的结果。

所以第一步是先把和需求相关的信息整理出来，比如原始需求、历史文档、相似功能、接口说明、权限规则等。尤其是已有的相似功能很重要，它能让 AI 参考项目里真实的写法，而不是重新发明一套方案。

上下文准备清楚了之后接下来就可以轻松的走下面的流程了，但是如果一开始信息有误，那很可能会在错误的基础上进行。

第二步：用 /requirement skill 梳理需求

上下文准备好之后，不要急着进入开发。先用 /requirement skill 把需求过一遍。

这一步主要是把零散的信息整理成结构化内容，比如功能目标是什么、给谁用、核心流程怎么走、涉及哪些字段和状态、权限规则是什么。

这里要特别注意未确认问题或者是当前没有想明白的地方，一定要先用 TODO 标记出来后面找人确认。 整理完后，基本能产出一个可执行的需求文档，能够明确整体方向了。后面我们还会用 grillwithdoc 来敲定细节

这里产出的时候记得选 plan 模式

第三步：用 /grillwithdoc skill 拷问需求

有了需求文档之后，不要马上认定它就是对的。这个时候可以用 /grillwithdoc skill 再拷问一遍。

使用 plan 模式的话 有 对话框 可以一次一次确认

这一步主要是检查需求有没有说清楚，比如边界在哪里、哪些场景不做、异常情况怎么处理、权限和数据范围有没有影响、按钮控制是不是完整。很多问题在正常流程里看不出来，只有换个角度追问，才会暴露出来。 这个 /grillwithdoc skill 很强，基本能把所有边界和细节明确的的很清楚。

拷问完成之后就能够得到一份宝贵的确认好细节的需求文档了

第四步：输出轻量技术实现说明

需求细节确认完之后，就可以开始看怎么实现了。

这里不建议一上来写很重的技术方案，太长了没人看，后面也不一定维护。我的做法是输出一份轻量技术实现说明，把关键内容讲清楚就行。

这一步的价值是让后面的开发有一个明确方向。特别是多人协作或者需求比较复杂的时候，有一份轻量说明，后面写代码、补测试、做 review 都会顺很多。

如果需求很简单，或者已经很明确了，这一步也可以省略，后期少维护一个文档

第五步：用 /TDD skill 实现核心逻辑

技术实现说明确定之后，就可以开始写代码了。

使用 /TDD skill 先处理核心逻辑。不要直接让 AI 上来一顿写，最好先让它拆出核心行为，然后先写测试，再实现代码。

这样做的好处是能限制 AI 的自由发挥。测试先写出来，AI 后面的实现就要围绕这些行为来做，不容易写偏。

/TDD skill 更适合用在核心逻辑、状态流转、工具函数、关键业务规则这些地方。如果是纯页面样式或者很简单的展示逻辑，就没必要硬套 TDD 。该轻就轻，不要把流程搞复杂。

第六步：用 /Testing Vue Vitest skill 补齐测试

TDD 做完之后，不代表测试就完成了。

TDD 更关注核心逻辑有没有写对，但页面交互、组件行为、异常分支、权限显隐这些，很可能还没有覆盖到。所以后面还要用 /testing skill 再补一轮。

补测试的时候也要结合最终代码看，不能只根据需求文档生成。否则测试看起来很多，但可能测不到真正关键的地方。

/Testing Vue Vitest skill 这个也包含了页面 UI 的 单元测试

第七步：用 /code review skill 做代码审查

代码和测试写完之后。这个时候可以用 /code review skill 再过一遍。

/code review skill 也适合用来发现一些容易忽略的问题，比如重复逻辑、边界处理不完整、测试没覆盖到关键场景等。

会按照优先级输出一份质量报告

不过这里还是要注意，AI review 只能作为提前检查。最后这个代码能不能合进去，还是要人自己判断。

第八步：本地运行和人工走查

review 完之后，一定要本地跑一下。

尤其是前端功能，不能只看代码和测试。页面能不能打开、搜索分页有没有问题、新增编辑删除是否正常、弹窗回显对不对、错误提示是否合理、权限按钮有没有按预期显示，这些都要实际走一遍。

这一步纯体力活，就是人工验收。AI 可以帮你写代码、补测试、做 review ，但它不能替你真实使用一遍功能。

如果本地走查发现问题，就回到前面的步骤修。不要因为流程已经走到第八步了，就硬往后推进。

第九步：用 /testcase skill 输出测试用例 Excel

本地走查通过之后，就可以开始整理测试用例了。

这里我会用 /testcase skill 输出测试用例 Excel 。它不是只根据最开始的需求生成，而是结合需求文档、技术实现说明、最终代码改动、已有测试点和本地走查结果一起生成。

这样出来的用例会更贴近真实功能，不容易写出那种看起来很完整、但测不到重点的内容。

我们当前是把 Excel 导入 Transcend 项目管理平台。或者交付给测试，让测试评估。

第十步：用 /feature-doc-maintainer 更新文档

最后一步是更新文档。

这里的文档主要是仓库内和功能强相关的文档，比如功能说明、权限规则、接口变化、操作流程、已知限制、测试说明等。不是为了补一篇很正式的文档，而是把最终实现沉淀下来。

很多时候文档只停留在需求阶段，后面代码改了，文档没跟上。时间一长，下一次再改这个功能，又要重新理解一遍。

所以我会在链路最后用 /feature-doc-maintainer 做一次同步，把最终实现和关键说明补回去。这样这次工作的结果，不只停留在代码里，也能给后面的人（ AI ）继续用。

三、人的判断点

做正确的事，比正确地做事更重要。

这套链路虽然用了很多 Skill ，但核心判断不能完全交给 AI 。

AI 可以帮我们整理信息、生成内容、补齐测试、做初步审查，但需求取舍、技术判断、测试评估和最终验收，还是要人来负责。

• 需求阶段：需要判断方向是否成立，哪些范围要做，哪些先不做，哪些问题必须找产品或负责人确认。AI 可以把问题列出来，但不能替我们做取舍。

• 代码和测试阶段：需要判断代码是否符合项目现状，改动成本是否可以接受，测试是否真的覆盖了关键风险。代码能不能合进去、测试用例有没有价值，最后还是要人来判断。

所以这条链路不是让 AI 替代人，而是让人从重复整理、补充、检查这些工作里抽出来，精力放在更重要的判断和取舍上。AI 负责把材料准备好，人负责判断这些东西是不是对的、能不能用。

四、这套链路带来的变化

这套链路最大的变化，不是某一步突然快了多少，而是整个过程变得更稳了。

• 需求问题更早暴露

通过 /requirement skill 和 */grillwithdoc skill*，很多边界、权限、异常场景可以在开发前先暴露出来，避免一边写代码一边补需求。

• AI 输出更可控

每一步都有明确输入和输出，不是让 AI 自由发挥。需求、方案、代码、测试、文档都能串起来，结果也更容易检查。

• 返工更少

问题越早发现，修改成本越低。需求和方案阶段能解决的问题，就不要拖到代码写完之后再改。

• 测试更有依据

测试不再是最后临时补，而是基于需求、实现、代码改动和本地走查结果生成，更贴近真实风险。

• 测试用例能进入协作流程

通过 /testcase skill 输出 Excel ，可以导入 Transcend ，或者交给测试评估，不再只是本地文件。

• 文档能同步更新

最后用 /feature-doc-maintainer 把最终实现、权限规则、接口变化、已知限制补回去，方便后续维护，也方便 AI 继续理解上下文。

• 人更专注判断和取舍

人负责确认方向、筛选结果和最终验收。

五、实践中的注意点

1. 需求：先用 Plan 模式，不要直接执行

   需求阶段尽量用 Plan 模式，让 AI 先问问题、拆边界、列 TODO 。

   这个阶段不要急着生成代码，重点是把方向、范围、不做项先确认清楚。

2. 代码：先用 Opus 4.7 计划，再用 Composer 2.5 执行

   复杂需求可以先用 Opus 4.7 做方案和拆解，让它把改动范围、核心逻辑、风险点先列出来。

   确认方向没问题后，再用 Composer 2.5 按计划执行代码修改。

   这样比直接让执行模型上来改代码更稳，也更容易控制改动范围。

1. 测试：先测核心路径，再补边界场景

   不要一开始就追求测试很全。

   先让 AI 覆盖核心流程，确认主路径能跑通，再补权限、异常、空数据、搜索分页、弹窗回显这些边界场景。

   测试用例也要人工筛一下，没价值的不要硬留。

2. 文档：最后再更新，基于最终实现写

   文档不要太早定稿。

   前面需求、代码、测试都会调整，最好在本地走查和 review 之后，再用 /feature-doc-maintainer 更新。

   重点写最终实现、权限规则、接口变化、已知限制，不要写成很重的说明书。

六、总结

回到最开始的问题，为什么要把这套实践融入研发链路？

因为单纯让 AI 写代码，只能解决一小段效率问题。真正拖慢研发的，往往不是代码写得慢，而是需求没说清、边界没想全、测试补得晚、文档跟不上。问题不是没做事，而是每一步都在补前一步的缺口。

这条链路的核心不是自动化，而是可控。每一步都有输入、有输出、有检查点，也都允许人随时介入确认。AI 能力越强，越需要这样的链路来承接它。

最后要做到的不是让 AI 替我们完成研发，而是让 AI 稳定地参与研发。让需求有依据，方案有约束，测试有反馈，文档有沉淀。这样提效才不是一次性的，而是可以持续复用的。

七、本文用到的 Skill

这套链路里主要用到了下面这些 Skill：

如果你也想把这些 Skill 放到自己的项目里，可以参考我整理的 Git 仓库：

Git 地址： https://github.com/535803710/ai-rd-skills

这些 Skill 不是固定答案，更像一套可以继续调整的流程模板。真正落地时，建议根据自己团队的项目结构、测试规范和文档习惯做一轮改造。