LLM 批评者是对的。我还是在用 LLM

批评的范围与使用

• 许多评论者同意关于 LLM 的关键批评（幻觉、技能退化、中心化、环境成本、伦理）是成立的，但仍然大量使用 LLM。
• 也有人认为，若清楚其局限，使用一个有缺陷的工具并不矛盾；批评者和使用者并不是互不重叠的群体。
• 有些人把对 LLM 输出一概斥为“slop”视为对其当前能力的否认；另一些人则认为无条件热情同样有偏见。

技能退化与知识深度

• 普遍担忧是，把“低层次”工作（编码细节、正则表达式、调试）外包出去，会在多年后侵蚀基础技能和架构判断力。
• 反驳观点：我们一直在抽象掉各层（计算器、编译器、云）；真正需要深厚底层技能的只是少数人。
• 有几位表示，依赖代理后已经注意到自己的回忆与保留能力变弱；有人会刻意让业余项目不使用 LLM，来“锻炼”自己的技能。
• 讨论还包括：没有底层理解，能否做好高层设计；一些“系统工程师”和 AI 用户给出了不连贯的架构作为例子。

生产力、质量与验证

• 反馈从“没有净收益”（花在审阅上的时间抵消了生成带来的收益）到“个人生产力提升约 1.5–2 倍”再到“裁员后团队产出提升约 25%”不等。
• 引用的研究表明，开发者会系统性高估收益；团队层面的提升通常很有限，而且常被额外开销或更多实验吞噬。
• 收益非常依赖上下文和质量标准：当“slop 可以接受”或用于样板代码时，LLM 很出色；但在高质量、安全关键的工作中，它们可能拖慢进度。
• 许多人说，开发者把收益“兑现”为更少的倦怠或更多副项目，而不是更高的公司产出。
• 一个共识是：信任与审查比代码是否由 AI 生成更重要。带测试、且改动较小的 diff 还可管理；而大规模代理生成的改动则不行。

测试、代码审查与代理

• 有人担心 LLM 写出的测试可能很琐碎，却能给出惊人的覆盖率数字，从而带来虚假的信心。
• 有些人确实有效地用 LLM 生成或重构测试套件，但强调必须有人类审查，并使用比行覆盖率/分支覆盖率更强的指标。
• 即使局部片段没问题，代理也可能生成结构混乱的代码库；架构和约束的责任仍在于人类。

初级开发者、指导与开源

• 人们担心，用代理替代“初级任务”会损害培养链条和长期代码质量。
• 开源维护者报告说，低质量、AI 编写的 PR 激增，往往比自己直接写修复更难审查，导致更强的门槛控制。
• 也有人指出，借助 LLM 的同事有时会提交更符合惯例的代码，实际上减少了审查负担。

认知与社会影响

• 有人担心，广泛使用 LLM 会使写作和思维趋于同质化，类似平台如何塑造文化；也有人认为它们只是另一种扩展“常识”的工具。
• 有些人把 LLM 当作导师和面试准备伙伴，确实报告了学习上的收益。

伦理、环境与 Token 使用

• 道德上的反对主要集中在数据来源、公司行为和环境影响；尽管如此仍使用 LLM，这一点被承认为一种认知失调。
• 关于碳成本的争论：有人认为每天的 token 使用量与通勤/食物相比微不足道；另一些人强调数据中心的总体增长以及 AI 能源占比的预测。
• 大规模 token 支出（例如每月约 1 万美元）极具争议：有人认为这是浪费或滥用代理；也有人认为，相比再雇一名工程师的成本，这样的支出相当划算。