小模型

​​​​​​​​​​​​​​​​​​​​​​​喜加一 | EPIC 限免（12.27）第十弹​

本期礼物

We Were Here Together「我们曾一起在这里」

注：游戏截止！12.28，00:00

链接：
官网
即时结账

前言

一句话总结：将重计算从 Worker 卸载到 DO 中。

我见网络上有零星的讨论提到可以将 CPU 任务卸载到 DO 中，但没找到一篇详细介绍的教程（也可能是我太火星了），官方文档里也没有类似的建议，能查到的主流用法都是维持 ws 长连接。我又问了一圈 AI，也没找到什么有价值的线索，它们给出的回答也不一致（甚至前后不一致），故来水一帖。

目前把帖子放 1 级是暂时防止 AI 爬到，看看佬友们有没有更好的向 AI 提问或是搜索方法。

为什么 Duration Object 可以缓解 CPU 时间限制

什么是 Duration Object

根据官方文档 What are Durable Objects?，原文如下：

A Durable Object is a special kind of Cloudflare Worker which uniquely combines compute with storage. Like a Worker, a Durable Object is automatically provisioned geographically close to where it is first requested, starts up quickly when needed, and shuts down when idle. You can have millions of them around the world. However, unlike regular Workers:

• Each Durable Object has a globally-unique name, which allows you to send requests to a specific object from anywhere in the world. Thus, a Durable Object can be used to coordinate between multiple clients who need to work together.
• Each Durable Object has some durable storage attached. Since this storage lives together with the object, it is strongly consistent yet fast to access.

Therefore, Durable Objects enable stateful serverless applications.

我的英语水平太过于塑料，就不翻译了，简单画一下重点：

• Worker 能跑的代码 DO 基本也能跑
• DO 是根据名称（id）来区分实例的，可以单例串行（多 Worker 共享）也可以多个实例并行
• DO 是直接有存储、有状态的

DO 是有状态的这一核心特征我们用不上，我们接着往下看文档。

计费与限制

Duration Object 的计费主要围绕计算和存储展开，计算部分的额度与计费规则如下：

其中有两条脚注需要特别注意：

4 Duration is billed in wall-clock time as long as the Object is active, but is shared across all requests active on an Object at once. Calling accept() on a WebSocket in an Object will incur duration charges for the entire time the WebSocket is connected. It is recommended to use the WebSocket Hibernation API to avoid incurring duration charges once all event handlers finish running. For a complete explanation, refer to When does a Durable Object incur duration charges?.

Limits 怎么说:

这里的 active CPU time 就是指的 CPU 时间，居然没有单独限制免费计划？！

我们再来跟 Worker 的限制对比一下：

看起来，虽然 Worker 对免费计划有单独的 10ms 限制，但 DO 却没有，那理论上所有请求都用 DO 处理请求的话，平均 CPU 时间可以到 1.04s？这… 这对吗？

对不对一试便知

剧透一下，对的，从这里开始就是教程了

从一个最简单的 Demo 开始

我们来实现一个最简单的处理 HTTP 请求的 DO 试试。

定义 Durable Object 类

// src/index.ts import { DurableObject } from 'cloudflare:workers' // 1. 定义 DO 类，必须 export export class MyDurableObject extends DurableObject<Env> {
  constructor(ctx: DurableObjectState, env: Env) {
    super(ctx, env);
  }

  // 2. 必须实现 fetch 方法，处理发给这个 DO 的请求 async fetch(request: Request): Promise<Response> {
    // 在这里执行 CPU 密集型操作 const result = await this.heavyComputation();
    return Response.json({ result });
  }

  private async heavyComputation(): Promise<string> {
    // 你的 CPU 密集型逻辑 return "done";
  }
}

在 wrangler.toml 中绑定

name = "do-cpu-test" main = "src/index.ts" compatibility_date = "2024-01-01" # 声明 Durable Object 绑定 [durable_objects] bindings = [
{ name = "MY_DO", class_name = "MyDurableObject" }
]

# 声明 DO 类的迁移（首次部署必须，免费计划只能使用 SQLite） [[migrations]] tag = "v1" new_sqlite_classes = ["MyDurableObject"]

定义 Env 类型

interface Env {
  MY_DO: DurableObjectNamespace;
  // 其他绑定...
}

从 Worker 调用 DO

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // 获取 DO 实例的 stub const id = env.MY_DO.idFromName("singleton");
    const stub = env.MY_DO.get(id);

    // 把请求转发给 DO return stub.fetch(request);
  }
};

串行复用与并行处理

还记得之前说过 DO 是通过名称（id）来识别实例的么？我们可以通过传递 id 来选择是否创建新的实例。刚才的代码中名称固定是 "singleton"，这样每次获取的都是同一个实例，一次只能处理一个请求，这在高并发下会排队，不过优势是可在 DO 内部维护状态（本文用不到）。

如果想并行处理：

每次请求都创建一个新的实例

可以直接使用 newUniqueId() 创建新 id。

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    // newUniqueId() 每次返回全新的实例 const id = env.MY_DO.newUniqueId();
    const stub = env.MY_DO.get(id);
    return stub.fetch(request);
  }
};

按需区分（如请求参数、用户 id）

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    // 用 URL 参数作为实例名称 const instanceName = url.searchParams.get("name") || "default";

    const id = env.MY_DO.idFromName(instanceName);
    const stub = env.MY_DO.get(id);
    return stub.fetch(request);
  }
};

完整的示例

这里我实现了两个端点，分别在 Worker 和 DO 中执行 PBKDF2 迭代，来模拟实际 CPU 密集任务。
用法如下：

# Worker 内执行（很快会撞 CPU 限制）
curl "https://your-worker.workers.dev/worker/pbkdf2?iters=100000&reps=100" # DO 内执行（可以随便跑，reps拉倒1000都行）
curl "https://your-worker.workers.dev/do/pbkdf2?iters=100000&reps=100&name=bench" 

wrangler.toml

name = "do-cpu-test" main = "src/index.ts" compatibility_date = "2025-12-25" [durable_objects] bindings = [
  { name = "CPU_DO", class_name = "CpuDo" }
]

[[migrations]] tag = "v1" new_sqlite_classes = ["CpuDo"]

src/index.ts

/// <reference types="@cloudflare/workers-types" /> import { DurableObject } from 'cloudflare:workers' export interface Env {
  CPU_DO: DurableObjectNamespace;
}

// ============ 工具函数：PBKDF2 烧 CPU ============ async function burnCpu(iters: number, reps: number) {
  const password = "benchmark-password";
  const salt = crypto.getRandomValues(new Uint8Array(16));
  const enc = new TextEncoder();

  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    enc.encode(password),
    "PBKDF2",
    false,
    ["deriveBits"]
  );

  const t0 = performance.now();
  let lastHash = "";

  for (let r = 0; r < reps; r++) {
    const bits = await crypto.subtle.deriveBits(
      {
        name: "PBKDF2",
        salt,
        iterations: iters,
        hash: "SHA-256",
      },
      keyMaterial,
      256
    );
    lastHash = [...new Uint8Array(bits)]
      .map((b) => b.toString(16).padStart(2, "0"))
      .join("");
  }

  return {
    params: { iters, reps, totalIterations: iters * reps },
    timing: { wallMs: Math.round(performance.now() - t0) },
    output: lastHash,
  };
}

// ============ Durable Object 类 ============ export class CpuDO extends DurableObject<Env> {
  constructor(ctx: DurableObjectState,

    env: Env) {
    super(ctx, env);
  }

  async fetch(request: Request): Promise<Response> {
    const url = new URL(request.url);
    const iters = Math.min(parseInt(url.searchParams.get("iters") || "100000"), 100000);
    const reps = Math.min(parseInt(url.searchParams.get("reps") || "1"), 1000);

    const result = await burnCpu(iters, reps);
    return Response.json({
      executor: "DurableObject",
      instanceId: this.ctx.id.toString(),
      ...result,
    });
  }
}

// ============ Worker 入口 ============ export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    const path = url.pathname;

    // 路由：Worker 内执行 if (path === "/worker/pbkdf2") {
      const iters = Math.min(parseInt(url.searchParams.get("iters") || "100000"), 100000);
      const reps = Math.min(parseInt(url.searchParams.get("reps") || "1"), 1000);
      const result = await burnCpu(iters, reps);
      return Response.json({ executor: "Worker", ...result });
    }

    // 路由：DO 内执行 if (path === "/do/pbkdf2") {
      const name = url.searchParams.get("name") || "default";
      const id = env.CPU_DO.idFromName(name);
      const stub = env.CPU_DO.get(id);
      return stub.fetch(request);
    }

    return Response.json({
      endpoints: {
        "/worker/pbkdf2?iters=N&reps=M": "在 Worker 内执行（受 10ms CPU 限制）",
        "/do/pbkdf2?iters=N&reps=M&name=X": "在 DO 内执行（按 Duration 计费）",
      },
    });
  },
};

package.json

{ "name": "do-cpu-test", "scripts": { "dev": "wrangler dev", "dev:remote": "wrangler dev --remote", "deploy": "wrangler deploy" }, "devDependencies": { "@cloudflare/workers-types": "^4.20251201.0", "typescript": "^5.7.3", "wrangler": "^4.34.0" } } 

测试结果

我直接把 reps 拉到 1000，除了玄学 1101 外没遇到别的限制。

这个 CPU 时间是 free plan 的 Worker 跑到冒烟都跑不出来的。

结论

现在可以回答开头的问题了：这对，DO 真的是 30s CPU 时间，只是 DO 还可能会受一些别的限制，比如释放不及时、同一台物理机上的 DO 会共用 128M 内存、创建 DO 和往返需要额外挂钟时间等。

现在我们来通俗的总结一下免费计划中 Worker 和 DO 的区别，这就像是占着茅
还是文雅的总结一下好了，这就像是在一家会员制餐厅里：

• Worker 是点餐的：点了多少才能吃多少（CPU 时间限制），但是这个座位想占多久占多久（挂钟时间不限制）
• Durable Object 是吃自助餐的：按座位数 × 时间算钱，但占着座位的时候可以一直猛猛吃。

无脑 DO 不可取，但适当利用可以极大拓展免费版 Worker 的可能，比如可以采用自实现的高迭代次数的密码 hash、解析大体积 JSON… 不知各位在用 Worker 构建项目时是否也遇到了 CPU 时间限制的困扰呢？也许 DO 就是你项目的最后一块拼图。

附言

这里我贴上各家 AI 对「DO 能否绕过 Worker 的 10ms 限制，是否有人这么尝试」的回答。
prompt：

CloseAI (gpt-5.2 Extended)

原回答很长，仅节选信息提取部分

评价：答案正确，信息来源提取无关，这两个都是后台任务，前者没用到 DO，后者更是非 CPU 密集任务，个人会将其评价为无效回答。

Gemini （3 Pro）

刚好测试的时候出 AB Test 了，我就截全了。

评价：回答正确，但是没有提供能立即验证的实际来源，也不知道到底有没有搜到正确的信息。右边算无效回答，不过左边直接给出 test 好评，个人将其评价为需要一点时间验证的有效回答。

Grok （免费版 Expert）

评价：搜索无敌，思考左右脑互搏，回答错误，这很 Grok。红框处的推明确提到可以用 DO 来 offload compute，你真就不自我怀疑一下的么… 评价为有用的错误回答。

Perplexity (gpt-5.2-thinking + 搜索更多来源提示词)

评价：居然回答正确且来源正确。虽然 Markus Ast 的文章主要在说 ws 集成，跟 CPU 密集型任务的时间限制关系不大，但 git-on-cloudflare 里真的提到了：

• Time-budgeted unpacking keeps pushes under 30s CPU limit

以及

• 30s CPU limit per request on the main fetch paths (unpack runs in alarm-driven slices)

这个结果出乎我意料，其他家的 AI 试了好几次都搜不到啥有用信息。

Cursor （gpt-5.2 xhigh）

Cursor 的 prompt 不同，我是直接贴出当前项目中的两个有性能瓶颈的端点，让它分析能否用 DO 解决。

评价：路边一条。中间思维链中明明发现了信息又冲突，但它都不愿意自我怀疑一下，我也不知道官方文档里什么东西干扰它的判断了… 而且我开的是 Agent 模式，为啥这么不愿意写一个 test 呢…

一个驱动 Claude Code 拆解开源项目的提示词，会在项目里查找所有的提示词，进行分析和翻译，最终输出一份项目拆解报告文档和一组提示词翻译文档。

项目拆解报告会包含项目数据流时序图、基于提示词分析的模型应用场景，以及项目为模型提供的工具几个维度。

如何使用

For Claude Code

1. 在 ~/.claude 路径下创建 commands 文件
2. 下载 howPrompt.md 保存到 commands 文件中
3. 重启 Claude Code，使用 /howPrompt 指令即可直接激活使用

For Cursor

1. 在 ~/.cursor 路径下创建 commands 文件
2. 下载 howPrompt.md 保存到 commands 文件中
3. 在任意项目使用 /howPrompt 指令即可直接激活使用

佬们好，最近在工作的时候需要使用 mqtt，然后调试的时候来回复制粘贴有点麻了，于是 vibe 了一个 mqtt 客户端，可以发送快捷指令，导入导出配置，方便多设备调试，这是我的第一个开源项目，大佬们多多包涵。

GitHub 项目地址：GitHub - HaxIOX/northrealm-mqtt: Northrealm (NR) — MQTT debugger / MQTT client (Web + Windows Desktop).
web 端：Northrealm MQTT

目前支持 Web 端 与 Windows 桌面端（Electron） ，后续计划扩展 移动端

亮点功能

• 配置导出 / 导入 ：快速备份与迁移多套 Broker / 连接参数
• 快捷指令 ：一键发送常用消息 / 主题组合，减少反复复制粘贴
• 排障友好日志与诊断提示 ：连接过程更直观，便于定位认证 / ClientID / 协议等问题

演示图

订阅用户在指定编程工具中接入 GLM Coding Plan，并配置 MCP，并输入口令，即可获得一张沪上阿姨新品奶茶兑换券，并通过沪上阿姨官方小程序完成兑换。

小程序链接：t.hsay.com/qf7TZX

官方配置原文：“阿姨助我” 奶茶领取说明 - 智谱 AI 开放文档

通用 mcp 配置：

 { "mcpServers": { "milk-tea": { "type": "streamableHttp", "url": "https://open.bigmodel.cn/api/mcp/milk_tea/mcp", "headers": { "Authorization": "Bearer your_api_key" } } } } 

cc 配置：

claude mcp add -s user -t http milk-tea https://open.bigmodel.cn/api/mcp/milk_tea/mcp --header "Authorization: Bearer your_api_key"

srs 是 sing-box 独有的规则集二进制缓存格式，由 json 文件编译而来。
如何方便快捷处理规则集的编辑和 srs 格式生成呢？我搞了这么个仓库：

借助 github action，只要编辑 json 文件内容，保存后自动生成 srs 格式。
给需要的佬友。

https://www.canva.com/brand/join?token=-CTmxgYpoF6OyM8TGOejRw&brandingVariant=edu&referrer=team-invite

還不快加入

https://www.canva.com/brand/join?token=HLL38YVS_p8wY5YHk6Ej8g&brandingVariant=edu&invitationDestinationType=group

标题

开源一个高颜值壁纸站：干净无广告，支持 4K 下载，已上线！

正文

大家好！最近做了一个自己日常在用的高清壁纸网站 —— Wallpaper Gallery，目前已部署上线，也已在 GitHub 开源，欢迎体验或 Star

在线访问：https://wallpaper.061129.xyz
GitHub 项目：https://github.com/IT-NuanxinPro/wallpaper-gallery

为什么值得试试？

市面上很多壁纸站充斥广告、加载慢、甚至无法下载原图。我希望能做一个 简洁、快速、尊重用户 的替代品 ——

• 真・4K 原图一键下载（无压缩、无水印）
• 智能适配设备：
  
  • 电脑访问 → 展示 16:10 电脑壁纸 + 头像
  • 手机访问 → 自动切换为 9:16 手机壁纸 + 头像
• 三种视图自由切换：网格 / 列表 / 瀑布流，切换时有流畅动画过渡
• 暗黑 / 亮色主题：自动跟随系统设置
• 每日精选推荐（PC 端首页）
• 完全静态站点，无广告、无追踪、加载快

所有图片均来自公开渠道整理，仅用于个人欣赏，版权归原作者所有。

如何支持？

如果你觉得这个小站还不错：

• 欢迎直接使用 https://wallpaper.061129.xyz
• 或去 GitHub 点个 Star 鼓励一下开源项目！

也欢迎提建议或贡献内容（比如推荐高质量壁纸源）～

感谢阅读，希望它也能成为你换壁纸的新选择

背景

从 24 年开始，LLM 从简单的文本对话向具备感知、规划、工具使用和自主行动能力的方向发展（关键词 React、Plan And Action），测试的核心痛点是模型的不确定性、技能的稳定性、行为的可控性。由于各种模型幻觉、rag 检索、工具使用、CoT 质量等等 span 的划分，传统的测试方法面临失效（注意 Tool、Mcp 的开发不在失效范围内）。在这种背景下应运而生一种全新职业，Agent 测评工程师。

测试崩塌

传统测试

在过去我们工作经验中，测试是质量保障，建立在确定性的基础上。无论是我们的单元测试、集成测试，都是输入 A 出 B 才适合功能正常，任何其他输出都是 Bug。但是 Ai Agent 的大脑 llm 天生就是概率性的系统。
这就导致传统测试以下问题：

1. 非确定性的输出，不是输入 A（Prompt）就会出现 B，而是可能出现完全不同的推理路径，比如输入 hello，传统就是 hello xxx。但是 agent 可能推理用户什么输入 hello，他想干什么，从而输出 hello​，或者 hello 我是 xxxx（自我介绍）
2. 测试覆盖度，传统的软件空间是有限的，你可以使用脚本或者人力枚举所有的测试案例，但是面对 agent 输入的是自然语言，输入就是无穷的。
3. 任务失败归因，当你的 agent 没有按照你的预期完成任务的时候，正常人是很难判定到底是模型能力不行、Rag 不行、Prompt 不行还是中间出现了异常情况 (网络、磁盘、工具等等)

信任问题

当 agent 出现一次离谱的操作的时候，你就会对其产生极度的不信任感，这种不信任感来自于对信息输入源、加工过程的黑盒问题，以及人类自身的能力边界，无法证伪但是我觉得不对。

简述

Agent 测评工作就是讲不确定性转变为可度量、可量化、可反馈的可靠性工程。

Agent 测试

测试集

代码

SWE-Bench 不容置疑，都用这个来跑 code agent 的能力，也是权威的测试基准之一。他不是建的算法题、一个功能实现，而是从 github 上的流行仓库中去收录 issue 和 pr。
测试方法通常包括：
issue（人类提出的问题）
pr（修复代码，金标答案）
test（fail to pass 测试用例）
测试过程：
注入 Prompt - llm - reasoning - plan - tool - llm 循环，过程中需要对每个节点继续观测，例如时间、轮数、决策、工具调用、Cot、结果。最后调用 test 用例测试修复效效果。
高阶一点的还要回归验证，如果太多还要通过 ast 找到代码修改后影响的功能，只对影响的进行回归。这里 pass@10 说一下，测试十次有一次通过就算通过，测试的是上限能力、探索能力、自我修正潜力，难度较低。
输出：
测试报告，dpo、sft 数据集（辅助 agent、模型成长）

通用

GAIA 测试的是 agent 的解决现实世界的能力，例如去淘宝买个低价 key。对于人来说很简单，但是对于 agent 来说需要复杂的工具使用、多模态理解和步骤规划。
测试方法：
Prompt（概念简单但步骤复杂，现实问题）
Mock (可以理解为一个测试淘宝站点，你不可能让 agent 真去买)
测试过程:
同代码雷同，但是这里会产生非结构化数据，比如录屏、截图（判断哪个步骤失败关键证据），最后以结果为导向，比如 mock 的数据库中数量 - 1（而不是 agent 说购买成功就行的）
输出：
同上

综合

AgentBench，涵盖 OS、DB、KG、卡牌游戏等不同的环境。

垂直

BFCL 专门测试模型函数调用的准确性，主要测试参数提取、格式对齐等能力。测试可以不真正调用，只要比对调用 json 与说明文档是否一致（不能多也不能少，还得对）

跑分

经过上面的说明，应该可以悟道为什么分高能低了吧。什么你不知道？

当指标成为目标

1. 数据污染，由于上面说的测试集是公开集，那么模型训练数据甚至微调数据中可能就包含了测试题答案。那么这就是开卷考试了直接背答案而不是推理。那么遇见真是场景要推理的时候，完犊子了
2. 针对性特训，为了刷榜写特定的 Prompt 或者启发式规则来迎合测试。

测试环境与现实的错误

1. 基准测试都是在温室里面进行的，环境干净、网络稳定、权限全开，但是真实环境充满了，不稳定的 api、复杂的权限、屎山的各种奇怪约束
   
   
2. 现实问题往往都是机械的多步的复杂的，误差会出现累积现象，每一个步骤都是 98% 成功，那么 50 个步骤呢？只有区区的 36%

评估的局限性

1. 许多基准只看最终结果，例如我刚刚说的 swe-bench 你修好了一个 bug，引入了 10 个 bug，然后原来的功能凉了。还有例如，\tau$\tau$-bench 的评估脚本存在漏洞，导致一个 “什么都不做” 的 Agent 竟然能获得 38% 的通过率，仅仅因为测试脚本未能正确检测空操作。
2. 缺乏过程监控，上面的测试集我都提到了，一个功能消耗 100k token 和 10 轮解决，与消耗 20k 和 15 轮解决你选哪个？还有为了解决 bug 把功能删了是不是修好了？
3. 还有的甚至都不开发 mock，就像我上面说的，直接信任 agent 输出。

职责、框架、标准

这一篇不讲评测平台架构设计、模块开发、三高实现

初、中级

关键字：数据清洗、脚本、Case
执行评测任务，维护评测数据集，编写自动化测评脚本，对 bad case 继续标注归因分析。

高级、专家

构建平台体系，搭建评测框架，仿真环境搭建、过程数据采集（平台级别）、算法优化、红队测试（安全不要遗忘）

核心技能树

1. Ai 与大模型原理（不掌握就找不到问题，只知道不行）
2. 代码工程能力（python）
3. 数据分析（统计学、归因）
4. 评估框架与工具掌握（实现、原理、使用）

晋升

纵向

测试 - 测开 - 转型（+AI）- 工程师 - 架构师 / 专家

横向

Agent Ops/MLOps、Ai 安全专家

未来

• 人评到智评，会出现 Agent 判官作为专家辅助测评。可能测评工程师后面就是 "训练裁判"，而不是亲自当裁判。
• 生成式社会模拟，把被测 agent 直接扔到一个 agent 社会里面，多智能体的高度延伸
• 安全与合规，目前从我的角度来看，都是裸奔没有什么安全可言。所以 Ai 安全专家也是安全转行的一个点（目前感觉都还在摸索 AI 安全的方向），Agent 跑不出软件的概念，传统安全可以涵盖但不是 AI 安全我认为。

目前各个企业都还是热衷于搞自己的 agent，虽然社会上已经有这么多的 agent。Agent 不断的发展也会带来测评的改变，引用 2 张图：

结束

仅供扫盲，讲讲一些通俗易懂的点

最近在搓一个天气相关的项目，结果发现 Dify 上居然还没有一个够用且全面的天气插件，每次都得用 HTTP 请求节点自己拼参数
想了想不如自己整一个（谁不喜欢拖拖拽拽就完事了呢

所以写了一个和风天气的 Dify 插件，整体不做多余逻辑，直接转发和风天气 API

目前已实现：

• 20 个工具，覆盖天气、地理、天文、空气质量等 7 大类
• 支持实时天气、3-30 天预报、逐小时预报
• 全球城市 / POI 搜索、天文数据（日出日落、月相）
• 空气质量监测、天气预警
• 分钟级降水预报（国内）

已经上架 Dify 官方 Marketplace 可以直接搜 QWeather 安装，或者用下面链接。

Github:

Dify Marketplace:

欢迎各位佬帮忙找 bug、提 PR、欢迎顺手点个 Star

本模型基于《滴天髓》、《三命通会》、《子平真诠》逻辑，将传统命理量化为数学模型。
第一部分：排盘与基础设定
1. 排盘原则
指定模式：直接读取输入的干支，跳过自动排盘公式，以输入的年月日时为准。
起运计算：
基准：3 天=1 岁（ 4320 分钟=1 岁）。
节气：排大运仅依“节”不依“气”。
顺逆：阳男阴女顺行，阴男阳女逆行。
真太阳年：立春前算上一年，立春后算当年。
2. 藏干赋分标准（字典库）
用于后续计算分值，需建立数据库。
地支藏干速查表
子 癸（专气，纯气） 本气占 100%
丑 己(60%) 癸(冬余气，25%) 辛(金入墓，15%) 冬天水强于金
寅 甲(60%) 丙(火长生，30%) 戊(10%)
卯 乙（专气，纯气） 本气占 100%
辰 戊(60%) 乙(春余气，25%) 癸(水入墓，15%) 春天木强于水
巳 丙(60%) 庚(金长生，30%) 戊(10%)
午 丁(70%) 己(30%)
未 己(60%) 丁(夏余气，25%) 乙(木入墓，15%) 夏天火强于木
申 庚(60%) 壬(水长生，30%) 戊(10%)
酉 辛（专气，纯气） 本气占 100%
戌 戊(60%) 辛(秋余气，25%) 丁(火入墓，15%) 秋天金强于火
亥 壬(70%) 甲(木长生，30%)
第二部分：静态分数计算（原局）
1. 五行基础分算法
公式：单五行分 = Σ天干分 + Σ藏干分 + 局势修正分
1.1 干支基础赋分
天干：统一 36 分。
地支本气：月支（提纲） 70 分；年/日/时支 40 分。
地支杂气：中气 15 分（若无余气则 25 分）；余气 10 分。
注：杂气分值固定，不享受月令加成。
伏吟：干支相同直接累加。
1.2 系数修正
月令状态系数（以月支主气为准）：
旺（同）：1.2 | 相（生）：1.2 | 休（被生）：0.8 | 囚（克）：0.7 | 死（被克）：0.5
通根系数（自坐强根）：
天干坐下为临官（禄）或帝旺（刃）：系数 1.5 。
否则：系数 1.0 。
1.3 局势修正分（直接加成到五行总分）
优先级：三会 > 三合 > 六合 > 六冲。
三会局（寅卯辰等）：三字全且非死/囚。
旺/相：+80 分；休：+50 分；死/囚：0 分。
三合局（申子辰等）：
全三合：得月令支持（化神当令或受生）+60 分；否则 0 分（合绊）。
半三合（生+旺）/ 拱局（旺+墓）：得月令支持 +50 分（拱局+40 分）；否则 0 分。
生墓半合（生+墓）：忽略不计。
六合：合化成功（得月令）+30 分；否则 0 分。
合化判定：必须 [得月令支持] （当令或相生）。若天干透出化神，可额外加分。
刑冲害破（扣分项）：
六冲：紧贴-15 ；隔柱-5 ；遥冲-2 。（若有合局解冲，扣分减免）。
三刑：全见-15 ；两字-5 。自刑：相邻-5 。
六害：-3 。相破：-2 。
2. 格局与强弱判定（层级判定法）
判定顺序：化气格 > 从格 > 调候格 > 通关格 > 正格（扶抑）。满足前序则锁定喜忌。
2.1 特殊格局
化气格：天干五合 + 化神当令 + 化神极旺 + 日主无根。
喜：化神、生化神者。忌：克化神者、还原日主者。
从格：
判定：同党/异党比值 C 。C>4 为从旺，C<0.25 为从弱。
熔断：若满足从格分值但有强根或印比透干得地，强制回退为正格。
喜忌：从旺喜同党（印比）；从弱喜异党（财官食）。
调候格（冬夏生人优先）：
寒局（冬月缺火）：强制取火为用（ 95 分），木为喜。
燥局（夏月缺水）：强制取水为用（ 95 分），金为喜。
通关格：两行对战且分值接近，取通关五行为用。
2.2 正格扶抑（常规）
计算公式：
同党分 = 比劫 + 印枭
异党分 = 财 + 官 + 食伤
冲克系数 K （反映内耗）：无冲 K=1 ；冲且均势 K=0.8 ；冲且一边倒 K=1 或 0.5 。
日主得分 S = 同党 - 异党 × K - 修正值(天干合化)
判定：S < 0 身弱（喜印比）； S ≥ 0 身旺（喜财官食）。
2.3 喜用神赋分
用神 (95 分)：核心解药。
喜神 (75 分)：辅佐用神。
闲神 (50 分)：无关紧要。
仇神 (25 分)：生助忌神。
忌神 (5 分)：核心病灶。
第三部分：运势动态计算（大运/流年）
1. 计算公式
基础原则：天干占 30%，地支占 70%。
流年/小运分 = 天干分×0.3 + 地支分×0.7 + 修正值
大运分（三七互涉）：
前 5 年 = 天干×0.7 + 地支×0.3 + 修正值
后 5 年 = 天干×0.3 + 地支×0.7 + 修正值
综合运势分 = (当前大运分 + 当前流年分) / 2
2. 修正值算法
2.1 内部修正（干支关系）
同气：吉+吉(+5)，凶+凶(-5)。
相生：吉生吉(+3)，凶生凶(-3)，凶生吉(+2)，吉生凶(-2)。
相克（盖头/截脚）：
制凶：吉克凶(+5)。
伤吉：凶克吉(-5)。
内耗：吉克吉(-3)。
狗咬狗：凶克凶(+3)。
2.2 外部修正（与原局作用）
优先级：组合关系 > 天干/地支单项叠加。
A. 组合关系（独占）：
天克地冲：冲月(-15)，冲日(-10)，冲年(-8)，冲时(-5)。(冲去忌神反+10)。
岁运并临：喜用(+10)，忌仇(-10)。
B. 单项叠加：
合局：合化喜用(+10)，合化忌仇(-10)，合绊喜用(-5)，合绊忌仇(+5)。
冲局（无天克地冲时）：冲月(-8)，冲日(-5)，冲年(-4)。
天干生克：喜用受克(-5)，忌神受克(+5)。
第四部分：逻辑判定与断语生成
1. 评分等级
85-100：大吉（巅峰）
70-84：吉（顺畅）
50-69：平（过渡）
30-49：凶（阻碍）
0-29：大凶（动荡）
2. 深度逻辑（优先级高于分数）
A. 凶局陷阱（熔断判凶）
虚不受补（身弱）：原局弱，流年见帝旺/禄神 -> 盲目自信，财来财去。
犯旺之灾（身强）：原局极旺，流年见微弱官杀 -> 衰神冲旺，犯众怒，官非血光。
用神崩塌：流年冲克第一用神 -> 支柱断裂，大凶。
B. 吉局飞跃（判吉）
真神得地：虚浮用神在流年得强根 -> 理想落地。
吉神成局：合成喜用局 -> 众志成城，爆发。
天降解神：流年填补通关或调候缺口 -> 绝处逢生。
3. 特殊断语逻辑
犯太岁：值/冲/刑/害/破，依地支关系输出。
十二长生：
长生：转折、获救。
帝旺：极致。若运分高为得强根；若运分低且凶，为羊刃之灾（冲动/伤残）。
墓：糊涂、积攒、住院。
绝：彻底结束，归零。
十神象义：根据流年天干十神及喜忌，输出对应的人际、事业、财运断语。
附：AI 分析报告演示
八字：癸亥 甲子 己丑 戊辰
性别：女
第一部分：排盘与原局静态分析
1. 排盘基础参数
出生时间：1983 年 12 月 27 日 08:00
八字：
年柱：癸亥 [壬(70%), 甲(30%)] 根基
月柱：甲子 [癸(100%)] 提纲
日柱：己丑 [己(60%), 癸(25%), 辛(15%)] 命主
时柱：戊辰 [戊(60%), 乙(25%), 癸(15%)] 归宿
性别：女
节气：[大雪 (12-07)] - [小寒 (01-06)]
己土生于子月，水旺、木相、金休、土囚、火死。
日干：己土。月令：子水。
水（旺）：同月令，系数 1.2 。
木（相）：水生木，系数 1.2 。
金（休）：生月令，系数 0.8 。
土（囚）：克月令，系数 0.7 。
火（死）：被月令克，系数 0.5 。
2. 大运排盘表（精确校验）
逻辑判定：
立春校验：[已过立春，年柱属当年癸亥]
阴阳顺逆：[癸(阴)] + [女] = [顺行]
目标节令：[小寒] (时间：1984-01-06 11:42)
起运计算（分钟级）：
天数差：12 月 27 日 08:00 到 1 月 6 日 11:42
总分钟数=14622 分钟
起运岁数换算（标准公式：4320 分钟=1 岁）：
岁：14622÷4320=3 岁(余 1662)
月：1662÷360=4 个月(余 222)
天：222÷12=18.5 天 (即 18 天 12 小时)。
最终结果：3 岁 4 个月 18 天 12 小时。
起运年份：
1983 年+3 岁=1986 年。
12 月 27 日，再加 4 个月 18 天，约在 1987 年上半年交运。
交运时间：1987 年 5 月 15 日。
生成交运日期：1988 年 9 月 9 日
大运序列：
乙丑 (1987)
丙寅 (1997)
丁卯 (2007)
戊辰 (2017-2026) 当前大运
己巳 (2027)
庚午 (2037)
辛未 (2047)
壬申 (2057)
癸酉 (2067)
甲戌 (2077)
3.计算五行分
水旺*1.2
水基础分计算：
年干癸：坐子(禄)、坐亥(刃)，符合自坐强根，系数 1.5
计算：36*1.2*1.5=64.8
年支亥 (本气壬)：40*1.2=48
月支子 (本气癸)：70*1.2=84
日支丑 (查字典：中气癸)：15*1.2=18
时支辰 (查字典：余气癸)：10*1.2=12
水修正分计算：
三会局：亥子丑三会北方水。条件：三字全，月令旺。加分：+80 。
拱局：子辰拱水。条件满足（帝旺+墓库），叠加计算。加分：+40 。
六合：子丑合。条件：成员已被三会征用。加分：+0 。
水总分：64.8+48+84+18+12+80+40=346.8
木相*1.2
木基础分计算：
月干甲：甲坐子，不符合通根，系数 1.0
计算：36*1.2=43.2
年支亥 (查字典：中气甲)：15*1.2=18
时支辰 (查字典：中气乙)：15*1.2=18
木局势修正分计算：无。
木总分：43.2+18+18=79.2
土囚*0.7
土基础分计算：
日干己：己坐丑，不符合通根，系数 1.0
计算：36*0.7=25.2
时干戊：戊坐辰，不符合通根，系数 1.0
计算：36*0.7=25.2
日支丑 (本气己)：40*0.7=28
时支辰 (本气戊)：40*0.7=28
土局势修正分计算：无
土总分：25.2+25.2+28+28=106.4
金休*0.8
金基础分计算：
日支丑 (查字典：余气辛)：10*0.8=8
金局势修正分计算：无。
金总分：8.0
火死*0.5
火基础分计算：全局无火。
火总分：0
4.计算日主分
日主：己土
同党(生助)：土(比劫)+火(印枭) 106.4(土)+0(火)=106.4
异党(克泄耗)：水(财)+木(官)+金(食伤) 346.8(水)+79.2(木)+8(金)=434.0
同党分远低于异党分
确定冲克系数 K
计算比值 C：
C=同党总分/异党总分=106.4/434.0≈0.245
检查冲克：地支为亥、子、丑、辰。无六冲。依据规则：无冲克时，不看 C ，K=1.0 。
确定修正合化值
检查天干：日干己与月干甲，甲己中正之合（甲己合土），但生于子月，水旺土囚，合化不成功，合绊。
依据规则：修正值，只考虑日主天干合化，取值 15 。
日主得分计算
日主得分=同党总分-异党总分*K-修正值
S=106.4-434.0*1-15=-342.6
格局判定：
化气格：甲己合，月令子水，非化神（土）当令之地。不成立。
从格：
比值 C (0.245) < 0.25 。满足从弱条件。
熔断检查：
天干透戊土（比劫），且通根于辰、丑。
地支辰、丑为湿土，虽参与会合水局，但本气土仍在。
判定：虽然水势浩大，但日主己土有强根（丑、辰），且时干戊土帮身。依据“多库微根”熔断机制，不能论真从。应为正格身弱（偏弱）。
修正结论：鉴于水分（ 346.8 ）占绝对优势（>60%），且亥子丑三会成局，湿土尽皆化水，土之根气尽失。且日主己土无强根(未见午、巳)，虽有丑辰湿土微根，但周围水势滔天，湿土尽皆化水(亥子丑会、子辰合)，日主无力抵抗，只能弃命从财。故判定为从财格（真从）。
在这个八字中，水的分数是异党总分的绝对分数，日主为己土，土克水，为财，最旺的五行为财星，这个从弱格的具体名字就叫从财格。
命主己土就像一个势单力薄的人，周围全是水财，金山银山，而且生在冬天水旺，她只能顺从这股巨大的财富气势，所以叫从财。
喜忌神赋分
用神（水 财）：95 分（旺神 财星）
喜神（金 食伤）：75 分（从弱格，喜食伤生财）
喜神（木 官杀）：75 分（从弱格中，官杀护财亦为喜）
闲神：无（此局金水木皆喜）
仇神（火 印枭）：25 分（生助忌神）
忌神（土 比劫）：5 分（克财、还原日主）
第二部分：运势动态计算
计算 1 岁（起运前）和 4 岁（起运后）的详细数据
1. 小运计算
1 岁，小运期
流年：癸亥 1 岁；小运：时柱戊辰，阴女顺推第一位，己巳。
计算小运运势分
小运干支：天干己土忌神(5 分)；地支巳火仇神(25 分)；
内部修正：火生土(仇生忌，凶生凶)-3 分；
外部修正：己土克癸水，忌克喜，巳亥冲，冲太岁，满足天克地冲，-8 分。触发天克地冲，不再单独计算天干克和地支冲。
公式：5*0.3+25*0.7-3-8=8
2.大运计算（当前大运期）
当前大运：戊辰（ 34-43 岁）
时间段：2017-2026 年。
当前所处：2025 年是戊辰运的第 9 年。
大运干支：天干戊土神(5 分)，地支辰土忌神(5 分)。
内部修正：干支同气（忌+忌）-5 分。
外部修正：
大运与原局
地支合：大运辰，月支子，年支亥，亥子辰（虽不成局，但半合水）。
地支合：大运辰，月支子，子辰半合水（喜）。+10 分。
天干克：大运戊克年干癸。忌克喜（合克）。-5 分。
外部修正总分=10-5=5 分
大运得分（后 5 年侧重地支）：
后 5 年大运分=5*0.3+5*0.7-5+5=5 分
大运虽地支贪合向水，但本质为忌神大运，且临近脱运期，土气混杂，运势极低。
3. 流年计算
乙巳（ 2025 年）
流年干支：乙木喜神(75 分)；地支巳火仇神(25 分)
内部修正：木生火（吉生凶）。-2 分。
外部修正：
天干克：乙(流) 克 己(日)。喜神克忌神（官杀护财）。+5 分。
地支冲：流年巳(仇)，冲年支亥(用)，太岁冲年。-4 分。
地支合：流年巳合日支丑 (仇神被绊)。巳丑拱金（喜），虽未化，但贪合忘克，化敌为友。+10 分。
解救：己土生于子月（冬天），水旺金休，合化金不成功，合而不化，为合绊，冲力未完全化解，扣分保留。
外部修正总分=5-4+10=11 分
流年得分：75*0.3+25*0.7-2+5-4+10=49 分
4. 流年综合运势分
公式：(大运分+流年分) /2
计算：(5+49) / 2=27 分。
其余年份的流年、大运数据，同理计算。
第三部分：运势报告（ 2025 乙巳）
[综合评分] ：27 分
[运势等级] ：大凶 (★)
[核心状态] ：动荡、危机。黎明前的黑暗，险象环生。
[核心事件] ：[劫财大运收尾-动荡脱运] + [七杀虚名-印星破财]
大运背景（戊辰-劫财-忌神-脱运期）：
周期解读：您正处于戊辰大运的第九年（ 2017-2026 ），属于“脱运期”。命理云“男怕交，女怕脱”，这是旧气场（土）最为混杂且做最后挣扎的时刻，往往伴随着人生方向的迷茫和环境的剧烈变动。
十神内象：干支一气皆为“劫财”（忌神）。这十年的底色是“掠夺”与“竞争”。意味着财富难以积聚，容易被同辈、朋友或合伙人分利，且常因盲目自信而陷入财务泥潭。
流年表象（乙木-七杀-喜神）：
外在机遇：流年天干透出乙木“七杀”。外在表现为：看似有新的权柄、职位提升、创业机会，或者是出现了一个强势的异性缘分。因为是喜神，这个机会看起来非常诱人，仿佛是翻身的救命稻草。
流年内象（巳火-正印-仇神）：
内在本质：流年地支巳火“正印”落地。内在本质是：印星生助了劫财（忌神），且冲克了命局唯一的生命线——亥水（财星）。
成败定性：这叫“杀印相生”生到了忌神上。意味着为了追求表面的虚名（七杀），不仅耗费了资源，还动摇了根本，导致严重的破财和根基受损。典型的“金玉其外，败絮其中”。
[互动关系] ：
岁运交战（凶）：大运戊辰（土）与流年乙巳（木火）天克地生，土木交战，局势混乱。
冲太岁（凶）：巳亥冲。根基受冲。
拱合解冲（吉中藏凶）：乙巳合己丑。鸳鸯合。感情或合作关系有重大变化。巳丑拱金。虽有食伤（金）从中调解，但难以完全化解水火激战之势。
在运势极低的情况下，这种“合”往往代表被迫的妥协。比如为了解决债务问题而变卖资产（合走），或者为了生存而委曲求全。
天干合绊（平）：大运戊土合年干癸水（戊癸合）。忌神合绊用神。大运戊土把财星癸水合住，代表这十年财运流通不畅，资金容易被套牢或被兄弟朋友（比劫）借走不还。
[十二长生状态]
大运状态（戊辰）：日主己土行至辰运，为“衰”地。
解读：经过了前面几步大运的消耗，日主在忌神大运末尾，能量已显颓势，心态上偏向守成、无力感较重。虽然辰土有根，但更多的是一种被环境裹挟的无奈。
日主（己土）：见流年支（巳）为 帝旺（羊刃）。
状态：身弱逢刃，盲目冲动。
解读：极度危险的信号。 在运气最差的大运末尾，突然觉得自己“行了”（帝旺），这是最危险的信号。千万不要孤注一掷去博翻身，否则会死在黎明前。对于从弱格（从财格）而言，最怕日主得强根。这叫“背禄逐马”。 你今年心态会发生剧变，从过去的顺从变得固执、冲动、好斗。你会误以为自己能力很强，想要逆势而为（如抄底投资、对抗上司），结果却是以卵击石。 帝旺在凶运：代表肢体冲突、手术血光。
[详细解读]
2025 年是“忌神大运收尾”与“流年虚火上升”的叠加期。
虽然流年天干乙木（喜神）让你看到了一丝希望，但大运戊辰（忌神）如同一潭死水，拖住了你的脚步。地支巳火（仇神）的出现，不仅冲了你的年支根基（亥水），还生助了你最忌讳的土气。
你会感到一种前所未有的撕裂感：一方面想大干一场（帝旺心态），另一方面现实环境却处处掣肘（大运忌神）。这种矛盾最容易导致破财和健康危机。
[避坑指南与行动建议]
[性格情绪] ：极度警惕“羊刃”心态。今年心态极不稳定，容易刚愎自用，听不进人劝。帝旺羊刃入命，脾气暴躁，易与人发生肢体冲突。务必时刻提醒自己：冲动是魔鬼。
[事业官运] ：切忌创业。七杀透干往往伴随着“独立门户”的诱惑，但大运不支持，一旦投入就是无底洞。职场中可能面临岗位调整（冲年柱），如果是被动调动，接受即可；如果是主动跳槽，建议暂缓。
[财富投资] ：严防破财。忌神比劫（土）得流年火生，劫财夺财之象明显。禁忌：不要借钱给任何人，不要担保，不要进行股票、房产等重资产投资。锁死现金流是唯一策略。
[健康安全] ：红色警报。火土燥热克水（用神）。重点防护：肾脏、泌尿系统、血液系统。巳亥冲为水火激战，需防烫伤、车祸等意外血光。
[感情婚姻] ：动荡不安。流年乙巳与日柱己丑天克地合，合中带克（乙克己）。单身者：容易遇到性格强势、给你带来压力的异性（七杀），虽然有缘（合局），但相处累。已婚者：夫妻宫被合动，需防烂桃花介入，或因财务问题引发激烈争吵。
[家庭长幼] ：长辈受冲。流年巳火冲年支亥水（祖辈宫）。警示：家中长辈（尤其是父亲或祖辈）健康恐有突变，需密切关注心脑血管或跌打损伤。今年不宜远行，宜留守家中照料。
[总体策略] ：潜龙勿用，保命为上。虽然流年分数比大运高，看似有转机，但综合分依然是大凶。这是戊辰忌神大运的收尾阶段，黎明前的黑暗最难熬。脱运之年土气重，羊刃逢冲祸随行。策略：熬。不要做任何重大决策，只需活着，熬过黎明前的黑暗。
附录：AI 提示词指令（ Prompt ）模板
角色设定：
你是一位精通《滴天髓》与《子平真诠》的计算型命理专家。请严格基于上述 [命理算法模型] 执行推演。
任务要求：
排盘：输出标准八字、真太阳时、节气、藏干。
原局计算：
列出五行得分明细。
判定格局（化气>从格>调候>正格），解释判定理由。
输出喜忌神及分值（用/喜/闲/仇/忌）。
运势推演：
计算当前大运分、流年分、综合分。
列出关键修正项（如天克地冲、合局、十二长生状态）。
生成报告：
核心状态：基于分数的定性（大吉/大凶等）。
深度解读：结合“深度逻辑（ A/B 组）”与十神象义，生成具体生活场景描述（事业/财富/健康/感情）。
避坑指南：分条列出建议。
输入信息：
八字：[用户八字]
出生时间：[用户时间]
性别：[男/女]
推演年份：[年份]
请开始计算。
由于原文档超 20000 个字符，这里仅提供精简版，完整版见公众号 高人有术

0 元验证的信用卡（bug 卡、黑卡）

4133310395577369|11/26|743
4133310403524940|01/27|712
4133310398070933|11/26|579
4133310598422082|01/28|945（日本 ip 能过 augmentcode）
4133310586230836|02/28|999
注册：Claim your invite and earn 10 credits - Lovable

功能 top
界面 top
流畅 top

• 支持反重力和 gcl，你甚至能自由组合，不过 api 联网正在研究怎么实现

体验地址：

支持单页简化模式，例如
https://api-monitor.zeabur.app/Hosts
https://api-monitor.zeabur.app/2fa
打开后即是单纯功能页

欢迎部署体验
以及

【预览】

AMD 7800XT 显卡 Windows 本地部署 ComfyUI + Z-Image 保姆级教程

前言

作为一名 AMD Yes! 用户，想在本地跑 AI 生图实在费劲。

网上很多教程推荐使用 WSL（Linux 子系统）或者双系统，我折腾了一圈，全部以失败告终，不仅步骤繁琐，还容易报错。

经过多次尝试，我终于摸索出了一套 在 Windows 下最稳、最简单的方案：利用 秋叶大神的整合包 + ZLUDA。现在我也能愉快地生图了，把踩过的坑分享给大家，希望能帮到同样使用 A 卡的佬友。

第一步：搞定驱动

AMD 跑 AI，驱动是重中之重。这里有两个巨大的坑，请严格按照以下步骤操作：

1. 下载并安装专用驱动

你需要安装特定的 PRO 版本驱动来支持 ROCm/HIP 环境。请按顺序下载：

• HIP 支持驱动 (必须安装) ：

  • 版本：AMD-Software-PRO-Edition-23.Q4-Win10-Win11-For-HIP
  • 下载地址：点击下载

• 显卡核心驱动 (配合使用) ：

  • 版本：AMD-Software-PRO-Edition-25.Q3 (由于官方链接失效，请使用第三方备份)
  • 下载地址：DriversCloud 下载

避坑指南 1：禁止驱动自动更新！

非常重要！ 安装完上述驱动后，一定要在 AMD 驱动软件设置里，把 “自动更新” 关掉！

如果不关，重启电脑后它会自动更新到最新的游戏驱动，会导致环境失效（比如提示显存不足、报错等），那时候就得全部重来了。

第二步：安装 ComfyUI 整合包

为了省去繁琐的代码部署，我们直接使用 B 站秋叶大佬的整合包，开箱即用。

• 下载地址：夸克网盘
• 解压密码：bilibili-秋葉aaaki

操作步骤：

1. 下载并解压 ComfyUI-aki-v2。
2. 点击 启动器 运行。

启动器设置（启用 ZLUDA）

进入启动器界面后，不要急着点运行：

1. 在启动器设置或内核选择中，找到 ZLUDA 选项并选中它（这是让 A 卡模拟 N 卡环境运行的关键）。
2. 确保显卡选项已正确识别你的 7800XT。

第三步：更新内核（避坑指南 2）

这里是很多人失败的地方。整合包自带的核心可能较旧，直接跑新模型会报错。

操作方法：

在启动器界面，找到 “版本管理” 或 “更新” 选项，选择 “最新代码”，点击 一键更新。

更新完成后，务必 重启软件，否则工作流可能无法正常加载。

第四步：模型选择与配置（性能优化篇）

避坑指南 3：显存不够怎么办？

我的 7800XT 虽然有 16G 显存，但在跑完整版 Z-Image (Flux) 模型时，显存依然捉襟见肘。

• 完整版现状：生一张图需要 500 秒 左右（严重爆显存，速度极慢）。
• 优化方案：使用 FP8 Scala 版本 的模型。

优化后的效果：

• 显存占用：仅需 6-7G。
• 生成速度：缩短至 50 秒 一张图（速度提升 10 倍！）。
• 画质损失：几乎肉眼不可见。

必备模型下载清单

Z-Image Turbo 需要三个核心组件才能运行：主模型、文本模型、VAE。 请按照下面的清单下载，并严格放入对应的文件夹中（找不到文件夹就根据路径自己新建一个，注意文件名不要改动太大）。

提示：由于涉及 HuggingFace 和 Civitai，部分网络可能需要魔法才能打开。

1. 主模型 (Checkpoints)

这是画图的主力核心，我们选用的是针对显存优化的量化版本，非常适合 7800XT 这样的 16G 显卡。

• 模型名称：Z-Image-Turbo (Quantized)

• 下载地址：点击前往 Civitai 下载

• 存放路径：

  ComfyUI-aki-v2\models\checkpoints
  

2. 文本模型 (Text Encoder / CLIP)

这是 AI 的 “耳朵”，用来听懂你的提示词。Z-Image 使用的是 Qwen (通义千问) 的 3.4B 版本作为文本编码器。

• 模型名称：qwen_3_4b.safetensors

• 下载地址：点击前往 HuggingFace 下载

• 存放路径：

  ComfyUI-aki-v2\models\clip
  

  (注：如果文件夹里没有 clip 文件夹，找一下有没有 text_encoders ，或者直接手动新建一个 clip 文件夹)

3. VAE 模型 (解码器)

这是 AI 的 “眼睛”，负责将计算好的数据解码成我们在屏幕上看到的像素图片。如果没有它，生成的图可能是一片灰色或彩色噪点。

• 模型名称：ae.safetensors
• 下载地址：点击前往 HuggingFace 下载
• 存放路径：

ComfyUI-aki-v2\models\vae

1. 主模型 (Checkpoints) ：下载 fp8 版本的 Z-Image/Flux 模型。
2. 文本编码器 (Text Encoder) ：下载 Qwen 8B (或对应的 Clip/T5) 文本模型。没有它，AI 听不懂你的提示词，点击下载。
3. VAE 模型：下载对应的 AE/VAE 模型。没有它，生成的图片会是一片灰或者噪点，点击下载。

第五步：愉快生图

将下面的内容保存为 json

{ "2": { "inputs": { "text": "a beautiful landscape, high quality, 8k", "clip": ["16", 0] }, "class_type": "CLIPTextEncode", "_meta": { "title": "正向提示词" } }, "4": { "inputs": { "seed": , "steps": 8, "cfg": 1, "sampler_name": "euler", "scheduler": "simple", "denoise": 1, "model": ["15", 0], "positive": ["2", 0], "negative": ["9", 0], "latent_image": ["5", 0] }, "class_type": "KSampler", "_meta": { "title": "K采样器" } }, "5": { "inputs": { "width": 768, "height": 768, "batch_size": 1 }, "class_type": "EmptyLatentImage", "_meta": { "title": "空Latent图像" } }, "6": { "inputs": { "vae_name": "ae.safetensors" }, "class_type": "VAELoader", "_meta": { "title": "加载VAE" } }, "7": { "inputs": { "samples": ["4", 0], "vae": ["6", 0] }, "class_type": "VAEDecode", "_meta": { "title": "VAE解码" } }, "8": { "inputs": { "filename_prefix": "ComfyUI", "images": ["7", 0] }, "class_type": "SaveImage", "_meta": { "title": "保存图像" } }, "9": { "inputs": { "text": "blurry, ugly, bad, lowres, jpeg artifacts, watermark, distorted, noisy, artifact, glitch, oversaturation, neon tones, harsh contrast or glow, color cast, pixelated, blocky", "clip": ["16", 0] }, "class_type": "CLIPTextEncode", "_meta": { "title": "反向提示词" } }, "15": { "inputs": { "ckpt_name": "zImageTurboQuantized_fp8ScaledE4m3fnKJ.safetensors" }, "class_type": "CheckpointLoaderSimple", "_meta": { "title": "加载主模型" } }, "16": { "inputs": { "clip_name": "qwen_3_4b.safetensors", "type": "stable_diffusion" }, "class_type": "CLIPLoader", "_meta": { "title": "加载CLIP文本编码器" } } } 

在工作流界面，按住 Ctrl+O，选择刚才的 json，导入后会形成如下工作流，点击运行即可。

这套工作流非常强大，不仅可以用来提示词生图，还能先炼丹，用 lora 脸模、腿模等配合提示词生图，还能生成视频，不过生成视频的模型需要更高的版本才支持，这属于进阶篇了，我折腾了几天目前这套已经足够使用了。

• 代码： DAZLXPG
• dazl.dev

LFM2-2.6B-Exp 是一个基于 LFM2-2.6B 的实验性检查点，采用纯强化学习技术构建。
在教学理解、知识掌握和数学基准方面不断取得进步

在这些领域优于其他 3B 模型
其 IFBench 得分超过了 DeepSeek R1-0528，后者是一款体积比它大 263 倍的型号。

感觉未来本地端都是小模型的天下喵，未来可期喵