用规格驱动 AI 编程：把 Agent 从“猜需求”拉回工程流程

一、问题引入：AI Agent 最怕的不是能力不够，而是目标太松

这个视频讨论的是一个很实际的问题：当你让 AI 编程 Agent “加一个认证功能”“做一个分析页面”“接一个搜索能力”时，它通常不是完全做不出来，而是会主动填补大量你没有说清楚的细节。它会选择库、改 API、决定存储方式、甚至顺手补一些你没有要求的功能。单次看似聪明，累计起来就是架构漂移。

Owain Lewis 给出的解法是规格驱动开发。这里的 spec 不是为了写一份漂亮文档，而是一份给 Agent 执行的合同：明确要做什么、为什么做、哪些东西不要做、任务怎么拆、每个任务如何验收。重点不是多写文档，而是让 Agent 在执行前先被约束。

视频的价值在于它没有把 spec-driven development 包装成新理论，而是把它还原成工程团队一直在做的事情：先收敛需求，再做设计，再拆任务，再审查，再提交。区别只是执行对象从人类工程师变成了 Claude Code、Cursor 或其他代码 Agent。

二、核心概念解释：PRD、技术设计和 AI Spec 不是同一个东西

PRD 面向人，AI Spec 面向执行

视频中先把几个容易混用的词拆开。PRD 通常回答“为什么做、为谁做、业务价值是什么”，它是给产品经理、业务方和工程团队对齐范围用的。技术设计文档回答“系统怎么建、架构边界是什么、扩展性和安全性如何处理”，主要服务工程决策。

AI Spec 的定位更窄：它是给 Agent 执行的文档。它可以包含一点 why 和 context，因为 Agent 遇到空白时仍需要判断依据；但它不是让团队辩论方向的地方，而是把已经收敛的意图变成可执行步骤。

Spec 的核心组成

一个有效的 AI Spec 至少包含四块：目标、约束、范围外事项、任务拆解。目标让 Agent 知道最终要交付什么；约束告诉它不能随便新增依赖、不能换掉既有模式、不能用不符合团队标准的方案；范围外事项尤其重要，因为 Agent 很容易“热心过度”；任务拆解则把大目标拆成可以 review、test、commit 的增量。

AI Spec 的关键不是让 Agent 更自由，而是减少它需要猜的地方。

三、关键论点与实操步骤：从一句模糊需求到可审查任务

1. 不要直接说“加认证”，先写可执行规格

视频用认证功能举例。模糊 prompt 可能只是“给应用加认证”，但真正实现时有大量隐藏决策：是 JWT 还是 session？是否支持密码重置？是否接 OAuth？access token 和 refresh token 的有效期是多少？用户数据存在哪里？是否允许新增依赖？如果这些都留给 Agent，它会根据训练经验拼出一个方案，而不一定符合项目实际。

规格化后的版本会明确：使用 JWT；access token 为 1 小时，refresh token 为 7 天；不做密码重置和 OAuth；用户数据走 Postgres + Prisma；不要新增依赖；token 不入库；每个接口需要怎样的错误处理和测试。这种写法把“想象空间”变成“执行边界”。

2. 把大功能拆成可以单独验收的任务

规格不是一次性扔给 Agent 让它生成 10,000 行代码。视频反复强调要把工作拆开：先加 user model，再做注册接口，再做登录接口，再做刷新 token，再补端到端测试。每个任务都要有 touched files、实现要求和 verification。任务完成后先 review，再 commit，然后才进入下一步。

这个节奏的实际收益很直接：每一步的 diff 小，review 成本低，错误更早暴露。如果任务 1 的数据模型就错了，你可以立刻修 spec，而不是等整个功能生成完之后在一堆跨文件变更里反推问题来源。

3. Spec 不是瀑布文档，可以边做边修

Lewis 特别提醒，规格不是锁死一切的瀑布设计。你可以先写到足够清晰，让 Agent 开始做第一步；review 后发现问题，再回到 spec 修改约束或任务。关键是把修改写回持久文件，让下一次 Agent session 仍能继承最新事实，而不是依赖聊天上下文。

4. 真实演示：先让 Agent 生成 spec，再人工改掉不可靠选择

演示项目叫 YouTube IQ，作者想新增一个“粘贴 YouTube URL 后分析视频”的功能：拉取字幕，分析开头、节奏、关键点，并给出改进建议。他先用一个 slash command 让 Agent 生成 spec，Agent 把功能拆成转写服务、分析 prompt、后端路由、UI 组件和侧栏入口等任务。

随后作者审阅 spec，发现 Agent 选择了 YouTube transcript package，但他过去遇到过限流和可靠性问题，于是把约束改成使用 SuperData API 拉字幕。这就是 spec-driven workflow 的重点：Agent 可以先给出草案，但人类工程师必须在执行前把关键决策收回来。

5. 执行时只让 Agent 做 T1，并要求验证

作者打开新的 Claude Code session，让 Agent 读取 spec 并只实现 T1。完成后 Agent 按要求跑了 build 或测试，作者再 review 生成代码。他注意到视频 ID 提取逻辑看起来可疑，说明即使通过验证，也还要用工程视角检查边界条件。随后他让 Claude 实际调用新服务，确认能从 YouTube URL 提取 ID、拉到 18 个 transcript segment，并转成 AI 可处理的纯文本。

四、对比表格：不同工作流该怎么选

五、视频中的核心判断

规格驱动并不是发明一种全新的工程方法；它只是把软件团队原本的需求、设计、拆任务和 review 流程，重新套到 AI Agent 身上。

这句话可以作为整集视频的中心。很多人讨论 AI 编程时，把 Agent 当成一个可以一次性接住所有上下文的超人工程师；作者的实际建议相反：把 Agent 当作一个执行力很强、但需要明确任务边界的工程成员。你不给边界，它就会热心补全；你给了边界，它才更像团队流程中的一环。

六、时间戳目录

七、相关推荐

如果你想把这套方法接到实际工具里，可以继续看这些课程：Claude Code 的计划模式、CLAUDE.md 项目记忆、MCP 工具接入，以及多 Agent 并行开发，都需要类似的规格约束才能稳定工作。