分享一名海外独立开发者的 AI 编程工作流

编者按: 当 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\][x.com/christiankl...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fchristianklotz%2Fstatus%2F1977866496001867925 "https://x.com/christianklotz/status/1977866496001867925") \[2\][x.com/pmddomingos...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fpmddomingos%2Fstatus%2F1976399060052607469 "https://x.com/pmddomingos/status/1976399060052607469") \[3\][steipete.me/posts/2025/...](https://link.juejin.cn?target=https%3A%2F%2Fsteipete.me%2Fposts%2F2025%2Foptimal-ai-development-workflow "https://steipete.me/posts/2025/optimal-ai-development-workflow") \[4\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1977771686176174352 "https://x.com/steipete/status/1977771686176174352") \[5\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1977498385172050258 "https://x.com/steipete/status/1977498385172050258") \[6\][gist.github.com/steipete/d3...](https://link.juejin.cn?target=https%3A%2F%2Fgist.github.com%2Fsteipete%2Fd3b9db3fa8eb1d1a692b7656217d8655 "https://gist.github.com/steipete/d3b9db3fa8eb1d1a692b7656217d8655") \[7\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1977119589860601950 "https://x.com/steipete/status/1977119589860601950") \[8\][x.com/weberwongwo...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fweberwongwong%2Fstatus%2F1975749583079694398 "https://x.com/weberwongwong/status/1975749583079694398") \[9\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1976353767705457005 "https://x.com/steipete/status/1976353767705457005") \[10\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1977072732136521836 "https://x.com/steipete/status/1977072732136521836") \[11\][x.com/vtahowe/sta...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fvtahowe%2Fstatus%2F1976709116425871772 "https://x.com/vtahowe/status/1976709116425871772") \[12\][x.com/s_streichsb...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fs_streichsbier%2Fstatus%2F1974334735829905648 "https://x.com/s_streichsbier/status/1974334735829905648") \[13\][x.com/kimmonismus...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fkimmonismus%2Fstatus%2F1976404152541680038 "https://x.com/kimmonismus/status/1976404152541680038") \[14\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1978099041884897517 "https://x.com/steipete/status/1978099041884897517") \[15\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1975297275242160395 "https://x.com/steipete/status/1975297275242160395") \[16\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1977466373363437914 "https://x.com/steipete/status/1977466373363437914") \[17\][x.com/deepfates/s...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fdeepfates%2Fstatus%2F1975604489634914326 "https://x.com/deepfates/status/1975604489634914326") \[18\][ampcode.com/news/gpt-5-...](https://link.juejin.cn?target=https%3A%2F%2Fampcode.com%2Fnews%2Fgpt-5-oracle "https://ampcode.com/news/gpt-5-oracle") \[19\][x.com/btibor91/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fbtibor91%2Fstatus%2F1976299256383250780 "https://x.com/btibor91/status/1976299256383250780") \[20\][x.com/badlogicgam...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fbadlogicgames%2Fstatus%2F1977103325192667323 "https://x.com/badlogicgames/status/1977103325192667323") \[21\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1976226900516209035 "https://x.com/steipete/status/1976226900516209035") \[22\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1977286197375647870 "https://x.com/steipete/status/1977286197375647870") \[23\][x.com/thsottiaux/...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fthsottiaux%2Fstatus%2F1975565380388299112 "https://x.com/thsottiaux/status/1975565380388299112") \[24\][www.anthropic.com/news/claude...](https://link.juejin.cn?target=https%3A%2F%2Fwww.anthropic.com%2Fnews%2Fclaude-code-plugins "https://www.anthropic.com/news/claude-code-plugins") \[25\][github.com/wshobson/ag...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fwshobson%2Fagents%2Fblob%2Fmain%2Fplugins%2Fllm-application-dev%2Fagents%2Fai-engineer.md "https://github.com/wshobson/agents/blob/main/plugins/llm-application-dev/agents/ai-engineer.md") \[26\][x.com/IanIsSoAwes...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2FIanIsSoAwesome%2Fstatus%2F1976662563699245358 "https://x.com/IanIsSoAwesome/status/1976662563699245358") \[27\][wisprflow.ai/](https://link.juejin.cn?target=https%3A%2F%2Fwisprflow.ai%2F "https://wisprflow.ai/") \[28\][x.com/cannn064/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fcannn064%2Fstatus%2F1973415142302830878 "https://x.com/cannn064/status/1973415142302830878") \[29\][conductor.build/](https://link.juejin.cn?target=https%3A%2F%2Fconductor.build%2F "https://conductor.build/") \[30\][www.terragonlabs.com/](https://link.juejin.cn?target=https%3A%2F%2Fwww.terragonlabs.com%2F "https://www.terragonlabs.com/") \[31\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1973132707707113691 "https://x.com/steipete/status/1973132707707113691") \[32\][github.com/steipete/cl...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fsteipete%2Fclaude-code-mcp "https://github.com/steipete/claude-code-mcp") \[33\][github.com/steipete/bs...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fsteipete%2Fbslog "https://github.com/steipete/bslog") \[34\][github.com/steipete/in...](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fsteipete%2Finngest "https://github.com/steipete/inngest") \[35\][developer.chrome.com/blog/chrome...](https://link.juejin.cn?target=https%3A%2F%2Fdeveloper.chrome.com%2Fblog%2Fchrome-devtools-mcp "https://developer.chrome.com/blog/chrome-devtools-mcp") \[36\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1977762275302789197 "https://x.com/steipete/status/1977762275302789197") \[37\][x.com/steipete/st...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fsteipete%2Fstatus%2F1976985959242907656 "https://x.com/steipete/status/1976985959242907656") \[38\][knip.dev/](https://link.juejin.cn?target=https%3A%2F%2Fknip.dev%2F "https://knip.dev/") \[39\][cookbook.openai.com/examples/gp...](https://link.juejin.cn?target=https%3A%2F%2Fcookbook.openai.com%2Fexamples%2Fgpt-5%2Fgpt-5_prompting_guide "https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide") \[40\][x.com/Altimor/sta...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2FAltimor%2Fstatus%2F1975752110164578576 "https://x.com/Altimor/status/1975752110164578576") \[41\][simonwillison.net/2025/Oct/7/...](https://link.juejin.cn?target=https%3A%2F%2Fsimonwillison.net%2F2025%2FOct%2F7%2Fvibe-engineering%2F "https://simonwillison.net/2025/Oct/7/vibe-engineering/") \[42\][x.com/thorstenbal...](https://link.juejin.cn?target=https%3A%2F%2Fx.com%2Fthorstenball%2Fstatus%2F1976224756669309195 "https://x.com/thorstenball/status/1976224756669309195") ***本文经原作者授权,由 Baihai IDP 编译。如需转载译文,请联系获取授权。*** **原文链接:** [steipete.me/posts/just-...](https://link.juejin.cn?target=https%3A%2F%2Fsteipete.me%2Fposts%2Fjust-talk-to-it "https://steipete.me/posts/just-talk-to-it")

相关推荐
yaocheng的ai分身1 小时前
AI 代码评估的下一阶段已经到来
ai编程
油炸小波1 小时前
02-AI应用开发平台Dify
人工智能·python·dify·coze
机器之心1 小时前
Gemini 3深夜来袭:力压GPT 5.1,大模型谷歌时代来了
人工智能·openai
该用户已不存在2 小时前
Gemini 3.0 发布,Antigravity 掀桌,程序员何去何从?
后端·ai编程·gemini
菠菠萝宝2 小时前
【Java手搓RAGFlow】-1- 环境准备
java·开发语言·人工智能·llm·openai·rag
大模型教程2 小时前
Happy-LLM:从零开始的大语言模型原理与实践教程
程序员·llm·agent
AndrewHZ2 小时前
【图像处理基石】如何从动漫参考图中提取色彩风格?
图像处理·人工智能·opencv·pillow·聚类算法·色彩风格·色彩分布
阿里云大数据AI技术2 小时前
PAI Physical AI Notebook详解3:基于仿真的导航模型训练
人工智能
小兵张健2 小时前
LLM 四阶段和 Transformer 架构(二)
llm