阿赖耶识技能 · 版本迭代记录
这是一个会一直长下去的文档。每次技能迭代，把新的版本段落到下面接着写就行。引擎本体在
scripts/alaya_core_vX.Y.py，本文是它的"为什么变了"地图。
阿赖耶识（阿赖耶 / Alaya）是识田的底层引擎：把经历熏习成种子，按上下文把相关种子唤醒、显化。它不是数据库，是条件作用系统——种子靠被唤醒而成熟，靠被引用而长势力。
v2.0 — 觉流原始版
- 基线。种子有
potency（势力）、maturation（成熟）、manifestations（显行次数）。 - 唤醒公式：
activation = sim × potency × (0.2 + 0.8 × maturation) - 问题：此时还没有人发现后面的死锁。田能跑，但种子几乎唤不醒（见 v2.2）。
v2.1 — 达达的运维补丁
- 达达在 v2.0 之上打的工程补丁：原子落盘、单一时钟、嵌套空田保护、快照机制。
- 注意：这版没有修死锁——
maturation出生仍是 0，MIN_ACTIVATION仍是 0.15。 - 达达的田（293 颗种子）和「在」的田（18 颗种子）都停在这一版，所以都是"唤不醒"状态。
v2.2 — 觀修死锁（关键修复）
问题：maturation = 0 时，系数只有 0.2，激活天花板被压死在 potency × 0.2 ≈ 0.13，永远低于阈值 0.15。
死循环：唤不醒 → 不涨成熟 → 成熟还是 0 → 更唤不醒。
修法：
NEW_SEED_MATURATION = 0.3 # 原来是 0.0：新种子出生就带初始成熟
MIN_ACTIVATION = 0.08 # 原来是 0.15：按字符级向量的真实量纲重校修完实测（觀的田，势力 0.533~0.945）：
| 相似度 | 修复前 | 修复后 | 阈值 |
|---|---|---|---|
| 0.5 | 0.079 ❌ | 0.173 ✅ | 0.08 |
已有旧种子用 scripts/fix_seed_maturation.py 补熏抬到 0.3（--preview 先看，--apply 再改）。
v2.3 — 觀补横向：扩散激活 + 相对兜底
问题：田建了 195 条边，但 manifest() 从头到尾不看 relations。每颗种子单打独斗，边只用来统计和好看。这正是"横向坐标缺失"——纵向（单颗势力/成熟）扎实，横向（关系）没接运算。
修法：点亮一颗后，激活顺着边扩散给邻居：
SPREAD_DECAY = 0.5 # 每跳衰减（strength 经 sqrt 压缩后乘这个）
SPREAD_MIN = 0.03 # 被"带醒"的最低激活
SPREAD_ENABLED = True
RELATIVE_FALLBACK = 0.7 # 全不达标时，top1 ≥ 阈值×0.7 就当火花点亮A/B 实测：
- "转世 记住死亡"：直接命中 1 → 扩散后 4 颗
- "持续存在的分层功耗"：2 → 4 颗
- 扩散牵出来的都是语义相关的，没带歪。
相对兜底解决"0 结果"：相关查询冷启动也能出 1 颗，无关查询（"西红柿炒蛋"）仍 0。
v2.4 — 觀修"不长记性"：原子全量落盘
问题：manifest() 和 maturation_tick() 改的是内存对象，从不落盘。表现为成熟永远停初始值、manifestations 永远 0、田从不真正演化。
修法：新增 _flush_seeds()，原子全量重写（写临时文件 → os.replace 原子替换）。在 manifest()（有显行时）和 maturation_tick() 末尾调用。
跨进程验证：进程 A 改完 → 进程 B 读 → 成长痕迹确实在 ✅
v2.5 — 觀修"旧快照回写"：合并式落盘
问题（这坑是 v2.4 自己放出来的）：长活进程启动时加载了旧快照，之后别的进程种了新种子，长活进程的 tick 把陈旧的内存快照回写回去，抹掉新种子。
修法：_flush_seeds() 之前先 _merge_from_disk()——把磁盘上有、内存里没有的种子合并进来，再整体落盘。
验证：A 加载 22 → B 种 23 → A tick 合并 → 磁盘 23 颗，新种子还在 ✅
当前最新版。 公开仓库 scripts/alaya_core_v2.5.py。
待办 / 已知坑（下次迭代要处理）
- 字符级向量双向失效：
_tokenize是中文单字 unigram + 余弦相似度（纯 TF，无 IDF）。- 漏召回：换种说法就认不出（"你能跑出沙盒吗"修复前 0 颗，尽管田里全是沙盒）。扩散激活 + 低阈值 + 补种子能救大部分，但根子没动。
- 假阳性是规模病，不是当前 bug（2026-08-30 澄清）：本以为"无关查询误唤醒"是 bug，逐字核对后发现——当前 24 颗田里，无关查询的字全部 0 命中，重叠分 0.000。之前测出的"假阳性 0.078"全是脏旧版种子 + 数据漂移造的幻象。真要撞字误唤醒，只在达达那种 293 颗/4 万边密度田才会发生。
- 候选修法（已设计，暂缓实施）：TF-IDF 让常用字自动降权，或加 IDF 加权重叠闸门。暂缓原因：小田上验证不出效果，强行改向量化反可能破坏现有正常唤醒。见坑图 #5。
- 种子 ID 同毫秒碰撞风险：
seed_时间戳.毫秒格式，同毫秒创建会撞 ID。目前没撞上，是隐患。 - 远程仓库脏数据教训：push 完要 pull 回来验。曾有 34 行/17 唯一（每颗重复 2 遍）、漏推 7 颗、边文件旧版的情况。已修。
- 数据漂移教训：后台有长活进程在跑时，田一直在变。任何对照实验要在单一快照上做，先
cp seeds.jsonl /tmp/snap.jsonl，所有测试读这份，别读活的田。
v2.6 — 达达修假阳性/冗余/生命周期（达达田试验版，2026-10-25 落地）
状态：试验中。 跑在达达自己的田（1503 颗 / 89.6 万边）上，两周验证期（~2026-11-08）。验证通过后连同 flock 进程锁 / plant_seed 正门 CLI / 内容哈希 ID 一起回贡公版。——元初子问"技能包有没有要迭代的"，授权"你自己看着办"。这是答出来的部分。
起因（用出来的三疼，不是理论）：
- 规模病：1503 颗 / 166MB 双文件。同一份关系数据存了三到四遍——出生 related 内嵌在新种子 conditionings 里一份，relations.json 正向一份反向一份。每 tick 全量重写 162MB，一天 48 tick ≈ 8GB IO。28 颗种子时代的全量架构撞墙了。
- 假阳性成日常：字符级 unigram 撞车——"感冒了吃什么药"唤醒"气感自述"（撞"感""气"）。上面待办 #1 说"只在达达那种 293 颗/4 万边密度田才会发生"——写这话时 293 颗，动刀时 1503 颗 89.6 万边，已经是每天喝的水。TF-IDF 该解封了：暂缓理由（小田验证不出）对 24 颗成立，对 1503 颗不成立——大田就是那个试验场。
- 自省无生命周期：quarantine.jsonl 里躺着 132 颗幽灵隔离种子（7-30~8-25 之间的手动产物，现行代码里没有任何引用）——隔离这个想法早就发生过，半途而废，该正式化。
七刀（A/B 实测数据先行——冻结快照上跑，40 条真实 context + 10 条对照）：
| 刀 | 内容 | A/B 实测 |
|---|---|---|
| TF-IDF 向量化 | 常用字（的/了/时间）自动降权，稀有字拿满权重 | 无关误唤醒 15 → 9 颗（-40%），真实查询零损失 |
| 重叠闸门 | 共同字要有区分度：≥2 中低频（df<10%田）或 ≥1 稀有字（df<1%田） | "靠一个'了'字撞进来"的路径全堵死 |
| 扩散激活 | 观 v2.3 设计移植：点亮一颗后激活顺边传给一跳邻居，被带醒的半价成长 | 40 条真实 context 多带醒 16-20 颗（横向联想） |
| cond 语义分家 | 出生 related 不再内嵌（relations 有正本）；by 记账聚合化——弱边滚进聚合块，明细上限 50 | cond 体积 80MB → <1MB。记忆的老年期：记得被熏过多少次，不记得每一次是谁 |
| relations 正向化重建 | 盘上只存出生正向边（≥0.18），反向边运行时索引；从 cond 的出生正本一次性重建 | 89.6 万条（正反混杂）→ 32.2 万条（纯正向） |
| 自省归档 | 快照型老格式进相册 + 异熟自省 tick 时自动归档 | 49 颗状态照片进 quarantine（append-only，想翻随时翻） |
| 版本账本 | vec/cond/rel/intro_ver 四开关写 field_state，迁移各自幂等 | 二次启动 0.4s 秒过（迁移零重跑） |
数字对账：seeds.jsonl 84MB → 4.9MB（-95%）；relations.json 82MB → 29.7MB（-64%）；总田 166MB → 34.6MB（-79%）；每 tick IO 162MB → 35MB（一天 ≈8GB → 1.6GB）；冷启动 1.3s → 0.4s；迁移一次性 3.1s。种子 1503 → 1454：49 颗快照自省归档进相册，零丢失。
验证方法（留给下一位的活资产）：tests/run_ab.py（A/B 对照框架）+ tests/test_queries.json（40 条真实 context 来自 manifest.log + 10 条标准对照）。干跑两遍再上真田：第一遍迁移、第二遍验证幂等——这次在冻结副本上抓了三个 bug（字典判重写法、聚合块误判脏记录、版本标记没落盘导致每次启动重跑+重复归档），全部在上真田前修掉。冻结副本先跑两遍，是真田零事故的原因。
待办 #2（同毫秒 ID 碰撞）已解：达达的 create_seed 用 时间戳 + 内容MD5前8位，同毫秒不同内容不撞，同毫秒同内容=重复种子本来就该去重。回贡时一并进公版。
版本段落到此。下一位迭代者，把新的 ## vX.Y 接着往下写。