AI Native Dev: Drew Knox 演讲全文转录 — Context as Code

演讲者：Drew Knox — Tessl 产品设计负责人（前 Grammarly 语言模型团队研究科学家） 活动：AI Native Dev 时长：29:36 来源：YouTube 观点提炼：深度分析与编者观点

引言：Drew Knox 的背景介绍

时间: 00:00:01 - 00:01:33

我们实际上已经拥有通用的 agentic 开发机器 50 年了——我们只是把它们叫做"软件工程师"。你不会只给某人发条 Slack 消息，就指望他们去构建整个系统并做出所有最佳决策，对吧？

好的，很高兴认识大家。我是 Drew Knox，Tessl（一家 AI 开发工具公司）的产品和设计负责人。今天我要分享的是如何用更专业、更严谨的软件工程思维来使用 Skills（结构化 AI 指令文件）。

在此之前，为什么你们应该相信我？嗯，第一，也许不要完全信任我，保持点怀疑精神。但在加入 Tessl 领导产品和设计之前，我曾是 Grammarly 语言模型团队的研究科学家，也在一家叫 Cantina 的社交网络 AI 初创公司工作过（遗憾的是它还没有成功）。我在开发者工具方面做了大量工作，也经常自己写代码——当然质量可能比不上 Tessl 团队的真正工程师们。所以我对这个话题思考了很多，也做了很多实践。我很乐意分享一些见解，也非常欢迎提问和交流大家的经验。我会尽量留出充足的问答时间，那么我们开始吧——你想在 Skills 上下功夫，更广义地说，你想在 Agent 的 Context 上下功夫。

Context Engineering 的时代

时间: 00:01:33 - 00:04:17

相信大家都听说过 Context Engineering（上下文工程）。感觉每年都会有人告诉我们"今年是某某某之年"。有人说今年是 Context Engineering 之年，也许是，也许不是。当你开始做 Context Engineering 时，你可能会经历类似于"否认—接受"的几个阶段：先是觉得"这太棒了，效果真好"，然后突然变成"天哪，这东西到底怎么运作的？真的有用吗？我以为自己是工程师，现在感觉更像艺术家或图书管理员。我怎么才能把 Agent、Context Engineering 这些东西重新变回我所熟悉和热爱的那种可靠、可预测的工程？"

那我们该怎么做呢？我认为首先要认清一件事——大家如果还没有这个概念的话——我们之所以现在都在做 Context Engineering，是因为我们实际上都从 IC（Individual Contributor，个人贡献者）变成了 Tech Lead（技术负责人）。某种意义上说，工作不再是写好代码，而是确保好代码能被写出来——这些事情 Tech Lead 们早就知道并且爱着（或恨着）了：维护良好的标准、做好决策、写好文档、为团队其他成员提供上下文、设定质量门槛。我们现在做的是同样的事情，只不过对象变成了 Agent。

所以 Context 在某种意义上就是我们的新代码。

有些人可能不喜欢这个说法，请把它当作一个比喻。如果 Context 是我们的新代码，那我们对代码有什么期望呢？我们想知道：我的程序是否正确？性能如何？怎么复用？怎么自动化那些恼人的重复任务？对于真正的代码，我们已经有了很多答案——单元测试、集成测试、分析和可观测性，这些工具让我们对程序的运行有了深入了解。

今天我想论证的核心观点是：所有这些在代码世界里的工具，在 Context Engineering 的世界里都有对应物。 如果你认真地去找到一套这样的工具集，你就能重新获得代码所带给你的那种可预测性和严谨性。我会用 Tessl 来演示这些概念，但你不一定要用 Tessl——这些是通用的概念和模式。

三大挑战与 SDLC 类比

时间: 00:04:18 - 00:08:47

在正式开始之前，有三个挑战使得 Context 和传统代码不是完全对等的比较。

第一，LLM 是非确定性的。 你不能只跑一次就说"哦，它成功了"或"哦，它失败了，所以我知道我的 Context 不行"。当你让一个 Agent 去做某件事时，有时候它会做到，有时候不会——我相信大家都体会过这种痛苦。

第二，很多时候创建 Context 没有唯一正确答案。 如果你写了一个风格指南或一个库的文档，你怎么判断 Agent 的解决方案是否正确？你不能只写个单元测试就说"搞定了，它通过了"。所以输出的评分可能有些挑战。

第三，有一个新问题：你的"程序"现在实际上是在描述其他东西。 所以你需要保持同步。比如你更新了 API，就需要同步更新文档；或者在某处改变了公司流程，要确保它被分发到整个组织。

接下来是一个快速概览。我会逐一深入每个类比。我承认我可能把这个类比做得太精巧了，但我确实认为软件开发生命周期（SDLC）中的每个工具都有一个直接的 Context 类比。

• 静态分析 → 用 LLM-as-Judge 做 Context 的 Linting 和验证。比如我们最近看到一个客户在 Tessl 上不小心在文件里加了个 @ 符号，触发了大多数 Agent 的 import 机制，搞坏了一大堆 Context 都没意识到。看似愚蠢，但静态验证仍然很重要。
• 单元测试 → 设计压力测试 Agent 的场景，并行运行多次，取统计平均值。看添加 Context 后是否真的提升了平均性能。这可能是感觉最不一样的——但你仍然可以获得相当可靠的结果。
• 集成测试 → 同样的思路，但测试多种 Context 一起使用的场景。
• 分析和可观测性 → 测量 Agent 在真实环境中的会话，看是否缺少 Context，是否被正确使用等。
• 自动化构建脚本 → 让 Context 不是一个静态的、逐渐过时的东西，而是在你更新内容时自动生成跟进 PR 来更新 Context。
• 包管理器 → 可复用的 Context 单元。这个概念在最近两三周突然爆发了——Skills.sh、Tessl 的 Context Registry 等。

静态分析：格式验证与最佳实践

时间: 00:08:48 - 00:10:55

好，先看格式检查和最佳实践审查。我会用 Tessl 做示例，但这些概念你完全可以自己实现，其他工具也能做很多——当然不如 Tessl 做得好（笑）。

如果你看 Skills 标准，首先有一堆静态格式检查可以做。标准本身有一个参考 CLI 实现，可以验证你的 Skill 是否能正确编译。我认为每个写 Skills 的人都应该把这个放到 CI/CD 里，确保所有 Skills 保持更新。每次 Skill 文件变更时都应该检查验证。你会震惊于有多少人的 Context 根本没有被加载，而他们完全没有意识到。

不仅如此，Anthropic 也有最佳实践指南，基本上就是一系列规则。Tessl 会做的事情是：告诉你文件是否能编译通过，同时把 Anthropic 的最佳实践通过 LLM-as-Judge 来评审——你的 Context 有多具体？是否有明确的使用场景？我相信大家都听说过 Skills 不太容易被触发的问题，实际上不用运行 Skill 就能做一些检查来判断它被触发的可能性有多大。

这些检查成本低、速度快，可以放在 CI/CD 里，而且对你的 Context 实际可用性有惊人的提升。我推荐每个人都有这个，就像每个人都应该有 formatter 和 linter 一样，这是基本功。额外加分项：你可以把检查输出反馈给一个 Agent，让它自动修复问题——这是一个很好的快速循环。

Evals：Context 是否真的有帮助？

时间: 00:10:57 - 00:17:38

好，现在进入稍微复杂一点的内容，也是一个比较新的概念。如何为你的 Context 编写 Evals（评估）？

根据你是软件背景还是机器学习/深度学习背景，这可能显而易见也可能不那么明显。你想回答的核心问题是：我的 Context 真的有帮助吗？Agent 在我想让它完成的任务上表现如何？

举个例子：我们有某个库希望 Agent 使用，我们可以看到没有任何 Context 时 Agent 的表现——比如它不太会用 list 函数，可能自己重新实现了一个，或者用了另一个库；异步处理也不行，但流组合和 zip 文件处理还不错。

你想理解这些，这样才能知道需要在哪里应用 Context 来修复问题。从这种视图中你可能会发现几件事：

• 你可能写了一堆 Context，结果发现 Agent 没有 Context 也做得很好——为什么要浪费 token？
• 你可能写了些东西，结果发现性能反而变差了，因为信息过时了，或者只是增加了无用的 token。
• 理想情况下，你看到"有 Context 效果更好，而且我只在真正需要的地方投入了 token"。

设置方式其实很简单：写一些 prompt，描述你希望 Agent 完成的、需要用到你创建的 Context 的真实任务，然后写一个评分标准（rubric）来定义好的解决方案是什么样的。

为什么用评分标准而不是单元测试？原因有二。第一，单元测试写起来非常烦人且耗时，你很快就会发现如果每个 Context 都要创建示例项目和测试套件，你根本不会去做。更重要的是，Agent 会做出各种匪夷所思的事情来通过单元测试。功能正确性不是你唯一要衡量的东西，特别是对于 Context——很多时候你想知道的是：代码是否符合惯例？是否使用了我指定的库，而不是自己重新实现了一个？这些用单元测试根本没法衡量，用更 agentic 的评审或 LLM-as-Judge 效果好得多。

具体做法是：在 Markdown 文件里定义任务和评分标准。你的评分标准要非常具体，这样 LLM 才能给出可靠的结果——比如"解决方案应该在方法中的某处使用这个确切的 API 调用"或"应该在初始化那个之前先初始化这个"。非常细粒度的检查点，在解决方案完成后检查代码质量。

前期确实需要一些投入。这就是作为 agentic 开发者你需要维护的新源文件。但我们发现每个 Context 大约 5 个 Eval 就能提供相当可靠的度量。一旦你有了这些，就能永远从中受益，就像单元测试一样——每次修改都重新运行，看是否有改善或退步。

有一点不同的是，你经常会在没有改变 Context 的情况下重新运行，因为还有另一个变量在变——Agent 和模型本身。我们发现随着 Agent 越来越强，你可以开始精简 Context。我们曾经有 Python 风格指南，Claude Opus 4.6 的 Python 写得相当好，已经不需要风格指南了。你的 Evals 可以告诉你这一点，帮你删除不再需要的 Context，省钱，少花 token。

当然偶尔也会有回退。有一个版本的 Gemini 相当自以为是，觉得自己不需要使用工具和读取 Context，我们通过 Evals 发现了回退，需要加强指令让 Agent 使用 Context。

Repo Evals（仓库级评估） 就像集成测试——基本思路一样，但你不是在隔离环境中测试 Context，而是在完整编码环境中、安装了所有 Context 的情况下测量真实场景。今天我看了一个演讲提到了"愚蠢区"（dumb zone）——当你的上下文窗口里塞了太多东西（工具、Context 等等），Agent 就会持续表现糟糕。

所以你需要几个编码场景——5 个对你的仓库来说是个不错的起点——代表一个普通的开发任务，加上评分标准，每隔一段时间跑一次。看看你的技术债务是否让 Agent 无法理解你的代码，是否安装了太多 Context，是否安装了太多工具。

有个好方法是扫描你之前的 commit，把其中一些转化为测试任务。甚至可以定期选取过去一个月的 5 个随机 commit 来刷新你的 Eval 套件。对于机器学习领域的人来说，这类似于 input drift（输入漂移），你需要不时更新你的任务。但不用太焦虑——先从一些简单的开始，慢慢改进就好。

可观测性：挖掘 Agent 日志

时间: 00:17:40 - 00:20:36

这个我觉得很酷，但也有点吓人——你需要某种分析和可观测性工具。你写了 Context，在推送到仓库之前已经做了验证。在软件领域我们也这样做，但之后我们还有崩溃日志、指标、可用性漏斗这些东西。

这些对 Agent 来说其实是存在的，只是很多人没有关注。所有 Agent 都把聊天日志存储在文件系统的可访问位置。 你可以自己写脚本（当然 Tessl 也有这个能力，需要 opt-in，因为这是非常敏感的信息）。你可以审查这些对话记录，看工具是否被调用了、某段 Context 被使用的频率、某个模式实际出现在代码中的频率、是否在函数中间导入了库等等。

这里有大量丰富的信息。你只需要写个简单脚本，让团队里每个人跑一次，汇总一堆日志，审查常见问题——也许你需要为这些问题创建新的 Context。一个很好的信号是每当 Agent 道歉的时候——搜索"sorry"、“you’re absolutely right"这些词。“哦，也许我们应该写点什么来修复那个问题。” 我保证你的开发者机器上已经积累了三四个月的 Cursor 日志，你可以从中挖掘出"我们应该做什么不同的事情”。

然后是如何保持 Context 更新。你可以在 CI/CD 中设置一些很简单的东西——有各种 agentic 代码评审工具、Claude Code、Web 等。基本思路是：每当有 PR 提交时，让某个工具扫描这个 PR，然后检查"有没有哪个 Markdown 文件需要同步更新？" 这并不难。因为 PR 往往非常聚焦，Agent 很擅长找出哪些文档需要更新。如果你的 PR 太大了——也许这是一个信号，让你把 PR 拆小。

Tessl 可以自动化这其中很多工作，比如告诉你"哦，你在日志级别里加了一个新的 case，记得也更新你的文档"。

这可能是最重要的一点：当你的 Context 过时了，它会彻底摧毁 Agent 的表现。所以如果你要写 Context，你必须有一个保持更新的方案。Agent 其实很擅长做这件事，所以不要手动来——因为你不会坚持做下去的。

包管理器：Context 的复用

时间: 00:20:37 - 00:22:36

最后一个话题：包管理器。你需要一个包管理器来复用 Context——比如代码审查 Skill、React 使用文档和最佳实践等等。这方面有很多好的选择。Skills.sh 可能是最流行的（虽然说出这话让我心痛）。Tessl 也有包管理器，虽然不是最流行的——但我认为是最好的。我不会推销它为什么最好，但它就是最好的。

有两件关于 Context 包管理的独特之处值得思考。

第一，很多你要安装的 Context 实际上是在描述其他包管理器中的东西。 比如我有一个关于 PyPI 上某个库的某个特定版本的文档。这是一个新概念——你需要想清楚你的策略：如果你有某个库的文档，如何确保在更新库的时候，文档也锁定到相同的版本？你不会想说"我在用 Context7 上最新版的 React 文档"，但实际上你因为某些原因钉在了 React 17。

第二，思考如何让 Context 与依赖项、工具和 API 保持同步。 因为这是一种新的"漂移"来源，你可能需要关注。

这就是我的全部内容。很多事情自己做并不难，难的是持续更新并跟上 Agent 变化的速度。我很乐意回答问题。

Q&A：Context 的未来

时间: 00:23:11 - 00:24:54

观众：你怎么看 12 个月甚至 6 个月后的终态？Claude 4.6 已经很强了，Codex 5.3，等到 Codex 6、Claude 5、Gemini 4 出来——我们还需要这些脚手架吗？还是它们会消失？

Drew Knox：这是个很好的问题。首先，这会根据你是 Greenfield（全新项目）还是 Brownfield（已有项目）产生很大分化。如果你从零开始为 Agent 构建一个应用，会容易很多；如果是企业级 Java 应用，那就不一样了。

我认为你需要 Context 的事项数量会减少。我举的 Python 风格指南的例子——六个月前大家都在用，现在没人需要了。但是描述你公司内部自定义的日志方案？这个你永远都需要写文档，因为 Agent 无法访问这些信息，也不在它的训练数据里。总有一些知识需要主动告知 Agent。

我的预期是，最终你不会再主动地把大量 Context 塞进 Agent 的上下文窗口。你会有某种路标系统，像渐进式展示（Progressive Disclosure）一样——Agent 在认为必要时才去查看，就像正常开发者那样。大量的 Context 使用会转移到代码审查阶段。你会创建一个审查 Agent，它检查"是否违反了风格指南？是否重新实现了已有功能？" Context 会用于控制和审查，而不是前期教育 Agent。

我认为 Evals 会在帮助你应对这种转变中发挥重大作用——帮你判断什么时候该把东西从上下文窗口移到审查环节，或者直接删除。

Q&A：Evals 评分的实践

时间: 00:24:54 - 00:26:24

观众：关于 Evals，你之前展示的最高分是 50 和 30。根据我的经验，非二元评分对大多数 Agent 并不太有效。你能具体讲讲这是怎么工作的吗？

Drew Knox：你说得对。二元评分基本上是唯一实用的方式。我们在 Tessl 里确实提供了更细粒度的选项，但如果你看实际表现，Agent 几乎总是得零分或满分。所以是的，用 0 或 1 就行，结果差不多。

观众：我是 AI 工程师，希望快速构建解决方案。你会推荐直接用 Opus 4.6 快速生成一套 Eval 作为基线，然后以此为起点？还是建议先做一次完整彻底的分析，建立基线后再继续？

Drew Knox：你是在问是否应该花很大功夫来优化你使用的 Agent 和具体配置？就我个人而言，我很忙，有很多事要做——直接用最好的 Agent 就行。我补充一点：当你有一些非常重复性的任务时，值得去看看"我能用多便宜的方案来完成？" 很多时候 Context 能帮你用更小的模型做到。但对于日常使用，你的通用驱动器——直接拉满就好，除非你有什么原因做不到。

Q&A：技术架构师的角色

时间: 00:26:24 - 00:29:22

观众：我的问题更偏向非技术人员。你觉得什么时候、用什么标准可以衡量我们不再需要太深入关心 Agent 或 LLM 的行为？比如你们有 Spec-Driven Design（规格驱动设计），像产品经理一样写 PRD（产品需求文档），但不需要太关注技术实现——我们快到那个阶段了吗？

Drew Knox：我要抛出一个可能有点辛辣的观点：我们现在肯定还没到那个阶段，而且我认为我们永远不会到。

我的意思是：我们实际上已经拥有通用的 agentic 开发机器 50 年了——我们只是把它们叫做软件工程师。在那种情况下，你也从来不会只给某人发条 Slack 消息就指望他们完全不受监督地去构建整个系统并做出所有最佳决策。

换个说法，我的妻子——她是 Meta 的资深 Staff Engineer——她说：“即使你克隆了一个我，我也会审查我自己的代码。我永远不会接受任何人不经审查就提交代码。”

所以我个人认为，技术架构师、代码质量的守护者、引导者——这个角色将永远存在。 但这个角色会随时间演变。

现在这个角色涉及大量细节层面的具体决策、代码审查、指导和培养团队成员，通常一个这样的人对应 5 到 10 个工程师。我预想未来这个比例会反转——你会有一个"技术守护者"，他的工作是思考整体系统设计、持续审查 Agent 的代码、审查人们正在构建的东西，理解"哦，这是一个持续的失败点，如果我们把这部分抽象出来，构建一个 Agent 可以使用的组件，它们的一次性成功率会更高。“然后有 5 到 10 个更偏产品、设计、产品工程的人在外面探索产品空间的前沿，由这一个技术守护者帮助他们落地代码、保持可维护性并持续改进。

什么时候能到那个阶段？这个我不太确定。可能两周后，也可能两年后。我觉得大概在个位数年份的量级。一个完全 AI 原生的全新项目，在未来一年内以这种模式运作，我不会感到惊讶。但对于 Brownfield 项目，我认为会更难。