把 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 当前最重要的设计方向。

相关推荐
等风来不如迎风去1 小时前
【win11】最佳性能:fix 没有壁纸,一直黑屏
网络·人工智能
云云只是个程序马喽1 小时前
AI漫剧创作系统开发定制指南
人工智能·小程序·php
Elastic 中国社区官方博客2 小时前
Elastic 和 Cursor 合作 加速 上下文工程 与 coding agents
大数据·人工智能·elasticsearch·搜索引擎·全文检索
迦南的迦 亚索的索2 小时前
AI_12_Dify_平台介绍
人工智能
HIT_Weston2 小时前
68、【Agent】【OpenCode】用户对话提示词(任务执行流程)
人工智能·agent·opencode
ting94520002 小时前
Micro1 超详细深度解析:架构原理、部署实战、性能评测与落地应用全指南
人工智能·架构
冰西瓜6002 小时前
深度学习的数学原理(三十三)—— Transformer编码器完整实现
人工智能·深度学习·transformer
科研前沿2 小时前
镜像孪生VS视频孪生核心技术产品核心优势
大数据·人工智能·算法·重构·空间计算
DreamBoy@2 小时前
Mnemra:一键剪藏,让灵感真正可复用(一键从Ai对话页面到飞书云文档,浏览器插件方便好用)
人工智能