AI 编程：从补全代码到协作式开发的工程方法论

AI 编程助手最擅长的不是替你设计整个系统，而是缩短“想法—实现—验证”的循环。本文讲清三种模式的边界、上下文该怎么喂、以及 Spec 驱动的安全工作流。

三种模式，能力边界各不同

把 AI 编程粗分三类，能避免“拿锤子找钉子”：补全模式（Copilot 类行内补全）最擅长局部、低决策密度的重复劳动——样板、正则、测试用例骨架，延迟低、上下文小；但它看不到全局，跨文件重构基本无能为力。聊天模式（Chat）擅长解释陌生代码、写单文件函数、根据报错给修复建议，决策密度中等，但缺乏“执行权”，改完要你手动落地。Agent 模式（Claude Code、Cursor Agent、WorkBuddy 类）能读目录、跑命令、改多文件、运行测试并自我修正，决策密度最高，代价是容易“自作主张”——改了你没让它改的文件、顺手加了依赖。

上下文工程：喂什么，比模型多大更关键

Agent 的产出质量，很大程度取决于你喂给它的上下文是否“刚好够”。太多会稀释注意力、撑爆窗口；太少它会瞎猜。经验法则：明确给出相关的接口契约 / 类型定义 / 现有调用点，比泛泛说“在 UserService 里加个方法”强十倍。历史对话要裁剪——只保留与本任务相关的决策与报错，别把整段闲聊塞进去。善用 @file、@symbol 这类引用把“精确片段”而非“整个大文件”喂进去。

一个反模式是“把整个 repo 丢给模型”。正确的上下文分层是：系统级（架构约定/编码规范）→ 任务级（本次改动涉及的文件与接口）→ 执行级（运行结果、测试报错）。层级清晰，模型才不容易跑偏。

Spec 驱动开发：先写规格，再写代码

Spec-driven 的核心是把“要做什么”先用自然语言（甚至伪代码）写清楚，让模型围绕一份明确契约工作，而不是边做边猜。典型流程：写一份 spec.md 描述目标、接口、边界条件、验收标准 → 让模型据此产出实现计划 → 你确认计划 → 模型分步实现并提交。这样每次改动都有据可查，回归也有基准。

# spec.md 片段示例
## 目标
为 POST /orders 增加“库存不足时自动排队”的能力。

## 接口约束
- 请求体新增字段 `queueWhenOutOfStock: boolean`
- 返回 202 且 `orderId`，不阻塞主流程
- 并发下单需幂等（同 requestId 重复提交返回首次结果）

## 验收标准
- 单测覆盖：库存充足 / 不足排队 / 重复提交
- 集成测试：模拟库存服务超时，断言订单进入队列而非失败
- 不修改既有 GET /orders 的响应结构

工作流：一张图看清协作节奏

测试生成与代码评审的实战

模型最被低估的能力是测试生成。给定函数签名和边界条件，它能快速产出单元测试用例骨架，你只需补断言和 fixture。但警惕它“为覆盖率而写测试”——只断言 not null、不验证业务结果，这种测试是假的。评审侧，让模型扮演 reviewer：检查异常是否被吞掉、权限校验是否缺失、是否有 N+1 查询、是否引入了不必要的依赖。把这类清单固化成 prompt，比一次性提问稳定得多。

主流工具差异与配置要点

工具选择取决于“你想要多少自动化，以及愿意交出多少控制权”：Cursor 强调编辑器内多文件 Agent 与索引体验，适合在 IDE 里全程协作；Claude Code 偏终端/CLI，擅长把仓库当整体、自主跑命令与测试，适合后端与脚本任务；WorkBuddy 类把 Agent 嵌进更完整的工作流（任务管理、多工具编排），适合团队级自动化。配置上的共性要点：限定可访问的文件/命令白名单、开启确认模式（危险操作需人工批准）、把编码规范与测试命令写进项目级配置，让每次会话都自带上下文。

安全：别让便利变成事故

三个真实风险。秘钥泄露：Agent 读仓库时可能把 .env 内容贴进日志或回复，务必在上下文里排除密钥文件、用 git-secrets 扫描。许可证风险：模型可能“记忆式”吐出某 GPL 代码片段，商用需许可证合规检查（如 FOSSA / ScanCode）。能力评测：别只看 demo，用 SWE-bench 这类真实 GitHub issue→PR 基准衡量模型解决真实工程问题的能力，它比“让它写一个快排”更接近生产难度。

AI 编程不是把键盘交给模型，而是把更多时间还给设计、判断和验证。选对模式、喂对上下文、用 Spec 框住范围、拿测试与评审兑现价值——你交付的不是更多代码，而是更可信的代码。