一、先给结论AI Coding 的发展大致经历了这样一条路线代码补全 ↓ 对话式编程 ↓ Copilot 编程 ↓ Agent 编程 ↓ Spec-Driven Development ↓ Harness-Driven Development这条演变背后的核心变化是AI Coding 正在从“帮人写几行代码”发展为“在约束、工具、测试和反馈组成的环境中独立完成软件工程任务”。早期关注的是模型能不能写出一段看起来正确的代码现在更关注的是模型能不能在真实代码库中理解目标、修改多个文件、运行测试、处理错误并最终交付一个可验证的结果二、什么是 AI CodingAI Coding 不只是“让 AI 生成代码”而是 AI 参与软件开发全过程理解需求阅读代码库设计实现方案拆解开发任务编写和修改代码运行测试调试错误重构代码创建文档和提交记录根据反馈继续迭代因此AI Coding 的能力不只取决于模型本身还取决于模型能力 上下文管理 工具调用 任务规划 测试反馈 安全约束 人机协作流程也就是说AI 编程逐渐从单纯的模型问题变成了一个完整的软件工程系统问题。三、第一阶段代码补全——AI 是“高级自动补全”1. 典型形态最早的 AI Coding 主要表现为根据当前代码补全下一行根据注释生成函数根据函数名猜测实现自动生成重复性代码补全类型、参数和 API 调用使用方式通常是defcalculate_total(items):# AI 根据上下文补全这里AI 可能生成returnsum(item.price*item.quantityforiteminitems)2. 这一阶段解决了什么问题它主要提高了打字效率重复代码编写速度常见 API 的使用效率简单函数的实现速度开发者查找模板代码的效率3. 它的局限代码补全有一个重要限制AI 只负责生成局部代码不负责确认整个任务是否完成。它通常不知道业务目标是什么这段代码是否符合产品需求其他模块是否需要同步修改数据库迁移是否需要添加测试是否需要更新这段实现是否破坏已有逻辑因此它更像人类负责思考和决策 AI 负责局部代码生成这个阶段的 AI 仍然是“代码输入法”而不是软件工程师。四、第二阶段对话式编程——AI 开始理解自然语言需求1. 从代码编辑转向自然语言交互随后开发者可以直接告诉 AI帮我写一个读取 CSV 文件并统计每个用户订单金额的 Python 函数。AI 不再只根据光标附近的代码进行补全而是根据一段自然语言描述生成完整代码。这带来了几个变化编程入口从代码变成了自然语言AI 可以一次生成更完整的函数或模块开发者可以要求 AI 解释代码AI 可以帮助定位报错AI 可以根据反馈修改实现2. 人机交互变成循环典型流程是人实现一个登录接口 AI生成第一版代码 人增加验证码校验 AI修改代码 人这个错误怎么解决 AI解释错误并给出修复这形成了一个基本循环描述 → 生成 → 反馈 → 修改3. 仍然存在的问题虽然 AI 可以写出更完整的代码但它依然容易出现忽略隐含需求误解业务规则使用过时 API只修改当前文件忘记更新测试生成无法运行的代码解决一个问题时引入另一个问题原因是自然语言需求通常是不完整、不精确、不可直接验收的。例如做一个用户登录功能。这句话没有说明使用邮箱还是手机号登录密码如何存储错误提示应该是什么是否需要验证码是否限制登录次数是否支持第三方登录登录成功后跳转到哪里是否需要记录登录日志AI 可以生成“一个看起来像登录功能的实现”但不一定是用户真正需要的实现。五、第三阶段Copilot 编程——AI 进入开发环境1. AI 不再只是聊天窗口接下来AI 被集成到 IDE 和代码编辑器中能够读取当前文件读取相关文件根据项目上下文生成代码直接修改代码解释选中的代码生成测试根据错误信息提供建议此时AI 的角色从问答机器人变成代码编辑器中的协作助手2. 上下文成为关键问题AI Coding 的效果开始强烈依赖上下文质量。AI 需要知道项目的目录结构当前使用的框架代码风格数据模型构建命令测试命令项目约定相关模块之间的依赖关系于是出现了各种上下文机制当前文件 打开的文件 相关代码片段 项目说明 Git diff 错误日志3. 新的瓶颈上下文窗口不等于理解能力即使模型可以读取很多代码也不代表它真正理解整个项目。常见问题包括读取了太多无关文件没有找到真正相关的代码混淆多个相似模块遗漏隐藏的架构约定修改范围过大记住了旧版本代码只理解局部无法理解全局影响因此AI Coding 开始需要更加结构化的工作方式而不能只依赖“把代码全部塞进上下文”。六、第四阶段Agent Coding——AI 开始执行完整任务1. AI 从“建议代码”变成“执行任务”Agent Coding 的关键变化是AI 不只是告诉你应该怎么改而是可以自己完成一系列操作。例如用户给这个项目增加 OAuth 登录支持。Agent 可能执行阅读项目目录查找现有认证逻辑查看依赖配置设计改动方案安装必要依赖修改后端代码修改前端页面添加环境变量编写测试运行测试根据报错继续修复汇总改动结果这已经不是简单的代码生成而是一个软件工程执行循环。2. Agent 的基本循环观察 Observe ↓ 思考 Plan ↓ 行动 Act ↓ 验证 Verify ↓ 根据反馈继续迭代用伪代码表示whilenottask_completed:contextinspect_repository()plandecide_next_step(context)resultuse_tool(plan)feedbackrun_tests_or_checks()update_state(feedback)3. Agent 为什么比普通聊天更强因为它具备了几个重要能力工具调用可以调用文件读取工具文件编辑工具终端Git测试框架浏览器数据库API部署系统多轮迭代它可以修改代码 → 运行测试 → 看到错误 → 再修改面向结果传统聊天模型的输出是一段代码Agent 的输出更接近一个经过验证的代码变更4. Agent Coding 的新问题Agent 变强之后问题也从“代码写得对不对”变成了它是否理解了任务它是否修改了不该修改的文件它是否执行了危险命令它是否遗漏了测试它是否在错误方向上反复尝试它是否声称完成但实际上没有验证它是否引入安全漏洞它是否知道什么时候应该询问人类这说明Agent 能力越强越需要明确的任务边界、执行规则和验证机制。七、第五阶段Spec-Driven Development——先明确“做什么”1. 为什么需要 SpecAgent 可以执行任务但自然语言任务往往过于模糊。例如优化一下这个页面。对人类来说这句话可能意味着提高加载速度改善视觉设计优化移动端体验调整交互流程修复无障碍问题提高转化率对 AI 来说存在大量可能的解释。因此开发流程开始强调先编写 Spec需求目标 功能范围 非功能要求 约束条件 验收标准2. Spec 的作用Spec 主要解决四个问题。统一目标让人类、AI、测试人员理解的是同一件事。限定范围明确哪些内容要改哪些内容不要改。提供决策依据当存在多种实现方式时可以根据 Spec 判断哪种更符合要求。支持验收最终可以判断这个任务到底完成了吗3. Spec-Driven 的基本流程用户需求 ↓ Spec明确需求和验收标准 ↓ Plan设计技术实现方案 ↓ Tasks拆解开发任务 ↓ Implement编写代码 ↓ Test运行测试和检查 ↓ Review人工或 AI 审查也可以表示为Spec → Plan → Tasks → Implement → Verify4. Spec 不等于传统文档传统需求文档经常存在这些问题写给人看但不容易执行只有功能描述没有验收标准需求和实现混在一起内容过于宏观更新不及时无法映射到测试AI Coding 中的 Spec 更强调精确可操作可验证与代码库相关能够指导 Agent能够转化为测试5. 一个简单例子模糊需求给系统增加文件上传功能。更完整的 Spec# 文件上传功能 Spec ## 目标 允许用户在个人资料页面上传头像。 ## 功能要求 - 支持 PNG、JPEG 和 WebP 格式 - 单个文件大小不得超过 5MB - 上传成功后显示新的头像 - 用户取消上传时不修改原头像 - 上传失败时显示明确的错误提示 ## 安全要求 - 服务端必须验证文件类型不能只依赖文件扩展名 - 文件名不得直接用于存储路径 - 用户只能修改自己的头像 ## 验收标准 - 合法图片可以成功上传 - 超过 5MB 的文件会被拒绝 - 非图片文件会被拒绝 - 未登录用户不能调用上传接口 - 上传失败不会删除原头像这样的 Spec 就可以直接指导技术方案设计任务拆解测试用例编写Agent 执行最终验收八、从 Spec 继续发展为什么出现 Harness1. Spec 仍然不够Spec 解决了我们希望实现什么但它没有完全解决AI 应该在什么环境中实现它可以使用哪些工具如何获得反馈如何判断它真的完成了如果失败了应该怎样恢复这就引出了Harness。九、什么是 Harness1. 基本含义Harness 原意是“挽具、套具”在软件工程和 AI 系统中通常可以理解为围绕 AI 模型搭建的一套执行、约束、反馈和验证系统。在 AI Coding 中Harness 不是单个提示词也不只是测试工具而是让 AI Agent 能够稳定完成工作的“运行环境”。可以把它理解为Harness AI Agent 的工作台、工具箱、护栏和反馈回路2. Harness 通常包含什么Harness ├── 任务输入 ├── Spec 和项目规则 ├── 代码库上下文 ├── 文件读写工具 ├── 终端和构建工具 ├── 测试与静态检查 ├── Git 和变更管理 ├── 权限控制 ├── 错误反馈 ├── 状态记录 ├── 重试与恢复机制 └── 最终验收标准3. Harness 和 Spec 的区别对比项SpecHarness核心问题要做什么如何让 AI 稳定地完成主要内容需求、规则、验收标准工具、环境、流程、反馈和约束作用对象人类、AI、测试人员AI Agent关注重点目标是否清晰执行是否可靠典型产物Markdown 需求说明Agent 运行框架或工作流判断标准需求是否定义完整Agent 是否能闭环交付可以用一句话概括Spec 定义目的Harness 提供实现目的所需的环境。十、为什么 AI Coding 会从 Spec 走向 Harness原因一任务从局部代码变成了完整交付早期任务是补全一个函数现在任务可能是为一个已有项目增加完整功能并保证不破坏现有系统任务范围变大后单纯依赖模型生成代码已经不够需要获取上下文调用工具执行测试处理错误管理修改范围保存中间状态这些都属于 Harness 的职责。原因二模型会生成代码但不会天然保证结果语言模型的本质是根据上下文生成最可能的输出。它擅长识别模式生成代码解释概念推测实现但它不会天然知道代码是否真的能运行需求是否完全满足是否违反项目规范是否破坏其他功能是否存在安全问题因此必须给它一个外部反馈系统AI 生成代码 ↓ 运行测试 ↓ 返回真实错误 ↓ AI 修复Harness 的核心价值就是把“代码生成”连接到“真实验证”。原因三真实代码库具有复杂状态一个真实项目并不是一组孤立的代码片段而是一个复杂状态系统代码 依赖 配置 数据库 环境变量 测试 构建流程 Git 状态 部署环境AI 如果不了解这些状态就容易做出局部正确、整体错误的修改。Harness 可以帮助 Agent在正确目录中工作使用正确的 Python 或 Node 环境执行项目规定的测试命令读取项目级规则文件控制可以访问的资源保留变更记录在失败后恢复原因四AI Agent 需要“护栏”Agent 能够执行终端命令之后风险会增加。例如它可能删除重要文件修改生产配置暴露密钥执行危险命令大范围重写代码引入不安全依赖所以 Harness 需要提供权限和安全控制哪些文件可以修改 哪些命令可以执行 哪些操作必须人工批准 哪些目录禁止访问 哪些秘密不能进入上下文这类机制通常称为GuardrailsSandboxPermission ControlApproval GatePolicy Enforcement它们都是 Harness 的组成部分。原因五任务失败时需要恢复而不是重新开始真实开发很少一次成功。常见过程是第一次实现失败 ↓ 测试发现问题 ↓ 修改方案 ↓ 第二次实现失败 ↓ 调整依赖或接口 ↓ 最终通过如果没有 HarnessAgent 可能忘记之前做过什么重复修改同一个地方不知道当前 Git 状态覆盖已有改动在错误方向上继续尝试Harness 可以保存当前任务状态已完成步骤测试结果错误日志文件变更上一次决策需要人工处理的问题因此Harness 让 Agent 从“一次性回答”变成“可以持续运行的工程过程”。十一、Harness 的核心闭环而不是工具数量很多人会把 Harness 理解成给 Agent 接上更多工具。但工具多并不一定代表系统强大。真正重要的是能否形成闭环明确目标 ↓ 读取正确上下文 ↓ 采取有限行动 ↓ 获得真实反馈 ↓ 根据反馈调整 ↓ 满足验收标准可以写成Goal → Context → Action → Feedback → Evaluation → Correction如果只有工具没有反馈AI → 修改代码 → 结束这仍然只是自动代码生成。如果有完整 HarnessAI → 修改代码 → 构建 → 测试 → 检查 → 修复 → 再测试 → 交付这才接近真正的 Agentic Coding。十二、从 Prompt 到 Spec再到 HarnessAI Coding 的控制方式也在变化。1. Prompt 驱动帮我实现一个登录接口。特点快灵活上手简单依赖模型临场理解结果不稳定难以复用和验收2. Spec 驱动根据这份 Spec 实现登录功能并满足所有验收标准。特点目标更明确方便拆解任务方便编写测试更适合多人协作更容易复用仍然依赖 Agent 自己完成执行3. Harness 驱动Agent 在规定的代码库、工具、权限、测试和反馈机制中 按照 Spec 执行任务直到满足验收条件。特点不只规定目标还规定执行环境有明确工具有自动反馈有安全边界有失败恢复有最终验证更适合长任务和批量任务三者可以这样理解方式类比Prompt对员工说一句口头要求Spec给员工一份清晰的任务说明书Harness给员工配备工作台、工具、权限、流程和验收系统十三、Harness-Driven Development 的基本流程第一步定义任务目标目标为订单系统增加批量取消订单功能。第二步定义 Spec- 用户可以一次选择多个待支付订单 - 已支付订单不能被批量取消 - 每次最多选择 50 个订单 - 操作完成后显示成功和失败数量 - 操作必须记录审计日志第三步准备 HarnessHarness 需要提供项目目录项目规则数据模型说明可用工具构建命令测试命令数据库测试环境Git 变更检查安全权限第四步Agent 执行读取代码 → 定位订单模块 → 设计修改方案 → 修改后端接口 → 修改前端交互 → 添加测试第五步自动反馈运行单元测试 运行类型检查 运行 lint 运行集成测试 检查 API 文档 检查 Git diff第六步循环修复测试失败 → 将真实错误反馈给 Agent → Agent 修改代码 → 重新运行测试第七步最终验收Spec 条件全部满足 测试通过 代码变更在允许范围内 没有敏感信息泄露 人工审查通过十四、Harness 中最重要的几个组件1. 上下文加载器负责向 Agent 提供正确的信息项目说明目录结构相关源码编码规范历史决策测试方式当前 Git 状态关键不是“加载最多的信息”而是加载对当前任务最有用的信息。2. 工具层典型工具包括read_file search_code write_file patch_file run_tests run_build git_diff database_query browser_test工具应该能够返回真实结果错误信息清晰权限范围明确尽量支持可逆操作3. 验证器验证器负责判断任务是否达到要求单元测试集成测试端到端测试类型检查静态分析格式检查安全扫描Spec 验收检查验证器是 Harness 的“反馈传感器”。4. 状态管理长任务需要记录{task:增加批量取消订单,completed_steps:[定位订单模块,添加后端接口],current_step:编写集成测试,test_status:2 passed, 1 failed,files_changed:[orders/api.py,orders/service.py]}状态管理能够减少重复劳动也方便任务暂停和恢复。5. 权限和沙箱Harness 应该限制文件访问范围命令执行权限网络访问权限环境变量访问数据库操作范围生产环境操作权限对于高风险操作可以设置人工确认普通文件修改自动执行 运行测试自动执行 安装依赖需要确认 删除数据库禁止 部署生产环境人工批准6. 评估器评估器不只检查“测试是否通过”还可以检查是否完成全部需求是否修改了不相关文件是否遵守代码风格是否增加了足够测试是否引入不必要的依赖是否存在安全风险是否符合性能要求十五、AI Coding 的能力评价标准正在变化早期评价 AI Coding常看代码是否语法正确函数是否能运行单个测试是否通过代码生成速度现在更重要的指标是1. 任务完成率复杂任务最终是否真正完成而不是只生成一段代码。2. 一次成功率是否需要大量人工修正。3. 验证可靠性Agent 是否会主动运行测试并根据真实结果修复。4. 变更准确性是否只修改必要文件避免无关重构。5. 长任务稳定性任务运行几十分钟甚至更久时是否会迷失目标。6. 安全性是否能够避免泄露密钥执行危险命令引入漏洞破坏数据越权访问7. 可审计性能否回答改了哪些文件为什么这样改运行了哪些检查哪些测试通过了还有哪些风险这些指标都已经超出了单纯的模型代码生成能力必须依赖 Harness。十六、为什么未来的竞争不只是模型竞争AI Coding 的最终效果可以近似表示为AI Coding 效果 模型能力 × 上下文质量 × 工具质量 × 反馈质量 × 任务定义质量 × 验证质量 × 安全控制质量其中任何一项接近零整体效果都会显著下降。例如模型很强但没有项目上下文仍然会改错代码Spec 很清楚但没有测试仍然不知道是否完成工具有很多但反馈不真实Agent 会在错误方向上运行测试很完整但权限过大可能造成严重副作用Harness 很完善但任务目标模糊Agent 仍然不知道要做什么因此未来 AI Coding 产品的差异化可能越来越体现在更好的代码库理解更可靠的任务规划更强的测试反馈更好的状态管理更细粒度的权限控制更低成本的长任务运行更完整的工程协作流程十七、一个完整的现代 AI Coding 工作流否是用户需求Spec项目上下文PlanTasksAgent 执行代码修改构建与测试是否满足验收标准错误反馈代码审查提交或发布对应到实际开发1. 先写清楚需求 2. 检查项目规则和现有架构 3. 制定技术方案 4. 拆成可执行任务 5. 让 Agent 修改代码 6. 运行真实测试 7. 将错误反馈给 Agent 8. 循环直到通过 9. 检查 diff 和安全性 10. 人工确认后合并十八、Spec 和 Harness 的关系可以用下面这张表总结层次解决的问题示例Prompt现在让 AI 做什么“增加登录功能”Spec具体要做到什么程度“支持邮箱登录错误信息不能泄露账号存在性”Plan准备用什么方式实现“新增认证服务使用 JWT增加接口测试”Tasks需要做哪些具体工作“修改 auth service、增加 middleware、补充测试”Harness如何让 Agent 稳定执行和验证“提供代码库、终端、测试、权限和反馈循环”Evaluation怎么判断结果合格“全部测试通过满足 Specdiff 范围合理”最关键的关系是Spec 定义正确结果 Harness 帮助产生正确结果 Evaluation 判断是否得到正确结果十九、最终理解从 Spec 到 Harness反映了 AI Coding 的一个根本变化AI 生成代码 ↓ AI 理解任务 ↓ AI 执行任务 ↓ AI 根据反馈迭代 ↓ AI 在受控环境中完成可验证交付因此Spec解决“目标不清楚”Plan解决“方案不清楚”Tasks解决“执行步骤不清楚”Harness解决“执行环境、工具、反馈和安全不完整”Tests/Evaluation解决“无法确认是否真正完成”最终AI Coding 的核心不再是让模型写出更多代码。而是让 AI 在明确目标、真实反馈和安全约束下持续完成软件工程任务。这也是为什么 AI Coding 会从Prompt-Driven走向Spec-Driven再走向Harness-Driven从表达意图 到定义规范 再到构建一个能够稳定实现规范的执行系统。