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

⏲️建议阅读时间: 10min
转生到 AI 研发时代，我不再迷信"许愿式编程"，而是把 AI 放进需求、开发、测试和文档这一整条研发链路里。

省流（TL;DR）

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

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

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

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

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

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

二、我的整体链路

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

2. 使用 /requirement skill 梳理需求

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

拷问完成之后就能够得到 《 宝贵的确认好细节的需求文档 》 x1

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

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

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

这一步的价值是让后面的开发有一个明确方向。特别是多人协作或者需求比较复杂的时候，有一份轻量说明，后面写代码、补测试、做 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，或者交给测试评估，不再只是本地文件。

• 文档能同步更新，这点在vibecoding中很重要

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

• 人更专注判断和取舍

人负责确认方向、筛选结果和最终验收。（每天都在不停的做决策，好累😮‍💨）

五、实践中的注意点 ⚠️（小技巧）

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

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

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

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

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

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

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

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

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

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

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

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

   文档不要太早定稿。

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

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

六、总结

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

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

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

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

七、本文用到的 Skill

这套链路里主要用到了下面这些 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 仓库：

Git 地址：github.com/535803710/a...

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