先把成果放在前面我用 WorkBuddy 做的一个“家庭账本”App在没写一份逐行人工代码的前提下走完了从需求梳理到双端上架的完整流程。前期我一度以为这只是个“用 AI 写 demo”的项目真正做完才发现AI 生成代码的能力只是入场券真正决定这个 App 能不能线上跑的是流程、规则和验收标准。这篇文章会把整个项目拆成六个阶段并把过程中踩到的 16 个坑一个一个列清楚最后附上我已经沉淀成技能库、可以直接复用的那套方法。先说结论如果你是想看“AI 一键生成 App”的魔法秀可以关掉这篇文章。我做的这个 App 不是什么大产品就是一个多成员记账、按月统计、带云同步的移动端应用但它的复杂度足够暴露所有“demo 能跑、上线翻车”的典型问题。以下内容适合三种人正在用 AI 编程工具做真实项目、被 AI 的“半成品自信”折磨过、以及想在 WorkBuddy 这类工作台上把开发流程固化下来的人。1. 为什么要先把流程拆成六个阶段1.1 AI 写代码不是新问题工程化才是在没有流程的情况下直接让 WorkBuddy 写功能最大的问题是它每个功能的局部代码都合理但整体却在不断漂移。今天让它加一个分类统计它顺手改了数据模型明天让它修一个同步 bug它又把另一个文件的接口地址换掉。你单独看每个 commit 都觉得没问题合在一起却越来越接近一个“看起来复杂、跑起来玄学”的系统。我这次把项目强行拆成两个边界一是阶段边界二是交付物边界。六个阶段依次是准备与规则、契约与架构、功能开发、集成与调试、测试与安全审查、上架与发布。每个阶段必须有明确的出口标准前一个阶段的产物没有确认绝不允许进入下一阶段。1.2 六阶段总览和产出物阶段核心任务必须产出的东西对应主要风险1. 准备与规则搭工作台、定义规则、梳理需求项目说明、阶段规则、验收标准规则混乱、上下文丢失2. 契约与架构定数据模型、接口约定、依赖策略架构决策记录、接口契约、依赖说明架构漂移、前后端割裂3. 功能开发按任务拆解实现功能可运行代码、测试用例骨架UI 风格不统一、隐性 bug4. 集成与调试真机运行、多端编译、联调修复记录、自测截图真机空白、调试残留5. 测试与安全功能验证、权限与隐私检查测试报告、权限清单、密钥扫描结果测试盲区、发布材料缺失6. 上架与发布商店素材、审核、发布后回归商店文案、上架包、回归清单素材不过审、回归破坏这个表看着简单但每一个产出物都是我在踩坑之后才补上去的。后面的章节会具体讲每个阶段是怎么落地的以及对应的坑到底长什么样。1.3 阶段规则比全局规则重要得多我一开始给 WorkBuddy 写了一套很大的全局规则包括“代码必须干净”“不要乱改依赖”“遇到问题先问”之类。结果发现全局规则在阶段一有用到了阶段三就开始拖后腿。比如“遇到问题先问”这条规则导致它在开发阶段每改一个函数都要停下来确认效率极低。后来我把规则改成按阶段加载准备阶段的规则强调“只梳理不写码”开发阶段的规则强调“按契约实现不要扩展”测试阶段的规则强调“用证据说话”。这个改变是项目后期效率提升的最大因素。2. 前三个坑全在准备期规则、上下文和验收标准2.1 坑 #1全局规则一锅端各阶段互相打架这是整个项目踩的第一个坑。我把所有规则写在一个文件里给 WorkBuddy 加载以为“规则越多越安全”结果适得其反。具体表现是设计阶段它因为“不改现有代码”的规则而过度保守不敢给出重构建议开发阶段又因为“保持代码整洁”的规则而频繁顺手重构无关模块。解决方法是把规则按阶段拆开每个阶段加载对应的规则文件。我最后落地的规则文件大概是这样的结构# 开发阶段规则phase3_rules.md - 只实现 README 中标记为“当前任务”的功能 - 不改动与当前任务无关的模块 - 数据字段必须符合 contract/api_schema.yaml - UI 样式必须引用 design_tokens.dart 中的定义 - 报错时先贴日志再贴修复方案禁止静默修复提示全局规则适合定义底线阶段规则才适合定义行为。底线规则建议控制在 5 条以内阶段规则则要足够具体让 AI 不需要猜。这个坑的教训是AI 工作台上的“规则”不是装饰它本质上是你的开发流程描述文件。规则写不好后面每一步都在给这个错误买单。2.2 坑 #2上下文全靠对话里扔没过多久就“失忆”搭建项目前期我习惯把需求文档直接贴在对话里以为 WorkBuddy 会自己记住。但它面对长上下文时有两个典型问题一是记不住早期讨论中确定的细节二是当对话轮次变多之后它会把“讨论过程中的备选方案”当成“最终决定”。我的解决方案是建立一个“项目小抄”文件所有关键决定都同步到这个文件里每个新任务开始时先让 WorkBuddy 读取这个小抄。小抄内容包含项目一句话定义多成员家庭记账应用核心是“快记 月度账单 多端同步”技术栈决策前端 Flutter后端 FastAPI数据库 PostgreSQL部署用 Docker当前阶段的入口文件路径哪个文件是全局入口、哪个文件是路由表已经否决的方案例如“不做复杂预算功能”“不做多币种”等避免 AI 重新发明WorkBuddy 这类工具并不缺上下文容量缺的是“结构化记忆”。你让它读文件它就能稳定引用你让它从聊天记录里回忆它就难免张冠李戴。实践下来我把“每个任务开始前强制读取 project_brief.md”写进了阶段规则类似的问题基本消失了。2.3 坑 #3验收标准缺位“做完”和“能用”是两回事这个坑很隐蔽但代价最大。让 WorkBuddy 开发“记账”功能时它说“已完成”但实际只是完成了“添加一条记录”的入口和列表展示编辑、删除、分类汇总、空状态这些全都没做。它认为“核心链路跑通就是完成”而我认为“完整功能链走完才是完成”。不是 WorkBuddy 偷懒而是我没有给出验收标准。后来我养成了一个习惯任何功能任务都必须附带一份验收清单并且明确把验收清单放在规则中。像这样功能添加记账条目 验收标准 - 输入金额、分类、备注后可保存 - 保存后列表立刻刷新无需手动下拉 - 金额为负或为 0 时给出明确提示 - 断网状态下保存失败时保留用户输入内容 - 以上 4 条全部通过才算完成注意“验收标准”不是测试用例而是行为边界。AI 拿到它之后会在实现前先对照边界检查自己是否理解到位。这段经历让我意识到在 AI 协作开发中“定义完成”是人的职责。你不定义完成AI 就会用自己的最低标准来定义。3. 契约阶段别让 AI 的自由发挥变成架构灾难3.1 坑 #4AI 对“合理重构”的冲动防不胜防进入开发阶段后我遇到一个奇怪现象后端服务的路由命名风格总在变一会儿用create_entry一会儿用add_record前端组件的目录结构也开始分层混乱。查了半天发现WorkBuddy 在不同的任务里会根据“当前场景最合理”的判断顺手做局部重构结果整个项目的架构风格被越拉越散。后来我在契约阶段增加了一份架构决策记录ADR把关键约定写死并明确告诉 WorkBuddy结构性变更必须先记录到 ADR经过确认才能实施。ADR 里的核心条目包括路由命名规范统一用资源名 动作比如POST /entries目录结构前端按功能模块分目录不按类型分目录状态管理方案统一用 Riverpod不允许局部引入其他方案数据访问所有数据库访问走 repository 层业务代码不得直接写 SQL这条规则加上之后架构风格才稳定下来。AI 本身没有“一致性偏好”它只有“局部最优偏好”你不想办法约束一致性它就会每天给你一个“局部最优但全局混乱”的版本。3.2 坑 #5前后端各自美丽接口契约靠“默契”这是一个经典问题WorkBuddy 前端任务和后端任务是两个独立会话两边各自生成后的代码接口字段经常对不上。最典型的一次是后端返回{ entry_id: 1 }前端却读取entry.id页面白屏了半小时我才发现。我采取的办法是在契约阶段先把 OpenAPI 风格的接口文档写出来作为前后端共同引用的唯一契约文件。每一次给 WorkBuddy 派发前后端任务都会明确要求“接口字段必须与契约文件一致”。同时我让 WorkBuddy 根据契约文件生成前后端的类型定义代码从源头避免字段名手写不一致。用 WorkBuddy 生成类型定义有个优势它特别擅长做“从一个 schema 翻译成多种语言代码”这类机械任务准确率远高于让它凭记忆手写接口。3.3 坑 #6依赖管理漂移锁文件形同虚设因为我采用的是“让 AI 装依赖”的策略它有时会用npm install package或flutter pub add来装包导致 lock 文件不断变化版本冲突和本地环境差异开始冒头。最麻烦的是它偶尔还会为了“解决问题”升级某个间接依赖结果其他功能开始报错。解决办法有两层。第一层是在阶段规则中明确新增依赖必须通过项目文档中约定的命令执行并且必须提交 lock 文件。第二层是在 CI 中加一道检查使用flutter pub get时带上锁文件强制校验前端 npm 则用npm ci而非npm install。这套组合拳打下去之后依赖问题基本没有再出现。对于 AI 协作开发来说依赖的“确定性”比“最新版本”重要得多因为 AI 无法理解你项目里所有隐式依赖关系。4. 开发期的隐形坑UI 一致性、真机空白和调试残留4.1 坑 #7没有设计资产每个页面都像不同人做的让我印象最深的是同一套色彩风格列表页用的是蓝绿色按钮设置页又变成蓝紫色甚至圆角值都不一样。原因是 WorkBuddy 在不同任务中会自动“设计”它认为美观的 UI于是产生了设计风格漂移。解决这个问题我在契约阶段增加了一个 design_tokens.dart 文件把颜色、字体、间距、圆角、阴影全部定义成常量。然后规则中明确所有 UI 实现必须引用这个文件不允许在 widget 里写裸颜色值和裸字体大小。这本质上是把“设计系统”压缩到一个 AI 能稳定引用的文件里。提示给 AI 用“设计令牌”比给它“设计规范文档”有效得多。一个是它直接能引用一个是它需要理解后再决定而理解就会带来偏差。4.2 坑 #8构建通过不代表真机能跑白屏是最难忍的坑有一次 WorkBuddy 告诉我“已完成”Web 端打开也正常结果打包到 Android 真机上直接白屏没有任何报错。最后发现是它在某个页面用了一个 Web 平台独有的 API移动端构建时没有报编译错误运行时却静默失败。从那之后我调整了流程凡是涉及页面交互的任务都必须让 WorkBuddy 在提交前附加“真机自测截图”或“模拟器运行记录”。更重要的是我在阶段规则里写了一条涉及平台差异的 API必须标注支持平台并在 commit message 里写出“已验证 Web/Android/iOS 三端”。这条规则让白屏问题彻底销声匿迹。4.3 坑 #9调试日志和 API 地址进了生产包这个坑是发布前差点翻车的关键。WorkBuddy 在开发过程中大量使用 console.log 和 debugPrint这本身没问题但问题出在两个地方一是日志中打印了用户的账单数据二是某个模块的 API 地址还指向本地 localhost。排查时我用了最笨但最可靠的方法让 WorkBuddy 做一个发布前扫描任务用正则匹配所有log、print、debug、localhost、test server等关键字输出一个清单。然后我根据清单逐一确认。实践证明把“扫描调试残留”做成固定任务比任何静态检查工具都来得直接因为 WorkBuddy 能理解上下文能判断“这行日志是不是该去掉”。4.4 坑 #10关键路径只在“开发者的脑子里”项目有很多跨模块关键路径比如“记账后同步到云端”涉及表单校验、本地存储、网络请求、后端写入、状态刷新五层。这类路径在前三周表现得都正常直到我加了“离线保存”功能才发现同步链路里没有做冲突处理数据老是丢。问题的根本原因是我从头到尾都没有把这些链路写成可运行的自测脚本而是依赖对话记忆。后来我把关键路径拆成一份“smoke 测试清单”每次有新改动就让 WorkBuddy 按照清单逐项跑并在最后输出一份带截图证据的测试结果。这个办法让我在后续开发中稳了很多。5. 测试阶段把“AI 的自信”变成白纸黑字的证据5.1 坑 #11一句“你测试一下所有功能”等于什么都没测“把这个功能测一遍”是我前期最常用的指令效果却极差。WorkBuddy 会跑一通快乐路径发现页面能打开、数据能提交就报告“功能正常”但这些测试根本没有覆盖异常输入、权限被拒绝、网络超时、空数据分页这些真实场景。改进方式是让测试任务携带测试用例列表直接把边界条件写进 prompt测试范围记账页的金额输入 测试用例 1. 输入 0 或负数应给出明确错误提示 2. 输入超大数字9999999应做范围校验 3. 清空备注后保存应允许为空 4. 金额输入非数字字符应被输入限制拦截 5. 保存失败时页面应保留当前输入内容这里有个很关键的逻辑AI 写测试用例的能力很强但主动想到所有边界的能力很弱。你把用例拆到足够细它的执行就会足够可靠。5.2 坑 #12单元测试覆盖率虚高集成链路却从没验证过WorkBuddy 特别喜欢写单元测试因为单元测试目标清晰、反馈快。项目后期单元测试覆盖率一度到了 90%但我还是碰到“添加分类后首页统计没变”的问题。原因是首页统计依赖状态管理容器的联动逻辑单元测试里把每个模块单独 mock 掉了真实联动没人管。引入集成测试之后我让 WorkBuddy 只关注三个核心链路记账链路、同步链路、统计刷新链路并且这些测试必须跑在真实模拟器环境里不 mock 数据层。这不代表单元测试没用而是对“能上线的 App”而言集成链路才是生命线。5.3 坑 #13权限和隐私这类“审核向”材料AI 不会自己思考到这一步才发现之前所有代码层面的工作都做完了但上架应用商店还需要权限说明、隐私政策、审核备注。WorkBuddy 不会主动帮你考虑这些因为它没有“上架审核”的心智模型。我通过一个任务让它生成权限清单和隐私政策草稿。权限清单用表格呈现包含权限名、用途、调用时机、涉及用户数据字段这样我一眼就能判断哪些权限是必要的哪些是冗余的。权限用途调用时机涉及用户数据网络访问数据同步启动同步时记账条目本地存储离线缓存保存条目时记账条目提醒通知月度账单提醒用户开启后无这里提醒大家一句话应用商店审核最喜欢的不是“功能强大的 App”而是“权限透明、文案清晰”的 App。AI 能帮你起草但审核材料的最终责任永远在开发者本人。6. 上架阶段最后 100 米反而是翻车重灾区6.1 坑 #14商店素材文案写得像“开发日报”App 商店的标题、副标题、描述、截图文案决定了用户下载前的一瞬间是否会停留。WorkBuddy 第一次生成的描述是“一款基于 Flutter 的跨平台记账应用”这完全是从开发者视角写的冷冰冰且没有用户价值。我重新给了它一个素材任务要求写三种不同风格的文案并明确规定描述里必须出现用户收益、使用场景、和同类的差异点禁止出现技术栈名词。最后选中的版本大概是“和家人一起记账月底自然知道钱去哪了”。这就是用户视角和开发者视角的差别AI 不会自动切换视角你得给它切换指令。6.2 坑 #15环境残留进上架包发布前一刻还在抓 bug上架前的最后一次打包检查中我们抓到一个问题某个页面仍然在请求测试环境的接口。原因是在一个多星期前为了联调方便代码中写死了测试地址后来忘了改回来。后来我把“发布预检”做成了固定任务在执行完代码扫描之后还要验证三件事API 地址必须是生产域名、调试日志开关必须关闭、测试账号必须不能在正式环境登录。宁可多花十分钟做预检也不要上架后收到用户反馈“App 登录不了”。6.3 坑 #16上线后的第一次回归改一个功能坏了两个老功能App 成功上架后的第三天我推送了一个“导出账单 CSV”的新版本。结果新版本把“月度统计图表”的展示弄坏了。这事让我很憋屈明明加了新功能老功能却被回归测试漏掉了。现在我让 WorkBuddy 在每个新版本任务中自动生成一份“上一版关键功能回归清单”并且以固定 skill 的方式沉淀下来。这个 skill 的逻辑是任何新功能开发完成必须强制验证旧版本核心功能的列表不允许只测增量。这个坑教会我的道理是上线不是终点而是新的起点。AI 开发的迭代速度很快回归风险也随之放大没有回归规则就相当于在高速公路上蒙眼换轮胎。7. 把 16 个坑沉淀成可复用的 WorkBuddy 技能7.1 把“坑清单”做进技能库而不是留在记忆里十六个坑全部踩完后我做了一件更重要的事把它们全部转化为 WorkBuddy 的技能模板和规则片段。比如我创建了一个“发布预检”技能它的输入是项目路径执行步骤包括读取项目配置识别当前环境扫描所有代码中的 localhost、测试域名、调试日志关键词检查权限声明与权限使用位置的对应关系生成一份发布预检报告报告必须包含证据截图和整改建议如果检查到任何一条不通过终止并输出原因以后再做新 App我不需要再把这些经验记在脑子里只需要让 WorkBuddy 加载这个技能它就会按流程执行。7.2 16 个坑速查表每一条都是可以检查的行为规则编号坑行为规则1全局规则互相冲突按阶段加载规则文件2上下文被冲淡维护 project_brief.md任务前强制读取3验收标准缺失每个功能任务附带验收清单4架构风格漂移建立架构决策记录并限制结构变更5前后端契约不一致用统一 OpenAPI 契约约束两端6依赖漂移lock 文件强制校验CI 用锁定模式7UI 风格不统一设计令牌文件统一引用8构建通过但真机不行强制真机运行记录和截图9调试残留进生产发布前扫描调试日志与测试地址10关键路径被忽略关键链路做成 smoke 测试清单11模糊测试指令测试任务附带用例列表12单测虚高集成断裂核心链路跑集成测试不 mock 数据层13审核材料缺失权限清单与隐私政策任务化14商店素材像开发文档素材文案规定用户视角15环境残留上架发布预检三验证16新版本回归破坏旧功能强制上一版核心功能回归清单这张表并不复杂但它是我这次项目能稳定上线的最核心资产。如果你现在也在用 WorkBuddy 或者其他 AI 工作台做项目建议直接拿这张表当参考把它改成你自己的规则文件。7.3 最后说一个我反复用到的小技巧在所有规则里我认为最有用的一条是在关键节点设置人工闸门。WorkBuddy 可以连续写代码、跑测试、生成截图但“能不能进入下一阶段”这个决策我一直坚持自己拍板。比如契约文件确认、验收清单确认、发布预检报告确认这三个节点我会亲自看。原因很简单AI 擅长执行但容易在“接近目标”时给出一份“看起来不错”的结果。人工闸门不是不信任它而是给项目增加确定的节奏感。任何事情只要设定了“必须过一道手”的节点后面出问题的概率就会小得多。这次用 WorkBuddy 搭能上线的 App最大的体会是AI 不是替你省掉工程化而是逼你把工程化做得更清晰。阶段、契约、验收、证据这些词以前我在团队协作中经常说但只有到了 AI 协作开发时我才真正理解它们每一个都很关键。希望这份六阶段、十六坑的经验对你有用也欢迎你在实际项目中把它继续补充完善。