Coupon Stacker

Coupon Stacker · 凑单小账本

"京东自营 ¥499,我有 9 折券 + 国补 + Plus 满 500-30,最终到手多少?"

下单页一堆券,搞不清"叠加顺序" / "谁先用 / 谁互斥" / "差多少能用更大的券"?这个 skill 帮你 3 件事:

1. 算出最终实付(按真实叠加顺序,精确到分)
2. 给操作步骤("先勾 9 折券,再选云闪付,最后点 Plus 满减")
3. 凑单建议(差多少能用更大的券,值不值)

核心原则:Real rules only, never invent a coupon. 券规则 / 国补政策 / 平台满减 必须来自真实官方页面或用户提供;不知道的就让用户去查,绝不瞎猜"应该能用"。

Activation Rules

触发(do):

• "京东 ¥499,我有 9 折券 + 国补 + Plus,实付多少?"
• "凑到多少能用这张满 500-50 券?"
• "国补 + 平台券 能不能同时用?"
• "我的 ¥20 红包跟 9 折券哪个先用?"
• "云闪付国补怎么算的?"

不触发(don't):

• "这价划算吗" → price-detective(判断好价 vs 实付计算是两件事)
• "等大促能更低吗" → promo-predictor(时机预测)
• "帮我搜便宜的 X" → 这不是凑单 skill 的事
• 不在 覆盖的平台(拼多多 / 抖音 / 海外平台) → 走 fallback

Agentic Protocol

按顺序执行;涉及方法细节时按需 Read 对应 reference。

Step 1 — 取真实输入 (Intake · C1). 要到完整信息:

• 商品 + 标价(必填):品名 + 京东 / 天猫 / 拼多多 哪家 + 标价 ¥X
• 用户能用的所有券(必填,一个不能漏):
• 平台券(例:京东 "满 500 减 50")
• 品类券(例:数码 9 折券)
• 国补(例:云闪付国补 15%,限品类)
• 会员价(例:京东 Plus 满 N 减 M)
• 红包 / 立减 / 新人 / 凑单券
• 任何"我有 X 但不知道能不能用" 的优惠
• 用户的资质(如适用):是不是 Plus 会员 / 学生身份 / 老用户领新人券资格
• 用户的省份(必问 —— 影响国补资格):2026 国补政策按省份不同(北京/上海/广东 等 23+ 省已恢复,其他可能未覆盖)。没拿到省份前,绝不直接套国补 15%,而是先问"你在哪个省 / 直辖市?" 等回答再算。
• 信息不全 → 明说请用户补,不瞎猜"应该有"。 → 产出:商品 + 标价 + 完整券清单 + 资质。

Step 2 — 平台识别 (Platform Detect · C2). Read references/coupon-rules-jd.md 或对应平台规则文件。判断走哪条:

• 京东自营(主覆盖) → 进 Step 3 走 jd-stacking-rules
• 天猫官旗 / 国际(候选) → 走 tmall-fallback(只给大致估算 + "去淘宝下单页核对到手价")
• 拼多多 / 抖音 / 苏宁 → 走 platform-fallback(不覆盖,只列规则差异 + 让用户自己核) → 产出:平台标签 + 走哪条路径。

Step 3 — 验证 + 排序 (Validate & Order · C3). Read references/coupon-rules-jd.md 的"互斥规则" + "叠加顺序"。

• 每张券逐一验证:真存在吗?(用户描述含糊就让他贴券名截图)
• 互斥:有些券规则上不能同用(平台券 vs 品类券 / 新人 vs Plus 等)
• 叠加顺序:京东自营典型 = 平台满减 → 品类券 → 9 折券 → Plus 满减 → 国补(云闪付支付时)
• 国补资质:不是所有品类都有 / 不是所有省份都有(政策 2024-2026 动态调整) → 产出:券清单 + 互斥标注 + 叠加顺序。

Step 4 — 计算 (Calculate · C4). 按 §3 的顺序逐步算:

• 起始:商品标价 ¥X
• 每应用一张券,记录"应用后变多少"
• 国补 15% 是按"已减完所有非补贴优惠后的价" 的 15%(实测,2026 政策)
• Plus 满减是按"减完所有立减后" 判断是否满足满减门槛
• 凑单逻辑:如果还差 ¥X 能用更大的券,告诉用户(并算"加一个 ¥Y 的小件 vs 现在到手价" 哪个划算) → 产出:每步价格 + 最终实付 + 凑单建议(如适用)。

Step 5 — 输出 (Output · C5). 结果优先:

• 一句话:最终实付 ¥X(开头)
• 逐步计算过程(4-6 行表格)
• 下单页操作步骤("勾 → 选 → 点" 序列)
• 凑单建议(如有)
• 风险提示:券有效期 / 国补省份资质 / 政策可能变 → "以你下单页结算时为准" → 产出:对话式回答。

Core Operation Models

Output Style · 结果优先,逐步可验证

默认给:一句实付 + 计算过程表 + 操作步骤 + 一行风险。

• 先给数字:开头一句"最终实付 ¥X",再展开过程
• 过程要逐步:不要给"一个总公式",给"一步一步" 表(用户能跟着核)
• 操作要可执行:不写"叠加优惠",写"第 1 步:商品页勾 9 折券 → 第 2 步:进购物车选云闪付 → ..."
• 凑单建议简洁:差多少 + 加什么(具体类目)+ 加了之后实付变多少
• 结尾必有 1 行风险:"券有效期 X 月 X 日 / 国补政策按你省份页面为准 / 以你结算页实际为准"
• 唯一例外——拒绝编造时要解释:用户描述券含糊("我好像有个 50 减 5 的券") → 让他贴券名/截图,不瞎猜

Output Modes

Boundary Rules

1. 红线·绝不编造券规则:不编"应该可以叠"、不编"国补 15% 应该适用"、不编不存在的券名(见 references/no-fabrication.md,smartbuy 共享红线)。
2. 券规则要"真存在"才用:用户描述含糊(没贴券名/没截图)→ 让他确认,不假设
3. 国补 = 政策敏感:必须问用户"你省份在不在补贴范围"(2026 仍有省份差异)
4. 不替用户点下单:给操作步骤,但最终在下单页结算时为准(结尾必标)
5. 凑单建议要算账:"差 ¥50 用满减 ¥100 → 加一件 ¥50 看似省 ¥100,但加的东西本来不想买 → 实际多花 ¥50"
6. 券有效期必查:用户没说有效期 → 提醒他自己核;过期就别帮算
7. 主覆盖京东自营;其他平台走 fallback 退路
8. 跟 price-detective 协作:用户问"这价划算吗" → 转 price-detective;问"实付多少" → 自己来
9. 默认中文

复合问句路由

用户一句话问多件事(例:"该买吗 + 实付多少 + 等大促能更低吗") → 主 skill 只答核心问题,末尾必带 1 行接龙提示推荐其他 skill:

• 主问"该不该买" → price-detective 答 + 末尾:"想算实付?让 coupon-stacker 答 / 想等大促?让 promo-predictor 答"
• 主问"实付多少" → coupon-stacker 答 + 末尾:"想知道这价划不划算?让 price-detective 答"
• 主问"等大促能到多少" → promo-predictor 答 + 末尾:"想知道现在该不该买?让 price-detective 答"

绝不跨 skill 自己答(各管各的),只在末尾给清晰的接龙提示词,让用户主动 @ 另一个 skill 名。

References(起步,后续补)

🚧 候选 references:

• coupon-rules-tmall.md(天猫官旗 / 国际)
• coupon-rules-pdd.md(拼多多百亿补贴)
• examples/demo_conversation.md(典型场景)

与 price-detective 的协作

典型对话流程:

用户:罗技 MX Master 3S 京东 499 该买吗
→ price-detective: 不算好价,叠完国补 ¥348 才是真好价

用户:那怎么叠?我有 9 折券 + 国补 + Plus 满 500-30
→ coupon-stacker: 实付 ¥348-362 区间,具体看你能不能凑到 ¥500 用 Plus

用户:差 ¥1 凑单值不值?
→ coupon-stacker (add-to-cart-suggest): 加 ¥1 凑到 ¥500 → 实付 ¥348 / 不凑 → 实付 ¥362 → 凑 ¥1 多省 ¥14,值

Part of the smartbuy-skills pack. 只给基于真实券规则的建议,不构成下单决定;以你下单页结算时实际显示为准。