哈十五

OpenClaw 对接大语言模型 API 全配置指南

Sun, 22 Mar 2026 14:57:08 +0800

OpenClaw 作为开源 AI 智能体网关，核心能力是通过统一接口对接各类大语言模型 API，实现多模型灵活切换与统一调用。其配置核心围绕 baseUrl（API 基础地址）、apiKey（API 密钥）、模型 ID 三大参数展开，同时兼容 OpenAI 协议、原生协议等多种适配方式，支持国内外主流商业模型与开源模型接入。本文将系统梳理 OpenClaw 对接主流大模型的 API 配置规范、参数说明与实操示例，助力快速完成模型对接。

一、OpenClaw 模型配置核心参数解析

OpenClaw 模型配置主要通过 ~/.openclaw/openclaw.json 配置文件实现，核心配置块为 models.providers，每个模型提供商对应独立配置项，关键参数如下：

参数	类型	说明	配置要点
baseUrl	string	API 服务基础地址	必须与模型官方接口一致，末尾禁止加斜杠，如 https://api.openai.com/v1
apiKey	string	模型平台 API 密钥	从对应平台控制台获取，建议通过环境变量 ${ENV_VAR} 引用，避免明文泄露
api	string	请求协议适配器	主流为 openai-completions（OpenAI 兼容协议），原生模型需指定对应协议（如 anthropic）
models	array	模型列表	包含模型 ID、名称、上下文窗口等信息，id 为模型官方唯一标识
id	string	模型唯一 ID	必须与模型平台提供的标识完全一致，如 gpt-4o、deepseek-chat
name	string	模型自定义名称	OpenClaw 内显示的模型别名，方便识别
contextWindow	number	上下文窗口大小	模型支持的最大 Token 长度，影响长文本处理能力
maxTokens	number	单次生成最大 Token	限制模型单次响应长度，避免超额计费

二、主流大语言模型 API 对接配置（含 baseUrl、apiKey、模型 ID）

（一）国际主流模型

1. OpenAI（GPT 系列）

平台入口：https://platform.openai.com/ 核心配置：

"openai":{
"baseUrl":"https://api.openai.com/v1",
"apiKey":"${OPENAI_API_KEY}",
"api":"openai-completions",
"models":[
{
"id":"gpt-4o",
"name":"GPT-4o",
"contextWindow":128000,
"maxTokens":4096
},
{
"id":"gpt-3.5-turbo",
"name":"GPT-3.5 Turbo",
"contextWindow":16384,
"maxTokens":4096
}
]
}

模型 ID 说明：gpt-4o（多模态旗舰）、gpt-4-turbo、gpt-3.5-turbo 等。

2. Anthropic（Claude 系列）

平台入口：https://console.anthropic.com/ 核心配置：

"anthropic":{
"baseUrl":"https://api.anthropic.com/v1",
"apiKey":"${ANTHROPIC_API_KEY}",
"api":"anthropic",
"models":[
{
"id":"claude-3-opus-20240229",
"name":"Claude Opus 4.6",
"contextWindow":200000,
"maxTokens":8192
},
{
"id":"claude-3-sonnet-20240229",
"name":"Claude Sonnet 4.6",
"contextWindow":200000,
"maxTokens":8192
}
]
}

模型 ID 说明：claude-3-opus-20240229（旗舰）、claude-3-sonnet-20240229、claude-3-haiku-20240307。

3. Google（Gemini 系列）

平台入口：https://aistudio.google.com/ 核心配置：

"google":{
"baseUrl":"https://generativelanguage.googleapis.com/v1beta",
"apiKey":"${GOOGLE_API_KEY}",
"api":"google",
"models":[
{
"id":"gemini-1.5-pro",
"name":"Gemini 1.5 Pro",
"contextWindow":1000000,
"maxTokens":8192
}
]
}

模型 ID 说明：gemini-1.5-pro、gemini-1.5-flash。

4. xAI（Grok 系列）

平台入口：https://x.ai/ 核心配置：

"xai":{
"baseUrl":"https://api.x.ai/v1",
"apiKey":"${XAI_API_KEY}",
"api":"openai-completions",
"models":[
{
"id":"grok-4.1",
"name":"Grok 4.1",
"contextWindow":128000,
"maxTokens":4096
}
]
}

（二）国内主流模型

1. DeepSeek

平台入口：https://platform.deepseek.com/ 核心配置：

"deepseek":{
"baseUrl":"https://api.deepseek.com/v1",
"apiKey":"${DEEPSEEK_API_KEY}",
"api":"openai-completions",
"models":[
{
"id":"deepseek-chat",
"name":"DeepSeek Chat",
"contextWindow":128000,
"maxTokens":8192
},
{
"id":"deepseek-reasoner",
"name":"DeepSeek R1",
"contextWindow":128000,
"maxTokens":32768,
"reasoning":true
}
]
}

模型 ID 说明：deepseek-chat（通用对话）、deepseek-reasoner（深度推理）。

2. 阿里云百炼（通义千问系列）

平台入口：https://www.aliyun.com/product/bailian 核心配置：

"bailian":{
"baseUrl":"https://dashscope.aliyuncs.com/api/v1",
"apiKey":"${BAILIAN_API_KEY}",
"apiSecret":"${BAILIAN_API_SECRET}",
"api":"openai-completions",
"models":[
{
"id":"qwen3.5-plus",
"name":"通义千问3.5 Plus",
"contextWindow":977000,
"maxTokens":8192
},
{
"id":"qwen3-coder-next",
"name":"通义千问3 Coder",
"contextWindow":256000,
"maxTokens":8192
}
]
}

模型 ID 说明：qwen3.5-plus、qwen3-max、qwen3-coder-next。

3. 智谱 AI（GLM 系列）

平台入口：https://open.bigmodel.cn/ 核心配置：

"zhipu":{
"baseUrl":"https://open.bigmodel.cn/api/paas/v4",
"apiKey":"${ZHIPU_API_KEY}",
"api":"openai-completions",
"models":[
{
"id":"glm-4-plus",
"name":"GLM-4 Plus",
"contextWindow":128000,
"maxTokens":4096
},
{
"id":"glm-4-flash",
"name":"GLM-4 Flash",
"contextWindow":128000,
"maxTokens":4096
}
]
}

4. Moonshot（Kimi 系列）

平台入口：https://platform.moonshot.cn/ 核心配置：

"moonshot":{
"baseUrl":"https://api.moonshot.cn/v1",
"apiKey":"${MOONSHOT_API_KEY}",
"api":"openai-completions",
"models":[
{
"id":"kimi-chat",
"name":"Kimi Chat",
"contextWindow":200000,
"maxTokens":4096
},
{
"id":"kimi-coding",
"name":"Kimi Coding",
"contextWindow":256000,
"maxTokens":4096
}
]
}

5. 百度文心一言

平台入口：https://console.bce.baidu.com/qianfan/ 核心配置：

"ernie":{
"baseUrl":"https://aip.baidubce.com/rpc/2.0/ai_custom/v1/wenxinworkshop/chat",
"apiKey":"${ERNIE_API_KEY}",
"secretKey":"${ERNIE_SECRET_KEY}",
"api":"ernie",
"models":[
{
"id":"ernie-3.5-turbo",
"name":"文心一言3.5 Turbo",
"contextWindow":128000,
"maxTokens":4096
}
]
}

三、OpenClaw 模型对接实操步骤

1. 获取 API 密钥

登录对应模型平台，完成实名认证后，在「API 密钥」或「开发者中心」创建新密钥，妥善保存（仅展示一次，丢失需重新创建）。

2. 配置环境变量（推荐）

将 API 密钥存入系统环境变量，避免配置文件明文泄露：

# Linux/Mac
echo "export OPENAI_API_KEY='你的密钥'">>~/.bashrc
source ~/.bashrc

# Windows（PowerShell）
[Environment]::SetEnvironmentVariable("OPENAI_API_KEY","你的密钥","User")

3. 编辑 OpenClaw 配置文件

打开 ~/.openclaw/openclaw.json，在 models.providers 中添加对应模型配置，示例如下：

{
"models":{
"mode":"merge",
"providers":{
"openai":{/*OpenAI配置*/},
"deepseek":{/*DeepSeek配置*/}
},
"defaults":{
"model":{
"primary":"deepseek/deepseek-chat"//设置默认模型
}
}
}
}

4. 重启 OpenClaw 服务

配置修改后，执行命令重启网关使配置生效：

openclaw gateway restart

5. 验证配置

发送测试消息，若模型正常响应，说明对接成功；可通过 openclaw models list 查看已配置模型列表。

四、常见问题与避坑指南

baseUrl 错误：末尾加斜杠、协议错误（http/https）、地址过时，需严格核对官方文档。 模型 ID 不匹配：使用自定义名称而非官方 ID，导致调用失败，需复制平台提供的完整模型标识。 apiKey 泄露：明文写入配置文件，建议通过环境变量引用，或使用 OpenClaw 内置的密钥管理功能。 协议适配器错误：非 OpenAI 兼容模型使用 openai-completions，需指定原生协议（如 anthropic、ernie）。 Token 超额：未设置 maxTokens 或上下文窗口过大，导致高额计费，需根据需求合理配置。

五、总结

OpenClaw 凭借灵活的配置架构，实现了对国内外主流大语言模型的统一对接，核心在于准确配置 baseUrl、apiKey、模型 ID 三大参数，并选择适配的协议类型。通过本文提供的配置示例与实操步骤，可快速完成多模型接入，结合 OpenClaw 的智能体能力，实现复杂任务的自动化处理。后续可进一步探索 OpenClaw 的模型切换、负载均衡、多模型协作等高级功能，最大化发挥大模型的价值。

ThinkTemplate 模板引擎完全指南

Sun, 22 Mar 2026 12:47:33 +0800

ThinkTemplate 模板引擎完全指南

ThinkTemplate 是 ThinkPHP 的内置模板引擎，现已支持独立使用。本文详细介绍其核心特性和使用方法。

环境要求

ThinkTemplate 3.0：PHP 8.0+
ThinkTemplate 2.0：PHP 7.1+

核心特性

ThinkTemplate 是一个基于 XML 的编译型模板引擎，具有以下特性：

支持模板标签定界符定义
支持直接使用 PHP 代码书写
支持文件包含
支持多级标签嵌套
支持布局模板功能
一次编译多次运行，编译和运行效率非常高
模板文件和布局模板更新，自动更新模板缓存
系统变量无需赋值直接输出
支持多维数组的快速输出
支持模板变量的默认值
支持页面代码去除 HTML 空白
支持变量组合调节器和格式化功能
允许定义模板禁用函数和禁用 PHP 语法
通过标签库方式扩展

模板标签详解

普通标签

普通标签用于变量输出和模板注释，默认以 { 和 } 作为开始和结束标识。

变量输出

{$name}           // 输出简单变量
{$vo.name}        // 输出对象属性
{$vo['name']}     // 输出数组元素
{$vo.name|strtoupper}  // 使用过滤器
{$defaultValue|default='默认值'}  // 默认值

系统变量

{$Think.version}   // ThinkPHP 版本
{$Think.now}      // 当前时间
{$Think.const.APP_STATUS}  // 常量
{$Think.session.user_id}   // Session 变量
{$Think.get.id}   // GET 参数

调节器（过滤器）

{$name|strtoupper}          // 字符串转大写
{$name|md5}                 // MD5 加密
{$name|substr=0,10}         // 字符串截取
{$time|date='Y-m-d',###}   // 日期格式化

标签库标签

标签库标签用于条件控制、循环输出等逻辑操作。

条件判断

{eq name="name" value="value"}
  相等时输出
{else/}
  不相等时输出
{/eq}

{neq name="name" value="value"}
  不相等时输出
{/neq}

{gt name="num" value="10"}
  大于时输出
{/gt}

{elt name="num" value="10"}
  小于等于时输出
{/elt}

{switch name="status"}
  {case value="1"}待审核{/case}
  {case value="2"}已通过{/case}
  {default/}未知状态
{/switch}

循环输出

{volist name="list" id="vo" offset="0" length="10"}
  {$vo.name}
  {$vo.id}
{/volist}

{foreach $list as $vo}
  {$vo}
{/foreach}

{for start="1" end="10"}
  {$i}
{/for}

比较标签

{eq name="vo.status" value="1"}
  正常
{/eq}

{like name="vo.email" value="%@qq.com"}
  QQ邮箱
{/like}

{between name="vo.age" value="1,100"}
  1-100之间
{/between}

文件包含

{include file="header" /}
{include file="footer.html" /}
{include file="$template" /}  // 动态模板

标签嵌套

支持多级标签嵌套，满足复杂业务需求：

{volist name="list" id="vo"}
  {eq name="vo.type" value="1"}
    <span>类型1：{$vo.name}</span>
  {elseeq name="vo.type" value="2"}
    <span>类型2：{$vo.name}</span>
  {else/}
    <span>其他类型：{$vo.name}</span>
  {/eq}
{/volist}

模板配置

默认配置（template.php）

return [
    // 模板路径
    "view_path"    => "",
    // 模板后缀
    "view_suffix"  => "html",
    // 模板开始标记
    "tpl_begin"    => "{",
    // 模板结束标记
    "tpl_end"      => "}",
    // 标签库开始标记
    "taglib_begin" => "{",
    // 标签库结束标记
    "taglib_end"   => "}",
    // 布局配置
    "layout_on"    => false,
    "layout_name"  => "layout",
    "layout_item"  => "{__CONTENT__}",
    // 去除HTML空白
    "strip_space"  => false,
    // 默认模板过滤器
    "default_filter" => "htmlspecialchars",
];

自定义定界符

如果需要避免与 Vue、React 等前端框架冲突，可以修改定界符：

tpl_begin = <{   // 普通标签开始
tpl_end   = >}   // 普通标签结束
taglib_begin  = <  // 标签库开始
taglib_end    = >  // 标签库结束

布局模板

ThinkTemplate 支持布局模板功能，便于统一页面结构：

// 启用布局
layout_on = true,
layout_name = layout,
layout_item = {__CONTENT__},

layout.html 示例：

<!DOCTYPE html>
<html>
<head>
    <title>{__TITLE__}</title>
</head>
<body>
    <header>网站头部</header>
    <main>{__CONTENT__}</main>
    <footer>网站底部</footer>
</body>
</html>

模板渲染

基础渲染

use think\Template;

// 实例化
$template = new Template();

// 渲染输出
$template->fetch("index");
$template->fetch("public/header");

// 渲染并返回
$content = $template->fetch("index");
echo $content;

传递变量

$template->assign("name", "ThinkPHP");
$template->assign("list", $data);
$template->fetch("index", ["title" => "首页"]);

渲染配置

$config = [
    "view_path" => "./template/",
    "view_suffix" => "html",
    "tpl_begin" => "{",
    "tpl_end" => "}",
];

$template = new Template($config);
$template->fetch("index");

性能优化

编译缓存：ThinkTemplate 是编译型引擎，模板会编译为 PHP 文件并缓存，无需手动管理
自动更新：当模板文件或布局模板更新时，会自动重新编译
去除空白：启用 strip_space 可以移除 HTML 中的空白字符，减少输出体积
禁用 PHP：生产环境可以禁用原生 PHP 语法，提高安全性

总结

ThinkTemplate 是一个功能强大且高效的 PHP 模板引擎，特别适合与 ThinkPHP 框架配合使用。其编译型架构保证了优秀的性能，丰富的标签库满足各种业务场景，灵活的扩展机制则让开发者能够轻松定制属于自己的标签。

无论是简单的变量输出还是复杂的业务逻辑，ThinkTemplate 都能提供优雅的解决方案。掌握好本文介绍的内容，你就能熟练运用 ThinkTemplate 进行模板开发了。

React 19 重大更新：Actions 与 Server Components 实战指南

Sat, 21 Mar 2026 17:44:05 +0800

React 19 重大更新：Actions 与 Server Components 实战指南

React 19 概述

React 19 是 React 框架的最新版本，带来了革命性的更新。Server Components 和 Actions 是这次更新的核心特性。

Server Components（服务端组件）

Server Components 允许组件在服务端渲染，大幅减少客户端 JavaScript 体积。

// Server Component - 默认行为
async function ArticleList() {
  const articles = await db.articles.findMany();
  
  return (
    ul
      {articles.map(article => (
        li key={article.id}>{article.title}/li
      ))}
    /ul
  );
}

// Client Component - 需要交互
use client
function LikeButton({ articleId }) {
  const [liked, setLiked] = useState(false);
  
  return (
    button onClick={() => setLiked(!liked)}>
      {liked ? '❤️' : '🤍'}
    /button
  );
}

Actions（服务器操作）

Actions 是一种在服务端处理表单提交的新方式。

use client
import { useActionState } from 'react';

async function createArticle(prevState, formData) {
  const title = formData.get('title');
  const result = await db.articles.create({ title });
  
  if (result.error) {
    return { error: result.error };
  }
  
  return { success: true };
}

性能对比

特性	传统方式	React 19
首屏加载	2.5s	1.2s
JS 体积	150KB	45KB
SEO 优化	需额外处理	原生支持

迁移建议

先升级到 React 18.3
逐步将静态组件转为 Server Components
用 Actions 替代 useEffect + API 调用

总结

React 19 的 Server Components 和 Actions 为构建高性能应用提供了全新的思路。

深入理解 LLM 微调技术：从 LoRA 到 QLoRA 实战指南

Sat, 21 Mar 2026 17:36:21 +0800

深入理解 LLM 微调技术：从 LoRA 到 QLoRA 实战指南

为什么需要微调

大型语言模型（LLM）在通用任务上表现优异，但在特定领域（如医疗、法律、金融）往往需要针对该领域的数据进行微调才能达到最佳效果。

全参数微调 vs 参数高效微调

传统全参数微调需要大量 GPU 显存，例如 70B 模型需要 140GB+ 显存。参数高效微调（PEFT）通过只更新少量参数大幅降低显存需求。

LoRA 原理

LoRA（Low-Rank Adaptation）的核心思想是在预训练模型的权重旁边添加低秩矩阵，通过训练这些低秩矩阵来微调模型。

# LoRA 核心思想
# 原始权重: W (d × k)
# LoRA 添加: ΔW = BA (d × r) × (r × k), r << min(d,k)
# 推理时: W' = W + ΔW

# PyTorch 实现示例
class LoRALayer(nn.Module):
    def __init__(self, in_features, out_features, rank=8):
        super().__init__()
        self.lora_A = nn.Parameter(torch.randn(rank, in_features))
        self.lora_B = nn.Parameter(torch.zeros(out_features, rank))
        self.scaling = 1.0
        
    def forward(self, x):
        # x @ W + x @ A^T @ B^T * scaling
        return x @ self.lora_B.T @ self.lora_A.T * self.scaling

QLoRA - 更高效的微调

QLoRA 在 LoRA 基础上引入了量化技术，进一步减少显存占用。

# QLoRA 关键技术
# 1. 4-bit 量化存储
# 2. 16-bit 训练
# 3. 分页优化器

# 使用 bitsandbytes
from transformers import BitsAndBytesConfig

quantization_config = BitsAndBytesConfig(
    load_in_4bit=True,
    bnb_4bit_compute_dtype=torch.float16,
)

model = AutoModelForCausalLM.from_pretrained(
    "model_name",
    quantization_config=quantization_config,
)

显存对比

方法	7B 模型	13B 模型	70B 模型
全参数	14GB	26GB	140GB
LoRA	4GB	8GB	40GB
QLoRA	2GB	4GB	10GB

实战：使用 PEFT 微调

from peft import LoraConfig, get_peft_model
from transformers import AutoModelForCausalLM

# 加载基础模型
model = AutoModelForCausalLM.from_pretrained("TinyPixel/Llama-2-7B-bf16-sharded")

# 配置 LoRA
lora_config = LoraConfig(
    r=16,  # rank
    lora_alpha=32,
    target_modules=["q_proj", "v_proj"],
    lora_dropout=0.05,
)

# 应用 LoRA
model = get_peft_model(model, lora_config)
model.print_trainable_parameters()
# 输出: trainable params: 4,194,304 || all params: 6,742,609,280 || trainable%: 0.062

微调最佳实践

数据准备：清洗数据，确保质量；使用 1000-5000 条高质量样本
超参数：learning_rate=2e-4, epoch=3-5, batch_size=4-8
评估：使用 HELM、BLEU 等指标综合评估
部署：合并 LoRA 权重到基础模型

总结

LoRA 和 QLoRA 让普通开发者也能在消费级 GPU 上微调大模型。掌握这些技术，能够更好地定制属于自己的 AI 助手。

什么是自适应网格布局？深入理解CSS grid-template-columns 属性

Wed, 18 Mar 2026 14:33:06 +0800

一、什么是grid-template-columns？

grid-template-columns 是CSS Grid布局中最核心的属性之一，用于定义网格容器的列数和每列的宽度。 Grid布局将容器划分为行和列的二维网格，而该属性专门控制列的维度，配合 grid-template-rows（控制行）可以灵活构建各种复杂的布局结构。

二、基本语法

语法格式：grid-template-columns: [值1] [值2] [值3] ...;

每个值代表一列的宽度，多个值之间用空格分隔，有多少个值就会生成多少列。

三、常用取值方式

1. 固定长度值（px、em、rem等）

直接指定每列的固定宽度，适用于列宽固定的场景，缺点是无法自适应容器宽度。

示例代码：grid-template-columns: 100px 200px 150px;

/* 容器样式 */
.grid-container {
    display: grid;
    grid-template-columns: 100px 200px 150px;
    gap: 10px; /* 网格项间距 */
}
/* 网格项样式 */
.grid-item {
    background-color: #3498db;
    color: white;
    padding: 1.5rem;
    text-align: center;
}

效果：生成3列固定宽度的网格，列宽分别为100px、200px、150px，不会随容器宽度变化。

2. 比例值（fr）

fr 是Grid布局的专属单位，表示“剩余空间的比例”，会根据容器宽度自动分配空间，是最常用的自适应取值方式。

示例代码：grid-template-columns: 1fr 2fr 1fr;（总比例4份，列2占2份，列1、3各占1份）

.grid-container {
    display: grid;
    grid-template-columns: 1fr 2fr 1fr;
    gap: 10px;
}

效果：3列网格按1:2:1的比例分配容器宽度，容器宽度变化时，列宽也会按比例自适应。

3. repeat() 函数

当多列宽度相同时，使用 repeat(重复次数, 宽度值) 简化代码，提升可读性。

示例代码：grid-template-columns: repeat(3, 1fr);（等价于 1fr 1fr 1fr）

.grid-container {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    gap: 10px;
}

效果：生成3列等宽的自适应网格，代码比直接写3个1fr更简洁。

4. minmax() 函数

minmax(最小值, 最大值) 定义列宽的范围，列宽会在最小值和最大值之间自适应，常用搭配 fr 使用。

示例代码：grid-template-columns: minmax(100px, 1fr) 2fr auto;

.grid-container {
    display: grid;
    grid-template-columns: minmax(100px, 1fr) 2fr auto;
    gap: 10px;
}

效果：

列1：最小宽度100px，最大宽度为1fr（剩余空间的1份）；
列2：占剩余空间的2份；
列3：宽度由内容自动决定。

5. 其他特殊值

auto：列宽由内容或容器自动决定，会自适应填充剩余空间；
%：按容器宽度的百分比设置列宽，例如 grid-template-columns: 20% 50% 30%;。

四、使用注意事项

使用 grid-template-columns 前，必须先给容器设置 display: grid; 或 display: inline-grid;，否则属性无效；
当列宽总和超过容器宽度时，网格会溢出，可配合 grid-auto-flow: dense 或 overflow 属性处理；
fr 单位会优先分配“非固定宽度”的剩余空间，混合使用固定值和fr时，固定值会先占用空间，剩余部分再按fr比例分配。

Cursor年度会员踩坑：付费不到半个月，账户被锁还多花100+美元

Sun, 15 Mar 2026 14:17:02 +0800

家人们避坑！跟大家唠个Cursor的小糟心事儿，Cursor用了几个月一直觉得顺手，也没出过啥问题，所以今年2月23日干脆直接冲了192美元的年度会员，本以为能安安稳稳用一整年，享受充足的token配额，结果万万没想到，付费还不到半个月，我的账户就被锁死，彻底用不了了！

升级年度会员没几天，我随手查看账户状态，当场就懵了——我的账号里居然同时挂着两个活跃订阅，一个是刚升级的年度计划，另一个是之前一直在用的月度计划（20美元/月）。按道理说，升级年度计划后，月度计划应该自动取消才对，还好我发现得及时，赶紧找Cursor客服反馈，客服很快帮我取消了月度订阅，当时还想着总算解决了一个小问题。

可没等我松口气，账户里又冒出了好几笔逾期账单，仔细一看，全是按需使用（On-Demand Usage）的费用，加起来居然超过100美元！这就很离谱了，我升级的年度会员明明包含380M的token配额，平时用着也很克制，压根没料到会产生这么多额外费用，更关键的是，我全程不知道系统居然默认给我开启了按需使用功能，连个提醒都没有，纯纯稀里糊涂被收费。

更坑的还在后面，因为这些逾期账单，我的账户直接被系统锁死了。我想进去关掉按需使用功能、设置使用限额，根本进不去账单设置页面，硬生生陷入了“账户被锁→关不了按需功能→可能继续产生额外费用”的恶性循环，只能被动吃亏，一点办法都没有。

之后我找客服沟通了好几次，跟他们说这是我第一次遇到这种账单问题，也承诺只要账户解锁，我立马关掉按需使用功能，继续做他们的长期用户，希望他们能减免部分不合理的费用，顺便解锁我的账户。但客服的回复全程都很敷衍，只一个劲儿说“理解我的感受”，却不给任何实质性的解决方案，还说这些费用是账户实际使用产生的，他们需要支付底层服务商成本，不能减免。

现在的处境就是，我花了192美元买了全年的年度会员，结果只用了不到半个月就被锁了，用不了服务不说，还得额外支付100多美元的冤枉钱，主打一个无奈又离谱😮💨 真心给正在用Cursor或者准备升级会员的朋友提个醒：升级会员后，一定要第一时间检查自己的订阅状态和账单设置，确认按需使用功能有没有被默认开启，别像我一样踩坑！后续我还会继续跟客服沟通，有进展的话会及时更新，有同款遭遇的朋友也可以在评论区交流，互相避坑～

在 PHP 中写真正的异步代码 TrueAsync 0.6.0 已支持数据库链接池

Sun, 15 Mar 2026 11:23:06 +0800

在 PHP 中写真正的异步代码 TrueAsync 0.6.0 已支持数据库链接池

现代软件的构建最终仍然要回到实践。再复杂的产品，也必须经过真实用户的检验。只有最终用户，才能真正区分哪些设计是有效的、哪些方向值得继续推进。再优雅的架构，如果没有落到真实代码和真实问题里，就很难体现实际价值。

完全异步化的 PHP Core

0.6.0 中最激进的一项变化，是 PHP 核心已经实现了完整的异步化。

长期以来，PHP 的运行模型一直以同步阻塞为主。一次 I/O 操作往往会直接阻塞当前执行流程，直到操作完成。而在这个版本中，这种情况已经发生了根本变化。

文件 I/O、socket、pipe、STDIO、STDERR、CURL 等能力现在都可以真正并发执行。无论是打开一个进程、读取文件，还是发起 HTTP 请求，这些操作都会运行在内部的 EventLoop 之下。不需要额外包装器，也不需要专门适配器，普通 PHP 函数本身就可以在协程中以异步方式运行。

一套新的异步编程 API

目前可用的核心能力包括：

Coroutines：通过 spawn() 启动异步任务
Future：一种更便于处理异步结果的 Promise 变体
Awaiting：包括 await、await_all()、await_first_success()、await_any_of()、delay()、suspend()
Channels：通过 Channel 在协程之间传递数据
Cancellation：提供 cancel()、protect()、timeout() 等一次性取消能力
Scope：用于管理一组协程的生命周期
TaskGroup / TaskSet：提供结构化并发能力
Context：为协程绑定上下文数据
iterate()：并发处理集合
Pool / PDO Pool：资源池与数据库连接池

PDO Pool：开箱即用的连接池

0.6.0 的一个亮点，是 PDO 现在已经支持内建数据库连接池。

 = new PDO('mysql:host=localhost;dbname=app', 'root', 'secret', [
    PDO::ATTR_POOL_ENABLED => true,
    PDO::ATTR_POOL_MIN => 2,
    PDO::ATTR_POOL_MAX => 10,
]);

开发者只需要在创建对象时增加几个参数，剩下的交给池本身处理即可。连接池会自动为每个协程分配独立连接，并在协程结束后归还。事务天然隔离；如果某个协程结束前没有显式调用 commit()，连接池还会自动执行回滚。

如何试用

最快的试用方式仍然是 Docker：

docker pull trueasync/php-true-async:0.6.0-php8.6
docker run --rm trueasync/php-true-async:0.6.0-php8.6 php -v

在 Linux 和 macOS 上，也可以通过安装脚本从源码编译 PHP。

你的 AI 代码审查员没有人可以反驳

Sat, 14 Mar 2026 09:37:27 +0800

你的 AI 代码审查员没有人可以反驳

让 AI 审查你的代码，你得到的只是一个模型的观点。一次对差异的检查。无论它首先关注什么。

有时这样就可以了。有时它确实能发现问题。

但如果你曾经在一个有强大审查文化的团队中工作过，你就知道最好的审查并不是这样工作的。最好的审查发生在具有不同关注点的人查看相同的代码，然后就他们发现的问题进行争论时。

安全人员标记了某个问题。架构师说："实际上这没问题，因为我们是这样构建 X 的。" 质量工程师注意到他们两人都忽略了一个连接这两个发现的错误处理漏洞。这种对话揭示了任何单个审查员都无法单独发现的问题。

这种来回交流才是真正的信号所在。而我试过的每个 AI 代码审查工具都完全跳过了这一点。

单次检查只是带有更好营销的抛硬币

让我对当前这一批 AI 审查工具感到困扰的是：

它们都在做本质上相同的事情：获取一个差异，将其扔给一个模型，然后漂亮地格式化输出。有些添加了项目上下文。有些并行运行多个检查。但归根结底，你得到的是单一的、未经争议的观点，没有人质疑这些发现是否真实。

你知道从未经争议的审查中能得到什么吗？误报。幻觉般的发现。表面级别的挑剔被包装成关键问题。偶尔，在噪音中埋藏着真正有用的反馈。

听起来熟悉吗？应该是的。这也是为什么单个人类审查员对于重要代码来说是不够的。几十年前我们就用多人审查的概念解决了这个问题。只是我们花了一段时间才将同样的逻辑应用到 AI 版本上。

如果审查员们真的互相交流呢？

这就是促使我开发 Open Code Review 的问题。

我最初将其作为内部工具为我们团队构建，因为我们对上述问题感到沮丧。想法非常简单：如果我们像高性能工程团队实际做的那样来构建 AI 代码审查会怎样？

所以它是这样工作的：

你配置一个具有特定角色的审查员团队。架构、安全、代码质量、测试，任何对你的代码库有意义的自定义角色。
每个审查员独立进行他们的检查。不同的关注点，不同的重点领域，不同的发现。
然后是真正重要的部分：一个结构化的讨论步骤，让他们互相辩论各自的发现。同意、挑战、连接相关问题、揭示新问题。
只有在这之后，最终的综合才会产生你实际看到的审查。

可定制到极致（或者直接使用默认设置）

你的代码库不是通用的，你的审查团队也不应该是通用的。

它了解你的需求，而不仅仅是"最佳实践"

这是让我对大多数审查工具感到恼火的另一件事。它们根据通用的最佳实践评估你的代码，而对你实际想要构建的东西没有任何概念。

OCR 允许你传入规范、提案、工单中的验收标准，或者其他任何内容。

每个审查员都会根据他们的专业知识和你声明的需求来评估代码。最终的综合包括需求验证，显示哪些已满足，哪些存在差距，哪些是模糊的。

如果你正在进行任何形式的规范驱动开发，这一点就真的很重要了。

无缝集成，不干扰工作流

我无法足够强调这一点对现有工作流的干扰有多小。这是一个核心设计目标。

那么它真的更好吗？

我们的团队再也没有回到其他任何工具。审查质量根本不在一个水平线上。

我认为这归结为一件非常简单的事情：有争议的观点比无争议的观点更有价值。无论模型有多聪明，如果在到达你之前没有任何东西对其发现提出质疑，你就会花时间过滤噪音，而不是处理真正的问题。

让审查员先争论。在成为你的问题之前先把噪音去掉。

现代响应式网站设计的最佳实践与技术选型

Fri, 13 Mar 2026 10:15:31 +0800

现代响应式网站设计的最佳实践与技术选型

在当今移动互联网时代，响应式网站设计已成为企业在线展示的标配。一个优秀的响应式网站不仅能提供良好的用户体验，还能显著提升搜索引擎排名和转化率。

响应式设计的核心原则

移动优先策略：从最小屏幕开始设计，逐步增强到更大屏幕。这种方法确保核心内容在所有设备上都能完美呈现。

弹性网格布局：使用CSS Grid和Flexbox创建灵活的布局系统，让页面元素能够根据屏幕尺寸自动调整。

媒体查询优化：合理设置断点，避免过度复杂的媒体查询，重点关注主流设备的屏幕尺寸。

前端技术栈选择

现代网站开发有多种技术选择：

Vue.js：轻量级、易上手的渐进式框架，适合中小型项目快速开发
React：组件化开发的标杆，拥有丰富的生态系统
静态站点生成器：如Next.js、Nuxt.js，提供优秀的SEO支持和性能优化

后端架构考量

网站的后端技术同样重要：

PHP：成熟稳定的服务器端语言，WordPress等CMS系统的基础
Node.js：JavaScript全栈开发，适合实时应用和API服务
Python：Django和Flask框架提供快速开发能力
Golang：高性能并发处理，适合高负载网站

性能优化要点

网站性能直接影响用户体验和SEO排名：

图片懒加载和WebP格式转换
CSS/JS文件压缩和合并
CDN加速静态资源
服务端渲染(SSR)提升首屏加载速度

专业网站建设服务

对于企业而言，专业的网站建设不仅需要技术实力，更需要对业务需求的深入理解。西安尊云科技（https://zunyunkeji.com）作为专业的网站建设服务商，拥有丰富的行业经验和完整的技术栈能力，能够为企业提供从需求分析、UI/UX设计到开发部署、后期维护的一站式解决方案。

无论是企业官网、电商平台还是定制化Web应用，西安尊云科技都能根据客户的具体需求，选择最适合的技术方案，确保网站的稳定性、安全性和可扩展性。

总结

响应式网站设计是一个系统工程，需要前端、后端、设计和运维的协同配合。选择合适的技术栈和专业的开发团队，是确保网站成功的关键因素。随着技术的不断发展，网站开发者需要持续学习和适应新的工具和最佳实践。

价值十亿美元的三个词：向确定性漂移（DriDe）

Sun, 08 Mar 2026 09:10:02 +0800

价值十亿美元的三个词：向确定性漂移（DriDe）

我怀疑我不是第一个想到这个概念的人，但我可能是第一个给它命名的人。

向确定性漂移（DriDe - 读作"DRY'd"，即"Don't Repeat Yourself"不要重复自己）是每个人在两年内都会做的事情，我告诉你现在就开始。

如果要用一句话解释：我建议，当大多数人都在尝试添加更多AI然后加以保护时，我们应该以一种方式构建系统，随着时间推移，尽可能完全地将AI从系统中写出去。

#ok聪明的家伙什么是向确定性漂移

好吧，聪明的家伙 - 什么是向确定性漂移？

这可不是《速度与激情3》期待已久的第二部（可惜啊 - 但这会是个超棒的片名对吧？）。

不，这是一种关于如何思考AI的哲学。

现在大家都在使用AI代理系统，像明天就没法用似的疯狂消耗token。

看到有人花20美元来设置一个买牛奶的提醒就让我心痛（是的，真的发生了...每30分钟的心跳检查时间就在消耗token！）。

我相信我们很快就会从这个"所有问题都用AI解决"的狂热梦境中醒来，意识到有一个简单的流程可以让我们以极小的成本和环境影响做几乎任何事情。

简单步骤：

给AI代理系统一个它以前没见过的"新奇"任务，让它消耗大量token来解决它。
在末尾放置第二个代理系统，观察哪些部分本可以通过确定性方式（即代码）解决。
为可重复的部分构建工具。
下次遇到类似任务时 - 在第一步就提供这些工具。
如果我们总是使用tool1然后传给tool6 - 就把它们直接连接起来。
重复这个过程，直到你尽可能地将AI从流程中完全移除。
还有很多细节，比如如果工具没有给出正确输出就回退到AI、运行工作流的影子版本来检查我们是否真的在改进、提供最终输出反馈来进行微调、生成LLM能够理解的系统、全程跟踪流程...但你能搞定这些对吧 :-)

随着时间推移，你那些耗资50美元运行、只有50%成功率、还需要你不断提示才能保持正轨的AI驱动的非确定性工作流，会变成华丽的自动化流程，只需0.02美元的AI成本进行分类，然后完全通过代码运行。

它更快、更一致、更值得信赖。

这就是我们要去的方向。

#是的人们在构建技能和工具这里有什么新意

这正是关键所在 - 我们已经有了让这工作所需的大部分东西，但在如何对待它们方面从根本上错过了要点。

没有人，我是说真的没有人，有明确的目标要将AI从当前用AI完成的流程中写出去。

你给我举一个在过去一年中使用AI更少的工具/产品。

来吧，我在等。

而这正是我所提议的。

你用AI来勾勒出一个流程的大致轮廓。它很昂贵、很慢（相比代码），但它解决了重复性的业务流程问题。

然后，你分析这个流程。我真的需要把公司12000行客户列表全部传给AI来知道下一个该打给谁吗？不需要，一个简单的工具就能获取一个月内未联系的前5个人。

我甚至需要把这个工具给代理吗？不，我应该把它作为上下文的一部分，这样它就有这些信息，我们还能节省大量的往返通信。

等等，我们要给AI一个工具去查看他们的网站？如果我们需要这些信息，我们应该自动获取并将其输入到上下文中。

等等，我们之前扫描过他们的网站？我们有这些信息？我们甚至根本不需要启动AI？

你明白我的意思了。

#结晶化是关键

每次你调用AI，你都在掷骰子 - 字面意义上的。

它已经变得好多了，但它过去是、将来也永远是一个非确定性系统。无论你如何精心设计提示，它总会给出不同的输出。

有时你确实需要AI的力量 - 比如处理自然语言（或者真的需要吗？）

或者编写代码（或者真的需要吗？）

每次你调用AI时，都要质疑有多少部分真的需要完全自主地使用LLM，有多少部分是确定性的步骤。

编写代码 - 我们拥有世界上所有的代码片段，每个挑战都可以分解成已经存在并经过实战检验的代码。我们只需要以不同的方式将它们连接起来。

那么我们应该让AI编写代码，还是给它我们已知有效的代码，让它连接起来解决新问题？

处理自然语言？我们已经有基于代码的工具可以完成LLM70%的工作 - 为什么不先让它们进行初步处理，然后找到需要集中LLM力量的区域，从而减少上下文大小、成本和遗漏关键信息的几率？

结晶化你的流程。让它尽可能地确定性和可重复。

#听起来工作量很大

好吧，是的，某种程度上是这样。

目前确实存在能力差距，LLM在识别流程优化点方面还不错，但在创造性地找出哪些部分最适合优化方面还不够。

它仍然需要人类的判断和指导（万岁 - 我们现在还是安全的！）。

但它肯定可以观察自己做了什么，然后给你指出需要关注的领域。

它肯定可以接受你的判断并提供可能的解决方案。

它只需要你的大脑来决定做什么、用什么方法、以及函数/步骤要做得多专门化或多通用化。

一旦你构建了足够多的这些工具（技能、MCP、工作流，随便你怎么叫），你就可以教它构建自己的工作流。

那时你将成为工作流的评判者，而不是各个部分的评判者。

#我的预测

在2-5年内，你会坐在终端前面对一个业务上的新问题。我们需要自动对账银行账户用于会计。

你解释期望的结果，提供好坏结果的示例、数据等。

AI会查看它所有的工具，并为你构建一个实现此目标的工作流。它还没有所有需要的工具，所以仍然会使用视觉模型、擅长分类的LLM等。

你会在测试模式下运行它，与AI合作调整边缘情况，然后运行它。它完成了工作，你将它推送到"影子模式"，与当前流程并行运行。

现在它开始将自己从流程中优化出去。

它使用OCR和模式匹配为每个供应商的发票格式构建单独的解析器，在毫秒级别处理每张发票。它拉取银行回单并将金额与发票进行对比，全部通过代码完成，LLM甚至不会启动，除了触发"对账流程"。

它的效果与当前流程一样好，准确率达到99%以上，因为我们使用确定性步骤处理了99%的工作流。

三个月后，我们输入的某个文档格式发生了变化 - tensorflow OCR工具无法找到发票号码。它回退到视觉模型来定位发票号码的新位置。它提示你"嘿，看起来供应商X的发票格式改变了 - 这个号码对吗？"，同时显示发票截图和相关项目的高亮。

你告诉它可以继续，它自我修复并完成本月的银行对账。

对比一下我们目前设想的做法：为每张发票调用视觉模型，给LLM提供相应的工具。然后我们给它一个读取银行交易的工具 - 将私有数据发送到云端。然后它把发票号码和账号搞混了，请求帮助，我们提示它，它更新了指令集，却在下一张发票上再次失败。

这种方式成本高昂、速度慢、容易出错，虽然比我们以前完全人工的流程要好，但远非理想状态。

#我对LLM的看法

LLM输出的每一个token都是一个故障点。

即使我们将LLM的准确率提高到99.999%（这会很棒对吧？），如果你的工作流有10000次传递，你的输出准确率会是多少？

不是99%，而是90%。（0.99999^10000 = 90%）

90%的准确率会毁掉业务：你会被起诉或破产。

但如果你构建LLM系统时给LLM一个单一目标："让自己变得多余" - 那么你就能蓬勃发展。

你可以从企业中消除所有的繁琐事务，消除所有投入到忙碌工作的人力。

LLM给了你将自动化构建成本降低到以前1%的能力。

小企业可以以前所未有的敏捷性与大玩家竞争。

但前提是他们的系统必须稳健。

#所以你在构建幻觉工厂还是确定性发电机

那么，你是在构建一个幻觉工厂还是确定性发电机？

你是在构建一个消耗token、掷骰子的怪物？

还是在构建一个精简、防弹的低效替代品？

可能介于两者之间，但如果你在做每件事时的指导原则都是DriDe - 那么当你向确定性漂移并避免重复自己时，你将获得优势。

你将拥有一把锋利的手术刀来自动化关键工作流，而你的竞争对手还在用钝器猛击他们的流程，走向灾难。

成本的降低、确定性的增加、诉讼的避免 - 所有这些都来自三个词，其价值绝对值十亿美元。

让DriDe指引你走向成功，今天就开始漂移吧。