> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh/2026-nian/w41-ge-ren-ai-shi-jian-gong-ju-gong-cheng-yu-yun-xing-huan-jing.md).

# W41-Side Project 总结：工具、工程与本机和云端的取舍

2026 年 10 月 10 日 · 10 月 13 日修订

中秋国庆长假去了金山岭阿那亚，挺适合家庭出行。回来后还有几天空闲，节后第一周工作也不算特别忙，正好把一些想做的事情往前推了推。

回头看，上周做的事情还不少。治理 AI 的运行环境，继续做家庭财务工程，替换用了多年的订阅管理软件，治理网络代理的可靠性，再跑一下自媒体的自动化流程。这些项目放在一起，也让我重新看了一遍这一年使用 AI 的方式。

之前写过把个人的事情工程化。当这些工程开始装进真实数据、接上真实账号，并且需要连续运行时，很多原来没怎么在意的问题就冒出来了。

## AI 运行环境维护

我的 Mac Studio 放在公司。平时下班回家或到了周末，我就会远程让它做些事情。国庆长假出发前，我想试试，这台机器能不能在十几天里持续保持可用，让我人在外面，也能随时调用它，做自己想做的事。

结果过了两三天就不太行了。期间 Claude 和 OpenAI 的模型有更新，部分客户端需要手动升级；一些登录态超时，要重新授权；机器上还有依赖 Chrome 自动化的任务，内存也需要清理。这些问题拆开看都不大，但人在外面时，只要一个环节卡住，后面的事情就没法继续。

所以回来第一天，我花了不少时间清理环境，顺便补上假期里的模型进展。

**机器通着电、网络连着，并不足以保证这套工作环境随时可用。**

这次之后，我给 AI runtime 增加了日常治理任务。一个方向是检查各个工具配置的模型，跟进同系列模型的更新；另一个方向是检查 Codex、Claude Code、Gemini 等运行时的版本，减少配置和工具版本逐渐脱节的问题。

这些事情以前往往是出了问题再处理。现在自己同时依赖的 AI 工具越来越多，维护它们也开始成为一项固定工作。尤其远程使用时，本地顺手点一下就能解决的授权和升级，都会放大成真正的阻塞。

## 家庭财务数据工程

家庭财务工程之前就提过，也已经起了一个基础。这次花了四五天，主要用 Claude 集中把它往前推进。大概完成了八成，花的时间明显超过最初的预期。

我想做的是把整个家庭财务情况放进一套可以持续维护的工程里，后面能够分析、监控、给出复盘依据，也能按需要生成不同的图表。真正动手之后，发现图表和分析只是其中一部分，底下的数据和规则才是大头。

比如隐私，最开始容易想到的是把金额藏好。后来细分下来，份额也不能随便公开，因为份额乘上公开净值就能反推出市值；一些比例和其他信息放在一起，也会暴露原本不打算公开的内容。只看单个字段，很容易觉得它没什么敏感的，组合起来就完全不同了。

再比如数据准确性。一条数据是什么时候发生的，什么时候录进去的，是实际观察到的、计算出来的，还是估算的，需要分开记录。修正一条旧记录，也要保留修正关系，而不是直接把原来的内容覆盖掉。来源抓取失败时，不能顺手生成一个看起来完整的结果；数据缺失也不能用零补上。

这些约束最后要落到程序里。现在工程在提交前会检查即将进入仓库的内容，还会识别文件本身的格式，避免只是改了后缀，就把不应该进入仓库的原始表格提交进去。提示词里的要求需要有程序配合，否则每次执行都只能指望模型记得足够牢。

这个过程里，有些问题是我一开始没想到的，是和 Claude 反复审查时逐渐暴露出来的。后半程花了很多时间去找边界、补校验、再做审查。一个个人项目，只要涉及真实的家庭数据，也不能因为使用人数少，就省掉这些工作。

我对这套工程后续的期待很具体：每个季度更新数据时少做重复劳动，能够解释这次和上次为什么不同，也能知道一个结论到底来自哪里。

**把事实维护好，分析和可视化可以随时重做。**

## 跨端订阅管理工具

相比之下，订阅管理软件做得很快。这次我想试的是，能不能用很低的成本，做出一个按自己习惯高度定制、跨平台使用，而且体验接近原生应用的小工具。

我先把旧软件里的订阅信息录了屏，让 ChatGPT 提取迁移数据。这一步也有细节：只保留我实际点开、展示过详情，而且仍在进行的订阅。币种也要核对，Google One 记的是新台币，电信记的是澳门币。如果这些基础字段错了，后面算得再漂亮也没有意义。

接着做界面、同步和部署。这个工具放在 ChatGPT Sites 上，使用它提供的数据库能力，在手机、PC 和 Mac 上都能打开。我在 iOS 上把它作为 Web App 使用，实际体验比预想好不少。

整个迭代过程也很直接。界面有哪里不符合预期，我就标注出来，做一点测试，再补充需求，继续调整。对这种只需要服务自己、功能边界比较清楚的小工具来说，这样的交付方式挺合适。

我用了很多年的旧订阅软件，就这样被替换掉了。以前买现成软件，总要接受一些自己并不喜欢的组织方式。现在可以按自己的习惯来做，修改成本也低。它未必需要成为一个面向所有人的产品，只要能把我的这件事处理好，就已经有价值。

**这也让我重新看了一眼 Web App 这种形式。对于轻量级的工具和效率产品，网页、托管和数据存储组合起来，已经能提供相当完整的体验。再配合 Scriptable 这样的应用，还可以用脚本补上系统提醒和桌面小组件，把网页里的数据带到手机的日常使用入口里。**

对于订阅管理这种场景，Web App 加上一点原生能力补充，已经可以用很低的成本做出高度定制、接近原生的体验。没有必要为了一个个人工具，就先给自己安排几套客户端的开发和维护工作。

## 网络代理可靠性优化

还有一两天，我主要花在网络代理的可靠性上。

现在很多工作和生产力工具都依赖国际互联网。只要供应商间歇性不可用，开发、查资料、调用模型都会一起受影响。被卡过几次以后，我觉得这件事需要认真处理一下。

我继续迭代代理配置工程，把自建台湾节点放在第一优先级，商业线路 A 的台湾节点作为第一备份，商业线路 B 的台湾节点作为最后候选。AI 流量只走台湾，国内、公司和私网流量仍按原来的规则直连。这样既把备用路径明确下来，也避免为了某个工具能用，就把整台机器的流量都改走同一条线路。

故障切换交给代理核心处理。现在每 30 秒主动测活，单次超时 3 秒。自建线路不可用时，后续连接转到备用线路；恢复后，再重新优先使用自建。已经建立的流式连接不能搬到另一台服务器上继续，所以切换仍然需要应用重试。这一层解决的是下一次连接能不能继续工作。

这次还做了 468 轮 HTTPS 测活。自建线路成功 465 轮，商业线路 A 成功 459 轮，两条线路至少有一条成功的轮次是 468/468。两条线路的故障在这组样本里确实形成了互补。

如果假定两条线路的故障彼此独立，并用这次采样的失败率估算组合可用率，结果约为 99.9877%。

**按这个假设粗估，组合可用率达到 4N 水平。**

这是基于短期样本和独立故障假设的粗估，尚未计入共同网络故障、故障检测与切换空档，也不代表全年实测的可用率。

验收也需要贴近实际工作。能打开网页，或者某个接口返回成功，并不说明模型在长时间生成内容时也稳定。我分别验证了自建线路和备用线路上的真实模型输出，接近两分钟的持续流式都通过了；也用隔离环境模拟自建失效和恢复，检查备用接管以及恢复后的优先级。测试时没有关闭实际运行的服务器。

我又把自建节点接入了固定订阅。节点的连接参数通过 Cloudflare 分发，实际代理流量仍连接自建服务器。Mac 已经接入，手机和 Apple TV 也有对应的订阅格式，设备端的导入和刷新还需要分别验收。以后节点参数变化，不用给每台设备重新发一份配置。订阅下载本身走商业备用线路，避免自建节点坏了以后，连更新参数也拿不到。

随后又补上了双 Mac 的协调管理。两台机器通过加密状态同步管理记录，同一时间只允许一台执行管理操作，避免同时改订阅或重复提交请求。

自建节点以后，我也考虑过通过非工作日释放、工作日重建来节省成本。真正往下做，又碰到了新服务器的可信身份、创建请求超时后的对账、状态恢复和多设备同步。后来我取消了这套周期释放重建方案，保留现有实例持续运行，继续让线路自动切换。

**为了节省一部分实例运行时间，把整个系统做复杂，未必是当下最划算的选择。**

## 自媒体工作流实践

另外一个试验是“AI有图说”。我想面向大众做一些 AI 主题的图文内容，先看看这种方式能走到哪一步。

我用 Multica 组织了一个多 Agent 小队，把选题、原文核对、编辑、配图、检查、人工确认和发布串起来。目前已经有正式发表的内容，流程不再只停留在草稿阶段。其中公众号仍然保留了我的手机确认，发布后再核对正式结果。

整个过程里会遇到不少小问题：选题是不是重复了，文章是不是只转述了一遍发布公告，图片和文字是否一致，平台到底保存成功了没有。单独看都不算很大的技术问题，但要把一次交付做完，就得逐个处理。

流程跑通后，内容本身还很早期。主题不多，选题也还比较生硬，现在谈曝光和点赞没有什么依据。我更想观察的是，后面能不能把执行记录和内容表现接起来，复盘什么值得写、怎么表达读者才愿意看，再影响下一轮选题。

这里还有不少需要调整的地方。我希望先保持调度方式，把这件事本身做顺。把它当成一个小试验，继续观察，会比很快给它下结论更有意思。

## 本机与云端的运行边界

这几件事做下来，我也更在意个人数字助理到底运行在哪里。现在这类应用越来越多，一个助理可以在云端接收任务、调用工具、替我执行。但完全云端的执行环境，与自己拥有一台本地主机相比，能不能等价地完成生产任务，还要看几个很具体的条件。

首先是凭证安全。助理要做真实的事情，就需要登录态、凭证和 Token。这些东西交给云端以后，存在哪里，谁能读取，能授予多大的权限，又能不能撤销，都需要明确。本地主机上的凭证也需要保护，但我能直接管理它们的保存位置和使用范围。到了云端，我需要平台提供同样清楚的边界。

其次是存储可靠性。个人项目会留下代码、文件、执行记录和长期状态。这些东西能不能持久保存，执行资源被回收以后还在不在，下次任务能不能接着上次的结果继续，都会影响助理是否真正可用。一次执行完成以后把结果发回来，与长期替我维护一个工程，是两种不同的要求。

再一个是网络访问。云端执行环境的网络出口可能限制某些网站或服务。在我的本机上，有些访问问题可以通过已有的代理配置解决；搬到云端后，能不能访问同样的目标，保持同样的登录态，还需要逐项验证。助理能访问互联网，并不等于它能访问完成这项任务所需的全部资源。

最后是开发和测试环境。以 iOS 应用为例，我目前使用的云端执行环境是 Linux，不能直接运行 Xcode 和 iOS 模拟器。如果助理能写代码，却没有对应的工具链和模拟器，它能完成的验收就会受到限制。涉及这些测试时，我仍然需要 Mac，或者一个能提供同等 macOS 工具链的执行环境。

**个人数字助理在生产端能走多远，也取决于凭证、存储、网络和工具链能否持续支撑它的工作。**

我希望这类应用继续补齐这些能力。文件能留下来，权限能够控制，目标资源可以访问，写完的程序能够实际运行和测试，才有条件把一个长期项目交给它。

目前我的订阅管理工具放在云端，手机和电脑直接打开就能用；依赖本地凭证、网络配置和 Mac 工具链的任务，继续在本机上做。