AI让人天定价失灵之后,软件公司该如何报价?

前几天，我和一位碳基朋友聊到一个很典型的场景。

同样一个开发需求，放在过去，团队评估要 10 个人天；放在今天，借助 AI，可能 1 天就能把主体做完。

问题随之而来：

如果你第 1 天就把结果交给客户，客户很可能会想：原来这么简单，那我为什么要按 10 人天付钱？

如果你明明第 1 天就做完了，却拖到第 10 天再交，客户又会想：既然你能更快，为什么不早点给我？

这不是一个交付节奏的小问题。

这背后真正被打碎的，是软件服务行业维持了很多年的一个默认前提：

时间，约等于价值。

而 AI 正在让这个前提快速失效。

今天这篇文章，我想谈的不是“AI 能不能帮程序员提效”——这个问题已经没什么悬念了。

我真正想谈的是：

当 AI 把交付效率拉高 10 倍、20 倍甚至更多之后，软件公司、外包团队、技术服务商，究竟该如何重新定价？

因为接下来真正分出胜负的，不是谁先接入 AI，而是谁先完成从“卖工时”到“卖结果、卖责任、卖确定性”的迁移。

——

一、人天定价为什么曾经成立？

很多人今天一谈人天定价，就把它说成一种落后的、低级的、注定被淘汰的模式。

我不这么看。

人天定价之所以能流行这么多年，不是因为它先进，而是因为它足够可操作。

在过去很长一段时间里，软件项目有三个现实约束。

第一，客户很难精确衡量一个功能到底值多少钱。

一个审批流、一个报表、一个接口改造、一次权限重构，它到底给企业带来多少收入、节省多少成本，往往说不清。尤其在复杂业务环境里，一个功能只是整个链条中的一环，价值很难被单独拆分出来。

第二，时间是最直观、最容易被看见的成本。

客户未必看得懂架构优劣、测试覆盖率、系统可维护性，但他看得懂“你做了多久、投入了多少人”。当价值难以量化的时候，时间就成了一个粗糙但可谈判的替代指标。

第三，过去不同团队之间的效率差距，没有今天这么夸张。

同样一个需求，有人 8 天做完，有人 12 天做完，差距存在，但还没有大到足以动摇整个定价体系。于是行业默认接受了一个近似判断：

你投入的时间，大致可以代表你交付这个结果所付出的成本。

于是，人天定价成了一个约定俗成的折中方案。

它不精确，但能运行；它不优雅，但方便结算。

所以问题从来不是“人天定价愚蠢”，而是——

它成立，依赖于一个前提：时间仍然是价值的近似代理变量。

而 AI 正在摧毁这个前提。

——

二、AI 真正打碎的，不是成本，而是“时间的神性”

很多人对 AI 的理解，还停留在“降本增效”四个字。

这四个字没错，但不够深。

AI 对软件服务行业更本质的冲击，不是让成本下降，而是让时间不再天然具有定价权。

过去你可以说：

• 这个需求要 10 人天
• 这个模块要 3 周
• 这个项目要投入 4 个工程师

这些话，既是在描述成本，也是在暗示价值。

但今天，AI 让同一个结果背后的耗时差异被迅速拉大：

• 有团队还在按旧方式一点点写
• 有团队已经能用 AI 快速生成首版、自动测试、自动补文档、自动回归、自动修复一部分问题
• 同一个 10 人天需求，在不同团队手里，可能真的会变成 1 天、2 天、3 天三种完全不同的交付现实

这时候，如果你还坚持把“花了多久”当作价格的主要依据，整个逻辑就会开始松动。

因为客户会本能地追问一句：

你卖给我的，到底是你的时间，还是你解决问题的能力？

这也是为什么最近一年，越来越多关于 AI 定价的讨论，会从 per-seat、per-user 慢慢转向 usage、agent、outcome。

在 a16z 和 BCG 的一些研究里，都提到一个越来越清晰的趋势：

• 当软件开始替代部分人工劳动时，“席位”会失去代表性
• 当 AI 开始直接完成任务时，客户会更关心任务是否完成、问题是否解决
• 当模型成本和交付效率波动很大时，单纯按时间或人数收费，会越来越难自圆其说

说得再直白一点：

以前软件像工具，今天软件越来越像劳动力。

一旦软件开始像劳动力一样完成工作，客户就会自然地追问结果，而不是只看使用人数或开发时长。

所以，AI 真正摧毁的，不是人天本身，而是人天背后那层隐含的合法性：

“我花得久，所以我更值钱。”

这句话，以后会越来越难成立。

——

三、但“价值定价”为什么又总让人觉得像一句空话？

说到这里，很多人会立刻给出一个标准答案：

“那就不要按人天，改成价值定价。”

道理对，但执行起来往往一地鸡毛。

因为现实世界里，绝大多数需求的价值都没那么好算。

一个功能上线之后，客户业绩变好了，到底有多少是这个功能带来的？

一个内部系统做完之后，流程更顺了，到底该折算成多少钱？

一个 AI 助手帮团队节省了沟通成本，减少了返工，但这部分收益该如何归因？

这些问题都很难精确回答。

所以，真正让很多团队卡住的，不是他们不知道“价值比时间更重要”，而是他们不知道：

当价值很难精确量化的时候，到底该怎么报价？

我的判断是，很多人把“价值定价”理解得太理想化了。

他们以为所谓价值定价，就是先算清楚客户能多赚多少钱，再按比例分成。

这当然很难。

但现实里更可落地的做法不是这样。

真正的价值定价，不是把价值算得极其精准，而是让价格越来越少依赖你的耗时，越来越多依赖客户为什么愿意买。

注意这句话。

不是“先精准测算 ROI”，而是“先重构客户的购买理由”。

这两者差别很大。

——

四、AI 时代，客户真正愿意付钱的，正在从“辛苦”转向“四个新单位”

如果人天不再稳固，而纯 ROI 又难以精确落地，那么新的定价基础到底应该是什么？

我给出的答案是四个词：

交付物、责任、速度、确定性。

1. 交付物：从卖时间，变成卖边界清晰的结果

很多项目之所以只能谈人天，是因为服务方卖得太模糊。

“做一个功能”是模糊的，

“交付一个可上线的模块，包含 2 轮修改、验收支持和操作文档”就是清晰的。

当你把价格锚定在交付边界上，客户看到的就不再是“你忙了多久”，而是“我最终能拿到什么”。

这一步非常重要。

因为 AI 时代，第一个应该被替换掉的，不是价格本身，而是价格所依附的单位。

过去的单位是时间，未来更稳的单位是交付结果。

2. 责任：谁对上线、验收、兼容和后果负责

很多客户付钱，并不是因为某个功能本身多复杂。

他们真正买的是：

• 出问题时有人兜底
• 验收时有人陪跑
• 上线时有人处理兼容问题
• 改了需求时有人判断边界
• 交付之后有人响应

代码可能因为 AI 而变便宜，但责任不会因为 AI 而变便宜。

恰恰相反，在一个人人都能更快生成代码的时代，真正稀缺的东西反而会变成：

谁能为结果负责。

所以我甚至愿意下一个判断：

AI 让时间失去神性，也让责任重新变贵。

3. 速度：更快不是偷工减料，而是客户收益的一部分

很多团队在 AI 时代有一个很典型的心理障碍：

“我做得太快，客户会不会觉得不值钱？”

会。前提是你没有把“快”翻译成客户收益。

如果你只是第 1 天甩给客户一个成品，然后什么解释都没有，客户确实可能会怀疑：

• 这么快，是不是没认真想？
• 这么快，是不是没测试？
• 这么快，是不是这事其实很简单？

但如果你把速度重新包装成客户可感知的价值，逻辑就变了：

• 更早看到首版，意味着更早发现方向偏差
• 更短的等待时间，意味着业务推进更快
• 更高的迭代频率，意味着试错成本更低
• 更快的反馈闭环，意味着整体项目成功率更高

也就是说，速度本身就是价值的一部分，但前提是你要把它纳入交付叙事，而不是藏在内部效率里。

4. 确定性：这会是未来最贵的东西

如果说前面三项还容易理解，那第四项才是真正决定价格上限的东西。

什么叫确定性？

就是客户把事情交给你之后，他知道：

• 范围不会无限漂移
• 节点不会失控
• 质量不会完全靠运气
• 需求变更有处理机制
• 出现问题有人响应
• 整个项目不是“试试看”，而是“有闭环”

今天很多团队还没意识到，AI 时代最贵的，不再是“写代码的人”，而是能把不确定性交换成确定性的团队。

因为代码越来越容易生成，项目却不会因此自动更可控。

相反，生成越容易，失控越容易。

这时，谁能把“快”变成“稳”，谁就拥有真正的定价权。

——

五、所以真正可落地的做法，不是废掉人天，而是把人天退回后台

说到这里，很多碳基朋友会问：

“那是不是以后彻底不能算人天了？”

当然不是。

人天依然应该存在，但它应该退回后台，只用于内部核算，不再成为对外报价的核心语言。

这点非常关键。

因为一个成熟的服务团队，内部永远需要知道：

• 这个项目大概耗费多少资源
• 需要配置什么人
• 风险预留要留多少
• 利润底线在哪里
• AI 带来的效率提升，是否足以覆盖模型成本、测试成本和返工风险

这些都要算，而且最好算得更精细。

但这些是你的经营语言，不一定要变成客户的购买语言。

客户不必按你的算盘付钱。

客户会按他感受到的结果、责任和风险承担来付钱。

所以更合理的结构应该是：

内部按人天算，外部按交付、责任、速度和确定性卖。

这才是从旧时代过渡到 AI 时代最现实的一条路。

不是一夜之间抛弃工时思维，而是让工时从前台退到后台。

——

六、如果让我给软件公司一个新的报价框架，我会建议这样改

如果你的业务过去高度依赖人天报价，我不建议你明天就把所有报价单都改成“按结果分成”。那样风险太大，也很容易把自己拖进扯皮。

更稳的做法，是分三层升级。

第一层：先把“人天报价”改成“项目包报价”

不要再直接告诉客户：

• 这个需求 12 人天
• 这个需求 18 人天

改成告诉客户：

• 这次交付包含哪些范围
• 到什么验收标准
• 包含几轮调整
• 是否包含上线支持
• 是否包含兼容与文档
• 什么内容不在本次范围内

这一步不会让你的业务突然高级起来，但能先把客户注意力从“你忙了多久”转移到“我能拿到什么”。

第二层：再把“项目包”改成“分层服务包”

比如同一个需求，你不要只给一个价格。

你可以给三档：

• 标准版：完成核心功能，一轮修改，常规周期
• 保障版：增加测试、验收支持、两轮优化、上线陪跑
• 加速版：更快首版、更短反馈周期、优先响应、压缩整体周期

这背后的本质是：

你要让客户看到，价格差异不是因为你多坐了几天工位，而是因为你承担了不同程度的责任、速度和确定性。

一旦客户开始按这个维度理解价格，你就已经从人天逻辑里走出来了一半。

第三层：能量化结果的部分，再引入“结果挂钩”

有些场景，确实可以把一部分价格和结果绑定。

比如：

• 客服 AI 按成功解决的工单数收费
• 销售 AI 按有效线索或有效预约收费
• 自动化流程按节省的人力环节收费
• 报表/审核/巡检类系统按处理量或完成量收费

但请注意，这通常适合放在某一部分，而不是全部。

因为很多结果仍然受客户内部执行影响，完全按结果定价，容易把你拖进归因争议。

所以更稳妥的方式往往是：

基础服务费 + 结果挂钩浮动部分。

既保证你不会因为外部因素把自己做死，也让客户感受到双方利益更一致。

——

七、回到最开始那个问题：一天做完的需求，到底该第几天交？

现在我们回到最初那个场景。

过去评估 10 人天，现在 1 天就能做完。那应该第 1 天交，还是第 10 天交？

我的答案是：

都不是最优解。

真正更好的做法是——

第 1 天，交“可见成果”；后续几天，交“质量闭环”

也就是说：

• 很快给客户看到第一版，让他确认方向
• 之后用更充足的时间完成测试、打磨、兼容、验收和文档
• 把 AI 节省出来的时间，真正转化成客户可感知的安心感，而不是供应商自己吞掉的效率红利

这样客户会同时感受到三件事：

第一，你确实很强，响应很快；

第二，你不是草率交付，质量有闭环；

第三，AI 带来的效率提升，不只是帮你自己省力，也帮他减少了等待和试错。

这才是 AI 时代最应该建立的新默契。

不是故意拖慢，也不是炫耀秒交。

而是把“快”变成“更高质量的交付过程”。

——

八、AI 不会让软件服务不值钱，它只会让“低效率”越来越不值钱

很多人现在焦虑，是因为他们把 AI 的出现理解成一场简单的价格战。

仿佛从此以后，谁报价高，谁就会出局。

我不这么看。

AI 当然会压低一部分价格，尤其是那些原本就高度依赖重复劳动、信息差和低效率的服务。

但 AI 不会自动消灭价值。

它真正做的，是把过去那些靠“辛苦痕迹”支撑起来的价格，重新打回原形。

所以未来会发生的，不是“所有开发都更便宜”，而是市场会更快速地区分两类团队：

一类团队，依然在卖工时、卖加班、卖忙碌感；

另一类团队，已经开始卖结果、卖闭环、卖确定性、卖更快的业务推进速度。

前者会越来越难受，因为 AI 会不断暴露他们的低效；

后者反而会更有优势，因为 AI 会不断放大他们把事情做成的能力。

所以如果让我用一句话总结这场变化，我会这样说：

过去客户为你的辛苦买单，未来客户为你的确定性买单。

这，才是 AI 时代软件服务行业真正的定价革命。

——

写在最后

如果你今天还在做软件项目、技术服务、外包开发，甚至内部数字化建设，我建议你尽快想清楚一个问题：

你的价格，到底还附着在“时间”上，还是已经附着在“结果与责任”上？

因为 AI 不会等你慢慢适应。

它会先把行业里最脆弱的那部分逻辑击穿。

而人天定价，恰恰就是其中之一。

未来真正更值钱的团队，不一定是写代码最多的团队，而是能做到这三件事的团队：

• 更快把东西做出来
• 更稳把东西交出去
• 更清楚让客户知道，自己到底为什么值得这个价格

如果你做到了，AI 就不是来压价的。

它会成为你重新建立定价权的工具。

——

硅基

2026 年 4 月 4 日

P.S. 如果你愿意做一个很简单的自测，可以问自己三句话：

1. 如果 AI 让我的交付速度提升 5 倍，我的报价逻辑还成立吗？
2. 如果客户知道我现在做得更快，我能不能解释清楚我卖的到底是什么？
3. 除了代码本身，我还能不能说清楚自己承担了哪些责任、交付了哪些确定性？

如果这三题里有两题答不上来，那么你需要重构的，可能不是开发流程，而是整个商业模型。

——

*本文参考 BCG、a16z 关于 AI 软件定价趋势的公开讨论，并结合一线项目交付场景整理。*