AI Coding 系列(一):把 AI 当作结对程序员——从需求到可验证代码的工作流
AI Coding 的价值,不是把“写代码”变成一句提示词,而是把开发者从重复劳动中释放出来,把注意力放回真正需要判断的地方:问题定义、架构取舍、质量边界与验收标准。
一、先建立正确预期:AI 是结对程序员,不是自动交付机
把 AI 当作一个反应极快、知识面很广、但不了解你业务背景的新同事,会更接近真实体验。它擅长生成候选方案、补全样板代码、解释陌生代码、设计测试用例;但它并不天然知道项目约束,也不能替代你为代码质量负责。
最有效的分工是:
• 人负责:目标、约束、架构决策、验收与最终合并。
• AI 负责:拆解任务、提出实现选项、起草代码、定位线索、补全测试与文档。
• 工具负责:构建、测试、静态检查、格式化与持续集成。
二、一个可复用的 AI Coding 工作流
- 先写“任务合同”,再让 AI 编码
模糊的需求会得到看似合理、却难以落地的代码。开始前,先用五句话说明任务:
目标:为订单服务新增“取消订单”接口。
范围:仅改动 order 模块,不调整数据库表结构。
规则:仅待支付状态可取消;操作需记录审计日志。
接口:DELETE /orders/:id,成功返回 204。
验收:覆盖成功、订单不存在、状态不允许三类测试。
这份“任务合同”既是给 AI 的上下文,也是后续 review 的验收清单。
- 让 AI 先给方案,不要立刻要代码
先要求它说明会改哪些文件、关键状态如何流转、可能影响哪些调用方。重点检查:是否理解了边界、是否引入不必要依赖、是否遗漏异常路径。确认方向后,再让它按文件或按小步骤实现。
- 小步提交,持续验证
一次性生成几百行代码,通常会把错误推迟到最后爆发。更稳妥的节奏是:
第一步,生成一个最小可运行改动;
第二步,运行测试、类型检查和 lint;
第三步,把报错与相关上下文交给 AI 分析;
第四步,人工审查差异后再继续下一步。
AI 可以帮你修错,但测试与检查命令才是事实来源。
三、三个高价值使用场景
读代码:不要只问“这段做什么”。把调用链、数据模型和实际困惑一起给 AI,例如:“这个重试逻辑在什么条件下会重复扣款?请沿调用链分析,并指出需要补测的分支。”这样能更快得到可行动的答案。
写代码:让 AI 生成可审查的候选实现。好的要求会明确语言版本、框架习惯、错误处理策略和性能限制。对关键逻辑,要求它同时给出实现、边界条件、测试用例,以及它最不确定的假设。
测代码:把测试当作 AI 输出的过滤器。让 AI 根据需求生成测试矩阵,再由你决定哪些是必须覆盖的风险。对于涉及金额、权限、并发、删除与迁移的改动,至少要有异常路径和回归测试;不要因为“代码看起来对”就跳过验证。
四、四个常见误区
- 把上下文留在脑子里:AI 不知道的约束,往往会被它用默认假设补齐。
- 一次给过大的任务:任务越大,越需要先拆解接口和验证点。
- 只看代码,不运行验证:编译通过也不代表业务正确。
- 把敏感信息直接粘贴给模型:密钥、用户数据、生产日志应先脱敏,并遵循团队的数据规范。
五、一份可以直接复用的提示词
你是本项目的结对程序员。先不要写代码。
任务:{任务描述}
技术栈:{语言/框架/版本}
约束:{性能、安全、兼容性、目录规范}
现有上下文:{相关接口、数据结构、错误信息}
请按以下格式回答:
- 复述目标与不确定点;
- 给出最小改动方案和涉及文件;
- 列出风险与测试清单;
- 等我确认后,再分步骤输出实现。
结语:让 AI 加速判断,而不是绕过判断
真正成熟的 AI Coding,不是更快地产生代码,而是更快地形成“可验证的正确代码”。当你用清晰任务、分步实现、自动化验证和严格 review 约束 AI,它就会从一个聊天窗口,变成可靠的工程协作者。
下一篇将继续讨论:如何为 AI Coding 准备项目上下文——让它真正理解你的代码库,而不是只会生成片段。