152 lines
4.4 KiB
Markdown
152 lines
4.4 KiB
Markdown
# 工作协议
|
||
|
||
## 1. 每日AI协作上限
|
||
|
||
为确保工作质量和效率，设定以下AI协作上限：
|
||
|
||
- **每日提示词数量上限**：50个
|
||
- **每日会话时长上限**：4小时
|
||
- **每日生成代码量上限**：2000行
|
||
|
||
## 2. 专注块规则
|
||
|
||
### 2.1 专注块时长
|
||
- 每个专注块为25-45分钟
|
||
- 专注块之间休息5-10分钟
|
||
- 每4个专注块后休息15-30分钟
|
||
|
||
### 2.2 专注块内容
|
||
- **开发专注块**：代码编写、调试、测试
|
||
- **文档专注块**：文档编写、整理、更新
|
||
- **设计专注块**：架构设计、方案评审、技术选型
|
||
- **AI协作专注块**：提示词设计、会话执行、结果分析
|
||
|
||
### 2.3 专注块要求
|
||
- 专注块期间关闭所有通讯工具通知
|
||
- 专注块期间不进行无关的网页浏览
|
||
- 专注块期间保持环境安静，避免干扰
|
||
- 专注块开始前明确目标，结束后进行简要总结
|
||
|
||
## 3. 协作时长记录表
|
||
|
||
### 3.1 每日协作记录
|
||
|
||
| 日期 | 开始时间 | 结束时间 | 持续时长 | 协作内容 | 成果描述 |
|
||
|------|----------|----------|----------|----------|----------|
|
||
| YYYY-MM-DD | HH:MM | HH:MM | HH:MM | | |
|
||
| YYYY-MM-DD | HH:MM | HH:MM | HH:MM | | |
|
||
| YYYY-MM-DD | HH:MM | HH:MM | HH:MM | | |
|
||
|
||
### 3.2 每周协作统计
|
||
|
||
| 周数 | 总协作时长 | 开发时长 | 文档时长 | 设计时长 | AI协作时长 | 主要成果 |
|
||
|------|----------|----------|----------|----------|----------|----------|
|
||
| 第X周 | HH:MM | HH:MM | HH:MM | HH:MM | HH:MM | |
|
||
| 第X周 | HH:MM | HH:MM | HH:MM | HH:MM | HH:MM | |
|
||
| 第X周 | HH:MM | HH:MM | HH:MM | HH:MM | HH:MM | |
|
||
|
||
## 4. 代码提交规范
|
||
|
||
### 4.1 提交信息格式
|
||
```
|
||
<type>: <description>
|
||
|
||
<body>
|
||
|
||
<footer>
|
||
```
|
||
|
||
### 4.2 提交类型
|
||
- **feat**：新功能
|
||
- **fix**：bug修复
|
||
- **docs**：文档更新
|
||
- **style**：代码风格调整
|
||
- **refactor**：代码重构
|
||
- **test**：测试相关
|
||
- **chore**：构建、依赖等配置变更
|
||
|
||
### 4.3 提交频率
|
||
- 每完成一个小功能或修复一个bug后提交
|
||
- 专注块结束时进行提交
|
||
- 避免大段代码一次性提交
|
||
|
||
## 5. 代码审查规范
|
||
|
||
### 5.1 审查流程
|
||
1. 提交PR后，至少等待2人审查
|
||
2. 审查者需在24小时内完成审查
|
||
3. 审查通过后由作者合并
|
||
4. 审查不通过需根据反馈修改后重新提交
|
||
|
||
### 5.2 审查重点
|
||
- 代码质量和可读性
|
||
- 功能正确性
|
||
- 性能和安全性
|
||
- 代码风格一致性
|
||
- 文档完整性
|
||
|
||
## 6. 会议规范
|
||
|
||
### 6.1 会议类型
|
||
- **站会**：每日15分钟，同步进度和遇到的问题
|
||
- **周会**：每周1小时，总结周进展和规划下周工作
|
||
- **评审会**：按需召开，评审设计方案和重要代码
|
||
- **复盘会**：每迭代结束后召开，总结经验教训
|
||
|
||
### 6.2 会议要求
|
||
- 会议前准备议程和材料
|
||
- 会议中保持专注，避免无关讨论
|
||
- 会议后及时整理会议记录
|
||
- 严格控制会议时间，避免超时
|
||
|
||
## 7. 文档规范
|
||
|
||
### 7.1 文档更新要求
|
||
- 代码变更时同步更新相关文档
|
||
- 功能设计变更时更新设计文档
|
||
- 架构决策变更时更新ADR
|
||
- 文档更新后更新docs/index.md索引
|
||
|
||
### 7.2 文档质量要求
|
||
- 文档内容准确、完整、清晰
|
||
- 文档格式一致，遵循Markdown规范
|
||
- 文档中包含必要的示例和说明
|
||
- 文档中使用统一的术语和命名
|
||
|
||
## 8. 问题解决规范
|
||
|
||
### 8.1 问题上报流程
|
||
1. 遇到问题首先尝试自主解决
|
||
2. 30分钟内无法解决的问题向团队成员求助
|
||
3. 1小时内无法解决的问题升级到技术负责人
|
||
4. 问题解决后记录解决方案到知识库
|
||
|
||
### 8.2 问题分类
|
||
- **阻塞性问题**：影响开发进度的关键问题
|
||
- **功能性问题**：功能实现不符合需求
|
||
- **性能性问题**：系统性能不满足要求
|
||
- **安全性问题**：存在安全隐患
|
||
- **文档性问题**：文档不完善或不准确
|
||
|
||
## 9. 工具使用规范
|
||
|
||
### 9.1 推荐工具
|
||
- **代码编辑器**：Visual Studio Code、IntelliJ IDEA
|
||
- **版本控制**：Git
|
||
- **项目管理**：JIRA、Trello
|
||
- **文档工具**：Markdown、Confluence
|
||
- **沟通工具**：Slack、Microsoft Teams
|
||
|
||
### 9.2 工具配置
|
||
- 统一代码编辑器配置，使用项目提供的配置文件
|
||
- 统一Git配置，使用项目提供的Git钩子
|
||
- 统一代码风格检查工具配置
|
||
- 统一文档模板和格式
|
||
|
||
## 10. 协议更新与维护
|
||
|
||
- 本协议每季度审查一次，根据实际情况进行调整
|
||
- 团队成员可随时提出修改建议
|
||
- 协议更新需经团队会议讨论通过
|
||
- 协议更新后及时通知所有团队成员
|