从一个没填完的提示词开始
朋友发来一段提示词，想让我帮他快速建立某个研究领域的"系统性认知模型"——提炼最基础的核心名词、关键动词、底层逻辑。模板写得挺认真，唯独中间留着一行：
【填写你的研究领域，例如：量子计算 / 宏观经济学 / 编译器设计】
占位符没填。
换作习惯性"先给点什么"的 AI，大概会挑一个领域直接开写，洋洋洒洒铺出一张漂亮的表格。但领域错了，后面所有内容都是废的。所以第一件事不是写，而是问：你想了解哪个领域？答案后来落在软件测试。
这件小事定了整件事的基调：不猜、先澄清、对齐了再动手。它也是后来整个产物里反复出现的一条原则。
第一版骨架，和它藏起来的毛病
软件测试的骨架很快出来了：9 个核心名词（测试用例、预言机、断言、测试替身、覆盖率、缺陷、回归、测试金字塔、质量门禁），每个配上 1-3 个动词，一张表格，一句话讲清每个名词在这个领域里到底怎么运转。开头还立了 Dijkstra 那句定调的话——测试无法证明程序无缺陷，只能证明缺陷存在。
看起来挺完整。然后我说了一句话：“拷问一遍你自己，刚才的答案是最优吗？不是为了推翻，是为了更优。”
这一句是整件事真正的转折。
“拷问你自己”——后来成了这个 Skill 的灵魂
对抗式自我审查一遍，初版的毛病全浮出来了。最致命的两条：
一是层级混杂。 我把"测试在干什么"的本体概念（预言机、缺陷、测量），和"测试怎么干"的工具概念（测试用例、测试金字塔、CI）混在同一张表里。表看起来面面俱到，读者却分不清哪些是地基、哪些是工具。
二是本体论遗漏。 我漏掉了这个领域最根基的几个概念——验证与确认（V&V）、错误/缺陷/失效的三分（Error/Fault/Failure）、可测试性（Testability）。这三个比任何"测试工具"都更接近"测试为什么存在"，却最容易被一个"懂测试的人"漏掉，因为太习以为常反而隐形。我引了 Dijkstra 的结论，却没给出产生这个结论的机制——虎头蛇尾。
改进版重组成两层：先讲本体论（这个领域是什么、为什么），再讲方法论（怎么干），并显式标注每个方法论概念服务于哪个本体论概念。这一下，“系统性"才真正立住——平铺的词典不配叫骨架，两层咬合的齿轮才配。
关键发现是：这次"自我拷问"是整个产物里最有价值的部分。 提炼名词、配动词、列表格，都是常规操作；唯独"用一份固定清单对抗式审查自己的初版"是差异点。其他 Skill 很少这么做。
把这个过程固化成一个 Skill
既然这套四步流程有效，就把它封装成一个可复用的 Claude Code Skill，让以后任何新领域都能跑一遍。我用了 yao-meta-skill（一个专门创建 Skill 的元 Skill）提供的 Scaffold 规范，刻意保持精简：
- 澄清领域 —— 含占位符或不明，先问，绝不猜。
- 第一层骨架 —— 5-10 个核心名词 + 1-3 个机制动词（概念自身的运作，不是围绕它的人类动作）+ 一句话逻辑串联。
- 二级展开 —— 选认知杠杆最大的一个概念深挖。
- 自我拷问 —— 用固定清单扫五类缺陷（层级混杂 / 本体论遗漏 / 观点当事实 / 动词偏离机制 / 格式违约），再产出"先本体后方法 + 层间映射"的改进版。
它叫 xj-domain-skeleton，已经放在 GitHub 上。
用两个领域去验证它
Skill 写完不算完，得跑。软件测试是范例。然后我换了一个完全不同的领域——量子计算——用它跑了一遍。
量子计算的初版骨架照例把"干涉”（interference）这个概念，悄悄折叠进了"量子算法"那一格里，只当个动词藏着。而干涉恰恰是量子计算力量的真正来源——大众科普里"量子计算机靠并行宇宙同时算所有答案"是错的，真正的机制是概率幅的相长与相消干涉。
自我拷问拦下了这个错误：把干涉从"算法"里拎出来，提升为本体论的核心概念。否则读者会带着"量子=并行"的误解离开。
这时候一个跨领域的模式浮现了：领域的"力量之源"最容易被人折叠进一个方法论名词里。 软件测试里，oracle（判定对错的依据）被折叠进"断言"；量子计算里，干涉被折叠进"量子算法"。因为机制天然依附在工具上表现，人写骨架时容易把它当工具的属性带过，而不是单列为本体概念。
这个模式不是写 Skill 时想到的，是两次实测跑出来的。于是我把它作为"高频子模式"补进了 Skill 的方法论文档里，让以后任何领域跑这个流程时，都会专项排查这一项。Skill 因为实测而变得更准。
最有意思的地方：它是自指的
回过头看，这件事最让我觉得漂亮的，是一个结构上的巧合：
这个 Skill 教别人"先出初版、再对抗式拷问、再分层改进"。而它自己的诞生，走的是同一条路——软件测试初版 → 拷问 → 改进 → 抽象成 Skill → 再拷问迭代。方法论和元过程完全同构。
更深一层：它的核心价值不是预设的，是从一次真实的交互里涌现出来的。“自我拷问"这一步，是从那句"拷问一遍你自己"里蒸馏出来的。不是把一个现成的最佳实践装进 Skill，而是把一次真正有效的协作固化下来。这是"从问题推理”，而不是"套模板"。
你能带走的三条方法
即便你不用这个 Skill，这套方法本身是可迁移的。面对任何陌生领域：
- 先找"立场"。 每个领域根基处往往有一条反直觉的限定（测试无法证明无 bug；量子计算不是更快的经典计算机）。找到它，整个骨架才挂得住。
- 概念分两层。 本体论（这个领域是什么、为什么）和方法论（怎么干）要分开。混在同一层，就是一本没骨架的词典。
- 出完初版，用固定清单拷问自己。 尤其要问：这个领域的"力量之源"，是不是被你折叠进某个工具名词里了？如果是，把它拎出来，单独成条。
最后一个小提醒：自己审自己天然偏向为已有的结论辩护。所以别用"再想想能不能更好"这种空泛反思——那只会换来一句"挺好的"。要用一份固定的缺陷清单强制扫描，要么找到具体的毛病，要么明确说"这一项我查过没问题"。
空泛的自我表扬，一律禁止。
这个 Skill 的完整代码和两个领域的范例（软件测试、量子计算）都在 GitHub：hongxiaojun/xj-domain-skeleton，欢迎 fork 来跑你自己的领域。