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

把 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 阶段。

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

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

  1. 你把 Thinking Skills 安装到本地 agent 环境。
  2. 在真实工作、写作、技术讨论、情绪梳理或创意探索中使用它。
  3. 观察哪些 skill 对你有效,哪些地方不适合你的语境。
  4. 基于自己的高频场景,进化出专属 skill。
  5. 如果某个 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-creatortechnical-deep-diveemotional-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

方法底座有几个作用:

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

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

尤其在 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-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 做成一个可维护系统:

text 复制代码
Intent Router
+ Domain Thinking Skills
+ Method Bases
+ Safety Boundaries
+ Evals
+ Conversation Review
+ Improvement Flywheel

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

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

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

相关推荐
fuquxiaoguang15 小时前
算力变天:当AI从“训练狂魔”转向“推理为王”
人工智能·openai·甲骨文·3000亿美元推理订单
程序员cxuan15 小时前
Codex 官方:/goal 的正确打开方式
人工智能·后端·程序员
tedcloud12316 小时前
wifi-densepose部署教程:构建无线感知AI实验环境
服务器·人工智能·系统架构·powerpoint·dreamweaver
2601_9594779116 小时前
Vatee:从技术架构看平台运行稳定性
大数据·人工智能·安全
穗余16 小时前
hermes agent出现Empty response原因和解决方案
人工智能·web3·区块链
英辰朗迪AI获客16 小时前
AI动态简报之算力基建篇(2026.05.25)
人工智能
o561路6o623o716 小时前
陈,反应时刺激器 无线运动生理 指脉换能器 心音换能器
人工智能
小仙女的小稀罕16 小时前
适合企业行政整理会议录音,总结会议纪要推荐
人工智能
不爱洗脚的小滕16 小时前
【向量数据库】Milvus 稠密与稀疏向量核心解析
数据库·人工智能·milvus
甲维斯16 小时前
MiMo2.5Pro《江湖百晓生》测试过程和结果!
人工智能·ai编程