Files
Genarrative/docs
lhk229 0abdc41c3c M1C-2c 收口:分隔符集合补全角冒号,并钉住 label 与回答的同尺比对
分隔符集合原本只有 `·`/`:`/`-`。prompt 全中文、实测用的是 DeepSeek 系模型,在中文
语境下写 `A:方案名` 是高频输出;漏掉全角冒号的后果不是判错,而是合法信封被判形状
错误、回灌重试,白吃一个未推进回合预算——而第 23.9 节自己就记着无界重试把单次
prompt 撑到 15 万 token 的实测。

- PLAN_OPTION_LABEL_DELIMITERS 补 `:`;prompt 的 label 说明与技术方案 §5.1、§5.2、
  §23.9 三处分隔符合同同步改口,避免两侧各写一份
- 回归 planning_clarification_accepts_fullwidth_colon_option_labels。变异验证:
  去掉 `:` 后该用例立刻红

另外收回一条误报。此前判断「答案走 normalize_plan_text 被 trim、label 是信封原文没
trim,模型吐带尾随空白的 label 会让用户点选 A/B 掉进自由填写分支、台账记成
user_freeform」。写完测试做变异验证时把改动回退,用例照样绿;查下去发现
user_input.rs 的 normalize_single_line_user_input_text 在信封严格解析时就已经 trim
过 label(并拒掉含换行的 label)。两边本来就是同一把尺子,不对称不存在。

- 生产侧只把比较抽成具名函数并在原地写清它依赖的是解析侧那条 trim,不做多余的重复
  规范化——那会把一个不存在的风险写进代码
- 保留 planning_clarification_option_pick_survives_untrimmed_label,它钉的是上游那条
  不变量:解析侧哪天不 trim 了,这条会红
- 测试脚手架加 *_with_labels 变体,让用例能注入自定义 label;原有 helper 转为薄包装

planning_clarification_ 16/0、plan_ 160/0、recovery 107/0,fmt 干净。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 06:15:25 +00:00
..
2026-07-17 21:03:15 +08:00
2026-08-15 11:43:58 +08:00

文档总览

docs/ 只把当前融合文档和仍在维护的专题文档作为实现依据。旧创作模板、旧创作入口及其专属服务文档仅保留为历史材料,不再要求继续实现或兼容。

必读入口

  1. Agent 工作入口与执行准则
  2. 当前产品与工程约束
  3. server-rs 与 SpacetimeDB 数据契约
  4. 平台入口与玩法链路
  5. 本地开发验证与生产运维
  6. AI 游戏创作项目开发工作台 PRD
  7. AI 游戏创作智能体 App 实施计划
  8. 客户端素材创作无限画布阶段一合同

团队长期约定、决策、流程和排障摘要统一从 项目记忆入口 读取。代码、当前融合文档与项目记忆冲突时,以代码和最新融合文档为准。

当前专题

AI 游戏创作与 Agent Runtime

图片编辑器与 Agent

后端与公开数据

后台、宿主壳与运维

测试与协作

历史文档边界

  • 旧创作模板、旧创作入口、旧运行态和旧素材生成方案不再从本页索引,也不再作为修复目标。
  • maincloud、旧 Node/Express/PostgreSQL/Go 后端和人工 spacetime --root-dir 口径均已废弃。
  • 历史文档不得覆盖当前融合文档、代码契约或 docs/project-memory/shared-memory/decision-log.md 中更新的决策。

命名规则

后续新增 Markdown 文档文件名使用 【标签名】中文标题-日期.md。历史文件不做无关批量重命名;本次涉及的旧文档可直接删除或在当前入口中取消引用。