故事纪年：让选择在多年后留下回声

它是什么

故事纪年是一套按年份推进的互动叙事系统。玩家先描述世界，再选择天赋、分配属性并作出年度选择；服务端保存每年的结构化结果，界面把它组织成可以持续阅读和继续推演的时间线。

它和“给模型一句提示词、等待一段故事”不同。系统关心的不只是下一段文字是否精彩，还要保证年龄推进、属性变化、关键人物、已有事件与后续分支能够接得上。

一次故事如何开始

1. 创建新故事并写下世界描述。
2. 选择天赋与初始属性，确认开局。
3. 阅读当年事件，在有限选项中作出选择。
4. 查看属性与关系变化，继续下一年。
5. 从存档恢复、回看时间线，或在关键节点探索另一条分支。

界面把“当前阶段”和主要前进行动放在同一视觉层级。移动端仍维持世界、天赋、属性、年度推演的顺序，不依赖桌面宽度才能理解流程。

服务如何协作

浏览器（Next.js）
  │  世界设定、选择、存档与时间线
  ▼
Webhome API 边界
  │  统一账号、输入校验、请求转发
  ▼
Storysim（Go）
  ├─ Writer：生成本年候选叙事
  ├─ Extractor：提取结构化事件与属性变化
  ├─ Prefetch：预取下一步候选，降低等待感
  └─ Store：保存世界、年份、选择与分支

Writer 和 Extractor 使用同一套 Provider 边界，但职责不同：前者负责表达，后者把表达收敛为后续推演可消费的数据。前端只通过 Webhome 的同源 API 访问 Storysim，内部服务地址不会暴露给浏览器。

关键设计取舍

时间线先于聊天记录

产品的核心对象是“年份”，不是“消息”。每年拥有选择、叙事、结构化事件和状态变化，因此可以按时间阅读，也能为恢复与分支提供稳定锚点。

分支必须保留来路

探索另一条选择时，系统不会覆写原有故事。新分支记录它来自哪个年份与哪个决策点，使用户能回到原时间线，也使后续调试可以回答“这段结果从哪里开始不同”。

预取不能越过一致性边界

预取用于减少下一步等待，但最终提交仍以用户实际选择和当前世界版本为准。过期的候选结果不能覆盖新选择，模型失败也不能伪装成已经保存的年份。

账号只在需要保存时出现

作品介绍保持公开；创建、恢复和管理故事时才进入账号边界。这样访客可以先理解作品如何运作，再决定是否投入一次完整体验。

作品证明了什么

• 将长程叙事拆成可持久化、可恢复的年度状态。
• 让多个 LLM 职责共享 Provider，同时保持生成与提取边界。
• 用分支来路、世界版本与结构化事件约束“记忆”。
• 在桌面与移动端维持同一任务顺序、反馈与错误恢复路径。

当前边界

故事纪年优先打磨单个世界的长期一致性与阅读体验。它不是通用写作平台，也不把模型输出当作不可修改的事实；所有可继续推演的信息都必须先落到明确的数据结构中。