240 lines
12 KiB
Markdown
240 lines
12 KiB
Markdown
# AI+OPC 培训团队协作经验分享 · 演讲稿
|
||
|
||
> **总时长**：约 38 分钟（留 2-3 分钟 Q&A 缓冲）
|
||
>
|
||
> **对应 PPT**：网页式模拟 PPT，共 10 页
|
||
|
||
---
|
||
|
||
## 第 1 页 · 标题页（约 1 分钟）
|
||
|
||
大家好，我是。。。
|
||
|
||
在上次培训中，我们小组被领导认为协作做得比较好，主要表现在三个方面：
|
||
|
||
1. **第一**，我们用 3 天时间完成了一个高完成度、细节丰满的系统；
|
||
2. **第二**，团队中每一个成员，包括计算机小白，都亲手参与了 AI 编码；
|
||
3. **第三**，我们的开发协作方式得到了领导的认可。
|
||
|
||
接下来，我会从项目管理和团队协作的角度，详细分享我们是如何做到的。
|
||
|
||
---
|
||
|
||
## 第 2 页 · 演讲者简介（约 3 分钟）
|
||
|
||
先做一个简单的自我介绍。
|
||
|
||
---
|
||
|
||
## 第 3 页 · 上次小组协作项目成果（约 3 分钟）
|
||
|
||
接下来先看一下我们上次小组协作完成的项目成果。
|
||
|
||
我想特别强调右边的三个关键数字：
|
||
|
||
| 指标 | 数据 | 说明 |
|
||
|------|------|------|
|
||
| ⏱ 开发周期 | **3 天** | 从选题到交付，功能完整、细节丰满 |
|
||
| ✅ 完成度 | **95%** | 不是半成品，而是真正可用的完整系统 |
|
||
| 👥 参与度 | **100%** | 包括零编程经验的同事都亲手参与了 AI 编码 |
|
||
|
||
这三个数字就是我们团队协作的最好证明。接下来的内容，我会详细分享我们是如何做到这样的结果的。
|
||
|
||
---
|
||
|
||
## 第 4 页 · 需求协同 — 集思广益达成共识（约 4 分钟）
|
||
|
||
我们协作的第一步是**需求协同**。
|
||
|
||
明确选题之后，我们做的第一件事不是直接开始写代码，而是采用**协同思维导图**的方式来收集和整理需求。大家看左边这张思维导图，这是我们小组成员使用在线思维导图工具实时编辑的成果。每个人都可以在导图上添加自己的想法——系统应该有哪些功能、业务流程应该是怎样的。这个过程我们叫做「集思广益」。
|
||
|
||
具体来说分三步：
|
||
|
||
**第一步，协同思维导图贡献需求。** 所有成员实时在线编辑，各自贡献对系统功能和业务流程的想法。
|
||
|
||
**第二步，集思广益覆盖功能与业务流。** 通过全员参与，确保不遗漏关键场景，全方位收集系统功能需求。
|
||
|
||
**第三步，小组会议统一调整形成共识。** 思维导图编辑完成后，我们召开小组会议，一起讨论和调整，确保需求得到全员的一致性认可。
|
||
|
||
这一步非常关键。为什么？因为如果需求不清晰、不统一，后面的开发就会频繁返工，团队信心也会受挫。而且让全员参与需求定义，大家对系统的理解更深入，执行时也更有归属感和主人翁意识。
|
||
|
||
---
|
||
|
||
## 第 5 页 · 任务分配与规范约束（约 4 分钟）
|
||
|
||
需求明确之后，就是任务分配和规范约束。
|
||
|
||
我们的做法是**四个步骤的流水线**：
|
||
|
||
```
|
||
① 协同思维导图 → ② 每人认领模块 → ③ 搭建脚手架 → ④ 统一规范
|
||
```
|
||
|
||
**第一步，协同思维导图**——刚才已经讲了，用思维导图明确系统功能和业务流程。
|
||
|
||
**第二步，每人认领模块**——每个人对照需求思维导图，认领自己负责的功能模块的开发工作。这样做的好处是，每个人都清楚自己要做什么，有明确的责任和主人翁意识，同时也保证了全员参与——包括计算机小白也能找到适合自己的、难度适中的功能模块。
|
||
|
||
**第三步，搭建脚手架**——技术负责人搭建好项目脚手架和 Git 仓库。脚手架已经内置了规范约束，所有组员在同一个框架下开发。
|
||
|
||
**第四步，统一规范**——代码风格、命名约定、目录结构全部统一，降低协作的摩擦成本。
|
||
|
||
我来特别强调一下「全员参与」这个点。我们小组有计算机小白，对编程完全没有概念。但我们通过合理的需求拆分和模块认领，让每个人都能找到适合自己上手的任务。再加上规范约束和脚手架的支持，即使是小白也能用 AI 编码完成自己的模块。
|
||
|
||
总结一下就是：**责任明确、参与充分、规范统一，最终实现零冲突协作**。每个组员有明确的主人翁意识，技术负责人用架构和规范来护航。
|
||
|
||
---
|
||
|
||
## 第 6 页 · 自动注册架构 — 零冲突协作的基石（约 5 分钟）
|
||
|
||
接下来是我们技术管理中最核心的设计——**自动注册架构**。
|
||
|
||
从软件技术架构的角度来做解读。大家看左边的架构图，我们的框架有一个核心解耦设计——**自动扫描注册**。意思是新增模块只需要创建独立文件，注册文件会自动扫描并加载，不需要修改任何已有代码。
|
||
|
||
### 后端三层自动注册
|
||
|
||
**第一层，API 路由自动注册。** 在 `api/` 目录下的每个 Python 文件，只要导出了一个 `router` 对象，就会被自动扫描并注册到主路由上。
|
||
|
||
**第二层，Model 自动注册。** 在 `models/` 目录下的每个模型文件，都会被自动导入到 SQLAlchemy 的 metadata 中，Alembic 就能检测到所有模型的变更。
|
||
|
||
**第三层，Service 自动注册。** 在 `services/` 目录下的每个 Service 类，都会被自动收集到命名空间中，其他模块可以直接 import 使用。
|
||
|
||
### 核心基础设施层
|
||
|
||
`core/` 目录提供了配置管理、数据库连接、安全认证、依赖注入等全局共享能力。关键是业务模块和基础设施之间没有直接耦合，全部通过 FastAPI 的 `Depends` 依赖注入机制来使用。
|
||
|
||
### 前端解耦设计
|
||
|
||
前端也采用了类似的设计——使用 Vite 的 `import.meta.glob` 实现路由自动扫描，每个模块的路由、页面、API 文件各自独立、互不引用。
|
||
|
||
### 模块自治四大隔离
|
||
|
||
1. **文件物理隔离**
|
||
2. **数据库字段隔离**
|
||
3. **命名空间隔离**
|
||
4. **导入路径固定**
|
||
|
||
每个模块在代码层面是完全自治的。
|
||
|
||
### 从架构师角度的总结
|
||
|
||
- **自动注册**本质上是「开闭原则」的工程化实现
|
||
- **依赖注入**实现了业务与基础设施的契约式解耦
|
||
- **模块自治**是高内聚低耦合的极致形态
|
||
|
||
### 对协作开发的意义
|
||
|
||
- 每人只操作自己的文件，从物理层面杜绝代码冲突
|
||
- 新增功能无需改旧代码，小白也能安全地添加模块
|
||
- 注册文件标记为「禁止修改」，从制度上消除了协作瓶颈
|
||
- 即使 N 个模块并行开发，合并时零冲突
|
||
|
||
这就是我们 3 天能完成系统的技术保障。架构层面的设计，让协作成本降到了最低。
|
||
|
||
---
|
||
|
||
## 第 7 页 · 开发规范与提示词工程（约 5 分钟）
|
||
|
||
有了好的架构，还需要好的规范和工具。在技术管理方面，我们做了**四件事**：
|
||
|
||
| # | 举措 | 说明 |
|
||
|---|------|------|
|
||
| 1 | **统一代码开发规范提示词** | 提供项目级提示词模板，AI 生成的代码自动遵循项目规范 |
|
||
| 2 | **高质量提示词样例** | 提供示例：包含上下文描述、技术约束、输入输出定义、边界条件 |
|
||
| 3 | **提示词审核机制** | 组员写好提示词 → 技术负责人审核 → 再返回使用 |
|
||
| 4 | **傻瓜式 Git 操作文档** | 从克隆仓库到提交代码，每一步有截图和说明 |
|
||
|
||
### 详细说明
|
||
|
||
**第一，统一代码开发规范提示词。** 我们提供了一套项目级别的开发规范提示词模板。所有组员在用 AI 编码时都要附上这个提示词，这样 AI 生成的代码就会自动遵循项目的编码风格、命名约定和目录结构，确保一致性。
|
||
|
||
**第二，高质量提示词样例。** 我们针对功能模块的开发，提供了一个高质量的提示词样例供组员模仿。一个好的提示词应该包含：
|
||
- **上下文描述**——告诉 AI 这是什么项目、什么模块
|
||
- **技术约束**——指定使用什么框架、什么规范
|
||
- **输入输出定义**——明确 API 的请求和响应格式
|
||
- **边界条件**——说明异常处理和特殊情况
|
||
|
||
有了样例，组员就知道怎么写好提示词了。
|
||
|
||
**第三，提示词审核机制。** 组员写好的提示词不是直接就用，而是先发给技术负责人审核修改，确认没问题了再发回去用。这个流程非常重要，因为好的提示词能一轮对话就生成可交付级代码，而差的提示词可能要反复修改好几轮。审核机制保证了一次性产出质量。
|
||
|
||
**第四，傻瓜式 Git 操作文档。** 我们提供了一份简明的 Git 操作指南，从克隆仓库到提交代码，每一步都有截图和说明，零基础的同事也能快速上手。
|
||
|
||
这套组合拳的效果就是：**规范提示词保证代码风格一致，高质量样例提升提示词水平，审核机制保证输出质量，Git 文档降低协作门槛**。最终实现了「一轮对话生成可交付级代码」的目标。
|
||
|
||
---
|
||
|
||
## 第 8 页 · Git 版本控制与团队协作（约 4 分钟）
|
||
|
||
接下来专门讲一下 Git。
|
||
|
||
**Git 是什么？** 简单来说，它是一个**分布式版本控制系统**。它能记录代码的每一次变更，支持多人同时并行开发，而且不会互相覆盖对方的工作。
|
||
|
||
### 基本操作流程
|
||
|
||
```
|
||
pull（拉取远程最新代码）
|
||
→ branch（创建自己的开发分支）
|
||
→ commit（在自己分支上提交代码）
|
||
→ push（推送到远程仓库）
|
||
→ merge（合并到主分支）
|
||
```
|
||
|
||
### 仓库地址
|
||
|
||
我们的项目有前端和后端两个仓库，地址都列在 PPT 上了，大家可以直接点击访问。
|
||
|
||
### 帮助文档
|
||
|
||
为了帮助零基础的组员也能使用 Git，我们提供了一份傻瓜式的操作文档。从「什么是 Git」开始讲，到安装配置、克隆仓库、创建分支、提交代码、合并分支，每一步都有截图和说明。我们的目标是让每个组员都能独立完成 Git 的基本操作。
|
||
|
||
### Git 对团队协作的价值
|
||
|
||
- **并行开发**——每个人在自己的分支上开发，互不干扰
|
||
- **版本可追溯**——每一次变更都有记录，出了问题可以回溯
|
||
- **变更可回滚**——如果某个改动出了问题，可以轻松回退到之前的版本
|
||
|
||
配合我们前面的**模块自治架构**，每个人只改自己的文件，即使大家同时往仓库推代码，也很少产生冲突。这就是架构设计和工具链的协同效应。
|
||
|
||
---
|
||
|
||
## 第 9 页 · 核心要点总结（约 4 分钟）
|
||
|
||
最后做一下总结。我们这次培训小组协作能取得好成绩，核心要点可以浓缩为**八个关键词**：
|
||
|
||
| # | 关键词 | 核心内涵 |
|
||
|---|--------|----------|
|
||
| 1 | **协同导图** | 思维导图集思广益，全员参与需求定义，确保需求清晰统一 |
|
||
| 2 | **认领分工** | 每人对照导图认领模块，责任明确，计算机小白也能上手 |
|
||
| 3 | **自动注册** | 零冲突架构设计，新增模块无需改旧代码，物理层面杜绝冲突 |
|
||
| 4 | **规范约束** | 统一框架和开发标准，所有人同一规范下协作，降低摩擦成本 |
|
||
| 5 | **提示词工程** | 审核机制保证提示词质量，一轮对话生成可交付级代码 |
|
||
| 6 | **Git 协作** | 版本可控可追溯，支持多人并行，出问题可回滚 |
|
||
| 7 | **模块自治** | 文件、字段、命名空间、导入路径四重隔离，高内聚低耦合 |
|
||
| 8 | **高效交付** | 3 天完成系统开发，95% 完成度，100% 团队参与 |
|
||
|
||
这些做法不是孤立的，而是一套完整的协作体系。从需求到分工，从架构到规范，从提示词到版本控制，环环相扣。
|
||
|
||
就像底部这个公式表达的：
|
||
|
||
> **协同导图 + 认领分工 + 自动注册 + 规范约束 + 提示词工程 + Git 协作 = 高效 AI 开发**
|
||
|
||
好的协作方式比个人能力更重要。我们用的这些方法，其实都不是什么高深的技术，但组合在一起，就产生了 1+1 远大于 2 的效果。
|
||
|
||
---
|
||
|
||
## 第 10 页 · 感谢聆听（约 1 分钟）
|
||
|
||
今天的分享就到这里。
|
||
|
||
总结一句话：**AI 时代，好的团队协作方式是高效开发的基石。** 通过协同导图明确需求、认领分工确保参与、自动注册架构零冲突、规范约束保质量、提示词审核提效率、Git 协作可追溯，我们用 3 天时间就交付了一个高质量的完整系统。
|
||
|
||
希望这些经验对大家有所启发，也欢迎大家在自己的项目中尝试这些方法。
|
||
|
||
如果大家有任何问题或者想进一步交流，欢迎随时联系我。
|
||
|
||
感谢大家的聆听！
|
||
|
||
---
|
||
|
||
> **演讲稿结束 — 总时长约 38 分钟，预留 2-3 分钟 Q&A 缓冲**
|