Go back

六位工程师的 AI 辅助开发工作流深度解析

Published:  at  12:00 AM

六位工程师的 AI 辅助开发工作流深度解析

在 AI 驱动软件开发的时代,工程师的工作方式正在发生根本性变革。Every 团队仅用六名工程师就维护着四款 AI 产品、一个咨询业务以及每日触达超过 10 万读者的技术通讯。这看似不可能完成的任务背后,隐藏着一套精心打造的 AI 辅助开发工作流。

本文将深入剖析这六位工程师的日常工作方式,揭示他们如何根据个人习惯和项目特点定制工具栈,以及这些实践如何帮助小团队实现大规模产出。

AI 代理时代的工程实践范式

传统软件开发中,工程师的工作主要围绕编写代码、调试问题和维护系统展开。而在 AI 代理的参与下,开发流程已经演变为一种”人机协作”的新模式:工程师更多地扮演”架构师”和”审查者”的角色,通过自然语言与 AI 沟通需求,让 AI 执行具体的代码实现,然后人类负责验证和优化。

这种转变带来三个核心变化:

规划能力成为核心竞争力。工程师需要将复杂需求拆解为清晰的执行步骤,因为 AI 代理的表现高度依赖输入的质量。一个结构良好的计划能让 AI 更准确地理解意图,减少返工次数。

工具选择高度个性化。不同于传统开发环境的标准化配置,每位工程师都会根据项目类型、个人偏好和任务特点选择不同的 AI 工具组合。Claude Code、Codex、Cursor 等工具各有所长,工程师需要理解它们的优缺点并灵活组合。

审查机制变得至关重要。AI 生成的代码并非总是正确或最优,工程师需要建立系统性的审查流程,既要防止明显错误,也要确保代码符合项目的架构规范和性能要求。

Yash Poojary: 在前沿实验的探索者

作为 Sparkle(AI 文件整理工具)的负责人,Yash Poojary 代表了一类”实验型”工程师——他们热衷于尝试最新工具,并通过对比测试找到最佳实践。

双机对比测试策略

Yash 的工作台配置独具特色:一台 MacBook 笔记本加一台 Mac Studio 高性能台式机。这不是简单的算力扩展,而是他精心设计的”对照实验平台”。

他会在两台机器上同时运行 Claude Code 和 Codex,向它们输入相同的提示词和代码库,然后对比两者的输出。通过大量测试,他总结出两个 AI 模型的”性格差异”:

这种对比测试方法论值得借鉴。在 AI 工具快速迭代的背景下,通过实证方法评估不同工具的适用场景,比盲目跟风或固守单一工具更加高效。

Figma MCP 集成的实践价值

Yash 在重构 Sparkle 界面时,充分利用了 Figma MCP(Model Context Protocol)集成。这个技术细节背后蕴含着重要的工程理念转变。

传统流程中,工程师需要手动将设计稿截图,粘贴到 AI 对话中,然后让 AI 根据图片理解设计意图。这种方式存在两个问题:一是信息丢失(颜色值、间距等精确参数难以从截图中提取),二是工作流断裂(需要在 Figma、截图工具和 AI 界面间频繁切换)。

而 Figma MCP 允许 Claude Code 直接读取 Figma 设计文件,包括设计系统的所有参数——颜色、字体、组件、间距规范等。AI 可以基于这些结构化数据生成代码,确保实现与设计的一致性。这不仅提高了效率,也减少了人为传达设计意图时的误差。

这种”让 AI 直接访问真实数据源”的模式是未来趋势。相比让 AI 理解二手信息(截图、文字描述),直接连接原始数据能显著提升 AI 的输出质量。

防止工作流失焦的系统性方法

Yash 强调了一个容易被忽视的问题:AI 工具可能导致注意力分散。当命令行界面(CLI)中运行 AI 代理时,AI 可能会建议各种”有趣的”优化或功能,这些建议虽然有价值,但会偏离当前的核心任务。

他的应对策略是建立明确的任务边界:

  1. 时间分区制度:早上是”执行模式”,只使用 Codex 和 Claude Code 完成既定任务,不允许引入新工具。下午是”探索模式”,可以自由尝试新的 AI 代理、应用和功能。这种分离确保了产品交付不会因实验而延迟。

  2. 任务结构化:每天设定一个主要任务和若干次要背景任务。主要任务获得全部注意力,背景任务只在主任务进展顺利时处理。

  3. 技术辅助工具:他开发了 AgentWatch 应用,当 Claude Code 会话完成时发送通知,允许同时运行多个会话而不丢失进度。这解决了并行工作时的上下文跟踪问题。

Yash 还维护一个”学习文档”(learnings doc),每次提交代码后记录两行关键收获,存储在云端。几天后,这些零散的学习笔记汇聚成为丰富的上下文,可以反馈给 AI 工具,帮助它们更好地理解项目历史和决策逻辑。

Kieran Klaassen: 流程编排的大师

Kieran 负责 Cora(AI 邮件助手)的开发,他的工作方式体现了”系统化”和”自动化”的极致追求。他构建的不仅是代码,更是一套可重复的工程流程。

三级特性分类体系

Kieran 根据任务复杂度将功能开发分为三个层级,每个层级采用不同的处理策略:

小型特性:可以”一次性完成”(one-shot)的简单任务,通常涉及单个文件的修改或简单逻辑调整。对于这类任务,他直接使用 Claude Code 生成代码,无需复杂的计划过程。

中型特性:跨越多个文件的功能,需要一定的架构思考。Kieran 会先生成计划,然后自己进行审查,确认技术路线无误后再让 AI 执行实现。

大型特性:复杂的功能建设,涉及深度研究、架构决策和大量交互。这类任务需要 Kieran 手动参与规划,并在执行过程中与 AI 密切协作,及时调整方向。

这种分级处理避免了”一刀切”的低效。简单任务不需要冗长的规划环节,复杂任务则获得足够的思考时间。

Context 7 MCP: 接入真相的工具

Kieran 特别强调规划阶段要”基于真相”(grounded in truth),这意味着计划不能仅凭经验或直觉,而要建立在可靠的技术文档、已知的最佳实践和实际代码库的基础上。

他使用 Context 7 MCP 工具实现这一目标。Context 7 能够拉取最新的、版本特定的官方文档和代码示例,并直接注入到 AI 的提示词中。相比让 AI 依赖训练数据中的旧信息,这种实时文档检索确保了技术方案的准确性和时效性。

例如,在实现某个 API 集成时,Context 7 会检索该 API 的官方文档,包括最新的接口定义、参数说明和示例代码。AI 基于这些一手资料生成的集成代码,自然比基于”记忆”中的旧版本 API 更可靠。

循环审查机制

Kieran 的开发流程本质上是一个循环:计划 → 工作 → 审查 → 修正 → (重复审查)→ 发布。

在”工作”阶段,他根据任务性质选择不同工具:

在”审查”阶段,他同样混合使用多种工具:Claude、Cursor、Charlie 等。每个工具对代码的理解角度不同,综合多个审查结果能发现更多潜在问题。

这个循环会持续迭代,直到 Kieran 确认功能达到发布标准。重要的是,每次迭代不是简单的”修复错误”,而是通过不同视角的审查发现深层问题,如性能瓶颈、架构不一致或边缘情况处理不当。

Danny Aziz: 将复杂性转化为里程碑

Danny 负责 Spiral(内容复用工具)的开发,他的工作流几乎完全依赖 Droid——Factory 公司开发的命令行界面工具,该工具允许并行使用 Anthropic 和 OpenAI 的模型。

模型协同策略

Danny 的工具选择体现了”让专业模型做专业事”的理念:

这种”粗粒度规划 + 细粒度实现”的分工,充分利用了不同模型的强项。

里程碑驱动的项目管理

Danny 强调将复杂性转化为具体的里程碑。他不会简单地告诉 AI”实现功能 X”,而是将任务分解为可验证的检查点:

  1. 完成数据模型设计
  2. 实现核心算法
  3. 添加单元测试
  4. 优化数据库查询
  5. 集成到现有界面
  6. 进行性能测试

每个里程碑都有明确的完成标准,AI 完成一个里程碑后,Danny 会审查输出,确认无误后再进入下一个阶段。这种方式避免了”一次性完成大功能”可能导致的质量问题。

简化的工作环境

有趣的是,Danny 的物理工作环境极其简约:大多数时间只使用笔记本电脑或单显示器。只有在实现设计稿时,他才会添加第二个显示器,用于并排查看 Figma 设计和代码实现。

这种”极简主义”反映了他的工作哲学:关键不在于硬件配置,而在于清晰的思维和高效的工具流。Droid 提供的分屏功能允许他在同一界面快速切换任务视图,搭配 Zed 轻量级编辑器审查代码,这个组合已经足够支撑复杂的开发任务。

Naveen 负责 Monologue(语音转文字工具)的开发,他的核心理念是”如果不在 Linear 中,就不存在”。这句话揭示了他对项目管理的严格态度。

Linear 作为唯一数据源

在现代软件开发中,需求来源极其分散:Discord 中的用户反馈、邮件里的 bug 报告、Featurebase 上的功能建议、与用户的实时通话等。Naveen 的做法是将所有这些输入汇聚到 Linear 项目管理工具中,每个任务都包含:

这种集中化管理的好处是显而易见的:团队成员无需在多个平台间跳转,所有信息在同一个界面中可访问;任务的历史演变清晰可追溯;AI 代理也能更容易地获取完整上下文。

双轨制规划方法

Naveen 根据任务规模采用不同的规划方式:

小任务(Bug 修复、简单改进):直接在 Linear 任务中添加上下文信息,然后将任务内容复制到 Codex Cloud 启动代理任务。这是一种轻量级的处理方式,避免了过度形式化。

大任务(新功能开发):跳出 Linear,在本地创建 plan.md 文件,详细记录设计思路、技术选型、实现步骤等。这个文本文件成为”权威规范”,在实现过程中不断迭代更新。

这种双轨制避免了两个极端:对小任务过度规划导致的效率低下,以及对大任务规划不足导致的返工。

异步探索与同步执行

Naveen 将工作分为两种模式:

异步探索:在 Codex Cloud 中发起多个并行任务,用于头脑风暴、方案对比、边缘情况探测。这些任务生成的 Pull Request 通常不会直接合并,而是作为”思考材料”,帮助他评估不同技术路线的优劣。他可以在 iOS ChatGPT 应用或网页端随时发起这些探索任务,无需坐在电脑前。

同步执行:当方案确定后,切换到 Codex CLI,在 Ghostty 终端中进行真正的代码实现。这个阶段需要全神贯注,密切监督 AI 的每一步操作,及时纠正偏差。

这种”异步探索 + 同步执行”的模式极大提高了工作灵活性。探索阶段可以利用碎片时间(通勤、排队等),执行阶段则集中精力保证质量。

三层审查体系

Naveen 的代码审查过程包含三个层次:

  1. 自动化审查:运行 Codex 的 /review 命令,快速扫描明显的 bug、安全漏洞、代码风格问题等。

  2. 人工对比审查:并排查看修改前后的代码,逐行确认变更的合理性。这一步主要关注逻辑正确性和架构一致性。

  3. 生产数据验证:对于 bug 修复,他会查看 Sentry(错误追踪工具)中的日志,对比修复前后的错误发生频率,确保问题真正解决。

第三层审查尤为关键。许多工程师止步于代码审查,但真正的验证应该基于生产环境的实际表现。如果某个 bug 在日志中仍然频繁出现,即使代码看起来”修复”了,也说明问题没有真正解决。

Monologue 的自举应用

有趣的是,Naveen 在开发流程中大量使用自己开发的产品 Monologue(语音转文字工具)。他通过语音输入来:

这种”吃自己的狗粮”(dogfooding)不仅提高了他的工作效率,也在实际使用中发现产品的问题和改进方向。语音输入比打字更快,特别适合需要快速捕捉想法的场景。

Andrey Galko: 坚守有效工具

作为工程负责人,Andrey Galko 代表了另一类工程师:不追逐新潮,坚守经过验证的工具,直到有更好的替代品出现。

从 Cursor 到 Codex 的转变

Andrey 曾长期使用 Cursor,认为它提供了最佳的用户体验。但当 Cursor 改变定价策略后,他发现自己每周就会用完月度额度,这迫使他寻找替代方案。

他选择了 Codex,原因不仅是经济性,更重要的是模型质量的提升。他观察到:

Andrey 的评价颇具洞察力:“我为 OpenAI 的工程师喝彩,他们终于成为 Anthropic 代码生成统治地位的真正威胁。“这反映了 AI 工具市场的快速演变:曾经的明显差距正在缩小,工程师有了更多选择。

专注于非视觉逻辑

Andrey 指出,Codex 特别擅长处理”非视觉逻辑”——即后端业务规则、数据处理流程、算法实现等不直接呈现给用户的代码。而随着 GPT-5-Codex 的到来,它在前端界面生成方面也达到了令人满意的水平。

这种观察提示我们:不同 AI 模型的强项正在趋同,但在特定领域仍有微妙差异。工程师需要根据项目特点选择:如果主要工作是后端逻辑,Codex 可能更合适;如果需要大量创意性的界面设计,Claude 可能仍有优势。

Nityesh Agarwal: 极致专注的艺术

Nityesh 为 Cora 工作,他的工作方式与前述工程师形成鲜明对比:极简的硬件(仅一台 MacBook Air M1)、单一的 AI 工具(Claude Code)、强调一次只做一件事。

单线程工作模式

Nityesh 的理念是”100% 的注意力投入到 Claude 正在处理的单一任务上”。他避免同时运行多个 AI 代理会话,因为这会分散注意力,难以及时发现问题。

他的工作流程是:

  1. 花数小时研究代码库,在 Claude 的帮助下绘制详细的实现计划
  2. 在单个终端窗口中启动 Claude Code,全神贯注地监督其工作
  3. 随时准备按下 Escape 键中断,一旦发现不对劲立即介入
  4. 如果需要查资料,在单独的标签页快速完成,然后立即返回主任务

这种”像老鹰一样盯着”的工作方式看似保守,但在 AI 容易”幻觉”的背景下,它是一种有效的风险控制策略。

缩短 AI 的自由度

近期,Nityesh 进一步缩短了 Claude 的”缰绳”:他会在 Claude 执行过程中频繁打断,要求解释当前的思路和决策。这虽然降低了速度,但带来两个好处:

  1. 减少幻觉:AI 在被迫解释时,会重新审视自己的推理,发现逻辑漏洞的概率更高。
  2. 提升自身能力:通过理解 AI 的思考过程,Nityesh 感觉自己的编程技能在提升,而不是单纯依赖工具。

他坦言:“我意识到自己对 Anthropic 的信任过度了,这让我变得脆弱。“当 Claude Code 宕机两天时,他尝试其他工具,但发现没有一个能达到他习惯的水平。“Claude Code 把我惯坏了”,他说,“所以现在我只能祈祷它不要再出问题。”

这段自白揭示了 AI 辅助开发的一个隐患:过度依赖单一工具会创造”技术债务”。一旦工具不可用,工作流程会受到严重影响。

GitHub 作为协作界面

Nityesh 和 Cora 团队将 GitHub 变成了与 Claude Code 协作的界面。他们的流程是:

  1. Claude Code 创建 Pull Request
  2. 团队成员在 GitHub 上逐行添加评审意见
  3. 将评审意见喂给 Claude Code,让它读取并理解反馈
  4. Claude Code 根据反馈修改代码
  5. 重复审查-修改循环,直到通过

这种做法将”人类审查”无缝集成到 AI 工作流中。GitHub 的评审工具本来是为人类协作设计的,现在成为人机协作的桥梁。

工具选择的深层逻辑

纵观六位工程师的实践,我们可以提炼出关于 AI 工具选择的几个原则:

没有银弹,只有权衡

每位工程师使用的工具组合都不同:Yash 对比 Claude Code 和 Codex,Kieran 混用 Claude、Cursor、Charlie,Danny 主要依赖 Droid,Naveen 在云端和本地间切换,Andrey 专注于 Codex,Nityesh 坚守 Claude Code。

这种多样性说明:没有一个工具能满足所有场景。不同的项目类型、开发阶段、个人习惯都会影响最优工具选择。工程师需要建立自己的”工具感知能力”,理解每个工具的长短板。

工具组合的协同效应

很多工程师不是单独使用某个 AI 工具,而是构建工具栈:

这种组合不是随意拼凑,而是根据工作流程的不同阶段选择最合适的工具。关键是理解各阶段的核心需求:规划需要”预测能力”,实现需要”精确性”,审查需要”多视角”。

MCP 集成的战略价值

多位工程师提到 MCP(Model Context Protocol)集成:Yash 的 Figma MCP、Kieran 的 Context 7 MCP、Naveen 的 Linear/Figma/Sentry MCP。

MCP 的本质是让 AI 直接访问结构化数据源,而不是通过人工转述。这种”去中介化”显著提升了 AI 的理解准确度。未来,MCP 集成可能成为 AI 工具的标准配置,工程师的工作环境将是”AI + 数据源”的网状结构,而非”人 + 工具”的线性流程。

人类角色的重新定义

在这些工作流中,人类工程师的角色发生了微妙但深刻的变化:

从编码者到架构师

工程师的核心价值从”编写代码”转向”设计方案”。Kieran 的三级特性分类、Danny 的里程碑驱动、Naveen 的 plan.md,都体现了对”架构思维”的强调。好的架构设计决定了 AI 能否高效执行,以及最终产出的质量。

从实现者到审查者

Andrey 的模型质量观察、Nityesh 的”老鹰式”监督、Naveen 的三层审查,都说明审查能力变得至关重要。工程师需要能够快速判断 AI 生成代码的质量,识别潜在风险,这要求对技术有深刻理解。

从工具使用者到工具编排者

Yash 开发 AgentWatch、Naveen 的双轨制、Kieran 的循环流程,都体现了”元工作”(work about work)的重要性。工程师不仅使用工具,还要设计工作流程、构建辅助系统,让 AI 工具更好地为项目服务。

可复制的实践经验

从这些工程师的经验中,我们可以提取出一些普适性的实践建议:

建立明确的计划-执行-审查循环

无论使用什么工具,这个三阶段循环都是必要的:

  1. 计划:将需求拆解为清晰的步骤,准备充分的上下文
  2. 执行:让 AI 实施,但保持监督
  3. 审查:从多个维度验证输出质量

不要跳过任何一个阶段。计划不足会导致 AI 理解偏差,监督缺失会让错误积累,审查遗漏会将问题带入生产环境。

投资于工具理解,而非盲目追新

Andrey 的经验告诉我们:不要因为工具”热门”就使用它,而要评估它是否真正解决了你的问题。投入时间深度理解手头工具的能力边界,往往比频繁更换工具更有价值。

构建个人知识库

Yash 的学习文档、Naveen 的 plan.md、Kieran 的 GitHub 集成,本质上都是在构建”可被 AI 读取的知识库”。这些文档不仅帮助人类记忆,更重要的是为 AI 提供了高质量的上下文。

建议每个工程师建立:

这些内容可以在与 AI 交互时引用,确保 AI 的输出符合项目标准。

实践”吃自己的狗粮”

Naveen 使用 Monologue 辅助开发 Monologue,这种自举实践能快速发现产品问题。如果你的产品是开发工具或生产力工具,自己先成为重度用户,体验会直接转化为产品改进方向。

保持技术敏感度

Nityesh 刻意要求 Claude 解释推理过程,以避免自己的技能退化。在 AI 越来越强大的背景下,保持对技术细节的理解仍然重要。建议定期进行”无 AI”编码练习,确保基础能力不丢失。

组织层面的启示

从 Every 团队的整体实践来看,小团队高效运作需要几个要素:

工具自治与经验共享的平衡

Every 没有强制统一的工具栈,每个工程师可以根据任务选择工具。但同时,团队内部有大量的经验分享:通过站会、内部文章、Vibe Checks 等方式交流工具使用心得。

这种”自治 + 共享”的模式既保留了灵活性,又避免了信息孤岛。关键是建立定期的知识同步机制。

产品驱动的组织结构

六位工程师分别负责不同产品(Sparkle、Cora、Spiral、Monologue),这种”产品所有制”模式让每个人对自己的领域有深度理解和自主决策权。相比传统的”前端团队”、“后端团队”划分,产品制更适合小团队的敏捷开发。

持续的工具评估文化

从 Yash 的双机对比到 Andrey 的模型质量观察,Every 团队有持续评估 AI 工具的文化。这不是”为评估而评估”,而是为了在快速变化的 AI 工具生态中保持竞争力。

建议团队建立”工具评估例会”,定期讨论:

未来趋势的预见

基于这些工程师的实践,我们可以预见 AI 辅助开发的几个趋势:

AI 代理的专业化分工

未来可能出现更多专精于特定任务的 AI 代理:专门做代码审查的、专门优化性能的、专门处理安全问题的。工程师的工作会变成”指挥 AI 团队”,而不是”使用单个 AI 助手”。

实时协作的深化

GitHub 作为协作界面只是开始。未来可能出现专为人机协作设计的开发环境,实时显示 AI 的思考过程,允许人类随时介入调整方向。

上下文工程的标准化

随着 MCP 等协议的普及,“如何为 AI 准备上下文”会成为一门显学。可能出现专门的”上下文工程师”角色,负责设计和维护项目的知识图谱,让 AI 能快速理解复杂系统。

审查工具的智能化

未来的代码审查可能由专门的 AI 系统执行,它们会检查不仅是语法和风格,还包括架构一致性、性能影响、安全漏洞等深层问题。人类审查者只需关注最高层次的战略决策。

结语

Every 团队六位工程师的实践揭示了 AI 辅助开发的本质:这不是简单地”让 AI 写代码”,而是重构整个软件工程流程,重新定义人类和 AI 各自的角色,并持续优化这种协作关系。

关键要点包括:

  1. 个性化工具栈:根据任务特点和个人习惯选择工具,不盲从
  2. 结构化流程:建立清晰的计划-执行-审查循环
  3. 上下文积累:构建可被 AI 读取的知识库
  4. 持续监督:不过度信任 AI,保持批判性思维
  5. 经验共享:在团队内部交流工具使用心得

六个人维护四款产品和一个咨询业务,这在传统软件开发模式下几乎不可能实现。但通过精心设计的 AI 辅助工作流,这个小团队展现了令人印象深刻的生产力。

对于个人开发者而言,这些实践提供了可操作的改进方向:不必一次性采用所有工具,可以从建立计划文档、尝试代码审查 AI、集成一两个 MCP 工具开始,逐步构建适合自己的工作流。

对于团队管理者,Every 的经验说明:给工程师工具选择的自由度,同时建立知识分享机制,可能比强制统一工具栈更有效。

AI 辅助开发仍在快速演化,今天的最佳实践可能在几个月后就过时。但这些工程师展现的核心能力——对工具的深刻理解、结构化的工作流程、持续的学习和优化——将在任何技术变革中保持价值。

软件工程的未来不是人类被 AI 替代,而是学会与 AI 协作,将人类的创造力、判断力与 AI 的执行力、记忆力结合起来,创造出远超单方能力的成果。Every 团队的六位工程师,正在用他们的日常实践书写这个未来的早期章节。

Share this post on:
Share this post via WhatsApp Share this post on Facebook Share this post on X Share this post via Telegram Share this post on Pinterest Share this post via email
Previous Post
VS Code Copilot 计划代理：让 AI 编程更系统化的任务规划工具
Next Post
AI 能编写代码,但无法构建软件系统