我记得很清楚那个想把内部工具改成 App 的念头是在一个周日下午冒出来的。需求本身不复杂一个能录入信息、能浏览记录、能导出报表的移动端页面团队几个人装上就能用。按老办法我至少得花两周时间搭脚手架、配环境、联调、打包。但那次我换了个思路——把从需求到上线的整条链路都交给 WorkBuddy 这种 AI 代理类工具去干。最后的结果是六个阶段、十六个坑外加一份我现在每次做新项目都会复用的方法论。这篇文章就把这段过程完整写出来包括每一步怎么走、坑是怎么踩进去的、怎么爬出来的给准备用 AI 工具接手真实项目的朋友做个参考。1. 六个阶段为什么按这条路走先说清楚 WorkBuddy 的定位。它和普通代码补全工具、聊天式问答工具最大的区别在于它能自己动手干活自己打开终端、执行命令、读报错日志、改文件、跑测试。从工作方式上说它更像一个坐在你旁边、会调校完整开发工具链的实习生而不是一个只会“说答案”的搜索引擎。同样是“生成一个 App”聊天工具只会给你一段代码让你自己编译WorkBuddy 会真的把工程建出来、把依赖装好、把构建跑起来然后根据报错反馈继续自我修正。这个“自己能试错、能看日志、能改代码再重跑”的能力是整个六阶段流程能成立的前提。1.1 为什么选 WorkBuddy 而不是手写我在选型阶段对比过三类方案纯手工搭建用低代码平台拖拽拼装以及这种 AI 代理工作台。纯手工最可靠但时间成本对一个“内部工具级”需求来说太高。低代码平台胜在快可一旦要加自定义权限、特殊页面交互、私有接口对接往往卡在平台的框架里动弹不得。WorkBuddy 这类代理工具刚好卡在中间它不限制技术栈写出来的就是标准工程代码随时可以换人接手同时它又把大量重复劳动比如建目录、写模板、改配置、查报错都自动化掉了。个人开发者和两三个人的小团队是最适合的受众。企业级大项目当然也能用但需要更强的工程纪律这篇文章里很多坑都属于这一类。1.2 六个阶段路线图总览这套流程我最终固定在六个阶段每个阶段有明确的交付物阶段核心任务交付物一、需求锁定把模糊想法拆成可执行任务一页需求清单 验收标准二、环境与工作区安装工具、配置规则、初始化工程一个能跑起来的空工程骨架三、功能开发用“提示词循环”逐模块实现功能完整、具备核心路径的 App四、调试与打磨处理报错、真机联调、补边界稳定通过测试的可用版本五、构建与签名生成正式安装包签名完成、可安装的包文件六、上架发布提交审核、处理拒绝原因应用成功上线这六个阶段不是拍脑袋定的。它背后有个很现实的原因AI 代理特别容易在“边界不清”的环境里失控。如果需求还没定就让它写代码它会自己给自己编需求越写越 Happy最后交付一个花里胡哨但根本不是你要的东西。环境没有准备好就催它干活依赖装错、路径对不上、构建缓存爆炸一连串问题全部混在一起连人都没法排查更别说代理了。所以顺序必须是先锁范围、再搭底座、然后开发、接着调试、最后发布。一步省掉后面就得多花两三步的代价补。1.3 最关键的一步把需求锁死我在阶段一耗费的时间最多但回报也最大。对于 AI 代理来说可执行的“需求”必须满足三个条件拆得足够小、边界说得足够明白、每一条都带验收标准。我总结了一个简单的模板每个功能都用这个结构写功能[一句话] 页面入口[哪个页面哪个按钮] 核心交互[用户点了会发生什么] 数据来源[本地Cache / 后端API字段有哪些] 成功标准[什么状态算做完什么状态算失败] 明确不做[本次开发不允许碰的范围]比如“信息录入”这个功能我最终拆出来是这样一条功能录入一条员工信息 页面入口首页右上角“新增”按钮 核心交互点击后进入表单页填写姓名、手机号、备注提交到后端 数据来源POST /api/records字段名 name、phone、remark 成功标准返回 200 后自动回列表页并弹“保存成功”提示失败保留已填内容 明确不做不做头像上传不做身份证校验当时我把这个结构发进 WorkBuddy 后它很快就把对应的页面、接口封装和回调逻辑全部生成了。少有的没返工。所以这句话我每次都要强调AI 时代最值钱的技能不是抽象思维是“把需求翻译成边界清晰的执行指令”的能力。这个能力决定你交付物的质量下限。2. 前两个阶段环境准备和第一个可运行骨架很多人大意在这个阶段。以为安装个工具就能开工结果各种硬门槛和配置问题直接把后续所有任务给卡住了。我在这个环节一共踩了三个坑其中有两个是靠 WorkBuddy 自己排掉的但我印象还是很深——因为它们是那种“一眼看去与代码无关却真实阻断后续所有操作”的坑。2.1 安装时的硬门槛版本、系统和安全审核WorkBuddy 对系统有要求Windows 7 及以下的老机器基本装不上也别想着装老版本绕过去——老版本和现在的模型服务、技能中心并不兼容装上也是残缺功能。建议 Windows 10/11 或 macOS 直接上。另外安装包尽量从官方渠道拿搜索引擎里搜到的“WorkBuddy 教程”里很多是旧版资源站版本不一致会导致一系列匪夷所思的 bug登录失败、技能加载不出来、任务跑到一半闪退。安装完成后第一次启动一般会遇到安全审核或权限确认弹窗。这个环节我的建议是认真读一遍再点同意。因为 WorkBuddy 要自动操作它需要访问工作区文件、执行终端命令、修改系统缓存目录这些权限在弹窗里如果没有授予后面工作起来会各种被系统拦而且报错方式是那种“任务中断但代码生态看起来又没问题”的情况排查起来特别费劲。我个人的习惯是先把默认缓存目录改到一个独立磁盘分区。默认缓存通常放在系统盘App 项目反复构建、安装依赖、生成中间产物体积很快就上去了。有几次我构建到一半直接磁盘满报错而且报错信息非常误导人显示是“编译失败”实际是磁盘空间不足浪费了大量查询时间。2.2 搭工作区让 Agent 从“问一句做一步”变成有章法安装好只是第一步。把工程目录的“运行规则”先定好是我认为整套流程里性价比最高的一件事。我在项目根目录下放了一个工作区规则文件内容长这样# 工作区规则 1. 技术栈固定为 React TypeScript Vite移动端优先 2. 所有 API 请求必须处理 loading 和失败态 3. 每次修改只改一个模块改完先说明结果再动下一个模块 4. 代码注释用中文关键逻辑写明原因 5. 不要引入未确认的第三方 UI 框架 6. 构建和测试命令统一从 package.json 中读取别小看这个文件。规则的核心价值不是“限制”AI而是降低它的随机性。没有规则时Agent 每个任务都可能重新选一套架构今天生成一个页面用 useState 管理数据明天生成同样页面用 zustand后天换 redux。代码风格完全分裂你后续接手时绝对想骂人。有了规则它的输出就收敛了像是给实习生一本团队编码规范即使他经验一般至少不会乱。有一个热搜关键词是“给 workbuddy 定几条规则,后续对所有任务都生效”这其实点到了一个关键功能全局规则和工作区规则是分开的。我建议把“语言风格”“注释习惯”“不引入额外依赖”“先解释后动手”这类通用约束放到全局规则里把“当前项目用什么技术栈、数据接口长什么样”放到工作区规则里。这样全局部分一处配置所有项目受益工作区部分则每个项目有各自特色互不污染。2.3 从空目录到工程骨架工程骨架我用了一段明确的 Prompt 来生成请在当前目录创建移动端优先的 PWA 应用工程。 技术栈React TypeScript Vite。 要求 1. 包含首页、列表页、设置页三个路由 2. 使用 react-router 做路由管理 3. 只搭目录骨架与基础配置不写具体业务逻辑 4. 不安装任何 UI 组件库 5. 用中文注释WorkBuddy 会自己跑npm create vite、装路由依赖、调整目录结构。它会边执行边输出日志你可以清楚看到它改了哪些文件、执行了什么命令。这个阶段我核心看三件事目录结构是否符合预期依赖是否加了不该加的东西路由是否真能跑通。自己动手验证的方式也很简单让它把 dev server 开起来然后我在浏览器里访问一下能看到默认骨架页面就说明通过。整个过程不到二十分钟。要是手工来光那套脚手架和配置折腾一晚上也很正常。从这一步开始我算是真正感受到了代理工具的价值它不是“给你建议”是“亲手把活干到你面前”。3. 核心开发阶段一段提示词循环代替手写这个阶段是整个项目的正文也是十六个坑相对密集的地方。我的做法是彻底放弃“一次性对话生成整个项目”的幻想改用“提示词循环”每个功能拆成多次小迭代每一次迭代都像一次小型的需求到交付的闭环。3.1 一个功能的三层提示需求、边界、验收以一个“信息录入”功能为例。我给 WorkBuddy 的最终 Prompt 长这样现在开始实现“录入信息”功能。 1. 页面包含姓名、手机号、备注三个字段前端校验姓名和手机号不能为空 2. 数据通过 POST /api/records 提交字段名为 name、phone、remark 3. 提交成功后返回列表页并提示保存成功 4. 提交失败时保留已填内容并在表单顶部显示错误原因 5. 不要引入新的 UI 库大家注意这里每一句都规定了行为而不是“做一个信息录入页面”这种大方向。为什么因为 AI 代理在有多个可行方案时会凭“猜测”来选。如果我不说“提交失败保留已填内容”它大概率会做一个清空表单的动作——那在很多真实业务里都是一场灾难。用户填了三分钟的东西因为一次网络抖动全没了这产品基本没法用。浙江这类边界条件是我比较看重的成功路径、失败路径、边界路径。AI 代胞擅长把功能写得很漂亮但“异常情况”是它的盲区。你在 prompt 里不点名它默认不处理。所以每个功能我都强制要求“写清楚失败时怎么办”。更有效的做法其实是“分三轮”第一轮告诉它功能目标它回一份实现方案第二轮把方案贴回去让它修正成“只做这个范围不延伸”第三轮才开始写代码。这样做的好处是能在代码落地前就发现需求理解偏差省掉大量返工。3.2 生成之后我是怎么检查它的代码的有人问AI 生成的代码到底要不要看我的答案是不用逐行看但必须看关键结构和关键函数。WorkBuddy 在执行任务时会列出改了哪些文件。我先扫一眼文件列表确认它没有凭空多出不该有的文件然后让它自己跑一遍类型检查和构建命令保证当前代码能通过编译最后我抽查一两个核心文件的实现逻辑核对是否符合 prompt 中的边界要求。在 WorkBuddy 这类产品中代码检查还可以直接指令化运行 npm run build如果编译失败就只列出第一个 error完整堆栈不超过200行然后分析原因、给出修复方案再动手修复不要一次处理多个错误。这条指令看着简单实际非常关键。AI 代理面对一长串编译错误时有时候会陷入“把所有错误同时修一遍”的思维模式。但真实的软件工程里大量错误只是第一个错误的连锁反应。修完第一个后面一大串自然消失。所以我一直给它规定只处理第一个错误。这个决策把这个阶段的效率提升了不止一倍。3.3 典型交互“从浏览器唤起 App”这件事开发过程中遇到最有趣的需求是做“浏览器唤起 App”这个交互。不少产品都有一个 H5 版本用户在浏览器里浏览时如果 App 已安装希望浏览器能直接唤起 App如果没安装则引导去应用商店下载安装。这个逻辑在 iOS 和 Android 上完全不一样。iOS 上的标准做法是 Universal Link通用链接。它需要你在 HTTPS 域名根目录放一个apple-app-site-association文件并在 App 内配置对应域名关联。比如用户点击https://example.com/open系统会先向该域名请求关联文件验证通过后直接唤起你的 App。Android 上则可以用 App Links 或者意图协议比如intent://example.com/#Intent;schemehttps;packagecom.example.app;end这种写法可以直接在 Chrome 等浏览器里尝试拉起应用失败时可以设置备用的 URL。这些实现细节确实让人头疼。配置格式不对、域名验证失败、浏览器行为差异任何一环都能导致“点了没反应”。我的做法是把对应的平台文档贴给 WorkBuddy让它先检查当前工程有没有做关联配置再按文档生成配置文件。遇到点击不响应的就让它打一条测试链接我在真机浏览器上点把实际行为截图给它让它对照排查。实际工作中还有一个隐形的坑很多浏览器对“自动唤起”做了限制必须要有用户手势事件触发。也就是说你不能一进页面就自动跳必须让用户点一下按钮。这个看似无厘头的规则恰恰是浏览器厂商为了杜绝恶意跳转设置的硬性约束。3.4 代理调试法一次只修一个错调试阶段我给 WorkBuddy 的指令一般长这样运行项目的构建命令只提取第一个 error 的完整堆栈。先不修改代码把错误原因、涉及文件、可能的修复方案列出来确认后再动手。这个流程模仿了有经验的工程师排查 bug 的方式不瞎改先精确定位。有一次项目报could not determine the dependencies of task :app:compiledebugjavawithjavac. could not resolve all task dependencies for configuration :app:debugcompileclasspath这是一个很常见的 Android 构建问题字面意思是“依赖解析失败”。WorkBuddy 用了这个流程先跑./gradlew dependencies --configuration debugCompileClasspath把失败的依赖列出来最终定位到某个依赖版本号写成导致拉取不一致。修复方式简单得让人无语——固定版本号。但如果没有这一步一步的定位直接搜报错信息很可能带你绕进一堆无关的老帖子里。这种“先诊断、后开方、再执行”的方式也是我在这个阶段反复强调的。AI 代理最大的优势是执行最大的劣势是缺乏判断优先级的能力。人需要做的是把“一次只修一个错”的判断准则写进它的执行规则里不然它就变成一只无头苍蝇满屏乱撞。4. 发布前的最后一公里构建、签名与上架功能开发完只是万里长征走了一半。真正拦住大多数人的是发布这个环节。我自己见过太多项目代码跑得挺好的倒在签名文件丢失、版本号冲突、隐私政策缺失这些“非技术问题”上。4.1 构建正式包前的三条红线第一条是签名。Android 的 APK/AAB 需要签名文件.jks或.keystore签名用的密钥别名和密码必须妥善保存。iOS 则需要证书和描述文件。我听过太多人把密钥文件放桌面结果某天清理垃圾顺手删了整个应用无法更新只能换个包名重新发布用户之前装了还不能覆盖安装极其憋屈。WorkBuddy 能帮你生成签名文件但密码保管这个动作我始终没有交给它——这件事必须由人来做。第二条是版本号和包名。包名一旦确定尽量不要改因为它是应用的唯一标识。版本号则要和商店后台一致否则提交审核时会被判定为“版本信息不一致”。第三条是应用图标。大部分工程模板自带的图标是默认的机器人头或空白画布直接拿去提交审核会被商店系统警告。能用 WorkBuddy 生成一个简单图标最好不用惊艳但至少和产品功能相关。4.2 真机调试两小时抵得过模拟器两天我做这个内部工具时直接在连着的 Android 手机上装测试包。测试过的同学都应该有同感真机测试能暴露出非常多在模拟器里藏得严严实实的问题。比如通知权限弹窗的时机、弱网状态下的超时表现、App 退到后台再恢复时的状态保留、不同系统版本上 UI 的适配差异。WorkBuddy 能直接帮我执行真机上的安装和日志拉取把当前构建产物安装到已连接的 Android 手机。 使用 adb install。如果失败把完整错误信息带回来并总结原因。有一次用户反馈 App 闪退我让它抓取本机 logcat 里崩溃堆栈它就能精确把报错的那几行文本提取出来定位到是一个空指针。这个流程以前我抓日志、筛堆栈、翻代码起码半小时现在五分钟不到。4.3 上架审核大多数人倒在最后一关上架审核看起来是流程问题实际上是对产品规范性的考验。我被多个平台打回来过核心原因都高度相似隐私政策缺失权限申请描述与功能不符应用内登录却没有提供测试账号。我的建议是在动手开发之前就把隐私政策和用户协议的两个网页做好挂在有公网访问能力的页面上。审核员真的会点开去看链接打不开、内容空白都是直接拒绝理由。如果应用要申请定位、通讯录、相机等权限必须在隐私政策里写明用途而且在应用内首次申请权限时也要有清晰的弹窗文案。不少开发者嫌麻烦结果审核回来意见比改代码还要费时。如果你做的是公司内部工具不一定非要走公开商店。Android 可以走企业分发通道iOS 可以用 TestFlight 或内部证书。这种情况下审核的重心就变成“内容安全”而不是公开商店的完整审核逻辑。这条利好不少小团队但合规审查仍然不能省略。5. 十六个坑速查表这一节是我最想保留的内容。把它当成一张检查清单每次走完一个阶段回头扫一眼能省掉不少弯路。我把十六个坑按阶段和类型分成了四组每组四到五个给每个坑标注了表现和对应解法。5.1 环境与配置区坑位表现解法1系统版本过旧安装后无法启动或功能缺失按官方要求升级系统不硬装老版本2安全审核弹窗被跳过后期自动化操作被系统拦截首次授权时逐项确认不要一键全部拒绝3缓存目录占满系统盘构建运行中突然失败提前把缓存目录改到独立磁盘分区4登录状态异常、同步失效任务跑到一半断掉定期确认账号登录态和版本一致这四个坑是“底层保障”基本不影响写代码本身但任何一个出问题后续任务都会莫名失败。我印象最深的是那个磁盘占满的坑报错显示“编译失败”其实只是 C 盘没空间了。那次以后我把进度条项目都用独立的缓存盘再也没遇到过。5.2 提示与规则区坑位表现解法5一个 Prompt 包含全部需求生成结果严重偏离目标拆成多轮小迭代每轮只做一件完整的事情6规则只写“不要做什么”AI 在正向操作上依然混乱规则同时包含正向动作和负向限制7没有写验收标准功能写完才发现“不是我要的”Prompt 里强制带上成功标准和失败场景8多次修改后需求参数不统一模块越改越乱每次修改都拿最原始的需求清单比对齐这一组坑的核心原因是“沟通颗粒度”。我看过太多人把 AI 代理当成一个全知全能的老程序员扔一句“做一个能用的商城后端”就撒手不管最后拿到一个谁也不敢跑的项目。这不能怪工具只能怪任务拆分做得不好。你给的信息越模糊输出就越随机。这就是规则存在的意义。5.3 代码与依赖区坑位表现解法9幻觉 API引用了不存在的库或方法构建时才报错每次引入新依赖和函数前先确认存在性10依赖版本冲突两个库要求不同版本导致无法解析固定版本号避免使用范围版本和最新版11工程路径含中文或空格打包脚本执行失败全局统一使用英文路径创建项目12只有成功路径没有异常处理上线后闪退率高Prompt 强制要求处理失败态和边界态这里多说一嘴第十个坑。Gradle 报“could not resolve all task dependencies”时就特别典型很多情况下就是一个依赖用了范围版本。依赖解析的结果因人而异、因机器而异今天能装上明天装不上。固定版本号是一个看起来很笨但实际极其稳妥的习惯。代码领域没有那么多惊喜要给可复现才是硬道理。5.4 调试与发布区坑位表现解法13日志太长AI 分析被不相关信息淹没陷入反复试错强制规定只处理第一个错误堆栈不超过200行14人手动改了代码和 Agent 改动混在一起无法追溯每个阶段用 Git 提交Agent 只用独立分支15签名密钥只在本地存了一份损坏后无法更新应用密钥和密码至少存两处定期备份16上架资料和功能对不上、隐私政策缺失发布前核对商店页描述、截图、权限声明第十四个坑特别值得展开不要让 AI 代理在你手动改过代码的文件上继续动手。我前期犯过这个错一个文件我手改了两个地方又让 WorkBuddy 去改第三个地方结果它基于旧代码做推断直接把我手动改的又改回去了。从那以后我给自己定下规矩要么全交给它要么全自己来混着来一定出问题。每一阶段结束用 Git 打个 tag绝对可靠。6. 沉淀下来的可复用经验项目结束后我把这套方法固化成了模板包括一份启动 Prompt、一组全局规则、一个发布前检查清单。现在每次接新的小项目我都从这套模板开始而不是真的重新从零“思考一遍怎么做”。6.1 一份可以抄作业的启动模板新项目开始我都会把这段话发给 WorkBuddy我需要在当前工作区把一个内部工具做成 App。需求如下xxx 请你先不要写代码只做三件事 1. 把需求拆成一组有序的任务清单 2. 标注每个任务需要我提供哪些信息 3. 列出你对我需求中不明确之处的三个疑问 回答完这些问题之前不要动代码。这一步几乎杜绝了“理解跑偏”。它强迫 AI 以“需求分析员”的身份先对话而不是马上以“程序猿”身份跳进实现细节。实际体验下来AI 提出的疑问往往能反哺需求它关注那些我描述不清晰的地方刚好就是最容易返工的地方。6.2 五个“一劳永逸”的全局规则我给 WorkBuddy 定了一组全局规则后续所有项目都生效。这大概是“六阶段、十六坑”这套经验里最可复用的部分1. 任何任务开始前先说明你的实现方案确认后再动代码 2. 修改只涉及当前任务范围不顺手改动无关文件 3. 每个新依赖使用固定版本号不使用 latest 和范围版本 4. 代码注释使用中文关键逻辑写明“为什么这样实现” 5. 每完成一个里程碑提示我执行一次 Git 提交有人问全局规则和工作区规则要怎么分工我现在的用法是全局规则管“做事习惯”工作区规则管“项目约束”。前者换项目依然有效后者仅针对当前项目。这个分工能避免一个项目上堆太多规则导致 Agent 行动迟缓、畏手畏脚。6.3 哪些环节我还是选择留给人来做话又说回来AI 代理不是万能的。我至少会保留三个环节由人来做需求拆解、数据和权限的合规审视、视觉细节的最终确认。需求拆解是人的判断力数据和权限的合规审视是责任边界绝不能交给模型去“觉得没问题”视觉方面AI 生成的设计往往能看但不耐看细节比例、色彩对比度、不同屏幕上的体验还是需要人眼确认一遍。平台审核她预览时的截图与实际不符还是得靠人去调整。用 WorkBuddy 做项目我的体感一句话总结它的能力边界远比大多数人想象的要高但发挥边界的前提是你的判断力和需求拆解能力要跟上。最后分享一个小技巧每次给 WorkBuddy 开新任务前我都会手动在 Git 里切一个新的分支任务结束后合回主分支然后打一次 tag。这套流程最初只是怕 AI 把代码改坏后来发现它带来的最大好处是“每次都能胆大包天地让它去试错了”因为反正错了可以随时扔。这个习惯我真心推荐给所有准备上手的人——勇敢地把活交给代理但一定要留好“后悔药”。