一个指标拦下了一个会走歪的方案。那个方案成立的前提是丢失发生在尾部，而真实情况恰恰发生在头部。
把平台记录的候选人发言调出来看，好多段不是从句子开头起的。
| 时间 | 平台记录到的开头 | 丢了什么 |
|---|---|---|
| 02:33 | 段。首先，我会组织需求调研会议…… | 上句尾部只剩一个段字 |
| 03:10 | 来说，项目初期，销售、技术、运维…… | 一般 两个字不见了 |
| 04:10 | 免再次出现类似偏差，建立统一的状态机…… | 以避 丢了 |
| 05:10 | 取了以下步骤，明确业务价值…… | 我采 被截掉 |
更关键的错位证据：有两段记录其实是同一条自我介绍答案的前后两截，中间被平台插了一句追问。平台按自己的时间窗切段，不认我们的句子边界。
语音活动检测不是一直开着听的，它得先判断有没有人在说话，有才开录，安静够久就认为说完。可以把它想成一个看门的人，听见动静才开门，安静够久就关门。而开门是有延迟的。
于是每次开口，最值钱的那半秒被系统性吃掉，而开头恰恰是点题、信息密度最高的地方。
别混淆两个长得很像的问题。大脑服务那套参数出问题时的表现，是听面试官的问句被截断，方向和责任正好相反。文档的态度很明确，由服务端治理、客户端不许打补丁，因为这类补丁会污染指标。
当时的流行推理是，平台一轮可能只收得下六十到一百字，那就把答案压短到两百字以内。
反对意见不复杂，却把整件事翻了个面。如果第一句是被系统性吃掉的，那么答案越短，首句占比越大，丢失比例反而可能更高。
而最要命的地方是，丢失到底发生在哪一部分，从来没有被单独量过。所有关于长度的讨论，都建立在一个没量过的假设上。
指标脚本里加两个字段，这条答案的第一句有没有出现在平台收到的片段里，以及它的比例。名字很直白，就叫首句落地和首句落地率。
关键设计是这个指标只负责量，不负责修。需求里明文写着，不得在拿到实测之前直接实施引导音方案，那等于盲改。
还有个意外收益。当时已经没有岗位可跑，多数验收写的是跑一场，于是先做了一个离线回归工具，固定三个历史场次当基线。这条首句落地率，正是第一次在离线工具里算出来的。
| 场次 | 首句落地 | 率 | 同场整体送达率 |
|---|---|---|---|
| 夜场 night A | 8/16 | 0.500 | 0.334 |
| job27 零四零三场 | 1/20 | 0.050 | 0.289 |
| job27 零七四零场 | 3/20 | 0.150 | 0.256 |
必须并排看的原因：只看首句落地率只能说它低。一比就清楚了，五成对比三成三还算说得过去，而百分之五对比两成九差了一个数量级，这不是随机波动，是结构性的。
结论是，平台不是少听了一点，而是每次都从答案中间某处起录，首句被系统性牺牲。作为对照，这三场的听对率分别是百分之一百、零点九四七、零点九四七，我们听别人听得很好，问题只出在平台听我们这一侧。
因为反例越强，拦下的动作越大。如果数字出来是九成，压短方案顶多是方向不精准；而它出来是五成、百分之五、百分之十五，说明那条待办从根上就是错的。
这条数据把三条独立的线彻底分开，在此之前它们被揉成一个词，叫效果不太好。答案太长被我方截断，答案开头被平台起录滞后吃掉，以及空转话术。三者表象相同，都会招来那句好像没有听到您的声音，但修法完全相反。
| 选项 | 做法 | 评价 |
|---|---|---|
| a | 播报前加零点三到零点五秒引导音，或一句前置短语 | 最像解决方案，但要动整条播报时序 |
| b | 首句强制短句化，二十字以内且句末完整 | 损失有限，但同样改动时序 |
| c | 只记账，把指标单列出来让它一直被看见 | 当时的建议，先走这条 |
于是需求状态写成，量化已完成，处置待确认，开工前需要人类再确认一次。而那条被它挡下的压短方案则单独冻结，两条被明确写着不许合成同一个动作。
REQUIREMENTS-DEV.md §0 v4 必读第 3 条、C-007、R-DATA-012（v4 实测表）、§1.2.1 裁决表；AGENTS.md 当前状态节。
场次锚点：data/2026-10-05T18-21-09_night_2026-10-06_A、data/2026-10-05T20-03-42_auto_0403_job27、data/2026-10-05T23-40-29_auto_0740_job27。