既然回到了书房，我就把所有的 n8n 节点都接上了本地 RAG。这玩意儿折腾了我整整三天，从“这他妈不就是个流程图工具”到“我操这玩意儿能成精”，心态跟坐过山车似的。
去年底还在跟团队那帮小年轻吹牛逼，说咱们这套爬虫+人工洗稿的流程多牛逼，壁垒多高。结果 ChatGPT 一出，我那些引以为傲的 DOM 树解析、反爬策略、多线程调度，一夜之间全成了废铁。不是不能用，是性价比低到令人发指。你吭哧吭哧写半天，人家一个 API 调用，语义理解得比你深，文章结构比你稳。那种感觉，就像你苦练十年冷兵器，对面掏出了加特林。技能恐慌？不，这是技能灭绝。所以我必须得回来，必须得把 n8n 这个“胶水”玩透，把 AI 这个“大脑”塞进去。
技术细节上，核心就两块：怎么让 n8n 跟我的本地知识库说话，以及怎么让流程别他妈动不动就崩。我本地用 LlamaIndex 搭了个简单的 RAG，把过去几年攒的行业报告、竞品分析、还有我自己写的那些狗屁不通的复盘笔记全喂进去了。n8n 这边，用 HTTP Request 节点去调本地 RAG 的查询接口。这里第一个坑就来了，n8n 默认的请求超时太短，RAG 检索稍微慢点就报错。得在节点配置里把 timeout 参数调到 30000 毫秒以上，不然流程跑一半就断气。
第二个坑是数据格式。n8n 节点之间传数据是 JSON，但我的 RAG 返回的可能是纯文本，也可能是带元数据的对象。你得用 Function 节点或者 Code 节点写点 JS 去解析和清洗。比如，RAG 返回 `{“answer”: “xxx”, “source”: “doc1.pdf”}`，但我下游的 OpenAI 改写节点只需要 `“answer”` 里的内容。你就得在中间加个节点，把 `$json.answer` 提取出来，再赋值给新的 `$json.content`。这活儿不复杂，但极其琐碎，错一个字段名，整个流程就卡那儿了，你还得一层层去 debug。
“自动采集-语义分析-自动改写-自动发布”这个全流程，我是这么串的。起点是一个 Schedule 触发器，每天凌晨两点自动跑。第一步，Webhook 节点模拟请求，去抓目标网站的 RSS 或者最新列表，拿到一堆 URL 和标题。第二步，用 HTTP Request 节点配合 Puppeteer（对，n8n 能跑无头浏览器）去抓具体文章内容，这里要处理图片懒加载和动态渲染，烦得很。第三步，把抓来的纯文本扔给本地 RAG 节点，让它基于我的知识库做语义查询，返回相关的背景知识和可引用的观点片段。第四步，才是重头戏：调用 OpenAI 的 Chat Completion API。
这里的设计逻辑变了。以前我写爬虫洗稿，是规则匹配，关键词替换，顶天了用个 TF-IDF 算算相似度。现在呢？我把原始文章、RAG 提供的背景知识片段，还有我预设的指令模板（比如：“用口语化、带点吐槽的语气，总结以下内容，并插入相关背景知识，生成一篇适合公众号发布的短文”），一股脑塞给 GPT-3.5-turbo。它自己会去理解、整合、改写。我只需要在 Function 节点里，把这几部分拼成一个符合 OpenAI 格式的 messages 数组。温度参数调到 0.7，有点创造性，又不至于胡编乱造。
最后一步，自动发布。把 AI 生成的文章，用 HTTP Request 节点 POST 到微信公众号的草稿箱接口，或者 WordPress 的 REST API。这里涉及 access_token 的管理和刷新，又得写点逻辑。n8n 的 Credit 节点能存敏感信息，算是个简陋的 secrets management。
整个流程调通那一刻，我盯着那个自动运行的绿色流程图，感觉非常复杂。不是兴奋，是空虚。以前解决问题的快感，来自于从零到一构建一个系统，调试每一个 bug，优化每一毫秒的性能。现在呢？我像个接线工，把 OpenAI 的接口、n8n 的节点、我的本地服务，用 JSON 数据流像水管一样接起来。我的核心技能从“写代码”变成了“调参数”和“设计提示词”。这算进步还是退化？我不知道。我只知道，如果我不当这个接线工，我连当工人的资格都没有。
AI 核爆纪元里，没有旧时代的船。你只能把自己变成水，或者变成燃料。
