夜雨聆风
产品经理AI实战:7天上架AppStore
FIELD NOTES ／ NO.01
一个产品经理的 AI 造 APP 实录
— 2014 to 2026, twelve years later —
2014年5月19日，我是一个即将大学毕业的学生，那天我向appstore提交了一个我做的APP进行审核，被拒绝了，当然这在意料之中，我只是用前端组件”搭了”一个APP的壳，里面的所有功能都实际上并没有实现，我根本没有代码能力完成那项工作。
12年后，7天前我决定用AI从零做一个iOS APP并上架App Store，这篇文章记录了完整的过程、踩过的坑，以及我对“产品经理用AI做APP”这件事的真实感受。
01CHAPTER ONE
我为什么做这个APP
核心目的：加速学习AI，动脑不如动手
希望看看AI现在到底能做到什么程度，成本有多低，哪些能干哪些不能干
实操层面，AI有哪些局限性和坑，会带来哪些问题
AI对于产品经理的意义如何
❋ ❋ ❋
02CHAPTER TWO
我做了个什么APP
PRODUCT
WearRight — 一个穿衣推荐工具
核心想法很简单：我经常出门穿多了热，穿少了冷，我想每天早上出门前看一眼手机，APP告诉你今天、明天该穿什么。
但它和普通天气APP的穿衣指数不一样。所有现有穿衣推荐产品的问题是：
THE PROBLEM
用数字温度代替了人的真实体感。
一个怕冷的女生和一个壮实的男生，站在同一个8°的街头，需要穿的衣服可能差两个层级。普通天气APP说”今天适合穿外套”，WearRight会说”你今天傍晚6点在户外最冷只有14度，室内公司25度，建议室内穿短袖，出门加一件拉链外套方便脱”。
三大差异化
|
01 |
不是按实时温度推荐，而是按你真正会经历的最低户外温度 |
|
02 |
考虑个人体质（怕冷怕热、年龄、出行方式） |
|
03 |
支持全家管理（给宝宝、给父母一起推荐） |
❋ ❋ ❋
03THE TOOLKIT
用了哪些AI工具
核心工具链：我 + Claude Code
其他配套工具
|
技术栈 |
React Native + Expo SDK 54 + TypeScript |
|
天气数据 |
和风天气API |
|
部署 |
EAS Build + EAS Submit |
|
页面托管 |
GitHub Pages（隐私政策等） |
|
UI 设计 |
Claude |
❋ ❋ ❋
04UNDER THE HOOD
这个项目的复杂度远超预期
“穿衣推荐”四个字听起来很简单，但做到第三天我就意识到，这个APP的复杂度被严重低估了。
No.1
算法不是查表，是多变量决策
不是”20度推荐薄外套”这种简单对应关系。一次完整的推荐要走6个计算环节：获取逐小时天气数据 → 找到用户户外时段内的最低温度 → 叠加体质修正 → 计算总保暖量需求 → 从70件单品库里按层级、温度范围、性别、场景筛选组合。
其中每一步的数值都不能靠AI拍脑袋，必须人工校准。我最后手写了42条真实场景的验收测试，逐条比对每个温度点的推荐结果，改了10+轮才全部通过。
No.2
四个时间维度，每个都不一样
APP有今天、明天、7天、旅行四个页面。看起来只是时间不同，但背后的数据源、计算逻辑、展示方式全不一样。最头疼的是数据一致性——同一天的推荐，在”今天”页面和”7天”页面里必须完全相同。这个问题我们修了不下5次，最终靠架构重构为”1个Store统一计算+所有页面只读缓存”才彻底解决。
No.3
多角色系统，隔离比想象中复杂
APP支持给家庭成员分别推荐——你的通勤穿搭、宝宝的外出穿搭、父母的散步穿搭。这意味着每个角色有独立的体质档案（怕冷程度、年龄段、出行方式、户外时段、室内温度），算法要按角色分别计算，但天气数据和城市又是全局共享的。
哪些数据跟着角色走、哪些数据全局共享，边界稍微没划清楚就会串数据。开发过程中确实遇到了引擎层计算正确、但UI层把数据写到了全局字段而不是当前角色字段的bug。
No.4
“其他”模块的触发规则全是特例
除了上衣裤子鞋袜这些”保暖量驱动”的推荐，还有一大类单品完全靠天气条件触发：推墨镜和防晒衣、加棒球帽、推遮阳伞；雨天推折叠雨伞、骑行加雨衣；推围巾手套帽子、加口罩、加耳罩。这些规则无法用统一公式覆盖，全是一条条手工定义的产品逻辑。
No.5
69件单品库，每件都要人审
每件单品有十几个属性——部位、层级、保暖度、温度适用范围、性别、正式度、常见度。这不是技术工作，是产品工作。
No.6
外部API集成的坑比代码还多
接入和风天气API要处理：专属Host域名配置、JWT鉴权和API Key两种认证方式的选择、逐小时预报和多日预报的数据格式差异、请求缓存策略、网络失败后的降级显示、以及后来上线后才暴露的——独立Host下不同API路径前缀不同。这些在文档角落里可能提了一句，不踩到坑你根本不会注意。
❋ ❋ ❋
05SEVEN DAYS
7天开发：从产品到上架的完整复盘
PHASE 01
产品定义 + 产品设计
这是整个项目里最重要、耗时最长、也最容易被低估的阶段。大部分人以为”用AI做APP”是从写代码开始的，但实际上，写代码之前的产品思考才是真正决定成败的东西。
我和Claude产出了一份完整的产品战略文档，涵盖：痛点分析、竞品差异化战略（竞品在”体质个性化”等维度全部空白）、产品架构设计、功能分期规划以及算法计算公式框架。
💡 阶段感悟 产品文档不是给别人看的，是给自己理清思路的。AI可以帮你讨论、写文档，但每个决策必须你自己拍。
PHASE 02
基础架构 + 代码开发
有了产品文档做输入，代码开发的效率高得惊人。Claude Code快速搭建了React Native项目骨架，接入和风天气API，并将文档里的算法框架（体感计算、保暖量分配、单品筛选）翻译成了代码。同时搞定了内购支付、状态管理等硬核功能。
💡 阶段感悟 确认了Claude Code确实能写出结构清晰的可运行代码。前提是大量逻辑讨论已经在阶段一完成了。
PHASE 03
UI完善 + 算法修复 + 架构重构
这是最痛苦的阶段。代码能跑了，但功能不对。第一次真机测试简直灾难：23度居然推荐穿厚卫衣+外套。
后来让Claude画出数据流图才发现是架构问题，4个页面各自独立计算导致参数不一致。最终将架构重构为”1个Store统一计算+4个页面只读缓存”才解决。
💡 阶段感悟 “代码跑通”和”功能正确”是两回事。Claude说”137个测试全通过”没意义，因为它自己mock数据自己测，相当于自己出题自己答。
PHASE 04
产品审核 + 最终修复 + 上架
这个阶段全是人工逐条审核。我让Claude生成算法逻辑和单品清单的中文文档，逐一排查。发现了体质修正值乱拍、逻辑写反等大量问题。经历了一轮大改，精简了单品库，跑通了5条我手写的真实场景验收测试。
💡 阶段感悟 如果没有人工审核，上架一定会被骂。PRD是理想，代码是现实，审核是把两者拉齐的过程。
❋ ❋ ❋
06PITFALLS
我踩过的那些大坑
|
PIT 01 |
AI说”已修复”但实际没修 |
它每次都在修表面症状，改个变量名，调个函数。遇到顽疾，必须让它停下来，画数据流图，找到根因，出方案确认后再执行。
|
PIT 02 |
关键数值全靠AI拍脑门 |
保暖量基准、体质修正数值，前3天我全放权给AI，结果一塌糊涂。经验：每个关键数值都要产品负责人”签字”。
|
PIT 03 |
改了A导致B出问题 |
改了首页的温度显示，明天页就崩了。经验：每次改完代码，必须重跑全部功能，改动范围严格控制在5个文件内。
|
PIT 04 |
单品库偷懒不得 |
一开始AI生成162件单品，审核发现背心、洞洞鞋全出来了，女性常见度全是0。这个工作必须人工一件件审，最终精简到69件。
|
PIT 05 |
验收用例比测试用例重要100倍 |
开发自测和产品验收是两码事。我手写的5条真实生活场景用例，发现了3个致命bug，比跑137个自动化测试还管用。
|
PIT 06 |
开发模式正常 ≠ 生产模式正常 |
这是上线翻车教给我的最贵一课。开发模式读的是本地配置文件，生产构建读的是云端环境变量——这两个是完全独立的来源。我在开发模式里测了无数遍”一切正常”，但生产环境里API密钥其实是空的。
以后的铁律：发版之前，必须用TestFlight装一遍生产构建版本，手动验证核心功能。开发模式下的测试只能算半个测试。
|
PIT 07 |
第三方API换了规则，你的代码就悄悄坏了 |
和风天气启用独立Host后，城市搜索API需要加路径前缀。这不是代码问题，不是逻辑错误，是第三方平台的规则变了。经验：接入第三方API后，验收测试必须覆盖每一个独立接口，不能只测主流程。
|
PIT 08 |
“未来24小时”不等于”今天24小时” |
这个bug藏得最深。和风天气的逐小时预报API返回的是从当前时刻起的未来24小时，而不是今天0点到23点。这意味着如果你下午3点查看，API返回的”13点数据”其实是明天下午1点的——而代码只看了小时数字没看日期，把明天的数据当成今天的用了。
结果就是：下午30度的天气，App算出来的体感温度是16度，推荐穿厚长袖加马甲。用户设了”上午””中午””下午”三个不同的时段，温度居然都是16度——因为拿到的全是明天同时段的数据。
更可怕的是，这个bug在上午使用时完全不会暴露，因为上午查看时API里的上午数据确实是今天的。只有在下午或晚上打开App时才会触发，而开发阶段我恰好大部分测试都在上午做的。
|
PIT 09 |
算法正确≠推荐合理，有时候整个思路需要推翻重来 |
1.0版本的核心逻辑是”按最低体感温度推荐衣服”。算法没bug，42条测试全通过。但上线后我自己用了一天就发现：杭州4月底，早上17度出门穿厚长袖加马甲确实合适，但到中午31度还穿着这身根本受不了。
AI给了三个补丁方案：加提示文案、标记”午后可脱”、做双时段推荐。我全部否掉了。因为根本问题不是缺提示，是整个推荐思路就是反的——应该先按最高体感选一套不会热的基础层（短袖），然后往上叠加可脱的外层（针织衫+薄外套）来扛住最低温度。这就是所有穿搭博主教的”洋葱穿法”。
这个改动牵一发动全身：保暖量计算要分层、上身选品逻辑要拆成基础层和外层两步、下身在高温时不能推荐两层、脚部要用折中温度。等于把推荐引擎的核心重写了一遍。但改完之后，推荐结果第一次让我觉得”这就是我会穿的”。
❋ ❋ ❋
07REFLECTIONS
关于AI协作，我想明白了这几件事
做完整个项目、经历了上线翻车和紧急修复之后，我对”产品经理用AI开发”这件事有了一些更深的认知。
i.
AI协作不是”下指令”，是”一起想”
很多人以为用AI做APP就是”我说你做”。但实际上我和Claude的关系更像两个合伙人在白板前讨论。它提方案，我否掉。我提想法，它指出漏洞。
比如算法要怎么处理温差大的天气——早上17°出门穿厚长袖加马甲没问题，但中午31°还穿着这身就热死了。Claude给了3个方案（加提示文案、标记”午后可脱”、双时段推荐），我全部否掉，说”应该按最高体感选基础层，再往上叠可脱的外层”。它立刻理解了，帮我把这个直觉翻译成了精确的计算公式。
“
AI最大的价值不是替你想，而是帮你把模糊的直觉变成精确的方案。
但前提是——你得有那个直觉。
ii.
交接文档是AI时代的新型PRD
传统产品经理写PRD给工程师，AI时代的产品经理写”交接文档”给AI。
我维护了一份不断更新的交接文档，记录了所有架构决策、算法参数、已知bug、验收标准。每次开新对话，上传这份文档，AI就能无缝继续。上线翻车那天晚上，我开了一个全新的对话窗口，上传交接文档，Claude立刻恢复了对整个项目的理解，5分钟内就进入了诊断状态。
这份文档和传统PRD最大的区别是：
“
PRD描述”要做什么”，交接文档记录”做了什么、为什么这么做、哪些坑踩过了”。
它既是给AI的上下文，也是给未来的自己的备忘录。
iii.
最危险的时刻是AI说”全部通过”
AI跑完137个自动化测试告诉你”全部通过”的时候，恰恰是你最应该警惕的时刻。因为测试用例是AI自己写的，数据是AI自己造的——相当于自己出题自己答。
真正有价值的验收是：我手写了5条真实生活场景（”杭州春天打车通勤的成年人””北京冬天老人外出”），用这些场景去比对推荐结果。5条场景发现了3个致命bug。
“
AI能保证代码不报错，但不能保证产品不离谱。后者是产品经理的工作。
iv.
“人拍数值，AI写公式”是最佳分工
算法里每一个关键数值全部是我根据生活经验拍板的，AI负责把这些数值组装成可运行的计算逻辑。
前面我偷懒让AI自己拍数值，结果灾难性的不准。AI没有穿过衣服，没有在寒风中等过公交，没有体会过室内25度和室外5度的温差。
“
这些只有人有的体感经验，恰恰是穿衣推荐算法的核心。
到后来每次涉及数值调整，Claude会主动给我几个选项并说明理由，然后等我确认。这个协作模式是磨合出来的——一开始它也喜欢自己拍脑袋，被我否了几次之后就学会了先问再做。
v.
上线才是真正的开始
开发7天，上线修复12小时——但上线后发现的问题密度远超开发阶段。
开发时你面对的是自己的测试环境，上线后你面对的是所有用户的真实环境。生产配置没带上、第三方API路径变了、苹果审核流程的各种细节——这些”代码之外的事”占了上线后工作量的80%。
而且这些问题AI帮不了太多。它不知道你的Expo后台有没有配环境变量，不知道和风天气最近改了路径规则，不知道苹果加急审核要去哪个页面申请。
“
AI能帮你把APP做出来，但运营一个APP需要的判断力、应变能力和对细节的执着，目前还替代不了。
“
AI 负责怎么做，
人 负责做什么、对不对、好不好。
— THE BOTTOM LINE —
❋ ❋ ❋
08BY THE NUMBERS
📊 项目数据盘点
|
DAYS 7 项目天数 |
⌨️ CODE LINES 10,000+ 代码行数（AI写的） |
|
🤖 BATCHES 80+ Claude Code 指令批次 |
🔧 ROUNDS 15+ 算法修复轮数（含核心重构） |
|
👕 WARDROBE 162 → 69 单品库精简 |
🏗️ FLAWS FIXED 7 发现并修复的架构缺陷 |
|
🐛 PROD BUGS 5 上线后发现的生产 bug |
⚡ APPLE REVIEW < 12 hrs 苹果加急审核通过时间 |
❋ ❋ ❋
EPILOGUE
最后我想说这次实战最核心的感受：最最最重要的是——定义产品的能力，应该花80%的时间在产品定义、产品设计上，这才是真正重要的事。
THE FINAL TAKEAWAY
AI降低了”做APP”的技术门槛
但没有降低”做好APP”的产品门槛
以后谁再说”我有一个idea，就差一个程序员了”——不，你现在连程序员都不差了。你差的是把idea变成精确产品需求的能力。
❋ ❋ ❋
NOW LIVE ON
WearRight
已在 App Store 上架 · 搜索”WearRight”即可下载
觉得有启发，点个 在看 或 分享 给需要的朋友吧 👇
— END —