用途
Drift Analysis 用于分析项目状态、检测计划漂移（plan drift），并创建按优先级排序的重建计划（reconstruction plans）。它适合在用户询问计划漂移、现实检查（reality check）、文档与代码对比、项目状态分析、路线图对齐、实现差距等场景下使用。
主要能力
漂移检测类型
- 计划漂移：文档化计划与实际实现出现偏差，例如 PLAN.md 条目长期未勾选、路线图里程碑延迟未更新、冲刺/阶段目标未反映在代码变更中。
- 文档漂移：文档落后于实现，例如新功能没有对应文档、README 描述了不存在的功能、API 文档与实际端点不符。
- 问题漂移：问题跟踪与现实脱节，例如不再适用的陈旧 issue、已完成工作但 issue 未关闭、高优先级事项被忽视。
- 范围漂移：项目范围超出原始计划，例如文档化功能多于可交付范围、持续添加而无完成、积压列表不断增长且未修剪。
检测信号
- 高置信度漂移指标：里程碑逾期 30 天以上且仍有未关闭 issue；PLAN.md 在 90 天后完成度低于 30%；5 个以上高优先级 issue 超过 60 天无活动；README 中的功能在代码库中找不到。
- 中置信度指标：文档文件 180 天以上未变更；草稿 PR 开放超过 30 天；issue 主题与代码活动不匹配；文档化功能与实现功能之间存在较大差距。
- 低置信度指标：代码库中大量 TODO；依赖陈旧；旧 git 分支未合并。
优先级框架
提供 calculatePriority 函数，综合严重程度基础分、类别乘数（安全 2.0、缺陷 1.5、基础设施 1.3、功能 1.0、文档 0.8）、近期性加成与陈旧惩罚来计算优先级。时间分桶包括：即时（severity=critical 或 priority >= 15，最多 5 项）、短期（severity=high 或 priority >= 10，最多 10 项）、中期（priority >= 5，最多 15 项）、积压（其余，最多 20 项）。默认优先级权重为 security: 10、bugs: 8、features: 5、documentation: 3、tech-debt: 4。
交叉引用模式
提供 featureMatch 模糊匹配函数，通过规范化、包含判断与 Levenshtein 距离（小于 3）匹配文档功能与代码功能。常见不匹配示例包括：文档中的 "user authentication" 对应代码中的 auth/、login/、session/；"API endpoints" 对应 routes/、api/、handlers/；"database models" 对应 models/、entities/、schemas/；"caching layer" 对应 cache/、redis/、memcache/；"logging system" 对应 logger/、logs/、telemetry/。
输出模板
提供漂移报告、差距报告与重建计划模板。重建计划按即时行动（本周）、短期（本月）、中期（本季度）与积压分段输出。
使用方式
架构上，/drift-detect 调用 collectors.js（纯 JavaScript）进行数据收集，包括 scanGitHubState()、analyzeDocumentation() 与 scanCodebase()，然后由 plan-synthesizer（Opus）在完整上下文下进行深度语义分析。数据收集使用纯 JavaScript（无 LLM 开销），语义分析使用单次 Opus 调用。
数据收集包括：
- GitHub 数据：按标签分类的开放 issue、带草稿状态的开放 PR、带截止日期的里程碑、陈旧项（超过 90 天无活动）、标题主题分析。
- 文档数据：解析 README、PLAN.md、CLAUDE.md、CHANGELOG.md，统计复选框完成数、章节分析与功能列表。
- 代码数据：目录结构、框架检测、测试框架存在性、健康指标（CI、linting、测试）。
语义分析（Opus）接收所有收集数据并执行交叉引用、漂移识别、差距分析、优先级排序与报告生成。
示例输入输出展示了从 collectors.js 收集的数据结构，以及 plan-synthesizer 输出的现实检查报告格式，包括执行摘要、漂移分析与优先级计划。
适用场景
适用于需要评估项目计划与实际实现之间偏差、检查文档与代码一致性、分析路线图对齐情况、识别实现差距以及生成优先级重建计划的项目管理或开发场景。
限制
资料中未提供关于收费、价格、平台支持范围、具体安装命令或使用效果保证的信息。除上述内容外，其他功能细节暂未提供。
最佳实践
分析漂移时：比较时间戳而非仅内容；寻找模式而非单个条目；考虑上下文（活跃开发自然存在漂移，成熟项目应最小化漂移）；按影响加权（面向用户的漂移比内部更重要，公共 API 漂移比实现细节更重要）。创建计划时：可操作而非穷尽（前 5 个即时项而非前 50 个）；分组相关项；包含成功标准；平衡类别。