硬条件一：数据能出内网吗
不能出内网，基本只剩自建或专有部署；能出但要分级，则按数据类型分流。这一项不要用应该可以回答，要让信息安全出具书面口径，否则方案会在评审阶段被推翻，返工代价很高，工期也保不住。为什么这一项不能含糊，因为它决定方案能否通过评审。
硬条件二：有没有人维护
自建需要能部署推理、看监控、跟补丁的人；没有就选托管或专有实例。判断方法很直接：写下三个具体岗位与姓名，写不出来就是没有，别用到时候招人糊过去，那通常是最贵的选项，也最容易失控。怎么确认人力，写岗位与工时，而不是写应该有人。
条件三：并发、延迟与微调
峰值并发高、延迟要求严，推理优化与扩容要提前设计；需要微调或蒸馏时，开源的可控性更有价值。把这三项写成数字目标，才能比较不同形态的可行性，否则讨论会停在感觉层面，谁也说服不了谁。怎么量化，把并发、延迟写成目标值，再谈形态。
条件四：许可证与商用边界
核对权重、配套组件与依赖的许可证，确认商用、分发与署名的要求；对外提供服务时还要看备案与标识要求。结论要落成书面文件，附在方案后面备查，而不是留在某人的聊天记录里。怎么留证，结论附在方案后，注明依据与日期。
条件五与六：锁定与版本节奏
闭源要评估涨价、条款变更与停服风险，保留可切换的抽象层；开源要评估自己跟版本的能力。两项都指向同一件事：把退出方案写进合同与架构，而不是等出事再想，那时议价空间已经很小。怎么设计退出，先留适配层，再谈价格与条款。
适用与不适用
适合谁
- 正在写选型报告、需要依据的架构师
- 需要与信息安全、法务对齐口径的项目
- 用量大、正在评估长期成本的企业
不适合谁
- 只想比较单价、不愿回答数据与人力问题的采购
- 没有明确业务场景、为技术而技术的团队
典型场景
某医疗器械企业的客服系统要升级。清单过一遍：售后记录含个人信息，不能出内网；运维只有两人，且都没有推理优化经验；峰值并发不高、延迟要求宽松；需要按产品线微调术语。结论是选专有部署形态，保留自建作为二期选项，并把版本锁定与退出条款写进合同。
可执行步骤
- 让信息安全出具数据出域口径的书面结论，并由负责人签字并留档确认
- 写明运维岗位、姓名与每月可投入工时，缺口写清楚补法与预算来源
- 把峰值并发、P95 延迟与微调需求量化成可验收目标与抽检方式
- 核对许可证与备案要求，形成书面结论附在方案后面备查与归档位置
- 写清退出方案、导出格式与可切换的抽象层，并指定负责人与时间表
常见坑
- 数据口径靠口头确认，评审时信息安全提出异议，方案推倒重来，工期至少延后一个月，预算也要重报。
- 运维人力按兼职即可估算，上线后无人跟补丁，安全通报来了才发现没人处理，只能临时外包。
- 许可证只看权重，忽略配套组件，商用后发现条款冲突，被迫替换组件，接口也要跟着改。
- 合同没写退出与导出，想换供应商时数据与配置拿不走，只能继续续约，价格也由对方定。
自检与验收清单
- 数据出域口径是否有书面结论并签字，并由双方确认
- 运维岗位与每月工时是否落实到人，与月度考核挂钩
- 并发、延迟与微调目标是否量化成验收项条目
- 许可证与备案结论是否留档可查可复核与验证
- 退出方案与抽象层是否写进架构文档并经过评审
常见问题
清单里的硬条件能妥协吗？
数据与人力两项不建议妥协。它们决定系统能否长期运行，而不是上线那天的效果；妥协的结果通常是上线三个月后停摆，届时切换成本更高，团队也会被拖住，前面省下的钱都要吐回去。
专有部署算开源还是闭源？
算闭源的一种形态：模型不开放权重，但部署在指定环境。它能缓解数据边界问题，条款仍需逐条核对，尤其是日志、版本与退出安排，别把它当成自建的替代品，也别当成万能的折中。
要不要同时评估两条路线？
建议至少各留一个候选，用同一批任务做对照。只评估一条路线，等于放弃谈判空间；两条都有数据时，价格与条款的讨论会务实很多，评审也更容易过，后续切换也有参照。与参照。