生成式AI设计模式：输入净化、状态重试与输出沙盒工程实践-平芜编程栈

1. 这不是又一本AI方法论手册，而是一套能立刻上手的设计“扳手”

“生成式AI设计模式（十二）”——看到这个标题，你第一反应可能是：又来？市面上讲Prompt Engineering、讲RAG、讲Agent Workflow的教程已经堆成山了，第十二个模式，是不是又要塞一堆抽象概念，比如“协同涌现范式”或者“多模态语义对齐层”？我实话实说：如果你也这么想，那恭喜你，踩中了绝大多数人理解生成式AI落地的第一个坑。这根本不是在罗列第十二种“理论模型”，而是指代一套经过十二轮真实项目迭代、被反复验证过、能直接拧进产品螺丝口里的设计扳手。它解决的不是“AI能不能写诗”，而是“客服系统如何在300毫秒内，把用户一句‘上次快递弄丢了’，精准拆解成：①识别物流异常事件、②定位订单ID、③调取赔付政策原文、④生成带赔偿金额和时效承诺的回复草稿、⑤自动插入人工审核钩子”这一整条链路里，那些教科书从不提、但工程师天天在填的坑。

核心关键词——生成式AI设计模式——在这里不是学术术语，是工程黑话。它指的是：当大模型不再是实验室玩具，而是要嵌入银行风控系统、医院电子病历、工厂设备巡检报告这些对稳定性、可解释性、合规性有硬要求的场景时，我们不得不放弃“喂Prompt→拿结果”的简单思维，转而像搭乐高一样，用一组可复用、可测试、可审计、可替换的结构化组件，去构建AI能力。比如，“状态感知型重试模式”不是教你写更好的retry逻辑，而是定义了一套标准：当模型输出失败时，必须记录当时的上下文快照、触发条件阈值、回退到哪个确定性规则引擎、以及如何向下游服务暴露这次失败的元数据——所有这些，都得提前设计进接口契约里，而不是等线上报警了再补日志。

适合谁看？不是给纯算法研究员看的，而是给三类人：第一类是正在把AI塞进现有业务系统的后端工程师，你手头有Spring Boot微服务，但不知道怎么让大模型输出和你的事务一致性对齐；第二类是技术型产品经理，你需要判断一个“智能合同审核”功能，到底是该用微调小模型，还是用RAG+规则兜底，抑或干脆放弃AI、回归人工抽检——这个判断背后，就是设计模式的选择；第三类是刚从学校出来的应届生，别急着背Transformer公式，先搞懂为什么你在实习时写的那个“AI写周报”脚本，上线三天就被运维砍掉——因为没设计“输入校验模式”和“输出沙盒模式”。这十二个模式，每一个都对应一个血泪教训换来的工程约束。接下来，我们就从最常被忽略、却最致命的第一个模式开始：输入净化与意图锚定模式。

2. 输入净化与意图锚定模式：为什么90%的AI线上故障，根源都在用户敲下的第一个字

2.1 你以为的“用户输入”，其实是未经消毒的原始战场

很多团队在做AI功能时，第一件事是写Prompt：“请根据以下内容生成专业回复……”。但没人告诉你，这句话前面的“以下内容”，可能是一段从微信截图OCR过来的、夹杂着emoji和乱码的文本；可能是销售在CRM里随手打的“客户很生气！！！”，后面跟着三个问号；甚至可能是前端传过来的一个空字符串，只因为某个JavaScript变量没初始化。这就是“输入净化与意图锚定模式”要解决的核心问题：大模型不是万能清洁工，它不能也不该承担输入数据的清洗责任。把它当成一个精密仪器，你不会把沾满泥浆的零件直接塞进CNC机床，对吧？同理，把脏数据直接喂给模型，得到的不是错误答案，而是“看起来合理、实则危险”的幻觉输出。

我去年帮一家保险科技公司重构理赔助手，他们最初的版本，用户上传一张模糊的医疗发票照片，后端直接调OCR，把识别结果原样拼进Prompt。结果呢？OCR把“¥1,234.56”错识成“¥123456”，模型没察觉这是金额异常，反而基于这个错误数字，生成了“建议赔付12万元”的回复。这不是模型的问题，是整个输入链路缺乏净化层。后来我们加了三层净化：第一层是OCR后置校验，用正则匹配金额格式，不匹配就标为“待人工复核”；第二层是语义锚定，强制要求用户在上传前选择“门诊发票”“住院清单”“药品收据”三个标签之一，这个标签会作为强约束注入Prompt；第三层才是模型推理。上线后，因输入错误导致的误赔付投诉下降了73%。你看，这里没有用任何新模型，只是把“输入净化”这件事，从“可选项”变成了“不可绕过的强制关卡”。

2.2 净化不是过滤，是建立输入可信度的信用体系

很多人把“净化”理解成删掉特殊字符、转义HTML标签这种基础操作。这远远不够。真正的净化，是给每一份输入打上可信度分数和意图置信度标签。举个具体例子：用户输入“帮我查下张三的保单”，系统需要回答三个问题：第一，张三是谁？（身份解析）；第二，哪份保单？（实体消歧）；第三，查什么？（意图分类）。这三个问题的答案，不能全指望模型一次猜准。我们的做法是：

身份解析层：先查用户当前登录会话绑定的手机号，再查该手机号名下是否有“张三”这个常用名关联；如果没有，再查CRM中最近30天联系人列表里叫“张三”的人；最后才 fallback 到模型模糊匹配。每一步都返回一个置信度（如：会话匹配度0.95，CRM匹配度0.62），加权后得出最终身份可信度。
实体消歧层：用户可能有5份保单，系统会提取每份保单的“最近出险时间”“当前状态”“保障类型”三个维度，生成一个向量；同时把用户输入中的关键词（如“车险”“续保”“理赔”）也向量化；计算余弦相似度，取Top3作为候选。不是简单返回“找到3份”，而是返回“保单A（相似度0.87，匹配关键词‘车险’）、保单B（相似度0.72，匹配‘续保’）……”
意图分类层：不用模型做NLU，而是用轻量级规则引擎。比如，输入含“怎么赔”“流程”“多久”→归为“理赔流程咨询”；含“不认可”“申诉”“投诉”→归为“异议处理”；含“修改”“更新”“换”→归为“信息变更”。规则覆盖85%常见case，剩下15%才交给模型，并附带规则引擎的“未匹配关键词”日志。

这套机制的关键在于：所有中间结果都可审计、可回溯、可干预。当某次输出出错，你不需要去翻模型log，直接看输入净化层的三张表：身份可信度低？说明用户没登录或用了小号；实体消歧相似度全低于0.5？说明用户输入太模糊，该触发澄清话术；意图分类未命中？说明规则库该更新了。这才是工程化的起点。

2.3 意图锚定：用结构化Schema把“模糊需求”焊死在确定性轨道上

很多AI产品失败，不是因为模型不行，是因为需求本身就在飘。用户说“帮我优化这段文案”，优化成什么样？更简洁？更热情？更适合发朋友圈？还是符合某品牌VI手册？如果不提前锚定，模型只能按自己训练数据里的“默认偏好”发挥，结果往往南辕北辙。意图锚定模式，就是强制在用户发起请求前，用最小成本获取结构化意图。

我们做过一个电商详情页AI改写工具，最初让用户自由输入“我想让这个页面更好”，结果模型生成的全是营销味浓重的文案，但商家真正想要的是“突出材质参数、弱化促销话术、适配中老年用户阅读习惯”。后来我们改了交互：第一步，用户必须从三个卡片中选择目标（提升转化率 / 提升信任感 / 适配特定人群）；第二步，针对“适配特定人群”，再弹出子选项（银发族 / 学生党 / 新手妈妈）；第三步，才允许输入原文。这三步看似增加了点击，但带来的收益是：所有输入都自带一个JSON Schema：

{ "optimization_target": "trustworthiness", "audience": "senior_citizens", "constraints": ["避免网络用语", "字体大小≥16px", "关键参数前置"] }

这个Schema会原样注入Prompt，并作为模型输出的硬性校验条件。比如，模型生成的文案如果包含“yyds”“绝绝子”，后置校验器会直接拒绝并提示“检测到不符合‘避免网络用语’约束的词汇，请重试”。你看，这里没有调用更贵的模型，没有增加算力，只是把“意图”从模糊的自然语言，变成了可编程、可验证、可版本管理的结构体。这正是设计模式的力量——它不改变模型能力上限，但极大提升了能力下限的稳定性。

提示：意图锚定不是增加用户负担，而是转移认知负荷。用户不想思考“我要什么”，他只想“解决问题”。你的任务，是把问题域的复杂性，封装成几个直观的按钮。就像汽车仪表盘，用户不需要懂ECU原理，但他需要一眼看懂油量和水温。

3. 状态感知型重试模式：当AI“想不出来”时，系统不该沉默，而该亮起红灯

3.1 重试不是技术动作，而是服务契约的履约声明

几乎所有AI系统都有重试机制，但99%的实现，只是简单地while (attempt < 3) { call_llm(); }。这在Demo阶段没问题，一旦上线，就会变成灾难。想象一下：用户提交一个“合同风险点分析”请求，第一次调用超时，系统默默重试；第二次返回了“未识别到风险条款”，但没告诉用户这是模型的不确定输出，还是真的没风险；第三次干脆返回空结果，前端显示“处理中…”然后永远转圈。用户得不到反馈，客服接到投诉，研发查日志发现三次调用都“成功”，但没人知道模型内部发生了什么。这就是典型的“重试失明症”。

状态感知型重试模式，核心思想是：每一次重试，都必须携带明确的状态上下文，并触发对应的业务动作。它把重试从一个后台技术细节，升级为面向用户的服务承诺。我们给这个模式定义了四个必选状态：

Pending（挂起）：请求已接收，正在排队。此时前端显示“已收到，正在分析中…”，并给出预估等待时间（基于历史P95延迟计算）。
Processing（处理中）：模型已开始推理。此时必须返回一个“处理进度标识符”，比如proc_abc123，这个ID会贯穿整个链路，用于日志追踪和用户查询。
Uncertain（不确定）：模型返回了低置信度结果（如分类概率<0.6，或生成文本含大量“可能”“或许”“建议核实”等模糊词）。此时系统不返回结果，而是主动触发“澄清交互”：向用户推送一条消息，“检测到合同中‘不可抗力’条款表述模糊，是否需要我重点分析该条款？或提供标准条款模板供参考？”——把不确定性，转化为用户可参与的决策点。
Failed（失败）：模型返回错误（token超限、服务不可用、内容安全拦截）。此时必须记录完整的失败原因代码（如ERR_MODEL_TIMEOUT、ERR_CONTENT_BLOCKED），并根据代码执行预设策略：如果是超时，降级到缓存结果；如果是内容拦截，切换到合规审查模式；如果是服务不可用，返回兜底的静态FAQ链接。

关键在于，这四个状态不是内部状态，而是对外暴露的API响应字段。前端必须根据status字段渲染不同UI，后端必须根据failure_code触发不同降级逻辑。这听起来很重？但比线上事故后花三天排查“到底哪次调用出了问题”要轻得多。

3.2 重试的“成本-收益”动态评估：不是次数越多越好，而是越准越好

传统重试是固定次数（3次），这很粗暴。状态感知模式引入了一个动态评估器，它在每次重试前，计算本次重试的预期收益和成本：

收益预测：基于历史数据，估算本次重试成功的概率。比如，第一次调用超时，大概率是瞬时负载高，重试成功率85%；但如果连续两次都返回ERR_CONTENT_BLOCKED，说明输入本身违规，再重试100次也没用，收益趋近于0。
成本核算：包括直接成本（API调用费用、GPU计费）和隐性成本（用户等待时间、系统资源占用）。我们给每个状态设置了成本权重：Pending权重1，Processing权重2，Uncertain权重3（因为要启动澄清交互），Failed权重5（因为要触发降级和告警）。
决策引擎：只有当“预期收益 × 收益价值 > 本次重试成本”时，才执行重试。收益价值由业务方配置：比如金融风控场景，一次成功分析价值100分；而电商文案改写，价值可能只有5分。这样，风控系统会更激进地重试，而文案工具则更早降级。

实操中，我们用一个简单的滑动窗口统计来实现：维护一个长度为10的数组，记录最近10次同类型请求的status序列。如果其中Failed出现超过3次，或Uncertain连续2次，系统自动将该请求类型标记为“高风险”，后续所有请求默认启用“快速失败”策略——即第一次失败就降级，不再重试。这个机制让我们在一次大促期间，将AI客服的平均响应时间降低了40%，同时用户满意度反升了12%，因为大家不再忍受漫长的“处理中…”等待。

3.3 失败不是终点，而是服务升级的入口

最体现设计模式深度的地方，在于它如何定义“失败”。在状态感知模式里，Failed状态从来不是终止信号，而是服务升级的触发器。我们为每个failure_code预设了升级路径：

failure_code	升级动作	执行主体	SLA
ERR_MODEL_TIMEOUT	切换至轻量级蒸馏模型（响应<500ms）	后端路由网关	2s内返回
ERR_CONTENT_BLOCKED	启动人工审核队列，同步推送至合规专员工作台	消息队列 + 工单系统	15分钟内响应
ERR_TOKEN_EXCEEDED	自动分块重试，并返回“已处理前3页，完整版请下载PDF”	前端SDK	即时返回摘要
ERR_CONTEXT_OVERFLOW	触发“关键信息抽取”子流程，仅保留合同主体、金额、违约条款	微服务集群	3s内返回

注意，所有这些升级动作，都发生在同一个HTTP请求生命周期内。用户不会看到“重试失败”，只会看到“已为您启用快速分析模式，结果如下…”或“您的内容已进入合规审核流程，预计15分钟内完成，期间可继续其他操作”。这彻底改变了用户对AI失败的认知——它不再是系统无能的表现，而是一种更高级别的服务保障。

注意：不要试图在单次请求里完成所有升级动作。把“升级”设计成异步事件驱动。比如ERR_CONTENT_BLOCKED触发后，后端立即返回一个upgrade_id给前端，前端用这个ID轮询升级状态，后端则通过消息队列把任务推送给人工审核服务。这样既保证主链路响应快，又确保升级动作可靠执行。

4. 输出沙盒与可逆执行模式：为什么你敢让AI修改生产数据库？

4.1 沙盒不是隔离，而是构建“可预测的现实镜像”

让AI直接操作数据库、调用支付接口、发送邮件，是很多团队的梦想，也是最大的雷区。常见的解决方案是“加审批”——AI生成指令后，弹窗让用户点“确认”。但这治标不治本：用户根本看不懂“UPDATE users SET balance = balance - 199.00 WHERE id = 12345”意味着什么。输出沙盒模式，本质是让AI的每一次“行动意图”，都在一个与生产环境1:1同步的镜像中，先行推演其全部影响。

这里的关键词是“镜像”，不是“副本”。副本可能数据陈旧，而镜像必须实时同步。我们采用CDC（Change Data Capture）技术，监听生产库的binlog，毫秒级将变更同步到沙盒库。更重要的是，沙盒库不是只读的，它支持全量写操作，但所有写入都会被拦截、记录、并打上sandbox:true标签，绝不流向生产。这样，当AI生成一条SQL：“将订单#ABC123的状态改为‘已发货’，并扣减库存5件”，系统会：

将这条SQL在沙盒库中真实执行；

拦截所有变更，生成一份“影响报告”：

{ "affected_tables": ["orders", "inventory"], "rows_affected": {"orders": 1, "inventory": 1}, "data_changes": [ {"table": "orders", "id": "ABC123", "field": "status", "old": "待发货", "new": "已发货"}, {"table": "inventory", "sku": "SKU789", "field": "quantity", "old": 100, "new": 95} ], "foreign_key_impacts": ["触发订单日志表插入", "触发库存预警检查"] }

将这份报告，以人类可读的方式呈现给用户：“此操作将：① 更新订单状态；② 扣减商品SKU789的库存5件（当前剩余100件）；③ 自动生成发货日志；④ 检查库存是否低于预警线（当前未触发）”。

用户看到的不是冰冷的SQL，而是业务层面的影响全景。这才是真正的“可理解的控制权”。

4.2 可逆执行：把“撤销”变成原子操作，而不是祈祷

沙盒解决了“预知”，可逆执行解决“后悔”。传统方案里，“撤销”意味着手动回滚SQL、找备份恢复、甚至联系DBA。可逆执行模式，要求每一次AI触发的生产操作，都自动生成且必须执行对应的逆向操作。这不是简单的“INSERT ↔ DELETE”，而是基于业务语义的精准反转。

比如，AI执行了“给用户张三发放100积分”，可逆操作不是“删掉这条积分记录”，而是“创建一条‘积分冲正’记录，类型为‘AI误发’，金额-100，关联原操作ID”。这样做的好处是：审计合规（所有操作留痕，不可抵赖）、业务清晰（财务报表能准确反映净变化）、用户体验好（用户看到“您收到100积分”和“系统检测到误发，已冲正-100积分”，而不是账户余额莫名少了100）。

技术实现上，我们在业务服务层加了一个“操作编排器”。当AI请求触发一个动作（如AwardPointsCommand），编排器会：

先生成正向命令（AwardPointsCommand）；
再自动生成逆向命令（RevertAwardPointsCommand），并注入原命令的唯一ID；
将两个命令一起提交到事务队列；
正向命令执行成功后，逆向命令进入“待激活”状态，存储在专门的revert_commands表中；
当用户点击“撤销”，系统只需查找对应ID的逆向命令，执行即可。

关键点在于：逆向命令的生成，必须在正向命令执行前完成。这样即使正向命令执行到一半失败，系统也能保证逆向命令可用。我们用Saga模式实现：正向命令是Saga的主事务，逆向命令是补偿事务，两者在同一个分布式事务框架下管理。

4.3 沙盒与可逆的组合拳：构建AI操作的“双保险”

单独看沙盒或可逆，都只是半解。它们的威力，在于组合。我们曾在一个供应链系统中部署这套组合：

场景：AI根据天气预报和历史销量，自动调整明日各仓库的备货计划。
沙盒阶段：AI生成调整方案后，先在沙盒中模拟执行，生成影响报告：“华东仓A将增加SKU123备货200件（当前库存500），预计占用资金12万元；华南仓B减少SKU456备货150件（当前库存300），释放资金8万元”。
用户确认后，正向执行：真实调整生产库的备货计划表。
同时，可逆命令生成：一条RevertStockPlanCommand，包含所有调整的原始值和时间戳。
如果第二天突发暴雨，实际销量远低于预测，运营人员点击“撤销”，系统瞬间恢复昨日计划，且所有关联的采购单、物流调度单都自动回滚到前一状态。

这个过程，用户全程感知不到技术细节，只看到“计划已更新”和“已恢复至昨日计划”。而背后，是沙盒提供的确定性预判，和可逆执行提供的零风险兜底。这才是企业级AI应用该有的样子——不是炫技，而是让业务人员敢于把决策权，放心地交出去一小部分。

实操心得：沙盒库的同步延迟必须<100ms，否则影响报告的准确性。我们用Flink CDC替代了传统的Debezium，将延迟从平均300ms压到45ms。另外，可逆命令的存储必须和主业务库物理隔离，防止主库故障导致无法撤销。我们把它放在独立的PostgreSQL实例上，每天全量备份。

5. 常见问题与排查技巧实录：那些文档里不会写的“血包”

5.1 “模型输出突然变差，但API返回全是200”——查输入净化层的“静默降级”

现象：某天早上，客服AI的回复质量集体下滑，用户投诉增多，但监控显示LLM API成功率99.9%，延迟正常。排查思路往往陷入“是不是模型版本更新了？”“是不是prompt被污染了？”，结果折腾半天，发现是输入净化层出了问题。

真相：我们有个OCR校验规则，当识别置信度<0.7时，标记为“待人工复核”，并返回一个占位符文本“[OCR结果待确认]”。但某次发布，开发误把占位符写成了“[OCR结果待确认]”，少了一个右括号。这个字符串被当作普通文本喂给了模型，而模型恰好在训练数据里见过大量类似占位符，于是开始“脑补”——把“[OCR结果待确认”当成某种特殊指令，生成了大量包含“请稍候，系统正在确认…”的无效回复。

排查技巧：

在输入净化层的日志中，加一个“净化后文本长度分布”直方图。正常情况下，用户输入长度集中在50-200字符；如果某天突然出现大量10-20字符的短文本，且内容高度相似（如全是[OCR结果待确认），就是线索。
对净化后的文本做MD5哈希，统计高频哈希值。如果某个哈希值占比突增>5%，立刻告警。
在净化层加一个“异常模式检测器”，用正则匹配常见占位符、乱码前缀（如``、□）、重复字符（如aaaaa），命中即记录为purification_anomaly，并采样上报。

解决方案：净化层必须有自己的健康检查，不能依赖下游模型反馈。我们后来加了一条硬规则：任何净化后文本，如果包含非UTF-8字符、或连续重复字符>5个、或长度<10且不含中文/英文字母，一律拦截并返回标准化错误码PURIFY_INVALID_INPUT，前端展示“输入内容异常，请重新提交”。

5.2 “重试了三次，每次都返回不同结果”——状态感知模式下的“确定性缺失”诊断

现象：用户提交同一请求，三次重试结果完全不同：第一次说“风险高”，第二次说“无风险”，第三次说“需人工审核”。这比直接失败更可怕，因为它摧毁了用户对系统的基本信任。

根因分析：这不是模型不稳定，而是重试时丢失了关键上下文。状态感知模式要求每次重试，都携带完整的context_snapshot（包含原始输入、净化后输入、意图标签、历史重试次数）。但我们发现，某次升级后，前端SDK在重试时，只传了原始输入，没传净化后的版本，导致后端每次拿到的都是“脏输入”，模型自然每次解读不同。

排查速查表：

现象	可能原因	快速验证方法	修复方案
重试结果随机波动	重试时上下文丢失	抓取三次重试的完整请求体，对比`context_snapshot`字段是否一致	强制SDK在重试时clone整个请求对象，而非只传input字段
`Uncertain`状态频繁触发	意图锚定Schema不匹配	查看`intent_schema`字段，对比用户选择的选项与实际输入的关键词是否冲突	在前端加实时校验：用户选择“适配银发族”后，输入框自动提示“请避免使用‘yyds’‘绝绝子’等网络用语”
`Failed`后无降级动作	降级策略未生效	检查`failure_code`与配置中心中`fallback_strategy`的映射关系是否最新	降级策略配置必须热加载，禁止重启服务才能生效

独家技巧：在重试逻辑里，加一个“结果一致性校验”。对三次重试结果，分别提取关键实体（如合同编号、金额、日期），计算Jaccard相似度。如果任意两次相似度<0.3，自动标记为RETRY_INCONSISTENT，并触发专项分析任务——这比等用户投诉快得多。

5.3 “沙盒报告看着没问题，但生产执行后出错了”——镜像同步的“最后一公里”陷阱

现象：沙盒里执行SQL一切正常，影响报告完美，但生产库执行时，报错“违反外键约束”。查日志发现，沙盒库的外键检查被关闭了，而生产库开启了。

这是镜像同步中最隐蔽的坑。沙盒库为了性能，常关闭外键、唯一索引等约束，但这就导致沙盒里能跑通的SQL，在生产库可能失败。

排查四步法：

比对Schema：用pt-table-checksum工具，每日自动比对沙盒库与生产库的表结构、索引、约束。差异项自动告警。
开启沙盒约束：在沙盒库的my.cnf中，设置foreign_key_checks=ON，sql_mode=STRICT_TRANS_TABLES，让它和生产库完全一致。性能损失可通过增加沙盒库资源配置弥补。
执行前预检：在沙盒执行SQL前，先运行EXPLAIN和SHOW CREATE TABLE，检查涉及的表是否有外键、触发器、分区等特性，如果有，额外生成一条“约束兼容性报告”。
生产执行熔断：在生产执行前，加一个轻量级校验：用同样的EXPLAIN在生产库跑一遍，如果执行计划差异过大（如沙盒走索引，生产走全表扫描），立即熔断并告警。

我们吃过这个亏。后来规定：沙盒库的Docker镜像，必须和生产库MySQL版本、配置参数完全一致，连innodb_buffer_pool_size的百分比都要相同。镜像不是用来省事的，是用来复现真实的。

5.4 “可逆执行后，业务数据对不上”——补偿事务的“幂等性”破防

现象：用户撤销一次AI操作后，再次执行相同操作，发现积分被扣了两次。查日志发现，可逆命令执行了，但正向命令的补偿事务，被重复触发了。

根因：可逆命令的执行，没有设计成幂等的。第一次撤销时，系统执行了RevertAwardPointsCommand，扣除了100积分；但用户刷新页面后，前端又发了一次相同的撤销请求，后端没做去重，又执行了一遍，再扣100积分。

解决方案：给每条可逆命令加全局唯一ID（UUID），并在revert_commands表中建唯一索引。执行前先INSERT IGNORE，成功则执行，失败则说明已存在，直接返回“已撤销”。同时，在正向命令的补偿事务里，加一个compensation_executed标志位，每次执行前先检查，避免重复补偿。

经验总结：可逆执行的难点，不在“逆”，而在“控”。控制它的触发时机、执行次数、失败重试，比控制正向操作更难。我们最终把可逆执行模块，做成了一个独立的gRPC服务，所有撤销请求都走它，由它统一管理状态和幂等性。这多了一次网络调用，但换来的是绝对的可靠性。