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

背景
很多 AI Agent workflow 在软件开发场景里已经非常成熟。
它们可以帮助用户分析需求、阅读代码、拆分任务、执行测试、提交变更。这类 coding-first workflow 对开发者很有价值,但它也带来一个隐藏问题:
当用户的请求不明确时,系统很容易默认把它理解成软件开发任务。
例如:
text
我有一个想法,帮我梳理一下。
这句话可能是产品设计,也可能是文章选题,也可能是生活决策,也可能是情绪梳理。
如果系统默认进入 coding workflow,后续所有推理都会偏向 implementation plan、task breakdown、tests、commit 等工程结构。
Thinking Skills 试图解决这个问题。
它的目标不是做一个新的 prompt collection,而是做一个独立的、领域中立的 AI Skill 框架。
核心目标是:
text
把用户请求路由到合适的思考模式,
再由 domain skill 使用自己的世界观、方法底座、输出形态和安全边界来协作。
项目地址:
text
https://github.com/huajiexiewenfeng/thinking-skills
Alpha 版本说明
Thinking Skills 目前仍然是 Alpha 阶段。
这意味着它不是一个已经定型的标准答案,而是一个可以被安装、试用、复盘和共同改进的开放框架。
我更希望它的使用方式是这样的:
- 你把 Thinking Skills 安装到本地 agent 环境。
- 在真实工作、写作、技术讨论、情绪梳理或创意探索中使用它。
- 观察哪些 skill 对你有效,哪些地方不适合你的语境。
- 基于自己的高频场景,进化出专属 skill。
- 如果某个 skill 具有通用价值,可以把它整理成 PR 提到仓库里。
换句话说,Thinking Skills 不只是一个"拿来用"的 skill 仓库。
它更像一个可以长出个人工作流的底座:每个人都可以在本地拥有自己的 thinking skills,也可以把被验证过的好技能贡献回来。
安装方式:
bash
npx skills add huajiexiewenfeng/thinking-skills
总体架构
Thinking Skills 当前的核心链路是:
text
用户请求
-> thinking-router
-> domain skill
-> method bases
-> response
-> meta review layer / Dolores
-> feedback / failure case
-> improvement loop
它包含几个主要层级:
| 层级 | 责任 |
|---|---|
| Router | 判断用户意图并选择 skill |
| Domain Skills | 执行领域专属思考 |
| Meta Skills | 观察 skill 使用轨迹,并把对话失败接入改进循环 |
| Method Bases | 显式声明底层方法 |
| Safety Boundaries | 处理高风险场景和能力边界 |
| Evals | 测试路由、输出形态和失败边界 |
| Improvement Flywheel | 将失败转化为 eval 和 patch |
当前仓库结构大致如下:
text
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。
它的核心规则是:
text
只判断用户应该进入哪种思考模式,不回答用户的实质问题。
这样设计是为了避免一个常见问题:系统在还没有判断任务类型之前,就已经开始用某个领域的模板生成答案。
Router 的职责包括:
- 读取用户请求
- 识别领域信号
- 检查安全或高风险信号
- 选择一个 primary skill
- 必要时选择一个 secondary skill
- 低置信度时只问一个短问题
当前 MVP routing table 包含几类主要路由:
| 用户信号 | Primary Skill |
|---|---|
| 文章、标题、大纲、读者、论点、草稿 | content-creator |
| 代码、架构、debug、性能、API、测试、部署 | technical-deep-dive |
| 焦虑、自责、关系痛苦、情绪困惑、看本质、抓主线 | emotional-support |
| self-review、Dolores、对话复盘、failure case、eval gap | conversation-review meta skill |
混合意图由 primary / secondary skill 处理。
例如:
text
我想写一篇文章,分析这个 API 设计为什么让人困惑。
这类请求的 primary skill 应该是 content-creator,因为用户的最终产物是文章;technical-deep-dive 可以作为 secondary context,用于保证技术判断不失真。
Domain Skills:每个领域有自己的判断标准
Thinking Skills 的一个核心原则是:
text
每个 skill 都应该拥有自己的世界观。
这意味着不同 domain skill 不只是换一套关键词,而是有不同的目标、方法、输出形态和边界。
content-creator
content-creator 的世界观是:
text
写作是与读者沟通。
它用于文章、博客、随笔、脚本、标题、大纲、论点、受众定位和内容结构。
它的输出不应该是工程任务列表,而应该围绕:
- 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 的世界观是:
text
技术推理应该区分事实、假设、推测、权衡和验证。
它适合代码、仓库、架构、debug、性能、API、数据库、测试和部署。
它的典型输出包括:
- 问题框定
- 假设树
- 架构选项
- 权衡表
- 失败模式
- 验证清单
这个 skill 的关键边界是:不要编造没有看过的代码事实。
emotional-support
emotional-support 的世界观是:
text
用户首先需要被接住。
方法论在内部指导回复,但不应该默认倒给用户。
它处理焦虑、自责、羞耻、burnout、关系痛苦、情绪困惑和危机信号。
这里最容易出现的问题是:
- 输出太长
- 问题太多
- 专业术语太多
- 太早给建议
- 把普通陪谈变成评估问卷
- 用确定语气替用户定性
因此该 skill 现在被拆成主 SKILL.md 和多个 reference modules:
text
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 是:
text
conversation-review / Dolores
conversation-review / Dolores:Conversation Self-Review
conversation-review 是最近新增的重要模块。
它的模式名是:
text
Dolores
Dolores Mode 的命名灵感来自《Westworld》里的女主角 Dolores 人工智能觉醒过程。
在 Thinking Skills 里,这个名字指向一个更具体的工程含义:
text
Conversation Self-Review & Improvement Loop
也就是说,AI 可以回看自己的"记忆",也就是当前可用的 conversation context,审查刚才的 skill 触发、路由选择、模式切换和输出质量,并在最终输出或后续 patch 前进行结构性的自我修正。
这个名称只是主题隐喻。Thinking Skills 与《Westworld》及其权利方没有关联。
它的世界观是:
text
对话不只是回答流,也是一条可以被观察的思考轨迹。
它用于做 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 系统的元技能:
text
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 的区别是:
text
conversation-review / Dolores 看整段对话的 skill trace;
skill-evaluator 看具体失败的分类、eval gap 和 patch discipline。
Method Bases:不要只依赖模型通用能力
Thinking Skills 不希望 domain skill 完全依赖大模型的泛化能力。
每个 skill 都应该声明 method bases。
例如:
yaml
method_bases:
core:
- Audience-first writing
- Thesis-driven structure
supporting:
- Inverted pyramid
- Problem-agitation-solution
safety:
- Avoid fabricating facts
方法底座有几个作用:
- 明确 skill 的判断标准。
- 约束输出形态。
- 帮助未来贡献者理解设计意图。
- 为 eval case 提供依据。
- 避免每次修改都变成主观偏好。
但方法论不应该默认暴露给用户。
尤其在 emotional-support 这类场景中,CBT、ACT、NVC、trauma-informed stance 等框架可以指导模型注意力,但不应该默认变成用户面前的术语清单。
Evaluation:用 cases 测行为,而不是只看感觉
当前项目使用 Markdown 形式维护 eval cases。
例如:
text
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 通常包含:
yaml
id:
skill:
type:
prompt:
context:
expected:
must_not:
quality_checks:
这种结构让项目可以把一次失败沉淀成可重复检查的行为要求。
Improvement Flywheel:从失败到补丁
Thinking Skills 的自进化不是指模型自动神秘变强,而是指项目有一套半自动改进飞轮。
当前流程是:
text
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
这个流程的关键原则是:
text
不要因为一次回答感觉不好,就直接大改 skill。
先判断:
- 失败是什么?
- 是否可复用?
- 应该改 router 还是 domain skill?
- 是否需要新增 eval?
- 最小修改是什么?
项目中已经有抽象失败案例,例如:
text
cases/emotional-support/caregiver-overload-too-fast-advice.md
这个 case 记录的是一种 reusable failure pattern:
用户处在长期照护压力中,AI 如果过快进入建议,会忽略更重要的结构性压力和支持系统缺失。
这个失败被抽象成 case 后,可以进一步进入 eval 和 patch 流程。
Platform Adapters:核心内容保持平台中立
Thinking Skills 的 canonical skill 内容放在:
text
skills/
平台目录只是薄适配层:
text
.codex/
.codex-plugin/
.claude-plugin/
.cursor-plugin/
.opencode/
当前平台支持状态:
| Adapter | Status |
|---|---|
| Codex native skills | Done, locally verified |
| Codex plugin | Implemented |
| Claude Code plugin | Implemented |
| Cursor plugin/rules | Implemented |
| OpenCode adapter | Implemented |
设计原则是:
text
Platform adapters should not fork the skill content.
也就是说,各平台不维护自己的 skill 副本,而是尽量指向同一份 skills/ 内容。
Roadmap
当前 first-party skills 包括:
Domain and routing skills:
thinking-routercontent-creatortechnical-deep-diveemotional-support
Meta and improvement skills:
conversation-reviewskill-evaluator
规划中的 skills 包括:
life-decisioncreative-studiolearning-coachbusiness-strategy
后续重点包括:
- 扩展更多非编程领域
- 增加结构化 eval cases
- 做真实客户端测试
- 强化 feedback 和 quality dashboard
- 持续优化 emotional-support 的输出质量
总结
Thinking Skills 想解决的问题不是"再写几个好用的 prompt"。
它想把 AI Skill 做成一个可维护系统:
text
Intent Router
+ Domain Thinking Skills
+ Method Bases
+ Safety Boundaries
+ Evals
+ Conversation Review
+ Improvement Flywheel
这个系统的核心价值在于:
- 不默认所有问题都是 coding
- 不让一个万能 prompt 处理所有场景
- 不把领域方法论完全交给模型自由发挥
- 不让失败停留在主观感觉
- 不让平台适配分裂核心 skill 内容
从 prompt collection 到可演进系统,这是 Thinking Skills 当前最重要的设计方向。