如意 Django CRM 后台美化决策：原生 Admin、Unfold 还是 SvelteKit？

OK，OK，大家好，欢迎大家来到大鹏 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 的后台美化由此有了明确起点。

下一步先落地品牌基线和登录页响应式头部，再扩展到导航、列表和表单。

每次扩展都继续保留三语言截图与功能测试。