AssetMgmt固定资产管理系统（一）：码道搭台，设计筑基
本案例采用华为云码道（CodeArts）代码智能体作为核心开发工具，结合dev-process-framework、page-mockup、function-detail等专业化skills，构建从需求分析、系统设计、页面原型到SDD文档体系的完整开发流程。实现固定资产管理系统从需求到设计的全流程智能化场景，让企业资产管理告别混乱，迈入数字化新时代。
最新案例动态，请查阅AssetMgmt固定资产管理系统（一）：码道搭台，设计筑基小伙伴们快来进行实操吧！
案例简介：本案例采用华为云码道（CodeArts）代码智能体作为核心开发工具，结合dev-process-framework、page-mockup、function-detail等专业化skills，构建从需求分析、系统设计、页面原型到SDD文档体系的完整开发流程。实现固定资产管理系统从需求到设计的全流程智能化场景，让企业资产管理告别混乱，迈入数字化新时代。
一、概述
1.1 案例介绍
在中型企业日常运营中，固定资产管理往往成为“隐形痛点”：5000多件资产分散在各个部门，资产信息不透明、利用率低、维保不规范、审计追踪困难。资产管理员疲于奔命，普通员工对名下资产状况一知半解，企业每年因资产闲置和流失造成的损失难以估量。在数字化转型浪潮下，如何让沉睡的资产数据“活“起来，成为企业管理升级的关键一环。本案例旨在通过AI驱动的规范驱动开发（SDD）方法论，为固定资产管理系统注入“数字智慧“，实现资产全生命周期的透明化、智能化管理。
本案例采用华为云码道（CodeArts）代码智能体作为核心开发工具，结合dev-process-framework、page-mockup、function-detail等专业化skills，构建从需求分析、系统设计、页面原型到SDD文档体系的完整开发流程。该方案将传统开发中分散的需求文档、设计文档、任务清单整合为规范化的SDD体系，使决策过程可追溯、文档与代码同步更新，大幅提升开发效率和项目可维护性。通过码道的智能体模式，开发者无需深厚架构背景即可快速完成复杂企业级应用的设计与规划。
案例技术选型：
- 华为云码道（CodeArts）代码智能体：集代码大模型、AI IDE、Code Agent为一体的智能编码产品。具备强大的需求理解、架构设计和代码生成能力，支持智能体模式自动规划并执行复杂开发任务。本案例中作为核心开发平台，通过对话式交互快速完成固定资产管理系统的需求分析、架构设计和SDD文档生成。
- SDD规范驱动开发方法论：系统化的软件开发方法论，包含creating-sdd-directory、managing-spec/design/tasks-document四大核心流程skills。使决策过程可追溯，文档与代码同步更新，形成完整知识库，特别适合多模块复杂功能项目。本案例中作为整体开发方法论指导，确保固定资产管理系统开发的规范性、可追溯性和可维护性。
1.2 适用对象
- 个人开发者
- 高校学生
- 企业开发者
1.3 案例时间
本案例总时长预计120分钟。
1.4 案例流程
说明：
- AI IDE华为云码道（CodeArts）代码智能体安装部署；
- 配置码道devecoflow skill，并使用该skill部署配置码道开发生态skills；
- 对话码道，使用dev-process-framework skill生成系统设计；
- 对话码道，使用page-mockup skill生成前端页面设计；
- 对话码道，使用test-designer skill生成测试设计文档；
- 对话码道，使用function-detail skill整合系统设计和页面设计和测试设计，生成 AssetMgmt SDD（需求、设计和开发任务）。
1.5 资源总览
本案例预计花费0元。
| 资源名称 | 规格 | 单价（元） |
|---|---|---|
| CodeArts代码智能体 | 系统标配 | 免费 |
二、环境和资源准备
2.1 AI IDE华为云码道安装部署
参考案例《AI IDE华为云码道（CodeArts）代码智能体安装部署》完成Windows版AI IDE华为云码道（CodeArts）代码智能体安装部署。
注：
- 本案例中项目所创建的本地目录为
D:/Repositories/asset_mgmt； - 本案例使用码道智能体模式，模型选择GLM-5.1，开发模式为探索模式(Vibe-Coding Mode)。
2.2 配置码道skills
2.2.1 配置dev-eco-setup
对话码道：“请帮我从https://gitcode.com/sinat_41661654/dev-eco-setup.git下载该skill，并配置到当前项目中。”
等待任务执行结束，可在左侧.codeartsdoer\skills目录下查看dev-eco-setup skill。
dev-eco-setup skill简介：
开发生态自动部署工具，dev-eco-setup skill 自动从 GitCode 下载并部署项目级 skills，一键搭建完整开发生态。适用于新项目初始化和开发生态配置。
2.2.2 部署开发生态
继续对话码道：“请使用 dev-eco-setup skill 快速帮我部署一下开发生态”。码道将调用 dev-eco-setup skill 自动部署开发生态。
等待任务执行结束，可在左侧.codeartsdoer\skills目录下查看开发生态 skills 。开发生态包含以下项目级skills：
| 序号 | skill 名称 | 功能描述 | 适用场景 |
|---|---|---|---|
| 1 | dev-process-framework | 开发流程框架 | 从意图到验证代码的开发流程框架。提供需求细化、架构决策、任务分解、代码质量和质量保证的完整指南。 |
| 2 | page-mockup | PC端页面原型设计工具 | 根据需求规格说明文档自动生成PC端页面原型设计文档，包含线框图、交互流程、设计规范等。 |
| 3 | function-detail | SDD 文档体系生成工具 | 从需求规格说明书、架构设计、数据模型设计、API接口设计和页面原型设计生成完整的SDD(Specification-Driven Development)文档体系。 |
| 4 | sdd-workflow | SDD开发全流程管理工具 | 集成进度跟踪、文档同步、变更管理三大核心能力，确保开发过程可追溯、可复盘、文档一致性。 |
| 5 | bug-fix-reporter - Bug | 修复报告生成器 | 自动生成标准化的 Bug 修复报告。当修复问题、记录修复过程或生成问题文档时使用此 skill。 |
| 6 | fullstack-testing | 全栈测试综合工具包，涵盖测试设计、单元测试、集成测试、E2E测试和覆盖率分析。 | 支持两种模式：测试设计模式：生成测试设计文档和测试用例。测试执行模式：编写和运行pytest/Vitest/Playwright测试 |
也可在码道设置 > 技能与规则的项目级技能中进行查看。
注：本案例为固定资产管理系统项目的需求、设计阶段，后续会使用dev-process-framework、page-mockup、function-detail、fullstack-testing等skills辅助码道分别完成 AssetMgmt从原始需求到系统设计、页面设计、测试设计，并最后转化成SDD需求开发设计文档。
除上述skills之外，本案例中还用到了如下系统内置skills：
- frontend-design：码道内置的前端设计skill，提供5种专业主题风格（线性美学、极简现代、苹果极简、赛博朋克、拟物化），用于生成避免AI通用风格的高质量、生产级前端界面代码。
- SDD：包含四大核心流程skills：
- **creating-sdd-directory：**是SDD流程的起点，负责初始化规范驱动开发所需的目录结构和基础文件。
- managing-spec-document：负责管理
spec.md文档，明确记录"做什么"，确保需求清晰无歧义，避免开发过程中的需求偏差，是整个SDD流程的基础。 - managing-design-document：负责管理
design.md文档，详细规划"怎么做"，在设计阶段就考虑架构、技术选型和潜在问题，大幅减少返工成本，是连接需求与实现的桥梁。 - managing-tasks-document：负责管理
tasks.md文档，将复杂项目分解为可追踪的具体任务，使开发进度一目了然，是SDD流程的落地环节。
2.3 码道使用技巧（上下文选择功能）
在执行任务过程中，有时我们期望指令是针对某个具体文件、目录进行，此时需要用到码道的上下文选择功能，此功能用于限定对话和指令的作用范围。
在AI IDE界面打开指定的文件/文件夹，在码道对话框中输入“#”弹出选择菜单，根据需要可选择 File（单个文件）或 Folder（文件夹）。选择后，后续对话和指令优先在该范围内执行。
作用：
- 提高指令执行精度，避免全局搜索
- 让AI更聚焦于你关注的代码区域
- 加快响应速度，减少无关内容干扰
注：后续案例内容若 prompt 中包含#文件/目录名，则说明该指令使用了上下文选择功能。
三、对话码道：AssetMgmt 项目设计
3.1 项目背景与原始需求
项目背景与原始需求是产品价值的源头定义与所有后续决策的基石。它确立了“解决谁的什么问题、如何衡量成功”，是整个产品开发流程中唯一不可逆的锚定点，后续所有工作都是对其的演绎与实现，而非替代或修正。
如下是一份 AssetMgmt 项目背景与原始需求（简略版本，完整版请查看附录）：
1 业务场景
我们公司是一家中型企业，拥有约500名员工和多个部门。目前公司有大量固定资产（如电脑、办公设备、生产设备等），但缺乏有效的管理系统，导致以下问题：
1. 资产信息不透明，难以实时掌握资产状况
2. 资产利用率低，存在大量闲置资产
3. 维保管理不规范，影响资产使用寿命
4. 缺乏有效的审计追踪，责任难以界定
5. 统计分析困难，无法支持管理决策
2 业务目标
希望通过开发一个固定资产管理系统，实现：
- 资产全生命周期数字化管理
- 提高资产利用率20%以上
- 降低资产管理成本
- 完善审计追踪机制
- 提供数据决策支持
3 目标用户
3.1 系统管理员（1-2人）
职责：负责系统维护和用户管理
核心能力：
- 用户创建：创建、禁用或删除系统用户账号
- 角色/权限管理：根据组织架构和岗位角色（如资产管理员、普通员工）分配不同的操作权限和数据访问范围（如只读、编辑、审批、导出等）
- 拥有资产管理员的所有权限
3.2 资产管理员（2-3人）
职责：负责资产日常管理
核心能力：
- 资产创建与入库：为新增资产建立唯一的资产详情（编码、名称、规格、价值、位置、使用人等）
- 变动管理：处理资产的领用、退库、借用、归还，及时在系统中更新状态和责任人
- 处置执行：对报废、丢失的资产，按流程发起处置申请，获批后完成实物回收、系统销账或残值处理
- 日常维护与盘点：按周期（如每季度/年度）制定盘点计划，下发资产核对通知，使用人自行核对资产并回传资产照片。生成盘盈/盘亏报告
3.3 普通员工（约500人）
职责：可查看和申请使用资产
核心能力：
日常使用与保管：
- 按照操作规程使用资产（如不私装软件导致电脑故障、不超负荷使用仪器）
- 对自己领用或负责的资产（如笔记本电脑、工具、工牌）负有保管责任，避免丢失、损坏或被盗
- 不将自己的资产与他人随意调换，如需变更需通过资产管理员走系统流程
资产变动申请：
- 领用/退还：新领资产时按要求签收；离职或岗位变动时，主动退还名下所有资产
- 借用/归还：临时借用公共资产（如投影仪、会议室设备）时，在系统申请或登记，用后及时归还
- 报修/报废提议：发现资产故障、损坏或达到报废条件（如电脑已无法满足工作需求），通过系统提交维修单或报废申请（由资产管理员或审批人最终决定）
配合盘点与核查：
- 确认名下资产：定期登录系统，核对名下挂接的资产清单是否与实际持有一致
- 配合盘点：在资产管理员组织盘点时，根据系统提示或者电子流核对名下挂接的资产清单是否与实际持有一致
- 反馈异常：若发现盘点清单中的资产已不在自己手中（例如已归还但未销账），及时向资产管理员说明
资产信息核实：
- 发现系统记录的资产位置、规格等信息与实际不符（如电脑内存大小错误），可提醒资产管理员修正
资产清算：
- 办理离职或跨部门调动手续前，必须先完成名下所有资产的归还或过户（由资产管理员确认），否则人事部门可能不予办理后续手续
4 业务规模
资产数量：约5000-10000件
部门数量：约10-20个
并发用户：约50-100人
数据增长：每年新增约500件资产
3.2 AssetMgmt 整体设计
3.2.1 AssetMgmt系统设计
基于以上项目背景与原始需求，使用 dev-process-framework skill 进行 AssetMgmt 项目系统设计。将以下完整的 AssetMgmt 项目 prompt 发送给码道。
#AssetMgmt项目背景与原始需求.md 请帮我完成以下工作 ：
第一阶段：需求分析与设计
1. 使用 dev-process-framework 方法论
2. 进行需求细化和决策发现
3. 识别关键决策点和风险
4. 设计系统架构
5. 定义数据模型
6. 设计API接口
7. 制定实施计划
第二阶段：文档输出
1. 生成需求规格说明文档（Markdown格式）
2. 生成架构设计文档
3. 生成数据模型文档
4. 生成API接口文档
5. 生成实施计划文档
输出要求：
1. 文档格式
- 使用 Markdown 格式
- 中文编写
- 结构清晰
2. 代码规范 - 遵循 PEP 8（Python）
- 遵循 ESLint（JavaScript）
- 有适当的注释
- 有类型提示
3. 其他
- 代码：按前后端分离结构
- 配置：项目根目录 请系统化地帮我完成这个项目的规划和设计，确保文档完整、设计合理、可执行性强。
码道自动调用 dev-process-framework skill，自行规划任务并开始 AssetMgmt 项目系统设计。
人工核验系统设计文档是否符合要求，也可以使用码道进行自行查验，根据检验结果优化建议，进行设计文档的优化和修改。
#systemDesign
使用dev-process-framework skill的规则逻辑，分析一下该项目设计文档，是否有需要优化或调整的地方，若有请进行最优调整。
注：本案中该指令执行了三次，以避免问题遗漏。
3.2.2 AssetMgmt 前端页面设计
前面我们已经生成了从“需求细化与决策发现”到“需求规格说明”一整套完整的系统设计文档，但目前还缺少页面设计部分，而页面设计对Web项目的用户体验至关重要。本节，我们将使用 page-mockup skill 完成 AssetMgmt 项目的前端页面设计。
#systemDesign
请使用page-mockup skill完成AssetMgmt项目的前端页面设计，设计过程中可使用frontend-design skill进行页面风格设计。
人工核验页面设计文档是否符合要求，也可以使用码道进行自行查验，根据检验结果优化建议，进行页面设计文档的优化和修改。
#systemDesign
使用dev-process-framework skill的规则逻辑，分析一下该项目设计文档，是否有需要优化或调整的地方，若有请进行最优调整。
注：本案中该指令执行了三次，以避免问题遗漏。
3.2.3 AssetMgmt 测试设计
我们继续使用 test-designer skill 完成 AssetMgmt 项目的测试设计。
#systemDesign
请使用test-designer skill完成AssetMgmt项目的测试设计。
人工核验测试设计文档是否符合要求，也可以使用码道进行自行查验，根据检验结果优化建议，进行测试设计文档的优化和修改。
#systemDesign
使用test-designer skill的规则逻辑，分析一下该项目测试设计文档，是否有需要优化或调整的地方，若有请进行最优调整。
注：本案中该指令执行了三次，以避免问题遗漏。
3.2.4 设计调整与整体优化
前面我们从项目原始需求出发，已经分别完成了AssetMgmt系统设计、页面设计和测试设计，并分别进行了优化和调整。经过人工审核，发现设计中存在一些问题需要进行优化和调整，对话码道：
#systemDesign
请对固定资产管理系统系统设计、页面设计做出如下调整：
1、设计中不可出现emoji表情，请进行合理替换和修改；
2、首页概览和统计分析应在同一个页面，在现有首页概览的基础上，新增两个图表：分类统计和部门统计；
3、设计中包含了通知的相关描述，但并未进行详细设计，请补充此部分的设计；（若已包含请跳过）
4、设计中包含了审批的相关描述，但并未进行详细设计，请补充此部分的设计；（若已包含请跳过）
设计生成完后需人工核验测试设计是否符合要求。若需要进行调整可对话码道进行设计文档的优化和修改。
#systemDesign
请帮我从整体和合理性上综合分析一下项目设计，是否有需要调整和优化的地方。
注：本案中该指令执行了三次，以避免问题遗漏。
前面我们已经完成了AssetMgmt 的整体设计，经过多次优化和调整后，码道在ProjectDocs\systemDesign目录下完成如下重要交付成果：
| 序号 | 文档 | 内容说明 |
|---|---|---|
| 1 | 01-需求细化与决策发现.md | 使用"五个为什么"方法深入分析需求，识别12个关键决策点（单级审批、退库/归还不审批等），定义MoSCoW优先级（Must:认证/资产全流程/审批, Should:统计/通知）和三阶段交付计划，识别技术、业务和项目风险并制定缓解措施。 |
| 2 | 02-架构设计.md | 设计三层架构（表现层、业务逻辑层、数据访问层），记录5个架构决策记录（ADR-001~005，含PyJWT替代python-jose），规划前后端分离架构和Docker容器化部署方案，设计4个核心模块（认证授权/资产管理/审批管理/通知服务），设计安全架构和性能优化策略。 |
| 3 | 03-数据模型设计.md | 设计10个核心数据表（User/Role/Permission/Department/Asset/AssetCategory/AssetStatusLog/Approval/Notification/OperationLog），定义完整的ER关系，设计资产状态流转模型（4状态+合法流转矩阵），规划32个索引和操作日志分区策略，制定数据约束和参照完整性规则。 |
| 4 | 04-API接口设计.md | 设计52个RESTful API端点（认证5+用户6+部门6+分类7+资产14+审批7+统计5+日志2+角色4+通知5+安全防护5），定义统一请求/响应格式，设计JWT双Token认证机制，规划权限控制矩阵，包含SQL注入/XSS/越权等安全防护。 |
| 5 | 05-实施计划.md | 制定四阶段交付计划（第1阶段:基础设施+认证+资产入库, 第2阶段:业务流程+审批, 第3阶段:统计+报表+日志, 第4阶段:测试+部署），分解50+任务到小时级别，明确依赖关系和验收标准，制定风险应对策略和质量保证机制（测试金字塔80%/15%/5%）。 |
| 6 | 06-需求规格说明.md | 完整的需求规格说明书（EARS格式），包含7个功能需求（F01认证/F02资产管理/F03状态管理/F04统计/F05系统管理/F06通知/F07审批）、非功能需求（性能/安全/可用性/兼容性）、约束条件、验收标准、角色权限矩阵。 |
| 7 | 07-页面设计.md | PC Web端完整页面原型设计（共18个页面），采用ASCII线框图+Mermaid流程图，包含登录(P01)/主布局(P02)/首页概览(P03,合并统计)/资产列表-详情-入库-编辑-导入(P04-P08)/审批列表-待审批-我的申请(P09-P11)/部门/用户/分类/日志/角色权限管理(P12-P16)/个人设置/修改密码(P17-P18)/通知列表弹窗。设计风格采用Minimalist Modern，去emoji化。 |
| 8 | 08-测试设计.md | 完整测试设计文档，测试金字塔策略（单元80%/集成15%/E2E 5%），包含85后端UT+86前端UT（认证/状态引擎/审批/权限等）、114集成测试（认证/用户/部门/分类/资产CRUD/业务操作/导入导出/审批/统计/日志/角色/安全防护/通知API）、33 E2E测试（12个核心流程：登录/领用/借用归还/退库/报废/转移/权限隔离/审批驳回/入库/修改密码/通知/首页角色差异化）。总计约318个测试用例，含测试数据设计和覆盖率要求。 |
下一章节中，我们将对AssetMgmt 整体设计进行拆分、重组、补充，以完成AssetMgmt SDD开发详细设计文档。
3.4 AssetMgmt SDD设计
3.4.1 初步生成AssetMgmt SDD
继续对话码道生成AssetMgmt SDD开发详细设计文档：
#systemDesign
请使用function-detail skill帮我生成AssetMgmt项目的SDD文档，要求：
1、每个设计、任务都有明确的需求，并包含需求引用；
2、SDD的任务应按照如下逻辑进行设计：
- 第一部分：基础环境准备与项目初始化，基础环境准备包含完整的windows开发环境部署，项目初始化包含工程目录、API和数据模型初始化。
- 第二部分：项目开发，包含所有AssetMgmt项目业务模块的开发任务，包含前端、后端部分。
- 第三部分：测试与优化，包含测试环境准备、测试用例编写和测试用例执行，我会在本地windows环境进行初次测试，并在测试环境（鲲鹏, 4vCPUs 8GiB, Euler）进行第二次测试。
- 第四部分：项目发布，我会在生产环境（华为云ECS：鲲鹏, 4vCPUs 8GiB, Euler，配置华为云EIP）进行项目部署与发布，
3、SDD设计应当包含对应的任务要求，每个任务都有明确的设计，并包含设计引用。包含：API设计及引用（如适用）、数据模型设计及引用（如适用）、验收标准引用具体的需求验收标准。
4、SDD任务应包含读取前序任务完成情况和基础环境准备与项目初始化情况提醒。
5、在进行SDD任务划分时，应当注意任务切割颗粒度，充分考虑码道的上下文长度。
码道加载 function-detail skill，调用 explore SubAgent 探索项目文档和结构，并自动规划任务开始生成AssetMgmt SDD。
3.4.2 人工核验与调整
人工核验SDD设计文档是否符合要求，经过检验发现如下问题，对话码道进行逐一修改：
在任务 1.1.2:后端项目初始化(FastAPI工程目录+API骨架+数据模型骨架) 中是否在设计中已包含初始化FastAPI后端项目骨架：包含完整目录结构、核心配置、数据库连接、数据模型定义和Alembic迁移配置，若没有请进行补充。
在任务 1.1.1: Windows开发环境部署任务 中是否可以找到完整的window环境部署指导设计或手册，若未找到请进行设计补充。
在任务 3.1.1: 本地Windows测试环境准备 中是否可以找到完整的本地Windows测试环境部署指导设计或手册，若未找到请进行设计补充。
在任务 3.1.2: 鲲鹏测试环境准备 和 任务4.1.2: 华为云ECS生产环境部署与发布 中是否可以找到完整的环境部署指导设计或手册，若未找到请进行设计补充。
请仔细查验tasks中的每一条任务，是否都能找到完整的设计引用，若未找到请补充设计。
3.4.3 需求与设计一致性检查
继续对话码道，对比两份设计文档，确保SDD设计与上一章节中的整体设计内容一致，并且符合新的设计要求。
请对比两份设计文档，确保specs_SDD与systemDesign设计一致没有遗漏。并遵照如下要求检验SDD，是否符合要求：
1、每个设计、任务都有明确的需求，并包含需求引用；
2、SDD的任务应按照如下逻辑进行设计：
- 第一部分：基础环境准备与项目初始化，基础环境准备包含完整的windows开发环境部署，项目初始化包含工程目录、API和数据模型初始化。
- 第二部分：项目开发，包含所有AssetMgmt项目业务模块的开发任务，包含前端、后端部分。
- 第三部分：测试与优化，包含测试环境准备、测试用例编写和测试用例执行，我会在本地windows环境进行初次测试，并在测试环境（鲲鹏, 4vCPUs 8GiB, Euler）进行第二次测试。
- 第四部分：项目发布，我会在生产环境（华为云ECS：鲲鹏, 4vCPUs 8GiB, Euler，配置华为云EIP）进行项目部署与发布，
3、SDD设计应当包含对应的任务要求，每个任务都有明确的设计，并包含设计引用。包含：API设计及引用（如适用）、数据模型设计及引用（如适用）、验收标准引用具体的需求验收标准。
4、SDD任务应包含读取前序任务完成情况和基础环境准备与项目初始化情况提醒。
5、在进行SDD任务划分时，应当注意任务切割颗粒度，充分考虑码道的上下文长度。
注：本案中该指令执行了三次，以避免问题遗漏。
3.4.4 SDD综合分析与优化
经过前面几轮调整和优化，SDD设计已经基本符合项目开发需要。接下来我们进行最后一轮的SDD整体分析与优化
请帮我从整体和合理性上综合分析一下项目SDD设计，是否有需要调整和优化的地方，若有请进行优化调整。
注：本案中该指令执行了三次，以避免问题遗漏。
执行任务执行完成后，自动在.codeartsdoer/specs/asset_mgmt目录下生成如下重要交付成果：
前面我们已经完成了AssetMgmt SDD开发详细设计，经过多次优化和调整后，码道在ProjectDocs\specs_SDD\AssetMgmt目录下完成如下重要交付成果：
| 序号 | 文档 | 核心内容 |
|---|---|---|
| 1 | spec.md | 项目概述、7大功能模块(F01-F07)需求规格、50个功能需求(FR)、43个验收标准(AC)、21个非功能需求(NFR-P/S/U/C)、19个业务规则(BR)、约束条件、验收方法、需求追踪矩阵 |
| 2 | design.md | 技术栈(Vue3/FastAPI/PostgreSQL/APScheduler)、模块化单体架构(前后端分离)、环境变量清单(7项)、Python依赖清单(12包)、侧边栏菜单结构(16项)、工程目录结构(后端9模块+前端9模块)、模块索引、部署架构(开发/测试/鲲鹏测试/生产4套指南) |
| 3 | tasks.md | 任务分解(36个任务)、四阶段流程(环境准备→开发→测试→发布)、需求引用(FR/NFR/AC)、设计引用(章节级)、API引用、数据模型引用、前序任务检查、实现要点、验收标准 |
| 4 | 01-用户认证与权限管理.md | 登录页设计(P01)、JWT双Token认证(8h+7d)、登录锁定(5次/30min)、RBAC权限中间件(25+权限代码)、数据权限过滤(部门隔离)、路由守卫、权限指令、5个API接口、5张数据表 |
| 5 | 02-资产管理.md | 资产列表/详情/入库/编辑/导入页设计(P04~P08)、资产CRUD、状态流转引擎(4种合法流转+管理员强制变更)、分类管理(树形)、批量导入导出(全部校验+事务)、数据权限标注、18个API接口、3张数据表、导入事务策略 |
| 6 | 03-审批管理.md | 审批列表/待审批/我的申请页设计(P09~P11)、统一审批模型(4种类型)、审批状态机(pending→approved/rejected/cancelled)、审批联动资产状态变更、事务一致性设计(同事务+并发保护)、7个API接口、1张数据表 |
| 7 | 04-统计分析.md | 首页概览页设计(P03)、统计聚合查询、分类/部门/状态/趋势统计、报表导出(资产清单+部门统计+分类统计)、ECharts图表(饼图+柱状图+统计卡片)、数据权限标注、8个API接口、无独立数据表(基于assets聚合) |
| 8 | 05-系统管理.md | 部门管理(P12)/用户管理(P13)/角色权限(P16)/操作日志(P15)/个人设置(P17)/修改密码(P18)页设计、组织架构管理(树形CRUD)、角色权限管理、用户状态切换(禁用/启用)、操作日志记录(中间件自动记录)、10个API接口 |
| 9 | 06-站内通知.md | 通知图标+弹窗+列表页设计(P19)、通知服务(4种触发时机)、定时任务调度(借用超期检测每日08:00+通知过期清理每日02:00)、轮询机制(30s)、BR-N3实现(30天清理)、5个API接口、1张数据表 |
| 10 | 07-数据模型详细设计.md | 数据库设计原则(UUID主键/软删除/乐观锁/JSONB扩展)、12张数据表完整定义、索引设计(30+)、外键关系、参照完整性、预置角色权限(3角色+25+权限)、数据字典(7类)、数据约束(业务+验证规则) |
| 11 | 08-API接口详细设计.md | RESTful API规范、统一响应格式、健康检查端点、约70个API端点完整定义(认证/用户/部门/分类/资产/审批/统计/日志/角色/通知)、限流策略(4类)、HTTP状态码(11种)、核心端点请求/响应JSON示例(5个) |
| 12 | 09-前端详细设计.md | Vue3技术栈(Vite+TypeScript+ElementPlus+Pinia+Axios+ECharts)、项目结构(目录树)、页面设计清单(P01~P19)、核心组件设计(Axios封装+状态管理+路由守卫+权限指令)、设计规范(布局+组件+状态标签+数据格式+交互+错误提示+响应式)、表单验证规则(3类) |
3.5 AssetMgmt项目介绍
3.5.1 项目架构设计
架构说明：
| 层次 | 组件 | 职责 |
|---|---|---|
| 前端层 | Vue3 SPA | 页面渲染、用户交互、状态管理、API调用 |
| 网关层 | Nginx | 反向代理、静态资源服务、HTTPS终止、负载均衡 |
| 应用层 | FastAPI + Uvicorn | 业务逻辑处理、认证授权、数据验证、定时任务调度 |
| 数据层 | Neon PostgreSQL | 业务数据持久化、关系查询、事务支持 |
| 存储层 | 本地文件系统 | Excel导入文件临时存储、报表导出文件生成 |
3.5.2 技术栈
| 层次 | 技术选型 | 版本 | 说明 |
|---|---|---|---|
| 前端框架 | Vue.js | 3.4+ | 组合式API，TypeScript支持 |
| UI组件库 | Element Plus | 2.x | 企业级Vue3组件库 |
| 状态管理 | Pinia | 2.x | Vue3官方状态管理 |
| HTTP客户端 | Axios | 1.x | HTTP请求库 |
| 前端构建 | Vite | 5.x | 快速构建工具 |
| 图表库 | ECharts | 5.x | 统计图表展示 |
| 后端框架 | FastAPI | 0.110+ | 高性能异步Web框架 |
| ASGI服务器 | Uvicorn | 0.30+ | ASGI服务器 |
| ORM | SQLAlchemy | 2.x | Python ORM |
| 数据验证 | Pydantic | 2.x | 数据校验和序列化 |
| 数据库 | Neon PostgreSQL | 15+ | 云端PostgreSQL |
| 迁移工具 | Alembic | 1.x | 数据库迁移管理 |
| JWT认证 | PyJWT | 2.x | JWT Token生成验证 |
| 密码加密 | bcrypt | - | 密码哈希 |
| 定时任务 | APScheduler | 3.x | 借用超期检测+通知清理 |
| Excel处理 | openpyxl | 3.x | 导入导出 |
| Web服务器 | Nginx | - | 反向代理和静态资源 |
| 容器化 | Docker | - | 容器化部署 |
| 容器编排 | Docker Compose | - | 多容器编排 |
3.5.3 系统分层设计
前端分层
frontend/
├── public/ # 公共资源
├── src/
│ ├── api/ # API接口封装
│ │ ├── auth.ts # 认证API
│ │ ├── asset.ts # 资产API
│ │ ├── user.ts # 用户API
│ │ ├── approval.ts # 审批API
│ │ ├── stats.ts # 统计API
│ │ ├── notification.ts # 通知API
│ │ └── log.ts # 日志API
│ ├── assets/ # 静态资源(图片/字体等)
│ ├── components/ # 公共组件
│ │ ├── common/ # 通用组件
│ │ │ ├── StatusTag.vue # 状态标签
│ │ │ └── PageHeader.vue # 页面标题
│ │ └── business/ # 业务组件
│ ├── composables/ # 组合式函数
│ │ ├── useAuth.ts # 认证逻辑
│ │ ├── usePermission.ts # 权限逻辑
│ │ └── usePagination.ts # 分页逻辑
│ ├── directives/ # 自定义指令
│ │ └── permission.ts # 权限指令
│ ├── layouts/ # 页面布局
│ │ ├── DefaultLayout.vue # 主布局
│ │ └── BlankLayout.vue # 空白布局(登录页)
│ ├── router/ # 路由配置
│ │ ├── index.ts # 路由入口
│ │ ├── guards.ts # 路由守卫
│ │ └── modules/ # 路由模块
│ ├── stores/ # Pinia状态管理
│ │ ├── auth.ts # 认证状态
│ │ ├── user.ts # 用户状态
│ │ ├── notification.ts # 通知状态
│ │ └── app.ts # 应用状态
│ ├── styles/ # 全局样式
│ ├── utils/ # 工具函数
│ │ ├── request.ts # HTTP请求封装
│ │ ├── format.ts # 格式化工具
│ │ └── validate.ts # 验证规则
│ └── views/ # 页面组件
│ ├── auth/ # 登录页(P01)
│ ├── dashboard/ # 首页概览(P03)
│ ├── asset/ # 资产管理(P04~P08)
│ ├── approval/ # 审批管理(P09~P11)
│ ├── stats/ # 统计分析
│ ├── system/ # 系统管理(P12~P18)
│ ├── notification/ # 通知管理(P19)
│ └── error/ # 错误页面(403/404)
├── package.json
├── vite.config.ts
└── tsconfig.json
后端分层
backend/
├── app/
│ ├── api/ # API路由层
│ │ ├── v1/ # API版本1
│ │ │ ├── auth.py # 认证路由
│ │ │ ├── users.py # 用户路由
│ │ │ ├── assets.py # 资产路由
│ │ │ ├── categories.py # 分类路由
│ │ │ ├── departments.py # 部门路由
│ │ │ ├── approvals.py # 审批路由
│ │ │ ├── notifications.py # 通知路由
│ │ │ ├── stats.py # 统计路由
│ │ │ ├── logs.py # 日志路由
│ │ │ └── roles.py # 角色权限路由
│ │ └── deps.py # 依赖注入
│ ├── core/ # 核心配置
│ │ ├── config.py # 配置管理
│ │ ├── security.py # 安全相关(JWT/密码/权限)
│ │ └── exceptions.py # 异常定义
│ ├── models/ # 数据模型层(SQLAlchemy)
│ │ ├── user.py # User, Role, Permission, RolePermission, RefreshToken
│ │ ├── department.py # Department
│ │ ├── asset.py # Asset, AssetCategory, AssetStatusLog
│ │ ├── approval.py # Approval
│ │ ├── notification.py # Notification
│ │ └── operation_log.py # OperationLog
│ ├── schemas/ # 数据验证模式
│ │ ├── auth.py # 认证Schema
│ │ ├── asset.py # 资产Schema
│ │ ├── user.py # 用户Schema
│ │ ├── approval.py # 审批Schema
│ │ ├── notification.py # 通知Schema
│ │ ├── stats.py # 统计Schema
│ │ ├── log.py # 日志Schema
│ │ └── common.py # 通用Schema(分页/响应)
│ ├── services/ # 业务逻辑层
│ │ ├── auth_service.py # 认证服务
│ │ ├── asset_service.py # 资产服务
│ │ ├── approval_service.py # 审批服务
│ │ ├── notification_service.py # 通知服务
│ │ ├── stats_service.py # 统计服务
│ │ ├── log_service.py # 日志服务
│ │ └── user_service.py # 用户服务
│ ├── repositories/ # 数据访问层
│ │ ├── base.py # 基础Repository(泛型CRUD)
│ │ ├── asset_repo.py # 资产Repository
│ │ └── user_repo.py # 用户Repository
│ ├── utils/ # 工具函数
│ │ ├── excel.py # Excel导入/导出
│ │ └── codegen.py # 资产编码生成
│ ├── tasks/ # 定时任务
│ │ ├── scheduler.py # APScheduler调度器配置
│ │ └── notification_tasks.py # 借用超期检测+通知清理
│ └── main.py # 应用入口
├── alembic/ # 数据库迁移
├── requirements.txt
└── Dockerfile
3.5.4 需求矩阵
| 需求ID | 需求描述(简) | 任务引用 | 设计文档引用 |
|---|---|---|---|
| FR-1.1.1 | 用户名密码登录 | 任务2.1.1 | 01-用户认证与权限管理.md#1.1 |
| FR-1.1.2 | 登录失败锁定 | 任务2.1.1 | 01-用户认证与权限管理.md#1.1 |
| FR-1.1.3 | JWT Token生成 | 任务2.1.1 | 01-用户认证与权限管理.md#1.1 |
| FR-1.1.4 | Token刷新机制 | 任务2.1.1 | 01-用户认证与权限管理.md#1.1 |
| FR-1.1.5 | 登出Token黑名单 | 任务2.1.1 | 01-用户认证与权限管理.md#1.1 |
| FR-1.1.6 | Token过期跳转 | 任务2.1.3 | 01-用户认证与权限管理.md#2 |
| FR-1.2.1~1.2.6 | RBAC权限控制 | 任务2.1.2 | 01-用户认证与权限管理.md#1.2 |
| FR-1.3.1~1.3.4 | 组织架构管理 | 任务2.2.1, 任务2.2.2 | 05-系统管理.md#1 |
| FR-2.1.1~2.1.3 | 分类管理 | 任务2.3.1 | 02-资产管理.md#1 |
| FR-2.2.1~2.2.6 | 资产入库 | 任务2.3.2, 任务2.3.3 | 02-资产管理.md#1.2 |
| FR-2.3.1~2.3.4 | 资产领用 | 任务2.4.3 | 02-资产管理.md#1.2 |
| FR-2.4.1~2.4.3 | 资产退库 | 任务2.4.3 | 02-资产管理.md#1.2 |
| FR-2.5.1~2.5.5 | 借用/归还 | 任务2.4.3 | 02-资产管理.md#1.2 |
| FR-2.6.1~2.6.3 | 资产报废 | 任务2.4.3 | 02-资产管理.md#1.2 |
| FR-2.7.1~2.7.3 | 资产转移 | 任务2.4.3 | 02-资产管理.md#1.2 |
| FR-3.1.1~3.1.4 | 状态流转 | 任务2.4.1 | 02-资产管理.md#1.1 |
| FR-3.2.1~3.2.3 | 状态变更记录 | 任务2.4.1 | 02-资产管理.md#1.1 |
| FR-4.1.1~4.1.3 | 首页概览 | 任务2.7.1, 任务2.7.3 | 04-统计分析.md#1.1 |
| FR-4.2.1~4.2.3 | 分类统计 | 任务2.7.1, 任务2.7.3 | 04-统计分析.md#1.1 |
| FR-4.3.1~4.3.3 | 部门统计 | 任务2.7.1, 任务2.7.3 | 04-统计分析.md#1.1 |
| FR-4.4.1~4.4.4 | 报表导出 | 任务2.7.2, 任务2.7.3 | 04-统计分析.md#1.2 |
| FR-5.1.1~5.1.3 | 用户管理 | 任务2.2.3, 任务2.2.4 | 05-系统管理.md#1 |
| FR-5.2.1~5.2.4 | 操作日志 | 任务2.8.1, 任务2.8.2 | 05-系统管理.md#1.2 |
| FR-6.1.1~6.1.6 | 通知管理 | 任务2.6.1, 任务2.6.2 | 06-站内通知.md#1 |
| FR-7.1.1~7.1.8 | 审批管理 | 任务2.4.2, 任务2.4.4 | 03-审批管理.md#1 |
3.5.5 任务矩阵
| 序号 | 部分 | 模块 | 任务编号 | 任务名称 |
|---|---|---|---|---|
| 1 | 第1部分：基础环境准备 | 环境部署 | 任务1.1.1 | Windows开发环境部署 |
| 2 | 任务1.1.2 | 后端项目初始化(FastAPI工程目录+数据模型) | ||
| 3 | 任务1.1.3 | 前端项目初始化(Vue3工程目录+API封装骨架) | ||
| 4 | 第2部分：项目开发 | 模块1: 用户认证与权限管理 | 任务2.1.1 | JWT认证服务实现(登录/登出/Token刷新/锁定) |
| 5 | 任务2.1.2 | RBAC权限中间件与预置数据初始化 | ||
| 6 | 任务2.1.3 | 认证前端实现(登录页面+路由守卫+权限指令) | ||
| 7 | 模块2: 组织架构管理 | 任务2.2.1 | 部门管理后端(API+树形结构) | |
| 8 | 任务2.2.2 | 部门管理前端(树形组件+CRUD交互) | ||
| 9 | 任务2.2.3 | 用户管理后端(API+CRUD+密码重置) | ||
| 10 | 任务2.2.4 | 用户管理前端+角色权限管理前端 | ||
| 11 | 模块3: 资产管理 | 任务2.3.1 | 资产分类管理(后端+前端) | |
| 12 | 任务2.3.2 | 资产入库后端(API+编码生成+数据权限) | ||
| 13 | 任务2.3.3 | 资产入库前端+资产列表前端 | ||
| 14 | 任务2.4.1 | 资产状态流转引擎 | ||
| 15 | 任务2.4.2 | 审批管理后端(申请/审批/撤销/状态联动) | ||
| 16 | 任务2.4.3 | 资产业务操作API(领用/退库/借用/归还/报废/转移) | ||
| 17 | 任务2.4.4 | 审批与资产业务前端(审批列表+资产操作交互) | ||
| 18 | 任务2.5.1 | 资产Excel批量导入导出(后端+前端) | ||
| 19 | 模块4: 站内通知 | 任务2.6.1 | 站内通知后端(通知创建+未读角标+超期提醒) | |
| 20 | 任务2.6.2 | 站内通知前端(通知弹窗+未读角标轮询) | ||
| 21 | 模块5: 统计分析 | 任务2.7.1 | 统计分析后端(首页概览+分类/部门/状态统计) | |
| 22 | 任务2.7.2 | 报表导出后端(资产清单+部门统计+分类统计) | ||
| 23 | 任务2.7.3 | 统计分析前端(首页概览+图表+报表导出) | ||
| 24 | 模块6: 操作日志与收尾 | 任务2.8.1 | 操作日志后端(记录中间件+查询+导出) | |
| 25 | 任务2.8.2 | 操作日志前端+个人设置+修改密码+全局异常处理 | ||
| 26 | 第3部分：测试与优化 | 测试环境准备 | 任务3.1.1 | 本地Windows测试环境准备 |
| 27 | 任务3.1.2 | 鲲鹏测试环境准备 | ||
| 28 | 测试用例编写 | 任务3.2.1 | 后端单元测试编写(认证+状态引擎+审批+验证) | |
| 29 | 任务3.2.2 | 前端单元测试编写(组件+Store+工具函数) | ||
| 30 | 任务3.2.3 | API集成测试编写 | ||
| 31 | 任务3.2.4 | E2E测试用例编写 | ||
| 32 | 测试执行 | 任务3.3.1 | 本地Windows环境测试执行与Bug修复 | |
| 33 | 任务3.3.2 | 鲲鹏测试环境测试执行 | ||
| 34 | 第4部分：项目发布 | 生产环境部署 | 任务4.1.1 | 生产环境Docker镜像构建与优化 |
| 35 | 任务4.1.2 | 华为云ECS生产环境部署与发布 | ||
| 36 | 任务4.1.3 | 项目发布验收与文档收尾 |
四、案例总结&补充
4.1 案例阶段性总结
截至当前，AssetMgmt 项目已完成两套完整文档体系的构建：
-
系统整体设计文档：从原始需求出发，系统性地完成了需求细化、架构设计、详细设计及实施计划的完整流程，并提供了明确的架构选型与技术决策依据。该文档为后续开发工作提供了完整的思路框架与功能溯源支持。
-
SDD文档（软件设计文档）：
-
采用“需求—设计—任务”三层架构，确保每一项需求均有对应的设计与任务支撑；
-
支持AI智能体实现 FR → Task → Design 的完整追溯链路，以指导精准代码生成；
-
每项任务均明确关联需求ID（FR）、验收标准（AC）、API接口及数据表信息。
两套文档定位明确、互为补充：SDD文档作为开发过程中的主要指导依据，系统整体设计文档作为辅助参考。二者协同使用，可有效保障项目的顺利推进与高质量交付。
本案例以华为云码道 AI IDE 为核心开发工具，结合 dev-process-framework、page-mockup、function-detail、test-designer 及 SDD 等技能套件，从原始需求出发，系统性地完成了包括需求细化、架构设计、详细设计在内的全流程设计工作。设计内容涵盖系统架构、数据模型、API、前端界面及测试方案，并制定了相应的实施计划，生成了系统整体设计和SDD两套完整的项目设计文档，为下一步项目实施提供了完整、可落地的设计基础。
4.2 附录
本案例中所涉及的AssetMgmt固定资产管理系统的相关需求、设计等文档已上传至gitCode，请根据需要进行下载：
- AssetMgmt固定资产管理系统 - 项目背景与原始需求；
- AssetMgmt固定资产管理系统 - AssetMgmt 整体设计；
- AssetMgmt固定资产管理系统 - AssetMgmt SDD；
本案例中所使用的skills下载路径如下：
码道领航AssetMind智能资产系统开发系列案例：
- AssetMgmt固定资产管理系统（一）：码道搭台，设计筑基 ← 当前案例
- AssetMgmt固定资产管理系统（二）：码道领航，落地生根
- AssetMgmt固定资产管理系统（三）：码道修缺，空间补全（持续开发中，敬请期待）
- AssetMgmt固定资产管理系统（四）：码道有仓，流水筑链（持续开发中，敬请期待）
- AssetMgmt固定资产管理系统（五）：码道发布，上线收官（持续开发中，敬请期待）
4.3 反馈改进建议
如您在案例实操过程中遇到问题或有改进建议，可以到论坛帖评论区反馈即可，我们会及时响应处理，谢谢！
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
0
0- 0
已为社区贡献101条内容
所有评论(0)