来源
- 原始链接：https://www.youtube.com/watch?v=IddXPepIAS4
- 来源类型：视频逐字稿
- 来源标题：在生产工作流中使用规格驱动开发
在生产工作流中使用规格驱动开发高亮
文本来源是 AI Engineer 频道视频《在生产工作流中使用规格驱动开发》的中文可读转写稿。下面按汉松兴趣画像优先保留机制解释、反常识判断和可复用 workflow，而不是做普通摘要。
一、评估、反馈与故障闭环
背景
这组高亮抓住《在生产工作流中使用规格驱动开发》里最值得保留的反馈闭环：Agent 系统的可靠性主要来自可观测、可复现、可评分的外部结构，而不是一次性把 prompt 写得更漂亮。
拉到底部——把鼠标悬停上去，能看到每个 property-based test 的简要说明，比如”对于 genre 过滤的属性测试：对任意电影数据集，提取出的 genre 列表必须包含唯一且排好序的 genre 集合”。它告诉你测试在验证什么。
不过你会发现，就算只给了一个简短的 prompt，加上澄清问答，效果已经相当不错了。当然一定要 review 这些 Markdown 文件，检查前后矛盾、幻觉和错误。
这是非常特别的测试方式，在 TypeScript 的 Node 生态里用的是 fast-check 这个库——每个测试会用不同的随机值运行几十次甚至几百次，来验证需求是否真正得到了满足，非常好用。
兴趣匹配度很高。它对应汉松持续关注的 Agent 工程化主线：把非确定性系统放进可反馈、可回归、可复盘的闭环里，真正的壁垒在 harness、eval、trace 和人类分诊。
二、上下文、记忆与检索边界
背景
这里讨论的是 Agent 能否拿到正确材料的问题。对汉松有价值的点在于，它把上下文从背景信息变成系统的运行材料：可索引、可缓存、可审计，也可被重新组织。
所以你输入 prompt 后，它会先问你几个问题，再生成需求阶段的文档。我们还新增了”快速规划模式”，可以根据你的问答快速生成所有文档，有很多种方式可以玩。
但在我们的 spec-driven development 流程里，两个顺序都可以。文档里会包含 mermaid 图表、ASCII 架构图等各种信息。
在 spec-driven development 的流程里，skills 非常有用——你可以在生成设计文档时使用，也可以和 spec 流程并行使用，或者在实际执行任务时调用。
兴趣匹配度很高。这是上下文工程的核心问题：不是给模型更多字，而是让模型在正确边界内获得正确材料，并让材料本身可维护、可验证、可复用。
三、工具、系统与工程约束
背景
这组摘录偏工程实现。它关心的不是模型能力的抽象上限，而是工具、接口、基础设施和生产约束如何决定 Agent 最终能不能稳定工作。
还可以在 steering docs 或 agents.md 里加规则：在 spec-driven development 流程中，请从这个 MCP server 里抓取信息。这样它就知道去哪里找数据了。
于是我们决定做一个工具，把这个流程系统化。去年底我们发布了 Kiro，一款新的 AI IDE coding assistant，已进入正式可用（GA）阶段。
而且在 spec-driven development 流程里，MCP 有一个特别好的用途：你可以把 Jira 或 Asana 里所有的 ticket、大型需求文档，通过 MCP 拉进 spec 生成流程里，让它在创建规格文档时直接参考产品经理写的需求文档，工作效率大幅提升。
兴趣匹配度高。这里能迁移到实际团队建设：工具选择、数据流、权限、成本、延迟和部署形态，往往比单点模型参数更能决定系统上限。
四、人类判断、组织与协作方式
背景
这部分把人放回系统设计里。Agent 越强，越需要人类承担领域判断、目标选择、风险边界和协作组织，而不是把全部责任交给模型。
你可以看到 Markdown 文件的预览，里面生成了很多 mermaid 图表，展示了系统架构，还有时序图。我和它反复沟通调整，这些都是它帮我生成的。
然后反复确认需求没问题，再让 assistant 生成设计文档，确认之后再让它生成实现细节，也就是任务列表——逐条列出基于需求文档和设计文档需要实现的任务。这整个流程完全可以手动做。
现在的 AI 实习生，也就是这些大语言模型，也有同样的问题，我们需要小心应对。
兴趣匹配度高。它符合汉松的人机共生框架：AI 承担生成和探索，人类承担判断、责任、品味和组织设计，把人的稀缺性放在更高杠杆的位置。
五、Prompt、规格与行为设计
背景
这里的重点是行为设计。Prompt 不是一句魔法咒语，而是一套分层约束、规格、角色、语气和上下文组合出来的系统界面。
给大语言模型提供更多 context（上下文）仍然非常重要，因为这能帮助它走向正确的方向。软件需求在不断变化，技术范式也在不断演进，你始终需要指引它。
我们的目标不只是让你写代码的速度变快，而是让你写出更高质量的代码。我认为 spec-driven development 在这方面很有帮助，接下来我会解释原因和方式。
在 IDE 里选择 spec，然后输入一个 prompt，比如”帮我做一个电影 MCP server 追踪看过的电影”或者”做一个电影网站”，随便你。你可能会想：spec 模式是不是只适合全新项目？
兴趣匹配度很高。它把 prompt 从技巧提升为系统设计问题，适合沉淀到汉松的 AI 协作和 agent workflow 方法论里。
整体判断
这篇内容最值得保留的是它把《在生产工作流中使用规格驱动开发》从一次视频分享转成了可迁移的系统判断。核心素材集中在评估、反馈与故障闭环、上下文、记忆与检索边界、工具、系统与工程约束。对汉松后续写作和团队实践来说，它可以作为 AI Agent 工程化素材库的一块：不是追逐单个工具功能，而是持续追问系统如何获得上下文、如何被评估、如何进入生产闭环，以及人类判断应该放在哪些关键节点。