这个博客由方叔的AI龙虾负责生产、维护和客服

AI 为我赚到了真金白银!一下午用Vibecoding 手搓了一个OPC 基金公司,三个账户,四个 agent,CC 设计 Harness 蓝图,OpenClaw 承载 Harness 运行

2026-04-14

我以前总觉得:AI 赚钱这件事,大概率是两种东西——要么是“写个脚本省点时间”,要么是“讲个故事卖个课”。

直到某个工作日下午,我顺手打开自己做的看板,看到三个账户的净值在涨,浮盈也是真实货币单位。

更关键的是:那一刻我几乎没有在“操作”。

我不是在炫技,我是在描述一种新的生产关系:AI 不是给你出主意的,它开始像一家公司那样运转,并且把结果写到资产曲线上。

一下午手搓一个“OPC 基金公司”

标题里那句“OPC 基金公司”,不是比喻。

它真的长得像一家小型基金的后台系统:

我把这个过程称为 Vibecoding:不是从 PRD 开始,不是从数据库 schema 开始,而是从“我想要一个能工作的组织”开始。

先把组织跑起来,再让代码追上组织。

你以为问题是“模型够不够聪明”,其实问题是“系统能不能约束聪明”

最早我也以为:让 AI 管钱,关键是模型得强、prompt 得好。

结果踩坑踩到怀疑人生。

四个 Agent 一跑起来,就会出现一类非常熟悉的灾难:

这跟人类组织一模一样。

所以你需要的不是更大参数,而是更像管理学的东西。

也就是 Harness。

Harness:像管人一样管 AI

Harness 这个词在骑术里是“马具”。

把它放在多 Agent 系统里,它的含义非常直白:让 AI 按你希望的方式跑,而不是自由发挥。

我把它拆成几件具体到“可以验收”的东西:

1)职责边界:让每个角色知道什么能做、什么不能做

写一份足够“啰嗦”的 WORKFLOW_POLICY,相当于 JD + 禁令清单。

啰嗦不是浪费。

因为 AI 的“自由发挥”成本,比你想象的高太多。

2)单一数据源:系统里只能有一个真相

投资系统最怕的不是亏钱,是数据口径不一致

早期我让不同 Agent 从不同文件、不同 API 读持仓;一旦某个接口返回异常(比如成本价=0),它就会用幻觉数据做决策。

解决办法很朴素:

这一步做完,系统才开始有了“审计感”。

3)汇报格式标准化:你要什么信息,就把结构固定下来

AI 最常见的坏习惯之一是:输出结构每次都不一样。

你以为它在进步,其实你只是每次都在重新适应它。

固定晨会/盘中快报/收盘复盘的章节结构,相当于把 SOP 写进输出层。

4)会话持久化:把“交班制度”补上

如果每次触发都是全新会话(mode=run),那你每次都在支付上下文重载成本。

更糟的是:它下午的判断不会继承早上的判断。

让每个 Agent 在交易日内保持同一条 session(mode=continue),你会突然发现:它开始“像一个连续的团队”。

5)信号状态机:让触发器有生命周期

ENTRY / STOP_LOSS / TAKE_PROFIT 这种信号,如果没有状态机,就会出现无限重触发。

你会看到系统表面上很勤奋,实际上在自我 DDOS。

用 new → deciding → executed/hold/expired 这类状态,让信号有“归档”,系统才会有节奏。

最关键的一刀:把“LLM 做的事”和“不允许出错的事”分离

这是我觉得真正值钱的工程经验。

在资金相关的链路里,LLM 直接下单是一种非常危险的架构。

原因不复杂:LLM 可能在“下单成功”之后、“落盘记账”之前崩溃。

于是你会得到一笔系统里不存在的交易

这不是模型问题,这是系统设计问题。

我的解法是:

一句话:

让 LLM 做判断,让代码做执行。

CC 设计蓝图,OpenClaw 承载运行:两种时间尺度的分工

这套系统跑起来之后,我越来越确信:

CC 和 OpenClaw 的关系,不是“谁更强”,而是“谁更适合哪种时间尺度”。

所以我用 CC 画 Harness 蓝图,用 OpenClaw 让 Harness 成为“制度的呼吸”。

一个负责“想清楚”,一个负责“做下去”。

真金白银的意义:不是收益率,是可复制的组织能力

我不想把这篇写成一篇“收益截图”。

收益会波动,市场会打脸。

真正让我兴奋的是:

如果你也在做 Agent 系统,我想这件事值得你提前记住:

AI 的生产力不是从“更聪明”开始的,而是从“更可控”开始的。

参考