376MB会话记录，炼成一页手册

特别企划 · 一次完整的「经验 → 知识库」工程：6 个 AI 考古代理、13 个会话、376MB 记录，炼成一份 AI 可执行的公众号操作手册 《智能编码进化论》系列 · 发布文体 · 2026-10

9 月 30 日晚上十点，公众号后台弹出一条通知：两篇文章被平台判定「不良信息——导流内容」。

被判的是《mac mini ComfyUI 实战》的 01 篇和 02 篇。判定理由不冤：文末有个「官网展示区」组件，展示官网网址，配一句「复制网址到浏览器打开」。这个组件当初的立项理由，恰恰是「规避微信正文外链不可点」——只放文字、不放链接，我们以为那是安全区。

平台不这么看。规则写得明白：文字形式的导流，也算导流。

03 篇没被判，但文末挂着同一套组件，一并净化重发；00 篇只做净化留档。下文说「三篇重发」，指的就是这次连带净化；被判的是两篇。

从当晚到次日凌晨的处置不算复杂：下架、净化、重发，分两轮走完——第一轮下架整改留档，第二轮全面净化后重发。真正让人后怕的是事后复盘时的一个发现——整套处置流程里最关键的经验，一条都不在我们的规则文件里。它们散落在过去三周的会话记录深处，只有亲身踩过坑的那个 AI 会话「记得」。

而 AI 会话，是没有记性的。

一、每个新会话，都是失忆的新员工

先交代背景。羲和Lab的公众号，大部分流程是 AI 在跑：写稿、排版、配图、合规审查、上传草稿，一条流水线。人类负责一件事——按下后台的「群发」或「发布」按钮。

这套流水线跑了两三个月，顺手，但有个隐患一直没处理：经验没有落地的住所。

项目里有规则文件（rules），写的是红线和规范——「不许导流」「封面必须加水印」。但「怎么把一篇 6 万字符的排版文塞进只收 2 万字符的接口」「改个标题为什么要重建整个草稿」「上传图片报 40164 该走哪条备用通道」这类操作性知识，全部沉淀在一次次会话的对话记录里。

于是每个新会话都是失忆的新员工。老会话踩过的坑，它原样再踩一遍。9 月 27 日有一批图片因为相对路径写法不对，建稿时被静默跳过，十一张图全丢；9 月 30 日违规处置时摸索出的「重发走『发布』按钮、不占群发额度」——这些都是用真实事故换来的，但没有任何一个新会话天然知道。

规则文件里甚至留着一条已经过时的口径：「按每天 1 次额度重发」。而实操早就演进了。知识库落后于一线，且没人知道落后了多少。

二、派六个考古代理，去挖 376MB

决定做一次彻底的整理：把所有会话历史翻出来，从中提炼公众号操作知识，做成一份 skill——Claude Code 的按需加载技能包，主线 04 篇《给 AI 配工具箱》讲过它：平时不占上下文，用到时整册调入。

先盘点家底：13 个会话文件，共 376MB，时间跨度 9 月 13 日到 10 月 1 日。说明口径：这是原始会话日志的总量，含工具输出、报错回显和图片数据，不是纯对话文本。最大的单个文件 100MB。

这个体量没法自己读，派了 6 个并行代理分段挖掘，按时间分片：9 月 13 日的 MCP 搭建期、9 月 24 日、9 月 26—27 日、9 月 28—29 日、9 月 30 日违规现场、10 月 1 日净化重发。每个代理负责还原自己那段里的工具调用序列、报错与修复、以及用户在当时的拍板原话。376MB 的日志没有一份报告能一次装下，好几份考古报告打到一半被截断，还得追在后面要补发——这活儿本身就是个耐心活。

考古出来的东西，比预想的丰富。

9 月 13 日那天是凭据灾难日：先撞 IP 白名单（40164），加白之后又撞 AppSecret 失效（40125）。最迷惑的是中间那段「假阳性」——早上明明测通了，下午全挂。最后查明是三层叠加：平台曾重置过密钥、MCP 服务的本地缓存里还存着旧值、旧 token 又没过期。而新密钥的真实位置在 ~/.zshenv，不是 .zshrc，第一轮排查扑了个空。这些后来都固化成了规范，但规范里没写「为什么」。

更值钱的是流程演化史。9 月中旬建草稿用的是「骨架 + 剪贴板」笨办法：接口建个占位草稿，全文复制进剪贴板，人再到后台全选粘贴。后来 MCP 服务器升级出「长文直写」通道，一步到位。新旧两代流程都躺在会话记录里，不挖一遍，根本不知道哪些是该扔的历史包袱。

还有两起「报告打架」。

第一起：一份考古报告说，draft_update 可以就地修改草稿标题；另一份说，对这类草稿它必然报 40007，两种改法都实测失败。两边都有「实录」背书。裁决办法是调原始调用记录对质——结果是两次调用全部失败，写「可以用」的那份报告收回结论，出报告的代理承认：只核对了调用清单，没核对返回值。

AI 整理 AI 的历史，也会转述失实。原始记录是最后的裁判。

第二起：一个会话里本地图片被自动上传图床，一切顺利；另一个会话里十一张图全部被跳过，成了废稿。矛盾持续到比对参数才发现：前者图片路径相对 HTML 文件可解析，后者写的是相对仓库根目录——服务器按 HTML 文件所在目录去找，找不到，就静默放弃。同一个功能，一个路径基准的差别，天壤之别。

三、炼成手册

六份考古报告汇齐，提炼成一份 skill，13 节，三百来行。标题里说「一页手册」是修辞，严格说是三百行——但比起 376MB，这就是一页的重量。

手册以 MCP 工具为主线，核心是这么几块：

**三层 25 工具速查。**官方 API 层（素材、草稿、发布能力——其中发布类接口订阅号无权限，仅作能力边界记录；吃 access_token 和 IP 白名单）、本地检查层（HTML 静态检查）、Web 会话层（浏览器登录态，长文直写、传图、数据统计，免白名单）。哪层干什么活、吃哪种鉴权，一张表说清。

**发布七步 SOP。**前置审查闸门之外七步：静态检查 → 检查登录态 → 图片上图床 → 建稿 → 交付人工清单 → 人工确认发表（群发/发布）→ 归档，每步写明工具名、参数、判据。人工清单是固定的——封面要人在编辑器里从素材库手选，因为直写通道设不了封面，「建稿自动、选封面手动两步」被写成了制度；标签、原创声明、移动端预览，一项不落。手册里甚至记着一句用户的强调原话：「再强调一遍，系列合集封面的规格是 3:4」——此前三个系列在同一个尺寸口径上连续出错，这句话就是那么来的。

**双通道能力边界。**这是踩坑密度最高的一节：官方草稿接口的 content 字段限两万字符，排版文动辄五六万，必须走 Web 通道；Web 通道建的草稿「读得到、删得掉、改不了」，改一个标题也得重建新稿删旧稿；发布能力接口（freepublish 系列）压根没对订阅号开放，连发布记录都查不了。每一条都是实测换来的。

**报错字典。**十四条，从 40164（IP 白名单，换网络就复发）到 40007（别修了，重建吧）再到「curl 拉图返回 243 字节不是死图，是防盗链占位图，别虚惊」。

手册里贯穿一条红线：**「群发」和「发布」两个按钮，永远由人点。**群发每天一次、推给粉丝；发布不占额度、不推粉丝。官方的发布 API，我们这类个人主体订阅号没有调用权限，AI 想自动发也发不了——这条红线有一半是平台帮着守的。

四、让它们互相挑刺

初稿写完，安排了三个「分身」并行质检——这套角色分工是项目里现成的：墨子管技术，金乌管发布实操，皋陶管合规。问题按红、黄、绿三级分类：红是必改，黄是建议改，绿是可选。

墨子对照 MCP 服务器源码逐条核验，抓出一串细节错误：检查工具的报错级别写错了两处，服务器注册名的归属张冠李戴，「统计可回查 7 天」把单次查询跨度误写成了数据保留期。全是措辞级，但操作手册里措辞就是精度。

金乌是这份手册未来的实际使用者，一眼看出缺了个东西：流程第一步应该是「皋陶审查通过、待发布文件就绪」的前置闸门——否则手册没写「不审查就不能发」这个落点。它还顺手发现了一个真正的事故隐患：官网文章索引停在 9 月 28 日没同步，重发之后官网挂的还是三篇失效旧链接。

皋陶抓到的是最重的一条，标了红：手册初稿里写了「教学命令块里的 git clone 网址可以豁免导流红线」——这条来自考古实录，10 月 1 日净化重发时确实这么操作了，三篇也确实没再被判违规。但规则文件里没有这条豁免。AI 把一次没被追责的实操，写成了通用规则——事实记录越过了规则制定权。

处置方式不是删掉了事，而是上报人类拍板。拍板通过了，豁免写进规则，附拍板日期。这一来一回确立了一条原则：AI 可以发现规则过时，但修规则的笔，必须握在人手里。

三个质检员合计抓出十几个黄级问题，其中四个属于「规则落后于实操」——按老规矩「冲突以规则文件为准」，新实证反而会被旧口径推翻。最终四个口径全部回写规则：重发额度、封面双规格、数据回收改按需、违规先下架。其中数据回收那条，用户的原话干脆利落：「不用定时任务了」——此后数据采集就改成了点名才查，规则里原本的定时口径在回写前一直是摆设。

五、真正想说的三件事

故事讲完了。这次整理沉淀出的方法论，比那份手册本身更值钱。

**第一，知识要分区安家。**CLAUDE.md 是常识区，每个会话开门就见；rules 是红线区，管「不许做什么」；skill 是操作区，管「怎么做」，按需加载不占日常上下文。三者的更新节奏不同——红线改动必须人拍板，操作细节可以随实操演进。混在一起的结果，就是要么天天背全量，要么关键知识没处放。

**第二，会话历史是被低估的资产。**376MB 的记录，平时看着是垃圾，其实是团队工作日志：每一次报错和修复、每一句用户拍板，都带时间戳躺在那里。问题只在于没人去挖。这次六个代理跑完全部考古，用时不到半小时——成本已经低到「没有理由不做」。

**第三，AI 整理的知识必须过质检。**考古报告会转述失实，会自相矛盾，会在无人监督时悄悄放宽红线。这次的解法是交叉验证（原始调用记录对质）+ 角色互审（使用者、技术、合规三个视角）+ 拍板上报（红线改动归人）。三个环节各拦住了一批真问题。

还有个尾巴值得一提：官网索引停摆是金乌在质检时发现的，顺手修复——重新生成索引、补上三篇重发后的新链接、推到部署分支。也就是说，这次「整理知识」的工作本身，全程在用这套知识库干活。吃自己的狗粮，狗粮是新鲜的。

互动话题

你的 AI 助手重复踩过最贵的一次坑是什么？你把经验交给它保管了吗？评论区聊聊。

参考资料

• 主线 04 篇《给 AI 配工具箱：Skills 技能实战》（本系列）
• wechat-mp-mcp-server（npm / GitHub 可搜索，开源）
• 微信开放文档：草稿箱 / 发布能力（可搜索）
• Claude Code 官方文档：Skills（可搜索）

免责声明

本文内容仅供学习交流，所述方法需结合实际场景灵活运用。AI 工具输出结果仅供参考，关键业务决策请结合人工判断。

本文由 AI 辅助创作，经人工审核编辑后发布。文中全部数字出自项目会话记录与 git 提交历史，可溯源。