简而言之： 工程师和他们的编码 Agent 写出的代码之所以偏离客户的实际情况，是因为业务上下文只存在于一个人的脑子里——也就是 FDE 的脑子里。解决办法是让客户上下文变得可查询，而不是靠人工传递。在 Aircall，工程师通过 MCP 向 Claude 查询上线相关的上下文（承诺事项、携转日期、集成决策），团队现在实现了每位工程师 3 倍的上线数量（5 → 15）。这件事的利害关系是可以量化的：30% 的开发者表示对 AI 生成的代码信任度很低或毫无信任，而上下文质量是你能掌控的最大杠杆。

你的工程师很优秀，他们的编码 Agent 速度很快，但代码交付回来仍然是错的，因为对前沿部署工程师来说，“错”很少意味着代码坏了，而是意味着技术上正确、商业上跑偏。集成处理的是客户上个季度就已弃用的 API 版本。买方在启动会上提到的边缘案例从未进入规格说明。功能比销售承诺的日期晚了一周才上线，而工程侧根本没人知道曾经承诺过日期。

这些信息都不在代码库里，而是散落在通话记录、Slack 讨论串和 FDE 的记忆中。一家垂直领域 AI 创业公司的 FDE 说得很直白：“工程师掌握的上下文和我不一样……我基本上是在充当产品经理。”我们接触过的大多数 FDE 团队都会说出类似的话。

本文讨论的正是这个鸿沟：它为何存在，编码 Agent 为何扩大了它，以及团队如何通过让工程师和 Agent 直接查询客户记忆、而不是排队等 FDE 来弥合它。这只是 FDE 团队共享上下文问题的一个切面，从工程侧来观察。

FDE 是如何变成团队的产品经理的？

没有人正式指派这个角色，它是逐渐累积起来的。FDE 参加了需求调研电话，走查了客户的工作流程，听到了关于旧系统会静默丢失字段的随口一提。而总部后方的工程师对这些一无所知。于是，每一项从客户流向代码库的工作都必须经过唯一掌握全貌的那个人，而这个人就变成了一个带着积压任务的翻译层。

传递工作：工单、证据、解读

这种传递工作有着熟悉的形态。撰写背景足够充分的 Linear 或 Jira 工单，让别人无需再开电话会就能着手处理。调取录音和日志，把“理赔团队说感觉有点慢”转化成可复现的案例。解释为什么截止日期就是截止日期。然后，在工单上回答同样的问题，在 PR 上再答一遍，到了 QA 环节还要再答一遍。

同一位 FDE 曾尝试将打包环节自动化：“把它丢给一个 Agent……把这一切变成，比如说，一个打包好的……但这还没实现。”原始素材存在于通话记录和笔记中，但从 FDE 脑海到工程师编辑器的流水线并不存在。

接力问题

一家工业 AI 公司的 FDE 描述了快递员工作的另一半：状态循环。客户问 CSM，CSM 问 FDE，FDE 问工程师，答案再沿同一条链传回去。每经过一环都会损失准确性并耗费数小时。这与实施团队付出的上下文税如出一辙，只不过是从工程师而非项目经理那里收取。

为什么编码 Agent 会让缺失的上下文变得更糟？

编码 Agent 改变了瓶颈所在。写代码变快了，但知道该写什么并没有。2025 年 DORA 报告的总结是：AI 会“放大已有的东西”，而这种放大是双向的。给 Agent 一份包含客户约束的清晰规格说明，它几分钟内就能产出有用的代码。给它一张凭记忆拼凑的工单，它产出的代码看似合理，却在业务层面自信地出错。这也是为什么仍有 30% 的开发者对 AI 生成的代码几乎没有信任或完全不信任的重要原因。

这种模式在公司层面同样存在。一项与 MIT 相关的研究发现，约 95% 的企业 AI 试点没有产生可衡量的损益影响，其解释是通用工具会陷入停滞，因为它们“不从工作流中学习，也不适应工作流”。一个无法访问客户账户中曾承诺过什么、决定过什么、冒过什么风险的编码 Agent，无论其背后的模型多么强大，都只是一个通用工具。

对于 FDE 工作来说，情况更为尖锐：领域细节就是业务逻辑。端口切换是在试点组上线之前还是之后进行，这不是细枝末节，而是代码中的一个分支。剥离这些细节，你并没有简化工单，而是删除了需求。

工程师实际需要什么上下文？

不是 CRM，也不是完整的通话记录。工程师和他们的 Agent 需要的是账户对定义共享上下文的四个问题的答案：承诺过什么、决定了什么、有什么风险、接下来做什么。

每个问题都对应一个具体的工程需求。承诺过什么是规格说明和日期。决定了什么是防止 Agent 重构掉某个刻意选择的推理依据，比如为什么这位客户用的是 webhooks 而不是轮询。有什么风险告诉工程师本周构建的哪个部分是承重墙。接下来做什么则无需开会就能确定先后顺序。

他们还需要在写代码的那一刻、在终端里获得这些信息。工程师在冲刺规划前可能会读的 wiki 页面，与编码 Agent 在会话中途能拉取的答案不是一回事。请注意，Claude Code 自身的记忆并不覆盖这一点：项目 CLAUDE.md 用于仓库约定并通过 git 传递，而自动记忆只留在一台机器上。账户状态在设计上就没有安身之处。

工程师现在从哪里获取上下文？

大多数团队混合使用四种渠道。以下是每种渠道实际能提供什么。

  • 电子表格 + Slack。工程师得到的是：状态单元格和翻找聊天记录，信息新鲜度因团队而异。编码 Agent 得到的是：什么都查不到。FDE 的代价：反复回答早已写在某处的问题，且无法量化。
  • 工单（Linear、Jira）。工程师得到的是：要做什么，很少知道为什么。编码 Agent 得到的是：工单文本，减去那些没写进去的背景。FDE 的代价：每张工单都要缓慢、仔细地撰写，之后还得再来几轮澄清。
  • FDE 的脑子。工程师得到的是：好的答案，前提是排得上队。编码 Agent 得到的是：什么都没有。FDE 的代价：每一次打断，双向皆是。
  • 共享的客户记忆。工程师得到的是：带来源的承诺、决策和风险。编码 Agent 得到的是：同样的答案，而且会话中途就能查询。FDE 的代价：从“跑腿传话”变成“维护整理”。

前三种方式并非错误，只是个人化或不完整。工单承载“做什么”。Slack 承载“为什么”的碎片。FDE 承载两者的调和，而 FDE 无法规模化。

传递上下文的实际成本究竟是多少？

每一个“快速提问”背后都隐藏着一个倍数。打断研究显示，重新回到任务的成本平均为 23 分 15 秒，而跑腿模式在两个方向上都会产生打断：工程师被阻塞等待 FDE，FDE 则被从客户构建中拉出来回答状态询问。

此外还有基于错误假设构建代码的累积成本。Stripe 2018 年的开发者研究发现，开发者平均每周已经要花费超过 17 小时处理维护问题，例如调试和重构。基于过时工单看似正确、却与客户实际情况不符的代码，会直接落入这一类，而且通常是在客户通话中才发现——那正是发现成本最高的时刻。

如何让工程师和 Agent 直接查询上下文？

跑腿模式的替代方案是一个可查询的团队记忆，工程师和编码 Agent 都能从中读取并写入。它的形态如下。

  • 把客户的真实情况集中记录在一处。通话、Slack 决策、承诺和风险都汇入一个项目大脑，而不是某个人的笔记。在 Tandem 的客户大脑中，你通过 AI 聊天界面来维护它，所以修正只需发一条消息，而不是一次“园艺整理”。
  • 把它连接到终端。MCP 是一个将 AI 应用连接到外部系统的开放标准，受 Claude、ChatGPT、VS Code 和 Cursor 支持。Tandem MCP 把大脑放在这个端口的另一端，可从 Claude、Claude Code 或 ChatGPT 访问。完整设置见通过 MCP 从 Claude Code 查询客户上下文。
  • 让 Agent 在写入之前先阅读。 在动集成之前，工程师（或 Agent 本身）会询问这次上线承诺了什么、架构上做了哪些决定、目前有什么风险。答案会附带来源返回，因此持怀疑态度的工程师可以核对原始记录。
  • 在编码会话结束时把决策推送回去。 真正的产品决策现在发生在编码会话中，如果没有人把它们移出来，它们就会死在那里。由你选择哪些内容从会话同步到团队记忆中，未经你触发，任何内容都不会移动。该工作流程在如何把产品决策从 Claude Code 会话中提取出来中有介绍。
  • 让 FDE 从信使转变为策展人。 FDE 审查流入的内容，纠正偏差，并把省下来的时间用于需求挖掘和构建。策展每周只需几分钟，而做信使每天要花数小时。

Aircall 采用的正是这种做法。工程师通过 MCP 经由 Claude 查询上线背景信息（承诺事项、号码携带日期、集成决策）。该公司的资深软件工程师 Paul Yi 这样描述效果：“我在 Claude 里问‘什么在阻碍切换’，就能得到带来源的真实答案。同样的问题，无论谁问，答案都一样。”同一个通道也支撑着 FDE 到产品的反馈闭环，因为一线的经验教训无需经过传话游戏就能到达产品团队。这也是 Tandem 如何支持 FDE 团队的核心。

仍需人工完成的部分

这里必须坦诚，因为这种模式消除的是中继传递，而不是角色本身。

FDE 仍然要做需求挖掘，也仍然要构建。与客户坐在一起就是这项工作的本质，任何记忆层都无法取代它。判断力也无法转移：两个拥有完全相同背景信息的工程师仍可能做出不同的决定，而资深工程师的判断依然更好。

同步由你在编码会话中亲自触发，由你决定什么值得保留。在每个检查点自动重新同步是我们听到过但尚未实现的需求。此外，Tandem Agent 针对账户提出的任何操作——一条消息、一次更新、一个标记——在触及客户之前都必须经过人工批准。

最后，错误的事实仍需要人来纠正。有了来源，错误可以在几秒钟内被找到，但什么是真相仍由人来判定。

从信使到策展人

我们追求的结果不是让工程师无所不知，而是让工程师和 Agent 能在需要答案的前几秒拿到带来源的答案，让 FDE 去策展记忆而不是重新输入，让代码在第一次就正确反映业务。Aircall 的成果是：在团队规模不变的情况下，每位工程师的上线次数提升了 3 倍。

看看你的工程师能省回多少时间。预约演示，观看 Tandem 在你的一个真实账户上回答“什么在阻碍上线”，并附上来源。

常见问题

编码 Agent 真的能利用业务背景信息吗？

是的，当上下文被交付到 AI Agent 工作的地方时。通过 Tandem MCP，AI Agent 在写下一行代码之前，就能像读取代码库一样查询承诺、决策和风险。Aircall 的工程师如今已在 Claude 中运行这一流程，业务成果是每位工程师的部署量提升了 3 倍。

这和写更好的工单有什么不同？

工单是 FDE 在某一时刻写下的快照，而客户情况每周都在变化。可查询的记忆在读取时是最新的，能回答工单从未预料到的后续问题，而且不需要 FDE 为每个问题花一个小时。更好的工单确实有帮助，但它们无法取代“信使”这一角色。

如果共享上下文是错的怎么办？

每条事实都带有来源，工程师可以打开原始记录或对话线程，在几秒钟内核实。更正通过聊天界面进行，之后对所有人可见。坦率地说：仍然需要由人来决定什么是真实的，这种责任不会因为任何工具而消失。

这会取代 FDE 和工程师之间的对话吗？

不会，它取代的是状态同步和背景转述。设计讨论、权衡取舍的沟通，以及“这真的是个好主意吗”这类对话仍然发生在人与人之间，而且当没有人需要花前二十分钟重建客户状态时，这些对话会变得更好。

我们只有两个人，需要这个吗？

也许暂时不需要。一个 FDE 坐在唯一一位工程师旁边，可以当面传递上下文。但当出现第二个客户、第二位工程师，或者第一个在你开会时仍在工作的编码 AI Agent 时，差距就出现了——而这通常比团队预期的来得更早。

关键术语

前沿部署工程师（FDE）： 前沿部署工程师是指大约一半时间与客户一起理解问题、另一半时间为该特定客户构建解决方案的工程师。

共享上下文： 整个团队及其 AI Agent 都可以查询的客户记忆，能够回答承诺了什么、决定了什么、有什么风险、下一步是什么，并附带来源。

项目大脑： 承载共享上下文的类目产物，是一个持续维护、来源可追溯的客户事实存储库，而不是一个文档文件夹。

客户大脑： Tandem 的产品组成部分，即项目大脑加上风险检测、Tandem AI Agent（操作需经人工批准）以及一个客户工作区。

编码 AI Agent： 一种在有限监督下编写和修改代码的 AI 系统，例如 Claude Code。它会双向放大所获上下文的质量。

MCP（Model Context Protocol）： 一种将 AI 应用连接到外部系统的开放标准，受到 Claude、ChatGPT、VS Code 和 Cursor 的支持。Tandem 的服务器名为 Tandem MCP。