餐饮SaaS系统迁移中的优惠券重建痛点，如何从3小时压缩到4分钟？本文通过17个版本的实战复盘，揭秘AI Skill如何攻克参数映射、单位转换、边界校验等20+关键坑，最终实现Excel批量导入与对话式创建的效率革命。从接口文档外的隐性规则挖掘到工程化细节打磨，这是一场关于AI落地真实业务场景的深度解剖。
这是一篇关于”用 AI Skill 解决一个具体业务痛点”的实战复盘。所有问题和数据都来自真实的生产环境实测，希望能给同样在做 AI Agent / Skill 落地的产品同学一些参考。
一、先说结论：我到底解决了一个什么问题如果你做过餐饮 SaaS，大概率听过运营同学的这句抱怨：
“又要换系统了，几百上千张优惠券得一张一张重新建……”
这件事的痛点非常具体。当商家从旧的收银/营销系统迁移到新系统时，原来配置好的优惠券没法直接搬过来，只能在新后台里重建。而一张券通常要填 20 多个字段——门槛、面额、有效期、适用门店、适用渠道、叠加规则、限领限用……
我们实测过：纯手工建 100 张券，要花 3 到 5 个小时，而且因为字段多、单位容易错（”元”和”分”的坑后面会讲），出错率非常高。
我想解决的就是这件事。最终做出来的东西，覆盖了两个场景：
场景一：系统切换批量迁移。面向运营和实施人员。用户把券信息整理成一份 Excel 上传，AI 自动识别字段语义、完成参数映射和单位转换，再通过后台 API 批量创建。
场景二：AI 对话式创建。面向不熟悉后台的商家。直接说一句”创建一张满 30 减 5 的代金券，有效期 7 天”，AI 理解意图、映射参数、调用接口完成创建。
最终成果，用一组对比数据最直观：
最近一次实战，5 种券类型共 19 张券，4.5 分钟创建完成；单张券创建稳定在 30 秒以内。
但这个结果不是一蹴而就的——它是 17 个版本、约 300+ 轮对话、近 400 +次接口调用、踩了 20+ 个关键坑之后的产物。下面我把这条路重新走一遍。
二、从 V1 到 V17：每个阶段都在解决一类问题我把整个迭代过程分成了六个阶段，每个阶段的核心矛盾都不一样。
方向探索期（V1~V3）：先让它能跑通最开始我走了一条弯路——用浏览器自动化去填后台表单，靠模拟键盘逐字符输入、注入页面状态。这个方案极度脆弱：页面结构一改就全崩，而且每张券要等 30 秒以上。
转折发生在 V2：我发现后台其实有一个可以直接调用的创建接口，完全能绕过浏览器。这是一个架构级的决策——单条创建时间从 30 秒直接干到了 1 秒。
V3 第一次端到端跑通了最简单的代金券。虽然字段映射还是硬编码、没有任何容错，但至少证明了”接口调用”这条路是对的。
心得：先让最简单的场景跑通，再逐步扩展。不要一上来就想着覆盖所有情况。
踩坑高峰期（V4~V6）：参数地雷阵这是整个项目最痛苦的阶段，几乎每个字段背后都埋着一颗雷。
第一颗雷：静默覆盖。某个门槛类型字段如果传错值，接口不会报错，但会悄悄把”满 30 减 5″变成”无门槛减 5″。接口返回成功，只有在后台手动查看时才会发现门槛没了。排查这个问题花了我整整一天——这是生产事故级别的”假成功”。
第二颗雷：金额单位。接口接收的是”分”，但用户 Excel 里写的是”元”。忘了乘 100，”5 元券”就变成了”5 分券”发出去了。
第三颗雷：数组字段不能传 null。所有列表类字段如果传 null 而不是空数组 ，会触发一个完全看不懂的反序列化异常。
第四颗雷：规则字段不能为空字符串。适用门店的规则字段必须是一段合法 JSON，传空字符串同样直接报错。
心得：接口里”不报错但行为不符合预期”的坑，比”直接报错”危险十倍。所以我下定决心：必须建立”创建后校验”的闭环，绝不能只看到 success 就认为搞定了。
多券类型扩展期（V7~V9）：复杂度爆炸从只支持代金券，扩展到商品兑换券、折扣/特价券、配送券。每种券都有自己的”专属脾气”：
折扣券的规则类型字段必须显式传，不能依赖默认值，否则会以一种诡异的方式”创建成功但类型显示异常”；配送券的渠道和子类型是固定的，缺任何一个都报同一个错误码，但错误信息只说”券设置信息错误”，根本不告诉你缺了啥；商品兑换券的商品列表如果为空，注定创建失败——这意味着要在预校验阶段就把它标出来。
心得：每种券类型都是一个独立的知识域，不能用”大概差不多”的心态去套。必须为每种类型建立独立的字段映射表和校验规则。
工程化期（V10~V12）：从”能用”到”好用”核心逻辑稳定后，我开始补工程化细节：
把商家上下文信息做了缓存，命中直接用，首次准备时间从 30 秒降到 0；针对长对话后连接会静默断开的问题，加了创建前的心跳探测，连接断了立刻提示用户开新会话，而不是傻傻地发请求等”无响应”；把创建结果写回文件（成功/失败、模板 ID、错误原因），方便用户追溯。
心得：一个工具从”能用”到”好用”的距离，就是这些工程化细节的总和。缓存、心跳、容错、结果回写——每一个单拎出来都不是核心逻辑，但缺一个，体验就断崖式下降。
边界测试期（V13~V15）：从”好用”到”可靠”我设计了 101 条覆盖各种边界的代金券测试用例：金额极值、标题含 emoji 和特殊字符、时间跨度边界、门店 ID 不存在等等。这一轮撞出了大量接口文档里根本没写的隐藏规则，比如：
“允许叠加使用”时，每人每天限用张数必须大于等于叠加次数，否则报错；指定门店后，门店规则字段不能再是”全选”,必须同步指定门店 ID;还有个不可用日期字段,我试了三种日期格式全部报错,至今没找到正确写法——已经如实标记为”待确认”。
心得：接口文档永远是不完整的。真正的规则藏在服务端代码里，只能靠系统性的边界测试一个一个”撞”出来，然后沉淀进排障指南。
全覆盖与标准化期（V16~V17）：收口最后阶段，我完成了配送券的验证（它是最后一个搞定的券类型），提供了一份多 Sheet 的标准 Excel 导入模板（每种券一个 Sheet，列名和字段一一对应），并针对商品兑换券做了 67 条边界测试，覆盖 34 个字段的各种组合。
心得：核心逻辑稳定后，迭代重点会从”修 bug”转向”扩覆盖”和”标准化”。一份好的模板和文档，比代码本身更能降低使用门槛。
三、关于”怎么验证 AI 真的做对了”AI 最坑的地方，是它会非常自信地告诉你”已完成”，但实际上根本没做对。所以校验这一环我花了不少心思：
第一步，让 AI 根据后台字段自己批量生成测试用例；第二步，人工抽查易错场景——满减、每满减、限次、指定菜品这类最容易出问题的 case 重点核对，确认”成功”的结果到底有没有真成功；第三步，发现问题后做单点测试，把一张券拆成基础信息、券类型、优惠门槛、优惠规则、优惠次数等模块，用自然语言一个模块一个模块地试，哪里不对就针对性地反复测。
那么，怎么降低 AI 在”已经定好规则”之后还犯错？我总结了几条做法：每一次错误都沉淀进案例库，沉淀完让它自己复盘走一遍看还会不会再犯；一个会话只做 2~3 次创建，后续修改或新建就开新会话；批量数量控制在 100 张左右，准确率最高；以及——果断删掉那段”自作聪明”的推理逻辑。
四、几条可以复用的方法论走完这 17 个版本，有几条经验我觉得是跨场景通用的，分享给同样在做 AI Skill / Agent 的同学。
1. 先窄后宽，先简后全。V1 只做代金券，V7 才扩展第二种。每种类型完全验证通过再开下一种——因为前一种的踩坑经验能复用到后一种，整体反而更快。
2. 每次失败都是知识沉淀的机会。每一个错误码、每一条诡异报错，都应该被记进排障指南。我那份完整的服务端校验规则表，不是一次写出来的，是 17 个版本里一条一条加出来的。
3. 结果必须可追溯。创建结果一定要持久化——写回文件、记录模板 ID、保存错误信息。这样用户后续发现某张券有问题，能立刻定位是第几行、什么参数、返回了什么错。
4. Skill 不是一次性产出，而是持续演化的知识体。V1 的主文件只有 50 行，V17 的主文件加参考文档超过 1000 行。它不是设计出来的，是在实战中长出来的。一个好的 Skill，本质上是一个活的知识库。
5. 在模糊中摸清边界。过程中 AI 多次”声称已完成但其实没有”，问得多了你会发现，它有些判断确实是在”硬编”。所以人的把关不能省。
6. 卡住时，找懂技术的人。很多卡点 AI 会在里面来回绕，反复”好像是这个、好像是那个”却定位不到。这时候和技术同学聊十分钟，往往比 AI 自己绕一小时更有效。
写在最后这件事最大的体会是，AI 落地一个具体业务场景，难的从来不是”调通接口”，而是把那些藏在文档之外、只有踩过才知道的隐性规则一条条挖出来，再让 AI 稳定地遵守它们。这是个体力活，也是个细致活，但跑通之后的效率提升，确实是数量级的。
本文由 @帅气滴呼呼 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
配资平台提示：文章来自网络，不代表本站观点。
