技能

TL;DR：如果你在使用Codex，command（命令） 用于控制会话或应用程序，而skill（技能） 用于教代理一种工作方法。在Claude Code中，目前的文档已经将技能视为可以用/skill-name直接调用的东西，所以这两种概念在Claude Code中更为融合。但在Codex中恰恰相反：types可以作为技能存在，但/types却可能不存在。 当你从Claude Code切换到Codex时，这种混淆非常常见。而且可以理解。 你创建了一个名为types的技能，回到终端时满怀信心地输入/types……然后Codex看着你，就像你在五金店里要了一杯拉格啤酒。 问题不是技能坏掉了。问题在于，在Codex中，技能和命令并不是一回事。 请注意，这种差异并非表面上的不同，它会彻底改变你设计工作流的方式。 一个让你秒懂的类比 想象一下，Codex就像是一架有两层结构的飞机。 第一层是驾驶舱：按钮、杠杆、指示器。这是命令的栖息地，用于改变会话、客户端或工具的状态，这是操作控制。 第二层是副驾驶手册：流程、标准、检查清单、避免陷阱的指南。这是技能的领域，用于改变代理思考和执行任务的方式。 通俗地讲： 命令是动驾驶舱里的按钮。 技能是改副驾驶脑中的手册。 如果你把手册当成按钮来用，那肯定行不通。 什么是Codex中的命令 在Codex中，命令有两种形式，千万别搞混。 第一种是CLI命令： codex login codex exec "run tests and fix failures" codex resume --last codex apply --- 这很直接明了。这些是应用程序的操作：登录、运行任务、恢复会话、应用变更。如果明天系统中没有了模型，这些命令依然有意义。 第二种是**交互式会话中的斜杠命令**： ```text /model /permissions /personality /agent /status 它们也并非是“华丽的提示语”。它们控制的是实时的会话：更改模型、调整权限、切换人物风格、设定活动线程或改变可见状态。这些就像驾驶舱中的控制按钮。 OpenAI事实上非常清晰地记录了它们的用途：一方面，有专门的斜杠命令页面用于“在交互会话中控制Codex”的说明；另一方面，另有一份独立的技能页面，将技能定义为可重用工作流的创建格式。 这也是为什么有些操作会成为命令而不是技能：因为它们需要可预测性、即时响应和稳定语义。你不希望模型“有创意地解释”/permissions的含义。你只希望它直接更改权限。就这么简单。 什么是Codex中的技能 Codex中的技能是完全不同的东西。它就是一个可重用的工作流，用来教给代理何时运用某种方法、如何思考某个任务并按照特定步骤操作。 这里还有一个细微但重要的区别：OpenAI表示，skill是一种编写格式，而**plugin（插件）**是可安装或分发的单元。换句话说，你会先将工作流设计为技能；如果需要分享或进行封装，就可以把它打包成插件。 明确的例子： $types $improve $owasp $blog 或者，如果更偏语言化： 使用types来审计这个代码仓库 使用improve来检查这个diff 你在这些例子里并不是叫Codex去“切换设置”。你是在告诉它，“当我让你执行这项任务时，请按照这套剧本来操作”。 以我的types技能为例，它不应该是个按钮。它的工作是读取项目代码、检测语言、检查模型、寻找“字符串类型化的代码”、判断一个Optional的使用是否合理并是否能正确建模域状态。这需要背景和判断能力，正是技能擅长的工作。 同理，improve作为一个技能也讲得通：检查diff并不是什么机械性的操作，反而涉及到判断、上下文和优先级的权衡。 为什么在Claude Code中“看起来像是一样的” 这里就是认知的陷阱了。 最新的Claude Code文档对这一点已经毫不避讳了。它谈到技能时，会告诉你可以通过以下方式直接调用： /skill-name 也就是说，在Claude Code中，你认为的某些属于“可重用工作流”的东西是通过斜杠命令语法来调用的。用户体验上，它将Codex中分离的两个概念合并了： ...

TL;DR：我的AI代理有一个246行的指令文件用于管理Linear中的问题。其中150行是变通方法：硬编码的UUID、对curl的回退、“CLI不支持X"的注释。我没有重写它们——而是构建了一个让它们变得不必要的工具。现在那150行变成了零行。 你是否曾经写过一份指令文档，它的长度本身就证明了有什么地方不对劲？ 我指的不是合理的文档。我指的是那些开头说"使用工具X”，然后花80%的篇幅解释工具X什么时候不工作以及应该如何替代的文件。那些实际上是为本应构建的工具道歉清单的指令。 我有一个这样的文件。而且很令人尴尬。 150行垃圾的解剖 背景：我与一个AI代理（Claude Code）合作，它管理我在Linear中的问题。为了让代理知道如何操作，我有一个技能文件——一个代理在需要创建、列表或更新问题时会读取的指令文件。 这个文件有246行。其中约100行是合理的文档：存在哪些命令、有哪些团队、使用哪些标签。这是合理的。 其他150行是防御性垃圾。三个类别： 约30行硬编码的UUID。 我使用的CLI不支持--project。所以技能文件在XML表格中包含了17个UUID（5个团队+12个项目）。代理必须找到正确的UUID并手动构建GraphQL突变来分配项目。一个应该是--project Tokamak的操作需要记住一个36字符的UUID。 约25行对curl的回退。 CLI没有搜索功能。没有按项目过滤。创建时没有项目分配。三个基本操作，三个嵌入GraphQL查询的curl块，引号转义，以及认证头。每一个都是等待代理吃掉引号的定时炸弹。 约15行"不支持X"。 五个"CLI不支持"的警告和两个"必需"（每次列表时的–sort和–no-pager）。注意这点：我在工具使用指令中记录工具的缺陷。这就像汽车手册花三页解释雨刷只有在先敲击仪表板后才能工作。 约80行防御性上下文。 整整一节标题为"何时使用API而不是CLI"。目录→UUID映射表。选择标签的启发式方法。当CLI挂起时该怎么办的规则。这些材料存在的唯一原因是工具无能为力。 “小心台阶"的标志 当一个工具有不舒适的界面时，自然的反应是记录变通方法。你写指令。你放警告。你创建一个"常见错误"部分。文档越详细，你就越相信问题已经解决了。 但实际上没有。你放了一个"小心台阶"的标志，而不是修复台阶。 当那些指令的用户是LLM时，问题就成倍增加了。人类读到"不支持–project"会记住（多多少少）。LLM读到它，处理它，三轮对话后还是会使用--project。这不是因为它笨——而是因为它优化完成任务，而--project是分配项目的逻辑路径。禁令在信号的海洋中是噪音。 我在另一篇文章中写过这个问题：对LLM的冗长指令完全等同于放置标志。LLM忽略它们不是因为叛逆。它忽略它们是因为它的功能是找到最直接的路径，而"不要使用–project，而是在这个表格中查找UUID，然后用这个GraphQL查询做curl"不是直接路径——这是一个粗糙的修补。 解决方案不是更好的技能文件 我本可以用更好的指令重写技能文件。更清晰的。有例子的。有图表的。我本可以从246行增加到400行并覆盖每个边缘情况。 这就像扩大标志。 我所做的是构建lql——一个用Rust编写的CLI，专门设计让AI代理（或人类，但主要是代理）可以与Linear交互而不需要生存手册。 设计理念是一句话：错误的路径不应该被禁止，应该是不可能的。 换句话说：你不在文档中禁止--status——你让它工作。你不记录--project在create中不存在——你让它存在。你不维护UUID表格——你自动解析名称。你不提供curl回退——工具没有做不到的事情。你不写"必需：–sort”——你设置合理的默认值。 消失的东西 这是我删除的清单： 防御性垃圾 删除的行数 删除原因 硬编码的UUID（17个ID） ~30 lql自动解析名称 对curl + GraphQL的回退 ~25 lql原生支持search、project、relate “不支持X"的注释（5个） ~15 代理期望的一切都存在 “必需"标志（2个） ~5 合理的默认值，没有必需标志 “何时使用API vs CLI"部分 ~15 没有"vs”——lql什么都能做 上下文→UUID映射表（XML） ~20 从TOML配置自动检测 启发式和防御性规则 ~40 工具是容错的，多余了 总计 ~150 剩下的是合理的文档：存在哪些命令，有哪些团队，使用哪些标签。零变通方法。零道歉。 为什么有效（有趣的部分） 行数的减少很引人注目，但这不是重点。重点是_为什么_那些行是多余的。 旧技能文件中的每行变通方法都存在是因为底层工具是脆弱和不宽容的。脆弱是因为它在合理输入面前失败（--status而不是--state）。不宽容是因为它拒绝而不提供替代（--project不存在，自己想办法）。 当你用容错工具替换脆弱工具时，指令_自动_简化。你不必重写手册——手册自己重写，因为不再有什么需要警告的。 这是解释为什么iPhone手册有10页而打印机手册有200页的同一原理。不是苹果写更好的文档。而是iPhone不需要你解释如何装纸、对齐打印头或清洁滚筒。 容错工具生成简短文档。脆弱工具生成生存手册。 当用户是LLM时，这更加重要。每行指令都是可能被误解、遗忘或矛盾的一行。有150行变通方法的技能文件给它150个错误遵循变通方法的机会。没有变通方法的技能文件给它…零个出错的机会。 ...

他没有预料到的解雇 一名38岁的高级开发人员。在公司工作了八年。代码整洁，遵循最佳实践，生产环境零故障。 在最后一次绩效评估中，他的产出比经验只有他一半的同事低40%。区别在于：他们使用Copilot、Cursor和Claude Code。而他仍然坚持手写每一行代码，坚信"AI工具生成的代码质量平庸"。 他被解雇不是因为写了糟糕的代码。而是因为写好代码的速度太慢了。 这个故事并非例外。这就是新的模式。 你的经验是有保质期的 几十年来，经验一直是价值的代名词。更多年份意味着更多积累的知识，而这些知识会随着时间增值。一个有20年经验的专业人士，几乎理所当然地比有5年经验的更有价值。 这个等式已经被打破了。 根据IBM和世界经济论坛的数据，技术能力的半衰期已经从1990年的大约10年降到了2020年的不到5年。目前的估计显示，对于软件开发、数据和人工智能相关技能，这个数字已经低于3年。 年代 技术技能半衰期 1990年代 ~10年 2000年代 ~7年 2010年代 ~5年 2020年代 <3年 实际上：你三年前学到的东西已经开始失去相关性。你五年前掌握的可能已经完全过时了。 这不是你工作好坏的问题。这是物理定律：技术知识会贬值，而贬值的速度在加快。 你应该每年问自己的四个问题 职业淘汰不会提前通知。当你跨越"难以安置"的门槛时，没有警报会响起。人力资源部不会发邮件说"你的简历不再具有竞争力"。有一天你只是发现市场继续前进，而你还停留在原地。 这四个问题是你的早期预警系统。诚实地回答它们。你的职业生涯取决于此。 1. 我今天使用的技能中，哪些是三年前不存在的？ 如果你没有明确的答案，那就有问题了。因为你的竞争对手有。 当你在完善已知的技能时，其他人在学习AI代理、RAG架构，或者用Terraform部署基础设施。不是因为他们更聪明。而是因为当你在优化舒适区时，他们把时间投入到了不舒适的领域。 市场不奖励对稳定技术的精通。它奖励在技术成为必需品之前采用新兴技术的能力。 2. 我上次学习真正困难的东西是什么时候？ 舒适区是职业生涯的坟墓。 你每过一个月不学新东西，就有更年轻、更便宜的人在学习。你不是在与五年前的自己竞争。你在与刚完成LLM密集课程的初级开发人员竞争，他们掌握你甚至没试过的工具，而薪水只要你的一半。 你的经验只有在包含最近经验时才有价值。“我编程15年了"如果最近3年都在做同样的事情，那就毫无意义。 3. 我的公司是在投资我的培训，还是只是在消耗我的时间？ 有些公司明白持续培训是投资。还有些公司把专业人士当作电池：榨取能量直到耗尽，然后更换。 如果你多年来公司没有资助培训，没有分配学习时间，没有提供会议或发展资源的机会，你有两个问题。第一：这正是他们看待你的方式——一个要榨干的资源，而不是要发展的资产。第二：更新技能的账单你要自己付。用时间。用金钱。或者用你永远不知道失去的机会。 投资培训的公司留住人才。不投资的公司轮换员工，直到找到已经培训好的人。猜猜谁要承担这种轮换的成本。 4. 如果我今天申请我现在的工作，我能得到吗？ 这是最痛苦的练习。也正因如此，它是最重要的。 现在就打开LinkedIn。搜索你当前职位的职位，在你的行业，在你的城市。阅读五个职位的要求。不是"希望"的，而是必需的。 你全部满足吗？你掌握他们要求的技术吗？你在他们提到的工具方面有可证明的经验吗？你能在技术面试中回答相关问题吗？ 数一数你不满足多少要求。这个数字就是你的个人技术债务。就像所有债务一样，它会产生利息。每过一个月不偿还，它就会增长。直到有一天你发现市场无论如何都不再需要你了。 最小可行计划 保持更新需要时间。但比从淘汰中恢复需要的时间少。 任何技术专业人士的最小可行计划包括： 主动培训：每周2-4小时。 不是被动地阅读文章或看视频。刻意练习：有练习的课程、项目、能运行的代码。 每年一个认证或密集课程。 不是为了证书，而是为了过程。强迫自己以结构化方式学习新东西，保持主动学习的肌肉记忆。 每六个月用新技术做一个个人项目。 学习某样东西的最好方法就是用它构建东西。不必很大。但必须是真实的。 活跃的专业网络。 不是被动的LinkedIn。是讨论、分享、提问的社区。集体知识比任何官方课程移动得更快。 这大约占你工作时间的5-10%。这是一项重大投资，但替代方案——当为时已晚时发现自己已过时——代价要高得多。 这不是未来。这是现在。 有一种趋势是把这些变化当作"即将到来"的事情来谈论。好像我们有时间准备。 我们没有。变化已经发生了。 AI已经在改变招聘方式、工作方式和什么能力有价值。公司已经在优先考虑当前技能而不是历史资历。市场已经比以往任何时候都更严厉地惩罚过时。 将要繁荣发展的专业人士不一定是最有天赋的。他们将是那些永不停止学习的人。 大学教育给了你基础。持续培训决定这个基础是否仍然相关。 这不是可选的。这不是有时间时的奢侈品。这是指导你的职业生涯和让职业生涯碾压你之间的区别。 预测未来的最好方法就是创造未来。从你自己开始。