AI 编程搭档：从代码补全到结对开发

AI 编程工具已经足够多，但团队之间的效率差距反而在拉大。原因不是工具本身，而是使用方式：有人把它当高级自动补全，有人把它当成一个需要管理的协作者。

一、三个层次：补全、对话、代理

层次	典型用法	主要风险
补全	根据光标上下文生成下一行	局部正确，整体不一致
对话	解释代码、写测试、排查报错	上下文不足导致瞎猜
代理	自主读文件、改代码、跑测试	改动范围失控，审查成本高

层次越高，节省的输入越多，但对任务描述和验收能力的要求也越高。没有审查纪律的代理式编程，只是把 bug 的生产速度提高了。

二、上下文比提示词更值钱

AI 写不好代码，通常不是「提示词不够聪明」，而是它不知道：项目用什么框架、错误处理有什么约定、相关代码在哪里、你已经试过什么。

一次高质量的请求，至少应包含四类信息：

• 位置：涉及哪些文件、模块、函数。
• 约束：不能改哪些接口、不能引入哪些依赖。
• 证据：完整的错误日志、复现步骤、相关测试。
• 验收：什么条件下算完成，需要哪些测试通过。

三、任务拆分：小步提交，小步验证

让 AI 一次完成「重构支付模块」几乎必然失控。更可靠的方式是拆成可独立验证的小步：先加测试，再改数据结构，再迁移调用方，最后删除旧代码。每一步都跑测试、看 diff、提交。

拆分的原则是：任何一步出错，都能在十分钟内定位并回滚。这和人做大型重构的原则没有区别。

四、让 AI 做它擅长的事

AI 表现稳定的任务，通常有清晰的输入输出和大量公开样例：

• 样板代码、CRUD、数据转换、正则表达式。
• 补测试、补类型标注、补文档注释。
• 解释陌生代码、翻译语言、迁移 API。
• 分析日志、归纳报错、给出排查方向。

它不擅长的是：模糊的产品需求、跨系统的隐性约定、需要权衡的架构决策，以及「只有老员工才知道」的历史包袱。这些部分仍然需要人来主导。

五、代码审查不能省

AI 生成的代码有一个特点：看起来非常合理。变量命名规范、注释完整、结构工整，但可能漏掉了权限校验，或者把异常吞掉了。越是像模像样，越容易在 review 时被放过。

审查时重点看四件事：边界条件、错误处理、安全风险、测试是否真的断言了行为。不要只看它「跑起来了」。

六、一个可复用的工作流

下面这段请求模板，适合大多数「给现有项目加功能」的场景：

背景：这是一个 FastAPI 服务，订单接口在 app/api/orders.py，
数据访问统一走 app/repositories/order_repository.py。

目标：给 GET /orders 增加按状态过滤和游标分页。

约束：
- 不改动现有响应字段
- 复用 OrderRepository，不新增第三方依赖
- 保持现有错误码风格
- 补充 pytest 用例，覆盖空结果和非法游标

要求：先给出改动计划和你需要确认的问题，不要直接写代码。

先看计划，确认理解一致，再让它逐步实现。实现完成后，先跑测试，再读 diff，最后才提交。这个流程看起来慢，但它避免了「生成两百行、推翻重来」的循环，整体反而更快。

AI 编程的收益，不来自少敲了多少字符，而来自把机械工作压缩，把判断力留给人类。守住这条边界，工具才会真正站在你这边。