把 AI Skill 做成系统：路由、领域技能、自我复盘和进化飞轮

把 AI Skill 做成系统：路由、领域技能、自我复盘和进化飞轮

背景

很多 AI Agent workflow 在软件开发场景里已经非常成熟。

它们可以帮助用户分析需求、阅读代码、拆分任务、执行测试、提交变更。这类 coding-first workflow 对开发者很有价值，但它也带来一个隐藏问题：

当用户的请求不明确时，系统很容易默认把它理解成软件开发任务。

例如：

我有一个想法，帮我梳理一下。

这句话可能是产品设计，也可能是文章选题，也可能是生活决策，也可能是情绪梳理。

如果系统默认进入 coding workflow，后续所有推理都会偏向 implementation plan、task breakdown、tests、commit 等工程结构。

Thinking Skills 试图解决这个问题。

它的目标不是做一个新的 prompt collection，而是做一个独立的、领域中立的 AI Skill 框架。

核心目标是：

把用户请求路由到合适的思考模式， 再由 domain skill 使用自己的世界观、方法底座、输出形态和安全边界来协作。

项目地址：

https://github.com/huajiexiewenfeng/thinking-skills

Alpha 版本说明

Thinking Skills 目前仍然是 Alpha 阶段。

这意味着它不是一个已经定型的标准答案，而是一个可以被安装、试用、复盘和共同改进的开放框架。

我更希望它的使用方式是这样的：

1. 你把 Thinking Skills 安装到本地 agent 环境。
2. 在真实工作、写作、技术讨论、情绪梳理或创意探索中使用它。
3. 观察哪些 skill 对你有效，哪些地方不适合你的语境。
4. 基于自己的高频场景，进化出专属 skill。
5. 如果某个 skill 具有通用价值，可以把它整理成 PR 提到仓库里。

换句话说，Thinking Skills 不只是一个“拿来用”的 skill 仓库。

它更像一个可以长出个人工作流的底座：每个人都可以在本地拥有自己的 thinking skills，也可以把被验证过的好技能贡献回来。

安装方式：

npx skillsaddhuajiexiewenfeng/thinking-skills

总体架构

Thinking Skills 当前的核心链路是：

用户请求 -> thinking-router -> domain skill -> method bases -> response -> meta review layer / Dolores -> feedback / failure case -> improvement loop

它包含几个主要层级：

当前仓库结构大致如下：

thinking-skills/ skills/ thinking-router/ content-creator/ technical-deep-dive/ emotional-support/ conversation-review/ skill-evaluator/ docs/ architecture-memory.md routing.md method-bases.md safety.md evaluation.md improvement-loop.md failure-taxonomy.md eval-schema.md eval-runbook.md platforms.md roadmap.md evals/ routing-cases.md content-creator-cases.md technical-deep-dive-cases.md emotional-support-cases.md conversation-review-cases.md skill-evaluator-cases.md cases/ emotional-support/ feedback/

Router 层：只路由，不解决

thinking-router是入口 skill。

它的核心规则是：

只判断用户应该进入哪种思考模式，不回答用户的实质问题。

这样设计是为了避免一个常见问题：系统在还没有判断任务类型之前，就已经开始用某个领域的模板生成答案。

Router 的职责包括：

• 读取用户请求
• 识别领域信号
• 检查安全或高风险信号
• 选择一个 primary skill
• 必要时选择一个 secondary skill
• 低置信度时只问一个短问题

当前 MVP routing table 包含几类主要路由：

混合意图由 primary / secondary skill 处理。

例如：

我想写一篇文章，分析这个 API 设计为什么让人困惑。

这类请求的 primary skill 应该是content-creator，因为用户的最终产物是文章；technical-deep-dive可以作为 secondary context，用于保证技术判断不失真。

Domain Skills：每个领域有自己的判断标准

Thinking Skills 的一个核心原则是：

每个 skill 都应该拥有自己的世界观。

这意味着不同 domain skill 不只是换一套关键词，而是有不同的目标、方法、输出形态和边界。

content-creator

content-creator的世界观是：

写作是与读者沟通。

它用于文章、博客、随笔、脚本、标题、大纲、论点、受众定位和内容结构。

它的输出不应该是工程任务列表，而应该围绕：

• reader
• angle
• thesis
• structure
• hook
• evidence plan
• revision direction

最近版本中，content-creator增加了多轮写作流程：

• Content Stage Detection
• Running Content Brief
• Initial Idea Gate
• Approval Gates
• Evidence Planning

这使它更像一个编辑，而不是一次性生成器。

technical-deep-dive

technical-deep-dive的世界观是：

技术推理应该区分事实、假设、推测、权衡和验证。

它适合代码、仓库、架构、debug、性能、API、数据库、测试和部署。

它的典型输出包括：

• 问题框定
• 假设树
• 架构选项
• 权衡表
• 失败模式
• 验证清单

这个 skill 的关键边界是：不要编造没有看过的代码事实。

emotional-support

emotional-support的世界观是：

用户首先需要被接住。 方法论在内部指导回复，但不应该默认倒给用户。

它处理焦虑、自责、羞耻、burnout、关系痛苦、情绪困惑和危机信号。

这里最容易出现的问题是：

• 输出太长
• 问题太多
• 专业术语太多
• 太早给建议
• 把普通陪谈变成评估问卷
• 用确定语气替用户定性

因此该 skill 现在被拆成主SKILL.md和多个 reference modules：

skills/emotional-support/ SKILL.md references/ default-response.md deep-analysis-mode.md mode-boundaries.md reflection-frames.md safety-boundary.md

设计目标是：让方法论留在底层，用户看到的是更短、更像人、更可校准的回复。

Meta Skills：让 Skill 系统观察自己

如果只有 router 和 domain skills，Thinking Skills 仍然只是一个更结构化的 skill collection。

它可以回答不同领域的问题，但还不能稳定地观察自己。

真正让它接近“自进化框架”的，是 meta skill 层。

Meta skill 不直接属于某个业务领域。它的对象不是文章、代码或情绪，而是一次 AI 协作过程本身。

当前最重要的 meta skill 是：

conversation-review / Dolores

conversation-review / Dolores：Conversation Self-Review

conversation-review是最近新增的重要模块。

它的模式名是：

Dolores

Dolores Mode 的命名灵感来自《Westworld》里的女主角 Dolores 人工智能觉醒过程。

在 Thinking Skills 里，这个名字指向一个更具体的工程含义：

Conversation Self-Review & Improvement Loop

也就是说，AI 可以回看自己的“记忆”，也就是当前可用的 conversation context，审查刚才的 skill 触发、路由选择、模式切换和输出质量，并在最终输出或后续 patch 前进行结构性的自我修正。

这个名称只是主题隐喻。Thinking Skills 与《Westworld》及其权利方没有关联。

它的世界观是：

对话不只是回答流，也是一条可以被观察的思考轨迹。

它用于做 conversation self-review，观察一段对话中的：

• skill 触发轨迹
• router 选择是否合理
• domain skill 是否匹配
• 子模式是否切换正确
• 输出是否过长、过冷、过度专业化
• 是否出现 failure signal
• 是否存在 eval gap
• 是否应该进入 improvement loop

因此，Dolores 不应该被看成和content-creator、technical-deep-dive、emotional-support同等级的 domain skill。

它更像是 AI Skill 系统的元技能：

Domain skills produce answers. Dolores reviews how those answers were produced.

这让 Thinking Skills 具备了对话级自我观察能力，也让后面的 improvement flywheel 有了入口。

skill-evaluator

skill-evaluator负责具体失败诊断。

它回答的问题不是“这个回答好不好”，而是：

• 失败类型是什么？
• 是 router 问题还是 domain skill 问题？
• 是否缺少 eval？
• 最小 patch 应该是什么？
• 这次修改是否有过拟合风险？

它和conversation-review的区别是：

conversation-review / Dolores 看整段对话的 skill trace； skill-evaluator 看具体失败的分类、eval gap 和 patch discipline。

Method Bases：不要只依赖模型通用能力

Thinking Skills 不希望 domain skill 完全依赖大模型的泛化能力。

每个 skill 都应该声明 method bases。

例如：

method_bases:core:-Audience-first writing-Thesis-driven structuresupporting:-Inverted pyramid-Problem-agitation-solutionsafety:-Avoid fabricating facts

方法底座有几个作用：

1. 明确 skill 的判断标准。
2. 约束输出形态。
3. 帮助未来贡献者理解设计意图。
4. 为 eval case 提供依据。
5. 避免每次修改都变成主观偏好。

但方法论不应该默认暴露给用户。

尤其在 emotional-support 这类场景中，CBT、ACT、NVC、trauma-informed stance 等框架可以指导模型注意力，但不应该默认变成用户面前的术语清单。

Evaluation：用 cases 测行为，而不是只看感觉

当前项目使用 Markdown 形式维护 eval cases。

例如：

evals/ routing-cases.md content-creator-cases.md technical-deep-dive-cases.md emotional-support-cases.md conversation-review-cases.md skill-evaluator-cases.md

Eval 主要覆盖：

• router 准确性
• domain fit
• mixed intent
• negative cases
• safety boundaries
• output shape
• failure regression

一个 eval case 通常包含：

id:skill:type:prompt:context:expected:must_not:quality_checks:

这种结构让项目可以把一次失败沉淀成可重复检查的行为要求。

Improvement Flywheel：从失败到补丁

Thinking Skills 的自进化不是指模型自动神秘变强，而是指项目有一套半自动改进飞轮。

当前流程是：

Failure signal -> conversation self-review / Dolores -> abstract failure case -> classify failure -> add or update eval -> evaluate current skill -> propose minimal patch -> apply patch -> update changelog -> retest

这个流程的关键原则是：

不要因为一次回答感觉不好，就直接大改 skill。

先判断：

• 失败是什么？
• 是否可复用？
• 应该改 router 还是 domain skill？
• 是否需要新增 eval？
• 最小修改是什么？

项目中已经有抽象失败案例，例如：

cases/emotional-support/caregiver-overload-too-fast-advice.md

这个 case 记录的是一种 reusable failure pattern：

用户处在长期照护压力中，AI 如果过快进入建议，会忽略更重要的结构性压力和支持系统缺失。

这个失败被抽象成 case 后，可以进一步进入 eval 和 patch 流程。

Platform Adapters：核心内容保持平台中立

Thinking Skills 的 canonical skill 内容放在：

skills/

平台目录只是薄适配层：

.codex/ .codex-plugin/ .claude-plugin/ .cursor-plugin/ .opencode/

当前平台支持状态：

设计原则是：

Platform adapters should not fork the skill content.

也就是说，各平台不维护自己的 skill 副本，而是尽量指向同一份skills/内容。

Roadmap

当前 first-party skills 包括：

Domain and routing skills：

• thinking-router
• content-creator
• technical-deep-dive
• emotional-support

Meta and improvement skills：

• conversation-review
• skill-evaluator

规划中的 skills 包括：

• life-decision
• creative-studio
• learning-coach
• business-strategy

后续重点包括：

• 扩展更多非编程领域
• 增加结构化 eval cases
• 做真实客户端测试
• 强化 feedback 和 quality dashboard
• 持续优化 emotional-support 的输出质量

总结

Thinking Skills 想解决的问题不是“再写几个好用的 prompt”。

它想把 AI Skill 做成一个可维护系统：

Intent Router + Domain Thinking Skills + Method Bases + Safety Boundaries + Evals + Conversation Review + Improvement Flywheel

这个系统的核心价值在于：

• 不默认所有问题都是 coding
• 不让一个万能 prompt 处理所有场景
• 不把领域方法论完全交给模型自由发挥
• 不让失败停留在主观感觉
• 不让平台适配分裂核心 skill 内容

从 prompt collection 到可演进系统，这是 Thinking Skills 当前最重要的设计方向。