Zexi's Notes

开场

大家好，今天我想介绍的不是一个聊天机器人，而是一个在企业 IM 里工作的数字员工，名字叫 AI 实习生。

先从一句话定义开始，再解释它背后的架构和原理。

如果先用一句话定义它，那就是：

AI 实习生 是一个接入了企业 IM、拥有独立员工身份、可以调用真实工具和环境来完成任务的通用 Agent。

我今天主要讲 4 个问题：

1. 通用 Agent 到底是怎么工作的。
2. 为什么 AI 实习生 不是普通聊天机器人。
3. 为什么我们最后把它放进企业 IM，而不是单独做一个网页。
4. 这套做法为什么可以迁移到其他业务。

一、通用 Agent 是怎么工作的

如果不先讲这个，后面很多关于 I/O、工具、技能、会话的讨论都会飘在空中。

我先用一张最小原理图说明通用 Agent 的工作方式。

这个循环通常叫做 Agent Loop，很多时候也会被叫做 ReAct Loop。

如果只用一句话解释 ReAct Loop，它的意思就是：模型一边推理，一边行动，再根据行动结果继续推理，直到完成任务。

flowchart LR
    U[用户任务] --> M[大模型]
    M --> D{需要调用工具吗}
    D -- 否 --> A[直接输出答案]
    D -- 是 --> T[调用工具]
    T --> E[获得外部结果]
    E --> C[写回会话上下文]
    C --> M

这张图表达的就是一个最小的 Agent Loop。

它只想讲 3 件事。

第一，Agent 不是一次性吐一段文本，而是在一个循环里工作。

第二，这个循环一般是：理解任务，判断要不要调工具，调完工具拿到结果，再把结果带回模型继续推理，直到产出最终答案。

第三，真正让它从“会聊天”变成“会干活”的关键，不是 UI，而是它能不能进入这个循环，并拿到真实世界的反馈。

所以我更愿意把 Agent 理解成：

大模型外面包了一层会话管理、工具调用和执行控制。

如果只说标准代码 Agent 的最小能力，其实通常不用一下子讲得太复杂。

很多通用 Agent，最核心的工具往往就是这几类：

1. Bash
2. 文件读取
3. 文件写入或编辑

有了这几类基础工具，它其实就已经能完成很多真实任务。

至于技能，不是通用 Agent 必不可少的前置条件。技能更多是把一段已经验证过的流程，用文件和约定的方式沉淀下来，本质上仍然是建立在文件读写和工具调用之上的。

这一点如果想详细展开，可以直接参考 MiniMax 的这份说明：

Mini-Agent README_CN

所以这里我不打算把技能体系展开太多，而是先把大家带到同一个理解上：Agent 的底座首先是模型、会话和基础工具。

如果再往上抽象一点，一个通用 Agent 可以看成 5 个部件：

1. 模型
2. 会话
3. 工具
4. 技能
5. 执行环境

模型负责推理，会话负责上下文，工具负责和外部世界交互，技能负责沉淀可复用流程，执行环境负责真的把事情做完。

到这里，大家就可以把各种 Agent 产品都先看成同一类东西的不同实现，而不是完全不同的物种。

二、AI 实习生是什么

理解了通用 Agent 的工作方式之后，再回到 AI 实习生，事情就会清楚很多。

如果把这套东西落到我们自己的工程里，可以先看一张更具体的图：

graph LR
    User[用户\n企业 IM 群/私聊]

    subgraph Mini[Mac Mini]
        IM[企业 IM 回调]
        Bot[Bot 服务]
        OC[Agent Runtime\nAI 引擎]
        Skills[技能系统]
        MCP[playwright-mcp]
        Browser[Chrome Browser]
        IOSSkill[ios-simulator-control]
        iOS[iOS 设备/模拟器]
    end

    User -->|发送消息| IM
    IM -->|回调| Bot
    Bot -->|派发任务| OC
    Skills -->|挂载技能| OC
    OC -->|调用 MCP| MCP
    MCP -->|CDP| Browser
    OC -->|调用技能| IOSSkill
    IOSSkill -->|WebDriverAgent| iOS
    OC -->|生成回复| Bot
    Bot -->|回传响应| IM
    IM -->|回复| User

    style OC fill:#fff2a8,stroke:#d48806,stroke-width:3px,color:#222

这张图和前面第一部分正好可以接起来。

前面那张图讲的是通用 Agent 的最小工作原理，而这张图讲的是我们怎么把这套原理落成一个具体系统。

这里我特意把 Agent Runtime 高亮出来，因为它对应的就是第一部分讲的那个 Agent 核心循环。外围再由 Bot 服务 负责接入企业 IM、消息调度和回传，由 技能系统 负责技能沉淀。

AI 实习生 的具象能力，我觉得可以先看 3 个：

1. 它可以在企业 IM 群聊和私聊里接任务，并持续承接上下文。
2. 它不只会回文本，还能调用浏览器、iOS 模拟器、本地开发环境去做事。
3. 它可以把常见工作流沉淀成技能，后面重复复用。

所以它和普通 Bot 的差异不在于“回复得更聪明”，而在于它真的能交付结果。

如果要下一句最短定义，那就是：

聊天机器人回答问题，数字员工交付结果。

AI 实习生 之所以不是普通聊天机器人，主要有 5 个原因：

1. 它不只是生成文本。
2. 它有真实工具可调用。
3. 它有长期会话可承接。
4. 它有独立身份和权限边界。
5. 它有技能可以重复执行。

三、为什么 I/O 很重要

讲到这里，再回头看 I/O，位置就比较准确了。

这一部分我会先把第一部分的图再简化一下，只保留和 I/O 最相关的那层：

flowchart LR
    U[用户输入] -->|Input| A[Agent Loop]
    A -->|Output| R[产出结果]

这张图的重点不是讲完整执行链路，而是单独讲清楚：什么叫 Agent 的 I/O。

所谓 I/O，本质上就是用户把任务和上下文输入给 Agent Loop，然后 Agent Loop 再把结果输出回来。

I/O 不是 Agent 的全部，它只是用户最直接感知到的那层表皮。

底层真正相似的，还是刚才那套：模型、会话、工具、技能和执行环境。

但也正因为底层相似，所以 I/O 会成为大家最先感知到的差异。

比如：

1. 终端型 Agent 的 I/O 在 terminal。
2. IDE 型 Agent 的 I/O 在编辑器、代码文件、diff、diagnostics。
3. IM 型 Agent 的 I/O 在 WhatsApp、TG、企业 IM、飞书这类消息流里。
4. 设计型 Agent 的 I/O 在画布、图层、选区和预览结果里。
5. 剪辑型 Agent 的 I/O 在时间轴、素材轨道和导出结果里。

所以更准确的说法应该是：

Agent 最表层的差异，往往是 I/O 形式不同；但 I/O 背后接了什么工具、状态和执行环境，才决定它真正能做什么。

四、为什么我们把它放进企业 IM

接下来就是我觉得这套方案里最有价值的一个产品判断。

我们最后把 Agent 放进企业 IM，不是因为“企业 IM看起来更方便”，而是因为 I/O 的位置会直接决定 Agent 能不能进入现有工作流。

如果一个 Agent 只存在于独立网页里，大家一般要多做 5 件事：

1. 记住一个新入口。
2. 学一套新的交互方式。
3. 手动复制上下文。
4. 手动转发结果。
5. 手动拉人协作。

这样它就很容易停留在“演示可用”。

但放进企业 IM之后，事情就不一样了：

1. 用户不用迁移习惯。
2. 任务天然发生在原本的沟通场景里。
3. 转发、拉群、@人、追问都是原生能力。
4. 上下文天然跟着群聊和私聊流转。
5. 结果直接回到大家本来就在使用的地方。

所以这里最重要的一句话是：

我们不是要求人迁移到 Agent，而是让 Agent 迁移到人原本的工作流里。

如果再说得更工程一点：

企业 IM不是一个聊天壳，而是组织内部的协作总线。把 Agent 接到企业 IM 里，本质上是把 Agent 接进了现有的消息流、任务流和协作流。

五、我们的工程架构

接下来我讲一下 AI 实习生 的工程主干。

整个链路并不复杂，大致是这样：

1. 用户在企业 IM 群聊或者私聊里发消息。
2. 企业 IM 把消息回调给 Bot 服务。
3. Bot 服务 按聊天上下文派发任务。
4. Bot 服务 把任务交给 Agent Runtime 执行。
5. Agent Runtime 再去调用浏览器、iOS 模拟器、本地开发环境等工具。
6. 结果回传给 Bot 服务，再发回企业 IM。

如果压缩成一句话，就是：

企业 IM 负责协作场景，Bot 服务负责接入、会话派发和回传，Agent Runtime 负责推理和执行，工具环境负责把任务真正做完。

六、这套实现里最值得讲的几个工程点

1. 会话不是全局一个脑子，而是跟聊天场景绑定

这一点在 IM 场景里特别重要。

在我们的实现里，会话是按 chatKey 去承接的。这意味着：

1. 一个群聊有自己的上下文。
2. 一个私聊有自己的上下文。
3. 上下文天然跟协作场景绑定。

这也是为什么 IM 场景下的 Agent，会天然适合做长期协作。

2. 它不是所有消息都无脑回复

IM Agent 先要解决的不是“怎么回答”，而是“什么时候该说话”。

所以它会有：

1. @触发
2. 承接回复
3. [[NO_REPLY]] 这类抑制机制

这说明 IM Agent 的工程难点之一，其实是对话权控制。

3. 结果交付不是纯文本

Bot 服务 不只是转发一段控制台字符串，它还支持：

1. Markdown
2. 图片
3. 本地文件链接
4. @人

也就是说，它交付的是可用消息，而不是单纯一段文本。

4. 技能不是让模型变聪明，而是把流程产品化

技能系统 里已经有很多很典型的技能：

1. ios-simulator-control
2. live-test-suite
3. monorepo-repo-router
4. bus-release
5. bot-self-ops

这里最关键的理解是：

技能不是魔法，它的本质是把成功 workflow 沉淀下来，让 Agent 下次不用从零开始。

七、为什么一定要独立身份

这是我觉得这套方案里非常关键的一点。

AI 实习生 使用的是独立员工身份 agent_staff，而不是借用某个真人账号去执行任务。

这样做的好处很直接：

1. 权限审批路径清晰。
2. 风险边界清晰。
3. 被拉进新群时不会默认继承操作者本人的权限。
4. 审计边界清晰。

所以它和很多“主人替身机器人”的差异，不只是实现方式不同，而是安全模型完全不同。

八、我们为什么选择 Agent Runtime

在这套系统里，Agent Runtime 不是被当成一个单纯的 IDE 工具，而是被当成一个 Agent 引擎来使用。

我们最后选择 Agent Runtime，原因其实很直接。

第一，它是开源的。

第二，它有很好的会话管理，这对我们这种企业 IM 群聊和私聊场景特别重要，因为一个聊天场景天然就应该绑定成一个工作上下文。

第三，它有现成的 GUI，而且整体体验比较顺，方便查看和管理会话。

第四，它支持接入多家大模型供应商，这让底座不会被某一家模型能力或者接口形式锁死。

第五，它可以开启 serve 模式，SDK 也比较成熟，方便我们在外围再接 Bot 服务、技能系统 这些自定义能力。

如果再往上说一层，我们并不是认为 Agent Runtime 和其他 Agent 产品在原理上有本质差异。

所有这类代码 Agent，底层其实都是 Agent Loop，差别并没有大到换了一个物种。

所以我们的选择逻辑也很简单：既然大家底层范式差不多，那就优先选一个代码质量高、界面好看、会话管理成熟、serve 模式可用、SDK 比较顺手的底座。

如果放到市面产品里看，也可以顺手把这些东西粗分成几类：

1. IDE / 终端型，比如 Agent Runtime、Cloud Code、Cursor。
2. 多渠道个人助理型，比如 OpenClaw。
3. 聊天工作区型，比如 LobeChat。
4. 强调自学习 / 自进化叙事的，比如 Hermes Agent。

九、自我进化与 Hermes Agent

最近 Hermes Agent 很火，讨论度非常高。

如果把它放到更大的背景里看，很多人会拿它去和 Claude Code、OpenClaw 这类东西做比较。

其中它最容易被记住、也最容易被传播的卖点，就是“自我进化”。

所以这里真正要回答的问题不是“它火不火”，而是：它说的自我进化到底是什么，它和 OpenClaw 这种系统相比，到底多了什么。

我这里先说结论：

Hermes Agent 和 OpenClaw 的差别，绝对不只是多了一句“自学习”的 system prompt。

根据 Hermes Agent 公开 README 和开发文档，它至少明确强调了这些能力：

1. 内建学习闭环，从经验创建 skill，并在使用中继续改进。
2. 持久记忆，持续沉淀 memory，并跨 session 搜索过去对话。
3. 用户建模，逐步建立对用户偏好和习惯的理解。
4. 多平台 gateway，Telegram、Discord、Slack、WhatsApp、Signal、CLI 等共用一套入口。
5. 调度与自动化，内建 cron scheduler。
6. 子代理与并行，可以 spawn isolated subagents。
7. 多种执行后端，local、Docker、SSH、Daytona、Modal 等。

如果和 OpenClaw 对比，我会这样总结：

1. OpenClaw 更像多渠道个人助理底座。
2. Hermes Agent 在这个底座上，进一步把 memory、skill、search、automation、subagent、self-improvement 叠得更厚。

所以更准确的说法是：

Hermes Agent 不是只多了一个 prompt，而是把经验沉淀和持续改进做成了系统级能力。

这里可以顺势引一段最近流传很广的原文。那张推特图里最核心的话其实是：

After completing a complex task (5+ tool calls), fixing a tricky error, or discovering a non-trivial workflow, consider saving the approach as a skill with skill_manage so you can reuse it next time.

如果把这句原文翻成更自然的中文，大意就是：

完成复杂任务、修 tricky error、发现非平凡 workflow 后，把方法保存成 skill，方便下次复用。

这句话之所以有传播力，是因为它把“自我进化”说得很像一句 prompt 就能触发的高级能力。

但如果真的往下拆，Hermes 的做法并不只是这一句提示词。

Hermes Agent 主仓库 README 里明确写了这些内容：

1. creates skills from experience
2. improves them during use
3. nudges itself to persist knowledge
4. searches its own past conversations
5. builds a deepening model of who you are across sessions

这已经说明它至少包含：

1. skill 持久化
2. 记忆写入
3. 会话检索
4. 用户建模

这已经说明它的“自我进化”至少包含 skill 持久化、记忆写入、会话检索、用户建模这些系统能力，而不是单独一句 prompt。

再进一步，它甚至还有单独的 self-evolution 项目。

NousResearch/hermes-agent-self-evolution 的公开 README 写得更直接：它会优化 skills、tool descriptions、system prompts，后续还计划优化 code，而且整个过程带有 evaluation dataset、execution traces、constraint gates、tests 和 PR review。

所以如果要简要分析它的原理，我会概括成三层：

1. 第一层，用 prompt 提醒自己在复杂任务后沉淀 skill。
2. 第二层，把记忆、skill、会话检索这些能力做成持久系统。
3. 第三层，再通过 evaluation、trace、优化流程去持续改进这些技能和提示词。

所以我最后会把它总结成一句：

那句 prompt 更像是“提醒自己沉淀经验”的最轻量入口，但 Hermes 真正宣传的自我进化，是一整套围绕 memory、skills、search、evaluation 和迭代优化展开的工程机制，而不是只有一句 prompt。

十、把这个话题再落回 AI 实习生

讲到这里，再回到 AI 实习生，我们的方向其实没有做得那么复杂。

我们走的是一种更直接、更克制、也更省 token 的路线。

我们没有去做一整套复杂的自进化框架，而是直接用本地 Git 仓库管理一些 md 文档，再配备少量脚本，把高频业务动作沉淀下来。

比如：

1. 发布系统 打包、锁包链接这类发布动作，对应业务仓库里的 workflow。
2. iOS 模拟器操作，对应 ios-simulator-control。
3. 获取业务场景链接，对应 room-link-query。

我们故意把这些脚本和说明包装得非常窄，只保留当前业务这一步真正需要的内容。

很多时候，一份说明可能就一两百字，多余的选择都不给 AI，避免它在模糊空间里乱选。

也就是说，我们不是在追求一个高度抽象、强泛化的“自动技能进化系统”，而是在做高度特化的业务流程沉淀。

从技能编写经验上看，我们总结下来的原则大概是这样：

1. 尽量围绕具体问题写，不追求空泛抽象。
2. 尽量把流程说明写得高度特化，直接对应当前业务动作。
3. 尽量减少不必要的分支和选择，避免模型在模糊空间里乱选。
4. 尽量把真正要执行的脚本入口收敛到最小，让每一步都短、准、直接。

这个做法未必有很强的泛化价值，但它非常实用，非常省 token，而且很适合真实业务先跑通。

所以我最后想强调的不是“我们也要做一个 Hermes”，而是另一种更克制的判断。

我觉得“自我演进”这件事现在还在一个很新奇的阶段，先不要追求大而全，而是一步一步来。

对我们来说，眼下更重要的不是构造一个宏大的自进化体系，而是先把真实业务里的高频动作稳定沉淀下来。

从这个角度看，我们现在做的事情其实很朴素：

给旧接口包一层 markdown UI，再把它交给 AI 去调用。

在这个基础上，我们已经有了几件很重要的东西：

1. 我们已经具备了技能沉淀的容器。
2. 我们已经有了经验记录，比如 experience-notes。
3. 我们已经有了真实工具、真实脚本和真实工作流。
4. 我们下一步真正值得做的，是继续把这些高频动作沉淀得更短、更准、更稳定。

收束

最后我想留下来的，不是某个概念词，而是这句话：

我们不是做了一个会聊天的机器人，而是把一个通用 Agent 工程化成了一个有独立身份、能在企业 IM 里协作、能调用真实工具交付结果的数字员工。

附录：参考依据

OpenClaw

1. v1.3.0 README: warelay
2. v2.0.0-beta1 README: CLAWDIS
3. v2026.1.5 README: Clawdbot
4. rename commit: Moltbot -> OpenClaw

Hermes Agent

1. NousResearch/hermes-agent README
2. NousResearch/hermes-agent AGENTS.md
3. NousResearch/hermes-agent-self-evolution README

中国高超音速技术领先全球的核心在于拥有以 JF-12 和 JF-22 为代表的尖端超高速风洞群，实现了高马赫数（可达30倍以上）与长实验时间（百毫秒级）的复合能力。通过“爆炸驱动”等创新技术，这些风洞能够真实复现极高空、极高速的飞行环境，使得高超音速飞行器不仅研制快，且成功率高。

核心结论

1. 写代码正在变得极其便宜，但判定代码对不对的成本没有同步下降。

2. 研发流程应该从“控制实现过程“转向“定义交付结果和验收标准“。

3. 两个 AI 落地抓手：代码找得到、结果看得到。

已经发生的事

2026 年 2 月，Cloudflare 一名工程师用 AI 在 Vite 上重新实现了 Next.js 94% 的 API——路由、SSR、RSC、Server Actions、缓存、中间件，全部从零写。一个人，800 多次编程会话，一周，约 1100 美元 token 费。项目叫 vinext，已开源，带 1700 多个单测和 380 个端到端测试。

他怎么做到的：对着 Next.js 的 API 行为规范，让 AI 反复实现、测试、修正，直到行为一致。

既然 AI 只需要验收标准就能实现目标，那我们花在设计、评审上的过程时间，还有多大价值？

AI 不能一枪必中，人也不能。

但人会多开几枪。

本文的三个前提

前提一：符号处理成本在快速下降

以 Claude 为例。24 年 3 月，Opus 3 定价每百万 Token 15/75 美元。三个月后 Sonnet 3.5 多数基准超过 Opus，价格只有20%。到 26 年初，Opus 4.6 定价 5/25 美元，Sonnet 4.6 只要 3/15 美元。

仅两年，同等能力的成本下降了一个数量级，上下文也从 200K 扩到了 1M。蒸馏、量化、KV缓存、专家网络、专有芯片也都在持续降低推理成本。

前提二：研发的大部分产物是符号

代码、配置、接口定义、测试用例、文档、日志、SQL、页面结构——都是符号。

前提三：研发的目标是结果，不是过程

代码不是目的，技术方案不是目的，过程文档不是目的。

目的是：在给定约束下，稳定产出符合预期的结果。

软件系统是实现目标的手段；研发流程又是实现软件系统的手段；过程文档是实现研发流程的手段…

瓶颈转移：从“写“到“验“

软件开发的核心就两件事：写和验。AI 让前者成本急剧下降。

软件成本 = 编码 + 测试

推理成本在快速下降。但工具调用（备环境、跑测试、取日志）成本没降。涉及物理世界的（硬件联调、用户实验、网络环境）更是。

数据很清楚。Faros AI 对 1 万多名开发者、1255 个团队的遥测数据：高 AI 采用率的团队任务量多 21%，PR 合并多 98%——但审查时间多 91%，PR 体积大 154%，bug 率升 9%。更要命的是，同一批团队的 DORA 指标（部署频率、交付周期、变更失败率、恢复时间）几乎没变。代码多了，交付没快。工作没消失，从“写“挪到了“验“。
Sonar 2026 全球开发者调查（1100+ 人）：96% 的开发者不完全信任 AI 代码的功能正确性，59% 认为审查 AI 代码要花“中等“或“大量“额外精力。Anthropic 自己也碰到了——工程团队代码产出过去一年涨了 200%，2026 年 3 月专门推出 Claude Code Review 来解决审查瓶颈。GitHub Octoverse 数据：约 41% 的新代码由 AI 辅助生成，月推送超 8200 万次。

过去：想法多，写出来贵
现在：写出来便宜，不知道哪个是对的

有人问：AI 代码不是越来越准了吗？确实，但要看这个“准“是哪层。

AI 能写出语法正确的代码，很大程度上靠 Compiler 和 Linter。在 Agent 循环，它们能提供毫秒级的反馈——变量不存在、类型不对、导入缺失，眨眼 AI 就能改正。

但难的是第二层：业务逻辑对不对、运行行为符不符合预期、场景覆盖全不全。这些必须让代码真正跑起来，获得真实世界的反馈。

静态验证（类型、语法）已经趋近于零，动态验证（业务）依然昂贵

深一点，孤立系统的熵不会自发减小。完全封闭在符号世界里的推理，产出的只能是“阴阳五行”般自洽但无用的符号闭环。

如今的 Agent 的幻觉降低，很大程度来自我们教会了它去使用 Bash、Python、WebSearch 获得真实世界的负熵。

验证，是把 AI 拉回现实的锚。

实践是检验真理的唯一标准。

流程变革：从“先拍板再实现“到“先实现再筛选“

过去的生产流程是围绕“研发很贵”设计的，都是尽可能用评审时间，去保护昂贵的研发时间。

但 AI 大幅降低开发成本后，人的评审、测试验收反而变最贵的环节。与其花时间争论哪个方案好，不如让 AI 先干再说。

评审只需一个：需求评审——本质就是“验收标准评审“。明确定义业务的输入、输出，要什么结果。

这里有一个关键：验收标准应当是可自动执行的量化的标准，而不是架构、规范之类的散弹枪许愿——全看 AI 道德。

代码越来越像可再生资源，验证体系越来越像稀缺资产。

开头提到的 vinext，关键不在“AI 能写代码“，在于 AI 是对着行为规范搜索兼容实现的。没有明确的行为标准，这事做不成。真正的资产不是 Next.js 的源代码，而是它定义了“什么行为算正确“。
SQLite 代码完全开源，但核心测试框架 TH3 闭源，需要授权。核心代码 15 万行，测试代码 9200 万行——比例约 600:1，100% MC/DC 覆盖。
代码开源，测试闭源。没有完整测试套件，你没法保证数据库不丢数据。护城河不是代码，是验证体系。
2026 年 2 月，开源绘图工具 tldraw 在 GitHub 提出把测试套件（约 327 个文件）从开源仓库迁到闭源仓库（Issue #8082）。理由直接：vinext 证明一套完整测试就够 AI 从零重建整个项目，测试正在成为开源项目最需要保护的资产。提案在 Hacker News 引发大量讨论。这不是个别现象，是趋势。

两个基建：代码找得到 + 结果看得到

做 AI 落地，顺着直觉就是做知识库、写规范…

但它们真的提供信息了吗？

基建一：代码找得到

代码有最全的信息。

微服务架构下，每个服务仓库只有自己一小片的上下文。AI 在一个服务里排查问题，爬到边界就断了，然后人去找另一个服务的人，那边人再问 AI…
本来能在代码里顺着调用链就能爬通的事，变成了：AI → 人 → 人沟通拉会 → 人 → AI。

建立统一仓库（monorepo）就是最简单的手段，让完整的信息对 AI 来说像本地文件一样简单、直接、可访问。

顺着这个思路，很多过程文档的价值也在变。所有的信息，比如 SPEC 文档、设计文档、架构说明里描述的约束、数据流和交互细节，最终都会实现在代码里；代码仓库也就自然成了唯一持续更新的信息，代码之外的文档都会随着迭代逐渐过时不可信。

事实上，大家现在也不怎么搜文档了：都是直接对着仓库问，然后 AI 根据问题追查代码生成“一次性文档”。“现炒”便宜方便，谁还吃“预制”？

所以，代码仓库是唯一的 source of truth，索引和目录文档都只是它的视图，只负责指路，不承载事实本身。

基建二：结果看得到

运行结果产生纠偏信息。

现在的 AI 编程瓶颈不在写代码，在于写完之后：谁来跑、谁来看结果、谁来判断对不对。大多数时候是人——人启动服务，人点页面，人查日志，人看监控。AI 写完代码就停下来等，等人告诉它结果，它再改，再等。一轮几秒钟的代码修改，卡在几分钟甚至几小时的人工验证上。在工厂里，人可以停，但机器不能停——现在 AI 是那台机器，人的验证速度成了产线瓶颈。

要让 AI 自己闭环，两件事要通：

• 第一，能跑起来——AI 能自己启动程序、触发操作（运行环境）；

• 第二，能看到结果——AI 能自己看到日志、埋点、数据库等运行结果（机器接口）。

代码找得到，让 AI 有了完整的符号世界；结果看得到，让它有了闭环修正的反馈机制。两个一接通，AI 就能在符号空间里持续闭环优化——因为优化本身也是符号操作。

有些场景看起来难测——分布式故障、安全攻击、硬件交互——但本质上也是同一问题：怎么把现实世界建模到符号世界。

AI 是符号世界的神，是人类发明的通用符号变换器，只要能把智力任务建模成符号变换，AI 就能闭环。

就像通用动力源蒸汽机：只要能把生产过程分解为往复、旋转、推拉等周期性物理运动，蒸汽机就能取代人力。

在这之后：从“造出来“到“搜出来“

一旦有了验证标准，软件研发就可以从“构造问题“变成“搜索问题“。

以前：人一步步把程序写出来。
以后：人定义目标和约束，AI 在符号空间里搜索满足约束的程序。

就像做一个不定积分，C 取多少都对。软件也一样——通过所有测试的实现可能有好几种，每种都“正确“，但可读性、复杂度各不相同。

AI 负责找出所有满足约束的解，人根据自己的品位和工程判断，挑一个最合适的。

最终，可能就在一年后

人类下午讨论、AI 半夜干、人类上午验收反馈、AI 中午修正、人类下午体验讨论、AI 凌晨继续干…

人类和 AI 在不同的时区两班倒，产线以半天为单位高速迭代。

---

附录

核心论断

• “推理成本指数下降，验证成本基本不变。两条曲线反向运动，瓶颈就在这。”

• “静态验证已趋近于零，动态验证依然昂贵。编译通过不等于业务正确。”

• “没有真实反馈的符号推理，只会退化成自洽但没用的闭环。测试是把 AI 拉回现实的锚。”

• “代码越来越像可再生资源，验证体系越来越像稀缺资产。”

• “阻碍 AI 闭环的不是 AI 不够聪明，是上下文路由成本和验证系统不可编程。”

• “满足约束的解不止一个，AI 负责搜索，人负责用品位挑最好的那个。”

• “代码是唯一的 source of truth，文档只是它的视图。”

• “Context, not control.”