AI会替代程序员吗？发现问题和定义问题才是稀缺能力

在我看来，AI 时代，发现问题、定义问题的能力，对程序员而言正变得比单纯的实现能力更为重要。这并不是说编程不再重要，而是因为 AI 正在大幅降低实现的成本。当机器已经能够帮助我们快速完成过去需要花费大量时间才能完成的工作时，决定最终结果的，就不再只是我们能多快地把东西做出来，还包括我们是否弄清楚了究竟要做什么，以及怎样才算真正把事情做好。

在算力芯片基础设施软件栈的实际工程实践中，我越来越感受到一个问题的重要性：当 AI 已经能够参与需求分析、方案设计、代码实现乃至结果验证时，我们究竟应该依据什么来判断它做得对不对？

在一次 AI 应用的开发与验证实践中，就出现过这样一个颇有意思的现象。我们在需求中明确规定，应用不提供删除功能，也就是说，用户不应该在应用中找到删除任务的功能入口。然而，在对应用进行评估时，大模型却把这一项标记为 unsupported，相当于认为应用没有满足这项要求。

乍一看，这似乎没有什么问题：既然应用没有删除功能，那么说它不支持删除，难道不是正确的吗？但这里必须区分两件事：应用是否具备删除能力，以及应用是否满足"不提供删除功能"的要求。评估的目的是后者。既然需求明确要求不提供删除入口，那么没有这个入口，恰恰说明应用符合要求。如果把"应用不具备某项能力"直接等同于"应用没有满足某项要求"，就可能把正确的实现判成错误的结果。

我们都知道大模型会犯错，而这里暴露出来的，已经不只是模型能不能正确理解需求、识别功能的问题，更是我们究竟想判断什么，以及有没有把判断标准定义清楚的问题。我们可能花费大量精力让 AI 更准确地分析应用、生成代码、执行测试，却忽略了一个更基础的问题：如果连要解决什么问题、怎样才算解决了问题都没有弄清楚，那么 AI 越高效，我们就越有可能更快地得到一个看似完整、实际上却偏离目标的结果。

那么，AI 会替代程序员吗？我的回答是：有些程序员必然会被替代，而有些则会在新时代如鱼得水、风生水起。要深入解析这个问题，我们不妨先回过头来，看看人类使用工具的历史。

一、工具进步，为什么会改变人的价值？

远古时代，人们靠双脚走路。后来，人们学会骑马，再后来有了马车，如今我们可以开汽车。从一个地方到另一个地方，目标一直没有改变，完成目标所使用的工具却越来越先进。工具不断进步，人们付出的体力越来越少，完成目标的效率却越来越高。难道因此就意味着，人不重要了吗？

显然不是。即使驾驶同一辆赛车，也有人能够驾驭自如，有人却发挥不出赛车的性能。工具的性能固然重要，但驾驶者对赛道的理解、对时机的判断、对车辆状态的把握，以及面对突发情况时的决策，同样会影响最终的结果。随着工具不断进步，人的能力并没有失去价值，而是在以新的方式发挥作用。过去，人主要依靠双腿的力量完成旅程；今天，驾驶员不必靠体力奔跑，却需要理解和驾驭更复杂的机器。

软件工程正在经历类似的变化。过去，我们习惯于通过传统的编程方式完成软件开发，从需求分析、架构设计到编写代码、调试程序，每一步都需要工程师亲自投入大量精力。编程语言、算法、数据结构、软件架构和调试技巧等专业能力，是把想法变成可运行软件的重要基础。由于实现本身需要投入大量时间，能够独立解决复杂技术问题、在有限时间内完成可靠实现的工程师，自然更容易体现自己的价值。

如今，以 GPT 为代表的 AI 智能体已经能够参与甚至独立完成许多开发任务。它可以帮助我们分析需求、比较架构方案、编写代码、生成测试，甚至承担一个相对完整的开发工作。过去需要数天才能完成的任务，有时很快就能得到一个可运行的结果。这显然是一件好事：实现成本降低，我们就有机会尝试更多方案、验证更多想法，也能够把过去因为成本太高而搁置的事情做出来。

但需要注意的是，实现成本降低，并不意味着所有工程问题都随之变简单了。如果一个功能原本需要三天才能实现，现在只需要半小时，而这个功能确实解决了重要问题，我们当然获得了效率上的收益；但如果一开始就没有弄清楚究竟要解决什么问题，那么 AI 只是让我们更快地实现了一个可能没有价值的方案。更麻烦的是，实现越快，我们越容易继续为它增加功能、优化细节，甚至投入更多精力维护一个方向本身就不正确的系统。

这就像驾驶汽车。汽车可以显著提高我们的行进速度，却不会替我们决定应该去哪里。假如目的地没有选对，汽车开得越快，我们也可能越快地偏离真正的目标。AI 扩展了我们的实现能力，却不会自动提高我们所追求目标的质量。当实现逐渐不再是唯一的瓶颈，能否判断什么事情值得做、究竟应该解决什么问题，就会成为更加关键的能力。

二、发现问题，不等于接受需求

先看一个软件开发中十分常见的场景。用户提出需求，希望在系统中增加一个批量导出功能。工程师拿到需求之后，开始考虑导出格式、数据规模、接口设计、异常处理和测试方法。如果使用 AI，还可以让它快速分析方案、编写代码并生成测试用例。整个过程可能非常顺利，最终交付的功能也完全符合需求描述。

但是，用户提出的需求，就一定是值得直接实现的解决方案吗？

用户希望批量导出数据，可能是因为他需要把数据交给另一个系统处理，也可能是因为现有的业务流程存在重复录入，或者不同系统之间无法有效交换信息。批量导出只是用户根据自身经验提出的一种解决办法，并不一定就是问题的根源。如果真正的困难是系统之间无法直接交换数据，那么我们也许应该优先考虑数据互通，而不是先开发一个功能齐全的导出工具。当然，经过分析之后，我们仍然可能认为批量导出是最合适的方案，但这时我们知道自己为什么选择它，而不是把用户提出的功能直接当成问题本身。

这里涉及一个非常重要的区别：需求、问题和解决方案，并不是一回事。用户提出"我需要一个批量导出功能"，这是需求；批量导出是用户设想的一种解决方案；至于真正需要解决的困难是什么，还需要继续分析。用户往往最了解自己在工作中遇到了什么困难，却未必能够准确判断最佳解决方案。工程师掌握技术知识，也不意味着天然就比用户更了解业务。发现问题，需要把两方面的信息结合起来，从具体诉求出发，进一步识别背后的矛盾、原因和真实目标。

这项工作并不简单。我们看到的现象未必是问题的根源，一个流程效率低，可能是工具不好用，也可能是流程设计本身不合理，甚至可能是这个流程原本追求的目标已经发生了变化。同样，不是所有不方便的事情都值得解决。工程师还需要考虑问题的影响范围、解决成本、潜在收益，以及它与其他目标之间的关系。这要求我们不仅具备专业知识，还要理解实际场景，能够分析因果关系，并对自己的判断保持必要的审慎。

AI 可以协助完成这类工作。我们可以让它整理用户反馈、归纳问题、分析可能的原因，甚至主动寻找我们没有注意到的情况。但是，AI 提出一种解释，并不意味着这种解释已经被现实证实；它给出一份看似完整的需求分析，也不意味着真正的问题已经被发现。我们仍然需要通过事实、沟通和实际验证来判断：问题是否真实存在，我们对问题的理解是否准确，以及解决它究竟能够带来什么价值。

因此，我认为，发现问题不是开发任务开始之前可有可无的准备环节，而是工程师创造价值的重要组成部分。如果连要解决什么问题都没有弄清楚，那么后面的实现能力再强，也可能只是把事情做得更快，却没有把事情做对。

三、发现问题之后，还必须把问题定义清楚

发现了问题，并不意味着我们已经可以直接开始开发。我们还需要进一步定义问题，明确希望达成什么目标、当前的困难究竟在哪里、有哪些条件不能突破，以及依据什么标准判断问题已经得到解决。

例如，我们发现某项业务的数据交接效率很低，但"提高效率"本身并不是一个足够清楚的目标。究竟是数据准备耗时太长，还是传递过程中容易出错？是接收方需要反复整理数据，还是现有系统之间缺少必要的连接？如果不进一步分析，我们可能会把大量精力用在优化界面、增加自动化功能或者调整数据结构上，却没有触及真正影响效率的环节。即使这些工作都做得很好，也不意味着原来的问题就一定得到了解决。

问题定义的价值，就在于把笼统的现象转化成能够分析、能够行动、能够验证的目标。我们需要了解当前状态，明确期望达到的结果，识别成本、安全、兼容性等方面的约束，并确定什么证据能够证明问题已经得到解决。这不是为了把需求文档写得越来越长，而是为了让后续的决策有明确依据，让工程师和 AI 都知道自己正在追求什么结果，以及哪些方案不能接受。

回到开篇的案例。如果我们只把"应用有没有删除功能"当作判断依据，就容易把"没有删除能力"直接等同于"不符合要求"。但如果真正的目标是确认应用是否遵守不提供删除操作的约束，那么判断标准就应该关注应用是否出现了被禁止的操作，而不是简单检查某项功能是否存在。这两种判断看起来只差了一点，实际对应的却是不同的问题定义。假如评估标准没有把正向功能要求与负向约束区分清楚，我们就可能把正确的行为判断成错误，或者把真正的违规行为漏掉。

这在 AI 参与开发之后尤其重要。AI 很擅长根据已有信息生成完整答案，但如果问题定义模糊，它也可能在错误的假设之上，构建出逻辑严密、结构合理、实现完整的方案。我们可能花很少的时间就得到一份令人满意的技术实现，却没有认真检查最初的目标是否正确，或者验收标准是否覆盖了真正重要的场景。AI 可以帮助我们更快地解决已经定义的问题，却不能因为生成了一个完整答案，就证明问题定义本身是正确的。

因此，工程师需要迁移的能力，不只是从手工编码转向使用 AI 编码，更是从熟练完成给定任务，进一步转向能够主动澄清目标、发现隐藏假设、定义问题边界，并根据事实判断方案是否合理。这并不意味着每一次开发都必须经过一套繁琐的分析流程。问题简单时，我们完全可以迅速行动；问题复杂、影响重大或者存在明显不确定性时，就应当投入足够的精力把问题弄清楚。关键不是形式，而是行动的程度应当与问题的性质相匹配。

四、完成实现，不等于解决问题

问题发现和定义决定了我们应该朝哪个方向努力，但最终仍然需要通过工程实践来检验判断。这里还存在一个经常被混淆的区别：完成实现，并不等于解决问题。

假设 AI 生成的程序已经通过全部测试，我们是否就可以认定任务成功了？从实现的角度看，这可能意味着开发任务已经完成，但从问题解决的角度看，我们还需要确认这些测试覆盖了什么条件，以及真实使用场景中的困难是否确实消失了。测试通过，说明实现满足了既定测试条件；它并不能单独证明最初选择的问题就是正确的，更不能证明所有重要场景都已经得到满足。如果我们一开始就把问题定义错了，那么测试完全可能把一个错误的方向验证得很好。

这也是为什么，我并不认为 AI 时代就不再需要技术能力，或者工程师今后只要会做需求分析就够了。发现问题、定义问题、选择方案、实现和验证，本来就是一个相互联系的过程。我们有时需要通过实现来检验原来的理解，有时需要根据测试结果重新考虑设计，有时又会因为真实环境中出现的新情况，发现最初忽略了某个重要因素。技术能力依然重要，因为我们只有理解系统的运行机制、技术方案的适用边界和潜在风险，才能对 AI 提供的结果作出可靠判断。

AI 能够加快这个过程，让我们更快地尝试方案、更早地暴露问题，也能帮助我们承担大量具体的实现工作。但我们不能因此把"代码已经生成""测试已经通过"当成最终目的。工程活动的意义，终究在于通过技术手段解决实际问题，并以合理的证据确认结果。实现是手段，解决问题才是目的；完成任务是过程，创造真实价值才是最终标准。

五、程序员真正需要迁移的是什么能力？

说到这里，我们就可以重新回答标题提出的问题：AI 会替代程序员吗？与其简单地把人分成会被替代和不会被替代两类，不如认真思考自己的能力结构会如何变化。AI 确实会自动化某些任务，改变一些岗位的工作内容，也会让某些技能不再像过去那样稀缺。但与此同时，我们也获得了更强大的工具，可以用更低的成本完成更多工作，尝试更多方案，并解决过去无力解决的问题。

对于程序员而言，掌握新的 AI 工具当然重要，但仅仅熟悉某一种工具或提示词技巧并不足以构成长期优势，因为工具本身还会继续变化。更值得重视的是那些能够跨越工具和工作方式变化的能力：理解技术原理，识别真实问题，定义清晰目标，判断方案是否合理，并通过验证确认最终结果是否符合预期。其中，随着实现成本不断下降，发现问题和定义问题的能力，正成为程序员更需要刻意培养的核心能力。

这种能力迁移并不是抛弃原有的专业知识，更不是认为编程不再重要，而是让过去积累的知识发挥新的作用。一个真正理解软件架构的工程师，可以借助 AI 更快地实现和比较不同架构方案；一个懂得测试原理的工程师，可以利用 AI 生成更多测试，却仍然能够判断测试是否覆盖了关键风险；一个熟悉业务的工程师，可以让 AI 协助分析需求，但不会因为它给出了一套完整的功能设计，就放弃对业务目标的判断。过去的技术经验没有失去价值，而是从亲自完成每一步操作，逐渐延伸到指导工具、评估结果和保证工程质量。

那么，什么样的程序员更可能被替代？如果一个人的价值几乎完全建立在按照明确指令完成编码任务上，他的主要优势只是比别人写代码更快、完成的任务更多，甚至需要依靠代码行数来证明自己的产出，那么，当 AI 能够以更低的成本完成这些工作时，他原有的优势就很难继续维持。如果他又没有能力识别需求中的问题、判断技术方案是否合理，或者对最终结果作出独立验证，那么受到冲击的就不只是某项技能，而可能是他赖以创造价值的整个工作方式。

反过来，那些既理解技术，又能够从业务诉求中发现真正的问题、把目标和约束定义清楚，并利用 AI 快速探索方案、验证结果的程序员，就有机会把自己的专业能力放大。他们并不是因为不再写代码而更有价值，而是因为不再把全部价值寄托在亲自编写代码上。AI 承担越来越多具体实现工作后，他们可以把更多精力用于判断方向、解决复杂问题和确保最终结果符合要求。这并不意味着他们永远不会受到技术变化的影响，而是说，他们所掌握的能力更容易迁移到新的工作方式中。

同样的道理也适用于其他领域。管理者需要发现组织运行中的真实问题，而不仅仅是安排任务；产品人员需要理解用户的实际困难，而不仅仅是列出功能；研究人员需要判断哪些问题值得研究，而不仅仅是更快地完成实验。AI 可以协助他们完成越来越多的具体工作，但工具能够做什么，与我们应该让它做什么，仍然是两个不同的问题。

我一直认为，工程实践应该坚持问题驱动的行动，追求解决问题所必需的充分性。先弄清楚为什么要做，再选择足以实现目标的方案，而不是为了使用某种新技术去寻找适合它的问题（所谓"拿着锤子找钉子"），也不是因为 AI 能够快速生成一个功能，就认为这个功能值得开发。能用简单的办法解决，就没有必要把系统做得复杂；如果确实需要更复杂的方案，也应该能够说明它解决了什么问题，以及为什么值得付出额外的成本。AI 让我们更容易采取行动，也就更要求我们在行动之前做好判断，在行动之后认真验证结果。

结语

从步行到骑马，从马车到汽车，人类不断改进工具，不是为了证明旧的方式毫无价值，而是为了更有效地到达目的地。工具的进步改变了人们实现目标的方式，却没有让目标、方向和判断变得无关紧要。软件工程也一样：从手工编写程序，到借助 AI 智能体完成越来越多的开发工作，我们获得了更强大的实现能力，但这并不意味着只要能够生成代码，就一定能够创造价值。

AI 时代，程序员需要迁移的，不仅是使用新工具的能力，更是把专业知识、判断力和解决问题的方法运用到新工作方式中的能力。尤其重要的是，发现问题、定义问题的能力，正在变得比单纯的实现能力更为重要。因为工具能够帮助我们做得更快，却不能自动保证我们做的是正确的事情。一个人真正的价值，不只在于他能够完成多少任务，还在于他能否看清什么问题值得解决，能否把问题定义清楚，并最终证明自己所做的事情确实产生了价值。

在 云栈社区 的日常讨论中，类似的思考也在不断涌现：越来越多开发者意识到，当 AI 把编码门槛拉低之后，真正把人区分开来的，不再是敲代码的速度，而是判断"该不该做"和"做得对不对"的能力。面对 AI，我们既没有必要恐惧技术进步，也不能因为拥有更强大的工具就放松思考。我们需要掌握新工具，更需要重新认识自己的能力：哪些能力已经可以借助 AI 得到扩展，哪些能力需要继续深化，哪些能力必须在新的工作方式中重新培养。对于程序员而言，真正的分水岭或许就在这里：如果你只能按照给定的要求实现功能，那么 AI 越强大，你原有的优势就越容易被削弱；如果你还能发现值得解决的问题、定义正确的目标、驾驭技术并对最终结果负责，那么 AI 也可能成为放大你能力的工具。