wechat-article-processor

name	wechat-article-processor
description	从 Feishu / Chat 中接收 URL（单条或批量），拉取全文，生成 Wiki 实体。支持批量 URL 串行处理 + 即时进度反馈。微信双路径抓取：用户粘贴→Chrome MCP (CDP) → Hermes 内置浏览器兜底 → Playwright Profile；inbox 扫描→Jina→TinyFish→Playwright→curl 兜底。小红书：Chrome MCP 提取文字区 ✅ → Jina Reader 兜底（Chrome MCP 断连 + 浏览器 IP 拦截时） → GitHub 回填（技术开源类，最后手段） → 图片轮播自动 OCR（screenshot 落盘 → delegate vision 子代理 macOS Vision OCR，2026-08-05 实测可全量提取）。内容评估与决策见 references/xiaohongshu-content-triage.md。
version	34
related_skills	["llm-wiki","wiki-pipeline","rss-to-wiki-pipeline","wechat-mp-rss-extractor","newsletter-link-extractor","tinyfish-web-agent"]
references	["references/scoring-calibration-session-2026-07-14.md","references/scoring-calibration-2026-08-04.md","references/scoring-calibration-2026-08-05.md","references/scoring-calibration-2026-08-06.md","references/scoring-calibration-2026-08-07.md","references/xiaohongshu-autocli-discovery-pattern.md","references/chrome-mcp-wechat-fetch.md","references/raw-article-post-processing.md","references/batch-contingencies.md","references/hermes-browser-fallback-wechat.md","references/scoring-calibration-session-2026-08-05.md","references/playwright-profile-race-condition.md","references/borderline-scoring-heuristics.md","references/xiaohongshu-content-triage.md","references/todo-externalized-state-pattern.md","references/concurrent-edit-conflicts.md","references/index-duplicate-sections.md"]

文章处理器（微信公众号 + 小红书 + 通用）

2026-08-07 v36 — 校准 #183-184（详见 references/scoring-calibration-2026-08-07.md）：①共享实测数据 ≠ DUPLICATE（#183）：若飞《拆解 TencentDB Agent Memory》→ v=8/c=6/48 SUPP to tencentdb-agent-memory-hierarchical——本文与 Datawhale 实测文（#140）连实测数字都完全一致（第5秒/第10秒/提炼6秒、不能吃辣召回、PostgreSQL→MySQL 冲突——官方 README 同一套测试场景），但若飞增量是独立框架维度（三路径速度分离/四对象分类含出错代价/四测试清单/五问框架/公开方案对比表）grep 全库零覆盖 → SUPP（#148 判据延伸：独立框架=SUPP，测试数据重合不改变判定）；②c 看作者档位不看内容形态：Datawhale 同型机制级解读 c=5→40 Raw，若飞同型内容 c=6（#83 分析型先例，非源码级也有 c=6）→48 SUPP；③若飞架构级拆解 + 已有实体 → 稳定 SUPP 档（#52/#63/#83/#100/#105/#183 全 42-56）；④**#184 Hyman 稳定档直判**：Skill-Entropy RL（arXiv:2608.05139）v=6/c=5/30 RAW——全库零匹配非 DUPLICATE 但 30<42 无 entity 可 SUPP；⑤坑 8b — commit hash 回填 replace 命中错误条目：content.replace('Commit: TBD', hash, 1) 会替换第一个 TBD——log.md 里常有其他会话 pending 条目（实测误填 sibling 的 MCP Bridge 条目），回填必须用自己条目的唯一末尾文本作锚（先 assert content.count(marker)==1），误填后 git diff log.md 定位 + patch 还原。

2026-08-06 v35 — 混合批 18 条收尾校准 #175-182（详见 references/scoring-calibration-2026-08-06.md）：①新信源 数据派THU 高校机构号 c=6（清华大数据研究中心背书，第一手实操+源码级拆解 → v=7/c=6/42 SUPP #176）；②新信源 中金公司研究部 券商第一方 c=8（正式研报 SAC 编号齐全 → v=8/c=8/64 NEW Entity #177，券商研报档位：低于第一方技术团队 c=9、高于媒体 c=7）；③新信源 爱折腾研究组 独立研究组 ★★☆☆☆ → 解读号档 v=6/c=5/30（#178）；④翻译号 DUPLICATE 模式（#179）：同一篇博客的不同翻译号再投 → DUPLICATE（XSecurity 译 Lilian Weng harness 文，量子位解读+机器之心编译+双实体已在库），先 grep 原文标题/原作者找同源；⑤占位 concept ≠ 覆盖（#177）：grep 命中 concept 先 head -40 查 TODO 占位符，占位页等同不存在不拦 NEW Entity；⑥坑 7 — index.md Glued lines：插入条目时 old_string 截断到目标行开头会把新行与原行粘成一行（diff 显示 +...v×c=42 (SUPP...) — 阿里云...），检测 grep -n ']] — .*]] — '，预防=old_string 含完整下一行；⑦同论文两种形态判定分叉（#180）：解读号/翻译号转述 → DUPLICATE，但用户提供论文原文 PDF（arXiv 第一手来源）→ SUPP 补强既有实体——判定锚点=论文原文是否含库内零覆盖技术内容（形式化定义/分项实验表/统计细节/局限声明），有则 SUPP（即使该实体当初是 30 分解读号建的）；一手源 c=8；⑧工具开源发布文 v=6 档（#181）：★★★★★ 第一方 c=8 但无量化数据/无 benchmark（只有架构描述）→ 48 在 42-55 区间、全库零覆盖且无 entity 可 SUPP → Raw only；⑨同一论文多解读号连续投喂（#182）：第 2 例起直接按 #150 判 DUPLICATE，无需逐篇论证细节是否"增量"。

2026-08-06 v34 — 混合批 13 条（微信 3 + 小红书 10）校准 #160-171（详见 references/scoring-calibration-2026-08-06.md）：①XHS 论文作者第一方发布 c 档位分界线——带 arXiv 链接+完整论文信息+量化数据 → c=6（CAGE 42、SESA 同型）；纯 teaser 无 arXiv → c=5（Harness-R1 35、LHTB #154 同型）；判定前先查帖内是否带 arXiv。②同一作者发布 ≠ 新内容：Haoran Luo 同日发 SEED（已入库→DUPLICATE）与 CAGE（未入库→RAW），逐论文查 arXiv ID。③新信源：千问AI平台 ★★★★★（阿里官方，c=9）；Vibe编码 = VibeCoder 微信账号名（c=5 常态）；AI技术立文未知个人号 c=5 封顶；4 个新 XHS 解读号（AIChannel/晓辉算法笔记/每日ComputerScience/小陈|RL每日雷达）全入 v=6/c=5/30 稳定档；清水第 2 例确认。④提及 ≠ 覆盖：grep 命中已有实体是 mention 非 coverage（Claw-Eval 被 minimax-m3 提及分数仍非 DUPLICATE；AgentEvolver 被六机制实体侧写仍非 DUPLICATE），独立实体/raw 才构成覆盖；但非 DUPLICATE 仍可能 Raw only（30<42 信源 c 是 gate）。⑤微信账号识别 #js_name 探测：fetch-with-profile.js --text 无账号名时用无头 playwright 读 #js_name（脚本见 calibration 文件）。

2026-08-06 v34 — 混合批 13 条（微信 3 + 小红书 10）校准 #160-171（详见 references/scoring-calibration-2026-08-06.md）：①XHS 论文作者第一方发布 c 档位分界线——带 arXiv 链接+完整论文信息+量化数据 → c=6（CAGE 42、SESA 同型）；纯 teaser 无 arXiv → c=5（Harness-R1 35、LHTB #154 同型）；判定前先查帖内是否带 arXiv。②同一作者发布 ≠ 新内容：Haoran Luo 同日发 SEED（已入库→DUPLICATE）与 CAGE（未入库→RAW），逐论文查 arXiv ID。③新信源：千问AI平台 ★★★★★（阿里官方，c=9）；Vibe编码 = VibeCoder 微信账号名（c=5 常态）；AI技术立文未知个人号 c=5 封顶；4 个新 XHS 解读号（AIChannel/晓辉算法笔记/每日ComputerScience/小陈|RL每日雷达）全入 v=6/c=5/30 稳定档；清水第 2 例确认。④提及 ≠ 覆盖：grep 命中已有实体是 mention 非 coverage（Claw-Eval 被 minimax-m3 提及分数仍非 DUPLICATE；AgentEvolver 被六机制实体侧写仍非 DUPLICATE），独立实体/raw 才构成覆盖；但非 DUPLICATE 仍可能 Raw only（30<42 信源 c 是 gate）。⑤微信账号识别 #js_name 探测：fetch-with-profile.js --text 无账号名时用无头 playwright 读 #js_name（脚本见 calibration 文件）。

2026-08-06 v34 — (1) 评分校准 2026-08-06 批次 #160-162（详见 references/scoring-calibration-session-2026-08-06.md）：腾讯云开发者 tdsql-harness 减法工程 v=8/c=9/72 NEW Entity——腾讯云开发者 原创团队深度工程实践（真实量化数据）→ c=9 同腾讯技术工程档（对比 #148 二手转述 → DUPLICATE；区分信号=原创实践+数据 vs 转述他人素材）；L0-L3 四层归属与已有保质期/主权线框架不同 → NEW 并显式标注互补。术哥 setup-matt-pocock-skills v=6/c=5/30 Raw——Matt Pocock skill 分析第 4 例（#85/#106/#144 同型，模式 4 例稳定，后续可直判 30 Raw）。美团图灵评测方法论 v=8/c=9/72 NEW Entity——人人一致/独裁者/Rubric 二元化/桥梁指标全库零覆盖 = 不可替代维度；与 IBM-Yale 学术综述、Langfuse 产品视角维度不同。(2) cross-link 目录陷阱：跨目录链接写 [[entities/X]] 前先验证目标实际目录（concepts/ 与 entities/ 存在同名 slug，实测 harness-gate-evaluation 在 concepts/，误写 entities/ 前缀 → lint BROKEN LINK 一次往返）。

2026-08-06 v34 — (1) 1st-party 技术号双档位（calibration #163）：腾讯云开发者首次达到 c=9（tdsql-harness 减法工程 v=8/c=9/72 NEW Entity）——判定依据是「reasoning about architecture + 团队真实度量 + 原创框架（L0-L3 四层归属）」，对照 #148 同账号 Graph 长文 DUPLICATE（同素材二手转述）→ c 评分看内容形态不看账号名。(2) NEW vs MERGE 判据实证：L0-L3 框架 vs 已有「保质期」「主权线」框架均不同 → 不同框架同一主题 = NEW entity + 显式互补跨链（7 条），主题重叠 ≠ MERGE。(3) 术哥 Matt Pocock 分析第 4 例（calibration #164）：setup-matt-pocock-skills v=6/c=5/30 RAW——系列档位稳定（#85/#106/#144/#164），第 2 例起直接套用不再逐篇论证；mattpocock-skills 实体存在但 30<42 不达 SUPP。详见 references/scoring-calibration-2026-08-06.md。

2026-08-06 v34 — (1) 评分校准 2026-08-06 批次 #163-166（详见 references/scoring-calibration-2026-08-06.md）：腾讯云开发者 tdsql-harness 瘦身 v=8/c=9/72 NEW Entity（账号双模式确认：一手实践实录 c=9 vs 二手转述 DUPLICATE #148；L0-L3 四层归属与保质期/主权线框架不同 → NEW + 互补标注）；术哥 Matt Pocock skill 分析第 4 例（setup skill）v=6/c=5/30（模式稳定归档）；美团图灵评测方法论 v=8/c=9/72 NEW Entity（人人一致/人机一致/Rubric 二元化/桥梁指标全库零覆盖=不可替代新维度；跨链目标目录前缀坑——concepts 页必须 [[concepts/slug]]，写 [[entities/slug]] 报 BROKEN LINK）；Harness-R1 XHS 第一方 teaser v=7/c=5/35 Raw（无 arXiv/方法细节 → c=5 封顶 #154 同型；同主题不同机制 → 非 DUPLICATE：训练 Harness Engineer vs Self-Harness 固定权重 inference-time 自提案）。(2) 跨链前缀规则：写实体相关实体节前先 ls entities/ concepts/ | grep <slug> 确认目标页目录。

2026-08-06 v34 — (1) MCP 瞬态恢复 + redirectPath 打捞组合路径（2026-08-06 批量 6 条实测，XHS）：MCP 首调用 Failed to connect 后，先用内置浏览器导航 xhslink 短链拿 300012 拦截页 redirectPath 里的完整 URL+xsec_token，然后重试 Chrome MCP 用该带 token URL 直接 navigate——一次成功（Harness-R1 实测），无需走代理 curl+Jina。兜底链触发条件是连续 4+ 次失败；单次失败+打捞成功 → 重试 MCP 而非跳 curl。(2) 第一方 XHS 发布 DUPLICATE vs 非-DUPLICATE 判据（#163/#164）：论文已入库且已有 raw 完整覆盖全部数字/机制 → DUPLICATE（SEED，Haoran Luo 第一方）；与已有实体机制根本不同（训练 vs inference-time）→ 非 DUPLICATE 并在 raw 内建范式对比表（Harness-R1 vs Self-Harness）。(3) 新信源 大模型知识分享（AIChannel） 入 XHS 论文解读号稳定档 v=6/c=5/30（"带你一起读论文"标签）。(4) 术哥 Matt Pocock skill 分析第 4 例确认（setup-matt-pocock-skills v=30，系列 #85/#106/#144 同型）。(5) 工业界方法论 vs 学术综述 = 不同维度 → NEW Entity 而非 SUPP（美团图灵评测 v=72，方法论关键词 grep 全库零覆盖作证据）。(6) 评分校准 2026-08-06 批次 #160-165 详见 references/scoring-calibration-2026-08-06.md

2026-08-06 v34 — (1) 新 DUPLICATE 规则：第一方作者发布自家论文（XHS）→ 论文已在库仍 DUPLICATE（calibration #167 SEED：论文作者 Haoran Luo 发布自家论文解读，同论文已由 Hyman 微信解读入库 → 增量仅作者列表/机构归属 = 论文元数据非独立维度 → DUPLICATE）。判定看「论文是否已在库 + 增量是否独立维度」，不因发布者身份（作者 vs 解读号）改变。(2) 第一方 XHS + 无 arXiv 链接（teaser 级）→ c=5 封顶 v=7/c=5/35（#166 Harness-R1 / #156 LHTB 同型）——c=6 需要论文/技术报告级深度（arXiv 链接+完整基准数据），宣传帖即使第一方也 c=5。(3) 新信源 2 个直接归档解读号稳定档：AIChannel（大模型知识分享）、每日ComputerScience → v=6/c=5/30 Raw（#168 SKT / #169 中科大 RAG 扩展）。(4) 术哥 Matt Pocock skill 分析第 4 例确认（#164 setup skill，v=6/c=5/30，与 #85/#106/#144 同型；实体存在 ≠ SUPP）。(5) 原创方法论 vs 二手转述：同信源不同判定——腾讯云开发者 #163 tdsql-harness（L0-L3 原创框架）→ v=8/c=9/72 NEW Entity，对照 #148（Graph 二手转述）DUPLICATE；分水岭是原创性不是账号。(6) 方法论体系级新维度 → Entity，单点维度 → SUPP：#165 美团图灵评测（人人一致/人机一致/Rubric 二元化/桥梁指标全库零覆盖 + c=9）→ 72 Entity；#160-162 单点维度（c=6-7）→ SUPP。(7) Chrome MCP 单次 Failed to connect 后重试即恢复（瞬态，非整场 down）——先重试 1 次再切兜底链。详见 references/scoring-calibration-2026-08-06.md。

2026-08-05 v33 — (1) 小红书代理 curl + Jina Reader 兜底路径（2026-08-05 实测，Chrome MCP 长时间不可达时可用）：Chrome MCP 连续 4+ 次 Failed to connect to MCP server + 内置浏览器被 300012 拦截时，内置浏览器访问 xhslink 短链的 error 页 redirectPath 参数里藏着带 xsec_token 的完整 URL——从 redirectPath 提取 note id + token，然后 curl -x http://127.0.0.1:10808 "https://r.jina.ai/https://www.xiaohongshu.com/explore/<noteid>?xsec_source=app_share&xsec_token=<token>%3D"（xsec_token 末尾 = 要编码成 %3D）→ HTTP 200 拿全文。注意 v2rayN 代理端口是 10808（不是 7890），Jina 走浏览器会卡 Cloudflare 质询、走 curl+代理直通。(2) 轮播图自动 OCR 取代手动 OCR：小红书 5 张轮播（leaderboard/PPT）可委托 delegate_task vision 子代理（macOS Vision OCR swift + 裁剪放大）完整转录，子代理还能用 chrome_javascript 从 DOM 拿原图 URL 逐张 OCR——「图片轮播需用户手动 OCR」已过时。(3) 评分校准 2026-08-05 批次 #155-162（详见 references/scoring-calibration-2026-08-05.md）：王晋东 AI evaluation 帖子 v=4/c=5/20 Reject（high-level teaser 无实质）；LHTB 第一方发布 v=7/c=5/35 Raw（完整 leaderboard 但 XHS 帖非论文级）；Oscholar LongHorizon-Harness v=6/c=5/30（研究组解读号档再确认）；新信源 清水（个人论文解读号）OpenThinker3 v=6/c=5/30；新信源 青稞社区 人大高瓴综述 DUPLICATE（同论文已入库 towards-long-horizon-agents-survey-mozi-space，METR 数据是论文原始数字）；飞樰 Loop→Graph v=7/c=7/49 SUPP（Anchors/Frozen Nodes/External Judgment 三防偏方法全库零覆盖=不可替代新维度）；数字人BuilderAgent 百度 v=7/c=7/49 SUPP（L1/L2/L3 Context 分级+Flow Efficiency+回流 Spec 全库零覆盖，姊妹篇不同维度）；vivo OpenSpec+AI Workflows v=7/c=6/42 SUPP（OpenSpec 规范层已覆盖但 AI Workflows 执行层五组件+Hooks 四时机全库零覆盖）。SUPP 关键判据再确认：核心实体已覆盖 ≠ 新文章 DUPLICATE——先检查本文是否有既有 raw 零覆盖的独立维度（四失败完整框架/三防偏方法/分级框架/执行层组件），有则 SUPP 而非 DUPLICATE（对照：腾讯云开发者那篇纯二手转述无增量 → DUPLICATE）。

2026-08-04 v32 — 术哥 Matt Pocock skill 分析档位第 3 例确认（calibration #144，详见 references/scoring-calibration-session-2026-08-04.md——主校准文件已到 100K 上限，新批次从该文件续写）：prototype skill 源码级分析（保真度光谱/UI vs Logic 双分支/?variant= 结构变体/handoff 进出主链路/六通用规则/三反例）→ v=6/c=5/v×c=30 Raw only，与 #85 main flow、#106 wayfinder+handoff 完全同型。关键确认：即使 mattpocock-skills 实体已存在，术哥的 Matt Pocock 二手 skill 分析仍 Raw only（30<42 不达 SUPP 门槛，实体存在 ≠ SUPP，c 仍是 gate）——Milvus 源码豁免（#122）仅限 wiki 已有姊妹实体（milvus-segment-lifecycle）的稀缺源码深度内容，不扩散到 Matt Pocock 分析系列。

2026-08-05 v33 — (1) Chrome MCP 整场不可达兜底链：连续 4+ 次 Failed to connect to MCP server = bridge 彻底 down（非瞬态），别死等——内置浏览器导航 xhslink 被 300012 拦截但错误 URL redirectPath 参数含完整 note URL + xsec_token，打捞后用代理 curl（本机 10808，非 7890）+ Jina Reader（token 的 = 编码为 %3D）抓全文，作者用 explore HTML regex "nickname" 提取（__INITIAL_STATE__ parse 常报错）；(2) 图片轮播 delegate vision 子代理 OCR 会实质改评分（LHTB 帖：文字区初判 v≈4 Reject 边界 → 轮播 OCR 挖出完整 leaderboard 表 → v=7/35 Raw only）——评分前先确认轮播图有没有数据表；(3) scoring calibration 2026-08-05 批次 #154-157（详见 references/scoring-calibration-session-2026-08-05.md）：王晋东 teaser v=4/c=5/20 Reject（第一方+零实质）、LHTB v=7/c=5/35（第一方+完整数据仍 c=5）、阿里 LongHorizon-Harness v=6/c=5/30（Oscholar 档再确认）、清水 OpenThinker3 v=6/c=5/30（新信源 清水 入个人论文解读号稳定档）；同团队/同模型不同维度（LHTB vs Harness Handbook、OpenThinker3 vs OPD 实体引用）→ 非 DUPLICATE。

2026-08-04 v32 — 术哥 Matt Pocock skill 分析档位第 3 例确认（calibration #144，详见 references/scoring-calibration-session-2026-08-04.md——主校准文件已到 100K 上限，新批次从该文件续写）：prototype skill 源码级分析（保真度光谱/UI vs Logic 双分支/?variant= 结构变体/handoff 进出主链路/六通用规则/三反例）→ v=6/c=5/v×c=30 Raw only，与 #85 main flow、#106 wayfinder+handoff 完全同型。关键确认：即使 mattpocock-skills 实体已存在，术哥的 Matt Pocock 二手 skill 分析仍 Raw only（30<42 不达 SUPP 门槛，实体存在 ≠ SUPP，c 仍是 gate）——Milvus 源码豁免（#122）仅限 wiki 已有姊妹实体（milvus-segment-lifecycle）的稀缺源码深度内容，不扩散到 Matt Pocock 分析系列。

2026-08-04 v32 — (1) 术哥「二手 skill 分析」模式第 4 例确认（calibration #144 Prototype）：术哥源码级拆解 Matt Pocock prototype skill（UI/Logic 双分支+保真度光谱+六规则+handoff 进出）仍 v=6/c=5/v×c=30 Raw only——即使已有 mattpocock-skills 实体，30<42 不达 SUPP；术哥源码豁免仅限 Milvus 分析（#122）。(2) 前端Q 原创实测档（calibration #145 Hermes 20 轮 CRUD）：winty 用 Hermes Agent 同一任务跑 20 轮量化自进化（步骤 12→5/耗时 26→11min/Token -40%/通过率 50%→90%），SKILL.md 沉淀→复用→补丁→稳态曲线；同作者实体 hermes-self-improving-overview-winty 存在但 35<42 → Raw only——「实体存在但不达 SUPP 门槛」路径示范。(3) 深思圈/深思SenseAI 账号家族（calibration #146/#147）：两篇（斯坦福 CS329A 课程解读、Graph Engineering podcast 编译）均 v=5/c=5/25 Reject——课程/podcast 二手解读无原创工程贡献，与 #75 同档；深思圈是深思SenseAI 母账号。(4) ：腾讯云开发者/邢志铭 Graph Engineering 长文核心概念全部已被腾讯技术工程 #77 实体覆盖（同一批 Anthropic 素材）→ DUPLICATE，增量（起源故事/工作图vs角色图/简报例子）属同一套事实不同粒度。

2026-07-22 v11b — scoring-calibration 追加 entry #52（若飞/架构师 三循环架构，Supplementary to Agentic RL entity）；新增「架构师 by 若飞」作者级可信度说明；新增使用提示：收到用户 URL → 必先加载本 skill，避免遗漏评分校准。

2026-07-22 v11a — scoring-calibration 扩展：追加 2026-07-22 批次 5 篇评分决策 (#40-44)；新增 Legend 分类「AI tech media (机器之心) ★★★★☆」「Independent research group ★★☆☆☆」；新增 Source Reliability 条目：千问AI平台 (★★★★★)、机器之心 (★★★★☆)、PaperWeekly (★★★☆☆)、大模型论文研习社 (★★☆☆☆)、数字莫伊拉 (★★☆☆☆)、爱折腾研究组 (★★☆☆☆)。

2026-07-17 v10 — scoring-calibration 大版本更新：清除批次号重复，补入 2026-07-17 全部 12 篇打分决策（#25-36），新增 6 类信源评级（第一方模型公司/研究分析号/AI独立实践者/AI新闻观察者/技术策展号/社区学习号），更新 Recurring Patterns，追加 10 条 Source Reliability 条目。

2026-07-17 v9 — 追加 2026-07-17 评分决策（PagePilot PC端AI测试Skill实战，v×c=64），阿里云开发者第3条校准数据点（连续3条 Entity）。

2026-07-16 v8 — 更新评分校准参考（scoring-calibration-session-2026-07-14.md），追加 2026-07-16 第二批次 3 条评分决策（State Lake/FAST/高德 ACM MM），扩充信源评级表（字节跳动技术团队、滴滴技术、高德技术、AI编程实验室、阿帕奇的小站）。确认个人账号（无机构背书）v×c 上限约 28-30，即使内容质量中上也无法突破 c≤4 限制。

2026-07-17 v9 — scoring calibration 追加 2026-07-17 批次 4 条评分决策（PagePilot/Matt Pocock/Harness Handbook/淘宝工作台），references/batch-contingencies.md 升级 v2：新增"预评分再委派"流程、顺序单 URL 与批量 URL 的判定规则、低分个人号处理策略。确认大淘宝技术 sub-brand（营销&交易技术）同属 ★★★★★ 第一方信源。 2026-07-15 v18 — references/raw-article-post-processing.md 新增 Supplementary Source 常见陷阱：陷阱 1（替换末行时丢失 existing backlink citation）、陷阱 2（index.md 实体插入后 |- 前缀污染，需每次 patch 后立即 grep 检查并修复）。

2026-07-17 v9 — references/batch-contingencies.md 升级 v2：新增"预评分再委派"流程、顺序单 URL 与批量 URL 的判定规则、低分个人号处理策略。 2026-07-15 v17 — references/chrome-mcp-wechat-fetch.md 升级 v2：新增 Hermes 内置浏览器作为第 2 层兜底（Chrome MCP 不可用时），更新 flow chart、对比表、fallback 顺序；追加 JS DOM 提取模式（2026-07-15 实测 5942 字文章零重复）。实测场景：Chrome MCP server 断开，browser_navigate + browser_console DOM 克隆提取成功绕过 WeChat CAPTCHA。，涵盖 10+ 个 WeChat 信源类型（官方技术号/QCon 演讲/独立博客/翻译/社区号）的实际 v×c 打分案例与信源可靠性评级。横向对比同一 session 内的所有决策，提供反复校准的参照系。\n> 2026-07-14 v15 — references/concurrent-edit-conflicts.md 新增：|## header 前缀污染检测与修复、sed -n 预防技巧、log.md sibling subagent 警告处理流程、grep -n 替代 read_file 进行 patch 构造的建议。基于 10 篇单日批量入库中重复出现的 ${\"|- \"}→{\"- \"} 循环修复模式总结。\n> 2026-07-14 v13 — references/hermes-browser-fallback-wechat.md 新增推荐方案三：DOM Clone + 逐文本节点遍历，彻底解决 TreeWalker 内容重复问题，同时输出带 markdown 格式的干净文本。原 TreeWalker 方案降级为历史记录。实测 5942 字文章零重复。\n> 2026-07-08 v12 — 新增 references/raw-article-post-processing.md：wechat-inbox → raw/articles 的 frontmatter 替换规范、重复 frontmatter body 清理、supplementary source 处理分支。patch SKILL.md 添加 references 字段指向现有全部 9 份参考文档。\n> 2026-07-06 v11 — 新增 Hermes 内置浏览器工具（browser_navigate + browser_console DOM extraction）作为 Chrome MCP 不可用时的抓取兜底。\n> 2026-07-06 v10 — 新增微信用户粘贴 URL 的 Chrome MCP 路径。\n> 2026-07-02 v8 — 小红书抓取策略重大更新：新增 Chrome MCP（CDP 连接用户真实 Chrome）成功提取文字区正文。\n> 2026-07-04 v9 — 新增 Playwright Profile 间歇失败 pitfall。\n> 2026-07-01 v6 — 用户粘贴 URL 路径重写：Playwright Profile 提升为 FIRST（非 Jina），批量场景 Step 0 循环体内也走此规则。\n> 2026-07-02 v4.1 — 修复 Batch Mode 遗忘问题：新增 todo 工具外部化状态追踪 + 循环强化规则。\n> 2026-07-02 v5 — Batch Mode 强化：使用 todo 工具外部化任务追踪 + 强制循环不中断规则。\n> 2026-07-01 v4 — 新增 Step 0 Batch Mode。\n> 2026-06-27 v3 — 新增小红书抓取策略、index.md raw 条目要求。\n> 2026-06-19 v2 完整重写 — 整合 wikify.md + wechat-article-processor.md 所有内容。

适用场景

用户通过 Feishu/Chat 粘贴微信公众号/小红书/通用 URL → 拉取全文 → 评估并入库到 wiki。

决策分类（4 种）

1. Entity (v×c ≥ 64 坚定 / 56-63 谨慎且无现有实体) — 创建新 entity + raw article + index + log
2. Supplementary (v×c ≥ 42 且 entity 已存在，内容提供不可替代新维度) — 不创建新 entity；raw article + 追加 entity source + index Sources 更新 + log ("SUPP")
3. Raw only (v×c 30-41，或 v×c 42-55 但无现有 entity 可补充) — raw article 存档 + index Sources + log
4. Reject (v×c < 30) — 告知用户，不入库

关键区分：Entity 与 Supplementary 的区别在于该主题是否已有现有实体。先搜索 wiki 确认，有则走 Supplementary。

⚠️ SUPP 目标判定：entity 文件存在即满足条件，不看该 entity 的原始评分（2026-08-03 实测）：qwen-skill-self-play-hyman-2026 的 raw 原始评分为 v×c=30（Raw only，Hyman 的杂货铺个人号 auto-harvested），但 entity 文件已存在 → 新文章 SESA（v×c=42，机制同源）成功判 SUPP 而非 Entity/Raw。判定依据是 entities/ 目录下实体文件是否存在，而非该实体当初的入库评分。用 grep -l "关键词" entities/*.md 确认实体存在即可走 Supplementary 分支。

SUPP 目标可以是 concept 页（2026-08-06 实测 #175 MCP 无状态化）：concepts/model-context-protocol-mcp.md 存在且新维度（网关视角+社区批判）零覆盖 → 追加 SUPP 段落 + frontmatter sources +2，与 entity SUPP 同流程（lint 校验 BROKEN LINK / EXCESS INFERRED）。判定"目标存在"时用 ls entities/ concepts/ | grep <slug> 同时查两个目录——同名 slug 可能只存在于 concepts/（实测 harness-gate-evaluation）。

一手论文原文 PDF → SUPP 而非 DUPLICATE（2026-08-06 实测 #180）：同一论文两种形态走出不同分支——解读号/翻译号转述 → DUPLICATE（增量仅转述措辞或论文原始数字，非独立维度）；但用户提供的论文原文 PDF（arXiv 第一手来源） → SUPP 补强既有实体（即使该实体当初是 30 分解读号建的——实体文件存在即满足 SUPP 目标条件）。判定锚点：论文原文是否含库内零覆盖的技术内容——形式化定义（公式/目标函数）、完整分项实验表、统计细节（如技能库 Active/Effective 数）、局限与未来方向声明；有 → SUPP（一手源 c=8，v 按补强内容定，形式化+分项数据 → v=7）；无 → DUPLICATE。PDF 提取：textutil 对论文 PDF 常报 Text encoding Unicode isn't applicable → 直接 pymupdf 诊断+全量提取。

Supplementary 门槛说明：v×c ≥ 42 即可 Supplementary（即使低于旧版 ≥49 阈值），前提是文章为现有实体提供不可替代的新维度（工程架构/学术理论/客户案例），而非仅凭质量堆叠。42-48 区间需在决策理由中明确指出新增维度为何不可替代。

抓取流程

微信文章（用户粘贴 URL）

flowchart TD
    A[用户粘贴 URL] --> B{Chrome MCP 可用？}
    B -->|是| C[mcp_chrome_chrome_navigate URL (default mode)]
    C --> D{mcp_chrome_chrome_get_web_content textContent?}
    D -->|成功| F[进入评估/入库流程]
    D -->|超时/失败| G[改尝试 background=true 模式]
    G --> G2{get_web_content 成功？}
    G2 -->|成功| F
    G2 -->|失败| I2[Hermes 内置浏览器兜底]
    B -->|否| I2
    I2 --> J[browser_navigate + browser_console DOM 提取]
    J --> K{有内容？}
    K -->|是| F
    K -->|否| L[Fallback Playwright Profile]

已知问题:

• Chrome MCP background=false (default) 可能在某些 WeChat URL 上 timeout（60s）。尝试 background=true 有时可绕过。
• Hermes 内置浏览器也可能 timeout。两种工具交替试：当一种 timeout 时立即切换另一种。
• browser_console 首次返回 NO_JS_CONTENT 不一定是页面没内容（2026-08-03 实测）：微信文章 DOM 提取可能遇到页面加载竞态——第一次调用 #js_content 克隆返回 NO_JS_CONTENT（snapshot 也只见空 paragraph+图片），但重新 browser_navigate 同一 URL 后再次提取即可拿到完整正文（实测重导航后 length=3086）。遇到 NO_JS_CONTENT 先重导航重试 1-2 次，不要直接跳到 Playwright Profile 或判抓取失败。
• 如果两种都 timeout，报告给用户而不是反复重试。

小红书文章（用户粘贴 URL）

小红书 IP 风控较严格，Hermes 内置浏览器经常被拦截。抓取优先级：

⚠️ xsec_token 必须保留（2026-07-31 实测）：用户粘贴的小红书分享链接通常带 xsec_token。抓取时必须带上该参数（保留 xsec_source + xsec_token，可去掉其余分享追踪参数；navigate 时 URL 被重定向到 /explore/ 前缀属正常现象）。用裸 item URL（无 token）打开会返回 404「当前笔记暂时无法浏览」（error_code=300031，区别于 IP 风控的 300012）——即使笔记存在也拿不到正文；Jina Reader 对小红书 URL 会触发 Cloudflare 质询，通过验证后也可能只返回空页面（仅页脚/导航、无笔记正文）。遇到 404 先补 token 重试，不要直接判定笔记已删除。若用户只给了短链（xhslink.cn），直接 navigate 短链即可自动重定向到带 token 的完整 URL；若只有裸 note ID 链接，抓取失败则告知用户需要带 token 的分享链接。实测路径：Chrome MCP + 完整 token URL 一步抓到正文。error_code 区分（2026-08-03 实测）：300012 = IP 存在风险（Hermes 内置浏览器常见，navigate 短链重定向后即触发）；300031 = 缺 xsec_token 笔记 404。遇到 300012 不要判定笔记删除——直接切 Chrome MCP（用户真实 Chrome 带真实 cookie），同一短链实测：Hermes 内置浏览器 300012 拦截 → Chrome MCP 一步成功。

1. Chrome MCP（首选）：mcp_chrome_chrome_navigate + mcp_chrome_chrome_get_web_content。文字区提取效果好。图片轮播不要默认跳过——delegate_task 带 vision toolset 可 OCR 整组轮播图，且会实质改变评分（2026-08-05 实测）：LHTB 帖正文文字区仅 high-level 概述（初判 v≈4），委托 vision 子代理对 5 张轮播图 OCR 后挖出完整 leaderboard 表（12 模型 Mean reward/solved）+ 论文关键数据（46 任务/9.9M tokens/15.2% pass@1）→ v 提到 7、从 Reject 边界变 Raw only。子代理可用 macOS Vision framework（Swift OCR）兜底 vision_analyze 不可用；为拿到原图，子代理可经 mcp_chrome_chrome_javascript 读轮播图真实 URL（注意 MCP 输出会脱敏 base64 片段，用 DOM 查询拼接）后下载到 /tmp 逐张 OCR。

⚠️ 图片轮播可自动提取——不需要用户手动 OCR（2026-08-05 实测推翻旧限制）：XHS 笔记正文文字区只是 teaser，实质内容（leaderboard 数据表/论文首页/PPT）常在轮播图里。自动提取路径：

# 1. 截图（screenshot 返回 base64 太大 → 落盘）
# chrome_computer action=screenshot 输出存 /tmp/xhs_page.png（JSON 里的 base64Data 字段，python3 解码）
# 2. 委托 vision 子代理分析（delegate_task toolsets=['vision','file','terminal']）
#    子代理可用 macOS Vision framework（swift OCR 脚本，原生中文识别）逐张转录
# 3. 子代理也可直接从 DOM 拿原始图 URL（chrome_javascript 读 swiper 的 img src，编码绕过 MCP 脱敏）
#    下载全部轮播原图（1080px）逐张 OCR，比截图放大更清晰

实测（LHTB 笔记）：5 张轮播图全部提取——leaderboard 12 模型排行表（Grok 4.5 第一/Grok 4.2 垫底+solved 计数）、20 行完整榜单、论文首页摘要数据（46 任务/9.9M tokens/85.3min/15.2% pass@1）、X 推文截图。评分必须计入图内数据：同一作者两帖，纯文字 teaser（无图数据）v=4 Reject vs 图含完整 leaderboard v=7 Raw——轮播图是 v 评分的关键证据，OCR 后再定分。

⚠️ Chrome MCP navigate 新标签页 → get_web_content 必须带 tabId（2026-08-03 实测）：mcp_chrome_chrome_navigate 打开短链（xhslink.cn）时会在新标签页打开并返回 tabId，但新标签页不一定是活动标签页——不带 tabId 调用 chrome_get_web_content 会抓取用户当前活动的其他标签页内容（实测抓到用户开的 Bilibili 视频页，标题/正文与目标完全无关）。正确姿势：navigate 后总是把返回的 tabId 显式传给 chrome_get_web_content（{ tabId, textContent: true }），不要依赖活动标签页。抓到无关页面 ≠ 短链跳错，先带 tabId 重试目标标签页，再考虑重定向失败。 2. Jina Reader 兜底（Chrome MCP 不可用时）：browser_navigate('https://r.jina.ai/RAW_URL') — 绕过 IP 拦截，直接获取 markdown 格式正文。实测 Chrome MCP server 断开 + 浏览器被 IP 限制时可用。

⚠️ Chrome MCP 持续不可达 → redirectPath 令牌打捞 + 代理 curl + Jina（2026-08-05 实测，Chrome MCP 整场 down）：当 mcp_chrome_* 连续 4+ 次 Failed to connect to MCP server（bridge 彻底不可达，非瞬态），不要死等恢复，走这条已验证的兜底链：

1. browser_navigate('http://xhslink.cn/o/XXXX')（Hermes 内置浏览器）→ 必被小红书 IP 风控拦截（300012），但错误 URL 的 redirectPath 参数里含完整 note URL + xsec_token——先把它打捞出来（如 https://www.xiaohongshu.com/explore/<note_id>?app_platform=android&...&xsec_token=<TOKEN>&...）。这就是 Jina/curl 需要的带 token 完整 URL，裸 note ID 无法替代。
2. 用代理 curl 调 Jina Reader（浏览器内 r.jina.ai 会卡 Cloudflare 质询页，但 curl 直通）：curl -s --max-time 60 -x <PROXY> "https://r.jina.ai/https://www.xiaohongshu.com/explore/<note_id>?xsec_source=app_share&xsec_token=<TOKEN>%3D" -o /tmp/xhs.txt。注意 xsec_token 的 = 要 URL 编码为 %3D。
3. 代理端口必须先探测（本机 v2rayN 是 10808，NOT 7890——7890 超时、10808 通）：networksetup -getwebproxy Wi-Fi 或 grep proxy ~/.zshrc。无代理时 Jina 直接 HTTP 000 超时。
4. 作者确认：代理 curl 直抓 explore URL 的 HTML（curl -x <PROXY> -H "User-Agent: Mozilla/5.0..." "https://www.xiaohongshu.com/explore/<id>?xsec_token=..."），用 re.findall(r'"nickname":"([^"]{1,40})"', html) 提取作者昵称（__INITIAL_STATE__ JSON parse 常因页面注入报错，regex 兜底更稳）。
5. Chrome MCP 恢复后优先切回（带 tabId 走完整流程），兜底只用于 MCP 不可达时。
6. Hermes 内置浏览器（Jina 也失败时）：browser_navigate(url) + browser_console(DOM提取) — 大概率被拦截回登录页。

// Jina Reader 示例
call browser_navigate({ url: 'https://r.jina.ai/https://www.xiaohongshu.com/explore/...' })
// 返回的 snapshot 中可直接读取 Markdown Content 字段

已知局限：Jina Reader 只能获取文字区，图片/轮播无法提取。内容评估见 references/xiaohongshu-content-triage.md。

⚠️ Chrome MCP 彻底不可达的完整兜底链（2026-08-05 实测）：Chrome MCP 连续失败（4+ 次 Failed to connect / unreachable after N failures）时不要干等自动恢复，直接走：

1. browser_navigate(xhslink短链) → Hermes 内置浏览器会被 300012 拦截，但拦截页 URL 的 redirectPath= 参数内含完整 note URL + xsec_token（error_code=300012 页面上能拿到带 token 的完整链接）。提取它——这就是一直要求的带 token URL。
2. 用该完整 URL 走 Jina 代理 curl：curl -s --max-time 60 -x http://127.0.0.1:10808 "https://r.jina.ai/<完整URL>"（10808 为 v2rayN 代理端口；浏览器内 Jina 会卡 Cloudflare 质询、直连 curl 超时，代理 curl 一步 HTTP 200 拿全文）。若代理端口变了先查：networksetup -getwebproxy Wi-Fi 或 lsof -iTCP -sTCP:LISTEN -P | grep -iE "clash|v2ray"。
3. 作者信息：代理 curl 抓 explore 页面 HTML（~750KB，HTTP 200）→ window.__INITIAL_STATE__ JSON 解析常因转义失败，改用正则 "nickname":"([^"]{1,40})" 提取作者。
4. XHS 笔记可带 PDF 附件（正文写"论文PDF已上传到附件"），curl/Jina 均不可取，raw article 里记录"附件存在未抓取"即可。

轮播图 OCR 决定 v（2026-08-05 实测）：同一作者连续投喂，有图（leaderboard）vs 无图（纯文字）内容价值差 2-3 分——抓取时必须检查轮播图。多图轮播（≥3 张）用 delegate_task（toolsets=['vision','file','terminal']）下载原图逐张 OCR：xhscdn 图片 URL 在 MCP 工具输出中被脱敏（redacted_base64），子代理可从 DOM 用字符编码拼接绕过脱敏取真实 URL，下载 ~1080px 原图后 macOS Vision OCR（vision_analyze 不可用时）可完整提取 leaderboard 表格/论文首页文字。实测 LHTB 5 张轮播：封面 + leaderboard 截图 + 20 模型完整榜单 + Musk 推文 + 两篇论文首页，全部可转录。

抓取方法

Chrome MCP（优先）：

call mcp_chrome_chrome_navigate({ url, background: true })
call mcp_chrome_chrome_get_web_content({ tabId, textContent: true })
// 识别公众号名（c 评分依据）：再取一次 #js_name 节点即可，返回账号名如"阿里云云原生"
call mcp_chrome_chrome_get_web_content({ tabId, selector: '#js_name', textContent: true })

⚠️ XHS 带 token 的完整 URL 直接 navigate 即可（2026-08-05 批量 15 条实测）：用户粘贴的 xiaohongshu.com/discovery/item/<id>?xsec_token=... 或 explore/<id>?xsec_token=... 完整链接，chrome_navigate 后自动重定向到 explore 页并保留 token，get_web_content({tabId}) 一次成功（3 条 discovery/item 链接全部直接抓到）——无需先走 xhslink 短链。只有裸短链（xhslink.cn）才需要 navigate 等重定向。

⚠️ mcp_chrome_chrome_javascript 必须用 return 语句（2026-08-05 实测）：该工具在 async wrapper 里执行，裸 IIFE (() => {...})() 形式会返回 undefined（实测 38 图页无输出）；改成 return {...} 顶层返回即正常。抓 DOM 数据用 return JSON.stringify({...}) 或 return {a, b, c}（对象会被序列化）。

Hermes 内置浏览器（兜底）：

// Browser navigate
call browser_navigate({ url })
// JS DOM extraction (recommended)
call browser_console({ expression: `
(() => {
  const content = document.querySelector('#js_content');
  if (!content) return 'NO_JS_CONTENT';
  const clone = content.cloneNode(true);
  const imgs = clone.querySelectorAll('img');
  imgs.forEach(img => {
    const alt = img.getAttribute('data-nick') || img.getAttribute('alt') || '[图片]';
    img.replaceWith(document.createTextNode(alt ? '[图片:' + alt + ']' : '[图片]'));
  });
  return clone.innerText || clone.textContent;
})()
` })

批量处理模式

用户确认门禁

批量 URL 推荐流程：先评估 → 汇总展示 → 用户确认 → 再执行入库。不要直接入库，等用户说"继续"后再逐篇操作。

使用 todo 工具追踪批量入库进度，每完成一步及时标记。这避免用户中途打断时丢失进度。

跨会话恢复已评估批次的「继续」指令（2026-08-02 实测）：用户可能在新的会话里回复"继续"，且回复对象可能是批外的其他消息（如附件 PDF）。此时批量评估结论只存在于旧会话的 session DB 中——不要重新抓取/重新评估（会改变既定决策且浪费 token）。正确恢复顺序：

1. session_search(query="<任一文章关键词>", sort="newest") 找到评估会话
2. 用 session_search(session_id=..., around_message_id=<评估汇总消息>) 滚动窗口，找回：3 个 URL、每篇的 v×c 决策、已定 slug、已入库的姊妹实体名
3. 直接按旧结论入库；若旧会话已部分入库（如 STAROps 已入库而 3 篇待确认），先核对 log.md / raw/articles 排除已完成的
4. 用户回复"继续"时若同时有未决问题（如 PDF 处理），先快速核查该问题状态（tail log.md + ls assets/），避免重复操作

判断"继续"指代对象：回复引用的是批外消息时，检查 todo 遗留（batch-contingencies 的 todo 外部化状态）或 log.md 未闭环的条目。

Sibling-race reconcile（2026-08-04 实测）：单 URL 入库时 write_file 返回 "modified by sibling subagent ''" 警告，或发现 index/log 已有自己的 slug——说明并行进程（cron/delegate 批次）先完成了同一文章的入库。先 grep 计数 + 核对决策一致性，不要盲目再写一遍：grep -c "<slug>" index.md 与 log.md 各为 1 → sibling 已完成；核对 sibling 的 v×c/decision 与自己评分是否一致（一致直接复用）；确认自己 raw 文件未被覆盖（grep 关键词计数 + 重新 shasum）；跑 lint。详见 references/scoring-calibration-session-2026-08-04.md Sibling-race reconcile pattern 段。

批量查重

Step 0 — 前置查重（所有类型必做）：

详见 references/scoring-calibration-session-2026-07-14.md（主校准文件，含 Legend 与历史决策；已到 100KB 上限，2026-08-04 起的决策在 references/scoring-calibration-session-2026-08-04.md 及更新的日期分文件）。

评分四要素：

• v (value): 内容原创性/技术深度/稀缺性（1-9）
• c (credibility): 来源可信度（1-9）
• v×c: 综合分
  • ≥64: 坚定接受（新 Entity）
  • 56-63: 谨慎接受（无现有实体则新 Entity，有则 Supplementary）
  • 42-55: 可 Supplementary（为现有实体提供不可替代新维度）；无现有 entity 则默认 Raw only（见 calibration 边界规则）
  • 30-41: ⚠️ Raw only
  • <30: ❌ Reject

log.md 格式

每种决策类型对应固定的 log 前缀：

• NEW — 新 Entity 创建
• SUPP — Supplementary 追加
• RAW — Raw only 存档
• DUPLICATE — 文章此前已入库（同 source_url 或同论文不同来源），跳过操作

DUPLICATE 格式示例：

## [2026-07-23] DUPLICATE | TimeLens2 时序定位 | timelens2-generalist-video-temporal-grounding | v×c=30 | Hyman的杂货铺 | 此前已入库(不同slug), 跳过

首次遇到 DUPLICATE 时：确认 Step 0 查重结果后仅写 log，不创建/修改文件。

DUPLICATE 判断补充（2026-07-31 校准）：同一论文的二手解读（个人号/媒体对已入库 arXiv 论文的转述），即使补充了论文中的具体数字（如成功率 62.1%→79.6%、mean@3 0.632），仍判 DUPLICATE 而非 SUPP——这些数字是论文原始数据，一手来源（arXiv 原文实体）是更好的引用载体；且个人号解读 v×c 通常 24-30，达不到 SUPP 门槛（≥42）。判断时先搜实体是否已覆盖核心概念（框架/方法/实验），而非仅看 URL 是否相同。

同作者同事件不同角度 → 非 DUPLICATE（2026-08-01 校准）：同一作者对同一协议/产品事件写了两篇文章，但角度实质不同（如 VibeCoder 的 MCP 2026-07-28 两篇：#98 状态类型/控制面总览 vs #124 Client 端迁移实操），判为新文章按自身 v×c 处理，不是 DUPLICATE。仅当两篇内容实质重叠（同一套事实、同一角度）才判 DUPLICATE。判断标准：是否有独立的技术细节/执行路径/实操步骤，而非只看 source_url 是否相同。

部分 DUPLICATE（一篇笔记覆盖两个主题，2026-08-05 实测 #156）：Yucheng Shi LHTB 笔记同时提 Harness Handbook（已被实体 harness-handbook-tencent-behavior-level-manual-2026 覆盖）与 LHTB（全库零匹配）→ 不整体判 DUPLICATE：已覆盖部分在 raw/log 标注不重复入库，新主题按自身 v×c 独立处理。判断：逐主题核对现有实体，而非以整篇为单位。

入库步骤

Step 0 — 前置查重（所有类型必做）： 在创建任何新 raw article 文件前，先搜索 raw/articles/ 下是否存在同 source_url 的现有文章。这可以避免同一篇 URL 以不同 slug 重复入库。

⚠️ SHA256 必须从保存后的文件计算，不要用 curl URL | shasum（2026-07-31 实测）：mp.weixin.qq.com 对无 cookie 的 curl 请求返回统一反爬页，不同文章会得到完全相同的哈希（本会话两篇不同文章 curl 哈希完全一致）。正确做法：write_file 保存 raw article 后，shasum -a 256 <file> 计算真实文件哈希并更新 frontmatter 的 sha256。小红书同理（且 curl 直接拿不到正文）。

批量入库优化原则：当一次处理 ≥2 篇需入库的文章时，按以下顺序执行以减少 index.md 操作次数：

1. 先创建所有文章的 raw article 文件（含 SHA256 更新）
2. 再创建所有 Entity 页面（如有）
3. 一次性更新 index.md：在一个 patch 中追加所有 entity 条目和所有 source 条目（Entities 节一次 + Sources 节一次），避免每篇文章单独 patch 带来的匹配风险
4. 一次性更新 log.md：汇总所有决策写入一条 log 条目
5. 修复管道符前缀污染（一次 grep 检查）
6. 运行 lint 验证

如果中途需要中断或发现遗漏，优先追加到已有 patch 而非再开新 patch。多次 patch index.md 会增加"Found 2+ matches"和"非连续删除中间行"的风险。

# 方法一：grep 搜索 raw/articles 目录
grep -rl "source_url: \"$SOURCE_URL\"" /Users/jinguo/wiki/raw/articles/
# 方法二：在 index.md Sources 节查重
grep "timelens2\|同一URL的部分标题关键词" /Users/jinguo/wiki/index.md | grep raw/articles

若发现已有同源文章：直接跳过 raw article 创建，仅更新 log.md 记录为 DUPLICATE，不再重复操作。source_url 是最可靠的匹配键（比 slug 更稳定）。

对于 Entity 或 Supplementary：

1. 保存 raw article（英文 slug + 日期）
2. 计算 SHA256 并更新 frontmatter（⚠️ 必须对保存后的文件算：先 write_file，再 shasum -a 256 <file> 回填 frontmatter。不要用 curl <mp.weixin.qq.com URL> | shasum——微信对 curl 返回统一反爬页，不同文章会得到相同哈希，2026-07-31 实测两篇不同文章哈希完全一致 db7d2a09…；XHS/Jina 抓取同理，一律以落盘文件为准。）
3. 创建 entity（检查是否已存在 → Entity 或 Supplementary） ⚠️ entity 正文 citation 必须带 .md 后缀（^[raw/articles/slug.md]），lint 的 CITATION_RE 正则要求 .md。2026-08-01 实测：写成 ^[raw/articles/starops-host-intelligent-inspection-ecs-ai-doctor-2026]（无 .md）→ lint 报 EXCESS INFERRED: 13/13 uncited paragraphs (100%)；补上 .md 后消失。只有 frontmatter sources: 数组不带扩展名，正文 citation 必须带。
4. 更新 index.md（Entities 节 + Sources 节）
5. 更新 log.md
6. ⚠️ 修复管道符前缀污染（patch 后立即 grep -n '^|' 全面检查）
7. 运行 lint 验证（node scripts/wiki-lint.mjs）— 只看首行 Wiki lint: N error(s)；MISSING sha256（历史批次文件缺字段）与 raw/articles 出现在 True Orphans 列表（raw 无需入链，500+ 同类文件均如此）都是正常/存量现象，不是本次操作引入的错误。判断本次新增文件是否有错：... | grep '<slug>'，无匹配即通过。⚠️ grep 命中不一定是错误：新 raw article 的 slug 出现在 True Orphans 列表属正常（raw 文件无需被链入，与 500+ 同类文件一致）；只有命中 MISSING from index、EXCESS INFERRED、INDEX DRIFT 等 error 级条目才需要修复。判断方法：grep -B3 '<slug>' 查看命中上下文，若在 True Orphans 段（紧随 ── True Orphans 标题、行首为 - raw/articles/...）即正常。

⚠️ INDEX DRIFT error（2026-08-02 实测）：本次入库新增 N 个文件后，lint 报 INDEX DRIFT: Total pages header says X, actual count is Y（error 级，非 warning）。修复两步，缺一不可：

1. 把 index.md 第 5 行 Total pages: X 改为 lint 输出的 actual count
2. 把 header 的 emoji 计数行 **📚X (linter: X tracked pages)** 同步为同一数字（lint 只查 Total pages: 行，emoji 行是装饰，但不同步会留下脏数据，下次对比困惑） 判断依据：本次新增文件数 = 新 raw articles + 新 entities 数量，lint 输出的 7783 tracked page(s) 即 actual count。

对于 Raw only： 1-2. 同 Entity 3. 仅更新 index.md Sources 节 + log.md，不创建 entity 4. ⚠️ 修复管道符前缀污染 5. 运行 lint

⚠️ index.md 操作注意

四坑预警：

坑 1 — |- / | / || 前缀污染：每次 patch index.md 后可能产生以下三种污染：

• |- 前缀（pipe-dash-space）：旧坑已覆盖
• | 前缀（pipe-space）：new_string 中用了 | 而非 - 作列表标记
• || 前缀（double-pipe）：new_string 行首多余 pipe

必须立即执行全面检查： ```bash

宽检：捕获所有管道符开头的行

grep -n '^|' /Users/jinguo/wiki/index.md

细筛：只有 |- 或 | 而非 |## 的行才是污染（⚠️ macOS BSD grep 不支持 -P，2026-08-03 实测报 invalid option -- P，用 -E + POSIX 字符类替代）

grep -nE '^|[[:space:]|-]' /Users/jinguo/wiki/index.md ``` 如有，用 patch 将 | 替换回 - （或 || 替换回 - ）。加宽的 ^| 检查能同时捕获 |- （漏 dash）、| （无 dash）和 ||（双 pipe）三种污染模式。grep -n '^|-' 单一模式会漏检后两种。

坑 2 — read_file 管道符 | 误当文件内容：read_file 输出格式 LINE_NUM|CONTENT，| 是列分隔符，非文件内容。直接复制 read_file 行到 patch 的 old_string/new_string 中时，容易将 | 作为前缀写入，导致插入行使用 | 而非 - 。修正：构造 patch 时始终用 - （dash-space）作列表前缀。复制 read_file 行时只取 | 之后的内容。

坑 3 — patch 非连续 old_string 会删除中间行：编写 patch 的 old_string 时，如果跳过了目标行之间的 1 行或多行不包含在 old_string 里，patch 会将这些跳过的行一并删除。预防：构造 old_string 时确保包含目标行之间的所有行，或使用更窄的匹配范围（2-3 行，不跨行）。修复：git checkout 回滚 index.md 后重做。

坑 4 — patch 报错 "Found 2+ matches"：当 old_string 在文件中出现多次时，patch 拒绝执行。加入更多上下文行使匹配唯一，或使用 replace_all=true。选上下文行时注意与上下游行的格式一致（统一 - 前缀）。

坑 5 — Sources 节编年子标题间的"游离条目"陷阱：index.md 末尾的 Sources 节使用 ### 2026-XX-XX Ingest 编年子标题。这些子标题之间或子标题后可能存在不属于任何子标题的条目（"游离条目"）。当用编年子标题作 old_string 上下文时，patch 可能匹配到非预期的位置，导致游离条目被移动到新的子标题下或与其他批次的条目合并。

修复：patch 前先用 grep -n '###.*Ingest' /Users/jinguo/wiki/index.md 确认 Sources 节的所有编年子标题位置及条目归属。构造 old_string 时包含目标子标题后全部可见条目行（而非仅要修改的条目标题），避免意外吞没上游或下游的游离条目。patch 后立即用 read_file offset=N 检查 Sources 节变动区域，逐行确认没有条目被移动或丢失。

坑 7 — index.md 插入行时 old_string 只给行前缀 → 粘行（2026-08-06 实测）：在 Sources 节插入新条目时，若 old_string 只包含目标行到某处的前缀（如 - [[raw/articles/higress-...|MCP 重回 HTTP 范式...]] 截断在中间），patch 会把该行剩余部分粘到 new_string 末行末尾（...新条目v×c=42) — 阿里云云原生，Higress 网关视角解读 MCP ...），形成一行两条目。修复：①old_string 必须包含整行到行尾（用 grep -n 取完整行再构造）；②patch 后立即 grep -nE '^[[:space:]]*\- \[\[raw' | head 目检相邻行是否粘连（两条目同行 = 粘行）；③粘行修复用 patch 把粘连行拆回两行（old_string=整条粘连行，new_string=两行）。

坑 8 — log.md commit hash 回填不得猜值（2026-08-06 实测）：先 commit 拿真实 hash（git log --oneline -2 读实际值）再回填，禁止在 python replace 里写占位符/臆测值（如 e85b3f1b3 + b2c4d5a6e）——本会话一次臆测 hash 写进 log 后需追加修正 commit 才闭环。正确顺序：①git commit 得真实 hash → ②git log --oneline -2 取两个 hash → ③python replace | Commit: pending → 真实 hash → ④再次 commit。回填后 grep -c "<hash>" log.md 验证。

坑 8b — Commit: TBD 盲替换会命中 sibling 的条目（2026-08-07 实测，双会话独立踩中）：log.md 里并行会话/cron 会留下多个 Commit: TBD 占位符（实测同批存在 5+ 个，如其他 2026-08-06 ingest 条目）。content.replace('Commit: TBD', '<hash>', 1) 替换的是文件里第一个 TBD——往往属于 sibling 会话的条目（实测误改 MCP Bridge 条目，write_file 还报 sibling subagent 修改警告），而不是自己刚追加的条目。修复：git diff log.md 定位误改行 → patch 还原 → 用自己条目的唯一末尾文本作锚重填。预防：①回填锚点不要用通用占位符 Commit: TBD，改用自己 log 条目独有的末句（如判定结论句「→ Raw only」「→ SUPP to ...」或 frontmatter sources +1）），且先 assert content.count(marker) == 1 再 replace；②自己的条目没有 Commit 占位符时用「唯一末句 + | Commit: <hash>」追加而非替换；③回填后 grep -n '<hash>' log.md 确认只命中自己的条目行；④log.md 并发修改警告（sibling subagent）出现时，回填前先重读文件核对当前状态。

坑 6 — 并发孤儿文件（2026-08-04 实测）：wechat-inbox-pipeline 或另一并行会话可能向 raw/articles/ 写入文件但未注册 index、git 未提交。特征：frontmatter 带 wechat_mp_fakeid/feed_name 字段、中文文件名、无规范 slug、mtime 在本次操作时间窗口内。症状：lint 报 MISSING from index Sources: raw/articles/<中文名> + MISSING from index: entities/<...>，且 INDEX DRIFT 增量大于本次新增数（实测新增 1 文件却 drift +4：2 个孤儿 raw + 1 个孤儿 entity + 自己的 1 个）。

处理规则：

1. 不要擅自补注册这些文件（可能是另一会话正在处理的中间状态，擅自 patch 会并发冲突——见 references/concurrent-edit-conflicts.md）
2. 先排查来源：git status --short raw/articles/ | grep '^??'（未跟踪文件）+ head -12 <file> 看是否有 wechat_mp_fakeid（pipeline 特征）；ps aux | grep hermes 看是否有并行会话
3. INDEX DRIFT 仍按 lint actual count 修 header（实际数包含孤儿），但明确向用户报告剩余 error 的来源和待处理建议
4. 自己的文件验证：grep 'MISSING from index: raw/articles/<my-slug>' 应无匹配；slug 出现在 True Orphans 列表属正常（raw 无需入链）

坑 6b — index.md 计数 header 并发修改（2026-08-06 实测）：并行进程可能已更新 index.md header（sibling 实测改到 7904），按旧值推算 patch 计数（7898+1=7899）会覆盖 sibling 的更新 → 造成 INDEX DRIFT error。patch 计数前先 grep -n "Total pages" index.md 看当前值；lint 报 INDEX DRIFT 时以 node scripts/wiki-lint.mjs 输出的 actual count 为准，两处 header（Total pages: 行 + emoji 计数行）同步为该数。并发孤儿文件（?? 未跟踪）不擅自补注册，仅校准计数。

坑 7 — Glued lines（两列表项粘成一行，2026-08-06 实测）：在 Sources 节某条目前插入新条目时，patch 的 old_string 只匹配到目标行开头（如 - [[raw/articles/X|标题]] 截断），new_string 又含完整新行——patch 边界处理会丢掉末尾 \n，导致新条目和原条目粘在同一行（diff 里显示 +...v×c=42 (SUPP...) — 阿里云云原生... 整行拼接）。这比 |- 前缀污染更隐蔽：行首仍是 - ，只有整行出现两个 ]] — 才看得出。检测：patch 后立即 grep -n ']] — .*]] — ' index.md（同行两个条目分隔符）；修复：把粘合行拆回两行（patch old_string=整条粘合行，new_string=两行各带 \n）。预防：插入类 patch 的 old_string 应含目标行的完整下一行（或子标题行），不要用截断行。

坑 6 — 并发孤儿文件（其他会话/pipeline 中途写入未注册，2026-08-04 实测）：批量处理中途 lint 报 MISSING from index 且指向不是本会话创建的文件时，先核对是否并发产物：

ls -lt /Users/jinguo/wiki/raw/articles/ | head -8   # 看时间戳是否落在本次会话之外
head -8 <可疑文件>   # 查 frontmatter 是否有 wechat_mp_fakeid / feed_name 字段（wechat-inbox pipeline 特征）

这些是其他进程（wechat-inbox-pipeline cron / 另一会话）中途写入的孤儿：raw 存在但 index 未注册、git 未提交（git status 显示 ??）。不要擅自补注册——可能与并发会话冲突（concurrent-edit-conflicts 教训）；INDEX DRIFT 差数 > 本次新增数即有并发写入迹象。正确做法：把 lint 剩余 error 归因到孤儿文件、如实报告用户并询问由谁处理（自己补注册需先按评分流程评估那两篇）。

坑 7 — 截断行 old_string → glued lines（2026-08-06 实测）：patch 插入新条目时，old_string 若只写到现有条目的行首/中间（如 - [[raw/articles/higress-...]] 截断在链接尾），new_string 又自带结尾换行 → patch 会把旧条目行剩余部分（ — 阿里云云原生，Higress 网关视角... 整段描述）粘到新条目行尾，合成一行。表现：新条目与旧条目描述在同一行、旧条目看起来"消失"（实际被吞进新行尾）。检测：patch 后 grep -n '<新slug>' index.md 看该行是否超长且尾部混着旧条目描述文字；lint 报 MISSING from index 指向旧 slug。修复：把粘连行拆回两行（新条目行 + 旧条目完整行）。预防：old_string 包含完整目标行（含行尾 ，v×c=... 全文），new_string 显式写成两行；或 old_string 用「上一行 + 目标行整行」作锚，避免截断。

坑 8 — SUPP 到 entity 而非 concept 时，实体名要核对目录：SUPP 目标在 entities/ 与 concepts/ 可能同名 slug（如 loop-engineering-methodology 在 concepts/、agent-loop-design 在 concepts/）。判定前 ls entities/ concepts/ | grep <slug> 同时查两目录，避免对 concepts/ 页写 entities/ 前缀链接（lint BROKEN LINK）。

常见拒绝原因

• v×c < 30: 个人账号综述/产品走查/无指标支持
• 30 ≤ v×c < 49: 独立博客 paper 总结/社区号最佳实践，无原创工程证据
• 已有实体时高级别文章走 Supplementary 而非新 Entity

参考文档

所有参考文档位于 skills/wechat-article-processor/references/ 目录：

• scoring-calibration-session-2026-07-14.md — 评分校准（2026-07-14 至 2026-08-03 决策 #1-143，主文件已达 100K 上限，2026-08-04 起新批次写入下一文件）
• scoring-calibration-2026-08-06.md — 评分校准 2026-08-06 批次（#160-182，混合批 22 条：tdsql-harness 减法/美团图灵评测/千问混沌工程/中金因子引擎 4 Entity；术哥 setup 第 4 例/Harness-R1 第一方 teaser/SKT/RAG 扩展/AgentEvolver/CAGE 第一方论文级 42/ScaleRL/Inference Hooks/上下文vs记忆/Claw-Eval/MedAgent-Pro/OpenAgentPack 9 Raw；SEED/Qwen Skill-SP/Lilian Weng 翻译/LongHorizon-Harness 第 3 例 4 DUPLICATE；MCP 无状态化 SUPP to concept + /loop 实操 SUPP to entity + Skill-SP 论文原文一手源 SUPP；XHS 第一方 c=6 vs c=5 分界线 + 提及≠覆盖 + SUPP 目标可 concept + 翻译号 DUPLICATE 模式 + 占位 concept≠覆盖 + 券商研报 c=8 档 + 同论文两种形态分叉 + 工具发布文 v=6 档；新坑：index 计数并发修改 + log.md hash 臆测回填）
• scoring-calibration-2026-08-07.md — 评分校准 2026-08-07 批次（#183：若飞 TencentDB Agent Memory 治理框架拆解 48 SUPP【同主题二次拆解非自动 DUPLICATE——Datawhale 实测数据完全一致但增量框架零覆盖 → SUPP；c 看作者档位不看内容形态：Datawhale c=5→40 Raw vs 若飞 c=6→48 SUPP】/ #184：Hyman Skill-Entropy RL 30 RAW；坑 8b 实例记录）
• scoring-calibration-session-2026-08-05.md — 评分校准 2026-08-05 批次（#154-159：王晋东 teaser Reject 20 / LHTB 35 / LongHorizon-Harness 30 / OpenThinker3 30 / 人大高瓴综述 DUPLICATE / 飞樰 Loop→Graph 49 SUPP；新信源 清水 入个人解读号档 + 青稞社区社区号档；轮播 OCR 改评分模式 + 同团队不同维度非 DUPLICATE + SUPP 新维度 grep 全量证据 + Chrome MCP 整场 down 的 redirectPath/代理 curl/Jina 兜底链）
• scoring-calibration-2026-08-04.md — 评分校准 2026-08-04 批次（决策 #144-154 + 新信源深思圈评级 + DUPLICATE 对照锚点）
• scoring-calibration-session-2026-08-04.md — 评分校准 2026-08-04 批次（#144-153：术哥 Prototype/前端Q 20轮实测/深思圈课程解读/Graph podcast 编译/腾讯同素材转述 DUPLICATE/Adams Qwen-SP DUPLICATE/Oscholar OpenMLE/InfoQ FDX SUPP/MemHarness/精臣 STAROps UModel Entity；含 recurring patterns + sibling-race reconcile 模式 + Sister-Capability vs 同主题深度侧判据）
• scoring-calibration-2026-08-05.md — 评分校准 2026-08-05 批次（#155-157：王晋东 XHS teaser Reject 档 / 第一方 benchmark 数据帖 v=7/c=5/35 / Oscholar 解读号档再确认；部分 DUPLICATE 模式 + 轮播图 OCR 决定 v 的启发）
• chrome-mcp-wechat-fetch.md — Chrome MCP 抓取方法
• raw-article-post-processing.md — 文章清洗与 Supplementary 处理
• hermes-browser-fallback-wechat.md — Hermes 浏览器兜底
• concurrent-edit-conflicts.md — 并发编辑冲突与 |- 修复 + 非连续匹配中间行删除陷阱
• batch-contingencies.md — 批量处理应急方案
• todo-externalized-state-pattern.md — Todo 状态追踪模式
• playwright-profile-race-condition.md — Playwright 锁竞争
• borderline-scoring-heuristics.md — 边界评分
• index-duplicate-sections.md — index.md 重复区块问题修复