蛛网之上 Above the Web
GitHub ↗

发布于 更新于 约 5 分钟读完 · 1,794 字

本文目录 11 节
  1. 事实记录(不可修改区)
  2. 已验证 vs 未验证(关键诚实区,可作交付模板)
  3. 做了什么(简述)
  4. 结果分析(预期 vs 实际,不混淆)
  5. 可复用经验(教训)
  6. 1. 审美类交付:先出真实尺寸预览,再发 ⚠️
  7. 2. 布局争议:量「盒子」,别量「像素行」 ⚠️
  8. 3. 观感/触发类功能在预览与无头环境无法自动验证 ⚠️⭐⭐⭐
  9. 下次改进
  10. 一句话提炼
  11. 关联文档

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

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

事实记录(不可修改区)

  • 预期目标:① v0.4.0 打磨成完整作品(补声音/图标/首次体验);② 发布到自有主页(展示页+下载);③ 小红书图文。
  • 最终结果:三项均达成并线上验证通过。追加计划外工作:弃用夸克网盘改香港服务器直连下载;主页与应用顶栏多轮 UI 迭代。
  • 数据来源:全部为自测/CI 验证(部署 success、curl HTTP 200 + Content-Length 与构建字节逐字节一致、headless 解析无报错、exe 冒烟启动)。发布当天,无任何传播/下载量数据——本复盘不含传播效果结论。

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

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

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

做了什么(简述)

  • 打磨:numpy 合成的环境水声循环+事件音效(autoload 单例+静音持久化)、PIL 像素应用图标、首启自动弹一次玩法说明;升 v0.5.0,Godot headless 导出。
  • 发布:自有 Astro 站加 /desk-pond/ 展示页 + 数据驱动的「可玩」卡片;CI 自动部署到香港服务器。
  • 下载架构:弃用夸克网盘,改为 CI 从 Release 抓 exe 托管到香港服务器做国内直连下载 → 见 CI从Release抓二进制托管自有服务器_桌面应用国内直连下载_v1。
  • 多轮 UI 修正(用户逐条反馈驱动):默认亮色+主题切换、修正作者名、截图融入背景、hero 与正文居中、背景水纹从静态→缓慢扩散→滚动联动;顶栏图标 文字→单色像素→(嫌丑)→emoji 风格彩色图标。

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

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

可复用经验(教训)

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

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

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

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

  • 再验(2026-10-06,v0.6.2,Godot 形态):Godot 无头模式照样能量控件盒子(get_combined_minimum_size() / get_global_rect())。issue #1「水族馆里按钮显示不全」靠两个数字定案:v0.5.0 上整列 676 宽、HEAD 上 644 宽,窗口 640;全程没看一张截图。见 2026-10-06_工位池塘v0.6.2_老issue分诊到三端发版_复盘_v1。

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

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

下次改进

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

一句话提炼

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

关联文档

类型/协作工具链