工具、资源与工作台 ·
SearchNews 优化方向（结合 WeWrite 对比分析）
研究了 WeWrite 之后，我发现两个项目有很多相似之处——都是面向中文内容创作者的自动化写作发布系统。但 WeWrite 在几个维度上做得更精细，值得你借鉴。以下是我梳理的具体优化方向：
SearchNews 优化方向（结合 WeWrite 对比分析）
研究了 WeWrite 之后，我发现两个项目有很多相似之处——都是面向中文内容创作者的自动化写作发布系统。但 WeWrite 在几个维度上做得更精细，值得你借鉴。以下是我梳理的具体优化方向：
一、内容质量层：从"能写"到"写得好"
1. 引入写作框架体系
你目前的 render_agent 是"给 LLM 素材让它写"，缺乏结构化引导。WeWrite 定义了 7 种写作框架（痛点型、故事型、清单型、对比型、趋势分析型、纯观点型、复盘型），根据话题自动推荐最匹配的框架，每种框架有专属的开头策略、分节大纲和 CTA 方式。
建议你在 renderers/ 下新增一个框架选择层，让 LLM 先判断话题适合哪种结构，再按框架模板生成大纲，而不是每次都自由发挥。
2. 建立"人味检测"机制
WeWrite 有一套 11 维度的 humanness scoring 系统，从句子长度方差、段落节奏、词汇丰富度、情感分布、副词密度等多个统计指标评估文章是否读起来像 AI 写的，还引入了钟形曲线评分防止"过度优化"。
你的系统目前没有内容质量评估环节。建议在渲染完成后加一个质量检查步骤，至少覆盖句式多样性、段落长度分布、连接词重复率这几个容易暴露 AI 痕迹的指标。
3. 增加写作人格系统
WeWrite 定义了 5 种写作人格（冷面分析师、行业观察者、深夜老友、犀利记者、温暖编辑），每种人格注入不同的句式节奏、情感表达和过渡模式。
你的适配 Agent 目前只做格式适配，没有风格注入。可以在 style/ 目录下用 YAML 定义几套人格配置，让用户选择或按平台自动匹配（比如知乎用"冷面分析师"，小红书用"温暖编辑"）。
二、反馈闭环层：从"开环"到"自进化"
4. 实现编辑学习飞轮（最值得做的一项）
这是 WeWrite 最有特色的功能。它会对比 AI 初稿和用户修改后的终稿，提取 7 类编辑模式（用词替换、段落调整、结构变化、标题偏好、语气偏好等），积累置信度并带 30 天衰减，每 5 次迭代自动更新写作规则。效果是从初始 30% 修改率逐步降到 5%。
你可以在 output/ 目录下保存 AI 原稿，当用户手动修改后发布时，用 diff 提取编辑模式，持久化到 style/learned_patterns.yaml，下次渲染时作为 few-shot 示例注入 prompt。这是让系统越用越好的关键。
5. 范文指纹提取
WeWrite 的 extract_exemplar.py 可以分析用户已有文章，提取"写作 DNA"——包括开头钩子风格、情感高峰分布、转折模式、收尾方式，以及句子长度方差、词汇温度分布等统计指标。
建议你增加一个 style/exemplar_extractor.py，让用户导入自己的代表作，系统自动提取风格特征，渲染时用这些特征约束 LLM 输出，让生成的文章更像用户自己写的。
三、素材采集层：从"搜到"到"选对"
6. 热点发现与 SEO 评分
WeWrite 集成了微博、头条、百度三个平台的热点抓取，用归一化评分（每个来源 0-100）做跨平台公平排序，还通过百度/360 自动补全做 SEO 热度评分（0-10）。
你的 collection_agent 目前是被动式的——用户给关键词才去搜。可以增加一个 collectors/hotspot_collector.py，定时抓取热点趋势，结合 SEO 评分自动推荐选题，变被动为主动。
7. 话题去重与时效管理
WeWrite 会追踪最近覆盖过的话题（7 天内 -3 分，7-30 天 -1 分），避免重复选题，同时保留 2-3 个常青话题。你目前的去重只在单次采集内做 embedding 去重，缺乏跨批次的话题记忆。建议维护一个 data/topic_history.json，每次选题前检查避免撞车。
四、发布层：从"能发"到"稳定发"
8. 微信发布的工程化处理
WeWrite 在 Markdown→微信 HTML 的转换上做了大量平台适配工程：外部链接自动转脚注（微信屏蔽外链）、中英文间距自动规范化、对话/时间线/高亮等自定义语法块、用 flexbox 重构列表保证渲染一致性、深色模式适配（data-darkmode-* 属性）、摘要自动生成（120 字节 UTF-8 安全截断）。
你的 publishing/renderer.py 可以参考这些处理逻辑，尤其是外链转脚注和 CJK 间距规范化，这两个是微信发布中最常见的坑。
9. 图片生成的多供应商容灾
WeWrite 支持 9 个图片生成供应商（豆包、DALL-E、Gemini、通义、MiniMax 等），有自动 fallback 机制。你目前支持 3 个（DALL-E、即梦、MiniMax），建议至少扩展到 5-6 个，并实现链式 fallback——第一个失败自动尝试下一个，而不是直接报错。
10. 主题/模板系统
WeWrite 内置了 16+ 套排版主题，支持 CSS 变量和深色模式。你的微信发布目前似乎只有单一样式。可以在 publishing/themes/ 下预置几套风格模板，让用户选择或按文章类型自动匹配。
五、架构层：从"脚本"到"产品"
11. 考虑 Skill 化封装
WeWrite 是以 Claude Code Skill 的形式分发的，用户安装后直接在 Claude 里用自然语言驱动。你的 SearchNews 是独立 CLI 工具，安装和使用门槛更高。可以考虑把核心流水线封装成一个 Skill（SKILL.md + toolkit/），降低使用门槛，同时保留 CLI 作为高级用法。
12. 配置分层
WeWrite 用 YAML 做配置（人格、框架、范文都是 YAML），比你的纯 .env 方案更适合复杂配置场景。建议把 LLM 参数、写作风格、平台偏好等非敏感配置迁移到 YAML 文件，.env 只保留 API Key 等敏感信息。
优先级建议
如果资源有限，我建议按以下顺序推进：
| 优先级 | 方向 | 理由 |
|---|---|---|
| P0 | 编辑学习飞轮（#4） | 这是让系统从"工具"变成"助手"的核心差异点，投入产出比最高 |
| P0 | 写作框架体系（#1） | 投入小但能显著提升文章结构质量 |
| P1 | 人味检测（#2） | 直接决定内容能否通过平台审核和读者信任 |
| P1 | 微信工程化（#8） | 解决实际发布中的高频痛点 |
| P2 | 热点发现（#6） | 从被动变主动，提升选题效率 |
| P2 | 范文指纹（#5） | 配合学习飞轮，形成完整的风格个性化能力 |
| P3 | 其余项 | 按实际需求逐步推进 |
总的来说，WeWrite 在内容质量控制和自适应学习上比你的项目走得更远，而你的项目在多平台覆盖和采集源多样性上更有优势。最有价值的借鉴方向是把 WeWrite 的质量闭环能力嫁接到你已有的多平台流水线上。