编者按： 当 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