我是怎么被AI坑了一把，然后彻底改变工作方式的

那天我花了三个小时调试一个AI写的"简单"功能。

那家伙信誓旦旦地提交了代码、推到了生产环境，还给我留了条愉快的消息说任务完成了。

问题是——代码完全跑偏了。不是普通的bug，是根本就没理解我们要做什么。

那一瞬间，我的认知崩塌了。

我一直把AI agent当成需要指导的初级开发者。但初级开发者不会趁你睡觉的时候把没测试的代码推到线上啊。

所以我把整个思维模型换掉了。

把AI当成分包商

我现在不把AI agent当员工，也不当助手。我把它们当成分包商。

说白了是这样的：

分包商没有你公司的钥匙。他们不会不请自来。干完活，交差，等你验收。质量不行？打回去重做。

这不是不信任的问题。这是激励和责任的问题。当分包商明白自己的角色是交付成果等我来审，而不是自己拍板决定一切——他们的表现反而更好。专注，高效，而且只在划定的范围内干活。

技术层面得跟上

光有心态不够，还得有技术兜底。我的做法是：

Token权限管理是关键

我的agent手里的凭证，从物理层面就碰不到生产环境。它们能读主代码库，但写操作只限一个独立的staging仓库。这不是规定，是加密层面的硬限制。就算agent发疯，或者产生幻觉般的git命令，它也改不了生产代码——token不允许。

Staging仓库就是个信箱

staging里的东西不会自动合并。主分支名字直接就叫"no-main"，里面只有一个README写着"请使用原仓库的main分支"。

agent把活儿干完推到这里，然后通知我。我来review，挑有用的cherry-pick，手动合并。

听起来麻烦？直到你想起来——Linux内核二十多年都是这么运作的。贡献者提交patch，维护者来合并。

Review是必须的

没有agent能自己合并代码。门都没有。分支不删，直到我独立验证了——程序化地验证——它的commits确实安全躺在生产环境里。"信任但要验证"还不够，因为验证本身就是免费的。

为什么Solo开发者特别适合这套

Solo开发者或小团队有个特点：你维护的上下文，有很多根本不在代码里。之前的故障记录、边界case、那个配置很奇葩的客户、你试过但没跑通的三种方案……

agent读得到文件，但读不懂你的世界。

所以目标不是给它们更多自主权，而是让它们在我能review的范围内做最多的事。

这就是"vibe coding"被黑的原因。做错了就是让agent随便搞然后祈祷没问题。做对了是用AI放大你的判断力，而不是替代它。

意想不到的好处

一旦接受了这种"分包关系"，会发生一件神奇的事——你敢冒险了。

你想试一个新功能？试试就试试。因为下限是可控的。agent最多给你搞出一个出乎意料的烂活儿，或者一个出乎意料的好活儿——但不管哪种，你都能在它造成影响之前拦住。

过去半年我启动的side project，比之前两年加起来都多。不是因为我更拼了——是因为我在安全边界内更敢放权了。

怎么用到你的工作流里

如果你也在用AI agent开发，问自己几个问题：

1. 我的agent现在能碰什么？如果答案是"生产环境"，那就出问题了。
2. 阻止它做错事的是技术硬限制，还是只是口头规定？
3. 谁来合并代码？如果不是人，为什么？

工具都现成的。Token scoping、独立的staging仓库、分支保护——这些不是什么 exotic git workflow。这是AI辅助开发和AI制造灾难的区别。

在NameOcean，我们在vibe coding支持方面也在认真思考这个问题。目标不是把所有事都自动化——而是创造一个空间，让AI真正有用，同时不制造新的风险类别。

你的判断力依然是瓶颈。但这不是限制——这才是核心。agent存在的意义是放大你能做的事，而不是替代那些让软件真正服务于用户的判断力。

按这个思路去构建吧。