⁷

⁶

⁸

【简历笔记，持续更新】针对代码生成平台，2026年分享一下我的Java+MCP/Skill+OpenClaw项目，供大家学习。

文艺倾年

2026-03-21 22:43

阅读1103

文艺倾年

2026-03-21 22:43

阅读 1103

仓库地址：孩子最近在找实习，整焦虑了，求点个star，谢谢了。

MCP/Skill 服务端：https://github.com/itxaiohanglover/mcp-codestyle-server

核心模板规范：https://github.com/itxaiohanglover/codestyle

模板仓库管理：https://github.com/itxaiohanglover/codestyle-repository

项目初始化Skill： https://github.com/itxaiohanglover/project-start-skill

一、前言

做开发的同学应该都懂：AI 编程工具用得好是提效神器，用不好全是坑 —— 这也是我从零到一打造 Codestyle 系列工具的初衷。

最初我们是实验室团队也跟风用 Claude、Cursor 这类工具，但越用越发现问题：

✅ 成本坑：Claude 按调用量收费，团队大规模用下来每月成本居高不下，想降本却没替代方案；

✅ 效果坑：某次核心业务代码生成时，模型输出质量极差，不仅没提效还返工，关键是这次失败的调用链路没法沉淀，既没法优化后续使用，也没法用来微调团队模型；

✅ 效率坑：同样用 AI 写代码，有人 3 次迭代就跑通，有人试 10 次还卡壳，核心差距不是技术能力，而是有没有复用过往的成功经验 —— 但这些经验散在各人手里，没法共享。

通过调研以及深度体验了国产IDE和国外IDE后，我得出了一个结论：把 AI 编程的 “隐性经验” 变成 “显性资产”，并通过技术手段无缝融入开发流程：

沉淀资产：把 “框架最佳实践”“常见避坑指南”（比如不同业务的缓存优化策略）做成可复用的 Codestyle 模板；
智能召回：通过 RAG 检索，编码时自动匹配召回相关经验，不用再重复踩坑；
无缝集成：基于 MCP 协议 / Skill 把能力接入 IDE，告别切换工具的割裂感。

为了落地这个思路，我打磨了三个核心仓库（也是整个体系的骨架）：【其实这里看着和Skill架构特别像了，确实是，但我们这个idea是在2025年8月提出的，后面逐步演化成这样。】

codestyle：核心层，沉淀多场景可定制的代码规范 / 模板（比如不同业务的缓存优化模板），借鉴 Maven 坐标体系设计 meta.json 索引，让模板管理更规范；
mcp-codestyle-server：服务化核心，支持本地 / 远程双模式检索（Lucene 本地缓存 + Open API 远程调用），还做了二阶段召回策略（轻量预览→详细加载），兼顾速度和体验；
codestyle-repository：模板仓库化管理，实现版本管控、权限管理，让经验迭代有迹可循。

这里我贴一个架构草图：

▼
text
复制代码
┌─────────────────┐
│ IDE + MCP Skill │ ← 对接GLM/Trae（替代Claude、Cursor）
└────────┬────────┘
         │ STDIO
┌────────▼────────┐
│  MCP Skill      │ ← Local Lucene Cache（轻量检索）
└────────┬────────┘
         │ REST API
┌────────▼────────┐
│  Admin          │ ← MySQL + Workflow Engine（经验/模板管理）
└─────────────────┘

目前个人使用的效果，明显取得了很多进步，至少现在可以让AI直接拿一个Ruo-YI、LightRAG、Continew直接生成全套可商用的前后端代码，直接上线。

✅ 成本降了：用 GLM/Trae 替代 Claude，每月 AI 调用成本直接砍半； ✅ 效果稳了：失败案例沉淀成模板 / 经验，RAG 检索让 GLM/Trae 输出更精准，波动率降低 60%； ✅ 效率齐了：能力强的同学的经验变成可复用模板，新人 / 效率低的同学直接调用，不用重复试错； ✅ 聚焦核心：开发者不用再纠结 “缓存策略怎么写” 这类机械工作，而是聚焦 “选什么策略适配业务”，把精力放在核心设计上。

这里补充一个，使用NanoBunana生成的架构图，方便大家理解：

下面我分享一些相关的设计心得，也欢迎大佬们一块来优化这个Skill。

二、检索设计

定位：为 AI 代理（如 Claude、Cursor）提供代码模板的智能搜索和获取能力。

检索流程：

▼
text
复制代码
用户输入 "CRUD"
    ↓
CodestyleService.codestyleSearch()
    ↓
┌─────────────────────────────────────┐
│ 判断：remote.enabled?                │
└─────────────────────────────────────┘
    ↓ true                    ↓ false
远程检索模式              本地检索模式
    ↓                          ↓
TemplateService              LuceneIndexService
.searchFromRemote()          .fetchLocalMetaConfig()
    ↓                          ↓
CodestyleClient              Lucene 全文检索
.searchFromRemote()          (SmartChineseAnalyzer)
    ↓                          ↓
Open API 签名认证           本地 meta.json 解析
(MD5 + TreeMap 排序)         ↓
    ↓                      返回 SearchResult 列表
返回 RemoteSearchResult       ↓
    ↓                      PromptService 格式化
下载模板到本地                ↓
    ↓                      返回目录树 + 描述
返回目录树 + 描述
     └─────────────────────────────┘

模板获取：【为什么这样设计，我在8月测试demo的时候，发现Trae内置的模型并不能实现并行调用MCP Tool，后来从11月那会，突然有一天，发现它意识到Codestyle MCP Tool是可以直接调用xx次，然后进行进一步思考，可以看到Code Agent对Tool的何时调用，如何调用已经有了更好的意识。】

▼
text
复制代码
用户输入完整路径
"continew/CRUD/1.0.0/src/main/java/Controller.ftl"
    ↓
CodestyleService.getTemplateByPath()
    ↓
TemplateService.searchByPath()
    ↓
CodestyleClient.searchByPath()
    ↓
解析路径 → 定位 meta.json → 查找匹配
    ↓
读取模板文件内容
    ↓
PromptService.buildPrompt()
    ↓
返回：文件名 + 变量说明 + 模板代码

二阶段召回策略：【没想到和后来的Skill的渐进式检索理念一致。】

▼
text
复制代码
阶段一：轻量预览
├─ 查询 meta.json 索引
├─ 返回 description 列表（轻量）
└─ 用户在 IDE 中选择目标

阶段二：详细加载
├─ 异步同步缺失文件到本地
└─ 返回完整模板内容

meta.json 索引设计：【借鉴 Maven 坐标体系，集中管理元信息】

▼
text
复制代码
{
  "groupId": "RuoYI",
  "artifactId": "CRUD",
  "version": "1.0",
  "files": [{
    "filePath": "src/main/java/controller",
    "filename": "Controller.java.ftl",
    "description": "CRUD 控制器模板",
    "sha256": "722f185c...",
    "inputVariables": [
      {
        "variableName": "packageName",
        "variableType": "String",
        "variableComment": "项目根包名",
        "example": "com.air.order"
      }
    ]
  }]
}

三、Skill化

整体目录设计：

▼
text
复制代码
codestyle/
├── SKILL.md                    # Skill 定义（YAML frontmatter + 工作流）
├── scripts/
│   ├── codestyle               # CLI 包装脚本（Linux/macOS）
│   ├── codestyle.bat           # CLI 包装脚本（Windows）
│   ├── install.sh              # JAR 安装脚本（Linux/macOS）
│   ├── install.bat             # JAR 安装脚本（Windows）
│   ├── update.sh               # 更新脚本（Linux/macOS）
│   ├── update.bat              # 更新脚本（Windows）
│   ├── init-repository.sh      # 仓库初始化（Linux/macOS）
│   ├── init-repository.bat     # 仓库初始化（Windows）
│   ├── cfg.json                # 默认配置
│   ├── .gitignore              # Git 忽略规则
│   └── codestyle-server.jar    # JAR 文件（自动下载）
└── references/
    ├── config.md               # 配置文档
    └── template-syntax.md      # 模板语法文档
___________

name: codestyle
description: Code template search and generation tool. Auto-initializes on first use with minimal user interaction.

接入终端Code Agent效果【Trae CLI目前还处于alpha阶段，流畅度不太够，最近重心还在找实习（27届），还是一名学生，后期有余力，在加入到Cli建设中。】

四、团队化管理

这一块对于开发者就比较常见，Sass管理 + （ES + Milvus混合检索） + Open API签名调用，就不再赘述了。

大概就是模板的基本管理：

检索模块：

▼
text
复制代码
┌─────────────────────────────────────────────────────────┐
│                    Controller 层                         │
│              SearchController (REST API)                 │
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│                     Service 层                           │
│  ┌──────────────────────────────────────────────────┐  │
│  │  SearchService (检索编排服务)                      │  │
│  │  - 单源检索                                        │  │
│  │  - 混合检索 (RRF 融合)                            │  │
│  │  - 检索并重排                                      │  │
│  └──────────────────────────────────────────────────┘  │
│                            ↓                             │
│  ┌──────────────┬──────────────┬──────────────────┐   │
│  │ ES 检索服务   │ Milvus 检索   │ 重排服务          │   │
│  │ ElasticsearchSearchService                       │   │
│  │              │ MilvusSearchService                │   │
│  │              │              │ RerankService      │   │
│  └──────────────┴──────────────┴──────────────────┘   │
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│                    Helper 层                             │
│  ┌──────────────┬──────────────┬──────────────────┐   │
│  │ 缓存助手      │ 融合算法助手  │ 容错助手          │   │
│  │ CacheHelper  │ FusionHelper │ FallbackHelper   │   │
│  └──────────────┴──────────────┴──────────────────┘   │
└─────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────┐
│                   外部依赖                               │
│  ┌──────────────┬──────────────┬──────────────────┐   │
│  │ Elasticsearch│ Milvus       │ BGE-Rerank API   │   │
│  │ Client       │ Client       │ HTTP Client      │   │
│  └──────────────┴──────────────┴──────────────────┘   │
└─────────────────────────────────────────────────────────┘

关于生成模块，我觉得真正的智能体，是不靠「提示词」工作的，当前模型主要依赖于tool agent rl，个人感觉未来会有workflow agent rl，大语言模型智能体能不仅动态地自主指挥自己的行动和工具使用，还可以去切换角色及行为模式，故这里本地实现未来的模式，web端作为workflow最佳实践探索。

事实证明，发现Web端的深度研究生成Codestyle模板使用率几乎为0，因为正在废弃这个功能，我们发现，使用者更倾向于借助OpenClaw连接上飞书上，走到哪，把灵感文章发给OpenClaw，然后调用Codestyle Skill进行生成模板，放到云仓库中。如果需要共享，则上传到远程仓库，方便其他Agent进行使用，也为未来的Agent Community时代做铺垫。

这里贴上我之前的一版设计：

▼
text
复制代码
┌─────────────────────────────────────────────────────────────────────────────┐
│                            用户交互层                                        │
│                                                                              │
│   ┌───────────────────────────┐          ┌───────────────────────────┐     │
│   │     AI IDE (本地模式)      │          │     Web 平台 (远程模式)    │     │
│   │                            │          │                           │     │
│   │  纯 Skill.md 驱动          │          │  DeepResearch Agent       │     │
│   │  - AI 自行决策             │          │  - 状态图管理             │     │
│   │  - 无状态管理              │          │  - 中断恢复               │     │
│   │  - 轻量快速                │          │  - 可视化进度             │     │
│   │                            │          │                           │     │
│   │  适合：简单模板生成        │          │  适合：复杂深度研究       │     │
│   └───────────────────────────┘          └───────────────────────────┘     │
│                                                                              │
└─────────────────────────────────────────────────────────────────────────────┘

五、Codestyle生成

后来我参考Skill-creator的设计，对我的Skill做了一些优化，这里分享一下个人心得：

Concise is Key - 保持简洁，只包含 AI 不知道的信息
Progressive Disclosure - metadata 始终加载，body 按需加载，references 按需加载
Set Appropriate Degrees of Freedom - 根据任务复杂度设置自由度
避免深层嵌套 - references 只有一层
Examples Pattern - 用例子说明期望的输出格式

Skill目录也进行了升级：

▼
text
复制代码
codestyle/
├── SKILL.md                      # 主入口（决策树）
├── references/
│   ├── config.md                 # 配置说明
│   ├── generate-workflow.md      # 生成工作流（核心·624行）
│   ├── search-workflow.md        # 检索工作流
│   ├── upload-workflow.md        # 上传工作流
│   ├── template-format.md        # 模板格式规范
│   └── template-syntax.md        # FreeMarker 语法
├── scripts/
│   ├── codestyle-server.jar      # CLI工具（Lucene）
│   ├── codestyle.bat / codestyle # 跨平台脚本
│   ├── cfg.json                  # 配置文件
│   ├── validate_template.py      # 验证脚本
│   └── init-*.bat/sh             # 辅助脚本
└── examples/
    └── crud-controller/
        ├── meta.json
        └── Controller.java.ftl

我相信，未来大模型当把最佳workflow AGent rl后，那么模型根据场景自动CosPlay角色、性格、剧本将会更好玩，更加智能。事实上，我实测后，我发现最新的Claude模型以及GLM-5，在我的这个设计下，效果很好，但是差一点模型，确实还很难在Workflow来回切换，经常被上下文影响、误导。

对于用户的交互，我这里分享几点设计心得：

输入识别后询问用户选择
检测到冲突时提供多种选项
合并操作时展示功能对比
最终确认前展示完整预览

对于冲突的处理：

覆盖：直接替换旧模板
升级版本：作为新版本保存
重命名：改名保存
合并：将新旧模板合并
不合并：保留两个独立的模板
删除旧模板：删除已有模板，用新模板替代
取消：不保存新模板

于是，整个生成流程：

用户输入 → AI识别类型 → AI预处理 → AI分析结构 → AI选择类型 → AI生成模板 → AI去重检测 → 用户确认 → 调用upload存储

这里最近我们参考 RepoMaster / DeerFlow / **Repomix**等前沿方案，实现了全局语法解析、上下文压缩、开发意图实时跟踪、沙盒编译子验证。因为我们发现，决定Code Agent对一个人类工业界的最佳实践做法进行理解，最重要的是去抽离抽象的设计以及通用解，这一部分，需要不断地去压缩冗余的知识，还需要去实时理解人类意图，去定位人类现实真正需要解决的问题。（近期发现AI提取的Codestyle风格，有时候不符合人类真实开发的场景，也就是无效模板。类似于无效Issue一样。）

随着不断的迭代Codestyle，因为我是做Java开发的，也一直在尝试用AI去解决我的后端开发领域的机械问题。希望能早日解放双手，失业。

在后端开发中，我们常常会对某个业务加入中间件优化来适配业务需求，例如缓存优化，此时，框架、技术栈、业务要求的不同，意味着缓存策略不同，我们针对性设计不同的模板，后期可以直接应用。开发者将不再聚焦于技术策略的机械应用，而在于技术策略的设计与选择。

就在寒假，我最近又加入了新的优化，我们常常会遇到这样一个需求：基于 X 项目/模板创建 Y 项目，比如，

「基于 LightRAG 初始化 SuperRAG」（Python）
「基于 ContiNew Admin 创建 MyCompany Admin」（Java）
「基于 RuoYi 初始化 myproject」（Java）
任意「基于 X 创建 Y」的项目初始化请求

大概的效果是这样的：

随着MCP/Skill的使用，我们摒弃了远程的深度研究，针对本地端的Agent进行模板生成中，对于复杂大型项目的理解做了一些AST解析、剪枝相关的优化：

感谢大佬的PR。

（1）对项目进行深入分析，构建骨架、依赖图、索引。

示例产物：

（2）分析多个关键词，返回项目整体大架构，用于分析项目。

示例产物：

（3）深入分析项目，多功能返回项目具体细节，用于指导修改。

示例产物：

我们也对优化进行了一个前后比对：

任务：

Task1（项目理解）：代码索引精度、输出质量二者相近，但 MCP 用 2 次调用即获得全局视图，探索轮次更少
Task2（代码修改）：MCP 方案在架构、聚类与 LLM 提示词设计上明显优于不使用MCP

可以看到：Task1 token 节省约 23%，Task2 token 节省约 21.4%，总 token 节省约 21.7%。

古法编程可能要读懂代码，然后一个一个替换修改。现在辅助编程呢，可能你需要先生成一份Wiki，或者让AI去读懂，然后再去读懂你的修改的期望需求，然后再一点点替换修改。先不说，一次性能不能替换成功，再者，也不能我得执行很多次步骤才可以。而且在这个模板上开发，我完全不懂这个框架，去改这个框架其实也很头疼的。就比如我们论文的A + B。

这个时候，我们不妨，交给 Project Start Skill,然后初始化，我们在这套风格交给Codestyle-generate途中作为干预，这样生成的风格都是你需要的，你甚至可以把这个过程交给另一个Agent，这个Agent继续理解你的需求，需求的任务将一一映射成Codestyle里面的最佳规范。这样做的第二个好处是，我们发现，在基于AI工具开发时，如果基模很差，Ralph Loop模式是没有用的。不如让 AI Coding 工具先出 Plan，Review，再写代码，再 Review，反复循环，也就是ReAct模式。这个时候呢，我们在规划时，指定尽可能复用Codestyle模板，此时Plan的文档，一方面Token将大大减少，解决方案直接标记使用xxcodestyle即可，另一方面，我们提前保证了Codestyle的质量和规范，我们不再需要考虑它的问题和实践性，我们只需要考虑，这套组合是否合理。是否满足业务需求。

更更重要的是，随着AI能力的提升，对我而言，已经开始了很多认知债，我已经在开发一些我的实际能力无法完成的工作，我只能做的是，告诉AI目标，帮他界定界限，让他帮我做完。而我刚开始的需求往往不是一蹴而就，可能刚开始不对，我会先用头脑风暴进行迭代很多轮，然后让AI Team帮我干活。此时我还会继续一致迭代，突然发现，这个Idea需要修改一下，如果是差模型，如果你的规约开发不够规范，那么你可能出现AI修改效率极低，且反复迭代，陷入循环，哪怕我新开chat，重新让他进行分析总结。

此时Codestyle Plan是一个很好的选择。我再规划是，设计文档是一堆Codestyle的堆砌，一旦出错，AI可以检索到对应Codestyle，进行回滚，顺着线索，它将以很少的次数即可回滚并替换成新的技术栈，这个是我感受最深的。

值得一提的是，我们尝试把这个能力接入到OpenClaw中，实现了随时随地整理自己的Codestyle，可能未来真的，这个我们写的代码，将不再面向人类，而是面向Agent，而这不正是Codestyle嘛？

🔗 开源仓库（欢迎技术交流 / PR），求大家多多Star（这对我的未来工作很重要，简历加分中哈哈哈），大家有任何的需求和问题，都可以评论区提问，我会每天晚上抽时间去优化修改，也会定期分享AI Coding心得：

MCP/Skill 服务端：https://github.com/itxaiohanglover/mcp-codestyle-server
核心模板规范：https://github.com/itxaiohanglover/codestyle
模板仓库管理：https://github.com/itxaiohanglover/codestyle-repository
项目初始化Skill： https://github.com/itxaiohanglover/project-start-skill

🔗 个人Github主页： itxaiohanglover (artboy)

最后，以一句话进行收尾：AI不是工具，不是软件，是一个新时代的思维方式，AI也不只是对话助手、第二大脑，而是多角色协同的数字军团，是撬动效率、认知、创造力杠杆的超级杠杆。

六、QA

下面补充一些，你可能会存在的疑惑。

Q：对于一个团队其实如果用好的模型进行产出有收益，其实不在乎 token，更在乎性能，你这个有什么意义？

A：Token消耗的背后，不仅仅是省 API 账单本身，背后反映的是三个更关键的问题：

延迟：上下文越长，模型推理越慢。有了codestyle后，我们可以规划中，借助Codestyle规划，能够减少很多模型输出时间。
稳定性 ：模型基于确定的限制，可以有效加快开发效率，对于小团队，更重要的是把优秀的框架用好，然后应用的实际生产中。
实践性：对于大厂的优秀技术，往往缺乏很好的实践生态，这就导致AI 需要每次阅读迭代总结，而且大厂的精力其实更多的聚焦在框架的极限提升，其实很多小厂跟不上，想应用，不仅要让工程师学习，还应该让AI 模型去提前学习。

Q：为什么选择Repomix XML 输出格式？

A：LLM 不是先“理解意思”再处理文本，而是先看 token 与 token 之间的关联。标签结构把这些关联提示得更明显，所以模型更容易学、也更容易对齐。 Transformer 的核心是 self-attention。它本质上在做：当前 token 应该重点看前后哪些 token？标签结构正好给了它很强的“路标”。

（1）同类信息更容易形成局部聚合，XML中：相邻 token、结构一致的 token、重复出现的模式。

（2）层级关系被显式表达，标签结构天然有树状层级，更让模型建立：局部强相关 + 跨层弱相关的注意力分布。【找一篇对应的论文作证一下。】

（3）Q · K 点击更大，标签的作用就是让很多 token 的表示更稳定。

其次， XML 标签语义更清晰、支持属性压缩，减少token消耗。

示例：

JSON格式：

▼
json
复制代码
{
    "type": "file",
    "path": "UserController.java",
    "children": [
      {
        "type": "class",
        "name": "UserController",
        "children": [
          {
            "type": "method",
            "name": "getUser",
            "visibility": "public",
            "returnType": "User",
            "params": [{"name": "id", "type": "Long"}]
          }
        ]
      }
    ]
  }

XML格式：

▼
text
复制代码
<file path="UserController.java">
    <class name="UserController">
      <method name="getUser" visibility="public" returnType="User">
        <param name="id" type="Long"/>
      </method>
    </class>
  </file>

问答助学