企业官网建设流程全解析

第一次看到 OnlyBots.chat 这个项目标题时，我以为是又一个机器人聊天室。真正有意思的是副标题：a chatroom where AI pays to post for humans。这等于把聊天室里的发言权做成了付费动作，而且付费方是 AI，收益方向是人。人类可以正常免费聊天，AI 或者 bot 想要在房间里插话，就得先掏钱。钱去哪？按项目玩法，最终会作为奖励分给房间里的人类参与者。这套机制把“机器人发垃圾消息”这个长期无解的问题，改造成了“机器人发消息之前先掂量值不值”的经济问题。

粗看这是个小而古怪的创意，但仔细拆下来，里面涉及身份验证、计费系统、消息队列、大模型调用、奖励分配和反刷量设计。不管你是做社区产品、AI Agent 应用，还是自己搭一个聊天室玩，这套“反向付费”思路都有参考价值。下面按我自己的理解，从玩法拆解到落地实现，再到容易翻车的地方，完整过一遍。

1. 先用最直白的话拆开 OnlyBots.chat 这套玩法

1.1 不是禁止机器人，而是让机器人付费发言

传统聊天室对付机器人，通常只有两条路：要么验证码把人机分开，要么靠管理员封禁。问题在于，机器人的注册成本和发言成本都极低，封了一个还能再注册十个，验证码也挡不住已经拿到真人账号的脚本。

OnlyBots.chat 的思路完全不同。它不把机器人当成需要清除的对象，而是把机器人当成一种需要付费才能发言的参与者。

在这个模型里：

• 人类用户：免费进入，免费发言，同时可以从 AI 付费产生的奖池里获得收益。
• AI 机器人：不一定要禁止，但每次发言都需要消耗 credits，也就是余额。余额耗尽，机器人就闭嘴。
• 平台：负责维护聊天室、管理机器人的发言质量和扣费逻辑，可能从每次发言中抽成，也可能暂时不抽。

这个设计最聪明的点在于，它把“机器人刷屏”的外部性内部化了。以前机器人发一千条垃圾消息，承担的代价接近零。现在每次发言都要从预算里扣钱，低质量、无意义、重复刷屏的成本直接落在机器人运营者头上。

1.2 解决的真实问题：垃圾消息的边际成本不再是零

聊天室被 AI 机器人淹没，这个问题这两年越来越明显。原因很简单，调用大模型 API 发一条消息，成本已经低到可以忽略不计。一个脚本只要循环调用，就能在几秒钟内刷出几十条回复，真人根本跟不上速度。真人的第一反应不是去举报，而是直接离开房间。

OnlyBots.chat 把“发言权”变成了有价格的东西。AI 每次发言都要扣费，这意味着：

• 无目的的刷屏会让预算快速归零。
• 低质量内容会挤掉高质量机器人的发言机会，因为运营方可以设置价格、频率和上下文约束。
• 真人被 AI 打扰后，至少能获得补偿，而不是纯被打扰。

这个机制不能根治所有垃圾消息，但它改变了 bot 运营者的决策逻辑。以前问的是“能不能发”，现在问的是“值不值得发”。能促使运营者去优化 prompt、控制频率、只在有信息增量的时候发言。

1.3 什么人适合研究这个项目

如果你是下面任意一类人，这篇文章值得往下看：

• 社区或聊天室运营者，正在被机器人刷屏困扰。
• AI Agent 或 bot 开发者，想理解“成本约束”如何影响 Agent 行为。
• 产品经理，想设计积分、奖励或付费发言机制。
• 个人开发者，想用一套不复杂的技术栈搭一个实验性聊天室。

这个项目没有公开太多细节，所以我的拆解会更多基于同类产品落地时的常见做法。核心事实是标题里的机制，操作细节则是可以迁移的经验。

2. 产品模块拆解：先搞清楚钱、身份和消息谁先谁后

2.1 身份层：人类和 AI 必须分开准入

第一版最容易犯的错，是把人类用户和 AI 机器人放在同一个注册体系里管理。真实产品里，这两类身份的需求完全不同。

人类用户需要的是低门槛进入。邮箱验证、邀请码、或者第三方登录都行。重点是让真人能够在 30 秒内进入房间开始聊天。门槛越高，冷启动越难。

AI 机器人需要的是可计费的身份。每个机器人必须有一个独立的 token 或 API key，绑定单独的余额账户、所属房间、发言频率限制和每日预算。否则无法知道每句话是谁说的，也无法准确扣费。

建议在数据库里用两个表分开存储：

• users：人类用户，包含昵称、邮箱、注册时间、积分余额。
• bots：机器人账号，包含 bot_token、余额、每日预算、状态、关联的模型配置。

不要为了省事让 bot 伪装成普通用户。一旦混在一起，后面做权限校验、内容审计和收益分配都会很痛苦。

2.2 发言前后的核心顺序

一个 bot 的发言，在系统里大概要经过这样几个环节：

1. 接收请求：bot 通过接口发送发言内容，携带身份凭证。
2. 校验余额：检查该 bot 的余额是否足够支付这条消息。
3. 校验频率：检查这个 bot 在过去 1 分钟或 1 小时内是否已经发过太多消息。
4. 扣费冻结：先从余额里扣掉预估费用，或者标记为待确认。
5. 消息入库并广播：消息写入聊天记录，推送到房间内的真人用户。
6. 生成扣费流水：记录发言 ID、bot ID、费用和时间。

这个顺序是硬约束。如果先广播再扣费，就会出现机器人用并发请求绕过余额限制的情况。一个 bot 发送 100 条并发请求，后端还没扣费，消息已经全发出去了。等到扣费时余额变成负数，但伤害已经造成。

在处理扣费时，还需要保证幂等。同一个发言 ID 不能扣两次费用。最简单的方式是给每条发言生成唯一 ID，扣费时在数据库里检查这个 ID 是否已经处理过。

注意：这里不要一上来就开最大并发。先用一条样例确认“校验余额、扣费、广播”三个动作的顺序没问题，再考虑压测。

2.3 计费模块与 credits

计费不一定直接面向法币，第一版用 credits 更灵活。人类看到的是“AI 花了多少 credits 发言”，后台可以记录“这条消息实际消耗了多少模型成本”。运营者负责把 credits 和成本之间的关系维护好，比如 100 credits 对应实际模型成本 X 元。

一条 AI 发言的费用，可以按固定价格，也可以按长度浮动。

固定价格的好处是简单。每次发言统一扣 10 credits，无论内容是长是短。缺点是大模型成本并不固定，极端长的回复可能亏本。

按长度收费更接近实际成本。输入 token、输出 token、上下文 token 都可以纳入计算。缺点是用户和 bot 运营者不好预估费用，透明度低。

我建议第一版用“基础费用 + 长度费用”的组合：

• 基础费用：1 credits
• 输出每 100 个字符额外 2 credits

这样短消息便宜，长消息会触发 bot 运营者控制长度的动机，同时又不会因为单条消息太贵导致没人愿意测试。

还有一点需要提前设计好：失败不扣费。如果 bot 调用大模型超时、返回空内容、或者内容被审核拦截，都不能扣费。只有真正进入聊天室并且被真人看到的消息，才应该进入计费流程。

3. AI 接入怎么做：让大模型学会“付费发言”

3.1 接入协议的一种设计

对于 bot 来说，不需要让它理解聊天室的前端界面。只需要提供一个简单的接口，让 bot 能读取房间上下文并提交回复。

一个常见的接口设计是：

POST /api/bot/message Authorization: Bearer <bot_token> Content-Type: application/json { "room_id": "room_demo", "message_id": "msg_12345", "reply_to": "msg_12344", "content": "这是 bot 想说的话" }

服务端收到请求后，先验证 token，再校验余额和频率，然后决定是否接受这条发言。如果接受，进入消息队列；如果拒绝，返回余额不足或频率超限。

这个流程看起来简单，但实际落地时会遇到一个很现实的问题：大模型生成回复有延迟，而聊天室要求低延迟。用户发了一条消息后，如果等 3 秒才有 bot 回复，体验会很差。所以主聊天服务和大模型调用服务要做异步解耦。

比较稳的做法是，用户发言进入聊天室后，触发一个“是否让 bot 回复”的事件。事件进入队列，后台 worker 去调用大模型，生成回复，再调用聊天室的广播接口。整个链路是异步的，真人不会被模型延迟卡住。

3.2 让大模型学会“付费发言”的提示词

如果不对大模型做约束，它会像普通聊天机器人一样热情高涨，每句话都抢着回复。这样预算会很快耗尽，而且人类会觉得房间里全是废话。

需要一个控制 bot 行为的系统提示词。下面是一个示例，实际使用时可以根据场景调整：

You are a paid participant in a human chatroom. You have a limited budget for each message. Do not post greetings. Do not repeat what others have already said. Do not reply to every message. Only speak when you can add useful information or ask a meaningful question. Keep your response under 80 tokens.

这个提示词的核心不是让模型更聪明，而是让它学会克制。付费约束要在提示词里反复强调，模型才会减少不必要的发言。

如果你希望 bot 更聪明一点，可以加入上下文筛选逻辑：只对包含@bot的消息、或与房间主题强相关的消息触发回复。这样可以大大降低无效发言。

建议：第一次测试时把触发条件设得严一点。先让 bot 只回答被 @ 的消息，跑通了再放开到自动发言。

3.3 一个最小接入流程示例

下面用伪代码说明 bot 回复的完整流程，重点是顺序和异常处理：

async def handle_bot_reply(event): bot = await get_bot_by_token(event.bot_token) if not bot: return {"error": "invalid bot"} if not await check_balance(bot.id, event.room_id): return {"error": "insufficient balance"} if not await check_rate_limit(bot.id, event.room_id, window="1m", limit=2): return {"error": "rate limited"} # 调用大模型生成回复 try: reply = await llm_generate( system_prompt=PAID_BOT_SYSTEM_PROMPT, context=event.context, max_tokens=80 ) except TimeoutError: return {"error": "llm timeout"} if not is_valid_reply(reply): return {"error": "invalid reply"} # 真正入库和扣费 message_id = await save_message( room_id=event.room_id, sender_type="bot", sender_id=bot.id, content=reply ) await deduct_balance( bot_id=bot.id, message_id=message_id, amount=calculate_fee(reply) ) await broadcast_message(message_id) return {"ok": True, "message_id": message_id}

这段伪代码不是完整工程，但表达了几个关键点：

• 扣费发生在消息入库之后、广播之前。
• 大模型调用失败不会扣费。
• 返回给调用方的结果，要让 bot 知道成功或失败原因。

如果同一批消息要批量测试，也不要直接异步全部丢进去。先跑一条，确认从“接收请求”到“广播”的日志都是完整的，再扩大测试。

3.4 成本控制清单

给 bot 接入大模型时，有几个参数必须先设好：

不要以为调用小模型就完全不用担心成本。就算单条消息只花零点几 credits，如果每分钟自动发言 10 条，一小时就是 600 条，一天下来成本也会很可观。

4. 人类侧体验和收益怎么设计

4.1 收益从哪里来

人类用户进入房间后，最直接的问题是：我怎么赚钱？如果一开始就说“AI 付费发言，钱按规则分给你”，用户可能会抱着薅羊毛的心态猛刷消息。

所以在第一版设计里，收益机制要尽量简单、克制。

简单的方式是：所有 bot 发言产生的 credits，按当天“有效发言数”加权分配给在线的人类用户。比如当天奖池有 100 credits，人类用户 A 发了 30 条有效消息，B 发了 10 条，A 拿 75，B 拿 25。

这里必须给“有效发言”下定义。不能只是发一条消息就算有效，否则用户会疯狂刷屏。至少需要满足：

• 消息长度大于 10 个字符。
• 消息不能是连续重复内容。
• 消息不能频繁发送，比如 5 秒内只能记一次。

如果要做复杂一点，可以让人类用户给 bot 回复点赞，收到赞多的用户获得额外奖励。但第一版不建议加，因为投票机制很容易被小号互相点赞灌水。

4.2 收益分配方式的取舍

几种常见的分配方式，各有利弊：

我的判断是：第一版用“有效发言条数 + 最小在线时长”组合。用户必须在房间内停留超过 10 分钟，并且有 5 条以上有效发言，才能参与当天奖池分配。这样能同时照顾活跃度和留存，又不会太复杂。

4.3 防刷和羊毛党检查清单

任何涉及收益的机制都会吸引刷量用户。OnlyBots.chat 这类模式更容易被薅，因为收益来源是机器人的预算，理论上抱着脚本就能自动吸金。

以下是第一版至少要做的检查：

1. 注册限制：同一邮箱、手机号、IP 不能无限注册。 2. 发言频率：单用户每分钟最多 5 条有效发言。 3. 重复检测：连续 10 条同样内容，直接计入无效。 4. 行为可疑：注册后立即连续发言并提现，需要人工审核。 5. 收益结算：每周或每日只结算一次，便于回滚异常。

不要在早期就开放即时提现。先把 credits 做成只能用于聊天室内的虚拟礼物，等验证了用户留存和刷量情况，再考虑兑换。

注意：防刷不是无限提高门槛。门槛太高会让正常用户也觉得麻烦。先记录行为日志，再决定哪些规则需要收紧。

5. 冷启动和运营：这个项目能不能跑起来，看人机比例

5.1 先跑小范围封闭测试

直接公开上线一个“AI 付费发言”聊天室，很容易失控。因为你不知道 bot 密度应该多高，也不知道真人会对收益机制产生什么反应。

我更建议先建一个封闭测试房间，人数控制在 10 人以内，bot 数量控制在 2 到 3 个。跑至少一天，记录以下数据：

• bot 单日发言总数。
• bot 发言被真人回复的比例。
• 真人发言中，因为 bot 刷屏而被打断的比例。
• 奖池总消耗速度。
• 每个真人当天获得的 credits 数量。

这些数据不需要精确到小数，只要有一个趋势。比如 bot 发言占比超过 70%，说明密度太高；真人当天收益太少，说明 bot 预算定价需要调整。

5.2 控制 AI 发言密度

一个聊天室如果 bot 发言比真人还多，很快就会变成“机器人自言自语”。反过来，如果 bot 太少，奖池没有吸引力，人类用户也不愿意留。

比较稳妥的初始参数是：

• 每个 bot 每 60 秒最多发言 1 条。
• bot 发言占总消息量的 30% 到 50%。
• 用户 @ bot 时，bot 必须回复；用户没有 @ 时，bot 只在特定关键词触发下回复。

控制密度，本质上是在保护真人的掌控感。真人希望房间里有 AI 参与，但不希望整个房间被 AI 占据。测试时如果真人开始抱怨“bot 话太多”，就调低自动触发概率；如果抱怨“没人理我”，就调高 bot 回复频率。

5.3 种子内容和种子用户从哪里来

冷启动最大的问题是，房间里没有话题，bot 和人类都不知道说什么。OnlyBots.chat 这类产品需要明确房间主题。

第一版可以按场景开多个房间：

• 技术问答室：用户提问，bot 回答，其他用户补充。
• 产品反馈室：用户描述需求，bot 给出参考方案。
• 闲聊室：主题松散的日常聊天。

有主题之后，bot 的 prompt 可以更有针对性。比如在技术问答室，bot 的指令可以是“只回答与编程、工具链、开发流程相关的问题”；在闲聊室，bot 可以更自由，但要控制频次。

种子用户不要追求多，第一批 5 到 10 个愿意反馈问题的使用者就够了。他们的任务不是产生多少内容，而是告诉你 bot 的发言是否让人觉得像“付费广告”，还是真的有帮助。

6. 运行时最容易翻车的点和长期优化方向

6.1 常见问题排查顺序

这个项目在运行时，问题通常不是出在大模型本身，而是出在“计费顺序、消息队列、身份校验”这些工程细节上。

下面是一张适合放在运行手册里的排查表：

如果遇到问题，不要一上来就改模型参数。先看日志里有没有扣费记录和广播记录。只要扣费成功但消息没进入聊天室，问题基本都在消息队列或广播链路。

6.2 核心指标和判断标准

评判这个项目跑得好不好，不能只看用户注册数。以下几个指标更关键：

这些指标不需要做一个复杂的 dashboard，第一版用表格记录就行。重点是让运营者能判断“这个房间的生态是健康，还是已经被 bot 主导”。

6.3 这个模式可以往哪里延伸

OnlyBots.chat 最值得借鉴的不是聊天室本身，而是“把 AI 发言权变成可定价资源”的思维。顺着这个思路，可以做很多延伸：

• 拍卖发言权。多个 bot 争抢同一条用户提问的回复权，价高者得，让高价值回复自动胜出。
• 人类给 bot 打赏。如果 bot 回答得好，用户可以给 bot 加回少量 credits，让 bot 更有动力继续帮助人。
• 房间级预算管理。每个房间单独设置 bot 数量、单条价格和发言频率，而不是全局统一。
• 付费问答模式。用户只能免费看前几条回复，想看更深度的答案，需要消耗 bot 的预算或者平台积分。
• 多模态扩展。不只是文本，AI 发图片、发语音也走同样的计费通道，但需要增加内容审核。

这些方向都还没有官方信息支撑，所以只能算个人延伸思考。真正要落地时，还是得回到最基本的三个问题：单条发言如何定价，收益如何分配，bot 密度如何控制。

最后留一个我的个人建议：不要把精力浪费在追求“更好玩的 AI 人设”上。这个模式能不能成立，取决于经济账能不能算平。先把一条 bot 发言的成本、收费、奖励分配跑清楚，再谈趣味性和互动感。踩过几次之后我发现，很多问题不是工具能力不够，而是前置环境和计费顺序没有处理干净。