2026 年谈软件外包报价，最容易吵起来的一句话是：「你们都在用 AI 写代码了，人天单价怎么还不降？」这句话吵不出结果，是因为双方对「哪一段变便宜了」没有共识。本文只讲一件事：AI 提效之后，人天单价这个计价单位还站不站得住，以及三种计价口径分别把钱和风险放在谁身上。成本构成怎么拆、开发路线怎么选，可以看AI 软件开发外包的 2026 年成本拆解与计价模式风险，本篇不重复。
优码云是深圳的软件定制开发团队，我们自己每天都在用 AI 编码工具，也持续被客户问同一批问题。下面这些数字都附了原始来源，判断和坑来自真实报价场景。
人天单价在 2026 年还成立吗：先分清哪一段变便宜了
一个软件项目的工时不是均匀的一块，它大致分成需求澄清、方案与技术验证、编码、联调、验收与上线几段。AI 编码工具真正压缩的是编码这一段，而且是压缩「写出第一版」的时间，不是压缩「写对」的时间。
这一点有实测支撑。METR 做过一次随机对照实验，让资深开发者在他们长期维护的开源仓库里完成真实任务，结论是使用 AI 工具时完成任务耗时反而比不用时延长 19%。原因不神秘：成熟代码库里，读懂上下文、判断改动影响面、跑通验证的时间远大于敲代码，而 AI 生成的代码反而增加了评审负担。这份实验测的是特定时期的工具与特定类型的仓库，METR 自己也说明后续工具版本已更新，但它指出的结构性问题没变——提效不均等地落在各段工时上。
组织层面的观测也一致。据 DX 对数百家组织、跨一年多的工程速度数据统计，AI 编码工具带来的 PR 吞吐量中位增幅只有个位数百分比——是真实存在但并不剧烈的改善，远谈不上翻倍。同一份数据还揭示了一个容易被忽略的事实：工具侧的钱并不便宜，单开发者的席位加 token 消耗合起来，往往远高于席位标价本身。
把这几条放在一张报价单上看，结论就清楚了。编码段工时在降，幅度是量级可观测的、非爆发式的；工具侧支出是每月持续发生的现金成本；而需求澄清、联调、验收、上线这几段工时几乎没有变。所以「人天单价该不该降」这个问法本身有偏差，更准确的问法是：降的是哪一段，省下来的时间和多出来的工具费分别记在谁账上。
三种计价口径对照：钱按什么算，风险归谁
2026 年市面上的软件外包报价，基本落在三种口径里，或者三者的组合。它们的差别不在数字高低，而在价格锚点和风险归属完全不同。
| 计价口径 | 计价单位 | 价格锚点 | AI 提效收益归谁 | 主要风险落在谁身上 |
|---|---|---|---|---|
| 传统人天 | 人 × 天 | 岗位级别与地域人力成本 | 供应商：工时减少即利润增加 | 客户：工时虚报、范围蔓延时无锚点 |
| AI 增强人天 | 人 × 天，工具费单列 | 岗位级别 + 许可与调用成本 | 双方按事先约定的提效假设分享 | 共同：提效假设事后难验证 |
| 按模块 / 按结果 | 可验收的交付物 | 同类模块的市场成交价 | 供应商：提效越快利润率越高 | 供应商：估错范围自己承担；客户：需求变更代价高 |
传统人天的问题在 2026 年变得更尖锐：AI 让编码段的实际耗时下降，但报价单上的人天没动，客户会觉得自己在为供应商的效率红利付费。供应商也确实有话说——工具费、评审成本、以及提效不覆盖的联调验收段都还在。
AI 增强人天是这两年最常见的折中做法：人天单价里不含工具成本，许可与 token 消耗单列成一行，同时约定一个提效系数，把编码段的估算工时有条件地下调。这行的关键在「有条件」三个字——系数绑定在哪些模块类型、哪些技术栈、是否包含存量代码改造，必须写清楚，否则签约时的折让就变成了无条件的价格承诺。口径本身也还在被模型能力推着变，可参考模型能力跃迁改写外包规则里对下半年成本变量的判断。
按模块或按结果计价对客户最省心，但它不是万能解。它把范围估算风险转移给了供应商，代价是供应商会在报价里加风险溢价，且需求边界一旦模糊，变更谈判会比人天模式更激烈。行业里按结果计价的占比在上升，混合口径（底座按人天、功能按结果）逐渐成为主流，可参考 Outcome-based pricing: a practical guide 对这几类结构的梳理。对客户来说，判断口径好坏的标准只有一个：出问题时，谁承担返工成本。
一张合格报价单该写什么
口径选完，落到报价单上还有六项必须写清。这六项缺失，任何一种口径都会在中期变成扯皮现场。
- 工时估算依据：不是一句「约 X 人天」，而是按模块拆到人天级的 WBS，标注每一项目前是「编码段」还是「澄清 / 联调 / 验收段」。
- 提效假设的适用范围：编码段打了几折、依据是什么、哪些模块不适用（存量系统改造、老框架迁移、涉及第三方封闭接口的模块通常不适用）。
- AI 工具成本归属：模型调用费、IDE 席位费、私有化部署的推理资源，是含在人天单价里、单列实报实销，还是设一个封顶额度。
- 返工责任划分：需求理解偏差导致的返工与质量缺陷导致的返工，承担方不同，必须分开写。
- 验收标准与判定方式：可执行的验收用例集、谁执行、争议时以什么为准。缺少这一项，提效省下来的时间会在无限返工里全部吐回去。
- 变更单价与响应时限：新增需求的人天单价、评估出结论的时限、超出多少幅度需要重新走合同。
这六项里，客户最容易忽略的是第二项和第三项，供应商最容易含糊的也是这两项。因为它们是 AI 提效之后新增的变量，而大多数报价模板还是几年前的版本。合同层面怎么加防线，可对照AI 软件开发外包合同条款与隐性成本转移那份清单逐条核。
客户侧怎么验算：三步倒推法
验算不需要看懂代码，只需要会做减法。下面三步在评标阶段半天就能做完，能把大多数不靠谱的报价单筛出来。
第一步：要一份能对着看的 WBS
要求供应商把工时拆到模块级，并标注每项属于哪一段。拆不出来的报价单，本质上是在卖一个总价猜测。拿到 WBS 后，把编码段工时单独求和，其余部分求和，两组数字的比值就是这份报价的「结构性假设」。
第二步：用两三个已交付模块倒推
挑两三个你熟悉、或者供应商已公开演示过的模块，问它当初实际花了多少人天，再看新报价里同类模块给的人天。差额就是它宣称的提效幅度。若这个幅度远高于行业观测到的中位水平，就要它说明：省掉的到底是编码时间，还是把评审和联调时间也一起算进去了。
第三步：把工具成本加回去看总账
把人天金额加上单列的工具费，再除以交付物数量，得到「单位交付成本」。三种口径只有在同一张总账上才可比较。很多看起来更便宜的人天单价，加上工具费和变更单价之后，总账并不便宜；反过来，按结果计价的报价偏高，往往买的是范围风险。
四个常见坑
坑一：把提效系数当成无条件折扣承诺
「AI 提效，全单打折」是最危险的表述。提效只发生在特定段、特定模块类型上，写进合同的无条件折扣，供应商只能用两种方式消化：压缩测试与评审投入，或在变更环节找回来。两种都由客户最终买单。
坑二：把模型调用费混进人天
模型调用费是随用量走的现金成本，人天是人力成本，混在一起的后果是两边都无法审计。客户不知道自己在为多少 token 付费，供应商也无法证明自己没在用人天补贴调用费。正确做法是单列，设封顶，按月对账。
坑三：验收标准缺失导致无限返工
没有可执行验收用例的项目，返工次数取决于双方的耐心而不是质量。AI 生成的代码更容易出现「看起来对、边界错」的问题，这类缺陷恰恰需要用例来暴露。报价单里没有验收用例集，等于把返工风险默认给了客户。
坑四：变更口头议价
「这个先做着，后面一起算」是外包项目最常见的成本失控起点。变更单价必须提前写进报价单，并且写清评估时限——需求提出后几个工作日内出评估结论。没有这条，每一次口头加需求都是一次议价能力的裸奔。
常见问题
AI 提效之后，人天单价应该降多少才算合理？
没有一个可以照抄的比例。提效只作用于编码段，而编码段在整体工时中的占比因项目类型差异很大：标准化 CRUD 类业务占比高，涉及存量系统改造、硬件联调、第三方封闭接口的项目占比低。判断标准不是降了几个点，而是供应商能不能说出降的是哪一段、哪类模块不适用。
按人天和按项目，哪种更适合我们？
需求边界清晰、可拆成独立可验收模块的，按模块或按结果更省心；需求还在探索期、方向可能调整的，按人天更灵活，但必须配套变更单价和 WBS 拆分。多数中型项目的现实选择是混合：底座与咨询按人天，功能模块按结果。
供应商说用了 AI 所以要收工具费，这笔钱该怎么核？
要它给出工具清单与月度账单口径，明确是席位费还是按量计费，并约定封顶。工具费本身是真实成本，不该被当成隐藏利润项；但它也不该被重复计入人天单价。两处都收，就是同一笔钱付了两次。
报价单里没写提效假设，是不是就一定有问题？
不一定有问题，但一定缺少可比性。没有提效假设的报价单无法与另一份带假设的报价单对比，你只能比总价，而总价里藏着完全不同的范围定义。补这一行不需要改合同结构，一封补充邮件就能解决。
下一步
如果你手上正有几份口径不同的报价单，最有效的动作是把它们的 WBS 与计价条款摊在同一张表上做一次对照。我们提供这项对照，也提供深圳与粤港澳大湾区范围内的现场沟通，可以从 联系我们 开始；想先看交付物形态的，可以先浏览已公开的案例页面。