1. 这不是“挂机脚本”，而是一套可持续运转的B站内容协作者系统

“运行8个月回复4500+条评论”——这句话乍看像营销话术，但拆开来看，它背后藏着三个被绝大多数人忽略的关键事实：时间跨度（8个月）、动作密度（平均每天约19条）、执行载体（Mac mini）。这不是用手机点几下就能完成的“自动回复”，也不是靠临时起号、刷完就弃的“羊毛号”。它是一套在真实硬件上持续存活、稳定输出、能自主应对平台策略变化的轻量级AI协作者系统。

我最初做这个项目的动机很朴素：作为B站中腰部UP主，每天花2小时手动翻评论区、挑高价值留言、组织语言回复，效率低、情绪耗损大，且容易漏掉关键反馈。更现实的问题是——B站网页版没有原生的“已读标记”和“评论分类筛选”，人工处理就像在沙里淘金。而市面上所谓“B站机器人”工具，要么依赖老旧的PC端模拟点击（极易被风控），要么打着“AI”旗号实则只是关键词匹配+固定话术轮播（用户一眼识破，互动率断崖下跌）。真正卡住脖子的，从来不是“能不能发”，而是“发得是否像真人、是否被平台识别为有效互动”。

所以这个项目的核心定位，从一开始就没走“全自动黑箱”路线，而是锚定在**“人机协同的最小可行闭环”**：Mac mini作为物理载体，承担24小时在线、环境稳定、资源可控的底层任务；所有AI逻辑全部本地化部署，不依赖任何第三方API调用（避免密钥泄露、调用限频、服务宕机）；每一条回复都经过“意图识别→语义生成→人工校验→定时发布”四步流程，其中前三步可自动化，最后一步由我每日晨间15分钟集中确认——这既保障了响应速度，又牢牢守住内容质量与账号安全的生命线。

你可能会问：为什么非得是Mac mini？换成树莓派不行吗？云服务器不更便宜？这里涉及三个硬性约束：第一，B站网页端登录态长期维持需要真实浏览器环境（Chromium内核），树莓派性能不足以支撑多标签页+视频预加载+弹幕渲染的复合负载；第二，云服务器无法通过B站的设备指纹校验（尤其是macOS特有的Metal渲染层、字体栈、系统证书链等特征），频繁触发二次验证；第三，Mac mini M1/M2芯片的统一内存架构，在运行LLM推理+浏览器自动化+后台监控三类任务时，内存带宽冲突远低于x86平台，实测连续运行30天无swap抖动。这些细节，不是查文档能知道的，是我在第7次重装系统、第13次调整Chrome启动参数后，用日志堆出来的结论。

提示：如果你打算复现，别急着买新机。手头有2018款或更新的Mac mini（必须是macOS 12.0+系统），就能跑通90%功能。重点不在硬件多新，而在系统环境是否纯净——我专门清空了所有非必要启动项、禁用了iCloud同步、关闭了Spotlight索引，只为让系统资源100%服务于这个单一任务。

2. 真正的“AI助理”藏在浏览器之外：本地化模型选型与轻量化部署

很多人看到标题里的“AI助理”，第一反应是接入ChatGLM或Qwen API。但实际落地时，这条路根本走不通：B站评论区的典型场景是“短文本、强情绪、高时效”，比如“求出下期教程！”、“这个参数调不对啊救救孩子”、“UP主今天吃啥了”，这类请求对模型的要求不是“知识广度”，而是“响应速度+语境捕捉+风格拟合”。调用远程API意味着每次回复都要经历DNS解析→TLS握手→网络传输→排队等待→结果返回，平均延迟超过1.2秒——而B站网页端的评论提交按钮，从点击到成功提示，整个交互周期通常压在800毫秒内。一旦超时，页面会卡在“发送中…”状态，用户刷新重试，系统就可能重复提交。

我的解法是：把AI能力“塞进浏览器进程里”。具体来说，采用Ollama + LM Studio双轨部署，核心模型选用Phi-3-mini（3.8B参数），而非更大尺寸的模型。选择依据非常务实：Phi-3-mini在Mac mini M1上，使用Metal加速后，单次推理（输入256token，输出128token）平均耗时仅320ms，且显存占用稳定在1.1GB以内，完全不影响Chrome的正常渲染。更重要的是，它的训练数据中包含大量代码片段和对话样本，对“技术类UP主评论”的语义理解准确率，比同尺寸的Llama3高出17%（基于我自建的500条B站评论测试集验证）。

部署过程不是简单ollama run phi3就完事。关键在于模型与浏览器的通信管道设计：我放弃了常见的HTTP API方式（会额外引入Nginx或FastAPI中间层，增加故障点），而是用Node.js的child_process模块，直接以stdin/stdout方式调用Ollama CLI。这样做的好处是——进程生命周期与浏览器完全绑定：Chrome崩溃时，AI子进程自动退出；重启Chrome时，自动拉起新的Ollama实例。更妙的是，这种直连方式规避了端口占用冲突问题，同一台Mac mini上，我可以同时跑3个独立的B站账号助理（分别对应不同UP主领域），彼此完全隔离。

注意：Phi-3-mini默认输出格式是纯文本，但B站评论支持基础Markdown（如**加粗**、*斜体*）。我在prompt模板里硬编码了格式转换规则：所有生成文本中，遇到“重点参数”自动包裹**，遇到“操作步骤”自动换行并前置1.2.。这个小技巧让AI回复看起来更“UP主本人风格”，实测用户误认为“是UP主亲自回的”比例提升至68%。

模型微调环节，我只做了两件事：一是用过去半年自己回复过的217条优质评论，构建了few-shot prompt模板；二是针对B站高频词做了词表注入——比如把“充电”映射为“感谢支持”，把“三连”映射为“已收到您的支持信号”，把“求更新”转化为“正在规划下期内容，预计X月X日上线”。这些替换不是简单字符串替换，而是通过LLM的attention机制，让模型理解这些词背后的真实意图。效果立竿见影：原来需要人工修改的35%回复，现在只需微调标点即可发布。

3. 浏览器自动化不是“点点点”，而是对抗式环境适配工程

市面上90%的“B站自动化工具”，死在同一个地方：把B站网页当成静态HTML来处理。但B站的前端是高度动态的React应用，评论区DOM结构每两周就会重构一次，class名随机哈希，元素加载顺序依赖用户行为路径。去年10月，B站把评论列表从<div class="comment-list">改成<section>