# Building Beautiful Context：把 Context 做漂亮 - URL: https://os.klynwuu.xyz/posts/building-beautiful-context?lang=zh - Author: Hong (克林) — https://os.klynwuu.xyz/readme - Published: 2026-07-12 - Language: Chinese (zh-CN) - Tags: ai, product-management, work - Translation: AI-translated from English, not yet reviewed by the author > 最近在忙什么——以及为什么我觉得，这是我做过最有价值的东西。 ![Building Beautiful Context 封面：蓝色背景上的 context 循环图。](https://os.klynwuu.xyz/images/building-beautiful-context/cover.jpg) 最近在忙什么——以及为什么我觉得，这是我做过最有价值的东西。 过去一个月，我一直在自己的工作环境里构建 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，我拍了一支短片，整支片子都是为了最后那一句话： [Klyn 在纽约一栋楼的天台上，给出 beautiful context 的定义](https://os.klynwuu.xyz/media/posts/building-beautiful-context/beautiful-context-definition.mp4) Beautiful context 是一种策展（curation）：用最少的一组高信号信息，让正确的结果变得可能。相关性胜过数量，新鲜度胜过完整性。它是恰到好处的约束。 ## 人类历史上最美的一份 context 在讲我们怎么实现之前，先给你看看灵感从哪来——这是我个人最喜欢的例子，我甚至觉得，它是人类拼出过的最美的一份 context。 [旅行者号探测器上的金唱片：一份实体化的人类文明 context](https://os.klynwuu.xyz/media/posts/building-beautiful-context/golden-record.mp4) 1977 年，[@NASA](https://x.com/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](https://x.com/chamath) 的 [@8090_Factory](https://x.com/8090_Factory) Backpropabagation。 **Agentic tools，而不是 MCP。** 时髦的做法，是把一大堆 API 接口直接丢给模型。我们反其道而行：教 agent _流程_——一些小的、有版本号的 recipe，把“我们这里是怎么做事的”编码进去。工具目录给模型的是能力，agentic tools 给它的是你们团队的判断力。把整栋楼的钥匙交给一个人，和把一本运营手册交到对方手里，是两回事。灵感来自 [@Spotify](https://x.com/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](https://engineering.atspotify.com/2026/5/spotify-ads-api-claude-plugins) 这是整个架构，放在我能公开的颗粒度上： ![Context 循环：来自 Slack、Google Docs 和 GitHub PR 的信号，由 agent 提炼成 working context，并经过 PM 把关进入 baseline context；两者组成 context layer，服务团队和每一个 AI 工具，而反向传播把上线的工作变成明天的信号。](https://os.klynwuu.xyz/images/building-beautiful-context/loop-diagram.jpg) _一个为企业产品开发策展 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 Agent 的 Slack Bot，开放 beautiful context](https://os.klynwuu.xyz/media/posts/building-beautiful-context/slack-context-agent.mp4) 同样常见的情况是，它根本不亲自干活，只是*提供* context——工程师把相关的那一块拉出来，直接喂给 Claude Code、GPT，或者当天在用的任何 AI 工具。Slack 里的这个 agent，只是 context layer 的消费者之一，长得最友好的那一个。这一层本身在设计上就和工具无关：策展一次，到处消费。 [Slack 里的 Context Agent 正在检索 context](https://os.klynwuu.xyz/media/posts/building-beautiful-context/context-search.mp4) 注意图里*没有*什么：没有新的数据库，没有新的目的地，承重的位置上也没有任何供应商的名字。底下的模型都是可替换的引擎；工厂、循环和 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 上阅读 ↗](https://x.com/klynwuu/status/2076467905894433059)