大语言模型 能力集成与智能工作流自动化实践：产品和研发怎样对齐交付
在推进 LLM 智能工作流自动化落地时，产品经理（PM）和研发工程师（R&D）之间经常陷入一种微妙的对抗状态。
仅用少量合同样例在 Playground 验证 Prompt，不能证明可以上线。复杂 PDF、模型输出格式变化和异常输入都应纳入研发测试与验收。
LLM 能力集成的核心矛盾，是产品对非确定性效果的期望，与研发对确定性系统调用的要求之间的冲突。
1. 跨角色协作中的三大体验陷阱
智能工作流项目在推进过程中，最容易在以下三个地方卡住：
第一，Prompt 变成写死在代码里的魔法字符串。PM 每次调整提示词，都需要发个 Pull Request 让研发重新上线，协作效率极低。
第二，边界条件归因不清。工单派单错了，PM 归咎于“研发没有调好系统参数”，研发归咎于“PM 写的提示词逻辑过于模糊，模型无法理解”。
第三，缺少 SLA 与 Token 预算控制线。PM 设想的自动化流程包含 5 轮复杂的 Chain-of-Thought（思维链）推理，结果单个任务运行耗时 20 秒、消耗 15000 个 Token。财务看到账单后直接叫停项目。
2. 划清界面：产品与研发的职责切分矩阵
为了避免相互扯皮，应当在架构层面清晰划定两者的责任边界：
| 协作维度 | 产品经理 (PM) 负责领域 | 研发工程师 (R&D) 负责领域 |
|---|---|---|
| 输入与提示词 | 撰写 Prompt 模版，管理提示词版本 | 负责参数插值渲染、敏感词过滤与转义 |
| 输出规范 | 定义预期 JSON 结构的业务含义 | 编写 JSON Schema 格式硬断言与正则修复器 |
| 效果与稳定性 | 提供包含 50+ 真实案例的评测数据集 | 负责并发控制、超时重试、自动降级兜底 |
| 成本与 SLA | 确定业务可接受的 P95 延迟与预算 | 实现 Token 计数器、速率限制（Rate Limit） |
下面这段 TypeScript 代码展示了如何实现一个让产品经理配置 Prompt 版本，同时让研发收口确定性校验与降级防护的智能工作流编排网关：
import { JSONSchemaType } from 'ajv'; import Ajv from 'ajv'; const ajv = new Ajv({ coerceTypes: true }); // 产品与研发共同认定的输出 Schema（如合同条款提取） export interface ClauseExtractionResult { contractId: string; hasRisk: boolean; riskClauses: Array<{ clauseNo: string; riskType: string; summary: string }>; } const clauseSchema: JSONSchemaType<ClauseExtractionResult> = { type: 'object', properties: { contractId: { type: 'string' }, hasRisk: { type: 'boolean' }, riskClauses: { type: 'array', items: { type: 'object', properties: { clauseNo: { type: 'string' }, riskType: { type: 'string' }, summary: { type: 'string' }, }, required: ['clauseNo', 'riskType', 'summary'], }, }, }, required: ['contractId', 'hasRisk', 'riskClauses'], }; export interface WorkflowOptions { promptTemplate: string; // PM 维护的提示词模版 maxTokenBudget: number; // 研发设置的 Token 预算上限 timeoutMs: number; // 研发设置的 SLA 超时限制 } export class SmartWorkflowOrchestrator { private schemaValidator = ajv.compile(clauseSchema); // 模拟调用 LLM private async callLLM(prompt: string): Promise<string> { // 模拟 LLM 返回 return JSON.stringify({ contractId: 'CTR_2026_8890', hasRisk: true, riskClauses: [ { clauseNo: '4.2', riskType: 'LATE_PAYMENT', summary: '违约金比例过高' } ] }); } // 执行工作流，内置确定性防护 public async executeWorkflow( contractId: string, contractText: string, options: WorkflowOptions ): Promise<ClauseExtractionResult> { // 1. 研发层检查：输入参数转义与防注入 const safeContractText = contractText.substring(0, 8000); // 截断防止溢出 const finalPrompt = options.promptTemplate .replace('{{contractId}}', contractId) .replace('{{contractText}}', safeContractText); // 2. 研发层检查：超时与 SLA 控制 const controller = new AbortController(); const timeoutTimer = setTimeout(() => controller.abort(), options.timeoutMs); try { const rawResponse = await this.callLLM(finalPrompt); clearTimeout(timeoutTimer); // 3. 确定性修复：处理 Markdown 代码块转义 let cleanedText = rawResponse.trim(); if (cleanedText.startsWith('```json')) { cleanedText = cleanedText.replace(/^```json\s*/, '').replace(/\s*```$/, ''); } const parsed = JSON.parse(cleanedText); // 4. 硬断言：Schema 校验 const isValid = this.schemaValidator(parsed); if (!isValid && this.schemaValidator.errors) { throw new Error(`Schema Violation: ${JSON.stringify(this.schemaValidator.errors)}`); } return parsed as ClauseExtractionResult; } catch (err: any) { console.warn(`[Workflow Fallback] Exception hit for contract ${contractId}:`, err.message); // 5. 自动降级兜底：当 LLM 解析崩溃时，退回到保守的人工复核标识，保证业务不中断 return { contractId, hasRisk: true, riskClauses: [ { clauseNo: 'UNKNOWN', riskType: 'SYSTEM_FALLBACK', summary: '系统解析降级，转人工复核' } ] }; } } }3. 产研协同落地三步走
建立好了职责边界与网关代理后，产研协同推进可以分三步落地：
第一步，构建真实的测试数据集（Dataset Evaluation）。在写第一行业务代码前，PM 整理出 50 份代表性合同作为评测基线。
第二步，自动化评测接入 CI。每次 PM 更改了仓库里的 Prompt 配置文件，自动跑一遍基准数据集，对比格式通过率与风险识别准确率。
第三步，设定线上熔断与降级预案。当模型服务不可用或连续抛出 Schema 校验错误时，系统自动切入预设的规则引擎或人工复核队列。
4. 产研推进的三条工程底线
智能工作流要真正赋能业务，产研双方需要达成三个共识：
第一，Prompt 是配置，不是业务逻辑。提示词交由 PM 或领域专家去优化，研发专注做架构防护。
第二，应当用 Schema 作为产研之间的接口契约。不能靠自然语言口头描述输出格式。
第三，应当有降级兜底方案。永远不要让 LLM 的不稳定直接暴露给终端业务。
