Building Beautiful Context：把 Context 做漂亮

最近在忙什么——以及为什么我觉得，这是我做过最有价值的东西。

过去一个月，我一直在自己的工作环境里构建 beautiful context。

不是做 feature。
也不是又一个 AI 套壳。

而是一份 Context。

我知道这听起来像什么。现在人人都在聊 context：context engineering 是新的 prompt engineering，context window 越来越长，context is king，context 就是护城河。每条 thread、每场分享、每份 roadmap 都在说同一件事：context 很重要。

但我一直注意到一件事：人人都告诉你 context 很重要，却几乎没人告诉你，好的 context 到底是什么。我们聊怎么设计它、往里塞、压缩它、检索它——却从没停下来，给这个东西本身下个定义。Beautiful context 到底长什么样？

那我先给一个定义。为了在我所在的公司里发布一个 context agent，我拍了一支短片，整支片子都是为了最后那一句话：

Beautiful context 是一种策展（curation）：用最少的一组高信号信息，让正确的结果变得可能。相关性胜过数量，新鲜度胜过完整性。它是恰到好处的约束。

人类历史上最美的一份 context

在讲我们怎么实现之前，先给你看看灵感从哪来——这是我个人最喜欢的例子，我甚至觉得，它是人类拼出过的最美的一份 context。

1977 年，@NASA 在两艘探测器的侧面各绑上一张镀金唱片，把它们扔向了星空。那不是人类知识的备份：没有百科全书，没有教科书。一个小小的委员会问了一个几乎无法回答的问题——如果只能寄出真正重要的那部分，你会寄什么？——然后给出了答案：55 种语言的问候、巴赫、一段心跳、鲸鱼的歌声，还有 116 张告诉对方“我们是谁”的图片。

一次策展。一组最少的高信号信息。在无尘室里亲手装载，寄给一个外来的智能（foreign intelligence）。

在这个词上多停一秒，因为整个想法都在里面。你的团队用的每一个 AI，恰恰就是这样一种外来的智能：它来的时候什么都懂一点，唯独对你一无所知。不知道你的战略，不知道你做过哪些决定，不知道你为什么在三月砍掉了那个 feature，也不知道在你的团队里，“好”到底意味着什么。模型有知识，但它没有你的 context。

而 context，是唯一真正属于你的那部分。

为什么 builder 需要 context layer

在产品开发里，这道鸿沟每天都在出现。设计师、工程师和 stakeholder 各自握着真相的一块碎片：战略在一份 deck 里，决策在某个人的脑子里，约束藏在一条谁也找不到的 thread 里。传统做法是让一个人站在交汇点上，靠说话把这些全部传递出去——Brian Armstrong 曾经告诉新入职的产品经理，他们的工作就是当沟通枢纽（communication hub），成为产品一切事务的对接人。

他说得对。但在 AI 时代，这只是下限，不是上限。沟通是在路由信息：靠推送、要同步、话一出口就开始衰减。同一套理由你在四个会上讲四遍，它照样会蒸发。沟通枢纽的上限，就是你的日历。

所以我们做了一次升级：一个 context layer——一个把策展好的 context 开放给整个团队的 AI agent。我们的这个 agent 是一只住在 Slack 里的章鱼（这个选择背后是一款 1988 年的 Konami 游戏，看片子就知道了）。问它一个问题，它会按你的角色来回答：前端工程师、后端工程师和设计师，各自拿到同一份真相里属于自己的那一块。团队用的每一个 AI 工具——coding agent、设计工具——也都在和它对话。这才是重点：它不只是让人和人对齐。它一步到位，就是企业的 AI 战略，因为它赋能的是真正动手做东西的人。

有三个设计决策，决定了我们怎么搭它：

Context as a Service Layer。 像流水线一样制造软件的梦想，基本上失败了——代码原来是一门手艺。但 context 是可以被制造的：每天按计划清扫、提炼、对账、过质检。这座工厂不生产产品，它生产的是共识，产品再从这份共识里被做出来。

组织的反向传播（Backpropagation）。 这是直接从神经网络的学习方式借来的：结果向后传播，更新权重。在我们这里，上线的代码会反向传播回产品 context——每一个合并的 PR，都会被翻译成“这对产品意味着什么”；经得起时间的经验，会被提议回上游，进入 ground truth。Context layer 不只是从战略向团队单向往前流，它还会从真正上线的东西里反向学习。正是这一点让它保持新鲜，而不是慢慢漂移成虚构。灵感来自 @chamath 的 @8090_Factory Backpropabagation。

Agentic tools，而不是 MCP。 时髦的做法，是把一大堆 API 接口直接丢给模型。我们反其道而行：教 agent 流程——一些小的、有版本号的 recipe，把“我们这里是怎么做事的”编码进去。工具目录给模型的是能力，agentic tools 给它的是你们团队的判断力。把整栋楼的钥匙交给一个人，和把一本运营手册交到对方手里，是两回事。灵感来自 @Spotify 的 Building a Natural Language Interface to the Spotify Ads API with Claude Code Plugins | Spotify Engineering：https://engineering.atspotify.com/2026/5/spotify-ads-api-claude-plugins

这是整个架构，放在我能公开的颗粒度上：

一个为企业产品开发策展 context 的 LOOP

信号诞生在工作本来就发生的地方——Slack、Google Docs、GitHub PR。一个 agent 每天把它们提炼一遍，每条都附出处，不确定的改动一律拒绝。产出落进两个以不同速度运转的存储里：working context（这周成立的事实，自动更新）和 baseline context（长期成立的事实——agent 在这里只能提议修改，每一条都要人来批准）。两个存储都只是 GitHub repo 里的 markdown——有版本、能 diff、能像代码一样 review。然后这一层再回过头服务团队和每一个 AI 工具，团队带着它把东西做出来，而做出来的东西，又成了明天的信号。

Working context 是自动化的，ground truth 是挣来的。而让它一直成立的，是这个循环。

那团队实际上怎么用到它？在内部，我们通过一个 Slack bot 来开放这一层——也就是那个 context agent。它在回答任何问题、执行任何 agentic 任务之前，都会先加载相关的项目 context。这个顺序就是全部的诀窍：它从不在一张白纸上推理，而是从策展过的记录出发。问它一个产品问题，或者丢给它一个任务，它都会从我们知道什么、决定了什么、以及为什么这样决定开始。

同样常见的情况是，它根本不亲自干活，只是提供 context——工程师把相关的那一块拉出来，直接喂给 Claude Code、GPT，或者当天在用的任何 AI 工具。Slack 里的这个 agent，只是 context layer 的消费者之一，长得最友好的那一个。这一层本身在设计上就和工具无关：策展一次，到处消费。

注意图里没有什么：没有新的数据库，没有新的目的地，承重的位置上也没有任何供应商的名字。底下的模型都是可替换的引擎；工厂、循环和 recipe，才是我们自己的。

真正改变了什么

三件事，连我自己都有点意外。

对齐变成了环境的一部分。 团队不再在会上反复争论优先级，因为答案在哪里都一样——它来自同一个策展过的地方，按角色切好。

Token 变得划算了。 平均 token 用量明显下降，因为 AI 工具不再每个 session 都烧 token 去重新挖掘同样的背景。Beautiful context 是真的更便宜——相关性胜过数量本身就是一个成本函数。工程师现在把 token 花在做 feature 上，而不是资助考古。

质量上去了。 回答、生成的代码、PR——都好了一大截，因为模型终于知道了那些前提：指标的定义、做过的决策、存在的约束。引擎还是同样的引擎，燃料更好了。

培养你自己的 context

下面才是我真正希望你带走的部分——不管你经营的是一家公司、一个团队，还是只有你自己和一台装满 AI 工具的笔记本：

培养你自己的 context。

模型会一直变——把它们当成可以互换的引擎。如果你的判断力住在你的 context layer 里，你就能随意更换引擎；如果它住在你对某一家厂商产品的使用习惯里，那你就不是他们的客户，而是他们的训练数据。

每家公司、每个团队、每个人，都应该策展一张属于自己的金唱片——关于自己怎么工作、做过什么决定、什么最重要的那一组最少的高信号信息——寄给下一个和你一起做东西的外来智能。

这就是我最近在忙的事：构建 beautiful context。

下一篇：它到底是怎么搭起来的——记忆架构、pipeline 的机制，以及一路上踩过的坑。记得带杯咖啡。🐙

原文以 X Article 形式发表于 2026 年 7 月 12 日。 在 X 上阅读 ↗