01
用 AI 监听公开讨论找客户：零依赖、本地运行的销售线索发现器，一次运行约 $0.07
AI + 销售自动化
Lead Generation
本地优先
零第三方依赖
首次开源 2026-10-10
66★ / 5 Fork
一句话结论：它把「找客户」这件长期靠人情和运气的事，做成了一条可配置、可审计、成本可算到分钱的生产线——而且核心逻辑不用大模型，用的是你能读懂也能改的规则。
01｜案例是什么？
Lead Signal Listener 是一个本地的销售线索发现工具。它的定位一句话说清：「在竞争对手之前，找到那些正在公开描述『你能解决的问题』的人。」它监听 Reddit、X、LinkedIn 帖子、LinkedIn 招聘、Facebook 帖子与群组、Instagram 话题与 Reels、融资新闻、Hacker News、YouTube、新闻与 RSS——也包括 Treg 目录里的 3800+ 个数据端点，还能捕捉「正在招人」「刚拿到融资」这类触发信号。每条线索会被打分、去重、排队，你可以先看分最高的。评分规则是一份可编辑的 JSON，改完点一下就能对已有线索重新打分。整个工具跑在你本机，只监听 127.0.0.1，不联网托管。
02｜为什么今天值得关注？
- 为什么是现在：2026-10-10 首次开源（北京 15:20），当天完成全部推送。它是本期窗口内唯一一个把「AI 销售自动化」做到可运行、成本可量化、且默认配置自带真实运行数据的开源项目（README 明确写出：默认关键词示例运行得到 284 条线索，花费 $0.073）。
- 以前为什么不容易做：线索发现长期是两难：买现成的 B2B 数据服务（贵、且名单是通用的，不针对你的问题）；或者人工刷平台（不可能覆盖十个来源）。用 LLM 直接扫平台也走不通——成本高、结果不可复现、而且你无法解释「为什么这条排第一」。
- 为什么现在变得容易：三个条件同时到位：① 公开内容的检索接口可以按次计费（Treg 这类聚合层把 Reddit / X / LinkedIn 等统一成一次调用 $0.0005–0.03）；② Hacker News、RSS 这些免费源本身就能承担冷启动；③ 规则引擎足够便宜——评分不用 LLM，用关键词规则就能筛掉 90% 噪音，把 LLM 留到「需要深入判断」的最后一步。
03｜案例的前世今生
前世。「监听公开讨论找线索」这件事本身不新——早年是舆情监控，靠关键词告警；后来是社交聆听工具，靠人工配置规则看板。痛点始终一样：监控结果是一堆帖子，不是一份可跟进的名单。销售拿到的还是噪音，得自己一条条看。
发展。LLM 出现后，第一波解法是「把帖子喂给模型判断是不是线索」。这条路线的代价很快显现：按条计费成本不可控、同一批数据跑两次结果不同（不可复现）、而且没法解释排序依据。于是出现了一个反向思路——把「可判定的部分」交还给规则，把「需要理解的部分」留给模型。
今生。2026-10-10，作者开源了这个项目，把上述判断落成了具体设计：评分完全基于规则（痛点短语、意图短语、人群词、互动量、是否提问、负面短语），透明、免费、可编辑；想更深入时，导出 JSON 交给 LLM 做资格判定，而不是让 LLM 从头扫一遍。同时它把成本控制做成了一等公民：单次调用上限、单次运行预算、1 小时内幂等重放不重复计费、token 失效或余额为零自动中止整次运行。
另一个值得记录的细节：作者在仓库里放了一份 docs/showcase.html，完整展示了「从想法到开源发布」的一次 AI 对话记录——项目本身被作者标注为「在一次 AI 对话中构建完成」（提交记录中多处共同署名为 Claude Opus 5.5）。这让本案例同时成为「AI 辅助开发」的一手样本。
下一步可能怎么发展（以下为分析 / 推演，非事实）：① 从「通用找线索」细化为垂直行业监听器（外贸、SaaS、跨境电商各有各的痛点短语库）；② 与 CRM 打通，形成「发现 → 跟进 → 记录」闭环；③ 评分规则库可能成为可交换的资产（谁来维护「什么叫高意向」的判断标准）；④ 国内替代路径是把 Treg 换成国内数据源，做本地化版本。
04｜原始资料
05｜作者是谁？
GitHub 账号 yangyixxxx，X 账号 @yangyi；README 标注项目由 newmax.ai 构建，底层数据能力来自 treg.to（其作者 Jason Zhou，X @jasonzhou1993）。项目内置中英双语界面与中文说明文档，作者在开发过程中使用 Claude Opus 5.5 辅助（提交共同署名）。
说明：本报告未独立核实其真实姓名、所在地与公司信息，不做推测。可确认的是作者具备完整的工程交付能力（零依赖架构、成本控制机制、测试目录、i18n）与产品意识（提供让 Agent 代装的引导文档）。
06｜解决了什么真实问题？
从使用者视角，问题非常直白：「我知道我的客户会在网上抱怨这个问题，但我没办法每天盯着十个平台看。」
- 外贸与跨境服务：买家会在 Reddit / X 上直接描述痛点（「我们的物流成本又涨了」「有人推荐靠谱的供应商吗」），但这些帖子存在时间很短，错过就没了。
- SaaS 与 B 端服务：高意向信号往往不是「我想买」，而是「谁能推荐一个工具」「我们正在找人做这件事」——这类表述有很强的时效性。
- 招聘与融资触发：「正在招某个岗位」和「刚拿到融资」是最经典的采购前置信号，但需要有人持续盯着。
- 现有工具的痛点：通用 B2B 名单不针对你的具体问题；舆情工具给你的是帖子不是名单；LLM 全量扫描成本不可控且不可解释。
07｜完整技术栈
| 语言 | Python 3.10+ |
| 依赖 | 零第三方依赖（README 明确标注） |
| 存储 | SQLite（data/signals.db） |
| 服务 | 本地 HTTP 服务，仅监听 127.0.0.1:8787；单页 UI（static/index.html） |
| 国际化 | 双语界面（EN / 中文），服务端消息 i18n（listener/i18n.py） |
| 字体 | 内置 OFL 字体，本地打包、离线可用，不依赖 Google Fonts |
| 免费数据源 | Hacker News（Algolia API）、RSS / Atom（Google Alerts、Reddit 的 .rss、hnrss.org、博客、招聘板，可加关键词过滤）、Import（导入 JSON） |
| 付费数据源 | 经 Treg 调用：Reddit（$0.002/次）、X（$0.00075–0.015）、LinkedIn 帖子（$0.002）、LinkedIn 招聘（$0.0005）、Facebook 帖子（$0.03）、Facebook 群组（$0.002）、Instagram 话题（$0.002）、Instagram Reels（$0.0015）、融资新闻（按结果计）等 |
| 模型 | 核心评分不使用 LLM（规则化）。README 建议：需要更深入的资格判定时，导出 JSON 交给 LLM |
| 协议 | MIT |
08｜完整 Workflow
① 描述你在找谁（Listeners 页）：填写目标人群描述，勾选启用的来源，逐行添加关键词
↓
② 抓取（Listen）：按关键词并发查询各来源。免费源（HN / RSS）与付费源（经 Treg）混用；每个关键词每次运行最多抓 max_pages 页（Reddit / X 默认 3 页，LinkedIn 默认 2 页）
↓
③ 打分（Scoring）：纯规则匹配——痛点短语（如 "traffic dropped"）、意图短语（如 "looking for" "recommend an agency"）、人群词（如 SaaS vs DTC）、互动量、是否为提问、负面短语（自我推广 / 招聘贴 / 垃圾信息）
↓
④ 去重入库：store.py 写入 SQLite 并去重
↓
⑤ 人工审核：按分数排序，状态板切换 All / To review / Qualified / Contacted / Replied / Ignored，可加备注（Ctrl+Enter 保存）
↓
⑥ 输出：导出 CSV / JSON（GET /api/export?fmt=csv|json）
↓
⑦ 反馈调优（回路）：在 Listeners → Scoring rules 里用 JSON 改规则，点 Rescore all leads 对已有线索重新打分
↓
⑧ 可选：交给 LLM 深判：导出 JSON，交给 LLM 做更深入的资格判定（README 明确建议的用法）
内置成本控制机制（README 原文）：单次调用上限（由 Treg 通过 X-Treg-Route-Max-Cost 强制）、单次运行预算（达到即停止分页与后续付费调用）、幂等重放（同一查询 1 小时内重跑不重复计费）、自动中止（token 无效返回 401 或余额不足返回 402 时取消本次运行剩余部分）。花费与调用次数直接显示在 Leads 面板上。
09｜它到底是怎么实现的？
几个关键设计值得单独拆出来：
- 为什么不用 LLM 打分（本案例最重要的判断）：三个理由——成本（按条调用不可控，规则免费）、可复现（同一批数据两次运行结果一致）、可解释（每条线索的分数来自哪几条规则命中，能指给人看）。把 LLM 推到最后一环（对已筛出的线索做深判），成本从「按条」变成「按需」。
- 免费源承担冷启动：没有 Treg token 也能跑——Hacker News、RSS、Import 三条路径完全免费。这让工具可以先被试用、再决定是否付费扩容，是一处很聪明的产品设计。
- RSS 是隐藏的万能接口：README 举例说明可用 Google Alerts、
reddit.com/r/NAME/new/.rss、hnrss.org/newest?q=... 等——等于把任意平台的可订阅内容都变成了线索源，且零成本。
- 安全设计（本地优先的完整实现）：服务仅绑定
127.0.0.1、检查 Host 头（阻止 DNS rebinding 攻击）、写请求必须带 JSON Content-Type、token 在界面上掩码显示且从不写入日志、所有数据留在 data/ 且被 git 忽略（README 明确警告「切勿提交或分享」）。
- 可审计的架构：职责切得很干净——
treg_client.py（HTTP 客户端 / 成本 / 上限 / 幂等）、sources.py（内置源与解析）、generic.py（RSS / 自定义端点 / 导入 / 目录检索）、scoring.py（规则评分）、store.py（SQLite + 去重 + 导出）、runner.py（一次监听）、server.py（本地 API + 调度）。
- 无界面也能跑：
python app.py --run-once 支持放到 cron 或 Windows 任务计划里定时执行；TREG_TOKEN 可走环境变量，密钥永不落盘。
10｜手把手复现
以下整理自项目 README 的官方快速开始（非本报告推导）：
# 需要 Python 3.10+，无第三方依赖
git clone https://github.com/yangyixxxx/lead-signal-listener.git
cd lead-signal-listener
python app.py # 自动打开 http://127.0.0.1:8787
# Windows 用户可直接双击 start.bat
Step 1 · 配置：Settings → 粘贴你的 Treg token → Save → Verify。没有 token 也能用，免费源（Hacker News、RSS、Import）照常工作。
Step 2 · 定义听众：Listeners → 描述你在找谁 → 启用来源 → 添加关键词（一行一个）。
Step 3 · 运行与审核：Leads → Run now → 按分数审核、设状态、加备注 → 导出 CSV / JSON。
另有一条「让 AI 帮你装」的路径（README 原文提供）：把下面这段复制到 Claude Code、Codex、Cursor、NewMax 或任何 coding agent：
Read AGENT_SETUP.md from https://github.com/yangyixxxx/lead-signal-listener
and set up Lead Signal Listener for me. Walk me through choosing keywords and scoring rules.
README 说明该 Agent 会「安装它、访谈你的买家画像、提出关键词与评分规则、在预算内跑第一轮、并和你一起调优结果」。本报告未实际执行上述任一步骤。
11｜Prompt / Code / Config
本案例公开的可复用配置主要是评分规则（JSON）与CLI 参数。评分维度（README 原文）：痛点短语、意图短语、人群词、互动量、是否提问、负面短语。规则在 Listeners → Scoring rules 里以 JSON 编辑，改完点 Rescore all leads 即可对存量线索重新打分——这意味着「判断标准」是可版本化、可交换的资产。
命令行用法（README 原文）：
python app.py --port 9000 # 换端口
python app.py --run-once # 无界面单次运行（cron / 任务计划）
python app.py --data ~/listener-data # 自定义数据目录
python app.py --catalog "tiktok search" # 检索 Treg 端点目录
python app.py --import leads.json # 导入线索
TREG_TOKEN=... python app.py # token 走环境变量，不写入磁盘
本地 API（仅 127.0.0.1）：/api/config、/api/test-token、/api/run、/api/status、/api/signals、/api/signals/counts、/api/signals/<id>、/api/import、/api/rescore、/api/catalog、/api/export。
来源标注：以上全部为原作者公开内容，非本报告推导。
12｜踩坑
坑 1 · 默认关键词只是示例。README 原文明确：默认关键词与评分规则只是一个例子（示例场景是「找那些在 AI 搜索可见性上有困难的公司」），必须换成你自己的目标人群与问题。直接拿默认配置跑，得到的线索跟你的业务无关。
坑 2 · 付费源的失败会中止整次运行。README 原文：token 无效（401）或余额为空（402）会取消本次运行剩余部分。首次配置时务必先 Verify。
坑 3 · 抓取深度有限。每个关键词每次运行受 max_pages 限制（Reddit / X 默认 3 页、LinkedIn 默认 2 页）。也就是说单次运行看不到全部公开讨论，需要靠定时运行累积。
坑 4 · 规则评分的边界。评分是规则化的、不是 LLM 原生判断，因此无法理解反讽、隐喻和上下文。README 给出的应对是导出 JSON 交给 LLM 深判——这也意味着「最后一道判断」仍然需要人工或额外的模型环节。
合规红线（README 明确写出）。原文要求：只采集公开内容，遵守各平台与 Treg 提供商的条款；这是「研究与线索发现工具，不是垃圾邮件加农炮」；触达时必须遵守 GDPR、CAN-SPAM 等规则。界面截图使用的是虚构演示数据，个人昵称已打码。
13｜中国用户能不能直接做？
- 国内访问：GitHub 可访问（部分网络需加速）。运行时若无 Treg token，仅走 Hacker News 与 RSS——这两个源在国内网络环境下也可能不稳定。需自行验证
- 注册：工具本身零注册。付费源需在 treg.to 注册并充值（海外服务，支付需自行解决）。
- API：需要 Treg token 才能用付费源；不需要任何大模型 API Key（核心评分不用 LLM）。
- 成本：免费源 0 元；付费源按次计费（单次调用约 $0.0005–0.03），默认配置一次运行约 $0.07。README 给出实测：默认示例跑出 284 条线索、花费 $0.073。
- 技术门槛：AI 用户级——
git clone + python app.py 两步，零第三方依赖，且提供了让 AI 代装的引导文档。
14｜国产替代方案
| 原方案 | 中国用户方案 |
Treg 付费数据层
（Reddit / X / LinkedIn 等） | 国内平台线索源需整体替换——改造而非替换接口。可对接的方向：微博、知乎、小红书、B站、贴吧、行业垂直论坛、以及各类企业信息查询平台。本项目未内置任何国内源，需要自行开发解析器（参考 generic.py 的 RSS / 自定义端点写法）。 |
| RSS / HN 免费源 | 天然最佳切入点——RSS 是通用标准，把国内平台的 RSS（或第三方 RSS 服务）接进来即可零成本运行；这是中国用户最容易先跑通的一条路。 |
DeepSeek / Qwen / GLM
（用于深判环节） | 可直接使用——导出 JSON 交给国产模型做资格判定，成本远低于国际模型，中文语境理解更有优势。理论上完全可行 |
| 评分规则 | 这是本土化的核心工作量：把「中文语境下的高意向表述」写成规则（如「求推荐」「有没有靠谱的」「打算换」等），比替换技术组件更重要。 |
| Compliance | 国内需关注《个人信息保护法》与各平台条款。README 的合规立场（只采公开内容、不群发）应当保留。 |
15｜中国企业可以怎么用？
- 企业场景 1 · 外贸 / 跨境 B2B：这是最直接的适配场景——海外买家确实在 Reddit / X / LinkedIn 上公开描述采购需求与痛点。用本工具建立「海外买家意向池」，销售按分数跟进。目标市场的语言与文化判断可交给国产模型做深判。
- 企业场景 2 · SaaS 与工具类产品：监听「谁能推荐一个 X 工具」「有没有替代 Y 的方案」这类高意向表述，在用户主动搜索之前就触达。项目自带的「招聘 / 融资」触发信号可用于识别正在扩张的潜在客户。
- 企业场景 3 · 跨境电商服务商：卖家在社群与论坛公开抱怨的问题（物流、退货、合规、税务）就是服务商的销售线索池。
- 企业场景 4 · 市场调研部门：把「负面短语」维度反过来用——不做销售，做产品口碑与竞品舆情监测；导出 JSON 后交 LLM 做归因分析。
16｜中国消费者可以怎么用？
- 自由职业者找单：设计、开发、翻译、咨询类自由职业者的痛点高度集中在外包平台与垂直社群，把 RSS 源接到这些讨论区即可。
- 独立开发者找早期用户：在发产品前先监听「这个问题有人抱怨吗、抱怨的具体措辞是什么」，这比自嗨式做需求验证可靠得多——而且抱怨的原话可以直接变成落地页文案。
- 知识服务与咨询：把「求推荐顾问 / 有没有人做过」这类表述当作高意向信号，先私信答疑建立信任，再谈合作。
17｜如何变成一个赚钱的项目？
- 产品化：项目为 MIT 开源，直接转卖不可行。可行的是「垂直行业的意向规则库 + 国内源适配」——谁把「外贸 / 教培 / 医美 / SaaS 各自的高意向中文表述」整理成套，谁就拥有可复用资产。
- 服务化：「线索发现即服务」。客户要的不是工具，是每周一份可跟进的名单；你可以用这个工具做交付，按周 / 按月收费。这一步的壁垒是关键词与规则调优经验，不是技术。
- 咨询化：帮企业设计「高意向信号定义」——很多企业连「什么样的公开表述算我的客户」都说不清，这本身就是咨询内容。
- 培训化：面向外贸团队 / SaaS 销售团队的工作坊：「如何用公开信息建立自己的意向池」。强调合规边界是这个课程区别于「群发工具培训」的关键。
- 内容化：「我监听了 3 万个帖子，总结出 20 句真正的购买信号」是极好的内容选题，且数据来自你自己的运行。
- 行业化：为某个垂直行业做定制版（如「跨境电商卖家痛点监听」「工业品采购信号监听」），卖的是行业规则库与源适配。
18｜变现路径
| 路径 | 客户 | 产品 / 服务 | 收费方式 | 难度 |
|---|
| 线索即服务 | 外贸 / SaaS / 服务商 | 周度意向名单 | 月度订阅 | 中 |
| 规则库售卖 | 同行业从业者 | 行业高意向表述库 | 买断 / 订阅 | 低 |
| 流程咨询 | 中小企业销售负责人 | 意向信号定义 + 流程设计 | 项目制 | 中 |
| 培训 / 工作坊 | 外贸 / 销售团队 | 公开信息找线索实操 | 按场 / 按人 | 低 |
| 舆情监测转型 | 市场部 / 品牌方 | 竞品与口碑监测 | 项目制 | 中 |
重要说明：以上为基于案例结构推导的潜在商业模式，不是已验证的商业结果。作者未公开任何客户、收入或变现数据。另需强调：无论是销售还是监测，都必须遵守平台条款与个人信息保护相关法规，不得用于群发骚扰——这一点作者在 README 中已明确写出。
19｜如果我是一个中国独立开发者
假设 1 人、预算有限、有基础编程能力、优先使用国产模型，7 天 MVP 路线（以下为本报告建议，非作者原始步骤）：
- Day 1：clone 并跑通，不配 Treg token，只用免费源（RSS / Import）——先确认「工具能跑」这件事与付费无关。
- Day 2：选定一个垂直方向（建议外贸或某个具体服务行业），写出 20 条该行业客户会说的中文原话，作为第一批关键词。
- Day 3：按
generic.py 的写法接入 2–3 个国内可得的信息源（行业论坛 RSS、知乎话题、社群公开内容的订阅入口），跑出第一批线索。
- Day 4：用 Day 3 的结果反向调规则：把误报（自我推广、招聘贴、无关内容）写进负面短语，把漏报补进 intent 短语，然后 Rescore 重跑。
- Day 5：接国产模型做深判——导出 JSON，让模型只回答「这条是否值得跟进、理由是什么」，记录它和你的判断差异。
- Day 6：把整条链设成每天定时运行（
--run-once + 计划任务），产出第一份「每日意向简报」。
- Day 7：拿这份简报去找 3 个该行业的从业者，请他们评价「如果你是销售，这 10 条里你会跟进几条」——这个反馈决定你的规则库值不值钱。
关键判断：这个 MVP 的技术部分 3 天足够，真正的价值在 Day 2 / Day 4 / Day 7——也就是「你是否真的懂这个行业的人怎么说话、以及什么样的线索值得跟进」。技术门槛低意味着竞争不在技术，而在行业理解。
20｜如何迁移到其他行业
① 招聘行业把「融资 / 扩招」信号换成「团队变动、岗位描述变化」，做候选人池与客户池的双向监听。
② 本地生活服务监听本地社群与点评平台的公开抱怨，生成「今日可触达客户」列表（务必克制频次，避免变成骚扰）。
③ 工业品 / 大宗贸易监听招标信息、扩产公告、供应链问题讨论，这类信号覆盖周期长、客单价高，最适合「带出处的线索池」形态。
迁移公式：高意向表述规则库（行业知识）+ 公开源接入（合规前提）+ 成本可控的定时运行。
21｜培训课程设计
| 课程名称 | 《用公开信息建立你自己的客户意向池》 |
| 适合人群 | 外贸业务员、SaaS 销售、服务商创始人、自由职业者、市场调研岗 |
| 建议时长 | 半天（3 小时） |
| 30 分钟 Demo | 现场用免费源（RSS）跑一次监听，展示「一堆帖子」如何变成「一份带分数的名单」 |
| 60 分钟 Workshop | 学员为自己行业写 10 条关键词与 5 条负面短语，跑出第一份名单并互相点评误报 |
| 半天课程 | 完整链路（源选择 → 规则 → 去重 → 审核状态 → 导出）+ 合规专题 + 深判环节接入国产模型 |
| 课程目标 | 让学员理解「线索质量取决于你定义的信号，而不取决于工具」 |
| 学员最终能够 | 独立搭建一条属于自己行业的线索监听线，并说清每条规则的来由 |
| 现场 Demo | 对比「规则评分」与「直接问大模型」在同一批数据上的结果差异与成本差异 |
| 学员练习 | 找出 5 条误报，把它们写成负面短语，Rescore 后观察排序变化 |
| 课后作业 | 连续运行 3 天，提交「线索名单 + 你的规则修改记录 + 合规边界说明」 |
| 企业迁移 | 企业内训时替换为「本公司产品的意向信号定义 + 触达合规规范」 |
22｜培训师点评
这个案例最值得教的，是「在哪里不用 AI」。所有人都在想怎么把大模型塞进流程，而它反其道而行——把可判定的部分交还给规则，把模型留到真正需要理解的一步。这个判断让成本降了一个量级，也让结果可解释、可复现。学会这条，比学会任何一个工具都值钱。
23｜最终判断
说明：「中国市场相关性」评为「中」而非「高」，因为内置数据源全是海外平台，国内用户需要自己开发源适配（工作量真实存在）。但它的架构判断（规则打分 + 按需调用模型 + 成本控制 + 本地运行）是通用的，且复现难度低、成本极低，因此作为方法论样本的价值很高。变现潜力评为「中」，因为「线索即服务」的交付依赖行业知识而非工具本身。
02
麦当劳 MCP 上的券组合优化 Skill：用真实计价替代模型估价，还教 AI 学会「劝你别买」
AI + 消费决策
MCP
零第三方依赖
约束优化
首次开源 2026-10-10
278★ / 19 Fork
一句话结论：它是「企业开放 MCP 之后，个人开发者能做什么」这个问题目前最好的答案——不堆功能，只做一件事：把「这单到底该不该点」算清楚，并且宁可少报也绝不编造。
01｜案例是什么？
麦麦省钱助手是一个基于麦当劳中国官方 MCP 的点餐成本优化 Skill，做两件事。短期——这一单怎么点最省：拉取当前门店的实时菜单与价格、拉取你账户里当前门店可用的优惠券，枚举「单品 / 套餐 / 券组合 / 加购凑单」的候选方案，然后用 MCP 的 calculate-price 逐方案真实计价（而不是猜），输出最省方案，并解释「为什么不推荐那个更便宜但你吃不饱的选项」。长期——你白扔了多少钱：手上几张券即将过期（沉默成本）、近几个月花了多少、客单价是否偏高、哪些单品该改成套餐。作者的立场写得很直白：「别处都在帮用户花钱，我们在帮用户止损。」
02｜为什么今天值得关注？
- 为什么是现在：2026-10-10 首次开源（北京 20:59），并于当天 13:00 提交参赛、13:59 获得官方回复「作品已成功参赛」。截至数据快照已 278★ / 19 Fork——在麦当劳 MCP 大赛涌现的 100+ 件作品中位居榜首（第一名）。它落在 10-11 期窗口内（10-10 期窗口截至 12:00，本案例创建于 20:59）。
- 为什么以前不容易做：「帮你点得便宜」这类工具长期做不准，原因是价格和券的可用性都是动态的——不同门店不同价、券有适用范围与叠加规则、凑单要不要加购取决于你本来的消费意图。用模型去估这些数字，一定会编。
- 为什么现在变得容易：麦当劳中国把点餐业务做成了 MCP（
mcp.mcd.cn），开放了 query-meals、order-list、calculate-price、query-my-coupons、available-coupons 等工具。于是「价格」和「券状态」第一次变成了可调用的真实数据，而不是需要模型猜测的知识——这让整类「消费决策优化」应用变得可做。
03｜案例的前世今生
前世。「怎么点最省」是个长期存在的小需求。早期解法是人工整理的「省钱攻略」帖——但攻略是静态的：券会过期、价格会调、不同门店不一样，所以攻略写完就过时。后来出现过计算器式的工具，但需要用户手工录入价格和券，录入成本高且容易错。
发展。MCP 出现后，企业把业务能力开放成工具，出现了新可能：工具可以直接查真实菜单、真实价格、真实券包。但随之而来的是一个新问题——很多团队会用模型来「估算」价格和券价值，因为那样实现最简单。这恰恰是这类应用最不能犯的错：算错钱的助手比没有助手更糟。
今生。2026-10-10，作者开源了这个 Skill，它的核心选择非常明确：「杜绝模型幻觉价格」是设计前提。作者把「券到底值多少钱」拆成两条可验证的路：首选是把券的商品码 + couponId 传给 calculate-price，返回的 discount 就是精确价值；兜底是从菜单反查原价（满减券取减免额、买一送一取商品单价、免费券取商品单价、固定价券取「菜单原价 − 固定价」）。两条路都走不通时，一律取 0 并标注「价值未知」，绝不估算。
更值得注意的是它引入了一个别处少见的概念——券的净价值：净价值 = 券面价值 − 为用这张券、你本来不会花的那部分钱。由此把券分成四类：顺手可用 / 努一把 / 纸面富贵（明确劝退）/ 无法判断。一个「帮你省钱的工具」主动劝退，这是它区别于同类的地方。
下一步可能怎么发展（以下为分析 / 推演，非事实）：① 同样的「净价值 + 排程」框架可迁移到外卖、电商、机票、酒店、会员权益——凡是「券 / 权益 + 约束条件」的场景都适用；② 成为跨平台的消费决策层（一个地方管所有平台的券）；③ 企业侧反向应用：品牌可以用同一套净价值逻辑评估自己的券策略是否在制造「纸面富贵」。
04｜原始资料
05｜作者是谁？
GitHub 账号 Ayzzz123，身份为麦当劳程序员创意开发大赛的独立参赛者（README 与 docs 均明确声明「非麦当劳官方产品」）。本报告未获得更多个人信息，不做推测。
从代码可以推断其工程习惯：项目为零第三方依赖（纯标准库，连开发期 linter 都不引入），并自研了一个规范检查脚本（scripts/style_check.py，基于标准库 ast + pathlib，七项检查，CI 直接跑，不达标即失败）；CI 覆盖 Python 3.8 / 3.10 / 3.12 / 3.13。愿意为了「零依赖」自造 lint 工具，说明作者的约束意识很强。
06｜解决了什么真实问题？
从消费者视角，问题是这样的：「我手里有一堆券，但我不知道哪张该现在用、哪张其实不值得为它多花钱；我甚至不知道我每个月因为券过期白扔了多少钱。」
- 信息不对称：券的价值不是面值。「满 40 减 10」看起来值 10 元，但如果你本来只想花 25 元，为了用这张券你得多花 15 元——这张券的净价值可能是负的。这是绝大多数「省钱工具」都算不清的地方。
- 动态数据：不同门店菜单与价格不同，券的适用范围不同，所以任何静态攻略都会失效。
- 沉默成本：券会过期，过期就是损失，但没人提醒你「哪张券你其实用不上了」。
- 决策疲劳：套餐 / 单品 / 加购 / 券组合的排列组合很多，人算不过来。
07｜完整技术栈
| 语言 | Python（CI 覆盖 3.8 / 3.10 / 3.12 / 3.13） |
| 依赖 | 零第三方依赖（仅标准库） |
| MCP | 麦当劳中国官方 MCP：https://mcp.mcd.cn，类型 streamablehttp，Bearer Token 鉴权 |
| 用到的官方工具 | query-meals（菜单）· order-list（历史订单）· calculate-price（真实计价）· query-my-coupons（我的券）· available-coupons（可领券）· query-store-coupons（门店券）· auto-bind-coupons（领券，写操作） |
| 模型 | 原文未提及使用任何大模型。设计上刻意避免模型估价（「杜绝模型幻觉价格」）——这是本案例最关键的架构选择 |
| 宿主 | README 给出了在 WorkBuddy 中通过「自定义连接器 → 配置 MCP」启用的完整步骤 |
| 测试 | 六套测试（python src/test_*.py）+ 自研规范检查（python scripts/style_check.py） |
| 协议 | MIT |
08｜完整 Workflow
链路 A · 这一单怎么点最省（saver.py）
① 拉真实菜单与价格：query-meals，限定「当前门店」
↓
② 拉当前门店可用券：query-my-coupons
↓
③ 枚举候选方案：单品 / 套餐 / 券组合 / 加购凑单
↓
④ 逐方案真实计价：calculate-price——关键：不是自家算的，是官方接口返回的
↓
⑤ 输出最省方案 + 为什么不推荐更便宜但吃不饱的选项
链路 B · 你白扔了多少钱（auditor.py）
① 读历史订单：order-list → 算总支出、客单价、结构性浪费
↓
② 券包体检：净价值 = 券面价值 − 为用这张券你本来不会花的钱 → 四类判定：顺手可用 / 努一把 / 纸面富贵（明确劝退）/ 无法判断
↓
③ 用券排程：先推算「券全部过期前你还会点几单」，再在此约束下分配券——「可实现的券，未必用得上」
↓
④ 可领取券评估：available-coupons 返回「已领取」与「可领取」，复用同一套净价值框架，只换问题（该不该领）
衔接层 mcd_adapter.py 是唯一一次做「分 → 元」换算、字段映射、退款过滤与券面价值反查的地方——把容易出错的换算收敛到一个文件里，这是很清晰的边界设计。
09｜它到底是怎么实现的？
这个项目最有价值的不是算法，而是三条自我约束：
- 约束一：不用模型估价，用官方接口计价。券的价值首选走
calculate-price（返回 discount 即精确值）；兜底才从菜单反查原价（满减券取减免额、买一送一取商品单价、免费券取商品单价、固定价券取「原价 − 固定价」）；两条路都走不通时一律取 0 并标注「价值未知」。作者的原话是「宁可少报，不可编造」。
- 约束二：不知道就不说。两个刻意的克制写在了 README 里：① 不输出券的剩余天数——因为有效期未知，套用
expiry_text() 会把 None 说成「无期限」，那是编造；② 不擅自替用户领券——auto-bind-coupons 是写操作，必须取得用户明确同意。
- 约束三：券状态不认识就排除。
available-coupons 的状态只有「已领取 / 可领取」两种；没见过的状态一律判「无法识别」并排除——宁可漏报，不可误报。
另一个值得记录的工程细节：作者在 MCP_INTEGRATION.md 里写出了官方文档没写、但跑通链路必需的 12 条实测调用契约，包括「门店查询的必传参数」「calculate-price 的字段名」「分 vs 元：两个接口方向相反的坑」。这份文档本身就是本案例最有价值的可复用资产——它记录的是「文档与实现之间的缝隙」，是下一个开发者最需要的东西。作者还做了自纠：文档里曾把契约条数写成 17（实际 19）、把「三种券型」写旧（实为四种：满减 / 买一送一 / 免费 / 固定价），都在后续提交中修正，并在 README 中公开了这些不一致。
10｜手把手复现
以下整理自项目 README 的官方说明（非本报告推导）。
Step 1 · 零配置试玩（不需要 Token、不联网，读 fixtures 里录制的真实响应）：
git clone https://github.com/Ayzzz123/mcd-coupon-strategist.git
cd mcd-coupon-strategist
python demo.py
作者称 demo.py 的输出与其 README 中列出的 12 个关键数据点逐字一致——这是本案例可验证性最强的一步，建议先跑这个。
Step 2 · 申请 MCP Token：前往 open.mcd.cn/mcp，手机号登录后在控制台激活并复制 Token。
Step 3 · 配置 MCP 连接（用 mcp-config.example.json，把 ${MCD_MCP_TOKEN} 换成真实 Token，勿提交到公开仓库）：
{
"mcpServers": {
"mcd-mcp": {
"type": "streamablehttp",
"url": "https://mcp.mcd.cn",
"headers": { "Authorization": "Bearer ${MCD_MCP_TOKEN}" }
}
}
}
Step 4 · 在宿主中启用：README 给出的路径是「左侧边栏【专家 · 技能 · 连接器】→【连接器】→ 右上角【自定义连接器】→【配置 MCP】→ 粘贴 JSON →【保存】→ 将 mcd-mcp 设为【启用】」。
Step 5 · 对话使用。示例提问：「我手里有券，想吃汉堡+薯条+饮料，预算 40 元，怎么点最省？」
Step 6 · 跑测试：python src/test_*.py（六套）+ python scripts/style_check.py。本报告未实际执行上述任一步骤。
11｜Prompt / Code / Config
作者公开的可复用内容有三类，均来自仓库原文：
① 净价值公式（本案例的核心方法论）：
净价值 = 券面价值 − 为用这张券、你本来不会花的那部分钱
分类：顺手可用 / 努一把 / 纸面富贵（明确劝退）/ 无法判断
② 券面价值的两条取值路径（作者公开）：
首选：券的商品码 + couponId → calculate-price → 返回 discount 即精确价值
兜底：从菜单反查原价
· 满减券 → 直接取减免额
· 买一送一 → 取商品单价
· 免费券 → 取商品单价
· 固定价券 → 菜单原价 − 固定价
两条都走不通 → 取 0 并标注「价值未知」（绝不估算）
③ MCP 连接配置模板：见上一步的 JSON。
此外 README 还公开了「可领取券」的四条契约（available-coupons 返回 Markdown 而非 JSON、不接受参数、不返回 couponId / 面值 / 有效期、状态仅有两种），这些属于实现细节，建议直接查阅原文。
12｜踩坑
坑 1 · 官方文档没写的关键契约。作者指出有 12 条「文档没写但跑通链路必需」的实测契约，其中包括「分 vs 元」两个接口方向相反的坑。这是接入任何 MCP 都会遇到的典型问题——文档描述与实现之间存在缝隙，只能靠实测补齐。建议：接入前先对着 MCP_INTEGRATION.md 核对，别自己重新踩一遍。
坑 2 · 免费券可能被高估。作者明确写出：若某张券实际要求「随单购买」，券面并无体现，此时会高估净价值。这条限制被写进了 docstring 与契约文档——属于作者已知但未解决的口径问题。
坑 3 · 可领取券信息不完整。available-coupons 不返回 couponId、面值与有效期，因此无法用带券计价实测、也无法参与用券排程。作者的处理是把它降级为「该不该领」的框架复用，而不是硬塞进排程。
坑 4 · 排程建立在假设之上。用券排程有三条假设：窗口内本来就会点 K 单、每单最多用 1 张券、用券不改变点单次数。作者明确说明「自然消费基准」取自历史订单客单价，是保守近似而非精确值，且假设写在报告里。（本报告补充：依赖历史客单价意味着新用户的排程结果可信度更低，这一点原文未特别提示。）
坑 5 · 数据口径不一致（作者已自查）。README 与 MCP_INTEGRATION.md 中「实测调用契约」的条数曾出现 12 / 17 / 19 三处不一致，另有「三种券型」的表述过期（实为四种）。作者已在后续提交中修正并公开说明。本报告在引用时采用其修正后的口径，并标注此处曾存在不一致。
13｜中国用户能不能直接做？
- 国内访问：完全国内服务（麦当劳中国 MCP
mcp.mcd.cn、Token 申请页 open.mcd.cn），无跨境障碍。直接可用
- 注册：手机号登录即可申请 MCP Token，门槛极低。
- API：需要 MCP Token（免费申请）；不需要任何大模型 API Key。
- 成本：0 元——项目零第三方依赖，不调用付费模型，
demo.py 离线可跑。
- 技术门槛：普通用户级——配好 MCP 后就是对话提问；想改代码则需 Python 基础（但零依赖意味着环境不会成为障碍）。
14｜国产替代方案
本案例本身就是国产方案，不存在「替换海外依赖」的问题。真正值得讨论的是反向迁移——把它的方法论搬到其他国内生态：
| 原方案 | 可迁移方向 |
麦当劳 MCP
（点餐 + 券） | 外卖平台 MCP / 开放平台、电商平台开放接口、航空公司与酒店会员权益接口、运营商与视频会员权益——凡是「有券 / 有权益 + 有约束条件」的生态都适用。各平台开放程度不同，需逐一确认是否提供等价的可调用接口 |
| 净价值公式 | 通用可移植——公式本身与平台无关，是纯粹的决策框架。 |
| 「宁可少报不可编造」原则 | 通用可移植——适用于任何涉及金额、库存、库存价、时效的 AI 应用。 |
| 宿主 Skill 形态 | 项目 README 已给出 WorkBuddy 的接入步骤；国产 Agent 宿主（CodeBuddy / Qoder 等）若支持 MCP 配置，理论上同样可接入，本报告未验证。 |
15｜中国企业可以怎么用？
- 企业场景 1 · 品牌与零售（反向应用）：用同一套「净价值」框架评估自己的发券策略——哪些券设计出来就是「纸面富贵」，用户根本用不上，反而伤害体验。这比传统的核销率分析更接近用户真实决策。
- 企业场景 2 · 本地生活服务商：把「券组合优化 + 沉默成本提醒」做成商家的会员权益顾问工具，帮商家的会员管好权益，提高复购。
- 企业场景 3 · 企业采购与报销：把「预算 / 约束 / 组合优化」框架迁移到企业差旅、办公采购等场景——本质都是「在多重约束下找最优组合，且必须用真实价格」。
- 企业场景 4 · 内部工具开发：把它当作「如何正确写一个 MCP Skill」的参考实现——记录实测契约、区分读写操作、对未知状态拒绝判断、把换算收敛到单一文件。这几条可以直接作为团队的 Skill 开发规范。
16｜中国消费者可以怎么用？
- 个人日常省钱：出门点餐前问一句「我手里有券，想吃汉堡+薯条+饮料，预算 40，怎么点最省」，拿到一个用官方接口算过的答案，而不是一个凭感觉的推荐。
- 月度消费体检：看「你白扔了多少钱」报告——券的沉默成本、客单价是否偏高、哪些单品该改套餐。这类「消费结构复盘」过去只有记账 App 能做一部分，而这里做到了券的粒度。
- 家庭与同事拼单：多人点餐时的组合优化（谁的券用在哪个单上），比人工凑单更接近最优。
17｜如何变成一个赚钱的项目？
- 产品化：项目为 MIT 开源，且强绑定麦当劳 MCP，直接转卖不可行。可行的产品化方向是「跨平台权益管家」——把净价值与排程框架做成一个统一的券与会员权益管理工具（这需要逐平台对接开放接口，工作量大但护城河清晰）。
- 服务化：为品牌方提供「券策略诊断」——用净价值框架分析一套券方案里有多少属于「纸面富贵」。客户是市场部与会员运营部门，付费意愿来自真实损耗。
- 咨询化：把「把用户的真实决策模型写进产品」作为咨询主题——帮助企业理解为什么自己的优惠券核销率低。
- 培训化：面向技术团队的工作坊：「如何写一个不会编造数字的 AI 应用」。用本案例的六条自我约束作为教材，比讲抽象原则有效得多。
- 内容化：「我用手里的券算了算，发现我每个月白扔 30 块」这类内容天然有传播力，且数据来自真实运行。
- 行业化：把「净价值 + 排程」框架做成某个垂直行业的权益顾问（如连锁餐饮的会员运营、航空公司的里程管理）。
18｜变现路径
| 路径 | 客户 | 产品 / 服务 | 收费方式 | 难度 |
|---|
| 券策略诊断 | 品牌市场部 / 会员运营 | 券方案净价值体检报告 | 项目制 | 中 |
| 权益管家工具 | 消费者 | 跨平台券与权益管理 | 订阅 / 会员 | 高 |
| Skill 开发规范咨询 | 企业技术团队 | MCP Skill 开发规范 | 项目制 | 低 |
| 培训 | 开发者 / 产品团队 | 「不让 AI 编造数字」实战课 | 按场 / 按人 | 低 |
| 内容 IP | 泛消费者 | 省钱方法论 / 消费复盘 | 课程 / 社群 | 低 |
重要说明：以上为基于案例结构推导的潜在商业模式，不是已验证的商业结果。作者未公开任何收入数据。另需注意：本案例是参赛作品，大赛官方条款禁止未授权商业变现（详见 10-09 期对大赛规则的分析）；若要基于它做商业项目，应重新实现而非直接使用参赛作品。
19｜如果我是一个中国独立开发者
假设 1 人、预算有限、有基础编程能力、优先使用国产模型，7 天 MVP 路线（以下为本报告建议，非作者原始步骤）：
- Day 1：先跑
python demo.py（零配置、离线）。目标是看清 fixtures/ 里录制的真实响应长什么样——这是理解「真实数据长什么样」最快的方式。
- Day 2：读完
MCP_INTEGRATION.md 的 12 条实测契约，尤其是「分 vs 元」那一条。把这份文档当作你接任何 MCP 的检查清单模板。
- Day 3：申请 Token 并跑通真实链路；对同一个订单，分别用「真实计价」和「让模型估算」各出一版结果，把差异记录下来——这就是你未来做同类项目时说服客户的证据。
- Day 4：把净价值公式提取成一个与平台无关的模块（输入：券面值、条件、你的原始消费意图；输出：净价值 + 分类）。这一步产出的东西是可复用的。
- Day 5：接第二个平台的券数据（外卖 / 电商 / 航司任选其一），验证「框架是否真的跨平台成立」。
- Day 6：把两个平台跑出来的结果做成一份「我的权益真实现状」报告，给自己用一周。
- Day 7：用这份报告做内容（「我发现我 60% 的券是纸面富贵」），测试是否有人愿意为「帮我看清自己的券」付钱。先验证需求，再决定做不做产品。
关键判断：这条路线里最值钱的是 Day 2 和 Day 4——「实测契约」与「可移植的决策框架」。单纯复刻一个麦当劳助手没有商业空间（平台随时可能自己做一个），但从中学到的「如何用真实数据替代模型猜测」，是能用在任何消费决策类产品上的能力。
20｜如何迁移到其他行业
① 电商与外卖跨店满减、店铺券、平台券的叠加优化，本质与券组合完全同构。
② 差旅与出行机票 + 酒店 + 会员权益的组合决策，约束条件更多（时间、退改、里程），净价值框架依然适用。
③ 企业采购供应商报价 + 账期 + 批量折扣的组合优化，且「必须用真实报价」的要求比消费场景更强。
迁移公式：真实价格接口（拒绝模型估价）+ 净价值（区分面值与实效）+ 约束下的组合优化 + 对未知状态拒绝判断。
21｜培训课程设计
| 课程名称 | 《写一个不会编造数字的 AI 应用：以券组合优化为例》 |
| 适合人群 | AI 应用开发者、产品经理、技术负责人、想接入 MCP 的团队 |
| 建议时长 | 半天（3 小时） |
| 30 分钟 Demo | 现场对比「让模型估算价格」与「调官方接口计价」在同一订单上的结果差异 |
| 60 分钟 Workshop | 学员跑通 demo.py 并改造净价值公式的参数，观察分类结果如何变化 |
| 半天课程 | 完整链路（MCP 接入 → 实测契约补齐 → 组合优化 → 未知状态处理）+ 六条自我约束逐条讲解 |
| 课程目标 | 建立「涉及金额与状态的应用，必须用真实数据、必须能说不知道」的工程直觉 |
| 学员最终能够 | 为自己的业务写出一条「真实数据优先」的 AI 决策链路，并列出需要拒绝判断的边界 |
| 现场 Demo | 展示「券的沉默成本」——让学员看到自己手里的券有多少属于纸面富贵 |
| 学员练习 | 列出自己业务中 5 个「模型会猜错」的地方，并写出对应的真实数据来源 |
| 课后作业 | 接入一个真实接口，输出一份「哪些结论有据、哪些标为未知」的决策报告 |
| 企业迁移 | 企业内训时替换为「本公司业务中不得由模型猜测的数据清单」 |
22｜培训师点评
它教的是「克制」。一个省钱助手主动劝你「这张券别用」，一个价格工具遇到算不准就直接标「价值未知」——这两件事在技术上都是加个判断就行，难的是愿意放弃「看起来更聪明」的答案。学员真正该带走的是：在要付钱的场景里，可信度就是产品力。
23｜最终判断
说明：中国市场相关性评为「高」——技术栈、数据源、宿主全部在国内，且手机号即可申请 Token，是本期两个案例中落地阻力最小的一个。商业价值与变现潜力评为「中」，原因有二：① 强绑定单一平台，平台方随时可能自己实现；② 作为参赛作品受大赛条款约束。但它的方法论价值远高于其商业化价值——「用真实接口替代模型猜测」这条原则，可以复用到任何涉及金额的 AI 应用上，这是本期最值得带走的一句话。