第一版”会议录音转写”写了三天代码，上线当天就把付费接口拖崩。复盘发现问题不在代码，而在设计：功能边界没划清，限流维度没想好，模型成本没有封顶。后来我们改成”问题—边界—指标—方案—灰度”五步走，同类型功能四小时就能定稿，之后再没出过这类事故。
给这类产品加新功能，先按这套流程走，而不是一上来写代码。设计阶段要做三件事：明确问题边界、画出数据流、定义成功指标；评审阶段要把”会不会影响付费与限流”作为强约束。
一、为什么要先做设计
新功能上线常失败，是因为只看到用户呼声，没看到对系统其它部分的影响。比如”增加直播总结”会同时影响下载器、字幕、模型选择、付费策略和实时性要求，任何一个环节没接上，功能就是坏的。
我见过一次典型的翻车：加”高清无损下载”选项时，下载器只按清晰度透传参数，没核对下游。部分来源返回的其实是分片视频，总结接口拿到的输入不对，字幕对不上时间轴，整个链路从源头就错了。事后查日志，需求评审只讨论了”能不能加”，没人问”加了之后下游谁受影响”。先做设计，本质是花半小时把链路风险摊在桌面上。
另一个原因是成本。设计阶段改边界只损失一页纸，写代码之后再改等于返工两遍。我们团队后来把设计评审设成强制关卡，没有评审记录的功能不进排期，新人加入时也靠这套流程快速对齐。
二、设计模板
每加一个新功能，按下表梳理。这套模板是我踩过坑之后整理的，六个格子填满，功能才算想清楚：
| 项 | 关键问题 | 文档约束 |
|---|---|---|
| 用户价值 | 谁会用？解决什么？ | 不写”提升体验”类虚词 |
| 边界 | 不做什么？ | 写明排除场景 |
| 核心数据 | 输入输出字段、来源 | 字段必须稳定可追溯 |
| 接口 | 内部 API、第三方依赖 | 标注速率限制 |
| 指标 | 成功如何衡量 | 至少 1 个可量化指标 |
| 风险 | 付费、限流、模型成本 | 风险与缓解措施配对 |
“指标”和”风险”两行最容易空着。指标写”提升体验”这类虚词等于没写，至少要有一个可量化数字，比如”转写成功率不低于 95%”；风险行必须与缓解措施配对，只写”可能超预算”而不写封顶方案，评审直接打回。
三、典型功能：会议录音转写
以”上传本地会议录音，自动转写并总结”为例。这是用户提得比较多的需求，我们原以为把视频输入换成音频输入就行，设计时才发现音频没有画面帧，分段、说话人分离、时间轴对齐全都要重新处理，工作量不比新做一个模块少。完整链路分五步：
- 用户上传 → 校验时长 ≤ 2h；
- 音频分段 → 每段 ≤ 30s，交给 ASR；
- 转写文本 → 说话人分离（可选付费）；
- 总结 → 模型分级（短总结免费，长总结按段计费）；
- 导出 → Markdown / PDF / Notion 同步。
第五步导出看起来不起眼，却是付费转化的关键：用户拿到一份能直接用的 Markdown，才愿意为长总结掏钱。我们把渲染层独立成模块，后来加 PDF、Notion 同步只改导出端，转写链路一行没动。
3.1 数据流
下面这张数据流图是评审时贴在白板上的底稿，用来确认每个节点的输入输出都有人负责。它解决的核心问题是：谁在什么时候调用了什么模型，成本花在哪一段：
上传 → 临时存储 → 分段 → ASR → 说话人标记
→ 总结模型 → 术语校对 → 渲染 → 导出图上最容易忽略的是”术语校对”节点。最初没有它，会议里的产品名、人名被 ASR 打错，总结里全是错词；加一层术语词典替换后，准确率明显上升，成本只多了一次小模型调用，这笔投入很划算。
3.2 与现有系统的边界
设计稿里单列一节边界，是为了回答一个问题：新功能会不会把老功能的配额和计费搞乱。我们当时的约束是三条：
- 限流：上传后立即占用 1 次配额，避免中途滥用；
- 付费：长总结按”段 × 模型”计价，避免无封顶；
- 性能：上传与转写解耦，前端只关心进度。
限流这条我们吃过亏。第一版在上传完成才扣配额，有人反复失败重试，把 ASR 预算耗光，连累其他用户。改成上传即占用配额后，滥用基本绝迹。付费按”段 × 模型”计价，是为了让成本可预测——转写是硬成本，总结是模型成本，两项都要有封顶。
配额检查的伪代码长这样，核心是先查再扣、一次性完成：
def check_quota(user, feature):
used = counter.get(f"{user}:{feature}", 0)
limit = user.quota.get(feature, 0)
if used >= limit:
raise QuotaExceeded(feature)
counter.incr(f"{user}:{feature}", 1)
return True注意两个细节：先校验再扣减，顺序反了会多扣；多实例部署时还要配合 Redis 原子操作，否则用户连点两次，配额会被漏扣。
四、典型功能：浏览器插件
第二个典型功能是浏览器插件：抓取当前页视频元数据并请求后台总结。它和录音转写不同，不用上传文件，但要处理跨域、鉴权、限流提示三件事。设计要点如下：
| 关注点 | 解决方式 |
|---|---|
| 鉴权 | 用户登录后拿到 token，存到插件本地存储 |
| 限流 | 每分钟最多 3 次，弹出提示 |
| 数据 | 仅抓取页面 URL 与标题，不抓取正文 |
| 付费 | 与 Web 端共用账号，按总结次数扣减 |
插件端的核心原则是”尽量少抓”。只取页面 URL 与标题，正文一律不进后台，既减少隐私争议，也让限流判断更简单——按次数扣减，不按内容量扣减。
五、灰度上线
不要一次性全量。灰度不是发布选项，而是质量兜底，尤其是动了付费与限流的改动，一次全量出问题，影响的是所有用户。我们的流程是：
- 内部用户先跑 3 天；
- 切 5% 真实流量，看错误率与延迟；
- 灰度期同时保留旧入口可回退；
- 全量后保留 7 天观察期。
第三点的回退开关经常被忽略。我们在灰度期保留旧入口，新链路出错时一键切回，用户无感知。灰度数据重点盯错误率和延迟两个指标，前者看功能是否可用，后者看是否拖慢老链路。
六、文档与协作
设计稿不是写给领导看的，是写给一周后的自己和下一位维护者看的。信息不落文档，两周后没人记得当时为什么这么定。设计稿至少包含：
- 一句话价值主张；
- 边界清单；
- 关键流程图（用户视角 + 系统视角）；
- 接口列表；
- 风险与回滚方案。
接口列表写清楚后，前端可以并行开发，不用等后端。流程图至少要画两张，一张用户视角、一张系统视角，两张图对不上，说明需求还没想透。到这里，一套”先设计后开发”的落地链路就完整了。
常见问题（FAQ）
Q1：加新功能时怎么判断该不该上？
看付费用户与活跃用户的重合度，重合度高才值得优先做。
Q2：哪些功能应该先做？
边际成本低、复用现有组件、能直接拉动付费的功能。
Q3：怎样避免新功能拖累老功能？
保持模块边界，灰度上线，并设置回滚开关。
