一句话定义
接受率（Acceptance Rate）是代码补全类工具最核心的产品指标：编辑器弹出补全建议后，用户真的按 Tab 或回车、把它变成自己代码的比例。
这个比例怎么算
分母是“建议被展示的次数”，分子是“建议被采纳的次数”。听起来简单，但实际有好几种计算口径，看数之前得先问清楚：
- 按条算：假设弹出 10 条建议，你接受了 3 条，接受率就是 30%。
- 按字符或行算：一条建议可能是一整段函数，只看其中多少行最终留在文件里。
- 按会话或人算：统计一段时间内有多少活跃用户至少接受过一次。
不同产品的接受率往往不是同一口径，跨厂商直接比大小没有意义，具体定义以各家官方文档为准。
打个生活化的比方
还记得用拼音输入法打字吗？你敲 “nihao”，候选栏跳出“你好”“你号”“尼豪”，你按空格选了“你好”，这就是一次“接受”。输入法厂商很在意这个数：候选词排得准，用户点得就多；老是推生僻词，用户干脆自己从头打完，候选栏就白占了屏幕。
代码补全完全一样，只是候选词从两三个字变成了半行到几十行代码，选中的动作从空格键换成了 Tab 键。
和几个容易混淆的指标的区别
| 指标 | 衡量什么 | 容易被什么情况抬高或拉低 |
|---|---|---|
| 接受率 | 已经弹出的建议中被采纳的比例 | 只弹极保守、极短的补全时，接受率会虚高 |
| 触发率/覆盖率 | 多少比例的输入能触发建议 | 门槛设太低，频繁弹出一堆没人用的建议 |
| 采纳后编辑率 | 接受的代码随后被改掉了多少 | 能识别出“先接受、再重写”的无效接受 |
| 编译/测试通过率 | 生成的代码本身对不对 | 正确但没人愿意用的代码照样不产生价值 |
| 留存/活跃度 | 用户还愿不愿意继续用 | 短期很热闹、长期却流失 |
关键区别在于：接受率是一种隐式反馈（implicit feedback），用户按 Tab 并不等于满意，也可能只是懒得多打几行。因此有经验的团队会把它和“接受后又被大幅修改的比例”“建议长度分布”“触发频率”放在一起看，而不是只盯着接受率这一个数。
对从业者和普通人的意义
对做产品的人来说，接受率离用户行为最近，几乎能实时统计，适合当 A/B 实验的主指标；但它也很容易被调整，只要把建议变短、变得更保守，接受率就能上去，用户实际省下的时间却没变。所以看接受率时必须配上“护栏指标”，否则容易优化出一个好看却无用的数字。
对一线工程师来说，这条指标意味着优化补全不只是“生成更正确的代码”，还包括“在对的时机、以对的长度出现”：补全半行，比一口气补全五十行更容易被接受。
对普通职场人来说，它解释了日常体感：为什么补全有时像读心，有时又啰嗦得像在抢键盘。这背后是产品在“多弹”与“弹得准”之间不断权衡的结果。