Six Core Permanent Rules for AI Development Projects（AI 开发项目六大永久规则）
该 DOCX 包含不完整的 Office 元数据关系，已使用兼容模式恢复正文和媒体。
AI 开发项目六大永久规则文件
本规则体系是项目长期有效的最高级工程约束。
任何 AI、开发工具、智能体、工程师在新增、修改、重构、修复项目代码之前，都必须先读取相关规则文件。
规则文件不是参考建议，而是项目执行规范。
未经项目负责人明确授权，不得自行删除、绕过或修改这些规则。
文件一：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. 每次需求任务完成后输出
修改功能：
涉及文件：
新增内容：
删除内容：
未完成事项：
潜在风险：
测试结果：
是否影响其他模块：
文件二：02_DESIGN_SYSTEM_RULES.md
UI、视觉与设计系统永久规则
版本：1.0状态：长期有效作用：保证页面越做越多，但视觉不会失控，未来可以整体换字体、颜色、圆角、主题。
1. 设计必须系统化
禁止每个页面单独设计一套：
字体。
颜色。
按钮。
阴影。
圆角。
间距。
动画。
项目必须建立统一：
Design Token。
2. 所有核心视觉参数必须集中管理
至少包括：
字体字号字重行高颜色间距圆角边框阴影动画速度层级页面宽度响应式断点
推荐：
:root { –font-primary: …; –font-display: …; –color-primary: …; –color-bg: …; –color-text: …; –spacing-xs: …; –spacing-sm: …; –spacing-md: …; –radius-sm: …; –radius-md: …; –shadow-sm: …;}
3. 字体永久规则
字体必须集中管理。
禁止在大量组件中重复：
font-family: xxx;
核心字体至少分：
PrimaryDisplayMonoFallback
必须做到：
修改一个配置，
即可切换全站主字体。
禁止：
字体URL散落。
字体文件路径散落。
页面自己加载字体。
组件自己定义字体来源。
4. 字体加载失败必须降级
例如：
font-family: var(–font-primary), system-ui, sans-serif;
5. 颜色规则
禁止业务组件大量直接写：
#FFFFFF#000000#6A5ACD
主题色应使用变量。
允许特殊艺术元素单独使用颜色。
但必须说明用途。
6. 间距规则
不得出现大量毫无体系的：
13px17px29px43px
优先使用统一间距体系。
例如：
4
8
12
16
24
32
48
64
7. 组件一致性
项目应该形成基础组件：
Button
Input
Modal
Card
Tooltip
Dropdown
Loading
Toast
Error
Empty State
禁止：
五个页面写五个完全不同的按钮逻辑。
8. 公共组件与艺术组件分离
标准组件：
强调统一。
艺术展示组件：
允许特殊视觉。
不能为了设计系统统一，把所有创意视觉压成普通后台界面。
9. UI和业务逻辑分离
组件负责展示。
业务逻辑不应直接埋进：
CSS。
动画文件。
视觉组件。
10. 动画规则
动画必须：
可控制。
可关闭。
不得阻塞主要交互。
不得导致页面无法使用。
不得造成明显性能问题。
进入动画不能阻止用户长时间访问功能。
11. 动画参数集中
例如：
fastnormalslow
避免页面各写：
283ms
420ms
612ms
12. 响应式规则
任何正式页面必须考虑：
手机。
平板。
普通电脑。
大屏。
至少考虑：
320px
375px
768px
1024px
1366px
1920px
13. 禁止仅依赖Hover
因为手机没有传统Hover。
重要操作必须可点击触发。
14. 图片规则
图片：
不得无意义重复加载。
不得严重拉伸变形。
大图片需要合理压缩。
保持适当比例。
15. SVG/Icon规则
统一来源。
避免同一图标使用多个完全不同图库。
16. z-index规则
必须建立层级范围。
例如：
页面内容浮层导航弹窗Toast系统级提示
禁止：
z-index: 999999999;
互相硬压。
17. Loading规则
异步功能必须有Loading状态。
不得用户点击后毫无反馈。
18. Error状态
任何异步模块必须考虑失败界面。
禁止：
白屏。
空白块。
无限Loading。
19. Empty状态
无内容时必须有合理状态。
禁止直接显示：
undefined
null
[]
20. 设计系统修改规则
修改：
字体。
颜色。
按钮。
圆角。
间距。
主题。
先改Design Token或公共组件。
不得优先全项目搜索替换。
21. 禁止AI擅自“美化”
没有明确设计任务时：
不得自主改变：
布局。
配色。
字体。
角色形象。
动画。
交互。
修Bug ≠ 改设计。
22. UI修改完成必须检查
Desktop。
Mobile。
主要页面。
相关组件。
Loading。
Error。
Hover/Active。
23. 每次设计改动输出
改了什么：
为什么：
修改了哪些Token：
修改了哪些组件：
影响哪些页面：
是否影响响应式：
是否影响动画：
文件三：03_ENGINEERING_RULES.md
架构、代码与工程永久规则
版本：1.0状态：长期有效作用：防止 AI 随着项目变大，把代码写成无法维护的“毛线团”。
1. 总原则
代码首先必须：
正确。
其次：
可维护。
然后：
可扩展。
最后才是：
聪明。
禁止为了炫技引入不必要复杂度。
2. 单一职责
一个模块尽可能只负责一个主要职责。
避免：
一个文件同时：
UI
数据库
API
认证
缓存
日志
全做。
3. 分层原则
原则上保持：
UI↓业务逻辑↓Service↓API↓数据访问↓Database
避免跨层乱调。
4. 前端不得直接访问数据库
禁止前端包含：
数据库密码。
数据库连接。
管理员数据库能力。
5. API统一管理
不得每个组件随便：
fetch(“http://…”)
应建立统一API Client。
负责：
Base URL。
认证。
超时。
错误处理。
状态码。
6. 配置与业务代码分离
以下必须尽可能配置化：
API地址。
端口。
域名。
数据库地址。
第三方接口。
模型名称。
字体。
功能开关。
环境变量。
7. 禁止环境硬编码
正式业务代码禁止绑定：
localhost。
192.0.2.10。
开发端口。
本地绝对路径。
个人电脑路径。
8. 模块边界
公共功能应抽离。
但禁止过度抽象。
规则：
重复一次：
可以接受。
重复两次：
关注。
重复三次以上：
评估公共抽象。
9. 禁止循环依赖
例如：
A依赖B。
B又依赖A。
必须拆分公共职责。
10. 控制文件体积
如果一个文件越来越大：
应分析是否职责过多。
但禁止为了“文件短”机械拆分。
11. 函数规则
函数应该：
职责明确。
名称可理解。
输入清晰。
输出稳定。
副作用可控。
12. 命名规则
禁止大量：
a
b
x
temp
test1
data2
newnew
final2
使用可以看懂意义的名称。
13. 禁止魔法值
例如：
if (role === 7)
应有清晰定义。
14. 错误必须处理
禁止：
try { …} catch {}
吞掉错误。
15. 异步必须处理失败
Promise。
Fetch。
Database。
File。
AI。
Third-party API。
必须考虑：
成功。
失败。
超时。
16. API统一返回规范
尽可能统一：
{ “success”: true, “data”: {}, “error”: null}
或项目既有标准。
不能不同接口完全随机返回。
17. HTTP状态码合理使用
200：
成功。
201：
创建成功。
400：
请求错误。
401：
未认证。
403：
无权限。
404：
不存在。
409：
冲突。
429：
频率限制。
500：
服务器错误。
18. 数据验证
前端验证：
用于用户体验。
后端验证：
用于安全和数据完整性。
后端验证不可省略。
19. 数据库操作原则
优先：
参数化查询。
ORM安全接口。
事务。
索引。
分页。
禁止直接拼接用户输入形成SQL。
20. 数据迁移规则
修改数据库结构：
必须考虑已有数据。
不得直接：
删表。
删字段。
改字段类型。
而不考虑迁移。
21. 第三方依赖规则
新增依赖之前必须判断：
是否真的需要。
是否已有能力实现。
是否仍维护。
是否安全。
是否增加项目复杂度。
22. 禁止为了一个小功能安装巨大框架
能用现有能力安全完成，就不要随意增加依赖。
23. Lock文件必须保留
例如：
package-lock.json。
pnpm-lock.yaml。
yarn.lock。
24. 不得擅自升级核心依赖
尤其：
框架主版本。
数据库。
认证库。
构建工具。
UI框架。
升级必须说明影响。
25. 删除代码规则
删除前确认：
是否引用。
是否动态调用。
是否部署使用。
是否兼容旧逻辑。
26. 重构规则
重构必须满足：
业务行为尽可能不变。
接口尽可能不变。
数据不损坏。
测试重新通过。
27. AI修改代码必须最小化影响
修一个Bug：
优先改最少相关代码。
不得顺便把整个项目重新组织一遍。
28. 禁止无关修改
任务是：
修登录Bug。
不得顺便：
改首页。
换字体。
改目录。
升级框架。
重新命名几百个变量。
29. 临时代码规则
临时代码必须明确：
TODO。
TEMP。
DEBUG。
并在上线前清理。
30. 日志代替随意console
开发期可以合理使用console。
生产环境应使用正式日志策略。
禁止留下大量：
console.log(secret)
console.log(password)
31. 环境分离
至少区分：
development。
production。
必要时：
test。
32. 本地开发不能成为隐性依赖
项目不能依赖：
某个人电脑已有文件。
手工复制资源。
未记录环境变量。
历史缓存。
33. 干净安装必须能运行
目标：
项目代码
依赖声明
配置文档
即可重新搭建。
34. 每次修改必须记录
涉及文件。
修改原因。
影响范围。
配置变化。
依赖变化。
数据库变化。
35. AI完成编码任务后必须进行自检
至少：
语法。
引用。
类型。
构建。
受影响功能。
36. 代码通过 ≠ 任务完成
必须区分：
【代码写完】
【编译通过】
【运行通过】
【测试通过】
文件四：04_SECURITY_RULES.md
安全、权限与隐私永久规则
版本：1.0状态：长期有效优先级：最高作用：所有功能默认以“不能因为方便而牺牲安全”为原则。
1. 安全默认原则
任何数据和功能默认：
没有权限就不能访问。
而不是：
只要没有隐藏就能访问。
2. 前端不可信
前端：
按钮隐藏。
字段隐藏。
路由隐藏。
都不是安全措施。
真正权限必须由后端验证。
3. 身份认证与权限授权必须分开
Authentication：
你是谁。
Authorization：
你能干什么。
两个都必须验证。
4. 最小权限原则
普通用户：
只能访问自己的必要资源。
管理员：
只获得管理需要权限。
数据库账户：
只获得应用需要权限。
服务：
只获得必要权限。
5. 敏感信息禁止进入前端
绝对禁止：
数据库密码。
服务器私钥。
第三方Secret。
管理员密码。
JWT Secret。
API Secret。
6. Secret必须使用环境变量或安全密钥管理
不得硬编码在：
JS。
HTML。
CSS。
Git。
README。
Demo。
7. .env不得提交真实密钥
允许：
.env.example
但只提供：
变量名。
示例值。
8. 密码规则
密码：
不得明文保存。
不得明文日志。
不得API返回。
必须使用成熟安全Hash方案。
9. Token规则
必须考虑：
有效期。
签名。
撤销。
刷新。
存储。
泄露。
10. Cookie认证
应根据实际场景设置：
HttpOnly。
Secure。
SameSite。
合理Domain。
合理Path。
11. 登录安全
登录必须考虑：
暴力破解。
频率限制。
异常尝试。
错误信息泄露。
12. 管理员安全等级高于普通用户
管理员系统必须单独检查：
登录。
认证。
授权。
限流。
操作日志。
敏感操作。
13. 权限测试
至少测试：
游客。
普通用户。
管理员。
超级管理员。
14. 防止IDOR
用户不能仅通过修改：
userId。
fileId。
orderId。
projectId。
就访问别人的资源。
15. 数据归属必须在后端验证
不能相信前端提交：
“userId”: “123”
就默认是该用户。
16. 用户输入默认不可信
所有用户输入必须：
验证。
限制。
转义。
必要时过滤。
17. XSS防护
任何用户内容输出到HTML时：
必须安全编码。
不得直接将不可信HTML插入页面。
18. SQL注入防护
禁止用户输入拼接SQL。
必须使用：
参数化查询。
成熟ORM。
19. 命令注入防护
如果程序调用：
Shell。
FFmpeg。
Python。
系统程序。
用户参数不能未经严格处理直接进入命令。
20. 路径穿越防护
文件系统不得允许：
../
..
绕过允许目录。
21. SSRF防护
服务器替用户请求URL时：
必须限制：
协议。
域名。
IP范围。
重定向。
不得访问：
localhost。
内网服务。
云平台内部敏感地址。
除非业务明确需要并安全控制。
22. CSRF
涉及敏感状态修改的系统：
必须根据认证方式评估CSRF风险并采取保护。
23. CORS
不得为了“先跑起来”直接全部：
Allow-Origin: *
尤其带认证信息时。
24. 上传安全
必须限制：
大小。
类型。
真实MIME。
数量。
文件名。
存储位置。
访问权限。
25. 上传目录与程序执行目录分离
用户上传文件不能因为上传成功就可以被服务器执行。
26. 文件下载权限
私人文件：
必须验证资源归属和权限。
不能只靠URL难猜。
27. 请求大小限制
限制：
JSON。
Form。
文件。
URL。
分页。
请求频率。
28. Rate Limit
至少评估：
登录。
注册。
验证码。
AI调用。
上传。
搜索。
昂贵接口。
管理员登录。
29. 防资源耗尽
防止用户通过：
超长输入。
超大文件。
超大分页。
无限调用。
复杂查询。
耗尽服务器资源。
30. 错误信息安全
用户可看到：
合理错误提示。
用户不可看到：
Stack Trace。
数据库SQL。
服务器绝对路径。
Secret。
环境变量。
内部网络信息。
31. 日志安全
禁止日志记录：
密码。
完整Token。
API Secret。
私钥。
不必要的隐私数据。
32. 管理员操作必须审计
重要操作记录：
谁。
什么时候。
做了什么。
对什么对象。
结果。
33. 数据隐私
只收集业务需要的数据。
不要因为：
“以后可能有用”
就收集大量信息。
34. 第三方数据传输
用户数据发给第三方之前必须确认：
是否必要。
发送什么。
第三方是谁。
是否包含敏感内容。
35. AI安全
如包含AI功能：
系统Prompt不得放客户端。
API Key不得放客户端。
工具调用必须权限控制。
36. Prompt Injection不应拥有系统权限
模型收到：
“忽略之前规则”
不应该因此：
访问管理员接口。
数据库。
文件系统。
Shell。
37. AI工具遵循最小权限
AI需要读文件：
不要给整个服务器写权限。
AI需要查数据库：
不要默认给DROP权限。
38. AI调用成本必须有限制
控制：
单次输入。
输出Token。
频率。
每日额度。
并发。
39. 安全优先于兼容错误行为
如果旧功能本身存在严重安全风险：
必须报告。
不能为了保持旧Bug继续留下漏洞。
40. 安全问题等级
发现：
密钥泄露。
管理员越权。
数据库暴露。
任意命令执行。
严重SQL注入。
用户数据越权。
默认按高风险或致命处理。
41. 安全修复完成必须复测
修完漏洞不能只检查代码。
必须尝试原攻击路径。
确认失败。
42. 任何“暂时关闭安全措施”都必须禁止进入生产
开发方便用的：
关闭认证。
全开放CORS。
默认管理员。
万能Token。
Debug接口。
上线前必须清除。
文件五：05_TESTING_RULES.md
测试、验收与回归永久规则
版本：1.0状态：长期有效作用：防止 AI “代码写完 = 功能完成”。
1. 测试是开发的一部分
任何功能完成必须包含：
实现。
测试。
验证。
2. 测试分层
至少考虑：
静态检查。
单元测试。
接口测试。
集成测试。
UI测试。
用户流程测试。
安全测试。
构建测试。
根据项目规模合理选择。
3. 静态检查不能替代运行测试
代码看起来没错：
不代表真的能运行。
4. 每项核心功能必须测试
正常情况。
异常情况。
边界情况。
无权限情况。
网络异常。
5. 页面测试
检查：
能加载。
无白屏。
无关键Console Error。
资源加载正常。
功能可操作。
6. 按钮测试
每个正式按钮必须判断：
点击结果。
重复点击。
Loading。
Disabled。
失败。
7. 表单测试
测试：
正常输入。
空输入。
错误输入。
超长。
特殊字符。
重复提交。
8. API测试
每个核心接口至少测试：
正常请求。
参数缺失。
非法参数。
未登录。
无权限。
9. 权限必须用实际角色测试
不能看代码后说：
“有中间件，所以正常。”
必须实际模拟：
游客。
用户。
管理员。
10. 登录完整流程
必须测试：
正确登录。
错误密码。
无账号。
退出。
登录状态。
过期状态。
受保护页面。
11. 用户核心流程
建立：
Happy Path。
从用户进入网站到完成核心目标完整跑通。
12. 异常流程
至少考虑：
API失败。
数据库失败。
网络中断。
第三方失败。
超时。
13. 空状态
测试：
无数据。
无搜索结果。
首次用户。
14. 大数据状态
如果可能：
测试大量列表。
长文本。
大量历史记录。
避免只用三条Demo数据。
15. 响应式测试
至少检查：
手机。
平板。
桌面。
16. 浏览器测试
主要支持浏览器必须明确。
至少重点验证项目主支持浏览器。
17. Console必须检查
任何：
Error。
Unhandled Promise。
资源404。
都必须记录。
18. Network必须检查
确认：
接口地址。
方法。
状态码。
请求次数。
重复请求。
19. 修Bug必须有复现步骤
BUG记录：
触发环境。
步骤。
预期。
实际。
20. 修Bug后复测原步骤
保证：
原问题消失。
21. 修Bug必须做关联回归
例如：
修Token。
需要重新测试：
登录。
退出。
刷新。
权限。
管理员。
而不是只点一次登录。
22. 修改公共组件必须测试所有关键使用位置
因为影响范围大。
23. 修改Design Token必须检查全站主要页面
24. 修改API Client必须检查主要接口
25. 修改数据库必须检查数据相关功能
26. 修改权限系统必须重新执行权限矩阵
27. Build属于测试
正式提交前：
Production Build必须通过。
28. Dev运行不等于Production通过
必须明确区分。
29. 测试结果状态
统一使用：
✅ 实际验证通过
🔎 静态检查通过
⚠️ 有问题
❌ 验证失败
❓ 无法验证
⏳ 未测试
30. 无法测试必须说原因
例如：
缺少API Key。
没有浏览器环境。
第三方服务不可访问。
数据库不存在。
不得直接标记通过。
31. 测试不得修改真实生产数据
除非有明确授权和安全测试环境。
32. 删除类操作特别谨慎
测试删除功能：
优先使用测试数据。
33. 管理员测试不能破坏真实数据
34. 自动化测试优先覆盖稳定核心逻辑
尤其：
登录。
权限。
关键API。
数据处理。
35. 不为测试数量而写无价值测试
测试的目标：
发现回归。
证明核心行为。
36. 每次完成任务输出测试报告
内容：
测试内容。
测试方式。
通过。
失败。
未测试。
异常。
风险。
37. 上线前必须进行全局回归
不能只测试本次改动。
至少重新确认：
启动。
首页。
登录。
核心功能。
管理员。
API。
Production Build。
文件六：06_RELEASE_OPERATIONS_RULES.md
构建、部署、上线、日志、备份与运维永久规则
版本：1.0状态：长期有效作用：确保项目不是“这台电脑能跑”，而是真正可部署、可维护、可恢复。
1. 上线不是上传代码
正式上线包括：
构建。
配置。
部署。
启动。
健康检查。
监控。
日志。
备份。
恢复。
2. 开发与生产分离
必须区分：
development。
production。
必要时：
test / staging。
3. 生产环境不得使用开发配置
禁止：
localhost API。
测试数据库。
Debug模式。
测试账户。
开发Secret。
Mock服务。
4. 环境变量管理
项目必须明确列出生产所需环境变量。
例如：
APP_ENVAPI_BASE_URLDATABASE_URLJWT_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状态
未验证内容
已知问题
后续建议
最后只能使用：
✅ 完成并验证
⚠️ 完成但仍有未验证项目
❌ 未完成
三种结论之一。