一个功能请求带着视频进 PR，工程师还需要看什么？

一张“这里间距再收一点”的设计图，通常会怎样走到生产环境？大概率是：设计师提工单，产品补描述，工程师找时间排进 sprint，再有人拉起本地环境确认一遍。需求在几个人之间倒腾，最后谁也说不清那张图和最终代码隔了多少层转述。

Replit 昨天把这个链路往前推了一步。它的 Cloud Agents 允许产品、设计、客服这些不直接写代码的人，用自然语言描述改动；Agent 在隔离环境里找代码、跑起应用、做浏览器测试，最后把带截图和视频证据的 GitHub PR 或 GitLab MR 交给工程师。官方说，工程师仍然决定什么能合并、什么能上线。官方公告在这里。

值得看的不是“非技术同事也能写代码”——这句话已经被说到快没有信息量了。更具体的变化是，过去一张模糊的需求单，现在开始尝试以一个可运行、可观看、可评论的变更提案进入评审。

一张需求单要变成能被团队接住的 PR，中间至少要跨过范围、证据和合并三道门。

不过，PR 上多了一段视频，不会自动让协作变简单。它只是把原来藏在工程师脑子里的判断，逼着团队明确写出来：谁能碰哪些目录？什么算“测过”？谁对合并负责？

第一扇门：不是“能描述需求”，而是“能在限定范围里改”

让客服同事写一句“这个报错提示太难懂，帮我改一下”，听上去没有风险。可一个成熟代码库里，错误提示可能散在前端组件、接口映射、国际化文案和埋点逻辑中。Agent 找到了相关文件，不代表它就该拥有改动所有相关文件的权力。

很多团队现在的自动化权限，仍像一个过大的共享账号：仓库给了，密钥给了，能跑就好。对人来说已经够危险，交给能跨文件规划和执行的 Agent，问题会变得更具体：它能不能读生产配置？能不能碰迁移脚本？能不能替换依赖？能不能在发现测试失败时顺手“修”到不相干的模块？

Replit 的方案里有一个值得注意的基础：共享环境不是让每位非工程贡献者各自搭一遍，而是由管理员一次性配置仓库、运行时、工具和依赖，并让新改动从主分支的当前版本开始。凭据则通过外部 secrets manager 的 credential broker 提供。这个方向是对的：先把环境和凭据收进边界，再谈谁可以发起改动。

但这里的关键词不是“共享”，是最小可用范围。一份给 Agent 的任务说明，最好能同时写清三件事：

• 这次只允许改动哪些路径或服务；
• 哪些配置、密钥、迁移和权限文件只读或完全不可见；
• 一旦需要跨出这个范围，PR 必须停在计划状态，等待人确认。

这不是给流程加戏。相反，它让产品同事可以更放心地提出真实问题，也让工程师不用把每一次协作都当作一次潜在的仓库事故。

第二扇门：视频是证据，但不是验收结论

Replit 的 Cloud Agents 会在隔离云沙箱里打开运行中的应用，像用户一样点击改动；如果失败，就修代码再测，随后把截图和视频附进 PR。对于评审者来说，这比“我改好了，麻烦拉下来跑一下”强得多。

因为评审最贵的时间，往往不在读 diff，而在重新构造上下文：这个改动影响了哪个页面？启动条件是什么？原来怎么坏？现在怎么好？一个能复现路径的短视频，至少把这些问题往前回答了一半。

视频回答“我看见了什么”；自动化测试回答“系统有没有按规则运行”；人工评审才回答“这是不是团队想要的改动”。

可别把三层混成一层。视频只能证明某个环境、某条路径、某个时刻看起来正常。它不等于覆盖了权限分支，不等于说明埋点、无障碍、国际化、性能和回滚都没有问题，更不等于这段代码符合团队长期的架构约束。

所以，Agent PR 的验收材料应该分开摆：

变更说明：用户问题、改动范围、明确不做什么
运行证据：截图或视频，以及复现步骤
机器证据：执行过哪些测试，哪些测试未覆盖，结果是什么
人工判断：产品验收人、代码评审人、最终合并人

如果一条 PR 只有一段漂亮的录屏，没有明确的测试命令和未覆盖项，它更像一个产品演示，不是可以放心进入主分支的交付物。反过来，只有绿勾没有可观看的路径，非工程同事也很难确认那个需求到底有没有被理解。

第三扇门：把评审意见变成团队记忆，但别让它自己长权限

Replit 还做了一件很像工程团队会遇到的事：把重复出现的评审意见沉淀成 workspace memory。Agent 可以把“这个目录要补回归测试”“提交前先跑某个检查”之类的反馈提议为团队 instructions，工程师批准后，后面的 PR 就会带着这份记忆出发。官方称这个功能仍在 early access。

这比让每位 reviewer 一遍遍打同样的评论要好。很多 PR 的摩擦并不来自高深设计，而是同一条默认规则没人写下来：文案改动需要截图，接口变更需要契约测试，新增开关必须有删除计划。把它们变成可审查的规则，Agent 才有机会在提交前替团队完成一些重复劳动。

风险也恰好在这里。记忆一旦被自动采纳，很容易从“建议”变成不透明的事实标准。今天某个 reviewer 的临时偏好，明天可能被 Agent 当成必须遵守的项目规则；一条错误的 instruction 还会被稳定地重复执行。

因此，团队应该把这类记忆当作普通代码一样管理：有来源、有负责人、有生效范围、有失效日期。尤其是权限、部署、数据处理和依赖升级相关的规则，不能只因为它曾经在评论里出现过，就获得长期执行权。

真正被压缩的，是“需求翻译”的往返

Replit 的公告描述了过去常见的来回：非工程同事发现问题后，请工程师启动应用、给截图、再根据反馈修改。现在，Agent 试图把这段往返折叠成一次带证据的 PR。

如果它能把“请你帮我看看”变成“这里是改动范围、运行视频、测试结果和待你决定的问题”，工程团队确实会轻一点。不是因为工程师被替代了，而是因为他们不必继续做每个需求的人工翻译器和环境管理员。

但合并按钮仍该留在人手里。能描述问题的人离代码更近了，不代表代码就该绕过设计约束、权限边界和责任链条直接落进生产。对多数团队来说，最值得先拿走的不是某个 Agent 的宣传语，而是把下面这句话写进自己的 PR 模板：“谁发起变更、它能碰什么、我们凭什么相信它、谁最终负责？”

你们团队里，哪一种需求最适合先从“工单”变成“带证据的 PR”？

小岛 AI