code-quality

name	code-quality
description	Perform a comprehensive quality analysis of the project

现在请帮我对该项目的完整实现做一个深度的质量检测分析，从架构设计、代码实现、工程规范、类型系统、状态管理、异步流程、并发安全、错误处理、资源释放、模块边界、依赖关系、可维护性、可扩展性、性能、安全性、测试覆盖率、CI/CD、构建配置、部署策略、开发体验等多个维度进行系统性审查。

请特别重点关注 AI 生成代码（AI-generated code）与 vibe coding 场景下常见的隐性问题，包括但不限于：

• 表面“能运行”但存在深层逻辑缺陷的代码
• 大量重复实现、抽象失控、职责混乱
• 虚假的模块化（文件拆分了但逻辑高度耦合）
• 类型系统形同虚设（大量 any、类型断言、类型漂移）
• 上下文缺失导致的错误调用链
• AI 补全造成的未被真正使用的“僵尸代码”
• 实现与注释/文档不一致
• 过度设计与伪扩展性设计
• 未被验证的 optimistic implementation
• 只覆盖 happy path 的流程实现
• 错误吞噬（silent fail）与无意义 catch
• 状态竞争、异步时序问题、潜在死锁
• 内存泄漏、事件监听未释放、定时器泄漏
• 缓存不一致、状态源重复、数据同步问题
• API 边界混乱与数据结构污染
• prompt-driven development 导致的风格漂移
• 不同阶段 AI 生成代码之间的范式冲突
• 配置文件、脚本、环境变量逐渐腐化
• “看起来先进”但实际不可维护的架构
• 缺乏真实约束下的异常恢复能力
• 日志系统不可观测、调试困难
• 假测试、低价值测试、无效断言
• 未考虑生产环境压力、并发、网络波动
• 缺少 backpressure、限流、重试、熔断等机制
• 安全边界缺失（注入、权限、sandbox escape、敏感信息泄露等）
• Agent / LLM 系统中特有的问题（上下文污染、工具调用失控、记忆污染、prompt injection、无限循环、自我欺骗式 reasoning 等）

请不要只做静态表面代码审查，而是尽可能像一个资深 Staff/Principal Engineer 一样，从“系统长期演化”和“真实生产环境”角度进行深入分析。

我希望你：

1. 主动推断系统设计意图与真实运行路径
2. 分析模块之间的实际耦合关系，而不是只看目录结构
3. 找出那些“短期可用但长期一定会出问题”的设计
4. 识别代码库中 AI 味过重、缺乏统一抽象的区域
5. 判断哪些部分已经进入“重构成本快速上升区”
6. 识别潜在技术债，并按严重程度排序
7. 给出“为什么这是问题”而不仅是代码风格建议
8. 尽量提供可执行、现实、渐进式的优化路线
9. 区分“应该立即修复的问题”与“未来演进风险”
10. 对整个项目给出架构成熟度评价与可持续性判断

请尽量以“批判性审查”方式进行，而不是默认当前实现合理。 如果你发现某些设计明显是 AI 凭空补全、没有经过真实验证，请直接指出。 如果某些代码虽然复杂但实际上没有必要，也请明确说明。

请特别关注那些：

• 在 demo 阶段表现正常
• 在单人开发阶段还能维持
• 但会在多人协作、长期维护、生产环境下迅速崩坏的问题。

最后请输出：

• 高风险问题列表（按优先级排序）
• 中长期架构风险
• 技术债地图
• 可维护性评分
• 架构健康度评价
• 推荐的重构顺序
• 如果继续当前模式开发，未来 3~6 个月最可能出现的问题

不要因为“项目规模大”而保守，请尽可能深入、尖锐、真实。