方法论与洞察

桌面应用打磨发布闭环复盘 · 工位池塘 Desk Pond v0.5.0

入档:2026-06-26 来源:把 Godot 桌面小工具《工位池塘》从 v0.4.0 打磨成「可叫做完了」的 v0.5.0,并发布到自有站 tiaozhuxiansheng.com + 产出小红书图文,单次会话内闭环 性质:一次「打磨→发布→引流」的工程闭环复盘;含发布架构、验证盲区、审美交付流程三类可复用经验

事实记录(不可修改区)

已验证 vs 未验证(关键诚实区,可作交付模板)

状态手段
部署成功✅ 已验证CI 三 job success
下载链接可用且为最新包✅ 已验证curl HTTP 200,Content-Length == 本地构建字节,多次一致
exe 能启动不崩溃✅ 已验证启动进程存活、窗口标题正确
页面居中/无横向溢出✅ 已验证预览 DOM 实测 getBoundingClientRect / scrollWidth
应用内图标/UI 的实际观感⚠️ 未亲自核验computer-use 遮蔽未授权的绿色 exe 窗口,截不到;靠离线 PNG 预览 + 用户肉眼终验
滚动联动水波的触发⚠️ 未端到端验证headless 预览不派发滚动事件、rAF 不推进;只验证了 spawn 机制 + WAAPI 在跑
音效实际听感⚠️ 未核验headless 用 dummy 音频驱动,只验证资源加载无报错

这张表是本次最该带走的协作习惯:交付前显式区分「已自动验证」与「需人眼终验」,并把后者主动告诉用户,而不是默认它没问题。

做了什么(简述)

结果分析(预期 vs 实际,不混淆)

成功的是工程交付(能发、能下、字节一致),不是「作品获得市场认可」——发布当天零传播数据,任何「作品很好」的结论此刻都不成立。计划外的 UI 来回(图标返工一次、居中误诊一次)消耗明显大于「打磨」本身,是下次要压缩的成本。

可复用经验(教训)

1. 审美类交付:先出真实尺寸预览,再发 ⚠️

图标/配色这类审美强相关的东西,发布前先出一张真实显示尺寸的离线 mockup 给用户看,别直接发。本次第一版单色像素图标没给预览直接发,被「有点丑」打回;emoji 版先做了顶栏真实尺寸模拟图再发,一次过。注意 mockup 要按真实尺寸,不是放大 N 倍的失真预览(放大会把抗锯齿边缘显得很糙,误判)。 纯功能/字节级产物不需要,自动校验即可。

2. 布局争议:量「盒子」,别量「像素行」 ⚠️

判断「是否居中/溢出」要读 DOM 的 getBoundingClientRect/scrollWidth,不要用截图某一行的深色像素边界去猜。本次误判「内容左偏 412px」——那是单行只截到部分字形的假象;DOM 实测显示容器本就居中,真正原因是内容左对齐而非容器偏移。一句话:布局问题先起静态服务器 + 预览 eval 读真实盒模型再下结论。

3. 观感/触发类功能在预览与无头环境无法自动验证 ⚠️⭐⭐⭐

滚动水波(滚动事件+rAF)、应用内图标观感,在 headless/预览里都验不了——这是工具环境的硬边界,详见 Claude预览环境不派发滚动事件_滚动类功能无法行为验证_v1(本次是该律的又一次验证,并新增「computer-use 遮蔽绿色 exe 窗口」这一桌面侧盲区)。

下次改进

  1. 审美元素默认走「先出真实尺寸 mockup → 用户点头 → 才发」,固化进流程。
  2. 每次桌面应用/动效交付,附「已验证 / 需你终验」小表(本文上方那张即模板)。
  3. 布局争议直接上 DOM 实测,省一轮误诊。

一句话提炼

一次干净的工程闭环;最大可复用资产是 CI从Release抓二进制托管自有服务器_桌面应用国内直连下载_v1 的发布架构,最大教训是「观感类交付要先出真实尺寸预览、并显式标注人眼终验盲区」。传播数据未出,当前不下「作品成功」结论。

关联文档

类型/协作工具链