最近有点疲惫。
并不是因为遇到了多么困难的技术问题，而是一直被一堆需求推着走：交付、优化、继续交付。一个功能刚刚完成，新的想法又来了；一个问题才解决，后面已经排上了更多问题。
按理说，AI 提高了开发效率，人应该更轻松才对。可真实的感受却常常相反：代码写得越来越快，事情反而越来越多。
今天和朋友聊到 Vibe Coding，我突然意识到，这种疲惫可能并不只是工作节奏的问题。
AI 降低了代码的生产成本，却也改变了需求产生、产品开发和团队协作的方式。代码正在变得越来越便宜，但把一件事情真正做好，并没有因此变得便宜。
代码不再稀缺
过去，一个想法要变成产品，需要经过很多现实约束。
有没有开发资源？需要多少时间？值不值得排期？做完以后谁来维护？
这些问题会自然过滤掉一部分不成熟的需求。因为实现成本足够高，所以在真正动手以前，人们通常需要先想一想：这件事是不是非做不可？
AI Coding 大幅降低了这道门槛。
现在，一个模糊的想法可以很快变成页面，一段简单的描述可以直接生成代码。很多过去因为成本太高而被搁置的需求，也有机会迅速得到验证。
这当然是一件好事。
但门槛降低也带来了另一个结果：做出某个东西本身，正在变得越来越廉价。
当写代码不再困难，“能不能做”很快就不再是问题。真正的问题开始变成：
这件事为什么要做？
解决的究竟是什么问题？
做到什么程度就够了？
它和现有产品是什么关系？
未来是否值得长期维护？
AI 可以迅速回答“怎么做”，却很难替人回答“为什么做”和“是否应该做”。
代码不再稀缺以后，判断开始变得更加稀缺。
代码越便宜，需求反而越多
效率提升并不一定意味着工作减少。
很多时候，恰恰因为实现成本下降了，过去不会被提出的需求开始被提出，过去会被放弃的想法开始进入开发流程。
以前一个需求可能需要一周，大家会认真考虑它是否值得做。现在听说 AI 一两天就能完成，很多事情便会变成：
既然这么快，顺便也做一下吧。
每一个需求看起来都不大，每一次修改似乎也都不难。但大量“顺便做一下”叠加起来，仍然会占满所有时间。
AI 节省出来的效率，并没有自动变成空闲，而是迅速被更多需求填满。
甚至因为生成速度变快、试错成本变低，需求本身也开始膨胀。今天做一个版本，明天换一种交互，后天又增加几个分支。产品看起来一直在快速迭代，团队也始终很忙，却很少有人停下来判断：这些变化究竟让产品变得更好了，还是只是让它变得更多了？
当供给能力增长，需求也会随之增长。
AI 不只是提高了代码产量，也在制造更多对代码的需求。这或许正是效率提高以后，人反而更累的原因之一。
需求还没想清楚，AI 已经开始写了
AI Coding 还有一个很容易被忽略的陷阱：它开始得太快了。
需求可能只有一句话，边界还没有定义，目标用户也不清楚，AI 已经开始创建文件、设计数据结构、生成页面和补充逻辑。
屏幕上不断出现代码，会给人一种项目正在快速推进的感觉。
但代码在推进，不代表思考也在推进。
很多时候，我们并没有真正想明白需求，只是把一段模糊的表达交给 AI，让它用代码替我们完成了第一次猜测。
接下来发现不对，再增加一条要求；新的要求和原来的设计冲突，就再打一个补丁；补丁带来新的问题，再让 AI 继续修改。
于是，原本应该发生在编码之前的需求讨论，被推迟到了编码之后，以一次次修改代码的方式重新进行。
而一旦已经有了一个能够运行的版本，人便很容易围绕现有实现继续修补，而不是回到起点重新追问：
我们真正要解决的是什么问题？
现在这条路，是不是从一开始就走错了？
当然，探索阶段不需要等到所有事情都完全明确。AI 非常适合快速制作一次性的原型，帮助人验证想法。
真正危险的是，把用于探索需求的代码，顺手当成了正式产品的基础。
原型可以允许猜测，生产系统却要为这些猜测长期买单。
输入的质量，首先是思考的质量
人们经常把 AI 生成结果的差异归因于提示词。
但真正重要的“输入”，并不只是怎样写出一段漂亮的 Prompt，而是一个人是否已经理解了问题。
服务谁？
核心场景是什么？
哪些是必须完成的，哪些只是锦上添花？
系统的边界在哪里？
哪些情况允许失败？
怎样才算真正完成？
什么暂时不应该做？
如果这些问题没有答案，再精巧的提示词，也只是在更准确地描述一个尚未想清楚的需求。
高质量的 AI Coding，不是把一句模糊的话润色成一份长长的指令，然后交给模型全部实现。它更需要人在过程中不断判断、验证和收敛。
需求定义、架构设计、测试标准、代码审查、用户反馈，这些环节并不会因为 AI 会写代码而消失。
AI 降低了实现的成本，却没有降低做出正确判断的难度。
为什么 AI 总是急着开始
几乎所有 AI Coding 产品都倾向于尽快给出可见的结果。
相比反复追问需求，立即生成一个页面、跑起一个服务，更容易让使用者感受到“它真的在工作”。
从产品设计和商业化的角度看，这种倾向并不难理解。
更快地产生代码，意味着更强的即时反馈；更多轮修改，意味着更高的使用频率；一个看起来不断推进的任务，也更容易让人继续投入时间。
这未必是什么阴谋，而是一种自然形成的激励机制：模型被鼓励回答问题，工具被设计成推动任务，用户则期待尽快看见结果。
于是，很少有 AI 会主动停下来告诉你：
这个需求还没有想清楚。
这几个功能之间存在冲突。
也许不应该继续增加，而应该先删掉一部分东西。
现在最有价值的动作不是写代码，而是重新定义问题。
AI 很擅长响应，却未必擅长克制。只要继续给它要求，它通常就会继续向系统里增加东西。
AI 偏爱即时满足，长期价值需要延迟满足
AI 的工作方式天然偏向即时反馈。
给出一个需求，它马上生成代码；提出一个问题，它立即提供方案；哪里运行不通，它就继续修改，直到眼前的问题消失。
这种即时反馈很容易让人产生满足感。代码在增加，页面在变化，任务列表里的事项被逐个完成，我们能够清楚地看见“进展”。
但许多真正有长期价值的事情，恰恰无法提供这样的即时满足。
花时间把需求想清楚，短期内没有代码产出；重新设计一个数据模型，暂时不会增加任何功能；补齐测试、整理结构、删除重复逻辑，也很难像上线一个新页面那样让人兴奋。
它们甚至会在短期内让开发显得更慢。
可正是这些看起来没有立即产出的工作，决定了一个产品半年以后是可以继续从容迭代，还是已经被层层补丁拖住。
AI 更容易帮助我们获得眼前的结果，长期价值却经常要求我们放弃一部分眼前的速度。
它需要人主动停下来判断：
现在应该继续生成，还是先把问题想清楚？
应该满足眼前的需求，还是保护系统长期的边界？
应该再加一个补丁，还是接受暂时变慢，重新整理结构？
AI 可以提供选项、分析代价，甚至帮助执行重构，但怎样在即时满足和延迟满足之间取舍，仍然需要人来决定。
也许未来真正重要的能力，并不是让 AI 响应得更快，而是知道什么时候不应该让它立刻开始。
“能跑”离“做好”还很远
AI 最容易生成的，是能够解决眼前问题的代码。
这里增加一个判断，那里补充一个状态；这个页面单独处理一下，那个接口再增加一个兼容分支。每一次修改都可能是合理的，局部看甚至非常聪明。
可当这些局部合理不断累积，系统整体却可能越来越混乱。
同一种概念出现多种表达，状态分散在不同位置，已经失效的逻辑仍然被保留，新功能只能绕着旧结构继续生长。
最后，所有功能似乎都能运行，却没有人能够清楚解释整个系统为什么会变成现在这样。
这就是 AI 很容易制造的“补丁叠补丁”。
问题不一定是模型写不出好代码，而是它接收到的往往是连续、局部、不断变化的指令。它擅长完成眼前这一步，却不会天然为产品几个月甚至几年后的复杂度负责。
如果人也只盯着眼前的交付，那么 AI 越高效，技术债的积累速度也可能越快。
代码生成速度提高了，并不意味着软件工程中的结构、边界、一致性、可维护性和长期演进不再重要。
恰恰相反，代码越容易产生，越需要有人控制它的生长。
高水平程序员的价值没有消失
AI 能写出越来越多的代码，于是很容易让人觉得，程序员之间的能力差异也在缩小。
但被缩小的，更多是完成具体编码动作的差异。
熟悉某个框架的 API、写一段常见的业务逻辑、根据报错查找解决办法，这些能力正在迅速被 AI 普及。许多过去依赖经验积累的操作性知识，确实不再像以前那样稀缺。
可另外一些能力，反而变得更加重要：
把模糊需求变成清晰问题的能力，识别复杂度来源的能力，判断哪些代码不应该出现的能力，在局部功能和整体结构之间做取舍的能力，以及为长期结果负责的能力。
高水平程序员的价值，从来不只是比别人更快地写出代码。
他们往往能够提前看见一条路继续走下去会发生什么，知道什么时候应该抽象，什么时候不该抽象；什么时候继续修补，什么时候应该推倒重来；什么时候需要增加能力，什么时候更应该删掉设计。
AI 可以放大这种判断，也可以放大判断的缺失。
一个人如果思路清楚，AI 能帮助他更快地抵达结果。一个人如果没有想清楚，AI 也能帮助他更快地制造复杂度。
怎么用 AI 做减法
我们已经很熟悉怎样让 AI 增加功能，却还不太熟悉怎样让它做减法。
增加一个按钮很容易，判断这个按钮是否应该存在很难。
生成一个新的抽象很容易，发现原来的抽象已经多余很难。
为了兼容现有实现再加一层逻辑很容易，重新梳理数据模型、删除重复状态很难。
“再做一点”通常会带来立即可见的结果，而删除、合并和收敛的价值，往往要在很久以后才能体现。
所以，真正值得练习的也许不是怎样让 AI 写得更多，而是怎样借助 AI 让系统变得更少、更清楚、更健壮。
让它查找重复逻辑，识别不必要的抽象，梳理依赖关系，补足测试，再安全地删除旧代码；让它比较几个方案的长期成本，而不只是选择最快能够运行的那个；让它在开始编码以前先提出问题、明确边界，并列出这一次不做的事情。
但 AI 不会天然知道什么是多余的。
做减法的前提，是人先知道什么才是最重要的。
谁来负责长期价值
AI Coding 当然是一种巨大的效率提升，我也并不想回到一切都靠手工完成的时代。
只是我们可能需要重新理解“效率”。
如果写代码的速度提高了十倍，需求也增长了十倍，产品复杂度同时增长了十倍，那么最终得到的未必是更多自由，也可能只是更快的交付循环和更深的疲惫。
AI 降低的是代码的生产成本，并没有替我们完成需求判断、产品取舍和长期负责。
当所有人都能快速制造更多东西，真正稀缺的能力不再是“做出来”，而是知道什么值得做，什么不该做，以及做到哪里就应该停下来。
AI 擅长把一个想法立刻变成结果，长期价值却常常来自克制、等待和取舍。
它降低了行动的成本，却没有替我们回答什么时候应该行动，什么时候应该停下来。
在即时满足和延迟满足之间找到平衡，仍然是人的责任。
评论 · 加载中
正在加载评论……