现在是AI最糟糕的阶段！别让AI带头！华盛顿初创创始人警醒：要保持团队的锋利！AI会造成公地悲剧！ 原创

​编辑 | 云昭

​出品 | 51CTO技术栈（微信号：blog51cto）

“现在是AI最糟糕的阶段！”

如果你去翻看OpenAI、Anthropic这两家的Top10 token 消耗的玩家排行榜、无一例外都会发现，各种 Code 工具都会名列前茅。如今各种AI Coding工具大行其道！

不管是开发者、还是“外行人”，都在这股洪流中亲自给这个赛道做出了注解，这已经是不可逆转的大趋势。

不懂编程的“外行人”，难掩兴奋：

大家问我怎么实现的，我也答不上来——只是想做一个“外星终端”，结果它真的跑起来了。

但身处企业之中，为成品负责、兜底的开发人员及高管们，却无疑都在面临这样一个开发真相：

AI 工具确实把前 10% 的工作变成了 1%，但后面的 99%依旧是瓶颈。

“所以，我们现在处于AI最糟糕的阶段！但以后会越来越好。”

近日，美国华盛顿特区一家AI初创公司Antithesis的CEO以及其现场首席技术官对于现在的Vibe Coding现状，带来了一手的实践心得。

图片

CEO Will Wilson 很直截了当的指出了大模型现在的弊端：LLM 其实还不够“聪明”。它更像是个“记忆巨兽”。

它见过互联网上所有的代码示例。对于常见问题，比如 React demo 或主流框架，它能迅速给出好结果；但一旦遇到新问题或小众技术栈，性能就会骤降。

它擅长“从 0 到 1”的生成，但不擅长在百万行代码库里做有逻辑的修改。它不会像人那样推理，只是在统计相似性。

但，可怕之处在于，并不是AI所带来的这种快餐式但长期看却有极大安全质量隐患的代码如果没有好的抵御措施，终将会酿成一场质量塌方的“公地悲剧”：

我常把它比作“公地悲剧”：一个人往湖里排点废水没关系，但大家都这么干，湖就完了。

同理，一个人用 AI 快速写代码、丢给同事改问题还好，但所有人都这么做，整个系统的质量就崩塌了。

不止如此，更令人担忧的是，大模型不仅仅带来的是减慢软件交付的真相，它还为业界带来了相当严重的隐形危险：AI代劳所带来的团队能力退化！

核心是别让团队的能力退化。

如果一个工程师长期让 AI 代劳，过几周不写代码，手感就会生疏。语言也是一样，写了一年 Python，就会忘了怎么写 C。这些“解决问题的肌肉”如果不用，就会退化。

关键还是在于，我们对待AI如何融入自己工作流的问题。

这里，Wilson分享了自己团队“使用AI不但不会阻碍交付速度、甚至真正加速”的两个非常实用的方法：文档和测试。

第一，文档本身可以作为 LLM 的上下文输入，帮助它输出更优结果；第二，文档能让团队保持对代码意图的共享理解——而这往往是“AI 写代码”环境下最先崩塌的东西。

另一个类似的关键点，是测试。有趣的是：那些最“保守”、最注重架构和测试规范的团队，反而能从 AI 工具中获得最大加速。

对于企业场景，现场首席技术官Shah认为，在软件开发赛道，企业没必要花费大力气为大模型去部署、构建一套全自动的、逼着员工去使用、然后统计员工使用时长的基础软件平台，反而不如直接帮员工订阅一份Claude、Gemini更好些。

企业现在面临的问题是，总想要在公司层面把 AI 部署成一种“大而全的自动化流水线”，并且真正提取价值，这其实很难。

反而，用当下这些工具，也许更好的做法是——干脆给每个员工一份 Claude、Gemini 或别的订阅，让他们自己决定怎么整合、怎么用得最顺手。

除此之外，两位还对于AI时代，针对AI辅助生成的代码，应该做怎样的测试给出了一个有意思的判断：属性测试又复兴了！

比如不要写 700 个测试去证明“在各种场景下机器人都不会杀我”，而是写一条规则：“防御机器人在任何情况下都不得杀死创造者。”——这才是有用的测试。

ok，料还很多，篇幅关系，这里就先打住。

小编这就为各位奉上整理的采访内容。密度很高，建议收藏细读。

 外行人用AI做Demo，是一场结构性变化

Chris Pirillo：大家好，我是Chris Pirillo，来自The NewStack。非常高兴见到各位。

今天我们要聊的主题是——如何让 AI 不再拖慢开发者的速度。我先自我声明一下：我不是程序员，连电视剧里的程序员都没演过。不过我算是一种“氛围型程序员”（vibe coder）：我在开发软件，但又不完全是传统意义的开发者，这本身就是个哲学问题。没人能回答我是不是“程序员”，不过这也没关系，我们今天要聊的话题才是真正有意思的。

和我一起参与讨论的有 Antithesis 的两位嘉宾——现场首席技术官 Akshay Shah，以及 CEO Will Wilson。

Akshay Shah：这个问题挺好。我其实本职是工程师，也曾是 Antithesis 的客户。当时我觉得他们的“来自未来的自动化测试技术”太惊人了，于是我就加入了。现在我的工作主要是和客户交流、参加像这样的讨论，让更多人理解这种技术，并让它真正落地。

Chris Pirillo：说到这，我自己也做过一个“外星人计算机终端”的小项目，用各种奇怪的字符和动画做出来，放到 GitHub 上后反响挺大。大家问我怎么实现的，我也答不上来——只是想做一个“外星终端”，结果它真的跑起来了。我知道有些人说这类东西只是个“潮流”，但我真心喜欢这种潮流。

Will Wilson：我觉得这不是潮流，而是个巨大的变化。它让非程序员也能快速做出原型，把想法具象化。以前设计师要做线框图、写产品文档，现在直接点个按钮、运行个 demo 就能展示效果。这极大改善了技术人员和非技术人员之间的沟通。

Chris Pirillo：对，我能理解。Akshay 是 Field CTO，那 Will 你作为 CEO，我猜你也得什么都管一点？

Will Wilson：没错，我负责点披萨和倒垃圾（笑）。

Akshay Shah：那你说说你到底都干嘛？

Will Wilson：所有其他没人干的事（笑）。

AI 把Demo开发提速 10%，但剩下的 90% 更难了，工程师来兜底

Chris Pirillo：哈哈，这就对了。我自己虽然懂点技术，但更多是站在产品经理的角度思考问题。我尊重代码的复杂性，但也不会被它束缚。像“vibe coding”这种让人用直觉和工具去创造技术的方式，真的挺迷人的。

Will Wilson：其实这种“原型和成品之间的差距”一直存在。你可以很快做个 demo，但要变成真正可用、可扩展、无 bug 的产品，那才是90% 的工作量。AI 工具确实把前 10% 的工作变成了 1%，但后面的 99%（也就是测试、健壮性、国际化、极端场景等）依然是瓶颈。

Chris Pirillo：我懂。AI 能加速早期阶段，但复杂度总归得有人来兜底。有人说：“现在是 AI 最糟糕的阶段，以后只会更好。”当然，也许有一天机器真会吃掉我们（笑），但我愿意相信事情会朝好的方向发展。

Akshay Shah：也许吧，但要注意一点——虽然模型在不断进步，但AI 对工程团队的影响不一定总是变好。技术进步常常带来意料之外的副作用，比如让系统更复杂或增加隐性风险。

为什么LLM让开发反而变慢了：公地悲剧

Chris Pirillo：那为什么很多公司用了 LLM 之后，开发反而变慢了？

Will Wilson：我觉得原因在于——LLM 其实还不够“聪明”。它更像是个“记忆巨兽”：见过互联网上所有的代码示例。对于常见问题，比如 React demo 或主流框架，它能迅速给出好结果；但一旦遇到新问题或小众技术栈，性能就会骤降。

它擅长“从 0 到 1”的生成，但不擅长在百万行代码库里做有逻辑的修改。它不会像人那样推理，只是在统计相似性。

Akshay Shah：对，而且还有个“次级效应”——过去我们把“写代码”当作一种“思考的证明”。但现在 LLM 可以帮你写代码，这个证明就消失了。团队协作体系还没适应这种变化。

这有点像自动驾驶汽车：当你以为它能完全接管时，其实它并不能。AI 写代码也一样，你太容易“放松警惕”，让它帮你开 Pull Request，然后你去问用户“你试了吗？”——这种行为模式破坏了原本工程师之间的信任契约。

Will Wilson：是的，现在很多开源项目已经开始拒绝 AI 生成的提交代码。除非贡献者声明“我看过每一行并理解它”，否则维护者不愿意审查。没人想帮 AI 善后。

Chris Pirillo：这其实在触及一个更深层的问题——速度的提升可能反而削弱了团队的质量控制机制。

Will Wilson：对。LLM 不会消失，就像我们不会回到编译器出现之前的时代。问题是，团队必须发展出新的文化习惯和技术防御体系，防止这些工具的滥用。

我常把它比作“公地悲剧”：一个人往湖里排点废水没关系，但大家都这么干，湖就完了。同理，一个人用 AI 快速写代码、丢给同事改问题还好，但所有人都这么做，整个系统的质量就崩塌了。

Akshay Shah：没错。AI 的使用也要有“环保意识”。否则生产效率的提升会被维护成本吞噬。

如何确保LLM不拖慢团队？最优秀的团队，都在“用文档与测试驯服 AI”

Chris Pirillo：说得好——那企业该怎么确保 LLM 真能提速，而不是拖慢团队呢？

Will Wilson：我认为关键在于控制使用这类强大但不可靠工具的“二阶后果”。AI 工具非常快、非常强大，但也非常容易出错。解决方案其实已经在出现：我们发现，那些大量使用 AI 和 LLM 的最优秀团队，都有极其完善的文档体系。

这其实带来双重好处。第一，文档本身可以作为 LLM 的上下文输入，帮助它输出更优结果；第二，文档能让团队保持对代码意图的共享理解——而这往往是“AI 写代码”环境下最先崩塌的东西。

另一个类似的关键点，是测试。可以把它看作另一种形式的文档。如果 LLM 写了一堆代码，而你有一套强大、健壮的自动化测试体系，能及时告诉你代码是否破坏了逻辑——那就意味着你可以“放心大胆地飞”。

比如你可以说：“LLM 写了这段代码，我没看完每一行，但测试全绿（通过）了，那我暂时允许它提交，之后再仔细审查。” 这样的体系让开发过程更轻松。有趣的是：那些最“保守”、最注重架构和测试规范的团队，反而能从 AI 工具中获得最大加速。

Chris Pirillo：Akshay，你怎么看？公司该怎么确保 LLM 真正提升速度？

Akshay Shah：Will 说得很到位。其实科技界很多问题早就有答案了。最优秀的团队一直擅长建立自动化护栏，减少人工的反复检查和收尾工作。AI 工具只是让“顶尖团队”与“普通团队”之间的差距进一步扩大。

Chris Pirillo：Will 提到了一个让人头疼的词：测试（Testing）。它到底为什么对 LLM 尤为重要？

Will Wilson：有两个原因。第一个是显而易见的：如果你信任自己的测试体系，知道它能覆盖代码的关键逻辑，那么即使你把部分思考交给一个“不会真正思考”的系统，也能放下负担。第二个原因其实更深刻：测试本身就是“会反击的文档”。每个测试都记录着开发者对系统行为的预期，这能有效防止在“高速协作”中出现的理解偏差和代码漂移。

测试是“会反击的文档”，也是最强的 Prompt

Akshay Shah：而那些对 LLM 最持怀疑态度的“老派工程师”常说：这场争论我们几十年前就吵过——汇编程序员批评 C，C 的人批评 Lisp，如今又轮到 LLM。

本质上，一个 prompt 其实就像是一种“高层编程语言”或“奇特编译器”中的规格说明。而最精确、最具可操作性的“规格说明”形式，就是测试套件（test suite）。

所以写出一套完备的测试，其实就是给 LLM 提供最精确的 prompt，让它不需要反复问“你想要这样吗？”，因为答案已经内嵌在测试中了。

Will Wilson：对，这正是一些团队（比如使用 Claude Code 的团队）已经在做的事：让模型在循环中修改代码、运行测试，直到通过所有检查。有时候它甚至“聪明”到会直接删掉测试（笑）——这可能是“机器人起义”的第一阶段。但显然，测试越多、定义越清晰，模型的效果越好、能力越强。

属性测试的复兴

Will Wilson：我认为接下来会复兴一种很特别的测试方式——属性测试（Property-Based Testing）。传统测试给出几个输入输出示例，比如“输入 1 输出 2，输入 2 输出 4”；而属性测试则定义抽象规则，比如：“无论输入什么数，输出都应是它的两倍。”这种方式既是更高维度的文档，也能更好地防止 LLM“钻空子”，让系统保持稳定。

Akshay Shah：对，最早的属性测试框架叫QuickCheck，发布于 1999 年。几乎同时，IETF 也确立了规范性用语：“MUST / MUST NOT / MAY”等大写关键字，用来表达开发者对规则的确定程度。

我觉得这两件事在今天都特别有意义：我们的测试应该像规范文档一样，直接、明确地表达人类对软件行为的期望。不要写成“例子堆砌”，而要写出“铁律”。

比如不要写 700 个测试去证明“在各种场景下机器人都不会杀我”，而是写一条规则：“防御机器人在任何情况下都不得杀死创造者。”——这才是有用的测试。

如何让AI重写旧系统，我们将处于一个“永久测试版本”时代

Chris Pirillo：我们收到一个现场观众提问。他问：未来的工作流将如何应对系统废弃（deprecation）的问题？

Will Wilson：好问题。我们没有时间机器，但确实可以“预见未来”。我理解你的意思是：当我们想重写或替换旧系统时，AI 工具和测试体系会如何帮忙？

其实这正是 LLM 特别擅长的场景。它非常擅长处理“迁移”类任务，比如：“请将这个系统重写为另一种语言”或“请改用新框架实现同样功能”。当然，它仍需要一定的指导和人工修正，但往往能帮你完成 80% 的工作。

而我们刚提到的属性测试在这里非常关键——你可以直接定义：‘新系统应与旧系统行为一致，但性能更好。’这样就能精确检测 AI 或工程师是否覆盖了所有边缘情况。我认为未来我们将更频繁地“拆掉旧系统、重建新系统”。

Akshay Shah：没错。这其实也是老生常谈。Michael Feathers 在那本经典著作《Working Effectively with Legacy Code》中早就说过：“所谓遗留代码，就是缺乏测试的代码。”

如今我们依然处在同样的境地，只是我们对软件演化速度的期望越来越高，因此我们必须写得更清晰、更可验证。

Chris Pirillo：我想到一个词——我们似乎正处在“永久测试版（Perpetual Beta）”的状态，没有任何东西是最终版。

Akshay Shah：我更乐观一点。这不是“半成品时代”，而是“迭代加速时代”。我们仍然能发布 1.0，但从 1.0 到 2.0 不该再等两年，而是两个月。

Vibe的价值，在于降低门槛，与其构建自动化流水线，不如给员工订阅Claude

Chris Pirillo：我同意。顺便，我提到过我那个“外星人终端”的 vibe coding 项目——我现在给大家展示下。

Akshay Shah：在 GitHub 上那个？

Chris Pirillo：对，就是那个。刷新一下就能换一组不同的小部件和颜色，全是“即兴 vibe coding”做出来的。不是严肃项目，就是好玩。虽然有一个 bug 我一直没修掉（笑）。

Akshay Shah：但这其实挺重要的。编程应该是一种游戏，一种探索。这世界上最棒的“乐高”就是软件，你可以靠它谋生。如果有一代人能从这种轻松好玩的方式入门，那未来的创新者就会更多。

Will Wilson：完全同意。有些人喜欢从零开始、纯手写代码；但对大多数人来说，从一个“能跑”的东西开始修改，更容易上手。而 vibe coding 的价值就在这里——它降低了进入门槛。

比如我小时候做游戏，全是文本界面，因为我画画太差。但今天，我可以让 Midjourney 给我画概念图，生成角色素材。AI 帮我补齐短板，这就是新一代创造者的力量所在。

Akshay Shah：这就回到我们一开始讨论的那个核心点——把 AI 整合进你的工作流程、让大模型真正帮你提速的最佳方式，并不是把整项任务全权交给它然后转身走人。而是把它当作一个“共创伙伴”，帮你补短板，在你卡住时给你提示。

我桌上摆着一只橡皮小黄鸭，每当我卡壳时，我就会跟它说话。它当然不会回我话，但 Claude 会。

图片

Akshay Shah：Claude 就像一个更聪明的“小黄鸭”，能在你陷入困境时帮你理清思路，这太神奇了。当然，这并不是一个“适合企业推广的故事”——它不是那种买来、部署、统计使用率、然后逼着工程师用的企业软件。

这更像是一种“个人选择”，就像我自己的 vim 配置，是让我变得更快、更高效的私人物品。

而这其实也是企业现在面临的问题——要在公司层面把 AI 部署成一种“大而全的自动化流水线”，并且真正提取价值，其实很难。反而，用当下这些工具，也许更好的做法是——干脆给每个员工一份 Claude、Gemini 或别的订阅，让他们自己决定怎么整合、怎么用得最顺手。

Chris Pirillo：是啊。

Will Wilson：我也有小黄鸭，我有好几只。

Akshay Shah：我不会和它们说话，我的是达斯·维达款小黄鸭。

VibeCoding的理解债和技术债

Chris Pirillo：哈哈，我喜欢这个。其实我也有几只维达鸭，它们也不会回我话。我最近在 3D 打印鸭子，这已经成了我日常的一部分。不过说回主题——我觉得我已经成了“vibe coding”的粉丝，这对我来说不仅是个爱好。那么，从长远来看，vibe coding 会带来哪些潜在问题？

Will Wilson：有人提出一个词，叫“理解债”（comprehension debt）。每次你用 vibe coding 写点东西，如果你没有认真 review 到“仿佛这段代码就是你亲手写的”这种程度，你其实就在代码库里放进了一段你并不真正理解的东西。如果这样做的次数太多，你最终就不知道整个程序是怎么运作的了。

Will Wilson：一旦出现一个 AI 解决不了的问题，你就彻底陷进去了。这个问题不仅会在个人层面出现，也会在团队层面蔓延。比如我和我的同事 Bob 一起写代码，有一块是 Bob 的专长，我自然会依赖他回答那部分的问题。但如果 Bob 都用 vibe coding 在写代码，而他自己也不清楚那部分到底怎么运作，那事情就会变得非常危险。

Will Wilson：如果你希望你的软件是长期存在、可维护、能持续交付的，那你必须非常警惕这种情况——最后也许没人知道系统是怎么跑的。还有一个更具体的版本，就是“技术债”——我们都很熟悉。它指的是你写的代码“眼下能跑”，但无法扩展、不能复用、将来不好改。

团队通常会严肃地管理技术债，但 AI 的动机跟团队的不一样——如果你不小心，它可能在帮你增加理解债的同时，也在疯狂制造技术债。

开发范式被大模型锁死在2024

Akshay Shah：完全同意。而且我觉得 AI 还有另一个结构性影响——它会强化行业里的“既得赢家”。

比如你在做一个前端应用，AI 模型在生成 React 代码方面会比 Svelte 强，这不是因为它“偏好 React”，而是因为它训练过的 React 代码实在太多了。这让我很担心——未来新技术要怎么推广？

Will Wilson：这是个特别好的问题。

Akshay Shah：我最近在写 Zig 语言，发现让大模型写 Zig 几乎不可能。它会生成一些看起来像 Zig、但根本过不了编译的奇怪代码。原因很简单——Zig 太新了，世界上可供学习的 Zig 代码太少，而且版本变化快。

这不意味着 Zig 不好，虽然有些人觉得它不好，但也有很多聪明人认为它是系统编程的一大进步。但现实是：我现在写 C 比写 Zig 还轻松，因为模型在 C 语言上能替我扛掉更多工作。

Chris Pirillo：因为你对 C 足够熟，能提供更好的上下文。

Akshay Shah：对，一方面是这个，另一方面就是——世界上实在有太多 C 代码，模型对它的“第一反应”就更准。

Will Wilson：没错，所以人们担心这会造成技术停滞。LLM 就像那个“学不会新花样的老顽固”，它需要无数示例才能学点新东西。

Akshay Shah：这话有点伤人（笑）。

Will Wilson：哈哈，但这是个真问题。如果我们真的被锁死在 2024 年的开发范式里，那就糟了。

别让AI带头，一定要让团队保持锋芒

Chris Pirillo：那你觉得该怎么在工程实践中整合 AI 编码，才能避免这些问题？

Akshay Shah：这是个好问题。简单的答案是——“谨慎，并视情况而定”。我现在的做法是：在写一些新东西、风险较低、或只是探索新思路时，我会让大模型承担更多实现层面的工作。这时我会把注意力放在测试和验证上，因为这样我能更放心地让模型写更多实现代码。

Will Wilson：我同意。核心是别让团队的能力退化。如果一个工程师长期让 AI 代劳，过几周不写代码，手感就会生疏。语言也是一样，写了一年 Python，就会忘了怎么写 C。这些“问题解决的肌肉”如果不用，就会退化。未来的挑战是：如何在用好 AI 的同时，让团队保持锋芒。

Chris Pirillo：有观众在聊天室留言说：当我 vibe coding 时，我往往会沿着 LLM 给的方向去构建，哪怕那不是最好的思路。因为一旦模型给出答案，我的脑子就被那个答案“固化”了，除非后来被证明错误，否则我就会一直沿着那条路走。

Akshay Shah：这其实和人与人协作也很像。正常情况下，我们不会走过去就说“你告诉我该怎么做”。更常见的是对话：我会问，“这里我有哪些选项？”、“有哪几种可能的做法？”AI 如果被这样使用——作为一个思路扩展器、方案生成器——其实会很有价值。

Will Wilson：对，我认识的一个最热衷于 AI 编码的人说得很好——“我是老板，AI 不是老板。”他说，关键是：我先想清楚要怎么做，再让 AI 去执行。这样我就能判断它做得对不对。如果反过来——我让 AI 带头，而我再去判断它做得对不对，那我就完蛋了。

Akshay Shah：乔布斯说过一句话：“个人电脑是人类思维的自行车。”AI 也一样——它是一种“智力倍增器”，能让我们以更快速度、更大范围去解决问题。但它是一辆自行车，不是一个人。

Chris Pirillo：对，它是工具。你们说的其实让我想到我自己的体验——哪怕我不是你们那种技术专家，当我用这些工具时，我得先明确我要什么，再去告诉它“不，这不是我要的，应该是这样。”这样最后得到的成果才“完整、正确”。哪怕有缺陷，也比之前更接近目标。

AI时代，新手何去何从？

Chris Pirillo：顺便说一句，我没在假装喝咖啡（笑）。我手边真的有两只杯子，都是无咖啡因的，一只是浓缩的，一只是大杯。别以为我是在做 AI 视频特效（笑）。

Chris Pirillo：这是真人、真对话、真影响的讨论。最后一个问题：你们对刚入行的软件工程师，有什么建议？

Will Wilson：我有两个方向建议。第一种：如果你天生喜欢钻研、善于思考底层机制，那么未来永远需要这样的人。不管是 CPU、操作系统、运行时、语言、编译器……每一层都有极难的问题，AI 暂时都替代不了这些深度开发者。

第二种：掌握足够的编程技能，但别止步于此。去深挖一个具体领域，比如金融、化工、税务、能源……成为那个能把软件与领域结合的专家。未来 AI 会让这种“跨界专家”的价值大幅提升，因为你能更高效地运用软件能力深入行业内部。

Akshay Shah：不论你走哪条路，现在都是令人兴奋的时代。从第一台 ENIAC 到现在，也才五十多年。如果你现在刚开始职业生涯，你的一生将覆盖计算机史的一半。作为技术人，我们的使命就是活在一点点未来里。我相信那个未来更广阔、更充满希望。还有什么职业能比这更让人激动？

Chris Pirillo：没错。我来自爱荷华州，好像 ENIAC 最初就在那建造的？

Akshay Shah：没错。

Chris Pirillo：从填满一整间屋子的电脑，到现在手掌里能运行上亿倍计算力的设备，真是惊人。未来软件开发的形态也一样令人期待。现在已经有人能在手机上“vibe code”，直接写应用、造组件，这种“技术民主化”的趋势太棒了。

Akshay Shah：完全同意。

Chris Pirillo：是的，这是一个很积极的结尾（笑）。我希望未来真是这样。谢谢 Will，谢谢两位的分享——我真心享受这场对谈，即使没在直播，我也会乐在其中。

Will Wilson：谢谢邀请，这真的很有意思。

Akshay Shah：谢谢。

Chris Pirillo：我只是希望能让过程更有趣。再次感谢各位的收看。

本文转载自​​51CTO技术栈​​，作者：云昭