修复策划智能体提示词边界与资源引用

恢复顾问态不自主推进、不安排下一步和不提交阶段审批的约束恢复过程文档轻量记录原则并明确审批与问询的职责边界补回顶层设计的排除方向及星露谷示例定位统一星露谷分析示例的五处旧路径引用同步策划专题文档与团队共享约定
2026-09-20 16:40:42 +08:00
parent 97d8a6c39a
commit 4358a3f7e0
12 changed files with 25 additions and 16 deletions
@@ -1,4 +1,3 @@
-顾问阶段遵照用户的具体指示行动。
+顾问阶段遵照用户的具体指示行动，不自主推进项目或主动安排下一步，不提交阶段审批。
 根据用户指示回答问题、读取相关文档、修改工作区文件，并说明改动可能影响的已有产物。
 涉及方向性变化或多个可行方案时，先向用户说明影响并等待用户决定。
-顾问阶段以完成用户当前请求并汇报结果为结束点。
@@ -3,7 +3,7 @@
 版本：v3　|　规则：台账放活队列——design 只放结论、分析只放论证、决定与开放问题住这里。编号连续不复用；被推翻的行标 overturned 挂新行，不删行。
 状态六态：`confirmed`（用户亲口/亲选）/ `auto_decided`（技术类代决，必带理由＋推翻条件，用户一键可翻）/ `default_pending`（默认建议兜底，用户未点头）/ `prototype_pending`（待原型验证）/ `pending_user`（等用户拍板）/ `overturned`（被推翻，挂旧行编号）。

-> 编号口径：D-01~D-13 与 exemplars/stardew-analysis.md 台账节选一致（D-04~D-06、D-08~D-10、D-12 原为"就地小权衡，直接登记未开条目"，此处按登记口径展开）；D-14 起为技术文档期新增，与 stardew-tdd-tech.md 开放问题回执互引。
+> 编号口径：D-01~D-13 与 templates/stardew-analysis.md 台账节选一致（D-04~D-06、D-08~D-10、D-12 原为"就地小权衡，直接登记未开条目"，此处按登记口径展开）；D-14 起为技术文档期新增，与 stardew-tdd-tech.md 开放问题回执互引。

 ## 当前待办（活队列）

@@ -1,7 +1,7 @@
 # 顶层设计：《星露谷物语》

 ## 顶层定位与规模锚点
-顶层设计让玩家每天都在想：
+顶层不是做长线农场生产线，也不是做以探索战斗为主的活动清单，而是让玩家每天都在想：
 > "今天做什么？——下雨天不用浇水，正好下矿井；回来的路上把罗宾的生日礼物送了。"

 | 项 | 定义 |
@@ -5,7 +5,7 @@ name: game-gdd-architecture
 description: 写游戏策划案（GDD）系统架构时使用。在顶层设计定稿之后，
  把顶层的系统范围表正式切成 Sxx 系统：编号、职责、依赖、数据流、优先级，
  并向系统文档站交付目录映射与 MVP 闭环。配套：templates/architecture.md、
-  templates/analysis.md（全局一份）、exemplars/stardew-architecture.md、exemplars/stardew-analysis.md（全局一份）。
+  templates/analysis.md（全局一份）、exemplars/stardew-architecture.md、templates/stardew-analysis.md（全局一份）。
 ---

 # 系统架构写法（策划 agent · 系统架构分册）
@@ -5,7 +5,7 @@ name: game-gdd-concept
 description: 写游戏策划案（GDD）概念层时使用。把一句话游戏想法写成一份
  "一次写对、之后不动"的立项概念文档——它是后续所有设计争议的仲裁依据。
  任何游戏类型通用。配套：templates/concept-design.md、templates/analysis.md（全局一份）、
-  exemplars/stardew-concept.md、exemplars/stardew-analysis.md（全局一份）。
+  exemplars/stardew-concept.md、templates/stardew-analysis.md（全局一份）。
 ---

 # 概念层写法（策划 agent · 概念层分册）
@@ -5,7 +5,7 @@ name: game-gdd-top-design
 description: 写游戏策划案（GDD）顶层设计时使用。在概念层定稿之后，
  回答"玩家为什么一直玩"——把概念变成可玩的时间结构（循环/资源/取舍/节奏），
  并向架构层交付系统范围。配套：templates/top-design.md、templates/analysis.md（全局一份）、
-  exemplars/stardew-top-design.md、exemplars/stardew-analysis.md（全局一份）。
+  exemplars/stardew-top-design.md、templates/stardew-analysis.md（全局一份）。
 ---

 # 顶层设计写法（策划 agent · 顶层设计分册）
@@ -45,7 +45,7 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定

 | # | 节 | 是什么 | 为什么写 | 和谁咬合 |
 |---|---|---|---|---|
-| 1 | 顶层定位与规模锚点 | 承概念定稿 + "让玩家每天都在想"念头句 + 规模参数表（循环单位/段落/复杂度/长期主轴） | 循环单位定错全盘错；定位句防止顶层漂离概念 | 承概念层"概念定稿"；念头句是概念层玩家念头的时间维度版 |
+| 1 | 顶层定位与规模锚点 | 承概念定稿 + 按需说明易混淆方向及排除理由 + "让玩家每天都在想"念头句 + 规模参数表（循环单位/段落/复杂度/长期主轴） | 循环单位定错全盘错；定位句防止顶层漂离概念 | 承概念层"概念定稿"；念头句是概念层玩家念头的时间维度版 |
 | 2 | 设计目标 | 几种回报、如何互相供给 | 回报并列=小游戏拼盘；互相供给才是循环 | 供给关系落到 4~5 的循环里 |
 | 3 | 核心推动力 | 按项目实际存在的即时、阶段或长期推动力组织 | 玩家"什么时候被什么推着走"的推动结构 | 与实际节奏结构对应 |
 | 4 | 大循环 | 跨较长时间的循环：文字箭头 + 核心循环图 | 长期留存的结构骨架 | 与 5、7 三层互检：大循环的每环应有小循环供血 |
@@ -88,6 +88,7 @@ description: 写游戏策划案（GDD）顶层设计时使用。在概念层定
 （本节是带写法要领的教学版；实际填写的纯净模板在 templates/top-design.md）

 ### 1. 顶层定位与规模锚点
+承接概念定稿说明核心定位；存在容易混淆的方向时，说明排除方向及理由，表述按项目需要组织。
 顶层设计让玩家每天都在想：
 > "__（玩家每天惦记的那件事）"
 规模锚点表：循环单位 / 段落构成 / 操作复杂度 / 经营复杂度 / 长期主轴排序。
@@ -1,4 +1,4 @@
-### C1 例子_星露谷_分析.md（分析金样；→ exemplars/stardew-analysis.md）
+### C1 例子_星露谷_分析.md（分析金样；→ templates/stardew-analysis.md）

 # 分析：《星露谷物语》

@@ -5,6 +5,9 @@
 # 顶层设计：《游戏名》

 ## 顶层定位与规模锚点
+核心定位：__。
+容易混淆的方向及排除理由（按需）：__。
+
 顶层设计让玩家每天都在想：
 > "__"

@@ -7,12 +7,12 @@

 正式策划文档在文档头部写明版本标记，例如“版本：v1”。由你自行维护版本号：只有整体修订、阶段性定稿或用户意见造成实质内容变化时才递增；错别字、措辞润色、单个局部修改和小范围补充不单独递增。

-阶段审批是每个阶段的最终检查，将已完成的本阶段产物交给用户检阅。提交前，解决所有影响本阶段完成的关键问题，或明确说明它们不阻塞本阶段交付，并更新相关产物。可以保留不阻塞当前阶段的后续事项和待原型验证项。
+阶段审批是五个策划阶段各自的最终检查，将已完成的本阶段产物交给用户检阅。需要用户选择的关键问题先通过问询解决，阶段审批不承担问询功能。提交前，解决所有影响本阶段完成的关键问题，或明确说明它们不阻塞本阶段交付，并更新相关产物。可以保留不阻塞当前阶段的后续事项和待原型验证项。

-过程文档用于记录关键依据、决定和待办。阶段内优先完成主要设计内容；只有稳定且影响后续工作的决定才需要同步到多个过程文档。阶段提交前，补齐影响验收的关键记录。
+过程文档用于记录关键依据、决定和待办，不要求实时完整，也不应重复正式设计文档。阶段内优先完成主要设计内容；只有稳定且影响后续工作的决定才需要同步到多个过程文档。阶段提交前，补齐影响验收的关键记录。

 阶段获批后，产物中已经采用的方案作为后续工作的依据，并保留原有决策来源。用户主动质疑或出现新的约束冲突时，再重新讨论相关决定。

-用户说“继续”时，继续推进当前阶段最有价值的工作。判断本阶段已完成并准备交用户检阅时，应调用 `submit_phase_for_approval`；只有该工具调用成功，才算正式提交审批。
+用户说“继续”时，继续推进当前阶段最有价值的工作。在五个策划阶段中，判断本阶段已完成并准备交用户检阅时，应调用 `submit_phase_for_approval`；只有该工具调用成功，才算正式提交审批。

 用户口头表示已经批准或要求进入下一阶段时，先调用 `get_workflow_status` 确认 Runtime 当前阶段。只有用户批准正式审批请求后，Runtime 才会推进阶段；审批工具是推进阶段的唯一方式。
@@ -9,5 +9,5 @@
  {"type":"function","function":{"name":"write_file","description":"创建或覆盖工作目录内的 UTF-8 文本文件。path 使用相对路径。","parameters":{"type":"object","properties":{"path":{"type":"string"},"content":{"type":"string"}},"required":["path","content"],"additionalProperties":false}}},
  {"type":"function","function":{"name":"search_text","description":"在工作目录内搜索文本。","parameters":{"type":"object","properties":{"query":{"type":"string"},"path":{"type":"string"}},"required":["query"],"additionalProperties":false}}},
  {"type":"function","function":{"name":"ask_clarification","description":"向用户展示多选项问询澄清卡片，选项数2-4。多选一场景时优先使用本工具，其他场景可以纯文本进行问询。每轮最多调用一次。","parameters":{"type":"object","properties":{"question":{"type":"string"},"options":{"type":"array","items":{"type":"string"}}},"required":["question"],"additionalProperties":false}}},
-  {"type":"function","function":{"name":"submit_phase_for_approval","description":"提交当前策划阶段供用户审批。当你判断当前阶段已经完成并准备交用户检阅时必须调用。用户批准后 Runtime 自动进入下一阶段。","parameters":{"type":"object","properties":{},"additionalProperties":false}}}
+  {"type":"function","function":{"name":"submit_phase_for_approval","description":"提交五个策划阶段中的当前阶段供用户审批。当你判断当前阶段已经完成并准备交用户检阅时必须调用。用户批准后 Runtime 自动进入下一阶段。","parameters":{"type":"object","properties":{},"additionalProperties":false}}}
 ]
@@ -18,6 +18,8 @@

 - Agent 提示词正文与工具说明放在所属组件的 `prompts/`；AGC 通过现有 Prompt Bundle 编译加载，服务端独立 crate 编译包含自己的提示词文件。代码负责变量填充、结构化 schema 与执行校验。

+- 策划 Agent 的顾问态由用户指示驱动，不自主推进项目、主动安排下一步或提交阶段审批；完成单次请求不结束顾问态。五个策划阶段的审批用于检阅已完成产物，关键选择先问询；过程文档按需记录且不重复正式正文。顶层设计按需保留易混淆方向及排除理由，提示词精简应保留这些行为与设计边界。详见策划 Agent 生产迁移与工作区浏览方案。
+
 - AGC 思考与执行入口共用共享单行摘要骨架；Markdown 在展开正文走既有安全渲染，折叠预览使用纯文本。耗时统一复用中文时分秒格式（不足一分钟一位小数，达到分钟后整数秒），格式化与各层计时边界分离。过程行在运行中和完成后的折叠层内保持同一紧凑间距；失败状态按明确终态与非零退出码呈现红色。

 - Direct 对话计时区分条目展示时间与生命周期事件时间：整轮用用户发送到明确终态的跨度，工具用各自开始/完成边界；运行时用 100ms 叶子时钟刷新一位小数，终态冻结，旧历史缺边界不推测。不得用整秒时间的大小比较取代 Thread Manager 的事件顺序判定新回合。
@@ -1,6 +1,6 @@
 # 策划 Agent 生产迁移与工作区浏览方案

-更新时间：2026-09-10
+更新时间：2026-09-20
 状态：已完成（2026-09-18）

 > 现状说明（2026-09-18）：本文记录的迁移已完成，当前策划入口统一使用 Design Agent。旧 Planning V1/V2 会话、专用命令、审批卡和展示适配已删除；文中提到的 V2 文件仅代表迁移时的参考来源，不得作为现行实现、回退路径或测试迁移目标。
@@ -180,6 +180,8 @@ concept → top_design → architecture → systems → tdd → consultant

 模板、范例、类型资料和没有明确要求自动注入的文档继续保持选读。必读资源缺失、为空或读取失败时，只记录诊断并继续请求 Provider，不阻断阶段推进。

+星露谷分析示例的资源路径统一为 `templates/stardew-analysis.md`，分册与示例中的引用保持一致；通过 `read_resource` 读取时使用目录登记的资源 ID `templates.stardew_analysis`。
+
 根据当前原型 `resources/catalog.json`，自动注入清单为：

 | 当前阶段 | 全文注入的资源 ID | 资源文件 |
@@ -206,13 +208,15 @@ concept → top_design → architecture → systems → tdd → consultant

 `systems: []` 是已确定的行为，不是迁移时需要补齐的缺口。`project/analysis.md`、`project/决策台账.md`、`project/dialog.md` 保持原型中的共享过程文件口径，不升级为新的审批必需项。速览卡保留原型结构提示，但 Runtime 与 UI 不解析其章节或内容字段。

+过程文档记录关键依据、决定和待办，不要求实时完整，也不应重复正式设计文档；阶段提交前补齐影响验收的关键记录。顶层设计的分册、模板和示例保留核心定位及按需说明的易混淆方向与排除理由，不强制使用固定的“不是 X，而是 Y”句式。
+
 进入下一阶段必须由用户批准触发。Runtime 推进后向 Agent 追加明确的用户行为语义，例如“用户已批准上一阶段，现在进入顶层设计阶段”，避免 Agent 误认为 Runtime 自行推进。

 ## 7. 审批与澄清交互

 ### 7.1 阶段审批

-Agent 完成当前阶段后必须调用 `submit_phase_for_approval`。普通文本中的“批准”“确认”“进入下一阶段”等内容不改变 Runtime 阶段。
+Agent 完成五个策划阶段中的当前阶段后必须调用 `submit_phase_for_approval`。需要用户选择的关键问题先通过问询解决，阶段审批用于检阅已完成的产物；可以保留不阻塞当前阶段的后续事项和待原型验证项。普通文本中的“批准”“确认”“进入下一阶段”等内容不改变 Runtime 阶段。

 提交时 Runtime 只检查：

@@ -234,7 +238,7 @@ UI 使用“批准”和“继续修改”两个文字按钮，分别配 Lucide
 - 选择“继续修改”后，再次出现新的审批请求前，不能重复批准旧请求；
 - 不实现 `/approve`、`批准`、`确认` 等文本检测。

-批准与拒绝通过带请求身份的结构化命令处理。后端只接受当前待审批请求；重复点击同一已处理请求不再次推进，旧卡不能批准新的请求。此处校验请求身份与会话状态，不对文件增加指纹、快照或内容校验。进入顾问态后不自主安排新任务。
+批准与拒绝通过带请求身份的结构化命令处理。后端只接受当前待审批请求；重复点击同一已处理请求不再次推进，旧卡不能批准新的请求。此处校验请求身份与会话状态，不对文件增加指纹、快照或内容校验。顾问阶段遵照用户的具体指示行动，不自主推进项目或主动安排下一步，不提交阶段审批；完成单次用户请求不结束顾问态。

 ### 7.2 澄清