Zhihu Content Pack

提供完整知乎内容创作流程，含选题、逐条全面事实核实、写稿、生成HTML、配图、交付标准包、发布自查与门禁、发布后回填台账与指纹管理。

Install

openclaw skills install @zhaoxinghua09-cell/zhihu-content-pack

知乎发文内容包（zhihu-content-pack）

适用场景

用户要求写知乎文章/回答、做知乎内容包、或把公众号内容改成知乎版。

固定流程（8 步，缺一不可）

🔴 第 0 步（执行本 skill 任何动作之前）：确认线上状态。 凡用户要求"发知乎"、或你拿到一份已有草稿/库存稿时，先用 question answers + search zhihu 判定三种状态：① 未发 → 走完整 8 步；② 已发需更新 → 走线上更正协议；③ 已发勿重复 → 停止，改补图/改错/弃稿。2026-09-30 实例：金融智能体安全标准题已被本账号发过回答，若未先查线上状态，就会做成重复内耗。

🔴 第 0.5 步（发布新内容前必跑）：查同账号已发内容是否角度重叠（防内耗）。 第 0 步只判"同一问题是否已答"，但新文章/新回答可能与你已发的另一篇角度撞车。2026-09-30 实例：拟发专栏《企业上 Agent 之前先想清楚三律》在账号 22 篇已发文章中虽未找到同名文，却与已发回答《凡自治之物：有籍、有证、有门禁》角度重叠 → 发布前须先确认是否内耗、能否合并或改角度。做法：先一次性拉全量已发清单成表——me contents --type article --limit 50 与 me contents --type answer --limit 50（用 Python 解析 CreatedAt/Title/LikeCount/Url，一次列出全部标题+日期），再 search zhihu 搜相关关键词，列出 2–3 篇最相关旧文做角度比对；命中重叠 → 默认改角度 / 合并 / 弃稿，不重复占坑。 2026-10-05 实例（全量盘点优于关键词搜）：关键词搜只看到零散几篇，拉全量清单才看清「身份」线已 4 篇（《我给 AI 发身份证：UIBC 开源了》《AI 的户口本上该写哪几栏》《SaMD 的「可信身份」是什么》《XLGD 三律给自治模型发一张「身份证」》）、「责任归属」「证据链」「人工闸口」「医械监管当老师傅」各已成篇 → 新选题必须避开这五类，否则内耗。教训：盘点要拉全量、按角度归类，不能只搜关键词。

对齐内容方向：新题材还是改写已有系列？账号与署名规矩先确认（默认署名：SynomosAI 治理线 · CC BY 4.0——2026-10-11 确立：国内平台绝不出现任何个人真名/拼音名/英文名/持久个人标识符类编号/历史笔名；客户向内容绝不出现真名/公司/客户信息）。
- 🔴 账号事实（用前必查）：知乎账号显示名可能改名，历史名不作判据、不作检索关键词。发稿前花一次 search zhihu --query "<标题关键词>" 反查返回项的 AuthorName 字段核对即可；别把记忆里的旧名当现名。
🔴🔴 全面核实（在写稿之前，不是之后）：见下节《强制全面核实协议》。两条顺序都会翻车——① 先写稿再核实，人会被自己的行文绑架，只去核对自己愿意核的那几条；② 只核源稿不核交付物，图注/图内文字/执行单会成为漏网区（2026-09-29 实际翻过）。动笔前先列全部交付物清单，逐件覆盖。
写稿：知乎文风 = 钩子开头 + 分节 + 加粗金句 + 结尾金句。回答体 500–800 字，专栏 1500–2000 字。
生成粘贴版 HTML：知乎编辑器是富文本（ProseMirror），粘贴 HTML 保留格式 ✅；直接粘 Markdown 源码不稳 ❌。每篇内容产出一个独立 HTML：浏览器打开 → Ctrl+A 复制 → 粘进知乎编辑器。页面顶部加黄色提示框说明用法（发布前删）。
出配图（可选）：见《出图管线》，硬性排版下限必须遵守。
发布指引：发布步骤 + 话题标签（提醒用户在知乎下拉框确认话题存在）+ 起量技巧（回答>专栏、挑关注数高的老问题、一天 1 篇文章+1~2 回答）。回答类还必须出 05-发布执行单-回答.html——见《回答交付标准包》，这是用户 2026-09-29 定的默认项，不用等他提。
发布前自查清单：删提示框、署名保留、无真名/公司/客户信息、话题确认。并跑确定性门禁——python $HOME/.workbuddy/tools/delivery_guard.py --config <交付目录之外>/guard.toml --json report.json；退出码非 0 不许交付（INCONCLUSIVE 是"检查不了"，同样不许放行）。配置从 tools/guards/zhihu.toml 抄改，必须放交付目录之外（放进去会污染 coverage，2026-10-06 实测踩过）。改稿后必须重跑，报告 JSON 与正文一并归档。详见《交付门禁脚本》。
发布后回填登记：拿到 URL 后登记 SynomosAI 权属台账 + 追加 SHA-256 指纹（见《回答交付标准包 · 发布后必做》）。若发布后稿件又修订，v2/v3 指纹分列登记、不覆盖旧值，并在发布指引里给出"线上更正路径"（含"编辑原文"与"评论区更正"两条，由用户择一）。

🔴 强制全面核实协议（2026-09-29 因返工确立，永久有效）

触发条件：任何涉及事实类陈述的内容产出（知乎/公众号/报告/简报/评估），无需用户要求，默认执行。

用户原话：「为什么第一次不核实准确，下次全面核实」——这是一条校正指令，此后不得再以"时间紧/看着够了"为理由降级。

三条不可妥协的动作

① 一手源必须抓全文，不得只看二手转述。 本次翻车的根因：只抓了一轮报告摘要就动笔，把媒体转述当成事实源。二手转述会丢限定条件（"约一半账号名暗示与 OpenAI 关联"被写成"全部带 OpenAI 字样"）、丢时序（"7/16 平台方先披露、7/21 OpenAI 承认"被简化成"次日公开"）、丢主体。 → 凡有原始 PDF / 报告 / 官方通知页，必须 WebFetch 抓全文，再与媒体交叉。只找到媒体报道时，在核实表里标"二手，未获一手证实"。

→ 🔴 PDF 一手源抓取（2026-10-05 实战补强）：WebFetch 对 PDF 会直接报 "non-text resource"，绕不过，别在这上面耗。 正确做法：① curl -sL <官方PDF直链> 下载到本地，先确认 HTTP=200 / Content-Type=application/pdf / SIZE 合理（异常直链会 301 到 HTML 错误页，下载到的是网页不是 PDF）；② 用隔离 venv 的 pdfplumber 抽全文——python -m venv <隔离环境> 后 pip install pdfplumber，勿污染系统 Python；③ 拿全文做关键词检索定位页码（如 "GEO" / "专栏四" / "附件2"），把"主张 → 页码"写进核实表。本次框架3.0 官方 PDF（136 页）即据此原文级坐实：GEO投毒=专栏四(p15)、智能体/具身智能风险首次单列(p12)、附件2=9类风险+7组防范措施(p42–50)、认知供应链(p33)、四个专栏(p9/13/14/15)、三律↔附件2映射。凡"首次/单列/等于某章某节"类断言，优先用这套拿到页码级证据。

② 逐条建"主张 → 状态 → 依据"表，覆盖每一个数字、日期、人名、机构名。 状态用三档：✅ 准确 / ⚠️ 需限定 / ❌ 需改。没有建表就不算核实过。 表格同时是交付物之一（04-事实核实报告_YYYYMMDD.md），供用户复核。易漏项清单（每条都要过一遍）：数字的量词与分母、"部分/约一半"类量词、日期锚点、人数与署名、机构全称、文件名与标准号、"首次/唯一/最"这类最高级、以及所有由数据推导出来的说法（例：不可由"25 年历史"直接推出"2001 年上线"）。

③ 二级结论（尤其"某某是空白/不存在"）必须反向搜索验证。 本次最严重的一条：写成"强制披露的时限与通道仍是空白"，实际 EU AI Act 第 55 条执法权已于 2026-08-02 生效、加州 SB 53 与纽约 RAISE Act 均有明确时钟，OpenAI 甚至已就本事件向欧委会提交事件报告。 → 凡要写"还没有 / 仍是空白 / 无人管"，必须先搜一遍"该领域 + 是否已有生效条文/执法案例"。写错这类断言，专业读者一眼判死，比写错一个数字更致命。

🔴 第二轮补强（2026-09-29 范围漏洞暴露后确立，与上三条同级）

根因：第一轮把核实范围写成"源稿 md + 前两张图"，但真正发到用户眼前的是粘贴版 HTML（含图注）、后两张图和执行单。"核实范围按源稿画、交付范围按实际交付画"——两把尺子不一致，中间那段就是漏网区。 结果：4 条图注、fig3/fig4、两份执行单全部没核，其中藏了 3 处硬错。

④ 核实范围按交付清单逐件枚举，不按"源稿"概括。 动笔核实前先列全部交付物（源稿、粘贴版 HTML、每条图注、每个图源 HTML、每份执行单、发布指引），每一件都要在核实表里有对应覆盖行。缺一行就是缺一件。

⑤ 图注、图内文字、执行单都是核实对象，不是源稿的搬运。 它们是新写的文案，会引入源稿里没有的断言（本次图注就把"跨站合计 1.8 万"写成了"同一处维基 1.8 万"）。图与图注是独立传播单元（会被单独截图转出），因此：匿名信源限定语必须在图内文字与图注里也带上，不能只在正文带。

⑥ 交付前跑"口径一致性自检"：同一数字在七处必须一致。 标题 → 正文 → 图注 → 图内文字 → 执行单 → 口径说明段 → 版本号与元信息。

口径说明段本身也是自检位（2026-09-29 第四次踩坑）。 文章标题从 1.8 万改成 1.7 万后，文末"口径说明"里仍写着"标题沿用 1.8 万指整批活动的总量"——改数字时只改了数字所在处，忘了改"对数字作出说明的那段"，等于文章自己承认标题写错了。凡文末有「口径说明／数据说明／修订说明」的，改主数字后必须回头重读该段，确认它描述的是新口径而不是旧口径。
版本号与元信息要单独核。 同日两次踩坑：粘贴版 HTML 的 <title> 写"粘贴版 v2"、正文黄框却写"本版为 v3"；执行单里也残留"版本 v2"。这类不出现在正文段落里的字段最容易被改版漏掉。改版后 grep 一次旧版本号（如 v2）确认零残留。
写 HTML 时不要混用 markdown 语法。 在 .html 粘贴版里写 **加粗** 不会渲染，会在页面上原样显示成星号；** 只能用于 .md 源稿，.html 一律用 <strong>。改完 HTML 要渲染截图放大目视——长图缩略态看不出星号残留。
接手旧稿（写好但没发的库存稿）时，第一件事是做"时效回溯"，不是改文字。 要在动手前问：这份稿定稿之后，有没有更新的核实结论推翻过它？ 2026-09-29 医疗线稿就栽在这里——稿写于 09-27 17:02，而同日 17:28 另一篇的核实已经推翻了它里面的说法（"缓存代理漏洞"→实为内部包管理器 Artifactory 的 SSRF 被当成出网代理），核实在前、稿子在中间、修正落在后面，旧稿没人回头同步。做法：翻当日/次日的工作日志，把该稿定稿时间点之后的所有核实结论过一遍，再逐条比对。
旧稿落地 = 交付形态升级，不只是改错字。 库存稿通常只有 .md + "【插图N】插在这里"的注释，缺 3 样：内嵌图注行的粘贴版 HTML（插图位是注释，粘到编辑器里会露出"【插图1】"字样，必须换成灰字图注行）、发布执行单（位点/自查/时效）、独立核实报告。缺一件就不算标准包。
插图位在列表中间的要挪出来。 图插在有序/无序列表的两条之间会打断列表排版。要么挪到列表之前，要么挪到列表之后（2026-09-29 医疗线图 2 从"登记/可核验两条之间"挪到三句列表之后）。执行单里要写明这个位点变更。
标题是独立的自检位，最容易漏。 2026-09-29 第三次踩坑：文章标题写 1.8 万、正文写 1.7 万、图与封面写 1.7 万——读者一看就觉得"数据不对"。前两轮自检把范围写成"正文/图注/图内文字/执行单"，标题不在其中（它不在源稿正文段落里）。
分不清"子集/全集"就先问分母。 本次 v2 在同一句话里同时出现 1.8 万（跨站合计）与 1.7 万（单站）。两个数都对，但并排出现而不点明从属关系，就等于自曝矛盾。凡"总数"与"其中"并列，必须显式写出从属词（"其中""合计"）。
跨口径统计的量不能与单站数字并排做算术。 本次 197（跨全部站点能归类到 AWS/DO/Tor 的条数）与 1.7 万（单站）并排，读者一算 1.7万×1.5%≈250 > 197 就认定写错。必须标注每个数的统计范围，并加一句"不可直接相减"。
媒体口径冲突时，回到一手报告原文定义分母。 本次 1.7 万的归属，媒体分成两派：报告原文 + Mobile World Live + SecNews + 钛媒体＝DSEWiki 单站；Information Security Report + radarbytes＝Azure 来源数；computing.co.uk 干脆写"between 15,000 and 18,000"。取一手报告摘要/正文原句的分母定义，并把媒体分歧整理成"读者可能质疑"预案写进发布指引。

⑦ 主体性断言必须找当事人自述，第三方专访是唯一可靠路径。 凡涉及"谁发现了 / 谁做了什么 / 谁没做什么"，报告写"有管理员察觉到"不等于当事人知道。本次：报告与多家媒体都写"6/2 有管理员发现并清理六周"，但站长本人受访时明确说他完全没察觉，是研究人员 8/27 通知的。两方说法必须并列，不得替读者选边。 → 做法：搜当事人姓名 + 事件名（含该国的本地语种媒体），找直接采访。找不到就标注"仅报告单方陈述，未获当事人确认"。

⑧ 相对性断言（"新增／首次／唯一／最"）必须做原文级版本比对**，媒体口径一律不算证据。** 2026-09-29 医疗线的第二次硬错就出在这里。断言是"这版首次为大模型和医疗智能体单独立章"——"首次/新增"是比较级，单看新文件永远无法判定，必须把新旧两版原文都拿到手逐节比。 → 做法：去官网找两个版本的文件（本次直接 curl 下载了器审中心 2022 年第 8 号通告附件与 2026 年征求意见稿附件两份 docx，解包 word/document.xml 提纯文本，再比对「技术考量」章的小节清单）。比对结果推翻了媒体和我们自己的说法：

真·新增独立小节 = 4 个（大模型 / 跨模态图像合成 / 多模态产品 / 多病种产品）；媒体写的"医疗智能体、持续学习算法单独立章"两项均不成立——医疗智能体是「大模型」节下的第 2 点，持续学习一节2022 版就有且两版逐字相同。
全文检索 2022 版：「智能体」「大模型」「跨模态」「多模态」「多病种」各 0 命中——这才是"首次出现"的硬证据。 → 推论：凡见"首次/新增/唯一/最多"，先在核实表里把状态标成"待版本比对"，拿到两份原文前不得写成 ✅。 媒体在"新增了哪几章"这类结构性事实上错得尤其集中（转载链条越长错得越一致）。 → 额外纪律：给非中文官方文件套《》＝冒充官方中文标题。原题无中文正式名时，用不加书名号的描述性指称（"FDA 2026-08-18 生成式 AI 医疗设备讨论文件"），或直接给英文原名。

附带的四条纪律

术语精度：分清"联合发布"与"同日分别发布"；分清"无人发现"与"无人披露"（本次真错：管理员 6/2 就发现并清理了六周，缺的是"识别为 AI 事件并对外披露"）；分清"同一批"与"独立两支"。
推断必须标注：归属类结论（"是 X 公司干的"）若依赖线索链而非内部确证，正文要写明"这是强推断"及线索构成；同时给出当事方否认/异议口径，两面都写。
口径差异并列不混用：见《口径纪律》。
改稿即改全链：核实结论若影响正文，源稿 .md、粘贴版 .html、配图 HTML/PNG、03-发布指引.md 的"已核实结论表"与自查清单必须同步改完，不能只改源稿。

🔴🔴 为什么总要用户催才查出来 —— 防"事后发现"五条机制（2026-10-06 用户质问后确立）

用户原话：「为什么都是每次让你调研检查你才查出错误」。这是校正指令，与《强制全面核实协议》同级，永久有效。

根因（五类，逐条对号入座）

#	根因	实例
①	把"推断"当"实测"用	写了 `text-align:center` 就认为标题居中（实为墨迹偏左 33–43 设备px）；按 3:1 想封面底条，没穷举 2.65:1 居中横裁（底条被整段裁掉）
②	图/衍生件免检	81 条核实行全在正文，图内一句没核 → fig2 漏"销售 10%–20%"、fig3 写"过渡期通常留 1 年左右"、fig4 标题 8 项目视 6 行
③	顺序反了：先出结论，后做侦察	先推荐"强制国标 8 项"→ 用户点头后才扫关键词 → 发现是红海。用户的点头变成了无效背书
④	把记忆/旧稿当事实源	账号显示名记成历史旧名（账号改过名）；旧稿定稿后的新核实结论没人回头同步
⑤	自检维度选错（最隐蔽）	第 38 条归组错误：自查只核"数字对不对"，没核"分法对不对"→ 自检通过而实际错。内部一致性自己能过，法理/归组只能回一手源证伪

五类的共同根因只有一句：我的自检是「内部一致性自检」（我写的东西彼此对得上吗），用户要的是「外部真实性与跨件一致性核验」（外部锚点认不认、图和文同不同步）。前者我自己就能过，所以「我自检通过」从来不等于「对的」；只有外部锚点（一手源、像素实测、交付清单）能证伪，而没人催时我不会主动去撞。 默认值设错了：默认是「推定通过」，正确值是「未验证 = 未知 = 不得声称已完成」。

五条机制（此后每次交付都要过）

M1 · 断言分级标注 —— 让用户不必重查就能看出风险区。

级别	含义	例
`[实测·一手]`	有原文/页码/命令输出	罚则 20%–50% ←《标准化法》第 33 条原文
`[实测·数值]`	有测量数据	标题墨迹中心 −3 / +7 设备px
`[推断]`	无外部锚点，逻辑推导	"该条构成要件是未公开执行标准"
`[经验·未实证]`	习惯性说法	"过渡期通常 1 年" ← 必须删或降级，不得入正文

规则：凡想写 [实测] 却复述不出锚点（命令、页码、像素值），一律降级为 [推断]。 直接对治 ①④⑤——它们出问题都是因为"推断"和"实测"长得一模一样。

M2 · 交付件清单 = 核实清单（机器闸）。 核实前先列交付目录全部文件，每一件都要在核实表里有覆盖行；交付前跑三组计数校验：图内断言条数 vs 正文核实行数、grep -c figcap vs 配图数、废弃表述 grep 0 命中。缺一行就是一漏件。对治 ②。

M3 · 输出前侦察钳制（顺序锁死）。 凡"给建议/选题/方案/命名/下一步动作"类输出——没有侦察结果不得输出结论。查重、反查账号、看站内现状都属前置动作，先跑，再说话。对治 ③。

M4 · 记忆降级为线索。 记忆/历史稿里的任何具体事实（账号名、包名、版本号、路径、数字）使用前一律现场反查，不得直接引用；接手旧稿先做"时效回溯"（定稿之后有无新核实推翻它）。对治 ④。

M5 · 交付必附「本次未验」栏。 比"我验了什么"更重要的是**"我没验什么"**——它划出真实风险边界，让用户知道哪些地方仍需他自己判断，而不是面对一句笼统的"已完成"。

text

## 本次未验（风险边界）
- [ ] 知乎信息流实际裁切像素（仅有裁切模型，无线上实测）
- [ ] 图在移动端窄屏的字号观感

禁止用"已全面核实""全部做到最好"这类无锚点总结收尾——没有逐件锚点的"已完成"就是过度声称。

M6 · 验证者必须独立于生产者 —— 这是架构约束，不是态度问题（2026-10-06 补）。

学术上已证伪「靠自己检查自己」：无外部反馈的内在自纠正会让准确率下降（arXiv 2310.01798, ICLR 2024）；LLM 自验证的假阳性率实测达 84%（arXiv 2310.08118）；同源模型评审团 9 票 ≈ 2 票有效（Apple）。三个 84%/2票这类数字见 调研-AI自检失灵的开源解法_20261006/00-调研报告（含来源分级）。 → 结论：单助手架构下条件①天然不满足，所以「更努力地自检」永远解决不了这类问题。正确动作是把能量转到条件②③——把能自证的部分交给确定性检查。

条件	要求	现状
① 验证者独立于生产者	不同模型族 + 不同证据源	🔴 结构性不满足。多模态复核属同族，不得记为"已验证"
② 存在 ground truth	字节/计数/像素/退出码，不是另一个 LLM 的意见	✅ 已可满足
③ 验证者在关键路径上	硬阻塞，非旁挂提示	✅ 已由脚本落实
④ 已测量阻断精度	统计拦截中的误报占比	🟡 每次误报都要记录并回修清单

推论：RAGAS / DeepEval / FActScore 等主流工具不可作为主门禁——判据是 LLM-judge，不满足条件②，且需 API key 与逐条调用成本。

🔴 交付门禁脚本 `delivery_guard.py`（2026-10-06 建，可直接复用）

正本位置：~/.workbuddy/tools/delivery_guard.py（v1.2.0，新增 visible_heading；~ 即 WorkBuddy 用户目录） 配置模板：~/.workbuddy/tools/guards/ —— zhihu.toml / wechat.toml / report.toml / skillpack.toml 说明文档：同目录 README.md（含能力边界清单 —— 跑过门禁 ≠ 都过了，务必看） 实例配置：历史项目归档「交付门禁/guard-xcgs.toml」（存量体检的完整写法，本地检索获取）

bash

PY="$HOME/.workbuddy/binaries/python/versions/3.13.12/python.exe"
"$PY" delivery_guard.py --config guard-xxx.toml              # 跑门禁
"$PY" delivery_guard.py --config guard-xxx.toml --json r.json # 留档
"$PY" delivery_guard.py --selftest                            # 负向自测：证明它会抓错

11 类确定性检查：coverage（交付目录每个文件都被清单覆盖）／grep_count／count_files／png_size／png_lightness／grep_zero／text_present／no_ascii_quote／visible_heading（读者可见标题，v1.2.0）／sha256／file_exists

四条核心纪律

fail-closed：三态 PASS / FAIL / INCONCLUSIVE（"检查不了" ≠ "通过"）；任一 FAIL 或 INCONCLUSIVE → 退出码非零，不许交付。
零成本：纯标准库 + 可选 Pillow，不联网、不调模型、不耗积分。
改稿后必须重跑，JSON 报告留档（含配置哈希 + 时间戳，可重放）。
配置文件必须放交付目录之外（2026-10-06 实测踩坑）：放进去会污染 coverage —— 门禁把自己当成了未覆盖产物，报出假 FAIL。验证者不该住在被验证对象里。

severity 分级（v1.1.0 新增，存量体检必用）

值	行为	用途
`blocking`（默认）	非 PASS 即阻断交付	当时就该满足的红线
`advisory`	只标 `[WARN]`、不影响退出码	规矩变了造成的差距（存量包 vs 新规矩）

实测用例：XCGS 包 10-05 定稿、封面深色；浅色系判据 10-06 才立 → 标 advisory，不把它误判成"这包错了"。不分级的话，扫存量包会清一色 FAIL，等于没有信息量。 ⚠️ severity 拼错直接报 FAIL，不静默降级（否则"以为配了观察项、实际在阻塞"看不出来）。

三个必须记住的坑（全部是实测踩出来的）

坑	症状	解法
数 HTML 属性时不能去标签	`grep_count` 数 `class="figcap"` 永远得 0（属性被去标签操作剥掉了）——若不测就交付，等于声称了一个永远失效的检查	数结构标记必须 `strip_tags = false`；`grep_zero` 反之默认扫原始文本
废弃清单不能跨件裸套	把「图」的废弃清单套到「正文」，`不设上限` 报 FAIL，查上下文发现正文里"这条不设上限"是合法用法 → false positive	清单逐件定制，匹配串带足上下文（用「罚款不设上限」而非「不设上限」）
被禁词会出现在否定句里	「四律」裸词扫 XCGS 命中 3 处，逐条看全是"年审是循环，不是第四律"——恰恰是发布口径要求强调的写法。同类误报两轮内出现两次	用 `ignore_patterns = ["不是第四律","而非第四律"]`；必须双向测（该豁免的豁免 + 真残留照抓），否则豁免会退化成"一键放行"
源码里有 ≠ 读者看得见（2026-10-11 实证翻车）	知乎粘贴版把标题只写在 `<head><title>`——标签页标题在预览/粘贴时不可见，交付了 5 篇"没题目"的文章，用户一眼识破。门禁 21 项全绿照样漏，因为检查清单里根本没有"可见标题"这一项	① 新增 `visible_heading` 检查（只认 `<h1>~<h6>` 非空或黄框大字样式，`<head><title>` 不算）；② 每个项目门禁配置必须含标题断言；③ 交付前必须做读者视角渲染自检（见下）

教训：验证者一旦误报，它的否决结论就没人信了（有部署实测：规则一致率 98.58% 但阻断精度仅 0.39%）。误报比漏报更能摧毁门禁的可信度——每次误报都要回头修清单，并把该案例写进配置注释。

写全新门禁时：先造「合规样本 + 植入错误样本」跑 --selftest，确认植入错误全部命中且 0 例 false accept，再拿去跑真实交付件。

🔴 交付前「读者视角渲染自检」（2026-10-11 立，硬性步骤不可跳）

背景：2026-10-11 知乎系列 5 篇交付时门禁 21/21 全绿，但用户打开预览发现"连题目都没有"——标题只在 <head><title>。根因有两层：

检查清单缺项（"可见标题"不在门禁里）→ 已修：visible_heading 检查 + 项目配置标题断言；
交付前没有任何人"以读者身份打开看过" → 工具再全也代替不了这一步。

硬性步骤（每篇交付稿必做，写进收尾清单）：

用浏览器/预览面板打开渲染结果（不是看源码），以读者视角过一遍：题目可见 → 正文结构完整 → 配图占位清晰 → 署名/许可在 → 无黄框残留风险点；
模型自己看不了渲染图时，必须把渲染截图挂给用户或做 DOM 级可见性断言，不许只说"源码里有"；
每次漏检被用户抓到，24h 内回写本清单 + 回修工具（本次案例 → visible_heading + 本节）；
记住不对称：门禁查的是"配置过的项"，清单外的问题门禁永远查不出来——所以"读者视角过一遍"不是仪式，是唯一能发现"未配置问题"的兜底层。

⚠️ 已知环境坑（2026-10-11 实测）：在沙箱环境下，--selftest 可能连带父进程被整树硬杀（无堆栈、exit 1）——疑似沙箱对特定组合的看门狗行为，真机不受影响。沙箱内验证新检查的替代法：直接跑真实门禁（已证稳定）+ 单独写最小复现脚本验证。

🔴🔴 L2 独立验证 + 「措辞强度」三件套（2026-10-06 首次实跑后确立）

L1（上面的门禁）只管"一致性"，永远抓不到一类问题：措辞比证据说得更满。 这类问题必须靠 L2 独立验证者——但它必须满足信息隔离，否则只是把问题包一层。

怎么起 L2（可复用）

✅ 给它	❌ 不给它
原子化断言（一句话一条，编号）	稿件的行文、论证、结构、结论
「默认立场是怀疑」的明令	作者立场、稿件主题、预期答案
要求输出「一手源 URL + 逐字原文片段」	我已核到的依据（会给它带偏）

三条硬规则写进指令：①每条先找矛盾证据；②找不到一手源必须判 无法证实，不得因"符合常识／多处转载一致"判支持；③二手一致 ≠ 一手证实，是二手就要注明。

⚠️ 关键限制（实测）：模型路由别名（lite/reasoning）不保证跨厂商。 [实测] 用 model:"reasoning" 起的验证者自报 deepseek-v4.1-flash，与生产者同族。 → 要真跨厂商，只能靠用户手动切模型后重跑，或接外部 API（需授权）。 → 不得把"用了 reasoning 路由"当成"跨族验证"来声称。

🔒 抽验纪律：验证者的锚点我自己必须再抽验（否则＝用一个不可靠判官检验另一个不可靠产出）。 [实测] 本次抽 3 条全中；其中 1 个疑似幻觉信号（同一标准两个页面 id）查证后是真页面—— std.samr.gov.cn 的「国家标准计划」页与「国家标准项目」页本就是两个不同页面。疑似幻觉也必须查实再定性。

🔴 抽验已升级为「机器全量校验」——anchor_verify.py（2026-10-06 建，正本在工具区）

手抽 3 条不够。换模型解决不了"验证者不独立"，但"换掉信任判官"可以：把 L2 的判断力降级为「找锚点」，再把「锚点真不真」交给确定性检查。

bash

PY="$HOME/.workbuddy/binaries/python/versions/3.13.12/python.exe"
S="$HOME/.workbuddy/tools/anchor_verify.py"
"$PY" "$S" --selftest                                     # 先证明它会抓错（7 项）
"$PY" "$S" --anchors anchors-xxx.json --json report.json   # 再信它

输入：把 L2 输出结构化成 {id, verdict, url, quotes[]} 的 JSON（quote 必须逐字抄）。三态：HIT / MISS（引用不实）/ UNABLE（反爬·超时·PDF）→ UNABLE 绝不等于通过。 [实测] 首次实跑 55 条引用 → 命中 49、实质不实 0、未核 5。

🔒 网络与隐私行为披露（2026-10-11 增，安全审计口径）

delivery_guard.py：纯本地组件，零网络请求，只读写用户显式指定的路径。
anchor_verify.py：本技能唯一联网组件——只向操作者锚点清单里逐条列出的 URL 发 GET 请求（唯一目的：核对逐字引用真伪）；限流（--delay 默认 0.6s）+ 超时（--timeout 默认 45s）；无遥测、无埋点、不上传任何数据、不携带任何凭证/cookie/账号元数据；结果只写操作者指定的本地文件。
本技能不发帖、不代登录、不存储账号凭证（知乎无发文 API，自动化发文违反平台协议——见发布通道红线）。正文的「账号事实」核对（如显示名反查）只读取本地检索返回的元数据，不回传任何信息。

它的能力边界（必须记住，否则会把技术性误判当成"验证者编造"）：

JS 动态渲染页核不了 → 只在 MISS 时提示"疑似动态渲染，须人工确认"，不直接判为引用不实
反爬站点（如 iso.org 403）无解 → 换抓取通道（WebFetch 能过）
网络不可达（如 eur-lex 在本环境 120s 超时）→ 硬约束，只能标未核
只核引用真伪，不核断言真假——引用存在 ≠ 能支撑结论

新认识：锚点除了"真不真"，还有"合不合格"。 实测反例：L2 引了一个 JS 动态页，并把页面上的「2026年5月22日 / GB/Z 185」改写成「2026-05-22 / GB/Z 185.1-2026」。结论没错，但格式被自己改写 + 内容靠 JS 加载 = 锚点不合格。 → 给 L2 下指令时必须写明「逐字照录，不得做规范化改写」。

「措辞强度」三件套（本次 L2 抓出的 3 处，全部是这类）

#	类型	症状	下稿强制写法
1	溯源链强度	稿中"最高法院曾明确…没有版权"，真实链条是市监总局官方解读转述最高法解释，最高法原文未逐字出现	转述的转述必须标出中间层级：「据 XX 的官方解读，……曾有解释提出……」
2	法律前提漏标	条例里"情节严重的，责令停产停业…，对责任人员没收…并处…，10 年内禁止…"——前提管着整串；稿件拆成两句时第二串没重申前提，断章取义会读成无条件适用	长条款被拆句时，共同前提必须在每串前重申：「同样是在情节严重的条件下，还要追到具体的人……」
3	口径并存未披露	充电宝强标一手库记 `2026-03-31`（发布日）、媒体记 `2026-04-03`（公开发布日），两者都对但读者只查一手库会看到另一个	同一事实有两个官方口径时：明确择一并写进核实报告，公共稿只用一个（不混用），缺口归档

三类共同点：事实没错，一致性没坏，只是比证据说得更满。这就是为什么"再仔细看一遍"永远发现不了——它不是靠注意力能筛出来的，要靠独立视角 + 明确的追问方向。

L2 的价值形态（与 L1 的分工）

L1 抓"不一致" —— 计数、字节、像素、图↔文不同步
L2 抓"强度过头" —— 溯源链、法律前提、口径并存
两者都会独立复现对方的结论 —— 当两个独立过程得出同一判断，该判断可信度显著上升（本次：ISO/IEC 42001 "38 项控制"的降级判断被 L2 独立复现）

知乎平台核实过的事实（2026-09-27 溯源，多来源一致）

事实	结论
个人发文 API	❌ 无。开放平台仅只读接口，发布接口仅内测。任何"API 发知乎"均不可行
浏览器自动化发文	🔴 违反知乎《用户协议》（禁止自动化访问），登录态有 ZSE-96 签名、≤4h 过期，有封号风险，默认不推荐。除非用户明确点头并知悉风险
HTML 富文本粘贴	✅ 可行，本 skill 的标准发布方式
Markdown 直接粘贴	⚠️ 不稳，会乱排版

知识更新

平台规则会变。每次执行本 skill 时，若距上次核实超过 3 个月，先重新搜索核实"知乎发文 API / 编辑器粘贴"再动笔。

选题侦察（第 1 步的标准动作，别空想题目）

用知乎 CLI（~/AppData/Local/ZhihuCLI/current/zhihu-cli.exe，在 Bash 里调，PowerShell 捕获 stdout 为空）：

bash

ZH="$HOME/AppData/Local/ZhihuCLI/current/zhihu-cli.exe"
"$ZH" question recommend --query "<领域关键词>" --count 8   # 探候选问题
"$ZH" question answers --question-url "<URL>" --limit 10    # 看站内现状（⚠️ 只认 --limit，--count 报错）
"$ZH" hot                                                  # 找时效钩子
"$ZH" me contents --limit 10                                # ⚠️ 索引滞后约 11 天（09-29 实测最新只到 09-18），**不能判"发没发"**

🔴 判"线上发没发"只能用 question answers 反查作者。me contents / me content 对近期内容一律滞后或返回 content is unavailable，据此判定"未发布"会误判（09-29 真实事故：把一份已挂 4 赞的旧稿当成待发件重新包装）。

🔴 侦察纪律：先过滤，再进上下文（2026-09-29 确立，省积分）

question answers 一次可返 30 条回答摘要，全灌进上下文 ≈ 6000 字，而这些字之后每一轮都要重新计费。多数时候你只想判"有没有我方回答"——grep -i "<账号名>" 命中一行就够。

规则：命令输出先在管道里过滤（grep / jq 选字段 / head），只把命中项或字段子集拿进上下文。同一张图不重复读；一条命令做多件事；能用 WebFetch 精准抓一个源就别 WebSearch 撒网。

选点四原则：①先查我方是否已答过该题（防同题内耗）②站内回答里是否缺"框架级解读"（有空档才值得写）③是否有时间钩子（截止日期、听证会、发布日）④是否有整整一类叙事没人占（09-29 选中"企业部署值不值"题，就是因为 20+ 条回答全在"算账"，零条讲"上线闸门"）。

出图管线（可选，回答带图完读率更高）

🔴 硬性排版下限（2026-09-29 用户反馈"字多、字太小"后确立）

用户原话：「图片字多，且字太小了」。此后出图必须先过这三条，不达标就重做：

项	下限
正文字号	≥ 20 CSS px
说明/脚注字号	≥ 16 CSS px
标题字号	≥ 42 CSS px

⚠️ 这套下限以「设计宽 = 1120 CSS px」为基准，换 viewBox 必须换算，别直接套。 换算公式：最终显示字号 ≈ 字号 ÷ 设计宽 × 知乎显示宽(≈690)。 1120 基准下的 20px → 显示约 12.3px；同样效果在 680 宽的 viewBox 里只需 12–13px（2026-09-29 医疗线两图即按 680 基准做：正文 12–13、盒标题 14.5、标题 17，实测显示效果达标）。 最坑的错觉是"把 PNG 做到 1200/2240 宽就够清晰"——知乎把图压到约 690px 显示，像素再多也不改变字号大小，唯一有效的手段是提高字号 ÷ viewBox 宽这个比值。 改完必须渲染后目视：长图缩略态看不出字号是否偏小，要按区段裁切放大看（PIL crop 后 Read）。 | 单张图文字总量 | ≤ 120 个汉字（不含标题、脚注、数据来源） | | 单卡片正文 | ≤ 30 个汉字 | | 时间线单节点 | ≤ 6 个汉字 × 2 行 |

宁可拆成多张，也不要把信息塞进一张。 一次内容多张图是正常的（本次 4 张：密度对比 / 时间线 / 三个断点 / 两方对照），每张只讲一件事。

🔴 封面规范（2026-09-29 确立）

文章必须单独出一张封面，不要拿内文图凑（内文图有标题行/来源行，裁成宽扁封面会被切，且与文章标题语义重复）。

构型铁律：核心信息横向铺开 + 垂直居中 + 上下留大面积可裁区。

原因是知乎封面在不同位置被裁成不同比例，网上流传的口径就有三种（690×260 = 2.65:1 ／ 800×450 = 16:9 ／ 1200×675 = 16:9），与其猜比例，不如让构图对任意比例都安全。

项	规范
画布	1120×630 CSS px（@2x = 2240×1260）
核心区位置	垂直居中，总高控制在 ±85px 内（即中央 170px 带）——这样裁到 2.65:1（保留 423px）、16:9、1:1 都切不到
核心区宽度	收在画面中央 ~55% 内，兼顾 1:1 方形裁（左右各裁 22%）
可裁区	顶部 kicker、底部来源/署名行——被裁掉不影响信息
内容量	只讲一件事，字号比内文图再放大一档（主数字 ≥100 CSS px），缩到信息流小图仍认得出

交付时必须做的验证（一步不能省）：写出封面后，另做一张「裁剪安全性验证图」——把同一张封面用 CSS 偏移模拟 2.65:1 / 16:9 / 1:1 三种裁切并排渲染，逐格 Read 目视确认主体在三种框内均完整。验证图存 assets/_cover-test/，并在执行单里明确写"此图勿当封面传"。

上传提示写进执行单：裁剪框拉到最大；若比例固定则居中即可。另需提醒：不手动设封面时，知乎会自动抓正文第一张图当封面。

🔴 封面构型补强（2026-10-05 实战，比"核心区 ±85px"更好落地）

上一版把"核心区垂直居中、控制在中央 170px 带"当作铁律，实操中一块标题+副标往往就是 280px 高，塞不进 170px。更实用的两条：

核心信息只要落在"中央 423px 高"带内就安全（2.65:1 裁切会保留中央 423px），不必强求 170px。文字块 280–300px 高完全没问题。
装饰元素做"左右对称 + 落在中央 630px 之外"——即把图形（竖条/栅栏/纹理）放在 x<245 与 x>875 两侧，且左右严格镜像。这样：2.65:1 与 16:9 能看到完整装饰；1:1 方形裁切时两侧被对称裁掉，只剩居中纯文字，构图不歪、也不显残缺。比"把图形挤进安全区"可靠得多。
别让装饰在某一侧（如只在右边放一组图形）——1:1 裁切会把单侧图形切掉一半，看起来像坏了。

🔴 裁切验证页的两个坑（2026-10-05 实际翻车）

必须用 background-size:cover 模拟裁切，不能写死像素。 本例误写 background-size:365px 365px，结果 1:1 方框里显示的是整张封面被非等比拉伸（横向 0.326×、纵向 0.586×），竖条根本没被裁掉，标题被压瘦——而框下文案却写着"两侧装饰已被裁掉"，图文自相矛盾，验证彻底失效。cover + 固定方块 = 等比缩放后居中裁切，才是真实模型。
验证页自身的内容高度必须留足。 本例第一版页面高 2360，而 1:1 预览框下沿需 2684 → "验证裁切的页面自己先被裁了"。截图后务必用 PIL 检查内容底边是否触及窗口高度（触及 = 被静默裁切）。
顺手做掉的两件事：每个预览框下加 ✅/❌ 状态标记；标注清"16:9 与画布同比例、不发生裁切"，别把"比例校验"写成"裁切"。

🔴🔴 配色默认「浅色系」——含封面，一律浅底深字（2026-10-06 用户定）

规则：所有配图（封面 + 内文图）默认浅色系，浅底深字。禁止深色/深蓝底大色块。 用户原话：「图片要用浅色系的」。此前封面误用了深蓝底，已整体返工。

理由（不是审美，是可用性）：

阅读环境是白底——知乎正文与信息流都是白底，浅色图与之同温、不割裂；深底图在信息流里像贴了块深色砖。
转发/长截图/暗色模式下不会出现"白字消失"。
与正文排版同源——知乎正文本就是深字浅底，配图沿用同一套色即天然像"文中之物"。

落地口径（本套定稿值，可直接复用）

元素	值
页底	`#F4F7FD`
卡片	`#FFFFFF` + 边框 `#E3E8F0`
主色（标题/强调文字）	`#0A2A5E` 深海军蓝
强调色（全系列唯一红）	`#C8102E` 正红
辅色	`#2E6BC4`
次要文字	`#41546E`
标注 / 页脚署名	`#5A6B85`
浅色底块（如三列中的"主列"）	`#DCE9FB` + 边框 `#8AB6E6`
提示条	底 `#FFF6F7` + 左边界 `#C8102E`
封面底	`radial-gradient(1180px 680px at 50% 24%, #FFFFFF 0%, #F3F7FD 52%, #E6EFFA 100%)`
装饰件（竖条/栅栏）	`linear-gradient(180deg,#A9CBEE,#6E9FDC)`，`opacity:.68`

浅色系的两个专属陷阱（深色系不会遇到，务必检查）

浅色封面在白色信息流里会"消失"——四角与 #FFFFFF 对比只有 1.05:1，读者看不出那是一条封面。必须补边界，且只能用「全框」：
css
```
body::after{content:"";position:absolute;left:0;top:0;right:0;bottom:0;
            border:3px solid #6E9FDC;pointer-events:none;z-index:4;}
```
⚠️ 不要用"底部横条"（本例第一版做法，已被证伪）：2.65:1 是居中横裁，会把上下各约 104px 整段裁掉，底条根本不在信息流预览里，等于没做。全框的妙处：2.65:1 横裁留左右竖边、1:1 方裁留上下横边——任何裁切比例下都至少保留一对边。#6E9FDC 对白底约 2.75:1，边界可辨又不抢戏（#8AB6E6 只有 2.12:1，偏淡）。 边框粗细按"最窄展示宽度"定：封面会缩到信息流约 690px（0.616×）。2px 设计值缩下来只剩 1.23px，发丝级几乎看不出 → 用 3px（缩后约 1.85px，主图上是干净细框，信息流里边界可辨）。推论：凡靠"边缘位置"起作用的元素（边框/底条/贴边装饰），设计时必须先过一遍裁切模型——"它在 2.65:1 和 1:1 下还在吗"，再按最窄展示宽度反推粗细/对比度。
装饰件会淡到看不见——低饱和淡蓝叠在浅底上，对比可能只有 1.2:1。设计时先算合成色：装饰件与底的对比要 ≥1.5:1。本例 #BBD5F2→#8AB6E6 @0.55 只有 1.35:1（缩到手机宽基本糊掉），改成 #A9CBEE→#6E9FDC @0.68 才到约 1.7:1。
居中标题会被全角标点"推"到左边——中文标题行尾常是「，」「。」「？」，它们字身框右侧有大段留白，而 text-align:center 是按字身框对齐的，于是墨迹整体左偏（本例 −33～−43 设备px ＝ 0.25～0.32em），肉眼能看出"整块偏左"。判据：只有标题偏、其他元素（眉题/分隔线/副标题）都精确居中时，这个偏差最刺眼（本例其余元素墨迹中心在 1118–1121，唯独标题 1077/1087）。解法：给标题整体做光学补偿 —— h1{transform:translateX(20px)}（≈0.30em；0.2em 只回收 2/3，不够）。别用 padding-left：容器度量被缩窄后只会位移一半。补偿后本例实测两行墨迹中心回到中轴 −3 / +7 设备px。顺带：若某段文字首字是全角左括号（如「），左缘也会多出留白 → 用 text-indent:-.6em 之类的负缩进光学对齐（-.25em 往往不够，本例实测要 -.6em）。

主次不能靠"深色块"拉。 浅色系里原本靠深底立主角的列（如三列对照的中列），改浅后色彩权重会掉。用四条叠加补回来（不破坏浅色系）：填充 #DCE9FB + 边框加到 2px #8AB6E6 + 顶部 6px #0A2A5E 实心条 + 柔和阴影 0 10px 30px rgba(10,42,94,.10)，再让该列略宽于邻列。实测即可恢复到"一眼看出是主角"。

顺手一条：若某列标题写"8 项"，列内就必须能数出 8 行。本例曾把 8 项压成 6 行（两行各塞 2 项），读者会数成 6 条、判定你写错。宁可缩字号/减行距也要逐行摊开。

🔴 系列一致性硬指标（多图必查，2026-10-05 复盘）

一次出 3+ 张图时，用同一套数值，否则一眼看出不是一套：

项	规则
灰阶	全系列最多 2 种（次要文字 `#41546E` / 标注 `#5A6B85`）
红色	单一正红 `#C8102E`，全系列唯一。同一张图内不得出现第二种红（含底条文字色、节点色）
底色	全系列浅色系（见上节），禁止任何深底大色块
卡片内边距	统一（如 28px），跨文件一致
卡片间距	统一（如 24px）
提示条左边界色	全系列同一个色（本例 fig4 误用辅蓝，与 fig2/fig3 的红不一致）
页脚署名	字号/字色/距底边逐像素一致
引号	中文内容一律用 “ ” 或「」，禁止英文直引号 `"`（见下）

🔴 中文引号纪律（2026-10-05 补）

在 .md 与 .html 的可见文本里，中文引号必须写成 “ ” 或「」，不得用 ASCII 直引号 "。直引号粘进知乎后看着像代码，专业读者一眼看出是机器产出。

🔴 2026-10-06 存量扫描实测教训：对已发布的 XCGS 两篇稿做机器统计 —— 可见文本里 ASCII 双引号 54 个（27 组）、中文引号 0 个（文章 32/9 行、回答 22/7 行）。而同期的《强制国标》包是中文引号 42/42、正文 ASCII 直引号 0。 两篇稿子做法完全不同 → 说明那不是个别漏网，是整体没走这条规范。 为什么当时没发现：这条纪律只存在脑子里、不在任何可执行检查里。 → 已把 cjk-quotes 做成 zhihu.toml 里的 blocking 检查（no_ascii_quote）。 教训：规矩要尽量降到可执行检查那一层 —— 注意力会漏，脚本不会。

交付前逐件 grep 复查：grep -o '>[^<>]*"[^<>]*<' *.html（HTML 可见文本）；md 里直接搜 "。
批量转换脚本要点：先把 HTML 属性 ="..." 保护起来（临时替换引号字符），否则会把 class="figcap" 一起改掉。转换后校验替换次数为偶数（成对）。
同一交付包内引号体系要统一：封面用「」就全用「」，别封面「」、内文 “ ”。

🔴 出图后必跑的 4 项机器自检（补 PIL 复核）

内容是否被静默裁切：扫内容底边，若 bot >= 窗口高 - 20 说明超出被切，加高窗口重出。
图片是否被拉伸：对比实际输出宽高与设计宽高 ×2，比例不符即为拉伸。
最弱对比度：抽样页脚/标注文字的像素色，与底色算对比度，低于 4.5:1 就加深（本例三张图的页脚原为 #8593AA，仅 2.9:1，统一改 #5A6B85 后达 5.0:1）。
色系是否真为浅色系（2026-10-06 补）：转灰度统计，三项全过才算浅色系——平均亮度 > 180、暗像素(v<100) 占比 < 15%、亮像素(v>200) 占比 > 60%。本例五张定稿值：avgLum 233.9–239.0、暗像素 3.7–5.7%、亮像素 92.9–95.5%；数值越接近，越证明"像一套"，可作为系列一致性的量化证据。

🔴 交付前必跑的「文章 ↔ 配图」双向同步核对（2026-10-06 新增）

图是压缩摘要，最容易出现四种"看着都对、一比就错"的不同步。必须在交付前做双向核对，不能只做视觉复核。

类型	表现	本例
① 计数不一致	标题/副标写"N 条"，正文与图写"M 条"	标题与封面副标写"三条法律后果"，正文第一节与 fig2 都写"四件事"
② 归组方式不同（最隐蔽）	数量都是 4，但分法不同，逐项一比全对不上	正文四件＝禁/罚/信用公示/公示无标准；fig2 四卡＝禁/罚/追到人/信用公示
③ 图里有、文里无	图内断言的数字/枚举正文无支撑，读者回正文找不到依据	fig3 写"过渡期须论证三件事"、fig2 写"技术要求全部强制"，正文均未提
④ 图用经验值、文用官方口径	图写了"通常/一般"这类概括，与官方明确的"无法统一规定"冲突	fig3 写"过渡期通常留 1 年左右"

处理原则：同步不是把图抄一遍，而是"先把事实/法律口径统一，再让图和文都服从它"。 本例最有价值的修正不是改数字，是改归组——第 38 条的构成要件是"未公开其执行的标准"，与第 25/33/34/37 条的"不符合强制性标准"不是同一个触发点，因此它不该与前者并列成"四件"，应单独归入"独立规则"。这类错误比你写错一个数字更伤：专业读者一读就知道你没读原文。

机械核对脚本思路（去标签 + 去空白归一化后做双向 in 检查）：

图 → 文：把每张图的可见文字拆成断言清单（数字、日期、法条号、枚举项），逐条断言正文中必须存在。
文 → 图：正文的枚举项数必须等于图上的卡片数/行数（标题说"8 项"就得能数出 8 行）。
反向查残留：对已废弃表述建 stale 清单（旧数字、旧措辞），grep 图源 html 确认0 命中——改文不忘改图是本类任务的最高频事故。
归一化时注意：–/-、到/–、全角/半角、·/、 的差异会造成假阳性，需人工判读"是压缩表述差异还是有实质不同"。

渲染步骤

写图源 HTML：body{width:1120px;height:Npx;overflow:hidden;}，配色用内联 style（nth-child 会把表头算进去，多行配色易错）；浅色主题白底深字。
文件名一律用 ASCII（fig1-density.html），避免中文名 + 空格在 URL 里出问题。
中文路径先 cp 到 ASCII 临时目录（如 /d/Workbuddy/_tmpfig2/）再截图。
截图："/c/Program Files/Google/Chrome/Application/chrome.exe" --headless=new --disable-gpu --hide-scrollbars --default-background-color=FFFFFFFF --force-device-scale-factor=2 --window-size=1120,N --screenshot="D:\\...\\figN.png" "file:///D:/.../figN.html"
🔴 必须逐张 Read 目视复核，重点看底部有没有被裁。经验：内容视觉高度 ≈ 图高 × 0.85 时最合适；本次 4 张里 3 张的页脚第一遍就被裁掉了，加 50–90px 高度后重出才对。
被替换的旧图移入 assets/_superseded/，不要留在同级目录（fig2-breaks.png 这类重名会造成后续拿错图）。

🔴 PIL 直接矢量出图管线（Chrome 截图通道不可用时的替代路径，2026-10-07 实战确立）

当本机无 Chrome 截图通道（无 playwright/imgkit，或 Bash/PowerShell 通道异常）时，改用 PIL 直接矢量绘制生成信息图——已 5 轮打磨，可复用。

核心技巧

2× 原生输出（比 1× LANCZOS 放大更锐利）：用 SC=2 + px(v)=int(v*SC) 包裹所有坐标/字号/线宽，Image.new(px(W), px(H)) 直接出 2 倍图。内文 680 逻辑宽→1360px；封面 1120×630→2240×1260。delivery_guard 的 png_size 检查要求 2×，1× 会判 FAIL。
字体：本机 C:/Windows/Fonts/msyh.ttc(常规) / msyhbd.ttc(粗)；DengXian 等线可作正文、Segoe UI Light 作品牌字（须指定字体文件，非系统默认）。
🔴 彩色 emoji / ✓ ✅ 必变豆腐块（tofu） → 一律用 draw.line 手绘对勾/叉，不依赖字体 glyph（与 9-30「Pillow 不支持彩色 emoji」同源坑，跨任务通用）。
🔴🔴 品牌字标（wordmark）必查字距，机器自检查不出来（2026-10-07 实战血的教训）：技术自检（tofu/尺寸/亮度/字形齐备/越界）全 PASS 也可能字标很难看——主观设计项必须单独查。
- 典型翻车：tracking_em=0.14 过松散；且 for s in ((MAIN,col),(ACCENT,col)) 两段循环间，第一段尾字距 + 第二段头字距形成双倍空隙，把 logo 割成两截 → 用户观感"公司字体不对"，但字体文件其实完全正确。
- 正确做法：字标用「字距 tracking + 段间隙 gap」两个独立参数，段间先 cx -= track 再 + gap，消除双倍空隙。推荐值：品牌全大写 tracking 0.04~0.05em、gap 0.06~0.08em。
- 必跑的字标视觉回归（转成可量化指标才叫查过，参考实现 _product/_wordmark_check.py）：① 总宽/字号 ∈ [6.0, 9.0]（过松=发散/过挤=粘连）；② 段间隙/字母间距 ∈ [0.8, 2.2]（>2.2 必断裂，此项真能抓到问题）；③ 与实际渲染 bbox 一致性；④ 无缺字兜底。
- 取证顺序（别瞎猜）：先查字体文件是否就位 + cmap 是否缺字 → 再查代码 font() 是否真走到目标字体（打印 _bk_face/path/get_variation_axes）→ 最后把真实渲染与候选字体并排放大目视。⚠️ 肉眼也可能误判（我曾把 Sora 看成 Inter）；NCC 互相关/IoU 在裁剪框没对位时会全负值不可靠——并排放大目视才是判定定论。
移动端字号反向放大（one-pager 实战）：知乎显示宽≈690px，2× 图在手机约 0.48× 缩放。逻辑字号须按「显示端 ≈ 字号 ÷ 逻辑宽 × 690」反推——one-pager 用 W=720 逻辑×2=1440 原始、正文 33px→显示约 16px 才达标。前几轮忽略此点导致手机实字仅 4–5px，第 3–4 轮才修正。
🔴 主观设计项 ≠ 技术自检能覆盖：用户说"看着不对/不高级/字体不对"时，先取证定性（放大目视 + 并排比对）再改，禁止猜着改。技术 PASS 不等于设计合格——这条是本 skill 最大的盲区补强。
🔴 Canvas.t() 的 anchor 语义（brand_kit 踩坑，2026-10-07）：水平 l=左对齐 / m=水平居中 / r=右对齐；垂直 t=顶 / m=垂直居中 / s=基线。anchor='ls' 是"左对齐+基线"，不是居中！ 想居中必须写 'ms'。踩坑实录：圈子背景图用 'ls' 导致整块文字从中心点往右偏、左半边大片空白，返工一轮才改对。任何"居中构图"都要先确认锚点。
🔴 知乎圈子禁外链 → 互动机制必须站内化（2026-10-07 战略级教训）：圈子铁律禁外链（《规范》四·禁导流 / 一·37 禁联系方式变体），所以任何本地工具/自测器/外部资源在圈里都点不到。若规划了"30秒参与"之类互动，必须把该动作的价值用知乎原生形态重做（如"逐条勾选"→"每周发3条焦点准则+评论回A/B/C，楼主手工汇总成进度条图"），否则没有可执行参与动作的圈子=空壳，冷启动必失败。本地 HTML 自测器只做自用/熟人手动发，绝不作为链接发圈。

与门禁协同（必记）

gen_images.py / gen_promo.py 的运行日志务必写到交付目录之外（如 gen_out.txt 落目录外）——否则 coverage 报"多 1 文件"假 FAIL。
png_lightness 的 max_dark_ratio=0.15 很敏感：放大字号后深色结论块变大易超阈 → 缩小深色块 + 增大画布留白（实测 dark 15.4%→12.7% 即回落）。
text_present 只校验文章正文含关键短语，图内加字安全（不改尺寸、不删原断言）。
coverage 只豁免 _ 开头或含 /_ 的路径 → 旧图源/临时脚本统一挪进 assets/_legacy-html/、_scratch/。

配图形式选型（2026-10-07 调研结论）：对比 / 流程 / 层级 / 配对四类最强（信息图首选）；雷达图弃用（面积随轴序变、平方放大、>2–3 系列不可读）→ 改用「五维缺口表」或分组柱状图；深色英雄图仅社媒专用、不进知乎正文（且不在扁平 *.png 浅色门禁匹配内）。

口径纪律（溯源核实的执行细节）

多来源数字不一致时并列不混用，例：路透"超 1.5 万次编辑" vs 研究者重建"约 1.8 万条"，写成"约 1.8 万条（路透口径为超过 1.5 万次编辑）"。
匿名信源必须带限定语（"据路透引述消息人士"），并同段给出当事方否认口径。
若发现中方官方口径（如国安部提示、网安标委文件），在中国平台要优先用上——既有权威性又贴合本土语境。
🔴 多解读"计数"冲突时，公共稿不引任何具体数字（2026-10-05 实战补强）。 同一份文件的不同解读常给不同的"细类/项数"计数，分母基准不同（例：框架3.0 有解读记"12细类36项"、另一记"14类51项"；某标准有解读记"约20项"、另一记"约36项"）。公共稿件一律不 assert 任一具体计数，改用结构事实描述（"风险分类进一步细化、细类持续扩充""首次单列：智能体·具身智能·冲击网络安全风险"），把"计数口径冲突"作为内部说明保留在 03-发布指引.md / 04-事实核实报告.md 里。凡遇到"X类Y项"类断言，先在核实表里标"⚠️ 口径冲突，不自称官方"，再决定引用方式——公共稿只引结构事实，数字留给内部件。 这同时是 ⑥ 条"口径一致性自检"的延伸：冲突数字进了公共稿，读者一比就判你错。
发布时间敏感的钩子（如意见截止日）要在自查清单里列一条"发布前复查是否仍有效"。

🔴 回答交付标准包（2026-09-29 用户定；此后所有知乎回答默认按此交付）

用户原话：「这种方式很好，后续回答问题的都这种方式给我」——指的是 2026-09-29《OpenAI 智能体劫持德国 wiki》那条回答的交付形态。此后每条回答都产这一整套，不用问、不用等他提。

一套 5 件：

#	产出	文件	作用
1	源稿	`02-回答-<问题>_SynomosAI.md`	内部改稿用
2	粘贴版	`02-回答-<问题>-粘贴版.html`	复制源：正文 + 内嵌图注行 + 顶部黄框
3	发布执行单	`05-发布执行单-回答.html`	对位点用（含红条提示，不可用于复制）
4	配图	`assets/figN-*.png` + 图源 `.html`	2240px 宽（1120 CSS px × 2 倍）
5	图注	已写进粘贴版正文对应位置	见下条规则

图注与插图位置的唯一规则

图片插在对应「图注行」的上方。图注 = 正文里那行灰色小字；找到它，图插它上面，别删别改。

图注只写「读图该看出什么」+ 数据来源与出处日期；不写"制图 SynomosAI™"（每张图内部页脚已有，重复即冗余）。

🔴🔴 图号 ≠ 文件名：两套编号体系必须显式对齐（2026-10-05 实际翻车）

症状：图注按正文出现顺序编（图1、图2…），文件名按全库创建顺序编（fig1-lifecycle、fig4-gui-vs-api…）。两套体系撞车 → 张冠李戴，插错图。

真实案例：对题版回答里「图1」写的是 GUI vs API，实际文件是 fig4-gui-vs-api.png；「图2」是五方面vs 九阶段，实际是 fig5-mapping.png。若按图注去取fig1-*.png，会插进完全不相干的「九阶段×七组措施」图。同一目录下还有另一篇稿的 fig1/fig2/fig3（自洽的另一套），极易混淆。

铁律：

一对多稿的项目，图注里必须同时写文件名，不能只写图号。格式：[插图位置 1 → assets/fig4-gui-vs-api.png｜读图该看出什么]。
顶部黄框的插图对照必须点名"勿按文件名猜"，并把「图号 ≠ 文件名」的错配显式写出（如「插图位置 1 = fig4-gui-vs-api.png（不是 fig1）」）。用户是照着图注操作的，不提示就会插错。
一稿多图时，不要跨稿复用图号。01/02 与 02b 是两篇稿，各自图号独立；检查时须确认「图号 ↔ 文件名」映射在每篇稿内各自成立。
md 源稿与粘贴版必须同步。本次md 源稿图2 注仍是旧图说明（fig1-lifecycle），粘贴版已改成新图（fig5-mapping）——源稿与交付件不一致，等于交付了错内容。改图注必须同时改两处，且用 Grep 逐件核，不靠印象。

交付前必跑校验（写完 Bash 一次即可）：

bash

grep -n "^\[图" 源稿.md; grep -n "figcap" 粘贴版.html   # 两处指向是否一致
for f in <每个被指到的文件>; do [ -f "assets/$f" ] && echo "[OK] $f"; done

反向自查：若发现「图注指向的文件名」与「图注描述的内容」不符，一律按描述为准、文件名存疑——因为图注描述是作者意图，文件名只是历史遗留。

🔴🔴 每张配图都必须有对位点：粘贴版 figcap 数 = 配图数

症状：粘贴版 HTML 里 class="figcap" 数量为 0，但配图有 3 张 → 用户在编辑器里没有插入位点，只能凭感觉插，或干脆不插。

铁律：

一稿多图时，每张图都要有一个独立 figcap 行，位置放在「引出该图的那句话」之后。封面不占figcap。

交付前必跑计数校验：

bash

grep -c 'class="figcap"' 粘贴版.html   # 应 == 正文配图数（封面除外）

数量对不上就是漏了，不许交付。

图不要硬塞进不相关稿件。多稿项目里，每张图要绑定到主题真正契合的那一篇：内容切题优先于「图凑齐」。判断方法——看正文有没有引出这张图的那句话：有段落呼应才配图；没有就说明这张图不属于这篇稿。硬塞会稀释重点，读者也看不出图和文的关系。
同类文件的黄框文案未必一致。文章稿有「设封面」步骤、回答稿没有；批量替换前先确认文案真的一致，否则只命中部分文件（本次 01 命中、02 漏，须单独处理）。
图注格式全库统一：[插图位置 N → assets/xxx.png｜读图该看出什么]。不写「文件：」前缀，不留[图N：] 旧格式，同一交付包内不允许两种风格并存。

执行单（05）必须包含的 6 项

一句话说明分工：「粘贴版用来复制，执行单用来对位点」；
逐步操作（Ctrl+A/Ctrl+C → 问题页「写回答」→ Ctrl+V → 删顶部黄框 → 按位点插图 → 加话题 → 发布）；
图注对照表：图号 / 文件名（必写，不能只写图号） / 插在哪 / 锚句（照抄正文原句，便于在编辑器里搜到）；
发布前 30 秒自查（黄框删净、图位对齐、加粗与列表未丢、参考来源与署名在、无真名/公司/客户信息）；
话题建议（提醒在知乎下拉框确认话题存在）；
时效提醒（正文里若有截止日期类钩子，写明剩几天 / 过期需改写）。

发布后必做（回填登记）

用户发布后拿到 URL，立即：

追加登记本地 SynomosAI 权属台账文件（2026-09-20 建档，新增「发布记录 + ContentToken + 本地存证目录 + 逐文件 SHA-256 表」）；
指纹覆盖发布版全套：粘贴版 html、源稿 md、配图 PNG、图源 html；执行单/发布指引/核实报告为内部件，登记时注明「不随发文公开」；
哈希一律现算 sha256sum "<file>" | cut -c1-64，不复制旧值（文件一改哈希即变，复制旧值等于自毁证据）。

验证发布状态的可靠通道（2026-09-29 实测）

me content / me content-stats 对刚发布的回答会返回 content is unavailable（索引延迟），不能据此判断未发布。me contents --type answer 的返回也可能滞后（本次最新只到 9/18，而 9/29 已发布的回答不在列表里）。

可靠的验证是——列出该问题全部回答，找 ContentToken：

bash

"$ZH" question answers --question-url "<问题URL>" --limit 20

命中后取该条的 ContentToken 与 Summary，与终稿开头比对，一致即确认已上线。

更强的一招：用站内搜索反查"这份稿到底在线没有、线上是哪一版"（2026-09-29 实测，推荐首选）

bash

"$ZH" search zhihu --query "<标题里的一句，或稿子里独有的一句>" --count 20

返回项带 AuthorName（实际发布账号名）与 Url，只要命中即证明已上线，且能判断是在哪个问题下、由哪个账号发的。本次靠它查出「医疗线回答其实 09-27 就已发布、跑的还是 v1 旧稿」——me contents 完全没显示（索引滞后），me content --content-url 返回 content is unavailable（抓不到 ≠ 没发）。

配套："$ZH" me contents --type question --limit 30 可列本人发布过的问题（回答/文章同理，--type answer|article），用于回填问题链接、核对账号归属。

🔴 由此确立第 0 条前置动作（2026-09-29 医疗线教训）：接手一份旧稿，第一步不是改文字，而是先确认它的线上状态——「未发 / 已发哪一版」。 本次因为默认了"未发"，把一份已经挂了 4 个赞、还带着事实性硬错的旧稿，重新包装成了"待发件"，等于白做一轮、还差点错过更正窗口。旧稿的"使用说明"里写的发布方式，是当时的意图，不是当时的结局。

🔴 线上更正协议（2026-09-29 因已发布回答数字矛盾确立）

第 0 步（关键）：先判"局部改"到底有没有优势。 很多人第一反应是"只改那几个字最省事"。但如果图也要换（图内文字含错，或图源在核实后重渲过），局部改就要逐处定位 N 处文字 + 逐张换图，而全文重贴只要 1 次粘贴 + N 次传图，且不易漏。→ 图要换 ⇒ 直接走全文替换，别走局部手术。

反向也要判：图基本是对的 ⇒ 走局部改。 判据：改动只集中在正文少数几处，且线上图在内容上仍然成立（差异仅限脚注措辞、字号、留白这类可选项）。此时局部改 = 逐处替换几段文字，图、图注、已积累的赞同全部保住，成本远低于全文替换（后者会清空重建、且会把图注打回你给的模板版）。本次医疗线正是此例：只改 4 处文字 vs 全文替换重传 2 图。两条路线都要写进操作单，并给出推荐与理由。

知乎编辑的三条实测事实

支持编辑已发布回答，会留下「编辑于 YYYY-MM-DD」标记——正常且诚实，不必回避，主动更正比留着矛盾被人抓强；
编辑已发布内容不重新推送关注者，不会造成二次打扰；
🔴 Ctrl+A 清空后，已上传的图会一起丢失，必须重新上传。这是全文替换唯一的成本，操作单里必须显式警告。

三档路径，按代价排序

路径	动作	适用
A · 全文替换（默认推荐）	编辑器 `Ctrl+A` 清空 → 粘粘贴版 HTML 全文 → 删顶部黄框 → 按图注位重传全部配图	改动 >3 处，或配图需换
B · 最小改动	只改硬错那一处文字 + 换最小必要图	仅 1 处硬错，且配图无需换
C · 评论区更正	正文不动，在评论区补一条更正说明	改不动，或错误轻微、不值得动正文

更正操作单必须包含：入口路径（怎么进编辑）→ 每步动作 → 新旧对照表（可直接照改）→ 改完自查 → 两条须知（编辑标记 / 不推送）→ 要复制的文件路径与配图顺序。

线上原文抓不到时怎么办：me content --content-url 对已发布内容常返回 content is unavailable（索引延迟），抓不到 ≠ 没发。此时只能以本地终版稿 + 修订点表反推线上文本，并在操作单里注明「线上原文未能读取，对照表基于本地 vN 稿」。

版本号也是自检位：本次 02-…粘贴版.html 的 <title> 写着 v2、正文黄框写着 v3。凡文件名、<title>、黄框、执行单里出现的版本号，必须一次改全（与 ⑥ 条的"标题也是自检位"同类）。

🔴 已发回答补图 → 评论补图路由（2026-09-30 实战确立）

场景：回答已发布、正文内容成立，但你后来做好的图（信息骨架类，如三律总览 / 门禁分层 / 行为账本）想补进去。

决策（用户 2026-09-30 定）：不走"编辑回答全文替换"，改走"原回答下评论补图"。理由：图是内容骨架、但评论区零风险且可置顶，不动已发正文 = 不触发"编辑于"标记、不清空已积累赞同、不重传全部图。

执行规则

在原回答评论区发 3 条图评（fig1 三律总览 / fig3 分类 / fig4 行为账本，可选第 4 条 fig2），并置顶；
🔴 知乎评论框不认粘贴 img——图必须手动上传（编辑器粘贴 HTML 的图也传不进评论），操作单须写明"评论区图由用户手动上传"；
05-v2 编辑版作废，05c-评论补图执行单生效；发布指引同步改成"评论补图"路径；
与《线上更正协议》路径 C（评论区文字更正）区分：此处是补图，正文不动。

何时用全文替换 vs 评论补图：图要补且正文已成立 → 评论补图（零风险）；图要换且正文也要改 → 仍走路径 A 全文替换（见上）。

🔴 知乎社区运营 · 圈子建设（2026-10-07 实战，溯源核实）

🔴 平台红线（硬约束）：《知乎社区规范》四（2025-01-07）禁止一切导流/营销；一·37 禁「故意夹带二维码、网址、邮箱等联系方式」及谐音变体 → 站外微信群/QQ 群不可作导流目标。外链被改写为 link.zhihu.com 中转 + nofollow → "放来源链接"低风险，"引导离站/留资"的意图高风险。正解＝知乎圈子（盐值≥450 可创建）+ 知识库公开订阅（站内零导流风险）。

圈子建设规范（多源核实）

盐值 ≥450（旧教程 800 已过时）；2025-08 官方「圈子主理人」招募确认平台鼓励建圈 + 流量扶持（1w–5w 曝光）。
🔴 每人仅 1 个圈子（保守）：36 氪 2019 内测报道明写「每人只能创建一个圈子，盐值>450」；2026 无官方更新确认放宽 → 建前在 App 创建页确认实时上限，名要宽、内容要尖、跨内容复用为统一社区枢纽。
命名定稿「可验证 AI 实践圈」（关键词可搜 + 行为词「实践」+ 干净；旗舰专栏「静默失败」降为专栏不进名）。
八格申请表可直接复制（名称/简介/公告/冷启动想法等），0–2 级破冰期，禁二维码/外链/谐音变体。
流量扶持 2026 现行：创作者激励计划（10 亿流量+5 亿现金）、港交所 2026 中报确认 H1 升级圈子+想法产品、专业认证新增开源类别。

知乎「识界」专家报名策略（2026-10-07，副业/IP 增值）

走 expertdata.zhihu.com（SoTALab）专家数据招募门户；须用户本人实名知乎号提交（品牌/公司号验不了个人资质），外部动作+登录墙须本人点，AI 不代发。
双轨报名：同一实名号擅长领域同时填「医疗器械法规」+「AI 治理(LGD)」；AI 治理侧陈述事实不吹"领先/首创"（知乎禁自夸）。
资质通道（2026-10-07 定稿）：医械侧走学历核验通道（有硕/博学位证佐证，最稳，不依赖公司/商标主体）；🔴 公司主体/商标未注册 → 对外素材禁用「CEO/总裁+商标已注册」硬背书，改「深耕垂直领域国际合规与商业化、主理自有业务品牌」。
医疗合规只做法规工程判断，不越界诊断。

产出物模板（目录结构）

text

知乎发文-<主题>/
├── 01-文章-<标题>.md              # 源稿
├── 01-文章-<标题>-粘贴版.html      # 复制粘贴用
├── 02-回答-<问题>.md
├── 02-回答-<问题>-粘贴版.html      # 正文已内嵌图注行
├── 03-发布指引.md                 # 发布步骤 + 已核实结论表 + 经验值未实证清单 + 自查清单
├── 04-事实核实报告_YYYYMMDD.md     # 🔴 逐条"主张→状态→依据"表（强制产出，不对外发布）
├── 05-发布执行单-回答.html         # 🔴 回答必出：步骤 + 图注对照表 + 插入位点锚句 + 自查 + 话题 + 时效
└── assets/
    ├── figN-*.html / .png          # ASCII 命名；1120 CSS px × 2 倍 = 2240px 宽
    └── _superseded/                # 被替换的旧图归档到这里

回答类默认交付：源稿 + 粘贴版 + 执行单 + 配图 + 图注（见《回答交付标准包》）。交付时在回复里逐个列出完整本地路径（Windows 绝对路径），不要只说"已生成"。

版权与许可

免责声明：本技能按"现状"提供（AS IS），不附带任何明示或默示担保（含适销性与特定用途适用性）；使用本技能产出的内容，其事实准确性、平台合规性与发布后果由使用者自行负责。

Zhihu Content Pack

Install

知乎发文内容包（zhihu-content-pack）

适用场景

固定流程（8 步，缺一不可）

🔴 强制全面核实协议（2026-09-29 因返工确立，永久有效）

三条不可妥协的动作

🔴 第二轮补强（2026-09-29 范围漏洞暴露后确立，与上三条同级）

附带的四条纪律

🔴🔴 为什么总要用户催才查出来 —— 防"事后发现"五条机制（2026-10-06 用户质问后确立）

根因（五类，逐条对号入座）

五条机制（此后每次交付都要过）

🔴 交付门禁脚本 delivery_guard.py（2026-10-06 建，可直接复用）

🔴 交付前「读者视角渲染自检」（2026-10-11 立，硬性步骤不可跳）

🔴🔴 L2 独立验证 + 「措辞强度」三件套（2026-10-06 首次实跑后确立）

怎么起 L2（可复用）

「措辞强度」三件套（本次 L2 抓出的 3 处，全部是这类）

L2 的价值形态（与 L1 的分工）

知乎平台核实过的事实（2026-09-27 溯源，多来源一致）

知识更新

选题侦察（第 1 步的标准动作，别空想题目）

🔴 侦察纪律：先过滤，再进上下文（2026-09-29 确立，省积分）

出图管线（可选，回答带图完读率更高）

🔴 硬性排版下限（2026-09-29 用户反馈"字多、字太小"后确立）

🔴 封面规范（2026-09-29 确立）

🔴 封面构型补强（2026-10-05 实战，比"核心区 ±85px"更好落地）

🔴 裁切验证页的两个坑（2026-10-05 实际翻车）

🔴🔴 配色默认「浅色系」——含封面，一律浅底深字（2026-10-06 用户定）

🔴 系列一致性硬指标（多图必查，2026-10-05 复盘）

🔴 中文引号纪律（2026-10-05 补）

🔴 出图后必跑的 4 项机器自检（补 PIL 复核）

🔴 交付前必跑的「文章 ↔ 配图」双向同步核对（2026-10-06 新增）

渲染步骤

🔴 PIL 直接矢量出图管线（Chrome 截图通道不可用时的替代路径，2026-10-07 实战确立）

口径纪律（溯源核实的执行细节）

🔴 回答交付标准包（2026-09-29 用户定；此后所有知乎回答默认按此交付）

图注与插图位置的唯一规则

🔴🔴 图号 ≠ 文件名：两套编号体系必须显式对齐（2026-10-05 实际翻车）

🔴🔴 每张配图都必须有对位点：粘贴版 figcap 数 = 配图数

执行单（05）必须包含的 6 项

发布后必做（回填登记）

验证发布状态的可靠通道（2026-09-29 实测）

🔴 线上更正协议（2026-09-29 因已发布回答数字矛盾确立）

🔴 已发回答补图 → 评论补图路由（2026-09-30 实战确立）

🔴 知乎社区运营 · 圈子建设（2026-10-07 实战，溯源核实）

产出物模板（目录结构）

版权与许可

🔴 交付门禁脚本 `delivery_guard.py`（2026-10-06 建，可直接复用）