两份方案书的目录页各圈了一遍：一份到操作系统为止，另一份圈进了知识库和权限管理。两份报价差的那截，差的其实是架构层次，价格只是结果。

一、交付清单是一个分层架构问题

一套能用的私有化大模型，可以拆成五层：硬件、操作系统与驱动、模型管理（接入、路由、调用记录）、知识库（导入、切分、检索、更新）、权限与统一管理。评审方案书时，每一层都应该被标成"本次包含"“不包含"或"客户自备”。

常见反例是硬件层写得极细，往上几层只有一句"支持知识库"“支持权限管理”。这不是文字问题，是交付边界问题——边界没画清，实施阶段就会出现"知识库要另采购、权限要自己开发"的缺口，架构图上少一层，账本上多一笔。

二、算力口径是一个可验证性问题

"配置若干张加速卡"这类描述，问题在于它不可验证。算力估算至少依赖四个变量：模型规模、并发人数、响应时延、单次输入输出长度。条件不写明，配置就没有依据，验收就没有锚点。

工程上合理的做法是让测算条件进入合同，并约定在该条件下做一次现场测试作为验收依据。上线后用户排队时，双方至少有同一个分母可以对话。

三、数据落点是三类资产的管理问题

私有化部署的价值，很大程度在于数据留在可控范围内。要分三类看：原始文档、知识库向量数据、调用与问答记录。每一类都要回答四个问题：存在哪、存多久、谁能导出、合同结束后如何移交或销毁。

典型的坑是文档在本地、调用记录回传服务商平台，或者向量库格式封闭导致换服务商迁不走。平时看不出来，审计、离场、安全检查时全部暴露。涉及个人信息或重要数据的，还要对照数据安全法、个保法与等保2.0 的要求自查一遍（具体合规判断请留给法务）。

四、复核边界即责任边界

在法律、财税、金融这类专业场景，AI 的职责范围应该写死：资料整理、初步审核、风险标记与提示；关键判断与签字确认归专业人员。系统层面要支持记录复核人和复核结果。

这一条翻译成架构语言就是：责任边界要落在系统记录上，而不能落在口头约定上。出了差错，回溯链路必须完整。

五、运维交接决定系统的生命周期

上线只是起点。告警谁接收、升级谁来做、故障响应时限是多少、知识库谁更新、账号权限谁维护，这些要写进方案。交接材料至少包括：部署文档、账号清单、配置说明、常见故障处理手册，以及客户方需要配备的人员和技能清单。

服务商撤场后系统慢慢闲置，多数不是技术问题，是交接问题。

收尾：一张三态核对表

把上面五条加上模型清单与授权（模型名称版本、商用授权、更换是否重签），整理成一张表，每项勾三种状态：已写明、口头承诺、未提及。备注栏记原话或页码。口头承诺和未提及越多，后期变数越大。最后把口头承诺集中成清单，请对方逐条确认能否写进合同附件。

方案书里没写的部分，往往就是后期要补钱的部分——这句话送给每一个准备在合同上签字的人。