为什么 AI 时代，开发者品味无与伦比的重要

过去一年，我对 AI 编程最强烈的感受，不是它又能生成多少代码，而是它真的把「做一个软件」的门槛往下压了一大截。

一个没有太多开发经验的人，今天可以对着麦克风描述需求，让 AI 写代码、改界面、修 Bug，甚至把一个小应用提交到应用商店。几年前，这件事多少还有点像技术圈里的想象；现在，它已经变成了很多人可以亲手体验的工作方式。

所以最近我越来越频繁听到一种说法：AI 时代，对开发者来说，最重要的能力不再是掌握多少编程语言，也不是熟悉多少框架，而是品位。

这个判断我基本同意。

但「品位」也是一个危险的词。它很容易让人产生一种体面的自我感觉，好像只要不再谈语法、框架和 API，开始谈审美、判断和长期价值，自己就已经站在了更高的位置。

这不是我想讨论的品位。

如果品位只是审美优越感，它在 AI 时代没有太多价值。真正有价值的品位，应该更具体：它是经验沉淀之后形成的标准感和取舍能力。

经验是你见过很多问题。品位是你因此知道什么结果可以接受，什么结果不能接受；什么时候应该快，什么时候必须慢；什么时候可以欠债，什么时候再欠下去就会出事。

所以这篇文章想讨论的不是「程序员会不会被 AI 取代」。这个问题已经被讨论得有些疲惫了。

我更想问的是：当代码越来越便宜时，为什么好软件仍然很贵？

我的理解是：AI 让代码变便宜了，但没有让好软件变便宜。因为好软件不是能跑的软件，而是在真实用户、真实约束和长期变化里仍然成立的软件。

而开发者的品位，正是判断一个软件如何在这些约束里成立的能力。

品位不是经验的换皮

今天很多开发者开始谈品位，本身是对现实变化的一种反应。

过去，写代码是一道很明显的门槛。一个人能不能开发软件，首先取决于他能不能理解编程语言、能不能搭环境、能不能调试、能不能把功能写出来。这个门槛足够高，所以很多讨论都停留在「会不会写代码」上。

大模型把这件事改写了。

当代码生成能力被大幅普及以后，「能写出来」这件事开始变得没有过去那么稀缺。一个想法从自然语言变成可运行软件，中间的距离被压缩了很多。很多过去需要一个开发者花几天甚至几周完成的事情，现在可能只需要一组还不错的提示词、几轮对话和一点耐心。

但执行成本下降以后，问题不会消失，只会转移。

过去最贵的是写出来。现在更贵的是选什么、怎么选、如何判断结果、出了问题谁负责，以及这个东西能不能在三个月后、六个月后继续被维护。

这也是为什么我更愿意把品位理解为标准感，而不是抽象的「综合判断力」。

标准感不是一句「我觉得这样更好」。它至少包含四个连续的问题：

1. 这个问题值不值得做；
2. 当前阶段应该做到什么程度；
3. 这个实现能不能被评估、维护和承担后果；
4. 用户最终会如何理解、信任和持续使用它。

换句话说，品位不是一个点，而是一条从「做什么」到「怎么做」，再到「如何长期存在」的判断链。

AI 可以参与这条链，但不能替你拥有这条链。

先判断是不是真需求

一个产品最早出问题的地方，通常不是代码。

而是需求。

没有经验的人做产品，很容易把自己当成用户，也很容易把用户说出口的话直接当成需求。用户说想要一个功能，就开始做一个功能；自己觉得某个想法有趣，就立刻进入开发环境；看到一个竞品有某个模块，就下意识觉得自己也应该有。

AI 会让这个过程变得更危险。

因为过去从想法到产品之间还有一道开发成本的阻碍。一个人即使有很多冲动，也未必真的能把它们都做出来。但现在 AI 让「做出来」变得容易以后，很多没有被验证过的想法会更快变成产品。

这听起来像效率提升。

但如果方向错了，效率越高，浪费越快。

判断真需求，并不是问「用户有没有说过这句话」。更重要的是理解：

1. 用户为什么会这样说；
2. 这个问题是否高频、刚性、具体；
3. 用户现在用什么方式解决；
4. 这个解决方式的真实成本是什么；
5. 你的产品是否真的比现有方案更好。

这里面需要的不是写代码能力，而是观察、追问和判断。

AI 可以帮你整理访谈记录，可以总结用户反馈，可以生成需求文档。但它很难替你承担最终判断：这个需求究竟值不值得做。

从这个角度看，品位首先是一种对问题的敏感度。

一个有经验的开发者，不一定比别人更快写出代码，但他可能更早意识到：这个问题压根不应该这样问。

再判断应该欠什么债

找到需求之后，也不意味着应该立刻把所有能力都做出来。

AI 很擅长提供方案。你给它一个需求，它可以给你很多实现路径：这里可以用本地存储，那里可以接数据库；这里可以做账号体系，那里可以加协作功能；这个界面可以做成仪表盘，那个流程可以拆成多步骤。

每个方案看起来都有道理。

但软件开发真正困难的地方，往往不是有没有方案，而是选择哪个方案。

一个产品不是静止的。它有阶段。

早期产品需要验证需求，中期产品需要提高稳定性和留存，成熟产品才需要更完整地处理协作、权限、成本、数据和长期维护。不同阶段对应的复杂度应该不同，技术架构也应该不同。

如果一个产品还没有证明用户真的需要它，就急着设计复杂的权限系统、可配置能力、插件架构和多租户模型，这看起来很专业，实际上可能只是过早复杂化。

反过来，如果一个产品已经开始被真实用户稳定使用，却仍然用一次性脚本和临时状态拼在一起，那它迟早会在迭代中变得难以维护。

这里有一个容易被误解的地方：强调品位，不是强调一开始就要把工程做得很完美。

很多成功产品早期都很粗糙。代码可能混乱，架构可能临时，界面可能也没有那么讲究。但它们抓住了真实需求，所以活了下来。

这并不反驳品位的重要性，反而说明品位不是洁癖。

品位不是不欠债，而是知道应该欠什么债、欠到什么程度、什么时候必须还。

好的开发者会问：

1. 这个问题现在真的需要完整解决吗；
2. 有没有一个更小但足够真实的版本；
3. 这个方案未来是否容易替换；
4. 当前复杂度是在节省成本，还是在制造债务；
5. 如果这个产品被更多人使用，最先崩掉的地方会在哪里。

AI 可以生成十种方案，但它不知道你当前真正能承受哪一种。

这仍然需要人来判断。

然后评估它能不能活下去

很多 AI 生成的软件，第一眼看起来是能用的。

这很容易让人兴奋。

但软件不是截图，也不是演示视频。它会被用户反复打开，会遇到异常输入，会碰到网络波动，会出现权限问题，会积累数据，会被不断修改，会在某一天被另一个人接手。

一个项目能跑起来，和一个项目能长期活下去，是两件事。

传统软件工程里那些看起来有点繁琐的东西，并不是没有意义：

• 架构分层；
• 类型约束；
• 错误处理；
• 测试；
• 日志；
• 权限；
• 数据迁移；
• 安全边界；
• 部署策略；
• 协作规范。

这些东西的价值，往往不是在第一天体现出来，而是在第十次需求变化、第一次线上事故、第一次多人协作、第一次用户数据异常时体现出来。

AI 生成代码的能力越强，这个问题反而越值得重视。

因为 AI 天然会倾向于满足当前上下文里的显性目标。你让它实现一个功能，它会尽力把功能实现出来。但它未必知道这个项目未来半年会如何演进，也未必能自动理解你对安全、稳定性和可维护性的底线。

所以 AI 时代开发者的品位，还体现在评估能力上。

不是只看「它有没有完成任务」，而是继续追问：

1. 这段代码在异常情况下会怎样；
2. 这个数据结构以后是否还能扩展；
3. 这个接口失败时用户会看到什么；
4. 这个权限判断有没有被绕过的可能；
5. 这个成本会不会随着使用量增长而失控；
6. 如果出了事故，谁能定位，谁能修复，谁来承担。

最后一个问题尤其重要。

AI 可以生成方案，但上线后的责任不会由模型承担。用户数据丢了，权限泄露了，账单失控了，业务流程被错误结果影响了，真正面对后果的一定是发布者、维护者和组织。

这也是我不太喜欢把 AI 编程只描述成「普通人也能做应用」的原因。

对于一次性脚本、个人自动化、小范围内部工具，这当然是好事。很多事情不需要被过度工程化，只要解决当下问题就足够。

但如果你想长期发布一个产品，服务真实用户，处理真实数据，并且让它在变化中继续成立，那就不能只满足于「它现在能跑」。

标准会变高。

责任也会变重。

产品还需要被感知

即使需求是真的，方案也合适，工程也足够稳定，一个产品也还没有结束。

它还需要被用户理解、信任和愿意使用。

这时品位会进入另一个层面：产品如何被感知。

为什么有的产品让人一打开就觉得粗糙？为什么有的产品明明功能不多，却让人觉得可靠、清爽、愿意继续探索？为什么同样是一个设置页，有的让人感到负担，有的让人感到秩序？

这不只是 UI 好不好看。

它涉及视觉、交互、文案、信息层级、反馈速度、品牌调性和整体一致性。一个产品用什么语言和用户说话，在哪些地方保持克制，在哪些地方提供解释，在哪些地方不要打扰用户，都会影响用户对它的判断。

AI 可以生成界面，也可以生成文案。

但一个产品是否俗不可耐，是否过度堆叠，是否为了显得强大而让用户感到疲惫，仍然需要人来判断。

很多时候，好的品位不是多做什么，而是少做什么。

不把所有功能都暴露出来。

不在每个地方都加动画。

不把每个按钮都写成营销文案。

不为了显得 AI 而让产品变得吵闹。

一个产品最终呈现出来的气质，来自无数个这样的取舍。

这类取舍看起来很软，但它会直接影响用户是否愿意把一个工具放进自己的工作流。一个让人不信任的产品，功能再多，也很难被长期使用。

AI 写作是一个很好的提醒

这件事可以类比到 AI 写作，但我不想把这个类比展开得太长。

今天任何人都可以让 AI 生成一篇文章。速度很快，结构完整，语句通顺，甚至还能模仿某种风格。

但我们也很容易读出一些文章的 AI 味。

它们看起来什么都说了，但没有真正的判断；每一段都很顺滑，但没有现场感；结构很完整，但读完之后很难记住一句话。

同样使用 AI，有的人生成的是一篇可以发布的文章，有的人生成的是一份正确但无趣的说明文。

软件也是如此。

生成能力的普及，不会自动拉平品质差异。它更可能放大这些差异。

因为当生产变容易，真正稀缺的东西会变成：

• 你选择什么问题；
• 你设定什么标准；
• 你接受什么结果；
• 你知道哪里不能妥协；
• 你是否能持续改进。

这也是为什么我认为，AI 时代谈开发者的品位，并不是一个空泛的说法。

它指向的是一个更具体的问题：当工具越来越强，人还负责什么？

小结

如果你是一个软件开发者，我不认为 AI 编程变强只意味着焦虑。

它当然会改变开发者的工作方式，也会让一部分只依赖重复编码经验的能力变得没有过去那么稀缺。但它同时会放大真正有经验的开发者的创造力。

因为你过去积累的，不只是语法、框架和 API。

你还积累了对需求的判断，对复杂度的控制，对工程质量的直觉，对用户体验的敏感，对产品长期演进的理解。

这些东西不会因为 AI 能写代码就突然失效。

相反，它们会变得更重要。

如果你不是开发者，只是因为 AI 编程能力变强而开始对软件开发感兴趣，这当然是一件好事。AI 确实降低了进入这个领域的门槛，也能让你更快获得正反馈。

但我会建议你把「我做出了一个应用」看作开始，而不是结束。

接下来更值得问的是：

1. 这个问题真的存在吗；
2. 这个工具会被谁反复使用；
3. 现在的粗糙是合理的阶段选择，还是未来一定会爆炸的债务；
4. 如果它开始服务真实用户，我能不能评估质量并承担后果；
5. 这个产品有没有一种让人愿意信任的表达方式。

这也是我现在理解的开发者品位。

它不是审美优越感，也不是经验的漂亮说法。

它是一种标准感：知道什么是好，什么只是能跑；知道什么时候该快，什么时候不能省；知道工具能替你完成什么，也知道最后哪些责任仍然回到人身上。

请让我再次强调这篇文章最重要的判断：

AI 让代码变便宜，但没有让好软件变便宜。

工具越强，越会放大方向、取舍和标准上的差异。