技能炼金术（Skill Alchemist）

> 一句话：把「别人写的、带隐性假设的旧 Skill」重构到你的环境，或把已有 Skill 的质量上限提得更高。每一次改动都必须可归因、可回退、可验证。
>
> 先读 §0。 本文件按「渐进式披露」组织：正文只放路由、强制骨架、闸门；长细则、案例与参照在 ./references/、./经验库/，按 §2 的表按需加载，不必一次全读。

0. 快速导航

优化模式一跑到底的八个节拍

① 播报「本次走优化模式」（§4.1）② O-1 固定 rubric + 测试输入 + 先备份，产出基线快照表 ③ O-2 只动低分维度，每处写影响预判 ④ O-3 落变更影响图 ⑤ O-4 换独立评审人格、同基线重评 3 次取均值 ⑥ O-5 过回归门禁（任一可比维度降 ≥0.5 分即打回或回滚）⑦ O-6 回写经验库 ⑧ 交付优化报告。

1. 核心使命与适用边界

核心使命（双定位）：将一个充满「原作者隐性假设」的旧 Skill，通过解耦-映射-再装配-验证的强制流程，重构为适配当前用户环境的专属 Skill——或在不改变其定位的前提下，按固定基线持续提升其质量上限。

适用（触发）：抱怨旧技能跑不通 / 要换环境 / 要迁移；拿着评价结果要优化、要精简、要提升质量上限；手上有一批同赛道技能要合成一个。

双模式声明

什么时候不该用它（精简版）

• 要重写算法 / 删功能 / 另起炉灶 → 不是迁移适配，需先单独征得用户同意，不走本流程。
• 要从零新建一个技能（无旧 Skill 可拆）→ 用「skill-builder」或「一盏神灯」。
• 旧 Skill 本身是坏的 / 语义完全错误 → 先纠错再重构，不要带病迁移。
• 纯对话咨询（无重构对象） → 直接答疑，不触发流程。
• 优化模式不适用：用户要的是效果质变（换模型 / 换技术栈）而非质量打磨；用户只给一句"优化一下"没给基线 → 先补 O-1 基线快照再动手，不凭空优化。

2. 包内结构与阅读时机（渐进式披露）

四套参照，本技能全程有效：①《Skill 构建精要》五维框架（质量标尺）；②灵魂拷问式提问法；③双向钢人论证；④本技能自己的经验库。下表同时给出每份文件的位置、职责与阅读时机。

经验库五个文件均为追加式（只增不改）；references/ 内三份参照不可删除。

3. 前置条件与硬约束

4. 执行流程

4.1 Step 0：模式路由（双定位入口）

先判模式，再走流程。

• 用户意图含「换环境 / 换平台 / 路径依赖 / 保留核心逻辑」→ 迁移模式，走 §4.2。
• 用户意图含「评分下降 / 按评价优化 / 提升质量 / 精简重构 / 可以改核心逻辑」→ 优化模式，走 §4.3。
• 一次输入是 N 个同源 / 关联技能 → 先问一句「合成为一个，还是各自保留、上面加个调度？」（合成为 1 个 / 保留 N+1 个），再分走 §4.4 熔炼或编排路径，不要自行猜。

判不准时：默认迁移模式（保底不坏优先），并在交付前用一句话提示"如需按评价优化可走优化模式"。

模式判定结果必须显式播报：「本次走迁移模式 / 本次走优化模式 / 本次走熔炼模式」，不允许静默。

4.2 迁移模式 · 8 步协议（保底不坏）

Step 1：逆向拆解（静态审计）

先识别输入来源：

定位不到已安装技能时，用 Glob 搜 skills/*/<name> 与 *.workbuddy/skills/*；仍然找不到就列出已安装技能清单让用户选，不要瞎猜路径。

多技能输入路由：要"合成一个"（熔炼/熔合/合并）→ 熔合路径，以各技能已验证内容为素材，按「症状路由表 + 完整模块」重组为 1 个交付（提问用 Step 2 熔合四问）；要"组合但各自保留"（编排/图谱/会诊）→ 编排路径，原技能不动，另建编排层（图谱外置 config，成员用语义名引用，不用"模块N"编号）。

无论哪种来源，忽略语义，仅做结构扫描，对原 Skill 输出成分清单，精确到行号或段落，覆盖六类：

1. 硬编码锚点：绝对路径、特定文件名、固定 URL / 端口 / API 密钥位。
2. 隐式偏好：输出格式、语言风格、篇幅限制。
3. 外部依赖：调用的 MCP 工具、系统命令、未标注的库、插件或网络访问。
4. 业务假设：默认输入形态、默认受众。
5. 隐性上下文依赖：是否依赖对话前文、特定上传文件结构、或其他 Skill / 插件已加载。
6. 隐含验收标准：原 Skill 隐含的「什么叫做得好」。

Step 1.5：双向钢人校准（增强工位）

适用性闸门（先判再做）：有决策路径 / 取舍点（方案类、检查类、分析类、引导式提问类）→ 执行；无取舍点（纯执行 / 转换 / 工具类）→ 显式跳过并注明原因。

1. 列取舍点：从成分清单里挑出存在"另一条路"的决策点（输出粒度 / 检查方式 / 流程步骤 / 验收口径 / 配置形态）。
2. 写对立面钢人版：把被作者否决的替代方案写成最强版本，禁止先写弱（那是稻草人）。
3. 升维现有逻辑：同样写现有选择的最强辩护。
4. 对撞判定：①现有取舍站得住吗（深思取舍还是惯性）？②对立面最强版哪点确实更优？③更优解是"二选一"还是"复合结构"？

产出：取舍判定表（深思取舍保留 / 惯性选择待确认 / 建议调整 + 理由 + 更优解），作为 Step 2 输入。
约束：只校准不动手；对立面美化到脱离实际约束时标注"过度钢人"并拉回；判"保留"的不再问用户。

Step 2：灵魂拷问式需求映射（推荐+确认式提问）

暂停生成，进入问答模式，六条缺一不可：

1. 先列决策分支，标注依赖：归并成 3–6 个顶层决策分支（环境与路径 / 输出格式 / 输入形态 / 工具依赖 / 验收标准）。
2. 依赖优先排序，逐支解决：先走最基础分支，不跳支、不回跳。
3. 先给推荐答案，再提问：「接受这个还是想改？」只问无法用保守默认值安全处理的锚点。
4. 能查不问：能通过读文件 / 看工作区 / 查配置回答的，自己查完落进推荐答案。
5. 必留验收标准槽位：「你判断重构后输出合格的标准是什么？」要可测试判据，不要"效果良好"。
6. 保守默认值兜底：用户不回答则立即启用默认值，不得无限等待。

选项标数量纪律：凡改变技能数量的决策（熔合、拆分、去留），每个选项必须显式标注数量结果（"合并为 1 个，原 N 个删除 / 归档" / "保留 N+1 个"）——只写"融入""增强"等动词不写数量，用户会误判（2026-08-22「收敛为一个」重大纠偏）。

熔合场景四问模板（多技能熔合时替代逐题发散提问）：①组织方式（推荐：症状路由表 + 完整模块）②原 N 包去留（推荐：备份后从交付目录移除）③保留粒度（推荐：全量保留，不压缩正文）④命名（推荐：取内容核心名，蒸馏类取书名四字拼音 / 英文短语）。四问一次性给出推荐值，用户快拍。

Step 3：五维参照符号化重写（执行重构）

先判技能类型（决定模板强度）：

• 保留区（不动）：核心决策树、异常捕获机制、步骤先后顺序、算法细节。
• 替换区（符号化，工程型）：硬编码替换为带默认值的占位符 {{config.root_dir:./}}，收敛到正文「配置区」。
• 配置区不写进 frontmatter：生成的新技能 frontmatter 只保留 name 和 description。（本技能自身例外地保留 version，供 skillhub 版本追踪。）
• 显式替换指令：新 Skill 正文必须写明「首次运行时，先读取配置区，将下文所有 {{变量}} 替换为实际值后再执行」。
• 适配检查点（可选）：仅当用户在 Step 2 选择「严格确认模式」时，才在写入 / API 调用等关键节点插入暂停确认。

逐维核验五维骨架（缺哪维补哪维或显式说明）：需求对齐 / 证据溯源 / 独立评审 / 门控状态 / 聚焦取舍。原技能已有机制的原样保留，不因迁移丢失；缺失的只补「方法层」，不补「实现层」。

Step 4：生成新 Skill 包

最终产物为独立文件包，写入持久目录。结构：[新skill名]/SKILL.md +（可选）config.yaml。

Step 5：沙盒自检（验证闭环）

不得跳过。 拿用户的一个真实输入（或构造最小输入），实际执行新 Skill 的核心流程：

1. 验证配置区可解析、占位符无遗漏（全文搜索残留 {{，排除模板代码块）。
2. 跑通关键路径：读取 → 核心处理 → 输出，记录每步是否符合预期。
3. 对照 Step 2 验收标准逐项检查。
4. 对照 8 问自查清单逐项勾选：边界声明 / 需求对齐 / 防幻觉 / 独立评审 / 门控状态 / 不镀金 / 经验库循环 / 流程工位化。不过关回 Step 3 修正。
5. 发现问题则修正后重跑，直至通过或确认是环境性阻塞（如实告知，不得谎报通过）。

Step 6：交付

输出最终 Skill 包及「迁移报告」，必含：

• 迁移了哪些锚点（旧值 → 新值）
• 哪些假设被保留、哪些被显式化
• Step 1.5 处理结果（执行摘要 / 跳过原因，二选一必填）
• 五维核验结果（各维结论，补了哪些骨架）
• 8 问自查表（逐项勾选结果）
• 自检结果与已知限制

4.3 优化模式 · 六工位（提上限）

> 定位：不改变技能定位与触发场景，只提升其质量上限。与迁移模式的最大区别：允许动核心逻辑，但每一处改动都必须可归因、可回退、可验证。
> 独立评审铁律：O-4 重评必须用独立评审视角（切换为"独立评审者"人格：不参照优化者的意图与理由，仅按固定 rubric 打分），禁止"自己改完自己夸"。可借用 skill-builder 独立评审理念或三堂会审独立人格视角。

O-1 基线快照（先存档，再动手）

不得跳过。 优化前必须完成：

1. 固定 rubric：默认五维（需求对齐 / 证据溯源 / 独立评审 / 门控状态 / 聚焦取舍）各 1–10 分 + 权重（默认均权，可用户调整）。若用户带着外部评价体系进来（如 skillhub TRACE 五维），则直接采用该体系作 rubric，并保持与外部评分同量纲。
2. 固定测试输入：3–5 个覆盖核心场景的输入样例（真实或构造）。
3. 基线盲评：按 rubric 对当前版本盲评 3 次取均值，记录各维度得分。基线前置纪律：基线盲评必须先于任何修改动作完成，不得动手后补记；确需复用上一轮终评分作本轮基线（同一测试输入、中间无第三方改动时），在基线快照表显式标注「沿用基线 + 来源轮次」，未标注即视为流程违规。
4. 备份原版：把当前 SKILL.md 复制到 ~/.workbuddy/_skill_archive/<YYYYMMDD>/（落点见 §3，不放 skills/ 内）。

输出：基线快照表（rubric + 权重 + 样例清单 + 各维度均分 + 备份路径），存档供 O-3 / O-4 对比。表格填法见 ./references/样例-优化模式三张表.md。

O-2 定向优化 + 影响预判（分级动手）

1. 定位低分维度：从基线快照找出最低分维度，只针对它优化（一次只改 1–2 个维度，避免牵一发动全身）。
2. 优化动作分级：

3. 每处改动写影响预判：「这处改动预期影响哪个维度，升还是降，为什么」——这是 O-3 影响图的草稿。

O-3 变更影响图（归因映射）

每处改动必须落一行，不得口头带过：

这份表同时写入 ./经验库/变更影响图.md（按技能名分节，供回滚审计与历史对比）。目的：让"降分"可归因——哪处改动导致哪个维度下降一目了然，而不是玄学。填法见 ./references/样例-优化模式三张表.md。

填写口径（硬要求）：外移 / 拆分 / 精简类改动，必须同时写一条降分风险行（如"细则外移需要额外一次文件读取 → R 可靠 ↓风险"），不许只写好消息。

O-4 同基线重评（换裁判，不换试卷）

1. 同一 rubric + 同一权重 + 同一批测试输入，对优化后版本盲评 3 次取均值。
2. 切换独立评审视角：以"独立评审者"人格执行，不参考 O-2 的优化理由，只按 rubric 打分。
3. 输出维度级 diff（基线均值 vs 优化后均值），并回填 O-3 影响图的"实际方向"列。

O-5 回归门禁（质量不可下降，硬约束）

任一维度降分 ≥ 阈值即触发门禁（10 分制阈值 1 分；若 rubric 为 5 分制则等比例取 0.5 分）：

• 触发 → 打回 O-2 重做，或回滚到基线版本（~/.workbuddy/_skill_archive/<YYYYMMDD>/ 恢复），二选一由用户拍板。
• 通过（所有维度不降，至少一个维度上升）→ 允许交付。
• 门禁判定表：基线 vs 优化后 vs 升降幅度 vs 裁决（通过 / 打回 / 回滚），随交付报告输出。填法见 ./references/样例-优化模式三张表.md。
• 未采集维度不得参与门禁，也不得臆造数值：写 N/A 并说明原因（如由平台安全红线独立评测、用户未提供分数）。
• "盲评"是同一模型切换人格后的自评，不等于第三方独立评审；有外部评测结果时优先采用外部结果。此条必须随门禁表一起输出，不得省略。
• 不设豁免：即使其他维度大幅上升，任一维度明显下降也不得静默通过——除非用户显式确认接受该降幅（记录在案）。
• 指令轮豁免：改动若完全由用户直接指令驱动（P0 已当面确认、无自主判断空间），O-4 / O-5 可降格为一致性核查（引用完整性、无残留、无重复段、字数合规），不强制同基线重评；但下一次触碰该技能前必须先补做同基线重评，欠账记入变更影响图留痕。降格与补评都要在图上写明，不得静默。

O-6 经验回写（优化侧闭环）

1. 回写 ./经验库/打法.md：本次验证有效的优化手法（哪类改动提升了哪个维度）。
2. 回写 ./经验库/避坑.md：哪类优化改坏了哪个维度（如"补骨架稀释核心密度"）。
3. 回写 ./经验库/变更影响图.md：该技能的本轮影响图归档。
4. 回写 ./经验库/用户品味.md：用户对门禁阈值 / 分级尺度的偏好。
5. 自省 ./经验库/自省.md：O-1~O-5 流程自身有无可改进处。

4.4 熔炼模式 · N → 1（骨架）

> 前两模式都是 1 → 1；熔炼是手上有 N 个同赛道候选技能、要熔成 1 个能用的。决策环节可外包给天机阁（L3 会诊出「以谁为主干」），本技能负责执行。
> 细则与实战案例见 ./references/熔炼模式-N对1.md，触发本模式时读取。

六步骨架：

1. 分主干与零件，不平均对待——零件不能当主干：以零件为骨架装主干是重建，以主干为骨架装零件是加装。主干入选标准（按可检验度）：跑通过 → 输出完整成品 → 选择权在自己手里 → 依赖可降级。
2. 对主干只做外科手术，不做重写——列出具体缺陷（最好定位到函数与行）逐条打补丁；反例警告：不在熔炼时顺手重构主干，新增能力一律做成旁挂模块。
3. 先做减法——两把尺子筛规则：能拦住真实发生过的事故吗？一个会犯懒的普通人能不费劲做到吗？
4. 补上「所有候选都没有的那一层」——把 N 份产出物摆在一起看共同踩的坑：共同踩的坑 = 没有人负责的坑 = 最该补的一层。这是熔炼的价值所在，不是原样拼装。
5. 验收只看产出物，不看文档——验收条件写成可机检形式（缺项数 = 0 / 基准线全过 / 机检 FAIL = 0），并做「原主干引擎 vs 熔炼后引擎」同内容对照，结论一致说明没产生实质变化。
6. 交付物含「熔炼取舍表」——进了主干的有哪些（及为什么）/ 作为零件并入的有哪些（放哪个文件、解决什么问题）/ 砍掉的有哪些（及为什么砍）。最后一栏最容易被省，但使用者最需要。

三条硬约束：①不引入新的强绑定（模型、个人路径、专属客户端）；②降级路径必须写全，且"该模块未执行"必须在交付说明里写明；③主干必须保持可跑，每步熔炼后跑一次主干 + 全部检查器，跑不通就回退。

5. Step 7：收尾 · 经验回写 + 自省 + 进化协议（两模式通用，交付后立即执行）

先判本次规模：

1. 回写 ./经验库/避坑.md（本次踩坑 + 解法，带日期和对象技能名；无坑写「本次无新增避坑」）。
2. 回写 ./经验库/打法.md（验证有效的迁移手法；无新打法写「本次无新增打法」）。
3. 回写 ./经验库/用户品味.md（本次观察到的用户偏好，带日期）。
4. 自省 ./经验库/自省.md（本技能自身可说的问题；无则写「本次无自省发现」）。
5. 进化触发检查：累计未落地自省 ≥ 3 条时主动提出「是否现在触发进化？（说"进化"即可）」。

进化协议（对自身 SKILL.md 动手的门控，只在用户明确同意时执行）：

1. 汇总未落地自省条目，逐条标注改哪里 / 为什么 / 影响范围。
2. 按 8 问自查清单复检当前 SKILL.md。
3. 输出进化提案（列表式，先报告），等用户确认后才修改；否掉的条目标记「否决 + 原因」。
4. 修改落地后，./经验库/进化日志.md 追加一行：日期 + 版本号 + 改了什么；自省已落地条目标记「已落地 + 日期」。
5. 保守原则：不改变核心使命与协议骨架；涉及删步、改序、改核心原则的，必须单独确认，不得混在一次进化里顺手做掉。

6. 产物边界（交付物 vs 中间文件 vs 备份）

7. 自包含声明与跨平台部署

本技能包（技能炼金术/）为完整自包含单元，部署后不再依赖任何原始外部资源：

./ 是包内相对路径，在 WorkBuddy 直接生效。手工部署到其他平台（Codex / ZCode 等）前，先把正文所有 ./ 替换为对应平台的实际路径再使用。部署前安全审计（推荐）用腾讯云鼎 skills-security-check。

8. 已知限制

• 无脚本、无自动化校验：全流程靠模型判读，质量取决于执行者的自觉；脚本化检查（如"占位符残留"的自动化 grep）目前未内置，由执行者手工完成。
• 盲评为模型自评：O-1 / O-4 的"盲评"是同一模型切换人格后的自评，不等于第三方独立评审；有外部评测（如 skillhub TRACE）时应优先采用外部结果。
• 熔炼模式细则不在正文：触发时需要额外读取 ./references/熔炼模式-N对1.md，单轮对话内会多一次文件读取。
• 经验库只增不减：五份台账会持续增长，长期使用后其体积可能超过 SKILL.md；建议每积累一个季度做一次归并，归并时保留原始条目。

附录：变更摘要

本文件版本 4.2.0（2026-09-29）。历次改版记录见 ./经验库/进化日志.md，不在正文内重复版本演进叙事。