藤蔓推理

你要解决的问题

很多编码 Agent 接到需求就直接动手：结论来自模型直觉而非项目文档，跑不通再回头猜原因。结果是风格漂移、离线构建里混入在线依赖、架构决策查不到出处。藤蔓推理把「先分析、后动手」变成硬约束——实现之前先做一轮系统性、可溯源的知识驱动分析。

它如何工作

核心是深度参数 N（0–10，默认 5），同时控制确认问题数量与分析深度，但有四项能力不随 N 缩减：

• 统一反思：分析后必须回看全貌
• 知识分析：结论必须追溯到项目文档与工程参考库
• 规范溯源：每条建议都要给出出处
• 只读约束：分析阶段不修改任何文件

流程分几步：

1. 知识导航：从 knowledge/Index/ 进入，按优先级选文档，不凭记忆作答
2. 九维分析：覆盖架构、业务逻辑、类型安全、性能、安全、简洁性、复用、健壮性、可维护性九个维度，禁止跳维度
3. 离线可行性：N ≥ 1 时强制评估离线分层（Tier 1–3），确认 build / run / test 全部通过
4. 问题报告：按 P0/P1/P2 分级输出问题与建议，格式固定为问题、严重度、受影响模块、知识引用、风险、建议、优先级

N 分三档：1–3 轻量档每维度一行状态、只报 P0；4–7 标准档给三句话摘要加关键引用；8–10 全面档要求逐维度完整报告与多轮搜索交叉验证。

适用边界

• 它是分析模式而非执行器：全程只读，不会替你改代码
• 结论质量依赖参考库覆盖度；仅在参考库未覆盖且有时效性顾虑时才触发联网搜索
• 项目文档优先级高于参考库，未文档化的个人经验不能冒充既定标准
• N = 0 快速模式跳过九维分析与大部分联网检查，只适合中等复杂度任务