比如：

• 拿到一个需求，需要先整理需求和开发步骤；
• 接口文档看完后，还要自己转换成 TypeScript 类型；
• 已经有类似页面，却需要重新搭一遍代码；
• 遇到一个报错，需要在浏览器、项目代码、文档之间来回切换；
• 写完代码以后，还要自己检查类型、逻辑和边界情况；
• 一些重复性的 CRUD、表单、列表页面，写起来更是“机械劳动”。

以前我的做法基本是：搜索 → 阅读 → 思考 → 写代码 → 调试 → 修改。

后来开始尝试使用 WorkBuddy，把 AI 从“问问题的聊天工具”，逐渐变成真正参与开发流程的助手。

这篇文章就分享一下我实际使用中的一套思路：如何利用 WorkBuddy 辅助前端开发，把需求分析、代码生成、代码优化和问题排查串起来。

一、我为什么开始使用 WorkBuddy？

先说一个比较真实的痛点。

前端开发中，有很多工作其实不需要特别复杂的技术能力，但需要大量上下文。

例如产品给过来一个需求：

增加一个用户列表页面，需要支持搜索、分页、新增、编辑和删除。

如果完全自己做，通常需要：

• 分析需求；
• 设计页面结构；
• 确定组件拆分；
• 定义接口类型；
• 写 API；
• 写列表；
• 写搜索表单；
• 写分页；
• 写新增/编辑弹窗；
• 处理 loading、empty、error 等状态；
• 最后自己测试。

真正耗时间的并不一定是“写代码”本身，而是这些事情之间不断切换。

所以我使用 AI 的核心目标并不是简单地说一句：“让 AI 替我写代码。”

更准确的表达其实是：

让 AI 帮忙接手那些重复、机械的工作，把更多时间腾出来，留给真正重要的事。

这也是我觉得 WorkBuddy 比单纯聊天式 AI 更适合进入开发工作流的原因。

二、先让 WorkBuddy 理解项目，而不是直接让它写代码

这是我使用 AI 辅助开发后最大的一个变化。

以前我可能直接问：

“帮我写一个 Vue3 用户列表页面。”

这样得到的代码虽然可能能运行，但很容易出现一个问题：

代码和当前项目风格完全不一致。

比如我的项目可能使用 Vue3 TypeScript Pinia Axios，但 AI 给出来的代码却使用了另外一种组件库或者完全不同的目录结构。

所以我现在更倾向于先让 WorkBuddy 理解当前项目。

我的做法

首先把项目打开，然后告诉 WorkBuddy：

请先分析当前项目的技术栈、目录结构、状态管理方式、接口请求方式和组件使用习惯。

暂时不要修改代码。

先告诉我：

• 1. 项目使用了哪些主要技术
• 2. 页面通常放在哪里
• 3. API 请求通常如何封装
• 4. TypeScript 类型通常如何定义
• 5. 项目中有没有可以参考的类似页面

让 AI 先分析，再开始开发。

因为 AI 最怕的不是不会写代码，而是不了解你的代码上下文就开始写代码。

三、让 WorkBuddy 帮我分析需求

确定项目结构以后，再把具体需求交给它。

例如：

现在需要增加一个用户管理页面。

• 需求：
• 1. 展示用户列表
• 2. 支持用户名搜索
• 3. 支持手机号搜索
• 4. 支持分页
• 5. 支持新增用户
• 6. 支持编辑用户
• 7. 支持删除用户

请先不要写代码。

先结合当前项目的实现方式，帮我拆解这个需求，并告诉我：

• 需要新增哪些文件
• 哪些现有组件可以复用
• API 需要哪些接口
• 页面需要哪些状态
• 实现顺序是什么

这个阶段我不会急着让 AI 输出大量代码。

原因很简单：

先确定方案，再写代码，返工成本更低。

而且通过这一步，还可以发现需求中一些容易遗漏的问题。

比如：

• 删除是否需要二次确认？
• 编辑和新增是否共用一个弹窗？
• 搜索条件变化后是否需要重置分页？
• 接口请求过程中是否需要禁止重复提交？
• 列表为空的时候怎么展示？
• API 返回的数据结构是什么？

这些问题如果一开始就考虑清楚，后面开发会顺很多。

四、让 WorkBuddy 根据项目现有代码生成，而不是凭空生成

确定方案以后，就可以进入真正的代码阶段。

这里我比较推荐一个原则：

给 AI 一个“参考样板”。

例如项目里面已经存在一个结构非常类似的页面：

src/views/user/UserList.vue

src/api/user.ts

src/types/user.ts

现在要做一个新的订单管理页面。

我不会直接说：

“帮我写订单管理页面。”

而会告诉它：

请参考当前项目中的 UserList.vue、user.ts 和相关类型定义。

按照项目现有的：

• 页面结构
• API 封装方式
• TypeScript 类型写法
• 表单组件使用方式
• 分页处理方式
• 错误处理方式

实现 OrderList 页面。

不要引入新的技术方案。

不要修改现有 User 模块。

如果发现需求存在不确定的地方，先告诉我。

这样生成出来的代码，通常会比那种“凭空写出来”的结果可靠得多。

最后总结

如果刚开始用 WorkBuddy，最好别一上来就直接让它：

“帮我完成整个项目。”

更推荐从一个小任务开始。

比如：

• 第一阶段：让它分析项目。
• 第二阶段：让它生成 TypeScript 类型。
• 第三阶段：让它辅助写一个简单页面。
• 第四阶段：让它根据报错帮助定位 Bug。
• 第五阶段：让它 Review 自己写的代码。

等你逐渐找到适合自己的工作方式之后，再把多个步骤串起来。

我认为 AI 编程工具真正的价值，并不是让开发者“不写代码”，而是：

减少低价值的重复工作，把开发者从机械劳动中释放出来。

这可能才是 WorkBuddy 对日常开发最实际的帮助。