01
把麦当劳中国官方 MCP 装进 Agent：品牌方把「点餐—到店—团餐—活动—积分」开放成 35 个 MCP 工具，开发者当天就能做出可用的 Agent Skill
MCP · 企业开放能力
中国企业
Agent Skill
消费品牌
窗口内：报名开启 + 报名波次
商业授权受限
【一句话结论】这是中国企业第一次把一整条消费业务链路（点餐/到店/团餐/活动/积分）以官方 MCP 的形式开放给外部开发者，并且用一场 GitHub Star 排行赛把「做 Skill」变成了可衡量的动作——中国开发者今天申请一个 Token 就能开始做，做完还能投稿参赛。
01｜案例是什么？
麦当劳中国做了一个叫「麦当劳 MCP」的官方服务：一个远程托管的 MCP Server，地址是 https://mcp.mcd.cn，走 Streamable HTTP，用 Authorization: Bearer <Token> 认证。开发者到官方开放平台 open.mcd.cn/mcp 用手机号登录、点「激活」就能拿到 Token。
拿到 Token 之后，任何支持 MCP 的客户端（WorkBuddy、Cherry Studio、Cursor、TRAE、VS Code……）都能让 AI 去查当天有哪些活动、查门店能卖什么、算价格、下单、取消订单、查积分、领券、抽奖、预约生日派对。官方文档列出的工具覆盖麦乐送点餐、到店取餐、团餐、积分兑换券、活动日历等场景。
2026 年 10 月 9 日 10:30，麦当劳中国同时开启了「麦当劳程序员创意开发大赛」：开发者用这套 MCP 做 Skill（套餐推荐、省钱助手、活动推荐等），开源到 GitHub，按 公开 Star 数排名，前 100 名进榜获奖。WorkBuddy（腾讯）是本次活动的官方合作伙伴。
02｜为什么今天值得关注？
- 因为报名窗口正好在昨天开：大赛报名及排名期为 2026-10-09 10:30 → 2026-10-25 23:59，本期采集窗口的起点就是活动开始的那一刻。这不是「旧事重提」，而是赛事刚刚起跑。
- 因为作品已经成批落地了：窗口内（10-10 上午）报名 Issue 密集刷屏，我们在采集时看到的连续编号为 #343～#350，标题从「控卡点餐助手」「麦力 McDaily」「麦麦省钱决策引擎」到「麦麦拼餐师」；仓库开放 Issue 数已达 310。
- 因为排行榜已经跑起来了：官方
RANKING.md 更新时间戳为 2026-10-10 20:00:22，榜首 mcd-event-radar 已到 68 ★，第 100 名附近约 4～5 ★——这意味着参赛成本极低、竞争者还很少。
- 因为这件事以前做不了：一年前，一个独立开发者想做一个「帮我点麦当劳」的应用，需要抓包、逆向、伪造请求，随时会被风控；现在品牌方自己把接口标准化成 MCP，合规路径被官方打通了。
03｜案例的前世今生
前世（为什么要做这个？）消费品牌的数字化服务长期停留在「App / 小程序 / 公众号」三种形态：用户必须到品牌的场子里用品牌给的界面。AI 时代出现了一个新问题——用户开始用 AI 助手直接说「帮我订个麦当劳」，而 Agent 没有眼睛也没有手指，它只能调接口。品牌如果不开接口，就会被第三方用爬虫和逆向「代劳」，既不可控也不安全。MCP 在 2025 年被 Anthropic 提出并被各大厂商迅速接受后，给了品牌方一个标准答案：与其被逆向，不如主动开放。
发展（时间线，均来自官方文档）
- 2025-12-09：MCP Server v1.0.0，只有「麦麦日历」和「麦麦省领券」两个能力。
- 2025-12-25：活动规则中注明，这一天是「麦当劳 MCP 正式上线」的日期（注意：与版本日志首版日期 12-09 并不一致，两个日期都是官方口径，我们如实并列）。
- 2026-01-23 → 2026-09-10：v1.0.1 → v1.0.9，依次加进营养信息、麦乐送点餐与积分兑券、到店取餐与团餐、积分兑实物与得来速、套餐定制、历史订单、随单买卡、派对/品鉴会预约、积分抽奖、取消订单与餐具选择……九个版本，把业务一条条搬上 MCP。
- 2026-09-23：官方开大赛仓库
M-China/mcd-developer-innovation-challenge，公布参赛规范（必须含 README.md / CONTEST_DECLARATION.md / MCP_INTEGRATION.md / mcp-config.example.json / workbuddy.md）。
- 2026-10-09 10:30：报名开启，排行榜机制（公开 Star 排行、前 100 进榜、10-26 00:00 定榜）正式生效。
今生（为什么是现在？）三个条件在同一周凑齐了：① MCP 已成为国内客户端的事实标准（WorkBuddy、Cherry Studio、TRAE、Cursor、VS Code 全部内置支持）；② 品牌方把接口做完了（35 个工具，覆盖下单闭环）；③ 出现了一个公开、可衡量、还给奖励的竞技场（Star 榜 + 巨无霸兑换券 + WorkBuddy 积分）。于是「做一个能用的消费级 Agent」的门槛，从「要拿到商务合作」降到了「贴一次 Token」。
下一步可能怎么发展（分析 / 推演，非事实）
- 10-25 定榜后，前 100 名项目会成为一批可被直接复用的公开 Skill 样板，可能催生「Agent Skill 外包 / 代做」的第一批自由职业者。
- 如果这次赛事数据好看，其他连锁消费品牌（咖啡、茶饮、便利店、连锁餐饮）大概率会复制同一套打法：开放 MCP → 办星数赛 → 借开发者做功。这可能是 2026 年 Q4 到 2027 年最值得盯的一个模式。
- 风险同样存在：官方服务条款明确「未经书面授权，不得将本仓库内容用于商业售卖、付费分发、引流变现或暗示官方背书」。这个案例的商机在「能力供给」，不在「转售接口」——推演成立的前提是拿到品牌方的商业授权，或把价值做在品牌方业务之外。
04｜原始资料
05｜作者是谁？
这个案例有两个主体，必须分开说：
- 能力提供方：麦当劳中国。活动规则中明确组织者为「金拱门（中国）有限公司」。官方 GitHub 组织账号为
M-China，名下只有两个仓库：MCP Server 指南（190 ★）与本次大赛主仓库（88 ★）。这是可核验的企业官方账号，不是社区模拟。
- 开发者一侧：目前由独立开发者主导。以当前榜首
Zafer-Liu 为例：昵称 Zafer_Liu，主页 zaferliu.me，45 个公开仓库、54 个 followers、bio 为 "Looking for reality."。属于「个人开发者 / 独立开发者」，从仓储结构与文档完备度看更像是习惯开源交付的人，但其职业身份无法从公开信息确认，不做推测。
本次采集未对 310 个报名 Issue 的参与者做整体画像统计，理由：报名仍在进行中，样本会持续变化，此时下结论会失真。
06｜解决了什么真实问题？
从用户需求而不是从 AI 技术讲起，这条链路原本卡在三处：
- 用户侧：点餐前的决策成本。「今天吃什么、有什么活动、我有什么券、券后多少钱、哪家店还有名额」——要把这些拼起来，用户得在 App、公众号、活动页之间来回跳。麦当劳自己的活动尤其如此：生日派对、读书会、品鉴会这类「场次 + 名额」型活动，信息分散且时效性强，用户很难自己扫完。
- 开发者侧：合规的接入路径缺失。想做一个「帮我点麦当劳」的小工具，私人开发者唯一的路径是逆向，随时可能失效、且明确违规。
- 品牌侧：AI 流量入口的失位。当越来越多用户的第一入口变成 AI 助手，品牌如果没有可以被 Agent 调用的标准接口，就会在这场迁移里彻底隐身。
官方 MCP 一次性回应了三方：用户得到「一句话问出结果」，开发者得到合规接口，品牌得到进入 Agent 生态的入口。
07｜完整技术栈
| 协议 | MCP（Model Context Protocol），传输层为 Streamable HTTP；官方说明接入客户端必须支持 Streamable HTTP |
| 服务地址 | https://mcp.mcd.cn（远程托管，官方运维，开发者不自建） |
| 鉴权 | 请求头 Authorization: Bearer YOUR_MCP_TOKEN；Token 由官方平台手机号登录后一键申请 |
| 限流 | 官方文档明确：每个 Token 每分钟最多 600 次请求，超限返回 429 |
| 工具数 | 官方文档列出约 30+ 个工具（点餐/订单/券/积分/商城/活动/抽奖）；参赛者实测 tools/list 返回 35 个（2026-10-09 实测） |
| 客户端 | WorkBuddy、Cherry Studio、Cursor、Kiro、TRAE、VS Code（官方文档逐平台给了接入教程） |
| 模型 | 官方未指定。由客户端自带模型决定，因此该案例天然不锁定任何一家模型厂商 |
| Skill 侧技术 | 以榜首作品为例：Node.js（package.json）+ setup-connector.mjs / check-connector.mjs / locate.mjs / live.mjs / radar.mjs；输出自包含 HTML（不依赖在线地图服务） |
| 数据存储 | 不涉及服务端数据库；配置落在本机 ~/.workbuddy/mcp.json，执行记录以脱敏 JSON 落盘 |
| 部署 | 免部署。MCP 在云端，Skill 装进客户端即可 |
| 未披露 | 官方未公开后端架构、QPS 上限以外的容量数据、内部模型选型。本报告不编造。 |
08｜完整 Workflow
用户输入：「这个周末附近哪家麦麦有生日派对还有名额？」（自然语言）
↓
Agent（Skill）：识别意图 → 判定需要「城市 + 日期 + 活动类型」→ 缺城市则先做 IP 级城市定位并请用户确认
↓
Tool 调用链（MCP）：campaign-calendar 找活动线索 → mall-points-products → mall-product-detail 拿 spuId → query-party-city → query-party-store（返回门店名/地址/经纬度/营业状态）
↓
Tool 调用链（续）：query-party-store-date 查可预约日期 → query-party-store-session 查场次；只有 leftNum > 0 才标「有名额」
↓
规则层（确定性，不交给模型）：日期/城市/关键词筛选、去重、价格单位核对、把「只有活动日历」的结果降级为「待核实」
↓
输出：单文件自包含 HTML 卡通活动地图（门店按官方经纬度线性投影、辖区与道路为卡通示意并明确标注「示意图」）+ 活动卡片，可筛选、可导出 .ics 日历
↓
Human-in-the-loop：party-order-create（下单）默认不调用，必须用户明确确认；不自动支付
注：以上调用链整理自榜首作品的 MCP_INTEGRATION.md（作者公开文档），不是我们的推导。工具清单与顺序均按其文档所述。
09｜它到底是怎么实现的？
把「为什么它能工作」拆成四层来看：
- 第一层｜能力层（官方负责）：把业务原子化成幂等的工具。
query-meals 查菜单、calculate-price 算价、create-order 下单、cancel-order 取消、query-my-coupons 查券——每个工具只做一件事，参数与返回结构由官方定义。这正好对应企业 Agent 设计的核心原则：模型负责不确定的语言，系统负责确定的事实。
- 第二层｜编排层（Skill 负责）：把「用户的一句话」翻译成一串有依赖顺序的工具调用。
spuId 必须来自上一步真实返回，不能从标题猜；门店经纬度只用于地图投影，不做逆地理编码。这一层的价值不在于模型多聪明，而在于依赖关系被显式建模。
- 第三层｜不变量层（阈值与闸门）：「可预约」= 官方接口返回的
leftNum > 0；价格单位未核实就不换算；只有活动日历线索时展示「待核实」。这类「不变量」是 Agent 不产生幻觉的真正原因——把结论收敛到可核验的字段上。
- 第四层｜交付层：输出不是一段文字，而是一个可交互的单文件页面。这是《AI 极客实战》系列一直强调的趋势：Agent 的交付物正在从「回答」变成「可直接使用的产物」。
顺带看一个很重要的负面信号：作者公开指出，官方文档页把两个工具写作 query-partystore-date / query-partystore-session，而线上 tools/list 实测为 query-party-store-date / query-party-store-session。文档与线上不一致，在 MCP 生态里是常态——所以成熟的做法是运行时读取工具 schema，而不是把字段名硬编码进提示词。
10｜手把手复现
以下 Step 1–2 来自官方文档原文，Step 3–6 来自榜首作品的公开文档，Step 7 为本报告整理。
Step 1（官方原文）· 申请 Token
浏览器打开 open.mcd.cn/mcp → 右上角【登录】→ 手机号验证码登录 → 点【控制台】→ 点【激活】→ 同意服务协议 → 一键复制 Token。
Step 2（官方原文）· 把 MCP 配进客户端
官方给了通用 JSON，粘进客户端的 MCP 配置即可：
{
"mcpServers": {
"mcd-mcp": {
"type": "streamablehttp",
"url": "https://mcp.mcd.cn",
"headers": { "Authorization": "Bearer YOUR_MCP_TOKEN" }
}
}
}
官方特别提示：一定记得把 YOUR_MCP_TOKEN 换成真实 Token；确保客户端支持 Streamable HTTP；Token 妥善保管，不要泄露。
Step 3–6（来自参赛作品公开文档）· 用 WorkBuddy 装载 Skill 并跑通
- Step 3：在 WorkBuddy 对话框里直接说「帮我安装这个技能：<仓库地址>，把
skill/<name> 复制到 ~/.workbuddy/skills/」；或下载仓库的 dist/*-skill.zip 走图形界面「技能 → 添加技能 → 上传技能」导入。
- Step 4：新开一轮会话（Skill 目录扫描在会话启动时进行，不重开会话不生效——这是最常见的第一次失败原因）。
- Step 5：对 Skill 说一句自然语言（如「查附近的活动」），它会先确认城市，再开跑。
- Step 6：首次使用贴一次 Token，Skill 内置的
setup-connector.mjs 会写前备份、保留其他服务器条目、不回显 Token、在线验证后提示「Trust → 启用 → 重开会话」。之后免配置。
Step 7（本报告整理，非作者原文）· 投稿参赛
按下述文件清单整理仓库 → 公开 → 按官方 Issue 模板发一条【参赛申请】→ 等官方自动化校验回帖 → 之后 Star 数被定时采集进 RANKING.md。
必须标注：Step 1–2 为官方文档原文；Step 3–6 转述自榜首作品的公开文档（README.md / MCP_INTEGRATION.md），本报告未实际执行该流程做端到端验证；Step 7 为本报告基于官方活动规则的整理。
11｜Prompt / Code / Config
官方公开（可直接使用）：MCP 配置 JSON（见上）、各客户端接入步骤截图与文字、完整工具清单与说明、版本日志。
参赛作品公开（以榜首为例）：mcp-config.example.json（只含环境变量占位符，不含凭证）、install.sh / install.ps1、SKILL.md、MCP_INTEGRATION.md（9 个工具逐一说明作用与边界）、workbuddy.md（WorkBuddy 对话上下文，用于专项奖励核验）。
设计意图（从公开文档提炼，非作者原文）：这份 MCP_INTEGRATION.md 是一份很好的「工具边界说明书」模板——每个工具都标注了「它返回什么」和「它不代表什么」。例如 campaign-calendar 只代表「有活动线索」，不代表某门店有名额；mall-points-products 只代表「该商品可预约」，不代表用户城市有位置。这种「能力边界表」是防止 Agent 过度推断的实用手段。
本文核对：上述提炼来自作者公开文档的事实陈述；本报告未获得作者的提示词原文，因此不引用任何未公开的 Prompt。
12｜踩坑
坑 1｜官方文档与线上工具名不一致。文档写作 query-partystore-date/query-partystore-session，线上实测为 query-party-store-date/query-party-store-session。解法：不硬编码工具名与字段名，运行时读取连接器实际 schema。（来源：参赛作品公开文档，作者原话）
坑 2｜装完 Skill 不生效。Skill 目录在会话启动时扫描，装完必须新开一轮会话。（来源：参赛作品公开文档）
坑 3｜Token 是唯一的身份凭证，泄露 = 别人用你的账号下单。官方要求妥善保管；项目做法是配置文件写前备份、不回显 Token、示例文件只放环境变量占位符。（来源：官方文档 + 参赛作品公开文档）
坑 4｜限流。600 次/分钟/Toke，超限 429。多轮工具链（一次查询可能串 7 个工具）很容易把频率打上去，尤其在批量扫城市/门店时。（来源：官方文档原文）
坑 5｜「有活动」不等于「有名额」。这是最容易让 Agent 说错话的地方。官方活动类目（生日派对 1>6>20、主题派对 1>6>21、体验营 1>6>22、品鉴会 1>6>25、读书会 1>6>34）只是线索，必须走到 query-party-store-session 才能确认名额。（来源：参赛作品公开文档）
说明：本节全部来自官方文档原文与参赛作品公开文档，未经我们独立实测复现；标为「坑」的是公开文档中已明示的失败点，不是我们的踩坑记录。我们未在任何社区评论或 Issue 中检索到额外的失败反馈（该作品 Issue 区仅 1 条讨论，且为作者自述的演示说明）。
13｜中国用户能不能直接做？
- 国内访问：可以。服务在中国大陆境内，官方明确「面向中国大陆地区（不含港澳台）使用」。
- 注册：很方便。手机号验证码登录，无需企业资质，个人即可申请 Token。
- API：容易获得。登录后点「激活」即得 Token，一键复制。
- 成本：MCP 服务本身官方未公布计费——截至采集时点，官方文档与活动规则中均未提及收费。我们不假设它永久免费，使用者应以官方条款为准。其余成本主要是客户端与模型费用。
- 技术门槛： 普通用户可上手 —— 只想用的话，配好 JSON、粘 Token 就能在对话里点餐、查券、查活动；AI 用户可做 Skill —— 要做成可复用的 Skill，需要理解 MCP 工具边界与文件结构；开发者做产品 —— 要做成独立产品需 Node.js / 前端能力。
- 参赛资格：必须是中国大陆合法居民、年龄 ≥18 周岁（未满 18 需监护人同意）；项目仓库必须公开可访问；项目创建时间需落在 2025-12-25 00:00 至 2026-10-25 23:59 之间。
14｜国产替代方案
| 原方案 | 麦当劳中国官方 MCP（mcp.mcd.cn）+ 任意支持 Streamable HTTP 的 MCP 客户端 |
| 中国用户方案 | 本身即国产：服务方麦当劳中国（金拱门），官方推荐客户端含 WorkBuddy（腾讯）、TRAE（字节）、Cherry Studio（国内开源）。不存在「需要替换」的问题。 |
| 模型侧 | 官方不锁定模型，客户端自带即可。这意味着 DeepSeek / Qwen / GLM / Kimi / 豆包 / MiniMax 都能直接配，因为约束在 MCP 协议层，不在模型层。属「协议中立、理论可用」，本报告未逐一实测。 |
| 同类中国案例 | 该模式的先例可在国内其他开放 MCP 的品牌/平台中寻找（如各类生活服务、票务、政务类开放平台）；本报告本期未完成同口径横向核查，故只给方向不给结论。 |
15｜中国企业可以怎么用？
企业场景 1｜连锁餐饮 / 零售：把「活动 + 库存 + 权益」做成 Agent 可调用能力。麦当劳已经示范了完整链路：活动日历 → 商品目录 → 门店与场次 → 名额核验 → 下单。任何有「门店 × 场次 × 名额」结构的业务（餐饮、健身、影院、医美、教培试听、连锁门店预约）都能照搬这个工具切分方式。
企业场景 2｜企业内部系统接入 MCP，替代「写死的工作流」。把 CRM 查客户、ERP 查库存、工单系统建单封装成 MCP 工具，让不同 Agent（客服、销售、运营）共用同一套能力，而不是每个场景重写一遍 API 调用。
企业场景 3｜用「公开 Star 排行」这种机制低成本征集外部创意。本次大赛的组织方式（开源 + 公开排行 + 小额奖励 + 官方自动化报名校验）是一套极低成本的外部创新征集模板——用 Issue 机器人做合规校验、用 Star 数做公开排序、用少量品牌权益做奖励。活动规则还把「内容合规」「原创性」「不得诋毁品牌」全部前置到参赛声明文件里，法务成本被大幅摊薄。
16｜中国消费者可以怎么用？
- 省钱场景：让 AI 先查「我有什么券」+「当前门店能卖什么」+「券后价」，再决定点不点——把「领券 → 算价 → 对比套餐」合并成一句话。
- 活动场景：查询附近门店的生日派对、读书会、品鉴会场次与名额，导出
.ics 进日历。这是传统 App 里最难找、最容易被忽略的信息。
- 家庭/团队场景：多人点餐、拼单分账、按热量或预算选套餐——这类「多约束求解」正好是模型擅长的，而人类自己在菜单上做很累。
17｜如何变成一个赚钱的项目？
先说清楚边界：官方条款明确禁止「商业售卖、付费分发、引流变现、暗示官方背书」。所以下面所有路径都必须建立在「拿到品牌授权」或「把价值做在品牌业务之外」这两个前提上，否则不建议做。
产品化：把「场景化点餐决策」做成一个轻量 Web / 小程序工具（多人拼单、热量预算、活动日历聚合）。核心资产不是接口，而是交互设计与规则沉淀。
服务化：更现实的路径是「MCP/Skill 交付服务」——把「把企业某个业务封装成 MCP 工具 + 写一份 Skill + 做工具边界说明书」做成标准化交付。本次大赛产出的 MCP_INTEGRATION.md 结构，本身就是一份很好的交付物范本。
咨询化：帮消费品企业做「品牌能力 MCP 化」的方案设计：哪些业务适合原子化成工具、工具边界怎么划、如何用排行榜机制做外部征集。
培训化：「从 0 做一个 MCP Skill」是最好的入门级 Workshop 题材——门槛低、有真接口、当天能出成果、还能顺手参赛。详见第 21 节。
内容化：「我用官方 MCP 做了个 XX」是天然的实操内容题材（B站 / 小红书 / 公众号），尤其是「一句话查出附近还有名额的生日派对」这类有画面感的结果。
行业化：把「活动 × 门店 × 名额 × 下单」这套模式抽象出来，复用到连锁服务业的任意细分——这是本次案例最值钱的抽象。
18｜变现路径
| 路径 | 客户／产品·服务／收费方式／难度 |
| A｜Skill 交付 | 想接 MCP 但没人做的中小企业 ／ 业务能力 MCP 化 + Skill 开发 + 文档 ／ 项目制 ／ 中（需企业侧接口权限） |
| B｜行业解决方案 | 连锁餐饮/零售/教培/健身 ／ 「活动+门店+名额+下单」Agent 方案 ／ 项目制 + 年维 ／ 中高 |
| C｜培训 / Workshop | 企业内训、高校、AI 训练营 ／ 「一天做一个 MCP Skill」 ／ 按人 / 按场 ／ 低 |
| D｜内容 / IP | 开发者社群、B站/小红书受众 ／ 实操教程、源码解析、参赛复盘 ／ 流量 + 咨询转化 ／ 低 |
| E｜参赛获奖 | 官方（本次赛事） ／ 第 1 名 = 巨无霸 50 次免费兑换券 + 10240 WorkBuddy 积分；入榜 = 汉堡回车键玩具 + 程序员节徽章；提交 workbuddy.md 的前 100 名另得 3000 WorkBuddy 积分 ／ 名次制 ／ 低 |
重要区分：上表中，E（参赛获奖）是已经验证的确定性回报——奖励内容与规则由官方文件公开载明；A/B/C/D 全部属于基于案例结构推导的潜在商业模式，不是已验证的商业成功，且 A/B 受官方商业条款限制，需取得授权。本报告不承诺任何收益。
19｜如果我是一个中国独立开发者
假设：1 个人、预算有限、有基础编程能力、使用国产模型。目标：7 天做出一个能参赛、也能留在作品集里的最小可行版本（MVP）。
- Day 1｜拿 Token，跑通最小闭环。申请 Token → 配进客户端 → 只调用一个工具（如
query-meals），确认能拿到真实菜单。验收：一句话问出今天的菜单。
- Day 2｜画工具边界表。把要用到的 5～8 个工具列出来，每个写清「返回什么 / 不代表什么」。这一步决定后面会不会说错话。
- Day 3｜定义不变量。确定哪些结论必须来自字段（如「有名额」=
leftNum > 0），哪些必须降级为「待核实」。把这些写成硬规则，不交给模型。
- Day 4｜串第一条多步链。活动日历 → 商品 → 城市 → 门店 → 日期 → 场次，跑一遍真实数据，记录每一步的真实返回结构（不要照抄文档字段名）。
- Day 5｜做交付物。把结果渲染成一个自包含的单文件 HTML（可筛选、可导出
.ics），而不是只输出一段文字。
- Day 6｜补异常路径。限流 429、Token 失效、工具名不符、字段缺失、无结果——每一条都要有明确提示，而不是让模型猜。
- Day 7｜打包 + 写文档 + 报名。整理 README.md / CONTEST_DECLARATION.md / MCP_INTEGRATION.md / mcp-config.example.json；写
workbuddy.md；发报名 Issue。
现实提醒：这份 7 天计划假设你每天能投入 2–4 小时，且当天就能拿到 Token。真正的瓶颈通常不在写代码，而在 Day 3 的不变量设计——想清楚「什么话绝对不能说」，比多加两个工具重要得多。
20｜如何迁移到其他行业
① 连锁服务预约医美 / 健身 / 教培试听 / 摄影：把「门店 × 项目 × 可约时段 × 名额」原子化成工具，Agent 负责一句话履约。
② 票务与展会演出 / 展览 / 赛事：活动日历 → 场次 → 余票 → 下单，与本案结构几乎一一对应。
③ 企业内部自助服务IT 报修 / 行政申请 / 会议室预订：把审批流封装成 MCP 工具，HR/IT/行政共用一个 Agent 入口。
迁移的关键不是「找一个也用 MCP 的品牌」，而是识别业务里是否存在「多条件筛选 + 实时余量 + 一次性提交」这个结构——只要有，这套方法就能直接搬。
21｜培训课程设计
| 课程名称 | 《一天做出你的第一个 MCP Skill：从官方 MCP 到可交付 Agent》 |
| 适合人群 | 有基础编程能力的开发者、AI 产品经理、想把业务接口 MCP 化的企业技术人员、准备参赛的选手 |
| 建议时长 | 半天（3.5 小时）为主，可拆成 30 分钟 Demo / 60 分钟 Workshop |
| 30 分钟 Demo | 现场申请 Token → 配进客户端 → 一句话问出「附近还有名额的活动」→ 生成活动地图。让学员先看到结果。 |
| 60 分钟 Workshop | 学员自己走一遍 Step 1–6；讲师强调两个关键点：装完要重开会话、结论必须来自字段。 |
| 半天课程 | 上半场：MCP 是什么、为什么品牌要开放能力（15 分钟）→ 动手跑通（45 分钟）。下半场：工具边界设计（45 分钟）→ 不变量与异常路径（45 分钟）→ 产出包装与投稿（30 分钟）。 |
| 课程目标 | 学员最终能够：独立完成一次 Token 申请与客户端配置；把一条业务链路拆成 5–8 个工具；写出「能力 / 边界」对照表；交付一个可交互的产物。 |
| 现场 Demo | 「这个周末附近哪家麦麦有生日派对还有名额？」——从提问到地图的完整链路。 |
| 学员练习 | 把一个自己熟悉的业务（哪怕是公司内部系统）拆成工具清单 + 边界表，不上线，只交设计。 |
| 课后作业 | 基于官方 MCP 做一个单场景 Skill，附 README 与 MCP_INTEGRATION.md，可直接投稿参赛。 |
| 企业迁移 | 把课程主体换成「企业自有系统的 MCP 化」：如何选工具粒度、如何做权限与审计、如何与现有审批流共存。 |
22｜培训师点评
点评：这个案例真正值得教的不是「怎么调 API」，而是「工具边界表」与「不变量」这两个动作——为什么 campaign-calendar 有结果不能等于「有名额」，为什么「可预约」必须落在 leftNum > 0 这唯一一个字段上。学员学完这一课，能拿走的是一套可迁移到任何企业 Agent 的工程直觉：模型负责不确定的语言，系统负责确定的事实。
23｜最终判断
为什么商业价值标「中高」而不是「高」：能力供给端毫无疑问是高的（中国企业第一次把整条业务链路 MCP 化），但官方商业条款明确限制了转售与引流变现，所以对普通开发者而言，可变现的接口是「做服务」而不是「卖产品」。这个扣分是刻意的。
02
把「热点日报站」做成可复制的引擎：AIHOT 开源全部 25 份提示词与入选门槛，一个人就能给自己的行业搭一个日报站
AI + 内容 / Research 完整 Workflow
开源引擎
RSS + 微信公众号信源
Docker 一键部署
窗口内：15 次提交
无 Release · 数据自述
【一句话结论】它把「选题 → 预筛 → 两次独立评分 → 写作 → 聚簇 → 热度 → 成刊」这条链路做成了开源引擎，并把提示词和入选门槛全部公开——这是「日报自动化」第一次从个人脚本变成可被复制的产品级框架。
01｜案例是什么？
AIHOT 是一个「自己找热点、自己写日报」的网站框架。它每天从一批信源里收资料，用大模型先筛一遍、再独立打两次分，挑出真正值得看的，写成中文标题和摘要；把不同来源说的同一件事聚成一个「事件」，按有多少人在说排热度，每天早上出一份日报。
作者把引擎本身开源了：网站、后台、精选流程、聚簇与热度算法、以及全部提示词原文和入选门槛，都在仓库里。他自己在 README 里说得很直白：「把信源换成你的，把精选标准换成你的 KnowHow，它就是你的行业热点站。」
仓库自带 18 个公开的海外 AI 资讯源做示范，够跑起来看效果；真正的信源和运营数据不在仓库里。
02｜为什么今天值得关注？
- 因为它正在被「工程化」而不是被「展示」。窗口内（10-09 → 10-10 UTC）该仓库有 15 次提交，集中在引擎侧的质量控制：撤下/补齐导航隐藏入口、修复「首个日报之前结束的周/月报不该出刊」的排期 bug、给「读者用词替换」补齐步骤说明、把撤回过的报道从聚簇证据里排除、隐藏掉桥接证据被撤销后的关联事件。这些改动说明它已经从「能跑」进入「跑得稳」阶段。
- 因为它的成本被压到了个人可承受。部署只需要 Docker + Node 24 + 一个 OpenAI 兼容的模型 Key，默认按 DeepSeek 配置，README 明确支持千问、智谱。一条命令起站。
- 因为它是「AI + 内容」方向少见的完整闭环。本系列连续多期找不到合格的「AI + 内容创作」一手案例，多被内容农场占据。这一个不是教程、不是工具推荐，而是一条可部署的完整流水线，附全部提示词。
如实说明本期的窗口证据强度：AIHOT 在窗口内没有发布新版本（该仓库不使用 GitHub Releases），窗口事件是 15 次引擎提交，属渐进式更新而非重大版本。我们仍将其收录，因为：① 「新更新」本身符合收录口径；② 其可复现性、一手程度与可迁移性在当日候选中最高；③ 当日没有第三个案例达到收录标准。我们同时提示一个指标异常：7022 ★ 对应 1723 Fork，而仅有 22 个 Watcher，Star/Fork 比例明显高于开源项目常态，其增长质量无法独立验证。
03｜案例的前世今生
前世（为什么会出现？）「把信息汇总成日报」这件事，过去十年经历了三代：第一代是 RSS 阅读器（人自己筛），第二代是爬虫 + 关键词（规则筛，误报多、重复多），第三代是 LLM 摘要（一句话总结，但没有取舍——所以每天都能生成一份「什么都说了等于什么都没说」的日报）。真正没被解决的那个问题，是「取舍标准」本身。
发展（这个项目自己讲的很清楚）
- 作者自述是设计师出身，「半年前还看不太懂代码」，这套代码是他和 AI 一起重写的——这是典型的 2026 年现象：非传统程序员用 AI 做出了产品级系统。（来源：作者 README 原文，属自述）
- 关键转变是「把标准外置」。大多数类似项目把筛选逻辑写死在代码里；AIHOT 把每一步的提示词放进
industry/prompts/，「改标准不用改代码」。这一步让它从「一个网站」变成了「一个可被改造的框架」。
- 然后是「可校准」。它提供
SelectBench，用你自己标注的样本去校准评分门槛；仓库里还带 gold.example.jsonl、relation-gold.example.jsonl、story-digest-eval.example.jsonl 等评测样例文件。
- 接着是「需求外溢」。作者原话：这半年「很多做法律、做 HR、做金融、做贵金属的朋友问我，能不能也给他们的行业做一个」——他做不了，因为他不懂那些行业，所以选择把引擎开源出去。（来源：作者 README 原文，属自述）
今生（为什么现在值得关注？）三件事同时具备了：① 模型成本降到「一天几百条信源打分」个人付得起；② Agent 编程能力让「非专业开发者重写一整套产品」第一次成为现实；③ 行业信源（尤其微信公众号）第一次可以在同一个流水线里和 RSS、X、JSON 接口并列处理。当「标准可以外置 + 信源可以自选 + 部署只要一条命令」三件事凑齐，它就从个人作品变成了可以被上百个行业各自改造的模板。
下一步可能怎么发展（分析 / 推演，非事实）
- 最可能的形态是「模板创业」：一批垂直行业热点站出现（法律、HR、金融、贵金属、宠物、母婴……），商业模式从「自己运营」转向「卖定制的站 + 代运营」。
- 第二批机会在「校准服务」：门槛怎么定、什么算重要，这是行业 KnowHow，正好是可以收费的部分——作者自己已经点了这个痛点。
- 风险：模板被大量复制后，同质化与信源版权/合规会成为主要约束；此外作者明确要求「不要用 AIHOT 的名字和 Logo」，说明他对品牌稀释是有防备的。
04｜原始资料
05｜作者是谁？
- GitHub：
KKKKhazix，昵称 Khazix。账号注册于 2025-10-22，公开仓库 4 个，followers 4065，未填写公司、博客、Twitter、bio。没有任何可核验的实名或职业信息。
- 作者自述：「我不是专业的开发者。我是设计师出身，半年前还看不太懂代码。这套代码是我和 AI 一起重写的。」（引自 README 原文 —— 这是作者自述，本报告无法独立验证）
- 可核验的客观事实：他确实拥有一个稳定运行的线上站（aihot.news），确实开源了 4 万行级别的完整工程（Dockerfile、docker-compose.yml、packages/、modules/、database/、deploy/、tests/、25 份提示词），也确实在持续迭代（窗口内 15 次提交）。至于「半年前看不懂代码」这一细节，属自述，存疑即存疑。
06｜解决了什么真实问题？
从用户需求讲起，不是从技术讲起：
- 「我盯的这个行业，每天发生的事我根本看不过来。」一个律师要盯法规动态与判例，一个 HR 要盯劳动政策，一个做贵金属的要盯行情与政策。这些信息散在几十个信源里，其中一部分只存在于微信公众号——最难聚合的那一类。
- 「看不过来」的下一层是「看错了」。同一个消息，官网发一篇、媒体转十篇、朋友圈刷一天。人真正的负担不是信息量，而是去重与判断重要性。AIHOT 对这个问题的回答是把「事件」而不是「文章」当作基本单位：48 小时内每个独立来源只算一次热度、24 小时减半——所以排名靠前的是真正有很多人在说的事，而不是某家媒体发得最多的事。
- 「我不需要一个 AI 帮我总结，我需要一个 AI 帮我取舍。」这是本项目与「RSS + 大模型摘要」的根本区别：摘要解决「看懂」，取舍解决「值不值得看」。而取舍标准，是可配置、可校准、可用自己标注的样本去验证的。
07｜完整技术栈
| 运行时 | Node.js 24（运行 init-env 生成配置需要） |
| 数据库 | PostgreSQL 17 |
| 部署 | Docker + docker-compose（仓库含 Dockerfile / docker-compose.yml / deploy/） |
| 语言 | TypeScript（tsconfig.base.json，含 packages/ 多包结构） |
| 模型 | 任意 OpenAI 兼容接口。默认按 DeepSeek 配置；README 明确说明可用「千问、智谱等」——即 Qwen / GLM 属官方支持范围 |
| 模型路由 | 后台支持「每一步单独换模型」；聚簇复核可单独指定 GROUP_REVIEW_MODEL；推理模型需设 LLM_REASONING_TOKENS 预留输出额度 |
| 信源 | 六种：RSS、网页列表、JSON 接口、X 账号、微信公众号、自定义脚本推送 |
| 信源分级 | 三级 T1 官方一手 / T2 官方账号与准官方 / T3 媒体与个人，各级入选门槛不同；抓取频率按产出自动调整 |
| 对外接口 | RSS（精选/全部/全文/日报/周报/月报）、公开 API（/openapi-v1.json）、MCP、Agent Markdown、llms.txt |
| 后台 | /admin：信源管理与试抓、内容诊断与人工评分更正、精选评测、预算熔断、运行记录与告警 |
| 提示词 | industry/prompts/ 下 25 个 .md，其中 selection-score.md 9.7 KB、structure.md 7.3 KB、rules-domain.md 3.9 KB、content-understanding.md 6.3 KB；另有 industry/wording.ts（用词表）、taxonomy.ts、topics.json |
| 许可 | MIT |
08｜完整 Workflow
信源层：RSS / 网页列表 / JSON / X / 微信公众号 / 自定义脚本推送 → 同一网址同一内容只留一份
↓
预筛（prefilter.md）：这是不是本行业的事。宽进——只拦明显无关的；只有标题没正文的先等材料，不评分、不凭标题写文案
↓
评分（selection-score.md）：同一份评分标准独立打两次分（0–100），两次之和 ≥ 2 × 门槛才够分；门槛按信源分级（T1/T2/T3）不同；页面上显示的是两次的平均（向下取整）
↓
结构化（structure.md）：分类/标签/主体公司；判断是「一条具体新闻」「综合稿」还是「说不清」；抽出「谁、做了什么、对什么、什么时候」与原文出处
↓
写作（content-understanding.md 等）：中文标题、答案先行的摘要、推荐理由；用词表命中的词让模型只改一次（mend-wording.md）
↓
归组与去重（group-*.md）：不同来源的同一件事聚成一个「事件」；用标题摘要向量（未配向量服务则比文字重合度）找候选 → 模型判断「同一件事 / 后续进展 / 两件事」→ 写入前再让模型复核一遍
↓
热度：按事件算，不按文章算。48 小时内每个独立来源只算一次，24 小时减半；和 6 小时前比涨得快的标「上升」
↓
成刊：日报（默认 08:00）→ 周报（周一 10:00）→ 月报（每月 1 日 10:30），从日报汇编，编排出刊不调模型，模型只写总述与栏目导读
09｜它到底是怎么实现的？
这套系统里真正有技术含量的，不是「调模型写摘要」，而是三个反直觉的设计：
- ① 两次独立评分，而不是一次打分。单次 LLM 打分方差大，同一个条目今天说 80 分明天说 55 分。它用「同一份标准独立打两次，两次之和 ≥ 2 × 门槛」来对抗这种抖动。这是把「模型的随机性」当成工程参数处理，而不是靠调提示词祈祷。
- ② 门槛按信源分级，而不是一刀切。T1（官方一手）容忍低分——官方发的就是重要的；T3（媒体与个人）要求高分——因为噪音大。这等于把「信任度」显式建模成了评分函数的输入。
- ③ 热度按事件算，每个来源只算一次。如果按文章数算热度，一家媒体发十篇就赢了。按「独立来源数」算，只有一个来源反复报道的事件不会进榜。这条规则直接决定了榜单的信息价值，而不是它的工作量。
另外两个工程细节值得单独记下来：
- 「旧文不刷屏」：没有可信发布时间的资料先不公开，读到原文日期后再判断新旧——这是自动日报最容易被忽略的失真源。
- 「有正文才写文案」：X 帖子没有正文或只有链接时，保留原帖的链接、图片和引用，不调用写作或翻译模型。这一条把一个高风险的幻觉路径直接砍掉了。
10｜手把手复现
以下 Step 1–4 来自作者 README 原文（命令逐字照抄）；Step 5–7 为本报告整理。
Step 1（原文）· 拿代码
想创建独立站点可直接点仓库的 Use this template 生成自己的仓库；想持续合并上游更新建议先 Fork。
Step 2（原文）· 生成配置
需要 Docker、Node.js 24，和一个 OpenAI 兼容的模型 API Key（DeepSeek、千问、智谱都可以）：
git clone https://github.com/KKKKhazix/AIHOT.git myhot
cd myhot
node scripts/init-env.ts --llm-key <你的模型 API Key>
docker compose up -d --build
打开 http://localhost:3000，后台在 /admin，管理员密码在 .env 的 ADMIN_PASSWORD 里。作者原文：「一两分钟后开始有内容，第一次导入的资料大约半小时处理完。」
Step 3（原文）· 换成别家模型
init-env 默认按 DeepSeek 配置；用千问、智谱等，照 .env.example 改 LLM_BASE_URL、LLM_MODEL 和 LLM_EXTRA_JSON；用推理模型时还要设 LLM_REASONING_TOKENS 给推理留出输出额度。
Step 4（原文）· 改成你的行业
作者给的最省事办法是把仓库直接交给你的编程 Agent：
请读 AGENTS.md 和 docs/customize.md，把这个站改成「XX 行业」的热点站。
我关心的是：……（写你想盯的信源、你觉得什么消息重要、什么不重要，越具体越好）。
改完帮我跑 npm run typecheck、npm test 和 node scripts/smoke.ts，
并告诉我还需要我自己决定哪些事。
要改的东西几乎都在 site/ 和 industry/ 两个目录里，代码基本不用动（站名、出刊时间 EDITION_TIMES、信源、提示词、用词表、分类）
Step 5（本报告整理）· 增信源
在 /admin 的「信源」里新建（或修改示范的 industry/sources.json）：选 kind（rss / 网页列表 / json / x / 微信公众号 / 脚本）、给 tier（T1/T2/T3）、给 interval_minutes。先用「试抓」验证，再启用。
Step 6（本报告整理）· 校准门槛
自己标注一批样本（结构参考仓库里的 industry/gold.example.jsonl），在 SelectBench 里把现有提示词与候选提示词并排比较，再决定门槛。作者明确说门槛是「可以改的」。
Step 7（本报告整理）· 接给 Agent
站点跑起来后打开 /agent 复制 MCP / RSS / API 接入方式；只能读网页的 Agent 从 /api/v1/agent 开始。
必须标注：Step 1–4 与三处引号内文字均为作者 README 原文；Step 5–7 为本报告基于其公开文档（docs/selection.md、docs/customize.md、industry/sources.json）的整理。本报告未实际部署该系统做端到端验证。
11｜Prompt / Code / Config
这是本案例最有价值的部分：提示词是公开的。仓库 industry/prompts/ 下有 25 个 Markdown 提示词文件，包括：
- 筛选链：
prefilter.md（预筛）、selection-score.md（评分，9.7 KB，最大的一份）、identity-context.md、understand.md
- 写作链：
content-understanding.md、structure.md、summarize-article.md 及针对「长帖/短帖/引用/空正文」的多个变体、translate-body.md、mend-wording.md
- 规则层：
rules-domain.md（行业规则，3.9 KB）、rules-answer-first-summary.md（答案先行）、rules-anti-hallucination.md（反幻觉）、rules-self-contained-title.md（自足标题）
- 聚簇链：
group-definitions.md、group-method.md、group-pair.md、group-batch.md、group-signal.md、story-digest.md（事件综述）
- 成刊：
report-period.md 及其带/不带栏目两个变体
配置类：.env.example（LLM_BASE_URL / LLM_MODEL / LLM_EXTRA_JSON / LLM_REASONING_TOKENS / GROUP_REVIEW_MODEL / ADMIN_PASSWORD）、industry/sources.json（信源，含 tier / owner_entity_id / participation_mode / interval_minutes）、industry/wording.ts（不想出现的词表）、industry/taxonomy.ts、industry/topics.json（主题）、site/site.ts（站名、EDITION_TIMES、NAV.hidden）。
评测类：gold.example.jsonl、relation-gold.example.jsonl、story-digest-eval.example.jsonl —— 这是「可校准」的落地形态。
本文核对：以上目录与文件均为我们在仓库中实际读取到的一手内容（文件名、体积、字段名均照实记录）。本报告只做结构总结，未逐字翻译或复述提示词正文。请注意 rules-domain.md、taxonomy.ts、topics.json 目前是AI 行业的版本，改成你的行业时必须重写。
12｜踩坑
坑 1｜把「摘要」当成了「取舍」。很多人做自动日报的第一反应是「抓下来让模型总结」。结果每天都能生成一份内容，但读者依然不知道什么重要。解法：先定义门槛，再定义摘要。（来源：项目设计逻辑，本报告归纳）
坑 2｜只有标题就敢让模型写文案。这是幻觉的高发区。项目的处理是硬规则：只有标题/摘要的普通文章先等待材料，不评分、不写文案；X 帖子无正文时保留原帖链接与图片，不调用写作或翻译模型。（来源：docs/selection.md）
坑 3｜旧文刷屏。没有可信发布时间的资料如果直接公开，会把几个月前的旧闻当成今天的新闻推。项目的处理是「旧文不刷屏」：读到原文日期后再判断新旧。（来源：docs/selection.md）
坑 4｜单次 LLM 打分的方差。同一个条目两次打分可能差 20 分以上。解法：独立打两次、要求和 ≥ 2 × 门槛。（来源：docs/selection.md）
坑 5｜按文章数算热度 → 一家媒体刷榜。解法：按事件算，48 小时内每个独立来源只算一次，24 小时减半。（来源：作者 README）
坑 6｜出刊排期边界。窗口内的一次提交正是修这个 bug：「在第一个日报之前结束的周/月不该出刊」——月中建站时会凭空生成一份空周报。（来源：窗口内提交记录，10-09）
坑 7｜「读者用词」改不干净。作者自述曾在一个分支统计过：入选的 166 条里，靠提示词里写「不要用某些词」并不能真的让模型不写。解法：写完之后按行业用词表再让模型只改这些词一次（独立的 mend-wording.md 步骤）。（来源：窗口内提交记录中的说明文字，属作者自述）
13｜中国用户能不能直接做？
- 国内访问：代码与文档在 GitHub，需要自备网络条件访问；部署本身可在国内服务器完成（README 专门有一节讲「服务器在中国大陆、要配域名和 HTTPS」）。
- 注册：无需注册任何平台账号（不是 SaaS，是自托管）。需要一个模型 API Key。
- API：只需一个 OpenAI 兼容接口。默认就是 DeepSeek，千问、智谱官方支持——对国内用户非常友好。
- 成本：软件本身 MIT 免费。真实成本 = 模型 API 调用量 + 服务器 + 可能的向量服务。作者提到后台有「付费服务的预算熔断」。作者未公布单站月成本，我们不估算、不编造。
- 技术门槛： 有一定门槛（AI 用户可做） —— 需要会 Docker、看得懂
.env； 开发者级（做定制） —— 改行业规则、调门槛、写自定义信源脚本需要 TypeScript 能力。作者自述「不要求你是专业人员」，其本人也是设计师出身。
14｜国产替代方案
| 原方案 | AIHOT 引擎 + 任意 OpenAI 兼容模型 |
| 国产替代 | 不需要替代——项目本身就是国产项目，且默认配置就是国产模型（DeepSeek）。README 明确写出「DeepSeek、千问、智谱都可以」，属官方支持（非理论推测）。 |
| 模型替换 | 后台支持每一步单独换模型：筛选用便宜模型、写作用好模型、聚簇复核再换一家（GROUP_REVIEW_MODEL）。这是国产多模型混搭的实用样板。 |
| 信源替换 | 六种信源里包含微信公众号——这是海外同类项目通常不支持的。对做中国行业情报站是决定性优势。 |
| 同类国产方案 | 若只想做「RAG + 摘要」而不需要取舍与聚簇，Dify / Coze 的工作流足以覆盖；若需要「事件聚类 + 热度」这一层，本次采集未找到同口径的国产开源替代，故不做横向对比结论。 |
15｜中国企业可以怎么用？
企业场景 1｜垂直行业情报站（对外获客）。律所、HR SaaS、财税服务商、券商研究所、大宗商品贸易商：做一个本行业的热点日报站，用「每日精选」做持续获客，用「事件时间线」做客户教育。这不是营销页，是有复用价值的工具型内容资产。
企业场景 2｜企业内部舆情 / 竞品情报台（对内）。把信源换成竞品官网、行业媒体、政策发布平台、社交账号，产出一份每天早上 8 点到岗的内部简报。关键收益是把「人肉搜 + 群转发」替换成一条固定流水线，且每条都带原文出处。
企业场景 3｜销售 / 采购线索雷达（对外作战）。本案的「事件聚类 + 独立来源数计热度」正好对应「一件事有多少人在说」——这在采购线索、招投标信息、政策变动预警上，比关键词匹配准确得多。
16｜中国消费者可以怎么用？
- 自建个人「信息减负」站：把关注的公众号、垂媒、政策发布源接进来，每天早上只看一份，不再刷群。
- 自建「备考 / 求职」情报站：把信源换成本专业院校通知、行业招聘、政策发布，用「事件」形式看趋势而不是看零散帖子。
- 自建家庭 / 小区信息站：把本地政务、交通、天气预警、业主群公告聚成一份日报——技术上是同一套。
17｜如何变成一个赚钱的项目？
产品化：「模板 + 托管」是最直接的形态：给某个行业起一个站，作者原话是「换上你自己的名字，它就是你的站」。可做独立站订阅，也可以做成只读的公开站 + 会员看历史与全文。
服务化：「帮你做一个你行业的 AIHOT」——交付范围清晰（选信源、定门槛、调提示词、部署上线、跑通日报），因为引擎开源，交付成本远低于从零开发。作者本人说「做不了，我不懂你们的行业」——这句话本身就是市场需求证明，也是差异化壁垒所在。
咨询化：门槛与「什么算重要」是行业 KnowHow，这部分最贵。可以做「信源审计 + 取舍标准设计」的轻咨询，也可做长期的月度校准服务。
培训化：「用开源引擎搭一个你行业的 AI 日报」是极好的实操课，学员当天能看到自己的站在跑。详见第 21 节。
内容化：项目本身就是一个内容题材（「我用 AI 做了个行业日报站，每天只看 10 分钟」），而站本身又是内容载体——内容与产品互相导流。
行业化：本案例最典型的「多行业复制」结构，同一份引擎可以长出 N 个垂直站。
18｜变现路径
| 路径 | 客户／产品·服务／收费方式／难度 |
| A｜行业站 SaaS | 垂直行业读者（法务/HR/金融/大宗） ／ 行业热点站 + 会员 ／ 订阅 ／ 中（获客是难点） |
| B｜建站交付服务 | 需要行业情报能力的中小企业 ／ 「你的行业 AIHOT」一次性交付 ／ 项目制 ／ 低中（引擎已开源） |
| C｜门槛校准咨询 | 已有站但精选质量差的团队 ／ 信源审计 + 取舍标准设计 + 评测 ／ 咨询费 / 月度 ／ 高（要行业 KnowHow） |
| D｜企业内训 / 训练营 | 企业内容团队、媒体、咨询公司 ／ 「搭你行业的信息流水线」 ／ 按场 / 按人 ／ 低 |
| E｜内容 / IP | 开发者与自媒体受众 ／ 教程、源码解析、运营复盘 ／ 流量 + 服务转化 ／ 低 |
重要区分：目前唯一可被视作「已验证需求信号」的是作者自述的一段话——半年内有做法律、HR、金融、贵金属的朋友主动问他能否给这些行业做，这是作者自述、无法独立验证，且不是成交记录。A–E 五条路径全部属于基于案例结构推导的潜在商业模式，本报告不承诺收益。
19｜如果我是一个中国独立开发者
假设：1 个人、预算有限、有基础编程能力、使用国产模型。目标：7 天上线一个垂直行业热点站。
- Day 1｜选行业，不选技术。选一个你真正懂取舍的细分行业（法律、宠物、母婴、地方政务、某个制造业）。判断标准：你能说出「什么算重要」。
- Day 2｜列信源清单。列出 15–25 个源，按 T1/T2/T3 分级。重点补微信公众号类源——这是别人抄不走的壁垒。
- Day 3｜部署跑通。
git clone → node scripts/init-env.ts --llm-key <DeepSeek Key> → docker compose up -d --build，先看示范信源的默认效果。
- Day 4｜换信源 + 换站名。改
industry/sources.json、site/site.ts、taxonomy.ts；按 docs/customize.md 走一遍。
- Day 5｜改取舍标准。重写
rules-domain.md、调 selection-score.md 与门槛。这是工作量最大也最值钱的一天。
- Day 6｜标注样本校准 + 配用词表。标 30–50 条样本进 SelectBench；把不想出现的词写进
wording.ts。
- Day 7｜上线 + 铺分发。部署 + 域名 + HTTPS，打开
/agent 拿到 MCP / RSS 接入方式，把 RSS 挂到自己的分发渠道。
现实提醒：这份计划里唯一不能压缩的是 Day 5。技术部署一天就够，取舍标准一周都未必够。真正的护城河不在代码，在「什么算重要」这个判断上。
20｜如何迁移到其他行业
① 法规合规情报法规发布平台 + 判例 + 监管公众号 → 每日合规简报，服务律所、财税、企业法务。
② 招投标 / 采购线索招投标公告 + 行业媒体 + 政府发布 → 事件化线索雷达，服务销售与代理商。
③ 跨境电商选品情报平台政策 + 品类趋势 + 竞品社交账号 → 每日选品与合规预警，服务卖家与代运营。
迁移方法完全一致：换信源清单 → 重写行业规则提示词 → 重新标注样本调门槛 → 换站名上线。代码不动，这也是本案最值得抄的地方。
21｜培训课程设计
| 课程名称 | 《给你的行业做一个 AI 日报站：从信源到取舍标准》 |
| 适合人群 | 独立开发者、内容/媒体从业者、想做垂直情报产品的产品经理、企业市场与战略岗 |
| 建议时长 | 半天（3.5–4 小时），可拆出 30 分钟 Demo 与 60 分钟 Workshop |
| 30 分钟 Demo | 现场 git clone + 一条命令起站，让学员看示范信源跑出的每日精选与事件时间线。 |
| 60 分钟 Workshop | 学员各自列 10 个行业信源并分级，改 sources.json 后试抓，看自己的信源进来后精选质量如何。 |
| 半天课程 | 上半场：自动日报的三代演进、为什么「取舍」比「摘要」难（30 分钟）→ 部署动手（60 分钟）。下半场：两次评分与信源分级（45 分钟）→ 聚簇与热度（30 分钟）→ 门槛校准与用词表（45 分钟）→ 上线与分发（30 分钟）。 |
| 课程目标 | 学员最终能够：独立部署一个站；按 tier 给自己的行业信源分级；说清「两次评分」「按事件算热度」为什么必要；标注样本完成一次门槛校准。 |
| 现场 Demo | 「同一件事，官网发一篇、媒体转十篇」——现场演示聚簇如何把它们折成一个事件、热度只算一次独立来源。 |
| 学员练习 | 给自己的行业写 10 条「什么算重要 / 什么不算」的判断，作为 rules-domain.md 的草稿。 |
| 课后作业 | 上线一个自己行业的只读站，产出连续 3 天的日报截图，并交一份门槛调整记录。 |
| 企业迁移 | 把课程主体换成企业内部情报台：信源怎么选、权限怎么管、与现有内容流程怎么并存、如何避免变成又一个没人看的日报。 |
22｜培训师点评
点评：这个案例真正值得教的是「把判断标准外置并允许校准」这个动作。两次独立评分是为了对抗模型抖动，按信源分级定门槛是为了把「信任度」写进函数，按事件算热度是为了防止刷榜——三条都是可迁移的工程直觉。而它最值钱的一课其实与代码无关：先定义什么算重要，再让 AI 去执行。
23｜最终判断
为什么复现难度标「中」：「装起来」是低难度（一条命令），但「改成一个真正有用的行业站」是中高难度——卡在取舍标准的重写上。把难度如实标成中，是因为部署容易不等于有效，这一点正是本案例最容易被误读的地方。
为什么商业价值标「中高」：需求真实、案例结构清晰、复制成本低，但「谁来为行业情报付费」这一步尚未被验证，作者自述的行业咨询也未形成任何公开成交记录，因此不给满分。