归档说明：本文最初发布于微信公众号“爱玩AI的医学生”。文中的“没写代码”指没有手写实现代码，代码由 AI 工具生成；本人负责需求、流程、测试、反馈和迭代，不代表具备脱离 AI 独立实现同等系统的能力。 查看公众号原文
上一篇文章，我花 200 刀和 48 小时给 OpenClaw 造了一套记忆系统。这次，我用 OpenClaw 花了一周时间，搭了一套完整的小红书矩阵管理系统——从内容采集到自动发布，全链路打通。全程没写过一行代码。
先看东西：这套系统能干什么
直接上功能。
WebUI 管理后台 ：5 个页面——账号管理、发布管理、内容采集、浏览器管理、代理池管理。暗色主题，Vue 3 + Element Plus 搭的。
多账号管理 ：支持多个小红书账号，每个账号独立的浏览器指纹和代理 IP。添加账号的流程是：系统自动打开一个带独立指纹的浏览器窗口，你扫码登录就行，登录态自动保存。还有批量登录态检测、软删除回收站（删错了 3 天内能恢复）。
内容采集 ：输入关键词，系统自动抓取小红书笔记数据（标题、正文、图片、互动数据），全部写入飞书多维表格。同事在飞书群里 @小张 说一句"采集 AI 编程"，系统就自动开始干活。
内容管理 ：飞书多维表格就是我们的内容中台。采集回来的笔记在这里筛选、改写、排期。哪些值得发、发到哪个账号、什么时候发——全在飞书里操作，不需要额外的后台。
自动发布 ：这是整套系统最核心的部分。 在飞书发布表里填好标题、正文、上传图片，把状态改成"待发布"，系统就会自动：
- 下载飞书里的图片
- 打开对应账号的浏览器窗口
- 导航到小红书创作者平台
- 上传图片、填标题、填正文
- 点击发布
- 检测发布是否成功
- 把结果回写到飞书（成功/失败、发布链接、错误信息）
同账号之间自动间隔 3-8 分钟随机延迟，不同账号可以并行。发完自动关浏览器、清临时文件。
飞书机器人集成 ：OpenClaw 跑在我的笔记本上，接了飞书机器人。同事在群里 @小张 说“采集 xxx”，系统自动排队执行，完成后群里通知结果。不需要登录任何后台，飞书群就是操作入口。
技术架构：一张图讲清楚
关键词输入（飞书群 @小张）
↓
内容采集（爬虫模块）
↓
飞书多维表格（内容表）
↓ 人工/AI 筛选改写
飞书多维表格（发布表）
↓
自动发布引擎（CDP 接管浏览器）
↓
小红书（多账号矩阵发布）
↓
结果回写飞书技术栈：Python + FastAPI + Playwright + 浏览器 CDP 协议 + 飞书开放平台 API + Vue 3 + Element Plus + SQLite。
全部跑在一台 Windows 笔记本上。没有服务器，没有 Docker，没有微服务。一个 FastAPI 进程搞定后端 + 前端静态文件，8080 端口启动就能用。
为什么选这些？因为够用。
飞书多维表格天然就是一个带权限、带协作、带附件的数据库，不需要自己搭后台管理内容。浏览器 CDP 协议可以直接接管已有的浏览器窗口，不需要模拟登录、不需要破解验证码。SQLite 单文件数据库，不需要装 MySQL，备份就是复制一个文件。
这套架构的核心思路是： 能用现成的就不自己造，能简单的就不搞复杂 。
全程没写一行代码，怎么做到的
先说清楚"没写代码"是什么意思：我没有手动敲过任何一行 Python、JavaScript、Vue、SQL。所有代码都是 AI 生成的。
但这不意味着我什么都没做。
我负责的部分
需求定义 ：系统要做什么、不做什么、优先级怎么排。比如"先把采集→飞书跑通，再做发布，最后做前端"——这个顺序是我定的。
逻辑设计 ：数据怎么流转、账号怎么管理、发布失败怎么重试、并发怎么控制。这些业务逻辑是我想清楚之后告诉 AI 的。AI 不会替你想这些。
技术决策 ：用 SQLite 还是 JSON 文件？用 Playwright 还是 Selenium？硬删除还是软删除？这些选择题是我做的。AI 会给建议，但最终拍板是我。
测试验证 ：每个功能写完我都会实际跑一遍。发布功能是真的发了一条笔记到小红书上验证的，不是看看代码觉得"应该没问题"。
踩坑处理 ：遇到问题的时候，我负责描述现象、提供报错信息、判断 AI 给的方案靠不靠谱。有时候 AI 的修复方案会引入新问题，我得能发现。
AI（OpenClaw）负责的部分
写代码 ：所有的 Python 后端、Vue 前端、API 路由、数据库操作、飞书 API 调用——全是 AI 写的。
调试 ：报错了把错误信息丢给它，它分析原因、给修复方案。
重构 ：比如发布任务从 JSON 文件迁移到 SQLite，我只说了"JSON 并发写有丢数据风险，换成 SQLite"，AI 就把整个存储层重写了，还自动做了数据迁移。
文档 ：项目文档、进度记录、快速阅读指南，都是 AI 写的。
协作方式
我和 OpenClaw 的协作模式基本是这样的：
- 我描述要做什么（用自然语言，不用写伪代码）
- AI 给方案，我确认或者调整
- AI 写代码，我跑一下看效果
- 有问题就反馈，AI 修
- 没问题就继续下一个功能
一个典型的对话是这样的：
我："发布功能现在检测成功的逻辑不对，明明没发成功也显示成功了。"
AI："当前是检测页面上的'发布成功'文案，但小红书可能改了文案。建议改成检测 URL 跳转——发布成功后 URL 会从 /publish 变成 /noteDetail。"
我："行，改。"
就这么简单。我不需要知道 Playwright 的 API 怎么写，我只需要知道"发布成功后 URL 会变"这个业务事实。
开发过程：一周干了什么
Day 1-2：采集模块
基于开源的 MediaCrawler 做了魔改，主要改了数据存储——原版存本地文件，我改成直接写飞书多维表格。这样采集完的数据直接就在飞书里了，不需要导入导出。
踩了一个坑：Windows 上 Playwright 的事件循环和 FastAPI 的 uvicorn 冲突，启动就报错。AI 帮我加了一行事件循环策略的配置就解决了。这种平台兼容性问题，说实话让我自己查可能要查半天。
Day 3-4：发布模块（最难的部分）
发布模块是整个系统技术含量最高的部分。核心流程是通过 CDP 协议接管浏览器，然后用 Playwright 模拟人工操作。
几个关键的坑：
图片上传 ：小红书的上传按钮背后的 file input 是隐藏的，常规的"等元素可见再操作"根本找不到它。AI 试了好几种方案，最后换了一种定位方式，才把这个隐藏元素稳定找到。
发布检测 ：怎么判断发布成功了？最开始是检测页面上的"发布成功"文案，但不稳定。后来改成以 URL 跳转为主——发布成功后页面会跳转到笔记详情页，URL 会变。加上 500ms 轮询、30 秒超时，可靠性上来了。
重试机制 ：不是所有失败都值得重试。账号被封了重试一百次也没用，但网络超时重试一次可能就好了。AI 帮我做了错误分类——配置类错误（账号问题、权限问题）标记为不可重试，直接跳过；网络类错误标记为可重试。
Day 5：账号管理
账号管理经历了一次完整的方案迭代。
最开始想用 Playwright 打开 Chrome、截取登录二维码、在前端显示。结果小红书登录页改版了，二维码的 CSS 选择器全部失效。
果断放弃，换了一个更简单的方案：直接调用指纹浏览器的 API 创建一个带独立指纹和代理的窗口，导航到小红书登录页，用户自己在弹出的浏览器里扫码。登录态直接保存在指纹浏览器里，不需要导出 Cookie。
这个方案比原来简单得多，而且更稳定。有时候最好的技术方案不是修复旧的，而是换一个思路。
数据存储也从 JSON 文件迁移到了 SQLite。原因很实际：JSON 文件每次写入都是全量覆盖，多个请求同时写就会丢数据。SQLite 的 WAL 模式天然支持并发读写。
Day 6：前端 WebUI
Vue 3 + Element Plus + Vite，暗色主题。5 个页面：账号管理、发布管理、内容采集、浏览器管理、代理池管理。
前端是我让 AI 一口气生成的，然后逐个页面调接口、修 bug。前端开发的速度是最快的，因为 Element Plus 的组件库很成熟，AI 对它非常熟悉。
一个小细节：发布管理页一开始没有分页，数据多了之后页面卡得不行。加了分页，每页 10 条，问题解决。这种"用了才知道缺什么"的需求，就是 Vibe Coding 的日常。
Day 7：集成和收尾
把 OpenClaw 的飞书机器人接上，配置采集队列。在飞书群里测试了完整流程：@小张 采集关键词 → 自动采集 → 写入飞书 → 人工筛选 → 填入发布表 → 自动发布 → 结果回写。
全链路跑通。
还做了一些收尾工作：发布任务从 JSON 迁移到 SQLite、.gitignore 补全、进度文档更新、项目快速阅读指南。
零代码不等于零门槛
我说"没写一行代码"，不是说这件事很简单。
Vibe Coding 的门槛不在代码能力，在这几个地方：
逻辑思维 ：你得能把一个模糊的需求拆成清晰的步骤。"我要一个小红书矩阵系统"——这句话 AI 没法执行。"我要一个系统，能从飞书表格读取待发布记录，下载附件图片，通过 CDP 打开浏览器，导航到发布页，上传图片，填写标题和正文，点击发布，检测结果，回写状态"——这个 AI 能执行。
判断力 ：AI 给的方案不一定对。它可能过度设计，可能用了不合适的技术，可能修了一个 bug 又引入两个。你得能判断。这个能力不来自编程经验，来自对问题本身的理解。
耐心和韧性 ：一周时间听起来很快，但中间有大量的"跑一下→报错→反馈→修→再跑→又报错"的循环。Vibe Coding 不是一句话就出成品，是持续的对话和迭代。
我之前写过一篇 AI Coding 的经验总结，里面有一条： 逻辑先行，代码在后 。这次项目完美验证了这一点。我的医学训练教会我的鉴别诊断思维——从一堆症状里抽丝剥茧找到病因——在这里直接变成了从一堆报错里定位问题根源的能力。
还有一条： 该重构就重构，别修补 。账号管理的方案迭代就是例子。二维码截取方案坏了，我没有让 AI 去适配新的选择器，而是直接换了一个更好的方案。有时候推倒重来比修修补补更快。
当前状态
已完成 ：
- 采集→飞书→发布全链路
- 多账号管理（独立指纹 + 代理 + 软删除回收站）
- WebUI 5 个页面
- 飞书机器人触发采集
- 发布重试机制（可重试/不可重试错误分类）
- 数据存储 SQLite 化
下一步 ：
- 飞书失败告警（发布失败自动通知）
- AI 内容改写（采集的内容自动改写后进发布表）
- 数据统计面板（发布成功率、各账号数据）
写在最后
上一篇文章我说："不会写代码不是障碍。"
这次我用一周时间证明了这句话。一套完整的小红书矩阵管理系统——采集、管理、发布、监控——全程没写一行代码，全靠 OpenClaw + Vibe Coding。
这不是玩具 demo，是真的在跑业务的系统。同事在飞书群里 @一下就能用，发布出去的笔记真的出现在小红书上。
Vibe Coding 的本质不是"让 AI 写代码"，是"让不会写代码的人也能把想法变成产品"。你需要的不是编程能力，是清晰的逻辑、准确的判断、和足够的耐心。
如果你也在用 OpenClaw，或者对 Vibe Coding 感兴趣，欢迎交流。
我是 Ktao，一个用医学生思维搞 AI 的人。上次造了个记忆系统，这次造了个小红书矩阵系统。下次造什么，还没想好。
本文首发于公众号，转载请注明出处。