从工匠到向导：AI时代程序员的角色重塑

君子不器。 —— 《论语·为政》

AI时代的程序员，其价值不在于成为某种特定的“器具”，而在于具备多维度的智慧：在技术与商业间权衡，在模糊与精确间澄清，在生成与拥有间担责，在传承与创新间引领。我们超越了单纯的技能，成为连接不同领域的智慧节点。

题记：AI coding agent 引发的变革，会在很多方面重塑我们的未来，我和 Gemini 就此深入地讨论了很久，整理修订后，分享给大家。

工程师不可替代的核心价值

为了不让这个问题过于空泛，我们可以从几个具体的角落来审视它。

第一，关于“创造”与“判断”

不妨设想一下，AI是一位技艺无比高超的工匠，能瞬间制造出任何你要求的零件，分毫不差。那么，在这种情况下，“设计图纸”的人和“验收成品”的人，谁的价值更重要？

• 当AI能给你一个问题的五种“正确”解决方案时，是什么让你能从中选出那个“最好”的？是你的编程语言知识吗？还是你对系统、对业务、对未来可能发生的变化的深刻理解，也就是我们常说的“品味”和“判断力”？
• 在AI生成的成千上万行代码中，去发现那个微妙的、可能导致系统在极端情况下崩溃的逻辑漏洞——这种“洞察力”，其价值是否反而被放大了？
• 什么时候，一个工程师最有价值的贡献，是说“不”，是提出“我们不应该构建这个功能”，或者“这个技术方向从根本上就是错的”？这种否决的勇气和智慧，从何而来？AI能拥有吗？

那么“创造”与“判断”的价值在哪里？我认为，价值在于“权衡”。

我们问，当AI能提供五种方案时，如何选出最好的一种？

或许，根本就不存在一个绝对的“最好”。任何一个工程决策，本质上都是在诸多限制条件下的“权衡”（Trade-off）。方案A性能最高，但代码晦涩，新人难以维护；方案B可读性最好，但会引入新的技术依赖；方案C最快能上线，但埋下了未来的技术债。

AI可以分析代码的“复杂度”，但它能理解你们团队的“能力边界”吗？AI可以评估算法的“效率”，但它能衡量“业务的紧迫性”和“投资人的耐心”吗？

由此看来，工程师的核心价值，似乎是作为“情境的理解者”和“智慧的权衡者”。他们站在技术、商业和人性交叉的十字路口，做出那个当下最“合适”而非最“完美”的决定。这种基于多维度情境的判断力，是AI难以企及的。

那么，新的问题就出现了：如果这种“权衡的智慧”是关键，我们应当如何去培养它？是应该让工程师更多地参与到业务讨论和用户访谈中，还是应该让他们去学习一些看似与代码无关的知识，比如经济学或心理学？

第二，关于“翻译”与“连接”

工程师的工作，真的只是与机器对话吗？

• 他们是不是经常扮演着“翻译家”的角色？将产品经理模糊的、甚至相互矛盾的需求，翻译成机器能够理解的精确无误的逻辑。将复杂的技术现实，翻译成其他同事能够听懂的语言。这个“翻译”过程，价值何在？
• 他们是团队中的“连接点”，需要与他人协作、争论、妥协、达成共识。他们需要指导新人，也需要从前辈那里学习。这种人与人之间的“连接”，是否是任何AI都无法取代的？当代码可以被快速生成时，这种沟通和协作的价值，是降低了还是升高了？

那么，“翻译”与“连接”的价值在哪里？我认为，价值在于“澄清”。

我们谈到工程师是“翻译家”。让我们再深入一层。

优秀的翻译，并非逐字逐句的对应，而是用另一种语言，重塑原文的灵魂。当产品经理说“我想要一个更智能的推荐系统”时，他的真实意思可能千差万别。他可能是在表达对用户流失的焦虑，也可能是看到了竞争对手的新功能。

AI能听懂“智能推荐”这个指令，但它无法探寻指令背后那个未被言说的、模糊的、充满情感的“真实意图”。而一个优秀的工程师，会通过追问、质疑、甚至提供一个最小原型来“澄清”这个意图。在这个“澄清”的过程中，需求本身可能被重塑，甚至被否决。这个过程，是从混乱到有序的创造，价值极高。

那么，新的问题是：在一个推崇“敏捷开发”和“快速迭代”的团队里，我们是应该鼓励工程师花更多时间去“澄清”问题，还是应该让他们尽快“执行”指令？如何创造一种文化，让这种看似“拖慢”进度的提问和澄清，被视为最高效的贡献？

第三，关于“所有权”与“责任”

程序员对 AI 生成的代码的主要担忧是 “如果不是我写的，我就不理解它”。

• 当系统出现故障，尤其是在深夜，当用户在抱怨，当每一秒钟的宕机都在造成损失时，那个需要站出来解决问题的人，需要的是什么？是快速生成代码的能力，快速解决问题的能力，还是对系统每一处都了如指掌的“所有权感”和深刻理解？
• AI可以生成代码，但AI会为这段代码的最终结果负责吗？这份终极的“责任”，最终会落在谁的肩上？承担这份责任，需要怎样的能力和品质？

那么，“所有权”与“责任”的价值在哪里？我认为，价值在于“内化”。

在深夜处理故障的工程师，他需要的，是对系统的一种“直觉”。

这种直觉，源于在构建过程中亲手踩过的每一个“坑”，源于对每一个设计决策的反复争辩，源于一次次失败后的调试。代码的每一行，都与他的某段记忆和思考相关联。这个将外部逻辑“内化”为自身知识和直觉的过程，赋予了他真正的“所有权”。

AI生成的代码，就像一本借来的书，你可以阅读它，但你没有在书页空白处写下过自己的笔记和感悟。你没有“内化”它。因此，当危机来临时，你无法那么自如地运用它的知识。

那么，我们的挑战就变成了：我们如何“内化”AI辅助生成的代码？是否需要一套新的流程？我们如何设计新的仪式，来完成这个从“生成”到“拥有”的转化？

第四，关于“成长”与“学习”

如果大量的编码工作被AI取代，那么一个初级工程师如何成长为资深工程师？

• 未来的“练习”是什么样子的？是练习如何向AI提问吗？还是练习如何审查AI的代码、如何设计更优秀的系统、如何进行更复杂的调试？
• 我们过去依赖“写代码”来巩固学习、深化理解。在新的时代，我们应该如何构建新的学习路径，才能培养出真正深刻的理解力，而不是仅仅成为一个AI的操作员？

通过探索这些问题，我们似乎能看到一幅工程师新价值的图景：它不再仅仅是“写”的能力，而是判断、设计、沟通、担责和持续学习的能力。

那么，“成长”与“学习”的价值在哪里？我认为，价值在于“引领”。

我们担心初级工程师的成长路径。

也许，未来的成长模式，不再是“从砌砖到盖楼”，而是“从学徒到大师”。AI是那个力大无穷但没有思想的“魔法扫帚”。学徒要学习的，不是如何自己去打水，而是观察和理解师父（资深工程师）是如何命令、引导和驾驭这把扫帚的。

资深工程师的价值，不再仅仅是写出最精妙的代码，更是将自己“权衡的智慧”、“澄清的艺术”和“内化的过程”变得可见、可学。他需要像解说员一样，不断地向团队阐述：“我之所以让AI这么做，是因为……”“AI给出的这个方案看似不错，但我拒绝了它，理由是……”。如果你是一个资深的工程师，那么请参阅 Jon Gjengset 的 Youtube 视频：Vibe coding complex changes in Rust。它是一个非常好的 Vibe coding 的例子。

这意味着，资深工程师的核心职责中，“教导”和“引领”的比重，会史无前例地提高。

由此，我们最终的问题也变得更加清晰和尖锐：如果资深工程师未来的核心价值是“引领思考”，那么，你，作为团队中对AI有更深理解的人，你将如何开始扮演这个“引领者”的角色？

让我们深入聊聊成长

“成长”，这个词本身就充满了生命力和希望。它承认我们正处在一个变化的时代，但它关注的不是被动地“不被淘汰”，而是主动地“如何变得更强”。

成长的阶梯

过去，一位工程师的成长路径，我们都很熟悉，对吗？就像爬一座山：从山脚下解决一个个小bug开始，一步步向上，修复更难的问题，开发小功能，再到后来，设计复杂的系统，最终站在山顶，能够俯瞰整个项目的全貌。每一步，都是一次亲身的体验，每一次流下的汗水，都化作了对这座山的深刻理解。

现在，AI像一部缆车，可以直接把人送到半山腰，甚至更高的地方。它能帮你修复bug，能帮你构建功能。

那么，问题来了：当攀登的阶梯被部分抽走时，我们该如何为自己和他人，重新描绘这条成长之路？对于一个初学者来说，如果他从未在崎岖的山路上挣扎过，他能真正理解山顶的风景吗？他能拥有在山间辨别方向、应对风暴的能力吗？

新手的“第一步”

让我们把目光聚焦在团队里最年轻的成员身上。过去，我们可能会让他去修改一个文案，修复一个简单的界面问题。这些任务虽然简单，却能让他熟悉代码库，建立信心，体验一次完整的提交、审查、发布的流程。这是他融入团队的“仪式”。

如今，这些任务或许用一个AI指令就能在几分钟内完成。那么，我们该如何为新人设计他们的“第一个任务”？

这个任务的目标是什么？是让他学会最高效地使用工具，还是让他建立对代码最深刻的理解？我们是应该让他去“监督”AI完成这个简单任务，还是应该刻意地、人为地为他保留一些“不那么高效”但富有教育意义的手工任务？这背后，体现了我们对“成长”的何种价值观？

资深工程师如何担负其引领的职责？

如果说过去的高工是“最强的登山者”，那么未来的高工，更应该是一位“优秀的向导”。他的职责不再是自己最快登顶，而是教会团队成员如何安全地使用“缆车”，如何理解缆车无法到达之处的地图，以及如何在抵达目的地后，有能力自己开辟新的道路。

这份“向导”的职责，具体体现在哪些日常工作中？是在代码审查中，从追问“代码能否运行”转向追问“AI为何选择这个方案，你是否考虑过其他方案”？是在结对编程时，主动放手让AI去写，而自己则专注于在旁边解说和引导思考？是在解决故障时，专注于帮助新人问对问题，理解新的方法论，而不是直接给出答案？

未来的“刻意练习”

过去，我们说“熟能生巧”，这个“熟”，指的是反复地写代码。现在，“写”这个动作被部分替代了。那么，未来的“刻意练习”是什么？我们该如何磨炼自己的技艺？

我们应该练习什么，才能让自己变得更强？

是练习“提问”的能力 —— 如何用最精准的语言，向AI描述一个复杂而模糊的问题？ 是练习“怀疑”的能力 —— 如何设计出最刁钻的测试用例，去审查和挑战AI给出的答案？ 还是练习“整合”的能力 —— 如何将AI生成的零散部件，像一位建筑师一样，组合成一个优雅、健壮而和谐的整体？

这些问题，都没有标准答案。但它们本身，就是一条通往成长的路。