shaomang/mtnode-aio/grill-me

拷问我（grill-me）

目标：在动手之前，用最少而准的提问把需求问到没有歧义。共识未经用户明确确认前：不写代码、不改画布、不出实施计划。

一、先把需求映射成决策树

• 每个「决策」是树上的一个节点，依赖它的决策挂在它下面。
• 严格区分两类：事实（能自己查到的，不是问题）与决策（只有用户能定的，才是问题）。
• 不要拿事实去烦用户，也不要把决策默默替用户拍板。

二、MTNode 的询问格式 = 询问窗（本技能的第一纪律）

提问必须调用 `ask_user_question` 工具——它会在 MTNode 界面上弹出询问窗（「🐋 模型等待你的回应」卡片），用户在卡片里点选项、填空，答案直接回到你手里。把问题写成回复正文的编号列表、让用户在输入框里敲答案，是错误做法（用户已明确反馈这是 bug），一律不允许。

一轮前沿 = 一次 ask_user_question 调用，把该轮全部问题放进 questions[]：

• id：本轮内稳定短名（q1、q2…），答案按 id 回传。
• question：完整题面（一句话说清要决定什么、为什么需要用户定）。
• header：可选短标题（卡片上显示在题面前，如「确认」「取舍」「范围」）。
• options：给出候选，推荐的那一项放第一位，并在 label 末尾加「（推荐）」；description 写一句话理由 / 代价（卡片会把这句显示在选项下方的第二行，所以只写一句，别塞长文）。
• multi_select：候选可并存时置 true。
• 一轮 3–7 题为宜，宁缺毋滥，能合并的合并；每题只问一件事。

调用后什么也不用多说：工具本身是阻塞的，答案回来再继续。不要为了「停下等用户」而提前结束回合，也不要在同一轮里既提问又开工。

三、按轮推进「前沿」

• 前沿 = 前置答案都已确定、现在就能问、不需要猜任何未听到的答案的那些决策。
• 一轮问完整个前沿：整轮只发一次询问窗，不要一题一题地弹。
• 禁止自问自答；禁止列完问题就接着开工。
• 某问题的答案依赖本轮另一个尚未确定的答案 → 它属于下一轮，不要现在问。
• 答案回来后据此重排决策树：已定的决策把前沿向外推，解锁原先被卡住的问题；下一轮只问新前沿，不重复已问过的问题、不重开已定的决策。
• 用户答得含糊（自定义答案太笼统、只选了「其他」）时，只就那一点再问一轮（询问窗可以只发一题），不要自行补全。

四、收尾确认

• 前沿为空：树的每个分支都走到过，没有任何东西被默默假设。
• 收尾这一轮仍然用询问窗，且按固定格式写那一张卡（询问窗会把 question 切成两块渲染：

首行当标题行，空行之后的其余内容按 Markdown 渲染进「📋 总结」区）：

• question 的第一行只放一句话题面，例如 以上共识是否无误？ —— 不要把总结塞在这一行里；
• 空行之后才是整份共识总结，用 Markdown 写：小标题 + 要点列表，条目多或要对齐取舍时用表格；
• 选项只留两项：推荐项 = 明确同意开工（如 确认无误，开始实施（推荐）），另一个 = 还要改，我补充

（措辞随交流语言）—— 得到「确认」这一项（或用户自定义的明确同意）才开始动手；

• 不要把共识拆成几张卡，也不要在正文里再列一遍问题编号。
• 用户点「稍后（终止本轮）」或「中断任务」= 本轮已被停掉，不要把沉默当成确认。

五、找事实是你的活，永远不是用户的

• 需要环境事实（读代码、查文件、确认工具与接口能力）时自己动手：用只读工具（read / grep / glob / 只读命令）或派子代理去查。
• 绝不向用户索要「你自己能查到的东西」。
• 不要为此阻塞：正在跑的探查是一个尚未落定的前置，只有依赖它的那些问题等它的结果；其余前沿照常现在就问。
• 探查回来后据此提问，或确认该分支已无决策、直接剪掉。

六、兜底：询问窗不可用时

当前会话的「Agent 工具许可」可能把「向用户提问」这一项关掉（ask_user_question 因此不存在，调用会失败）。只有这种时候才退回正文排版，并在开头说明「本会话询问窗不可用，改用正文提问」：

❓ **Q1** - **<问题标题>**：<问题正文>
 
➡️ <你推荐的答案，以及一句话理由>
 
---
 
❓ **Q2** - **<问题标题>**：<正文>
 
➡️ <推荐答案>

除此之外，正文里不要再出现「Q1 / Q2」式的提问清单。

七、拷问的另一条出口：长周期任务图（DAG）

拷问清楚之后，产物不一定是「一次跑完的画布」。如果第 1~6 步问出来的结论里有下面任何一条，就该产出一张长周期任务图（应用里的「长周期任务 · 状态机」，画布上方那条细线展开后的东西），而不是流水线：

• 中间有必须人来做的判断或交付：审批（通过 / 驳回）、把定稿 / 素材 / 参数交进来；
• 驳回后要退回前面某个环节重做（回跳默认不限次数；可选设上限，超出上限该环节转失败）；
• 有并行分支要等齐（汇聚），或要逐项展开跑同一段子流程（数组摊开，各项互不可见）；
• 一段流程要装成子图复用（可下钻编辑、层层套）。

四条都不沾，就别硬造状态机 —— 常规画布更简单。判据一句话：这张图需不需要「停下来等人、拿到人的结果再继续往下走」。需要就是长任务；不需要就是流水线。

产出契约

图的字段只以 renderer/app-longtask.js 的 ltNormCfg / ltNormGraph 为准（归一化会补齐缺省、丢掉非法值，所以多余字段无害、缺字段有默认）。写成：

{
  "kind": "mtnode-longtask-graph",
  "ver": 1,
  "name": "任务名（用户语言）",
  "graph": { "ver": 1, "nodes": [ ... ], "edges": [ ... ] }
}

节点：{ id, kind, x, y, title, cfg }。id 全图唯一、只用字母数字下划线中划线（回跳 backTo 与子图引用都靠它）；x/y 给个从左到右的粗略布局即可（条带有自动排版）。kind 与各自的 cfg：

交付清单条目：{ id, kind: "file"|"text"|"choice"|"media", title, desc, required, options[], multi, byAgent }。required 缺省为真 —— 必填项全交齐才允许人工点「确认交付完成」。byAgent: true 表示这条由 Agent 声明「我产出了它」，人仍要验收。id 请用 ASCII（它同时是运行态状态键与清单对齐的键）。

交付清单是双向的：应用写 <画布工作目录>\mtnode-deliverables\<uid>\manifest.json，也会在重新进入该环节 / 点「继续」时把磁盘上的完成状态（done / value / paths / choice）读回来 —— 用户在应用外手改 / 丢文件是生效的。uid 由系统生成（lt<随机>-<环节短名>，短名可含中文），不要在图 JSON 里自己编。

边：{ id, from, to, label, cond }。cond 是一小段受限 JS 谓词，作用域里有 input.state（整份共享状态，读键写 input.state.<键>；也可以直接写 `state.<键>`，引擎两条都认）、input.node（本边起点那一环：{id,kind,title}）与 input.runId。两条写法都行：return <真值>，或直接写一行表达式（如 state.pool_ok === false —— 引擎会按表达式求值，别写成没值可言的语句序列）。写错或超时会转成「需人工」而不是把任务崩掉。

报错不许把整条链卡死（用户口径）：跑起来后某一环报错（Agent 重试用尽 / 缺输出键 / 条件谓词炸 / 子图里跑坏），用户在条带「卡住的环节」卡上点「无视报错并继续」即可当场放行（可指定跳到哪一环，也能勾「以后这一环报错都照此放行」写回图定义）—— 所以图要留兜底路径：关键环节后面最好有一条能继续往下走的分支（end_fail 或一条无条件出边），别把整张图收在一个必过节点上。

怎么交到用户手上

不要试图直接改画布 JSON 里的 `wf.longtask`（那是应用持有的字段，画布写工具不碰它）。 共识达成后，图的落地只有这一条正路 —— 把它建出来，不是把清单交给用户让他自己搭：

1. 调用 mtnode_app（action:"create_longtask"，带 name 与 graph）把这张图落库到当前画布的

长周期任务列表：应用会归一 + 校验，有 err 就把 err 文本回给你 —— 照它改完重新调用，直到落库成功； 落库成功后用中文给一份「节点 → 干什么 → 吃哪些键 / 产出哪些键」+ 连线清单的摘要即可；

1. 若本会话没有注册 mtnode_app（开发 / 细化绑定会话、与画布无关的会话等），或调用报错：

把完整图定义 JSON（同一份 kind:"mtnode-longtask-graph" 外壳）原样放进回复正文的 ```json 围栏里， 并说明「本会话落库入口不可用」—— 长任务新建窗的引导会话会由应用自动接手落库；

1. 无论哪条路，都可以顺手把这份 JSON 写到当前工作目录留档（如 longtask-<任务名>.json），

但留档不是交付：交付 = 图已经落库（或图 JSON 已在回复里），绝不是一句「请你在条带上照着搭」。

1. 图搭好后（或应用自动落库后）由用户点条带右端的 「▶ 启用并绑定」 才真正开始跑

（启用即拍图快照，之后改图不影响在跑的这次）；交付类环节会自动在画布上生成交付节点 （该类型不能手动添加，也不必添加）；任务切换 / ＋ 新建 / 历史 run / 交付目录体检都在条带右端的 ⚙ 里。

本技能的产物只有两种：长周期任务图，或（四条判据都不沾时的）常规画布方案。 【禁止】用 <!--MTNODE-PLAN--> 计划块 / todo_write 任务清单来代替这张图 —— 那是普通会话的流程， 长任务入口不认它（宿主不会弹计划窗、也不会执行），用户看到的就是「建出来的不是状态机图，而是一份普通计划」。

交给用户前用同一份判据自检一遍，别把明显跑不动的图丢给用户：至少一个 start；除 start 外每个节点都有上游；agent 都有 goal；map 都有 overKey 且子图非空；fork 的出边至少一条带 cond；human.deliver 的清单非空。这些正是编辑器与启用时的校验口径。

MTNode 约束

• 全程用界面当前的交流语言提问（中文界面即中文）；代码、路径、标识符保持原文。
• 在「开发节点」绑定会话里由「先拷问需求」开关注入时，本技能生效期间只读：不得修改任何文件、不得改画布、不得回写开发节点的 note / devStatus / devFiles；确认达成共识后才进入正常开发流程（那时再按两段式规范回写）。
• 提问要贴着项目真实代码：先查证（第五条），再问只有用户能定的取舍——不要把「代码里写着什么」当问题问。
• 一轮问满是硬要求：不要一次只问一题拖很多轮，用户的时间比你的问题数宝贵。