山东大学软件学院创新实训——MarketClaw（七）：把零散能力整合成一个可用的运营工作台

2401_83356673

12人浏览 · 2026-06-20 23:27:02

2401_83356673 · 2026-06-20 23:27:02 发布

一、背景

上一阶段的核心工作是平台化——接大模型、做多入口、搭记忆和资产模块，让系统从一个 Web 文案生成工具变成一个智能体运营平台的雏形。

到了这一阶段，事情开始变得不一样。接口写得再多，如果页面还是功能堆叠、评论进不来、Skill 藏在脚本目录里看不见，那这个系统对非开发人员来说仍然不可用。于是这轮工作的重点从“加功能”变成了“整理功能”——把已有的能力串成一条完整的运营流程，让平台真正可操作、可演示、可解释。

二、做了什么

这轮主要完成了四件事：

1. 重新设计小红书运营工作台

之前的页面像一张功能清单：一键生成方案、生成封面、启动调研、发布内容、生成评论回复……按钮堆在一起，用户不知道先点哪个。

现在按真实运营流程重新分了区：顶部是连接状态和指标，往下依次是方案生成、热点学习、发布准备、成品预览、评论收件箱、任务日志。页面逻辑变成了“生成 → 学习 → 发布 → 评论 → 复盘”的顺序。改动不算大，但效果很明显——用户进来就知道下一步该做什么。

2. 评论收件箱：让评论从命令行进入平台

之前评论功能只能一条条手动输入测试，现实中收到的评论没有入口进入系统，更谈不上管理。

这轮加了一个完整的评论收件箱模块。后端建了 XhsComment 表，存评论内容、评论人、所属笔记、类型、情绪、建议回复、处理状态。前端增加了一个类似工单系统的列表，可以导入评论、查看分类和情绪、生成回复建议、标记状态（待处理/已回复/已忽略/需关注）。

评论来源有两条路：手动导入（演示稳定兜底）和自动同步（脚本抓取后回传到平台）。两条路并存，不把鸡蛋放在自动化这一个篮子里。

3. 评论自动分类和情绪判断

基于关键词规则，系统会把评论分成质疑类、询问方法、价格咨询、赞扬类、求带类、一般评论六种，同时判断正面/中性/负面情绪。负面或质疑类评论自动标记为“需关注”。

这还不是完整的舆情预警，但至少让运营人员知道哪些评论需要优先处理。

4. Skill 管理扩展

之前 /api/skills 只返回三个核心 Skill，但项目里实际已经积累了热点学习、封面生成、自动发布、评论回复、账号预热等十三四个能力。这些能力在代码里是存在的，但在平台页面上看不见。

这轮把 Skill 列表扩展到 13 个，按“核心链路/小红书运营/互动运营/内容资产/账号能力/编排能力”分组展示，每个 Skill 显示调用次数、成功率、平均耗时、运行方式（单独运行/编排调用）。让隐藏的能力浮出水面。

三、这个过程中遇到的问题

第一个问题是：功能做出来了，但进不了主流程。 自动回复脚本早就能跑了，但如果它只在命令行输出结果，那对于平台用户来说这个能力就是不存在。这轮花了不少精力做“衔接”——让脚本返回结构化数据、后端解析写入数据库、前端展示到收件箱。衔接本身不复杂，但不做的话之前的自动化工作就白做了。

第二个问题是：自动化不稳定。 小红书页面结构会变、登录态会掉、Chrome 调试端口会冲突。如果系统完全依赖自动化，演示随时可能翻车。所以在评论模块保留了手动导入作为降级方案——能自动抓取最好，抓不到也可以手动输入演示。

第三个问题是：Skill 的定义变模糊了。 最初三个 Skill 都是纯函数，输入输出结构清晰，可以通过 API 单独运行。但后来的小红书发布、评论同步这些能力依赖 Chrome、登录态、图片文件等上下文，本质上不是“函数”，而是“运营流程中的节点”。强行把它们塞进 run(input) 的模型里会很别扭。所以在展示层面用“单独运行”和“编排调用”做了区分，把问题暴露出来而不是掩盖掉。