一份可评估需求至少说明什么？
- 用一段话说明谁使用、解决什么问题、当前卡在哪里，再列出必须跑通的关键流程。附可公开的资料目录即可，首次沟通不必传完整工程，更不要发送涉密或无权分享的数据。
- 明确交付形态：报告、模型工程、软件、源码、部署包还是组合。说明目标操作系统、离线要求、协同人数和已有工具版本，避免报价后才发现关键环境约束。
哪些因素容易增加工作量？
- 原始数据质量不明、多系统接口未冻结、商业组件授权受限以及验收工况持续增加，都会影响估算。复用资产也需要核对版本、权利和适用范围，不意味着零成本接入。
- 把许可、算力、第三方服务、硬件联调和现场支持分别列项，说明由哪方提供。不同方案只有在同一交付范围和验收口径下才有可比性。
如何用试点降低不确定性？
- 选取有代表性的最小闭环，先验证数据、模型和接口是否可用。试点应有自己的验收标准，同时记录尚未覆盖的系统规模和复杂工况。
- 将后续阶段设为可单独评审的里程碑，范围变化时更新输入、交付与周期，而不是把所有新增要求都隐含在原报价中。
如何理解性价比与源码交付？
- 性价比应结合可复用资产、沟通成本、维护能力和验收结果综合判断。团队以目标比例指导复用评估，具体经费与周期根据项目范围确定。
- 源码交付需要说明自研部分、第三方库、数据与媒体许可，以及接收方可修改和再分发的范围。仅获得仓库副本不等于获得所有依赖的商业授权。