真正的 AI 生产力，不在模型里，而在它身后的工作系统

一个模型再聪明，如果没有边界、记忆和复盘机制，也不过是一个反应很快的实习生。真正拉开人与人之间差距的，可能已经不再是“谁能问出更好的问题”，而是“谁能把 AI 组织成一个不会轻易失控的系统”。

这解释了几个看似无关的现象：有人把模型部署在本地，让代码补全保持私密；有人用 Gemini 做研究，再交给 NotebookLM 拆解、讲授和出题；有人在代码仓库里维护 AGENTS.md、CLAUDE.md 或 GEMINI.md；还有人专门部署一个“家庭医生”去修复被升级弄坏的 agent 集群。

它们表面上分别属于编程、学习、配置和运维。实际上，它们都在回答同一个问题：当 AI 从一次性问答变成持续工作的协作者时，我们应该如何设计它的工作环境？

我的判断是：AI 时代最重要的生产力单位，不是模型，而是上下文系统。模型负责生成能力，上下文系统负责决定它看什么、记什么、能做什么、如何被检查，以及失败后谁来修复。

从“使用模型”到“设计工作回路”

早期使用 AI，基本是一个简单动作：输入问题，得到答案。这个模式把模型想象成搜索框，效率提升主要来自回答速度。

但真正复杂的工作从来不是一个问题，而是一条链路。学习一篇论文，需要发现资料、理解结构、建立联系、主动回忆、检验漏洞。修改一个大型代码库，需要读取局部规则、理解依赖、制定计划、执行变更、运行测试、处理失败，最后再交付。两者都不是“生成一段内容”可以解决的。

可以把高质量的人机协作抽象成五层：

1. 来源层：系统从哪里获得原始材料。
2. 记忆层：哪些信息被保留，哪些规则持续生效。
3. 行动层：模型可以调用哪些工具，执行哪些操作。
4. 验证层：什么条件满足后，结果才算合格。
5. 恢复层：系统出错时，如何隔离故障并恢复工作。

普通聊天往往只有来源层和行动层。它可以读一段文字，也可以给一个答案，却没有稳定的记忆、清晰的权限、客观的验收标准，更没有可靠的恢复机制。

这就是为什么很多人会产生一种错觉：模型似乎越来越强，自己的工作却没有成比例地变快。因为他们升级了发动机，却没有升级道路、交通规则和维修体系。

AI 的能力决定它能做什么，工作流的结构决定它最终会做成什么。

学习和编程，其实是同一种闭环

NotebookLM 与 Gemini 的组合，值得注意的地方不只是“总结资料更快”。它更像一个经过分工的学习系统。

Gemini 负责向外扩张。它可以围绕一个新领域做研究，整合多个来源，形成初步地图。NotebookLM 则负责向内压缩。它把论文、视频、文档和研究报告放在一个受控的资料空间里，允许使用者逐段追问、重新解释、生成音频内容，再通过对话把复杂材料拆成可吸收的结构。最后，测验把“我听懂了”变成“我能否在没有提示时回忆出来”。

这不是简单的工具串联，而是三种认知动作的分离：探索、消化、检验。如果只让一个模型从头做到尾，研究、解释和评价很容易混在一起，使用者也很难知道哪些是事实，哪些是模型的推断。

代码 agent 的理想工作流同样如此。它先读取仓库规则和目标文件，接着进入计划模式，再执行修改，最后运行 lint、type check、test 和 build。这里的测试并非附属环节，而是相当于学习中的小测验：它迫使系统证明自己完成了任务，而不是仅仅生成了一份看起来合理的结果。

一篇论文的播客稿可以很流畅，却可能把关键概念讲错。一次代码修改也可以很漂亮，却可能破坏边界条件。流畅性是表达指标，不是正确性指标。

因此，任何值得长期依赖的 AI 工作流，都应该包含一个与生成动作分离的验证动作。学习者需要用测验验证记忆，程序员需要用测试验证行为，运营系统需要用健康检查验证服务状态。没有验证的自动化，只是更高速地制造自信。

配置文件不是说明书，而是组织的宪法

在代码仓库中加入 AGENTS.md、CLAUDE.md 或 GEMINI.md，真正重要的并不是文件名，而是它们改变了规则的存在方式。

过去，项目规范主要写给人看。README 解释背景，架构文档说明设计，代码评审依赖经验。现在，一个 agent 会主动读取文件、执行命令、修改代码，甚至创建提交和发起 PR。于是，原本藏在资深工程师脑中的习惯，必须变成机器能够发现、执行和验证的规则。

这里需要区分两类内容。

第一类是跨工具的执行合约。 它应该说明项目如何验证，哪些命令必须运行，哪些目录有什么局部约定，哪些操作明确禁止。比如根目录规定全局检查，某个子包规定自己的测试命令，数据库目录则明确禁止自动迁移。AGENTS.md 适合承担这种角色，因为它描述的是“在这里工作，合格行为是什么”。

第二类是工具适配层。 CLAUDE.md 和 GEMINI.md 可以记录特定工具的记忆加载方式、权限偏好、常用命令、MCP 使用方式或计划审批习惯。但它们最好只是薄薄一层，不要在不同文件中重复维护同一套工程真相。

这可以类比为软件接口。AGENTS.md 是公共协议，告诉任何合作者必须满足哪些条件。CLAUDE.md 和 GEMINI.md 是不同客户端的适配器，负责让各自的交互更顺手。如果把核心规则全部写进某一家厂商的私有文件，团队就会被工具锁定，也会因为规则分叉而产生不可见的差异。

层级结构同样重要。大型代码库不应该把所有知识都堆在根目录。一份根级文件只需要包含全局架构、关键禁区和统一检查。具体子目录再补充局部约定，让 agent 进入某个区域时获得恰到好处的上下文。

这和优秀的学习系统完全同构。一个人不可能每次学习都重新读完所有背景材料，他需要全局框架、当前章节的局部记忆，以及针对这次任务的具体提示。好的上下文不是越多越好，而是让正确的信息在正确的距离内出现。

自动化的核心不是放权，而是可逆性

当 agent 只能生成文本时，错误通常停留在屏幕上。当它能读写文件、运行命令、访问服务时，错误会进入现实世界。风险也因此发生了变化：危险的不再只是提示词注入，更是流程注入。

如果仓库里的某个 Markdown 文件要求 agent 执行一条危险命令，而系统又把“文件中写了”误当成“可以执行”，那么攻击者不需要直接说服模型，只要改变模型所依赖的工作流程，就可能改变它的行为。

所以，配置文件必须像代码一样进入评审。它们不应被视为无害的文字，也不能因为扩展名是 md 就绕过审查。尤其要警惕部署、数据库迁移、删除数据、访问外部服务、下载并执行未知脚本等不可逆操作。

一个稳健的权限模型，可以从四个问题开始：

1. 这条命令是否幂等？重复执行会不会造成额外损害？
2. 这项操作是否可逆？出错后能否从备份或版本控制恢复？
3. agent 是否真的需要这个权限？能否用更小的权限完成任务？
4. 结果是否有独立检查？谁来确认它没有越界？

本地运行模型的价值，也应该放在这个框架里理解。DeepSeek 之类的代码模型通过 Ollama 在本地运行，意味着代码补全可以留在自己的设备上。这提升了隐私和控制力，但本地并不自动等于安全。如果一个本地 agent 拥有过大的文件系统权限、网络权限和凭证，它只是把风险从云端搬到了自己的电脑。

真正可靠的设计不是“让模型什么都能做”，而是让它在一个最小权限、可观测、可回滚的环境中完成足够多的事情。云端沙箱、禁网容器、工具白名单、逐步确认和 CI 检查，看起来会降低一点即时自由，却显著提高了长期可用性。

这也解释了“家庭医生”架构为什么有价值。多个 agent 分别拥有隔离的 workspace，各自处理写作、信息抓取或分析任务。另一个独立 gateway 不参与日常业务，只负责检查日志、修复配置和重启故障服务。它相当于把业务系统和恢复系统分开，避免一个 agent 既是故障制造者，又是唯一的维修者。

这是一条经常被忽视的工程原则：自动化系统必须拥有独立于业务流程的恢复能力。 人类组织也一样。医院不会让正在进行手术的团队同时负责维护整栋医院的供电系统，关键系统需要备用电源、监控和专门的维修角色。

从今天开始搭建你的 AI 工作系统

如果把上述思想落地，不需要一开始就建立复杂的平台。可以按照工作的重要程度逐步增加结构。

第一步，建立一个单一事实来源。把项目的测试命令、格式要求、目录边界、禁止操作和交付条件写入根目录的 AGENTS.md。内容要短、明确、可执行，少写背景故事，多写“先做什么、必须检查什么、失败后怎么办”。

第二步，把局部规则下沉到局部目录。一个 monorepo 可以为不同 package 设置自己的测试和风格约定。这样 agent 不必在每次任务中处理整座代码库的所有信息，也能减少上下文冲突。

第三步，让工具专属文件只保存增量。CLAUDE.md 或 GEMINI.md 可以写权限、记忆刷新、计划审批和常用操作，但应明确引用公共规则，而不是复制一份容易过时的版本。

第四步，把验证变成合并门槛。lint、type check、test 和 build 不应只是建议，而应进入 CI。任何 agent 生成的 PR，都要经过同样的检查。模型可以改变，工具可以更换，验收标准不能随意漂移。

第五步，为高风险系统准备“医生”。当 agent 数量增加、任务开始定时运行后，日志、健康检查、隔离 workspace 和独立修复角色就不再是过度设计，而是基本设施。

学习工作流也可以用同样的方式改造：先用研究模型扩展资料，再把资料导入受控知识库进行解释，随后通过主动提问和测验验证掌握程度，最后把真正重要的结论沉淀为可复用的笔记。不要把“听过一遍”当成学会，也不要把“生成过代码”当成完成。

Key Takeaways

1. 把 AI 工作拆成来源、记忆、行动、验证和恢复五层，检查自己是否只拥有了生成能力，却没有验收和修复能力。
2. 建立一个跨工具的公共规则文件，将测试、风格、交付条件和禁行操作写入 AGENTS.md，工具专属文件只保存必要的适配信息。
3. 把验证从建议变成门槛。学习使用测验，编程使用测试，自动化服务使用健康检查，所有重要产出都要有独立的证明环节。
4. 按照最小权限和可逆性设计 agent。优先允许幂等检查，谨慎开放写入、网络、部署和数据库权限，生产环境使用沙箱与隔离凭证。
5. 为自动化系统准备独立的恢复角色。业务 agent 负责创造价值，维护 agent 负责观察、修复和恢复，避免单点故障。

我们常说，未来的竞争是模型能力的竞争。但当基础模型逐渐普及，真正稀缺的可能是另一种能力：把模型嵌入一个有记忆、有边界、有反馈、有免疫系统的环境中。

最好的 AI 使用者，不是最会向模型提问的人，而是最会设计工作回路的人。他们不把模型当作万能天才，而是把它放进一支有规章、测试、权限和维修制度的团队里。

当我们从“如何让 AI 给出更好的答案”转向“如何让 AI 在一个可靠系统中持续完成任务”，AI 才真正从聊天工具变成基础设施。