这是一篇关于 AI 智能体工程（Agentic Engineering）实战经验的深度分享。作者 Peter Steinberger 详细介绍了他在处理 30 万行代码的大型项目时，如何通过“直接对话”而非复杂的工程套路，实现 AI 编写 100% 代码的高效工作流。

本文核心观点是：回归简单，直接与 AI 对话（Just Talk To It）。作者认为，当前的 AI 智能体工程中存在过多的“花招”（如复杂的子代理、RAG、计划模式等），这些往往会降低效率。作者目前已全面转向使用 gpt-5-codex 命令行工具（CLI），并总结了一套实战经验：

1. 工具选择：相比于 Claude Code，作者更推崇 OpenAI 的 codex。它在上下文容量（230k）、Token 使用效率、消息队列功能、运行速度以及沟通语言的“情绪价值”上表现更优。
2. 核心策略：引入“爆炸半径”（Blast Radius）概念，主张通过多个并行运行的代理处理小规模、原子化的任务，而不是一个庞大且难以控制的任务。
3. 提示词技巧：随着模型能力的提升，提示词应变得更短、更直接。作者强调了“截图”在提供上下文方面的巨大威力，并建议通过 tmux 管理后台任务，而非依赖复杂的插件系统。
4. 维护与重构：AI 编写的代码并非完美，作者投入 20% 的时间进行“代码除草”（重构），利用 knip、eslint 等工具保持代码库健康。
5. 工程本质：尽管 AI 承担了编码工作，但架构设计、系统思考和用户体验仍需人类把关。管理 AI 代理的能力正逐渐演变为高级软件工程师的核心竞争力。

---

内容精简

主题 1：从 Claude 转向 Codex 的实战选择

作者在长期实践后，将主力工具从 Claude Code 切换到了 OpenAI 的 codex CLI。这一转变并非盲目跟风，而是基于多维度的生产力对比。首先是上下文管理：Codex 拥有约 230k 的可用上下文，且 Token 消耗比 Claude 更慢，极少出现 Claude 常见的“压缩中（Compacting）”提示。其次是交互体验：Codex 允许消息排队（Message Queuing），用户可以一次性输入多个相关任务让其依次完成，若需干预只需按 Esc 键。

在性能与稳定性方面，Codex 采用 Rust 重写，运行速度极快，没有 Claude Code 在某些终端（如 Ghostty）中出现的闪烁或内存占用过高的问题。更重要的是沟通风格：作者认为 Claude 有时显得过于“客套”或在测试失败时仍坚称代码完美，而 Codex 更像是一个沉默寡言但干活利索的工程师，这种语言风格上的差异显著改善了开发者的心理健康。此外，Codex 在开始工作前会阅读更多文件，这种“先调研后动手”的策略使其在处理复杂逻辑时比急于尝试的 Claude 更稳健。

主题 2：并行代理与“爆炸半径”管理

作者摒弃了复杂的 Git 工作树（Worktrees）或分支管理，转而采用在同一个文件夹下开启 3-8 个并行终端窗口的方案。每个窗口运行一个 Codex 代理，负责不同的原子化任务。为了维持代码库整洁，作者通过自定义的 Agents.md 指令让代理执行原子提交（Atomic Commits），确保每个代理只提交自己修改的文件。

这里引入了一个关键概念——“爆炸半径”（Blast Radius）。在下达指令前，开发者应预判该变更会触及多少文件。作者倾向于投掷多个“小炸弹”（小任务），而非一个“大胖子炸弹”（大规模重构）。如果某个代理运行时间超出预期，作者会立即中断并询问状态，这种实时干预比等待一个可能出错的长任务更高效。这种并行模式不仅加快了开发速度，还允许开发者在单一开发服务器上实时测试所有变更，避免了频繁切换环境的开销。

主题 3：提示词工程的简化与多模态辅助

随着模型能力的进化，作者发现提示词工程正在“退化”——即变得越来越短。过去需要详尽描述背景，现在往往只需 1-2 句话配合一张屏幕截图。截图是极佳的上下文补充，AI 能迅速通过视觉信息定位到代码中的特定字符串或 UI 组件，这比文字描述快得多。作者推荐使用 Wispr Flow 进行语音输入，进一步提升沟通效率。

对于复杂的任务，作者不再依赖专门的“计划模式”，而是直接与 AI 讨论。他会要求 AI 先给出方案或选项，待人工确认后再动手。如果任务确实棘手，他会先在网页端使用 GPT-5-Pro 生成详细规格书（Spec），再将其喂给 CLI 代理执行。这种“直接对话”的模式取代了繁琐的子代理（Subagents）架构。作者认为，所谓的子代理往往只是将任务包装在模糊的指令中，反而增加了上下文污染和控制难度，不如直接在不同终端窗口手动分配任务来得透明。

主题 4：代码质量维护与“AI 辅助重构”

AI 编写的代码不可避免地会产生“废料”或技术债。作者坚持将 20% 的工作时间用于重构。这并非手动完成，而是指挥 AI 代理利用专业工具进行清理：使用 jscpd 检测重复代码，使用 knip 移除死代码，运行 eslint 插件优化 React 性能，以及将日益臃肿的文件拆分。

作者认为，这种“快速迭代 + 定期清理”的节奏比在每次提交时追求完美更具生产力。此外，他强调了测试的重要性：在每个功能完成后，要求 AI 在同一上下文中编写测试。这不仅能覆盖逻辑，还能反向发现实现中的 Bug。为了长效维护，作者还利用 ast-grep 设置 Git 钩子，强制执行代码规范。通过在 Agents.md 中记录项目特有的命名规范、API 模式和架构偏好，AI 能够随着时间的推移变得越来越懂这个项目，从而减少沟通成本。

---

问答

问：为什么作者不推荐使用 RAG 或复杂的子代理（Subagents）框架？ 答：作者认为这些是针对模型能力不足的“补丁”。GPT-5 等高级模型已经具备极强的代码搜索和长上下文处理能力，直接对话（Just Talk To It）比通过复杂的中间层更高效、更易控制。

问：在并行运行多个 AI 代理时，如何避免 Git 提交混乱？ 答：通过在代理指令文件（Agents.md）中设定严格的 Git 规则，要求 AI 执行原子提交，且仅针对其编辑的文件进行操作。

问：为什么截图在 AI 开发流程中如此重要？ 答：截图能提供极高密度的上下文信息。AI 可以通过视觉识别 UI 元素并快速关联到代码位置，省去了大量定位文件和描述逻辑的文字工作。

问：作者如何处理 AI 代理卡死或陷入死循环的问题？ 答：作者使用传统的 tmux 工具在后台管理持久会话。如果 AI 任务卡住，他会直接按 Esc 中断并询问状态，而不是等待其自行恢复。

问：AI 编写 100% 的代码后，人类工程师的价值体现在哪里？ 答：价值体现在架构设计、系统依赖管理、功能定义以及对用户体验的把控上。管理 AI 代理的能力（类似管理人类工程师）已成为高级工程师的核心技能。