AI时代,最可怕的不是它不会做,而是它把一件不该做的事做得太好了

💡AI正在降低做事的门槛，却让判断什么值得做，变得更加重要。

把路修得更好之前，先确认它通向哪里。

最近看到几段关于 AI 编程的讨论，很有意思。

有人原本完全不懂代码，借助 AI，真的做出了可以使用的软件。可随着项目不断深入，他逐渐发现：最困难的不是让程序运行起来，而是弄清楚自己究竟想做什么。

也有人分享了一次深夜线上故障。

小程序即将上线，突然出现一个偶发的边界 Bug。AI 能快速生成修复代码，但面对项目历史遗留问题、兼容逻辑、线上负载，以及不同修复方案的风险，最终仍然需要有人作出判断。

还有开发者提到，客户提出的需求，往往只是客户自己设想的一种解决方案，而不是真正需要解决的问题。

这些讨论看似在聊不同的事情。

但它们指向了同一个问题：

当 AI 越来越擅长执行，人类真正的价值究竟在哪里？

我认为，答案不只是经验，不只是技术，更不只是所谓的创造力。

而是四个字：判断问题。

一、AI最值得警惕的，不是写错代码，而是把错误的方向做到了极致

过去，我们担心程序员写错代码。

现在，AI 可以在很短的时间内生成一套看起来相当完整的实现。你提出需求，它编写代码；你发现问题，它修改代码；你继续提出意见，它不断优化。

整个过程越来越顺畅。

但这里有一个容易被忽略的漏洞：

我们默认了一个前提——只要把事情做得更好，结果就会更好。

事实并非如此。

假设你想开发一个功能，AI 很快就给出了实现方案。

你觉得不错，于是让它继续完善。

它补充边界条件，优化代码结构，考虑异常情况，甚至把整个方案的优点和理由解释得头头是道。

你越来越确信，这个功能值得开发。

但有没有一种可能：

从一开始，这个功能就不应该存在？

也许用户真正需要的不是一个新功能，而是简化原有流程。

也许问题根本不在技术实现，而在业务规则本身。

也许你正在花费大量时间，解决一个通过调整产品设计就能彻底消除的问题。

AI 可以把一条路修得越来越平坦，却不一定意味着这条路通向正确的地方。

更值得警惕的是，AI 有时会表现出一种迎合倾向。

当你提出一个未经验证的想法，它可能先表示认同，再顺着你的思路不断补充和完善。

于是，一个原本只是猜测的方案，在反复论证中逐渐变得完整、合理，甚至令人信服。

但请记住：

论证得通，不代表前提正确；实现得好，不代表方向正确。

人类也会犯这样的错误。区别只在于，当一个人获得了一个能力极强的执行工具，却没有同步提高自己的判断能力时，错误就可能以更快的速度被放大。

过去，一个错误的想法可能因为实现成本太高而停留在脑子里。

现在，它可能在几小时内变成一个功能完整的软件。

这就是 AI 时代一个值得警惕的变化：错误想法的落地成本降低了，错误决策造成的损失却未必降低。

二、客户说「我要什么」，不等于他真的需要什么

这是我在实际开发中越来越深的一个体会。

客户提出的，往往不是问题本身，而是他认为可行的解决办法。

例如，客户说：

「我想加一个按钮。」

你问为什么，他说操作太麻烦。

如果直接开始设计按钮的位置、颜色和交互，你可能很快就能完成任务。

但如果继续追问，真正的问题可能是：用户每次操作都需要重复填写相同的信息。

那么，比增加一个按钮更好的方案，可能是自动填充。

甚至进一步梳理业务流程后，你会发现，其中某个步骤本来就没有必要存在。

最后，你不仅没有增加按钮，反而减少了整个操作流程。

这时，你完成的不是客户最初描述的任务，却可能更好地解决了客户真正的问题。

这就是「照做」和「解决问题」的区别。

我平时做的事情比较杂，既涉及全栈开发，也参与产品设计、运营和技术咨询。从需求分析、产品规划，到开发上线、实际运营，都有不同程度的参与。

这种经历让我越来越意识到：很多问题，单独从技术角度看，是找不到真正答案的。

举个例子。

最近遇到一个小程序登录问题。表面上看，只是本地缓存丢失之后，如何恢复登录状态。

如果只看技术实现，很容易开始讨论 Token、JWT、缓存恢复和身份校验。

这些技术方案本身没有问题。

但随着沟通深入，情况变得复杂起来：多个微信用户可能共用一个系统账号，一个微信身份也可能关联多个业务账号。

这时候，真正需要先回答的就不是「使用哪种 Token 方案」，而是：

• 微信身份与业务账号，究竟是什么关系？
• 多个用户共用账号时，系统应该如何识别？
• 一个身份关联多个业务账号时，应该如何确定当前操作主体？
• 哪些操作需要区分用户权限，哪些可以共享？

这些问题没有理清，技术方案做得越完善，后面越可能推倒重来。

因为你解决的只是表面上的登录问题，而真正需要确定的是业务规则与身份归属。

有时候，经验的价值不是更快地找到答案，而是更快地发现：我们一开始问错了问题。

这也是为什么，优秀的开发者不应该只是需求的执行者。

他们还应该是问题的发现者。

真正的解决方案，有时不是增加功能，而是移除不必要的复杂度。

三、真正拉开差距的，不是知道多少信息，而是知道什么信息重要

有人可能会说，这些问题并不难。

只要把项目文档、历史代码、业务规则和客户背景全部交给 AI，它不就可以判断了吗？

这确实能解决很大一部分问题。

AI 并不是天然无法理解业务，也不是永远无法获取项目背景。随着上下文、工具和执行能力不断完善，它能够处理的事情会越来越多。

但这里仍然存在一个更深层的问题。

知道所有信息，不等于知道应该优先考虑什么。

假设一个项目有三个目标：

第一，尽快上线。

第二，保证系统稳定。

第三，尽量减少未来的维护成本。

听起来都很重要。

但现实中，它们可能互相冲突。

如果今天必须上线，就可能没有时间彻底重构历史代码。

如果要彻底消除技术债务，就可能需要推迟交付。

如果要满足某个大客户的定制需求，又可能增加产品的复杂度，影响其他客户的使用体验。

此时，问题已经不是单纯的技术问题。

而是：在有限的时间、预算和人力下，究竟应该优先保障什么？

业务方可能关心交付时间。

客户可能关心功能是否满足需求。

开发团队可能关心系统的长期可维护性。

管理者可能更关心成本、收益与最终结果。

每一方都有自己的理由。

而现实不可能让所有目标同时达到最优。

你必须作出取舍。

这时候，真正有价值的经验，体现在能不能迅速识别关键矛盾，知道哪些问题可以妥协，哪些底线不能突破，以及接受某种代价是否值得。

技术人员不仅要知道怎么实现一个功能，还要知道这个功能的收益是否值得它带来的复杂度。

不仅要知道怎么修复一个 Bug，还要知道在当前环境下，哪种修复方案的整体风险更低。

不仅要知道如何满足客户，还要知道什么时候应该提出不同的方案。

专业能力，不只是知道怎么做，更是知道在什么条件下，应该选择什么。

当然，这并不意味着 AI 无法做这些判断。

只要目标、约束、风险偏好和背景信息足够明确，AI 同样可以帮助我们比较方案、评估风险，甚至作出相当优秀的建议。

真正困难的是：现实中的目标经常没有被明确表达，利益之间存在冲突，信息也并不完整。

而这些恰恰是日常工作最常见的状态。

四、为什么有经验的人，有时只需要几句话就能抓住问题？

这是我认为最值得深入思考的地方。

有时候，一个经验丰富的人只听几句话，就能意识到问题的关键。

而一个刚入行的人，即使拥有大量资料，也可能绕很久。

为什么？

因为经验并不只是记住了更多知识。

真正有价值的经验，是能够迅速识别问题的结构。

一个经历过多次线上事故的开发者，听到「偶发报错」「临近上线」「复现概率很低」，就会自然想到一些需要优先核查的方向：日志、环境差异、并发、历史兼容逻辑，以及修复方案可能带来的副作用。

他不一定已经知道答案。

但他知道先检查什么，哪些假设最值得验证，哪些修改现在不应该贸然进行。

一个有产品经验的人，听到客户要求增加功能，可能会先问用户为什么需要它。

一个熟悉运营的人，可能会进一步追问这个功能究竟影响哪项业务指标。

一个理解商业的人，则可能会继续判断：解决这个问题的成本，是否与它带来的价值相匹配。

不同领域的经验，让人能够从一个局部现象，迅速联想到背后的其他可能性。

这是一种经过长期实践形成的模式识别能力。

新手看到的是一个任务，高手看到的是这个任务背后的关系、约束和潜在后果。

当然，经验也有局限。

过去有效的方法，不一定适用于新的环境；熟悉的模式，也可能让人忽视新的可能性。

所以，经验真正的价值不是永远正确，而是能够更快形成有质量的假设，再通过事实验证它。

这也解释了为什么，知识储备丰富并不必然意味着解决问题更快。

知道很多，是一种能力。

知道眼前应该调用哪部分知识、优先验证什么，以及什么时候推翻自己的判断，是另一种能力。

五、真正的专业性，往往体现在知道什么时候不应该做

我越来越觉得，一个人的能力不能只看他能完成多少任务。

还要看他能避免多少没有必要的工作。

客户提出一个需求，你立刻完成，体现了执行能力。

客户提出一个需求，你发现了更简单的解决办法，体现了问题解决能力。

客户提出一个需求，你发现这个需求根本没有必要存在，并且能够解释清楚原因，帮助客户以更低的成本达成目标，这体现了更高层次的判断能力。

三者的价值并不相同。

在软件开发中，这种差别尤其明显。

有些功能可以实现，但不值得实现。

有些代码可以继续优化，但真正的问题在于架构设计。

有些技术债务应该尽快处理，有些则应该暂时接受，因为当前业务阶段并不值得为它付出高昂成本。

有些 Bug 必须立即修复，有些低风险问题则需要结合影响范围、复现概率和修复风险决定处理时机。

如果一个开发者只追求完成任务，他可能会不断增加功能、不断修改代码、不断扩大工作量。

但一个真正理解业务的人，会持续追问：

• 这件事究竟解决了什么问题？
• 它带来了多少价值？
• 有没有更简单的办法？
• 如果不做，会发生什么？
• 有没有必要现在做？

这些问题，有时候比写出一千行代码更有价值。

因为开发工作的最终目的，从来不是生产更多代码。

代码只是手段，解决问题才是目的。

而当 AI 已经能够快速生成大量代码时，这个区别会越来越明显。

六、AI时代，开发者真正需要升级的是什么？

我不认为开发者拥有某种永远无法被 AI 替代的能力。

AI 还在不断进步。

今天需要人类花费大量时间完成的工作，明天可能就会变成 AI 的常规能力。

今天需要依靠个人经验判断的事情，未来也可能被沉淀为系统规则、自动化测试、历史案例和决策模型。

因此，单纯强调「AI 不懂业务」「AI 没有经验」，并不能成为长期的护城河。

如果某种经验能够被记录、被解释、被验证，它就有可能逐渐转化为 AI 可以利用的能力。

真正值得思考的是：

当 AI 能力越来越强时，我们应该如何重新组织自己的专业能力？

我认为至少有三个方向。

1. 从执行需求，升级为定义问题

不要只满足于客户说了什么。

要理解客户为什么这样说，他遇到了什么困难，真正希望改变的结果是什么。

学会区分事实、假设、需求和解决方案。

在开始实现之前，先确认问题是否成立，目标是否清楚，成功标准是什么。

2. 从个人经验，升级为系统化判断

不要让关键经验只存在于少数人的脑子里。

把项目背景、历史决策、业务规则、常见陷阱和风险边界沉淀下来。

让 AI 不仅能够访问代码，还能够理解为什么代码会变成今天的样子。

让它知道哪些地方不能轻易修改，哪些业务规则不能破坏，哪些历史问题曾经造成过严重后果。

这样做的价值，不只是提高 AI 的工作效率。

更重要的是，让团队的专业能力不再完全依赖某个具体的人。

3. 从完成任务，升级为对结果负责

不要把代码成功生成、功能成功运行，当成工作的终点。

要继续验证：用户是否真正受益？业务目标是否达成？系统是否稳定？有没有引入新的风险？

在关键决策中，明确风险边界、验证条件、回滚机制和责任归属。

让工作流程从「生成结果」走向「验证结果」。

做出来只是起点，经得起验证、真正被使用，才是结果。

未来，优秀的开发者可能不再需要亲自完成所有技术细节。

但他仍然需要知道，哪些事情值得交给 AI，哪些结果必须验证，哪些风险不能接受，以及如何让整个系统持续产生价值。

这才是从一个单纯的代码执行者，走向真正的问题解决者。

七、最后，我想说一个更重要的观点

AI 时代，人与人之间的差距，未必会因为工具的普及而消失。

相反，它可能转移到新的地方。

过去，一个人不会编程，就很难独立做出软件。

现在，他可以借助 AI 实现自己的想法。

这是巨大的进步。

但当越来越多人都能把想法变成产品时，新的问题就会出现：

谁能发现真正值得解决的问题？

谁能判断一个方案是否合理？

谁能在有限资源下作出正确取舍？

谁能把技术、产品、运营和商业结合起来？

谁能通过现实结果，证明自己的判断是有效的？

这些问题不会因为代码生成变得容易，就自动消失。

当然，AI 也会不断进步。它会接触更多业务背景，学习更多历史案例，拥有更强的推理、执行和验证能力。

未来，人类与 AI 的分工一定还会变化。

但有一点不会因为技术进步而失去意义：

我们真正追求的，从来不是把事情做得更复杂，而是用更少的成本，更可靠地解决真正重要的问题。

一个优秀的开发者，不应该以写了多少代码证明自己的价值。

一个优秀的产品，也不应该以拥有多少功能证明自己的价值。

同样，一个优秀的 AI，也不应该只以完成了多少指令来衡量。

它们最终都应该回到同一个标准：

有没有解决真实的问题，有没有创造实际的价值。

所以，如果要用一句话总结我对 AI 时代开发者价值的理解，我会说：

💡当 AI 让「怎么做」越来越容易，真正拉开差距的，将是「为什么做」「该不该做」，以及「怎样才算真正做好」。

而一个人真正的专业性，可能恰恰体现在这里：

他不仅能把事情做成。

他还能在开始之前，就发现有些事情根本不必做。