经代码质检关卡把主题清单变成检查过的草稿

经代码质检关卡把主题清单变成检查过的草稿

一个 n8n 工作流，拿一串主题，把每个主题变成一篇草稿文章。它研究这个主题，写提纲，写草稿，然后在存入任何东西之前，用普通代码检查草稿。通过的草稿会作为草稿发给你的发布接口。没通过的草稿会连同原因退回。

这是一个骨架，不是现成的服务。每个对外的步骤都是对你提供的 REST API 的一次 HTTP 调用，文件里写明了它期待的四个接口。请先读“开始之前”。

包里有什么

• workflow.json：n8n 导出的工作流，18 个节点，其中一个是便签。里面没有任何凭据，也没有 HTTP 节点发送密钥。
• README.md：这份设置说明，压缩包里的是英文版。

我们相对原来的副本改了什么

• 文件里有两张便签，一张是说明，一张是设置清单，都带着宣传链接。它们换成了一张简短的标题便签，设置步骤写在这里。
• 别的都没改。没有需要删的凭据，也没有需要修的代码。

开始之前

• 一个 n8n 实例。
• 你自己的 REST API，在同一个地址上，有四个接口。工作流不直接调用模型或搜索服务，调用的是你的 API。
• POST /search 接收 {"query": "<topic>", "recency_days": 90}，回复 {"results": [...]}。
• POST /llm/complete 接收 {"task": "outline", "input": {"topic", "sources"}}，回复 {"output": {"title", "sections"}, "usage": {"input_tokens", "output_tokens"}}。同一个接口还接收 {"task": "draft", "input": {"topic", "title", "sections", "sources"}}，回复 {"output": {"title", "body"}, "usage": {...}}。
• POST /alerts 接收 {"channel", "text"}，审批消息上还有一个 approval 字段。任何回复都行。
• POST /publish/doc 接收 {"title", "body", "status": "draft"}，回复 {"url"}。

设置

1. 在 n8n 里新建一个工作流，打开它的菜单，选 Import from File，选中 workflow.json。
2. 在 Config 里，把 base 的值 https://api.your-company.example 换成你的 API 地址。在 Config (errors) 里也一样。
3. 在 Config 里设置 min_words（出厂是 120）和 auto_approve_in_test。
4. 激活工作流。复制 Webhook / weekly schedule: topics 的生产地址，它的路径是 content-run。
5. 向那个地址发一个 POST 请求，JSON 内容比如 {"topics": ["first topic", "second topic"]}。用逗号隔开的主题字符串也行。想给运行起自己的名字，就加上 run_id。

一次运行的过程

1. Webhook / weekly schedule: topics 收到请求。Config 加上设置，One item per topic 是一个 Code 节点，为每个主题生成一条记录。列表为空时，它会带着“No topics supplied”停下。
2. Loop topics 一次取一个主题。没有剩下的主题时，它把所有东西送去 Run summary (respond)。
3. Agent 1 · Research (search API) 把主题发到 /search，时间窗口是 90 天。
4. Agent 2 · Outline (LLM) 把主题和搜索结果发到 /llm/complete，拿回标题和各个小节。
5. Agent 3 · Draft (LLM) 把提纲和资料发到同一个接口，拿回标题和正文。
6. Agent 4 · QA gate (deterministic checks) 是一个 Code 节点。下面任何一条成立，它就把草稿标为没通过：
   - 正文比 min_words 短
   - 没有 Sources: 这一行
   - 含有 guaranteed、risk-free、100% 或 best in the world 这几个说法之一
   - 缺少 ## Why it matters now 或 ## What to do this quarter 这两个小标题
   - 网页链接少于两个

它还会把提纲和草稿用掉的 token 加起来，估算一个成本。

1. QA passed? 把通过的草稿送去 Human approval (Slack)，它向 /alerts 的 #content-approvals 频道发一条消息。下一个节点 Publish as draft (Google Docs / CMS) 立刻把草稿发到 /publish/doc。
2. 没通过的草稿去 Send back with reasons (no publish)，它把原因发到 /alerts 的 #content-qa-failed 频道。
3. Run log row 为这个主题写一行：标题、字数、通过与否、问题、已发布的地址（如果有）、估算成本和 token 数。然后循环取下一个主题。
4. Run summary (respond) 数出主题数、已存的草稿数和失败数，把成本加起来，webhook 再把这个结果返回给调用方。

错误分支是独立的：Error trigger 运行 Config (errors) 和 Alert ops，后者把带着错误信息的“Content pipeline failed”发到 /alerts 的 #ops-alerts 频道。

改变风格

• 检查项：Agent 4 · QA gate (deterministic checks) 的代码里有字数、禁用说法、两个必需的小标题和链接数。改成你自己的规则。
• 研究的时间窗口：Agent 1 · Research (search API) 里的 recency_days。
• 频道：#content-approvals、#content-qa-failed 和 #ops-alerts 是三个节点里的纯文字。
• 成本：估算用的是每百万输入和输出 token 3 美元和 15 美元，写在质检代码里。把你的模型的费率放进去。

注意事项

• 没有任何一步在等人。Human approval (Slack) 只是发一条消息，然后草稿马上被存成草稿。那条消息的 approval 字段，在 auto_approve_in_test 打开时是 auto-approved，关闭时是 awaiting human，两种情况下流程的行为一样。要做真正的审批，就在消息后面加一个 Wait 节点，再从你自己的工具里让它继续。
• 名字里写着每周定时，但唯一的触发器是 webhook。想每周运行，就加一个 Schedule Trigger。
• webhook 没有认证，所以任何知道地址的人都能启动一次运行，而每次运行都在花你的 API。请在 webhook 节点里打开 Header Auth。HTTP 节点也都不发送密钥。如果你的 API 需要，就在每个节点里加上认证。
• 调用方的请求会一直开着，直到所有主题处理完，因为 webhook 用最后一个节点来回复。名单很长的话，可能超过 n8n 前面某一层的超时限制。请让名单短一些，或者马上回复，再把汇总发到别处。
• 汇总里的 run_id 是空的，因为 Run log row 没有带上它。把 run_id: q.run_id 加进它返回的对象里。
• 错误分支只对自动运行起作用。你从编辑器里启动的运行不会触发它。n8n 默认把含有 Error Trigger 的工作流当作它自己的错误工作流。
• 质检关卡检查的是形式，不是真假。它分不出一个链接是真的还是一个说法是对的。请读草稿。
• 你的数据：主题、资料来源和草稿都会发给你自己的 API，以及它背后的服务。