在上一篇文章中，我们确立了这款“神兵利器”的宏大目标：依托 JetBrains 强大的底层生态，通过自动化劫持网页版 AI（Web AI），实现零 Token 费用、极速响应的完美编程体验。
牛皮吹完了，接下来就是最硬核的架构设计环节。
把 AI 接入 IDE 听起来很简单，但懂行的朋友都知道，这里面最致命的痛点根本不是网络连通性，而是上下文（Context）管理。如果不能把正确的代码喂给 AI，再强大的模型也只会满嘴跑火车。
🗑️ 为什么我极其嫌弃 RAG？
现在市面上很多主打“全代码库理解”的工具，底层清一色用的都是 RAG（检索增强生成）技术。也就是把你的代码切成一个个小块（Chunk），向量化存入数据库。等你提问时，再通过余弦相似度去把“最相关”的代码片段捞出来喂给 AI。
但在实际编码场景中，RAG 简直就是个“瞎子”。 写代码不是做阅读理解！代码是高度结构化、具有极强逻辑跳转和依赖关系的。RAG 经常会给你捞出来一堆包含同名变量的废话，却完美避开真正需要修改的接口定义或父类逻辑。依靠这种“玄学”检索，AI 根本无法纵观全局。
既然 RAG 这条路走不通，我们就得换一种更符合程序员思维的硬核解法。
🧠 我们的四步核心逻辑：外科手术式的代码修改
为了让 AI 做到“指哪打哪”，我们的插件将采用一套全新的两段式推理工作流。核心思想就四个字：先看骨架，再看血肉。
第一步：提取代码骨架（Skeleton）
既然把整个项目的代码全扔给 AI 会导致上下文爆炸，我们就给代码做一次“瘦身”。 依托 JetBrains 强大的 PSI（程序结构接口）语法树解析能力，我们可以轻松扫描当前工程或特定模块，剔除所有方法体内的具体实现，只保留代码骨架。 这个骨架包含了：文件路径、类名、接口定义、方法签名、成员变量以及核心注释。它极其轻量，却完美描绘了整个系统的宏观拓扑结构。
第二步：海选阶段 —— 让 AI 自己挑文件
有了轻量级的骨架，操作就简单了。我们将代码骨架 + 你的具体需求（Prompt）一起打包，发送给网页版 AI。 此时，AI 的任务不是写代码，而是做“架构师”级别的决策。它需要根据你的需求，在整个骨架中进行诊断，并明确输出：“为了实现这个需求，我需要修改哪几个具体的文件？” 这就好比告诉主刀医生病人的全身扫描图，让医生决定要在哪几个部位开刀。
第三步：精准打击 —— 投喂全量文件与“军规”
当 AI 给出了目标文件列表（例如 UserService.java 和 UserController.java），我们就进入实质性的编码阶段。
此时，插件会自动从本地抓取这些被选中文件的全量源代码。但这还不够，很多时候 AI 写的代码风格跟狗啃的一样。所以，我们还要附带上我们预设的编码协议（Coding Protocols）。
在这个协议里，你可以狠狠地约束 AI：“必须使用 Lombok”、“接口必须返回标准的 Result 包装类”、“严禁使用魔法值（Magic numbers）”。
将 选中的源文件 + 编码协议 + 原始需求 再次精准投喂给 AI。
第四步：操刀修改与差异合并
由于前面排除了无数无关代码的干扰，此时 AI 的注意力达到了空前的集中。它会在限定的文件范围内，严格遵循你的编码军规，输出高质量的修改后代码。 它不仅不会乱改其他文件，还能保持当前业务逻辑的连贯性。
⏳ 未完待续...
摒弃了扯淡的 RAG，这套**“骨架扫描 -> 目标锁定 -> 精准注入”**的逻辑，才能真正发挥出现代大模型强大的代码推演能力。
但是问题又来了： 当网页版 AI 哗啦啦地吐出了几百行修改后的代码时，我们难道要手动复制粘贴回 IDE 吗？那这插件做得还有什么意义？
如何实现代码差异（Diff）的精准解析？如何在 JetBrains 编辑器中实现一键 Apply、丝滑覆盖？
