项目 Bug、风险与问题追踪台账
该 DOCX 包含不完整的 Office 元数据关系，已使用兼容模式恢复正文和媒体。
BUG_TRACKER.md
项目 Bug、风险与问题追踪台账
文档版本： v1.0文档状态： 持续维护最后更新： 2026-07-27文档性质： 项目问题事实源适用对象： 项目负责人、AI开发助手、测试AI、安全审计AI、后续维护人员
0. 本文件是什么
本文件用于记录：
已发现Bug
功能异常
安全漏洞
架构问题
配置冲突
硬编码问题
API异常
数据库问题
UI问题
Build问题
部署问题
性能问题
依赖风险
日志问题
AI功能问题
已修复问题
已验证问题
复发问题
本文件负责回答：
项目目前到底有哪些已知问题？
以及：
这个问题之前是不是出现过？
1. 本文件与其他文件的关系
项目现在做到哪
查看：
PROJECT_STATUS.md
项目结构在哪
查看：
ARCHITECTURE.md
配置去哪改
查看：
CONFIGURATION.md
历史版本改了什么
查看：
CHANGELOG.md
怎么部署
查看：
DEPLOYMENT.md
2. Bug管理最高原则
发现问题以后：
不要只在聊天里说。
必须进入：
BUG_TRACKER.md
如果AI说：
“发现3个问题。”
那么这3个问题必须：
编号↓分类↓分级↓记录位置↓记录影响↓记录状态
不能下个窗口以后全部消失。
3. Bug不是只有代码报错
本项目将以下内容统一纳入问题台账：
程序错误功能失效UI异常交互异常安全漏洞权限漏洞数据风险硬编码高度耦合配置冲突API错误依赖漏洞性能问题部署问题日志缺失测试失败文档与代码不一致
4. 问题ID规则
统一格式：
BUG-0001BUG-0002BUG-0003
编号一旦创建：
不得复用。
即使问题被关闭：
原编号永久保留。
安全问题可以增加标签：
BUG-0042标签：SECURITY
而不是重新建立另一套编号。
5. 状态规则
所有问题只能使用以下状态：
🔴 OPEN
问题已经确认存在。
尚未开始修复。
🟠 INVESTIGATING
正在定位原因。
根因尚未完全确认。
🟡 FIXING
已经确认根因。
正在修复。
🔵 FIXED
代码已经修改。
但是：
还没有完成完整验证。
🟢 VERIFIED
已经：
修复
实际测试
相关回归
确认通过。
🟣 MONITORING
问题已经修复。
但属于：
偶发
性能
并发
生产环境
等无法一次完全证明的问题。
需要继续观察。
⚫ WONTFIX
确认存在。
但明确决定暂时不修。
必须写原因。
⚪ INVALID
经过调查：
并不是Bug。
例如：
误报
预期行为
测试方法错误
环境问题
🔁 REOPENED
原本已经关闭。
但问题再次出现。
6. 严重程度
统一使用：
P0P1P2P3
P0 — 致命
可能造成：
项目无法启动
项目无法部署
数据库损坏
大规模数据泄露
任意管理员权限获取
远程命令执行
核心Secret暴露
核心业务完全不可用
原则：
禁止上线
P1 — 高风险
可能造成：
登录不可用
管理员异常
用户越权
核心API失效
严重安全漏洞
Production Build失败
重要数据异常
高概率崩溃
严重费用失控
原则：
上线前必须处理
P2 — 中风险
例如：
部分功能异常
页面错位
非核心API异常
高耦合
配置分散
性能明显下降
部分浏览器兼容问题
错误处理不足
原则：
视业务影响安排修复。
P3 — 低风险
例如：
轻微UI问题
可读性
代码规范
非关键重复代码
未来维护风险
小范围体验问题
通常不阻断上线。
7. 问题类型
每个问题必须选择至少一个类型。
FUNCTIONUIUXFRONTENDBACKENDAPIDATABASEAUTHPERMISSIONADMINSECURITYCONFIGHARDCODEARCHITECTUREDEPENDENCYBUILDDEPLOYMENTPERFORMANCELOGCACHEUPLOADAITESTDOCUMENTATIONOTHER
8. Bug完整模板
每个正式问题使用：
BUG-XXXX
标题：
状态
OPEN
严重程度
P0 / P1 / P2 / P3
类型
API / SECURITY / UI …
发现日期
YYYY-MM-DD
发现方式
例如：
人工测试AI静态检查自动测试Build生产日志用户反馈安全审计
影响模块
【填写】
文件
【填写真实路径】
代码位置
【行号 / 函数 / 类 / 模块】
问题描述
清楚说明：
到底哪里不正常。
预期行为
应该发生什么。
实际行为
实际上发生什么。
复现条件
例如：
浏览器：环境：账号角色：网络状态：数据状态：
复现步骤
1.2.3.4.
复现概率
100%高概率偶发未知
错误信息
【如存在】
不得将Secret复制进本文件。
Console
【如存在】
HTTP状态
【如涉及】
日志证据
【如存在】
截图/附件
【如存在】
根因
【未确认 / 已确认】
详细说明：
影响
可能导致：
是否影响上线
是 / 否 / 待确认
临时规避方案
如有：
正式修复方案
修改文件
【修复后填写】
修复日期
【修复后填写】
修复状态
未修复 / 已修改待验证 / 已验证
验证方式
验证结果
✅ 通过❌ 失败⚠️ 部分通过❓ 无法验证
回归测试
检查：
□ 原问题已消失□ 相关功能正常□ 公共模块未受影响□ 未引入新Console Error□ API正常□ 权限正常□ Build正常
按实际任务选择。
关联问题
BUG-XXXX
关联提交/版本
【如有】
备注
9. Bug简化模板
对于P3或非常简单的问题，可以使用：
BUG-XXXX
标题：状态：严重度：类型：文件：问题：影响：修复：验证：
但是：
P0 / P1不得使用简化模板。
10. 当前问题总览
由AI持续更新。
| ID | 标题 | 等级 | 类型 | 状态 | 是否阻断上线 |
|---|---|---|---|---|---|
| 待录入 |
11. 当前P0问题
当前数量：【待统计】
如果P0 > 0：
项目状态必须：
🔴 禁止上线
12. 当前P1问题
当前数量：【待统计】
P1原则上必须在正式上线前解决。
13. 当前P2问题
当前数量：【待统计】
14. 当前P3问题
当前数量：【待统计】
15. 上线阻断问题
所有：
P0
以及标记：
Blocking Release = Yes
的问题进入此处。
| ID | 问题 | 等级 | 当前状态 | 原因 |
|---|---|---|---|---|
| 待统计 |
16. Bug发现流程
标准流程：
发现异常↓确认是否可复现↓建立Bug编号↓分级↓记录证据↓定位根因↓制定最小修复方案↓修复↓验证↓回归↓关闭
17. 禁止发现问题立即静默修改
如果AI在开发过程中发现重要问题：
不要：
直接偷偷修掉。
然后最终只说：
“顺便优化了一下。”
应该：
建立Bug记录。
尤其：
P0P1安全问题数据库问题权限问题架构问题
必须留下记录。
18. P3小问题例外
如果只是：
拼写错误明显小CSS错误局部注释错误
且本次任务本来就在修改相关模块：
可以直接修。
但任务报告中仍应说明。
19. 复现优先
修Bug前优先做到：
先证明它真的存在。
不要只看代码：
“感觉这里可能有问题。”
直接修改。
如果只能通过静态分析判断：
标记：
【静态发现，尚未运行复现】
20. 根因与现象必须分开
例如：
现象：
用户刷新后退出登录。
根因：
认证状态只存在内存，没有恢复机制。
不能只记录：
登录有Bug。
21. 一个Bug尽量只记录一个核心问题
错误：
BUG-0031登录、字体、数据库、动画都有问题。
正确：
BUG-0031 登录状态刷新后丢失BUG-0032 字体重复请求BUG-0033 数据库连接未配置超时BUG-0034 首页动画导致按钮不可点击
方便：
修复
验证
追踪
回归。
22. 同一根因多个症状
如果：
一个根因产生多个症状：
可以使用一个主Bug。
并记录：
影响页面：影响功能：
不要为了增加数量机械拆Bug。
23. Bug去重
创建新Bug前：
先搜索：
BUG_TRACKER.md
确认是否已经存在。
如果是同一个问题：
不要建立：
BUG-0121
而应：
更新原Bug。
24. 重复报告
如果同一个问题由不同方式发现：
记录：
再次发现日期：发现方式：新证据：
25. Bug复发
如果已经：
VERIFIED
的问题重新出现：
状态改为：
REOPENED
保留原修复记录。
不要覆盖历史。
增加：
复发日期：复发版本：复发场景：为什么原修复失效：
26. 修复完成 ≠ Bug关闭
代码改完：
状态只能变：
FIXED
只有实际验证后：
才能：
VERIFIED
这是强制规则。
27. 验证必须针对原复现路径
例如原Bug：
管理员接口普通用户可访问
修完以后：
不能只测试：
管理员自己能访问。
必须实际测试：
普通用户再次调用该接口。
28. 关联回归
Bug修复后需要检查：
与它有依赖关系的功能。
例如修：
API Client
必须回归：
登录用户数据管理员主要API
29. 公共模块Bug
如果问题涉及：
API ClientAuthRouterDatabaseConfigTheme公共组件权限中间件
默认影响范围较大。
必须扩大测试。
30. UI Bug记录
至少记录：
页面设备浏览器宽度组件状态
例如：
375pxChrome MobileModal打开状态
31. API Bug记录
至少记录：
EndpointMethodRequestHTTP StatusResponseAuth
不得记录真实敏感Token。
32. 数据库Bug记录
必须说明：
数据库环境涉及表涉及字段是否影响已有数据是否需要迁移是否已备份
生产数据库问题：
默认高风险。
33. 权限Bug
权限问题必须至少记录：
攻击/操作角色目标角色接口或资源预期权限实际权限
例如：
普通用户↓访问管理员用户列表↓返回200
属于严重权限问题。
34. 管理员Bug
涉及管理员：
默认至少评估为：
P1
除非可以明确证明影响很低。
特别包括：
管理员认证管理员接口管理员Session管理员密码管理员操作日志
35. 安全漏洞
安全漏洞必须记录：
漏洞类型攻击入口受影响范围前置条件影响修复方式复测结果
例如：
XSSIDORSQL InjectionSSRFPath TraversalCommand Injection
36. Secret泄露
如果发现Secret：
禁止把Secret本身写入本文件。
只记录：
Secret类型：暴露文件：暴露位置：是否进入Git：是否需要轮换：
如果真实有效Secret已经暴露：
修复通常不只是：
删掉代码。
还必须：
轮换Secret↓撤销旧Secret↓检查历史暴露
37. Git历史泄露
如果Secret曾提交到Git：
即使当前文件已经删除：
也不能直接标记修复。
必须评估：
是否公开仓库是否被推送Secret是否仍有效是否已经轮换
38. 硬编码问题
可使用：
类型：
HARDCODE
记录：
内容类型：文件：是否环境相关：是否会影响部署：建议配置入口：
39. 配置冲突
如果同一个配置存在多个来源：
类型：
CONFIG
记录：
配置名称：来源A：来源B：当前实际生效：风险：
40. 前后端接口不一致
例如：
Frontend:POST /api/loginBackend:POST /api/auth/login
记录：
前端路径：后端路径：调用结果：修复方向：
41. 端口冲突
记录：
服务A：服务B：端口：环境：结果：
42. Build问题
至少记录：
Build命令：环境：错误阶段：错误信息：是否Dev正常：是否Prod失败：
43. 部署问题
记录：
环境：域名：服务：发生阶段：本地是否正常：生产是否异常：
部署问题不能仅写：
服务器跑不起来。
44. 性能问题
记录：
页面/接口：环境：数据规模：现象：测量结果：预期：实际：
例如：
首页首屏加载 11.2s
比：
首页有点慢
更有价值。
45. 内存泄漏
如果怀疑：
必须记录：
触发操作持续时间内存变化是否可复现
46. 重复请求
记录：
操作一次实际发出请求数量是否导致重复数据是否产生费用
AI接口重复调用：
可能属于高风险费用问题。
47. 第三方服务Bug
必须区分：
项目自身Bug第三方服务故障第三方API变更第三方网络异常
如果不是项目Bug：
可以标记：
EXTERNAL
作为标签。
48. 文档Bug
例如：
README写：
npm run start
实际上启动不了。
这也是Bug。
类型：
DOCUMENTATION
49. 文档与代码不一致
记录：
文档：代码：哪一个是当前真实状态：影响：
50. Bug标签
除类型外，可增加标签：
REGRESSIONSECURITYPRODUCTIONMOBILEDESKTOPADMINUSERDATAAIBLOCKINGEXTERNALINTERMITTENTLEGACY
51. 回归Bug
如果：
新版本把之前正常功能弄坏。
标签：
REGRESSION
必须记录：
最后正常版本：首次异常版本：
如可确认。
52. 偶发问题
标签：
INTERMITTENT
不要因为：
“这次没复现”
直接关闭。
需要记录：
出现频率日志环境监控情况
53. 无法复现
状态仍可以：
INVESTIGATING
记录：
用户看到：AI测试结果：当前是否可复现：还缺什么证据：
54. INVALID使用规则
只有确认：
不是Bug
才能标记：
INVALID
不能因为：
“修不好”
标记INVALID。
55. WONTFIX使用规则
必须写清：
为什么不修：影响：风险：谁做的决定：未来是否可能处理：
P0原则上不得WONTFIX。
56. Bug关闭条件
满足以下条件：
□ 根因已确认或问题已经明确消除□ 修复已完成□ 原复现路径验证通过□ 相关回归通过□ 无新增严重错误□ 文档已同步（如需要）
才能：
VERIFIED
57. Bug修复原则
默认：
最小修复
不因为修一个Bug：
顺便：
重写架构更换框架升级所有依赖修改UI移动大量目录
58. 根因修复优先
例如：
5个页面API地址错误。
如果根因是：
API Client配置错误。
优先修：
统一配置。
而不是：
5个页面分别手改。
59. 临时补丁
如果只能做临时修复：
必须标记：
【临时补丁】
并说明：
为什么无法完成根治：未来需要做什么：
60. 技术债与Bug区分
技术债：
当前功能可能正常。
但未来风险较大。
例如：
重复代码很多文件过大耦合较高
可以进入Bug Tracker。
类型：
ARCHITECTURE
严重度根据风险判断。
61. “建议优化”不一定是Bug
例如：
换更现代的框架
如果当前系统完全正常：
不应该强行登记为Bug。
可以记录到未来规划。
62. AI审计发现问题时
如果AI执行：
项目全量审计。
发现所有实际问题后：
必须首先创建台账。
不要先修改。
流程：
审计↓BUG_TRACKER↓排序↓修复
63. AI不得降低Bug等级讨好用户
严重度必须基于：
真实影响。
不能因为：
“项目负责人可能担心”
就把P1改成P3。
64. AI不得夸大Bug等级
同样：
不要为了显得专业：
把所有问题都标P0。
必须根据实际影响。
65. 严重等级判断顺序
评估：
安全数据权限核心功能部署影响用户数量复现概率恢复难度
综合判断。
66. P0发现后的行为
如果发现P0：
应：
立即记录↓停止相关上线判断↓明确告知↓优先处理
如果继续其他非危险检查：
可以继续。
但不能最后说：
项目可上线
67. P1处理原则
P1原则上进入：
上线前必须修复
68. Bug与PROJECT_STATUS同步
如果发现：
P0 / P1。
应更新：
PROJECT_STATUS.md
中的风险状态。
修复并验证后：
同步更新。
69. Bug与CHANGELOG同步
重要Bug修复进入：
CHANGELOG.md
尤其：
P0P1安全数据核心功能
70. Bug与CONFIGURATION同步
如果Bug根因是：
配置入口混乱。
修复以后配置位置发生变化：
必须更新：
CONFIGURATION.md
71. Bug与ARCHITECTURE同步
如果修复导致：
架构关系发生变化：
必须更新：
ARCHITECTURE.md
普通Bug修复：
不需要修改架构文档。
72. Bug与DEPLOYMENT同步
如果问题涉及：
部署步骤环境变量反向代理端口服务器备份恢复
修复后可能需要同步：
DEPLOYMENT.md
73. 当前已知历史问题
以下历史问题来自项目过往开发记录。
这些项目需要由当前代码重新确认状态。
BUG-HISTORY-001
标题：普通CSS中出现非法组合类语法
历史现象
曾出现：
.sm-display-hero { .sm-display; font-size: 72px;}
普通CSS中：
.sm-display;
不是合法声明。
历史影响
浏览器可能忽略非法声明。
导致：
字体样式没有按预期继承。
当前状态
❓ 待扫描确认是否已经完全修复
类型
FRONTEND / UI
历史严重度
P2
74. 历史问题转正式Bug规则
如果扫描发现：
BUG-HISTORY-001
仍然存在：
不要继续使用：
BUG-HISTORY-001
而是创建正式编号：
BUG-0001
并注明：
历史关联：BUG-HISTORY-001
75. Bug统计区
AI更新本文件时维护：
总问题数：OPEN：INVESTIGATING：FIXING：FIXED：VERIFIED：MONITORING：REOPENED：WONTFIX：INVALID：
76. 严重度统计
P0：P1：P2：P3：
77. 类型统计
可统计：
FrontendBackendAPISecurityDatabaseUIBuildDeployment其他
目的：
判断项目哪里最容易出问题。
78. Bug趋势
以后版本较多时：
可以记录：
v0.5 → 发现18 / 修复14v0.6 → 发现9 / 修复10v0.7 → 发现4 / 修复5
不是为了KPI。
而是判断：
项目是否越来越稳定。
79. Bug老化
长期OPEN的问题：
应该关注。
例如：
OPEN > 30天
不一定自动升级。
但需要重新评估：
为什么没处理是否仍存在是否还重要
80. 安全漏洞禁止无限期挂起
尤其：
P0P1 Security
不能长期：
OPEN
后继续上线。
81. 测试失败自动进入Bug
如果正式测试：
失败
且不是测试本身问题：
应建立Bug。
82. Build失败自动进入Bug
Production Build失败：
至少：
P1
如果完全阻断项目交付。
83. 自动扫描发现Secret
直接建立安全问题。
84. 自动扫描发现依赖漏洞
根据漏洞严重程度：
建立问题。
不是所有依赖Warning都要登记。
要判断：
是否真实影响当前项目。
85. Console Error
稳定复现的：
Console Error
应进入Bug。
Warning：
根据影响决定。
86. 404资源
如果生产页面正常访问时：
固定出现404资源：
进入Bug。
87. 用户反馈
用户反馈问题必须：
先复现。
如果确认：
进入台账。
如果无法复现：
记录为：
INVESTIGATING
88. Bug优先级不只看技术严重度
两个P2中：
一个影响所有用户核心页面。
一个影响罕见设置页。
处理顺序可以不同。
因此可以额外设置：
修复优先级：HIGH / MEDIUM / LOW
89. 推荐修复排序
默认：
P0↓P1 Security / Data / Permission↓P1 Core Function / Build↓P2 Core User Experience↓P2 Architecture / Performance↓P3
90. 当前开发前检查
AI开始任务前：
如果任务涉及已有模块：
先搜索：
BUG_TRACKER.md
查看该模块是否存在：
OPEN
FIXING
REOPENED
问题。
避免：
在已知故障模块上继续堆功能。
91. 已知Bug不能被新功能掩盖
例如：
登录系统已有P1。
用户要求：
增加头像。
AI不能完全无视登录故障。
可以继续开发：
但必须明确：
已有P1仍未解决。
92. 修复Bug不得改业务预期
Bug：
实际行为
≠
预期行为。
修复目标：
恢复预期。
不是：
为了方便直接改变预期。
如果需要改变产品需求：
先走需求变更。
93. Bug报告必须让非程序员能看懂
每个重要Bug除了技术描述：
最好增加：
简单解释：
例如：
技术：
存在IDOR。
简单解释：
普通用户只要修改URL中的用户ID，就可能看到别人的数据。
94. 风险描述必须具体
不要只写：
存在安全风险。
应该写：
普通用户可能绕过前端限制直接调用管理员接口。
95. 修复建议不能只写“优化代码”
必须说：
修什么。
在哪里修。
为什么。
如何验证。
96. 无法确认根因
标记：
根因：未确认
不得编造根因。
97. 多个可能根因
可记录：
假设A：证据：假设B：证据：
调查后再确定。
98. 生产环境Bug
增加标签：
PRODUCTION
记录：
首次发生时间影响时长影响用户是否数据受损是否恢复
99. 事故级问题
如果未来出现：
生产服务中断严重数据泄露数据库损坏大面积登录失败
除了Bug记录：
建议建立：
INCIDENT-XXXX
事故报告。
Bug Tracker只保留：
问题入口和关联。
100. Bug解决后的经验
P0 / P1问题修复后建议增加：
为什么测试以前没发现：如何防止再次发生：
如果可以自动化：
应增加测试或扫描。
101. Bug转自动测试
重要Bug修复后：
尽量创建：
Regression Test。
目标：
人工发现一次↓以后机器自动防复发
102. 防止Bug复发的四种方式
修复后考虑：
代码修复+自动测试+规则约束+配置限制
不是只改一行代码。
103. Bug关闭后不要删除
Bug记录属于项目历史。
不要因为已经修好：
从文件中删除。
否则：
未来复发时没有历史。
104. 大量已关闭Bug的管理
当文件过长时：
可以拆分：
BUG_TRACKER.md
只保留：
当前OPEN问题。
历史移入：
/docs/bugs/BUG_ARCHIVE_2026.md
但原编号保持不变。
105. 当前推荐结构
BUG_TRACKER.md├── 当前摘要├── P0 / P1阻断问题├── OPEN问题├── INVESTIGATING├── FIXING├── FIXED待验证├── MONITORING└── 最近VERIFIED
老问题定期归档。
106. OPEN问题区域
当前OPEN
【待扫描后填写】
107. INVESTIGATING区域
当前调查中
【无 / 待填写】
108. FIXING区域
当前修复中
【无 / 待填写】
109. FIXED待验证区域
这里特别重要。
用于防止AI说：
修好了。
然后没有测试。
【无 / 待填写】
110. MONITORING区域
【无 / 待填写】
111. 最近已验证
保留最近重要修复。
【待填写】
112. AI首次建立真实台账流程
读取当前真实项目后：
STEP 1
读取：
AI_START_HERE.mdPROJECT_STATUS.mdARCHITECTURE.mdCONFIGURATION.md
STEP 2
扫描当前代码和运行状态。
STEP 3
发现问题。
STEP 4
去重。
STEP 5
为真实问题分配：
BUG-0001BUG-0002…
STEP 6
按照P0-P3分级。
STEP 7
记录证据。
STEP 8
本轮如果只是审计：
禁止直接修复。
STEP 9
更新：
PROJECT_STATUS.md
的重要风险。
113. AI不得把“待验证”变成Bug
例如：
管理员系统：待验证
不等于：
管理员一定有Bug。
只有：
发现具体异常或明确风险证据后：
才建立Bug。
114. 架构风险也需要证据
例如：
不能仅因为文件有800行：
就自动判定：
P1。
需要判断：
是否真的造成：
耦合
维护困难
错误
影响。
115. AI不得制造虚假Bug数量
目标不是：
找到100个问题。
目标是：
准确找到真实问题。
116. 审计发现“未验证”
如果只是无法测试：
记录到：
PROJECT_STATUS.md
或审计报告。
不要强行创建Bug。
除非：
“无法验证本身就是项目缺陷。”
例如：
项目完全没有部署说明。
那可以作为：
DOCUMENTATION / DEPLOYMENT
问题。
117. Bug记录证据等级
可以使用：
E1
猜测 / 可能风险。
不应正式判定Bug。
E2
静态代码证据。
E3
运行复现。
E4
生产环境真实发生。
重要Bug尽量达到：
E2 + E3
118. 证据级别字段
可增加：
证据等级：E3
119. Bug可信度
如必要：
高中低
例如静态安全扫描可能：
有误报。
120. 安全扫描误报
不得因为扫描工具报告：
直接判定真实漏洞。
需要人工/AI分析：
漏洞代码是否真正可达。
是否可利用。
121. 依赖漏洞误报
如果漏洞存在于：
未使用功能。
或非运行环境。
需要说明实际风险。
122. BUG Tracker不是任务清单
例如：
做一个新首页
不是Bug。
应该进入：
项目任务/需求系统。
123. BUG Tracker不是愿望清单
例如：
以后加一个3D人物
不是Bug。
124. BUG Tracker不是纯优化池
例如：
未来可以把动画做得更高级
不应该记录为Bug。
125. 什么时候必须创建Bug
符合至少一项：
实际行为违背需求功能无法使用存在安全问题存在数据风险存在部署阻断已知代码缺陷明显配置错误产生用户可见异常会造成可靠性问题
126. 当前重点需要寻找的问题
下一轮真实项目审计优先查：
登录管理员权限API一致性硬编码字体配置依赖Build部署Secret限流日志异常用户防护
127. Bug修复任务启动模板
当AI开始修复：
本次修复目标：BUG-XXXX问题：严重度：当前状态：复现方式：预计修改文件：影响范围：验证方法：
先说明。
再修改。
128. Bug修复结束模板
BUG-XXXX修改完成：修改文件：根因：修复方式：原问题验证：关联回归：Build：未验证：最终状态：
129. 一个Bug一次尽量修完
不要：
今天改一半。
明天不知道做到哪。
如果必须中断：
状态保持：
FIXING
并记录：
已完成：还剩：当前风险：
130. 上下文丢失后的恢复
新的AI接手：
只需读取：
AI_START_HERE.mdPROJECT_STATUS.mdBUG_TRACKER.md
即可知道：
当前有哪些问题。
如果处理某个问题：
再读取对应：
架构
配置
规则。
131. Bug状态禁止由聊天记忆维护
错误：
我记得之前已经修好了。
正确：
看：
BUG_TRACKER.md
是否：
VERIFIED
132. 项目负责人查看Bug最重要区域
文件顶部应长期维护：
P0数量P1数量上线阻断问题正在修复问题已修待验证问题
不需要翻完整文件。
133. 项目健康信号
理想趋势：
P0 = 0P1 = 0FIXED待验证 = 0REOPENED越来越少REGRESSION越来越少
不是追求：
Bug总数永远是0。
真正项目有Bug很正常。
重要的是：
每个问题都知道在哪里、是什么状态。
134. 当前文件初始化状态
目前：
正式Bug编号：尚未开始当前OPEN数量：待真实扫描P0数量：待真实扫描P1数量：待真实扫描P2数量：待真实扫描P3数量：待真实扫描
历史已知问题：
CSS非法语法问题
等待在当前版本重新确认。
135. 下一步
创建本文件以后：
下一份建议建立：
CHANGELOG.md
负责回答：
从v0.1到现在，到底每个版本发生了什么变化？
END
本文件是：
项目Bug、风险和已知问题的主要事实源。
任何问题只有经过实际验证后：
才能标记：
VERIFIED
任何已经修复但没有测试的问题：
只能标记：
FIXED
任何无法确认的问题：
不得假装正常。
任何重要Bug：
不得只存在于聊天记录中。