现在优化 skill 的工具都是一次挑一个：你选中某个 skill，给它写一批测试 prompt，跑评委打分，改完再跑一遍。有几十上百个 skill 的时候这条路走不通，瓶颈根本不是优化算法，是你没空逐个去挑、逐个编测试用例。
lamarck 换的是这个前提：装一次，之后所有已装的 skill 全部进入观察，不用挑、不用写用例、不用配置。它在后台看真实调用，攒够同一类证据才对某一个提出一处改动，改完立刻验，变差就退回去。
一次挑一个的做法，隐含假设是你知道哪个 skill 有问题。实际上你不知道，你只知道最近某个任务干得不顺，至于是哪条指令没写清楚、还是压根触发错了 skill，事后很难复盘。而那些一直安静工作的 skill 里有多少段落是从来没被用到过的死重，更没人去查。
全量观察把这两件事都变成了副产品。每个 skill 各自积着自己的账，谁反复出同一类问题，看账本就知道；谁的哪一段九十天零引用，也是账本里现成的数字，可以直接变成一条修剪提案。挑选这一步被取消了，不是因为有更聪明的挑法，是因为不需要挑。
前提是它必须常驻，而常驻的东西一旦贵，两天就会被卸掉。所以省这件事在这里不是优化项，是能不能成立的问题，后面好几处设计都是从这一条推出来的。
同类工具的信号来自专门造出来的考场，基准分数，或者人编的测试 prompt 加评委打分。lamarck 用的是生产遥测，你真实的调用和你真实的纠正。你打断一句「不是这个意思」，这句话就是 ground truth，比模型自评硬得多。
顺带解决了回归用例从哪来。被纠正和失败的调用会蒸馏成回归用例存下来，三个字段：任务要点、按 rubric 的达标要求、来源账本时间戳。分布是真实的，而且一条都不用手写。
PostToolUse 匹配 Skill，每次调用往待评队列追一行：时间、会话、技能名、参数前 200 字，外加一枚基因哈希，也就是那个 skill 的 SKILL.md 在调用当刻的内容摘要取前 8 位。后面按版本分窗比健康度全靠这枚戳。插件类技能名字里带冒号、路径解析不出来，戳留空，这类 skill 因此享受不到版本分窗。
这一行里不存执行痕迹，只存一个指向会话 transcript 的路径，完整日志本来就躺在那儿，没必要再抄一份。代价是 transcript 被清理之后指针会失效，消费端必须能退化处理。
Stop 钩子负责触发评估，它的做法是省字数的关键：不加载 SKILL.md，而是把一份精简的评估规程整段写进阻断理由的字符串，模型执行完就丢。每轮都重载一份长协议的话，成本压在每一次对话上，那就回到了「贵到会被卸掉」。只有证据攒够、要动真格提案的时候才去读完整协议，那是罕见路径。
两个钩子都吞掉所有异常、永远退出 0，不允许把主流程搞挂；但异常不会凭空消失，会往 data/hook-errors.log 留一行，那个文件安静就是健康。目录里放一个名为 off 的文件即全部静默，手动调用仍然可用。另有两处防自噬：技能名等于 lamarck 的调用直接跳过，免得评估器去评估自己；stop_hook_active 保证一轮最多阻断一次。只有本会话的条目会触发评估，别的会话没有上下文证据，留给手动跑。
每条待评条目判四样，每样限五行以内，只许引用真实可见的执行痕迹，看不见就归档，不许编。
trigger_fit：这次触发对不对，还是误触发、还是该用另一个 skillgaps[]：skill 的指令里缺了什么，每条写成「缺了 X，导致 Y」outcome：干净 / 被纠正 / 失败，用户的原话要引进来friction：白走的弯路，可以为空
这四项逐条落进账本，有可复用的教训另写进 learnings。衡量的尺子同样是长出来的：每个 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 在 config.json 里有自己的等级，新装的自动落进默认级：
observe（默认）：只记账、沉淀教训、长 rubric，不产生任何提案；证据照积，哪天升级历史证据立即可用suggest：过门的提案只写进suggestions/，永不直接编辑evolve：过门的提案走用户三选一，你说改才改auto：过门的提案直接施工，不再事前问你
auto 看着危险，实际做法是把回放从事后验证提成了放行条件：当场跑全场景回放，不过就立即自动回滚、提案进拒绝缓冲，落地的每一笔在下次输出里显式报告，照常进 CHANGELOG、账本和 git，git revert 一步可撤。还有一条补漏改得挺关键，如果这个 skill 的回放语料是空的，auto 自动降回三选一，没有放行条件就没有放行，零验证落地是禁止的。
禁区是硬的，lamarck 自身、Iron Rules 那一节、以及插件和 marketplace 来的文件，无论怎么配都不受 auto 覆盖，插件更是永远只能到 suggest。建议也写得直白，只把经历过多次 evolve 级成功编辑的 skill 升上来，自治是挣来的。
场景不变时 skill 会收敛，继续全量评估就是纯浪费，所以每个 skill 有两态。默认 active，每条待评条目走完整评估；连续十次干净之后转 stable，之后每条只做一眼扫描，本回合没有纠正和异常就记一行 stable-skip 并把连击加一，但每第五条仍然做全量评估，防止悄悄漂移。
唤醒回 active 有四个触发条件，任一即生效：用户纠正或失败、抽样评估发现缺口、基因哈希变了（被编辑或被外部改动，编辑后的验证期必须全量）、以及参数呈现出 rubric 场景标签覆盖不了的新场景，场景变了收敛的前提就不成立。
连击本身也算证据，报告会把它当成生产可靠性凭证呈现，某个 skill 最近多少次真实调用零纠正。stable 加上长期零引用的条目，正好是修剪提案的天然候选。
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 这件事本身走得更远。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。