从阅读到知识（一）：个人阅读档案的设计与实现
微信读书没有官方 API 的那几年，我用抓包拼出了一套数据管道，定期爬书架和阅读记录。2026 年 5 月官方开放 Agent Skill，迁移只花了一个下午。但技术问题好解决，更难的是设计判断——那些满屏图表的阅读看板，对自己和访客真的有用吗？
目录
阅读
微信读书没有官方 API 的那几年，我用抓包拼出了一套数据管道，定期爬书架和阅读记录。2026 年 5 月官方开放 Agent Skill，迁移只花了一个下午。但技术问题好解决，更难的是设计判断——那些满屏图表的阅读看板，对自己和访客真的有用吗？
这是「从阅读到知识」系列的第一篇，讲的是数据层：如何拿到微信读书的数据，以及如何判断展示什么。
第一个问题的答案从抓包演变为官方 Skill，中间发生了一件值得记录的事——平台从封闭走向开放。第二个问题更难，因为它不是技术问题，而是设计判断：一个满屏图表的阅读看板，对读者（和自己）究竟有多大价值？
微信读书在很长一段时间里没有对外开放任何接口。想拿到自己的书架、阅读时长、划线记录，唯一的办法是抓包。
iOS 端的请求没有签名校验，鉴权靠两个字段：vid（用户 ID）和 skey（会话密钥）。把它们塞进请求头，就能直接访问 i.weread.qq.com 的内部接口：
HEADERS = {
"Host": "i.weread.qq.com",
"vid": "xxxxxxxxxxx",
"skey": SKEY,
"user-agent": "WeRead/9.4.0 (iPhone; iOS 26.1; Scale/3.00)",
"v": "9.4.0.63",
}
def get_shelf():
url = "https://i.weread.qq.com/shelf/sync"
params = {"userVid": "xxxxxxxxxxx", "synckey": "0"}
response = requests.get(url, params=params, headers=HEADERS)
return response.json()接口路径基本能猜到：/shelf/sync 是书架，/readdata/detail 是阅读时长，/user/notebooks 是笔记本。数据结构也比较稳定。
这套方案能用，但很脆弱：
用了一段时间，够用，但一直有点不踏实。
2026 年 5 月，微信读书开放了官方的 Agent Skill：WeChatReading Skill 。
WeChatReading Skill 是微信读书为 AI Agent 设计的标准化接入方式。和 MCP（Model Context Protocol）的思路类似，它把平台的数据能力打包成一份可描述的接口规范，让 AI 助手能够直接调用——搜索书籍、查看书架、读取划线、获取阅读统计，都在其中。
开放的能力包括：
| 能力 | 说明 |
|---|---|
| 书架管理 | /shelf/sync，含电子书、有声书/专辑、文章收藏 |
| 书籍信息 | /book/info、/book/getprogress，书籍详情与阅读进度 |
| 阅读统计 | /readdata/detail，支持 weekly / monthly / annually / overall 四种维度 |
| 笔记划线 | /user/notebooks、/book/bookmarklist，个人笔记与划线内容 |
| 书籍点评 | 公开点评查询 |
| 发现推荐 | 个性化推荐、相似推荐 |
| 搜索 | /store/search，在书城搜索书籍 |
鉴权方式变为 API Key（格式 wrk-xxxxxxxx），所有请求通过统一入口代理：
export async function POST(req: NextRequest) {
const apiKey = process.env.WEREAD_API_KEY;
const body = await req.json();
const res = await fetch("https://i.weread.qq.com/api/agent/gateway", {
method: "POST",
headers: {
"Authorization": `Bearer ${apiKey}`
请求体里用 api_name 指定接口，其余业务参数平铺在同一层：
// 书架
{ api_name: "/shelf/sync", skill_version: "1.0.4" }
// 阅读统计（按年）
{ api_name: "/readdata/detail", mode: "annually", baseTime: 1704067200, skill_version: "1.0.4" }
// 某本书的划线
{ api_name: "/book/bookmarklist", bookId: "xxx", count: 3skill_version 是版本上报字段，服务端用它检查客户端是否需要升级——如果回包出现 upgrade_info，说明 Skill 有新版本，需要更新后再继续请求。
原来的抓包方案是分散的 GET 请求，每个接口有自己的 URL 和请求头。迁移后，所有请求收拢成一个 POST，接口路径几乎没变，数据结构也基本保持一致。改动主要集中在鉴权方式：从手动维护 skey 换成环境变量里的 API Key。迁移花了一个下午。
这个方向的下一步可能是更完整的 MCP 支持、更细粒度的权限控制，以及目前还未开放的数据——比如社交数据、书评互动、跨用户的阅读行为。
有了稳定的数据来源，下一个问题是：展示什么？ 我看了一些现有的微信读书看板产品。大部分都很酷炫：年度阅读热力图、分类雷达图、书籍完成率、阅读时段分布……数据非常全面，图表非常漂亮。但我在想两个问题：
对自己：我每次打开这个页面，真正想知道的是什么？是我上个月读了多少小时，还是我现在在读什么、读到了哪里？统计数据有价值，但它是回顾性的，而不是日常需要的。
对访客：我的阅读记录，对访客有什么用？他们需要知道我的阅读时段分布吗？或者，他们只是想知道我在读什么书，偶尔发现一本他们也感兴趣的？
这两个问题导向了一个相反于「展示一切」的设计方向：降低信息密度，让书本身说话。
具体的选择：
hover 封面会出现一个放大镜按钮，点开才是详细信息（作者、分类、划线摘录）。信息藏在交互里，而不是直接铺在页面上。
统计部分有四个图表：年度阅读趋势、月度时长分布、阅读时段、偏好分类。没有引入任何图表库。
理由很简单：Next.js 的 bundle size 敏感，Recharts 压缩后也有 ~200KB；而这几个图表的需求很确定，不需要库的通用性。
核心是一个坐标映射函数：
const py = (v: number, max: number, h: number, pad: Pad) =>
pad.top + (h - pad.top - pad.bottom) * (1 - v / max);把数据值映射到 SVG 像素坐标。所有图表共用这一个函数，差别只是 max 和 pad 的取值。
年度趋势图有双 Y 轴——左轴是小时数（柱状），右轴是本数（折线）。两套独立的 py 函数，共用同一个 SVG 画布：
const pyHours = (v: number) => py(v, hoursMax, CHART_H, PAD);
const pyBooks = (v: number) => py(v, booksMax, CHART_H, { ...PAD, left: 0 });月度分布图支持年份切换，数据懒加载并缓存在组件 state 里：
const [cache, setCache] = useState<Record<number, number[] | "loading">>({});
useEffect(() => {
if (cache[selYear]) return;
setCache(prev => ({ ...prev, [selYear]: "loading" }));
fetchMonthHours(selYear).then(data =>
setCache
"loading" 作为哨兵值，避免重复请求。
封面 hover 的详情模态框用了 createPortal，挂载到 document.body。原因是书架容器有 overflow: hidden，如果模态框渲染在容器内部会被裁剪。
return createPortal(
<div style={{ position: "fixed", inset: 0, zIndex: 200 }}>
{/* 遮罩 + 内容 */}
</div>,
document.body
);划线数据在模态框打开时才发起请求，结果缓存在组件自身的 state 里：
useEffect(() => {
if (!open || highlights !== null) return;
fetchHighlights(bookId).then(setHighlights);
}, [open, bookId]);highlights !== null 保证每本书只请求一次，关闭再打开不会重复拉取。整个懒加载的时序如下：
「阅读」这个页面现在能回答：
但它还不能回答：
这些问题，是数据层解决不了的。把划线从数据库里捞出来展示，和让这些划线真正进入思考过程，是两件事。
下一篇会从这里继续：从展示到使用——让划线不只是存档，而是能被用上。