AI降低了开发成本，却提高了什么成本？

先确认降低的那部分，这个没什么争议：写一个能跑的功能，成本已经低到接近零。以前占大头的查资料、写样板、调试低级错误，现在要么被自动化，要么被压缩到几分钟。

但成本不会消失，只会转移。这一年里我明显感觉到有两项在涨，而且涨得比降下来的那部分更隐蔽。

第一项：验收成本

产出变快之后，验收成了唯一的瓶颈。

一天里经手的代码量翻了几倍，而每一行都需要判断"这段该不该留下"。这个判断没法自动化——类型检查、测试、lint 能挡掉一部分错误，但挡不掉"实现对了、方向错了"的那部分。

验收贵在它是串行的人工作业。生成可以并行，验收不行。你可以同时开三个任务让它们各写各的，但你读这三份产出的时间是累加的。于是一个反直觉的现象出现了：工具越强，你的时间越不够用，因为瓶颈从生成侧移到了判断侧，而判断侧的吞吐没有提升。

还有一层更麻烦的：验收质量依赖你对系统的理解深度，而理解深度是靠亲手写代码积累的。当你写的代码变少，你对系统的熟悉度会缓慢下降，反过来又削弱你的验收能力。这个负反馈很慢，慢到不容易被察觉，但一两年之后会很明显。

我的应对方式很笨：每个模块至少亲手重写一遍核心逻辑，哪怕 AI 已经给了一版能用的。不是为了代码更好，是为了保持"我知道这里在干什么"的状态。这个状态一旦丢了，验收就只能流于形式。前端尤其如此——JavaScript 的运行时行为、React 的渲染时机，这些知识的保持需要真的动手，读别人的产出补不回来。

第二项：放弃成本

第二项涨得更隐蔽：决定"不做"这件事变难了。

以前一个想法要花两周实现，你会本能地筛一遍。现在一个下午就能做出原型，筛的环节就被跳过了——反正便宜，先做了再说。

代价是你会积累一堆半成品。每一个都不难做，每一个都"差一点就好了"，于是每一个都舍不得删。十个半成品占用的注意力，比一个做完整的产品多得多。而它们几乎不产生任何收益。

Stripe 的数据里有组数字值得放在这里看：独立创始人中，早期收入的中位数下降了 23%，而收入最高的前 10% 上升了 19%，两者差距达到 61 倍。产出能力是普遍提升的，结果却严重分化——多出来的产出没有平均转化成收入，它堆在了那些"做了但没做完、或者做完了没人要"的地方。

这个分化说明的不是有些人更会用 AI，是有些人的判断力配得上突然变大的产能，有些人配不上。产能翻倍而判断力不变，结果就是产出更多不需要的东西。

第三项：一致性成本

还有一项介于两者之间：维持系统内部一致的成本。

每一份产出单独看都自洽，但它们之间会互相矛盾——命名不一致、同一概念有两种实现、同一份数据在两个地方被不同方式处理。这些矛盾不会立刻报错，它们会慢慢积累，直到某天一个跨模块的改动引爆。

维持一致需要有人持续持有全局视图。这个人只能是你，而且这份工作无法交给模型，因为它每次对话都是无状态的。把约定固化成 schema、类型约束和 CI 检查是唯一可持续的做法。环境层面也一样——Docker 把运行环境固化成配置文件，本身就是对抗漂移的一种手段。

怎么把这两项压下来

验收成本能压的空间有限，但有两个方向有效。

一是缩小单次验收的单位，让它一次只改一件事。改动越小，判断越准。一个两百行的改动里藏一个错误，你得读两百行；五个四十行的改动，你读四十行就能发现哪一块不对。让 AI 拆小，比让它写对更管用。

二是把判断变成可执行的检查。凡是你能在心里说清楚的规则，就写成 lint 规则、类型约束或者测试。写一次，之后每一版产出自动过一遍。这件事的回报随产出量线性增长，产出越大越划算。

放弃成本只能靠硬规则：每个新想法先写一段话说明它服务谁、解决什么、为什么现有方案不够好，写不出来就不开工。一段话的成本远低于一个下午，但能挡掉大部分不该做的东西。

变了的是什么

成本结构变了，不是总成本降了。

以前的成本集中在"做不出来"，是能力门槛；现在的成本集中在"不知道该不该做、做完不知道对不对"，是判断门槛。前者靠学习和工具能解决，后者只能靠积累和纪律。

这也解释了为什么同样的工具，在不同人手里结果差得那么远。工具给的是产能，产能要转化成结果，中间隔着判断。而判断这件事，恰好是唯一没有被自动化的部分。

所以衡量自己有没有从中受益，别看一天生成了多少代码，看一个月里你砍掉了多少东西。砍得越狠，说明判断在起作用。

Stripe 关于独立创始人收入分布的数据引自其公开的创业生态报告。