Command Palette
Search for a command to run...
Comments
Join the discussionNo comments yet. Be the first to comment.
独立开发
Part 1 of 1
Search for a command to run...
No comments yet. Be the first to comment.
我用 Swift + SwiftUI 写了一个 iPad 智能家居中控 App，核心解决一个问题：比旋钮和语音更方便地控制灯光。这是一套完全基于个人需求、非常"自我"的实现，文章记录了从灵感诞生到踩坑落地的全过程。
早在装修新家之前，我就盯上了 iPad 上墙这个「行为艺术」。
市面上的解决方案大多搭配小米平板控制米家设备。但作为多年果粉，我对 HomeKit 和 Matter 的大一统有种莫名的迷信，于是装修时选择了 Aqara 全屋 + Matter 单品 的方案——这也意味着我的上墙方案只能用 iPad。
我在客餐厅边上的墙体留了一处 86 底盒，从旁边的智能开关并联取电，给磁吸墙充供电，加上魔改磁吸壳，把一台闲置的 iPad Pro 改成了磁吸充电的形式。
装修入住后，一套「手扶拖拉机」般的方案诞生了：
但很快发现问题：绝大多数智能家居控制通过语音或自动化完成，真正需要靠近 iPad 操作的情况，用隔壁面板直接点按反而更方便。
如果需要整体调节客餐厅亮度，语音没那么方便，我会用 Aqara 旋钮 V1 加上预设好的灯组直接转动——但这个旋钮也有局限，比如进度 100% 时顺时针转没法改变灯光状态，需要先点按开灯再旋转（此处 @Aqara）。
入住半年后，转机出现——Vibe Coding 火了。
看着大量非专业开发者用 AI 把想法变成现实，我心里痒痒的。作为多年全栈开发，虽然没什么原生 iOS 经验，但抱着对 Swift 的憧憬，我敲下了第一行 Prompt。
开门见山，这个 App 就做三件事：
这款 App 是完全基于自身需求出发、非常「自我」的一套实现，希望能吸引到有相同需求、相同脑回路的智能家居玩家。
很多人问：你跨平台经验那么丰富，为什么不用 RN？
答案很简单：HomeKit 仅支持 iOS，而且 HomeKit 相关的开源库年久失修。与其在跨平台框架里折腾原生桥接，不如直接上手 Swift。
最终选择 Swift + SwiftUI：
AI 工具方面没有特别偏好：Cursor → Claude Code → Gemini，甚至 CodeX 和 OpenCode 都用过。
AI 大模型训练素材主要是开源大户，Swift 作为苹果闭源语言，知识储备明显不足。
典型例子：AI 不清楚我用的是 Swift 6 和 iOS 26，经常引用 deprecated 接口。最搞笑的是 Gemini 3 刚接入时，坚称我代码里的 iOS 26 是 typo，要给我改成 17。
解决：在 agent 文档里写清楚版本约束，配合 Context7 这类 MCP 查询最新文档。
滑动调节房间亮度时，总有一组灯带不受控制。让 AI 单独 debug，它很容易把自己绕进去。
后来深入了解协议才知道：设备下面还分「服务」，对应物理设备上的「回路」。最早只把指令发到灯带上，实际只控制了每个驱动的第一个回路。应该下发到服务上才能实现预期效果。
感悟：把原因描述清楚后，AI 很快就能修复问题。人类的领域知识仍然关键。
这部分大概率受限于我的表达能力，AI 产出的结果总不能令我满意，微调起来也很麻烦，半人工半自动改了很久。
另外，最初本着 MVP 原则对数据结构做了很多简化，导致 Xcode 里的 Canvas 预览工具没能充分利用——几乎所有组件都直接依赖 HomeKit SDK，很难 mock。最后专门分了精力做依赖封装和抽象，才让关键组件的预览可以 mock 家庭实例。
对于之前 JS 经验为主的我来说十分陌生（上学学的早就生疏了），这里只能劝自己相信 AI，至少目前为止还没出严重问题。
受很多大佬启发，原型是通过传感器触发点亮屏幕，在 App 里变成了直接监听指定传感器状态，除了传感器外没有其他第三方依赖。
结合「人来亮屏」，只需抬手一划就能将空间内的灯开到想要的亮度，比旋钮更直观。
不同于传统的「暗黑模式跟随系统」，App 里有一个「自适应」选项，根据当前房间背景图片的「明度」自动选择明暗外观，确保文字可读性。
虽然希望一次操作控制所有灯，但难免有例外。用户可以在房间设置里取消勾选对应设备，或在制冷、制热季节分别勾选空调、地暖设备。
另外，针对卫生间、储藏间等琐碎空间，用户也可以选择隐藏。我自己就只在 App 里显示客餐厅、阳台、走廊这样的公区可调光空间。
App 最初叫「WallFlow」，是起项目时 AI 自己取的，主要因为早期 Prompt 过度强调了「上墙」属性。
经过多番深入交流，定了一个更贴切的名字 「Hearth」（壁炉）。考虑到中式家庭和很多现代家庭不再配置壁炉，就算有也是假的，希望这个 App 能像最早的壁炉一样给家庭带来温暖和便利。
中文名还没想好。
最早用的 AI 编辑器，tab tab 的体验记忆犹新。后来出了 Agent 模式也用了一段时间。自动模式下处理文档还可以，实际上手开发时需要手动指定 Claude Sonnet 才有理想效果，去年订阅到期后没再续了。
一开始用 CC 加 Kimi-k2，后来发现 token 烧得挺快，转而订阅。目前用下来是当之无愧的王者，Claude 一直在引领 AI 编程的方向。
最大的问题是用量——5 小时限制卡得死死的，到了就得歇，要不就继续氪金，每周也有上限。开多个项目基本不够用，得开 5x。
早期跟风用来做 Code Review，确实发现了不少问题。后来更新后需要重新配置 API，懒得折腾，没再用了。
后起之秀，最近刚开了一年 Gemini Pro。目前体验非常好，但不太稳定，有时会陷入循环或报错。
好处是用量很慷慨，按天设上限，用完了还能回退到 Gemini 2.5 flash。此处继续吐槽 Claude Code 五小时上限简直反人类，经常激情编程时戛然而止。
除了 AI 工具外，也用了一些其他工具确保产出可控，首当其冲的是 SpecKit。通过「宪章」确定项目基础（编程风格、技术选型等），减少 Code Smell。其次将每个功能模块以 Spec 形式定义，从需求描述到任务划分、验收标准，框死开发内容。
实际开发大型模块时有一定帮助，小改动反而浪费。目前被 Claude Code 的 plan 模式取代——先用 Opus 指定计划，再交给 Gemini 实现，是我现在比较接受的模式。
从第一次接触 GitHub Copilot 和 Cursor，到现在 Agent 模式为主，AI 编程已经发生巨大变化。相信再过几个月，我的工作模式又会大相径庭，就像现在的 Vibe Coding 之于之前的 Tab Tab。
这个项目还有大量手动干预，一方面是在熟悉 Vibe Coding 流程，另一方面也是想借此机会上手憧憬已久的 Swift。基于这个体验，后续可能还是会走向更激进的 AI 编程之路。