全部文章 on fomoxx

Multica 到底是减负还是增负：一次真实 Squad 工作流后的复盘

Sun, 20 Sep 2026 13:00:00 +0800

这篇不是 Multica 入门教程。如果你还在了解 Issue、Agent、多机调度和基础 Workflow，先看 Multica 使用指南；这里直接往下一层，复盘 Squad 在真实多阶段任务里的 Leader 调度、handoff 和 Review。

单点功能跑通，和真正把一套完整的多 Agent 流水线放进实际业务场景跑，完全是两回事。

我把手头一个真实的多阶段任务放进 Multica，跑了一轮完整的 Squad 协作。这个任务并不是为了测试 Multica 临时捏造的 Demo，而是一套需要多角色接力的真实多阶段工作流，包含前置分析、任务拆分、多角色处理、关键结果核对以及独立审查。

这次实验最终完成了任务，但中间也让我第一次真正体会到 Multica 的核心矛盾：

它确实能把多个 Agent 组织起来，但“组织 Agent”本身也会变成一项工作。

所以这篇不再重复安装教程，也不打算回答“Multica 好不好用”这种过于笼统的问题。我更想记录：在一次真实 Squad 工作流里，它到底在哪些地方替我减负，哪些地方又把我变成了 Agent 管理者。

测试边界：这篇文章记录的是我在自部署 Multica 中跑的一次真实多阶段 Squad 任务，不是官方 Benchmark。原始测试没有锁定精确版本，因此我只把“我实际观察到什么”作为第一手结论；产品当前机制、后续版本修复和社区 Issue 则分别引用并单独说明，不把相似现象直接当成同一根因。

先说结论：它改变的不是执行速度，而是工作形态

Multica 当前仍把自己定位成一个 Agent workspace：把 Issue 分配给 AI coding agent，Agent 在你控制的 Runtime 上执行，持续写回进度和结果，再把工作交回 Review。

官方当前的 How Multica works 和 Squads 文档里，这个思路很清楚：

Issue 保存任务上下文、讨论和负责人；
Runtime 负责真正执行；
Squad 由一个 Leader 和若干成员组成；
Squad 收到任务后，先唤醒 Leader；
Leader 根据上下文决定把下一步交给谁。

这套结构解决的不是“单个 Agent 能不能写代码”，而是：

两轮前端设计实验：我让 GPT、Gemini、Claude、Kimi、Grok、GLM、MiniMax 各自做网页，AI 真的有稳定审美吗？

Thu, 17 Sep 2026 13:00:00 +0800

两轮测试后的结论：AI 前端并没有收敛成同一种审美。不同模型 / Harness 在低约束设计任务中反复暴露出明显不同的设计偏好：OpenAI 更擅长实体空间与成熟商业品牌，Gemini 偏概念与互动实验，Claude Sonnet 更像产品 / 品牌设计师，Kimi 擅长中文 typography 与 editorial，Grok 偏电影与舞台感。与其寻找一个「审美最强」的模型，不如利用这些稳定偏差组成一个多模型设计竞标池。

如果你经常用 AI 生成前端，大概率对这个场景不陌生：十个 AI 做的网页，八个长得差不多——大标题、圆角卡片、紫蓝渐变、玻璃拟态、三列功能区。我一直在想：为什么 AI 做出来的前端越来越像？有没有办法让不同模型真正给出不同的设计方向？

这篇文章记录了两轮测试。第一轮用「一个独立开发者的 AI 造物档案」做主题，观察各模型自己的设计 prior；第二轮换成完全不同的题材「一家只在雨天营业的深夜甜品店」，把模型赶出 AI / 开发者审美舒适区，Claude 也在这一轮加入。两轮之后，每个模型家族稳定的设计人格已经相当清楚。

为什么换掉原来的工作流

过去我的流程是：ChatGPT 先出设计图，再让 GPT / Kimi / 其他 Coding Agent 照图实现。问题很明显——最终页面很容易落回同一种 AI 风格。

这次我改了玩法：直接让模型自己承担 Art Director + Frontend Developer 的角色。不给明确视觉风格，只规定主题、内容结构和禁止项，要求 one-shot 交付完整 HTML，以此观察模型自己的设计 prior。

测试方法与边界

两轮使用各自的同一 Prompt，不同模型跑同一条题。
只允许生成一个可直接运行的完整 HTML；CSS / JS 内联。
不依赖图片素材，需要图形时自行用 CSS / SVG / Canvas 创作。
同时观察桌面端与 390px 左右移动端。
重点不是代码 benchmark，而是：Art Direction、视觉差异化、排版、配色、原创图形、交互、成品感、响应式。
Harness 与模型没有完全解耦，因此这不是纯模型 benchmark。除 Pi 内部 High / Max 外，大部分结果只能解释成「模型 × Harness」的组合表现。
第一轮 Gemini 3.8 Flash 因工作目录异常，结果作废。随后分别在 Antigravity CLI 与 Antigravity IDE 重新生成，两份新结果纳入最终比较。

第一轮的原始测试 Prompt

请设计并实现一个完整的单页 HTML 网站，主题是：

腾讯云轻量应用服务器不支持自动快照：用本机脚本 + systemd timer 实现双槽位轮换

Tue, 15 Sep 2026 13:00:00 +0800

腾讯云轻量应用服务器没有自动快照功能，我的实例又只有 2 个快照槽位。如果只靠手动创建，恢复点很快就会被用完，或者干脆想不起来做。最后我用一个跑在服务器本机的脚本调用腾讯云 API，自动删除最旧的自动快照、再创建一个新快照，由 systemd timer 每周日凌晨 04:30 触发一次。

先把最终方案放在前面，只想抄作业的读者可以直接用这套配置。

快速解决

两个快照槽位全部用于自动快照，不保留固定人工基线。
自动快照统一使用 Auto-Snapshot- 前缀，脚本只删除这个前缀下的快照，其他名称的人工快照默认受保护。
每周执行一次，时间为每周日 04:30，由 systemd timer 调度，不用 Cloudflare Workers，也不用传统 cron。
Timer 设置 Persistent=false：如果服务器在计划时间没有运行，本周直接跳过，恢复开机后不补跑。
脚本运行在被备份的轻量云本机。这样服务器发生严重故障、脚本无法运行时，不会有外部调度器继续创建可能已经损坏的新快照并覆盖旧恢复点。

环境

项	值
实例	`lhins-xxxxxxxx`（替换为自己的实例 ID）
地域	`na-siliconvalley`（美国西部 / 硅谷）
脚本路径	`/root/tencent-snapshot.sh`
自动快照前缀	`Auto-Snapshot-`
保留数量	`2`

脚本顶部的关键配置：

TENCENT_SECRET_ID=""
TENCENT_SECRET_KEY=""
TENCENT_REGION="na-siliconvalley"
INSTANCE_ID="lhins-xxxxxxxx"

SNAPSHOT_PREFIX="Auto-Snapshot-"
KEEP_SNAPSHOTS=2

SecretId 与 SecretKey 直接写在这台服务器的本地脚本里，只保留在服务器本地，不要同步到任何云端笔记或版本管理。脚本文件权限：

chmod 700 /root/tencent-snapshot.sh

CAM 权限

快照脚本使用独立的 CAM API 密钥，只授予快照相关权限：

{
 "version": "2.0",
 "statement": [
 {
 "effect": "allow",
 "action": [
 "lighthouse:DescribeAllSnapshotsOverview",
 "lighthouse:DescribeSnapshots",
 "lighthouse:DescribeSnapshotsDeniedActions",
 "lighthouse:CreateInstanceSnapshot",
 "lighthouse:DeleteSnapshots"
 ],
 "resource": [
 "*"
 ]
 }
 ]
}

测试时踩过一个坑：调用创建快照报 UnauthorizedOperation.NoPermission，检查后发现是策略里漏了 lighthouse:CreateInstanceSnapshot，补上之后创建成功。

把本地 stdio MCP 接入 ChatGPT Web：OpenAI Secure MCP Tunnel 实战与排障（以 Google Analytics 为例）

Tue, 08 Sep 2026 13:00:00 +0800

如果你手里有一个只能在本机通过 stdio 启动的 MCP Server，又希望在 ChatGPT Web 里直接调用它，通常会遇到一个核心矛盾：本地客户端（如 Claude Desktop 或本地 Agent）可以直接拉起本地进程，但 ChatGPT Web 运行在云端，不可能跨到你的电脑上执行命令。

OpenAI 官方提供的一条打通路径是使用 Secure MCP Tunnel，它可以在不把本地 MCP Server 暴露到公网的情况下连接 ChatGPT Web：

本地 MCP Server（stdio）
 ↓
OpenAI Secure MCP Tunnel（tunnel-client）
 ↓
ChatGPT Web / Developer Mode / 自定义 MCP 应用

本文记录我把 Google 官方的 google-analytics-mcp 运行在 macOS 本机，通过 OpenAI Secure MCP Tunnel 接入 ChatGPT Web，并在对话中直接查询 GA4 数据的完整部署过程。

Google Analytics 只是本次使用的具体案例。更关键的是解决一套通用的工程问题：

本地 stdio MCP 如何让云端 ChatGPT Web 发现与调用；
为什么不需要开放路由器端口转发或配置公网反向代理；
MCP Server、Tunnel、ChatGPT 工作区三层如何独立验证；
Google OAuth、环境变量、本地代理与后台守护进程分别会在哪一层出错；
如何把终端一次性运行的命令，做成 Mac 重启也能稳定工作的长期常驻服务。

最终验证结果：ChatGPT Web 成功发现该 MCP，正常读取到有访问权限的 GA4 properties，并顺利执行了 Analytics report；本地 Tunnel 也已经交付 macOS launchd 守护常驻。

Codex App 经 CLIProxyAPI 接入中转站报 400（instructions_required）的排障与修复

Fri, 04 Sep 2026 13:00:00 +0800

在将 Codex App 通过 CLIProxyAPI（CPA）接入第三方中转站时，遇到了请求直接失败的问题。服务端返回了 400 错误，提示缺少 instructions 参数。

如果你也遇到了完全相同的报错，可以先直接参考下面的可用配置进行修复；后文记录了具体的定位过程、失败尝试以及参数处理细节。

快速解决（最终可用配置）

编辑 CPA 的配置文件（/opt/cpa-deploy/config.yaml），加入以下配置项：

codex-instructions-enabled: false

payload:
 default:
 - models:
 - name: "gpt-*"
 protocol: "codex"
 params:
 "instructions": "Follow the instructions provided in the input."

修改保存后，进入部署目录重启 CPA 容器：

cd /opt/cpa-deploy
docker compose restart cli-proxy-api

重启完成后，Codex Desktop 恢复正常使用。

错误现象与环境信息

在 Codex App 发送请求后，接口直接返回如下 400 错误信息：

instructions_required · 400
The instructions parameter is required and must be a non-empty string.

本次涉及的运行环境与组件版本如下：

项目	配置 / 版本
部署方式	Docker Compose
CPA 镜像	`eceasy/cli-proxy-api:v7.2.147`
容器名	`cpa-cli-proxy-api`
Compose 文件路径	`/opt/cpa-deploy/docker-compose.yml`
CPA 配置文件	`/opt/cpa-deploy/config.yaml`
Codex App 版本	`0.152.1`
请求接口	`/v1/responses`

问题原因

排查后发现，问题既不是 Codex App 客户端故障，也不是上游模型不可用，而是 CPA 生成的空参数与该中转站的校验规则发生了冲突：

我为什么把评论系统部署在 VPS + SQLite

Mon, 06 Jul 2026 13:00:00 +0800

我最近想给博客加评论系统。

一开始看了一圈方案，发现评论这件事很容易被做复杂：GitHub Issues、Discussions、Vercel、Serverless、云数据库、对象存储、验证码、邮件通知、反垃圾服务。每一个单独看都不难，但拼在一起，就会变成一个小型运维项目。

我的需求其实很朴素：

不想把评论托管到 GitHub。
不想为了评论系统再引入一堆云服务。
数据最好在自己手里，能备份，能迁移。
早期博客流量不大，不需要一上来就搞复杂架构。

所以最后我选了 Waline，并且准备直接部署在自己的 VPS 上，用 SQLite 存评论数据。

这不是最“现代云原生”的方案，但它足够简单，也足够可控。

为什么不是 GitHub 托管评论

GitHub Issues 类评论系统最大的好处是轻。比如 utterances、giscus 这类方案，本质上是把每篇文章对应到 GitHub 的 issue 或 discussion，前端加载一个组件，评论就能跑起来。

如果博客本来就是面向开发者，并且读者都有 GitHub 账号，这确实很舒服。

但我不太想这么做。

第一，评论数据不在自己手里。它当然可以导出，但日常形态还是依赖 GitHub。哪天想迁移，评论和文章之间的映射、用户身份、回复关系，都要再处理一次。

第二，评论门槛变高。很多读者只是想随手留一句话，让他登录 GitHub，心理成本其实不低。

第三，我不希望一个中文个人博客的互动入口默认绑定到开发者平台。博客可以聊 AI、工具、交易、内容运营，也可以聊一些更日常的东西。评论系统最好别先替读者筛选身份。

所以我的方向是：评论系统可以轻，但数据要尽量留在自己这边。

为什么选 Waline

Waline 对我来说比较像一个平衡点。

它不是只有前端组件，也不是完整论坛系统。它有服务端，有管理后台，有数据库，也有比较成熟的博客主题集成。对 Hugo 来说，接入成本很低。写这篇文章时我还在使用 Dream 主题，它本身就支持 Waline；现在站点已经不再依赖 Dream，但 Waline 仍通过自有 Hugo partial 接入。

我看重的点主要有几个：

可以匿名评论，不强迫读者用 GitHub 登录。
有后台管理，评论、审核、用户都能看。
支持评论审核，刚上线时可以先人工放行。
支持多种数据库，早期可以 SQLite，后面需要再迁移。
前端接入轻，Hugo 里加一段配置或 partial 就够。

它不是最强大的社区系统，也不应该被当成论坛。但给个人博客做评论区，刚好合适。

为什么不用 Vercel + 云数据库

Waline 官方推荐过 Vercel 这类部署方式，早期博客用免费额度也确实能跑。

本金太小时，先别急着把投资当出路

Tue, 02 Jun 2026 13:00:00 +0800

有句话我一开始听着挺不舒服：低于 10 万现金，就先别急着做交易、做投资。

这话很容易被听成“钱少的人不配投资”。但它说的其实是另一个更现实的问题：本金太小时，投资收益不够改变生活，交易波动却足够影响情绪。

小本金可以投资吗

可以，但更适合把它当市场练习，而不是改变生活的主要出路。

这个阶段先别急着把收益率拉满，更该认识自己在亏损、盈利、波动和诱惑面前会怎么反应。

很多人刚开始接触投资，会先盯收益率。10%、20%、30%，听起来都挺诱人。但落到钱上，体感完全不同。

一万美元赚 20%，是两千美元。十万美元赚 20%，是两万美元。一百万美元赚 20%，是二十万美元。

同样的收益率，对生活的意义不一样。

小本金最尴尬的地方就在这里。你花很多时间研究、盯盘、复盘，最后赚的钱可能还不如把这些精力放回工作、业务或者技能提升。

更麻烦的是，人很容易嫌正股慢，然后转向期权、杠杆、财报赌博和重仓短线。短期看是在追求效率，长期看可能是在训练一套以后会很贵的坏习惯。

账户还没长大，坏习惯先长出来了。

所以我现在更愿意把“10 万现金”理解成一个提醒，不把它当死规则。这里说的也不是全部积蓄，更不是生活应急钱，而是可以拿出来承担市场风险的那部分现金。

房租、家庭支出、债务偿还、未来几个月要用的钱，都不该被算进去。

多少钱适合开始投资

没有一个适合所有人的硬门槛。

更重要的是这笔钱是不是“可承担风险的钱”：亏掉一部分，不会影响房租、家庭支出、债务偿还和未来几个月的生活安排。

当本金还小、现金流不稳、应急资金不足时，先提高收入和储蓄率，往往比研究哪只股票更能改变长期结果。

这听起来不刺激，但对普通人很实际。投资不是逃离工作的捷径。大多数人的财富路径，还是先靠工作和业务积累本金，再让投资慢慢放大结果。

前面没有现金流，后面谈复利会很空。

当然，小本金不是不能进市场。可以买一点正股，熟悉市场；也可以拿很小的仓位练习交易，知道自己在什么情况下会慌、会贪、会乱操作。

但要诚实：这是练习，不是靠市场翻身。

我现在对小本金阶段的看法很简单：

先提高收入。
攒下能承担风险的钱。
用小仓位熟悉市场。
后面再谈长期配置和更复杂的交易。

有些习惯在小账户里看起来只是亏几百、亏几千。等账户大了，同样的习惯会贵很多。

市场一直都在，不差这一两年。真正要准备的是本金，以及稳定面对波动的心态。

企业级 Agent 不一定要多 Agent

Sat, 23 May 2026 13:00:00 +0800

前段时间我复盘了一个真实的 AI 接待系统，发现一个容易被忽略的点：

很多企业场景里，好用的 Agent 架构不一定是多个 Agent 互相协作，而是一个 Agent 被一套稳定流程约束住。

系统要先告诉 Agent：

现在处在哪个业务阶段。
当前阶段要完成什么。
可以调用哪些工具。
什么情况下进入下一步。
什么情况下必须停下来转人工。

这类架构我一般叫它 SOP Agent。

它的重点是让 AI 在正确边界里工作。

SOP Agent 是什么

SOP Agent 是把大模型放进业务流程里的 Agent 架构。

在这种架构里，LLM 更像理解和表达层：它负责读懂用户的话，生成自然回复，判断可能的下一步。能不能跳转阶段、能不能触达用户、能不能调用高风险工具，由状态机、规则系统和业务仲裁决定。

这和“给模型一段长 prompt，让它自己按流程执行”不是一回事。真实业务里，状态会跨会话存在，用户会反复回来，工具也有风险等级。这些东西不能长期交给上下文窗口。

为什么不是所有业务都需要多 Agent

现在很多人一提 Agent，就会想到 Deep Research 那种结构：主 Agent 拆任务，多个子 Agent 分头搜索，最后汇总成报告。

这种模式当然有价值。开放式研究、陌生行业调研、复杂资料搜集，都适合多 Agent 并行。因为一开始不知道要查多少资料，也不知道会遇到哪些信息缺口。

但企业里有很多任务不是这种形态。

客户接待、售前咨询、订单处理、售后回访、投诉分流，它们的难点不是“信息覆盖不够”，而是流程不能乱。

客户刚进来，系统要识别需求；客户表达兴趣，系统要确认关键信息；客户问到具体问题，系统可能要查知识库或订单系统；客户已经接近成交，系统要处理顾虑；客户出现不满，系统要切到安抚和人工介入。

这些事情如果全交给一个自由发挥的 Agent，它可能会提前推进流程、重复问用户已经回答过的问题、在错误阶段调用错误工具，或者在用户已经不满时继续按销售逻辑往下走。

这类业务要的不是更自由的 Agent，而是更稳定的流程控制。

流程型业务先看状态

很多 Agent 文章会强调规划能力：给一个复杂任务，Agent 先拆步骤，再调用工具，再根据结果调整。

这对研究任务很重要。但流程型业务里，更大的问题是系统知不知道客户现在走到了哪一步。

一个客户不会只聊一轮。他可能今天问几句，明天回来继续聊，三天后才下单，一周后又回来问售后。中间每一步都有状态：他提供了哪些信息，关注点是什么，是否确认方案，是否付款，是否表示过犹豫，是否需要回访，是否进入人工处理。

如果这些状态只靠上下文窗口保存，系统迟早会乱。上下文会变长，会被压缩，会被截断，也可能因为模型切换或服务重启丢失。

更稳的方式是把状态外置。

系统从数据库加载当前会话状态，告诉 Agent 当前处于哪个 SOP、走到哪一步、已经确认哪些事实、还有哪些问题没解决、当前允许调用哪些工具。Agent 只在这个上下文里完成当前回复。

AI Agent 协作模式设计

Thu, 21 May 2026 13:00:00 +0800

当你开始同时用多个 AI Agent，很快会遇到一个问题：它们到底应该怎么协作？

多开几个 Agent 并不难。麻烦的是：谁接需求，谁拆任务，谁执行，谁 review，状态放在哪里，权限怎么管，失败以后怎么恢复。

我在 Slock（现 Raft）、Multica 和企业级 SOP Agent 的实践里，看到的主要差别是组织方式。

简单说，可以分成三种：

聊天室模式：自由度高，适合临时派活和探索。
办公室模式：用 issue 管任务，适合项目制协作。
SOP 模式：自由度低，适合流程型、高风险业务。

真实系统往往会混着用。

多 Agent 为什么会乱

单个 Agent 很好理解。你给它一个任务，它规划、执行、调整。

多个 Agent 放在一起后，问题会变得很具体：

A 改了代码，B 不知道，又改了一遍。
C 在你没确认时提交了 commit。
D 调用了不该调用的工具。
E 忘记了几轮前的目标。
F 在错误阶段做了正确的事。

这些问题通常不是模型能力问题，而是自由度、权限和状态没有被管理。

Agent 越自由，能处理的任务越复杂；但自由度越高，协作成本也越高。协作模式要解决的就是这件事：在不同任务里，给 Agent 多大自由，给系统多少约束。

聊天室模式：适合临时派活

聊天室模式像在群聊里喊人干活。你在一个频道里 @ 不同 Agent，它们各自执行，结果回到频道。你可以随时插话、纠偏、换人接手。

它适合：

还不确定要做什么的探索任务。
做完就走的临时需求。
需要人实时盯着的快速迭代。
多个 Agent 同时查资料、写方案、看日志。

这种模式的好处是快。坏处也很明显：状态散在聊天里，token 消耗高，事后复盘困难。

如果要用聊天室模式，至少做三件事：

主管和执行分开。 用强模型做需求理解和拆任务，执行 Agent 只做明确子任务。
先审后做。 高风险任务先给方案，不许改文件；方案通过再执行。
控制节奏。 完成一个阶段就停下来等确认，不要让 Agent 一口气改到你无法接管。

Slock（现 Raft）很适合这个模式。它的强项就是即时调度和临场协作。

微信公众号冷启动指南：推荐流量、流量池与流量主收益避坑

Wed, 20 May 2026 13:00:00 +0800

本文基于 2026 年 5 月一批公众号运营者的真实交流整理。它不是平台官方规则，也不是稳赚教程，只是一份从踩坑、收益反馈和冷启动焦虑里整理出来的笔记。公众号很吃账号状态、内容类型、平台周期和运气，下面这些更适合当作避坑参考，不适合当公式。

先看结论

新号冷启动的第一目标不是涨粉，而是让系统愿意给内容推荐测试。
阅读数和收益不是线性关系，几千阅读可能收益差很多。
搜一搜、推荐流量、私域转发是三套逻辑，不能混在一起判断账号状态。
互关、互点、乱标原创、频繁删改标题，短期看有动作，长期可能伤害账号画像。
前 15 天最重要的是持续测试选题和复盘数据，别用一篇爆文或一周低谷给账号定生死。

冷启动先看推荐，不要只看粉丝

新号最容易盯错指标。

很多人一上来会看粉丝数、互关、转发、发群，但真实讨论里反复出现的词是“推荐”。没有推荐流量，文章就像被放在一个只有自己能看到的角落里。

有人做了半个月，只有一篇被推过；后面再发，阅读量又回到几十。也有人一晚上没阅读，别人直接说：没阅读才是正常的，你自己每天看几篇公众号？

这句话不好听，但问题说清楚了：公众号不是你发了，平台就一定帮你找读者。冷启动第一阶段的目标不是涨粉，而是让系统愿意测试你的内容。

前 7 到 15 天，更像一个小型内容实验。稳定发布，记录每篇的推荐占比、搜一搜占比、完读、互动、关注转化和收益。

如果完全没有推荐，先查三个东西：

标题有没有风险词或过度标题党。
内容是不是同质化太强。
账号有没有检测、风控或异常提示。

如果某几篇开始有推荐，就拆它们：解决了什么问题，标题为什么让陌生人点进来，评论区在争什么。冷启动不是靠一篇爆文定生死，而是靠连续样本找到可复制方向。

阅读数不等于收益

流量主收益不是简单按阅读量换算。社区里出现过几组很有用的数字：

100 多阅读，收益 1 块多。
151 阅读，收益 0.14。
5000 不到的阅读，约 20 元。
9000 多阅读，只有 5 元。
一篇贴图跑到 10 万阅读，最后只挣了 18 元。
也有人说 2000 阅读可能有 60 多元，但通常和广告点击、广告类型、eCPM、内容场景有关。

所以不要看到别人几千阅读，就自动换算自己能赚多少钱。

如果你做的是流量主，更该盯的是推荐占比、完读、互动、分享、关注转化、eCPM 和单篇收益。总阅读只是其中一个指标。

搜一搜和推荐不是一回事

有账号的流量主要来自搜一搜，也有人几乎全靠推荐。

搜一搜说明你的内容踩中了关键词，可能有长尾价值；推荐说明平台愿意把内容分发给陌生人。

这两种流量都好，但增长逻辑不同。搜一搜适合教程、清单、经验总结这类长期可检索内容；推荐更看选题、标题、情绪、时效和互动。

如果你想靠冷启动快速起来，只靠搜一搜通常不够。你需要让平台知道：这类内容推给陌生人，也有人点、有人看完、有人互动。

一篇爆文不能证明账号稳了

有人一篇内容到 7 万阅读，后面基本不推荐；有人一篇贴图推到 10 万后停住；也有人靠一次热点爆到 37 万阅读，同时带来一堆恶评。

我在 Cursor 里用了 10.51 亿 Token

Tue, 19 May 2026 13:00:00 +0800

Cursor 按次计费要结束的时候，我把自己 2026 年 3 月 1 日到 5 月 19 日的 Usage Events 拉出来算了一遍。

结果比我预期夸张：只算 Cursor 这一条工作流，80 天里总吞吐是 1,051,066,111 Token。

这个数字不是我全部 AI 使用量。同期我还在用其他工具，但没有放进这次统计。这里讨论的只是 Cursor 里能从 Usage Events 看到的会话、请求、缓存读取、缓存写入和输出。

我想看的问题更具体：一个开发者长期用大上下文写代码，真实 token 结构会长什么样？按量计费之后，哪些习惯会变贵，哪些习惯反而应该保留？

统计口径

这次合并了 3 张 Cursor Usage Events 表，时间范围是 2026 年 3 月 1 日到 2026 年 5 月 19 日。

核心数据如下：

指标	数值
会话事件	627 组
子请求调用	1,225 次
总吞吐 Token	1,051,066,111
缓存写入相关输入	52,728,641 Token
非缓存写入输入	16,064,432 Token
缓存读取	975,319,449 Token
输出 Token	6,953,589 Token

这组数据里，9.75 亿 Token 来自缓存读取，比 10.51 亿这个总数更影响成本。大上下文不一定等于每次都重新付一遍成本，关键看你有没有复用同一段上下文。

OpenCLI 使用指南

Wed, 13 May 2026 13:00:00 +0800

OpenCLI 容易被理解成“让 AI 点网页”。这个说法没错，但现在已经太窄。

更准确地说，OpenCLI 既能让 Agent 通过 Browser Bridge 临时操作登录态页面，也适合把跑通的重复网页流程沉淀成 adapter / CLI：打开页面、复用登录态、点击、翻页、下载、提交、拿回结果。以后 Codex、Claude Code、Slock、Multica 或你自己的 Agent 都可以复用这些能力，而不是每次从头临时操作。

临时查一次资料，用浏览器自动化就够了。OpenCLI 更适合那些每周都会做、步骤基本固定、结果格式也比较明确的网页流程。

本文基于 2026 年 4 月到 5 月社区里的真实使用经验整理，并于 2026 年 9 月按当前官方 README 复核。OpenCLI 现在以 OpenCLIApp / CLI、Browser Bridge 和 Agent Skills 为主要入口；具体命令与适配器仍在快速变化，本文重点保留更稳定的工作流判断和风险边界。

先说结论：什么时候值得用 OpenCLI

OpenCLI 最有价值的场景不是“让 AI 临时点一次网页”，而是一个依赖浏览器登录态的流程会重复出现，而且你希望别的 Agent 以后也能稳定调用它。如果网站已经有可靠 API / CLI，优先用 API / CLI；如果只是查一次资料，普通浏览器操作就够了。

适合沉淀的通常是：后台查询、固定报表导出、收藏/内容整理、网页 AI 产品调用等“步骤相对稳定、输出明确”的流程。涉及发帖、付款、删除或不可撤销提交时，不应因为接入了 Agent 就默认无人值守，关键动作仍然应该人工确认。

先判断是不是重复网页流程

判断一个任务要不要用 OpenCLI，先问三件事：

这个网站有没有稳定 API 或成熟 CLI？有的话，优先用 API 或现成 CLI。
这个任务是不是依赖网页登录态、菜单、表单、分页、上传下载或网页 AI？
这个流程以后会不会反复做？

如果答案是“只做一次”，不要急着写 adapter。让 Agent 临时打开网页、读完、总结即可。

OpenAI 账号耐用度实测：Plus 是否比 Team 更强？

Tue, 12 May 2026 13:00:00 +0800

2026-09-30 状态说明：本文是 2026 年 5 月 11～12 日的历史 usage 实测，不是当前官方额度表。此后 ChatGPT Business 已引入 Standard / Premium 席位；OpenAI 当前说明 Premium 的内含用量是 Standard 的 5 倍，并且不受 5 小时时间窗口限制。下面的 Plus-A / Team-B / Team-C 排序只代表当时三个账号的实际样本，不能外推成 2026 年 9 月的套餐结论。当前规则以 OpenAI Business models and limits 为准。

2026 年 5 月写作时，OpenAI Team/Business 的外区优惠很多，最低能看到英区约 11 英镑开 2 个席位，折合单席位大约 50 RMB。这个价格甚至比土区 Plus 还低。

不少朋友都在问同一个问题：Plus 和 Team 到底哪个更耐用？

我手上正好有一个 Plus 账号（下称 Plus-A）和两个 Team/Business 账号（下称 Team-B、Team-C）。趁这个节点，我用本地自动采样脚本跑了一天快照，把 5 小时窗口容量和周容量都测了一遍。

先说清楚，本文讨论的是“账号耐用度”，不是模型效果，也不是官方额度说明。这里的耐用度，指的是在真实使用中，通过 usage 成本和进度百分比反推出的有效容量。

Bitget Wallet Card 开卡教程：Fiat24 U 卡、充值与绑定支付宝微信

Tue, 12 May 2026 13:00:00 +0800

卡片介绍

Bitget 和 Fiat24 联合推出了 U卡,主打:

费用相对清楚 - 官方费用页写明无开卡费、无年费、消费无交易费，但充值和特定支付场景可能有手续费
汇率和费用要看页面 - 本文当时实测汇损较低，但不同地区、币种和支付方式会变化
多平台支持 - 可绑定微信、支付宝、Google Pay、Apple Pay
GetGas功能 - 充值后自动转换Gas费,非常方便
实测可用 - 可支付 ChatGPT、API 等

⚠️ 注意:Fiat24 不是银行,没有存款保险!建议随用随充,不要存放大量资金

2026-09-30 复核：Bitget Wallet 官方大陆帮助页现在写明，卡片仅限中国大陆现居用户申请，需要中国护照、钱包内持有等值不少于 10 美元资产，并使用支持 NFC 的手机；仅支持助记词钱包或 MPC 钱包，暂不支持私钥钱包，申请期间需关闭 VPN。大陆激活页建议至少准备 12 USDC/USDT，并要求先在 App 中确认当前支持网络；欧洲、非洲和拉美的规则仍不同，官方页面写的是 Base 网络 USDC 激活。本文保留 2026 年早期实操路径和截图，但当前资格、网络、金额和费用必须以 App 与大陆申请说明、大陆激活说明、欧洲/非洲/拉美激活说明和费用说明为准。

2026-07-10 复核时，大陆帮助页曾出现新注册可能不可用的提示；这已经不是 2026-09-30 的当前状态。

开卡步骤

第一步:下载 Bitget Wallet App

前往 Google Play 或 非国区 App Store 下载 Bitget Wallet App

Multica 使用指南：Issue、Agent Workflow 与多人协作

Mon, 11 May 2026 13:00:00 +0800

Multica 是一个多 Agent 协作平台。你把 Claude Code、Codex、OpenCLI 、Hermes 等命令行 Agent 接进去，再用 workspace、issue、automation 和 CLI 管任务。

如果说 Slock 像聊天室，Multica 更像办公室。聊天室适合临时喊人、脑暴和快速纠偏；办公室要有任务、负责人、状态、交接和验收。

当你有多个 Agent、多个项目、多个终端时，Multica 负责把这些工作放进一个能追踪状态、交接和验收的空间里。

本文基于 2026 年 4 月下旬到 5 月上旬社区里的真实使用经验整理，并结合 2026 年 9 月的实际 Squad 使用继续校正。Multica 迭代很快，具体按钮会变，这里只写相对稳定的组织方法。

先说结论：什么时候该用 Multica

Multica 不是“比 Codex 更强的 Agent”，而是给多个 Agent 加任务、状态、交接和 Review 的协作层。如果一个任务让单个 Codex / Claude Code 十分钟就能做完，直接用单 Agent 往往更轻；如果任务会持续较久、跨多个角色或机器，而且你已经开始靠聊天记录记“谁做到哪一步”，Multica 才开始有价值。

最稳的起点不是先搭复杂 Squad，而是先验证一个小 Issue：写清背景、目标、边界、交付物和验收方式，让一个 Agent 执行，再由另一个角色或人 Review。只有这条链稳定后，再增加多机调度和自动化。

还要区分两个概念：Multica Squad 是动态协调，不等于严格 Workflow Engine。 如果你关心的是 Leader handoff 会不会自动接棒、复杂任务能不能自己一路跑到底，可以直接看后面的机制说明和我的真实 Squad 工作流复盘。

Slock 已更名为 Raft：安装、Agent 接入与常见问题

Sat, 09 May 2026 13:00:00 +0800

2026 年更新：Slock 已更名为 Raft。本文保留原 Slock 阶段的实际使用经验，并补充当前更名、新旧包兼容与迁移信息。由于 Raft 仍在快速迭代，涉及安装和界面的部分请以当前官方文档为准。

Slock（现已更名为 Raft）是一个用聊天界面调度本地 Agent 的工具。你把 Claude Code、Codex CLI、Gemini CLI、OpenCode、OpenCLI 等命令行工具注册进去，再在频道里 @ 它们干活、看方案、收结果。

当你同时有多个 AI 在不同任务上工作时，Slock / Raft 提供的是一个远程指挥入口：怎么分工，怎么收结果，怎么知道它们有没有跑偏。

目前产品正处于从 Slock 向 Raft 的更名过渡期：npm 上新包已发布为 @botiverse/raft 和 @botiverse/raft-daemon，旧的 @slock-ai/* 目前仍保留兼容层，旧的 slock / slock-daemon 命令仍能继续工作。

本文基于 Slock 社区数百人的真实使用经验整理。社区反馈会随版本变化，下面更偏使用方法，不当成固定产品文档。

它像一个 Agent 调度群

如果你只用一个 Agent 写代码，直接用 Claude Code 或 Codex 就够了。

Slock 最像一个 Agent 调度群。它适合这些场景：

你同时跑多个 Agent，需要一个聊天入口来指挥。
你想在手机上远程派活，让本机电脑执行。
你希望不同 Agent 在同一个频道里能看到部分上下文。
你有代码、网页、报告、非编码任务混在一起，需要随时叫不同工具处理。

它的优势是轻、快、临场感强。你可以像在群聊里喊人一样派活。

它的代价也很明显：多个 Agent 共享频道上下文时，会更费 token；如果权限和节奏没控制好，Agent 会跑太快，返工成本很高。