OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。如意 Django CRM 已经有一套能用的 Django Admin。简体中文、繁体中文和英语也已经可以切换。真正的问题不是后台能不能打开而是下一步该把改造成本花在哪里。是继续改造原生 Admin接入 Unfold还是建设 SvelteKit 独立运营台我的选择是保留原生 Django Admin通过浅层模板覆盖逐步实现“青岚如意”。Unfold 更适合快速获得通用现代后台SvelteKit 则留给真正的独立运营产品。先把路线选对再进入登录页、导航和表单的具体改造。一、从真实后台确认问题先从已经能够运行的 Django 6.0.7 Admin 开始而不是从一张理想效果图开始。1.1 简体中文后台暴露了哪些结构问题项目已有 7 个admin.py、19 个ModelAdmin、7 处直接注册和 6 个内联管理类。我们不是给空壳选择皮肤而是在规划一个已有管理系统怎样继续演进。先看头部品牌标题、三个语言入口和主题按钮为什么全挤在同一段横向空间里问题集中在三个位置。品牌标题标题已经被拆成两行首要信息没有获得稳定空间。语言入口语言名称出现逐字换行操作区难以快速扫描。布局结构品牌区和工具区缺少清楚边界多个控件互相挤压。我的判断是最先暴露的是布局容量和信息层级而不是配色。因此第一批改造要守住三条线。处理顺序先稳定头部结构再加入国风视觉表达。容量基线设计必须同时容纳品牌名称和三种语言入口。改造目标美化不能破坏已经可用的登录与语言切换功能。1.2 英语页面为什么是更严格的压力测试再切换到英语文案长度变化会把同一个问题放大。比较中英文页面时哪些布局关系应该始终保持稳定英语页面给出了更严格的压力测试。标题长度英语品牌标题占据三行纵向高度明显增加。语言状态三个语言入口仍然挤在右侧当前语言能够正确识别。功能状态登录表单、主题控制和语言切换仍然可以正常使用。自动化断言已验证页面返回 HTTP 200、登录表单可见并且html lang为en。我因此把它定义为明确的视觉改进项而不是国际化功能故障。英语页面进一步明确了验收标准。响应式规则文案变长以后品牌区和工具区仍要保持稳定层级。验证方式三种语言都要经过功能断言和真实截图检查。✅设计原则先解决结构再讨论水墨蓝、山水纹理等装饰语言。二、在三条后台美化路线中做选择三条路线都能让后台变得更现代但它们对应的投入和产品目标不同。2.1 三条路线分别解决什么问题先把方案放进同一张决策图再讨论各自的适用边界。三条路线表面上都在美化后台真正购买的能力各是什么放到同一张图里差异就出来了。️原生改造沿用现有管理能力以受控改动换取更高品牌自由度。⚡主题接入用迁移成本换取成熟组件和更快的现代化速度。独立前端用新产品建设换取流程与交互的最大自由度。对当前项目而言我更愿意用受控改动换取品牌自由度。对应到现阶段优先级如下。当前首选原生 Admin 渐进式改造最符合当前范围。备选条件Unfold 适合品牌差异较小并追求快速交付的阶段。升级信号运营后台成为独立产品时再启用 SvelteKit 路线。2.2 为什么当前选择原生 Django Admin这条路线保留现有注册、权限、表单和模型管理结构。Django 官方支持项目级模板覆盖也支持继承原模板后只重写特定 block。Django 官方文档https://docs.djangoproject.com/en/6.0/howto/overriding-templates/当前项目已经具备四个适合渐进改造的条件。现有能力已有管理类、权限和表单不需要整体迁移。模板接缝项目已经覆盖admin/base_site.html并拥有独立语言模板。品牌基础可运行的品牌配置模型能够继续承载统一设计规则。成本边界专业视觉仍需完成响应式、状态规范和可访问性验收。选择原生 Admin 不等于选择零成本而是把成本集中在真正需要差异化的界面层。2.3 Unfold 和 SvelteKit 何时更合适Unfold 适合快速获得现代导航、组件和仪表盘但它不是无需迁移的皮肤。Unfold 快速开始https://unfoldadmin.com/docs/installation/quickstart/Unfold 多语言配置https://unfoldadmin.com/docs/configuration/multi-language/SvelteKit 独立运营台拥有更大的产品自由度也会引入新的前端和 API 建设。两条备选路线各有清楚的触发条件。️通用后台品牌差异较小并追求快速交付时可以优先评估 Unfold。迁移投入接入 Unfold 仍要适配管理类、认证页面和多语言行为。产品自由独立运营台可以围绕销售流程和经营分析重新组织交互。建设边界启动 SvelteKit 会把视觉优化扩大成新的运营产品建设。当前需求仍是提升内部管理后台的品牌感和可用性因此暂不扩大实施范围。三、把中国风约束成可执行设计系统路线确定以后还要让视觉审美、工程边界和品牌表达能够互相约束。3.1 三个约束为什么必须同时成立这次改造必须同时面对 UI 设计、Django 架构和中国风表达。如果只满足其中一个方案会在哪个环节失控三个视角各自守住一条底线。UI 设计重做视觉层级但保留成熟表单和键盘操作行为。️Django 架构控制依赖、升级面和回滚半径优先复用现有接缝。️中国风表达用秩序、留白和曲线形成气质避免堆砌传统符号。放回如意 Django CRM我更看重三种约束能否同时成立。对应到工程实施结论很具体。共同结论原生 Admin 能以较小架构扰动承载较大品牌自由度。️功能底线三语言、权限、表单和模型管理行为必须持续回归。演进方式每次只改一层并保留独立验证和回滚能力。3.2 青岚如意如何形成可执行规则现代中国风应该成为稳定的设计规则而不是一次性的装饰效果。只看这组原则中国风一定要靠大量传统图案才能被识别吗“青岚如意”把文化气质拆成四个可以执行的系统原则。色彩系统水墨蓝建立稳定感如意绿表达品牌朱砂只做少量提示。视觉秩序栅格、标题层级和工具区边界共同保证后台扫描效率。️留白节奏列表、表单、筛选和危险操作通过空间关系彼此分离。如意曲线抽象轮廓进入圆角、焦点环和分组边界不直接绘制如意。我会把“克制”作为验收标准文化表达不能压过高频工作任务。这四条原则也形成了后续页面评审的共同尺度。品牌识别页面离开概念图以后仍能保持统一的如意气质。信息效率任何装饰都不能降低表格、表单和筛选的可读性。视觉分量蓝色承担主体金色、红色和绿色只负责关键点缀。复用价值设计语言能够沉淀为令牌和组件规则而不是一次性效果图。四、用阶段验收控制实施范围推荐方案不仅要说明怎样开始还要规定每一步在哪里停止。4.1 四阶段路线如何控制改造半径先通过路线图确认每个阶段的输入、产出和停止条件。沿着图中的四个阶段推进为什么每一步都要能够独立验证和独立回滚四阶段把品牌设计、模板改造和功能回归分开处理。️第一阶段固定色彩、字体、间距和三语言排版容量不触碰业务表单。第二阶段只改登录页、品牌区和导航等少量浅层模板接缝。️第三阶段用真实任务流验证列表、编辑、筛选和错误状态。第四阶段将功能测试、响应式截图和键盘检查纳入发布条件。我用“每一阶段都能停止”约束范围避免视觉美化悄悄演变成整体重构。路线图最终落实为四项交付纪律。行为锁定先保存现有三语言与权限行为的自动化证据。最小改动能通过模板 block 完成时不复制整份 Django 上游模板。分批交付一个视觉批次只处理一个清楚的问题集合。双重证据截图发现视觉问题测试证明功能状态二者不能替代。现有三语言后台测试已实际执行 11 项并全部通过。后续视觉批次还要增加 1600×900 与 375px 的真实截图检查。4.2 什么时候应该重新选择技术路线推荐原生渐进改造不代表它适用于项目的所有发展阶段。重新选择路线需要由明确的业务信号触发。面对同一个后台什么变化足以让我们离开当前路线三个分支对应三种不同的项目状态。⏩优先速度团队接受管理类迁移且品牌差异较小时应重新评估 Unfold。运营产品后台出现跨模型流程和任务工作台时应评估 SvelteKit。内部管理需求仍是模型管理和独特品牌时应继续采用渐进式改造。我的判断是只要后台仍以模型管理为核心就没有必要为了视觉新鲜感更换技术路线。重选方案时要守住三条判断线。触发依据先确认业务目标已经变化再讨论框架迁移。路线结果速度、品牌和产品自由度只能按当前优先级取舍。评审结论没有出现新的业务信号就继续完成原生 Admin 渐进改造。4.3 下一步从哪里开始路线确定以后第一步不是全面换肤。先处理最能暴露结构问题的品牌基线和登录页头部。实施顺序可以压缩为三件事。品牌令牌先固定色彩、字体、间距和状态语义。️头部结构再解决品牌名称、语言入口和主题按钮的空间冲突。回归验收最后用三种语言、两种视口和现有测试复核行为。如意 Django CRM 的后台美化由此有了明确起点。下一步先落地品牌基线和登录页响应式头部再扩展到导航、列表和表单。每次扩展都继续保留三语言截图与功能测试。
（支持资料、图片参考_相关定制）_)
)
