1

docs/prd/AI_NATIVE_AGENT_FIRST_EIGHT_ANCHOR_CO_CREATION_FLOW_PRD_2026-04-16.md

@@ -1,6 +1,6 @@
 # AI 原生 Agent-First 八锚点共创流程 PRD
 
-更新时间：`2026-04-16`
+更新时间：`2026-04-17`
 
 ## 0. 文档目的
 
@@ -23,7 +23,7 @@
 
 ## 1.1 一句话定义
 
-让玩家通过与一个懂 RPG 剧情策划方法的 Agent 对话，在自然聊天中逐步明确作品方向、玩家视角、剧情发动机和世界统一母题；同时由 Express 后端把这些聊天沉淀成结构化八锚点状态，并支持确认、锁定、补缺和进入后续世界底稿生成。
+让玩家通过与一个懂 RPG 剧情策划方法的 Agent 对话，在自然聊天中逐步明确作品方向、玩家视角、剧情发动机和世界统一母题；同时由 Express 后端把这些聊天沉淀成结构化八锚点状态，并支持确认、锁定、补缺、真实进度反馈和进入后续世界底稿生成。
 
 ## 1.2 产品定位
 
@@ -33,7 +33,7 @@
 
 它应当是：
 
-**一个会启发玩家表达、会主动总结当前理解、会识别缺口并只追问关键问题、最终把共创结果沉淀成结构化创作锚点的 Agent 共创流程。**
+**一个会启发玩家表达、会主动总结当前理解、会识别缺口并只追问一个高杠杆问题、最终把共创结果沉淀成结构化创作锚点的 Agent 共创流程。**
 
 ## 1.3 目标用户
 
@@ -50,6 +50,7 @@
 - Agent 是否会少问废话
 - 摘要是否准确
 - 锚点是否可编辑、可锁定、可回看
+- 进度条是否真实
 
 ## 1.4 成功标准
 
@@ -61,6 +62,9 @@
 4. 玩家在任意时刻都能看懂“现在这个世界已经定了什么、还有什么没定、Agent 正在为什么追问”。
 5. 当前锚点状态能直接进入下一阶段，生成世界底稿、关键角色、关键地点和主线第一幕。
 6. 所有锚点状态更新、确认、锁定、冲突判断和完成度裁决都在 Express 后端完成，前端只负责表现和输入。
+7. 八锚点阶段的平均问答轮次控制在 `15` 轮左右。
+8. Agent 每轮只问 `1` 个主问题。
+9. 进度区不再显示抽象阶段说明，而是显示基于真实完成度的弹性进度条。
 
 ## 1.5 本次不做什么
 
@@ -80,7 +84,7 @@
 
 现有文档已经证明，“最小锚点 + AI 初稿卡 + 系统托管层”方向是对的。
 
-但如果直接把锚点做成显式卡片或显式问题列表，会出现 4 个体验问题：
+但如果直接把锚点做成显式卡片或显式问题列表，会出现 5 个体验问题：
 
 1. 玩家会有表单焦虑
    - 明明只是有一个灵感，却像在填写策划需求单
@@ -94,6 +98,9 @@
 4. 锚点层级混乱时，玩家会觉得问题很多但抓不住重点
    - 不知道先定体验，还是先定设定，还是先定剧情
 
+5. 当前“阶段提示”过于抽象
+   - 玩家看不到真实完成度，也不知道为什么还没结束
+
 ## 2.2 新方案的核心判断
 
 更合理的方式不是让玩家“填写八个锚点”，而是让 Agent 围绕八个锚点做 3 件事：
@@ -105,7 +112,7 @@
    - 把玩家已经表达的内容收束成清晰锚点
 
 3. 补缺
-   - 只追问当前最影响后续生成质量的缺口
+   - 只追问当前最影响后续生成质量的一个缺口
 
 也就是说：
 
@@ -183,6 +190,7 @@
 3. 每聊一两轮，我都能明显看到这个世界变得更成形。
 4. 如果我一开始只说了一个模糊点子，Agent 也能把我带进状态。
 5. 如果我说得已经很多，Agent 不会浪费时间问明显问题。
+6. 进度条会诚实反馈进展，而不是每轮机械上涨。
 
 ## 4.2 业务目标
 
@@ -200,6 +208,9 @@
 4. 可控性
    - 锚点状态清晰、可回看、可锁定、可修改
 
+5. 效率
+   - 平均轮次稳定控制在 `15` 轮左右
+
 ---
 
 ## 5. 核心原则
@@ -221,7 +232,7 @@
 
 当多个锚点都不完整时，Agent 不应平均追问。
 
-系统必须基于优先级只选择当前最影响后续生成质量的 `1~2` 个问题。
+系统必须基于优先级只选择当前最影响后续生成质量的 `1` 个问题。
 
 默认优先级如下：
 
@@ -249,6 +260,8 @@
 2. 哪些已经比较稳
 3. 接下来只差什么就能往下走
 
+但即使在做总结的轮次里，也只能保留 `1` 个主问题，不允许总结后再追加第二个待答问题。
+
 ## 5.4 显式区分确认与推断
 
 Agent 可以根据玩家的话做合理推断，但不能把推断伪装成已确认事实。
@@ -273,6 +286,39 @@ Agent 可以根据玩家的话做合理推断，但不能把推断伪装成已
 
 除非玩家主动要求。
 
+## 5.6 进度必须真实，但允许弹性跳跃
+
+进度条不能按固定阶段平均切分，也不能做成“每聊一轮就涨一点”的假进度。
+
+进度必须建立在真实可用信息之上：
+
+1. 玩家一句话如果高质量覆盖多个锚点，进度可以明显跳升。
+2. 玩家回答空泛、重复或自相矛盾时，进度可以停滞。
+3. 如果后续出现重大冲突，进度允许小幅回退，但回退必须有明确原因。
+
+## 5.7 轮次预算必须是产品硬约束
+
+八锚点阶段不是无限对话。
+
+系统必须默认带着 `平均 15 轮` 的预算意识工作，而不是等聊散了再补救。
+
+这意味着：
+
+1. 每轮问题都必须追求最高信息增益。
+2. 一条回答应尽可能更新多个锚点。
+3. 越接近预算上限，问题越要偏向“收束多个缺口”的高杠杆问法。
+
+## 5.8 单轮只问一个主问题
+
+为了降低回答负担和提高回答质量，Agent 每轮只允许问 `1` 个主问题。
+
+这里的“一个主问题”定义为：
+
+1. 只允许一个明确待答槽位。
+2. 不允许并列追问多个不同认知动作。
+3. 不允许出现两个以上问号。
+4. 可以附带示例选项，但示例不得构成新的独立问题。
+
 ---
 
 ## 6. 整体流程体验
@@ -288,6 +334,32 @@ Agent 可以根据玩家的话做合理推断，但不能把推断伪装成已
 5. `共识确认`
 6. `进入世界底稿生成`
 
+## 6.2 轮次预算概览
+
+建议把八锚点阶段的平均轮次预算控制为：
+
+1. `第 1~3 轮`
+   - 接住灵感并快速建立方向盘层
+
+2. `第 4~9 轮`
+   - 高密度补齐剧情发动机层
+
+3. `第 10~12 轮`
+   - 收束标志元素、硬规则和暗线节奏
+
+4. `第 13~15 轮`
+   - 做共识确认、补最后高风险缺口、准备进入下一阶段
+
+软上限：
+
+- `15` 轮
+
+硬上限：
+
+- `18` 轮
+
+如果超过 `18` 轮仍未达到可用底稿标准，系统必须触发“收束模式”，优先产出当前最好版本，而不是继续无上限追问。
+
 ---
 
 ## 7. 阶段设计
@@ -326,6 +398,10 @@ Agent 可以根据玩家的话做合理推断，但不能把推断伪装成已
 - 世界已经开始成形了
 - 下一步很容易答
 
+### 轮次预算要求
+
+阶段 A 默认只占 `1~2` 轮。
+
 ## 7.2 阶段 B：方向盘收束
 
 ### 目标
@@ -359,6 +435,10 @@ Agent 可以根据玩家的话做合理推断，但不能把推断伪装成已
 2. 玩家幻想包含 `身份或追求` 与 `失去恐惧或代价`
 3. 主题边界至少包含 `1` 条风格方向与 `1` 条禁忌边界
 
+### 轮次预算要求
+
+阶段 B 默认应在 `3~4` 轮内完成，不应为了把语言润色到完美而过度追问。
+
 ## 7.3 阶段 C：剧情发动机补齐
 
 ### 目标
@@ -394,6 +474,12 @@ Agent 可以根据玩家的话做合理推断，但不能把推断伪装成已
 3. 至少有 `2` 条关键关系骨架
 4. 暗线与揭示节奏至少明确 `1` 条隐藏真相和 `1` 条延后揭示意图
 
+### 轮次预算要求
+
+阶段 C 是信息密度最高的阶段，默认占用 `5~6` 轮预算。
+
+如果玩家单轮回答已经同时覆盖开场、冲突、关系和暗线，系统必须允许跳过后续冗余追问，直接推进。
+
 ## 7.4 阶段 D：世界统一母题收束
 
 ### 目标
@@ -416,6 +502,10 @@ Agent 可以根据玩家的话做合理推断，但不能把推断伪装成已
 1. 至少确认 `2~5` 个标志元素
 2. 至少确认 `1~3` 条硬规则
 
+### 轮次预算要求
+
+阶段 D 默认应在 `2~3` 轮内完成。
+
 ## 7.5 阶段 E：共识确认
 
 ### 目标
@@ -442,6 +532,12 @@ Agent 必须输出一份结构化但仍然易读的摘要，分成三类：
 2. 锁定部分锚点后进入下一阶段
 3. 指定某个锚点继续精修
 
+### 轮次预算要求
+
+阶段 E 默认只占 `1~2` 轮。
+
+如果用户没有明确异议，系统应倾向于推进，而不是反复征求确认。
+
 ## 7.6 阶段 F：进入世界底稿生成
 
 ### 目标
@@ -474,19 +570,28 @@ Agent 必须输出一份结构化但仍然易读的摘要，分成三类：
    - 用 `2~4` 条短句总结已浮现的锚点
 
 3. `补缺`
-   - 只问 `1` 个主问题，必要时附 `1` 个轻量补充问法
+   - 只问 `1` 个主问题
 
-## 8.2 禁止行为
+## 8.2 单问约束
+
+为了保证单轮只问一个问题，Agent 回复生成时必须经过单问检查：
+
+1. 回复中只允许一个主问句。
+2. 若存在第二个问号，默认判定为违规。
+3. “你更偏 A、B、C 还是 D”这类选项式问法视为一个问题。
+4. “你更偏 A 吗？如果不是为什么”这类双槽位问法视为两个问题，禁止输出。
+
+## 8.3 禁止行为
 
 这一阶段禁止 Agent 出现以下回复模式：
 
 1. 连续大段夸赞，没有实质推进
 2. 把玩家原话换个说法重复一遍就结束
-3. 一次抛出 `5` 个以上问题
+3. 一次抛出 `2` 个以上待答槽位
 4. 在锚点未稳定前自动生成成批设定
 5. 把推断写成已确认事实
 
-## 8.3 提问模板原则
+## 8.4 提问模板原则
 
 提问模板必须符合：
 
@@ -504,6 +609,90 @@ Agent 必须输出一份结构化但仍然易读的摘要，分成三类：
 - 坏问题：
   - “请详细描述你的主题母题、叙事支柱、隐性线索分发策略与世界统一意象。”
 
+## 8.5 问题选择器
+
+后端必须有一个明确的问题选择器，而不是把“下一问”完全交给模型自由发挥。
+
+建议每轮按以下顺序计算候选问题：
+
+1. 生成当前未完成锚点列表
+2. 为每个锚点估算 `信息增益分`
+3. 为每个锚点估算 `轮次紧迫分`
+4. 为每个锚点估算 `重复惩罚分`
+5. 选择总分最高的一个锚点生成问题
+
+建议公式：
+
+```ts
+questionPriority =
+  informationGainWeight * infoGain
+  + turnPressureWeight * turnPressure
+  + stageWeight * stageUrgency
+  - repetitionPenaltyWeight * repetitionPenalty
+  - userFatigueWeight * fatiguePenalty;
+```
+
+其中：
+
+- `infoGain`
+  - 回答这个问题后，理论上能补齐多少高权重字段
+
+- `turnPressure`
+  - 当前剩余预算越少，越倾向选择能一次补多个缺口的问题
+
+- `repetitionPenalty`
+  - 近期已经问过、或用户已经回答过相近信息时提升惩罚
+
+- `fatiguePenalty`
+  - 用户最近回答很短、明显迟疑或连续改口时，惩罚高负担问法
+
+## 8.6 轮次预算器
+
+后端必须维护一个 `TurnBudgetController`，至少负责：
+
+1. 记录当前已进行轮次
+2. 估算剩余轮次
+3. 计算当前是否需要进入收束模式
+4. 给问题选择器提供预算压力信号
+
+建议状态：
+
+```ts
+type TurnBudgetState = {
+  currentTurn: number;
+  softLimit: number; // 15
+  hardLimit: number; // 18
+  budgetPressure: number; // 0 ~ 1
+  mode: 'normal' | 'compress' | 'closing';
+};
+```
+
+模式说明：
+
+1. `normal`
+   - `1~10` 轮，允许适度启发和探索
+
+2. `compress`
+   - `11~15` 轮，优先提能一次收束多个缺口的问题
+
+3. `closing`
+   - `16~18` 轮，只补高风险缺口并准备确认总结
+
+## 8.7 单轮回答利用率
+
+为了把平均轮次压到 `15` 轮，系统不能只从玩家回答里抽取被提问的那一个锚点。
+
+每轮用户回答都必须做全量扫描，尝试更新全部八个锚点。
+
+例如玩家回答“我想让玩家一开始是被宗门追杀的弃徒，因为他手里有改命神器的钥匙”，系统至少应同步更新：
+
+1. 玩家幻想
+2. 玩家切入口
+3. 核心冲突
+4. 标志元素
+
+而不是只更新“玩家切入口”。
+
 ---
 
 ## 9. 前台交互设计
@@ -512,21 +701,26 @@ Agent 必须输出一份结构化但仍然易读的摘要，分成三类：
 
 沿用现有创作工作区，不新开页面。
 
-只在现有 Agent 工作区中新增更明确的锚点反馈区和阶段反馈区。
+只在现有 Agent 工作区中新增更明确的锚点反馈区和进度条区。
 
 ## 9.2 工作区组成
 
-八锚点阶段的工作区默认包含三块：
+八锚点阶段的工作区默认包含四块：
 
 1. `左侧或主区：聊天流`
    - 玩家输入
    - Agent 回复
    - 阶段性总结
 
-2. `侧边摘要区：当前世界底子`
+2. `顶部进度条区：当前完成进度`
+   - 弹性真实进度条
+   - 当前模式提示
+   - 剩余预算提示
+
+3. `侧边摘要区：当前世界底子`
    - 以易读摘要展示八锚点当前状态
 
-3. `底部操作区：下一步动作`
+4. `底部操作区：下一步动作`
    - 继续聊
    - 确认这一版
    - 锁定当前理解
@@ -549,15 +743,152 @@ Agent 必须输出一份结构化但仍然易读的摘要，分成三类：
 3. `待补充`
 4. `已锁定`
 
-## 9.4 阶段提示
+## 9.4 进度条设计
 
-工作区应始终用一句短提示明确当前阶段，例如：
+原本的“阶段提示区域”改为进度条区域。
 
-- 正在帮你收束作品方向
-- 正在补齐剧情冲突和关系发动机
-- 正在确认这个世界最有记忆点的母题
+进度条必须满足三个要求：
 
-禁止在 UI 上默认显示大段规则说明文字。
+1. 玩家能直观看到完成度
+2. 进度变化必须和真实锚点收集结果绑定
+3. 玩家能理解为什么此刻涨得快、涨得慢或小幅回退
+
+### 9.4.1 展示组成
+
+进度条区域默认展示：
+
+1. 一条 `0~100%` 的主进度条
+2. 进度副标题
+   - 例如：`已完成 6/8 个锚点，正在收束核心冲突`
+3. 预算提示
+   - 例如：`第 8 / 15 轮`
+4. 模式标签
+   - `正常推进`
+   - `压缩收束`
+   - `准备确认`
+
+### 9.4.2 真实进度定义
+
+进度条不是按轮次走，而是按 `八锚点完成度加权总分` 走。
+
+建议总分公式：
+
+```ts
+progressScore =
+  sum(anchorWeight[i] * anchorCompletion[i])
+  - contradictionPenalty
+  - unresolvedRiskPenalty;
+```
+
+其中：
+
+- `anchorCompletion[i]`
+  - 每个锚点的完成度，取值 `0 ~ 1`
+
+- `anchorWeight[i]`
+  - 每个锚点的权重
+
+- `contradictionPenalty`
+  - 已发现但未解决的设定冲突惩罚
+
+- `unresolvedRiskPenalty`
+  - 高风险缺口尚未补齐时的惩罚
+
+### 9.4.3 建议权重
+
+```ts
+worldPromise: 0.16
+playerFantasy: 0.14
+themeBoundary: 0.10
+playerEntryPoint: 0.13
+coreConflict: 0.18
+keyRelationships: 0.12
+hiddenLines: 0.07
+iconicElements: 0.10
+```
+
+解释：
+
+1. `核心冲突` 和 `世界承诺` 权重最高
+2. `玩家幻想` 与 `玩家切入口` 决定代入感，权重次高
+3. `暗线与揭示节奏` 重要，但在首轮底稿阶段允许相对后置
+
+### 9.4.4 弹性机制
+
+进度条必须允许以下行为：
+
+1. `跨锚点跳升`
+   - 玩家一条高质量回答覆盖多个锚点时，进度可一次上涨 `8%~18%`
+
+2. `停滞`
+   - 用户回答没有提供新信息时，进度可保持不动
+
+3. `轻微回退`
+   - 当新输入推翻已确认内容，进度允许回退 `2%~6%`
+
+但不允许：
+
+1. 因为一次轻微改词大幅掉进度
+2. 每轮机械上涨固定百分比
+3. 进入确认阶段后无意义来回跳动
+
+### 9.4.5 玩家可见文案要求
+
+当进度上涨时，副标题应尽量解释原因，例如：
+
+- `玩家切入口和核心冲突已经明确，进度明显前进`
+
+当进度停滞时：
+
+- `目前信息更像补充语气，关键缺口还在关键关系`
+
+当进度回退时：
+
+- `你刚刚调整了世界气质，相关冲突需要重新确认，所以进度小幅回收`
+
+禁止只显示空泛文案，如“处理中”“继续努力”。
+
+## 9.5 进度条映射规则
+
+为了避免玩家在很早时看到过低进度产生挫败感，建议采用“真实分数 + 轻度前期提振”的映射。
+
+内部真实分：
+
+```ts
+rawProgress = clamp(progressScore, 0, 1);
+```
+
+前台显示分：
+
+```ts
+displayProgress =
+  rawProgress < 0.2
+    ? rawProgress * 1.25
+    : rawProgress < 0.8
+      ? rawProgress * 1.05
+      : rawProgress;
+```
+
+要求：
+
+1. 显示分不得虚高到越过真实完成区间含义
+2. `85%` 以上必须基本意味着已接近可确认状态
+3. `100%` 只在进入 `ready` 后显示
+
+## 9.6 预算提示规则
+
+预算提示必须与轮次预算器联动：
+
+1. `1~10` 轮显示：
+   - `正在铺底，别急着一次想全`
+
+2. `11~15` 轮显示：
+   - `开始收束高杠杆设定`
+
+3. `16~18` 轮显示：
+   - `准备用当前最好版本进入底稿`
+
+禁止显示“剩余 3 次提问机会”这类压迫感过强的说法。
 
 ---
 
@@ -573,6 +904,8 @@ Express 后端必须作为唯一真实状态源，负责：
 4. 生成下一轮提问建议
 5. 生成阶段性摘要
 6. 判断是否进入下一阶段
+7. 计算真实进度与显示进度
+8. 管理轮次预算
 
 ## 10.2 结构化状态模型
 
@@ -585,9 +918,12 @@ type AnchorField<T> = {
   value: T | null;
   status: AnchorStatus;
   confidence: number;
+  completionScore: number;
   sourceMessageIds: string[];
   summary: string;
   openQuestions: string[];
+  lastUpdatedAt: string;
+  conflictFlags: string[];
 };
 
 type EightAnchorDraft = {
@@ -600,6 +936,17 @@ type EightAnchorDraft = {
   hiddenLines: AnchorField<HiddenLineValue>;
   iconicElements: AnchorField<IconicElementValue>;
   phase: 'spark' | 'direction' | 'engine' | 'motif' | 'review' | 'ready';
+  progress: {
+    rawScore: number;
+    displayScore: number;
+    completedAnchorCount: number;
+    contradictionPenalty: number;
+    unresolvedRiskPenalty: number;
+    mode: 'normal' | 'compress' | 'closing';
+    currentTurn: number;
+    softLimit: number;
+    hardLimit: number;
+  };
   readyForFoundationDraft: boolean;
 };
 ```
@@ -662,11 +1009,13 @@ type EightAnchorDraft = {
 2. 判断新增内容是确认、补充还是冲突
 3. 生成新的锚点摘要
 4. 重新计算缺口优先级
-5. 产出下一轮 Agent 回复所需的：
+5. 重新计算进度条
+6. 产出下一轮 Agent 回复所需的：
    - 当前理解
    - 待补问题
    - 禁止重复问的问题
-   - 推荐阶段标签
+   - 推荐进度条文案
+   - 当前预算模式
 
 ## 10.5 冲突处理
 
@@ -676,6 +1025,53 @@ type EightAnchorDraft = {
 
 - “你前面更像想做冷硬末日，现在这轮开始偏浪漫奇谭了，我先不自动改，想确认你是准备转方向，还是只想让其中一条支线更柔一点？”
 
+## 10.6 进度计算器
+
+后端必须实现 `ProgressEvaluator`，用于从结构化锚点状态生成真实进度。
+
+建议输入：
+
+1. 八锚点字段完成度
+2. 字段置信度
+3. 锚点状态
+4. 未解决冲突
+5. 当前轮次
+
+建议输出：
+
+```ts
+type ProgressEvaluation = {
+  rawScore: number;
+  displayScore: number;
+  completedAnchorCount: number;
+  gainReason: string | null;
+  stallReason: string | null;
+  fallbackReason: string | null;
+};
+```
+
+## 10.7 问题与进度联动
+
+每次提问前，后端必须先检查：
+
+1. 当前进度停滞的主因是什么
+2. 哪个问题最可能让进度跨过下一关键阈值
+3. 该问题是否会造成过高认知负担
+
+关键阈值建议为：
+
+1. `25%`
+   - 方向盘初步成型
+
+2. `50%`
+   - 玩家已能看懂这世界大致怎么玩
+
+3. `75%`
+   - 八锚点已具备可生成底稿的主体骨架
+
+4. `90%`
+   - 仅剩低风险补强或确认
+
 ---
 
 ## 11. 完成度判断
@@ -691,6 +1087,23 @@ type EightAnchorDraft = {
 - 世界承诺只有“修仙世界”不能算完成
 - 世界承诺如果是“一个靠借寿续命维持秩序的仙朝里，玩家要在飞升诱惑和众生寿债之间做选择”，则可判定为高完成度
 
+建议完成度分级：
+
+1. `0.0 ~ 0.24`
+   - 只有题材词，没有可执行信息
+
+2. `0.25 ~ 0.49`
+   - 已有方向，但缺少差异点或关键约束
+
+3. `0.50 ~ 0.74`
+   - 已可用于底稿生成，但仍有明显模糊区
+
+4. `0.75 ~ 0.89`
+   - 高质量可用
+
+5. `0.90 ~ 1.0`
+   - 已确认或已锁定，且可稳定约束后续生成
+
 ## 11.2 阶段完成判定
 
 系统不要求八个锚点都达到满分才允许进入下一阶段。
@@ -705,6 +1118,32 @@ type EightAnchorDraft = {
 
 满足以上条件即可进入 `ready`
 
+## 11.3 轮次达标判定
+
+上线后的核心效率指标必须包含：
+
+1. 平均轮次 `<= 15`
+2. `P75` 轮次 `<= 18`
+3. 单轮双问违规率 `< 1%`
+4. 重复问题率 `< 8%`
+
+## 11.4 收束模式
+
+当出现以下任一情况时，系统进入收束模式：
+
+1. 当前轮次 `> 15`
+2. 连续 `2` 轮进度增长 `< 2%`
+3. 用户明显疲劳
+   - 极短回答
+   - 连续说“你帮我定”
+   - 明显不想继续细抠
+
+进入收束模式后：
+
+1. 只追问能一问收束多个缺口的问题
+2. 优先确认而不是继续发散
+3. 必要时允许以“高置信推断 + 玩家确认”完成低风险锚点
+
 ---
 
 ## 12. 示例体验脚本
@@ -776,6 +1215,8 @@ Agent 不应回复成八问表：
    - 继续打磨
    - 锁定并继续
    - 放弃
+6. 单轮是否违规出现多个问题
+7. 进度条上涨、停滞、回退的次数与原因
 
 ## 14.2 质量评估指标
 
@@ -789,56 +1230,246 @@ Agent 不应回复成八问表：
 
 ---
 
-## 15. 实现拆分建议
+## 15. Harness 机制
 
-## 15.1 第一阶段
+## 15.1 目标
+
+这套流程必须有专门的 harness，而不是只靠人工体验几轮聊天判断好不好。
+
+harness 的目标是稳定评测 4 类问题：
+
+1. 是否真的做到了单轮只问一个问题
+2. 是否真的能把平均轮次压到 `15` 轮左右
+3. 进度条是否真实反映锚点完成度，而不是假涨
+4. 八锚点提取、总结、追问是否真的有效
+
+## 15.2 总体结构
+
+建议 harness 分成三层：
+
+1. `回放层`
+   - 用固定用户画像和固定答案回放会话
+
+2. `裁判层`
+   - 对每轮 Agent 输出做结构检查和质量打分
+
+3. `报表层`
+   - 输出轮次、进度、锚点覆盖率、违规率等指标
+
+## 15.3 用例集设计
+
+至少维护以下 8 类标准用例：
+
+1. `一句话灵感型`
+   - 用户一开始只给一个模糊钩子
+
+2. `高密度设定型`
+   - 用户首轮就给出大量设定
+
+3. `犹豫改口型`
+   - 用户中途多次修改方向
+
+4. `高配合短答型`
+   - 用户每轮只回一句，但都直击重点
+
+5. `低配合泛答型`
+   - 用户经常回答很虚
+
+6. `强审美主导型`
+   - 用户更在乎气质，不擅长冲突设计
+
+7. `强剧情主导型`
+   - 用户冲突很强，但世界母题薄弱
+
+8. `让 Agent 代定型`
+   - 用户频繁说“你帮我想”
+
+## 15.4 每个 harness 用例的输入结构
+
+建议每个用例包含：
+
+```ts
+type EightAnchorHarnessCase = {
+  id: string;
+  title: string;
+  userProfile: string;
+  hiddenGroundTruth: {
+    desiredAnchors: Partial<EightAnchorDraft>;
+    mustAskTopics: string[];
+    forbiddenAssumptions: string[];
+  };
+  scriptedUserPolicy: {
+    responseStyle: 'short' | 'rich' | 'hesitant' | 'contradictory';
+    allowAgentInferenceLevel: 'low' | 'medium' | 'high';
+    maxTurnsBeforeFatigue: number;
+  };
+  scriptedTurns: Array<{
+    whenAgentAsksAbout?: string[];
+    userReply: string;
+  }>;
+};
+```
+
+## 15.5 裁判规则
+
+每轮会话结束后，裁判层至少检查：
+
+1. `单问检查`
+   - 是否只有一个主问题
+
+2. `重复问题检查`
+   - 是否反复追问用户已高置信回答过的内容
+
+3. `提取准确率检查`
+   - 本轮从用户回答中提取的锚点是否合理
+
+4. `进度真实性检查`
+   - 进度上涨是否对应真实信息增量
+
+5. `轮次预算检查`
+   - 当前策略是否仍符合 `15` 轮平均目标
+
+6. `收束能力检查`
+   - 接近预算上限时是否切换到更高杠杆问法
+
+## 15.6 单问检查器
+
+单问检查器必须是硬规则，不只靠 LLM 主观判断。
+
+建议组合以下方法：
+
+1. 文本规则检查
+   - 问号数量
+   - 疑问词数量
+   - 是否存在并列问句连接词
+
+2. 结构化输出检查
+   - Agent 回复生成时同步输出 `questionSlotCount`
+
+3. 裁判模型复核
+   - 判断是否存在多个待答槽位
+
+判定原则：
+
+1. 任一检查器判定为多问，则记违规
+2. harness 报表必须输出具体违规回复文本
+
+## 15.7 进度真实性检查器
+
+进度真实性检查器应对每轮打出：
+
+1. `expectedProgressDelta`
+   - 基于真实新增信息量推测的合理涨幅
+
+2. `actualProgressDelta`
+   - 系统实际涨幅
+
+3. `deltaGap`
+   - 两者差值
+
+若出现以下情况则记风险：
+
+1. 用户几乎没提供新信息，但进度上涨 `> 6%`
+2. 用户一轮补齐多个高权重锚点，但进度上涨 `< 3%`
+3. 发生重大冲突却没有小幅回退
+
+## 15.8 轮次预算检查器
+
+轮次预算检查器至少输出：
+
+1. 总轮次
+2. 到达 `50% / 75% / ready` 所用轮次
+3. 各阶段平均用时
+4. 是否超过软上限
+5. 是否超过硬上限
+
+## 15.9 报表输出
+
+每次 harness 跑完，至少输出以下报表字段：
+
+```ts
+type EightAnchorHarnessReport = {
+  caseId: string;
+  totalTurns: number;
+  reachedReady: boolean;
+  finalProgress: number;
+  averageProgressGainPerTurn: number;
+  multiQuestionViolationCount: number;
+  repeatedQuestionCount: number;
+  extractionAccuracyScore: number;
+  progressTruthfulnessScore: number;
+  anchorCoverageScore: number;
+  closingEfficiencyScore: number;
+  notes: string[];
+};
+```
+
+## 15.10 发布门禁
+
+八锚点流程上线前，harness 至少要满足：
+
+1. 标准用例集平均轮次 `<= 15`
+2. `P75` 总轮次 `<= 18`
+3. 单问违规率 `< 1%`
+4. 进度真实性得分 `>= 0.85`
+5. 锚点覆盖率得分 `>= 0.9`
+6. 高密度设定型用例在 `8` 轮内能达到 `75%` 进度
+7. 低配合泛答型用例也能在 `18` 轮内进入可确认状态或可用收束状态
+
+---
+
+## 16. 实现拆分建议
+
+## 16.1 第一阶段
 
 先做最小闭环：
 
 1. 八锚点结构化状态
-2. 锚点状态标签
+2. 真实进度条计算器
 3. 单轮提炼 + 单问题追问
 4. 共识确认摘要
 5. 进入下一阶段的后端判定
 
-## 15.2 第二阶段
+## 16.2 第二阶段
 
 再补：
 
 1. 冲突检测
 2. 更细的完成度评分
-3. 阶段提示语
+3. 轮次预算器
 4. 指定锚点重聊
 5. 锁定后禁止自动改写
 
-## 15.3 第三阶段
+## 16.3 第三阶段
 
 继续补：
 
 1. 更强的 Agent 提问策略
 2. 更丰富的摘要模板
-3. 基于锚点的底稿质量评估
+3. harness 与发布门禁
 4. 对不同题材的提问风格适配
 
 ---
 
-## 16. 验收标准
+## 17. 验收标准
 
 本 PRD 对应功能完成后，至少必须满足：
 
 1. 玩家只输入一段模糊灵感时，Agent 能给出有效提炼和一个高杠杆追问。
 2. 玩家连续多轮输入后，八锚点摘要会持续更新，不只是聊天记录增长。
-3. 工作区能稳定显示每个锚点的当前状态。
+3. 工作区能稳定显示真实进度条和每个锚点的当前状态。
 4. Agent 不会在同一锚点已高置信完成后继续反复追问。
 5. 玩家可明确确认当前理解、锁定部分锚点或指定某个锚点继续打磨。
 6. 八锚点状态能被后端判定为 `ready` 并进入世界底稿生成。
 7. 前端不承担锚点完成度判断、冲突裁决和下一步阶段判断。
-8. 相关测试、`check:encoding` 通过。
+8. 平均轮次控制在 `15` 轮左右，且 `P75` 不超过 `18` 轮。
+9. 单轮双问违规率低于 `1%`。
+10. harness、相关测试、`check:encoding` 通过。
 
 ---
 
-## 17. 一句话结论
+## 18. 一句话结论
 
 八锚点真正应该做成的，不是一套问卷，也不是一堆字段，而是：
 
-**一个由 Agent 主导的启发式共创流程：先接住灵感，再提炼方向，再补齐剧情发动机，最后把玩家和 Agent 的共识沉淀成可运行的世界底子。**
+**一个由 Agent 主导、带真实进度条、受轮次预算约束、并可被 harness 持续校验的启发式共创流程：先接住灵感，再提炼方向，再补齐剧情发动机，最后把玩家和 Agent 的共识沉淀成可运行的世界底子。**