在人机协同的工程实践中，我们常常会陷入两个极端：要么试图用 Prompt 规定一切，导致 AI 变得死板且极易在长上下文中崩溃；要么给予 AI 极大的自由度，结果连一个简单的任务状态更新都会因为输出格式的微小变化而导致下游系统报错。

判断"哪些需要固化，哪些需要多样化"，是构建智能体（Agent）系统的核心架构决策。这本质上是在解决"可靠性"与"泛化性"之间的矛盾：固化用来兜底限，多样化用来拉高上限。

一、 固化：将"不可接受的幻觉"转化为"机械的必然"

1. 为什么要固化？大模型并非状态机

大模型的底层逻辑是基于概率的下一个 Token 预测（Next-token prediction），这就注定了它是一台模式匹配机器，而非精确的状态机。 它的优势在于在海量数据中找到语义上的关联，但劣势在于极度缺乏精确执行的稳定性。

举个实际的例子：如果你让 AI "把今天任务里的 caddy 标记为迁移，并复制到明天"，如果纯靠 AI 直接编辑文本，它今天可能会写 m 配置懒猫微服，明天可能就变成了 [Migrated] 配置懒猫微服，甚至还会自作主张加上 Markdown 加粗。人类能看懂，但下游的统计脚本会直接崩溃。

在工程中，任何需要严格状态流转、精确格式输出、绝对路径依赖的操作，都不应信任模型的临场发挥。固化，就是用传统代码（Python/Bash 脚本）的确定性，去接管这些环节，从而彻底根除这一层面的"幻觉"。

2. 固化什么？剥离重体力活

• 操作原语（Primitives）：诸如文件读写、API 请求（重试与限流逻辑）、Git 提交流程等。AI 不该自己去写 curl 命令处理 SOCKS5 代理和 429 限流，这些应该被封装为 arxiv_search.py 这样的脚本。
• 状态约束与业务逻辑：在 bujo（日拱一卒）系统中，t（待办）变成 m（迁移）的同时，必须在目标日期新建一条对应的 t，且连带子笔记 n1 一起复制。这种强耦合的事务性操作（Transaction），必须写死在 bujo.py 脚本里。AI 的任务仅仅是决定调用 migrate 命令。
• 通信协议与界面呈现：例如 Telegram 的心跳简报（Heartbeat）。由于 Telegram 对 Markdown 支持有限，如果让 AI 自由发挥，很容易因为输出了未闭合的加粗符号 ** 导致整条消息发送失败。因此，必须在 Prompt 中固化模板格式，甚至精确到每行用什么 Emoji 和前缀。

3. 如何确保固化被严格执行？

• 工具隔离（Tooling & Sandboxing）：将固化逻辑物理剥离出 LLM 的上下文，变成独立可执行的命令行程序。AI 的作用从"直接生成最终结果"降维成了"生成参数并调用函数"。这是最极致且最可靠的固化。
• 强制前置挂载（Pre-flight Prompting）：对于必须遵守的上下文规则，通过系统机制（如读取 HEARTBEAT.md 或 SKILL.md）强制在每次请求前注入。用强关联词（如"必须"、"严禁"）收束概率空间。

二、 多样化：释放"上下文涌现"的非线性价值

1. 为什么要多样化？处理高熵的现实世界

如果我们把所有东西都写成了脚本和死规则，AI 就退化成了一个套壳的 CLI 工具（Command Line Interface），毫无智能可言。 多样化的存在，是为了处理现实世界中那些高熵、模糊、非结构化的意图和信息。这就是大模型最擅长的事情。

2. 多样化什么？让 AI 充当"大脑"与"路由器"

• 意图路由（Intent Routing）：用户发出一句高度模糊的语音："那个反向代理的事儿今天不干了，推到周三吧。" AI 需要理解"反向代理"对应 caddy 任务，"推到周三"对应 next-周三，然后自动转化为精确的固化指令：bujo.py migrate today caddy next-周三。
• 抽象归纳（Summarization & Synthesis）：比如分析千行的错误日志、总结英文技术博客的核心观点、或者对长篇大论进行哲学提炼。在这里，没有固定的标准答案，AI 的发散能力成为了巨大的财富。
• 自我纠偏（Self-Correction）：这是智能体区别于自动化脚本的核心。当 bujo.py migrate 返回 "未找到条目" 时，传统的自动化脚本会直接中断报错；而具备多样化认知能力的 AI 会反思："是不是我搜索词给错了？"，然后截取更短的关键词重新重试执行。

3. 如何确保多样化不失控？用软边界引导灵感

多样化不是放任自流，而是需要用"价值观"来牵引。

• 软性约束（Constitutional AI）：我们不规定 AI 具体说什么话，但我们通过 SOUL.md 或 nopua （反职场 PUA 的道家哲学驱动）来规定它的行事风格：不废话、不推诿、穷尽工具再提问。这种约束让它在遇到难题时，依然能保持我们期望的工程师素养。
• 运行时记忆（Dynamic Context）：通过 MEMORY.md记录长期的偏好（比如"回答直接给技术细节，不降级解释"），在多样化发挥时自动对齐用户的审美。
• 演化机制（Self-Improving）：通过 corrections.md 记录曾经犯过的错（如"调用 edit 忘了传 path"）。多样化试错是允许的，但同样的错误不能犯两次。这使得多样化的边界在不断探索中逐渐收敛，趋于完美。

三、 架构闭环：确信体系的建立与"技术平权"

如何确保"我们需要它固化的它固化了，需要它多样化的它多样化了"？我们需要建立一个分层的架构。

1. 智能体的三层架构

• 执行层（Execution Layer）：全固化。由 Bash/Python 脚本、API 接口组成。这是 AI 的"肌肉"，力求 100% 的确定性和幂等性。
• 路由层（Routing Layer）：半固化。由 SKILL.md 提供映射手册，相当于"神经系统"。告诉模型"遇到什么情况，应该如何组合下层的肌肉"。
• 认知层（Cognitive Layer）：全多样化。由 LLM 自身的上下文、SOUL.md、MEMORY.md 构成。这是 AI 的"大脑"，负责理解模糊输入、制定计划、反思结果。

2. 演进理念：技术平权与知识的提炼

这就引出了一个非常关键的实践心得："好（贵）的模型用来打通工作流，总结为技能；便宜的模型用来执行技能。"

面对一个全新的复杂问题，我们需要用顶尖的模型（如 Claude 3.5 Sonnet / GPT-4o）去发散思考、查阅文档、反复试错。一旦探索出一条走得通的路，我们就不应该再依赖大模型每次去重新推理一遍。 相反，我们应该把这条路**"固化"成代码和 SKILL.md。这时候，这条知识就被降维成了工具。此后，哪怕我们使用极其便宜、推理能力较弱的模型，只要它能看懂 SKILL.md 并调用函数，它就能完美完成同样的任务。这就实现了 AI 时代的技术平权**。

总结

和 AI 相处，本质上是在进行一场认知层面的分工调度：

• 把确定性的操作下沉给代码，让脚本包揽一切重体力活与状态管理；
• 把不确定性的推理上浮给模型，让 AI 专注理解意图与反思纠错；
• 用工具的硬边界去收束模型的幻觉，保障系统的底线；
• 用价值观的软边界去引导模型的灵感，拔高能力的上限。

一言以蔽之：**脚本管确定性，文件管倾向性，纠错管成长性。**这就是我们与 AI 共生的长久之道。