当软件开始小批量生产：AI、长尾需求与一人公司

一、缝得更快，和敢做得更少

先做一道选择题。

假设一家服装公司对外宣布，它找到了一种办法，可以让缝纫工人的效率提高三倍。你觉得这件事最重要的后果是什么？

大多数人的第一反应是成本：过去一天做一百件衣服，现在一天做三百件，同样的衣服更快、更便宜地被生产出来。这个回答不算错，但它把一件本来相当有想象力的事，读成了一道算术题。

因为快时尚真正改变服装市场的方式，并不是把同一批衣服缝得更快。它改变的是，一家企业愿意为一个款式承担多大的初始承诺。

在传统服装工业里，一件衣服要进入生产，必须先跨过一道很高的门槛。设计要定，面料要订，版要打，产线要切换，货要运，门店要陈列，这些都得提前安排。为了把单件成本压下来，一次就必须生产足够多。于是，一个款式值不值得存在，首先不是由”有没有人喜欢它”决定的，而是由”喜欢它的人够不够多”决定的。

这两句话听着差不多，其实差得很远。一个只在上海几家店有需求、只流行六周、只吸引某个亚文化群体的款式，即使确实有一批人愿意掏钱买，也可能根本进不了生产计划。它不是没有需求。它是需求的规模，小于这套供应体系能够经济处理的最小批量。

Zara 所代表的快反体系做了两件互相配合的事：把第一批货做小，把销售反馈送回来得更快。哈佛商业评论对 Zara 供应链的那篇经典分析指出，它有意保留冗余产能，采用小批量，并保持对设计、生产和门店反馈的较强控制，用牺牲一部分静态效率来换取反应能力（Rapid-Fire Fulfillment）。第一批不必押那么大，卖不动的可以停，卖得好的可以追加。企业买到的其实不是生产速度，而是一种延迟承诺的权利：等知道得更多一点，再决定把多少资源押上去。

这里藏着一个容易被忽略的事实：市场并不总是先完整地存在，然后等着供给者去”发现”。有些需求，只有在供应成本、批量和反馈周期改变之后，才第一次成为可以经营的市场。在那之前，它们当然也存在于人的偏好里，只是没有一种经济的生产方式能接住它们，所以在企业的报表上近似于不存在。供给曲线变了，需求才从噪声变成订单，从个人偏好变成产品品类。

现在把这套逻辑搬到软件上。

AI 编程正在对软件做类似的事，而我们通常把它描述成程序员提效：同一个团队完成更多需求，同一个项目更快上线，同样数量的代码需要更少的人。这些说法都是真的，但它们的目光始终停在那些原本就会被批准的软件上——相当于只讨论缝纫机变快了几倍。更大的变化很可能发生在批准线以下：那些以前因为用户太少、寿命太短、场景太窄、维护太麻烦而不值得开发的软件，现在开始有机会被造出来。

为了给这条批准线一个名字，不妨借用制造业的语言，叫它软件的起订量。它指的不是代码至少要写多少行，也不是产品至少要有多少用户，而是：一个真实需求必须大到什么程度，才值得一个组织为它承担需求分析、开发、集成、测试、上线和维护的全部成本。

这篇文章接下来要讲的，都是围绕这一个量展开的。AI 的产业意义，很可能就在于它正在把这个数字往下压。

二、复制免费的东西，为什么偏偏只肯服务大多数人

软件行业最常被强调的经济特征，是复制成本接近于零。一套程序写好之后，再多一个用户下载或调用，边际成本通常远低于制造一件新商品。这个事实解释了软件公司为什么能获得极高的规模收益，但它也顺手制造了一个误解：既然复制这么便宜，软件理应天然适合各种小众需求才对。

现实恰好相反。软件的复制很便宜，第一次创造和长期存在却很昂贵。

举个具体的例子。想象一家三百人的制造企业，其中八个人负责售后索赔。他们每天收到不同经销商发来的表格，需要把表格里的产品序列号、物流记录、保修期限、配件批次和费用归属，与 ERP 里的数据逐项核对。规则本身并不神秘：某类零件保修十八个月，某种运输损坏由经销商承担，某些批次需要额外复核。麻烦在于，这些规则散落在制度文件、ERP 字段、历史邮件和员工经验里，输入数据又不完全统一。于是八个人每天要花几个小时复制、筛选、比对、标色和追问。

从业务价值看，这显然值得改善。假设它每年消耗数千小时，还会造成漏赔、错赔和客户等待，做一个工具似乎理所当然。

可一旦真的进入正式立项，问题就换了一副面孔：谁负责把经销商的不同表格映射成统一格式？哪个系统里的日期才算保修起点？权限怎么划分？异常由谁审批？工具要不要接入单点登录？数据保存多久？员工离职以后谁来维护？ERP 升级的时候谁负责调整接口？

请注意，这些问题里只有一小部分是”写代码”。传统项目需要产品经理梳理需求，需要工程师实现，需要测试人员覆盖例外，需要运维和安全团队把它送进生产环境，还可能需要走一遍采购流程去找外部供应商。项目结束以后，它还会留下一条长长的尾巴：依赖升级、权限回收、数据备份、漏洞处理、需求变化。而这里最要命的一点是：即使这个工具只服务八个人，上面这些固定成本，也不会缩小到服务八千人时的千分之一。

于是传统软件组织不得不去追求大市场。固定成本越高，就越需要更多相似用户来分摊。SaaS 公司到处寻找”可重复销售”的标准工作流；企业软件把差异统统收进配置项、实施项目和定制接口；投资人要求足够大的可寻址市场；内部 IT 部门优先建设跨部门平台，而不是去解决某个角落里八个人的麻烦。这些选择看起来保守，其实是成本结构下的理性结果——它们不是想象力不足，是算过账的。

被这套结构挡在门外的需求，并没有因此消失。它们退回到 Excel、邮件、微信群、浏览器收藏夹、复制粘贴、临时脚本和人的记忆里。所以你会看到一种很常见的错位：一个组织的表面系统是 ERP、CRM、OA 和数据平台，它真实的运行方式却由大量”最后一公里”的人工动作组成。员工每天在标准系统之间搬运信息，用自己的判断去弥补接口之间的缝隙。大型软件服务的是能够被标准化的共同部分，而无法摊薄的那部分小众性，是由人来承担的。

换个说法：在很多组织里，人就是那段没人愿意写的中间件。

软件的起订量因此是一条看不见的产业边界。它决定哪些活动会被正式编码，哪些活动继续由人充当接口；哪些需求会变成产品，哪些需求只配被叫作”特殊情况”；哪些人获得一套顺手的工具，哪些人只能学会忍受现有流程。

三、账单上真正变短的是哪几栏

说 AI 降低软件的起订量，不能简单等同于”生成代码变便宜了”。这是一个必须认真对待的区别。如果一个项目的成本有九成来自组织协调、数据清理、安全和责任划分，那么代码生成成本哪怕降到零，项目也未必成立。真正值得分析的是：AI 沿着软件的生命周期，能压低哪几类固定成本，又有哪几类成本不会跟着下降。

下降得最明显的是实现成本。过去一个再窄的工具，也得搭前端、后端、数据库、权限、接口、部署脚本和测试。这些活儿单看都不难，但种类多、切换频繁，需要工程师一项一项地做完。编程代理可以一次理解一个相对完整的目标，生成跨多个文件的修改，调用测试和构建工具，失败以后继续修正。Cognition 的 Scott Wu 在一次访谈里把 AI 编程更大的机会概括为产能，而不只是效率：当我们能够制造的软件数量显著增加，过去不可行的事情会进入可行区间（Sourcery 访谈，37:17 起）。他关于 Devin 在公司内部写出大部分代码、以及交付量增长的那些数字属于公司自述，不能直接外推成全行业事实；但”供给能力扩大以后会释放什么需求”这个问题本身是成立的，而且比任何具体倍数都更值得想。

第二类是试错成本。传统软件项目常常要求在写出成品之前就把需求说清楚，原因很朴素：每次返工都很贵。这就造成一种奇怪的局面——业务人员只能靠文档、原型和会议去想象一个还不存在的系统，工程师则被迫在信息最少的时刻冻结接口。当构建和修改都变便宜，一部分需求可以从”先把一切讨论正确”变成”先做一个能跑的版本，再对着真实流程改”。这就是软件领域的小批量投放：第一版不再是一次不可逆的大承诺，而是一支用来获取信息的探针。

第三类是理解已有系统的成本。很多内部工具和政府系统之所以改不动，不是因为新界面难写，而是因为没有人完整理解旧系统。规则埋在几十年的代码、数据库触发器、批处理脚本和操作手册里，知道它的人可能已经退休了。AI 能帮助阅读不同语言的代码，追踪调用关系，解释数据转换，生成表征当前行为的测试，整理文档，搭建适配层。它未必知道旧行为在法律和业务上是否正确，但它可以显著降低”先弄清楚它实际上在做什么”这一步的工程费用——而这一步过去往往是整个改造项目里最贵、最容易被低估的部分。

第四类是小范围维护成本。一个只有八个人使用的工具，不可能长期配一支完整团队。过去这意味着它一出问题就成了孤儿：写它的人走了，没人敢碰，最后自然死亡。代理式开发让未来的维护者更容易重新进入上下文——读代码、看日志、翻历史提交、定位错误、完成依赖升级、补测试。维护不会因此免费，责任也不会自动出现，但单位变更所需的专业时间可能确实下降了。

现在说另一半，这一半同样重要。至少有五类成本，不会按同样的速度下降。

业务判断不会因为代码是生成的就自动正确——经销商索赔究竟以发货日还是安装日作为保修起点，这是制度问题，不是语法问题。数据权限也不会因为界面顺手就自然合理：谁能看到客户信息，谁能批准赔付，哪些操作必须留痕，仍然需要组织明确下来。集成成本更不会消失，旧系统的数据脏、接口不稳、字段含义打架，模型可以帮着处理，却无法把现实变成一个干净的 API。安全与合规成本甚至可能不降反升，因为工具的数量本身变多了。而最难自动化的是责任成本：系统做错了以后，必须有人出来决定、解释、赔偿和修复。

把两半合起来，边界就清楚了：AI 降低的主要是”把明确意图转化为可运行软件、再根据反馈修改软件”的成本。它不替组织决定意图，也不替组织承担后果。

这个边界不但没有削弱”起订量下降”的判断，反而顺手给出了一份释放顺序表：范围窄、规则相对明确、出错可回滚、用户和责任人能被识别的需求，会比高风险、跨机构、法律含义复杂的需求更早进入可行区间。想预判长尾软件先从哪里冒出来，看这四个条件就够了。

四、门槛落下来之后，先长出来的是什么

起订量一旦下降，新增的供给不会平均分布。最先出现的，不会只是更多长得差不多的通用 SaaS，而是几类过去很难被正式软件化的东西。

第一类，是企业内部的”八人问题”。它们通常长在大型系统的接缝处：把销售预测转成采购建议，把不同渠道的退货原因统一归类，把实验室设备导出的文件整理成质量记录，把某个国家的税务要求映射到总部系统，把供应商证书和物料批次对应起来。这些流程有明确的用户、可观察的输入和相对有限的输出，但差异大到无法直接买标准产品，规模又小到不值得做传统定制开发——两头不靠。

这类工具的价值，不能只按节省工时来算。人工流程往往还意味着不可追溯：某次判断为什么这么做，依据的是哪条规则，谁在什么时候改过结果，事后很难回答。一个窄工具如果能把输入、规则、例外和审批都留下来，它同时改善的是效率、质量和组织记忆三件事。过去这三项收益加起来仍然覆盖不了项目成本；当构建和迭代成本下降，这笔账可能第一次算得过来。

第二类，是寿命很短的软件。传统开发倾向于建设”长期平台”，因为启动一个项目太贵，必须假设它会用很多年——这是成本结构逼出来的思维习惯。但现实里有大量临时任务：一次并购的数据核对，一次展会的线索处理，一个为期三个月的迁移项目，一个法规过渡期的报送，某个大客户上线前的专项协同。过去人们用表格和临时群组硬扛，因为给一个三个月的任务写软件显得荒谬。如果一个代理可以在几天内做出工具，并在任务结束时连同数据保留规则一起把它下线，那么”活不长”本身就不再构成否决理由。

第三类，是高度个性化的软件。一个通用产品必须找到大量相似用户，所以它往往要求用户去适应产品。起订量下降以后，软件可以反过来适应个人或小团队：研究者按自己的文献分类方式构建阅读工具，销售人员按自己的客户节奏组织跟进，家庭按自己的资产和照护关系管理事务，创作者为一套只有自己在用的工作流做一个控制台。这不等于每个人都得成为程序员。它意味着人和软件之间多了一层生产系统，能把自然语言、示例和一次次纠正翻译成程序行为。

第四类，是公共服务的局部现代化。Scott Wu 在访谈里提到 DMV，这个例子背后是一条特别长的尾巴：大量公共部门流程并不是完全没有软件，而是被困在几代系统的接缝之中。一次驾照续期，可能牵扯核心记录、预约、支付、身份核验、医疗限制和人工复核。全面替换风险极高，局部体验又长期排不上资源，于是就那么僵着。

可信的路线不是让模型一键重写旧系统——那恰恰是把承诺做大。可信的路线是把每一次承诺缩小：先让 AI 帮着梳理旧系统的实际行为，针对可观察行为建立测试；再用适配层把旧接口包住；然后在外围建设材料预检、状态查询、通知、收据这类风险较低的功能；最后才逐步迁移边界清楚的模块。法律解释、资格判定、隐私边界、安全批准和申诉责任，仍然由有权机构承担。AI 在这里的作用，不是提供一条新路线，而是让这条本来就正确、只是太贵而没人走得起的渐进路线，变得可执行。

第五类最有意思：那些以前根本不会被称为”软件产品”的一次性生成物。某个复杂决策可能只需要一个用一下午的模拟器；某份数据只需要一个临时的可视化界面；某次谈判只需要一套把合同条款和历史执行记录对照起来的工具。传统观念里，软件是需要长期发布、维护和销售的东西；而生成能力会让一部分软件更接近文档——为了一个具体目的被制作、被使用，然后归档或销毁。它的价值来自当时帮人完成了一次认知或协作任务，不来自积累永久用户。

把这五类放在一起，会看到一个共同点：AI 让软件供给增长，最重要的结果不是应用商店里多出更多图标，而是”什么值得被编码”这条边界，正在向日常活动的深处移动。以前只有稳定、重复、规模足够大的流程才配拥有软件；接下来，短暂的、局部的、个人化的、不规则的活动，也可能拥有自己的可执行工具。

五、供给不只是满足市场，它还会造出市场

经济学课本喜欢把需求画成一条已经存在的曲线：价格下降，购买量上升。软件起订量的变化比这个模型有意思，因为它不只是让同一种产品变便宜，它还改变了产品能被切分到多细。

传统 SaaS 的基本单位，通常是一个横向品类或一个垂直行业：项目管理、客服、财务、医院管理。这些边界并不是世界天然的关节，而是产品必须聚合足够多用户来分摊固定成本的结果。大量更细的需求，要么被打包进大产品的功能菜单，要么干脆留给人工。当产品单位可以变小，一个”大市场”就会分解成许多小市场：不是”制造业售后软件”，而是”某类工业设备经销商的索赔核对”；不是”政府数字化”，而是”某项续期业务的材料预检与状态解释”；不是”个人效率工具”，而是”一个人把研究资料转成写作问题的流程”。

市场切细之后，过去显现不出来的付费意愿也会跟着出现。用户可能不愿为一个有两百项功能的平台多付订阅费，却愿意为一个每天替自己消掉四十分钟痛苦的窄工具掏钱。企业可能不愿批一个百万级的系统工程，却愿意让业务部门在可控边界内买一个小型方案。公共机构可能没有能力推动核心替换，却能采购一个不改变法定判断、只改善材料收集和状态透明度的外围模块。

这和快时尚挖出来的那些需求是同一种东西。一个小众款式并不是因为 Zara 出现才被人喜欢，但只有当首批生产足够小、补货足够快，这份喜欢才成为企业能够响应的信号。同样，一个八人团队的流程麻烦早就存在，只有当软件的固定成本降到与之相称的水平，它才成为供应商或内部创业者可以服务的市场。

再往前走一步，事情会变得更有意思：供给能力还会改变人的期待。

智能手机出现之前，没有人会在需求调查表上填写”我想随时叫到一辆陌生人的车”；电子表格出现之前，绝大多数普通办公室人员不会提出”我要自己建立一个可计算的模型”；搜索引擎出现之前，人们也不会期待几秒钟内定位一条冷门资料。原因很简单：人只能对自己想象得出来的产品表达需求。新供给让一种行为变成日常之后，围绕它的新需求才会被看见。

AI 软件也会产生这种二阶效应。当一个部门第一次发现，可以用很低的成本为自己的窄流程做一个工具，它就会开始重新打量更多原本被当作”工作就是这样”的摩擦。当一个人第一次拥有一个真正按自己方式工作的应用，他会突然意识到通用产品里有多少妥协其实并非必需。需求不是一次性被释放完的，它是在使用新供给的过程中被逐步教育和细分出来的。

这也意味着，我们今天很难准确估算这个市场有多大——而且几种常规估法都会系统性地偏低。用现有 SaaS 支出去推算，会漏掉那些目前由人工忍耐承担的成本；用现有软件项目数量去推算，会漏掉那些从未进入立项表的需求；用户访谈里问”你还需要什么软件”，答案又受限于对方的想象边界。

更好的观察对象，可能是组织里那些反复发生的复制粘贴、人工核对、跨系统搬运、临时汇总和口头例外。过去我们把它们看成低效的零散现象，其实它们是一份相当准确的清单：尚未跨过起订量的潜在软件需求，都写在上面。

六、一个人开一座小批量工厂

软件起订量下降以后，最容易被想象的组织形态是”一人独角兽”：一个创始人借助 AI 完成过去需要几百人的工作，建起一家估值十亿美元的公司。这个故事足够醒目，但它未必抓住了最先发生的变化。

更现实的形态，是一个人经营一座小批量软件工厂。

他不把全部资源押在一个宏大产品上，而是围绕自己熟悉的用户、渠道或工作流，连续推出多个窄产品。每个产品的首批投入都很小，上线以后观察真实使用，没有需求的尽快关掉，有增长信号的继续追加。关键不在于这个人拥有超人的执行力，而在于单次试验的成本已经降到可以承受高失败率——这和 Zara 敢做小批量是同一个道理。

Pieter Levels 公布过自己历年项目的清单，里面有少数持续成功的产品，也有大量停止或没有形成规模的尝试（List of all my projects ever）。这份清单最值得看的不是”一个人也能成功”这种励志结论，而是它展示出的组合经营结构：如果一次上线不再需要融资、招聘和半年开发，那么失败就可以成为投资组合里的常态，而不是职业生涯里的灾难。少数赢家覆盖多数失败，而经验、代码、渠道和受众又能在项目之间反复复用。

Base44 提供了另一种极端样本。创始人 Maor Shlomo 曾自述其单人阶段没有雇员、依靠自有资金，并报告六个月内约 350 万美元 ARR 和超过三十万用户；需要说明的是，这些运营数字来自创始人本人，并非审计财务。后来 Wix 正式宣布以约八千万美元加业绩对价收购 Base44（Wix 公告）。这个案例至少说明一件事：一项在极小团队阶段形成的产品，可以迅速积累到足以被大型公司买下的用户关系和市场位置。它不证明所有一人公司都能复制这条路径，也不证明这样的公司会一直保持一个人。

顺便说，”一人公司”里的那个”一”，其实很容易造成误导。

这个人并没有独自制造芯片、训练基础模型、运营数据中心、建设支付网络、处理全部法务和客服。他站在一条高度成熟的外部供应链上：模型 API 提供认知产能，云平台提供计算和部署，支付服务提供结算，身份服务提供登录，应用市场和社交平台提供分发，开源社区提供基础组件，承包商提供设计、法律和专项服务。过去必须通过雇佣才能纳入公司内部的能力，现在可以按需从市场上买。

所以一人公司真正缩小的，是内部协调的边界，而不是它所依赖的生产体系。它有点像一个服装品牌，不拥有每一台纺织机，却掌握选款、节奏、品牌和渠道；也有点像一位电影制片人，不亲自完成每一个工种，却决定项目是否成立、资源如何组合。模型和代理让可外购的能力进一步增加，个人手里保留下来的，是判断、品味、用户理解、资源配置，以及最终责任。

这种组织最可能从三种优势里长出来。一是流程知识：创始人真的理解一个很窄但真实的麻烦，知道哪些例外决定了这个产品有没有用。二是分发关系：他已经在某个社群、行业或内容渠道里积累了信任，不必为每个小产品从零买流量。三是组合复用：多个产品服务相近的用户，共享品牌、账号、数据连接、客服和支付，单个产品的固定成本被整个作品集分摊掉。

反过来，一个只有”写代码更快”这一项优势的一人公司会非常脆弱。因为同一个模型也向所有竞争者开放，功能很快会被复制。真正能沉淀下来的资产，通常不是那些被生成出来的代码，而是对一条窄工作流的理解、持续获得用户的渠道、历史使用积累的数据和纠错，以及用户相信这个人会长期负责的信誉。

七、进门变容易了，赢没有

关于一人创业增长的早期证据，支持”更多人能够进入”，但不支持”团队已经失去价值”。这两件事经常被混为一谈。

Nasdaq Economic Institute 在 2026 年的一份分析中指出，美国一人企业的申请量自 2025 年初以来明显增长，增量集中在 AI 采用度较高的行业；该机构同时明确说明，把 AI 当作解释是基于时间和行业构成的推断，而不是一个已经建立的因果关系（AI Is Enabling More Entrepreneurship）。远程工作、就业环境、无代码工具和平台经济，都可能同时在推动这个变化。

一项覆盖十六万余次 Product Hunt 发布的研究给出了更有张力的结果：生成式 AI 提高了单人创业进入的比例，但在排名靠前的项目中，团队的优势依然存在，甚至还扩大了（Generative AI Fuels Solo Entrepreneurship, but Teams Still Lead at the Top）。

这个结果看起来矛盾，其实只是把两道门槛分开了。

进入门槛主要由”能不能把东西做出来”决定，而 AI 对这一部分的影响最大，所以更多个人能够上线产品、验证需求、拿到第一笔收入。胜出门槛则越来越由别的能力决定：能否持续触达用户，能否建立品牌，能否完成复杂集成，能否通过企业采购和安全审查，能否在事故发生时及时响应，能否在竞争者复制了功能之后继续演化，能否给客户一个长期承诺。前一道门槛在往下走，后一道门槛没有跟着走。

团队的价值也会随之迁移——从”凑够写代码的人”，迁移到”同时拥有多种不可替代的能力”。当生产代码不再需要大量人手，判断一个团队是否合理，就要看这些人之间是否存在必须长期紧密协作的互补关系：产品判断与行业销售，安全与运维，客户成功与复杂实施，品牌与内容，法律责任与技术变更。AI 会削弱一部分按工种堆人的组织，却不会消灭那些由互补知识和共同责任结成的组织。

所以一人公司和大团队之间，不会是简单的替代关系。更可能出现的是企业形态的分布变宽：大量个人和小团队进入过去不经济的窄市场，少数产品在复杂度和规模上升之后选择扩张团队，另一些则保持小而盈利，还有一些被掌握分发或治理能力的大公司收购。AI 不是要把所有公司压成一个人，它是让”一开始必须有多少人”这个数字下降。

八、便宜的生产会带来昂贵的库存

快时尚的故事还有另一半，我们最好一起讲完。

小批量生产确实降低了单次押错款式的风险，但它也可能把整个系统推向更高的上新频率和更大的总产量。小批量并不天然等于少生产。当试验足够便宜，企业就会试更多款，消费者就会买更多，最终的废弃和外部成本反而上升。

软件会遇到结构上完全相似的问题。

过去，昂贵的开发成本本身就是一道数量闸门。一个部门想做工具，得排期、要预算、走审批，许多不重要的想法在进入生产之前就被成本挡掉了。这个过程缓慢而官僚，但它客观上限制了应用的数量——它是一道笨拙的过滤器，可它确实在过滤。当 AI 让任何团队都能快速生成工具，这道天然闸门就消失了。

软件没有布料库存，但它有自己的持有成本。每一个小工具都可能带着一套账号和权限、一份客户或员工数据副本、一组第三方依赖、一个域名、一条云资源账单和若干自动化任务。即使已经没人使用，它也可能继续在跑。写它的人离职之后，别人不知道它为什么存在，于是既不敢关，也不敢改。单看一个工具几乎是免费的，几十个叠加起来就是攻击面、数据孤岛、指标冲突和运维债务。

更麻烦的是，生成的速度可能超过组织形成责任关系的速度。某个业务人员用代理做出一个应用，很快解决了眼前问题，却未必知道要登记数据来源、设置访问期限、准备故障告警、确定备份策略、指定继任者。传统 IT 治理是以项目审批为中心的，因为过去生产是稀缺环节，卡住入口就等于卡住一切；而当生产不再稀缺，治理的重心必须转向生命周期。

说得更直白一点：治理要从”谁允许你开始”，改成”谁对它持续负责”。

一个轻量工具至少要能回答几个问题——负责人是谁，处理什么数据，依赖哪些系统，谁可以访问，出错会造成什么后果，多久重新评估一次，在什么条件下自动下线。但这些问题不应该都变成冗长的审批表，否则等于把起订量重新抬回去，前面所有的收益就被治理成本吃掉了。它们更应该成为低成本生产平台的默认元数据和自动化控制：不是让人多填一张表，而是让平台默认知道答案。

由此，删除能力会变得和生成能力一样重要。一个健康的软件小批量体系，不仅要能快速上线，还要能快速确认无人使用、导出必要数据、撤销权限、关闭资源并保留审计记录。服装业最难处理的是卖不掉的库存；软件业未来最难处理的，可能是没人敢关的应用。

个人经营者面对的是同一个问题的小型版本。作品集策略只有在失败产品能够低成本退出时才成立。如果每次尝试都留下客服承诺、付费用户、数据义务和依赖维护，那么连续上线很快就会把一个人拖垮——他会变成自己那座工厂的仓库管理员。真正跑得久的一人软件工厂，需要的不只是发布节奏，还需要止损标准、迁移方案和关停纪律。

九、最稀缺的工种，从生产变成了选择

当一种生产能力稀缺的时候，管理的中心自然是提高产量。工业时代衡量一家工厂每小时生产多少件商品，软件时代衡量一个团队完成多少需求、发布多少版本、写出多少行代码。AI 编程延续了这套语言：消耗多少 token，多少比例的代码由模型生成，速度提高几倍，一个人能顶几个工程师。

这些数字可以描述供给的扩张，却回答不了供给扩张之后最重要的那个问题。起订量下降以后，组织面对的不再是”还有哪些需求做不出来”，而是”哪些需求值得被赋予一个长期存在的软件实体”。

请注意这里发生了什么：以前，成本替我们做了大量筛选。一个想法不成立，往往不需要谁去否决它，预算会替所有人说不。这是一种把判断外包给经济规律的舒服状态。现在这项判断被退回来了，必须由人显式地承担。

这会改变我们对”软件能力”的定义。优秀的组织不再只是拥有最强的工程团队，还要拥有一套完整系统：能发现窄需求，能迅速形成小批量解决方案，能从真实使用中学习，能扩大有效产品并关闭无效产品。它既像一个研发体系，也像一个投资组合管理机构；既要鼓励试验，也要控制数据和责任；既要让业务一线能够表达差异，又要避免每一个差异都长成一座永久孤岛。

它同样会改变创业者的优势结构。当代码供给普遍增加，单纯拥有代码不再构成壁垒。更稀缺的是：知道哪个小需求虽然人数不多但痛得足够深，知道怎么抵达这些人，知道哪些例外决定了产品能不能真正进入工作流，知道什么时候该继续投入、什么时候该承认自己判断错了。AI 扩大的是每个人可以调动的生产能力；而生产能力越大，配置错误的代价就越依赖判断。

回到快时尚这个类比，它最重要的启示从来不是”软件也会更快”。它的启示是：生产批量和反馈周期共同决定了什么东西能够成为产品。大批量时代，企业必须先相信一个需求足够大，才愿意生产；小批量时代，企业可以先用一个很小的承诺向现实提问，再根据答案决定要不要扩大。AI 让软件第一次大规模地获得了这种提问的能力。

于是，判断软件产业的变化，可以少问一句”程序员效率提高了多少”，多问几句别的：一个需求最少需要多少用户，才值得被做成软件？第一版的成本是否低到可以纯粹用来学习？失败之后能不能安全地关掉？成功之后，谁拥有分发、信任和责任？这几个问题比代码生成比例更贴近产业变化本身。

而如果只带走一样东西，我希望是这个视角的转换：以后再看一家公司、一个部门、一个行业，不要先数它有多少代码、多少系统、多少工程师，先去问它的起订量是多少——它能为多小的一群人、多短的一段时间、多奇怪的一种例外，认真做一件东西？这个数字会告诉你，那里有多少需求正在被默默地由人扛着。

在这座突然扩产的工厂里，最稀缺的工种最终可能不是生产，而是选择：选择什么应该存在，谁愿意拥有它，以及何时让它体面地结束。