AI 辅助编码工作流

AI 编码工具（从补全到对话式 Agent）已经改变写代码的方式，但把它当"自动写正确代码的机器"会让人失望，把它当"需要校验的快速协作者"才能用好。关键不在于工具多强，而在于你给它什么任务、怎么验证它的产出、以及哪些事坚决不交给它。

它擅长什么，不擅长什么

先用对地方。AI 编码工具的能力分布很不均匀：

擅长	不擅长
写样板代码、CRUD、重复性脚手架	理解大型代码库的隐式约定和历史决策
解释报错、补全 API 用法	精确的边界条件和并发安全
单元测试草稿、类型定义	复杂业务规则的准确性
已有模式的迁移、重构	判断某段代码是否真的该存在

擅长的部分放手给它，能省大量时间；不擅长的部分必须由人把关。最大的误区是"它写得像对的，所以是对的"——AI 生成的代码往往结构合理、命名规范，但会在边界情况、权限检查、错误处理这些细节上出错，而这些恰恰是 bug 的来源。

上下文决定质量

AI 编码工具的输出质量，几乎完全取决于它看到的上下文。给它的信息越精准，结果越靠谱：

差的提问：帮我写个登录功能。
好的提问：这是一个 Vue3 + TS 项目，用 Pinia 管理状态。
需要实现登录：调用 POST /api/auth/login，返回 { token, user }。
登录态存在 localStorage，401 时跳登录页。
已附上现有的 api.ts 和 auth store 结构。

具体怎么做：

• 提供相关文件：把要修改的文件、它依赖的类型和接口、类似已有实现一起给工具，而不是让它猜项目结构。
• 说清约束：用什么框架、遵循什么风格、不能碰哪些部分。不说约束，它会用最常见的默认实现，未必符合你的项目。
• 给例子：让它"照着现有的某个模式写"，比描述模式更准确。

分小步，勤验证

不要一次让 AI 生成一整个大功能。大块生成的代码很难验证——你能看出明显错误，但难以确认每一处细节都对。分小步推进：

1. 先让它搭结构或写接口定义，人审查通过。
2. 再让它填实现，跑测试。
3. 最后处理边界和错误路径。

每一步都验证再往下走，比一次性生成再排错高效得多。AI 生成代码后，立即运行测试或手动验证，不要"看起来对就提交"。一个常见的失败模式是：AI 生成的代码能编译，逻辑却错了，人扫一眼觉得没问题就合进去，直到生产环境才暴露。

代码审查不能省

AI 写的代码和真人写的代码一样需要审查，甚至更严格——因为它不会因为"不确定"而停下来问你：

• 边界条件：空值、并发、超时、重复请求，这些它容易忽略。
• 安全：是否信任了外部输入、是否有注入风险、权限检查是否到位。
• 是否存在：有时候它会"好心"加一个根本不需要的功能或抽象。
• 是否符合项目约定：命名、错误处理风格、目录结构。

审查 AI 代码的一个原则：如果你无法解释这段代码为什么对，就不要保留它。看不懂就要求工具解释，或者自己重写到能理解。看不懂的代码是未来的债。

哪些事要特别谨慎

有些任务，AI 工具能用，但风险显著更高，需要额外的把关：

• 涉及鉴权、支付、数据迁移的代码：一个细节错就是事故，必须人工逐行审。
• 删除或大规模重写：AI 不理解某段"奇怪"代码可能是为了修某个历史 bug，贸然删掉会回归。
• 性能敏感路径：AI 倾向写"清晰"的代码，不一定是"快"的代码。
• 依赖隐式业务规则的部分：这些规则不在代码里，在人的脑子里，AI 看不到。

对这类任务，用 AI 起草或探索方案，但最终决策和验证由人完成。

把交互沉淀成项目约定

用 AI 编码多了，会发现某些反复出现的问题——比如它总用错状态管理方式、总把 API 调用写在组件里。这些可以通过项目级的约定文件解决：把架构规则、风格约束、禁区写进文档，让工具（或新成员）每次都能读到。约束越显式，AI 的产出越贴合项目，反复纠正的次数越少。

务实的工作清单

• 这个任务是否适合交给 AI（样板/测试/解释 vs. 复杂业务规则）？
• 是否提供了足够的相关上下文和约束？
• 是否分小步推进，每步都验证而不是一次性生成？
• 生成的代码我能否逐行解释？边界、安全、错误处理是否到位？
• 高风险改动（鉴权/支付/迁移）是否有额外的人工审查？

AI 编码工具真正放大的，是有判断力的工程师的效率——他们知道该让工具做什么、怎么验证、哪里不能信。对于缺乏判断的场景，它反而可能加速制造难以察觉的问题。把它当协作者，保持你作为最终负责人的审查权，才能拿到它带来的效率红利。