用 LLM 解决技术问题已经成了很多人的默认工作方式。问题来了，把上下文丢进去，方案出来，套上去能跑，结束。效率确实高，但有一种隐隐的不安：解决问题的过程——那个在传统学习路径里被认为最有价值的部分——被外包了。结果保留了，生成结果的认知劳动消失了，拿到的是一个空壳。
这种不安是有道理的，但它常被错误地归因为”LLM 让人变笨”。真正的问题不在工具，而在人和工具的认知分工。
最常见的失败模式是这样的：遇到问题，把上下文交给 LLM，拿到方案，套上去，关掉对话。在这个流程里，人是 context manager，LLM 是 problem solver，学习增量接近于零。但这不是 LLM 强加的工作方式，而是阻力最小的路径——它默认会发生，除非你刻意选择别的方式。
一种被推荐的替代方案是：先自己形成假设，再用 LLM 验证或反驳。听起来合理，但对新人不现实。它有个隐藏前提——你脑子里得有足够的先验知识，能生成一个非空的假设空间。对一个完全陌生的中间件、第一次见的报错、别人写的没看过的模块，你连”猜”的素材都没有。
更现实的路径是承认学习有阶段性。第 0 阶段是完全不懂，这时候直接让 LLM 给方案是合理的——你需要先看到”一个能工作的东西长什么样”，这是必要的 bootstrapping。第 1 阶段是关键转折点，也是最容易被跳过的：方案能跑了，但你不知道为什么。这时候不应该关掉对话，而是回过头去拆这个方案——为什么用 X 而不是 Y？这一行删掉会怎样？设计者当时在解决什么问题？这一步把”拿到的方案”变成”理解的方案”，时间成本可能比解决问题本身还大，但学习就发生在这里。第 2 阶段是积累了先验之后，下次遇到类似问题先自己想，再用 LLM 校验。
不是每个问题都值得走完三个阶段。判断标准大概是：未来三个月会反复遇到吗？是不是岗位的核心能力？能不能用一句话向别人解释清楚为什么这个方案成立？满足这些条件的问题才值得投入拆解成本，其余的拿来即用就好。
但拆解的时候又会遇到新困难——很多人发现自己根本不知道该问什么。这其实是两个问题：一种是知道自己不懂什么，但说不出来，本质是概念词汇量不够；另一种更隐蔽，是看一段代码每行都”懂了”，但完全没意识到每个设计选择背后都有可问的东西。
第一种的解法是降低提问标准。不追求”提一个好问题”，先追求”把困惑用大白话说出来”，哪怕暴露无知。LLM 不会嫌烦，追问能力比首次提问能力更重要。第二种需要刻意训练问题意识，几个可操作的角度：对每个”理所当然”的设计选择，问”为什么不是别的”；找两个相似的东西，问它们的本质区别；往边界上推，找方案的失效点；假装自己是设计者，问”如果让我做我会怎么选”。
一个最低成本的入门动作：每天选一个今天用过、看过、写过的东西，写出三个”为什么不是别的”问题。不需要回答，只需要列出来。坚持几周，扫描可问点会变成下意识动作。这就是 senior 工程师跟新人最大的视角差异——新人看到”代码”，senior 看到”一系列被做出的决定”。
回到最初那个不安。新的人机协作模式不必然让人空心化，但它的默认路径会。保持有效学习需要刻意的纪律，就像知道吃糖更轻松但还是选择吃饭一样。能识别出这个问题，已经是大部分人不会到达的觉察程度——剩下的，是在每一次”问完就关掉”的诱惑面前，多花一倍时间去拆解的那个动作。