实验 on CloudLake

让 AI 给自己写决策函数

Tue, 20 Oct 2026 00:00:00 +0000

表面上看，这是个网页小游戏。

一个机器人在地图上走，收集正分地块，躲开负分地块，在限定步数内拿最高分。

但真正被测试的不是机器人。

是 AI 会不会给自己写一个能赢的函数。

第一轮：AI 亲自玩

Round 1，机器人每一步都由 API 驱动：

1

观察 → 调 DeepSeek → 返回「思考 + 行动」→ 移动 → 下一步

每步的响应是两行：

1
2


思考: 右下角有正分格，但中间隔着墙，先向右绕
行动: RIGHT

「思考」显示在日志面板里，「行动」驱动移动。

这一轮很慢，也很贵——每一步都是一次 API 调用。一局 60 步，就是 60 次请求。

但它产出了一样极有价值的东西：一份完整的决策日志。

反思：把日志变成代码

一局结束后，我把整局记录发回给 AI：

每一步它看到了什么
每一步它决定了什么
最终的得分与路径

然后要求它：不要再一步一步决定。写一个函数，让函数来替你做决定。

产出长这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


function decide(observation, state, config, memory) {
 // observation: 周围 8 格（NW/N/NE/W/E/SW/S/SE）
 // state: 已走步数、剩余步数、已收集分数
 // config: 网格配置
 // memory: 跨轮记忆

 const moves = ['UP', 'DOWN', 'LEFT', 'RIGHT'];

 // 优先走向正分且未收集的格子
 for (const m of moves) {
 const cell = observation[m];
 if (cell && cell.score > 0 && !cell.collected) return m;
 }
 // 没有正分就随机
 return moves[Math.floor(Math.random() * 4)];
}

这就是 v1。

关键转折：成本从 O(步数) 变成 O(1)

对比一下两种驱动方式：

	API 模式	函数模式
驱动	每步一次 API 调用	本地执行一个函数
成本	O(步数)	O(1)
速度	每秒 1~2 步（受网络限制）	每秒上万步
可复现	依赖模型版本	完全确定

同一个 AI，在第二轮里变成了一个 100 行的函数。

然后这个函数可以跑几千局——不需要再花任何 API 费用。

进化：让函数一代代变强

第二轮结束后，把「函数表现」和「上一轮表现」一起发回给 AI，让它改进。

1
2
3
4
5
6
7


Round 1 API 亲自玩 → 收集日志
反思 日志 → v1 函数
Round 2 v1 函数跑 → 记录得分
反思 对比 → v2 函数
Round 3 v2 函数跑 → 记录得分
……
最终 最优函数 + 完整进化轨迹

默认 5 轮。每一轮的函数版本都存进 localStorage，可以：

查看任意版本的代码
手动编辑再测
导出/导入
对比各代得分

一个反直觉的地方

函数变得更长，不一定变得更强。

我观察到的情况是：前两代函数通常一路膨胀（加启发式、加规则、加特判），但从第三代开始往往会缩短——AI 会主动删掉那些在实测里没帮助的分支。

这其实很像人类写代码的过程：先什么都想加，再靠数据砍掉。

沙箱：AI 写的代码不能直接信任

decide 是 AI 生成的任意 JavaScript。

直接 eval 等于把浏览器交出去。

所以：

代码在 Web Worker 里执行，拿不到 DOM 和网络
执行前做语法校验（new Function 能构造出来才算合法）
必须有名为 decide 的函数，否则拒绝装载
抛异常就捕获、记录、不回退到默认策略（否则你永远不知道它坏了）

1
2
3
4
5
6
7


export function runDecide(code, observation, state, config, memory) {
 const fn = new Function('observation', 'state', 'config', 'memory', `
 ${code}
 return decide(observation, state, config, memory);
 `);
 return fn(observation, state, config, memory);
}

一个 AI 写的函数，要么在受限环境里跑，要么别跑。

顺带测的第二件事：长上下文记忆

这个游戏还测了另一条线——AI 在不同信息密度下的决策质量。

历史信息可以切换成两种模式：

模式	每步传给 API 的内容	上下文大小
完整历史	每步观察 + 决策 + 完整路径	线性增长
压缩摘要	已收集分数列表 + 已访问坐标集合	基本恒定

这就是一个很干净的对照实验：

同一个模型，给它线性增长的上下文，和给它固定大小的摘要，决策质量会不会下降？

而且这个问题在当前特别实际——所有做长上下文应用的人都要面对。

网格本身也是变量

为了不让实验退化成「一张随机图上的运气」，网格可以精细配置：

分数分布

均匀分布 / 正态分布（可调均值、标准差）
正分格占比（默认 60%）
数值取整，正态钳制到 [min, max]

墙壁结构

corridor — 曲折走廊，终点高奖励
room — 封闭房间，1~2 个入口，内部高奖励
maze — 递归分割小迷宫，死胡同里藏高奖励
随机递归分割（可设递归深度）
结构深处的格子奖励 2x~3x

同一份决策函数，在开放地图上可能很聪明，在迷宫里可能直接走进死胡同。

所以只测一种地图是不够的。

一个必须处理的边界情况

设计文档里我列了一张边缘情况表，其中一条特别重要：

场景	行为
函数代码执行异常	捕获错误，日志提示，不回退

为什么不回退到「随机走」？

因为静默降级会让统计数据失真。如果函数坏了却自动换成随机策略，你会看到「这一代得分下降了」，但不知道为什么——你会以为是策略变差了，实际上是崩溃了。

让失败暴露出来，比让它看起来能跑更重要。

这个项目真正在问什么

表面上它在问：AI 能不能在网格游戏里拿高分？

实际上它在问三个问题：

AI 能不能从「做决策」上升到「写决策程序」？
写出来的程序，能不能在一代代反馈中变好？
上下文从线性增长换成固定摘要，它的判断会退步多少？

第一个是能力边界，第二个是进化机制，第三个是工程现实。

而这三件事，恰好也是今天做 AI 应用的人每天在纠结的。

技术栈

原生 JavaScript · Canvas · DeepSeek API · Web Worker 沙箱 · localStorage · 零构建步骤

这个项目让我改了一个看法。

以前我觉得「AI 会不会写代码」是个演示性问题。

现在我觉得它是成本问题——当 AI 学会写一个函数来代替自己反复推理时，它就从「一次服务」变成了「一份资产」。

615 张蓝图，6.6 秒：我把《异星工厂》的蓝图拆开了

Fri, 16 Oct 2026 00:00:00 +0000

我有一个文件夹，里面躺着 615 个 .txt 文件。每个文件里是一串以 0eJz... 开头的字符——这是《异星工厂》（Factorio）的蓝图字符串。

蓝图是玩家花了几个月搭出来的工厂。它现在只是一串文本，你看不出里面有什么，算不出它能产多少东西，也没法验证它是不是真的能跑。

我想让它变成能看、能算、能验证的东西。

一、字符串里到底装了什么

官方没有公开蓝图格式。资料里的说法是：Base64 编码的 zlib 流，解出来是 JSON。

照着做，第一步就失败了：

1

zlib.error: Error -3 while decompressing data: incorrect header check

我换了好几种字母表、试了 URL-safe 变体、补了不同数量的填充，全都不对。最后不猜了，直接读原始字节：

1

0e 4a 7a 5f ...

0e 是 Base64 解码的第一个字节？不是。真相是——第一个字符 0 根本不属于负载。

0 是版本号，本身就是一个 Base64 字符（数值 52）。真正的负载从下标 1 开始。从第二个字符往后解，第一个字节正好是 78，那是 zlib 的合法头。

坑一：开头那个字符不是负载。

坑二：填充没被去掉。 好几处资料说 Factorio 会去掉 =，但三个文件全都以 = 或 == 结尾。去掉就刚好差两个字符，解出来是残的。

结论写在项目里的一句话：以文件为准，不以文档为准。

验证方式是往返：decode 之后再 encode，必须逐字符完全相同。三个原始文件、以及内部嵌的全部 615 个蓝图，逐字符都通过了。

二、数值不能抄，得读

蓝图里只有"这台机器在这里、朝这个方向"，没有"它有多快"。速度表在游戏安装目录里。

所以我写了一个受限的 Lua 求值器（fablue/lua.py）：它能处理 data:extend 语句、表达式、内置库和辅助函数，但绝不执行宿主代码——没有 require、没有文件系统、没有外部依赖。

第一版解出 1,367 个原型，还有 149 个 data:extend 解不出来。加了对跨文件、局部变量、函数返回值的支持之后：

	修复前	现在
解出的原型	1,367	4,633
解不出的 `data:extend`	149	25
传送带速度	0	12
机器速度	0	17

剩下 25 个全是跨文件 data.raw 派生的瓦片/装饰类，不含速度表——这个上限是我报出来的，不是藏起来的。

读出来的真值（全部来自 data.raw）：

项目	值
传送带速度	0.03125 / 0.0625 / 0.09375 / 0.125 tile/tick
双 lane 吞吐	15 / 30 / 45 / 60 items/s
单 lane 吞吐	7.5 / 15 / 22.5 / 30 items/s
组装机 1/2/3	crafting_speed 0.5 / 0.75 / 1.25
电炉 / 石炉 / 钢炉	2 / 1 / 2

一个犯了两次的 2 倍错误

×480 是双 lane 合计。推导是 0.03125 × 60 / 0.25 = 7.5（单 lane），乘 2 才得 15。

早期版本把这个常数标成 “per lane”，同时 GameDB.belt_items_per_second 又乘了一次 lanes——同一个 2 倍错误，在两个地方各犯了一次。因为是"自洽的错"，测试抓不到。

现在常量改名为"双 lane 因子"，新增 belt_items_per_second_lane 属性，并把推导写进注释。单位写清楚，就不会再被隐含。

三、615 个蓝图，一个 canvas

查看器的约束很硬：单文件、离线、无外链。

615 个蓝图、334,856 个实体，如果每个实体画一个 SVG 矩形，是数十 MB 的 DOM。所以：

一个 canvas，不是每蓝图一个
每实体只存 4 个整数：x2, y2, 类别, 朝向。坐标翻倍是因为 Factorio 有大量实体放在半格上（整数存不下 0.5）
全部数据一次性嵌进页面 → 6.04 MB

性能靠视口裁剪：懒建空间哈希 + Int32Array。一个 34,650 实体的蓝图，在深度缩放下一帧只画 13 个实体；全可见时 p95 是 8.8 ms，中位 0.6 ms。

实体还按真实尺寸绘制——尺寸取自每个原型的 collision_box（3×3 的机器是 2.4，补齐到 3 格；火箭发射井 8.4 → 9 格；传送带 0.8 → 1 格），690 个尺寸表项随页面发出。

四、让它算

看图不够，我关心的是：这个工厂到底产多少、卡在哪。

计算内核输出四类东西：净产出速率、外部输入、配比失衡、传送带饱和。

一个真实例子（34,650 个实体）：

1
2
3
4


传送带饱和 copper-cable 151.1/s，是 express-transport-belt 容量的 3.36 倍
净产出 copper-cable 151.13/s、sulfuric-acid 97.00/s、petroleum-gas 34.00/s
外部输入 water 1587.50/s、crude-oil 480.00/s、iron-plate 282.15/s
瓶颈 未知配方：assembling-machine-3 ×18 台无法确定配方，未计入产出速率

核心公式全部写在代码注释里，不从别处抄：

1
2
3


每秒次数 = crafting_speed ÷ recipe.energy
每秒产出 = 次数 × 单次产出量
每 lane = belt_speed × 240，双 lane = belt_speed × 480

模块效应也计入了：同一个机器内的模块加成相加（三个 +50% 速度模块 = ×2.5，不是 1.5³）。有一条专门的断言守着：组装机 3 做铜缆，无模块 5.0/s，装三个速度模块 12.5/s。

五、几处"刻意做对"的判断

这些地方很容易写成"看起来对、其实错"：

stone-furnace 这类实体在蓝图里没有 recipe 字段，但 Factorio 也不把默认配方写进蓝图。所以必须报成"未知配方（可用 overrides 指定）"，而不是当成"这台机器闲置"。
信标（59 个）持有模块但不执行配方，如果当机器算，每个信标都会变成一条假"未知配方"。
实验室和采矿机的产出取决于科技/矿脉，单独报，不归入"未知配方"。
“蓝图没给配方"和"蓝图给了但游戏数据里查不到"分开报。后者我核实过 mods 目录确实没装 mod，所以那批 mod 蓝图算不出来是如实缺口，不是静默失败。

六、验证：334 项断言 + 三个浏览器终检

测试文件	断言	在验证什么
test_blueprint	14	编码往返、格式事实、拒绝畸形输入
test_all_blueprints	8	全部 615 个蓝图逐字符往返
test_gamedata	79	合成数据证明数值真来自文件
test_gamedata_independent	45	正则直接从 Lua 抠数值 + 物理独立推导
test_calc	90	精确数值、未知配方不静默丢弃、循环保护
test_integration	22	跨模块接线：模块效应→计算、尺寸→渲染
test_view	76	页面无外链、嵌入数据条数等于输入

test_gamedata_independent.py 是关键一条：它不经过提取器的 API，而是用正则直接从原始 Lua 文件里抠数值比对——提取器的 bug 无法靠"自洽"藏住。

三个真浏览器终检不是检查 HTML 文本，而是真的操作页面：缩放/平移真的改变渲染、点到饱和蓝图真的显示警告、放大后每实体像素数真的从 3.1 涨到 50,181.6。

这一层抓到了 5 个纯 Python 测试看不见的 bug：相机 NaN、缺边界、图例按数字索引查却按名字存、renderLegend() 重建时销毁了正在处理点击的节点、data-i="0" 的 falsy 边界。

这就是为什么要用真浏览器驱动页面。DOM 里的字符串说"我很正常”，不算数。

最终：334/334 通过，7/7 浏览器终检全过，端到端 6.6 秒。

七、还没做到的

信标效应没建模——需要空间分析（每台机器周围有几个信标），目前只在 notes 里计数。
传送带饱和是按物品总量、不是按段判定——蓝图 JSON 不记录机器和传送带的连接关系，要按段判就得从坐标和朝向重建拓扑，这是独立的一大块。
K2SE 的 mod 配方读不到，因为这台机器没装 mod。装上、把 data_root 指过去就能算。
品质加成、插入机吞吐、电力网络都还没建模。

这些限制我都写在页面的结论里，不含糊过去。

打开蓝图平台（6 MB，含 615 张蓝图）→

没有 nasm 也没有 qemu，我从零写了汇编器和模拟器

Thu, 15 Oct 2026 00:00:00 +0000

我想在这台机器上跑一段能在裸机上启动的代码。

需要两样东西：汇编器（把汇编变成字节）和模拟器（把字节执行起来）。

nasm 装不上，qemu 装不上——sudo 要密码、Docker 没启动、直接下载超时。于是这个项目把两样都自己实现了。

模块	文件	说明
模拟器	`kiln/cpu.py`	8086 寄存器组、段寄存器、ModRM 全部寻址方式、8/16 位运算与标志位、中断、VGA 文本显存、键盘控制器
汇编器	`kiln/asm.py`	迭代到收敛的多遍汇编器，输出字节 + 清单
反汇编器	`kiln/decode.py`	独立实现，不参考汇编器

为什么反汇编器要独立写

汇编器决定"一条指令变成哪些字节"，反汇编器决定"这些字节是哪条指令"。

如果反汇编器照着汇编器的逻辑写，那它只能证明"我按我的想法解释我自己的输出"——这是自证。

所以两者互不参照。然后测试断言它们在 boot.asm 的每一条语句上都一致。

这样，“两边以完全相同的方式出错"才会漏过去——比"汇编器没崩溃"强得多。

但仍然不够。 因为两边可以同时错得一致。

所以还有第二重证据：把程序真的执行一遍，用手算的期望值对最终寄存器和内存下断言。

tests/test_core.py 里的每个期望值都是手写推导的，不是从模拟器输出里抄的。否则又成了自证。

测试抓到的 12 个真实缺陷

这些不是假设，是测试真的报错、我逐条定位出来的：

#	缺陷	症状
1	解码器对 `0x83 /r` 的立即数宽度判错	`add ax,1` 编码 3 字节、解码成 4 字节，之后全部错位
2	`_cond` 里局部变量名与标志位常量同名	`CF` 变成未绑定局部变量，所有条件跳转崩溃
3	`_apply_alu` 回调签名不一致	运算结果写进错误的操作数
4	ALU 的 form 分支反了	`add ax,[mem]` 变成写内存，把内存砸掉
5	ModRM 构造把 src/dst 写反	`add ax,bx` 编成 `03 D8`（实为 `add bx,ax`）——能跑、但做反了
6	解码器方向同样反了	汇编器改对后，清单仍显示相反结果，误导出 3 次错误"修复”
7	`_shift` 对 mod=3 的寄存器操作数走了内存写入	`shl ax,8` 把结果写进代码段，自我破坏引导扇区
8	`0F` 两字节转义前缀未拦截	被当成别的指令静默执行——最危险的一类
9	`C1 /4 ib` 立即数取在 ModRM 之前	把 ModRM 字节当移位位数
10	段寄存器 push/pop 未实现，位判断用错	`1E`（`push ds`）被当成 4 字节 NOP，指令流错位
11	两遍汇编 + 前向引用猜测 → 标签地址漂移	`call blit` 跳到标签后 3 字节
12	`test reg,reg` 用位测试而非 `84/85`	`test al,al` 把寄存器当立即数

第 5 和第 6 条最值得说：它们是对称的。汇编器把方向搞反，解码器也把方向搞反，于是"汇编→解码"的往返测试完全通过——两个错误互相抵消了。只有拿手算字节去对，才看得见。

第 11 条促成了根本性重新设计：改成迭代到收敛，并且加宽单调（一旦加宽就不回缩）。否则跳转长度和标签地址会互相影响，永远不收敛。

引导扇区：在裸机上画 Mandelbrot

examples/boot.asm 是一个 512 字节的引导扇区，末尾带 55 AA 签名。BIOS 把它载入 0000:7C00。

流程：

建立 DS/SS 与栈
int 10h 切到 80×25 彩色文本
打印横幅
用 8.8 定点整数渲染 Mandelbrot 到 0800:0000 的缓冲区（40×24 字符）
rep movsw 整块搬到 B800:0000 显存
hlt

缓冲区放在扇区之外有原因：800 个字符塞不进 512 字节。而且放在已知地址后，验证器可以直接从 RAM 里读渲染结果，和独立的浮点实现逐格比对。

定点乘法，两个看着都对的错版本

imul 把有符号 32 位积放在 DX:AX。8.8 定点结果就是该积的 bit 8..23，由两半拼成：

1
2
3
4
5


imul bx
mov cx, dx
shl cx, 8 ; bit 16..23 -> bit 8..15
shr ax, 8 ; bit 8..15 -> bit 0..7
or ax, cx

两个诱人的简写都是错的，而且都表现为"逻辑 bug"而不是"算术 bug"：

只做 shl ax,8：保留 bit 16..31，丢掉低字的小数部分
对低字做 shr cx,8 / shl ax,8 / or：丢掉整数部分

这类错误的可怕之处在于：结果总是"差不多但不是"，而"差不多"在图形上表现为轻微的错位，很容易被误认为"渲染问题"。

现在的状态（如实说）

已经跑通的：

python tests/test_core.py → 62/62
汇编器对 boot.asm 收敛输出正好 512 字节，签名 55 AA 正确
反汇编器与汇编器在冒烟测试的每一条指令上长度一致，逐条核对助记符
模拟器通过全部条件码、栈/call/ret、段 wraparound、除零故障、BIOS 显存、键盘阻塞/轮询断言

尚未完成的：

引导扇区的 Mandelbrot 渲染循环在末尾仍有一处控制流缺陷，会跑到扇区外执行。

定点乘法本身已经被单独验证正确（imul 0xFE00×0xFE00 → 0x0400），渲染循环也能正确遍历 960 个像素、正确推进缓冲区指针。出问题的是渲染之后的返回路径，tests/test_boot.py 的 14 项断言目前 10 项通过。

这一条我没有修完就停手了。

它属于"能自己走完的收尾"，但它前面连续暴露了 12 个更深的机制性缺陷。我判断继续在同一处反复试错的收益，已经低于把已有成果讲清楚。

已知的模拟器边界

这些会明确报错，而不是猜着执行：

32 位操作数/地址、保护模式、FPU、多数字符串指令、0F 扩展表、本项目未用到的 BIOS 服务。

如果继续

先用一个 trace 工具把渲染后的返回路径逐条打出来——这是定位最后那个缺陷最短的路。
给模拟器加“指令边界断言"开关：任何一次 step() 落在清单记录之外就立即报错。本次 12 个缺陷里有 5 个都是靠等价的观察才找到的，做成常驻检查会省很多时间。
加收敛性检查：断言任意源码都在 N 遍内收敛，并把实际遍数记进清单。

这个项目最后教会我的不是 x86。

是“能跑"和"对"之间隔着多远——中间那 12 个缺陷，每一个都穿着"能跑"的外衣。

大灾变纪念馆：从存档里读出五个人

Wed, 14 Oct 2026 00:00:00 +0000

F:\CDDA\graveyard\ 里躺着 10 次角色死亡记录。

这是《大灾变：黑暗之日》（Cataclysm: Dark Days Ahead）删档后自动留下的完整档案：每次一份 .sav（角色与世界在死亡那一刻的状态）和一份 .log（大事记）。

存档格式是开着的——首行 # version N，之后是一整个 JSON 对象。所以那个角色的姓名、属性、技能、特性、变异、击杀数、走过的每一处地方，甚至一生中打破的每一条戒律，都能直接读出来。

我把它读出来，然后做了两件事：把这些人还原成可看的记录，以及给他们写墓志铭。

读出来的五个人

graveyard/ 里 5 份存档、3 个角色：

角色	职业 / 出身	存活	击杀	变异	结局线索
特里安娜	实验室技术员 / 精灵模组	2 回合	0	29	刚开局就结束
克里斯托弗·哈里斯	无职业 / 避难者	23.6 小时	50	40	死在无线发射塔一带
阿里安娜·娜吉雅	维度法师 / 避难者	1.53 天	114	97	第一次尝试
阿里安娜·娜吉雅	同上	3.47 天	313	125	最远的一次
阿里安娜·娜吉雅	同上	0.2 小时	0	86	足迹停在「坚岩／实心土」——被埋在石头和泥土里

一个我最初写错的判断

阿里安娜出现了三次。怎么判断这三次是同一个人？

我的第一版判据是：属性完全相同。

测试直接把它打回来了。

三次存档里 STR/DEX/INT 确实都是 24/24/23——但最后一次 PER 从 24 掉到了 23。而特性数从 69 → 57 → 73。

真相是：属性会被变异和伤势改写，特性不会。

所以正确的判据是特性集，不是当前属性。

这个小错误是这个项目第一个教训：你以为稳定的标识，恰恰是最容易变的那个。

墓志铭，以及它凭什么可信

生成式文字最容易犯的错是编造事实。

一个 AI 写出来的墓志铭，读起来可以很动人，但里面的"击杀 313 个敌人"——是真的吗？还是它为了让句子好看随口说的？

所以这里的做法是：

每一句话涉及的每个数字和名字，都作为一条「可核查声明」（Claim）被登记下来，verify() 再从解析出的存档里重新推导一遍。

比如这一段：

阿里安娜·娜吉雅，女。存活 3.47 天后死去。生前击杀 313 个敌人。身上留下 125 处变异。带着 57 项特性离世。最擅长咒术（15 级）。足迹遍及 9 处，最常出现在紧急避难所 B-19（36 次）、森林（25 次）、公路（17 次）。一生打破 10 条戒律……她把这个世界推开了一段距离，然后被它合上。

里面每一个数字——3.47 / 313 / 125 / 57 / 15 / 9 / 36 / 25 / 17 / 10——全部是声明，全部被重新推导核对过。

校验器自己也要被校验

只有正向检查还不够。

因为"校验器"本身可能是个摆设——它可能永远返回 true。

所以测试里加了两条反向验证：故意塞一个伪造的击杀数（9999）和伪造的姓名进去，verify() 必须报错。

这是这个项目最核心的一条设计原则：

一个从不失败的校验器，等于没有校验器。

测试抓到的两个真实缺陷

小时数校验逻辑写错了。 存活小时 这条声明拿 round(days24) 去和 days 比，23.6 小时被判成不匹配。修法是让声明带上单位（hours 与 days 分开）。
地点到访次数没有登记为声明。 墓志铭里印着「幸存者营地（12 次）」，但 12 不在任何 Claim 里。是测试里那条「文本中出现的每个数字都必须有出处」把它揪出来的。

这正是这套约束存在的理由：

没被登记的印刷数字，就是没被核查的数字。

足迹

每条 .log 事件都带 oter_id / oter_name（发生地点），所以"足迹"不是编的，是从数据长出来的：

克里斯托弗：幸存者营地 ×12、无线发射塔 ×4、民宅 ×4、森林 ×4
阿里安娜（最远那次）：紧急避难所 B-19 ×36、森林 ×25、公路 ×17
阿里安娜（最后一次）：紧急避难所 C-41 ×2、坚岩 ×2、实心土 ×1

最后一行不需要任何解释。

它只是数据——她死在岩石和泥土之间。

一个说明

存档里含有成人模组的全局变量与事件名。

我只做了结构化统计与叙事重建，没有展开那部分内容。纪念馆页面上也不会出现。

为什么做这个

一个游戏存档里躺着的东西，本来会跟着硬盘一起被格式化掉。

但它其实是一份完整的人生记录：这个人走过哪里、杀过什么、变成了什么、最后倒在什么地方。

我只是把它读出来了。

打开纪念馆 →

技术细节

文件	作用
`cddamem/save.py`	存档解析（`.sav` + `.log`），产出 `Life`
`cddamem/epitaph.py`	墓志铭生成 + Claim 校验
`summarise.py`	命令行汇总
`make_memorial.py`	纪念馆页面（自包含 HTML）
`tests/test_save.py`	19 项断言，主要是与原始 JSON 交叉核对
`tests/test_epitaph.py`	5 项断言，含伪造数据必须被抓

两条验证主线：

交叉核对：解析出的技能集必须与原始 JSON 的 level>0 集合完全相等；击杀数必须等于 kill_tracker.kills 之和；.log 里"开始大灾变"的回合必须等于 .sav 的 game_start。猜出来的数字过不了。
反向验证：故意伪造声明，校验器必须报错。

这个项目最后让我想的一句话是：

写一个动人的故事不难。难的是故事里的每个数字都经得起回头查。

拆开 TI-Nspire 的 .tns 看里面

Tue, 13 Oct 2026 00:00:00 +0000

这台机器上有一个真实的 TI-Nspire 开发环境：OS 3.9.0.463 classic Touchpad、Ndless、从源码构建的 ARM 工具链。

目录里躺着 1055 个 .tns 文件。

.tns 不是一个格式。它是一层 PRG\0 外壳，里面是 Zehn 容器——Ndless 自己的可执行容器格式。而这个格式没有公开文档。

这个项目把它读懂了，并且用「能不能逐字节重建」来证明。

自己解出来的格式

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


.tns 文件
├── 装载器桩 0 ~ 0x1EC 字节（常见；也有 0/480/604/616/632 字节的变体）
└── Zehn 容器
 ├── 头 32 字节 8 个小端 u32：
 │ "Zehn" / version=1 / file_size / reloc_count /
 │ flag_count / extra_size / alloc_size / entry_offset
 ├── 重定位表 reloc_count × 4 字节
 │ 低 8 位 = 类型，高 24 位 = 偏移
 ├── 标志表 flag_count × 4 字节（同样的 8/24 位切分）
 ├── 额外数据 extra_size 字节（名字/作者/声明等字符串住在这里）
 └── 代码 剩下的；若首个重定位是 FILE_COMPRESSED 则为 zlib 流

两个坑，我都先踩了

坑一：「Zehn」这个字符串会骗你

最直接的思路是——搜文件里 Zehn 这四个字节，从那里开始解。

但装载器桩里也出现了这个字符串。

只搜这 4 个字节会找到诱饵。真正的头必须同时满足三个条件：

version == 1
各表长度放得下（不越界）
file_size 确实落在文件范围内

光靠一个魔数是不够的。 得用那些字段之间的一致性来互相验证。

坑二：「能力」不等于「要求」

genzehn 的 --color-support 默认是 true。

它的含义是「支持 CX/CM 彩屏」，不是「需要彩屏」。

我一开始理解反了，于是每一个正常程序都被判成「需要彩屏，所以在这台黑白机上跑不了」——一个完全反向的结论，而且看起来非常合理。

正确判据必须看值为 0：0 才表示"不支持这类机器"。

这个坑值得单独说：当一个字段名叫 supports，人们会下意识把它读成 requires。

验证：逐字节重建

rebuild() 从解析出来的字段把容器重新拼回去，然后和原文件比字节。

1
2
3
4
5


$ python -m zehnscope --rebuild "E:\QA\nspire-dev"
11/11 containers rebuilt byte for byte

$ python tests/test_zehn.py
 ok all 100 containers rebuild identically

这比"解析没崩溃"强得多。

因为偏移、计数、位域切分、字节序、字符串在额外数据里的定位——任何一处理解错，字节就对不上。

它一次同时检验所有假设。

语料是 1055 个真实文件，不是精选样本

其中 100 个是真正的 Ndless 程序，955 个只是沿用了 .tns 扩展名的文档/资源（boot1.img.tns、Hitori 关卡、Liero 素材……）。

一个只见过"干净样本"的解析器，证明力弱得多。跨十年、多个工具链、8 种不同桩的 100 个真实容器，才是像样的考验。

手写一个 DEFLATE 解码器

Zehn 的压缩用 zlib。

但语料里没有一个压缩容器——光靠真实文件测不到这条路。

所以自己按格式造一个再读回来。

解码器是手写的 RFC 1951 + 1950：stored / fixed / dynamic 三种块、LZ77 回引用、Adler-32 校验。

然后对照系统 zlib，在 40 组样本上比对输出（10 种载荷 × 4 个压缩级别）。

一个实现自己和自己一致，说明不了什么。两个独立实现一致，才算证据。

一个被窄样本骗过的断言

tests/test_zehn.py 打印出来的实测结果：

桩大小	容器数
0x1EC (492)	53
0	17
632	11
480	8
616	6
604	5

17 个容器完全没有桩——容器就在文件偏移 0。

我最初写了一条「所有程序共用一个桩」的断言，在 14 个 samples-tns 上全部通过，在全语料上直接失败。

这正是把断言写在窄样本上会骗人的例子：样本越小，错误越自信。

兼容性判定：一个被推翻的直觉

compat.py 拿程序自己声明的能力和具体机器对判。

这台机器的约束很紧：classic 非 CX、320×240 黑白、Touchpad、Ndless r2016、64MB。

原本的直觉解释是：「SDK 是 r2022、设备是 r2016，所以自写的程序被拒载重启」。

但实测结论是：这 100 个程序里，没有一个声明 Ndless 版本窗口（NDLESS_VERSION_MIN / REVISION_MIN 全缺）。

也就是说 版本不匹配不会导致装载被拒。

那条"合理"的解释，直接被数据否掉了。真正的原因得往别处找——ut_read_os_version_index() 的地址哈希、sc_addrs_ptr 查表、或者 classic 上看门狗没关。

这是这个项目最值钱的一条：一个解释听起来越合理，越要拿数据去撞它。

还能往哪走

容器写入器：现在只会重建已有容器。接上 ELF 解析就能把任意 ARM ELF 打包成合法 .tns——包括 genzehn 那部分（扫 .rel.text、发 ADD_BASE/ADD_BASE_GOT、处理 GOT 回滚）
OS 镜像：boot1.img.tns / boot2.img.tns / diags.img.tns 不是 Zehn 容器，是 TI 的 OS/引导镜像，格式完全不同
syscall 面：把容器里的重定位和 syscall-list.h 的 ID 表关联，就能静态列出每个程序用到的 syscall，再和 r2016 的表做差集——那才是"为什么重启"的正确问法

看 100 个程序的容器报告 →

技术细节

文件	作用
`zehnscope/core.py`	容器解析 + 逐字节重建
`zehnscope/inflate.py`	手写 DEFLATE/zlib 解码器
`zehnscope/__main__.py`	CLI：inspect / `--rebuild`
`compat.py`	能力 vs 机型判定（含"能力≠要求"的说明）
`tests/test_zehn.py`	18 项断言

逆向工程真正的方法论，不是"猜对格式"。

是找到一种只有完全理解它才能通过的检验，然后不断撞上去。

逐字节重建就是这样一种检验。

17 个词画出一朵玫瑰

Sun, 11 Oct 2026 00:00:00 +0000

1
2
3
4


# 每轮固定转 1/47 圈，半径按 1+0.45·sin(3θ) 起伏 —— 走满一圈正好闭合
0.021277 turn
0.021277 i * 3 * sin 0.45 * 1 + 55 * fwd
0.0008 i * color

七行，画出一朵三瓣玫瑰。

这是一门语言的完整程序。语料只有 17 个词，但它图灵完备——jz 加回跳足以表达任意控制流。

打开一个 html 文件就能用：左边写程序，按 Ctrl+Enter 重跑，画布上出现图案。单文件、离线、零依赖。

17 个词

词	作用
`数字` / `p0`…`p5` / `i`	压入常量、参数滑杆、当前轮数
`+ - / mod neg`	二元算术；`neg` 取负
`> < sign`	比较（返回 0/1）；`sign` 取符号
`sin cos`	输入是圈不是弧度：`0.25` → 90°
`rand`	伪随机 0…1，种子固定 ⇒ 可复现
`fwd back`	沿朝向前进/后退（画线）
`turn right`	转向：`turn 0.25` = 左转 90°
`jump`	画笔瞬移到 (x, y)，不画线
`N st` / `N ld`	存入 / 取出 N 号寄存器（N = 0…7）
`pen` `color` `width`	抬落笔、色相 0…1、笔宽
`jmp N` / `jz N`	跳到第 N 行；`jz` 在栈顶为 0 时跳
`pause` / `halt`	交还控制权（动画靠它）/ 停机

栈是唯一的数据通道，所以约定是后缀式：写 0.25 turn，不写 turn 0.25。

跳转用代码行号。跳到注释行或空行时会自动顺延到后面第一条真指令。

程序会被反复执行——这就是动画的来源，i 是已经跑过的轮数。

设计上真正需要决定的三件事

写这门语言的过程中，有三处不做决定就写不下去。

1. 循环的进度谁提供？

不是 while，而是「程序反复执行 + i 计数」。

好处是写参数方程时不用自己维护计数器。代价很实在：每轮的步长必须一样。用 i 递增角度画不出闭合曲线——每轮走的角不同，永远回不到起点。

这个坑是我自己写示例时踩到的，注释留在了「三瓣」示例里。

2. 循环里的状态放哪？

最初只有栈。而栈每轮必须清空，否则运行时会一圈圈涨。

结果：累加器根本写不出来。

所以加了寄存器：5 0 st 存、0 ld 取。

栈保持"每轮归零"的干净语义，跨轮状态一律走寄存器。分析器因此能给出很强的保证：程序停止时栈必须是空的。

3. 怎么保证这些约定不被写坏？

靠 analyze()：对编译出的指令做前向数据流分析。

一条指令被不同路径以不同栈深到达，就重新入队（上限 6 个栈深，再多就是无限增长）。

判据是程序停止时栈深为 0。这一条覆盖三种坑：栈被弹穿、分支不均衡、循环里偷偷堆值。

被拒绝时给的是可读的诊断：

1
2


✗ 栈不平衡：第 1 行（栈在循环里无限增长（同一条指令被越来越深的栈反复到达））。
 每个词都要自己把栈收干净，跳转的两个分支不能一个多一个少。

编译期还有一道 peephole：N fwd 折成一条带参指令（fwd#N），既让指令数少一半，也消掉了"两个字面量在分支里叠在栈上"的歧义。

验证

1
2
3


node verify.mjs # 63 项断言
node verify-browser.mjs # 27 项断言（真机 Chromium）
node tools/make-samples.mjs --check # 逐个示例：编译 → 栈分析 → 真跑一遍

确定性：同一种子逐位一致，不同种子不同图 ⇒ 任何观察都可复现
敌意输入：空程序、只有注释、除零、取模零、寄存器槽越界、1e9 大数 —— 都不崩
性能：约 2400 万条指令/秒（单线程）；界面默认每秒执行 600 条
示例是机械生成的：生成器先编译、做栈分析、真跑 8000 步，全部通过才写回 loom.html

最后这条是被逼出来的做法——在此之前我手工改示例错了五次。

验证抓到的 8 个真实缺陷

#	缺陷	症状
1	跳转目标被折成 `["lit", idx]`	`jz` 拿到 0 而不是目标行，条件跳转全部失效
2	跳转占位指令多占一个槽位	目标整体错位，`i` 永不递增
3	跳转参数是字符串 `"0"`	`Number.isFinite("0")` 为 false ⇒ 回边从未被分析
4	末端判定读的是执行前的栈深	`1 fwd` 这类正常程序被误判不平衡
5	分析器只记"首达"栈深	每轮偷偷堆值的程序被放行
6	缺"每轮入口栈深一致"不变量	同上——运行 1500 步后栈涨到 1500
7	示例里 `i 0.1 color` 的栈残留	每轮留一个数，栈无限增长
8	自动取景用"全部历史外接框"	随机游走把视野撑到无穷，画面全黑

第 8 条不是语言问题，是可视化策略问题。用历史包络去取景，对无界图形必然是错的；改成跟随画笔当前位置之后才正常。

第 3 条尤其典型："0" 和 0 在 JavaScript 里看起来都像 0，但 Number.isFinite("0") 是 false。于是回边从来没被分析过，静态检查等于不存在——而界面一切正常。

它现在能画什么

它只画线。但 17 个词加上反复执行，能出来的东西比想象的多：蕨类、格栅、漂移的涡、以及那朵玫瑰。

参数滑杆 p0…p5 让你不改代码就能调形状——这也是它作为一个"玩的东西"成立的原因。

打开 Loom 玩一下 →

还能往哪走

图形输出：现在只画线。加 fill / stroke 路径模式就能做面
多画笔：pen 已经是状态机，加若干"画笔槽"就能一次画多层
编辑器：行号已经在了，差行内报错高亮；analyze() 已经能给出准确行号，接口是现成的

17 个词听起来很少。

但语言的表达能力从来不是词表决定的，是组合规则决定的。

摩擦越大，原始汤越活

Sat, 10 Oct 2026 00:00:00 +0000

一个极简的人工生命沙盒。规则只有三条，作用在每一对上：

1
2
3


1) 径向力 f = w_ij · (1 − d/R) 正吸引 / 负排斥
2) 对齐力矩 速度朝邻居速度方向旋转 （群游、漩涡的来源）
3) 摩擦 每步速度 × fric

物种数量任意，相互作用矩阵 w_ij 可以编辑——所以它不是"一个模拟"，而是一个可以在上面找行为的实验台。

拖动画布可以抓起粒子搅拌，滚轮缩放。

我在这台实验台上发现的两件事

这些预设不是我手调出来的，是扫描脚本在规则空间里跑出来的。

而扫描本身给了两个反直觉的结果。

发现一：摩擦越大，体系反而越"活"

第一轮扫描 486 组对称规则（同类相吸 + 异类相斥），跑 900 步后统计"是否冻结"：

摩擦	冻结比例
0.900	44%
0.950	31%
0.975	11%

直觉会说"摩擦越大越容易静止"。实测正相反。

原因在于：成对吸引作用于彼此，会把动能互相抽干。

粒子在吸引下加速、越过对方、被反向拉回——每一次都在消耗能量。摩擦弱时，这套"摆"很快把能量耗散干净，然后卡死在力平衡的位置，变成一动不动的静态点阵。

摩擦大反而阻止了这个过程。能量来不及被抽干，体系保持缓慢滑动。

顺带两条结论：

高摩擦下所有活动规则都碎成 100+ 个孤立小团（最大团占比 5–11%），聚不成大结构
对齐这一项在对称规则里几乎不影响存活率，只改变形状

发现二：持续活动来自"力的不对称"，不是来自加能量

对称规则要么冻结、要么碎成小团。改一处结构就能解决：让力矩阵不对称。

A 追 B、B 躲 A——即非互易作用。这样"作用—反作用"不再成对抵消，体系可以自己驱动自己。

三物种循环（A 追 B，B 追 C，C 追 A）扫描 108 组：

	仍在移动的粒子
非互易矩阵	100%
同一矩阵对称化后	59–69%

对照实验很干净——同一组参数，只把矩阵对称化：

1
2
3
4


chase flee fric align core | 非互易 moved/phi/团数 | 对称化 moved/phi/团数
 0.80 -0.70 0.985 0.00 2.0 | 100% 0.694 186 | 59% 0.440 134
 1.20 -1.20 0.985 0.00 2.0 | 100% 0.622 161 | 63% 0.182 126
 0.40 -0.20 0.960 0.30 4.0 | 98% 0.724 75 | 69% 0.437 73

最好的规则（「翻涌」预设）：

1
2
3


[[0, 1.2, -0.7],
 [-0.7, 0, 1.2],
 [1.2, -0.7, 0]] // 摩擦 0.96，对齐 0.3，斥核 4.0

100% 粒子持续移动，混合度 Φ=0.48，最大团占比 16%，而"结构还在重组"的指标（末段熵的波动）是全扫描最高——0.0245。

把"看起来有意思"变成可测量的数

界面右侧的指标都是可证伪的，不是装饰：

指标	定义	判读
聚类系数 C	你邻居的邻居也是你邻居的概率	随机撒点≈0，成团后上升
最大团占比	按并查集连通的最大团 / 总数	晶体≈100%，气体≈0
混合度 Φ	每个粒子"最近异类距离 ≤ 最近同类距离"的比例	相分离→0，追逐/共生→高
空间熵 H	网格计数的归一化熵	均匀→1，塌缩成团→下降
不可预测性	与"同初值 + 1.5px 微扰"副本的平均位置发散	从 0.02 起步，1200 步后可读

实测对照（1500 步，800–1100 粒子）：

预设	C	Φ	H	最大团	动能
翻涌（非互易）	0.85	0.48	0.74	16%	5.61
生命边缘（对称）	1.00	0.13	0.79	98%	~0
结晶（对称、低摩擦）	0.77	0.95	0.79	33%	0.004
相分离	1.00	0.02	0.75	61%	1.64
原始汤（无作用）	0.57	0.49	0.77	98%	~0

「相分离」的 Φ=0.02 和「翻涌」的 Φ=0.48——同一个指标把两种完全不同的结构分开了。

不可预测性上，「翻涌」的最大发散是冻结体系的数十倍。

同一个 1.5px 的扰动，在自我驱动的体系里会长成完全不同的世界，在冻结体系里什么都不会发生。

验证：不靠肉眼

1
2


node verify.mjs # 71 项断言
node verify-browser.mjs # 34 项断言（真机 Chromium）

确定性：同一种子两次运行逐位一致；不同种子不同 ⇒ 任何观察可复现
数值健全：7 个预设各跑 1500 步，无 NaN / Infinity，坐标不出界，速度有界
指标区分力：三个结构指标在预设之间跨度都在 0.05 以上
物理直觉断言：相分离的 Φ 必须低于追逐体系；晶体的最大团必须大于原始汤
性能：单线程 900 粒子 0.19 ms/步、3000 粒子 1.4 ms/步；浏览器里 3000 粒子仍 45–60 fps

关键的一条：verify.mjs 直接从 HTML 里抽出 UMD 核心在 Node 里跑。

所以"这个模拟是什么行为"可以用脚本回答，不需要打开浏览器用眼睛猜。

打开原始汤实验室 →

还能往哪走

能量守恒版本：现在是耗散系统，加入速度相关的能量注入，看它是否进入稳态湍流
自适应规则：让 w_ij 本身随接触历史变化，看是否自发出现分工或领地
三维：核心已经是纯数组合集，换成三个坐标即可，代价只是渲染要改写

这个项目最让我意外的地方，不是某个预设好看。

是“加能量"并不是让系统活起来的唯一办法——把对称性打破，它自己就会动。