13篇基准要求的代码之道
有一段时间，我对 skill（技能模块）的期待很高。按照要求写好了 skill，参数配置也一一对应，自认为已经做了该做的一切。字面意义上，所有该填的字段都填了，所有该设置的选项都设了。但实际用下来，效果始终不尽如人意——输出质量距离预期差了不止一个档次。
问题出在哪里？我开始追问。
从效果追问到机制
"为什么 skill 按要求写了，效果不如预期？"
这个问题我问过 Agent，Agent 也展示了当前的结果。坦诚说，那份结果不算差，某些方面甚至比我预期的还好一些。但离我心里的基准线有明显距离。我正准备接受这个现实，继续往前走——但我停住了。
"先别急着看结果，"我说，"我想先搞清楚这13篇基准要求是怎么被处理的。"
这是一个有点反直觉的操作。通常遇到效果不理想，我们第一反应是调整参数、增加示例、重新生成。这些都是正确的排查方向。但我没有走那条路，而是把注意力转向了系统内部对"基准要求"本身的处理逻辑。问题可能不是"执行质量"的问题，而是"理解深度"的问题。
Agent 开始帮我追溯。我问它：这13篇基准要求，从它出现在对话里，到最终影响输出质量，中间经历了哪些环节？每个环节是如何处理这些要求的？
追溯的结果让我们都愣了一下。
一个被忽视的环节
Agent 帮我梳理出了完整的处理链路：来源、候选、计划、写作输入。这条链路看起来没有问题，每一步都在运转，逻辑通顺，前后衔接。如果只看表面，你会觉得系统完全理解了这13篇基准要求。
但当我追问"基准要求在哪个环节真正发挥作用"时，答案指向了一个关键缺口——
基准要求只被当成 skill 参数。
这句话需要一点解释。在系统的设计里，基准要求是作为参数传入 skill 的。参数传入意味着什么？意味着它只是一个"输入值"，系统读取它，执行预设的逻辑，然后输出结果。参数是外部信息，系统处理它，但系统本身并不知道为什么要处理它。
我找到了类比来理解这件事。你给 GPS 输入了一个目的地，GPS 知道你要去哪里——它读取了你的目的地，按照内置地图输出路线。但它没有被设置任何路线规则：没有偏好高速还是省道，没有避开拥堵的逻辑，没有你上次走哪条路更快的记忆。它只是机械地把已知路线输出给你。你得到了一条路，但不一定是最优的那条。而且如果你下次输入一个稍微不同的目的地，它依然会给你一条路，但依然不会主动学习什么。
13篇基准要求，在我的使用场景里，就是那个未被转换成内部规则的"目的地"。系统知道它们的存在，知道它们的值，知道它们叫什么，但不知道它们为什么重要、它们如何影响决策、它们和其他输入之间是什么关系。它们是输入，但不是判断依据。
从参数到代码逻辑的跃迁
发现这个缺口之后，解决方向变得清晰了。
不能只把基准要求当作外部参数传入，而要把它们编码到执行逻辑里——让系统真正理解"为什么要这样做"，而不是每次都等着外部参数来提醒它"要这样做"。
这意味着重新设计 skill 的内部判断机制。不再是"接收这个输入，执行这段代码"，而是"基于这个判断原则，做出这个决策"。当基准要求成为代码逻辑的一部分，系统才能在面对新情况时主动应用这些原则，而不是每次都等着外部参数来提醒它。
这个转变解决的不只是当前某一次输出的质量。这解决的是一个系统性的能力缺口——当规则被编码进代码层面，系统就不再依赖"有人记得传入正确的参数"这种被动机制，而是能够主动做出符合原则的判断。
真正的效率提升，不是堆砌更多的 skill，不是引入更多的参数，而是把最基础的行为规则写进代码的核心层——让系统真正理解"为什么"，而不是只知道"做什么"。
人机协作的新认知
回顾这次追溯，我意识到那次"先别急着看结果"的叫停意义重大。它把我从"优化输出结果"的战术层面，拉到了"理解系统机制"的战略层面。大多数时候，我们习惯于用更多的努力去弥补系统性的不足——更多参数、更多示例、更多调整——但真正有效的做法，是回到根本，重新定义规则如何被系统理解。
更深一层去想，这其实揭示了人机协作的一个本质问题：我们总想着控制机器给出更好的结果，但实际上更有价值的做法，是和机器一起构建更好的规则体系。机器执行指令的能力很强，但定义规则、理解规则背后的逻辑，是人的优势所在。当这两者各司其职、协同运转，效果远超一方独自努力。人不是主人，机器也不是工具——两者更像是共同演进系统中的不同角色，各有分工，各有不可替代的价值。
所以那13篇基准要求，最终不只是被"写入"了某段代码。它们改变了我理解人机关系的方式——不是主人和工具，而是两个角色在共建一个能持续进化的规则体系。每一次追问，都是在重新定义这个规则体系的边界；每一次调整，都是在让这个体系更好地理解它应该服务的目标。