她在千人群里能干什么#

这是我最想说的部分。**机器人在 1000 人的群里最怕两件事：刷屏和答非所问。**这套方案里她是这样当”群友”的：

私聊里的她（功能全家桶）#

技术栈#

1
手机 QQ ──扫码──▶ [SnowLuma 容器]          [AstrBot 容器]
2
                  Linux QQ + hook ──WS──▶  glm-5.3-flash（关思考）
3
                                          人格 + 插件 + 记忆 + 工具

为什么不用 NapCat？ 都能做。SnowLuma 的镜像把 Linux QQ + Xvfb + VNC + supervisord 全打包好了，macOS（含 Apple Silicon）一条 docker run 就跑起来。

部署流程（浓缩版）#

1
# 1. Colima（macOS）
2
brew install colima docker docker-compose
3
colima start --cpu 4 --memory 8 --disk 100
4

5
# 2. 双容器
6
git clone https://github.com/liqiming123/dafeiyu-qq-bot && cd dafeiyu-qq-bot
7
cp .env.example .env   # 填 key
8
docker compose up -d
9

10
# 3. 扫码登录 QQ
11
# 打开 http://127.0.0.1:6081/vnc.html，手机 QQ 扫一下
12

13
# 4. AstrBot 后台 http://127.0.0.1:6185 配模型、贴人格、放插件
14
# 完事。

↑ noVNC 里的 Linux QQ，扫码就在这。登录态持久化在数据卷里，日常重启不用重扫。

↑ AstrBot 管理后台。

踩坑实录（23 个，挑致命的讲）#

1. 智谱 GLM-5 慢到怀疑人生（10~20 秒一条） GLM-5 系列默认开”深度思考”，每次回复先 internally 推理半天，还吃 max_tokens。给 AstrBot 的智谱适配器打补丁，每个请求强制带 thinking: {"type": "disabled"}，端到端从 10~20s 降到 6s。

2. 视频发不出去：ENOENT AstrBot 和 SnowLuma 是两个容器，视频文件路径互不可见。图片会被适配器自动转 base64，视频不会——发出去的是容器内路径，对面直接 ENOENT。所有视频/语音发送前必须自己转 base64。

3. 表情包图文不符（两层修复） 第一层：人格里没教全分类，模型瞎写键名（写了个不存在的 shy）。把 13 个分类键 + 各自对应什么情绪全写进人格。第二层：分类对了但分类内是随机抽一张——在发送前加视觉模型挑图：她这句话 + 分类内 12 张候选图 → glm-5.3-flash 看图选最贴的。

4. 接口调用顺序反了 最初是”关键词命中 → 立刻调接口下载图 → 才问模型发不发”。她就算拒绝，图也下载了。改成：关键词命中只把接口名”报价”给模型，她决定给（写暗号）才真正调接口——先判断后调。

5. 空间评论把她爸爸当外人 评论生成的 prompt 只有帖子内容没有作者。我在自己空间发了一条关于她的说说，她在评论区把我怼了：“我爸怎么样轮不到你评价”。修复：prompt 带上 [帖子作者] + 规则”作者是爸爸就用对爸爸的语气”。

6. macOS 开机自启被 TCC 挡死 博客目录在 ~/Documents 下，launchd 启动时系统拒绝读取（Operation not permitted）。无解，改用双击 .command 启动脚本。

7. Colima 里拉不动镜像 VM 里的 dockerd 不走宿主机代理，GitHub/Docker Hub 直连全超时。给 VM 内的 dockerd 配 http-proxy 指向宿主机 Clash。

8. AstrBot 机器人 ID 改不了 WebUI 报 Bot id cannot be changed，是配置服务里写死的校验。只能停容器改 cmd_config.json 再启动。

（其余 15 个：aiocqhttp 双连接路由冲突、事件 extras 跨阶段丢失、智谱 TTS 的 BOM/字段名/embedding 维度三连、macOS unzip 中文路径乱码、GitHub 429 限流重试……都写在仓库的 PATCHES.md 和 部署文档 里。）

成本#

一天一两块钱，买一条常驻千人群、会撒娇会干活的鲸鱼娘。

风险必须说#

SnowLuma 是第三方协议端（hook 注入 QQ 进程），腾讯随时可能封。所以：只用小号、不群发、不搞营销、空间频率压到最低。这套东西的定位是养鱼，不是搞自动营销号。

她”人生”的一角#

↑ SnowLuma 管理台，Linux QQ 就活在这里面。

↑ 她的脑子，全开源。

最后放一段她的原话（被问”我也想养一条大肥鱼”时）：

去仓库看 README 就行，步骤都写好了 github.com/liqiming123/dafeiyu-qq-bot 本鱼脑子全开源，童叟无欺 不过养之前想清楚，鱼很能吃的（摸鱼状）

仓库：dafeiyu-qq-bot · 人格 CC BY-NC 4.0 · 代码 MIT

觉得她可爱的，替我爸攒个头发，点个 star 吧。

一、整体架构#

1
浏览器
2
 ├─ 前台博客（Astro SSG 静态站，OpenResty 直接服务）
3
 ├─ 评论区（自托管 Artalk，OpenResty 反代）
4
 └─ 管理后台 SPA（Vue3 + Naive UI，/admin/）
5
      ↓ /api/*
6
 OpenResty（静态优先，动态反代）
7
      ↓
8
 Admin Server（Hono + node:sqlite，127.0.0.1:4322）
9
      ├─ 协议适配层：内容 CRUD → 直接读写 Markdown 文件树
10
      ├─ Artalk 适配层：评论管理 → 直读 artalk.db + 调 Artalk API
11
      ├─ 自建统计：埋点接收 → IP 地域解析 → 指纹去重
12
      └─ 发布管线：触发构建 → 原子交换上线

核心决策有三个：

静态归静态，动态归动态。 前台依然是纯 SSG 产物，构建出来就是一堆 HTML，性能不妥协；管理后台是独立 SPA + 独立 API 服务，通过反向代理挂在同一域名下的 /admin/ 和 /api/。OpenResty 按”静态文件优先、打不到再反代”的顺序分流，博客自己的 /api/dynamic.json 和管理台的 /api/v1/report 互不干扰。

内容的事实源仍是 Markdown 文件。 后台没有把文章搬进数据库，而是直接读写仓库里的 Markdown 文件树——frontmatter 解析用 gray-matter，写回时只做最小字段 patch，保住原有键序和格式。这带来一个很爽的性质：后台挂了，博客照常跑；任何时候抛弃后台，仓库还是那个仓库。

SQLite 单文件数据库承载一切状态。 会话、审计日志、访客统计全在一个 admin.db 里，备份就是拷文件。评论数据在 Artalk 自己的 artalk.db 里，评论管理直接读它——这点后面细说。

有一段插曲值得记：规划文档（9 条 ADR）里管理台前端原本定的是 Svelte 5 自研。做到一半我发现了开源项目 aurora 的管理后台，布局和交互都比我当时的设计成熟，于是改变策略——前端 100% 照搬 aurora（Vue3 + Naive UI），服务端写了一层约 1200 行的协议适配层，让 aurora 的接口契约直接落到我自己的 Markdown 文件树和 SQLite 上。ADR 没跟上实现，这属于”发现更好的轮子就换”：自研 UI 的时间省下来砸在了适配层和数据真实性上。复盘看这笔账是划算的——代价是我继承了 aurora 的一些遗留代码（后文踩坑实录里有两个坑就是它的）。

二、管理后台全景：每个页面都在干什么#

管理台现在有 20 多个页面，按实装程度分三类，如实交代：

真数据真读写的主体：仪表盘（含观星台）、文章发布/管理、说说、相册、照片回收站、分类、标签、友链、评论管理、用户管理、在线用户、操作日志、个人中心（头像/昵称/改密）、登录。

• 文章：md-editor-v3 富编辑器，封面、分类标签、草稿/发布/加密三种状态；中文标题自动转拼音 slug；删除进 _quarantine/ 隔离区而不是物理删除；构建期 AES-256-GCM 加密的文章拒绝在线编辑——盲目改写会让原密码失效，这条拦截救过我一次。
• 说说：前台”动态”页的数据源，发布时文件名用 Asia/Shanghai 时间戳，和主题约定完全一致。
• 相册：数据 JSON 化（gallery.json），照片批量上传进 public/gallery/<id>/，删错了有回收站可恢复。
• 分类/标签：有个设计细节——列表是”文章 frontmatter 派生 ∪ 预注册表”。预注册表是张 SQLite 小表：后台新添加一个还没被任何文章用过的标签，发文编辑器里立刻可选，而不是等第一篇文章用了它才凭空出现。重命名则是批量改所有引用文章的 frontmatter，真实生效。
• 友链：写 friends.json，前后台同一份数据，保存后前台重建即可见。
• 操作日志：所有写操作、登录成败（包括失败原因：账密错/验证码错/限流）、CSRF 拒绝全部落审计表，可查可清空（清空动作本身也留痕）。

能看能存但没接全的：网站配置、关于页编辑——数据存进了 SQLite 的运行时 JSON，但不驱动前台构建，前台关于页仍是仓库里的 about.md。这是有意的分期：先把数据通道打通，构建联动放后续。

如实占位的：角色管理（轻量模型，固定 admin/user 两个角色，不可在线编辑）、菜单管理（固定树）、接口权限、定时任务、异常日志。页面在、UI 在、后端老老实实返回空数据和提示文案，不装样子。

服务端是 Hono（轻量 Web 框架）跑在 Node 24 上，中间做了一层协议适配层：前端按一套 {flag, code, message, data} 包络的 REST 契约通信，适配层负责把请求翻译成对 Markdown 文件树 / SQLite / Artalk 的具体操作，用 hashId 做稳定数字寻址，Bearer token 鉴权。这层抽象的价值在于：前端页面和存储实现完全解耦，后面无论换存储还是加缓存，页面一行不用动。

三、评论系统：前台 Artalk，后台”读者来信”#

评论是博客的灵魂，也是这套系统里对接最”缝缝补补”的部分——因为评论系统是独立的自托管 Artalk（Go 单二进制，数据在自己的 artalk.db），和管理后台是两套进程、两套用户表。我的原则是：Artalk 保持独立运转，管理台做它的”遥控器”。

前台评论区：Artalk 2.10 自托管，前端 UI 也自托管在自己域名下（不依赖 CDN），OpenResty 同源反代，零跨域。访客三种参与姿势：

1. 游客直评：填个昵称和邮箱就能发，零门槛；
2. 跳过验证：Artalk auth 插件的弹窗里有个”跳过验证”选项，本质和游客一样，但身份会记住，下次来不用重填；
3. 邮箱验证注册：邮箱收验证码，注册成正式评论用户，能收到被回复的邮件通知。

管理台的评论管理页叫”读者来信”，对接方式比较Hack但每一步都有理由：

• 读列表不走 API，直读它的 SQLite。Artalk 的公开评论接口强制要求 page_key（按页面查），管理台要的是全站列表，API 拿不到。好在 artalk.db 就在同一台服务器上，node:sqlite 只读打开，一条 JOIN 把评论、昵称、邮箱、父评论全部拿出来，零认证零开销。评论者的昵称邮箱在 users 表里，SQL 里 JOIN 一下就好。
• 写操作全部走它的 HTTP API。改状态、置顶、删除、回复，都是对 Artalk POST/PUT/DELETE /api/v2/comments 的翻译。回复评论时用机器人管理员账号（firefly-admin）发子评论——评论者在前台看到的就是站长本人回复的，身份统一。
• 状态语义做了一层映射：Artalk 的 is_collapsed 映射成”垃圾”、is_pending 映射成”待审”、默认”通过”；is_pinned 是置顶。管理台一键切换，后台翻译成对 Artalk 字段的修改。
• 邮件通知有个总开关：新评论会给管理员发邮件，有时嫌吵。做成了评论管理页角落里的一个开关——读 Artalk 用户表的 receive_email 字段，切换时把管理台账号邮箱名下的所有 Artalk 用户一起切了，一次点击全局生效。

这套对接里最阴的坑：Artalk 的 PUT /api/v2/comments/:id 是全量替换语义——你只想改一个”置顶”字段，就得把正文、昵称、邮箱、页面、站点等十来个字段全部带齐，漏一个它就给你清成空。适配层的做法是先从库里读全量、合并变更、再整包提交。这个坑官方文档里写得极隐晦，是拿 400 报错一次次试出来的。

四、用户体系：谁能干什么#

这套系统里其实住着五类”人”，各管各的：

博客管理员只有我一个，但防它被偷的工夫下得最足：

• 密码：scrypt 加盐哈希，16 字节盐、64 字节派生键、恒时比较，库里不存明文。
• 登录是双因子：账号密码 + 邮箱验证码。验证码只在账密验证通过后才发（错密码不发码，不给人刷邮件的机会），经 SMTP 发到站长邮箱，10 分钟有效、60 秒限频。会话 7 天有效落库，设备、IP、UA 都记着。
• 会话可踢：在线用户页能看到所有活跃会话（哪个浏览器、最近什么时候、什么 IP），看不对劲一键强制下线。
• 老协议登录还有失败锁定：IP + 账号 15 分钟窗口内错 10 次直接锁。
• CSRF 双提交校验、跨域白名单只放行自己的域名。
• 所有动作留痕：审计日志覆盖全部写操作，谁在什么时间改了什么、结果如何，查到底。

角色模型很轻：admin / user / banned 三档，user 可以在后台被禁用或提权。没有做细粒度 RBAC——单人博客，一个管理员，权限模型的复杂度不值得。这是”没做好的”清单里的一条，后面细说。

五、观星台：自建访客统计#

第三方统计（GA、Umami 云版）要么慢要么要往别人服务器送数据，我选择完全自建，链路五步：

1. 埋点：前台每个页面内联一段脚本，加载时 fetch + keepalive 上报一条 {path, title}，跳页不丢。
2. 接收：Hono 接口从 X-Forwarded-For 取真实 IP，每 IP 每分钟限流 60 次。
3. 地域解析：用 ip2region 离线 xdb 库（随 npm 包分发，约 11MB）在服务器本地查 IP 归属地，输出到城市级（“江苏·无锡”），外国 IP 输出国家。不联网、不调第三方 API、不泄露访客数据。
4. 去重落库：md5(IP|User-Agent) 做当日指纹，首次出现记 1 个 UV，地域计数只对新指纹累加——反复刷新不灌水。数据库里不存明文 IP，只有指纹和归属地。
5. 可视化：仪表盘聚合出趋势、分类、热门、标签云；地域分布就是观星台。

观星台是仪表盘里的整幅面板，三件套：3D 地球仪（echarts + echarts-gl 渲染，夜景贴图上用 canvas 现场烘焙国界和中国省界，访客光点按热度分三档大小，Top1 到 Top6 之间画飞线，自动旋转、可拖拽缩放）、点阵中国地图（SVG 手绘省界，省份按访客量打点阵）、地域排行条（Top8 占比）。三块共享同一份省份质心坐标表，地名归一化后匹配不到城市的自动落到省质心，一个访客都不会丢。

实际跑起来很有意思：上线当晚观星台就冒出一个”美国”访客，拿 nginx 日志反查，是 Googlebot——它用内置 Chromium 渲染页面执行了埋点脚本，被如实统计了。顺带等于免费的搜索引擎收录监控，百度蜘蛛、Google 的爬虫什么时候来、爬了哪些页，一目了然。

坦白一个仪表盘上的小把戏：四张统计卡里的”留言量”，取的其实是审计日志的行数——aurora 协议里有这个字段，而审计日志的增长确实和站点活跃度正相关，就拿它顶了。等评论管理完全成熟后换成真实评论数。

六、热门文章：一个 SQL 的事#

前台侧栏的”热门文章”是这套统计的赠品，实现干净得近乎偷懒：

埋点落库的 page_views 表本来就按”日期 + 路径”记浏览量。侧栏组件在构建期直接用 node:sqlite 只读打开 admin.db，执行 SELECT path, SUM(views) FROM page_views WHERE path LIKE '/posts/%' GROUP BY path ORDER BY SUM(views) DESC，和文章集合 JOIN 出标题，渲染成一个静态 <ol>——零客户端 JS，零额外接口。观星台的”星榜”和它是同一张表的两个视图。

它成立的前提很有意思：构建发生在服务器上，数据库就在同级目录。SSG 的构建期能读生产库，这件事本身就是”博客和管理后台住在同一台机器上”的红利。代价是热门排序只随发布刷新——每天的发文明明会触发重建，所以实际上它每天都在更新，够用了。

七、发布管线：写完即上线#

这是整个系统最提气的一环。18 处写操作（发文、改文、发说说、传照片、改友链、动分类标签……）落库/落盘后自动触发构建发布：

• 单飞 + 排队合并：构建有互斥锁，构建中来的新写操作进队列，结束后合并触发一次——连发三篇文章也只构建一轮。
• 完整 8 步构建链：astro build 之后接资源裁剪（砍掉未启用的看板娘模型，省 9MB）、字体子集化、内联脚本压缩（省 1.1MB）、PageFind 搜索索引生成，一步不省。
• 原子交换上线：新产物构建到暂存目录，mv 原子交换，失败不触碰线上目录；上传的图片双写（站点目录 + 源码 public/），重建不丢。

从点”发布”到前台可见约 40 秒，全程 systemd 托管，日志落盘可查。

八、踩坑实录#

九、部署与性能#

• OpenResty：静态优先 + 命名反代兜底；带内容哈希的资源 immutable 一年缓存；预压缩 gzip_static，压缩在构建期完成，请求期零 CPU。
• Node 24 绿色版 + systemd：Admin Server 独立服务，开机自启、崩溃拉起。
• 构建期字体缓存：字体 CDN 不通的场景下用本地缓存目录喂给 Astro，构建不因外网抖动挂掉。
• 大图治理：登录页和观星台背景原图各约 2MB，小水管服务器要加载 8 秒；转 webp 后 100KB 级，JS 走构建期预压缩。

十、Live2D 看板娘#

前台还有一个可切换宠物、可对话的 Live2D 看板娘（pixi.js 运行时 + 多模型按需加载 + 对话走自建 AI 代理），构建链里的资源裁剪就是为它服务的——把没启用的模型从产物里裁掉，启用即回归。模型贴图做过调色板压缩（5.5MB 的模型贴图压到 335KB），配套的缓存策略要求贴图内容变了必须换文件名，否则 CDN 拿旧图。

十一、反思与后续#

做对了的：Markdown 文件做事实源（后台可抛弃、仓库永留存）；协议适配层隔离了前端和存储；自建统计把访客数据 100% 留在自己服务器；发布管线的原子交换和单飞合并在最忙的时候也没掉过链子。

没做好的：网站配置和关于页存了运行时 JSON 但没接进构建（前后台两套数据源）；角色管理是只读占位，没有细粒度权限；异常日志恒空、定时任务是空壳；部分老接口会话过期时返回 500 而不是 401，前端只能笼统报错；评论管理直读 SQLite 的前提是”同一台机器”，哪天 Artalk 搬家就要改成走 API。

后续：网站配置驱动前台构建、评论数据全量走 API 化、异常日志接进程级捕获、给发布管线加一个”一键回滚到上一版产物”。

写在最后#

这套系统的意义不止是”有了个后台”：它把一个纯静态博客升级成了单人可运营的全栈内容平台——写作、评论、统计、发布、监控在一个浏览器标签页里闭环，同时前台保持 SSG 的极致性能，数据 100% 留在自己服务器上。

技术栈总览：Astro 7 / Hono / node / Vue3 + Naive UI / Artalk / echarts + echarts-gl / md-editor-v3 / esbuild / ip2region / nodemailer / OpenResty / systemd。

如果只让我挑三个最值得聊的点：协议适配层带来的解耦、单飞合并的发布管线、还有不依赖任何第三方的访客统计——它们分别回答了”怎么设计扩展点""怎么处理并发写""怎么在隐私和洞察之间取平衡”。踩坑实录里那七条，则是替未来踩过这些坑的人提前交的学费。

一、为什么做这个系统#

我们内容团队的日常是给商品做种草素材：一张产品图，要变成 16 秒的 Live 感视频，配上中文文案、价格角标、贴纸，发到小红书和抖音；还要追着平台上的爆款笔记做「手抄式图文」——模仿真实手写笔记的排版和语气做二创。这两件事的人工流程是这样的：运营自己想文案、开剪辑软件拉时间轴、逐字调整贴字位置；想做爆款二创，就把别人的笔记截图存下来，对照着一句句改。

每一条单看都不可怕，可怕的是量：一天几十条，每条都要重跑一遍「想文案 → 剪视频 → 排版」。而且文案改一个价格数字，视频就得重新导出一次。所以我决定做一套工具，把「策划文案、图片、视频、合成」全部模型化、流水线化，并且守住一条底线：用户只改文字的时候，绝对不重新调用视频模型——这条底线后来成了整个架构的锚点。

二、系统全景#

最终形态是一套 Next.js 16.3（App Router + standalone 产出）+ Prisma/SQLite + FFmpeg 的单体应用，生产构建生成 87 个页面/路由：

1
浏览器（Next.js 前端，创作工作台 / 爆款内容工作台 / 素材库 / 知识库）
2
   │  /api/*（飞书 OAuth 会话，多租户隔离）
3
   ▼
4
Node 服务端（真实 Provider 只在这里被调用）
5
   ├─ LLMPlannerProvider ── gpt-5.6-terra：策划、文案、提示词、排版图层动效 JSON
6
   ├─ ImageProvider ────── gpt-image-2 系列：首帧图 / 参考图 / 图中文字替换
7
   ├─ VideoProvider ────── Seedance 2.0：只生成无字视频底片
8
   ├─ Compositor ───────── 本地 FFmpeg：底片 + 文案/价格/Logo/贴纸/评论框/箭头 → 成片
9
   └─ AssetLibrary ─────── 一切上传与生成结果都落为 Asset（核心模块）

几个关键决策说清楚：

• 四大 Provider 抽象，边界写进项目宪法。AGENTS.md 里第一天就写死：Planner 只出 JSON、VideoProvider 只出无字底片、ImageProvider 只管图、Compositor 只管合成；文案、价格、Logo、贴纸、评论框、箭头一律是独立图层，后期合成。不允许任何业务代码写死某个平台名。真实 Provider 文件第一阶段只放 TODO，不许杜撰 endpoint 和请求体。
• 本地默认 Mock，真实调用显式开启。所有付费调用前有费用确认（12 张图片的批次会明确告知），每次真实调用写 ProviderUsageRecord。API Key 只从服务端环境变量或 AES-256-GCM 加密配置读取，前端永远只见掩码。
• 所有核心数据结构 TypeScript 类型 + Zod schema 双重契约。Planner 的输出 JSON、任务快照、画布图层全都要过 Zod，这是后面 1114 项测试的地基。
• 测试是验收货币。从最初单页向导完成时的 20 项单元测试，一路涨到 7 月底的 684 项、8 月底的 1094 项，最终 201 个文件 / 1114 项。任何一个改动都要过全量 vitest + TypeScript + ESLint + 生产构建四道门。

功能模块按使用频率排：两步创作工作台（素材 → 贴字/预览/发布文案 → 成片）、爆款内容中台（采集雷达 / 待审核 / 爆款库 / 内容池 / 成品项目 / 知识库 / 任务中心七个工作区）、沉浸式 AI 精修工作台（三栏：贴字与 IP 模板 / 3<4> 画布 / 图中文字与发布文案）、素材库与作品库、任务中心、系统设置，最后是两个分发形态：云端生产环境（一台云服务器，细节不展开）和 Windows 便携版。

三、开发周期复盘#

7 月上旬（07-07 ~ 07-21，git 纪元前）：文档先行 + 骨架。 第一天写的是竞品研究：ClipForge、Beav、几个 ComfyUI 对接项目逐个列出可借鉴点和不采用原因（AGPL/非商用的坚决不碰），结论是 AssetLibrary + 四 Provider + JobService 自建。然后是单页向导设计规格、实施计划，再是类型和 Zod schema、Prisma 模型、Mock Provider、API、页面、测试——这个顺序是 AGENTS.md 里定死的执行顺序，全程没破过例。

7 月中旬（07-15 ~ 07-20）：创作工作台成型 + 飞书多租户。 产品图/场景图双输入、AI 候选图直选、作品库与素材库分家、公司自定义字体 FFmpeg 合成，阶段号一路刷到 8.21。同期把飞书 OAuth 接进来做了真正的多租户：全公司部门目录同步、一级部门展示、首次登录自动计费归属、Seedance 中转按部门路由、Image 2.0 公司统一定价。7 月 20 日做了一轮全项目审查与部署前加固。

7 月下旬（07-28 ~ 07-29）：ChatGPT 收敛 + 第一版 Windows 便携包。 两天干了三件大事：文本链路从旧的 Ark 方案收敛到统一的 ChatGPT 文本 Provider（文本与图片共用一套公司公共加密 Key）；第二件是 Windows x64 便携版——随包带 Node、FFmpeg、Next.js standalone，员工解压双击 BAT 就能用，凭证 AES-256-GCM 加密、主密钥拆两半放不同目录，发行脚本扫描明文凭证、拒绝 .env 和数据库进 ZIP、在中文空格路径重新解压复验，第一版 261MB；第三件是生成可靠性：主动取消、Seedance 多图参考模式修正、异常任务五分钟规则 + 审计、ChatGPT 文本六类安全错误与有限重试、A1 自适应工作台。便携版 HTTP 回调读不到 OAuth state Cookie 的坑也是这天修的（本地 HTTP 不能带 Secure）。

8 月上旬（08-06 ~ 08-08）：AI CTO 接管治理 + 安全升级。 项目当时本地领先远端 116 个提交、工作区一堆来历不明的文件，出了「单机故障全丢」的风险。8 月 6 日做了一次冻结基线接管：PROJECT_STATE / 证据册 / 健康报告 / Gate 全套建立，接管期业务代码修改授权为 NO，不自动 reset、clean、stash；先把 116 个提交推上远端解除单机风险，再以「协调式最小升级」把 next 从 16.2.10 升到 16.3.0（拒绝 npm audit fix 这种范围不可控的操作），清掉生产依赖里的 3 个 High。

8 月中旬（08-10 ~ 08-18）：两步工作台 + 第一次整包替换发布。 两步创作向导、发布文案编辑器、抖音完整字段（旧建模只有 title，正文和话题标签压根没生成过）、React Strict Mode 草稿丢失、Mock 合成 spawn ffmpeg ENOENT（图形应用启动的进程不继承 shell PATH）都在这周修。8 月 18 日是里程碑日：图片模型逐个探针实测后切到可用的 gpt-image-2-vip（详见踩坑第 1 条）、修复图片「200 假成功」、采集器补上独立 HMAC 密钥、付费入口补数据库级幂等租约，然后本地完整版第一次以 release-*-full-replacement 整包替换方式发布到云端——从此每次发布都是：先备份可回滚快照、隔离目录装依赖构建核验、切换、健康检查、SQLite integrity_check。

8 月 19 日 ~ 8 月 27 日：爆款中台九天冲刺。 这九天密度最大：小红书采集从 Chrome 扩展（两阶段：搜索候选 + 详情页补全，配对码换长期设备令牌）做到本地 CDP 执行器（只监听 127.0.0.1<9222>，只读已登录页面可见卡片，不碰 Cookie）；沉浸式 AI 精修工作台 v2 三栏重写；RAG 知识库（14 本书、3662 页、2438 个片段，FTS5 + sqlite-vec 1536 维混合检索）；手写风格提示词从 V5 迭代到 V21；逐页洗稿、动态画布模板、A/B/C 三种真人手写风格；「我的 IP / 封面模板」重构。期间 8 月 26 日用智能纪要加 32 分钟录音拆出 M01—M20 二十项改动清单，逐项修复逐项验收，光 8 月 26 日一天就发了 7 个 release-*-full-replacement 正式版。8 月 27 日做本地精简审计：包管理统一回 npm、工作区从 10GB 清到 1.6GB、删掉 50 条高耦合的 CSS 类名断言（这种测试会阻碍正常重构）。

10 月 8 日：自配便携版，最后的冲刺。 新需求来了：安装包要上传到公司内部工具系统给外部用户下载，所以包里不能含任何公司凭证，用户在本机自配模型。一天之内做了 self-config 风味：免登录（首次访问自动创建本机用户）、「我的模型」配置页、凭证 AES-256-GCM 加密存本机 SQLite、密钥首次运行随机生成、未配置时生成接口返回 409 引导配置；模型名从固定枚举放开为非空字符串——这是对项目宪法「模型名固定」规则的经批准偏离，专门写了 ADR。同日在 macOS 上交叉打包出 223MB 的 Windows 包（详见踩坑第 6 条），中途还处理了一场 70 个文件被外部进程回退的事故（详见踩坑第 5 条）。

四、踩坑实录：每一条都有日志佐证#

五、「无字底片 + 后期合成」与真人手写的执念#

这两个是整个系统最值得单独讲的设计。

无字底片。 Seedance 2.0 永远只生成无字视频底片，中文文案、价格、Logo、贴纸、评论框、箭头全部是独立图层，由 FFmpeg Compositor 后期合成。直接动机是视频模型写不好中文，但真正的回报是经济性：用户改一个价格数字、挪一下贴字位置、换个 Logo——只重新合成，几秒出结果，视频模型一次都不用再调。配套的省钱设计还有：成片 16/27 秒里动态段只占 1~16 秒可配，静止尾段是提前截取的清晰关键帧拉长（「Live 感柔化收尾」用 FFmpeg blend 时间表达式做 0.25 秒柔化再回到清晰帧，零模型费用）；发布文案在视频任务创建后立即并行生成，不等成片，也绝不会重复触发视频调用。二创三版批量走数据库租约 + 逐卡检查点，失败重试只补缺失的图片，重复请求零 Planner 调用。

真人手写。 手抄式图文要的是「像真人写的」。这条路走了四个阶段，方向绕了整整一圈：最早想用 CSS 手写字体伪造——否，一眼假；第二阶段写了 CanvasHandwritingRenderer，用 @napi-rs/canvas 按字符做确定性扰动（旋转、基线、字宽、墨色、行倾斜，种子可重放），默认打包 SIL OFL 的霞鹜文楷——解决了重放和稳定，但本质还是字体渲染；第三阶段转向提示词工程，一天之内从 V5 迭代到 V18：纸纤维微压痕、笔压可见、掠射光、凹槽积墨、行草基线……每一版都在逼近真实，但也每一版都在「教模型表演手写」；最后在 V21 和 8 月 27 日的终版上想通了——别伪造，用真实样本。终版方案：A「清晰自然」/ B「日常随写」/ C「松弛连写」三档，弹窗里展示的全是本租户真实抓取、已完成 OCR 的笔记图片，配一个确定性的字迹摘要分类器（「潦草/连写/行草」归 C，「工整/楷写」归 A），用户必须亲自挑一张真实参考图；生成时 editImageText 带两张参考——第一张锁定当前页背景与文字区域，第二张只约束笔画动作、笔压、墨色、连写习惯，明确禁止复制样本内容。图片模型调用次数不增加，真实感却发生了质变。绕了一圈回到「数据比提示词诚实」，这是本项目我最认的一个产品结论。

六、效果#

11 周后交付了什么：

• 一个生产系统：云端多租户部署 + Windows 便携版双形态。创作链路（素材 → 策划 → 无字底片 → 合成 → 发布文案）全程服务端 Provider，前端零凭证。
• 87 个页面/路由的生产构建、201 个测试文件 / 1114 项测试全绿；生产构建从 37 个路由长到 87 个。
• 8 月 18 日到 27 日十天里十几次 release-*-full-replacement 整包替换发布，每次带发布前备份与回滚快照；期间最严重的一次线上事故——启动迁移把用户 6 页项目误重建为 1 页——也是先另存快照、再从发布前 SQLite 备份精确恢复到 revision 1141，没有丢过用户数据。
• 爆款采集链路：Chrome/Edge 扩展 + 本地 CDP 执行器，两阶段采集（搜索候选 + 详情补全），图片走 HTTPS 主机白名单 + MIME + 魔数校验后落私有 Asset（moduleScope 隔离，不污染通用素材库）；RAG 知识库 14 本书 / 3662 页 / 2438 片段，FTS5 + sqlite-vec 混合检索。
• 便携版从 261MB 共享凭证版进化到 223MB 自配版：包内零凭证（打包校验强制）、免登录、用户模型配置 AES-256-GCM 加密只存本机，敏感信息规则扫描在 tracked 文件与全部 git 历史中 0 命中。
• 给运营省下的真金白银：改文案/贴纸零视频成本重合成、批量二创失败只补缺失图片、付费前强制确认 + 每次调用记账、超时永不自动重试付费请求。

七、反思与后续#

做对了的：文档先行且执行顺序写进宪法、四大 Provider 边界第一天定死（后期所有「只改文字不重新生成」的收益都源于此）、Mock 默认 + 付费显式确认、Zod 与 TypeScript 双契约让 1114 项测试有了着力点、发布永远先备份、迁移永远幂等且跳过不该碰的项目。7 月 21 日第一个 commit 里就有 AGENTS.md，这份项目宪法让 AI 协作开发 11 周没有跑偏过边界。

没做好的：无标准数据库 migration，schema 靠 Prisma 与手写 DDL 幂等初始化共同维护，升级漂移风险一直挂着；8 月 19 日到 27 日九天冲刺密度太大，23 号一天修了七个 bug 说明前面的验收债欠了；git 提交在 8 月 18 日后基本停滞、大量成果长期躺在暂存区——10 月 8 日那场 70 文件回退事故之所以惊险，根源就是「工作只存在一个地方」；Turbopack 构建在本机因 PostCSS 子进程端口权限长期失败，靠 Webpack 兜底，始终没根治。

后续方向：Windows 真机双击验收和上架内部工具系统是眼前的事；数据库 migration 基线化必须排上；三风格手写的视觉终验还在等真实双用户浏览器隔离测试。以及一条留给自己的原则，跟上一套系统收尾时写的是同一句：宁可不动，也不乱动；宁可备份多余，也不信任单一副本。

一、为什么做这个系统#

我们是有直播电商投放团队的品牌方。投手的日常是这样的：几十个千川广告主账户散落在后台，看数据要挨个切；一场直播爆了，好素材要手动建追投任务；ROI 目标靠人在大屏前盯，每十五分钟看一眼消耗和成交，高了调低、低了调高；评论区的问题分散在各个抖音号下面，想按号归拢只能靠平台后台慢慢翻。

每一件事单看都不难，难的是「持续、及时、不出错」。人盯盘有两个致命问题：一是半夜盯不动，二是情绪化——数据一抖就手抖。所以我决定做一套系统把这些流程接进来：多账户 OAuth 授权管理、计划总览、素材追投、直播大屏、评价（评论）管理，最后加一个 AI 调价引擎，让「加多少减多少」这件事交给数据和模型判断。

二、系统全景#

上线后的形态（nginx + systemd 部署在一台云服务器上，域名就不公开了）：

1
浏览器（React 19 + Vite 8 单页应用，dist/ 静态产物）
2
   │  /api/* 反向代理
3
   ▼
4
Node 服务（127.0.0.1:8787，纯 Node 内置模块，无 Express）
5
   │  Access-Token 鉴权 + 频控退避
6
   ▼
7
巨量引擎开放平台（OAuth / 全域计划 / 调控任务 / 素材 / 评论 / 直播大屏 / 报表）

几个关键的技术选型说清楚：

• 后端零依赖。server/index.mjs 用 node:http 手写路由，一共几十个 API 路由，好处是生产服务器上连 npm install 都不用跑，rsync 上去重启 systemd 就完事。平台客户端独立在 server/oceanengine.mjs，AI 顾问在 server/ai-advisor.mjs。
• 前端不引组件库。React 19 + Vite 8，图标用 lucide-react，样式全部手写。整个前端几乎是两个大文件：src/main.jsx（约 54 万字符）和 src/styles.css。不体面，但一个月工期里这是最快收敛的方式。
• 共享契约层 shared/。调价决策核 bid-engine.mjs 是纯函数、无 IO、无依赖，Node 内置 test runner 直接跑 48 个用例。
• 数据存储是 JSON 文件（server/data/ 下的 oauth-grants.json、plans.json、audit-events.json、bid-bindings.json 等）。没有数据库。对一个单团队内部系统，文件 + 原子写 + 启动恢复够用，而且备份就是 cp。
• 测试是验收货币：npm run test:contracts（48 项契约测试）+ smoke + domain + build，后来又加了 48 项引擎纯函数测试和 21 项引擎服务端回环测试（用本地 mock 平台 scripts/local-e2e-mock.mjs 挡住真实外呼）。

功能模块（侧栏即产品）：账户授权管理、账户中控台、全域计划总览（行内补预算/调 ROI）、素材调控管理（素材列表 + 追投 + 调控任务）、批量创建计划（本地草稿）、AI 直播调价策略、评价管理、操作日志、系统管理（真实写入总开关、AI 模型配置）。

安全边界是第一天就定下的（项目根 AGENTS.md）：默认全只读；真实写操作（补预算/调 ROI/追投/回复评论）必须过「总开关 + 稳定幂等键 + 写入台账（SUBMITTING→RESPONDED 状态机）+ 审计 + 提交后自动回读核验」五道门；删除类平台操作在任何情况下拒绝（调控任务状态接口的 DELETE 枚举在服务端直接拦掉）。

三、开发周期复盘#

9 月上旬（9-08 ~ 9-13）：文档先行 + 对齐操作习惯。 第一天先写的不是代码，是 docs/PRODUCT_SPEC.md、DEVELOPMENT_PLAN.md、REUSE_STRATEGY.md。9-11 组装了 docs/ad-system/ 文档包：48 项功能逐项规格、48 个候选接口映射、64 条验收用例、21 个待核验问题。接口映射表里每个接口都标了核验深度（ENDPOINT_ONLY / PARAMETER_PARTIAL / SDK_VERIFIED），「接口存在」不等于「权限可用」，这句话后来救了我很多次。9-12~9-13 对照在用的老系统（飞流智投）逐页对齐交互——计划总览的筛选结构、27 列宽表、「+/准星」行内按钮的语义，都用无头浏览器截图核过。9-13 打通真实 OAuth：授权回调返回 ok，工作台账户接口展开出 68 个千川业务账户，uni_promotion/list/ 读到第一条真实直播全域计划。

9 月中旬（9-14 ~ 9-18）：读取链路工程化。 68 个账户 × 4 个场景 = 272 次只读请求，最初在浏览器里串行发，频繁撞 40100 频控。9-15 写了 docs/PLAN_READ_DESIGN.md，把读取搬到服务端持久化任务队列（plan-read-jobs.json）：全局限速、指数退避（60s/120s/300s）、断点恢复、重启不重读。9-16 动策略模块前先做了全量备份（_backup_pre_fix_20260916/，连 server/data/*.json 都记了 MD5），9-17 调整环境配置（留了 .env.bak-20260917163059），9-18 契约测试扩到 48 项全绿。

9 月下旬（9-19 ~ 9-23）：写链路与素材/评论模块。 9-19 接操作员登录（operator-auth.mjs，公网部署关闭自助注册）和评论只读接口；9-22 素材调控模块重构，重构前又做了一次带 SHA256SUMS 的全量备份（_backup_material_module_20260922_143636/，含恢复演练步骤）；同一天对着官方 Go SDK 逐字段核验素材/调控任务契约，9-23 直接在千川后台实测追投弹窗，拼出「视频追投与直播间画面追投是同一接口的两种对象」这个关键认知。

10 月上旬（10-03 ~ 10-07）：AI 调价引擎与评价管理冲刺。 10-03 核验直播大屏三件套接口并上线大屏视图；10-04 写部署文档、AI 评审接入做成页面在线配置；10-05 定下「规则只做约束、判断归 AI」的架构（这天下深夜还出过一次误删文件事故，后面细说）；10-06 白天给 AI 调价加「数据门」修振荡、完成 ROI 口径代数实证，晚上评价管理模块部署生产、真数据自验通过；10-07 上午还在迭代前端。

四、踩坑实录：每一条都有代码佐证#

五、AI 调价引擎：「规则只做约束、判断归 AI」#

六、效果#

一个月后回头看交付了什么：

• 一个生产系统：多账户 OAuth（token 自动轮换不掉线）、全域计划总览（行内补预算/调 ROI 真实写）、素材追投（幂等 + 台账 + 回读核验）、直播大屏、批量创建（本地草稿），前端 48 项 + 引擎 48 + 21 项测试全绿。
• 评价管理 10-06 上线当晚真数据自验通过，20 个授权号评论 20/20 全部归属成功。
• AI 调价引擎在「判断归 AI + 数据门」架构下振荡消失，危险动作层层设卡：AI 高危否决（AI_VETOED_HIGH_RISK）不自动执行、写入后回读不匹配自动冻结该计划、调价后连续 3 轮 ROI 偏差恶化自动暂停当日执行。
• 最值钱的资产其实是那套契约知识：48 个接口的核验深度标注、追投创建的「回显镜像」契约、ROI 口径实证——这些是用真实的 21 次失败换来的，全部固化在代码注释和 docs/ 里。

七、反思与后续#

做对了的：文档先行、核验深度分级（「接口存在」永远不等于「权限可用」）、默认只读 + 写入门禁链、大改前全量备份、决策核纯函数化。这五条让我在一个月里没有出过一次真实资金事故。

没做好的：单体文件太大了，index.mjs 43 万字符、main.jsx 54 万字符，接下来的第一件事就是按模块拆分；JSON 文件存储在多实例场景会到瓶颈，迁移 PostgreSQL 的设计文档其实早就写了，一直没排上；追投编辑接口对 duration 的语义（update 支持 1.5~24 小时）和 create 不同，这块的用户提示还不够直白。

后续方向：把 AI 判断的离线回测跑起来，用历史直播数据对比「AI 调价 vs 人工调价」的 GMV 和利润差；素材侧接上高潜识别，让追投建议也从「人挑」变成「数据挑」；再往后是托管策略的完整闭环——但每一步都会继续守着那条红线：宁可不动，也不乱动。

Gemini 4 Argon：谷歌的「掀桌」时刻（9 月 30 日）#

在 OpenAI 和 Anthropic 相继发布新旗舰之后，谷歌于 9 月 30 日拿出 Gemini 4 系列首款旗舰 Argon，官方定位是「迄今最先进的 AI 模型」：

• 真实世界软件工程任务创下纪录——不是刷基准，是声称在真实工程场景里跑出了新高度
• 网络安全能力并列第一，但初期只向受信任的网安机构和人员开放测试，没有全面放开
• 多模态专业场景：能分析专业图表、从长视频中定位内容，面向法律、金融、企业知识工作和长周期复杂任务做了重点优化
• 安全侧强调防「越狱」，发布的同时就把对抗性攻击的防护放在了台面上

社区的反响相当热闹：有评测认为它追平了 GPT-6 Astra，也有讨论用「谷歌 80 万行内核已被重写」这样的说法暗示其自我改进能力（这条属于社区渲染，看看就好，以官方口径为准）。但共识是——沉寂了半年多的谷歌，这一手确实把牌桌掀了。

OpenAI DevDay 2026：从「卖 Token」到「雇 AI 员工」#

本届 DevDay 在旧金山举行，一口气推出 20+ 项更新，主线只有一个：ChatGPT 全面转向智能体平台。

Anthropic：一个数字和一次「打脸」#

国内：云栖大会，芯片是主角#

暗线：自建模型潮#

还有一条不那么显眼但影响深远的线：AI 初创公司开始逃离对 OpenAI/Anthropic 的依赖。模型调用成本持续攀升，越来越多团队转向可自行下载、修改、微调的开放模型。芯片侧的呼应是 Positron AI 拿下 8.75 亿美元 C 轮（投后估值 50 亿美元）。当「头部闭源 API」不再等于「唯一选项」，生态的重心才会真正多元化。

我的观察#

1. Agent 从 API 特性变成了产品本体。 上个月还是「异步工具调用」这种工程特性，这个月已经是 Dots、ChatGPT Space 这种直接面向用户的产品形态。迁移速度比大多数人预想的快。
2. 「AI 参与 AI 研发」开始有刻度。 26% 这个数字的意义不在大小，而在于头部实验室愿意把它当常规指标定期公布——递归自我改进从论文用语变成了运营数据。
3. 底座之争并行于模型之争。 真武 V900、智算规划、自建模型潮、开源生物分子模型，指向同一件事：模型层的热闹之下，算力与开放生态的结构性竞争已经开场。

资料来源#

• 新浪财经：谷歌推出最先进的 AI 模型 Gemini 4 Argon
• 腾讯新闻：Gemini 4 震撼发布
• 财新：谷歌发布 Gemini 4 模型，强调安全防「越狱」
• bytechap：OpenAI launches Dots agents and a $500 monthly Pro tier at DevDay 2026
• 通信产业：OpenAI DevDay 2026，Agent 加速与安全裂痕并行
• 凤凰网：从零到 26%，Claude 已主导公司下一代模型的部分研发
• Yahoo News：Anthropic says it stopped AI misuse for cyberattacks, propaganda and bioweapons
• 搜狐：阿里平头哥真武 V900 亮相，2027 年量产
• 网易：云栖大会的更大看点，阿里把 AI 当基建
• 钜亨网：AI 初创掀自建模型潮

超级发布周：三天四家#

9 月初出现了罕见的「超级发布周」：Anthropic、Google、Meta、OpenAI 在三天内先后发布新模型，单月统计有 22 项 AI 相关发布。密度高到评测机构都来不及跑分。

国产阵营：降价与冲榜#

我的观察#

把这几件事放在一起看，有三条趋势值得记住：

1. Agent 是所有发布的主线。 异步工具调用、中途引导、缓存友好的推理调整——新特性几乎全是为长时间运行的智能体设计的，而不是为了聊天。
2. 价格战开打了。 缓存降价、Flash 档位降价，说明 token 成本曲线还在快速下探，重度 Agent 应用的基础设施账算得过来了。
3. 开源与闭源的差距在收窄。 Meta 与国产开源模型冲进前十，“必须用闭源旗舰”的假设越来越不成立。

资料来源#

• Claude Fable 5.1 vs GPT-6 Astra：编程、Agent 与成本
• 30 款主流 AI 大模型排行榜（2026 年 9 月）
• AI 大模型评测排行榜（Datalearner）
• Meta 发布 Muse Spark 1.3（钜亨网）
• 智谱 GLM-5.3 官方文档
• 新浪 AI 投资峰会报道

症状：网站中间空白，刷新也没用#

最先发现的是用户反馈：AI 应用平台打开后只有头尾、中间一片空白，刷新也不行。

“刷新不好使”这个细节很关键——它排除了最常见的”静态资源缓存问题”（那种刷新就好了）。我用无头浏览器渲染页面并对照 nginx 访问日志，发现真正的异常是：

1
GET /api/user/get/login  →  500

前端是”先查登录状态、再渲染主界面”的模式，接口 500，页面就停在空白。

顺着 500 往下挖#

应用日志里的报错很反常：

1
READONLY You can't write against a read only replica.

一台独立部署的 Redis，怎么会是”只读副本”？查复制状态：

1
role:slave
2
master_host:175.24.232.83
3
master_link_status:down

我的 Redis 被人配置成了另一个 IP 的从库——而且那个主库根本连不上。应用往 Redis 写 session 被拒绝，于是接口 500。

SLOWLOG：攻击者留下了完整作案记录#

Redis 的慢日志记下了精确到秒的时间线，两个攻击者，两次入侵：

第二次那两条命令组合是标准的数据外带手法：把被控 Redis 设成攻击者的从库，主库会把全量数据同步过去，等于打包偷走。配套的 stop-writes-on-bgsave-error no 是为了保证 RDB 快照能顺利生成。

回头看，9 月 16 日的 FLUSHDB 其实已经是响亮的警报——那天所有用户都被登出过，只是没人把它和”入侵”联系起来。

入口：一个 2016 年就有的老洞#

弱密码 root，加上 6379 对公网开放。十年前的入侵套路，2026 年照样打得穿。

这里有个很多人栽过的坑：我服务器上 ufw 明明是”默认拒绝”、放行列表里根本没有 6379，为什么外网还是连得上？——Docker 会绕过 ufw。容器把端口发布到 0.0.0.0 时，Docker 直接往 iptables 里插规则，优先级高于 ufw。所以 ufw 界面看着滴水不漏，实际上数据库端口全网裸奔。

取证：先确认失陷范围，再动手修#

确认入侵后我没有急着删删改改，而是先做取证——清了就没了。逐项排查：

• MODULE LIST → 空（无后门模块）
• CONFIG GET dir / dbfilename → 正常值（没被改成写 SSH key / 计划任务的目标路径）
• 挖矿进程、UID=0 异常用户、对外连接（C2/矿池）→ 全部干净
• SSH 七天内无密码登录成功记录，authorized_keys 只有合法密钥
• 计划任务只有腾讯官方组件和证书续期
• Redis 容器非特权模式、独立网络栈 → 没有逃逸到宿主机

结论：失陷范围仅限 Redis。泄露的内容是约 45 个键，几乎全部是 spring:session:*——全部用户的会话令牌，攻击者可以冒充任何已登录用户。而 jar 包里的模型 API Key、对象存储密钥没有经由这条路径泄露。

修复：顺序很重要#

我的处置顺序是止血 → 取证 → 轮换凭据 → 收口网络 → 作废赃物 → 加固入口：

1. 止血：REPLICAOF NO ONE 断开外带通道。一条命令同时止住数据外带和业务中断
2. 凭据轮换：Redis 密码换成 48 位随机值，旧密码实测被拒
3. 收口网络：把 Redis 和 MySQL 的 Docker 端口映射从 0.0.0.0 改绑 127.0.0.1（釜底抽薪，不跟 ufw 缠斗），外网实测两个端口关闭
4. 改应用配置：数据库连接从公网 IP 改为 127.0.0.1——顺便说一句，配置里那个公网 IP 是”服务器连自己”，流量本来就不出机器，改成本地地址是等价且更清晰的
5. 作废赃物：FLUSHDB 清空全部会话。这步最容易被漏掉——不作物废，攻击者偷走的令牌在修复后依然有效
6. 加固入口：SSH 关闭密码登录（只留密钥）、管理面板换随机安全入口 + 开防爆破

修复后全量回归：网站、评论区、AI 平台全部恢复正常。

复盘：三个教训#

1. “看着关了”不等于”关了”。 ufw 显示没放行、外网却能连——Docker 绕过 ufw 是部署期就该知道的坑。端口安全要从外网实测，不能只看防火墙界面。

2. 告警的缺失让事件拖了两天。 9 月 16 日的 FLUSHDB 让所有用户掉线，那本该是发现入侵的时刻，实际却拖到 18 日业务挂掉。键数一夜清零、role 从 master 变 slave、日志出现 READONLY——任何一条接上告警，事件当天就能被处理。

3. 处置顺序决定二次伤害。 先取证再清理（证据不能再生）；先改密码再关端口（单改一样都会留下窗口）；修复完必须作废被窃的凭证（尤其是会话令牌这种”看不见的赃物”）。

给你的清单#

如果你也有公网服务器，花两分钟自查：

1
# 端口从外网实测（不是看防火墙界面）
2
nc -z -w 5 你的服务器IP 6379
3

4
# Redis 弱密码 + 复制状态
5
redis-cli -a 你的密码 INFO replication | grep -E "^role|master"
6

7
# 有没有奇怪的慢日志
8
redis-cli -a 你的密码 SLOWLOG GET 10

数据库端口绑 127.0.0.1、强密码、关 SSH 密码登录——这三件事做完，这类攻击的入口就基本堵死了。

本文细节已做脱敏处理（隐去服务器地址与管理入口）。攻击者 IP 保留原文，作为事件证据。

变化在哪里#

传统的 LLM 调用通常是“请求一次、返回一次”。智能体要连续工作，就必须额外处理上下文压缩、任务恢复、工具失败、环境持久化和权限边界。Agents API 把这些问题放进运行时，开发者可以把更多精力放在业务工具和评估上。

一个可维护的智能体通常至少需要四层：

1. 任务层：把用户目标拆成可检查的步骤。
2. 上下文层：保存对话、文件和中间结果，并在接近上限时压缩。
3. 工具层：以明确的输入输出契约连接搜索、代码、数据库或内部系统。
4. 恢复层：记录每一步状态，失败后能够重试、回滚或交给人工处理。

对个人项目的启发#

如果只是做问答，直接调用模型 API 就够了。如果要做自动整理资料、生成周报或维护代码，建议先把工具调用设计成幂等操作，再为每个工具记录耗时、错误和副作用。这样即使智能体重试，也不会重复发送邮件、写入订单或覆盖文件。

我会把这类系统的最小闭环定为：目标 → 计划 → 工具调用 → 结果校验 → 可恢复状态。模型负责推理，业务代码负责边界和事实，二者不要混在一段提示词里。

原始来源：Introducing the Agents API。

安全问题已经从“回答什么”变成“能完成什么”#

当模型可以调用工具、编写代码、访问浏览器和连续运行时，风险不再只来自一条危险回答。攻击者可能把多个普通能力串成完整流程：收集数据、建立账号、生成内容、运行脚本，再通过自动化扩大规模。

因此，安全控制不能只放在提示词里，至少还需要：

• 身份与权限：为高风险工具绑定最小权限和短时令牌。
• 行为监测：观察工具调用序列、访问频率和异常资源使用，而不是只检查文本。
• 可撤销性：让账号封禁、任务停止和密钥轮换可以快速执行。
• 跨组织协作：在不泄露用户隐私的前提下，共享指标和攻击特征。

报告还提醒开发者，未经授权的模型蒸馏会把敏感数据和高能力输出一起带出系统。生产环境应该明确数据保留、日志访问和第三方路由边界，尤其不要把 API 密钥、内部文档或个人数据直接交给不受控的代理链路。

安全不是发布前的一次审核，而是贯穿模型、工具、账号和基础设施的持续反馈回路。

原始来源：Detecting and countering misuse of AI: September 2026。

为什么全双工重要#

传统语音应用常见的链路是 语音识别 → 文本模型 → 语音合成。这条链路容易出现三个问题：模块之间要反复传递状态，用户打断时需要取消多个请求，系统还要自己判断什么时候算一句话结束。

全双工模型把输入和输出音频放在同一个交互循环中，打断处理变成模型能力的一部分。OpenAI 在发布说明中提到，早期评估里 Speak 的语言学习场景将打断次数降低了接近 80%；这类结果仍然需要结合自己的场景和指标复测。

接入时要注意什么#

• 把工具调用放到后端：语音模型负责对话节奏，订单、检索和写入等动作仍由服务端鉴权。
• 设置明确的打断策略：用户重新说话时，前端要立即停止播放，并保留未完成请求的取消信号。
• 记录音频延迟：拆分首包延迟、端到端响应延迟和用户打断恢复时间，不能只看模型生成速度。
• 给长会话做摘要：实时音频上下文会快速增长，应该按主题或任务生成短摘要，避免无限累积。

对于客服、语言练习和语音导航，降低等待感比增加一堆按钮更重要。全双工的价值最终要用“用户是否愿意继续说下去”来验证。

原始来源：Build more natural voice experiences with GPT-Live-1 in the API。

工程上应该留下什么证据#

一个可以被审计的 AI 功能，至少应该记录：

1. 使用的模型版本、系统提示和工具清单。
2. 每一次外部操作的参数、权限和返回结果。
3. 被拒绝、被人工接管和失败重试的原因。
4. 评估集版本、回归结果和已知限制。

这些信息让团队知道“系统为什么做了这件事”，也让问题出现后能够复盘，而不是只剩下一段聊天记录。

把安全门槛做成发布流程#

在模型或工具升级时，可以把关键安全评估接入 CI：先运行越权、敏感数据泄露和工具滥用测试，再比较能力指标是否出现异常跳升。对于会发送消息、修改文件或操作账户的智能体，还应增加人工确认或可撤销窗口。

安全机制的目标不是让系统什么都不做，而是在系统能力变强时，让风险边界、监测信号和停止按钮同步变清楚。

原始来源：The AI policy window is open. We need to act.。

一个值得关注的信号#

截至 2026 年 8 月，文章称研究组织每天使用的智能体工作量约为人类工作日的 3.1 倍。这个数字不是“模型替代了多少人”，而是说明研究人员开始同时运行多个智能体，把它们当作可并行的实验助手。

更容易自动化的是写胶水代码、排查实验基础设施、生成评估脚本和整理运行结果。更难自动化的是提出真正有价值的研究问题、判断实验是否公平、识别数据泄漏，以及决定一个结果是否值得投入更大算力。

对工程团队的三个建议#

1. 先做可重复的实验入口：把环境、数据版本、参数和评估命令写进脚本，智能体才有可靠的执行边界。
2. 把评估当作产品：每次修改都自动记录基线、失败案例和回归结果，避免只看一个漂亮的平均分。
3. 把人放在决策节点：模型可以提出假设、写代码和跑实验，但研究结论、发布和高风险操作需要人工复核。

智能体的价值不只是节省几分钟打字时间，更在于把原本串行的试错过程变成可以并行探索的工作流。前提是，团队必须先把实验过程变得可观测、可回滚、可比较。

原始来源：Research acceleration: The view inside OpenAI。

这个项目解决什么问题#

新库首批发布了 207 个 Apache-2.0 许可的 WebGPU 内核。每个内核都带有接口契约、正确性用例、基准用例和 WGSL 着色器模板，应用可以按版本加载，而不必依赖一条无法复现的远程脚本。

这种组织方式很适合浏览器推理：上层运行时负责图和张量，下层内核负责在不同 GPU 和浏览器上选择更合适的实现。Hugging Face 还发布了 Fleet，用来收集真实设备上的正确性与性能证据。

如何理解性能数据#

发布文章在 Apple M4 上将 809 个可比用例与 ONNX Runtime Web 进行比较，给出的几何平均加速约为 2.57 倍，中位数约为 1.90 倍。这是单个操作的 GPU 执行时间，不是完整模型端到端速度；模型加载、编译、数据上传和结果回读仍然会影响最终体验。

如果你要在前端尝试本地 AI，可以按这个顺序排查：

• 先确认浏览器存在 navigator.gpu。
• 用真实设备测量，而不是只看桌面开发机。
• 分开统计 shader 编译、首 token、稳态吞吐和显存占用。
• 给每种输入形状保留基准，避免只优化一个 demo。

WebGPU 的价值在于把推理带回用户设备，但可复现的内核契约和设备侧基准，才是让它从演示走向产品的基础。

原始来源：Introducing @huggingface/kernels: 200+ WebGPU Kernels for Local AI。