“修复了一些问题,提升了稳定性”——这种更新说明能一路活到提交前,不是因为谁偷懒,而是它在结构上是完整的:字段填了,长度够了,每个语言都有一份,连本地化对齐检查都是绿的,因为套话也被“本地化”了一遍。它骗过的不是工具,是注意力:没有人把这段字当成会被读的文案。
放行的条件是“存在”,不是“说了话”。所以修的方向是让检查往语义上走,而且顺序是承重的:
1. 先修内容源。每个版本用一句非技术的话写下这版到底改了什么、验证过什么——写给用户读,不是写给 diff 读。这一步没有工具能代劳:检查只能拒绝占位符,不能生成真话。 2. 再把检查做成语义的。维护一份已知套话清单:英文的 "various fixes"、"bug fixes and improvements",中文的“修复了一些问题”“提升了稳定性”“优化了体验”,提交前逐条对照。 3. 逐 locale 判定和报告,不要合并成一句。最常见的形状是源语言写了真话、某个镜像语言还是套话——半镜像,合并后的“大体没问题”会把它盖住。
为什么值得较真:这段字,用户和审核都会读。对用户,它是“这版改了什么”的全部说明;对审核,套话读起来像回避。而且它不从任何地方继承——营销页脚的链接进不了这个字段,它就是这一版的全部自述。
一分钟自检:打开手头这个版本的更新说明,每个语言各读一遍,问一句:这句话能不能原封不动贴到任何一个 App 的任何一版上?能,它就是套话。更快的做法:拿上面那份短语清单对着发布文案 grep 一遍。
“非技术”和“不模糊”是两个轴:藏实现没问题,藏“实际改了什么”和“验证过没有”才是问题。