奉天承运，治乱由人。

天命是一款以 AI 为引擎的中国古代王朝历史模拟。这里的 AI 不是替古人配台词的点缀，而是推演整个世界的发动机：你以诏令、朝议、问对、任免执掌一朝，而江山如何回应——臣子的奏报、派系的博弈、史局的走向——皆由 AI 依据满盘局势逐回合演绎；确定性的账本与规则闸门则在底下兜住每一笔钱粮民心，让每一步变化都力求有因、有账、有后果。不是随机生成的戏剧，而是讲得通的兴衰。

An AI-driven dynastic simulator of imperial China — the AI is the engine, a deterministic ledger keeps it honest.

天命的乐趣不在旁观一段生成的剧情，而在能追问因果的治理循环。一回合大致是这样：

1. 读局势 —— 翻阅奏报、账本、人物、舆图、军队与朝堂反馈，弄清此刻的财政、边防、民心与党争。
2. 定方略 —— 决定这一回合要处理灾变、税赋、任免、边患、科举还是派系。
3. 下敕令 —— 通过御案诏书、朝堂议政、御前问对、奏疏批复、鸿雁往来等方式落子。
4. 过回合 —— AI 综合你的操作、剧本状态、人物与势力的行动，推演出新的局势。
5. 对真账 —— 财政、民心、皇威、皇权、吏治、军队、地方、人物状态等核心指标，力求写回真实字段，而非只停在叙事里。
6. 复盘纠偏 —— 你依据新一轮的奏报与账本变化，继续补救、追责、安抚、扩张或改革。

循环的核心，是让你能始终追问一句话：我做了什么，系统是否忠实地反映了什么。

传统的历史与策略游戏，引擎是一套写死的规则：事件表、触发条件、概率骰子、行为树。世界里能发生什么，开发者在出厂前就已穷举完毕——玩得够久，你迟早撞见「这个事件我见过」。

天命把引擎本身换成了 AI。

臣子如何回应你的诏令、党争如何发酵、边将是否抗命、灾荒之后民心流向何处——都不是从预设事件表里抽签，而是 AI 读你的诏书、读各人的处境与记忆、读各省的账本与各派的算盘，当场推演出来的。没有两局相同，也没有穷尽之日。

代价是 AI 会跑偏、会失忆、会前后矛盾。所以天命给这台引擎配了一套「物理定律」：

• 确定性账本 —— 钱粮、民心、皇威、吏治、军队的每一笔变动都落到真实字段；AI 说「国库已空」，国库就真的空了，不是嘴上说说。
• 规则闸门 —— 叛乱、政变、劫狱这类大事，必须与民心、皇威、看押强度、人物忠诚相称；盛世强君之下，AI 编不出一场凭空得逞的宫变。
• 记忆与校验 —— AI 的输出经结构化提取、字段校验与记忆归档，让它记得住你施过的恩、认得清你改过的数。

分工于是清楚了：AI 负责「世界会发生什么」，账本负责「发生的必须算数、必须守恒」。 AI 是导演，账本是这部戏的物理与会计。它仍不是一台永不出错的模拟器，但方向始终如一——让 AI 放手去演，让账本牢牢兜底。

把引擎交给 AI，带来的不是画面更炫、对话更多，而是三样传统游戏从原理上给不了的东西：

• 你的手段，不止于菜单。 传统游戏里你只能点设计师列好的选项；天命里你写一道诏书，AI 去理解、去演绎。能做什么的上限，是你想得到、写得出的，而不是开发者枚举好的。
• 局面会长出没人预设的样子。 AI 现场演绎，常涌现连设计者也没写过的转折——一次赈灾如何挪动某省士绅对你的观感，一道操之过急的新政如何在边镇激起连锁哗变。剧本给的是开局，不是结局。
• 满朝文武是有动机的人，不是布景。 每个臣子各有处境、记忆、立场与算盘，会因你的恩怨记仇念恩，在朝堂上替自己的利害博弈，而不是播放固定台词。你面对的是一屋子智能体，不是一棵对话树。

天命那套账本与闸门，正是为这种自由准备的：AI 给得起这些自由，总得有人接得住它的代价。

那么，这台引擎眼下能驱动多大的世界？天命当前处在「可玩核心、持续补账」的阶段：朝廷交互与官方剧本已可完整游玩，世界账本已在底层运转，并仍向更多玩家入口与未尽之处延伸。

朝廷交互（你影响世界的主入口，均为可用闭环）

• 御案诏书 —— 拟定政令、军令、外交、经济诸般诏书，支持议题纳入、分类拟旨、有司润色与诏令影响预估；发布后由系统解析诏文，落成真实的任免与施政。
• 朝会三制 —— 常朝、廷议、御前各司其职。廷议尤为完整：与会群臣由 AI 按各自立场实时发言、博弈、斡旋，参议筛选、表决与裁决落账一应俱全，异见者甚至可能拂袖请辞或暗中谋划。
• 官署制度·动态生命周期 —— 官署衙门不再是开局写死的死物：可下诏新设、试行、改革、裁撤任意机构，每个机构走「提出→廷议→试行→成败→废止→引为前例」全过程，逐回合反馈经费、腐化、欠费裁员与存废。
• 百官奏疏·御案批红 —— 重做为「御案批红」三栏（奏牍架 / 御览朱批 / 辅臣拟议）：奏疏可准、可驳、可批、可留中、可发廷议；密折火漆封缄需启封、弹章朱砂警示、远方奏疏朱批由信使在途回传、留中过久言官续奏；辅臣先就每折拟出处理意见（各带立场私心、可采可驳），已批之折回显实际去向与具题人态度。
• 御前问对与鸿雁传书 —— 御前问对深化为有来有往的政治博弈：赏罚（赐金赐宴 / 杖责下狱）真正落到忠诚、压力与国库，君臣承诺会立账并在日后核验履约失诺，臣下主动求见各有缘由，可犯颜直谏、当廷令多人对质、按语气与厂卫线索识破谎言、即时差遣、屏退旁人密谈，使节问对可准奏 / 驳回 / 羁縻并联动邦交与岁币。鸿雁传书重做为「驿路长卷」：每封信一条可视化驿路（信使在途、截获断裂、权臣阻滞、回函返程），配火漆封缄、虎符玺印金牌信物与密级、截获概率。
• 史官实录·史册库 —— 四库（史记 / 起居注 / 纪事 / 编年）史料数据库：多视图浏览（馆藏概览 / 四库浏览 / 时间轴 / 人物列传 / 势力地域）、跨库全局检索、人物立绘与列传聚合、史料权威钤印，回看每一回合的四层文体实录、人事、诏令与国势变化。

治理与账本 你很少直接拨动这些数字——天命的治理是下诏，而非编辑数值：你颁一道诏令，或在朝议上裁断，再由推演把它落成账本变化（连国库的加派赋税、开仓赈济、借贷，也已归位为「拟诏颁行方才落效」，不再点按钮直接改数值）。底层账本系统已完整运转：

• 财政 —— 国库钱粮、央地起运与存留、近二十种税种与实征率，共同决定你究竟能调度多少；国库破产沿「告急→欠俸→举债→失信→军饷断→赈济断→崩溃」七阶段连锁恶化，亦可在财政转正后逐级回血。
• 民心 —— 各省、各阶层分别记账，民怨累积可推动民变链条逐级演进。
• 皇威与皇权 —— 各自五段 / 三段的权威指标，既因失政下滑，也因功业回升。
• 吏治 —— 六部门、九来源的腐败账本，牵动征税效率、奏疏质量与改革阻力。
• 军务 —— 下诏建军募兵确实落入军务名册、据实扣支钱粮，统帅任免与名册接通。
• 户籍 —— 按年龄性别核定可役丁口、民族信仰混杂形成治理压力、保甲清查隐户逃户、战乱折损男丁，附二十余条历史徭役预设，回灌徭役与兵源并留账。

人物、势力与士林

• 人物 —— 各有官职、派系、关系、家底、亲族、声望与行动记录；恩赏与嫌隙会被记住、累积成对你的总体立场，名望随重大事件涨落并影响话语权与改革推动，抄家可按隐匿财产估值分「本人 / 九族 / 十族」分级株连、获罪者降为庶人，家族共财与私产（田宅、店铺、商号、投资、债务）细账在底层运转。私产、门第、社会阶层与仁义礼智信五常，共同决定臣僚会去理政、赈灾、结党还是中饱私囊。
• 势力 / 党派 / 阶级 —— 升级为会自己行动的政治势力：每回合推演各自诉求与立场，主动上书、请愿、罢市乃至酝酿民变，并由一位现任大臣出面代言；阶层不满下沉到州县民心、生成可议的朝议议题与民变候选。你只能用诏令 / 奏疏 / 问对 / 朝议 / 鸿雁回应，右侧栏可查其近因因果链、生态亲疏与走势预判。
• 科举士林 —— 科举主线可完整运行，从乡试、会试到殿试亲策钦点；恩科、武举、童子、改革范式、言官清议与门生网络持续扩展。

舆图与官方剧本

• 舆图区划 —— 省府州县、地形、资源、人口、民心、腐败、财政多层信息；舆图按主权归属上色，每个区划可就地「安民、巡按、调粮、拟诏」纳入御案。
• 剧本库与开始游戏 —— 《天启七年·九月》（明末天启崇祯之交，203 名人物、22 方势力并立，含后金、察哈尔、朝鲜与葡荷西诸殖民据点）；《绍宋·建炎元年八月》（南宋初建，73 名人物，更聚焦的单线叙事）。开始游戏会列出官方剧本、桌面用户剧本与剧本编辑器写回的自制剧本；未完善、草稿态或仍在补字段的剧本也会显示，方便作者随时试跑。

诚实口径：可玩的闭环已经不少——御案、朝会、奏疏、问对、科举主线与官方剧本都能完整游玩，账本系统也在背后真实运转，御案右侧栏的各情报面板（政务、文事、军务、舆图、户部、人事、纲纪）已逐一从开发期半成品做成可读的情报与账册，党争与社会阶层升级为会自行上书请愿的活势力，官署制度也有了可新设改革裁撤的完整生命周期，创意工坊更已升级为一座可发布、可社交、有审核的活社区（详见下文）。仍在建设的，主要是更直接的军务与舆图军事交互（如在舆图上点选调兵、战斗演示）与科举特科的默认开放。下文「设计原则」说明我们如何对待这种「未完成」。

如果 AI 是推演世界的引擎，剧本就是喂给它的初始世界。天命的长期目标，不是做好一个明末剧本，而是让你能亲手造出任意中国古代朝代，交给引擎去推演。为此它内置了一整条创作工具链：

• 剧本编辑器 —— 覆盖朝代、年号、皇命、人物、官制树、势力、行政区划、财政、军政、世界设定与历史事件等 20 余个维度。支持一键全量 AI 生成（严格史实 / 轻松史实 / 演义三种取向）、逐维度生成、官制与区划的多轮深化，以及生成后的一致性校验与修复。主画布更升级为可视化就地编辑：人物以列传卡片就地改名 / 改能力 / 改所属（改势力即时换色）、势力外交关系做成可交互图谱（点线改倾向、点两势力拉新关系），字段墙退居幕后、所见即所得。
• 地图编辑器 —— 独立的舆图工作台：导入底图描边、手绘多边形、自动拓扑与邻接，内置商周至民国 9 个朝代的行政层级预设，支持跨朝代时间线（同一地点在不同年份的归属与名称变迁），并能 AI 一键推断人口、民心、腐败、财政等字段，导出后直接接入剧本与游戏。如今更与剧本编辑器双向打通：区划与地块的绑定可在剧本编辑器内轻量核对、一键校准错绑、逐块改归属上色乃至拖顶点微调省界；需要重画整块几何时一键往返地图编辑器、画完自动写回剧本。
• 剧本写作 agent（国师） —— 用自然语言驱动改剧本的对话式 AI 助手：分编辑 / 审阅 / 问答 / 讲解 / 分解执行五种模式，覆盖人物 / 势力 / 事件 / 财政 / 军事 / 官制 / 规则 / 行政 / 开篇九大章——改完自动跳到对应章节并在主画布实时反映，并获高权限可写入剧本原本没有的自定义字段（如人物隐藏身世、自定义传说）。在沙箱副本上多轮操作并强制自检校验（如父级人口不小于子级之和、势力引用必须存在）；改动以逐条 diff 卡片呈现、可单条接受或拒绝、应用后可撤销回退；新增跨会话记忆（记得你近期已应用的改动），应用一批改动后对话不中断、可连续协作；对话界面支持 Markdown / 表格渲染、推理过程折叠、实体跳转与「创作约定」记忆。
• 创意工坊（社区版） —— 一座全屏的「联网中枢」内容社区：浏览 / 搜索 / 安装他人与官方的剧本、立绘、配乐、地图、MOD，封面按类型各有场景母题；账号与邮箱验证码登录、评分评论、SHA256 校验已打通，作者可在创作中心直接导入打包好的资源包、连同封面与商店信息一键提交发布申请，经审核通过后上架（无需再自行托管，亦可 AI 起草）；站长侧另有独立审核台把关待审队列、可通过上架或驳回。在此之上还内置了一整套社交闭环：以「史官档案」沉淀社区品级与声望，「史馆动态流」把一局高光发成邸报体动态，关注作者与一键三连（收藏 / 推荐 / 关注），「同台竞史」开擂台比拼同一开局的结局，「鉴赏家合集」策展好作品，「同好圈子」按朝代聚同好、圈内发帖，「共编修订」给他人作品提改、作者采纳，「约稿墙」求人为你的剧本配立绘配乐——配套服务器后端支撑动态 / 关注 / 收藏 / 擂台 / 合集 / 圈子 / 修订 / 约稿。

跨朝代不是一句口号：货币单位随朝代而变（汉以钱、唐以贯、明清以两），央地财政内置秦郡县、唐前期、明起运存留、清存留定额、藩镇割据等多套历史分账预设，户籍可细分编户、军户、匠户、乐户等十类名色——这些都写在通用机制层里、由剧本数据驱动，而非专属某一朝。

前面说 AI 是引擎、账本是物理定律——这一节看它们如何协作。一个回合的推演，由「回合管道、提示词、结构化输出、校验、变更应用、账本写回」串成。

回合管道 —— endTurn() 是唯一入口，整个回合被组织成显式的六步：准备 → 后台预热 → AI 推演 → 诏令结算 → 系统结算 → 渲染收尾。每一步都声明了失败策略：关键步骤失败即中止，绝不写半截账本；非关键步骤（如后台预热）失败则继续。主推演之外还有十余个并行子调用，分管文事、势力、实录、记忆召回等专项。

从 JSON 到真实字段 —— AI 返回的结构化结果，经预检后由统一派发层按字段族路由：财政变更写国库与省级财政，任免写官制树，人物更新写忠诚 / 在世 / 派系，军队变更写名册与统帅，区划更新写人口 / 民心 / 民变。若 AI 只写了叙事而漏了结构化字段，还有一层兜底，从文本中模糊提取并记录告警。所有变化都汇入回合报告，供「史记」复盘。

账本引擎群 —— 账本不是一个文件，而是一组专题引擎：财政（国库与央地）、权威（皇威 / 皇权 / 民心）、民心总账（按省、按阶层、按来源差异化封顶）、吏治腐败、央地分账、货币与承载力、户籍与徭役。每个引擎都把抽象的「局势恶化」落成可查的具体字段。

记忆系统 —— 一个统一的记忆检索层，按来源权重与当下相关度，从硬状态、诏令、事件史、人物恩怨、君臣承诺中挑出最要紧的喂给推演脑；NPC 受过的恩、结过的怨会被综合成一条「净账」，失败或废止的诏令则沉淀为教训，提醒 AI 勿重蹈覆辙。

相称性闸门 —— 高风险事件由两道约束守住：提示词层明文要求 AI 轻重相称，确定性账本层则在写回时驳回不合理的结果。一句话概括其原则：

盛世强君之下，祸事多为「未遂、暗流、打折」；末世弱君之下，方有「得逞、公然、失控」。

更完整的架构图景，见仓库内的 ARCHITECTURE.md。

• 零编译的原生 Web 运行时 —— 纯原生 JS，无模块系统、无构建步骤。index.html 按依赖顺序加载大量脚本，能力挂在 window 全局上；改动加载顺序或全局字段需格外谨慎。
• 两套数据 —— GM（运行时状态，每局独立）与 P（持久化数据：剧本库、设置、玩家档案）。运行时只读写 GM，不改 P——这是阅读代码时最重要的一条心智模型。
• 自带 API key —— 游戏不内置、也不代理任何 AI 服务。玩家在设置中填入自己的接口（兼容 OpenAI 协议，亦支持 Anthropic 原生），密钥仅存本地。GitHub Pages 是纯静态托管，没有服务端。
• 桌面与 Web 双形态 —— 同一套 web/ 既是 GitHub Pages 的在线版本，也是 Electron 桌面本体加载的游戏主体。

想深入代码，从这两份文档入手：ARCHITECTURE.md（架构导图、GM/P 字段表、回合管道）与 INDEX.md（文档总索引与控制台速查）。

在线游玩 —— 直接打开 https://misfit-user.github.io/tianming/，在设置中填入你的 AI API key 即可开局。

本地静态运行 —— 克隆本仓库，在根目录起一个静态服务器：

python -m http.server 8080
# 然后访问 http://localhost:8080/

桌面开发运行 —— 本仓库是 Web 运行时，完整桌面工程在外层目录，通过 Electron 加载本目录。在外层工程根目录执行：

npm install
npm start

Windows 下也可直接使用外层目录的 启动天命.bat（正式启动）或 dev-start.bat（热重载开发）。

无论哪种方式，AI 推演都需要你自备 API key——这是体验完整玩法的前提。

天命的桌面本体与 Web 内容是两套版本号，初次接触常被绕晕，这里一次说清：

• 桌面公开安装包可能仍显示较低的本体版本（如 1.2.2）；
• 游戏的主体内容由 Web 运行时承载，可通过热更新滚动到最新（当前 1.3.3.6）；
• 热更包的下载与文件总量上限已提升至 2GB，内容批次较大的版本（如本版多面板、编辑器与创意工坊大更新）也能顺利取得；
• 普通前端热更默认不设置最低本体版本门槛；只有确实依赖新安装包能力时，发布包才会显式写入 minAppVersion；
• 若遇到「无法完成热更」或「本体版本过低」，应先检查热更 manifest 是否误写了门槛，而非急着重装整个安装包。

因此 README 顶部标注的「内容版本」，指当前公开可取得的游戏内容版本，并不等同于 Electron 外壳的本体版本。完整更新记录见 changelog.json。

本仓库（web/）是天命的 Web 运行时，也是 GitHub Pages 的发布源。

web/
├─ index.html              运行时入口，按顺序加载全部脚本
├─ tm-*.js                 核心：推演、账本、人物、势力、朝会、科举、舆图、存档等
├─ phase8-formal-*.js      正式界面层（御案、记录、舆图、顶栏 / 右栏）
├─ editor.html / editor-*.js          剧本编辑器
├─ map-editor.html / map-editor-*.js  地图编辑器
├─ changelog.json          公开更新记录（邸报，最新条目在最前）
├─ bundled-scenarios/      官方剧本（随热更包分发到此目录）
├─ data/                   舆图、行政区划、历史补充与运行时快照
├─ scripts/                smoke 测试、校验与数据构建脚本
├─ tools/                  模型准备、热更新包构建等工具
├─ docs/                   系统设计、AI 管线、地图、热更新、工坊等文档
└─ godot/                  Godot 迁移实验工程（非当前正式发行）

想进一步了解，推荐这几份文档：

关于 Godot：godot/ 是面向未来的迁移实验。当前正式发行仍以 Electron + 原生 JS 为准，Godot 不是已替换上线的主版本。

坏事可以发生，但必须讲得通。

天命不怕灾荒、党争、兵变、财政崩坏、边患失控、权威扫地——一个不会出坏结局的王朝模拟，没有意义。它较真的是另一件事：坏结局必须有明确的前因、范围、代价链与可处理的入口，而不是 AI 一时兴起的天降横祸。这正是确定性账本与相称性闸门存在的理由——给放手演绎的 AI 划一条物理底线。

并且，失败该是合理的历史结果，而非玄幻的惩罚：边镇哗变，是因为你拖欠了军饷，不是因为夜观天象见了彗星。难度三档——叙事、标准、硬核——也不是数值倍率，而是三种史观，决定 AI 推演时对你治绩的尊重程度。

所以，对天命最有价值的反馈，从来不是「我不爽」，而是——我做了什么，系统没有忠实地反映什么。

提交 bug 或建议时，若能附上以下信息，最容易定位与修复：

• 游戏版本或 changelog 日期；
• 使用的剧本与难度档；
• 上一回合的关键诏令、议题选择或操作；
• 新一回合的奏报、账本变化、异常截图或存档；
• 你预期系统如何响应，以及实际发生了什么。

越能定位到「哪一项操作没有进入真账」，就越容易修。

如果你想动手改代码，请先读 ARCHITECTURE.md 与 INDEX.md，并留意：新增脚本要登记进 index.html 且置于依赖之后；不要随意调整加载顺序；改全局函数或字段前先全仓搜索调用点；GM 与 P 是核心状态对象，字段改名会影响旧存档兼容；改完至少跑一遍 node --check 与相关 smoke 测试。

MIT License，详见 LICENSE。