Nova Kwok's Awesome Blog

随笔——AI 到底是在替你劳动,还是替你思考?

博文封面图拍摄于北京。设备:ILCE-7M3 + 28-200MM, 1/40 ISO5000

恍惚间距离上一次博客更新已经过去了大半年,而距离上一次写作其实已经快过去一年了(上篇博文「只有自律才能看到真正的自由——Durov Podcast 随笔」写就于 2025 年 11 月)。

本周末暂时关闭了 Tab, Agents 能力,做点古法写作/编程/思考的工作,尝试找回一点“100% 属于自己大脑输出”的乐子。

从 3 年前开始,每年我都会有个念想——今年一定要多花点时间在赛道练习上面。

但是每年都因为这样或者那样的原因而搁置。

这半年内由于有了大模型工具的发展,许多之前想做但是有阻碍的地方几乎都被扫去,其中就包括:

  1. 避震器应该如何选型,前后弹簧应该如何搭配才是正确的。通过 LLM 辅助和自己的联网搜索+资料整理,终于汇总了一篇避震器相关的记录并更新在了 https://fk7.nova.moe/mod/suspension/ ,也同样因此得到了一个自己满意的避震器搭配——BC DS ,定制前轴 6K 后轴 7K(不定制则默认 5K),且有了 -2° 前轮外倾角,同时还基本保持了原车高度。

  1. 避震器的后轴阻尼应该如何设定,通过手机陀螺仪+phyphox 记录后轴均速通过减速带的滚动/加速度数据,判断后轴阻尼是否会有欠阻尼或者过阻尼的情况,用重复测试的数据辅助判断当前 setting 是否存在明显振荡或收敛过慢

  1. 购买 M9N GPS + ESP32 组件 ,有 Cursor 配合的情况下,在几乎没有嵌入式开发经验的情况下完成了一个 DIY 25Hz GPS 能力,且通过 BLE 接入了 Racechrono ,获得了一个高刷新的 GPS,成本仅 200CNY(对比类似商业产品普遍在 800+CNY)

得益于以上的一些更新(还有些其余的小更新),今年终于有了更多的动力和契机在赛道试车,也成功在 2026/07 在上海天马赛车场完成了一次完整的 shakedown 测试,核心改件整体达到了预期,同时测试也暴露出了后刹制动力分配以及全油门换挡程序两个需要继续调整的问题,详细记录和车载视频见: https://fk7.nova.moe/track/logs/2026-07-shanghai-track/

希望今年剩余的时间可以再接再厉,努力提升人的水平,并多去一些不同的赛道对车辆进行测试。

回头看,上面这些事情其实都是我很喜欢的大模型使用方式:模型替我扫掉了很多资料搜索、代码实现和陌生领域入门的障碍,但问题应该怎么定义、结果是否可信、最终方案是否有效,仍然需要自己去测量和验证。

但过去这一年,我也越来越明显地感觉到,同样的工具还有另一种完全不同的使用方式——不仅把执行交给模型,也逐渐把问题定义、判断和验证一起交出去。

大模型

由于深知自己对于行业了解的不足,我很少在公开场合对于 AI 相关内容进行评论,但是最近越来越多的事情让我意识到——应该趁现在记录一下自己的想法,无论是为了方便未来对照,还是只是为了捡起自己长期不用的大脑组织语言和写作能力。

这快接近一年的时间内我们看到了大模型能力的飞速进步,在我(这个偶尔写点代码,但是也明确知道自己代码水平并不过关的“程序员”)视角中,从最初 GPT-3.5 Turbo 大规模普及,开源的 LLaMA 出现,然后人均一个 Web based 聊天工具(NextChat/LobeChat/xxChat),再到各类 RAG 知识库并堆积各类 Rerank 能力提升命中度(例如 Qanything),后续大家突然意识到参数量对于模型能力并非线性提升,而是遇到了边际递减,于是 Agent 工具,ReAct 循环,Harness,以及 Reasoning 能力开始被逐渐应用到主流。

社会似乎陷入了一个循环,更好的模型 -> 更少的员工 -> 更多钱给了模型相关公司 -> 更好的模型 -> 更少的员工…

从最近看到的显卡,内存,硬盘价格几乎都到了 ATH 的状态可以越发看到这个循环和泡沫的明显,且短期内好像看不到一个明显的拐点。

但相比这个宏观问题,我最近更在意的是另外一件事:作为使用者,我们自己正在发生什么变化?

我们看什么决定我们是什么

最近重读了一遍「娱乐致死」一书,书中的一个主要观点是——媒介会改变知识/信息传播的方式,而这个方式本身就会改变人的认知和理解知识的能力。

如果时间往两年前回想一下,当时短视频平台的推出,让许多只看电视的中老年人沉迷了手机上不断向上滑动的短视频,让许多小朋友也不断抱着手机翻看着各类短视频(只不过最近可能他们会看到更多 AI 生成的猫猫短片 etc.),我们可以有明显的担忧/顾虑——这么做会扼杀他们的专注力,深度思考能力以及思维深度,并最终成为一个浅薄的人。

或者至少我个人是这么想的,一来我知道这种奶头乐式的应用对于维护社会稳定,提供矛盾缓冲有切实的作用,二来我依然对于创造出这些产品的公司以及他们官网故意凸显的「社会责任」嗤之以鼻,同时很庆幸自己没有直接在这些公司工作过。

开发相关

但是很快,奶头乐来到了开发领域,以往我们要排查一个问题(例如为什么某个 K8s 节点连接不上网了,或者某个 140+ 表的数据库应该如何理清里面的关系制作出一个对应的 kanban 供上游使用)。

对于第一个问题,我们可能需要有大量的 K8s 知识,同时理解集群部署情况,通过一系列指令尝试排查是否可能是网络插件的问题,或者证书下发的问题,或者单纯是某些 Node 的 iptables 被搞坏了,拥有这些知识需要大量的实践并联想(才能整合出完整的排查思路链),在目前有了大模型之后,可能只要配置好 kubectl 命令给模型,直接交给它就能完成绝大部分排查工作并生成一个汇报。

对于第二个问题,模型的解决思路就更加简单了,连接串交给模型,完整的报告就出来了。

当然,上面仅限于 YOLO 或者权限被高度控制在只读时的玩法,对于任何有读写权限的工具而言,都不应该在生产环境交给模型直接操作,这不仅损害自己的专业性,也是对他人的设施不负责任。

这样,对于问题的解决/排查,思路很多时候就变成了:

  1. 2024 年前:我想到可以这么解决(想不到就放弃交给别人来处理了),应该需要确认 a,b,c,针对 a,b,c 搜了很多帖子,看了很多文档,本地手写了很多代码验证,和语法搏斗,解决了 a, b ,尝试推出 c ,d
  2. 2025 年:我想到可以这么解决,应该需要确认 a,b,c ,分别针对 a,b,c 对模型提问,得到反馈,测试 a,b,c ,得到结论后输出 d ,d 是问题的解决方式
  3. 2026 年:我想到大概可以这么解决,交给 Cursor/Codex 的 /plan,等 /plan 给我 a,b 和我没想到的 c,看上去不错,/build 也许得到了 d
  4. 20xx 年:我发现有这个问题,交给 xx 工具,/build, 也许得到了解决

好处是对于常见和覆盖常见路径的解决问题的速度变得越来越快,Human in the loop 的时间越来越少(当然,这个是模型能力变强的目标),大家对于事情解决的效率要求和预期变得越来越高,同样的工作可以交给更少的人来做,剩余的人可以完成更多的工作。

坏处也很明显:人对于跨领域的理解需求变得越来越少,每个人需要并行处理(可能多半是 review 模型的工作)的工作会越来越多,然后可能大家都越来越累了。

自动化偏误(Automation bias)

此外,对于坏处这里还可能会有一些自动化偏误的风险,即——不是模型变得足够聪明,而是人在某个时间点已经失去了判断模型究竟聪不聪明的能力。

Automation bias is the propensity for humans to favor suggestions from automated decision-making systems and to ignore contradictory information made without automation, even if it is correct.

https://en.wikipedia.org/wiki/Automation_bias

例如在上面对于 K8s 网络的排查中,你自己已经想到了 CoreDNS 正常,别的 Node 正常, 但是这个机器的 iptables 好像和别的机器不一样,但是还没仔细分析,这个时候,Codex 告诉你根因是 kubelet certificate expired,建议重新生成证书,然后给你一个很完整、很漂亮、有十几个步骤的操作方案。

我相信大部分人都会认为——模型已经做了这么多研究和探索了,那应该它是对的,然后就开始 /build 更新证书了。(即使你眼前已经有证据与它冲突。)

另外一种则更加隐蔽,例如针对上面数据库的例子中:Agent 做了数据库 Schema 的完整分析,结论是 “已经完整分析 143 张表,没有发现数据一致性风险,同时有 12 个问题需要关注“,但此时 Agent 其实漏掉了一个 legacy_payment_mapping 表。

欸!?这个时候如果是你自己在做(且有对于这个数据库深度的了解和认知)的话会想:Payment 数据在哪?有没有 legacy 表?我是不是漏搜了?

但在这里,现在你的思维变成:Agent 没说有,那大概是没有。

于是…

「“没有 evidence of X”」

悄悄变成了

「“evidence that there is no X”。」

这样一来,LLM 时代就有一个非常漂亮也非常危险的正反馈:

越多认知卸载 → 自己掌握的上下文越少 → 越难判断模型哪里有问题 → 越容易产生自动化偏误 → 越相信自动化 → 更愿意认知卸载。

那作为一个普通的开发人员,第一次尝到了 /plan + /build 的甜头后可能就会像第一次打开了抖音的大门,发现正反馈周期居然可以变得这么短,不再需要有仔细的思考和设计,不再需要仔细推敲细节的实现(因为大部分情况下模型在微观层面做的比你好,除非你用垃圾模型),慢慢也不需要仔细推敲功能的实现(毕竟能跑就没问题,有 bug 就让模型修就好,不是么?),慢慢的,项目层面也不用管了,只要写好 PRD,剩下交给模型猛蹬就行。

这样跟着上面展开一下就是:

flowchart TD
    A["⚡ 反馈越来越快<br/>`/build` 几分钟就给出结果"]
    B["📦 过程越来越容易外包<br/>不再亲自建模、搜索、实现"]
    C["🧠 自己拥有的内部模型越来越弱<br/>越来越不知道「正常结果」应该长什么样"]
    D["🤖 自动化偏误越来越强<br/>「它既然跑通了,应该就是对的」"]
    E["↗️ 更大胆地继续外包<br/>把更多判断与执行交给模型"]

    A --> B
    B --> C
    C --> D
    D --> E
    E -->|"进一步压缩反馈周期"| A

和短视频平台的「向上滑动」,「向上滑动」一样,大部分常规的功能只要/build/build,只要动动手(或者 Codex /build就好了。)

短视频的内容玩法也是类似,随便给你推一些看上去很震撼的结论和标题,5 分钟的拼接+后期视频里面可能有几句真话你就会习惯性转发到 xx 群里面,结果被质疑了之后为了维护自己的面子可能还会说出「你觉得有道理就看,没道理可以忽略」,「我们需要善于提取有益的信息,不考虑糟粕性的内容」之类没有任何逻辑的话。

这样来看,有了同样的:反馈压缩 -> 认知卸载 -> 自动化偏误的路径之后,我们就会发现如果把 AI 配置成只负责迅速消除认知摩擦的话,它会呈现出和无限滚动内容非常相似的行为激励——一代人有一代人的奶头乐。

当然,以上一些经验不适用于某些(甚至大型)传统企业,这些传统企业的文科管理层可能思维足够固化,AI 落地速度足够慢,内部还是以采购各类 xx 解决方案为主,给各类互联网或者长得像互联网的公司提供了套利空间——毕竟在 2026 年卖一个带 RAG 的聊天工具对于企业内可能都以为得到了香饽饽并为之支付超额代价,同时以为自己得到了信息化的提升和 AI 能力的落地。

从朋友那儿听来的真人真事,而且这个朋友还不是我自己 😓

当然这是题外话了

日常相关

如果说开发相关只是开发人员白天(或者晚上)的工作的话,那日常相关可能就和每个人息息相关了。

从 DeepSeek R1 刚刚出现的时候,配合 C 端 App 的上线,很快人们就发现——以往需要思考很久的问题可以直接外包给模型来做,只要判断一下模型有没有(很明显的)幻觉就行了。

到之后出现了豆包,元宝,千问的大规模普及,模型能力的逐渐提升,幻觉的逐渐被压制,我们逐渐将越来越多的大脑思考的部分给 offload 给了模型,并随着模型的幻觉越来越少,我们对模型的信任和依赖就越来越高,很快,从最无脑外包的角度就可以看到类似这样的一些例子:

来源: https://www.v2ex.com/t/1205029

帖子作者也表示:国内很多人根本就不知道 AI 的边界在哪里, AI 存在幻觉也不清楚, 连 AI 实际接入了哪些业务也不清楚, 甚至真的相信 AI 给出的建议和方案。

慢慢的,人们发现长时间的思考不如直接丢给模型思考,长时间的阅读不如丢给模型快点出来一个 TL;DR ,人和人之间的交流就变得越来越急躁/流于表面,对于事实的判断能力越来越差(反正不会了就问大模型就好了),我们又走上了短视频奶头乐的老路,只不过之前是别人创作好的垃圾给你看,现在是自己让模型生成的不确定是不是垃圾的东西给自己看(或者可能还转发给别人参考)。

在 2025 年微软研究团队调查了 319 名知识工作者、936 个实际 GenAI 使用案例,发现一个很有意思的关系:对 AI 越有信心的人,自报投入的批判性思考越少。 不过,论文同时发现,AI 并非简单消灭思考,而是把思考活动从“搜集信息、亲自解决问题”,转移到了“验证输出、整合答案、监督任务”。

相关研究: https://www.microsoft.com/en-us/research/publication/the-impact-of-generative-ai-on-critical-thinking-self-reported-reductions-in-cognitive-effort-and-confidence-effects-from-a-survey-of-knowledge-workers/

思考一下,当你想要研究一个不那么通用的话题比如——「对于目前既有的新风系统的工作方式而言,如果目标是在不开门窗的情况将室内二氧化碳浓度压制到 500PPM 以内是否现实」,你是直接把上面这段话打给模型,还是先思考一下这个话可以被分解成哪些问题,然后逐个搜索+考证(当然,这里可能依然会用到大模型),然后得出一个结论呢?

flowchart TD
    A["遇到一个陌生问题<br/>例:不开门窗,能否把室内 CO₂ 压到 500 ppm?"]

    A --> B{"怎么使用 AI?"}

    B --> C["直接把完整问题丢给模型"]
    C --> D["得到一个完整、流畅的结论"]
    D --> E["检查有没有明显幻觉"]
    E --> F["接受答案"]
    F --> G["问题解决了<br/>但自己没有建立多少内部模型"]

    B --> H["先自己拆解问题"]
    H --> I["室外 CO₂ / 人员产气量<br/>新风量 / 房间体积<br/>渗透率 / 传感器误差……"]
    I --> J["让 AI 辅助检索、计算和整理"]
    J --> K["阅读原始资料 / 实测 / 交叉验证"]
    K --> L["自己形成结论<br/>同时建立对问题的内部模型"]

当然,模型和短视频可能还不一样的点在于——它的用法是多样的,如果你能坚持保留着类似 2025 年的思路:

我想到可以这么解决,应该需要确认 a,b,c ,分别针对 a,b,c 对模型提问,得到反馈,测试 a,b,c ,得到结论后输出 d ,d 是问题的解决方式

那模型可以代劳很多其实不需要承担的体力工作(虽然依然会破坏一些你的搜索引擎等工具使用能力),而保持能力的提升(或者至少不衰退)。

但如果你就是打算躺了,或者工作上的事情让你不得不快速做出一些代码变更/修改/调试,那「丢给模型有什么不好呢?」,所有的文档都不觉得需要自己亲自打开,亲自阅读,甚至本博客的内容也打算丢给模型来看个总结版本,那模型或许在带着我们走向一个深渊。

写到这里,想引用一个 Twitter 推文和一篇文章:

文章是:「教育的下一步 | 螺莉莉的数据中心

推文则是如下:

https://x.com/S_Byzantine/status/2074832063556104490

或许可以给读者带来一些灵感或者想法。

AI 最大的诱惑之一,是它可以消除认知摩擦;但过去很多我们讨厌的摩擦,本身恰恰就是学习发生的地方。

不要停止思考。

以上。

#Chinese #Random Thoughts