（14697期）Docx Chapter Clean – 科研级文献溯源与文档生成

科研级文献溯源与文档生成 基于 ACP 并行搜索与双引擎研究（unified-search + Tavily），自动生成带严格来源验证的学术 DOCX 文档，全流程可审计、可复现。 使用说明 核心用法 docx-chapter 是一套面向学术写作与研究的专业级文档生成管线，采用六阶段流水线架构：大纲解析 → 并行 ACP 研究 → 内容合成 → DOCX 生成 → 来源验证 → 截图标注验证。用户通过 YAML 格式输入章节大纲，系统自动拆分为独立研究主题，调用 unified-search 与 Tavily Research 双引擎执行深度搜索，最终输出符合学术规范的 DOCX 文档及完整验证报告。 关键操作流程包括：使用 sessionsspawn(runtime="acp") 启动并行研究代理（禁止使用默认 subagent 模式）；强制启用 /unifiedsearch 作为搜索降级路径（禁止 llm-task 直接搜索以防 URL 幻觉）；通过 dedupsources.py 执行硬编码的跨代理 URL 去重；使用 Pandoc 生成 DOCX 并经由 addhyperlink_footnotes.py 将脚注 URL 转为可点击超链接。 显著优点 研究严谨性：双引擎搜索（结构化快速搜索 + Tavily 深度研究）确保来源覆盖度；强制脚注编号系统与来源验证关键词映射实现全文可追溯；Two-Pass 验证架构（声明提取 → 内容级验证）自动检测统计误差、幻觉引用与数值精度问题。 工程可靠性：针对 ACP Claude CLI 的 ~30% 空返回率（#50597）实施自动重试 + 智能降级；Checkpoint 持久化机制支持长时任务断点续传；完整错误处理矩阵区分 FATAL/ERROR/WARN/INFO 四级严重程度。 输出规范性：自动生成符合学术出版标准的 DOCX，含层级标题样式、超链接脚注、数学公式支持；验证报告涵盖数值误差、幻觉声明、结构缺陷等完整审计追踪。 潜在缺点与局限性 基础设施依赖重：强制依赖 Pandoc、Node.js、Python3 + lxml、Playwright 等多语言工具链；Tavily Research 需 API 密钥且单请求耗时 20-60 秒；Roxy 截图验证需 MCP 浏览器服务，配置复杂度高。 人工审核不可省略：阶段三内容合成后必须人工审阅；阶段六截图验证前必须获得用户显式批准（"批准截图"），无法全自动执行。 技术债务明显：大量硬编码 Python 脚本（dedupsources.py、verifydocx.py、purplehighlightscreenshot.py 等）需维护；Pandoc 脚注重编号行为与 DOCX XML 结构黑箱操作带来调试难度；Roxy CDP WebSocket URL 提取、MCP stdio 缓冲等底层细节暴露给上层用户。 适合的目标群体 高校科研人员、研究生：需要生成带严格文献溯源的学位论文或期刊投稿章节 智库与政策研究机构：产出可审计的研究报告，满足来源验证合规要求 企业技术写作团队：标准化产品文档、白皮书的多人协作与版本控制 对学术诚信与引用规范有极高要求的内容生产者 使用风险 性能风险：完整六阶段管线执行时间 10+ 分钟，Tavily Research 与 ACP 并行调用存在 API 配额与速率限制；Roxy 浏览器窗口额度有限，大规模截图可能触发资源耗尽。 依赖风险：任一外部服务（Tavily API、Roxy MCP、unified-search skill）不可用将导致降级或中断；Pandoc 3.7+ 版本存在扩展兼容性变更需持续关注。 数据一致性风险：Pandoc 脚注重编号、DOCX XML 手动修改后的 footnoteRef 丢失、字体污染等结构性问题需通过 verify_docx.py 持续监控；用户若跳过强制检查步骤可能输出格式损坏的文档。 安全与合规风险：截图验证阶段涉及访问外部网站，存在隐私数据泄露与恶意网站风险；用户需自行确保引用内容的版权合规性。 原始说明 Research-backed chapter pipeline: outline → parallel ACP research → MD synthesis → DOCX generation → source verification → screenshot verification (mandatory)