skill 写完就定死了，哪条指令没写清楚、哪一段从来没人用到，只能靠自己隔一阵翻出来重读。
lamarck 换个办法：装上之后它在后台看着每一次真实调用，攒够同一类证据才提出一处改动，改完立刻验，变差就退回去。用进的留下，废退的剪掉。
所有不可逆的一步都要你点头，账本留在本地。

它解决什么

现有的做法基本是两类。一类拿基准分数当信号，跑离线评测；一类拿人编的测试 prompt 加评委打分，一次挑一个 skill 来优化。共同点是信号都来自专门造出来的考场。

lamarck 的信号是生产遥测：你真实的调用、你真实的纠正。你打断它说「不是这个意思」，这句话就是 ground truth，比任何模型自评都硬。范围也不同，装一次之后所有已装的 skill 都在观察下，不需要逐个挑、逐个写测试用例。

代价是它必须常驻，而常驻的东西一旦贵就没人留着。这是整个设计的第一约束。

lamarck 的一轮进化

两个钩子

只挂两个。

PostToolUse 匹配 Skill，每次调用往待评队列追一行：时间、会话、技能名、参数前 200 字，还有一枚基因哈希，也就是那个 skill 的 SKILL.md 在调用当刻的内容摘要取前 8 位。这枚戳是后面版本分窗统计的全部依据。插件类技能名字里带冒号、路径解析不出来，戳留空。

这一行里不存执行痕迹，只存一个指向会话 transcript 的路径。完整执行日志本来就在那儿躺着，没必要再抄一份；代价是 transcript 被清理之后指针会失效，所以消费端必须能退化处理。

Stop 钩子负责触发评估。它的做法是整个设计里最省的一处：不加载 SKILL.md，而是把一份精简的判词规程整段写进阻断理由的字符串里，交给模型执行完就丢。每轮都重载一份长协议，代价压在每一次对话上，那种东西装两天就会被卸掉。只有证据攒够、要动真格提案时，才去读完整的 SKILL.md。

两个钩子都吞掉所有异常、永远退出 0，不允许把主流程搞挂。但异常不会凭空消失，会往 data/hook-errors.log 留一行，那个文件安静就是健康。目录里放一个名为 off 的文件即全部静默，手动调用仍然可用。

还有两处防自噬：技能名等于 lamarck 的调用直接跳过，免得评估器评估自己评估自己；stop_hook_active 保证一轮最多阻断一次。只有本会话的条目会触发评估，别的会话没有上下文证据，留给手动跑。

四维判词

每条待评条目判四样，每样限五行以内，只许引用真实可见的执行痕迹，看不见就归档，不许编。

trigger_fit：这次触发对不对，还是误触发、还是该用另一个 skill
gaps[]：skill 的指令里缺了什么，每条写成「缺了 X，导致 Y」
outcome：干净 / 被纠正 / 失败，用户的原话要引进来
friction：白走的弯路，可以为空

判词逐行落进账本。有可复用的教训另写进 learnings，被纠正和失败的还要蒸馏成一条回归用例，存成 {essence, expect, src}。这批用例的来源是真实调用痕迹，分布是真的，一条都不用手写。

尺子也是长出来的。每个 skill 有自己的 rubric，用户纠正一次即可入册，但每条必须带账本出处，没出处禁止写入；淘汰的进 attic 不删。rubric 跟协议同库 git 版本化，可以 diff 可以回滚，而遥测本身被 gitignore 挡在外面，只留本地。

证据门

提案不是想提就能提。八个条件同时成立才行，下面挑几条展开。

证据至少两次。同一类缺口要在两次独立调用里都出现。单次观察永远不触发编辑，n=1 是噪声。但提案生成时要综合这个 skill 的全部在案证据，不只是撞线的那两条。

场景围栏这条管的是跨场景污染。证据全部来自同一个场景标签时，只允许做场景分支式增量，新增一段「当某场景时……」，不得改写共享核心。要动共享核心，得拿出至少两个不同场景的证据。这条是防止你为 B 场景做的优化把 A 场景依赖的部分改坏，切回去就退化。

回放也不许只测触发场景。任何编辑的回放验证必须带上其他场景的既有用例，不只是触发场景的。回放语料就是全部历史场景的记忆，「切回旧场景会不会崩」在施工前就演过一遍。

反震荡拦的是覆写式打摆子。如果一个提案实质上推翻了最近十次里已经被接受的编辑，判定为震荡，禁止直接覆写，强制转成场景分支提案，并且把两个场景的证据摆在一起交给用户决定。没有这条，两种场景交替出现时协议会在两版之间反复横跳。

净增长预算管的是只涨不减。提案要报净行数变化。让 SKILL.md 超过 500 行，或者连续两次净增超过 10%，就必须同时附一个删减案。删除类提案是一等公民：九十天零引用的 rubric 条目、被证据标记为「误导或从未用到」的段落，主动产出修剪提案。用进废退的废退那一半在这里。

剩下三条是：提案必须具体到能写成定点的增删改并写明验证方式；被否过的同类提案进拒绝缓冲，除非有新类型证据否则不许重提；上一次编辑的验证还没跑完时该 skill 冻结，不接新提案。

门过了才轮到用户三选一：现在就改 / 只留提案 / 否决。否决连原因写进拒绝缓冲。非交互会话一律只留提案。施工是有界的，一次最多改三处、单处最多十行，禁止整文件重写。

验证与回滚

改完不是就完了，三道验证依次上。

回放最快：从回归用例里取这个 skill 的历史场景，派新的 subagent 分别按旧版和新版跑，按 rubric 成对比。新版更差直接回滚，不用等下一次真实调用。

盲评是自然验证：被编辑 skill 的下一次真实调用，派一个独立 subagent，同时给它旧版全文、新版全文、这次调用的真实痕迹和 rubric，在同一上下文里比出 better / worse / tie。用成对比较而不是绝对打分，是因为绝对分跨会话有校准噪声，成对比可以抵消。平时单评委省成本，只有出现平局或者跟回放结论打架时才加派两个凑成三票多数。

版本分窗是统计兜底：按基因哈希把这个 skill 的健康度分窗算，编辑后的窗口样本够三条之后跟编辑前比，变差就判负优化。

回滚的语义按证据强度分级。回放和盲评是同输入直接对照，属于强证据，自动回滚；版本分窗是观察性统计，可能混着任务漂移，只出回滚提案，仍然走用户三选一。而且回滚被定义成恢复用户已经批准过的上一个基线，不算新编辑，所以不受三选一和有界编辑的约束，但必须落账并且明确告诉用户。

三种验证各记一行 verify 记录进账本，还要记这次动用了几个评委，成本本身也要核算。没落账的效果等于没有效果。

成熟度

不是每次评估都有收益。场景不变时 skill 会收敛，继续全量评估就是纯浪费。

所以每个 skill 有两态。默认 active，每条待评条目全量四维评估。连续十次评估干净之后转 stable，之后每条只做一眼扫描，本回合没有纠正和异常就记一行 stable-skip 并把连击加一。但每第五条仍然做全量评估，防止悄悄漂移。

唤醒回 active 的条件有四个，任一即触发：用户纠正或失败；抽样评估发现缺口；基因哈希变了，也就是被编辑或者被外部改动过，编辑之后的验证期必须全量；参数呈现出 rubric 场景标签覆盖不了的新场景，场景变了收敛的前提就不成立了。

收敛本身也是证据。报告会把 stable 状态和清白连击数当成一种生产可靠性凭证呈现：这个 skill 最近 N 次真实调用零纠正。stable 加上长期零引用的条目，就是废退修剪的天然候选。

谁能被改

白名单分三级，写在本地的 config.json 里，不入库。

evolve：过门的提案可以走用户三选一直接施工
suggest：过门的提案只写进 suggestions/，永不直接编辑
observe（默认）：只记账、沉淀教训、长 rubric，不产生任何提案

新装的 skill 自动落进默认级，也就是只看不动。证据照样积累，哪天升到 evolve，历史证据立即可用。配置文件缺失时一律按 observe 处理并提示你去建。插件、marketplace 和 synced 来的 skill 无论怎么配都不会被直接编辑，上限就是 suggest。

十条 Iron Rules 兜底，改这一节本身都要用户明确批准。里面包括永不删除账本历史、永不删除已有观察和 rubric attic、每次编辑必须可回滚并写进 CHANGELOG。

怎么用

npx lamarck-skill

一条命令：拷贝 skill、初始化本地配置、把两个钩子写进 ~/.claude/settings.json（先备份、只增不改、可重复执行），最后跑一遍自检让安装自证。装完重启 Claude Code 或者打开一次 /hooks 让钩子加载。

卸载是 npx lamarck-skill uninstall，只解钩子，文件和遥测都留着。

日常几乎不用管。想调节奏就 /lamarck mode every、manual 或者 threshold N；想处理别的会话攒下的积压、或者看某个 skill 的完整证据、或者要那份进化战报，就手动跑一次 /lamarck。

头一周基本看不到动静，这是设计如此。钩子静静记账，默认攒满五条才触发一次评估，然后要同一个缺口出现两次才会有第一个提案。一周没有提案通常说明你的 skill 是健康的，不是它没在干活，翻 data/ledger.jsonl 就能看见。

证据与限制

诚实政策是不做自评分：优化器拿自己的评委给自己的产出打分，什么也证明不了。所以证据分层摆出来，机制自检 48 项全过、跑在隔离沙盒里不碰真实遥测；变异基准是预注册协议之后再跑的，第一轮五个已知劣化变体抓出四个、两个已知改进变体零误拒，那个漏掉的被写进分析而不是藏起来；自我应用那条最实在，它自己的每次改动都是证据触发、有界、用户批准并验证过的，CHANGELOG 就是可审计的流水，包括在这套纪律下抓出并修掉的四个自身缺陷。

限制也得说清楚。

冷启动是真的，前期什么都不会发生，要攒够真实调用才有信号。
观察性统计混着任务漂移，所以版本分窗只敢出提案不敢自动回滚。
判词由模型给出，虽然只许引用真实痕迹、看不见就归档，但仍然不是零误判，证据门和用户在环是为此设的两道闸。
插件类 skill 拿不到基因哈希，版本分窗对它们不生效。
遥测的执行痕迹存的是指针，transcript 被清理之后就查不到原始上下文了。
生产案例还在积累中，要等真实用例攒够、连同任务漂移的观察性注意事项一起发，不先发结论。

路线图里说下一步不限于 skill：subagent 定义、CLAUDE.md 这类记忆文件、slash command、MCP 工具配置，凡是能反复在生产里被使用的、用来引导 agent 的文本产物，都可以套同一套遥测到账本到 rubric 到有门编辑的架构。真正被验证的其实是这套治理骨架，skill 只是第一个宿主。