AI 能替你干活，但不能替你成长
最近一段时间，我陆续记下了几句话：
不要把 AI 的输出能力，当成自己的能力。
深度思考，不是把一个问题想得更久。
遇到问题时，要复盘问题本身，而不是陷入自我否定。
今天做的事情，应该成为明天继续前进的基础。
它们看起来分别在谈 AI、思考、心态和长期主义。后来我发现，它们其实都在回答同一个问题：
当 AI 已经能替我完成越来越多工作，我到底怎样才算真的成长了？
这个问题没有看上去那么简单。
写这篇文章的时候是 2026 年秋天。对工程师来说，用 AI 写方案、做网页、整理调研、搭一个小工具，已经从新鲜事变成默认工作方式。正因为协作足够日常，产出与能力的错位，也更容易被忽略。
现在写一份方案、做一页网页、整理一篇调研，甚至完成一个小工具，都比以前容易得多。给 AI 一些 Context，再来回修改几轮，很快就能拿到一份像模像样的结果。
但有时候，结果虽然做出来了，我却未必真的变强了。
如果让我解释为什么采用这个方案，我可能说不清楚；让我判断里面最大的风险，我需要再问一遍 AI；换一个相邻的问题，我还是不知道从哪里开始。
这时我得到的是一次不错的产出，却不一定获得了可以带走的能力。
“做出来了”不等于“学会了”
过去，一个工程师想完成一项工作，通常要亲手查资料、读文档、写代码、调试和修改。这个过程很慢，却会迫使人不断接触现实反馈：编译器报错、测试失败、性能不达标、用户觉得不好用。
现在，中间大量执行工作都可以交给 AI。速度确实快了，但原来夹在执行过程里的思考和反馈，也可能一起被跳过去。
我把这种情况叫作“能力幻觉”：系统完成了任务，我却误以为是自己掌握了能力。
怎么判断一次 AI 协作有没有真正变成自己的成长？我现在会问自己三个问题：
- 我能不能解释，为什么最后选择了这个方案？
- 我能不能识别，结果中可能存在的错误、风险和取舍？
- 换一个相邻问题，我能不能复用这次获得的方法？
如果三个问题都答不上来，那么这次合作可能完成了任务，却没有完成学习。
这不意味着应该少用 AI，更不是说凡事必须重新手搓一遍。恰恰相反，AI 越强，我们越应该把可以外包的执行交出去。
但需要区分两件事：
思维过程可以外包，理解和责任不能外包。
AI 可以帮我推演、编码、搜索和评估，但系统为什么这样设计、边界在哪里、什么情况下会失败，以及我为什么愿意接受这个结果，最终仍然要由我掌握。
否则，我们只是从“亲手做但速度慢”，变成了“产出很多但无法判断”。
人的工作，正在向两端移动
宝玉整理腾讯学堂的一次分享时，提到一句我很认同的话：
验证题交给 Agent，判断题留给人。
我理解这里的“判断题”，主要集中在工作的两端。
第一端是定义问题。
这个问题值得解决吗？真正的用户是谁？我们要的是一个 Demo，还是一个能够长期运行的系统？哪些是硬约束，哪些只是过去形成的习惯？
如果问题一开始就定义错了，AI 只会更快地把错误方向做得更完整。
另一端是验收结果。
功能跑通就算完成，还是还要看性能、安全、成本和维护性？结果看起来合理，证据是否充分？哪些失败可以回滚，哪些错误会产生物理后果？
AI 可以执行检查，但“什么值得检查”“什么结果可以接受”，仍然需要人作出判断。
这也在改变工程师的角色。
代码实现的门槛下降以后，工程师不会因此变得不重要，但能力的重心会发生变化：从单纯的功能实现者，逐渐变成场景定义者、系统拆解者、结果验收者和方法沉淀者。
底层技术能力当然仍然重要。没有对系统的理解，就无法判断 AI 写出的代码是否可靠。只是我们不能再把“亲手写了多少代码”当成唯一的能力证明。
真正更难的问题变成了：
- 你能不能找到值得解决的问题？
- 能不能把它拆成 AI 可以执行、系统可以验证的结构？
- 能不能建立清楚的完成标准？
- 最后能不能为结果负责？
尤其是嵌入式、基础设施、安全和隐私相关的工作，人不逐行执行，不等于人不再负责。
低风险、可回滚的任务，可以更多依靠自动测试和黑盒验收；涉及硬件副作用、数据安全或不可逆操作时，就必须按风险建立证据链。减少人肉操作没有问题，减少可验证性就危险了。
深度思考，不是把问题想得更久
当定义问题和验收结果变得更重要，我们自然会谈到“深度思考”。
但很多所谓的深度思考，只是把一个问题反复想、补充更多细节，或者堆上更多模型和概念。过程很辛苦，最后却没有形成可以行动的判断。
我最近越来越觉得，深度思考不是让问题显得更复杂，而是穿过表面现象，找到关键变量、因果机制和可以验证的行动。
比如一个项目延期了。
最直接的解释可能是：“大家执行力不够。”
但这句话既不是事实，也没有办法指导行动。再往下追问，会出现完全不同的问题：
- 延期发生在需求、拆解、编码、验证还是协同？
- 为什么风险没有提前暴露？
- 是过程不可观测、责任不明确，还是反馈周期太长？
- 高能力成员是否也遭遇了相同的阻塞？
- 如果不换人，只改变系统，能不能避免下一次延期？
追问到这里，问题可能从“怎样提高大家的执行力”，变成了：
当前交付系统无法在编码前识别跨模块接口和验证风险，导致问题集中到联调阶段暴露。
两个问题会导向完全不同的行动。
前一个问题容易导向开会、督促和加班；后一个问题则可能导向接口契约检查、测试前置、责任边界和更短的反馈周期。
我现在尝试把深度思考压缩成六个动作：
- 事实：先写可以被验证的事实，不把评价当成事实。
- 问题：重新定义真正需要解决的问题。
- 结构：找出少数关键变量以及它们之间的关系。
- 假设：明确自己的判断依赖哪些条件。
- 反证：写出最强的反方解释，并设计最小实验。
- 决策：形成一个带条件、可以修正的行动。
最后最好能够写成一句话：
因为 A，在条件 B 下导致 C；因此先做 D，通过指标 E 验证；如果出现 F，就修改原来的判断。
这个表达不一定漂亮，但它很有用。它让观点不再是一句正确的口号，而是变成可以被现实检验的判断。
AI 可以参与这六个环节，帮助我们列出事实、发现遗漏、构造反方和设计实验。但最终选择相信哪条因果链、接受什么风险，仍然是人的工作。
把每个任务变成一轮训练
如果成长不能靠“完成了多少任务”来衡量，那应该怎样发生？
我目前给自己的答案是：不要只完成任务，要让每个任务都形成一轮反馈。
我把接收和完成任务的过程概括成四步：
价值 → 设计 → 交付 → 复制
先看价值。
接到任务，不要马上开始做。先问它真正要解决什么问题、创造什么价值、最后怎样才算完成。如果长期接收的都是低价值任务，就应该主动质疑问题边界，而不是把低价值工作做得越来越熟练。
再看设计。
如果原来的结构无法支撑核心目标，就不能一直在上面修修补补。当然，“推翻重来”也不是为了追求完美，而是在继续修补的累计成本已经高于重新设计时，敢于回到核心约束重新选择方案。
然后是交付。
不是做到“差不多”，也不是留下一个半拉子工程，而是做到真正可验收。只有结果进入真实环境，我们才能得到有效反馈。
最后是复制。
一次工作完成以后，留下了什么？是一份只能汇报一次的材料，还是一张 Checklist、一个模板、一项自动测试、一个 Skill，或者一个能被团队继续使用的工具？
把它和 AI 协作放在一起，大概是这样一个循环：
1 | 定义价值 |
我以前很喜欢一句话：“沿着目标，日拱一卒。”
现在我觉得，“日拱一卒”并不只是每天做一点。更重要的是，今天的成果要能成为明天的基础。
如果每天都很忙，每个项目结束后经验也跟着归零，那只是重复消耗；如果一次实践沉淀成标准，标准变成工具，工具又在下一轮得到反馈和更新，日积月累才会产生真正的复利。
反馈能不能发生，还取决于激励
个人可以建立自己的成长 Loop，但一旦进入团队，事情就没那么简单了。
一个团队嘴上说重视什么，并不重要。真正重要的是它在奖励什么、惩罚什么、考核什么。
如果组织口头鼓励创新，实际只奖励按时交付，大家自然会选择最安全的方案。
如果组织要求主动暴露问题，却总是在问题出现后追究“是谁的责任”，大家很快就会学会隐藏风险。
如果团队只奖励救火的人，却不奖励提前消除隐患、沉淀工具的人，那么火只会越来越多，救火英雄也会越来越忙。
所以我最近在思考带队伍时，越来越关注几件具体的事：
- 评价真实贡献，而不是表面上的忙碌；
- 允许成员重新定义问题，也允许带着证据提出反对意见；
- 复盘目标、行为和机制，不把一次失败变成对人的否定；
- 对真正创造价值的人，不只口头表扬，还要及时兑现认可和回报；
- 不只奖励个人解决了问题，也奖励他把经验变成了团队可以复用的能力。
这几件事看起来在讲管理，本质上仍然是在保护反馈循环。
人只有愿意暴露真实问题，反馈才会出现；反馈能够指向具体行为而不是人格，人才愿意继续尝试；贡献和回报能够匹配，正确行为才有可能长期持续。
这次工作有没有留下什么？
所以我现在会用一个很简单的问题检查自己：
这次我只是借 AI 把事情做完了，还是让下一次的自己变得更强了？
如果一项工作结束以后，我多了一个更清楚的判断、一条被验证的因果链、一份可以复用的 Checklist，或者一个能被团队继续使用的工具，那么这次工作才没有随着交付结束而归零。
如果只是得到了一份看起来不错的输出，却不知道它为什么成立、在哪里会失败、下一次怎样做得更好，那我拥有的仍然只是一次结果。
AI 可以替我走得更快。
但往哪里走、怎样算到达，以及每一轮结束后留下什么，还是得由我自己负责。
参考
- 宝玉：腾讯学堂《AI 原生思维——像训练大模型一样训练自己》：https://x.com/dotey/status/2094624092015992854