一人10天搞定双平台App：AI协同开发的实战方法论

1. 先泼一盆冷水：一个人10天做完双平台App，靠的不是魔法

这个标题写出来，肯定有人觉得是贩卖焦虑，也有人觉得是吹牛。但我刚做完这件事，账实打实摆在这儿：iOS和Android两个平台，10个自然日，我一个人，从画原型到上架测试包，全部搞定。工具链不神秘，核心就一句话——把AI当成一个随叫随到但不能完全信任的远程实习生团队，而我是那个既当产品经理又当架构师还当测试负责人的唯一全职工。

先把概念说清楚。我这里的“双平台App”指的是同一套业务逻辑、两套独立原生终端的移动应用，不是PWA套壳，也不是简单的WebView包装。为什么强调这一点？因为很多人一听说“一人10天双平台”，下意识的第一反应是“你肯定用了Flutter/React Native这类跨端框架”。这确实是最常见的路，但我下面会讲清楚：跨端框架只是技术选型的一种，真正让10天这件事成立的，不是框架，而是你如何把“人-机协作”拆成一条可复用的流水线。

这篇文章适合谁看？三种人。第一种是正在观望要不要用AI写代码的独立开发者，你可以少走我踩过的弯路；第二种是已经在用AI但总觉得“改来改去不如自己写”的团队工程师，你会在这里找到问题出在哪个环节；第三种是产品负责人，想评估AI协同开发究竟能把周期压缩到什么程度。不适合谁看？指望AI点两下就自动生成完整商业产品的人——这篇文章教的是方法论，不是许愿术。

先说一个反直觉的结论：整个10天里，我真正坐在屏幕前“写”代码的时间，可能不到30个小时。剩下的大量时间，花在了三件看起来完全不“开发”的事情上——写文档、做验收、拆任务。这大概是AI协同开发与过去所有开发方式最本质的区别：过去程序员的时间成本集中在“生成代码”，现在生成代码变得极其廉价，真正的成本转移到了“定义需求”和“验证结果”上。谁先适应这种成本结构的转移，谁就能把这套打法跑通。

2. 一人公司的团队结构：我是CEO，AI是五个远程实习生

如果只是“我用AI写代码”，那这篇文章没有写的必要。真正值得复盘的，是我如何把一堆通用大模型组合成一个“虚拟五人组”——每个人各司其职、上下文隔离、按流程交接。

2.1 为什么不能只开一个聊天窗口干到底

很多人在使用AI编程工具时有个坏毛病：想做什么就开一个会话，上下文乱七八糟，今天让它写登录页，明天又让它改同一个文件里的支付逻辑，中间还夹着聊天式的“帮我看看这个报错”。这种用法在小项目里勉强能跑，一旦项目进入多模块并行阶段，马上会翻车。

我的做法是给AI角色分区，每个角色固定承担一类工作，用独立的会话或独立的项目目录把它们隔离开。这里，我把“自研AI助手”这个双平台App的开发团队拆成了五个虚拟角色：

你可能会说，这不就是多开几个窗口吗？区别不在这里，在于上下文和交付标准的隔离。给产品经理角色的对话，我绝不丢代码文件过去，只给用户场景和业务指标；给测试角色的对话，我绝不只让它“看一眼代码”，而是明确要求它从用户视角构造边界条件。每个角色的思维模式都被我锁死在特定频道里，AI的随机性和飘移感被大幅压缩。

2.2 把“人机接口”定义清楚，比提示词技巧重要十倍

我见过很多人跟AI协作时，提示词写得花团锦簇，什么“请你扮演一位拥有十年经验的高级架构师”之类。说实话，这种开场白在偶尔一次对话里可能有点用，但在一个多角色、长周期的项目里，作用会被迅速稀释。真正稳定的是结构化输入。

我的每个角色会话，第一次对话都会固定发送一份“角色设定+当前任务+输出格式”三元组。举个例子，给架构师角色的第一条消息大概是这样的：

角色：移动应用架构师 项目背景：自研AI助手，一款面向C端用户的双平台App，功能包括AI对话、智能体广场、会员支付。 约束条件：一人开发，周期10天，代码必须可维护，尽量少写胶水代码。 任务：请输出完整的技术方案，包含技术栈选型及理由、全局目录结构、数据模型设计（含表结构）、关键模块划分、第三方服务选型。 输出格式：Markdown文档，每个模块需写清楚职责说明和模块间依赖关系。

注意关键词：“约束条件”和“输出格式”。AI模型在没有边界的情况下会倾向生成宏大、完备但不可落地的方案，而一旦你给了它“一人开发、10天周期”这种硬约束，它会自动砍掉很多理想主义的架构设计，给出更务实的选择。这个“务实的倾向”不是模型的思考能力变强了，而是提示中的约束触发了它对可行性的概率加权。理解这一点，你在与AI协作时就不需要再纠结“它到底懂不懂我”，你只需要把边界描述清楚，剩下的交给它。

3. 技术选型：为什么我没选原生双写，也没选RN，而是上了Flutter

技术选型这件事，在传统团队里往往是架构师的政治决策，但在一人公司里，只有一个决策标准：能不能在10天内让我以最低的认知负担交付两个平台的产物。我的答案很明确——Flutter。

3.1 双平台方案的对比表与选择逻辑

先说结论和理由，对比表放在下面，后续再展开。

原生双写首先排除——10天做两个原生应用对一个人来说不是难，是不可能。React Native和Flutter之间我犹豫了两天。最后让天平倾斜的其实不是技术指标，而是一个很现实的点：一个人开发时，最大的敌人不是性能天花板，而是“心智切换成本”。Flutter的Widget树把UI和逻辑粘在同一套代码体系里，我在写界面时不需要切换语言思维。React Native虽然也用JavaScript，但它的组件层级里藏着大量原生桥接的“暗坑”，每个坑都是一次心智消耗。仔细算下来，这些“小消耗”积少成多，在一人团队里足以造成致命延期。

3.2 为什么AI协作场景下Flutter的优势会被放大

这就到了本文标题里“与AI协同开发”的关键点了。我选Flutter，不只是因为它适合一个人开发，更因为它特别适合AI来写。

第一，Flutter的UI代码风格高度统一。所有界面都是Widget套Widget，这种“万物皆Widget”的组合模式与AI大模型的生成模式天然匹配。模型见过的Flutter代码越多，生成的Widget组合就越规范。相比之下，原生iOS的SwiftUI和原生Android的Compose虽然也声明式，但两套代码风格差异巨大，AI在跨平台时容易“串味”。Flutter意味着我只给AI一套语法体系，它就能同时负责两个平台的界面。

第二，Flutter的官方文档和示例代码极其丰富。大模型的训练语料里，Flutter相关内容密度很高，这意味着AI生成Flutter代码的“幻觉率”明显低于一些小众框架。实测下来，用Flutter写UI时，AI第一遍生成的代码平均有七八成能直接跑通，而写某些后端框架时，第一遍能跑通的比例大概只有一半。这个差异在长周期开发里是决定性的。

第三，Flutter的编译反馈链路调试体验非常平滑。我用的开发流程是：AI写代码、我直接热重载看效果、不对劲就把报错和截图扔回去让AI改。Flutter的热重载速度在主流框架里是第一梯队，几乎存盘即刷新，能把“人机反馈回路”压缩到秒级。这个回路越快，AI协作的迭代周期就越短，10天做完双平台App这件事就越多一分把握。

提示：技术选型没有银弹。如果你团队里全员React技术栈，或者产品对原生系统能力依赖极重，Flutter未必是你的答案。我这里只提供一个真实场景下的决策样本，不要直接照搬结论。

4. 10天周期的拆解：我不是在写代码，我是在“导演”一段协作流程

定好了团队结构和技术栈，接下来就要面对最实际的问题——10天到底怎么排。我的做法是把它拆成三个阶段：前2天“共识期”、中间6天“冲刺期”、最后2天“收敛期”。每个阶段的任务类型、人机协作比重、验收标准都完全不同。

4.1 共识期（第1-2天）：把AI逼成“复读机”

这个阶段的核心目标只有一个：让AI把需求和方案用文档形式固定下来，反复振荡直到没有歧义。很多人拿到需求就急着让AI写代码，这是最大的时间浪费。我在前2天做的，是让产品经理会话输出完整PRD，让架构师会话输出技术方案，然后我自己以“最终决策人”身份逐条审阅。

你要做的是把这两份文档丢回给对方，然后开启“复读机模式”。怎么复读？举个例子，PRD里写着“支持微信登录”，我会这样追问：

请明确以下几个细节： 1. 微信登录是否包含手机号绑定流程，还是仅作为第三方授权凭证？ 2. 登录后如果用户手机号与微信不一致，账号体系如何合并？ 3. 微信登录失败（用户取消授权）时，前端应提示什么文案？ 请逐条回答并更新PRD文档。

这个过程看起来很枯燥，但它有一个巨大的价值：AI在复述和澄清的过程中，会把所有含糊概念“压实”成可执行的结构。传统团队里产品经理和开发来回确认需求要开三次会，这里变成了人机对话里的三次追问。两天结束后，我手里有了两份我完全理解、AI也完全理解、且颗粒度足够细的文档。后面的6天冲刺才有底气。

4.2 冲刺期（第3-8天）：模块流水线的“你写我验”

冲刺期是整个项目的心脏。我的排法是按模块纵向推进，每个模块走一遍“四步流水线”：任务拆解、AI生成、人工验收、反向修改。

四步流水线实操起来是这个样子的。第一天早上，我把PRD里的模块清单拆成6个feature切片：用户登录、AI对话、智能体列表、会员支付、个人中心、全局框架。每个feature切片单独开一个开发会话，避免上下文互相污染。开发会话的启动消息严格遵循我在第2.2节定义的格式，并追加本次任务的具体范围。

以AI对话模块为例，我让AI生成的代码任务拆解为：

阶段一：搭建消息列表、输入框、发送按钮的基础UI。 阶段二：对接后端stream接口，实现流式打字机效果。 阶段三：处理错误重试、网络断线提示、空状态展示。 阶段四：历史会话记录持久化与加载。

每个阶段生成完，我不直接拿走，而是先要求AI“自测”——让它自己列出代码里可能存在的三个边界问题。这一步不是形式主义，而是利用了模型对自己生成内容概率分布的“弱点筛查”。怎么说呢？模型生成代码时，对比较生僻的API调用容易含糊，但让它回头检查时，它往往能精准指出这些含糊点。相当于你免费得到了一个代码review机器人。

四步流水线的最后一步“反向修改”，是把编译报错、运行时白屏、交互不符合预期这些现象，原封不动地描述给AI，让它提供修改方案。注意，这里的玄机在于不要只给结论，要给现象。比如“登录按钮点击后没有反应”，AI可能猜到了很多原因，但如果你补一句“点击后控制台输出了一行红色报错：TypeError: null is not an object”，它的修改命中率就高了一个量级。

4.3 收敛期（最后2天）：把所有“看起来能用”的东西变成“确实能用”

前8天结束，理论上功能全部齐了，但一个一个人做完的项目，此时的状态一定是“表面完整、内部随机”。收敛期就干三件事：第一件，我让测试工程师会话对着PRD逐条走查，把“边界情况缺失”“异常分支没处理”“文案不统一”这类问题全部列出来，形成一张问题清单，每天集中修一轮；第二件，我自己拿真机跑一遍完整的核心用户路径——注册、对话、支付、查看记录，发现一处不对就立刻丢回给AI；第三件，把打包、证书、上架这些环境配置一次性搞定，我踩过的坑是双平台证书和软硬件要求差异很大，如果不是收敛期专门留出时间，很容易在上架环节突然卡住两天。

这里有一个关键心得：收敛期不该写任何新功能，哪怕看到一个“顺手就能加”的小按钮。这些顺手功能会无限膨胀，把10天的节奏在最后关头拖垮。记录下来，放进V2.0的池子里，才是理性的取舍。

5. 那些AI不会替你做的事：文档、验收、兜底，以及人机协作的边界

聊完了顺风顺水的部分，必须泼第二盆冷水。这篇文章我刻意没有把它写成一篇“AI吹”文，因为AI协同开发真正难的部分，从来不是让AI多写几行代码，而是你想清楚哪些事必须留给自己做。如果下面的内容你只记住一条，我建议你记住这句话：AI可以把你的开发速度提升三倍，但它不会替你扛责任——产品不好用、上架被拒、数据出错，这些锅最终全部落在你一个人身上。

5.1 文档依然是王者，但它的角色变了

传统开发里，写文档是为了团队协作；一人公司的文档，写文档是为了和AI协作。我说的文档不是那种几十页的正式文档，而是精确到“AI可以直接按图施工”的接口级说明。在实战中，我建的“docs”目录包含了PRD、技术方案、数据字典、接口清单四类文档，加起来不到100KB，但这些文字成了整个AI协作的“宪法”。

一个很典型的场景：让AI改后端接口时，我直接把接口清单里对应的那一段丢给它，说“保持其他字段不变，只把status字段的类型从int改为enum，并同步更新client代码”。因为没有歧义，AI一次改对，没有出现它自作主张“顺便重构”的额外风险。这让我更加确认：喂给AI的上下文越收敛，它给你惹的麻烦越少，协作效率越高。

5.2 验收是“人唯一的不可替代岗位”

我经常做一个比喻：AI是效率极高的施工队，但施工队不会为烂尾楼负责，负责的是甲方。在一人公司里，甲方和乙方都是你，但你不能用同一套思维来扮演这两个角色。写代码时，你要像一个信任下属的leader，放手让AI发挥；验收时，你要像一个挑剔的甲方，逐条核对需求、体验、异常场景，半步不让。

Zustand? 不，我实测时用的是Riverpod。这个细节不重要，重要的是我在验收AI生成的状态管理代码时，不会因为它跑通了就跳过。我会额外追问自己三个问题：这个状态在App重启后是否需要保留？两个页面同时依赖这个状态时，A页面的修改会不会意外影响B页面？这个状态对应的异步操作，失败之后用户能看到什么反馈？这三个问题用word计数可能只有30个字，但它们背后是我多年踩坑换来的肌肉记忆，AI没有这个肌肉记忆，它只会确认“按需求实现了”，而不会追问“这个需求本身是否完备”。

5.3 遇到AI反复改不对的Bug时，我的兜底战术

10天里不可能不遇到AI改不对的情况。分享一个真实的Bug：AI对话页面在快速连发多条消息后，偶发消息顺序错乱。我把它丢回给AI修了四轮，每次它都给出“自信满满”的修复方案，每次实地测试都复现。第四轮结束后，我做了两个动作：第一步，让AI输出当前消息列表的完整数据结构，手工画出消息在状态管理里的流向；第二步，给AI下了一个死命令——“不要想着改逻辑，先给状态流加锁，用队列方式把并发消息串行化”。

结果不到半小时就修完了。这里想说的不是“AI不行”，而是“AI在局部修复上的效率很高，在全局分析上的能力值得怀疑”。因为大模型生成的代码就像一张概率互联网，它往往能算出“补丁最可能长什么样”，却不擅长推演一个补丁在一长串并发时序下的连锁反应。发现了这个边界之后，我的策略调整为：让AI写局部功能，我来做全局推演。

6. 实测下来最值钱的五个协作技巧：提示词、上下文、错误处理、代码管理、节奏控制

理论整完了，这篇的干货就在这里。实践了一整个项目后，我把所有“有效动作”和“无效动作”做了个对照，选出了五个最值得复制的方法。它们不依赖任何特定模型或工具，只要你也在用AI写代码，大概率用得上。

6.1 提示词不是越详细越好，而是约束化、结构化最好

我试过两种极端风格的提示词。一种是“帮我写一个登录页面”，结果AI给出一个极其通用的、带有示例图片链接的半成品，毫无可用度。另一种是恨不得把每个按钮的像素大小都描述出来，结果AI被细节淹没，完全丢失了主次结构。最后用的中间态是这个模板，百试百灵：

写一个函数：输入是用户手机号和验证码，输出是登录结果。 要求： 1. 先调 /api/auth/login 接口，拿到token后存入本地缓存。 2. 如果缓存失败，不影响登录成功逻辑，但要输出警告日志。 3. 错误码1001表示验证码错误，需要提示文案；其他错误码统一提示“服务异常，请稍后重试”。 4. 单元测试中需要覆盖这四条路径。

概括一下，四部分：函数签名、业务规则、异常分支、输出格式。这四项恰好是AI最容易自己发挥也最容易跑偏的维度，全部框死之后，生成的代码基本都能直接落进项目里，不需要大改。

6.2 上下文管理：每次只做一件事，做完干净退出

如果连续给同一个会话扔三个不同模块的任务，AI大概率会把第三个模块的代码风格“借鉴”到第一个模块里，或者干脆张冠李戴。我的习惯是“一任务一会话”，做完了如果改动了公共文件，我会做两件事：一是把变更同步回允许它在会话内保留的“项目状态摘要”文档；二是把这个会话归档，不再复用。虽然多花几十秒开新会话的时间，但换来了“每次生成都在干净上下文里完成”的高命中率，这个取舍极其划算。

6.3 错误处理：把报错原文和可复现路径同时丢回去

很多人的习惯是把报错截图给AI，然后问“怎么办”。我总结了一个信息完整度公式：报错原文 + 操作路径 + 期望结果 = 高概率一次修对。比如：

运行flutter run时，编译报错：Error: The method 'toInt' isn't defined for the type 'String?'。 场景：在支付回调里，我尝试把返回的amount字段转成整数。 期望：金额保留两位小数展示。请给出修复方案并说明修改原因。

三要素全部给齐，AI能准确定位问题，不用来回追问。如果只甩一句“支付金额报错了”，你很可能要陪AI聊五个来回才推进一米。这个技巧能大幅缩短每次修复的往返次数。

6.4 代码管理：让AI生成的代码在合入前必须过“编译+格式”两道闸

AI生成代码的质量波动很大，哪怕同一个会话里，前一段代码质量不错，后一段也可能拉胯。我的经验是：AI每次交付代码后，我不立刻人工审阅，而是先本地编译一遍，让编译器做第一道“审核员”。编译不通过的直接丢回；通过了，再跑一遍lint和格式化工具。两道闸通过之后，人工审阅只需要关注逻辑合理性，不用把时间浪费在“这里少了个分号”“那里缩进不对”这种琐碎问题上。这个习惯让我把每天花在验收上的时间压缩了大概一半。

6.5 节奏控制：奖励小步快跑，惩罚集中爆发

最后一条是关于人的纪律。我的实际体会是，与AI协同开发，最大的风险不是技术难点，而是你会在某个瞬间突然过度信任AI，一次性让它做完一大堆东西。这种“集中爆发式”的玩法，几乎必然会带来上下文溢出、风格漂移和bug堆积。反过来，小步快跑——一次只交付一个功能点、一个页面、一个接口——虽然看起来“不够高效”，但每步都有明确的验证节点，出问题时的排查范围也小得多。10天下来，我大概跑了60多个这样的“小步”，每一步都稳稳当当，从没有出现“三天做的东西突然全部推翻”的局面。

7. 结语前想说的两句实话：关于10天这个数字的真相

最后想聊一些不留面子的大实话。10天做完双平台App，这个数字的真实含义是什么？它不是一个标准答案，它是我在特定约束条件下的一个系统输出。我的功能范围刻意控制过了：核心功能就五个模块、UI走清爽简洁风、没有复杂动画、没有实时音视频、没有复杂社交关系链。如果换成一套重度交互的社交App，10天翻三倍也做不完。一人公司想清楚“砍什么”，比想清楚“做什么”更重要，这可能是这10天里最值钱的洞见。

同时想给自己留个台阶，也顺便提醒各位：10天做完不代表10天做“好”。做完的那一版，只能算是可用水平，离“精品”还有相当距离。性能调优、视觉打磨、无数个边角体验的细节，都留给了一轮一轮的后续迭代。这跟过去的工作方式没有本质区别——先跑通，再跑好，唯一的不同是AI把“先跑通”这段路的时间压缩到了极致。

我自己判断这套方法论是否成功的标准，不是它在10天内产出了多少代码，而是它能不能被复用。下一次做一个完全不同领域的App，我愿不愿意继续用这个流程？答案是肯定的。工具会换代，模型会升级，但“结构化约束、角色隔离、小步验收、人工兜底”这套协作原则，大概率在相当长的时间里依然有效。这可能才是“一人公司+AI”这个组合真正的护城河。