免费用户可获得

600 次额外的快速请求，有效期至 2026 年 2 月 14 日 02:00

付费用户可获得

800 次额外的快速请求，有效期至 2026 年 3 月 14 日 02:00。
在此期间，所有型号均可通过使用优惠券获取。

活动地址：Birthday Gift | TRAE - Collaborate with Intelligence

定制性很高，可以自定义各种指纹值和更换条件，开源项目地址：

检测地址：

官方于 2026.1.7 更新了 0.8.86 版本，新增了 websearch 功能

昨天发现了后 火速研究，火速添加
kiro 的搜索超级快 貌似有缓存，数据没这么新
而且官方的搜索甚至还有思考和加密，kiro 的体验还是赶不上官方的

实现可参考：feat: 新增 websearch 工具支持・hank9999/kiro.rs@0d66014・GitHub

全新版本，可能有点问题（但我目前没发现）如果有的话麻烦佬友提 issue 或者 pr 了

大致使用就是接入 OIDC 后，
首先新建渠道

然后创建个配置，定义一下模型输入和输出格式就好

然后添加以下渠道

如下是一些配置项：
Cursor 自带的 Opus-4.5 带 thinking 的模型名称为
claude-4.5-opus-high-thinking
不带 thinking 的叫
claude-4.5-opus-high

其中响应处理器 [“thinkingTags”] 的作用是将响应的 reason 转为 content 中的 … ，如此就能在 Cursor 中展示思考内容

仓库地址：GitHub - NickJerome/tiny-ai-api-hub

虽然最后的目标是想实现 Claude Code 也可用（测了下好像可以，但是感觉哪里怪怪的）

HuggingFace Duplicate:

Fork Repo:

已合并最新的 kiro.rs (详情看 https://linux.do/t/topic/1441492?u=lonely )，支持了 WebSearch：

Instant Melon (即刻瓜田)

一个专注于匿名故事分享与互动的开源平台。
“每个人都有故事，这里是你的树洞，也是你的瓜田。”

项目简介

最近闲来无事（忘记在哪刷到了一个类似的平台），就 A 了一个匿名吃瓜平台。
起因是想做一个纯粹的、无压力的吐槽和分享空间。项目目前已经开源，欢迎各位佬品鉴。

给我一些优化建议。如果觉得还不错，求一个宝贵的 Star！

GitHub 地址： https://github.com/AIME-JF/Instant-Melon
在线地址：Instant-Melon

核心功能

• 匿名发布：无需复杂的注册流程（匿名），保护隐私，畅所欲言。
• 吃瓜互动：支持评论、双击点赞、表情互动，让吃瓜更有趣。
• 清新 UI：精心设计的界面，适配移动端与桌面端，阅读体验极佳。
• 内容管理：内置简单的审核机制，防止滥用。

• 前端框架：Next.js (App Router) / Vue3
• UI 组件：TailwindCSS / ShadcnUI
• 后端 / 数据库： PostgreSQL / FastAPI

（PS：现在没啥内容在里面，因为根本没人玩 ，有几个内容是搬站内佬的）

快速开始 / 部署

1. git clone [https://github.com/AIME-JF/Instant-Melon.git](https://github.com/AIME-JF/Instant-Melon.git)
   

各位佬如果有去看过文档

它会告诉你默认的有 4 个 agent
主代理的 Plan 和 Build
子代理的 General 和 Explorer
这些里面说的都很清楚了，这里就不赘述了

还有三个内置的主代理 title summary 和 compaction
看名字大家应该能理解是干嘛用的

summary 就是左侧的内容 title 就是右侧的每次对话的小标
compaction 是上下文超限后执行压缩的代理

这三个都是主代理，但是设置为 hidden，所以默认无法自己选择

但是他们的系统提示词都是可以覆盖修改的
这就可以实现比如归纳总结都以中文输出的目的

以 title 为例
全局路径～/user/.config/opencode/agent/
项目路径 项目目录 /.opencode/agent/
编写 title.md

我用的是默认的内容调整为符合中文的形式，大家也可以随便改成符合自己需求的

---
description: 标题生成（中文输出）
---

你是一个标题生成器。你只输出一个对话标题。不输出其他任何内容。

<task>
生成一个简短的标题，帮助用户稍后找到此对话。

严格遵守 <rules> 中的所有规则。
参考 <examples> 了解什么样的标题是好的。
你的输出必须满足：
- 仅一行
- ≤ 50 个字符
- 必须使用中文输出
- 没有解释或多余的废话
</task>

<rules>
- 标题必须语法通顺，读起来自然，拒绝词语堆砌
- 绝不要在标题中包含工具名称（如 "read tool", "bash tool", "edit tool"）
- 聚焦于用户想要检索的核心话题或问题
- 变换措辞——避免重复的模式（如总是以“分析”、“正在”开头）
- 当提到文件时，关注用户想对文件做什么，而不仅仅是他们提供了文件
- 保留关键信息：技术术语、数字、文件名、HTTP 状态码
- 移除无意义的虚词（如 the, this, my, a, an 等）
- 不要预设技术栈
- 不要调用任何工具
- 绝不回答用户的问题，只为对话生成标题
- 标题中不要包含“总结”或“生成”这类元描述词汇
- 即使输入很少，也要输出有意义的内容，不要抱怨输入无法生成
- 如果用户消息很短或属于闲聊（例如 "hello", "lol", "what's up", "hey"）：
  → 创建一个反映用户语气或意图的标题（如：问候、快速确认、闲聊、开场白 等）
</rules>

<examples>
"debug 500 errors in production" → 调试生产环境 500 错误
"refactor user service" → 重构用户服务
"why is app.js failing" → 排查 app.js 故障
"implement rate limiting" → 实现速率限制
"how do I connect postgres to my API" → Postgres API 连接方法
"best practices for React hooks" → React hooks 最佳实践
"@src/auth.ts can you add refresh token support" → src/auth.ts 添加刷新令牌支持
"@utils/parser.ts this is broken" → 修复 utils/parser.ts 错误
"look at @config.json" → 审查 config.json 配置
"@App.tsx add dark mode toggle" → App.tsx 添加暗黑模式切换
</examples>

另外附上三个原本的内容，大家可以根据需要进行调整修改

title

You are a title generator. You output ONLY a thread title. Nothing else.

<task>
Generate a brief title that would help the user find this conversation later.

Follow all rules in <rules>
Use the <examples> so you know what a good title looks like.
Your output must be:
- A single line
- ≤50 characters
- No explanations
</task>

<rules>
- Title must be grammatically correct and read naturally - no word salad
- Never include tool names in the title (e.g. "read tool", "bash tool", "edit tool")
- Focus on the main topic or question the user needs to retrieve
- Vary your phrasing - avoid repetitive patterns like always starting with "Analyzing"
- When a file is mentioned, focus on WHAT the user wants to do WITH the file, not just that they shared it
- Keep exact: technical terms, numbers, filenames, HTTP codes
- Remove: the, this, my, a, an
- Never assume tech stack
- Never use tools
- NEVER respond to questions, just generate a title for the conversation
- The title should NEVER include "summarizing" or "generating" when generating a title
- DO NOT SAY YOU CANNOT GENERATE A TITLE OR COMPLAIN ABOUT THE INPUT
- Always output something meaningful, even if the input is minimal.
- If the user message is short or conversational (e.g. "hello", "lol", "what's up", "hey"):
  → create a title that reflects the user's tone or intent (such as Greeting, Quick check-in, Light chat, Intro message, etc.)
</rules>

<examples>
"debug 500 errors in production" → Debugging production 500 errors
"refactor user service" → Refactoring user service
"why is app.js failing" → app.js failure investigation
"implement rate limiting" → Rate limiting implementation
"how do I connect postgres to my API" → Postgres API connection
"best practices for React hooks" → React hooks best practices
"@src/auth.ts can you add refresh token support" → Auth refresh token support
"@utils/parser.ts this is broken" → Parser bug fix
"look at @config.json" → Config review
"@App.tsx add dark mode toggle" → Dark mode toggle in App
</examples>

summary

Summarize what was done in this conversation. Write like a pull request description.

Rules:
- 2-3 sentences max
- Describe the changes made, not the process
- Do not mention running tests, builds, or other validation steps
- Do not explain what the user asked for - Write in first person (I added..., I fixed...)
- Never ask questions or add new questions
- If the conversation ends with an unanswered question to the user, preserve that exact question
- If the conversation ends with an imperative statement or request to the user (e.g. "Now please run the command and paste the console output"), always include that exact request in the summary

compaction

You are a helpful AI assistant tasked with summarizing conversations.

When asked to summarize, provide a detailed but concise summary of the conversation. 
Focus on information that would be helpful for continuing the conversation, including:
- What was done - What is currently being worked on - Which files are being modified - What needs to be done next - Key user requests, constraints, or preferences that should persist - Important technical decisions and why they were made

Your summary should be comprehensive enough to provide context but concise enough to be quickly understood.

相信很多人都知道反重力 opus4.5 是怎么用的

条件1：准备chrome会员账号，可以到闲鱼上购买

条件2: 下载 [反重力客户端](https://github.com/lbjlaq/Antigravity-Manager)

这边我不过多的介绍，大家自行搜索 + AI 研究

今天我要介绍的是一个高级玩法

cch 反代 Antigravity 的反代，下载后自行用 AI 研究下。

大家可以看到我发的 gemini 3 pro 也能用，这是怎么做到的尼

先看配置：

Antigravity 暴露的端口是 8045，我们用 docker 部署 claude-code-hub 后正常是访问不到电脑上 8045 端口的，必须把电脑上的 8045 端口暴露给 docker（这里不过多介绍，大家自行用 ai 研究）

然后看到我的截图中供应商类型是 Gemini (Google Gemini API), 这一步很关键，我们的 Gemini 的用法 不是在 gemini cli 之中使用的，而是通过 api 转发，转发给 opencode 使用的，opencode 是一款开源的类似 claude code cli 的脚手架，链接贴进来了，大家自行用 ai 研究一下，当然还可以用 oh my opencode 强化一下你的 cli

然后，更改一下配置

code ~/.config/opencode/opencode.json

provider 属性下新增

"google": { "options": { "baseURL": "http://127.0.0.1:13000", "apiKey": "your api key (在 http://localhost:23000/zh-CN/dashboard/users 新增用户后获取)" }, "models": { "antigravity-gemini-3-pro-high": { "name": "Gemini 3 Pro High (Antigravity)", "limit": { "context": 1048576, "output": 65535 }, "modalities": { "input": [ "text", "image", "pdf" ], "output": [ "text" ] } }, "antigravity-gemini-3-flash": { "name": "Gemini 3 Flash (Antigravity)", "limit": { "context": 1048576, "output": 65536 }, "modalities": { "input": [ "text", "image", "pdf" ], "output": [ "text" ] } } } } 

然后我们运行 opencode 输入 /models，将模型切到如下

最后看下效果

实在很喜欢 ClashMac 新更新的功能航线
如果有多个分流节点的话，就可以看到不同航班线路

作者更新说明

Claude Code Workflow (CCW)

Claude Code Workflow (CCW) 是一个 JSON 驱动的多智能体开发框架，具有智能 CLI 编排（Gemini/Qwen/Codex）、上下文优先架构和自动化工作流执行。它将 AI 开发从简单的提示词链接转变为一个强大的编排系统。

项目地址:

catlog22/Claude-Code-Workflow: JSON-driven multi-agent development framework with intelligent CLI orchestration (Gemini/Qwen/Codex), context-first architecture, and automated workflow execution

安装方式:

npm install -g claude-code-workflow
ccw install #安装工作流
ccw view #打开看板 

个人理解

无论 Skills 还是 Slash command 本质都是规范化的提示词，Skill 可以看作有标准结构文件结构的提示词组合。渐进式披露是一种设计思路，并不是 Skill 的机制，slash command 也可实现。在 Skill 没有出来之前，CCW 的工作流命令已经采用类似的设计机制，将一个复杂的工作流转为链式调用 command，以提升命令遵循度。对于长序列任务，例如 /workflow:plan 在上下文收集阶段只关注于上下文收集，产出内容再调用任务生成命令，而不是将上下文探索和生成命令写到一起。

编写 Skill 也会遇到 command 执行过程中上下文被挤爆的问题，压缩后可能遗忘内容，进而影响执行指令。根据前面开发经验，总结了一些设计技巧，创建了 Skill-generator 专门为复杂工作流生成的 meta-Skill。

如何使用 CCW 进行 Skill 设计

总结起来就是三步：

执行流程

步骤 1: CLI 分析

提示词输入：

可以在 ccw view 界面查看流式输出：

步骤 2: 完成后进行 Review

步骤 3: 进行 Agent 修复

SKill.md

---
name: review-code
description: Multi-dimensional code review with structured reports. Analyzes correctness, readability, performance, security, testing, and architecture. Triggers on "review code", "code review", "审查代码", "代码审查".
allowed-tools: Task, AskUserQuestion, Read, Write, Glob, Grep, Bash, mcp__ace-tool__search_context, mcp__ide__getDiagnostics
---

# Review Code

Multi-dimensional code review skill that analyzes code across 6 key dimensions and generates structured review reports with actionable recommendations.

## Architecture Overview

┌─────────────────────────────────────────────────────────────────┐
│  ⚠️ Phase 0: Specification Study (强制前置)                       │
│              → 阅读 specs/review-dimensions.md                   │
│              → 理解审查维度和问题分类标准                          │
└───────────────┬─────────────────────────────────────────────────┘
                ↓
┌─────────────────────────────────────────────────────────────────┐
│           Orchestrator (状态驱动决策)                             │
│           → 读取状态 → 选择审查动作 → 执行 → 更新状态              │
└───────────────┬─────────────────────────────────────────────────┘
                │
    ┌───────────┼───────────┬───────────┬───────────┐
    ↓           ↓           ↓           ↓           ↓
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Collect │ │ Quick   │ │ Deep    │ │ Report  │ │Complete │
│ Context │ │ Scan    │ │ Review  │ │ Generate│ │         │
└─────────┘ └─────────┘ └─────────┘ └─────────┘ └─────────┘
     ↓           ↓           ↓           ↓
┌─────────────────────────────────────────────────────────────────┐
│                     Review Dimensions                            │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐            │
│  │Correctness│ │Readability│ │Performance│ │ Security │            │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘            │
│  ┌──────────┐ ┌──────────┐                                       │
│  │ Testing  │ │Architecture│                                      │
│  └──────────┘ └──────────┘                                       │
└─────────────────────────────────────────────────────────────────┘


## Key Design Principles

1. **多维度审查**: 覆盖正确性、可读性、性能、安全性、测试覆盖、架构一致性六大维度
2. **分层执行**: 快速扫描识别高风险区域，深入审查聚焦关键问题
3. **结构化报告**: 按严重程度分类，提供文件位置和修复建议
4. **状态驱动**: 自主模式，根据审查进度动态选择下一步动作

---

## ⚠️ Mandatory Prerequisites (强制前置条件)

> **⛔ 禁止跳过**: 在执行任何审查操作之前，**必须**完整阅读以下文档。

### 规范文档 (必读)

| Document | Purpose | Priority |
|----------|---------|----------|
| [specs/review-dimensions.md](specs/review-dimensions.md) | 审查维度定义和检查点 | **P0 - 最高** |
| [specs/issue-classification.md](specs/issue-classification.md) | 问题分类和严重程度标准 | **P0 - 最高** |
| [specs/quality-standards.md](specs/quality-standards.md) | 审查质量标准 | P1 |

### 模板文件 (生成前必读)

| Document | Purpose |
|----------|---------|
| [templates/review-report.md](templates/review-report.md) | 审查报告模板 |
| [templates/issue-template.md](templates/issue-template.md) | 问题记录模板 |

---

## Execution Flow


┌─────────────────────────────────────────────────────────────────┐
│  Phase 0: Specification Study (强制前置 - 禁止跳过)               │
│  → Read: specs/review-dimensions.md                              │
│  → Read: specs/issue-classification.md                           │
│  → 理解审查标准和问题分类                                          │
├─────────────────────────────────────────────────────────────────┤
│  Action: collect-context                                         │
│  → 收集目标文件/目录                                               │
│  → 识别技术栈和语言                                                │
│  → Output: state.context (files, language, framework)            │
├─────────────────────────────────────────────────────────────────┤
│  Action: quick-scan                                              │
│  → 快速扫描整体结构                                                │
│  → 识别高风险区域                                                  │
│  → Output: state.risk_areas, state.scan_summary                  │
├─────────────────────────────────────────────────────────────────┤
│  Action: deep-review (per dimension)                             │
│  → 逐维度深入审查                                                  │
│  → 记录发现的问题                                                  │
│  → Output: state.findings[]                                      │
├─────────────────────────────────────────────────────────────────┤
│  Action: generate-report                                         │
│  → 汇总所有发现                                                    │
│  → 生成结构化报告                                                  │
│  → Output: review-report.md                                      │
├─────────────────────────────────────────────────────────────────┤
│  Action: complete                                                │
│  → 保存最终状态                                                    │
│  → 输出审查摘要                                                    │
└─────────────────────────────────────────────────────────────────┘


## Directory Setup


const timestamp = new Date().toISOString().slice(0,19).replace(/[-:T]/g, '');
const workDir = `.workflow/.scratchpad/review-code-${timestamp}`;

Bash(`mkdir -p "${workDir}"`);
Bash(`mkdir -p "${workDir}/findings"`);


## Output Structure


.workflow/.scratchpad/review-code-{timestamp}/
├── state.json                    # 审查状态
├── context.json                  # 目标上下文
├── findings/                     # 问题发现
│   ├── correctness.json
│   ├── readability.json
│   ├── performance.json
│   ├── security.json
│   ├── testing.json
│   └── architecture.json
└── review-report.md              # 最终审查报告


## Review Dimensions

| Dimension | Focus Areas | Key Checks |
|-----------|-------------|------------|
| **Correctness** | 逻辑正确性 | 边界条件、错误处理、null 检查 |
| **Readability** | 代码可读性 | 命名规范、函数长度、注释质量 |
| **Performance** | 性能效率 | 算法复杂度、I/O 优化、资源使用 |
| **Security** | 安全性 | 注入风险、敏感信息、权限控制 |
| **Testing** | 测试覆盖 | 测试充分性、边界覆盖、可维护性 |
| **Architecture** | 架构一致性 | 设计模式、分层结构、依赖管理 |

## Issue Severity Levels

| Level | Prefix | Description | Action Required |
|-------|--------|-------------|-----------------|
| **Critical** | [C] | 阻塞性问题，必须立即修复 | Must fix before merge |
| **High** | [H] | 重要问题，需要修复 | Should fix |
| **Medium** | [M] | 建议改进 | Consider fixing |
| **Low** | [L] | 可选优化 | Nice to have |
| **Info** | [I] | 信息性建议 | For reference |

## Reference Documents

| Document | Purpose |
|----------|---------|
| [phases/orchestrator.md](phases/orchestrator.md) | 审查编排器 |
| [phases/state-schema.md](phases/state-schema.md) | 状态结构定义 |
| [phases/actions/action-collect-context.md](phases/actions/action-collect-context.md) | 收集上下文 |
| [phases/actions/action-quick-scan.md](phases/actions/action-quick-scan.md) | 快速扫描 |
| [phases/actions/action-deep-review.md](phases/actions/action-deep-review.md) | 深入审查 |
| [phases/actions/action-generate-report.md](phases/actions/action-generate-report.md) | 生成报告 |
| [phases/actions/action-complete.md](phases/actions/action-complete.md) | 完成审查 |
| [specs/review-dimensions.md](specs/review-dimensions.md) | 审查维度规范 |
| [specs/issue-classification.md](specs/issue-classification.md) | 问题分类标准 |
| [specs/quality-standards.md](specs/quality-standards.md) | 质量标准 |
| [templates/review-report.md](templates/review-report.md) | 报告模板 |
| [templates/issue-template.md](templates/issue-template.md) | 问题模板 |

  review-code/
  ├── SKILL.md                  
  ├── phases/
  │   ├── orchestrator.md       # 编排器
  │   ├── state-schema.md       # 状态定义
  │   └── actions/
  │       ├── action-collect-context.md
  │       ├── action-quick-scan.md
  │       ├── action-deep-review.md
  │       ├── action-generate-report.md
  │       └── action-complete.md
  ├── specs/
  │   ├── review-dimensions.md  
  │   ├── issue-classification.md # 问题分类标准
  │   └── quality-standards.md  # 质量标准
  └── templates/
      ├── review-report.md      # 报告模板
      └── issue-template.md     # 问题模板 

总结

通过上述三个步骤生成一份规范化提示词。如需获得更优效果，需要观察执行过程，借助 cli 分析进行微调。

下贴预告

— 全文完 (采用 ccw text-formatter skill 进行格式化) —

前言

之前薅了某为云的 2c2g 鸡，一直吃着灰，反观我的另一台 1c1g 鸡跑了好几个服务，是时候迁移了，顺便也来试试传说中的 GitOps，做个步骤记录，欢迎佬们提提建议

迁移

首先在所有鸡上都安装上 docker

随后先是 Portainer 的迁移。

1. 在旧机器上：

   • 登录 Portainer Web 界面。

   • 进入 Settings → Backup。

   • 选择 Download backup file。

   • 设置个密码（可选），点击 Download。你会得到一个 .tar.gz 文件。

2. 在新机器上：

   • ssh 上去，拉起一个新的、空的 Portainer。

   • 第一次访问登录页面时，不要创建新管理员，点击下方的 Restore from file。

   • 上传刚才下载的备份文件，然后配置都回来了

然后是 docker 的容器部分。首先确认卷名，找到你真正需要的数据卷

docker volume ls # 找到后停掉
docker stop <容器ID>

打包

sudo -i
# 进入 Docker 卷目录 cd /var/lib/docker/volumes/ 
# 把你需要迁移的卷打包
tar -czvf /root/migration.tar.gz gpt_load-data newapi-data sub-store_data
# 直接 scp 扔过去 # 这里我尝试了 Termius 的 SFTP，估计是走本机中转，速度只有几十 k
scp /root/migration.tar.gz root@<IP>:/var/lib/docker/volumes/
# 在另一台机子上 sudo -i
cd /var/lib/docker/volumes/
tar -xzvf migration.tar.gz
# 让 docker 认出来
docker volume create gpt_load-data 
docker volume create newapi-data 
docker volume create sub-store_data

仓库配置

你需要把你的所有 docker-compose 文件组织起来，初始化 Git 仓库里并上传，这里以上传到 GitHub 为例。

文件结构仅供参考：

│  renovate.json
│          
├─ai
│      docker-compose.yml
│      
├─cloudflare-imgbed
│      docker-compose.yml
│      wrangler.toml
│      
├─network
│  │  docker-compose.yml
│  │  
│  ├─conf
│  │      Caddyfile
│  │      
│  └─site
├─nezha-dashboard
│      docker-compose.yml
│      
├─portainer
│      docker-compose.yml
│      
└─sub-store
        docker-compose.yml

接下来所有的容器相关操作都来到 Portainer 里面进行。

Portainer 配置

去 Portainer 创建 stack，Build method 选择到仓库类型，照着填就行

注意，如果你的 compose 文件里还依赖于仓库里的其他文件，比如 .env，那么得把下图中最下面的 Enable relative path volumes 勾上，Portainer 会从你填写的目录里把你的整个仓库拉下来再执行 compose 命令。

Re-pull image 这里我没有测试未勾选的效果，Force redeployment 的效果是每次 Webhook 触发时都会让容器重新部署，我这里没有勾选。

然后我们来到 GitHub 仓库里，填入对应 Webhook 地址，Payload URL 填 Portainer 给的， Content type 两种都可以。

完成后点 Update 就可以了。如果你之前给 Portainer 配置过 ZeroTrust，测试不通可能是 cf 那里没有配置 bypass 策略，得加个策略放行一下。

Note

如果后续要给 Portainer 配置多节点，记得在 cf 那里还要放行一个 api/endpoints

不出意外的话就可以了。

一些可能的报错

ErrorFailureCould not get the contents of the file '**/docker-compose.yml
检查 compose 文件是否有误，比如是否写了正确的镜像名

Renovate 配置

现在我们只是实现了代码即基础设施，上了一辆定制的电动车，但是不踩油门不动，每个镜像都要手动改镜像版本再 git push，太麻烦了。接下来我们将引入Renovate 机器人，实现自动更新镜像。

Warning

我也没用过 WatchTower，几种方法也没有孰好孰坏之分，这里不展开讨论

首先我们来把机器人安装到我们的仓库里，直达链接。添加到新仓库后会跳转到新页面来配置。这里没有许可证，选第二个免费版。

下一步，选择 Scan and Alert，这样子就会自动提 PR 了。

配置完成会跳转到个人主页，这里还能看到对应仓库的每一次触发日志

等一会仓库会自动收到一条来自机器人的 PR，类似于下图：

这条 PR 里会列出你的所有 compose 文件以及更新提示，可以直接 Merge，也可以顺手直接用下面配置覆盖。合并之后会多出一个 Dependency Dashboard 的 issue，可以在这里进行快速操作。

关于 renovate 的配置，建议仔细阅读一遍官方文档，这里放几个可能会用到的

• DevOps tooling
• AutoMerge
• 配置文件存放处
• Branch VS PR automerging

两条路

这里我让 Gemini 和 Claude 改了 2 份 renovate.json，第一份让机器人来管理合并的事，挂了快一周，实测小版本更新自动 commit 没有问题；第二份中 "platformAutomerge" 不填，默认为 true，托管给 GitHub 来管理自动合并。但是 GitHub 私人仓库的 AutoMerge 功能只对 Pro 用户开放，而且我死活调不出来，一个 PR 挂在那里一天了都没有触发自动合并，等一位大佬来帮我看看

作用是上游镜像推了个小更新，就自动 commit 掉，大版本更新提 PR 手动批准

可用配置

{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:recommended" ], "timezone": "Asia/Shanghai", "schedule": ["at any time"], "platformAutomerge": false, "automergeSchedule": ["at any time"], "ignoreTests": true, "packageRules": [ { "matchDatasources": ["docker"], "matchUpdateTypes": ["minor", "patch", "digest"], "automerge": true, "automergeType": "branch", "groupName": "all non-major docker updates" }, { "matchDatasources": ["docker"], "matchUpdateTypes": ["major"], "automerge": false, "addLabels": ["major-update-warning"] } ] } 

[未成功] GitHub Pro 用户配置

需要打开仓库设置里的 Allow auto-merge：

在我这里未生效，仅供参考

{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:recommended" ], "timezone": "Asia/Shanghai", "schedule": ["at any time"], "packageRules": [ { "matchDatasources": ["docker"], "matchUpdateTypes": ["minor", "patch", "digest"], "automerge": true, "groupName": "all non-major docker updates" }, { "matchDatasources": ["docker"], "matchUpdateTypes": ["major"], "automerge": false, "addLabels": ["major-update-warning"] } ] } 

后记

修改完文件记得跑一下下方的检查命令：

npx --yes --package renovate -- renovate-config-validator renovate.json 

实测 bunx 不可用：

"err": { "code": "MODULE_NOT_FOUND", 

如果忘了也没关系，机器人会在 issue 里报错

要是没啥问题，机器人就能自动干活了：

Baichuan-M3 是百川智能的新一代医疗强化大型语言模型，是继 Baichuan-M2 之后的一项重要里程碑。

与以往主要侧重静态问答或表面化角色扮演的方法不同，Baichuan-M3 被训练为显式建模临床决策过程，旨在提高在真实医疗实践中的可用性和可靠性。模型不仅仅生成 “听起来合理” 的答案或诸如 “你应尽快就医” 之类的高频模糊建议，而是被训练为主动获取关键临床信息、构建连贯的医疗推理路径，并系统性地约束易产生幻觉的行为。

核心亮点

• 超越 GPT-5.2：在 HealthBench、HealthBench-Hard、幻觉评估和 SCAN-bench 上均优于 OpenAI 的最新模型，确立了医疗 AI 的新 SOTA（最佳水平）
• 高保真临床询问：在 SCAN-bench 的三个维度 —— 临床询问、化验检测和诊断 —— 中唯一排名第一的模型
• 低幻觉、高可靠性：通过 Fact-Aware 强化学习实现比 GPT-5.2 更低的幻觉率，即使在未使用外部工具的情况下也能保持高可靠性
  
  
  
  
  

与 Baichuan-M2 相比，Baichuan-M3 在 HealthBench-Hard 上提升了 28 个百分点，达到 44.4%，并且超过了 GPT-5.2。它在 HealthBench 总榜上也排名第一。
在幻觉评估方面，我们将长篇回答拆解为可细化、可验证的原子医学陈述，并将每一条与权威医学证据进行校验。即便在无外部工具的情况下，Baichuan-M3 的幻觉率仍低于 GPT-5.2。

Baichuan-M3 在所有三个核心维度中均排名第一，在 “临床询问” 维度上领先第二名 12.4 个百分点。

体验地址

用了 openwebui 大半年了。从一开始的毛胚房到现在的精装修。踩了很多坑，也一步步的看着 openwebui 更强大更好用。我把我理解的各项功能的好用配置分享给大家交流一下

安装

我是在群晖上通过 docker 方式安装的

docker image prune
docker pull ghcr.io/open-webui/open-webui:main
docker pull ghcr.io/open-webui/mcpo:main

除了端口设置外就只有一个文件夹挂载，这是所有用户数据了。我更新的方式都是通过重置这个容器来升级。

本来是没有第一行的。直到我 200G 系统盘因此被占满 ……

添加模型服务器

通过管理员设置 - 外部链接 - 加号 - 把供应商的域名和 apikey 填进来就可以了

他默认会把所有的模型都以私有的方式给你添加到 owu 来。你可以选择禁用某些用不到的模型，让他们不在可选列表里面出现（比如 rag 相关的重拍、向量化模型），也可以用过将私有转公开的方式让其他用户可以使用该模型。最简单也可以通过环境变量 BYPASS_MODEL_ACCESS_CONTROL=True 来放开所有模型，不用单独设置。

我比较喜欢我的小房子 我去 cherrystudio 偷了一些图标美化我的小房子～

可以在管理员设置 - 模型 - 编辑单个模型去上传图标。

函数

我本地的函数比较简单。就配置了联网搜索以及本地事件的补充，告诉 ai 当前时间

当前时间的话如下。

"""
title: Message Date And Time
author: benasraudys
author_url: https://github.com/benasraudys
funding_url: https://github.com/benasraudys
description: Gives model current date and time context for each message. Don't forget to adjust the timezone in the settings.
version: 0.1.1
required_open_webui_version: 0.6.4
"""

import datetime
import os
from pydantic import BaseModel, Field
from typing import Callable, Awaitable, Any, Optional


class Filter:
    class Valves(BaseModel):
        timezone_hours: int = Field(
            default=0,
            description="Timezone offset hours (e.g., 5 for UTC+5:30, -4 for UTC-4:00)",
        )
        timezone_minutes: int = Field(
            default=0,
            description="Timezone offset minutes (e.g., 30 for UTC+5:30, 45 for UTC-4:45)",
        )
        southern_hemisphere: bool = Field(
            default=False,
            description="Enable if you're in the Southern Hemisphere (Australia, South America, etc.)",
        )

    def __init__(self):
        self.valves = self.Valves(
            **{
                "timezone_hours": int(os.getenv("DATETIME_TIMEZONE_HOURS", "0")),
                "timezone_minutes": int(os.getenv("DATETIME_TIMEZONE_MINUTES", "0")),
                "southern_hemisphere": os.getenv(
                    "DATETIME_SOUTHERN_HEMISPHERE", "false"
                ).lower()
                == "true",
            }
        )

    def get_season(self, month, southern_hemisphere=False):
        if not southern_hemisphere:
            if 3 <= month <= 5:
                return "Spring"
            elif 6 <= month <= 8:
                return "Summer"
            elif 9 <= month <= 11:
                return "Autumn"
            else:
                return "Winter"
        else:
            if 3 <= month <= 5:
                return "Autumn"
            elif 6 <= month <= 8:
                return "Winter"
            elif 9 <= month <= 11:
                return "Spring"
            else:
                return "Summer"

    def get_time_of_day(self, hour):
        if 5 <= hour < 12:
            return "Morning"
        elif 12 <= hour < 17:
            return "Afternoon"
        elif 17 <= hour < 21:
            return "Evening"
        else:
            return "Night"

    async def inlet(
        self,
        body: dict,
        __event_emitter__: Callable[[Any], Awaitable[None]],
        __request__: Any,
        __user__: Optional[dict] = None,
        __model__: Optional[dict] = None,
    ) -> dict:
        now_utc = datetime.datetime.utcnow()

        timezone_hours = self.valves.timezone_hours
        timezone_minutes = self.valves.timezone_minutes
        total_offset_minutes = (timezone_hours * 60) + timezone_minutes

        now = now_utc + datetime.timedelta(minutes=total_offset_minutes)

        month = now.month
        hour = now.hour

        formatted_date = now.strftime("%B %d, %Y")
        formatted_time = now.strftime("%H:%M:%S")
        day_of_week = now.strftime("%A")

        hours_offset = abs(total_offset_minutes) // 60
        minutes_offset = abs(total_offset_minutes) % 60

        if minutes_offset == 0:
            if total_offset_minutes >= 0:
                timezone_str = f"UTC+{hours_offset}"
            else:
                timezone_str = f"UTC-{hours_offset}"
        else:
            if total_offset_minutes >= 0:
                timezone_str = f"UTC+{hours_offset}:{minutes_offset:02d}"
            else:
                timezone_str = f"UTC-{hours_offset}:{minutes_offset:02d}"

        season = self.get_season(month, self.valves.southern_hemisphere)
        time_of_day = self.get_time_of_day(hour)

        context = f"Current date is {day_of_week}, {formatted_date}, {season}, {time_of_day}, the user time is {formatted_time} {timezone_str}"

        datetime_message = {
            "role": "system",
            "content": f"Time context: {context}. ",
        }

        if "messages" in body and isinstance(body["messages"], list):
            body["messages"].insert(0, datetime_message)
        else:
            body["messages"] = [datetime_message]

        return body

联网搜索的话主要是基于各家模型自己的能力（大概也就是在消息接口参数里面注入模型对应的工具，但是一般都要额外付费，所以我现在基本不用了） 我了解到的，gemini 有这样的函数配置，以及 openai 流式接口也有。这个可以站内查对应工具直接使用。函数认准方块佬就对了。加个方块，搜索更快！

两个工具结合就能达到以下示例的效果

外部工具

这里主要是提供 mcp 的能力 说实话挺难用的。但是我刚好联网搜索走其他方式都有些不好用。我目前是通过 mcp 的方式来实现的。

部署 mcpo

我通过在本地 docker 部署 mcpo，镜像地址在一开始应该已经准备好了。

我群晖这边的部署操作主要是配置了端口为 38000 以及启动命令

mcpo --config /app/mcp-config.json --hot-reload

然后通过文件挂载 /app/mcp-config.json 这个配置文件

文件内容可以参考下面这个

{
    "mcpServers": {
      "grok-search": {
	      "type": "stdio",
	      "command": "npx",
	      "args": ["-y", "grok-search-mcp"],
	      "env": {
	        "GROK_API_URL": "https://-----/v1",
	        "GROK_API_KEY": "-----",
	        "GROK_MODEL": "grok-4-fast",
	        "DEBUG": "true"
	      }
      }
    }
  }

然后我们就可以直接访问 38000 这个端口就可以看到 json 返回了 也能知道你哪些工具启动成功了。

我们就能去管理员设置 - 外部工具 - 加号 新增工具服务器了

在配置完成之后我们可以在对话界面去勾选这个工具 对他进行一些询问。示例如下

当然你可能觉得每一次点都好费劲，当然我们也可以到 管理员设置 - 模型 - 对应模型去默认启动某些工具或其他功能

知识库

知识库我用的其实不多。但是我觉得效果还是不错的。就是遇到这个坑导致 rag 检索不符合预期

内容提取

首先提取引擎我推荐 mistral (主要可以白嫖) 效果也不错 我用过自部署的 tika。有些中文 pdf 会乱码 这个挺好的。但是我还是建议如果可以自己转 md 把

嵌入和检索

这一块我也是跟着 ai 配的。效果还是不错的。

上传合适的文档，结果也能够图文并茂

辅助功能

在管理员设置 - 界面 - 任务这边可以配置一些异步的小任务是否使用 ai 生成

我就开了这个标题自动生成（效果图如左上角），openai 每天免费的 nano 用不完就来这边干点活吧。有标题了也方便你到时候快速查询历史的对话。

图片生成

目前我觉得 owu 做的这个功能比较死板（主要问题是只能填入一个模型）

我有个朋友部署好了 comfy，等给我之后这边估计Pro 就要从对话模型里面选了。

通过这种方式配置好的话 体验和 openai 就很像了。对话勾选一下画图。描述需求就好了

画图也踩过一些坑，比如分享一个 openwebui 中生图模型 chunk too big 问题的解决办法 。里面也有其他佬遇到的其他坑和他们的解决方式。L 站真的是我见过 ai 相关信息最快的一个站了。在站内搜不到，我估计谷歌也搜不到

结语

以上就是我的配置心得。希望我的分享能给你一些启发，也欢迎大家交流各自的 “装修方案”。

替换 antigravity 里面的一个文件，重启即可使用.

版本更新

1.2.1: 修复了 mermaid 提前渲染导致的截断问题.
1.2.0: 新增 Mermaid 流程图渲染功能
1.1.0: 来自 github 社区的提交，增加了 LaTeX 公式的渲染支持，增加了悬浮复制按钮，重构了代码.

1.0.0: 表格颜色增强，增加回复内容一键复制按钮.

图片展示:

1.2.0

原版 mermaid 图

增强渲染版 mermaid 图

1.1.0

原版公式

增强渲染版公式

1.0.0

初版展示效果

复制代码块格式的增强

刚刚在推上看到的
ymcki 给 Kimi-Linear-48B-A3B 加上了 MLA KV cache
实测下来 1M 上下文 F16 KV cache 显存占用从 140G 降到 15G。
如果显存少一点的用户可以选择（with KV Quant )

• q8_0: 7.9GB
• q5_1: 5.6GB
• q4_0: 4.2GB
  有兴趣可以玩看看

Kimi-Linear-48B 的效果

接上回：Zotero 全面学习指南（黑板报画风）

今天是第二期，本期视频采用水彩画风教学，主要为科研小白扫除一些障碍，希望佬友们喜欢。研究生院官网已同步更新。

特此鸣谢佬友 @555hai 的大力支持！！！
直达链接：

后续规划内容已在路上，敬请期待：