更新ai-devops

.vitepress/config.mts

@@ -271,11 +271,11 @@ function sidebarCompiling(): DefaultTheme.SidebarItem[] {
           link: '/src/compile/why-distributed-compiling'
         },
         {
-          text: 'CloudBuild分布式编译',
+          text: 'CloudBuild',
           link: '/src/compile/cloudbuild'
         },
         {
-          text: 'ShareBuild共享编译',
+          text: 'ShareBuild',
           link: '/src/compile/sharebuild'
         },
       ]

src/compile/cloudbuild.md

@@ -1,13 +1,11 @@
-# CloudBuild私有云分布式编译系统
-
-##  CloudBuild的适用场景
-
-对于大型开发团队，CloudBuild私有云分布式编译系统不仅可以通过分布式编译加速项目编译过程，而且有大量编译任务是相同的，分布式编译缓存可以避免重复编译，从而节约算力消耗，并进一步缩短项目编译时间。
-
-## CloudBuild QuickStart
-
-todo
+# 分布式编译系统CloudBuild
+![alt text](/public/compile/promotional-graphic-cloudbuild.jpg)
+##  为什么需要分布式编译？
+- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟，所以缩短大型项目的编译时间的分布式编译系统有重要意义
+- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率，缩短项目编译时间
+- 在实际开发时，同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译，从而进一步加快编译效率
 
+## 总体架构
 ### 系统总体架构
 ![alt text](/public/compile/architecture.png)
 - Ninja：客户端，该机器上需要保存有完整的待编译项目源代码。

src/compile/index.md

@@ -1,24 +1,80 @@
 # 编译加速
 
 
-##  分布式编译
+##  分布式编译技术
 
 ![alt text](/public/compile/promotional-graphic-cloudbuild.jpg)
 
-- [为什么需要分布式编译？](/src/compile/why-distributed-compiling)
-- [CloudBuild私有云分布式编译系统](/src/compile/cloudbuild)
-- [ShareBuild分布式共享编译工作站](/src/compile/sharebuild)
-  - [以AOSP14项目为例ShareBuild分布式编译详细配置方法](/src/compile/sharebuild-aosp14.md)
+- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟，所以缩短大型项目的编译时间的分布式编译系统有重要意义
+- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率，缩短项目编译时间
+- 在实际开发时，同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译，从而进一步加快编译效率
 
+### CloudBuild
+![alt text](/public/compile/architecture.png)
+- Ninja：客户端，该机器上需要保存有完整的待编译项目源代码。
+- Action Cache：服务端缓存，主要保存编译任务的执行结果。
+- CAS Cache：服务端缓存，主要保存客户端上传的依赖文件，编译结果文件。
+- Scheduler：任务调度器，将编译任务id分发到各个编译节点。
+- Redis：主要存储具体的编译任务供编译节点领取执行，也可存储Action Cache和 CAS Cache中的内容加速编译。
+- MySQL：主要存储编译过程中的任务统计信息。
+- Executor：各个编译节点
 
-## AI编译器
+### ShareBuild
+![alt text](/public/compile/system-diagram.png)
+CloudBuild主程序分为三个部分：Client、Server、Executor。
+- Client：运行在客户端，和用户对接，用于生成待执行的远程编译任务， 同时也作为本地编译节点执行本地任务。
+- Server：运行在主服务器，主要用于连接各个编译节点，以及 将客户端上传的编译任务调度到与其连接的各个编译节点上。
+- Executor：运行在编译节点，负责接收并执行编译任务，是编译任务真正执行的地方。
 
-todo
+### 系统分层结构
+![alt text](/public/compile/layered-system-architecture.png)
 
-## PGO/LTO编译性能优化
-
-todo
+## 运行原理与流程
 
+### 分布式编译原理
+![alt text](/public/compile/compiler-principles.png)
+
+### CloudBuild客户端
+CloudBuild客户端基于Ninja改造，有下面这些优势
+- 兼容使用Ninja编译的项目
+- 使用远程执行的方式提高编译时并发度
+- 使用编译缓存减少需要编译的任务数量
+
+### CloudBuild服务端
+- 使用远程执行的方法提高编译时并发度，实现了任务分发至远程节点同步执行
+- 使用分布式任务调度提高任务调度效率和计算节点资源利用率，避免集中式调度的任务阻塞问题
+- 使用编译缓存结合内容寻址存储技术减少网络传输量、避免重复上传与重复编译
+
+### CloudBuild优势
+- 低成本：组成executor的机器不需要使用专门的高性能计算型机器，可使用多个平价的空闲机器
+- 高效：CloudBuild实现分布式编译的功能，相比单机大大提升并发度
+- 兼容Ninja：CloudBuild客户端基于Ninja改造，对于使用Ninja构建和可以转换为Ninja构建的项目不用额外修改构建清单
+
+### CloudBuild执行流程
+- 客户端: 生成远程任务->生成任务依赖->发送任务与依赖
+- 服务端：检查任务缓存->检查依赖完整性->调度任务
+- 编译结点：还原文件目录->还原文件目录->返回编译结果
+
+## AOSP和LLVM上的应用
+### LLVM上的应用效果
+![alt text](/public/compile/table1.png)
+### AOSP上的应用效果
+![alt text](/public/compile/table2.png)
+### CloudBuild硬件资源利用率
+4核CPU利用率:
+![alt text](/public/compile/CPU-utilization-4.png)
+8核CPU利用率:
+![alt text](/public/compile/CPU-utilization-8.png)
+16核CPU利用率:
+![alt text](/public/compile/CPU-utilization-16.png)
+
+## CloudBuild使用方法
+### CloudBuild安装
+![alt text](/public/compile/cloudbuild-installation.png)
+CloudBuild项目地址：https://gitee.com/cloudbuild888/cloudbuild.git
+### CloudBuild分布式编译
+![alt text](/public/compile/cloudbuild-distributed-compilation.png)
+LLVM项目地址：https://gitee.com/mirrors/LLVM.git
 
 
 

src/compile/sharebuild-aosp14.md

@@ -1,68 +0,0 @@
-# 以AOSP14项目为例ShareBuild分布式编译详细配置方法
-
-##  ShareBuild的适用场景
-
-在同一局域网内工作的小型团队，ShareBuild以P2P共享架构将空闲算力贡献给团队其他成员，从而为每个团队成员提供编译加速效果。
-
-## ShareBuild QuickStart
-
-* 同一个局域网内的A、B、C等所有节点上安装ninja2:
-
-```
-wget -c https://raw.githubusercontent.com/ninja-cloudbuild/ninja2/refs/heads/main/install.sh && chmod +x install.sh && sudo ./install.sh
-```
-
-* 启用ShareBuild的前置要求
-
- 1. 所有节点上均安装配置好了项目的编译环境，即所有节点上均能采用ninja成功单机编译项目。
- <!-- 
-
- 2. 选择任一节点上作为项目开发环境，项目中使用.devcontainer/devcontainer.json 配置了image镜像（示例如下），依次镜像创建的开发容器中能采用ninja成功单机编译项目。
-
-```
- {
-  "name": "DevContainer",
-  "image": "devstar.cn/devstar/DevContainer:latest" # 仅作示例，务必使用您已安装配置好项目编译环境的容器镜像！
- }
-```
-> 注意：以上两种方式二选一即可，第2种方式省掉了在其他节点上安装配置项目编译环境，但是首次ShareBuild模式分布式编译时其他节点会自动下载项目编译环境的容器镜像。
--->
-
-* 选择任一节点上作为项目开发环境，开启ShareBuild模式，然后进行分布式编译。
-
-项目根目录下创建ninja2.conf 文件如下即可开启ShareBuild模式：
-```
-sharebuid:true
-```
-这时使用ninja编译将自动进入ShareBuild模式分布式编译项目。
-
-> 如果直接使用ninja命令编译项目，也可以加上-s参数表示启用ShareBuild模式，示例如下：
-```
-ninja -s -r `realpath ../`            #启动分布式编译，注意-r 指定项目根目录
-ninja -t clean                        #清除编译产物
-````
-
-* 对一些特殊项目的补充说明
-
-除以上常规的ShareBuild配置外，对于一些特殊项目需要做一些额外的配置，补充说明如下：
-
-## 使用ShareBuild编译Android开源项目（AOSP）
-
-除按照以上方法准备好编译环境和开启ShareBuild模式外，以AOSP14项目为例，还需要替换ninja和准备.sharebuild.yml来过滤掉一些无法远程编译的命令，具体操作如下：
-
-```
-cp /usr/bin/android_ninja prebuilts/build-tools/linux-x86/bin/ninja
-cp /etc/ninja2/aosp14/.sharebuild.yml ./
-```
-
-然后就可以单机编译一样使用make命令来分布式编译Android开源项目（AOSP）。
-<!-- 
-## 使用ShareBuild编译鸿蒙开源项目（OpenHarmony）
-
-todo
--->
-## 版权声明
-
-Copyright @ Mengning Software
-
-梦宁软件（江苏）有限公司 版权所有

src/compile/sharebuild.md

@@ -1,74 +1,79 @@
-# ShareBuild分布式共享编译工作站
-
-##  ShareBuild的适用场景
-
-在同一局域网内工作的小型团队，ShareBuild以P2P共享架构将空闲算力贡献给团队其他成员，从而为每个团队成员提供编译加速效果。
-
-## ShareBuild QuickStart
-
-* 同一个局域网内的A、B、C等所有节点上安装ninja2:
-
-```
-wget -c https://raw.githubusercontent.com/ninja-cloudbuild/ninja2/refs/heads/main/install.sh && chmod +x install.sh && sudo ./install.sh
-```
-
-* 启用ShareBuild的前置要求
-
- 1. 所有节点上均安装配置好了项目的编译环境，即所有节点上均能采用ninja成功单机编译项目。
- <!-- 
-
- 2. 选择任一节点上作为项目开发环境，项目中使用.devcontainer/devcontainer.json 配置了image镜像（示例如下），依次镜像创建的开发容器中能采用ninja成功单机编译项目。
-
-```
- {
-  "name": "DevContainer",
-  "image": "devstar.cn/devstar/DevContainer:latest" # 仅作示例，务必使用您已安装配置好项目编译环境的容器镜像！
- }
-```
-> 注意：以上两种方式二选一即可，第2种方式省掉了在其他节点上安装配置项目编译环境，但是首次ShareBuild模式分布式编译时其他节点会自动下载项目编译环境的容器镜像。
--->
-
-* 选择任一节点上作为项目开发环境，开启ShareBuild模式，然后进行分布式编译。
-
-项目根目录下创建ninja2.conf 文件如下即可开启ShareBuild模式：
-```
-sharebuid:true
-```
-这时使用ninja编译将自动进入ShareBuild模式分布式编译项目。
-
-> 如果直接使用ninja命令编译项目，也可以加上-s参数表示启用ShareBuild模式，示例如下：
-```
-ninja -s -r `realpath ../`            #启动分布式编译，注意-r 指定项目根目录
-ninja -t clean                        #清除编译产物
-````
-
-* 对一些特殊项目的补充说明
-
-除以上常规的ShareBuild配置外，对于一些特殊项目需要做一些额外的配置，补充说明如下：
-
-## 使用ShareBuild编译Android开源项目（AOSP）
-
-除按照以上方法准备好编译环境和开启ShareBuild模式外，以AOSP14项目为例（[详细的配置方法](/src/compile/sharebuild-aosp14.md)），还需要替换ninja和准备.sharebuild.yml来过滤掉一些无法远程编译的命令，具体操作如下：
-
-```
-cp /usr/bin/android_ninja prebuilts/build-tools/linux-x86/bin/ninja
-cp /etc/ninja2/aosp14/.sharebuild.yml ./
-```
-
-然后就可以单机编译一样使用make命令来分布式编译Android开源项目（AOSP）。
-
-<!-- 
-## 使用ShareBuild编译鸿蒙开源项目（OpenHarmony）
-
-todo
--->
-
-## 参考链接
-
-* [以AOSP14项目为例ShareBuild分布式编译详细配置方法](/src/compile/sharebuild-aosp14.md)
-
-## 版权声明
-
-Copyright @ Mengning Software
-
-梦宁软件（江苏）有限公司 版权所有
+# 分布式编译系统ShareBuild
+![alt text](/public/compile/promotional-graphic-cloudbuild.jpg)
+##  为什么需要分布式编译？
+- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟，所以缩短大型项目的编译时间的分布式编译系统有重要意义
+- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率，缩短项目编译时间
+- 在实际开发时，同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译，从而进一步加快编译效率
+
+## 总体架构
+### 系统总体架构
+![alt text](/public/compile/architecture.png)
+- Ninja：客户端，该机器上需要保存有完整的待编译项目源代码。
+- Action Cache：服务端缓存，主要保存编译任务的执行结果。
+- CAS Cache：服务端缓存，主要保存客户端上传的依赖文件，编译结果文件。
+- Scheduler：任务调度器，将编译任务id分发到各个编译节点。
+- Redis：主要存储具体的编译任务供编译节点领取执行，也可存储Action Cache和 CAS Cache中的内容加速编译。
+- MySQL：主要存储编译过程中的任务统计信息。
+- Executor：各个编译节点
+
+### 部署示意图
+![alt text](/public/compile/system-diagram.png)
+CloudBuild主程序分为三个部分：Client、Server、Executor。
+- Client：运行在客户端，和用户对接，用于生成待执行的远程编译任务， 同时也作为本地编译节点执行本地任务。
+- Server：运行在主服务器，主要用于连接各个编译节点，以及 将客户端上传的编译任务调度到与其连接的各个编译节点上。
+- Executor：运行在编译节点，负责接收并执行编译任务，是编译任务真正执行的地方。
+
+### 系统分层结构
+![alt text](/public/compile/layered-system-architecture.png)
+
+## 运行原理与流程
+
+### 分布式编译原理
+![alt text](/public/compile/compiler-principles.png)
+
+### CloudBuild客户端
+CloudBuild客户端基于Ninja改造，有下面这些优势
+- 兼容使用Ninja编译的项目
+- 使用远程执行的方式提高编译时并发度
+- 使用编译缓存减少需要编译的任务数量
+
+### CloudBuild服务端
+- 使用远程执行的方法提高编译时并发度，实现了任务分发至远程节点同步执行
+- 使用分布式任务调度提高任务调度效率和计算节点资源利用率，避免集中式调度的任务阻塞问题
+- 使用编译缓存结合内容寻址存储技术减少网络传输量、避免重复上传与重复编译
+
+### CloudBuild优势
+- 低成本：组成executor的机器不需要使用专门的高性能计算型机器，可使用多个平价的空闲机器
+- 高效：CloudBuild实现分布式编译的功能，相比单机大大提升并发度
+- 兼容Ninja：CloudBuild客户端基于Ninja改造，对于使用Ninja构建和可以转换为Ninja构建的项目不用额外修改构建清单
+
+### CloudBuild执行流程
+- 客户端: 生成远程任务->生成任务依赖->发送任务与依赖
+- 服务端：检查任务缓存->检查依赖完整性->调度任务
+- 编译结点：还原文件目录->还原文件目录->返回编译结果
+
+## AOSP和LLVM上的应用
+### LLVM上的应用效果
+![alt text](/public/compile/table1.png)
+### AOSP上的应用效果
+![alt text](/public/compile/table2.png)
+### CloudBuild硬件资源利用率
+4核CPU利用率:
+![alt text](/public/compile/CPU-utilization-4.png)
+8核CPU利用率:
+![alt text](/public/compile/CPU-utilization-8.png)
+16核CPU利用率:
+![alt text](/public/compile/CPU-utilization-16.png)
+
+## CloudBuild使用方法
+### CloudBuild安装
+![alt text](/public/compile/cloudbuild-installation.png)
+CloudBuild项目地址：https://gitee.com/cloudbuild888/cloudbuild.git
+### CloudBuild分布式编译
+![alt text](/public/compile/cloudbuild-distributed-compilation.png)
+LLVM项目地址：https://gitee.com/mirrors/LLVM.git
+
+
+
+
+

src/compile/why-distributed-compiling.md

@@ -1,11 +1,76 @@
 # 为什么需要分布式编译？
 
-大型项目过长的编译耗时给开发、调试、测试和CI/CD都带来延迟，缩短大型项目的编译时间是分布式编译系统的主要目标。
+- 大型项目过长的编译耗时将会给开发、测试和调试都带来延迟，所以缩短大型项目的编译时间的分布式编译系统有重要意义
+- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率，缩短项目编译时间
+- 在实际开发时，同一个团队大量的编译任务时相同的。CloudBuild提供的编译缓存可以避免重复上传和重复编译，从而进一步加快编译效率
 
-- 使用分布式编译系统编译项目可以利用计算机集群提高编译效率，缩短项目编译时间。
-- 在实际开发时，同一个团队有大量编译任务是相同的，分布式编译缓存可以避免重复编译，从而节约算力消耗并进一步缩短项目编译时间。
+## 总体架构
+### 系统总体架构
+![alt text](/public/compile/architecture.png)
+- Ninja：客户端，该机器上需要保存有完整的待编译项目源代码。
+- Action Cache：服务端缓存，主要保存编译任务的执行结果。
+- CAS Cache：服务端缓存，主要保存客户端上传的依赖文件，编译结果文件。
+- Scheduler：任务调度器，将编译任务id分发到各个编译节点。
+- Redis：主要存储具体的编译任务供编译节点领取执行，也可存储Action Cache和 CAS Cache中的内容加速编译。
+- MySQL：主要存储编译过程中的任务统计信息。
+- Executor：各个编译节点
 
-![alt text](/public/compile/promotional-graphic-cloudbuild.jpg)
+### 部署示意图
+![alt text](/public/compile/system-diagram.png)
+CloudBuild主程序分为三个部分：Client、Server、Executor。
+- Client：运行在客户端，和用户对接，用于生成待执行的远程编译任务， 同时也作为本地编译节点执行本地任务。
+- Server：运行在主服务器，主要用于连接各个编译节点，以及 将客户端上传的编译任务调度到与其连接的各个编译节点上。
+- Executor：运行在编译节点，负责接收并执行编译任务，是编译任务真正执行的地方。
+
+### 系统分层结构
+![alt text](/public/compile/layered-system-architecture.png)
+
+## 运行原理与流程
+
+### 分布式编译原理
+![alt text](/public/compile/compiler-principles.png)
+
+### CloudBuild客户端
+CloudBuild客户端基于Ninja改造，有下面这些优势
+- 兼容使用Ninja编译的项目
+- 使用远程执行的方式提高编译时并发度
+- 使用编译缓存减少需要编译的任务数量
+
+### CloudBuild服务端
+- 使用远程执行的方法提高编译时并发度，实现了任务分发至远程节点同步执行
+- 使用分布式任务调度提高任务调度效率和计算节点资源利用率，避免集中式调度的任务阻塞问题
+- 使用编译缓存结合内容寻址存储技术减少网络传输量、避免重复上传与重复编译
+
+### CloudBuild优势
+- 低成本：组成executor的机器不需要使用专门的高性能计算型机器，可使用多个平价的空闲机器
+- 高效：CloudBuild实现分布式编译的功能，相比单机大大提升并发度
+- 兼容Ninja：CloudBuild客户端基于Ninja改造，对于使用Ninja构建和可以转换为Ninja构建的项目不用额外修改构建清单
+
+### CloudBuild执行流程
+- 客户端: 生成远程任务->生成任务依赖->发送任务与依赖
+- 服务端：检查任务缓存->检查依赖完整性->调度任务
+- 编译结点：还原文件目录->还原文件目录->返回编译结果
+
+## AOSP和LLVM上的应用
+### LLVM上的应用效果
+![alt text](/public/compile/table1.png)
+### AOSP上的应用效果
+![alt text](/public/compile/table2.png)
+### CloudBuild硬件资源利用率
+4核CPU利用率:
+![alt text](/public/compile/CPU-utilization-4.png)
+8核CPU利用率:
+![alt text](/public/compile/CPU-utilization-8.png)
+16核CPU利用率:
+![alt text](/public/compile/CPU-utilization-16.png)
+
+## CloudBuild使用方法
+### CloudBuild安装
+![alt text](/public/compile/cloudbuild-installation.png)
+CloudBuild项目地址：https://gitee.com/cloudbuild888/cloudbuild.git
+### CloudBuild分布式编译
+![alt text](/public/compile/cloudbuild-distributed-compilation.png)
+LLVM项目地址：https://gitee.com/mirrors/LLVM.git
 
 
 

src/devstar/ai-code-reveiw.md

@@ -30,106 +30,3 @@ DevStar代码托管平台中项目设置、用户设置和后台管理中都可
 
 ### AI Code Review详解
 
-## **一、核心工作流程说明**
-
-AI Code Review 的执行过程如下：
-
-1. **触发条件**
-   - 当有人新建 PR（pull_request/opened）
-   - 或更新了 PR（pull_request/synchronize）
-      → 工作流自动开始执行。
-2. **代码检出（Checkout）**
-    使用 actions/checkout 拉取 PR 的代码差异，为审查准备上下文。
-3. **调用 AiReviewPR Action**
-   - Action 会读取 PR 的 diff、文件内容与上下文。
-   - 将这些内容组装为审查提示（prompt）。
-   - 调用你配置的大模型（Ollama、OpenAI 兼容接口等）。
-   - 获得模型输出后，自动写入 PR 评论区或输出到日志。
-4. **输出结果**
-   - 如果 `REVIEW_PULL_REQUEST=true` → 自动在 PR 下评论。
-   - 如果为 false → 只在日志输出，便于本地验证。
-
-------
-
-## **二、AiReviewPR 的内部实现机制**
-
-以下是 Action 的实际工作方式（代码见 GitHub）：
-
-### **1. 自动收集 PR 信息**
-
-Action 会自动读取：
-
-- PR 编号、作者、提交信息
-- diff 内容（新增、删除、修改）
-- 受影响的文件内容
-
-### **读取 PR Diff**
-
-```
-const diff = await octokit.pulls.get({
-  ...github.context.issue,
-  mediaType: { format: "diff" },
-}).then(r => r.data);
-```
-
-### 2. 构建审查 Prompt
-
-Prompt 会自动包含：
-
-- 代码变更摘要
-
-- 修改前/修改后的代码片段
-
-- 模型需要回答的格式，例如：
-
-  ```
-  1. 潜在Bug
-  2. 代码风格问题
-  3. 性能优化
-  4. 安全风险
-  5. 重构建议
-  ```
-
-### **3. 调用大模型 API**
-
-AiReviewPR 支持任意 OpenAI API 兼容模型，例如：
-
-- 本地 **Ollama**
-- OpenAI、DeepSeek、Qwen 公开服务
-- 私有化模型服务
-
-只需提供：
-
-```
-vars.MODEL
-vars.OLLAMA_HOST
-```
-
-Action 会自动发送：
-
-```
-{
-  "model": "qwen2.5:14b",
-  "messages": [
-    {"role": "system", "content": "..."},
-    {"role": "user", "content": "这是PR的代码修改内容..."}
-  ]
-}
-```
-
-### **4. 返回数据解析**
-
-Action 提取模型的回答内容，将其转换为 Markdown，并根据配置输出为：
-
-- GitHub/Gitea PR 评论
-   或
-- 工作流日志（便于调试）
-
-### **发布评论**
-
-```
-await octokit.issues.createComment({
-  ...github.context.issue,
-  body: review,
-});
-```

src/devstar/ai-devops.md

@@ -15,11 +15,11 @@ wget -c https://devstar.cn/assets/install.sh && chmod +x install.sh && sudo ./in
 sudo devstar start
 ```
 
-安装完成后，我们得到DevStar代码托管平台的URL，比如http://172.16.94.26:80 ，之后作为 `GITEA_HOST`（给 MCP Server 用）
+安装完成后，我们得到DevStar代码托管平台的URL，比如http://172.16.94.26:80
 
 ### 二、Ollama私有部署代码大模型
 
-> 如您使用第三方API及Token，比如从[智谱AI开放平台](https://bigmodel.cn/usercenter/proj-mgmt/apikeys) 上注册申请并添加新的API Key，可以跳过这一部分。
+> 如您使用第三方API及Token，比如从http://xxx 注册申请，可以跳过这一部分。
 
 Ubuntu-20.04下完成安装：
 ```
@@ -54,14 +54,7 @@ systemctl daemon-reload
 systemctl restart ollama
 ```
 
-**产出**
-
-- 模型服务地址，例如：`http://172.16.94.26:11434`
-- 模型名，例如：`qwen2.5-coder:32b`
-
-**后面用在哪里**
-
-- CI/CD 里的 AI Code Review（作为 `vars.MODEL` / `vars.OLLAMA_HOST`）
+安装完成后，我们得到API URL,比如http://172.16.94.26:11434/api/tags model比如qwen2.5-coder:32b token比如TOKEN***************
 
 ### 三、在项目中使用代码大模型
 
@@ -90,14 +83,8 @@ jobs:
           model: ${{ vars.MODEL }}
           host: ${{ vars.OLLAMA_HOST }}
           REVIEW_PULL_REQUEST: false
-          //如果用ai token 则需配置
-          //ai_token: ${{ vars.AI_TOKEN }}
 ```
-然后在 DevStar（项目设置 / 用户设置 / 后台管理）里设置变量：
-
-- `vars.MODEL`：填入 **第二步中的模型名**，例如 `qwen2.5-coder:32b`
-- `vars.OLLAMA_HOST`：填入 **第二步中得到的模型服务地址** 例如 `http://172.16.94.26:11434`
-- `vars.AI_TOKEN`：填入 **第二步中第三方获取的token**
+DevStar代码托管平台中项目设置、用户设置和后台管理中都可以设置变量vars.MODEL、vars.OLLAMA_HOST等。
 
 #### 安装配置MCP Server
 
@@ -131,7 +118,7 @@ jobs:
           "docker.gitea.com/gitea-mcp-server"
         ],
         "env": {
-          "GITEA_HOST": "<Your Gitea Host>",
+          "GITEA_HOST": "http://172.16.94.26",
           "GITEA_ACCESS_TOKEN": "${input:gitea_token}"
         }
       }
@@ -139,22 +126,11 @@ jobs:
 }
 ```
 
-`GITEA_HOST`：**第一步中得到的 DevStar 代码托管平台地址**
-
-`gitea_token`：来自 DevStar / Gitea 的「个人访问令牌」
-
-获取方式：
-
-1. 登录 DevStar（`GITEA_HOST` 对应的网站）
-2. 进入：**设置 → 应用 **
-3. 点击「生成新的令牌」，给予仓库读取等必要权限
-4. 复制生成的一串字符串，这就是你的 `gitea_token`
-
 #### 配置AI IDE/CLI使用私有大模型及MCP Server
 
 * Copilot，点击提示框里的“管理模型”，选择ollama；将mcp配置添加到 .vscode/mcp.json下
 
-* Cursor，不支持内网地址的私有部署大模型，需要做反向代理使用公网可以访问的地址；点击Cursor Settings -> Tools & MCP
+* Cursor，不支持私有模型，需要本地部署后做代理；点击Cursor Settings -> Tools & MCP
 
   ->  New MCP Server 将mcp配置添加到mcp.json中
 
@@ -172,33 +148,33 @@ jobs:
 
 使用ai-develops项目模板创建项目
 
-![](./static/template.png)
+![](template.png)
 
-在项目中创建一个issue
+配置mcp.json的GITEA_HOST和GITEA_ACCESS_TOKEN
 
-![](./static/issue-1.png)
+![](mcp.png)
 
 ### AI生成代码
 
-1.请在 Gitea 仓库 owner/repo 中读取 issue #1，帮我用自己的话总结问题、预期行为，并给出一个简单的解决思路。
-
-2.请根据你对 issue #的理解实现这个功能
-
-3.请为这次修复 issue #1 的改动补充或更新测试代码，遵循项目的现有测试风格，并说明每个测试在验证什么行为。
-
+![](issue.png)
 
+![](code.png)
 
 ### 提交PR
 
-1.请使用 Gitea MCP 为 issue #1创建一个新分支（如 fix/issue-1），将本次所有相关修改提交为一个清晰的 commit
+![](feature.png)
 
-2.请使用 Gitea MCP 从你刚才创建的分支向 main 分支发起一个 PR，标题中包含 “#1”，描述中简要说明问题、解决方案、主要改动和测试情况，并把 PR 的链接或编号发给我。
+![](feature-2.png)
 
-![](./static/pr.png)
+![](pr.png)
 
 ### AI Code Review
 
-![](./static/code-review.png)
+设置工作流相关变量
 
-![](./static/review.png)
+![](vars.png)
+
+![](code-review.png)
+
+![](review.png)
 

src/devstar/mcp-server.md

@@ -1,3 +1,4 @@
+
 # MCP Server
 
 ### 快速安装配置MCP Server
@@ -10,6 +11,7 @@
 
 ```
 {
+  "mcp": {
     "inputs": [
       {
         "type": "promptString",
@@ -32,32 +34,18 @@
           "docker.gitea.com/gitea-mcp-server"
         ],
         "env": {
-          "GITEA_HOST": "<Your Gitea Host>",
+          "GITEA_HOST": "--host http://172.16.94.26",
           "GITEA_ACCESS_TOKEN": "${input:gitea_token}"
         }
       }
     }
+  }
 }
 ```
 
 ### MCP Server使用注意事项
 
-#### Copilot（VS Code）
-
-- 配置放在 `.vscode/mcp.json`。重启 VS Code → Copilot 自动加载。
-- [官方文档](https://vscode.js.cn/docs/copilot/customization/mcp-servers)
-
-
-
-#### Cursor
-
-- 配置放在 `.cursor/mcp.json` 或 `.vscode/mcp.json`。
-- 打开 Cursor → 会提示“检测到 MCP Server”。点 Enable 即可。
-- [官方文档](https://cursor.com/cn/docs/context/mcp)
-
-
-
-#### Continue
-
-- 配置放在 `.continue/mcpServers/mcp.json`
-- [官方文档](https://docs.continue.dev/customize/deep-dives/mcp)
+* Copilot，简要文字描述，不要上太多图，可以提供官方配置链接
+* Cursor
+* Continue
+* ...