公众号文章系列 · 09 · 深度版

一个产品的三天

从 CLI，长成 Developer Platform

Author姚光华 Colin

Role声网 ConvoAI 产品负责人

区间v1.2.1 → v1.6.0 · 累计 33 工作小时

Date2026.04.02 – 04.04

上一篇发出去之后

01

很多人问我同一个问题：
「17 小时做出来的东西，能用吗？」

我的回答

能用，但不够好。

于是

4 月 2 日下午到 4 月 4 日晚上，跨三天、累计 16 个工作小时。

结果

v1.2.1 → v1.6.0。不是修 bug。

是把一个 CLI 工具，推进成了一个 Developer Platform。

33

个工作小时，跨 3 天。
前 17 小时是「从零到一」，后 16 小时是「从能用到好用」。

这 16 小时里：对话轮数从 ~150 涨到 ~330，源代码从 8,790 行涨到 ~13,000 行，
测试从 448 个涨到 507 个，npm 发布从 25 次涨到 50+ 次。平均每 40 分钟发一个版本。

先说数据变化04

v1.2.1（上篇终点） → v1.6.0（现在）

六个口径，同一个方向

01工作时间17 小时 → 33 小时（+16h）

02对话轮数~150 轮 → ~330 轮（+180）

03源代码8,790 行 → ~13,000 行（+4,210）

04npm 发布25 次 → 50+ 次（+25）

05测试通过448 → 507（+59）

06Starter0 → 20 文件 / 1,629 行（新增）

每个版本发布前都跑全量测试。从 448 到 487 到 507，没有跳过。也不是因为改动小 —— v1.3.0 重写了整个 quickstart 引导流程。

全景05

33 个工作小时的四级台阶

从工具，到 Developer Platform

从「一个 API wrapper」，走到「一个有品牌、有体验、有开发者路径的平台」。

MONEY QUOTE · 01

不是修 bug 是把工具 推进成平台

如果说前 17 小时是「从零到一」，后 16 小时是「从能用到好用，从工具到平台」。

ACT I / V

TOKENS

先回应被问最多的

「8790 行代码 + 448 个测试，4M Tokens 真能做出来？」
先说结论：4M 是我基于主对话窗口的估算，实际消耗大概在 5-6M。

I Token 账II 发版速度III 阶段一 IV 阶段二V 阶段三

ACT I · Token 账08

1-2M 的估算误差，从哪来

4M，还是 5-6M

终端里看得到的

主对话 ~1.5M

coordinator 模式下，主对话窗口的消耗是可见的。这就是「4M」这个估算的来源。

终端里看不到的

子 Agent ~2-2.5M

并行构建的 4 个模块、Code Review Agent，各自有独立的上下文。这部分消耗在主终端里不显示。

5-6M 和 4M 的区别，是估算精度的问题，不是「能不能做出来」的问题。（上一篇标注的是 ~4M；本篇为作者自己的修正口径。）

v1.2.1 确实是一天之内做出来的。更值得拆解的是这些 Token 花在了什么地方。

ACT I · Token 账09

重点不是总量，是分布

Token 都花在哪了

只有 30% 用在写代码上。剩下 70% 花在「先理解问题、想清楚方案、写完再审、审完再修」。

MONEY QUOTE · 02

只有 30% 用在写代码上

如果 100% 的 Token 都用来「直接写代码」，5M 确实不够。
但如果你的流程是先想后写、先测后发，Token 的利用效率会高得多。

ACT II / V

SPEED

五十次发版意味着什么

33 个工作小时，50+ 次 npm 发布。平均每 40 分钟发一个版本。
这个数字看起来非常反直觉。但它是真实的。

I Token 账II 发版速度III 阶段一 IV 阶段二V 阶段三

ACT II · 发版速度12

一次不可逆的范式转移

版本间隔，一级一级塌下来

不是说所有产品都应该 40 分钟发一版。复杂的 B2B 产品有灰度、有客户验证、有合规 —— 快不起来，也不应该快。

ACT II · 发版速度13

速度不是因为不做测试，也不是因为改动小

三个结构性变化

01等待消失AI 消灭了「实现等待时间」。spec 写完，10 分钟后就能看到第一个可运行版本。

02发布归零npm publish 的成本趋近于零。不需要审核、不需要灰度、不需要发布窗口。

03闭环压缩真实用户反馈的闭环缩短到分钟级。「小步快跑」不再是口号，而是自然发生的事。

去年 12 月我在人人都是产品经理大会上讲过一个判断：「2 周一个版本迭代，已经是 AI Native 组织的新常态。」当时举的例子是 HeyGen 和自己带的 ConvoAI 产品线。

后来那张图刷屏了 —— Claude 团队在 52 天里几乎每天都有发布。 当我认为「一天一迭代」已经是天花板的时候，我自己的项目打破了这个判断。

ACT II · 发版速度14

v1.4.2 → v1.4.3 · 一个真实的闭环

20 分钟，从抱怨到修好

当「发现问题 → 修复 → 发布 → 用户验证」被压缩到 20 分钟，迭代频率自然就到了这个量级。

MONEY QUOTE · 03

以前的瓶颈 是做不出来 现在是想不清楚

做不出来可以靠加人加时间。想不清楚，加多少人都没用。

ACT III / V

SKIN

先让它看起来像产品

v1.2.1 功能完整，但视觉上……就是一坨纯文本。
跟 Claude Code、OpenClaw 的终端体验比，差了一个档次。阶段一，约 3 小时。

I Token 账II 发版速度III 阶段一 IV 阶段二V 阶段三

ACT III · 阶段一 v1.3.x17

三件事，都不是「加个颜色」

品牌化，是一层层做出来的

01渐变 UI让 Claude Code 在终端里用 ANSI escape code 直接渲染 5 种视觉方案，不是截图，我当场选。最终选了蓝→粉渐变框线 + 渐变标题 + 增长式进度条。

02中英分流选声网走中文，选 Agora 走英文。中文版通义千问排第一、凭证 4 步详细指引；英文版 OpenAI 排第一、3 行精简提示。

03步骤重排凭证 → LLM → TTS → ASR，改成凭证 → ASR → LLM → TTS。ASR 最简单，推荐 ARES，免费不用填 key。

把最简单的一步放前面，让用户先拿到成就感。而不是一上来就被 LLM 的 API key 卡死。

ACT III · 阶段一 v1.3.x18

一个经典的终端 UI 坑

中文字符占 2 列

所有 .length 算出来的宽度都是错的，右边框全部错位。写了一个 displayWidth() 才对齐。

终端 UI 的坑，不在渲染，在你以为字符宽度是 1。

ACT IV / V

JOURNEY

从用户旅程重构命令

30+ 个命令摆在那里：quickstart？agent start？agent join？chat？
阶段二，约 5 小时。这一段的起点不是一个功能，是一个问题。

I Token 账II 发版速度III 阶段一 IV 阶段二V 阶段三

阶段二的起点是一个问题

02

用户第二次打开 ConvoAI CLI，
该输入什么命令？

摆在那里的

30+ 个命令。quickstart？agent start？agent join？chat？

我的答案

用户不应该需要想这个问题。

做法

用 Superpowers 的 brainstorming，从用户旅程出发重构整套命令体系。

于是有了 convoai go。

ACT IV · 阶段二 v1.4.x21

convoai go 的诞生

按「第几次用」来设计命令

然后我废弃了 chat、repl、watch 三个命令。 Help 页面从一堆平铺命令，重构成分组 + 智能提示：已配置提示 convoai go，未配置提示 convoai quickstart。

ACT IV · 阶段二 v1.4.x22

go 处理了所有 corner case

「零参数」背后是五个兜底

01没配置过提示你先跑 convoai quickstart。

02配置不全告诉你到底缺什么，而不是抛一个异常。

03Agent 没关上次的 Agent 还在跑？自动 stop。

04端口被占自动 kill 占用进程。

05Chrome 缺失找不到 Chrome？fallback 到其他浏览器。

五个兜底，换来一个「零参数」。用户看到的是一个词；这个词底下藏着五次「如果出错了怎么办」的产品决定。

ACT IV · 阶段二 v1.4.x23

Agent 启动后，用户原来只能「等着」

运行时控制面板

[l]切 LLM 模型换模型 / 调 temperature，改完立即生效，不用重启 Agent。热更新

[a]换 ASR换语音识别供应商，保存到配置。下次生效

[t]换 TTS换语音合成供应商，保存到配置。下次生效

[v]调 VAD调静音检测参数，保存到配置。下次生效

对话内容实时滚动显示，不用按任何键就能看到。全键盘操作，全程不退出 raw mode。

把「等着」变成「可以动手」。这是从工具变成产品的一小步。

ACT IV · 阶段二 v1.4.x24

一个血泪教训

raw mode 和 inquirer 不兼容

第一版 · 怎么按都没反应

用 inquirer 做子菜单

Enter 键被 raw mode 的 data listener 抢走。修了 listener 之后还是不行 —— raw mode 和 readline 有根本性的兼容问题。

最终方案 · 能用

纯 raw mode 数字键

全面废弃 inquirer 子菜单。[1] [2] [3] 选择，[0] 返回。全程不退出 raw mode。

这一类问题 AI 帮不上太多忙：它会顺着你的第一版方案不断打补丁，直到你自己决定推翻这个方案。

有时候正确的修法不是修，是换掉那一层。

ACT IV · 阶段二 v1.4.x25

每个版本发布后都有用户立刻测试

三条反馈，改变了产品

反馈 01 「RESTful API 密钥在哪找？上面写了一大段，但我只看当前输入行」 → 每个输入前加行内提示

反馈 02 「模型那步没有 key 就卡死了，没有后退」 → 留空 = 跳过，之后补全

反馈 03 「大段提示被忽略」 → 渐变框与输入行同时给

修法很具体：把提示写进输入行本身 —— App ID (console.shengwang.cn → 总览 → 项目信息):

你精心排版的大段说明，他不看。

MONEY QUOTE · 04

用户只看 当前输入行

三条反馈的共同规律只有这一句。
关键信息不在你排版最漂亮的地方，在光标闪的那一行。

ACT V / V

PLATFORM

这是方向性的跳跃

CLI 解决了「体验」，但没解决「开发」。开发者用 convoai go 试完觉得不错，然后呢？
他需要的是：一个自己的项目，有前端、有后端、能改、能部署。阶段三，约 8 小时。

I Token 账II 发版速度III 阶段一 IV 阶段二V 阶段三

ACT V · 阶段三 v1.5–v1.628

在写任何代码之前，先定五件事

五个关键设计决策

01前端栈纯 HTML + Vanilla JS —— 8 小时约束，零依赖，开发者拿到就能改。

02后端栈Node 主 + Python stub —— 同生态，一个 npm run dev 跑起来。

03凭证流转.env + .env.example —— 业界标准，安全，不泄露到 git。

04API 调用直接 REST API —— 透明，有教育价值，不藏在 SDK 后面。

05dev 机制CLI 检测 + delegate npm —— starter 独立运行，CLI 只是入口。

五个决策都不是技术偏好，是对「开发者拿到之后要干什么」的判断。

ACT V · 阶段三 v1.5–v1.629

四条命令，一条完整旅程

开发者路径

实现阶段把 12 个 Task 拆给 Subagent 并行执行，一个 subagent 一口气创建了全部 22 个 starter 模板文件。

CLI 不再只是一个入口，它成了通往「自己的项目」的那条路。

ACT V · 阶段三 v1.5–v1.630

这个项目实际上用了四个模型交叉审查代码

不同模型有不同的盲区

跨模型 Review 不是噱头，是正在成型的工程实践。

ACT V · 阶段三 v1.5–v1.631

三轮跨模型 Codex Review

不是 Claude 审自己的代码

01第 1 轮agora-rtc-sdk-ng 的 exports 字段拦截子路径 resolve。

02第 2 轮非 TTY 环境进 inquirer 阻塞、Gemini URL 模板未替换、Python 缺 interrupt。

03第 3 轮Windows spawn 需要 shell:true、端口检查硬编码、RTM 失败无 fallback。

加上 v1.5.0 阶段用 Gemini 和 GPT 做的架构 Review，一共四个模型。（Starter 规模：原文数据表记「20 文件 / 1,629 行」，正文记「22 个模板文件」，此处照原文并列。）

三轮，12 个问题，全部修完。

MONEY QUOTE · 05

不同的模型 有不同的盲区

Claude 的代码生成最强，但 Codex 对 npm 生态的边缘 case 更敏感，
Gemini 对架构简化有直觉，GPT 对竞态条件有嗅觉。

ACT V · 阶段三 v1.5–v1.633

字幕战争

完美方案被环境挡住了

不完美，但能用。这就是做产品的现实。

MONEY QUOTE · 06

你想要的完美方案 被环境约束挡住了 你得在约束里找到 能 ship 的方案

DataStream 不发 Agent 字幕，RTM 又要用户额外开通服务。
能 ship 的那一版，长得不好看，但它上线了。

全景回看35

33 个工作小时，跨 3 天

四个阶段，四种产品性质

17hv1.0→v1.2.1CLI 核心 + OpenClaw 集成 —— 工具

3hv1.3.x渐变 UI + i18n + 步骤重排 —— 品牌化工具

5hv1.4.xconvoai go + 控制面板 + 用户反馈修复 —— 产品

8hv1.5→v1.6init/dev + Starter + 三层架构 —— Developer Platform

中间没有一次「重写」。每一层都是在上一层还能跑的前提下，把它往前推了一格。

现在这个版本，已经可以用「平台」而不是「工具」来称呼了。

现在的状态36

三条命令，覆盖完整旅程

试用、体验、开发

# 试用（3 分钟） curl -fsSL https://convobench.org/install.sh | bash # 体验（10 秒） convoai go # 开发（2 分钟） convoai init my-voice-app && cd my-voice-app && convoai dev

01ROADMAP

ConvoBench

语音 Agent 自动化评测。

02ROADMAP

Telephony connector

接上电话网络。

03ROADMAP

React 模板

Starter 的第二个技术栈。

还没结束。但这个版本已经站得住「平台」这两个字。

带走37

如果只带走三件事

这三天里最可复用的三条

01

给流程

只让 30% 的 Token 去写代码

学习、设计、Review、调试占掉 70%。先想后写、先测后发，Token 的利用效率会高得多。

02

给命令

按「第几次用」来设计入口

不要让用户在 30 个命令里挑。第一次给 quickstart，第二次给 go，想换配置给 go --setup。

03

给审查

换一个模型再审一遍

Claude 生成、Codex 抓 npm 边缘 case、Gemini 简化架构、GPT 嗅竞态。四个模型，12 个问题。

那些阻碍你把想法变成可用版本的中间环节 —— 排期、等待、联调、发布窗口 —— 正在一个一个被碾平。

MONEY QUOTE · 07

「能力到交付」的鸿沟 正在被系统性地消除

以前的瓶颈是「做不出来」。现在的瓶颈是「想不清楚」。
做不出来可以靠加人加时间。想不清楚，加多少人都没用。

谢谢

一个产品的三天

从工具，到品牌化工具，到产品，到平台。

Author姚光华 Colin · 声网 ConvoAI

一手源本人 2026-04-02 – 04-04 开发记录

数据口径Token 实际 5–6M（上篇标注 ~4M）

立场提示作者即项目作者，非第三方评测