← 返回 故知
故 知 通 讯 · 第 0 1 封

算了一笔账,发现这事可能跑得通

第 二 封 · 2 0 2 6 春

上一封信发出去之后,有个朋友看完跟我说:

"故事我都听懂了。但你这种 agent-driven 的东西,能跑下去吗?我见过太多这类产品,几千 DAU 就把账面烧穿了。"

那句话戳到我了。

我做了一周的事情就一件:算账


先说结论:单 DAU 月成本压到了个位数美分量级。这意味着即便规模化,推理成本也不会成为压垮这事的那根稻草。

这数字看起来比一般 agentic social 产品低一个量级。原因不浪漫,纯粹是架构上的运气 ——

故知的核心匹配,不烧 token

知识图谱匹配是图算法,不是大模型。一个人 KG 子图里有几条边,另一个人 KG 子图里有几条边,两图在哪些簇上重合、强度多深,这套是确定性运算。Python 跑,0 token。

只有两个地方真的要叫 AI:

1. 用户写下一段话 → AI 把它抽成 KG 边
2. 匹配上的两人 → AI 写那段相遇对话

第一个一次性多、之后增量小。第二个只在"该叫的时候"叫。


我之前的账算错过一次。

最早的版本里,我跟着投资人那句"几千 DAU 就能烧穿"的直觉,把 agent 在小镇里走的每一步都算成了 LLM 调用 —— 那是动辄百万次的调用量。

但故知不是那种 agent。镇上的小人是个确定性状态机,它不思考、不决策、不"想找谁聊"。它只是在走。它撞上谁,是物理事件,不是 AI 决定。

撞上之后,KG 匹配也是图算法。仍然不烧 token。

只有当算法说"这两个该聊",AI 才被请出来 —— 写那段对话。

把账重新算一遍,单 DAU 月成本掉了一个数量级。


这周做完三件事。每一件都是为了让"算账"的结论不止是 Excel 里的承诺,而是代码里的事实。

第一件:让不同分量的相遇走不同档的 AI

普通的相遇用便宜的模型写对话,对它来说已经够了。高分的相遇用更贵更细腻的模型,笔触更深一点。极少数真正的灵魂时刻 —— 大约二十分之一的相遇 —— 再用最顶档的模型慢慢写。

这不是"省钱式"路由,是把钱花在刀刃上。便宜档省下来的钱,让顶档可以慢一点、深一点。

第二件:把"写对话"这一步从主程序里解耦出来

以前匹配上了就同步等 AI 写完。现在变成事件队列,主程序产出"该写"的信号,后台 worker 异步消费。

听上去是工程细节,但意味着规模化时 worker 可以独立扩。整个系统不用等同一个慢调用。

第三件:把 prompt 写薄

低档调用保留精简版,高档调用把两人共簇里相关的"侧面"加进来 —— 让贵的模型看到更多 evidence,写出来不只抓主线。

低档便宜、高档更细。


但其实我想说的不是这些技术。

我想说的是 —— 算完这笔账之后,我有一种奇怪的轻松感

不是因为数字漂亮。是因为我第一次确定:这件事不是非要烧钱才能跑

我以前以为,做这种 AI-heavy 的产品就得有融资、有团队、有一堆显卡。算完之后才发现:如果 KG 是确定性的、如果 AI 只在最关键的两个点出现、如果路由分层、如果在 100k DAU 之前不上那些贵的基础设施 ——

这事一个人也能扛。

我不是说一定能成。我是说,至少在被钱掐死这条路径上,故知有可能不死。


下一封信会写什么我还不知道。可能是"waitlist 到了多少人",可能是"第一镇圈了谁、为什么是 ta 们"。

也可能是又一次反复推翻自己之后写的。

— Z

这 周 改 了 什 么
代码改完测试都绿。具体的成本表和模型选型,给真正在认真考察这事的人单独看。

P.S. demo 还是那个 demo。下一次有产品变化我会专门说。

下 一 封
想收到下一封
加 入 名 单