拒绝瞎折腾！独家揭秘 6 位工程师的 AI 工作流：AI 开发效率翻 10 倍的核心，不是换工具而是改流程

拒绝瞎折腾！独家揭秘 6 位工程师的 AI 工作流：AI 开发效率翻 10 倍的核心，不是换工具而是改流程 拒绝瞎折腾！独家揭秘 6 位工程师的 AI 工作流：AI 开发效率翻 10 倍的核心，不是换工具而是改流程 Modified November 2, 2025 Danny 工作流中最独特的部分是他的规划阶段。他不会直接开始编码，而是会花时间与 GPT 5 Codex 交谈。这种对话不是简单的问答，而是一种深入的实施计划具体化的过程。他会主动询问他的技术选择可能带来的 二阶和三阶后果 (second order and third order consequences) 。 例如，他会探索这样的问题：如果 Agent 实现了某个功能，但由于它从数据库提取数据的方式（比如一个效率低下的 N+1 查询），是否会导致整个应用变慢？Danny 的目标是提前发现这些潜在的性能瓶颈或架构缺陷，而不是等到功能上线后才作为 bug 来修复。他让 AI 将这些深入的见解和风险分析转化为项目的里程碑。这种对话式规划将 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 (自研): 语音转文字应用，用于口述提示词、工单和计划。 • 工作流程: ◦ 运行 Codex 内置的 /review 命令自动扫描。 ◦ 手动进行之前和之后的代码对比。 ◦ (Bug 修复) 检查 Sentry 日志，确认错误率下降。 ◦ Codex Cloud (探索): 用于头脑风暴、生成 PR 草稿 (探索边缘情况)、运行异步任务。 ◦ Codex CLI (构建): 在 Ghostty 终端中，围绕 plan.md 让 Agent 驱动文件编辑。 ◦ 小 Bug: 在 Linear 中添加上下文，手动复制到 Codex Cloud。 ◦ 大功能: 在 Codex CLI 中编写本地 plan.md (蓝图)。 a. 规划 (双轨): b. 执行 (双轨): c. 审查: 他的工作流围绕一个核心原则展开： 流程即是真相来源 。对他而言，这个真相来源就是项目管理工具 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: 可靠的附加功能，但非必需。 • 工作流程: ◦ 团队在 GitHub 中审查 Claude 创建的 PR 并逐行评论。 ◦ Nityesh 让 Claude Code 在终端中读取这些评论。 ◦ 人类和 AI 共同根据评论进行修复。 a. 规划: 编码前花数小时用 Claude Code 研究代码库并制定详细计划。 b. 执行: 保持在一个终端中，像鹰一样监视 Claude 工作，随时准备按 Escape 键介入。 c. 互动: 频繁打断 Claude 要求解释。这虽然减慢了速度，但减少了幻觉，也提升了 Nityesh 自己的技能。 d. 审查 (GitHub 协作流): Nityesh Agarwal 的工作流是极简主义和专注的典范。他的整个 Agent 工具栈都在一台 MacBook Air M1 上运行——他不需要庞大的多显示器设置。他的理念是：“我是那种不喜欢经常更换工具的开发者。我喜欢一次专注于一件事。” 而他的“那一件事”就是 Claude Code。他使用的是 Max 计划，并将 Claude Code 用于他所有的 AI 辅助编码工作。他的工作流程与许多人先写代码再修补的方式截然相反。在编写任何单行代码 之前，他会花数小时时间研究代码库，并在 Claude 的帮助下，为所有功能将如何协同工作勾勒出详细计划 。这种研究先行的方法，确保了他在开始执行时已经有了清晰的蓝图。 一旦他开始编码，他就会待在一个终端中，完全专注于手头的任务。他意识到，对他而言最有效的方法是：“给 Claude 正在处理的一件事 100% 的注意力。” 他将这种专注的监督方式描述为“像鹰一样” 监视 Claude 的工作，他的手指始终放在 Escape 键上，准备在 AI 的输出看起来“不对劲”的那一刻立即介入。 最近，他实际上缩短了对 Claude 的控制，这意味着他会更频繁地在过程中打断 AI，并要求它解释自己的行为。这种做法虽然会让开发过程变慢，但带来了两个关键的回报： 1. AI 方面： Claude 产生的幻觉更少了。频繁的介入和澄清迫使 AI 保持在正确的轨道上。 2. 人类方面： Nityesh 感觉自己正在提升自己的开发者技能。通过不断审查 AI 的思考过程，他被迫更深入地理解代码库和解决方案。 Nityesh 工作流的另一个关键部分是 GitHub，它已经演变为他与 Claude Code 协作的核心界面。对于 Cora（Nityesh 工作的 AI 电子邮件助手）项目，工程团队会审查由 Claude Code 创建的拉取请求。团队成员们（人类工程师）会在 GitHub 的 PR 界面中逐行留下评论 。然后，Nityesh 会让 Claude Code 获取并将这些评论读入终端。这样，整个团队——包括人类工程师和 Claude Code——就可以一起进行所需的修复。这是一种真正意义上的人机协作审查模式。 思考总结 这 6 位工程师的工作流程虽然各不相同，但都有一个共同点：他们都找到了适合自己节奏和偏好的工具组合。从 Yash 的双机对比实验到 Nityesh 的单一专注策略，从 Kieran 的多层次规划到 Danny 的里程碑驱动方法，没有唯一正确的工作方式。 重要的是理解工具背后的思考——何时需要更多控制，何时可以让 AI 自主运行，以及如何在速度和质量之间找到平衡。在 AI 辅助开发的时代，10 倍生产力工程师不是那些使用最多工具的人，而是那些知道何时以及如何使用正确工具的人。 这份被 1012 位读者付费订阅的 AI 周刊，今天免费了，帮你直接省下 90% 无效阅读时间 信息量很大！LangChain 与 Manus 内部关于 Agent 上下文工程的讨论会实录 Get 笔记、腾讯 ima被甩几条街？NotebookLM 的 3 个设计巧思，重新定义 AI 知识管理 这份被 1012 位读者付费订阅的 AI 周刊，今天免费了，帮你直接省下 90% 无效阅读时间 信息量很大！LangChain 与 Manus 内部关于 Agent 上下文工程的讨论会实录 Get 笔记、腾讯 ima被甩几条街？NotebookLM 的 3 个设计巧思，重新定义 AI 知识管理 Danny 工作流中最独特的部分是他的规划阶段。他不会直接开始编码，而是会花时间与 GPT 5 Codex 交谈。这种对话不是简单的问答，而是一种深入的实施计划具体化的过程。他会主动询问他的技术选择可能带来的 二阶和三阶后果 (second order and third order consequences) 。 例如，他会探索这样的问题：如果 Agent 实现了某个功能，但由于它从数据库提取数据的方式（比如一个效率低下的 N+1 查询），是否会导致整个应用变慢？Danny 的目标是提前发现这些潜在的性能瓶颈或架构缺陷，而不是等到功能上线后才作为 bug 来修复。他让 AI 将这些深入的见解和风险分析转化为项目的里程碑。这种对话式规划将 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 (自研): 语音转文字应用，用于口述提示词、工单和计划。 ◦ Linear: 项目管理中心，如果不在 Linear 中，它就不存在。 ◦ Codex (Cloud & CLI): 日常主力工具 (已从 Claude Code 迁移)。 ◦ Ghostty: 选择的终端工具。 ◦ Xcode / Cursor: 分别用于 macOS 开发和后端工作。 ◦ Monologue (自研): 语音转文字应用，用于口述提示词、工单和计划。 • 工作流程: ◦ 运行 Codex 内置的 /review 命令自动扫描。 ◦ 手动进行之前和之后的代码对比。 ◦ (Bug 修复) 检查 Sentry 日志，确认错误率下降。 ◦ Codex Cloud (探索): 用于头脑风暴、生成 PR 草稿 (探索边缘情况)、运行异步任务。 ◦ Codex CLI (构建): 在 Ghostty 终端中，围绕 plan.md 让 Agent 驱动文件编辑。 ◦ 小 Bug: 在 Linear 中添加上下文，手动复制到 Codex Cloud。 ◦ 大功能: 在 Codex CLI 中编写本地 plan.md (蓝图)。 a. 规划 (双轨): b. 执行 (双轨): c. 审查: ◦ 运行 Codex 内置的 /review 命令自动扫描。 ◦ 手动进行之前和之后的代码对比。 ◦ (Bug 修复) 检查 Sentry 日志，确认错误率下降。 ◦ Codex Cloud (探索): 用于头脑风暴、生成 PR 草稿 (探索边缘情况)、运行异步任务。 ◦ Codex CLI (构建): 在 Ghostty 终端中，围绕 plan.md 让 Agent 驱动文件编辑。 ◦ 小 Bug: 在 Linear 中添加上下文，手动复制到 Codex Cloud。 ◦ 大功能: 在 Codex CLI 中编写本地 plan.md (蓝图)。 a. 规划 (双轨): b. 执行 (双轨): c. 审查: 他的工作流围绕一个核心原则展开： 流程即是真相来源 。对他而言，这个真相来源就是项目管理工具 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 集成，追求的是简单、快速。 ◦ 流程： 非常直接。他直接在 Linear 工单的描述中添加必要的上下文和需求。 ◦ 工具： 他将这些信息手动复制粘贴到 Codex Cloud（网页版）中，以启动一个 Agent 任务。 ◦ 特点： 没有使用花哨的 MCP 集成，追求的是简单、快速。 • 轨道二：更大的功能 (Bigger features) ◦ 流程： 他会跳出 Linear，进入 Codex CLI（命令行界面）。 ◦ 工具： 他在本地编写一个 plan.md 文件。这个简单的 Markdown 文本文件是项目的权威规范。 ◦ 特点： plan.md 列出了所有步骤、范围和关键决策。在后续的工作中，他会不断与 Agent 迭代和完善这个文件，使其成为指导 AI 工作的核心文档。 ◦ 流程： 他会跳出 Linear，进入 Codex CLI（命令行界面）。 ◦ 工具： 他在本地编写一个 plan.md 文件。这个简单的 Markdown 文本文件是项目的权威规范。 ◦ 特点： plan.md 列出了所有步骤、范围和关键决策。在后续的工作中，他会不断与 Agent 迭代和完善这个文件，使其成为指导 AI 工作的核心文档。 2. 执行模式 (Execution Mode) • 轨道一：Codex Cloud (云端) ◦ 目的： 头脑风暴和生成拉取请求草稿。 ◦ 特点： 他在这里生成的 PR 通常不是为了最终合并，而是为了探索想法、揭示边缘情况 以及获得并行的潜在修复方案。 ◦ 优势： 他偏爱云端，因为这允许他异步启动后台任务。无论他是在 iOS ChatGPT 应用上还是在网页上，都可以随时启动一个任务，而不必占用本地机器资源。 ◦ 目的： 头脑风暴和生成拉取请求草稿。 ◦ 特点： 他在这里生成的 PR 通常不是为了最终合并，而是为了探索想法、揭示边缘情况 以及获得并行的潜在修复方案。 ◦ 优势： 他偏爱云端，因为这允许他异步启动后台任务。无论他是在 iOS ChatGPT 应用上还是在网页上，都可以随时启动一个任务，而不必占用本地机器资源。 • 轨道二：Codex CLI (本地命令行) ◦ 目的： 真正的构建 。 ◦ 流程： 他会不断完善那个 plan.md 文件，然后让 Agent 在他选择的 终端 Ghostty 中逐步驱动文件编辑 。 ◦ 工具： 在这个过程中，他使用 Xcode 进行原生 macOS 开发，使用 Cursor 进行后端工作。同时，与 Linear, Figma 和 Sentry 的 MCP 集成 会将问题工单、设计稿和错误跟踪实时连接到这个开发循环中。 ◦ 目的： 真正的构建 。 ◦ 流程： 他会不断完善那个 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，但因定价模式达到使用上限而放弃。 ◦ Codex: 当前主力。 ◦ Cursor (曾用): 曾认为是最佳 UX，但因定价模式达到使用上限而放弃。 • 工作流程: ◦ 演变: 早期 OpenAI 模型偷懒，但 GPT 4.5 和 GPT 5 改变了游戏规则，能完成端到端的 MVP 构建。 ◦ 模型选择: Codex (尤其是 GPT 5 Codex) 现在在 UI 和非可视化逻辑上都表现出色，几乎不再需要切换到 Claude。 ◦ 演变: 早期 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: 可靠的附加功能，但非必需。 ◦ Claude Code (唯一主力): 使用 Max 计划，用于所有 AI 编码。 ◦ GitHub: 作为与 Claude Code 协作的核心界面。 ◦ Cursor / Warp: 可靠的附加功能，但非必需。 • 工作流程: ◦ 团队在 GitHub 中审查 Claude 创建的 PR 并逐行评论。 ◦ Nityesh 让 Claude Code 在终端中读取这些评论。 ◦ 人类和 AI 共同根据评论进行修复。 a. 规划: 编码前花数小时用 Claude Code 研究代码库并制定详细计划。 b. 执行: 保持在一个终端中，像鹰一样监视 Claude 工作，随时准备按 Escape 键介入。 c. 互动: 频繁打断 Claude 要求解释。这虽然减慢了速度，但减少了幻觉，也提升了 Nityesh 自己的技能。 d. 审查 (GitHub 协作流): ◦ 团队在 GitHub 中审查 Claude 创建的 PR 并逐行评论。 ◦ Nityesh 让 Claude Code 在终端中读取这些评论。 ◦ 人类和 AI 共同根据评论进行修复。 a. 规划: 编码前花数小时用 Claude Code 研究代码库并制定详细计划。 b. 执行: 保持在一个终端中，像鹰一样监视 Claude 工作，随时准备按 Escape 键介入。 c. 互动: 频繁打断 Claude 要求解释。这虽然减慢了速度，但减少了幻觉，也提升了 Nityesh 自己的技能。 d. 审查 (GitHub 协作流): Nityesh Agarwal 的工作流是极简主义和专注的典范。他的整个 Agent 工具栈都在一台 MacBook Air M1 上运行——他不需要庞大的多显示器设置。他的理念是：“我是那种不喜欢经常更换工具的开发者。我喜欢一次专注于一件事。” 而他的“那一件事”就是 Claude Code。他使用的是 Max 计划，并将 Claude Code 用于他所有的 AI 辅助编码工作。他的工作流程与许多人先写代码再修补的方式截然相反。在编写任何单行代码 之前，他会花数小时时间研究代码库，并在 Claude 的帮助下，为所有功能将如何协同工作勾勒出详细计划 。这种研究先行的方法，确保了他