从手写代码到指挥 AI：一套能落地的 AI 辅助开发工作流

写在前面

过去两年，"AI 写代码"从演示视频走进了日常开发。但真正把它用起来的人会发现一个尴尬的事实：能生成代码不等于能交付功能。AI 给出的第一个版本往往看起来很美，跑起来全是坑——接口签名对不上、边界条件缺失、依赖版本冲突。

这篇文章不复述"AI 有多强"，而是把我实际项目中跑通的一套工作流拆开讲：怎么分工、怎么给上下文、怎么验收，以及哪些环节不要交给 AI。全文约 2500 字，含可复用的提示词模板与代码示例。

一、先想清楚：AI 该站在流水线的哪个位置

我踩过的第一个坑，是把 AI 当成"更快的打字员"——把需求丢过去，等它吐出一个完整模块。结果是返工率极高。

后来我把开发流程拆成五段，明确每段 AI 的参与度：

一个经验结论：越是确定性高、边界清晰的任务，AI 收益越大。写一个 CRC32 校验函数，AI 几秒钟给对；设计"订单超时关单"的分布式方案，AI 给的东西必须人工重写。判断标准很简单——这件事能不能用一段话把输入、输出、约束讲清楚。能，交给 AI；不能，先自己把话说清楚。

二、给上下文的三层结构

AI 输出质量的差异，80% 来自上下文质量。我现在固定用三层结构组织提示词：

第一层：角色与边界。明确它在哪个代码库里工作，遵循什么规范。

第二层：输入与约束。精确到不可再降：语言版本、框架版本、已有函数签名、不允许引入的依赖。

第三层：验收标准。这一层最容易被忽略，却最能提升一次通过率——直接告诉它"什么样的输出算合格"，包括要覆盖哪些异常分支、要不要写单测、性能要求。

举个真实例子。我需要给一个前端项目加"分页数据缓存 + 失效"的 hook，最初的提示词只有一句"帮我写一个分页缓存 hook"，产出的东西带了一堆用不上的配置项。改成三层结构后：

【角色】你是资深 React + TypeScript 工程师，维护一个使用 React 18、SWR、
       不引入新依赖的中后台项目。

【任务】实现 usePagedCache<T>(key, fetcher, options)，满足：
1. 同一 key 的相邻页数据共享缓存，TTL 默认 60s，可配置；
2. 提供 invalidate(key) 与 invalidateAll()；
3. 并发请求同一页时只发一次真实请求（去重）；
4. 只使用 React 18 内置能力与项目已有依赖；
5. 不修改现有文件，新增文件放 src/hooks/。

【验收】
- 输出完整 TS 源码 + 3 个 Vitest 用例：命中缓存、TTL 过期后重新请求、
  并发去重各 1 个；
- 不使用 any；
- 代码通过 tsc --noEmit。

一次通过率从"基本不能用"变成"改两行就能合"。差别不在模型，在于我把验收标准写成了可执行的检查项。

三、三个高收益场景

场景 1：把存量代码"读薄"

接手老项目最难的不是写新代码，是理解旧代码。我习惯让 AI 做结构化摘要，而不是直接问"这段代码干什么"：

读 utils/request.ts，输出：
1. 模块职责（一句话）；
2. 对外暴露的 API 列表：名称、入参类型、返回值、副作用；
3. 所有错误分支及其处理方式（表格）；
4. 三处最可疑的实现（说明理由，不要改代码）。

"列出所有错误分支"和"指出可疑实现"这两句，能把一个 800 行的工具文件压缩成半页可读文档。人读这半页只要两分钟，读原文要半小时。

场景 2：测试用例批量补齐

单测是 AI 收益最稳定的地方——因为验证是自动化的，写错了测试会红。我的做法是先让 AI 输出用例清单，人工挑过之后再让它写代码。跳过清单直接写，经常得到一堆"测了但没测到点上"的用例。

场景 3：跨语言、跨栈的胶水代码

Shell 脚本、Nginx 配置、CI 流水线 YAML、正则表达式——这些"一年写三次、每次都要查文档"的东西，是 AI 的理想战场。前提是让它解释每一行在做什么，因为这类配置的错误往往在某个隐蔽的默认值上。

四、必须由人守住的四条线

这部分比前面所有内容都重要。

第一条：安全与合规。代码、日志、配置里可能带密钥、内网地址、真实用户数据。任何情况下不要把生产数据粘进对话。项目里该有 .aiignore 或等价机制，把敏感目录排除掉。

第二条：依赖与许可证。AI 有时会"顺手"引入一个包，或写出一段来源可疑的实现。所有新增依赖必须人工过一遍版本、维护状态和许可证。

第三条：并发的正确性。AI 写的并发代码"看起来对"的比例很高，实际对的比例不高。锁粒度、竞态、幂等性这几处，必须自己逐行读。

第四条：性能敏感路径。排序、循环内的 IO、大数据量渲染——这些地方 AI 的默认实现通常是"能跑"，不是"能扛"。

一句话总结：AI 可以写代码，但不能替你承担后果。提交按钮按下去的那一刻，责任人是人。

五、怎么度量收益

不要用感觉判断，用三个可量化指标：

1. 一次通过率：AI 产出到能编译通过、跑通主流程的比例。低于 50% 说明上下文给得不够。
2. 单位功能耗时：同类需求（比如"加一个列表页 + 筛选 + 分页"）改动前后的实际工时。
3. 返工率：上线后一周内因该功能产生的缺陷数。

我自己的实测：在业务 CRUD、测试补齐、脚本类任务上，端到端耗时下降约 40%–60%；在架构设计、复杂并发、性能调优上，AI 主要作用变成了"帮我列选项"，耗时下降不到 10%。这个分布很稳定，可以用来判断一个任务值不值得交给 AI。

六、结语

AI 辅助开发的本质，不是让人少写代码，而是把人的精力从"语法实现"转移到"问题定义"和"质量把关"。写代码这件事正在贬值，把需求翻译成精确约束、把结果验证到可以上线的能力，正在升值。

所以真正该练的不是提示词的花活，是这两件事：把问题说清楚的能力，和判断输出对不对的能力。前者靠需求拆解的基本功，后者靠扎实的工程素养。这两样，AI 替不了。

如果这篇对你有帮助，欢迎在评论区聊聊你的 AI 工作流——尤其是那些"翻车"的部分，往往比成功经验更有信息量。