客服主管把一批工单导出，让模型改写回复。读起来顺畅，语气也像样。可到了上线前，会议室反而安静了：工单里出现的地址、电话、订单备注，哪些能进上下文；模型写偏了，谁在发送前拦住；模型版本一换，上次的结果怎么复现。这些笨问题不解决，试用越顺，后面越难收。
输入边界不是一句脱敏就结束
企业工单常夹着客户信息、内部备注和历史沟通。AI大模型拿到越多上下文，回复越容易贴题，但上下文也越容易越过数据边界。与其在提示词里反复叮嘱，不如先把字段分级：哪些字段可进入模型，哪些必须留在系统内，哪些要截断或替换。白名单、字段脱敏、日志留存，这些看起来像基础活，却决定项目能不能持续。模型看不到的字段，靠提示词补不回来；模型不该看到的字段，也不该靠运气。
输出错了，流程里要有停的地方
工单回复不是纯文本，它可能包含时效承诺、责任说明和后续动作。模型可以起草，但不该直接发送。草稿与发送分离，关键字段由系统回填，输出附上依据片段，失败时回退模板——这些不是复杂架构，而是给错误留一个可回滚的位置。AI大模型在工单里更像文本加工层，不适合承担最终承诺。企业需要回答的不是模型能不能写，而是写完之后，哪一步必须由人确认。
版本变化会让上次能用变成一句空话
模型更新、提示词调整、上下文截断策略变化，都会改变输出。若没有留下输入样本、提示版本、模型标识、输出结果和人工修改记录，出现争议时只能凭记忆。可追溯性不性感，但它是把试用转成生产的前提。刚开始不必铺大，选低频工单类型做小流量灰度，把异常样本收回来，比急着扩大范围稳妥。
别把会写当成会判断
模型能生成顺畅回复，不代表理解业务约束。工单系统里很多规则藏在字段和状态里：待补件、处理中、已关闭。这些状态应由系统判断，模型只负责表达。把状态判断交给AI大模型，等于把确定性问题变成概率问题。比较稳妥的分工是：规则留在系统层，表达交给模型层，中间用结构化接口连接。这样即使模型输出有偏差，业务状态也不会被改坏。
回到那间会议室，三个笨问题其实指向同一件事：先把边界、责任和回滚写清楚，再谈体验。AI大模型可以进工单系统，但不该以先上了再说的方式进。谨慎不是保守，是让试用的顺畅有机会变成稳定的日常。