一、一个值得警惕的模式

2025年以来，一个反复出现的现象：在AI辅助编程工具快速普及的背景下，技术管理层的落地效果呈现出一种反直觉的分化——越是强调"战略导向"的领导者，其团队的AI转型越容易陷入形式化。工具采购了，培训完成了，KPI也设了，但研发效率和组织能力并未发生实质性变化。

这个现象本身并不令人意外。真正值得警惕的是背后的逻辑：问题不在于执行力不足，而在于一种结构性的认知陷阱正在悄然形成。

要理解这个陷阱，我们需要先厘清一个根本性的问题——AI工具究竟改变了什么？

二、从"接触"到"界面"：生产关系的范式重构

一个常见的误解是：AI工具让编程"更快了"。如果这个判断成立，那么AI不过是"更快的镰刀"——工具升级，但生产关系不变。管理者只需要调整节奏预期，无需改变认知框架。

但事实并非如此。

AI工具改变的不是速度，而是路径。更准确地说，它改变了人与生产资料之间的接触方式。

在传统研发范式中，工程师与代码之间是一种"直接接触"的关系——手指敲击键盘，每一行逻辑都经过人脑的实时处理。这种接触方式产生了一种特殊的知识形态：你知道代码为什么长这样，因为它是你一笔一划写出来的。你的判断力建立在"亲手做过"的基础上。

AI工具打破了这种直接接触。现在，生产流程变成了"意图→执行→验证"的三段式结构：人定义问题，AI生成方案，人审核修正。人与代码之间多了一层界面——这层界面不是物理的，而是认知的。你不再"写"代码，而是"审"代码；不再"设计"架构，而是"判断"AI生成的架构是否可行。

这种转变的深远之处在于：它分离了"意图"与"执行"，而传统管理模式假设二者是合一的。

三、判断力的来源：实践性知识的不可替代性

这里需要引入一个哲学上的区分：命题性知识与实践性知识。

命题性知识是可以说清楚的——"AI能生成代码"、"AI有时会产生幻觉"、"提示词质量影响输出效果"。这些命题可以通过培训、文章、报告传递给任何人。

实践性知识则完全不同。它是"知道如何做"而非"知道是什么"。它无法通过语言完整传递——就像游泳，你可以读完所有流体力学的教材，但下水后仍然会呛水。实践性知识的获取，必须通过亲身参与、反复试错、在具体情境中建立直觉。

传统的技术领导力建立在实践性知识之上。一个合格的CTO之所以能做技术决策，不是因为他读过架构设计的教科书，而是因为他亲手写过代码、调试过bug、经历过系统崩溃、处理过技术债务的累积。他的判断力来自"具身认知"——身体和心智在实践中共同积累的经验模式。

问题在于：当生产流程本身发生范式转移时，旧有的实践性知识会迅速贬值。

这不是说过去的编程经验毫无价值。工程本质没有变——目标仍然是交付可靠的系统，核心仍然是模块化、抽象和耦合控制。变的是生产流程的组织方式：从"人写代码→人审查→人测试→人部署"的线性流程，变成了"人定义问题→AI生成方案→人审核修正→AI辅助测试→人最终把关"的协作流程。

两者的差异，不亚于从手工收割到机械化收割的转变。

四、"亲手做"的本质：获得一种翻译能力

那么，技术领导者需要"亲手做"——这个"亲手做"究竟意味着什么？

它不是要成为团队里最好的AI程序员。它的本质是获得一种翻译能力：把AI工具的实践体验，翻译成组织可以理解和执行的策略、流程和文化。

这种翻译能力包含几个层面：

对AI能力边界的具身体认。 AI擅长什么、在什么地方会出错、什么样的提示词能获得高质量输出——这些判断无法通过阅读报告获得。你必须亲自体验"AI生成的代码在边界条件下频繁出错"的过程，才能建立起对"幻觉模式"的直觉识别能力。

对新生产流程的结构理解。 当同一个需求可能有多种完全不同的实现路径时——比如"AI生成完整方案"与"AI生成契约、人工填充逻辑"——你需要理解每种路径的隐性成本：代码可维护性、调试难度、团队学习曲线、长期技术债务。这种理解无法通过抽象讨论获得，必须通过亲手走完至少一个完整周期来建立。

对团队动态变化的感知。 当工程师从"代码的作者"变成"代码的审查者"，身份认同会发生根本性转变。团队需要新的能力模型、新的人才标准、新的协作方式。这些变化的冲击力，只有身处其中的管理者才能真切感知。

五、信息衰减：为什么"代劳"行不通

一个自然的推论是：如果CTO确实无法抽身，能否让技术骨干先探索，然后汇报结论？

答案是：可以作为补充，但不能替代。

原因在于信息衰减。技术骨干的实践报告，经过层层过滤到达决策层时，已经丢失了大部分体感信息。你能收到"AI有时会出错"这个命题，但收不到"在我们的特定技术栈和代码库上，AI的出错模式是这样的"这个实践性知识。

更深层的问题是：AI时代的技术决策，越来越多地涉及"人机协作"的微妙平衡。比如，当AI生成的代码覆盖率很高但可读性很差时，是要求团队重写还是接受？当AI建议的架构方案在理论上最优但团队无法维护时，如何取舍？这些判断没有标准答案，它们取决于你对团队能力、业务优先级和技术债务的"综合体感"——而这种体感，只能通过亲身实践获得。

六、门槛而非理想：3到6个月的实践窗口

如果"亲手做"是必要的，那么需要多久？

我的判断是：3到6个月。这是一个门槛，而非理想数字。

为什么是3个月？因为AI工具的使用存在一个被严重低估的学习曲线。第一个月，你会被AI的即时生产力震撼——简单的接口过去需要半天，现在10分钟生成。这个阶段最容易产生的误判是：把"AI能生成代码"等同于"AI能替代工程师"。

第二个月，问题开始暴露。AI生成的代码在边界条件下出错；看似正确的架构出现性能瓶颈；团队抱怨"AI写的代码看不懂、改不动"。你会经历一个认知崩塌：原来AI有明确的能力边界，而且这个边界和人类工程师的弱点完全不同。

第三个月，你开始建立"人机协作"的真实体感：什么问题适合AI、什么必须人工介入；如何设计提示词才能获得高质量输出；AI代码的审查重点和人类代码有何不同。

这些认知，没有任何文章、培训或演示能够替代。

而6个月的上限，则来自组织的承受力。在这个窗口内，你需要完成一个完整的项目周期——从需求定义到生产交付——并建立一套"AI原生研发"的内部评估框架。这个框架将成为团队后续工作的基准，也是你从"实践者"回归"管理者"的过渡桥梁。

七、领导力的重新定义

回到最初的问题：技术领导者在AI时代应该扮演什么角色？

不是旁观者，不是战略制定者，而是第一个走过新路径的人。

这不是对领导者的苛责，而是范式转移的结构性要求。当人与生产资料之间的接触方式发生根本变化时，管理者如果不能首先建立对新流程的实践性理解，就无法做出有效的战略判断。他的经验越丰富，盲区可能越大；他的权威越稳固，转型阻力可能越强——因为他会用"过去的成功"来论证"现在的正确"。

当镰刀变成拖拉机，农场主必须学会开拖拉机。不是因为他要成为最好的司机，而是因为如果他不会，他就无法判断该买多少台、该走哪条路、该用什么样的收割计划。

这种判断力，是任何外部顾问、任何培训课程、任何技术报告都无法提供的。它只能来自亲身实践——来自你在新工具面前的困惑、试错、顿悟，以及最终建立起来的那套属于你自己的认知框架。

3到6个月，是门槛，也是门票。