AI Coding 系列（一）：把 AI 当作结对程序员——从需求到可验证代码的工作流
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 准备项目上下文——让它真正理解你的代码库，而不是只会生成片段。