本月需要一位博弈论专家和一位形式逻辑专家来构建两个AI技能。作者没有这两个领域的深度知识，而是找到了一个出乎意料但效果极好的方案：两份PDF + NotebookLM。

提取：加载、查询与脚手架

前四步是纯机械操作。将源材料加载到NotebookLM（Schelling的《冲突的策略》用于构建焦点技能，Weston的《论证规则》用于论证技能），创建一个可查询的专业知识版本。然后穷举式查询：比如论证技能，意味着从9个部分中提取全部45条规则、19个命名谬误及其识别模式、6种演绎形式，以及需要示例的规则的工作示例。

用NotebookLM CLI将查询能力接入编码环境。作者使用了pi（pi.dev），一个精简的编程Agent，采用不同的架构思路：极简核心、无MCP、无技能市场，让Agent根据需求自行构建工具。

在NotebookLM CLI和编码环境之间反复迭代：构建技能的一个章节 → 向NotebookLM提问验证是否与源材料一致 → 优化 → 重复。随后用skill-creator工具搭技能脚手架：frontmatter、模式定义、输出模板和初始规则。

Note：设置NotebookLM以学习指南模式回应，并将响应长度设为更长。

设计评估

这是最难的部分，也是作者两次做错、第三次才对的部分。

第一次尝试：用NotebookLM作为0-100评分员。运行测试用例后把输出传给NotebookLM让它评分。产出的数字没有校准意义，50分和90分可能都是噪声。

第二次尝试：切换到二元pass/fail判定，仍用NotebookLM。35个顺序NLM调用，每次26秒，总运行时间900秒。每次都超时。

真正有效的方案简单得尴尬：大多数二元标准可以用模式匹配检查。如果标准是是否识别了ad hominem谬误，就检查输出是否包含ad hominem。命名谬误、规则编号、结构标记（如CLAIM、PREMISES、VERDICT）在文本中都是可观察的。

最终评估架构：约85%的标准使用确定性正则表达式模式匹配（快速、免费、可重复），约15%使用Claude-as-judge处理模式无法可靠检测的格式敏感型结构检查。完整套件运行时间8-10分钟，无NotebookLM依赖。

运行评估

二元评估暴露了论证技能的三个真实缺口。

DEBATE模式是最大的问题。技能说steelmann双方，但Claude会把一方构建得很扎实，另一方则草草收尾或产生一个平衡的摘要。修复方案是对DEBATE模式进行完全重写，采用明确的四步流程：完整BUILD立场A、完整BUILD立场B（同等深度）、对双方进行AUDIT（检查谬误和过度声明）、最后给出结构化的判决，并保持适当的谦逊。输出模板展示确切章节起了决定性作用。

背景率（Rule 9）表述过于抽象。原技能说问：多少次中有一次？，这对Claude来说太模糊，无法可靠应用。添加了四个具体的命名模式：生动打击陷阱、占星陷阱、百慕大三角错误和翻倍欺骗。

BUILD模式缺少引用。Claude产生了结构良好的论证，但将所有前提视为不言自明的。向输出模板添加SOURCES NEEDED字段，标记哪些前提需要实证支持，修复了这个问题。

三次修复后，技能在原始36个标准上达到100%，于是作者添加了三个更难的测试用例：归谬法构造、定义处理和多步演绎链。技能也通过了这些测试——这才开始信任这个技能可以用于真实工作。

自动化这个循环的工具是pi-autoresearch，这是pi的一个扩展，运行自主实验循环：尝试更改、用评估套件基准测试、保留改进、回滚回归、重复。它在会话文件中跟踪已尝试的内容，以便Agent在上下文重置后甚至跨fresh会话（无先前记忆）都能恢复。

验证源材料

评估告诉你技能产生的输出是否包含正确的结构元素。它们无法告诉你技能是否以作者会认可的方式忠实应用了源材料。

为此，作者回到NotebookLM。用技能处理一些新输入，然后问NotebookLM将输出与原书比较。NotebookLM能回答这些问题，因为它有完整文本。

如果你读过上一期关于三个海湾的内容，这里就是它们的映射位置：评估处理泛化海湾（它在不同输入上是否一致有效？），NotebookLM处理规范海湾（它是否按照源材料的要求衡量重要内容？），你自己的阅读处理理解海湾。那个第一条仍需自己完成。

手动时间投入约65分钟：30分钟阅读输出并建立失败直觉，15分钟审查错误类别，20分钟标注输出以验证评判者。之后优化循环自动运行。

Pipeline汇总

  1. 将源材料加载到NotebookLM（书、PDF、课程、任何文档）
  2. 穷举式查询NotebookLM以提取可操作知识
  3. 用NotebookLM CLI接入编码环境
  4. 用skill-creator工具搭建技能脚手架
  5. 设计评估：二元标准、大多数模式匹配、部分LLM-as-judge
  6. 运行评估，修复暴露的缺口，重复直到通过
  7. 通过NotebookLM验证源材料（针对评估无法捕捉的部分）

前两条技能是从书籍开始的。但Pipeline适用于任何源材料：课程PDF、一组内部文档、一系列研究论文、一个团队使用但没有人将其记录为系统提示的方法论。NotebookLM是领域专家。评估是质量控制。你自己对输出的阅读是让这两者发挥作用的那一部分。

提取决定天花板

在构建190+技能中学到的东西，适用于你自己构建技能：

提取步骤决定天花板。如果你提取摘要，你得到一个产生摘要的技能。如果你提取可操作细节（具体规则、命名模式、决策标准、工作示例），你得到一个可以将框架应用于新情况的技能。论证技能有效，是因为它有所有19个命名谬误及其识别模式，而不是因为它知道谬误存在。

大多数评估标准可以用模式匹配检查，这出乎意料。命名概念、结构标记、必需输出章节在文本中都是可观察的。模式匹配比LLM评判更快、更便宜、更可重复。现在约85%的标准用模式匹配，约15%用LLM评判——远低于第一次尝试时的100%。

手动阅读步骤是人们最想跳过的，也是最重要的。每一个跳过阅读输出就设计评估的技能，都评分很好但在真实工作中表现很差。每一个先阅读输出再针对观察到的失败设计评估的技能，都是可以信任的。在35+个技能中追踪这一点，相关性是1:1。仍然会想跳过它。

构建公司特有技能

Pipeline也适用于内部知识。如果团队有一个方法论、一个 playbook 或一个框架存在于Confluence页面或Google Doc中，你可以将其转化为技能。

将文档加载到NotebookLM，查询它以提取可操作结构：步骤是什么，决策标准是什么，常见失败模式是什么。然后搭技能，针对上下文中重要的标准编写评估，运行改进循环。最后验证步骤不同于基于书籍的Pipeline：不是用NotebookLM检查，而是用团队中最了解该方法论的人来检查。