Thinking Skills 第二阶段：从领域路由到 Benchmark 驱动的自进化
上一篇文章
- 把 AI Skill 做成系统：路由、领域技能、自我复盘和进化飞轮
我写了 Thinking Skills 最初想解决的问题：
很多 AI Agent 工作流都很强，尤其是在编程场景里。但它们也很容易形成一个隐含默认值：当用户的问题不够明确时，系统会自动把它理解成软件开发任务。
比如用户说：
我有一个想法，帮我梳理一下。这句话可能是在写文章，可能是在做学习计划，可能是在处理情绪，也可能是在做一个生活决策。
如果 AI 一开始就进入 coding workflow，也就是以编程任务为默认工作流，它后面的所有判断都会自然偏向需求分析、任务拆分、实现计划、测试和提交。
但人的问题不只有代码。
所以 Thinking Skills 第一阶段做的事情，不只是写几个好用的 prompt，而是尝试建立一套更通用的思考技能框架：
先判断用户真正需要哪一种思考模式， 再进入对应领域的 skill。这就是thinking-router的位置。
它不负责回答问题，而是负责判断：这个请求更像写作、技术分析、学习理解、情绪支持，还是别的思考场景。
项目地址与安装方式
Thinking Skills 目前仍然是一个 Alpha 阶段的开源项目。
它不是一个已经定型的标准答案，而是一套可以安装到本地 agent 环境里、在真实对话中使用、复盘和继续改进的 thinking skill 框架。
项目地址：
https://github.com/huajiexiewenfeng/thinking-skills如果你的环境支持 Skills CLI，可以直接安装：
npx skillsaddhuajiexiewenfeng/thinking-skills安装之后，本地 agent 就可以发现这些 first-party skills，也就是项目内置的第一批核心技能：
thinking-router：领域路由，判断用户请求应该进入哪种思考模式。content-creator：内容创作，处理文章、标题、大纲、论点和写作结构。technical-deep-dive：技术深潜，处理代码、架构、调试、性能、接口和验证。learning-coach：学习教练，帮助理解概念、建立心智模型和发现知识盲区。emotional-support：情绪支持，处理焦虑、自责、关系困扰、burnout 和情绪梳理。conversation-review：对话复盘，也就是 Dolores 机制，用来回看 skill 使用轨迹和失败信号。skill-evaluator：技能评估器，用来分类失败原因并提出最小修改建议。benchmark-assistant：评测助手，用来运行、生成、评分和解释 benchmark 评测流程。
也就是说，Thinking Skills 的使用方式不是“复制一段 prompt”，而是把一组可路由、可复盘、可评测的 thinking skills 安装到本地环境里。
第一阶段不只是领域路由
如果只把第一阶段理解成“加了一个 router”，其实是不够的。
Thinking Skills 第一阶段真正建立的是三个平面。
第一个是Runtime Plane，也就是运行平面。
它负责当前这一次回答如何产生：
用户请求 -> thinking-router -> domain skill -> method bases -> response这里的domain skill指的是领域技能，比如写作、技术分析、学习、情绪支持等不同场景下的专门 skill。
method bases可以理解成方法底座，也就是每个 skill 背后依赖的判断框架、专业方法或实践经验。
比如：
content-creator的方法底座包括读者意识、论点结构、叙事和论证结构。technical-deep-dive的方法底座包括系统思维、问题拆解、权衡分析、根因分析和验证意识。learning-coach的方法底座包括心智模型构建、费曼技巧、提取练习和误解诊断。emotional-support的方法底座包括情绪命名、接纳、事实和想法分离、安全边界等。
第二个是Reflection Plane，也就是反思平面。
它负责在一次对话之后回头看：
这次是不是选错了 skill？
skill 选对了，但模式是不是错了？
回答是不是问太多问题？
是不是把本该藏在底层的方法论直接倒给了用户？
是不是太早给建议？
是不是漏掉了安全边界？
这里的核心机制，就是conversation-review / Dolores。
conversation-review是对话复盘 skill。
Dolores是 Thinking Skills 里对这个机制的主题化命名，可以理解成对话自我复盘机制。它不是每次回答后都必须执行的一步，而是在需要复盘时，用来观察一段对话里的 skill 使用轨迹、模式切换和失败信号。
第三个是Content Plane，也就是内容平面。
它负责沉淀那些可以被复用的东西：
skills/ docs/ evals/ cases/ benchmarks/ benchmark-runs/ feedback/换句话说，Thinking Skills 从一开始就不是单纯的 prompt collection，也就是提示词集合。
它更像是一个会把运行经验、失败复盘和技能文档连接起来的系统。
Dolores 已经让系统可以回头看自己
第一阶段里，Thinking Skills 已经有了半自动的自我进化飞轮：
Failure signal -> conversation-review / Dolores -> abstract failure case -> skill-evaluator -> eval -> minimal patch -> retest这里的Failure signal是失败信号。
它可能来自用户明确说“这个回答不对”，也可能来自一次对话里暴露出的模式问题，比如：
- router 选错了 skill
- emotional-support 问了太多问题
- content-creator 太快进入写全文
- technical-deep-dive 编造了没看过的代码事实
- 某个 skill 把专业框架暴露得太重
- 用户想聊天，但 assistant 还停留在评估模式
skill-evaluator是技能评估器。
它不负责直接修补所有内容，而是先判断失败类型：这是路由错误、模式错误、问题过载、术语暴露、输出过长，还是建议给得太早？
这一步很重要。
因为 Thinking Skills 的改进原则不是“感觉哪里不好就大改一通”，而是：
先把失败变成可复用 case， 再判断最小修改面。这里的case是失败案例，通常会被抽象化保存，而不是保存用户原始私密对话。
minimal patch是最小补丁，意思是只修改最有必要的规则、边界或 eval，不为了一个失败案例把整个 skill 重写得越来越重。
这也是第一阶段已经有的自我进化能力。
所以第二阶段不是从“没有进化”走向“有进化”。
更准确地说，第二阶段是在问另一个问题：
当我们已经能复盘一次失败之后，怎么证明一次修改真的让系统变好了？
复盘不等于验证
Dolores 能帮助系统回头看自己哪里出了问题。
但只靠复盘，还不够。
因为一次 skill 修改之后，我们很容易遇到几个问题：
第一，原来的问题修好了吗？
第二，修这个问题的时候，有没有把别的能力改坏？
第三，这次回答变好了，是因为 skill 真的变稳定了，还是只是刚好适配了一个样例？
第四，如果过几天又改了 router、改了 content-creator、改了 emotional-support，怎么知道系统整体有没有退化？
这就是 Thinking Skills 第二阶段要处理的问题。
第二阶段的重点，不是简单新增几个功能，而是把原来的自我进化飞轮继续往前推一步：
从“能复盘一次失败” 走向“能验证一次改进”。这里就需要Benchmark。
Benchmark可以翻译成基准评测或回归评测。
在 Thinking Skills 里，它不是为了做排行榜，也不是为了追求一个漂亮分数。它更像软件工程里的回归测试：把一些固定场景保存下来，每次修改 skill 之后，都可以重新跑一遍，看看行为有没有变好或退化。
这里需要强调一点：
Benchmark 并不是把人的判断拿掉。
恰恰相反，它是把人的判断保存下来。
一次真实失败里，人判断“这不是我想要的回答”；Dolores 和 skill-evaluator 帮助把失败抽象出来；Benchmark 再把这个抽象判断变成以后可以重复检查的案例。
所以当前阶段的 Benchmark 更像 v0 版本的行为回归框架，而不是最终形态的智能裁判系统。
它能帮助发现明显退化，但还不能替代复杂语义质量判断。
Benchmark 是系统的质量记忆
一个 benchmark case 大概长这样：
{"id":"router-learning-vs-technical-001","skill":"thinking-router","prompt":"I read about attention in transformers but I still do not understand it.","expected_route":{"primary":"learning-coach","secondary":null},"expected":["learning-coach"],"must_not":["technical-deep-dive as primary"]}这里的prompt是测试输入，也就是模拟用户会怎么问。
expected_route是期望路由结果。
expected是希望回答或路由里出现的关键行为。
must_not是不应该出现的行为。
这个 case 测的不是 transformer attention 本身。
它真正测试的是一个路由边界：
技术名词不等于技术任务。
用户说自己不理解 attention，这里更像学习问题，而不是架构诊断或源码分析。
所以它应该进入learning-coach，也就是学习教练 skill，而不是直接进入technical-deep-dive，也就是技术深潜 skill。
这就是 benchmark 的意义。
它把一次设计判断变成了可以重复检查的系统记忆。
以前这个判断可能只存在于人的脑子里：
遇到“我不理解某个概念”，不要因为里面有技术词就直接走技术分析。现在它变成了一个固定案例。
以后 router 怎么改、learning-coach 怎么改、technical-deep-dive 怎么改，都可以用这个 case 来检查有没有破坏这个边界。
learning-coach 不是新增一个分类那么简单
第二阶段里，learning-coach的加入也很关键。
表面上看，它只是新增了一个 skill：帮助用户理解概念、建立心智模型、发现知识盲区、做学习路径和练习。
但从系统角度看，它让 Thinking Skills 的路由边界更真实了。
因为很多请求表面上带有技术词，但本质上不是技术决策。
比如：
Explain Kafka like I am new to distributed systems.这不是让 AI 设计 Kafka 架构，也不是让 AI debug Kafka 集群。
用户真正需要的是：
- 一个紧凑的心智模型
- 一个例子
- 常见误解
- 能继续学习的抓手
这时候如果进入technical-deep-dive，回答很可能会变成架构、性能、部署、实现细节。
但用户现在不是要做技术判断，而是要建立理解。
这就是learning-coach的世界观：
学习是建立一个能被回忆、解释、应用和修正的模型。这个 skill 的加入，让 Thinking Skills 更清楚地区分了两件事：
我需要分析一个技术系统。 我需要理解一个技术概念。这两句话都包含技术对象，但它们需要的是完全不同的思考方式。
从 eval 到 benchmark dashboard
有了 benchmark case 还不够。
如果每次跑完结果都散落在命令行里，系统还是缺少长期记忆。
所以第二阶段还加入了Dashboard，也就是质量看板。
质量看板记录不同 benchmark run 的结果：
- 总分变化
- 每个 skill 的分数
- 哪些 case 失败
- 最近失败原因
- 和上一次相比是进步还是退化
这里的benchmark run是一次完整评测运行。
也就是说，同一批固定案例可以在不同版本、不同修改之后重复运行，然后把结果放到看板里比较。
这一步的价值在于，它让 Thinking Skills 不再只依赖“我感觉这版更好”。
它可以开始回答：
这次修改之后，learning-coach 有没有保持稳定？ content-creator 是不是退化了？ emotional-support 的某个失败模式有没有改善？ router 有没有把学习问题错误路由到技术分析？当然，现在的 benchmark 还很轻量。
它不是model-as-judge，也就是不是用另一个模型来做复杂裁判。
它目前更像一个早期的行为回归框架：固定场景、固定期望、简单评分、生成报告。
但这已经足够重要。
因为 Thinking Skills 现在开始有了一种工程化的质量记忆。
失败模式才是真正的质量资产
对 Thinking Skills 来说，最重要的质量资产其实不是某一次 benchmark 的分数。
分数只是一个信号。
真正有价值的是那些被沉淀下来的失败模式：
- 什么时候路由会错
- 什么时候 skill 会选错子模式
- 什么时候回答会问太多问题
- 什么时候方法论会暴露得太重
- 什么时候建议给得太早
- 什么时候一次修补会引入新的退化
这些失败模式，才是系统长期进化的记忆。
比如 Thinking Skills 里已经出现过这样一个情绪支持场景：
用户一开始可能是在做情绪自测或评估，但后来明确说测试阶段已经过了，现在想聊天，想理解更深层的问题。
这时候如果 assistant 继续问很多评估式问题，或者马上进入行动建议，就会产生一种错位感。
这个失败不能简单总结成“这次回答不好”。
它需要被抽象成几个可复用的 failure type，也就是失败类型：
MODE_MISMATCH：skill 对了，但子模式错了QUESTION_OVERLOAD：问题太多ASSESSMENT_STUCK：用户想聊天后仍停留在评估模式PREMATURE_ADVICE：建议给得太早CERTAINTY_OVERREACH：把猜测说得太确定
这些失败类型一旦被沉淀下来，后续就不只是修补某一句回复，而是在修补系统的判断边界。
这也是 Thinking Skills 和普通 prompt collection 最大的不同之一。
普通 prompt collection 往往关注“这个提示词现在好不好用”。
Thinking Skills 更关心：
当它不好用时， 我们能不能知道为什么， 能不能把失败留下来， 能不能避免下次再犯， 能不能确认修改没有带来新的退化。第二阶段的完整飞轮
现在 Thinking Skills 的自我进化飞轮可以更完整地描述为：
真实失败 -> Dolores 对话复盘 -> skill-evaluator 失败分类 -> 抽象 failure case -> 写入 eval 或 benchmark case -> minimal patch -> 跑 benchmark -> dashboard 比较变化 -> 决定继续 patch、调整案例，或重新判断失败来源这里每一步都有自己的责任。
Dolores 负责看见对话级问题。
skill-evaluator 负责分类失败，而不是立刻重写 skill。
failure case 负责把一次私人、具体、偶然的失败，抽象成可复用的问题模式。
eval 和 benchmark 负责让这个问题以后还能被检查。
minimal patch 负责控制修改范围，避免为了一个失败把整个 skill 写得越来越重。
dashboard 负责留下长期质量轨迹。
这就是第二阶段真正的变化。
它不是“多了一个测试工具”。
它是把原来的半自动改进飞轮，接上了可回归验证的一环。
从 skill 仓库到质量系统
我越来越觉得，AI Skill 的难点不在于写出第一版 prompt。
第一版 prompt 很容易让人兴奋。
但真正困难的是：
它能不能持续变好？ 它能不能从失败里学到东西？ 它能不能避免越改越重？ 它能不能知道自己哪里退化了？ 它能不能把一次用户反馈沉淀成长期质量资产？这也是 Thinking Skills 第二阶段真正想探索的方向。
第一阶段，Thinking Skills 证明的是：
AI 不应该默认用一种思考方式处理所有问题。
第二阶段，Thinking Skills 想继续证明：
AI Skill 的改进不应该只靠感觉，而应该能被复盘、被沉淀、被回归验证。
如果说 Dolores 让 Thinking Skills 能够回头看自己哪里想错了，那么 Benchmark 让它进一步能够确认自己有没有真的变好。
这就是我理解的第二阶段：
从领域路由， 到对话复盘， 再到 Benchmark 驱动的自进化。Thinking Skills 不是想做一个更大的 prompt 仓库。
它想做的是一个能持续生长、持续校准、持续验证自己的思考技能系统。
