定位代码逻辑

根据用户给出的需求描述或问题与指定代码入口，沿组件引用、方法调用、接口与路由关联向前端子模块或后台分层方法收敛，直至定位实现该需求的关键代码位置，并输出带路径与行号的核心代码片段。当用户说定位逻辑、定位功能、找实现、代码在哪、从入口追到业务、或给出「需求/问题 + 入口文件」并要求缩小到关键代码时使用。与「梳理功能点」不同：本技能以问题驱动、早停于关键实现，不默认输出完整模块知识库文档。

需求驱动的代码定位

与「梳理功能点」的边界

维度	本技能（定位逻辑）	梳理功能点
输入	需求/问题描述 + 一个入口	入口为主，偏全量结构
目标	收敛到关键实现即止	结构化知识库、递归全景
输出	结论 + 少量核心片段 + 短调用链	多章节文档模板

若用户仅要「从入口完整梳文档」，改用梳理功能点；若用户要给具体问题找落点，用本技能。

触发后先确认的信息

若用户未显式给出，用一句话向用户补齐（或从附件/打开文件合理推断）：

1. 需求或问题：要验证的行为、报错现象、接口名/按钮文案/字段名等可检索线索。
2. 代码入口：单文件路径（或符号名 + 大致路径），作为追踪起点。

追踪策略（按栈自适应）

1. 从入口读上下文：import/导出、模板事件、路由名、$http/axios/fetch 的 URL、RPC/Action 名、常量与枚举、注释中的业务词。
2. 语义匹配优先：用需求中的名词、动词、接口 path、表名、状态码、字典值在当前文件与一跳依赖内 grep/语义搜索，缩小下一跳，避免无目的全仓库展开。
3. 前端：入口 → 子组件 / composable / API 模块 / store action → 与 URL 或 mock 路径对应的调用点。
4. 后端：入口（多为 Controller）→ Service → DAO/Mapper/XML → 关键分支；注意注解路由、Feign、消息监听等多入口。
5. 跨端：发现前端请求 path 或 operationId 后，在后端按 path、@RequestMapping、网关前缀变体搜索；反向则从 Controller 找前端封装函数名。
6. 早停：一旦某处代码直接实现需求中的分支、校验、持久化或 UI 展示，即视为关键位置；若存在多层薄封装，保留「最接近业务判断」的一层为主锚点，上一层可附一行引用。
7. 工作空间外：关联代码不在当前 workspace 时，标明 [⚠️ 不在当前工作空间] 并给出已知的符号名或接口约定，停止臆造路径。

工具使用

• 优先：Grep（精确符号/path）、SemanticSearch（语义）、Read（局部验证）。
• 避免：无关键词时对整个 node_modules 或生成物目录大范围搜索。

输出格式（默认在对话中输出）

按顺序给出，保持简洁：

markdown

## 定位结论
- **需求摘要**：[一句话]
- **关键实现**：[文件路径] — `函数名/类名` 或「模板/配置段」
- **为何是此处**：[1～3 条，对应需求中的哪一点]

## 调用链（简写）
`入口文件` → `A` → `B` → **关键** `C`

## 核心代码片段

代码块必须使用 Cursor 可导航引用格式（单独一行起始）：

startline

// 仅保留与需求直接相关的连续行；无关处用 // ... 略

可附 次要位置（校验、枚举、SQL 片段）各一段，每段不超过约 40 行有效代码。

无法收敛时的输出

• 列出已追踪路径与已排除原因。
• 明确缺少的信息（例如未知接口 path、动态路由参数）。
• 给出建议的下一入口或用户可提供的 grep 关键词。

质量自检

• 片段来自真实文件，行号与内容一致，禁止编造。
• 至少一个「关键」位置与需求表述可逐条对应。
• 调用链无环、无跳步神话（未读文件不写进链）。