知乎高质量回答网页生成器

它解决什么问题

把一个研究主题变成知乎风格的单页回答，难点不在排版，而在证据、规模和协作：搜索配额是主子代理共享的硬限，7 个并行代理容易同时触顶；多代理并行时证据要统一沉淀，否则下游章节会读到不一致的上下文；篇幅被硬指标约束（每章 ≥11,000 有效中文字，全页 ≥100,000 字），字数容易失真；头像、外链、Windows 编码、CSS 注入都可能在组装阶段翻车。该技能把搜索、写作、校验、组装和异常处理固化成一套可重复执行的工作流。

它如何工作

• 执行前检查 SKILL.md 顶部的 版本头，发现更高版本就把工作区旧文件归档到 ./other/_OLD/，再从只读 skill 目录同步最新定义。
• 阶段 0 先建目录：mkdir -p ./images ./other ./research_result，所有中间文件落在 ./other/ 和 ./research_result/，最终 index.html 留在根目录。
• 阶段 1 做结构化诊断：拆出核心问题、3~5 个关键子问题，规划互不重叠的搜索方向，并拟定一个知乎风临时标题。
• 阶段 2 读取 references/css-template.css 生成骨架 HTML，不修改 CSS，避免知乎设计 Token 被破坏。
• 阶段 3 用 3 轮串行的搜索配额感知策略推进 ≥500 次真实搜索：先启动 3 个代理，配额回落后再启动下一批；官方文档优先用 WebFetch 抓取，不计入配额。每个代理回传后，主流程立即把结构化报告追加到 ./research_result/search_result.md，来源跟着数据内联，不单独拆来源池。
• 阶段 4 完全由证据驱动规划 10 个章节，从搜索报告里提取高频主题、争议焦点和知识缺口，而不是先拍脑袋拟标题。
• 阶段 4.5 处理答主身份与头像：默认用 DiceBear 风格化 SVG；只有用户明确要求真实头像时才搜索，且要求“身份交叉印证 + 图链可达”，有效头像统一缓存到 ./images/，HTML 引用本地路径。
• 阶段 5 并行启动 10 个撰写代理，每章写入 _draft_ch_XX.html，并运行 scripts/wordcount_check.py 自验有效中文字 ≥11,000，与自述差 ≤5% 才算完成。
• 阶段 6 运行 scan_html.py 预扫描 <code> 标签完整性，再用工作区的 assemble.py 拼接成最终页面，过程中保持 Skill 目录只读。

适用边界与注意点

• 子代理默认会被 Write/Bash 权限拦住，需要在 .claude/settings.local.json 显式授权 _draft_*.html、index.html、assemble.py，并确认工作区在 additionalDirectories 内。
• 异常处理先看 TROUBLESHOOTING.md，它覆盖配额耗尽、task-notification 不实、字体异常、Windows 编码崩溃、颜色归一误伤、字数失真、权限被拒等 12 类场景；没有匹配方案时再自行分析。
• 验收只看文件落盘：ls 确认报告存在且大小 > 0，task-notification 里的搜索次数声明不可信；code 自检前移，草稿阶段就发现问题比组装后返工便宜。
• Windows 下必须给 Python 加 -X utf8 或设置编码，避免 emoji 输出触发 UnicodeEncodeError。
• 所有外链必须来自真实搜索，禁止编造 URL；头像不做不可验证的外链，查不到公开身份就降级到 DiceBear 或单字符占位。
• 需要缩略版本时用 N% 部分执行模式：目录、搜索次数、字数、章节数和代理数等比缩放，title 和问题标题必须带“N%版本”字样，且与上一版本主题保持一致。N%>300% 建议分批交付，避免单次 session 的 token 耗尽。