从 Prompt 工程到知识库驱动：一次自动化率跌至 6% 后的架构反思

背景：在最近一次自动化解析率复盘会议上，我们直面了一组刺眼的数据------上周航司政策文件自动化解析率仅 6% 左右，远低于理论应达的 20%；42 个文件中实际走完自动化流程的只有 2 个。会议最终定调：当前最大瓶颈不在模型，而在知识管理缺失。本文以我们的航司政策智能解析系统（基于 DDD 分层架构）为样本，复盘静态 Prompt 工程架构的踩坑记录，并论证向知识库（KBS/RAG）驱动转型的必要性。

一、踩坑记录：静态 Prompt 架构的四个结构性缺陷

1.1 固定字段结构：把"知识"塞进一个 String 字段

先看领域层的 PromptTemplateEntity，它是整个 Prompt 管理的核心实体：

scala 复制代码

public class PromptTemplateEntity extends BaseEntity {
    /** 航司代码，COMMON表示通用 */
    private Field<String> airlineCode;
    /** 版本号 */
    private Field<Integer> version;
    /** Prompt内容 */
    private Field<String> content;
    /** 生效状态：ACTIVE/INACTIVE */
    private Field<String> status;
    ...
}

所有业务知识------航司映射规则、票种特征、字段填写逻辑------最终都被压缩进一个 content 字符串。check() 方法暴露了这个设计的天花板：

javascript 复制代码

if (getContent().length() > 20000) {
    throw new AggregateException("Prompt内容长度不能超过20000字符");
}
// 非COMMON航司，content必须是JSON数组格式
List<Map<String, String>> fieldPromptList = JSON.parseObject(getContent(),
        new TypeReference<List<Map<String, String>>>() {});

这里有三个硬伤：

20000 字符上限是模型上下文窗口约束向领域模型的"倒灌"。知识本应无限增长，但实体校验强制知识总量封顶------当某航司的政策规则超过上限，运营只能删旧留新，隐性知识被迫丢弃。
List<Map<String, String>> 的扁平结构只能表达"字段名 → 填写说明"这一种知识形态。而会议识别出的五大拦截点（无大客户码的文件、无历史记录的新政策、扫描版 PDF、多 Sheet 复杂结构、抓取周期限制）没有一个能用"字段级说明"这种粒度表达。
知识以 JSON 字符串形态存储在数据库 ，queryFieldPrompt() 每次遍历解析、异常时静默返回 null------知识既不可检索、不可关联，出错了也无人知晓。

1.2 Prompt 硬编码：业务方法论被焊死在 Java 代码里

政策解析应用服务中的 buildColdStartUserMessage() 是硬编码问题的典型样本------110 余行的 StringBuilder 拼接，把"体裁约束""样例解读指引""写作要点"等本属于运营方法论的内容写死在应用服务里：

go 复制代码

sb.append("## 体裁约束（必读）\n")
        .append("- 输出体裁 = **字段填写规范文案**，不是独立的「抽取 Agent Prompt」。\n")
        .append("- **禁止输出**：H1/H2 等 Markdown 标题、`Step 1/2/3`...\n")
        ...

后果是：每当航司政策格式出现新变体（比如某航司中转产品新增多种待验证的文件格式），调整 AI 的判断逻辑就意味着改 Java 代码 → 提 MR → Code Review → 发布的完整链路。会议纪要中"系统高度依赖大客户码匹配确认规则，面对新政策、新客户时能力失效"，其代码层面的根因正在于此------判断规则以代码形态存在，AI 没有任何运行时可学习的知识输入，遇到规则外情形只能失败。

1.3 版本管理与缓存：为"静态"而生的机制

Prompt 管理领域服务的版本逻辑做得相当规范：分布式锁防并发、queryMaxVersion + 1 递增版本、旧版本置 INACTIVE、refreshPromptCache() 刷新缓存。但恰恰是这套机制暴露了架构假设的过时------它假设知识是低频、整体、人工发布的：

scss 复制代码

// 将旧的Prompt状态置为INACTIVE
promptTemplateRepository.updateStatusToInactive(airlineCode);
// 保存新的Prompt
promptTemplateRepository.save(aggregate);
// 刷新缓存
refreshPromptCache(airlineCode);

每次哪怕只修改一个字段的说明（modifyFieldContent），也要整体产生一个新版本、全量失效旧版本、全量刷缓存。知识更新粒度是"整份 Prompt"，而航司政策的变化粒度是"某航司某票种的某条潜规则"。粒度错配导致：版本号飞涨但无法回答"这条规则是谁在什么场景下加的"，缓存刷新保证了一致性却无法保证相关性------AI 每次拿到的都是全量 content，无论当前解析的文件是否需要。

1.4 兜底逻辑掩盖知识缺失

getActivePromptByAirlineCode() 中，航司无特化 Prompt 时静默降级到 COMMON 通用 Prompt。这个看似合理的 fallback，实际把"该航司知识缺失"这一重要信号吞掉了------新航司、新政策进来，系统不会报告"我不认识"，而是拿通用规则硬解析，产出低质量结果后由人工修正。这正是自动化率虚高（前一周 19%）随后崩塌（6%）的机制：系统没有"知道自己不知道"的能力。

二、Prompt 工程 vs RAG：约束机制与动态注入的本质差异

维度

静态 Prompt 工程（现状）

RAG / 知识库驱动

知识载体

DB 中的 JSON 字符串，≤20000 字符

独立知识库（语雀 Markdown），无上限

知识粒度

整份 Prompt 全量替换

单条知识（航司映射/票种特征/潜规则）独立沉淀

注入方式

全量拼接进上下文

按当前文件特征检索 Top-K 相关知识

更新链路

改代码或改 DB → 发版/刷缓存

运营直接写自然语言文档，即时生效

新场景适应

规则外即失败（无大客户码文件直接中断）

按「航司+产品类型+文件特征」检索相似经验做替代匹配

维护主体

开发工程师

运营团队（专人整理 + 持续补充）

关键区别在于约束的方向。静态 Prompt 是"预先约束"：开发者预测所有可能情形，把判断逻辑固化为规则（大客户码匹配即是极致------一条规则决定走不走自动化）。AI 在这种架构里是"填空机器"，其推理能力被 Prompt 的预设边界严格限制。

RAG 则是"运行时供给"：AI 面对新文件时，先检索知识库中的相关经验（"某航司的规则政策里 93→7 表示比例拆分""某类中转文件的 Sheet2 才是运价页"），再基于检索结果推理。会议上有一个精准的类比------"正如本科生需先学完高数离散才能解题，AI 需先学习知识库中的基础方法"------说的正是这个转变：AI 不是万能创造者，通用模型在缺乏领域知识输入时等同于无效；但把人脑中的判断逻辑显性化、文档化后喂给它，它就能成为可靠的执行引擎。

值得注意的是，系统里的 optimizePromptByAI() 接口（AI 优化 Prompt）已经是朝正确方向的尝试------用"AI 解析结果 vs 人工修正结果"的差异反哺 Prompt。但它反哺的目标仍是那个 20000 字符的静态 content，相当于把新知识不断塞进一个固定大小的抽屉，治标不治本。

三、DDD 视角：职责边界的越位与重构方向

从架构规范看，政策解析应用服务（Application 层）存在明显的职责越位：

Application 层直接依赖 Infrastructure 具体实现------AI SDK（Spring AI Alibaba）、OSS、Excel 解析等 Adaptor 均以具体类形式注入，违反了"应用/领域层禁直接引用外部 IO，必须通过接口隔离"的分层铁律。
业务方法论沉淀在错误的层 ------buildColdStartUserMessage() 里的"字段填写逻辑写作规范"是不折不扣的领域知识，却以私有方法形态存在于应用编排层，既无法复用也无法测试。
编排逻辑过重 ------compareFliggyPolicyExcel 一个方法内串起了文件中转上传、OSS 双下载、Excel 解析、记录查询、Prompt 富化五段逻辑，任何一段的变化都要动这个 400 多行的类。

重构方向上，知识库应当被建模为一个独立的领域概念而非 Prompt 的附属品：

Domain 层定义 KnowledgeRepository 接口（retrieveByContext(airline, productType, fileFeature)），检索实现（语雀 API / 向量检索）隔离在 Infrastructure 的 Adaptor 中------这与现有 PromptTemplateRepository 的隔离模式一致，改造成本可控。
将"大客户码匹配失败 → 流程中断"改造为"匹配失败 → 触发知识库推荐 → 按航司+产品类型+文件特征替代匹配 → 人工确认"，即从硬性拦截 转为知识库辅助推理。
静态 Prompt 退化为"骨架模板"（输出格式、安全约束等确定性部分），动态知识由检索层按需注入，两者在 Adaptor 层组装。

主要技术挑战有三：知识冷启动 （初期需专人把隐性经验整理为 Markdown，打破"人肉知识孤岛"）；检索质量 （航司政策术语高度专业，需要按"航司/票种/文件类型"建立结构化元数据而非裸向量检索）；效果归因（一次解析注入了 N 条知识，错误归因于哪条？需要在现有解析修正记录的基础上扩展知识引用追踪）。

四、全局思考：确定性与创造性的边界划分

引入知识库不等于放任 AI 自由发挥。这个系统有一条不可动摇的红线------政策投放最终生效前必须人工确认。这提示了一个清晰的分层原则：

确定性层（代码规则）：金额计算、日期校验、投放生效审批------继续由代码和人工把关，AI 无权触碰；
推理层（知识库 + AI）：文件理解、字段抽取、格式变体适配------由检索到的知识约束 AI 的推理边界；
兜底层（人工）：知识库检索置信度不足时显式上报"我不认识这种文件"，而非静默降级到 COMMON 模板硬解。

展望：当运营知识库沉淀起航司映射、票种特征、投放潜规则之后，系统的能力上限将不再由工程师的发版节奏决定，而由运营团队的知识沉淀速度决定。新航司接入从"开发排期两周"变为"运营写一篇文档"；扫描版 PDF、多 Sheet 复杂结构等当前的硬拦截点，也将随着多模态能力升级和对应方法论的入库逐步转化为自动化增量。6% 到 20% 的差距以及未来全量自动化的展望，缺的不是更强的模型，而是一套让 AI"先学方法论、再做推理"的知识供给架构------这正是从"人肉运维"走向"智能协同"的必经之路。

文中代码片段为真实项目代码的节选与简化。