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

恢复顾问态不自主推进、不安排下一步和不提交阶段审批的约束恢复过程文档轻量记录原则并明确审批与问询的职责边界补回顶层设计的排除方向及星露谷示例定位统一星露谷分析示例的五处旧路径引用同步策划专题文档与团队共享约定 Reviewed-on: #433 Co-authored-by: Linghong <ink29535@proton.me> Co-committed-by: Linghong <ink29535@proton.me>
2026-09-20 18:07:37 +08:00
parent 288e1d4f4a
commit 4864e92e30
28 changed files with 6166 additions and 6030 deletions
@@ -95,6 +95,14 @@ Rust 侧在 `server-rs/crates/shared-contracts` 维护唯一权威 `GameCreation

 客户端平台服务固定为 dev，登录页不提供服务器选择。凭据按 origin 隔离迁移；官网下载入口汇总最新渠道清单，自动展示已有首装包的 Windows/Mac 平台及架构。完整合同见 [AGC 客户端更新检查与下载](./【技术方案】AGC客户端更新检查与下载-2026-08-31.md) 的“官网下载与客户端服务地址”。

+## Agent 提示词与回合测试边界
+
+预览快捷操作的 UI 回归按独立命令及必要的连续操作拆分，每例使用新的项目 fixture、invoke mock 和页面，项目打开后再采样副作用调用计数。保留命令输出、草稿填入、焦点、权限确认和原生参数断言；预览启停、快照回滚取消、导出确认与取消作为各自短流程验证，使用默认测试超时。定向运行 `npx vitest run apps/ai-game-creator-shell/tests/appSurface.test.ts -t "预览快捷操作："`。
+
+提示词拼装测试核对动态错误、外置片段和实际 Provider 请求结构，避免绑定可自由润色的中文原句。源码载荷限制由实际动作校验与 Provider 修复测试覆盖；工具参数自动修复和超预算上下文压缩继续验证恢复结果、状态及私有信息隔离。Direct 消息原样转发复用生产请求转换测试，文件变化与版本幂等直接测试生产文件投影函数，删除测试专用的重复回合编排。
+
+Rust 分片日志在失败时输出有界 stdout 尾部中的失败段，保留 panic 位置、断言详情和 Rust 汇总；selected 只表示该分片选中的用例数量。成功分片保留简短摘要。定向验证使用相关 Rust 用例与 `node --test apps/ai-game-creator-shell/scripts/run-rust-shell-test-shards.test.mjs`。
+
 ## 策划 Agent 批量局部修改

 `patch_file` 的所有 edits 均匹配同一份原文件，参数顺序不影响结果。完成唯一匹配与不重叠校验后，按原文起点升序拼接未修改片段与替换文本，最后一次性写入；任一校验失败时不写文件。回归用例覆盖乱序 edits、中文内容与替换长度增减，并核对完整落盘内容。此行为仅属于策划 Agent 文件工具。
@@ -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 澄清