开发日志11: 在规则和自主之间平衡

我们在用AI的时候，其实可以对应到日常工作中的两种模式。规则和自主，其实不是两个孤立的点，而是形成了一条连续的光谱。没有哪一种工作流是完全处在两个极端的，它们都是要么靠近规则多一些，要么靠近自主多一些。就像我们在用 Claude Code 来做一些工作流的时候，其实都是在这两个极端之间进行权衡。

为了方便理清楚什么是规则，什么是自主，我拿一个比较极端的例子来说明。

极端的约束就是我完全写好了脚本，每一步应该怎么干，能拿到什么样的结果，这一步拿到预期和没有拿到预期之后，分别的步骤又是什么。用一个比较正式的词，应该叫它“决策树”。就你一棵树，从根生发，长出不同分杈的枝枝蔓蔓。虽然看上去复杂度指数级上升，但如果从单个节点来看，也不过是非此即彼的选择题。这个模式，很像是没有任何表演天赋、第一次拿到剧本的演员，只是在合适的时机照着自己的台词念了就行，然后做出相应的动作。

而极端的自主，就像是一个没有任何限制的大模型，你给了他一个终极目标，他会自己去拆解，自己规划，自己决定怎么取舍、怎么判断，然后最终交付给你一个符合你预期的结果。比较简单的就像早期的ChatGPT，我们让他去做一个调研报告，你可能并不知道他要访问哪些网络资源，也不知道他是通过什么方式访问的，甚至不知道他在这个网站上面深入的程度有多少，每一篇文章对他写最终报告占的权重有多少。你只是在他一顿发挥之后，拿到了一个最终的结果，就是你要的那份调研报告。

对于一些简单的任务，我们可以采取比较靠近极端的方式，比如就是想跑一个命令的结果，你只需要写脚本就行。或者说你就只是想大致了解一下某些领域的最新的方向，也完全把它交给大模型，让它自己发挥就行，因为你只是想简单了解一下。但是实际我们在工作中遇到的问题都不是非此即彼的，而是有一定的复杂度要求，既要有规则的约束，还要同时保留自主发挥的空间。因为这里简化成了两个维度，即自主和规则，所以我也按照这个简化的模型，以两个分支分别讲它们的用法，以及如何对应到Claude Code。

如果是让大模型发挥多一些的这一个分支，我们会去做一些插件、技能、Agent，然后会去让这些大模型自己调用我们做好的这些插件，用这些插件里面用自然语言表达出来的逻辑和推进结构，来把整件事情有序做完。就像我之前提到过那个做播客的流水线，在一个主会话里面，主模型负责整个过程的调度和监控。它会按照我们事先写好的一个文档，第一步应该去执行什么，调哪些技能，分发哪些 subagent，然后第二步又该做什么，然后每一步的预期是什么，到底有没有符合每一步想要的结果。这整个过程中，对这些规则的约束的理解，全靠大模型自主理解。模型的能力和对门控的遵循程度，极大地左右了这种模式最终呈现的质量。所以在换模型的时候，得到的结果最终是大相径庭，好像完全是两个流水线生产出来的东西。

而另一种方式，规则为主、大模型辅助推进，仍然是在主会话里面，不过这次不是由大模型来遵循一个已经写好的流程文档，来从头到尾自己理解，自己执行，自己完成调度。而是在这个主会话里面嵌入一个脚本，可以是一个Python，可以是一个 shell，甚至可以是 Go 或者 TS，只要是执行器能拿到明确执行结果的语言，都可以。然后我们把整个本来需要用自然语言描述的流程，做成脚本的每一个需要判断的分支和行动。比如拿播客简单来讲，主脚本中会依次排列好需要执行的大步骤，比如采集素材、拼合文本、润色稿件、转换语音。每一大步都是需要判断和可重试的一个模块。在这个大模块中，以采集举例，不再依靠 Claude Code 自己调用 Skill，分发 Sub-agent 的能力，而是手动地调用它的一次性命令，比如 claude -p '全网调研 AI 相关的最新讯息，并进行多个信息源交叉验证。把结果写入 result-2026-06-22.md 文件中，不少于 1000 字。'。当这个命令执行完成后，我们并不会完全相信模型能够完美地遵循指令。所以需要用脚本来检查是否有预期的文件生成，文件中的文字是否确实没有少于 1000 字，还要用另一个 claude -p "检查 result-2026-06-22.md 这个文件中所有信息是否属实，语气是否有明显夸大。" 来定向核验模型的表现。而主会话的职责，除了监视整个过程，以便在异常报错后可以快速自愈，另一方面也是作为边车（sidecar）来评估整个框架的性能，以便于不断优化。

当然，这两个例子远没有看上去那么明显。我再拿工作中的场景来说明。第一种，偏自主的方式，就像是现代的公司一样（偏牛马的那种），他会给每一个员工指派一个任务，然后这个员工根据自己的理解完成这个任务，然后提交到系统里面，这个任务会流转到下一个环节，然后由另外的员工完成他自己的任务，依次进行持续交接。而整个这个链条之外，又有一个 team leader 来进行协调，他根据自己对这一整个任务流程的理解，进行汇总、编排以及及时的调整。而在他之上又会有部门的领导做同样的事情、协调多个小组，使整个公司看上去像一个不断扩散且自包含的循环。

而对于偏向规则约束的方式，想象一下工厂里面的流水线。它是一个死板的、机械的、不断往前推进的平台，工人只需要在上游的产物到达自己的节点之后，按照固有的操作把它分发到自己的下游即可，甚至不需要过多的思考，只是重复的、机械的做自己小范围内的本职工作。

明确了解了规则和自主两种工作流的运行方式后，对于那些有固定流程、不需要自主性的，就可以用脚本驱动模型这种方式来做。而对于那些自主发挥比较多的，就可以让模型驱动模型，也就是模型驱动 Agent 来完成。

但实际上并没有完全隔离开的自主和规则，即便是在流水线这样机械重复的劳动之中，工人也会有些许的思考，一个上游的产物过来，到底是怎么样的规则，或者说是满足什么样的条件，我才能把它们派发到不同的下游？这也是一个小范围之内做决策的过程。而对于自主驱动的现代职场里面，它也有规则的一部分。整个管理体系用到的一些流程软件，如 CRM、OA、Jira等等，其实就充当了脚本的这一层，它有固定的判断标准，有强制的产物规范，有明确的流转方向。这两者通过不同比例地搭配，共同组成了我们现在做每一件事情的整个流程。

进一步想，从编程语言的强制约束，到自然语言的可自主发挥，我们只是在人和计算机之间（也包括大模型）不断地通过改变交流媒介（也就是语言），来调节两者之间契约的完整性。契约越是完整，过程越是死板，越是可预见，少了创新，但质量稳定；而契约越是宽松，过程越是灵活，虽然偶有惊喜，但良莠不齐，加重了筛选的难度。

所以话说回来，没有一成不变的方案，因为没有一成不变的问题。把握自主和规则的平衡，不但是大模型应用的基本功力，瞧着还是一个为人处世的学问呢？！