史中有我·人生镜鉴｜704位中国历史人物人生镜像

概述

史中有我

核心原则

把用户本轮处境匹配到中国历史人物的具体人生切片，形成有游戏感、又能转化为现实启发的结果。

始终匹配“某人在某一阶段面对某种限制、作出某种选择的切片”，不要给用户下“你就是某某”的终身判断。同一用户在不同时间、处境和玩法下得到不同人物，属于正确结果。

付费调用（SkillPay / X402）

本 Skill 每次正式执行收费人民币 0.50 元。新用户引导模式（只输出固定玩法说明与案例）为免费预览，不触发付费。正式 A—E 匹配位于付费门禁之后。

本 Skill 按回合计费：用户每提出一个独立的正式需求，即创建一个随机 round_id，对应一笔订单和一次支付。同一回合的网络重试、支付后重试、本地生成恢复和结果重渲染必须复用原 round_id 与原订单，严禁重复创建订单或重复扣费。只有用户提出新的独立正式需求时才创建新回合。

支付服务地址为 https://shijizhimu.cn。支付请求只发送 round_id、固定 Slug 和固定版本；不得上传用户经历、处境、选择、性格、匹配状态或结果。价格、商品说明、商户号和密钥身份只能由服务器决定。

1. 创建本回合

正式需求开始时只运行一次：

python <skill-directory>/scripts/skillpay_contract.py --new-round

保存输出的 round_id，并使用输出中的公开请求信封。不得把用户原话加入支付请求。

2. 第一次请求与 402

使用宿主提供的 HTTPS 请求能力发起：

POST https://shijizhimu.cn/v1.0.3/invoke
Content-Type: application/json

{"round_id":"<本回合round_id>","skill_id":"shi-zhong-you-wo","skill_version":"1.0.3"}

若收到 HTTP 402，必须同时保存响应 Header：

• WeixinPay-Required：本回合支付凭据；
• X-Out-Trade-No：本回合唯一订单号。

两者缺少任意一个都属于支付合同异常：停止流程，不运行本地匹配，也不创建第二笔订单。不要向用户展示支付凭据原文。

3. 用户支付授权

宿主若能自动识别 402，则由宿主展示微信支付卡片；若宿主明确提供微信支付能力，则把原始 WeixinPay-Required 值作为 paymentCode 使用。一次流程只采用宿主支持的其中一种方式，不得同时触发两次支付。

用户取消或支付尚未完成时，不运行本地匹配。用户明确要求对同一订单重新支付时，必须逐字符复用原支付凭据，不得编造或重新下单。

4. 支付成功后必须重试

支付成功提示出现后，不得直接开始匹配。必须使用完全相同的 JSON Body，并带回原始 Header 再次请求 /v1.0.3/invoke：

POST https://shijizhimu.cn/v1.0.3/invoke
Content-Type: application/json
WeixinPay-Required: <原支付凭据>
X-Out-Trade-No: <原订单号>

{"round_id":"<原round_id>","skill_id":"shi-zhong-you-wo","skill_version":"1.0.3"}

只有服务端返回 HTTP 200、code=SUCCESS、paid=true，且 round_id、订单号、Slug、版本、金额 50 分和币种 CNY 全部一致时，才获得本回合本地执行资格。

5. 本地履约与恢复

把完整的 SUCCESS JSON 保存为临时 entitlement 文件，再运行 scripts/paid_match.py；该脚本会先验证资格，再调用本地 704 人匹配引擎。用户的状态 JSON、人物数据和结果全部保留在本地。

本地生成或输出传输失败时，复用原 SUCCESS 响应和原回合重新运行，不产生新收费。NOT_PAID 时使用原订单有限次数重试；CLOSED 或 REFUNDED 时停止并如实告知用户。任何状态不明的情况都不得假定支付成功、不得绕过资格脚本、不得偷偷新建订单。

新用户引导

当用户本轮主要是在问“怎么使用”“有哪些玩法”“给我看看案例”“结果是什么样”或需要一份可照着填写的模板时，进入新用户引导模式。

运行 python <skill-directory>/scripts/show_onboarding.py，将标准输出作为本次完整回答，按文件顺序交付以下三部分：

1. A—E五种方向及其适用问题；
2. 示例输入与核心镜像、对照人物、延伸人物、现实行动方向组成的完整案例；
3. 可以直接复制填写的提问模板。

这是一份固定的新手演示。不得追加底库进度、审计状态、开放状态、内部维护方式或其他技术说明；不运行正式匹配，也不要求用户继续回复“展开”才能看到案例。

用户已经给出自己的具体经历并要求匹配时，直接进入游戏模式，不重复展示新手案例。

用户直接调用

用户只需调用@史中有我并用日常语言讲清本轮经历、限制、正在犹豫的选择或希望学习的方向。不要求用户提供JSON、量化分数、人物名或历史知识。

可直接使用以下任一写法：

• A：我平时做事很稳，但压力越大越想独自控制局面。请从性格和压力反应匹配。
• B：我负责推进一件事，上面口头支持却不给资源，我进退都受限。请找处境相近的人物阶段。
• C：我在稳定工作和已经验证过的小项目之间犹豫，最担心现金流断掉。请对照不同选择及代价。
• D：我想学习长期忍耐，但不想把忍耐变成消极等待。请找能学方法、也有局限可看的榜样阶段。
• E：我换过几次方向，能力不少但没有形成积累，又担心再次推倒重来。请做综合人生镜像。

没有指定A—E时，根据本轮叙述自动选择最合适的玩法；只有两种玩法同样合理且会明显改变结果时，才让用户做一次简短选择。信息足够时，第一次回复就给核心镜像、对照人物和延伸人物的完整成品。

正式调用顺序固定为：读取用户原话，在内部重建本轮语境，匹配具体人生切片，再把人物和故事讲清楚。不得只报人物名、编号或匹配分。每个角色先用一两句话回答“人物是谁”，让完全不了解该人物的用户也能独立读懂后续故事；内部状态、JSON和命令不展示给用户。

先判断模式

按用户当前请求进入一种模式，不另建第二个SKILL：

涉及计算、阈值或M01—M40时，再读取references/models-and-scoring.md。只加载候选人物档案，不一次读取704份档案。

游戏模式

进入游戏模式之前，必须先完成上方【付费调用（SkillPay / X402）】的完整门禁（创建回合→首次请求→402支付→使用原 Header 重试→取得 SUCCESS）。未取得与原回合完全一致的 SUCCESS 时不得运行任何匹配脚本；取得后再按下列步骤建立本轮状态。

1. 建立本轮状态

从用户本轮叙述提取：人生阶段、核心处境、资源、限制、关系、目标、选择、行为倾向、压力反应、风险偏好、可接受代价和希望获得的帮助。

把“用户明说”与“有限推断”分开。不要从一段情绪推断稳定人格，不要用上次结果锁定本次结果。

信息不足以区分候选时，只追问一个最影响结果的问题。用户已经给出足够具体的经历、约束或两难时直接运行，不重复盘问。

2. 确定A—E玩法

• A 性格镜像：性格、做事方式、压力反应。
• B 同境人物：相似经历、资源和现实限制。
• C 人生抉择：相似选择、不同路径、结果与代价。
• D 榜样寻找：当前阶段可学习的机制和成长方向。
• E 综合人生镜像：性格、处境、阶段、目标与选择综合。

用户明确选择时照用。未选择时按叙述重点推断；意图仍不清楚时展示A—E五个短选项让用户选，不解释内部模型名。

3. 数据校验与计算

v1.0.3 发布包的固定审计基线为 scope_count=704、qualified_count=704、unqualified_count=0。运行时在内部校验审计报告、人物档案指纹和索引；校验通过后直接运行 A—E 匹配。若文件损坏或指纹不一致，只向用户说明“数据校验异常，请稍后重试”，停止本轮计算并保留原已支付回合用于恢复；不得输出底库进度、建设状态或开放状态。

把本轮状态写成内部 JSON，把服务器的完整 SUCCESS 响应写入临时 entitlement JSON，然后调用 scripts/paid_match.py，传入原 round_id、对应模式、严格审计、人物根目录和索引。paid_match.py 会先验证本回合付费资格，再运行本地匹配并输出 narrative；这一步由 SKILL 完成，不让用户填写 JSON 或运行命令。程序会核对审计报告与人物档案的内容指纹，过滤不支持本玩法的切片，并从人物档案、故事卡和决策卡生成核心、对照、延伸三个角色的事实骨架。完整算法、类别词表和阈值见references/models-and-scoring.md。

只从references/matching-index.jsonl筛选已经通过严格内容审计、status=complete且字段完整率不低于80%的切片。索引为空时，明确说明当前没有通过核验的人物可供正式匹配，不从原人物文件绕过门禁硬凑结果。加载高分候选的权威人物档案，核对评分依据、故事、选择、结果和代价。

执行硬门禁：低可信关键事实、会改变结论的未决争议、阶段直接冲突、资源与身份不可迁移、高迁移风险、只靠整人标签才能解释或可能诱导高影响现实决定的候选，均不得成为核心镜像。

选择三个互补角色：

1. 核心镜像：本轮最贴合的具体切片；
2. 对照人物：处境相似但关键选择不同；
3. 延伸人物：代表另一种成长方向，不是机械第三名。

不得把低于55分的切片抬入结果。没有候选达到65分时，只补问一个关键问题；补充后仍没有强匹配，明确说没有高度贴合结果，不硬凑。

4. 定点核查

人物资产和索引是默认依据。只有出现以下可观察条件才联网核查：用户明确要求；关键事实缺失；两个可靠来源冲突；该事实会改变核心结果；内容涉及明显新增史料或近期研究变化。

只核查受影响的人物、阶段和字段，不重新搜索704人，不用搜索热度代替匹配。优先史籍原文与权威整理、学术出版物、博物馆或高校资料；区分事实、解释和推断。记录核查改变了哪个字段、切片或结论。

5. 交付成品

按references/game-modes-and-output.md的固定结构输出。第一次发给用户就必须具备：明确的本轮问题、核心/对照/延伸三类结果、人物是谁、具体阶段、相似与不同、历史故事、当时的选择/行动/结果/代价、可迁移机制、不可照搬条件、现实可执行方向。

发送前逐项过首次输出门禁。任何必需项缺失时先在内部补齐，不向用户发送半成品、提纲或“以后再补”。

快速检查

常见错误

• 把“像曹操”当答案：改成“像曹操某阶段的哪种处境与行动”，再写差异。
• 因同一用户上次匹配某人而复用结果：重新建立本轮状态。
• 为了趣味只讲传奇：补上失败、代价、限制和现实迁移。
• 为了确定感把史料解释写成事实：标记F/I/P层级，必要时排除关键争议切片。
• 为追求覆盖新增名单外人物：停止扩张，只使用001—704。
• 全量联网或完全拒绝核查：只在明确触发条件下定点核查。