在Codex中,技能不是/命令(在Claude Code中几乎是)

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中分离的两个概念合并了: ...

2026年3月30日 · Fernando

Linear Agent 不是你需要的。你的代理早就在终端里

TL;DR: Linear 推出了一个集成的人工智能代理。听起来不错,但它并没有解决开发者在终端操作 coding agents 时的痛点。我们需要的不是另一个代理,而是一个可靠的 CLI,我们现有的代理可以直接调用。如果要重写,那就用 Rust——这就是 lql 的由来,一款专为 Linear 设计、面向代理的 CLI。 昨天,Linear 宣布了他们的人工智能代理。这是一个集成到应用中的聊天机器人,能够理解你的 roadmap,你的 issue 和你的代码。你可以在 Slack 上与它对话,在评论中@提到它,它会综合上下文,建议行动方案,甚至直接为你创建 issue。 听起来很棒。真的,很棒。 尽管如此,当我读到这个公告时,我的第一反应是:“这不是我需要的东西。” Linear 的大冒险 为了让你明白我的意思,我需要先讲讲背景。我和 Linear 的关系就像一部委内瑞拉肥皂剧一样,是一段充满了爱恨交织的故事。 第一幕:MCP 服务器。 Linear 曾经有一个 MCP 服务器,供人工智能代理与其交互使用。它的表现就像是在飓风里点打火机:技术上是能点着火,但火焰从来维持不到两秒。断断续续、缓慢,偏偏总是在关键时刻掉链子。最终我直接把它卸载了。 第二幕:GraphQL API。 于是唯有通过 GraphQL 直接和 Linear 沟通。没错,它确实能用,直到你需要在某个 issue 的描述中加入特殊字符,结果这些字符的转义问题会让你重新思考自己的整个人生。某一次,我花的时间转义一个括号比写 issue 所描述的代码还要长。 第三幕:Linear CLI。 然后 linear CLI 出现了,这是一个由社区开发的项目。brew install schpet/tap/linear 然后直接运行。一个第三方工具,朴素、不显眼,但正是我需要的工具:能够直接在终端创建、列出并更新 issue,而不需要与 GraphQL 或那个让人发疯的 MCP 作斗争,也没有弹窗干扰。 我甚至专门写了一篇文章 讲述自己如何用这个 CLI 解放了工作流。一个简单的 bash 脚本帮我在不到一分钟内创建了 49 个 issue。如果用 MCP,我可能会花上一个半小时。 进入代理 现在 Linear 推出了他们的代理。这款产品承诺:一个可以理解你的工作空间、与你的代码连接并自动化你的工作流程的集成助手。 ...

2026年3月25日 · Fernando

我的配置:Claude Code + Ghostty + worktrees 在 Mac 上的极致实践

我现在有三个运行中的 Claude Code 会话。一个在翻译博客文章,另一个在为 CLI 编写测试,还有一个在帮我调试数据流水线。每个会话都运行在独立的 worktree 中,每个会话都开启在 Ghostty 的一个 split 里,而我则通过 Cmd+Alt+方向键 在它们之间快速切换。 我几个月没打开过 iTerm2,几个星期没用过 tmux。现在几乎所有工作都集中在 Ghostty 的一个窗口里。 它是完美的配置吗?当然不是。但它是迄今为止让我最高效的配置?毫无疑问。 为什么选择 Ghostty,而不是别的终端? 一句话总结:Ghostty 和挖矿一样耗电。我详细讲过 GPU终端和电量消耗问题,这一问题并没有改善,这依然是它最大的缺点。如果我用的是电池,我会果断关掉 Ghostty,转而使用 Terminal.app。 但每当电脑插电源时——我80%的时间都会坐在 Studio Display 前的桌子上工作——Ghostty 赢下这场比赛的两个原因与外观美化完全无关: 1. 没有闪屏。 听起来没什么,但当你每天对着终端屏幕盯八个小时时,就完全不一样了。iTerm2 在快速滚动时会有轻微的闪屏;调整窗口大小时会出现显示滞后;切换标签页时会有轻微的画面闪烁。Terminal.app 这些问题更严重。而由于 Ghostty使用 GPU 渲染,它提供的视觉流畅度绝对不会让人眼睛疲劳。当 Claude Code 输出200多行日志时,你滑动查看有哪些问题时,一款没有闪屏的终端和一款有闪屏的终端,体验可以说完全不可同日而语。 2. 支持超大缓存。 我设置了 scrollback-limit = 50000,即每个终端窗口有 50,000 行历史记录。Claude Code 输出日志时非常详细:生成代码、解释代码、运行代码、显示结果,偶尔还会附上一堆自言自语式的冗长分析。对于 iTerm2 或 Terminal.app 默认有限的缓冲区来说,这种频率的日志输出很容易就会丢失早期的上下文。而在 Ghostty 中,我可以随心所欲地向上滚动,甚至找到两小时前的操作记录,非常可靠。 除此之外,它还支持默认分屏(通过按 Cmd+D 快速创建),内建下拉式 Quake 风格终端(`Ctrl+``),但这些只是锦上添花。无闪屏、不丢日志历史才是它的两大核心亮点。 我的工作窗口布局 当我需要同时处理多个独立任务时,我的 Ghostty 窗口通常如下: ┌──────────────────────────────────┬──────────────────────────────────┐ │ │ │ │ Claude Code (worktree A) │ Claude Code (worktree B) │ │ feature/nueva-validacion │ chore/traducciones │ │ │ │ │ │ │ ├──────────────────────────────────┴──────────────────────────────────┤ │ │ │ 主仓库(main)—— 测试、构建、git log │ │ │ └─────────────────────────────────────────────────────────────────────┘ 上方两个 splits,每个运行一个 worktree 和对应的代理。下方是 main 仓库,用于运行测试、查看变更和在代理完成任务后进行合并。 ...

2026年3月11日 · Fernando

Codex CLI 没有 worktrees(教你手动实现!)

如果你读过我之前写的 关于 Claude Code 中 worktrees 的文章,你应该知道这个功能的核心就是一个小小的参数:--worktree。执行这个参数之后,每个代理都能在一个隔离的代码仓库副本中运行。每次启动一个代理程序,就在独立的目录中操作。三个代理同时跑也互不干扰,仿佛魔术一般。 现在打开 Codex CLI,想找一下等效的参数,结果发现它根本不存在。 没有 --worktree。没有 --tmux。也没有支持自定义代理的 isolation: worktree 参数。而且,尽管issue #12862 在 GitHub 上已经开了很久,并且已经有人在 fork 中实现了这些功能,但官方始终没有合并代码。到目前为止,Codex CLI 还是无法原生支持多个代理并行操作。 这是否意味着无法使用 Codex 实现并行工作?答案是否定的。这只是意味着你需要自己动手 “折腾” 一下。而这件事说穿了,不过是几个 git 命令和一些预防措施。 计划:手动 worktrees + 每个目录运行一个 Codex 整体思路跟 Claude Code 中的方法类似,只是没有自动化功能。简单来说,就是你自己创建 worktree,自己启动代理程序,事情完了也需要自己清理。这工作听上去有点人工,但它确实管用。 # 从你的主仓库目录开始 cd ~/code/mi-proyecto # 为每个任务创建一个 worktree git worktree add ../mi-proyecto-feat-auth -b feature/auth git worktree add ../mi-proyecto-fix-tests -b fix/tests-rotos git worktree add ../mi-proyecto-refactor -b chore/refactor-db --- 现在你有四个目录:一个主目录和三个 worktree,每个 worktree 都是相互独立的。每个 worktree 拥有自己的分支、暂存区 (*staging area*) 和 HEAD,但共享仓库的元数据(`.git/` 目录),其他一切隔离。 接下来,在每个 worktree 运行一个 Codex: ```bash # 终端 1 cd ../mi-proyecto-feat-auth codex --approval-mode never --sandbox workspace-write \ "实现 JWT 鉴权中间件,编写测试代码。" # 终端 2 cd ../mi-proyecto-fix-tests codex --approval-mode never --sandbox workspace-write \ "运行测试套件,修复所有失败的测试,一直重复直到全部通过。" # 终端 3 cd ../mi-proyecto-refactor codex --approval-mode never --sandbox workspace-write \ "重构数据库模块以使用连接池功能。" 三个代理,三个任务,它们互不干扰。每个 Codex 只看到自己对应的 worktree,并且只操作相应的分支。 ...

2026年3月11日 · Fernando

我再次宣布邮件破产,这次我有计划了

2004年,劳伦斯·莱西格(Lawrence Lessig)给他的所有联系人发了一封群发邮件,大意是:“抱歉,我把你们所有的邮件都删了。如果有什么重要的事情,请再发一次。” 当时,他已经花了整整80个小时清空从2002年积累下来的收件箱。他每天收到200封邮件。 莱西格并不是个不善管理的人——他是斯坦福大学法律学院的教授。然而,即便如此,他仍然败给了电子邮件。 我至少宣布过三次邮件破产。第一次让我感到如释重负。第二次让我觉得自己很狼狈。第三次让我意识到问题根本不在我自己。 电子邮件是一个任何人都可以填满的收件箱 好好想想。你的收件箱是一个地球上任何人都可以随意修改的任务列表。你的老板、你的银行、你四年前在某次会议上认识的一个人、你醉酒时订阅的某个电子邮件新闻简报,还有Jira的一个机器人提醒你某人刚刚把一个任务从“待处理”挪到了“进行中”。 所有人都可以往你的任务列表里塞东西。没有人会问你是否有时间。 就好像你把家门敞开,门口挂个牌子写着“想让我干什么就放这儿吧”。然后你还会惊讶地发现门口堆满了包裹。 被过度滥用的工具 电子邮件的发明初衷是用来传递消息的。一条消息。从一个点到另一个点。就像信件,只是更快罢了。到这一步,一切都好。 但问题是,人类把它变成了什么: 电子邮件本来的用途 我们把它变成了什么 一个消息传递系统 一个任务列表 异步通信 “你有没有看到我5分钟前发给你的邮件?” 点对点沟通 抄送47个人,“以防万一” 纯文本邮件 带有追踪像素和动态GIF的HTML邮件 沟通工具 CRM、文件管理器和法律档案库的集合 用通俗点的话说:我们拿了一把锤子,却把它当成螺丝刀、黄油刀和开瓶器来用。然后又抱怨它的把手坏了。 混乱的数字 加州大学尔湾分校的一项研究发现,我们在被严重打扰后需要花23分钟15秒才能重新集中注意力。而普通员工平均每小时检查电子邮件36次。也就是说,每小时就可能有36次干扰。 算一算账:如果你每次查看电子邮件都会损失2分钟的工作状态转换时间,那你每天仅仅因为查看新邮件,就可能浪费超过1小时。不是为了阅读邮件,也不是为了回复邮件,仅仅是切换注意力。 这就像是每100米就突然猛转方向盘。这确实可以前进,但却是耗费了双倍的油,同时精疲力尽。 邮件破产行不通(你也知道) 每次我宣布电子邮件破产时,循环总是一样的: 第一周: 收件箱变为空,无比平静,精神得以解脱。“这次我一定行。” 第二周: 收件箱里有47封未读邮件。“我一会儿再看。” 第三周: 收件箱有200封邮件。一些很重要。我开始眯着眼扫主题。 第四周: 500封邮件。我已经不知道哪些看过哪些没看。焦虑突升。 第三个月: 又宣布破产。 问题不是你不够有条理。问题在于,把电子邮件当作任务管理和提醒系统是结构性地站不住脚的。这个系统既没有优先级,也没有截止日期,更没有状态变化。它无法区分“有空再看”和“今天不回复你就丢了大单”。 一切内容都会以相同的形式,通过同一个入口,排成一条以“最近有人联系你”为顺序的无限列表。这不是什么生产力系统。这是一个时间消耗的垃圾场。 更好的解决方案并不是更好地管理 email 我尝试过各种方法。Gmail的过滤器。像地铁线路图一样的颜色编码标签。邮件“稍后提醒”。文件夹命名为“今天要回复”“这一周要处理”“闲时阅读”(剧透一下:所谓的“闲时”从来不会来)。我还用过FollowUpThen,你可以把一封邮件转发到3days@followupthen.com,然后它会在3天后把邮件发回你的收件箱。 你知道用FollowUpThen后会发生什么吗?那就是:现在你的收件箱里不仅有原始邮件,还有提醒邮件。解决邮件过量问题的方法,反而制造了更多邮件。这就像想用汽油灭火一样。 真正的解决方法是:将提醒和跟进行动从邮件里完全分离出来。 没有模棱两可,只能彻底剥离。 Memento:虽无趣却有效的解决方法 我的第一个解决方案叫做Memento。它不是一个带漂亮界面和订阅计划的应用程序。它是一个只有120行代码的Python脚本,用来查询Linear(我的任务管理工具),告诉我有哪些事项超出了截止日期。 # GraphQL 查询:筛选出过期但未完成或取消的任务 issues(filter: { dueDate: { lte: "2026-03-11" }, state: { type: { nin: ["completed", "canceled"] } } }) --- 就是这样了。一段简单的查询字符串:**“有哪些我本该做但却没做的事情?”** 我用终端运行这个命令来查看: ```bash uv run memento 然后就会显示类似这样的内容: ...

2026年3月11日 · Fernando