你有没有那种时刻——需求方刚提完需求，你还没来得及评估，AI 已经把 demo 跑起来了。对方看完眼前一亮："太好了，就按这个来。"
【灯光渐暗，程序员低头看了一眼那坨 AI 生成的代码，表情像在看自己刚出生的孩子，而这个孩子已经负债累累】
最近 dev.to 上那篇 "You can build it. Should you?" 其实聊的就是这个事。非技术人员拿着 Lovable、Bolt、Replit 这些家伙，一个周末就能把应用造出来，"能不能构建"已经不是约束了——时间不是、预算不是、复杂程度也不是。这个判断我举双手双脚赞成。
但接下来才是重点：能不能的问题解决了，该不该的问题浮出水面了。
而"该不该"这件事，AI 不负责回答，因为它连自己刚编的参数都不负责。
以前"能不能"是一面很好的挡箭牌。需求方问"这个能做吗"，你沉吟三秒，说"能做，但时间上比较紧张"，大家体面收场。现在不行了，你说"能做"，对方就默认"那做吧"，再补一句"AI 不是很快吗"。
你从一个快乐的评估咨询师，变成了一个屎上雕花的雕刻家，而且雕完第一刀，作品就已经进了生产环境。
渡劫的内容换了，渡劫这件事本身没变。以前渡的是"怎么在预算内造出来"的劫，现在渡的是"造出来之后谁维护"的劫——周期还更长了，因为造得越快，埋下的雷越来不及标记。
【打住，这个展开有点大了，回到正题。】
还有同质化这事儿，帖子底下吵得挺热闹。观点是：大家都用相似的模型、相似的工具、相似的构建模块，写出来的东西自然长得越来越像，真正的差异化只剩"你选了哪个问题去解决"。
这话理论上是没错的，但我看到的是另一个更朴素的版本。
前阵子接手一个仓库，打开一看，commit message 工整得像在用 AI 写年终总结，代码结构和注释风格眼熟得像我上周刚删掉的那个 side project。我一度怀疑是不是自己记错了，翻了下 git log 的作者——确实不是自己。但这种熟悉感不是幻觉，是所有人都用同一个模型写代码的必然结果。
同质化先从代码开始，再从审美开始，最后从世界观开始。
现在看别人的 commit，已经分不清是"那个人写的"还是"那个模型写的"了。这大概就是 AI 时代的辨识度危机。
我承认社区里有人说得对，说 AI 时代最重要的工程技能是"决定不构建什么"，并且确保自己理解、能维护、并对所构建的东西负责。Richard J. 的原话大意是这样。这话对得不能再对了。
但对得有点超纲。
对在座的各位打工人来说，"决定不构建什么"的日常版本是：决定不接需求方那第七版改动，决定不重构那坨能跑但没人敢碰的模块，决定不再给那个 AI 生成的内部工具加新功能——因为每加一个功能，"试用期"就跟着无限续约。这个功能本来只是周五下午没事干随手造着玩的，现在成了全组离不开的系统，你就是那个亲手给自己挖了个 P0 坑的负责人。
有个评论说"AI 不会取代开发者，只是把大家从常规工作中解放出来"。这话我只同意前半句。解放出来的时间，全都花在了给"不该存在的东西"擦屁股上。
一个白天的我：太好了，AI 帮我省了三小时。
一个凌晨三点的我：这三小时，它帮我还回去了。🫠
后来我学聪明了，决定把"该不该"的判断也外包给 AI。我问它："这个功能我该不该做？"
它回了我一段格式工整、逻辑自洽、完全可以发表的文章。结构是"首先、其次、最后"的那种。读起来每个字都对，合上屏幕，什么也没记住。
我甚至怀疑它把这个问题当成了一道阅读理解题，而不是一个活人在凌晨三点发出的求救信号。
（友情提示：不要用"该不该"句式问 AI，它的回答准确率不算低，但它不会告诉你那个被它编出来、还写进文档里的参数名，是你自己翻源码找出来的。）
（郑重声明：以上吐槽不针对任何具体模型、工具、公司或参数——如有雷同，纯属 AI 行为高度趋同。）