TrendPublish 文档

Appearance

Editorial Automation 计划 ​

Editorial Automation 是 TrendPublish 下一阶段的开发主线：把微信文章流程从“自动摘要和发布”升级成“自主选题、自动组稿、自我审稿、自学习反馈”的内容编辑系统。

当前优先级不是继续扩大数据源数量，而是提高文章质量、降低重复选题、增强发布前判断。

目标 ​

现有流程：

text
抓取 -> 去重 -> 排序 -> 摘要 -> 标题 -> 封面 -> 渲染 -> 发布

目标流程：

text
抓取
-> 去重
-> 主题聚类
-> 结合历史记忆评分
-> 选择今日内容策略
-> 做编辑决策
-> 生成文章计划
-> 生成正文、标题、封面和配图
-> 自动审稿
-> 自动修复
-> dry-run / 发布
-> 记录反馈和学习信号

第一版不做复杂机器学习模型，不强依赖公众号阅读数据，也不引入人工协作编辑流。多账号运营先聚焦公众号账号画像、矩阵 dry-run 和账号级复盘，不做复杂团队权限或多租户系统。正式发布仍保留 dry-run 和 force publish 保护。

阶段规划 ​

阶段 1：主题聚类与选题评分 ​

状态：已开始实现。

目标是先建立“主题层”，让系统不再直接对单篇文章机械排序，而是先判断今天有哪些值得写的主题。

核心产物：

  • TopicCluster：同一事件、产品、论文、项目、公司公告或趋势的文章集合。
  • TopicScore：主题级评分，包括新鲜度、相关性、影响、证据、可行动性、同质化、风险和综合分。
  • EditorialTopicReport：一次运行的选题报告。

Workflow 插入点：

text
dedup-contents -> plan-editorial-topics -> rank-contents

当前行为边界：

  • 主题聚类和评分先作为 artifact 输出，不改变原有排序、摘要和发布结果。
  • AI 输出失败时使用本地兜底：每篇文章生成一个基础主题，保证 workflow 不中断。
  • Dashboard 质量复盘 -> 选题 是选题工作台，用于查看主题、主线候选、 评分维度、推荐理由、入选/跳过原因、账号定位适配和下一次审题提醒。
  • 选题工作台支持人工标记“锁主线 / 采用 / 跳过”。这些主题级取舍会写入编辑记忆， 下一次选题 prompt 会把它作为账号偏好和避坑信号。

验收标准：

  • 每次新运行都能产出“今日选题”和“选题评分” artifact。
  • Dashboard 可以看到主题列表、推荐用途、评分原因、编辑取舍和账号适配。
  • 原有 dry-run、Cloudflare、Docker、微信发布能力不回退。

阶段 2：编辑决策与文章计划 ​

状态：已开始实现。

目标是在正文生成前先做编辑决策，再生成结构化文章计划，让文章写作从“直接根据文章列表生成”变成“先解释为什么写，再定主线、再写正文”。

编辑决策回答：

  • 今天主线选题是什么。
  • 为什么选它，而不是选别的。
  • 哪些主题被跳过，以及跳过原因。
  • 是否和近期文章或人工反馈重复。
  • 哪些来源适合作主来源，哪些只适合作参考。
  • 标题和正文要避免什么问题。

计划结构包括：

  • 文章形态：日报速递、深度分析、工具测评、趋势分析。
  • 主线观点：今天这篇文章到底想说明什么。
  • 章节安排：每节的意图、关联主题和支撑文章。
  • 标题方向：多个可选标题角度。
  • 封面方向：封面视觉和文字方向。
  • 风险提示：事实不确定、容易误导或不适合下结论的点。

实现边界：

  • 第一版复用现有 LLM Capability，不新增单独的 planning provider。
  • Editorial Decision 作为 artifact 保存，Dashboard 可读。
  • Article Plan 作为 artifact 保存，Dashboard 可读。
  • Article Plan 会消费 Editorial Decision，优先遵守主线、跳过原因、标题规避项和写作指令。
  • dynamic 模板 prompt 优先消费 Article Plan，而不是直接消费文章列表。
  • AI 决策或计划失败时使用本地兜底，workflow 不因为计划生成失败中断。

验收标准：

  • 每次运行能看到“为什么写这篇”的编辑决策和可读的文章计划。
  • 生成正文能体现计划中的主线、章节和风险边界。
  • 后续可以只重生成标题、封面或正文，不必重跑抓取。

阶段 3：质量审稿与自动修复 ​

状态：已开始实现。

目标是在发布前增加自动 reviewer，降低事实错误、标题党、AI 味和结构松散问题。

审稿维度：

  • 事实一致性：是否新增未被来源支持的事实。
  • 标题质量：是否标题党、空泛或误导。
  • 结构质量：是否有主线、层次和必要背景。
  • 表达质量：是否像 AI 套话、营销腔或重复啰嗦。
  • HTML 合规：是否包含公众号不兼容标签和属性。
  • 图片相关性：封面和正文配图是否与内容匹配。
  • 风险边界：不确定信息是否被明确标注。

默认规则：

  • 质量分 >= 80：允许继续发布。
  • 质量分 60-79：自动修复一次。
  • 质量分 < 60：只生成 dry-run，不正式发布。
  • 高危事实问题：禁止正式发布。

当前实现边界：

  • 第一版先生成质量审稿 artifact 和 Dashboard 视图。
  • AI 审稿失败时使用本地 HTML 合规规则兜底。
  • 已加入有限编辑闭环：只修 reviewer 指出的 autoFixable 问题，默认最多 1 轮，修完复审。

发布保护：

  • 已加入最小质量门禁 features.article.qualityGate。
  • 默认开启，只保护真实发布；dry-run 永远继续产出。
  • 低于 minScore、审稿建议不是 publish、存在 blocker 或高危事实问题时，真实发布会写入 blocked 发布结果，不会创建微信草稿。
  • qualityGate.forcePublish 可在 Dashboard 或 TS 配置中开启；开启后真实发布即使 不达标也会创建草稿，但会记录 warning 和审稿 artifact。
  • maxRevisionRounds 控制自动修复轮次，默认 1，建议不要超过 2。
  • 抓取阶段会额外输出 source-health artifact，Dashboard 的 Sources 页面会展示每个数据源的成功、空结果和失败原因，方便先处理输入质量。

验收标准：

  • Dashboard 展示质量分、问题列表和修复建议。
  • 自动修复只针对具体问题，不整篇盲目重写。
  • 正式发布前必须通过质量阈值。

阶段 4：编辑记忆与反馈闭环 ​

状态：已开始实现最小闭环。

目标是让系统记住自己写过什么、哪些来源质量高、哪些主题容易重复，以及人工反馈。

记忆类型：

  • 已发布主题：标题、关键词、涉及公司、主线观点。
  • 来源质量：成功抓取次数、有效内容数量、入选次数、失败次数。
  • 人工反馈：选题好坏、标题好坏、内容深浅、是否重复。
  • 被拒绝主题：低质量、重复、证据不足或风险过高的主题。

使用方式：

  • 排序时降低最近重复主题权重。
  • 提升历史表现好的来源。
  • 降低经常抓到低质量内容的来源。
  • 给 Article Plan 提供“不要重复上次角度”的上下文。

当前实现边界：

  • 每次运行结束后记录标题、主线、关键词、主题标题、来源 URL、质量分、发布状态。
  • 抓取阶段累计每个数据源的成功次数、失败次数、空结果次数、有效文章数和最近错误。
  • Dashboard Runs 页面支持给一次运行标记“好 / 一般 / 差”并附一句反馈。
  • Dashboard 选题工作台支持给单个候选主题标记“锁主线 / 采用 / 跳过”，用于沉淀账号级选题偏好。
  • 下一次 plan-editorial-topics 会读取最近文章记忆、来源表现、运行反馈和主题级取舍，并注入选题 prompt。
  • Dashboard Sources 页面会显示本次 source health 和最近一次运行携带的历史来源表现。
  • 第一版不直接改排序分、不做复杂推荐模型；先让选题阶段避免重复角度、识别低质量来源。

存储边界：

  • 配置仍然只保存“系统怎么运行”。
  • 编辑记忆是业务学习数据，不写入 runtime config。
  • SQLite 和 D1 使用同一套 schema。

验收标准：

  • Dashboard 支持对运行结果做轻量反馈。
  • 下一次选题会受历史主题和反馈影响。
  • 系统能减少同类重复内容。

阶段 5：多账号运营闭环 ​

状态：已开始实现。

目标是让同一套内容生产系统可以横向运营多个公众号账号，但每个账号都有自己的定位、读者、语气、标题风格、默认文章方案和内容来源分组。

当前实现边界：

  • 账号 Profile 保存非密钥运营信息，微信 AppID/AppSecret 仍来自部署配置。
  • 账号可绑定默认文章方案，也可以覆盖模板、提示词风格、文章数量和 sourceGroupIds。
  • 矩阵 dry-run 会为每个账号创建独立 child run，parent run 汇总每个账号的状态、质量分、发布结果和 artifact 数量。
  • parent run 会生成 矩阵账号对比 artifact，并在 summary 中写明质量控制是否达标、 主线/文章形态是否拉开差异，避免多账号 dry-run 只停留在“都跑成功”。
  • 选题、编辑决策、文章计划、动态模板和编辑记忆都会接收账号画像，避免多账号共用同一种表达。
  • 人工反馈、主题取舍、文章记忆和来源表现按账号维度记录，Dashboard 账号矩阵 展示账号级质量复盘。
  • 账号级复盘会把反馈和质量分转成可解释学习摘要：画像完整度、质量趋势、 风险信号、下一次写作建议和推荐动作，避免反馈只停留在日志或原始 JSON。
  • relay 检测结果会回写账号运维状态，Dashboard 刷新后仍能看到上次检测结果。

验收标准：

  • 账号可以在 Dashboard 中维护定位、文章方案和来源分组。
  • 账号复盘能说明“系统学到了什么”，并给出下一次选题和写作的可执行建议。
  • 同一批素材进行矩阵 dry-run 时，不同账号能生成独立 run 和独立产物。
  • 矩阵父批次能展示每个账号的主线、文章形态、质量分和发布结果，并标出是否同质化。
  • 账号级复盘能看到最近文章、质量分和人工反馈。
  • relay 发布链路在真实发布前可以按账号检测可用性。

Dashboard 方向 ​

Dashboard 下一阶段要从“运维控制台”继续向“编辑台”演进。

新增或增强视图：

  • 今日选题：主题聚类、评分、入选/跳过理由。
  • 文章计划：主线观点、章节、标题方向、封面方向。
  • 质量报告：审稿分数、高危问题、自动修复结果。
  • 反馈入口：好/不好、太浅/太长/太像 AI、来源质量差、以后多写/少写某方向。

普通用户视图应避免暴露大段 JSON。JSON artifact 保留为高级排查入口。

工程边界 ​

  • 新能力优先放在 features/weixin-article，因为它服务微信文章业务。
  • 应用组装继续放在 src/app/weixin-article。
  • 外部模型、图片、抓取和发布 provider 仍通过 integrations 注入。
  • 大对象继续写入 ArtifactStore，Dashboard 通过 artifact 查看。
  • 不因为这条主线引入新的 workflow runner 或重新拆架构。

当前优先任务 ​

  1. 用真实 dry-run 观察 Article Plan 和 Quality Review 的输出是否稳定。
  2. 校准质量审稿 prompt，减少泛泛问题，提高事实和结构检查的命中率。
  3. 下一张任务卡进入自动修复：只修 reviewer 指出的具体问题，修完再复审一次。

后续每一阶段都应保持一个原则：先让系统产出可观察的中间 artifact，再让后续步骤消费它。这样可以避免自动化链路变成不可调试的黑盒。

Released under the MIT License.

Copyright © TrendPublish