Claude Code 热潮退去后：它真能提升"真实"代码的生产力吗？

一位来自生物信息学软件团队的开发者，在经历了对 Claude Code 从追捧到祛魅的完整周期后，给出了一个颇具争议的结论：代码越重要，Claude 对他而言就越没用——这恰恰与一个优秀生产力工具应有的表现相反。这篇来自 Reddit 的深度吐槽，道出了许多专业开发者在高标准生产环境中使用 AI 编程工具时的真实困境。

一个两极分化的工具

这位开发者的核心观点很直接：使用 Claude Code 时，你基本只有两种选择。

要么你接受"vibe coding"（凭感觉编码），对代码的内在质量不做过多要求，只要能跑出结果就行——在这种场景下，Claude 的表现"碾压一切"；要么你坚持人类工程师的质量标准，而此时 Claude 的输出错得足够离谱，以至于自己写反而更快。

这种两极分化的特性，在非关键任务、无需高可读性的场景下并不构成问题。但他所在的团队开发的是生物信息学软件，正确性、可读性和一致性是绝对的生命线。代码库必须被开发者充分理解，否则会对人们的健康福祉产生实际影响。在这样的要求下，"痛苦就开始了"。

"Vibe coding"是2025年初由Andrej Karpathy提出并迅速流行的概念，指一种完全依赖AI生成代码、开发者自己几乎不阅读甚至不理解代码细节的编程方式——核心是「感觉能跑就行」。这种模式在快速原型验证、个人项目或一次性脚本中有其合理性，因为此类场景对代码可维护性和长期正确性要求极低。但它与专业工程实践之间存在根本性的价值观冲突：正式的软件工程要求代码可审查、可维护、行为可预测，而vibe coding则主动放弃了对这些属性的追求。这位作者所揭示的困境，本质上是AI工具被设计为优化vibe coding体验，却被应用于需要工程纪律的场景时产生的结构性错配。

每天都要纠正 Claude 的六类问题

尽管他认真尝试过各种官方推荐的最佳实践——规划、编写指南文档、创建 skills——Claude 仍然无法稳定产出符合标准的代码。他列举了需要每天手动修正的典型问题：

设计与抽象能力缺失。 在所有抽象层级上，Claude 都不像人类那样进行设计，需要持续"看护"。即便是单个函数签名这样的底层细节，它也无法稳定地做对。

命名问题。 名称往往不包含恰当层级的信息，而且 Claude 喜欢自创古怪的术语，拒绝使用领域内的标准术语。

注释与文档。 信息密度从来对不上，写作风格"糟糕透顶"，往往需要全部删掉重写。

错误处理混乱。 Claude 经常写出吞掉错误或静默失败的代码，需要大量 prompt 才能避免，更糟的是这种行为不可预测。

算法效率低下。 对性能的基础关注很差，会产生重复计算同一结果的奇怪代码流，开发者还得花时间去理解和修复。

治标不治本。 Claude 的默认做法是"打补丁"式修复，必须不断提示它退一步、重新评估，才能找到真正最优的方案。

此外还有人尽皆知的过度冗长问题。

最佳实践为何救不了场

作者预判了社区的标准回应：初始化仓库、使用规划、写具体的 prompt、创建 skills。他承认这些确实能提升表现，但认为它们无法从根本上解决问题，原因有三。

第一，起点太低。如果连变量命名这种细节都要规划到极致粒度，那还不如自己动手写来得快。

第二，Claude 在太多场景下出错，导致一个不断膨胀的"待修复补丁集"。到某个临界点，修补的成本高到不划算，真正的解法是一个更好的基线能力。

第三，也是最致命的——指令遵循的不一致性。他在 CLAUDE.md 文件里写了从高层方法论到具体操作的各类指令，但 Claude 往往在几条消息之后就把它们"愉快地忘掉了"。这种不一致极难驾驭。

他坦言，自己不想把一整天的时间花在反复给 Claude "补课"上，教它用 null 而不是传入垃圾值这类基本常识，"这不值得付出认知成本"。

CLAUDE.md是Anthropic为Claude Code设计的项目级配置文件，放置在代码仓库根目录，用于向模型传达项目规范、编码风格偏好、架构约定等持久性指令——其设计初衷是解决「每次对话都要重复说明背景」的问题。类似地，「skills」是用户可定义的可复用任务模板。这套机制的理论前提是：如果把规则写进上下文，模型就能持续遵守。但作者指出的核心问题是，Claude在长对话中会出现「指令衰减」现象——随着对话轮次增加，早期注入的约束逐渐被忽视。这一现象与大语言模型的注意力机制有关：在超长上下文中，距离当前生成位置较远的内容权重会自然下降，导致模型行为向其训练时的默认模式漂移，而非用户定义的规范。

潜力巨大却被琐碎问题拖累

作者的总结相当尖锐：Claude 的实用性以一种不幸的方式高度两极分化。代码越重要，Claude 对他越没用——而这与他对一个工具的期待完全相反。他把它形容为一个"显然拥有巨大潜力、却被无处不在的愚蠢小问题所拖累"的产品。

值得补充的是模型版本信息：作者使用的是 Opus 4.8，他还尝试过 Opus 5，但发现表现"更差"。

几点延伸思考

这篇吐槽的价值不在于否定 AI 编程工具，而在于精准定位了它当前的能力边界。对于原型验证、脚本工具、一次性数据处理等"结果导向"的任务，AI 编程助手的效率提升是真实且巨大的。但在对正确性、可维护性、团队共识有严苛要求的生产级代码库——尤其是医疗、金融、科学计算这类高风险领域——AI 工具目前更像是一个需要密切监督的初级实习生，而非可信赖的协作者。

一个更深层的问题是：当纠错和驾驭 AI 的成本，接近甚至超过了自己编写的成本时，这个工具的生产力价值就被稀释了。这也提醒团队在引入 AI 编程工具时，需要诚实评估自身代码库的质量门槛，而不是被宣传周期（hype cycle）裹挟着全盘接受。

当然，这只是单一开发者在特定领域、特定模型版本下的主观体验，不同技术栈、不同任务类型下的结论可能完全不同。但它提出的核心矛盾——工具的实用性与任务重要性成反比——确实值得整个行业认真对待。

生物信息学软件是AI编程工具「高风险场景」的典型代表，其特殊性体现在几个维度：首先，该领域有大量领域专有术语和命名约定（如基因组坐标的0-based vs 1-based系统、特定文件格式的字段语义），AI模型的训练数据覆盖密度远低于通用软件开发，导致其在领域术语和惯用法上更容易出错；其次，算法的静默错误（silent error）在生物信息学中尤为危险——一个吞掉异常、返回空结果的函数，在基因组分析流水线中可能产生看似合理但实际错误的生物学结论，而这类错误极难被下游发现；第三，可重现性是科学软件的核心要求，而AI生成代码在算法一致性上的随机性与这一要求天然冲突。这些特点共同解释了为什么该领域开发者对AI工具的容忍度远低于一般场景。