迭代篇：一枚图标，四个版本——Python Skill 的"活体进化"实录，这次邀你一起共建

原创 李伟坚 Excel催化剂（附件请在原始资料库或公众号中获取）)

2026年10月13日

先讲一个我自己的真实故事。 开发上一个 MYN 任务管理工具的时候，我总觉得任务栏图标“怪怪的”——不清晰。我第一反应：是不是图标的边框线太细了？于是反复换图标……可换来换去，还是看不清。 直到一次次验证、一次次和 AI 对话，才终于挖出真相：问题根本不在图标上，而是 NiceGUI 这个 UI 框架的问题。 一个图标而已，至于这么较真吗？至于。因为在我这里，每一个不起眼的细节，都不该被放过。 这篇推文，就讲这枚图标的四轮死磕——以及一个邀请：这场进化，我想请你一起来。

---

一、“小题大做”：一枚图标的四轮死磕

我给 Python Skill 记着一本“进化账”——就在它的 CHANGELOG 里。翻开最近的几页，你会看到一个有点“偏执”的故事。

第一轮：发现图标“静默失效”

事情开头很普通：一个真实交付的项目里，用 Skill 打包出来的桌面程序，窗口图标不对——显示的是系统默认的蓝方块，而不是自己的图标。

这种事，在别人那里可能就“算了”。但我追了一下，发现水比想象中深：

• 代码明明写了设置图标的语句，日志里也显示“设置成功”；
• 可实际上，图标根本没生效——不报错、不崩溃，就是悄悄失败；
• 更绝的是：不打包时一切正常，一打包就失效。

“完成”了，但没“成功”。这就是最危险的坑——它不报错，它骗你。

我花了整整一轮版本，把底层机制翻了个底朝天，最后把整个设置方案换成更底层的系统接口重写。顺手立了一条铁律：验收图标，不许“截个图看看”，要直接读像素、用数据说话。

实机验证那天，读出来的数字是 740。图标，真的上去了。

第二轮：这一回，坑是我自己踩进去的

说起来有点好笑——第二轮的起点，不是别人的反馈，而是我自己的项目“犯傻”。

开发 MYN 任务管理工具的时候，我总觉得任务栏图标怪怪的——不清晰。

我第一反应：是不是图标的边框线太细了？——换！换一版，还是看不清；再换一版，仍然糊涂。图标换了一轮又一轮，问题像粘在屏幕上一样，怎么都甩不掉。

直到一次次验证、一次次和 AI 对话，我才终于挖出真相：问题根本不在图标上——是 NiceGUI 这个 UI 框架的问题。 它在处理任务栏图标和窗体左上角图标时，天生就容易“糊”。

换句话说：我前面折腾的所有“换图标”，方向全错了。

最邪门的还是对比：

• 同一枚图标文件，放在微信、影刀这些成熟应用上，清清楚楚；
• 放到 NiceGUI 打包的应用上，必糊。

同一个文件，为什么两种命运？

我不服，继续刨根。越挖越深——这一挖，居然挖出了一个四个连环坑：框架取图标的方式有问题、图标文件本身的“尺寸目录”不全、图标的视觉风格在作怪——甚至连负责生成图标的那道工具链，都埋着一颗雷。

坑坑相扣，缺一不可。 那几天的感受，说出来都是泪：解决一个，冒出下一个；再解决一个，又冒出一个。一个人对着屏幕，跟一枚 16 像素的图标死磕到底。

最后，四个坑被我一个个全绕了过去。方案说白了就一句话：给图标备齐“每一个缩放档位都恰好精确”的尺寸，再让程序在启动时，按当前屏幕真实的缩放比例，精确匹配那一帧。

听起来简单，做起来难——因为这不是“找篇文章照着抄”的事，而是全世界都没有现成答案的事。

修好之后，我复盘了这次“翻车”，也想明白了一件事——为什么偏偏会在这里栽跟头？

• AI 写代码，强在业务逻辑——流程、结构、算法，它又快又稳；
• 但 UI 型代码，从来不是它的“原生强项”——界面这东西，很吃视觉、很吃细节调校，差一点都瞒不过眼睛；
• 再加上这些第三方包比较新——NiceGUI 这类框架面世不久，网上的语料少、范例薄，AI 用起来也相对陌生。

几项一叠加，各种小瑕疵就容易钻出来。这不是 AI 不行，而是说明：再强的 AI，也需要有人替它把坑探明、把经验沉淀。

第三轮、第四轮：把“答题”变成“标准答案”

修好我自己的 MYN 之后，我做了一件更重要的事——把这次优化，重新写回到 Python Skill 的蓝图项目里。

这一步的意义，值得展开说：

• 对下一个使用 Skill 的人：再也不会踩这个坑——做出来的程序，图标开箱就是清晰的；
• 对 AI：不用再“反复试错练习”——蓝图里已经放着标准答案，一把就能做出效果；
• 对我：这个坑，从“我的教训”，变成了“大家的资产”。

而且不是“我说好了就好”——同一枚图标，我在五个技术框架里全部实测了一遍：

• 哪个默认必糊、需要内置修复；
• 哪个轻度模糊、需要特别处理；
• 哪个无需处理但要防止回退……

全部记录在案，写进文档，还加了“质量门禁”——下次谁想偷偷把修复代码改回旧写法，不许过门。

回顾：这一枚图标，一共有多少轮？

• 丢失修复一轮（静默失效 → 底层接口重写 → 像素级验收）；
• 模糊修复又一轮（四个连环坑 → 精确尺寸 + 精确匹配）；
• 蓝图内置一轮（让所有人不再重踩）；
• 五框架回归一轮（把个案变成标准）。

四个版本，五个框架实测，一条不许回退的门禁。

而这一切，只是为了任务栏上那枚 16 像素的小图标。

值得吗？值得。因为用户第一眼看到的，就是它。

二、不止图标：那些“不起眼的细节”，我们一个一个磨

图标只是一个缩影。翻开 Python Skill 的 CHANGELOG，这样的死磕随处可见：

• “代码写对了，一打包就崩”——宿主环境在暗中捣乱，换了几种写法都挡不住，最后才发现：是工具链被“劫持”了，必须入场前先把干扰摘干净；
• “删一个文件，居然也能失败”——办公环境的安全策略拦在半路，于是专门设计了“安全删除”：删不掉就挪进隔离区，绝不打断用户的正事；
• “一个中文项目名，就能让配置爆炸”——中文名、特殊字符，一路埋雷，一路填平；
• “这台电脑上打的包，换个环境就水土不服”——检测、重试、自动回退，把跨平台的沟沟坎坎一点点磨平。

还有：图标素材的统一收编（一张素材图，自动生成三平台的图标全家桶）、交付前的“验收门禁”……这些坑，没有一个是坐在书桌前能想出来的。

三、Skill 是“活”的：它不是写出来的，是长出来的

说到这里，我想分享一个越来越深的体会：

Skill 不是一个“写完就完事”的静态文档。它是动态的、有生命的。

你现在看到的每一版 Python Skill 里，藏着什么？藏着AI 写代码时犯过的错、踩过的坑，和踩完之后总结出来的经验。

我给你拆解一下这个“生长”的过程：

1. 一个真实需求来了——比如“把程序打包给朋友用”；
2. AI 去写代码——一路上犯各种错：图标失效了、字体乱码了、打包崩了；
3. 我们一条条排查、修复——有些坑挖了半天才见底；
4. 把根因和正确做法总结成文档——写进参考手册、写进蓝图、写进门禁；
5. 下一个用户再走到这里——坑已经被填上了，一路平坦。

这就是“活”的含义：每踩一个坑，Skill 就长大一点。

我的 CHANGELOG 为什么记得那么细？因为每一行都是“血泪”，都是真实项目里一锤一锤砸出来的。整个 Skill 仓库，一路提交了 167 次；单是 Python Skill 一个，版本号已经从 5.x 走到了 6.4.0——几十个版本，几乎每个版本都在填坑、打磨、加固。

而你拿到手的时候，看到的只是“好用的工具”——那些背后的坑，你都感觉不到了。

这，就是我想给你的东西：让前面的人摔过的跤，变成后面的人脚下的平地。

四、可是——光靠我一个人，这场进化走不远

铺垫了这么多，接下来是我今天真正想说的重点。

还记得上一篇文章吗？——《我做了个重大决定：把网友的作品，彻底“还”给你们》。那篇里，我把作品社区开放了：给作者搭台、开放微信号、让大家被更多人看见。

今天这一篇，是它的“续集”：作品要开放，Skill 的进化，也要开放。

为什么？说几句掏心窝子的实话：

第一，我面对的实际问题不多。

我只是一个人，用的场景有限，踩的坑也有限。我做的项目、我遇到的情况，远不如你们所有人加起来那么丰富。你们里的每一位——做财务的、做设计的、做管理的、写代码的——每天在真实工作里遇到的花样，是我一个人无法想象的。

第二，我也没有那么多精力去“挖掘”更细的问题。

把一个问题挖到底、总结成规范、写进文档、加上门禁——这活儿很重。我心里清楚：如果只靠我，很多细节永远等不到被发现的这一天。

第三，你们踩的每一个坑，都是候选的“Skill 营养”。

你这次踩的坑，如果你不说，就只有你一个人踩——你浪费了时间，它悄悄溜走。 但如果你把它交给 AI 总结、转给我、我把它写进 Skill——这个坑就变成了全社区的路标。

一个人踩坑 → 所有人避坑。这就是共建的意义。

所以我说：只有大家不断做出贡献、共同努力，才能把生态做得更好。 我的 Skill 质量提升，离不开你们的参与——这不是客套话，是机制上的事实。

五、怎么参与？门槛低到“不像在做贡献”

我知道很多人看到“贡献”两个字就头大：是不是要写文档？是不是要懂技术？

不用。我把门槛，也打到了地上。

你只需要做三个动作——而且全程不用动脑筋：

第一步：向 AI 提两个问题。

在你用 Skill 做完一个项目之后，打开 AI，直接问它：

“这个项目做下来，有哪些值得改进的地方？” “我用的这个 Skill，有哪些不足需要去修正？”

第二步：让 AI 帮你总结成文档。

AI 会把你们这次开发里踩过的坑、卡壳的地方、别扭的体验，整理成一份条理清楚的 Markdown 文档——哪一步出的问题、什么原因、怎么解决的，AI 替你写。

第三步：把文档转发给我。

完成。就这么简单。

提交两条这样的改进问题，就算一次正式贡献——而且，如果总结得有价值，还能升级成 2~5 个贡献点（重头戏在下一节）。

门槛有多低？——

• 不用你分析根因（AI 分析）；
• 不用你写文章（AI 总结）；
• 不用你懂技术细节（你只负责“提问”和“转发”这两个动作）；
• 甚至连“想”都不用你想——那两句提问模板，照抄就行。

你踩的坑 + AI 的总结 + 我的落地 = 下一个版本里，所有人的平地。

六、你的贡献，回报也是实打实的

可能有朋友要问：我贡献了，有什么好处？

一，对社区——你帮到了所有后来者。

你之后每一个走到这个坑边的人，都会因为你的贡献，少熬一个夜晚。这是最实在的“功德”。

二，对你自己——贡献值（而且比提交作品更值钱）。

提交改进问题、提交作品，都会登记到你的贡献值里。而这一次，我专门给“坑点经验”定了一条实在的规则：

• 你提交的坑点经验，我会亲自评估；
• 有价值的坑点总结，可以抵扣 2~5 个贡献点——相当于 2~5 个作品提交的贡献；
• 换句话说：质量范围内的贡献，最高可以抵扣 5 个作品。

为什么给这么高？因为我就是要鼓励大家多提交坑点总结——它比提交作品更容易操作（问 AI 两句、转发一下就行），得到的贡献值却更高。

这是我认真设计过的“双赢”：你省力，Skill 受益。

你的每一次“举手之劳”，都在为你自己攒“通行证”。

三，对 Skill 本身——它会因为你的名字变得更好。

说不准下一次更新日志里，就写着“感谢某某某反馈的场景”。这份参与感，比什么都珍贵。

写在最后

回到开头那枚图标。

它从“丢失”到“清晰”，用了四个版本、五个框架、一条门禁——看起来是一个人的偏执。但说实话，它从来不是一个人的作品：

• 反馈问题的用户，提供了第一个线索；
• 每一个真实项目踩出的坑，提供了素材；
• 而把这些坑变成标准的，是“有人愿意说 + 我愿意接”的合作。

工匠精神的极致，从来不是一个人的死磕——是一群人的共建。

上一篇，我把作品还给了作者； 这一篇，我想把“进化的权利”，也分享给你们。

你踩过的坑，别让它白踩。——交给 AI 总结，转给我，下一次更新，我们一起来写。

叫上身边的人，一起来把 AI 编程玩转。

想体验全套免费 Skill？欢迎加好友进入免费社群，关注公众号，后台回复「Skill」，不要理会AI自动回复，等我发联系方式，加好友进群自助获取。

公众号：Excel催化剂 | 微信：190262897 | 承接数据咨询解决方案、软件功能定制、AI编程培训服务等