## `grill-me` 与 `grill-with-docs` 这两个 skill 的作用不是直接产出方案，而是在正式写规格、写计划或写代码之前，把问题问清楚。 它们的区别不在于“谁更强”，而在于输入上下文不同： - `grill-me`：适合只有一句话需求、想法还很粗的时候 - `grill-with-docs`：适合已经有文档、但文档还不完整的时候 这两个 skill 负责澄清，不负责直接替团队做最终方案、架构或实现决定。 开源仓库：[`mattpocock/skills`](https://github.com/mattpocock/skills) ```text 先不要实现。 先把这个任务问清楚： - 如果我现在只有一句需求，用 `grill-me` - 如果我已经给了 PRD、设计稿或说明文档，用 `grill-with-docs` 请优先找缺口、边界、依赖和待确认项。 ``` ### 这两个 skill 真正解决什么问题 很多团队的问题，不是没有方案能力，而是太早进入方案能力。 需求只说了一半时就开始写 spec，文档还缺关键约束时就开始进入技术计划，最后返工往往不是因为实现差，而是因为前面的澄清阶段被跳过了。 这两个 skill 的职责不是替团队做决定，而是把决定前必须澄清的问题暴露出来。 ### 怎么选用 推荐用法很简单： 1. **没有文档，只有想法**：先用 `grill-me` 2. **已经有文档，但仍然模糊**：改用 `grill-with-docs` 3. **问题问清楚后**：再把结果交给 `speckit.specify`、`clarify` 或后续计划阶段 这类 skill 最适合追问的内容包括： - 目标用户是谁 - 这次改动真正要解决什么问题 - 哪些行为必须支持 - 哪些范围明确不做 - 有没有特殊边界、例外情况或兼容性要求 - 已有文档里哪些结论还没有证据支撑 ### 为什么它们很适合放在流程最前面 澄清阶段如果做对，后面所有阶段都会更稳定： - 规格更容易一次写准 - 方案边界更清晰 - review 时更少出现“目标理解错了” - 代码返工和测试补洞会显著减少 从产品说明书角度看，这两个 skill 不是“附加优化”，而是需求进入正式执行链之前的前置过滤器。 ### 二者的输入差别 | Skill | 更适合的输入 | 主要作用 | | --- | --- | --- | | `grill-me` | 一句话需求、口头想法 | 把模糊任务问具体 | | `grill-with-docs` | PRD、设计稿、已有说明文档 | 对着文档查缺补漏 | `grill-me` 更像从零开始搭问题空间。 `grill-with-docs` 则更像拿着现有材料做结构化审问：文档里哪些地方已经足够明确，哪些地方仍然存在缺口、歧义或跳步。 ### 典型错误用法 最常见的错误不是不会用，而是跳过用： - 需求还没问清楚，就直接进入方案设计 - 有文档就误以为信息已经足够，不再继续审文档 - 把澄清阶段和执行阶段混在一起，边问边写边改 这样做的后果通常不是“多花一点时间”，而是把本该在前面发现的问题推迟到 spec、代码或 review 阶段才暴露。 这两个 skill 更适合作为需求进入 `speckit` 或实现前的前置澄清环节，而不是与实现并行混用。 如果文档本身不可读、附件缺失或上下文入口不完整，`grill-with-docs` 的效果会明显下降，此时应先修复材料可读性，再继续澄清。 这一步通常不需要正式审批，但问出来的关键边界和待确认项，应该在进入 `speckit` 或实现前得到确认。 `grill-with-docs` 的质量取决于当前 Agent 是否真的能读取文档系统中的材料；文档不可达时，需要退回 `grill-me` 或先补齐访问能力。 读完本章后，读者应该能明确：什么时候该先用 `grill-me`，什么时候该先用 `grill-with-docs`，以及为什么澄清阶段不能被直接跳过。