你可能也遇到过这种时刻把一个复杂需求丢给 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.mdGitHub 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。贯穿动作多轮 Reviewrequirements.md生成以后我先不进入开发而是继续让 AI 做第一轮 review。这里 review 的对象首先是 Requirements但 review 不是一个固定步骤也不是只发生在需求阶段。后面的 Design、Tasks、Goal 执行结果和页面验证结果都可能需要根据风险继续 review。第一轮 Review 的重点不是挑错别字而是看用户故事是否清楚边界是否清楚明确不做什么是否写清楚是否存在隐藏假设是否有未确认的接口、字段、状态验收标准是否真的可验证如果上线会不会有权限、隐私、成本、兼容性风险还是智能相册这个例子。grill-me已经把“演示原型还是可上线功能”这条分界问出来了但被问出来不等于已经收敛。当前 Requirements 看起来已经比较完整支持自然语言搜索、展示匹配原因、处理无结果和失败状态。如果最后确认是可上线功能就必须继续确认是云端分析还是本地分析不同手机系统的相册权限差异怎么处理搜索无结果时怎么区分是真的没有还是还没分析完云端分析成本和额度怎么控制敏感内容是否参与分析和搜索第一阶段成功指标是什么这时就能看出来Requirements 写得完整不代表需求已经足够清楚。很多关键问题不是 AI 不知道而是你没有逼它问出来。第二步从 Requirements 到 Design 和 TasksRequirements 确认以后才进入 Design 和 Tasks。我一般把这三个文档的分工理解成Plaintextrequirements.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: None1.1 实现 PhotoAnalysis 类型和存储结构按照 design.md 中 PhotoAnalysis 的定义实现数据结构。为测试图库准备海边、雨天、生日、办公室、夜景等样本数据。Dependencies: NoneRequirements: R1, R31.2 实现分析任务状态流转按照 design.md 中 PhotoAnalysisJob 的定义实现分析任务状态流转。按照 design.md 中的错误处理策略实现失败状态和重试入口。Dependencies: 1.1Requirements: R3, R52. 实现自然语言搜索能力Dependencies: 1.1, 1.22.1 实现 SearchService接收用户输入的自然语言搜索词。根据场景、颜色、天气、人物状态、事件、用途等字段匹配 PhotoAnalysis。返回照片列表时同时返回匹配原因。Dependencies: 1.1Requirements: R1, R22.2 处理搜索无结果和分析未完成状态按照 design.md 中的错误处理策略区分“没有匹配照片”和“部分照片仍在分析中”。搜索失败时展示 error 状态和重试入口。Dependencies: 1.2, 2.1Requirements: R4, R53. 实现搜索页面和浏览器验证Dependencies: 2.1, 2.23.1 实现 SearchPage创建搜索框、示例词、照片网格和照片详情入口。在照片卡片上展示主要匹配原因。补齐 loading、empty、error 状态。Dependencies: 2.1, 2.2Requirements: R1, R2, R43.2 验证页面行为使用浏览器或 Playwright 验证搜索结果、无结果提示、分析中提示、失败重试和移动端布局。检查控制台是否存在错误。输出验证结果和剩余风险。Dependencies: 3.1Requirements: 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 写代码先让它帮你把需求问清楚再让它在清晰的目标里完成开发。