它是什么
Qmai 国际前端规则中心不是一个业务系统，也不是一份普通提示词。
它是一套前端协作规则模式：把“需求应该落到哪里”“不同仓库负责什么”“AI 修改代码前要遵守什么”这些团队经验，整理成清晰、可读取、可执行的规则。
简单说，它让 AI 在写代码前先完成三件事：
- 看懂需求属于哪个业务系统。
- 找到应该修改的前端仓库。
- 按团队约束完成实现、验证和交付。
为什么需要它
Qmai 国际前端不是一个单仓库项目，而是一组系统共同工作：
console-vue-international负责后台基座、菜单、登录、容器和微应用挂载。- 多个
*-vue-international仓库负责不同业务域页面。 common-vue-international负责公共业务页和公共打印模板。vue-kylin-international负责共享业务组件。operation负责打印运行时、打印桥接和国际打印代码。- 装修平台、BI、供应链、营销、会员、支付等又有各自边界。
如果没有统一规则，AI 或新人很容易遇到这些问题：
- 只看需求关键词就猜仓库。
- 把共享组件问题复制修到多个业务仓库。
- 把打印模板和打印运行时代码混在一起。
- UI 页面只按通用模板做，忽略 Qmai 后台真实工作台风格。
- 进入发布阶段后误用 feature 分支、正式环境或浏览器操作。
规则中心解决的就是这些边界问题。
新版规则怎么分层
新版规则中心用“人先看地图，AI 再执行细则”的方式组织。
| 层级 | 作用 | 可以怎么理解 |
|---|---|---|
00-总览 | 解释国际前端整体由什么构成 | 一张系统全景图 |
01-PRD到系统拆分 | 把需求、飞书、工单拆到系统和仓库 | 需求归属判断表 |
02-系统内部结构 | 说明每类系统内部怎么拆模块和文件 | 仓库内部导航 |
03-模块页面命名 | 统一页面、路由、API、i18n、样式命名 | 落代码的命名规则 |
04-样式与组件库 | 说明样式入口、主题变量、组件库和 UI 规范 | 页面和组件怎么长 |
05-AI执行规则 | 给 AI 的全局约束、项目识别、路由和 playbook | AI 真正执行时读这里 |
06-维护映射 | 说明宏观规则变更后要同步哪些执行规则 | 规则更新检查表 |
这套分层的好处是：人读起来像文档，AI 执行起来像流程。
一个需求如何被处理
可以把一次交付想成一条固定链路：
收到需求 -> 读取需求内容 -> 提取业务词、页面词、接口词 -> 查仓库职责清单 -> 判断目标系统和目标仓库 -> 判断是否涉及基座、组件库、公共页、打印或 UI -> 选择最小 playbook -> 修改前给出目标、影响范围和步骤 -> 实现、验证、交付说明这里最关键的是前半段。代码不是第一步，判断边界才是第一步。
最重要的规则
1. 先判断仓库，不先写代码
普通 *-vue-international 需求必须先查“国际 Vue 仓库职责清单”。这个清单会说明每个仓库的一句话职责、优先处理的需求、关键模块线索和容易混淆的边界。
2. UI 任务先读 UI 详细规范
只要涉及页面布局、组件视觉、样式、长文本或 RTL，就必须先读 UI 详细规范。Qmai 国际后台是高频业务工作台，不是营销官网，也不是通用 SaaS 卡片模板。
3. 打印要分清两个世界
公共打印模板和纸面内容布局优先看 common-vue-international。
打印插件、桥接、国际打印代码和运行时调试属于 operation。
4. 可选发布阶段有独立约束
发布不属于默认交付主流程。只有任务明确进入发布或部署阶段时，才应用发布规则。
普通国际仓发布到 OPMS 平台时，必须走本地配置和 opms_release.py 脚本，不能通过浏览器页面点击完成。
如果发布 pre，必须先把当前任务分支合到 pre，推送 origin/pre，然后只部署 branch/pre。不能直接部署 feature 分支。
5. AI 不主动做高风险动作
未经明确要求，不执行 git commit、git push 或发布。修改前先给方案，完成后说明改了什么、为什么、如何验证。
核心价值
Qmai 国际前端规则中心的价值体现在三个层面。
| 层面 | 价值 |
|---|---|
| 业务层 | 需求先拆到系统和仓库，减少改错位置、重复联调和边界争议 |
| 工程层 | 基座、业务仓、公共页、组件库、打印、装修平台和 UI 规范都有清晰职责 |
| AI 层 | AI 在明确约束下执行，修改前有方案，修改后有验证和交付说明 |
这套模式把多仓库协作经验沉淀为可读、可执行、可维护的规则，让 AI 编码从“直接生成代码”变成“先识别边界，再稳定交付”。