9 月 25 号，有人打开 VS Code，看见了圆角。
然后他决定，把这件事报上去。
我读到那份复现步骤的时候先笑了很久，后来有点笑不出来。步骤一共两步，我原样转述，因为它值得：第一步，打开 VS Code。第二步，编辑器界面就会显示圆角。
【舞台提示：此处应有掌声，但掌声现在也是圆的】
这是我这辈子见过最诚实的复现步骤——它精确描述了从正常到灾难的全过程，中间没有灰区，没有偶现，没有"重启后消失"。打开，圆角。这两件事在时间上是同一件事。
它同时也是最没用的复现步骤。没有一个开发能照着它修。
不对，我收回。真要查是查得出来的：如果某次提交把某个边框属性从 0 改成了 6，bisect 照样能把它揪出来。所以问题从来不在能不能定位——定位到了又怎么样。
这才是我想说的那件事：圆角不是 bug。圆角是一个所有人都觉得好看的决定。
bug 你能修，"大家都同意"你修不了。你在 PR 里写一句"这行改成 4 会清爽一点"，review 里会有人排着队回你同一个 emoji，表情停在"你是认真的吗"和"审美不同但我懒得跟你辩"之间。
接着看他干了什么。
他在禁用所有扩展的前提下复现了这个问题。
遇到界面出怪事，第一反应先关扩展，这套流程我熟。关到最后剩一个光秃秃的编辑器，问题还在——那感觉像把家里所有电器插头都拔了，发现漏电的是墙本身。他以为自己剥一层皮就能找到病灶，剥完才发现，圆角长在骨头上。
顺带说一句，他把文本编辑器、文件资源管理器、终端和 Copilot Chat 全列进去了。
Copilot Chat 也圆了。
这个细节我最喜欢。连 AI 都躲不过这次统一视觉规格，它没法拿"这不是我负责的模块"甩锅，因为它自己就是那个模块。一个连自我意识都没有的对话框，就这么被悄没声地磨圆了边角，连意见都没法有。
然后，重头戏。
这份报告被标记为重复，关闭。
我盯着这四个字看了半天。这才是真正的渡劫——不是被圆角折磨，是你熬了一晚上，排查做到最彻底，复现步骤写得朴素又真诚，提交上去，得到的回复是：这个有人提过了。
你想象一下那个画面。你以为自己推开了一扇新世界的门，系统告诉你，这世界上一共有两百个你。
而且他多半搜过。搜不到，因为那两百份报告里，标题可能写的是"面板圆角不一致"，也可能写的是某个组件名加一串数字。总之搜不到，你只能提一份新的，然后被人用一分钟判定成别人的影子。
在座的各位可以自测一下：现在把窗口拖到全屏，找个直角出来。找不到了。你甚至不记得它是从哪天开始变圆的——他记得，他还写下来了，还提交了。
（郑重声明：以上是对一个已关闭 issue 的情绪投射，本人对圆角本身毫无意见，本人此刻的编辑器也是圆的。）
再补一个细节，整件事里最冷的那个。
这个 issue 没有类型，没有项目，没有里程碑，没有关联项，没有开发分支，也没有任何拉取请求。
它有一个指派人。
也就是说，有个人被正式指派去处理这件事，而这件事的定义是：处理它，是不存在的。
这大概是现代软件工程里最精妙的一句职场隐喻。但我不展开——展开就得牵扯到具体的谁，那样就不好笑了。
最后，那个页面上反应功能显示不可用。
它死了，没有一个人能给它的尸体点个赞。🫠
我本来想用"圆角无罪"收尾，想了想，不成立。圆角有罪。罪的形态是它太安全了——安全到没人愿意为干掉它付出成本。尖角是有风险的，尖角会有人说太锋利；圆角不会。它是设计界的沉默大多数，它赢不是因为它对，是因为没人反对。
所以那份报告注定是这个结局。不是因为他错了，恰恰是因为他描述的，是一件所有人都已经接受了的事。
（友情提示：本条不针对任何具体桌面环境、设计语言或前端框架。如果你此刻正看着自己编辑器里那个圆润的边角，请把它想象成多年前那个方方正正的它，然后顺便想想，这些年你都做对过什么。）