Django 开发
让 Django 应用的数据和权限符合实际工作流程。
增加一个审批步骤，可能同时影响数据库记录、内部界面、导出和客户访问。我们围绕这些关联开发 Django 应用，保留团队依赖的数据，并让下一次修改有清楚的依据。
直接回答
Django 开发涵盖围绕模型、视图、身份验证和后台管理构建的应用。我们共同确定业务流程、访问规则与数据库变化，再交付实现及后续维护所需的验证。
适合
- 需要扩展已有 Django 产品，或已为明确应用选择 Django 的团队
- 具有结构化记录、内部管理和角色权限要求的产品
可考虑其他服务
- 独立脚本或命令行工具
- 尚未选定技术的产品探索，或整体架构替换
明确业务必须保留什么
我们沿着一个流程梳理记录、关系和允许的状态变化，分别确定输入校验、数据库约束和事务边界。查询应取得正确记录，并防止意外访问其他客户账户的数据。交付对象是一项具有明确数据规则的应用变更。通用打包和运营脚本仍由 Python 开发承接。
让员工获得符合职责的操作界面
Django 后台管理文档将 admin 定位为内部管理界面。我们配置相关表单、列表和操作，并在服务端验证权限。面向客户的流程可以使用专门视图。仅隐藏字段或按钮不能落实访问控制；关联记录选择、导出和批量操作也需要逐一检查。
接触生产记录之前先审查迁移
自动生成的迁移文件只是起点。我们检查结构变化、现有值以及数据库本身的行为，再用代表性数据演练。历史记录补填、不兼容的应用版本和维护窗口都需要写入发布计划。Django 迁移文档解释其机制；对于不能直接逆向执行的变化，项目仍须确定可行的恢复路径。
增加审批字段，同时保留账户边界
示例验收：已有订单增加审批状态，历史记录按照约定规则处理。工作人员可以操作分配给自己的客户账户，但不能通过直接 URL 或导出取得其他账户的订单。演练记录数据数量、被拒绝的操作和恢复步骤。这是一项拟议验证场景，不是既有客户成果。
让下一次发布仍然可以理解和操作
你将收到存放在自己代码仓库中的实现、迁移文件、角色与流程测试、配置和运行说明。Hyperstate AI 案例记录了 Django API、身份验证及项目管理相关工作。你的交付范围按照实际应用确定。更大规模的架构替换属于旧系统现代化，后续升级可以另行约定维护范围。
开始之前的问题
可以。提出变更前，我们先检查谁负责数据库结构、迁移历史和代表性数据。未由 Django 管理的表，以及其他系统的写入，都需要单独处理，不能假定每条记录都由 Django 独占管理。
后台管理适合可信员工维护记录。审批流程或客户任务可能需要专门视图，让界面顺着业务步骤展开，而不是直接展示数据库结构。
不一定。我们检查 Python、Django 和扩展的兼容关系，再围绕关键流程安排可审查的改动。只有调查结果支持时，才提出范围更大的替换方案。
不会。模型级权限本身并不定义租户边界。我们会在视图、后台管理、导出和后台任务中实现并验证所需的查询、对象及操作检查。