AI写代码的速度,和定位线上问题的速度,不是同步提升的

今天早上，也就是2026年11月1日，因为公司过几天有新品活动，我就提前巡检了一下系统，结果发现新品所需要的物料（过几天会用到），在订货界面里没有出现。这意味着，今天下午，门店的店员就无法订到新物料。这是一个比较严重的问题。

由于订货模块我非常熟悉，所以一开始并没有立刻去看日志和代码，而是按照关键业务流程，判断了一下大概是哪个环节出了问题。但分析了一圈，发现每个步骤看起来都是对的，理论上应该能够正常订到新物料。

既然初步判断流程没有问题，我本来打算直接让AI分析一下。毕竟订货模块后面的代码，基本都是AI生成的，让AI分析自己的代码，应该也能很快找到原因。

但我后来没有这么做。原因是之前有过类似的经验：如果你给AI的问题粒度太粗，分析范围太大，它会给出很多可能的原因。你还需要花不少时间去看它的分析结果，逐一排查。

所以，我先去看了一下日志。结果发现，物料为什么没有出现在订货界面，这个原因在代码里是有单独记录日志的。我找到对应的日志后，直接把这段日志和相关代码交给AI分析。

这样一来，分析范围就非常小了。不出所料，AI大概一分钟就找到了原因，并给出了修复方案：只需要修复数据，不需要发版。

这次问题也让我更加意识到，在AI Coding时代，日志的重要性并没有降低，反而应该更加重视。

写好工程规则，让AI生成代码时记录好日志

现在，我们公司的很多代码都是由AI生成的。

因此，我在工程规则里专门配置了日志相关的要求：

• • 核心业务场景需要打印日志；
• • 异常场景需要打印日志；
• • 对于一些容易导致数据被跳过、过滤或者降级的场景，需要记录必要的原因。

另外，在做规格驱动开发时，如果我在分析业务需求的过程中，发现某些地方需要记录日志，也会直接写进Spec里。这样，AI在根据Spec生成代码时，就会把日志记录的要求一起考虑进去。

为什么要这么做？因为代码生成得快，不代表后续线上问题也能定位得快。当出现线上问题时，如果关键业务节点都有日志，至少可以快速缩小排查范围。但如果关键位置没有日志，即使AI能够分析代码，也只能根据代码逻辑推测可能发生了什么。

AI写代码的速度，和定位线上问题的速度，不是同步提升的。

还有一点需要注意：你给AI的问题范围越大、描述越模糊，它需要分析的内容就越多，定位问题自然也会更慢。

问题可能出在哪里，和问题到底出在哪里，是两回事

排查线上问题，可以分成两件事：

第一，分析可能的原因。

第二，确认到底是哪一个原因。

第一件事，AI现在已经能提供很大的帮助了。给它相关代码、调用链路和问题现象，它可以分析哪些地方可能导致这个问题，并给出排查思路。

但第二件事，需要结合生产环境的实际运行数据才能确认。因为AI不一定能直接拿到生产环境里的运行时信息。

例如：

• • 上游服务实际返回了什么？
• • 数据库里有没有对应的那条数据？
• • 配置中心读取到的值是不是预期的？
• • 某个业务分支今天到底有没有执行？
• • 为什么某条数据被过滤掉了？

这些信息，如果没有通过日志、监控或者其他手段记录下来，AI就无法凭空知道。于是，它只能根据现有信息，列出一份可能性清单。清单可能很完整，但里面的每一种可能性，都需要进一步验证。

因此，我们不妨直接把生产环境里的运行时信息提供给AI。日志就是其中一种非常重要的方式。

已经记录在日志里的信息，AI可以直接分析；没有记录下来的信息，AI再强，也只能根据代码和现象推测。

换句话说，AI排查线上问题的效率，很大程度上取决于我们能否给它提供足够的运行时信息。

哪些场景需要写日志？

结合日常开发和线上问题排查，我认为下面几类场景尤其值得关注。

第一，数据被丢弃的地方。

例如：

continue、filter、return null、返回空集合等。

这类代码有一个共同点：某些数据被过滤掉或者直接跳过了，但整个过程并不会抛出异常。最终表现出来的可能就是界面上少了一条数据，但开发人员在日志里什么也看不到。这种情况下，如果能够记录数据被过滤的原因，排查效率会高很多。

当然，不是每一个过滤操作都需要打印日志，尤其是高频过滤场景，要根据业务重要程度决定。

第二，降级的地方。

例如，主流程执行失败后，走了备用流程，或者直接返回一个兜底值。降级本身没有问题，有时候甚至是为了保证系统可用性而必须做的设计。

但事后我们需要知道：

• • 降级发生了多少次？
• • 是偶发情况，还是一直在发生？
• • 从什么时候开始发生的？
• • 降级的具体原因是什么？

如果这些信息没有记录下来，系统表面上可能一直运行正常，但实际上某些业务已经长期处于降级状态。

第三，前置条件不满足，导致业务被跳过的地方。

例如：

• • 功能开关没有打开；
• • 配置项缺失；
• • 不符合白名单条件；
• • 日期不在业务允许的范围内；
• • 当前门店不满足某个业务条件。

这些场景通常不会抛异常，而是直接跳过后续逻辑。但如果业务没有正常执行，我们就需要知道到底是哪个前置条件没有满足。否则，排查时只能把每一个条件重新确认一遍。

第四，查询结果为空的地方。

这个场景需要具体分析，并不是每次查询结果为空都要打印日志。例如，查询一个允许为空的列表，返回空集合是正常业务行为，就没必要每次都打印日志。

但如果是调用第三方系统，正常情况下应该返回数据，结果却返回了空数据，而自研系统又走了兜底逻辑，那么就应该记录日志。因为这可能意味着上游系统出现了问题，只不过被当前系统的兜底逻辑掩盖了。

第五，跨系统调用的地方。

尤其是调用第三方系统或者其他微服务时。例如，对方返回了异常、空数据或者不符合预期的结果，但当前系统通过catch异常、返回默认值等方式，把问题处理掉了。

这类场景比较隐蔽。因为调用方看到的可能是一个正常的返回结果，但实际上，中间已经发生了异常。所以，对于跨系统调用，需要关注请求参数、响应结果、调用耗时以及异常原因等信息。

上面这几类场景有一个比较明显的共同点：它们很多时候都不会抛出异常。

不抛异常的分支，恰恰容易被忽略。因为它们不会触发异常告警，也不一定会出现在错误监控里。但业务结果可能已经不符合预期了。

最后还要强调一点，日志并不是越多越好。如果让AI在所有地方无差别地打印日志，最终可能带来大量重复日志、存储成本增加，甚至影响系统性能。我们真正需要的是：在关键业务节点，把有助于判断问题的信息记录下来，尤其是业务为什么没有继续执行、为什么走了降级、为什么返回了非预期结果。

AI可以帮我们生成代码，也可以帮我们分析代码。

但要让它快速定位生产环境里的问题，我们还需要提前把系统运行时的重要信息记录下来。