程序员视角：AI编程的诚实评价

如今想避开大语言模型（LLM）已经越来越难了。就算你完全不用社交媒体（或者说至少过滤掉了信息洪流中的大部分垃圾内容），对那些在新闻中被理所当然地接受了的夸大营销说辞也嗤之以鼻，它仍然很可能找上门来，在你的工作场所与你相遇。不同于过去的那些"银弹"（比如微服务或 NoSQL），AI 的采纳似乎在很多地方都是从管理层自上而下强制推动的，不管这些人中有多少真正干过（或者学过）工程类工作。

我承认这种方法立即触发了我的逆向心理，让我对所有 AI 工具都产生了强烈的抵触。我不相信一个从未写过一行代码的人应该来指点我该用什么工具来做工程工作。这听起来像是最极端的微管理案例，而且这从来都不是什么好事（更别说还涉及对个人的冒犯）。

不管怎样，在过去三个月里，我工作中用到了 Claude 及其同类产品，我不得不承认它确实有一定用处。只要你别让它写代码就好。请千万不要让它写代码。但我有点说在前头了。

人工"智能"

你可能已经听腻了，但人工智能真的没那么智能。全是营销和时髦词汇。我们真正拥有的只是一个（非常庞大的）专注于自然语言处理的神经网络。

事实证明，我们在电脑上做的很多事情本质上都是用文字进行双向交流，而这个模型可以被用来解析查询、根据概率启发式方法生成文本响应¹，或者输出命令行，然后以传统方式执行，再将结果反馈给模型，形成一个循环，直到达到某个退出条件。

这并不是说这样做天生就是坏的。但它也不神奇。"AI 智能体工作流"（或者在你读这篇文章时他们怎么叫它）不过是认识到这样一个事实：每个软件问题都可以通过再添加一层间接寻址来解决，LLM 也不例外。如果神经网络的输出可以通过提供更多输入来改进，那就接入更多输入。如果找出具体该接什么输入的最佳方式是查询模型让它生成一条命令，然后通过 system() 来执行，那就这么干。

但对于本文的其余部分，让我们把焦点放在用户体验上。

家有谷歌……

互联网上有大量有价值的东西。如果我们做好维护现有记录的工作，公共知识的净总量只会增加（但是，预先提示，这里有一个问题）。问题在于找到它。这不是什么新鲜事。我年纪大到还记得最初被推荐去试试这个新"谷歌"的时候。但遗憾的是，自 2000 年代的黄金时代以来，情况已经变得相当糟糕。他们一直在与 SEO 打一场艰难的持久战，而且看起来并没有占到上风²。

AI 作为搜索工具，我发现它在用自然语言表达针对性问题方面通常表现不错，尤其是考虑到其对话能力可以让你在当前上下文的基础上细化答案或提出后续问题。在实践中，这相当于执行多次搜索、浏览前 N 条链接，然后重复直到我们认为已经搞清楚了大致情况。写一段较长文本的简短摘要似乎是 LL最擅长的事情，因此用它来自动化这个过程是合理的。此外，抓取并汇总多次搜索本质上是一个可以并行的任务，所以如果我们有足够的算力且它不会在摘要中产生幻觉，就能看到自动化带来的效率提升——我们稍后会回到这两个要点，因为它们相当重要。

阻碍的一面当然是，LLM 降低了用文字垃圾信息淹没互联网的成本，这些内容稀释了本就堪忧的信息海洋。Freya Holmér 就这个话题和用 AI 生成内容污染网页对永无止境的 SEO 军备竞赛的影响发布了一个非常好的视频。手动搜索信息在今天仍然是一个选择，尤其是当你已经知道某个特定主题的可靠来源时。但如果你不知道，那就需要非常小心地把垃圾和真实数据区分开来，而如果你无法指示它保留哪些来源、丢弃哪些来源，用 LLM 循环来自动化这个过程可能并没有帮助。甚至在谈论幻觉之前，LLM 生成的摘要质量上限取决于它摄入的来源质量。

……现在还有工作中的谷歌

在一个我还没看到太多讨论的搜索场景中，LLM 循环被证明特别有用，那就是企业内部知识库。无论你在哪里工作，很可能都有维基、Slack 对话、Google Drives、Confluence 页面等各种组合，其中有很多有用的信息，但似乎从来没有人能找到。我经历过一些这种"企业解决方案"做得非常糟糕，有时候我甚至找不到一周前浏览过的页面，即使我在搜索栏中输入了标题（或者我记得的标题）。我写过很多内部技术文章，我非常确信没有人找到过它们，除非他们在我在技术群里首次分享链接时保存了书签。

在过去的几个月里，尽管我刚加入这家公司，但我已经能够找到许多在我入职前就写好的答案。因为就像"AI 谷歌搜索"可以并行运行多个查询并汇总答案一样，Claude 及其同类产品可以将我的自然语言问题转化为一系列可能同义词的搜索查询，直到命中目标。当我遇到引擎的一个特定边缘情况时，它被证明非常方便，我可以快速搜索是否有人报告过这个问题、是否提供了变通方案，或者讨论过为什么它必须这样表现。每次你在技术工作中遇到问题，很可能在之前已经被讨论过了，而如果你能找到那些对话，你会处于一个好得多的起点。

从技术上说这不是什么新东西。谷歌及其同类产品长期以来如此高效的原因之一，是它们在构建页面关键词元数据时会自动生成同义词。你的公司维基或聊天搜索功能很可能没有³。我怀疑在 Slack 对话记录中有很多价值被埋没，这些记录已经有一年了，如果没有 LLM 来搜索，或者一位更资深的同事能够记住并指引你方向，就很难获取到。

从技术角度看，用一个昂贵的 LLM 在公司维基上搜索是否高效？答案是否定的，我相当确定它并不高效。索引内容的方式如果像谷歌 20 年前做的那样，肯定在计算资源上会高效得多。但从用户角度来看，它比试图搜索"UI"却因为他们要找的页面中纯文本写的是"User Interface"而得不到结果要好得多。

幻觉与误报

一旦 LLM 找到了一个答案，通常好的做法是去看看原始来源。阅读那篇文章、文档或聊天记录将有助于确保答案不是幻觉产生的。

幻觉是 LLMs 工作方式固有的特性。Token 的生成不是基于逻辑或真理，而是基于统计学，据我理解，没有任何方法可以完全避免它们。我在所有模型上都遇到过这个问题，从必应自带的 Copilot 免费版（相当糟糕）到 Claude 最顶级的付费模型。

我发现它们最常出现在问一个非常具体的问题而这个问题之前没有被回答过的时候，比如问 CMake、Vulkan 或 Xcode 中的某个特定小众功能。它不会回答"不，它做不到"，而是给出最概率化的答案，建议我点击一个不存在的按钮或启用一个不存在的功能标志。

整个过程有点像问一个对某个问题领域有大致了解的人，但不是你正在使用的特定软件或库。他们会回答"是的，这听起来像是一件你应该能做到的事"，因为这像是一个合理的期望，而且在类似的产品中可能确实有这个功能。我怀疑这就是为什么在写代码时 LLM 会尝试调用一个不存在的 API，因为根据其他语言的经验，C++ 容器应该有 .sort() 函数。因为这是你在 Python 和 C# 中可以做的事情。实际情况并非如此，因为 C++ 对容器、迭代器和算法有严格的区分，但 LLMs 不会（尽管其营销声称在"推理"）从第一性原理出发进行推理。

虽然这可以通过始终要求提供原始来源或引用来部分补救，但我讨厌的是，你必须在查询中添加一些神奇咒语才能获得正确的结果。拿"make no mistake"表情包开玩笑确实很有趣，直到你开始认真地考虑类似的事情。此外，模型似乎每隔一年或更短时间就会发布新版本，这可能需要用户修改所有的仪式（或者看着这些仪式变成工程师们做了却不知道为什么要做的无意义习惯）。

另一个我注意到的问题是，使用连接器时，让 LLM 自我喂养是相当容易的。例如，当被要求查找我为客户撰写的某条建议的先前提及内容时，Claude 坚持认为这得到了过去的报告支持……直到后来发现其中一份报告实际上就是我自己正在写的那份。这很容易被发现，因为我有关于来源的详细分析，但如果它只是给我一些数字，我很可能已经创造了一个自我强化的循环。同样，如果同事们查询同一个数据库并发现了我这份工作进行中的报告，他们的摘要可能会将其视为金科玉律。再说一遍，那些机器人绝不是什么智能体，通常你需要非常清楚地阐述一些非常基本的事情，以避免做出非常愚蠢的假设。

关于这个话题的最后一点，我还注意到一个风险：接入另一个 LLM 的连接器可能会发生"传话游戏"。有一次，Claude 告诉我有确凿证据表明某项技术设计是团队深思熟虑后的选择，然而实际上它是把另一个 AI 的摘要当作事实接受了，而真正的原始来源是两个用户在公共论坛上猜测为什么这个模块会以这种方式工作。再说一遍，这是一个擅长汇总数据的工具，但并不总是擅长选择哪些数据值得信任。

到上一段为止，我的使用场景都集中在研究上。但写代码呢？毕竟，这可是下一个大事件™，不是吗？它随时都会到来，不是吗？简单来说：它不太好。

虽然我发现 LLM 在研究和规划代码变更方面很有用，但我尝试让它们实际写代码的效果却相当差强人意。我发现生成的结果既慢又贵，换来的却是一个平庸的产出。

在一个使用案例中，经过长时间的讨论后，我要求它做一个优化重构：移除 MonoBehaviour 派生对象的 Update() 方法，将这些对象放入管理器类拥有的 List<Foo> 中，然后在管理器类中以 for 循环运行等效的更新。这是 Unity 游戏中的一个相当常见的优化，以避免在有多个同类型对象时，从引擎的 C++ 部分调用托管 C# 脚本时支付 MonoBehaviour.Update()（虚）调用的成本。

Claude 没有只做这一件事，而是创建了一个带有 OnUpdate() 方法的 GameUpdateable 基类，让 Foo 继承自它，然后在管理器中以 List<GameUpdateable> 存储数组，并用一个循环调用 GameUpdateable.OnUpdate()。虽然这仍然可以被某些 C# 后端去虚化，而且使用纯 C# 调用相比 C++ 到 C# 的调用仍然是胜利，但它仍然比我要求的更复杂和过度设计。Claude 没有"直接做这件事"，而是决定应用某种不必要的 OOP 设计模式。这不是一个很难的事情，变更只涉及可能 2 或 3 个文件。

研究表明，这可能是由于游戏开发（以及在一定程度上所有原生编程）的训练数据质量较差。偏好 OOP 的语言主导了训练数据，即使应用了一些过滤权重也是如此。

更糟糕的是，在游戏领域，几乎没有可用的原始来源。上一款开源的 AAA 游戏是《毁灭战士 3》，这是 2004 年发布的作品，距今已有 22 年。它甚至没有多线程⁴！过去几年在 Github 上发布的其他经典作品通常是 90 年代的，包含软件光栅化或幸运的话是固定管线 OpenGL 1.2。

如果你今天让 LLM 写游戏代码，它很可能是根据业余项目、游戏开发 jam 和教程演示进行训练的，假设它接受过游戏相关的训练的话。

从事定制引擎和专用脚本语言的朋友告诉我，他们从 LLM 获得的大部分脚本与他们内部编写的方式完全不同，因为他们内部脚本语言的可用训练数据只能在模组中找到。

哦，当我提到贵的时候，记住输出使用的 token 是输入的 5 到 10 倍（或者说输出 token 的价格是输入的 5-10 倍，结果是一样的）。所以虽然写摘要不会太消耗 token，因为它摄入的内容远多于产出的内容，但让它写代码则相反。

我最近在阅读英国管理顾问 Stafford Beer⁵ 的工作。他的整个管理控制论⁶领域可以非常粗略地总结为一个观点：管理者（在更大范围内是公司）处理自身运作、客户和供应商以及任何可能影响结果的其他因素的信息能力，决定了其做出正确决策的能力。一个重要因素是，随着情况变化，总是会有更多的信息（信号）涌入，因此如果某些东西无法被处理，它很可能被丢弃；如果太多东西被丢弃（例如你采取极端情况，将所有输入减少为绿色或红色信号），坏事就会发生。你需要在被处理的数据中有足够的多样性，以避免错过关键的东西。

在一个类似（但我承认不完全准确）的类比中，置身于一个新代码库需要处理大量数据才能做出正确的判断。每次你换工作或项目时都会发生这种情况，当你身处咨询行业时，这种情况可能相当频繁。因此，当试图在短时间内对一个项目产生影响时，一个人往往受到其能够吸收的信息量的限制。在这些环境中，有一个可以帮助探索代码和顺藤摸瓜的 LLM 是相当有帮助的。也许我们应该坚持使用最初的"AI 编程助手"这个名字，而不是试图让它们做所有事情……

我也确实用它来帮助我修复 bug，同样在我不熟悉的领域发现它很有用，因为它帮助我理解了一些代码，但我再次强调需要仔细检查所有内容。当涉及我以前做过的事情时，我通常能发现荒谬的说法，但对于新主题来说，它危险得多。

举几个例子，我在我的个人渲染项目中尝试用它来帮助理解我试图理解的 bug，得到了好坏参半的结果。

第一个是由于坐标系手性混淆导致的剔除 bug。如果不像我一样固执地拒绝学习其第一性原理数学的人，应该相当容易找到它。我确信从事图形学几年的人会很快发现它。当被要求写一个修复方案时，它提出了一个教科书式的解决方案，可以工作，但比我一直借鉴的项目的效率低得多，尽管 Claude 已经在上下文中解析了该源码。

第二个是一个 PBR 光照问题，它建议我们重写整个光照、移动主光源位置并添加环境光照，折腾了几个小时后得出结论：其中一个资产的金属度/粗糙度纹理有问题，再怎么改光照代码都无法正确修复。同样，当你不是该主题的专家时，很容易被听起来很自信的 LLM 带入 wild goose chase。我最近一直在心里记住这句话：

有意思的是，AI 一直在在我专业领域提供虚假信息和错误陈述。幸运的是，在我知之甚少的 topics 上，它非常有用且总是正确的。— pikuma.com (@pikuma) 2026 年 6 月 19 日

AI 公司都在亏损。当然它们都有承诺，说最终会盈利并带来疯狂的投资回报，但到目前为止还没有。你获得的 token 正在产生边际利润，但总体而言它们仍在亏损。考虑到硬件没有变得更便宜，而且模型仍然需要一直训练，目前看来当前的价格是不可持续的。

这些都是为了说明，有迹象表明 LLM 在未来会更加昂贵，而不是更便宜。像你可以在工作中购买或租用的每一种工具一样，应该牢记成本效益计算，到目前为止，这似乎没有在除了公司强制所有人使用 AI、几个月后收到账单后再发出反向命令之外的地方发生。

在上一份工作中，我每年都得费力争取续费一个 profiling 工具的许可证，每月费用约 20 欧元。听说后来公司里人人都配了 Claude 订阅，连非程序员都有。这种决策让我百思不得其解。管理层不会信任工程师自行决定购买他们声称需要的工具，但却会告诉所有人必须用他们根本没要求过的、闪闪发光且昂贵的新玩具。

对普通程序员来说，LLM 订阅是否比 profiler 许可证更通用？大概吧。在我不熟悉的领域，我确实发现它能加速研究。但如果我一直做同一个项目，我会每天用它吗？大概不会。它根本改变了我编程的方式了吗？并没有。它会取代程序员吗？我认为还做不到，而且此刻我严重怀疑它是否有一天能做到。

而如果你发现自己经常用它来写样板代码，而这些代码你并不真的想去 review，那也许你需要投资一个更好的 API。

1: 我知道 LLM 也能生成图像和视频格式。但这不在本文讨论范围内。而且效果很差。AI"艺术"在我看来根本不可行。

2: 如果你喜欢烹饪，有时会在网上搜索食谱，你一定完全明白我的意思。

3: 另一方面，邮件搜索自 Google Desktop 时代以来确实有了进展——那时候要在 Outlook 里搜索任何东西都得先装 Google Desktop，这大概是因为如今最大的邮件提供商同时也在运营搜索引擎和 AI 研发部门。

4: 2012 年的 BFG 版确实有一些[内容]，但更像是移植而非新作。

5: 如果你听过"系统的目的就是它所做的"这句话，那就是他说的。

6: 啤酒[文化]受到了 W. Ross Ashby 的影响，而 Ashby 又在 Claude Shannon 的成果上继续发展。是的，就是你那 LLM 名字里的那位 Claude。从某种意义上说，我们兜了一圈回来了。

7: 意思是说如果只考虑运行模型的直接成本，它们是盈利的，这其中排除了大量研发和硬件支出。