云端杂谈

和 AI 一起折腾项目时，我发现最有价值的场景往往不是“帮我写完所有东西”，而是有人陪着把不清楚的问题一层层拆开。 但这也带来一个提醒：如果一开始的判断错了，后面的步骤可能越做越偏。最近排查博客同步时，我反而更希望先看源码、看本地配置、看 Git 实际输出，再决定应该改哪个地方。 所以我想养成一个习惯：所有重要结论尽量注明来自代码、日志还是推测；所有会覆盖文件的建议，先确认备份与回退方法。 > 我想要的是能检验的答案，而不是看起来很笃定的答案。

旧设备总有一种很奇怪的吸引力：参数明明已经过时，它却还在那里，像是在问“你确定我只能做到这些吗？” 一边是想重新用起来的 Android 4.2 车机，一边是偶尔让人抓狂的双路 X79。折腾它们未必省时间，也未必省钱。可是在翻文档、看日志、排除假设的过程里，我又确实学到了不少东西。 我现在更愿意给这些项目写一份“实验日志”，而不是只在成功时晒结果。失败和偶然恢复，也都有记录价值。 > 设备会旧，方法可以越来越新。

做车机专用 APK 的时候，我很容易被一个念头诱惑：先把界面画出来，看起来就像“有进度”了。 但真正的接收端首先要证明自己能在 Android 4.2 上安装、启动、得到必要的权限，再逐层验证 iPhone 与车机之间的通信能力。 因此下一次我想优先拿到三个事实：设备架构、可用的通信链路，以及最小安装包的实机日志。外观可以晚一点优化，兼容性不行的话再漂亮的页面也只是一张壳。 > 先让连接真实发生，再让体验好看。

聊到《明日方舟》的卫戍协议时，我突然觉得：与其继续用长段文字描述回合和资源，不如做一块可以看到状态变化的战术沙盘。 有行动档案、资金、防线和回合计数的概念演示很适合验证交互结构。不过它仍然是概念，不是完整复刻。之后若继续做下去，应该先确认规则和数值的对应关系。 把抽象机制变成可观察状态，这一步本身就很有意思。

最近重做 CiRCLE Garage 的时候，我越来越觉得，界面不是“把功能排得漂亮”就够了。 车辆卡片比密密麻麻的文字友好，但更重要的是：用户改完一辆车之后，能否知道这次会影响哪些槽位？发布前能不能看差异？出错能不能回滚？ 同样的思路其实也适用于博客后台。一个同步按钮，如果不能清楚说明将要覆盖哪些文件，就应该先补上安全检查，而不是再给它加一圈发光动画。 > 好看负责吸引人，可信赖才负责让人留下来。