四种上下文决定AI是在帮你还是在浪费你的时间

我花了整整一个周末解析超过100MB的PDF。当时的逻辑很简单：喂给智能体的知识越多，输出质量越高。事实证明我错了。

折腾了好几天之后，我画了一张图，把之前喂给模型的所有内容分成四类。问题一目了然。从来不是数据量的问题，而是上下文类型的问题。

喂给模型它已经知道的东西，只会让结果变差

大语言模型在万亿级别的token上完成训练。当你把同样的信息粘贴进提示词，这些冗余token就占据了上下文窗口的空间，分散了注意力，让模型难以专注于真正重要的内容。你本来是为了帮助模型，加进去的信息反而在约束它。

我直接测试过这一点。把Python语法和基础React模式塞进提示词，模型开始和自身的训练数据产生冲突，输出结果比什么都不加时还要奇怪。堆积足够多的冗余信息，就会出现”上下文腐化”现象，模型的回答质量会持续下滑。“输入越多，输出越聪明”这种直觉，是提示词工程里最危险的陷阱。

环境上下文是唯一模型无法自行推断的类型

项目目录结构、团队约定、内部API的数据结构，这些内容不存在于训练数据中，模型在没有明确输入的情况下根本无法推理。这一类才是上下文真正应该发挥作用的地方。

围绕环境上下文的工具链正在以超过其他任何领域的速度演进。文档OCR的努力正在多个地区同步推进：国内有Upstage、深度求索和智谱，还有小红书也在布局；法国有Mistral，印度有Sarvam。曾经最难捕捉的语音媒介也在被快速结构化，Granola这类会议记录工具能保存那些以往开完电话就消失的对话，Wispr Flow等产品则能把实时的口头思路转为文字。浏览器行为、环境视觉信息，那些你顺手扫一眼就忘掉的东西，也正在被转化成可以喂给模型的结构化上下文。

方向已经很清楚：以前会蒸发掉的信息，正在被批量转化成模型能够使用的输入。

知道和执行之间的差距，才是人与人之间真正的分野

环境上下文告诉模型”有什么”，技能告诉它”怎么做”，用什么顺序，达到什么标准。存储和核验知识，每个人都会做。但一旦加入结构化的执行层，也就是基于推理来定义步骤序列，人与人之间的差距就开始拉大。

一个好的技能定义不只是简单的指令列表，它包含六个要素：操作纪律、完成标准的定义、任务拆解、缺陷修复方法、反模式以及环境适配。把所有任务塞进一个技能必然失败，把工作拆成细粒度的技能，再通过AGENTS.md这样的工作流文件组合起来，才能让智能体灵活运转。哪怕只是一些粗糙的提示性备注，也可以用/skill-creator之类的工具即时转化成技能。

这里设计视角最关键。保存中间文件、先分析再执行、提前定义验证标准，这些决策决定了智能体成功还是失败。我更倾向于用脚本而非MCP，这是生产环境用下来得出的结论，不是理论推演。技能会随使用而精进，给智能体提供对比示例，它就能自己优化执行方式。

老实说，把技能设计做对花了我比预期更长的时间。最初几次要么太宽泛，智能体直接忽略了一半的指令；要么太死板，稍微有点变体就卡住了。找到那个”够具体但又有弹性”的平衡点，真的需要反复迭代。

意图和品味，才是为什么相同配置却产生不同结果

观察了十多年人们的工作方式，有一个规律一直在重复出现。收集和验证知识，每个人都会做。通用知识层面，AI现在掌握的已经远超任何一个人类。技能可以通过重复积累。但用完全相同模型的人，依然会产出截然不同的结果。

看看”氛围编程”的产出就知道了。有些人的作品会让人忍不住问”这怎么做到的”，另一些人的作品只换来沉默。差别在于，一个人接受AI给出的默认审美，另一个人坚持推动某个具体的视野。快速捕捉信息，和带着特定意图过滤信息，是两种完全不同的能力。后者需要考虑目标受众的视角以及完整的外部语境，是一种更高阶的思维方式。

模型不知道你想要什么，你得有能力把它说清楚。这就是为什么品味在AI时代比知识更值钱。

越难自动化的东西，背后的人越有价值

通用知识已经归AI所有，继续往提示词里塞只会适得其反。环境上下文正在被OCR和语音工具以越来越快的速度捕获。技能可以通过重复和结构化来构建，再交给智能体执行。只有意图和品味，是目前唯一完全抵抗自动化的类别。

收集AI工具和信息当然有用，但真正的杠杆不在那里。与其往提示词里塞更多上下文，更好的做法是更精准地知道自己想要什么。你在AI时代的价值，藏在你的品味里。