晓辉博士《Skill 自迭代能力改造指南》
分级：【摘要即可】——指南八步与视频要点已在下面写到能独立成立；视频 9:27 按需看（五层与三组实践在摘要里都有）。
出处：晓辉博士（@xiaohuiyuan，新可能实验室发起人｜腾讯研究院高级顾问）2026-11-05 X thread：一条 9:27 视频 + 一条“Skill 自迭代能力改造指南”（复制给能访问、编辑 skill 文件的 agent 就能跑）。视频为自动字幕转录，个别专名以音频为准、不确定；16% 与 30% 两个数是作者视频口述，未给出处。 一句话：先验证，再迭代——把标准写清楚、可重复的操作做成工具、确定的要求变成检查、每次反馈留下来；否则自迭代只会批量生产垃圾。
- 核心主张（验证税）：Anthropic 内部说法是 16% 的工作已能交给 AI 做自动化 R&D（L4 不是 L5）；但验收还要人来做，约 30% 的时间花在验收上——这就是“验证税”。skill 达不到 100% 交付标准就放手让它自己迭代，产出的是更多垃圾与更多验收工作，解放不了注意力。先把验证系统写清楚，才是 agent 能自己 loop 的前提。
- 三组实践：① poteto 的 Verification Skill（软件工程：feature map——软件是干什么的、每个功能在哪找，把工程师脑子里的东西写出来；CLI——日志、评审、交付封装成 agent 能调用的工具）；② Addy Osmani 分享的 Claude Code 团队代码评审实践（纠错五层）；③ yetone 的 Agent Loop（让 agent 自己循环迭代）。
- 纠错五个层次：最强的两层是黄金样例与脚本检查——好样例让 agent 少犯错（代码乱就别交给 agent，越写越乱）；正式检查必须跑脚本（知识型任务也一样：完整性、字数、上下文是否查全）。其余三层（规则、skill、偏好）是弱的——给 agent 当参考可以，没法验证它有没有照做。任务就是把前两层做强。
- 指南八步：① 理解现有 skill（解决什么问题、适用场景、产出什么、现在怎么做、有什么问题）；② 明确验收标准（质量长什么样、硬约束、相对偏好、可自动化检查、3–5 个黄金样例做固定评估集、反馈来源；未确认不进改造）；③ 把可靠操作变成工具（重复性强、步骤确定、容易出错的环节脚本化；写清何时调用、“没调用就失败”、接口说明与退出码）；④ 结构化（目标与范围、前置检查、主流程、输出标准、验证与输出、常见问题与反馈收集；验证是核心步骤不是可选项）；⑤ 反馈机制（用户反馈、执行偏差记录、评估结果三种来源，沉淀到 skill 内的反馈日志，每次调用先读）；⑥ 反馈变迭代（最小改动单位、一次 1–2 处、留时间/原因/改动/效果的痕迹、3–5 例先测、测试组 vs 对照组、P0/P1/P2）；⑦ 测试流程（脚本检查为主、LLM 审查为辅，防假阴性；改前跑一遍评估集、改后跑一遍，同一标准比指标；出错先记录类型与触发条件，别急着回滚）；⑧ 验收机制（文件结构完整性、与用户逐项确认、验收方式写进 skill、交付前自我检查说明、验收报告模板、指标可统计可比较）。
- thread 回复补的一条：回归样例里留“看起来完成了”的失败——文件生成了但内容为空、检查通过了但查的是旧版本。改完 skill 后这些例子仍应判失败，免得迭代优化的是通过率，漏掉的错误反而更多。
跟你的咬合
- thinktank 最直接：评测集（股票 S1–S7、代码 P1–P3、量化 S4–S7）就是指南说的 evaluation set；incident-to-eval 就是反馈沉淀。昨晚 m3.1 那轮是反例：4000 上限饿死 9 题、重试白烧 token——迭代之前没验证，越迭越亏。按指南，“空回答顶上限”这类失败样例应留进回归集。
- muse-agent-harness 缺后半段：INVENTORY.md / PROGRESS.md 是 feature map 的雏形，tools/ 里的脚本检查已有一批；缺的是 skill 内的反馈日志与验收报告模板。
- open-memex 能对上两处：§20 编译版总纲就是知识库的 feature map；D79 反馈加权排序就是反馈机制；capture 校验可以按指南写成脚本检查。
- WorkBuddy 已在按这个做：M0 验收（stdout 全空才算通过）就是脚本检查；C3 注入扫描是现成的 P0 例子。
-
视频剪辑是小头：她自己的例子就是录音转写；你的字幕/音频剪辑规矩也可以写成脚本检查，优先级低。
- 三个关键问题：先拿哪个 skill 试点（thinktank 评测集 vs harness 某个 skill）/ 反馈日志放哪（skill 内 vs AGENTS.md）/ 验收报告模板先定哪几个可统计算指标。