16岁背挪威童话的CEO，用AI写代码被CTO罚站墙角

1991年，一个16岁的澳大利亚高中生学会了用挪威语表演《三只山羊》。30多年后，他把这套"氛围感编程"（vibe coding）用到了公司项目上——结果被CTO没收了笔记本电脑。

这位CEO来自Secret公司，他的经历正在硅谷疯传。不是因为项目多成功，而是因为他精准踩中了AI编程时代最讽刺的陷阱：工具给了你信心，却没给你真本事。

从挪威童话到AI代码：同一套幻觉

Secret CEO至今能用挪威语背诵《三只山羊》，尽管他完全不懂这门语言。这个"派对 trick"在挪威人面前屡试不爽——直到对方用挪威语回话，场面立刻崩盘。

他把这套逻辑复制到了AI编程上。把功能规格说明书和用户故事丢给AI编码助手，跑出来的代码看起来能跑，演示时还能收获"哇哦"的反馈。

CTO的质问来得很快：「这里为什么禁用了代码检查（linting）？」

CEO反问：「代码检查是什么意思？」

CTO让他去"硬编码凭证角落"面壁思过，没收了电脑。「等你意识到自己干了什么、并道歉之后，再拿回去。」

20年老兵为何翻车

这并非新手冒进。Secret CEO有20年大型定制软件项目经验，12年故事驱动软件设计实践，经历过功能规格书、行为驱动开发、测试驱动设计等多轮方法论迭代。

他甚至试过Gherkin——一种以为能弥合开发者与业务方思维差异的规范语言。

他的准备堪称充分：严格的实体库、安全模式、统一的schema定义规范，外加一堆用AI工具做出来的"令人印象深刻"的原型。

但AI给他的信心，恰好掩盖了他不知道自己在问什么。

就像那个挪威交换生表演——有模有样，内核空洞。AI生成的代码能编译、能演示，却经不起追问：为什么这样设计？边界情况怎么处理？安全策略是什么？

"氛围感编程"的真相

这个案例戳破了当前AI编程叙事的最大泡沫。

各种教程都在演示：用自然语言描述需求，AI几分钟生成可用代码。但很少有人展示后续——当需求变更、出现bug、需要维护时，写代码的人是否理解自己"创造"了什么。

Secret CEO的CTO用了一个精准类比：硬编码凭证。这是安全领域的经典反模式，把密码直接写死在代码里。CEO的AI代码里可能就有这类问题，而他甚至不知道"linting"是什么——这是代码静态分析的基础工具，能自动检测潜在错误和风格问题。

禁用linting，等于主动蒙上眼睛写代码。

信心曲线与能力曲线

这个现象有心理学解释。邓宁-克鲁格效应描述过：能力欠缺者会高估自己，因为缺乏能力本身就让他们无法认识到自己的无能。

AI编程工具恰好放大了这个效应。它提供了即时反馈（代码跑起来了）、社交认可（ demo 时的惊叹）、以及"我也能编程"的错觉。

Secret CEO的反思很直接：他能用挪威语表演童话，是因为反复练习形成了肌肉记忆；但遇到真实对话，零理解的事实立刻暴露。

AI编程同理。描述需求、生成代码、看到结果——这个闭环练的是" prompt 工程"，不是软件工程。

CTO的惩罚与行业的隐喻

被罚站墙角的CEO，最终拿回了电脑。但这个场景被传开，因为它浓缩了一个组织困境：当高管用AI工具绕过专业判断，技术负责人该如何应对？

CTO的选择是强硬但有效的——用具体的技术问题（linting）揭示抽象的能力缺口，而不是泛泛批评"AI不靠谱"。

这也给AI编程工具的设计者提了醒。当前产品优化的是"首次成功"体验：让新手快速看到成果，获得多巴胺反馈。但软件的生命周期是维护，不是 demo 。

Secret CEO的经历暗示了一种可能：未来的AI编程工具，或许该内置"CTO模式"——不仅生成代码，还强制解释关键决策、标记潜在风险、阻止危险操作。

否则，会有更多人在"硬编码凭证角落"排队面壁。

那位CEO最后学会挪威语了吗？没有。但他现在会向挪威人提前声明：「我能背童话，但别用挪威语回我。」

用AI写代码的人，是否也该给自己贴个类似的免责声明？