AI极客实战案例日报

01｜案例是什么？

EEO 是 Everything Engine Optimization 的缩写，它是这个社区给 SEO、AEO、GEO、LLMO 起的统称（Apache-2.0，Node 18+，零依赖）。项目做三件事：① 建一个全球品牌目录（eeo.brand.v1 结构，含网站、行业、国家、LEI 法人识别码等字段）；② 提供一套「审计工具」，向真实的 AI 引擎提出真实买家会问的问题、把每次原始回答存档、再给品牌的可见度打分——工具以六种形态分发（单文件网页、CLI、自托管服务、MCP 服务、GitHub Action、浏览器扩展），内置 26 个引擎预设，其中 11 个是中国本土引擎；③ 让品牌通过公开 PR 完成域名验证，「认领」自己的名片。所有判定文件都存档在仓库里可供逐行审计。

02｜为什么今天值得关注？

• 窗口内的事实（可用 API 核实）：该仓库创建于 2026-10-05T12:24:03Z，即北京时间 10-05 20:24，落在本期窗口（10-05 12:00 → 10-06 12:00）内；此后持续推送（至 10-08）。
• 它回答了一个正在变成刚需的问题：当买家问 AI「推荐几个奶茶品牌」，模型的回答是从它读过的内容里拼出来的，而品牌自己的说法很少以结构化形式进入模型。这个项目就是冲着这个缺口去的。
• 为什么以前不容易做：「AI 可见度」这件事过去只能靠手工问几句、截图留证——分数不稳定、无法比较、更无法证明改进有效。它本质上缺的是度量方法，不是一个工具。
• 为什么现在值得花时间：它同时做了两件稀缺的事——把中国本土引擎放进预设（11 个），把度量方法写成了可复现的流程（冻结引擎快照、双引擎采样、双裁判立场判定并公布 kappa=0.909、Wilson 置信区间、Bradley-Terry 排序）。对做 GEO 服务的人来说，这套方法论本身就是可交付物。

03｜案例的前世今生

前世。SEO 时代，品牌关心的是「搜索页排第几」——这件事有确定答案，因为搜索页是固定的那一屏。品牌只要做好内容与链接，就能被看见。

发展。生成式 AI 改变了前提：买家不再看到一屏链接，而是拿到一段结论。于是「排第几」变成了「模型提没提你、怎么提你、在什么语境下提你」。行业把它叫做 AEO / GEO / LLMO，但很长一段时间里，这些说法都停留在「刷内容、塞关键词」的玄学层面，缺少可验证的度量。

今生。EEO 的做法是「把度量当第一性问题」：不先卖优化服务，而是先建可复现的评测——固定问题面板、冻结引擎快照、字节级可复现打分、双引擎采样、双裁判判定立场分歧（并公开 0.909 的一致性 kappa）、Wilson 置信区间、改写鲁棒性检查、Bradley-Terry 排名。作者明确说了它要回答单次审计的两个致命质疑：分数不稳定，以及把「被提及」误当成「被推荐」。

下一步可能怎么发展（分析 / 推演）。这类「AI 可见度」评测很可能成为品牌营销的常规预算项——就像当年的 SEO 报告一样。更值得关注的是它的两个衍生方向：一是「品牌事实源」的标准之争（谁的结构被模型优先采信），二是「优化服务商的行业行为准则」（README 中提到了一份五条的服务商行为 pact）。以上为推演，非事实。

04｜原始资料

• 开源仓库Hiteater-wzm/eeo（Apache-2.0，Node 18+，建于 2026-10-05T12:24:03Z = 北京时间 10-05 20:24）
  https://github.com/Hiteater-wzm/eeo
• 标准文档docs/eeo-standard.md（含五条优化服务商行为准则，CC BY 4.0）
  github.com/Hiteater-wzm/eeo/blob/main/docs/eeo-standard.md
• 中文说明README.zh.md（中文版说明）
  github.com/Hiteater-wzm/eeo/blob/main/README.zh.md
• 数据统计datasets/STATS-FULL.md（每次合并后由实时数据重新生成，为权威统计口径）
  github.com/Hiteater-wzm/eeo/blob/main/datasets/STATS-FULL.md
• 评测快照snapshots/panel-奶茶-v1-*（首个公开的固定问题面板快照）
  github.com/Hiteater-wzm/eeo/tree/main/snapshots
• 可复现命令README-AI.md（度量栈与复现命令）
  github.com/Hiteater-wzm/eeo/blob/main/README-AI.md
• 目录浏览社区实例（由种子集构建的静态品牌站）
  hiteater-wzm.github.io/eeo/

05｜作者是谁？

GitHub 账号 Hiteater-wzm，显示名 Hiteater，个人简介为「MAKE AMAZING EEO」，公开资料显示仅有 1 个仓库、81 个关注者——典型的「为一个项目专开账号」。README 中「How this was made」一节明确说明：代码、文档与数据管线借助 AI 完成，并由维护者审核后发布。其真实身份、机构背景未公开，本文不猜。

06｜解决了什么真实问题？

从需求侧看，痛点是「品牌在 AI 眼里是透明的」：

• 需求一（品牌方）。花了大钱做内容与公关，但顾客现在问 AI「哪个牌子好」，答案里可能压根没有你；更糟的是，你无法证明「做了之后有没有变好」。
• 需求二（营销服务商）。客户问「GEO 到底怎么做、效果怎么衡量」，行业里拿不出一套可复现的度量——只能凭感觉汇报。
• 需求三（买家侧的可信度）。如果 AI 的回答里混入了大量品牌自己灌的水，最终受损的是使用 AI 的人。所以「品牌用结构化方式声明事实 + 可审计」，对双方都有价值。
• 共同点：不是「AI 不提我」，而是「没人知道 AI 为什么提我，也没人能证明我改了之后有没有用」。

07｜完整技术栈

模型	审计对象是各家 AI 引擎（内置 26 个引擎预设，其中 11 个为中国本土引擎），项目本身不绑定某一家模型；数据清洗环节使用「逐条目 AI 判定」。
运行环境	Node.js 18+，零依赖；核心入口 core.cjs / cli.cjs / server.cjs，另有 tools/ / mcp/ / action/ / extension/
六种分发形态	单文件网页（eeo-local.html）· CLI（cli.cjs）· 自托管服务（server.cjs）· MCP 服务 · GitHub Action · 浏览器扩展
数据集	datasets/registry/（13 个 JSONL 分片）；结构为 eeo.brand.v1
审计产物	原始回答存档 + 可见度分数 + 快照（snapshots/panel-奶茶-v1-*）
度量方法	固定问题面板 · 冻结引擎快照 · 字节可复现打分 · 双引擎采样 · 双裁判立场判定（公布一致性 kappa 0.909）· Wilson 置信区间 · 改写鲁棒性 · Bradley-Terry 排名
认领机制	域名验证在 CI 上通过公开 PR 完成，「不离开 Git」
许可	代码 Apache-2.0；标准文档与分类法 CC BY 4.0；数据卡（Wikidata 来源）CC0

08｜完整 Workflow

路径 A：做一次品牌可见度审计（源自 README 的命令）

路径 B：零门槛试用　直接用浏览器打开 eeo-local.html——不安装、不需要 Key，密钥保存在浏览器 localStorage 里；也可以用 docker build + docker run 起一个社区实例浏览品牌目录。

路径 C：品牌认领　在目录里找到自己的名片 → 按 platform/README.md 通过域名验证提交公开 PR → CI 校验通过后生效。

09｜它到底是怎么实现的？

这个项目最值得拆的不是数据量，而是它把「度量」当成工程问题来解决的四个动作：

① 明确定义并解决「分数不稳定」。单次问 AI 得到的答案会漂。项目的应对是：固定问题面板 + 冻结引擎快照 + 字节级可复现打分。这三者合起来，把「一次问答」变成了「一次可重复的实验」。

② 区分「被提及」与「被推荐」。这是 GEO 评测里最容易被糊弄的地方——模型提到你的名字，不等于在推荐你（可能是反面举例）。项目用双裁判判定立场并公开一致性 kappa（0.909），等于把「主观判断」也纳入了可审计范围。

③ 统计上不打折扣。Wilson 置信区间回答的是「这么小的样本量，这个排名可信吗」；Bradley-Terry 排名回答的是「两两对比如何汇总成全局顺序」；改写鲁棒性回答的是「换个说法问，结果还稳吗」。这三条一起出现，说明作者是按评测集的标准在要求自己，而不是按「demo 能跑就行」。

④ 数据质量可逐行审计。1,497,628 个候选经五轮逐条目 AI 判定，剔除 46,883 个非组织实体（单场活动、个人、地点、列表页、虚构、网页与垃圾）；每一份判定文件都存档在仓库里，清洗规则是可读代码，并用 LEI 法人识别码交叉验证。作者还立了一条规矩：数字必须与来源一起引用，STATS-FULL.md 每次合并后从实时数据重新生成，是唯一权威统计口径。

10｜手把手复现

Step 1（原文）。零门槛试用：用浏览器直接打开仓库里的 eeo-local.html。无需安装、无需 Key，密钥保存在浏览器 localStorage 中。

Step 2（原文）。命令行使用：cp config.example.json config.json 配好引擎 Key（浏览数据不需要），然后跑：

node cli.cjs check 蜜雪冰城 --industry 餐饮

Step 3（原文）。自托管社区实例：docker build -t eeo-community . 然后 docker run -p 8080:80 eeo-community，得到一个由策展种子集构建的静态品牌站。

Step 4（原文）。想要可复现的评测，按 README-AI.md 的「measurement stack」章节执行；结果对照 snapshots/ 里的公开快照。

Step 5（原文）。品牌认领：在目录中找到自己的名片，按 platform/README.md 走域名验证并提交公开 PR。

Step 6（本文补充的建议）。先拿 3–5 个你熟悉的品牌做「人工基线」：自己问一遍引擎、记下答案，再用工具跑一遍，对比两者是否一致。这一步能帮你判断工具在你的行业里是否可用。此建议为本文推导。

Step 7（本文补充的建议）。把审计结果做成「时间序列」而不只是单次报告——连续 4 周每周跑一次同一面板，趋势比绝对值更有说服力。此建议为本文推导。

11｜Prompt / Code / Config

原作者公开的内容（可直接引用）：

• 快速开始命令：cp config.example.json config.json；node cli.cjs check 蜜雪冰城 --industry 餐饮；docker build -t eeo-community . / docker run -p 8080:80 eeo-community
• 数据规模与来源口径：datasets/STATS-FULL.md（含「数字必须与来源一起引用」的 house rule）、tools/gen-stats.cjs
• 数据结构：eeo.brand.v1；datasets/registry/ 共 13 个 JSONL 分片
• 清洗与判定证据：tools/clean-registry.cjs、datasets/harvest/verdicts/（逐条目判定文件）
• 标准与分类法：docs/eeo-standard.md（含五条服务商行为 pact）、standards/taxonomy/（特征库与买家问题库）
• 度量方法：双引擎采样、双裁判立场判定（kappa 0.909）、Wilson 置信区间、改写鲁棒性、Bradley-Terry 排名；首个快照 snapshots/panel-奶茶-v1-*

作者已明确声明的制作方式：「代码、文档与数据管线借助 AI 完成，并由维护者审核后发布」。这一点值得称赞——它主动交代了 AI 参与的程度。本文未独立复现其评测流程。

12｜踩坑

13｜中国用户能不能直接做？

• 国内访问：GitHub 直连不稳定；但项目自提供 eeo-local.html 单文件形态，下载一次后可离线使用，是比较友好的一点。
• 注册：无需注册；密钥保存在浏览器本地。
• API：要真正跑审计需要各家引擎的访问方式；只浏览数据不需要任何 Key。
• 成本：软件免费；成本在引擎调用与人工复核时间。零依赖 Node 18+ 意味着不需要服务器也能跑单机版。
• 技术门槛：普通用户可以试用（打开单文件网页）／有一定门槛（CLI 与评测流程）。

14｜国产替代方案

原方案的境外依赖	引擎预设中的国际模型、GitHub 分发、部分数据源（Wikidata 等）
中国用户方案	项目已内置 26 个引擎预设，其中 11 个是中国本土引擎；单文件版本可离线使用；目录数据本地落盘，可在内网部署
替代性质	作者已原生覆盖中国引擎（README 明确说明「including all major China-native engines」）——这是本案例对中国用户最直接的价值

15｜中国企业可以怎么用？

• 企业场景 1｜品牌 AI 可见度体检。用固定面板定期审计：顾客问「这类产品推荐哪个牌子」时，自家品牌出现频率与语境（被推荐还是被提及）。
• 企业场景 2｜营销效果的新指标。把传统 SEO 报表加上「AI 可见度」一栏，作为内容投放的第四类效果指标。
• 企业场景 3｜公开事实源建设。参考其认领机制，把公司基本信息以结构化方式发布并验证，让模型更容易正确引用你的事实。

16｜中国消费者可以怎么用？

• 核对 AI 的推荐是否靠谱：用工具看看某个品类里，AI 到底提到了哪些品牌、依据是什么线索——有助于理解「AI 推荐」的局限。
• 自己创业/开店：确认自家小店在 AI 眼里是否可见，以及该怎么描述自己的业务。
• 做本地探店内容：用审计结果作为选题线索（「AI 眼里本地奶茶 TOP10 和我心里的差在哪」）。

17｜如何变成一个赚钱的项目？

产品化：做垂直行业的「AI 可见度月报」——例如只做餐饮、只做宠物、只做医美，按月交付固定面板的趋势报告。这是最直接可规模化的形态。

服务化：GEO 诊断 + 事实源建设服务：帮企业把品牌事实结构化并提交验证，再按月跟踪可见度变化。

咨询化：帮品牌重新组织内容策略——从「写给搜索引擎」转向「写给模型读」，这是一个正在成形的咨询需求。

培训化：《GEO 入门：当顾客开始问 AI「买哪个」》——面向品牌市场部，半天课就能讲清方法论。

内容化：「AI 眼中的奶茶品牌排行」这类选题天然有传播力（项目自己就用「奶茶」做了首个公开面板）。

18｜变现路径

路径	客户 ｜ 产品/服务 ｜ 收费方式 ｜ 难度
行业月报	品牌/连锁 ｜ AI 可见度定期报告 ｜ 订阅 ｜ 中
GEO 服务	企业 ｜ 诊断 + 事实源建设 ｜ 项目制 + 维护 ｜ 中
咨询	品牌市场部 ｜ 面向模型的内容策略 ｜ 项目制 ｜ 高
培训	市场/公关 ｜ GEO 半天课 ｜ 按场 ｜ 低
内容	从业者 ｜ 行业榜单与解读 ｜ 广告/会员 ｜ 低

注意：以上为基于案例结构的潜在商业模式分析，非已验证的商业成功；项目未公开任何收入信息。

19｜如果我是一个中国独立开发者（7 天 MVP）

1. Day 1：下载 eeo-local.html 跑通零门槛版本，用自家或朋友的品牌试一次。
2. Day 2：选定一个垂直行业（建议：本地生活 / 餐饮），设计 20 个真实顾客会问的问题。
3. Day 3：用一个中国本土引擎跑一遍，把结果整理成一页「可见度快照」。
4. Day 4：找 3 家该行业的小老板免费出报告，问他们「哪一条最想改」。
5. Day 5：把最想改的那条做成一件可执行的事（结构化介绍、常见问答页等）。
6. Day 6：做落地页 + 一份脱敏样例报告，说明「怎么量、多久一次、能改什么」。
7. Day 7：推出低价「行业 AI 可见度月报」，先服务 3 家验证付费意愿。

20｜如何迁移到其他行业

21｜培训课程设计

22｜培训师点评

23｜最终判断

说明：以上是案例属性描述，不是排名。「落地性中」指完整评测流程仍需投入；「复现难度低」指单文件版本零安装即可试用。「商业价值高」是就方法论而言，不构成对项目本身的评价。

01｜案例是什么？

dailypaper-skills（Apache-2.0）是一套面向研究者的 Agent Skill 包：你说一句「今日论文推荐」，它会从 HuggingFace Daily/Trending 与 arXiv 发现论文、按你配置的研究兴趣筛选（默认关注大模型 RL、RL infra、世界模型/JEPA、灵巧手操作与物理仿真）、给出有态度有依据的分流（必读 / 值得看 / 可跳过），再对「必读」论文生成完整笔记（含公式、图表、概念链接），全部落进你自己的本地知识库（Obsidian 或普通 Markdown 目录）。它由 7 个 skill 组成，可装进 Claude Code、Codex、Cursor、GitHub Copilot、Gemini CLI、OpenCode、OpenClaw 等。最特别的一点是它明确做了一次成本工程：把高频的「主题相关性打分」交给一个便宜得多的判定模型（Jev），把贵的主模型留给点评与全文精读。

02｜为什么今天值得关注？

• 窗口内的事实（可用 API 核实）：该仓库在 2026-10-05 14:39 与 14:46（北京时间）出现两次提交——「Initial commit: daily paper research skills」与「Merge daily paper skills with Jev scoring and product documentation」，均落在本期窗口内；README 中公布的 Jev 成本对照也明确标注为「2026-10-05 单次对照」。
• 它给了两个具体数字：同一批 30 篇候选、两组都推荐 10 篇——GPT-6 Astra 约 $0.109264 / 10.35 秒，Jev 1.13.0 约 $0.000576408 / 0.52 秒；按官方标价折算费用降低 99.47%，两组入选重合 9/10。
• 为什么以前不容易做：「AI 追论文」的常见做法是全部交给一个强模型——效果不错，但每天都在烧钱，且相关性打分这种「重复劳动」用贵模型是浪费。
• 为什么值得花时间：它把一个通用的架构问题摆到了台面上：一条 Agent 流水线里，「判断相关性」和「生成内容」应该用不同的模型。这个分工思路可以套用到几乎任何高频 Agent 任务上（邮件分诊、工单分类、情报筛选……）。

03｜案例的前世今生

前世。「追论文」的第一阶段是订阅与手工：arXiv 邮件列表 + 关键词检索 + 自己判断。信息过载是常态，真正的问题不是「看不到」，而是「筛不动」。

发展。LLM 出现后，第二阶段是「把论文丢给聊天模型问它有没有用」。可行，但有两个问题：一是成本随论文量线性增长，二是模型越强、每次问「这篇跟我有关吗」越浪费。

今生。第三阶段出现了两个变化：① Agent Skills 让「一条研究工作流」可以被拆成可安装的包（抓取 / 点评 / 笔记各司其职）；② 判定模型这类「只输出概率分布、不生成文本」的小模型，让「高频判断」的成本降到可以忽略。dailypaper-skills 正是这两者的结合——并且它把成本对照做成了公开的、可复现的文档。

下一步可能怎么发展（分析 / 推演）。「贵模型做生成、便宜模型做判断」很可能成为 Agent 流水线的标准分工，就像数据库里「索引」与「存储」分工一样自然。进一步，这类判定模型还可能被用来做「质量门禁」——先由便宜模型把不合格的输出筛掉，再让贵的模型只处理值得处理的。以上为推演，非事实。

04｜原始资料

• 开源仓库huangkiki/dailypaper-skills（Apache-2.0，Python）
  https://github.com/huangkiki/dailypaper-skills
• 窗口内提交10-05 14:39 / 14:46（北京时间）
  github.com/huangkiki/dailypaper-skills/commits/main
• 成本基准docs/jev-benchmark.md（含原始请求、用量、价格来源与复现方法）
  github.com/huangkiki/dailypaper-skills/blob/main/docs/jev-benchmark.md
• 使用指南docs/usage.md（环境、安装目录、配置、常见问题）
  github.com/huangkiki/dailypaper-skills/blob/main/docs/usage.md
• Agent 兼容docs/agents.md（各 Agent 接入与验证范围）
  github.com/huangkiki/dailypaper-skills/blob/main/docs/agents.md
• 配套项目huangkiki/zotero-ai-sidebar（PDF 阅读时即时问答、点译）
  github.com/huangkiki/zotero-ai-sidebar

05｜作者是谁？

GitHub 账号 huangkiki，同时维护配套项目 zotero-ai-sidebar。默认研究兴趣集中在大模型强化学习、RL 基础设施、世界模型 / JEPA、灵巧手操作与物理仿真——从这份兴趣清单可以判断作者本人是相关方向的研究者或工程师。README 提到桌面环境（macOS / Windows 安装命令差异），但未披露机构与身份。本文不猜。

06｜解决了什么真实问题？

从需求侧看，痛点是「筛选成本」而非「获取成本」：

• 需求一（研究者 / 研究生）。每天新增论文远超可读量，真正费时间的是判断「哪些和我的研究有关、哪些值得读全文」。而这件事每天都要做一遍。
• 需求二（长期跟进者）。读了以后要留下什么。「读完就忘」是普遍状态，缺少从「读过」到「能复用」的链路。
• 需求三（成本敏感的个人）。用强模型每天筛论文，一个月下来账单可观；而这类判断任务其实不需要强模型。
• 共同点：不是「找不到论文」，而是「每天都得重新判断一遍，还留不下痕迹」。

07｜完整技术栈

模型分工	两级：日常主题相关性打分交给 Jev 判定模型（需在启动 Agent 的环境中设置 TYPESAFE_API_KEY）；点评与全文精读使用宿主 Agent 的模型。无 TypeSafe key 时可显式切换为关键词筛选模式。
形态	Agent Skill 包，共 7 个 skill：daily-papers、paper-reader、github-trending、generate-mocs 为对外入口；daily-papers-fetch / daily-papers-review / daily-papers-notes 负责内部的抓取、点评、笔记
支持的宿主	Claude Code · Codex · Cursor · GitHub Copilot · Gemini CLI · OpenCode · OpenClaw（python3 install.py --agent <name>）
运行环境	Python 3.10+ · Git · curl；PDF 文字与图片提取需 Poppler；Obsidian 与 Zotero 均为可选
数据来源	HuggingFace Daily / Trending 与 arXiv；另有 GitHub 周榜（日榜、月榜也可用）
输出形态	本地 Markdown：每日推荐页 · 重点论文笔记 · 概念库与目录页（三者互相链接）；可用项目自带 Web Viewer 浏览
配套	Obsidian 双向链接、Zotero 文献库按标题或分类读取
许可	Apache-2.0

08｜完整 Workflow

另一条入口：精读。「读一下这篇论文 <arXiv 链接或 PDF 路径>」或「读一下 Zotero 里的 Diffusion Policy」→ 走 paper-reader；「GitHub 周榜」→ 走 github-trending，汇总热门项目并标注与你研究方向的关系。

09｜它到底是怎么实现的？

这个项目最值得学的是三层分工：

① 便宜的模型做高频判断，贵的模型做低频生成。相关性打分是每天都发生、每次都很「轻」的任务；点评与精读是低频但需要高质量的任务。把前者交给判定模型（Jev），后者留给宿主主模型，成本结构立刻改变。作者给的数据是：同样 30 篇候选取 10 篇，强模型 $0.109 / 10.35 秒，Jev $0.00058 / 0.52 秒，约 99.47% 的费用降幅、20 倍左右的速度差，入选重合 9/10。

② 用「不凑数」保护信噪比。README 明确写「默认每天最多 10 篇，相关论文不足时不凑数」——这是做信息产品的关键纪律。每天硬凑 10 篇只会让人取消订阅。

③ 把「笔记」做成可长期积累的结构。推荐页 → 论文笔记 → 概念库三层互相链接；「下次读到相似方法时，可以顺着链接找到已有积累」。同时支持从 Zotero 已有文献库出发，接入用户既有的阅读习惯而不是另起一套。

一条值得注意的诚实之处：作者在成本对照旁明确标注——「这是 2026-10-05 的单次评分测量，计入主模型缓存；不代表整个阅读流程的费用，也不是订阅账户实际扣款。重合率不等于人工质量评价。」这句话本身就是一个很好的工程声明范式。

10｜手把手复现

Step 1（原文）。准备环境：一个能读写文件、执行命令、联网的 Agent，以及 Python 3.10+、Git、curl；PDF 文字与图片提取需要 Poppler（Obsidian 与 Zotero 都是可选）。

Step 2（原文）。安装技能包：

git clone https://github.com/huangkiki/dailypaper-skills.git
cd dailypaper-skills
python3 install.py --agent codex

把 codex 换成你用的 Agent：claude / cursor / copilot / gemini / opencode / openclaw；Windows 可将 python3 换成 py -3。安装器会一起装好七个技能与共享依赖。

Step 3（原文）。创建个人配置：python3 skills/_shared/user_config.py --init。

Step 4（原文）。让 Agent 帮你填配置（原文给出的对话示例）：

帮我配置 dailypaper-skills。
我的笔记库在 /path/to/ObsidianVault。
我关注大模型强化学习、RL infra、世界模型和 JEPA、灵巧手操作与物理仿真。
请使用跨 Agent 的共享配置，每天最多推荐 10 篇。

Step 5（原文）。设置 TYPESAFE_API_KEY 以启用 Jev 语义评分；没有该 key 时可显式选择关键词筛选模式。

Step 6（原文）。刷新或重启 Agent 会话，输入「今日论文推荐」。Agent 会依次完成筛选、点评与重点笔记，并返回产物位置。

Step 7（本文补充的建议）。第一周先把「每天最多 10 篇」降到你真正读得完的数量（例如 3–5 篇），否则会被推荐页淹没——推荐质量高不等于你有时间读。此建议为本文推导。

Step 8（本文补充的建议）。把它做成「只读不写」的检查习惯：先看推荐页的分流理由，只看你同意的那些，用一周时间验证它的判断是否合你的口味，再决定是否让它自动生成笔记。

11｜Prompt / Code / Config

原作者公开的内容（可直接引用）：

• 安装与配置命令：git clone … / python3 install.py --agent codex / python3 skills/_shared/user_config.py --init
• Agent 对话指令：「今日论文推荐」「过去一周论文推荐」「读一下这篇论文 <arXiv 链接或 PDF 路径>」「读一下 Zotero 里的 Diffusion Policy」「快速看一下这篇论文 <PDF 路径>」「GitHub 周榜」「更新索引」
• 七个 skill 的目录与职责（skills/*/SKILL.md）：daily-papers / paper-reader / github-trending / generate-mocs + 内部 fetch / review / notes
• 成本对照数据（docs/jev-benchmark.md）：GPT-6 Astra $0.109264 / 10.35 秒 / 11,932 token；Jev 1.13.0 $0.000576408 / 0.52 秒 / 14,198 token；费用降 99.47%；两组重合 9/10；相对首版 Jev token 用量减少 25.12%
• 笔记模板：obsidian-templates/论文笔记模板.md
• 环境变量：TYPESAFE_API_KEY（Jev 评分用）

原作者未公开的内容：Jev 判定模型的具体实现、每日推荐的具体提示词全文。本文不编造。

12｜踩坑

13｜中国用户能不能直接做？

• 国内访问：GitHub 直连不稳定；运行时需要访问 arXiv 与 HuggingFace，这两处对国内网络也可能不稳定，是本案例最实际的门槛。
• 注册：无账号体系；Jev 评分需额外的 API key。
• API：需要 TYPESAFE_API_KEY（可用关键词模式绕过）；宿主 Agent 的模型由你自选，可换国产模型。
• 成本：软件免费；成本 = 少量判定模型调用 + 主模型调用。这正是本案例要解决的问题（把高频判断的成本压下来）。
• 技术门槛：有一定门槛 需要 Python 环境、命令行操作，以及能读写文件与联网的 Agent。

14｜国产替代方案

原方案	Jev 判定模型（TypeSafe）做相关性评分 + 宿主 Agent 主模型做点评与精读
中国用户方案	把「两级模型」的分工结构保留，将初筛换成国产小模型 / 判定模型（或先用关键词模式），主模型换成 DeepSeek / Qwen / GLM / Kimi；论文源可增加国内可达的镜像与聚合
替代性质	架构可迁移（本文推导），具体实现需自行替换。项目对 Jev 的调用为内置依赖，作者未提供国产判定模型的适配；不能写成「已验证兼容」。

15｜中国企业可以怎么用？

• 企业场景 1｜技术情报跟踪。把「研究兴趣」换成「公司关注的技术方向」，每天自动产出行业技术动态摘要 + 重点条目精读，供研发与战略参考。
• 企业场景 2｜竞品与专利情报。同样的两级模型结构可迁移：便宜模型做初筛、强模型做深度分析，控制情报成本。
• 企业场景 3｜内部知识库自动生长。把部门里的技术资料、调研报告接入同一套「推荐页 + 笔记 + 概念库」结构，让知识库自己长起来。

16｜中国消费者可以怎么用？

• 学生 / 研究者：把它当成「每日阅读清单生成器」，先看分流理由再决定读哪几篇。
• 转行学习者：把兴趣方向设成目标岗位所需知识，让系统把你拉回正轨。
• 知识管理爱好者：参考它的「推荐页 → 笔记 → 概念库」三层结构，改造自己的知识库。

17｜如何变成一个赚钱的项目？

产品化：做垂直领域的「每日情报简报」——不限论文，可以是行业政策、竞品动态、招投标信息。核心卖点是稳定的信噪比 + 可控的成本。

服务化：给企业做「情报流水线」搭建：定义关注方向、设计初筛规则、接上内部通知渠道，交付后按月维护。

咨询化：帮团队设计「多级模型分工」，把 AI 成本降下来——这在 AI 预算开始被审视的当下是真实需求。

培训化：《用 Agent Skill 搭一条你自己的情报流水线》——研究者和分析师都会感兴趣。

内容化：「如何把 AI 使用成本降 99%」本身就是极好的选题，而且有一手数据支撑。

18｜变现路径

路径	客户 ｜ 产品/服务 ｜ 收费方式 ｜ 难度
垂直情报简报	个人/团队 ｜ 每日情报 + 精读 ｜ 订阅 ｜ 中
企业流水线	企业 ｜ 情报系统搭建与维护 ｜ 项目制 + 订阅 ｜ 中
成本优化咨询	企业 ｜ 多级模型分工设计 ｜ 项目制 ｜ 高
培训	研究者/分析师 ｜ Agent 情报流水线课 ｜ 按人 ｜ 低
内容	AI 从业者 ｜ 成本工程拆解 ｜ 付费/广告 ｜ 低

注意：以上为基于案例结构的潜在商业模式分析，非已验证的商业成功；项目未公开任何收入信息。

19｜如果我是一个中国独立开发者（7 天 MVP）

1. Day 1：装好技能包，用关键词模式先跑通「今日论文推荐」，确认链路可用。
2. Day 2：把「研究兴趣」换成你的商业场景（如「AIGC 政策与监管」），调整筛选关键词。
3. Day 3：设计输出模板：一页简报（最多 5 条 + 每条一句「为什么重要」）。
4. Day 4：找 3 位目标读者免费订阅一周，问「哪一条你会点开」。
5. Day 5：按反馈砍掉没人看的类别，只留最受关注的 2 类。
6. Day 6：把流程固化（定时运行 + 自动推送），做成一页落地页。
7. Day 7：推出低价订阅，先服务 10 个人验证付费与留存。

20｜如何迁移到其他行业

21｜培训课程设计

22｜培训师点评

23｜最终判断

说明：以上是案例属性描述，不是排名。「中国市场相关性中」指其默认场景（英文学术论文）偏海外；但「两级模型分工」的方法在中国企业的情报场景中迁移价值很高，故「商业价值高」。