@KingBootoshi: 我的新AI工作流程搞乱了我的作息，但太值了。我感觉我的工程生产力又提升了一个层次……

我的新AI工作流程搞乱了我的作息，但太值了。我感觉我的工程生产力又提升到了新高度！（下文有详细的长篇阐述）经过大量试错和所谓的“效率表演”，我终于找到了有史以来最好用的编码工作流程。例如，用智能体协调子智能体试图最大化token利用，一次性捕获尽可能多的工作——这之前确实有效，并且很出色（对于老模型如opus 4.5和gpt 5来说甚至很有必要），但对于新一代模型（gpt 5.5和opus 4.8）来说，它不再有效。虽然这些模型的版本号看起来只是小幅递增，但它们的能力完全不同。由于扩展的上下文窗口和更高的智能，它们单独在一个单一超级线程中反而更强大。将复杂任务分解为步骤，然后用这些模型的子智能体并行执行，现在是对这些模型的错误使用方式。相反，将复杂任务分解为步骤，然后让一个单一的Codex智能体从头到尾运行整个列表，配合/goal模式，这是我一生中用过的**最精准、最快、最强大**的工作流程。几个月前，@steipete发布了一篇博客文章（下方有链接），标题是“直接跟它说”，他在文章中只是……直接跟Codex智能体对话来完成工作。没有疯狂的多智能体工作流，没有疯狂的插件……这个狂人只是告诉它要做的事情，然后信任它去完成。去年十月那篇文章发布时，我并不相信Codex能可靠地做到这一点，而且每次我自己尝试时，都没有得到最佳结果。Codex在编写原始代码方面一直是个好模型，但它太“自闭”了，无法理解我的意图，所以我用Claude Code来管理Codex智能体完成任务。这支撑了我2026年前半段的工作，也是我最好的个人工作流，因为我有一个能理解我意图的主智能体，可以把这些自闭的编码怪物对齐并掌控住。**然而**——随着5.5的发布和Codex框架的更新（特别是/goal模式），我旧的工作流完全失效了！5.5发布后的第一个月，我专门用Codex编码。这非常笨拙，感觉很奇怪，而且我有点神经多样性，所以跟Codex聊天（它说话的方式绝对给人一种神经多样性的感觉哈哈）真的很尴尬和奇怪。问题在于我太习惯跟Opus聊天了，Codex不像Opus那样理解我。我花了几个星期调整我的沟通风格来匹配Codex，然后我们就真的开始高效运转了！我开始从零开始做新的复杂项目，真正测试它的能力，这个怪物能够为我处理疯狂的项目，比如构建一个弹性系统，在我的Mac mini上启动微型虚拟机，安全地托管隔离的智能体——只需通过跟它对话。当然，我也有一些与我的工作流匹配的个人技能，以及像ESLint这样的代码库护栏来帮助维持秩序，但Codex只是在我要求时创建了这些，并更新它们以匹配它所做的工作。让Codex出类拔萃的是它通过在我的MacBook上使用计算机进行“自用测试”和运行端到端测试的能力。我觉得这是一个被严重低估的功能，但它让智能体即时创建可靠代码的能力提升了10倍，并且只有在代码从用户角度完全测试通过后才向我报告。这里的神奇动词是“自用测试”。自用测试意味着在向客户发布软件之前使用你自己的软件。Codex非常擅长使用它自己编写的软件，然后再将成果交付给我！因为这提高了工作的可靠性，我不再浪费时间修复只有通过实际使用应用才能发现的bug（重复多次会耗费大量时间），而是专注于提示下一个功能。这是一个巨大的时间节省器，因为@RayFernando1337教会我，代码本身看起来可能完美无瑕且逻辑上“无bug”，但自用测试应用会显示那些最终是架构性的问题——Codex非常擅长自己发现这些问题并重新设计逻辑来解决，同时出人意料地不破坏其他功能，因为如果它在重写中确实破坏了其他功能，它会发现它，并抛出一张网，覆盖所有相关的问题，设计出恰当的解决方案，因为它拥有**完整的上下文**。过去，告诉智能体“修复”一个问题会导致它在过程中破坏其他正常功能，但嘿，它“修复”了原始问题，哈哈。至于我如何与Codex沟通以获得这些出色结果，其实很简单，但最终需要花费相当多的时间。我将在这里更详细地说明，因为这是整个过程中最关键的部分。实际上，在关键工作中，**没有比讨论阶段更重要的了**，你**绝对不能搞砸**。你对工作流程所做的任何优化，与这设置的影响相比都微不足道！在过去的六个月里，我一直在开发我的产品，构建一个能为我所在地区的非技术企业主完全自动化有影响力工作流程的东西。AI令人困惑，所以我设计了一个解决方案，让它使用起来异常简单。比如，他们甚至不需要跟智能体对话或使用应用，只需偶尔点一下按钮。重点是，代码库已经变得相当庞大，我需要极其小心地工作。我不能只告诉Codex两句话就让它做事，因为它不理解我设计品味的具体细节——但经过几次简单的来回对话，它就**完全与我对齐**，精确地理解它需要做什么，然后一次性完成一大块工作，**没有错误**。它每次都交付完美。这个过程大致如下：1. 我：“嘿Codex，我们需要实现计费系统。我希望这是集中式且强制的，这样每一个计费服务都通过这个系统路由。研究并界定范围，然后向我报告几个选项，选择最简单且长期来看最正确的设计方案——以及最多5个我需要回答的重要架构问题。”（注意：要求“最简单”的设计实际上能防止过度工程化。我要求不同的选项来激活“创造性”向量，探索完全不同的解决方案。我必须告诉它找到长期最正确的解决方案，因为如果不这样，它会找到能有效完成工作的“最简单”方案，但不利于扩展或长期愿景。这三个简单请求的组合为我产生了最有效的输出。）2. 然后Codex去阅读所有相关文档、我们的ADR（关键，下面会进一步解释）和原始代码本身。这里**绝对不要**让Codex子智能体去做阅读。子智能体在压缩大量研究方面做得很好，但代码是具体的，逻辑至关重要。摘要总会遗漏重要细节。让一个Codex智能体阅读并持有这个逻辑的一个巨大好处是，它不需要再次读取文件，然后**快速完成**实现。3. 由于5.5非常智能，它会反馈高度相关的问题，使我能够将我的意图与Codex对齐。这些问题通常非常容易回答，我总会问它推荐答案及其支持解释。如果你在代码库中设置了ADR，你可能会发现Codex最终推荐的答案完全与你一致。95%的情况下，我都不需要回答这些问题，因为它直接推荐了我会说的话，所以我只说“是”来确认对齐。**现在**——快速插播一下ADR是什么，我如何使用它，以及为什么它完全取代了我应用中其他形式的文档。ADR是架构决策记录。这是一种企业实践，允许大型团队和新成员在……