做了一年多AI辅助开发我踩过的坑可以写满一张A4纸。这次用 WorkBuddy 从零搭一个能上线的 App目标很朴素不依赖纯手工敲代码但也要保证最终产物能过审、能跑、能维护。现在回看整个过程项目走了六个阶段记录下十六个坑和一套可复用的经验。这篇东西不是产品文档是我自己在真实开发里一点一点试出来的流程适合那些正在用 WorkBuddy 或类似AI工作台工具做正经项目的朋友。先说清楚 WorkBuddy 在我这里扮演的角色。它负责把任务拆得足够细、把规则定得足够死、把产出盯得足够紧真正的代码生成配合 CodeBuddy、Cursor 这些编程工具完成。WorkBuddy 更像一个懂流程的项目经理加上一个带记忆的规则引擎。它不会替你写代码但它能逼着你按顺序做事也能把每次任务里的约束条件记住下次生成直接复用。理解了这一点后面的六个阶段才走得通。1. 六个阶段从想法到上架1.1 阶段一需求梳理与方案选型这个阶段的核心不是写代码而是把“想做什么”翻译成“系统该怎么做”。我当时第一件事是打开 WorkBuddy建了一个新项目工作区把需求用自然语言全部倒进去目标用户是谁、核心功能有哪些、要不要登录、数据存本地还是上服务端、要不要分享、要几个平台。WorkBuddy 会把这些内容整理成条目还能反向追问模糊点。这个动作别嫌麻烦它决定了后续 Skill 和规则怎么配。需求清单出来后我开始做技术选型。这里给个实用建议如果只是工具型产品优先考虑跨端方案如果涉及复杂原生交互老老实实走原生或混合开发。WorkBuddy 本身不限制技术栈但它的 Skill 库对 Web 类和跨端项目支持最好。我这次选的是跨端框架加原生壳原因后面讲。方案确定后我把技术选型、目录结构、接口风格全部写成一份约束文档再把它转成 WorkBuddy 的规则文件。这一步相当于给 AI 划了边界。没有边界的 AI 生成代码三天后你就看不懂它在写什么。1.2 阶段二环境搭建与项目初始化环境这块WorkBuddy 提供了一个我特别看重的功能项目模板和依赖清单管理。在 WorkBuddy 里建任务时可以指定项目类型它会生成一份初始化清单包括需要安装哪些依赖、用什么包管理器、启动命令是什么。我照着清单在一个干净目录里初始化项目没有自己东装一个西装一个。这里要特别提醒依赖版本尽量锁定不要用“latest”。AI 生成的代码有时候会依赖某个具体版本的新特性你这边装了新版本那边 API 变了就出现一堆让人头大的错误。WorkBuddy 的规则里也可以写死版本范围比如“本项目使用 React 18.x不使用 19 的新 API”。项目初始化后需要配置环境变量。我需要接入一个后端服务WorkBuddy 规则文件里有环境变量占位实际值放在本地 .env 文件里并且这个文件在提交时要从仓库里排除。这个动作很朴素但它避免了后面安全审计时的大坑。1.3 阶段三核心功能开发与 AI 辅助编码这是我的主体开发阶段。WorkBuddy 配合 CodeBuddy 或 Cursor流程是这样的我写一个任务描述放到 WorkBuddy 的任务队列里。WorkBuddy 根据我预先定义的一系列规则把大任务拆分成若干小步骤。每个小步骤包含明确的验收条件。然后 CodeBuddy 读取这些步骤开始生成具体代码。生成完我这边人工跑一遍把结果同步回 WorkBuddy。WorkBuddy 会记录哪些步骤通过了、哪些失败了失败的原因是什么。下一次类似任务出现时它会自动规避已经踩过的坑。听起来很顺实际操作却花了我不少时间在调教上。前几次生成的代码表面能用一旦把边界条件放进去就爆出一堆问题。后来我总结出关键原因任务拆得不够小规则订得不够具体。比如“做一个登录页面”这种描述是不可用的它该被拆成“表单校验规则”“接口调用逻辑”“错误提示状态”“防重复提交机制”“Token 存储方案”五个子任务每个子任务还要给出明确的技术约束。当任务被拆成这种颗粒度AI 代码生成的准确率高了一个量级。1.4 阶段四测试与联调开发完功能后我有一个强烈建议别急着打包先做三轮测试。第一轮是 WorkBuddy 的静态审查。WorkBuddy 可以把当前代码仓库作为上下文加载跑一遍规则检查比如有没有硬编码 API Key、有没有未处理的 Promise、有没有明显的内存泄漏点。这个不是传统意义上的单元测试更像是一个“带着规则表的代码评审助手”。第二轮是单元测试与组件测试。我会让 CodeBuddy 根据 WorkBuddy 生成的验收条件输出对应的测试用例代码。这里要相信 AI 生成测试的能力它比生成业务代码更稳定因为测试的输入输出边界很明确。我跑完之后把通过的测试用例留在仓库里作为回归保障。第三轮是手动真机测试。这也是我踩坑最多的地方。模拟器上很正常的布局真机上出现刘海屏适配问题测试环境正常的流程真机弱网状态下直接卡死。这些问题不能靠 AI 发现必须拿真机跑一遍。我建议至少准备两台不同系统的设备覆盖主流屏幕尺寸。1.5 阶段五安全审核与合规准备上架前最磨人的环节不是开发是安全与合规。我这次给 WorkBuddy 配了一套安全审计规则它会在发布前自动扫描几类问题权限声明是否对应功能、隐私政策是否覆盖数据收集行为、日志中是否出现敏感字段、网络请求是否都是加密连接。别小看这套扫描很多开发者被应用市场拒审不是因为功能有问题而是因为隐私政策写得和实际行为对不上。数据存储方面我强制要求所有用户数据必须加密后再落盘。图片、缓存这类非核心数据也要做基本校验避免非法文件混进来。这个习惯在后期帮了大忙。软件著作权和合规资质也要提前弄。如果你上线的是工具类 App通常软著就够如果是内容社区或金融类前置条件更多。这个阶段别拖因为软著申请有周期等你要上架了才想起来就白白耽误两三周。1.6 阶段六上架发布与持续迭代上架不是终点是另一个循环的起点。我把发布流程也交给了 WorkBuddy 管理。它会列出需要准备的清单应用图标尺寸、截图数量、隐私政策链接、版本号设置、签名文件路径。每一项做完了就打勾。这样微臣不容易漏东西。正式包上传后我给自己设了一个规则首周每天看一次崩溃日志和用户反馈任何崩溃率异常都要当天定位原因。后续版本迭代时WorkBuddy 的上下文记忆就发挥作用了。它会记住历史任务里的教训比如“上个版本改了支付回调导致重复扣款”那么新任务里只要涉及支付模块它的规则会自动带上“必须处理回调幂等”这个条件。2. WorkBuddy 的核心配置心法2.1 Skill 到底该怎么写WorkBuddy 的 Skill 机制可能是我觉得最有用、也最容易被用歪的功能。简单说Skill 是一段结构化指令里面包含提示词模板、输入输出约定、限制条件和过程步骤。它相当于给 AI 一个“工作说明书”。我一开始写的第一个 Skill 是用来生成注册登录模块的写完发现效果很差生成的代码风格和项目完全不一致。后面我把项目里已有的代码片段喂给它做参考限定它必须遵循现有目录结构并且必须导出到指定文件路径效果才变得可用。一个合格的 Skill 至少要包含这几部分功能目标、输入参数说明、输出文件路径、禁用写法列表、验收关键词。比如“本 Skill 生成的所有表单组件必须包含 disabled 状态样式按钮必须有点击反馈”。这类具体约束比冷冰冰的“请遵循最佳实践”有用一百倍。2.2 上下文管理与规则约束AI 工具的上下文窗口再大也装不下整个项目的全部历史。WorkBuddy 的做法值得肯定它允许按任务维度管理上下文而不是一股脑把整个仓库丢给模型。我习惯把规则文件分成几个层级全局规则负责编码风格和通用约束项目规则负责当前项目的目录结构和技术选型任务规则负责某一个模块的具体验收条件。这样每次生成代码时WorkBuddy 只会注入当前任务相关的部分不会让无关信息干扰结果。上下文管理这件事很多人忽视但它直接决定 AI 输出的稳定性。我试过一次把全部功能需求都塞进一个任务里跑结果生成的代码结构混乱逻辑串线返工成本极高。后来我就彻底执行“一次任务只做一件事”的原则。2.3 和 Cursor、CodeBuddy 的分工在我的工作流里WorkBuddy、Cursor、CodeBuddy不是替代关系而是协作关系。WorkBuddy 管流程、管规则、管上下文Cursor 在我需要看代码、改代码时提供一个完整 IDE 能力CodeBuddy 专注生成函数级或文件级的代码实现。具体操作中我会先在 WorkBuddy 里创建任务并拆解步骤然后把这些步骤描述作为生成提示词粘贴到 CodeBuddy 或 Cursor 里执行。生成结果跑通后把代码文件路径与测试结果回填到 WorkBuddy 的当前任务状态里。这样一套下来整个项目的历史记录是连续的你可以随时回溯“这个模块当时为什么这么写”。3. 十六个坑逐一拆解3.1 需求与选型阶段的坑坑一需求清单留了太多“到时候再说”。我第一版需求漏了分享功能。开发到一半产品同学说“必须加”结果整个数据模型都要跟着动WorkBuddy 里的任务树也被迫重排。这个教训让我明白需求阶段多花一小时把边界问题问完比开发阶段多花一周返工强一万倍。我建议在 WorkBuddy 里建一个“需求追问清单”每条需求后面附上三个问题什么场景触发、失败怎么办、数据归谁管。坑二低估 AI 生成代码的试错成本。我最初以为有了 AI 辅助就能直线推进后来发现每次都得分摊调 Skill、修约束、清上下文的时间。AI 生成的代码大概有六成能用三成需要小改一成直接推倒重来。这个比例在项目前期和后期差别不大。所以排期的时候不要把 AI 编码当成“免费加速buff”它更多是帮你把重复劳动压缩但思考和验证环节一步都省不了。3.2 环境与初始化阶段的坑坑三依赖版本漂移项目被“latest”坑惨。我中途重新拉了一次依赖结果把某个 UI 库升到了新版本组件 API 发生变化导致十几个文件报错。后来在 WorkBuddy 的全局规则里写死版本号并且安装了依赖锁定文件但凡检测到版本偏差静态审查就会报错。坑四环境变量泄露。有一段时间我为了让调试方便把后端地址直接写进了公共配置里。WorkBuddy 的安全扫描立刻标红。这个问题在国内应用市场上是致命的审核人员会抓到并拒绝。正确做法是所有配置都走环境变量项目仓库里只保留占位文件。3.3 开发过程中的坑坑五Skill 写得像散文AI 根本没法执行。我见过有人把 Skill 写成“希望生成的代码质量高、逻辑清晰、易于维护”这种话这种描述没有任何约束力。AI 只会照着自己的直觉随便写。Skill 里必须有具体到函数名级别的指令比如“用户信息接口必须放在 services/user.ts 中错误码统一使用 ResultCode 枚举”。坑六上下文像通下水道一样乱塞。把整个版本的代码全丢进上下文AI 生成时会捡到一堆无关信号导致改错文件、改错变量。正确姿势是按模块注入。要让一个表单组件生成准确只需把相关类型定义和组件样式契约给它就够了。坑七AI 生成的代码不审查直接合入主干。有一次我图省事把一个 AI 生成的网络层代码直接合入结果发现它对所有异常都只做了 console.log没有对用户做任何提示。这种代码是可以跑的但产品上是不可接受的。WorkBuddy 有一个“审查模式”要求每段 AI 生成代码必须经过规则校验后才能标记为完成这个环节我后期一直保留。坑八把大需求塞给一次生成。我试过一次让 AI 生成完整的“设置页面”包含头像上传、密码修改、消息通知开关、隐私设置、清除缓存五个子模块。结果 AI 生成的代码里五个子模块互相引用状态管理混乱。后来我把设置页拆成五个独立任务每个任务只对应一个子模块质量立刻上来。3.4 测试与联调阶段的坑坑九只测“happy path”。我最初测试时只跑正常流程登录、点按钮、看结果全过就以为没问题。结果后端返回超时、服务端 500、断网重试这些场景全是洞。WorkBuddy 的任务模板里我加了一条规则每个功能任务必须包含“空状态”“弱网”“异常返回”三个测试子任务。坑十真机适配不足。模拟器上看着好的样式到真机上经常位移。Android 上不同机型的刘海屏适配、iOS 上的底部安全区都是得用真机逐台验证的。我建议测试时候把系统字体调到最大看看布局会不会溢出这一步能发现很多隐藏问题。坑十一前后端接口字段没对齐。前端模型和后端接口文档如果有偏差联调阶段就会变成灾难。我在 WorkBuddy 里维护了一份接口契约文件每次后端调整字段都要先改契约再由 WorkBuddy 触发前端类型更新。这个流程看起来多了一个文件实际上省了无数“你传的是 string我收到的是 number”的扯皮。3.5 安全与合规阶段的坑坑十二权限申请和功能不对应。曾经申请了读取位置权限但功能里根本没用后来直接采纳。这种问题很容易被审核发现属于“权限滥用”。 WorkBuddy 的规则里可以配置权限用途说明每个权限项必须绑定至少一个触发场景。坑十三日志信息打得太“慷慨”。我修一个问题时打印了用户手机号差点引发安全事故。日志里出现敏感字段是上架大忌也是隐私合规大忌。发布前用 WorkBuddy 扫描日志输出把敏感信息全部替换成脱敏标识。坑十四隐私政策是“照着模板抄的”。上架审核反馈隐私政策与实际行为不符我只好逐条核对并重写了隐私政策。这件事提醒我隐私政策必须实际描述 App 在做什么不能用模板糊弄。完善的做法是把 WorkBuddy 的权限清单导出来直接对照清单写隐私政策保证“写到的都做了做了的都写了”。3.6 上架发布阶段的坑坑十五签名和证书管理混乱。我的证书过期后调试包还能跑但打包后安装失败。这个坑测试阶段完全暴露不出来只有提审时才发现。WorkBuddy 的发布清单里有一个“证书有效期检查”项建议每次构建前都自动跑一遍能省掉发布当天的手忙脚乱。坑十六发布后缺少监控。第一次上架后以为大功告成结果第三天在应用市场看到一名用户报告闪退我才后知后觉去查。等发现是某个机型的内存缓存问题已经有多位用户受到影响。现在我的规则里有一条硬性要求任何版本发布后首周每日必须查看崩溃日志、启动耗时、用户反馈三个指标。4. 常见问题排查速查表下面这个表是我实际开发中遇到问题后汇总出来的。不想看过程的朋友直接对着排查。问题现象常见原因解决动作编译报错提示找不到某个模块依赖版本不匹配或目录路径写错检查 dependencies 和 tsconfig/eslint 路径配置把版本锁死运行时崩溃报错信息指向第三方库第三方库与当前系统版本不兼容查看版本记录升级或降级库到已验证版本上架被拒理由是隐私政策描述不实隐私政策与实际权限/数据收集行为不符导出租权限清单逐条核对隐私政策内容布局在真机上偏移未做安全区适配或暴力响应式写法使用官方安全区控避免固定像素写死网络请求偶发失败未处理超时和重试在请求层统一增加超时控制与重试机制包体积超标引入大量未使用的依赖或静态资源过大用产物分析工具检查按需引入压缩图片WorkBuddy 任务一直标记失败Skill 指令中存在无法满足的约束查看失败日志逐步放宽其中不可执行的部分AI 生成的代码风格混乱缺少全局编码风格规则添加全局规则限定命名风格、模块导出方式、文件头注释格式App 启动速度变慢大量同步初始化逻辑占主线程把非必要初始化放到子线程减少首屏加载项应用市场提示证书过期签名证书未在有效期或私钥不匹配重新生成证书并配置好自动续期提醒5. 一些实操上的补充心得写到这里我发现能说的细节还有很多但核心经验其实可以浓缩成几句话。第一AI 辅助开发要想稳定最重要的不是提示词写得多花哨而是流程边界定得有多清楚。WorkBuddy 的价值在于把流程固化成可检查的清单让每一步都有依据而不是每次生成完就凭感觉判断行不行。第二越早把规则写进工具里后面节省的时间就越多。我很多规则都是在踩坑之后补的补完就发现同样的坑再没有第二次踩过。最后分享一个自己觉得特别实用的小技巧每个任务完成后在 WorkBuddy 里添加一条“经验备注”。\n比如“这次用 fetch 调接口时发现 Android 端偶尔会触发两次请求需要加 abort 控制”下次遇到同类型任务时这条经验就会自动挂在任务描述里。这个功能在我看来比任何模板都宝贵因为它让整个项目的历史经验持续沉淀整个团队不会因为换人而丢失知识。我用这个方法做了大半年发现越到后面任务执行的成功率越高返工成本越低。这也是我为什么愿意把 WorkBuddy 作为整个开发流程的锚点的原因。