编者按： 当 AI 编程智能体宣称能自动化一切时，我们是否在工具与概念的丛林中迷失了方向，反而忘记了如何最简单、直接地解决问题？

本文的核心主张尖锐而明确：与其追逐繁杂的“智能体套件”、子智能体（Subagents）、RAG 等概念，不如回归本质 —— 选择一个强大且高效的模型，像与一位靠谱的工程师同事那样，通过简洁的对话和直觉性的协作来直接解决问题。作者直言不讳地批评了当前生态中许多“华而不实”的工具，认为它们不过是绕开模型本身低效的临时补丁，并分享了他如何用多个终端窗口和经典工具（如 tmux）实现比许多专用工具更灵活、更可控的工作流。

本文系原作者观点，Baihai IDP 仅进行编译分享

作者 | Peter Steinberger

编译 | 岳扬

最近我没怎么在社交平台上活跃，因为我正全身心投入到最新的项目中。如今，智能体工程（Agentic engineering）已经变得非常强大，几乎能编写出我需要的 100% 的代码。然而，我却看到很多人还在费力解决本不该存在的问题，搞出一堆繁复的表演，而不是专注把事搞定。

这篇文章的部分灵感来自最近在伦敦参加的“Claude Code Anonymous”活动[1]上的对话，另一部分则是因为距离我上次更新工作流已经整整一年（还是 AI 年[2]😏）。是时候做个回顾了。

所有基础理念依然适用，像上下文管理这类简单内容本文不再赘述。想了解基础内容，请阅读我之前写的《Optimal AI Workflow》[3]一文。

01 我的工作背景与技术栈

我是一名独立开发者，当前开发的项目是一个约 30 万行代码的 TypeScript React 应用，外加一个 Chrome 扩展、一个 CLI 工具、一个基于 Tauri 的客户端应用，以及一个使用 Expo 的移动应用。网站托管在 Vercel 上，每次 PR 后大约两分钟就能测试新版本，其他应用尚未实现自动化部署。

02 我所使用的技术工具和处理开发任务的总体思路

我已完全改用 codex cli 作为主力工具。通常我会在一个 3x3 的终端网格中同时运行 3 到 8 个实例，它们大多位于同一目录[4]，部分实验性任务则会放在独立文件夹中。我尝试过 worktrees、PR 等方式，但总会回到当前这套配置，因为它能最快地把事情做完。

我的智能体（agents）会自行执行原子化的 Git commits[5]。为了保持相对干净的 commit 历史，我在 agent 配置文件[6]上反复迭代优化。这样一来，Git 操作更精准，每个智能体只提交它实际修改过的文件。

是的，用 Claude 你可以设置 hooks（译者注：可能是 git commit hook），而 codex 目前还不支持 hooks，但大模型极其聪明 —— 一旦它们下定决心，没有任何 hook 能拦得住[7]。

过去我曾因此被嘲讽为垃圾代码制造机[8]，如今看到并行运行智能体的做法逐渐成为主流[9]，深感欣慰。

03 模型选择

我几乎所有的开发工作都交由 gpt-5-codex 在“medium 配置”下完成。它在智能程度与速度之间取得了极佳的平衡，还能自动调节思考深度。我发觉过度纠结这些设置并无明显的回报，而且不用操心“超深度思考”（ultrathink）的感觉真的很轻松。

3.1 爆炸半径 💥

每次工作时，我都会考量“爆炸半径” —— 这个词不是我发明的，但我非常喜欢。当构思某个改动时，我基本能预判其耗时及波及的文件范围。我可以向代码库投掷多枚“小手雷”，或是一发“胖子”配几颗小炸弹。但如果你同时扔下多个大炸弹，就几乎不可能做出隔离良好的提交，一旦出错也更难回滚。

这同时也是我观察智能体运行时的一个重要指标。如果某项任务耗时超出预期，我会直接按 Esc，然后问一句“当前状态如何？”来获取任务进度，再决定是帮模型调整方向、中止任务，还是继续执行。别害怕在中途打断模型 —— 文件修改是原子性的，它们非常擅长接续未完成的工作。

当我对改动的影响不确定时，会先让模型“在修改前给我几个选项”，以此评估影响范围。

3.2 为何不用 Worktree？

我始终只运行一个开发服务器。在迭代项目时，我会通过实时操作界面，一次性测试多处改动。如果为每个功能变更都创建独立的工作树（worktree）或分支（branch），会严重拖慢我的测试流程。而同时启动多个开发服务器又会带来不必要的操作负担。此外，我的项目受 Twitter OAuth 规则限制，只能注册有限数量的回调域名，这从客观上也不支持多环境并行的开发方式。

3.3 那 Claude Code 呢？

我曾经很喜欢 Claude Code，但如今实在受不了了（即便 codex 对其赞誉有加[10]）。那种语言风格、那种斩钉截铁的“绝对正确”[11]、那种测试明明失败却宣称“100%满足生产要求”的语气——实在令人无法继续。相比之下，codex 更像是那个内向但靠谱的工程师：默默推进，把事情做完。它在开始工作前会读取更多文件，因此即使是简短的提示词，通常也能精准实现我想要的效果。

在我关注的信息流中，大家已普遍认为 codex 才是当前的首选[12-13]。

3.4 codex 的其他优势

• 约 23 万的可用上下文（context），而 Claude 只有 15.6 万。 是的，如果你运气好或愿意按 API 定价付费，Sonnet 确实有 100 万上下文，但现实中 Claude 在耗尽上下文之前就已经开始胡言乱语了，所以这个超长上下文实际上并不可用。
• 更高的 token 利用效率。 我不知道 OpenAI 做了什么不同处理，但我的上下文空间在 codex 中消耗得明显更慢。用 Claude 时我经常看到 “Compacting…” 提示，而在 Codex 中我极少触及上下文上限。
• 消息队列（Message Queuing）。 Codex 支持消息排队[14]。Claude 以前也有这功能，但几个月前改成了“消息会实时引导模型”的机制。如果我想引导 codex，只需按 Esc 再回车就能发送新消息。能同时选择“排队”或“即时干预”显然更好。我经常一次性将多个相关功能任务放入队列，它总能可靠地逐个完成。
• 速度。OpenAI 用 Rust 重写了 codex，效果立竿见影 —— 响应速度快得惊人。 而用 Claude Code 时，我经常遇到数秒的卡顿，内存占用动辄飙到几个 GB。还有终端显示的闪烁问题，尤其是在用 Ghostty 时。Codex 完全没有这些问题，感觉极其轻量、流畅。
• 语言风格。 这点对我的心理健康真的很重要[15]。我曾无数次对 Claude 大吼大叫，但很少对 codex 发火。哪怕 codex 模型能力稍弱，光凭这一点我也愿意用它。只要你两个都用上几周，就懂我在说什么。
• 不会到处乱生成 markdown 文件[16]。懂的都懂（IYKYK）[17]。

3.5 为何不选用其他开发工具

在我看来，终端用户和大模型公司之间其实没有太多中间空间。我目前通过订阅获得的性价比远高于其他方式。我现在有 4 个 OpenAI 订阅和 1 个 Anthropic 订阅，每月总花费大约 1000 美元，基本可以享受“无限 token”的使用体验。如果改用 API 调用，成本大概会高出 10 倍。别太较真这个数字——我用过像 ccusage 这样的 token 统计工具，数据多少有些不精确，但即便只是五倍，也已是相当划算的交易了。

我很欣赏像 amp 或 Factory 这样的工具，但我不认为它们能长期存活。无论是 codex 还是 Claude Code，每个版本都在变得更强，而且功能理念正在快速趋同。某些工具可能在待办列表、引导控制或细微的开发者体验（DX）上暂时领先，但我不觉得它们能真正超越大型 AI 公司。

amp 已经不再以 GPT-5 为核心驱动，转而称其为“Oracle”（神谕）[18]。而我直接使用 codex，本质上就是一直在和那个更聪明的模型——也就是“Oracle”——打交道。是的，有各种基准测试[19]，但考虑到使用场景的巨大不同，我不太信任那些结果。实际体验中，codex 给我的输出远优于 amp。不过我得承认，他们在会话共享方面确实做了些有趣的创新。

Factory？我还没被说服。他们的演示视频有点尴尬，虽然我在信息流里确实听到一些正面评价 —— 尽管目前还不支持图像（至少现在还不行），而且也有标志性的闪烁问题[20]。

Cursor……如果你还在亲手写代码，那它的 Tab 补全模型确实是业界领先。我主要用 VS Code，但确实欣赏他们在浏览器自动化和计划模式（plan mode）等方面的探索。我试过 GPT-5-Pro，但 Cursor 依然存在那些从五月起就让我烦躁的 bug[21]。听说他们正在修复，所以它还留在我的程序坞里。

像 Auggie 这样的工具，只在我的信息流上昙花一现，之后就再没人提过。归根结底，它们底层无非是封装了 GPT-5 和/或 Sonnet，完全可以被替代。RAG 对 Sonnet 或许有点用，但 GPT-5 本身在代码检索上已经强到根本不需要额外的向量索引。

目前最有希望的是 opencode 和 crush，尤其是搭配开源模型使用时。你当然也能通过它们使用 OpenAI 或 Anthropic 的订阅（得益于一些巧妙的技术手段[22]），但这是否合规仍存疑，况且为何要为一个专为 Codex 或 Claude Code 优化的模型，配上一个能力较弱的“外壳”呢。

3.6 关于开源模型

基准测试只能说明一半的问题。在我看来，智能体工程（agentic engineering）大约在 Sonnet 4.0 发布的五月，才真正从“这玩意儿真烂”迈入“这还不错”的阶段；而随着 gpt-5-codex 的出现，我们又迎来了一次更大的进步 —— 从“不错”直接进入“这简直太棒了”的境界。

3.7 计划模式（Plan Mode）与方法

基准测试所忽略的，是模型与工具在接到指令后所采取的策略。codex 要谨慎得多 —— 它会在决定行动前读取你代码库中更多的文件。当你提出一个荒谬请求时，它也更倾向于明确反对[23]。相比之下，Claude 或其他智能体会更急切地直接动手尝试。虽然可以通过“计划模式”（plan mode）和严谨的结构化文档来缓解这个问题，但对我而言，这感觉像是在给一个有缺陷的系统打补丁。

如今我几乎不再为 codex 使用大型的计划文件。其实 codex 甚至没有专门的计划模式（plan mode） —— 但它对提示词的理解和遵循能力实在太强，我只要写一句“我们先讨论一下”或“给我几个选项”，它就会耐心等待我确认后再行动。完全不需要那些花里胡哨的东西，直接跟它对话就行。

3.8 但 Claude Code 现在有插件了

你听见远处那声叹息了吗？那是我在叹气。这真是彻头彻尾的胡扯。Anthropic 的这一举动让我对他们的产品方向感到非常失望。他们试图用插件[24]来掩盖模型本身的低效。当然，为特定任务维护优质文档是个好主意 —— 我自己就在一个 docs 文件夹里存了大量有用的 Markdown 文档。

3.9 但是！子智能体呢

但关于这场“子智能体”（subagents）的盛宴，我有些话不吐不快。今年五月时，这还叫“子任务”（subtasks），主要是当模型不需要完整上下文时，把任务拆出去单独处理——比如并行执行，或避免把冗长的构建脚本塞进主上下文造成浪费。后来他们重新包装并升级为“子智能体”，让你可以带着指令“优雅地”打包并分派任务。

但使用场景本质上没变。别人用子智能体干的事，我通常用多个终端窗口就搞定了。 如果我想调研某个问题，可能会在一个终端窗格里操作，再把结果粘贴到另一个窗格。这种方式让我对上下文工程拥有完全的控制权和可见性，而子智能体反而让上下文变得难以查看、引导或控制。

还有 Anthropic 博客里推荐的那个子智能体 —— 你去看看他们那个所谓的“AI Engineer”智能体[25]。那简直就是一锅大杂烩：一边吹集成了 GPT-4o 和 o1，一边堆砌一堆自动生成的空洞词汇，试图显得有逻辑。里面根本没有能让智能体真正变成更好“AI 工程师”的实质内容。

这到底有什么用？如果你希望获得更好的输出，光告诉模型“你是一位专精于生产级 LLM 应用的 AI 工程师”是没用的。真正有用的是提供文档、示例，以及明确的“该做什么/不该做什么”。 我敢打赌，你让智能体去“搜索 AI 智能体构建的最佳实践”并加载几个网页，效果都比那堆废话强得多。你甚至可以说，这种胡扯本身就是一种上下文污染（context poison）[26]。

04 我的提示词撰写之道

以前用 Claude 时，我（当然不是手打，而是靠语音）会写非常详尽的提示词，因为那个模型“给越多上下文，越懂我”。虽然所有模型多少都这样，但我发现换用 codex 后，提示词明显变短了 —— 常常就一两句话，外加一张图。这个模型读代码库的能力极强，就是能精准理解我的意图。有时候我甚至又愿意打字了，因为 codex 根本不需要太多上下文就能明白。

添加图片是个绝妙的技巧，能快速补充上下文。 模型非常擅长精准定位你截图中的内容 —— 无论是字符串还是界面元素，它都能迅速匹配并跳转到你提到的位置。我至少有一半的提示词都包含截图，虽然添加标注效果更佳但效率更低，而直接拖拽截图到终端仅需两秒。

带语义纠错的 Wispr Flow[27] 仍是当前最优方案。

05 Web 端智能体新体验

最近我又重新尝试了一些 Web 端智能体：Devin、Cursor 和 Codex。Google 的 Jules 界面美观，但配置流程繁琐，且 Gemini 2.5 现在已经算不上好模型了。不过一旦 Gemini 3 Pro 上线[28]，情况或许会有所转变。目前唯一留下来的只有 codex web。虽然它也存在配置复杂的问题，而且现在还有 Bug（终端目前就无法正确加载），但我靠一个旧版环境让它跑起来了，代价是启动速度更慢。

我把 codex web 当作临时的问题追踪器。在外突发灵感时，就用 iOS App 发一条一行字的提词词，回头在 Mac 上再仔细处理。当然，我完全可以在手机上做更多事，比如审查、合并代码，但我刻意保持克制。我的工作已经够让人上瘾了，所以当我出门或和朋友聚会时，不想被进一步拉回工作状态。说这话的人，可是曾花将近两个月专门开发了一款便于使用手机编程的工具啊。

codex web 上的任务原本不计入使用额度，可惜这样的好日子恐怕快到头了。

06 The Agentic Journey

聊聊那些工具吧：Conductor[29]、Terragon[30]、Sculptor[31] 等数以千计的同类产品。有些是个人爱好项目，有些则被 VC 投来的钱淹得喘不过气。我试过太多太多，没一个能让我长期用下去。在我看来，它们都是在绕开当前模型的低效，推行一种并不真正高效的工作流。而且大多数还藏起终端，不让你看到模型的全部输出。

绝大多数不过是 Anthropic SDK 的浅层封装 + 工作树管理，毫无技术护城河可言。我甚至怀疑：我们真的需要在手机上更方便地调用编程智能体吗？这些工具的有限应用场景，现在 codex web 已经完全覆盖了。

不过我确实观察到一个普遍现象：几乎每个工程师都会经历一个“自己造工具”的阶段 —— 主要是因为好玩，也因为现在做这件事确实太容易了。既然如此，还有什么比造一个“（我们以为）能让造工具变得更简单的工具”更自然呢？

07 但 Claude Code 能处理后台任务！

确实如此。codex 目前缺少一些 Claude 有的小功能，其中最让人头疼的就是后台任务管理。 虽然理论上应该有超时机制，但我确实多次遇到它卡在不会自动结束的 CLI 任务上，比如启动开发服务器，或者死锁的测试。

这曾是我一度切回 Claude 的原因之一。但鉴于那个模型在其他方面实在太不靠谱，我现在改用 tmux。tmux 是一个老牌工具，能在后台持久化运行 CLI 会话，而且模型里早就内置了大量相关知识 —— 你只需要说一句“用 tmux 运行”，就能搞定，无需任何复杂的智能体配置流程。

08 那 MCPs 呢？

关于 MCP（Model Context Protocol），其他人已经写了很多。在我看来，大多数 MCP 本质都只是市场部门用来打勾炫耀的工具。几乎所有 MCP 其实都应该做成 CLI。这话出自一个自己写过 5 个 MCP[32] 的人之口。

我可以直接按工具名字调用一个 CLI，根本不需要在 agent 配置文件里写任何说明。模型第一次调用时可能会试一些乱七八糟的命令（$randomcrap），CLI 会自动返回帮助菜单，上下文立刻就拥有了完整的使用信息 —— 从此一切顺利。我不用为任何工具付出额外代价，而 MCP 却是持续的成本，还会污染我的上下文。试试 GitHub 的 MCP，瞬间吃掉 23k tokens。好吧，他们后来优化了 —— 刚上线时可是接近 5 万 tokens！换成 gh CLI 呢？功能基本一样，模型本来就认识它，还完全不用交“上下文税”。

我自己开源了一些 CLI 工具，比如 bslog[33] 和 inngest[34]。

我现在确实在用 chrome-devtools-mcp[35] 这个工具来做最终验证[36]，它已经取代了 Playwright，成为我进行网页调试时的首选 MCP 工具。虽然我不常用它，但一旦需要，它就能帮我完成从“代码修改”到“验证结果”这个关键闭环，非常有用。我还专门设计了我的网站，让模型能通过 curl 查询任意接口（通过我生成的 API key）——这在几乎所有场景下都比 MCP 更快、更省 token。所以就连这个 MCP，我也不是每天都需要。

09 但生成的代码太糟糕了！

我约 20% 的时间[37]投入在重构上。当然，这些全由智能体完成，我绝不会手动浪费时间干这种事。当我不太需要高度专注或感到疲惫时，“重构日”就特别有用 —— 即使状态一般，也能取得显著进展。

典型的重构工作包括：用 jscpd 找重复代码，用 knip[38] 清理死代码，运行 eslint 的 react-compiler 和弃用插件（译者注：一类 ESLint 插件，用于检查代码中是否使用了已过时的 API、方法或特性，并提示你改用现代、推荐的替代方案。），检查是否有可合并的 API 路由，更新文档，拆分过大的文件，为复杂逻辑补充测试和注释，更新依赖项，升级工具链，调整目录结构，找出并重写慢测试，引入现代 React 模式（比如你可能根本不需要 useEffect）等等。总有做不完的事。

有人可能会说这些应该在每次提交时就做完。但我发现，先快速迭代、再集中维护和优化代码库——即阶段性偿还技术债务——这种方式不仅效率更高，而且整体上有趣得多。

10 你采用规范驱动开发（spec-driven development）吗？

我去年六月还在用这种方式：先写一份详尽的规格文档，然后让模型去实现，理想情况下能连续跑上好几个小时。但现在我觉得，这种“先设计后构建”的思路已经是过时的软件开发范式了。

我现在的做法通常是：先直接和 codex 展开讨论，贴一些网站链接、初步构想，让它解读现有代码，然后我们一起把新功能逐步梳理出来。如果问题比较棘手，我会让它把思路整理成一份规范文档，然后交给 GPT-5-Pro（通过 chatgpt.com）做评审，看看是否有更好的建议 —— 出乎意料的是，这经常能大幅优化我的方案！接着，我会把其中我觉得有用的部分粘回主上下文，用于更新实际文件。

现在我对不同任务消耗多少上下文已经有不错的直觉，而 codex 的上下文容量也相当充足，所以很多时候我干脆直接开干。有些人很“虔诚”，总喜欢为每个新计划新开一个上下文窗口 —— 我觉得这在 Sonnet 时代还有点用，但 GPT-5 处理长上下文的能力强得多，如果还这么做，每次都会白白多花 10 分钟，因为模型得重新慢慢加载所有构建功能所需的文件。

更有趣的方式是做基于 UI 的开发。我经常从一个非常简单的东西开始，故意把需求写得极其模糊，然后一边看模型编码，一边在浏览器里实时看到效果。接着我再排队加入更多调整，逐步迭代这个功能。很多时候我自己也不确定最终该长什么样，这种方式让我能边玩边试，看着想法慢慢成形。有时 codex 甚至会做出一些我根本没想到但很妙的设计。我从不重置进度，只是一步步迭代，把混沌慢慢塑造成我觉得对的形状。

开发过程中，我也常会冒出一些关联功能的新点子，顺势对其他部分也做些调整 —— 这部分工作我会放到另一个智能体里处理。通常我主攻一个核心功能，同时并行处理一些次要但相关的任务。

就在我写这段文字时，我正在给 Chrome 扩展开发一个新的 Twitter 数据导入器，为此我正在重构 graphql 导入模块。因为还不确定这个方案是否合理，我把这部分代码放在一个单独的文件夹里，这样可以通过 PR 预览来判断思路是否成立。主仓库则在做重构，让我能专心写这篇文章。

11 请分享您的斜杠命令！

我只有少数几个斜杠命令，而且很少用：

• /commit（自定义说明文本，用于协调多智能体在同一目录协作时仅提交自身修改。这样能保持提交信息干净，也能防止 GPT 因看到其他改动而 panic，比如 linter 报错时乱 revert（译者注：Git 版本控制中的常用术语，撤销某次或某几次提交（commit）所引入的更改。））
• /automerge（一次处理一个 PR：响应机器人评论、回复、等 CI 通过后自动 squash 合并（译者注：Git 版本控制中的常用术语，将多个连续的提交记录合并成一个单一的、干净的提交。））
• /massageprs（和 automerge 类似，但不用 squash，方便在有大量 PR 时并行处理）
• /review（内置命令，偶尔用 —— 因为 GitHub 上已有 review bot，但有时还是有用）

即便如此，大多数时候我其实就直接打 “commit” 两个字。除非我知道当前有太多脏文件，担心智能体在没有引导的情况下出错。如果我确信简单指令就够了，就绝不会搞那些花哨的表演或浪费上下文。这种直觉是慢慢练出来的。到目前为止，我还没见过其他真正有用的斜杠命令。

12 其他实用技巧

与其费尽心思写出完美的提示词去“激励”智能体完成一个长期任务，不如用点偷懒的变通方法。 比如进行大型重构时，Codex 常会在中途暂停响应。这时候，只要提前排好几条 “continue” 消息，你就可以走开，等回来时活儿就干完了。如果 codex 已经完成了任务，再收到更多消息，它也会愉快地忽略掉。

每次完成一个功能或 Bug 修复后，请让模型在同一上下文中顺手写点测试用例。 这样做不仅能产出质量高得多的测试用例，还常常能暴露代码实现中的 bug。如果是纯 UI 调整，可能测试意义不大。但对于其他情况，我强烈建议这么做。AI 写测试用例总体上还是不太行，但已经比没有强多了 —— 而且说实话，你自己每次改代码都会写测试用例吗？

让模型“保留你的原始意图”，并“在复杂逻辑处添加代码注释”，这对您和后续模型理解代码都大有裨益。

当遇到棘手难题时，在提示词中加入一些触发词，比如 “take your time”（慢慢来）、“comprehensive”（全面一点）、“read all code that could be related”（读所有可能相关的代码）、“create possible hypothesis”（提出可能的假设） —— 这些都能让 codex 解决最棘手的问题。

13 你的 Agents/Claude 配置文件是什么样的？

我创建了一个名为 Agents.md 的主配置文件，然后为它创建了一个符号链接（译者注：Linux 操作系统中一个特殊的文件，内容存储指向目标文件或目录的路径字符串），这个链接的名字叫 claude.md。我这么做是因为开发 Claude 的 Anthropic 公司没有采用和其他工具（比如 Codex）统一的配置文件命名标准。我承认这很麻烦也不理想 —— 毕竟 GPT-5 和 Claude 偏好的提示词风格差异很大[39]。如果你还没看过它们各自的提示词指南，建议现在就去读一读。

Claude 对那种 🚨 全大写咆哮式命令 🚨[40]（比如“如果你执行 X 命令，后果将极其严重，100 只小猫会死掉！”）反应良好，但这会让 GPT-5 直接崩溃（也确实该崩溃）。所以，请彻底放弃这种写法，像正常人一样用平实的语言就行。这也意味着这些配置文件很难被最优地共享。不过对我来说问题不大，因为我主要用 codex，即使偶尔让 Claude 上场，我也接受这些指令对它来说可能强度不足。

我的 Agent 配置文件目前大约 800 行，感觉就像一堆“组织创伤”留下的疤痕组织。这不是我手写的，而是 codex 自己生成的。每次出了状况，我都会让它在文件里加一条简洁备注。我应该找个时间清理一下配置文件，但尽管文件很长，它却运行得极其可靠 —— GPT-5 也确实几乎总是遵守里面的规则。至少比 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，用来拦截不符合规范的提交。）

我还尝试过一种基于文本的“设计系统”，用来规定 UI 应该长什么样 —— 不过这个实验目前还没下定论。

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

当然不是。有时候它会花半个小时重构代码，然后突然 panic，把所有改动全 revert 掉 —— 这时候你得重新运行，并像哄小孩一样安抚它：“你有足够的时间，慢慢来。” 有时它会忘记自己其实能执行 bash 命令，需要你鼓励一下。偶尔它还会用俄语或韩语回复。更离谱的是，有时候这个“怪物”一滑手，直接把内部思考过程原样扔进了 bash 终端。但总体而言，这些情况相当罕见，而它在其他几乎所有方面都强到离谱，让我完全可以忽略这些小毛病。毕竟，人类也不是完美的。

我对 codex 最大的不满是它会“丢失文本行” —— 快速向上滚动时，部分文本会莫名其妙消失。真心希望 OpenAI 把这个 Bug 放在修复清单的最顶端，因为这是目前唯一迫使我放慢操作速度的原因，就怕消息突然不见了。

15 结论

别在 RAG、子智能体（subagents）、Agents 2.0 或其他华而不实的花架子上浪费时间了。直接跟它对话，动手试，慢慢培养直觉。你和智能体合作得越多，结果就会越好。

Simon Willison 的文章[41]说得特别到位：管理智能体所需的许多技能，其实和管理工程师非常相似 —— 而这些能力，几乎全都是资深软件工程师的特质。

而且没错，写出好软件依然很难。我不再亲手写代码，并不意味着我不再深入思考架构、系统设计、依赖关系、功能实现，或者如何让用户感到惊喜。使用 AI 只意味着：大家对你交付成果的期望值变高了。

PS: 本文 100% 原创手写。我热爱 AI，但也清楚有些事用老办法反而更好。保留这些笔误，保留我的声音。🚄✌️

PPS: 文章头图由 Thorsten Ball 提供[42]，特此致谢。

END

本期互动内容 🍻

❓文中哪个观点你极度认同？或者，哪个地方你持保留意见？

文中链接

[1]https://x.com/christianklotz/status/1977866496001867925

[2]https://x.com/pmddomingos/status/1976399060052607469

[3]https://steipete.me/posts/2025/optimal-ai-development-workflow

[4]https://x.com/steipete/status/1977771686176174352

[5]https://x.com/steipete/status/1977498385172050258

[6]https://gist.github.com/steipete/d3b9db3fa8eb1d1a692b7656217d8655

[7]https://x.com/steipete/status/1977119589860601950

[8]https://x.com/weberwongwong/status/1975749583079694398

[9]https://x.com/steipete/status/1976353767705457005

[10]https://x.com/steipete/status/1977072732136521836

[11]https://x.com/vtahowe/status/1976709116425871772

[12]https://x.com/s_streichsbier/status/1974334735829905648

[13]https://x.com/kimmonismus/status/1976404152541680038

[14]https://x.com/steipete/status/1978099041884897517

[15]https://x.com/steipete/status/1975297275242160395

[16]https://x.com/steipete/status/1977466373363437914

[17]https://x.com/deepfates/status/1975604489634914326

[18]https://ampcode.com/news/gpt-5-oracle

[19]https://x.com/btibor91/status/1976299256383250780

[20]https://x.com/badlogicgames/status/1977103325192667323

[21]https://x.com/steipete/status/1976226900516209035

[22]https://x.com/steipete/status/1977286197375647870

[23]https://x.com/thsottiaux/status/1975565380388299112

[24]https://www.anthropic.com/news/claude-code-plugins

[25]https://github.com/wshobson/agents/blob/main/plugins/llm-application-dev/agents/ai-engineer.md

[26]https://x.com/IanIsSoAwesome/status/1976662563699245358

[27]https://wisprflow.ai/

[28]https://x.com/cannn064/status/1973415142302830878

[29]https://conductor.build/

[30]https://www.terragonlabs.com/

[31]https://x.com/steipete/status/1973132707707113691

[32]https://github.com/steipete/claude-code-mcp

[33]https://github.com/steipete/bslog

[34]https://github.com/steipete/inngest

[35]https://developer.chrome.com/blog/chrome-devtools-mcp

[36]https://x.com/steipete/status/1977762275302789197

[37]https://x.com/steipete/status/1976985959242907656

[38]https://knip.dev/

[39]https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide

[40]https://x.com/Altimor/status/1975752110164578576

[41]https://simonwillison.net/2025/Oct/7/vibe-engineering/

[42]https://x.com/thorstenball/status/1976224756669309195

本文经原作者授权，由 Baihai IDP 编译。如需转载译文，请联系获取授权。

原文链接：

https://steipete.me/posts/just-talk-to-it