# AI 驱动的开发实战：用 WorkBuddy 构建 多门店商城系统

、为什么选择 AI 辅助开发

一个基于二次开发的多门店 SaaS 平台，代码量庞大——后端六端控制器、服务层、数据访问层、模型层四层架构，前端四套独立 Vue 应用加一套 uni-app 移动端。传统开发模式下，光是理解现有代码结构、定位某个功能的完整调用链路就要花大量时间。

我需要的不是一个"聊天机器人"，而是一个能读懂项目规则、记住历史决策、快速执行的开发伙伴。WorkBuddy 的 .codebuddy 记忆机制和工具链执行能力，正好满足了这个需求。

二、开发规则的建立与严格执行

2.1 项目编码规范

在开发开始前，我在 .codebuddy/memory/MEMORY.md 中写明了完整的编码规范：

后端分层架构（严格四层链路）：

• 控制器继承 AuthController，构造方法注入 Service
• Service 继承 BaseServices，通过 $this->dao 调用数据层
• Dao 继承 BaseDao，封装查询逻辑
• Model 继承 BaseModel，定义表名、主键、关联关系
• 路由 RESTful 风格，Route::group + resource 注册

前端组件规范：

• 根元素 <Card :bordered="false" dis-hover> 包裹
• 表格用 <Table :columns :data :loading>，分页用 <Page class="page-box">
• 弹窗 <Modal :mask-closable="false">，样式 <style scoped lang="stylus">
• API 文件统一放 @/api/，用 request 封装调用

关键红线：

• LOGO/图片素材是版权图，禁止 AI 重新生成，必须原样复制
• 品牌名统一「协企乐」，主色 #059669（墨绿）

2.2 AI 对规则的执行表现

整个开发过程中，AI 严格遵守了上述规范。举几个真实例子：

例1：新增门店热词接口 按规范新建了 app/controller/store/product/StoreProductWords.php，继承 AuthController，构造方法注入 StoreProductWordsServices，在 route/store.php 的 product 分组内注册路由。完全符合四层架构。

例2：门店 DIY 编辑器改造 修改 DiyServices.php 时新增了 saveStoreDiy、delStoreDiy、setStoreStatus 等方法，全部强制 type=5 + store_id 隔离，防止越权跨门店。控制器层用 try-catch + $this->fail($e->getMessage()) 统一异常处理，返回结构保持 ['info'=>$data] 与 Admin 端一致。

例3：菜单配色统一 用户要求"所有后台颜色改成墨绿 #059669"，AI 分两层执行：

1. 主题变量层：改四端 default/index.less 覆盖 iView @primary-color
2. 硬编码层：用 Node 脚本批量替换 312 个文件 1336 处蓝色硬编码

并且跳过了登录页（深色底保留翡翠绿 #34D399）和商品颜色选择器色块（非主题色），这种细节判断体现了对规则的深度理解。

三、Token 消耗极低的秘密：记忆系统

3.1 三层记忆架构

WorkBuddy 的 .codebuddy/memory/ 目录是 Token 效率的核心：

3.2 实际节省效果

举一个真实场景：门店 DIY 列表查出多条数据的问题。

第一次排查时，AI 读了代码、查了数据库、定位到 BaseDao::search() 丢失 store_id 字段，花了大量 Token 分析根因。整个过程写进了 2026-08-18.md：

BaseDao::search($where) → withSearchSelect() 只取模型定义了 searchXxxAttr 搜索器的字段，无搜索器的普通字段（如 store_id）被丢弃。

后续会话遇到类似的多租户查询问题，AI 直接从记忆文件中读到这条经验，无需重新排查，Token 消耗趋近于零。

3.3 累积的知识库

两个月的开发，.codebuddy/memory/ 积累了：

• 11 篇日开发日志（7月14日 — 8月18日）
• MEMORY.md 长期记忆：包含技术栈规范、一号通移除改造、需求文档进度、已知问题记录、GBK 编码修复、uni-app 分包优化等
• 90+ 个 temp_scripts 脚本：每个都有对应日志记录用途和执行结果

这些记忆让 AI 每次会话都"带着前两个月的经验"开工，而不是从零开始。

四、开发速度：从需求到上线的高效闭环

4.1 典型开发节奏

以门店端 DIY 编辑器全链路改造为例，一次会话完成了：

1. DIY 列表空数据修复——定位到 $storeId 属性重复声明覆盖父类（10分钟）
2. "选择链接"弹窗报错修复——$refs 判空 + 复用 Admin 端 PageLink 逻辑（15分钟）
3. 选项卡去掉微页面——改 nav_bar.vue + home_comb.vue + c_tab_list.vue（10分钟）
4. 图片链接限制为商品分类+详情——新增 filterTypes prop + 白名单过滤（15分钟）
5. 热词接口 404 修复——新建控制器 + 注册路由（5分钟）
6. 全量 admin 残留排查——3类问题（路由跳转/Vuex namespace/死代码）共修复 20+ 文件（20分钟）

一次会话，6个功能点，20+文件修改，全部完成。 传统方式这至少需要2-3天。

4.2 全量测试数据重建

最体现效率的是测试数据重建任务。用户要求"全量测试，清理所有业务数据后按开发规则重建，密码统一 666666"。

AI 的执行路径：

最终数据规模：

• 20个用户（5级会员 + 分销链）
• 3个门店 + 6个店员 + 3个代理商
• 25个商品（10平台 + 15门店）
• 31条订单（覆盖全状态）
• 16条门店分类 + 5条平台标签 + 3个门店DIY
• 12条客户名单 + 6条账期 + 6条专属价 + 9条月账单

整个过程，AI 自动处理了多个技术坑：

• Authori-zation Token Header（非标准 Authorization）
• 用户端密码 md5() vs 管理端 password_hash(bcrypt) 的差异
• 运营模式 shop_operation_type=1 下商城只展示 type=0 平台商品
• 商品规格结果表 bd_store_product_attr_result 缺失导致详情页报错

4.3 出错后的快速修复

测试数据重建后，用户反馈"门店菜单数据怎么没有了"。AI 在同一会话内完成了：

1. 诊断：菜单数据完好（88条），真正误删的是两个配置类表
2. 恢复平台商品标签 5 条
3. 恢复门店商品分类 16 条（含子分类层级）
4. 修正 10 个商品的 store_cate_id 引用
5. 修正店员 level=0（超级管理员）
6. 重新初始化门店 DIY
7. 回归验证 11/11 通过

从发现问题到修复完成，一个会话搞定。

五、真实开发数据

5.1 脚本清单

temp_scripts/ 目录累计 90+ 个 PHP 脚本，分类清晰：

5.2 开发日志统计

5.3 接口测试覆盖

全量测试 66 个用例覆盖四端：

唯一失败项是 nginx SPA 兜底把 API 404 吞成 HTML，属于服务器配置问题，非数据问题。

六、核心体验总结

便利性

一句话描述需求，AI 完成全链路开发。 从后端控制器到前端页面，从数据库 SQL 到路由注册，从代码编写到测试验证，AI 都能自主完成。我只需要审查结果、提出修改意见。

最典型的例子是"所有后台颜色改成墨绿"——一句话触发 312 个文件 1336 处替换，还包括主题变量层和硬编码层两层处理，以及登录页/商品色块等需要跳过的细节判断。

Token 消耗

记忆系统是 Token 效率的关键。 .codebuddy/memory/ 让 AI 每次会话都带着历史经验开工：

• 项目规范写在 MEMORY.md，不用每次重复描述
• 当天工作记录在日期日志里，跨会话无缝续接
• 踩过的坑有记录，同类问题不重复排查
• 90+ 脚本有日志索引，需要时直接复用

实际感受是：随着开发推进，Token 消耗不升反降——因为知识库越来越丰富，AI 需要探索的未知越来越少。

速度

一次会话完成传统开发2-3天的工作量。 关键在于 AI 能并行处理：

• 同时读取多个文件理解上下文
• 同时执行多个脚本（探针+修复+验证）
• 批量文件操作（Node 脚本批量替换）
• 自动生成测试脚本并执行验证

门店 DIY 编辑器改造那次会话，6个功能点 20+文件修改，从开始到完成大约1小时。全量测试数据重建（99张表清理+7个脚本重建+66个接口测试），也是一个会话内完成。

规则遵守

AI 严格遵守了项目的每一项开发规范：

• 后端代码严格走 Controller → Service → Dao → Model 四层链路
• 前端组件统一用 iView 组件库 + scoped stylus 样式
• 路由 RESTful 风格，命名规范统一
• 多租户隔离（store_id 强制过滤）
• 版权素材原样复制，不重新生成
• 品牌名、主色统一执行

甚至在遇到框架特有的坑（Authori-zation Header、BaseDao::search 丢字段、iView 手风琴失效）时，AI 也能自主排查根因并修复，而不是绕过问题。

七、一些建议

给同样准备用 AI 辅助开发的同行几点建议：

1. 先写规范再开工。 在 .codebuddy/memory/MEMORY.md 中写清楚项目的技术栈、分层架构、命名规范、红线禁忌。这份规范会被 AI 每次会话加载，是一切规则遵守的基础。
2. 坚持写日开发日志。 每天的工作记录是 Token 效率的护城河。记录的越详细（包括根因分析、关键认知、踩坑教训），后续会话节省的 Token 越多。
3. 让 AI 执行脚本而不是纯对话。 AI 的价值在于能读写文件、执行 PHP/Node 脚本、操作数据库。把需求转化为"执行这个脚本并验证结果"，比纯文字讨论效率高几个数量级。
4. 出问题不要慌，先查日志。 AI 的记忆文件里往往已经有类似问题的排查记录。比如"门店菜单数据丢失"那次，AI 先诊断确认菜单数据完好，再定位到是配置类表被误删，整个排查过程基于历史经验快速完成。
5. 测试数据要幂等可重跑。 seed 脚本开头做 DELETE 清理，保证可以反复执行。字段用 SHOW COLUMNS 动态核对而不是凭记忆。这些都是 AI 在实践中总结并记录的经验。

结语

两个月的开发，原始系统演进为支持多门店运营、代理分销、DIY 装修、专属定价、月结账期的完整 SaaS 平台。这个过程中，AI 不仅是代码生成器，更是项目知识的积累者和开发规则的执行者。

Token 用量少、速度快、规则遵守严格——这三点不是营销话术，而是记忆系统 + 工具链执行 + 规范前置带来的真实效果。当 AI 带着两个月的项目记忆开工时，它已经不是"一个新来的实习生"，而是"一个熟悉项目的开发者"。

这或许就是 AI 辅助开发的正确打开方式：不是替代人，而是让人的开发规则和经验以可执行的方式沉淀下来。