Last updated on

别再当 AI 的「上下文搬运工」，去当它的「环境架构师」

一套和 AI 协作的方法论：把「人在回路里验证一个改动」这件高频苦活，逐项拆成 AI 能自取、自跑、自判的机器能力。

背景

我在公司里需要并行开多个 Agent，快速做产品迭代。瓶颈很快从「AI 写代码」变成「人能不能跟上验证」——这套方法论就是从这个痛点里长出来的。

为什么是现在

过去 AI 弱，协作模式是人不断把上下文喂给它——贴日志、贴截图、解释「现在系统处于什么状态」「这个报错意味着什么」。单线程协作里这还能忍；一旦并行，这条路立刻不可扩展：人喂多快，AI 才能走多快；人一离场，AI 就瞎。你不是在和一个能干活的伙伴协作，你是在给一个健忘的实习生当人肉传感器。

模型变强之后，瓶颈换了位置。今天更划算的做法是人把环境搭好，让 AI 自己去取上下文：给它可编程的入口、结构化的事件、可寻址的证据、自描述的索引——AI 按需拉取、逐层探索，而不是等人投喂。

人的角色随之上移：不再当 AI 的「上下文搬运工」，而当它的「环境架构师」。你只做 AI 做不动的关联判断——这件事值不值得做、这条链路应该长什么样、出了边界要不要拦——把其余可形式化的部分一次性工程化下去。

这其实是业界两条实践的合流：

  • 上下文工程（context engineering）：不预先把全部数据灌进模型，而是给它轻量句柄（文件路径、会话 ID、查询接口），让它在运行时按需、渐进式地取，只保留「最小的高信号 token 集」，避免上下文被噪声淹没。
  • Agent-Computer Interface（ACI）：把系统能力做成为 AI 而非为人设计的接口。SWE-agent 的结论很直白——同一个模型，接口调好和没调好，任务成功率差一大截。能力存在 ≠ AI 用得上。

下面这套方法，就是把这两条思路落到并行协作里最高频、最卡脖子的事上：验证一个改动到底有没有跑通。 你并行开的 agent 越多，这件事的边际成本就越不能靠人肉线性堆。

核心命题

把「人在回路里验证一个改动」这件事，逐项拆成机器能力，机器能补的全补上，只把无法形式化的判断留给人。

你回想一下，人验证一个改动时，脑子里在干什么？大概是这 6 件事，每一件都对应一个可以被机器接管的能力原语：

人肉动作机器能力（原语）
点 UI 触发操作驱动 Drive
看发生了啥（翻日志 / 看界面）观测 Observe
判断对不对（对照预期）判定 Assert
出错时定位断在哪一层归因 Localize
串联跨服务的证据取证 Evidence
（元）知道这些能力存在发现 Discover

第一性原则：这 6 个能力必须配套成闭环。只观测没判定，AI 看到一堆事件也不知道算不算成功；只判定没驱动，还得喊人去点。单个工具没价值，闭环合拢才有价值。 评估「某条链路的 AI 协作做没做完」，唯一标准就是：闭环是否合拢——AI 能不能无人介入地跑完「驱动 → 观测 → 判定」。

六个能力原语

1. 驱动 Drive —— 让 AI 能像人一样发起操作

抽象：暴露一个可编程入口，让 AI 用代码触发本来要靠 UI 手点的操作。

铁律：必须复用真人同款 handler，不能另开一条旁路。否则你验证的是一条假链路——AI 跑通的那条路，用户根本不会走。这是整套设计的命门。

接口为 AI 设计（这就是 ACI）：注意这里有个微妙的张力。链路要走真人同款 handler（保证验证的是真链路），但入口和回执的形态要为 AI 优化——意图化的程序入口、清晰的参数、机器可读的回执，而不是逼着 AI 去点 UI、读截图。「链路一致」和「接口为 AI」不打架：前者管「走的是不是同一条路」，后者管「AI 上不上得了这条路」。

泛化：任何「有 UI 才能触发」的动作，都该有一个意图化的程序入口。这个驱动通道可以是挂在前端全局上的意图注册表、一个远程调试协议（如 Chrome DevTools Protocol），或一个后端 API——形态不重要，能让 AI 用代码发起、且走的是真链路，才重要。

2. 观测 Observe —— 让系统自己说出发生了什么

抽象：在关键节点吐出结构化事件（谁 / 在哪一层 / 什么时刻 / 发生了什么 / 带什么数据），而不是让 AI 去 OCR 截图、用正则爬非结构化日志。

铁律：机器可读优先。截图和自然语言日志是给人看的；AI 要的是带 schema 的事件。一句话——凡是能结构化的，绝不留给截图。

按需 ≠ 全灌：观测的产物要让 AI 按需、渐进式地取，别一次性把全部日志灌进它的上下文。给它轻量句柄（一个会话 ID、一个文件路径、一个能按条件过滤的查询接口），让它自己摘出当下需要的那一小段。上下文是有限资源，目标是「最小的高信号 token 集」——灌爆和不给，一样有害。

泛化：每条关键链路都该有探针点；事件 schema 尽量统一，这样一套观测 / 判定 / 取证工具才能跨模块复用。一个够用的通用事件模板长这样：

{ "ts": 1700000000, "origin": "agent", "component": "http",
  "event": "http.response", "sessionId": "s_…", "payload": { "version": 42 } }

3. 判定 Assert —— 把「对不对」写成机器能跑的契约

抽象：把「成功长什么样」固化成可执行的断言——期望的事件序列、字段约束、状态迁移、版本号 +1……

铁律：必须可证伪。没数据要 FAIL，缺一环要 FAIL，绝不能让 AI 自我安慰成「看起来没报错，应该过了吧」。断言脚本自身要有「无证据 → FAIL」的自检——这是 AI 最容易骗自己的地方，也是最该用机器堵死的地方。

泛化：每个场景定义自己的「黄金序列 / 不变量」。判定要和观测分离——同一份事件流上可以挂多套断言（保存成功一套、协作合并一套、权限拦截一套），互不干扰。

4. 归因 Localize —— 出错时直接指到「哪一层 / 谁干的」

抽象：每条事件都带分层标签（在哪一层：编辑层 / 网络层 / 持久化层……）和来源标签（谁触发的：用户 / AI / 系统），让「哪一环断了」「这是谁干的」一眼可读。

铁律：当多方共用同一个证据池时，来源归因不可省。真人、AI、其他自动化进程的事件全混在一起，靠来源标签 + 会话 ID 才能各自摘出来对照。并行协作时这一点尤其致命——三个 agent 同时改同一条链路，没有来源标签，你连「这是谁干的」都分不清。

泛化：「来源」（user / agent / system）和「层」是两个正交的维度，几乎任何场景都适用。归因做好之后，报错会从「保存失败」升级成「网络层发出了请求，但持久化层没回 ack」——前者只能干瞪眼，后者直接告诉你去哪儿修。

5. 取证 Evidence —— 一张「现象 → 证据在哪」的地图

抽象：维护一张**「看到某个现象，该去翻哪个日志 / 哪张表 / 哪个端点」**的对照地图，再配一个一键采集器（给定一次操作的会话 ID，把它的全栈证据一次摘出来）。

泛化：这本质上是把「老工程师的肌肉记忆」显性化、可寻址化。每个系统都该有自己的这张地图；采集器的接口尽量统一，AI 才不用每次都重新学一遍「证据藏在哪」。

6. 发现 Discover（元能力）—— AI 怎么知道这些能力存在

抽象：能力必须自描述 + 被索引，否则等于不存在。

泛化：两个层面——一个进仓库 / 进项目就能看见的索引（一份给 AI 看的 README / 能力清单），加一个运行时能现场自查的接口（help() / listIntents() 之类）。

这条最容易被漏掉，也最致命：任何新建的协作能力，最后一步永远是「登记到 AI 能发现的地方」——这一步漏了，前面全白做。 你造了一把绝世好刀，但没人知道它在抽屉里，那它就不存在。

横切设计约束（决定它能不能被长期信任、长期复用）

  1. 链路一致性：AI 走真人同款路径。→ 验证才有意义。
  2. 生产零影响 + 不打扰人：能力默认 no-op、仅在开发态启用，绝不擅自重启别人的进程、不改别人的启动脚本。→ 没有人因为你的工具被打扰，它才会被保留下来，而不是第二天被人删掉。
  3. 分层下沉：探针埋在最底层的共享代码里，应用层零重复。→ 一处埋点，所有上层受益。
  4. 半场分离：把驱动半场和判定半场拆开。→ 可以分别跑、可以替换驱动通道、断言逻辑可以独立复用。
  5. 统一事件契约：跨模块共享同一套事件 schema 和落点约定。→ 一套工具吃遍所有链路，复利就来自这里。

人机边界：什么坚决留给人

不是所有事都该往机器上挪。判据很简单：能写成「期望 X，实际 Y，比对」的，归机器；只能靠「我觉得」的，归人。

留给机器（可形式化）留给人（主观 / 审美 / 产品）
数据流是否贯通、版本号是否 +1排版好不好看、间距对不对
字段约束、状态机迁移是否合法交互手感、动画顺不顺
权限是否按预期拦截这个功能该不该做、产品取舍
跨服务事件是否齐全、有序文案语气、视觉一致性

而这套方法论的本质，就是不断把右边的东西想办法挪到左边。一个经典例子：视觉回归测试，就是把「这个页面好不好看 / 有没有改坏」这种看似主观的事，形式化成了「像素 diff 超没超阈值」。今天归在右边的东西，明天可能就有办法挪到左边——边界是动态的。

Playbook：怎么把这套套到一个新场景

第 0 步  选一条「人最常手动验证」的高频链路（痛点最大、回报最高的先做）
第 1 步  观测：在关键节点埋结构化事件（复用统一 schema）
第 2 步  驱动：给这条链路一个意图化入口，复用真人 handler
第 3 步  判定：写下「黄金序列 / 不变量」，做成可证伪的断言
第 4 步  归因 + 取证：补上「层 / 来源」标签 + 这个场景的证据地图
第 5 步  发现：登记到 AI 能发现的索引 / 运行时自查接口里
──── 闭环合拢的标志：AI 能无人介入跑完「驱动 → 观测 → 判定」 ────

复利从哪来？每套一个新场景，前几步会重做，但观测的 schema 和判定的框架是可复用的——做的场景越多，新场景的边际成本越低。

成熟度阶梯：自评你的链路到 L 几了

L0  人肉      ：人点 UI、人翻日志、人判断
L1  可观测    ：有结构化事件了，但还得人去读
L2  可判定    ：有断言了，人触发之后机器判对错
L3  可驱动    ：AI 自己触发 + 自己判定（半自动闭环）
L4  自主闭环  ：AI 无人介入跑完整条链路 + 跨服务取证
L5  自愈      ：失败能自动定位、提方案、甚至自修

关于 L5，别当它是科幻。 自愈说穿了就是「判定」反过来喂「驱动」——一条失败的断言（期望 X、实际 Y、断在哪一层）本身就是最好的修复信号。业界已经在跑的 evaluator-optimizer / 自改进循环就是这个形状：一个 AI 产出、另一个 AI 拿契约判定并把反馈回灌，循环到通过为止；更进一步，AI 还能分析自己的运行记录，去优化它所依赖的那些工具。

而 L5 的着力点，恰恰是前面的归因（原语 4）给的：故障一旦被精确归因到某一层，就有了自动补救的抓手。 比如「首次提交因版本陈旧而冲突」这种确定性的失败，完全可以让驱动器自动拉取最新版、重试一次——这已经是 L5 的雏形了。归因做得越细，自愈就够得越着。

一句话记忆

观测让系统开口，驱动让 AI 动手，判定让对错可证伪，归因让故障可定位，取证让证据可寻址，发现让能力可被找到——六者合拢成闭环，AI 才真正进了回路。

立场再钉一遍：别再当 AI 的「上下文搬运工」，去当它的「环境架构师」——把可形式化的部分一次性工程化下去，让 AI 自取、自跑、自判，人只保留那些无法形式化的判断。

实践：Worktree + PR 并行

总纲一句：写在支线、跑在主线。

  1. 你发需求 → Agent 开 linked worktree 做分析；方案写成文档，和代码 commit 到同一分支（PR 里方案 + 代码一起看）。
  2. 代码在 linked worktree 改。支线只做静态活（分析 / 改码 / lint / typecheck）——这里没有 node_modules，也没有跑着的 app，跑不了探针、做不了执行。
  3. 做完直接提 PR，不等你点头。
  4. 你在 PR 里看方案、扫代码。
  5. 你发话 → 我把 main worktree checkout 到该分支（会先 remove 同名 linked worktree——一个分支不能在两处 checkout）。
  6. 在 main worktree 跑 dev + 探针自验证，你做回归。执行只在主线。
  7. 你说「可以合」→ 我才合；合后 main worktree 切回 main branch，清理残留 worktree。

为什么拆成两条线？并行开多个 Agent 时，每个任务占一个 linked worktree、一条分支，互不挡路；但 dev server、探针、运行时状态只能有一份——强行在每个支线各起一套，又慢又乱。静态改动可以并行堆，驱动 / 观测 / 判定收拢到 main worktree 上跑，人和机器各干该干的那半场。

这条实践对应上文「横切约束」里的半场分离：支线交付 diff + 方案，主线负责执行与验收。

延伸阅读

这套方法论不是凭空造的，对应了几条公开的行业实践，想深挖可以顺着读：