我做 ReadGZH 的起因挺简单我经常把公众号文章丢给 AI它有时直接说打不开有时又会很快给我一份挺完整的总结。后来我才有点不放心。回答得像那么回事不一定代表它真的读过原文。它也可能只看到了标题或搜索摘要然后顺着往下写。我不知道是不是每个模型、每篇文章都会这样。只是从那以后我多了一个很笨的检查先问它原文第二个小标题是什么再问那个小标题下面的一个具体例子。我现在一般先发这段先不要总结。请告诉我文章标题、作者、前两个小标题 再说出第二个小标题下面的一个具体例子。 不知道就说不知道不要推测。标题有可能猜到后两项通常没那么容易蒙对。答不上来我就不继续让它总结了。如果只是偶尔读一篇我会直接复制正文。下面这些接口更适合我需要反复处理长文或者想让 Agent 自己取内容的时候。我目前用的最小请求ReadGZH 是我自己维护的工具下面也是我现在实际使用的接口不是通用标准。curl-i-Ghttps://api.readgzh.site/rd\-HAuthorization: Bearer YOUR_READGZH_API_KEY\--data-urlencodeurlhttps://mp.weixin.qq.com/s/替换为真实文章ID\--dataformattext我会保留 -i因为有几项响应头排错时挺有用X-Cache有没有命中缓存X-Credit-Cost这次消耗了多少X-Credits-Remaining还剩多少额度X-Total-Parts长文章有没有被分块。我之前在云函数里碰到 429第一反应是解析坏了后来才发现 ChatGPT 工具、Vercel、Cloudflare Workers 一类环境经常共用出口 IP。匿名额度有时会被同一出口的其他请求先用掉。Python 里我只多做了几个检查importosimportrequests api_keyos.getenv(READGZH_API_KEY)headers{}ifapi_key:headers[Authorization]fBearer{api_key}responserequests.get(https://api.readgzh.site/rd,params{url:https://mp.weixin.qq.com/s/替换为真实文章ID,format:text,},headersheaders,timeout(10,60),)response.raise_for_status()article_textresponse.text.strip()iflen(article_text)100:raiseRuntimeError(返回内容太短先别交给模型)print(article_text[:1000])这里没有什么复杂技巧。我只是让 requests 负责编码 URL设置连接和读取超时再检查一下返回内容是不是短得不正常。API 返回 200也不等于模型后面一定用了这些正文所以我还是会再问一次小标题。需要自动调用时我才接 MCP我现在用的远程 MCP 配置是{mcpServers:{readgzh:{url:https://api.readgzh.site/mcp-server,headers:{Authorization:Bearer YOUR_READGZH_API_KEY}}}}不同客户端的配置文件位置不一样这里没法一概而论。配置完成以后我仍然不会第一句话就让它总结而是先让它把标题、小标题和一个细节复述出来。我目前碰到比较多的情况大概是现象我通常先检查什么400URL 有没有传错401Authorization 请求头和 Key404原文是否还公开可见429是否用了共享出口、并发是否太高200 但内容很短返回的可能不是有效正文AI 回答跑偏它是否真的调用了工具、使用了正文这套办法肯定不完美。已经删除、需要登录、只有视频或小程序的文章依然可能处理不了。能读取公开文章也不代表可以随便转载。完整参数放在这里免得这篇文章以后过期https://readgzh.site/docs?utm_sourcecsdnutm_mediumarticleutm_campaignreadgzh_cn_growth_202608utm_contentpersonal_notes这只是我现在的处理方式。对我最有用的反而不是哪段代码而是那个很土的问题第二个小标题是什么