AI 编程的诚实评价：别让它写代码
An Honest Review of AI Programming
公司强制我使用 Claude 进行 AI 编程，起初我对此充满抵触，认为这是管理层对工程师的过度干预。经过三个月的实战，我发现 LLM 在搜索内部知识库和总结信息方面确实高效，能帮我快速定位 Slack 聊天记录或旧文档中的答案。但核心原则是：千万别让它直接写代码。LLM 本质是基于统计概率的文本生成器，而非逻辑推理引擎，面对 C++ 或 Vulkan 等特定技术细节时，它极易产生幻觉，编造不存在的 API 或功能。它擅长做“搜索引擎”的总结者，却是个糟糕的“程序员”。
只要你不让它写代码，它就还挺有用；但请绝对不要让它写代码。
HN 评论区
76- tangotaylor
> 在过去，我每年都得为了续用一个每月约 20 欧元的剖析工具许可证而据理力争。后来听说，公司里现在人人都配了 Claude 订阅，连非程序员也不例外。
这句被低估的名言。我也觉得这很让人沮丧。在我待过的一家非常老的公司（当时正试图转型做软件工程），为了申请 Pycharm、Obsidian 甚至 GitHub 的访问权限，我们跟 IT 部门打了一场场地狱般的官僚主义战役。可后来 AI 热潮一来，管理层二话不说就给全员配了 GitHub Copilot，甚至都没需要我们开口。
Cory Doctorow 的书《逆半人马座指南：AI 时代后的生活》对此有更多探讨。这不过是古老权力斗争的现代症状罢了。员工希望对自己的手艺拥有更多掌控权，包括质量标准和使用工具，但老板们却想加强对员工的控制。
眼下发生的情况是，老板们感受到来自投资者的压力，必须展示 AI 带来的生产力提升，于是他们在公司内部恐慌式地强推 AI。这导致了激励错位，比如 tokenmaxxing（疯狂堆 token）。
- adamddev1
这位老哥做的可不光是简单臃肿的终端用户应用。他试图深入代码，进行新颖的性能优化等等。他看穿了 AI 并不能搞定所有代码。
- dr0idattack
我喜欢文章里提到的那两个原始实验，它们在微观层面与我一年多来深度智能体开发的经验不谋而合。但我真想看到一篇专门写他经验的文章，包括他用了哪个模型（Opus？Fable？呃，Sonnet？）以及投入了多少精力。
我在使用最新的 Claude 系和 GPT 模型方面有所进步，通常把它们视为称职的队友或伙伴，也大致知道如何把虚张声势的废话和真材实料区分开来（天哪，当年我还是个毛头小子程序员时也是这副德行：因为编译无误且跑了一次没段错误，就过度自信了。）
你得投入时间，打磨技能，设计系统提示词/个性化配置，进行（有时是 adversarial 的）自动化，还要做测试和验证，去踢倒那些循环城堡（这通常是因为在最高努力级别下耍小聪明造成的）。
- spprashant
> 虽然我发现 LLM 在调研和规划代码变更方面很有用，但我尝试让它们直接写代码的效果却相当惨淡。我发现它们生成速度慢、成本高，结果却平平无奇。
我认为这个观察对于作者正在处理的那类问题大体上是成立的。
但我不会因此就断定要避免在写代码时使用 LLM。LLM 在工程师花费时间的 95% 以上的代码上表现非常出色。对于这些部分，我们应该利用这项技术。
作为工程师，我们需要自己判断何时该停止使用 LLM。我们比单纯把日志和几个专门的 markdown 文件丢给 LLM 然后让它想办法要聪明得多。
- btbuildem
读起来就像是从过去穿越回来的时间旅行者写的东西。