silenceper – silenceper | AI 工具、科技观察与开源实践

html-video：用 HTML、CSS 和 Coding Agent 在本地生成真实 MP4

Fri, 05 Jun 2026 23:34:00 +0800

一句话定位

html-video 是一套面向 Coding Agent 的本地视频生成工具：给它一句描述、文章链接或 GitHub 仓库，它会生成多帧动画 HTML，并渲染成真实 MP4。

基础信息卡片

项目	信息
项目名	html-video
GitHub	https://github.com/nexu-io/html-video
官网	https://open-design.ai/html-video
作者/团队	Open Design / nexu-io
协议	Apache-2.0
主要技术	HTML、CSS、TypeScript、Headless Chromium、ffmpeg
默认渲染引擎	Hyperframes
模板数量	21 个内置模板
支持 Agent	Open Design、Claude Code、Cursor、Codex、Gemini、Qwen、OpenCode、Copilot、Aider、Hermes 等
定位	Agent 驱动的 HTML-to-Video 本地生成工作流

解决什么问题

程序化视频并不是新概念。Remotion、Motion Canvas、Manim 这类工具都能把代码变成视频，但它们通常都有各自的创作模型：有的偏 React，有的偏 Canvas，有的偏数学动画。

这会带来一个现实门槛：你不是只在“做视频”，还要先选择框架、学习语法、理解渲染方式，然后再把内容拆成镜头。

html-video 的目标是把这层复杂度往后藏起来。你面对的是本地 Studio 或 CLI，真正负责拆解内容、选择模板、生成画面的，是接入的 Coding Agent。

flowchart LR
A[一句描述 / 文章链接 / GitHub 仓库] --> B[抓取并整理素材]
B --> C[Coding Agent 生成故事板]
C --> D[每一帧生成动画 HTML]
D --> E[Headless Chromium 录制]
E --> F[ffmpeg 编码与合成]
F --> G[输出 MP4]

这套流程最关键的地方在于：内容理解和画面渲染被拆开了。Agent 负责“讲什么、怎么分镜”，渲染引擎负责“怎么把画面变成视频”。

核心功能

1. 从链接或仓库生成视频

html-video 不只支持一句 Prompt。你也可以粘贴网页文章、微信公众号文章，或者 GitHub 仓库地址。Studio 会先把来源内容抓取并整理成 Markdown，再交给 Agent 生成视频内容。

这对技术内容尤其有用：比如给它一个开源项目仓库，它可以读取项目简介、README 和顶层结构，然后生成一段项目介绍视频。

2. 多帧故事板

项目内部使用 content-graph 来组织多场景视频。可以理解为：Agent 先把内容拆成多个节点，每个节点对应一个画面；节点之间的顺序、对比、依赖关系，决定视频的节奏。

单帧视频可以直接走快速路径；多场景视频则会逐帧生成 HTML，再统一合成为 MP4。

3. HTML/CSS 表达画面

相比直接写视频框架，HTML/CSS 的门槛更低，也更容易被 Coding Agent 生成和修改。标题、卡片、图表、渐变、动效、布局，都可以用 Web 技术来表达。

当前默认引擎是 Hyperframes：它会用无头 Chromium 加载这些动画 HTML，逐帧录制，再交给 ffmpeg 编码。

4. 内置模板库

html-video 自带 21 个模板，覆盖数据可视化、产品宣传、标题卡、片尾、动感排版、决策树、电影感画面等常见场景。

上面这种数据图表模板，适合把“一个指标如何变化”讲成短视频里的关键画面。Agent 不需要从零设计每一帧，而是基于模板填入标题、数据、标注和来源。

这类标题模板则更适合片头、主题揭示，或者技术类视频里常见的“系统上线”“趋势变化”一类表达。

5. 支持本地 Agent 工作流

项目支持多种 Coding Agent，包括 Open Design、Trae CLI、Claude Code、Cursor Agent、Codex CLI、Gemini CLI、Grok、Qwen Code、OpenCode、Copilot CLI、Aider、Hermes，以及 Anthropic API。

这意味着它不是绑定某一家模型或平台，而是更像一个本地视频生成工作台：你可以根据自己已经安装和使用的 Agent 来驱动视频生成。

6. 可选配乐和旁白

如果配置 MiniMax API Key，还可以生成背景音乐和 TTS 旁白。导出时，音频会通过 ffmpeg 混入最终 MP4。没有音频配置时，视频生成流程本身也可以正常使用。

适合谁

html-video 比较适合这几类人：

想把技术文章、开源项目、产品说明做成短视频的开发者；
想用 Agent 批量生成项目介绍视频的内容团队；
想做“Video as Code”工作流的工程师；
不想依赖云端渲染、不想按次付费的视频自动化用户；
已经在使用 Claude Code、Codex、Cursor、Hermes 等 Coding Agent 的用户。

它尤其适合“内容结构明确，但需要更快转成视频表达”的场景。例如开源项目介绍、产品更新、数据变化解读、技术教程片头、社媒短视频素材等。

快速上手

项目使用 pnpm 管理 monorepo，官方给出的启动方式是：

pnpm install
pnpm -r build
node packages/cli/dist/bin.js studio

启动后打开本地 Studio：

http://127.0.0.1:3071

常用 CLI：

node packages/cli/dist/bin.js doctor
node packages/cli/dist/bin.js search-templates --intent "github stars race" --top 3

doctor 用来检测本地可用的 Agent 和渲染引擎；search-templates 可以根据视频意图搜索合适模板。

结论

html-video 的价值不在于“HTML 截图转视频”这么简单，而在于它把内容输入、Agent 理解、故事板生成、HTML 动画、MP4 渲染串成了一条完整链路。

对开发者来说，它降低了程序化视频的上手成本：不用先押注某个视频框架，也不用从空白画布开始设计。你可以先用文章、仓库或 Prompt 提供内容，再让 Agent 基于模板生成视频。

目前真正可运行的核心是 Hyperframes 引擎，其他引擎还在规划中。但如果你关注 AI Agent、内容自动化、技术视频生成，html-video 是一个值得跟进的开源项目。

html-ppt-skill：让 AI 生成专业 HTML 演示文稿

Tue, 02 Jun 2026 15:20:00 +0800

一句话定位

html-ppt-skill 是一套面向 AI Agent 的 HTML PPT 生成技能包，用纯静态 HTML/CSS/JS 快速产出带主题、布局、动效和演讲者模式的专业演示文稿。

基础信息卡片

项目	信息
项目名	html-ppt-skill / HTML PPT Studio
GitHub	https://github.com/lewislulu/html-ppt-skill
作者	lewis
协议	MIT
主要技术	HTML、CSS、JavaScript、Shell
Star	约 5.3k
Fork	约 505
定位	AgentSkill / HTML PPT 生成工具包
核心卖点	36 套主题、15 套完整 deck 模板、31 种页面布局、47 个动效、演讲者模式
构建方式	纯静态 HTML/CSS/JS，无需构建步骤

解决什么问题

很多 AI 工具可以生成 PPT 大纲，但真正落到“可展示、好看、能演讲”的页面时，往往还需要大量人工排版。

html-ppt-skill 解决的是：让 Agent 不只是写内容，而是直接生成可以打开、演示、导出截图的 HTML 演示文稿。

它把常见 PPT 制作能力封装成一个 AgentSkill，包括：

视觉主题
页面布局
完整演示模板
CSS / Canvas 动效
演讲者模式
导出脚本
示例 deck 和验证截图

对使用者来说，可以直接对支持 AgentSkill 的 AI 工具说：

“做一份 8 页的技术分享 slides，用 cyberpunk 主题”
“把这段 outline 变成投资人 pitch deck”
“做一个小红书图文，9 张，白底柔和风”

然后让 Agent 根据这套技能生成对应的 HTML PPT。

核心功能

1. 36 套视觉主题

项目内置 36 套主题，覆盖极简、杂志、暗色、赛博朋克、蓝图、小红书、投资人路演、学术论文等风格。

主题是 CSS token 驱动的，换一行 <link> 就能给整份 deck 换皮。适合让 Agent 根据内容类型自动选择风格，比如：

技术分享：tokyo-night、cyberpunk-neon、engineering-whiteprint
商业汇报：corporate-clean、pitch-deck-vc
小红书图文：xiaohongshu-white、soft-pastel
学术内容：academic-paper
架构方案：blueprint

2. 15 套完整 deck 模板

它不是只给几个单页组件，而是提供了完整的多页演示模板。

模板分两类：

真实风格提炼款

小红书白底杂志风
暗底知识图谱风
蓝图 / 架构图风
终端 cyberpunk 风
紫色渐变卡片风
警示 / 安全测试风
柔和马卡龙图文
方向键极简风

通用场景款

投资人 pitch deck
产品发布会
技术分享
周报
小红书 9 页图文
教学模块
带完整逐字稿的演讲者模式模板

这些模板对 Agent 很有用，因为它不需要从零设计每页结构，可以直接基于场景套用骨架。

3. 31 种单页布局

项目提供 31 种常见页面布局，覆盖大多数 PPT 页面类型。

包括：

封面
目录
章节页
bullet 列表
双栏 / 三栏
引用页
数据高亮
KPI 网格
表格
代码
diff
终端
流程图
时间线
路线图
思维导图
对比页
甘特图
图片大图
图片网格
柱状图 / 折线图 / 饼图 / 雷达图
架构图
CTA
Thanks 页

README 里还展示了自动轮播的真实布局预览：

4. 47 个动效

html-ppt-skill 内置 27 个 CSS 动画和 20 个 Canvas FX 动画。

CSS 动效包括：

淡入
上升进入
缩放弹出
模糊进入
打字机
霓虹光效
渐变流动
列表错开入场
数字滚动
路径绘制
3D 翻卡
页面翻转
聚光灯等

Canvas FX 包括：

粒子爆发
彩带
烟花
星空
Matrix 代码雨
知识图谱
神经网络脉冲
星座连线
数据流
磁场
冲击波等

这让 Agent 做出来的不是“静态网页截图”，而是可以真正播放和展示的 HTML slides。

5. 演讲者模式

这是项目里比较亮眼的功能。

在任意 deck 中按 S 键，可以打开独立的演讲者窗口。窗口里有 4 个可拖拽、可调整大小的磁吸卡片：

当前页预览
下一页预览
逐字稿
计时器

它的设计比较认真：预览不是截图，而是 iframe 加载同一份 deck HTML，通过 ?preview=N 只显示指定页面。因此演讲者看到的预览和观众视图使用同一套 CSS、字体、主题和 viewport，视觉上保持一致。

翻页时通过 BroadcastChannel 和 postMessage 同步，不需要重新加载页面，避免白屏和闪烁。

适合谁

这个项目适合：

想让 AI 直接生成演示文稿的用户
使用 Claude Code、Codex、Cursor、OpenClaw 等 Agent 工具的人
经常做技术分享、产品发布、周报、课程内容的人
想用 HTML/CSS/JS 替代传统 PPT 的开发者
需要批量生成小红书图文、课程 slides、项目介绍页的人
想把演示文稿变成可版本管理、可脚本化、可导出的静态资产的人

尤其适合“内容由 AI 生成，但希望页面也有设计感”的场景。

快速上手

安装命令很简单：

npx skills add https://github.com/lewislulu/html-ppt-skill

安装后，可以让支持 AgentSkill 的 Agent 直接调用这套能力。

如果手动 clone 项目，也可以用脚本新建 deck：

./scripts/new-deck.sh my-talk

查看内置资源：

open templates/theme-showcase.html
open templates/layout-showcase.html
open templates/animation-showcase.html
open templates/full-decks-index.html

导出 PNG：

./scripts/render.sh templates/theme-showcase.html
./scripts/render.sh examples/my-talk/index.html 12

常用快捷键：

← → Space PgUp PgDn Home End 翻页
F 全屏
S 打开演讲者窗口
N 打开 notes 抽屉
R 重置计时器
O slide 总览
T 切换主题
A 演示当前页动画
#/N 跳转到第 N 页
?preview=N 单页预览模式

结论

html-ppt-skill 的价值不只是“用 HTML 写 PPT”，而是把 主题、布局、模板、动效、演讲者模式和导出流程 打包成一套 Agent 可调用的标准能力。

如果你已经在用 AI Agent 写文档、做方案、生成代码，这个项目可以让下一步变得更自然：直接让 Agent 把内容变成一套能展示的 HTML slides。

Agent 不只需要模型：上下文基础设施正在成形

Sun, 31 May 2026 22:55:00 +0800

最近看 GitHub 上的新项目，有一个方向越来越明显：

Agent 的关键问题，正在从“能不能调用一个更强模型”，转向“能不能持续、可靠、低成本地管理上下文”。

这不是一个单点新闻，而是几个项目同时指向同一件事。

OpenViking 把自己定位成面向 AI Agent 的 context database，用文件系统范式统一管理 memory、resources 和 skills。Mirage 试图把 S3、Google Drive、Slack、Gmail、Redis 这类外部服务挂到同一棵虚拟文件树里，让 Agent 用类 Unix 工具访问不同后端。SkillOpt 则更进一步，把自然语言写成的 skill 当成可以训练、验证和迭代的外部状态，而不是一次性提示词。

这三个项目解决的不是同一个问题，但它们都在回答一个更大的问题：

当 Agent 开始长期执行任务、调用工具、沉淀经验之后，它的“工作记忆”应该放在哪里？应该怎么读、怎么改、怎么调试、怎么复用？

我的判断是：上下文基础设施会成为 Agent 应用接下来最重要的一层。

先认识这三个项目

这篇文章不是要把三个项目混在一起讲。它们处在 Agent 基础设施的不同位置：OpenViking 更像上下文数据库，Mirage 更像工具和数据源的虚拟文件系统，SkillOpt 更像 skill 优化器。

如果用一句话区分：

项目	一句话定位	更像解决哪一层问题
OpenViking	面向 AI Agent 的 context database	memory、resources、skills 怎么统一管理
Mirage	面向 AI Agent 的统一虚拟文件系统	Agent 怎么用同一种方式访问不同工具和数据源
SkillOpt	面向 Agent skills 的自然语言优化器	skill 怎么从手写经验变成可评估、可迭代资产

这三个项目都不只是“又一个 Agent 框架”。它们更像是在补 Agent 长时间工作时缺失的底层能力。

OpenViking：给 Agent 一个上下文数据库

OpenViking 的定位是 The Context Database for AI Agents。

它想解决的问题是：Agent 所需的上下文正在变得越来越碎。项目文档、用户偏好、任务日志、技能说明、外部资源、历史经验，都可能影响一次任务结果。如果这些内容只散落在 prompt、聊天记录、向量库和临时文件里，Agent 很难稳定复用。

OpenViking 的做法是把 memory、resources 和 skills 放到一个统一的 context database 里，并用文件系统范式组织它们。它不是只提供“相似度搜索”，而是强调层级结构、目录递归检索、分层加载和检索轨迹可视化。

可以把它理解成 Agent 的“上下文工作区”：

memory 用来保存偏好、经验和历史状态；
resources 用来挂载文档、代码、资料和外部知识；
skills 用来描述可复用的任务方法；
分层加载用来控制哪些上下文应该进入当前任务；
可视化检索轨迹用来帮助开发者排查 Agent 为什么读到了这些信息。

它适合关注长期记忆、项目级上下文和多技能协作的 Agent 应用。比如代码助手、企业知识助手、个人工作流 Agent，都可能遇到类似问题。

它的边界也很明确：OpenViking 解决的是上下文组织和检索问题，不等于替你解决权限、安全、任务规划和业务审批。上下文数据库如果接入了敏感信息，仍然需要单独做访问控制和审计。

Mirage：把外部世界挂成一棵文件树

Mirage 的定位是 A Unified Virtual Filesystem For AI Agents。

它关注的是另一个实际问题：Agent 要访问的工具越来越多。今天一个 Agent 可能要读 GitHub、查 S3、看 Slack、读 Gmail、访问 Redis、处理本地文件。每个系统都有自己的 API、权限、分页、错误码和数据格式，Agent 调得越多，失败概率越高。

Mirage 的思路是把这些外部数据源挂载成统一的虚拟文件系统。仓库 README 里给出的例子是让 Agent 在同一棵树下看到 /s3、/gdrive、/slack、/gmail、/redis 这类资源，然后用类似文件操作的方式探索、读取和组合数据。

这个设计有两个价值。

第一，它把工具调用变成 Agent 更容易理解的环境探索。ls、cat、grep、目录、文件、路径，这些抽象比一堆异构 API schema 更稳定。

第二，它给复杂任务提供了一个中间工作区。Agent 可以把不同来源的数据读进来、整理成文件、产生中间结果，再交给下一个步骤使用。

它适合那些“数据源很多，但多数动作是读取、搜索、整理、组合”的 Agent 场景。比如研究助手、数据整理助手、自动化运维助手、企业内部资料查询工具。

但 Mirage 也不应该被理解成万能 API 替代品。涉及转账、删除、审批、发消息这类有副作用的操作，仍然需要更严格的权限、确认和审计。文件系统抽象适合降低读取和组织复杂度，不应该模糊业务动作的风险边界。

SkillOpt：让 skill 可以被训练和验证

SkillOpt 来自 Microsoft Research，定位是 Executive Strategy for Self-Evolving Agent Skills。

它解决的是 Agent 经验复用的问题。现在很多 Agent 系统都有 skills、prompts、playbooks 或 SOP，但这些内容通常靠人写、靠人工试错。一个 skill 改好还是改坏，往往没有稳定评估。

SkillOpt 的思路是：不改模型权重，而是优化外部自然语言 skill。它会根据任务轨迹、反馈和验证结果反复编辑 skill，并只接受能提升验证表现的改动，最终产出类似 best_skill.md 的可部署技能文档。

这个项目值得关注，是因为它把 skill 从“提示词经验”变成了“可训练资产”。

对开发团队来说，这意味着未来可以像维护代码一样维护 skills：

为某类任务准备固定评估集；
记录每次 skill 修改前后的效果；
把失败案例反向写入优化过程；
对高风险 skill 设置人工审核；
把稳定 skill 发布到真实 Agent 工作流里。

SkillOpt 更偏研究和方法论，不是拿来就能替代现有 Agent 平台的完整产品。但它指向的方向很重要：当 Agent 越来越依赖 skills，skill 本身就需要版本管理、评估、优化和发布流程。

为什么现在才变重要

早期的 AI 应用大多是 chat。

用户给一段输入，模型给一段输出。上下文管理主要是把历史对话塞进窗口里，超长了就截断、总结，或者做一个简单 RAG。

但 Agent 不一样。

一个真正做事的 Agent 会不断产生新的状态：

它读过哪些文件；
调用了哪些工具；
哪些命令失败过；
哪些用户偏好已经确认；
哪些经验下次可以复用；
哪些外部资源只应该按需加载；
哪些技能在这个项目里有效，哪些无效。

如果这些信息只是散落在对话历史、向量库、临时文件和工具日志里，Agent 很快就会变得不可控。

问题不只是“记不住”，更是“记住了也不知道怎么用”。

传统 RAG 能解决一部分检索问题，但它通常把信息打平：文档切块、向量化、相似度召回。对于长任务 Agent 来说，这还不够。Agent 需要知道上下文之间的层级、来源、时效、权限和任务关系，也需要在出错时回看“为什么它检索到了这些东西”。

这就是 OpenViking、Mirage、SkillOpt 这类项目值得看的地方。它们不是在堆一个更大的上下文窗口，而是在重新设计 Agent 怎么组织外部状态。

方向一：上下文从向量库变成文件系统

OpenViking 的核心想法很直接：把 Agent 需要的 memory、resources、skills 统一组织成类似文件系统的结构。

它强调的不是“所有东西都向量化”，而是用目录、文件、层级加载、递归检索这些开发者熟悉的方式来管理上下文。README 里提到的几个点很关键：文件系统范式、L0/L1/L2 分层上下文加载、目录递归检索、可视化检索轨迹、自动会话管理。

这背后有一个很重要的工程判断：

Agent 的上下文不应该只是一个黑盒知识库，而应该是可组织、可观察、可调试的工作空间。

如果一个 Agent 因为错误上下文做出了错误决策，开发者不能只看到“模型答错了”。更有价值的是知道：

它读取了哪个目录；
它用了哪段 memory；
它忽略了哪些资源；
它为什么选择这个 skill；
它在第几轮任务里产生了错误假设。

这会把上下文管理从“检索增强”推进到“上下文工程”。

方向二：外部工具变成一棵虚拟文件树

Mirage 的思路更偏工具访问层。

它把多个服务和数据源挂到同一棵虚拟文件系统里，比如 /s3、/slack、/github、/data。Agent 不需要为每个后端学习一套新的 API 语义，而是用已经熟悉的文件、目录、管道和命令组合来访问它们。

这个设计的价值在于降低 Agent 调工具的认知成本。

今天很多 Agent 工具调用看起来很强，但实际接入成本并不低。每个 MCP server、每个 SaaS API、每个数据库都有自己的参数、权限、分页、错误码和数据结构。工具越多，Agent 越容易在工具选择和参数构造上出错。

如果把后端能力抽象成统一文件系统，Agent 至少可以用一种稳定心智模型来探索环境：

ls 看有哪些资源；
cat 读取内容；
grep 搜索线索；
cp 或 mv 组织中间结果；
用 snapshot/version 管理一次任务的工作空间。

这不是说文件系统能解决所有问题。复杂业务动作仍然需要明确 API、权限和事务边界。但对“读取、搜索、整理、组合”这类 Agent 高频动作来说，虚拟文件系统是一个很自然的抽象。

方向三：skill 从提示词变成可优化资产

SkillOpt 关注的是另一层：Agent 怎么复用经验。

现在很多 Agent 平台都有 skills、instructions、playbook 或 prompt library。问题是，这些东西大多靠人写、靠经验调。写得好不好，通常只能靠几次人工试用判断。

SkillOpt 的思路是把自然语言 skill 当成“冻结模型之外的可训练状态”。它不是改模型权重，而是通过任务轨迹、反馈和验证门槛去迭代 skill 文档，最终产出可部署的 best_skill.md。

这件事很有意思，因为它把 skill 从“提示词片段”抬高成了工程资产。

一个成熟团队未来可能不会只维护代码、测试和文档，还会维护：

面向某类任务的 skills；
每个 skill 的评估集；
skill 变更前后的成功率；
哪些任务适合自动优化；
哪些规则必须人工审核后才能进入生产。

这和软件工程里的测试、CI、灰度发布很像。区别只是优化对象从代码变成了自然语言策略。

这比单个项目更重要

把这几个项目放在一起看，可以看到 Agent 应用栈正在分层：

层级	过去怎么做	现在正在出现什么
模型层	选择 GPT、Claude、Gemini、DeepSeek	多模型路由、成本控制、端侧模型
工具层	写 API wrapper 或 MCP server	工具网关、权限、沙箱、虚拟文件系统
上下文层	对话历史、RAG、手写 memory	context database、分层加载、检索轨迹
经验层	prompt、系统提示词、人工 SOP	skills、评估、自动优化
运维层	看 token 和日志	成本、权限、审计、回放、失败分析

这说明 Agent 的竞争点会越来越工程化。

未来一个 Agent 产品好不好，不只看它接了哪个模型，而要看它有没有稳定的上下文系统：能不能记住重要信息，能不能忘掉垃圾信息，能不能按需加载，能不能解释自己用了什么上下文，能不能把成功经验沉淀成可复用 skill。

对开发者的实际启发

如果你正在做 Agent 应用，不一定马上要引入这些项目，但至少可以先把上下文当成一等公民设计。

我会优先检查这几个问题：

上下文有没有结构？
不要只把所有材料塞进 prompt。至少区分用户偏好、项目文档、任务日志、工具输出、长期记忆和临时草稿。
上下文有没有来源？
每条 memory、资源和 skill 都应该能回到来源。否则 Agent 一旦基于错误信息行动，很难排查。
上下文有没有生命周期？
有些信息只对当前任务有效，有些可以长期保留，有些必须定期失效。长期记忆不是越多越好。
上下文有没有可观察性？
至少要能记录一次任务里 Agent 读取了什么、跳过了什么、用了哪个 skill、在哪一步失败。
skill 有没有评估？
如果一个 skill 会影响真实任务结果，就不要只凭感觉改。给它准备几个固定任务，用成功率、耗时、成本和错误类型来判断改动是否有效。

使用边界

这类基础设施也不能被神化。

第一，上下文系统不能替代权限系统。Agent 能看到什么、能调用什么、能写入什么，仍然需要独立控制。

第二，虚拟文件系统不能把所有业务操作都简化成文件读写。涉及交易、审批、删除、外发消息的动作，必须有明确确认和审计。

第三，skill 自动优化不是万能的。评估集设计不好，优化出来的 skill 可能只是过拟合某几个任务，看起来更聪明，实际更脆弱。

第四，开源项目本身还在快速变化。像 OpenViking、Mirage、SkillOpt 这类项目值得关注，但在生产环境使用前，仍然要看协议、数据边界、依赖复杂度和维护节奏。

结论

Agent 的下一阶段，不会只靠更强模型推进。

模型仍然重要，但只解决“怎么思考”的一部分。真正让 Agent 能长期工作的是另一套东西：上下文怎么组织，工具怎么暴露，经验怎么沉淀，失败怎么回放，权限怎么收敛。

OpenViking、Mirage、SkillOpt 的共同信号是：Agent 需要自己的基础设施层。

如果说过去一年大家在追“让模型会用工具”，接下来更重要的问题会变成：

当工具越来越多、任务越来越长、上下文越来越复杂时，Agent 凭什么还能稳定工作？

答案大概率不在某个更长的 prompt 里，而在一套可管理、可观察、可迭代的上下文系统里。

参考

AI 工具的免费时代正在结束：从 Copilot token 计费到 Agent 预算治理

Sun, 31 May 2026 01:20:00 +0800

最近几天，围绕 AI 工具成本的信号变得很密集。

一边是 GitHub Copilot 宣布从 2026 年 6 月 1 日开始切换到 usage-based billing，不再只按 premium request 这种相对抽象的单位计量，而是引入 GitHub AI Credits，并按模型 token 消耗来计算用量。

另一边，OpenRouter 推出 Guardrails，把预算限制、模型/供应商限制、零数据保留、提示词注入防护和数据泄露防护做成工作区级别的治理能力。开源侧也出现了 AgentBudget 这类项目，目标很直接：给 AI Agent 会话加一个类似 ulimit 的预算上限，防止一次 agent run 把预算烧穿。

这些事情放在一起看，趋势很清楚：

AI 工具正在从“买了订阅就尽量多用”，进入“每一次长任务、每一个模型选择、每一轮 agent 循环都要被计量和治理”的阶段。

这不是简单涨价问题，而是 AI 工具产品形态变化之后，成本模型终于开始跟上了。

为什么这个变化现在发生

早期 AI 编程工具更像一个增强版编辑器插件。

你让它补一段代码、解释一个函数、写一个测试，它多数时候只是一次短请求。即使背后模型按 token 收费，产品层也可以用订阅制或请求额度把复杂度包起来。

但现在的 AI 编程工具已经不只是“问一句，答一句”。

它们开始做这些事情：

读取整个仓库上下文；
在多个文件里规划修改；
调用终端、浏览器、MCP 和外部 API；
运行测试并反复修复；
自动创建 PR、做 code review；
长时间保持会话状态，持续迭代一个任务。

GitHub 在 Copilot usage-based billing 的公告里也提到，Copilot 已经从编辑器助手演进成 agentic platform，能够执行长时间、多步骤的编码会话，并跨仓库迭代。这类 agentic usage 会带来更高的计算和推理成本。

这就是问题的核心：一次简单聊天和一次持续很久的 autonomous coding session，在旧计费模型里可能看起来差不多，但真实成本完全不是一回事。

所以从平台角度看，usage-based billing 是迟早的事。

Copilot 的变化说明了什么

GitHub 这次变化有几个关键点。

第一，Copilot 的基础订阅价格没有直接变化，但每个计划会包含一定额度的 GitHub AI Credits。之后的用量会按 token 消耗计算，包括输入、输出和 cached tokens。

第二，旧的 premium request unit 会被替换。过去用户更关心“还剩多少请求”，之后会更关心“这次任务消耗了多少 token / credits”。

第三，代码补全和 Next Edit Suggestions 仍然包含在计划内，不消耗 AI Credits。但更重的 chat、agent、code review 等能力会逐渐进入更精细的用量模型。

第四，fallback 体验会取消。以前某些场景下额度耗尽后，可能还能回落到低成本模型继续工作；新模型下，是否继续用，更多取决于剩余额度和管理员预算设置。

第五，Copilot code review 除了消耗 AI Credits，还会消耗 GitHub Actions 运行时间。这一点很关键：当 AI 功能开始真正执行工作流，它消耗的就不只是模型 token，还包括运行环境资源。

这意味着开发者和团队以后不能只问：

这个 AI 工具多少钱一个月？

而要问：

我们日常使用它的任务结构是什么？哪些任务最耗 token？哪些模型最贵？哪些 agent run 容易失控？预算超了之后要自动阻断，还是允许继续付费？

为什么 Agent 更需要预算治理

普通聊天工具的成本通常还比较可控。用户问一句，模型答一句，最多是上下文越来越长。

Agent 不一样。Agent 有几个天然容易烧预算的地方。

1. 它会循环

一个 coding agent 可能会经历：

读代码 -> 写补丁 -> 跑测试 -> 报错 -> 再读代码 -> 再写补丁 -> 再跑测试

如果没有停止条件，它可能会在同一个错误上来回试很多轮。每一轮都会消耗模型调用、工具调用和上下文传输成本。

2. 它会扩大上下文

Agent 为了理解任务，可能会读取大量文件、issue、PR、网页和日志。上下文越大，输入 token 越高；输出越长，输出 token 也会上去。

3. 它会调用外部工具

搜索、浏览器、数据库、向量检索、代码执行、沙箱、CI，这些都可能有成本。真正的 agent 预算，不应该只看 LLM token，还要看工具链成本。

4. 它可能被错误任务拖住

如果用户目标不清楚，或者上下文里有噪声，Agent 可能会走错方向。方向错了，越努力越贵。

所以 Agent 时代的成本治理，不只是“省钱”，而是工程安全的一部分。

从额度到 Guardrails

OpenRouter 的 Guardrails 很能说明这个方向。

它不是只做一个账单页面，而是把治理放进请求路径里：可以设置每日、每周、每月预算；超出后请求直接失败；还能限制模型和供应商，强制使用零数据保留端点，并增加提示词注入和数据泄露防护。

这类能力的价值在于，它把“事后看账单”变成了“事前设边界”。

对个人开发者来说，这可能只是避免一个脚本跑飞。对团队来说，它对应的是更现实的问题：

新人能不能用最贵的模型？
自动化任务能不能无限重试？
某个 API key 能不能单独设置预算？
测试环境和生产环境能不能用不同模型池？
涉及客户数据时，能不能强制走不保留数据的 provider？

当 AI 调用开始进入业务流程，这些问题会比“哪个模型更聪明”更重要。

AgentBudget 这类项目为什么值得看

AgentBudget 的定位很朴素：给 AI Agent 会话加硬预算。

它可以包住 LLM 调用、工具调用和外部 API 请求，实时记录成本，达到限制后触发 circuit breaker。它还考虑了一个很实际的问题：不要让 agent 在最后一步被预算切断，所以支持为最终回复预留一部分预算。

这说明成本治理已经开始从平台侧下沉到应用侧。

如果你在写自己的 Agent，不能只依赖模型平台的账单。因为平台账单通常告诉你“最后花了多少钱”，但你的应用需要在执行过程中知道：

当前任务已经花了多少？
剩余额度够不够做下一步？
是否进入重复调用循环？
某个子任务是否应该有独立预算？
预算快耗尽时，应该停止、降级还是总结已有结果？

这和传统系统里的 timeout、rate limit、memory limit 很像。以前我们限制进程资源，现在要限制 agent 资源。

还有一个容易被忽略的问题：token 账单要能被信任

当 token 变成计费核心，另一个问题也会出现：token 数本身是否可审计？

最近一篇 arXiv 论文讨论了 token inflation 的风险。它的核心观点是，商业模型通常会隐藏模型实现、tokenizer 和执行细节，用户很难独立验证 provider 报告的 token 数是否完全可信。

这不代表每个平台都会乱报账单，但它提醒我们：当按 token 计费成为主流，成本可观测性和审计能力也会变成基础设施问题。

以后团队做 AI 成本治理，不能只保存一行总金额。更合理的做法是记录：

层级	需要记录什么
任务层	用户目标、任务 ID、执行入口
模型层	使用了哪个模型、provider、价格档位
用量层	input / output / cached tokens，是否 streaming
工具层	搜索、浏览器、CI、外部 API 等额外成本
控制层	预算、限流、降级、阻断原因
结果层	任务是否完成，是否重试，是否人工接管

这和我之前写 Agent observability 时提到的“意图到动作日志”是一条线：AI 系统越能自主行动，越需要把成本、权限、上下文和结果串起来看。

对个人开发者的建议

如果你只是日常使用 AI 编程工具，我建议先养成几个习惯。

第一，不要默认所有任务都用最强模型。简单补全、解释错误、生成小脚本，可以用便宜模型；架构设计、复杂调试、跨文件修改，再切强模型。

第二，大任务先让 AI 计划，不要直接让它无限执行。计划阶段可以暴露上下文范围、风险点和验证方式，也能减少后续反复试错。

第三，长任务要设停止条件。比如最多跑几轮测试、最多读取哪些目录、失败后先总结而不是继续猜。

第四，关注账单里的“形状”，不是只看总额。真正值得看的指标是哪些任务、模型、工具和人消耗最多。

对小团队的建议

小团队更应该把 AI 成本当成工程治理，而不是财务报销。

可以从这几个动作开始：

给不同场景分预算
- 日常问答
- 代码生成
- 自动 code review
- 批量重构
- CI 里的 AI 检查
给不同身份分权限
- 普通开发者默认便宜模型；
- 资深开发者可以手动切换强模型；
- 自动化任务必须有硬预算；
- 生产相关任务必须有审批。
给 Agent 设置硬边界
- 最大花费；
- 最大迭代轮数；
- 最大上下文范围；
- 最大工具调用次数；
- 失败后的降级策略。
把成本写进复盘
- 这次 AI 帮我们节省了多少人工时间？
- 花费主要来自模型还是工具？
- 哪些步骤其实可以用规则、缓存或脚本替代？
- 是否应该沉淀成 skill，减少下次重复消耗？

这不是坏事

很多人看到 token 计费，第一反应会是“AI 工具变贵了”。

这当然是现实问题。但从长期看，这也是 AI 工具走向成熟的信号。

订阅制把复杂度藏起来，适合早期教育市场；usage-based billing 把真实成本暴露出来，逼着用户和平台一起面对资源消耗。

当 Agent 开始真正替你跑任务，成本治理就不是可选项。

更成熟的 AI 工程系统，应该同时具备：

模型选择；
上下文管理；
权限控制；
工具审计；
预算限制；
任务复盘；
降级和停止策略。

一句话总结：

AI 工具的下一阶段，不只是“更聪明”，而是“更可控”。

谁能把成本、权限和执行边界管理好，谁才更适合把 AI Agent 放进真实工作流里。

参考

用 Codex 优化网速靠谱吗？先把它当成网络诊断助手

Sat, 30 May 2026 23:20:00 +0800

最近刷到一个很有传播性的说法：有人用 Codex 把电脑网速从 400Mbps 优化到了 900Mbps。

听起来像玄学，但细看之后，这件事没有那么神，也不是完全没用。

我的结论很简单：Codex 不能突破你的宽带套餐、路由器、光猫和运营商上限，但它可以像一个会用终端的网络诊断助手，帮你把本机网络配置、DNS、代理、Wi-Fi 状态和后台进程系统性查一遍。

如果问题真的出在本机配置，它可能有明显效果；如果瓶颈在运营商、路由器、墙体信号、网线或远端服务，它最多只能告诉你问题不在电脑上。

事情是怎么火起来的

最早看到的是 X 上这条提示词，核心思路不是“让 Codex 神奇加速”，而是要求它按流程做三件事：

先跑 before 基准；
再做安全、可逆、低风险修改；
最后复测 before / after。

这个思路比“帮我优化网速”靠谱得多。因为网络问题很容易被错判：测速站点、DNS、VPN、代理、Wi-Fi 频段、后台同步、路由器位置、系统网络服务顺序，任何一个点都可能影响结果。

爱范儿也写了一篇实测文章，标题很抓人：用 Codex 优化网速狂飙 900Mbps。文章里提到，原案例的关键解释是 Windows 上的 auto tuning level 被从关闭调回了 normal。

这里要注意一个边界：这不是 Codex 改变了运营商给你的带宽，而是它可能发现了本机网络栈里被错误关闭的能力。

Codex 真正能做什么

我更愿意把它理解成“网络排查执行器”。

它能做的通常是这些：

跑测速和延迟基准，比如下载、上传、空闲延迟、加载延迟；
检查 DNS 解析耗时，判断是不是 DNS 配置拖慢了访问；
检查默认路由、代理、VPN、TUN 设备和网络服务顺序；
查看 Wi-Fi 信号强度、频段、信道、Tx Rate 和噪声；
发现占带宽的后台进程，比如网盘同步、下载器、VPN、代理客户端；
在 Windows 上检查 TCP Auto-Tuning、DNS 缓存、网络适配器状态；
在 macOS / Linux 上检查路由、DNS、网络服务、MTU 和丢包。

这些事人当然也能做，但麻烦在于命令分散、指标多、判断链路长。Codex 的价值在于：它可以把一组检查串成流程，并把结果整理成“发现了什么、改了什么、是否有效”。

实测不一定会变快

爱范儿的实测结果就比较冷静：他们让 Codex 按提示词检查 DNS、数据包、网络配置等问题，Codex 也确实给出了几个结论，但复测后没有明显网速提升。

这其实更接近真实情况。

如果你本机没有明显错误配置，Codex 做完清理 DNS、调整服务顺序、提示关闭后台进程之后，测速可能不会有什么变化。它能提升的是“被本机问题拖慢的部分”，不是凭空给你增加带宽。

所以判断它有没有用，不能只看“测速数字有没有变大”，还要看：

DNS 解析是不是更稳定；
延迟和抖动是不是下降；
丢包有没有减少；
VPN / 代理是否误接管了路由；
Wi-Fi 链路速率是否匹配你的宽带；
后台进程是否一直占用上传或下载。

有时候“网速慢”的体感，不是下载带宽低，而是 DNS 慢、首包慢、丢包高、代理绕路或 Wi-Fi 干扰严重。

风险也是真实存在的 ⚠️

这类任务最大的问题是：它会碰系统网络配置。

爱范儿文章里也提醒，有评论提到 Codex 把原有网络配置删掉后，还解释说这是为了让网速更快。这个风险不能忽略。

所以我不建议直接对 Codex 说：

帮我优化网速，直接改。

更好的方式是把权限和边界说清楚：

目标：优化当前电脑的网络速度和稳定性。

工作方式：
1. 先诊断，不要直接修改；
2. 给出 before 基准，包括下载、上传、延迟、DNS、丢包、默认路由；
3. 解释每个异常指标可能代表什么；
4. 只提出安全、可逆、低风险修改；
5. 任何需要 sudo、删除网络服务、重置网络、影响 VPN 或远程连接的动作，都必须先说明风险并等待确认；
6. 修改后复测，并对比 before / after。

限制：
- 不要删除现有网络配置；
- 不要破坏 VPN、代理和远程连接；
- 不要修改路由器或运营商侧配置；
- 如果无法确认收益，就只输出建议，不执行修改。

如果你在 Codex 里使用目标命令，可以写成：

/goal 提升当前电脑的网络稳定性和可用带宽表现；
通过 before/after 的测速、DNS 查询耗时、ping 延迟、丢包和路由信息验证；
约束是不删除网络配置、不重置网络、不影响 VPN/远程连接；
只允许先诊断和提出可逆修改，涉及 sudo 或系统配置变更时必须等待确认。

不同系统的关注点

不同系统上，Codex 能排查的重点也不一样。

macOS

macOS 上可以先关注：

networkQuality 的上下行和响应性；
scutil --dns、scutil --proxy、scutil --nwi；
Wi-Fi 的 RSSI、噪声、Tx Rate、频段；
网络服务顺序；
VPN、代理、Tailscale、Clash、Stash、Shadowrocket 等是否接管路由。

macOS 很多底层网络参数并不适合乱改，所以更适合让 Codex 做诊断、解释和建议。

Windows

Windows 上可以关注：

TCP Auto-Tuning 是否被关闭；
DNS 缓存、网卡驱动、网络适配器状态；
代理、VPN、虚拟网卡；
电源管理是否让网卡省电；
任务管理器里是否有异常占用网络的进程。

如果 auto tuning level 这类配置真的被错误关闭，恢复默认值可能会有明显收益。但这仍然应该先看当前值，再决定是否修改。

Linux

Linux 上可以关注：

ip route、resolvectl status、nmcli；
DNS、MTU、丢包、默认路由；
容器、虚拟网卡、代理、TUN/TAP；
后台同步、下载任务和服务进程。

Linux 的网络配置差异更大，尤其是服务器和桌面发行版差异明显，更应该先让 Codex 输出判断依据。

我会怎么用

我不会把这件事当成“AI 网速加速器”，而是当成一个排查清单自动执行器。

比较稳的流程是：

先手动跑一次测速，记下结果；
让 Codex 只做诊断，不改配置；
让它解释异常点和可能原因；
只批准最小、可逆的修改；
每改一项就复测，不要一次改一堆；
如果没有明显收益，保留诊断结论，不继续折腾。

最有价值的不是那句“从 400Mbps 到 900Mbps”，而是这个工作方式：给 Agent 一个目标，同时给它证据、约束和验收标准。

这也是 Codex 越来越有意思的地方。它不只是写代码，也可以变成一个会使用工具、会跑诊断、会做对比的工作台。

但越是接近系统设置、账号权限、网络连接、文件删除这类高风险区域，越要让它慢下来。

结论

Codex 优化网速这件事，靠谱但别神化。

它靠谱的地方在于：可以系统性检查本机网络问题，把 DNS、代理、Wi-Fi、后台进程、网络服务顺序和系统配置串起来看。

它不靠谱的地方在于：不能突破物理链路和运营商上限，也不应该被允许直接大改网络配置。

我的建议是：让 Codex 先做网络体检，再由你决定要不要动手治疗。

参考来源：

FreeDomain：给个人项目和开源项目一个免费的域名入口

Fri, 29 May 2026 20:00:00 +0800

一句话定位

DigitalPlat FreeDomain 是一个提供免费域名注册与 DNS 托管接入的平台，目标是让个人、开发者、开源项目和组织能低成本拥有自己的线上域名身份。

基础信息卡片

项目	信息
GitHub 仓库	https://github.com/DigitalPlatDev/FreeDomain
官网	https://domain.digitalplat.org
注册控制台	https://dash.domain.digitalplat.org/
主要语言	HTML，少量 JavaScript / Python
开源协议	AGPL-3.0
GitHub 热度	约 171k Stars、3.3k Forks
当前可用后缀	`.DPDNS.ORG`、`.US.KG`、`.QZZ.IO`、`.XX.KG`、`.QD.JE`

解决什么问题

域名是网站上线最基础的一环，但对学生、个人开发者、小型团队、开源项目或非营利组织来说，购买和续费域名仍然是一笔需要考虑的成本。

FreeDomain 试图降低这一步的门槛：用户可以申请一个免费的域名，再把它接入自己熟悉的 DNS 服务，用来承载个人主页、项目文档、Demo 页面、开源服务或组织官网。

它的重点不是替代传统商业域名注册商，而是给预算有限、处于早期验证阶段的项目提供一个更容易开始的入口。

核心功能

免费域名注册

用户可以通过 DigitalPlat FreeDomain 控制台申请免费域名。目前 README 中列出的可用后缀包括 .DPDNS.ORG、.US.KG、.QZZ.IO、.XX.KG 和 .QD.JE。

对很多个人项目来说，这类域名已经足够用于上线展示、测试服务或对外分享。

自由选择 DNS 服务

FreeDomain 不要求用户绑定某一个固定 DNS 平台。README 中提到，用户可以使用 Cloudflare、FreeDNS by Afraid.org、Hostry，也可以使用自己的 DNS 基础设施。

这意味着拿到域名后，后续解析、CDN、SSL、访问控制等能力，可以继续沿用自己熟悉的服务商和工作流。

面向新手的教程文档

仓库内提供了教程入口，覆盖账号创建、DNS 托管配置、域名激活等基础步骤。文档明确面向第一次使用域名的用户、个人开发者、开源项目和非营利组织。

这对没有 DNS 经验的人比较友好：不需要先理解完整的域名体系，也可以按步骤完成最基本的上线配置。

滥用处理与安全提醒

免费域名平台容易遇到滥用问题，因此项目提供了 abuse report 邮箱，用于处理域名滥用举报。

README 中还特别提醒：此前的 Telegram 账号和群组已经被攻破，不再作为官方沟通渠道。项目当前推荐的社区渠道是 Discord。使用这类免费服务时，最好以 GitHub、官网和官方 Discord 信息为准，避免相信非官方渠道里的链接或公告。

适合谁

想给个人主页、项目 Demo、文档站配置域名的个人开发者
预算有限、但希望拥有独立域名入口的学生和创作者
需要快速上线展示页面的开源项目
想配合 Cloudflare 等 DNS/CDN 服务使用免费域名的用户
小型组织、公益项目或早期产品原型

快速上手

打开注册控制台： https://dash.domain.digitalplat.org/
注册或登录 DigitalPlat 账户。
选择一个可用的免费域名后缀，例如 .us.kg、.dpdns.org 等。
提交域名申请。
配置 DNS：
- 可以使用 Cloudflare；
- 也可以使用 FreeDNS、Hostry；
- 或者接入自己的 DNS 服务。
根据官方教程完成域名激活和解析配置： https://github.com/DigitalPlatDev/FreeDomain/blob/main/documents/tutorial/index.md

需要注意的是，FAQ 中提到当前默认限制是每个用户账户 1 个域名。这是为了减少滥用并保证公平使用。

结论

FreeDomain 的价值很直接：让更多人可以先拥有一个能用的域名，再去搭建自己的网站或项目。

如果你正在做个人项目、开源项目、学生作品集、公益页面或早期产品 Demo，它可以作为一个低成本的域名入口。后续仍然可以搭配 Cloudflare 等成熟 DNS 服务使用，整体迁移和管理成本也比较低。

不过，免费域名通常会有使用规则、额度限制和滥用审核。用于长期正式业务之前，建议先认真阅读项目 FAQ 和平台政策；用于学习、展示、验证和轻量项目，则是一个值得了解的选择。

Pi 项目介绍：把 Coding Agent 做成可改造的终端 Harness

Wed, 27 May 2026 23:45:00 +0800

这两年 AI Coding 工具越来越像完整产品：内置计划模式、权限弹窗、子代理、MCP、任务列表、后台任务、图形界面。

earendil-works/pi 走的是另一条路：核心保持轻，能力尽量开放给用户自己扩展。

项目地址：https://github.com/earendil-works/pi

官网文档：https://pi.dev/

一句话定位

Pi 是一个可自定义的终端 AI coding agent harness：它提供编码 Agent、工具调用 runtime、统一模型 API、TUI 组件和包机制，让你按自己的工作流改造 Agent，而不是被工具默认形态限制。

如果说很多 Coding Agent 是“开箱即用的产品”，Pi 更像是“可以自己搭积木的 Agent 底座”。

基础信息卡片

字段	内容
项目名	Pi
仓库	https://github.com/earendil-works/pi
官网	https://pi.dev/
License	MIT
技术栈	TypeScript 为主
核心包	`pi-coding-agent`、`pi-agent-core`、`pi-ai`、`pi-tui`
运行形态	交互式 TUI、print/JSON、RPC、SDK
核心场景	终端 Coding Agent、自定义 Agent 工作流、模型/工具/界面扩展

说明：Stars、Forks、版本号和语言占比会持续变化，发布后请以 GitHub 页面实时数据为准。

它解决什么问题

现在很多 Agent 工具的能力越来越强，但也带来一个问题：默认工作流越来越重。

有些人需要内置 plan mode、权限确认、MCP、子代理和图形界面；也有人只想要一个轻量、可脚本化、能嵌进自己终端工作流的 Agent。

Pi 的判断是：

不要把所有功能都塞进核心；
保留足够小的 Agent harness；
把扩展点开放出来，让用户按自己的工作流组合。

这也是它最值得看的地方。Pi 不是单纯再做一个 Claude Code 或 Codex 的替代品，而是在回答另一个问题：Agent 的“底座”应该长什么样，才能被个人和团队长期改造？

核心功能

1. 终端优先的 Coding Agent

Pi 的主要入口是终端 TUI。它支持常见的 AI coding agent 工作流：读取项目上下文、调用工具、修改文件、执行命令、在会话中继续迭代。

官网给出的定位很明确：Pi 是一个 minimal terminal coding harness。重点不是把每个功能都做成固定按钮，而是让你可以把它接进自己的终端习惯里。

2. 多模型、多 provider

Pi 通过 @earendil-works/pi-ai 提供统一的多 provider LLM API。

官网列出的 provider 覆盖 Anthropic、OpenAI、Google、Azure、Bedrock、Mistral、Groq、Cerebras、xAI、Hugging Face、OpenRouter、Ollama 等。实际可用情况取决于你的配置、账号和 API Key。

这对团队有用：你可以把“Agent 工作流”和“模型供应商”拆开，不必因为换模型就换整套工具。

3. 可扩展的 Agent runtime

@earendil-works/pi-agent-core 提供工具调用、状态管理等 Agent runtime 能力。

这意味着 Pi 不只是一个 CLI，也可以作为更底层的 Agent 组件被复用。你可以把它嵌到自己的 Node.js 应用里，或者通过 RPC / JSON event stream 让其它系统调用它。

4. Skills、Prompt Templates、Extensions 和 Packages

Pi 的扩展思路很接近“把上下文工程产品化”：

Skills：按需加载的能力说明和工具约束；
Prompt Templates：可复用的提示词模板；
Extensions：TypeScript 模块，可扩展工具、命令、快捷键、事件和 TUI；
Pi Packages：把 extensions、skills、prompts、themes 打包分享。

这套机制的价值在于：你不必每次都靠一段超长 prompt 控制 Agent，而是把稳定的规则、工具和工作流沉淀成可复用资产。

5. 会话树与可分享历史

Pi 的 session 是树结构，可以回到之前某个节点继续分支，也可以导出 HTML 或分享 session。

这点对调试 Agent 很重要。真实工作流里，Agent 往往会经历尝试、失败、修正、回退。树状历史比线性聊天更适合保留这些决策路径。

一个重要取舍：核心不追求全内置

Pi 官网专门列了“What we didn’t build”：没有内置 MCP、没有内置 sub-agents、没有内置 permission popups、没有内置 plan mode、没有内置 todos、没有内置 background bash。

这不是简单的“缺功能”，而是产品哲学：

核心提供 primitives，复杂功能通过扩展、技能、脚本、tmux 或包来实现。

这个取舍会筛选用户。

如果你想要完整、保守、开箱即用的 Agent 产品，Pi 可能会显得太自由；如果你想控制 Agent 的系统提示词、上下文、命令、UI 和运行方式，Pi 反而更有吸引力。

适合谁 / 不适合谁

适合谁

经常在终端里工作的开发者；
想研究 AI coding agent 底层机制的人；
想把 Agent 接入自己工具链、脚本或产品的人；
对 skills、prompt templates、extensions 有长期沉淀需求的团队；
需要多模型、多 provider 切换，但不想绑定单一平台的人。

不适合谁

只想要零配置、图形化、开箱即用的普通用户；
不愿意理解终端、配置文件和扩展机制的人；
需要企业级权限审计、集中管控、稳定 SLA 的团队；
只追求“马上替我写完代码”，不关心 Agent 工作流可塑性的人。

快速上手

官方文档给出的 npm 安装方式：

npm install -g --ignore-scripts @earendil-works/pi-coding-agent

macOS / Linux 也可以使用安装脚本：

curl -fsSL https://pi.dev/install.sh | sh

然后在项目目录运行：

pi

认证方式可以用 /login，也可以设置模型供应商的 API Key，例如 ANTHROPIC_API_KEY。具体 provider 配置建议以官方文档为准。

我会怎么试用

如果只是“看一眼”，不要一上来就研究所有扩展机制。

更好的试用路径是：

找一个非核心仓库；
用 pi 让它读项目并做一个小改动；
试一次 pi -p "..." 的 print 模式，看它是否适合脚本化；
看 session tree、skills、prompt templates 是否能沉淀你的固定工作流；
再决定要不要研究 extensions 和 packages。

重点不是它第一次生成得多惊艳，而是你能不能把自己的规则放进去，并且长期复用。

优缺点（客观）

优点

核心轻，适合终端重度用户；
扩展点明确，适合做上下文工程和自定义工作流；
多 provider 支持较完整，降低模型绑定；
会话树、导出和分享能力适合复盘 Agent 行为；
MIT License，对二次开发和商业探索友好。

可能的限制

自由度高意味着学习成本也高；
很多高级能力需要通过扩展或外部工具组合实现；
对非终端用户不够友好；
团队级权限、安全、审计能力需要自己补齐；
生态是否成熟，要看后续 packages、extensions 和社区贡献的质量。

可变现方向（若你想做产品化）

团队 Agent Harness 定制：基于 Pi 给研发团队做统一的 coding agent 工作流。
行业 Skills / Packages：为前端、数据分析、DevOps、安全审计等场景做可安装包。
企业私有化 Agent 底座：把模型路由、审计、权限和内部工具接进 Pi runtime。
Agent 工作流咨询：帮团队把 prompt、AGENTS.md、skills、templates 和 CI 验证流程沉淀下来。

结论

Pi 最有价值的地方，不是“它也能写代码”，而是它把 Coding Agent 拆成了更可改造的几层：CLI、runtime、模型 API、TUI、skills、extensions 和 packages。

如果你需要的是一个成熟的一体化产品，Codex、Claude Code、Cursor 这类工具可能更直接。

但如果你在意的是：我的 Agent 能不能按我的工作流长出来，Pi 就很值得研究。

它代表了一种很有意思的方向：Agent 不只是工具本身，也可以是一个可持续演化的开发者工作台底座。

GitHub Trending 的信号：AI Agent 正在进入 Skills 工程化阶段

Wed, 27 May 2026 23:40:00 +0800

2026 年 5 月 27 日，我看了一眼 GitHub Trending，最有意思的不是某个单点项目突然爆了。

真正值得注意的是：榜单里同时出现了一批和 AI Agent Skills、插件、工作流、知识图谱、领域方法论 有关的项目。

如果只看单个项目，它们各自解决的问题并不一样：

有的帮 Agent 理解代码库；
有的给 Agent 装上软件开发方法论；
有的把内容审美、写作风格、安全分析做成 skill；
有的把知识工作岗位拆成插件；
有的试图把 memory、hooks、MCP、规则和安全扫描打包成一套 agent harness。

但把它们放在一起看，趋势很清楚：AI Agent 的竞争点正在从“模型会不会回答”转向“工作方法能不能被安装、复用、验证和团队化”。

今天看到的几个项目信号

下面不是完整榜单，而是我从今天 GitHub Trending 中挑出来、和 Agent 工作流最相关的一组项目。

项目	它在做什么	我看到的信号
Lum1104/Understand-Anything	把代码库、知识库、文档转成可探索、可搜索、可提问的交互式知识图谱	Agent 不只要读文件，还要先建立“系统地图”
obra/superpowers	给 coding agent 提供一套由 skills 组成的软件开发方法论	开发流程开始被封装成可触发的技能链
affaan-m/ECC	把 skills、memory、hooks、安全扫描、研究优先流程等打包成跨 harness 系统	Agent harness 正在从配置文件演化成操作系统
anthropics/knowledge-work-plugins	为销售、客服、产品、市场、法务、财务、数据等岗位提供知识工作插件	插件不再只服务程序员，也开始服务岗位工作流
hardikpandya/stop-slop	用 skill 约束 AI 写作里的套路化表达	质量标准可以被写成可复用的编辑器
Leonxlnx/taste-skill	用 skill 约束前端设计审美、动效、密度和反套路输出	“品味”也开始被流程化、检查化
mukul975/Anthropic-Cybersecurity-Skills	把安全分析方法拆成 754 个结构化 cybersecurity skills	领域专家经验正在变成 Agent 可执行的 playbook

我更愿意把这类项目理解成一个新层级：Agent 能力包。

它不是单个 prompt，也不是一个聊天模板，而是一组能被版本管理、安装、更新、组合和审计的工作方法。

为什么这比“写一个好提示词”重要

早期使用 AI Agent，很多人会把重点放在 prompt 上。

比如：

给它一个更详细的系统提示词；
在项目里写一份 AGENTS.md；
给它一段“你是资深工程师”的角色设定；
让它按某种格式输出。

这些都有用，但 prompt 很快会遇到三个问题。

第一，不可维护。一大段提示词越写越长，最后谁都不知道哪些规则真的有效，哪些只是历史遗留。

第二，不可组合。写代码、做 UI、查安全、改文案、整理数据，都塞进同一个提示词里，Agent 很容易在错误场景触发错误规则。

第三，不可验证。如果一次输出变好了，很难判断是模型变强了、上下文刚好够用，还是那段规则真的起了作用。

Skills 和插件的价值在这里：它们把“怎么做某类工作”拆成相对独立的能力单元。

一个好的 skill 应该回答这些问题：

它适合什么任务？
它不适合什么任务？
它需要读哪些上下文？
它产出什么？
它怎么验证自己没跑偏？
它能不能在 Claude Code、Codex、Cursor、Gemini CLI 等不同 harness 里迁移？

这就是从“提示词”走向“工程资产”的关键差异。

这波项目背后的四个方向

1. 代码理解先变成基础设施

Understand-Anything 这类项目说明，一个大型代码库不能只靠 Agent 临时 rg、cat、打开几个文件来理解。

真正有价值的是先生成结构化地图：

flowchart LR
A[代码库] --> B[静态结构解析]
A --> C[LLM 语义总结]
B --> D[知识图谱]
C --> D
D --> E[搜索 / 问答 / 影响分析 / 新人导览]

这件事和传统文档不同。文档经常过期，知识图谱如果能跟随提交增量更新，就会变成 Agent 的长期上下文。

未来团队接入 Agent，第一步可能不是“让它改代码”，而是“让它先给仓库建一张可查询的系统地图”。

2. 工作方法开始被安装

superpowers、ECC 这类项目不是在给 Agent 一个新命令，而是在给 Agent 一套工作纪律。

比如先澄清目标、写设计、拆计划、做验证、跑 code review、用 worktree 隔离风险。这些原本是工程团队里的流程经验，现在被写成 skills 和 hooks。

这会让 Agent 的表现从“看运气”变成“更接近流程驱动”。

我不认为每个项目都需要完整套用这类方法论。轻量任务不应该被流程拖慢。但它们指出了一个方向：当 Agent 开始处理真实仓库、真实权限、真实发布链路时，方法论会比单次聪明更重要。

3. 领域经验正在被拆成 playbook

Anthropic-Cybersecurity-Skills 把安全工作拆成大量结构化 skills，并映射到 MITRE ATT&CK、NIST CSF、MITRE ATLAS、D3FEND、NIST AI RMF 等框架。

这件事的意义不只是“安全领域也有 skill 了”。

更大的信号是：领域专家的判断路径正在变成 Agent 可调用的 playbook。

以后不只是安全。法务、财务、销售、客服、产品、增长、数据分析，都可能出现类似结构：

任务类型 -> 适用 skill -> 输入上下文 -> 执行步骤 -> 风险点 -> 验证标准 -> 交付物

这会让 AI Agent 从“泛用助手”变成“带岗位 SOP 的执行者”。

4. 质量标准也可以被技能化

stop-slop 和 taste-skill 很有代表性。

它们不是让 Agent 多知道一个 API，而是把“不要写 AI 味”“不要做无聊 UI”“注意节奏、密度、动效、层级”这些模糊质量要求写成可触发的 skill。

这类项目看起来轻，但很关键。因为大多数 AI 输出的问题不是完全错误，而是：

正确但空泛；
能跑但不好用；
有内容但没审美；
有结构但不像真人写的；
生成了界面但没有产品语境。

当质量标准可以被单独封装，团队就不必每次都重新解释“我们想要什么风格”。这也是知识复用。

对开发者的实际启发

如果你现在已经在用 Codex、Claude Code、Cursor 或其他 coding agent，我建议不要只关注“哪个模型更强”。

更应该开始整理三类资产。

第一类是 项目级规则：放在 AGENTS.md、CLAUDE.md、README 或 docs 里，告诉 Agent 这个仓库怎么构建、怎么测试、哪些目录不能乱动、怎么发布。

第二类是 任务级 skills：比如“写 Hugo 双语文章”“排查 Go 服务慢启动”“生成 GitHub issue 封面图”“做一次前端视觉审计”。这些任务如果会重复发生，就值得变成 skill。

第三类是 验证脚本：没有验证，skill 很容易变成漂亮的建议。每个常见任务最好都有对应的 hugo --renderToMemory --minify、go test、pnpm test、seo-check、截图检查或 diff check。

我自己的判断标准很简单：

问题	如果答案是“是”，就值得做成 skill
这个任务会重复出现吗？	是
每次都需要解释相同背景吗？	是
失败通常来自同一类坑吗？	是
产出有明确验收标准吗？	是
能不能限制它只读/只改某些范围？	是

满足三条以上，就别再只靠口头提示了。

下一步会发生什么

我觉得接下来会出现三个明显变化。

第一，skill registry 会变重要。大家需要发现、安装、更新、评分、组合 skills，而不是到处复制 Markdown。

第二，团队私有 skills 会变成生产力资产。公开 skill 解决通用问题，真正有价值的是团队自己的业务流程、代码规范、发布规则、事故经验。

第三，skills、memory、observability 会合在一起。Agent 需要知道该用什么方法，也需要记住历史经验，还需要留下可审计的执行链路。

所以今天 GitHub Trending 里的这些项目，不只是热闹。

它们在提示一个更大的方向：AI Agent 正在从“聪明的聊天窗口”变成“可安装方法论 + 可复用能力包 + 可验证执行链路”的工程系统。

这也是我觉得 2026 年开发者工具最值得盯的一条线。

参考

GitHub Trending Today: https://github.com/trending?since=daily
Understand-Anything: https://github.com/Lum1104/Understand-Anything
Superpowers: https://github.com/obra/superpowers
ECC: https://github.com/affaan-m/ECC
Knowledge Work Plugins: https://github.com/anthropics/knowledge-work-plugins
Stop Slop: https://github.com/hardikpandya/stop-slop
Taste Skill: https://github.com/Leonxlnx/taste-skill
Anthropic Cybersecurity Skills: https://github.com/mukul975/Anthropic-Cybersecurity-Skills

AI Agent 需要可观测性：为什么下一代安全日志要记录“意图到动作”

Sat, 23 May 2026 21:05:00 +0800

现在很多团队在接 AI Agent 时，第一反应是加权限、加审批、加 sandbox。

这些都对，但还少了一层：可观测性。

传统系统的安全日志通常回答三个问题：

谁调用了接口？
什么时候调用的？
成功还是失败？

但 Agent 不一样。它不是简单点按钮，也不是固定执行一条 API。它会理解目标、拆计划、读上下文、选择工具、生成参数、等待确认，再执行动作。

所以下一代安全日志不能只记录“做了什么”，还要记录：它为什么认为自己应该这么做。

一句话定位

Agent 安全日志的核心，不是多打一行 log，而是把“用户意图 → Agent 计划 → 工具调用 → 权限判断 → 实际动作 → 执行结果”串成一条可追溯链路。

如果只看到最后一条：

DELETE /api/users/123 200 OK

你并不知道这是：

用户明确要求删除；
Agent 误解了“停用账号”；
页面里的恶意文本诱导它执行；
某个自动化流程越权调用；
还是审批逻辑本来就放行了错误动作。

这些场景在传统日志里可能长得一模一样。

传统日志为什么不够

传统应用里，用户点按钮，后端执行接口。安全日志记录接口、身份、IP、状态码，基本能还原责任链。

Agent 加入之后，中间多了几层：

flowchart LR
A[用户目标] --> B[Agent 理解]
B --> C[任务计划]
C --> D[工具选择]
D --> E[参数生成]
E --> F[权限 / 策略判断]
F --> G[人工确认]
G --> H[实际执行]
H --> I[结果反馈]

真正危险的地方，往往不在最后一步。

比如 Agent 最终确实调用了一个合法 API，凭据也有效，权限也没过期。但问题可能是：

用户本意是“归档”，Agent 理解成“删除”；
检索到的网页内容里藏了诱导指令；
Agent 选择了错误工具；
工具参数来自不可信上下文；
策略引擎只看了权限，没有看任务意图；
人工确认界面只展示了动作，没有展示原因。

这时只看 API audit log，会得到一个很尴尬的结论：一切看起来都正常。

Agent 日志应该记录什么

我会把 Agent 安全日志分成六层。

层级	要记录什么	为什么
目标层	用户原始目标、压缩后的任务意图、任务来源	判断动作是否偏离用户本意
推理层	Agent 计划、关键决策点、选择某个工具的理由	还原“为什么走到这一步”
上下文层	参与决策的文件、网页、检索片段、memory 来源	判断是否被不可信上下文影响
工具层	工具名、动作类型、参数摘要、资源范围	知道 Agent 准备做什么
控制层	策略判断、权限结果、人工确认、阻断原因	证明安全控制是否生效
结果层	实际执行结果、外部系统返回、回滚信息	形成完整审计闭环

注意，这里不是让你把所有 prompt、网页、参数原文都存下来。

安全日志应该记录的是可审计证据，不是把敏感上下文复制一份。

一个更实用的日志结构

如果我要给 Agent 设计第一版日志事件，我会从这些字段开始：

{
 "event.name": "agent.tool.execution",
 "trace_id": "01HT...",
 "agent.session_id": "sess_123",
 "agent.intent_id": "intent_456",
 "agent.task_id": "task_789",
 "user.id": "u_001",
 "user.goal_summary": "停用某个测试账号，而不是删除账号数据",
 "agent.plan_step": "调用账号状态更新工具",
 "agent.decision": "选择 update_user_status，因为目标是停用账号",
 "tool.name": "user_admin",
 "tool.action": "update_status",
 "tool.args_hash": "sha256:...",
 "target.resource": "user:123",
 "risk.level": "medium",
 "policy.decision": "allow",
 "approval.required": true,
 "approval.actor": "human",
 "context.refs": [
 "issue:28",
 "file:docs/account-lifecycle.md"
 ],
 "result.status": "success"
}

这份日志有几个关键点：

trace_id 把一次 Agent 任务里的多条事件串起来；
intent_id 记录用户目标，不和单次工具调用混在一起；
tool.args_hash 避免直接存敏感参数原文；
policy.decision 说明策略层有没有介入；
approval.* 说明关键动作是否有人确认；
context.refs 只记录来源引用，不把全文塞进日志。

这样出问题时，你不是只查“谁调用了接口”，而是能问：

这个动作对应的原始意图是什么？
Agent 是在哪一步选择了这个工具？
参数来自哪里？
策略为什么放行？
有没有人工确认？
执行结果是否和计划一致？

最关键的是“动作前日志”

很多系统只在动作完成后记日志。

对 Agent 来说，这不够。

Agent 至少需要两类事件：

1. 动作前事件

记录 Agent 准备做什么：

当前意图；
计划步骤；
工具选择理由；
参数摘要；
风险等级；
权限判断；
是否需要人工确认。

如果这里就发现风险，可以在执行前阻断。

2. 动作后事件

记录实际发生了什么：

调用了哪个外部系统；
返回结果是什么；
是否失败或重试；
是否触发补偿动作；
是否改变了数据状态。

动作前日志解决“为什么要做”，动作后日志解决“最后做了什么”。

缺少前者，很多 Agent 事故只能看到结果，无法还原意图偏移。

不要把日志变成新的泄漏面

Agent 日志越细，越容易踩到另一个坑：把敏感信息全存进日志。

我会明确禁止记录这些内容：

API key、token、cookie、SSH 私钥；
完整 prompt 和完整工具参数；
用户输入里的隐私字段；
网页正文里的敏感业务数据；
未脱敏的订单、账号、学生、客户信息；
大段 memory 原文。

更合适的方式是：

原文只在短期安全存储里保留，设置过期时间；
长期日志只存摘要、hash、资源 ID、来源引用；
高风险字段单独打标签，查询也需要权限；
日志系统本身也要有审计记录；
训练、分析、报表默认不使用原始敏感日志。

可观测性不是“什么都保存”，而是“关键证据能被安全地还原”。

从工程上怎么落地

第一版不用做得很复杂。我会按这个顺序做：

1. 先打通 trace

一次用户请求、一次 Agent run、一次工具调用，都要能串起来。

至少需要：

trace_id
agent.session_id
agent.intent_id
tool.call_id

OpenTelemetry 的日志模型里已经有 TraceId、SpanId、Attributes、EventName 这类字段，适合承载这种结构化事件。不要把 Agent 行为只写成一段不可解析的字符串。

2. 在工具网关统一打点

不要让每个工具自己随便写日志。

更稳的做法是让所有工具调用都经过一个 tool gateway：

Agent → Tool Gateway → Policy Check → Human Approval → Tool Execution

这样你可以在同一个地方记录：

工具调用前的 intent / plan / args；
策略判断；
审批状态；
执行结果；
失败和重试。

安全控制和日志打点在同一个边界上，排障会简单很多。

3. 给高风险动作做单独事件

不是所有动作都需要同样粒度。

这些动作应该单独提升日志等级：

删除数据；
导出大量数据；
修改权限；
修改账单或支付；
调用生产环境；
访问敏感系统；
自动提交代码或发布。

高风险动作至少要记录：意图、策略、确认人、执行前参数摘要、执行后结果。

4. 做几个真正有用的告警

不要一开始就做一堆 dashboard。

先做这些告警更实用：

高风险工具调用没有人工确认；
Agent 计划是只读任务，但实际发生写操作；
同一个 intent 下出现异常多的工具重试；
工具参数来自不可信上下文；
策略引擎不可用时仍然放行动作；
单个 Agent 在短时间内访问大量资源；
动作结果和计划步骤不一致。

这些告警都不是传统 API 日志能轻易发现的。

一个判断标准

设计 Agent 安全日志时，可以用这个问题检查：

如果明天有一个 Agent 误删数据，我能不能在 30 分钟内回答：用户原本想做什么、Agent 怎么理解、为什么选择这个工具、谁批准、实际影响是什么？

如果不能，说明现在的日志还不够。

结论

Agent 的风险不只来自“有没有权限”，还来自“拿着合法权限做了错误的事”。

所以安全日志也要升级。

下一代 Agent 安全日志应该记录：

用户意图；
Agent 计划；
上下文来源；
工具选择；
策略判断；
人工确认；
实际动作；
执行结果。

这不是为了事后甩锅，而是为了让 Agent 系统变得可解释、可审计、可阻断、可恢复。

真正可用的 AI Agent，不只是能完成任务，也应该能说明自己为什么这么做，以及每一步留下足够清楚的证据。

参考

OWASP：https://genai.owasp.org/resource/agentic-ai-threats-and-mitigations/
OpenTelemetry Events：https://opentelemetry.io/docs/specs/semconv/general/events/
OpenTelemetry Logs Data Model：https://opentelemetry.io/docs/specs/otel/logs/data-model/
NIST AI RMF：https://www.nist.gov/itl/ai-risk-management-framework

Codex 已经不只是写代码工具，而是在变成长任务工作台

Sat, 23 May 2026 15:40:00 +0800

我最近对 Codex 的感受很明确：它已经不只是一个“帮我写代码”的工具。

更准确地说，Codex 正在从代码生成器，变成一个长任务工作台。

它的核心变化不是多一个按钮，而是把线程、工具、权限、验证、自动化、记忆和项目规则串在一起，让你可以把一个任务交给它推进，中途接管、纠偏、复核结果。

一句话定位

以前的 Codex 更像“帮我改这段代码”；现在更像“围绕这个目标，帮我持续推进到可验证结果”。

这类工具的关键不是一次生成多漂亮，而是能不能做到：

任务不断线：同一个 thread 里保留上下文和决策；
过程可接管：你可以随时补充背景、改方向、批准下一步；
结果可验证：跑测试、看 diff、截屏、打开浏览器检查；
经验可沉淀：把重复流程写进 AGENTS.md、Skill 或 automation。

我会怎么用

1. 给每个重要任务开一个长期线程

不要把 Codex 当一次性问答窗口用。

一个 bug、一篇文章、一次重构、一个发布流程，都应该有自己的 thread。这样它能保留前面读过的文件、做过的判断、跑过的命令和你给过的反馈。

我的提示词一般会这样写：

目标：把这个问题从定位推进到可验证修复。
背景：这是线上反馈，相关模块可能在 xxx。
约束：不要改无关文件，不要重构接口，不要碰 public 构建产物。
完成标准：能解释根因，代码已修改，测试或本地验证通过。
工作方式：先读代码和日志，给出判断，再动手改。

重点是把“完成标准”写清楚。Codex 不怕任务长，怕的是目标模糊。

2. 让它用工具验证，而不是只给结论

长任务最容易出问题的地方，是 Agent 自己觉得完成了，但你没有证据。

所以我更喜欢让 Codex 每一步都留下可检查的东西：

代码任务：git diff、测试命令、失败日志、修复后的输出；
前端任务：本地页面截图、浏览器控制台、关键交互验证；
内容任务：来源链接、引用边界、最终 Markdown 文件；
发布任务：dry run、构建产物、部署日志、回滚方式。

这也是 Codex 变成“工作台”的原因：它不只是写文本，还能把终端、文件、浏览器和 diff 放到同一个任务链路里。

3. 把重复要求写进项目规则

如果你每次都要提醒：

不要改 public
默认中文
先跑 hugo --renderToMemory --minify
文章图片放到 static/img/YYYYMMDD

那就不应该每次手动说一遍。

更好的做法是写进项目里的 AGENTS.md，或者沉淀成一个 Skill。这样 Codex 进入这个仓库时，就知道默认边界、语言风格、校验命令和不能碰的文件。

这件事很小，但对长任务很关键。因为长任务不是靠单次提示词撑住的，而是靠稳定规则减少偏航。

4. 把重复任务变成 automation

OpenAI 官方也在强调 Automations：让 Codex 按计划回来做重复任务，然后把结果交给你 review。

我觉得适合先自动化的不是“高风险发布”，而是这些低风险、强重复、可检查的任务：

每周整理最近文章草稿；
每天扫一次仓库里的 TODO / failing tests；
定期总结 GitHub issue / PR 状态；
固定检查站点构建和 SEO 输出；
给长期项目生成一份进展摘要。

一个可用的 automation 提示词可以是：

每周五下午回到这个线程，检查本周新增文章和草稿。
输出三部分：
1. 已发布文章列表；
2. 可以继续优化的标题或配图；
3. 下周最值得写的 3 个选题。
只做总结和建议，不要自动改文件。

先让它做“可复核的整理”，再逐步交给它执行。

5. 手机端接管适合用来“不断线”

OpenAI 近期把 Codex 接进 ChatGPT mobile app，一个重要价值就是：Agent 跑长任务时，你不一定要一直坐在电脑前。

比如它中途问你：

这个方案选 A 还是 B？
能不能运行某个命令？
这个 diff 是否继续扩大？
需要不要改测试？

这些决策如果能在手机上及时回复，长任务就不会卡在一个小确认上。

但我不会把手机端理解成“远程让 AI 随便改生产环境”。更合理的用法是：让它继续推进调查、整理、验证和草稿，关键动作仍然人工确认。

一个可直接复制的长任务模板

下次你想让 Codex 做一个完整任务，可以直接从这个模板开始：

目标：
请完成 [具体任务]，直到达到 [可验证结束状态]。

背景：
- 业务背景：
- 相关路径：
- 已知问题：

约束：
- 不要修改：
- 不要做：
- 必须遵守：

工作方式：
1. 先阅读相关文件和日志；
2. 给出根因或执行计划；
3. 等我确认后再修改高风险内容；
4. 修改后必须运行验证命令；
5. 最后用文件、命令和结果说明完成情况。

完成标准：
- [ ] 代码 / 文档已修改；
- [ ] 验证命令通过；
- [ ] 关键风险已说明；
- [ ] 没有触碰无关文件。

如果任务特别长，可以再加一句：

如果上下文变长，请先总结当前状态、已做决策、剩余任务，再继续。

不适合直接放手的场景

Codex 变强了，但不代表所有事情都应该全自动。

我会保留人工确认的场景包括：

删除生产数据；
修改账号、安全、支付、密钥配置；
大规模重构公共接口；
没有回滚方案的部署；
涉及隐私数据的网页操作。

长任务工作台的价值，是让人从“每一步手动操作”变成“在关键节点做判断”。不是把判断也一起交出去。

结论

Codex 最值得关注的变化，不是它又多会写几行代码，而是它开始能围绕一个目标持续工作。

对我来说，实用的用法就五个：

一个重要任务一个 thread；
开始前写清完成标准；
让它用工具留下验证证据；
把重复规则写进 AGENTS.md 或 Skill；
低风险重复任务再做 automation。

如果你还在把 Codex 当“代码补全 + 聊天窗口”，可以试着换一种提示方式：不要只问它“怎么写”，而是给它一个目标、约束和验收标准，让它像一个可接管的工作台一样推进。

参考

OpenAI：https://openai.com/index/introducing-the-codex-app/
OpenAI：https://openai.com/index/work-with-codex-from-anywhere/
OpenAI Academy：https://openai.com/academy/codex-automations/
OpenAI Developers：https://developers.openai.com/codex/use-cases/follow-goals

HTML Anything：让本地 AI Agent 直接生成可发布 HTML

Sat, 23 May 2026 13:01:30 +0800

一句话定位

HTML Anything 是一个本地优先的 Agentic HTML 编辑器：把 Markdown、表格、草稿、数据等输入交给你本机已登录的 AI coding agent，生成可以直接发布的单文件 HTML 或 PNG。

项目地址：https://github.com/nexu-io/html-anything
官网演示：https://open-design.ai/html-anything/

基础信息卡片

项目	信息
仓库	`nexu-io/html-anything`
核心定位	Agent 时代的 HTML 编辑器
主要技术栈	Next.js、React、Tailwind、SSE、本地 CLI agent 调用
License	Apache-2.0
当前热度	约 4.6k Stars / 476 Forks
支持的 Agent CLI	Claude Code、Cursor Agent、Codex、Gemini CLI、GitHub Copilot CLI、OpenCode、Qwen Coder、Aider
典型输出	HTML、PNG、公众号 / 知乎可粘贴内容、社交平台图片、数据报告、PPT、海报、视频帧

解决什么问题

Markdown 很适合写草稿，但不一定适合直接给读者看。

尤其是当内容要发到公众号、知乎、X、小红书，或者要变成数据报告、长图、PPT、海报时，Markdown 往往只是第一步。后面还要处理排版、字体、间距、截图、平台粘贴兼容等问题。

HTML Anything 的判断很直接：如果最终给人看的形态是 HTML 或图片，那就让 AI agent 直接生成最终成品，而不是让用户继续手工调样式。

它把原来的流程：

写 Markdown → 手工排版 → 调 CSS → 截图 / 粘贴平台 → 反复修格式

变成：

输入内容 → 选择模板 → 本地 agent 生成 HTML → 预览 → 复制或导出

核心功能

1. 自动识别本地 AI Agent

HTML Anything 不要求你再配置一个新的 API Key。它会扫描本机 PATH，识别已经安装并登录过的 coding-agent CLI。

支持的工具包括 Claude Code、Cursor Agent、OpenAI Codex、Gemini CLI、GitHub Copilot CLI、OpenCode、Qwen Coder 和 Aider。

只要你已经在终端里登录过这些工具，HTML Anything 就可以复用已有 session，把本地 agent 当成生成 HTML 的执行引擎。

2. 用 Skill 模板控制输出质量

项目内置了 75 套 Skill 模板，覆盖文档、PPT、海报、社交卡片、Web 原型、数据报告、Hyperframes 视频帧等场景。

这些 Skill 不是简单的主题皮肤，而是带有明确设计约束的模板。比如字体栈、8px 基线网格、颜色对比、圆角、阴影、真实数据使用等规则都会写进模板约束里，减少 AI 随意发挥带来的粗糙感。

3. 支持多种内容形态

除了普通文章，HTML Anything 更像一个“内容成品生成器”。它可以把输入转成不同交付形态：

杂志风文章
Keynote / PPT
简历
海报
小红书卡片
X / Tweet 卡片
Web 原型
数据报告
Hyperframes / Remotion 视频帧

这类模板的价值在于：同一份内容不再只是一段 Markdown，而是可以根据发布场景变成不同的视觉成品。

4. 流式生成和沙箱预览

它的生成流程走 SSE 流式返回。agent 输出的 HTML 会不断追加到前端 iframe 里，用户可以实时看到页面长出来。

整体结构可以理解为：

flowchart TD
A[用户输入 Markdown / CSV / Excel / JSON / 草稿] --> B[选择本地 Agent]
B --> C[选择 Skill 模板]
C --> D[POST /api/convert]
D --> E[本地 CLI Agent 生成 HTML]
E --> F[SSE 流式返回]
F --> G[Sandbox iframe 实时预览]
G --> H[复制到平台或导出 HTML / PNG]

预览放在 sandbox iframe 中，既能隔离生成内容，又能让用户在浏览器里直接确认最终效果。

5. 一键导出到发布平台

生成后的 HTML 可以继续导出或复制到不同平台：

微信公众号：内联 CSS 后粘贴，减少样式丢失
知乎：适配富文本和公式场景
X / 微博 / 小红书：把预览区域导出成高 DPI PNG
本地文件：下载单文件 .html 或 .png

这一步让它不只是“生成页面”，而是更接近一个面向发布的工作台。

适合谁

HTML Anything 比较适合这些人：

经常把 Markdown 文章发到公众号、知乎、社交平台的人
希望快速生成长图、海报、PPT、数据报告的内容创作者
已经在使用 Claude Code、Cursor、Codex 等本地 AI coding agent 的开发者
想把内容生产从“写完再排版”变成“直接生成可交付成品”的团队
想研究 agentic editor、AI design workflow、Skill 模板机制的开发者

快速上手

git clone https://github.com/nexu-io/html-anything
cd html-anything
pnpm install
pnpm -F @html-anything/next dev

启动后打开：

http://localhost:3000

基本使用流程：

顶栏选择本机识别到的 AI agent
选择一个 Skill 模板
粘贴 Markdown、表格、JSON、SQL 或草稿
按 ⌘ + Enter
在 iframe 中预览生成结果
复制到平台，或导出 .html / .png

结论

HTML Anything 的重点不是“又一个 HTML 编辑器”，而是把本地 AI agent、设计模板和平台导出串成了一条内容交付链路。

它适合解决一个很具体的问题：内容已经有了，但不想再花时间手工排版、截图、适配平台。

如果你本来就在用 Claude Code、Cursor、Codex 这类工具，HTML Anything 提供了一个很自然的延伸：让 agent 不只写代码，也直接生成读者最终看到的内容成品。

OpenAI 图像验证工具：给 AI 图片加上一层出处说明

Thu, 21 May 2026 17:30:38 +0800

AI 生成图片越来越像真实照片，也越来越容易被转发、截图、二次编辑。问题随之出现：当一张图片在社交平台、新闻现场或聊天群里传播时，普通人很难判断它到底来自相机、设计软件，还是某个 AI 工具。

OpenAI 这次推出的“验证 OpenAI 生成的图像”工具，解决的正是这个问题：上传一张图片，系统会检测它是否带有 OpenAI 生成图像相关的溯源特征，从而判断这张图是否可能由 ChatGPT、OpenAI API 或 Codex 等 OpenAI 工具生成。

它不是一个“识别真假新闻”的工具，也不是用来判断图片内容是否真实的工具。它更像是一张图片的“来源检测器”：告诉你这张图里有没有 OpenAI 生成内容留下的技术痕迹。

它能做什么？

这个工具的使用方式很简单：上传一张 PNG、JPG 或 WEBP 图片，系统会自动分析，并返回检测结果。

它主要检测两类特征：

C2PA 内容凭证
SynthID 数字水印

如果图片中存在这些特征，工具就可以判断它很可能来自 OpenAI 的图像生成工具。

这里的重点是“溯源”，不是“鉴定真假”。比如一张 AI 生成的“某地洪水照片”，即使工具检测到它来自 OpenAI，也只能说明这张图片由 OpenAI 工具生成，不能进一步判断图片描述的事件是否真实、地点是否准确、上下文是否被误导性使用。

换句话说，它回答的是：

这张图片是不是 OpenAI 工具生成的？

而不是：

这张图片讲的事情是不是真的？

C2PA 和 SynthID 分别是什么？

OpenAI 这个验证工具背后，主要依赖两种技术路径。

第一种是 C2PA 内容凭证。

C2PA 可以理解为一种嵌入数字内容中的来源信息。对于支持的 OpenAI 生成图片，它可以记录这张图是由 ChatGPT 或 API 等工具创建的。只要这个凭证还在，它就是很有力的来源证明。

但它也有一个限制：C2PA 依赖元数据。图片经过某些平台转发、压缩、截图、编辑后，元数据可能会被清除。一旦这些信息被去掉，工具就可能检测不到。

第二种是 SynthID 数字水印。

SynthID 是一种更“隐形”的水印技术。它不是简单地把文字或标记贴在图片角落，而是把特征嵌入到图像本身。这样即使图片被裁剪、加滤镜或有损压缩，仍然有机会保留可检测的水印信号。

简单说：

C2PA 更像图片文件里的“身份证信息”
SynthID 更像藏在图片内容里的“隐形标记”

两者结合，可以提高 AI 图片来源识别的可靠性。

检测成功意味着什么？

如果工具检测到了相关特征，说明这张图片极有可能由 OpenAI 的工具生成。

OpenAI 页面中也提到，这类检测结果非常可靠，误报很少。也就是说，如果系统明确检测到 OpenAI 的相关特征，基本可以把它视为一个强信号。

但这里仍然有边界：它不能说明这张图生成之后发生了什么。

比如：

图片是否被裁剪过
是否被重新压缩过
是否被加了文字
是否被用于错误语境
是否被人为拼接或二次编辑

这些都不是这个工具主要回答的问题。

所以，检测成功只能证明“来源倾向”，不能证明“传播语境”。

检测不到，又意味着什么？

这是最容易被误解的地方。

如果工具没有检测到任何相关特征，并不代表这张图一定不是 OpenAI 生成的。

可能原因包括：

图片元数据已经被清除
数字水印被破坏或降级
图片经过截图、压缩、编辑等处理
图片来自较早的 OpenAI 图像模型
图片生成时间早于相关溯源能力上线
图片可能由其他公司的 AI 模型生成

所以，“未检测到”只能说明：当前上传的这张图片里，没有发现该工具支持的 OpenAI 溯源特征。

它不能反推出“这张图一定不是 AI 生成”，也不能反推出“这张图一定真实”。

这一点非常重要。

为什么这个工具有意义？

现在的互联网内容环境里，AI 图片的传播速度很快，尤其在新闻事件、公共安全、社会争议和营销传播中，一张图很容易被脱离上下文使用。

内容溯源的价值在于，它可以给用户多一个判断依据。

当你看到一张图片时，如果能知道它是否由 AI 工具生成，就可以更谨慎地决定：

是否相信它
是否转发它
是否把它当作新闻证据
是否需要进一步核查来源

对于媒体、平台、研究人员、内容创作者和普通用户来说，这类工具都能降低信息误判的概率。

它不解决所有问题，但它让“图片从哪里来”这件事变得更透明。

使用时需要注意什么？

OpenAI 给出的建议是：上传单张图片进行检测。如果使用截图，最好紧贴图片边缘裁剪，避免把多张图片放在同一个文件里。

这样做是为了减少干扰，让系统更准确地检测图片中的 C2PA 元数据或 SynthID 水印。

另外，OpenAI 表示，上传的图片会被用于检测是否包含相关溯源特征。除非法律另有规定，上传图片不会被存储，也不会用于训练模型。

这个工具真正改变的是什么？

过去，我们看到一张可疑图片时，常常只能依赖肉眼判断：看光影、看手指、看文字、看细节。但 AI 图像生成能力越来越强，肉眼识别会越来越不可靠。

OpenAI 这个工具代表的是另一条路线：不再只看图片“像不像真的”，而是看它有没有可信的技术来源信息。

这比单纯的视觉识别更稳健，也更适合未来的内容生态。

当然，它仍然不是万能答案。它只覆盖 OpenAI 支持的生成图片，也不能识别所有 AI 模型生成的内容，更不能判断图片表达的信息是否真实。

但它提供了一个清晰的方向：未来的 AI 内容不应该只是“生成”，还应该能被追溯、被解释、被验证。

在 AI 内容越来越多的时代，透明度本身会变成基础设施。OpenAI 的这个图像验证工具，就是这个基础设施的一部分。

Marketing Skills for AI Agents：给 AI Agent 装上一套营销工作流

Wed, 20 May 2026 09:06:51 +0800

项目地址：https://github.com/coreyhaines31/marketingskills

一句话定位

marketingskills 是一套面向 AI 编程代理的营销技能包，让 Claude Code、OpenAI Codex、Cursor、Windsurf 等 Agent 在处理 SEO、转化率优化、文案、广告、分析和增长任务时，有更专业的工作流与判断标准。

基础信息卡片

项目	信息
项目名称	Marketing Skills for AI Agents
GitHub	`coreyhaines31/marketingskills`
作者	Corey Haines
官网	https://marketing-skills.com
许可证	MIT
主要语言	JavaScript / Shell
最新版本	v2.0.1
仓库热度	约 29.5k Stars、4.8k Forks
适配对象	Claude Code、OpenAI Codex、Cursor、Windsurf，以及支持 Agent Skills spec 的 AI Agent

解决什么问题

现在很多 AI 编程代理已经很擅长写代码，但当任务进入营销领域时，输出质量往往不稳定。

比如你让 Agent：

优化一个落地页的转化率
写一组冷邮件
做一次 SEO 审计
规划 A/B 测试
设计产品发布方案
分析用户流失和留存问题

它通常能给出一些建议，但这些建议很容易停留在通用层面：看起来合理，但缺少具体流程、检查清单和营销经验。

marketingskills 解决的正是这个问题。它把常见营销任务沉淀成一组可复用的 Agent Skills，让 AI 在遇到具体营销场景时，不只是“临场发挥”，而是能按相对专业的营销工作流执行。

核心功能

1. 覆盖完整的营销工作链路

这个项目不是单一提示词，而是一组围绕营销工作的技能库。README 中列出的技能覆盖了从获客、转化到留存的多个环节。

常见方向包括：

SEO 与内容：seo-audit、ai-seo、schema、content-strategy、programmatic-seo
转化率优化：cro、signup、onboarding、popups、paywalls
文案与内容生产：copywriting、copy-editing、cold-email、emails、social、video、image
广告与投放：ads、ad-creative
增长与留存：referrals、free-tools、churn-prevention、community-marketing
销售与 GTM：revops、sales-enablement、launch、pricing、competitors
策略与研究：customer-research、marketing-ideas、marketing-psychology

这意味着它不是只帮你“写一段营销文案”，而是能覆盖更完整的营销任务链路。

2. 以产品上下文作为基础

项目中很重要的一个设计是 product-marketing 技能。

根据 README 的说明，其他技能会先读取 product-marketing，理解产品、用户、定位和市场信息，再进入具体任务。这一点很关键。

因为营销任务很依赖上下文。不同产品的用户、使用场景、定价方式、竞争对手都不一样。如果没有统一的产品语境，AI 很容易写出“正确但没用”的内容。

product-marketing 相当于给所有后续营销任务提供一个基础档案，让 Agent 先理解“这个产品到底卖给谁、解决什么问题、为什么值得买”，再去写页面、邮件、广告或 SEO 内容。

3. 技能之间可以相互协作

marketingskills 的另一个特点是技能之间存在关联。

比如：

copywriting 可以和 cro、ab-testing 配合，用于落地页优化和实验设计
revops 可以和 sales-enablement、cold-email 配合，用于销售线索与外联流程
seo-audit 可以和 schema、ai-seo 配合，用于搜索与 AI 搜索优化
customer-research 可以为 copywriting、cro、competitors 提供输入

这种设计更接近真实营销工作：不是每个任务孤立完成，而是研究、定位、文案、渠道、数据和实验之间互相影响。

4. 支持主流 AI 编程代理

项目明确提到支持：

Claude Code
OpenAI Codex
Cursor
Windsurf
其他支持 Agent Skills spec 的代理

这让它更像一个可迁移的营销能力包，而不是绑定在某个特定 AI 产品里的提示词集合。

如果团队已经在用 AI 编程代理做开发任务，可以把这套技能加入项目，让同一个 Agent 同时承担部分增长、内容和转化优化工作。

适合谁

这个项目比较适合以下几类用户：

技术型创业者

有产品、有代码能力，但缺少系统营销经验。可以用它帮助自己完成定位、落地页、冷启动内容、SEO、冷邮件和增长实验。

独立开发者

很多独立开发者的问题不是不会做产品，而是不知道如何持续获客。marketingskills 可以把一些常见营销动作流程化，降低启动成本。

SaaS / AI 工具团队

这类产品通常需要持续做内容、转化、试用激活、留存和销售辅助材料。项目中的 CRO、SEO、onboarding、pricing、sales-enablement 等技能都很贴合。

使用 AI Agent 的技术营销团队

如果团队已经在用 Claude Code、Codex、Cursor 处理工程任务，也可以把营销任务中的重复流程交给 Agent 辅助完成，比如生成广告创意、优化页面文案、整理竞品对比页、搭建实验计划等。

快速上手

推荐使用 npx skills 安装全部技能：

npx skills add coreyhaines31/marketingskills

如果只想先试几个常用技能，可以安装指定技能：

npx skills add coreyhaines31/marketingskills --skill product-marketing cro copywriting seo-audit

也可以先查看可用技能列表：

npx skills add coreyhaines31/marketingskills --list

安装后，可以让 Agent 处理类似任务：

帮我基于当前产品定位，重写首页首屏文案。

审计这个 landing page 的转化问题，并给出优先级排序。

为这个 SaaS 产品设计一个 signup flow 的 A/B 测试方案。

基于我们的产品信息，写一组 B2B 冷邮件和 follow-up sequence。

帮我规划一套 AI SEO 内容优化方案。

结论

marketingskills 的价值不在于“又整理了一堆提示词”，而在于它把营销工作拆成了可复用、可组合、可被 AI Agent 自动调用的技能模块。

对于开发者和技术团队来说，这相当于给 AI 编程代理补上一套营销工作流。它不能替代真实的市场判断，但可以显著降低执行营销任务的起步成本：从写文案、做 SEO，到规划转化实验和产品发布，都有更清晰的流程可以遵循。

如果你已经在用 Claude Code、Codex、Cursor 或类似 Agent 做开发工作，同时又希望让 AI 帮你处理一部分增长和营销任务，marketingskills 值得加入工具箱。

Persistent Memory 不是越多越好：Agent 到底该记住什么？

Sun, 10 May 2026 11:20:00 +0800

现在很多 AI Agent 产品都在讲 memory：长期记忆、项目记忆、个人偏好、会话历史、知识库、向量检索、自动总结。

这件事很容易让人产生一个错觉：记得越多，Agent 就越聪明。

我的判断正好相反。

对真正参与工程工作的 Agent 来说，Persistent Memory 不应该是聊天记录垃圾桶，也不应该是“把所有东西都塞进向量库”。它更像一层过滤器：只留下那些稳定、可复用、能改变未来行为的上下文。

否则，memory 会从助力变成噪音。Agent 会拿过期信息当事实，把一次性偏好当永久规则，把未验证猜测当项目结论，甚至把不该保存的敏感内容带到下一次任务里。

先说结论

Agent 最应该记住的，不是“发生过什么”，而是这些信息：

未来大概率还会用到；
短期内不会快速过期；
能减少重复解释；
能改变 Agent 的默认行为；
有来源、有边界、必要时能重新验证。

反过来，下面这些东西不应该直接变成长期记忆：

密钥、密码、token、cookie、恢复码；
某次任务里的临时分支状态；
价格、排期、版本、政策这类会变化的信息；
没有证据的猜测；
原始聊天记录和大段私人上下文；
一次性的情绪、口头偏好或临时指令。

一句话：memory 是索引，不是档案馆；是工作规则，不是原始日志。

为什么“记得越多”会出问题

普通聊天助手记住你的称呼、语言偏好、写作风格，通常问题不大。但工程 Agent 不一样。它会读代码、改文件、跑命令、接 MCP、调用浏览器、访问内部系统，甚至参与发布流程。

一旦 memory 质量不好，风险会被放大。

比如：

它记住“这个项目用 pnpm”，但项目后来迁移到了 bun；
它记住“release 分支可以直接部署”，但后来发布规则变成必须和 origin/release 完全一致；
它记住“某个接口返回字段叫 groupName”，但真实 source-of-truth 已经变成 displayName；
它记住“用户不需要测试”，然后在更高风险的后端改动里也跳过测试；
它记住某次排障里的临时 SQL，把它当成通用诊断入口。

这些都不是模型能力问题，而是 memory 生命周期问题。

OpenAI 在 ChatGPT memory 文档里把记忆分成 saved memories 和 reference chat history 两类，并强调用户可以管理、删除或关闭记忆能力。这个产品设计背后的重点不是“无限保存”，而是“可控制”。Claude Code 的 memory 设计也把用户级、项目级、目录级记忆拆开，让 CLAUDE.md 这类文件承担不同范围的上下文。

工程 Agent 的 memory 也应该这样分层，而不是把所有上下文混在一起。

三种上下文，不要混用

我更倾向于把 Agent 上下文分成三类。

1. 当前任务上下文

这是最短命的上下文。

比如：

当前用户刚说的需求；
当前工作树的 diff；
当前终端输出；
当前浏览器页面状态；
本轮排障看到的错误日志；
当前计划和待办列表。

这些信息对当前任务很重要，但大多不应该进入长期 memory。任务结束后，它们要么被代码、文档、issue、commit 记录接管，要么就应该自然消失。

如果把当前任务上下文都存进 memory，下一次任务会被旧现场污染。

2. 项目 source-of-truth

这是应该优先相信的上下文。

比如：

AGENTS.md / CLAUDE.md；
README.md；
Makefile；
CI 配置；
schema / migration；
package catalog；
API 类型定义；
测试用例；
项目内设计文档。

这些东西不一定叫 memory，但对 Agent 来说，它们就是最重要的可验证记忆。

如果某条 memory 和代码仓库里的 source-of-truth 冲突，应该以仓库为准。memory 只能提示“可能去哪里看”，不能替代真实文件。

3. 长期工作记忆

这才是 Persistent Memory 应该承担的部分。

它记录的是跨任务稳定成立、但不一定已经写进项目文件的协作知识。

比如：

用户默认使用中文；
某个仓库新增文章要同时生成 .en.md；
public 目录经常是脏的，文章验证应避免直接构建进去；
用户明确要求某类 UI 改动不能碰无关界面；
某个部署脚本必须保留 linux/amd64，因为本机是 mac arm；
某类排障要先查日志，不要先猜修复方案。

这些记忆的价值是减少重复沟通，让 Agent 在下一次任务里更快进入正确边界。

Agent 到底该记住什么？

我会用下面这张表来判断。

应该记住	例子	原因
稳定偏好	默认中文、回答简洁、先给结论	会持续改变协作方式
项目惯例	新文章放 `content/article/`，英文版用同 slug `.en.md`	能减少重复探索
硬约束	不改后端接口、不碰无关 UI、不要写入 `public`	违反会造成真实风险
反复出现的故障模式	某类安装报错来自缓存权限，某类部署慢要看 workflow	能加速排障
已确认的业务规则	协作者只能加减分，不能改学生数据	能避免产品规则回退
用户认可的方向	某个 UI 展示方案已被认可，后续应基于它迭代	能保持连续性
可复用工作流	发文后用 `hugo --renderToMemory --minify` 验证	能提高交付稳定性

这些信息有一个共同点：它们不是“历史细节”，而是“未来默认动作”。

一条好的 memory 应该能回答这个问题：

下一次遇到相似任务时，Agent 的行为会不会因此变得更正确？

如果答案是否定的，就不要存。

什么应该重新验证？

有些信息可以作为线索，但不能作为事实。

例如：

最新 API 用法；
当前价格和套餐；
GitHub Actions 当前状态；
远端分支是否已经更新；
某个模型是否仍然可用；
某个法规、政策、平台规则；
当前日期、排期、发布节奏；
线上服务是否正常。

这些信息即使曾经正确，也很容易过期。

所以 memory 里最多只能写：

上次排障时，问题出现在 release workflow 的镜像构建阶段。
下次遇到类似发布慢问题，先检查当前 workflow 和最近一次 Actions 日志。

而不是写：

发布慢就是因为镜像构建。

前者是可复用诊断线索，后者是过期风险很高的结论。

什么绝对不该存？

长期 memory 最危险的不是“不够聪明”，而是“记住了不该记的东西”。

我会把下面几类列入禁止区：

1. secrets 和凭据

包括：

API key；
token；
cookie；
SSH 私钥；
数据库密码；
支付后台密钥；
恢复码；
临时验证码。

这些信息不应该进 memory，也不应该进文章、日志、截图、issue。

2. 原始私人内容

不要把大量聊天原文、邮箱内容、客户资料、订单详情、学生信息、病历、财务记录直接写进 memory。

如果确实需要保留工作上下文，也应该压缩成非敏感规则，例如：

用户处理教育类 SaaS 项目时，很在意老师协作权限和家长端展示边界。

而不是保存某个具体学生、家长或订单的原始信息。

3. 未验证猜测

Agent 很容易在排障中形成假设。假设可以存在当前会话里，但不应该沉淀成长期记忆。

只有经过代码、日志、测试、线上验证支撑的结论，才有资格进入 memory。

4. 一次性临时状态

比如：

当前正在某个临时分支；
某个端口今天被占用；
某个文件刚才被生成；
某个任务这次不需要测试；
某个页面现在打开在 Chrome 第三个标签页。

这些信息应该留在当前任务上下文里，不应该污染长期记忆。

一个简单的保存判断法

我会让每条 memory 通过 5 个问题：

下次还会用吗？
一个月后大概率还成立吗？
能改变 Agent 的默认行为吗？
是否能追溯来源或重新验证？
如果记错了，会不会造成风险？

只有前四个答案偏“是”，第五个风险可控，才值得保存。

如果一条信息很有用但容易过期，就不要写成事实，写成“下次优先检查哪里”。

如果一条信息风险很高，就不要写进 memory，应该写进项目权限、CI guard、测试、文档或人工审批流程。

Memory 应该怎么写？

好的 memory 应该短、稳定、可执行。

不好的写法：

用户上次让我们改文章，后来 public 脏了，然后用了 hugo 命令，最后好像可以。

好的写法：

在 silenceper.com 新增文章时，文章真源是 content/article/；英文版使用同 slug 加 .en.md；验证优先用 hugo --renderToMemory --minify，避免写入 public。

差异在于：

去掉了过程噪音；
保留了未来动作；
标明了适用仓库；
给出了具体路径和命令；
没有把临时现场当事实。

不同信息应该放在哪里？

不是所有长期信息都应该放进同一个 memory 系统。

信息类型	更适合的位置
项目硬规则	`AGENTS.md` / `CLAUDE.md`
构建和发布命令	`README.md` / `Makefile` / CI
业务规则	代码、测试、产品文档
用户个人偏好	用户级 memory
仓库协作惯例	项目级 memory
可复用操作流程	Skill / runbook
当前任务现场	当前会话 / issue / PR 描述
可变化事实	每次重新查源

一个成熟的 Agent 工作流，不应该把 memory 当唯一入口。

更好的结构是：

memory 负责提示方向
repo 文件负责定义规则
测试负责防止回退
日志负责还原现场
人工审批负责高风险动作

这样 Agent 即使记忆不完整，也能通过 source-of-truth 找回正确上下文。

Persistent Memory 的真正价值

Persistent Memory 最有价值的地方，不是让 Agent 像人一样“什么都记得”。

它的价值是让 Agent 少犯重复错误。

比如：

不再每次都问“这个项目用中文还是英文”；
不再把已确认的业务规则推翻；
不再重复踩同一个部署坑；
不再把用户明确拒绝的 UI 方案又拿出来；
不再在脏工作树里误改无关文件；
不再把需要查代码的套餐信息凭印象回答。

这些看起来都不是宏大的 AGI 能力，但对真实工作非常重要。

工程效率的提升，往往不是来自 Agent 记住了更多碎片，而是来自它记住了更少、更准、更能约束行为的东西。

我的建议

如果你在重度使用 Codex、Claude Code、Cursor 或其他编程 Agent，可以按这个原则管理 memory：

把 memory 当索引，不当真源。
把稳定规则写进项目文件。
把可变化事实留给实时搜索和源码检查。
把敏感内容挡在 memory 外面。
把每条 memory 写成未来行为，而不是历史流水账。
定期清理过期、重复、含糊的记忆。

最终目标不是让 Agent 记住一切，而是让它在下一次工作时更少打扰你、更少跑偏、更少踩坑。

当 memory 变成一套可维护的工程资产，而不是聊天记录堆积物，Agent 才真正开始像一个可靠的长期协作者。

参考资料

Codex Chrome 插件：什么时候该让 AI 使用你的浏览器登录态

Sat, 09 May 2026 22:15:00 +0800

很多人第一次看到 Codex Chrome 插件，会把它理解成“让 AI 打开网页”。这个说法太窄，也容易让人误解。

更准确地说，它解决的是另一类问题：当任务必须依赖你的 Chrome 登录态、浏览器上下文或真实网页操作时，让 Codex 在你授权的范围内进入这条工作流。

比如：

你要让 Codex 读取登录后才能看到的 CRM、邮箱、后台系统；
你要在真实业务页面里复现一个 bug；
你要让它根据页面状态回到代码仓库里修复问题；
你要上传一个本地文件到网页表单，再核对页面结果；
你要处理没有 API、只有网页操作入口的内部系统。

这些任务过去通常只能靠人手动完成，AI 最多在旁边给步骤建议。Chrome 插件补上的，就是“真实浏览器环境”这一段。

先说结论

Codex Chrome 插件不是普通网页摘要插件，也不是一个独立聊天机器人。它是 Codex App 的浏览器能力扩展。

我的使用判断很简单：

本地开发预览、公开网页、无需登录的页面，优先用 Codex 的 in-app browser；
某个系统有专门插件或结构化集成时，优先用对应插件；
只有任务必须依赖 Chrome 登录态、浏览器 profile、cookies 或真实网页操作时，再使用 Chrome 插件；
涉及付款、转账、删除生产数据、安全设置、导出敏感信息时，让 Codex 准备和核对，不要让它直接提交关键动作。

也就是说，它的价值不是“更方便地打开网页”，而是让 Codex 可以参与完整验证链路：看页面、操作后台、复现问题、回到代码里修复，再继续验证。

基础信息

项目	信息
名称	Codex Chrome extension
官方文档	https://developers.openai.com/codex/app/chrome-extension
所属产品	Codex App
核心定位	让 Codex 使用 Chrome 处理需要登录态的浏览器任务
典型场景	Gmail、Salesforce、LinkedIn、CRM、内部系统、需要账号登录的网页流程
推荐搭配	Codex App、Plugins、In-app Browser、Computer Use
权限模型	新站点默认请求确认；支持 allowlist / blocklist
安全重点	页面内容按不可信上下文处理，敏感操作需要人工确认

它解决的真实边界

很多 AI 编程工具都能读代码、改文件、跑命令，但一进入真实网页环境，就会遇到新的边界：

页面需要登录；
数据只存在浏览器会话里；
内部系统没有稳定 API；
复现问题必须点击真实页面；
本地开发页面和线上后台之间要来回验证；
有些任务需要复制、上传、下载、截图或核对页面状态。

没有 Chrome 插件时，Codex 可以告诉你“下一步点哪里”，但它自己无法在你的登录态页面里继续推进。接入 Chrome 后，它可以在你确认的网站里完成更长的任务链路。

一个典型流程可能是这样：

@Chrome 打开后台的订单详情页，核对这个用户的订阅状态。
如果页面显示异常，回到仓库里检查对应接口和前端展示逻辑。
修复后再用浏览器验证页面是否恢复正常。

这类任务的重点不是浏览器自动化本身，而是 Codex 能把“网页证据”和“代码修改”放进同一个工作线程里。

和 in-app browser 怎么分工

官方文档里把边界说得很清楚：本地开发服务器、文件预览、公开页面、无需登录的页面，优先用 in-app browser。这样可以把预览和验证留在 Codex 内部，不必动用你的 Chrome profile。

Chrome 插件更适合这些场景：

页面必须依赖你的 Chrome 登录态；
任务需要访问真实账号下的数据；
需要浏览器 profile、cookies 或扩展环境；
本地预览工具无法完成登录、权限或业务状态验证；
目标系统没有可用 API，只能通过网页操作。

我的建议是：能不用真实登录态，就不用真实登录态；必须用时，再把权限收窄到当前任务。

核心能力

1. 连接 Chrome，使用真实登录态

安装和连接完成后，Chrome 工具栏里的 Codex 扩展会显示 Connected。之后你可以在新的 Codex 线程里直接指定 Chrome 任务，例如：

@Chrome open Salesforce and update the account from these call notes.

这里真正重要的是：Codex 使用的是你的 Chrome 环境，而不是一个无登录态的临时浏览器。因此它可以处理 Gmail、Salesforce、LinkedIn、CRM、内部后台这类必须登录后才能访问的页面。

2. 新网站默认需要确认

Codex Chrome 插件默认不会无差别使用所有网站。它在访问每个新网站前会询问，通常按 host 维度确认，例如 example.com。

你可以根据任务风险选择：

只允许当前聊天使用这个网站；
将该 host 加入长期允许列表；
拒绝访问这个网站。

这个设计很关键。因为登录态浏览器里可能有邮箱、后台、财务系统、内部工具和个人账号，不能把“能访问”直接等同于“应该访问”。

3. 支持 allowlist / blocklist

官方文档提到，可以在 Computer Use 设置里管理域名 allowlist 和 blocklist：

allowlist：Codex 可以再次使用这些域名，不需要每次重复确认；
blocklist：Codex 不应该使用这些域名；
从 allowlist 移除后，下次会重新询问；
从 blocklist 移除后，Codex 可以重新发起请求，而不是继续视为禁止。

高频、低风险、任务边界清楚的网站，可以考虑放进 allowlist。邮箱、金融、账号安全、生产后台这类页面，我更倾向于临时授权或保持人工确认。

4. 文件上传需要额外开启 file URL 权限

如果 Chrome 任务需要上传本机文件，官方文档要求在 Chrome 扩展详情里开启 Allow access to file URLs。

路径大致是：

Chrome toolbar → Extensions → Manage Extensions → Codex → Details → Allow access to file URLs

这类权限建议按需开启。因为一旦涉及本地文件，任务边界就从“网页操作”扩展到了“本机文件 + 网页上传”。明确需要上传时再开，用完后重新评估是否保留。

使用时最应该注意什么

把网页内容当成不可信上下文

官方文档明确提醒：页面内容应该被视为 untrusted context。

原因很直接：网页里可能包含误导性文本、隐藏指令或恶意内容。如果 Codex 把网页内容当成用户指令，就可能发生越权操作或数据外发。

所以使用 Chrome 插件时，我建议保持几个习惯：

不要让 Codex 访问和任务无关的敏感页面；
首次访问某个站点时认真看确认弹窗；
对邮箱、财务、账号、安全设置类页面保持人工复核；
不要把密码、密钥、恢复码等敏感信息交给浏览器任务；
复杂任务拆小，每一步都能看清楚结果。

谨慎开启 Always allow browser content

官方把 “Always allow browser content” 标成 Elevated Risk。开启后，Codex 使用网站时不再每次确认。

这对高频低风险站点可能方便，但对真实账号环境来说风险会明显上升。我的建议是：默认不要全局开启。除非你非常确定站点不敏感、任务边界稳定，并且你能接受它被长期授权。

浏览器历史不是普通上下文

浏览器历史可能包含内部 URL、搜索词、业务系统路径、账号活动记录等信息。官方文档也说明，Codex 在需要浏览器历史时会单独询问，而且浏览器历史没有 always-allow 选项。

这个设计是合理的。历史记录不是普通辅助信息，它可能暴露你的工作习惯、内部系统结构甚至业务线索。除非任务确实需要，否则不建议授权。

适合哪些任务

Codex Chrome 插件比较适合：

在 CRM / 后台系统里按说明更新资料；
读取登录后才能访问的业务页面，并结合代码修改；
在真实网页里复现 bug；
验证需要账号态的功能流程；
处理内部工具、低代码后台、工单系统这类没有稳定 API 的任务；
根据页面结果回到代码仓库里继续修复问题；
上传文件、核对页面状态、下载结果并继续处理。

不太适合一上来就交给它的动作包括：付款、转账、删除生产数据、修改安全设置、导出大量个人信息。即使工具能做，也应该把这些动作留给人工确认。

快速上手

按照官方文档，基本流程是：

1. 打开 Codex App
2. 进入 Plugins
3. 添加 Chrome plugin
4. 按引导安装或连接 Chrome 扩展
5. 接受 Chrome 权限提示
6. 在 Chrome 工具栏确认 Codex 扩展显示 Connected
7. 新开一个 Codex thread
8. 在提示词里用 @Chrome 指定浏览器任务

如果连接异常，可以先检查：

Chrome 扩展是否显示 Connected；
Codex App 里的 Chrome plugin 是否开启；
当前是否使用安装了扩展的 Chrome profile；
目标网站是否在 blocklist；
是否需要重启 Chrome / Codex；
上传本地文件时，是否开启了 Allow access to file URLs。

我的使用建议

如果你把 Codex 当成工程协作者，而不是单纯聊天机器人，Chrome 插件会很有用。它让 Codex 不只停留在代码仓库里，还能进入真实页面完成验证闭环。

但越接近真实账号和真实业务系统，越要收紧权限。

我会按这个顺序使用：

公开页面、本地页面：先用 in-app browser；
结构化系统：优先用专门插件或 API；
必须登录态：再用 Chrome 插件；
高风险动作：只让 Codex 准备、检查、解释，由人最终确认。

这样用，Chrome 插件不是“把浏览器交给 AI”，而是把一段过去必须人工完成的验证流程，变成可控、可复核、能回到代码里的协作流程。

Warp：把 AI Agent、终端和代码审查合在一起的智能开发工作台

Sat, 09 May 2026 21:47:00 +0800

一句话定位：
Warp 是一个从终端演进而来的 AI 原生开发环境，把命令行、编码 Agent、Git Diff、代码审查和提交工作流整合在同一个界面里。

基础信息卡片

项目	信息
项目名称	Warp
GitHub	https://github.com/warpdotdev/warp
官网	https://warp.dev
项目定位	从终端演进而来的 AI 原生开发环境
主要语言	Rust
Stars / Forks	约 57k Stars / 4.3k Forks
开源协议	主要为 AGPL-3.0；`warpui_core` / `warpui` 使用 MIT
核心能力	AI Coding Agent、终端工作区、Git Diff 审查、Agent 开源协作流程
快速开始	官网下载安装；开发者可参考 `./script/bootstrap`、`./script/run` 本地构建

它解决什么问题？

传统终端很强，但开发流程往往分散在多个工具里：
写命令在终端，改代码在编辑器，看 Diff 在 Git 工具，评审在 PR 页面，AI 编程助手又是另一个窗口。

Warp 的思路是：把这些开发动作收拢到一个 AI 原生工作区里。
你可以让 Agent 执行任务、生成代码变更、跑测试，同时直接查看 Git Diff、添加评论、准备提交。

核心功能亮点

1. 内置 AI Coding Agent

Warp 不只是终端，而是内置了编码 Agent。
你可以把一个开发任务交给它，例如实现功能、修改代码、运行检查、生成 Diff。

README 中也提到，Warp 支持使用内置 coding agent，也可以接入 Claude Code、Codex、Gemini CLI 等外部 CLI Agent。

2. 终端 + Agent + Git Diff 一体化

截图中可以看到：

左侧是 Agent 执行任务的过程
右侧是代码 Diff 审查界面
可以查看未提交变更
可以逐行审阅代码
可以添加评论
可以直接进入提交流程

这让 Warp 更像一个“开发工作台”，而不是单纯的命令行窗口。

3. 面向开源协作的 Agent 工作流

Warp 提供了 build.warp.dev，用于观察 Oz agents 如何参与开源项目流程，包括：

triage issues
编写 spec
实现变更
审查 PR
查看活跃 agent session

这说明 Warp 不只是个人效率工具，也在探索 Agent 参与开源协作的流程。

4. 开源客户端代码

Warp 的客户端代码已经开源，并提供贡献指南。
本地构建流程大致是：

./script/bootstrap
./script/run
./script/presubmit

适合想研究现代终端、AI Agent 工作流、Rust 桌面应用架构的开发者深入看看。

适合谁？

Warp 比较适合：

高频使用终端的开发者
希望把 AI 编程助手融入日常开发流程的人
想在一个界面里完成命令执行、代码变更、Diff 审查和提交的人
关注 AI Agent 如何参与开源维护、Issue 处理和 PR 工作流的团队
Rust / 桌面开发 / 开发者工具方向的研究者

快速上手

普通用户可以直接下载安装：

https://www.warp.dev/download

开发者想研究源码，可以从 GitHub 开始：

https://github.com/warpdotdev/warp

本地构建参考：

./script/bootstrap
./script/run
./script/presubmit

结论

Warp 的吸引点在于：它不是给终端简单加一个 AI 聊天框，而是把 AI Agent 真正放进开发流程里。
从任务执行、代码修改、Diff 审查到提交，Warp 试图把开发者每天反复切换的工具链整合成一个 AI 原生工作区。对于习惯终端、又想系统性使用 AI 编程工具的开发者来说，这是一个非常值得关注的项目。

DeepSeek TUI：把 DeepSeek V4 变成终端里的本地编程 Agent

Fri, 08 May 2026 17:20:00 +0800

一句话定位

DeepSeek TUI 是一个面向 DeepSeek V4 的终端原生编程 Agent：它把模型推理、文件编辑、命令执行、Git、MCP、子智能体、LSP 诊断和成本追踪都放进一个键盘驱动的 TUI 工作流里。

如果说很多 AI 编程工具是在编辑器里“补代码”，DeepSeek TUI 更像是在终端里启动一个会读项目、会改文件、会跑命令、会看诊断、还能控制权限和成本的本地协作环境。

基础信息卡片

项目	信息
项目名称	DeepSeek TUI
GitHub	https://github.com/Hmbown/DeepSeek-TUI
项目定位	Terminal coding agent for DeepSeek models
主要语言	Rust
License	MIT
适配模型	DeepSeek V4，包含 `deepseek-v4-pro` / `deepseek-v4-flash`
安装方式	npm、Cargo、Homebrew、Release 二进制、Docker
支持平台	Linux x64/ARM64、macOS x64/ARM64、Windows x64

解决什么问题

AI 编程工具现在很多，但不少工具有一个共同问题：要么偏聊天，要么偏编辑器补全，要么把自动化能力藏得很深。

DeepSeek TUI 解决的是另一类需求：

你习惯在终端里工作；
你希望 AI 能直接理解当前工作区；
你希望它不仅能回答，还能读文件、改文件、跑命令、管理 Git；
你又不希望它无边界地乱动项目；
你还想看清楚模型在用什么上下文、花了多少 token、是否命中前缀缓存。

所以它不是一个简单的“DeepSeek 聊天终端”，而是一个围绕真实代码工作流设计的 TUI Agent。

核心特点

1. 为 DeepSeek V4 做了原生适配

DeepSeek TUI 的第一大特点，是它不是泛泛接一个 OpenAI-compatible 接口就结束，而是围绕 DeepSeek V4 的能力做了细化设计。

它支持：

deepseek-v4-pro / deepseek-v4-flash；
100 万 token 上下文；
思考模式流式输出；
前缀缓存感知的成本统计；
根据任务自动选择模型和 thinking level 的 Auto mode。

这意味着它更适合拿来跑长上下文任务：读大项目、跨文件排查问题、做架构梳理、分批分析代码，而不是只处理单个函数级别的小问答。

2. Auto mode：模型和思考强度都可以自动选

项目里比较有辨识度的设计是 Auto mode。

使用：

deepseek --model auto

或者在 TUI 里：

/model auto

Auto mode 会在每轮真正执行前，先做一次轻量路由判断，再为当前任务选择：

使用 deepseek-v4-flash 还是 deepseek-v4-pro；
thinking 使用 off、high 还是 max。

简单问题可以走 Flash + thinking off；复杂的调试、架构、安全审查、发布任务，则可以升级到更强模型或更高思考强度。

这个设计很实用，因为真实开发任务不是每一轮都值得用最高成本配置。让工具按任务选择档位，比用户手动频繁切模型更自然。

3. 终端里完整跑一个编程 Agent 工作流

DeepSeek TUI 的工具集覆盖得比较完整：

文件读写；
shell 命令执行；
Git 操作；
网页搜索和浏览；
apply-patch；
子智能体；
MCP Server；
RLM 批量分析；
HTTP/SSE runtime API。

官方架构里，它的链路大致是：

deepseek 调度器 CLI
→ deepseek-tui 伴随二进制
→ ratatui 终端界面
→ 异步 Agent Engine
→ OpenAI-compatible streaming client
→ 工具注册表和运行结果回流

也就是说，它不是只把模型输出显示在终端里，而是有一套完整的工具调用、会话状态、任务队列和诊断反馈机制。

4. 三种模式：Plan、Agent、YOLO，把权限边界摆在明面上

很多 Agent 工具容易让用户困惑：它到底会不会改文件？会不会直接跑命令？会不会做危险操作？

DeepSeek TUI 把交互模式分成三类：

模式	适合场景
Plan	只读探索，先理解项目和方案
Agent	默认交互模式，关键操作需要审批
YOLO	可信工作区自动批准，更适合隔离环境或高熟练用户

这个分层对日常使用很重要。新项目、新需求、新仓库，先用 Plan 让它读懂；方向确认后再进 Agent；只有非常明确、可回滚、环境隔离时才考虑 YOLO。

5. side-git 工作区回滚：不污染项目自己的 Git

DeepSeek TUI 还有一个很实用的安全设计：工作区回滚。

它通过 side-git 记录每轮操作前后的快照，支持：

/restore

以及 revert_turn 这类按轮次回滚能力。

关键点是：它不依赖也不污染你项目自己的 .git。这对 AI 编程特别有用，因为 AI Agent 往往会连续做多轮修改，如果中间某一步方向错了，用户需要一个比手动 git checkout 更贴近“会话轮次”的回滚方式。

6. LSP 诊断会回流到下一轮推理

另一个值得突出的是 LSP diagnostics。

项目支持在每次编辑后，通过这些语言服务拿到错误和警告：

rust-analyzer；
pyright；
typescript-language-server；
gopls；
clangd。

这些诊断不会只是展示给用户看，而是会反馈进下一轮模型上下文。也就是说，Agent 改完代码后，可以更快知道“哪里红了”“类型哪里不对”“下一步该修哪里”。

这让它比单纯的文本编辑型 Agent 更接近真实开发环境。

7. 成本追踪和前缀缓存感知

DeepSeek TUI 不是只告诉你模型回答了什么，也会追踪：

每轮 token 用量；
会话级 token 用量；
成本估算；
cache hit / miss；
前缀缓存相关信息。

对长上下文 Agent 来说，这个功能非常关键。因为真正跑项目时，成本不只来自“这次问了什么”，还来自历史上下文、文件内容、工具结果和反复推理。

如果你经常把 AI 用在大仓库里，能看见成本结构本身就是一种控制能力。

8. 本地二进制分发，不把运行时绑死在 Node 或 Python 上

DeepSeek TUI 使用 Rust 编写，发布的是自包含二进制。

虽然可以通过 npm 安装：

npm install -g deepseek-tui

但 npm 包更像下载器，会拉取对应平台的预编译 Rust 二进制。项目本身也支持：

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

以及 Homebrew、Release 二进制和 Docker。

这种分发方式对终端工具很友好：安装入口多，但运行时尽量简单。

9. 中国大陆和 ARM64 场景考虑得比较细

README 里专门写了中国大陆镜像安装方式，也说明了 Linux ARM64 的预构建支持。

比如 npm 可以使用：

npm install -g deepseek-tui --registry=https://registry.npmmirror.com

Cargo 可以配置清华镜像源。

这类细节看起来不是核心功能，但会直接影响工具能不能顺利装上。尤其是国内网络环境、树莓派、Graviton、国产 ARM 设备、HarmonyOS PC 这类环境，安装体验往往比功能介绍更先决定用户是否继续尝试。

适合谁

DeepSeek TUI 比较适合这些人：

已经在用 DeepSeek API，希望有一个终端里的编程 Agent；
喜欢 TUI、键盘驱动、命令行工作流；
经常处理大仓库、长上下文、多文件任务；
希望 AI 能跑命令、改文件，但仍然保留审批和回滚；
想把 MCP、子智能体、LSP 诊断、任务队列接进本地开发流程；
希望对 token 和成本有更细粒度感知。

如果你已经熟悉 Codex CLI、Claude Code、Gemini CLI 这类终端 Agent，DeepSeek TUI 的价值在于：它把 DeepSeek V4 的上下文、推理、缓存和成本能力做成了更贴近本地开发的终端体验。

快速上手

最简单的安装方式：

npm install -g deepseek-tui

检查版本：

deepseek --version

首次启动：

deepseek

也可以提前配置 API Key：

deepseek auth set --provider deepseek

检查配置状态：

deepseek auth status

验证安装：

deepseek doctor

推荐第一次使用时，不要直接 YOLO。可以先从自动模型选择开始：

deepseek --model auto

然后让它先读项目、给计划：

先阅读这个项目的目录结构，说明主要模块和启动方式，不要修改文件。

确认理解正确后，再让它进入具体实现或修复任务。

结论

DeepSeek TUI 最值得关注的地方，不是“它又做了一个终端聊天界面”，而是它把 DeepSeek V4 的能力包装成了一套比较完整的本地 Agent 工作流。

它的特点很明确：

面向 DeepSeek V4 深度适配；
终端原生 TUI；
Auto mode 自动选择模型和思考强度；
Plan / Agent / YOLO 三种权限模式；
side-git 回滚；
LSP 诊断回流；
MCP、子智能体、RLM、HTTP/SSE API；
成本和前缀缓存可见。

如果你想找一个“更懂 DeepSeek、更贴近终端开发、更强调可控性”的编程 Agent，DeepSeek TUI 值得试一下。

Codex 指令速查：从会用到用顺手

Fri, 08 May 2026 14:20:00 +0800

这篇是写给已经装好 Codex CLI、但还停留在“打开终端跟它聊天”的使用者。Codex 真正好用的地方，不只是让它改代码，而是把一次性提问、持续会话、自动化脚本、代码审查、上下文管理这些动作拆成一组清晰的指令。

很多人第一次用 Codex，会把它当成一个终端里的 ChatGPT：输入需求，等它回答。这样当然也能用，但很容易遇到两个问题：

不知道什么时候该让它直接改代码，什么时候只让它分析。
每次都重新解释项目背景、权限边界和任务目标，效率不高。

更好的方式，是先把 Codex 的指令分成几类来理解：

启动和登录
交互式会话
非交互式执行
审查和应用变更
会话恢复与分支
权限、沙箱和配置
MCP、插件和扩展能力

下面按实际使用频率来讲。

1. 安装与登录：先让 Codex 能正常工作

Codex CLI 可以用 npm 或 Homebrew 安装：

npm install -g @openai/codex
# 或
brew install --cask codex

安装后直接运行：

codex

第一次使用时，通常会进入登录流程。你可以使用 ChatGPT 账号登录，也可以使用 API Key：

codex login

如果你想用 API Key，可以把 key 从标准输入传给 Codex：

printenv OPENAI_API_KEY | codex login --with-api-key

检查当前登录状态：

codex login status

如果要清除登录信息：

codex logout

这组命令解决的是“能不能用”的问题。只要登录状态正常，后面的指令才有意义。

2. `codex`：最常用的交互式入口

最简单的入口就是：

codex

它会打开一个交互式会话。你可以在里面描述需求，比如：

帮我看一下这个项目的启动流程，并指出最容易出错的三个地方。

也可以启动时直接带上 prompt：

codex "阅读这个仓库，给我一份模块结构说明"

如果要指定工作目录，用 -C：

codex -C /path/to/project "帮我分析这个项目的测试结构"

常见选项还有：

codex -m gpt-5.5 "帮我重构这个函数"

codex --search "帮我根据最新文档检查这个 SDK 的用法是否过时"

codex -s workspace-write "实现这个功能，但只允许修改当前工作区文件"

我的建议是：

想边看边改，用 codex。
想一次性跑完任务，用后面讲的 codex exec。
不确定任务范围时，先让它分析和计划，不要一上来就给全权限。

3. 交互式会话里的斜杠指令

进入 codex 之后，可以用 / 查看可用的斜杠指令。这些指令更像“会话控制面板”，不是普通聊天内容。

`/model`：切换模型

/model

用于查看或切换当前会话使用的模型。

如果你发现一个任务需要更强推理能力，可以切到更强的模型；如果只是改一点文案或做轻量分析，也可以切到更快的模型。

`/fast`：切换快速模式

/fast on
/fast off
/fast status

适合在“小修小补、快速问答、简单代码定位”场景里使用。复杂重构、跨模块分析、线上故障排查这类任务，不建议盲目追求快。

`/plan`：先要计划，不急着改

/plan

或者：

/plan 给这个服务设计一个迁移方案，要求兼容旧接口

这是我认为非常实用的指令。很多时候你并不是要 Codex 马上动手，而是要它先把风险、步骤、影响范围讲清楚。

适合用 /plan 的场景：

重构核心模块
数据库字段调整
API 行为变化
前端页面大改
发布流程改造

一个好习惯是：先 /plan，确认方向后再让 Codex 实现。

`/review`：让 Codex 做代码审查

/review

适合在提交前检查当前改动。它会把注意力放在潜在 bug、边界条件、回归风险上。

如果你希望 Codex 不只是“帮你写”，还要“帮你挡问题”，这个指令应该经常用。

`/diff`：查看本轮改了什么

/diff

当 Codex 改了一堆文件后，先别急着提交。用 /diff 看一下变更范围，确认它没有顺手改掉不该改的东西。

尤其是以下情况要多看 diff：

它修改了配置文件
它改了测试快照
它动了锁文件
它同时改了前端、后端、脚本

`/status`：查看当前会话状态

/status

这个指令用来确认当前模型、权限、工作区、配置等状态。排查“为什么它不能写文件”“为什么它没有联网搜索”“为什么当前目录不对”时很有用。

`/permissions`：调整权限

/permissions

Codex 的能力强不强，不只看模型，也看你给它什么权限。

权限相关指令适合用来回答这些问题：

能不能写当前工作区？
能不能运行命令？
是否需要每次确认？
有没有额外可读目录？

如果你在一个重要仓库里工作，建议保持权限克制：先读、再计划、最后再开放写入。

`/sandbox-add-read-dir`：增加只读上下文目录

/sandbox-add-read-dir /path/to/another/repo

有些任务需要参考另一个仓库，但不希望 Codex 改它。这个时候可以把它作为只读目录加进来。

典型场景：

主项目要参考旧项目实现
后端要参考前端类型定义
新服务要参考老服务 API
写文档时要参考另一个资料目录

`/mcp`：查看 MCP 工具

/mcp

如果你给 Codex 配了 MCP Server，比如数据库、浏览器、内部工具、GitHub、Linear 等，就可以通过这个指令查看当前可用工具。

MCP 的价值是让 Codex 不只会读代码，还能接触外部系统。但这也意味着权限边界更重要：能查什么、能不能写、能不能执行危险操作，都要提前想清楚。

`/init`：生成项目规则

/init

通常会用于初始化项目规则文件，比如 AGENTS.md。这个文件可以写项目约定：

代码风格
测试命令
分支规则
目录说明
禁止修改的路径
发布前检查项

如果你在一个长期项目里使用 Codex，AGENTS.md 很重要。它能减少你每次重复解释项目规则的成本。

`/compact`：压缩上下文

/compact

长会话里，上下文会越来越多。/compact 可以把前面的对话压缩成更短的摘要，保留主要任务状态。

适合在这些时候使用：

一个任务已经跑了很久
中间查了很多资料
已经完成前半段，准备进入实现阶段
你发现 Codex 开始忘记早期约束

`/clear`、`/new`、`/quit`

/clear
/new
/quit

这几个用于清理或结束会话：

/clear：清空当前会话上下文
/new：开始新会话
/quit 或 /exit：退出 Codex

不要把完全无关的任务一直塞在同一个会话里。一个会话最好只围绕一个明确目标。

4. `codex exec`：把 Codex 当成脚本工具

codex exec 是非交互式模式。它适合自动化、批处理、CI 辅助、日志分析等场景。

最简单的用法：

codex exec "总结这个仓库的结构，并列出 5 个风险点"

你也可以把管道输入交给它：

npm test 2>&1 \
 | codex exec "总结失败的测试，并给出最小修复建议"

分析日志：

tail -n 200 app.log \
 | codex exec "找出最可能的根因，并给出下一步排查步骤"

生成发布说明：

codex exec "根据最近 10 个 commit 生成 release notes" \
 | tee release-notes.md

如果希望输出最后一条消息到文件：

codex exec "提取项目元信息" -o project-summary.md

如果你要把 Codex 接进自动化流程，exec 比交互式 TUI 更适合。

5. `codex review`：专门做代码审查

除了会话里的 /review，命令行也有独立的审查指令：

codex review

审查未提交改动：

codex review --uncommitted

和某个基础分支对比：

codex review --base main

审查某个 commit：

codex review --commit <SHA>

你也可以追加自定义审查要求：

codex review --uncommitted "重点检查并发安全、权限校验和数据库迁移风险"

这个指令适合放在提交前，尤其是你已经让 Codex 改过代码之后，再让它从另一个角度挑问题。

6. `resume` 和 `fork`：不要浪费已经建立好的上下文

Codex 会话最值钱的不是那几句回答，而是它已经理解过的上下文。

恢复最近一次交互式会话：

codex resume --last

恢复指定会话：

codex resume <SESSION_ID>

非交互式模式也可以恢复：

codex exec resume --last "继续修复刚才发现的问题"

如果你想在已有会话基础上开一个分支，而不是污染原来的上下文，可以用：

codex fork --last

resume 适合“继续刚才的任务”，fork 适合“沿着另一个方向试试”。

7. `apply`：应用 Codex 生成的变更

如果你使用 Codex Cloud 或某些远程任务流程，可能会拿到一个任务 ID。此时可以用：

codex apply <TASK_ID>

它会把 Codex 产生的 diff 应用到本地工作区。

建议应用之后立刻做三件事：

git diff

npm test
# 或你的项目测试命令

git status -sb

不要把 apply 当成自动合并按钮。它只是帮你把变更拿下来，是否接受仍然要由你判断。

8. 沙箱与审批：控制 Codex 能做什么

Codex 的权限控制主要由两个概念组成：

sandbox：它能访问和修改什么
approval：它什么时候需要你确认

常见沙箱模式：

codex -s read-only
codex -s workspace-write
codex -s danger-full-access

大致可以这样理解：

模式	适合场景
`read-only`	只分析、不修改
`workspace-write`	允许修改当前项目，日常最常用
`danger-full-access`	高风险，只有在外部环境已经隔离时才考虑

审批策略常见有：

codex -a on-request
codex -a never
codex -a untrusted

日常使用建议：

看代码、问问题：read-only
做普通功能：workspace-write + on-request
自动化脚本：谨慎使用 never
不要在重要机器上随手开 danger-full-access

9. 配置文件：把常用偏好固定下来

Codex 的配置通常在：

~/.codex/config.toml

项目内也可以有：

.codex/config.toml

你可以用 -c 临时覆盖配置：

codex -c model="gpt-5.5" "分析这个模块"

也可以使用 profile：

codex --profile work

一个简单配置示例：

model = "gpt-5.5"
approval_policy = "on-request"
sandbox_mode = "workspace-write"

[features]
web_search = true

配置文件适合放“长期偏好”，命令行参数适合放“本次任务的特殊要求”。

10. MCP 与插件：让 Codex 接入外部工具

管理 MCP Server：

codex mcp list
codex mcp get <name>
codex mcp add <name> <command>
codex mcp remove <name>

如果 MCP Server 需要登录：

codex mcp login <name>
codex mcp logout <name>

插件相关入口：

codex plugin marketplace

MCP 和插件不是新手第一天必须掌握的东西。更合理的顺序是：

先熟悉 codex 和斜杠指令。
再学会 codex exec 自动化。
最后再接 MCP 和插件扩展外部系统。

否则很容易还没建立基本使用习惯，就先把权限和工具链搞复杂。

11. 一套日常工作流

如果你刚开始用 Codex，可以按这个节奏来：

第一步：让它先读项目

codex -C /path/to/project "阅读项目结构，说明主要模块和启动方式，不要修改文件"

第二步：让它给计划

/plan 给这个功能设计实现方案，列出需要改哪些文件、风险点和测试方式

第三步：确认后再实现

按刚才的方案实现，保持改动尽量小，并补充必要测试

第四步：看 diff

/diff

第五步：审查

/review

或者在终端里：

codex review --uncommitted "重点检查回归风险和边界条件"

第六步：跑测试，把失败日志交给它

npm test 2>&1 | codex exec "总结失败原因，并给出最小修复建议"

这个流程比“直接让 Codex 改到能跑”为好。它把计划、实现、审查、验证拆开，出错时也更容易定位。

12. 最容易踩的坑

坑一：一上来就给大权限

danger-full-access 看起来省事，但也最容易出事。除非你在容器、临时机器、隔离环境里，否则不要把它当默认模式。

坑二：把所有任务塞进一个长会话

一个会话写功能、改文案、查线上问题、顺便重构配置，最后上下文会变得很混乱。任务边界变了，就 /new。

坑三：不看 diff

AI 写代码最怕“顺手”。它可能顺手改格式、顺手换依赖、顺手动配置。每次实现后都应该看 diff。

坑四：没有项目规则

长期项目一定要写 AGENTS.md 或项目级规则。否则你每次都要重新告诉它测试命令、目录约定、提交习惯、哪些文件不能改。

坑五：把 `exec` 当万能自动驾驶

codex exec 很适合自动化，但它不是替你承担责任。凡是会写文件、发请求、部署、删除数据的任务，都应该有明确权限和校验步骤。

结论

Codex 的核心不是“多一个 AI 聊天窗口”，而是把编码任务拆成可控制的工作流：

用 codex 做交互式协作
用斜杠指令管理模型、计划、权限和上下文
用 codex exec 做自动化分析和批处理
用 codex review 做提交前检查
用 resume / fork 延续或分叉已有上下文
用 sandbox、approval 和配置文件控制风险

如果只记一条建议：不要一开始就让 Codex 直接改。先让它读项目、写计划、说明风险，再放开权限实现。这样用起来更慢一点，但结果通常更稳。

Codex 零基础使用指南：从小白到会让 AI 帮你读代码、改代码、交付代码

Thu, 07 May 2026 23:39:08 +0800

本文所说的 Codex，指 OpenAI 当前的 Codex coding agent。它可以帮助你读代码、理解陌生代码库、审查代码、调试问题，并可通过 Codex App、IDE 扩展、CLI、Web / Cloud 等入口使用。

本文截图来自 OpenAI 官方页面或 OpenAI 官方 GitHub 仓库中的界面图。实际界面可能随版本更新略有变化。

适合谁看？

这篇文章写给完全没用过 Codex，甚至不太会写代码的人。

你不需要先理解所有 AI Agent 概念。先记住一句话就够了：

Codex 不是只能聊天的 AI，它可以进入一个代码项目，读文件、改文件、跑命令，并把修改差异展示给你。

但也正因为它能动项目文件，新手最重要的不是一上来让它“做个完整项目”，而是学会：

先让它读项目；
再让它提计划；
只做小修改；
看 diff；
跑测试；
用 Git 留回退点。

Codex 是什么
先看真实界面：Codex 长什么样
零基础先理解 5 个关键词
选择入口：App、IDE、CLI、Web 怎么选
第一次使用：推荐从 Codex App 开始
第一次提问：先让 Codex 读项目，不要急着改代码
第一次改代码：只改一个小地方
提示词模板：直接复制就能用
安全使用：权限、沙盒、审批、隐私
7 天小白练习路线
进阶：AGENTS.md 让 Codex 更懂你的项目
常见问题 FAQ

1. Codex 是什么

Codex 可以理解为一个“会进入代码项目工作的 AI 编程助手”。

你可以用自然语言告诉它任务，例如：

请解释这个项目是做什么的。

请找出这个 bug 的原因，并做最小修改。

请为这个函数补一个单元测试。

它会读取项目文件、分析代码、必要时修改文件、运行命令或测试，然后把结果和修改差异展示给你。

更简单地说：ChatGPT 更像是在聊天窗口里回答你，Codex 更像是坐在你的项目目录里一起干活。

Codex 的基本工作流

flowchart LR
A[你提出任务] --> B[Codex 读取项目文件]
B --> C[分析代码和上下文]
C --> D[提出计划或直接修改]
D --> E[运行命令 / 测试 / 检查]
E --> F[展示总结和 diff]
F --> G[你审查、追问、接受或回滚]

这里最关键的是最后一步：你仍然要审查结果。

Codex 很强，但它不是“自动上线机器”。新手最稳的用法，是把它当成一个能干活的助手，而不是一个不需要检查的自动驾驶。

2. 先看真实界面：Codex 长什么样

图 1：Codex 欢迎 / 登录界面

第一次打开 Codex App 时，可以看到欢迎页面，通常可选择使用 ChatGPT 账号继续，或输入 API key。

图 2：选择项目文件夹

Codex 不是只和你闲聊，它通常需要知道自己要在哪个项目里工作。你可以选择一个项目文件夹或 Git 仓库。

图 3：第一次输入任务

选择项目后，就可以在输入框里告诉 Codex 要做什么。第一次建议先让它解释项目，不要急着改代码。

图 4：Codex App 主界面：线程、项目、修改预览

Codex App 是桌面端工作台，可以并行处理多个线程，也能配合 worktree、自动化和 Git 功能使用。

图 5：Local / Worktree / Cloud 模式

Codex App 中，一个线程可以选择不同模式：Local、Worktree、Cloud。

Local：直接在当前项目目录工作；
Worktree：把改动隔离到新的 Git worktree；
Cloud：在配置好的云环境中远程运行。

图 6：Git 提交面板

Codex App 内置 Git 工具，可以展示 diff，也可以 stage、commit、push、创建 PR。

图 7：内置终端

每个线程可以使用内置终端，常见用途包括：

git status
npm test
pnpm run lint

图 8：App 内置浏览器

做前端项目时，Codex 可以借助 App 内置浏览器预览本地页面、检查页面元素，或验证 UI 修复。

图 9：VS Code / Cursor / Windsurf 中的 Codex 扩展

如果你已经使用 VS Code、Cursor、Windsurf 或 VS Code 兼容编辑器，可以用 Codex IDE 扩展。

图 10：IDE 中切换权限模式

Codex IDE 扩展支持 Chat、Agent、Agent Full Access 等模式。新手建议先用 Chat 或普通 Agent 模式，不要一开始就给 Full Access。

图 11：CLI 终端界面

Codex CLI 是在终端里运行的 coding agent，更适合已经习惯命令行的开发者。

图 12：GitHub 中请求 Codex Review

当 Codex Cloud / GitHub 集成设置好后，可以在 GitHub PR 评论中使用 @codex review 请求代码审查。

图 13：Codex 在 GitHub PR 中发布 review

Codex 会在 PR 上留下 review comment，指出具体代码位置和问题说明。

3. 零基础先理解 5 个关键词

关键词	小白解释	为什么重要
项目文件夹	装代码的文件夹	Codex 需要知道在哪个项目里工作
Git	代码版本管理工具	改坏了可以回退
diff	修改前后的差异	Codex 改完后，你要看 diff 决定是否接受
PR / Pull Request	把一组代码修改提交给别人审查	Codex Cloud / GitHub 场景经常会用到
沙盒 / 审批	限制 Codex 能改哪里、能否联网、何时要你同意	小白避免误删文件或误跑危险命令

如果你现在只想记一个词，那就是 diff。

Codex 改完文件后，不要只看它的总结。一定要看 diff，因为 diff 才是它真正改了什么。

4. 选择入口：App、IDE、CLI、Web 怎么选

Codex 有多个入口。零基础用户最容易卡住的地方，就是不知道该从哪里开始。

flowchart TD
A[我要开始用 Codex] --> B{我会用代码编辑器吗?}
B -- 不太会 --> C[优先用 Codex App]
B -- 会用 VS Code / Cursor / Windsurf --> D[用 Codex IDE 扩展]
B -- 会用终端 --> E[用 Codex CLI]
A --> F{项目在 GitHub 上吗?}
F -- 是，想让 Codex 后台跑任务或出 PR --> G[用 Codex Web / Cloud]
F -- 否，本地文件夹为主 --> C

入口	适合谁	主要用途
Codex App	最适合零基础开始	桌面 App，选择项目后直接发任务
IDE 扩展	已经用 VS Code、Cursor、Windsurf、JetBrains 的人	在编辑器侧边栏中使用 Codex
CLI	会用终端的人	在终端中让 Codex 读、改、跑项目
Web / Cloud	项目在 GitHub 上，想后台处理任务	在云环境中运行任务、审查 diff、创建 PR

我的建议很简单：

小白优先 Codex App；开发者优先 IDE 扩展；命令行熟练后再用 CLI；GitHub 项目需要后台跑任务时再看 Web / Cloud。

5. 第一次使用：推荐从 Codex App 开始

5.1 账号与计划

Codex 的可见入口、额度和功能，会受你的 ChatGPT 计划、workspace 权限和登录方式影响。

如果你使用 Codex App，通常可以用 ChatGPT 账号登录，也可以使用 OpenAI API key。需要注意的是，用 API key 登录时，某些 Cloud 相关功能可能不可用。

5.2 下载、打开、登录

建议小白按这个顺序：

安装 Codex App。
使用 ChatGPT 账号登录。
选择一个练习项目文件夹。
第一次先选择 Local。
第一次任务只让 Codex 解释项目，不要让它改代码。

5.3 第一次推荐输入

请先不要修改任何文件。请用中文解释这个项目：

1. 这个项目大概是做什么的？
2. 主要文件夹分别有什么作用？
3. 入口文件可能在哪里？
4. 如果我要运行它，通常要执行哪些命令？
5. 你有哪些不确定的地方？请明确说“不确定”，不要猜。

这条 prompt 的核心是：先读项目，不改项目。

6. 第一次提问：先让 Codex 读项目，不要急着改代码

新手最容易犯的错误，是第一次就说：

帮我重构整个项目。

帮我做一个完整网站。

把所有 bug 都修了。

这些任务范围太大，你很难判断 Codex 改得对不对。

更好的顺序是：

flowchart TD
A[第一步：解释项目，不改文件] --> B[第二步：让 Codex 提计划]
B --> C[第三步：只改一个小地方]
C --> D[第四步：运行检查或说明无法检查]
D --> E[第五步：看 diff]
E --> F[第六步：接受、追问或回滚]

第一次可以这样问：

请先不要修改文件。请解释这个项目的结构，并告诉我新手应该先读哪些文件。

等你确认 Codex 对项目理解基本正确，再进入下一步。

7. 第一次改代码：只改一个小地方

等你确认 Codex 已经大致理解项目后，再让它做一个很小的修改。

推荐从 README 开始：

请只修改 README.md，新增一个“小白如何启动项目”的小节。

要求：
- 不要修改其他文件
- 不要安装新依赖
- 不要改代码
- 改完后告诉我你改了哪里
- 如果项目里没有明确启动命令，请说明“不确定”，不要编造

改完后，你要看两件事：

git status
git diff

如果你用的是 Codex App，也可以直接看 review pane 或 diff pane。

看 diff 时重点看什么？

有没有改到你没让它改的文件；
有没有新增你不认识的依赖；
有没有删除关键配置；
文案或代码是不是符合你的需求；
它说“已完成”的事情，diff 里是否真的体现了。

新手不要怕看不懂全部代码。先从“它到底改了哪些文件”开始，就已经能避免很多风险。

8. 提示词模板：直接复制就能用

8.1 万能结构

目标：
我想让你完成什么？

上下文：
相关文件、错误信息、复现步骤、截图是什么？

范围：
允许你改哪些文件？不允许你改哪些文件？

约束：
不要做什么？例如不要新增依赖、不要改数据库结构、不要改接口字段。

验证：
完成后请运行哪些命令？如果不能运行，请说明原因。

输出：
请列出修改文件、验证结果、风险点和下一步建议。

这个结构不复杂，但很有用。它能减少 Codex 自己猜。

8.2 读项目模板

请先不要修改文件。请帮我理解这个项目：

1. 这个项目是做什么的？
2. 技术栈是什么？
3. 入口文件在哪里？
4. 主要目录分别负责什么？
5. 我作为新手应该按什么顺序阅读？
6. 你有哪些不确定点？

8.3 修 bug 模板

我遇到一个 bug，请帮我定位并修复。

现象：
[粘贴报错或描述现象]

复现步骤：
1. [第一步]
2. [第二步]
3. [第三步]

要求：
- 先解释你认为的原因
- 只做最小必要修改
- 不要新增依赖，除非先征得我同意
- 修完后运行相关测试或说明无法运行的原因
- 最后列出修改文件和风险点

8.4 新增功能模板

请帮我新增一个小功能。

功能目标：
[描述你要的功能]

范围：
- 可以修改：[文件/目录]
- 不要修改：[文件/目录]

要求：
- 先给出简短计划
- 每一步尽量小
- 保持现有代码风格
- 如需新增依赖，先停下来问我
- 完成后运行相关检查

输出：
- 改了哪些文件
- 如何验证
- 还需要我手动检查什么

8.5 代码审查模板

请审查当前未提交的修改。

重点看：
1. 是否有明显 bug
2. 是否有边界情况遗漏
3. 是否破坏现有行为
4. 是否有安全或性能风险
5. 是否需要补测试

要求：
- 先列高风险问题
- 再列中低风险建议
- 不要直接修改文件，除非我明确要求

8.6 带截图做 UI 的模板

Codex 支持图片输入。做 UI 时，可以把截图、设计稿或报错截图一起发给它。

请根据我附上的截图实现一个页面。

要求：
- 使用当前项目已有技术栈
- 尽量匹配截图中的布局、间距和字体层级
- 不要新增 UI 库，除非先问我
- 只新增必要组件
- 完成后告诉我运行哪个命令、访问哪个页面查看效果

9. 安全使用：权限、沙盒、审批、隐私

Codex 能读文件、改文件、运行命令，所以安全边界很重要。

9.1 小白推荐权限

flowchart LR
A[Chat / Read-only<br/>只读、解释、规划] --> B[Agent / Auto<br/>可在工作目录内读写和运行命令]
B --> C[Full Access<br/>更大权限和网络访问]
A -. 新手优先 .-> A
B -. 小任务可用 .-> B
C -. 谨慎使用 .-> C

模式	适合场景	小白建议
Chat / Read-only	解释项目、问问题、写计划	第一次使用优先
Agent / Auto	小范围改文件、跑测试	看清 diff 后再接受
Full Access	跨目录、联网、复杂任务	新手不要默认使用

9.2 审批弹窗怎么选

当你看到 Codex 请求批准时，先看它要做什么。

谨慎对待这些行为：

rm -rf

sudo

curl ... | sh

npm install 某个你不了解的包

访问系统目录或项目外目录

如果你不确定，就选更窄的批准方式，或者直接拒绝，让 Codex 解释为什么需要这个命令。

9.3 不要把这些内容交给 Codex

不要把以下内容直接放进项目、prompt、日志或截图里：

API key
数据库密码
生产环境 token
客户隐私数据
身份证、银行卡、手机号等敏感信息
公司未授权共享的内部材料
生产数据库连接字符串

尤其要注意：很多错误日志里会带 token、cookie、URL 参数或数据库连接信息。粘贴前先看一眼。

9.4 每次改代码前先做 Git checkpoint

在项目目录里执行：

git status
git add .
git commit -m "checkpoint before codex task"

Codex 改完后执行：

git status
git diff

如果改坏了，可以用 Git 回退。

如果你还不会 Git，至少先做到一点：不要在没有备份的情况下，把 Codex 放进很重要的生产项目里大改。

10. 7 天小白练习路线

第 1 天：只读项目，不改文件

请不要修改文件。请解释这个项目的用途、目录结构、入口文件和运行方式。

目标：知道项目大概是什么。

第 2 天：让 Codex 写项目说明

请根据你对项目的理解，生成一份 docs/project-overview.md 草稿。

要求：
- 面向零基础读者
- 解释主要目录和启动方式
- 不要修改代码文件

目标：练习让 Codex 生成文档。

第 3 天：只改 README

请只修改 README.md，补充“安装依赖”和“启动项目”说明。
不要修改其他文件。

目标：练习看 diff。

第 4 天：修一个小 bug

这是报错信息：[粘贴错误]

复现步骤：
1. [第一步]
2. [第二步]
3. [第三步]

请定位原因并做最小修改。修完后运行相关检查。

目标：学会提供现象和复现步骤。

第 5 天：补测试

请为刚才修复的问题补一个最小测试。

要求：
- 先说明测试覆盖什么
- 不要大范围重构
- 完成后运行测试

目标：不要只让 Codex 改代码，也要让它验证。

第 6 天：让 Codex 审查你的改动

请审查当前未提交修改，重点看 bug、边界情况、回归风险和是否需要测试。
先不要修改文件，只输出审查意见。

目标：把 Codex 当第二双眼睛。

第 7 天：尝试 Worktree 或 Cloud

请在隔离分支或 worktree 中尝试实现这个小功能：[功能描述]

要求：
- 先给计划
- 改动尽量小
- 完成后说明如何验证

目标：学会在隔离环境里尝试更复杂的改动。

11. 进阶：AGENTS.md 让 Codex 更懂你的项目

当你经常使用 Codex，可以在项目根目录添加 AGENTS.md。

可以把它理解成“给 AI Agent 看的项目说明书”。Codex 开始工作前会读取这些项目指导，帮助它理解团队约定。

示例：

# AGENTS.md

## 项目约定

- 修改 JavaScript 文件后，请运行 npm test。
- 不要新增生产依赖，除非先征得用户确认。
- 修改公共工具函数时，请同步更新 docs/。
- 输出总结时，请包含：修改文件、验证方式、风险点。

适合写进 AGENTS.md 的内容包括：

项目启动方式；
测试、构建、lint 命令；
代码风格；
不能改的目录；
发布流程；
PR 要求；
数据库和接口兼容性要求。

一个好用的原则是：当你第二次提醒 Codex 同一件事，就应该考虑把它写进 AGENTS.md。

12. 常见问题 FAQ

Q1：我完全不会代码，可以用 Codex 吗？

可以，但建议从“解释项目”“整理文档”“读报错”“写学习路线”开始，不要一上来让它做大范围重构。

你可以把 Codex 当成辅助学习工具，但它修改文件后仍然需要你审查 diff 和验证结果。

Q2：Codex App、IDE、CLI、Web 到底选哪个？

小白优先用 Codex App；已经每天用 VS Code、Cursor 或 Windsurf，就用 IDE 扩展；会终端再用 CLI；项目在 GitHub 上且想让 Codex 后台处理任务、生成 PR 时，用 Web / Cloud。

Q3：Codex 改错了怎么办？

先看 diff，不满意就让它继续改；如果项目已经被改乱，使用 Git 回滚。

如果你还没学 Git，建议先用练习项目，不要直接在重要项目上大范围改动。

Q4：Codex 要求批准命令，我该点同意吗？

看懂命令再同意。

涉及删除文件、安装依赖、访问项目外目录、联网下载、运行脚本的命令尤其要谨慎。

看不懂时，可以直接问：

请解释这个命令要做什么、为什么必须执行、有没有更安全的替代方式。

Q5：需要 API key 吗？

不一定。

Codex App 可以使用 ChatGPT 账号或 OpenAI API key 登录。但使用 API key 时，部分功能例如 cloud threads 可能不可用。

Q6：Codex 能直接替我上线吗？

不建议让 Codex 在无人审查的情况下直接操作生产环境。

更安全的流程是：

小范围任务
→ 查看 diff
→ 运行测试
→ 审查风险
→ commit / PR
→ 人工确认后再发布

最后总结

Codex 的正确入门方式不是：

帮我一次性做完整项目。

而是：

先解释项目
→ 再提出计划
→ 只做小修改
→ 看 diff
→ 跑测试
→ 再迭代

把任务拆小、把权限收紧、把验证写清楚，你就可以从零基础开始，安全地使用 Codex 帮你读代码、改代码和审查代码。🚀

参考资料

如何免费申请 ChatGPT Pro：OpenAI Codex for Open Source 开源计划指南

Thu, 07 May 2026 22:30:00 +0800

很多人搜索“如何免费使用 ChatGPT”，但更准确的说法应该是：如何通过 OpenAI 官方计划，合规申请一段时间的 ChatGPT Pro 权益。

ChatGPT 本身已经有免费版本。如果你只是普通用户，并没有维护开源项目，那么这篇文章不适合把它理解成“免费领取 Pro”的教程。

但如果你是开源项目维护者，OpenAI 的 Codex for Open Source 计划确实提供了一个官方申请渠道。根据 OpenAI 官方页面，开源维护者可以申请 API credits、6 个月 ChatGPT Pro with Codex，以及有条件的 Codex Security 访问权限。

本文按 2026 年 5 月 7 日可见的 OpenAI 官方页面整理。项目规则和表单可能会变化，申请前建议再核对一次官方页面。

一句话总结

Codex for Open Source 不是面向所有人的免费 Pro 活动，而是 OpenAI 面向开源维护者的支持计划。

如果你维护公共开源项目，并且能说明项目价值、维护者角色和 AI 工具在开源维护中的真实用途，就可以尝试申请。

这个计划是什么？

Codex for Open Source 是 OpenAI 面向重要开源软件维护者推出的支持计划。

OpenAI 在官方说明中提到，开源维护者经常要处理 pull request review、issue triage、release 维护、安全和代码质量保障等工作。这个计划的目的，是用 Codex、ChatGPT Pro、API credits 等工具，降低真实开源维护流程里的编码和审查负担。

官方页面目前列出的权益包括：

权益	适合用途
6 个月 ChatGPT Pro with Codex	日常编码、代码理解、issue 分析、PR review、文档和维护工作流
API credits	PR 自动审查、维护自动化、release workflow、开源项目机器人
Codex Security	对符合条件的仓库进行更深入的安全相关分析

需要注意：这些权益不是保证发放。OpenAI 的项目条款说明，获批者可能收到一项或多项权益，具体由 OpenAI 审核决定，权益的可用性、期限、范围和时间也可能因申请者、仓库或使用场景不同而变化。

哪些人适合申请？

这个计划更适合下面几类人。

1. 开源项目的主维护者或核心维护者

如果你是某个开源项目的 primary maintainer 或 core maintainer，并且日常负责 issue、PR、release、安全修复、文档、测试或社区维护，那么你比较适合申请。

申请表会要求你说明自己的维护者角色，所以不要只写“我是用户”或“我关注这个项目”，而要说清楚你实际负责什么维护工作。

2. 维护公共且被真实使用的项目

官方页面建议 core maintainer 或维护 widely used public project 的人申请。

这不意味着只有超高 stars 的项目才有机会。如果你的项目在某个语言、框架、插件、基础设施或开发者工具生态中有价值，也可以在申请材料里解释它为什么重要。

可以准备这些证据：

GitHub stars、forks、contributors
npm、PyPI、Maven、crates.io、Docker Hub 等平台下载量
下游依赖、用户案例、生产使用场景
最近 3 到 6 个月的 PR、issue、release 活跃度
你本人负责的 review、triage、release、安全修复或文档维护工作

3. 有明确 AI 维护工作流的人

如果你计划把 Codex 或 API credits 用在 PR 初审、变更摘要、测试建议、release notes、维护脚本、issue 分类等场景，申请材料会更有说服力。

一个好的申请不应该只写“我想免费用 ChatGPT Pro”，而应该写清楚：

你的项目为什么值得被支持；
你在项目中承担什么维护责任；
ChatGPT Pro、Codex 或 API credits 会如何帮助开源维护；
AI 输出会如何被维护者复核，而不是直接无人值守地合并。

申请前需要准备什么？

OpenAI 官方申请表目前需要填写这些信息：

字段	说明
First name / Last name	你的姓名
Email	与 ChatGPT 账号关联的邮箱
GitHub username	GitHub profile visibility 需要设为 public
GitHub repository URL	仓库需要设为 public
维护者角色	说明你是 primary maintainer 还是 core maintainer
Why does this repository qualify?	说明项目为什么符合条件，可写 stars、monthly downloads 或生态重要性，限制 500 字符
I’m interested in	可选择 Codex Security、API credits
OpenAI Organization ID	申请表提供了查询入口
How will you use API credits for your project?	说明 API credits 如何用于项目维护，限制 500 字符
Anything else we should know?	补充项目背景、维护压力或其他说明，限制 500 字符

申请表还说明，OpenAI 会 rolling basis review applications，并通过 email 通知 selected applicants。

具体申请步骤

第 1 步：确认自己是否符合申请定位

先判断自己是否真的在维护开源项目。

不要为了申请权益临时创建空仓库，也不要夸大项目影响力。OpenAI 的项目条款要求申请者提供准确、完整的个人、仓库和维护角色信息；OpenAI 也可能考虑仓库使用情况、生态重要性、活跃维护证据、角色或权限以及项目容量等因素。

更直接地说：提交申请不等于一定获得 ChatGPT Pro、API credits 或 Codex Security。

第 2 步：整理项目影响力材料

建议提前准备一段 500 字符以内的项目资格说明。重点不是堆形容词，而是给可验证的信息。

可以按这个结构写：

I am the core maintainer of [project], responsible for PR review, issue triage, releases, and security fixes. The project has [stars/downloads/users] and is used by [ecosystem/users/downstream projects]. It plays an important role in [specific ecosystem or scenario].

如果你的项目 stars 不高，但在某个细分生态里很关键，就把这个事实说清楚。例如它是某个框架插件、部署工具、SDK、MCP server、CLI 工具、语言生态组件，或者被一批真实项目依赖。

第 3 步：打开官方申请页面

进入 Codex for Open Source 官方页面，点击页面里的 Apply today，进入 OpenAI 官方申请表。

官方表单说明，入选维护者可获得：

6 months of ChatGPT Pro, which includes Codex
Conditional access to Codex Security
API credits for coding, maintainer automation, release workflows, and core open source work

第 4 步：填写关键说明

申请表里最关键的是两段短文本。

第一段是 Why does this repository qualify?

这段要回答：你的仓库为什么值得被支持？

可以参考：

I am the primary maintainer of [project], responsible for PR review, issue triage, releases, and documentation. The project has [stars] GitHub stars and about [downloads] monthly downloads. It is used by [downstream projects/users] and provides [specific value] for the [ecosystem] ecosystem.

第二段是 How will you use API credits for your project?

这段要回答：你准备如何把 API credits 用在开源维护上？

可以参考：

We plan to use API credits for pull request review, change summaries, test suggestions, release note generation, issue triage, and maintainer automation. All outputs will be reviewed by maintainers and used only for authorized repositories and core open-source maintenance workflows.

重点是把“使用用途”限定在开源维护里，不要写成个人娱乐、商业项目试用或给团队随意共享。

第 5 步：提交并等待邮件

提交后等待 OpenAI 审核。

官方表单写明，申请会滚动审核，入选者会通过邮件收到通知。没有收到邮件，通常就代表还在等待或没有被选中；官方条款也说明 OpenAI 可以自行批准或拒绝申请，并可能要求额外信息来验证身份、仓库关联、维护者状态或仓库控制权。

提高通过率的写法

不要只强调“我想免费用 ChatGPT”

这个计划的关键词是 open-source maintenance，不是 personal free access。

更好的表达是：你希望用 ChatGPT Pro with Codex 减少维护负担，提高 PR review、bug triage、release、文档和测试效率。

项目影响力要具体

“我的项目很重要”不如下面这种表达更有说服力：

The project has 2,000 GitHub stars, 50,000 monthly npm downloads, and is used by several downstream developer tools.

如果没有下载量，也可以写活跃度、下游引用、社区使用场景或生态位置。

维护者身份要清晰

申请表要求 GitHub profile 和 repository 公开。你也应该在申请材料里讲清楚自己是 primary maintainer 还是 core maintainer，以及你负责哪些维护动作。

比如：

review pull requests
triage issues
maintain releases
fix security issues
maintain documentation
manage CI or release workflow

API credits 用途要合规

不要写：

I want to use the credits for my personal AI experiments.

更建议写：

We will use API credits for PR review summaries, test suggestions, release note generation, and issue triage. Maintainers will review all AI outputs before taking action.

注意事项

1. 不是申请就一定成功

OpenAI 的项目条款写得很清楚：提交申请不保证被选中、获得资助或获得访问权限。

OpenAI 可能根据仓库使用情况、生态重要性、活跃维护证据、维护者角色或权限，以及项目容量等因素综合判断。

2. 权益不可转让、出售或共享

项目权益是个人、有限、不可转让、没有现金价值的。不能出售、转让、再授权、交换或共享。

如果你获得兑换码、邀请或激活流程，也需要按 OpenAI 提供的兑换说明和附加条款使用。

3. Codex Security 和 API credits 可能需要额外审核

Codex Security 和 API credits 属于额外权益，可能需要单独审核、额外资格检查或附加条款。

尤其是 Codex Security，OpenAI 可能会限制在申请者拥有、维护或被授权管理的仓库中使用。

4. 不要扫描或审查未授权仓库

官方条款明确限制：不要用该计划，包括 Codex Security，去扫描、探测、测试或审查你不拥有、也没有权限审查的仓库、系统或代码库。

如果授权不清楚，OpenAI 可能要求证明控制权或授权，也可能限制或撤销访问。

可直接复制的申请文案模板

项目资格说明模板

I am the core maintainer of [project name], responsible for PR review, issue triage, releases, documentation, and security fixes. The project has [stars/downloads/users] and is used by [ecosystem/users/downstream projects]. It plays an important role in [specific ecosystem or scenario], and ChatGPT Pro with Codex would help reduce review workload and maintain code quality.

API credits 使用计划模板

We plan to use API credits for pull request review, change summaries, test suggestions, release note generation, issue triage, and maintainer automation. All outputs will be reviewed by maintainers before use, and credits will only be used for authorized repositories and core open-source maintenance workflows.

总结

通过 Codex for Open Source 申请 ChatGPT Pro，本质上不是“免费薅羊毛”，而是 OpenAI 对开源维护工作的支持。

如果你确实在维护公共开源项目，并且能清楚说明项目价值、维护职责和 AI 工具的使用场景，就值得认真准备并提交申请。

对开源维护者来说，这个计划最有价值的地方不只是 6 个月 ChatGPT Pro，而是把 Codex、API credits 和安全工具接入真实维护流程：更快 review PR，更高效处理 issue，更轻松生成 release notes，也让维护者把时间花在更关键的架构、质量和社区决策上。

官方链接

open-slide：为 AI Agent 设计的幻灯片框架

Thu, 07 May 2026 19:47:00 +0800

一句话定位

open-slide 是一个为 AI Agent 设计的 React 幻灯片框架：你用自然语言描述要做什么，Agent 负责写 React 页面，open-slide 负责画布、预览、演示、导出和迭代。

基础信息卡片

项目	信息
项目名	open-slide
作者	1weiho
定位	Agent-native slide framework
技术栈	TypeScript、React、Vite、pnpm、Turbo
许可证	MIT
最新版本	`@open-slide/core@1.0.6`
GitHub 热度	约 2.1k Stars / 143 Forks
官网	https://open-slide.dev
初始化命令	`npx @open-slide/cli init my-slide`

解决什么问题

传统做 PPT 的流程，通常是在 Keynote、PowerPoint、Figma 或网页编辑器里手动拖拽、调样式、排版。

但现在很多内容其实可以由 AI Agent 生成：结构、文案、视觉层级、配色、代码实现，Agent 都能参与。open-slide 的思路是：既然幻灯片本质上也是视觉代码，那就让 Agent 直接写代码生成幻灯片。

它提供了一个固定的幻灯片运行时：

每页都是一个 React 组件。
每张幻灯片渲染在固定的 1920 × 1080 画布中。
支持开发预览、热更新、演示模式和导出。
Agent 可以围绕项目内置的 skills / 规则来生成和修改幻灯片。

这样用户不需要从零搭建 React、Vite 和导出逻辑，也不需要手动写一堆样板代码。你只需要描述“我要一套关于某个主题的演示文稿”，Agent 负责生成页面，open-slide 负责把这些页面变成可展示、可迭代、可交付的 deck。

核心功能

1. Agent-native authoring

open-slide 的核心卖点是“为 Agent 写幻灯片”设计。

它可以配合 Claude Code、Codex、Cursor 等 Coding Agent 使用。初始化后的项目会带有给 Agent 使用的技能说明，例如：

/create-slide：从主题、风格、页数、文字密度、动效偏好等信息出发，生成一套完整幻灯片。
/slide-authoring：告诉 Agent 画布尺寸、字号体系、配色、布局规则等技术约束。

也就是说，open-slide 不只是一个普通幻灯片组件库，而是把“Agent 如何生成幻灯片”也纳入了工作流。

2. React-first，每页都是代码

open-slide 没有发明一套受限的幻灯片 DSL。每页幻灯片就是任意 React 组件。

这意味着：

可以用普通 TSX 写页面。
可以自由控制布局、样式、动画和组件结构。
可以用 Git 管理版本。
可以让 Agent 直接修改源码。
可以像普通前端项目一样 code review。

官网上也强调：A slide is a file. Just React, nothing else.

3. 固定 1920 × 1080 画布

每张 slide 都渲染在固定的 1920 × 1080 画布中。

这对 Agent 生成内容很重要，因为它给了明确的视觉边界：字号、布局、元素位置、比例关系都可以围绕一个稳定画布设计。

相比响应式网页，这种固定画布更接近真实演示文稿，也更方便导出和展示。

4. 浏览器内 Inspector

open-slide 提供了一个很有意思的迭代方式：可以在开发服务器里点击页面元素，并留下修改意见。

比如你可以点某个标题，然后备注：

“改成红色”
“标题缩小一点”
“把文案改成 Open Slide Rocks”

这些评论会以 @slide-comment 标记写回源码。之后运行 /apply-comments，Agent 就可以读取这些待处理评论，批量修改代码并清理标记。

这个流程很适合“先让 Agent 生成，再人工点选反馈，然后让 Agent 继续改”的协作模式。

5. 素材管理和 Logo 搜索

open-slide 内置 assets panel，可以按 deck 管理图片、视频、字体等素材。

它还集成了 svgl Logo 目录，可以直接搜索并插入品牌 Logo。对于做产品介绍、路演、技术分享来说，这能减少到处找 SVG Logo 的时间。

6. 专业演示模式

open-slide 不只是开发预览，还提供面向正式展示的 present mode：

全屏播放
键盘导航
当前页 / 下一页预览
speaker notes
timer

也就是说，它生成的不只是网页，而是可以真正拿去演讲的演示文稿。

7. 导出静态 HTML 和 PDF

open-slide 支持将 deck 导出为：

自包含静态 HTML
可打印 / 分发的 PDF

静态 HTML 可以部署到 Vercel、Cloudflare Pages、Netlify、Zeabur 或任意静态托管服务。它既适合本地演示，也适合在线分享。

8. Slide manager

项目还提供 slide manager，用来把多个 deck 按文件夹、emoji、拖拽排序等方式组织起来。

当你生成的演示稿越来越多时，这个管理能力会变得有用。

适合谁

open-slide 比较适合这些人：

想用 Claude Code、Codex、Cursor 快速生成演示文稿的人。
更喜欢“幻灯片即代码”的开发者。
需要把技术方案、产品介绍、项目汇报做成可演示 deck 的团队。
想要可版本管理、可 review、可自动化生成的幻灯片流程的人。
不想在传统 PPT 工具里反复拖拽排版的人。

它尤其适合技术型内容：架构讲解、产品 demo、路线图、开源项目介绍、技术分享等。

快速上手

初始化一个项目：

npx @open-slide/cli init my-slide
cd my-slide
pnpm dev

初始化后的 workspace 会预置 open-slide 的运行环境和 Agent 相关规则。你可以让 Agent 通过 /create-slide 生成幻灯片，也可以直接编辑：

slides/<id>/index.tsx

如果要参与 open-slide 本身开发，仓库是一个 pnpm + Turbo monorepo：

pnpm install
pnpm dev
pnpm build
pnpm check
pnpm lint

主要目录：

路径	说明
`packages/core`	核心运行时，包括首页、slide viewer、present mode、inspector、Vite plugin 和 dev/build/preview CLI
`packages/cli`	初始化脚手架，提供 `npx @open-slide/cli init`
`apps/demo`	示例工作区，用于本地开发和演示

结论

open-slide 代表了一种很自然的新方向：不是让 AI 生成一份静态 PPT 文件，而是让 Agent 直接写一套可运行、可迭代、可版本管理的幻灯片代码。

它把 React、固定画布、演示模式、Inspector、素材管理和导出能力组合起来，给 Agent 提供了一个稳定的“幻灯片运行时”。

如果你已经在用 Claude Code、Codex 或 Cursor 做内容和代码生成，open-slide 很适合用来尝试“用 Agent 做演示文稿”的工作流。

OpenLess：开源的 AI 语音输入工具，按住说话，松开成文

Thu, 07 May 2026 11:26:00 +0800

一句话定位

OpenLess 是一个开源的桌面语音输入工具：按住快捷键说话，松开后把语音转成经过 AI 润色的文字，并直接插入到当前光标位置。

基础信息卡片

项目	信息
项目名	OpenLess
GitHub	https://github.com/appergb/openless
官网	https://openless.top
项目定位	开源语音输入 + AI 润色工具
支持平台	macOS 12+、Windows 10+
技术栈	Tauri 2、Rust、React、TypeScript
许可证	MIT
当前版本	v1.2.21-tauri
GitHub 热度	约 900+ Stars

解决什么问题

很多语音输入工具只是把语音转成逐字稿，结果常常还要手动删语气词、补标点、整理结构。

OpenLess 想解决的是：把口语直接变成可用的书面文字。

典型使用方式是，把光标放在 ChatGPT、Claude、Cursor、Notion、邮件、微信或 Slack 的输入框里，按下全局快捷键说一段话。OpenLess 会完成录音、语音识别、AI 润色，然后把处理后的文字插入到当前光标位置。如果目标输入框无法直接插入，它会自动复制到剪贴板，避免刚才说过的话丢失。

它尤其强调 AI prompt 模式：你可以随口描述需求，它帮你整理成结构清晰、约束明确的 prompt，再直接发给 ChatGPT、Claude 或 Cursor。

比如你口述：

我想让 ChatGPT 帮我写个 SQL，从 orders 表里查上个月的订单，按客户分组，金额倒序，要前十个。

OpenLess 可以整理成：

请帮我写一段 SQL，要求如下：

- 从 `orders` 表查询上个月的订单。
- 按客户分组。
- 按金额倒序排序。
- 只返回前 10 条。

这类场景里，它不是简单“听写”，而是把口语变成更适合发送、提问或提交的文字。

核心功能

1. 全局快捷键语音输入

OpenLess 支持通过全局快捷键触发录音。用户可以把光标放在任意输入框里，然后按快捷键开始说话。项目当前支持按住说话和切换式录音两种方式，录音过程中也可以用 Esc 取消。

2. 多种输出模式

OpenLess 不是只输出原始转写，而是提供了几种处理方式：

原文：直接输出转写文字，不额外修改。
轻度润色：修正语气词、标点和明显错字，尽量保留原意。
清晰结构：把口语整理成结构化 prompt，适合直接发给 AI 工具。
正式表达：把口语转换成更正式的书面语。

其中“清晰结构”是它最有辨识度的模式，尤其适合经常写 AI prompt 的用户。

3. 直接插入当前光标位置

OpenLess 的目标不是成为一个新的笔记容器，而是减少输入成本。处理后的文字会直接落到当前应用的输入框里，例如浏览器、聊天工具、编辑器、文档工具等。

如果某些应用限制了直接写入，它会回退到复制到剪贴板，用户手动粘贴即可。

4. 词典和热词

项目提供词典能力，可以维护产品名、人名、专有名词等。启用后的词条会用于语音识别阶段的热词提示，也会在润色阶段作为语义参考。

这对经常输入英文产品名、技术名词、团队内部名称的用户会比较有用。

5. 历史记录和设置面板

OpenLess 提供主窗口，用来查看概览、历史、词典、风格和设置。用户可以回看每次录音的原始转写和润色结果，也可以调整语言、快捷键、模型凭据等配置。

6. 本地优先，自带服务凭据

类似工具很多是闭源订阅服务，用户的数据、词典和模型调用都沉淀在服务商账户里。

OpenLess 的思路是：应用开源，数据尽量保留在本机，用户自己配置语音识别和文本润色服务。当前支持火山引擎 ASR、OpenAI Whisper 兼容批式 ASR，以及 Ark / DeepSeek / OpenAI 兼容的 Chat Completions。

适合谁

OpenLess 比较适合这些用户：

经常给 ChatGPT、Claude、Cursor、Gemini 写 prompt 的人。
经常写邮件、需求说明、长消息，又不想一直打字的人。
希望用语音快速整理代码注释、commit message、PR 描述的开发者。
想要开源方案，不想完全依赖闭源订阅语音输入工具的人。
macOS 或 Windows 桌面重度用户。

如果你的日常工作里有大量“把想法变成文字”的环节，OpenLess 会比较容易融入工作流。

快速上手

普通用户可以直接到 GitHub Releases 下载对应平台安装包：

macOS：OpenLess_<version>_aarch64.dmg
Windows：OpenLess_<version>_x64-setup.exe

首次启动后需要授予必要权限。

macOS 用户需要：

授予麦克风权限。
授予辅助功能权限。
退出并重新打开 OpenLess。
在设置里填写 ASR 和 LLM 服务凭据。

Windows 用户需要：

授予麦克风权限。
在设置里确认全局快捷键监听正常。
填写 ASR 和 LLM 服务凭据。

开发者从源码运行大致如下：

git submodule update --init --recursive

cd openless-all/app
npm ci
npm run tauri dev

项目当前活跃代码在 openless-all/app/，桌面端基于 Tauri 2，后端为 Rust，前端为 React / TypeScript。

结论

OpenLess 可以理解为一个开源版 AI 语音输入助手。

它不做问答，不帮你执行任务，也不试图变成另一个 AI 客户端。它专注做一件事：把你说的话变成更清楚、更适合发送或提问的文字，并放到当前输入框里。

对于经常写 prompt、长消息、邮件、需求说明或代码相关描述的人来说，这个方向很实用。开源、自带服务凭据、本地优先，再加上面向 AI prompt 的结构化整理，是 OpenLess 目前最值得关注的几个特点。

Petdex：给 Codex 找一个会动的桌面伙伴

Wed, 06 May 2026 23:20:00 +0800

一句话定位

Petdex 是一个面向 Codex 的动态宠物图鉴网站：你可以在里面浏览、预览、收藏和安装各种像素风 companion，让本地 Codex 使用体验多一点陪伴感。

基础信息卡片

项目	信息
官网	https://petdex.crafter.run/
GitHub	https://github.com/crafter-station/petdex
项目定位	Codex-compatible animated pets public gallery
当前规模	首页显示 870+ 个宠物，GitHub 仓库约 600+ Stars
快速安装示例	`npx petdex install boba`

解决什么问题

Codex 这类命令行工具通常很高效，但也很“冷”：窗口里只有文本、任务、日志和结果。

Petdex 做的事情很简单：把各种动态 companion 做成一个公开图鉴，让用户可以像逛头像库、贴纸库一样，为自己的 Codex 环境挑一个宠物。

它主要解决三个小问题：

资源集中展示：不用到处找宠物包，直接在 Petdex 里浏览。
效果可以预览：每个 companion 不只是一个名字，而是带有图像、状态和描述。
安装路径明确：网站直接给出安装命令，降低尝试成本。

这不是一个提高模型能力的工具，而是一个让开发环境更有个性、更有仪式感的小组件。

核心功能

1. 浏览宠物图鉴

首页展示了大量 companion 卡片，每个卡片包含编号、名称、分类、简介、标签、作者和安装数据。

比如首页中的 Boba，是一只喝珍珠奶茶的小水獭；Duo、Doraemon、Noir Webling 等角色也都以像素风或 chibi 风格呈现。

这种设计让 Petdex 更像一个“宠物图鉴”，而不只是一个文件列表。

2. 一条命令安装

Petdex 首页直接给出安装命令：

npx petdex install boba

对用户来说，这个体验比较直接：看到喜欢的 companion，复制命令安装即可。

3. 精选合集

网站有 Collections 页面和首页精选合集，例如：

GRAYCRAFT：原创机甲风角色合集
Meme Lords：Pepe、Wojak、Doodlebob 等 meme 风格角色
Anime Heroes：动漫角色风格 companion

合集让浏览更有主题感，也方便创作者把一组相关设计放在一起展示。

4. 社区提交

Petdex 提供 Submit 入口，README 里也提到支持在浏览器中校验并提交社区宠物包。

这意味着它不是一个只读图库，而是希望让更多人参与补充 companion。

5. 开源维护

Petdex 的 GitHub 仓库公开，README 中说明它是一个 Codex-compatible animated pets gallery，并列出了几个核心能力：

浏览已审核的宠物包
预览每个动画状态
下载单个 ZIP 包
下载完整图库包
在浏览器中校验和提交社区宠物包

从仓库结构看，宠物资源放在 public/pets，可下载包生成在 public/packs。

适合谁

Petdex 适合几类人：

经常使用 Codex，想让本地环境更有个性的人；
喜欢像素风、chibi 风、桌面宠物这类轻量视觉元素的人；
想给自己的工具链加一点“陪伴感”的开发者；
想创作并分享 Codex companion 的设计者。

如果你只关心模型效果、任务成功率或工程自动化，Petdex 不是必需品；但如果你已经每天都在终端里和 Codex 打交道，它能让这个过程更轻松一点。

快速上手

打开官网：

https://petdex.crafter.run/

选择一个喜欢的 companion，比如 Boba，然后执行：

npx petdex install boba

也可以在网站里继续浏览更多宠物、合集和创作者页面。

如果想了解项目本身，可以查看 GitHub 仓库：

https://github.com/crafter-station/petdex

结论

Petdex 不是一个复杂的大工具，它更像 Codex 生态里的一个趣味入口：把 companion 做成可浏览、可预览、可安装、可提交的公共图鉴。

它的价值不在于让 Codex 变得更聪明，而在于让使用 Codex 的过程更有个性、更轻松，也更像一个可以被社区一起装饰的工作空间。

Keep Codex Fast：让 Codex 本地状态保持轻快的安全维护技能

Mon, 04 May 2026 15:49:45 +0800

一句话定位

Keep Codex Fast 是一个面向 Codex 重度用户的本地状态维护 Skill：先检查、先交接、先备份，再把旧会话、日志、临时工作区等“拖慢体验”的本地状态安全归档。

基础信息卡片

项目	信息
GitHub	https://github.com/vibeforge1111/keep-codex-fast
作者	vibeforge1111
开源协议	MIT
主要语言	Python
默认分支	main
项目定位	Codex 本地状态检查与安全维护 Skill
当前热度	约 559 Stars、29 Forks（2026-05-04 查询）

解决什么问题

Codex 用久之后，很多人会遇到一种不太容易定位的“变重”：

长对话越积越多；
经常恢复旧线程；
同时维护多个仓库；
本地终端、开发服务器、日志、工作区持续堆积；
想清理，又担心误删历史上下文。

Keep Codex Fast 关注的不是“让模型回答更快”，而是整理 Codex 在本机留下的运行状态。它的核心原则很克制：

Make handoffs first. Archive, don’t delete. Apply changes only when you are ready.

也就是：先做交接文档，归档而不是删除，只有在你确认准备好时才真正应用改动。

这对长期使用 Codex 做开发的人很实用。因为真正让人犹豫清理的，往往不是文件本身，而是旧会话里还藏着项目决策、排错过程、失败命令和下一步计划。Keep Codex Fast 把“清理”拆成了更安全的流程：先看清楚，再保留可恢复的上下文，最后再归档。

核心功能

flowchart TD
A[Codex 本地状态变重] --> B[只读检查]
B --> C[生成维护报告]
C --> D{是否还有重要旧会话?}
D -- 有 --> E[创建 handoff 交接文档]
E --> F[备份重要状态]
D -- 没有 --> F
F --> G[归档旧会话/旧工作区]
G --> H[轮转大日志]
H --> I[清理失效项目引用]
I --> J[再次检查并确认结果]

这张流程图里最关键的是第一步：默认只读检查。Keep Codex Fast 不会一上来就移动文件或删除历史，而是先报告本地状态，让你知道问题主要来自哪里。

1. 默认只读报告

项目 README 明确说明：默认模式只做报告，不写文件、不创建备份、不移动目录，也不会修改本地 Codex 状态。它会帮助你看到哪些本地状态增长明显，例如活跃会话、归档会话、日志、旧工作区、失效项目引用以及较重的 Node/开发进程。

这让第一次使用的心理负担比较低：你可以先把它当成一次体检，而不是一次清理操作。

2. Handoffs First：先交接，再归档

Keep Codex Fast 特别强调 handoff 文档。所谓 handoff，就是一份小型连续性笔记，记录：

当前在做什么；
已经改了什么；
哪些文件重要；
已经跑过哪些命令或检查；
还有什么错误、警告或未决问题；
下一步应该怎么继续。

有了这份文档，你就可以把沉重的旧聊天归档，然后在新的 Codex 会话里从 handoff 继续，不必一直依赖越来越长的历史线程。

3. 备份优先，归档而不是删除

真正执行维护时，Keep Codex Fast 的策略也是保守的：先备份重要状态，再把旧会话、旧工作区、大日志移动到归档位置。它处理的是“从热路径移走”，而不是“永久删除”。

根据项目说明，它可以处理的内容包括：

旧的非置顶活跃会话；
过期 worktrees；
较大的 logs_2.sqlite* 日志文件；
config.toml 中失效或临时项目引用；
Windows \\?\C:\... 这类扩展路径不一致问题；
较重的 Node/开发进程报告。

4. 手动应用，不建议自动清理

项目也给出了一个很重要的边界：周期性维护更适合做“提醒”和“报告”，不适合自动执行清理。原因很简单，自动化并不知道哪些旧会话对你仍然重要，也不知道 handoff 是否已经准备好。

所以更稳妥的方式是：定期检查，人工确认，然后在 Codex 关闭或明确等待 Codex 退出后再应用维护。

适合谁

Keep Codex Fast 更适合这些 Codex 用户：

每天高频使用 Codex 做开发；
经常跨多个仓库工作；
习惯保留很长的历史会话；
经常恢复旧线程继续排错或开发；
本地同时运行多个终端、服务或 worktree；
想清理 Codex 本地状态，但不想冒丢上下文的风险。

如果你只是偶尔打开 Codex 问几个问题，可能暂时感受不到它的价值。但只要 Codex 已经成为日常开发工作流的一部分，这类“本地状态维护”就会越来越重要。

快速上手

在 Codex 中可以直接让它安装这个 Skill：

Install the keep-codex-fast skill from https://github.com/vibeforge1111/keep-codex-fast

安装后，先做一次只读检查：

Use $keep-codex-fast to inspect my Codex local state and recommend a safe maintenance plan.

如果检查结果显示有旧会话值得归档，先为还可能继续的项目创建 handoff：

Create a comprehensive handoff document for this repo/session before I archive Codex history.

Include:
- repo/path and branch
- current goal
- what we already completed
- files touched or investigated
- commands/tests already run
- known errors, warnings, or failing checks
- open decisions
- constraints, user preferences, and do-not-touch areas
- the next 3-7 concrete steps

Also include a reactivation prompt I can paste into a fresh Codex chat so it can continue from this handoff without relying on the old chat context.

确认重要会话都有交接文档后，再考虑应用安全维护：

Use $keep-codex-fast to apply safe Codex maintenance.

Before changing anything, confirm that important active repo chats have handoff docs or do not need them.

Then back up first, archive instead of deleting, move stale worktrees, rotate large logs, prune dead config references, and verify the result.

If Codex is currently running, do not mutate local state. Tell me to close Codex first.

如果你想直接运行脚本，项目也提供了命令行方式：

python scripts/keep_codex_fast.py

只读报告之外，还可以按需使用：

python scripts/keep_codex_fast.py --details
python scripts/keep_codex_fast.py --backup-only
python scripts/keep_codex_fast.py --apply --archive-older-than-days 10 --worktree-older-than-days 7
python scripts/keep_codex_fast.py --apply --wait-for-codex-exit

结论

Keep Codex Fast 的价值不在于做一次“激进清理”，而在于把 Codex 本地维护变成一个可控流程：先报告，先交接，先备份，再归档。

对重度 Codex 用户来说，旧会话和本地状态既是负担，也是资产。这个项目提供的思路很实用：把真正有价值的上下文沉淀成 handoff，把不需要长期留在热路径里的状态移出去，让新的 Codex 会话重新变轻。

如果你已经明显感觉 Codex 本地使用体验变重，Keep Codex Fast 值得先跑一次只读检查。即使暂时不执行清理，它也能帮你看清楚：到底是哪些本地状态在增长，以及后续应该怎样安全地处理。

HyperFrames：用 HTML 生成视频的开源渲染框架

Sat, 02 May 2026 10:39:18 +0800

一句话定位

HyperFrames 是 HeyGen 开源的 HTML 视频渲染框架：用写网页的方式定义视频画面、时间轴和动画，再通过浏览器预览并渲染成 MP4。

基础信息卡片

项目	信息
GitHub	https://github.com/heygen-com/hyperframes
官方文档	https://hyperframes.heygen.com/introduction
NPM 包	`hyperframes`
主要语言	TypeScript
开源协议	Apache-2.0
当前版本	0.4.41
运行要求	Node.js >= 22、FFmpeg
项目定位	HTML-native、AI-first、deterministic video rendering

解决什么问题

做视频自动化时，常见路线大概有两种：一种是使用传统剪辑工具，适合人工制作，但不适合批量生成；另一种是使用代码化视频框架，适合自动化，但经常要求开发者进入特定组件体系或 DSL。

HyperFrames 选择了一条更贴近 Web 开发的路线：视频本身就是 HTML。

它把视频里的片段、字幕、图片、音频、时间点、轨道关系都放进 HTML 元素和 data-* 属性里。你可以像写页面一样组织画面，用 CSS / GSAP / Lottie / Three.js 等熟悉的前端技术做动画，再用命令行把它渲染成 MP4。

这个思路对 AI Agent 也很友好。因为大模型本来就擅长生成 HTML、CSS 和简单脚本，HyperFrames 又提供了面向 Agent 的 skills / plugin / CLI 工作流，让 Agent 可以从“描述一个视频”一路做到“生成项目、预览、检查、渲染”。

核心功能

1. 用 HTML 描述视频结构

HyperFrames 的核心输入是一份 HTML。每个元素通过 data-start、data-duration、data-track-index 等属性表达它在视频中的出现时间、持续时间和轨道位置。

一个简单的视频可以由视频素材、标题、图片、背景音乐这些普通 HTML 元素组成：

<div id="stage" data-composition-id="my-video" data-start="0" data-width="1920" data-height="1080">
 <video
 id="clip-1"
 data-start="0"
 data-duration="5"
 data-track-index="0"
 src="intro.mp4"
 muted
 playsinline
 ></video>

 <h1
 class="clip"
 data-start="1"
 data-duration="4"
 data-track-index="1"
 >
 Welcome to HyperFrames
 </h1>

 <audio
 data-start="0"
 data-duration="5"
 data-track-index="2"
 data-volume="0.5"
 src="music.wav"
 ></audio>
</div>

这种设计的好处是门槛很低：不需要先学习一个全新的视频编辑格式，也不要求把所有内容改写成 React 组件。

2. 浏览器预览，本地渲染成 MP4

HyperFrames 提供 CLI，可以直接初始化、预览和渲染项目：

npx hyperframes init my-video
cd my-video
npx hyperframes preview
npx hyperframes render

预览阶段会在浏览器里实时查看效果；渲染阶段则通过 headless Chrome 逐帧捕获画面，并交给 FFmpeg 输出最终视频。官方文档强调的是确定性渲染：同样的输入应得到一致的输出，这对自动化流水线很重要。

3. 面向 AI Agent 的工作流

HyperFrames 不只是一个 CLI，还提供了面向 AI 编程工具的配套能力。项目 README 中推荐先安装 skills：

npx skills add heygen-com/hyperframes

这些 skills 会教 Agent 如何写正确的 composition、GSAP 时间线、Tailwind v4 浏览器运行时样式，以及不同动画运行时的适配方式。

项目还提供了面向 Claude Code、Cursor、Codex、Gemini CLI 等工具的使用说明或插件入口。也就是说，它不是只把“AI 支持”当营销词，而是把 Agent 能不能无交互地初始化、lint、预览、渲染，作为框架设计的一部分。

4. 支持多种动画与素材运行时

HyperFrames 使用 Frame Adapter 模式来接入动画运行时。你可以使用 GSAP、Lottie、CSS animation、Three.js、Web Animations API 等方式构建动画，只要它们能够按帧 seek，就可以被纳入确定性渲染流程。

这点对视频自动化很关键：视频不是简单录屏，而是要在指定帧上得到确定画面。HyperFrames 把“页面如何播放”和“渲染器如何按帧捕获”之间的关系抽象出来，让不同动画技术能进入同一条视频生成链路。

5. 内置组件目录与多个子包

项目提供了 50+ ready-to-use blocks and components，例如社交媒体覆盖层、shader transition、数据可视化、电影感效果等，可以通过命令添加：

npx hyperframes add flash-through-white
npx hyperframes add instagram-follow
npx hyperframes add data-chart

从仓库结构看，它是一个 monorepo，主要包含：

包	作用
`hyperframes` / `@hyperframes/cli`	初始化、预览、lint、渲染的 CLI
`@hyperframes/core`	类型、解析器、生成器、linter、runtime、frame adapters
`@hyperframes/engine`	基于 Puppeteer + FFmpeg 的页面到视频渲染引擎
`@hyperframes/producer`	完整渲染流水线，包括捕获、编码和音频混合
`@hyperframes/studio`	浏览器端 composition editor UI
`@hyperframes/player`	可嵌入的 `<hyperframes-player>` Web Component
`@hyperframes/shader-transitions`	用于 composition 的 WebGL shader transitions

官方视频示例

npx hyperframes init my-video --example warm-grain

示例	类型	视频链接
Warm Grain	品牌 / 生活方式	https://static.heygen.ai/hyperframes-oss/docs/images/templates/warm-grain.mp4
Play Mode	社交媒体 / 产品发布	https://static.heygen.ai/hyperframes-oss/docs/images/templates/play-mode.mp4
Swiss Grid	企业 / 技术 / 数据	https://static.heygen.ai/hyperframes-oss/docs/images/templates/swiss-grid.mp4
Kinetic Type	标题卡 / 宣传片	https://static.heygen.ai/hyperframes-oss/docs/images/templates/kinetic-type.mp4
Decision Tree	解释型视频 / 教程	https://static.heygen.ai/hyperframes-oss/docs/images/templates/decision-tree.mp4
Product Promo	产品展示	https://static.heygen.ai/hyperframes-oss/docs/images/templates/product-promo.mp4
NYT Graph	数据故事 / 图表视频	https://static.heygen.ai/hyperframes-oss/docs/images/templates/nyt-graph.mp4
Vignelli	竖屏标题 / 公告	https://static.heygen.ai/hyperframes-oss/docs/images/templates/vignelli.mp4

适合谁

HyperFrames 比较适合这几类场景：

熟悉前端技术、想用代码生成视频的开发者
如果你会写 HTML、CSS、JS，理解它的成本会比较低。
需要批量生成营销视频、教程视频、数据视频的团队
例如把 CSV 变成动态图表、把产品文档变成短视频、把模板批量填充成不同版本的视频。
正在搭建 AI Agent 内容生产流程的人
它的 CLI、skills 和插件设计都偏向自动化，适合作为 Agent 生成视频的执行层。
希望视频生成链路可复现、可集成到流水线的人
相比人工剪辑工具，HyperFrames 更适合放进脚本、CI、Docker 或后端任务里运行。

快速上手

如果想让 AI Agent 参与生成，官方推荐先安装 skills：

npx skills add heygen-com/hyperframes

然后可以直接让 Agent 按 /hyperframes 的上下文生成视频，例如：

Using /hyperframes, create a 10-second product intro with a fade-in title, a background video, and background music.

如果想手动创建项目，可以走 CLI：

npx hyperframes init my-video
cd my-video
npx hyperframes preview
npx hyperframes render --output output.mp4

本地需要准备：

Node.js >= 22
FFmpeg
可以运行 Chromium / Puppeteer 的环境

结论

HyperFrames 的核心价值不在于“又做了一个视频编辑器”，而在于它把视频生成问题重新拉回 Web 技术栈：HTML 负责结构，CSS 和动画库负责表现，浏览器负责渲染，FFmpeg 负责输出。

对于开发者来说，这意味着视频可以像页面一样被生成、版本管理和自动化；对于 AI Agent 来说，这意味着它有了一个更容易理解和操作的视频生成目标格式。

如果你正在做内容自动化、批量视频生成、数据视频，或者想让 AI Agent 从文本直接生成可渲染的视频项目，HyperFrames 是一个值得关注的开源项目。

Multica：把编码 Agent 当成团队成员管理的开源平台

Thu, 30 Apr 2026 17:44:00 +0800

一句话定位

Multica 是一个开源的 Managed Agents 平台，用看板、Issue、运行时和技能系统，把 Claude Code、Codex、OpenCode、Hermes 等编码 Agent 管理成可以被分配任务、跟踪进度、复用经验的“团队成员”。

官方 README 将 Multica 定位为开源的 Managed Agents 平台。它的重点不是再造一个新的编码 Agent，而是把 Claude Code、Codex、OpenCode、Hermes 等已有 Agent 纳入团队协作流：分配任务、跟踪进度、管理运行时，并把常见工程动作沉淀成可复用技能。

官方 README 列出的支持范围包括 Claude Code、Codex、OpenClaw、OpenCode、Hermes、Gemini、Pi、Cursor Agent、Kimi、Kiro CLI。实际支持能力建议以仓库最新 README 和本机 CLI 检测结果为准。

基础信息卡片

项目	信息
GitHub	https://github.com/multica-ai/multica
官网	https://multica.ai
项目定位	Human + Agent 团队协作 / 编码 Agent 管理平台
主要语言	TypeScript（前端为主），后端使用 Go
默认分支	main
Stars	约 22.7k
Forks	约 2.8k
协议	修改版 Apache License 2.0（商业使用有附加条款，正式采用前建议阅读 LICENSE）
支持的 Agent/CLI	Claude Code、Codex、OpenClaw、OpenCode、Hermes、Gemini、Pi、Cursor Agent、Kimi、Kiro CLI 等

解决什么问题

现在很多团队已经开始使用编码 Agent，但常见用法仍然偏“临时对话”：打开一个 CLI、复制一段需求、等待它跑完，再人工确认结果。这个模式适合个人效率工具，却很难自然进入团队协作流程。

Multica 想解决的是另一类问题：当团队里不止一个人、也不止一个 Agent 时，如何把 Agent 纳入日常工作流？

它把 Agent 放到类似项目管理工具的上下文里：任务可以被分配，执行过程可以被观察，阻塞可以被报告，结果可以沉淀为可复用技能。这样 Agent 不再只是一个命令行窗口，而更像看板里的协作者。

Multica 的核心界面接近团队项目管理工具：左侧是工作区导航，中间是 Issues 看板，任务按 Backlog、Todo、In Progress、In Review、Done 等状态流转，Agent 和人类成员共享同一套任务视图。

核心功能

1. Agent 像队友一样被分配任务

在 Multica 里，Agent 可以出现在看板、成员列表、任务负责人和评论区中。你可以像给同事分配 Issue 一样，把任务分配给某个 Agent。

它接手后会更新状态、发表评论、报告阻塞，也可以创建新的 Issue。对团队来说，重点不是“又多了一个 AI 工具”，而是 Agent 的动作被放进了统一的协作记录里。

这也是 Multica 和单个编码 Agent CLI 最大的区别：CLI 解决的是“让 Agent 做事”，而 Multica 解决的是“让团队知道 Agent 在做什么、由谁负责、做到哪一步、结果如何沉淀”。

2. 完整的任务生命周期管理

Multica 不只关注一次 prompt 的输出，而是关注任务从排队、认领、开始执行到完成或失败的全过程。

官方 README 中提到，Multica 支持完整的任务生命周期管理，包括 enqueue、claim、start、complete/fail，并通过 WebSocket 实时推送进度。这样团队可以看到 Agent 正在做什么、卡在哪里、最终产出了什么，而不是几个小时后才发现任务没有继续推进。

这对于团队场景很重要。因为团队协作里，任务是否完成只是结果，过程中的状态、阻塞、上下文和责任归属同样重要。

3. 统一运行时：本地机器和云端都能管理

Multica 通过本地 daemon 连接你的机器，也支持云端运行时。daemon 会自动检测本机 PATH 中可用的 Agent CLI，例如 Claude Code、Codex、OpenCode、Hermes、Gemini、Cursor Agent 等。

这意味着团队可以在一个控制台里管理不同运行环境：有人用本地 MacBook 跑 Agent，有人用云端实例跑任务，Multica 负责把这些运行时统一呈现和调度。

从架构上看，Runtime 是 Multica 很关键的一层。它不只是展示一个看板，而是把“任务”和“执行环境”连接起来，让 Agent 真正可以在指定环境里接手工作。

4. 技能系统：把经验沉淀给整个团队

Multica 的 Skills 设计很关键。它把“如何完成某类任务”的步骤、配置、上下文和模板沉淀下来，让之后的 Agent 可以复用。

例如部署到测试环境、编写数据库迁移、做 PR Review、补测试等，都可以被整理成技能。一次解决方案不只是一次性结果，而会变成团队后续可调用的能力。

这也是 Managed Agents 平台和普通 AI 工具的区别之一：普通 AI 工具更多是在单次对话里产生结果，而 Managed Agents 平台需要让经验可以积累、复用和团队共享。

5. 多工作区与团队隔离

Multica 支持 workspace 级别的隔离，每个工作区可以有独立的 Agent、Issue 和设置。对于多团队、多项目场景，这比单机工具或单人看板更接近真实协作需求。

如果团队同时维护多个项目，或者不同业务线有不同的 Agent、运行时和权限边界，多工作区设计会比单一全局配置更可控。

适合谁

Multica 比较适合以下几类团队或个人：

已经在使用 Claude Code、Codex、OpenCode、Hermes 等编码 Agent，希望把它们纳入团队流程；
有多个项目、多个运行环境，需要统一管理 Agent 执行位置和状态；
希望减少“复制 prompt、盯着终端、人工汇报进度”的重复操作；
想把常见工程动作沉淀为团队级技能，而不是让每个人各自维护脚本和经验；
对自部署、厂商中立、可控基础设施有要求的团队。

如果只是偶尔让 AI 帮忙改一个小函数，Multica 可能显得偏重；但如果团队已经开始认真把编码 Agent 当成协作者，它的价值会更明显。

快速上手

macOS / Linux 推荐使用 Homebrew 安装：

brew install multica-ai/tap/multica

也可以使用安装脚本：

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash

Windows PowerShell：

irm https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.ps1 | iex

安装后，一条命令完成配置、认证和启动 daemon：

multica setup

如果要自部署完整服务，可以使用：

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host

官方架构大致如下：

flowchart LR
A[Next.js 前端] <--> B[Go Backend\nChi + WebSocket]
B <--> C[PostgreSQL 17\npgvector]
B <--> D[Agent Daemon]
D --> E[Claude Code]
D --> F[Codex]
D --> G[OpenCode / OpenClaw]
D --> H[Hermes / Gemini / Cursor Agent 等]

前端使用 Next.js 16，后端使用 Go、Chi、sqlc 和 gorilla/websocket，数据库是 PostgreSQL 17 + pgvector。整体架构并不只是一个 UI 壳，而是围绕 Agent 执行、状态同步、运行时管理和技能复用做了一套完整平台。

Multica 和普通编码 Agent 的区别

很多编码 Agent 解决的是“执行”问题，例如根据提示修改代码、运行命令、生成测试或提交补丁。

Multica 解决的是更上层的“管理”问题：

维度	普通编码 Agent CLI	Multica
使用方式	单次对话或命令行任务	Issue / 看板 / 工作区协作
关注重点	生成代码、修改文件、执行命令	分配任务、跟踪进度、管理运行时
团队可见性	依赖人工同步	状态、评论、阻塞、结果进入统一记录
执行环境	通常绑定本机或单一环境	本地 daemon + 云端 Runtime
经验复用	依赖个人 prompt 或脚本	通过 Skills 沉淀为团队资产

所以它不是 Claude Code、Codex、OpenCode 的替代品，而更像是这些 Agent 之上的协作和管理层。

结论

Multica 的核心价值，是把“编码 Agent”从个人命令行工具提升为团队协作对象。

它没有把重点放在再造一个 Agent，而是站在管理层：谁来做、在哪里跑、进度如何、失败怎么暴露、经验如何复用。对于正在把 AI 编程工具接入真实研发流程的团队来说，这个方向很值得关注。

从当前关注度和功能迭代节奏看，Multica 已经是 Managed Agents 方向里值得关注的开源项目之一。如果你已经在使用多个编码 Agent，并且开始遇到任务分配、运行监控、团队复用这些问题，Multica 可以作为一个开源方案优先试用。

Codex 使用最佳实践：别把它当聊天机器人，要当成一个可配置的工程队友

Sun, 26 Apr 2026 23:27:33 +0800

一句话定位：Codex 的关键不是“写一句 prompt 让它生成代码”，而是把它当成一个可以被配置、被训练工作方式、能持续沉淀经验的工程队友。

这篇文章参考了 OpenAI 官方的 Codex best practices，但不会逐条翻译官方文档，而是整理成更适合日常使用的实践方法。

先说结论

很多人刚开始用 Codex，会把它当成一个更强的代码聊天机器人：

描述一个需求
等它生成代码
看看能不能跑
不行再继续追问

这种方式能用，但很容易不稳定。

更好的方式是：把 Codex 放进一套工程工作流里。

也就是说，不只是让它“写代码”，还要让它知道：

目标是什么
项目上下文在哪里
需要遵守哪些约束
怎么判断任务完成
应该跑哪些测试
哪些经验以后要沉淀下来

当这些东西逐渐固定下来，Codex 的表现会明显更像一个熟悉项目的队友，而不是每次都从零开始的临时助手。

1. Prompt 不用花哨，但上下文要完整

Codex 已经足够强，即使 prompt 写得不完美，也经常能给出不错的结果。

但在真实项目里，尤其是代码量较大、约束较多的项目里，真正影响结果的不是文案写得多漂亮，而是你有没有把关键上下文说清楚。

一个比较稳的任务描述，可以包含四块：

目标：你到底想改什么、做什么。
上下文：相关文件、目录、错误日志、接口文档、历史实现在哪里。
约束：代码风格、架构边界、安全要求、不能改的东西。
完成标准：什么情况算完成，比如测试通过、bug 不再复现、页面行为符合预期。

比如不要只说：

帮我修一下登录问题。

可以改成：

目标：修复用户登录后偶尔跳回首页的问题。
上下文：登录逻辑在 src/auth，路由守卫在 src/router，最近错误日志见 logs/login-error.log。
约束：不要改数据库结构，不要重写登录流程，只修复当前跳转问题。
完成标准：补充或更新测试，确认登录后能回到原访问页面，相关测试通过。

这不是为了“教模型怎么写代码”，而是为了减少它做无谓假设。

2. 复杂任务先 Plan，再让它动手

如果任务简单，比如改一个文案、修一个小 bug，可以直接让 Codex 做。

但如果任务具备这些特征，就应该先让它计划：

涉及多个模块
需求还不清楚
可能影响现有架构
需要排查原因
需要分阶段上线

这时不要急着说“直接改”，而是先让它：

阅读相关代码
复述它对问题的理解
找出可能的风险点
给出修改方案
说明验证方式

官方文档里也强调了 Plan mode。它的价值不是让流程变慢，而是先把“怎么做”暴露出来，避免 Codex 一上来就改一大片代码。

一个好用的说法是：

先不要写代码。请先阅读相关文件，给出你的理解、修改计划、风险点和验证方式。等我确认后再开始实现。

对于不确定的需求，还可以让 Codex 反过来采访你：

我现在只有一个粗略想法，请你先问我问题，帮我把需求变成可执行的开发任务。

这一步对产品功能、重构、复杂 bug 都很有用。

3. 把重复要求写进 AGENTS.md

如果你发现自己经常反复提醒 Codex：

不要改无关文件
改完要跑测试
提交前先看 diff
API 返回格式不能变
某些目录不能碰
这个项目用 pnpm，不要用 npm

那这些就不应该每次都写进 prompt，而应该沉淀到 AGENTS.md。

可以把 AGENTS.md 理解成“给 AI Agent 看的项目 README”。

它适合写：

项目目录结构
本地启动方式
测试、构建、lint 命令
代码风格和工程约定
Pull Request 要求
禁止事项
什么情况算完成

官方建议可以用 /init 快速生成一个初版，但不要停在生成结果上。真正有价值的是根据项目实际情况持续修改。

一个短但准确的 AGENTS.md，通常比一份很长但空泛的规则更有用。

我更建议这样维护：

先写最核心的启动、测试、约束。
当 Codex 犯同一个错误第二次，就把规则补进去。
如果文件变得太长，把 code review、发布流程、调试流程拆成独立文档，再从 AGENTS.md 引用。

也就是说，AGENTS.md 不应该是一次性写完的文档，而应该是团队和 Codex 磨合出来的工作说明书。

4. 配置比临场提醒更稳定

很多 Codex 使用问题，本质不是模型能力问题，而是环境配置问题。

比如：

工作目录不对
没有写权限
默认模型不合适
sandbox 权限太松或太紧
缺少必要工具
MCP 没配好
每次都用命令行参数临时覆盖

官方文档里提到，可以通过 config.toml 固化默认配置，包括模型、reasoning effort、sandbox、approval policy、profiles、MCP 等。

一个比较稳的习惯是：

个人默认配置放在 ~/.codex/config.toml
项目级配置放在 .codex/config.toml
临时命令行参数只用于一次性场景

如果是新手，不建议一开始就给 Codex 很大权限。

更安全的方式是：先用默认权限，让它在需要执行高风险命令时请求确认；等你熟悉某个项目和工作流之后，再逐步放宽。

这点很重要：权限不是越大越好，合适才好。

5. 不要只让 Codex 写代码，也要让它验证代码

很多人用 Codex 的流程停在“代码写出来了”。

但在工程里，真正的完成应该是：

测试补了没有
相关测试跑了没有
lint / format / type check 过了没有
diff 有没有异常
有没有引入回归
最终行为是否符合需求

所以你可以直接把验证要求写进任务：

实现后请运行相关测试，并检查 git diff，确认没有无关修改。如果测试无法运行，请说明原因和你已经做过的验证。

Codex 不是只能生成代码。用得好时，它也可以帮你做：

补测试
跑测试
看日志
review diff
找潜在回归
根据 checklist 做 PR review

官方也提到 /review 这类能力。对团队来说，如果能把 code review 规则写成 code_review.md，再从 AGENTS.md 引用，就可以让 Codex 的 review 行为更稳定。

6. 外部上下文用 MCP，不要一直复制粘贴

有些上下文不在代码仓库里，比如：

issue 系统
文档系统
数据库
监控平台
日志系统
内部 API
设计稿

如果每次都手动复制粘贴，很快就会变成负担，也容易过期。

这时可以考虑 MCP。

MCP 的价值不是“把所有工具都接进去”，而是让 Codex 能稳定访问某些真正高频、会变化、和任务强相关的信息。

比较适合接 MCP 的场景：

经常需要查 issue / PR / CI 状态
经常需要读内部文档
经常需要查日志或监控
多人协作时希望上下文来源一致

但不要一上来就把所有工具都接进去。更好的方式是：先找一个你每天都在手动复制的信息源，把它接好，用顺了再扩展。

7. 重复工作做成 Skill

如果一个流程你已经重复做了很多次，而且每次都要写一大段 prompt，那它就应该变成 Skill。

Skill 适合封装一类稳定任务，比如：

日志排查
发布说明生成
PR checklist review
数据迁移计划
事故复盘摘要
标准调试流程

一个好的 Skill 不需要一开始覆盖所有边界。

更现实的做法是：

先选一个典型任务。
把输入、输出、执行步骤写清楚。
跑几次，看哪里容易失败。
再把失败经验补进去。

官方文档里有一句很实用的判断标准：如果你反复使用同一段 prompt，或者反复纠正同一个流程，它大概率应该变成一个 Skill。

这也是 Codex 从“会帮你写代码”变成“懂你工作方式”的关键。

8. 稳定流程再自动化

自动化很诱人，但不要太早。

如果一个任务还需要你频繁盯着、反复纠正，就不适合直接自动化。

更好的顺序是：

先手动跑通。
把方法沉淀成 Skill。
确认输出稳定。
再放到 automation 里定时执行。

适合自动化的任务包括：

汇总最近 commits
扫描潜在 bug
生成 release notes
检查 CI 失败
生成站会摘要
定期跑某类分析报告

可以简单理解为：Skill 定义方法，Automation 定义时间。

如果方法还不稳定，先别急着定时跑。

9. 长任务要管理 session，不要一个线程聊到底

Codex 的 session 不只是聊天记录，它会积累上下文、决策和中间状态。

所以 session 管理会直接影响结果质量。

一个实用原则是：一个 session 对应一个相对完整的任务。

不要一个项目永远用同一个 session。这样上下文会越来越臃肿，后面反而更容易跑偏。

如果任务还在同一个问题里，继续用同一个线程是合理的，因为它保留了推理过程。

但如果任务已经分叉，就应该 fork 新线程，或者用 subagent 去做边界清晰的子任务，比如：

代码探索
测试补充
日志分析
方案对比
风险排查

主线程负责推进核心判断，子线程负责消化局部信息。这样更容易保持清晰。

常见误区

最后总结几个常见误区：

把长期规则全塞进 prompt，而不是放进 AGENTS.md 或 Skill。
只让 Codex 写代码，不告诉它怎么运行、测试、验证。
复杂任务不先计划，直接让它改。
一开始就给它过大的本机权限。
多个 live thread 同时改同一批文件，却不用 git worktree 隔离。
还没稳定的流程，过早做 automation。
把 Codex 当成必须一步步盯着的工具，而不是可以并行工作的队友。
一个项目只开一个巨大 session，长期混用所有任务。

结论

Codex 的最佳实践，其实不是某个神奇 prompt。

真正重要的是把它纳入工程化使用方式：

用清晰上下文启动任务
复杂需求先计划
用 AGENTS.md 沉淀项目规则
用配置保证一致性
用测试和 review 闭环
用 MCP 接入外部上下文
用 Skill 固化重复流程
用 automation 放大稳定工作流
用 session 管理保持上下文干净

如果只把 Codex 当成“代码生成器”，它能帮你省一些时间。

但如果把它当成一个可配置、可复盘、可沉淀经验的工程队友，它带来的效率提升会大很多。

Obscura：一个为 AI Agent 和网页抓取而生的 Rust 无头浏览器

Sun, 26 Apr 2026 13:55:19 +0800

一句话定位：Obscura 是一个面向 AI Agent 和网页抓取场景的开源无头浏览器，用 Rust 实现，主打轻量、隐身和兼容 Puppeteer/Playwright。

基础信息卡片

项目名：Obscura
仓库：h4ckf0r0day/obscura
定位：Headless browser for AI agents and web scraping
技术栈：Rust + V8
协议兼容：Chrome DevTools Protocol（CDP）
可接入：Puppeteer、Playwright
License：Apache 2.0
当前热度：约 5k Stars / 292 Forks
最近更新：仓库页面显示 2026-04-25
发布情况：目前有 2 个 Release

解决什么问题

这个项目主要解决的是：做自动化抓取或 AI Agent 浏览网页时，传统 Headless Chrome 太重、启动慢、资源占用高，而且容易被识别。

这张图想表达的是：Obscura 不是替代 Puppeteer / Playwright 这些上层框架，而是把一个更轻的浏览器执行层放在 AI Agent、抓取任务和目标网页之间。

Obscura 想提供一个更适合这类场景的替代方案：

不依赖完整 Chrome
单二进制即可运行
启动更快、内存更低
自带一定的反检测能力
又能兼容现有 Puppeteer / Playwright 生态

如果你现在做的是：

大规模网页抓取
AI Agent 自动操作网页
需要执行真实 JavaScript 的采集任务
想减少 Chrome/Node 依赖

那它的切入点就很明确。

核心功能

1）真正执行 JavaScript

它不是简单 HTTP 抓页面，而是基于 V8 跑真实前端逻辑，所以适合：

SPA 页面
动态渲染内容
XHR / fetch 加载后的数据提取
表单提交、登录态保持

2）兼容 CDP，可接 Puppeteer / Playwright

README 里明确写了，它实现了 Chrome DevTools Protocol，可以作为 headless Chrome 的替代后端来接：

Puppeteer
Playwright

这点很实用，因为你不一定要改整套自动化代码。

3）自带 CLI，适合直接抓取

它提供了几个很直观的命令：

obscura fetch：抓单页
obscura scrape：并发抓多个 URL
obscura serve：启动 CDP 服务

适合两类人：

直接命令行跑抓取
作为底层浏览器接入现有自动化脚本

4）隐身模式

这是它比较突出的卖点。README 提到 stealth 模式包括：

指纹随机化
navigator.webdriver 伪装
原生函数伪装
userAgentData 模拟
tracker blocking（拦截追踪/分析脚本）

对于容易被识别的抓取场景，这部分很有吸引力。

5）资源占用轻

README 给出的对比数据里，Obscura 主打：

内存约 30MB
二进制约 70MB
启动接近即时
页面加载明显快于 Headless Chrome

这里要注意：这些是项目 README 自述数据，可以作为方向参考，但真实效果还得看你的目标网站和部署环境。

适合谁

我觉得它比较适合这几类人：

做 AI Agent 的开发者：需要一个更轻的浏览器执行层
做网页抓取的工程师：尤其是高并发、批量抓取场景
做自动化平台的人：希望兼容 Puppeteer/Playwright，但不想带完整 Chrome
Rust / 基础设施方向开发者：愿意尝试新一代浏览器自动化底座

不太适合的点我也顺带提醒一下：

它目前看还是相对较新的项目
生态成熟度、兼容性边角、复杂站点稳定性，可能还需要更多实战验证
如果你要的是“最稳、最成熟、社区最大”的方案，Chrome/Playwright 仍然更稳妥

快速上手

它的上手路径很简单。

直接下载二进制

Linux 示例：

curl -LO https://github.com/h4ckf0r0day/obscura/releases/latest/download/obscura-x86_64-linux.tar.gz
tar xzf obscura-x86_64-linux.tar.gz
./obscura fetch https://example.com --eval "document.title"

常见用法

获取标题：

obscura fetch https://example.com --eval "document.title"

导出链接：

obscura fetch https://example.com --dump links

渲染 JS 后导出 HTML：

obscura fetch https://news.ycombinator.com --dump html

启动 CDP 服务：

obscura serve --port 9222 --stealth

然后 Puppeteer / Playwright 就可以连这个端口。

结论

Obscura 的价值不在“再做一个浏览器”，而在于它试图成为 AI Agent / 抓取场景下更轻、更快、更隐蔽的浏览器执行层。

如果你现在正遇到这些问题：

Headless Chrome 太重
启动慢
部署麻烦
抓取容易被识别
想保留 Puppeteer / Playwright 使用习惯

那这个项目非常值得关注和试用。

andrej-karpathy-skills：把 AI 编程助手调教得更稳一点

Sun, 26 Apr 2026 00:44:55 +0800

一句话定位：andrej-karpathy-skills 不是新的 AI 编程工具，而是一套把 Andrej Karpathy 对 LLM 编码常见问题的观察，整理成可直接放进 Claude Code、Cursor 或个人技能系统里的行为准则。

基础信息卡片

项目名称：forrestchang/andrej-karpathy-skills
项目地址：https://github.com/forrestchang/andrej-karpathy-skills
项目定位：用一份 CLAUDE.md / 规则文件改善 AI 编程助手的协作方式
核心形式：CLAUDE.md、Claude Code 插件、Cursor rule、Skill 文件
开源协议：MIT
默认分支：main
创建时间：2026-01-27
最近活跃：2026-04-25
热度参考：86k+ Stars、8.2k+ Forks

解决什么问题

如果你经常让 AI 参与写代码，大概率已经碰到过几类典型问题：

模型会默认替你做假设，没确认清楚就直接开始写。
一件本来很小的需求，最后被写成过度抽象、层层包装的大工程。
改一个点的时候，顺手把无关代码、注释、结构也改掉了，diff 越看越心慌。
用户说的是“修一下”“补一下”，模型却没有把任务转成可验证目标，最后只能靠人反复返工。

这个项目的价值就在于，它不试图再造一个编码框架，而是直接约束 AI 助手的工作方式：先想清楚，再少改、精改，并且用能验证的目标去推进任务。

核心功能

1. 用四个原则约束 AI 的默认行为

项目把整套方法压缩成四条非常明确的原则：

编码前思考：不要默认假设，遇到歧义先澄清，把权衡说出来。
简洁优先：能简单解决就不要过度设计，不为没被要求的灵活性买单。
精准修改：只改和当前任务直接相关的内容，减少“顺手优化”的副作用。
目标驱动执行：把“去做某件事”改成可验证目标，比如先写测试，再迭代到通过。

这四条听起来像原则，但本质上是在减少 AI 写代码时最常见的失控点。

2. 不只适用于 Claude Code，也照顾到不同使用场景

仓库不只是放了一份 CLAUDE.md，还把同样的思路整理成了多种可落地形式：

Claude Code 插件安装方式
按项目落地的 CLAUDE.md
Cursor 可直接使用的 .cursor/rules/karpathy-guidelines.mdc
可放进个人技能目录的 SKILL.md

也就是说，它不是“看完就结束”的经验贴，而是尽量把原则做成了能直接复制、安装和复用的东西。

3. 强调“让 AI 围绕成功标准工作”

我觉得这个项目最值得看的点，不是四条原则本身，而是它对任务表达方式的强调：

不要只说“修 bug”
不要只说“加校验”
不要只说“重构一下”

而是把这些话改成 AI 更容易闭环的目标，例如：

先写一个能复现问题的测试
再修改实现
最后以测试通过作为结束条件

这会明显降低“看起来做了很多，实际没有真正完成”的情况。

适合谁

这个项目比较适合下面几类人：

经常使用 Claude Code、Cursor 或其他 AI 编程助手的开发者
已经被 AI 的“自作主张”“过度发挥”“过度工程”折腾过的人
想给团队沉淀一套统一协作规则，而不是每次都临时口头提醒的人
希望把 AI 从“会写代码”进一步拉到“更稳、更可控、更贴近真实工程协作”的人

如果你已经有自己的项目规范，这个仓库也很适合当一个基础模板，再叠加你自己的技术栈要求。

快速上手

项目给了几种很直接的接入方式。

方式一：作为 Claude Code 插件安装

/plugin marketplace add forrestchang/andrej-karpathy-skills
/plugin install andrej-karpathy-skills@karpathy-skills

方式二：直接把 `CLAUDE.md` 放进项目里

新项目：

curl -o CLAUDE.md https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md

已有项目追加：

echo "" >> CLAUDE.md
curl https://raw.githubusercontent.com/forrestchang/andrej-karpathy-skills/main/CLAUDE.md >> CLAUDE.md

方式三：在 Cursor 中使用同样规则

仓库已经提供 .cursor/rules/karpathy-guidelines.mdc，把对应规则文件带进项目，就能把这套原则继续用在 Cursor 里。

结论

andrej-karpathy-skills 的亮点不在于“功能很多”，而在于它把 AI 编程里那些最容易踩坑的地方，整理成了一套足够简单、又能立刻落地的约束方式。

如果你已经在用 AI 写代码，这个项目值得看一遍；如果你已经被 AI 改坏过项目、写复杂过实现、或者因为没有明确验证目标而反复返工，那它的价值会更直接。

从定位上看，它更像一份高复用的协作说明书，而不是另一个新工具。但很多时候，真正缺的恰恰不是更多工具，而是一套更稳的工作方式。

DESIGN.md：给 AI 编程工具看的设计规范文件

Thu, 23 Apr 2026 09:57:00 +0800

一句话定位：DESIGN.md 是 Google Labs 推出的一份开放格式规范，用一个 DESIGN.md 文件同时承载机器可读的 design tokens 和人类可读的设计说明，让 AI 编程工具更稳定地理解界面风格。

基础信息卡片

项目名称：DESIGN.md
仓库地址：https://github.com/google-labs-code/design.md
规范文档：https://stitch.withgoogle.com/docs/design-md/specification
NPM 包：@google/design.md
命令入口：design.md
项目定位：A format specification for describing a visual identity to coding agents
开源协议：Apache-2.0
当前版本：0.1.1

解决什么问题

如果只是把一套颜色、字号、间距丢给 AI，它能读到值，但很难真正理解这套设计背后的意图。

比如下面这些问题，在实际使用 AI 生成页面时都很常见：

它知道主色是什么，却不知道什么场景才该用主色强调
它知道按钮圆角和字号，却不知道这套界面整体是偏克制、偏轻盈还是偏活泼
它能读到 token，却很难稳定理解组件语义、品牌气质和使用边界
换一个 Agent、换一次会话，生成出来的页面风格就开始漂

DESIGN.md 处理的，就是这类“有数值但没语境，有说明但不够结构化”的问题。

它的核心思路很直接：把精确 token 和设计说明放进同一个文件里，让机器和人看到的是同一份设计系统。

核心功能

1. 用 YAML Front Matter 描述机器可读 token

在 DESIGN.md 顶部，可以写结构化的设计 token，比如：

colors
typography
rounded
spacing
components

README 里的最小示例就是这样的：

---
name: Heritage
colors:
 primary: "#1A1C1E"
 secondary: "#6C7278"
 tertiary: "#B8422E"
 neutral: "#F7F5F2"
typography:
 h1:
 fontFamily: Public Sans
 fontSize: 3rem
rounded:
 sm: 4px
 md: 8px
spacing:
 sm: 8px
 md: 16px
---

这部分的价值很明确：AI 工具不需要再从一大段自然语言里猜颜色、字号和间距，而是可以直接读取确定值。

2. 用 Markdown Body 描述设计意图和使用方式

DESIGN.md 不只放 token，还要求在正文里继续写清楚：

整体风格和品牌气质
配色策略为什么这么定
排版该呈现什么感觉
组件应该怎么用
哪些做法应该避免

官方 spec 把这部分定义成标准章节顺序，常见包括：

Overview
Colors
Typography
Layout
Elevation & Depth
Shapes
Components
Do’s and Don’ts

这一步很关键，因为很多设计系统真正难传达的不是 token 本身，而是 token 背后的语义。

3. 允许 token 引用，方便形成完整系统

在 DESIGN.md 里，token 不只是散值，还支持引用关系，比如：

components:
 button-primary:
 backgroundColor: "{colors.tertiary}"
 textColor: "{colors.on-tertiary}"
 rounded: "{rounded.sm}"
 padding: 12px

这意味着它不只是在记录“颜色表”和“字号表”，而是在描述一个更完整的设计系统结构。

4. 自带 CLI 工具链，不只是文档格式

项目不只是定义格式，还提供了 CLI 能力。README 和包信息里已经给出了完整入口：

npx @google/design.md lint DESIGN.md
npx @google/design.md diff DESIGN.md DESIGN-v2.md
npx @google/design.md export --format tailwind DESIGN.md
npx @google/design.md spec

目前能直接看到的能力包括：

lint：校验结构、token 引用、颜色对比度等
diff：比较两个 DESIGN.md 的 token 和说明变化
export：导出到 Tailwind、DTCG 等格式
spec：输出完整规范内容，方便直接给 Agent 使用

也就是说，DESIGN.md 并不是“写一份规范给人看”就结束，而是可以真的进入工程流程。

5. 仓库已经给了完整示例，不只是抽象概念

这个仓库里已经带了多套示例设计系统，比如：

Atmospheric Glass
Paws & Paths
Totality Festival Design System

这些示例不是只写几行 token，而是把颜色、字体、圆角、组件配置和整套设计说明都写进了 DESIGN.md，很适合直接拿来理解它到底想解决什么问题。

适合谁

我觉得它尤其适合这几类团队：

已经让 AI 参与前端开发的团队
希望不同 Agent 在生成界面时尽量保持一致。
有设计系统，但信息散落在多个地方的团队
想把 token、组件规范、设计描述收拢到一个统一入口里。
设计和开发协作频繁的产品团队
既想让设计原则写得清楚，也想让工具链能直接消费。
想把设计系统接进工程流程的团队
需要 lint、diff、export 这类能力，而不只是一个静态文档。

如果只是做一两个简单页面，这套规范未必立刻体现价值；但只要项目开始强调品牌一致性、可维护性和 AI 生成稳定性，它的意义就会越来越明显。

快速上手

如果想最快感受 DESIGN.md 的方式，我建议按这条路径走：

第一步，先写一份最小 DESIGN.md

先不追求很全，只写最关键的部分：

colors
typography
spacing
Overview
Colors
Components

也就是先把“值”和“说明”最重要的部分补齐。

第二步，用 linter 检查结构

npx @google/design.md lint DESIGN.md

先确认：

格式是不是合法
token 引用有没有断掉
对比度是否合理
章节顺序是否符合规范

第三步，再接入自己的生成流程

如果你本来就在用 AI 生成页面、组件或者主题样式，那么可以把 DESIGN.md 当作稳定上下文的一部分，让它不只是看 prompt，而是真正理解你这套设计系统。

结论

DESIGN.md 最值得关注的地方，不是它把 design token 换了种写法，而是它把过去经常分散处理的几件事重新收拢到了一起：

机器要精确值
人要设计说明
团队要统一入口
工具链要可校验、可对比、可导出

从这个角度看，它更像是给“AI 参与前端和设计系统协作”补的一层基础设施。

如果后续更多 AI 编程工具开始支持这种格式，那么 DESIGN.md 很可能会变成设计系统和 Agent 之间一个很自然的中间层。

Browser Harness：让 AI 直接接管真实浏览器的轻量自愈执行层

Tue, 21 Apr 2026 00:50:08 +0800

如果你已经在用 Claude Code、Codex 这类 AI 编程助手，又希望它们能直接操作你的真实浏览器，那么 Browser Harness 是一个很值得关注的项目：它不是再套一层厚重框架，而是给模型一条直连 Chrome 的最短路径，并允许它在任务进行中自己补齐缺失能力。

一句话定位

Browser Harness 是一个面向 AI Agent 的轻量浏览器执行层，直接连接 Chrome DevTools Protocol，让模型在真实浏览器里完成任务，并能在执行过程中自我扩展能力。

基础信息卡片

字段	内容
项目名称	Browser Harness
GitHub	https://github.com/browser-use/browser-harness
官网/相关服务	https://cloud.browser-use.com
项目定位	面向 AI Agent 的轻量自愈浏览器执行层
核心能力	直连 CDP、真实浏览器控制、任务中补 helper、远程浏览器、多站点技能沉淀
开源协议	MIT
主要技术栈	Python
默认分支	main
适合搭配	Claude Code、Codex、Hermes 等 Agent 工具

说明：Star、Fork、Issue 数等活跃数据会持续变化，阅读时请以 GitHub 仓库实时信息为准。

解决什么问题

现在很多 AI 浏览器自动化方案都有一个共同问题：能力看起来很多，但真正落到复杂网页任务上，往往还是需要人为补脚本、补选择器、补边界处理。框架层越厚，模型离真实浏览器越远，遇到页面变化时就越容易卡住。

Browser Harness 想解决的就是这件事。

它的思路不是把浏览器操作封装成一套固定配方，而是尽量缩薄中间层，直接建立到 Chrome DevTools Protocol（CDP）的连接，把浏览器能力更直接地暴露给模型。这样当任务中途发现“当前 helper 不够用”时，模型不是立刻失败，而是可以直接改 harness 本身，把缺的函数补进去，再继续执行。

这也是它 README 里反复强调的关键词：self-healing。这里的“自愈”不是玄学，而是允许模型在执行过程中扩展工具本身，而不是永远被预设接口限制住。

核心功能

1. 直连 CDP，尽量减少中间抽象

项目最吸引人的一点，是它对“薄”这件事非常执着。

README 里直接把整体规模写得很透明：核心代码量大约只有 592 行 Python，主要由 run.py、helpers.py、admin.py、daemon.py 组成。它传递出的不是“大而全平台”的感觉，而是一个刻意保持轻量、方便被模型理解和修改的浏览器执行层。

对于 AI Agent 场景，这一点很关键。中间层越薄，模型越容易读懂当前工具到底能做什么、不能做什么，也越容易在任务失败时自己修。

2. 允许模型在任务中途补齐缺失能力

这个项目最有辨识度的地方，不是“能操作浏览器”，而是“能边做任务边长能力”。

README 里给了一个很直观的例子：当模型想上传文件时，如果 helpers.py 里还没有 upload_file()，它就直接把这个函数写进去，然后继续完成上传。

这意味着 Browser Harness 不是把模型当成一个只能调用固定 API 的操作者，而是把它当成一个既能执行任务、又能维护执行层的工程师。对于那些流程多变、网站细节又经常变化的场景，这种设计会比一套完全预定义的动作库更灵活。

3. 支持真实本地浏览器，也支持远程浏览器

从 install.md 和 SKILL.md 看，Browser Harness 的使用路径分成两类。

第一类是连接用户自己的真实 Chrome。它强调的是“直接接到你正在用的浏览器”，这样模型看到的就是你真实登录态、真实标签页和真实环境，更适合日常助理式操作。

第二类是远程浏览器。项目提供了 Browser Use cloud 这类远程能力，适合子代理并行执行，或者在无界面的服务器环境里运行。README 还明确提到免费层支持 3 个并发浏览器，不需要绑卡，这对做自动化实验或者多任务拆分来说门槛比较低。

4. 把经验沉淀成 domain skills

很多自动化项目把“经验”留在一次性脚本里，下一次重跑还得重新踩坑。Browser Harness 则明显想把这些网站级经验沉淀下来。

仓库里有 domain-skills/ 和 interaction-skills/ 两类知识：

domain-skills 更偏站点级任务经验，比如某个平台的页面结构、稳定选择器、交互细节
interaction-skills 更偏通用浏览器操作能力，比如下载、滚动、iframe、上传、弹窗等

更有意思的是，项目鼓励这些技能由 agent 在真实任务中自动生成，而不是手工拍脑袋编写。这个思路很符合 Agent 工具演进的方向：真正有价值的知识，不是事先想出来的，而是任务跑通之后沉淀下来的。

5. 对 Codex / Claude Code 的接入路径比较清晰

这个项目并不试图做一个封闭产品，而是很明显地在拥抱现有的 AI 编程助手工作流。

README 里直接给了面向 Claude Code 和 Codex 的 setup prompt；install.md 还专门说明了如何把它的 SKILL.md 注册到对应 agent 的全局技能目录中。换句话说，它不是让你额外学习一套新平台，而是把自己做成现有 Agent 工作流中的浏览器能力补丁。

这也是它容易传播的原因之一：对已经在用 Claude Code、Codex 的用户来说，上手心智负担很低。

适合谁

我觉得 Browser Harness 比较适合这几类人：

已经在使用 Claude Code、Codex、Hermes 这类 agent，希望把浏览器能力也接进来的人
经常要处理真实网页登录态、后台录入、上传下载、内容运营这类网页任务的人
想做更灵活的浏览器自动化，而不满足于固定脚本的人
想让多个子代理并行跑网页任务的人

如果你的目标只是做稳定、封闭、规则非常明确的网页测试，那么传统测试框架可能已经够用了。但如果你更在意“让模型自己理解页面、补工具、继续执行”，那 Browser Harness 的设计会更对路。

快速上手

按照项目文档，体验它的大致路径不复杂：

打开仓库，先看 install.md
克隆项目并安装为可全局调用的工具
让它连接到你的真实 Chrome，或配置远程浏览器
再读 SKILL.md，了解日常使用方式
从一个具体网页任务开始，让模型边做边学习

它的一个典型调用形态是：

通过 browser-harness 执行一段 Python
helpers 会预先导入
daemon 自动启动
模型根据任务不断调用、修改、补充 helper

如果你已经在自己的 AI 工作流里用了技能文件、任务脚本、子代理协作这些机制，那么 Browser Harness 基本能无缝接进去。

结论

Browser Harness 的价值，不在于它把浏览器自动化包装得多花哨，而在于它重新定义了 AI 操作浏览器时“工具应该长什么样”。

它足够轻，模型看得懂；它足够近，能直接碰到真实浏览器；它又足够开放，允许模型在任务执行过程中自己把工具补完整。这几件事叠在一起，才让它和传统“浏览器自动化脚本封装层”拉开了差异。

如果你最近正好在关注 AI Agent 如何真正落到网页任务、内容运营、后台操作、跨站点流程自动化这些场景，这个项目值得你专门花点时间看一遍。

我自己的判断是：它未必会成为所有人都用的浏览器方案，但它很可能会成为“AI 如何接管真实浏览器”这条路线里，一个非常有代表性的轻量实现。

Manifest：帮个人 AI Agent 降低模型成本的开源路由器

Mon, 20 Apr 2026 00:05:18 +0800

如果你已经开始长期使用 Hermes、OpenClaw 这类 AI Agent，很快就会遇到一个现实问题：模型能接很多，但成本不太好管。

很多时候，真正浪费钱的地方不是“模型太贵”，而是不同难度的请求都被发给了同一个模型。简单问题用了大模型，复杂任务又缺少稳定的回退链路，最后的结果往往是：钱花了不少，但整体调用方式并不精细。

Manifest 想解决的，就是这件事。

它不是再包一层模型接口，而是把 Agent 和模型提供方之间的“分发逻辑”单独做成一个开源路由层：根据请求复杂度自动选模型，在失败时自动 fallback，同时把 token、成本和耗时记录下来。

一句话定位

Manifest 是一个面向个人 AI Agent 的开源 LLM 路由层，能根据请求复杂度自动选择更合适、也更省钱的模型，把模型成本控制这件事从“手动切换”变成“默认发生”。

基础信息卡片

字段	内容
项目名称	Manifest
GitHub	https://github.com/mnfst/manifest
官网	https://manifest.build
项目定位	个人 AI Agent 的开源模型路由器
核心能力	智能路由、模型分层、自动回退、预算限制、成本与用量追踪
支持方式	Cloud 版本、Docker 自托管
开源协议	MIT
主要技术栈	TypeScript
适合搭配	Hermes、OpenClaw，以及其他自主 Agent 框架

说明：Star、Fork、活跃度这类数据会持续变化，阅读时请以 GitHub 仓库实时信息为准。

解决什么问题

现在很多 AI Agent 在调用模型时，常见做法其实比较粗暴：

要么所有请求都走同一个模型
要么手动在便宜模型和大模型之间来回切
要么把路由能力直接交给第三方代理平台

问题在于，Agent 的请求天然不是同一种难度。

有些只是简单问答，有些是多步推理，有些是代码、视觉、长上下文任务。如果所有请求都默认走高价模型，成本会很快失控；但如果一味追求低价模型，又会在关键任务上掉质量。

Manifest 想解决的，就是让个人 Agent 也能像成熟系统一样，根据请求复杂度自动选模型。

它的价值不在于“再包一层 API”，而在于把日常最费钱、也最容易被忽略的那一步做成基础设施：

简单请求走更快、更便宜的模型
复杂请求走更强的模型
某个模型失败时自动切到后备模型
全部调用过程都能在面板里看到成本、token、耗时和使用情况

如果你平时已经在用多个模型供应商，或者本身就有订阅型模型额度，这类路由层的价值会非常直观。

核心功能

1. 自动判断请求难度，再分配到合适模型

Manifest 的核心不是“模型聚合”，而是“模型分配”。

根据官方说明，它会在每次请求进入时做一次本地评分，并把请求划分到不同层级，例如 simple、standard、complex、reasoning，再路由到对应模型。

对个人用户来说，这件事最直接的意义是：

你不需要每次手动想“这一问值不值得上大模型”
Agent 也不必把所有任务都交给最贵的那一个
模型使用变得更像一个自动调度系统，而不是一个固定开关

真正影响长期成本的，往往不是你接了多少家，而是有没有把不同难度的请求分开处理。

2. 支持多层模型回退，不把稳定性压在单点上

除了选模型，Manifest 还强调 fallback。

你可以按层级设置多个候选模型。当首选模型异常、不可用或效果不理想时，请求可以继续回退到下一层备用模型，而不是整条链路直接中断。

这对 Agent 场景尤其重要，因为 Agent 一旦进入多轮任务，单次失败带来的损失往往不是“一次回答没出来”，而是整个流程被打断。

从产品角度看，Manifest 做的不是“给你更多模型”，而是把模型调用从“单点依赖”升级成“可调度、可容错的执行链路”。

3. 内置成本、token、时延追踪

很多人知道自己“模型费用越来越高”，但不知道高在哪。

Manifest 把这一层可视化做成了默认能力。根据官方资料，路由过程中会自动记录：

使用了哪个模型
消耗了多少 token
调用耗时多久
每次请求大概花了多少钱

这意味着你不只是“省钱”，而是能进一步看清：

哪类任务最消耗预算
哪些模型用得最多
哪个供应商性价比更高
哪些请求其实没必要走高阶模型

对于已经把 AI 工具纳入日常工作流的人，这类数据面板通常不是锦上添花，而是后续持续优化的前提。

4. 同时照顾云端使用和本地自托管

Manifest 目前提供两种典型使用方式：

直接使用官方 Cloud 版本
用 Docker 自托管部署

如果你更关注上手速度，Cloud 版本会更省事；如果你更关注控制权、链路透明度和本地数据边界，自托管会更有吸引力。

从官方文档和 About 页面可以看到，这个项目非常强调“个人可控”这件事。它把自己和传统第三方云代理服务做了明显区分：

开源
可自托管
路由逻辑透明
更强调个人 Agent 的使用场景

对很多重度用户来说，这种差异比“是否再多支持几家模型”更关键。

5. 对个人订阅和多供应商组合更友好

Manifest 一个比较有意思的点，是它不是只围绕 API Key 思路来设计。

官方资料里明确提到，它既支持连接多个主流模型提供方，也支持复用部分已经付费的订阅型入口。对于已经同时购买了不同模型服务的人，这会更容易把现有资源整合起来，而不是重新回到单一平台里重复付费。

如果你已经在 OpenAI、Anthropic、MiniMax、OpenRouter 或本地模型之间切换，这类统一路由层会比“再买一个聚合平台”更像真正可长期使用的基础设施。

适合谁

1. 已经在长期使用个人 AI Agent 的用户

如果你已经把 Hermes、OpenClaw，或者其他 Agent 工具接进自己的日常工作里，那 Manifest 的价值会非常直接。

因为你真正要解决的，不再是“能不能调用模型”，而是：

怎么控制长期成本
怎么避免每个任务都走高价模型
怎么在多个提供方之间保持灵活性

2. 同时在用多个模型供应商的人

如果你手里已经有多家 provider 的 API Key，或者本来就会混合使用不同模型，那你很容易遇到一个问题：模型很多，但调度很乱。

Manifest 更像是把这些分散资源收拢成一层统一入口，让调用逻辑变得更稳定、更有章法。

3. 想自托管 AI 基础设施的个人开发者

如果你不想把所有请求都放进第三方黑盒代理里，又希望保留完整的使用追踪、预算控制和回退能力，那这种可自托管的路由层很有吸引力。

它不是大而全的平台，而是一个比较清晰的中间层：只解决“请求该发给谁、怎么追踪、怎么控成本”这件事。

快速上手

Manifest 的上手路径并不复杂，重点是先把它放到 Agent 和模型提供方之间。

方式一：直接使用官方 Cloud

去官网注册后，把 Agent 的模型入口接到 Manifest，再把你已有的 provider 配进去，就可以开始使用它的自动路由能力。

适合想先验证效果、尽快体验的人。

方式二：Docker 自托管

官方目前主推 Docker 安装方式，自托管也是它比较明确的使用路线。

典型步骤可以理解为：

按官方安装脚本或 Docker 说明部署 Manifest
打开本地面板并创建管理员账号
配置模型提供方
设置不同复杂度层级对应的模型和 fallback
把 Agent 的请求入口切到 Manifest

完成后，后续大部分收益都会来自日常自动路由，而不是频繁手动切换模型。

结论

如果把 Manifest 看成一个“再包装一层模型接口”的项目，会低估它。

它真正有价值的地方在于：把个人 AI Agent 的模型调用，从静态选择变成动态调度。

这件事听起来不像生成式 AI 那么显眼，但对长期使用者非常实际：

成本更容易压住
模型使用更有层次
失败时不容易整条链路中断
后续还能基于真实用量继续优化

如果你已经开始认真使用个人 Agent，而不是偶尔玩一玩，那 Manifest 很值得看。

Superpowers：给 Claude Code、Codex、Cursor 装上一套更靠谱的开发方法论

Sat, 18 Apr 2026 23:55:00 +0800

如果你已经开始把 Claude Code、Codex、Cursor 这类 Coding Agent 放进日常开发流程里，应该很容易碰到一个共同问题：它们会写代码，但不一定总能按一个稳定、可复用、可验证的方式把项目往前推进。

很多时候，真正让人头疼的并不是“它写不出来”，而是：

需求还没聊清楚，它就先开工了；
方案还没定下来，代码已经改了一半；
任务拆得不够细，执行过程里来回返工；
测试和验证经常被放到最后，甚至被跳过；
一个阶段做完了，但缺少 review 和收尾动作。

Superpowers 想补的，就是这部分能力。

它不是新的大模型，也不是新的 AI IDE，而是一套面向 Coding Agent 的 skills 框架和软件开发方法论。简单理解，它更像是给已有 Agent 装上一套“先澄清需求、再拆计划、按 TDD 实现、过程中复查、最后收尾”的工作系统，让 AI 不只是会写代码，而是更像一个更有流程意识的工程助手。

一句话定位

Superpowers 是一套给 Coding Agent 使用的 skills 框架，通过把需求澄清、方案设计、任务拆解、测试驱动开发、代码评审和分支收尾串成标准流程，让 AI 编程从“会写代码”变成“会按工程流程做项目”。

基础信息卡片

字段	内容
项目名	Superpowers
仓库	https://github.com/obra/superpowers
作者 / 团队	Jesse Vincent / Prime Radiant
License	MIT
类型	Coding Agent 的 skills framework + software development methodology
支持对象	Claude Code、Codex CLI / App、Cursor、OpenCode、GitHub Copilot CLI、Gemini CLI
核心价值	给现有 Agent 补上更完整的软件开发流程

说明：Stars、Forks、更新频率等属于动态数据，发布后可能变化，请以 GitHub 页面实时信息为准。

解决什么问题

现在很多 Coding Agent 的问题不是“能力弱”，而是“过程容易飘”。

如果只是让它写几个函数、补一段脚本，这种问题还不明显；但一旦进入真实项目，问题会立刻放大。因为真实开发不是把代码写出来就结束，而是要经历需求确认、方案评估、任务拆解、实现、测试、复查、合并、收尾这一整条链路。

Superpowers 的思路，不是继续叠提示词，而是把软件开发里那些真正有价值的步骤做成一组可组合的 skills，再通过初始化指令把这些 skills 串起来，让 Agent 在不同阶段自动进入对应流程。

换句话说，它更像是在给 Coding Agent 补“工作方法”，而不是补“能力插件”。

核心功能

在具体展开之前，可以先看一下 Superpowers 想让 Coding Agent 走的一条典型开发路径：

flowchart LR
A[想法 / 需求] --> B[Brainstorming<br/>先把目标和边界聊清楚]
B --> C[设计确认<br/>分段展示并确认方案]
C --> D[Writing Plans<br/>拆成可执行的小任务]
D --> E[Subagent Driven Development<br/>把任务交给子代理推进]
E --> F[TDD + Code Review<br/>边实现边验证]
F --> G[Finishing Branch<br/>验证、收尾、合并]

这张图可以帮助快速理解它和普通“提示词包”的差别：Superpowers 想补的不是某一个单点能力，而是把需求澄清、计划拆解、执行、验证和收尾串成一条更完整的开发链路。

1. 先把需求聊清楚，而不是上来就写代码

Superpowers 的第一步不是直接生成代码，而是先进入 brainstorming 流程。

这个流程会围绕你的想法继续追问，把目标、边界、方案和取舍逐步聊清楚，然后把设计结果分段展示给你确认。这样做的好处非常直接：避免 Agent 一开始就基于错误理解往下写，后面越写越偏。

对于真实项目来说，这一步的价值往往比“多生成几十行代码”更大。

2. 先做计划，再做实现

当设计确认之后，Superpowers 会进入 writing-plans 流程，把接下来的工作拆成一批小任务。

这些任务不是“优化一下接口”“补一下前端”这种模糊描述，而是更偏可执行的工程任务，通常会包含：

明确的目标；
具体要改哪些文件；
需要实现什么内容；
如何验证是否完成。

这种拆法的意义在于，后续无论是人继续做，还是交给子代理去做，执行成本都会低很多，也更容易保持上下文稳定。

3. 把 TDD 变成默认流程

Superpowers 很强调 test-driven-development，也就是常说的 RED-GREEN-REFACTOR。

它的思路不是“有空再补测试”，而是要求：

先写失败的测试；
先看到测试失败；
再写最小实现让测试通过；
最后重构整理。

这套要求对人来说并不新鲜，但放到 Coding Agent 场景下意义很大。因为很多 Agent 在没有约束时，天然会优先把“能跑的代码”写出来，而不是优先建立验证闭环。Superpowers 相当于给它加了一套明确的轨道，让实现更可控。

4. 支持子代理协作，不只靠一个 Agent 硬扛

Superpowers 里一个很有代表性的部分是 subagent-driven-development。

它不是让一个 Agent 在超长上下文里一直干到最后，而是把任务交给新的子代理分段完成，并且在过程中加入两轮检查：

先看是否符合规格；
再看代码质量是否过关。

这种方式更接近团队协作里的“执行 + review”，能减少上下文污染，也更适合较长链路的开发任务。对于复杂项目来说，这比单代理一路写到底更稳。

5. 把代码评审和收尾也纳入流程

很多工具会把重点放在“生成”上，但真正做项目，最后的检查和收尾同样重要。

Superpowers 把 requesting-code-review、finishing-a-development-branch 这类技能也放进了流程里。也就是说，它不只是关心“代码写出来了没”，还会把下面这些环节补上：

是否和原计划一致；
是否有严重问题阻断进度；
分支要继续保留、合并还是发 PR；
是否完成最终验证和清理。

这也是它和普通“提示词包”差别很大的地方：不是只管开始，而是把整个交付链路都考虑进去了。

适合谁

这个项目更适合下面这几类人：

第一类，是已经在日常开发里使用 Coding Agent 的工程师。如果你已经会把 Claude Code、Codex 或 Cursor 用在真实项目里，Superpowers 能帮你把“偶尔好用”变成“流程更稳定”。

第二类，是在团队里推动 AI 编程落地的人。很多团队最大的问题不是没人用 AI，而是每个人用法都不一样，结果不可复用。Superpowers 提供了一套更统一的工作方式，比较适合作为团队内部的约定参考。

第三类，是经常做中等复杂度项目的人。如果只是让 AI 写几个函数，这套流程可能显得稍微重一些；但一旦进入“要改多个文件、要做验证、要持续迭代”的项目场景，它的价值就会明显体现出来。

快速上手

Superpowers 的安装路径比较多，已经覆盖多个常见工具。

比如：

Claude Code 可以通过插件市场安装；
Codex CLI / App 可以在插件界面搜索安装；
Cursor 可以通过插件市场添加；
GitHub Copilot CLI、Gemini CLI 也都有对应安装方式。

安装完成后，它的关键点不是多出一个单独命令，而是把一套 skills 注入到现有 Coding Agent 的工作流里。也就是说，你原来怎么和 Agent 协作，现在大体上还是怎么协作，只是它在处理开发任务时会更主动地按流程推进。

如果你想先快速理解这个项目，最值得先看两部分：

README 里的 Basic Workflow；
skills 列表里和 brainstorming、writing-plans、test-driven-development、subagent-driven-development 相关的部分。

看完这几项，基本就能理解 Superpowers 的核心设计思路。

结论

Superpowers 不是另一个 Coding Agent，而是一套给 Coding Agent 使用的 skills 框架和开发方法论。

它真正吸引人的地方，不在于“能多做一件事”，而在于“让已经会做事的 Agent，用更靠谱的流程去做事”。

如果你对 AI 编程的期待，已经从“帮我写点代码”升级到“帮我把项目稳定推进下去”，那这个项目很值得认真看一眼。

fireworks-tech-graph 项目解析：把技术架构图生成这件事做成一个可复用 Skill

Wed, 15 Apr 2026 11:21:00 +0800

一句话定位

fireworks-tech-graph 是一个面向技术文档、AI/Agent 场景和 UML 制图需求的 Claude Code Skill，核心价值是：你只需要描述系统，它就能较稳定地生成可直接使用的 SVG + PNG 技术图。

基础信息卡片

字段	内容
项目名	fireworks-tech-graph
仓库	https://github.com/yizhiyanhua-ai/fireworks-tech-graph
License	MIT
类型	Claude Code Skill / 技术图生成 Skill
核心能力	将自然语言描述转成 SVG 技术图，并导出高分辨率 PNG
支持范围	7 种视觉风格、14 种图类型、完整 UML 支持、AI/Agent 常见图模式
依赖	`rsvg-convert`、Node.js、本地脚本工具链
核心场景	架构图、流程图、数据流图、Agent 图、记忆系统图、时序图、类图、ER 图等

说明：Stars、Forks、更新频率等属于动态数据，发布后可能变化，请以 GitHub 页面实时信息为准。

解决什么问题

很多人写技术文档时都会遇到一个很现实的问题：图很重要，但画图本身特别耗时间。

常见痛点通常有这几类：

脑子里已经有结构，但真正落到图里很慢；
Mermaid 适合快速表达，但视觉效果和复杂结构承载能力有限；
draw.io 这类工具虽然强，但手工拖拽成本高，不适合频繁改稿；
当图要服务于 AI、Agent、RAG、Memory 这类新领域时，通用绘图工具缺少现成语义。

fireworks-tech-graph 的价值主要体现在：

把“描述系统”直接转成“生成图”；
不只是出 SVG，还能直接导出适合博客、文档嵌入的 PNG；
对 AI/Agent 领域有明显偏向，很多图不是从零开始凑，而是带着领域结构理解去生成；
风格不是单一的，既能做文档风，也能做品牌感更强的展示风。

核心功能（按使用链路）

1) 输入描述层

它最直接的使用方式，不是让你先画框，而是让你先描述系统。

比如你可以直接说：

“画一张 Mem0 记忆架构图”
“生成一张多智能体协作图”
“画一张微服务架构图，蓝图风格”
“做一张 API integration flow，OpenAI 风格”

也就是说，它把“先想结构、再手动画图”的流程，改成了“先说需求、再自动出图”。

2) 图类型识别层

这个 Skill 不只是简单模板替换，它会先对用户描述做图类型归类。

仓库里明确支持的范围比较完整，包括：

架构图
数据流图
流程图
Agent 架构图
Memory 架构图
时序图
对比矩阵
时间线
思维导图
各类 UML 图
ER 图

这件事很关键，因为不同图类型，布局规则本来就不一样。比如架构图更强调层级，时序图更强调时间顺序，类图更强调关系和可读性。如果没有这一层分类，生成结果很容易只是“看起来像图”，但并不真正适合那个场景。

3) 风格系统层

这个项目另一个很明显的特点，是它不是只有一种统一画风，而是提供了 7 种视觉风格。

目前仓库里展示出来的风格包括：

扁平图标风
暗黑极客风
工程蓝图风
Notion 极简风
玻璃态卡片风
Claude 官方风格
OpenAI 官方风格

这意味着它不是只能拿来画“内部草图”，也可以直接服务不同类型的内容输出。

比如：

写博客、写文档，适合极简风或 Claude 风格；
做技术分享 PPT，可能更适合玻璃态或蓝图风；
做 AI 产品介绍图，OpenAI 风格和 Claude 风格会更容易形成统一视觉感。

4) 语义表达层

很多绘图工具的问题，不是画不出框，而是画出来之后“语义不够强”。

fireworks-tech-graph 在这方面做得更细，它不只是画节点和箭头，而是试图给不同对象赋予更明确的表达规则。

仓库里提到的设计包括：

不同类型节点对应不同形状；
箭头颜色和虚线样式可以表达读写、异步、循环等不同语义；
对 AI/Agent 场景里的常见组件有比较明确的形状词汇；
支持产品图标和品牌色体系。

这会直接影响图的阅读效率。

一张技术图真正有价值，不只是“好看”，而是别人一眼能看懂什么是核心组件、什么是数据流、什么是控制流、什么是外部依赖。

5) 输出与验证层

这个 Skill 不是只负责“生成一份 SVG 文本”，它还把输出链路补得比较完整。

仓库里提供了几个比较实用的脚本：

生成图
从模板生成起始 SVG
校验 SVG 语法
批量测试不同风格

同时它要求通过 rsvg-convert 导出 PNG，这一点很适合实际发布场景。

因为很多时候，SVG 更适合继续编辑，但真正发到博客、文档、知识库、PPT 里，PNG 往往更省事，也更稳定。

这意味着它更像一个“技术图生产工具链”，而不只是一个临时灵感型脚本。

适合谁

经常写技术博客、产品文档、方案文档的人；
经常需要画架构图、流程图、Agent 图，但又不想每次都手动画的人；
做 AI / Agent / RAG / Memory 相关内容输出的人；
希望把“描述需求 → 生成图 → 嵌入文章”这条链路尽量标准化的人。

快速上手（3步）

安装 Skill

npx skills add yizhiyanhua-ai/fireworks-tech-graph

安装导出依赖

macOS：

brew install librsvg

Ubuntu / Debian：

sudo apt install librsvg2-bin

直接用自然语言出图

例如：

“画一张微服务架构图，蓝图风格”
“生成一个多智能体协作图，玻璃态风格”
“画一张 Mem0 架构图，输出到 /tmp/diagrams/”

如果只是第一次体验，我会建议先从仓库 README 里已经给出的稳定 prompt 样例开始，这样更容易得到接近展示图的结果。

结论

如果只把 fireworks-tech-graph 看成一个“自动画图工具”，其实会低估它。

它更有意思的地方在于，它把技术图这件事，从一次性手工劳动，变成了一种可以沉淀、复用、批量生成的 Skill 能力。

尤其是在 AI / Agent 相关内容越来越多的背景下，很多图已经不是简单方框箭头，而是带有明显领域结构的表达需求。在这种情况下，一个既能理解图类型、又能提供风格系统、还能直接输出发布级 PNG 的 Skill，价值会比普通绘图模板更高。

如果你经常写架构说明、流程文章、项目分析，或者本身就在搭自己的 Claude Code Skill 体系，那 fireworks-tech-graph 是一个很值得试一下的项目。

从 OpenClaw 到 Hermes Agent：为什么我觉得它更懂你

Wed, 15 Apr 2026 08:25:09 +0800

这两天我把日常在用的 Agent，慢慢从 OpenClaw 切到了 Hermes Agent。

一开始我其实没有抱太高预期。因为这类 Agent 产品，最容易出现的情况就是：第一次上手很惊艳，但真正多用几轮之后，你会发现它们更像“会执行命令的聊天工具”。单次对话里看起来很聪明，但一旦上下文断开，很多东西就又回到了起点。你得重新交代偏好，重新说明习惯，重新告诉它哪些事情能做、哪些事情不要做。

但在实际用了 Hermes 一天之后，我对它的印象确实和一开始不太一样。

最直观的一点是，它不像一种“用完就走”的 Agent。相比我之前使用 OpenClaw 的感受，Hermes 更像是会持续积累上下文的助手。它不仅能记住一些长期偏好，还会把一些稳定的工作习惯、发布规则、表达方式、甚至你纠正过它的点，逐步沉淀下来。用得越久，这种差异会越明显。

简单说一句我的体会：目前体验下来，Hermes 确实比 OpenClaw 更“懂你”。

这篇文章我不打算写成功能罗列，而是结合我自己的上手过程，讲清楚三件事：

Hermes Agent 怎么安装
装完之后怎么配置，尤其是怎么把 Telegram 这一条链路跑通
为什么从长期使用体验看，Hermes 会比 OpenClaw 更容易形成“更懂你”的感觉

一、Hermes Agent 到底是什么

Hermes Agent 是 Nous Research 开源的一个通用 Agent 框架。它可以跑在终端里，也可以挂在 Telegram、Discord、Slack、WhatsApp、Signal 等消息平台上。你可以把它理解成一个“既能聊天，也能真正调用工具做事”的长期在线助手。

它和普通聊天机器人最大的区别，不只是能不能调用 shell、文件系统或者浏览器，而是它本身带了一套比较完整的长期能力：

一是持久化记忆。它会把你是谁、你偏好的沟通方式、你环境里的固定约束、你反复强调过的规则，拆分成用户画像和系统记忆，跨会话保留下来。

二是技能。不是每次都从零开始，而是可以把做成过的复杂流程沉淀成 skill，下次遇到类似任务时直接复用。

三是会话检索。以前聊过什么、做过什么、怎么修过某个问题，它能搜索历史会话，不需要你每次都从头复述背景。

所以它更像一个“越用越贴合你”的 Agent，而不是一次性工具。

二、怎么安装 Hermes Agent

Hermes 官方给出的安装方式很直接，Linux、macOS、WSL2 都可以直接走安装脚本。

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

安装完成后，一般重新加载一下 shell：

source ~/.bashrc

然后直接运行：

hermes

如果只是想先快速看看它能不能跑起来，这一步就够了。

官方仓库里给出的常用入口也比较清晰：

hermes
hermes model
hermes tools
hermes setup
hermes gateway
hermes claw migrate
hermes doctor

其中我建议第一次安装完，别急着自己手填配置，先跑一遍：

hermes setup

这个 setup 会比你手改配置省事很多。尤其是你后面还要接 Telegram，或者准备从 OpenClaw 迁移过来，这一步可以少踩不少坑。

三、Hermes 的配置文件大概长什么样

Hermes 的核心配置主要在两个地方：

~/.hermes/config.yaml
~/.hermes/.env

前者更偏“设置”，比如模型、工具、显示、memory、delegation 这些；后者更偏“密钥和环境变量”，比如各平台 token、API key、allowed users 等。

这点和很多项目一样，建议你也延续这个习惯：配置归配置，密钥归密钥。不要把 token、bot secret 之类的内容直接混到 config.yaml 里。

日常最常用的几个命令是：

hermes config edit
hermes config set
hermes model
hermes tools
hermes doctor

如果只是先用 CLI，其实配好模型就能开始了。但如果你希望它在消息平台上长期在线，那接下来就该配置 gateway。

四、怎么接入 Telegram

如果你只是想先把 Hermes 挂到一个最稳定、最容易用的平台上，我会推荐先接 Telegram。

原因很简单：配置链路短，生态成熟，BotFather 的体验也相对稳定，而且 Hermes 对 Telegram 的支持已经比较完整。

这一节不追求把所有参数讲全，而是先把 Telegram 消息收发链路跑通。等你确认这条链路稳定后，再回头补更细的策略配置，会更省时间。

1. 前置条件

在开始之前，最好先确认下面几件事：

你已经能在本机或服务器上正常运行 hermes
模型已经配置完成，CLI 模式下可以正常对话
你已经通过 BotFather 创建好 Telegram Bot
你知道自己的 Telegram 用户 ID，或者至少知道后面要限制哪些用户可以访问
你准备让 Hermes 长期在线，而不是只在当前终端里临时跑一下

如果前面这些还没准备好，不建议一上来就折腾 Telegram 端，不然很容易把“模型问题”和“消息平台问题”混在一起排错。

2. 最小可用配置

Hermes 这边 Telegram 的核心环境变量主要有这些：

TELEGRAM_BOT_TOKEN
TELEGRAM_ALLOWED_USERS
TELEGRAM_HOME_CHANNEL
TELEGRAM_HOME_CHANNEL_NAME
TELEGRAM_REPLY_TO_MODE

如果你只想先跑通，先关注下面几个配置项就够了：

TELEGRAM_BOT_TOKEN：这是入口。这个 token 去找 BotFather 创建机器人就能拿到，没有它就不可能接通 Telegram。
TELEGRAM_ALLOWED_USERS：非常建议一开始就配上。对于一个能调用终端、文件和各种工具的 Agent 来说，访问边界最好默认收紧，不要等跑通之后再补安全限制。
TELEGRAM_HOME_CHANNEL：这是给定时任务和默认投递用的。如果你后面想让 Hermes 发日报、巡检结果或者定时提醒，这个配置会直接决定它往哪里送消息。
TELEGRAM_REPLY_TO_MODE：影响的是回复体验。如果你在群聊里使用，或者你很在意消息线程关系，这个参数会明显影响观感。第一次配置时保守一点，用 first 就够了。

3. 启动与验证

配完环境变量之后，先直接启动 gateway：

hermes gateway run

如果你后面准备长期后台运行，也可以继续接：

hermes gateway install
hermes gateway start

验证时我更推荐用最简单的“三步法”：

看启动日志里有没有明显报错
在 Telegram 里给 Bot 发一条简单消息，比如“你好”
看 Hermes 是否能返回一条正常回复

只要这三步能闭环，基本就说明消息链路已经打通了。

4. 常见问题

Telegram 这一段虽然相对简单，但也有几个很典型的坑：

Bot token 配错：最常见，尤其是复制时多空格或漏字符
allowed users 没配对：表现为 Bot 在线，但你发消息它不理你
直接把群聊场景当成私聊场景来测：线程、reply 关系会更复杂
先在本地临时跑通，后面换到服务器后忘了同步环境变量

所以更稳妥的做法是：先在私聊里把最小闭环跑通，再逐步扩到群聊、线程和自动投递。

五、从技术架构上看，为什么 Hermes Agent 会更容易形成“更懂你”的体验

如果把“更懂你”理解成一句产品宣传语，这件事很容易说空。但从 Hermes Agent 的系统设计来看，它之所以更容易给人这种感觉，并不是因为某一轮回答突然更像人，而是因为它把“长期协作”这件事拆成了几层明确的技术结构。

换句话说，Hermes 不是只在做一个会聊天的 Agent，而是在做一套能够把“用户是谁、过去做过什么、哪些规则长期有效、哪些流程已经验证过”重新接回当前任务的执行系统。

先看一张结构图：

图里最关键的是这几层关系：用户画像、持久记忆、技能、历史会话召回，并不是孤立存在的，而是会在 Prompt Builder 和 Agent Loop 中被重新接回当前任务。工具执行后的结果也会继续回流，新的经验再写回记忆、技能和会话体系里。

这张图里最关键的一点是：Hermes 并不把所有信息都粗暴塞进一次对话上下文里，而是把“更懂你”拆成了几个不同的技术来源，再由 Prompt Builder 和 Agent Loop 在执行时重新组合。

所以它带来的体验不是“这一轮刚好猜对了”，而更像是“这次是在以前的基础上继续往下做”。

1. 它把长期信息拆成了不同层次，而不是全塞进一次对话上下文

很多 Agent 在实际使用里最大的问题，并不是模型不够强，而是所有信息都挤在当前会话里。

当前对话一长，上下文就会膨胀；开了新会话，很多信息又得重新说一遍；如果没有明确的持久层，所谓“记住你”其实只是“这轮还没忘”。

Hermes 在设计上把这件事拆开了：

用户画像
持久记忆
技能
历史会话检索

这几个层不是一回事。

用户画像更偏“你是谁、你习惯怎样工作”；持久记忆更偏“有哪些长期有效的稳定约束”；技能更偏“某类任务该怎么做”；历史会话检索则解决“以前到底聊过什么、做过什么”。

这种分层很关键，因为它避免了一个常见问题：把所有长期信息都粗暴塞进 prompt，结果越堆越乱，最后谁也不好用。

2. 它不是只会存信息，还会在合适的结构里使用这些信息

很多系统也能“记忆”，但记忆只是存起来，未必真的在后续任务里稳定起作用。

Hermes 的一个优势，是它把记忆和执行链路接得比较近。

比如：

用户偏好会在后续对话里直接影响表达方式
环境约束会影响工具选择
已经验证过的流程会沉淀成 skill，而不是每次重新推理
过去会话可以通过检索重新找回，而不是靠模型模糊回忆

也就是说，它不是把“记住”做成一个装饰层，而是把这些信息真正接进了后续决策里。

从技术角度看，这会直接影响使用体验：同样一个模型，如果每次都重新理解你，和它能够基于稳定信息继续往下做事，主观感受会差很多。

3. 技能机制让它能把“会做”变成“下次还会这么做”

Hermes 里我觉得非常重要的一点，是 skill 这一层。

因为很多 Agent 的问题并不是这次做不出来，而是下次遇到类似任务时，又要重新走一遍。之前踩过的坑、试过的方法、确认过的流程，并不会自然沉淀下来。

Hermes 的 skill 机制，本质上是在补这个缺口。

当一个复杂流程被验证可用之后，它可以被写成结构化技能。下次再遇到类似任务，系统不是“从头想一遍”，而是优先沿用已经跑通过的方法。

这种设计带来的结果，不只是效率更高，更重要的是风格和行为会更稳定。

用户会逐渐感受到：它不是这次碰巧做对，而是开始形成一种持续一致的工作方式。

4. 会话检索让“过去做过什么”不再只能靠模糊记忆

另一个很容易被忽略的点，是历史会话检索。

很多 Agent 系统一旦离开当前上下文，过去发生过的事基本就断掉了。哪怕它曾经帮你解决过类似问题，下一次也不一定能用上。

Hermes 在这里做得更实用一些。它不是假设模型天然会记住一切，而是提供会话搜索能力，把历史记录当成可召回的信息源。

这件事非常重要，因为“懂你”很多时候并不是人格化的感觉，而是它能不能重新找到以前与你相关的真实上下文。

如果它能找回：

你之前怎么定义一个问题
当时为什么选了某种方案
哪个约束是你反复强调过的
某个流程之前已经验证过

那它在下一次继续工作时，就更像是在延续关系，而不是重新开始。

5. 它的结构更强调长期协作，而不是单轮最优

如果只追求单轮回答漂亮，很多系统都能做得不错。

但长期使用时，真正重要的往往不是“这一轮说得有多好”，而是：

下一轮还能不能接上
过几天还能不能延续
新会话里还能不能保持一致
遇到相似任务时能不能少让用户重复自己

Hermes 的架构里，memory、skills、session search、cron、gateway 这些能力是互相连着的。

这意味着它不是单纯围绕一次回答来设计，而是更接近“长期在线、持续协作”的思路。

而一旦系统的目标从“回答一次”变成“陪你持续工作”，它在体验上就会更容易给人一种“越来越懂你”的感觉。

6. 所以这里的“更懂你”，本质上不是拟人化，而是系统工程结果

我现在更愿意把这件事理解成一个技术结果，而不是一句感受型判断。

Hermes 给人的“更懂你”，并不是因为它突然更会聊天，也不是因为它某一轮特别像人，而是因为它在系统层面做了几件更利于长期协作的事：

把长期信息分层保存
把记忆接入后续执行
用技能沉淀流程
用会话检索补足跨会话连续性
让 Agent 真正适合长期在线工作

这些能力叠在一起，最后才会表现成用户侧的那种主观感受：它好像越来越知道你要什么，也越来越少需要你反复解释同一件事。

六、最后

如果你只是想找一个“能调工具、能跑命令、能接平台”的 Agent，其实现在已经有不少选择。

但如果你在意的是另外一件事：这个 Agent 能不能越来越理解你的偏好、越来越贴合你的习惯、越来越不像一次性工具，那 Hermes 确实值得认真试一下。

至少就我目前这一天的体验来说，它已经给了我一个很明确的结论：

Hermes 不只是另一个 Agent。它更像是一个会持续积累、会慢慢记住你、也更可能在长期使用里形成默契的 Agent。

而这件事，恰恰是我现在最看重的。

Paseo 是什么？一个用来远程管理 coding agent 的开源项目

Tue, 14 Apr 2026 00:00:00 +0800

Paseo 不是新的大模型，也不是又一个“AI IDE”。如果非要给它找一个更准确的位置，我会觉得它更像是放在现有 coding agent 外面的一层管理与调度工具，用来把 Claude Code、Codex、OpenCode 这类东西统一起来，并且把使用场景从“只能坐在电脑前操作”，延伸到手机、桌面端、Web 和 CLI。

Paseo 想解决什么问题

如果你已经开始把 coding agent 放进日常工作流里，那你大概率会越来越熟悉一种状态：

本地终端里跑着一个 Claude Code
另一个窗口里挂着 Codex
远程机器上可能还跑着别的任务
人一离开电脑，整个跟进链路就断掉了

Paseo 处理的，基本就是这类问题。

它不是去替代这些 agent，而是给这些 agent 补上一层统一入口：你可以在不同设备上接入同一套工作流，查看任务进度、追加一句 follow-up、继续推进没有做完的事情，而不必总是守在那台启动任务的电脑前。

这里其实挺适合直接看一眼它的界面。只看文字不太容易形成感觉，但看到截图后就会明白，它想做的并不是一个聊天框，而更像一个围绕 agent 会话展开的工作台。

它和常见 AI 编程工具的区别

从产品形态上看，Paseo 最容易被注意到的点当然是“可以从手机上控制 coding agent”。这个卖点很直观，也确实很容易传播。

但如果只把它理解成“在手机上看 Claude Code”，其实还是有点低估它了。

我觉得它真正有意思的地方，不在手机，而在“统一管理”这件事。因为很多人现在缺的已经不是一个更强的模型，而是一个能把这些模型和 agent 会话接到一起的操作台。

当你只开一个 agent 时，这个需求并不明显；可一旦开始并行跑多个任务，问题就会很快出现：

哪个 agent 在做什么
哪个任务卡住了
哪个会话还需要补一句说明
哪个结果值得回来看一眼

这些事情如果都靠终端窗口和记忆去维护，其实非常容易乱。

Paseo 的价值，恰恰就在这里。它试图把原本散落在不同终端、不同机器、不同 provider 里的 agent，收拢成一个更容易管理的工作流。

Paseo 是怎么工作的

它的基本思路并不复杂：真正执行任务的环境还是你自己的机器，但会有一个统一层把这些 agent 管起来，然后再让手机、桌面端、Web、CLI 这些不同入口都能接上来。

这点我觉得挺关键。因为实际开发里，最难迁移的很多时候不是代码，而是环境。

你可以很容易复制仓库，但很难完全复制：

本地依赖
shell 配置
环境变量
已经调好的工具链
自己平时积累的脚本和习惯

Paseo 没有试图把这层问题抹平，而是承认一个更现实的前提：开发环境本来就是高度本地化的。既然这样，那不如让 agent 继续跑在你的机器上，再去解决“如何远程管理这台机器上的 agent”。

这也是为什么它看起来会比一些纯云端方案更实用一些。不是因为技术更炫，而是因为它更贴近真实开发场景。

为什么它适合多 agent 场景

从支持对象上看，Paseo 也不是围着单一 provider 打转。它重点接的是 Claude Code、Codex、OpenCode 这类 coding agent。这意味着它不是某一家的配套工具，而更像是一个上层管理面。

如果你的工作流本来就是混合的，比如：

用 Claude Code 做规划和讨论
用 Codex 跑实现
再让另一个 agent 做 review 或补测试

那你就会更容易理解这种统一入口的意义。

再看一张移动端预览图，会更明显一些。它想表达的并不是“把 IDE 缩小到手机里”，而是让你在离开电脑之后，依然能跟进 agent 的执行过程。

所以我会觉得，Paseo 真正切中的不是“AI 编程”里最热闹的那部分，而是一个更往后、更偏工作流的问题：

当 coding agent 开始真正参与开发流程之后，人和 agent 之间的协作方式应该怎么组织？

哪些人会更适合用它

以前写代码，很多时候是人盯着编辑器一点点敲；现在越来越像是人先下任务，再去看 agent 跑得怎么样；再往后一步，就会自然进入另一个问题：如果手上同时跑着多个 agent，会话、任务和进度应该怎么管理？

Paseo 给出的答案，大概就是做一个新的工作台。

这个工作台不一定非得是浏览器里的网页，也不一定非得是某个厂商的 IDE。它可以是你自己的机器上跑着 agent，再由不同设备去接入、查看和继续控制。

所以我觉得它更适合下面几类人：

已经稳定在用 Claude Code、Codex 或类似工具的人
经常并行跑多个 agent 任务的人
更愿意把 agent 跑在自己机器上的人
希望在离开电脑后还能继续跟进任务的人

如果你现在还是偶尔试一试 coding agent，那 Paseo 对你的帮助未必会立刻特别强；但如果你已经进入“多会话、多任务”的阶段，它的价值会更容易体现出来。

最后

它未必会立刻变成每个人都离不开的工具，但它提出的问题非常真实，而且很可能会越来越普遍。

如果你现在已经稳定在用 Claude Code、Codex 或其他 coding agent，那 Paseo 很值得看一眼。它也许不是那种“看完马上替换你所有工具”的项目，但至少它把一个越来越现实的需求，做成了一个相对完整的产品形态。

从公开信息看，它现在已经不是一个很早期的小 demo 了。仓库活跃度、产品形态和多端布局都已经比较完整，明显是在按一个长期项目持续推进。

所以如果你最近也在关注 AI 编程工具，我会觉得 Paseo 是一个值得单独花点时间了解的项目。不是因为它又造了一个模型，而是因为它在试图回答：

当 coding agent 越来越像“长期协作对象”时，我们该怎么管理它们？

这件事，比单纯讨论哪个模型更强，可能更值得看。

项目地址：

官网：https://paseo.sh
GitHub：https://github.com/getpaseo/paseo
Docs：https://paseo.sh/docs

让 AI 代理接管所有软件：CLI-Anything 项目分析

Thu, 12 Mar 2026 22:30:00 +0800

如果你最近在做 AI Agent 落地，大概率已经遇到同一个问题：Agent 会“思考”，但不会稳定地“操作软件”。

CLI-Anything 这类项目的价值，就在于把“软件操作能力”从 GUI 点击变成可组合、可测试、可自动化的命令行能力。

一句话定位

CLI-Anything 是一个把任意软件“Agent-Native 化”的方案：通过生成结构化 CLI，让 AI 代理可以稳定调用真实软件能力，而不是依赖脆弱的 UI 自动化。

基础信息卡片

字段	内容
项目名	CLI-Anything
仓库	https://github.com/HKUDS/CLI-Anything
License	Apache-2.0
技术栈	Python（插件与命令体系）
运行形态	Claude Code 插件 + OpenCode 命令 + Codex Skill
核心场景	把现有软件能力封装为 Agent 可调用 CLI

注：Stars/Forks、支持平台与命令细节会持续变化，发布时请以 GitHub 仓库最新 README 为准。

解决什么问题

传统 Agent 集成软件通常有三条路：

GUI 自动化（截图+点击）——脆弱、难维护。
直接 API 调用——接口分散、业务语义弱。
重写一层工具——成本高、功能覆盖不足。

CLI-Anything 选择的是第 4 条： 直接把目标软件转成结构化 CLI 接口，让 Agent 通过命令行完成操作，且支持 JSON 输出、测试验证与持续迭代。

核心功能（按业务链路）

1）一键生成 CLI（7 阶段流程）

项目强调“分析→设计→实现→测试计划→测试实现→文档→发布”的完整流程，目标不是 demo，而是可长期维护的 CLI Harness。

2）多代理平台接入

README 中已给出 Claude Code、OpenCode、Codex 的接入路径，降低了平台切换成本。

3）结构化输出（Agent 友好）

支持 JSON 输出，便于 Agent 消费结果并进入下一步工具链。

4）支持 refine 迭代

不只“首次生成”，还支持按功能方向持续补齐能力，适合长期演进。

5）强调测试与可验证性

项目突出测试覆盖与端到端验证，这是和很多“只会生成脚手架”的工具拉开差距的关键点。

适合谁 / 不适合谁

适合谁

正在搭建 Agent 工作流的开发团队。
需要让 Agent 可靠调用已有软件（而非重写软件）的场景。
对“稳定性、可测试、可维护”有要求的工程化团队。

不适合谁

只做一次性 PoC，不打算维护 CLI 层的人。
目标软件本身无可访问代码或运行边界极其受限的场景。
希望零配置“马上全自动生产可用”的用户（仍需工程判断与迭代）。

快速上手（3步）

选定平台（Claude Code / OpenCode / Codex）并安装对应插件/命令。
对目标软件执行 CLI 生成命令（如 /cli-anything ...）。
先跑基础命令与测试，再用 refine 持续补齐高频业务能力。

优缺点（客观）

优点

把 Agent-软件集成从“UI 脚本”升级为“CLI 工程”。
有完整方法论与跨平台接入路径。
可扩展、可测试、可持续迭代。

潜在限制

对目标软件结构与可调用边界有一定要求。
初次落地仍需要工程师参与规则定义与质量把关。
在超复杂软件上，自动生成能力与人工补齐仍需结合。

可变现方向（若你想做产品化）

企业 Agent 接入服务：把存量软件批量 Agent-Native 化。
行业 CLI 能力市场：沉淀可复用的垂直软件 CLI 模块。
Agent 工程平台：结合评测、回归测试、监控做完整交付。

结论

CLI-Anything 的核心价值，不是“又一个 AI 工具”，而是它抓住了 Agent 落地最难的一段： 让 Agent 稳定、可验证地使用真实软件能力。

如果你在做 Agent 工程化，这个项目值得重点关注，尤其适合作为“软件接入层”的基础设施参考。

一个命令找到适合你硬件的大模型：llmfit 项目介绍

Thu, 12 Mar 2026 21:35:00 +0800

在本地跑大模型时，最常见的问题不是“模型不够多”，而是“我这台机器到底跑哪个最合适”。llmfit 就是专门解决这个问题的工具。

一句话定位

llmfit 是一个根据你本机硬件（CPU/GPU/内存）自动评估并推荐可运行模型的终端工具，帮你快速找到“跑得动、速度可接受、效果还不错”的那一档模型。

基础信息卡片

字段	内容
项目名	llmfit
仓库	https://github.com/AlexsJones/llmfit
License	MIT
技术栈	Rust
运行形态	TUI（默认）+ CLI + HTTP API
核心场景	本地模型选型、硬件适配、节点调度前置评估
配套生态	支持 Ollama / llama.cpp / MLX 等本地运行时

注：Star、Fork、版本与支持模型数量会动态变化，发布时请以 GitHub 仓库实时数据为准。

解决什么问题

很多人会遇到这几类问题：

模型一大堆，不知道哪一个在自己机器上“真正可用”。
只看参数规模容易踩坑，显存、量化、上下文长度和速度经常互相打架。
换一台机器或换一个运行时（如 Ollama/llama.cpp）后，需要重做一遍选型。

llmfit 的价值是把这些评估动作标准化：自动探测硬件 → 计算适配度 → 输出可执行建议。

核心功能（按业务链路）

1）硬件探测

自动读取 CPU、RAM、GPU/VRAM、后端信息（如 CUDA/Metal/ROCm 等），形成可计算的资源画像。

2）模型适配评分

对模型做多维评分（质量、速度、适配度、上下文），并结合 use case（如 coding/chat/reasoning）给出综合排序。

3）量化与可运行路径判断

不是只判断“能不能跑”，而是进一步建议更合理的量化与运行方式（GPU、CPU offload、CPU-only）。

4）三种输出形态

TUI：适合交互式筛选。
CLI：适合脚本化调用。
API（serve）：适合做调度系统或多节点选型服务。

适合谁 / 不适合谁

适合谁

本地部署 LLM 的开发者与技术团队。
经常在不同机器上做模型评估的人。
需要把“模型选型”流程自动化的平台团队。

不适合谁

只想用云端托管模型，不关心本地硬件适配的人。
完全不做技术配置、只追求开箱即聊的普通用户。

快速上手（3步）

安装工具（例如 Homebrew / Scoop / 安装脚本，具体以仓库 README 最新说明为准）。
运行 llmfit 进入 TUI，看本机可运行模型排序。
用 llmfit recommend --json 输出推荐结果，接入脚本或自动化流程。

优缺点（客观）

优点

把“硬件-模型匹配”这件事做成了可重复流程。
同时支持交互式和自动化场景（TUI + CLI + API）。
对本地运行时生态友好，实战价值高。

可能的限制

评分与速度估算本质是模型化估算，不等于你业务里的真实端到端延迟。
某些硬件检测依赖系统命令，环境异常时可能需要手动覆盖参数。
对新型号 GPU 或新模型格式的支持节奏受项目迭代影响。

可变现方向（若你想做产品化）

团队版模型选型平台：把评估结果做成可视化看板与审批流程。
企业节点调度服务：利用 serve 接口做多机房/多节点调度。
咨询与交付服务：为企业提供“本地 LLM 基础设施选型 + 落地优化”。

结论

如果你经常遇到“模型很多但不知道选哪个”的问题，llmfit 是一个值得放进工具箱的项目。

它不能替代业务压测，但能显著减少你在模型初筛阶段的试错成本，尤其适合做本地 LLM 的第一轮决策。

mem9 平台介绍：和本地 memory 对比后，你就知道它值不值得上

Wed, 11 Mar 2026 23:58:00 +0800

如果你已经在用 Agent，最现实的问题其实不是“模型够不够聪明”，而是：

它能不能记住你，而且明天还记得。

所以这篇不先讲概念，先讲你最关心的：

mem9 和本地 memory 到底差在哪；
为什么它能跨设备共享记忆；
它在 OpenClaw 里是怎么工作的。

官网：https://mem9.ai/

一、先看核心：mem9 vs 本地 memory

维度	本地 memory（`memory/*.md`）	mem9
持久性	有，但依赖本机文件	有，云端持久化
跨设备	需要手动同步（git/rsync/迁移）	天然支持，同一 space 即可
检索方式	主要靠人工翻文件/关键词	关键词 + 语义混合检索
多 Agent 协作	容易各写各的、难统一	同一记忆空间可共享
透明可审计	强（文件可直接看）	可查，但更多依赖工具接口
运维复杂度	低（文件即可）	中（需配置后端与密钥）
Token 成本	低到中（看你贴多少上下文）	中（检索/注入会增加一些）

一句话总结：

本地 memory 更像“你的工作日志”；
mem9 更像“Agent 可实时调用的长期大脑”。

如果你只有单机、单会话、低频使用，本地文件足够。如果你要跨设备、多会话、多 Agent 协作，mem9 的收益会很明显。

二、为什么 mem9 能跨设备共享记忆？

因为它不是把记忆存你本地，而是存到远端记忆空间（space）里。

你在 A 设备写入一条偏好，B 设备只要连到同一个 space，就能读到同一份记忆。

这就是它和“本地 markdown 文件”的本质区别：

本地文件：默认跟着机器走；
mem9：默认跟着你的 space 走。

三、再看场景：什么时候你会真正感知到价值？

场景 1：长期偏好不想重复说

比如：发布前先确认、默认 private、安全脱敏规则。

这类规则每天重讲会很烦。mem9 适合把它们沉淀为长期可检索记忆。

场景 2：多端切换不想断上下文

电脑、手机、不同会话来回切时，记忆还能延续，不用每次从零开始。

场景 3：多个 Agent 分工协作

内容、发布、运营各用一个 Agent 时，记忆不再是孤岛。

四、它在 OpenClaw 里是怎么实现的？

用最实在的话讲，就是三步：

把 OpenClaw 的 memory slot 切到 mem9；
通过统一工具接口读写记忆（store/search/get/update/delete）；
在对话流程中按需检索并注入相关记忆。

重点不在“多了个插件”，而在于：

记忆从“笔记文件”变成“可调用的数据层”；
检索从“硬关键词”升级为“关键词 + 语义”；
会话重置后也能接上历史上下文。

五、你该怎么选：不是二选一，而是分层

更推荐的做法是组合，而不是替代：

本地 memory：保留过程记录、人工审计、长期归档；
mem9：承接运行时检索、跨设备共享、跨 Agent 协作。

这样你既有可追溯的“日志层”，也有高可用的“记忆服务层”。

六、真实代价也要讲清楚

mem9 不会魔法般“零成本”带来收益。

你要承担的主要成本：

检索与注入会增加一些 token；
需要做记忆治理（删噪声、保高价值）；
需要管理好 space/memory 相关密钥与权限。

但如果你已经进入长期使用阶段，这些成本通常小于“反复补上下文”的隐性成本。

七、如何安装到 OpenClaw（官方推荐路径）

安装建议按官方文档来，最稳妥的一句话是：

阅读 https://mem9.ai/SKILL.md ，按照说明为 OpenClaw 安装并配置 mem9。

结论

如果你只是偶尔聊两句，本地 memory 足够。

如果你要的是“长期可用、跨设备共享、多人/多 Agent 协作”的 Agent 系统， mem9 基本是从好用到可用的分水岭。

MediaCrawler 项目解析：多平台自媒体数据采集的工程化方案

Wed, 11 Mar 2026 22:50:00 +0800

一句话定位

MediaCrawler 是一个面向多平台自媒体公开数据采集的开源工程化项目，核心优势是“多平台支持 + Playwright 登录态方案 + 相对低门槛上手”。

基础信息卡片

字段	内容
项目名	MediaCrawler
仓库	https://github.com/NanmiCoder/MediaCrawler
License	Other / NOASSERTION（以仓库当前 LICENSE 为准）
技术栈	Python + Playwright + Node.js（部分平台依赖）
运行形态	CLI 为主，支持 WebUI/API 方式启动
核心场景	多平台公开内容抓取（搜索、详情、评论、创作者主页等）

说明：Stars / Forks / 语言占比等属于动态数据，发布后可能变化，请以 GitHub 页面实时信息为准。

解决什么问题

在做自媒体数据分析时，常见痛点是：

各平台接口与抓取方式差异大，维护成本高；
登录、签名、会话管理复杂，新手上手门槛高；
数据采集与存储流程缺少统一规范。

MediaCrawler 的价值主要体现在：

一套工程覆盖多个主流平台；
利用浏览器自动化和登录态缓存降低逆向复杂度；
提供较完整的数据导出与存储路径（CSV/JSON/SQLite/MySQL 等）。

核心功能（按业务链路）

1) 采集入口层

支持关键词搜索、指定内容 ID 抓取、评论抓取等模式；
提供多平台统一命令参数入口。

2) 登录与会话层

基于 Playwright 保留登录态；
通过浏览器上下文减少复杂签名逆向门槛。

3) 数据处理与存储层

支持多种存储格式（结构化落盘）；
便于后续清洗、分析、可视化或报表自动化。

4) 运行与运维层

支持 CLI 跑批；
可通过 WebUI / API 方式进行可视化操作与服务化部署。

适合谁 / 不适合谁

适合谁

需要做多平台内容数据监测与分析的团队；
想系统学习“可维护爬虫工程”而不是单脚本的人；
需要把抓取流程接入数据分析或业务系统的人。

不适合谁

只想零配置、零维护直接产出稳定商业数据；
不具备基础开发与环境运维能力；
忽略合规边界、希望“无限抓取”的场景。

快速上手（3步）

阅读文档并确认本地依赖（Python、Node.js、Playwright）；
按官方方式初始化环境并安装依赖；
先用单平台小范围验证（少量关键词 / 指定内容 ID），确认流程后再扩展。

优缺点（客观）

优点

多平台覆盖度高，功能完整度不错；
社区活跃度高，文档与使用示例相对丰富；
工程化程度优于很多“单文件脚本式”爬虫项目。

缺点

平台策略变化快，长期维护成本客观存在；
环境依赖较多，初次部署对新手不算轻；
涉及明显的合规与平台条款风险，不能忽视。

可变现方向（若适用）

行业数据服务：提供特定垂类的舆情/内容监测报告；
企业内部情报系统：做竞品内容追踪与选题辅助；
咨询与交付：为中小团队做采集+清洗+分析一体化部署；
自动化运营插件：围绕数据看板、告警、定时报表形成产品化能力。

结论

MediaCrawler 是一个值得研究的“多平台采集工程样本”，在学习价值和实战能力上都不错；但它不是“无风险数据提款机”，在法律合规、平台规则、运行维护上都需要长期投入。

建议：先做低频、低规模、合规优先的 PoC，再决定是否纳入正式生产链路。

Hermes Agent 项目解析：一个能持续学习的开源 AI Agent 框架

Wed, 11 Mar 2026 19:10:00 +0800

一句话定位

Hermes Agent 是一个“可持续学习”的开源 AI Agent 框架：它不仅能调用工具执行任务，还强调跨会话记忆、技能沉淀与自动化调度，适合做长期运行的个人或团队智能助理。

基础信息卡片

字段	内容
项目名	Hermes Agent
仓库	https://github.com/NousResearch/hermes-agent
License	MIT
技术栈	以 Python 为主（配合 CLI/Gateway 生态能力）
运行形态	CLI + Gateway（可接入 Telegram/Discord/Slack/WhatsApp/Signal 等）
核心场景	多渠道消息接入、任务执行、跨会话记忆、自动化定时任务

说明：Stars / Forks / 语言占比属于动态数据，发布后可能变化，请以 GitHub 页面实时数据为准。

解决什么问题

很多 AI 工具的问题是：

只会“回答”，不会“稳定执行”；
会话一断就丢上下文，长期协作能力差；
多平台、多工具之间割裂，运维成本高。

Hermes Agent 的价值在于把这些问题放进一个统一框架里：

统一入口（聊天平台 + CLI）；
统一执行（工具调用 + 子代理并行）；
统一沉淀（记忆 + 技能 + 搜索历史）；
统一调度（cron 自动化）。

核心功能（按业务链路）

1) 接入层：多渠道统一收口

支持 Telegram、Discord、Slack、WhatsApp、Signal 等渠道；
用户从任意入口发起请求，后端统一处理。

2) 执行层：工具调用 + 并行协作

支持工具调用与工作流执行；
可用子代理并行处理复杂任务，减少串行等待。

3) 记忆层：跨会话长期记忆

支持跨会话记忆与检索；
强调“从历史经验中学习”，让 agent 越用越贴近用户。

4) 自动化层：内置定时任务

可做日报、巡检、备份、审计等周期任务；
配合消息渠道可直接推送执行结果。

5) 部署层：从低成本到高性能可扩展

可跑在本地、VPS、容器或云环境；
对“长期在线、可远程访问”的个人助理场景友好。

适合谁 / 不适合谁

适合谁

想把 AI 从“聊天助手”升级为“执行助手”的个人开发者；
需要跨平台消息接入和自动化运营的团队；
对“长期记忆 + 任务闭环 + 可运维”有明确需求的人。

不适合谁

只需要一个简单网页聊天框、没有自动化诉求；
对本地环境、部署维护完全不想投入；
追求零配置、零学习成本的用户。

快速上手（3步）

打开项目仓库并阅读文档：
- GitHub: https://github.com/NousResearch/hermes-agent
- Docs: https://hermes-agent.nousresearch.com/docs/
按官方安装脚本完成本地安装与初始配置；
先从单一渠道 + 一个具体自动化任务开始验证（例如日报/监控提醒）。

优缺点（客观）

优点

多渠道 + 多能力一体化，体系完整；
强调长期记忆与技能沉淀，适合持续使用；
MIT 开源许可，对商业化探索友好。

缺点

功能面较宽，新手上手存在学习曲线；
真实生产可用性高度依赖你的配置质量与运维习惯；
多组件协作时，排障复杂度会高于“单点工具”。

可变现方向（若适用）

企业私有化部署服务：给中小团队做“可执行 AI 助理”交付；
行业模板包：如客服、运营、舆情、销售跟进等垂直工作流模板；
托管运维服务：按月提供 agent 托管、巡检、日志分析与优化；
培训与咨询：围绕“从聊天到执行”的落地方法论做培训营。

结论

如果你希望的是“能长期干活、可记忆、可自动化、可运营”的 Agent 系统，Hermes Agent 值得重点关注；如果你只要轻量对话入口，它可能会显得“能力过剩”。

建议：先做一个 7 天小闭环试运行（单渠道 + 单任务 + 可量化指标），再决定是否全面引入。

GEO SEO 新方向实战项目：geo-seo-claude（Claude Code 技能体系）

Tue, 10 Mar 2026 19:30:00 +0800

仓库：https://github.com/zubair-trabzada/geo-seo-claude

一句话定位

geo-seo-claude 是一个把 GEO（Generative Engine Optimization）方法论产品化 的 Claude Code 技能包：用一套可执行命令，完成 AI 搜索可见性审计、评分和交付报告。

基础信息卡片

字段	内容
项目名	geo-seo-claude
仓库	zubair-trabzada/geo-seo-claude
License	MIT
主要技术栈	Python + Claude Code Skills + 子代理（subagents）+ Schema 模板
运行形态	本地命令驱动（`/geo ...`）+ 报告导出（Markdown / PDF）
核心场景	面向 ChatGPT / Claude / Perplexity / Gemini / Google AI Overviews 的站点可见性优化
当前热度（动态）	Stars 约 1.1k，Fork 约 200+

注：Stars / Forks /语言占比等为动态数据，实际请以 GitHub 页面实时显示为准。

解决什么问题

传统 SEO 更关注“搜索引擎结果页排名”；而这个项目切的是“AI 引擎引用与推荐”的新路径，核心解决三个现实问题：

内容是否具备 AI 引用价值（citability）
AI crawler 是否能正常访问你的网站
品牌在 AI 常引用平台上的信号是否足够强

如果你是做内容增长、SaaS 增长或代运营服务，这三点都直接影响未来自然流量质量。

核心功能（按业务链路）

1) 快速体检与全量审计

/geo quick <url>：快速快照（短时间判断是否值得深入）
/geo audit <url>：全量审计（并行子代理分析）

2) 关键维度专项分析

/geo citability <url>：AI 可引用性评分
/geo crawlers <url>：robots.txt 与 AI 爬虫可达性
/geo llmstxt <url>：llms.txt 分析/生成
/geo brands <url>：品牌提及与平台信号
/geo schema <url>：结构化数据分析与建议
/geo technical <url>：技术 SEO 基础健康度
/geo content <url>：内容质量与 E-E-A-T 维度

3) 交付导向输出

/geo report <url>：Markdown 报告
/geo report-pdf：可交付给客户的 PDF 报告

这点很关键：它不是只给“诊断结论”，而是尽量往“可交付、可服务化”方向靠。

适合谁 / 不适合谁

适合

GEO/SEO 服务商（需要规模化做审计和交付）
内容团队与增长团队（要优先级清单和可执行建议）
SaaS / 本地商业 / 电商项目（重视 AI 搜索曝光）

不太适合

只想做一次性轻量 SEO 检查的个人站
没有 Claude Code 使用场景的团队
完全不做内容更新、只靠广告投放的短期项目

快速上手（3步）

第 1 步：安装

curl -fsSL https://raw.githubusercontent.com/zubair-trabzada/geo-seo-claude/main/install.sh | bash

第 2 步：跑一次审计

/geo audit https://your-domain.com

第 3 步：先做“低成本高收益”改动

优先执行：

crawler 可达性修复
可引用内容块改写（问答式、事实密度、可独立引用）
关键页面 schema 补齐

优缺点（客观）

优点

结构完整：从诊断到报告的闭环很清晰
指令化强：团队可复用，便于流程标准化
场景新：紧贴 AI 搜索流量迁移趋势

潜在不足

结论可靠性受外部环境与采样策略影响，仍需人工复核
指标体系偏方法论导向，不同品类需二次调参
对团队执行力有要求：拿到报告不等于拿到结果

可变现方向

如果你做服务，这个项目可直接用作 GEO 服务中台：

审计服务包：按站点规模报价（基础版/深度版）
月度优化陪跑：围绕内容与技术改造做连续迭代
行业模板化方案：SaaS / 本地商业 / 电商的垂类打法
培训产品化：企业内训 + SOP 文档 + 周报机制

结论

geo-seo-claude 值得关注的点，不是“它是不是万能”，而是它把 GEO 从概念变成了可执行流程。对于想尽早卡位 AI 搜索流量的团队来说，它是一个非常好的起步框架；真正拉开差距的，仍然是后续持续优化能力。

OpenClaw Skills 去哪找？我常用的 6 个渠道与实用命令

Tue, 10 Mar 2026 12:50:00 +0800

很多人开始用 OpenClaw 后都会遇到同一个问题：

我知道它很强，但到底去哪里找好用的 skills？

这篇给你一套实战版答案：去哪里找、怎么判断值不值得用、怎么避免装了一堆却不好用。

先说结论：优先顺序

我建议按这个顺序找：

ClawHub / skills.sh / SkillHub.club / 腾讯 SkillHub（中文）→ 官方 docs → GitHub 实现 → 社区案例。

原因很简单：

ClawHub 适合快速发现；
官方 docs 适合确认规范与兼容性；
GitHub 适合看真实代码质量；
社区适合看“别人正在怎么用”。

1) ClawHub：最快发现可用技能

这个是小龙虾作者开发和维护的 OpenClaw Skills 官方站点。

入口：https://clawhub.ai

适合场景：

你已经有明确问题（如：内容发布、SEO、部署、运营巡检）；
你希望先拿一个能跑通的版本，再逐步优化。

建议用法：

先按“任务目标”搜，不要先按技术名词搜；
看 skill 描述是否包含你的输入/输出；
看是否有明确边界（比如只做分析，不做外发）。

2) skillhub.club

这个站点更偏本土化，适配中国用户使用习惯，全中文界面，还提供小红书等本土平台专属技能。

它的特点主要有：

下载体验更顺畅：依托国内 CDN 高速镜像节点，技能安装更快；
资源兼顾量与质：既有大量 AI Skills，也有 TOP50 精选榜单；
覆盖场景更全：整合运营、开发、办公、创作、搜索等多领域技能；
生态联动较强：深度对接 ClawHub、GitHub 等生态，还能连接超 100 个主流 API。

3) skills.sh

Vercel 官方推出的 Skill 资源平台，提供一键安装功能，支持多 Agent 平台。网站设有排行榜和趋势榜，可以快速发现热门 Skill，适合需要快速获取高质量 Skill 的用户。

4) GitHub：看代码质量和维护活跃度

可以直接找到 skill 对应的 GitHub 仓库，看 star 数量和活跃度。

判断一个 skill 是否靠谱，建议看这 5 点：

是否有清晰的 SKILL.md 描述（输入、输出、限制）；
最近是否有维护（提交时间与 issue 响应）；
是否有最小可运行示例；
是否声明风险（比如涉及外发、删除、抓取）；
是否方便你做二次定制。

5) 社区：找“活用范式”而不是只看功能列表

Discord 社区：https://discord.com/invite/clawd

社区最有价值的不是“有这个 skill”，而是：

别人如何把多个 skill 串成工作流；
常见失败点是什么；
在真实业务里如何做降级与兜底。

不要“按名字装”，要“按问题选”

很多人踩坑的原因是：

看名字觉得很强就装；
结果输入不匹配、输出不可用、流程不闭环。

更稳的方式是先回答这 4 个问题：

我到底要自动化哪一步？
输入是什么，输出要给谁？
失败后影响多大，能否回滚？
这个能力是一次性需求，还是高频需求？

这 4 个问题想清楚，选 skill 的准确率会明显提高。

一个可复制的选型流程（实战）

第一步：先找 3 个候选

从 ClawHub / GitHub 各找一批候选，保留 3 个最相关的。

第二步：做 10 分钟“最小验证”

只跑最小任务：

输入 1 条真实数据；
看输出是否可直接进入下一步；
记录是否有副作用（误发、误删、格式错乱等）。

第三步：只保留 1 个主方案

不要并行长期保留多个同类 skill，避免冲突和维护成本。

常见误区（提前避坑）

误区：装得越多越强

现实：越多越容易冲突，触发路径更复杂。

误区：先追“最火”

现实：最火不一定最适合你的业务闭环。

误区：忽视权限边界

现实：涉及外发、删除、发布的 skill 必须先做确认机制。

给新手的一条简单策略

如果你刚起步，先只做这三类：

信息检索类（找资料、汇总）；
内容整理类（改写、结构化）；
低风险自动化类（构建、检查、报表）。

先跑通一个小闭环，再逐步扩展到发布、部署、跨渠道协同。

结语

找 OpenClaw skills 的核心不是“哪里最多”，而是：

能不能稳定解决你的真实问题。

从问题出发，用最小验证筛掉噪声，你的技能库会更轻、更稳，也更容易长期维护。

AiToEarn：多平台内容增长与变现一体化工具

Tue, 10 Mar 2026 12:00:00 +0800

项目地址：https://github.com/yikart/AiToEarn?tab=readme-ov-file

1) 一句话定位

AiToEarn 是一个面向内容营销场景的开源 AI Agent 平台，主打“创作—分发—互动—变现”的一体化流程。

2) 基础信息卡片

项目名：AiToEarn
仓库：yikart/AiToEarn
License：MIT
技术栈（README披露）：Node.js（推荐 Node 20.18.x）、Docker Compose、MongoDB、Redis
运行形态：Web + 后端服务 + 渠道服务（可 Docker 一键启动）
核心场景：多平台内容发布、互动运营、数据分析、AI 辅助运营

3) 这个项目在解决什么问题？

如果你做过内容运营，大概率会遇到这些痛点：

同一内容要分发多个平台，重复劳动重
评论和私信线索容易漏，转化效率不稳定
数据散落在各平台，复盘困难

AiToEarn 的思路是：把“内容生产 + 渠道分发 + 互动转化 + 数据复盘”收敛到一个系统里，尽量减少人工切换与重复操作。

4) 核心功能（按业务链路看）

4.1 内容分发

多平台分发（国内外平台组合）
日历式发布管理
历史内容导入与二次分发

4.2 热点与选题

热点案例库
话题发现能力

4.3 互动与线索

评论搜索与筛选
高意向信号识别（如“怎么买”“求链接”）

4.4 数据分析

跨平台数据对比
内容效果追踪与增长复盘

4.5 AI Agent

文档里强调了 Agent 辅助运营能力
目标是让 AI 不只“写文案”，还参与执行链路

5) 适合谁用 / 不适合谁

适合

多平台运营的内容团队
做出海内容分发的个人或小团队
想做“内容自动化 SaaS”二次开发的开发者

不太适合

只运营单一平台且流程很轻的账号
完全不需要自动化和数据分析的小体量场景

6) 快速上手（开发者版）

README 给出的最短路径是 Docker：

git clone 项目
复制 .env 并配置密码/密钥
docker compose up -d

启动后可直接访问前端与 API 服务，快速验证核心链路。

7) 优缺点（客观视角）

优势

场景聚焦：围绕“内容增长”全链路设计
工程可落地：提供 Docker 化启动方案
开源可改造：适合二次开发与私有部署

挑战

多平台适配本身复杂，维护成本高
平台规则变化快，长期稳定性要持续投入
对运营方法论依赖较强，工具不能替代策略

8) 可变现方向（如果你要借鉴）

基于这个方向，能做的商业化路径包括：

托管部署服务：帮团队低门槛上线
行业模板包：按垂直行业交付预设流程
代运营增强工具：评论线索、跟进、报表自动化
企业版能力：权限、审计、团队协作、SLA

9) 结论

AiToEarn 值得关注，不在于“功能多”，而在于它切中了一个真实需求：

内容增长已经从“单点创作”进入“流程竞争”。

如果你在做 AI + 内容营销，这类“可执行工作流”的项目，比单纯的文案工具更有长期价值。

OpenClaw 介绍：把 AI 变成真正能干活的个人助理

Tue, 10 Mar 2026 09:00:00 +0800

OpenClaw 是什么？

OpenClaw 是一个面向个人与团队的 AI Agent 平台。

它不只是“会聊天”的 AI，而是可以连接你的常用工具，真正执行任务：

回消息、整理信息
控制浏览器完成网页操作
调用本地脚本与命令
接入 Telegram / WhatsApp 等消息渠道
通过技能（Skills）扩展专业能力

简单说：让 AI 从“回答问题”进化到“帮你做事”。

它解决了什么问题？

很多时候我们并不缺一个会回答问题的模型，而是缺一个能持续执行任务的“数字助理”。

OpenClaw 的价值在于：

统一入口：通过消息就能下达任务，不用来回切工具
执行闭环：从理解需求到执行动作再到反馈结果
可持续协作：把重复工作流程化，减少手工操作

典型使用场景

内容创作：收集素材、整理提纲、发布前检查
运维与开发：执行脚本、检查服务状态、更新文档
个人效率：日程提醒、消息整理、待办追踪
业务自动化：线索跟进、表单处理、日报生成

为什么值得尝试？

如果你已经在用各种 AI 工具，那么 OpenClaw 能把它们“串起来”：

让能力从单点工具变成工作流
把临时操作沉淀成可复用流程
让你把时间花在更有价值的事情上

一句话总结

OpenClaw = 能连接工具、可执行任务、可持续协作的 AI 助理框架。

如果你希望 AI 真正参与日常工作，而不只是当问答机器人，OpenClaw 是一条非常值得走的路线。

OpenClaw、ZeroClaw、NanoClaw 以及云端 Claw 平台怎么选：一篇给普通人的实用指南

Sun, 08 Mar 2026 12:30:00 +0800

最近一段时间，Claw 类智能体工具越来越多。有人关注 OpenClaw 这样的开源生态型方案，也有人开始尝试 ZeroClaw、NanoClaw 这类更轻量、更可控的自托管路线。同时，腾讯云等云厂商也在推出更易用的智能体平台，让普通用户和业务团队不用自己搭底层系统就能快速上手。

但问题也随之而来：这些工具看起来都能做智能体，普通人到底该怎么选？

这篇文章不打算再花太多篇幅解释 Claw 到底是什么了。毕竟现在大家都在养虾，多少都已经见过这类“能接模型、能调工具、还能帮你干活”的系统。真正值得讲清楚的，不是谁功能最多，而是哪条路线更适合你。

我的核心结论很简单：

想最快上手、最少折腾，优先看云端平台
想要生态活跃、玩法多、适合个人开发，优先看 OpenClaw
想轻量自托管、长期运行，优先看 ZeroClaw
想自己完全掌控系统复杂度，优先看 NanoClaw

如果你只想先看结果，到这里已经够用了。下面再把原因讲透。

为什么 Claw 工具现在反而更难选了

难选的根本原因，不是名字太多，而是这些工具走的根本不是一条路线。

有些方案是本地生态优先，强调插件、社区、玩法和扩展能力；有些方案是轻量部署优先，强调资源占用、隔离边界和长期运行；还有一些则直接把重点放在云端托管、团队协作和业务接入上。

官方宣传通常会强调功能，但普通用户真正关心的问题其实很朴素：

难不难装
难不难配
贵不贵
会不会把自己折腾进运维坑
数据能不能留在本地

所以这篇文章的判断标准也很明确：不比参数堆料，主要看易用性、成本、安全边界、扩展性和适用对象。

先把 Claw 分成 3 类

1. 本地生态型

代表方案：OpenClaw

这一类工具通常有几个明显特征：

社区活跃，资料多，教程也多
可接的能力多，玩法丰富，上手反馈快
很适合个人开发者和喜欢尝鲜的人

它的优点很明显。你想快速体验一个“能跑起来”的智能体系统，通常这类工具最容易给你成就感。很多时候不是它最轻，也不是它最稳，但它往往是最好开始的。

代价也很现实。功能越多，系统边界通常就越大，权限、升级、兼容性和安全配置也更容易变复杂。如果你只是想稳定放在某台机器上长期跑，本地生态型方案未必是最省心的。

2. 轻量自托管型

代表方案：ZeroClaw、NanoClaw

这一类方案的共同点，是尽量把系统做得更轻、更清晰、更可控。

相比生态型工具，它们通常不会把“什么都能接”放在第一位，而是更强调：

部署简单
资源占用低
运行边界清晰
长期维护成本可控

其中，ZeroClaw 更适合偏生产环境、自托管和长期运行场景。它更像是一条“我想把这东西稳定放在服务器、NAS 或边缘设备上持续跑”的路线。

NanoClaw 则更偏向另一种思路：系统尽可能小，源码尽可能容易读懂和改造。它不是为了给所有人提供最多现成功能，而是为了让技术用户能快速掌控整个系统。

3. 云端平台型

代表方案：腾讯云智能体/Agent 平台，以及其他云厂商提供的智能体开发平台

这类方案最核心的卖点，就是省掉大量基础设施工作。

你不需要先部署服务，不需要先管节点、容器、反向代理、权限隔离、升级策略，也不一定要自己从零拼接工作流。对很多普通用户、小团队、业务团队来说，这一点比“是否完全可控”更重要。

云端平台的典型优势是：

开箱即用
模板和集成通常更多
团队协作更方便
从验证想法到上线业务更快

它的代价通常有三类：

长期成本依赖调用量
平台规则和能力边界受厂商影响
数据边界和生态绑定需要提前评估

普通人真正该怎么选

这一部分我直接给结论。

如果你是普通用户

如果你的核心目标是“先用起来”，那就不要先折腾服务器。

对大多数普通用户来说，云端平台通常是更合理的起点。你不需要研究太多底层架构，也不用先补齐运维知识。只要平台的文档清楚、模板够用、接入流程顺，你就能更快判断这类工具到底值不值得继续投入。

这里最容易犯的错误，是一上来就追求“最强方案”。但普通用户真正需要的，往往不是最强，而是最稳定、最容易持续使用的方案。

如果你是个人开发者

个人开发者一般有三种典型诉求：

想快速试各种能力和玩法
想把系统长期跑在自己的机器或小服务器上
想自己改，甚至想完全掌控整个实现

如果你偏第一种，优先看 OpenClaw。它更适合快速验证想法，也更容易接触到丰富的社区经验。

如果你偏第二种，优先看 ZeroClaw。它更适合轻量、稳定、长期运行，不容易把你拖进过重的系统负担。

如果你偏第三种，NanoClaw 会更有吸引力。它不一定最省事，但更适合技术型用户按自己的方式裁剪和改造。

如果你是小团队或企业

小团队和企业做选型时，第一问题其实不是功能，而是数据边界。

如果公司数据可以上云，而且你们的目标是先完成业务验证，那么腾讯云这类云端平台通常是效率更高的路线。它能让团队更快做出可演示、可试用、可验证价值的 Agent 应用。

如果数据不能上云，或者你们明确需要私有化、边缘部署、长期稳定运行，那么就应该优先考虑 ZeroClaw 这类更偏自托管和生产部署的路线。

至于 NanoClaw，它更适合有较强工程能力、希望最小化系统复杂度、并且愿意自己承担更多工程实现工作的团队。

一张表看懂四类方案

维度	OpenClaw	ZeroClaw	NanoClaw	腾讯云等云端平台
上手难度	中	中	中到高	低
部署方式	本地/自托管	本地/自托管	本地/容器优先	云端托管
易用性	强	中上	中	很强
资源占用	中到高	低	低	本地压力低
安全边界	依赖版本和配置	相对清晰	更强调最小化	依赖平台能力和配置
生态与模板	强	中	较弱	强
自定义能力	强	强	强，但更工程化	中到强，取决于平台开放度
运维成本	中到高	中	中	低
长期成本	低到中	低到中	低到中	中到高
适合谁	尝鲜者、个人开发者	自托管、生产部署	技术型用户、小团队	普通用户、业务团队

如果你更在意“开箱即用”，表里最值得看的其实是上手难度、易用性和运维成本。

如果你更在意“长期可控”，那就重点看安全边界、部署方式和长期成本。

每一种路线，分别适合什么人

OpenClaw：适合“先跑起来，再逐步扩展”的人

OpenClaw 的优势通常不在于最轻，而在于最容易形成正反馈。

你能快速把一个可用系统搭起来，也更容易从社区里找到示例、教程、模板和排错经验。对于个人开发者、内容创作者、独立产品尝试者来说，这种“先能跑，再优化”的体验非常重要。

但它的问题也同样明显：随着功能和集成能力越来越多，系统复杂度往往会上升。你需要更关注版本变化、权限配置、依赖更新以及升级策略。它适合快试、快做、快扩展，但未必天然适合所有长期稳定部署场景。

ZeroClaw：适合“想稳、想省资源、想长期运行”的人

ZeroClaw 的核心卖点是轻量和可控。

如果你希望把系统长期放在自己的服务器、NAS、家用设备或者边缘节点上稳定运行，那么这类方案往往更有吸引力。它不一定有最花哨的生态，但通常能给你更可预测的部署体验和更清晰的运行边界。

对于工程读者来说，它更像是一条偏生产环境的路线：不是为了玩具化体验，而是为了在成本、资源和可维护性之间取得平衡。

NanoClaw：适合“想尽量简单、想完全掌控”的人

NanoClaw 更像是极简主义路线。

它适合那些不想要一个“大而全”平台，而是更想得到一个“小而清晰”基础骨架的人。对于能读源码、愿意自己加功能、也愿意自己承担维护责任的工程师或小团队来说，这种方案很有吸引力。

它的优势是结构简单、改造直接、理解成本低。它的不足也很直接：生态、模板和开箱即用能力，通常不如更成熟、更重的项目。

腾讯云等云端平台：适合“先用起来，再决定要不要自建”的人

云端平台的最大优势，不是绝对性能，而是效率。

如果你是业务团队、产品经理、运营人员，或者是没有专门基础设施能力的小团队，那么云端平台通常是最省时间的路线。它特别适合做业务验证、内部助手、知识库问答、流程连接、客服类 Agent 这类场景。

如果你的目标是尽快接企业知识库、流程系统、客服系统或者内部服务，云端平台通常能让你少走很多基础设施弯路。

但一定要单独评估两件事：

长期成本是否可接受
平台绑定是否会影响未来迁移

很多团队前期上云很顺，真正开始扩量后，才发现成本和边界才是后半程的关键变量。

普通人最容易忽略的 5 个坑

1. 把“功能多”误当成“更适合自己”

功能多不一定是好事。功能越多，学习成本和配置复杂度通常也越高。很多人最后不是输在不会用 AI，而是输在系统太重，根本懒得继续维护。

2. 只看演示，不看部署和维护

演示视频里三分钟跑通，不代表你自己部署也能三分钟跑通。真正应该看的是：

有没有清晰文档
有没有现成模板
遇到问题有没有明确排错路径

3. 只看首月成本，不看长期成本

自托管看起来便宜，但需要你自己负责维护。云端平台上手很快，但调用量增长后，成本不一定比自托管低。

选型时最好把“未来三个月到一年”的使用量和维护投入一起算，而不是只看第一周能不能免费跑起来。

4. 忽略数据边界

如果系统会接入公司文档、客户资料、代码仓库或者业务数据，那么“能不能上云”往往比“功能是否更多”更重要。这个问题应该在一开始问，而不是等系统接好以后再问。

5. 忽略安全和版本问题

Claw/Agent 类系统天然拥有更高权限。它们可能会读文件、执行脚本、连接内部系统，风险并不等同于普通聊天工具。

所以选型时最好明确看三件事：

项目是否持续维护
升级路径是否清楚
权限和安全说明是否明确

可以直接照抄的选型结论

如果你只需要一句话版本，可以直接这么记：

想最快上手、资料多、社区活跃：选 OpenClaw
想轻量自托管、长期稳定运行：选 ZeroClaw
想系统尽量简单、自己可控：选 NanoClaw
想低门槛、少运维、快速落地：选腾讯云等云端平台

如果你更喜欢按场景来判断，可以直接这样看：

普通用户：优先云端平台
个人开发者：优先 OpenClaw
想低资源部署：优先 ZeroClaw
想深度改造：优先 NanoClaw
企业业务验证：优先云端平台
企业私有化和长期生产部署：优先轻量自托管路线

最后一句

不存在适合所有人的 Claw。

真正好的选型，不是追求功能最多，而是选择最符合自己成本、安全边界和维护能力的方案。对大多数普通人来说，先从易用的云端平台开始，再决定是否迁移到本地或自托管，通常是更稳妥的路径。

如果你已经很明确自己会长期使用、需要更强控制力、或者数据不能上云，那就不要被“开箱即用”迷惑，直接看轻量自托管路线，反而更省时间。

告别"上下文爆炸"：AI Skills 带来的上下文管理革命

Mon, 19 Jan 2026 00:00:00 +0800

在 AI Agent（智能体）的开发中，我们经常面临一个两难困境：想让 AI 处理复杂的项目，必须提供足够的信息；但如果把整个项目代码或数据库都塞进 Prompt，不仅 Token 费用惊人，还会迅速撑爆模型的上下文窗口（Context Window），导致 AI “变笨"或遗忘。

Skills（技能）正是为了解决这个问题而生。它不仅仅是给 AI 装上双手，更重要的是给 AI 一个“按需索取"的过滤器，让 AI 能够主动检索、精准操作，而不是被动接收海量数据。

1. 核心痛点：为什么我们需要 Skills 来省 Token？

传统模式：Context Stuffing（上下文填充）

在没有 Skills 之前，如果你想让 AI 修复一个 Bug，你可能需要把整个文件夹的代码复制粘贴给它。

后果：

费用高：输入 10 万行代码可能消耗几十美元
效果差：大量无关信息（噪音）干扰 AI 的注意力，导致幻觉
不可行：如果你的数据库有 1TB 数据，你根本无法塞进 Prompt

进化模式：Skills（动态检索）

有了 Skills，AI 变身为一个"主动调查员”。它不再被动接收庞大的数据投喂，而是拥有了检索工具。

场景对比：

假设你要在一个包含 1000 个文件的项目中找一个变量定义的错误。

没有 Skills：你需要把 1000 个文件全部喂给 AI（Token 爆炸）
有 Skills（如 grep_search, read_file）：
1. AI 思考：“我需要先找一下这个变量在哪里”
2. AI 调用 grep_search Skill → 消耗极少 Token
3. Skills 返回 3 个相关文件路径
4. AI 调用 read_file 只读取这 3 个文件 → 只消耗这 3 个文件的 Token
5. AI 解决问题

结论：Skills 将"全量数据处理"变成了"精准数据交互”，Token 消耗可能降低 90% 以上。

2. 图解：Skills 如何优化 Token 流量

我们可以通过数据流向图来直观对比：

graph TD
subgraph "传统方式: 上下文填充"
DB[整个数据库/所有代码] -->|全部通过 Context 传输 (巨大 Token 消耗)| LLM1[AI 模型]
LLM1 -->|处理过载| Result1[结果: 往往不准确]
end
subgraph "新方式: Skills 动态检索"
LLM2[AI 模型] -->|1. 仅发送查询指令 (极小 Token)| Skill[Skill: 搜索/查询]
DB2[整个数据库/所有代码] -- 过滤 --> Skill
Skill -->|2. 仅返回相关的那几行数据 (少量 Token)| LLM2
LLM2 -->|精准处理| Result2[结果: 精准且便宜]
end
style DB fill:#ffcccc
style DB2 fill:#ccffcc
style Skill fill:#ffffcc

3. Skills 的三大核心优势

除了降低 Token，Skills 还有什么不可替代的优点？

优势一：无限的"虚拟上下文"（Infinite Context）

这是 Skills 最大的优点。虽然现在的模型（如 Claude 3、GPT-4）支持 128k 甚至更多上下文，但依然有限。通过 Skills（如数据库查询、搜索引擎、文件系统访问），AI 实际上连接到了无限的外部存储。AI 不需要"记住"所有维基百科的内容，它只需要"拥有"搜索维基百科的 Skill。

优势二：数据的实时性（Freshness）

大模型的知识是静止的（训练截止日期）。Skills 是动态的。

例子：模型不知道今天英伟达的股价，但 fetch_stock_price Skill 知道
价值：让 AI 从"历史学家"变成了"实时分析师"

优势三：副作用与行动力（Agency）

这是从"读"到"写"的跨越。Skills 允许 AI 对现实世界产生影响（Side Effects）。

不仅仅是建议代码，而是直接 write_file 到磁盘
不仅仅是写邮件草稿，而是通过 API send_email 发送出去

4. 总结

Skills 的引入，本质上是一场**“上下文管理的革命”**。

它不再强迫用户去"筛选信息"喂给 AI，而是把这个筛选的权利交给了 AI 自己。

以前：用户手动从海量数据中人肉检索 → 喂给 AI → AI 处理
现在：用户给指令 → AI 利用 Skills 低成本试错、检索、验证 → AI 解决问题

这不仅让 AI 变得更聪明（拥有实时数据和行动力），更关键的是，它让复杂的 AI 应用在**成本（Token）和规模（上下文长度）**上变得真正可行。

随着开源 Skills 生态系统的不断成熟，我们有理由相信，未来的 AI Agent 将更加智能、高效，能够处理更复杂的任务，同时保持合理的成本。

收集Vibe Coding 的AI工具集合

Thu, 08 Jan 2026 00:00:00 +0800

日常开发中已经离不开AI工具，我创建了一个GitHub仓库，用于收集Vibe Coding 的AI工具集合，欢迎大家一起维护，目前收集的工具如下：

Vibe Coding AI Tools

免费体验 Google AI 图片生成神器：Nano Banana Pro 完整教程

Sun, 30 Nov 2025 00:00:00 +0800

简介

Google Cloud Platform (GCP) 为新用户提供了 300 美元的免费试用额度，可以用来体验各种 Google Cloud 服务。本文将详细介绍如何利用这个免费试用额度来使用 Google AI Studio 中的 Nano Banana Pro 模型。

Nano Banana Pro 是 Google 推出的轻量级 AI 模型，适合快速原型开发和实验。通过本文的步骤，你可以免费体验这个强大的 AI 模型。

前提条件

在开始之前，请确保你具备以下条件：

一个 Google 账号
一张有效的信用卡（用于验证身份，不会在免费试用期间扣费）
能够访问 Google Cloud Platform 和 Google AI Studio

详细步骤

步骤 1：访问 Google AI Studio

首先，访问 Google AI Studio，使用你的 Google 账号登录。

步骤 2：创建新项目并设置账单

在左侧导航栏中，点击 Dashboard
选择 Projects
点击 Create a New Project
输入项目名称（例如：Free300API）
点击 Setup billing 设置账单

步骤 3：填写信用卡以及地址信息

地区选择美国，通过用https://www.meiguodizhi.com/ 生成一个美国地址，然后填写到账单设置页面。在账单设置页面，填写你的信用卡信息。这是 Google 用于验证身份的方式，在免费试用期间（300 美元额度内）不会产生任何费用。

注意：确保你的信用卡信息正确，Google 可能会进行小额验证（通常会在验证后立即退还）。

步骤 4：启动免费试用

完成信用卡验证后，前往 Google Cloud Console
在控制台中，找到并点击 启动免费使用 或 Start Free Trial 按钮
确认激活 300 美元的免费试用额度

步骤 5：创建 API Key

返回 Google AI Studio
在左侧导航栏中，点击 Dashboard
选择 API Keys
点击 Create API Keys 创建新的 API 密钥
选择你刚才创建的项目（例如：Free300API）
复制生成的 API Key（请妥善保管，不要泄露）

步骤 6：在 Playground 中链接 API Key

在左侧导航栏中，点击 Playground
选择 Nano Banana Pro 模型
点击 Link API Keys 或 链接 API Keys
选择刚才创建的 API Key

步骤 7：开始使用 Nano Banana Pro

完成以上步骤后，你就可以在 Playground 中免费使用 Nano Banana Pro 模型了。你可以在输入框中输入提示词，与模型进行交互。

使用效果展示

以下是通过 Nano Banana Pro 生成的一些示例效果：

提示词：电影级史诗镜头，一名未来超级战士站在废墟中，全身正在被黑色的纳米液态金属迅速覆盖，六边形蜂巢结构的装甲正在自动组装与闭合，装甲缝隙中流动着高亮的青色能量电流，极其精细的机械纹理，微观视角下可见无数微小的纳米机器人在工作，体积光，火花飞溅，丁达尔效应，超写实，8k分辨率，虚幻引擎5渲染，压迫感，赛博朋克风格。

注意事项

免费额度限制：300 美元的免费试用额度通常有效期为 90 天，请在有效期内使用。
超出额度：如果超出免费额度，Google 会按照标准费率收费。建议在 Google Cloud Console 中设置预算提醒。
API Key 安全：请妥善保管你的 API Key，不要将其提交到公开的代码仓库中。
地区限制：某些地区可能无法使用 Google Cloud 服务，请确认你所在地区的可用性。

常见问题

Q: 免费试用期间会扣费吗？
A: 在 300 美元免费额度内不会扣费，但需要绑定信用卡进行身份验证。

Q: 免费试用额度用完后怎么办？
A: 你可以选择升级到付费账户继续使用，或者在 Google Cloud Console 中设置预算限制以避免意外费用。

Q: API Key 可以用于其他项目吗？
A: 可以，你可以在多个项目中使用同一个 API Key，但建议为不同项目创建不同的 API Key 以便管理。

总结

通过以上步骤，你可以轻松利用 GCP 的 300 美元免费试用额度来体验 Nano Banana Pro 模型。这是一个很好的机会来探索和测试 Google 的 AI 服务，而无需承担任何费用（在免费额度内）。

如果你在使用过程中遇到任何问题，可以参考 Google AI Studio 官方文档或 Google Cloud 支持中心。

参考资料

AI辅助开发小程序的实践分享

Wed, 26 Nov 2025 00:00:00 +0000

背景

没写过前端，只写过后端主要熟悉的语言是golang，完成这个小程序主要分为了以下几个阶段：

需求分析

通过 Google AI Studio 中的gemini进行规划进行需求分析以及列出详细的需求说明；这个小程序的主要功能主要是进行万能的记录类应用，同时我也给出了几个同类的APP让它进行分析；包括名字也是它给取的

最后得到如下的项目介绍，当然还有其他的一些项目的描述（这里没有记录下来）

# 星轨纪 (Star Trace)
> 记录点滴，看见轨迹 ✨
## 📖 项目理念
**星**：是您记录下的每一个数据点
**轨**：是时间将这些星点串联成的生命轨迹
**纪**：是我们为您铭记并呈现这一切
生命如繁星点点，每一次体重测量、每一粒服下的药丸、每一餐精心的饮食，都是您生命星图中闪烁的光点。时间如织，将这些星点串联成轨迹，勾勒出您的健康图景、生活节奏与成长轨迹。
**星轨纪** 是一个基于灵活事件模板系统的数据追踪微信小程序，致力于帮助您：
- 🌟 **记录每一颗星** - 轻松捕捉生活中的每个数据点
- 🛤️ **绘制生命轨迹** - 用时间串联起零散的记录
- 📚 **铭记成长历程** - 将数据转化为有意义的洞察
无论是健康管理、习惯养成，还是生活记录，星轨纪都能成为您忠实的数字伙伴。

AI编码

编码我用的是vscode 中的copilot；

为了能够让AI能够进行完全的全栈式的编写，后端也一起放在同一个仓库了，分为了backend和miniprogram目录。

我指定了技术栈，后端使用golang+gin+gorm的方式，前端使用tdesign库保证美观。


## 后端项目结构
backend/
├── cmd/ # 命令行工具
│ ├── server/ # API 服务器
│ ├── migrate/ # 数据库迁移
│ └── gen/ # GORM Gen 代码生成
├── pkg/ # 核心包
│ ├── handler/ # 请求处理器
│ ├── middleware/ # 中间件
│ ├── config/ # 配置管理
│ ├── db/ # 数据库连接和迁移
│ ├── models/ # 数据模型
│ ├── dal/ # 数据访问层（自动生成）
│ └── response/ # 统一响应格式
├── docs/ # 文档
├── scripts/ # 脚本文件
├── examples/ # 示例代码
├── Dockerfile # Docker 镜像构建
├── docker-compose.yml # Docker 编排
├── Makefile # 构建脚本
└── go.mod # Go 模块定义
## 前端项目结构
miniprogram/
├── app.js # 应用入口
├── app.json # 全局配置
├── app.wxss # 全局样式
├── theme.wxss # TDesign 主题定制
├── pages/ # 页面文件夹
│ ├── dashboard/ # 首页（事件快捷入口）
│ ├── timeline/ # 记录时间线
│ ├── charts/ # 数据分析图表
│ ├── profile/ # 个人中心
│ └── templates/ # 模板管理（新增）
├── utils/ # 工具函数
│ ├── storage.js # 数据存储管理
│ └── util.js # 通用工具函数
└── custom-tab-bar/ # 自定义底部导航

当然在实现的过程中还要不断地调教，不过最后实现的效果还可以，用的越多发现要时不时的切换新的会话，不然会“降智”，我基本用的是CLaude Sonnet4模型。

最后放几个效果图：