两种计价方式的差别，本质上是风险放在谁那边。

按人天结算，甲方按投入的实际工时付费，单价相对透明，人也看得见。它的好处是需求变动时不用重新谈判，改多少算多少；坏处是总价开出来之前永远不确定，需求边界模糊时账单容易失控。这种方式适合方向还在探索、业务规则会随市场调整的项目，还有一些需要长期迭代、分阶段推进的系统。

按功能模块报价，甲方拿到的是相对确定的总价，心里有底，方便做预算审批。它对需求文档的要求高，功能清单要拆到能对应后端接口与数据表这个颗粒度，否则模块边界模糊，报价差异会非常大。适合业务逻辑稳定、功能项可以清晰枚举的项目，比如会员体系、订单流程、对账模块这类边界比较清楚的板块。

行业里常见的折中做法是混合计价：主体功能按模块包干，增量需求按人天另算，同时在合同里约定变更流程，需求确认之后新增的内容要书面提出、评估工时、双方签字再开工。有数据显示，需求变更导致的额外工时在软件项目里的占比通常落在两成到三成半之间，把变更流程写清楚，比在报价上压几个百分点更管用。

报价的透明度也值得看。同一份人天报价，背后可能是不同角色的组合，架构设计与初级编码的单价不应混为一谈，报价单里列明角色、单价与预估投入，后续核算才有依据。付款节点建议与可验证的交付物绑定，原型确认、测试通过、上线验收分别对应一笔，比按时间平均切分更能约束进度。

验收标准怎么写进去？建议分三层。功能层对着需求文档逐条核对，注明以哪个版本的文档为准；性能层写明并发数、响应时间、可接受的错误率范围，以及测试环境的配置；交付层写明源代码、数据库结构、接口文档、部署说明的移交清单，以及部署验收的操作步骤。含糊的表述像"系统稳定""运行流畅"这类，不要往合同里放。