Every 的一篇博文，记录了他们内部 6 位工程师日常是怎么使用 AI 的，可以学习借鉴一下。这 6 个人都很厉害，撑起了 4 款 AI 产品、一个咨询业务，还有一个 10 万多读者的订阅每日更新。

第 1 位 —— 走在实验前沿：Yash Poojary, Sparkle 总经理

Yash 是 Sparkle 产品的负责人，他同时开两台电脑，一台跑 Claude Code，一台跑 Codex，然后给它们下达同一个任务，看它俩谁干得又快又好。

Yash 说，在五个月前，他得先把设计图（Figma）截图，再粘贴到 Claude 里，让它“看图写代码”。现在用上了 Figma MCP 集成，Claude 可以直接读取 Figma 的设计源文件——包括颜色、间距、组件这些。

Yash 不仅在用AI，他还在优化和AI的配合。比如，他把一天切成两半：
- 上午：专注执行。 这时候只用自己最熟的AI工具（Claude 和 Codex），绝不玩新东西，保证产出。
- 下午：自由探索。 这时候才开始测试各种新出的AI应用和功能。

他很清楚 AI 既是生产力工具，也是个“时间黑洞”。他用严格的时间管理，给自己建立了“防护栏”，防止自己沉迷于“调教AI”而忘了真正的工作。

第 2 位 —— 编排闭环：Kieran Klaassen, Cora 总经理

Kieran 负责 Cora 产品，他的风格是““谋定而后动””。

他的工作流核心就两个字：计划。

他会根据功能的大小，制定三种不同级别的编程计划。他会用一个叫 “Context 7 MCP” 的工具，先把最新的、最准确的官方文档和代码喂给AI，确保AI不是在“凭空想象”或用过时的知识来制定计划。

等Claude Code 交出一个完美的计划后，他再把计划发到 GitHub，然后在云端让 Coding Agent（主要是Claude Code）去执行这个计划。AI写完代码后，他会再启动一个““审查””命令，让AI自己先检查一遍，然后他再上手。

对 Kieran 来说，AI 不是一个“黑匣子”，而是一个必须在他制定的蓝图内严格执行的“施工队”

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

Danny 负责 Spiral 产品，他可能是这群人里最硬核的一位。

他的主战场不在花哨的图形界面，而是在一个叫 “Droid” 的命令行工具里。这个工具能让他同时调用 OpenAI 和 Anthropic 的模型。

他的工作流是：
1. 用 GPT-5 Codex 做大的任务：搭建复杂功能的框架。
2. 用 Claude 做小的任务：优化和打磨代码细节。

Danny 最有价值的一个做法是，他会在““规划阶段””花大量时间跟AI对话，让AI帮他推演一个决策可能带来的第二层、第三层后果”。

举个例子：“我要加这个新功能，但你帮我分析一下，它会不会因为从数据库拿数据的方式，导致整个App变慢？”

他用AI来辅助自己做更高维度的“架构思考”，而不仅仅是写几行代码。

> “我不再用 Cursor 了，”他说，“我已经好几个月没打开过它了。”取而代之的是，他的主界面是 Warp，可以在上面分割屏幕、快速切换任务。在它背后，他用 Zed ——一个轻量、快速的代码编辑器——来审阅计划文件和特定的代码片段。

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

Naveen 负责 Monologue 产品，他是个“程控”。他的信条是：“如果一个任务没录入 Linear (项目管理工具)，那它就不存在。”

他把所有需求和Bug都先在 Linear 里归档，然后再启动AI。他也有两套流程：
- 小Bug：直接从 Linear 复制粘贴问题描述，扔进 Codex Cloud 让AI去跑。
- 大功能：在本地写一个详细的 https://t.co/1aLAUFxX5j (计划文档)，把它作为和AI沟通的“唯一事实蓝图”，在命令行里一步步推进。

最有意思的是，他深度使用自己开发的产品 Monologue (一个语音转文字工具) 来口述需求、写文档、给AI下指令。这简直是““用自己造的锤子，来修自己的房子””。

他还有一套严格的审查标准：AI 自动审查 -> 自己人工对比代码 -> 查看Sentry（错误监控工具）的日志，确保Bug真的被修复了。

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

Andrey 是工程主管，他代表了另一种工程师：不爱折腾。

他不喜欢追逐“闪亮的新玩具”。他之前一直用 Cursor (一个AI代码编辑器)，觉得体验最好。但后来因为 Cursor 改了定价，他一周就把免费额度用完了，这才“被迫”换工具。

他换到了 Codex。他认为以前的 OpenAI 模型写的代码很“懒”，经常跳步骤，不如 Claude 好用。但现在的 GPT-5 Codex 已经进化得非常强，连以前 Claude 的强项——用户界面(UI)——都能搞定了。

第 6 位 —— 极致的专注：Nityesh Agarwal, Cora 工程师

Nityesh 是 Cora 的工程师，他的风格和第一位 Yash 截然相反。他追求极致的专注。他的装备极简（一台MacBook Air），他的工具也极简：只用 Claude Code。

但他用 Claude Code 的方式很特别：
1. 他会花好几个小时，先和 Claude 一起研究、制定一个巨详细的计划。
2. 一旦开始编码，他就待在一个终端窗口里，“像老鹰一样””盯着 Claude 输出的每一行代码，手指就悬在 Escape 键上，一旦发现不对，立刻中断它。

最近，他甚至故意频繁地打断AI，强迫AI向他解释“你为什么要这么写？”。

他承认，这样做效率变低了，但带来了两个巨大的好处：
1. AI 胡说八道（hallucinate）的次数变少了。
2. 他感觉自己的开发技能也在这个盘问 AI 的过程中变强了。

他意识到，自己已经对 Claude 产生了依赖，这让他很脆弱。前阵子 Claude 宕机了两天，他试了别的工具，都感觉不顺手。所以，他现在逼着自己和AI一起思考，而不是纯粹依赖AI。

---

看来每个人用 AI 的方式都不一样，但也有一些共同点：

1. 重点不在“写代码”，而在“做规划”

没有人真正的是在“Vibe Coding”，没有说写个提示词就完事了的，都是在 AI 干活前反复的讨论，直到清楚了再动手

2. 上下文很重要

Yash 用 Context 7 MCP 的工具，确保 AI 在写代码时，能自动去查阅最新、最官方的“技术文档”。这就避免了 AI 用过时的知识（比如一个老版本的函数）来写新代码。还会用 Figma MCP，读取 Figma 的原始设计数据，让 AI 可以直接拿到准确的颜色、间距等信息

3. 工程师的角色在进化

工程师已经不再是单纯写代码，还要做计划、写提示词、审查 AI 生成的代码

4. 专注

这个问题其实我也有感触，AI 让人更难专注了，在等 AI 结果的时候去做点其他事，很快就把任务忘记了；或者 AI 工具太多，每个新 AI 工具都去试试太费时间了。像 Yash 那样，一半时间专注交付，一半时间探索。

原文：Inside the AI Workflows of Every’s Six Engineers
https://t.co/xqTMIAxTVj

点击图片查看原图