最近我在做一个内部代号为 Xfwl4 的 LLM 落地实验需求听起来并不复杂把一堆零散的业务文本交给大模型让它抽取关键字段、格式化输出再送进下游系统。刚接手时我以为最大的难点是写 Prompt毕竟所有教程都在强调提示词的重要性。真正做了两周之后我发现 Prompt 只是冰山一角。项目能不能长期跑下去真正卡人的地方在模型外面的那层系统设计输入边界怎么定、输出结构怎么约束、失败怎么兜底、日志怎么留、成本怎么控。这篇文章想讲的不是“LLM 能做什么”而是当一个普通开发团队想把 LLM 嵌进真实工作流时最容易忽略的几条工程原则。Xfwl4 这个代号可以看作一个通用示例一个用 LLM 处理文本抽取和内容补全的内部项目。它不一定代表某个官方产品也不代表某个成熟框架而是一类正在大量出现的内部实验项目。这类项目有一个共同点模型能力已经不是瓶颈工程化才是。1. 先定义边界再让大模型进场1.1 输入不是“一堆文本”而是“一种格式”最常见的起步方式是直接把原始文本拼进 Prompt然后问模型“请提取里面的公司名称、金额、日期”。这样不是不行但会很快碰到几个问题第一输入如果不做归一化模型要同时处理格式噪声和业务语义。正文里有换行、表格、特殊符号、重复段落模型很容易被无关信息带偏。第二输入长度不稳定。有些文本只有几十个字有些是几千字的合同同一个 Prompt 很难同时覆盖两种长度。第三输入内容不完整。原始文本里常见的省略表达比如“甲方为上述公司”模型缺乏上下文只能靠猜猜出来的结果又不能保证稳定。所以在 Xfwl4 里我做的第一件事不是调 Prompt而是给输入定标准。所有进入模型的文本先经过一道预处理统一编码去掉不可见字符和多余空白。业务文本按段落拆开必要时加序号方便后续定位。如果原始文本超过模型支持的上下文长度先做摘要或分段而不是硬塞。对必须依赖上下文才能理解的表达提前把指代关系补全比如把“上述公司”替换成实际名称。这样做的好处很快体现出来。模型看到的输入更干净输出自然更稳定。更关键的是当模型偶尔出错时你能判断是输入的锅还是模型理解的锅。输入标准化这一层本质上是在给后续排查留线索。1.2 输出结构比 Prompt 措辞更关键很多人调 Prompt 时只关心“让模型输出 JSON”但很少进一步定义这个 JSON 是什么结构。结果就是模型每次都输出 JSON但有的字段叫total_amount有的叫amount有的把日期写成字符串有的写成数组。解析层为了兼容这些变体代码越写越复杂。我的建议是先定义输出 Schema再写 Prompt。所谓 Schema就是对输出格式的明确约束。比如一个抽取任务可以用这样一份 JSON Schema{ type: object, properties: { company_name: { type: string }, amount: { type: number }, currency: { type: string, enum: [CNY, USD] }, date: { type: string, format: date }, confidence: { type: number, minimum: 0, maximum: 1 } }, required: [company_name, amount, currency, date] }然后把 Schema 放在 Prompt 里作为硬约束并在 Prompt 中明确说明如果某个字段在原文中找不到输出null不要自行编造日期统一输出YYYY-MM-DD金额只输出数字不要带千分位逗号。为什么这样做因为模型是概率输出它不会天然遵守业务格式。如果不约束输出结构后面每个下游环节都要处理格式兼容问题。而一旦结构固定就可以写通用的解析函数、校验函数和异常报警。整个系统从“模型说什么是什么”变成“模型必须在既定框架内回答”可控性会强很多。我还建议在 Prompt 末尾加一句“只输出符合 Schema 的 JSON不要输出解释文本”。这一步能减少很多多余信息也方便直接解析。2. 单次跑通不等于稳定运行2.1 成功样例说明不了真实分布在 Xfwl4 项目早期我用几个手头样例测试模型输出质量相当不错该抽取的字段基本都抽对了。于是团队信心大增开始设计批量流程。但一跑起来就发现真实业务文本千奇百怪几个成功样例根本无法代表真实分布。同一个 Prompt在精心挑选的样例上表现很好在真实文本上却频繁出错。这就是很容易误解的地方LLM 的评估不能只看几个案例而要看一批有代表性的输入。我在项目里做了一件事从真实业务数据里随机抽 100 条人工标注正确答案再拿模型批量跑一遍记录字段级别和记录级别的准确率。这个过程很花时间但非常值得因为它能告诉你“当前 Prompt 的真实水平”到底是多少。如果批量准确率连 80% 都不到后面根本不用谈全自动化。正确做法是先跑人工辅助流程模型给出初稿人工做二次确认通过流程把模型的失败模式逐步摸清再针对高频错误改 Prompt 或加预处理。2.2 失败是系统的一部分不是意外工程上有一个基本前提任何依赖 LLM 的流程都必须假设模型会出错。这不是悲观而是因为 LLM 本身就是概率模型。可能这次输出合法 JSON但关键字段缺失可能“amount”被抽成了字符串可能模型在原文没有答案时编造了一个结果。针对这些可能至少需要三层兜底解析层兜底模型输出不是合法 JSON 时尝试修复比如重新请求一次或者剥离多余文本。字段层兜底合法 JSON 但字段缺失时根据业务规则填默认值或者标记为“待人工确认”。语义层兜底数值范围明显不合理时比如金额突然变成天文数字触发告警并转人工。在 Xfwl4 里我见过最多的错误不是模型“不懂”而是应用层没有处理非法输出导致下游系统收到坏数据。这个错误非常隐蔽因为它不会立刻让流程崩溃而是让数据质量慢慢变差。2.3 人工审核不是可有可无很多团队在刚开始引入 LLM 时会对自动率有很高期待希望 100% 自动化。但在实际业务里自动率是逐步涨上去的而不是一开始就拉满。比较稳妥的做法是设定一个审核阈值置信度高于某个值的结果自动通过低于阈值的进入人工审核池。置信度可以由模型自己给出也可以根据规则判断比如关键字段是否齐全、字段取值是否在合理区间。注意不要一上来就追求全自动。先把自动率控制在 70% 到 80%剩余部分人工兜底积累足够数据后再逐步提高阈值。这套机制的价值在于有了人工兜底系统不会因为模型的一次突发错误产生严重后果同时也给了你调整优化的时间。3. 参数不是玄学先理解再调整3.1 temperature 和 max_tokens 的真实作用任何一个 LLM 的 API 里几乎都有一组生成参数。最常见的两个是 temperature 和 max_tokens。temperature 控制的是随机性。值越高输出越发散值越低输出越稳定、越接近最可能的回答。在做抽取、分类、格式化这类任务时我更建议把 temperature 调低比如 0.1 到 0.2。这样能减少无意义的改写和随机波动。如果你在做创意写作、头脑风暴这类开放性任务再考虑调高到 0.7 以上。max_tokens 控制的是单次生成的最大长度。这个参数很多人容易忽略但它的影响很直接如果设得太小输出可能在中间被截断导致 JSON 不完整解析失败。设得过大遇到异常输入时模型可能输出大量无关内容既浪费成本也增加解析难度。我的做法是先根据输出 Schema 估算一个正常输出需要的 token 量然后留出 30% 到 50% 的余量再配合输出长度校验。如果输出太短或太长就记录告警。3.2 上下文长度不是越长越好上下文越长模型能参考的信息越多但同时也意味着更多噪声、更高成本和更慢的响应。在 Xfwl4 里一开始为了不丢信息我们把整篇文档都塞进 Prompt结果成本高输出还容易漂移。后来改成按需分段检索只把相关片段放进上下文准确率和成本都明显改善。这个对比说明了一个问题上下文管理不是简单地把所有信息丢给模型而是要围绕任务选择“够用”的信息。常见的做法有两种文档切片把长文档按固定大小切块为每块做摘要或索引任务需要时只取相关块。分层摘要先把长文档切成多段分别生成摘要再把摘要汇总给模型适合全局判断类任务。两种方式没有绝对优劣关键要看任务是偏局部还是偏全局。局部抽取用切片全局概括用摘要。3.3 一个可复用的参数起点对于大多数把 LLM 嵌入业务系统的场景我一般会用这样一组参数作为起点任务类型temperature 建议max_tokens 建议备注结构化抽取0.1 - 0.2按输出结构估算再加余量优先保证稳定性分类/打标0.1 - 0.3短输出即可可以使用枚举约束摘要0.3 - 0.5根据目标长度估算需要防止截断创意生成0.7 - 1.0较大余量不追求严格一致这个表不是公式只是起点。最终参数一定要基于你自己的验证集来定。每次改参数跑同一批标注样本看输出质量的变化而不是凭感觉调。4. 把一次经验沉淀成可复用业务流程4.1 从“调 Prompt”变成“搭 Pipeline”刚开始接触 LLM 的人很容易把全部精力都放在 Prompt 优化上。但真正要把 LLM 用进业务需要的是一个完整的处理流水线。这里有一个比较通用的 Pipeline输入归一化清洗、分段、补充上下文。上下文组装按任务选择模型需要的信息组装 Prompt。模型调用带参数、超时、重试策略发起调用。结构化解析把模型输出解析成业务对象。质量校验检查字段是否齐全、值是否合理。异常处理失败重试、默认值、告警、转人工。结果入库记录原始输入、输出、耗时、成本、错误信息。每一步都可以做得很重也可以做得很轻但骨架不能少。少了任何一环后面的维护成本都会显著上升。以 Xfwl4 为例当我按照这个 Pipeline 重构代码后系统从一个“调用模型”的函数变成了一个可观测、可回退、可迭代的处理流程。新需求进来时只需要替换输入归一化和校验规则主体不用动。4.2 日志和可观测性决定你能否长期迭代在整个 Pipeline 里日志最容易被低估。很多团队在实验阶段不记日志等部署上线后遇到问题才发现完全没有现场数据。我的建议是至少在每条处理记录里保存以下信息输入的唯一标识比如业务单号输入内容的前几十个字符摘要方便人工定位实际发送给模型的 Prompt 模板版本模型返回的原始输出解析后的结构化结果每次调用的耗时、token 消耗、重试次数失败阶段和失败原因有了这些日志你才能做到两件事一是问题可复现二是迭代可比较。否则模型表现一波动你根本不知道是 Prompt 变了、参数变了、还是输入变了。注意不要把原始 Prompt 原样打印到日志里尤其是包含个人信息或业务敏感信息时。可以先做脱敏处理或者只记录模板 ID 和关键参数。4.3 人工兜底是长期能力不是过渡方案我见过一些团队把“人工审核”当成临时方案觉得等模型优化好了就不需要人了。但真实业务里错误再少只要批量够大都会累积出数量可观的问题数据。与其让这些问题直接流到下游不如在流程里保留一个人工审核层。人工审核层不一定要零散地抽查更合理的是做成一个待办队列低置信度结果进入待办池人工确认后回写正确结果同时把人工修正过的数据攒下来作为下一轮 Prompt 调优和模型微调的数据集。这样人工操作就不只是兜底还在为模型持续提供反馈信号。5. 遇到问题用这条链路排查5.1 先看现象再对号入座LLM 应用出错时的现象五花八门但归纳起来常见的无非这么几类现象最可能的原因优先排查动作输出不是合法 JSON上下文太长、温度偏高、模型被输入带偏降低 temperature检查 Prompt 是否被输入干扰关键字段缺失原文没有明确信息或 Prompt 没有兜底规则检查输入文本是否包含该字段补充“缺失时输出 null”规则输出内容正确但格式不统一缺少 Schema 约束增加结构化输出定义加枚举和格式说明速度很慢上下文太长或并发不足缩短上下文检查 API 超时和并发限制成本快速上涨上下文冗余、重试过多、异常输入过长做输入长度控制优化上下文选择策略5.2 通用排查顺序当问题定位不明确时我一般按下面这个顺序排查看输入。先确认进入模型的文本是什么有没有格式问题、长度问题、缺字段问题。看上下文。确认发给模型的 Prompt 里到底塞了什么是不是把无关信息也带了进去。看参数。检查 temperature、max_tokens 是否和任务匹配。看模型能力。如果任务本身需要复杂推理而模型版本较老确实可能出现能力不足这时再考虑换更强的模型。看应用层。确认解析、校验、重试逻辑是否处理了异常输出。看资源。API 是否限流、超时时间是否太短、并发是否打到上限。这个顺序并不是严格的但它覆盖了大多数问题的来源。最怕的是跳过输入和上下文直接怀疑模型能力甚至直接换模型。那样往往解决不了问题反而让系统越来越复杂。5.3 两个典型排查案例在 Xfwl4 里我遇到过两个很典型的例子。第一个问题是输出 JSON 偶尔被截断。从现象看像是模型输出能力不够但实际排查后发现是 max_tokens 设置偏小而某类输入文本特别长导致模型在输出 JSON 时被强制截断。调整 max_tokens 之后问题消失。第二个问题是同一个字段有时返回数值有时返回带单位字符串。现象在解析层原因却在 Prompt。因为 Prompt 里只说“返回金额”没有说明“金额只返回数字不要带单位”模型就自由发挥了。给字段加严格说明后格式立刻稳定。这两个例子说明LLM 应用的很多问题表面是模型问题实际是工程问题。排查时要先看自己能不能把变量隔离出来再决定要不要怀疑模型。6. 适合与不适合都要提前知道6.1 适合的场景结合 Xfwl4 的经验我觉得以下场景更适合用 LLM 来落地输入和输出边界清晰的任务比如抽取、分类、格式化、摘要。允许部分结果进入人工审核而不是要求 100% 自动。业务对单次错误有容忍度可以通过重试、默认值和告警来兜底。需要快速迭代的流程比如规则经常变化用传统规则写很费劲。已有一定数量的历史数据可以用于验证和迭代。6.2 不适合的场景反过来有些场景我并不建议强行引入 LLM实时性要求极高模型响应延迟不能接受。一致性要求极强同一个输入必须产出同样的结果。高风险决策比如直接决定贷款额度、诊疗建议等除非有严格的人工复核和合规流程。数据敏感场景但团队没有足够能力做好脱敏、权限和审计。错误几乎不可接受的场景比如计费、合同金额等核心数据。这类场景更适合把 LLM 作为辅助预填而不是直接决策。6.3 长期维护离不开基准集和回归测试最后一点其实是最容易被长期忽略的。LLM 应用上线后Prompt、模型版本、参数都可能被调整但调整之后如何判断是变好还是变坏我的建议是建一个小的基准集。从真实业务里抽几百条有代表性的数据记录下每个字段的正确答案。每次修改 Prompt、参数或模型版本时都拿这个基准集跑一遍对比准确率和格式符合率。这个基准集不需要很大但要有代表性。它像一盏路灯能告诉你每一次改动到底是在前进还是后退。没有基准集所谓的优化很可能只是对某一个样例的过度拟合。写到这里想再回到开始的话题。Xfwl4 不是某个神秘系统它只是我在做 LLM 落地实验时给项目起的一个代号。这个代号将来可能被换掉过程也会不断迭代但它留下的方法论是通用的先定义输入输出边界再构造可观测的流程然后逐步提升自动化比例最后形成一套能长期迭代的工程体系。如果你手头也准备启动一个 LLM 项目我的建议很简单不要急着写完 Prompt 就上批量任务先拿 50 到 100 条有代表性的数据跑一遍小样本验证记录失败模式再决定下一步。模型本身只是引擎真正决定项目成败的是引擎外面那辆车的底盘、刹车和仪表盘。