这是一个创建于 150 天前的主题，其中的信息可能已经有所发展或是发生改变。
我看了下，对外公众看到的 App 有版本更新后的日志内容都是类似这样的，实在搞不懂算是写了还是没有写？写出来都是不痛不痒的文字描述，没有具体的实质性文字内容展示，与其这样，还不如不提供下述案例中的文字描述呢？
对外话术 1：解决已知问题，优化用户体验。
对外话术 2：问题修复及性能优化，改善用户体验。
对外话术 3：我们进行了一些小更新，多项细节优化，希望为你提供更好的使用体验。
对外话术 4：修复了已知问题，优化整性能，让点餐体验更顺滑。
对外话术 5：BUG 修复。
对外话术 6：修复部分小错误，提升整体稳定性。
对外话术 7：优化了多项交互细节，提升使用体验。
对外话术 8：解决部分已知问题，持续优化使用体验。
对外话术 9：修复已知问题，优化部分内容。
对外话术 10：优化了产品使用体验并修复了一些问题。
对外话术 11：修复了一些 BUG 。
另外，微信万年不变，永远是：优化了一些已知的问题。
而不是向有些比较好的 App ，会动脑子写日志信息，比如：
新增：XXXX
优化：XXXX
修复：XXXX
对外话术 1：解决已知问题，优化用户体验。
对外话术 2：问题修复及性能优化，改善用户体验。
对外话术 3：我们进行了一些小更新，多项细节优化，希望为你提供更好的使用体验。
对外话术 4：修复了已知问题，优化整性能，让点餐体验更顺滑。
对外话术 5：BUG 修复。
对外话术 6：修复部分小错误，提升整体稳定性。
对外话术 7：优化了多项交互细节，提升使用体验。
对外话术 8：解决部分已知问题，持续优化使用体验。
对外话术 9：修复已知问题，优化部分内容。
对外话术 10：优化了产品使用体验并修复了一些问题。
对外话术 11：修复了一些 BUG 。
另外，微信万年不变，永远是：优化了一些已知的问题。
而不是向有些比较好的 App ，会动脑子写日志信息，比如：
新增：XXXX
优化：XXXX
修复：XXXX
 | 1 skallz 150 天前  1 说的好像国外不是一样，国外很多 app 一样和这差不多，主要是版本迭代有时候东西太散太碎，没办法写的很详细 |
 | 2 lychee930224 150 天前 没人在意。。。 |
 | 3 bclerdx OP @lychee930224 为什么没人在意？这不是有人在意嘛？ |
| 4 lychee930224 150 天前 @bclerdx 我就是写这个的，“没什么人在意” |
 | 5 Lowlife 150 天前 via iPhone 让我想起某 app 写:杀了一个程序员祭天 |
 | 6 pingdog 150 天前 via Android CICD 方便直接推，写这写那的还得手工推 |
 | 7 cutecore 150 天前 那你是没看过 youtube 的 ， 喝了太多咖啡/探索了宇宙的边界/看了更多的猫咪视频/下午休息下/div> |
 | 8 choah 150 天前 有时候改程序就是这样，改了一个看着就有问题的地方，但是呢又不能形象化描述，在提交里只能说修复内存问题、优化程序逻辑等等等等 |
 | 9 xiangyuecn 150 天前 版本号也是一堆无意义的数字，有年月那种还好点 知道是哪个朝代发布的版本 苹果家也学乖了，开始用年份命名 xxx 26 ，看到版本号不用查年份对照表了 剩下 Android 和 Harmony 两个傻 |
 | 10 jiirouwei 150 天前 之前写，后来渐渐的都不写了是因为，写的太详细了，就导致有些人不升级，旧版本会有一些可以利用的 bug |
 | 11 Kenshiro 150 天前 via Android 以前那会更新 apps 还能激动一波，现在一看这说明立刻不更 |
 | 12 Chicagoake 150 天前 基本没人在意，没必要花心思去写。 |
 | 13 little_cup 150 天前 5 作为开发者，我对外也越来越倾向于对外使用「 Bug 修复和性能提升」这种套话了。 以下是一些情况的模拟举例： - [新增]: 针对 A 厂设备，新增…功能 用户：我们 B/C/D 厂的怎么就不行？ - [修复]: 修复某情况下的某 bug 用户： 更严重的某某 bug 怎么不修？净整这些没用的 - [变更]: 因为学习成本过高，对新用户不展示某某功能，已启用的老用户保留 用户 A： 难道不能加个开关吗？（现在开关已经需要翻页了）用户 B： 搞这么多开关不会用 - [新增]: 新增新样式的支付界面 用户：想钱想疯了 更新日志属于 PR 的一部分，除非有明确需要对外宣传的新功能，否则多做多错，不做不错。 |
 | 14 moefishtang 150 天前 via Android @cutecore 现在哔哩哔哩更新日志也开始学这个了 |
 | 15 OrionParker 150 天前 就跟我写 git 提交记录一样 不知道咋写 |
 | 16 chqome 150 天前 都是随心写的，不可能一五一十给你交代得清清楚楚 |
 | 17 JensenQian 150 天前 这东西就和我每天的工作报表一样 随便写点 |
 | 18 GDSR 150 天前 via Android YouTube：请查看产品内的相关说明及通知，了解并学习使用新功能！ Chrome：感谢您选择 Chrome ！此版本在稳定性和性能方面均有所提升。 |
| 19 GDSR 150 天前 via Android @GDSR 再补几个： Snapchat：漏洞修补和改进！ Line：已修复部分问题。请将 LINE 应用更新至最新版本。 Uber：我们尽可能频繁地更新优步乘客端，以便为您提供更便捷可靠的服务。该版本修复了几个错误，并改善了多项性能。 喜欢这款应用吗？请给我们评分！您的反馈是优步不断进步的动力。 有疑问吗？请轻触优步乘客端中的“帮助”或访问 help.uber.com 。 |
 | 20 lindongwu11 150 天前 VSCode 好，每次都有一整页的更新报告 |
 | 21 usVexMownCzar 150 天前 有时候可能有严重的 bug ，我给你写出来，你不更新怎么办。 比如一个 app 在某次更新后，原本的订阅制，20/月，失效了，用户 0 付款就能使用订阅的功能，还无法通过网络来限制这个功能。本来可能就一小部分用户知道，然后告诉了开发者。之后开发者下一版本修复了，更新日志写「修复了用户 0 付款订阅制的问题」，用户看到更新日志，直接停在 0 付款的版本，那开发者不是亏大了。 当然还有另外一个原因，不写清楚，审核也就不清楚我更新了啥，稀里糊涂的审核就通过了。 |
 | 22 cwxiaos 150 天前 via iPhone/span> 少部分认真写的，大部分敷衍，appstore 一样 |
 | 23 zhanying 150 天前 via iPhone @bclerdx 在意的人不多，就和 electron 一样，看 v2 以为人人喊打，事实上 99.99%的人根本不在意。app 更新这玩意大部分人直接自动更新，谁闲的一个一个看更新内容…… |
 | 24 zhxhwyzh14 150 天前 via Android play 商店的也一样，特别是谷歌自家的 app |
 | 25 cokey 150 天前 上面有人说的对，除非有明确需要对外宣传的新功能，否则越简单越好。 不然 1 是比如你把修改了哪些问题暴露出来，那有些用户就不升级了，说不定可以利用你的老版本的某些 bug 2.是你的一些修改点是用户不喜欢的，用户也不升级了 3.是会增加审核不过的风险，你写详细了，审核员就会全部覆盖测试你的新增和修改点，你写简单点比如修改了一些问题，审核员就随便玩两下过了 |
 | 26 bgm004 150 天前 因为用户是真的不会去看啊。看了也看不懂。 |
 | 27 myderr 150 天前 总不能写 新增了 xx 广告吧 |
 | 28 psklf 150 天前 1 @GDSR #18 Spotify: We’re always making changes and improvements to Spotify. To make sure you don’t miss a thing, just keep your Updates turned on. |
 | 29 ShinichiYao 150 天前 想到了过去早先会写的很详细，后面越来越简单，也说明需要改进的东西越来越少 https://lineage2s.net/changelog.html |
 | 30 maxmax4max 150 天前 新增了广告 sdk 你会写上去吗，协议或者业务流程修改更有利于企业你会写上去吗？主要还是减少不必要的麻烦。 |
 | 31 sc2yml 150 天前 正常，看看小破站的，三点到了饮茶先 |
 | 32 qwerthhusn 149 天前 就连 iOS 商店的 X ，Youtube ，Facebook 等这些全是随便写的 |
Select Language