一个业务四个端，怎么组织代码
一个业务四个端：后台管理端、客户端 H5、经销商端 H5、代理商端 H5。业务域相同，用户角色不同，交互流程差异明显。代码怎么组织？按技术栈分，还是按端分？我们的答案：目录第一层按端语义命名，不用技术栈做第一层。
为什么按端分，不按技术栈分
四个端的主要使用者和职责完全不同：后台端是运营、管理、审核、财务等内部角色，管配置、审核、订单账务；客户端 H5 面向客户，走商品、认证、下单、签约、还款全流程；经销商端管申请认证、签约、收益、提现；代理商端管营销业绩、收益、经销商管理。
按技术栈分（比如 vue/、react/、admin/），分出来的是"用什么写的"，不是"给谁用的"。新人找代码时想的是"我要改经销商提现页"，不是"我要找 Vue3 写的 H5"。目录结构应该回答业务问题，不回答技术问题。
四个端，四种视角
同一个业务，四个端看到的是完全不同的切面。后台端看的是全局：配置、审核、订单、账务、设备、产品，所有后台能力收拢在这里。客户端 H5 看的是自己的事：商品、认证、下单、签约、验收、还款、支付、发票，一条完整的用户旅程。经销商端看的是生意：申请认证、签约、收益、服务费、提现、交易记录。代理商端看的是规模：营销业绩、收益、提现、银行卡、经销商管理。
"业务域相同"不等于"做一样的事"。四个端的交互流程差异明显，硬塞进同一套页面模板，省的是代码，丢的是体验。按端拆分首先承认差异，其次才是复用——复用的是底座和变量，不是页面。
三条工程规则
- 根目录是业务集合目录：新增端工程优先继续放在同一集合目录内，不另起炉灶。四个端是一个业务，不是四个项目。
- 子目录名体现端语义：第一层目录叫"后台管理端""客户端 H5"，不叫"vue3-admin""h5-vite"。技术栈会换，端语义不会。
- 模板遗留名称只作线索：脚手架带下来的名字不能直接当业务名称用，看到要改，不要将就。
还有一条元规则：项目级 AGENTS.md 优先于工作区通用规则——离代码最近的规则最有发言权。没有项目级规则的端，参考同业务集合内更近的明确规则，但推断永远不能写成正式规则。"隔壁端是这么做的"可以当起点，不能当依据。
前端实现纪律
页面层只负责编排、跳转和状态分发；字段清洗、状态文案、接口兼容，优先下沉到 adapter/mapper 层。页面里不写"如果后端返回 A 就显示甲，返回 B 就显示乙"的兼容屎山。
接口字段以已确认的文档为准，不为同一语义主动保留多套猜测字段名。"可能是 userName 也可能是 username，先都写上"——这种代码一出现，字段语义就永远确认不了了。
样式用语义变量：主题、按钮、边框、阴影，优先走变量，不新增硬编码。四个端视觉要统一，靠的不是"大家自觉写一样"，是变量只有一套。新端接入时，先继承变量，再谈定制。
还有一条 AI 协作纪律：AI 生成的代码、候选建议、未确认的状态流转和未确认的字段语义，只能以候选/待确认方式沉淀，不能直接写成正式实现。AI 补的代码越顺，越要有人把"已确认"和"待确认"分开。
没确认的不写死
这套模式目前还有四个待确认问题：四端是否共用统一服务端、租户模型和鉴权机制；代理商、经销商、客户之间的正式关系模型；收益、提现、订单、还款等状态流转的正式定义。没确认之前，代码里按"各端独立"写，不提前做统一假设——假设写进代码，就成了事实上的架构。"先各端独立，以后再统一"听起来像拖延，但它是诚实：统一的前提是关系模型先确认。在模型确认之前写统一代码，省的是今天的时间，欠的是明天的重构。
小结
多端代码组织就三句话：第一层目录按端语义，不按技术栈；页面只做编排，清洗下沉 adapter；没确认的关系不写死。目录是给人看的，先让人找到，再让机器跑通。