译：直接跟它说——Agentic Engineering 的简单直接之道

原文： https://steipete.me/posts/just-talk-to-it
作者： Peter Steinberger
译者： Gemini 2.5 Pro

最近我在这里不太活跃，因为我正埋头于我的最新项目。Agentic engineering 已经变得非常出色，现在它几乎编写了我 100% 的代码。然而，我看到很多人仍在试图解决问题时搞出各种花里胡哨的套路，而不是直接把事儿干成。

这篇文章的灵感，部分来自昨晚在伦敦的 Claude Code 匿名交流会上的对话，部分因为距离我上次更新工作流已经过去一整个 AI 年了。是时候复盘一下了。

所有基本理念依然适用，所以像上下文管理这类简单的事情我就不再赘述了。可以阅读我那篇《最佳 AI 开发工作流》作为入门。

背景与技术栈

我独自工作，目前的项目是一个大约 30 万行代码的 TypeScript React 应用，一个 Chrome 扩展，一个命令行工具 (cli)，一个用 Tauri 开发的客户端应用，还有一个用 Expo 开发的移动应用。我托管在 Vercel 上，一个 PR 大约能在 2 分钟内将新版本的网站部署好以供测试。其他所有东西（应用等）都没有自动化。

工具链与通用方法

我已经完全转向使用 codex cli 作为日常主力工具。我会在一个 3x3 的终端网格中同时运行 3 到 8 个 codex 实例，大部分都在同一个文件夹里，有些实验会放在单独的文件夹。我试过 worktrees、PRs，但最后总是回到这个设置，因为它干活最快。

我的智能体自己会进行 git 原子提交。为了保持一个基本干净的提交历史，我对我的智能体配置文件进行了大量迭代。这使得 git 操作更加精准，每个智能体都只提交它自己编辑过的文件。

是的，用 claude 你可以设置 hooks，codex 目前还不支持，但模型非常聪明，如果它们下定决心，没有什么 hook 能拦住它们。

过去我曾被嘲笑，被称为“垃圾代码生成器”，很高兴看到并行运行智能体正逐渐成为主流。

模型选择

我几乎所有东西都用中等设置的 gpt-5-codex 来构建。它在智能和速度之间取得了很好的平衡，并且能自动调整思考的深度。我发现过度思考这些设置并不会带来有意义的结果，而且不用去想什么 ultrathink 的感觉也挺好。

爆炸半径 💥

每当我工作时，我都会考虑“爆炸半径”。这个词不是我发明的，但我很喜欢它。当我构思一个变更时，我对于它会花费多长时间、会触及多少文件，都有一个很好的预感。我可以向我的代码库扔很多小炸弹，或者一颗“胖子”原子弹外加几颗小炸弹。如果你同时扔下多颗大炸弹，就不可能做到隔离提交，一旦出了问题，重置起来也会困难得多。

这也是我观察我的智能体时的一个很好的指标。如果某件事花费的时间比我预期的要长，我就会按下 escape 键，问一句“现在什么情况”来获取状态更新，然后要么帮助模型找到正确的方向，要么中止，要么继续。不要害怕中途打断模型，文件更改是原子性的，它们很擅长从中断的地方继续工作。

当我不确定影响范围时，我会用“在做改动前给我几个选项”来评估一下。

为什么不用 worktrees？

我只运行一个开发服务器，随着项目的演进，我会点击界面并一次性测试多个变更。如果每个变更都有一个 tree/branch，这会大大降低效率，启动多个开发服务器会很快变得烦人。而且我的 Twitter OAuth 也有一些限制，我只能注册几个域名用于回调。

Claude Code 怎么样？

我曾经很喜欢 Claude Code，但现在我再也受不了它了（尽管 codex 倒是它的粉丝）。它的语言风格，那些“完全正确”的口头禅，以及在测试失败时还声称“100% 生产就绪”的消息——我真的受够了。Codex 更像一个内向的工程师，默默地埋头苦干，把事情搞定。它在开始工作前会阅读更多的文件，所以即使是很短的 prompt，它通常也能准确地执行我的意图。

在我的时间线上，大家普遍认为 codex 才是正道之选。

codex 的其他优点

• 约 230k 的可用上下文 vs claude 的 156k。 是的，如果你运气好或者愿意付 API 的价格，有 Sonnet 的 100 万上下文。但现实是，Claude 远在耗尽上下文之前就会变得非常愚蠢，所以那并不是一个你真正能用上的东西。
• 更高效的 token 使用。 我不知道 OpenAI 做了什么不同的处理，但我的上下文填充速度比用 Claude Code 慢得多。以前用 claude 时我总是看到 “Compacting…”，而用 codex 我很少会超出上下文限制。
• 消息队列。 Codex 允许将消息加入队列。Claude 曾经有这个功能，但几个月前他们改了，让你的消息变成“引导”模型。如果我想引导 codex，我只需按下 escape 再按 enter 发送新消息。两种选择都有显然要好得多。我经常把相关的功能任务排入队列，它总能可靠地逐一完成。
• 速度。 OpenAI 用 Rust 重写了 codex，效果显而易见。它快得惊人。用 Claude Code 时，我经常遇到数秒的卡顿，而且它的进程会占用几个G的内存。还有终端闪烁的问题，尤其是在使用 Ghostty 的时候。Codex 完全没有这些问题。它感觉非常轻量和快速。
• 语言。 这对我的心理健康真的很重要。 我对 claude 大吼大叫过很多次。但我很少对 codex 生气。即使 codex 是个更差的模型，仅凭这一点我也会用它。如果你两种都用上几周，你就会明白。
• 不会到处都是随机的 markdown 文件。懂的都懂。

为什么不用某个特定的工具链

在我看来，最终用户和模型公司之间根本没有太多空间。通过订阅，我能得到目前为止最好的交易。我现在有 4 个 OpenAI 订阅和 1 个 Anthropic 订阅，所以我的总成本大约是每月 1000 美元，基本上可以无限使用 tokens。如果我用 API 调用，成本大约会高出 10 倍。别在这数学上跟我较真，我用了一些像 ccusage 这样的 token 计数工具，都有点不准，但即使只是 5 倍，那也是一笔非常划算的交易。

我很高兴有 amp 或 Factory 这样的工具，但我只是看不到它们能长期生存。codex 和 claude code 每个版本都在变得更好，它们都在朝着相同的理念和功能集趋同。有些工具可能会在更好的待办事项列表、引导功能或微小的开发者体验（dx）特性上拥有暂时的优势，但我认为它们无法在根本上超越那些大型 AI 公司。

amp 已经不再使用 GPT-5 作为驱动，现在称之为他们的“神谕”。而我呢，我用 codex，基本上一直在和那个更聪明的模型，也就是那个神谕，一起工作。是的，有一些基准测试，但考虑到使用数据的偏差，我并不相信它们。codex 给我的结果远比 amp 好。不过我必须为他们的会话分享功能点赞，他们确实在推进一些有趣的想法。

Factory，我持保留态度。他们的视频有点尬，不过我在时间线上确实听到了关于它的一些好评，尽管它（还）不支持图片，而且有那个标志性的闪烁问题。

Cursor… 如果你还在自己写代码，它的 Tab 补全模型是行业领先的。我主要用 VS Code，但我确实喜欢他们推进像浏览器自动化和计划模式这样的东西。我试过 GPT-5-Pro，但 Cursor 仍然有那些五月份就让我烦恼的 bug。不过我听说他们正在解决，所以它还留在我的 Dock 栏里。

其他像 Auggie 这样的工具，在我的时间线上只是昙花一现，之后就再也没人提起了。归根结底，它们都只是 GPT-5 和/或 Sonnet 的一层包装，都是可替代的。RAG 对 Sonnet 来说可能还有点用，但 GPT-5 的搜索能力太强了，你根本不需要为你的代码建立一个单独的向量索引。

最有希望的候选者是 opencode 和 crush，尤其是在与开源模型结合使用时。你完全也可以在它们上面使用你的 OpenAI 或 Anthropic 订阅（多亏了一些聪明的技巧），但这是否被允许还很难说，而且为一个已经为 codex 或 Claude Code 优化过的模型去使用一个能力较差的工具链，又有什么意义呢。

某个开源模型怎么样

我一直关注中国的开源模型，它们追赶的速度令人印象深刻。GLM 4.6 和 Kimi K2.1 是强有力的竞争者，正在慢慢接近 Sonnet 3.7 的质量，不过我还是不推荐它们作为日常主力。

基准测试只能说明一半问题。在我看来，agentic engineering 大约在五月份随着 Sonnet 4.0 的发布，从“这玩意是垃圾”变成了“这东西还不错”，而随着 gpt-5-codex 的出现，我们又实现了一次从“不错”到“太惊人了”的更大飞跃。

计划模式与方法

基准测试忽略的是，模型+工具链在收到 prompt 后所采取的策略。codex 要谨慎得多得多，它会在决定做什么之前阅读你仓库里更多的文件。当你提出一个愚蠢的请求时，它会更强硬地顶回去。 而 Claude/其他智能体则要急切得多，它们会直接去尝试做点什么。这个问题可以通过计划模式和严格的结构化文档来缓解，但在我看来，这感觉像是在为一个有问题的系统打补丁。

现在用 codex，我很少使用大型的计划文件了。codex 甚至没有一个专门的计划模式——然而它在遵循 prompt 方面做得好得多，我可以直接写“我们讨论一下”或“给我一些选项”，它就会耐心地等待我的批准。不需要工具链的花招。直接跟它说就行。

但 Claude Code 现在有插件了

你听到远处的声音了吗？那是我在叹气。真是一派胡言。这件事真的让我对 Anthropic 的专注点感到失望。他们试图为模型的低效之处打补丁。是的，为特定任务维护好的文档是个好主意。我自己在 docs 文件夹里就用 markdown 保存了一大堆有用的文档。

但是但是，子智能体！！！1！

但关于子智能体这套花样，还是得说几句。早在五月份，这东西还叫子任务，主要是在模型不需要全文的情况下，将任务分离到一个独立的上下文中——主要是为了并行化，或者为例如嘈杂的构建脚本减少上下文浪费。后来他们重新包装并改进为子智能体，这样你就可以用一些指令分拆出一个任务，包装得很漂亮。

用例是一样的。别人用子智能体做的事，我通常用单独的窗口来做。如果我想研究点什么，我可能会在一个单独的终端面板里做，然后把结果粘贴到另一个面板。这让我对我构建的上下文有完全的控制和可见性，而不像子智能体那样，让查看、引导或控制返回内容变得更加困难。

而且我们必须谈谈 Anthropic 在他们博客上推荐的那个子智能体。看看这个“AI 工程师”智能体。它就是一堆垃圾的混合体，提到了用于集成的 GPT-4o 和 o1，整体上就像一锅自动生成的、试图讲通道理的词语乱炖。里面没有任何实质内容能让你的智能体成为一个更好的“AI 工程师”。

那到底是什么意思？如果你想得到更好的输出，告诉你的模型“你是一个专注于生产级 LLM 应用的 AI 工程师”是没用的。给它文档、例子和该做/不该做的清单才有用。我敢打赌，如果你让你的智能体去“google AI agent 构建最佳实践”并加载一些网站，得到的结果都会比这堆垃圾好。你甚至可以说，这堆垃圾就是上下文毒药。

我如何写 prompts

以前用 claude 的时候，我习惯写（当然不是写，我是说出来）非常详尽的 prompts，因为我提供的上下文越多，这个模型就越“懂我”。虽然这对任何模型都适用，但我注意到用 codex 之后，我的 prompts 变得短了很多。通常只有一两句话，再加一张图片。这个模型在阅读代码库方面非常出色，一下子就能明白我的意思。我甚至有时会重新开始打字，因为 codex 需要的理解上下文少得多。

添加图片是提供更多上下文的一个绝佳技巧，模型非常擅长精确定位你展示的东西，它会找到字符串并进行匹配，直接到达你提到的地方。我可以说，我至少 50% 的 prompts 都包含一张截图。我很少在上面做标注，虽然那样效果更好但会慢一些。一张截图拖进终端只需要 2 秒钟。

带有语义校正功能的 Wispr Flow 依然是王道。

基于 Web 的智能体

最近我又试验了一些网页版智能体：Devin、Cursor 和 Codex。Google 的 Jules 看起来不错，但设置起来真的很烦人，而且 Gemini 2.5 已经不再是一个好模型了。一旦我们用上 Gemini 3 Pro，情况可能很快就会改变。唯一坚持用下来的是 codex web。它的设置也很烦人而且有问题，终端目前无法正常加载，但我用了一个旧版本的环境让它跑起来了，代价是启动时间变慢。

我把 codex web 当作我的短期问题追踪器。每当我在外面有想法时，我就会通过 iOS 应用发一条简短的指令，之后再在我的 Mac 上查看。当然，我可以用手机做更多事情，甚至审查和合并代码，但我选择不这么做。我的工作本身已经足够让人上瘾了，所以当我外出或见朋友时，我不想被进一步卷入。要知道，说这话的我可是花了近两个月时间构建了一个工具，只为让在手机上编码更容易的人。

Codex web 之前甚至不计入你的使用限额，但可惜这样的好日子屈指可数了。

智能体之旅

我们来谈谈工具。Conductor、Terragon、Sculptor 以及其他成千上百个工具。有些是个人项目，有些则淹没在风险投资的钱海里。我试过很多，没有一个能坚持用下去。在我看来，它们都在围绕当前的低效问题打补丁，并推广一种并非最佳的工作流。另外，它们中的大多数都隐藏了终端，不显示模型展示的所有内容。

大多数都只是 Anthropic SDK + work tree 管理的薄薄一层包装。没有护城河。而且我怀疑你是否真的想在手机上更方便地使用编码智能体。这些工具为我提供的有限用例，codex web 已经完全覆盖了。

不过我确实看到了这样一种模式，几乎每个工程师都会经历一个构建自己工具的阶段，主要是因为这很有趣，而且现在做起来也容易得多。除了构建那些（我们认为）能让构建更多工具变得更简单的工具，还能构建什么呢？

但 Claude Code 可以执行后台任务！

没错。codex 目前确实缺少一些 claude 拥有的花哨功能。最痛苦的缺失是后台任务管理。虽然它应该有超时设置，但我确实见过它好几次被不会结束的命令行任务卡住，比如启动一个开发服务器或者出现死锁的测试。

这是我曾经换回 claude 的原因之一，但由于那个模型在其他方面实在太蠢，我现在用 tmux。这是一个老工具，可以在后台的持久会话中运行命令行界面，而且模型中有大量关于它的世界知识，所以你只需要说“通过 tmux 运行”就行了。不需要自定义 agent.md 文件的花招。

MCPs 怎么样

其他人写了很多关于 MCPs 的文章。在我看来，大多数 MCPs 只是为了让市场部在功能列表上打个勾并引以为豪的东西。几乎所有的 MCPs 都应该做成命令行工具 (clis)。我是以一个自己写过 5 个 MCPs 的人的身份说这番话的。

我可以直接通过名字来引用一个 cli。我不需要在我的智能体配置文件里做任何解释。智能体在第一次调用时会随便试一下，cli 会显示帮助菜单，现在上下文中就有了关于它如何工作的全部信息，之后就没问题了。我不需要为任何工具付出代价，不像 MCPs，它们是持续的成本，是我上下文里的垃圾。用一下 GitHub 的 MCP，23k tokens 就没了。嘿，他们还算改进过了，因为它刚发布的时候几乎要用掉 50,000 tokens。或者你可以用 gh cli，功能集基本相同，模型已经知道怎么用它，而且上下文成本为零。

我开源了一些我的 cli 工具，比如 bslog 和 inngest。

我现在确实会用 chrome-devtools-mcp 来形成闭环。它取代了 Playwright，成为我进行网页调试的首选 MCP。我用得不多，但需要时，它对于形成闭环非常有用。我设计我的网站时，创建了 API 密钥，让我的模型可以通过 curl 查询任何端点，这在几乎所有用例中都更快、更节省 token，所以即使是那个 MCP，我也不是每天都需要。

但代码质量很差！

我大约花 20% 的时间在重构上。当然，所有这些都是由智能体完成的，我不会浪费时间手动去做。在我不太需要集中精力或者感到疲惫的时候，重构日就非常棒，因为我可以在不需要太多专注或清晰思考的情况下取得很大进展。

典型的重构工作包括：用 jscpd 查重，用 knip 找死代码，运行 eslint 的 react-compiler 和弃用插件，检查是否引入了可以合并的 API 路由，维护我的文档，拆分过大的文件，为复杂部分添加测试和代码注释，更新依赖，工具升级，文件结构重组，查找和重写慢速测试，提出并使用现代 React 模式重写代码（例如，你可能不需要 useEffect）。总有事情可做。

你可能会说，这些工作可以在每次提交时完成，但我发现，快速迭代，然后进入维护和改进代码库的阶段——基本上是偿还一些技术债，这种方式效率要高得多，总体上也更有趣。

你进行规范驱动开发吗？

我六月份的时候还这么干。设计一个大的规范，然后让模型去构建它，最好是花上几个小时。在我看来，那是构建软件的旧思维方式。

我现在的做法通常是，和 codex 开始一段讨论，我粘贴一些网站、一些想法，让它去读代码，然后我们一起把一个新功能具体化。如果遇到棘手的问题，我会让它把所有东西写成一个规范，然后交给 GPT-5-Pro (通过 chatgpt.com) 审查，看看它有没有更好的主意（出乎意料地，这经常能极大地改进我的计划！），然后我再把我认为有用的部分粘贴回主上下文中来更新文件。

现在，对于什么样的任务需要多少上下文，我已经有了很好的感觉，而且 codex 的上下文空间相当不错，所以我常常直接就开始构建了。有些人很固执，总是会带着计划在一个新的上下文中开始——在我看来，这对于 Sonnet 来说可能有用，但 GPT-5 在处理更大的上下文方面要好得多，而且那样做很容易给每件事都增加 10 分钟，因为模型必须重新慢慢获取构建功能所需的所有文件。

更有趣的方法是当我做基于界面的工作时。我常常从一些简单的事情开始，并且故意不把需求说清楚，然后看着模型构建，看着浏览器实时更新。然后我把额外的变更加入队列，对功能进行迭代。很多时候我并不完全知道某个东西应该是什么样子，通过这种方式，我可以把玩这个想法，不断迭代，看着它慢慢成形。我经常看到 codex 构建出一些我甚至没想到的有趣的东西。我不会重置，我只是简单地迭代，把混乱塑造成感觉对的形状。

在构建过程中，我常常会产生关于相关交互的想法，并同时在其他部分进行迭代，这部分工作我会在另一个智能体中进行。通常我会在一个主要功能和一些相关的次要任务上同时工作。

就在我写这篇文章的时候，我正在我的 Chrome 扩展中构建一个新的 Twitter 数据导入器，为此我正在重塑 graphql 导入器。由于我不太确定这是否是正确的方法，所以我把它放在一个单独的文件夹里，这样我就可以查看 PR，看看这个方法是否合理。主仓库正在进行重构，这样我就可以专注于写这篇文章了。

给我看看你的斜杠命令！

我只有几个，而且很少用：

• /commit （自定义文本，用来解释多个智能体在同一个文件夹工作，并让它只提交自己的更改，这样我能得到干净的注释，并且在 linter 失败时 gpt 不会因为其他更改而抓狂并试图回滚）
• /automerge （一次处理一个 PR，对机器人的评论做出反应，回复，让 CI 变绿，然后在变绿后 squash 合并）
• /massageprs （与 automerge 相同，但不进行 squash，这样当我有很多 PR 时可以并行处理）
• /review （内置命令，只偶尔用，因为我在 GH 上有审查机器人，但有时也挺有用）

即使有这些命令，我通常也只输入“commit”，除非我知道有太多未提交的文件，智能体没有一些指导可能会搞砸。当我有信心这样做就足够时，就不需要那些花招和上下文浪费。再说一次，你会对这些事情产生直觉。我还没见过其他真正有用的命令。

你还有其他什么技巧吗？

与其绞尽脑汁想一个完美的 prompt 来激励智能体继续执行一个长时间运行的任务，不如用一些懒人方法。如果你在做一个大的重构，codex 常常会在中途停下来回复。如果你想走开然后回来看到事情已经完成，那就把“继续”的消息排入队列。如果 codex 已经完成了任务，它收到更多的消息时，会愉快地忽略它们。

要求模型在每个功能/修复完成后编写测试。使用相同的上下文。这会产生好得多的测试，并且很可能发现你实现中的 bug。如果只是纯粹的界面调整，测试可能意义不大，但对于其他任何事情，都应该这样做。AI 通常不擅长写好测试，但它仍然有帮助，而且说实话——你为自己做的每个修复都写测试了吗？

要求模型保留你的意图并“在复杂部分添加代码注释”，这对你和未来的模型运行都有帮助。

当事情变得困难时，提示并添加一些触发词，比如“慢慢来”、“全面地”、“阅读所有可能相关的代码”、“建立可能的假设”，能让 codex 解决最棘手的问题。

你的 Agents/Claude 文件长什么样？

我有一个 Agents.md 文件，用符号链接指向 claude.md，因为 Anthropic 决定不进行标准化。我承认这很困难且不是最优解，因为 GPT-5 偏好的提示方式与 Claude 大不相同。如果你还没读过，现在就停下来去读一下他们的提示指南。

Claude 对🚨 全大写尖叫 🚨 的命令反应良好，比如威胁它如果运行 X 命令就意味着最终失败，会有 100 只小猫死掉，但这种方式会吓到 GPT-5。（理所当然）。所以，放弃所有这些，像个人一样说话。这也意味着这些文件无法被最佳地共享。这对我来说不是问题，因为我主要用 codex，并且接受在少数 claude 上场的情况下，这些指令可能太弱了。

我的 Agent 文件目前大约有 800 行长，感觉就像一堆组织留下的伤疤。不是我写的，是 codex 写的，每当发生什么事，我都会让它在里面做个简要记录。我应该在某个时候清理一下，但尽管它很大，却工作得非常好，而且 gpt 真的基本上会遵守里面的条目。至少，它遵守的频率比 Claude 高得多得多。（Sonnet 4.5 在这方面有所改进，得给他们点赞）

除了 git 指令，它还包含关于我的产品的解释、我偏好的通用命名和 API 模式、关于 React Compiler 的笔记——通常都是比世界知识更新的东西，因为我的技术栈相当前沿。我预计随着模型的更新，我可以再次减少里面的内容。例如，Sonnet 4.0 真的需要指导才能理解 Tailwind 4，而 Sonnet 4.5 和 GPT-5 更新，已经了解那个版本了，所以我可以删除所有那些废话。

重要的部分是关于我偏好的 React 模式、数据库迁移管理、测试、使用和编写 ast-grep 规则。（如果你不知道或不使用 ast-grep 作为代码库 linter，现在就停下来，让你的模型把它设置为一个 git hook 来阻止提交）

我还试验并开始使用一个基于文本的“设计系统”来规定东西应该是什么样子，对此还没有定论。

那么 GPT-5-Codex 是完美的吗？

绝对不是。有时它会重构半个小时，然后恐慌并撤销所有操作，你需要重新运行并像安抚孩子一样告诉它时间足够。有时它会忘记自己可以执行 bash 命令，需要一些鼓励。有时它会用俄语或韩语回复。有时这个怪物会失控，把原始的思考过程发送给 bash。 但总的来说，这些情况相当罕见，它在几乎所有其他方面都表现得太出色了，以至于我可以忽略这些瑕疵。人也不是完美的。

我对 codex 最大的不满是它会“丢失”行，快速向上滚动会导致部分文本消失。我真心希望这个问题在 OpenAI 的 bug 列表上排在首位，因为这是我有时不得不放慢速度的主要原因，为了不让消息消失。

结论

别在像 RAG、子智能体、Agents 2.0 或其他多半只是花招的东西上浪费时间了。直接跟它说。和它一起玩。培养直觉。你和智能体一起工作得越多，你得到的结果就会越好。

Simon Willison 的文章提出了一个极好的观点——管理智能体所需的许多技能，与你管理工程师时所需的技能相似——而这些几乎都是高级软件工程师的特质。

是的，编写好的软件依然很难。仅仅因为我不再写代码，不代表我不再深入思考架构、系统设计、依赖、功能或如何取悦用户。使用 AI 只是意味着，对于交付产品的期望提高了。

附：这篇文章是 100% 有机手写的。我热爱 AI，但我也承认有些事情用老派的方式做会更好。保留错别字，保留我的声音。🚄✌️

又及：头图的功劳归于 Thorsten Ball。