一天上线 50 次、不用代码评审：Amp 工程师的 AI 协作法

关联

人物 Dario Hamidi

公司 AMP

概念 智能体 · pull request · Orb · 智能体工程 · 泄露的凭证 · 认知负荷 · 云端智能体

Amp 是一家只有 20 人左右的软件公司，团队每天往生产环境部署大约 50 次，中间没有任何拉取请求（pull request，即代码提交后等别人审阅再合并的传统流程）。

工程师 Dario Hamidi 在 Beyond Coding 播客里解释了他们为什么敢这么做，以及围绕 AI 智能体踩过的坑。

为什么说该取消拉取请求了？

Dario 的说法很直接：不管你用不用 AI，取消拉取请求都能让生产力提升两位数甚至三位数的百分比 。

理由是拉取请求本质上来自互不信任的环境——就像网上一个陌生人想改你的项目，你当然要先检查他改了什么。

但在一个互相信任的团队里，这套流程反而成了枷锁。

更实际的问题是：没人真的认真审查。理想情况下，审阅者应该把分支拉下来、跑起来、亲手点一遍，但这成本太高，没人做。

于是拉取请求挂在那里好几天，双方都想赶紧合并，审查变成走过场。

而万一发现架构方向错了，那已经是所有工作都做完之后——最糟糕的发现问题的时机。

直接入主干的团队，靠什么保持信心？

Dario 建议，如果明天宣布所有拉取请求自动关闭、想发布就必须直接推送到主干，会发生什么？

大家会自己做更多验证——比如让智能体展示截图、录像，证明功能真的能跑。

他还点出一个心理变化：

想开拉取请求这个念头本身就是信号，通常意味着你害怕改动会弄坏东西，而恐惧往往来自改动太大。

取消拉取请求后，人们自然会拆成小块提交，因为小块是安全的。

想试的团队可以做两周实验：不开拉取请求，所有人直接推主干。照常讨论、照常帮同事看代码，只是不阻塞发布。

第一周会很痛苦，第二周大家就会爱上小块提交。

他的观察是：有没有拉取请求，质量没差别，差别在交付速度 。

而且正因为随时能发版，出了错误报告也能用同样的速度修掉，哪怕只是回滚一次提交。

智能体权限：调严了挨骂，调松了也挨骂

去年 Amp 解决过一个非常头疼的问题：智能体的每个工具调用要不要用户批准？

结果发现，不管怎么选，用户永远是一半对一半地不满意——管得太严，有人抱怨不安全；

放得太开，有人抱怨干点小事要点 10 次批准。

Dario 的结论是：这根本不是产品决策问题，而是沟通问题 。正确做法是让用户自己选择阵营，再给每个阵营配好合理的默认值。

Amp 内部干脆不做逐条批准。原因不是模型完美，而是他们把环境里的“锋利边缘”都磨掉了：

就算智能体想删生产数据库，数据库连接本身就没有删除权限，到那里就结束了。

出事的团队，都是在“抛刀杂耍”

那些被智能体删掉生产数据库的案例，Dario 的比喻是：他们在抛刀杂耍 。

往往是刚接触 Cursor、Lovable 这类工具的新手，被这些工具突然带来的可能性兴奋到了，就照着智能体的建议照做，不知道要先配置行级安全。

有经验的开发者会说，我们换个不抛刀的玩法行不行？

原则是：什么该归模型层管，什么该归周围确定性的系统管，这是智能体工程的核心技能 。

不想让智能体推代码，去配置 GitHub 权限；不想让它写生产数据库，就只给它只读凭证。

Orb：不花钱的待机虚拟机

Amp 现在力推的方案叫 orb——本质是虚拟机，但不只是虚拟机：

不运行就不计费，彼此互联，每个 orb 自带一个可以点开的门户页面，直接预览正在开发的应用 。

可以一口气开 100 个，睡一觉它们就都停了。这解决了并行开发的经典痛点：

没人愿意手动管理 Git worktree、解决端口冲突、为不同分支各起一套数据库——每个 orb 就是一套独立的小环境。

有人把 orb 当成“开了外挂的上下文窗口”：一个项目一个 orb，一个月回去一次，架构决策、项目背景全都在里面。

最难的两个问题：凭证和状态

远程执行环境里，凭证很麻烦。把密钥写进 orb 的文件里最省事，但 orb 长期存在，密钥会一直躺在磁盘上。

理想方案是短时效凭证，但极少有服务商允许你创建只活 7 天或 25 分钟的 API 密钥 ，「创建 API 密钥」流程里根本没有这个选项 。

【背景】节目之外的一个常见折中是用 1Password 的服务账户：智能体只拿到一个短时令牌，密钥本身不落盘。

状态管理同样琐碎：

3 个浏览器标签页连着同一个智能体会话，每个标签页是一个身份，底下又挂着来来去去的 WebSocket 连接——合上笔记本电脑、地铁过隧道，连接都会断。

听起来简单，做起来每个细节都要做决定。Amp 的经验是先发出去、拿到反馈，才知道一半的方案根本不用考虑。

一天 70 条错误报告，怎么消化？

Amp 发版太频繁，用户反馈也多——每天 60 到 70 条错误报告，比如“渐进式网页应用的图标在安卓上很难看”。

他们把报告功能做进了产品本身，智能体可以直接读取。

Dario 现在每天开工时说一句话：把所有未解决的问题过一遍，按标准挑 10 个分给我；

每个问题开一个 orb 去分类——追问用户、提出修复方案，或者判定不是问题。

他只负责逐个检查方案并推进，连给用户的邮件都可以直接从 Amp 里发 。

有个例子：用户想要 shell 补全脚本。智能体写完，Dario 看了一眼觉得可能慢，让它量一下——按一下补全要 600 毫秒。

换个实现方式，降到 30 毫秒，顺手又加上了 PowerShell 支持，四种 shell 的补全脚本就都有了。

放在两年前，这种需求根本不值得做；现在全程后台跑，几乎不花他精力。

警惕一种新型过劳

Dario 提醒，智能体时代认知负荷没有上限了——“你想把自己烧干完全可以” 。

他提到网上流传的“AI 精神崩溃”案例：有人不停让智能体干活、不停做决定，一直干到凌晨 4 点。

所以用智能体来降低自己的认知负荷，本身就是新的必修课。

另一个反直觉的提醒：以前开发成本高，你会先问“这真是个问题吗、值得修吗”；

现在做方案太容易，反而容易跳过这个问题直接动手。他说，还是得先退一步，问清楚用户到底想干什么 。

本集带走

• 取消拉取请求、直接推主干，能显著提升交付速度，且质量不会因此下降；小块提交本身就是安全保障。
• 信任智能体的关键不在模型，而在环境：不给数据库删除权限、不在 GitHub 给推送权限，磨掉锋利边缘。
• Orb 这类按需计费的远程环境让大规模并行开发变得便宜，不用再手动管理 worktree 和端口冲突。
• 大批量重复工作（如每日错误报告分诊）可以交给智能体批量处理，人只做判断和把关。
• 开发变快之后，更要保留“这值得做吗”这个旧问题；认知负荷管理是智能体时代的新技能。

我甚至敢说，即使你今天没有用 AI，如果你在你的组织里取消 pull request，你也可以获得两位数百分比甚至三位数百分比的生产力提升。
And I would even go as far as saying, even if you’re not using AI today, you can get double-digit percentage, if not triple-digit percentage gains in productivity if you get rid of pull requests in your organization.
—— Dario Hamidi · [01:59]

所以如果你感到有打开一个 pull request 的冲动，那对你来说是一个信号，说明有什么地方不对劲。
So if you feel the desire to open up a pull request, that’s a signal to you that something is off.
—— Dario Hamidi · [04:02]

质量不会改变，无论你有没有 pull request。
It doesn’t change the quality, whether you have pull requests or whether you don’t have pull requests.
—— Dario Hamidi · [08:27]

现在，人类才是瓶颈，因为他们注意力有限，因为有这么多并行的工作在进行。
Now, humans are the bottleneck with their limited attention because so much parallel work is going on.
—— Dario Hamidi · [34:51]

认知负荷已经没有上限了。
There is no ceiling anymore for cognitive load.
—— Dario Hamidi · [43:06]