我的笔记

主题

马奇诺 马奇诺 2026年7月4日 16:49

写在前面

本文尝试从一个数据产品的视角，复盘从 0 到 1 做成一个正常运营、日均 500+ 次数据请求产品的反思与收获。为了便于理解这个复盘视角，先补充下个人背景：我是数据产品，懂数据，理解一些技术，了解一些产品。基于此，这个产品从 day 0 开始的设计和开发都有强数据架构，但产品和技术上走了很多弯路，也收获很大。
其次，Distilled 是一个实验性质的产品，本质是把我想做的、想学习的技术概念、想实现的产品想法打包放在一起，通过实现来提升个人能力，而不是一个面向用户的创业项目。
本文从真需求的挖掘和验证，到大模型评测的引入和质量运营，再到数据管线与文生文功能的改造，详细讲其中的反思和收获。内容比较长，算是给这个项目做个 archive。AI 把实现变成了成本最低的环节，难的部分换成了定义：定义需求、定义"好"、定义系统怎样才算还在正常工作。

01 需求是真的，需求满足方式是多样的 ​

需求源于我对 AI 进展、AI 资讯的焦虑，自然而然的解法就是抓取信息源，自己筛选，再有选择地看。按照梁宁老师的产品理念，这是真需求，但实现下来，产品上的顾虑点很多。
最开始我没有想做个产品。纯数据视角，无非就是数据爬取、过滤、筛选，然后看。看是通过 Obsidian 的 Markdown 文件去看，这个方式确实解决了我那时那刻的需求，但问题也随之出现：我发现自己看不过来。文章做了筛选排序，但量还是很大，主题很广，我作为碳基生物，吸收很慢。因此后来让 AI 去学习，这个思路的转变是顺其自然的，也是启发式的。AI 作为硅基生物学到了，但我作为碳基生物，还是要高质量精读一些。
这时候"抓住主线"的观点发挥了指挥棒的作用。我一直坚持的观点是，在 AI 领域跟踪 Claude、Codex 以及重要 KOL 的发展和观点即可，国内大部分 KOL 做的是信息转发的事。另外大模型领域发展很快，要判断什么是中间产物，什么是真值得关注的。这些指挥棒下，我考虑对内容做实体改造，把所有内容都挂载到实体上，实体与子实体、引文、摘要这些概念就顺其自然产生了，这也是需求、体验、需求、迭代的过程。所以产品其实有三版改造：第一版是纯 Markdown 形式，第二版是实体形式，第三版是现在这种有更多摘要蒸馏内容的形式。
图片

02 内容引入与标准设计 ​

内容引入包含两部分：一是我的自建库，自己抓取并搭建内容管道，这部分占了 90%；二是外部 API，例如 Zara Zhang、卡兹克都提供了 AI 资讯 API，前者偏向海外 X 平台的 AI KOL，后者是内容视角的 AI 资讯，这些都接入到了我的内容库。

1/ 两次失败的筛选

第一版筛选是关键词：让模型看标题和正文里有没有 Claude Code、codex、agent 这些词，有就收。跑起来发现可读性很差，很多文章只是提到了这些词，讲的完全是别的事。第二版改成信源分级，自己观察哪些源值得看、哪些不值得，按源定级。用了一阵又发现不稳：同一个创作者的内容质量参差，有可圈可点的干货，也有 PR 稿，按源一刀切会两头误伤。两次失败下来的判断：筛选既要看创作者，也要看内容本身，创作者用长期表现衡量，内容要一篇一篇地评。

2/ 信源：选择与按月复盘

221 个信源（167 个中文公众号加 54 个海外源）不是静态名单。系统侧，每个信源有质量指数和命中率（达到精读级以上的文章占比），打分维度反过来给信源画像：可行动性分高的自动标成实操派，分析深度高的标深度派，信息增量高的标前沿派；长期不活跃的按天衰减，自动清出画像，订阅名单有 221 个、下图信源页显示 216 个有画像，差的那几个就是被清出去的。人工侧，我每月做一次信源复盘，谁当月表现好、谁停更了、谁持续稳定，稳定的置顶；月度生态报告里会把信源放进四层生态位的气泡图（深度、可行动性、产出量三个维度），谁在产干货、谁在发媒体稿，一眼能看到。
图片

3/ "忽略啥"：负向标准

首页有个"忽略啥"板块，把不值得看的也列出来。动机有两个：一是省时间，明确不看什么和知道看什么一样重要；二是它是评测体系的反馈入口，一篇文章为什么被判不值得看，反过来能校验打分标准。忽略的判定有四条规则：被判"过誉"（声量大但可信度不足）、总分低于 40、50 分以下且信息增量为零、命中噪音模式词。还有一个设计：每篇被忽略的文章都带一个"回头再看的条件"，比如"当可信信源覆盖同一话题时"，忽略不是一刀切，是带条件的暂缓。

03 大模型评测 ​

大模型评测是现在做 AI 产品最重要的事情之一，在这个产品里我已经引入了这个方案：对内容做评测体系，设计好评测维度，从而能精准地给每篇文章做一个客观打分。

1/ 七个维度的 rubric

按内容逐篇评，落地方式就是把工作里接触的大模型评测搬过来：对每篇文章做逐篇评测，从多个角度打分、设计权重。现在的 7 个维度，每个维度问一个具体问题：
图片

每个维度 0-3 分，加权到满分 100，再分四档：85 以上收藏，70 以上精读，55 以上速览，55 以下噪音。must_read 另有附加条件：总分要到 88，而且信息增量、分析深度、可行动性三个核心维度里至少两个拿到 2 分以上，防止靠时效性和表达堆出来的"高分水文"。另外有三个一票否决项：涉安全内容、无分析的纯搬运、标题与内容严重不符；PR 软文只打标记不否决，让它带着标签参与排序。
rubric 第一版没设计好，打出来的分不稳定。重写时把 prompt engineering 的基本功补齐：每个维度讲清楚是什么、为什么、怎么打，配正反样例，把每一档写成具体的锚点描述，比如综合信号的 3 分是"我会主动转发给同行，这种质量一周最多遇到几篇"。模型按锚点打分，比按公式算分稳定得多。锚点和打分的 system prompt 长什么样，直接看原文：
图片

权重也调了一版。第一版学术性权重偏高，用了一阵发现自己对学术内容没那么大兴趣，更在意能不能动手、有没有启发，第二版把可行动性这类维度的权重提了上去。评分体系不是设计完就结束的，权重要跟着真实使用校准。

2/ 一次静默的质量退化

3 月底有一个改动，评分模型从 Gemini 换成 DeepSeek 便宜档，动机是省钱。换完之后定时任务每天两次准点跑，网站每天更新，日志全绿。6 月中旬我发现值得看的内容越来越少，第一反应是排查：信源出了问题，还是打分出了问题？查下来是后者，评测任务有一段时间没正常跑，大量文章用的是兜底的默认分。
拉数据确认影响面：must_read 级文章的占比，3 月是 8.2%，4 月降到 4.6%，5 月只剩 2.2%；分数分布里有 433 篇恰好是 33 分，这是走了默认分路径的特征值（7 个维度全给 1 分，总分刚好 33）；机器之心、新智元这些长期稳定的信源，月均分普遍下降了 15 到 26 分。稳定信源集体降分，基本可以排除内容真变差，是打分器的问题。
根因是：便宜档跑批量结构化输出不稳，一批 10 篇送进去，约四分之一的概率返回不完整的 JSON，而兜底逻辑是整批回退默认分。4、5 两个月有 18.6% 的文章拿的是默认分，这个状态持续了两个半月。
图片

3/ 修复：先选型，再重跑

修复前先做了一次选型：拿同一批 20 篇文章，让三个模型同台打分。便宜档默认率 25%；Gemini 3 Pro 判断最准，最难判的一篇给到 87 分，但批量输出有一半概率格式失败；DeepSeek pro 零失败、标尺正常。最后选了 pro。判断力最强的模型没被选上，因为在批量场景下，工程稳定性也是模型能力的一部分。
工程上同时改了三处：批次从 10 篇降到 5 篇；加单篇补救层，批量失败的文章单独取出逐篇重打；再把 4 月以来的 8450 篇全量重跑。重打那晚 API 余额直接用完，单日消费 80 块上下，前后合计一百五十块上下。日常评测每天大概只花 3 块钱，DeepSeek 单价便宜，但全量回跑并不便宜，重跑一两天的数据成本可控，重跑几个月就不可控了，所以评测任务的健康必须每天确认。
修复后默认分率从批次级的 25% 降到 0.02%，每天的评分质量写进一份滚动的质量日志，五个字段：当日评分数、默认分数、默认率、must_read 率、均分。
系统"在跑"和系统"是对的"，是两回事，前者看进程，后者要在数据层面校验。
三轮换下来：便宜档不稳定，pro 档在内容理解、prompt 遵循程度和提取质量上都更高，差距在批量结构化输出的场景被急剧放大。现在的用法是分档：批量任务直接用 pro；今日导读这类单次生成先试便宜档、失败升级到贵档；API 余额不足时快速失败，不做无谓重试。
图片

4/ 事后补的监控

这次问题是人看出来的，不是监控报的。事后把缺的监控补齐：发布前有强制校验，输出文件不完整就阻断上线；发布后有 6 条数据质量规则，比如默认分率超 15%、当日均分比 7 日基线低 12 分以上、must_read 率跌破基线的 75%、今日导读为空，命中就发飞书提醒；另有一层独立检查，确认线上数据确实是当天的。下一步想做"问题枚举加自动修复"：把模型、数据、产出各环节的常见故障列出来，各配一个修复方案，让系统自己处理一部分。

04 数据架构设计 ​

1/ 分层与冷热分离

这个产品本质是一个数据问题，从采集、清洗、加工到应用，每一层要做的事不一样，所以从第一天起就按数仓思路分层：ODS、DWD、DWS、DM（简单理解就是从原始数据，到清洗、汇总、再到应用，一层层加工），层内有数据协议，层间解耦。重跑那次直接受益：上游的采集和清洗是冷数据，不用动，只重跑了打分层，前端一行没碰。如果连抓取和清洗都要跟着重跑，成本和风险完全是另一个量级。
评测层的产出不只是分数。一次调用同时产出打分字段和提取字段（标题、摘要、核心观点），一篇文章全链路累计五六十个字段，对外输出收敛成十几个核心字段加 7 个维度分，除了分数还有"为什么重要""最弱的维度"，网站、终端 Skill、API、月报全部消费同一份数据。

2/ 去重做了三层

第一层指纹去重，信源加归一化标题加日期算 MD5，72 小时窗口内见过的直接丢；第二层同信源精确去重，处理只改了链接的重发；第三层同信源模糊去重，标题相似度 95 以上判定为转载。第三层里有个细节：标题里数字不同的强制保留，防止把"v0.2 发布"和"v0.3 发布"当成同一篇合并掉。跨信源的转载有意不去重：同一件事，不同信源的解读角度不一样，多个视角值得都留下；而且很多信源同时讲一件事，本身说明热度高。

3/ 数据的灵活性

除了自建库的数据，数据架构也给第三方数据留了接入通道，能快速展示优秀的数据 API 内容，前面提到的 Zara Zhang、卡兹克两个外部 API 走的就是这条通道，接入后直接在产品里常驻。
数据通道是双向的：自建库的数据也开放了 API，我自己采集、评测、加工的文章、评分、实体、导读这些结构化数据，都能按接口取用（第三方接入的数据不在其中），申请入口在 distilled.makinote.cn/api-access.html。

05 系统架构设计 ​

1/ 高内聚低耦合：一条管道，四个消费端

架构上的总原则是高内聚低耦合，各模块封装好，模块之间靠数据协议衔接。一条 Python 数据管道跑在 VPS 上，每天两次定时执行，从采集到评测到聚合，最终产出一组静态 JSON 数据文件发布到 CDN。下游四个消费端全部只读这份数据：网站、终端 Skill（在 Claude Code 里一条命令读日报）、给知识星球成员的 token 制 API，还有一份 llms.txt（专门写给 AI 看的站点说明书）。加一个消费端不用动引擎，改引擎不用动消费端。
图片

2/ 计算和内容吐出都在后端，不放前端

前后端一条原则：所有排序、聚合、摘要生成都在后端算好，前端只做渲染，不做计算。前端到今天还是一个单文件 HTML，算是技术债，但它没影响迭代速度，改版照样一天上线，所以一直没还。性能优化也是数据侧优先：首屏加载的数据从 1.14MB 压缩到 230KB，核心数据文件从 917KB 压缩到 352KB，终端 Skill 从解析 870KB 的 JSON（要 30 秒）改成读预渲染的 40KB Markdown（2 秒）。

3/ 安全：别让数据在前端裸奔

最近研究了不少个人开发者的产品，很多没做过安全审计，用户的数据在前端裸奔。我给自己定了三条底线。一是接口要有健全的鉴权设计，Distilled 对外的 API 用 token 制，没有 token 拿不到数据；二是密钥只放后端，所有大模型调用都在服务器上的管道里跑，前端不碰模型，密钥自然不会露出来，做 AI 对话功能的产品尤其要注意这一点；三是数据接口要防未登录抓取，公开的就明确公开，需要授权的必须在服务端校验，不能靠前端把入口藏起来假装安全。

4/ 能复用的不自己写

一定要多找现成的精品组件。这个项目里，微信公众号的抓取用的是现成的 wechat2rss，网站托管直接交给 Vercel，访问统计用开源的 Umami，这三块我一行代码都没写。自己写的部分收敛在真正差异化的地方：评测体系、数据分层、实体聚合。
这条可以直接固化成 system prompt：在 CLAUDE.md、AGENTS.md 这类全局规则文件里加一条，凡是新架构或新技术方案，先去 GitHub 和网上找竞品、找能复用的组件，找不到再自己写。AI 默认爱从零造轮子，靠每次口头提醒没用，写进规则文件才管得住。

06 产品设计 ​

1/ 实体与子实体：只跟踪主线

实体改造落到设计上：所有内容按实体拆分，Claude Code、GPT、MCP 都是实体，实体之间有关系，实体下面挂子实体，比如 Claude Code 下面有 Skills 这类子话题，实体和子实体各有摘要，想看某条主线，进对应实体就能把相关内容分门别类看完。策展用白名单制：92 个追踪实体里只有 36 个在名单里，且近 30 天至少有 3 篇非忽略级文章才生成 AI 叙事，内容不够只做归档。

2/ 文生文：基于引文生成多方向摘要

第三版改造的核心是文生文：基于引文和 prompt engineering 构造，生成不同方向的内容摘要，今日导读、实体叙事、主题摘要，让我不点开原文也能拿到内容核心，且每条结论都带引文编号，能追溯到原文。
早期对生成结果的校验是硬性的：引文数量超出上限，整篇作废。当时的想法是防 LLM 胡编乱造，引用错了不如不要。实际跑起来发现误杀比造假更常发生，prompt 一改、引文数量一变，整篇导读就没了。后来改成抢救式：先逐段清洗，去掉"重磅""震撼""必看"这类词，丢掉没有引文支撑的段落（这一步本身就在防胡编），再按上限截断段数和字数，只有剩余内容低于底线（不足 2 段或引文少于 3 条）才判定失败。LLM 的输出是概率性的，校验要给它留降级的余地，不能只有过和不过两档。

3/ 两个需求方：我和我的 AI

产品设计上想得最清楚的一件事：这个产品的需求方有两个。第一个是我自己，解决我的 AI 信息焦虑，需求是真的，用户是我自己，好不好用每天都能验证。第二个是我的 AI：我要让自己的 AI 持续学习新技术，那底层架构就得 AI 友好，数据全部结构化、字段有明确定义、提供机器可读的接口。做需求设计时要同时考虑两个用户：我看的是页面，AI 读的是数据。
两个需求方也打过架。AI 要字段全，数据文件越攒越大；我要页面秒开，一份文件满足不了两头。最后的解法是分端出数据：页面吃裁剪过的精简切片，AI 和 API 吃全量结构化文件，终端 Skill 另吃一份预渲染的 Markdown，同一份底层数据，三种消费形态，谁也不迁就谁。

07 开发范式 ​

1/ 从多窗口到 PM 模式

开发模式五个月迭代了一轮。之前是开多个窗口、多个 session 并行、自己逐个检查，人当调度器；现在收敛成 PM 模式，我只管把需求讲清楚和验收，中间交给 AI 组织，这个之前单独写过一篇，不展开。贯穿始终的课题是三角平衡：怎么在 vibe coding 里同时拿到高效、质量和轻松，三者互相牵制，只能不断调整分工找平衡点。

2/ 跟模型协作的两个习惯

一是眼见为实。有一天做样式改版，想起"高保真图"这个工作里听过的词，让 AI 出了几版，才真正明白它在产品设计里的作用。之前不做设计稿直接让 AI 写页面，出来的效果很奇怪。现在改成三步：先研究竞品、把自己的需求想清楚；再找有没有开源组件可以复用；最后让 AI 出几版不同交互的高保真图，对比后再实现。这套也未必最好，还在摸索。
二是同频。大模型本质是语言概率模型，context 没给够就要结果，出来的东西多半不是想要的，很多不满意的产出不是模型不行，是我没把话说到位。

3/ 弯路的根因：没有对应领域的 context

这些弯路有一个共同根因：我只有数据背景，没有技术和产品背景，在对应领域就没有对应的 context。大模型本质是预测类模型，给它什么样的问题，它就给对应的答案；当我的问题和相关专业不沾边时，它自然输出不了更专业的结果，只会顺着我说。同一个我、同一个模型：数据领域我有判断，数据架构从第一天就是对的；设计领域我没有，产出基本是 AI 给什么是什么，说不上是"我的"设计，主导权到今天没拿回来。差距不在模型，在我两边的 context 厚度完全不同。
最近听到一个分享，观点我很认同：大模型时代，人反而更要学习。不学习，在对应领域就不知道怎么判断，不知道怎么给 context 驱动模型给出更好的方案。这也是真正解决弯路的办法：专业背景到位，模型的能力才能被挖掘出来；不到位，就永远停在做成一个 demo 的层面。

08 收获：数据飞轮 ​

五个半月沉淀了 11270 篇带评分、带实体标注的文章，我写文章前跑一遍它，模型就有了最近的行业上下文；月报直接从它出数；数据越多，AI 越了解我关注什么，筛出来的东西越准，我就越愿意继续补充新数据。做之前我以为这是个信息工具，做到现在发现它是一份不断增值的数据资产，连这篇复盘里的数字都来自它自己的积累。
流量也拆开说。Umami 后台近 30 天：2400+ 次页面浏览，400+ 独立访客，其中 59 个是回访，还包括我自己每天的使用。不是大流量产品，它本来也不是做给流量的。

写在后面 ​

一个偶尔写代码的数据产品，从 0 到 1 做出一个每天稳定运行的产品，放在两年前我自己都不信。这条路有个前提：实现已经是成本最低的环节，所以这不是"努力就能做产品"的鸡汤，是窗口期真实存在。
这个产品从头到尾是一个实验场：把工作里听到的名词、方法论、技术概念拿过来实操一遍再串起来，大模型评测、数仓分层、本体论、prompt engineering，全在这一个项目里跑通了，等于把工作上的未尽事项在自己感兴趣的事情上做完了一遍，非常有意思。
做完这个项目，我还有一个感受：职业的边界开始模糊。数据、产品、技术、设计，这些原来各归各的岗位，现在只要想做，就有方法去做，有方法去学。怎么学？最好的方式就是把自己的想法和需求，通过产品化的形式从零到一做一遍，一路上要什么学什么，学到的都是带着场景的。
以上是关于 Distilled 从 0 到 1 的一家之言。就酱~

Distilled 网站：https://distilled.makinote.cn
Distilled 数据 API：https://distilled.makinote.cn/api-access.html
Distilled Skill（开源）：https://github.com/makinotes/makino-distilled

猜你想看 ：

如果对你有帮助，欢迎点赞、在看、转发~

AI · 目录

作者提示: 个人观点，仅供参考