前端小蜗

# 从需求到测试：AI 参与研发链路的实践总结

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

# 省流（TL;DR）

  • 核心问题： AI 编码能力最然很强，但是需求、边界、测试、文档没准备好就让它开写，代码 “看起来能用、后面难改”。

  • 做法：用一串 Skill 把 AI 放进完整研发链路 —— 先收集上下文，再梳理需求、拷问边界、出轻量方案，然后 TDD 实现、补测试、做 review、本地走查、导出用例、更新文档。

  • 流程特点：10 步有顺序，但可在需求、方案、审查、走查、文档等环节回退修正，越早改成本越低。

  • 人的角色：AI 负责整理和生成，取舍、验收、能不能合仍要人判断；目标是可控、可复用。

⏲️建议阅读时间: 10min

转生到 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-analysis skill 梳理需求

上下文准备好之后，先别急着开发。 先用 /requirement-analysis 把需求完整过一遍。

这一步主要是把零散信息整理成结构化内容，比如：

  • 功能背景是什么

  • 给谁使用

  • 核心流程怎么走

  • 涉及哪些字段、状态

有些地方如果还没确认，或者自己也没想清楚，不要硬猜。 直接用 TODO 标出来，后面再找人确认。

这一步做完后，基本就能得到一个可执行的需求文档，整体方向也会清晰很多。 后面再配合 /grillwithdoc 去补细节、抠边界。

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

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

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

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

这一步主要是专门找漏洞，比如：

  • 边界到底在哪

  • 哪些场景不做

  • 权限和数据范围会不会受影响

很多问题在正常阅读里其实看不出来。

但换个角度不断追问，就很容易暴露出来。

这个 Skill 很强，基本能把所有边界和细节明确的的很清楚。 拷问完成之后就能够得到一份宝贵的确认好细节的需求文档了

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

这时候没必要先写一大份技术方案。文档太重，很多人懒得看，后面也容易没人维护。

通常整理一份轻量实现说明就够了，把关键内容写清楚：

  • 准备怎么实现

  • 会改哪些模块

  • 数据流怎么走

  • 有没有新增字段、状态、接口

  • 哪些地方风险比较高

这样后面的开发会顺很多。

尤其是多人协作、需求比较复杂的时候，有个统一方向，后面写代码、补测试、做 Review 都会轻松不少。

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

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

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

这里我一般会先用 /TDD 处理核心逻辑。

因为一旦测试先确定下来，后面的代码就会围绕这些预期行为去实现，AI 乱发挥的情况会少很多，逻辑也更容易收敛。

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

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

/TDD 做完之后，测试其实还没结束。

它更偏向核心逻辑验证，很多真实场景依然可能漏掉。比如页面交互、组件行为、异常流程、权限显隐，这些通常还需要后面再补。

所以代码完成后，我还会再用 /testing 过一轮。

而且补测试的时候，最好结合最终代码一起看。

只盯着需求文档生成测试，很容易出现“测试写了不少，但关键路径没测到”的情况。

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

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

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

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

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

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

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

Review 做完之后，一定要自己本地跑一遍。

特别是前端功能，光看代码和测试远远不够。页面能不能正常打开、搜索分页有没有问题、新增编辑删除是否正常、弹窗回显对不对、错误提示合不合理、权限按钮显示是否正确，这些都得自己实际点一遍。

这一步纯体力活，就是人工验收。

AI 可以帮你写代码、补测试、做 review，但真正使用功能这件事，最后还是得靠人。

如果本地走查发现问题，就直接回前面的步骤修。

流程走到第八步也没意义，问题留到后面，只会更难收拾。

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

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

这里我一般会用 /testcase 直接生成测试用例 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. 测试：先测核心路径，再补边界场景 多用 /diagnose skill

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

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

    前面需求、代码、测试都会调整，最好在本地走查和 review 之后，用文档 skill 更新。

# 六、总结

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

因为单纯让 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 地址：https://github.com/535803710/ai-rd-skills

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