你可能也遇到过这种时刻：把一个复杂需求丢给 AI，它很快写了几百行代码，页面也跑起来了，看上去效率很高。但仔细一看，边界条件漏了，业务规则靠猜，异常状态没处理，甚至还顺手重构了不该动的代码。

这不是 AI 不够努力。很多时候，是我们给 AI 的任务本身就不够清楚。

过去一段时间，我在工作里越来越多地使用 AI 辅助研发。小需求直接让 AI 写，确实很快；但复杂需求如果也这么做，就很容易变成“写得快，返工也快”。后来我逐渐形成了一套更稳定的流程：

Plaintext 先用 Spec 管方向， 再用 Goal 管执行， 最后用验证闭环管交付。

图 1：需求输入→Grill-Me 需求拷问→输出需求文档、方案设计、任务拆解→Goal 自动化执行→验证闭环交付

这篇文章，就是对这套实践的整理。

下面为了表达方便，我用 Spec 泛指这套规格驱动流程；具体到文档时，用 Requirements、Design、Tasks 来讲。

AI 不怕任务多，怕目标不清

现在的顶级模型已经很强了。它们能读代码、改代码、写测试、解释报错，也能跨多个文件完成一次复杂修改。业内普遍存在一种观点：只要需求描述足够详尽，不同大模型的产出差距微乎其微。但结合我的一线落地实践，实际情况并非如此。

模型能力当然重要。复杂任务要优先使用顶级模型。跨文件修改、复杂需求理解、页面问题定位、测试失败修复，这些都高度依赖模型能力。强模型能把事情做出来，但方向对不对，还是取决于需求讲没讲清楚。

如果需求本身模糊，AI 会放大模糊点：

• 边界不清时，它会自行补业务规则。

• 验收标准不清时，它会做出“看起来完成了”的结果。

• 技术约束不清时，它可能写出不符合项目风格的实现。

• 不做什么没有讲清楚时，它容易顺手扩展，甚至做无关重构。

所以现在遇到大一点的需求，我不急着让 AI 写代码，而是先让它把需求整理成 Requirements，再沿着 Spec 工作流继续往下走。

第一步：先澄清需求，生成 Requirements

这里的 Spec，更准确地说，是一套围绕 specification 展开的工作流。不同工具的文件名不完全一样。比如 Kiro 里通常是 requirements.md、design.md、tasks.md；GitHub Spec Kit 里更常见的是 spec.md、plan.md、tasks.md。名字不同，但核心分工类似：先定需求，再定设计，最后拆任务。

所以第一步里的重点，不是让 AI 直接写技术方案或任务清单，而是先把几个问题讲清楚：

• 为什么要做？

• 谁会用？

• 用户在什么场景下用？

• 预期行为是什么？

• 哪些事情明确不做？

• 什么样才算完成？

在整理 Requirements 前，我现在会先做一轮需求拷问。这里我会用一个叫 grill-me 的需求拷问 Skill，让 AI 扮演一个很较真的产品经理或架构 reviewer，一次只问一个关键问题，持续追问，直到需求里的关键决策都暴露出来。

它的重点不是让 AI 替人做决定，而是逼自己在动手前把决定做清楚。

比如有一个需求：

我要做一个智能相册。它和传统相册不同，不只是按时间、地点、相册名找照片。

用户可以用接近自然记忆的方式搜索照片。

比如“去年夏天在海边的蓝色调照片”“孩子生日时很开心的照片”“适合做封面的横屏风景照”。

这段话本身还不能直接进入开发。grill-me 会继续追问：这是演示原型，还是可上线功能？搜索失败和照片尚未分析完成是否要区分？云端分析的成本、隐私和权限边界怎么控制？这些问题确认后，AI 才能把它整理成更稳定的需求规格。

需求规格也就是 Kiro 里的 requirements.md 或 GitHub Spec Kit 里的 spec.md，通常会包含：背景与目标、用户故事、预期行为、明确不做什么、验收标准、待澄清问题。这里面我最关注的是用户故事。

用户故事不是简单列功能点，而是回答：

谁，在什么场景下，为了什么目标，需要这个能力。

比如智能相册，真正的用户场景不是“做一个搜索框”，而是：用户照片很多，但经常不记得日期、相册名、文件位置，只记得一些模糊线索。用户想通过“海边、蓝色调、安静”“孩子生日、开心”“适合做封面”这样的描述找照片。

这个“为什么”写清楚以后，AI 后面做方案和开发时，方向会稳很多。

一个整理后的 requirements.md 片段，大概会长这样：

背景与目标：

用户照片数量很多，但经常不记得准确日期、地点或相册名。智能相册希望让用户用更接近自然记忆的方式找照片，例如氛围、天气、颜色、人物状态、使用场景等。

用户故事：

作为一名经常拍照但很少整理相册的手机用户，当我只记得“海边、蓝色调、安静”这类模糊线索时，我希望能通过自然语言搜索找到相关照片，以便快速分享、回忆或制作内容。

预期行为：

用户可以输入自然语言描述，系统返回匹配照片，并展示主要匹配原因，例如颜色、场景、天气、人物表情或画面用途。

明确不做什么：

第一期不做专业修图，不做跨账号共享相册，不做完整云盘能力，也不承诺识别所有抽象情绪。

验收标准：

• R1：当用户搜索“蓝色调 海边 安静”时，系统能够返回与海边、蓝色画面、安静氛围相关的照片。

• R2：搜索结果需要展示主要匹配原因，例如颜色、场景、天气、人物表情或画面用途。

• R3：照片需要有分析状态，至少区分 analyzing、ready、failed。

• R4：当没有结果时，页面需要区分“没有匹配照片”和“照片尚未完成分析”。

• R5：分析失败或搜索失败时，需要展示失败状态，并提供重试入口。

但 requirements.md 也有边界。它主要解决需求语义问题：为什么做、做什么、不做什么、怎么验收。它不等于原型图，不等于交互设计稿，也不等于视觉设计稿。

如果一个需求强依赖界面体验，只给 requirements.md 是不够的。按钮放哪里、筛选怎么展开、无结果状态怎么提示、错误状态怎么恢复，这些需要原型、交互说明，或者至少让 AI 先输出页面交互方案再 review。

贯穿动作：多轮 Review

requirements.md 生成以后，我先不进入开发，而是继续让 AI 做第一轮 review。这里 review 的对象首先是 Requirements，但 review 不是一个固定步骤，也不是只发生在需求阶段。后面的 Design、Tasks、Goal 执行结果和页面验证结果，都可能需要根据风险继续 review。

第一轮 Review 的重点不是挑错别字，而是看：

• 用户故事是否清楚？

• 边界是否清楚？

• 明确不做什么是否写清楚？

• 是否存在隐藏假设？

• 是否有未确认的接口、字段、状态？

• 验收标准是否真的可验证？

• 如果上线，会不会有权限、隐私、成本、兼容性风险？

还是智能相册这个例子。grill-me 已经把“演示原型还是可上线功能”这条分界问出来了，但被问出来不等于已经收敛。当前 Requirements 看起来已经比较完整：支持自然语言搜索、展示匹配原因、处理无结果和失败状态。

如果最后确认是可上线功能，就必须继续确认：

• 是云端分析，还是本地分析？

• 不同手机系统的相册权限差异怎么处理？

• 搜索无结果时，怎么区分是真的没有，还是还没分析完？

• 云端分析成本和额度怎么控制？

• 敏感内容是否参与分析和搜索？

• 第一阶段成功指标是什么？

这时就能看出来：Requirements 写得完整，不代表需求已经足够清楚。很多关键问题，不是 AI 不知道，而是你没有逼它问出来。

第二步：从 Requirements 到 Design 和 Tasks

Requirements 确认以后，才进入 Design 和 Tasks。我一般把这三个文档的分工理解成：

Plaintext requirements.md  定需求 design.md        定设计 tasks.md         定执行

Requirements 关注 What 和 Why：为什么做、做什么、不做什么、怎么验收。Design 关注 How：怎么做，涉及哪些模块，数据模型怎么设计，接口怎么变，页面状态怎么组织，有哪些风险。Tasks 关注 Step by Step：先做什么，后做什么，每一步改哪些地方，每一步怎么验证。

还是智能相册这个例子。Requirements 确认以后，Design 不能只写“用云端分析”这种一句话方案，它要把系统怎么工作讲清楚。一个 design.md 片段可能会长这样：

系统架构：

智能相册第一期采用云端分析。客户端负责相册授权、照片选择、搜索界面和结果展示；后端负责分析任务调度、模型调用、分析结果存储和搜索匹配。

组件设计：

• PhotoPermission：处理 iOS、Android、鸿蒙等系统的相册授权差异。

• PhotoAnalysisJob：管理照片上传、模型分析、失败重试和状态更新。

• PhotoAnalysis：保存场景、颜色、天气、人物状态、事件、用途、分析状态和失败原因。

• SearchService：解析自然语言查询，结合 PhotoAnalysis 标签返回匹配照片和匹配原因。

• SearchPage：展示搜索框、示例词、照片网格、loading / empty / error 状态和照片详情。

数据流：

用户授权相册 → 选择照片进入分析队列 → 云端模型生成 PhotoAnalysis → 用户输入搜索词 → SearchService 匹配分析结果 → 页面展示照片和匹配原因。

错误处理：

• 授权失败：展示权限说明和重新授权入口。

• 分析中：搜索结果需要提示“部分照片仍在分析中”。

• 分析失败：记录失败原因，允许用户重试。

• 搜索无结果：区分“没有匹配照片”和“照片尚未完成分析”。

测试策略：

• 使用固定测试图库验证海边、雨天、生日、办公室、夜景等场景。

• 使用浏览器验证搜索、无结果、分析中、失败重试和移动端布局。

• 检查控制台错误和关键接口失败时的页面状态。

再往下，Tasks 就不能只写一句“帮我把搜索做了”，也不能只是把功能点重新列一遍。Kiro 里的 Tasks 更像一份可执行的开发清单：有父任务、子任务、具体改动点、依赖关系，还会标明它对应哪条 Requirements。这里的 [ ] 表示待执行，[x] 表示已完成。

• 1. 搭建智能相册搜索的基础数据结构

Dependencies: None

• 1.1 实现 PhotoAnalysis 类型和存储结构

• 按照 design.md 中 PhotoAnalysis 的定义实现数据结构。

• 为测试图库准备海边、雨天、生日、办公室、夜景等样本数据。

• Dependencies: None

• Requirements: R1, R3

• 1.2 实现分析任务状态流转

• 按照 design.md 中 PhotoAnalysisJob 的定义实现分析任务状态流转。

• 按照 design.md 中的错误处理策略实现失败状态和重试入口。

• Dependencies: 1.1

• Requirements: R3, R5

• 2. 实现自然语言搜索能力

Dependencies: 1.1, 1.2

• 2.1 实现 SearchService

• 接收用户输入的自然语言搜索词。

• 根据场景、颜色、天气、人物状态、事件、用途等字段匹配 PhotoAnalysis。

• 返回照片列表时同时返回匹配原因。

• Dependencies: 1.1

• Requirements: R1, R2

• 2.2 处理搜索无结果和分析未完成状态

• 按照 design.md 中的错误处理策略区分“没有匹配照片”和“部分照片仍在分析中”。

• 搜索失败时展示 error 状态和重试入口。

• Dependencies: 1.2, 2.1

• Requirements: R4, R5

• 3. 实现搜索页面和浏览器验证

Dependencies: 2.1, 2.2

• 3.1 实现 SearchPage

• 创建搜索框、示例词、照片网格和照片详情入口。

• 在照片卡片上展示主要匹配原因。

• 补齐 loading、empty、error 状态。

• Dependencies: 2.1, 2.2

• Requirements: R1, R2, R4

• 3.2 验证页面行为

• 使用浏览器或 Playwright 验证搜索结果、无结果提示、分析中提示、失败重试和移动端布局。

• 检查控制台是否存在错误。

• 输出验证结果和剩余风险。

• Dependencies: 3.1

• Requirements: R4, R5

执行过程中，AI 每完成一项就会更新状态。比如 1.1、1.2 会从 [ ] 变成 [x]：

• 1.1 实现 PhotoAnalysis 类型和存储结构

• 1.2 实现分析任务状态流转

• 2.1 实现 SearchService

这样一来，三个文档的差异就很清楚：Requirements 讲清楚需求和边界，Design 讲清楚技术路线和风险，Tasks 把方案拆成可以执行、可以检查、可以逐步完成的开发动作。

这一步很重要，因为它把“规格文档”变成了“AI 可执行的开发任务”。

如果直接从 Requirements 跳到写代码，AI 还是容易自由发挥。Design 和 Tasks 能进一步限制它的执行路径，让它知道这次不是做一个想象中的完整产品，而是按确认后的范围一步步落地。

第三步：用 Goal 模式让 AI 连续执行

Requirements、Design、Tasks 都收敛后，我会用 Goal 模式让 AI 执行开发。前面的 Requirements / Design / Tasks 是工作流，不绑定具体工具；到了执行阶段，可以选择支持目标化执行的工具来跑。这里说的 Goal，也不限定某一个工具。Codex、Claude Code、Oh My Pi 等很多 AI 编码工具，都可以用类似的目标化方式来执行。

Goal 的核心作用，不是重新定义需求，也不是替代前面的文档。它解决的是另一个更实际的问题：让 AI 围绕一个明确目标持续工作，完整跑完这一轮任务，而不是做一步就停下来等人继续指挥。

普通 prompt 更像一次请求，适合让 AI 做一步；Goal 更像一次完整执行，适合让 AI 跑完一件事。

从个人实践看，Goal 也是 AI 编程往更自动化阶段发展的一个信号。过去我们更多是在对话里一步一步指挥 AI：改这里、跑一下、报错了再修。现在更理想的方式是，在范围清晰、任务可验证的前提下，人把目标、范围和完成条件讲清楚，AI 自己连续完成开发、检查、修复和汇报。人不再盯着每个小动作，而是在关键决策和最终验收上介入。

我现在会把一个 Goal 写成三个部分：范围、约束、完成标准。

反面写法可能是：

帮我实现一下智能相册搜索页面。

这句话的问题，不只是写得短，而是它很容易让 AI 做到某一步就停下来：代码写完了停一次，测试报错停一次，页面还没看也停一次。最后人要不断追问“继续”“修一下”“再测一下”。

我更倾向于这样写：

请严格根据已确认的 requirements.md、design.md 和 tasks.md 完成本轮开发。

本轮只处理 tasks.md 中的页面开发和页面验证任务：

• 首页搜索框

• 搜索示例

• 照片网格

• 搜索 loading / empty / error 状态

• 移动端适配

不要修改搜索排序算法，不要引入新依赖，不要做无关重构。

完成后请运行现有检查，并使用浏览器验证首页、无结果状态、失败重试和移动端布局。

最后输出改动说明、验证结果和剩余风险。

这才是我理解里的 Goal：不是更长的 prompt，而是给 AI 一个可以持续推进的目标，让它按任务范围完成开发、检查、修复和结果汇报。

图 2：普通 Prompt 与 Goal 模式的差异

Requirements 和 Design 负责让 AI 知道“该做什么、怎么做”，Tasks 负责把事情拆成步骤，Goal 负责让 AI 把这一轮任务连续跑完。它的价值不在于重新解释需求，而在于减少人工在执行过程中的频繁接力。

第四步：用验证闭环管交付

Goal 能让 AI 连续执行，但代码写完不代表功能完成。尤其是页面需求，不能只看代码。页面能不能打开，按钮能不能点，loading、empty、error 状态是不是正常，移动端有没有遮挡和溢出，控制台有没有报错，这些都需要看真实页面。

所以涉及界面的需求，我会继续让 AI 使用 Codex 内置浏览器或 Playwright 打开真实页面，按用户路径做验证。

我不太接受 AI 只说一句“页面正常”。验证要有证据，比如截图、控制台日志、网络请求结果、关键 DOM 状态，或者测试命令输出。

如果验证发现问题，就让 AI 修复，然后再次验证。但这个过程不能无限循环。如果同一个问题反复修不好，就应该停下来重新分析根因，而不是让 AI 一直试。

人在流程里还做什么

AI 做得越来越多以后，一个常见误解是：人是不是就不用参与了？我的感受正好相反。

人不用再亲自完成每一步，但人的职责更靠前，也更关键：

• 人提供上下文：PRD、设计稿、接口文档、历史讨论、现有代码约束、业务规则、验收标准。

• 人做关键决策：技术方案、依赖选择、公共组件和接口是否要改、哪些风险可以接受。

• 人确认结果：需求是否正确、边界是否合理、最终效果是否符合真实业务预期。

• 人沉淀经验：把有效提示词、Requirements / Design / Tasks 模板、Goal 模板、失败模式和验证方式沉淀下来。

AI 的问题不只是“不知道”，还有“知道但没用”。它可能读过约束，但实现时忘了；它可能知道要验证，但最后没跑；它可能知道不要扩大范围，但还是顺手重构。

所以关键约束要写进 Requirements、Design、Tasks、Goal 和验证流程里，不能只靠聊天时口头提醒。

工具和成本，只是取舍问题

具体用什么工具不是最重要的，但工具名也不需要刻意隐藏。真实工作里，我确实会根据任务类型做分工。

我现在大致是这样用：

• Codex 更像主控。我个人主要用 Codex app 做 Requirements 整理、Review、Goal 执行和页面验证。

• Claude Code 是独立的 AI 编码工具，也有 CLI、编辑器插件等不同入口。我个人更多通过 VS Code 插件使用它，处理局部代码解释、小范围修改和顺手排查问题。

• Oh My Pi 更像低成本执行层。代码搜索、样式调整、跑测试、机械性清理这类低风险任务，可以交给它处理。

• Playwright 或 Codex 内置浏览器负责页面验证。只要涉及 UI，我就不只看代码，而是让 AI 打开真实页面跑一遍。

这些工具都可以按 Goal 的思路使用。真正重要的不是某个工具，而是分清：谁负责沉淀上下文，谁负责主要执行，谁承担低风险任务，谁负责验证结果。

复杂需求、影响范围大的需求，值得使用顶级模型和完整流程。简单文案、小样式、机械修改，不需要完整 Spec / Goal 流程。

成本不能只看 token，也要看减少了多少反复沟通、返工和人工测试时间。

结尾

我现在越来越明确的一点是：AI 辅助研发不是让 AI 替代研发流程。相反，它要求我们把研发流程讲得更清楚：需求、边界、任务、验证方式和停止条件，都要尽量显性化。

这套方法也不是要求每个小需求都写完整 Spec。小文案、小样式、局部 bug，可以直接交给 AI 做；真正需要拉开流程的，是那些范围大、依赖多、影响用户体验或业务规则的复杂需求。

对这类需求来说，Requirements 负责把方向讲清楚，Design 和 Tasks 负责把路径拆清楚，Goal 负责让 AI 连续跑完这一轮任务。最后先让 AI 通过测试、浏览器或 Playwright 做自动验证，再由人做 UAT，整个链路才算闭合。

对我来说，从 Spec 到 Goal 的变化，不是把人从研发里拿掉，而是把人的判断前置，把 AI 的执行拉长。

AI 越强，越不能只靠一句模糊指令让它自由发挥。复杂需求不要急着让 AI 写代码，先让它帮你把需求问清楚，再让它在清晰的目标里完成开发。