Harness Engineering 与 Spec-Driven Development 的区别
Harness engineering 在 AI 编码 agent 语境下是什么,它和 spec-driven development 有什么区别,以及两者怎么一起用。
基础概念相关文章集合,解释 Spec-First 开发、验收标准、技术规格和团队落地流程。
Harness engineering 在 AI 编码 agent 语境下是什么,它和 spec-driven development 有什么区别,以及两者怎么一起用。
AGENTS.md 是写给 coding agent 的 README。难的不是格式,而是边界:哪些规则对每次改动都成立,哪些只属于某一次改动的规格。
从不触发的规则比没有规则更糟,因为团队以为自己被覆盖了。三个 frontmatter 字段决定你写出的是四种类型中的哪一种,而多数团队写出了那个死的。
为运行 AI 编码 agent 的团队设计的五阶段 spec-first 工作流:规格包、任务边界、写入范围、证据门禁和可扩展的 PR 评审。
2026 年 11 月核对版:OpenSpec、Superpowers 和 Spec Kit 各管什么,怎么组合使用,以及该从哪个开始。
大多数 AI 编码工具都在为一个目标做优化:让东西在未来十分钟内跑起来。Spec Skills 优化的是另一件事——确保生成出来的代码,就是你当初真正要的那个东西。
同一个订单退款功能,分别用 vibe coding 和 spec coding 两种方式实现:前者上手快却漏掉边界情况,后者先写清范围、验收标准、测试和上线证据。
网上大多数验收标准示例都太浅,没法直接用到实际项目中。本文给你 20 个生产级的真实示例,覆盖认证、电商、API、数据处理和通知五大领域——全部采用 Given/When/Then 格式,可以直接复制到你的规格文档里。
技术规格文档该包含哪些章节,五个不同类型的完整示例(配置变更、API、数据迁移、UI),以及一份可以直接复制的模板。
迁移文件是永久性的。一旦它在生产环境中运行,你无法撤销它,只能再写一个迁移来修正。然而大多数团队写迁移的方式和写应用代码一样:打开编辑器,开始敲列定义,约束条件边写边想。
为什么 AI 编程工具会加上你根本没要求的校验逻辑,把下游还有消费者的字段随手重命名,还生成一堆超出任务范围的辅助函数?因为你丢给它的是一个"要解决的问题",而不是一份"要遵守的 spec"。
用 spec-driven prompts 治理 AI 辅助编程:提示词必须包含什么、AI 必须遵守哪些边界,以及让“这是 AI 写的”变成可核验声明的审计链。
围绕「为 Agentic 客户端设计 API 规格」展开,说明契约字段、兼容边界、失败路径和评审检查点,帮助团队在上线前减少集成风险,可直接用于规格评审、实现前对齐和测试计划补充。
围绕「AI 辅助开发下的规格质量门禁」展开,说明如何用规格约束 AI 编码、保留人工评审点,并用证据判断实现是否达标,可直接用于规格评审、实现前对齐和测试计划补充。
一个团队如果交付很快但不断返工,并不是在跑得更快——而是在烧跑道。问题几乎总是一样的:没人在编码之前写清楚"完成"是什么意思。Spec-First 开发解决这个问题——在实现之前定义验收标准,而不是之后。