📚 MBE 开发流程完整文档 (AI驱动版)

创建时间: 2026-01-28
文档版本: v2.0
适用团队: MBE 开发团队
核心理念: AI驱动开发 + CI/CD自动化

🎯 文档导航

🚀 快速开始

文档	阅读时间	适合人群	优先级
🤖 AI驱动开发指南	15分钟	所有人	⭐⭐⭐
📋 快速参考	5分钟	所有人	⭐⭐⭐
📖 新手指引	15分钟	新成员	⭐⭐⭐
🔄 流程可视化	10分钟	所有人	⭐⭐

📖 完整文档

文档	内容	适合人群
部署指南	🚀 三环境隔离部署详解	所有人 ⭐
AI驱动开发指南	🤖 Cursor AI + CI/CD自动化	所有人 ⭐
团队协作指南	完整的团队开发协作流程	所有人
开发工作流	详细的开发部署流程	开发者
环境分析	Docker环境配置详情	运维

📁 项目文档

文档	内容
System Prompt优化方案	优化设计和实施
验证报告	测试验证结果
更新报告	更新操作记录

🆕 新手快速上手

第1天: 环境搭建 (2小时)

# 1. 克隆代码
git clone https://github.com/your-org/mises-behavior-engine.git
cd mises-behavior-engine

# 2. 配置环境
cp env.example.txt .env
# 编辑 .env，填入 LLM API 密钥等必要配置

# 3. 启动本地开发服务（代码热重载）
.\start-local.bat
# 或: docker-compose -f docker-compose.local.yml up -d

# 4. 验证环境
curl http://localhost:8002/
docker logs mbe-api-local

# 5. 运行测试
python -m pytest tests/
python quick_test_lawyer.py

✅ 检查点:

服务可以访问: http://localhost:8002
测试可以运行
日志正常输出

三环境说明

环境	启动命令	访问地址	用途
本地开发	`.\start-local.bat`	http://localhost:8002	日常编码（热重载）
开发版	`.\start-dev.bat`	https://dev.hi-maker.com	功能测试
生产版	`.\start-prod.bat`	https://mbe.hi-maker.com	正式服务

详细部署文档: DEPLOYMENT_GUIDE.md

第2-3天: 熟悉代码 (4小时)

阅读文档:

📖 QUICK_REFERENCE.md - 了解常用命令
📖 TEAM_COLLABORATION_GUIDE.md - 了解团队协作
📖 项目README - 了解系统架构

代码导读 (Mentor陪同):

/src
├── main.py              # FastAPI 应用入口
├── mcp/
│   └── server.py        # MCP 服务器，处理用户请求
├── knowledge/
│   ├── dynamic_expert.py  # 动态专家管理
│   └── qa_critique.py     # QA质量检查
├── llm/
│   └── base.py          # LLM 接口
└── storage/
    └── database.py      # 数据库操作

关键流程:
1. 用户提问 → mcp/server.py
2. 专家匹配 → knowledge/dynamic_expert.py
3. 知识库检索 → _search_chunks()
4. LLM生成回答 → llm/base.py
5. 质量检查 → qa_critique.py

第4-5天: 小任务实践 (8小时)

任务建议:

修复一个简单Bug
添加一个测试用例
优化一处代码注释
完成一次代码审查

实践流程:

# 1. 创建分支
git checkout -b feature/my-first-task

# 2. 开发
# 编辑代码...

# 3. 测试
python -m pytest tests/test_your_module.py

# 4. 提交
git add .
git commit -m "feat: 我的第一个提交"
git push origin feature/my-first-task

# 5. 创建 PR
# 在 GitHub/GitLab 创建 Pull Request

# 6. 等待审查和反馈

🔄 标准工作流程

日常开发循环

┌─────────────────────────────────────┐
│  1. 早上: 同步代码                   │
│     git pull origin develop         │
└────────────┬────────────────────────┘
             ↓
┌─────────────────────────────────────┐
│  2. 站会: 同步进度                   │
│     10:00 每日站会 (15分钟)         │
└────────────┬────────────────────────┘
             ↓
┌─────────────────────────────────────┐
│  3. 开发: 编写代码                   │
│     - 实现功能                       │
│     - 编写测试                       │
│     - 本地验证                       │
└────────────┬────────────────────────┘
             ↓
┌─────────────────────────────────────┐
│  4. 提交: 推送代码                   │
│     git commit && git push          │
└────────────┬────────────────────────┘
             ↓
┌─────────────────────────────────────┐
│  5. 审查: 请求review                │
│     创建 PR，等待审查                │
└────────────┬────────────────────────┘
             ↓
┌─────────────────────────────────────┐
│  6. 修改: 根据反馈                   │
│     修改代码，再次提交               │
└────────────┬────────────────────────┘
             ↓
┌─────────────────────────────────────┐
│  7. 合并: merge到develop            │
│     自动部署到开发环境               │
└────────────┬────────────────────────┘
             ↓
┌─────────────────────────────────────┐
│  8. 验证: 开发环境测试               │
│     运行集成测试                     │
└─────────────────────────────────────┘

📊 质量管理

代码质量门禁

提交前 (Pre-commit)
    ├─→ 代码格式检查 (black)
    ├─→ 代码规范检查 (flake8)
    ├─→ 类型检查 (mypy)
    └─→ 单元测试

PR创建后 (CI)
    ├─→ 所有单元测试
    ├─→ 测试覆盖率检查 (> 70%)
    ├─→ 代码复杂度检查
    ├─→ 安全漏洞扫描
    └─→ Docker镜像构建

代码审查 (Human)
    ├─→ 功能正确性
    ├─→ 代码可读性
    ├─→ 性能考虑
    └─→ 文档完善

合并前 (Final Check)
    ├─→ 至少1个Approve
    ├─→ CI全部通过
    ├─→ 无未解决的评论
    └─→ 目标分支已更新

必须全部通过才能合并 ✅

🎯 实用建议

对于新成员

✅ 做:
- 多问问题（没有愚蠢的问题）
- 主动阅读文档和代码
- 积极参与代码审查
- 分享你的想法和建议
- 记录学习笔记

❌ 避免:
- 不懂装懂
- 独自困扰太久（超过2小时就问）
- 跳过测试
- 不写文档
- 害怕犯错

对于开发者

✅ 做:
- 小步提交，频繁集成
- 先写测试，后写代码
- 及时更新文档
- 主动代码审查
- 分享知识和经验

❌ 避免:
- 大功能一次提交
- 跳过代码审查
- 直接推送到main
- 不写测试
- 不看审查意见

对于Tech Lead

✅ 做:
- 技术方向把控
- 代码质量保证
- 团队能力培养
- 风险识别和控制
- 流程持续优化

❌ 避免:
- 微观管理
- 忽视技术债务
- 不给反馈
- 闭门造车
- 过度优化

📈 持续改进

定期回顾

每周 (Sprint内):
  - 代码质量指标
  - 开发效率
  - 问题记录

每2周 (Sprint结束):
  - Sprint Retrospective
  - 流程改进
  - 工具优化

每月:
  - 技术债务盘点
  - 架构review
  - 技能提升计划

每季度:
  - 团队能力评估
  - 技术栈更新
  - 工具链优化

改进案例

问题: 部署耗时太长 (1小时)
分析: 镜像构建慢，测试时间长
改进: 
  - Docker层缓存优化
  - 并行测试执行
  - 分离数据库迁移
结果: 部署时间降到15分钟

问题: Bug修复周期长 (1周)
分析: 测试覆盖不足，定位困难
改进:
  - 增加单元测试
  - 完善日志
  - 添加监控告警
结果: Bug修复周期降到1天

🎊 成功要素

技术层面

✅ 自动化程度高
✅ 测试覆盖充分
✅ 文档完善及时
✅ 监控告警完善

流程层面

✅ 流程清晰简单
✅ 权责明确
✅ 快速反馈
✅ 持续改进

团队层面

✅ 沟通透明
✅ 互相信任
✅ 共同成长
✅ 目标一致

📞 获取帮助

遇到问题时:

1. 查文档
   └─→ QUICK_REFERENCE.md
   └─→ 相关技术文档

2. 搜索历史
   └─→ GitHub Issues
   └─→ Slack 历史消息

3. 问团队
   └─→ Slack #development
   └─→ 找 Mentor

4. 调试
   └─→ 查看日志
   └─→ 本地复现

5. 记录
   └─→ 更新文档
   └─→ 分享经验

🎯 核心价值观

1. 质量第一
   代码质量 > 开发速度

2. 用户至上
   用户体验 > 技术炫技

3. 团队协作
   团队成功 > 个人英雄

4. 持续学习
   保持好奇 > 固守经验

5. 简单有效
   实用主义 > 完美主义

📚 完整文档列表

d:\Mises\mises-behavior-engine\

核心流程文档:
├── README_DEVFLOW.md                      # 📋 总索引 (本文件)
├── QUICK_REFERENCE.md                     # ⭐ 快速参考卡
├── TEAM_COLLABORATION_GUIDE.md            # 👥 团队协作指南
├── DEVELOPMENT_WORKFLOW.md                # 💻 开发工作流
├── WORKFLOW_VISUALIZATION.md              # 🔄 流程可视化

环境和配置:
├── DOCKER_ENVIRONMENT_ANALYSIS.md         # 🏗️ 环境架构分析
├── DEV_TUNNEL_CONFIG_ISSUE.md             # ⚠️ Tunnel配置问题

项目文档:
├── knowledge_bases/enhancements/
│   ├── FINAL_SOLUTION.md                  # System Prompt方案
│   ├── IMPLEMENTATION_PLAN.md             # 实施计划
│   └── system_prompt_text.txt             # System Prompt文本
├── SYSTEM_PROMPT_VERIFICATION_REPORT.md   # 验证报告
├── SYSTEM_PROMPT_UPDATE_REPORT.md         # 更新报告
└── CASE_LAW_TEST_ANALYSIS.md              # 案例测试分析

🎓 学习计划

新成员 Week 1

Day 1:
  ✅ 阅读 QUICK_REFERENCE.md
  ✅ 搭建本地环境
  ✅ 运行第一个测试

Day 2:
  ✅ 阅读 TEAM_COLLABORATION_GUIDE.md
  ✅ 理解项目架构
  ✅ 熟悉代码结构

Day 3:
  ✅ 阅读核心代码
  ✅ 运行调试
  ✅ 理解关键流程

Day 4:
  ✅ 修复第一个Bug
  ✅ 完成代码审查
  ✅ 提交第一个PR

Day 5:
  ✅ 参与技术分享
  ✅ Sprint Review
  ✅ 总结本周学习

进阶开发者

Month 1:
  ✅ 独立完成中等复杂功能
  ✅ 参与技术方案讨论
  ✅ 进行代码审查

Month 2-3:
  ✅ 负责模块开发
  ✅ 技术方案设计
  ✅ 指导新成员

Month 4-6:
  ✅ 架构设计参与
  ✅ 性能优化
  ✅ 技术分享

🎯 关键流程速查

功能开发

创建分支 → 本地开发 → 测试 → 提交 
→ PR → 审查 → 合并 → 部署开发环境 
→ 测试 → 发布生产

Bug修复

定位问题 → 创建hotfix分支 → 修复 
→ 测试 → 快速审查 → 部署 → 验证

配置更新

修改配置文件 → 本地验证 → 备份 
→ 更新生产 → 重启服务 → 验证

✅ 检查清单

每次提交前

代码格式化 (black src/)
测试通过 (pytest tests/)
无明显Bug
Commit信息规范

每次发布前

所有测试通过
代码审查完成
文档已更新
生产备份完成
回滚方案准备

每个Sprint结束

所有任务完成或转移
技术债务记录
Sprint演示准备
Retrospective总结

🎊 总结

📖 文档使用建议

新成员入职:
  Day 1: QUICK_REFERENCE.md → 环境搭建
  Day 2-3: TEAM_COLLABORATION_GUIDE.md → 理解流程
  Day 4-5: 实践开发 → 参考文档

日常开发:
  快速查询: QUICK_REFERENCE.md
  流程疑问: WORKFLOW_VISUALIZATION.md
  团队协作: TEAM_COLLABORATION_GUIDE.md

项目管理:
  流程规范: TEAM_COLLABORATION_GUIDE.md
  环境管理: DOCKER_ENVIRONMENT_ANALYSIS.md
  案例参考: 各项目文档

🎯 成功的标志

个人层面:
  ✅ 能够独立完成功能开发
  ✅ 能够进行有效的代码审查
  ✅ 能够快速定位和解决问题
  ✅ 能够分享知识和经验

团队层面:
  ✅ Sprint完成率 > 85%
  ✅ 代码质量稳定提升
  ✅ 协作流畅高效
  ✅ 持续学习和改进

项目层面:
  ✅ 交付质量高
  ✅ 生产故障少
  ✅ 用户满意度高
  ✅ 技术债务可控

📞 联系方式

技术问题: Slack #development
流程问题: Tech Lead
紧急事件: Slack #emergency
文档建议: 提PR更新

文档维护: 流程变化时及时更新
反馈: 欢迎提出改进建议
版本: v2.0 (三环境隔离架构 - 2026-01-28)

🎉 欢迎加入 MBE 团队！