title: 让 Claude 写完一个 Mac 应用的全部代码:首个可用版只用了约 8 小时
category: 编程搭建
score: 81
status: 已实现(作者自述,commit 与 TestFlight 构建真实)
source_author: Andy Bennett(Medium 署名)
source_url: https://medium.com/@akbsteam/claude-wrote-all-the-code-the-time-went-somewhere-else-003a468e323d
source_date: 2026-10-19
tools: [Claude(代码与设计), TestFlight, Todoist, 自研 Claude skill(拉取商店反馈)]
cost: Claude 订阅成本(作者未公布具体档位与 token 账单)
time_needed: 读者照搬该 loop 到自己项目约 1 天学会;完整产品仍需数周
---
速览卡
- 分类:编程搭建
- 结果:原生 Mac/iPhone/iPad 求职应用 Helm,9 月 11 日首 commit → 10 月 18 日 641 次提交 / 21 个计划,Mac build 40、iOS build 34 上 TestFlight;首个可用 Mac 版约 8 小时 commits(已实现,作者自述)
- 状态:已实现(作者自述,未经审计;commit/TestFlight 构建为真实记录)
- 成本:Claude 订阅(具体金额未给出)
- 耗时:首个可用版约 8 小时 commits;完整 beta 约 5 周
一句话
一位有 iOS 背景的开发者让 Claude 写了一个原生三端应用的全部代码——代码 8 小时就写完了,但他发现真正的耗时搬家了:从“写代码”搬到了“证明值得用”。
原作者怎么做的
- 先拿 Web 版探路:用 Next.js 花一周、73 个 commit 做出可用的数据语料与产品形状,确认方向后再转原生(转原生的动因:CloudKit 同步 + 一次性买断制更适合求职者)。
- Loop:定需求→写规格→plan→拆成任务→逐个任务构建→每个任务独立评审。OpenRouter 引擎一处就拆出 13 个计划任务,若干走了 1–2 轮修复。
- 全分支评审:每个评审者只看一个切片,但有些 bug 只活在接缝处——一次全分支评审抓到任务评审全漏掉的致命问题:余额请求在用户同意前就发出去了。
- 真机与 Release 双轨:测试抓不到的问题清单——CloudKit 三个 session 连不上(binary 没链 CloudKit.framework)、首个 TestFlight 包只在 Release 崩(#Predicate trap)、iOS 同步只在 app 打开时工作(Xcode 静默丢了 entitlement)。作者的结论:“出问题的信息不在代码里,模型再强也推理不出来”,只能靠真机与 Release 实测。
- 反馈闭环做成 Claude skill:TestFlight 的“分享 Beta 反馈”(截图+语音转文字备注)被 skill 自动拉进 Todoist(带附件),按 rubric 打 p1–p4 并写理由,作者可推翻;排好序的清单直接喂给下一个 build 计划。实例:iPad build 25 的 5 张截图变成 5 个任务;iPhone 上“粘贴简历后键盘关不掉”的真 bug 当晚合并修复。
- 结论诚实:软件生命周期被同时向左(研究/立项/规格要想得更多)向右(测试与发布变成开发的输入)挤压;“证明能跑的成本崩塌了,证明值得用的成本还在以人的速度跑”。
结果
- 交付:641 次提交 / 21 个计划,Mac build 40、iOS build 34,均上 TestFlight 内测(已实现,作者自述)
- 速度:首个可用 Mac 版约 8 小时 commits(已实现,作者自述;作者强调 working ≠ shippable,沙盒/同步/正式包都在之后)
- 方法:任务独立评审 + 全分支评审 + 反馈→Todoist→排期 skill,三件套真实跑通(已实现,作者自述)
- 诚实声明:beta 反馈样本目前只有作者自己加 1 个外部用户,“毛边冒得快”但样本小
提示词结构
(按原文 loop 还原的任务下达结构,非原文逐字提示词)
```
阶段 0(探路):先用最快的技术栈(一周)做出真实数据语料与可演示形状,确认方向再转正式栈。
Loop(每个功能):
1. 定需求 → 写规格 → 生成 plan → 拆成独立任务
2. 逐任务构建 + 每个任务独立评审(修 1–2 轮正常)
3. 全分支评审:专找“只活在接缝处”的 bug(权限/计费/跨模块状态)
4. 真机 + Release 双轨验证:测试与 Debug 跑不出来的问题( entitlement、Release 特有崩溃、后台同步)必须真机走一遍
5. 反馈 skill:把[用户反馈渠道]的截图/文字/崩溃自动拉进[任务系统],按[分级 rubric]打优先级并写理由,人可推翻;排好序直接喂给下个 build 计划
铁律:信息不在代码里的问题,别指望模型推理出来——留出真机时间。
```
中国读者怎么迁移
Helm 是求职应用,loop 本体与赛道无关:独立开发者的 App/小程序/插件都能套。TestFlight 换成 TestFlight(iOS)/ 内部测试渠道(安卓)/ 灰度发布;Todoist 换成飞书/钉钉任务或 Notion;“反馈→任务→排期” skill 用任何 agent 框架(Claude Code、Codex)都能写,核心是 rubric 分级 + 人可推翻。先拿一个小功能跑通 loop 再铺全量。
风险与限制
- 作者有 iOS 开发背景(自述多年没深耕 SwiftUI Mac 但平台熟),“8 小时”是 commits 口径且建立在“知道要做什么”之上——纯新手不要把 8 小时当成自己的预期。
- Claude 订阅与 token 成本未公布;641 次提交的真实花费未知,预算闸门自己设。
- 结论里的“时间去哪了”建立在小样本上:beta 反馈只有作者 + 1 个外部用户,“值得用”阶段的耗时规律还没被验证。
- 文末 waitlist(helm.kaiyou.digital)是作者自家应用的内测招募——内容本身是真实构建记录,阅读时知晓即可。
- 与已发布/待审批案例无重复:2026-10-19-03 常驻智能体失败账本是“自动化活了多久”,本篇是“代码已不是瓶颈后的 loop 方法论”;与 2026-10-18-07 Issue→PR 不同赛道。