1. 从一条自定义命令说起：为什么"技能"这个概念值得单独拎出来讲
很多人第一次接触命令行里的 AI 助手，都是从一条自定义命令开始的。比如你在终端里敲一个简短的别名，它就去帮你做代码审查、生成提交信息、或者把一段日志翻译成人话。用起来很爽，但用久了你会发现一个问题：这些命令是散的。它们散落在不同的配置文件里，散落在不同人的 dotfiles 里，散落在各种"我本地能跑，你那边报错"的尴尬里。
我最早也是这么干的。当时我在一个跨平台项目里维护了七八条自定义命令，每条都对应一个具体的活儿：有的负责把散乱的接口文档整理成结构化注释，有的负责在提交前扫一遍改动、提示潜在的空指针风险，还有的负责把一段报错日志压缩成三行以内的结论。刚开始觉得挺高效，直到团队里第二个人想复用我的命令，问题就全冒出来了——他缺一个环境变量，我少写了一个路径判断，第三个人用的 shell 版本还不一样。那一刻我意识到，自定义命令解决的是"我一个人的效率"，但解决不了"一群人的协作"。
这就是"技能"这个概念要登场的地方。所谓技能，本质上是对自定义命令的一次抽象升级：它不再是一条孤立的命令，而是一个有名字、有描述、有输入输出约定、有依赖声明、可以被发现和复用的能力单元。你可以把它理解成从"手写脚本"到"封装成函数库"的那一步跨越。命令是动词，技能是名词——命令是"你去干这件事"，技能是"我具备干这件事的能力"。
这个区别听起来有点绕，但落到实际使用里非常具体。一条自定义命令，你得知道它叫什么、放在哪、怎么调用；而一个技能，你只需要知道"我需要做代码审查"，系统就能告诉你"这里有一个代码审查技能，它的输入是 diff，输出是问题清单"。前者靠记忆，后者靠发现。前者是个人资产，后者是生态资产。
我之所以想把这个演进过程完整地讲一遍，是因为我发现很多人在用这类工具时，卡在了"会写命令"和"会用技能"之间的那道坎上。他们能写出很漂亮的单条命令，但一旦要组织成一套可维护、可分享、可组合的能力体系，就不知道从哪下手了。这篇文章就围绕这条演进路径展开：从最原始的自定义命令，到技能的结构化定义，再到技能之间如何组合、如何被调度、如何形成一个真正能用的生态。中间我会穿插大量我自己踩过的坑，包括命名冲突、上下文污染、权限边界这些在官方文档里往往一笔带过、但实际用起来能让人抓狂的细节。
适合谁看？如果你已经在用命令行里的 AI 助手，并且开始觉得"每次都要重新描述一遍需求"很烦，那这篇就是写给你的。如果你还没开始用，但想搞清楚"技能"到底比"命令"强在哪，也可以顺着往下看，我会尽量用生活化的类比把概念讲透。
2. 自定义命令的天花板：三个绕不过去的现实问题
2.1 命名空间混乱：当你有二十条命令的时候
自定义命令最开始的体验是极好的。你写一条review，敲下去就出结果。再写一条summarize，也很顺。问题出在数量增长之后。当你手里有二十条命令，你会发现命名开始打架：review到底是审查代码还是审查文档？fix是修格式还是修逻辑？check检查的是依赖还是类型？
我见过一个团队的做法是加前缀，比如fe-review、be-review、doc-review。这确实能缓解冲突，但代价是命令名越来越长，记忆成本越来越高。更麻烦的是，前缀本身没有语义约束——你没法阻止别人再起一个fe-review-v2，于是混乱只是被推迟了，没有被解决。
这个问题的本质是：自定义命令没有"命名空间"这个概念，它只有一个扁平的命令列表。而技能体系里，每个技能都有明确的归属和分类，你可以按领域、按用途、按团队去组织，冲突在结构层面就被消解了。
2.2 上下文无法传递：命令之间是孤岛
第二个问题是上下文。假设你先用一条命令把一段代码拆成了函数列表，然后想用另一条命令对每个函数生成注释。在纯命令模式下，你得手动把第一条命令的输出复制出来，再喂给第二条。中间任何一步格式对不上，就得人工调整。
这就像你有一堆很好用的工具，但每个工具之间没有传送带。你得自己当那个传送带，把半成品从一台机器搬到另一台机器。偶尔搬几次还行，天天搬就是纯体力活。
技能体系解决这个问题的思路是：把输入输出标准化。一个技能声明它接受什么格式的输入、产出什么格式的输出，另一个技能声明它需要什么输入。只要格式对得上，系统就能自动把前者的输出接到后者的输入上。你不再需要当传送带，你只需要描述"我要完成什么"，剩下的连接工作交给调度层。
2.3 权限与边界模糊：一条命令能干什么，没人说得清
第三个问题最隐蔽，也最危险。一条自定义命令，本质上就是一段可以执行任意操作的脚本。它可能只是读读文件，也可能顺手把你的配置改了、把某个目录删了、把敏感信息发到某个地方。在个人环境里，你信任自己写的命令；但在团队环境里，别人写的命令你敢直接跑吗？
我遇到过最惊险的一次，是某条命令在"整理临时文件"的时候，把一个还没提交的改动目录给清空了。写命令的人本意是清理缓存，但他用的通配符范围太大。这件事之后，我们团队定了一条规矩：任何会写文件的自定义命令，必须显式声明它要动哪些路径。
技能体系在这方面的优势是，它天然要求你声明能力边界。一个技能能读什么、能写什么、能调用什么外部资源，都是定义的一部分。这不是为了限制你，而是为了让"信任"这件事有据可依。你可以放心地把一个只读技能交给新人用，因为它的边界是写死的。
3. 技能的结构化定义：一个技能到底由哪些部分组成
3.1 名称与描述：让技能可被发现
一个技能的第一要素是名称和描述。名称要短、要唯一、要能望文生义；描述要一句话说清楚"这个技能解决什么问题"。这两样东西决定了技能能不能被找到。
我见过很多写得不好的技能描述，典型的有两种：一种是太笼统，比如"处理代码"，这等于没说；另一种是太技术化，比如"基于 AST 的语义分析并输出 JSON"，用户根本不知道这能帮他干什么。好的描述应该站在使用者的角度，比如"审查代码改动，指出潜在的空指针和边界问题"。
这里有个我自己的经验：描述里最好带上触发场景。比如"当你准备提交代码前，用这个技能扫一遍改动"。这样用户在需要的时候能立刻联想到它，而不是在一堆技能列表里翻找。
3.2 输入输出契约：技能之间的通用语言
输入输出契约是技能体系里最关键的设计。它规定了技能接受什么、产出什么。这个契约可以是简单的文本，也可以是结构化的数据格式。
为什么契约这么重要？因为它是技能组合的基础。如果每个技能的输入输出都是自由格式的自然语言，那组合起来就是一场灾难——你得用另一个 AI 去解析前一个 AI 的输出，误差会层层累积。而如果契约是结构化的，比如固定的字段名和类型，那组合就是可靠的拼接。
我一般会把输入输出设计成"最小必要"的形式。比如一个代码审查技能，输入就是 diff 文本加可选的规则配置，输出就是问题列表，每条问题包含位置、类型、严重程度、建议。不多不少，刚好够用。设计得太复杂，别人不愿意用；设计得太简单，又表达不了必要信息。
3.3 依赖声明：技能不是凭空运行的
任何技能都可能依赖外部条件：某个命令行工具、某个环境变量、某个版本的运行时。这些依赖如果不声明，用户拿到技能后第一件事就是踩坑。
我踩过最典型的一个坑，是一个技能依赖某个特定版本的格式化工具，但没写进依赖里。结果在别人的机器上，工具版本不同，输出格式就变了，下游技能直接解析失败。排查了半天才发现是版本问题。
所以依赖声明不是可选项，是必选项。它至少应该包含：需要哪些可执行程序、需要哪些环境变量、对版本有没有要求。声明清楚了，用户在安装技能时就能一次性把环境准备好，而不是运行到一半才报错。
3.4 权限边界：能做什么，不能做什么
权限边界是技能定义里最容易被忽略、但长期来看最重要的一部分。它明确告诉使用者：这个技能会读哪些路径、会写哪些路径、会不会发起网络请求、会不会修改系统配置。
我现在的习惯是，任何会写文件的技能，都在定义里列出它可能触及的路径范围。任何会发起网络请求的技能，都说明请求的目标类型。这不是为了形式主义，而是为了让使用者在运行前心里有数。尤其是当技能来自第三方时，这份声明就是信任的基础。
4. 技能组合与调度：从单点能力到工作流
4.1 串行组合：把多个技能接成一条流水线
技能真正发挥威力，是在组合的时候。最简单的组合是串行：技能 A 的输出作为技能 B 的输入，B 的输出再给 C。这就像工厂里的流水线，每个工位只做一件事，但连起来就能完成复杂任务。
举个我实际用过的例子。我有一条流水线是这样的：第一个技能读取最近的代码改动，提取出变更的函数；第二个技能对每个变更函数生成单元测试草稿；第三个技能检查这些测试草稿有没有明显的逻辑漏洞。三个技能各司其职，串起来就完成了一件我一个人要花半小时才能干完的事。
串行组合的关键是格式对齐。A 的输出格式必须能被 B 解析。这就是为什么前面强调输入输出契约——契约就是流水线上的传送带标准，标准统一了，拼接才顺畅。
4.2 并行与条件分支：不是所有技能都要排队
有些技能之间没有依赖关系，可以并行跑。比如你要同时检查代码风格、检查依赖安全、检查文档完整性，这三件事互不干扰，完全可以同时进行。并行能显著缩短总耗时，尤其是在每个技能都要调用外部服务的时候。
条件分支则更灵活一些。比如一个技能先判断改动的类型：如果是新增功能，就走"生成测试"的分支；如果是修 bug，就走"回归验证"的分支。这种分支逻辑让工作流有了"判断力"，而不是死板地一条路走到黑。
我一般会把条件判断做得尽量简单，因为分支越多，调试越难。如果发现分支超过三个，我会考虑把它拆成多个独立的工作流，而不是硬塞进一个。
4.3 调度层的角色：谁来决定先跑哪个
调度层是技能生态里的"大脑"。它负责决定哪个技能先跑、哪个后跑、哪些可以并行、遇到错误怎么处理。在简单的场景里，调度可以是你手动指定的顺序；在复杂的场景里，调度可以基于技能声明的依赖关系自动推导执行顺序。
我见过两种调度风格。一种是显式编排，你明确写出"先 A 再 B 再 C"，控制力强但不够灵活。另一种是声明式，你只声明"我要完成 X 目标"，调度层根据技能的能力描述自动组合出执行路径。后者更智能，但对技能描述的准确性要求极高——描述写歪了，调度就会组合出奇怪的路径。
实际用下来，我的建议是：核心流程用显式编排，保证稳定；探索性任务用声明式，享受灵活。两者不是对立的，可以混用。
5. 生态视角：技能如何被分享、复用与演进
5.1 分享的障碍：为什么好技能传不开
一个技能写得再好，如果传不开，价值就有限。而技能分享的障碍往往不在技术层面，而在"信任"和"适配"两个层面。
信任问题是：别人凭什么相信你的技能不会干坏事？这就需要权限边界声明足够清晰，最好还能有某种形式的验证机制。适配问题是：你的技能依赖的环境，别人不一定有。这就需要依赖声明足够完整，最好还能有自动化的环境准备。
我观察到的一个现象是，那些被广泛复用的技能，往往不是功能最强大的，而是边界最清晰、依赖最少、描述最直白的。功能强大但依赖一堆私有环境的技能，反而没人敢用。
5.2 版本演进：技能也会过时
技能不是写完就一劳永逸的。外部工具会升级，输入输出的格式会变，使用场景会迁移。一个技能如果长期不更新，慢慢就会失效。
我自己的做法是给技能加版本号，并且在描述里注明它适配的环境范围。当外部条件变化时，我倾向于新增一个版本而不是直接改老版本，这样依赖老版本的用户不会突然被打断。这跟软件库的版本管理是一个道理——破坏性变更要谨慎，兼容性要尽量保持。
5.3 从个人技能到团队资产：一次真实的迁移
最后分享一段我自己的迁移经历。最开始我的技能都是个人用的，散在一个私有目录里。后来团队想复用，我们做了一次整理：把技能按领域分类，统一了输入输出格式，补全了依赖声明和权限边界，还写了一份简单的使用说明。
整理过程中发现，真正需要保留的技能只有原来的一半左右。很多技能是临时写的，用完就废了；还有一些功能重叠，可以合并。这次整理让我意识到，技能生态的健康度不在于数量，而在于每个技能是否清晰、是否可组合、是否有人真正在用。
迁移之后最大的变化是，新人上手的时间从原来的半天缩短到了半小时。因为他们不需要理解每条命令背后的实现，只需要看技能描述和输入输出契约，就能把技能串起来用。这就是从"命令"到"技能"再到"生态"这条演进路径的真正价值——它把个人经验变成了可传递、可组合、可演进的集体能力。
如果你现在手里还只有一堆散乱的自定义命令，我的建议是先从最常用的那几条开始，把它们改写成有名称、有描述、有输入输出契约的技能。不用一次全改完，改一条用一条，慢慢你就会感受到那种"能力可以被组合"的顺畅感。这个过程我走过，前期确实有点麻烦，但一旦跨过去，后面省下的时间远超投入。
