这两年，做产品、写代码、做设计的人，应该都感受过 AI Coding 带来的那种兴奋。
以前搭个页面，要去官方社区翻阅文档、配环境、找组件，折腾一两天都很正常。想起我快毕业出来面试的时候，还遇到过一家挺神奇的公司，在不能上网的环境下，给了各种框架的jar包，要求从0在Eclipse里面搓出一个系统的关键业务，搭建项目，整合各种框架，从前端到后端，完整链路都得跑起来。最后我当然没做完，只能把大致思路讲了一遍。结果被他们技术总监当场痛批了一顿…现在想想，好像这些事情AI都可以完全承包了。
现在把想法丢给 AI，几分钟就能生成一个能跑的版本。可能细节还粗糙，但界面也已经像模像样了。比如我让ChatGPT生成一个移动端的点餐页面：
AI只思考了6秒钟就开始干活，生成结果如下：
怎样，是不是像模像样的。
刚开始，这种速度确实让人上头。好像做 App 不再是什么高门槛的事情，谁都能很快把想法变成一个可以上架的App。
但当你体验多了这种类型的产品之后会发现，产品迭代是变快了，但是很多产品也越来越雷同了。
为此，我在思考一个问题：当所有人都能快速生成一个看起来不错的东西之后，真正稀缺的到底是什么？
我的答案是：判断力、品味和对结果负责的能力。
低质量创作一直都存在
现在很多 AI 产品长得像，确实不冤。比如 SaaS 官网，常见套路就是大号渐变标题、几张功能介绍卡片，再配一个“立即体验”的圆角按钮；AI 工具图标也很容易做成紫蓝渐变、玻璃质感。看多了就会腻，甚至一眼就能猜到是 AI 生成的。
但这不全是 AI 的锅。
AI 之前，就已经流行低代码平台，或者模板站了，像WordPress之类的，我以前也用来搭建过博客，核心功能都是一套，只不过换换主题。这种模板站有模板味，低代码有低代码味，组件库用多了也有组件库味。真正的问题出现在哪里呢？其实是很多人没想清楚要做什么，也分不清哪里好、哪里不对，就急着把想法交给工具。
AI 只是把产品的粗糙感抹平了。它能让东西看起来完整、标准、专业。可当你没有自己的判断力，没有自己的品味，做出来的产品，点进去会发现没有重点，让人过目就忘。
要是一眼就看出哪里烂的东西还好改，麻烦的是看着还行的东西。它容易混过去，最后变成一堆完成度不错、但没人记得住的产品。
当谁都能做出原型，竞争力在哪？
以前做产品，会涉及很多流程节点，比如页面、后端、部署、登录、支付，哪一步都有可能卡主。能把想法变成能跑的软件，还是有一定的门槛的。
现在有了 AI，这道门槛被压低了。你说做个记账 App，它能很快搭出页面；说做个知识库产品，大概率也不在话下。当你拿到生成的结果粗看一下，真像那么回事。
所以，能把想法做出来越来越不稀奇了。那么你的竞争力在哪里呢？你为什么要做这款软件？解决谁的问题？用户为什么不用现成工具？第一次打开时，哪些体验必须做好？
这些想不清楚，AI 只能把一个模糊想法翻译成一个模糊产品。最早回归做出来的产品页面能打开，功能点的动，但用户看完大概率只会觉得又是一个平平无奇的东西。
原型和产品之间，差的不不仅仅是几页界面，更是需求判断、体验打磨、工程质量，以及让用户愿意相信你的理由。
别把时间都花在追工具上
AI 工具更新非常快，新模型、Agent、各种AI编码工具、开源项目…刷多了也许你很容易会觉得，不用最新的就落后了。
于是很多人忙着比较模型、收藏 Prompt、试插件，但是最核心的项目却没往前走多少。
工具当然很重要，但它更像放大器。你想得清楚，它能帮你更快落地；但是如果你的想法本来就是一团乱，它也只是把混乱包装得更像样。
所以，真正值得练的能力，是把问题说清楚：我要解决什么？什么结果算做好？哪里可以妥协，哪里不能随意？
当我们把这些想明白了，不管换什么工具结果都不会太差。想不明白，再强的模型也只是更快生成一个“看起来像答案”的东西。
不知道你听过这句话没：在AI时代，只要你学的足够慢，你就可以不用学。
也许你学的慢点，还有些东西没来的学就已经过时了呢。这么看来，是不是有节省了很多时间呢？
品味不是玄学
有些人不愿意谈“品味”这个东西，怕太抽象了。但做过产品就知道，品味不是玄学，当你看多了、做多了、踩坑多了之后，慢慢会形成的判断标准。
比如一个设置页，不是把所有开关都平铺摆出来。可以把常用项放前面，危险操作藏的深一点，顺便在旁边补一句清楚解释，这些细节背后，是对用户行为的理解。
AI 可以生成方案，也能把界面做完整。但哪个方案更符合你的场景，哪个细节会影响信任，还是需要人判断。
当同类产品越来越多时，用户看的不只是功能，而是你有没有理解他的场景，有没有在容易出错的地方给了一个周全的方案。
这些东西，很难靠一句 Prompt 直接生成。
AI 时代别只追求快
当聊起 AI 提效，很多人第一个想到的是加快进度。
追求快没错。就好比MVP 不该憋一年，重复劳动也该交给工具。但是我们需要警惕，别为了追求快，把该想清楚的东西也省掉了，比如需求没理顺，边界没确认，异常状态也不管了，文案没想清楚就上。
这么做看起来更快更敏捷，但是最终会导致把粗糙的产品提前交给了用户，最终会直接用户的影响信任。
AI 省下来的时间，不该全拿去堆功能。我们同样应该关注下把核心流程多走几遍，把错误状态补上，把危险路径再仔细评估下，看看是否还有优化空间。
有时候慢点，并不代表低效，而是在把产品从“能跑”往“可信”推进一步。
AI 越强，开发者越不能把判断让出去
这一点也是我最想强调的，因为在工作中看到太多过于信任AI的案例了，最终导致快速低质量的交互，这将是另一场灾难。
当我们用 AI 写代码时，很容易有种错觉：代码不是我一行行敲的，出了问题好像也不完全是我的问题。
但上线后，AI不会站出来替你担责了。你用codex写的代码出了线上问题，OpenAI不会替你背锅的。它只有在你反问道：“这个已上线的xxx实现机制是不是有问题？是不是应xxx更合理？”的时候，给你回答一句：“你说的没错，你的思路是对的…” 当初AI在实现的时候可不是这么说的，可能还跟你打过包票，说它当时的实现方式是最牛逼的。
如果接口挂了、数据错了、用户点不进去这些常见问题，最后还是开发者去查（或借助AI去排查）。AI 可以帮你写代码，但不能替你承担责任。
又比如 AI 补了一段缓存逻辑，看起来完整，测试也过了。可老数据能不能兼容？权限有没有被绕开？缓存失效会不会打爆数据库？线上出问题日志能不能定位？这些都得人来判断。
AI 知道通用写法，却未必知道你们系统里的历史包袱。
代码一旦进了仓库，Commit了上去，就不再只是 AI 的产物。你批准它，它就是你的责任。
使用AI编码看起来快了，风险也可能被一起推到后面的流程里面。
别把自己变成工具链里最可替换的一环
现在是2026年，AI还在快速进化，还会变得更强。页面、代码、图片、文案都会生成得更快更准确，Vibe Coding 也会更普遍。我想，这也不是坏事，它让更多人能动手，也让想法验证更快。
但是需要警惕的一点是，你还剩多少判断力？
如果只是丢一句模糊需求，接收到一个看起来还行的结果，然后改两下就交出去，那你很容易变成工具链里的一个按钮。替换你的未必是 AI，而是另一个更会点按钮的人。
AI 生成的东西通常不差。它能把框架搭起来，也能把内容补完整。但问题在于，它太容易发挥成平均水平：能用，却不一定好用；完整，却不一定真正命中关键问题。
所以人的价值，并不是和 AI 比谁更快，而是知道哪些部分可以交给它，哪些地方必须自己判断。哪里可以省时间，哪里不能偷懒。尤其是那些看起来“差不多”的地方，往往正是产品和内容拉开差距的地方。
你觉得呢？
