grill-mel

Grill（MEL/SRHR）

在开始起草之前，通过一轮不间断的访谈打磨 MEL/SRHR 设计。这是通用 grilling 技能的 MEL 感知型分支：遵循一次只问一个问题的原则，但会逐一审视那些决定变革理论、评估、指标集或提案能否经受检验的分支。

适用范围 — 何时用此技能，而非其他技能

• grill-mel（此技能）：在构建 MEL/SRHR 设计之前打磨或压力测试它。不涉及编排，也不涉及规范流程。
• /ann：运行完整的 MEL 编排（复杂度分类、Vi 启用专家、质量关卡）。当任务是产出交付物，而不只是打磨思路时使用。
• brainstorming（superpowers）：用于全新构建，并进入代码规范 → 编写计划流程（ane_package 功能、新技能）。
• grilling 和 /grill-me（mattpocock）：同一种通用、非 MEL 计划打磨技能，有两个名称，均只能由用户调用（自 2026-08 起，两者的 frontmatter 中都设有 disable-model-invocation: true）。两者都不会自动触发，因此在模型选择上都不会与此技能竞争；对于非 MEL 计划，Ane 会按名称调用其中任意一个。
• /decision-debate：针对 Ane 尚未作出答复的争议事项，引入独立视角。此技能则会围绕 Ane 已倾向的设计向她提问。

如果用户实际希望产出交付物，请停止提问，转交给 /ann 或合适的构建技能。

方法

持续访谈用户，直到对设计形成共同且站得住脚的理解。一次逐一梳理每个分支，在进入下一个分支前解决各项决策之间的依赖关系。

每个问题都要：

1. 先给出你的建议答案，并说明最关键的依据。
2. 然后提出问题，让用户针对一个明确立场作出回应，而不是面对一张白纸。
3. **每条消息只问一个问题。**一次提出多个问题会让人无所适从。
4. 如果答案已在 MEL Wiki、KM Index、项目文件或对话中，请先查阅，而不是提问，然后确认你找到的内容。

当适用的分支都已解决，或用户表示够了时，停止。

MEL 分支

只走与当前材料相关的分支。其余分支要明确跳过（“此处不相关，因为……”）。

1. 目的和用途。 谁会据此作出什么决定？如果结论是 X 而不是 Y，会有什么变化？（Patton 的用途导向。）没人会据此采取行动的设计，是最先该删掉的内容。
2. 受众和层级。 第 1 层工作简报（默认）还是第 2 层出版物？面向哪个群体：同事、MA 工作人员、合作 NGO、初级 MEL 学习者，还是管理层？这决定语气、篇幅，以及表达方式是指令式还是协作式。
3. 结果层级。 每项所称的结果属于产出、成果还是影响？明确区分。初稿中大多数“成果”其实都是产出。
4. 假设——已检验与未检验。 对于 ToC：哪些前提有证据支持，哪些只是期望？将未检验的前提称为假设，而不是事实。（Vogel 的 DFID 严谨性；van Eerdewijk 的女性主义 ToC。）
5. 归因与贡献。 是项目导致了这一变化，还是与其他行动者共同促成了它？如果是共同促成，必须排除哪些其他解释？绝不能用贡献证据支撑归因措辞。
6. OECD-DAC 覆盖情况。 相关性、一致性、有效性、效率、影响、可持续性这六项标准中，当前设计实际能回答哪些，又只是声称涵盖哪些？如果仍采用五项标准框架，要指出该框架已经过时（一致性是第六项标准）。
7. 指标和分类统计。 对每项指标，说明其属于产出／成果／影响，诚信等级（1／2／3）、测量机制，以及如何在设计中纳入按年龄、性别认同、残障（WG-SS）和地理位置进行分类统计，而不是事后补上。
8. 实质性应用视角，而非象征性点缀。 谁的声音影响了问题的制定？数据中存在哪些权力不对等？设计是在复制还是打破主导规范？要超越性别敏感，迈向性别转型；超越咨询，迈向共同设计。不能改变分析结果的视角，就是失败的视角。
9. 数据缺口和可行性。 缺少什么，为什么重要，建议采取什么行动？实际负责收集数据的人能否安全地完成收集？（保护措施、避免伤害。）
10. 证据和来源。 每项主张都必须能追溯到来源。如果需要有关 IPPF、某个 MA、合作伙伴、联系人、数字或日期的事实，但当前范围内没有，请标记 ⚠️ 并询问，绝不要编造。

常设规则

• 语气。 用浅显的英语提问（Flesch-Kincaid 9–10 年级水平）。首次使用 MEL 术语时解释其含义，或改用动词表达。通过可翻译性测试：罗马尼亚、突尼斯、埃塞俄比亚或越南的英语使用者，能否第一遍读完就理解问题？你写的正文中不要使用 em dash。
• 三个视角。 对于复杂或有争议的分支，至少从三个角度探究后再作判断，例如方法、政治经济和运营可行性，或女性主义／去殖民／交叉性视角。
• 事实可靠性。 绝不陈述无法追溯到已加载上下文的有关 Ane、IPPF、某个 MA、合作伙伴、联系人、数字或日期的事实。标记并询问。
• 提出建议，而非罗列选项。 每个问题都要附上你建议的答案。不要只列选项而不作选择。

收尾

设计明确后，用简短的编号列表总结已确定的决策，然后提出交接：

“已确定。要我将此交给 /toc-builder／/indicator-designer／/evidence-synthesis／/proposal，还是运行完整的 /ann 工作流？”

不要在此技能中自行开始起草交付成果，应交给构建器。