为什么用 Skill 做需求澄清

为什么用 Skill 做需求澄清背景PRD 到 AI Coding 的断层传统的软件开发流程中PRD产品需求文档是写给开发者的。开发者作为人具备一种关键能力自动脑补。PRD 说支持批量删除开发者会自动推断应该有个全选框、应该有二次确认、删除完列表要刷新。这些细节 PRD 没写但人知道。AI 不具备这种能力。AI 不会脑补——它要么根据训练数据中最常见的写法猜测要么直接忽略。一个支持批量操作的需求AI 可能不会加二次确认不会处理部分失败的情况不会考虑全选后翻页的行为差异。这就是断层PRD 的隐含假设无法被 AI 消费。需求澄清的目的就是把这些隐含假设显式化变成 AI 能直接使用的精确规格说明。什么是需求澄清需求澄清是一个结构化的信息补全过程输入PRD 文档面向人的、有隐含假设的过程从 5 个维度范围边界、交互流程、异常边界、数据规则、非功能需求系统性提问输出澄清文档面向 AI 的、无隐含假设的澄清文档和 PRD 的关键区别PRD澄清文档读者人开发者、测试AI代码生成工具隐含假设大量人不写也懂零所有细节显式化异常处理通常不写每个场景都有定义字段约束粗略“手机号”精确11位数字必填唯一性校验错误提示该手机号已注册空状态不提每个列表/表单都有定义为什么选择 Skill 而不是 Tool 或 SubAgent在 Claude Code 生态中有三种扩展机制各有不同的能力边界。需求澄清的特征决定了它只能用 Skill 来做。三种机制的本质区别Tool执行操作Tool 的本质是给输入出结果。它是一个函数f(input) - output。比如search_table(用户表)→ 返回匹配的表列表run_sql(SELECT * FROM users)→ 返回查询结果Tool 是无状态的——每次调用独立不记忆上下文不管理流程。它适合做具体的、可重复的、确定性的操作。SubAgent自治执行SubAgent 的本质是给任务自主完成。它是一个独立的 Agent 实例有自己的上下文、工具访问权限和决策能力。比如“分析这个代码库的架构找出性能瓶颈” → SubAgent 自主探索、分析、返回结论“把这组测试用例跑通” → SubAgent 自主执行、调试、修复SubAgent 是自治的——它自己决定怎么做、用什么工具、什么时候完成。适合复杂的、需要多步自主判断的任务。Skill流程模板Skill 的本质是按模板引导用户走完流程。它是一组结构化的指令由主 Agent 执行用户深度参与。比如brainstorming引导用户从模糊想法到具体设计TDD引导开发者先写测试、再写实现、再重构需求澄清引导用户逐维度补全 PRD 的隐含假设Skill 是交互式的——每一步都需要用户输入Agent 按模板引导不替用户做决策。需求澄清的特征矩阵特征需求澄清的实际情况Tool 匹配度SubAgent 匹配度Skill 匹配度交互模式多轮对话一问一答❌ 单次调用⚠️ 可以但不擅长✅ 天然支持用户决策强依赖每个答案都需要人确认❌ 无用户参与❌ 会自己脑补✅ 强制等用户回答流程标准化5 个维度固定顺序❌ 无流程概念⚠️ 可能跳过维度✅ checklist 保证完整外部 API不需要❌ Tool 的价值就是调 API❌ 能力浪费✅ 不需要额外工具输出格式结构化文档⚠️ 可以但不灵活⚠️ 格式不统一✅ 模板化输出与主流程衔接澄清完直接进 coding❌ 结果孤立⚠️ 需要手动传递✅ 主 Agent 自然衔接为什么 Tool 不行需求澄清不是一个输入→输出的操作。它的核心困难不是执行而是问对问题。Tool 可以搜索表、执行 SQL、调接口——这些都是确定性的操作。但删除操作是否需要二次确认这个问题不是 Tool 能回答的也不是 Tool 能问出来的。Tool 没有流程编排能力无法根据前一个答案决定下一个问题。如果强行用 Tool 做大概会变成clarify_requirements(prd_text)→ 返回一堆问题。然后呢谁来问用户谁来记录答案谁来保证 5 个维度都覆盖到了这些问题 Tool 解决不了。为什么 SubAgent 不行SubAgent 最大的问题是自治。需求澄清不能自治——它必须让用户做决策。如果用 SubAgent 做需求澄清有两种可能SubAgent 自己脑补答案它根据训练数据推断删除操作通常需要二次确认然后自己填上。这就不是澄清了而是猜测。用户看到的是一份看起来完整的文档但每个答案都是 AI 替用户决定的——比 PRD 更危险。SubAgent 反复向用户提问但它缺乏流程模板约束提问顺序可能混乱可能遗漏某个维度可能同一个问题换个说法问两遍。SubAgent 的强项是自主探索不是按部就班地走流程。为什么 Skill 正好Skill 的三个特性与需求澄清的三个需求一一对应1. 模板驱动 ↔ 维度覆盖Skill 定义了 5 个维度和每个维度的检查清单。Agent 按模板走不会遗漏。每个维度有提问模板确保问题结构化。这是 Tool 做不到的流程保证也是 SubAgent 容易丢失的结构约束。2. 交互式执行 ↔ 用户决策Skill 天然是一问一答的。Agent 问一个维度的问题 → 等用户回答 → 总结确认 → 进入下一个维度。用户始终是决策者Agent 只是引导者。这是 SubAgent 做不到的交互保证。3. 主 Agent 执行 ↔ 无缝衔接Skill 在主 Agent 中执行不需要启动独立进程。需求澄清的结果直接在主 Agent 的上下文中下一步可以直接交给 coding Skill 使用不需要把结果传过去。这是 SubAgent 做不到的衔接保证。一句话总结需求澄清 结构化流程保证不遗漏交互式对话保证用户决策模板化输出保证可消费。这三点恰好是 Skill 的能力边界而 Tool 只能做操作SubAgent 太自治。选对机制事半功倍。