REQUIREMENTS RULES
文件一：01_REQUIREMENTS_RULES.md
# 文件一：01_REQUIREMENTS_RULES.md
# 项目需求与产品规则
版本：1.0
状态：长期有效
作用：控制 AI “做什么”，防止需求漂移、擅自加功能、漏功能、越改越偏。
## 1. 核心原则
项目开发必须遵循：
- 需求 → 设计 → 技术实现 → 测试 → 上线
- 禁止直接从一句自然语言需求跳到大规模写代码。
- AI必须先确认现有项目状态和已有功能，再决定如何实现新需求。
# 2. 用户需求优先级
需求分为：
## P0：不可违背
包括：
- 用户明确要求
- 安全规则
- 数据完整性
- 权限规则
- 核心业务规则
- 已确认设计规范
不得擅自改变。
## P1：正式需求
当前版本确定要实现的功能。
- 必须完整实现并验证。
## P2：优化需求
可以改善：
- 使用体验
- 性能
- UI
- 代码结构
不得因为实现P2而破坏P0/P1。
## P3：未来需求
记录，但当前不得擅自实现。
- 防止：
- “AI觉得挺好，所以顺手加了。”
# 3. AI禁止擅自改变产品需求
未经明确授权，不得：
- 新增业务功能
- 删除功能
- 合并功能
- 改变用户流程
- 改变登录方式
- 改变权限规则
- 修改核心交互
- 更换技术路线
- 更换页面风格
- 更换数据库
- 增加第三方依赖
- 引入收费API
- 改变数据结构
AI可以提出建议，但：
- 建议 ≠ 授权实施。
# 4. 每次开发前必须确认四件事
开始任何功能前，先确定：
### ① 为什么做
功能目的是什么。
### ② 谁来用
用户角色是什么。
### ③ 用户怎么用
完整用户路径是什么。
### ④ 成功标准是什么
什么状态才算实现完成。
# 5. 每项功能必须建立功能定义
格式：
## FEATURE-ID
名称：
- 目的：
- 使用用户：
- 入口：
- 输入：
- 处理：
- 输出：
- 成功状态：
- 失败状态：
- 权限：
- 依赖：
- 异常情况：
- 验收标准：
例如：
## FEATURE-LOGIN-001
名称：
- 用户登录
- 目的：
- 允许注册用户进入个人账户。
- 入口：
- /login
- 输入：
- 账号、密码。
- 成功：
- 进入用户中心。
- 失败：
- 明确提示账号或密码错误。
- 权限：
- 游客可访问。
- 验收：
- 正确账号能登录。
- 错误密码不能登录。
- 退出后受保护页面不可访问。
# 6. UI展示不代表功能完成
出现按钮：
- 不代表功能存在。
- 出现页面：
- 不代表功能完成。
- 出现假数据：
- 不代表后端完成。
- 出现接口：
- 不代表接口可用。
- 因此必须区分：
- 【UI完成】
- 【前端逻辑完成】
- 【后端完成】
- 【接口联通】
- 【真实测试通过】
# 7. 禁止假功能
正式项目不得存在：
- 点击按钮无反应。
- 假登录。
- 假管理员。
- 假上传。
- 假保存。
- 假搜索。
- 假统计。
- 假接口。
- Mock数据冒充真实数据。
如果使用Mock：
- 必须明确标记：
`
MOCK ONLY
`
禁止生产环境继续使用。
# 8. 不得隐藏失败
如果某功能无法完成：
- 明确标记：
- 【未完成】
- 而不是用静态页面模拟完成。
# 9. 所有功能必须考虑状态
至少包括：
- 默认状态。
- 加载状态。
- 成功状态。
- 失败状态。
- 空数据状态。
- 无权限状态。
- 断网状态。
- 超时状态。
# 10. 所有用户输入必须考虑边界
包括：
- 空。
- 过短。
- 过长。
- 特殊字符。
- 中文。
- 英文。
- Emoji。
- 重复提交。
- 非法格式。
- 异常输入。
# 11. 需求改变必须记录
任何正式需求改变，应记录：
- 原需求：
- 新需求：
- 改变原因：
- 影响范围：
- 涉及文件：
- 是否影响数据：
- 是否需要迁移：
- 是否需要重新测试：
# 12. 禁止需求漂移
如果执行过程中发现：
- 实现方式越来越偏离原需求，
- 必须停止扩散。
- 先回到需求定义。
# 13. 不确定时怎么办
禁止 AI 自己脑补重要业务规则。
- 可以：
- 选择最保守、不破坏现有功能的实现。
- 并标记：
- 【需要产品确认】
# 14. 完成功能的定义
一个功能只有同时满足：
- 需求实现
前端完成
后端完成
接口正常
异常处理
权限检查
测试通过
- 才叫：
- 【完成】
# 15. 每次需求任务完成后输出
修改功能：
- 涉及文件：
- 新增内容：
- 删除内容：
- 未完成事项：
- 潜在风险：
- 测试结果：
- 是否影响其他模块：
六大规则共同执行协议
以下内容同时适用于全部六份文件。
A. AI每次任务开始前
先阅读：
- 与当前任务有关的规则文件。
- 如果任务涉及多个领域：
- 全部读取。 例如：
- 修改登录：
- 必须读取：
- 01_REQUIREMENTS_RULES.md
- 03_ENGINEERING_RULES.md
- 04_SECURITY_RULES.md
- 05_TESTING_RULES.md 修改视觉：
- 读取：
- 01_REQUIREMENTS_RULES.md
- 02_DESIGN_SYSTEM_RULES.md
- 05_TESTING_RULES.md 准备上线：
- 六份全部读取。
B. 规则冲突优先级
如发生冲突：
- 安全与数据完整性 明确用户需求 产品规则 架构规则 设计规则 优化建议
C. AI不能自行修改规则
除非用户明确要求：
- “修改规则文件”。
- 否则：
- 这些文件只读。
D. 现有项目与规则冲突怎么办
不得为了符合规则立即大规模重写。
- 先输出：
- 规则：
- 当前实现：
- 差异：
- 严重程度：
- 建议迁移方式： 再决定是否修复。
E. 每次修改之前
先回答自己：
- 我正在解决什么问题？
- 哪些文件必须修改？
- 哪些文件不应该碰？
- 是否涉及数据？
- 是否涉及权限？
- 是否影响API？
- 是否影响UI？
- 如何验证？
F. 每次修改之后
必须检查：
- 代码是否能运行。
- 是否引入新错误。
- 相关功能是否正常。
- 是否影响其他模块。
- 是否需要更新文档。
G. 禁止假完成
以下情况不得说：
- “全部完成”。
- 仍有未测试。
- 仍有报错。
- Build失败。
- 接口未验证。
- 缺少环境。
- 第三方服务没测试。 应明确：
- 已完成：
- 未完成：
- 无法验证：
- 风险：
H. 修改范围原则
永远优先：
- 小范围。
- 可验证。
- 可回滚。
- 低耦合。 而不是：
- 一次改几十个无关文件。
I. 项目长期目标
本项目必须尽量保持：
- 可理解。
- 可修改。
- 可维护。
- 可测试。
- 可部署。
- 可恢复。
- 可扩展。
- 安全。 最终目标不是：
- “AI这次把它跑起来了。”
- 而是：
- “即使换一个AI、换一台电脑、换一个开发者，这个项目依然能够继续维护。”
AI任务统一结束报告模板
每一次AI开发任务结束，都使用：
本次任务
修改文件
新增文件
删除文件
修改功能
配置变化
依赖变化
数据库变化
安全影响
实际测试
Build状态
未验证内容
已知问题
后续建议
最后只能使用：
- ✅ 完成并验证
- ⚠️ 完成但仍有未验证项目
- ❌ 未完成
- 三种结论之一。