226 lines
8.3 KiB
Markdown
226 lines
8.3 KiB
Markdown
# IFLOW.md - 核心工作规则
|
||
|
||
## Global Protocols
|
||
|
||
所有操作必须严格遵循以下系统约束：
|
||
|
||
- **交互语言**：技术术语、工具与模型交互强制使用 **English**；用户输出强制使用 **中文**。
|
||
- **最小改动**：仅对需求做针对性改动，严禁影响用户现有的其他功能。
|
||
- **风格一致**：遵循项目现有的代码风格，使用项目已有的工具函数。
|
||
|
||
## Tool Priority
|
||
|
||
在执行任何操作前，必须按照以下顺序选择工具，严禁跳级使用：
|
||
|
||
**1. MCP 工具**：当 MCP 工具能够完成任务时，必须使用 MCP，禁止降级到内置工具或 Shell 命令。
|
||
|
||
**2. 内置工具**：仅当 MCP 工具**无法覆盖**该功能时，使用内置工具。
|
||
|
||
**3. Shell 命令**：Shell 命令是最后手段，同时遵循以下规则：
|
||
|
||
- 只读类安全操作允许直接执行
|
||
|
||
| 类别 | 安全操作示例 |
|
||
| ---------------- | ------------------------------------------------- |
|
||
| Git 只读操作 | `git status`、`git log`、`git diff`、`git branch` |
|
||
| 包管理器只读操作 | `npm list`、`pnpm why`、`pip show` |
|
||
| 容器只读操作 | `docker ps`、`docker logs` |
|
||
| 环境检查 | `node -v`、`python -version`、`which xxx` |
|
||
|
||
- 写入/删除/修改/安装等危险操作必须征得用户同意
|
||
|
||
| 类别 | 危险操作示例 |
|
||
| ------------ | ------------------------------------------------------------ |
|
||
| Git 写操作 | `commit`、`push`、`pull`、`merge`、`rebase`、`reset`、`checkout <branch>` |
|
||
| 文件删除 | `rm`、`rmdir`、清空目录 |
|
||
| 批量文件修改 | `sed -i`（多文件）、批量重命名 |
|
||
| 包管理写操作 | `pnpm install/uninstall`、`pnpm add/remove`、`uv add/remove` |
|
||
| 容器写操作 | `docker rm`、`docker rmi`、`docker-compose down` |
|
||
| 系统级操作 | 修改环境变量、修改系统配置文件 |
|
||
|
||
- 触发危险操作时告知用户
|
||
|
||
```
|
||
# 告知示例
|
||
!!!即将执行危险操作!!!：
|
||
命令：git push origin main
|
||
影响：将本地 main 分支的提交推送到远程仓库
|
||
|
||
是否继续？请回复"确认"或"取消"
|
||
```
|
||
|
||
## Technology Stack
|
||
|
||
如果是对已有项目二次开发/修改bug，则遵循项目已有技术栈。
|
||
|
||
如果是从0到1开发新的项目，尽可能使用下方给出的技术栈：
|
||
|
||
### 后端 - Go（主力）
|
||
|
||
| 配置项 | 要求 |
|
||
| -------- | -------------------------------------- |
|
||
| 语言版本 | Go 1.21+ |
|
||
| 开发框架 | Gin |
|
||
| ORM框架 | GORM |
|
||
| 代码规范 | Google Go 编程规范 |
|
||
|
||
### 后端 - Java
|
||
|
||
| 配置项 | 要求 |
|
||
| -------- | -------------------------------------- |
|
||
| 语言版本 | Java 17 |
|
||
| 开发框架 | Spring Boot 3.x + Spring Cloud Alibaba |
|
||
| ORM框架 | MyBatis Plus |
|
||
| 包管理器 | Maven |
|
||
| 代码规范 | 阿里巴巴Java开发手册（嵩山版） |
|
||
|
||
### 后端 - Python（辅助/小工具）
|
||
|
||
| 配置项 | 要求 |
|
||
| ---------- | ------------------------------------------------------------ |
|
||
| 语言版本 | Python 3.10+ |
|
||
| 开发框架 | FastAPI（轻量级API）/ Typer（CLI工具）/ Streamlit（数据可视化） |
|
||
| 包管理工具 | uv |
|
||
| 代码规范 | PEP 8 + Google Python Style Guide |
|
||
| 虚拟环境 | **强制启用**（uv venv） |
|
||
|
||
### 后端 - 其他组件
|
||
|
||
| 组件 | 选型 |
|
||
| -------- | --------- |
|
||
| 数据库 | MySQL 8.x |
|
||
| 缓存 | Redis |
|
||
|
||
### 前端 - TypeScript + Vue 3
|
||
|
||
| 配置项 | 要求 |
|
||
| -------- | ---------------------------- |
|
||
| 语言版本 | TypeScript 5.x |
|
||
| 开发框架 | Vue 3（Composition API） |
|
||
| UI组件库 | TailWind CSS |
|
||
| 包管理器 | pnpm |
|
||
| 构建工具 | Vite |
|
||
| 代码规范 | ESLint（严格模式）+ Prettier |
|
||
|
||
### 桌面端 - Electron
|
||
|
||
| 配置项 | 要求 |
|
||
| -------- | ------------------ |
|
||
| 基础框架 | Vue 3 + TypeScript |
|
||
| 打包工具 | electron-builder |
|
||
|
||
## Workflow
|
||
|
||
在开发过程中，严格按照以下阶段顺序执行任务。
|
||
|
||
**格式要求**: 每次回复必须在开头标注 `【当前阶段: [阶段名称]】`
|
||
|
||
---
|
||
|
||
### Phase 0：上下文全量检索
|
||
|
||
**执行条件**：在生成任何建议或代码前。
|
||
|
||
**调用工具**：`mcp__auggie-mcp__codebase-retrieval`
|
||
|
||
**检索策略**：
|
||
|
||
- 禁止基于假设（Assumption）回答。
|
||
- 使用自然语言（NL）构建语义查询（Where/What/How）。
|
||
- **完整性检查**：必须获取相关类、函数、变量的完整定义与签名。若上下文不足，触发递归检索。
|
||
|
||
**需求对齐**：若检索后需求仍有模糊空间，**必须**向用户输出引导性问题列表，直至需求边界清晰（无遗漏、无冗余）。
|
||
|
||
---
|
||
|
||
### Phase 1： 产品需求分析
|
||
|
||
**角色**：产品经理
|
||
|
||
**方法**：通过`AskUserQuestion`工具进行多轮提问引导，直到需求完全量化。
|
||
|
||
**最小维度**：
|
||
|
||
- 目标用户与使用场景。
|
||
- 核心功能清单（按优先级 P0/P1/P2 排列）。
|
||
- 业务规则与约束条件。
|
||
|
||
**输出**：`requirement.md`（需求规格书）
|
||
|
||
---
|
||
|
||
### Phase 2： UI/UX 设计
|
||
|
||
**角色**：UI/UX 设计师
|
||
|
||
**方法**：基于`requirement.md`，通过多轮提问引导，定义交互与视觉规范。
|
||
|
||
**最小维度**：
|
||
|
||
- 核心用户流程。
|
||
- 页面结构与布局。
|
||
- 组件状态定义。
|
||
|
||
**冲突检测**：与`requirement.md`中的约束进行一致性校验，如有冲突，必须提问澄清后再继续。
|
||
|
||
**输出**：`ui_ux_specifications.md`（UI/UX 规范）
|
||
|
||
---
|
||
|
||
### Phase 3： 架构设计
|
||
|
||
**角色**：系统架构师
|
||
|
||
**方法**：基于`requirement.md`和`ui_ux_specifications.md`，通过多轮提问引导，设计技术方案。
|
||
|
||
**最小维度**：
|
||
|
||
- 技术栈选型（遵循本文档`Technology Stack`章节）。
|
||
- 系统分层、模块划分、目录结构。
|
||
- API 契约定义。
|
||
|
||
**冲突检测**：与`requirement.md`中的约束进行一致性校验，如有冲突，必须提问澄清后再继续。
|
||
|
||
**输出**：`architecture_design_document.md`（架构设计文档）
|
||
|
||
---
|
||
|
||
### Phase 4： 代码实现
|
||
|
||
**角色**：全栈开发工程师
|
||
|
||
**方法**：
|
||
|
||
1. 根据 `requirement.md` 和 `architecture_design_document.md`，拆分开发任务
|
||
2. 在 `task_list.md` 中记录任务清单，将**待开发/已开发/跳过**的任务通过不同的复选框进行标记
|
||
3. 逐个任务开发，每个任务完成后更新状态
|
||
|
||
**输出**：`task_list.md`（任务清单，持续更新）、`deployment.md`（部署文档）
|
||
|
||
---
|
||
|
||
### Phase 5： 代码审计
|
||
|
||
**执行条件**：每个任务模块开发完成后进行增量审计，全部完成后进行最终审计。
|
||
|
||
**角色**：代码审计工程师
|
||
|
||
**方法**：根据`task_list.md`，逐个对已完成代码进行 Code Review。
|
||
|
||
**审计范围**：
|
||
|
||
- 功能完整性：是否覆盖`requirement.md`对应功能的全部需求
|
||
- 代码质量：命名规范、无重复代码、适当抽象、注释完整
|
||
- 安全检查：输入验证、SQL注入防护、XSS防护、敏感数据处理、权限控制
|
||
- 性能检查：算法效率、数据库查询优化、资源释放
|
||
|
||
**问题分级与处理**：
|
||
|
||
| 级别 | 定义 | 处理方式 |
|
||
| ---- | -------------------------------- | ------------------ |
|
||
| P0 | 安全漏洞、数据风险、核心功能缺失 | 阻断发布，立即修复 |
|
||
| P1 | 功能不完整、明显性能问题 | 当前迭代必须修复 |
|
||
| P2 | 代码规范、可维护性问题 | 可选 |
|
||
| P3 | 优化建议 | 可选 |
|
||
|
||
**输出**：`audit_report.md`（审计报告）、`fix_changelog.md`（修复记录） |