我记得很清楚，那个想把内部工具改成 App 的念头，是在一个周日下午冒出来的。需求本身不复杂：一个能录入信息、能浏览记录、能导出报表的移动端页面，团队几个人装上就能用。按老办法，我至少得花两周时间搭脚手架、配环境、联调、打包。但那次我换了个思路——把从需求到上线的整条链路都交给 WorkBuddy 这种 AI 代理类工具去干。最后的结果是六个阶段、十六个坑，外加一份我现在每次做新项目都会复用的方法论。这篇文章就把这段过程完整写出来，包括每一步怎么走、坑是怎么踩进去的、怎么爬出来的，给准备用 AI 工具接手真实项目的朋友做个参考。

1. 六个阶段：为什么按这条路走

先说清楚 WorkBuddy 的定位。它和普通代码补全工具、聊天式问答工具最大的区别，在于它能自己动手干活：自己打开终端、执行命令、读报错日志、改文件、跑测试。从工作方式上说，它更像一个坐在你旁边、会调校完整开发工具链的实习生，而不是一个只会“说答案”的搜索引擎。同样是“生成一个 App”，聊天工具只会给你一段代码让你自己编译，WorkBuddy 会真的把工程建出来、把依赖装好、把构建跑起来，然后根据报错反馈继续自我修正。这个“自己能试错、能看日志、能改代码再重跑”的能力，是整个六阶段流程能成立的前提。

1.1 为什么选 WorkBuddy 而不是手写

我在选型阶段对比过三类方案：纯手工搭建；用低代码平台拖拽拼装；以及这种 AI 代理工作台。

纯手工最可靠，但时间成本对一个“内部工具级”需求来说太高。低代码平台胜在快，可一旦要加自定义权限、特殊页面交互、私有接口对接，往往卡在平台的框架里动弹不得。WorkBuddy 这类代理工具刚好卡在中间：它不限制技术栈，写出来的就是标准工程代码，随时可以换人接手；同时它又把大量重复劳动，比如建目录、写模板、改配置、查报错，都自动化掉了。个人开发者和两三个人的小团队，是最适合的受众。企业级大项目当然也能用，但需要更强的工程纪律，这篇文章里很多坑都属于这一类。

1.2 六个阶段路线图总览

这套流程我最终固定在六个阶段，每个阶段有明确的交付物：

这六个阶段不是拍脑袋定的。它背后有个很现实的原因：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;scheme=https;package=com.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 环境与配置区

这四个坑是“底层保障”，基本不影响写代码本身，但任何一个出问题，后续任务都会莫名失败。我印象最深的是那个磁盘占满的坑，报错显示“编译失败”，其实只是 C 盘没空间了。那次以后，我把进度条项目都用独立的缓存盘，再也没遇到过。

5.2 提示与规则区

这一组坑的核心原因是“沟通颗粒度”。我看过太多人把 AI 代理当成一个全知全能的老程序员，扔一句“做一个能用的商城后端”就撒手不管，最后拿到一个谁也不敢跑的项目。这不能怪工具，只能怪任务拆分做得不好。你给的信息越模糊，输出就越随机。这就是规则存在的意义。

5.3 代码与依赖区

这里多说一嘴第十个坑。Gradle 报“could not resolve all task dependencies”时就特别典型，很多情况下就是一个依赖用了范围版本。依赖解析的结果因人而异、因机器而异，今天能装上明天装不上。固定版本号是一个看起来很笨但实际极其稳妥的习惯。代码领域没有那么多惊喜要给，可复现才是硬道理。

5.4 调试与发布区

第十四个坑特别值得展开：不要让 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 把代码改坏，后来发现它带来的最大好处是“每次都能胆大包天地让它去试错了”，因为反正错了可以随时扔。这个习惯我真心推荐给所有准备上手的人——勇敢地把活交给代理，但一定要留好“后悔药”。