AI 编程方式：辅助、原型、Agent 与规格驱动

AI Coding 是用模型参与理解、设计、编码、测试和评审的统称。它并不天然等于 Vibe Coding，也不天然等于让 Agent 自主执行。区分方式时，应看三个问题：需求是否确定，工具行动由谁推进，完成结果靠什么验证。

对订单导出，工程师让模型补一个字段转换函数，是 AI 辅助；用自然语言生成页面并靠试用调整，是 Vibe 探索；委托 Agent 读取仓库、修改功能、执行检查，是 Agentic 开发；先明确角色权限和任务状态，再据规格实现，是规格驱动。规格驱动也可以完全由人实现，Agent 也可以执行没有完整规格文档的小任务。

四种方式怎样运行

方式	典型反馈循环	人的主要工作	合适场景与边界
AI 辅助开发	选定局部问题 → 生成建议 → 人修改 → 验证	保持代码理解，决定集成和测试	解释代码、局部补全、小重构；复杂跨模块任务需补上下文
Vibe Coding	描述意图 → 生成原型 → 运行观察 → 调整	判断方向和使用体验，约束数据与环境	低风险探索；页面可用不能证明权限和恢复正确
Agentic 开发	任务契约 → 读仓库 → 工具执行 → 检查修复 → 评审	定义目标、权限和验收，审查证据	明确功能、已复现缺陷、机械迁移；自治程度取决于可验证性
Spec-Driven	澄清行为 → 评审规格 → 方案和任务 → 实现 → 对照验收	决定业务规则和高成本取舍	跨模块、公共接口、数据和安全边界；局部小改动可用轻量契约

严格意义上的 Vibe Coding 强调通过意图和运行效果推进，使用者可能不逐行理解代码。专业工程师使用 AI 并审查、测试代码，不应仅因为“输入自然语言”就被归为 Vibe。这里的原型实践保留快速反馈，同时明确它进入生产前还缺哪些责任。

图中的选择是当前任务的下一步，不是项目永久归类。低风险且方向模糊，可以先做原型；高风险且规则模糊，先澄清和做受控试验；目标明确但缺少验证入口，先建立复现、测试或基准。只有结果能够判断，才适合增加委托范围。

AI 辅助：让局部修改保持可解释

例如 CSV 中金额以分保存，展示时要转换为元。提供现有转换函数、精度规则和样本，让模型提出修改，再由工程师检查舍入、负值和空值。不能只接受一个“看起来更简洁”的实现，尤其不能让浮点格式化改变对账金额。

适合辅助的任务通常能明确输入和输出。遇到仓库事实不清楚时，先让模型解释调用链、定位已有实现，确认后再改。代码解释属于待核对假设，文件和实际运行才是证据。

Vibe：先得到方向反馈

原型可以用合成订单数据，先展示字段、筛选和下载状态。运营反馈“文件需要按支付时间命名”，就把它转为下一轮行为；反馈“仍然需要手工整理”，则重新判断功能目标。原型结束的标准是学习足够支撑决策，不是代码已经很多。

不确定方向时，也可采用手工草图或低代码原型，Vibe 不是必经阶段。方向已清晰的小修复，可以直接进入实现。订单导出的具体原型和反馈方式见 原型快速验证。

Agentic：将行动放进证据闭环

Agent 的价值在于把读取、编辑、运行和修复连接起来。它需要知道真实入口、允许范围和检查方法，而不只是收到“实现异步导出”一句话。人负责业务决策，Agent 在授权范围内执行，工具提供运行反馈，评审者检查差异与证据。

先读取订单入口、权限、查询、任务状态和已有测试，运行基线检查。若基线已有失败，记录原始现象；若无法复现环境，先说明缺口，不应把后续失败一概归因于新代码。实现中使用小步差异，检查失败就回到定位和修复。

以下是任务契约示例，其中路径和命令应替换为仓库实际入口：

目标：授权财务用户可创建所属租户的异步 CSV 导出任务。
范围：订单导出入口、现有任务模块、相关测试。
非目标：不新增退款导出，不迁移数据库，不发布生产。
行为：无权限返回 403；其他租户无法查询或下载任务文件。
约束：字段采用白名单；复用已有队列；资源上限从配置读取。
验证：先运行基线；覆盖权限、隔离、任务失败和下载过期场景。
交付：说明差异、验证结果、未覆盖项和需要人工决定的事项。

契约不需要规定每个局部方法名，但必须规定会影响业务、安全和公共接口的行为。发现必须改数据库或跨服务协议时，先调整任务与方案，不能让局部实现静默扩大范围。

规格驱动：使高成本分歧在实现前可见

“支持重试”需要具体含义：允许重试哪些失败，是否沿用任务标识，重复点击是否产生重复任务，已过期文件能否重新生成。规格把这些问题变成状态和行为，测试再把它们变成检查。文档有标题却没有规则，并不构成有效规格。

一个可评审规则可以写成：“只有当前用户所属租户内的失败任务可被重试；重复重试请求必须遵守既定幂等规则；重试仍使用当前字段白名单。”若业务决定重试沿用原始字段快照，规格、数据结构和测试必须一起改变。哪个方案正确由业务与技术约束决定，不能让模型猜测。

规格、实现和测试保持版本对应。实现发现新约束时，区分代码偏离规格、规格遗漏事实、需求主动变化，再分别修正。详细机制见 Spec-Driven；复杂需求的拆分与实践见 项目实战。

上下文、工具和 Harness 补什么

提示词表达当前任务，上下文工程 提供仓库事实和约束，工具与 Agent 工程 连接行动，Harness 工程 用环境、测试和策略约束执行。它们是协作能力，不是必须依次升级的产品等级。

没有仓库上下文，Agent 容易重复已有模块；没有测试入口，错误只会在聊天里反复解释；没有权限边界，普通实现任务可能触发未授权外部操作。增加提示词长度不能独自解决这些问题。

评审结果，而非相信自述

Agent 声称“所有测试通过”时，应能对应实际命令、环境和结果。模型生成的测试可能跟着错误实现一起改变，评审要检查预期是否来自业务规则，是否覆盖真实调用路径。换一个模型评审可以提供额外意见，不能替代独立验收。

并行 Agent 适合接口明确、文件范围可分离、结果能独立检查的任务。若权限模型未确认就分头写接口、前端和任务处理，集成时仍会冲突。先确定合同，隔离工作区，统一集成检查，再考虑并行。

最终完成定义应是：满足约定行为，相关检查通过，差异可解释，未覆盖边界已说明。代码量、工具调用次数和 Agent 运行时长都不是完成依据。

→ 工程验证 · 方法组合实践 · AI 编程工程化专题