如果一个不会写代码的人想做一款 iPhone App，第一步通常是什么？找工程师，学编程，攒预算，或者把想法先放进备忘录，等一个“更合适的时机”。
Bryce Rattner Keithley 的故事偏偏绕开了这条老路。她不是工程师，职业背景在招聘和人才领域。她只是有一个很小、很日常的念头：每天让自己动起来，做一个动作，完成 100 次。
后来，这个想法变成了真正上架 App Store 的健身 App：Daily Hundred。
这个案例最吸引人的地方，不是“AI 又写了一段代码”，也不是“不会编程也能一键创业”的爽文。它更像一条完整的新链路：一个编程小白，如何借助 AI 工具，把生活里的小想法推进成真实产品。
Daily Hundred 的起点非常朴素。每天推送一个不同的运动动作，用户做满 100 次，然后记录下来。它没有试图一开始就颠覆健身行业，只是在解决一个普通人的生活摩擦：我想运动，但我需要一点提醒、一点变化、一点完成感。
过去，这样的想法很容易停在“听起来不错”。因为从想法到 App，中间隔着产品设计、前端、后端、数据库、部署、移动端适配和审核规则。任何一个环节，都足够让非技术人停下。
Bryce 的第一步，是把想法直接交给 AI 开发工具。她同时试了 Lovable 和 Replit，提示词并不复杂，核心意思就是：帮我做一个叫 Daily Hundred 的工具，每天推送不同的运动动作，让我记录 100 次完成情况。
一句自然语言需求，过去更像是说给产品经理或工程师听的，现在却可以直接变成一个可运行的 MVP。
她最后主要留在 Replit 里迭代，因为那里可以一边看预览，一边继续对话修改。早期她也踩过坑：直接命令 AI 改 UI，比如把进度条改成圆形，结果有时会跑偏，甚至影响已经能用的部分。后来她开始使用 Replit 的 Plan Mode，先让 AI 解释会改哪里、为什么这么改、是否影响其他功能，再决定执行。
这一步很关键。她不是单纯“命令 AI 写代码”，而是在学习如何和 AI 一起规划。
MVP 能跑之后，新的问题出现了。朋友试用时反馈，有些动作不知道怎么做。比如 Superman、reverse lunge 这样的动作，如果 App 只是给出一个名称，用户很可能卡住。健身产品不能只有任务，还要有示范。
传统做法当然存在：自己拍视频，找教练录素材，请动画师，或者买素材库。但 Bryce 不想做一组普通的客厅自拍视频，也不想让产品看起来像所有健身工具一样。她决定让拟人动物来演示动作：北极熊、乌龟、狐狸，穿着运动装备，在健身房里完成训练。
这听起来像一个小创意，但它说明了 AI 工具链的另一层变化：AI 不只是把原来的事情做便宜，也会让过去“不值得专门投入”的表达方式变得可以尝试。
她的内容生产流程分三步。第一步，用 Gemini 生成静态角色图，提示词细到动物种类、服装、场景、身体朝向、动作起始姿势，以及画面里不要出现其他角色。第二步，用 iPhone 录制自己的动作参考，不追求精致，只要动作轨迹清楚。第三步，把静态图和参考视频放进 Higgsfield，用 Motion Control 和 Kling 模型让角色动起来，并尽量保留原图里的健身房场景。
于是，一个原本可能需要插画师、动画师、剪辑师协作的小素材，被拆成了普通人可以执行的几步。Gemini 负责角色和画面，手机负责动作数据，Higgsfield 负责动画合成。Bryce 做的事情更像导演：决定要什么，检查像不像，不对就重新提示、重新生成、重新组合。Daily Hundred 也因此不再只是“能记录次数”的工具，而有了自己的产品气质。
但把 Web App 做出来，和把 iPhone App 上架，是两件完全不同的事。
真正的难关出现在 App Store 提交流程。对技术团队来说，这也许只是上线工作的一部分；对非技术人来说，它是一片陌生地带：部署、配置、账号、认证、权限、审核规范、登录机制、用户数据删除，每个词都可能让人停下来。
一开始，很多人会以为她最后还是需要工程师。但等她真正准备上架时，Claude 和 Claude Code 已经足够让她尝试自己推进。她问 Claude 的方式很坦白：我不懂技术，如何把一个 Replit App 准备到可以提交 App Store？
接下来，她形成了一个有意思的“小团队”工作流。普通 Claude 像技术架构师，负责解释整体路径、拆解步骤、判断方案是否合理；Claude Code 像工程师，负责生成具体代码、命令和修改；然后她再把 Claude Code 的结果交回 Claude 检查，确认没有明显问题后，自己在终端执行。
这不是盲目复制粘贴 AI 输出，而是让一个 AI 监督另一个 AI，让非技术人也能建立基本的质量控制。她真正掌握的是流程控制：先问清楚，再执行；执行完，再复核；出错后，把错误信息继续交给 AI 解释。
第一次提交 App Store 后，Daily Hundred 被拒了。原因也很真实：年龄限制配置不对，Sign in with Apple 有问题，还缺少用户删除账户的功能。
这些问题不是 demo 阶段会暴露的东西，而是产品进入真实世界之后才会遇到的门槛。很多原型之所以永远停在原型，就是因为它们没有穿过这些无聊、繁琐、没有创意但必须完成的环节。
Bryce 的处理方式很直接：把 Apple 的审核反馈复制给 Claude，让它逐条解释问题，再给出修复方案。她用一个周末，大约 25 到 30 个小时，把这些问题逐项解决，重新提交，最终通过审核。
这也是这个故事最值得记住的地方。AI 的价值不只是帮人开始，而是帮人继续。
很多关于 AI 编程的讨论，都停留在“几分钟生成一个 App”的演示感里。但真实产品从来不是生成第一版就结束，它还会遇到反馈、边界、平台规则、权限限制、用户体验问题和审核拒绝。Bryce 的案例之所以完整，是因为它把这些不光鲜的环节也串了起来。
从一句提示词生成 MVP，到用 AI 生产动作视频；从让 Claude 拆解上架路径，到让 Claude Code 写代码；从第一次被拒，到把拒稿原因变成修复清单。它不是一段炫技，而是一条产品链路。
所以，如果要给这个故事下一个判断，我不会说“以后人人都能一键做 App”。更准确的说法是：AI 正在把产品创造从“只有懂技术的人能启动”，变成“能清楚表达、持续判断、愿意修正的人也能推进”。
技术门槛确实下降了，但并没有消失。它变成了另一种门槛：能不能把想法讲清楚，识别结果是否可用，在不理想时继续追问，并面对审核拒绝、部署报错、体验反馈这些麻烦事。
Daily Hundred 的故事，表面看是一款健身 App 的上架过程。往深处看，它记录的是普通人进入软件创造的一扇新门。门已经开了，但能不能走进去，仍然取决于你是否愿意把一句“我有个想法”，一步步追问成“下一步该怎么做”。
