共享环境：把工作现场从个人电脑搬出来
共享环境：把工作现场从个人电脑搬出来
——「人 × Agent 协作」系列 · 第 5 篇
前面四篇，我们建立了一套看似完整的体系：AI 接手机械工作，AI review 治理 AI 产出，三角结构管控整个流程。但如果你真的去试着落地，会撞上一个最容易被忽视、却最致命的问题。
这个问题和模型能力无关，和 prompt 工程无关，和流程设计也无关。它是一个物理问题：
当 AI 把代码写完、把 review 做完、把工单处理好之后，人要真正验收这些工作时——他面对的是什么？
它是整套协作模式能落地的物理基础。
一个被所有人忽视的"最后一公里"
让我还原一个让你会心一笑的场景。
某个 Agent 接到一个任务：修复一个线上 bug。他分析根因、定位代码、写好补丁、跑通本地测试，然后提交了一个 MR，并在 MR 描述里认认真真写了一段话：
"已修复 HAR-xxx 问题。根因是 A 模块的缓存 key 没有带 documentId，导致并发场景下串读。已在分支
fix/har-xxx修复，本地回归通过。验收时请关注 B 流程的审核结果。"
一个工程师接到 review 任务，打开 MR，看到代码——这部分没问题。然后他想实际验证一下运行效果。于是：
- 先把分支拉到本地：
git fetch && git checkout fix/har-xxx。 - 发现本地依赖是半个月前的，
pnpm install跑了 5 分钟。 - 启动本地数据库，发现 migration 没跑，跑了一遍。
- 想复现 bug，但不知道该用什么测试数据——Agent 用的那批材料，在他本地根本没有。
- 好不容易凑出数据，跑了一遍流程，又发现某个环境变量配错了，服务起不来。
- 折腾了两小时，终于跑通了，验证了修复有效。
这两小时里，工程师做的每一件事，都不是 review，也不是判断。 它们是纯粹的"把环境跑起来"的体力活。而这套协作模式前四篇积累的所有效率——AI 自动分析、AI 自动 review、自动化巡检——在这两小时里全部漏光了。
这就是"最后一公里"问题。它的本质是：Agent 完成了他的工作，但他完成的是一段"代码 + 文字说明"，而不是一个"人可以直接接手的工作现场"。
三个协作断点：为什么"交付代码"不等于"交付现场"
让我们把这个问题拆开，看清它到底断在哪里。我们团队踩过无数坑之后，总结出三个协作断点：
断点一：代码 Review 和功能验收脱节。 MR 可以让人 review 代码——这部分是数字化的、可追踪的。但"这段代码运行起来到底是什么效果"，却藏在某个人的本地环境里。Agent 说"我已经验证过了"，可他验证用的是他自己电脑上的数据、他自己配的环境、他自己的租户。Reviewer 想看运行效果，只能选择：要么信任 Agent 的描述，要么自己从头搭一遍环境。前者丧失了 review 的意义，后者重复了 Agent 已经做过的劳动。
断点二：Agent 完成 ≠ 人可以验收。 Agent 说"已经修好"，这句话是廉价的。它不包含任何可被独立验证的证据。人接手后，第一件事不是"判断这个修复对不对"，而是"先花时间把环境跑起来"。判断被环境搭建挤掉了。一个本该是"高质量人机协作"的节点，退化成了"人给 Agent 打下手"。
断点三：工作状态无法稳定交接。 更隐蔽的问题是，当换一个人、或者换一个 Agent 来接手时，前一个执行者的环境、材料、上下文几乎无法完整复用。所有这些状态都留在某个人的电脑里——本地数据库的状态、Redis 里的临时数据、测试租户里造的规则和材料、"这个 bug 要怎么复现"的个人经验。换人 = 从头来过。
这三个断点，指向同一个根本问题：
传统开发流程，把大量关键状态留在了开发者电脑上。代码、数据库、配置、测试数据、复现经验——全是个人的、本地的、不可共享的。
只要这个现状不改变，无论 AI 多强、review 多智能、自动化多严密，人接手的那一刻，永远要重新搭一遍环境。这是协作效率的真正天花板。
解法：把协作中心从"电脑"搬到"共享对象"
我们的解法，是做一次协作中心的迁移。
传统流程里，协作的中心是"开发者电脑"——所有状态都围绕某台机器组织。我们把协作中心迁到两个共享对象上：
- MR（Merge Request）：承载可审查的代码变更、commit 历史、Pipeline 结果、决策记录。它是代码层面的共享现场。
- Review App：承载当前 MR commit 的真实运行状态——跑起来的服务、准备好的数据、可点击的验收入口。它是运行层面的共享现场。
这两个对象，都是脱离任何个人电脑的。它们存在于 GitLab 和云平台上，任何人（包括任何 Agent）都能访问，且状态明确、可追踪。
这次迁移带来的根本改变是：Agent 不再只交付"代码已写完"，而是同时交付一个完整的、可进入的工作现场。 一个 Agent 完成任务后，他交付的是：
- 一个可以审查代码的 MR；
- 一套运行着当前 MR commit 的独立环境；
- 一个可以直接点进去验收的入口（带短期凭证的协助链接）；
- 已经准备好的测试租户、规则、额度、材料和模拟批次；
- 自动检查的结果，或者清晰的失败证据和复现入口。
而人接手时，不需要搭任何环境。他打开 MR 看代码，点 Review 按钮直接进入运行中的环境验收功能。判断和环境搭建，终于解耦了。
三方职责的重新划分
共享环境这件事，看起来只是"多部署一个临时环境"，但它实际上重新定义了人、Agent、平台三方的职责边界。这次划分，是这套协作模式最反直觉、也最核心的设计之一：
| 参与者 | 负责 | 不应承担 |
|---|---|---|
| Agent | 分析问题、建立证据链、修改代码、运行测试、准备数据、创建环境、执行标准 E2E、整理失败信息 | 代替人做最终工程判断和业务取舍 |
| 人 | 明确目标与边界、Review 代码、在 Ready 环境中验收功能、决定合并或继续修改 | 手工搭建验收环境、重复导入数据、查找临时入口 |
| CI / 平台 | 保存共享状态、运行指定 commit、隔离资源、提供入口、记录结果、回收环境 | 解释无法机器化的复杂业务口径 |
请注意"不应承担"那一列——这才是这张表的精髓。
- Agent 不应承担"最终判断"——他能准备一切，但拍板的是人。
- 人不应承担"搭环境"——他能判断一切，但搬运数据不是他的活。
- 平台不应承担"业务口径解释"——它能跑一切、记一切，但"这个 case 到底该怎么判"它管不了。
这张表背后，是一句贯穿全系列的话（也是这套模式的灵魂）：
自动化的目标不是减少人的参与，而是把人的参与推迟到真正需要判断的节点。
共享环境，正是这句话的物理体现。它把"搭环境、造数据、找入口"这些不需要判断的体力活，从人的肩上彻底卸下，全部交给 Agent 和平台。人剩下的，只有那两件真正需要他的事：
- 代码是否正确、清晰、可维护。
- 产品行为是否符合真实业务预期。
"环境已经 Ready"：一个被重新定义的完成标准
但这里有个陷阱：如果 Agent 说"环境已经 Ready 了"，人怎么知道这是真的？
最常见的误解是：把"Pipeline 跑完了""批次执行 completed 了"等同于"环境 Ready 了"。这是错的。一个 Pipeline 绿灯，只代表构建和部署的机械流程走完了；一个批次 completed，只代表任务执行链路结束了——它们都不能证明"人现在可以进去验收了"。
我们为此定义了一个严格的 Ready 标准，Agent 把任务交给人之前，环境必须同时满足：
- 当前 MR commit 已完成生产构建并部署（不是 dev 构建）。
- 管理端和验收租户的 readiness 接口，都返回当前 commit SHA——证明跑的就是这个版本。
- 数据库 migration 已完成。
- 测试租户、规则、额度、材料包、模拟批次已全部准备。
- 协助链接已验证，可以直接进入正确租户。
- 标准 E2E 已通过，或者失败原因、日志、复现入口已经整理清楚。
- MR、manifest、运行环境、验收结果，指向同一个 commit。
最后一条最关键。它要求"代码、环境、数据、入口、验收预期"同时对齐。任何一个环节指向了不同的 commit，整个 Ready 状态就作废——因为你不知道你验收的，到底是不是你以为的那个版本。
这个标准看起来繁琐，但它的意义在于：它把"完成"从一个模糊的主观判断，变成了一个可机器验证的客观清单。 Agent 不能凭感觉说"好了"，他必须让每一项都通过检查。这也是"用 AI 治理 AI"思想在工程层面的延伸——前一篇是 AI review 治理代码产出，这里是机器门禁治理"完成状态"。
从协作问题到工程能力：一张对照表
共享环境听起来美好，但落地需要解决一堆具体的工程问题。我们把这些协作问题和对应的工程能力做了一张对照表，它是这套模式的落地蓝图：
| 协作问题 | 需要的工程能力 |
|---|---|
| 人无法复用 Agent 的本地环境 | 每个 MR 创建可共享的远程 Review App |
| 不知道环境运行的是哪个版本 | readiness 与 manifest 强制绑定 commit SHA |
| 多个 MR 相互覆盖 | Worker、Container、数据库和域名按 MR 隔离 |
| 人仍要寻找账号和入口 | Review 按钮直接提供短期协助链接 |
| 每次验收都要重新造数据 | 自动准备固定租户、规则、额度、材料和批次 |
| "执行完成"无法证明功能正确 | 标准 E2E 断言最终业务 decision |
| 临时环境持续产生费用 | 手动创建、合并/关闭停止、TTL 回收 |
| 失败后现场消失 | ready 后失败保留环境和日志用于诊断 |
这张表值得逐行读。每一行左边，都是一个真实的协作痛点——它们看起来琐碎，但每一个都足以让人接手时卡住。每一行右边，都是一个对症的工程能力。你会发现，共享环境不是"多部署一个东西"那么简单，它是一整套面向协作的工程基础设施。
其中有两行特别值得展开，因为它们体现了最深的洞察：
"readiness 与 manifest 强制绑定 commit SHA"。 这是解决"我验收的到底是不是这个版本"的唯一办法。环境会告诉你它跑的是哪个 commit，验收结果会记录是在哪个 commit 上做的——三者必须一致，否则作废。这把"版本漂移"这个隐蔽的协作杀手，彻底锁死了。
"标准 E2E 断言最终业务 decision"。 这一行是下一篇（第 6 篇）的伏笔。它说的不是"E2E 跑通了"，而是"E2E 断言了最终的业务判断是对的"。一个批次跑完不等于结果正确——正例必须通过、反例必须被拦。这是"机器门禁只管机器能管的"的起点。
为什么"共享环境"是这套模式的物理基础
让我把这一篇的视角再拉高一次。
回看全系列：第 2 篇讲 AI 接手机械工作，第 3 篇讲 AI review 治理 AI 产出，第 4 篇讲三角管控。这三篇解决的，都是信息层面的问题——怎么让信息流动得更高效、更可靠。
但信息最终要落到物理层面才能被验证。一段代码对不对，要跑起来才知道；一个修复有没有效，要在真实环境里复现才作数；一个业务流程通不通，要真的点一遍才算。而这些"跑起来、复现、点一遍"，全都需要一个真实运行的环境。
如果这个环境不存在，或者只存在于某个人的电脑里，那前面所有的信息层优化，都会在"最后一公里"失效。Agent 写得再快，人 review 得再智能，自动化巡检得再严密——人接手时还是要花两小时搭环境，一切归零。
共享环境，就是把这套协作模式从"信息层"锚定到"物理层"的那根钉子。 它保证了：无论信息怎么流转，无论 Agent 和人怎么异步协作，最终都有一个所有人都够得着、状态明确、可独立验证的现场，作为协作的共同地基。
这也是为什么我们把 Review App 和 MR 称为"两个共享对象"——它们不是工具，是协作的锚点。没有它们，协作就退化成了"Agent 发一段文字，人自己脑补现场"。
一个对照：Cloudflare 的"本地共享环境"
讲到这里，可以呼应一下第 3 篇提到的 Cloudflare 设计。
Cloudflare 的 AI review 系统有一个本地插件，工程师可以在自己的工作树上跑 /fullreview，"用的是和 CI 里完全一样的 agents 和 prompts，只是跑在你的笔记本上"。这个设计的精髓在于：让 AI 和人看到同一个现场。
我们的做法把这个思想推到了极致——不只是"AI 和人看同一个代码现场"，而是"AI、人、所有协作方，共享同一个运行现场"。Review App 是这个共享现场的载体：Agent 在里面准备数据和材料，人在里面验收功能，AI review 的结论可以直接对着这个真实运行的版本来验证。
这种"运行现场的共享"，比"代码现场的共享"更强。因为代码是静态的，运行是动态的；代码可以被脑补，运行只能被观察。当协作的中心是一个真实运行的环境时，所有"我以为""应该是""大概是"都会被现实校正。
收束：让人真正"接得住"
让我用一句话收束这一篇：
共享环境，是让"人接得住 AI 产出"这件事，从一句口号变成物理现实的唯一办法。
它的本质，是把工作现场外部化——从个人电脑的私域，搬到 MR 和 Review App 的公域。一旦外部化，所有的协作断点都消失了：
- Agent 完成 = 人可以直接进去看（不再需要搭环境）。
- 工作状态 = 沆淀在共享对象里（不再随人流失）。
- 版本一致性 = 由 readiness 绑定 SHA 保证（不再漂移）。
- 验收 = 在真实运行的环境里进行（不再脑补）。
讲到这里，前五篇的物理基础已经铺好。但还有一个问题悬而未决，它正是最后一篇工程篇（第 6 篇）的主题：
在这个共享环境里，怎么保证验收本身是可靠的？ 当 AI 跑完了一批测试，说"全部通过"，人凭什么相信？机器门禁到底该管什么、不该管什么？
这是第 6 篇的主题：门禁驱动——让机器只管机器能管的，人只判人该判的。我们会用一个真实的案例说明，为什么"批次全部 completed"反而可能是一次失败的验收，以及那套 G1–G5 门禁如何把"完成"和"正确"彻底分开。
下篇见。
一句话结论
共享环境（MR + Review App）把工作现场从个人电脑外部化到共享对象，让"人接得住 AI 产出"从口号变成物理现实；严格的 Ready 标准和 commit SHA 绑定，则是这套物理基础的可靠性保证。