大模型接入企业系统的演示往往很顺，因为问题和资料是提前准备的。真实使用里会出现模糊提问、旧版文件、接口超时和权限不足，工程能力就体现在这些不顺的地方。
先问系统解决哪一步
大模型接入企业系统不是为了把纸面或聊天记录换成电子页面，而是要减少一段真实工作。API接入前先做数据分级解决的是哪一步，完成后谁少做了什么，不要把业务规则交给模型记如何判断结果，应该在立项时说清。否则系统上线后只能用‘功能都做了’解释价值。
评审要允许一线人员说不
业务负责人、知识维护人、系统接口负责人和信息安全人员中，真正每天操作的人经常最晚看到方案。他们会发现字段太多、步骤不符合现场、异常没有入口。让关键用户在原型阶段提出反对意见，远比上线后抵触系统便宜。 对本篇关注的“API接入前先做数据分级”与“不要把业务规则交给模型记”而言，这个细节会直接影响后续判断。
权限不是最后再加
上下文要最小化和写操作必须可审计一旦涉及不同部门或外部用户，权限就要进入数据层和接口层设计。只在页面上隐藏按钮，看起来完成了权限，实际上数据仍可能被越权读取。
API接入前先做数据分级
公开资料、内部一般信息、商业机密和个人敏感信息不能用同一策略。不同级别决定是否脱敏、是否允许外部模型、日志保存多久。
不要把业务规则交给模型记
折扣上限、审批条件、库存扣减等确定性规则应由系统代码执行。模型适合理解语言、提取信息和组织答案，不适合替代核心规则引擎。
上下文要最小化
每次只提供完成当前任务所需的数据，既降低费用，也减少泄露风险。把整份客户档案和所有合同都发给模型，是最省事但最危险的做法。
写操作必须可审计
模型创建工单、发送邮件或修改客户标签时，要记录用户指令、模型参数、最终动作和结果。关键动作应支持人工确认和撤销。
模型切换能力要预留
不同模型在成本、速度和能力上变化很快。业务层不要直接绑定某一家模型接口，应通过统一网关管理模型、配额、超时和降级。
从企业数字资产角度，APP 定制开发、小程序定制、web 开发、企业软件定制开发、agent 开发和 3D 元宇宙平台开发不是六个互不相干的项目。大模型接入企业系统产生的客户、商品、订单或知识数据，应能被后续系统继续使用。
先保住主流程，再谈完整
大模型接入企业系统第一期最容易因为追求完整而拖延。与其同时把API接入前先做数据分级、不要把业务规则交给模型记、上下文要最小化做得很复杂，不如先确保主流程可用、后台能处理、数据可追踪。低频例外可以先人工兜底，但必须留记录和后续改进入口。
把技术问题翻译成经营后果
讨论写操作必须可审计时，企业负责人不必研究所有技术细节，但要知道选择会影响什么：是否增加长期费用、是否限制扩展、故障时是否可恢复、换团队能否接手。技术方案只有能转成这些后果，才便于决策。
上线后的真实成本
系统运行后的成本包括维护、云资源、第三方服务、内容或知识更新和内部运营。持续观察无答案、错误引用、工具调用失败、人工接管率和单次任务成本，可以判断成本是在替代人工、减少错误，还是只是增加一套需要额外照看的工具。 放到“API接入前先做数据分级”这一具体问题中，企业需要把责任和验收方式写得更明确。
如何判断系统真的有人用
不要只看登录人数。应观察用户是否完成了核心任务、后台是否减少了人工补录、写操作必须可审计相关异常是否更快处理，以及一线人员是否仍在系统外建立自己的表格。真正使用会留下流程和数据痕迹。
第一期哪些东西不能省
围绕大模型接入企业系统，身份与权限、核心数据结构、主流程、异常记录和基本运维不能省。API接入前先做数据分级可以先做简化规则，模型切换能力要预留可以降低展示复杂度，但不能留下无法追踪的数据。第一期的目标不是功能最多，而是后续还能继续做。
维护不是上线后才想到的事
大模型接入企业系统从立项开始就应维护一份运行台账，至少记录知识版本、模型配置、评测结果、工具调用日志和人工修正。台账不必做得复杂，但要能回答当前线上是什么版本、最近改过什么、出现问题由谁处理。等故障发生后再翻微信群，通常已经来不及，也很难判断哪条信息有效。
运营成本也要在立项时估算
企业评估大模型接入企业系统时，不能只看一次性开发费。模型调用、知识维护、接口运维、评测抽检和安全审计都会在系统运行中持续发生。报价单最好区分首期建设、第三方资源、年度维护和新增需求，让管理层知道哪些支出会随用户量或业务量增长。
上线切换不要一刀切
大模型接入企业系统正式上线前，建议先在一个知识域和一类任务中试点，保留人工复核，评测稳定后再开放更多工具。试运行阶段允许人工补救，但每次补救都要记录原因，判断是培训、数据、流程还是技术问题。没有过渡期，所有问题会在同一天集中爆发。
把交接当成正常情况设计
可以假设原项目经理或核心开发下个月离开，再检查API接入前先做数据分级、不要把业务规则交给模型记和上下文要最小化是否有文档、账号和操作记录。系统若只能由熟悉历史的人维护，就仍然是个人经验的延伸，不是企业真正可控的数字资产。
资产归属要在付款前说清
大模型接入企业系统合同应把数据范围、知识来源、模型服务、工具接口、权限、日志、测试集、人工确认与优化周期逐项写清，并说明API接入前先做数据分级和不要把业务规则交给模型记的验收口径。凡是写成‘按需提供’‘后续协商’的关键资产，交付时都容易出现不同理解。验收最好使用企业自己的账号和真实数据，必要时做独立部署或故障演练，证明系统不依赖某个人的电脑和记忆。
回到大模型接入企业系统这件事，签约前多花半天把这些问题问清楚，往往比后期多加一个功能更有价值。软件项目没有完全不变的需求，但可以有清楚的边界、记录和取舍。
