这个程序员把AI塞进Discord，3天后发现收入涨了23%

有个叫Creem的支付仪表盘，创始人每天要看17次。睡前刷，等编译刷，开会走神也刷。这种"数字鸦片"让他产生了一个念头：既然AI能写代码，为什么不能替我盯着钱？

72小时后，一个住在Discord里的AI员工Alfred上线了。不收工资，不请假，凌晨3点发现支付失败会立刻弹窗。更意外的是，这套零成本架构跑通的第一周，他的SaaS收入环比涨了23%——不是因为Alfred多卖了货，而是它把漏掉的钱捡了回来。

Alfred的KPI只有三项

作者给这个AI定的任务极其具体，没有"优化用户体验"这种黑话。每天早上8点，Alfred会推送一份营收健康日报：昨日收入、新增订阅、异常波动，用Discord消息直接砸到脸上。

第二项是防流失。当系统检测到用户取消订阅，Alfred自动创建挽回折扣码，并起草一封重新激活邮件——不是发送，是起草，最终决策权仍在人类手里。

最关键的一项是追坏账。支付失败在SaaS里是个沉默杀手，很多创始人直到月底对账才发现。Alfred的做法是： webhook（网络钩子）一响，立刻生成账单门户链接，把问题推到创始人眼前。作者原话：「以前这些订单直接蒸发，现在能救回来一半。」

零成本架构的四个器官

这套系统能跑起来，靠的是四层分工明确的组件。作者把它类比成人体：大脑、工具、神经、心跳。

大脑层是OpenClaw（开源AI代理框架）叠加大语言模型。作者最初试了Gemini，三句话后被限流；Claude太贵；最终落地OpenRouter的免费高智能模型，重活才 fallback（回退）到Claude或Gemini。成本压到接近零，但有个隐藏代价——OpenClaw每次调用会塞10万-20万token的上下文，对话历史、技能文件、工具schema全打包，「像每次咨询都要把病历本从出生时带上」。

工具层是Creem Skill，一个发布在ClawHub上的官方技能包，让Alfred能直接调用Creem的CLI和REST API（应用程序接口）。没有这层，AI只是个会聊天的哑巴。

神经层是作者自己搭的Express服务器，专门处理安全验证：校验creem-signature的HMAC签名、去重webhook重试、在事件发生时"拍醒"Alfred。这层不能省——支付数据的完整性比响应速度更重要。

心跳层是个后台脚本，负责异常检测和定时日报。作者把它独立出来，避免和实时事件处理抢资源。

安装比想象中轻

OpenClaw的设计哲学是本地优先。不需要云服务器，笔记本就能跑。安装命令只有一行curl脚本，依赖Node 22+。初始化时选QuickStart模式，模型提供商填OpenRouter，Discord机器人去开发者门户注册，复制token进去——作者说全程5分钟。

跑通后执行openclaw gateway status，看到18789端口在监听，就知道"脉搏还在跳"。

有个细节作者特意警告：OpenClaw的上下文膨胀问题。每次对话都携带完整历史，长会话后token消耗会失控。他的 workaround（变通方案）是定期重启对话线程，把Alfred"格式化"回初始状态。

23%从哪来

收入增长不是Alfred创造了新需求，而是堵住了旧漏洞。支付失败、沉默流失、账单异常——这些"营收暗物质"以前靠人工巡检，频率和精度都靠运气。

作者算过一笔账：挽回一个年付$240的用户，Alfred的成本是零（OpenRouter免费层）。而在此之前，这类用户取消后平均要沉默47天才会被人工发现。

更有意思的是组织层面的变化。作者把Alfred拉进团队频道后，其他成员开始@它查数据，「它变成了公共记忆体，而不是我的私人秘书」。这种意外的网络效应，是初期设计时没预料到的。

现在Alfred每天处理的事件量在200-400条之间，真正需要人类介入的不到5%。剩下的95%，AI在3秒内完成判断-执行-归档。作者最新的念头是：要不要给它开通部分支付渠道的只读权限，让它直接对账，而不是等webhook通知？

如果AI员工能实时看见钱流进流出的每一笔，它下一步会要求什么权限——或者，创始人敢给吗？