那时难决

我近期开发了一款Rust命令行工具Everyday CLI，
配合自带的Skill，
可为 AI Agent 提供便捷的邮箱、日历、RSS 订阅、笔记、待办事项及书签管理能力。。
我几乎全程在腾讯推出的 WorkBuddy 上进行开发，期间不断切换模型与工作流，推动项目逐步迭代至较完善版本，也积累了不少实践经验。

微软近期正式发布了WSL container CLI(wslc.exe)，可以直接在windows上管理Linux 容器，不必再安装Docker Destop或在某个wsl实例里安装docker ce。

wslc.exe随最新的wsl预览版发布，可通过wsl --update --pre-release命令升级。

wslc.exe的命令行语法与docker高度一致，开发者（以及AI Agent）可以使用熟悉的命令。

近期微信推出了官方的 Clawbot 插件和官方的 Openclaw Plugin，用于配置 Openclaw 连接。与此同时，其他 Openclaw 类工具也纷纷接入了微信 Clawbot。

我使用的 Zeroclaw 暂时还没有官方的微信 Clawbot 接入方案，不过可以通过 OpeniLink Hub 来间接实现 Zeroclaw 与微信 Clawbot 的连接。

OpeniLink Hub 是一个基于微信官方 iLink 协议的开源微信机器人（Bot）管理平台，同时也是一个 App 应用市场。

它主要提供以下能力：

• 支持多账号扫码绑定
• 提供内置应用市场，可一键扩展飞书、Slack、Notion 等 20 多种工具
• 支持 AI 自动回复能力

我将自己的微信 Clawbot 连接到了 OpeniLink Hub，并安装了两个内置应用：

1. MCP Server

   • 提供向微信发消息的能力
   • 配置到 Zeroclaw 中后，可以让 Zeroclaw 向微信发送消息

2. Runner

   • 提供斜杠命令能力
   • 可以在微信中通过 /agent 触发 Zeroclaw 中的功能

虽然微信的 Clawbot 对于 Markdown 消息、流式消息等功能的支持还不完善，但通过 OpeniLink Hub 的中转，Zeroclaw 的功能可以在微信中得到一定程度的展现,目前可以满足一些简单的消息交互需求。

在技术领域，2026年的第一季度属于OpenClaw，近期我也开始了自己的“养龙虾”之旅。
我个人非常不愿意在个人设备上给予AI过多的权限（比如屏幕读取和文件系统权限），所以选择了在一台云服务器安装“龙虾”。作为一个TypeScript实现的node.js服务，原版的OpenClaw需要消耗相当高的服务器资源（运行时占用1GB以上的内存）。考虑到我的云服务器只有4GB内存，我最终选择安装配置了zeroclaw（一个rust实现的轻量级OpenClaw同类产品）。

在现有架构下，我主要维护的是一个运行在 AlmaLinux ECS 实例上的后端服务：基于 FastAPI 构建，通过 Docker Compose 进行容器化部署。服务中包含多条 AI 对话类 SSE（Server-Sent Events）长连接接口。

随着用户规模增加，我逐渐发现一个现实问题：Docker Compose 在滚动发布和长连接共存场景下，几乎无法实现真正的零停机更新。容器重建过程中，SSE 连接被强制断开，用户体验受到明显影响。

在与 AI 进行多轮技术探讨后，我重新审视了技术选型。结论是：在当前规模与复杂度下，并不需要直接迁移到 Kubernetes。采用 Docker Swarm 即可满足零停机更新与滚动发布的需求，同时保持架构复杂度可控。

经过半天实践，我成功将服务从 Docker Compose 迁移至 Docker Swarm。以下是关键迁移步骤与问题记录。

在近期的 AI 辅助开发实践中，我逐步形成了一套相对稳定、可复用的工作流，核心目标是：让 AI 可规划、可执行、可追踪、可审查。

整体流程如下：

首先，为每个项目建立专属的 agents.md，用于描述项目背景、技术约束以及 AI 开发规范，例如强制要求在代码生成后执行静态检查和单元测试。这一步相当于为 AI 提供“项目宪法”。

其次，提出足够明确、结构化的需求，并使用 Copilot 的 Planning 模式生成开发计划，避免直接进入无序实现。

在实施阶段，切换至 Copilot 的 Agent 模式执行计划，并明确要求使用 PRD.md 和 process.md 跟踪进度：前者记录需求，后者记录每次代码变更与当前状态。通过外部文件系统作为长期记忆，降低上下文丢失的风险。

完成初步实现后，由人工对功能正确性进行验证，确保需求被真实满足，而非“看起来能跑”。

最后，引入我自定义的Linus 风格 Code Review Agent进行代码审查，集中指出设计、可维护性和工程质量问题，再由人工或 AI 执行针对性的重构。

值得一提的是，近期社区中出现了一个名为 planning-with-files 的 Claude Skill，其思路与上述流程高度相似，同样通过外部文件作为 AI 的长期记忆，并额外引入 findings.md 用于沉淀调研结论和经验知识。这类模式进一步验证了“文件即上下文”的工程价值。

1
2

# Skill安装命令
npx skills add https://github.com/othmanadi/planning-with-files --skill planning-with-files

总体来看，AI 开发正在从“对话式生成”走向“工程化协作”，而可追踪的计划、状态与知识载体，是这一转变的关键基础。

Zed 是一款由前 Atom 及 Tree-sitter 团队打造的跨平台代码编辑器。它采用 Rust 语言编写，核心定位在于极致性能、原生 AI 集成以及多人实时协作。

Zed is a minimal code editor crafted for speed and collaboration with humans and AI.

得益于 Rust 语言的底层优势和自研的 GPU 加速框架 GPUI，Zed 在响应速度上远超基于 Electron 的编辑器。
在处理中等规模项目时，Zed 的内存占用通常仅为 VS Code 的十分之一左右（约 100MB vs 1GB+）。
Zed 充分利用多核 CPU 和 GPU 渲染，使得输入延迟和 UI 刷新达到了原生应用的最佳水准。

Zed集成了很多AI开发功能，包括代码智能补全、编辑预测、Agent开发模式。
除了登录账号订阅Zed官方的AI服务外，用户还可以通过BYOK模式使用自己的OpenAI、Gemini或Claude API密钥（也可以直接使用Github Copilot订阅）。
Zed也支持和Claude Code、Gemini CLI与Codex CLI集成。

虽然插件生态尚处于早期阶段，但 Zed 通过原生支持 LSP（语言服务协议），已实现对 Python、Rust、TypeScript 等主流语言的完美支持。

对于追求极致流畅度、且希望在开发流中深度使用 AI 的开发者来说，Zed 无疑是目前 VS Code 最强有力的挑战者。

【由 ChatGPT 辅助翻译】

原文链接

发布时间: 2025-12-26

uv 安装包的速度比 pip 快一个数量级。通常的解释是“它是用 Rust 写的”。这确实没错，但并不能解释太多。毕竟，也有大量用 Rust 编写的工具，并没有表现出显著的速度优势。真正有意思的问题在于：究竟是哪些设计决策带来了这种差异。

Charlie Marsh 在 Jane Street 的一次演讲（Jane Street talk）以及一篇来自 Xebia 的工程深度解析（Xebia engineering deep-dive）已经很好地覆盖了技术细节。更值得关注的，是其中的设计选择：哪些标准让“快速路径”成为可能，uv 放弃了哪些 pip 所支持的特性，以及哪些优化其实完全不依赖 Rust。

前段时间突发奇想，从更理论的角度审视AI智能体，于是和Gemini进行了一番对话。

我的提问是：从系统论、控制论、信息论的视角，深度探讨AI智能体

以下是Gemini的回答：

这是一个非常深刻且宏大的视角。系统论（Systems Theory）、控制论（Cybernetics）和信息论（Information Theory），也就是经典的“老三论”（SCI），是研究复杂系统的基石。

将AI智能体（AI Agent）置于这三个维度下审视，我们不再将其视为单纯的代码或大模型，而是一个 “在开放环境中，通过信息交互维持自身有序性，并利用反馈机制实现目标的复杂系统”。

以下是基于这三个维度的深度探讨：

VS Code 的 Github Copilot 拓展最近的更新带来了对 Claude Skills 的实验性支持，我简单尝试了一下，使用 Claude 官方的前端设计 Skill开发了一个赛博朋克风格的个人网站。 项目初始化和代码编辑全程由 AI 自动完成，我只是手工批准了一些关键步骤。
仓库地址
感言：AI生成的网页终于不是千篇一律的渐变紫背景了。