真正会用 AI 编程的人，都会做需求抽象
在AI编程这件事上，需求抽象是拉开普通开发者和高效开发者之间距离的核心能力。别小看这个词——它决定了你是停留在解决眼前一个具体问题的层面，还是能顺手把解决方案变成可以反复调用的通用能力。
拿一个具体案例来说。
去年10月，有个客户提出了一笔定制化需求，希望将视频文案自动改写成多种语言版本。功能做完了，客户很快又补了一条优化意见：
「现在生成的泰文我完全看不懂，能不能给我一个中文对照？」
站在纯定制的角度，这个需求改起来并不难。目标语言泰语，输出格式泰文加中文对照，提示词敲进去，事情就结束了。
但当时产品侧停了一下。
问自己一个问题：那如果下一个用户是英文呢？再下一个是日文、越南文呢？
是不是每来一种语言，就要重写一套逻辑？
这时候你会发现一件事，需求本身不复杂，复杂的是它未来的变化。
用户真正需要的，不是「泰文加对照」，而是一种能够帮助理解非母语文案的能力。问题出在「看不懂」三个字上，和具体哪种语言无关。
这个思维方式在AI编程这个领域里，特别值得反复琢磨。
说实话，这种敏感度不是天生的。
刚入行的前五年，纯粹做项目交付，追求的是快和效率。客户要什么就写什么。代码写得烂不烂？烂。现在回头看，很多功能简直不忍直视。
但那五年给了一样东西——面对各种完全陌生的行业需求，都有意愿、也有能力去理解，并把它变成软件。顺带说一句，原本是个极度I人，正是这五年和客户不断沟通的过程，把一个在陌生领域沉默寡言的人，磨成了在熟悉领域也能畅所欲言的状态。
后来误打误撞，转向了行业通用产品的方向。
此时面向的不再是一个项目，而是一群客户、一堆场景。
这个转变逼着养成了一种产品洁癖
等AI编码时代到来后，这种思维方式突然变成了一个巨大的杠杆。
做了一年多的AI产品开发，遇到过太多类似的场景。
有个客户说「帮我把会议纪要自动发到飞书群里」。最简单的做法是直接写死一个飞书webhook。
但停一秒想想：下一个客户可能要发到钉钉，再下一个要发到企业微信。
真正的需求不是「发到飞书」，是「会议结束后自动把结论推送到团队协作平台」。
再比如，有人让做一个「把PDF论文翻译成中文」的功能。做完了，下一个人说能不能翻成英文，再下一个说能不能只翻摘要。如果一开始把「中文」写死在代码里，后面每次都得改。
但如果一开始就把它抽象成
「目标语言」加「翻译范围」两个参数
坦率地讲，这种从个案中提炼通用性的能力，不是AI时代才有的。
1880年代电力开始在美国普及的时候，每个工厂主都在解决自己的「定制化问题」：我的纺织机要多大马力，我的车间要怎么布线。
但真正改变历史的，是那些看到了通用性的人。他们意识到，所有工厂需要的不是「一台适合我的发电机」，而是「一个标准化的电力网络」。
从定制到通用，从自建电站到公共电网，这个跃迁花了将近四十年。
软件工程里也有个经典的说法，叫DRY原则，Don't Repeat Yourself。
Andy Hunt和Da ve Thomas在《程序员修炼之道》里提出这个概念时，核心思想就是，
每一个知识片段在系统中应该只有一个单一的、明确的、权威的表示。
重复写三遍同样的逻辑，就意味着未来要改三个地方，漏一个就是bug。
但是。
必须是但是。
过度抽象这件事，同样是个陷阱。而且是个更隐蔽的陷阱。
软件工程里还有另一个原则叫YAGNI，You Ain't Gonna Need It。
极限编程的核心人物Ron Jeffries反复强调这一点，不要为你想象中的未来需求写代码。
觉得「以后肯定会有人要这个功能」，结果那个以后永远没来，代码库里多了一堆没人用的抽象层，维护成本反而上去了。
这个坑不少人踩过。
有一次做文档处理的功能，觉得未来肯定会支持各种格式，于是一上来就设计了一套插件化的架构，定义了一堆接口。
结果呢？半年过去了，只用到了Markdown和PDF两种格式。
那套精心设计的插件系统，变成了纯粹的认知负担。
而且说实在的，现在有AI辅助，通用化设计的成本比以前低太多了。
把需求描述丢给AI，让它分析
「这个需求真正想解决的核心问题是什么」「哪些设计是强绑定当前场景的」「未来可能受限的地方在哪」
连对应的交互设计草图都能一并给出来。
以前这种通用性的设计，靠自己去想，挺吃经验的。现在AI把这个门槛拉低了。
但门槛低了不代表判断力不重要了。
什么时候该通用化，什么时候该克制住抽象的冲动，这个分寸感，依然是人的活儿。
那五年烂代码教的事，AI替代不了。
但它教会了一个很重要的判断标准，可以分享出来：
定制化需求背后藏着通用化的机会，这是真的。但不是每个机会都值得现在就抓。
三次重复是信号，一次出现是噪音。
分清这两者，然后对信号下手，别犹豫。
