现在是 2026 年 1 月 11 日，周日，凌晨。
昨天和 Hobo 一起吃了顿午饭，许久未见，见面就在饭桌上聊了许多，他非常关切我们的近况和工作。我们交流了很多。
很羡慕在外企工作的他可以无限量地使用 GPT, Claude Opus 等 LLM 来做工作辅助，提升效率。相比之下，我们在国内的工作环境中，使用这些工具还存在诸多限制和不便。
我们的共识是，目前编码工作中，LLM 写的代码是不能直接进生产环境的，非常非常不可靠。
可观测性
我问他，如果限制在一个模块中，并且通过了严格的单元测试，和基准测试，能否使用？他补充说，还需要非常好的可观测性，毕竟要考虑 long-run 的服务稳定性。 再者，一个庞大的系统，拆分成许多如此 well-defined 的小模块，本身的代价就是非常高的。
这确实是我之前遗漏的问题，在 这篇文章 中我提及过，通过了接口风格测试、单元测试和基准测试后，人才能够信任 LLM 生成的代码。 曾经我构造过一个基准测试，在考虑 CPU 和内存使用的情况下，光靠普通的基准测试，是无法发现 LLM 生成代码中的性能问题的。你必须提前上压力测试，才能发现问题。 压力测试实际上也无法真实模拟生产环境中的各种复杂场景，所以最终还是需要非常好的可观测性，才能在生产环境中使用 LLM 生成的代码。
但是可观测性应该如何设计和测试？
可观测性本身也是一种测试实际情况是否符合预期的工具，只是它的运行环境是在生产环境中，而不是在测试环境中。
再者，它可能需要侵入到实现代码中，才能收集到足够的信息。（侵入式埋点通常意味着更高的维护成本）
如果简单地在接口外部以及环境信息中收集一些指标数据，往往只能发现一部分问题。 例如无法观测到模块内部的状态是否正确，是否占用了过多的资源，是否有内存泄漏，是否有死锁等等。
而且，可观测性的指标往往和资源隔离有关，例如 CPU, 内存, IO 等等，如果没有非常好的资源隔离，往往很难发现问题。
以及，可观测性的关键在于报警系统。Hobo 曾经提到，“每一个埋点指标都暗示它应该有对应的报警规则，否则这个埋点就没有意义。”
通常实践上来说，报警规则是个运维工作，但埋点是开发工作。或许这种实践本身就有问题，我们为什么不考虑直接在代码中直接内嵌报警规则呢？
比如说，每个埋点都可以携带一个报警规则的定义，当指标超过某个阈值时，自动触发报警。这样一来，开发人员在编写代码时，就可以直接考虑到可观测性和报警规则，从而提高代码的质量和可靠性。
例如，埋点的同时，还可以设计一个断言机制，如果断言没有通过，就触发报警。这个好像很像 error / warning 机制，打个 error / warning 日志是否就意味着需要被关注？
倒是可以先从日志入手，重点记录 error / warning 日志，将这些日志作为可观测性的一部分，结合报警系统，来提升系统的可靠性。
我非常同意 Hobo 的观点：上生产环境的代码，必须要有非常好的可观测性，否则无法保证 long-run 的稳定性。
LLM 智能水平 vs 工程方法
另外，Hobo 还提到关于 LLM 自身的智能水平对编码质量的影响问题。此处我们有一些分歧。
他认为，LLM 的智能水平是决定编码质量的关键因素，智能水平不足，无法完成任务。 而我认为，LLM 的智能水平固然重要，但更关键的是如何设计好任务和测试流程，确保生成的代码符合预期。
Hobo 偏向于精英能力，是天赋主义的观点；而我是更倾向于系统优化，是建构主义的观点。
两者皆对，但阶段不同。
在模型能力临界点之下，我是绝对正确的。对于当前绝大多数商业应用，工程方法的价值远大于等待下一个“更智能”的模型。一个精心设计的提示链、完备的测试套件和迭代流程，完全能让一个能力中等的模型产出稳定、可用的代码。这是目前 AI 应用落地的主流和成功之道。
在面对真正的认知极限时，Hobo 的观点会显现。当任务复杂度达到需要真正理解、抽象和创新时（例如，设计一个全新的算法，或理解一个极其模糊、矛盾的需求），模型的“智能天花板”就会成为无法逾越的障碍。此时，再好的流程也无法让模型完成它“认知上做不到”的事情。
我代表的是 “工程师的务实” ，是当下让 AI 创造价值的核心驱动力。 Hobo 代表的是 “研究者的远见” ，关注的是未来能力的突破点。
最理想的状态是 “精英级的智能” 加上 “精英级的工程方法”。
用最好的流程，去激发和驾驭最强大的智能。我们的分歧不是对错之分，而是关注点（当下优化 vs 根本突破）和时间尺度（短期落地 vs 长期演进） 的不同。
在团队中，这种互补的视角非常宝贵。
