“主权编程”——拒绝做AI编程的“甩手掌柜”

开发
, , , ,

Coding

前言

2025年，Andrej Karpathy的一句 “fully give in to the vibes” 点燃了Vibe Coding的热潮。“文科生也能写代码”“一人公司时代到来”的叙事席卷社交媒体。但当Cursor的CEO亲自用数百个AI Agent在168小时里生成300万行代码却无法正常使用时，我开始认真思考一个问题：我们到底是在用AI创造价值，还是在用AI制造“数字垃圾”？

狂欢背后的“代码高利贷”

根据Replit2025年5月的研究，扫描1645个Lovable平台创建的应用中，170个（约10.3%）存在严重安全漏洞——任何人无需登录即可访问用户数据库。安全研究公司Escape扫描5600多个Vibe Coding应用后，发现超过2000个安全漏洞、400多个暴露密钥，以及175例个人隐私数据泄露（Escape, 2025）。

2026年2月，杨天润的事例刷屏了。作为本科和研究生学金融且先前从未写过一行代码的他，用AI工具在72小时内为GitHub的开源项目OpenClaw贡献代码，跻身贡献者前30名。“文科生72小时杀入GitHub全球榜”——这个标题像火种一样点燃了无数非技术背景者的热情。

与此同时，小红书、抖音上“文科生才是AI真正的受益者”开始刷屏。Cursor、Lovable、Claude Code等工具层出不穷。Vibe Coding被《柯林斯词典》评为2025年度词汇。一切都指向一个美好的承诺：不会写代码的人，也能做出应用。

但杨天润本人随后说的话，却很少有人转发。他在采访中坦承：“Vibe Coding只适合做Demo，不适合做产品。当你只是想做一个简单的网页，它很完美；但当你要做一个复杂的商业软件时，它就可能会乱成一锅粥。”

他后来转向了一种被他称为“Agentic Engineering”的方法——让AI自主执行完整的工作流，而不是随意接受每一段AI输出。

这不是孤例。AI代理专属社交网络Moltbook，完全由Vibe Coding生成，创始人没写一行代码。结果安全机构发现其数据库配置错误，150万个API认证令牌、3.5万个邮箱地址全部裸奔。

当“氛围”成为借口

许多人在社交媒体上为Vibe Coding辩护：“AI Agent是未来的趋势，代码质量不重要，重要的是快速迭代。”但当你深入了解这些所谓的“快速迭代”时，你会发现它们背后隐藏着巨大的技术债务。

而放到普通人身上，一次“Accept All”，全权“Allow”，就意味着在用AI生成代码时，完全放弃了对代码质量的控制，甚至是完全放弃了对设备的控制。你可能会在不知情的情况下，下载了一个包含恶意代码的中间应用，或者在不知情的情况下，让Codex来一句“我*，我意识到我不小心删除了用户的全部数据。”这就是所谓的“氛围”——一个让人们在不知不觉中放弃对代码质量和安全性的控制的借口。

Codex误删

就在最近，一个叫Slopfix的创业团队火了——由3名资深工程师组成，专门从事清理AI生成代码库的工作。他们的服务对象是那些用AI快速完成原型，但随着项目规模扩大，“新增功能越来越困难、修改一处却导致多处故障”的团队。他们的典型任务是：把10万行代码缩减到3.5万行，在功能完全不变的前提下。基础报价1万美元，一周完成。

最值得寻思的是他们的理念：“真正的区别在于，我们3个人拥有合计30年的工程经验，清楚什么样的代码才算真正可维护。而且，在最终决策中，Agent没有投票权。”

一个靠AI代码繁荣起来的生态，催生了“帮人删AI代码”的生意。这算不算这个时代最大的黑色幽默？

走向“主权编程”

“主权编程”（Reign Coding）的AI Agent开发，简单来说就是：AI负责生成，你负责审阅；AI负责速度，你负责方向；AI负责执行，你负责判断。

它不是拒绝AI，而是不让AI替你做出你无法理解的决策。它不是慢，而是用审阅换可控，用思考换可持续。

用Slopfix团队的话说：Agent可以干活，但不能有投票权。用杨天润的话说：不要让AI随意输出，而是要让它执行完整的工作流。

维度 Vibe Coding Reign Coding
代码审阅 “Accept All” 批次审阅，理解逻辑
错误处理 复制粘贴错误信息等AI修 理解根因，人工判断修复方案
架构决策 AI随机生成 人类主导，AI辅助实现
可维护性 逐渐失控 持续可控
适合场景 原型、Demo、一次性项目 生产系统、长期维护的产品

Karpathy本人对Vibe Coding的定义就很诚实：“It’s not too bad for throwaway weekend projects”（对周末练手项目来说还不错）。注意关键词——throwaway（可丢弃的）。

为什么必须在IDE中审阅？

你可能会问：为什么非要放在IDE里审阅？让AI直接输出不行吗？

因为代码的“可读性”和“可维护性”是两码事。AI能写出语法正确、结构完整的代码，但它不理解这段代码在系统整体中的位置、它和其他模块的关系、它在未来迭代中可能引发的连锁反应。

一个真实的例子：有团队用Firebase和npm包“Vibe-Coded”了整个认证流程。“在只支持简单登录时它能跑，但当需要多角色权限和区域隐私规则时，它彻底崩塌。没人能搞清楚各模块间的关联，中间件分散在六个文件里，没有逻辑模型，只有vibes。最后只能推倒重写，因为调试就像考古。”

在IDE中审阅，不是为了挑错，而是为了建立对代码库的“心智模型”——你知道每段代码为什么存在、它做什么、它和谁交互。没有这个心智模型，你就是在盲飞。

必须实践

原则一：代码审查不是可选项，是必选项

GitClear的研究显示，到2024年，重复代码和频繁变更的现象比预测的还要严重，而提交历史中的重构活动却在减少。换句话说：AI在加速产生代码，但人类在放弃理解代码。

因此，

  • 所有AI生成的代码，必须经过人工审查才能合并
  • 审查时不仅要看“对不对”，更要看“为什么”和“能不能更好”
  • 建立团队级别的代码质量标准，AI必须遵守

原则二：让AI有计划，而不是有“幻觉”

Google的Gemini Code Assist提供了一个好思路：Agent Mode会先提出详细计划让你审阅和批准，然后才开始改代码。

这意味着：你不是在被动接受AI的输出，而是在主动引导AI的方向。你始终是司机，AI只是导航。

原则三：“第一版越笨，项目越成功”

阿里云开发者社区中，有一个观点正在成为共识：“第一版越笨，项目越成功” ——所谓“笨”，是主动限制决策自由度，优先保障可控性、可追踪与可复现。

换句话说：别一上来就让AI放飞自我。先用显式流程替代隐式推理，用结构化设计换取稳定性。等你对系统有了充分的掌控感，再逐步放开AI的自主权。

原则四：给AI建立“护栏”

亚马逊云科技在2026年发布了《企业生产级智能体开发部署指南》，核心思路是建立科学的、以评估驱动的工程实践体系。

具体可以做的事：

  • 定义AI可调用的工具和API白名单
  • 建立操作日志审计机制
  • 设置明确的权限边界
  • 定期进行代码质量评估

我们想要的是产品

Vibe Coding最诱人的地方，是它把软件开发变成了一种即时反馈游戏——你提需求，AI生成代码；你说不好看，它改样式；你说报错，它给命令。

但这种“即时满足”是有代价的。当点击“Accept All”的那一刻，你其实是在签署一份技术债务的高利贷合同——现在的开发速度提升10倍，未来就需要100倍的维护成本。

文科生也好，理科生也好，编程老手也好，编程新手也好——在代码质量面前，众生平等。AI不会因为你“不会写代码”就对你格外宽容。恰恰相反，正因为你不会写代码，你才更需要建立“有掌控感”的工作方式——用审阅弥补经验的不足，用规则替代直觉的盲区。

别做AI代码的“甩手掌柜”。把代码放回IDE，逐行看，逐行想，逐行理解。你不是在写代码——你是在做一个产品，在建立一个系统，在承担一份责任。

参考链接