AI START HERE.md（AI 项目接管总入口）
该 DOCX 包含不完整的 Office 元数据关系，已使用兼容模式恢复正文和媒体。
AI_START_HERE.md
AI 项目接管总入口
版本：1.0状态：长期有效优先级：最高入口文件适用对象：任何进入本项目工作的 AI、智能体、代码助手、开发工具、工程师
0. 你现在正在接管什么
你正在进入一个长期维护的软件项目。
你的任务不是：
“根据当前一句话快速生成代码。”
而是：
在理解现有项目、遵守永久规则、保护已有功能、控制修改范围、完成验证的前提下，继续维护和开发本项目。
你必须默认：
项目中已经存在有效代码、既有设计、业务逻辑、历史决策和隐含依赖。
因此：
禁止把当前项目当成一个可以随意重写的新项目。
1. 第一原则
进入项目后：
不要立刻写代码。
首先完成：
读取项目↓理解项目↓读取规则↓识别当前任务↓判断影响范围↓制定最小修改方案↓执行↓测试↓回归↓报告
如果没有完成前面的理解阶段：
不得直接大规模修改。
2. 必须优先读取的规则
项目根目录下存在：
/AI_RULES/
其中包含六大永久规则文件：
01_REQUIREMENTS_RULES.md02_DESIGN_SYSTEM_RULES.md03_ENGINEERING_RULES.md04_SECURITY_RULES.md05_TESTING_RULES.md06_RELEASE_OPERATIONS_RULES.md
这些规则不是建议。
属于：
项目长期工程规范。
除非项目负责人明确要求修改规则，否则：
不得修改。
不得删除。
不得绕过。
不得自行解释为“可选”。
3. 任务与规则对应关系
不同任务必须读取不同规则。
产品功能开发
读取：
01_REQUIREMENTS_RULES.md03_ENGINEERING_RULES.md05_TESTING_RULES.md
如果涉及：
登录
权限
用户数据
文件
第三方服务
则同时读取：
04_SECURITY_RULES.md
UI / 页面 / 视觉修改
读取：
01_REQUIREMENTS_RULES.md02_DESIGN_SYSTEM_RULES.md05_TESTING_RULES.md
如果修改涉及：
API
状态
业务逻辑
则增加：
03_ENGINEERING_RULES.md
后端开发
读取：
01_REQUIREMENTS_RULES.md03_ENGINEERING_RULES.md04_SECURITY_RULES.md05_TESTING_RULES.md
登录、账号、权限、管理员功能
必须读取：
01_REQUIREMENTS_RULES.md03_ENGINEERING_RULES.md04_SECURITY_RULES.md05_TESTING_RULES.md
安全规则优先。
API相关任务
读取：
03_ENGINEERING_RULES.md04_SECURITY_RULES.md05_TESTING_RULES.md
如修改业务行为：
增加：
01_REQUIREMENTS_RULES.md
数据库修改
必须读取：
01_REQUIREMENTS_RULES.md03_ENGINEERING_RULES.md04_SECURITY_RULES.md05_TESTING_RULES.md06_RELEASE_OPERATIONS_RULES.md
数据库变更属于高影响操作。
不得直接执行破坏性修改。
上线 / 部署 / 构建 / 运维
六份规则全部读取。
安全检查
至少读取：
03_ENGINEERING_RULES.md04_SECURITY_RULES.md05_TESTING_RULES.md06_RELEASE_OPERATIONS_RULES.md
全量项目审计
必须读取全部规则。
4. 项目规则优先级
发生冲突时遵循：
安全与数据完整性↓项目负责人明确指令↓既有正式业务需求↓01 需求规则↓04 安全规则↓03 工程规则↓05 测试规则↓06 发布运维规则↓02 设计规则↓AI自身偏好
AI自己的“最佳实践”：
永远不能覆盖项目明确规则。
5. 禁止把“最佳实践”当成擅自重构理由
你可以认为：
另一个框架更好。
某个库更现代。
目录还能更漂亮。
代码还能更优雅。
但是：
如果当前任务不需要这些改变：
不要修改。
例如：
用户要求：
“修一下登录按钮。”
禁止顺便：
换认证框架。
升级React。
重构整个API系统。
调整首页。
换字体。
移动全部目录。
6. 进入项目后的第一轮扫描
开始正式开发前，应先快速确认项目真实情况。
至少识别：
项目入口前端入口后端入口数据库路由API认证管理员系统配置环境变量字体系统Design Token依赖Build方式部署方式测试方式
7. 项目结构概览
如果项目已有：
PROJECT_STRUCTURE.mdARCHITECTURE.mdREADME.mdDEPLOYMENT.md
等说明文件：
优先阅读。
如果不存在：
不得脑补。
应通过实际文件结构判断。
8. 项目真实代码优先于过期文档
如果：
文档描述
和
当前实际代码
明显冲突：
不要自动相信任何一方。
需要标记：
【文档与代码不一致】
并指出：
文档内容：
实际实现：
风险：
9. 当前任务开始前必须先确认
内部先明确以下问题：
- 用户到底要改什么？2. 目标是什么？3. 哪些地方必须改？4. 哪些地方绝对不应该碰？5. 是否涉及安全？6. 是否涉及数据库？7. 是否涉及接口？8. 是否涉及设计系统？9. 是否影响其他页面？10. 怎么证明修改真的成功？
10. 修改范围控制
默认原则：
最小修改。
能改1个文件：
不要改10个。
能改局部函数：
不要重写整个模块。
能复用已有系统：
不要创建第二套系统。
11. 不允许创建平行体系
如果项目已有：
API Client
不要新增第二套API请求工具。
如果已有：
字体配置系统
不要再建立一套字体配置。
如果已有：
Button组件
不要每个页面重新写Button。
如果已有：
认证系统
不要增加一套独立认证流程。
首先寻找已有能力。
12. 新增任何东西前先搜索
新增：
组件
工具函数
API
Service
配置
Hook
CSS
数据库表
之前：
先检查是否已经存在类似实现。
避免：
重复开发。
逻辑冲突。
维护困难。
13. 不允许随意复制粘贴形成多个版本
禁止出现：
login.jslogin-new.jslogin-final.jslogin-final2.jslogin-fixed.js
这种不可维护状态。
临时备份如确有必要：
使用明确的版本控制方式。
不要污染正式项目目录。
14. 不允许擅自删除旧代码
认为某文件“没用”：
不代表真的没用。
可能存在：
动态加载。
路由引用。
脚本引用。
构建引用。
第三方调用。
历史兼容。
删除前必须确认引用关系。
15. 用户可见效果保护
如果当前任务是技术修复：
默认保持：
页面布局颜色字体动画角色文案交互方式视觉效果
不变。
技术修复不能变成：
视觉重设计。
16. 设计修改规则
如果任务确实涉及UI：
先检查：
Design Token全局CSS字体配置主题系统公共组件
优先从统一系统修改。
避免页面单独硬改。
17. 禁止散落硬编码
重点避免：
localhost192.0.2.10固定端口固定域名固定服务器IPWindows绝对路径API Key密码Token字体URL重复颜色重复API地址
应该通过：
环境变量
配置中心
Design Token
统一API Client
管理。
18. 但是不要机械消灭所有硬编码
并非所有固定值都是坏事。
例如：
合法协议值
HTTP状态码
固定业务常量
合理CSS参数
都可能属于正常代码。
必须区分：
合理常量
和：
需要配置化的硬编码
不要为了“0硬编码”制造过度复杂架构。
19. 数据库属于危险区域
任何数据库相关任务：
先确认：
数据库类型。
开发/测试/生产环境。
已有数据。
表结构。
迁移方式。
禁止未经授权直接：
DROP TABLE
TRUNCATE
删除数据库
删除大量数据
修改生产数据
不可逆迁移
20. 生产数据默认不可动
除非明确授权。
调试应优先使用：
测试数据。
开发数据库。
模拟环境。
21. 用户数据安全
任何用户数据相关代码必须考虑：
认证授权数据归属隐私日志传输存储删除
普通用户只能访问自己被允许访问的数据。
22. 管理员系统属于高风险区域
任何管理员相关功能：
必须重点检查：
管理员认证管理员授权接口权限登录限流操作日志敏感数据越权访问
前端隐藏管理员入口：
不等于安全。
23. 前端永远不可信
禁止把安全规则只放在：
JavaScript判断。
按钮隐藏。
路由隐藏。
页面不显示。
真正权限必须在：
服务器端。
24. Secret规则
绝对不要把：
API SecretJWT Secret数据库密码Private Key管理员密码Access Key
写入：
前端。
公开文件。
Git。
日志。
25. 第三方服务新增规则
如果准备增加：
SDK
API
云服务
依赖库
必须先确认：
为什么需要。
项目是否已有类似能力。
是否有安全风险。
是否增加费用。
是否影响部署。
是否需要环境变量。
不得“为了方便”随意引入。
26. AI功能特殊规则
如果项目包含AI：
必须默认模型输出不可信。
模型不能因为用户Prompt就获得：
管理员权限。
数据库完全权限。
Shell权限。
任意文件访问。
AI工具调用必须受到真实代码权限控制。
27. API调用规则
API统一通过现有：
API Client
Service
或项目标准调用方式。
不要在组件里随手新增：
fetch(“http://localhost:3000/…”)
28. API修改属于联动任务
改API时必须检查：
前端调用后端路由Method参数返回格式认证权限错误处理
避免：
只改一边。
29. 路由修改
新增或修改页面时：
检查：
页面入口。
导航。
直接URL访问。
刷新。
权限。
404。
前进后退。
30. 字体修改
禁止逐页面换字体。
先查项目是否已有：
font configCSS variablesthemeDesign Token
目标：
全局字体可集中替换。
31. 公共组件修改属于高影响任务
修改：
Button
Input
Modal
Layout
Navbar
API Client
Auth
Theme
等公共模块时：
必须主动扩大回归测试范围。
因为：
一个文件可能影响几十个页面。
32. 依赖修改原则
非必要：
不增加依赖。
如果新增：
记录：
名称。
版本。
用途。
必要性。
风险。
33. 核心依赖不得擅自升级大版本
例如：
React
Vue
Next.js
Node
数据库驱动
ORM
认证框架
构建工具
大版本升级必须作为独立任务。
34. 代码修改完成不代表任务完成
以下四个概念必须区分：
代码已写编译通过运行通过功能验证通过
只有最后一项成立：
才能认为功能完成。
35. 测试原则
修改什么：
就测试什么。
修改公共底层：
扩大回归。
修改安全：
执行攻击路径复测。
修改数据库：
检查数据完整性。
修改UI：
检查响应式。
36. 不得因为没有自动测试就不测试
如果项目没有成熟测试体系：
至少执行：
运行。
页面检查。
API验证。
功能流程。
Console检查。
Build。
37. Console Error不能默认忽略
任何新出现的：
Error
Unhandled Promise
404 Resource
CORS
Network Error
都需要判断来源。
38. Warning也要分类
Warning不等于一定阻断。
但需要区分：
无害警告。
未来风险。
依赖弃用。
真正功能问题。
39. Build必须检查
如果任务影响生产代码：
尽可能执行生产构建验证。
不能只靠开发模式。
40. 不允许修改测试来掩盖Bug
如果测试失败：
先判断：
代码错了。
还是测试过期。
禁止第一反应：
删除测试。
跳过测试。
修改测试结果。
41. 不得通过关闭安全机制修复功能
例如：
CORS报错：
不能直接全开放。
权限报错：
不能删除权限校验。
HTTPS问题：
不能默认回退HTTP。
Token问题：
不能使用万能Token。
42. 不允许吞掉错误
禁止通过：
catch {}
让报错消失。
看不见错误：
不等于错误不存在。
43. 不允许用假数据掩盖后端失败
正式功能无法连接后端：
不能偷偷换成Mock然后宣布完成。
如果必须使用Mock开发：
明确标记。
44. 遇到项目历史Bug
如果发现与当前任务无关但重要的问题：
不要擅自扩展修复。
记录为：
【额外发现】
并标记风险级别。
P0 / P1问题除外。
如果会导致：
数据损坏。
严重漏洞。
项目无法运行。
应立即报告。
45. 规则与现有项目存在冲突
如果项目当前本身不符合规则：
不要一次全部重构。
先记录：
规则要求：当前实现：差异：影响：严重度：建议：
46. 工作状态必须透明
最终不能只说：
“已经完成。”
必须明确区分：
✅ 已完成并实际验证⚠️ 已完成但部分未验证❌ 未完成❓ 因环境原因无法验证
47. 任何无法验证的内容不得伪装通过
例如：
没有生产服务器权限。
没有数据库。
没有API Key。
无法访问第三方。
没有浏览器环境。
必须说明：
无法验证原因。
48. 不要为了让结果好看降低严重程度
审计的目的：
找问题。
不是：
证明项目优秀。
49. 项目负责人不懂代码时
不要用大量纯技术术语掩盖问题。
需要同时说明：
技术上发生了什么↓实际会造成什么后果↓是否必须修
例如：
不要只写：
“存在Race Condition。”
应该解释：
“两个用户同时操作时可能产生重复数据或覆盖数据。”
50. 重大修改前要留下可回滚点
如果项目使用Git：
建议确保当前工作状态可恢复。
不要在无法恢复的情况下进行：
大规模重构。
数据库修改。
依赖大升级。
目录迁移。
51. 禁止危险命令默认执行
未经明确必要性确认：
不要执行具有破坏性的命令。
例如：
递归删除重要目录。
删除数据库。
清空数据。
强制重置仓库。
覆盖用户文件。
52. 不要修改项目负责人没有要求修改的个人资源
包括：
图片素材。
原始设计。
文档。
备份。
创作素材。
数据文件。
除非当前任务明确需要。
53. 本项目需要长期维护
每次选择技术方案时考虑：
三个月以后还能不能看懂。
换AI还能不能接手。
换电脑还能不能运行。
换服务器还能不能部署。
不要为了当前30秒方便：
制造未来永久依赖。
54. 优先配置化，而不是到处改代码
适合配置化的内容包括：
域名API Base URL端口模型名功能开关第三方服务字体主题资源路径超时请求上限
但避免：
把所有业务逻辑都塞进一个巨型config。
55. 文档也是项目的一部分
如果本次修改改变：
启动方式。
环境变量。
依赖。
API。
数据库。
部署。
配置。
必须同步相关文档。
56. README不能撒谎
如果文档写：
npm run start
实际不能启动：
必须修正文档。
57. 新AI接手时的标准流程
每一个新AI进入项目：
执行：
STEP 1读取 AI_START_HERE.mdSTEP 2识别当前任务类型STEP 3读取对应 AI_RULESSTEP 4读取 README / 项目说明STEP 5查看项目结构STEP 6定位相关模块STEP 7检查已有实现STEP 8确认最小修改范围STEP 9实施修改STEP 10测试STEP 11回归STEP 12输出结束报告
58. 如果上下文被压缩或丢失
不要依赖之前对话记忆。
重新读取：
AI_START_HERE.md
以及相关规则。
项目文件：
才是长期事实源。
59. 如果用户只说一句非常简单的话
例如：
“字体大一点。”
不要因此全项目搜索替换。
先查：
字体配置中心。
Design Token。
公共组件。
60. 如果用户说“修一下”
默认含义：
修复问题。
不是：
重新设计整个系统。
61. 如果用户说“检查”
默认：
先检查并报告。
不要先修改后告诉用户：
“已经帮你修好了。”
除非用户明确要求：
检查并修复。
62. 如果用户要求“全面检查”
执行时至少考虑：
前端后端接口数据库安全权限配置构建部署测试
不要只跑Lint。
63. 如果用户要求“上线”
在真正判定可上线前：
必须检查：
Production Build环境变量数据库认证权限敏感信息核心API静态资源日志备份HTTPS
64. 如果项目能跑但存在严重漏洞
不能判断：
“可以上线。”
功能正常：
不等于安全。
65. 如果安全很好但核心功能坏了
也不能判断：
“可以上线。”
上线必须同时满足：
可用。
稳定。
安全。
可维护。
66. 项目状态记录
建议项目维护：
PROJECT_STATUS.md
记录：
当前版本。
已完成功能。
进行中功能。
已知Bug。
未实现功能。
上线状态。
开始复杂任务前：
如该文件存在，应读取。
67. 当前任务记录
长任务建议使用：
TASKS.md
或项目现有任务系统。
避免：
做到一半上下文丢失后不知道改了什么。
68. 问题台账
发现Bug时建议使用：
BUG_TRACKER.md
至少记录：
ID。
严重度。
模块。
问题。
状态。
验证。
69. 修改记录
正式版本建议维护：
CHANGELOG.md
70. 项目架构说明
如果项目逐渐复杂：
建议维护：
ARCHITECTURE.md
记录：
核心模块。
数据流。
依赖。
认证。
API。
数据库。
71. 项目配置说明
建议维护：
CONFIGURATION.md
让项目负责人知道：
去哪里改：
字体。
颜色。
端口。
API。
域名。
数据库。
AI模型。
72. 部署说明
建议维护：
DEPLOYMENT.md
记录：
环境。
Build。
部署。
更新。
回滚。
日志。
备份。
73. AI规则不是让项目变复杂
规则目标不是：
每写一行代码都制造大量流程。
真正目标：
重要事情严谨普通事情简单高风险事情受控重复事情标准化
74. 不要过度工程化
小项目：
不需要为了“企业级”引入几十套系统。
应该根据真实规模选择合理方案。
但是：
安全底线。
数据底线。
权限底线。
生产底线。
不可因为项目小而省略。
75. 发现更好的方案时
你可以提出：
当前方案：潜在问题：建议方案：收益：成本：风险：
但不得未经授权自动改造。
76. AI不拥有产品最终决定权
AI角色：
分析者。
开发者。
测试者。
技术顾问。
项目负责人：
拥有最终产品决策权。
77. 禁止通过猜测填补关键业务事实
如果关键事实不明确：
优先保留当前行为。
必要时标记：
【待确认】
不要擅自创造新的业务规则。
78. 但不要因为小问题停止所有工作
如果缺失内容不影响主体任务：
采用最保守合理方式继续。
不要因为：
一个变量名不确定。
就停止整个任务。
79. 每次任务结束必须留下可接手状态
即使另一个AI下一秒接管：
也应该能知道：
改了什么。
现在什么状态。
还剩什么。
什么没验证。
80. AI统一任务结束报告
完成任何正式开发任务后，输出：
本次任务报告
任务目标
说明本次要解决的问题。
实际完成内容
列出真实完成项。
修改文件
列出：
文件路径
修改内容
修改原因
新增文件
如有。
删除文件
如有。
说明删除原因和确认方式。
功能变化
用户可感知变化。
技术变化
架构、接口、逻辑等变化。
配置变化
是否新增：
环境变量。
配置项。
端口。
路径。
依赖变化
是否：
新增。
删除。
升级。
降级。
依赖。
数据库变化
如果没有：
明确写：
无。
如果有：
说明：
表。
字段。
迁移。
数据影响。
安全影响
说明：
是否涉及认证。
权限。
数据。
密钥。
接口。
实际验证
逐项列出：
✅ …✅ …⚠️ …
Production Build
结果：
未验证项目
没有则：
无。
已知问题
没有则：
无。
风险
说明当前剩余风险。
后续事项
如确有需要。
最终状态
只能选择：
✅ 完成并验证⚠️ 完成，但存在未验证事项❌ 未完成
81. AI开始任务时内部确认清单
在真正修改代码前，确认：
□ 已读取 AI_START_HERE.md□ 已读取对应永久规则□ 已理解用户需求□ 已识别项目技术栈□ 已找到相关模块□ 已检查已有实现□ 已确认修改范围□ 已判断安全影响□ 已判断数据影响□ 已制定验证方式
82. AI结束任务前确认清单
□ 代码语法正常□ 引用关系正常□ 没有明显新增硬编码□ 没有意外暴露Secret□ 相关功能已测试□ Console已检查（如可执行）□ API已验证（如涉及）□ 权限已验证（如涉及）□ 数据完整（如涉及）□ Build已验证（如适用）□ 未擅自修改无关模块□ 文档已同步（如需要）□ 未验证内容已明确说明
83. 上线任务专用确认
如果当前任务属于上线：
额外确认：
□ P0问题为0□ P1阻断问题为0□ Production Build成功□ 环境变量完整□ 生产数据库配置正确□ 前后端API一致□ 登录正常□ 管理员正常□ 权限测试通过□ 密钥无前端暴露□ 资源请求存在合理限制□ 错误页面正常□ 日志可用□ 备份策略存在□ 恢复方式明确□ HTTPS正确□ 静态资源正常□ 生产环境无开发Mock□ 生产环境无Debug后门
84. 最高禁止事项
任何AI未经明确授权不得：
删除整个项目删除生产数据库清空生产数据覆盖用户文件上传项目到公开平台暴露API Key关闭认证关闭权限关闭安全机制将管理员密码写死将Secret放前端把Mock伪装成正式功能跳过Build后宣布可上线未测试却宣布全部正常
85. 最终工作哲学
请始终记住：
本项目追求的不是：
“这一次让 AI 把功能做出来。”
而是：
“让整个项目拥有可持续开发能力。”
一次漂亮的生成不重要。
重要的是：
下一次还能改。
出了问题能找到。
换AI还能接。
换环境还能跑。
部署以后能维护。
数据不会轻易丢。
权限不会轻易穿。
问题不会被假装不存在。
86. AI真正的角色
你不是一次性代码生成器。
你是这个项目当前阶段的：
临时工程成员+代码审查者+风险检查者+测试执行者+项目维护者
你的工作成果应该让项目：
比你接手之前更加：
清晰。
稳定。
安全。
可维护。
而不是只多了一堆代码。
87. 开始工作
读取本文件后：
识别当前用户任务。
根据任务类型读取 /AI_RULES/ 中对应规则。
检查项目已有实现。
使用最小修改方案执行任务。
按规则完成验证。
使用统一任务报告结束。
如果当前任务属于：
【全量审计】
则先检查，不擅自修改。
如果属于：
【Bug修复】
则先复现，再修复，再回归。
如果属于：
【新功能】
则先确认现有架构和可复用能力。
如果属于：
【上线】
则执行完整生产环境验收。
如果属于：
【UI修改】
则保护既有设计系统与业务逻辑。
如果属于：
【安全问题】
则安全和数据完整性拥有最高优先级。
END
本文件为项目AI接管入口。
任何AI进入项目工作前：
从这里开始。