用途
这是一个交互式规格工程（Specification Engineer）技能。它的核心任务是在写下一行代码、或把任务委派给更便宜的智能体之前，先与用户一起把一份完整的规格梳理清楚。
该技能基于一个判断：多数任务失败不在模型，而在输入。用户知道自己想要什么，却无法足够精确地表达；AI 会用统计上的合理性去填补空白，也就是以一种常常微妙出错的方式去猜。结果就是 70-80% 正确、40 分钟返工，或者更糟——技术上正确但偏离目标。
背景上，Anthropic 自己的工程团队曾记录：即使给 Opus 4.5 一个高层级提示，它也无法构建生产级 Web 应用。解决办法不是更好的模型，而是一种规格模式：环境搭建、进度日志，以及一个针对结构化计划增量推进的编码智能体。规格成为让多个智能体跨多个上下文窗口保持一致工作的骨架。
何时不要使用
- 单个小改动（1 个文件、几行、任务清晰）
- 用户已经写好详细规格，只想执行
- 纯知识问答或调研
- 用户明确说“直接做”或“不要写规格”
主要能力：四个阶段
阶段 1：现状盘点（我有什么，缺什么）
先读已有材料，再问用户。检查：对话上下文（用户已说了什么、提到哪些文件）、项目上下文（CLAUDE.md、AGENTS.md、README.md、package.json）、代码上下文（相关文件的导入、导出、约定、现有测试）、记忆（若 persistent-memory 可用则加载项目状态）。
然后按七个维度内部评估：目标（想要的结果是否清晰）、上下文（背景信息是否齐全）、验收（外人能否判断是否完成）、约束（什么不能发生）、拆解（任务是否拆成可验证部分）、技术（技术栈、文件、依赖）、失败模式（什么可能微妙出错）。
向用户展示这张表并给出诚实评估，简要说明已知与缺失，不写长篇独白。
阶段 2：针对性访谈（填补缺口）
只问真正缺失的内容，每轮最多 3 个问题，先问最重要的 2-3 个缺口。规则：不问自己能查到的（读代码、读文档）；不问显而易见的东西，而是深挖难点；用户说“不知道”或“无所谓”时，提出一个合理默认并确认；发现用户未考虑到的冲突时给出提示；问题要让没有编程经验的人也能回答，同时足够精确以便直接写入规格。
典型问题按维度举例：目标——“看到结果的人应该能用它做什么？”“如果必须在 A 和 B 之间选，哪个更重要？”验收——“你凭什么判断它完成了？”“什么会让你说‘不，这不是我的意思’，即使它技术上正确？”约束——“什么绝对不能坏？”“有没有不能动的现有代码/逻辑？”失败模式——“上次做类似事情时哪里出错了？”“你最不确定的地方在哪？”
重复阶段 2，直到七个维度全部为 ✅ 或 ⚠️（有意接受）。
阶段 3：撰写规格
清晰度足够后写规格，格式取决于目标。
选项 A：SPEC.md（用于自己执行或较长项目），包含：目标、上下文（项目/技术栈/仓库结构、当前状态、相关文件路径）、验收标准（可验证条目）、约束（MUSS / DARF NICHT / BEVORZUGT / ESKALATION 四类）、子任务（每个含输入、输出、验证方式与预估时长）、已知风险/失败模式、完成定义。
选项 B：CC-Prompt（用于委派给 Sonnet 或更便宜模型）。结构顺序为：上下文（项目是什么、已完成什么、CC 应读的参考文档）；Self-Fix 协议（强制，每个阶段循环：创建/修改文件 → 用具体命令验证 → 出错则读错误、调试、修复、回到验证，每个子任务最多 3 次修复，超过则记录问题并进入下一阶段 → 通过则进入下一阶段）；关键规则（项目特定陷阱）；阶段 N（文件名、新建或扩展、精确代码或精确修改说明、执行命令、失败排查）；收尾提交（git add 逐个列出文件、git commit 含 conventional commit 信息）；预期结果表。
CC-Prompt 规则：新文件给精确可运行代码；扩展文件说明插入位置并给代码块；配置改动展示 diff（前→后）而非“改 X”。散文式描述对 Opus 可行，但 Sonnet 需要具体代码。关键规则典型类别包括命名冲突、Mock 边界、选择器/路径（用代码中的真实选择器而非文档）、环境变量、现有代码“扩展而非重复”。每阶段排查块常见模式：选择器找不到、超时（用 waitForLoadState 而非 waitForTimeout）、导入错误、功能不存在（优雅跳过并说明）、构建错误、API 错误。
CC-Prompt 质量清单：上下文是否清楚；是否含 Self-Fix 循环及最大次数与跳过回退；关键规则是否记录所有已知陷阱；每阶段是否有精确代码或精确修改说明；每阶段是否有执行命令；每阶段是否有常见错误排查；现有文件是否扩展而非重复；导入与路径是否与实际代码一致；结尾是否有含全部文件的提交命令；结尾是否有结果表。
阶段 4：评审与授权
向用户展示完成的规格/提示，明确询问：“这样行吗？还缺什么？”“我直接开始，还是你想委派给 CC/Sonnet？”只有获得授权后才执行，或把 CC-Prompt 保存为文件（如 docs/CC_PROMPT_[任务].md）。
使用方式
- 输出格式：把完成的 CC-Prompt 保存为 Markdown 文件（如 docs/CC_PROMPT_[任务].md），供用户复制粘贴进 CC。该提示必须能作为独立文档工作，因为 CC 无法访问当前对话。
- SPEC.md 放在项目根目录或 docs/ 文件夹。
- 与其他技能集成：persistent-memory（盘点前加载项目状态）、lara-assistant（沟通规则同样适用）、code-quality-gate（若规格涉及代码，在约束中引用质量门要求）。
适用场景
需要多步骤、多文件、需要委派给其他模型、或用户表达不够精确的任务。
限制与成本说明
规格阶段会消耗 token，但能节省数倍：一次 10 分钟访谈可省 3-5 轮修正（每轮 10,000-50,000 token）；给 Sonnet 的清晰规格相比给 Opus 的模糊提示约省 80%；精确验收标准可避免“80% 问题”（几乎正确，返工比新建更久）。资料中给出的价格参考：Sonnet 4.5 为 $3/$15 每 MTok（输入/输出），Opus 为 $15/$75。资料称规格投入是质量与成本效率的最大杠杆。
若不确定某任务是否需要规格，可简短询问用户：“这听起来不止是个小改动。要不要我先过一遍我需要什么、还缺什么，再开始？”宁可多问一次，也不要朝错误方向干一小时。