提问预算收回给策划子 Agent，Supervisor 不再自撰提问门槛
首轮委派 task 由 Supervisor 自由撰写，实测它每次都把提问条件写成一个高门槛： 「若确有缺少且会实质改变结果的用户事实……否则直接创建并提交完整 GDD」。本机 13 个生产 project 里 8 个是 0 轮直出，CLI 同参基线 8 个 run 也有 3 个 0 轮、 均值 0.75 轮、无一顶满 3 轮预算。 病根是提问门槛这件事同时写在两个地方而且口径相反：plan/common.md 告诉 Supervisor「专业 Agent 若缺少会实质改变结果的用户事实才提问」，Supervisor 照抄 进 task；而子 Agent 的 role brief 只写了 3 轮上限，没写默认姿态、没有判断该不该 问的程序、也没有它自己两次引用的那份「默认建议」清单到底是什么。 按原型的做法收口——两边各一份闭集白名单，不给「可以无视 task」的授权： - roles/project-planning.md：出稿触发器收成四个（任务正文出现「直接出稿」四个字 / 已完成第 3 轮 / 剩余空白能被默认建议覆盖且不影响首个可玩闭环 / Runtime 超时 提示），任务正文能改变流程的只有第一条。Supervisor 写的门槛不在其中，自然不是 触发器，不需要授权无视。补上字段差距检测（逐项对照 plan-submit-gdd-input.v1 的 game 字段三分类，提问名额只花在空白项）和那份缺席的默认建议清单。 - plan/supervisor-playbook.md：本轮指令三选一（继续澄清 / 直接出稿 / 按意见修订）， 不得自撰提问条件。独立成段，因为 both_playbooks_carry_the_same_anti_pre_deciding_contract 要求共享段在两条 lane 逐字相同，并进去就得改做游戏 lane。plan/common.md 那句病根改不动（planCommon 受逐字子集断言约束，且通用 common.md 的口径对其它专业 Agent 是对的），只能覆盖。 默认建议按本仓库的 GDD schema 重排，没有照抄原型：原型的「缺成长 / 缺探索 / 缺构建」三条落到 plan-submit-gdd-input.v1 上全在 pillars 与 coreLoop，而那两个字段 就是首个可玩闭环本身，给它们配默认值等于把最该花提问预算的两项默认掉，和 「提问顺序：核心行为与本局目标 → 重玩动力」的前两顺位直接打架。故清单只覆盖 genre.fusion / artStyle / targetUsers / outOfScope，并明写 pillars 与 coreLoop 没有默认建议。 实测（8 vs 8，同一句开场白、同一条 --swarm-chat --plan、同一个模型、决策卡一律 选 A）：轮数均值 0.75 → 2.62，0 轮 3/8 → 0/8，顶满 3 轮 0/8 → 6/8；Supervisor 在 首轮 task 里写提问门槛 8/8 → 0/8。这会让用户明显感到问得多了，是有意的产品取舍。 补一条断言：这份 role brief 此前两次要求「按默认建议填写」却从未写出清单，就是 因为没有任何测试看着它。新断言钉住清单在场、按 schema 字段名写、pillars 与 coreLoop 被排除、出稿触发器是闭集。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
@@ -17,4 +17,6 @@
|
||||
|
||||
委派 `project-planning` 时，acceptanceCriteria 只写产物形状、覆盖范围与红线（例如必须交付 `game/fast_gdd.md`、必须原创、必须只定义一个 MVP 闭环），**不得替用户预先裁定产品取舍**。用户没有指定的玩法规则、数值、关卡量级、美术方向和目标人群，一律留给策划子 Agent 按其 3 轮问询预算决定是提问还是按默认建议填写；不要写“未指定的标注为立项假设”“自行假设后继续”这类指令，那会把问询预算作废。平台事实（自包含 Web、desktop/mobile 双视口、keyboard/touch 双输入、本地 HTTP 预览）由 Runtime 固定注入，属于已定事实，不得要求标为待定、建议或开放项。
|
||||
|
||||
**本轮指令三选一。** 委派任务正文里，除了用户原始意图和已确认答案原文，你只能再写一句“本轮该做什么”，且必须是下面三个之一：**继续澄清**（默认，不附加任何前置条件）、**直接出稿**（仅当用户明确要求跳过问询）、**按意见修订**（仅审批返回修改或退回时）。不要自己描述“什么情况下才该提问”“若缺少会实质改变结果的事实则……”“否则直接提交完整 GDD”——那不在这三项里。提问预算怎么花，由 `project-planning` 按 Runtime 注入的判据决定。
|
||||
|
||||
不要向用户暴露内部 task/event、工具计划、动态 child ID 或调试状态。
|
||||
|
||||
@@ -9,8 +9,11 @@
|
||||
|
||||
## 目标与轮次
|
||||
|
||||
- 除非用户明确说“直接出稿”，最多进行 3 轮关键澄清；每轮是新 run、同一 session。你看得到自己的历史，但用户答案以 Supervisor 委派任务中的转述为准，缺失信息不能臆造。
|
||||
- 优先顺序：核心行为与本局目标 → 重玩动力 → 制作边界与 MVP。每轮最多问一个主要决定；达到第 3 轮、剩余问题不影响首个可玩闭环或 Runtime 提示接近活跃预算时，直接整理并提交。
|
||||
- 最多进行 3 轮关键澄清；每轮是新 run、同一 session。你看得到自己的历史，但用户答案以 Supervisor 委派任务中的转述为准，缺失信息不能臆造。
|
||||
- **默认先澄清。** 出稿只有四个触发器，除此之外每轮都先做下面的字段差距检测再决定问不问：①任务正文出现“直接出稿”这四个字；②已完成第 3 轮澄清（任务正文写明的已用轮次已达上限）；③剩余空白都能由默认建议覆盖，且不影响首个可玩闭环；④收到 Runtime 的活跃预算或超时提示。任务正文能改变流程的只有第 ① 条——它写的其它说明属于内容，不是出稿触发器。既定事实（用户答案、已确认决定）仍以任务正文为准。
|
||||
- 每轮提问前逐项对照 `plan-submit-gdd-input.v1` 的 `game` 字段做差距检测：用户明确提供的 = `confirmed`；有依据可推断的 = 按下面的默认建议填写并标 `default_pending`；无从判断**且影响首个可玩闭环**的 = 空白。提问名额只花在空白项上；有默认建议兜底的字段一律先用默认建议，不占轮次。`title`、`oneLiner`、`mvpSystems`、`creatorTips` 由你生成并标 `default_pending`，不作为提问对象；`platformFacts` 禁问。
|
||||
- **默认建议**（一律 `answerSource=default`、`round=0`；只用于缩短对话，不覆盖用户明确输入）：`genre.fusion` 缺 → `null`，MVP 不做融合第二类型；`artStyle` 缺 → `visualType` 风格化、轮廓清楚，`keywords` 取自已确认的核心行为，`mvpArtBoundary` 写明 MVP 用占位资产、资产可复用；`targetUsers.sessionLength` 缺 → 10～20 分钟一局；`targetUsers.coreUsers` / `preferences` 缺 → 按已确认的类型与核心行为写典型玩家，不得编造人群规模、销量或市场数据；`targetUsers.referenceGames` 缺 → 空数组；`outOfScope` 缺 → 多人、商城、服务器、开放世界、赛季、复杂社交、完整剧情、全量内容。**`pillars` 与 `coreLoop` 没有默认建议**：它们就是首个可玩闭环本身，空白时属于该问的空白，不得用默认值填掉。
|
||||
- 优先顺序：核心行为与本局目标 → 重玩动力 → 制作边界与 MVP。每轮最多问一个主要决定。
|
||||
- 决策卡的 header 固定为“第N轮·关键决定”，其中 N 是 Runtime 从委派谱系派生的当前轮号，必须精确相等，写错会被 Runtime 拒收：首轮恒为 1；之后每次续跑的任务正文都会写明已用轮次与上限，本轮该用的 N 就是“已用轮次 + 1”。正文以“当前要决定：”开头，只问尚未由平台事实或 MVP 规则排除的真实产品取舍，并说明为什么现在问；每张卡固定提供三个选项：A 是你的推荐方案（label 以 `A ·`、`A:`、`A：` 或 `A-` 开头并写明推荐、好处和代价），B 是形状不同且真实可行的平行备选（label 以 `B ·`、`B:`、`B：` 或 `B-` 开头并写明后果和代价），第三项逐字为“需要原型验证”，description 必须给出 30～90 分钟微型原型、试玩对象、观察信号和通过标准。自由输入按用户原话处理。
|
||||
|
||||
## 低幻觉与 GDD 约束
|
||||
|
||||
@@ -1019,6 +1019,50 @@ mod tests {
|
||||
);
|
||||
}
|
||||
|
||||
/// 这份 role brief 早先两次要求子 Agent「按默认建议填写」，却从未写出默认建议
|
||||
/// 是什么——引用了一份不存在的清单，而没有任何断言看着它。这条钉三件事。
|
||||
///
|
||||
/// 一、清单在场，且逐条按 `plan-submit-gdd-input.v1` 的字段名写，改 schema 时
|
||||
/// 这条会跟着红。
|
||||
///
|
||||
/// 二、`pillars` / `coreLoop` 明确排除在清单外：它们就是首个可玩闭环本身，
|
||||
/// 给它们配默认值等于把最该花提问预算的那两项默认掉。原型那份清单里的
|
||||
/// 成长 / 探索 / 构建三条落到本仓库的 schema 上正好落在这两个字段上，照抄
|
||||
/// 会和「提问顺序：核心行为与本局目标 → 重玩动力」的前两顺位直接打架。
|
||||
///
|
||||
/// 三、出稿触发器是闭集。生产实测过 Supervisor 会把「若缺少会实质改变结果的
|
||||
/// 事实才提问，否则直接提交」写进委派 task，子 Agent 照办后 0 轮出稿；这里
|
||||
/// 不给「可以无视 task」的授权，改为钉住触发器只有四个——Supervisor 写的门槛
|
||||
/// 不在其中，自然不是触发器。
|
||||
#[test]
|
||||
fn project_planning_default_suggestions_exist_and_spare_the_core_loop() {
|
||||
let planning = game_creator_agent_runtime_role_overlay_prompt(
|
||||
GAME_CREATOR_PROJECT_PLANNING_AGENT_ID,
|
||||
None,
|
||||
);
|
||||
assert!(
|
||||
planning.contains("**默认建议**"),
|
||||
"role brief 三处引用「默认建议」，清单本身必须在场"
|
||||
);
|
||||
for field in [
|
||||
"`genre.fusion`",
|
||||
"`artStyle`",
|
||||
"`targetUsers.sessionLength`",
|
||||
"`targetUsers.referenceGames`",
|
||||
"`outOfScope`",
|
||||
] {
|
||||
assert!(planning.contains(field), "默认建议清单缺少字段 {field}");
|
||||
}
|
||||
assert!(
|
||||
planning.contains("**`pillars` 与 `coreLoop` 没有默认建议**"),
|
||||
"pillars / coreLoop 不得进默认建议清单"
|
||||
);
|
||||
assert!(
|
||||
planning.contains("出稿只有四个触发器"),
|
||||
"出稿触发器必须是闭集，否则委派 task 里的任意措辞都能当触发器"
|
||||
);
|
||||
}
|
||||
|
||||
#[test]
|
||||
fn project_planning_prompt_advertises_submit_gdd_contract() {
|
||||
let prompt = game_creator_agent_runtime_tool_plan_system_prompt_for_agent(
|
||||
|
||||
Reference in New Issue
Block a user