CRMEB Pro 二开新思路：把后台接口整理成 AI 能读懂的项目知识库
CRMEB Pro 二开新思路：把后台接口整理成 AI 能读懂的项目知识库
摘要
很多 CRMEB Pro 二开项目做到后期，最痛苦的不是功能写不出来，而是“项目知识散落在代码里”：路由在 route 文件，业务在 Services，查询在 Dao，字段语义在 Model 和 SQL，前端菜单又在后台管理端。新人接手时要翻很多目录，AI 辅助开发时也经常因为上下文不足，给出看似能跑但不符合项目分层的方案。
这篇文章围绕一个更实用的方向：如何基于 CRMEB Pro 现有路由、Controller、Services、Dao、Model，把后台接口整理成 AI 能读懂的项目知识库，让后续二开、排查和接口文档维护更稳定。
一、为什么 CRMEB Pro 二开适合先做“AI 知识库”
CRMEB Pro 的模块比较完整，常见业务包括商品、订单、用户、分销、客服、统计、营销活动、门店、供应商等。项目本身已经有清晰的后端分层：
route/admin.php 后台路由入口 route/api.php 用户端接口入口 route/kefu.php 客服端接口入口 app/controller 控制器层 app/services 业务服务层 app/dao 数据访问层 app/model 模型层 crmeb_pro_admin/src 后台前端 crmeb_pro_uniapp/api 移动端接口封装如果直接让 AI 看一个局部文件，它很容易只根据当前代码片段生成方案。但 CRMEB Pro 二开通常要遵守完整链路：
Route -> Controller -> Services -> Dao -> Model所以更好的做法不是“让 AI 猜”，而是先把接口、模块、字段、调用边界整理成结构化知识。AI 看到的是项目上下文，而不是零散代码。
二、第一步：从路由开始抽取接口地图
CRMEB Pro 的后台接口集中在route/admin.php，用户端在route/api.php，客服端在route/kefu.php。这些路由不仅包含 URL 和控制器方法，还经常通过option(['real_name' => '...'])写明接口中文含义。
例如后台订单模块能看到这些入口：
admin/order/list 订单列表 admin/order/chart 订单头部数据 admin/order/write 订单核销 admin/order/refund 订单退款统计模块也有清晰的分组：
statistic/user/get_basic 用户基础统计 statistic/user/get_trend 用户增长趋势 statistic/product/get_product_ranking 商品排行 statistic/trade/top_trade 今日营业额统计 statistic/order/get_channel 订单来源这些路由信息非常适合整理成知识库的第一层：
模块名：订单 接口名：订单列表 请求方式：GET 路由：order/list 控制器：v1.order.StoreOrder/lst 权限说明：后台登录 + 角色权限 + 操作日志 适用场景：后台订单列表、订单筛选、AI 运营分析取数入口这样 AI 在回答“我要扩展订单列表字段”时，就不会只说“去改页面”，而会知道要从路由进入 Controller，再追到 Services 和 Dao。
三、第二步：把 Controller 变成“入口说明”
CRMEB Pro 的 Controller 通常负责三件事：
1. 接收请求参数 2. 调用 Services 3. 统一 success / fail 返回以客服端商品接口为例，app/controller/kefu/Product.php中包含：
getCartProductList 获取用户购买记录 getVisitProductList 用户浏览记录 getProductHotSale 获取用户购买的热销商品 getProductInfo 商品详情这类方法非常适合沉淀成 AI 知识库里的“能力入口”。比如整理成：
能力：客服侧查看用户购买记录 入口：kefuapi/product/cart/:uid 控制器：kefu/Product@getCartProductList 服务层：kefu/ProductServices@getProductCartList 典型用途：客服侧用户画像、AI 导购推荐、售后沟通辅助 边界：必须在客服登录态下访问有了这层说明，AI 做二开建议时就能判断：如果是客服工作台的 AI 导购，不应该直接去查订单表，而应该优先复用客服端已有接口和 Services。
四、第三步：把 Services 识别为业务语义层
CRMEB Pro 二开时，Services 是最重要的业务层。它负责权限判断、状态流转、跨模块组合、事务处理、异常兜底等。
知识库里不要只记录“这个方法叫什么”，还要记录它代表什么业务语义。例如：
StoreOrderServices 用途：订单主业务服务 常见能力：订单列表、订单详情、发货、退款、核销、拆单 二开注意：订单金额、退款、库存、积分、优惠券、分销佣金都可能被影响再比如统计模块：
UserStatisticServices 用户统计 ProductStatisticServices 商品统计 TradeStatisticServices 交易统计 OrderStatisticServices 订单统计这些服务适合被整理成 AI 分析助手的“可用数据域”。当运营问“最近订单来源有什么变化”时，AI 不应该凭空分析，而是知道可以优先引用订单统计、交易统计、用户统计这些既有口径。
五、第四步：Dao 和 Model 只做数据访问知识，不让 AI 乱查库
很多二开事故来自一个习惯：在 Controller 或 Services 里临时写查询。短期看很快，长期会破坏项目分层。
知识库里应该明确告诉 AI：
查询逻辑必须走 Dao / Model 业务编排放在 Services Controller 不直接拼查询 不要在业务层临时写 SQL可以把 Dao 层整理成“查询能力目录”：
StoreOrderDao 订单主表查询 StoreOrderCartInfoDao 订单商品明细 StoreProductDao 商品主表查询 StoreProductAttrValueDao 商品 SKU 查询 UserDao 用户基础查询 UserLabelRelationDao 用户标签关系 DivisionUserRelationDao 团队分销关系这样后续让 AI 生成代码时，就可以在提示词里明确要求：
请遵循 CRMEB Pro 的 Controller -> Services -> Dao -> Model 分层。 如果需要新增查询，请在对应 Dao 中封装，不要在 Controller 或 Services 中直接查询数据库。六、第五步：给 AI 准备一份“模块卡片”
实际落地时，可以给每个模块整理一张模块卡片。比如订单模块：
模块：订单 后台路由：route/admin.php 中 order 分组 控制器：app/controller/admin/v1/order 服务层：app/services/order 数据访问：app/dao/order 模型：app/model/order 前端页面：crmeb_pro_admin/src/pages/order 移动端接口：crmeb_pro_uniapp/api/order.js 高风险字段：订单金额、支付状态、退款状态、发货状态、库存、积分、优惠券、佣金 二开原则：先确认状态流转，再改展示字段；先复用 Services，再扩 Dao 查询商品模块也可以这样写：
模块：商品 用户端入口：api/product/detail/:id、api/products 后台能力：商品列表、SKU、分类、标签、品牌、库存 服务层目录：app/services/product 数据访问目录：app/dao/product 移动端接口：crmeb_pro_uniapp/api/store.js AI 适用场景：商品问答、导购推荐、商品标签补全、运营选品分析这类卡片越清晰，AI 越不容易“乱发挥”。
七、二开落地建议：先做内部知识库，再接 AI 问答
建议的落地顺序是：
1. 抽取 route/admin.php、route/api.php、route/kefu.php 的接口清单 2. 按模块关联 Controller、Services、Dao、Model 3. 为订单、商品、用户、客服、统计等核心模块补充模块卡片 4. 把高风险业务规则单独沉淀为注意事项 5. 再接入 AI 问答或 AI 开发助手不要一开始就让 AI 直接改代码。先让它“读懂项目”，后面才能让它更稳定地辅助写代码、生成文档、排查问题。
八、注意事项
- 不要把账号、密钥、真实客户数据、线上库名、服务器路径写进知识库。
- 不要把完整业务库表数据交给 AI，建议只整理字段含义、接口说明和脱敏样例。
- 订单、支付、退款、库存、余额、积分、优惠券、分销等模块要标记为高风险模块。
- 让 AI 生成二开方案时，要明确要求遵守 CRMEB Pro 分层，不允许跳过 Dao 直接查库。
- 知识库不是一次性文档，新增接口和字段后要同步更新。
九、标签建议
CRMEB CRMEB Pro 二次开发 ThinkPHP AI 编程 接口文档 项目知识库 后台系统