前言¶
方案写到一半、决策有了雏形，接下来最常见的做法是发到群里求意见。意见会来，但通常是整体评价：「看起来还行」「方向对的」。真正要挑出来的漏洞，往往在你没写出来的那几条分支里，而熟人评审很少逐条追问。
另一种做法是自己反复想。问题是想的时候容易顺着原来的假设走，同一个漏洞会绕开两次。
「发起方案拷问」针对的就是这个环节：你已经有方案或决策雏形，它负责发起一轮逐分支、并且给出推荐答案的压力拷问，把评审从「整体评价」变成「逐条过」。
这是什么¶
一句话定位：一个在方案成型期介入的评审型 Skill，对已有方案逐分支提问，并给出倾向性结论。
- 出品方：昆仑增长（@kunlungrowth）
- 坐标：
@kunlungrowth/kg-grill-me - 版本：1.0.0
- 来源：enterprise
- 分类：business-ops
- 标签：
requires_api_key=false，即不需要额外配置 API Key - 页面数据：评分 100000，下载 951 次，安装 0
它解决的问题是：方案有雏形之后，缺一个结构化、不客气的逐分支质疑过程。它不负责从零生成方案，也不负责执行方案。
核心功能¶
官方简介给出的能力只有两条，都围绕「拷问」这个动作：
- 逐分支：把方案拆开成分支分别审视，而不是只给一个总评。这意味着分支是否覆盖完整、每条分支的假设是否成立，都会被单独过一遍。
- 给推荐答案：不止于提问，还会给出倾向性结论。这一定位比单纯头脑风暴更接近评审：你要的是「这一条我建议怎么处理」，而不是「你觉得这条怎么样」。
适用前提写在简介里：你需要已经「有方案或决策雏形」。输入物是一个初步方案或一个待定决策，不是一句需求描述。
安装与启用¶
官方页面未提供安装命令、目录路径或配置字段。已有资料里也没有 Cursor、Codex CLI、Claude Code 三种环境各自的差异说明。这部分不写推测内容，需要时以官方页面当前说明为准。
可以确定的是配置侧：标签为 requires_api_key=false，因此不涉及 API Key 的申请与填入。
典型用法¶
官方资料未提供可复现的调用示例，下面是一条基于简介构造的输入示意，不是官方原文。
把方案写成包含分支、假设和备选的文本交给它，例如：
方案：下季度获客预算从内容投放转向渠道分销。
分支一：内容投放削减 50%，预计自然流量下降 30%。
分支二：新增 3 个区域渠道，每个渠道首季度投入 20 万。
分支三：保留 10% 预算做新渠道实验。
请逐分支拷问，并给出每个分支的推荐处理方式。
期望得到的输出是逐条质疑加上每条的推荐答案，而不是一段整体评价。实际措辞以你使用的客户端为准。
适用场景与注意¶
适合谁：
- 方案已经写到有分支和假设的程度，需要一次不客气的复核
- 决策涉及多条互斥路径，自己反复想容易绕回原结论
- 团队评审节奏慢，需要一个能立刻启动的结构化提问过程
限制：
- 输入必须是成型的方案或决策雏形。如果只有一句需求或一个模糊方向，它没有足够信息拆分支
- 「推荐答案」是模型基于你提供的方案文本给出的倾向性结论，不替代事实核查。分支里涉及的数据、成本、外部依赖仍需自行验证
- 拷问质量取决于方案文本的完整度。分支写得含糊，拷问也只能在含糊的层面展开
结尾¶
这个 Skill 的价值在于把方案评审从整体感觉拉回到逐分支判断：每条分支单独过，每条给出推荐答案。它不帮你写方案，也不替你决策，只是在你已有雏形时补上一轮结构化的压力测试。
官方地址：https://api.skillhub.cn/kunlungrowth/kg-grill-me
页面地址：https://www.skillhub.cn/skills/kunlungrowth/kg-grill-me
