模块四：n8n 搭建逻辑 (★)

4.1 解构需求：任何复杂的工作，本质上都是一系列有逻辑顺序的小任务的组合

• 核心： 先画靶，再射箭。
• 做什么： 明确你最终想要的输出结果是什么。然后从这个最终结果开始倒推，将整个任务拆解成几个关键的、可执行的子步骤。
• 举例（以自动监控竞对获取选题的工作流为例子）：
  • 最终目标是什么? (e.g., 自动完成竞对监控和选题，把好点子存入表格)
  • 流程的起点/触发器是什么? (e.g., 每天晚上10点定时启动)
  • 第一步做什么? (e.g., 获取我需要监控的公众号列表)
  • 需要哪些外部信息/工具? (e.g., 需要一个能查询公众号文章的API，一个能爬取文章内容的工具)
  • 下一步做什么? (e.g., 拿到文章后，需要AI帮我阅读和总结)
  • 过程中有判断/决策吗? (e.g., AI需要根据我的IP定位，判断这篇文章是否有价值，并打分)
  • 最终结果是什么? (e.g., 把AI筛选出的、有价值的选题，自动添加到我的Google Sheets选题库里)

4.2 寻找积木：为每一个小需求找到可用的节点&API接口

• 核心： 不重复造轮子。
• 做什么： 针对上一步拆解出的每个子步骤，去寻找对应的“积木”——优先是 n8n 的官方或社区节点，其次是外部服务的 API 接口。
• 举例（以自动监控竞对获取选题的工作流为例子）：
  • [Trigger] 使用 Schedule Trigger (定时触发) 节点，设置为每天晚上22:00启动工作流。
  • [Action] 使用 Code (代码) 节点，定义一个包含所有竞对公众号信息的列表。
  • [Action] 循环调用 HTTP Request (HTTP请求) 节点，通过第三方API查询每个公众号当天的发文链接。
  • [Action] 使用 Firecrawl (网页抓取) 节点，访问每一个文章链接，并抓取其完整的正文内容。
  • [Action] 使用 Agent (AI智能体) 节点（“核心内容总结”），让AI阅读并总结文章的核心内容、标题和标签。
  • [Action] 将所有总结后的文章信息聚合，再次传入一个更高级的 Agent 节点（“选题初筛”），这个AI被赋予了我的IP定位和读者画像知识，它会逐一分析每篇文章，进行相关性判断、潜力评分，并提出新的创作切入点。
  • [Action] 最后，使用 Google Sheets 节点，将AI筛选并分析完成的高质量选题，追加写入到我的“内容选题库”表格中。

4.3 连接数据：理解数据是如何连接的，进行数据处理，将非结构数据结构化

• 核心： 让数据流动起来。
• 做什么： 将找到的“积木”按照逻辑顺序连接起来。这是最关键、也最容易卡壳的一步：你需要对数据进行必要的清洗和处理，确保上一个节点的输出（Output），能够被下一个节点正确地识别和引用为输入（Input）。
• 核心问题举例（以自动监控竞对获取选题的工作流为例子）：
  • 结构不匹配： Firecrawl 节点输出的文章正文，路径是 data.markdown，但下游的 AI 节点可能需要一个更简洁的 content 字段作为输入。
  • 格式不匹配： 上游节点输出了一个包含多个信息的复杂对象，但下游节点只需要其中的一个链接（URL）。
  • 数量不匹配： 上游节点一次性输出了10篇文章（10个 Items），但下游的 API 一次只能处理1个item。
• 解决方案：
  • 连接操作： 我们在这两个节点之间插入一个 Set 或 code 节点进行“数据清洗”。
    • 在这个 Set 或 code 节点里，我们新建一个字段，命名为 content，它的值，我们通过表达式设置为 {{ $json.data.markdown }}。
  • 结果： 经过 Set 或 code 节点的“翻译”，流向下游 AI 节点的数据就变得非常干净，只包含我们需要的 content 字段。AI 节点的提示词就可以非常稳定地引用 {{ $json.content }}，而无需关心上游数据结构有多复杂。

4.4 精炼优化：优化提示词和流程结构

• 核心： 从“能用”到“好用”。
• 做什么： 此时你的工作流已经可以跑通了，但输出的结果可能还很粗糙。这一步是反复调试、迭代优化的过程，目标是让最终的产出无限接近你的理想状态。运行整个工作流，观察输出结果，从结果倒推反复调整和优化流程中的细节（比如 AI 节点的提示词、数据处理的逻辑），让最终产出更精准、更高效。
• 优化的关键领域：
  • 提示词工程 (Prompt Engineering)： 初版的 Prompt 可能只能得到60分的结果，通过不断增加细节、背景信息、角色扮演、输出格式约束和范例，才能将结果提升到90分甚至更高。
  • 逻辑优化： 检查 IF 节点的判断条件是否严谨？Merge 节点的合并逻辑是否正确？是否需要增加新的分支来处理特殊情况？
  • 效率优化： 某个 API 调用是不是太慢了？能否用其他节点替代？处理大量数据时，是否可以并行处理，以提升整体运行速度。
• 举例（以自动监控竞对获取选题的工作流为例子）：
  • 初始问题： 第一次运行时，我们发现“选题初筛”这个 AI 节点返回的分析结果很空泛，比如“这篇文章相关性很高，有潜力”，这种模糊的结论基本毫无用处。
  • 精炼过程：
    1. 给 AI 注入灵魂： 修改这个 Agent 节点的 System Prompt（系统提示词）。明确告诉它，它的角色是“公众号首席内容策略官”，并为它提供了详细的“背景信息”，包括我的三个IP支柱和目标读者画像。
    2. 将标准量化： 我们不让 AI 凭感觉打分，而是为它设计了一套明确的“潜力评分”规则，包含价值深度 (4分)、时效性 (3分)、爆款潜力 (3分) 三个维度。
    3. 提供思考框架： 我们引导 AI 去分析“核心价值”和“人性钩子”，并给出了钩子的具体分类（恐惧、贪婪、懒惰等）。
    4. 约束输出格式： 最关键的是，我们提供了一个极其严格的 Markdown 输出格式范例，强制 AI 按照我们设计的结构来输出，确保了结果的稳定性和可用性。
  • 优化结果： 经过几轮优化，AI 的输出从一句空话，变成了一份结构清晰、分析到位、有具体评分和理由、并且直接可用的“内容策略简报”。这个工作流也从一个“信息抓取器”，升维成了一个真正的“AI内容助理”。

4.5 加固测试：进行大规模运行测试和压力测试，将工作流优化为可靠产品

• 核心： 为意外做准备。
• 做什么： 一个在测试环境运行良好的工作流，并不等于一个能在生产环境中稳定运行的系统。这一步的目标，是预见所有可能发生的意外（“Edge Cases”），并为流程增加容错和监控机制，确保它在连续、高频的真实场景下仍然可以稳定运行。
• 加固的关键手段：
  • 错误处理 (Error Handling)： 这是最重要的加固措施。为每一个可能失败的节点（特别是进行 API 请求、读写文件等与外部系统交互的节点）开启 “Continue on Fail” 选项。这会给节点增加一个“Error”输出端口，当该节点运行失败时，流程不会中断，而是会进入你预设的“错误处理”分支。
  • 空值判断： 很多时候流程失败不是因为节点出错，而是因为上游没有返回任何数据。在关键节点后增加一个 IF 节点，判断输入数据是否为空。如果为空，可以选择直接终止流程，或发送一条通知。
  • 告警与日志： “错误处理”分支的终点不应该是沉默。它应该连接到一个 Gmail、Slack 或 钉钉 节点，在错误发生时第一时间通知你。同时，也可以连接到一个 Google Sheets 节点，将错误发生的时间、节点、和错误信息记录下来，形成一个错误日志，方便你排查问题。
• 举例（继续“竞对监控”工作流）：
  • 可能遇到的意外：
    • 监控公众号的第三方 API 突然服务器维护，请求失败。
    • Firecrawl 抓取某篇文章时，因对方网站有反爬虫机制而失败。
    • OpenAI 的 API 瞬间网络波动，导致 AI 分析请求超时。
  • 加固策略：
    • 我们在 HTTP Request（监控API）和 Firecrawl（抓取内容）这两个节点上，都进入 Settings 标签页，打开 “Continue on Fail” 开关。
    • 从这两个节点的 “Error” 输出端口，连接出一个新的分支。
    • 在这个分支上，我们先连接一个 Set 节点，创建一个 error_message 字段，内容可以是：【竞对监控流程告警】节点 {{ $executionContext.node.name }} 在处理 {{ $json.biz || $json.url }} 时失败，错误信息: {{ $json.error.message }}。
    • 然后，将这个 Set 节点连接到一个 Gmail 节点，将上述错误信息作为邮件内容发送给自己。
  • 最终效果： 现在，即使晚上有两三个竞对的文章抓取失败，整个工作流也不会中断。它会跳过这些失败的项，继续处理其他成功的文章，并将最终的选题报告正常生成。而我第二天早上，不仅能看到成功的选题，还会收到几封精准的错误告警邮件，让我清楚地知道哪个环节出了什么问题，可以从容地进行排查和迭代。