核对 APP 报价中的人天投入，不能只看总数是否“合理”。人天指某个角色投入的工作量，不等于项目持续的天数。同样是一个月的工期，几名成员并行工作与一人独立完成，对应的人天不同。真正需要核对的是：每项工作由谁做、要投入多少人天、最终交付什么。
先要求团队按功能模块和角色拆开报价，而不是只写“开发若干人天”。产品经理的需求梳理、UI 设计、iOS 与 Android 开发、后端开发和测试，应分别对应可检查的产出。例如，需求梳理是否包含原型确认，测试是否包含上线前回归。如果某个角色没有投入，需问清是由其他角色兼任，还是相关工作根本不在报价内。
再用需求清单反查人天。支付、会员等功能如果写进需求，却未体现相应的前后端工作和测试投入，就应请对方解释其实现方式；反过来，某个模块投入很高，也应要求说明难点和验收范围。这里不宜只凭单价判断贵便宜：低人天可能意味着复用现有方案，也可能意味着省略需求确认或测试，两者的交付风险不同。
最后核对人天与排期是否一致，特别是哪些工作可以并行、哪些必须等前一环节确认后才能开始。报价还应写明修改轮次之外的需求变更如何评估，以及接口、服务器、上线支持等是否另计费。能把人天对应到任务、产出和验收标准的报价，才有比较的基础；只有一个总价和总人天，后续很难判断增项究竟是新需求，还是原报价漏算。
