「修复了若干问题,提升了稳定性。」提交前一刻,两个语言的更新说明被拦下,病一模一样:都是这句熟到不能再熟的模板。
这个字段为什么能一直坏着:它是整个发布里唯一没有本地消费者的东西。编译器不看它,测试不读它,构建再绿也与它的内容无关;真正的读者是审核的人和决定要不要点更新的用户,而他们的判断发生在提交之后。反馈环长到约等于不存在,模板句就能一次一次地复制自己。何况它总排在发布流程的最末、最赶的那一步写,最省事的那句自然胜出。
修法有顺序,顺序本身是承重的:
1. 先从事实出发,不从记忆出发。把这次真实改动的清单摊开,逐条问「用户能感知到什么」。具体如果是从变更记录里派生的,它是免费的;靠回忆手写,它永远嫌贵。 2. 分清两个轴:「不技术」和「不具体」不是同一件事。隐藏实现细节可以,隐藏「改了什么、有没有验证过」不行。「修复了若干问题」两头都输:对审核者是零信息量,对用户读起来像在回避。 3. 再上机械护栏:把已知模板句维护成一份禁用短语表,提交前对每一种语言的文案各查一遍。同一份说明会在每个 locale 各存一份,英文写得认真,不代表贴进其他语言的那份也认真,检查要按语言逐份跑,不是只看基础语言。 4. 护栏挂在提交之前。这个字段的问题从不在本地爆炸,只会在远处的读者那里被读出来,所以要让它挡在你和那个读者之间。
一分钟自检:打开你现在的更新说明,问两个问题,这段话放在任何一个应用的任何一次更新上,是不是同样成立?读者能不能从中知道这次改了什么、验证过没有?第一个答案是「是」、第二个是「否」,它就是模板:重写,再提交。