AI提升开发速度后，有人质疑产品是否该建得更多

Scotland, Nikon, 2026

打开你电脑上最熟悉的那款应用。现在想象一下，它的创造者把产品路线图向100位随机挑选的用户开放。他们会把这群人在半年内提出的每一个功能需求、每一个想法、每一次重新设计都做出来。你觉得两年后你还会用那个工具吗？

我很确定我不会。我认为它会很快变成一坨晦涩难懂的产品乱麻，什么都做，什么都做不好。

这个问题是我最近和一位朋友聊天时冒出来的。他告诉我，他所在的组织里有些人认为，AI已经实质性地解决了工程瓶颈。以前我们一个月发布一个功能，现在能发布二十个。我不怀疑你能做出二十个功能，但我非常怀疑你能用这种方式为产品带来二十倍的价值。

2010年代初，我在一些创业公司做过咨询，我一直很喜欢在那里看到的“障眼法”。一个很好的例子是一项为用户自动化产品运输和检查的服务。那是一个精致的网站，你填上自己的地址和产品信息，它会生成所有文书，第二天就有快递员上门取件。非常专业。

幕后则略有不同。那个网站实际上只是Google表单外面套的一层薄壳。生成文书的工作，是那里唯一的员工手动从表单导出的Excel里填充一些模板完成的。而那位快递员，也是同一位员工，他开车到你家，在车里检查产品，然后继续前往邮局。

那是一个能带来不错利润的产品¹。最终，他们扩大了平台规模，把大部分流程自动化了。但这恰恰就是MVP的意义所在：从最精简的实现开始，验证它行得通，然后随着业务增长，把真正让人痛苦的部分自动化。

这也给了你调整工作流的最快方式。如果你需要在引导流程里多加一行，你只需把它加到Google表单里，并在手动导出数据时把它考虑进去。

我想说的是，功能需要时间成熟。你需要反馈、迭代、打磨和实际使用，才能知道自己做的东西是否有用。

如果你一个月上线20个功能，那你到底什么时候做这些事？

我认为把一个功能的工程实现归类为瓶颈，是看问题的错误方式。工程不仅仅是敲代码。真正把一个功能工程化，还意味着理解用户需求、把它整合进现有产品、确保质量，并保证它可以维护。

功能也很少孤立存在。它们会与现有功能交互，引入依赖关系，产生新的边界情况。一个功能的成本，并不会在你合并pull request时就结束。

有能力构建20个功能，并不意味着你有能力恰当地理解、验证和维护20个功能。

你能想象自己是一名销售人员，必须带着潜在客户走一遍你的应用，而这个应用在过去六个月里新增了120个大型新功能吗？

那CEO呢？他得定义明年的战略。你还知道自己到底在哪个市场里竞争、你的竞争对手是谁、你产品的真正差异化优势是什么吗？

自从AI时代开始以来，我一直听到人们说，组织的生产力提高了多少，代码行数更多了，功能上线更快了，上市时间更短了。然而我还没听到任何一位CFO自信地宣称，我们在商业价值上取得了同样大的飞跃。

读到这里，你可能会觉得我是一个强烈的AI批评者，但我不这么认为。它确实是一个能提升功能上市时间的工具。但这不该成为把所有约束都扔出窗外的借口。我们别在这里跑偏了，我们仍然是在努力做出能解决问题的产品，而只有理解问题，你才能解决问题。

正如我在之前一篇文章中所说，并非所有的移动都是进步

那是那里某位员工的副业，我并没有在这家公司做咨询，因为没什么可咨询的 ↩︎

组织层 • 2026年7月

你不会雇初级员工来做琐碎的杂活

有一种想法困扰我有一段时间了：“随着LLM的到来，我们不再需要初级员工了”。这个……