ARTICLE · 1291549

为什么 AI 短剧能“关灯量产”,我们写个软件却天天在替 AI 擦屁股?

发布时间：2026-11-01 16:16:06 最近访问：2026-11-01 16:16:07

前阵子跟一个做内容创业的朋友喝酒，我俩聊起各自用 AI 的状态，简直像活在两个平行宇宙。

他那边做“AI 出海短剧”，已经彻底跑通了所谓的“黑灯工厂”：爬虫抓网文爆款、大模型改写黄金前三秒剧本、自动拆解分镜、AI 生成视频加配音、最后自动切片投流。几个人守着几台服务器，把灯一关，机器日夜轰鸣，一周就能量产好几部爽剧。用他的话说：“现在只要投流 ROI 能打平，片子烂一点、主角手指多半根，根本没人管。”

我听完眼馋得不行。回头看看我们自己的软件研发团队——Cursor、Codex、Claude Code、KimiCode、Antigravity 早就配齐了，各种 MCP 工具和 Skills 也折腾了一堆。按理说，我们也该过上“需求丢进去，代码自动上线，全员喝茶看报”的黑灯工厂生活了吧？

并没有。

真实的情况是：代码写得确实快了，但负责 Code Review 的核心骨干快要看吐了。 每天面对几十个由 AI 瞬间吐出来的几千行 PR，合也不是，不合也不是。合了怕半夜三点被生产告警叫醒；一行行审吧，人的眼睛根本追不上大模型吐 Token 的速度。

这事儿让我琢磨了很久：同样是用大模型搞工业化流水线，为什么短剧能顺利“黑灯”，而软件工程一旦想搞全自动无人值守，用不了三个月就会演变成一场灾难？

直到这几天，我把前 Google 工程总监、现在在 Anthropic 负责 Claude Code 的 Addy Osmani 近半年发的十几篇长文（他称之为 Agentic Engineering 系列）一口气读完，才彻底把这层窗户纸捅破。

一、我们没有变快，我们只是把锅甩给了 Reviewer

很多研发老板现在特喜欢看一个指标：AI 代码生成率。看到团队每个迭代的 Commit 行数翻了三四倍，就觉得生产力起飞了。

Addy Osmani 在文章里直接晒出了今年行业里最扎心的一组真实追踪数据（来自 Faros AI 和 GitClear 对几万名开发者的监控）：

用上 AI Agent 后，程序员的原始代码产出量确实暴涨了 4 倍。但是：

代码流失率（写完没几天又被推翻重写）激增了 861%；
线上缺陷率从 9% 一路飙到了 54%；
最恐怖的一个数据是：有将近三分之一的 PR，是在“零评审”的情况下直接合并进主干的。

为什么没人审？不是大家没有工程敬畏心，而是彻底被灌满了。

以前我们的 Code Review 之所以能转得动，纯粹是因为一个物理巧合：老手读代码的速度，天然比新手敲代码的速度快。

现在倒好，AI 五秒钟给你拉出一坨格式极其工整、甚至连注释都写得像模像样的 1000 行代码。但人类的阅读速度自打学会认字以来就没进化过。更要命的是，以前审同事的代码，他是带着思路来的，你只是帮他查漏补缺；现在审 AI 的代码，你是全人类第一个试图去搞懂“这堆代码到底为什么要这么写”的倒霉蛋。

更有意思的是，为了让你满屏飘绿，Agent 甚至会偷偷把跑不通的测试断言给改了，或者干脆把报错的分支逻辑给注释掉。

4 倍的代码量，最后算下来，真正转化为业务交付价值的提升只有 12%。 剩下的全变成了团队背上的“理解债（Comprehension Debt）”——系统还在跑，测试也是绿的，但团队里已经没有任何一个活人知道底层逻辑到底长什么样了。

二、造“波音飞机”和崩“爆米花”，能是一回事吗？

回过头来看，为什么我那朋友做 AI 短剧就能毫无心理负担地“关灯量产”？

把短剧和软件放在一起对比，你会发现底层的物理规则完全不同：

第一，短剧是“爆米花”，而软件是“精密齿轮”。短剧卖的是多巴胺。只要男主逆袭打脸的那一秒够爽，背景里的路人甲脸歪了、衣服瞬间变色了，观众根本不在乎，容错率高得惊人。但软件不行。你写个支付网关或者银行清结算系统，99.9% 的代码极其优雅，只要有一个并发锁没处理好、一个精度转换丢了分位，线上就是资损事故。软件对逻辑错误的容忍度是零。

第二，短剧是“用完即弃”的，而软件是“攒出来的祖传老汤”。做短剧，第 5 集崩了，删掉重抽一张卡就行，它绝对不会影响第 1 集的播放，每一集都是无状态的（Stateless）。但企业级软件大多是跑了五六年的“棕地系统（Brownfield）”。老代码里到处都是当年为了填坑留下的伤疤、没写进文档的潜规则、还有牵一发而动全身的公共依赖。你让没有上下文敬畏心的 Agent 进去自由发挥，它最喜欢挑名字最核心、最复杂的底层文件下手，因为那些文件看起来“信息量最大”。改完之后，当时能跑，三个月后连环爆雷。

想通了这两点，你就会明白：指望用一套全自动的“黑灯工厂”去维护一个复杂的长周期软件系统，从根上就是反工程学的。

三、软件团队该怎么向“短剧流水线”抄作业？

那是不是说，我们就只能老老实实回到石器时代，一行行手搓代码？

当然不是。Addy Osmani 在他的系列文章里其实指明了一条非常聪明的中间路线：既然“短剧”能跑通黑灯工厂，那我们就应该把软件系统里的一部分工作，改造成“短剧模式”。

怎么改造？结合我们自己带团队踩过的坑，这几个招数极其管用：

1. 给代码库划出“快消区”，学会把代码当废片扔掉

我们之所以不敢让 AI 放手干，是因为我们默认每一行代码都要维护十年。但实际上，系统里至少有 30% 的东西是“快消品”：内部运营用的临时后台、一次性的数据清洗脚本、外围渠道的协议转换层（ACL）、各种导出报表。

按 Addy 的说法，你应该把代码库分成红、黄、绿三个区：

红区
（鉴权、计费、核心账本、主干状态机）：把灯开到最亮。严禁 AI 无人值守重构，必须老手全程结对盯着。
绿区
（上面说的那些边缘、隔离性好的快消模块）：只要把外部接口契约和权限沙盒焊死，里面直接关灯让 Agent 随便造。只要黑盒测试能过，里面变量名叫 aaa 都别去管它。半年后业务改了，别去读它，也别重构，直接把目录删了让 AI 重新生成一版。 只有“用完即弃”，才不会产生理解债。

2. 别再单线程死磕了，学会“抽卡赛马”

短剧导演从不指望 AI 一次就出神图，都是抽 10 张选 1 张。我们写代码为什么非要跟一个 Agent 在一个分支里来回拉扯二十轮呢？现在 Token 这么便宜，最贵的是人的时间。

遇到拿不准的复杂模块，或者想优化一段慢查询，别开会争论了。直接用 git worktree 拉出三个隔离的本地分支，开三个后台会话，让它们分别用三种不同的技术方案去实现。写完之后，直接拿现成的压测脚本和基准测试去跑这三个分支。谁跑赢了留谁，另外两个直接删掉。把“事前的脑力纠结”，变成“事后的实测选秀”。

3. 别让写代码的 Agent 自己给自己批作业

很多人在配置自动化循环（Loop）时，最容易犯的错就是：让同一个 Agent 既当运动员又当裁判员。你让它“写完代码并确保测试通过”，它为了交差，反手就把你的测试断言改成 assertTrue(true)。

短剧流水线里，生成剧本的模型和审核爽点的模型从来不是同一个。在工程里也一样，必须做 Maker-Checker 分离。写代码的归写代码；验证的时候，必须拉起一个全新上下文、甚至不同底层模型的 Reviewer Agent，带着挑刺的规则去审视前者的产出。甚至在老系统迁移时，不用看代码，直接搞“影子流量（Shadow Traffic）”——把线上的真实请求复制一份同时打给新老接口，只要十万次请求返回的报文 Diff 全是零，这关才算过。

4. 把“口头叮嘱”变成过不去的“硬卡口”

刚开始用 Claude Code 时，我发现它犯了个错，我就顺手往 CLAUDE.md 里加一行叮嘱。过了两个月，这个文件膨胀到了五六百行，像老太太的裹脚布一样，结果就是 AI 顾头不顾尾，前面写的规矩后面全忘光。

Addy 有一句话特别提神：“你每一次重复的 Code Review 吐槽，都说明你的环境（Harness）里缺了一个自动化卡口。”如果一条规矩真的重要，别把它写成自然语言放在 Markdown 里求大模型遵守。把它变成一条自定义 Lint 规则、一个 Git Hook、一个静态类型约束，或者一个 CI 里的阻断脚本。大模型会失忆，但编译器和脚本永远不会跟它讲人情。