放宽策划V2修订续跑合同

允许审批修改后的 continuation 继续问询或直接提交完整 GDD 明确继承已确认问答与问询计数且不新增意图识别调用
2026-09-06 09:49:14 +00:00
parent 49d814fec1
commit 7d54aa6552
2 changed files with 3 additions and 3 deletions
@@ -793,7 +793,7 @@ fn planning_v2_system_prompt(session: &PlanningSessionV2) -> String {
    // 问询策略只是偏好，两者不要求数值一致。这里仅传当前已展示数，
    // 达到硬上限时再明确禁止本次继续提问。
    format!(
-        "你是立项策划 Agent。当前会话 {}，回合 {}。{}\n\n每轮必须且只能调用一个工具：问询用 plan_ask_question，出稿用 plan_submit_gdd。不要在正文输出 JSON、Markdown、解释或代码围栏。\n\n除非用户明确要求直接出稿，否则先进行关键设计澄清。\n整个会话最多提问 3 轮。\n3 轮是上限，不是配额；信息已经足够时允许 0～2 轮提前出稿。\n达到第 3 轮或信息足够时，整理当前信息并调用 plan_submit_gdd。\n每轮收到用户回答后重新选择最重要的下一个未决决定，不要重复已回答的问题。\n提问优先顺序：核心行为与本局目标 → 重玩动力 → 制作边界与 MVP。\n主题包装、美术、数值和次要系统可以用 assumption_pending，answerSource 记为 agent_inferred。修改以最新用户意见为准，提交完整 GDD，不要打补丁。",
+        "你是立项策划 Agent。当前会话 {}，回合 {}。{}\n\n每轮必须且只能调用一个工具：问询用 plan_ask_question，出稿用 plan_submit_gdd。不要在正文输出 JSON、Markdown、解释或代码围栏。\n\n除非用户明确要求直接出稿，否则先进行关键设计澄清。\n整个会话最多提问 3 轮。\n3 轮是上限，不是配额；信息已经足够时允许 0～2 轮提前出稿。\n达到第 3 轮或信息足够时，整理当前信息并调用 plan_submit_gdd。\n审批修改后的续跑沿用本协议：可以继续问询，也可以直接提交新的完整 GDD；已确认问答和问询计数不重置。\n每轮收到用户回答后重新选择最重要的下一个未决决定，不要重复已回答的问题。\n提问优先顺序：核心行为与本局目标 → 重玩动力 → 制作边界与 MVP。\n主题包装、美术、数值和次要系统可以用 assumption_pending，answerSource 记为 agent_inferred。修改以最新用户意见为准，提交完整 GDD，不要打补丁。",
        session.session_id,
        session.turn_index,
        planning_v2_question_policy(session),
@@ -9,7 +9,7 @@

 当前普通完整构建会从简短需求直接进入 `autonomous-game-build`，用户在消耗完整构建成本前没有正式确认玩法方向、MVP 范围和原型验证项的环节。现有完整构建中的 `design-director` 是只读协调任务，`design-foundation` 又会自行补齐玩法定位；用户意图与后续实现之间缺少可版本化、可审批、可恢复的策划基线。

-本方案新增“立项策划”阶段：用户给出一句需求后，由 Project Supervisor 顶层 root run 通过 `agent.delegate` 发起一个独立 `agentId` 的静态委派子 Agent（`agentId=project-planning`；2026-08-13 起取代原“下游工作流节点由 manifest ready-task 调度器启动”的表述，见第 1.1 节「D11 新拓扑」与 D11），在最多 3 轮决策卡内形成 Fast GDD（该 3 轮上限依赖 WP1——静态委派澄清轮次与返工深度拆分——先落地，见第 1.1 节；落地前实际上限仍是 1 轮）；Runtime 校验并提交不可变版本，用户通过审批卡批准、修改或退回。只有不可变 GDD 与对应 approve receipt 同时有效时，后续完整构建才能取得 `approvedGddRef`。
+本方案新增“立项策划”阶段：用户给出一句需求后，由 Project Supervisor 顶层 root run 通过 `agent.delegate` 发起一个独立 `agentId` 的静态委派子 Agent（`agentId=project-planning`；2026-08-13 起取代原“下游工作流节点由 manifest ready-task 调度器启动”的表述，见第 1.1 节「D11 新拓扑」与 D11），在最多 3 轮决策卡内形成 Fast GDD（该 3 轮上限依赖 WP1——静态委派澄清轮次与返工深度拆分——先落地，见第 1.1 节；落地前实际上限仍是 1 轮）；Runtime 校验并提交不可变版本，用户通过审批卡批准、修改或退回。审批修改后的 continuation 沿用普通 Planning V2 回合协议，Provider 可以继续问询，也可以直接提交新的完整 GDD；既有问询计数和已确认问答继承，不因修改重置。只有不可变 GDD 与对应 approve receipt 同时有效时，后续完整构建才能取得 `approvedGddRef`。

 目标：

@@ -389,7 +389,7 @@ Runtime 注入并强校验以下精确结构：

 ### 5.1 对话循环

- 最多 3 轮主动追问，每轮只问 1 个主要决定。
+- 最多 3 轮主动追问，每轮只问 1 个主要决定；审批修改后的 continuation 仍沿用同一问询预算，可以继续问询或直接提交新的完整 GDD，问询计数不重置。
 - 建议顺序：核心行为与本局目标 → 重玩动力 → 制作边界与 MVP。
 - 满足任一条件即出稿：用户明确说“直接出稿”；已经完成第 3 轮；剩余问题不影响首个可玩闭环；Runtime 注入 240 秒 Agent 活跃时间软提示。
 - `accumulatedAgentMillis` 只累计 Provider 活跃区间，不包含等待用户、等待审批、进程休眠或应用关闭时间。