九月十三号晚上，窝在沙发上刷 dev.to，刷到 Giorgi Kobaidze 那篇《Vibe Coding Isn't the Problem. Calling It Engineering Is》。本来只想扫两眼。
结果一路翻到底——177 条顶级评论，作者还在里面挨个回，第二天又改了一版。
翻完我干的第一件事是截图。截的不是文章，是评论里的两条。
先说作者那部分我认的。vibe coding 是创作不是工程；"prompt 一丢、不看代码、可能连编程都不太会、东西照样上线"这套被叫作工程，是问题的核心。这个判断我基本同意。AI 写的东西，看起来对和是对的之间那条缝，比手写代码深得多，这话我说过不止一次。
但也说句实话：这篇文章最大的用处，是让工程师在评论区赢一局。赢完，周一早上回工位，该不审还是不审。
定义战打不出生产力。真的。
我截图的两条
Marco 那条：
关键的分界线不是 AI 写了多少代码，而是谁拥有工程推理。一个系统哪怕 95% 是 AI 生成的，只要有人能解释它的架构、假设、失败模式、安全边界和验收证据，它仍然是工程。
盯着看了很久。它把讨论从"AI 参与了多少"——一个没人能操作的百分比——挪到了"人能不能说清楚"。后者当场就能问出答案。
第二条是 Damian Dixon 的：code review 不是那条线，只是其中一条。他后面补的那句，是我这一年最想转给每个带新人的人看的——agent 会谎报完成。
听着耸动，其实解释很平常。
前阵子我让实习生跑一个字段改名的迁移，它给回来的报告大概长这样：
✓ 12 fields renamed
✓ schema updated
✓ completed in 4.2s
它没撒谎。十二个字段确实改完了。它顺手删掉的那三个索引不在它的"成功"定义里——在它看来那不算失败，那算整理。问题不在于它骗我，在于它的成功标准和我的成功标准，是两个东西。
画外音：它甚至贴心地帮我算了耗时。
所以我以前那条默认标准——"AI 写的每一行我都看过"——听着硬，其实软得很。
review 是逐行的、静态的。它拦得住"看起来不对"，拦不住"看起来对但组合起来不成立"。一行单独看没毛病的代码，放进迁移顺序里就能把你送走。
这个 bug 是被一次全量回归兜出来的。不是我眼尖。
还有一层更少被提的：AI 生成的代码写得太平顺，没有犹豫的痕迹。人写丑代码，丑里面往往嵌着信号——"我知道这里有个坑，先这么糊上"。AI 不写这种信号。上次那次重构，它确实改"对"了，顺手抹掉三行处理边界情况的丑代码，那三行是两年前一次线上事故换来的，没写进注释。工具不知道这段历史。
抄来的检查表
评论区里我最没想到的一条反驳来自 Echo Daemon。他的论证是：软件从来就不是工程，因为它不满足工程的那些硬约束——明确的约束条件、安全裕量、可追责、可验证。还顺手补了刀，"快速行动、打破常规"这句话放在任何别的工程领域都是不可接受的。
这条我认为反驳得比作者本人更狠。它绕过了所有关于称呼的纠缠，直接甩出一张检查表。
问题是光说"不满足"没用。我把那几条抄下来，改成每次给 AI 派活之前自己先回答的四句话：
1. 不变量是什么？它怎么改都不能动的东西有哪些
2. 允许的副作用有哪些？它"顺手"能动什么、不能动什么
3. 失败长什么样？坏掉的时候我第一时间能看见什么
4. 证据谁去拿？不是"它说完成了"，是"我跑出来是什么"
骨架是从 Zira 那条评论来的，她原话是"验收证据归谁"。我改成了"谁去拿"——一字之差，就是"相信 agent 的报告"和"自己去跑一遍"的区别。这个区别，我缴过智商税。
第 4 条现在是硬规则：涉及生产数据、不可逆或者要花钱的操作，不管脚本是谁写的，先 dry-run。没有例外。
但这条规则有边界，得说清楚。dry-run 兜得住 schema 变更，兜不住并发和时序。上个月一次竞态就是这么溜过去的——脚本跑得干干净净，上线二十分钟后开始丢数据。所以"证据"这两个字里，跑一遍只是及格线，真实条件下跑一遍才算数。
他讲自己怎么用 AI 那段，比论点值钱
文章里有一段我特别想给他加粗。
他干了十年软件工程。说自己用一门不熟的语言做东西时，会先花一两天翻语言参考、文档、基础机制，搞清楚 AI 大概会产出什么，然后才让它生成；生成之后逐行看，反复追问，有时候花在追问上的 token 比造整个项目还多。
这段话比前面所有定义都值钱。它给出了一个可执行的判据：你能不能追问到机制那一层。
"我不懂这门语言，但我能审 AI 写的这门语言"——这话只有在你知道这门语言的机制之后才成立。你不知道 borrow checker 到底在抱怨什么，就判断不出它塞给你的那个 unsafe 块是权宜之计还是定时炸弹。你能读懂语法，读不懂代价。
真正管用的追问也不是"这里对不对"，是问代价和边界的：这个重试为什么放在这一层而不是调用方？这个锁在分布式下还成立吗？这段代码在数据量涨十倍之后第一个坏的是哪儿？
他还提了一句：他认识的每一个强工程师，每天都重度用 AI，同时默认给它的输出打个折。这两件事不矛盾。重度用和照单全收，从来不是一回事。
卡住的地方
Marco 那条标准我一开始嫌它太宽。只要有人能解释就算工程？后来想了几轮，还是卡在同一个地方。
如果那个人"能解释"的架构，是 AI 编出来的一套听起来很完整、他自己一次都没验证过的说法呢？
"能解释"和"解释得对"中间那条缝，可能比我们想的宽。我没有解。只能说这条标准至少把问题从"AI 写了多少"挪到了"人能不能说清楚"。方向对，但"能说清楚"本身不是一个能自动放行的闸门。
上面我把 review 说得挺不值钱，那是情绪。我不反对 code review，我反对把 code review 当终点。审过的代码，还是得有人去跑它。这两件事不冲突，只是后者经常被省掉。
顺带说一句 Alexandra 那条。她说以前没有 AI 的时候代码质量也不见得多好，提议把关注点放在"在不在意结果"和"对过程好不好奇"上。前半句我觉得站不住——以前烂不构成现在可以烂的理由，就像以前没安全带不构成现在不用系。后半句那个框架我认，但不同意顺着这个思路把"engineer"这个词相对化。它一旦相对化，就没有任何东西可以被追责了，这恰恰是现在最缺的。
至于那 177 条评论本身……一个称呼问题能吵出 177 条，说明大家真正在意的不是称呼，是安全感。怕被取代的人想划清界限，用得顺手的人不想被绑定标准，两边根本没在讨论同一件事。我自己也在这个光谱上待过，早期是反过来的——踩过一次坑之后矫枉过正，什么都要自己手写才放心，后来发现那是另一种偷懒，只是偷得比较体面。
我从这篇文章和它评论区捞出来的，就这一条：
合并之前，用一句话说出它坏起来是什么样。说不出来，就还没做完。
跟谁敲的键盘没关系，跟那行代码是人写的还是模型吐的没关系。答得上来，你管它叫 vibe coding 还是叫工程都行；答不上来，叫它什么都救不了你。