需求驱动的代码定位
与「梳理功能点」的边界
| 维度 | 本技能（定位逻辑） | 梳理功能点 |
|---|---|---|
| 输入 | 需求/问题描述 + 一个入口 | 入口为主，偏全量结构 |
| 目标 | 收敛到关键实现即止 | 结构化知识库、递归全景 |
| 输出 | 结论 + 少量核心片段 + 短调用链 | 多章节文档模板 |
若用户仅要「从入口完整梳文档」，改用梳理功能点；若用户要给具体问题找落点，用本技能。
触发后先确认的信息
若用户未显式给出，用一句话向用户补齐（或从附件/打开文件合理推断）：
- 需求或问题：要验证的行为、报错现象、接口名/按钮文案/字段名等可检索线索。
- 代码入口：单文件路径（或符号名 + 大致路径），作为追踪起点。
追踪策略（按栈自适应）
- 从入口读上下文：import/导出、模板事件、路由名、
$http/axios/fetch 的 URL、RPC/Action 名、常量与枚举、注释中的业务词。 - 语义匹配优先：用需求中的名词、动词、接口 path、表名、状态码、字典值在当前文件与一跳依赖内 grep/语义搜索，缩小下一跳，避免无目的全仓库展开。
- 前端：入口 → 子组件 / composable / API 模块 / store action → 与 URL 或 mock 路径对应的调用点。
- 后端：入口（多为 Controller）→ Service → DAO/Mapper/XML → 关键分支；注意注解路由、Feign、消息监听等多入口。
- 跨端：发现前端请求 path 或 operationId 后，在后端按 path、@RequestMapping、网关前缀变体搜索；反向则从 Controller 找前端封装函数名。
- 早停：一旦某处代码直接实现需求中的分支、校验、持久化或 UI 展示，即视为关键位置；若存在多层薄封装，保留「最接近业务判断」的一层为主锚点，上一层可附一行引用。
- 工作空间外：关联代码不在当前 workspace 时，标明
[⚠️ 不在当前工作空间]并给出已知的符号名或接口约定，停止臆造路径。
工具使用
- 优先：
Grep（精确符号/path）、SemanticSearch（语义）、Read（局部验证）。 - 避免：无关键词时对整个
node_modules或生成物目录大范围搜索。
输出格式（默认在对话中输出）
按顺序给出，保持简洁：
## 定位结论
- **需求摘要**：[一句话]
- **关键实现**：[文件路径] — `函数名/类名` 或「模板/配置段」
- **为何是此处**：[1～3 条，对应需求中的哪一点]
## 调用链（简写）
`入口文件` → `A` → `B` → **关键** `C`
## 核心代码片段
代码块必须使用 Cursor 可导航引用格式（单独一行起始）：
startLine:endLine:相对或绝对路径
// 仅保留与需求直接相关的连续行；无关处用 // ... 略
可附 次要位置（校验、枚举、SQL 片段）各一段，每段不超过约 40 行有效代码。
无法收敛时的输出
- 列出已追踪路径与已排除原因。
- 明确缺少的信息（例如未知接口 path、动态路由参数）。
- 给出建议的下一入口或用户可提供的 grep 关键词。
质量自检
- [ ] 片段来自真实文件，行号与内容一致，禁止编造。
- [ ] 至少一个「关键」位置与需求表述可逐条对应。
- [ ] 调用链无环、无跳步神话（未读文件不写进链）。
