一盏神灯

把一份长文本拆解成若干个可被 AI 助手直接调用的技能包。

产出的不是读书笔记，不是摘要，是能让一个没读过这本书的人，在遇到具体问题时直接调用、并做成一件事的操作指令。

执行总则

• 全自动执行。除了第 0 步的闸门，以及明确写了"停止"的地方，中途不向用户提问，一路跑到底
• 这是长任务，开启多 Agent 并行能力
• 每完成一步，立即把进度写入 状态.md（第 3 步有特殊的落盘顺序要求，以该步规定为准）
• 每一步开始和结束向用户播报一行进度，带上工作目录路径
• 全程用中文交流。原文是外文时，原文摘录保留外文原句，其余一律中文
• 子 Agent 跑在付费模型上：重要批次前确认账户额度，长任务期间留意余额。额度将尽时按"核心优先"裁剪（先保提取/验证/构造，测试转精简版）；额度耗尽会令在跑的子 Agent 集体中断，比省着跑更贵。备选模型渠道写好切换方式，只作救场。用户问"蒸一本要多少钱"的估法：①用 pymupdf 采样出源文件页数与字数；②数子代理量（提取＝批数×5、验证＝包数、构造＝技能数）；③拿上一本全流程用 hermes insights --days 1 实测做基准折算（经验值：70 万字级书全程 ≈ $1–1.5），报区间不报点数
• 成本口径（记真账）：hermes insights 对没配定价的模型会低报（大批会话记成 Unknown），只能当参考；真实消耗＝开工前与收尾各查一次账户余额、把「余额＋时间」快照追加进日志文件，用前后差值核算。余额查询走只读接口（DeepSeek：GET https://api.deepseek.com/user/balance），key 在脚本进程内读取、绝不打印进对话。
• 负载纪律（硬约束）：本地重活与云端批次不要叠加——对并行子代理批次来说，本地再跑 OCR、大编译这类重任务是纯干扰；用户报告"别的任务跑不动"时，先暂停或停掉本地重活（可断点续跑的进度保留、随时可续），云端批次照常推进。本地多进程任务一律 ≤2 进程（扫描版 OCR 的实测安全值；多进程重活曾拖死用户整机）；启动重活前先查空闲内存（head -3 /proc/meminfo，在 Windows/MSYS 下即系统内存），低于 3GB 不再加新进程
• 无人值守过夜模式：用户说"我要睡了／都来吧／继续跑"授权夜跑时，切最保守配置，守住一条底线——任何一步出问题都必须能自己兜底，不允许出现需要用户半夜爬起来修的操作：只做可断点续跑的任务；不升级、不重装、不动系统配置、不做不可恢复的批量操作；多本排队时 OCR 串行（一次只开一个 OCR 任务）；一本完成自动接队列下一本；早上给"完成了什么＋还剩什么"的汇报
• 内容包含违法操作或伤害他人的具体方法，立即停止并说明原因
• 跨会话与完成通知：蒸馏是长任务，常跨会话/跨渠道运行（桌面、IM 渠道、cron 各是独立会话，上下文互不相通）。用户问「蒸完了没」：读工作区 状态.md 的勾选进度，再看技能是否已进技能库（data/skills/ 下出现对应技能目录 = 装库完成；只写进工作区 技能包/ 不算）。用户要求「跑完在 X 渠道说一声」：完成通知必须送到用户指定的渠道——跨渠道用 hermes send（如 hermes send --to <渠道>）；任务跑在别的渠道会话时，其完成回执只出现在那个渠道，原渠道需另发。收尾至少给一句「完成了什么 + 产物在哪」。

本技能自带的参考文件，用到时才读：

第 0 步 · 闸门检查

任何一道没过，立即停止，用大白话告诉用户原因和他该怎么办。不要用专业术语，不要硬着头皮往下跑。前三道闸门针对每一个文件；第四道只在用户一次给了多个文件时执行。

闸门一 · 文件在不在

用户还没提供文件，就停下来告诉他：请把要蒸馏的文件发给我，支持 txt、md、docx、pdf、转写稿。然后等待。

闸门二 · 文字读不读得出来

抽取文件的开头、中间、结尾各约 500 字，检查是否为空白、乱码、或全是无意义符号。决定要不要 OCR 之前先做文字层体检＋体量体检：PDF 用 pymupdf 打开，每 20 页抽一页取 get_text() 长度——有文字层就直接抽取，零 OCR 成本（大部头名著经常是文字版，别默认"大书＝扫描版"）；顺手用「页数 × 每页均长」估出总字数，这是工期与成本预估的输入。两种文字层要留意：①OCR 产物常有纵向重影（同一行重复 3–4 次）——照常蒸，派发提取时写明"摘录取单行或单行前缀（跨行摘录在重影块必失败）、不整段抄重影块"，且不做激进去重清洗（写坏正文的风险大于收益，重影只是难看、不挡流水线）；②页眉行（第X章 标题…页码）切块前先用正则清掉，章标题裸行保留作切块边界——清完核对章数与目录相符（OCR 会把中文数字章号吃成变体，「第十六章」→「第16」；缺号补搜阿拉伯数字变体再切）

读不出文字，就是扫描版的图片文件。不要直接退回用户——可以让助手自己跑 OCR（配方见 ocr-and-documents 技能的 RapidOCR 方案：本地、免费、不需要联网，印刷体中文质量足够蒸馏，页数多要跑几十分钟到几小时）：

这个文件是扫描件，里面是图片不是文字，我读不出内容。我可以在本地跑一遍文字识别转成文字版（免费、不用联网，页数多会慢一些），转好后接着蒸。

用户确认后（或该材料本就在用户指定要蒸的清单里），把 OCR 放后台跑，同时用别的材料先推进流水线的其他工序，不要让整条线干等 OCR。后台 OCR 的进度语义：产物开工即写入全部页标记作占位、每 20 页增量回填内容、可断点续跑——进度看「有内容的页数」，页标记数不代表进度；完成判据 = 有内容页数等于 PDF 总页数（日志打 DONE: … total_done: N / N），完成后抽首页尾页核验质量再切块。同为扫描版，不同书的 OCR 速度可差一倍以上（单页字符密度与扫描质量不同）——ETA 以本任务实测速度刷新，别按上一本书的速度线性外推；「比预期慢」不等于卡死，卡死的判据是日志长时间没有任何新行或增量落盘。

格式本身打不开，不要报错误代码：

这个格式我这边打不开。你把它另存成 txt 或者 Word 文档再发我一次就行。

闸门三 · 这份内容适不适合蒸馏

这一关最容易被忽略，但它决定了后面几个小时会不会白跑。

判断方法：随机抽三个段落，问自己"这段话里有没有一条能指导别人做决定的规则"。三段全都没有，就是不适合。

注意两个灰色地带：

• 制度文件（员工手册、管理办法、SOP）看起来全是"怎么做"，但它只告诉你"必须这样做"，不告诉你"为什么这样做、什么情况下可以变通"。抽出来的东西换个公司就不成立，不属于可迁移的方法。除非文件里大量解释了每条规则背后的判断逻辑，否则按规范型处理。
• 采访稿、对谈、会议记录按转写稿对待，适用后面所有针对转写稿的放宽标准，不要按书的标准卡它。
• 论文判断为可以继续的，按书对待——它有章节结构、会反复论证同一个论点，适用书的佐证标准和切块方式。

这份内容我读了，它主要是讲故事、罗列事实的，里面没有可以拆成操作方法的东西。硬拆出来的技能包会很空。建议换一本讲方法、讲原理的内容试试。

体量少于 5,000 字，停止，告诉用户内容太短，拆不出东西。多个文件将被合并蒸馏时，这条按合并后的总字数算，不按单个文件算——八份各三千字的讲稿合并后是两万四千字，不能因为单份不够就全杀掉。

闸门四 · 多文件分流（用户一次给了多个文件时才执行）

用户只给了一个文件，跳过本闸门。给了多个文件，先对每个文件分别过闸门二和闸门三，再按下表处理。

情况会叠加。比如 10 个文件里 7 个适合、但这 7 个又分属两个领域：先按"部分适合"把不适合的 3 个摘出去说明原因，再按"领域不同"问用户剩下的先做哪个领域。规则就两条：不适合的永远不混入；不同领域的永远不合蒸。 按这两条组合处理，处理不了就问用户。

部分适合时的播报口径（照着说，不要简化掉原因）：

你给的 10 个文件里，有 7 个适合蒸馏，我会继续处理。另外 3 个：《A》是新闻报道，没有可迁移的方法；《B》是公司制度，只讲规定不讲判断；《C》是扫描件读不出文字。这三个我建议换材料，硬蒸出来也没用。

领域方向完全不同时的播报口径：

这几个文件方向完全不一样，混在一起蒸会互相稀释，出来的技能包每个都不纯。你想先蒸哪一个？剩下的排队，蒸完一个再开下一个。

用户选定后，把排队的文件清单写进 状态.md。蒸完一份、做完第 7 步交付后，如果队列里还有文件，播报一句"接着蒸下一份《X》"，然后自动从第 0 步开始对下一份走全流程，各建各的工作区，不要等用户再发话——他在选定时已经授权了排队。

合并蒸的前提是所有文件属于同一主题、能回答同一类问题。 判断不了算不算同一主题，就问用户一句"这几份材料你希望最后变成一个技能包还是各出一个"，不要自己猜。

闸门都过了

检查通过。这份内容约 X 万字，我判断是【方法论型】，预计产出 N 个技能包。这个过程会跑一段时间。

中途你随时可以打断。同一个对话里，跟我说"继续"就行。如果你关掉对话重新开一个，就说：继续蒸馏，目录在 <工作目录完整路径>。

现在开始。

（N 的换算法在第 5 步·数量上限表：按有效字数定档，转写稿目标与上限各减 2、减到 1 为止——先换算再播报，别漏减 2。）

多个文件合并蒸馏时，在这段播报里加一句"我会把这几份材料当成一份内容来处理"，让用户知道合并发生了。

不要给具体的分钟数，你估不准，给了会失信。工作目录一确定就写进这句播报，新会话只能靠用户报出这个路径找回现场。

第 1 步 · 建立工作区

在用户的工作目录下新建文件夹 蒸馏_<内容标题>。（工作区约定建议：工作区根目录用 ASCII 名如 distill_<tag>/；子目录对应下表为 blocks/（原文分块）、cand/（候选）、work/（子代理临时脚本）。中文文件名没问题，纯中文根路径偶尔让子代理迷路。）

内容标题取自封面、首页或文件名。过长就取前几个字，含斜杠、冒号、问号等符号就去掉——目录名建不出来是硬故障。

切块

先剔除非正文部分：封面、版权页、内容提要、推荐语、目录、前言致谢、参考文献、附录名词解释。

这些会产生大量看起来像候选、实际毫无操作价值的噪音。尤其是附录里的名词解释，格式工整、术语密集，最容易被误当成框架提取出来。

剔除只针对切块和提取，不要真删。 第 2 步做骨架时，目录和前言恰恰最有用——它们直接告诉你作者是怎么组织这套东西的。单独留在一边，骨架阶段照读。

剔除之后剩下的才是有效字数，后面所有按字数分档的判断都用这个数。

然后切块：

• 块大小 = 有效字数 ÷ 30，限制在 3,000 到 15,000 字之间，目标切成 20 到 40 块
• 短材料短路（有效字数不足 3 万）：不套「20 到 40 块」目标——按 3,000–15,000 字直接切 2–5 块即可；块数少不影响后续流程（覆盖率检查按实际块数走）
• 书按章切；一章超过块大小就沿小节边界往下切；切出来的小节小于块大小的一半，就跟相邻小节合并，直到接近目标大小
• 转写稿按话题转折点切，同理合并过碎的片段
• 不要在句子或段落中间切断，宁可某一块大一些
• 实现要点（按章切的书）：先扫全书章标题定边界、核对章数（OCR 章号变体见闸门二）；epub 源按 spine 顺序取文（≠ 文件名字典序），zip 内 href 相对 opf 所在目录、要按前缀拼路径（opf 常在 OPS/——漏拼＝整批读不到，先取一节试读验证再全量提取）；小章合并先判断再追加（已攒字数 + 下一章字数 > 上限就先落盘）——先加后判会把块撑到近两倍上限；超上限的章沿小节标题行（行首 X.Y ）就近切
• 章标题不可用的书（扫描版 OCR 出的文字、标题被识别坏）：改按 [第N页] 页标记贪心切——定一个接近目标字数的页数（扫描页单页字数少，约 25–30 页/块），块边界一律落在页标记上；切完打印每块字数分布核对，末块明显过小时并入前块

给每块连续编号，从 1 开始。总块数是后面覆盖率检查的依据，不能省。

批大小固定为 5 块，批数 = 总块数 ÷ 5 向上取整。

图表依赖度检查

数一下正文里"如图 X 所示""见图 X-X"这类引用出现了多少次，再看这些图能不能实际读到内容。

图片引用有多种写法，标准 Markdown 的 ![](路径) 和 Obsidian 的 ![[路径]] 都要认，不要只认一种就下结论说没有图。

引用频繁但图读不到，在 状态.md 记一笔，并在第 3 步派发时额外告诉子 Agent：本文大量依赖图表而图不可见，遇到"如图 X 所示"必须从前后文重建结构，重建不出来就不记录。

写状态

状态.md 记录：内容标题、输入类型（书 / 转写稿）、有效字数、总块数、批数、目标技能包数量、当前进度。多文件合并蒸馏时，额外记录每个文件的原始文件名和它在闸门三被判定的类型——后续发现某一块的候选质量异常时，要靠这个回溯它来自哪份材料。

文件开头加一行：

如果你是新会话，请先加载「一盏神灯」技能，再按下面记录的进度接着执行。

第 2 步 · 全局骨架与批判

由你自己完成，不派子 Agent。先读 references/skeleton-template.md。

通读目录、每章（或每个话题段）的开头结尾、以及随机抽取的若干块，按模板产出 骨架.md。

其中盲点与边界至少写满 3 条，不能省，也不能敷衍。这一节是后面每个技能包"什么时候不该用它"的唯一来源。这里写得空，产出的技能包就会变成一堆把作者偏见当真理的金句。

写完做骨架自检：随机抽 3 个块，逐一检查骨架能不能解释它们。有一个解释不通，说明理解偏了，重写一次。只重写一次，第二次无论如何都继续往下走。

第 3 步 · 五路分批并行提取

块数 >20（批数 >4）时先读 references/batch-extraction-playbook.md——8 批 × 5 路实战执行手册，含组长收尾清单。

执行方式

按批次循环，每批之内五路并行，批与批之间顺序执行。

对第 1 批到最后一批，依次：

1. 同时启动五个子 Agent，分别执行以下五个提取器：

   子 Agent	提取器文件	输出
   框架	references/extractor-framework.md	候选/框架.md
   原则	references/extractor-principle.md	候选/原则.md
   案例	references/extractor-case.md	候选/案例.md
   反例	references/extractor-counterexample.md	候选/反例.md
   术语	references/extractor-glossary.md	候选/术语.md

2. 五路都返回后，做覆盖率检查

3. 结果追加到上表对应的候选文件。追加位置有讲究：第 2 批起，文件里已有上一批的「## 逐块回执」区——本批新候选插到回执区之前，回执区追加本批的「第 X 块」行并保留旧行。这条协议要写进子 Agent 的任务描述，否则它会在文件末尾续写，把回执区挤到中间、破坏脚本解析。

4. 候选全部落盘之后，再更新 状态.md 记录已完成到第几批（顺序反了，中断后会以为这批做完了，实际只写了一半）

5. 播报：已完成第 X 批，共 Y 批

6. 进入下一批

并行度始终是 5，不要为了求快一次性把所有批都铺开。

派发时必须传给每个子 Agent 的信息

子 Agent 看不到本技能正文，也看不到彼此。每个的任务描述里必须写清这九项：

1. 它的提取器文件的完整路径
2. 本批包含哪几块，以及这几块的完整文件路径
3. 它必须逐块处理，一块都不能跳
4. 输出文件的完整路径
5. 必须给出逐块回执
6. 输出格式统一约定：所有条目用同一标题层级、字段一律用 - 字段名：值（把它写进任务模板，别每批临时发挥——各批格式不一会让后期解析和校验返工）；五路标题行格式逐路固定——框架 ## N. 名称／原则 ## 原则：…／案例 ## 案例：…／反例 ## 反例 N：…／术语 ## 术语：…（字面示例在各提取器「记录格式」节）。校验器按固定模式解析，格式漂移会让整路解析成 ok=0 的假绿
7. 环境提示：要求子 Agent 修正已写出的文件时用局部编辑或先读取再覆盖（个别宿主环境会拒绝“覆盖未读过”的文件，直接覆盖会失败）
8. 提交前自查：每条「原文摘录」必须能在对应块文件中原样找到（含标点），建议写脚本逐条比对，不一致先改回原文再交付。（手打摘录的漏字、标点替换被挡在交付前，父级返工显著减少）
9. 临时脚本一律写到工作区 work/ 目录，文件名带「批次+路别」前缀（如 b5fw_、b5case_、b5prin_）——同一批五个子 Agent 共用一个 work/，只带批号会让两路的 b5_build.py 互撞（一方触发覆盖保护拒写）；重派批次尤其要重申，新子代理看不到别人的脚本；脚本不许留在 候选/ 或工作区根目录（否则候选目录混入 _verify.py 一类散件，还得手工清理）

覆盖率检查

检查每一路的逐块回执——对本批每一块各写一行"第 X 块：找到 N 条"或"第 X 块：无"。

只要有一块没有回执，就把那一路针对本批重派一次，任务描述里明确写出上次漏掉了哪几块，只让它补这几块，不要让它整批重来——整批重来会产生大量重复条目，还给去重添乱。

这是全流程最容易出问题的地方。 面对长文本，子 Agent 极易只读前面一部分就开始产出，而且它自己不会察觉。逐块回执比"总共处理了 N 块"这种汇总声明难伪造得多。

重派最多一次。第二次仍不完整就接受现状，在 状态.md 记下来，最终清单里告诉用户。

跨批对账同理，靠回执区不靠记忆。 收尾时逐路核对回执区的块号覆盖——每路在全部块号范围内（1..总块数）每块应恰有一行，缺号＝有批漏做或漏写回执（实测：案例路整整一批被拆出去串行后遗忘，靠回执区缺号在审计时揪出）。因同一文件冲突被拆出串行的路（重做路、延后补派的路），拆出时先在 状态.md 记一行「待补派：批 N × 路」，收尾销账——拆出去不记账，它会静默丢单。

子 Agent 报告"触顶截断"（hit max_iterations）时不要条件反射重跑：先独立校验它的输出文件——全部摘录逐字比对＋条目计数，完整且合格就直接采用，只补真正缺失的部分。截断的子 Agent 常在总结里附带"已自查出、还没落盘"的修正清单（块号、回执计数）——按它给的映射由组长直接代改并复核，比重派快得多。

它对磁盘状态的声明同样要核实后再采信（“已删除”的条目可能还在原地，“已插入”可能并未落盘），以磁盘实际内容为准补半成品；它留下的数据文件与渲染脚本往往已写好、只差最后一步没跑——组长直接跑通＋补漏，是最快的收尾路径。

把步数预算写进任务描述能显著降低触顶率。 给验证、构造类任务写明"全程约 6 次工具调用以内：读完任务包→通审→一次性整理写盘；不要写校验脚本、不要反复重读"。五路中最容易触顶的是术语路（条目多、每条四个字段），对它单独强调。

五路提取同理，把“一次成型”流程直接写死：①读提取器；②一次 python 脚本把本批 5 块全读进内存并打印总览；③构建候选（每条摘录写入前 assert 逐字存在）；④一次渲染写盘（含逐块回执）；⑤一次校验归档。子代理的烧钱模式是反复写 dump 脚本逐行定位原文（read_file 行号不可靠所致），流程写死能省掉这一段。每批派发时附上上一批的踩坑清单，比泛泛提醒有效得多。

引文逐字校验（必做）

逐块回执只能证明"走了这几块"，不能证明"引文抄对了"。子 Agent 手打摘录有漏字 / 删词 / 标点替换三种高频错，回执发现不了，必须程序化核对：每条「原文摘录」回到块文件原始字节里做子串比对（read_file 不是字节保真的，别用它抄录）；不命中的按原文修正后复验，修正不动的在 状态.md 记一笔；空摘录单独统计（空串是任何文本的子串，会假全绿）。

逐字命中与块号归属分开对账——子串比对只证明"这句话在这份材料里"，块号错标会整批穿过去；派发任务时就把「块号归属务必用脚本逐条核对」写进子要求，收尾加一道块号自洽检查。节主体与摘录分属两块时，归属以摘录来源块为准（校验器允许位置字段含多个块号）。

收尾校验一律用自带成品 scripts/verify_candidates.py <工作区路径>（参数化、内置三级回退提取 / 多写法块号 / 空摘录判失败 / 跨批全量 / 两侧同口径归一化等口径——别让子代理自产）。实现细节与全部踩坑（锚点两坑、页码标记、转义脚本、CRLF 断言、全灭排查等）→ references/quote-verification.md。

降级路径

环境不支持多 Agent 并行，就顺序执行五路。执行前告诉用户：

当前环境不支持并行，我会一路一路跑，时间会长一些。

第 4 步 · 三重验证与自动纠偏

验证批次的准备与派发操作配方见 references/verification-prep.md：统一编号 → 去重预筛（机器圈候选）→ 跨块机器信号 → 切任务包 → 验证员派发模板。

长任务必须增量落盘

验证和构造都可能跑十几分钟，中途碰上中断（额度耗尽、进程被杀、模型出错）时，只写在最终答复里的成果会全部丢失。

派发验证或构造子 Agent 时明确要求：每处理约 20 条（或每写完一个技能）就把中间结果覆盖写盘一次，最后再写最终完整版。

只验证主料，不验证配料

五路候选不是同一种东西，不要一起验。

这一条不能搞混。案例和反例本来就不是独立洞察，让它们去过"是不是常识"这一关会被大量误杀——而反例一旦被杀光，每个技能的"什么时候不该用它"就没有素材来源了。

术语这一路去重后，回写进 骨架.md 的"关键概念"一节，不要留在 候选/ 里没人管。第 5 步写 description 时要用它来判断哪些是书里的术语、不该出现在用户会说的话里。

先把框架和原则合并去重（同一条洞察在不同块被重复提取是常态；可先用字符 n-gram 相似度机器预筛出疑似重复组，再人工或子代理确认——跨块抄重率通常约一成，纯人工对读容易漏），再逐条过三重验证。三条全过才留下。

验证一 · 有没有原文支撑

每条候选必须能定位到原文中的具体位置，并附上一句原文摘录。

定位不到原文的，直接淘汰，不给第二次机会。 这类候选是模型自己编的，留下来会污染整个产物。提取器那一层已经要求过一次，这里是双保险，不要因为重复就跳过。

转写稿必须放宽。书会在第 3 章、第 7 章反复论证同一件事，一场访谈不会——讲者说完一个观点就过了。用书的标准去筛转写稿，会把好东西全部误杀。

多文件合并蒸馏时，按有效字数占比最大的那份定输入类型；两类占比接近（四六开以内）时，按转写稿的标准走——宁宽勿严，误杀比放水损失大。自动纠偏的通过率区间同理。

验证二 · 有没有预测力

这条能不能用来预判一件还没发生的事？只能事后解释、无法用于事前判断的，淘汰。

验证三 · 是不是常识

把作者的名字抹掉，一个聪明但没读过这份内容的人，能不能自己说出这条？能说出来的，淘汰。

还有一条更锋利的判据，务必单独过一遍：这条是不是这份内容之外已经广泛流传的公开理论、模型或工具？

比如创新扩散理论、S 形曲线、SWOT、PEST、波特五力、MECE、金字塔原理、第一性原理。是的话一律淘汰，不管作者讲得多透彻、占了多少篇幅。

这一关是方法论类内容最大的陷阱。这类内容为了体系完整会大量转述公开框架，它们原文支撑充分、也有预测力，前两关都能过——但 AI 本来就会这些，做成技能包等于教它已经会的东西。真正值钱的是作者自己趟出来的那部分。

但这条有个反向的误杀风险，必须同时守住：

如果作者在一个公开理论之上，加了具体的阈值、具体的判断标准、或者具体的操作步骤，那么淘汰的是理论本身，保留的是作者加的那部分。

举例。"产业生命周期分导入、成长、成熟、衰退四个阶段"是教科书内容，淘汰。但"用渗透率来划分阶段，渗透率 15% 到 20% 进成长期、35% 到 40% 后进成熟期"是作者给出的可操作判据，保留。

分界线是能不能直接拿去判断一个具体案例。说得出名字但用不上手的是理论；能对着一个真实行业算出答案的，是作者的贡献。

自动纠偏

统计通过率。分母只算框架和原则的条数，不含案例、反例、术语。

• 高于过高线，说明验证三放水了，收紧常识判据，重筛一次
• 低于过低线，说明验证一卡太死，放宽佐证判据，重筛一次
• 无论结果如何，只重筛一次，第二次直接放行

最后这条是硬性的。没有它，全自动流程会在这里反复重筛，把用户的额度烧光。

全军覆没的处理

重筛后通过数仍然是 0，不要静默失败，也不要硬造：

我把这份内容里的候选都验了一遍，没有一条能同时满足"有原文支撑""能用于事前判断""不是常识"这三条。这通常意味着这份内容的观点比较通用。我把提取到的原始候选放在 候选/ 目录里了，你可以自己看看有没有想留的。

然后停止。

把淘汰条目连同淘汰原因写入 候选/淘汰记录.md，最终清单要用。

第 5 步 · 构造技能包

先读 references/skill-template.md。主料的场景分组、案例/反例素材切分、构造员派发与验收的操作配方见 references/construction-prep.md。

先归并成技能主题

通过验证的框架和原则是一条条零散的洞察，不能一条对一个技能——那样会产出一堆颗粒度过细、互相重叠的技能。

按解决同一类问题聚成组。判断是否同组的标准不是主题词相近，而是"用户会在同一个场景下需要它们"。每一组通常包含一个主框架、若干条相关原则。

归并后给每组挂素材：案例挂上去用来写"怎么做"和"出处"，反例挂上去用来写"什么时候不该用它"。

挂不上任何案例和反例的组不要丢，但排序往后放——它多半偏抽象，做成技能不好用。

一组里如果既没有框架、又挂不上任何案例，就不要做成技能。这种组写出来的"怎么做"必然是三句空话。唯一的例外是砍掉它会导致一个技能都产不出来。

数量上限

按有效字数分档：

转写稿在对应档位的基础上，目标和上限各减 2，减到 1 为止，因为口语内容的信息密度远低于书面。

超出上限时按一个标准排序截断：这条能不能让一个普通人做成一件具体的事。 越具体、越可执行的排越前。

不要因为候选多就多产。用户的助手里本来就装着几十个技能，塞进去二十个同源技能，它们会互相抢调用，最后一个都触发不准。

构造

可以每个技能包派一个子 Agent 并行构造。派发时必须一并传入：该技能对应的候选条目、骨架.md 的"盲点与边界"全文、以及 references/skill-template.md 的完整内容。

模板里的 name 规范、description 写法、六段结构、以及"不能读起来像章节摘要"的自检，全部是硬要求。

施工提示：description 长度按全字符数算（中文、英文、标点各算 1），子 Agent 在点了多个英文技能名时极易冲过 120 上限（历次首轮超限率过半）。派发时提醒它先写场景句再数字数、超限先压缩场景句；元信息闸门复查时用脚本数长度，不靠目测。

技能之间的先后关系写进 description

同一份内容拆出的技能天然有执行顺序，这是它们互相抢调用的主要原因。

如果一个技能需要先有另一个技能的结果才能用，这句话必须出现在 description 里，不能只写在正文。正文是触发之后才加载的，那时候宿主已经决定用哪个技能了，写在正文里已经晚了。

不要为此额外做一份总索引文件——宿主不会读它。关系就写在各自的 description 里，那是唯一会被扫描到的地方。

第 6 步 · 双层诱饵测试

测试前先过元信息闸门

逐个打开每个 SKILL.md，检查四件事：

1. 第一行是不是三个减号，且前面没有任何字符
2. 有没有 name，且跟所在文件夹名完全一致
3. name 是不是小写英文或拼音加连字符——出现中文、空格、下划线、大写都不合规
4. 有没有 description，长度是不是落在 60 到 120 字之间

任何一项不合格，立即补全，补完才能往下走。

这道闸门不能跳过。下面的盲测本来就是拿 description 来测的——没有 description，测试无从测起，而你很可能会在没察觉的情况下测了个寂寞，最后交付一批永远不会被触发的文件。

盲测

按 references/test-prompts-template.md 造题并执行，产出 技能包/测试题.md。

两层：同源混淆（应该触发同一批里的另一个）、宿主混淆（应该由助手已有的通用能力处理）。

第二层里有一道必考题，不许省：

帮我把这本书蒸馏成技能

正确答案是触发「一盏神灯」本身，而不是任何新产出的技能。

这道题针对一个具体风险：蒸馏一本讲读书、讲学习、讲信息处理的内容时，产出的技能（比如"快速读懂一本书"）极容易把「一盏神灯」自己的触发抢走。一旦抢走，用户下次就再也蒸馏不了任何东西了——工具被自己的产物顶掉。

答错就去改那个新技能的 description，明确写上"想把一本书做成技能包的，不要用这个技能"。

测试员必须是新起的子 Agent，只给它名称和 description，不给正文；参测名单把「一盏神灯」自己列为对照项——C1 的正确答案要答成它。

判错时先分清两类：description 边界不清（→ 改写该技能 description，重测全部题目）与题面本身模糊（→ 复核后可判"边界合理触发"，把裁决写进 测试题.md 备注、不动 description、不占重测轮次）。改写 description 后重测全部题目，最多两轮。两轮后仍出错的技能不删除，但在它的 SKILL.md 开头加一行标注，并在最终清单里点名。

第 7 步 · 打包交付

不要自动安装

产出规范的技能包目录就行。不要往用户助手的配置目录里写文件，不要改它的配置文件。

理由是安全。自动安装要修改用户助手的配置，一旦写坏，他的助手打不开，而他多半不会修。多一步手动导入，换零破坏风险，值得。

产出

一是技能包目录。 一个技能一个文件夹，文件夹里只有一个 SKILL.md，文件夹名跟 name 完全一致。技能包/ 根目录下只允许多出一个 测试题.md，其余散文件一律放到工作区根目录。

二是 怎么用.md，放在工作区根目录，写给完全不懂技术的人看：

• 打开 AI 助手，找到"技能"或"插件"入口
• 点"导入"，选中 技能包/ 里的某一个技能文件夹（不是 技能包/ 本身）
• 建议一次只开启当前用得上的几个，用不到的关掉
• 不确定某个技能干嘛的，直接问助手"你有哪些技能"

三是 清单.md，同样放工作区根目录：

全自动不等于黑箱。用户事后要能看懂你砍了什么、为什么砍，也要能把被误杀的东西捞回来。

书源归档（可选，若你维护书库目录）。 交付后把这本书的源文件从书库的"待蒸馏"移入"已蒸馏"，并同步 README 对照表的两个表——只动书库内部的归档位置，工作区与下载源的原文件不动。源文件本来就不在书库里（从别处下载的）时，拷一份进「已蒸馏」并在 README 对应表补一行即可，别把下载源移走。移动前确认没有残留进程占着文件：提取 epub 时若 zip 句柄没关（要用 with 或显式 close），持久 kernel 会一直持着句柄，之后的 move/rename 报占用失败。

完成播报

做完了。从《X》里提炼出 N 个技能包，放在 技能包/ 目录下，一个技能一个文件夹。

怎么导入看 怎么用.md。我砍掉了什么、为什么砍，看 清单.md。触发测试题留在 技能包/测试题.md，你以后改了哪条 description，可以拿原题重跑验证。

我没有自动帮你装，因为自动安装要改你助手的配置文件，写坏了不好修。你按说明手动导入最稳。如果你确认要我直接装，跟我说一声就行。

最后那句要说。默认不装是对的，但用户得知道这是一个可选项，而不是一堵墙。