企业官网建设流程全解析

1. 项目概述

1.1 这个系统到底解决什么问题

社区设备报修这件事，做过物业系统的人都知道，表面看是“住户提交一条工单，维修师傅上门处理”这么简单，实际上牵扯到的环节远比想象中复杂。住户报修渠道不统一，有的打电话、有的在业主群喊、有的直接去物业前台登记；工单记录散落在微信群聊天记录和纸质登记本里，管理员要统计某类设备的故障频率、某个片区的报修趋势，只能靠人工翻记录、拍脑袋；更麻烦的是报修量的波动——每年入冬水管爆裂会集中爆发、夏季用电高峰跳闸频发，如果等住户报上来了才安排人手，物业永远处于救火状态。

这套“基于Django的社区设备报修住户反馈智能预测系统”想做的，就是把“报修工单管理”和“机器学习预测”这两件事揉在一起。核心价值不是做了一个在线登记表，而是把历史工单数据当作生产资料，让系统学会在故障爆发之前给出预警信号：哪些设备在未来两周内故障概率升高、哪个片区的报修量会出现峰值、对应的备件和维修人力应该提前怎么调配。

我一开始接触这类需求时，最常见的误区是把精力全花在“报修表单怎么做好看”“工单状态怎么流转”上，对预测模块只是装模作样挂了一个回归模型。后来在模拟项目X里被现实毒打了几次才明白：没有干净的历史数据和合理的数据口径，预测就是一个摆设。所以这篇博文会重点拆解两条主线——工单管理链路怎么设计才能为预测提供高质量数据，以及预测模块怎么落地才能真正帮到物业运营。

适合谁来参考？两类人最对口：一类是接社区/园区数字化项目的开发者，想了解Django如何承载“业务系统+算法模块”混合型项目；另一类是对智能预测有想法但不知道怎么和Web业务系统集成的学习者。文章不会堆砌大而全的理论，所有方案都是从实际能跑通、能上线、能维护的角度来聊的。

1.2 项目技术全景与设计基调

整体技术栈以Django为核心，这个选择不是随便拍的。Django自带Admin后台、ORM、认证体系、迁移机制，应付社区设备管理这种中等复杂度的业务模型非常合适。尤其是自带的Admin后台，开发初期可以零成本获得一个可用的管理界面，物业管理员录入设备台账、查看报修进度这种需求，不需要额外写前端页面就能先跑起来。

预测模块采用“离线训练 + 在线推理”的分离策略。系统用Celery定时把历史工单数据抽取成特征集，在后台完成模型训练和指标评估，训练得到的模型文件持久化存储，Web请求进来时直接加载模型输出预测结果。这套模式在数据量不大、预测频率要求不高的场景下最稳，也最容易维护。如果非要引入实时流计算、实时特征更新，对一个社区规模的系统来说成本收益完全不成正比。

前端部分，实际开发中建议用Django模板加轻量JS的组合，避免一开始就上前后端分离。社区物业管理系统使用者就两类——物业工作人员和住户，界面清晰、操作顺手远比技术架构“先进”重要。后期如果需要做小程序或者移动端适配，再通过Django REST Framework把核心接口暴露出去，这种演进路径最平滑。

2. 数据建模与业务模块设计

2.1 核心表结构的设计思路

设备报修系统的数据模型，可以从“设备—位置—住户—工单”这四个实体出发来梳理。设备表不能简单存一个“设备名称”字段，必须区分设备类型、安装位置、所属楼栋/片区、投入使用日期、品牌型号这些属性。为什么投入日期重要？因为设备的报修频率和它的生命周期强相关，一个用了十年的水泵和一台上周刚装好的水泵，故障概率完全不同，这是后面预测模型的关键特征。

我习惯给设备表加一个device_code唯一编码，格式类似“HQ-03-02-PUMP-021”，含义是“A区3栋2单元-水泵-编号21”。这种编码在物业线下管理中本来就用得普遍，系统里延续这个习惯能让住户和维修师傅快速对齐认知。同时建议增加shelf_date字段记录设备启用日期，而不是用安装日期，两个日期在某些改造项目中可能相差数月。

工单表是整条业务链路的枢纽。除了住户信息、设备信息、故障描述、报修时间、状态这些常规字段，一定要保留几个容易被忽略的字段：arrive_time维修人员到达时间、finish_time完成时间、fault_category故障分类、handle_method处理方式、parts_used更换配件。这些字段当前的业务作用可能不明显，但它们是训练预测模型的原料。没有到达时间和完成时间，你没法预测响应时效；没有故障分类，你只能预测“报修量涨了”，却不知道是哪种故障在涨。

住户反馈表则建议单独拆出来，不要塞进工单表。住户在工单完成后评价维修质量、响应速度、服务态度，这些反馈数据既能为物业考核维修人员提供依据，也能作为预测模型的补充特征——如果某类工单的“差评率”持续走高，大概率是某种设备故障反复发作的间接信号，这在预测模型里是一个有价值的前置指标。

2.2 工单状态机与流程闭环

工单状态设计直接决定系统的可用性。我见过不少项目把状态字段做成一个字符串，今天写“处理中”明天写“维修中”，表格里乱七八糟。正确的做法是把状态定义成一组固定的枚举值，通过状态机约束流转方向。“待派单→已派单→维修中→待验收→已完成”是主干流程，再加上“已取消”和“已退回”两个分支状态作为异常出口。

有一个细节值得特别注意：状态流转必须记录时间戳，而不是只更新一个状态字段。比如从“已派单”变为“维修中”时，记录dispatch_time和start_time；从“维修中”变为“待验收”时，记录finish_time。这些时间字段本身就是预测模型最原始的输入变量，比如“从报修到维修人员出发的平均时长”“不同片区的维修时长中位数”，都是从这里来的。

一个好的状态机设计还要考虑“超时无人处理”这种情况。我在项目里用的是Django的信号机制加Celery定时任务：每30分钟扫描一次所有“已派单”状态且超过2小时未开始维修的工单，给物业经理推送提醒消息。这类逻辑用信号触发容易出并发问题，用定时任务扫描反而是最简单可靠的方案。

2.3 住户端与管理端的权限划分

权限这块，Django自带的Group和Permission就够了，不需要引入第三方复杂的权限框架。我的划分方案是三个角色：普通住户、物业客服、维修主管。住户只能创建工单、查看自己提交的工单记录、对已完成工单评价；物业客服可以创建工单（代报修）、指派维修人员、修改工单信息；维修主管拥有客服的全部权限，额外可以查看设备台账、导出统计报表、查看预测结果页面。

住户端不建议强制注册登录。现实场景里，很多住户报修时不愿意注册账号，嫌麻烦。我的做法是提供“手机号+短信验证码”的轻量身份通道，没注册过的手机号首次提交工单时自动创建账号。这个设计在社区场景里非常实用，能把报修流程的摩擦成本降到最低。敏感操作比如修改个人信息、查看历史工单，再强制要求补充密码或实名验证也不迟。

3. 智能预测模块的原理与落地

3.1 预测目标拆解：不是只做一个“预测报修量”

很多人听到“智能预测”就想到时间序列预测下一个月的报修总量，做完发现对物业运营帮助有限。实际上，报修量预测只是最浅一层。从这个系统的实际运营价值出发，预测目标至少可以拆成三类。

第一类是“报修量趋势预测”。以周或天为粒度，预测未来7到14天各片区的报修工单数量。这个结果用于人员的排班调配：如果预测显示下周三报修量是平时的1.8倍，提前安排两个维修师傅加班，比临时从外面找外包便宜得多。第二类是“设备故障概率预测”。针对每台重点设备，根据设备年龄、历史维修次数、最近一次维修时间、运行环境（楼层/户外/机房）输出未来30天内故障概率排名。这个结果用于预防性维护：概率排名前20的设备，安排巡检工单提前检查。第三类是“备件需求预测”。结合历史工单中更换的配件记录，预测未来一个月各型号备件的消耗量，避免出现“报修要换泵却要等三天调货”的情况。

第三类预测往往最容易被忽略，但它恰恰是最容易落地见效的。备件数据是结构化最强的数据，库存记录、领用记录、采购周期都是现成的，直接可以做需求预测；而且备件预测出错的影响范围小——多备一个密封圈或少备一个，不会像排班错误那样引起住户投诉。

3.2 特征工程：预测效果分水岭

特征工程是整个预测模块里最花时间、也最决定效果上限的部分。直接拿原始工单数据丢给模型是新手最容易犯的错。工单数据里面除了“报修时间”“设备类型”“片区编号”“故障描述文本”之外，其他乱七八糟的文本字段基本都不能直接用，必须转换成一列一列的数字特征。

时间特征方面，从报修时间可以拆出：月份、星期几、是否为节假日、是否为月初/月末（很多小区物业缴费节点前后，住户对公共设备问题的容忍度更低，报修意愿更高）。滞后特征方面，计算每个片区、每种设备类型在过去7天、14天、30天内的报修量。这个特征对序列预测特别有效，因为它直接把“最近是不是有某种设备开始频繁出问题”这个信息带进来了。设备画像特征方面，把设备的使用年限、累计维修次数、距上次维修天数算出来。注意累计维修次数不能用原始次数直接输入，最好做一次归一化或者排序分箱，否则设备之间的量纲差异会干扰模型。

有一类特征我试过之后强烈建议加上：天气特征。社区设备报修量和天气的相关性非常明显——连续强降雨后地下室排水泵报修量激增，寒潮过后水管冻裂集中爆发。把历史天气数据按工单日期关联进来，再把未来几天的天气预报数据用于预测推理，效果提升非常直观。获取历史天气数据不复杂，Django项目里写一个定时任务，每天从公共天气数据源抓取城市级天气信息存到本地表就行。

文本数据（故障描述）也值得利用。住户报修时填写的“漏水”“不启动”“异响”“跳闸”这些关键词，可以直接做标签化处理。我的做法是在系统里维护一个故障关键词词典，每个关键词关联一个标准故障类别，提交工单时自动从描述文本中匹配关键词，分类不够明确的再人工修正。这样产出的fault_category字段不再依赖住户精确填写，脏数据比例能大幅下降。

3.3 模型选型：轻量方案优先

模型选择上，我强烈不建议社区级项目一上来就上深度神经网络。真实场景数据量可能就几千条工单，LSTM、Transformer这些模型在小数据量上没有优势，反而带来训练时间长、部署复杂、结果解释性差的麻烦。我实际测试下来，效果和性价比最好的是两套轻量方案。

时间序列预测用Facebook Prophet或者statsmodels的SARIMA，后者更偏传统，前者胜在健壮性。Prophet对缺失值容忍度高，趋势和季节性的分解结果直观，关键是训练速度极快——几千条数据几秒钟就能收敛，非常适合Celery定时任务里每天跑一次。长短期趋势分开拟合之后，还能把预测曲线和置信区间直接画出来展示在管理后台，物业经理看到的是“预计下周三A区报修量达到峰值，置信区间较宽”这种可理解的信息。

设备故障概率排序用LightGBM或者XGBoost。这类梯度提升树模型处理表格数据的效果公认能打，而且能输出特征重要性，方便向物业团队解释“为什么这台设备被预测为高风险”。把设备画像特征、维修历史特征、环境特征拼成一个二分类数据集，标签是“未来30天内该设备是否发生报修”，训练完成后对全量在册设备逐一预测概率，取Top N生成巡检工单。这个流程逻辑清晰，可解释性强，落地沟通成本最低。

3.4 模型与Django的集成方式

模型集成这一环，核心原则是“训练和推理分离”。训练任务放在Celery Beat定时任务里，每天凌晨2点执行：从数据库抽出历史数据，跑特征工程，训练模型，评估指标，把模型文件持久化到磁盘指定目录。Web请求走进的是完全独立的推理路径，视图函数加载磁盘上的模型文件，构造当前请求需要的特征，调用模型预测并返回结果。

有一个细节务必处理好——模型文件版本管理。我建议在模型文件命名中加入训练日期或版本号，同时把每次训练的模型评估指标（比如MAE、RMSE、AUC）记录到数据库一张model_metrics表里。这样做的好处是：某天预测结果明显异常时，可以快速对比历史版本，一键回滚到上一版模型。实际操作中，模型性能轻微波动是常态，但如果某项指标断崖式下跌，通常意味着上游数据链路出了问题，这时候回滚模型只是权宜之计，真正要排查的是特征数据更新是否完整。

序列化方案用pickle或joblib都可以。我偏向用joblib，它压缩后的模型文件更小，加载速度更快。需要注意跨环境兼容问题——开发机上训练的模型和生产环境的Python版本、依赖库版本不一致时，加载会报错。规范的做法是在部署环境的Docker镜像里固定Python版本和关键依赖版本（scikit-learn、lightgbm、prophet的版本号），训练和推理必须在同一环境内进行。

4. 开发实操：从骨架搭建到联调上线

4.1 环境初始化与Django项目结构

开发环境方面，Python版本建议3.10或3.11，虚拟环境用venv即可，不折腾conda。Django版本用4.x稳定版，搭配Django REST Framework用于后期接口预留，Celery用5.x配合Redis作为消息队列和结果存储。

项目结构上，我推荐按业务域拆分应用，而不是一个myapp包打天下：

community_repairstack/ ├── manage.py ├── config/ │ ├── settings.py │ ├── celery.py │ └── urls.py ├── accounts/ # 住户/物业账号体系 ├── devices/ # 设备台账、位置管理 ├── workorders/ # 工单管理、状态流转 ├── feedback/ # 住户反馈评价 ├── prediction/ # 特征工程、模型训练、预测接口 └── common/ # 公共工具、枚举定义、信号处理

prediction独立成一个应用的好处是，模型训练和业务逻辑解耦，后续如果要把预测能力换成独立服务，迁移成本低。我最初的版本把模型代码散落在workorders和devices两个应用里，改一次特征字段要动三四个文件，后来重构才理顺。

4.2 报修工单核心流程实现要点

先看报修创建这一步。住户端提交表单时，前后端同时做校验，但校验的侧重点不同。前端校验格式，比如手机号长度、描述不能为空；后端校验业务规则，比如设备状态是否为“已停用”、同一设备当天是否已有未完成工单（防止重复报修）。Django Form或者DRF Serializer都能做，我建议至少把后端的业务校验写清楚，因为很多住户会从不同渠道提交，绕过前端校验的情况并不少见。

状态流转的核心逻辑，不建议在视图函数里到处写instance.status = "processing"。更干净的做法是把状态转移封装在工单模型的方法里：

class WorkOrder(models.Model): status = models.CharField(max_length=20, choices=WORK_ORDER_STATUS_CHOICES, default="pending") dispatched_at = models.DateTimeField(null=True, blank=True) started_at = models.DateTimeField(null=True, blank=True) finished_at = models.DateTimeField(null=True, blank=True) def dispatch(self, repairer): if self.status != "pending": raise StateTransitionError("只有待派单状态的工单才能派单") self.status = "dispatched" self.repairer = repairer self.dispatched_at = timezone.now() self.save(update_fields=["status", "repairer", "dispatched_at", "updated_at"])

这个方法的好处是把状态机规则收敛在模型层。视图层不管从哪个入口操作（后台Admin、API、爬虫脚本），都必须经过统一的方法，不会出现状态被随意改写的情况。工单完成时同步更新关联设备的信息：device.last_repair_date = today、device.repair_count += 1。这个联动逻辑可以用信号（signal）来做，但我更倾向于在finish()方法里显式调用，因为信号在批量更新场景下容易漏触发，显式调用虽然多写一行代码，但行为可控得多。

4.3 预测特征的自动化流水线

特征的自动化计算，是整个预测模块能否从“demo”走向“持续可用”的关键。报修量趋势预测的特征流水线，我在Celery任务里按“日更”节奏来执行：

1. 从工单表聚合出每个片区、每种设备类型、每天的报修数量。
2. 按时间窗口滑动构造滞后特征（7天、14天、30天窗口）。
3. 关联天气数据表，把每日最高温、最低温、降雨量填到特征行。
4. 合并节假日特征（从holiday表查，节假日前后的报修行为模式差异很大）。
5. 按设备类型和片区分组，分别训练Prophet模型。

设备故障概率预测的标签构造要特别注意：需要做样本回看。假设要预测“未来30天内设备是否报修”，训练数据集的时间窗口必须是历史数据的“某个时间点往后斩30天”。举个例子，用2024年1月1日当天的全部特征数据，去关联该设备在2024年1月1日至1月31日之间是否有报修记录，有则标签为1，无则为0。然后滚动时间窗生成多条训练样本。新手最容易犯的错误是用全量历史直接生成标签，导致“未来信息泄露”，模型在训练集上表现极佳，一到真实预测就失效。

这类数据泄露问题在时间序列预测中特别隐蔽。特征工程代码里最常见的一个坑是：在构造第t天的滞后特征时，不小心用到了t天之后的工单数据。因为工单表只有一个报修时间字段，稍一疏忽就会把整张表的统计结果当作当天的特征值。规避方法是在SQL查询和特征拼接逻辑里显式加上work_order_time < window_end的过滤条件，然后写一个独立的校验脚本，随机抽几条特征行人工核对其滞后值与原始工单记录是否匹配。这个校验脚本我强烈建议保留在项目里，每次特征代码改动后都跑一遍。

4.4 定时任务与可视化呈现

Celery定时任务配置使用beat_schedule，三份任务分别处理数据同步、特征重算、模型训练：

from datetime import timedelta CELERY_BEAT_SCHEDULE = { "sync-weather-daily": { "task": "prediction.tasks.sync_weather_data", "schedule": timedelta(hours=6), }, "rebuild-features-daily": { "task": "prediction.tasks.rebuild_prediction_features", "schedule": crontab(hour=3, minute=0), }, "train-models-daily": { "task": "prediction.tasks.train_prediction_models", "schedule": crontab(hour=4, minute=30), }, }

凌晨执行训练任务，白天Web请求直接加载模型推理，这种节奏和社区物业的实际运作一致——早上物业经理上班打开系统，看到的是凌晨训练完成的当日预测结果，不需要等待。

可视化方面，直接在管理后台嵌入ECharts或者Chart.js的折线图。报修趋势页面展示“近90天实际报修量”和“未来14天预测报修量”两条曲线，置信区间用半透明色带绘制。设备风险页面用表格加红黄绿三色标记故障概率排名，点击设备行可以下钻查看该设备的历史维修记录和特征明细。不要过度做3D图表和大屏可视化，社区物业场景下，信息密度适中、颜色语义明确的图表比花哨的动图实用得多。

5. 常见问题与排查实录

5.1 训练数据太少，预测结果不敢用怎么办

社区项目刚上线时，历史工单数据积累通常不足，可能只有几百条。这种情况预测结果确实不可靠，但不能因此放弃方案。我的做法是分段推进：上线初期只运行描述性统计和规则预警——比如“某类设备近7天报修量环比增长超过50%就触发黄牌提醒”，这个阶段不需要机器学习，历史均值加标准差就能做一个很实用的异常检测器。运行两到三个月，积累足够数据后再切换为Prophet时序预测。

还有一个容易被忽视的数据补充途径：从同类社区的公开数据或者设备厂商的售后数据中借鉴模式。比如水泵类设备在高温季节故障率上升，这个先验知识可以编码成先验特征，弥补自身数据不足。刚开始模型效果差很正常，关键是建立好“预测结果—实际结果”的比对机制，每周复盘一次预测偏差来源，迭代特征比盲目换模型更有效。

5.2 模型文件加载报错与版本回滚

项目上线后，最典型的线上事故就是模型文件加载失败导致预测接口500。常见原因包括生产环境升级了依赖库版本导致pickle反序列化失败、模型文件被定时任务覆盖写入了一半（写入过程中进程被杀）、服务器磁盘空间不足导致文件写入失败但没有异常捕获。

我的处理方案是在推理接口加一层兜底逻辑：加载模型失败时，不直接抛异常，而是读取最近一份备份模型文件，同时记录告警日志并通知管理员。模型文件写入采用先写临时文件再原子替换的方式：

import os import tempfile from joblib import dump def safe_save_model(model, path): dirpath = os.path.dirname(path) fd, tmp_path = tempfile.mkstemp(dir=dirpath, suffix=".tmp") try: dump(model, tmp_path) os.replace(tmp_path, path) except Exception: os.unlink(tmp_path) raise

这个细节看似不起眼，但能在模型训练任务异常中断时避免生产环境的预测接口连带崩溃。线上系统最怕的是“一个模块的故障传染到另一个模块”，做隔离兜底比让每个模块都追求绝对可靠更现实。

5.3 反馈数据质量差，预测特征受影响

住户反馈表是预测模型的辅助数据来源，但也是脏数据重灾区。很多住户工单完成后根本不评价，或者随手打满分，反馈数据的区分度很低。我的处理方法是把反馈数据的“填写率”和“离散度”作为单独指标在看板中展示，如果反馈填写率低于50%，就主动降低反馈特征在模型中的权重。

另外，反馈表的设计要有意识地做一些区分度引导。评分从1到5星这样的经典设计，容易“全给5星”；改成三维评分——响应速度、维修质量、服务态度，每一项单独打分，住户填写时需要稍微动一下脑子，反而能给出更多有效信息。评论区的文本再走一遍关键词分类，提炼“反复维修”“未修好”“态度差”这些负面信号，对模型的补充价值立竿见影。

5.4 定时任务积压导致的预测延迟

Celery任务在凌晨集中执行，一旦某个环节卡住（比如外部天气数据源响应缓慢），会影响后续任务队列。这里有两种处理策略：一是把天气同步任务的重试次数调低，失败就跳过当日数据，不要阻塞后面的特征重建任务；二是训练任务执行时，先把预测模型的副本从“当前版本”改成“上一版本”，确保早上Web请求能正常输出结果，训练完成后更新版本号。简单来说，预测功能的价值在于“每天稳定给出一个可用结果”，而不是“每天给出一个完美结果”。宁可当天结果基于昨天的模型，也强过因为模型训练卡住导致整个预测接口不可用。

任务执行状态监控也别漏掉。我给每个Celery任务都加了一个简单的状态表，任务开始、结束、失败都会写入记录，第二天早上巡检只看一眼表就能发现哪个环节出了问题。Django后台放一个“任务执行日志”页面，比每次去翻日志文件高效得多。

6. 部署上线与运行维护经验

6.1 生产环境部署方案

生产部署我推荐用Docker Compose编排，容器包括Nginx、Gunicorn、Django应用、Celery Worker、Celery Beat、Redis、PostgreSQL。这个组合在2核4G内存的入门云服务器上就能跑得很稳，社区级项目的并发量完全没有压力。

settings.py里需要注意几个生产环境配置项：DEBUG必须设为False，ALLOWED_HOSTS用具体域名或IP列表，SECRET_KEY不写入代码库，通过环境变量注入。静态文件交给Nginx处理，媒体文件（住户上传的照片）单独挂载一个持久化卷，因为容器重启后容器内部的文件系统会被清空，照片丢失是实打实的运维事故。

数据库我建议用PostgreSQL而不是默认的SQLite。设备报修系统的数据总量不大，但预测特征计算涉及大量按时间聚合的查询，SQLite在并发读写下容易报database is locked，特别是在定时任务和Web请求同时操作数据的时候。PostgreSQL的窗口函数和日期运算支持也比SQLite完善，写特征工程SQL时会省很多事。

6.2 安全与隐私注意事项

住户手机号、住址信息属于个人敏感数据，部署时必须考虑基础的安全防护。HTTPS证书用免费的即可，关键在于数据访问权限控制：Django Admin后台必须开启AdminHoneypot或者至少换一个非默认路径，避免后台地址被扫描器直接命中；工单API接口做频率限制，防止被脚本刷接口；备份数据加密存储，数据库备份文件不要直接丢在公开目录。

另外，模型推理中输入的特征里如果包含住户个人信息，要注意脱敏。我实际开发中把“住户是否为老年人”“住户历史投诉次数”这类潜在敏感特征去掉了，因为它们对预测效果的提升有限，但涉及隐私评估和合规解释的成本很高。做预测系统要时刻提醒自己：特征可以少一些，但不能踩线。

6.3 运行维护中的真实经验

系统上线后的头一个月是问题集中爆发期。最典型的场景是：物业经理看到预测曲线“下周报修量上升”，但不知道该怎么行动，预测报告被忽略；另外维修师傅对系统派单不习惯，还是电话沟通。这提醒我一个关键点——技术系统的成功不等于业务效果的成功，预测系统要想真正产生价值，必须在产品层面把“预测结果→可操作动作”这条链路设计好。

我后来在预测报告页面加了“建议行动”栏：报修量预测超过阈值时，自动生成“建议安排1名值班维修人员”“建议提前联系外包维修团队”等行动文案；设备风险排名页面增加“生成巡检工单”按钮，物业主管一键把高风险设备转为巡检任务。有了这些面向动作的出口，预测结果才真正融入了物业运营流程，而不是一块好看的大屏数据。

根据我的实际测试，这套系统从开工到核心功能可用大约需要六到八周时间，其中数据建模和特征工程占掉了一半以上的精力。很多初学者容易低估特征工程、数据口径这类“不性感”的工作在预测项目中的分量，总想着换个好模型一步到位，结果往往是模型反复调参效果依旧不佳，最后倒回来补数据治理的课。如果你正在规划一个类似的Django智能管理系统，我的建议是：先把工单管理的基础做扎实，把每一个时间字段、分类字段记录准确，预测模块永远建立在干净数据的地基之上。