独家揭秘 6 位工程师的 AI 工作流：流程比工具更重要

在 AI 编码工具（如 Claude Code, Codex 等）日益强大的今天，高效的开发者不再依赖单一工具，而是进化出高度个性化、多工具编排的复杂工作流，未来的开发效率不仅取决于 AI 模型的能力，更取决于开发者如何围绕 AI 设计自己的工作系统，以平衡快速执行、深度探索和上下文管理，从而将 AI 的生产力真正释放出来。本文作者莫尔索

Yash Poojary : 平衡执行与探索的双重模式

核心策略: 通过"上午执行，下午探索"的模式来平衡交付和实验。上午只用成熟工具 (Codex, Claude Code) 专注核心任务；下午才测试新工具。
工具栈: - 对比测试: 在两台机器上 (Mac Studio + 笔记本) 同时运行 Claude Code 和 Codex。 - Figma MCP: Claude 能直接连接 Figma 文件，读取设计系统并生成代码。 - Warp: 现代命令行工具。 - AgentWatch (自研): 当 Claude Code 会话完成时发出提醒，以便同时运行多个会话。
工作流程: 1. 设计转代码: 直接通过 Figma MCP 集成，让 Claude 读取设计系统并转换代码。 2. 上下文管理: 使用 Warp 时，会随手记录"学习文档"，为 AI 提供近期上下文。 3. 防偏离: 严格划分任务，设置"护栏"，避免被 AI 建议带偏。

他发现，Claude Code 扮演着"友好的开发者" (friendly developer) 的角色。这个模型的优势在于它擅长将复杂问题进行拆解，并清晰地解释其背后的推理过程。这使得 Claude Code 非常适合用于探索性任务、理解遗留代码或学习新的编程范式。它更像一个"结对编程"的伙伴，重在过程和理解。

相比之下，Codex 则是"技术型开发者" (technical developer) 。它的特点是更加"字面化" (literal) 和"精确" (precise)，不（太）善于解释，但倾向于在第一次尝试时就给出技术上正确的解决方案。这使得 Codex 成为执行明确、定义清晰的任务时的首选工具，它的价值在于速度和准确性。Yash 的工作流因此变得更加智能：他会根据任务的性质（需要探索还是需要执行）来选择合适的 AI "同事"。

为了解决 AI 工具（尤其是命令行界面）容易让人"偏离方向" (easy to deviate) 的问题，Yash 强调了 "设置护栏" (setting guardrails) 的重要性。他开发了一个名为 AgentWatch 的应用，专门用于在 Claude Code 会话完成时提醒他。这解决了一个关键痛点：当开发者同时运行多个 AI 任务时，很容易失去追踪，导致时间浪费和上下文切换的混乱，AgentWatch 让他可以放心地"并行"处理任务。

最核心的是，Yash 将他的一天划分为两种截然不同的模式，以此来消除测试新工具时常见的"生产力拖累" (productivity drag)，上午执行模式 (Execution Mode) 专注于交付，此阶段的唯一目的是完成一个大任务和几个小任务，推动项目前进，严格限制只使用 Codex 和 Claude Code，这些是已经验证过的、可靠的生产力工具。下午探索模式 (Exploration Mode) 学习和发现新的 Agent、应用和功能。

最后，Yash 还依赖 Warp（一个现代化的开发者命令行工具）来构建他的长期"记忆"。每次他推送代码时，他都会在一个"学习文档" 中记录两行关于所学内容的笔记，并将其存储在云端。几天后，这份文档就成了他近期上下文的滚动记录。当他开始新任务时，会把这份"记忆"反馈给他的 AI 工具。这极大地提高了 AI 的上下文感知能力，使其建议更加贴合他当前的项目状态和技术思考。

Kieran Klaassen: 基于复杂度的分层规划与编排循环

核心策略: "计划先行"。所有工作都始于 Claude Code 生成的详细计划，并根据复杂性分层。
工具栈: - Claude Code: 用于生成计划和执行编码的首选工具 (因其可控性)。 - Codex / Amp: 用于处理更传统或"更极客"的功能。 - Context 7 MCP: 用于抓取最新的、特定版本的官方文档和代码示例，注入提示词。 - Cursor / Charlie: 用于辅助代码审查。
工作流程: 1. 规划: 使用 Claude Code 和 Context 7 MCP 生成计划 (分为小型、中型、大型三类)。 2. 执行: 计划发送到 GitHub，使用"工作命令" (提示词) 将计划转为 AI 编码任务。 3. 审查: 使用"审查命令"，以 Claude 为主，结合其他工具进行循环审查，直到功能准备就绪。

他的所有工作都始于一个"计划"，这个计划本身就是在 Claude Code 中通过一套自定义的 Agent 和工作流程生成的。他强调，计划的目的是将后续的开发工作"建立在事实基础上" (grounded in fact)。

为了实现这一点，他使用 Context 7 MCP （一种集成工具）来构建计划。这个工具至关重要，因为它能从官方来源（如技术文档、API 参考）直接提取最新的、特定版本的文档和代码示例，并将这些权威信息直接注入到提示词中。这意味着 AI 在制定计划时，其依据的不是过时的网络信息或模型的"幻觉"，而是最准确、最相关的技术事实。这从源头上保证了计划的质量和可行性。

Kiera 的核心方法论是根据功能的复杂程度，将编程计划分为三个层次：

小型功能 (Small features):

定义： 足够简单，AI 可以一次性完成。 - 流程： 通常不需要复杂的审查，AI 生成代码后可快速合并。

中型功能 (Medium features):

定义： 跨越几个不同的文件，可能涉及多个组件的交互。 - 流程： AI 完成编码后，必须经过一个审查步骤，这个步骤通常由 Kieran 亲自完成。这确保了跨文件的更改是协调一致的，并且符合整体架构。

大型功能 (Large features): - 定义： 复杂的构建，涉及新架构、深入研究或重大的重构。 - 流程： 这类功能需要大量的手动输入和来回讨论。计划阶段可能就需要 Kiera 和 AI 进行多轮对话，AI 提出方案，Kiera 进行决策和调整。

这个分层系统确保了资源（无论是 AI 的计算资源还是人的注意力）都能被高效利用。

一旦计划设定（无论哪个层次），它会被发送到 GitHub。GitHub 在这里不仅是代码仓库，更是 Kiera 工作流的"任务板"。从那里，他使用一个"工作命令"------这本质上是一个精心设计的提示词，它将 GitHub 上的计划转化为 AI Agent 可以执行的具体编码任务。

在工具选择上，Kiera 也表现出灵活性。对于大多数项目，Claude Code 是他的首选，因为他认为 Claude 给了他更多的"控制和自主权"。他也会在特定情况下转向 Codex 或智能编码工具 Amp，尤其是处理那些"更传统" (more conventional) 或"更极客" (geekier) 的功能时。

工作完成后，他会启动一个"审查代码的命令" 。在这个阶段，Claude 通常也扮演主要角色，但 Kiera 会混合使用其他 AI 工具，包括 Cursor 和 Charlie，来进行交叉验证和深度审查。

这个 "计划 -> GitHub -> 工作命令 -> 编码 -> 审查命令 -> 审查 -> 迭代" 的过程会循环进行 (This process loops...)，直到 Kieran 认为功能已经完全准备好发布。这套工作流的精妙之处在于，它将 AI Agent 无缝地集成到了一个标准化的、可重复的软件开发生命周期中，AI 在其中扮演了从"规划者"到"执行者"再到"审查者"的多个角色，而 Kieran 则作为最终的"编排者"和"决策者"掌控着整个循环。

Danny Aziz: "对话式规划"与工具收敛

核心策略: 高度集成。约 70% 的工作在 Droid (一个允许并排使用 Anthropic 和 OpenAI 模型的 CLI) 中完成。
工具栈: - Droid (核心): 主要工作界面。 - GPT-5 Codex: 用于大型功能构建和规划。 - Anthropic 模型: 用于完善和处理细节。 - Warp: 作为 Droid 之外的主要界面，用于分屏和任务切换。 - Zed: 轻量级代码编辑器，用于审查计划文件和代码片段。 - (已弃用 Cursor)
工作流程: 1. 规划: 在 Droid 中与 GPT-5 Codex "交谈"，推演功能的二阶和三阶后果，并将其转化为项目里程碑。 2. 执行: 在 Droid 中使用 GPT-5 Codex 进行主体构建，然后切换到 Anthropic 模型进行收尾。 3. 设置: 保持极简，通常只用一个显示器或笔记本。只在实现设计时才添加第二屏，用于并排查看 Figma。

他的工作流呈现出一种"极端收敛"的趋势。他目前的工作流程几乎完全在 Droid 内部运行。Droid 是 Factory（一家构建编码 Agent 的初创公司）拥有的一个命令行界面，其核心特性是允许开发者并排使用 Anthropic 和 OpenAI 的模型。Danny 大约 70% 的工作都在这个环境中完成，这显示了他对该工具的高度依赖。

他的模型使用策略非常明确：他依靠 GPT-5 Codex 来进行大型功能的构建。这可能是因为 Codex 在处理复杂逻辑和生成大规模、结构化代码方面表现出色。然后，他会切换到 Claude 来进行完善和确定细节。这种组合利用了不同模型的优势：一个擅长"搭建骨架"，另一个擅长"精细打磨"。

Danny 工作流中最独特的部分是他的"规划阶段"。他不会直接开始编码，而是会花时间与 GPT-5 Codex"交谈"。这种对话不是简单的问答，而是一种深入的"实施计划具体化"的过程。他会主动询问他的技术选择可能带来的 "二阶和三阶后果" (second-order and third-order consequences) 。

例如，他会探索这样的问题：如果 Agent 实现了某个功能，但由于它从数据库提取数据的方式（比如一个效率低下的 N+1 查询），是否会导致整个应用变慢？Danny 的目标是提前发现这些潜在的性能瓶颈或架构缺陷，而不是等到功能上线后才作为 bug 来修复。他让 AI 将这些深入的见解和风险分析转化为项目的"里程碑" (milestones)。这种"对话式规划"将 AI 从一个"代码生成器"提升为了一个"架构顾问"。

他的主要界面是 Warp （现代命令行工具），他可以在 Warp 中将屏幕分成不同的视图，并在任务之间快速切换。而在 Warp 的背后，他使用 Zed------一个以速度著称的轻量级代码编辑器 ------来专门审查 AI 生成的计划文件和特定的代码片段。这个"Warp + Zed + Droid"的组合，构成了他高度优化的开发环境。

Naveen Naidu : 以 Linear 为核心的双轨工作流

核心策略: 双轨制工作流 (规划和执行均分轨)，并以 Linear 作为唯一的"真相来源"。
工具栈: - Linear: 项目管理中心，"如果不在 Linear 中，它就不存在"。 - Codex (Cloud & CLI): 日常主力工具 (已从 Claude Code 迁移)。 - Ghostty: 选择的终端工具。 - Xcode / Cursor: 分别用于 macOS 开发和后端工作。 - Monologue (自研): 语音转文字应用，用于口述提示词、工单和计划。
工作流程:

规划 (双轨): - 小 Bug: 在 Linear 中添加上下文，手动复制到 Codex Cloud。 - 大功能: 在 Codex CLI 中编写本地 plan.md (蓝图)。 2. 执行 (双轨): - Codex Cloud (探索): 用于头脑风暴、生成 PR 草稿 (探索边缘情况)、运行异步任务。 - Codex CLI (构建): 在 Ghostty 终端中，围绕 plan.md 让 Agent 驱动文件编辑。 3. 审查:

运行 Codex 内置的 /review 命令自动扫描。 - 手动进行"之前"和"之后"的代码对比。 - (Bug 修复) 检查 Sentry 日志，确认错误率下降。

他的工作流围绕一个核心原则展开：流程即是真相来源 。对他而言，这个"真相来源"就是项目管理工具 Linear。功能请求的来源多种多样------可能来自 Discord 聊天、电子邮件、反馈，甚至是实时的用户电话------但它们最终必须汇集到同一个地方：Linear。"如果不在 Linear 中，它就不存在"，每张 Linear 工单都会附带一个指向原始来源（如 Discord 消息链接）的链接。这确保了他始终可以追溯到"是谁提出的"以及"为什么提出"，保证了上下文的完整性。

在过去几周里，Naveen 的主力工具发生了变化，他已经从 Claude Code 迁移到了 Codex 来进行日常工作。

Naveen 的工作流被清晰地划分为"规划"和"执行"两个阶段，并且每个阶段都存在两条并行的轨道，这取决于任务的规模：

1. 规划模式 (Planning Mode)

轨道一：小型 Bug 和快速改进 (Small bugs or quick improvements)
流程： 非常直接。他直接在 Linear 工单的描述中添加必要的上下文和需求。 - 工具： 他将这些信息手动复制粘贴到 Codex Cloud（网页版）中，以启动一个 Agent 任务。 - 特点： 没有使用花哨的 MCP 集成，追求的是简单、快速。
轨道二：更大的功能 (Bigger features) - 流程： 他会跳出 Linear，进入 Codex CLI（命令行界面）。 - 工具： 他在本地编写一个 plan.md 文件。这个简单的 Markdown 文本文件是项目的"蓝图" 和"权威规范"。 - 特点： plan.md 列出了所有步骤、范围和关键决策。在后续的工作中，他会不断与 Agent 迭代和完善这个文件，使其成为指导 AI 工作的核心文档。

2. 执行模式 (Execution Mode)

轨道一：Codex Cloud (云端)
目的： 头脑风暴和生成拉取请求草稿。 - 特点： 他在这里生成的 PR 通常不是为了最终合并，而是为了"探索想法" 、"揭示边缘情况" 以及"获得并行的潜在修复方案" 。 - 优势： 他偏爱云端，因为这允许他异步启动后台任务。无论他是在 iOS ChatGPT 应用上还是在网页上，都可以随时启动一个任务，而不必占用本地机器资源。
轨道二：Codex CLI (本地命令行) - 目的： 真正的构建。 - 流程： 他会不断完善那个 `plan.md 文件，然后让 Agent 在他选择的 终端 Ghostty 中逐步驱动文件编辑。 - 工具： 在这个过程中，他使用 Xcode 进行原生 macOS 开发，使用 Cursor 进行后端工作。同时，与 Linear, Figma 和 Sentry 的 MCP 集成会将问题工单、设计稿和错误跟踪实时连接到这个开发循环中。

Naveen 的审查 (Review) 流程也自成一派，细致入微。首先，他会运行 Codex 内置的 /review 命令，对代码进行自动扫描，捕捉明显的 bug 或问题。然后，他会亲自通过并排比较代码的"之前"和"之后"版本来再次检查所有更改。当处理 bug 修复时，他还会更进一步：他会查看 Sentry 中更改前后的错误日志，通过数据来验证问题发生的频率是否确实降低了。

贯穿 Naveen 整个工具栈的一个独特工具是 Monologue ，这是他自己构建的语音转文字应用（在 Every 孵化，并于上个月推出）。他用 Monologue 来口述提示词、编写工单描述和更新他的 plan.md。这个工具无缝地将他的"想法"转化为了 AI Agent 可以理解和执行的"上下文"，极大地提高了输入效率。

Andrey Galko: 务实的工具选择与对模型进化的观察

核心策略: 实用主义。保持工作流程简单，"如果某样东西有效，就坚持使用"。
工具栈: - Codex: 当前主力。 - Cursor (曾用): 曾认为是最佳 UX，但因定价模式达到使用上限而放弃。
工作流程: - 演变: 早期 OpenAI 模型"偷懒"，但 GPT-4.5 和 GPT-5 改变了游戏规则，能完成端到端的 MVP 构建。 - 模型选择: Codex (尤其是 GPT-5-Codex) 现在在 UI 和非可视化逻辑上都表现出色，几乎不再需要切换到 Claude。

Andrey Galko 的工作流哲学可以用"务实"来概括。他不是那种"新工具"的开发者------在 AI 这个新工具层出不穷的领域，这一点尤为难得。他的准则是：如果某样东西有效，他就会坚持使用。

在很长一段时间里，Cursor 是他的主力工具，他至今仍然称其为拥有"最佳用户体验"的工具。他的迁移是被迫的。当 Cursor 改变定价策略后，Andrey 发现自己在短短一周内就达到了每月的（高级）使用限额，这迫使他必须寻找替代品。

他在 Codex 中找到了答案。Andrey 对 AI 模型的进化有着敏锐的观察。他说，在相当长的一段时间里，OpenAI 的模型（如早期的 GPT）生成的代码并"不够理想"。它们生成的代码片段虽然"技术上可以工作"，但存在两个主要问题：一是与现有代码库的风格和结构"不一致" ；二是经常"跳过步骤"，给人一种"偷懒"的感觉。

GPT-4.5 和 GPT-5 的出现让情况发生了变化。Andrey 观察到，这些新模型开始能够真正地"阅读代码"，并且能够独立完成从"从头到尾到功能性 MVP"的任务。这是一个质的飞跃。

他进一步指出，Codex 过去一直擅长的是"非可视化逻辑" ------即那些软件运行的幕后规则和流程，与用户点击的用户界面 (UI) 相对。而当 GPT-5 Codex 到来时，它终于也"擅长用户界面了"。

这是一个关键的转折点。虽然 Andrey 承认 Claude 可能仍然产生更具创意（有时甚至"过于创意"）的 UI，但他发现自己几乎不再需要在 OpenAI 和 Anthropic 的模型之间切换了。Codex 的能力已经变得足够全面。他总结道："我为 OpenAI 的人喝彩，他们成为了 Anthropic 代码生成统治地位的真正威胁。" 这反映了一个资深工程师对工具的实用主义态度：他选择的是能最可靠、最全面完成工作的工具，而不是仅仅追求某一方面的极致创意。

Nityesh Agarwal: 专注、研究与"鹰式"监控

核心策略: 极致专注。"一次只专注于一件事"，在单台 MacBook Air 上完成所有工作。
工具栈: - Claude Code (唯一主力): 使用 Max 计划，用于所有 AI 编码。 - GitHub: 作为与 Claude Code 协作的核心界面。 - Cursor / Warp: "可靠的附加功能"，但非必需。
工作流程: 1. 规划: 编码前花数小时用 Claude Code 研究代码库并制定详细计划。 2. 执行: 保持在一个终端中，"像鹰一样"监视 Claude 工作，随时准备按 Escape 键介入。 3. 互动: 频繁打断 Claude 要求解释。这虽然减慢了速度，但减少了幻觉，也提升了 Nityesh 自己的技能。 4. 审查 (GitHub 协作流): - 团队在 GitHub 中审查 Claude 创建的 PR 并逐行评论。 - Nityesh 让 Claude Code 在终端中读取这些评论。 - 人类和 AI 共同根据评论进行修复。

Nityesh Agarwal 的工作流是"极简主义"和"专注" 的典范。他的整个 Agent 工具栈都在一台 MacBook Air M1 上运行------他不需要庞大的多显示器设置。他的理念是："我是那种不喜欢经常更换工具的开发者。我喜欢一次专注于一件事。"

而他的"那一件事"就是 Claude Code。他使用的是 Max 计划，并将 Claude Code 用于他所有的 AI 辅助编码工作。他的工作流程与许多人"先写代码再修补"的方式截然相反。在编写任何"单行代码" 之前，他会花数小时时间研究代码库，并在 Claude 的帮助下，为所有功能将如何协同工作"勾勒出详细计划" 。这种"研究先行" 的方法，确保了他在开始执行时已经有了清晰的蓝图。

一旦他开始编码，他就会待在一个终端中，完全专注于手头的任务。他意识到，对他而言最有效的方法是："给 Claude 正在处理的一件事 100% 的注意力。" 他将这种专注的监督方式描述为"像鹰一样" 监视 Claude 的工作，他的手指始终放在 Escape 键上，准备在 AI 的输出看起来"不对劲"的那一刻立即介入。

最近，他实际上"缩短了对 Claude 的控制"，这意味着他会更频繁地在过程中打断 AI，并要求它"解释" 自己的行为。这种做法虽然会让开发过程"变慢" ，但带来了两个关键的回报：

AI 方面： Claude 产生的"幻觉"更少了。频繁的介入和澄清迫使 AI 保持在正确的轨道上。 2. 人类方面： Nityesh 感觉自己正在提升自己的开发者技能。通过不断审查 AI 的"思考过程"，他被迫更深入地理解代码库和解决方案。

Nityesh 工作流的另一个关键部分是 GitHub，它已经演变为他与 Claude Code 协作的核心界面。对于 Cora（Nityesh 工作的 AI 电子邮件助手）项目，工程团队会审查由 Claude Code 创建的拉取请求。团队成员们（人类工程师）会在 GitHub 的 PR 界面中逐行留下评论。然后，Nityesh 会让 Claude Code 获取并将这些评论读入终端。这样，整个团队------包括人类工程师和 AI Agent Claude Code------就可以"一起"进行所需的修复。这是一种真正意义上的"人机协作"审查模式。

思考总结

这 6 位工程师的工作流程虽然各不相同，但都有一个共同点：他们都找到了适合自己节奏和偏好的工具组合。从 Yash 的双机对比实验到 Nityesh 的单一专注策略，从 Kieran 的多层次规划到 Danny 的里程碑驱动方法，没有"唯一正确"的工作方式。

重要的是理解工具背后的思考------何时需要更多控制，何时可以让 AI 自主运行，以及如何在速度和质量之间找到平衡。在 AI 辅助开发的时代，10 倍生产力工程师不是那些使用最多工具的人，而是那些知道何时以及如何使用正确工具的人。