zhouwentao
/
vitesse-yitisheng-web
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
vitesse-yitisheng-web/IFLOW.md

8.3 KiB
Raw Blame History

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（修复记录）