相信大家在AICoding中都遇到过类似的问题。

      收到需求后，直接丢给AI工具，AI工具不知道改哪里。

      需求文档和项目代码之间至关重要的“业务含义”关联关系丢失了。

      AI工具读得懂文档，也看得懂代码，但它不能很快的知道这个需求涉及哪些模块，没有研发介入，有时候就会有缺失。

      AI工具不知道怎么做，原因在于上下文中信息的缺失。

      这部分信息往往在核心开发者在脑中承载着。一些关键决策以注释或者技术方案形式零星留存，更多则留在记忆和聊天记录里。

      前几天遇到一个涉及老项目的需求，懒病犯了，我试着直接把需求文档丢给AI工具，让它给我分析试试。

      结果出来之后吓得我手一哆嗦，结果有没有缺失先不说，接近10W的token看的我一阵心疼。       

     Claude Code 自带三个工具：Glob 找文件、Grep 搜内容、Read 读文件。

      听上去挺简单，但关键是**每次查询都要重新读代码**，然后用 LLM 即时理解。打个比方，就像你每次找东西都要把整本书从头翻一遍。

      好处是通用，任何语言都能用，不用预处理。坏处是大项目反复查询的话，Token 消耗惊人。

自己动手丰衣足食

      于是就有了手搓skill的想法，核心的技术和组件如下：   

设计思路                                                                                                              
  核心目标: 将 Java 代码转换为可搜索的语义知识库，实现"需求→代码"的智能定位。                                            esc to interrupt

  架构层次:
  Java源码 → AST解析 → 语义提取 → 向量嵌入 → Qdrant存储 → 搜索服务

  关键设计决策:

  1. 混合语义提取策略
    - 规则引擎: 提取注释、方法名、类名等显式语义
    - LLM 增强: 理解复杂业务逻辑的隐式含义
    - 原因: 纯规则无法处理复杂业务场景，纯LLM成本高且不稳定
  2. 多维数据模型
    - 结构数据: 类/方法/字段、继承、调用链
    - 语义数据: 业务含义、关键词、注释摘要
    - 关系数据: 调用者、被调用者、继承树
    - 原因: 单一维度无法支持复杂的查询需求
  3. 向量数据库选择
    - Qdrant: 支持元数据过滤 + 向量搜索
    - 原因: 纯向量搜索无法精确过滤（如按类型），纯数据库无语义匹配能力
  4. 工具链选择
    - tree-sitter-java: 快速 AST 解析，无需编译项目
    - sentence-transformers: 多语言语义嵌入（支持中文注释）
    - 原因: 轻量级、不依赖 Java 运行环境

      执行 `/java-code-analyzer`，然后给项目路径。

      skill分析完会输出个报告，告诉你多少类、多少方法、注释覆盖率多少，还有业务域分布，一目了然。

      数据会存入向量数据库，用于后续的查询，连续使用的token节省了近90%。

      大家感兴趣的话也可以自己试试手搓一个skill，或者评论区找我要一下源文件。

总结

      Claude Code 原生能力适合"快速探索"，就像翻书找答案。Skill 适合"深度分析"，就像提前给书做目录。

      Token 消耗的本质区别：原生是每次付，Skill 是一次付多次用。

      我的做法是这样的——新项目先用原生快速看一眼，判断会不会长期维护。要是长期接手，就跑一遍 Skill 建索引。要是就查这一次，原生完事。

      反正两种方式都备着，按场景选就行。