当错误也能被完美论证，我们凭什么相信？

前言

今天在朋友圈看到了一篇 PostgreSQL 参数解析文章，读完以后，五味杂陈。原文如下：

文章讨论的是 PostgreSQL 18 中的 autovacuum_min_duration 参数，从核心原理、常见误区，一直讲到不同业务场景下的配置建议，头头是道，结构完整，语气笃定。按照文中的说法，系统会自动跳过执行耗时低于该阈值的 VACUUM 和 ANALYZE 操作，以此减少资源消耗，提高维护效率。

读到这里，我的第一反应是：我什么时候遗漏了这么重磅的特性？但转念一想，又觉得不太合乎常理。如果仅仅因为一次清理耗时较短，就认为它没有执行的必要，那么这些任务所承担的维护工作怎么办？阈值设得不合适，会不会让一些表长期得不到正常维护？

于是我去核对了官方文档。原来，社区版 PostgreSQL 18 并没有这个参数。真正存在的是 log_autovacuum_min_duration，用于控制自动清理和自动分析任务的日志记录阈值。而这篇文章，恰恰是围绕过滤短时清理任务展开的。后面的资源优化、分场景配置和生产建议，都建立在这个前提上。文章还提到，PG18 会根据碎片率、事务 ID 消耗情况综合判断这个时长阈值，自然也找不到相应的实现依据。

一个错误的前提，也可以长出一整套理论

我无法判断它是怎么写出来的，也不打算讨论作者。只是最近的所见所思让我感同身受：当答案不再稀缺，连错误都可以被解释和包装得如此完整，我们该如何保持清醒？

一个错误的前提，也可以长出一整套理论。

技术文章里出现错误，并不是什么新鲜事。以前没有 AI 的时候，写一篇文章需要反复核对源代码，辅以实验，不断核对和修正。参数记错了、版本混淆了，或者对某段机制理解得不够准确，都可能发生。

这次让我在意的，是一个不存在的参数，竟然被解释出了完整的工作机制和使用场景。

假如我们给 AI 一个要求：”写一篇 PostgreSQL 18 autovacuum_min_duration 参数深度解析，包含原理、常见误区、分场景优化和生产配置。” 如果模型没有先核验题目中的参数，而是直接顺着这个前提展开，就可能写出一篇看起来相当完整的文章，加上真实存在的 log_autovacuum_min_duration 又与它高度相似，毫秒单位、时长阈值、表级覆盖等真实特征，进一步加剧了 AI 的”信心”。

我之前就曾说过，强对话模型都有一个普遍能力：倾向于迎合你的问题、迎合你的观点，甚至迎合你的错误前提。这不是因为 AI 想讨好你，而是因为：它的目标是合理延续你的输入，而不是纠正你，所以 AI 可能会在你错误的前提下继续构建答案。

一旦接受”短任务会被过滤”这个前提，后面的内容就很容易顺着写：过滤短任务可以减少资源消耗，大表需要更多资源，不同业务应该设置不同阈值，阈值过高会清理不足，过低又会调度频繁。最后，再给出一组精确到毫秒的配置建议。

这些内容头头是道，但它们都依赖同一个错误前提，解释之间相互呼应。

再加上核心原理、常见误区、生产最佳实践这样的章节，以及结合大量生产故障复盘、适配 99% 的企业生产场景等表述，一篇文章就有了专业分析的外观。

我这个 PG 老油条第一次读完文章，都开始了自我怀疑，如果换成一个新手小白，其结果不言而喻。

今天能够看出问题，很大程度上是因为它落在了我熟悉的范围里。换一个领域，我也可能成为那个被完整解释说服的人。

当专业的外观变得容易获得

过去，一篇文章结构严密、细节充分，我们会认为作者做过大量研究；一套软件功能完整、运行流畅，我们会倾向于认为开发者理解了问题。这些判断并非毫无道理。过去完成这样的工作通常需要投入相当多的时间和经验，成果的完整程度，多少能够反映背后的积累。

AI 让这层关系变得不那么可靠了。一个人可以借助它完成自己尚未充分理解的论证，也可以做出超出自身经验范围的软件。成果已经摆在眼前，但支撑它的理解，未必同步建立起来。

我们需要重新审视那些曾经用来判断”专业”的线索。完整的表达、丰富的功能和流畅的演示，仍然有价值，却越来越不足以单独支撑信任。

这并不意味着，只有自己从头写出的内容、亲手敲出的代码才值得相信。那只是在维护一种旧的门槛。我更在意的是：当表达和实现都可以借助工具完成时，我们能否说明，这个结论为什么成立，这个设计为什么必要，以及在什么条件下它会失效。

这些问题，才会暴露一个人对事情的真实理解。

更需要祛魅的，也包括我们自己

之前白鳝老师在《当 codex 成为最懂我的，我有些恐慌》文章中提到，AI 可以让一个想法迅速拥有理论、架构、代码、测试和文档，而过去协作中的质疑、分歧和实现困难，本来也在承担纠错的作用。

我十分认同这个警示。尤其值得警惕的，是我们可能把工具带来的完成度，算成了自己的理解力。

一个想法得到充分论证，会让人更有信心；一个方案被实现出来，会让人更难承认它最初可能就没有必要。投入越多，越容易继续寻找支持它的理由。

AI 恰好能够很快提供这些理由。

因此，祛魅也需要朝向自己：我现在比以前更能解释、能写、能做了，但我是否也更清楚事情为什么成立？还是只是更容易把自己的直觉，包装成一套像样的论证？

让 AI 赞同自己，或者让它反驳自己，都可以成为思考的材料。但如果我最后只是从几套说法中挑出最顺耳的一套，判断依然没有真正发生。

有自己的想法，需要能够说明自己为什么接受它，也知道什么证据出现时，自己应该放弃它。如果一个观点无论遇到什么反例，都能继续让 AI 找到解释来维护，那么这场对话越深入，我可能反而离事实越远。

能做出来以后，什么还值得做

这种变化，在软件和产品上同样明显，群里铺天盖地的软文，今天一个插件，明天一个巡检，后天又是一套平台。主页漂亮，功能齐全，演示丝滑，似乎每一个都是下一轮革命。

我并不反感这种繁荣。更多人能够把自己的经验变成工具，本身就意味着更多可能性。但当开发成本下降时，一个产品能够被做出来，也就更不能说明它有多大的必要性。

以前，实现上的困难会迫使人先做取舍：这个需求真的存在吗，值得投入这么多时间吗？现在，一个念头很快就能变成产品，我们可能还没有想清楚它的价值，就已经开始为它补充功能、寻找用户。

以数据库巡检为例，采集指标、生成报告、列出几十条建议，都可以做得很完整。但报告里哪些问题值得处理，哪些只是当前环境下的正常现象，哪些建议落实以后反而会增加风险，才决定了这次巡检有没有帮助。

如果使用者仍然要重新核对每一条判断，那么一份更长、更漂亮的报告，未必减少了他的工作。

功能的数量不能替我们回答价值的问题，开发的速度也不能替我们决定方向

对于使用者，这意味着不必因为一个工具已经出现，就急着替它在自己的工作中寻找位置。对于开发者，也意味着需要接受一种可能：有些想法即使很容易实现，也没有继续做下去的必要。

我认为，能够作出这种取舍，和能够把东西做出来，同样重要。

判断力要有自己的来处。

说到这里，很容易得出一个结论：以后只需要保留判断，把其他事情交给 AI 就好了。但这个说法里还有一个问题 —— 判断力从哪里来？这才是重中之重。如果不理解数据库机制，就很难发现那篇参数文章的异常；如果不了解业务，就很难判断一个功能是否有用；如果没有接触过失败，就容易低估方案中的边界条件。

判断需要知识和经验支撑。过去查资料、做实验、处理故障的过程，既在完成工作，也在形成判断。AI 可以帮助我们缩短这个过程，但如果我们只保留拿到结果的那一步，久而久之，自己用来判断结果的依据又从哪里补充？

这也是我觉得真正需要思考的地方：我们希望 AI 接过越来越多的工作，却不能默认，自己会自然保有评判这些工作的能力。

我愿意把大量查找、整理和实现工作交给 AI，也希望借助它接触自己原来做不到的事情。但对那些决定方向和结果的关键问题，我需要参与到推理、验证和修正之中。否则，看似一直由我作出最后决定，实际上我可能已经只能在它提供的选项里挑选。

总结

保留最终确认的权力，并不等于保留了独立判断的能力。

回到开头那篇文章。让我停下来核对的，是它与我对数据库维护机制的理解发生了冲突。当时我既不能凭经验直接否定，也不能因为文章写得完整就接受，只能带着这个疑问去找依据。

我希望自己能保留的，就是这种能力：面对一个解释，能够追问它的前提；面对一个产品，能够判断它的必要性；面对自己的确信，也愿意给反例留下位置。

AI 可以帮我把一个想法推演得很远。至于为什么从这里出发，要到哪里去，以及发现走错以后是否愿意回头，这些仍然需要我自己想清楚。