用 Caddy 和脚本替代臃肿的控制面板

多年来，我在 OpenLiteSpeed 上运行 WordPress 站点。快速的服务器，LSCache 真的令人印象深刻，OLS/WordPress 的组合在原生性能上难以被击败。对于控制面板，我最初使用了 CyberPanel——比微软产品还要漏洞百出，其团队似乎刻意破坏免费功能，来逼迫用户升级到付费计划。我说的不是那些无法修复的 bug。我说的是那些似乎被工程化的 bug，专门用来阻止免费层级功能完成任何操作。

两个例子。WordPress 安装：我多年没有问题地使用过它。自从 CyberPanel v2.4.x 之后，一个 SQL 错误阻止了最后一步。文件都在那里，已完全下载，但你必须手动创建数据库并自己运行安装。轻描淡写地说，这很不直观。

第二个例子：Let's Encrypt SSL 证书生成，因为生成的配置文件不正确而持续失败。在这两种情况下，都有一个付费的"增强"版本可用。理所当然。

我的立场很简单：如果一个功能曾经能用多年，现在却不能用了，我无法保证付费版本能用——或者条款明天不会改变。这是诱饵转换吗？我不会明确说。但当一个免费功能曾经能用多年，然后在连续多个版本中停止工作，而付费替代品涵盖相同范围——这个问题就自己回答了。我问过它，得出了我的结论，然后将供应商加入黑名单。

所以我转向了 aaPanel：更舒适，更稳定，更轻量。但对 OLS 管理采用了完全失控的方法——你无法直接配置 OpenLiteSpeed，一切都通过 aaPanel 的抽象层，你失去了对自己堆栈的控制。直接接触端口 7080，你就冒着破坏一切的风险。你使用 aaPanel 仪表板。就这样。

然后我的使用场景转变了。更多的 Astro，更多准静态站点，更多不需要 PHP 的项目。一旦你踏出 WordPress 周边，OLS 就失去了吸引力。另一方面，Caddy 自动处理 HTTPS，其配置可以用几行可读的代码完成，并且没有 OLS 的重写怪癖。

问题变成了：你能用 Caddy 和一个控制面板替代 aaPanel/OLS 吗？GitHub 上有一个——CaddyManager，1.1k stars，单一贡献者，永远处于"早期开发"。还有 CaddyGen，一个用 8 小时建立的 Caddyfile 生成器——更多是概念证明而不是完成的产品。没有生产就绪的东西。

结论很明显：写得好的 shell 脚本和一个最小的 FastAPI 接口就能完成工作——而且会无限地更易维护。只是有人必须写它们。

与其自己写，我想过把规范交给 GitHub Copilot CLI。或 Claude Code。但考虑到 Copilot 的新定价，刚好让你沾一点就账单就来了……我对 OpenCode 和 Kilo CLI 感兴趣了，接入 DeepInfra 或 OpenRouter。我决定把它作为一个基准。

📋 TL;DR：在一个真实 VPS 项目上测试了 8 种工具/模型组合。两个阶段——架构然后代码。一个独立的外部审查来确定胜负。唯一被判定生产就绪的工具包总成本为 $1.94。获胜的模型？你可能在常见的比较中没有见过它。

💡 阅读说明：直到第 5 节，为代码阶段选定的四个实现被标识为 A、B、C 和 D。模型名称在外部审查裁决后被揭示——原因与你在陪审团中匿名化的原因相同：在读标签前读代码。

这个 brief 故意很具体：一个用于 Ubuntu 24.04 的最小 VPS 管理工具包。Caddy 作为 web 服务器，两个版本的 PHP-FPM（当前版本和备用版本），MariaDB 和 PostgreSQL，Valkey 用于对象缓存。所有操作的 Shell 脚本，一个用于自动化的 FastAPI 接口。没有 Docker，没有控制面板，没有不必要的抽象。

四种网站类型需要处理：static（仅 HTML/资产，无 PHP，无数据库）、PHP（自定义应用，可选数据库）、WordPress（通过 WP-CLI 完整安装，需要数据库）和反向代理。最后一个值得注意：它只是一个 Caddy vhost，将请求转发到本地端口——一个运行在同一服务器上的 Node.js、FastAPI 或 Go 应用。Caddy 处理 HTTPS 和域名；应用不需要关心。没有 PHP-FPM，没有数据库——只是一个 reverse_proxy 块和一个端口号。

预期的操作覆盖完整生命周期：服务器引导、站点配置、删除（任何破坏性操作前自动备份）、按需数据库创建、通过 rsync 的静态部署、备份和服务管理。

为什么用真实项目而不是合成基准？因为合成基准测试模型在理想条件下能做什么。真实项目测试它们在约束堆积时能做什么——安全性、幂等性、跨文件一致性、shell 和 Python 层之间的错误处理。这就是差异出现的地方。

完整的功能 brief 可在项目的 GitHub 仓库中获得。

该协议在两个不同的阶段运行，由人工验证分隔。

阶段 1——架构

将相同的功能 brief 提交给每个工具/模型组合。没有额外上下文，没有配置文件，没有关于预期解决方案的提示。该工具提议一个架构、一个项目结构、一个脚本及其职责列表、一个 API 路由图。如果设计得很好，它会在生成任何东西之前询问问题。

阶段 2——实现

一旦计划被验证和决策确定，一个单一的开发提示被提交给所有工具。它包括验证的架构、十个确认的技术决策、脚本→API 退出码约定，以及一个明确的指令：将三十个文件依次交付到磁盘，无摘要，无捷径。

Devstral 2（123B）被计划了。不幸的是，该模型没有出现在 OpenCode 或 Kilo CLI 的模型选择器中——两者都从 models.dev 提取其目录，尽管它可在 OpenRouter 上使用，但还没有被索引。通过 OpenRouter 游乐场的测试确认该模型可通过 API 访问，但在一个编码智能体之外，它会失去我们试图测量的大部分内容。Devstral 2 缺席纯粹是出于技术原因，而不是质量原因。

Haiku 4.5 出现了三次——在三个不同的工具上。这是故意的：这正是让我们独立于模型隔离工具影响的东西。

代码阶段在四个代表性实现上运行，在第 5 节的揭示之前标记为 A、B、C 和 D。

四个实现生成的代码被提交给基准中没有的模型，带有一个固定的评估网格：安全性、正确性、幂等性、代码质量、完整性。每个实现五个代表性文件，满分 25 分。

3. 规划阶段——谁真正思考？

功能 brief 向每个工具提出了一个隐含的问题：当被交给一个没有预先烹饪的解决方案的开放式项目时，你做什么？

你注意到的第一件事——这很显著——是测试的模型都没有在生成计划前提出他们的问题。没有一个。他们都先交付一个完整的架构，然后在最后才要求澄清。这与人类建筑师的做法相反，人类建筑师会在绘制任何东西之前对歧义进行阻止。

这很重要。几个在事后提出的问题本应在前期询问时改变架构决策。一个模型识别了"磁盘上无秘密"和应用配置文件（合理需要凭据）之间的张力——wp-config.php 是明显的例子。这是一个真正的阻止问题。在计划后提出，它就变成了一个脚注。

计划揭示的内容

问题质量是第一个区分信号。两个模型提出了四到五个真正阻止的问题，框架有选项和建议。另一个提出了八个通用问题——归档格式、日志轮换——在架构上不会改变任何东西。

提议的结构是第二个信号。只有一个模型自发地提议了一个统一的 CLI 入口点——bin/vpsmgr——来分派到脚本。这是将脚本集合变成一个连贯工具的细节。其他的没有想到。

一个模型是唯一从规划阶段提议一个规范化的、文档化的退出码约定的：

这不是化妆品。这是 shell 脚本和 FastAPI 层之间的约定——没有它，HTTP 映射就变成任意的，每个路由都不同地实现它。

Gemini 3.1 Pro 生成最简洁的输出——一个质量计划的 27k tokens。OpenCode 上的 Haiku 4.5 消耗 69k tokens 的质量较低。Token 量不预测质量。

4. 代码阶段——谁真的交付？

代码阶段从提交给四个选定实现的单一开发提示开始。它包括经过验证的架构、十项确认的技术决策、退出代码约定，以及一条明确的指示：将三十个文件按依赖顺序交付到磁盘，不要摘要，不要走捷径。

这是不同模型之间差异变得具体的地方。

common.sh 揭示的内容

共享库是交付的第一个文件。它是其他所有内容的基础——日志记录、密钥处理、站点状态管理、密码生成。一个有缺陷的 common.sh 会污染每个源它的脚本。

模型 A 交付 98 行简洁代码。密钥编辑明确涵盖所有十个 WordPress 模式——salts、authentication keys。在这一特定点上最完整。但没有域名验证、没有 require_cmd()、没有原子状态文件写入。

模型 B 交付 310 行代码。带 readonly 的命名常量、带 RFC-1035 正则表达式的 normalize_domain()、并发锁、使用 mktemp+mv 的原子写入。最富有的系统实用工具库。但密钥编辑遗漏了 WordPress salts。

模型 C 交付 366 行代码。编辑模式可通过环境变量配置——不硬编码。纯 shell JSON 助手，如果 jq 不存在则回退到 Python。按开发提示的规范用 <<>> 标记包装输出的 print_credentials()。用于配置文件的 render_template()，无 Jinja 依赖。不包括有歧义字符的密码生成（0/O/1/l/I）。唯一预见开发提示中记录的每个边界情况的实现。

模型 D 交付 184 行代码。基准测试中最独特的想法：将退出代码封装在命名函数中——exit_input_error()、exit_conflict()——比裸 exit 3 调用更可读。直接在 common.sh 中的 json_output()，从 shell 生成 API 就绪的 JSON。没有原子写入，没有 require_cmd()。

你自己发现的 Bug——或者没发现的

模型 C 在会话期间测试自己的代码。写完 schemas.py 后，它使用测试用例运行它，发现两个 bug，并立即修复：一个 Pydantic v2 验证器实现不正确（field_validator 而不是 model_validator 用于跨字段验证），以及未在模式级别强制实施的互斥。它还修复了 render_template() 中的 sed 替换问题——在路径中的 / 处中断——用纯 bash 参数展开替换。

在会话结束时，模型 C 交付验证摘要：所有脚本上的 bash -n，所有文件上的 Python AST，19/19 API 路由通过 OpenAPI 规范验证，18/18 bash 助手已测试，PHP 回退规则已验证（8.5→8.4，8.4→none，7.x rejected）。

模型 A 在完成前检查它的 shebangs。模型 B 交付精良的用户文档——故障排除、curl 示例、快速开始。模型 D 验证 bash 和 Python 语法。三者都没有测试功能逻辑。

模型 D 在 9m42s 内交付模型 C 在 23m37s 内交付的内容——但没有功能测试。模型 C 消耗 3.4 倍更多令牌，因为它在会话期间执行代码，在每次迭代时重新加载上下文。

5. 外部审查——和结果揭晓

四个实现，四种安保方法。为了不带偏见地解决这个问题，代码审查被提交给不在基准测试中的模型，使用固定网格评估五个标准。每个实现五个代表文件——common.sh、site-create.sh、site-delete.sh、backup.sh、api/runner.py——二十个文件在单次加载中。

审查成本：$0.0766 用于 543k 令牌。比初级开发人员一小时的时间便宜十倍。

单个文件观察

在 site-create.sh 上，审查者在模型 D 中发现一个隐蔽的 bug：SFTP 密码已生成但从不捕获或返回给调用者。用户永远看不到他们的凭证。核心功能在没有错误信息的情况下被破坏。在模型 B 上，local 在三个脚本中的函数外使用——一个导致运行时失败的 bash 错误。这些不是微妙的 bug：它们是阻碍。

在 site-delete.sh 上，模型 C 是唯一处理两种调用模式的——交互 TTY 和用于非交互 API 调用的 --confirm 标志。模型 D 仅实现交互模式，使用 skip-backup 的 API 驱动删除被阻止。

在 backup.sh 上，模型 A 和 B 使用 eval "$POST_HOOK"——潜在的命令注入。模型 C 将存档路径作为参数传递——更安全。模型 A 不实现自动存档修剪。

在 api/runner.py 上，模型 C 是唯一使用 asyncio 且从不记录 stdout 的——stdout 可能包含凭证。模型 D 有死代码：定义了 build_command() 但从未调用。模型 A 交付 28 行没有超时、没有日志记录、没有错误处理——挂起的请求会无限期地阻止 API。

即插即用的生产就绪：四个中的一个。模型 C，25/25。

模型 B——Claude Code + Haiku 4.5——在实际边际成本上最昂贵，Pro 订阅最低 $20/月。它得分 12/25，由于 bash 基础错误不可部署。模型 C——来自清华大学 THUDM 实验室的 GLM 5.2——得分 25/25，是审查者认为生产就绪的唯一一个。它花费 $1.73。

附录——模型 E：Kimi K2.7 Code

在发布后应读者评论指向该模型后添加。相同协议，相同开发提示，相同 Qwen 3.7 Plus 审查网格。

外部审查得分：19/25

生产就绪：否。阻碍问题：数据库密码作为参数内联传递给 mysql -e 和 psql -c——对系统上任何用户的 /proc/*/cmdline 可见。修复很直接（MYSQL_PWD / PGPASSWORD 作为环境变量），但没有应用。

根据审查者的说法，基准测试中最模块化的架构——干净的 lib/ 分离、一致的幂等性模式。但安全间隙阻止它挑战 GLM 5.2。

排名中的位置：在 DeepSeek V4 Pro（$0.24，12/25）和 GLM 5.2（$1.73，25/25）之间，在两个轴上。比模型 B 和 D 有更好的架构/成本比率，但不生产就绪。

附录 2——多审查者验证

在评论中的读者建议之后，盲审被扩展到两个额外模型：GPT-5.3 Codex 和 Gemini 3.1 Pro Preview。相同协议，每个实现五个相同文件，相同评分网格。

三审查者对比揭示的内容

排名 C > E > D > A > B 在所有三个审查者中都成立——原始结果是稳定的。

GLM 5.2 是唯一在两个独立审查者中得分 25/25 且被两个中的两个认为生产就绪的模型。GPT Codex 整体上是最严格的审查者——没有模型通过它的生产就绪门槛，包括 GLM 5.2，它被评为 17/25，引用 site-create.sh 中的参数解析 bug 和 common.sh 中缺失的 set -euo pipefail。这些是真实问题；Codex 审查可以说是三个中最严格的。

主要分歧在模型 B（Claude + Haiku）上：Qwen 和 GPT Codex 都是 12/25，但 Gemini 是 18/25，它对回滚逻辑和 shell 结构的评价更慷慨。Gemini 还将 Kimi K2.7 评为 21/25，有条件的生产就绪判决——比 Qwen（19/25，否）和 GPT Codex（13/25，否）更宽松。

方法论批评是有效的。单个审查者引入偏见。三个独立盲审查者在相同排名上收敛是比任何单个得分更强的结果。

6. 智能路由——真正的经济学

这个基准测试提出了一个隐含的问题：你需要用 GLM 5.2 做所有事情吗？

否。这可能是这项工作中最有用的结论。

GLM 5.2 以 $1.40/M 令牌计价是正确选择，当复杂性能证明它时——架构、安全、跨文件一致性、关键决策。但在真实项目中，这些任务代表交互的一部分。其余的是样板代码、小修正、文档、提交信息。

三个级别，三个模型

BigPickle 在完整的 32 文件实现上得分 15/25。它完全能够读取 50 行差异并编写充分的提交信息。调试 1064 You have an error in your SQL syntax 或 Fatal error: Call to undefined function。从现有代码生成 README。对于这些任务，GLM 5.2 的架构深度是过度的——BigPickle 是免费的。

DeepSeek V4 Pro 以 $0.44/M 令牌计价——比 Haiku 4.5 便宜五倍，比 GLM 5.2 便宜三到四倍——舒适地处理简单代码生成、CRUD、小的重构、内联文档、短脚本。其 9m42s 的代码阶段以 $0.24 用于 1.29M 令牌的表现证明了这一点。

当复杂性超过该范围时，GLM 5.2 发挥作用——架构设计、连贯的多文件实现、安全决策、非平凡的业务逻辑。

每个级别的任务比例取决于项目、开发周期中的位置和你认为复杂的内容。没有通用数字——每个团队根据他们的实际使用情况校准。

💡 值得注意的是：GLM 5.2 的成本远高于 BigPickle——在代码阶段处理 442 万 token，前者为 1.67 美元，后者为 0 美元。但纯文本输出——计划、架构、分析——消耗的 token 很少，成本几乎可以忽略不计：本次基准测试的规划阶段仅花费 0.06 美元。真正让账单攀升的是代码阶段，其中包含多轮迭代、会话内测试执行以及不断累积的上下文。所谓智能路由，正是把 GLM 5.2 留给那些确实需要超长上下文的任务，而将其他所有任务交给另外两个较低层级的模型。

令人不安的对比

GitHub 于 2026 年 6 月 1 日改为按 token 计费。Copilot 上的 Claude Sonnet 4.6，输入 token 的费用约为每百万 3.00 美元，输出 token 则约为每百万 15.00 美元。如果在 Copilot + Sonnet 4.6 上复现本次基准测试中的 GLM 5.2 会话——共 446 万 token——预计将花费 25 美元。而且还不包含功能测试，不包含自我纠错，也不包含外部评审。

每月 39 美元的 Copilot Pro+ 包含价值 39 美元的 AI 额度。像这样的完整会话会消耗每月预算的三分之二。改用新计费方式的当天，就有用户反映仅用两个提示词便耗尽了整月额度。

最终的成本比为：全流程 1.94 美元，对比 Copilot + Sonnet 约 25 美元。便宜了 13 倍，而且它还是唯一被外部评审认定达到生产就绪水平的结果。

1.94 美元。这就是本次基准测试从头到尾的总成本——包括规划、实现和外部评审。得到的还是唯一一套被评审认定达到生产就绪水平的工具包。

这个数字让 AI 编程工具市场感到不安，因为这个市场一直通过定价来传递一种可靠感。每月 39 美元的 Copilot Pro+、输出 token 每百万 15 美元的 Claude Sonnet，以及占据醒目位置的各大知名品牌——其背后的隐含假设是，质量会随着价格上涨。本次基准测试却表明，事实并非如此。

获胜者名为 GLM 5.2。其所属实验室 THUDM 隶属于清华大学。你可能没有在上周的对比文章中看到过它。它给出了唯一一套从规划阶段就采用标准化退出码约定的架构，完成了唯一一个会在会话过程中测试自身代码的实现，还提供了唯一一个支持可配置脱敏、并能在缺少 jq 时回退到 Python 的 common.sh。而且，它在交付前自行修复了三个 bug。

第一，模型的价格无法预测它在复杂任务上的输出质量。Haiku 4.5 在三种不同工具——Claude Code、Copilot CLI 和 OpenCode——上，以相同成本产出了完全相同的结果。在规划阶段——只生成纯文本，没有反馈循环，也不探索代码库——工具本身没有任何可测量的影响。真正重要的是模型。而基准测试中最不起眼的模型却占据了绝对优势。

第二，并非所有 token 都具有同等价值。规划阶段花费 0.06 美元，代码阶段花费 1.67 美元——相差 28 倍。这并非异常现象，而是由问题本身的结构决定的。一份计划只需要几千个用于推理的 token；一个完整实现则需要数百万 token，用来承载不断累积的上下文、已执行的代码以及反复迭代的测试。根据任务复杂度，在成本为 0 美元的 BigPickle、每百万 token 0.44 美元的 DeepSeek V4 Pro，以及每百万 token 1.40 美元的 GLM 5.2 之间进行智能路由——这才是这些工具真正的经济账。

VPS Manager 工具包的全部四个版本均已发布在 GitHub 上。

pcescato / LLM-Challenge

一项可复现的基准测试：让 8 种 AI 编程智能体与模型组合完成同一个真实项目，并比较它们的表现。

本仓库包含一项基准测试的全部产物。在该测试中，8 种不同的 AI 编程智能体与模型组合被要求构建同一套 VPS 管理工具包。其目标是在完全相同的条件下，衡量不同工具和模型在代码质量、架构决策以及生产就绪程度方面的表现。

这不是一次营销性质的对比。测试使用了一个具有明确需求的真实项目，并由一名外部评审人员进行结果评估；该评审人员并不知道每份实现分别由哪种工具或模型生成。

本次基准测试采用了两阶段流程：

第一阶段：架构。所有工具都收到相同的功能需求说明，并被要求产出一份架构文档。此阶段不编写任何代码。

第二阶段：实现。所有工具都收到相同的开发提示词，并被要求完成实现……

功能需求说明、提示词和评估表也都包含在其中。如果你想验证，整个测试均可复现。

太便宜，所以不可能好？这个问题从一开始就问错了。

部分评论可能仅对已登录的访客可见。登录后可查看全部评论。部分评论已被文章作者隐藏——了解更多

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。