life-sim-template

背景与边界

本 skill 是 world_simulator 的第一个"场景模板"（对应方案 2.4 节），
服务两类场景：

1. 决策推演分析：用户给出当前处境 + 候选选择，模拟未来走向，
   辅助对比。
2. 持续性人生模拟：从一个起点持续推进，形成一条可以回看的时间线。

被 generate_scenario workflow 挂载时，你只做"生成初始状态"这一件事；
被 advance_step workflow 挂载时，你只做"推进一步"这一件事——两者的
result_file 契约不同，见下方两节，不要混淆。

关于"推进一步"可能被拆成两次调用（阶段三十三第八批，4.12 节
第三步，manifest.settings.split_decision_calls == True 时生效，
默认关闭）：这种情况下你不会被 advance_step workflow 挂载，而是
被 world_evolve 和 decision_generate 两个 workflow 分别挂载
两次——两者的 prompt 已经在各自的 yaml 里清楚说明了"这次调用只负责
什么、不要输出什么"（world_evolve 只产出世界状态变化，不产出
options；decision_generate 只产出候选选项，next_vars/
narrative 等世界状态字段已经由上一次调用决定，不需要你重新生成）。
下面"推进一步（advance_step）"这一节里描述的所有字段规则/正反例
仍然完全适用，只是被拆成了两次调用各自负责其中一部分字段，不需要
在这份 SKILL.md 里额外区分——world_evolve/decision_generate.yaml
的 prompt 已经明确告诉你这次调用该输出哪些字段、不该输出哪些。

关于"创建初始状态"可能被拆成两次调用（第五轮方案 5.5 节，阶段
三十四第六批，manifest.settings.split_creation_calls == True 时
生效，默认开启）：这种情况下你不会被 generate_scenario workflow
挂载，而是被 world_builder 和 causal_space_builder 两个 workflow
分别挂载两次——world_builder 只产出世界状态本身（title/
summary/vars/时间粒度等），不产出候选行动/因果线；
causal_space_builder 把前一次的世界状态当既成事实，只产出
options/causal_lines/declared_causal_graph，不重新生成
title/summary/vars。下面"生成初始状态（generate_scenario）"
这一节里描述的所有字段规则/正反例仍然完全适用，只是被拆成了两次
调用各自负责其中一部分字段，不需要在这份 SKILL.md 里额外区分——
world_builder/causal_space_builder.yaml 的 prompt 已经明确告诉
你这次调用该输出哪些字段、不该输出哪些。

通用判断原则

1. 不要越界替用户做决定：除非上游明确给出"代理决策"的画像/原则
   （advance_step prompt 里的 decision_context 非空），否则你只负责
   给出候选选项和对应后果，不擅自替用户选。

2. 变量要具体、可追踪：vars 里的字段应该是"这个人生模拟里真实
   存在、会随时间变化"的量（年龄、存款、健康、职业阶段、人际关系状态
   等），不要塞入大段自由文本描述当变量值。

3. 叙事克制、有代入感，但不夸张：narrative 是几句话的情节推进
   文本，不是小说章节，服务"看得懂发生了什么"，不是文学创作比赛。

4. 候选选项数量是判断出来的结果，不是要凑够的目标值：
   {option_count_hint} 只是一个软上限（防止候选列表刷屏），不是
   "请生成这么多个"。先判断这一步是否真的走到了需要主体做选择的
   分岔点——没有就给空数组；只有一个真正有效的方向就只给一个；多个
   方向有实质区分度（不同代价/不同风险/不同路线）才都列出来；理论
   上能想到的方向很多但彼此差异很小时，优先合并成"有意义的决策
   前沿"，而不是罗列一堆大同小异的选项凑数，也不要为了不超软上限
   而硬砍掉一个仍有实质意义的方向。

   候选选项必须是现实世界里可以理解、可以执行的具体行动/路线/决策，
   不能是抽象的内部指标调节。本模板（人生模拟）的正反例：

   • 正例："转向 AI 相关岗位"（职业线的具体行动路线）、"卖掉部分
     股票增加现金储备"（财务线的具体行动）、"接受降薪换稳定"（现实
     可执行的取舍）；
   • 反例："提升职业竞争力 20%""增加收入 15%""财务健康度 +0.1"——
     这些是内部数值语义，不是用户能理解、能执行的现实行动，即使
     选中后确实会引起这些数值变化，也不能把数值本身写成选项内容。

   如果这一步的关键变化是主角无法直接干预的宏观事件（行业震荡、
   宏观经济衰退、政策突变等），不要把宏观事件本身包装成选项——先在
   narrative/next_vars 里如实呈现这个宏观变化，再沿因果链往下想
   "这件事最终影响到主角自己能采取行动的地方是什么"，把候选选项落在
   主角真正能施加影响的位置（例如"全球经济衰退"不直接变成选项，但
   "调整职业风险""增加现金储备"可以）。

   当且仅当"不作为"是这一步的一个真实后果分支（不选会带来和"选了
   某个选项"同样值得说明的后果，比如机会窗口关闭）时，才显式给出一项
   id 以 continue_ 开头的"维持现状"选项并说明"维持现状会怎样"；
   不是每一步都要有的机械项。

5. 大环境是活的，不是静止背景板：真实人生不是只有主角一个人在
   做选择——经济周期、行业/技术发展（比如 AI 浪潮改变某个岗位的
   含金量）、就业市场松紧、政策法规变化、社会观念/舆论风气变化等
   "主角控制不了、但真实影响他处境"的宏观因素，应该随时间自己演化，
   不能因为主角做了什么选择就停止变化，也不能从头到尾一成不变。
   vars 里建议单列一个 macro_environment 字段跟踪这部分（见下）；
   narrative/选项设计里要让这些宏观变化实际影响到主角的处境和
   选择后果，而不只是背景装饰性的一句话。

6. 时间粒度可以是"自动/引导"的，不要以为一次模拟只有一种粒度：
   每一步对应多长的模拟内时间，由用户设置的 {time_granularity_hint}
   决定，具体分三种模式（文案里会写明是哪一种）：

   • 固定模式：明确给了一个值（比如"1 个月"），每一步都严格照做，
     不要不管设置成什么都按"过了一年"来写——这种模式下不会出现"切换
     粒度"的情况。
   • 自动/引导模式：允许你按情境自行判断每一步的粒度，且同一次
     模拟里可以出现多种粒度——比如日常推进用"1 年"一步，进入一场
     关键谈判/冲突时可以临时切到"一轮"或"1 周"一步，谈判结束后再切
     回日常粒度。默认延续上一步用过的粒度（advance_step 场景里会
     告诉你上一步用的是什么），只有情境明显需要时才切换，不要没理由
     来回跳；引导模式下额外有一句用户给的偏好/基准，仅供参考，不是
     必须严格遵守的精确值。
     变量变化幅度、叙事节奏都要按"这一步实际用的粒度"换算，time_label/
     next_time_granularity 字段（见下）就是对这个粒度的具体落实。

作为 generate_scenario 挂载时（result_file: scenario.json）

输入：{intent}（用户一句话意图）、{previous_draft_json}（此前一轮
草稿，可能为空字符串）、{feedback}（用户对上一份草稿的补充意见，可能
为空字符串）、{option_count_hint}（用户设置的候选方向数量，比如
"4 个左右"）、{time_granularity_hint}（用户设置的时间粒度，比如
"1 个月"/"1 年"/"自动——由你根据模拟对象的性质自行判断"）。feedback
非空表示这是一次"根据意见修改"请求：以 previous_draft_json 为基础
按意见调整，未提及的部分（包括未被要求改动的 options 条目，尽量连
id 一起）保持不变；feedback 为空则忽略 previous_draft_json，按
intent 从零生成。

输出（合法 JSON，顶层字段）：

• title：字符串，这次模拟的简短标题。
• summary：字符串，初始状态一句话摘要。
• vars：对象，初始状态的结构化变量（字段自定，需具体可追踪，见上）。
  建议至少包含：age（年龄，整数或字符串区间）、stage（当前人生
  阶段/身份，字符串）、resources（资源状况，字符串或子对象）、
  key_relationships（关键人际关系，字符串数组）、macro_environment
  （宏观环境现状，字符串或子对象——只写和这个模拟意图相关的部分即可，
  比如"AI 行业处于快速发展期，就业市场对相关技能需求旺盛，但泡沫化
  风险也在讨论中"这种一两句话的描述，不用面面俱到覆盖经济/社会/技术
  所有维度）。
• options：数组，按 {option_count_hint} 给出对应数量的初始候选
  方向，每项含 id（短英文/拼音标识）、label（几个字的选项名）、
  description（一两句话说明这个方向意味着什么）。若用户意图里已经
  明确给出了几个候选选择，直接对应展开成这几项（数量可以不等于
  {option_count_hint}）；若没有，你需要合理生成对应数量、方向明显
  不同的选项，不要为了凑数给出实质等价的假选项。
• time_label：字符串（可选），初始状态对应的模拟内时间点，一般
  就是 起点；如果意图里明确给出了具体时间起点（比如"从 2020 年
  开始"），可以写成对应的描述。
• time_granularity：字符串（可选，{time_granularity_hint} 为
  "固定模式"时可以不写，引擎会用设置里的固定值），这次模拟的起始
  基准粒度（比如"1 年"/"1 个月"）——只需要给一个能代表"日常节奏"
  的值，不用考虑中途可能出现的特殊情境，那部分由 advance_step 逐步
  判断是否需要切换。
• resource_fields：数组（可选），vars 里属于"资源类数值"的字段
  声明（比如现金存款这类"不应该低于某个下限、后续会被消耗/增减"的
  数值），每项是字段名字符串（如 "resources.cash"，默认下限 0）或
  {"field": "resources.cash", "min": 0}。之后每一步 advance_step
  推进时，引擎会自动检查这些字段有没有被算成负数（不用你在
  advance_step 阶段自己操心这件事）。没有这类字段就不用输出。
• resource_relations：数组（可选），vars 里两个资源字段之间明显
  存在的因果关系。必须先判断这两个字段是不是同一种量纲/记账单位，
  再决定用哪种 type：
  • "transfer"（转移）：只用于同一种量纲之间的搬运——一个字段
    减少的量大致等于另一个字段增加的量，本质是同一个数换了个记账
    位置（比如"花现金买库存"：花掉的现金和库存账面价值上涨的量是
    同一种东西）。每项是 {"type": "transfer", "from": "resources.cash", "to": "resources.inventory", "tolerance": 0.1}
    （tolerance 可省略，默认 0.1，即允许 10% 的合理偏差）。之后每一步
    advance_step 推进时，引擎会自动检查这两个字段的变化量是否大致
    相反。如果两个字段量纲不同（比如"花的现金"和"体能指数涨幅"、
    "投入的时间"和"技能等级"），不要用 transfer——它们之间不存在
    "变化量之和≈0"这种零和关系，套用 transfer 会被引擎误判成"不
    一致"，这不是数值算错，是类型选错了。
  • "conversion"（有代价的跨量纲转化）：一种资源消耗、换来另一种
    不同量纲的东西涨跌，比如花钱健身（现金 → 体能）、花时间学习
    换技能（时间 → 技能等级）、花体力换收入（体力 → 现金）。每项是
    {"type": "conversion", "from": "resources.cash", "to": "health.physical_fitness", "note": "花钱健身"}（note 可选，
    一句话说明换算的现实依据）。这个类型不会被引擎做任何数值核对，
    只是记录"这两个字段之间存在因果转化关系"，用于展示。
    没有这类明显的转移/转化关系就不用输出，不要为了填这个字段而牵强
    配对字段；已经确定是同一量纲的搬运关系时，不要因为"担心报警"就
    刻意改标成 conversion 来逃避核对——核对本身是有价值的一致性
    保障，只是不该套用在不同量纲的字段上。
• uncertain_fields：数组（可选），vars 里属于"你自己主观估计出来、
  置信度不高"的字段声明（比如"创业成功率"这类本质是推断而非确定事实
  的数值——age 这类确定性字段不要放进来），每项是
  {"field": "startup_success_rate", "confidence": "low", "note": "一句话 说明为什么置信度低"}。confidence 只能是 high/medium/low
  三档之一，不要给出精确概率造成"伪精确"的印象；note 可以省略但建议
  给一句话。没有这类字段就不用输出。
• objectives：数组（可选），字符串列表，这次模拟"主要关心的指标"
  （比如 ["资产净值", "工作满意度", "健康水平"]），不要求是 vars
  里的精确字段名，写清楚意思即可。用户意图里能看出明确关心的方向时
  给出建议；看不出来就不用输出，不要为了填这个字段而牵强编造。这个
  字段只是记录用途（供创建向导展示、供后续「对比实验」页面提供默认
  关注字段参考），不会触发任何自动排序/推荐。
• causal_lines：数组（默认应该给出，不是可选装饰），声明这次模拟
  存在的几条"因果线"（阶段二十二，多尺度因果线：Causal Line 成为
  一等公民；因果线是模拟的默认基础机制，不需要用户提前要求），
  每项 {"id": "tech", "label": "技术线", "time_granularity": "年"}
  ——id 是短英文标识（之后 advance_step 阶段的 line_updates/
  causal_links.line_id 会引用它）、label 是给用户看的中文名、
  time_granularity 是这条线大致的节奏描述（自由文本提示，不是
  精确约束）。请你主动识别这次模拟里天然存在的几条节奏可能不同的
  线索（比如"个人职业发展"是主线、"AI 技术演进"是一条按年推进的
  背景线、某次"关键谈判"是一条按轮次推进的插曲线），一般给 24 条；
  即使是看起来单一节奏的日常人生模拟，通常也至少能拆出"主线"+
  一两条背景线（比如"健康"、"人际关系"），不要因为怕"生硬拆分"就
  完全不给——只有当模拟本身极其简单、确实拆不出第二个独立维度时才
  可以只给一条主线，但即便如此也建议给出这一条，不要留空。每条线
  还必须同时给出一个 future_tree（阶段二十六，因果线的"未来因果
  树"）：{"branches": [{"id": "fast", "description": "AI 成本快速 下降，两年内降至当前 1/3", "likelihood": "medium"}, {"id": "slow", "description": "AI 成本仅缓慢下降", "likelihood": "medium"}]}——
  每条线给 23 个相互之间有实质区分度的未来可能方向（不要写成同义
  反复），likelihood 只能是 high/medium/low 三档，不要给精确
  概率。就算你判断不出细致的分支，也请至少给出"乐观/悲观"这类最朴素
  的两条，不要完全不给——系统会用通用模板兜底，但贴合具体情境的树
  对用户更有价值。
• desired_state：对象（可选，第九轮批次一，Desired State 结构化），
  这次模拟意图里能看出的"理想状态"结构，最多包含三个可选 key（都是
  字符串数组）：conditions（达成理想状态需要满足的一组条件，如
  ["financial_independence", "meaningful_work"]）、constraints
  （已知的硬约束，如 ["cannot relocate", "limited capital"]）、
  assumptions（这次推演基于的假设）。意图里看不出明确的理想状态
  结构就不用输出这个字段或给空对象，不要为了填这个字段而牵强编造。
• declared_causal_graph：数组（可选，第五轮方案 5.4 节），声明因果线之间"先验的、稳定的结构性认知"——不是"这次模拟实际发生过什么"（那属于advance_step 阶段的 line_updates/causal_links），而是"这条线一般来说会影响那条线，即使这次模拟还没有历史数据"这类在任何具体历史事件发生之前就成立的常识性结构。每项 {"from_line_id": "tech", "to_line_id": "industry", "note": "技术突破通常先影响行业格局，再传导到具体企业"}：from_line_id/to_line_id 用上面 causal_lines里的 id，note 一句话说明。只有存在真正明显的先验关系时才给，不要为了填这个字段而牵强地编造，没有就不给或给空数组。

作为 advance_step 挂载时（result_file: next_state.json）

输入：当前标题、当前状态摘要、当前 vars（JSON）、当前时间步、当前
状态对应的模拟内时间点（{current_time_label}，可能为空字符串）、
产生当前状态那一步实际用的时间粒度（{current_time_granularity}，
可能为"无（这是第一步……）"）、当前状态的候选分支选项（JSON 数组，
可能为空）、本次选择的选项（可能为空对象 {}）、可选的
decision_context（"代理决策者画像"，非空时表示这一步是自动挡场景，
你需要自己从候选分支选项里选一个，见下方规则）、{option_count_hint}/
{time_granularity_hint}（同上，含义与 generate_scenario 一致）。

选择逻辑（按优先级）：

1. 如果"本次选择的选项"非空：直接按这个选项推进，chosen_option_id/
   chosen_reason 字段可以省略（调用方已经知道选的是什么）——这个
   选项的 id 如果是 custom_ 开头，说明是用户自己新增的、不在原
   候选列表里的选项（系统给的候选终究只是建议），处理方式完全一样，
   不需要特殊判断。
2. 如果"本次选择的选项"为空对象，但 decision_context 非空（自动挡
   代选）：从"候选分支选项"里挑一个最符合 decision_context 给定
   原则/风险偏好的选项，在输出里加上 chosen_option_id（选中选项的
   id，必须是候选列表里真实存在的 id，不要编造）和 chosen_reason
   （一两句话，说明为什么这么选，要具体到"符合了画像里的哪条原则"，
   不要写"综合考虑后选择了这个方向"这种空话）。若候选分支选项为空
   数组（无可选项），按第 3 条处理，不需要这两个字段。
   若 decision_context 里明确写了"允许你跳出候选列表提出自定义
   选项"，且你确信候选列表里没有一个足够合理，可以改为输出
   custom_option_label/custom_option_description（新方向的标题
   和说明）+ chosen_reason（说明候选列表为什么不够好），不要同时
   输出 chosen_option_id；没有明确允许时不能这样做，必须从候选
   列表里选。
3. 如果"本次选择的选项"为空对象且 decision_context 也为空（普通
   手动挡，未指定选择）：依据当前状态给出最合理的默认走向，不要等待
   用户输入，也不需要 chosen_option_id/chosen_reason。

推进时要把"大环境也在自己变化"考虑进去：不要只推演"主角这次选择
的直接后果"，current_vars_json 里如果带了 macro_environment，
它应该有独立于主角选择的演化（经济周期、行业技术发展、就业市场、
政策、社会观念等按自己的逻辑往前走），并且要让这个变化真的影响到
这一步的叙事和下一步候选选项——比如"你选择继续深耕某项技术方向"这个
选择本身没变，但因为大环境里"这项技术这半年被更新的技术路线超车"，
后果就应该和"大环境没变"时不一样。没有明确迹象要引入宏观转折时，
macro_environment 也可以只是渐进式的小幅变化，不需要每一步都制造
剧烈冲击。

输出（合法 JSON，顶层字段）：

• next_summary：字符串，推进后新状态的一句话摘要。
• narrative：字符串，本步发生了什么的叙事文本（几句话，不要写成
  大段小说）。
• next_vars：对象，推进后的完整 vars（不是增量，是完整新值——
  引擎不做字段合并，直接整体替换）。数值型字段变化要符合常理的幅度，
  幅度按这一步实际用的粒度（即下面 next_time_granularity 的值，
  默认延续 {current_time_granularity}）换算（比如粒度是"1 个月"，
  年龄这类按年变化的字段一般不该整数 +1，除非正好跨了年；粒度是
  "5 年"，很多字段的变化量就该明显大于"1 年"粒度下的量）；
  macro_environment（如果初始状态里有）也要给出推进后的新值，体现
  它自己的演化，而不是原样照抄。
• time_label：字符串（可选），这一步结束时对应的模拟内时间点，在
  {current_time_label} 基础上按这一步实际用的粒度往前推算（比如
  当前是"起点"、粒度是"1 个月"，这里给"1 个月后"；当前是"第 2 年"、
  粒度是"1 年"，这里给"第 3 年"），合理估算即可，不用精确到具体日期。
• next_time_granularity：字符串（可选），这一步实际使用的时间粒度
  （比如"1 个月"/"1 年"/"一轮谈判"）。固定模式下应该原样等于
  {current_time_granularity}（不会变）；自动/引导模式下默认
  延续 {current_time_granularity}，只有情境明显需要时才给一个不同
  的值（比如从"1 年"切到"一轮"），不要没理由随意改变；留空表示"和
  上一步一样"，引擎会自动延续，不强制每次都显式重复同一个值。
• granularity_reason：字符串（仅当 next_time_granularity 与
  {current_time_granularity} 不同时才需要），一两句话说明为什么
  现在要切换节奏（比如"进入关键谈判，改为按轮次推进以体现细节博弈"），
  没有切换就不要输出这个字段。
• options：数组，供下一步选择的候选分支（结构同上，数量按
  {option_count_hint}，情节明显没有分支可以给空数组）；有意义的话，
  候选方向里可以体现"应对大环境变化"这条思路（比如"顺应新趋势转型"
  vs "坚持原方向"），不用每次都是纯粹的个人选择。每个选项除了
  id/label/description，可以额外给出 risk_level/
  reversibility/affected_lines/key_uncertainty（阶段三十二）、
  action_reason（阶段三十三第二批 4.2 节，为什么这个方向现在值得
  列入）、urgency/time_window（阶段三十三第二批 4.3 节，紧急
  程度四档 + 时间窗口，独立于 risk_level；声明 urgency: critical
  会使模拟自动暂停，谨慎使用）、action_type（阶段三十三第六批
  4.7 节，single/combo/conditional，标注这是不是一个组合/
  条件方案，"组合了什么/条件是什么"直接写进 description 就行，
  不用拆成额外字段）、prerequisites/consequences（第五轮方案
  5.1 节，next_doc/world_simulator_decision_engine_round2_gap_ analysis_plan.md——prerequisites 是字符串数组，选这个方向前
  需要满足的前提条件；consequences 是一个对象，包含
  short_term/long_term 两个可选 key，分别是短期/中长期后果各
  一句话，description 已经说清楚就不用重复）——不确定就不填，
  不要瞎猜凑数。
• decision_reason：字符串（可选，顶层字段，不是某个选项内部的
  字段），这一批 options 共享的背景说明——"为什么现在需要做这个
  决定"，只有一个选项或原因足够简单时可以不填。
• major_decision：布尔值（可选，默认 false），当这一步的选择/走向
  明显是人生的重大转折点时设为 true——自动挡的 review_mode: pause_on_major_decision 用它判断是否需要暂停等用户确认，见
  world_simulator/autopilot.py；手动挡场景可以照常产出这个字段，
  引擎不会因为它是 true 而改变手动挡的任何行为。
• uncertain_fields：数组（可选），这一步 next_vars 里属于"你自己
  主观估计出来、置信度不高"的字段声明，格式同 generate_scenario
  阶段（见上）。只标注这一步真正新增/变化的估计值型字段即可，不需要
  每一步都重复列出从未变化的旧标注；没有这类字段就不用输出。
• resource_transfers：数组（可选），如果 {current_vars_json} 所属
  模拟声明过 resource_relations 里的 transfer 关系，并且这一步
  确实触发了某条转移，在这里如实报告一下，每项是
  {"relation": "resources.invested->resources.cash", "amount": 1000}——relation 是那条 transfer 关系的 "{from}->{to}"
  （必须和声明时的字段路径完全一致），amount 是这一步这条关系
  搬运的量（正数）。报了之后引擎会直接信任这条记录、不再对比
  next_vars 前后差值做核对——这在同一步这个字段还有别的变动时
  （比如现金这一步既收到一笔转移、又花掉了别的钱）能避免被
  错误地判定为"不一致"。没有声明 transfer 关系、这一步没有触发
  任何转移、或者不确定具体搬运量时都不用输出这个字段，引擎会自动
  退回估算，不强制每一步都填；正因为这个字段会被直接信任、不再
  核对，只应该在这条转移确实发生时才报告，不要为了避免"不一致"
  提示而不实报告。
• key_drivers：数组（可选），字符串列表，1~3 条短语概括这一步变化
  的关键驱动因素（比如"市场需求超预期""现金储备见底被迫收缩"），帮
  用户不用逐字读 narrative 就能抓住重点；这一步变化平淡、没有特别
  值得划重点的因素就不用输出，不要为了凑够 3 条硬找理由。
• causal_links：数组（可选），每项 {"driver": "现金储备见底", "affected_fields": ["cash", "stage"], "effect": "被迫从「自由职业」 转为「求稳定工作」"}——把 key_drivers 的短语和具体受影响的字段、
  具体后果关联起来，是给"想深入看一步"的用户的进阶信息，可以只给
  key_drivers 而不给这个字段，也不要求一一对应，不需要每一步都给。
  每项还应该带上 line_id（阶段二十二），标注这条因果链归属到哪条
  因果线，用 {causal_lines_hint} 里列出的 id；确实判断不出归属哪
  条线时可以不给，但这应该是少数情况，不是默认不给。能明确判断的
  话，再带上 relation_type（阶段二十七，"one_way"/"two_way"/
  "indirect"/"feedback_loop" 四选一，不给按单向处理）和
  source_line_id（影响从哪条线发起，配合 line_id 表达"A 线影响
  到 B 线"，同线内部关系或发起线不明确就不给）。
• line_updates：对象（默认应该给出，因果线是基础机制，不是仅当
  提前声明过才需要考虑的可选项），key 是线的 id（{causal_lines_hint}
  会告诉你当前已经声明/自动登记过哪些线，正常情况下延续使用这些
  id；如果这一步确实催生了一条全新的、独立的因果线，也可以直接
  启用一个新 id，系统会自动登记为新线，不需要提前声明），value 形如
  {"time_label": "第 3 年", "summary": "AI 成本持续下降", "advanced": true}——time_label 是这条线推进到的时间点（这条线自己的时间
  维度，和这一步 next_time_label 不必同步）、summary 一句话说明
  这条线这一步的进展、advanced 可省略（省略等价于 true）。只需要
  给"这一步真的有推进"的线，没有进展的线不要出现在这个对象里，
  不强制每条线每一步都更新；如果 {causal_lines_hint} 里某条线带了
  "用户对这条线的修改意见"，推演这条线时请认真纳入考虑。还可以选填
  trend（第五轮方案 5.3 节）："accelerating"（加速）/"steady"
  （匀速延续）/"decelerating"（放缓，可能即将转折）/"reversing"
  （方向已反转）四选一，回答"这条线自己觉得现在处于什么阶段"——不
  确定就不填，不要为了填而猜一个，不认识的取值会被系统直接忽略。
• tree_updates：数组（可选，阶段二十六，因果线的"未来因果树"
  修正），{causal_lines_hint} 里会列出各条线当前的未来分支
  （及其状态）；如果这一步的实际走向印证/排除了某个已有分支，或者
  催生了一个原树上没有的新可能性，给出对应条目，每项形如
  {"line_id": "tech_line", "confirmed_branch": "fast", "pruned_branches": ["slow"], "new_branches": [{"description": "出现了原来没想到的第三条路径：政策突然放开导致成本结构性下降", "likelihood": "low"}]}——三个子字段都可选，只给这一步真正发生的
  部分；这一步的走向没有明显印证/排除任何分支、也没有催生新可能性
  时，不需要输出这个字段。
• triggered_relationships：数组（可选，阶段三十六第二批，Influence
  Field / Relationship 完整机制），字符串数组，只有当 {relationship_ hint} 非空、且这一步的情节里某条声明了延迟（delay_steps > 0 或 delay_days > 0）的
  关系的"源头"确实发生了，才给出被触发的关系引用（id 或声明顺序
  的下标）。绝大多数步骤没有这个字段——relationship_hint 为空，或
  相关关系都是即时生效（未声明延迟）时都不需要输出。
• structural_change：对象（可选，阶段二十三，Model Regime
  Detection / Emergence），只有当这一步出现了原模型没预期、且看起来
  会稳定存在下去的新结构时才给（新的人物/关系、新的稳定机制、或者
  整个人生阶段性质的转折），格式 {"kind": "new_entity" | "new_mechanism" | "regime_shift", "description": "一句话", "proposed_fields": {...}}，绝大多数步骤不应该有这个字段。系统
  不会自动采纳，只是展示给用户确认，{confirmed_structural_changes_hint}
  里能看到之前已被确认的项，请把它们当成既有事实。
• problems：数组（可选，第九轮批次一，Problem 结构化），只有当
  这一步的发展暴露了一个明确的现实问题、解决了之前的问题、或者让
  之前的问题演变成了另一个问题时才给，每项 {"id": "problem_1", "symptom": "资金不足，无法招聘核心工程师", "blocked_goal": "在 12 个月内完成产品原型", "missing_capabilities": ["种子轮融资", "早期客户验证"], "status": "emerging"}——id 延续同一问题时请
  复用之前用过的值，status 只能是
  "emerging"/"active"/"solved"/"transformed" 四选一，
  blocked_goal 可以参考上面 {desired_state_hint} 声明的理想
  条件但不要求精确对应。绝大多数平淡的推进步骤不需要这个字段，不要
  为了"显得有内容"而每步都编造问题；如果上面提示里出现了用户已确认
  关注的潜在问题建议，可以判断是否值得直接采纳成一条正式的
  problems，不采纳也可以。
• 本步已发生的外部事件（第二十二轮 WP2，仅当提示里出现"外生事件采样已开启"
  时才有）：那是引擎按先验概率抽样决定的既成事实，不是你的选择——把列出的事件
  自然写进叙事与状态变化，不要否认/替换；没有列出事件说明本步抽样为空，可以写平静的
  一步，不要凭空引入与已声明先验无关的突发外部冲击（由角色自身行动引发的后果不受此限）。
  这不需要你输出任何新字段。
• elapsed_days 与 tech_updates（可选，第二十二轮 WP1/WP2。elapsed_days
  在提示里出现"技术发展模型已开启"、"外生事件采样已开启"或"因果引擎已开启"（且要求给 elapsed_days）时输出；
  tech_updates 仅在"技术发展模型已开启"时输出；都没有就不要输出）：elapsed_days 是
  这一步在模拟世界里大致跨越的天数（正数，量级估计即可）；tech_updates
  是技术变化数组，每项以 id 为键，可含 name/kind（登记新技术）、
  stage（本步结束时你认为所处阶段，六选一同 maturity_stage）、
  investment（low/normal/high，非 normal 须附 investment_reason）、
  bottleneck/bottleneck_severity、adoption、market、cost_index、
  perceived_stage、regression_reason 等。引擎按时间推算阶段内进度并
  裁决迁移——你不能自己宣布"进入下一阶段"：一步最多升一档、进度未满或
  硬前置未满足会被驳回并记录在时间线上；新技术只能从 lab 开始（世界里
  本来就存在的技术请标 preexisting: true）。详见提示里的协议说明。
• effect_dispositions（可选，第二十二轮 WP3，仅当提示里出现"因果引擎已开启"且列出了
  到期的待兑现因果时输出；否则不要输出）：数组，每个到期项一条
  {"pending_id": "提示里方括号中的 id", "disposition": "realized"|"dampened"|"postponed"| "countered", "reason": "一句话原因"}。realized=效果已在本步的 next_vars/line_updates/
  叙事里体现；dampened=只体现了一部分；postponed=推迟（之后仍会提醒）；countered=被别的
  因素抵消。dampened/postponed/countered 必须给 reason，否则引擎会忽略该条并记录
  违规；延迟期未到的项、提示里没列出的 id 不要给交代。引擎只记录你的回报并统计兑现情况，
  不会替你改任何数值——realized 就要真的写进状态里。
• tree_updates 里新增分支的两个可选字段（第二十二轮 WP3 / P5c，仅当提示里出现"因果树接地已开启"
  时才使用；否则不要填）：trigger_condition（结构化触发条件，如
  {"var": "字段路径", "op": ">=", "value": 5} 或 {"tech": "技术id", "min_stage": "developer"}，
  数组表示全部满足；是你对"什么情况下它会发生"的可核验假设，没把握就不填）与 exclusive_group
  （同一条线内同名即互斥的组名）。引擎据此强制：前置未 resolved 的分支不能 active、互斥组内不能同时
  active，违反会被降回 emerging 并记录；条件满足只产生建议（除非用户另开自动迁移）。
• tree_updates 里新增分支的可选字段 effects_if_active（第二十二轮 WP3 / P5d，仅当提示里出现"树影响世界已开启"
  时才使用；否则不要填）：数组，每项 {"to_line_id": "目标因果线或技术节点 id", "mechanism": "一句话机制", "sign": "positive|negative|mixed", "strength": "high|medium|low", "delay_days": 90}，声明"该分支一旦变为
  active，会对哪里施加什么压力"。分支新变为 active 后，引擎把它排进待兑现队列，延迟期到了会在因果引擎
  那一项里列出，你要用 effect_dispositions 交代。这是可核验的假设，没把握就不填，不要编目标 id；
  引擎不会替你改任何数值。
• capabilities_gained：数组（可选，第九轮批次二，Capability 对象），
  只有当这一步的发展让角色真正获得了一项新能力（不是单纯"变好一
  点"，而是"之前做不到的事，现在能做了"）时才给，每项
  {"capability": "能够自动分析潜在客户的付费意愿", "enables": ["更精准的销售话术", "更快的产品迭代"], "limitations": ["无法替代 真实用户访谈"]}——capability 一句话说明新能力是什么，enables
  13 条短语说明这个能力让哪些事情变得可能（说明性文字，不代表引擎
  会据此自动扩展候选选项），limitations 13 条短语说明这个能力
  目前的局限。绝大多数步骤不应该有这个字段，不要把普通数值变化
  包装成"新能力"。