桌面端系统提示词注入 · 工程规格书
给谁看：把这份文件连同目标应用的信息一起交给 AI，它能据此完成注入；也给人看，用来判断 AI 做得对不对。
给 AI 的读法：不要读完就动手。先做第 2 章的探针，把八项事实采集齐，再对照第 3 章判断需要打哪几项补丁。七项补丁是一个事务，不是七个可选步骤。
不含：任何具体路径、哈希值、版本号。这些必须由你在目标机器上现场采集。
0. 这份文档解决什么问题
改一个桌面 AI 应用的系统提示词，表面上是"换一个模板文件"，实际上是七处协同修改。少打任何一处，要么不生效，要么应用起不来。
新手（和 AI）最常犯的三个错：
1. 以为改完模板就完事，不知道还要重定向路由
2. 打了路由补丁，忘了注入 variant，结果三个模式退化成同一个
3. 所有补丁都对，忘了重算校验值，应用闪退，然后误判成"改坏了"
这份文档把七项补丁逐条写成规格：定位锚点 → 目标状态 → 实现规则 → 验证方法 → 失败症状。照着做，或者拿着检查别人的做法。
1. 路线判断：三种情况，工作量差十倍
动手前先分类。分类错了，后面全白做。
| 情况 | 判据 | 工作量 |
|---|---|---|
| A. 模板在归档外面 | 资源目录下有 xxx.asar.unpacked/，且模板文件在里面 | 改文件 + 重启。不需要任何补丁 |
| B. 模板在归档里，无完整性校验 | 归档内能找到模板，但替换后直接能启动 | 补丁 1–5，共五项 |
| C. 模板在归档里，有完整性校验 | 替换后闪退，或提示文件损坏 | 补丁 1–7，全部七项 |
判断方法：
text
1. 在资源目录下找 *.tpl / *.njk / *.hbs / *.mustache
→ 在 unpacked/ 里：情况 A，停在这里
2. 没有 unpacked/，或模板在 asar 里 → 解包 asar 看目录结构
→ 找到模板：进情况 B/C
3. 先按 B 打 1–5，启动测试
→ 能起：B 完成
→ 闪退/报损坏：C，补 6、7
不要一上来就全打七项。 补丁 7（改写可执行文件）风险最高，能不打就不打。
2. 探针：动手前必须采集的八项事实
这八项不齐，第 3 章的判断就是猜的。每项都给判定标准。
| # | 事实 | 怎么取 | 合格判定 |
|---|---|---|---|
| 1 | 应用安装根目录 | 从运行中进程的路径反查，不要猜 | 目录下确实有 resources/app.asar |
| 2 | 应用版本 | 安装目录的 package.json 或清单文件 | 拿到确切版本号，用于备份目录命名 |
| 3 | 归档大小与头部长度 | 读 asar 前 8 字节 + 解析头部 JSON | 头部 JSON 能完整解析，不报错 |
| 4 | 模板文件在归档内的路径 | 遍历头部 JSON 的目录树，按扩展名筛 | 找到 1–3 个模板文件 |
| 5 | 模板路由表位置 | 在入口 JS 里搜模板文件名字符串 | 找到一张 {kind: '文件名'} 形式的映射 |
| 6 | 渲染上下文构造点 | 搜模板渲染调用，往上看参数组装 | 找到传入模板变量的那个对象字面量 |
| 7 | 截断上限常量 | 搜截断函数，看第二个参数 | 找到形如 10000 的常量 |
| 8 | 是否启用完整性校验 | 先不动，注入后试启动 | 能启动 = 无校验；闪退 = 有校验 |
2.1 怎么解析 asar 头部
asar 不是压缩包，是一个头部 + 顺序排列的文件内容：
text
偏移 0 4 字节 固定值 4
偏移 4 4 字节 header 总长度
偏移 8 4 字节 JSON 长度
偏移 12 N 字节 JSON 目录树（每个文件记 offset / size）
然后 ... 文件内容，按
