技术思辨｜AI Coding：经验壁垒正在失效，工具进化重塑编程

高德技术

于 2025-06-09 18:00:25 发布

阅读量858

点赞数 9

文章标签：人工智能

本文链接：https://blog.csdn.net/amap_tech/article/details/148546645

版权

导读

AI飞速发展，AI Coding对传统研发模式带来了很大的冲击，本文作者总结了所观察到的5个变化趋势，以及对AI时代开发人员所需掌握的核心技能的思考，欢迎大家共同交流。

专业性的转移和升级

生成式AI确实在降低某些技术操作的门槛，例如自动生成基础代码片段，或辅助完成以往需要专门技能才能处理的配置任务。但这并不意味着专业性的完全消亡，更准确地说，是专业性的转移和升级。

过去，软件开发的专业性更多体现在"如何做"（how）的层面，比如熟练手写各种算法、精准实现复杂逻辑。未来，专业性的重心将更多地向"做什么"以及"为什么这么做"（what & why）迁移。这意味着，准确定义问题、清晰拆解复杂任务、以及具备批判性思维来评估AI生成结果的能力，将成为新的核心专业技能。IBM的研究也指出，尽管存在对AI可能削弱开发者基础编码技能的担忧，但更普遍的观点是AI在增强而非取代开发者，使其能够更专注于系统层面的优化和更具创造性的工作。

然而，过度依赖AI确实存在潜在风险，可能导致开发者在基础编程技能方面出现退化。因此，这种"去专业化"更应被理解为一次专业内涵的重塑。它对"专业人士"的要求实际上是更高了，需要你站在一个更高的维度去思考问题，并有效地驾驭AI这个强大的工具，而非仅仅被动地接受其输出。

效率来自高质量专注

▏氛围化，不用专注，边嘬着奶茶就把活儿干完了。
这种"爽"感，源于AI将开发者从大量重复、枯燥的"体力活"中解放出来。例如，AI可以快速生成样板代码、进行初步的代码格式化、甚至辅助编写单元测试的框架。这使得你可以将宝贵的精力更多地投入到更具创造性、更富挑战性的任务上，比如深入思考系统架构、解决核心的复杂逻辑、进行前瞻性的创新设计等。
GitHub的调查数据也显示，使用AI编码工具的开发者通常能体验到更高的工作幸福感和满足感，并且更容易进入"心流"状态。因此，这可能并非简单的"低专注化"，而更像是一种"高质量专注"——你可以将有限的专注力资源，更有效地分配到价值密度更高的环节。
当然，如果将AI单纯视为"摸鱼"的工具，期望边喝奶茶边让AI"一把梭"完成所有工作，那么效率的提升自然无从谈起，而且从长远来看，这对个人的职业成长也是不利的。关键在于如何正确利用AI带来的这种轻松感，将其转化为深度思考和持续创新的内在动力。

可复用性仍然是铁律

▏引入一个日历组件库 vs 直接生成一个最小满足业务需要的日历组件。

对"去组件化"的担忧，是因为AI的确具备快速生成看似能满足当前特定业务需求的"最小化组件"的能力。然而，软件开发的复杂性并不仅仅在于功能的即时实现，更在于其长期的可维护性、可扩展性和整体的稳定性。GitClear的研究指出，AI辅助编码可能会导致代码库中重复代码的比例上升，因为开发者可能不再像过去那样主动进行代码重构以实现复用，而是倾向于让AI针对每个相似的场景生成新的代码。这种做法会快速累积技术债，导致软件系统变得日益臃肿且难以维护。

▏可复用的铁律有所动摇，晃了晃之后又站稳了，复用还是必要的，架构设计也还是需要的，因为效率至上没有变。AI一把梭确实爽，4端x4倍的工作量和不一致性风险却一点都不爽。

"可复用的铁律"在AI时代不仅没有动摇，反而因为AI可能带来的潜在混乱而显得更加重要。一个经过良好设计的可复用组件，通常都经过了充分的测试和实际应用的验证，其可靠性和健壮性远高于临时生成的代码片段。相比之下，AI生成的代码虽然速度快，但其质量、可读性、可维护性乃至安全性都可能参差不齐，需要你投入额外的精力进行甄别和修正。

尤其是在多端（例如iOS、Android、鸿蒙、Web、小程序）场景下，如果每个端都依赖AI生成一套独立的所谓"最小化组件"，而缺乏统一的架构设计和复用策略，那么结果几乎必然是灾难性的。各端功能表现的不一致性、重复开发带来的资源浪费以及后期维护成本的急剧飙升，这些都会让最初"一把梭"的爽感荡然无存。

因此，架构设计在AI时代依然是软件开发的核心环节。架构师的职责不仅没有减轻，反而需要思考如何将AI的能力有效地融入到现有的组件化和复用体系中。例如，可以利用AI辅助生成符合既定架构规范和设计模式的组件代码，或者利用AI对现有的组件库进行智能化的改造、优化和文档生成。效率至上的原则没有变，而真正的效率来自于深思熟虑的架构和高质量的复用。

全栈开发者与领域专家

▏一岗多责，大前端工程师、全栈工程师、全干工程师。

当许多原先需要特定领域技能才能完成的编码、测试、甚至一些简单的设计任务，都可以由AI高效辅助完成时，个体工程师的能力边界似乎得到了极大的扩展。麦肯锡的报告也曾指出，AI将推动开发者向更全面的全栈能力发展，甚至催生出所谓的"AI栈开发者"，即能够熟练运用AI工具和平台进行软件开发的复合型人才。

这听起来前景广阔，但也对工程师的综合素质提出了前所未有的高要求。你不仅需要掌握更广泛的技术栈，还需要具备强大的快速学习能力、跨领域知识整合能力，以及与AI高效协作并对其输出结果进行准确判断和最终负责的能力。

然而，"一岗多责"也可能带来新的问题。人的精力是有限的，过于宽泛的职责范围可能导致"样样通，样样松"的局面，即在多个领域都有所涉猎，但都缺乏足够的深度。团队协作的模式也可能因此需要调整，或许会涌现出更加灵活、更加动态的技能组合方式，而不是简单地将所有职责都压在少数"全干工程师"身上。

更重要的是，深度的专业知识和长期积累的经验，在解决复杂、棘手和关键性问题时依然是不可或缺的。AI或许能够高效完成80%的通用性、重复性任务，但剩下的那20%决定系统成败、关乎核心创新的关键难题，仍然高度依赖于在特定领域深耕多年的专家。

左移，还是左移

测试左移：TDD与AI编程的天然契合

▏TDD是顺应AI编程的，原因是人类并不需要知道AI具体是怎么做的怎么想的，只要最终结果work well即可。

TDD（测试驱动开发）顺应AI编程的观点极具洞察力。在TDD模式下，开发者首先编写测试用例来定义期望的软件行为，然后编写代码使其通过测试。AI恰好可以基于这些明确的测试用例来辅助生成代码，这使得你可以将更多精力聚焦于准确定义"期望的行为"（即编写高质量的测试），而不是纠结于具体的实现细节。AI甚至还能辅助生成一部分测试用例，帮助识别一些开发者可能忽略的边界场景或异常情况，从而提升测试的覆盖率和质量。

然而，AI生成代码的"黑盒"特性也给测试带来了新的挑战。我们如何确保AI生成的代码内部逻辑是正确、安全、没有潜在偏见或后门的？如果过度依赖AI来生成测试用例，也可能导致测试用例本身的设计质量不高，或者未能覆盖到真正关键的业务逻辑。因此，即便在AI辅助编程的时代，人工对测试策略的深思熟虑、对AI生成代码的严格审查以及对核心业务逻辑的重点测试依然至关重要。

研发左移：从需求到代码的直接转化

prompt2code 和 prd2code 在形式上是一回事。
lowcode/nocode 是研发左移在特定场景的成功案例。
左移本质上是减少了中间环节，减少信息折损，提高效率。

"Prompt2code"和"prd2code"（从需求文档直接生成代码）确实是研发左移理念的体现。它们的核心目标是缩短从需求理解到代码实现的路径，最大限度地减少信息在传递和转化过程中的损耗与曲解，从而提高端到端的开发效率。Low-code/no-code平台在特定业务场景（如企业内部应用、简单网站搭建等）的成功，也印证了这种"左移"趋势的有效性和巨大潜力。AI的介入，理论上可以将自然语言描述的需求文档更直接、更快速地转化为可执行的应用程序。

但这同样带来了严峻的挑战。自然语言本身固有的模糊性、多义性和不完备性，是"prd2code"需要克服的巨大障碍。如何确保AI能够准确无误地理解复杂的、有时甚至是相互矛盾的业务需求，并生成完全符合预期的代码？这反过来对需求提出者（如产品经理、业务分析师）的能力提出了更高的要求——他们可能需要学习如何编写更清晰、更精确、更结构化，甚至更"AI友好"的需求文档。

此外，"左移"也意味着责任边界的重新划分。如果AI基于需求文档直接生成了有问题的代码，那么这个责任应该由谁来承担？是需求提出者，还是AI工具的提供者，抑或是最终审查代码的工程师？

DevOps的理念是将运维（Operations）的关注点和实践方法向开发（Development）阶段左移，实现开发和运维的紧密协作。类似地，由生成式AI引发的"研发左移"，可能意味着需求分析、系统设计、甚至一部分用户体验（UX）设计的工作，都需要更早地考虑AI的能力边界和集成方式，并让AI更早地介入到整个创造过程中，而不仅仅是作为编码阶段的助手。

那10%的核心技能是什么

长程规划的能力：人类能把超级大项目拆解成一系列环环相扣的细粒度任务，然后涌入N多个人类同事，几周到数月就能把项目做成。每一个人都是具备超强长程规划能力、学习/反思、泛化能力的Agent。
作出决策/解决问题的能力：基于多方面信息/分析推理，作出正确决策，并承担责任（AI不背这个锅）。
与人协作的能力：调动资源，处理人与人之间的问题。

Kent Beck曾说："The value of 90% of my skills just dropped to $0. The leverage for the remaining 10% went up 1000x. I need to recalibrate."（我90%技能的价值已经归零，剩余10%的杠杆作用却提升了1000倍，我需要重新校准。）

这段话精准地概括了AI时代技能价值的剧烈分化。他所说的"价值归零的90%技能"，很可能就是那些重复性的、有固定模式可循的、可以被AI高效替代的编码实现、基础调试、常规信息检索等任务。这些在过去是工程师赖以生存的"手艺活"，但在AI的强大能力面前，其稀缺性和独特性确实大大降低了。这并非说这些技能完全无用，而是它们不再是决定工程师核心价值的关键所在。

那么，那"杠杆提升了1000倍的10%技能"究竟是什么？这正是那些AI难以企及、人类独有的高级认知能力和软技能。拥有这些技能的人，能够有效地驾驭AI，将AI作为自身能力的延伸和放大器，从而创造出远超以往的巨大价值。具体而言，这些关键技能包括：

长程规划与复杂问题定义能力：AI可以帮助解决你明确提出的问题，但它不能替你发现和定义那些真正具有商业价值和社会意义的复杂问题。将模糊的业务愿景转化为清晰的技术战略和可执行的路线图，设计健壮且可扩展的复杂系统架构，进行长远的战略规划并预见潜在的风险与依赖——这些需要极强的抽象思维、系统思考能力和丰富的经验沉淀。你能够将一个超级庞大的项目拆解成AI可以理解和逐步执行的细粒度任务，并预见在整合这些AI"零件"时可能出现的挑战和协同问题，这正是"1000倍杠杆"的起点。
批判性思维、决策制定与责任承担能力：AI生成的内容，无论是代码、分析报告还是设计方案，都可能存在错误、偏见、疏漏或不符合特定场景的局限性。能够运用批判性思维去审视AI的输出，辨别其真伪优劣，结合多方面信息（包括那些AI无法提供的商业直觉、行业洞察、伦理考量和价值观判断）做出关键决策，并为这些决策的后果承担最终责任——这是人类智慧与担当的核心体现。AI不会为项目失败或错误决策"背锅"，但拥有这10%技能的人会，也正因为如此，他们的判断和决策才变得弥足珍贵。
深度洞察与创造性解决问题的能力：AI目前更擅长在已有的知识和数据模式中寻找最优解或进行模式匹配，但对于那些需要跳出固有框架、打破常规思维的颠覆性创新和原创性解决方案，它往往显得力不从心。能够洞察问题的本质，发现隐藏的关联，提出全新的思路，设计出AI都"想不到"的巧妙方案——这种源于人类灵感、直觉和想象力的创造力，是AI难以复制的。当AI能够帮助处理掉那90%的繁琐工作后，你将有更多的精力去进行这种深度的、富有创造性的思考和探索。
与人协作、沟通与领导力：软件开发本质上是高度依赖团队协作的社会性活动。有效地进行跨团队沟通、清晰表达复杂思想、协调各方资源、激励团队成员发挥潜能、处理复杂的人际关系和潜在冲突、建立和维护信任——这些与人打交道的能力，在AI时代不仅没有被削弱，反而因为项目的复杂性和对跨学科协作的要求提升而变得更加重要。你需要领导一个可能包含人类同事和AI"助手"在内的多元化团队，向着共同的目标前进，这种领导力和影响力是实现"1000倍杠杆"的重要组成部分。
持续学习、快速适应与"重新校准"的能力：正如Kent Beck所强调的，"I need to recalibrate." 技术在以惊人的速度发展，AI的能力边界在不断拓展。能够保持开放的心态，快速学习新知识、掌握新工具、适应新方法，并主动调整自身的技能结构和工作方式，这种元认知能力和终身学习的成长型心态，是保持并发展那关键10%核心竞争力的根本前提。

Kent Beck的感受非常真实地反映了AI正在迫使整个行业进行一次深刻的"价值重估"。那些能够准确识别、并全力投入去发展和运用这"10%"核心技能的人，将真正成为AI时代的引领者和价值创造者，他们的影响力将被AI这个强大的"杠杆"成百上千倍地放大。而如果仅仅停留在那些AI可以轻易取代的"90%"技能层面，那么职业发展的危机感将会非常真实和迫切。

“老师傅”的经验在AI时代也重要

AI在某些方面拉平了经验差距，尤其对于那些可以通过学习现有模式和信息检索来解决的问题。研究也表明，初级开发者通常能从AI编码助手中获得更大的即时生产力提升。新人可以借助AI快速上手，完成一些在过去需要一定经验积累才能胜任的任务，这无疑降低了入门门槛。

但这是否意味着"老师傅"积累的深厚经验就一文不值了呢？我认为并非如此。

首先，"老师傅"的经验并不仅仅是解决已知问题的能力，更重要的是他们应对未知、复杂和模糊问题的能力，以及在关键时刻基于直觉和经验做出的判断力。这些深层次的经验和智慧，很难被AI简单地学习和复制。AI或许能模仿"老师傅"解决过的特定问题，但当面对一个全新的、前所未有的挑战时，"老师傅"的经验往往能指引方向。

其次，AI工具本身也需要经验来驾驭。有经验的开发者通常能更有效地向AI提问（即编写更高质量的prompt），更准确地判断AI生成结果的优劣和潜在风险，并能对其进行更有效的修正、优化和整合。他们知道什么时候可以信任AI，什么时候需要质疑AI，什么时候需要人工介入进行深度调整。正如Addy Osmani指出的，AI编码工具往往对有经验的开发者更有利，因为他们能够不断地评估、纠正和改进AI的输出；而初级开发者如果缺乏批判性思维，可能会更容易盲目接受AI的结果，反而可能写出看似能工作但实际上很脆弱或存在隐患的代码。

再者，"老师傅"的价值在于他们通常对业务领域有更深刻的理解，对系统有更全面的认知，这些是AI仅通过代码学习难以完全掌握的。

所以，与其说是"乱拳打死老师傅"，不如说是AI正在迫使"老师傅"转变其核心价值的体现方式。他们需要从过去亲力亲为的执行者，更多地转向战略规划者、复杂系统设计者、关键决策者、质量把控者以及团队的知识传授者和引领者。而"初生牛犊"则需要警惕，不能因为有了AI这个强大的工具就忽视了基础能力的培养、批判性思维的锻炼以及对问题本质的深入理解，否则可能永远停留在"能够使用AI的初学者"阶段，难以应对未来更复杂、更具挑战性的工作。

总结