我用周末复刻了一条 AI 内容流水线

上周末刷小红书刷到一个非常有意思的号，这个号作者说99%的努力还不如一个AI内容生产线，并晒出了他的小红书数据。还扬言一天50条内容是小红书的上限，不是AI的上限。

这是他的一次社会实验，蛮有意思的一个思路，脑袋里有任何选题，丢给AI就能搜索、研究、写文、生成图片、自动发小红书，好酷。

我周末花了蛮多时间和gpt对话，尝试复刻他这个工作流。

记录一下过程和弯路。

直接把原作者的po文down下来丢给gpt帮我分析实现方式。

结果gpt把简单的流程拆解地异常复杂，生生弄了7个大步骤，技术选型上又是langchain、又是autogen这种复杂的玩意。最后我还是决定用trae来完成工作流。

💡

过度设计：在上面第3步，爬网页这块，咱们项目基本就是为了生成一次性的图文，也不指望像知识库一样检索再利用，它给我搞了RAG，fetch其实很没有必要

对服务不了解：比如playwright-mcp里就不像原生的playwright可以缩放N倍获得高清截图，这个在这坑里掉了好久才放弃了mcp用原生playwright+脚本来解决。

💡

不知道为什么同样的制卡的提示词，claude 4和genimi 2.5 PRO相比，后者效果惊艳，甩claude 4一大截。

估计是TRAE的问题，以前我用claude网页版的时候，前端代码能力和prompt理解执行能力超强。

💡

内容生产搞定了，发布到小红书也有蛮多方法，听gpt建议让我用rpa，或者puppeteer/playwright选一个，非要头铁想去选rpa这种看起来最接近人的操作的方式，代价是还要选rpa工具，学工具使用，不够费劲的。最后还是选了playwright+脚本来实现。

💡

之前gpt建议把风格、约束之类的写在项目规则里，把通用的流程、处理数据的方式、调用mcp服务写在agent的prompt里，这样风格和流程能解耦。

规则作为context，而prompt作为指令。听起来很美好，但我在调试的过程中还是会两边一起调试，非常繁琐。鉴于项目没那么复杂，后来还是合并成一个啦，别搞rule啦。

💡