怎么用两个周末手搓一个 Lightroom 平替

[hisea]

怎么用两个周末手搓一个 Lightroom 平替

AnyLUT 开发笔记

先说结果。

AnyLUT·光璐 已经上架 App Store 了。iPhone 和 iPad 都能用，能开 RAW，能套任何 .cube LUT，光线、颜色、HSL、曲线、质感、去雾、降噪、蒙版、裁剪这些该有的都有，照片全程不离开手机。

顺手还做了一个 Mac 版，叫 AnyLUT Studio，有图库、导入、筛选、批量调色、导出队列。

还有一个命令行工具 anylut，带 MCP server，AI agent 也能拿它修图。

仓库里 309 次提交，6 万行左右的 Swift 和 C++（含测试），18 份实现计划。第一次提交是 9 月 9 日，9 月 19 日做完上架准备。

花了多少钱？Claude Pro 加 ChatGPT Plus，一个月 50 加币。

这么多代码当然不是我一行一行敲出来的。

我带了一个 AI 草台班子

干什么	谁	交出来的东西
聊需求	ChatGPT	功能、定位、取舍
写 plan	ChatGPT	docs/plan/*.md
画界面	Claude Design	design/*.dc.html
写代码	Claude Code（主要用 Sonnet）	代码、测试、提交
审代码	ChatGPT	P0–P3 的问题清单
DevOps	GLM（在 omp 里跑）	官网、CI/CD、发布脚本
市场调研和营销	OpenClaw	docs/marketing/
拍板、看屏幕	我	决定

表格看着挺像回事，像是我带了个团队。

其实它们互相之间不说话。

它们之间传的是文件：plan 是 Markdown，设计稿是 HTML，规则写在 AGENTS.md 里，全放在仓库里。哪个 AI 换掉了，哪个上下文用完了，东西都还在。

为什么是一个 Monorepo

文件要在 AI 之间传，前提是都在一个地方。AnyLUT 所有东西都在一个仓库里：

core/            C++ 色彩引擎，没有平台相关代码
ios/             iPhone / iPad app，project.yml 定义所有 Xcode target
apple/           iOS、Mac、命令行共用的 Swift 包
                 （配方、渲染、设计 token、AI 助手、人像识别、统计）
apple/CLI/       命令行工具和 MCP server
studio/          Mac 版 AnyLUT Studio
luts/            内置 LUT
tools/           构建和发布脚本
docs/plan/       实现计划        
docs/cicd/       构建发布过程说明        
docs/marketing/  营销计划
design/          设计稿          
site/           官网
AGENTS.md        给所有 AI 的规则

好处比我想的大。

Claude Code 做一个界面，可以自己打开 design/ 里的设计稿对着做。写代码前可以先读 plan。改了统计上报，能顺手找到 site/privacy/ 把隐私政策也改了。它不用问我"那个文件在哪"，我也不用来回贴东西。

一份 C++ 引擎和一套 Swift 包，同时编进 iPhone、Mac 和命令行。改一次颜色算法，三个地方一起变，三套测试一起跑。

一个功能一个提交。"将效果存为 LUT"从 C++ 一路改到 iOS 界面、Studio 界面、中英文翻译和 plan 文档。后来把名字改短，iOS 和 Studio 也是一个提交改完。

一个事实只存一处。命令行工具给 agent 看的说明只写在一个文件里，代码里那份是脚本生成的，对不上测试就挂。AI 最爱干的事就是改了这边忘了那边，这样它想忘都忘不了。

代价也有。

最直接的一个：好几个 AI 在同一个工作区里干活。写这篇文章的时候，另一个 session 正在旁边改 Studio 的文件夹功能，工作区里一半的改动不是它的。

正经的做法是每个 agent 一个 git worktree，各干各的，互不打扰。

道理我都懂。但一个人开发，为了几个 AI 搞一套分支、合并的流程，有点杀鸡用牛刀。所以目前是将就着来：大家挤在一个工作区里，提交的时候各认各的文件。

这个取舍迟早要还。哪天两个 AI 同时改了同一个文件，大概就是换 worktree 的时候了。

还有依赖边界。在一个仓库里什么都够得着，所以更要写清楚谁不能碰谁。比如共享的 AnyLUTKit 不能 import UIKit，因为命令行也要编译它。

第一步：先想清楚不做什么

"Lightroom 平替"这个题目太大了，大到没法做。

跟 ChatGPT 来回聊了几轮，最后定下来的其实是几条"不"：

• 不锁相机品牌，不开滤镜商店。任何标准 .cube 都能用，LUT 是一等公民。
• 不要账号，不上云。RAW 解码、调色、导出都在本机。
• AI 不重画照片。AI 助手只帮你拖滑块，曝光、色温、HSL 这些，照片永远是你的照片。

第二步：用最强的模型写 plan

每个稍微大一点的功能都有一份 plan，色彩科学、曲线、去雾、降噪、蒙版、iPad、Studio、变现，加起来 18 份。

我觉得好的 plan 有三个特点。

写清楚不做什么，为什么不做。 "将效果存为 LUT"的 plan 专门有一节讲颗粒、蒙版、降噪为什么放不进 LUT。

写清楚唯一的实现在哪。 "曝光、对比度……不能有第二份实现"这一句话，比十页架构图管用。AI 找不到现成的函数，就会自己再写一个，这是它最常犯的错。

写清楚怎么算做完。 要测什么，测到什么程度。

但 plan 也会错。

所以写代码之前，我先让 Claude Code 拿 plan 去对照真代码，把 plan 里不对的地方写下来。这一步抓到过好几次错误的假设。LUT 那份 plan 里有一个地方，把整条颜色处理链都写成了在线性空间里做，实际上只有曝光一步是。要是照着错的 plan 做下去，算出来的 LUT 和编辑器里看到的就对不上。

第三步：Claude Design 画界面

plan 和功能清单交给 Claude Design，出来的是浏览器里直接能打开的设计稿。design/ 里现在有主界面 v1 到 v4、iPad 版、桌面版 v1 到 v3、Logo、官网、社交海报……

光看版本号就知道，没有一稿过的。

设计稿里的颜色、圆角、字号，后来整理成了设计 token，iOS 和 Mac 共用一份，所以两个 app 看起来是一家人。

第四步：Sonnet 写代码

设计稿和 plan 一起交给 Claude Code，主力是 Sonnet。

为什么是 Sonnet，这个我是试出来的。

不同家的中档模型我试了一圈。单看跑分，大家差不太多。真放到项目里，差别就出来了。

下面说的只是我在这个项目里、这几轮试下来的感受，不是什么评测结论：有明确 plan 的时候，Sonnet 最能打。它不抢戏，plan 里写的一步不落地做完，规矩守得住，测试会写也会跑，跑挂了自己回去修。有的模型更"聪明"，喜欢自己加戏：plan 没让它重构的地方它顺手重构了，没让它加的功能它贴心地加了。一个人开发，最怕的就是这种惊喜。

结果最扎实，价格又是中档。算下来，性价比最高的就是它。

当然前提是 plan 得写清楚。plan 含糊的时候，它也会跟着含糊。所以脑子要花在 plan 上，手交给 Sonnet。

让它稳定干活的，是仓库根目录那份 AGENTS.md。里面都是很短、很具体的规矩：

• 参数范围只能在 EditParameterRange 一个地方定义。
• sidecar 里的坏数据要报错，不能偷偷改成合法值。
• 不许碰我真实的照片目录，测试用临时文件夹。
• 改了共享代码，三个平台的测试都要跑。
• 我没说提交，不许提交。

基本上每一条后面都有一个坑。

但测试全绿，不代表东西是对的。

比如给顶栏加了一个"更多"按钮，单元测试一个没挂，结果在 390pt 宽的 iPhone 上，Save 按钮被挤出屏幕 21pt。又比如另一个 agent 接手做的菜单，测试全过，单独看也挺干净，放进 app 里就是不对劲，跟其他界面像是两家公司做的。

这两个问题都不是测试发现的。一个是靠 UI 测试读出控件坐标算出来的，一个是我看了一眼屏幕说出来的。

第五步：换一家的模型审代码

写代码的和审代码的，不能是同一个模型。

自己审自己，容易带着同一套盲点。git 历史里有一串 "review P1"、"review round 2" 的提交，都是 ChatGPT 审出来的，比如：

• .cube 解析太宽松，坏文件也能读进来（P0）。
• 去色差开得很大时，会越过中性点（P1）。
• 降噪在大图上内存扛不住（P1）。

降噪这条的处理是：先关掉。承认现在做不好，比硬上一个会崩的功能强。

两天后换了个架构重做了一版，又被审了 6 轮，git 里能看到 "review round 2" 一直排到 "review round 6"。每一轮都还能挑出问题，大多是解码和撤销之间的竞态。

审代码这件事，AI 比我有耐心多了。

第六步：GLM 做 DevOps

app 之外，还有一堆不做就上不了线的活：官网、打包、上架、发版。这部分交给了在 omp 里跑的 GLM。

• 官网：site/ 里的中英双语官网，加上上架前的 SEO（canonical、Open Graph、hreflang、sitemap），部署在 Cloudflare。
• CI/CD：Xcode Cloud 的脚本，TestFlight 打包上传脚本。
• 发布：命令行工具的 Homebrew 发布、Studio 打包、agent skill 包的同步。发布脚本默认只演练，加参数才真发。

每个脚本在 docs/cicd/ 里都有说明，连踩过的坑也写进去了。

今天上传 TestFlight 的时候，导出又失败了一次，错误和文档里记着的那次一模一样：profile 没放到脚本读的位置，Xcode 自作主张挑了一个旧证书的。照着文档改一下，第二次就传上去了。

第七步：OpenClaw 做营销

东西做出来，还得有人知道。

OpenClaw 做了市场调研，写了 docs/marketing/ 里的营销计划：小红书找中文摄影用户，X 上 build in public，Reddit 和 Hacker News 给开发者看，Product Hunt 只发一次。前 30 天先做什么、每周最多花几个小时、只看哪几个数，都写清楚了。

我觉得最有用的是它定的几条规矩：先讲照片，再讲产品；只放真实的前后对比；不买粉，不刷评论。

它跑在我自己的 Mac 上，能直接读本地的仓库。但它不写代码，也不参与讨论。在这个班子里，它是个旁观者。

旁观者有旁观者的好处。

它看到的是产品本来的样子，不是我嘴里的样子。 自己写营销，很容易越写越吹。它是从代码、plan、官网里自己读出来的，有什么说什么。所以营销计划里的素材，全是 app 里真有的东西：用 app 自带的 Social Poster 做前后对比图，拿 CLI 和 MCP 给开发者做演示。没有一样是"以后会有"的。

不用喂资料。 产品每天都在变。要是靠我把功能一条条贴给它，贴不了几天就过时了。它每次读的都是仓库里最新的样子。

离得远，看得清。 写代码的 AI 天天埋在细节里，我也是。它不在里面，反倒更容易看出哪个功能拿得出手、哪个只有我们自己在乎。

照片、代码都在本机，它只用一个 API key 出去调模型。对一个标榜"本地优先"的产品来说，营销也用本地部署，我觉得挺搭的。

算一笔账

Claude Pro 加 ChatGPT Plus，一个月 50 加币。

GLM 和 OpenClaw 也不在这笔账里。GLM 是之前赶上促销买的一年 coding plan，钱早就花了。OpenClaw 跑在我自己的 Mac 上，用的也是这个 GLM 的 key。这次只是把它们用起来。

这笔账是按天摊的订阅费：一个月 50 加币，10 天就是三分之一，大约 17 加币。Adobe 摄影计划在加拿大最便宜的一档是一个月 19.99 加币。

也就是说，做一个平替花的钱，还不够订一个月 Lightroom。

能这么省，关键就一条：好钢用在刀刃上。

plan 用最强的模型写。功能怎么取舍、架构怎么搭、唯一的实现放哪，这些一旦错了，后面所有代码跟着错。这里值得慢慢想。

代码交给 Sonnet。前面说过，plan 写清楚以后，写代码要的是扎实，不是聪明。额度也省得多。

反过来就是两头吃亏。全用最贵的模型写代码，额度几天就见底。用便宜的模型写 plan，省下的钱会在返工里加倍还回去。

那我自己干了什么

看到这里，可能会觉得我就是个派活的。

其实最花时间的活，是我自己干的。

定方向。 做什么产品、给谁用、怎么收钱，这些是写任何一份 plan 之前就得想好的。仓库里有一份《产品方向与平台策略》，几条大方向都是我定的：

• iPhone 负责"快速搞定一张照片"，iPad 跟 iPhone 是同一个 app、同一次购买，不因为屏幕大就多收钱。
• Mac 版单独做、单独卖，但前提是它真有桌面级的工作流：图库、批量、导出队列。只是把 iPad 版放大，就不配单独收费。
• 本地功能一次买断，只有真正持续产生成本的服务才考虑订阅。买断过的东西，以后不改成强制订阅。
• 命令行工具免费，它是给开发者和 AI agent 的入口，不是用来赚钱的。

这些 AI 都能帮我分析利弊，但选哪条路、以后不后悔，得我自己来。

磨 plan。 表格里写着 ChatGPT 写 plan，但那只是执笔。每一份 plan 都是我跟它一轮一轮聊出来的：先 brainstorm，写个初稿，我挑毛病，它改，再挑，再改。仓库里光是改 plan 的提交就有 39 个，这还不算聊天里来回的那些。

拿"将效果存为 LUT"来说。初稿出来以后，我拉着 AI 先把 plan 平复一遍、再 review 一遍，然后一条一条定细节：手机上算不算 Pro，Studio 要不要包含，要不要直接加进"我的 LUT"，重名了怎么办——最后定的是自动加 -1、-2 的后缀。这些都不是 AI 自己能拍的，也不是一轮就能想清楚的。

磨设计。 设计稿也是一样。design/ 里主界面从 v1 到 v4，桌面版从 v1 到 v3，每一版都是我看了、提了意见、再改出来的。

写这篇文章前后改的那个"更多"菜单就是个缩影：先用系统原生菜单，嫌它跟 app 不搭，换成自己画的；另一个 agent 改了一版，风格又跑偏了，再拉回来；加图标，调字号，最后连名字都从 "Create LUT from Current Look…" 改成了 "Save Look as LUT…"。一个菜单，改了六七轮。

拍板。 方向定了，每天还有一堆小决定：这个功能放不放进 Pro，这一版能不能上 TestFlight，用户说的"快捷键"到底要不要做。AI 能把选项列得清清楚楚，但它不用为结果负责。

看屏幕。 测试只能证明功能是对的，证明不了它好看。这次开发里最有用的几条反馈，都是我看了一眼屏幕说的一句话。比如"这个跟 app 其他地方不像"，比如"这两行字一样大么？"——还真不一样大，代码里都写的 15pt，长的那行被自动缩小了，AI 看了截图也没发现。

真的是 Lightroom 平替吗

说实话，不完全是。

没有云同步，没有镜头校正和暗角，也没有插件生态。

但我自己的日常就是导入 RAW、套个 LUT、拖几个滑块、导出分享。这个流程上，它已经够用了，而且更快、更安静，照片不用离开手机。

至少对我来说，这个取舍是成立的。

如果你也想这么干

1. 文件在 AI 之间传，别靠聊天记录。plan、设计稿、规则，全进仓库。
2. 写代码的和审代码的，用两家的模型。
3. 规则写短、写具体，写明唯一的位置。每踩一个坑，补一条。
4. 先拿代码检查 plan，每做完一个阶段记一笔。
5. 最强的模型写 plan，扎实的模型写代码。
6. 留一个不写代码的旁观者，让它直接读仓库，替你看清产品本来的样子。
7. 你自己的时间，花在拍板和看屏幕上。

写了这么多年代码，这次最大的感受是：AI 把"写"这件事变得很便宜了，但"想清楚要写什么"和"看出哪里不对"，还是得人来。

AnyLUT·光璐 已在 App Store 上架，iPhone 和 iPad 都能用，欢迎来试。anylut.com