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