试用一个模型时，很多人会拿它润色邮件、改一段说明，结果看起来像样。真正接进工单、知识库和审批流之后，麻烦才出现：它不知道上一环节改了什么，也说不清依据来自哪份材料。问题不在“会不会写”，而在它能否被放进一条有状态、有约束的流程里。
流畅，并不等于可交付
大语言模型的基本能力，是在给定上下文里预测接下来更可能出现的文本。这让它在局部表达上很顺，却也意味着它并不天然掌握流程状态。你让它总结一份文档，它可以做得不错；你让它根据三天前的变更、当前权限和未关闭的工单来回复客户，它就需要有人把“此刻发生了什么”整理清楚再交过去。
不少团队把“能对话”当成“能执行”，于是把接口一接，期待它自己串起系统。结果往往多出一层人工核对：员工先复制上下文，再判断回答是否可用，最后还要回到原系统操作。省下的时间，被新的搬运和检查吃掉了。
上下文不是越长越好
遇到答非所问，常见反应是把更多资料塞进提示词。但上下文变长，不等于相关性变强。过期制度、无关段落、互相冲突的口径，都会让输出更不稳定。与其把整本手册一次交过去，不如先想清楚：这次任务真正需要哪几段事实，哪些字段必须来自实时系统，哪些内容不应让模型看到。
权限问题也常被低估。模型能读到什么，取决于喂给它的材料；如果检索环节没有做好隔离，它可能把不该出现的内容带进回答。这里更稳妥的做法，是把检索、权限和生成拆开处理，而不是指望一句“不要泄露”解决全部问题。
评估要贴着任务走
讨论大语言模型是否好用，容易变成主观感受：有人觉得表达自然，有人觉得废话太多。更有意义的评估，是把它放回具体任务，看输出能否被直接使用，出错时能否被发现，修正成本有多高。
- 任务边界是否清楚：输入是什么，输出交给谁，什么情况下必须转人工。
- 错误是否可查：回答能否给出依据段落，关键字段是否来自可核验的数据源。
- 流程是否闭环：模型只负责起草、分类或提取，还是被要求直接做最终决定。
这三件事没有统一答案。写作辅助容错高，可以多生成几版再挑；工单回复、合同条款解释之类场景，容错低，就需要更明确的拦截条件和人工确认。用同一套标准衡量所有任务，容易得出似是而非的结论。
把它放在合适的位置
更务实的做法，是不把大语言模型当成一个全能接口，而把它当成流程中的一个环节：需要理解模糊表达时用它，需要稳定计算和状态流转时交给确定性系统；需要起草时让它先出草稿，需要承担责任时仍由人确认。这样安排并不削弱它的价值，反而能减少那些“演示很顺、上线很累”的落差。
回到开头那个问题：模型答得流畅，为什么一进流程就卡住？答案可能不在模型本身，而在我们是否愿意把上下文、权限、评估和分工这些“不性感”的活儿做细。工具越会说话，周围的基础工作越不能含糊。