补充策划问询不对称设计说明

明确模型侧 3 轮策略与 Runtime 侧 8 个问题门禁的分层语义补充自动评测和代码评审口径，说明两者有意不对称
2026-09-05 07:07:31 +00:00
parent eabd8f393a
commit 861ed14a6f
2 changed files with 18 additions and 0 deletions
@@ -15,6 +15,13 @@
 - 关联文档：相关 PRD、技术文档、提交或 Issue
 ```

+## 2026-09-05 Planning V2 的 3 轮策略与 8 个问题门禁有意不对称
+
+- 决策：模型提示最多提问 3 轮，并在达到 3 后要求出稿；Runtime `question_limit` 默认 8，对偏离模型策略的合法问题保留接收空间，达到 8 才拒绝新 question。前者是模型行为指令，后者是运行时接收边界，数值有意不同，不是缺陷或配置不一致。
+- 评审口径：Session/UI 的 8 是容量，不是必须问满的配额；正常路径在 3 轮或更早出稿符合设计。不得仅因数值不同，把模型提示改为按 `question_limit` 出稿、把 3 改成可继续到 8 的软目标，或把 Runtime 门禁收紧为 3。
+- 影响范围：仅补充文档解释，现有提示词、运行逻辑、校验和测试保持不变。
+- 关联文档：[策划会话 Runtime V2 接入与旧链路退役方案 §1.3](../../technical/【技术方案】策划会话RuntimeV2接入与旧链路退役-2026-09-03.md#13-问询策略与-runtime-门禁的不对称设计)。
+
 ## 2026-09-04 Planning V2 将决定 ID 从 Provider 输入移回 Runtime

 - 背景：`plan_submit_gdd` 原先要求模型生成 `decisions[].id` 及原型验证项引用 ID。该字段既不是方案内容，又容易出现 `initial_request`、`initialRequest` 或错误层级，导致合法 GDD 在 Runtime 事后校验阶段失败。
@@ -49,6 +49,17 @@ V2 复用底层能力，但不复用旧策划编排身份：
 - 本次不保证未完成旧会话继续运行、继续问询或继续审批；切换后它们只能查看历史记录。
 - 本次不把 V2 做成 Python 子进程；生产实现仍在 AGC 客户端 Rust/Tauri 侧。

+### 1.3 问询策略与 Runtime 门禁的不对称设计
+
+**模型提示最多 3 轮、Runtime `question_limit` 默认 8，是明确的分层设计，不是缺陷、bug、配置漂移或校验遗漏。** 两个数值约束不同层面的行为，不要求统一成单一配置来源。
+
+- **模型侧策略为最多 3 轮**：提示词明确要求 `question_count >= 3` 时整理已有信息并调用 `plan_submit_gdd`；信息足够时允许 0～2 轮提前出稿。第 3 轮后的出稿指令是有意的策略约束，不是应当放宽为“必要时继续问到 8 轮”的软目标。
+- **Runtime 侧门禁为最多 8 个有效问题**：`question_limit=8` 表示运行时最多接受并展示多少个问题。模型偏离 3 轮策略、继续返回 question 时，Runtime 不因超过 3 而直接拒绝；仍按现有格式和业务门禁判断，达到 8 后才拒绝新的 question。这是对模型输出保留的容忍空间。
+- **Session/UI 中的 8 表示容量，不是配额或出稿前置条件**：不承诺正常路径会问满 8 轮，也不要求模型必须能够按当前提示一路问到第 8 轮。按策略在 3 轮或更早生成 GDD，是正常行为；不能仅凭未问满 8 轮推断 GDD 质量不足。
+- **评审与自动评测口径**：应分别核对模型是否收到 3 轮收敛指令、Runtime 是否按 `question_limit` 执行门禁。两者数值不同本身不构成问题；不得据此把提示词改成由 `session.question_limit` 决定何时出稿，也不得把 Runtime 门禁收紧到 3。`questionCount=3` 的提示要求出稿与 Runtime 仍可接受合法 question 可以同时成立；`questionCount=8` 时 Runtime 拒绝新 question。
+
+以上说明解释现有实现，不修改提示词、条件分支、默认值、校验或测试逻辑。
+
 ## 2. 当前生产链路与迁移原因

 当前“做方案”生产路径是旧 Supervisor 链路：