实验项目 ContextCue：用 AI 保留跨团队协作中的上下文

O'Reilly Radar· Dhruv Deshpande·2026-10-19 18:54· 26 分钟前AI 评分46

AI 改变了我们的编码方式，却没有改变我们的协作方式。

AI 导读

开发者构建实验项目 ContextCue，用 FFmpeg、Faster-Whisper 和 Qwen VL 等工具把会议录音、屏幕共享画面与决策理由整理成可随工作流转的共享上下文。它按请求或决策而非单场会议组织输出，以 Markdown 格式保存，便于人和语言模型读取。该项目针对分布式团队在编码前耗费大量时间对齐理解的问题，目前仍是实验。

正文 · 原文

今年夏天，我构建了一个名为 ContextCue 的小型实验。这个想法源于我在实习期间反复看到的现象。我身边的工程师在软件开发流程的各个环节都在使用 AI。GitHub Copilot 和 Claude 模型帮助处理规格说明、代码、评审和测试。团队还维护了一些可复用的技能，用来教会编码智能体团队的工作方式。其中一项技能可以把 UI 设计转化为可运行的前端代码。

代码的推进速度变快了，但对代码的理解似乎并没有随之加快。这个软件由分布在三大洲的九个团队共同构建，其中一个团队与客户紧密合作。一个需求可能始于一次客户对话，经过一个团队，然后传到相隔几个时区的另一个团队。当工作到达工程团队时，最初的一些含义可能已经丢失了。

这正是我希望 ContextCue 探索的问题。ContextCue 接收会议录音，并试图保留比转录文本或摘要更多的内容。它保留了口头讨论、屏幕上重要的视觉上下文、做出的决策、决策背后的原因，以及它们的来源。目标是创建一份共享的上下文，让它能随工作从一个团队传递到另一个团队。

这仍然是一个实验，但它背后的问题感觉非常真实。据我所见，分布式软件团队在开始编码之前，会花费大量时间达成共识。AI 已经在帮助软件开发的最后阶段。我想看看它能否更早地提供帮助，在团队仍在努力理解他们要构建什么以及为什么构建的时候。

上下文在哪里消失

会议本来就在被录制，Microsoft Teams 等工具可以生成 AI 摘要。在我的团队里，这份摘要通常以电子邮件的形式送达，然后就停留在那里。对于参加会议的人来说，这已经足够好用。但对于后来接手工作的团队来说，它的用处就没那么大了，尤其是当那个团队在另一个国家、没有看到原始对话时。

还有另外两个问题。一份摘要通常只覆盖一次会议，而一个功能背后的理解往往是在多次会议中逐步建立起来的。不同团队可能相隔数天讨论同一个需求，各自添加新的约束或解读。

转录文本也可能遗漏重要的视觉上下文。我们的许多对话都涉及屏幕共享。有人可能指着某个页面说：“这太慢了”，或者在解释需要改动什么时高亮工作流的某一部分。仅凭文字并不总能承载含义。这就是我开始把上下文视为比转录文本更宏大的东西的起点。

一个简单的例子

设想一位客户要求提供一份“更快的报告”。在通话中，客户共享了屏幕，指着一个打开缓慢的页面，并解释说经理们每天早上开会前都会使用它。通话中的每个人都明白“更快”意味着页面应该更快打开。

两天后，另一个时区的另一个团队讨论了同一个请求。那次会议中没有人看到最初的屏幕。他们将“更快的报告”理解为“报告应该更快运行完成”，并开始规划后端工作。两次会议的摘要可能都包含同一句话：

让报告更快。

这句话中没有任何内容表明两个团队的意思不同。只有当客户看到结果时，问题才会显现出来。

这是一个简单的例子，但它捕捉到了我一直注意到的问题。需求在变成代码之前要经过很多人。如果在这个过程中含义发生了变化，AI 可以帮助团队非常高效地实现错误的解释。

同一问题的体育版本

体育给了我另一种思考方式。想象一场足球比赛，一名球员在最后时刻错失了进球机会。比赛报告可以记录射门、球员、分钟以及是否射正。这些事实很有用，但观看回放的教练看到的要多得多。边锋可能传球太早。后卫可能迫使前锋用较弱的脚接球。队友可能跑动拉开了空间。

事件只是故事的一部分。教练从它周围的序列中学习。

Jake M. Hofman、Daniel G. Goldstein 和 David M. Rothschild 在《哈佛商业评论》的一篇文章中使用了相关的体育框架，他们根据 AI 如何帮助人们，将其描述为类固醇、运动鞋或教练。“教练”这个想法让我印象深刻。一个有用的 AI 系统不仅帮助人们产出更多。它还可以通过呈现之前的证据和经验，帮助人们做出更好的决策。这接近我希望 ContextCue 为团队做的事情。

我构建了什么

ContextCue 从会议录音开始。FFmpeg 处理媒体，Faster-Whisper 转写语音。转录内容保留在带时间戳的片段中，以便任何后续答案都能指向某句话被说出的时刻。

系统还使用 Qwen VL 等视觉模型查看屏幕共享中的选定帧。这有助于保留那些含义取决于某人在指什么而不仅仅是他们所用词语的情况。

最终输出围绕请求或决策组织，而不是围绕会议。例如：

# 请求：更快的报告

客户的意思：
报告页面打开太慢。
来源：客户通话，屏幕上显示

为什么重要：
经理们在早会前打开它。
来源：客户通话，口头说明

计划了什么：
让报告更快运行完成。
来源：团队规划会议

未解决的问题
当前计划与原始请求不匹配。

这种格式刻意保持简单。我使用 Markdown，是因为人可以直接阅读，语言模型可以使用，而且无需依赖特殊界面就能存储或进行版本管理。当后续会议涉及同一请求时，可以更新该页面，而不是再创建一份互不关联的摘要。这就把记忆单元从会议变成了主题。

为什么这对产品工作很重要

我见过的最清晰用途之一是产品管理。产品经理在编写用户故事时，通常要综合工单、会议记录、客户反馈以及与工程师的对话。重要的细节往往分散在所有这些材料中。

如果产品经理只把最新的会议摘要交给 AI 模型，模型只能看到历史的一个片段。ContextCue 页面可以提供更多信息。页面可能包含最初的客户请求、背后的业务原因、后来提出的技术约束、产品部门的决策，以及一个仍待解答的未决问题。

这为模型创建用户故事提供了好得多的起点。模型本身没有改变，改善的是它可用来工作的材料。这是一个重要的区别，因为很多 AI 工作聚焦于提示词和模型，而上下文的质量往往决定输出是否有用。

上下文如何增长

每次新会议都可以更新现有页面或新建页面。随着时间推移，这会形成按主题记录工作演变过程的档案。这与拥有一个装满会议摘要的文件夹不同。文件夹迫使人们记住哪次会议包含了有用的细节。主题页面则把相关片段收集在一个地方。

存储的上下文还可以被搜索。我使用嵌入和 Qdrant 来检索以往会议的相关部分。像“客户说的更快是什么意思？”这样的问题，可以返回答案以及支持该答案的会议和时间戳。

其他请求需要更结构化的处理。“查找周二的会议”是一次查找。“我们为什么更改这个需求？”可能需要来自多次会议的信息。“还有什么尚未解决？”应该查找未决问题，而不仅仅是相似文本。

ContextCue 可以通过模型上下文协议（MCP）暴露这些操作，这样语言模型就能为请求选择合适的工具。重点不在于协议本身。有用的部分是，不同类型的问题可以使用不同方式访问同一份共享上下文。

为什么录制的对话值得保留

一项研究让我认为录制的对话尤其有价值。在 2025 年发表于《经济学季刊》的《工作中的生成式 AI》一文中，Erik Brynjolfsson、Danielle Li 和 Lindsey Raymond 研究了一款供客服人员使用的 AI 助手。

他们发现，技能较低和经验较少的员工提升最大。该系统似乎帮助他们更像高技能员工那样沟通。让我感兴趣的是，一些有用的知识来自过去的对话。

公司中包含大量从未成为正式文档的知识。它出现在解释、客户电话、设计讨论、示例、纠正以及会议期间做出的小决策中。录制的会议就是这类知识已经存在的一个地方。

我注意到的第一个好处是个人层面的

作为一名实习生，加入大型项目最难的部分之一，就是弄清楚事情为什么会是现在这个样子。你可以阅读代码，却仍然不知道当初为什么选择某种设计。一张工单可能只描述了要构建什么，却没有解释产生它的讨论过程。

通常的解决办法是去问别人。这往往也是正确的做法，但这也意味着要打断一个本来就有工作要完成的人。一个共享的上下文层可以让其中一些问题更容易得到解答，而无需再开一次会，也无需再跨时区发一条消息。

同样的思路也可以帮助新员工入职、减少重复会议、促进团队之间的交接，以及应对有人需要理解某个旧决策的情况。作为实习生，我能看到这些可能性，但它们仍然需要恰当的衡量。

哪些做法有效，哪些仍然困难

我目前的测试还很有限。我创建了一小组问题，并且已经知道每个问题的正确来源。在那组测试中，ContextCue 大约十次中有九次首先检索到正确的来源，并且每次都把它排在前三名结果之内返回。

这令人鼓舞，但也让问题中更困难的部分变得更加清晰。一家真实的公司可能会使用多种不同的会议工具。不同团队对于什么可以被录制可能有不同的规定。有些上下文应该在全公司范围内可见，而另一些上下文应该只保留在团队内部。人们需要知道会议何时被录制，以及这些录制内容将如何被使用。

还有一个时间问题。一个团队可能在三月做出某项决定，又在四月改变它。三月的决定不应该消失，因为它解释了团队是如何走到当前立场的。与此同时，系统应该明确表明四月的决定取代了它。

这种历史记录很有用，但它比简单的搜索更复杂。它需要围绕归属、权限、时间和信任制定规则。ContextCue 并不能解决所有这些。

这件事的走向

实习期间让我一直记在心里的，是 AI 对编码方式的改变之大，与它对编码周边交接环节的改变之小，两者形成了鲜明对比。一旦需求明确，工程师们已经拥有强大的工具。较慢的部分往往发生在那个节点之前，也就是团队试图理解一个请求、添加约束、把它交给另一个团队，并让所有人保持一致的时候。

ContextCue 是我针对流程中这一部分所做的第一次尝试。这个实验规模仍然很小，如果它真的要进入真实的企业环境，技术系统将需要改变。对我来说，有用的想法是：会议录制可以不只是存档。它们可以成为团队如何达成某项决策的共享记录。

如果 AI 能帮助保存这段历史，并在下一个团队需要时把它呈现出来，那么它可能改进的就不只是编写代码的速度。它可能改进的是团队如何在组织的不同部分之间传递理解。

来源：O'Reilly Radar · oreilly.com