夜雨聆风不是"Claude 帮我写了个 App",而是一份很诚实的分工账:人干了什么,AI 干了什么,哪里翻了车。
✿ ✿ ✿
先看这组数字
18 天。第一次 commit 是 2026 年 3 月 28 日,App Store 上架是 4 月 15 日。现在版本号到了 v1.3,365 个单元测试,全过,一个没挂。
做的是个棒球记分 App,叫 BaseballScorer,主打 iPad,顺带管 iPhone。作者是谁不重要,重要的是——这是他第一次写 Swift。
我之所以盯上这篇 build log,是因为它没有那种"我躺着 AI 把活全干了"的味儿。相反,作者花了很大篇幅讲一件事:这 App 到底是谁做的。
他自己给了答案,我觉得特别准:
"这不是'Claude 做的',也不是'我做的、Claude 当个高级自动补全'。这是一次真实的分工。"
更扎心的是后面那句。他说这个棒球记分的点子 2009 年就有过,那一版黄了——因为对一个兼职爱好者来说,做一个真正能上架的 iOS App,就是场噩梦。2026 这一版能上线,是因为 Claude Code 把"做出我心里那版 App"从幻想,变成了一个能干的活儿。
开篇:2009 失败 vs 2026 上架的对照,18 天/365 测试/0 失败
✿ ✿ ✿
谁干了什么,得掰开说
先说人这边带来了什么。
作者定了整个 App 的设计哲学,一句话:"the app trusts you"——这 App 信任你。每个字段都可选,一个没记完的打席,绝不挡着你往下走。打过棒球记分的人懂,真实的看台上,你经常漏记、错记、回头补。一个动不动就报"必填项为空"的 App,记到第三局你就想砸手机。
还有那些只有内行才纠结的细节,也是人定的。比如 K 和 Kc 的区别——挥棒落空的三振,和愣在那儿被判的看着三振,得分开记。再比如 iPad 优先而不是 iPhone 优先的定位。这些 Claude 自己想不出来,它不懂棒球,也不知道你站在哪个看台。
那 Claude 干了啥?
它补上了作者完全不会的那部分。SwiftUI 的惯用写法——人生第一次写 Swift,这玩意儿太顶用了。还有球、好球、界外、触身球那一套颜色编码,以及在"投球结果"和"击球进场结果"之间来回切换的那个翻面逻辑。数据模型也是 Claude 帮着捋顺的:Game → Inning → AtBat → PlayEvent,一层套一层。
你看出来没?这不是替代,是补位。作者补不上 SwiftUI,Claude 补不上"棒球应该怎么记"。两边各拿各的。
人与 Claude 的分工:设计哲学/领域知识 vs SwiftUI 惯用法/数据模型
✿ ✿ ✿
真正救命的,是那些"无聊"的东西
这部分我得划重点。
很多人以为 vibe coding 的关键是 prompt 写得多花,其实不是。让这个项目 18 天能跑完、还能留下 365 个测试的,是几条听上去特别无聊的纪律。
第一条,自定义 skill 只留了 5 个。bug-fix、release、commit、testflight-upload、security-review。作者特意强调:keep custom skills minimal——别贪多。每一个 skill,都对应一个真实存在、而且步骤烦人的多步流程。release 这个就直接接了 fastlane,一键打包送 TestFlight。不疼的地方,不要硬塞 skill。
第二条,修 bug 之前,先写一个会失败的测试。这是他给自己定的死规矩。先让 bug 在测试里复现出来,红的,然后再去修到绿。365 个测试就是这么一个一个攒出来的,不是最后补的。
第三条更细,也最容易被忽略:从出 bug 那个构建的 tag 切分支,而不是从 main 切。
这条我第一眼没反应过来,想了一下后背有点凉。假设 v1.2-b23 这个构建里混进了一个 bug。你要修它,如果直接从最新的 main 拉分支,那你的"复现测试"复现的根本不是当初那个版本的 bug——main 早就变了。从那个出问题的 tag 切,才能保证你测的就是当时那个东西,修完再干净地 cherry-pick 回 main。
作者还说了句挺好玩的:他以为这是常识,后来才被告知"其实没多少人这么干"。
哦对,还有个小动作我很喜欢——App Store 的元数据(标题、描述那些)他放在仓库里,docs/app-store-metadata.md,而不是丢在 App Store Connect 后台。理由也简单:放仓库里,它就跟代码一起被版本管理,改了有记录,谁动的、什么时候动的,都查得到。
5 个自定义 skill + 三条纪律:先写失败测试 / 从 tag 切分支 / 元数据进仓库
✿ ✿ ✿
翻车现场,只有一张截图
讲点不那么顺的。这才是实战。
某天,一个 TestFlight 测试者发来一张截图。截图里,看起来是四个互不相干的 bug。
作者去查根因,结果发现:这四个 bug,根子是同一个结构性问题。
问题出在哪?他的 App 有两条往里写数据的路径——一条是你手动记分,另一条是从 MLB 的赛事 feed 里补录已经打完的比赛。这两条路径,几乎不共享任何代码。各写各的。所以同一个底层数据状态,在两条路上各错各的,表面上就长出了四个看着不一样的 bug。
这里有意思的地方来了。
作者早就写好了一份 docs/architecture-retrospective.md——一份"架构复盘文档"。注意,是早就写好,放在那儿等着的。里面写明了:出现什么样的信号,就该停下来认真重构,而不是再打一个补丁糊过去。
那张测试者的截图,正好命中了他写在文档里的触发条件。
他原话是这么说的:
"在你需要它之前,就把复盘文档写好……带上明确的触发条件,定义清楚什么时候'直觉'该变成'动手'。"
我盯着这句看了挺久。说实话,大部分人(包括我)写技术债注释,都是 // TODO: 这里以后要重构,然后那个以后永远不来。他不一样——他提前把"什么时候必须动手"这件事,变成了一条写死的、可触发的规则。等信号一到,不用纠结、不用跟自己谈判,直接动。
翻车:一张 TestFlight 截图,4 个表面 bug,1 个根因;命中预写的 retrospective 触发条件
✿ ✿ ✿
最大的遗憾,他自己说了
那两条不共享代码的路径,就是这个项目最大的架构债。作者也没藏着。
他说,如果重来一次,他会先建一个 typed event log(带类型的事件日志),然后强制两条路径——不管是手动记分还是 feed 补录——都只能产出"事件",再把所有事件喂给同一个 applier(应用器)去改状态。
翻译成人话:别让两条路各自直接去改数据。让它们都老老实实生成一串事件,真正动数据的活儿,交给唯一一个地方去干。这样不管数据从哪条路进来,最后都走同一个收口,bug 自然就没法在两边各长一个。
这事儿给我的提醒是:AI 写代码快,不等于它会帮你想架构。Claude 能飞快地把两条路径都给你实现得漂漂亮亮、各自都能跑,但"这两条路本来应该收口到一处"——这种判断,得人来下,而且最好在第一行代码之前就下。
扯远了。回到主题。
✿ ✿ ✿
你能直接抄的几条
我把这篇 build log,以及最近同期几个实战的共识,凑成一份能直接上手的清单。顺手说一句,这些结论不是这一个人的孤证:
有人(Venkat Peri)用 26 个日历天、97 个活跃小时、烧掉 9.9B token 做完一个项目,打法是固定的——一次只开一个对话,Opus 高思考档,跑起来就盯着。还有人(Lakshmi)一个周末干出个 SaaS,核心动作是让 Claude 反过来采访自己,把需求一条条问到没有灰色地带为止。重复出现的就那么三样:写下来的 CLAUDE.md、精确到"动哪儿不动哪儿"的任务简报、用一个全新的 AI 去做 audit。
落到你手上,我建议这几条:
先写 spec,让 AI 采访你。 你要是答不上它的问题,说明你自己也没想清楚——那就别急着让它写。
一次只盯一个任务。 别一口气派一堆活,context 一糊,它就开始胡说。
bug fix 先写失败的测试。 这是把"试错"变可控的最便宜的办法。
把复盘文档提前写好,带触发条件。 别等债爆了才想起来。
那什么时候别这么干?
如果你连"做完是什么样"都说不清,先别开 prompt。还有,涉及钱、涉及多条数据路径交汇的核心逻辑,该自己慢慢写就慢慢写——这位作者最大的坑,恰好就在两条路径的交汇处。AI 给你提速的地方,往往也是它埋雷的地方。
写到这儿我自己都有点感慨。18 天、一个新手、一个能上架的 App——这事儿放三年前真不敢想。但真正让它成的,不是模型多聪明,是那几条无聊到你想跳过的纪律。
你呢?手里有没有一个搁置了好几年、一直说"等有空"的小工具?也许它缺的不是时间,是一份写清楚的 spec,和一个肯陪你把它问明白的搭子。
