← 回到建造日记
工具链

🛠 v1 怎么搭出来的 —— 不写代码的人，用 AI 工具做一个 iOS app

立项第二天就开干。我已经很多年不写代码了，把 Claude 当 PM、把 Codex 当主力工程师、Claude Code 跑短任务，一天就跑通了第一版。但我自己测试时就发现：豆包的 ASR/TTS 好用，它的 LLM 却完全不适合做"给孩子的英语陪练"—— 回复全是成年人对话，连我自己都听不懂。我直接否决了 v1，跟 Claude 一起查问题,最后决定换架构。

立项第二天我就开始动手。

但我立刻撞到第一个问题：我已经很多年不写代码了。立项时的兴奋一过，剩下的就是一个 8 岁孩子 + 一份产品想法 + 一台 Mac + 一份完全空白的 Xcode。

这一篇讲的就是：一个不写代码的人，怎么用 AI 工具把 v1 搭出来的。

我的工作配置

工具栈很朴素：

  • Claude（chat） —— 产品经理 + 技术顾问。所有”该怎么办”的问题都问它
  • Codex —— 实际敲代码的 agent。我把任务书丢给它，它产出 Swift 并顺手编译验证
  • Xcode + 真机 iPhone —— 跑 build、上真机调试

为什么是 Codex 写大段代码、Claude Code 跑短任务、Claude 当 PM

实际分工是这样的：

  • Claude（chat） —— 产品决策、架构判断、写工程任务书
  • Claude Code —— 短交互任务：Xcode 配置怎么设、Info.plist 怎么填、build 报错怎么解。直接在终端里问、得到具体步骤
  • Codex —— 大段代码产出：写整个 CappyEngine 模块、写 prompt composer 体系。给一份任务书，它一气呵成实现 + 顺手编译验证

为什么不全用 Claude Code 来写代码？两个原因：

  • 听别人说 Codex 的编程能力不错，想试试
  • 我用 Claude Code 跑过长任务，感觉 token 消耗很快，长任务有点心疼
  • 两个 AI 我都订阅了 —— 不如各自做擅长的事

这个分工后来证明是对的：Claude 输出的”工程任务书”对 Codex 非常友好（结构化、有明确 DOD、有代码骨架），Codex 拿到之后基本能一气呵成实现。短的环境配置 Q&A 留给 Claude Code 在终端里手把手教我，不浪费 token。

工作流

我有问题 → 跟 Claude 讨论 + 让它输出”工程任务书”（一份对编程 agent 友好的需求文档）→ 把任务书丢给 Codex → 它产出代码并编译验证 → 我打开 Xcode 真机跑 → 出问题截图给 Claude → 进入下一轮

我自己只做三件事：拍板产品决策、按 Xcode 的 ▶ 按钮、看真机日志后描述给 AI。代码不是我的活。

第一个问题：用什么实时语音方案？

我跟 Claude 列了硬约束：

  1. 真·实时语音对话 —— 不要”语音输入 → 文字回复 → 朗读”那种伪实时，要像跟人讲电话一样
  2. 国内能用 —— 我在国内，OpenAI Realtime 系列没有稳定方案
  3. 有现成的 iOS SDK —— 我不能从底层往上调
  4. 便宜 —— 自用产品，烧不起钱

Claude 当时给了几个候选：

方案优势劣势
豆包 Realtime（火山引擎）文档全、iOS SDK 现成、国内访问稳、按字符计费便宜字节出品，定制空间相对小
Minimax 实时语音国内厂商，质量也不错当时还没有官方 iOS SDK，集成成本高
阿里云 / 腾讯云类似产品大厂稳实时双向语音的成熟方案当时没找到
OpenAI Realtime质量第一档国内访问 / 合规 / 价格都不行

我选了豆包 Realtime。 排第一的原因不是音质，是 iOS SDK 现成。

对一个不写代码的人来说，最怕的就是”得自己从底层调”。谁能让我跳过最多的工程细节，谁就赢。

至于豆包的实时质量到底好不好 —— 这一篇还没到要讨论这个的时候。先把伏笔埋在这里。

第二个问题：拿后台 key

火山引擎控制台注册账号、实名、开通豆包 Realtime、领新用户额度。

到这一步我撞到了纯产品文档救不了我的坑：

控制台里有一堆看起来非常像的字段 —— AppID / Access Key ID / Secret Access Key / Token。豆包 iOS SDK 文档里要的那个”AppKey”，到底对应控制台里的哪一个？

我猜错了好几次，每次都返回认证失败。翻文档、翻 issue、问 Claude，最后才搞清楚正确的对应关系。

这种”看起来一样实际上不是”的字段命名是国内云厂商控制台的通病。后来我特意让 Claude 把这个坑写进了 v2.x 的工程任务书，红字提醒以后任何 Codex 跑这个流程时都先核对一遍。

第三个问题：iOS 项目怎么起

我让 Claude 起了一份 v1 工程任务书 —— 目录结构、技术栈、关键文件骨架、装哪些依赖、最小可跑 demo 的代码。然后整份甩给 Codex。

技术栈定下来：

  • SwiftUI（UI 层）
  • SwiftData（本地存储，先不联云）
  • CocoaPods 装豆包 SDK（SpeechEngineToB）
  • 真机调试（模拟器没法用麦克风权限）

Codex 把项目骨架生成出来：

Cappy/
├── CappyApp.swift          ← app 入口
├── ContentView.swift       ← 主界面
├── CappyEngine.swift       ← 封装豆包 SDK 的核心类
├── Models/Profile.swift    ← 小朋友档案
├── Prompts/                ← 各种 prompt 文件
└── Credentials.swift       ← 后台 key 放这里

然后我打开 Xcode 做了几件事：

  • 接收 Codex 已经生成并编译验证过的代码
  • 在 Claude Code 的指导下设置 Info.plist 里的麦克风权限描述
  • 把 iPhone 接上线、Signing 选自己的 Apple ID
  • 按 ▶ build & run

整个过程我自己没写一行代码。 麦克风权限怎么配、Signing 怎么选、Info.plist 里的描述要写什么 —— 全是 Claude Code 在终端里手把手给我具体操作步骤。我连 Apple Developer 账号怎么配 Signing 都不太懂，照着 Claude Code 一步步点。

第一次跑通

从我打开 Xcode 到产品发出第一句话，大概只用了一天。

这个速度跟我预想的差距挺大 —— 我以为搭一个能跟 AI 实时语音对话的 iOS app 至少要两天。但实际只花了一天。

主要原因是 Codex 写完代码会顺手编译一遍，每一步出错都能立刻定位、立刻改。短的环境配置 Q&A 在 Claude Code 里直接问，分秒得到答案。整个流程异常顺。

第一次按下”按住说话”按钮、对着手机说 “Hello, Cappy. How are you?”，片刻之后听到一段流利的英语回来 —— 这是项目里第一个 “work 了” 的瞬间。

但我立刻闻到了不对劲。

闻到不对劲

我的 prompt 里明明写了：

  • 200 词高频白名单（对应 4 岁母语孩子水平）
  • 句长上限 5 词
  • 不能用 magnificent / interesting / observe 等等几十个”超纲”词

但豆包回的每一句都是完全成人化的对话：

  • 长度上 —— 经常是 10-30 词的长句，跟我要求的 5 词上限完全两回事
  • 内容上 —— 充满 awesome / interesting / curious 之类的”超纲”词，语调温柔，表达”自然”
  • 风格上 —— 像一个温暖的心理咨询师，不像给孩子的英语陪练

我试了一晚上各种话题、各种问法，每一句回复都不在我设的轨道上。Cappy 完全无视我的 prompt，按自己”做一个温暖大人对话”的本能在说话。

我以为是 prompt 不够狠

第一反应：肯定是我 prompt 写得不够严。

于是我开始加码：

  • 把 “Please use only these words” 改成全大写的 “STRICT REQUIREMENT: NEVER use any word outside this list”
  • 加了 self-check checklist：让 AI 回复前先数自己用了几个词，超过 5 就重写
  • 把所有可调的难度参数全压到最低档
  • 把白名单、黑名单、示例对话全塞进去

还是超纲。 一字一句都没听。

最后我注意到豆包后台开始报错 —— prompt 字符数到上限了。

我当时第一反应是疑惑：大模型的上下文不是动辄几十万 token 吗？怎么会这么短就到上限？

后来才搞清楚：这个 4000 字符不是模型的 context 上限，是豆包 Realtime 这个产品自己加的系统 prompt 长度限制。底层模型本身的能力跟你能传给它多少 prompt，是两件不同的事。

也就是说：我用了一晚上想”再加点约束就能让它听话”，但其实 prompt 这条路从工程层就被人为掐住了 —— 我加不动了。

但这一版完全没法用 —— 我自己都听不懂

不是孩子的问题。是我自己的问题。

我一个成年人，听 Cappy 回的话都得停下来想”它在说什么”。那些 14 词、20 词的句子里塞了 awesome / interesting / chill / curious 这种抽象词，再加上语调温柔的心理咨询式反问 —— 我自己理解都吃力。

别说 8 岁孩子了。

所以这一版我根本没给小菠萝看。直接否决。

决定否决 v1，开始查问题

那天后半夜我把 v1 否决掉。第二天打开 Claude，把整个情况摊给它：prompt 是这样写的、模型回的是这样的、4000 字符上限撞到了、加重措辞没用。

接下来花了 4 天才真的想清楚出路在哪（中间还过了个周末）。

这 4 天没写一行代码、没出新的任务书 —— 但走通了”为什么不行 + 怎么改”的判断链。下一篇 诊断 4 天 — v1 整体不能用，但可以拆开用 细讲。

几个小总结

不会写代码的人能做 iOS app 吗？ 2026 年这个时间点，能。但你要接受一个新角色：你不是工程师，你是产品经理 + AI 的”反馈终端”。判断、决策、试用、描述问题 —— 这些是你的活。代码不是。

干永远比想重要。 做产品要用最快的速度跑出 MVP，在能跑的基础上慢慢迭代。我选豆包的第一原因是”iOS SDK 现成”，不是质量 —— 因为我要的是先撞到墙、再决定方向。很多问题不撞墙根本想不到。“想清楚再开始”是最容易把自己卡死的状态。

遇事不决问 AI。 不会就问 Claude / Claude Code / Codex。如果它一时不知道，直接把官方文档丢给它。我做这个项目里 90% 的”我不知道怎么办” —— 从 Xcode 配置、到 SDK 集成、到 prompt 调试、到诊断模型问题 —— 都是这么过来的。要相信 AI 真的能帮你解决任何工程问题，只要你愿意把上下文（包括文档）喂全。

控制台字段名 ≠ SDK 字段名。 国内云厂商常见坑。AppID / AppKey / Access Key / Secret 几个名字看起来一样，实际不是同一回事。集成前先跟 SDK 文档对一遍每个字段。

自测时连成年人都觉得不对劲，就别幻想”再调调就行”。 我熬夜疯狂加 prompt 那一晚就是最大的浪费。自己作为成年人都听不懂的对话，就别想”小朋友可能能听懂” —— 那是给自己的幻觉。

下一篇：诊断 4 天 — v1 整体不能用，但可以拆开用。