RELEASE OPERATIONS RULES
文件六：06_RELEASE_OPERATIONS_RULES.md
# 文件六：06_RELEASE_OPERATIONS_RULES.md
# 构建、部署、上线、日志、备份与运维永久规则
版本：1.0
状态：长期有效
作用：确保项目不是“这台电脑能跑”，而是真正可部署、可维护、可恢复。
# 1. 上线不是上传代码
正式上线包括：
- 构建。
- 配置。
- 部署。
- 启动。
- 健康检查。
- 监控。
- 日志。
- 备份。
- 恢复。
# 2. 开发与生产分离
必须区分：
- development。
- production。
- 必要时：
- test / staging。
# 3. 生产环境不得使用开发配置
禁止：
- localhost API。
- 测试数据库。
- Debug模式。
- 测试账户。
- 开发Secret。
- Mock服务。
# 4. 环境变量管理
项目必须明确列出生产所需环境变量。
- 例如：
`
APP_ENV
API_BASE_URL
DATABASE_URL
JWT_SECRET
第三方服务Key
`
# 5. 提供 .env.example
不能包含真实Secret。
# 6. 部署不能依赖开发者记忆
必须有文档说明：
- 安装什么。
- 配置什么。
- 怎么启动。
- 怎么Build。
- 怎么部署。
# 7. Production Build必须成功
不能只有：
- npm run dev
- 能运行。
- 正式构建必须验证。
# 8. 干净环境验证
目标：
- 新的环境拿到项目，
- 按照文档，
- 可以重新部署。
# 9. 依赖版本必须稳定
使用Lock文件。
- 不要生产环境随机获得新版本。
# 10. 数据库迁移必须可控
生产环境不得启动时无提示自动执行危险数据库修改。
# 11. 域名配置化
换域名不应修改大量源码。
# 12. HTTPS
正式外网网站原则上使用HTTPS。
# 13. HTTP重定向
正式环境合理配置：
- HTTP → HTTPS。
# 14. 反向代理规则需要记录
如使用Nginx等：
- API路径。
- 静态资源。
- 上传限制。
- 超时。
- WebSocket。
# 15. SPA必须检查刷新路由
例如：
- /dashboard
- 直接访问不能意外404。
# 16. 静态资源路径
Build后确认：
- JS。
- CSS。
- 字体。
- 图片。
- 都可访问。
# 17. Source Map
生产环境根据需要决定是否公开。
- 不得无意识暴露大量源码信息。
# 18. 日志体系
至少应考虑：
- 应用错误。
- 访问。
- 登录。
- 管理员操作。
- 关键业务。
# 19. 日志必须可定位问题
至少记录合理：
- 时间。
- 事件。
- 结果。
- 错误标识。
# 20. 日志不能无限增长
需要：
- 轮转。
- 归档。
- 清理策略。
- 避免占满磁盘。
# 21. 健康检查
正式长期运行服务建议提供Health Check。
- 检查：
- 应用。
- 数据库。
- 关键依赖。
# 22. 服务异常恢复
考虑：
- 程序崩溃。
- 服务器重启。
- 数据库短暂断开。
服务应有合理恢复机制。
# 23. 优雅关闭
服务关闭：
- 停止接受新请求。
- 处理必要任务。
- 释放数据库连接。
- 释放资源。
# 24. 备份原则
至少考虑：
- 数据库。
- 用户上传。
- 关键配置。
# 25. 备份和代码仓库不是一回事
Git不能代替数据库备份。
# 26. 备份必须有周期
根据数据重要程度制定。
# 27. 备份必须有保留策略
避免：
- 永远覆盖唯一一个备份。
# 28. 恢复比备份更重要
必须知道：
- 数据库怎么恢复。
- 文件怎么恢复。
- 配置怎么恢复。
# 29. 定期验证备份是否可用
不能只看到：
- backup.zip
- 就认为安全。
# 30. 发布前必须有检查清单
至少：
- 代码提交完成。
- 依赖确认。
- 配置确认。
- 数据库确认。
- Build通过。
- 测试通过。
- 安全检查通过。
- 备份完成。
# 31. 上线前P0/P1必须处理
已知致命和高风险问题原则上不得带病上线。
# 32. 发布必须可回滚
重大更新前必须知道：
- 如果失败怎么恢复旧版本。
# 33. 数据库变更必须有回滚/恢复思路
尤其不可逆修改。
# 34. 禁止上线时临时大规模重构
上线阶段目标是：
- 稳定。
- 不是：
- 顺便把架构改漂亮。
# 35. 上线后检查
必须验证：
- 首页。
- 登录。
- API。
- 核心功能。
- 管理员。
- 静态资源。
- 数据库。
- 日志。
# 36. 生产环境错误不能只看用户反馈
需要日志和监控。
# 37. 第三方服务需要故障策略
例如：
- AI服务挂了。
- 邮件服务挂了。
- 对象存储挂了。
系统应：
- 合理降级。
- 明确提示。
- 避免整个网站崩溃。
# 38. 外部API必须配置超时
不能无限等待。
# 39. 重试必须有限制
禁止无限重试造成：
- 请求风暴。
- 费用爆炸。
- 服务器压力。
# 40. AI服务成本保护
如使用收费模型：
- 必须有：
- 请求上限。
- Token上限。
- 并发控制。
- 异常成本保护。
# 41. 管理员操作应可追踪
尤其：
- 删数据。
- 改权限。
- 封账号。
- 改配置。
# 42. 更新流程
推荐：
- 备份
- ↓
- 部署新版本
- ↓
- 迁移
- ↓
- 启动
- ↓
- Health Check
- ↓
- 核心流程测试
- ↓
- 确认上线
失败：
- ↓
- 停止继续发布
- ↓
- 回滚
- ↓
- 检查日志
- ↓
- 恢复服务
# 43. 版本号
正式发布建议建立：
- 版本号。
- 发布时间。
- 主要修改。
例如：
- v1.0.0
- v1.0.1
- v1.1.0
# 44. CHANGELOG
重要版本记录：
- 新增。
- 修复。
- 安全修改。
- 兼容问题。
- 数据库修改。
# 45. 生产环境禁止随手改代码
正式变更必须：
- 修改源码。
- 测试。
- Build。
- 发布。
- 而不是直接服务器现场手改。
# 46. 上线判定
只有满足：
- 核心功能通过。
- Production Build通过。
- 权限通过。
- 安全无已知严重问题。
- 配置正确。
- 日志可用。
- 有恢复方案。
- 才能判定：
- 【可正式上线】
六大规则共同执行协议
以下内容同时适用于全部六份文件。
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状态
未验证内容
已知问题
后续建议
最后只能使用：
- ✅ 完成并验证
- ⚠️ 完成但仍有未验证项目
- ❌ 未完成
- 三种结论之一。