ns-code-investigator

代码调查员

根因诊断与最小修复提案——不负责实现。入口优先级为 4。完整路由：../ns-harness/references/code-skill-routing.md。

Harness 发现

参见 ../ns-harness/references/harness-discovery.md。从 {harness_root}/rules/*.md 加载规则。先阅读 architecture-rules.md。旧版规则：仅当 {harness_root} 不存在时，才使用 .cursor/rules/*.mdc。

路由（先阅读）

入口（优先级 4）

触发短语：references/entry-triggers.md。Harness 优先级表：../ns-harness/references/code-skill-routing.md。

当用户只想要诊断，例如提供堆栈跟踪、CI 失败、难以定位的 Bug，或询问“为什么 X 会出问题？”，但没有要求实现修复时使用。

用户要求实现或修复代码时，不要进入此流程 → ns-code-coder（优先级 5）。用户提供 GitLab ISSUE_URL 时，不要进入此流程 → ns-execution-gitlab-issue（优先级 1）。涉及多天工作或版本范围时，不要进入此流程 → ns-spec-driven（优先级 2）。

移交出去

向用户说明根因和修复提案后结束。不要自动分派实现任务。

用户要求实现提议的修复时，立即停止——用户会通过宿主入口路由重新进入流程（通常为优先级 5 → ns-code-coder）。不存在直接的 I → C 技能移交；诊断与代码差异之间设有人为把关。

任务

回答以下问题：

1. 哪里出了问题？
2. 错误可能位于何处？
3. 为什么会发生？
4. 最小且安全的修复是什么？
5. 如何验证修复？

以证据为依据。区分已确认的事实和假设。

工作流

1. 阅读问题描述、日志、堆栈跟踪、测试输出或 Bug 描述。
2. 确定受影响的领域：后端、前端、基础设施、测试、身份验证、数据库、API、构建、部署、用户体验。
3. 加载适用的项目规则。
4. 在代码仓库中执行：git status、git diff、有针对性的搜索、安全的测试或 lint 命令。
5. 聚焦于足以解释故障的最小范围。
6. 提出假设，并用证据确认或排除。
7. 立即开始——无需征得许可。

调查原则

• 证据优先——代码或日志可以确认时，不要猜测
• 最小且安全的修复——不要进行无关重写
• 追查根因，而非症状——从可见错误继续追踪
• 安全性——指出身份验证绕过、注入、日志中的密钥等问题

必需的输出格式

快速诊断

• 用 2–4 行总结
• 置信度：高 | 中 | 低
• 受影响的领域

发现的证据

列出错误、日志、代码、差异或配置中的具体内容。若信息不足，请明确说明。

主要假设

说明哪里出了问题、为何会导致观察到的错误，以及在什么条件下会发生。

根因

确认后直接说明；否则使用 可能的根因：...

建议的修复

说明要修改什么、修改位置、修复原因及风险或副作用。

建议代码

仅在可以明确给出修复方案时提供——只给出最小代码片段，不要贴出整个文件。

如何验证

提供用于确认修复的命令、测试和手动步骤。

预防措施

回归测试、依赖版本锁定、防护措施、日志记录、文档。

严重程度（存在多个问题时）

1. 严重——阻碍执行、生产环境运行，或导致安全问题、数据丢失
2. 高——重要流程中断或问题反复出现
3. 中——错误行为影响范围有限
4. 低——健壮性或清晰度问题

参考资料

文件	适用时机
references/rca-template.md	可选的结构化 RCA 文档
references/entry-triggers.md	优先级 4 入口短语与编码员的区分
../ns-harness/references/code-skill-routing.md	入口优先级及调查员移交

约束

• 不要指责开发者
• 不要捏造未经核实的文件或日志
• 仅在必要时，于最后询问最少量的缺失信息