01 / 从用户任务拆解范围
“做一个智能客服”不足以估算。需要明确渠道、语言、知识来源、允许调用的业务系统、人工转接方式与安全要求。每个任务对应可演示的验收场景。
将必须上线的能力与后续优化分开，优先验证最容易影响整体可行性的依赖。
把每个任务写成角色、输入、动作和预期结果，例如“门店负责人查看本店预约并取消未支付记录”。同时标注权限、异常和兼容要求，这些内容通常比主流程页面数量更影响工作量。
02 / 把外部依赖写成假设
支付商户资质、第三方 API 权限、历史数据质量和客户验收时间都会影响进度。报价中说明哪些由交付团队负责，哪些需要客户或平台配合。
不确定的接口先做小规模技术验证，再给出实施区间。无法验证的依赖应设置缓冲及替代路径。
为每个假设设置确认日期和责任方。外部接口未开放时可以先做契约模拟，但最终验收必须在真实授权环境中完成；模拟开发完成不应被表述为第三方集成已经可用。
03 / 按交付物建立里程碑
需求阶段交付范围清单与验收条件；设计阶段交付原型与接口契约；实施阶段交付可运行版本和测试证据；上线阶段交付部署、监控与交接材料。
每一阶段都能独立复核，付款与验收规则提前约定。范围变化记录影响、费用和时间后再执行。
将估算分为已知工作、技术验证和风险预留，写清楚各自消耗条件。里程碑评审不仅看已完成的页面，还要检查剩余依赖是否变化，及时调整后续范围而不是压缩必要验证。
04 / 把维护和所有权算进去
预算包含代码仓库、构建流水线、依赖许可证、账号归属、故障响应及知识转移。能部署一次不代表客户团队可以长期维护。
本文不提供统一人天价格；实际估算应建立在已确认的范围、团队配置和交付风险上。
交接演练让接收方在文档帮助下执行一次部署、配置变更和恢复操作。发现必须口头传授的步骤后补入文档，账号与密钥通过正式移交机制处理，不放进源码或操作截图。
- 范围对应可演示的角色与任务。
- 外部依赖有责任人和确认日期。
- 每个里程碑列出交付物、验收条件与变更规则。
项目交付工程治理
