揭秘Every六位工程师的AI“武功秘籍”

作者：Rhea Purohit

团队中的每个人都根据自己的喜好，打造了专属的工具组合

2025年10月27日

在Every和工程师们一起工作时，我有时会好奇：他们整天到底在干嘛？写软件，就像写作一样，是一种创造性行为。这也就意味着，过程难免有些“混乱”。我写作时，会在谷歌文档和我当下最依赖的大语言模型 (LLM) 之间来回切换（目前是 GPT-5）。但对那些开发软件的人来说，这个过程又是怎样的呢？

当然，在每天的“站会” (一种短暂的团队晨会) 上我能听到他们正在交付什么产品，在我们进行“Vibe Checks” (一种快速的团队状态同步) 时，我也能窥见他们工作流的零星片段。但这些都只是冰山一角，是只言片语，远非全貌。

于是我挨个问了：我们的每位工程师，他们真正的工作流是怎样的？他们到底打造了什么样的“技术栈” (指工程师使用的工具和技术组合)，才能让区区六个人，同时运营四个AI产品、一项咨询业务，以及一份日更、读者超10万的电子报？

走在实验前沿：Yash Poojary, Sparkle 总经理

Yash Poojary 曾经是那种坚持只用一台笔记本电脑搞定所有开发的工程师。几周前，他终于“投降”了，给自己的装备里加了台 Mac Studio——也就是苹果的高性能台式机。他承认：“我本想用笔记本电脑干所有事，但在需要更快测试时，我感到了瓶颈。”

这次升级很值。现在他一台机器上跑 Claude Code，另一台上跑 Codex，给它们喂同样的提示词（prompt）和代码库，看它们如何反应。他发现这两个模型各有“性格”。Claude Code 像个“友善的开发者”，擅长分解问题、解释思路；而 Codex 则像个“技术型开发者”，更严谨、更精确，常常一次就能给出正确答案。

Yash 最近还发布了 Sparkle（我们的 AI 文件管理器）的新版本，包含一个他在 Figma (一款流行的设计软件) 上重新设计的界面。在“黑暗时代”（也就是五个月前），Yash 得把设计图截屏，然后粘贴给 Claude，让它写代码。

现在，有了 Figma MCP (一种能让AI连接并理解Figma设计文件的技术) 集成，Claude 可以直接“插上”Figma 文件，自己读取设计系统——包括颜色、间距、组件——然后把它们翻译成可用的代码。这省事多了，也保证了 Claude 始终基于那个唯一的“事实来源” (指最原始的设计文件) 来工作。

在 AI 智能体 (AI Agent) 之外，Yash 依赖 Warp——一个现代版的开发者“命令行” (就是那个黑客电影里常见的、用来输入命令的黑色文本界面)。每次他提交（push）代码，都会在一个“学习文档”里随手记下两行心得，并存到云端。几天后，他就积累了一份关于近期工作的“滚动记忆”，可以再喂给他的 AI 工具。

尽管做了这么多实验，Yash 仍强调“护栏”（guardrails）的重要性。他围绕一个大任务和几个小的后台任务来安排自己的一天，并且小心翼翼，不让 AI 生成的建议带偏自己。正如他所说：“CLIs（命令行界面）的问题在于，你很容易跑偏，忘了自己到底想干嘛……所以在系统里设置护栏至关重要。”

他自己就做了个 AgentWatch 来解决这个问题。当一个 Claude Code 会话结束时，这个应用会提醒他，这样他就能同时跑好几个会话而不会手忙脚乱。Yash 和其他一些人最近都在用它；如果你也想试试，可以私信（DM）他。

他还把一天分成两种模式：上午是专注执行——只用 Codex 和 Claude Code，不准碰新工具——保证交付不拖延。下午才是探索时间，用来试验新的 AI 智能体、应用和功能。这种“开发”和“发现”的分离，消除了他过去在测试新工具时感到的那种效率拖累。

编排闭环：Kieran Klaassen, Cora 总经理

对 Kieran 来说，Cora 的一切工作都始于一个用 Claude Code 生成的计划，这背后是一套定制的 AI 智能体和工作流。他会根据功能大小，把编程计划分成三个等级：

1. 小功能：足够简单，可以“一枪命中”（one-shot）。

2. 中等功能：跨越几个文件，需要一个审查步骤（通常由 Kieran 亲自审查）。

3. 大功能：复杂的构建，需要手动敲代码、深入研究以及大量来回沟通。

他说，做计划的意义在于让工作“立足于事实”——也就是最佳实践、网上的已知方案，以及通过 Context 7 MCP (一个能从官方源抓取最新、特定版本文档和代码示例的工具) 拽来的可靠上下文。

计划定好后，就发到 GitHub (一个代码托管和协作平台)。然后，他用一个“work”命令——这其实是个提示词（prompt），它会读取计划，并将其转换成给 AI 智能体 的编码任务。大多数项目，Claude Code 是他的首选，因为它给了他更多控制权和自主权。但他有时也会用 Codex 或 Amp 这种 AI 编码工具来处理更传统或更“硬核（nerdier）”的功能。

活干完后，他有一个命令来审查（review）代码。在这一步，Claude 仍然经常是主力，不过他也会混用其他 AI 工具，包括 Cursor 和 Charlie。这个过程会一直循环，直到 Kieran 决定这个功能可以发布了。

化繁为简，拆解里程碑：Danny Aziz, Spiral 总经理

Danny Aziz 现在的工作流几乎完全在 Droid 里跑——这是一个由 Factory（一家开发编码 AI 智能体的创业公司）开发的命令行界面，让他可以同时使用 Anthropic 和 OpenAI 的模型。他大约 70% 的工作都在这里完成：依赖 GPT-5 Codex 来构建大型功能，然后切换到 Anthropic 的模型来打磨和敲定细节。

在规划阶段，Danny 会花时间与 GPT-5 Codex “交谈”，让实施计划变得具体明确——他会问 AI 各种选择可能带来的“二阶和三阶后果” (指那些不是立即可见、但会连锁发生的深远影响)，并让 AI 把这些洞察转化为项目的里程碑。举个例子，如果 AI 智能体实现了一个功能，但它从数据库拉取数据的方式导致应用变慢了，Danny 希望能提前发现这个问题。

Droid 在帮助 Danny 构建全新版 Spiral 的过程中发挥了关键作用。其他工具基本都被他扔掉了。“我不再用 Cursor 了，”他说，“我已经好几个月没打开过它了。”取而代之的是，他的主界面是 Warp，可以在上面分割屏幕、快速切换任务。在它背后，他用 Zed ——一个轻量、快速的代码编辑器——来审阅计划文件和特定的代码片段。

至于他的办公桌配置，Danny 保持极简：绝大多数时候，他就用一个显示器，甚至只用笔记本电脑。唯一会加第二台显示器的时候，是他正埋头实现某个设计，这时把 Figma 文件和开发界面并排摆放，能让他更容易锁定视觉效果。

让流程成为唯一的“事实来源”：Naveen Naidu, Monologue 总经理

对 Naveen 来说，一切都始于项目管理工具 Linear。功能需求可能来自四面八方——Discord、邮件、Featurebase、用户访谈电话——但它们最终都会汇总到同一个地方。“如果一个东西没在 Linear 里，那它就不存在，”他说。每张任务卡（ticket）都会带上原始需求的链接，这样他总能追溯到是谁、为什么提的。

过去几周，Naveen 已经把他日常工作的主力从 Claude Code 迁移到了 Codex。

然后，Naveen 会切换到规划模式，他有两种玩法。对于小 bug 或快速改进，他会直接在 Linear 的任务卡里添加上下文，然后复制粘贴到 Codex Cloud 里启动一个 AI 智能体任务——没有花哨的集成，纯手动复制粘贴。

但对于大功能，他会跳出 Linear，进入 Codex CLI (Codex的命令行界面)，在本地写一个 plan.md 文件——这是一个简单的文本文件，充当项目的蓝图。它列出了步骤、范围和决策，并在后续与 AI 智能体迭代工作的过程中，成为那个权威的“规格说明书”。

执行阶段也兵分两路。在 Codex Cloud 里，他会头脑风暴各种方法，生成“拉取请求”（pull requests）草稿，通常不是为了合并代码，而是为了探索思路、发现边缘情况 (指那些不常见但可能导致错误的特殊情况)，并并行地获取潜在的修复方案。他更喜欢云端，因为这让他可以异步启动后台任务，无论是在 iOS 的 ChatGPT 应用上还是在网页上。

一旦他对某个方向有了信心，他就会转到 Codex CLI 进行“动真格的”开发，在 Ghostty（他偏爱的终端）里不断完善 plan.md，让 AI 智能体一步步驱动文件编辑，同时他会密切关注 AI 智能体的工作。在此过程中，他使用 Xcode 进行 macOS 原生开发，使用 Cursor 进行后端工作。与 Linear、Figma 和 Sentry (一个错误追踪工具) 的 MCP 集成，让问题、设计和错误追踪始终保持在工作闭环内。

对 Naveen 而言，代码审查自成一派。首先，他运行 Codex 内置的 /review 命令，进行自动扫描，找出明显的 bug 或问题。然后，他自己再通过并排比较“修改前”和“修改后”的代码来二次检查。当修复 bug 时，他还会多做一步：查看 Sentry 里的错误日志，对比修改前后的数据，确保问题发生的频率真的降低了。

Naveen 的工具栈里还穿插着一个他自己开发的工具：Monologue。这是一款语音转文本应用，由 Every 内部孵化，并于上个月刚刚发布。他用它来口述提示词、撰写任务描述、更新他的计划——把他的想法转化成 AI 智能体 的上下文。你也可以试试看。

钻研打磨，精益求精：Andrey Galko, 工程主管

Andrey Galko 的工作流很简单。他不是那种追逐每一个“闪亮新工具”的开发者——而在 AI 领域，这样的工具可太多了。如果一个东西好用，他就会一直用下去。

在很长一段时间里，这意味着他一直用 Cursor，他至今仍称其为市面上用户体验（UX）最好的工具。但当这家公司改了定价后，他发现自己一周就把月度用量给耗尽了，迫使他另寻他法。

他在 Codex 找到了答案（而且如果 Codex 没发布，他很可能就付费继续用 Cursor 了）。Andrey 说，在相当长一段时间里，OpenAI 的模型生成的代码都不咋地（suboptimal）。它们生成的代码片段虽然“技术上可行”，但与现有代码库的风格不一致，会跳过步骤，感觉“懒洋洋的”。

接着，GPT-4.5 和 GPT-5 来了，情况变了：模型开始能读懂代码，并且能一路完成任务，直到做出一个可用的“最小可行产品” (MVP, Minimum Viable Product)。

Codex 过去一直擅长“非视觉逻辑”——也就是那些软件在幕后运行的规则和流程，而不是你点击的用户界面（UI）——而当 GPT-5-Codex 问世时，它终于也搞定了用户界面。Claude 也许仍能生成更有创意（有时是过于有创意）的 UI，但 Andrey 发现已经没必要在两者之间换来换去了。“我为 OpenAI 的伙计们鼓掌，他们真的威胁到了 Anthropic 在代码生成领域的统治地位，”他说。

专注其一：Nityesh Agarwal, Cora 工程师

Nityesh Agarwal 喜欢让一切保持“紧凑、专注、整洁”。他整套 AI 智能体（agentic）工具栈都在一台 MacBook Air M1 上运行——完全不需要大显示器。“我是那种不喜欢频繁更换工具的开发者，”他说，“我喜欢一次只专注做一件事。”

而那“一件事”，就是 Claude Code。他用的是 Max 套餐，他所有的 AI 辅助编码都靠它。在写下第一行代码之前，他会花上好几个小时，在 Claude 的帮助下，研究代码库并草拟一份详尽的计划，规划一切该如何运作。

一旦开始编码，他就待在一个终端窗口里，像激光一样专注，只处理手头的任务。“我意识到，对我最有效的方式，就是百分之百地专注于 Claude 正在处理的那一件事，”他说。如果中途冒出一个研究性问题，他可能会在单独的标签页里快速开个会话，但原则上，他会避免同时“耍”多个 AI 智能体。

他喜欢“像老鹰一样”紧盯着 Claude 的工作，手指时刻悬在 Escape 键上，一旦发现不对劲就立马介入。

最近，他甚至把 Claude 的“缰绳”拉得更短了，经常在它干到一半时打断它，要求它做出解释。这虽然拖慢了进度，但有两方面的好处：Claude 产生“幻觉” (指AI模型一本正经地胡说八道) 的情况变少了，而且 Nityesh 感觉自己作为开发者的技能也更敏锐了。“我意识到我过去太信任 Anthropic 了，这让我变得很被动，”他承认道。当 Claude 宕机了两天，他试了试别的工具，但没有一个能比得上他用惯了的。“Claude Code 真是把我惯坏了，”他说，“所以现在我只能祈祷它别再出岔子了。”

Nityesh 工作流的另一个关键部分是 GitHub，它已经成了他与 Claude Code 协作的一个界面。在 Cora（Nityesh 参与开发的 AI 邮件助手）项目中，工程团队会审查 Claude Code 创建的“拉取请求” (Pull Request，一种请求合并代码的机制)。他们在 GitHub 里留下逐行评论，然后让 Claude Code 获取并读取这些评论到终端里，这样整个团队（包括人类工程师和 Claude Code）就能一起完成修改。

至于其他工具，Nityesh 称 Cursor 和 Warp 是“很不错的锦上添花”，但如果明天就用不了了，他也不会觉得有什么大不了。