面向场景：本指南基于"智慧社区管理平台"全栈项目的真实 AI 编码过程提炼，旨在为后续新项目的 AI 辅助开发提供可复用的方法论、流程模板和协作规范。
- 1. 项目概览
- 2. AI 编码方法论总览
- 3. 核心实践一：需求驱动，设计先行
- 4. 核心实践二：六大模块高内聚低耦合拆分
- 5. 核心实践三：分阶段增量交付
- 6. 核心实践四：标准化交接提示词（关键创新）
- 7. 核心实践五：分层架构一致性与代码约束
- 8. 核心实践六：四层验证闭环
- 9. 创新点注入策略：独立服务化集成
- 10. 团队协作拓扑
- 11. 可复用模板集
- 12. 经验总结与适用场景
- 13. 附录：文生图提示词
智慧社区管理平台是一个覆盖 Web 管理端 + 居民移动端 + 后端服务 + 数据库 + AI 工具集 的一体化全栈系统，面向小区日常管理和社区治理服务两类核心场景，连接居民、物业、业委会、社区、街道、网格员和志愿者等多类用户角色。
| 层级 | 技术选型 |
|---|---|
| Web 管理端 | Vue 3 + Vite + TypeScript + Element Plus + ECharts + Leaflet |
| 居民移动端 | Flutter 3.x + Provider 状态管理 |
| 后端服务 | Spring Boot 2.7 / 3.x + MyBatis Plus + MySQL + Redis + WebSocket |
| 数据库 | MySQL 8.x（18 个初始化脚本，含字典、权限、种子数据） |
| AI 工具（本地部署） | PaddleOCR（身份证识别）、face_recognition + OpenCV（人脸签到）、Ollama + Qwen（AI Agent） |
| AI 工具（API 集成） | 百度 AI 车牌识别 API、百度 AI 图片理解 API |
| 地图 | 高德地图 SDK（移动端网格地图）/ Leaflet（管理端） |
| 指标 | 数据 |
|---|---|
| 后端 Java 源文件 | 约 200+ 实体/Mapper/Service/Controller |
| 前端 Vue 页面 | 25+ 独立管理端业务页面 + 居民 H5 端 |
| Flutter 移动端页面 | 20+ 功能模块页面 |
| 数据库 SQL 脚本 | 18 个增量脚本 |
| 静态权限码 | 117 个 |
| 动态流转动作权限 | 31 个 |
| 演示角色 | 8 个多层级角色 |
| AI 工具独立服务 | 3 个（OCR、人脸签到、Ollama Agent） |
| 技术文档 | 15+ 份 |
本项目的 AI 编码方法论可以概括为六个字："拆、约、叠、验、注、协"。
┌──────────────────────────────────────────────────────────────────┐
│ AI Coding 六大核心实践 │
├─────────────┬────────────────────────────────────────────────────┤
│ ① 设计先行 │ 以系统设计文档为唯一基线，不凭空设计 │
│ ② 模块拆分 │ 需求拆为六大高内聚低耦合模块，分派给 6 人并行开发 │
│ ③ 增量交付 │ 按 8.1→8.6 六个阶段递进，每阶段有明确输入输出 │
│ ④ 提示词复用 │ 每阶段产出标准化的"新对话提示词"，新AI会话可续接 │
│ ⑤ 分层约束 │ 强制沿用已有命名/分层/响应格式/权限体系 │
│ ⑥ 四层验证 │ 编译→权限SQL一致性→种子数据→运行时冒烟 │
└─────────────┴────────────────────────────────────────────────────┘
需求规格说明书
↓
系统设计文档（含 6 阶段开发计划、数据库设计、接口规范）
↓
┌─────────────────────────────────────────────────────────┐
│ 阶段一 (8.1)：基础框架 + JWT + RBAC + 系统管理 CRUD │
│ 阶段二 (8.2)：社区/小区/房屋/居民/车辆档案 │
│ 阶段三 (8.3)：问题上报/事件流转/巡查管理 │
│ 阶段四 (8.4)：志愿服务/便民/就业/公告 │
│ 阶段五 (8.5)：统计分析/日志审计/居民H5接口 │
│ 阶段六 (8.6)：部署文档/验收修复/演示数据 │
└─────────────────────────────────────────────────────────┘
↓
创新点注入（4人并行）→ 闭环联调测试（1人）→ 界面美化+数据完善（1人）
↓
验收交付
任何一行 AI 生成的代码，必须有一条可追溯的设计基线。
本项目以 docs/智慧社区管理平台系统设计文档.md（约 2400 行）作为唯一开发基线，包含：
- 第 1 章：需求分析（项目定位、建设目标、用户角色、业务边界、核心流程）
- 第 2 章：架构设计（技术选型、模块划分、部署拓扑）
- 第 3 章：数据库设计（ER 图、表结构、字段说明、索引设计）
- 第 4 章：接口设计（RESTful 规范、请求/响应格式、错误码体系）
- 第 5 章：权限设计（RBAC 模型、菜单权限、按钮权限、数据权限）
- 第 6 章：页面设计（管理端布局、移动端布局、页面路由规划）
- 第 7 章：项目目录结构
- 第 8 章：分阶段开发计划（8.1 ~ 8.6，每阶段有目标、交付物、验收标准）
- 第 9 章：验收与测试方案
| 步骤 | 内容 |
|---|---|
| 1 | 编写需求规格说明书，明确业务边界和用户角色 |
| 2 | 产出系统设计文档，至少覆盖架构、数据库、接口、权限、页面、分阶段计划 |
| 3 | 设计文档完成后，再进行任何编码；AI 的每次对话都引用设计文档作为上下文 |
| 4 | 如发现设计缺陷，先指出并等待确认，不得擅自修改架构、数据库结构或接口规范 |
将整个项目按 业务领域 和 技术层级 两个维度拆分为六个高内聚、低耦合的模块。每个模块有清晰的所有者、交付边界和接口契约。
| 模块编号 | 模块名称 | 技术栈 | 核心职责 | 对外接口 |
|---|---|---|---|---|
| M1 | Web 管理端 | Vue 3 + Element Plus | 管理后台全部页面（25+ 业务页） | 调用后端 REST API |
| M2 | 后端核心服务 | Spring Boot + MyBatis Plus | 全部业务逻辑、权限、数据访问 | REST API /api/v1/* |
| M3 | 居民移动端 | Flutter | 居民 H5/App 端全部页面（20+ 页面） | 调用后端 REST API |
| M4 | 数据库 | MySQL + SQL 脚本 | 表结构、字典、权限、种子数据 | JDBC（M2 调用） |
| M5 | AI 工具集 | Python FastAPI/Flask | 独立 AI 推理服务 | HTTP API（M2 调用） |
| M6 | 部署与文档 | Nginx + Docker + Markdown | 部署配置、技术文档、验收文档 | — |
M1 (Web端) ──REST──→ M2 (后端) ──JDBC──→ M4 (数据库)
│
M3 (移动端) ──REST──→ ├──HTTP──→ M5 (AI工具)
│
权限/认证/日志 ←─┘
关键约束：
- 前端（M1/M3）不直接访问数据库
- 前端（M1/M3）不直接调用 AI 工具（M5），统一由后端（M2）代理
- 模块间仅通过 REST API 或 JDBC 通信，无代码级耦合
- 拆分前先画模块拓扑图，确认每个模块的职责边界和对外接口
- 每个模块分配一个所有者，负责该模块的所有 AI 对话
- 接口先行：在编码前先约定 API 路径、请求/响应格式、错误码
- 共享上下文：所有人共享同一份设计文档和数据库 Schema
不追求一次性完成所有功能，而是按 6 个阶段递进，每个阶段有明确的"输入→交付→验证→交接"闭环。
| 阶段 | 设计文档对应章节 | 核心目标 | 交付物 | 验证标准 |
|---|---|---|---|---|
| 阶段一 | 8.1 | 基础框架搭建 | JWT 登录、RBAC 权限、系统管理 CRUD | mvn test 通过 + npm run build 通过 + 管理员登录成功 + 权限拦截验证 |
| 阶段二 | 8.2 | 基础档案管理 | 社区/小区/网格/楼栋/单元/房屋/居民/车辆/家庭成员真实 CRUD | 同上 + 数据权限收窄验证 + 层级校验 |
| 阶段三 | 8.3 | 治理与服务闭环 | 问题工单/事件流转/巡查管理含状态机 | 同上 + 流转记录链路完整 |
| 阶段四 | 8.4 | 便民服务模块 | 志愿服务/便民/就业/公告 CRUD + 报名/申请/投递流转 | 同上 + 时长累计/评价闭环 |
| 阶段五 | 8.5 | 统计与审计 | 统计分析/操作日志/居民H5真实接口/文件上传 | 同上 + 占位代码清零 |
| 阶段六 | 8.6 | 交付收口 | 部署文档/验收测试/多角色演示数据/问题修复 | 全部角色登录验证 + 菜单差异检查 + 接口冒烟 |
┌─────────────────────────────────────────────────────────┐
│ 1. 输入上一阶段的"新对话提示词" │
│ 2. AI 阅读设计文档 + 现有代码 + SQL │
│ 3. AI 生成代码（后端实体/Mapper/Service/Controller） │
│ 4. AI 生成前端页面（Vue 文件 + 路由 + API 调用） │
│ 5. AI 更新权限 SQL + 种子数据 SQL │
│ 6. 验证：编译构建 → 权限一致性 → 种子数据 → 冒烟测试 │
│ 7. 输出本阶段的"新对话提示词"（供下一阶段或新会话使用） │
└─────────────────────────────────────────────────────────┘
- 将项目按功能复杂度拆为 4
8 个阶段，每阶段 24 天 - 每阶段必须有明确的"Done"标准（编译通过 + 联调通过）
- 不要让一个 AI 会话处理超过一个阶段的工作量（上下文窗口有限）
- 阶段之间通过"交接提示词"传递上下文
AI 编码的最大痛点之一是上下文断裂：当一次 AI 对话结束（或上下文窗口耗尽），新的对话需要重新理解项目状态。如果每次都要人工复述"当前做到了哪里、有什么坑、下一步做什么"，效率极低且容易遗漏。
本项目创新性地设计了**"标准化交接提示词"**模式，在每个阶段结束时输出一段可复制的提示词，包含：
请先阅读 docs/文档1-开发交接.md 和 docs/智慧社区管理平台系统设计文档.md，
然后从文档1第 N 节的下一步开发顺序继续开发。
当前状态：
1. 设计文档已作为开发基线，不要重新设计架构、数据库结构或接口规范。
2. 已完成的模块清单及其验证状态。
3. 已知问题及修复记录。
4. 前后端链路已测通，默认账号可登录。
接下来请进入设计文档 8.X：XXX模块。
要求：
1. 先阅读现有代码和 SQL，沿用已有分层、命名、统一响应、异常处理、
JWT、RBAC、MyBatis-Plus 逻辑删除、前端 API 封装和页面布局风格。
2. 不要重新设计架构、数据库结构或接口规范；如发现设计缺陷，先指出并说明影响。
3. 实现 XXX 模块的后端真实 CRUD、分页查询、基础校验、权限控制。
4. 实现对应前端管理页面，接真实接口，不使用假数据。
5. 完成后运行必要测试和构建，并汇报通过项、未完成项、风险和下一步建议。
| 要素 | 说明 | 示例 |
|---|---|---|
| 基线声明 | 告诉 AI 设计文档在哪里，不要重新设计 | 请先阅读 docs/文档1-开发交接.md |
| 当前状态 | 明确已完成什么、验证通过什么 | 8.1 阶段一已完成首轮验收 |
| 已知问题 | 有哪些坑已经踩过并修复 | admin 密码 hash 已修正 |
| 下一步目标 | 具体要实现什么 | 进入 8.2：社区、小区、房屋、居民 |
| 约束规则 | 必须遵守的编码规范 | 沿用已有分层、命名、统一响应格式 |
| 验收要求 | 完成后要做什么检查 | mvn test 通过 + npm run build 通过 |
本项目 docs/文档1-开发交接.md 的第 8 节记录了一段完整的交接提示词，第 3~17 节记录了 15 轮 AI 编码迭代，每轮都有独立的"本次对话更新总结"。
- 维护一份"开发交接文档"，包含每轮的提示词模板和更新总结
- 每个阶段结束时立即输出下一阶段的提示词，趁上下文还热乎
- 提示词中必须包含约束条件，否则 AI 容易"放飞自我"重新设计架构
- 提示词要包含验证命令，让新 AI 会话可以自检
AI 生成的代码必须严格遵守项目已有的分层架构、命名规范和代码风格，否则会逐步退化为一盘散沙。
controller/ → @RestController + @PreAuthorize 权限注解 + 统一响应 Result<T>
↓ 调用
service/ → @Service + 业务逻辑 + 数据权限收窄
↓ 调用
mapper/ → MyBatis-Plus BaseMapper + 自定义 SQL
↓ 操作
entity/ → @TableName + @TableLogic 逻辑删除 + BaseEntity 审计字段
强制规则：
- 所有 API 前缀：
/api/v1 - 所有响应：包装为
Result<T>（code + message + data） - 所有异常：通过
GlobalExceptionHandler统一处理，不返回裸 500 - 所有删除：MyBatis-Plus 逻辑删除（
deleted字段） - 所有权限：
@PreAuthorize("hasAuthority('xxx:xxx')") - 所有审计：
BaseEntity自动填充createdAt/updatedAt/createdBy/updatedBy
views/ → Vue SFC 页面组件，调用 API，不直接操作 store
↓ 调用
api/ → Axios 封装，统一请求/响应拦截
↓ 使用
stores/ → Pinia 状态管理（auth、dict、permission）
↓ 依赖
router/ → Vue Router + 路由守卫（权限控制）
强制规则：
- 所有 API 调用通过
api/目录统一封装 - 管理端页面独立为单个 Vue 文件（一页一文件）
- 权限按钮使用
v-permission指令或PermissionButton组件 - 手机号展示必须脱敏
- 在第一个阶段就建立分层骨架，后续所有 AI 生成的代码都往里填
- 把命名规范写入交接提示词的约束条件中
- 定期用正则扫描（例如
rg @PreAuthorize）检查权限码一致性 - 发现 AI 偏离约定时立即纠正，不要让偏差累积
每个阶段的交付必须通过四层验证，不允许"看上去对"就认为完成。
第一层：编译/构建验证
├── 后端：mvn test（单元测试） + mvn -DskipTests compile
└── 前端：npm run build（含 vue-tsc 类型检查）
第二层：权限码一致性验证
├── 检查 Controller 中所有 @PreAuthorize 权限码
├── 与 003_init_permissions.sql 中的权限码比对
└── 确保无缺失、无拼写错误
第三层：种子数据回放验证
├── 在本地 MySQL 重放所有 SQL 脚本
├── 验证所有演示账号可登录
└── 验证各角色菜单数量和权限符合预期
第四层：运行时冒烟验证
├── 验证未登录 → 401
├── 验证无权限 → 403
├── 验证管理员登录 → 全部菜单可见
├── 验证低权限角色 → 仅允许的菜单可见
└── 验证核心 CRUD 链路（列表/新增/编辑/删除）
| 检查项 | 结果 |
|---|---|
后端 mvn test |
✅ 通过 |
前端 npm run build |
✅ 通过 |
| 静态权限码检查 | 117 个，缺失 0 个 |
| 动态流转动作权限检查 | 31 个，缺失 0 个 |
| 权限 ID 重复检查 | 无重复 |
| 8 个演示角色登录验证 | 全部通过 |
| 占位代码引用扫描 | 0 个引用 |
- 把验证命令写入交接提示词，让每个新 AI 会话都执行验证
- 权限码一致性检查可以用正则脚本自动化：
rg "@PreAuthorize.*hasAuthority"vs SQL 中的权限码 - 种子数据脚本必须保持可重复执行（使用
REPLACE INTO或先删后插） - 至少用 2 个不同权限级别的角色做运行时验证
创新点不应侵入主业务代码，而应以独立微服务的形式注入，通过 HTTP API 与后端松耦合集成。
| 创新点 | 实现方式 | 部署形态 | 与主系统集成方式 |
|---|---|---|---|
| 车牌识别 | 百度 AI API | 云端 API | backend/.../ai/AiAlertService.java 调用 |
| 图片理解（问题上报） | 百度 AI API | 云端 API | backend/.../ai/AiAlertService.java 调用 |
| 身份证 OCR | PaddleOCR + FastAPI | 本地 Python 服务 tools/idcard_ocr_service/ |
POST /ocr/id-card → 后端 IdCardOcrClient |
| 人脸签到 | face_recognition + OpenCV + Flask | 本地 Python 服务 tools/face_checkin_service/ |
POST /face/verify → 后端 FaceCheckinClient |
| AI Agent（小智） | Ollama + Qwen 3:8B | 本地 Ollama 服务 deploy/ollama/ |
POST localhost:11434 → 后端 OllamaClient → Flutter 展示 |
| 网格地图 | 高德地图 SDK + Leaflet | 前端/移动端 SDK | GET /api/v1/grid-map/* → 后端聚合坐标 JSON |
本地部署场景（推荐优先考虑）：
├── 涉及隐私数据（身份证、人脸）→ 本地 OCR + 本地人脸
├── 需要离线演示 → Ollama 本地 LLM
└── 需要体现"自主实现"工作量 → 自建 Python 服务
云端 API 场景：
├── 识别能力超出本地模型能力范围 → 车牌识别、图片理解
└── 快速原型验证 → 先调 API，后续可替换为本地方案
每个创新点的开发都有独立的技术实现文档（如 docs/人脸签到-技术实现文档.md），包含：
- 功能概述与架构图
- 模型选型理由（为什么用预训练模型而不是自己训练）
- 关键代码路径
- 部署步骤
- 联调方案
- 验收标准
- 创新点与主业务物理隔离：独立目录、独立端口、独立进程
- 每个人负责 1~2 个创新点，并行开发不阻塞
- 每个创新点写一份技术实现文档，方便后续答辩和复用
- 本地部署优先于云端 API，更能体现技术深度
- 为每个创新点预留"开关配置"（
application.yml中的enabled标志），方便演示时切换
阶段一 ~ 阶段六（串行）
┌───────────────────────────────────────┐
│ 6 人分领 6 个模块，AI 辅助并行开发 │
│ M1-Web端 M2-后端 M3-移动端 │
│ M4-数据库 M5-AI工具 M6-部署文档 │
└───────────────────────────────────────┘
↓
┌───────────────────────────────────────┐
│ 1 人（模块闭环测试 + 联调） │
│ 负责端到端验证、接口联调、问题汇总 │
└───────────────────────────────────────┘
↓
┌───────────────────────────────────────┐
│ 4 人（创新点注入，并行） │
│ ① 车牌识别 API 集成 │
│ ② 图片理解 API 集成 │
│ ③ 身份证 OCR 本地部署（PaddleOCR） │
│ ④ 人脸签到本地部署（face_recognition） │
│ ⑤ AI Agent 本地部署（Ollama + Qwen） │
│ ⑥ 地图功能本地部署与强化 │
└───────────────────────────────────────┘
↓
┌───────────────────────────────────────┐
│ 1 人（界面美化 + 数据库记录丰富完善） │
│ "Civic Warmth" 设计体系 │
└───────────────────────────────────────┘
↓
验收交付
| 要点 | 说明 |
|---|---|
| 统一上下文入口 | 所有人从同一份设计文档和交接文档开始 AI 对话 |
| 接口契约先行 | 后端 Controller 的方法签名即为前后端契约，先定义再实现 |
| 独立数据库脚本 | 每个人的数据库变更写入独立的 SQL 文件（007_xxx.sql），避免冲突 |
| 每日同步 | 每天确认彼此的 API 路径、字段名、状态码没有漂移 |
| 共用种子数据 | 共用的演示数据写入 004_seed_demo_data.sql，模块专属数据写入独立种子脚本 |
- 最少 3 人、建议 6 人：少于 3 人无法体现并行优势，多于 8 人协调成本过高
- 必须有一个人做联调：AI 生成的模块间接口大概率有偏差，需要专人发现并修复
- 创新点可以提前并行准备：创新点不依赖主业务代码完整，可以在阶段三之后就开始
- 界面美化放在最后：因为前端页面随时可能被 AI 重新生成
## 模块名称：XXX
### 业务边界
- 面向用户：XXX
- 核心能力：1.XXX 2.XXX 3.XXX
### 数据库表
| 表名 | 说明 | 关联 |
|------|------|------|
| xxx | xxx | xxx |
### API 接口
| 方法 | 路径 | 说明 | 权限码 |
|------|------|------|--------|
| GET | /api/v1/xxx | 分页查询 | xxx:list |
| POST | /api/v1/xxx | 新增 | xxx:create |
### 前端页面
| 路由 | 页面组件 | 说明 |
|------|---------|------|
| /admin/xxx | XxxView.vue | XXX管理页 |
### 权限码
- xxx:list, xxx:create, xxx:edit, xxx:delete参见第 6 章，核心结构如下：
[请先阅读 docs/交接文档.md]
当前状态：[已完成模块 + 验证状态 + 已知问题]
接下来：[下一阶段目标]
要求：
1. 沿用已有分层和命名规范
2. 不要重新设计架构
3. 实现真实 CRUD + 权限控制
4. 前端接真实接口
5. 完成后运行验证并汇报
## 阶段 N 验证清单
### 编译构建
- [ ] 后端 `mvn test` 通过
- [ ] 前端 `npm run build` 通过
### 权限码一致性
- [ ] @PreAuthorize 权限码与 SQL 无缺失
- [ ] 权限 ID 无重复
### 种子数据
- [ ] 所有 SQL 脚本可重放
- [ ] 所有演示角色可登录
### 运行时冒烟
- [ ] 未登录访问 → 401
- [ ] 无权限访问 → 403
- [ ] 各角色菜单数量符合预期
- [ ] 核心 CRUD 链路正常参见 tools/idcard_ocr_service/ 和 tools/face_checkin_service/ 项目结构：
tools/xxx_service/
├── app.py # FastAPI/Flask 主程序
├── requirements.txt # Python 依赖
└── README.md # 启动说明
| 因素 | 重要性 | 本项目实践 |
|---|---|---|
| 设计文档先行 | ⭐⭐⭐⭐⭐ | 2400 行设计文档，覆盖需求和接口 |
| 分层约束严格 | ⭐⭐⭐⭐⭐ | 后端 4 层 / 前端 3 层，AI 强制遵守 |
| 交接提示词 | ⭐⭐⭐⭐⭐ | 15 轮 AI 迭代，每轮输出可复用提示词 |
| 增量验证 | ⭐⭐⭐⭐ | 每阶段四层验证，问题早发现 |
| 权限码自动化检查 | ⭐⭐⭐⭐ | 117 个权限码正则比对，0 缺失 |
| 种子数据可重放 | ⭐⭐⭐ | 18 个 SQL 脚本，支持任意环境重建 |
| 创新点独立部署 | ⭐⭐⭐ | 3 个本地 Python 服务 + 2 个 API，互不干扰 |
| 陷阱 | 表现 | 对策 |
|---|---|---|
| AI 重新设计架构 | 新会话改了 API 前缀、响应格式、表结构 | 在提示词中明确"不要重新设计架构" |
| 占位代码堆砌 | AI 只生成空壳/假数据 | 提示词中要求"接入真实接口，不使用假数据" |
| 权限码遗漏 | 新增功能没有对应权限码 | 每阶段用正则脚本检查 Controller 与 SQL 的一致性 |
| 上下文溢出 | AI 忘记前面的约定 | 用交接提示词压缩上下文，每阶段不超过一个会话 |
| 模块间接口漂移 | 前后端字段名/路径不一致 | 专人联调 + 接口冒烟测试 |
| 种子数据不可重复执行 | 重复导入报主键冲突 | 使用 REPLACE INTO 或先 DELETE 再 INSERT |
| 适用 | 不太适用 |
|---|---|
| ✅ 需求明确、有设计文档的项目 | ❌ 需求持续剧烈变更的探索性项目 |
| ✅ 4~8 人团队的全栈项目 | ❌ 单人独立项目（方法论 overkill） |
| ✅ 模块可清晰拆分的业务系统 | ❌ 高度算法密集、核心逻辑无法拆分的项目 |
| ✅ 有明确验收标准的企业级项目 | ❌ 纯研究型/原型探索项目 |
| ✅ 技术栈统一（如全 Java/Vue 体系） | ❌ 异构技术栈过多（AI 容易串味） |
以下提示词用于生成 AI 图片，放入 PPT 中介绍 AI Coding 方法论。建议使用 Midjourney / Stable Diffusion / DALL·E 等工具生成。
一张展示"AI Coding 多模块协作方法论"的信息图风格插图，扁平化设计，蓝色和白色为主色调，干净、现代、科技感。
画面中央是一个发光的六边形核心，标注"AI 编码中枢"。
六条发光的管道从核心向外连接到六个模块图标，六个模块围绕核心排列成圆形：
- 左上：Web 管理端（显示器图标）
- 右上：移动端（手机图标）
- 左中：后端服务（齿轮图标）
- 右中：数据库（圆柱体图标）
- 左下：AI 工具集（大脑/芯片图标）
- 右下：部署与文档（文件夹图标）
画面左侧有一条纵向的流水线，三个节点从上到下排列，用箭头连接：
- 顶部节点："设计基线"（文档图标）
- 中间节点："分阶段增量交付"（层叠方块图标）
- 底部节点："四层验证闭环"（对勾/盾牌图标）
画面右侧展示六人团队协作拓扑：六个简化的人物图标，每人连接到一个模块。下方标注角色分工："模块开发(6人)→联调测试(1人)→创新注入(4人)→美化完善(1人)"。
整体色调：深蓝背景，白色和亮蓝色元素，浅蓝色发光效果。图中不要出现任何文字（让文字由 PPT 后期添加），只展示可视化符号和连接关系。画面比例为 16:9，适合 PPT 宽屏插入。
An infographic-style illustration representing "AI Coding Multi-Module Collaboration Methodology", flat design, blue and white color scheme, clean, modern, tech feel.
At the center, a luminous hexagonal core labeled "AI Coding Hub".
Six glowing pipelines radiate from the core to six module icons arranged in a circle:
- Top-left: Web Admin (monitor icon)
- Top-right: Mobile App (phone icon)
- Mid-left: Backend Service (gear icon)
- Mid-right: Database (cylinder icon)
- Bottom-left: AI Toolkit (brain/chip icon)
- Bottom-right: Deployment & Docs (folder icon)
On the left side, a vertical pipeline with three nodes connected by arrows, top to bottom:
- Top: "Design Baseline" (document icon)
- Middle: "Incremental Phase Delivery" (stacked blocks icon)
- Bottom: "4-Layer Verification" (checkmark/shield icon)
On the right side, a team collaboration topology: six simplified person icons, each connected to a module. Below, role labels: "Module Dev (6)→Integration Test (1)→Innovation Injection (4)→UI Polish (1)".
Color palette: deep blue background, white and bright blue elements, light blue glow. NO text in the image (let PPT add text later), only visual symbols and connections. 16:9 aspect ratio for widescreen PPT insertion.
| 文档 | 说明 |
|---|---|
| 系统设计文档 | 项目需求、架构、数据库、接口、分阶段计划 |
| 开发交接文档 | 18 轮 AI 编码迭代记录与交接提示词 |
| 部署说明 | 环境搭建与部署步骤 |
| 验收测试用例 | 功能测试用例与结果 |
| 多角色演示账号 | 8 个角色差异说明 |
| 项目演示流程 | 现场演示操作步骤 |
| AI 预警中心技术文档 | 5 种预警类型 + 大模型分析 |
| AI 指挥中心技术文档 | 大屏数据可视化 |
| 人脸签到技术文档 | 活体检测 + embedding 比对 |
| 身份证 OCR 技术文档 | PaddleOCR 本地部署 |
| 移动端 AI 助手文档 | Ollama + Qwen 智能问答 |
| 网格员地图部署文档 | 高德地图 + 网格标记 |
| Ollama 搭建与训练指南 | 模型构建 + 训练数据 |
版本: v2.0
日期: 2026-07-06
用途: AI Coding 方法论指导 + 项目 README