AI 赋能传统业务工作流的落地案例：原型怎样变成可用功能
规范样例能验证 AI 辅助审批或文档提取的可行性，却覆盖不了异常输入、并发限制和输出字段校验。接入业务工作流前，应把这些情况纳入验收。
原型验证可行性，交付前则需要一套可重复执行的验收体系。
生产落地的幻觉与非确定性陷阱
在传统业务系统（如供应链审批、报销单自动核验）中，系统对数据的确定性要求接近 100%。但大语言模型本质上是一个概率预测引擎。
过去很多团队上线 AI 功能时，直接让前端调 LLM，拿返回结果直接写入 DB。这会导致几个严重的生产隐患：
要把原型改造成生产可用功能，就必须在 LLM 外层包裹一层强校验的网。
生产验收防线：三级门禁机制
在将 AI 模块推向生产之前，我们梳理出了 3 项硬性工程验收指标：
1. 结构化 Schema 隔离与类型收口
禁止任何直接返回非结构化文本的 Prompt。所有输出必须绑定 JSON Schema，并通过工具链在中间件层进行硬断言。只要字段缺失或类型不符，直接阻断写入。
2. 业务规则双重检查（Double-Check Engine）
模型提取出数据后，不能直接信任。必须送入业务规则引擎做次校验。例如“报销明细子项之和必须等于总金额”、“合同签署日期不能晚于生效日期”。
3. 兜底转人工（Human-in-the-Loop Threshold）
为模型的输出置信度设置阈值。一旦置信度评分低于 0.85，或者规则引擎校验失败，自动捕获异常并生成待办任务投递给人工审核界面，确保业务流程不会因为 AI 报错而中断。
生产级数据提取与双重校验引擎实现
以下是在 Node.js/TypeScript 后端架构中落地的 AI 数据提取与业务防护中间件。集成了 Schema 校验、规则阻断与自动转人工机制：
import { z } from 'zod';
// 1. 定义业务要求的严格 Schema
const InvoiceSchema = z.object({
invoiceNumber: z.string().min(5, "发票号格式不符"),
taxAmount: z.number().nonnegative("税额不能为负数"),
totalAmount: z.number().positive("总金额必须大于零"),
vendorName: z.string().min(1, "供应商名称不能为空"),
lineItems: z.array(
z.object({
description: z.string(),
amount: z.number().positive(),
})
).min(1, "至少包含一条消费明细"),
});
type InvoiceData = z.infer<typeof InvoiceSchema>;
interface ExecutionResult {
status: 'SUCCESS' | 'FALLBACK_HUMAN' | 'REJECTED';
data?: InvoiceData;
reason?: string;
}
export class ProductionAIEngine {
private maxRetries = 2;
constructor(
private llmClient: { complete: (prompt: string) => Promise<string> },
private humanQueue: { enqueue: (raw: string, reason: string) => Promise<void> }
) {}
/**
* 带有硬校验与兜底转人工的提取逻辑
*/
async processInvoice(rawDocumentText: string): Promise<ExecutionResult> {
let attempt = 0;
let lastError = '';
while (attempt <= this.maxRetries) {
attempt++;
try {
const prompt = this.buildPrompt(rawDocumentText, lastError);
const rawResponse = await this.llmClient.complete(prompt);
// 尝试解析 JSON
const parsedJson = JSON.parse(rawResponse);
// Zod 模式硬校验
const validatedData = InvoiceSchema.parse(parsedJson);
// 业务规则双重二次检查
const businessError = this.validateBusinessRules(validatedData);
if (businessError) {
lastError = `业务规则不匹配: ${businessError}`;
console.warn(`[Attempt ${attempt}] 业务规则校验失败: ${businessError}`);
continue;
}
// 全部校验通过，安全交付生产系统
return {
status: 'SUCCESS',
data: validatedData,
};
} catch (err: any) {
lastError = err.message || '未知解析异常';
console.warn(`[Attempt ${attempt}] 数据提取过程异常: ${lastError}`);
}
}
// 多次重试依然失败，触发人类兜底流程，避免阻塞业务
console.error(`AI 提取失败，转入人工复核队列. 根因: ${lastError}`);
await this.humanQueue.enqueue(rawDocumentText, `AI 提取失败: ${lastError}`);
return {
status: 'FALLBACK_HUMAN',
reason: lastError,
};
}
private buildPrompt(document: string, previousError: string): string {
let prompt = `请从以下文档中提取发票信息，严格输出 JSON 格式:\\n\\n${document}`;
if (previousError) {
prompt += `\\n\\n[注意]: 上一次尝试失败，错误信息为: "${previousError}"。请修改你的输出，确保严格符合格式和逻辑规范。`;
}
return prompt;
}
/**
* 业务规则硬逻辑断言：明细累加必须等于总金额
*/
private validateBusinessRules(data: InvoiceData): string | null {
const itemsSum = data.lineItems.reduce((acc, item) => acc + item.amount, 0);
// 允许 0.01 的浮点数误差
if (Math.abs(itemsSum – data.totalAmount) > 0.01) {
return `子项总和 (${itemsSum.toFixed(2)}) 不等于总金额 (${data.totalAmount.toFixed(2)})`;
}
return null;
}
}
落地生产前的最后一公里检查
将原型推向生产环境，本质上是一场将“不确定性”压缩到可控范围内的系统工程。以下是我们在上线验收前总结的核查步骤：
AI 赋能传统业务不是为了噱头，只有当确定性的工程架构把好了最后一道门关，它才能真正成为生产力工具。
