Article
不少企业做 AI 项目，前半段都在聊模型、知识库、提示词，真正到上线前才发现最麻烦的不是“答得准不准”，而是 AI 到底能不能改数据、发通知、提单据、改状态、触发下一步流程。这个边界如果一开始没定清，后面系统会越来越像一个谁都不敢碰、谁也说不清责任的半自动黑箱。
发布时间
2026年4月10日
阅读时间
7 分钟
企业系统
读知识、查资料、给建议，这类 AI 能力通常比较容易试点，因为错了最多是不采纳。但一旦它开始往内部系统写回内容，事情就完全变了：一条错误状态、一个错误审批建议、一次误发通知，都会直接影响业务流转。很多团队前期把注意力都放在“先接上模型”，等到要和 ERP、CRM、工单、审批流对接时，才发现风险控制根本没设计。
我现在更倾向于把 AI 项目分成两层：一层是“只读辅助”，另一层是“可执行动作”。前者重点是上下文质量和回答边界，后者重点则是权限、责任、可回滚和人工确认。两层不拆开，系统很容易在 demo 阶段看起来很聪明，到了正式运行阶段却没人敢真正放权。
很多项目最容易犯的错，是把“AI 可以推荐下一步”直接滑成“AI 可以直接做下一步”。这中间差的不是一步技术实现，而是一整套责任设计。比如客服工单分类、采购异常判断、报价草稿生成，这些场景里 AI 给建议通常问题不大；但如果直接改工单优先级、直接发报价、直接把异常单转成处罚或补单，就已经进入执行层。
真正稳的做法，是把系统动作按风险分级。低风险动作可以半自动，中风险动作需要人工确认，高风险动作则只允许 AI 给建议不允许写回。先把这个分层写清楚，后面的接口设计、按钮文案、日志追踪和权限模型才不会一团乱。
建议型输出和执行型输出必须分开设计
不要把“能调接口”误当成“适合自动执行”
风险分级先定，产品形态和交互才能稳
只要 AI 会往系统里写数据，就不能只记“模型返回了什么”，还要记“最后是谁让它生效的”。很多团队会做操作日志，但日志里只有一条“AI 已执行”，这其实不够。真正出问题时，业务方要问的是：这是系统自动执行的，还是某个角色确认后执行的？确认时看到了哪些上下文？为什么会通过？
这也是为什么我不建议一开始就追求全自动闭环。与其上线一个责任模糊的自动系统，不如先做成“AI 预填 + 人工确认 + 留痕执行”。这听起来没那么炫，但更适合企业环境。因为企业系统不是聊天窗口，很多动作最后要落到账务、库存、客户记录和审批责任上。
日志里要区分 AI 建议、人工确认、系统落库三个时点
关键动作需要记录操作者、审批者和触发上下文
企业内部系统优先要的是责任清晰，不是自动化表演
很多 AI 项目一开始都默认“执行成功”是主路径，却很少认真设计“执行失败怎么办”。比如 AI 自动整理客户信息后写进 CRM，如果字段映射错了怎么办？AI 自动生成采购建议后推送给供应链，如果数据口径过期怎么办？AI 自动改工单状态后触发了别的流程，发现判断错了还能不能撤回？这些问题不在第二阶段，而在第一版就该想清楚。
我一般会要求团队至少回答三件事：写错了能不能撤，撤了之后谁补，系统怎么提示异常。如果这三件事回答不出来，那就说明这个动作还不适合交给 AI 直接写回。不是因为模型不够先进，而是系统还没有准备好承担错误成本。
AI 接内部系统时，最大风险往往不是回答效果，而是写回动作的责任和边界不清。
建议型与执行型动作必须分层，高风险动作不要一开始就放给 AI 自动执行。
日志、审批、回滚和人工兜底，应该和接口一起设计，而不是上线后再补。