企业官网建设流程全解析

一、项目定位与最终成果

这是一个企业级前后端分离电商平台，从截图可以看到它已经完整运行：用户（localhost:3000）——第一张截图展示的就是用户前台首页。顶部蓝色导航栏包含"首页、全部商品、购物车、登录"四个入口；中间是蓝色渐变的 Hero Banner，写着"欢迎来到电商平台 / 品质生活，从这里开始"；下方分为两个区域：分类导航（电子产品、服装鞋帽、食品饮料、家居用品、图书音像五个一级分类）和推荐商品网格（8 个商品卡片，展示封面图、名称、红色价格标签）。管理后台（localhost:3001）——第二张截图是管理后台的数据大盘。左侧导航包含数据大盘、用户管理、商品管理、分类管理、订单管理、系统配置、日志查看七个功能模块。主区域顶部是五个指标卡片（总用户数 6、上架商品 22、今日订单 0、今日销售额 ¥0、待处理订单 0），中间是"近30天订单趋势"折线图（使用 ECharts 渲染，蓝色柱状图表示订单数、绿色折线表示金额），底部是"热销商品 TOP10"表格。

二、开发方法论：superpower + SDD + TDD

整个项目的核心开发理念是用 superpower 工具约束 AI Agent 按照规范化流程工作。superpower 底层集成了两套开发规范：SDD（Specification-Driven Development，规格驱动开发）——先写清楚"做什么"，再动手写代码。项目中体现为 docs/superpowers/specs/ 下的设计规格文档，它定义了数据库模型、API 接口、业务流程、安全策略等所有"契约"，Agent 编码时必须严格遵守这份规格。TDD（Test-Driven Development，测试驱动开发）——每个业务模块都配有测试目录。从实施计划可以看到，users 模块有 test_auth.py、test_profile.py、test_address.py；goods 模块有 test_category.py、test_goods.py、test_search.py；order 模块有 test_order.py、test_tasks.py。Agent 在实现功能的同时必须编写对应测试。

三、十步开发流程详解

第 1 步：头脑风暴（brainstorming skill）

与 Agent 进行多轮对话，逐步确认以下关键决策：

• 技术架构：确定采用前后端分离方案，后端提供 RESTful API，前端通过 Axios 调用
• 技术栈选型：后端 Django 5.x + DRF + SimpleJWT + Celery；前端 Vue 3（Composition API）+ Vite + Pinia + Element Plus；数据库开发用 SQLite、生产用 PostgreSQL；缓存和消息队列用 Redis
• 模块划分：用户（users）、商品（goods）、购物车（cart）、订单（order）、管理后台（admin_dashboard）五大模块
• 功能确认：每个模块的具体功能点，比如订单模块需要支持下单、支付、取消、确认收货、超时自动关单等

这一步的产出是双方对"要做什么"达成共识。

第 2 步：编写设计规格文档（writing-plan skill → spec）

产出文件：docs/superpowers/specs/2026-07-29-ecommerce-platform-design.md这份 322 行的设计文档是整个项目的"宪法"，内容极其详尽：

• 数据库模型：定义了 8 张表的完整字段设计——user（继承 AbstractUser）、user_address、goods_category（支持二级分类自关联）、goods（含 recommend_weight 推荐权重）、goods_image（轮播图）、cart（user+goods 唯一约束）、order_info（含 address JSON 快照）、order_item（含商品名称和封面快照）
• API 接口设计：6 大模块约 30 个端点，统一响应格式 {"code": 200, "message": "success", "data": {...}}
• 核心业务流程：下单流程（select_for_update 行锁 → 库存检查 → 创建订单 → 清购物车 → 启动 Celery 延迟任务）、支付流程（策略模式，AlipayStrategy / WechatStrategy）、超时关单流程（30 分钟 ETA + Celery Beat 兜底扫描）
• 安全设计：JWT 认证、接口权限隔离、支付签名验证、OSS 服务端签名直传、CORS 白名单
• 部署架构：Nginx 反向代理 + Gunicorn + Redis + Celery Worker + PostgreSQL + 阿里云 OSS

第 3 步：编写实施计划（writing-plan skill → plan）

这份文档将设计规格拆解为可逐步执行的 Task 清单，使用 checkbox 语法（- [ ]）跟踪进度。每个 Task 明确标注：

• 需要创建/修改的文件列表
• 接口契约（Produces / Consumes）
• 具体的代码实现步骤（含完整代码片段）
• 全局约束（Python 3.14+、Node.js v24+、中文文本、Mock 模式支付等）

例如 Task 1 是"后端项目脚手架搭建"，精确到要创建哪些目录、requirements 里写哪些依赖及版本范围、settings/base.py 的完整配置内容。

第 4 步：执行计划开始编码（execute-plan skill）

Agent 按照实施计划逐 Task 执行。从项目实际代码可以看到执行结果：

后端——backend/apps/ 下五个完整的 Django App，每个都有 models.py、serializers.py、views.py、urls.py。以订单模块为例，OrderInfo 模型实现了四种状态（pending/paid/completed/cancelled）、唯一订单号生成器（时间戳+UUID）、JSON 地址快照、双索引优化；OrderItem 保存了下单时的价格和商品名称快照，确保历史订单不受商品后续修改影响。

前端用户端——12 个页面组件（Home、Login、Register、GoodsList、GoodsDetail、Cart、OrderConfirm、OrderList、OrderDetail、Pay、Profile、AddressManage），路由使用懒加载，购物车/订单/个人中心等页面设置了 requiresAuth 路由守卫。首页 Home.vue 通过 Promise.all 并发请求分类和推荐商品数据，使用 Element Plus 的 el-row/el-col 实现响应式网格布局。

管理后台——8 个页面（Dashboard、UserManage、GoodsManage、CategoryManage、OrderManage、SystemConfig、LogViewer、Login），Dashboard 使用 vue-echarts 渲染订单趋势图，通过 Promise.all 并发拉取统计数据、趋势数据、热销排行三组 API。

第 5 步：编辑项目配置

backend/config/settings/ 下分了三套配置：

• base.py：公共配置——INSTALLED_APPS 注册五个业务 App 和第三方库、CORS 设置、DRF 全局配置、JWT 参数、时区设为 Asia/Shanghai、语言设为 zh-hans、自定义用户模型 AUTH_USER_MODEL = 'users.User'
• dev.py：开发环境——DEBUG=True、SQLite 数据库、CORS_ALLOW_ALL_ORIGINS
• prod.py：生产环境——DEBUG=False、PostgreSQL、Gunicorn、CORS 白名单

此外还有 docker-compose.yml 编排了 Redis、Django 后端、Celery Worker 三个服务容器。

第 6 步：初始化数据（init_db.py）

这是一个 322 行的完整初始化脚本，支持三种运行模式（完整初始化 / 只迁移 / 只导数据），执行以下操作：

• 创建 3 个用户：admin（管理员）、demo（测试用户）、user1（普通用户），密码使用 Django PBKDF2 哈希
• 创建 5 个一级分类 + 12 个二级分类的树形结构
• 创建 22 个示例商品，覆盖所有子分类，每个商品有真实的名称、价格、库存、销量、描述和 picsum.photos 占位图
• 为 demo 用户创建一个默认收货地址
• 使用 @transaction.atomic 保证数据一致性，get_or_create 保证幂等性（重复运行不会报错）

从管理后台截图可以看到初始化结果：总用户数 6、上架商品 22，与脚本设计完全吻合。

第 7 步：启动测试与错误修复

启动三个服务（Django 8000、用户前端 3000、管理后台 3001），遇到报错让 Agent 诊断修复。这个过程是迭代式的——Agent 提示代码修改方案，修复后重新验证，直到所有服务正常运行、页面正确渲染。

第 8 步：编写启动脚本（start.sh）

产出一个 196 行的一键启动脚本，功能非常完善：

• 端口冲突检测（启动前检查 8000/3000/3001 是否被占用）
• 虚拟环境自动激活（source venv/Scripts/activate）
• 依赖自动安装（检测 node_modules 是否存在）
• 健康检查轮询（curl 探测各服务是否就绪，最多等 15 秒）
• 彩色日志输出（不同服务用不同颜色标识）
• 进程管理和优雅退出（trap SIGINT/SIGTERM，统一 kill 所有子进程）
• 启动完成后打印汇总信息（访问地址 + 测试账号）

第 9 步：同步规范到 Agent 管理文件

将项目约定（编码风格、API 响应格式、命名规范、架构边界等）写入 AGENTS.md / CLAUDE.md，这样 Agent 在后续迭代中会自动加载这些约束，不需要每次重复交代。

第 10 步：逐步推进

基础框架稳定后，进入持续迭代阶段——逐步检查各模块功能完整性、补充边界情况、优化性能、完善 UI 细节。

四、技术架构亮点

从源码中可以提炼出几个值得注意的设计：

商品模型的推荐机制——Goods 表有 recommend_weight 字段，首页推荐商品按此字段降序排列，初始化时直接用销量作为权重，实现了"卖得越好越靠前"的效果。

订单的数据快照设计——OrderInfo 用 JSONField 存储下单时的完整地址快照，OrderItem 保存商品名称和封面快照。这意味着即使用户后来修改了地址、商品改了名字或下架了，历史订单展示的信息依然准确。

前端路由守卫——购物车、订单、个人中心等需要登录的页面统一通过 meta.requiresAuth 标记，router.beforeEach 全局守卫检查 localStorage 中的 JWT token，未登录自动跳转登录页。

管理后台的数据可视化——Dashboard 使用 ECharts 双 Y 轴图表（左轴订单数用柱状图、右轴金额用折线图），配合 StatCard 组件和 el-table，构成了完整的运营数据看板。

五、总结

这个项目的价值不仅在于最终产出了一个功能完整的电商平台，更在于它展示了一套可复用的 AI 协作开发方法论：先用头脑风暴对齐认知，再用规格文档锁定契约，然后用实施计划拆解任务，最后让 Agent 在约束下高效执行。superpower 工具在整个过程中扮演了"技术总监"的角色，确保 Agent 不会跳过设计直接写代码、不会偏离规格随意发挥、不会遗漏测试。这种 SDD + TDD 的工作流，对于任何中大型项目都有参考意义。