开发工具 on KnightLi的博客

Understand-Anything 怎么用？把代码仓库变成可问答知识图谱

Sat, 06 Jun 2026 22:26:00 +0800

Lum1104/Understand-Anything 是一个把代码仓库变成交互式知识图谱的工具。项目 README 里的口号很直接：Graphs that teach > graphs that impress。意思是图谱不是为了好看，而是要帮助你理解代码。

它适配 Claude Code、Codex、Cursor、Copilot、Gemini CLI 等工具，目标是让开发者和 AI Agent 都能更快理解一个仓库。

为什么需要代码知识图谱

AI 编程工具现在很强，但理解大型仓库仍然容易卡住：

文件太多，入口不清楚；
函数、类、模块之间关系复杂；
新人不知道从哪里开始读；
Agent 搜到了片段，但不知道它在整体架构里的位置；
文档过时，代码才是真相；
多语言、多目录项目更难建立全局地图。

代码知识图谱的价值就在这里：它把“文件和符号列表”变成“可探索的关系网络”。你不只是搜某个函数名，而是能看到它连接了谁、被谁调用、属于哪个模块、在业务路径里处于什么位置。

它能做什么

从项目介绍看，Understand-Anything 主要强调几件事：

把任意代码转成交互式知识图谱；
支持探索、搜索和提问；
让图谱服务理解，而不是只做视觉展示；
能和 Claude Code、Codex、Cursor、Copilot、Gemini CLI 等工具配合；
适合拿来做仓库 onboarding、代码审查、重构前梳理和 Agent 上下文增强。

这类工具尤其适合陌生仓库。你第一次接手项目时，与其让 Agent 盲目 rg，不如先生成一张结构图，再围绕关键节点问问题。

适合哪些使用场景

我会优先把它用在这些场景：

新人接手老项目；
读开源仓库源码；
重构前梳理模块依赖；
找核心入口和关键调用链；
给 AI Agent 提供仓库结构上下文；
代码审查前快速理解改动影响范围；
生成技术文档或架构说明。

它对小项目可能有点重。几十个文件以内，直接读代码就够了。仓库一旦到几百上千个文件，图谱才更容易体现价值。

和 RAG 有什么区别

RAG 更擅长“检索相关片段”，知识图谱更擅长“理解关系”。

比如你问：

“支付流程在哪里？”
“这个函数谁调用？”
“这个模块改了会影响哪些地方？”
“为什么这里有两个类似的服务？”

普通 RAG 可能会给你几个代码片段，但图谱能帮助你看路径、依赖和邻近节点。最好的方式通常不是二选一，而是结合：RAG 找文本证据，图谱提供结构导航。

使用时要注意什么

代码图谱不是银弹：

语言解析能力会影响图谱质量；
动态调用、反射、配置驱动逻辑可能难以完全捕捉；
图谱太大时也会变成信息噪音；
生成结果需要和真实代码交叉验证；
Agent 不能只看图谱就直接改代码。

如果你用于生产项目，最好把它当作阅读辅助，而不是权威架构文档。真正的权威仍然是代码、测试和运行行为。

小结

Understand-Anything 的定位很清楚：把代码仓库变成可探索、可搜索、可问答的知识图谱，让人和 Agent 更快建立全局理解。

如果你经常读陌生仓库、维护大项目、做重构，或者想让 Codex/Claude Code 在动手前先理解系统结构，这类工具很值得试。它不替你读代码，但能帮你更快知道该从哪里读。

参考来源

Lum1104/Understand-Anything - GitHub

Jimmy：把 Evernote、Notion、Google Keep 等笔记导出转换成 Markdown

Sat, 30 May 2026 11:55:56 +0800

Jimmy 是一个笔记转换工具，目标是把不同笔记应用或文档格式里的内容转换成 Markdown。它适合想把笔记从封闭应用里迁出来、放进 Obsidian、Joplin，或者只想长期保存为纯文本的人。

项目文档里的定位很直接：导出或备份原笔记应用的数据，运行 jimmy 转换，再把结果导入 Joplin、Obsidian，或者直接用 VSCode 等文本编辑器查看。

Jimmy 解决什么问题

很多笔记应用都有自己的导出格式。换应用时，最麻烦的往往不是文字内容，而是图片、附件、标签、内部链接和 front matter 这些结构化信息。

Jimmy 做的事情就是把这些导出数据尽量整理成更通用的 Markdown 目录：

笔记正文转换为 Markdown。
尽量保留图片、资源和附件。
尽量保留标签、外部链接和笔记内部链接。
输出 Markdown + front matter。
结果可以导入 Joplin、Obsidian 等工具，也可以直接用文本编辑器查看。

这类工具的意义在于降低迁移成本。笔记一旦变成 Markdown，就不再强绑定某个应用，后续备份、搜索、版本管理和 LLM 处理都会简单很多。

支持的笔记应用很多

Jimmy 支持的来源覆盖面很广，包括 Anki、Anytype、Bear、CherryTree、ColorNote、Day One、Diaro、Drafts、Dynalist、Evernote、Google Docs、Google Keep、Joplin、Notion、Obsidian、OneNote、QOwnNotes、RedNotebook、Reflect、Roam Research、Signal、Simplenote、Standard Notes、Synology Note Station、Telegram、Tiddlywiki、Turtl、UpNote、Wordpress、Zim、Zoho Notebook 等。

并不是所有来源的保真度都完全一样。实际迁移时，仍然要先用一小批笔记试跑，重点检查图片、附件、标签、内部链接和日期字段是否符合预期。

也能转换普通文档

除了笔记应用导出，Jimmy 也能处理一些常见文档格式。文档中提到可以转换单个文件，也可以递归转换整个文件夹，适合把杂乱的资料目录整理成 Markdown。

常见支持格式包括：

类型	例子
办公文档	DOCX、ODT、RTF
标记语言	Asciidoc、DocBook、Markdown、MediaWiki、reStructuredText
网页与电子书	HTML、MHTML、EPUB
数据与结构化文件	CSV、OPML、Jupyter Notebook
其他	PDF、EML、Fountain、txt2tags

如果只是把 DOCX、PDF 或 HTML 批量转成 Markdown，Jimmy 也可以作为一个离线批处理工具来用。

两种使用方式

Jimmy 提供 CLI 和 TUI 两种界面。

界面	适合场景	说明
CLI	批处理、脚本、完整功能	适合一次性转换文件夹、写迁移脚本、指定来源格式
TUI	交互式转换	适合手动操作，目前功能子集仍处于 beta 状态

官方 README 给出的 Linux 示例命令如下：

# 使用交互式 TUI 转换
jimmy-linux tui

# 转换一个 pandoc 支持的单文件
jimmy-linux cli libre_office_document.odt

# 转换整个文件夹
jimmy-linux cli path/to/folder

# 转换 Google Keep 导出
jimmy-linux cli takeout-20240401T160516Z-001.zip --format google_keep

这些命令说明它不是只面向某一个笔记应用，而是把“笔记导出包”和“普通文档目录”都纳入了同一套转换流程。

它的几个特点

特点	说明
离线运行	转换过程不依赖云服务，适合处理私人笔记
开源	仓库采用 GPL-3.0 license
跨平台	官方提供 Linux、Windows、macOS 下载
独立二进制	不要求用户额外安装 Docker、Python 或 Node.js
不使用 AI	转换过程不调用 AI，结果更可控，也减少隐私顾虑
Markdown + front matter	方便导入笔记软件，也方便后续用 Git 管理

其中“离线”和“不使用 AI”很适合笔记迁移场景。笔记里经常有私人信息、工作资料和历史附件，把转换放在本地完成，会让风险边界更清楚。

适合谁使用

Jimmy 适合几类人：

想从 Evernote、Notion、OneNote、Google Keep 等工具迁移到 Markdown 的用户。
想把笔记导入 Obsidian、Joplin 或其他纯文本工作流的人。
想把长期资料保存为未来更容易读取格式的人。
想把笔记或文档准备成 LLM 可处理文本的人。
需要递归转换 DOCX、PDF、HTML、ODT 等文件夹资料的人。

它不一定适合追求“一键完美迁移”的用户。不同笔记应用导出格式差异很大，复杂页面、数据库、嵌入内容和内部链接都可能需要人工复查。

使用前的检查建议

真正迁移前，建议按这个顺序做：

先从原笔记应用导出一小批样本。
用 Jimmy 转换样本，而不是一上来转换全部笔记。
检查 Markdown 正文、图片、附件、标签、创建时间、内部链接。
确认目标应用，例如 Obsidian 或 Joplin，能正确识别目录结构和 front matter。
再对完整导出包执行转换。
保留原始导出包和转换结果，至少等确认无误后再清理。

这个流程虽然慢一点，但能避免迁移后才发现附件丢失、链接断掉或标签结构不对。

我的判断

Jimmy 的价值在于把笔记迁移从“依赖某个应用的导入器”变成“先转成通用 Markdown”。它支持的来源很多，输出也足够通用，适合把个人知识库从封闭格式里释放出来。

如果你只是偶尔导出一两篇笔记，可能用不到它。但如果你有多年积累的笔记、附件和文档目录，想迁移到 Obsidian、Joplin 或 Git 管理的 Markdown 工作流，Jimmy 很值得试。它最适合做迁移中间层：先把数据变成可读、可备份、可批处理的文本，再决定放进哪个笔记系统。

项目链接：marph91/jimmy
文档链接：Jimmy - Note Conversion Tool

Google Pay 与 Wallet 推出 Developer MCP Server：把支付集成接入 AI 助手

Fri, 29 May 2026 15:24:18 +0800

Google Developers 发布了 Google Pay 与 Wallet Developer MCP Server。它面向正在集成 Google Pay API 和 Google Wallet API 的开发者，把官方文档、账号状态、集成校验和部分业务指标接入 MCP 兼容的 AI 开发工具。

这类更新看起来不像模型发布那么热闹，但对开发者很实用。支付和钱包集成往往不是“会不会写代码”的问题，而是文档细节多、配置项多、审核要求多、错误反馈分散。MCP Server 的价值就在于让 AI 助手可以在更接近真实上下文的位置帮开发者排查问题。

它解决什么问题

开发者在接入 Google Pay 或 Google Wallet 时，通常要在多个地方来回切换：

查官方文档和示例代码
确认账号与商户配置
检查请求参数和返回错误
验证集成是否符合要求
观察调用表现和关键指标

如果只把这些内容当成网页文档，AI 助手最多只能解释概念或生成示例。接入 MCP Server 后，助手可以通过工具访问更具体的信息，从而给出更贴近当前项目状态的建议。

MCP 在这里为什么合适

MCP 的作用是给 AI 应用提供标准化工具接口。对 Google Pay 和 Wallet 这样的开发者产品来说，它非常适合处理“文档加状态加校验”的组合任务。

例如，开发者可以让支持 MCP 的 AI 工具帮助回答：

当前集成缺了哪些配置
某个 Google Pay 请求为什么失败
Wallet pass 定义里哪些字段可能不符合要求
代码示例应该如何改成当前业务需要的形态
集成上线前还需要检查哪些项目

这些问题如果只靠大模型记忆，风险很高；如果能结合官方工具和当前账号信息，回答就更可操作。

对 AI 编程工作流的意义

这次发布也说明一个趋势：AI 编程助手正在从“读代码”走向“读产品系统”。

过去，开发者让 AI 帮忙集成支付能力，通常只能把文档片段、错误日志和代码贴进去。AI 可以解释，但不一定知道当前集成的真实状态。MCP Server 把这部分能力向前推进了一步，让 AI 助手有机会直接围绕产品集成环境工作。

这对几类场景尤其有价值：

新项目首次接入 Google Pay 或 Wallet。
旧项目迁移到新的 API 或配置方式。
上线前做集成检查。
遇到错误码、审核问题或配置不一致时快速定位。

对团队来说，收益不只是少查几页文档，而是减少“文档理解正确，但配置现场不一致”的摩擦。

它不会替代开发者判断

支付和钱包相关集成有安全、合规和用户体验要求。MCP Server 可以帮助 AI 助手更快找到信息、检查状态、生成建议，但最终仍需要开发者确认代码、安全策略、商户配置和上线流程。

尤其是支付链路，不能因为 AI 给出一个看似合理的建议就直接上线。更稳妥的方式是把 MCP 工具当成检查员和导航员：它能缩短定位时间，但不能替代审核、测试和业务责任。

我的判断

Google Pay 与 Wallet Developer MCP Server 的意义不在于“又多了一个 MCP 示例”，而在于它把 MCP 放进了一个真实、复杂、强约束的开发者场景。

如果 MCP 只连接文档，它的价值有限；如果它能连接账号状态、集成校验、指标和产品后台，AI 助手就能承担更多实际开发工作。Google 这次发布正好展示了这个方向。

未来类似能力很可能会出现在更多云服务、广告平台、支付系统和企业 SaaS 里。开发者要适应的不是“AI 会写代码”，而是“AI 可以通过标准工具接口参与整个集成流程”。

原文链接：Supercharge your integration workflow with the Google Pay & Wallet Developer MCP Server

Remotion：用 React 以编程方式生成视频

Wed, 27 May 2026 14:39:22 +0800

remotion-dev/remotion 是一个用 React 以编程方式创建视频的框架。它把视频制作从传统时间轴工具里抽出来，变成可以用组件、状态、数据、API、CSS、Canvas、SVG、WebGL 和算法控制的前端工程问题。

项目地址：remotion-dev/remotion

这类工具很适合今天的 AI 编程工作流：如果一个 agent 能生成网页、图表和数据视图，它也可以继续生成视频脚本、动画组件和可渲染的短片。

Remotion 解决的是什么问题

传统视频工具擅长人工剪辑，但不擅长规模化、参数化和自动化。

比如这些任务：

给每个用户生成一条个性化年度回顾视频
根据数据库自动生成产品演示视频
把图表、代码片段和讲解字幕组合成技术短片
批量生成营销素材、社交媒体短视频或课程片段
用 CI/CD 或后端服务按需渲染视频

如果用传统剪辑软件，这些任务很难完全自动化。Remotion 的做法是把视频当成 React 应用来写：每一帧都是组件和数据在某个时间点的结果。

为什么是 React

Remotion README 里给出的理由很清楚：React 可以复用 Web 技术和组件化能力。

它让你可以使用：

CSS 做布局和动画
SVG 做矢量图形
Canvas 和 WebGL 做复杂绘制
JavaScript / TypeScript 做变量、函数、API 调用、数学和算法
React 组件做复用、组合和快速迭代

这意味着前端开发者不需要重新学习一套完全陌生的视频 DSL。很多已有的 UI、图表、设计系统和数据逻辑，都可以迁移到视频生成场景里。

快速开始

如果已经安装 Node.js，README 给出的入口命令是：

`1`	`npx create-video@latest`

创建项目后，你通常会编写 React 组件来描述画面，再让 Remotion 按帧渲染输出视频。

更完整的文档可以看：

文档：remotion.dev/docs
API Reference：remotion.dev/api

它适合哪些场景

Remotion 最适合“视频内容由数据或代码驱动”的场景。

个性化视频

例如年度回顾、用户成就、订单总结、学习报告。每个用户的数据不同，但视觉结构相同。用 React 组件加数据驱动，会比手工剪辑更自然。

技术演示视频

如果视频里包含代码、图表、产品界面、步骤动画和说明文字，Remotion 很适合把这些元素组织成可重复渲染的模板。

数据视频和图表动画

数据可视化本来就是前端强项。Remotion 让图表不仅可以出现在网页里，也可以按时间轴进入视频。

AI 生成视频工作流

AI agent 可以先生成脚本和素材结构，再生成 Remotion 组件，最后渲染视频。这比让模型直接生成最终视频更可控，因为中间产物是代码，可以检查、修改、版本管理和复用。

对 AI 编程工具的意义

Remotion 对 Codex、Claude Code、Cursor、Gemini CLI 这类 AI 编程工具特别有意思。

原因是视频生成被拆成了开发任务：

生成 React 组件。
调整样式和布局。
接入数据。
预览画面。
根据反馈修改。
渲染输出。

这套流程非常适合 agent：每一步都有文件、有代码、有预览、有明确反馈。相比“直接生成一个视频文件”，代码化视频更容易被审阅和迭代。

如果再结合浏览器侧边栏、截图检查、自动化渲染和评论反馈，Remotion 可以成为 AI 工作流里的视频产物层。

使用前要注意许可

Remotion README 特别提醒：Remotion 有特殊许可，在某些公司使用场景下需要获得 company license。

所以不要只把它当成普通 MIT 小工具来用。个人项目、开源项目、商业项目、企业内部工具，许可要求可能不同。正式用于公司生产前，应该先阅读它的 LICENSE 页面和官方许可说明。

这点很重要，尤其是把 Remotion 接进自动化内容生成、营销素材生成或企业内部视频流水线时。

我的判断

Remotion 的价值不只是“用 React 做视频”，而是把视频变成可编程、可复用、可自动化的产物。

对普通前端团队来说，它适合做数据驱动的视频模板。对 AI 工具来说，它更像一个稳定的输出目标：模型不需要一次性生成黑盒视频，而是生成可读、可改、可渲染的 React 代码。

如果你的内容需要批量生成、个性化生成、根据数据更新，或者需要让 agent 反复调整视觉细节，Remotion 值得放进工具箱里。它不是传统剪辑软件的替代品，而是把视频生产接入软件工程流程的一种方式。

RTK：给 AI 编程代理省 token 的命令行代理工具

Wed, 27 May 2026 13:52:01 +0800

rtk-ai/rtk 是一个面向 AI 编程代理的命令行代理工具。它的思路很直接：很多 agent 在开发过程中会频繁调用 ls、cat、grep、git status、git diff、测试命令和构建命令，而这些命令的原始输出经常又长又重复。RTK 会在命令输出进入 LLM 上下文之前先做过滤和压缩，让模型看到更短、更有用的结果。

项目地址：rtk-ai/rtk

它解决的是什么问题

AI 编程工具真正贵的不只是模型调用次数，还有上下文里被塞进去的无效信息。

例如：

ls -la 可能输出大量权限、时间和无关文件。
git diff 可能夹杂很多重复上下文。
pytest、cargo test、npm test 失败时，最重要的是失败用例和错误栈，而不是所有通过项。
docker ps、kubectl pods、aws 命令往往字段很多，但 agent 只需要少数关键信息。

这些输出如果原样进入模型上下文，会快速消耗 token。RTK 的目标不是替代这些命令，而是在它们和 AI 编程代理之间加一层“压缩代理”。

RTK 的基本工作方式

RTK README 里给出的定位是：它会在命令输出到达 LLM context 之前，对结果做过滤和压缩。它是一个 Rust 单文件二进制程序，支持大量常见开发命令，并强调低额外开销。

它主要做四类处理：

Smart Filtering：去掉注释、空白、样板内容和低价值噪音。
Grouping：把相似项目聚合起来，例如按目录、错误类型或状态分组。
Truncation：保留关键上下文，截断重复或不重要的部分。
Deduplication：把重复日志折叠成更短的计数表达。

从 agent 的角度看，命令仍然是熟悉的开发命令；变化在于返回给模型的结果更短。

支持哪些命令

RTK 覆盖的命令范围比较偏“日常开发现场”：

文件查看：rtk ls、rtk read、rtk find、rtk grep
Git：rtk git status、rtk git log、rtk git diff
GitHub CLI：rtk gh pr list、rtk gh pr view、rtk gh issue list
测试命令：rtk pytest、rtk go test、rtk cargo test、rtk vitest、rtk playwright test
构建和 lint：rtk lint、rtk tsc、rtk next build、rtk cargo clippy
容器和云命令：rtk docker ps、rtk docker logs、rtk kubectl pods、rtk aws sts get-caller-identity
数据和日志：rtk json、rtk deps、rtk env、rtk log

这类工具最适合 agent 高频读命令输出的场景。它不负责替你写代码，而是让 agent 少读废话。

安装和接入方式

README 给了几种安装方式。

Homebrew：

`1`	`brew install rtk`

Linux/macOS 快速安装：

`1`	`curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh \| sh`

Cargo：

`1`	`cargo install --git https://github.com/rtk-ai/rtk`

安装后可以先检查版本和统计信息：

1
2

rtk --version
rtk gain

接入 AI 编程工具时，可以用初始化命令：

rtk init -g
rtk init -g --gemini
rtk init -g --codex
rtk init -g --agent cursor
rtk init --agent windsurf
rtk init --agent cline

初始化后需要重启对应的 AI 工具。对于支持 hook 的 agent，Bash 命令会在执行前被重写，例如把 git status 变成 rtk git status，让 agent 收到压缩后的输出。

使用时要注意什么

RTK 的收益取决于 agent 是否真的通过 shell 命令读取信息。

README 里特别提醒：像 Claude Code 的内置 Read、Grep、Glob 这类工具不经过 Bash hook，因此不会自动被 RTK 改写。要让 RTK 介入，需要使用 shell 命令，例如 cat、head、tail、rg、grep、find，或者直接调用 rtk read、rtk grep、rtk find。

这点很关键。RTK 不是全局透明地压缩所有 agent I/O，它更像是 shell 命令层面的代理。

Windows 用户也要注意，README 建议不要直接双击 rtk.exe，而是把它放到 PATH 里，通过 Command Prompt、PowerShell 或 Windows Terminal 使用。它也提到，如果想获得完整 hook 体验，WSL 会更自然。

适合谁用

RTK 适合三类人：

重度 AI 编程用户：每天让 agent 跑很多 git、rg、测试和构建命令。
大仓库用户：命令输出动辄几百行，agent 经常被无关上下文淹没。
关心 token 成本和上下文窗口的人：希望模型把注意力放在失败、变更和关键文件上。

如果你的项目很小，或者 agent 主要通过 IDE 内置工具读取文件，RTK 的体感收益可能没那么明显。它真正发力的地方，是命令行输出又长又频繁的开发流。

我的判断

RTK 的方向很实用。现在很多 AI 编程工作流都在强调更强的模型、更大的上下文、更长的任务，但开发现场还有一个朴素问题：agent 经常读了太多没必要读的东西。

把命令输出先压缩，再交给模型，能减少 token 消耗，也能降低模型被噪音带偏的概率。

不过它不是魔法开关。要用好 RTK，需要把 agent 的工作方式往 shell 命令靠一靠，并确认当前工具的 hook 是否真的生效。对 Codex、Claude Code、Gemini CLI、Cursor、Windsurf 这类场景来说，它更像一个值得测试的“上下文节流器”：不改变开发命令本身，但让 agent 读到更干净的结果。

Codex 官方文章解读：如何把 Codex 用到极致

Wed, 27 May 2026 08:21:18 +0800

多数开发者第一次使用 Codex，通常是从代码任务开始：阅读仓库、修改 diff、运行测试、打开 pull request。

这仍然是 Codex 的核心场景。但电脑上的很多工作本来就被代码和工具包围：执行 shell 命令、浏览网页、调用 API、导出文档、响应消息、触发自动化。随着这些能力逐渐接入 Codex，它就不再只是狭义的代码助手，而更像一个帮你完成电脑工作的系统。

Codex app 让这种变化变得更具体。一个 thread 可以保留上下文、调用工具、展示产物，并在多轮提示之间持续推进，而不是每次对话都重新开始。

想更充分地使用 Codex，关键是把这些能力组合起来：

持久线程，用来保存长期上下文
语音输入、steering 和 queuing，让用户仍然掌控过程
browser、computer use、MCP servers 和 connectors，让 Codex 走出仓库
thread automations 和 Goals，让任务在用户离开后继续推进
侧边栏，用来审阅代码、文档、幻灯片、网页和其他产物
共享记忆，把重要上下文写到线程之外

持久线程

Durable threads 指的是能在多次会话之间保留工作上下文的长线程。

Pinned threads 是一种很实用的入口。它适合放那些会反复回来的工作流，比如：

Chief of Staff 线程
发布线程
文档审阅线程
外部监控线程

这些不是临时聊天，而是持续存在的工作空间。Codex 可以在后续继续回到同一个线程，沿用之前的决策、偏好和背景信息，避免每次都从零重建上下文。

快捷键也让它更顺手。Command-1 到 Command-9 可以直接跳转到已保存的线程。

语音输入

语音输入的价值在于，它能捕捉还没有被整理成正式文字的想法。

Codex 内置语音输入。它特别适合那些说起来很自然、打字时却很别扭的模糊起点：

1
2
3

我记得 Slack 里好像有个叫 Ben 的人提过这个。
具体细节我不记得了。
帮我去找一下。

对于一个能搜索、整理上下文并汇报结果的 agent 来说，这通常已经足够开始。

语音也适合两三分钟的想法倾倒。会议转录、口述规划笔记、未整理的原始记录，往往比一句摘要更有用，因为它们保留了不确定性、重点和没说完的思路。

Steering 和 queuing

语音和显式控制结合起来时，会更有用。

Steering 指的是在 Codex 任务执行过程中插入新的方向，让它在当前步骤结束前改道。

例如在审阅网页时，用户可以一边在侧边栏标注，一边打断当前任务：

1
2
3

这里再小一点。
这两个元素之间的间距不对。
这句文案写错了。

Queuing 则不同。它不打断当前任务，而是把下一步工作排到队列里：

`1`	`这项工作完成后，把预览链接发给 Slack 里的 reviewer。`

Steering 改变 Codex 现在正在做什么。Queuing 改变它接下来应该做什么。两者都让用户在任务展开时仍然靠近现场。

工具和可触达范围

线程有了连续性之后，下一个问题就是：它能操作什么？

Codex 可以一层层向外扩展：

$browser：适合侧边栏里的网页检查、标注和 review
@chrome：适合依赖用户 Chrome 登录状态的浏览器工作流
@computer：适合只能通过桌面 GUI 完成的任务

MCP servers 和 connectors 把同样的思路扩展到更多工作流中。Slack、Gmail、Calendar 很重要，因为很多任务最初不是以代码形式出现，而是以消息、邮件和日程问题出现。

Skills 则适合固化重复工作。当某个流程已经被证明有用，就可以把它打包成 skill，让 Codex 下次不必重新学习这套步骤。

从任何地方继续工作

Codex mobile app 改变了用户必须坐在电脑前的时间。

一个任务可以在 Mac 上开始，因为文件、权限和本地环境都在那里；随后用户离开桌面，只用手机继续确认、补充或改方向。

这在很多小场景里很有价值：Codex 跑长任务时，用户可以离开座位；如果它需要确认，可以在外面回复；如果方向错了，也能及时 redirect。真正留在原地的是本地环境，而不是用户本人。

自动化

Automations 可以按计划运行 Codex 工作。

如果一个周期任务应该从某个 workspace 重新开始，例如日报或常规仓库检查，可以用 scheduled automation。如果调度应该回到一个已有对话，并沿用它的上下文，就更适合 thread automation。

Thread automations 更像心跳式唤醒：按固定节奏回到同一个 Codex thread。

Pinned threads 需要用户主动回来，而 thread automation 可以每几分钟或每几小时检查一次，持续运行到满足条件为止，并随时间调整节奏。

例如，一个 Chief of Staff 线程可以每 30 分钟运行一次：

1
2
3

每 30 分钟检查 Slack 和 Gmail，找出需要我注意但还没有回复的消息。
帮我判断哪些最重要。
如果有人问我问题，尽可能深入研究答案，并替我起草回复，但不要发送。

用户回来时，最耗时的上下文收集往往已经完成。真正要不要发送，仍然由人决定。

Thread automations 也适合反馈循环。它可以定期查看 pull request 评论、Google Docs 评论或 Slack 回复，在用户离开时继续推进周边工作。

比如一个动画工作流：reviewer 在 Slack 里发来视频反馈，thread automation 定时检查线程；如果有新评论，就重新渲染版本，并在同一个 Slack thread 里回复 reviewer。如果某个集成无法完成最终上传，桌面自动化还可以通过 GUI 补上最后一步。

这个循环会跨过 Slack、代码库和桌面应用，但对用户来说仍然留在同一个工作流里。

Goals

Goals 最适合那些有明确终点、并且 agent 可以持续推进的任务。

一个较弱的 goal 可能是：

`1`	`实现这个 Markdown 文件里的计划。`

更强的 goal 会有可衡量的完成标准。

例如，把一个内部工具从 Python 迁移到 Rust 时，可以先建好新目录，再把目标说清楚：新实现只有在单元测试通过后才算完成。

Goal 本质上是持续执行加验证器。用户需要定义结果、停止条件，以及判断 Codex 是否更接近目标的信号。

常见的验证器包括：

测试套件
benchmark
bug reproduction
validation matrix
必须持续通过的端到端工作流

任务可以有野心，但没有验证条件时，它更像愿望，而不是 goal。

侧边栏

侧边栏把工作产物放在生成它的对话旁边。用户不必导出文件、切换上下文，再回头描述问题。产物可能是代码，也可能是 deck、PDF、网页、表格，或者工作过程中生成的其他 artifact。

它特别适合四类工作：

检查 artifact
标注需要修改的地方
操作网页界面
审阅变更

Markdown、表格、数据表、文档和幻灯片都可以直接在侧边栏里看。用户可以检查、标注、修改，而不用把这个过程变成另一轮交接。

如果是 deck 或 PDF，它可以一直停在产生它的 thread 旁边，随时接受 review 和修复。

浏览器也是类似的工作面。Codex 可以打开渲染后的页面，检查它，响应用户在页面上的标注，并继续修复同一个对象。网页既是输出结果，也是控制表面。

这些表面尤其适合放在侧边栏里：

index.html 这种轻量静态 artifact
Storybook
Remotion Studio
浏览器幻灯片
数据分析应用

一个单独的 index.html 文件就可以成为长期存在的交互 artifact，不一定需要服务器。Thread automations 也可以定期刷新静态 artifact，让用户回来时看到新的结果。

共享记忆

长线程很有用，但重要上下文不应该只存在于对话记录里。

Shared memory 指的是把持久上下文存放在线程之外，让未来的工作可以从明确、可审阅的地方继续。

一种稳定做法是把持久线程锚定在 Obsidian vault 里。实际形态可以很简单：一组普通文件，方便检查、编辑、移动和长期保存。团队可以把它放在 cloud storage、Git、Dropbox、Google Drive 或其他同步层里。

一个 vault 可能长这样：

vault/
├── TODO.md
├── people/
├── projects/
├── agent/
└── notes/

顶层的 AGENTS.md 可以说明 Codex 应该如何维护这个工作空间：什么信息要写下来，写到哪里，什么时候不要制造噪音。

一个实用的 AGENTS.md 可以这样写：

- Treat ~/vault as durable work memory.
- Prefer canonical notes over note sprawl.
- Route TODOs, people, projects, daily summaries, and scratch notes explicitly.
- Preserve decisions, blockers, owners, dates, and useful links.
- If nothing meaningful changed, do not churn the vault.

不要照抄某个 vault 结构。更重要的是教会 agent：长期上下文应该放在哪里，哪些信息值得保留，什么时候不应该反复改动文件。

仓库存放代码。Vault 存放滚动上下文：相关人员、发生了什么、哪里卡住、谁负责、下一步是什么，以及那些如果不写下来就会在会话之间消失的细节。

Codex 也有第一方记忆能力，可以在 Settings > Personalization > Memories 中配置。它适合记录偏好、重复工作流和常见坑点，但它更适合作为显式 written context 的补充，而不是替代品。Chronicle 也在同一个方向上推进：从最近的屏幕上下文中帮助 Codex 建立记忆。

从代码向外扩展

Codex 仍然从代码开始。但代码周围的更多工作，现在也能被同一个系统触达：MCP servers、浏览器界面、桌面控制、thread automations 和可审阅 artifact。

这改变了使用 Codex 的控制方式。Steering 用来打断正在进行的工作。Queuing 用来排下一步。Thread automations 让线程在用户离开后继续活动。Goals 给长期任务加上明确终点和验证信号。

当这些能力连起来时，Codex 就能把一个工作流从指令推进到执行，再推进到 artifact review。即使任务已经离开代码仓库，它仍然可以留在同一个系统里完成。

原文链接：Getting the most out of Codex

Codex Goal 设置目标失败：Failed to set goal 怎么处理

Wed, 27 May 2026 08:17:57 +0800

最近有用户反馈，使用 Codex Goal 时会立即出现 Failed to set goal 或“设置目标失败”的错误。这个错误和 prompt 长短无关，在 Codex 应用和 VS Code 扩展里都可能出现。

从讨论里的反馈看，这个问题更像是本地功能开关或配置状态异常，而不是目标内容本身写错了。

先检查 goals 功能开关

最直接的处理方法，是检查 Codex 的配置文件：

`1`	`~/.codex/config.toml`

确认里面有 [features] 段，并开启 goals：

1
2

[features]
goals = true

如果已经有 [features]，只需要在该段下面补上 goals = true。如果没有这个段，就新建一个。

改完以后，重启 Codex 应用或 VS Code 扩展，再重新尝试设置 Goal。

如果还有问题，检查配置目录

讨论里也有人提到，.codex 目录里的缓存或临时文件异常时，也可能触发类似问题。

比较稳妥的处理顺序是：

先备份 ~/.codex/config.toml。
关闭 Codex 相关应用。
临时移走或重命名 ~/.codex 目录。
重新打开 Codex，让它重建配置目录。
再把原来的 config.toml 里需要的配置合并回来。

不要直接删除配置目录，尤其是里面可能有你手动维护的配置、技能、会话或其它本地状态。

Windows 上还要留意安全软件

也有反馈提到，Windows Defender 可能会把 config.toml 当成可疑文件。这不一定是所有人的原因，但如果你在 Windows 上遇到同样问题，可以顺手检查一下安全软件的隔离记录。

如果配置文件被隔离、改名或阻止访问，Codex 读取不到功能开关，也可能表现为 Goal 无法启用。

判断是不是 prompt 的问题

一个简单判断方法是：用极短目标测试。

例如：

`1`	`修复一个测试失败`

如果极短目标也立即报 Failed to set goal，基本就不是 prompt 写法问题，而是本地配置、功能开关、扩展状态或缓存目录问题。

如果只有很长、很复杂的目标会失败，再考虑是否是目标内容太复杂、包含特殊链接、字段格式不被 UI 接受。

小结

Codex Goal 的 Failed to set goal 可以按这个顺序排查：

检查 ~/.codex/config.toml。
在 [features] 下加入 goals = true。
重启 Codex 应用或 VS Code 扩展。
仍失败时，备份配置后重建 ~/.codex。
Windows 用户额外检查 Defender 或安全软件是否误拦截配置文件。

这个问题的重点不是“目标怎么写”，而是先确认 Goal 功能本身是否在本地配置里正常启用。

oh-my-codex：给 Codex CLI 加上工作流、技能和运行时护栏

Mon, 25 May 2026 07:41:45 +0800

Yeachan-Heo/oh-my-codex，简称 OMX，是一个围绕 OpenAI Codex CLI 的工作流层。

项目地址：https://github.com/Yeachan-Heo/oh-my-codex

它想解决的不是“再做一个新的 coding agent”，而是让已经在使用 Codex CLI 的人，有一套更稳定的日常工作方式：启动时带上项目指令，任务变复杂时先澄清再计划，执行时有 durable goal 和状态记录，收尾时用 review 和 QA 把结果压住。

截至写作时，GitHub 页面显示仓库约有 29.4k star，最新 release 是 v0.18.1，发布时间为 2026 年 5 月 21 日。README 也明确说，官方项目是 Yeachan-Heo/oh-my-codex，官方 npm 包是 oh-my-codex，不要把第三方 “OMX v2” 项目误认为这个仓库的官方延续。

它到底是什么

OMX 不替代 Codex。

它保留 Codex CLI 作为实际执行引擎，自己主要补三类东西：

更固定的任务流程。
可复用的 prompts、skills 和 specialist agents。
.omx/ 目录下的计划、日志、状态和运行时记录。

换句话说，Codex 负责“动手干活”，OMX 负责“让干活过程更像工程流程”。这也是它和普通 prompt 包最大的区别：它不是只往系统提示词里塞规则，而是把澄清、计划、执行、检查、团队协作和运行时诊断拆成一组可调用的工作面。

默认工作流

OMX 的主线工作流大致是：

$deep-interview "clarify the authentication change"
$ralplan "approve the auth plan and review tradeoffs"
$prometheus-strict "stress-test the plan before durable execution"
$ultragoal "turn the approved plan into durable Codex goals"

其中最常用的是三步：

$deep-interview：在需求还不清楚时追问边界、目标和非目标。
$ralplan：把需求整理成计划，并经过架构与批判视角确认。
$ultragoal：把批准后的计划转成更耐跑的目标和检查点。

如果任务需要并行协作，可以在 Ultragoal story 里用 $team；如果只需要一个持续推进的单人循环，可以用 $ralph。这套命名看起来有点重，但背后的想法很清楚：不要让 agent 一听到需求就急着改文件，而是先把“要做什么、怎么做、怎么验收、什么时候停”写清楚。

skills 和 agents 提供了什么

OMX 文档把技能分成几类。

Canonical Workflow 里有 $deep-interview、$ralplan、$prometheus-strict、$ultragoal、$code-review 和 $ultraqa。这些面向的是完整工程任务：先澄清，再计划，再执行，再审查，再 QA。

Execution Modes 里有 $team、$ralph、$autopilot、$ultrawork 等。它们决定任务是单线推进、团队并行，还是更强的自动循环。

Agent Catalog 则更像角色库，包括 analyst、planner、architect、debugger、executor、verifier、security-reviewer、performance-reviewer、code-reviewer、test-engineer、designer、researcher 等。你不一定每天都要手动点名这些角色，但它们说明 OMX 的定位不是“万能大 prompt”，而是把工程过程拆成可复用的角色和阶段。

这对长期项目有意义。AI 编程里很多失败不是模型完全不会写代码，而是它太快进入执行，跳过需求确认、架构边界、测试基线和收尾审查。OMX 试图用技能和角色把这些步骤固化下来。

插件形态和运行时状态

README 提到，仓库里也包含官方 Codex plugin layout，路径是 plugins/oh-my-codex，并带有 marketplace metadata。

但文档也强调：这个插件形态不是 npm install -g oh-my-codex 加 omx setup 的替代品。插件作用更像是把 hooks、skill surface 和 Codex 生命周期集成包装起来，真正运行时仍然依赖已安装的 omx CLI。

最新 v0.18.1 release 的重点也集中在这条线上：插件安装会使用 pinned OMX launcher，hook 失败时更保守，Ultragoal 状态变更会序列化，release packaging 会排除 crate-local .omx runtime cache，并同步 npm、Cargo workspace、lockfile 和插件 manifest 的版本号。

这些变化说明 OMX 已经不只是一个 prompt 仓库，它开始认真处理安装形态、hook 安全、状态写入、release 包内容和跨运行时一致性。对工具链来说，这些都属于“不炫但很要命”的工程细节。

适合谁

OMX 比较适合已经在认真使用 Codex CLI 的开发者，尤其是这些场景：

经常让 Codex 处理多文件、多步骤任务。
希望 agent 先澄清需求，而不是直接改代码。
想把计划、执行、检查、review 和 QA 分开管理。
需要在项目里保留 .omx/ 状态、计划和日志。
想尝试 tmux/team runtime 或更强的长任务推进方式。
团队愿意把自己的工程习惯沉淀成 skills 和 prompts。

如果你只是偶尔让 Codex 改一行配置、生成一个脚本、解释一段代码，OMX 可能会显得偏重。它更像是给高频 AI 编程用户准备的工具腰带，而不是新手必须安装的第一层入口。

使用时要注意什么

第一，不要把 OMX 当成“无人值守自动完成一切”的保证。它能强化流程，但不能替你判断需求是否合理、架构是否该改、风险是否可接受。

第二，平台边界要看清楚。README 现在明确推荐 macOS/Linux + Codex CLI。Windows 原生路径存在，但不是默认最佳体验。如果你在 Windows 上使用，WSL2 通常比原生终端更稳。

第三，omx doctor 不是最终验收。真正能证明环境可用的是 codex login status 加 omx exec 这种实际模型调用测试。

第四，流程越强，越需要你写清楚任务边界。$ultragoal、$team、$autopilot 这类能力适合有验收标准的任务。如果需求本身还很含糊，应该先用 $deep-interview 或普通对话把边界拉清楚。

小结

oh-my-codex 的价值不在于让 Codex “变成另一个工具”，而在于给 Codex CLI 加了一层更工程化的工作方式。

它把 AI 编程从“我说一句，你改一轮”往“澄清、计划、执行、检查、记录状态”推进了一步。对轻量任务来说，这可能有点重；但对经常用 Codex 做真实项目的人来说，稳定流程、可复用技能、运行时诊断和 durable goal 反而是省心的关键。

如果你已经把 Codex CLI 当成日常开发工具，OMX 值得试一下。即使不直接安装，它对 skills、agents、计划和验收流程的拆法，也很适合拿来改造自己的 AI 编程工作流。

参考资料

Yeachan-Heo/oh-my-codex：https://github.com/Yeachan-Heo/oh-my-codex
Getting Started：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/getting-started.html
Agent Catalog：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/agents.html
Skills Reference：https://github.com/Yeachan-Heo/oh-my-codex/blob/main/docs/skills.html
v0.18.1 release：https://github.com/Yeachan-Heo/oh-my-codex/releases/tag/v0.18.1

CLI-Anything：把软件变成 Agent 可用的命令行

Mon, 25 May 2026 00:24:36 +0800

CLI-Anything 是 HKUDS 开源的 Agent 工具化项目，目标是把原本面向人类 GUI 操作的软件，转成 AI Agent 更容易调用的命令行接口。它不是重新实现一个简化版软件，而是围绕现有代码库和真实后端生成 CLI harness，让 Agent 可以通过稳定命令、状态会话和结构化输出来完成任务。

这个方向解决的是 Agent 使用软件时最常见的断层：GUI 自动化依赖截图、点击和坐标，容易受界面变化影响；单个 API 又经常覆盖不完整，Agent 需要自己拼接大量上下文。CLI-Anything 选择把软件能力收敛成命令行，因为命令天然适合被模型读取、组合、验证，也便于接入脚本和自动化流程。

它怎么工作

官方仓库把 CLI-Anything 描述为一套自动生成 CLI 的流水线。给它一个本地软件源码路径或 GitHub 仓库地址后，流程会分析代码结构、识别后端和数据模型，设计命令分组，再实现 CLI、测试和文档。

生成出来的 CLI 通常包含两种使用方式：一种是面向连续工作的 REPL，会保留项目状态；另一种是子命令模式，适合脚本和流水线。命令还会提供 JSON 输出，方便 Agent 直接解析结果，同时保留人类可读的格式用于调试。

官方示例里，Claude Code 插件可以这样使用：

1
2
3

/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anything
/cli-anything <software-path-or-repo>

如果已经生成某个软件的 harness，后续使用方式会更接近普通 Python CLI：

cd <software>/agent-harness
pip install -e .
cli-anything-<software> --help
cli-anything-<software>
cli-anything-<software> --json <command>

适合什么场景

CLI-Anything 更适合那些“能力在真实软件里，但 Agent 不好稳定操作”的场景。例如图像、视频、音频、办公文档、3D 建模、数据分析或 AI/ML 工具链，只要项目有可分析的代码库、可调用的后端或清晰的数据模型，就有机会被包装成 Agent 可用的命令集。

它的价值不只是在命令行里多一层封装，而是把软件的关键操作变成可发现、可组合、可测试的接口。Agent 可以先通过 --help 理解能力，再用 JSON 输出接收结果，并把多个命令串成工作流。对于需要批处理、自动验证和持续迭代的任务，这比临时让 Agent 点击界面更可控。

需要注意的边界

CLI-Anything 并不等于任何软件都能立刻无成本接入。它依赖目标软件的源码、后端能力、文件格式和可测试性；如果一个软件高度封闭、关键逻辑只存在于 GUI 层，生成高质量 CLI 的难度会明显上升。

官方方法论也强调真实后端和测试验证，这意味着生成 harness 不是只写几个命令包装脚本就结束。要让它用于严肃工作，还需要确认命令覆盖范围、输出格式、依赖安装、真实软件调用和端到端测试是否可靠。更现实的用法，是先为一个明确工作流生成 CLI，再通过 refine、test、validate 等命令逐步补齐能力。

小结

CLI-Anything 的思路很直接：不要让 Agent 去适应脆弱的人类界面，而是为现有软件补上一层稳定、结构化、可测试的命令行入口。它适合想把专业软件纳入 Agent 工作流的人，也适合研究“Agent 原生软件”形态的开发者。真正落地时，重点不在于一句命令生成了多少代码，而在于生成的 CLI 是否能调用真实能力、保持状态、输出结构化结果，并经得起测试。

GitHub Spec Kit 是什么？用规格驱动开发约束 AI 编程

Mon, 25 May 2026 00:19:14 +0800

GitHub 的 Spec Kit 是一个面向 AI 编程的新工具包，目标是帮助开发者实践 Spec-Driven Development，也就是规格驱动开发。

它解决的问题很直接：现在很多 AI 编程工作流太像“边聊边写”。人类给一个大概想法，Agent 立刻开始改代码，短期看很快，但需求边界、验收标准、技术取舍和任务拆分往往没有沉淀下来。项目稍微复杂一点，就容易变成一次性的 vibe coding。

Spec Kit 的思路是反过来：先把规格写清楚，再进入计划、任务和实现。代码不再是第一步，规格才是第一步。

Spec Kit 是什么？

Spec Kit 是 GitHub 开源的规格驱动开发工具包。它提供 specify CLI、模板、脚本和面向 AI coding agent 的命令，让团队可以围绕同一套结构化产物推进开发。

它强调的不是“让 AI 少问问题”，而是让 AI 在写代码前先生成并完善这些内容：

项目原则：团队对质量、测试、体验、性能等方面的约束；
功能规格：要做什么、为什么做、用户故事和功能需求；
技术计划：使用什么技术栈、如何落地、有哪些架构决策；
任务清单：把计划拆成可执行步骤；
实现过程：按任务逐步修改代码，而不是一次性乱改。

这套流程让 AI 编程更像工程协作，而不是一次提示词表演。

基本使用流程

官方 README 给出的入门流程大致是这样：

1
2
3

uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@vX.Y.Z
specify init my-project --integration copilot
cd my-project

初始化后，项目里会生成 .specify 目录、模板、脚本和与 Agent 集成的命令。随后在支持的 AI coding agent 中使用 /speckit.* 命令推进开发。

典型顺序是：

/speckit.constitution
/speckit.specify
/speckit.clarify
/speckit.plan
/speckit.tasks
/speckit.implement

其中 /speckit.constitution 用来建立项目原则，/speckit.specify 描述产品需求，/speckit.clarify 补齐模糊点，/speckit.plan 生成技术计划，/speckit.tasks 拆任务，最后由 /speckit.implement 执行实现。

这和直接对 Agent 说“帮我做一个应用”差别很大。Spec Kit 要求你把“做什么”和“怎么验收”先说清楚，再让 Agent 动手。

它改变了 AI 编程的入口

传统 AI 编程经常从代码开始：

`1`	`我想做一个任务管理应用，帮我写出来。`

Spec Kit 更像这样：

先定义这个任务管理应用的用户、场景、功能边界、验收标准和非目标；
再根据这些规格选择技术方案；
然后拆成任务；
最后逐步实现。

这个变化很重要。因为 AI 最擅长根据上下文执行，但如果上下文本身是松散的，执行速度越快，偏离方向也可能越快。Spec Kit 把上下文变成文件和模板，让需求、计划和任务都能被 review、修改和版本管理。

换句话说，它不是让 AI 更“自由”，而是让 AI 在更清晰的工程轨道上自由发挥。

核心命令怎么理解？

`/speckit.constitution`

这是项目的“宪法”。它会生成或更新 .specify/memory/constitution.md，用于记录项目长期遵守的原则，例如代码质量、测试标准、用户体验一致性、性能要求和技术决策规则。

这一步适合写团队共识，而不是单个功能需求。

`/speckit.specify`

这是功能规格阶段。你需要描述要构建什么、用户是谁、解决什么问题、有哪些核心流程。

官方特别强调：这一阶段不要过早关注技术栈。先把 what 和 why 写清楚，再讨论 how。

`/speckit.clarify`

这是补问题的阶段。很多需求第一次写出来都会有空洞：权限怎么处理？异常状态是什么？数据是否持久化？边界条件如何验收？

/speckit.clarify 的价值，是让 Agent 主动发现规格中的不确定点，并把回答记录回规格文档，减少后面返工。

`/speckit.plan`

这是技术计划阶段。到了这里，才开始明确框架、数据库、架构、API、测试策略和约束。

如果说 /speckit.specify 是产品语言，/speckit.plan 就是工程语言。

`/speckit.tasks`

这一步把计划拆成可执行任务。好的任务清单应该能让 Agent 逐步推进，也能让人类看懂每一步的目的。

`/speckit.implement`

最后才进入实现。Agent 根据前面沉淀的规格、计划和任务修改代码。这时它不再是凭一段大 prompt 猜需求，而是在一组结构化文档里执行。

为什么它适合 AI 编程？

Spec Kit 的价值不在于某个神奇命令，而在于它把 AI 编程中最容易缺失的东西补了回来：

需求可审查；
计划可讨论；
任务可追踪；
决策有上下文；
产物可以进入 Git 历史；
团队可以复用模板和原则；
Agent 的实现不再只依赖一次性聊天记录。

这对复杂项目尤其有用。越是多人协作、长期维护、质量要求高的项目，越不能只靠临时 prompt 驱动开发。

扩展和 Preset

Spec Kit 还提供了两类自定义能力：

Extensions：增加新命令、新模板或外部工具集成；
Presets：改变现有规格、计划、任务模板的格式和术语。

简单理解：如果要新增能力，用 Extension；如果要改造工作流风格，用 Preset。

例如，团队可以通过 Preset 强制加入安全审查、监管追踪、领域术语或测试优先规则；也可以通过 Extension 增加 Jira 集成、代码审查、项目健康检查等新阶段。

这说明 Spec Kit 并不想把所有团队锁进同一种流程，而是提供一个可扩展的规格驱动骨架。

适合谁用？

Spec Kit 适合这些场景：

用 AI coding agent 做新项目原型；
想把 vibe coding 变成可复盘流程；
团队希望统一 AI 生成代码前的需求和计划格式；
项目需要明确验收标准和测试要求；
希望把需求、计划、任务和实现过程都纳入版本管理；
正在探索 GitHub Copilot、Claude Code、Codex CLI 等工具的团队化用法。

它不一定适合非常小的一次性脚本。对于几行代码能解决的问题，完整规格流程可能显得重。但只要任务开始涉及多个页面、多个模块、状态管理、权限、数据模型或长期维护，Spec Kit 的结构化收益就会变明显。

我的理解

Spec Kit 代表的是 AI 编程工具的一种重要转向：从“让 Agent 更快写代码”，转向“让 Agent 更可靠地参与软件工程”。

过去的 AI 编程关注提示词和模型能力；Spec Kit 更关注流程、产物和约束。它提醒我们：AI 写代码越快，规格、计划和验收就越不能省。

如果你已经习惯让 AI 直接实现功能，可以尝试用 Spec Kit 改变起手式：

先让 AI 帮你把需求写成规格，再让它写代码。

这一步看似变慢，实际是在减少后面“代码写完了，但不是我想要的”的返工。

参考链接

github/spec-kit

OpenAI Symphony 是什么？Codex 编排、Issue 驱动与 AI Agent 开发工作流

Mon, 25 May 2026 00:17:32 +0800

OpenAI 最近开源了一个很有意思的 Codex 编排规范：Symphony。

它不是另一个聊天式编程助手，也不是一个完整的新 IDE。更准确地说，Symphony 是一套面向 Codex 的“工作编排方式”：把类似 Linear 的 issue tracker 变成编程智能体的控制平面，让每一个未关闭的任务都能对应一个持续运行的 Agent。

官方文章里有一句话很能概括它的方向：过去工程师要同时盯着多个 Codex 会话，不断分配任务、审查输出、纠偏和重启；Symphony 想解决的，正是这个上下文切换瓶颈。

Symphony 解决的不是写代码，而是管理 Agent

单个 Codex 会话适合交互式开发：你给它一个任务，它修改代码，你 review，再继续追问。但当团队开始同时使用多个 Agent 时，问题会从“代码能不能写出来”变成“谁在做哪件事、做到哪一步、失败后谁来接手”。

OpenAI 的做法是把工作重心从“会话”切到“任务”：

issue 是真正的工作单元；
每个未关闭 issue 都可以映射到一个独立 Agent 工作空间；
Symphony 负责持续轮询任务看板，决定哪些任务需要启动、重试、停止或回收；
Codex 在工作空间里执行实现、测试、提交、创建 PR、更新状态等动作；
人类不再微操每个会话，而是审查结果、调整目标和维护边界。

这背后的变化很关键：Agent 不再只是一个被人类临时唤起的工具，而是开发流程里持续运行的一类执行者。

为什么是 issue tracker？

因为团队已经用 issue tracker 管理真实工作。

需求、bug、重构、迁移、调研、优先级、阻塞关系、负责人、里程碑，这些信息本来就沉淀在 Linear、GitHub Issues 或类似系统里。Symphony 没有重新发明一个庞大的控制台，而是把这些现有系统当作 Agent 的任务入口。

这样做有几个好处：

工作不必从 issue 复制到聊天窗口里。
人类可以继续按熟悉的方式创建、拆分、排期和关闭任务。
Agent 的状态变化能回写到同一个工作系统里，方便团队异步协作。
任务依赖可以自然形成 DAG，让未阻塞的任务并行推进。

如果把传统 CI 看成“代码提交后的自动化”，Symphony 更像是“issue 创建后的自动化”。

它的核心工作流

一个典型的 Symphony 流程可以理解为：

创建 issue
  -> Symphony 轮询到可执行任务
  -> 为该 issue 创建独立 workspace
  -> 启动 Codex agent session
  -> Agent 阅读任务、修改代码、运行测试
  -> 创建或更新 PR
  -> 写回任务状态、评论、证据和交付物
  -> 人类 review、合并或要求修改

官方规范里还强调了几个工程化点：

每个 issue 使用独立工作空间，降低相互污染；
编排器维护重试、并发和恢复状态；
工作流策略放在仓库内的 WORKFLOW.md，让团队把 Agent 应该如何处理任务写成可版本化的规则；
实现需要保留可观测性，至少要有结构化日志；
成功状态不一定是 Done，也可以是交给人类 review 的中间状态。

这说明 Symphony 不是简单地“让 AI 自动写代码”，而是在定义一套可运行、可恢复、可审计的 Agent 工作系统。

目标驱动，而不是死板状态机

OpenAI 在文章里提到一个重要转变：早期他们尝试把很多动作写死在外层 harness 里，例如提交代码、跑测试、处理 GitHub 流程。但随着 Codex 能力增强，这种方式反而限制了 Agent。

后来的方向是给 Agent 设定目标，而不是把每一步都写成固定状态转换。

比如，一个任务的目标可以是“完成 Vite 迁移并确保 CI 通过”。Agent 可以自己判断是否需要改配置、修测试、读 CI 日志、处理 review feedback，甚至拆出新的后续 issue。Symphony 负责提供边界、上下文和运行框架，而不是替 Agent 规定每一个动作。

这也是它和传统自动化脚本的区别：脚本擅长重复确定流程；Symphony 面向的是带有不确定性的工程任务。

和普通 Codex 使用方式有什么不同？

普通 Codex 会话更像“人带着 AI 写代码”：

人类打开会话；
人类描述任务；
人类观察输出；
人类随时纠偏；
任务结束后再开下一个会话。

Symphony 更像“团队把任务池交给一组 Agent 执行”：

人类写清楚 issue；
系统持续发现可执行任务；
Agent 在独立环境里推进；
结果以 PR、评论、测试状态、视频或分析报告的形式返回；
人类在关键节点做 review。

这不是替代工程师，而是把工程师从“同时照看多个会话”的负担里解放出来。OpenAI 在官方文章中提到，在部分团队中，合并到主分支的 PR 数量有明显提升；但更值得注意的是工作方式的变化：试验一个想法、发起一次重构、验证一个假设的启动成本变低了。

适合哪些场景？

Symphony 更适合这些任务：

常规功能实现；
已有代码库里的小型重构；
基础设施迁移；
依赖升级；
测试补齐；
CI 修复；
调研后生成实现计划；
根据 review feedback 继续修改 PR。

它不一定适合高度模糊、需要强业务判断或架构拍板的任务。对这类问题，交互式 Codex 会话仍然更自然，因为人类需要在过程中持续参与。

风险和边界

Symphony 的吸引力很强，但真正落地时不能只看“自动化”这一面。

几个边界要提前想清楚：

issue 必须写清楚，否则 Agent 会把模糊需求放大成错误实现；
Agent 的权限要收敛，尤其是仓库、密钥、生产环境和第三方服务访问；
每个工作空间要隔离，避免多个任务相互污染；
CI、测试、lint 和 review 仍然是必须的质量门；
任务状态、PR 链接、日志和失败原因要可追踪；
人类 review 不能省，尤其是涉及安全、计费、数据迁移和权限逻辑的改动。

官方仓库也把 Symphony 定位为 trusted environment 里的工程预览和参考实现，而不是一个拿来就能无脑替代研发流程的成品平台。

我对 Symphony 的理解

Symphony 最有价值的地方，不在于它用了 Linear，也不在于参考实现选择了 Elixir，而在于它重新定义了编程 Agent 的入口。

过去我们习惯从聊天窗口启动 AI 编程：这很灵活，但规模一大，人类注意力就成了瓶颈。Symphony 把入口放回 issue tracker，让 Agent 围绕真实任务持续工作。这样一来，AI 编程从“个人效率工具”开始向“团队工作流基础设施”靠近。

如果你已经在使用 Codex、Claude Code、Cursor Agent 或类似工具，Symphony 值得关注的不是某个具体实现，而是它背后的模式：

不要只管理 Agent 会话，要管理需要完成的工作。

这可能会成为下一阶段 AI 编程工具的关键分水岭。

参考链接

browser-harness 是什么？AI Agent 接管真实 Chrome 的浏览器自动化工具

Sun, 24 May 2026 17:19:54 +0800

browser-use/browser-harness 是一个面向 AI Agent 的浏览器控制工具。它的目标不是再做一层复杂的自动化框架，而是把大模型直接连到真实 Chrome，通过 CDP 完成浏览、点击、截图、下载、上传和表单操作。

项目 README 对自己的定位很明确：用一层很薄、可编辑的 CDP harness，让 LLM 直接连接真实浏览器；当任务中缺少 helper 时，Agent 可以在执行过程中补上代码，并把可复用经验沉淀成 domain skills。

这类工具值得关注，是因为浏览器仍然是很多真实工作的入口：后台系统、SaaS 面板、电商页面、招聘网站、CRM、报销系统、云控制台、文档平台，往往没有稳定 API，或者 API 权限比网页权限更难拿到。让 Agent 能可靠地操作浏览器，本质上是在补齐“最后一公里”的自动化能力。

browser-harness 是什么

从结构看，browser-harness 更像一个给 Agent 用的浏览器运行时，而不是普通用户手动点击的浏览器插件。

它的核心思路有几个：

直接连接 Chrome 或 Chromium 浏览器。
通过 CDP WebSocket 操作页面。
让 Agent 用截图、坐标点击、DOM、网络请求和原始 CDP 组合完成任务。
把任务相关 helper 放在 agent-workspace/agent_helpers.py。
把站点相关经验沉淀到 agent-workspace/domain-skills/。
保持核心很薄，避免做成庞大的自动化平台。

README 中提到，项目核心架构大约是 4 个核心文件、约 1000 行代码，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。

这种设计的重点不是“内置所有网站能力”，而是给 Agent 一个足够贴近真实浏览器的操作层，让它在具体任务里补齐缺失能力。

它和传统浏览器自动化有什么不同

传统浏览器自动化通常围绕测试框架展开，例如 Playwright、Selenium 或 Puppeteer。它们适合写确定性的测试脚本：打开页面、定位元素、点击、断言结果。

browser-harness 面向的是另一类任务：用户说一句目标，Agent 自己探索页面、判断状态、处理弹窗、补 helper、复用站点经验。它强调的是交互过程中的适应性。

差异可以这样理解：

Playwright 更适合人写脚本，Agent 执行脚本。
browser-harness 更适合 Agent 边看页面边行动。
传统自动化偏固定流程。
browser-harness 偏开放任务。
传统脚本常依赖选择器。
browser-harness 鼓励先截图、再按可见界面行动，必要时再退回 DOM 或 CDP。

这并不意味着它要替代 Playwright。对稳定测试来说，Playwright 仍然更成熟。browser-harness 的价值在于把真实网页变成 Agent 可操作的环境，尤其适合那些页面结构复杂、步骤不固定、需要临场判断的任务。

为什么强调真实 Chrome

很多浏览器 Agent 工具会使用隔离的无头浏览器。这样部署简单，也适合批量任务，但它有一个现实问题：用户真实工作里的登录态、扩展、历史记录、书签和日常浏览器环境并不一定能直接复用。

browser-harness 支持连接本机 Chrome，也支持 Browser Use cloud browser。对本机浏览器，它提供两种方式：

通过 chrome://inspect/#remote-debugging 允许当前 Chrome 实例被连接。
用 --remote-debugging-port=9222 --user-data-dir=... 启动一个隔离 profile。

如果要让 Agent 帮你处理真实账号里的任务，项目文档更倾向于第一种方式，因为它能复用日常 Chrome 的登录态、扩展和书签。如果要做无人值守自动化，或者不希望被弹窗打断，则更适合使用隔离 profile 或云浏览器。

这里的取舍很清楚：真实浏览器更贴近用户工作流，但安全边界也更敏感；隔离浏览器更适合自动化，但需要重新处理登录和环境。

可编辑 helper 和 domain skills

browser-harness 最有意思的地方，是它把“Agent 会学到什么”设计进了项目结构。

agent-workspace/agent_helpers.py 用来放任务中临时补出来的 helper。比如 Agent 做文件上传时发现现有能力不够，可以补一个稳定的上传函数；下次再遇到类似页面，就不用从零开始。

agent-workspace/domain-skills/ 则用来放站点级经验。README 里举的方向包括 LinkedIn outreach、Amazon 下单、报销系统等。项目建议不要手写这些 skill，而是让 Agent 在真实任务中发现可复用流程后再生成，这样更贴近实际页面行为。

这个思路很适合浏览器自动化。因为网页自动化的难点往往不是“怎么点击按钮”，而是：

某个网站的登录后页面怎么跳转。
哪些弹窗会挡住主流程。
哪些 selector 稳定，哪些只是临时样式名。
上传、下载、iframe、shadow DOM、跨域组件怎么处理。
某个后台系统有哪些隐藏等待和异步状态。

这些知识如果只留在一次运行日志里，很快就会丢掉。把它们沉淀成 domain skills，才可能让 Agent 越用越顺。

适合哪些场景

browser-harness 更适合以下任务：

帮用户操作真实网页后台。
在没有 API 的系统里完成重复流程。
登录态依赖强的个人或企业网页任务。
需要截图判断页面状态的复杂交互。
Agent 需要在执行中补工具、补站点经验。
多个子 Agent 各自使用独立浏览器执行任务。
研究浏览器 Agent 的运行时设计。

具体例子包括：整理网页表格、提交内部系统表单、下载账单、上传文件、处理报销流程、检查订单状态、在 SaaS 控制台里配置资源、从登录后的网页提取信息。

如果任务只是抓取静态网页，未必需要浏览器。项目自己的 SKILL.md 也提到，静态页面可以直接用 HTTP 批量获取；浏览器应该留给真正需要页面状态、登录态和交互的场景。

需要注意的风险

让 AI Agent 接管真实 Chrome，很强，也很危险。

第一，权限边界要清楚。真实 Chrome 里可能有邮箱、支付后台、云控制台、公司系统和个人账号。Agent 一旦能操作浏览器，就等于获得了这些网页权限的一部分。

第二，不要把凭据交给模型。遇到登录页、支付验证、二次确认等敏感步骤，应该让用户自己处理。Agent 可以等待登录完成，但不应该从截图里读取或输入密码、验证码、支付信息。

第三，自动化不等于可托管。很多网页任务看似简单，但中间可能出现风控、误点击、数据删除、批量提交、不可逆操作。适合先从只读、低风险、可回滚的流程开始。

第四，domain skills 需要避免泄露隐私。站点经验可以公开，但不要把账号、内部 URL、客户数据、坐标流水账或一次性任务细节写进去。

第五，真实浏览器连接方式要谨慎选择。如果要复用日常登录态，使用当前 Chrome 很方便；如果要跑长时间自动化，隔离 profile 或云浏览器更可控。

对 AI Agent 工具的意义

browser-harness 代表了一种很务实的 Agent 工具路线：少做平台，多给模型一个可以直接触达真实环境的接口。

过去很多 Agent 失败在两端。一端是模型会推理，但摸不到真实页面；另一端是自动化框架很强，但需要人先把流程写死。browser-harness 试图把这两端接起来：浏览器负责真实世界的状态，Agent 负责观察、判断和补工具。

这也是“自我改进 harness”的意义。它不是说 Agent 会神奇地变聪明，而是把可复用的操作经验放到项目结构里，让下一次任务少走弯路。

对开发者来说，browser-harness 的价值主要在三个层面：

作为个人 Agent 的浏览器控制层。
作为研究浏览器自动化和 Agent 工作流的样本。
作为把网页流程变成可复用技能的实验框架。

它不是所有浏览器自动化问题的答案，但它给出了一个清晰方向：当 Agent 真正要帮人做事时，工具层不只要能调用 API，也要能理解和操作人类每天使用的网页界面。

简单结论

browser-use/browser-harness 值得关注，不是因为它包装了多少高级功能，而是因为它把浏览器 Agent 的几个关键问题摆在了台面上：真实 Chrome、CDP、截图驱动、可编辑 helper、站点技能沉淀，以及用户权限边界。

如果你只是写稳定端到端测试，继续用 Playwright 或 Selenium 就很好。如果你想让 Codex、Claude Code 这类 Agent 直接帮你处理真实网页任务，browser-harness 提供了一个更贴近 Agent 工作方式的入口。

真正使用时，建议从低风险任务开始：先让它读页面、截图、提取信息，再逐步尝试点击和提交。等你确认它能稳定识别页面状态，再考虑让它接管更长的流程。

参考资料：

GitHub 项目：https://github.com/browser-use/browser-harness
README：https://github.com/browser-use/browser-harness/blob/main/README.md
安装文档：https://github.com/browser-use/browser-harness/blob/main/install.md
使用说明：https://github.com/browser-use/browser-harness/blob/main/SKILL.md

CLIProxyAPI Management Center：给 CLIProxyAPI 配一个可视化管理后台

Sun, 24 May 2026 10:05:15 +0800

Cli-Proxy-API-Management-Center 可以理解成 CLIProxyAPI 的“驾驶舱”。

前一篇提到的 CLIProxyAPI 负责把 Gemini CLI、Codex、Claude Code、OpenRouter 等能力代理成统一 API；而这个 Management Center 解决的是另一个问题：

代理服务跑起来之后，配置、账号、OAuth、日志、配额和凭据，总不能全靠手改文件和翻终端吧？

所以它提供了一个 Web 管理界面，让你可以用浏览器管理 CLIProxyAPI 的配置与运行状态。

它是什么

从项目说明看，Cli-Proxy-API-Management-Center 是 CLIProxyAPI 的独立管理前端，核心功能包括：

可视化编辑 CLIProxyAPI 配置。
上传和管理 auth.json 一类认证文件。
查看请求日志和模型响应日志。
管理 OAuth 认证流程。
检查 Gemini CLI 账号配额。
提供账号、配置、日志等日常维护入口。

另外，官方仓库也提示：新版 CLIProxyAPI 已经内置了这个管理界面，可以直接通过 /management.html 访问；独立仓库仍然保留给需要单独部署或二次开发的人使用。

这点很重要。也就是说，大多数普通用户未必需要额外部署这个仓库；先确认你的 CLIProxyAPI 版本是否已经自带管理页。

它解决的不是“调用模型”，而是“管理模型入口”

CLIProxyAPI 的难点不只是能不能把请求转到模型。

真正麻烦的是这些东西：

多个 Gemini、OpenAI、Claude、Codex 账号如何放进池子里。
哪个账号已经失效，哪个账号配额快用完。
OAuth 登录态怎么导入、刷新和排查。
配置文件怎么改才不会漏逗号、漏字段。
请求到底打到了哪个 provider、哪个模型、哪个账号。
失败请求是上游问题、协议问题，还是本地配置问题。

Management Center 的价值就在这里：它把“代理基础设施”的日常维护变成可视化操作。

如果你只是本机跑一个账号、偶尔调几次 API，它不一定是刚需；但只要你开始做多账号、多模型、多客户端接入，一个后台界面就会明显省事。

典型使用场景

第一，管理账号池。

CLIProxyAPI 支持多账号轮询和负载均衡，但账号越多，越不适合靠手工翻配置文件维护。管理中心可以帮助你查看账号状态、导入凭据、排查异常账号。

第二，排查请求失败。

当客户端报错时，你需要知道请求有没有进代理、走了哪个 provider、返回了什么错误。日志界面比在终端里滚屏找错误舒服很多。

第三，处理 OAuth。

Codex、Claude Code、Gemini CLI 这类工具经常涉及 OAuth 登录态。管理中心提供 OAuth 相关操作入口，能减少重复命令行操作。

第四，给团队内部使用。

如果 CLIProxyAPI 变成团队共享网关，那管理者需要一个能快速查看配置和状态的界面。否则每次变更都要登录服务器改文件，效率很低，也容易误操作。

和 CLIProxyAPI 的关系

可以把两者分成前后两层：

客户端 / IDE / 脚本
        |
        v
CLIProxyAPI：负责协议代理、账号池、模型路由
        |
        v
Gemini CLI / Codex / Claude Code / OpenRouter / 上游模型

Management Center 不在这条推理请求链路的核心位置。它更像运维面板：

浏览器
  |
  v
Management Center：编辑配置、看日志、管账号、查配额
  |
  v
CLIProxyAPI 管理接口 / 配置 / 日志 / 凭据

所以不要把它理解成另一个模型代理。它是管理 CLIProxyAPI 的工具，不是替代 CLIProxyAPI 的工具。

为什么新版内置后仍然值得单独看

既然 CLIProxyAPI 已经内置了 /management.html，为什么还要关注这个独立仓库？

主要有三个原因。

第一，独立仓库能让你看清管理中心本身的功能边界。哪些是前端负责的，哪些必须由 CLIProxyAPI 后端提供接口，一眼更清楚。

第二，如果你要二次开发，比如改 UI、加鉴权、接自己的监控系统，独立仓库更适合作为入口。

第三，如果你的部署环境比较特殊，比如前后端分开部署、管理页走单独域名、静态资源由内网网关托管，独立版本更灵活。

对普通个人用户来说，优先用 CLIProxyAPI 内置版就够了；对团队或深度定制用户，独立仓库更有意义。

部署时最该注意什么

管理后台接触的是敏感东西：账号、OAuth、API Key、日志、请求内容、上游配额。

所以第一条原则是：不要把管理页面裸露到公网。

比较稳的做法是：

只允许本机访问，比如绑定 127.0.0.1。
如果必须远程访问，放到 VPN、Tailscale、内网跳板机或反向代理鉴权后面。
给管理接口加认证，不要只靠“地址没人知道”。
日志里尽量避免暴露完整 Key、Cookie、OAuth token 和用户原始请求。
团队环境里要分清“调用 API 的人”和“能改配置的人”。

很多代理工具真正出问题，不是模型调用失败，而是管理口、日志和凭据文件没保护好。

它适合和哪些东西一起用

如果你只部署 CLIProxyAPI，一个管理中心已经能解决基础维护问题。

如果你进一步关心统计和可观测性，还可以搭配 CLIProxyAPI 生态里的其他工具：

CPA Usage Keeper：偏用量同步和 SQLite 存储。
CLIProxyAPI Usage Dashboard：偏本地优先的用量、配额和图表展示。
CPA-Manager：偏完整管理中心，关注请求监控、费用估算、账号巡检和异常账号清理建议。

可以简单理解：

Management Center 管“配置和日常维护”。
Usage Dashboard 管“看用量和配额”。
CPA-Manager 管“更重的运营和巡检”。

实际用哪个，要看你的部署规模。个人本机用不需要把全家桶都装上。

使用建议

如果你刚开始折腾 CLIProxyAPI，可以按这个顺序来：

先让 CLIProxyAPI 本体跑通，确认 API 能正常响应。
打开内置的 /management.html，看看配置和日志是否能正常读取。
再导入一个账号或一个 provider，确认管理界面能反映状态变化。
有公网访问需求时，先做认证和网络隔离，再考虑开放入口。
等账号和请求量变多，再补用量统计和更完整的管理工具。

不要一开始就把所有账号、所有 provider、所有管理组件一次性接上。越是代理和账号池类项目，越适合小步验证。

总结

Cli-Proxy-API-Management-Center 的定位很清楚：它不是模型、不是聊天客户端，也不是新的 API 网关；它是 CLIProxyAPI 的可视化管理层。

当 CLIProxyAPI 只是一个本机小工具时，你可以不用它；当 CLIProxyAPI 开始承载多账号、多模型、多客户端调用时，它就会变成很实用的“控制台”。

真正要注意的是安全边界。管理后台能改配置、看日志、碰凭据，一旦暴露不当，风险比普通 API 调用口还高。把它放在可信网络里，用认证保护好，再去享受可视化管理带来的省心。

参考资料：

CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 统一封装成 API

Sun, 24 May 2026 10:03:33 +0800

CLIProxyAPI 是一个很有“民间工程味”的项目：它不是再造一个大模型，也不是单纯做 API 转发，而是把一堆原本偏交互式、偏 CLI、偏 OAuth 登录的 AI 工具，重新包成统一 API 服务。

它支持的对象包括 Gemini CLI、OpenAI Codex、Claude Code、Amp CLI、AI Studio Build，以及上游 OpenAI 兼容服务。换句话说，它想解决的问题是：

我手上有 CLI 工具、有订阅账号、有 OAuth 登录态，能不能像调用普通 API 一样，把这些能力接到自己的客户端、脚本、IDE 或内部服务里？

CLIProxyAPI 给出的答案是：可以，中间加一层代理，把不同来源的 CLI 能力转换成 OpenAI、Gemini、Claude、Codex 兼容接口。

它真正解决的痛点

很多 AI 编程工具的能力本来很强，但默认使用方式并不适合自动化。

比如：

Gemini CLI 能登录账号使用，但你的程序更习惯调用 HTTP API。
Claude Code 很适合交互式编码，但接入其他客户端时会遇到协议不一致。
Codex CLI 支持 OAuth 登录和 Responses 风格能力，但不是所有上层工具都知道怎么和它说话。
一个团队可能有多个账号，需要轮询、负载均衡、异常账号剔除和配额观察。
你想让某些工具只认 OpenAI 格式，但后端实际可能是 Gemini、Claude 或 Codex。

CLIProxyAPI 的定位，就是做这些工具和客户端之间的“协议适配层”。

它把复杂的一侧藏在后面：OAuth、CLI 登录、多账号、不同协议、不同 provider。前面则暴露相对熟悉的接口，比如 OpenAI Chat Completions、OpenAI Responses、Gemini、Claude Messages、Codex 相关端点。

能力概览

从官方 README 和文档看，CLIProxyAPI 目前的核心能力包括：

为 CLI 模型提供 OpenAI、Gemini、Claude、Codex 兼容 API 端点。
通过 OAuth 登录接入 OpenAI Codex 和 Claude Code。
支持流式、非流式响应，以及部分场景下的 WebSocket。
支持函数调用、工具调用和多模态输入。
支持 Gemini、OpenAI、Claude 多账号轮询与负载均衡。
支持 Gemini AI Studio API Key。
支持 AI Studio Build、Gemini CLI、Claude Code、OpenAI Codex 的多账号池。
可以通过配置接入 OpenAI 兼容上游，比如 OpenRouter。
提供 Go SDK，方便把代理能力嵌入到自己的服务里。

这类项目最有价值的地方，不是“多支持几个模型名”，而是把账号登录、协议转换和请求路由这些琐碎工作打包起来。

它适合谁用

CLIProxyAPI 更适合下面几类人：

第一类是重度 AI 编程用户。你已经在用 Codex、Claude Code、Gemini CLI，但想把它们接到 Cursor、Cline、RooCode、Amp、内部脚本或自建工作流里。

第二类是有多账号池的人。比如你有多个 Gemini、OpenAI、Claude 登录态，不想手工切换，希望自动轮询、均衡使用、遇到异常账号时能快速排查。

第三类是做团队内部网关的人。团队不希望每个客户端都分别适配 Gemini、Claude、Codex，而是想通过一个中间层统一暴露 API。

第四类是喜欢折腾协议的人。你可能关心 Responses、Chat Completions、Claude Messages、Gemini v1beta 这些接口如何互相转换，也可能希望在同一套客户端里切换不同后端。

如果只是个人偶尔问几句 AI，或者只用官方 App 聊天，那 CLIProxyAPI 的部署和维护成本就显得重了。

和普通 API 中转有什么不同

普通 API 中转服务一般是：

`1`	`客户端 -> 中转 API -> 上游模型 API`

CLIProxyAPI 的链路更像：

`1`	`客户端 -> CLIProxyAPI -> CLI / OAuth 登录态 / 多账号池 -> 模型服务`

区别在于，它处理的不只是 API Key 转发，还包括 CLI 工具、OAuth 账号、协议表面和模型别名。

比如 Codex 和 Claude Code 这类工具，本身就不是传统意义上“拿一个 API Key 就能稳定调用”的模式。CLIProxyAPI 把这些登录态和调用逻辑包装起来，让外部客户端像调用 API 一样访问它们。

这也是它吸引人的地方，同时也是它复杂的地方。

使用时最容易误解的地方

第一，不要以为统一 /v1/... 就能解决所有协议差异。

CLIProxyAPI 文档里专门提醒过：当你需要某一类后端的请求和响应形态时，优先使用 provider-specific 路径。例如 messages 风格用 /api/provider/{provider}/v1/messages，Gemini 模型路径用 /api/provider/{provider}/v1beta/models/...，chat-completions 风格用 /api/provider/{provider}/v1/chat/completions。

统一入口方便，但不同协议的语义并不会凭空消失。工具调用、流式返回、多模态输入、系统消息处理，都可能因为后端不同而有细节差异。

第二，模型名不等于唯一后端。

如果多个后端暴露了相同的客户端可见模型名，仅靠路径不一定能锁定真正执行推理的那个后端。要严格固定后端，最好使用唯一 alias、前缀，或者避免让多个后端暴露同名模型。

第三，多账号轮询不是无限额度。

轮询只能更均匀地使用账号池，不能绕过上游服务的真实限制。账号异常、配额耗尽、风控、OAuth 失效，都需要单独监控。

第四，它不是免维护魔法盒。

一旦你把它放进日常工作流，就要关心配置、日志、上游账号状态、版本升级、客户端兼容性和安全边界。

管理和监控怎么办

官方 README 提到，从 v6.10.0 开始，CLIProxyAPI 和 CPAMC 不再预置数据统计功能。如果需要使用量统计，可以配合独立项目：

CPA Usage Keeper：同步 CLIProxyAPI 数据，存到 SQLite，并提供聚合 API 和仪表盘。
CLIProxyAPI Usage Dashboard：本地优先的用量与配额看板，可展示账号、模型、时间窗口和 Codex 配额余量。
CPA-Manager：更完整的管理中心，面向请求监控、费用估算、账号池巡检、异常账号定位和清理建议。

这说明 CLIProxyAPI 的核心更偏“代理和协议层”，而不是一站式商业管理后台。如果是团队使用，最好一开始就把日志、监控和账号池管理考虑进去。

一个比较合理的使用姿势

如果要试用，可以按这个顺序来：

先用官方文档的 Quick Start 跑起来。
只接一个 provider，比如 Gemini CLI 或 Codex，确认基本请求能通。
再测试流式响应、工具调用、多模态输入这些高风险能力。
确认客户端实际使用的是哪个 endpoint，不要混用协议路径。
最后再加入多账号轮询、管理面板和用量统计。

不要一上来就把 Gemini、Codex、Claude、OpenRouter、多账号和所有客户端全接进去。这样出错时很难判断是认证问题、协议问题、模型名问题，还是上游账号问题。

安全边界也要想清楚

CLIProxyAPI 会接触到账号登录态、API Key、OAuth 相关凭据和请求内容。它如果只跑在自己机器上，风险相对可控；如果暴露到公网或团队内网，就必须认真处理认证、访问控制、日志脱敏和网络隔离。

尤其是管理端点，最好只允许本机或可信内网访问。不要为了省事直接把管理接口裸露出去。

总结

CLIProxyAPI 的价值在于，它把原本散落在多个 CLI、多个账号、多个协议里的 AI 能力，收拢成一个可编程的 API 层。

它适合重度 AI 编程用户、多账号用户和团队内部网关场景；不太适合只想“开箱即用、完全无维护”的轻量用户。

如果你正在折腾 Codex、Claude Code、Gemini CLI 这些工具，并且希望把它们接进自己的客户端或自动化工作流里，CLIProxyAPI 值得认真看一眼。但要把它当基础设施来用，而不是当一次性小工具来用。

参考资料：

让 Codex 使用 DeepSeek 模型的两种方法：本地网关和 OpenRouter BYOK

Sun, 24 May 2026 09:52:55 +0800

想让 Codex 使用 DeepSeek，第一反应通常是改 ~/.codex/config.toml：

1
2

model = "deepseek-chat"
base_url = "https://api.deepseek.com"

这个思路在一些旧版本或普通 OpenAI SDK 场景里确实成立，但放到当前 Codex CLI 上，很容易撞到一个底层问题：Codex 的自定义模型供应商走的是 OpenAI Responses 协议，而 DeepSeek 官方接口主要提供 OpenAI 兼容的 Chat Completions 调用方式。

我本机当前是 codex-cli 0.111.0。codex --help 里可以看到它支持 --config、--model、--profile 这些配置入口；OpenAI 官方 Codex 配置参考也写得很明确：model_providers.<id>.wire_api 目前只支持 responses，省略时也默认是 responses。

DeepSeek 官方文档则给出的调用路径是 https://api.deepseek.com/chat/completions，示例也是 client.chat.completions.create(...)。所以问题不在于 DeepSeek 不能被 OpenAI SDK 调用，而在于 Codex 发出去的请求语义和 DeepSeek 原生接口能理解的语义不完全是一套东西。

这就是为什么直接把 base_url 改成 https://api.deepseek.com 后，可能出现下面这些现象：

请求路径不匹配，直接 404 或返回格式不对。
多轮对话、工具调用、补丁生成时解析失败。
tool_calls 顺序、消息结构、流式事件格式对不上。
看起来模型能回一句话，但一到 Codex 真正干活就开始报错。

更稳的办法，是在 Codex 和 DeepSeek 之间放一个“翻译层”。常见有两种路线。

方法一：用本地网关桥接 DeepSeek

本地网关的作用不是简单转发，而是把 Codex 侧的 Responses 风格请求，转换成 DeepSeek 能处理的 Chat Completions 风格请求，再把 DeepSeek 的结果转换回 Codex 能吃的格式。

如果你用的是 ccx 一类本地网关，配置思路大致是这样：

[profiles.deepseek-ccx]
model = "deepseek-v4-flash"
model_provider = "ccx-bridge"

[model_providers.ccx-bridge]
name = "Local CCX Gateway"
base_url = "http://localhost:3000/v1"
env_key = "DEEPSEEK_API_KEY"

然后在终端里设置 DeepSeek Key，再用这个 profile 启动：

1
2

export DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

PowerShell 里是：

1
2

$env:DEEPSEEK_API_KEY="your-deepseek-key"
codex --profile deepseek-ccx

这里有两个细节要注意。

第一，base_url 要指向网关暴露给 Codex 的地址，不是 DeepSeek 官方地址。网关背后再去调用 DeepSeek。

第二，env_key 写什么取决于网关怎么鉴权。有的网关直接读取 DeepSeek 官方 Key，有的网关会要求你给它一个本地代理 Key，再由网关自己的后台保存 DeepSeek Key。遇到这种情况，env_key 就应该改成网关要求的环境变量名。

这条路的优点是本地可控，延迟和成本也更容易算清楚。缺点是你必须确认网关真的支持 Codex 当前使用的 Responses 语义，而不是只做了普通 Chat Completions 代理。

方法二：用 OpenRouter BYOK 做线上桥接

如果不想在本地部署网关，可以考虑 OpenRouter 的 BYOK。BYOK 的意思是把你自己的上游供应商 Key 绑定到 OpenRouter，由 OpenRouter 负责路由和转发。

这里最容易写错的是环境变量。Codex 访问的是 OpenRouter，所以 env_key 通常应该是 OPENROUTER_API_KEY，不是 DEEPSEEK_API_KEY。DeepSeek Key 要在 OpenRouter 的 BYOK 或 provider key 设置里添加。

配置示例：

[profiles.deepseek-openrouter]
model = "deepseek/deepseek-chat"
model_provider = "openrouter"

[model_providers.openrouter]
name = "OpenRouter"
base_url = "https://openrouter.ai/api/v1"
env_key = "OPENROUTER_API_KEY"

启动方式：

1
2

export OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

PowerShell：

1
2

$env:OPENROUTER_API_KEY="your-openrouter-key"
codex --profile deepseek-openrouter

然后在 OpenRouter 后台把 DeepSeek 的 provider key 加进去。OpenRouter 的 BYOK 文档说明，绑定的 provider key 会被加密保存，并用于路由到对应供应商。

这条路的优点是省掉本地网关维护成本，配置起来更像普通第三方 API 代理。缺点是中间多了一层线上服务，排障时要同时看 Codex、OpenRouter、DeepSeek 三边的错误信息。

要不要继续用 deepseek-chat 这个模型名？

DeepSeek 官方文档在 2026 年 5 月的说明里，推荐模型名已经出现 deepseek-v4-flash 和 deepseek-v4-pro，并提示 deepseek-chat、deepseek-reasoner 兼容别名会在 2026-07-24 之后废弃。

所以新配置里更建议优先测试：

`1`	`model = "deepseek-v4-flash"`

如果走 OpenRouter，则要按 OpenRouter 的模型命名来写，例如：

`1`	`model = "deepseek/deepseek-chat"`

实际可用名称以你所用网关或 OpenRouter 模型页为准。模型名不对时，错误通常会表现为 model not found、404，或者 provider 找不到对应 endpoint。

直接改 DeepSeek 官方 base_url 为什么不推荐

你当然可以试着写：

[profiles.deepseek-direct]
model = "deepseek-v4-flash"
model_provider = "deepseek"

[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com"
env_key = "DEEPSEEK_API_KEY"

但这更像排错实验，不适合作为稳定方案。因为 Codex 会按 Responses 协议去和自定义 provider 说话，而 DeepSeek 官方示例走的是 /chat/completions。如果 DeepSeek 或 Codex 未来补齐了兼容层，这种直连才可能变得简单；在此之前，桥接层更靠谱。

改完配置后还是走 OpenAI 怎么办

先确认配置文件位置。全局配置应该在：

`1`	`~/.codex/config.toml`

项目里的 .codex/config.toml 不适合放 model_provider、model_providers 这类机器级 provider 配置。OpenAI 官方文档也提醒，项目级配置不会覆盖这些本地 provider 和认证相关字段。

如果 Codex 仍然要求网页登录，或者看起来还在走默认 OpenAI 模型，可以先退出当前登录态：

`1`	`codex logout`

有些旧教程会写成交互界面里的 /logout。在当前 CLI 里，更稳的是直接在终端执行 codex logout。

还可以用临时参数做一次快速验证：

`1`	`codex --profile deepseek-ccx`

或者：

`1`	`codex -c model_provider=ccx-bridge -c model=deepseek-v4-flash`

如果这样能生效，说明配置本身可读；如果不生效，优先检查 profile 名称、TOML 语法、环境变量是否只在当前 shell 里有效。

排障清单

401：Key 不对，或者 env_key 指向了错误的环境变量。
404：base_url 或模型名不对，也可能是把 Responses 请求打到了只支持 Chat Completions 的地址。
tool_calls、patch、流式解析报错：大概率是协议桥接不完整。
仍然提示登录 OpenAI：执行 codex logout，再确认是否用了正确 profile。
PowerShell 设置环境变量后新开窗口失效：$env:... 只对当前会话生效，需要长期保存就改用户环境变量。
OpenRouter BYOK 没走自己的 DeepSeek Key：检查 OpenRouter 后台 provider key 是否绑定、是否允许当前 OpenRouter API Key 使用，以及是否开启了 fallback。

结论

让 Codex 使用 DeepSeek，不是不能改 config.toml，而是不能只改 base_url 就指望一切自动兼容。

当前更稳的两条路是：

用本地网关做协议桥接，Codex 连本地网关，网关再连 DeepSeek。
用 OpenRouter BYOK 做线上转发，Codex 连 OpenRouter，DeepSeek Key 绑定在 OpenRouter 后台。

如果只是想快速试用，OpenRouter 路线更省事；如果你希望 Key、成本、日志都尽量掌握在自己手里，本地网关更适合长期折腾。

参考资料：

CodeGraph 是什么？给 Claude Code、Codex 和 Cursor 加一个本地代码地图

Sat, 23 May 2026 21:09:46 +0800

CodeGraph 是一个给 AI 编程工具使用的本地代码知识图谱。它会提前给项目建立索引，把符号关系、调用图、代码结构、路由关系等信息整理成可查询的图，让 Claude Code、Codex CLI、Cursor、OpenCode、Hermes Agent 这类工具不用每次都靠 grep、glob、Read 和子代理到处翻文件。

它解决的是一个很实际的问题：AI Agent 看大型代码库时，很多成本不是花在真正修改代码上，而是花在“找代码在哪里”。如果每次都重新搜索、读取、筛选，token、时间和工具调用都会被消耗掉。CodeGraph 的思路是先把代码库变成一张本地地图，让 Agent 先问地图，再决定要不要读具体文件。

它主要解决什么痛点

AI 编程工具在小项目里通常还好，文件少，搜索快，读一遍也不贵。但项目一大，常见问题就会出现：

Agent 为了理解一个模块，反复调用 grep、find、ls、Read。
探索子代理读了很多无关文件，主任务上下文却没有变清楚。
问一个架构问题时，token 大量花在定位文件上。
改一个函数前，不知道谁在调用它、它又调用了谁。
Web 项目里，URL 路由和实际处理函数之间的关系不够直观。

CodeGraph 试图把这些“先找路”的工作前置。项目索引建好后，Agent 可以直接查询相关符号、调用方、被调用方、影响范围和代码片段。

安装方式

项目提供跨平台安装脚本，不要求用户自己准备 Node.js：

`1`	`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh \| sh`

Windows PowerShell 可以使用：

`1`	`irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 \| iex`

如果已经有 Node 环境，也可以直接用 npm：

`1`	`npx @colbymchenry/codegraph`

或者全局安装：

`1`	`npm i -g @colbymchenry/codegraph`

安装器会自动检测并配置已安装的 Agent，例如 Claude Code、Cursor、Codex CLI、opencode 和 Hermes Agent。它会写入对应的 MCP server 配置和指令文件，让这些工具知道什么时候调用 CodeGraph。

初始化项目

安装完成后，需要在目标项目里建立索引：

1
2

cd your-project
codegraph init -i

这个命令会生成项目级知识图谱索引。README 中提到，只要项目里存在 .codegraph/ 目录，Agent 就可以自动使用 CodeGraph 工具。

如果不想继续使用，也可以卸载全局配置：

`1`	`codegraph uninstall`

它会移除安装器写入的 MCP server 配置、指令和权限。项目中的 .codegraph/ 索引不会被自动删除，如果要移除项目索引，需要使用 codegraph uninit。

为什么它对 Agent 有用

Claude Code、Codex CLI、Cursor 这类工具在理解代码库时，常常会先做探索：找文件、读入口、查引用、再追调用链。这个过程对人来说像“翻项目”，对模型来说就是一串工具调用和上下文消耗。

CodeGraph 把这一步变成索引查询。Agent 可以先用 codegraph_context 找到相关入口、符号和片段，再用 codegraph_explore 或其他工具读取必要内容。这样做的好处是：

少读无关文件。
少调用搜索工具。
更快找到真正相关的代码。
改动前更容易看清影响范围。
大型仓库里的架构问题更容易回答。

项目 README 给出的基准测试显示，在 7 个真实开源代码库上，对比启用 CodeGraph 和不启用 CodeGraph，平均结果是成本更低、token 更少、速度更快、工具调用更少。具体数字会受项目规模、语言、问题类型和 Agent 使用方式影响，但方向很清楚：越大的仓库，预索引的价值越明显。

核心能力

1. 智能上下文构建

一个工具调用可以返回入口点、相关符号和代码片段，减少 Agent 先派一堆探索任务再慢慢筛选的情况。对架构理解、模块定位、功能入口分析很有用。

2. 全文搜索

CodeGraph 使用 FTS5 做全文搜索，可以在整个代码库里快速按名称和文本查找代码。这不是替代所有 grep 场景，而是让 Agent 有一个更结构化的第一站。

3. 影响分析

在改函数、类、方法或路由前，可以查询 callers、callees 和影响半径。对重构、修 bug、删除旧代码尤其有用，因为最怕的就是只改了当前文件，却漏掉上游或下游调用。

4. 自动保持新鲜

README 中提到，CodeGraph 使用原生文件系统事件，例如 FSEvents、inotify、ReadDirectoryChangesW，并带有 debounce auto-sync。意思是索引会随着本地代码变化自动更新，不需要每改一个文件都手动重建。

5. 多语言支持

项目列出的支持范围超过 19 种语言，包括 TypeScript、JavaScript、Python、Go、Rust、Java、C#、PHP、Ruby、C、C++、Swift、Kotlin、Dart、Lua、Luau、Svelte、Liquid、Pascal / Delphi 等。

这让它更适合多语言仓库和全栈项目，而不是只服务某一种语言。

6. Web 路由感知

CodeGraph 还会识别多种 Web 框架里的路由文件和路由声明，把 URL pattern 和处理函数连接起来。README 中提到的框架包括 Django、Flask、FastAPI、Express、NestJS、Laravel、Rails、Spring、Gin、Axum、ASP.NET、Vapor、React Router、SvelteKit 等。

这点很实用。很多 Web 项目的真实入口不是某个明显的 main 函数，而是路由、controller、handler、view 或 resolver。Agent 如果能先知道 URL 到处理函数的关系，理解业务流程会快很多。

本地优先的设计

CodeGraph 强调 100% local。它不需要 API key，不依赖外部服务，索引数据保存在本地 SQLite 数据库里。

对企业项目、私有仓库或敏感代码来说，这个设计很重要。AI 工具接入代码库时，大家最担心的往往不是“能不能查到代码”，而是“代码结构和索引会不会被发出去”。CodeGraph 的定位是本地构建、本地查询、本地服务 Agent。

当然，本地也意味着要考虑磁盘空间、索引时间、文件监听和项目规模。如果仓库特别大，第一次初始化和后续同步仍然需要资源。

适合哪些场景

CodeGraph 更适合这些场景：

大型代码库，经常需要问架构和调用链问题。
使用 Claude Code、Codex CLI、Cursor 等 Agent 做代码理解和修改。
希望减少 Agent 到处读文件、乱搜、反复探索。
需要在改动前分析影响范围。
Web 项目路由复杂，需要快速从 URL 找到处理函数。
团队希望给 AI Agent 一个更稳定的本地项目索引。

如果只是几十个文件的小项目，普通搜索已经够快，CodeGraph 的优势可能不明显。它最有价值的地方，是中大型代码库和经常让 Agent 做探索的场景。

使用时要注意什么

第一，CodeGraph 不是替代代码审查和测试的工具。它能帮助 Agent 更快找到相关代码，但不能保证 Agent 的修改一定正确。

第二，索引质量会影响使用效果。项目结构复杂、生成代码很多、语言混杂或 build 产物没有排除时，索引可能会变得臃肿。使用前最好确认 .gitignore、项目目录和索引范围是否合理。

第三，MCP 配置和 Agent 指令很关键。README 里也提醒，CodeGraph 只有在被正确查询时才有帮助。如果 Agent 仍然绕开它去大量读文件，预索引就会变成额外开销。

第四，虽然它是本地工具，也要注意权限。安装器会写入 Agent 配置和权限列表，团队环境中最好统一审查这些配置。

小结

CodeGraph 的价值可以简单理解为：给 AI Agent 一张本地代码地图。它不是让模型更聪明，而是让模型少迷路。

当 Claude Code、Codex CLI、Cursor 这类工具面对大型仓库时，最耗费上下文的往往是探索过程。CodeGraph 用预索引的符号关系、调用图、路由图和全文搜索，把“找代码”这一步提前做好，让 Agent 把更多预算花在理解和修改上。

如果你已经在真实项目里使用 AI 编程工具，并且经常遇到“它读了一堆文件还是没找到重点”的情况，CodeGraph 值得试一下。它代表了 AI 编程工具的一个重要方向：不只是换更强的模型，也要给模型更好的本地代码上下文。

参考资料：

GitHub 项目：https://github.com/colbymchenry/codegraph

Claude Code 也有插件市场了：能装什么、怎么装、要注意什么

Sat, 23 May 2026 19:03:30 +0800

anthropics/claude-plugins-official 是 Anthropic 管理的 Claude Code 官方插件目录。它不是一个普通代码库，而是一个可被 Claude Code 插件系统直接使用的 marketplace，集中放置经过 Anthropic 维护或筛选的 Claude Code 插件。

这个仓库值得关注，是因为 Claude Code 正在从“一个 AI 编程命令行工具”变成“可扩展的开发环境”。插件可以把 Skills、Agents、Hooks、MCP servers、LSP servers、后台监控和默认设置打包起来，让团队或社区用统一方式分发。

这个仓库是什么

仓库 README 对它的定位很直接：这是一个高质量 Claude Code 插件的 curated directory。

目录主要分成两块：

/plugins：Anthropic 内部开发和维护的插件。
/external_plugins：来自合作伙伴和社区的第三方插件。

也就是说，它既包含官方能力，也包含经过收录的外部生态入口。对普通用户来说，最直接的意义是可以通过 Claude Code 的 /plugin 系统发现和安装插件；对开发者来说，它提供了观察 Claude Code 插件格式和生态方向的窗口。

如何安装插件

README 给出的安装方式很简单。可以直接通过 Claude Code 的插件系统安装：

`1`	`/plugin install {plugin-name}@claude-plugins-official`

也可以在 Claude Code 里打开插件发现入口：

`1`	`/plugin > Discover`

这里的关键点是 @claude-plugins-official。它代表官方插件目录这个 marketplace。根据 Claude Code 文档，claude-plugins-official 是 Anthropic 维护的官方 marketplace，并且会在 Claude Code 安装中默认可用。

插件长什么样

仓库 README 给出了标准插件结构：

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
├── commands/
├── agents/
├── skills/
└── README.md

其中 .claude-plugin/plugin.json 是插件元数据文件，通常用来声明插件名、描述、版本、作者等信息。其他目录则按需存在：

skills/：放 Claude 可自动调用的技能说明。
commands/：放 slash commands。
agents/：放自定义 agent 定义。
hooks/：放事件触发逻辑。
.mcp.json：配置 MCP server。
.lsp.json：配置语言服务器。
monitors/：配置后台监控。
settings.json：给插件附带默认设置。

这说明 Claude Code 插件不是单一类型扩展，而是一种打包格式。它可以只是一个小命令，也可以是一整套面向某个技术栈的工作流。

官方目录里已经有哪些方向

从 /plugins 目录看，官方维护插件覆盖了不少开发场景，包括：

LSP 类插件：typescript-lsp、pyright-lsp、rust-analyzer-lsp、gopls-lsp、clangd-lsp、csharp-lsp、jdtls-lsp、kotlin-lsp、lua-lsp、php-lsp、ruby-lsp、swift-lsp。
编程工作流：code-review、feature-dev、code-modernization、code-simplifier、commit-commands、pr-review-toolkit。
Claude Code 配置和插件开发：claude-code-setup、claude-md-management、plugin-dev、skill-creator、mcp-server-dev。
输出风格和专项能力：explanatory-output-style、learning-output-style、security-guidance、session-report、math-olympiad。

/external_plugins 里则能看到更多第三方工具和服务方向，例如 github、gitlab、linear、asana、firebase、playwright、terraform、context7、serena、telegram、discord 等。

这组插件透露出一个趋势：Claude Code 不只是想帮你改文件，还想接入代码智能、项目管理、云服务、测试、基础设施和团队协作工具。

为什么插件系统重要

过去很多 Claude Code 自定义能力都可能散落在项目里的 .claude/ 目录中，比如 commands、agents、skills 或 hooks。这种方式适合个人或单个项目，但不方便跨项目复用，也不方便团队统一分发和更新。

插件解决的是可复用和可分发问题：

同一套配置可以跨多个项目安装。
命令和技能有命名空间，减少冲突。
插件可以通过 marketplace 发布和更新。
团队可以把内部最佳实践打包成标准插件。
社区可以围绕某个框架、语言或服务维护专门扩展。

这和 VS Code 插件、JetBrains 插件、浏览器扩展的思路类似：当一个工具开始有稳定插件生态，它就不再只是单一产品，而是在形成平台。

对开发者有什么用

如果你只是 Claude Code 用户，这个仓库最实用的地方是找插件。比如需要 TypeScript、Python、Rust 或 Go 的 LSP 能力，可以先看官方目录里是否已有对应插件；需要 PR review、commit、代码现代化等工作流，也可以从官方插件开始试。

如果你是插件开发者，这个仓库更像样板库。你可以参考它的目录组织、plugin.json 写法、README 说明方式，以及 Anthropic 如何把 skills、agents、MCP、LSP 和 hooks 组合起来。

Claude Code 文档也明确建议：如果只是单项目自定义，可以先用 .claude/；如果需要分享给团队、跨项目复用、版本化发布，或者进入 marketplace，就应该做成插件。

安全边界不能忽略

仓库 README 在开头就提醒：安装、更新或使用插件前必须信任该插件。原因很简单，插件可能包含 MCP server、文件、脚本或其他软件。Anthropic 维护目录，不等于能保证每个插件在你的本地环境中都按你预期运行。

实际使用时建议至少做几件事：

安装前看插件主页和 README。
检查是否包含 .mcp.json、hooks、可执行脚本或后台监控。
对需要访问账号、代码仓库、聊天工具、云服务的插件格外谨慎。
在重要项目中启用插件前，先在测试仓库验证。
团队环境最好统一审核插件来源和版本。

AI 编程插件的权限往往比普通编辑器主题高得多。它可能能读项目文件、调用外部服务、启动本地命令，甚至影响提交和部署流程，所以信任边界要比“装一个小工具”更严格。

和社区 marketplace 的关系

Claude Code 文档提到，Anthropic 维护两个公开插件 marketplace：

claude-plugins-official：Anthropic 维护的 curated 插件集合。
claude-community：第三方提交后进入审查流程的社区插件目录。

这两者的定位不同。社区插件可以通过提交表单进入 review；官方目录则由 Anthropic 自行决定是否收录，没有普通申请流程。换句话说，claude-plugins-official 更像官方精选目录，claude-community 更像开放社区目录。

小结

anthropics/claude-plugins-official 的意义不只是“多了一个 GitHub 仓库”。它说明 Claude Code 的扩展机制正在平台化：Skills、Agents、Hooks、MCP、LSP、后台监控和默认设置都可以被打包、安装、更新和分发。

对个人开发者来说，官方插件目录能降低配置 Claude Code 的门槛。对团队来说，它提供了把内部流程标准化的路径。对插件开发者来说，它给出了 Anthropic 认可的插件结构和生态方向。

接下来值得关注的不是某一个插件本身，而是 Claude Code 插件生态会不会形成稳定分层：官方精选、社区插件、团队私有 marketplace，以及围绕主流语言、框架和 SaaS 服务的专门扩展。如果这条路线走通，Claude Code 会越来越像一个可编排的 AI 开发平台，而不只是一个命令行助手。

参考资料：

GitHub 项目：https://github.com/anthropics/claude-plugins-official
Claude Code 插件文档：https://code.claude.com/docs/en/plugins

oh-my-pi 是什么？一个把终端、IDE 和调试器打通的 AI 编程助手

Sat, 23 May 2026 19:02:20 +0800

oh-my-pi 是一个面向终端和编辑器的 AI Coding Agent。它来自 Mario Zechner 的 Pi 项目分支，由 can1357 继续扩展，目标不是只做一个命令行聊天界面，而是把文件读取、代码搜索、结构化编辑、LSP、调试器、浏览器、子代理和多模型提供商接到同一个编程工作流里。

从项目 README 看，它更像一套 AI 编程工具底座：终端里可以直接交互，编辑器可以通过 ACP 接入，Node 项目也可以通过 SDK 嵌入。对已经在用 Claude Code、Codex CLI、Cline、Cursor 或其他 Agent 工具的人来说，oh-my-pi 值得关注的地方在于它把很多原本分散在外部工具里的能力做成了内置工具面。

它主要解决什么问题

很多 AI 编程工具的短板不在模型本身，而在工具接口。模型想改代码时，如果只能拿到粗糙的全文、脆弱的字符串替换和一次性 shell，失败率就会被工具链放大。

oh-my-pi 的思路是把这些常见摩擦点压低：

读取文件时优先给结构化摘要，而不是把整份文件塞进上下文。
搜索、glob、find、语法高亮、token 计数等能力尽量放进原生实现，减少对外部命令的依赖。
写代码时接入 LSP，让重命名、引用查找、文件移动更接近 IDE 行为。
调试时接入 lldb、dlv、debugpy 等 DAP 工具，而不是只靠日志和猜测。
复杂任务可以拆给子代理，并用结构化结果返回。
对编辑操作使用内容锚点和预览机制，降低错误 patch 直接落盘的概率。

这些设计说明它关注的不是“模型会不会回答”，而是“模型能不能稳定完成一次真实代码修改”。

安装方式

项目提供了几种安装入口。macOS 和 Linux 可以使用安装脚本：

`1`	`curl -fsSL https://omp.sh/install \| sh`

如果使用 Bun，官方推荐全局安装 npm 包：

`1`	`bun install -g @oh-my-pi/pi-coding-agent`

Windows PowerShell 可以使用：

`1`	`irm https://omp.sh/install.ps1 \| iex`

项目 README 还提到可以通过 mise 固定版本：

`1`	`mise use -g github:can1357/oh-my-pi`

安装前要注意 Bun 版本要求。README 中标注的平台范围包括 macOS、Linux、Windows，并要求 bun >= 1.3.14。

值得关注的能力

1. 工具调用不只停留在 shell

oh-my-pi 内置了文件读取、搜索、写入、编辑、AST 编辑、浏览器、任务拆分、调试、LSP 等工具。README 中提到它有 32 个内置工具、13 个 LSP 操作和 27 个 DAP 操作。

这意味着 Agent 不必把所有事情都包装成命令行输出。比如查引用可以走 LSP，读 PR 或 issue 可以走统一的文件式接口，网页和 PDF 可以被转换成带链接结构的 Markdown，再交给模型处理。

2. LSP 接入更适合真实代码库

对大型项目来说，重命名和移动文件最怕漏掉 re-export、别名导入、barrel file 或跨目录引用。oh-my-pi 的 README 特别强调写入路径会接入 LSP，例如文件重命名会经过 workspace/willRenameFiles，让编辑更接近 IDE 的语义操作。

这类能力适合 TypeScript、Rust、Go、Python 等项目里的日常重构，尤其是那些“手动改能改，但很容易漏一个引用”的场景。

3. 调试器是一级工具

很多 AI 编程流程遇到崩溃时，仍然停留在添加日志、重新运行、再读输出。oh-my-pi 把 DAP 调试器接入工具面，README 里举了 C 程序用 lldb、Go 服务用 dlv、Python 进程用 debugpy 的例子。

这会改变 Agent 处理 bug 的方式：它可以暂停进程、查看栈帧、读局部变量，再决定下一步，而不是只靠报错文本猜测。

4. Hashline 编辑降低 patch 失败率

项目强调的 Hashline 是一种基于内容锚点的编辑方式。它的目标是让模型指向要修改的内容锚点，而不是反复输出大段 diff。这样做的好处是减少空格、上下文过期、字符串匹配失败造成的编辑错误。

对 Agent 工具来说，这类机制很重要。模型能力再强，如果写入接口经常失败，最终体验仍然会变成反复重试。

5. 子代理和工作区隔离

README 中介绍了 task 子代理能力：一个任务可以拆给多个隔离 worker，结果再以结构化对象返回。项目还包含工作区隔离相关实现，用来支持并行任务、分支探索和避免互相覆盖。

这适合代码审查、迁移、批量修复、测试定位等任务。真正的价值不只是“并行更快”，而是让不同探索路径之间的上下文和文件改动更清楚。

6. 兼容已有规则和配置

oh-my-pi 首次运行时会读取已有工具留下的规则和配置，包括 .claude、.cursor、.windsurf、.gemini、.codex、.cline、.github/copilot 和 .vscode 等目录。

这点很实用。很多团队已经为不同 AI 工具写过规则，如果每换一个工具都要迁移一遍，成本会很高。oh-my-pi 的做法是尽量直接继承已有上下文。

四种入口

项目提供了四类使用入口：

交互式 TUI：在终端里直接运行 omp。
一次性命令：用 omp -p 发送单次 prompt。
Node SDK：通过 @oh-my-pi/pi-coding-agent 嵌入到 Node 或 TypeScript 项目。
RPC / ACP：通过 stdio 或 Agent Client Protocol 接入其他程序和编辑器。

这说明它不只面向个人终端用户，也给 IDE、插件、自动化平台和内部工具留了集成空间。

适合谁尝试

oh-my-pi 比较适合这几类用户：

经常在终端里做代码修改、调试和审查的人。
已经在使用 AI Coding Agent，但觉得文件读取、patch、搜索或调试链路不够稳的人。
想把 Agent 接入编辑器、RPC 或 Node 服务的开发者。
需要在一个工具里切换多模型和多提供商的人。
对 LSP、DAP、AST 编辑和子代理这些底层能力感兴趣的工具开发者。

如果只是想要一个开箱即用的聊天式代码助手，学习成本可能会偏高。它更适合愿意理解工具链，并把 Agent 当成可配置开发环境的人。

使用时要注意什么

第一，oh-my-pi 仍然是快速演进中的开源项目。仓库提交频繁，issue 和 PR 数量也不少，安装和使用时要预期到变化。

第二，它的能力边界和本地环境强相关。LSP、调试器、Bun、模型提供商认证、终端环境、Windows 或 Unix 差异都会影响体验。

第三，内置工具多不等于每个场景都应该全开。实际使用时更适合按任务启用需要的工具，把规则、权限和工作区边界配置清楚。

第四，AI Agent 能写代码，也能误改代码。即使有预览和锚点编辑机制，重要项目仍然要保留版本控制、测试和人工审查。

小结

oh-my-pi 的亮点不在于又做了一个 AI 终端壳，而在于它把 AI 编程中最容易拖后腿的工具层重新整理了一遍：文件读取、搜索、编辑、LSP、调试、浏览器、子代理和 SDK 都被放进同一个 Agent 工作流。

它适合关注 AI 编程基础设施的人，也适合想比较不同 Coding Agent 路线的开发者。当前 AI 编程工具的竞争，已经不只是模型回答质量的竞争，也是在比谁能把模型稳定接入真实代码库、真实调试流程和真实团队规则。oh-my-pi 正是在这个方向上给出了一套很激进的开源实现。

参考资料：

GitHub 项目：https://github.com/can1357/oh-my-pi
官方站点：https://omp.sh/
SDK 文档：https://omp.sh/docs/sdk

Bun：把 JavaScript 运行时、包管理器、测试和打包合在一起

Sun, 17 May 2026 17:42:25 +0800

Bun 是 oven-sh 开源的 JavaScript / TypeScript 一体化工具链。

它不是只想做一个更快的 Node.js 替代品，而是把运行时、包管理器、脚本运行器、测试运行器和打包器都塞进同一个 bun 命令里。对前端和 Node.js 开发者来说，Bun 的吸引力在于：少装一堆工具，少等一堆安装和构建过程，很多常见任务可以直接用一个命令完成。

项目地址：https://github.com/oven-sh/bun

先说结论

Bun 最适合想简化 JavaScript 工具链的人。

它能做这些事：

运行 JavaScript、TypeScript、JSX 和 TSX。
作为 Node.js 兼容运行时。
替代 npm / yarn / pnpm 做包管理。
运行 package.json 里的 scripts。
执行测试。
打包前端或后端代码。
用 bunx 执行 npm 包里的命令。
提供 Bun.serve、bun:sqlite、Bun.sql、Bun.redis、Bun.s3 等内建 API。

它最明显的价值是开发体验：安装依赖快、启动快、命令统一、TypeScript 和 JSX 开箱即用。

但 Bun 也不是所有项目都该立刻切换。大型 Node.js 项目、依赖大量原生扩展的项目、生产稳定性要求极高的服务，仍然需要逐项验证兼容性、构建行为、测试行为和部署方式。

Bun 是什么

按照官方 README 的描述，Bun 是一个面向 JavaScript 和 TypeScript 应用的一体化工具包。它以单个可执行文件 bun 发布。

它的核心是 Bun runtime：一个快速 JavaScript 运行时，目标是作为 Node.js 的 drop-in replacement。Bun 使用 Zig 编写，底层基于 JavaScriptCore，重点优化启动时间和内存占用。

这意味着你可以直接运行：

`1`	`bun run index.tsx`

TypeScript 和 JSX 不需要额外配置就能跑。

同一个 bun 命令还包含：

test runner
script runner
Node.js 兼容包管理器
bundler
package runner

常见命令包括：

bun test
bun run start
bun install <pkg>
bunx cowsay 'Hello, world!'

过去一个项目里可能同时出现 node、npm、pnpm、tsx、jest、vitest、webpack、esbuild、ts-node 等工具。Bun 的路线是尽量把高频路径收进一个工具里。

安装方式

Bun 支持 Linux、macOS 和 Windows，覆盖 x64 与 arm64。

官方推荐安装脚本：

`1`	`curl -fsSL https://bun.com/install \| bash`

Windows：

`1`	`powershell -c "irm bun.sh/install.ps1 \| iex"`

也可以通过 npm 安装：

`1`	`npm install -g bun`

macOS Homebrew：

1
2

brew tap oven-sh/bun
brew install bun

Docker：

1
2

docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

Linux 用户要注意内核版本。README 提到强烈建议 Linux kernel 5.6 或更高，最低要求是 5.1。

升级到最新版：

`1`	`bun upgrade`

升级到 canary：

`1`	`bun upgrade --canary`

生产环境一般不建议直接用 canary，除非你是在验证新特性或排查特定 bug。

为什么 Bun 会快

Bun 的“快”主要来自几个层面。

第一，运行时启动快。

很多 CLI 工具和开发脚本的瓶颈不是长期 CPU 运算，而是进程启动、模块加载、TypeScript 转译和依赖解析。Bun 针对这些路径做了很多优化。

第二，包管理快。

bun install 的目标是替代 npm / yarn / pnpm 的依赖安装流程。它使用全局缓存和自己的 lockfile，安装大量依赖时通常能明显减少等待。

第三，TypeScript / JSX 开箱即用。

很多项目只是想运行一个 .ts 或 .tsx 脚本，传统 Node.js 工具链需要额外加 tsx、ts-node、Babel 或构建步骤。Bun 可以直接跑，减少了胶水工具。

第四，内置工具减少进程和配置切换。

测试、脚本、打包、运行都在同一个工具里，很多场景不用再在多个 CLI 之间切换。

但要注意，“Bun 很快”不等于每个项目都一定更快。真实效果取决于依赖类型、脚本逻辑、测试框架、构建配置、Node.js API 使用情况和 CI 缓存策略。

包管理：替代 npm / yarn / pnpm

Bun 可以直接安装依赖：

`1`	`bun install`

添加依赖：

`1`	`bun add react`

添加开发依赖：

`1`	`bun add -d typescript`

移除依赖：

`1`	`bun remove react`

查看依赖原因：

`1`	`bun why react`

安全检查：

`1`	`bun audit`

如果你从 npm 或 pnpm 迁移，重点要看：

bun.lock 是否进入版本控制。
CI 是否使用 bun install --frozen-lockfile。
私有 registry 和 .npmrc 是否兼容。
workspace 行为是否符合预期。
lifecycle scripts 是否会带来安全风险。
原本依赖 pnpm 特性的 monorepo 是否能平滑迁移。

小项目可以直接试。大型 monorepo 不建议一次性全切，可以先在单个 package 或 CI 的非关键任务里试。

运行脚本和 TypeScript

Bun 可以运行 package.json 里的脚本：

`1`	`bun run start`

也可以直接运行文件：

1
2

bun run index.ts
bun run index.tsx

这对工具脚本很方便。比如以前项目里有一堆：

scripts/build.ts
scripts/seed.ts
scripts/migrate.ts
scripts/check.ts

如果用 Node.js，通常要解决 TypeScript loader 或预编译问题。Bun 的直接运行能力可以让这些脚本更轻。

不过，如果脚本依赖 Node.js 特定行为，尤其是 loader、ESM/CJS 边界、原生模块、child process、文件监听和某些边缘 API，仍然要测试。

测试运行器

Bun 内置测试运行器：

`1`	`bun test`

它适合想减少 Jest / Vitest 配置的小项目，也适合把一些单元测试、工具测试、库测试迁移到更轻的运行方式。

迁移测试时重点关注：

expect 行为差异。
mock API 差异。
snapshot 行为。
DOM 测试环境。
测试发现规则。
覆盖率输出。
CI reporter 支持。

如果项目已经深度依赖 Jest 生态，比如大量自定义 matcher、复杂 mock、jsdom、babel-jest、ts-jest，迁移就不要太急。可以先让新模块用 bun test，旧测试继续保留原框架。

打包和构建

Bun 也提供 bundler，常见用法是：

`1`	`bun build ./src/index.ts --outdir ./dist`

它可以用于前端包、后端脚本、CLI 工具和库构建。Bun 文档里还覆盖了 loaders、plugins、macros、CSS、HTML、HMR、minifier、single-file executable 等方向。

适合优先尝试的场景：

小型前端工具。
Node.js CLI。
内部脚本。
单文件服务。
不依赖复杂 webpack loader 的项目。

谨慎迁移的场景：

复杂 webpack 插件链。
大量 Vite 插件。
深度依赖 Babel 转换。
特殊 CSS / asset pipeline。
微前端和模块联邦。
对构建产物 hash、chunk、兼容性要求很细的项目。

Bun bundler 很有吸引力，但构建工具迁移的风险通常比包管理更高，最好单独验证。

运行 HTTP 服务

Bun 提供 Bun.serve 来写 HTTP 服务：

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun")
  },
})

这对小型 API、内部服务、Webhook receiver、边缘风格服务很方便。Bun 还提供 WebSockets、Workers、Streams、SQLite、PostgreSQL、Redis、S3、TCP/UDP sockets 等 API。

但如果你已有 Express、Fastify、NestJS、Next.js、Hono、Elysia 等框架，也可以先看它们在 Bun 上的兼容程度，不必为了用 Bun 就重写服务。

更现实的路径是：

先用 Bun 做开发脚本和包管理。
再用 Bun 跑测试。
最后评估是否把运行时切到 Bun。

运行时迁移最需要谨慎，因为它直接影响生产服务行为。

和 Node.js 的关系

Bun 的目标之一是作为 Node.js 的 drop-in replacement，但“兼容”不是“完全等同”。

Node.js 生态已经积累了很多年，很多包依赖细微行为：

CJS / ESM 互操作。
Node 内置模块。
原生扩展。
npm lifecycle scripts。
文件系统边缘行为。
stream 和 Buffer 细节。
worker / child_process。
调试和 profiling。

Bun 在兼容性上进步很快，但生产迁移仍要以测试结果为准。

比较稳妥的判断方式：

你的测试能否在 Bun 下通过。
关键依赖是否支持 Bun。
构建产物是否一致。
CI 和本地表现是否一致。
线上运行是否有监控和回滚。
Docker 镜像和部署脚本是否稳定。

如果只是替换包管理器，风险较低；如果替换生产运行时，风险高很多。

适合哪些项目

Bun 很适合这些场景：

新的 JavaScript / TypeScript 小项目。
内部工具和脚本。
CLI 项目。
需要快速安装依赖的 CI。
希望减少工具链复杂度的前端项目。
对启动速度敏感的脚本和服务。
想用 TypeScript 开箱即跑的开发者。

暂时要谨慎的场景：

超大型 monorepo。
深度绑定 pnpm workspace 行为的项目。
依赖大量 Node.js 原生扩展的服务。
构建链路高度定制的前端工程。
对生产运行时一致性要求极高的后端。
依赖 Jest 复杂生态的测试套件。

一个保守但实用的策略是：先把 Bun 当作开发工具，而不是马上替代全部生产运行时。

迁移建议

如果想在现有项目试 Bun，可以按这个顺序：

在本地安装 Bun。
运行 bun install，观察依赖安装结果。
提交或暂存 bun.lock，避免和原 lockfile 混用造成混乱。
尝试 bun run <script> 跑常用脚本。
用 bun test 迁移少量测试。
在 CI 加一个非阻塞 Bun job。
确认没有兼容问题后，再考虑替换主安装流程。
最后再评估生产运行时是否切换。

对于团队项目，最好保留回滚路径：

迁移前保留原 npm / pnpm / yarn 流程。
CI 里同时跑一段时间。
不要在同一次改动里同时换运行时、包管理器、测试框架和打包器。
把迁移拆成小步骤，每一步都有可验证收益。

这样做虽然慢一点，但不容易把问题混在一起。

常见命令速查

安装：

`1`	`curl -fsSL https://bun.com/install \| bash`

升级：

`1`	`bun upgrade`

安装依赖：

`1`	`bun install`

添加依赖：

`1`	`bun add lodash`

运行脚本：

`1`	`bun run dev`

直接运行 TypeScript：

`1`	`bun run scripts/build.ts`

测试：

`1`	`bun test`

打包：

`1`	`bun build ./src/index.ts --outdir ./dist`

执行包命令：

`1`	`bunx cowsay 'Hello, world!'`

总结

Bun 的价值不只是“比 Node.js 快”。更重要的是，它把 JavaScript / TypeScript 开发里一堆分散工具收进了一个 bun 命令：运行时、包管理器、脚本运行器、测试运行器和打包器。

对新项目和内部工具来说，这种一体化体验很舒服：安装快、启动快、配置少，TypeScript 和 JSX 也能直接跑。对已有大型项目来说，Bun 更适合先从低风险环节切入，比如包安装、脚本和部分测试，再逐步验证构建和运行时。

如果你经常被 Node.js 工具链里的安装速度、配置碎片和测试启动时间折磨，Bun 值得认真试一下。但真正迁移生产服务时，还是要回到最朴素的工程判断：测试能不能过、依赖是否兼容、CI 是否稳定、线上有没有回滚。

参考链接：

Godot 游戏开发入门：从节点、场景到第一个 2D 小游戏

Sun, 17 May 2026 12:37:30 +0800

Godot 是一款开源游戏引擎，适合从 2D 小游戏、独立游戏原型，到中等规模的 3D 项目开发。

它最大的特点是轻量、开源、启动快，节点和场景系统非常清晰。对新手来说，Godot 的门槛通常比 Unity 低；对独立开发者来说，它不绑定商业授权模式，也更容易做出可控的小项目。

这篇文章用最少概念把 Godot 的入门路线讲清楚：你先理解节点和场景，再学 GDScript，最后用一个 2D 小游戏把输入、物理、碰撞、UI、音效和导出串起来。

先说结论

Godot 入门不要一上来就学大而全的引擎功能。

更合理的路线是：

先做 2D，不急着做 3D。
先理解节点和场景，不急着写复杂架构。
先学 GDScript，不急着上 C#。
先做一个能跑、能失败、能重开的小游戏。
再逐步补动画、音效、UI、关卡和导出。

只要做完一个完整小项目，你对 Godot 的理解会比刷十几个零散教程更稳。

Godot 适合什么人

Godot 很适合这几类人：

想从零开始学游戏开发。
想做 2D 独立游戏。
想快速做玩法原型。
不想被复杂商业引擎工具链压住。
想理解游戏引擎底层组织方式。
有一点 Python / JavaScript 经验，想快速上手脚本。

如果你的目标是大型 3A 画面、复杂商业团队管线、现成资产商店生态，Unity 或 Unreal 可能仍然更成熟。但如果目标是学习和做自己的游戏，Godot 非常适合起步。

安装和项目创建

Godot 的安装很简单。

到官网下载安装包，解压后直接运行即可。它不像很多大型引擎那样必须先装完整启动器，也不需要复杂账号流程。

新建项目时，建议先选：

Renderer：默认即可。
Project Name：用英文短横线或下划线。
路径：不要放在中文或空格特别多的目录里。
版本管理：建议从一开始就用 Git。

第一个项目可以叫：

`1`	`first-godot-game`

项目创建后，Godot 会进入编辑器。你需要先熟悉几个区域：

Scene：当前场景的节点树。
FileSystem：项目资源目录。
Inspector：选中节点的属性面板。
Script：脚本编辑区。
2D / 3D 视图：编辑画面和对象位置。

Godot 的核心：节点和场景

Godot 最重要的概念只有两个：节点和场景。

节点是功能单元。比如：

Node2D：2D 对象基础节点。
Sprite2D：显示图片。
CollisionShape2D：碰撞形状。
CharacterBody2D：可移动角色。
Camera2D：2D 摄像机。
AudioStreamPlayer：播放音频。
Label：显示文字。

场景是一组节点的组合。一个角色可以是一个场景，一个敌人可以是一个场景，一个关卡也可以是一个场景。

比如一个玩家角色场景可能长这样：

Player (CharacterBody2D)
├── Sprite2D
├── CollisionShape2D
└── Camera2D

这棵树的意思是：玩家本体负责移动，Sprite2D 负责显示角色图片，CollisionShape2D 负责碰撞，Camera2D 跟随玩家。

Godot 的思路就是：把游戏拆成很多可复用场景，再把场景组合成完整游戏。

第一个 2D 项目做什么

新手第一个项目不要做 RPG、开放世界、联机游戏或复杂平台跳跃。

建议做一个最小 2D 闪避游戏：

玩家可以上下左右移动。
敌人从屏幕边缘出现。
玩家碰到敌人就失败。
存活时间越长分数越高。
有开始按钮、失败界面和重新开始。

这个项目很小，但能覆盖 Godot 入门最重要的东西：

角色移动。
输入系统。
碰撞检测。
敌人生成。
UI 显示。
定时器。
音效。
场景切换。

做完它，你就已经跨过了“只会看教程，不知道怎么组织项目”的第一道坎。

玩家移动怎么写

在 Godot 里，玩家角色通常用 CharacterBody2D。

给 Player 节点挂一个脚本：

extends CharacterBody2D

@export var speed := 300.0

func _physics_process(delta):
    var direction := Vector2.ZERO

    direction.x = Input.get_axis("move_left", "move_right")
    direction.y = Input.get_axis("move_up", "move_down")
    direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

这段代码做了几件事：

读取水平和垂直方向输入。
把方向向量归一化，避免斜向移动更快。
把方向乘以速度，得到 velocity。
用 move_and_slide() 让角色移动并处理碰撞。

还需要在 Project Settings 里设置输入：

move_left  -> A / Left
move_right -> D / Right
move_up    -> W / Up
move_down  -> S / Down

Godot 的输入系统建议一开始就用 action，不要在代码里直接写死键盘按键。这样以后支持手柄、触屏或改键会方便很多。

碰撞和物理怎么理解

Godot 的碰撞不是只靠图片大小判断，而是靠碰撞形状。

常用节点有：

CollisionShape2D：给角色或敌人定义碰撞范围。
Area2D：检测进入、离开、重叠，适合触发器。
CharacterBody2D：适合玩家和会移动的角色。
RigidBody2D：适合受物理力影响的物体。
StaticBody2D：适合墙、地面、固定障碍。

入门阶段记住一个原则：

如果你要自己控制角色移动，用 CharacterBody2D。

如果你只想检测“玩家碰到敌人”，敌人可以用 Area2D，再监听信号：

1
2
3

func _on_body_entered(body):
    if body.name == "Player":
        get_tree().reload_current_scene()

后面项目变复杂时，可以改成发送 game_over 信号，而不是直接重载场景。新手阶段先跑通逻辑更重要。

场景实例化：让敌人不断出现

Godot 的场景可以当成“预制体”使用。

假设你有一个 Enemy.tscn，可以在主场景里用脚本生成它：

@export var enemy_scene: PackedScene

func spawn_enemy():
    var enemy = enemy_scene.instantiate()
    enemy.position = Vector2(800, randf_range(50, 550))
    add_child(enemy)

再配合 Timer 节点，每隔一段时间调用一次 spawn_enemy()，敌人就会不断生成。

这就是 Godot 项目常见组织方式：

一个场景负责一种对象。
主场景负责调度和组合。
需要时动态实例化子场景。

UI 和分数

Godot 的 UI 使用 Control 系列节点。

常用节点包括：

CanvasLayer：让 UI 固定在屏幕上，不跟随相机移动。
Label：显示文字。
Button：按钮。
Panel：面板背景。
VBoxContainer / HBoxContainer：自动排版。

分数可以先用存活时间来做：

var score := 0.0

func _process(delta):
    score += delta
    $CanvasLayer/ScoreLabel.text = str(int(score))

这样每秒增加 1 分。后面可以改成击败敌人、收集金币或完成关卡加分。

音效和反馈

小游戏好不好玩，很大一部分来自反馈。

即使画面很简单，也要加：

移动或点击音效。
碰撞音效。
得分音效。
失败音效。
屏幕震动或闪烁。
按钮 hover / pressed 状态。

Godot 里可以用 AudioStreamPlayer 播放音效：

`1`	`$HitSound.play()`

新手常犯的错误是只做功能，不做反馈。功能能跑只是第一步，玩家能不能感到“我做了一个动作，游戏回应了我”，才是游戏体验的开始。

文件怎么组织

项目一开始就建议整理目录：

res://
├── scenes/
│   ├── Main.tscn
│   ├── Player.tscn
│   └── Enemy.tscn
├── scripts/
│   ├── player.gd
│   └── enemy.gd
├── assets/
│   ├── sprites/
│   └── audio/
└── ui/
    └── GameOver.tscn

不要把所有资源都丢在根目录。小游戏阶段无所谓，项目稍微大一点就会混乱。

一个简单原则是：

场景放 scenes/。
脚本放 scripts/。
图片和音频放 assets/。
UI 单独放 ui/。

Godot 新手常见坑

第一个坑：节点选错。

能自己控制移动的角色用 CharacterBody2D，不是随便用 Node2D。触发检测用 Area2D，固定障碍用 StaticBody2D。

第二个坑：忘记碰撞形状。

只有图片没有碰撞体，游戏不会知道它们撞上了。

第三个坑：把按键写死。

不要直接判断 KEY_A，用输入 action。

第四个坑：场景职责混乱。

不要让一个脚本同时管玩家、敌人、UI、音效和关卡。新手可以简单，但不要所有东西都堆在 Main.gd。

第五个坑：一开始就做大项目。

第一个项目越小越好。只要完整，有开始、有失败、有重新开始，就比半途而废的大项目更有价值。

Godot 和 Unity 怎么选

如果你主要做 2D 独立游戏、教学项目、个人原型，Godot 非常舒服。

如果你需要庞大的资产商店、成熟商业插件、移动广告和商业化 SDK、成熟团队经验，Unity 生态仍然更强。

如果你要做高规格 3D、复杂渲染、影视级画面，Unreal 更适合。

对新手来说，不要把选引擎变成拖延。Godot 足够你做出大量完整小游戏。你真正需要先学会的是：

游戏循环。
输入响应。
碰撞和反馈。
场景组织。
状态管理。
资源和版本管理。

这些能力换到其他引擎也能用。

第一个项目的完成标准

你可以用这个清单判断自己是否真的入门：

玩家能移动。
有敌人或障碍。
有碰撞失败。
有分数或目标。
有开始界面。
有失败界面。
能重新开始。
有至少两个音效。
有简单动画或视觉反馈。
能导出一个可运行版本。

做到这里，你就不是“打开过 Godot”，而是真的完成了一个游戏闭环。

总结

Godot 入门的关键，不是把所有功能看一遍，而是先理解它的组织方式：节点组成场景，场景组成游戏，脚本驱动行为，信号连接事件，资源通过目录管理。

第一个项目建议从 2D 小游戏开始。玩家移动、敌人生成、碰撞失败、UI 分数、音效反馈、重新开始，这几个环节跑通之后，再去学动画树、TileMap、存档、状态机、3D、Shader 和导出优化。

游戏开发不是先学完引擎再开始做，而是在做小项目的过程中反复补概念。Godot 的优势正好在这里：它足够轻，能让你很快从“想做游戏”走到“真的跑起来”。

DeepSeek-TUI：把 DeepSeek V4 变成终端里的编程智能体

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI 是一个把 DeepSeek V4 接入终端开发流程的开源项目。它不是普通聊天壳，而是更接近 Claude Code、Codex CLI 这类“命令行编程智能体”：能看文件、改代码、执行命令、调用工具，并在终端里用 TUI 方式持续推进任务。

如果你已经习惯在编辑器和终端之间切换，这类工具的价值很直接：不用把代码来回复制到网页对话框里，也不用手动描述完整项目结构。你把任务交给它，它可以在当前工作区里读取上下文、规划步骤、执行修改，再把结果交还给你审查。

它解决的是 DeepSeek 的使用入口问题

DeepSeek 模型本身提供了很强的推理和代码能力，但模型能力要落到真实开发流程里，还需要一层工程化外壳。

网页聊天适合问问题，不适合长时间改项目。API 适合接入系统，但普通开发者还要自己写工具调用、上下文管理、文件读写和权限控制。DeepSeek-TUI 想补上的正是这一层：把 DeepSeek V4 包成一个可以在终端里工作的 Agent。

从项目介绍看，它的重点能力包括：

终端 TUI 界面；
面向 DeepSeek V4 的对话与任务执行；
工具调用和文件操作；
1M 上下文支持；
Auto 模式；
子智能体；
沙箱执行；
持久化任务队列。

这些功能组合起来，目标不是“让模型回答得更像人”，而是让模型更容易进入开发现场。

TUI 比纯命令行更适合长任务

很多 AI CLI 工具一开始都是纯文本交互：输入提示词，等待输出，再复制命令或补充上下文。这种方式简单，但任务一长就容易混乱。

TUI 的好处是能把会话、文件、执行结果、任务状态放在一个更稳定的界面里。对编程 Agent 来说，这很重要。因为一次代码任务往往不是一问一答，而是包含：

理解项目结构；
查找相关文件；
修改代码；
运行测试或命令；
根据报错继续修复；
总结变更。

如果界面只是一串日志，用户很难快速判断 Agent 走到了哪一步。TUI 至少给了一个更适合观察和接管的入口。

Auto 模式适合明确边界的任务

DeepSeek-TUI 提到的 Auto 模式，适合用在边界比较清楚的工作里。例如修一个小 bug、补一个脚本、改一段配置、整理一组文档、实现一个局部功能。

这类任务的共同点是：目标清楚，检查方式明确，影响范围可控。Agent 可以自己查文件、改文件、跑命令，然后把结果交给用户确认。

但 Auto 模式不适合无限放权。尤其是在真实项目里，文件删除、批量重构、数据库迁移、部署命令都应该有明确确认。编程 Agent 的效率来自自动化，但风险也来自自动化。越是能执行命令的工具，越需要沙箱、权限边界和人工审查。

子智能体的意义在于拆任务

子智能体不是新概念，但放在代码场景里很有用。

一个稍复杂的任务，通常会同时需要几类工作：有人负责读代码，有人负责改实现，有人负责检查测试，有人负责整理文档。传统多 Agent 系统经常显得花哨，是因为它们没有真实工具和真实工作区，只是在对话里互相讨论。

如果子智能体能结合文件系统、命令执行和任务队列，它就更像一种任务拆分机制。比如一个子智能体专门分析依赖关系，另一个负责修改某个模块，主智能体再整合结果。这样可以减少单个上下文里堆太多无关信息的问题。

当然，子智能体也会带来额外成本：更多 token、更复杂的状态、更难追踪的责任边界。所以它适合中等复杂度以上的任务，不一定适合每一次小修改。

1M 上下文不是万能，但很适合读项目

1M 上下文听起来很夸张，但在编程场景里并不只是营销数字。

真实代码库的上下文很碎：README、配置文件、类型定义、测试、调用链、历史约定、错误日志，都可能影响一次修改。更长上下文能减少“只看局部就动手”的问题，也能让模型保留更多项目约束。

不过，上下文长不等于判断一定更准。代码任务仍然需要检索、筛选和验证。把整个项目塞进上下文并不一定比精准读取相关文件更好。好的编程 Agent 应该把长上下文当作缓冲区，而不是把它当成替代工程判断的捷径。

更适合哪些用户

DeepSeek-TUI 更适合几类人：

想在终端里使用 DeepSeek 做代码任务的开发者；
不想自己搭工具调用和文件操作框架的人；
已经熟悉 Claude Code、Codex CLI，但想尝试 DeepSeek 模型入口的人；
需要本地项目上下文，而不是只在网页里问代码片段的人；
想把 AI 编程流程放进命令行环境的人。

如果你只是偶尔问一个函数怎么写，网页聊天已经够用。如果你希望模型直接参与项目修改，终端 Agent 才更有意义。

需要关注的风险

这类工具最需要关注三件事。

第一是权限。只要工具能读写文件、执行命令，就要确认它默认能访问哪里、能不能删除文件、能不能联网、危险命令是否需要确认。

第二是可回滚。使用前最好保持 Git 工作区干净，让每次 Agent 修改都能被 git diff 清楚看到。不要在一堆未提交改动里让 Agent 自动改项目。

第三是验证。Agent 写完代码不代表任务完成。测试、构建、lint、人工 review 仍然要保留。AI 编程工具可以提高推进速度，但不能替代最后的工程确认。

总结

DeepSeek-TUI 的意义不在于又多了一个聊天客户端，而在于它把 DeepSeek V4 放进了更接近真实开发工作的终端环境里。

对开发者来说，模型能力只是第一步。真正影响体验的是：它能不能读项目、能不能安全改文件、能不能执行验证命令、能不能在长任务里保持状态、能不能让用户随时接管。

如果你想把 DeepSeek 用在日常代码修改、项目阅读和自动化开发任务里，DeepSeek-TUI 值得关注。它代表的方向也很清楚：AI 编程工具正在从“回答代码问题”转向“参与项目执行”。

Codex 手机远程访问来了：用 ChatGPT App 跟进 Mac 上的编程任务

Sat, 16 May 2026 17:42:40 +0800

OpenAI 在 2026 年 5 月中旬把 Codex remote access 带进了 ChatGPT 手机 App。这个功能的重点不是“在手机上写代码”，而是让你用手机远程跟进 Mac 上正在运行的 Codex。

它更像一个移动审批和监控入口：Codex 继续在电脑上读项目、跑命令、改文件、看测试结果；手机端负责查看进度、回答问题、补充指令和批准操作。

对经常让 Codex 跑长任务的人来说，这个变化很实用。你不必一直坐在电脑前等它卡在哪里，出门或离开工位后，也能从 ChatGPT App 里接上现场。

它能做什么

根据 OpenAI Codex remote connections 文档，手机端远程访问可以做这些事：

在 Mac 主机上的项目里开启新线程，或继续已有线程；
发送后续指令，回答 Codex 提出的问题，调整任务方向；
批准命令和其他操作；
查看输出、diff、测试结果、终端输出和截图；
在 Codex 完成任务或需要你注意时收到通知；
在多个已连接主机和线程之间切换。

也就是说，手机端不是一个简化版聊天窗口，而是接入了 Codex 当前工作现场。你看到的不只是模型回复，还有它在主机上产生的工程上下文。

使用前需要什么

当前手机远程访问有几个前提。

第一，你需要有可用的 Codex 权限，并且手机和 Mac 使用同一个 ChatGPT 账号与 workspace。

第二，手机上要安装最新版 ChatGPT App，iOS 或 Android 都可以。如果 App 里看不到 Codex，先更新 ChatGPT。

第三，主机目前要求是 Mac，并且需要保持在线、唤醒、正在运行 Codex App。OpenAI 文档明确写到，移动端设置和设备控制当前需要主机上运行 Codex App for macOS，不能从 Codex CLI 或 IDE Extension 里完成设置。

第四，如果账号或 workspace 要求 MFA、SSO 或 passkey，需要先完成对应认证。团队 workspace 还可能需要管理员开启 Remote Control access。

这些限制说明它目前更像是 Codex App for macOS 的移动控制能力，而不是通用远程桌面，也不是所有 Codex 入口都能用。

Codex 手机远程访问的限制

这个功能虽然很方便，但限制也要提前看清楚。

第一，当前需要 macOS host。手机端连接的是 Mac 上运行的 Codex App，不是直接连接 Codex CLI、IDE Extension，也不是任意 Linux / Windows 开发机。

第二，主机必须在线。Mac 需要保持唤醒、联网，并持续运行 Codex App。如果电脑睡眠、断网或 Codex 关闭，手机端远程会话就可能断开。

第三，连接依赖扫码流程。你需要先在 Mac 端打开 Set up Codex mobile，再用手机扫描二维码进入 ChatGPT 完成绑定。它不是输入一个地址就能直接连，也不是纯账号登录后自动发现所有设备。

第四，远程操作仍然要经过审批流程。手机端可以批准命令和其他操作，但这也意味着你需要看清 Codex 请求做什么，再决定是否继续。尤其是涉及终端命令、文件修改、测试运行和外部访问时，不应该把手机审批当成无脑点确认。

所以它适合“人离开电脑后继续跟进任务”，不适合替代完整开发环境，也不适合把主机长期无人值守地开放给远程操作。

怎么连接

设置流程从 Mac 上的 Codex App 开始。

在 Mac 上打开 Codex。
在侧边栏选择 Set up Codex mobile。
Codex 会为这台主机开启远程访问，并显示一个二维码。
用手机扫描二维码，进入 ChatGPT 里的 Codex mobile setup 流程。
确认同一个 ChatGPT 账号和 workspace。
完成必要的 MFA、SSO 或 passkey 验证。
设置成功后，这台 Mac 会出现在手机端 Codex 里。

连接完成后，可以在 Mac 端 Codex 的 Settings > Connections 管理已连接设备。这里也可以设置是否让电脑保持唤醒、是否启用 Computer Use、是否安装 Chrome extension。

手机端适合干什么

手机端最适合三类操作。

第一类是审批。Codex 需要运行命令、访问文件、继续某个动作时，你可以在手机上看清请求，再决定是否批准。

第二类是纠偏。比如 Codex 走偏了、误解了需求、测试失败后需要你选方向，你可以直接补一句说明，让它继续处理。

第三类是查看结果。你可以看 diff、测试输出、终端日志和截图，不必回到电脑前才知道任务跑成什么样。

这和“手机写代码”不是一回事。真正有价值的是把手机变成工程任务的随身控制台，让 Codex 在主机上干重活，人只在关键节点介入。

常见问题

如果手机上看不到主机，先确认 Mac 上 Codex App 仍在运行，并且开启了 Allow other devices to connect。手机和主机也必须使用同一个 ChatGPT 账号与 workspace。

如果审批请求没有出现，可以打开 ChatGPT 手机 App，进入 Codex，再重新扫码或从主机重新开始设置。团队账号还要确认管理员是否已经允许 Remote Control access。

如果远程会话断开，通常要检查三件事：Mac 是否睡眠、网络是否断开、Codex App 是否关闭。远程访问依赖主机保持唤醒和联网。

如果认证卡住，就先完成账号或 workspace 的 MFA、SSO、passkey 流程。企业环境里，权限问题往往要管理员介入。

适合哪些场景

这个功能适合这些人：

经常让 Codex 跑较长的代码修改任务；
需要在通勤、会议间隙、离开工位时继续跟进任务；
希望及时审批命令，而不是让 Codex 停在等待状态；
同时管理多个项目或多个 Codex 线程；
使用 Mac 作为主力开发机，并已经习惯 Codex App。

不太适合这些场景：

主要使用 Windows 或 Linux 主机；
只用 Codex CLI 或 IDE Extension；
希望手机端独立完成完整开发环境；
网络不稳定，或 Mac 经常休眠；
团队 workspace 没有开启远程控制权限。

我的判断

Codex 手机远程访问的意义，不是把开发工作搬到手机屏幕上，而是把“等待 Codex 跑完”的时间变得更可控。

以前 Codex 长任务经常卡在审批、追问、测试失败或方向确认上。现在这些节点可以通过 ChatGPT 手机 App 处理，Mac 继续做真正的工程执行，手机负责轻量决策。

这会让 Codex 更像后台工程代理：它可以在电脑上持续工作，人不用一直盯着终端，只需要在需要判断的时候回来。限制也很清楚，目前它强依赖 macOS 上的 Codex App、同一账号 workspace、主机在线和组织权限。

如果你已经在 Mac 上重度使用 Codex，这个功能值得开启。如果你还只是偶尔问几句代码问题，它的价值可能没有那么明显。

参考资料

Claude Code + Ollama 本地部署教程：用 CC Switch 打造免费 AI 编程助手

Fri, 15 May 2026 23:27:50 +0800

最近 Claude Code 在 AI 开发工具圈很火，原因不难理解：它不像普通聊天机器人那样只回答问题，而是可以读取项目、修改代码、执行终端命令、安装依赖，并尝试自动修复报错。

真正的问题在成本。Claude 官方 API 在长上下文、大型项目、多轮 Agent 调用和自动修 Bug 场景下，Token 消耗会很快变大。于是出现了一种新的玩法：继续使用 Claude Code 的 Agent 外壳，但把模型请求转发给本地 Ollama。

这条链路的关键工具是 CC Switch。

这套方案解决什么问题

可以把它理解为：

1
2
3

Claude Code 桌面版
+ CC Switch API 转发层
+ Ollama 本地模型

Claude Code 继续负责项目操作、终端执行、文件修改和 Agent 流程；真正负责推理的大模型，则换成本地运行的 Qwen、DeepSeek、Gemma、GLM 等模型。

这样做的吸引力很直接：

不依赖 Claude 官方 API。
没有持续 Token 计费压力。
模型和数据可以留在本机。
小项目、脚本、网页、运维任务可以低成本反复试。

但它不是“免费获得 Claude Sonnet 能力”。本地模型的工程理解、长上下文稳定性和复杂任务规划，仍然会受模型能力、显存、量化版本和上下文长度限制。

基本准备

前置环境主要包括：

安装 Git。
安装 Claude Code 官方桌面版。
安装最新版 Ollama 客户端。
下载 CC Switch 开源工具。
在 Ollama 中准备合适的本地模型。

模型选择可以按显存来定。常见选择包括：

Qwen 3.6 / Qwen 3.5
Gemma4
DeepSeek R1
GLM

如果显存不大，优先选择较小参数或较低量化版本。不要一开始就用超大模型，否则很容易出现加载慢、上下文短、响应卡顿或直接显存不足。

CC Switch 关键配置

这套方案里最关键的配置项是下面几项。

请求地址：

`1`	`http://127.0.0.1:11434/v1`

API 格式：

`1`	`OpenAI Chat Completions`

认证字段选择：

`1`	`ANTHROPIC_API_KEY`

Claude Code 桌面版的自定义配置文件末尾，还需要加入注册表修改命令：

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

这一步的作用，是让 CC Switch 把模型名称注入到 Claude Code 里显示。Claude Code 以为自己在调用 Claude 模型，实际请求已经被 CC Switch 转发到了本地 Ollama。

Claude Code 强在哪里

很多人第一次接触 Claude Code，会把它当成高级聊天工具。但它和普通 AI 聊天客户端不太一样。

普通聊天式 AI 通常是：

1
2

你问一句
它答一句

Claude Code 更接近：

`1`	`AI + IDE + Terminal`

它可以读取项目结构，例如：

src/
components/
package.json
docker-compose.yml

然后尝试完成一串操作：

分析代码。
修改文件。
安装依赖。
执行命令。
查看报错。
再次修改。
重新运行项目。

这也是为什么很多开发者把它叫做 AI 开发 Agent。它的价值不只是“写一段代码”，而是能围绕项目状态连续行动。

Ollama 在这里扮演什么角色

Ollama 负责在本机运行模型。

这套组合的核心逻辑是：

Claude Code 负责 Agent 能力和项目操作。
CC Switch 负责把 Claude Code 的请求转成兼容本地模型的 API。
Ollama 负责实际推理。
本地模型返回结果后，再交给 Claude Code 继续执行。

所以，这不是把 Ollama 变成一个普通聊天窗口，而是把它接进 Claude Code 的工作流。

对于小型任务，这种组合会很有吸引力。比如：

生成一个 HTML 页面。
修改小型前端项目。
写自动化脚本。
处理 Docker 配置。
做 VPS 运维辅助。
生成简单工具或测试代码。

类似“帮我生成一个赛博朋克风格的个人主页网站”这类任务，本地模型可以完成项目创建、网页生成、动画和特效配置，并尝试自动运行。

体验边界在哪里

这套玩法很有意思，但边界也要说清楚。

目前本地模型仍然很难完全替代 Claude Sonnet，尤其在这些场景里：

长上下文理解。
大型工程结构分析。
多步骤推理。
复杂项目架构调整。
长时间连续修 Bug。

项目一复杂，本地模型更容易出现：

逻辑混乱。
修改错误文件。
反复修同一个 Bug。
忘记前文上下文。
对项目结构判断不稳定。

所以更合理的定位是：它适合低成本试验、小项目、脚本任务和局部代码修改；不适合一开始就把大型生产项目完全交给它自动改。

多模态兼容性还不稳定

这套链路还有一个明显问题：Vision 多模态兼容性。

虽然 Ollama 已经支持一些 Vision 模型，但 Claude Code + CC Switch + Ollama 这条链路对图片支持并不完整。常见情况是：用户上传了图片，但 AI 仍提示没有看到图片。

这并不一定是模型不支持 Vision，而是整条链路里：

Claude Code 更偏代码 Agent。
CC Switch 主要处理 API 转发。
Ollama 模型能力和请求格式还要匹配。
图片输入在不同客户端和模型之间并不总是无缝传递。

所以目前更适合的场景还是：

编程。
终端操作。
项目文件修改。
自动化脚本。

而不是：

图片理解。
OCR。
多模态聊天。
复杂视觉任务。

适合谁尝试

这套方案适合几类人：

想体验 Claude Code Agent 工作流，但不想持续消耗 Claude API 的用户。
已经在本机跑 Ollama 的本地大模型玩家。
做小项目、脚本、网页、运维工具的开发者。
想测试本地模型真实编程能力的人。
对数据本地化更敏感的用户。

不太适合：

完全不想折腾配置的人。
希望获得 Claude Sonnet 同等能力的人。
需要稳定处理大型生产代码库的人。
强依赖图片输入和多模态能力的人。

使用建议

如果要尝试，建议按低风险方式开始：

先用测试项目，不要直接接生产仓库。
选择中小模型，确认 Ollama 本身运行稳定。
先做 HTML、脚本、配置文件这类简单任务。
每次修改后自己检查 git diff。
不要让它在不确认的情况下批量删除或重构文件。
多模态任务暂时不要依赖这条链路。

如果项目比较复杂，最好把任务拆小：让它只改一个模块、一个函数、一个页面或一个配置文件。这样比“一句话让它重构整个项目”可靠得多。

小结

Claude Code + Ollama + CC Switch 的意义，不是让本地模型立刻变成 Claude Sonnet，而是把本地模型接进一个真正能操作项目的 Agent 外壳里。

这让本地 AI 开发助手第一次变得更接近真实生产力工具：它可以看项目、改文件、跑命令、修错误，而不是只在聊天框里给建议。

但它的能力上限仍然取决于本地模型本身。小项目和自动化任务会很有价值；大型工程、长上下文和复杂推理仍然需要更强模型。

如果你的目标是“零 API 成本、无 Token 焦虑、在本机反复试 AI 编程 Agent”，这套方案值得折腾。只是要记住：它是本地开发助手，不是万能自动程序员。

Ghostty 文档速读：安装、配置与日常使用要点

Fri, 15 May 2026 14:50:11 +0800

Ghostty 是一个新的终端模拟器，但它并不只是“又一个更快的终端”。按照官方文档的说法，它想同时兼顾三个方向：速度、功能和原生桌面体验。也就是说，它既希望有 GPU 加速和较好的渲染性能，也希望在 macOS 和 Linux 上尽量像一个真正的本地应用，而不是把所有交互都塞进自绘界面里。

如果你正在用 iTerm2、Kitty、Alacritty、WezTerm 或系统自带终端，Ghostty 最值得关注的地方不是某一个单点功能，而是它把“开箱即用”和“深度可配置”放在了一起。默认配置已经能直接使用；想继续折腾时，文档又给了配置文件、主题、快捷键、字体、Shell 集成和终端控制序列等完整入口。

先看定位

Ghostty 的核心定位可以概括为三句话：

它是跨平台终端模拟器，目前重点覆盖 macOS 和 Linux。
它使用平台原生 UI：macOS 端使用 Swift、AppKit 和 SwiftUI，Linux 端使用 Zig 和 GTK4。
它的终端核心是 libghostty，GUI 应用围绕这个共享核心构建。

这个设计会影响日常体验。比如标签页、分屏、错误提示、窗口状态恢复、系统快捷键等能力，不是简单做成“看起来像桌面应用”的组件，而是尽量贴近所在系统的交互习惯。macOS 和 Linux 默认快捷键也会按各自平台约定区分。

安装方式：macOS 最直接，Linux 看发行版

官方预构建二进制主要面向 macOS。最普通的安装方式是下载 .dmg，打开后把 Ghostty 拖到 Applications 目录。Homebrew 用户也可以用社区维护的 cask：

`1`	`brew install --cask ghostty`

Linux 的情况更分散。Ghostty 文档把不同发行版的包管理器、社区二进制和源码构建分开说明。Arch、Alpine、Gentoo、NixOS、Snap、Solus、Void 等都有对应路径；如果发行版没有官方或可信仓库，文档更倾向于让用户从源码构建，而不是随意安装第三方二进制。

这点对服务器和工作机尤其重要：终端模拟器会处理大量输入输出、剪贴板、链接、SSH 会话和本地文件路径。安装源最好保守一点，优先选官方 macOS 包、发行版仓库或自己能审计来源的构建流程。

配置：先别急着复制一大份 dotfiles

Ghostty 的配置哲学是“零配置可用”。默认字体内置 JetBrains Mono，也带有 Nerd Font 支持；大多数用户第一次打开就能正常工作。文档甚至建议，如果你发现必须配置某个非主观选项才舒服，可以先考虑它是不是应该成为默认行为。

真正需要定制时，Ghostty 使用文本配置文件。当前配置文件名是 config.ghostty，旧版本也支持 config。常见路径包括：

$XDG_CONFIG_HOME/ghostty/config.ghostty
$XDG_CONFIG_HOME/ghostty/config
$HOME/.config/ghostty/config.ghostty
$HOME/.config/ghostty/config

macOS 还会读取：

1
2

$HOME/Library/Application Support/com.mitchellh.ghostty/config.ghostty
$HOME/Library/Application Support/com.mitchellh.ghostty/config

配置语法非常直接，就是 key = value。例如：

font-family = JetBrains Mono
font-size = 14
theme = light:Rose Pine Dawn,dark:Rose Pine
keybind = ctrl+shift+t=new_tab

一个实用建议是：不要一开始就找别人的完整配置照抄。更稳的方式是先裸跑几天，只改三类东西：字体、字号和主题。等你真的发现快捷键、分屏、窗口、Shell 集成有摩擦，再逐项加配置。

文档查询：本地也能查完整配置

Ghostty 的配置项很多，官方文档把它们集中在 Option Reference。除了网页，安装后也可以从本地查配置参考：

`1`	`ghostty +show-config --default --docs`

这个命令会把默认配置和文档输出到标准输出，适合接到分页器里慢慢搜：

`1`	`ghostty +show-config --default --docs \| less`

查看可用字体时可以用：

`1`	`ghostty +list-fonts`

查看内置和可用主题时可以用：

`1`	`ghostty +list-themes`

查看默认快捷键时可以用：

`1`	`ghostty +list-keybinds --default`

这些命令比在网上复制片段更可靠，因为它们来自你当前安装的 Ghostty 版本。

快捷键：把“动作”当成核心概念

Ghostty 的快捷键配置格式是：

`1`	`keybind = trigger=action`

trigger 是按键触发方式，action 是 Ghostty 执行的动作。比如新建标签页、关闭当前 surface、重新加载配置、跳转到提示符等，都属于 action。这个模型的好处是清晰：你不是在“改某个菜单项”，而是在把一个输入序列绑定到一个动作。

配置改完后，可以在运行时重新加载。默认快捷键是：

Linux：ctrl+shift+,
macOS：cmd+shift+,

不过并不是所有配置都能即时生效。有些选项只影响新建终端，有些需要完整重启。遇到“配置写了但没变化”时，先查对应选项说明，比反复怀疑语法更省时间。

主题和字体：先用内置，再做细调

Ghostty 自带大量主题，并支持按系统浅色、深色模式切换不同主题：

`1`	`theme = light:Rose Pine Dawn,dark:Rose Pine`

主题也可以来自自定义文件。文档提醒得很明确：主题文件本质上也是 Ghostty 配置文件，可以设置很多配置项，所以不要随便使用不可信来源的主题。

字体方面，font-family 可以重复多次，用来指定 fallback 字体。对多语言环境很实用，比如主字体负责英文和符号，后续字体补中文、日文或其他字符。遇到 emoji、粗体、斜体、连字等显示细节时，再去 Option Reference 里查对应选项即可。

Shell 集成：SSH 用户尤其应该看

Ghostty 支持自动注入 shell integration，覆盖 bash、elvish、fish、nushell 和 zsh。启用后，一些体验会更自然，比如：

新终端从前一个终端的工作目录打开。
复杂提示符 resize 时可以重绘，而不是被错误回流。
可以通过提示符标记在命令输出之间跳转。
在提示符处支持更符合编辑习惯的光标行为。

如果不想自动注入，可以在配置里关闭：

`1`	`shell-integration = none`

更值得注意的是 SSH。Ghostty 使用 xterm-ghostty 作为 TERM，但很多远程主机还没有对应的 terminfo。文档提供了 ssh-env 和 ssh-terminfo 两个 shell integration 功能，默认关闭，可以按需启用：

`1`	`shell-integration-features = ssh-env,ssh-terminfo`

如果你经常连接旧服务器、容器、跳板机或严格管理的生产环境，建议先读完官方的 Terminfo 和 Shell Integration 文档，再决定是否启用这些功能。终端能力协商看起来不起眼，但一旦出问题，表现可能是颜色异常、快捷键失灵、全屏程序显示错乱。

我的上手顺序

如果只是想判断 Ghostty 是否适合自己，可以按这个顺序试：

安装后不写配置，直接用一天。
只调整 font-family、font-size 和 theme。
用 ghostty +list-keybinds --default 看默认快捷键，而不是先搬运别人的快捷键表。
如果常用 SSH，优先检查远程主机的 terminfo 兼容问题。
最后再处理分屏、窗口、透明度、标题栏、背景图等视觉和工作流偏好。

Ghostty 文档写得比较工程化，适合把它当成“配置参考手册”而不是“宣传页”阅读。对多数用户来说，真正的判断标准也很简单：默认体验是否已经舒服，日常编辑器、Shell、SSH、tmux 或 Zellij 是否稳定。如果这几件事都顺，Ghostty 就值得进入你的长期终端候选列表。

参考链接

Prompt-Vault：一个适合测试 AI 编程能力的 Prompt 规格库

Fri, 15 May 2026 09:00:52 +0800

w512/Prompt-Vault 是一个很小但有用的 prompt 仓库。它不是收集“万能咒语”，而是把一组可执行的 coding prompt 按难度整理成规格文档，用来测试 LLM 或 coding agent 能不能真正完成一个小项目。

项目地址：https://github.com/w512/Prompt-Vault

截至写作时，这个仓库只有少量文件和提交，但结构很清楚：Easy、Medium、Hard 三个目录，每个 Markdown 文件都是一个独立任务。README 里也写得很直接：这些 prompt 适合测试大语言模型，或者给开发者当练手项目。

它不是 prompt 收藏夹

很多 prompt 仓库的问题，是内容看起来很多，但很难判断质量。标题很吸引人，真正拿去用时却缺少验收标准。

Prompt-Vault 更像一个小型规格库。每个任务都尽量写清楚：

要做什么应用
必须有哪些功能
UI 应该是什么风格
技术约束是什么
是否必须单文件运行
是否允许外部依赖
数据是否需要持久化

这种结构比“请帮我做一个好看的看板”更适合测试模型。因为它能看出模型是否真的理解需求，而不是只生成一份看似完整的页面。

Easy：测试基础交互

Easy 目录里有两个任务。

第一个是 Bubble_Sort_Visualizer.md，要求做一个单文件 index.html，用柱状条实时展示冒泡排序。它要求有开始按钮、重置按钮、速度滑块、比较次数统计和深色主题。

这个任务适合测试模型的基础前端能力：

能不能把算法状态映射到 UI
能不能做动画节奏控制
能不能正确处理重置和运行状态
能不能保持代码简单可读

第二个是 ToDo_List.md，从静态 HTML 开始，一步步增加添加任务、完成状态、删除按钮、计数器、Active / Completed 统计和 localStorage 持久化。

这个任务看起来普通，但很适合测试模型是否会按步骤演进，而不是一口气堆出一份混乱代码。

Medium：测试复杂状态和动画

Medium/Sorting_Visualization.md 把排序可视化升级了一档。

它要求同一个页面支持 6 种排序算法：

Bubble Sort
Insertion Sort
Selection Sort
Merge Sort
Quick Sort
Heap Sort

同时还要有算法选择、速度滑块、数组大小滑块、重置按钮、开始 / 暂停切换，以及实时统计面板。

这个任务能测出不少问题。很多模型可以写出一个冒泡排序动画，但一旦要支持多个算法、暂停恢复、统计比较次数和交换次数，就容易出现状态混乱。

如果用它做评测，可以重点看这些点：

每种算法是否真的按预期排序
动画是否和算法步骤一致
暂停后能否继续
重置是否会停止旧动画
数组大小变化是否会破坏状态
统计数据是否可信

这类 prompt 很适合作为前端 coding agent 的中等难度 smoke test。

Hard：测试完整产品感

Hard 目录目前有两个任务。

一个是 Kanban_Board.md。它要求做一个完整的看板应用：默认四列、可新增列、双击重命名、空列删除、卡片标题和描述、优先级、截止日期、拖拽、搜索、优先级过滤、localStorage 持久化、底部统计栏、深色玻璃拟态风格和响应式横向滚动。

这个 prompt 的价值在于它不是只测单点能力，而是测“产品完整度”：

原生 Drag & Drop 是否可靠
新增列和卡片后状态是否持久化
搜索和过滤是否影响布局
overdue 逻辑是否正确
Done 列是否触发视觉状态变化
删除、重命名、取消、保存这些边界是否完整

另一个是 Markdown_Editor_Desktop.md，要求用 Tauri 2 做跨平台 Markdown 编辑器。它包含分栏编辑与预览、同步滚动、实时渲染、预览模式、专注模式、打开文件、保存、另存为、窗口标题未保存标记、格式化工具栏、快捷键、主题、字体设置、Vue 3、Pinia、marked.js、prism.js 和 Tauri 插件。

这已经不是普通网页 prompt，而是一个能测试桌面应用工程能力的规格。模型需要理解前端状态、Tauri 插件、文件系统权限、IPC 边界和跨平台打包。

为什么这种仓库有价值

Prompt-Vault 的价值不在于任务数量，而在于它给了可复用的评测样本。

如果你在比较不同模型或 coding agent，可以用同一个 prompt 反复测试：

哪个模型更能遵守约束
哪个模型更少漏功能
哪个模型更会处理边界状态
哪个模型生成的代码更容易维护
哪个模型更擅长 UI 细节
哪个模型在单文件约束下更稳定

这比“我感觉这个模型更聪明”可靠得多。

尤其是前端任务，很多失败不是语法错误，而是体验细节缺失。比如按钮能不能禁用、动画是否卡住、刷新后数据是否还在、拖拽目标是否高亮、统计是否同步更新。这些都需要具体 prompt 才能测出来。

可以怎么扩展

如果要把 Prompt-Vault 变成更完整的评测库，可以继续补几类任务。

第一类是验收清单。每个 prompt 后面加一组 checklist，比如“刷新后任务仍存在”“删除空列成功，非空列不能删除”“暂停排序后数组状态不变”。这样人和 agent 都更容易验收。

第二类是失败用例。比如给排序可视化任务补充“快速连续点击 Start / Reset 不应产生多个动画循环”。这能测出状态管理是否扎实。

第三类是评分维度。可以按功能完整度、代码可维护性、UI 质量、可访问性、性能、边界处理打分。

第四类是参考实现。不是为了让模型抄答案，而是给评测者一个基准，方便判断输出是不是合理。

第五类是跨模型记录。把不同模型在同一 prompt 下的结果、失败点和 token 成本记录下来，就能形成真正的 coding benchmark。

使用建议

如果你想用这个仓库测试 AI 编程工具，建议不要只看“能不能生成页面”。

更好的做法是：

选一个 prompt，原样交给模型。
不做额外提示，看第一次输出能完成多少。
打开生成结果，按功能逐项验收。
记录漏掉的功能和明显 bug。
再给一次修复机会。
比较总耗时、token 成本和最终代码质量。

这样测出来的结果更接近真实开发。因为真正的 coding agent 不只是生成代码，还要理解规格、处理反馈、修复缺陷，并保持代码可维护。

小结

Prompt-Vault 是一个轻量级 prompt 规格库。它适合拿来做 AI 编程测试，也适合前端开发者练习小项目。

它提醒我们：好的 prompt 不只是描述愿望，而是写清需求、约束、交互、状态、验收和运行方式。越是想测试模型能力，越不能只给一句模糊指令。

如果你正在比较 Codex、Claude Code、Cursor、Gemini CLI 或其他 coding agent，这类分级 prompt 很值得收藏。它们能帮你把“感觉好用”变成“具体哪里做对了，哪里漏了，修一次能不能补回来”。

Token Efficiency 是什么？从 DeepSeek V4 看大模型规划、小模型执行

Fri, 15 May 2026 08:59:33 +0800

AI 编程接下来真正重要的指标，可能不是“谁的模型最强”，而是谁能用更少的 token、更低的成本、更稳定的流程，完成更多可验收的工作。

这就是 Token Efficiency 的价值。

很多人理解 Token Efficiency，只会想到模型便宜、上下文变长、缓存命中更低价。但这些只是底层条件。真正能把它变成生产力的，是模型分工、任务编排、上下文预算和评估体系。

换句话说，Token Efficiency 不是省钱技巧，而是一套把 token 转换成产出的工程方法。

DeepSeek V4 的定位：把大小模型分工产品化

这篇文章最应该先补上的背景，是 DeepSeek V4 的定位。

DeepSeek V4 不是单纯发布一个更强模型，而是把 Token Efficiency 需要的两层能力直接拆成了 V4 Pro 和 V4 Flash：Pro 更适合做规划、推理、架构判断和关键审查，Flash 更适合做高频执行、批量改写、代码补全、资料整理和 agent 循环里的普通节点。

这正好对应 AI 编程里的两个角色：

V4 Pro：当作 planner / consultant，用在需求拆解、技术方案、复杂 bug 根因、架构审查和最终验收。
V4 Flash：当作 executor，用在文件扫描、简单实现、测试补齐、文档整理、候选方案生成和重复性任务。

DeepSeek 官方 API 文档显示，V4 Flash 和 V4 Pro 都支持 1M 上下文、JSON Output、Tool Calls、Chat Prefix Completion 和 FIM Completion；价格页也把缓存命中输入单独计价，并说明全模型 input cache hit 价格已降到发布价的十分之一。这几个点组合起来，才是它和 Token Efficiency 关系最密的地方。

1M 上下文解决的是复杂 agent 任务容易被压缩的问题；低缓存命中价格解决的是长系统 prompt、项目文档、代码片段和历史状态反复进入上下文的成本问题；Flash / Pro 双模型形态解决的是“每一步都用旗舰模型太贵、每一步都用小模型又不稳”的分工问题。

所以 DeepSeek V4 的优势不应该只写成“便宜”或“上下文长”，而应该理解成三件事：

执行层便宜：大量 agent 节点可以交给 V4 Flash，让 token 消耗落在低成本模型上。
判断层可用：关键步骤仍然可以调用 V4 Pro，避免为了省钱牺牲复杂推理质量。
长链路友好：1M 上下文和缓存价格让代码库、文档、工具调用历史更容易留在可用窗口里。

这就是为什么 DeepSeek V4 对 AI 编程的意义，不只是又多了一个模型选项，而是给“顾问模型 + 执行模型 + harness 编排”的模式提供了更现实的成本结构。

不要让最强模型干所有活

过去使用 AI，常见做法是找一个最聪明的模型，让它从需求分析、代码实现、测试、总结一路干到底。

这个方式简单，但不一定高效。因为很多任务并不需要最高级别的推理能力。真正贵的模型，应该更像顾问、架构师或规划员：只在关键决策点介入。

更合理的结构是：

大模型负责拆问题、定方向、做关键判断。
小模型负责执行、批量处理、重复修改。
工具和 harness 负责流程、状态、上下文和验证。
人负责定义产品、验收结果和决定取舍。

这样做的好处是，前沿推理能力不会被浪费在机械执行上。大部分 token 消耗可以落到便宜模型和缓存输入里，贵模型只处理真正需要“脑力”的部分。

上下文不是越大越好

长上下文很重要，尤其是 coding agent。代码、文档、历史对话、测试输出、错误日志都会吃掉上下文。上下文一旦接近上限，模型就容易触发压缩、遗忘或误判。

但长上下文不等于可以无限塞资料。

Token Efficiency 的关键，是让每个任务都能在一个清晰、可控的上下文窗口内完成。最理想的状态不是“把整个仓库塞进去”，而是：

当前任务只带必要文件。
背景文档只带决策相关部分。
历史信息只保留当前阶段需要的状态。
每个节点有明确输入和输出。
完成后把结果压缩成结构化摘要，交给下一个节点。

上下文越便宜，越要警惕浪费。便宜 token 会诱导人把无关信息全塞进去，最后模型不是更聪明，而是更容易被噪声拖慢。

Harness 比单个模型更重要

如果只是把 Claude Code、Codex 或其他 coding agent 接到便宜模型上，效果未必好。小模型容易在长链路任务里跑偏，需要更强的流程控制。

真正让小模型发挥价值的，是 harness。

这里的 harness 可以理解为一套调度系统：它知道任务怎么拆、节点怎么跑、模型怎么选、结果怎么验收、失败怎么重试、上下文怎么传递。

一个可用的编排系统，至少要回答几个问题：

哪些任务需要规划？
哪些任务可以直接执行？
哪些节点可以并行？
哪些节点必须串行？
哪个节点用大模型，哪个节点用小模型？
每个节点最多允许多少上下文？
每个节点完成后输出什么结构？
谁来 review，谁来决定是否继续？

没有这层软件，小模型只是便宜；有了这层软件，小模型才可能变成杠杆。

用 DAG 拆任务

一个有效的思路，是把复杂任务拆成有向无环图，也就是 DAG。

比如一个功能开发任务，可以拆成：

需求澄清
方案设计
任务拆分
编码实现
测试补齐
Code Review
修复问题
提交 PR

每个节点都可以是一个独立 agent。它们运行在独立环境里，有自己的角色、prompt、工具权限和输出格式。节点之间不靠长篇聊天传递信息，而是靠预先定义好的结构化结果。

这会带来两个直接收益。

第一，单个节点更短。任务越小，越容易被小模型完成，也越不容易撑爆上下文。

第二，流程更可测。你可以单独观察“编码节点失败率高”还是“review 节点漏问题多”，然后针对性优化。

任务可以跑多个副本

当 token 足够便宜时，一个有趣的变化会出现：同一个任务不一定只跑一次。

你可以让同一个任务用不同模型、不同 prompt、不同编排跑多个副本，再从结果里选最好的，或者把多个结果合并。这个思路有点像“抽卡式任务解决”，但前提是必须有评估和验收。

适合多副本的任务包括：

方案设计
文案生成
测试用例补全
Bug 根因假设
重构方案比较
Code Review

不适合盲目多副本的任务，是那些会直接修改共享状态、会产生外部副作用、或者验收标准不清楚的任务。

多跑几次不是为了碰运气，而是为了获得可比较样本。样本越多，越能反过来优化编排、模型选择和节点技能。

必须建立评估体系

Token Efficiency 不能只看价格。便宜但失败率高，最后会吞掉人的时间，反而更贵。

所以每个团队都应该逐步建立自己的评估体系。它不需要一开始就很复杂，但要能量化。

可以先记录这些指标：

任务完成率
人工介入次数
工具调用失败率
测试通过率
Review 发现的问题数量
单任务 token 成本
单任务耗时
返工次数
不同模型组合的差异

有了这些数据，才能知道哪些任务适合小模型，哪些任务必须上大模型，哪些任务应该交给人判断。

真正的优化不是“所有地方都换便宜模型”，而是把每类任务放到最合适的模型和流程里。

业务流程要原子化

普通用户不一定要自己写完整 harness。未来这类工具会越来越多，也会越来越成熟。

但现在就可以做一件事：把自己的业务流程拆成原子节点。

比如内容生产可以拆成：

选题
资料收集
提纲
初稿
事实核查
风格改写
SEO 标题
多语言翻译
发布检查

软件开发可以拆成：

需求确认
技术方案
数据结构
接口变更
单元测试
实现
迁移脚本
文档
Review

每个节点都要尽量做到输入明确、输出明确、验收明确、上下文可控。这样等 harness 工具成熟时，你的业务流程可以直接接进去。

硬件不是第一优先级

很多人聊 Token Efficiency，很快就会聊到本地部署和显卡。但对大多数人来说，第一选择仍然应该是 API。

原因很简单：在没有跑通经济模型之前，本地硬件只是成本前置。你还不知道 token 怎么转化成收入或生产力，就先买昂贵设备，很容易变成玩具。

更稳的顺序是：

先用 API 跑通业务流程。
建立任务评估和成本统计。
找到稳定高频的执行节点。
再考虑哪些节点值得本地化。
最后再计算硬件、电费、维护和折旧。

如果只是个人提效，API 往往已经够用。如果是创业团队，要验证模型边界和推理框架，本地 CUDA 平台才更有学习价值。如果已经有明确生产场景和经济模型，多卡部署才有讨论空间。

小结

Token Efficiency 的本质，不是“用便宜模型替代贵模型”，而是重新设计 AI 工作流。

大模型负责关键判断，小模型负责批量执行，harness 负责调度和验证，人负责定义目标和验收结果。只有这四层配合起来，token 才能稳定变成生产力。

接下来真正有价值的能力，不只是会用最新模型，而是能把任务拆小、把上下文控住、把结果量化、把流程编排起来。

模型会继续降价，上下文会继续变长，小模型会继续变强。越是这样，越应该早点理解 Token Efficiency。因为未来的差距，很可能不在谁调用了最强模型，而在谁能用同样的 token 撬动更多真实产出。

Superpowers：把 Coding Agent 拉回工程流程的技能框架

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers 是一个给 coding agent 使用的技能框架，也是一套软件开发方法论。它的目标不是再写一个“让 AI 更听话”的万能 prompt，而是把 agent 的工作流程固定下来：先澄清目标，再产出设计，再拆计划，再按测试驱动开发推进，最后做 review 和收尾。

项目地址：https://github.com/obra/superpowers

截至写作时，GitHub API 显示这个仓库已有超过 19 万 star，许可证为 MIT，最近仍在更新。README 对它的描述很直接：An agentic skills framework & software development methodology that works.

它想解决什么问题

现在很多 AI 编程工具的问题，不是“不够会写代码”，而是太容易直接写代码。

用户刚说一个模糊需求，agent 就开始改文件；改完以后看似完成，其实边界没对齐、测试没补、架构没想清楚。短任务可能没事，复杂项目里就会变成返工、回滚和技术债。

Superpowers 的思路是：让 agent 在动手前先进入流程。

README 里描述的核心路径大致是：

发现用户要做东西时，不立刻写代码，而是先追问目标。
从对话中整理出规格说明，并分段给用户确认。
设计通过后，生成足够清楚的实施计划。
用户说 “go” 之后，再进入实现流程。
实现时强调 TDD、YAGNI、DRY，并通过 review 检查结果。

这套流程听起来不新，但放到 coding agent 里很关键。AI 的执行速度越快，前置澄清和中途验证越重要。

支持哪些工具

Superpowers 不是只面向一个 agent。README 里列出的安装入口包括：

Claude Code
Codex CLI
Codex App
Factory Droid
Gemini CLI
OpenCode
Cursor
GitHub Copilot CLI

其中 Codex CLI 和 Codex App 都可以通过官方 Codex plugin marketplace 安装。Claude Code 也可以通过官方插件市场或 Superpowers 自己的 marketplace 安装。

这说明它的定位更像“跨 harness 的工作流层”，而不是绑定某一家模型或某一个命令行工具。

基础工作流

Superpowers 的基础工作流分成几个阶段。

第一步是 brainstorming。它会在写代码前触发，通过问题把粗糙想法整理成可执行设计。它不是让 agent 自嗨式补全需求，而是把设计分段拿给用户确认。

第二步是 using-git-worktrees。设计确认后，它会创建隔离的工作区和新分支，先确认项目能正常安装、测试基线是干净的。这一步能减少多个任务互相污染工作区的问题。

第三步是 writing-plans。它会把设计拆成短小任务，每个任务要求有明确文件路径、代码范围和验证步骤。README 里甚至把计划写给“没有上下文、品味可疑、不爱测试的热情初级工程师”也能执行，当作清晰度标准。

第四步是实现。它可以用 subagent-driven-development 派发子任务，也可以用 executing-plans 分批执行。重点不是并发本身，而是每个任务都要能检查、能 review、能继续推进。

第五步是 test-driven-development。Superpowers 强调真正的 RED-GREEN-REFACTOR：先写失败测试，确认失败，再写最小实现，确认通过，然后重构。它甚至要求删除测试前写出来的实现代码，避免“先实现后补测试”的假 TDD。

第六步是 requesting-code-review。任务之间做 review，按严重程度报告问题。Critical 问题会阻塞继续推进。

最后是 finishing-a-development-branch。任务结束后，验证测试，给出合并、发 PR、保留或丢弃 worktree 的选择。

Skills Library 里有什么

Superpowers 的技能库可以分成几类。

测试类主要是 test-driven-development，围绕红绿重构循环，并包含测试反模式参考。

调试类包括 systematic-debugging 和 verification-before-completion。前者要求按复现、最小化、假设、验证、修复的过程找根因；后者强调不要在没有验证前宣布完成。

协作类更丰富，包括：

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

元技能包括 writing-skills 和 using-superpowers。前者用于创建新技能，后者用于理解技能系统本身。

这些技能组合起来，像是给 agent 装了一套工程习惯：什么时候该问，什么时候该计划，什么时候该测试，什么时候该停下来 review。

和普通 prompt 最大的区别

普通 prompt 往往把规则堆在一段 system prompt 里：不要乱改、先思考、要测试、要解释、要简洁。问题是规则越堆越多，模型越容易在复杂任务里选择性遗忘。

Superpowers 更像把规则拆成可触发的流程模块。不同任务阶段使用不同技能，每个技能只负责一段工作。这样做有几个好处：

规则更短，目标更集中。
agent 更容易知道当前阶段该做什么。
复杂流程可以被拆成可检查的步骤。
技能可以跨工具复用。
团队可以把自己的工程习惯沉淀成技能。

这也是它最值得参考的地方：不要只追求“更聪明的模型”，还要给模型一套可重复的工作方式。

适合谁用

Superpowers 更适合已经在认真使用 coding agent 的开发者，尤其是这些场景：

任务不只是单文件改动。
希望 agent 先设计再实现。
项目需要 TDD 或至少需要验证步骤。
经常并行做多个功能分支。
希望用 subagent 分摊实现、检查和 review。
想把团队流程写成可复用技能。

如果只是让 AI 改一行配置、生成一个脚本，它可能显得偏重。但一旦任务涉及多文件、多阶段、多轮确认，它的流程约束就会变得有价值。

使用时要注意什么

第一，不要把它理解成自动驾驶。Superpowers 能让 agent 更有流程感，但设计取舍、需求边界和最终验收仍然需要人负责。

第二，TDD 和 review 会增加前期成本。小任务可能会变慢，但复杂任务通常能减少返工。

第三，子代理并发不是越多越好。并发适合边界清楚、写入范围不重叠的任务；如果需求还没想清楚，先并发只会把混乱放大。

第四，团队要维护自己的技能质量。技能不是写完就万事大吉，过时的流程、模糊的指令和互相冲突的规则，也会拖累 agent。

小结

Superpowers 的价值，不在于某个单独技能多神奇，而在于它把 coding agent 从“接到需求就写代码”拉回了软件工程流程。

它提醒我们：AI 编程真正缺的往往不是生成速度，而是澄清、计划、验证、review 和收尾。模型越强，这些流程越不能省。否则 AI 只是更快地制造未验证的代码。

如果你已经在用 Codex、Claude Code、Cursor 或 Gemini CLI 做真实项目，Superpowers 值得看一眼。即使不直接安装，它的技能拆分方式也很适合拿来改造自己的 agent 工作流。

拒绝 Vibe Coding：Matt Pocock 的 skills 仓库给 AI 编程补上工程约束

Fri, 15 May 2026 08:46:23 +0800

AI 写代码越快，项目失控也可能越快。真正的问题不是模型会不会生成函数，而是它是否理解需求、是否遵守团队语言、是否能在已有架构里小步推进。如果把 AI 当成“随便说一句就自动完工”的代码喷射器，最后很容易得到一堆跑不通、难维护、没人敢改的代码。

Matt Pocock 开源的 mattpocock/skills 仓库，正好给了一个相反方向的示例：不要让 AI 接管整个开发流程，而是把 AI 放进成熟的软件工程约束里。

项目地址：https://github.com/mattpocock/skills

这套方法的重点不是某个神奇 prompt，而是一组可以组合的 agent skills。它们把需求澄清、领域建模、测试驱动、问题诊断、架构审查这些老派工程实践，重新包装成适合 AI 编程工具调用的工作流。

先解决对齐失败

AI 编程最常见的失败，是你以为它懂了，其实它只是顺着你的模糊描述开始猜。

grill-me 的思路就是反过来：在写代码之前，先让 AI 变成一个会追问的审稿人。它不会立刻开始实现，而是持续追问计划里的分支、边界和未决问题。

比如你说“做一个登录页”，它应该先问：

忘记密码怎么处理？
是否支持第三方登录？
登录失败时要显示什么错误？
账号锁定、验证码、风控是否在本期范围内？
成功后跳转到哪里？

这一步看起来慢，但它减少的是后面返工的时间。AI 生成代码的成本越低，需求没想清楚带来的浪费就越大。

把领域语言写进上下文

第二个问题是 AI 的“通用词汇病”。它不了解团队内部的业务叫法，只能用常见词来猜，于是变量名、函数名、文档描述都开始漂移。

grill-with-docs 解决的是这个问题。它不只是追问需求，还会结合项目里的 CONTEXT.md、ADR 或领域文档，检查用户表达是否和既有术语冲突。确认后的术语、边界和决策，可以继续沉淀回上下文文档。

这和领域驱动设计里的“统一语言”很接近。假设团队把 user 称为 customer，把 order 称为 transaction，那么 AI 在写代码时也应该继承这些叫法，而不是自己再发明一套。

上下文文档的价值不在于堆资料，而在于让 AI 少猜一点。

用 TDD 限制生成速度

AI 的危险之处在于它太快了。过去写出一大段坏代码需要时间，现在几秒钟就能生成几百行。速度本身不是问题，缺少反馈循环才是问题。

tdd skill 把经典的红绿重构流程放回 AI 编程里：

先为一个行为写失败测试。
再实现刚好让测试通过的代码。
然后重构。
按垂直切片继续推进。

重点是“一次一个行为”，而不是让 AI 一口气写完所有测试和所有实现。这样做可以把任务切小，也能让每一步都有可验证结果。AI 负责执行，人类负责确认方向和边界。

用诊断循环处理复杂问题

遇到 bug 时，很多 AI 会直接猜答案，然后连续改几轮，把问题越修越乱。

diagnose 的价值在于要求 AI 先建立反馈循环：

复现问题
最小化场景
提出假设
增加观测或日志
修复
补回归测试

这套流程不新，但在 AI 编程里尤其重要。因为 AI 很擅长快速尝试，却不一定擅长判断哪次尝试真正接近根因。诊断流程相当于给它加了一条轨道。

定期审查架构，而不是只看单个任务

单次任务跑通，不代表代码库变好了。AI 反复提交小改动后，最容易出现的问题是模块边界变模糊、接口越来越复杂、测试越来越难写。

improve-codebase-architecture 这类 skill 的意义，是让 AI 定期跳出当前任务，从更高层看代码库：

哪些模块职责开始混在一起？
哪些接口太复杂？
哪些路径难以测试？
哪些命名和领域语言不一致？
哪些重复逻辑应该收敛？

这不是让 AI 自动大重构，而是让它先给出结构化观察和改进方向。真正要不要改、改到什么程度，仍然需要开发者判断。

真正该限制的是自由度

这套方法论的核心可以压缩成一句话：AI 编程不是放任模型自由发挥，而是给它清晰的目标、上下文、测试和停止条件。

人类更适合负责问题定义、架构边界、业务取舍和验收标准；AI 更适合负责代码生成、测试补全、重复修改和局部重构。两者配合得好，AI 是放大器；配合得不好，它会把混乱也一起放大。

所以，软件工程基础没有因为 AI 变强而过时。恰恰相反，需求澄清、领域语言、TDD、诊断、架构审查这些能力，在 AI 时代变得更关键。

会写代码的人会越来越多。真正拉开差距的，是谁能把 AI 放进可维护、可验证、可长期演进的工程体系里。

cc-haha 是什么？一个把 Claude Code 做成桌面工作台的项目

Thu, 14 May 2026 22:36:43 +0800

cc-haha 是一个围绕 Claude Code 工作流改造出来的项目。它的完整仓库名是 NanmiCoder/cc-haha，项目页面写得很直接：它基于 2026-03-31 从 Anthropic npm registry 泄露的 Claude Code 源码修复而来，现在主要形态是一个桌面端 Claude Code 工作台。

项目地址：https://github.com/NanmiCoder/cc-haha

这句话里有两个重点。

第一，它不是 Anthropic 官方 Claude Code。项目 README 也明确写了原始源码版权归 Anthropic 所有，仅供学习和研究用途。

第二，它现在的重点已经不只是“本地跑一个 Claude Code CLI”。从 README 和最新 release 看，cc-haha 更像一个把 Claude Code 的会话、项目、权限、Diff、Computer Use、远程访问和模型提供商配置集中起来的桌面应用。

它想解决什么问题

Claude Code 原本是偏终端的工具。会话、命令执行、权限确认、文件修改、上下文切换都在终端里完成。对熟悉 CLI 的人来说没问题，但长期使用时会遇到几个不方便的地方：

多个项目和多个会话不好同时管理。
AI 改了哪些文件，需要自己切到 Git 或编辑器里看。
权限审批、命令执行、文件 Diff 分散在不同界面。
想在手机或其他设备上远程看当前会话，需要额外方案。
想接入非 Anthropic 模型，需要自己处理协议兼容。

cc-haha 的方向就是把这些东西做成一个图形化工作台。它并不是只给 Claude Code 换皮，而是把“会话管理”和“本地开发流程控制”放到了桌面端里。

桌面端工作台：从终端变成控制台

根据 README，cc-haha 桌面端把这些能力集中到 macOS / Windows App 里：

多会话工作台：用标签页、项目切换、终端入口和历史记录管理不同任务。
分支 / Worktree 启动：新会话可以选择仓库分支，也可以选择使用当前工作树或隔离 Worktree。
右侧代码改动面板：聊天时直接查看修改过的文件、增删行和工作区状态。
代码修改可视化：查看 AI 对文件的编辑、Diff 和执行过程。
权限与确认流：把危险命令、工具调用和 AI 反问集中到桌面端审批。
多模型提供商：支持 Anthropic 兼容 API、第三方模型、WebSearch fallback 和本地配置。
H5 远程访问：用一次性 token 在手机或其他设备上接入当前桌面会话。
IM 接入：通过 Telegram、飞书、微信、钉钉远程对话、切换项目和审批权限。
定时任务与 token 用量统计：在桌面端创建计划任务，并查看本机 token 使用趋势。

这类功能说明它更接近“AI 编程工作台”，而不是单纯的命令行替代品。它想把 AI 写代码时最常见的几个界面放到同一个地方：聊天、文件改动、权限、项目、远程入口、模型配置。

安装和启动方式

普通用户更适合从 Releases 下载桌面端安装包。

项目 README 给出的桌面端安装流程是：

前往 GitHub Releases 下载 macOS 或 Windows 安装包。
首次启动后，在桌面端设置里配置模型提供商、API Key 和默认模型。
如果 macOS 提示应用无法打开，按安装指南处理 Gatekeeper 权限。

最新 release 页面显示，v0.2.6 发布于 2026-05-13。这个版本主要围绕 H5 手机访问安全恢复、桌面会话管理、文件提及搜索和桌面体验细节。

如果想从源码启动 CLI，README 给出的命令是：

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

这个路径更适合想调试底层 CLI、服务端或自行开发的人。普通使用还是桌面端更直接。

v0.2.6 更新了什么

v0.2.6 的重点是把 H5/LAN 访问从临时放行收回到显式开启和 token 配对模型。

几个值得注意的变化：

H5/LAN 访问需要本地显式开启。
QR 链接会携带一次性显示的 token。
远程 API、proxy 和 WebSocket 不再裸露。
Settings 新增独立 H5 Access 页面。
桌面侧边栏增加批量管理模式，支持多选和删除会话。
桌面文件提及搜索改为 git-first，遵守 ignore 规则，减少 node_modules 和构建产物噪声。
新增纯白主题，修复长 URL 撑破聊天布局、多 tab 草稿串台等问题。

这说明项目已经不只是“能跑”，而是在补桌面产品需要的安全边界和日常体验。

尤其是 H5 访问这一块，作者在 release 里明确提醒：H5 是给个人或可信团队使用的浏览器访问入口，不是公开多租户登录系统。实际使用时，不应该把它当成公网开放的 SaaS 登录后台。

Computer Use：让 Agent 操作桌面

cc-haha 另一个重要卖点是 Computer Use。

项目文档说明，这个功能基于 Claude Code 泄露源码中的 Computer Use 内部实现改造而来。官方实现依赖 Anthropic 内部私有原生模块，例如 @ant/computer-use-swift 和 @ant/computer-use-input，无法公开获取。cc-haha 用 Python bridge 替换底层操作层，通过 pyautogui、mss、pyobjc 等公开库实现系统交互。

Computer Use 支持的操作包括：

截屏：screenshot、zoom
鼠标：点击、拖拽、移动、滚动、读取光标位置
键盘：输入文字、按键、按住按键
应用：打开应用、切换显示器
权限：请求应用授权、列出已授权应用
剪贴板：读取和写入剪贴板
其他：等待、批量操作

它的工作方式是一个“截图 - 分析 - 操作”的闭环：

模型收到用户请求。
调用 screenshot 获取屏幕画面。
模型根据视觉能力识别按钮、输入框和坐标。
调用点击、输入或应用操作工具。
再次截图确认结果，再继续下一步。

从文档看，完整支持的平台主要是 macOS，包括 Apple Silicon 和 Intel。Windows / Linux 在理论上可行，但涉及 pyobjc 的应用管理部分需要替换为对应平台方案，当前并不是完整适配状态。

运行要求包括：

Bun >= 1.1.0
Python >= 3.8
macOS Accessibility 辅助功能权限
macOS Screen Recording 屏幕录制权限

这类功能很强，但也意味着权限风险更高。让 AI 操作桌面应用时，最好只授权明确需要的应用，不要在无关窗口里打开敏感内容。

多模型接入：通过 Anthropic 协议兼容层

cc-haha 的通信基础仍然是 Anthropic Messages API 协议。项目文档给出的推荐方案是用 LiteLLM 做协议转换代理。

基本结构是：

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

也就是说，cc-haha 发出 Anthropic Messages API 请求，LiteLLM 把它转换成 OpenAI Chat Completions 等格式，再转发给 OpenAI、DeepSeek、Ollama 或其他模型服务。

文档给出的 LiteLLM 安装方式是：

`1`	`pip install 'litellm[proxy]'`

然后可以在 litellm_config.yaml 里配置 OpenAI、DeepSeek、Ollama 等模型。启动代理后，在 .env 或 ~/.claude/settings.json 里设置：

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

这里有几个实际注意点：

drop_params: true 很重要，因为 Anthropic 的 thinking、cache_control 等参数在 OpenAI API 中不存在。
Extended Thinking 属于 Anthropic 专有能力，使用第三方模型时不可用。
Prompt Caching 也不会按 Anthropic 原生方式生效。
工具调用会经过 Anthropic tool_use 到 OpenAI function calling 的转换，复杂工具调用可能存在兼容性问题。
本地 Ollama 小模型未必能稳定处理这套工具调用流程。

所以多模型接入能跑，不等于所有模型体验一样。cc-haha 对模型的工具调用、代码理解和长上下文能力要求仍然不低。

适合什么人

cc-haha 更适合这几类用户：

已经熟悉 Claude Code，但想要桌面端会话管理的人。
经常同时处理多个仓库、分支和 AI 会话的人。
希望在右侧直接看 AI 文件改动、Diff 和工作区状态的人。
想尝试 Computer Use，让 Agent 操作桌面应用的人。
想用 Anthropic 协议接入 OpenAI、DeepSeek、Ollama 或其他模型的人。
需要手机或 IM 远程查看会话、审批权限的人。

不太适合：

只想稳定使用官方 Claude Code 的用户。
不能接受泄露源码背景和版权不确定性的人。
不愿意给本地工具较高系统权限的人。
需要企业合规、审计和官方支持的人。
不熟悉 API key、代理、模型兼容和本地服务配置的人。

风险和边界

这篇文章不能只讲功能，也必须讲风险。

cc-haha 的来源决定了它不是一个普通的社区重写项目。README 明确写到它基于泄露的 Claude Code 源码，且原始源码版权归 Anthropic 所有。这会带来版权、合规和长期维护上的不确定性。

另外，Computer Use、H5 远程访问、IM 接入和本地权限审批都属于高权限能力。它们越方便，越需要清楚边界：

不要在不可信网络下开放 H5 访问。
不要把 token 当作长期公开登录凭证。
不要给 Agent 操作不相关的敏感应用。
不要在生产环境或公司合规环境里随意接入。
不要把第三方模型代理和 API key 配置暴露到公共仓库。

如果只是学习 AI 编程工具架构、桌面端工作流和 Computer Use 实现，它很有参考价值。如果要放进长期生产工作流，就要先评估法律、权限、安全和维护风险。

总结

cc-haha 最值得关注的地方，不是“它能不能复刻 Claude Code”，而是它把 Claude Code 类型的 AI 编程工具推向了桌面工作台形态。

会话、项目、Worktree、Diff、权限、远程访问、Computer Use、多模型提供商、定时任务和 token 用量统计都被放进同一个桌面体验里。这说明 AI 编程工具的下一步，不只是模型更强，也包括工作流界面更完整。

不过它的边界也很清楚：这不是 Anthropic 官方产品，来源存在敏感背景，高权限能力需要谨慎使用。更合适的态度是把它当成一个观察 AI 编程工具演化方向的项目，而不是无脑替代官方 Claude Code。

参考资料

GitHub 仓库：https://github.com/NanmiCoder/cc-haha
最新 Release：https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Computer Use 文档：https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
第三方模型文档：https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal：长任务自动跑到完成

Thu, 14 May 2026 22:22:42 +0800

/goal 正在变成 AI 编程工具里的一个重要命令。

它解决的不是“让模型多写几行代码”，而是另一个更实际的问题：当任务有明确完成条件时，能不能让 Agent 持续推进，直到条件满足，而不是每完成一轮就停下来等用户继续催。

Codex CLI 已经在官方文档里加入了实验性的 /goal。Claude Code 也上线了自己的 /goal 文档，而且把它描述成一种可以跨多轮持续工作的自动化能力。两者名字一样，但产品取向并不完全一样。

`/goal` 到底解决什么问题

普通 AI 编程对话通常是“一问一答”：

用户提出任务。
Agent 分析、改代码、跑测试。
Agent 汇报结果。
用户再决定下一步。

这个流程适合短任务，但遇到迁移、重构、测试修复、issue backlog 清理时，就会变得很碎。Agent 可能每次只推进一小段，然后停下来等你输入“继续”。

/goal 的思路是把任务从“下一步做什么”改成“最终什么状态算完成”。例如：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

这类目标天然适合长任务，因为它有清楚的终点：测试通过、构建成功、文件拆分完成、队列清空、验收条件满足。

Codex 的 `/goal`：实验功能，绑定当前线程

OpenAI 的 Codex CLI 文档把 /goal 标为实验功能。它不是默认稳定能力，需要先开启 features.goals。

开启方式有两种：

`1`	`/experimental`

或者在 config.toml 里加入：

1
2

[features]
goals = true

启用后，可以这样使用：

`1`	`/goal Finish the migration and keep tests green`

常用命令包括：

/goal
/goal pause
/goal resume
/goal clear

按照 OpenAI 文档的说法，Codex 会把 goal 附着在当前 active thread 上，在更大的任务运行过程中持续跟踪这个目标。

这里要注意一个细节：官方文档对 Codex /goal 的措辞比较克制。它强调“给长任务设置实验性目标”“把目标附着到当前线程”，但没有像 Claude Code 文档那样展开说明每一轮结束后由独立 evaluator 自动判断并继续下一轮。所以现在使用 Codex /goal 时，最好仍把它看作实验中的长任务目标机制，而不是完全稳定的无人值守执行模式。

Claude Code 的 `/goal`：完成条件驱动的多轮执行

Claude Code 的 /goal 文档写得更明确：用户设置 completion condition 后，Claude 会跨 turn 持续工作，直到条件满足。

示例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code 的机制大致是：

当前 turn 完成后，不直接把控制权还给用户。
一个小型快速模型会检查目标条件是否已经满足。
如果没有满足，Claude 自动开始下一轮。
如果满足，goal 自动清除，并在 transcript 里记录完成状态。

这意味着 Claude Code 的 /goal 更像“按完成条件自动续跑”。它不只是把目标挂在会话里，而是把“是否继续下一轮”交给一个独立评估步骤。

Claude Code 还支持直接查看状态：

/goal

状态里会显示目标条件、运行时间、已评估 turn 数、token 消耗，以及 evaluator 最近一次给出的原因。

如果要提前停止，可以使用：

`1`	`/goal clear`

stop、off、reset、none、cancel 也可以作为清除别名。开启目标后，如果会话中断，之后通过 --resume 或 --continue 恢复时，仍然 active 的 goal 可以被带回来；但计时、turn 数和 token 基线会重新计算。

两者最大的差异

Codex 和 Claude Code 都在把 AI 编程从“单轮回答”推向“长任务执行”，但 /goal 的定位有差异。

对比项	Codex CLI `/goal`	Claude Code `/goal`
状态	experimental	官方文档单独成页说明
启用方式	需要开启 `features.goals`	可直接在受信任 workspace 使用
目标作用域	当前 active thread	当前 session
常用操作	set / view / pause / resume / clear	set / view / clear
自动判断	文档强调目标附着与跟踪	明确说明每轮后由 evaluator 判断
自动续跑	文档表述较克制	条件未满足时自动下一轮
适合场景	想在 Codex 长任务里保持目标上下文	想按完成条件让 Claude Code 持续推进

简单说，Codex 的 /goal 更像“给当前线程挂一个实验性的长期目标”；Claude Code 的 /goal 更像“给当前会话设置一个可验证的停止条件，让它自动干到满足为止”。

写好 `/goal` 的关键

不管使用哪一个工具，/goal 都不适合写成模糊愿望。

不太好的写法：

`1`	`/goal 把项目优化一下`

更好的写法：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

一个好目标通常包含三点：

明确的完成状态。
可执行的验证方式。
必须遵守的边界。

如果目标太大，还应该加上停止条件：

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

这很重要。/goal 越强，越需要边界。否则 Agent 可能会为了追求“完成”而改动过多文件、跑太久、消耗太多 token，甚至把原本该停下来询问的问题继续往前推。

什么时候适合用 `/goal`

适合：

测试修复：直到指定测试通过。
代码迁移：直到所有调用点改完并编译成功。
批量清理：直到某类 lint 或类型错误清零。
文档补齐：直到所有指定模块都有说明。
issue 队列处理：直到某个标签下的问题都被处理或明确分类。

不适合：

需求本身还没想清楚。
需要频繁产品判断。
涉及高风险删除、数据迁移或权限变更。
验收条件只能靠主观判断。
任务会跨越大量无关模块。

一个实用原则是：如果你能写出“跑哪个命令、看到什么结果、哪些文件不能碰”，就适合用 /goal。如果只能写“帮我做得更好”，那还是先用普通对话、计划模式或人工评审更稳。

对 AI 编程工具的影响

/goal 代表一个很明显的方向：AI 编程工具正在从“交互式助手”变成“可持续执行的工作单元”。

过去我们让 Agent 做任务，经常要在旁边守着。它卡住了要提示，测完了要继续，报错了要再下命令。/goal 把这部分交互压缩成一个完成条件，让 Agent 自己决定下一轮该做什么。

但这也带来新的要求。以后写 prompt 不只是描述任务，还要写验收条件、验证命令、修改边界和停止规则。换句话说，用户的工作从“催它继续”变成“定义什么叫完成”。

Codex 和 Claude Code 走到 /goal 这一步，说明长任务 Agent 已经不再只是后台任务或云端队列的专利。终端里的本地编程工具，也开始需要更强的自主推进能力。

总结

Codex CLI 和 Claude Code 都有了 /goal，但现阶段不要把它们简单看成同一个功能。

Codex 的 /goal 仍是实验能力，需要开启 features.goals，更适合在 Codex 当前线程里维持长期目标。Claude Code 的 /goal 则更明确地把“完成条件”和“自动续跑”连在一起，通过独立 evaluator 判断是否继续。

对日常开发来说，这类命令最适合处理有明确验收标准的工程任务。它不会替代需求判断，也不会消除代码审查，但能减少长任务里大量重复的“继续”“再跑一次”“修到测试通过”。

真正要学会的不是某个命令本身，而是如何把任务写成清楚、可验证、可停止的目标。

参考资料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal 文档：https://code.claude.com/docs/en/goal

Codex 怎么接入国产大模型？OpenAI 兼容接口与 CodexBridge 使用思路

Wed, 13 May 2026 23:08:28 +0800

CodexBridge 是一个本地桥接工具，目标很直接：把 Codex CLI/SDK 封装成 OpenAI 兼容的 HTTP 服务。这样一来，原本只能在终端里使用的 Codex，可以被 OpenWebUI、Cherry Studio、脚本、自动化系统或任何兼容 OpenAI Chat Completions 的客户端调用。

它提供的核心接口是 /v1/chat/completions 和 /v1/models。前者负责对话，支持普通同步返回和 SSE 流式输出；后者让客户端能像读取模型列表一样发现可用模型。对已经接过 OpenAI API 的工具来说，这种设计的好处是改动小，通常只需要改 base URL、API key 和模型名。

项目地址：https://github.com/begonia599/CodexBridge

适合什么场景

CodexBridge 适合想把 Codex 接入现有 AI 客户端或工作流的人。例如：

想在 OpenWebUI、Cherry Studio 里直接选择 Codex 模型。
想用 curl、Python、Node.js 等脚本调用本机 Codex。
想让同一个前端同时接 OpenAI、Ollama、其他兼容接口和 Codex。
想保留 Codex 的本地线程、沙箱、工作目录和审批能力。
想给内部工具提供一个统一的 /v1/chat/completions 入口。

它不是一个新的大模型，也不是替代 Codex CLI 的完整前端。更准确地说，它是一个适配层：上游仍然是 Codex，本地桥接器负责把 OpenAI 风格的请求转换成 Codex 能理解的会话输入。

基本环境

运行前需要准备：

Node.js 18 或更高版本。
已安装并登录的 Codex CLI。
npm，或者按自己的习惯换成 pnpm / yarn。

源码部署的基本步骤如下：

git clone https://github.com/begonia599/CodexBridge
cd codexbridge
npm install
cp .env.example .env
cp .env .env.local

然后编辑 .env 或 .env.local，设置 API key、默认模型、工作目录、沙箱模式、联网权限等配置。

启动 HTTP 服务：

`1`	`npm run codex:server`

默认端口是 8080，可以通过 PORT 修改。服务启动后，可以访问：

1
2
3

GET /health
POST /v1/chat/completions
GET /v1/models

CLI 对话模式

除了 HTTP 服务，CodexBridge 也保留了一个轻量 CLI：

`1`	`npm run codex:chat`

CLI 里可以直接输入自然语言与 Codex 对话。常用命令有两个：

/reset：创建新的 Codex 线程。
/exit：退出 CLI。

当前线程 ID 会保存在 .codex_thread.json。下次启动 CLI 时，如果这个文件还在，就能继续之前的对话。

HTTP 调用示例

最基础的请求可以这样写：

curl http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:medium","session_id":"demo","messages":[{"role":"user","content":"ls"}]}'

这里有几个点需要注意：

authorization 里的 token 要和 CODEX_BRIDGE_API_KEY 一致。
model 可以带推理等级，例如 gpt-5-codex:medium 或 gpt-5-codex:high。
session_id 用来绑定会话，方便复用同一个 Codex 线程。

如果需要流式输出，加上 stream: true：

curl -N http://localhost:8080/v1/chat/completions \
  -H "content-type: application/json" \
  -H "authorization: Bearer 123321" \
  -d '{"model":"gpt-5-codex:high","session_id":"stream","stream":true,"messages":[{"role":"user","content":"一步步介绍如何创建 Node.js 项目"}]}'

对支持 OpenAI 流式响应的客户端来说，这种返回方式更接近正常聊天体验。

会话持久化怎么做

CodexBridge 的一个重点是会话映射。请求里可以通过这些字段传入会话 ID：

session_id
conversation_id
thread_id
user

也可以从请求头传：

x-session-id
session-id
x-conversation-id
x-thread-id
x-user-id

生产环境建议开启：

`1`	`CODEX_REQUIRE_SESSION_ID=true`

这样所有请求都必须带会话 ID，避免不同用户或不同聊天窗口混到同一个临时上下文里。会话映射保存在 .codex_threads.json，删除这个文件可以重置桥接层的映射关系；Codex 自身线程仍然保存在 ~/.codex/sessions。

如果 CODEX_REQUIRE_SESSION_ID=false 且请求没有提供会话 ID，桥接器会把当前 messages 展开成一次性输入发给 Codex。这种方式适合临时调用，但不适合长期对话。

多模态输入

CodexBridge 支持 OpenAI 风格的内容块，并会把图片转换成 Codex 可用的 local_image 输入。

远程图片可以写成：

{
  "type": "image_url",
  "image_url": {
    "url": "https://example.com/demo.png"
  }
}

本地图片可以写成：

{
  "type": "local_image",
  "path": "./images/demo.png"
}

远程资源会先下载到临时目录，回合结束后清理。实际使用时要注意请求体大小，尤其是把图片转成 base64 发送时，可能需要增大 CODEX_JSON_LIMIT。

结构化输出

如果客户端支持 response_format，可以让 CodexBridge 映射到 Codex 的 outputSchema。这适合让 Codex 返回固定 JSON 结构，例如检查结果、摘要、分类结果或自动化任务报告。

最小思路是：

{
  "model": "gpt-5-codex",
  "session_id": "lint",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "lint_report",
      "schema": {
        "type": "object",
        "properties": {
          "summary": { "type": "string" },
          "status": {
            "type": "string",
            "enum": ["ok", "action_required"]
          }
        },
        "required": ["summary", "status"],
        "additionalProperties": false
      }
    }
  },
  "messages": [
    {
      "role": "user",
      "content": "检查 src/ 的 lint 问题，并以 JSON 返回结果"
    }
  ]
}

需要注意，type: "json_schema" 必须提供 schema，否则服务会直接返回 400。

关键环境变量

常用配置可以分成几类。

服务与鉴权：

1
2
3

PORT=8080
CODEX_BRIDGE_API_KEY=123321
CODEX_JSON_LIMIT=10mb

默认模型：

1
2

CODEX_MODEL=gpt-5-codex
CODEX_REASONING=medium

Codex 运行环境：

CODEX_WORKDIR=
CODEX_SANDBOX_MODE=read-only
CODEX_APPROVAL_POLICY=never
CODEX_SKIP_GIT_CHECK=true

联网能力：

1
2

CODEX_NETWORK_ACCESS=false
CODEX_WEB_SEARCH=false

如果只是给前端聊天用，默认关闭联网更稳。只有明确需要让 Codex 执行 curl、git clone 或使用 Web 搜索时，再单独打开对应开关。

Docker 和一键脚本

项目也提供 Docker 方式，适合想把服务常驻起来的场景：

1
2

docker compose up -d
docker compose logs -f codexbridge

也可以用项目提供的 Linux 安装脚本：

`1`	`curl -fsSL https://raw.githubusercontent.com/begonia599/CodexBridge/master/scripts/install.sh \| bash`

脚本会安装依赖、克隆或更新仓库、复制 .env.example，并通过 Docker Compose 启动服务。它需要 sudo 权限，适合在干净服务器上快速部署。已经有复杂 Node.js、Docker 或 Codex 环境的机器，建议先读脚本内容再执行。

常见问题

请求返回 413

通常是请求体太大，常见于 base64 图片。可以增大：

`1`	`CODEX_JSON_LIMIT=20mb`

提示 API key 无效

检查请求头是否带了：

`1`	`Authorization: Bearer <你的 CODEX_BRIDGE_API_KEY>`

或者使用 x-api-key。

Codex 报 Git 仓库限制

如果运行目录不是可信仓库，可能会触发 Codex 的检查。只在确认安全的环境中使用：

`1`	`CODEX_SKIP_GIT_CHECK=true`

想清空会话

桥接层会话映射在 .codex_threads.json，Codex 自身线程在 ~/.codex/sessions。停掉服务后删除对应文件或目录即可重置。

使用建议

本地试用时，可以先用默认 API key 和 read-only 沙箱跑通流程。确认 OpenWebUI、Cherry Studio 或脚本能正常调用后，再逐步调整 CODEX_WORKDIR、CODEX_SANDBOX_MODE、CODEX_NETWORK_ACCESS 和 CODEX_APPROVAL_POLICY。

如果要给多人使用，建议至少做三件事：

强制要求 session_id。
修改默认 API key。
明确限制工作目录和沙箱权限。

CodexBridge 的价值不在于功能复杂，而在于把 Codex 放进了现有 OpenAI 兼容生态里。只要客户端能改 base URL，它就有机会把 Codex 当成一个普通聊天模型来接入，同时保留本地线程、沙箱和工具调用这些 Codex 自身的能力。

AI 编程工具这一轮，DeepSeek 为何成了省钱关键？

Mon, 11 May 2026 04:59:00 +0800

这一轮 AI 编程工具的竞争，表面上是在比模型能力、插件生态和 agent 自动化程度，真正用起来以后，最先撞上的问题却是成本。

Claude Code、Codex、OpenClaw、Superpowers 这类工具都很好用，但它们有一个共同特点：一旦进入复杂任务，就会非常吃 token。它们要读项目、建计划、调用工具、总结上下文、反复检查结果，还可能拉起多个子任务。模型越聪明，工作流越自动化，账单也越容易悄悄变大。

所以 DeepSeek 在这一轮里变得很关键，不只是因为它能写代码，而是因为它在长上下文和缓存成本上，刚好打中了 AI 编程工具最烧钱的地方。

Agent 工具为什么特别费 token

传统聊天式编程助手，通常是一问一答。你问一个函数怎么写，它回答一段代码。这个模式消耗不小，但还算可控。

Agent 工具不一样。它不是只回答问题，而是要像一个临时工程师一样进入项目：

先扫描目录和关键文件；
再理解需求和现有架构；
然后制定计划；
修改文件；
运行命令或测试；
根据报错继续修；
最后总结改了什么。

这个过程里，模型反复读取同一批上下文。项目说明、代码片段、工具结果、历史对话、计划和错误日志都会被塞回上下文。任务稍微复杂一点，几十万 token 很快就出去了。

如果再装一些更激进的插件，成本会更明显。比如有些 OpenCode 或 Claude Code 增强工具，会默认组织一整套 agent 团队。你只是想改一个小功能，它也可能启动规划、审查、执行、复盘等多个环节。任务当然显得更“智能”，但 token 也会一路往上跑。

Superpowers 的好处是按需触发

Superpowers 这类工具的一个优点，是它不会在所有任务里都强行拉起完整 agent 流程。

平时你还是可以让 Claude Code、OpenCode 或 Codex 按原来的方式工作。只有当你明确调用某个 skill，比如头脑风暴、写计划、执行计划、做复盘时，它才进入更重的自动化流程。

这对成本很重要。

AI 编程不应该所有任务都用重武器。改一行配置、查一个报错、写一个小脚本，用普通对话就够了；只有复杂重构、跨文件修改、长文档处理、多轮验证，才值得上完整 agent 流程。

工具越强，越要学会控制触发条件。否则自动化越多，浪费越多。

DeepSeek 的关键优势是缓存便宜

DeepSeek 适合接这类 agent 工具，一个很重要的原因是缓存命中成本低。

AI 编程任务里有大量重复前缀。比如项目背景、系统提示词、工具说明、文件内容、前几轮对话，经常会在后续请求里反复出现。如果模型服务支持 prompt cache，这些重复内容命中缓存后，成本会明显下降。

很多模型的缓存命中价只是比未命中便宜一些，比如便宜到三分之一左右。DeepSeek 的优势在于，命中缓存后的价格差距可以大很多。对长上下文、多轮调用、重复读取项目的 agent 工作流来说，这个差距会直接反映到账单上。

也就是说，DeepSeek 不是每一次回答都一定最强，而是在“长任务、多轮任务、反复读上下文”的场景里，成本结构特别适合 AI 编程。

长上下文让 Claude Code 更好用

把 Claude Code 或类似工具接到 DeepSeek V4 时，另一个明显优势是长上下文。

AI 编程工具最怕上下文不够。上下文一不够，就要频繁压缩；压缩一多，前面读过的细节就可能丢失。模型开始忘记项目结构、忘记约束、忘记某个文件为什么这么改，后续质量就会下降。

DeepSeek V4 系列的长上下文能力，让它更适合处理代码仓库、文档批处理、字幕翻译、站点文章整理这类任务。特别是接入 Claude Code、OpenClaw 这类工具时，如果配置得当，可以让它尽量晚一点进入上下文压缩，让模型保留更多项目细节。

这也是为什么有些任务用 DeepSeek 会显得“很经使”：它不一定每一步都惊艳，但能承受长时间、低成本、反复调用。

V4 Pro 和 V4 Flash 怎么分工

DeepSeek V4 Pro 和 V4 Flash 不应该混着用。

简单任务用 DeepSeek V4 Flash 更合适。它速度快、成本低，用在下面这些场景通常足够：

翻译字幕；
整理文档；
生成普通脚本；
修改小范围代码；
跑 OpenClaw 里的轻量任务；
做简单的站点内容处理。

复杂任务再考虑 DeepSeek V4 Pro：

大规模重构；
多模块代码理解；
复杂推理；
长链路 agent 任务；
高风险代码修改；
需要更强规划能力的工程任务。

很多人一上来就想挂最强模型，这反而不划算。AI 编程工具最现实的玩法，是把任务分层：便宜模型吃掉大量常规工作，贵模型只处理关键节点。

MiniMax、豆包和 DeepSeek 的位置不同

国产模型和套餐里，MiniMax、豆包、Kimi、DeepSeek 各有位置。

MiniMax 的优势是量大、便宜、功能全。它未必是最聪明的编程模型，但拿来做翻译、轻量整理、批处理，很划算。比如批量处理字幕、改格式、做简单校对，MiniMax 这类套餐很耐用。

豆包的优势是生态工具比较全，图片、视频、搜索、TTS、可能的 STT 和 embedding 都能接在一起。它更像综合型工具箱。

DeepSeek 的位置更明确：文本、代码、长上下文、低成本缓存。它没有完整的图像生成、语音、视频生态，短板很明显；但在 AI 编程和长文本 agent 工作流里，它的长板足够长。

所以不是谁替代谁，而是任务拆开以后各用各的。

省钱的关键不是只找便宜模型

AI 编程想省钱，不是简单把所有请求都换成便宜模型。

真正有效的省钱方式有几条：

简单任务不要启动重 agent。
能用 Flash 的任务不要上 Pro。
长任务尽量利用缓存。
重复上下文要稳定，避免无意义改动导致缓存失效。
大任务先让便宜模型做草稿和批处理，再让强模型做关键审查。
明确告诉 agent 不要重复描述事实，不要反复总结同一件事。

尤其是最后一点很重要。AI 工具很容易啰嗦，啰嗦不只是阅读体验问题，也是成本问题。提示词里明确要求“事实只描述一次，观点只表达一次”，能同时改善文章质量和 token 消耗。

DeepSeek 适合哪类 AI 编程工作流

DeepSeek 最适合这些任务：

长代码仓库阅读；
多文件轻量修改；
批量文档整理；
批量字幕翻译；
Hugo 文章整理；
agent 计划执行；
大量重复上下文的低成本自动化。

它不一定适合所有任务。如果要做特别强的前端审美、复杂产品判断、跨模态创作，可能还要搭配 Claude、GPT、Gemini、豆包或其他工具。

但只要任务是“长文本、长上下文、反复调用、成本敏感”，DeepSeek 就很容易变成首选。

小结

AI 编程工具这一轮，DeepSeek 的价值不只是“国产模型能写代码”，而是它解决了 agent 工具最现实的痛点：长任务太烧钱。

Claude Code、OpenClaw、Superpowers 这类工具会让开发流程越来越自动化，但自动化的背后是大量上下文读写和多轮调用。谁能把这部分成本压下来，谁就能让 AI 编程从“偶尔爽一下”变成“天天用得起”。

DeepSeek 的长上下文、低缓存成本和 V4 Flash / V4 Pro 分层使用，正好让它站在这个位置上。

这一轮真正省钱的关键，不是不用好模型，而是把好模型、便宜模型、缓存和 agent 流程搭配好。能把这套账算明白，AI 编程工具才真的会变成生产力，而不是一个漂亮但昂贵的玩具。

AI Coding 套餐怎么选：轻度看顺手，重度看灵活性

Sun, 10 May 2026 08:20:58 +0800

AI Coding 套餐这半年变化很快。很多工具从“按次”转向“按量”，免费或低价套餐的额度被收紧，部分海外服务还增加了身份验证、地区限制和更严格的用量规则。

对开发者来说，问题已经不只是“哪个模型最强”，而是：每个月要花多少钱、额度是否够用、工具是否顺手，以及当某个套餐突然涨价或改规则时，能不能平滑切换。

一个比较实用的结论是：轻度用户买顺手的工具，中度用户买性价比，重度用户买灵活性。使用越重，越不要把模型和工具绑死在同一个套餐里。

选套餐先看四件事

过去选 AI Coding 套餐，通常看三点：

模型能力是否足够强。
响应速度是否稳定。
套餐额度是否够用。

现在还要加上第四点：模型和工具能不能分开。

模型负责推理能力，工具负责上下文管理、文件编辑、Agent 编排和工作流体验。两者都重要，但最好不要完全绑定。比如喜欢 Claude 模型，可以买官方套餐，也可以通过 API 接到其他工具里；喜欢某个编辑器或 Agent 工具，也最好确认它能接入不同模型，而不是只能使用自家套餐。

这样做的好处不是折腾，而是降低风险。AI Coding 是变化最快的赛道之一，今天额度宽松的套餐，过两个月可能就改计费；今天好用的工具，下一版也可能因为模型接口变化而体验下降。把模型和工具分开，等于给自己留了迁移空间。

海外套餐正在收紧

GitHub Copilot、Cursor、Windsurf、Claude Code 这类工具仍然是很多人的主力选择，但整体趋势已经很明确：低价高额度越来越难维持，按量计费越来越常见。

GitHub Copilot 这类服务开始更强调使用量计费后，套餐本身的“套利空间”会明显减少。对轻度用户来说，它仍然方便；但对高频使用 Agent、长上下文和复杂代码任务的人来说，实际消耗会更接近真实 API 成本。

Cursor 和 Windsurf 本质上是把模型能力包进 IDE 体验里。它们的优势是开箱即用、编辑器体验成熟，缺点是工具绑定较深。一旦你依赖其中的专属 Agent、索引和自动化流程，后续迁移成本会越来越高。

Claude Code 的体验和生态热度很高，但海外订阅、身份验证、地区限制、中转服务安全性，都会成为国内用户需要额外评估的风险。尤其是第三方中转服务，可能存在模型掺杂、稳定性不足、数据安全和跑路风险，不适合作为重要项目的长期基础设施。

国产套餐的优点和短板

国产 AI Coding 套餐的一个优点，是很多服务以 API 形式提供，天然不太锁定工具。你可以把模型接入 OpenCode、Cline、Continue、自己的脚本或内部 Agent。

短板也很明显：如果同时要求模型强、速度快、额度足，很少有一个套餐能全部满足。

GLM 系列在国产模型里能力较强，但高峰期吞吐可能不稳定，重度任务容易被速度卡住。Kimi 的能力不错，但价格和额度规则需要持续关注，尤其要看后台额度是否透明。MiniMax 这类模型速度和额度较友好，适合日常轻任务、批处理和不太复杂的代码辅助，但在复杂工程推理上可能略低一档。DeepSeek 新模型如果处在活动价或优惠期，性价比会很高；活动结束后，就要重新按官方价格和套餐规则评估。

所以国产方案更适合作为“模型池”使用：不同任务用不同模型，而不是押注一个模型包打天下。

轻度用户：选顺手的，不必折腾 API

如果一周只是让 AI 改脚本、补文档、解释报错、写一点小工具，不需要复杂配置。

这类用户优先选顺手的产品。Cursor、Windsurf、Trae、CodeBuddy、通义灵码、GitHub Copilot 之类都可以尝试。重点不是追求最低单价，而是减少使用门槛：能在你常用编辑器里稳定工作、补全质量不错、出错时容易回退，就足够了。

轻度用户不建议为了省一点钱去折腾多层 API、中转站和复杂代理。时间成本、账户风险和排错成本往往高于节省下来的订阅费。

中度用户：看性价比，也看可迁移性

如果每天都会用 AI 写代码、改项目、生成测试、整理文档，就要开始关注额度和实际消耗。

这类用户可以把主力工具和备用模型分开安排。比如一个顺手的 IDE 套餐负责日常编辑，再配一个可接入多工具的 API 或聚合套餐，处理更长上下文、更复杂的 Agent 任务。

选择时可以重点看三点：

是否支持接入第三方工具。
是否能清楚看到 token 或额度消耗。
超额后是限速、降级、停止服务，还是按量付费。

如果一个套餐看起来便宜，但只允许在自家工具里使用，就要把迁移成本算进去。如果一个套餐贵一点，但能接入多种工具，反而可能更适合作为长期主力。

重度用户：不要把模型和工具绑死

重度用户的核心诉求是灵活性。

当一个人或团队每天大量使用 AI Agent，消耗会非常快。复杂代码库检索、长上下文修改、多轮调试、自动化测试修复，都会让 token 消耗成倍增长。此时再依赖单一套餐，很容易遇到三个问题：

额度突然不够。
计费规则突然改变。
某个工具或模型临时不可用。

更稳妥的做法是准备多层组合：一个主力 Agent 工具，一个或多个可替换模型接口，一个低成本模型处理简单任务，一个高能力模型处理复杂任务。日常小任务不要都交给最贵模型，关键任务也不要只依赖最便宜模型。

对重度用户来说，“工具能接任意模型，模型能接入任意工具”比单月便宜几十美元更重要。因为真正贵的不是订阅费，而是工作流被某个生态锁死后，迁移和重建习惯的成本。

一个更稳的组合思路

比较稳妥的组合可以这样安排：

轻任务用低成本模型：解释代码、写小脚本、改格式、生成简单文档。
中等任务用性价比模型：常规功能开发、测试补全、重构建议。
难任务用强模型：复杂架构调整、跨文件修复、疑难 bug、长上下文推理。
工具层保持开放：尽量选择能接 API、能导出配置、能切换模型的工具。
保留备用方案：主力套餐改规则时，可以快速切到另一个模型或工具。

这样不一定最省钱，但更抗波动。AI Coding 套餐的价格和额度还会继续变化，真正值得长期投入的是可迁移的工作流，而不是某个短期看起来特别划算的套餐。

小结

AI Coding 套餐不适合只看单月价格。轻度用户应该少折腾，选一个顺手的工具；中度用户要开始看额度、消耗和可迁移性；重度用户则要把模型和工具解耦，避免被单一生态绑定。

现在最值得记住的一点是：套餐会变，模型会变，工具也会变。把选择权留在自己手里，才是长期使用 AI Coding 工具时最重要的成本控制。

Codex vs Claude Code：两套 Subagent 机制怎么选

Fri, 08 May 2026 14:01:38 +0800

现在的 AI 编程工具越来越重视 Subagent。原因不是功能跟风，而是单个 Agent 处理真实工程任务时，很快会撞到边界。

一个 Agent 如果同时负责读代码、查日志、改实现、跑测试、分析报错、总结结果，主上下文会很快变脏。搜索结果、命令输出、测试日志和中间推理混在一起，后续判断就会被噪声干扰。任务也很难并行：探索、实现、验证和审查都塞在一条主线上，系统越做越重。

Subagent 的本质，是给 Agent 减压。主会话不再把所有事情从头做到尾，而是更像协调者：判断目标、安排任务、接收结果，再把结果合成最终答案。子 Agent 处理某一段局部工作，例如探索、实现、验证或审查，并只把压缩后的结论带回来。

所以 Subagent 不是“再开一个同款自己”，而是把原来糊成一团的工程工作拆成几个边界更清楚的角色。

成熟 Subagent 系统的底层共识

无论具体产品怎么设计，成熟的 Subagent 系统通常都绕不开四件事：

上下文隔离。
角色专用化。
项目和用户级配置。
工具与权限边界。

上下文隔离是前提。真实仓库里的中间结果很多：搜索结果可能几十条，测试日志可能几百行，命令输出里还混着大量无关信息。这些内容如果直接塞进主会话，主线很快会变乱。Subagent 的价值之一，就是让局部过程先在局部被消化，主会话只看到真正有决策价值的结论。

角色专用化也很关键。多 Agent 不是多开几个一样的模型一起干活。探索型任务要擅长搜索、阅读、总结；实现型任务要专注改代码和处理局部细节；验证型任务要跑检查、识别风险，并把结果清楚汇报。它们的任务边界、工具权限和输出形式都应该不同。

工具和权限边界决定了系统能不能安全落地。子 Agent 不应该默认拥有主会话的全部能力。探索型角色未必需要写文件，验证型角色未必需要改实现，后台任务也不该随意越过工作区边界。权限越清楚，协作越可控。

在这些共识之上，Codex 和 Claude Code 走出了两种不同路线。

Codex：显式派工，主会话始终在场

Codex 的 Subagent 设计气质更克制。

它更像是在说：我给你一套受控、轻量、围绕当前主会话展开的分工机制。什么时候派活、派给谁、什么时候收结果，都由主会话明确决定。控制流始终握在当前任务里。

这种设计的特点是“显式”：

需要子任务时，主会话明确发起委托。
子任务角色数量保持克制。
主会话知道哪个 Agent 在做什么。
结果回到主线后再统一判断。
协作边界比较透明。

公开可见的角色思路也偏简洁：通用角色、探索角色、工作角色这类基础分工已经能覆盖很多工程场景。自定义 Agent 更像配置层上的补充，而不是一套非常重的运行时对象系统。

Codex 这套方式的好处是可预期。它适合需要手动编排、强调确定性、希望主会话始终掌控节奏的团队。比如你正在做一个代码修改任务，可以先派一个探索角色查清调用链，再派一个工作角色做改动，最后由主会话整合并决定是否继续测试。

它的缺点也很清楚：如果任务越来越复杂，所有编排压力仍然落在主会话身上。主会话要判断何时拆分、如何拆分、派给谁、怎么合并结果。对轻量协作来说这很舒服，对长期复杂工程流来说，可能不如平台化系统省心。

Claude Code：把 Agent 做成正式工位

Claude Code 的取向更平台化。

它不是只提供几个临时帮手，而是把 Agent 做成可描述、可选择、可配置、可记忆、可隔离、可后台运行的正式对象。子 Agent 不只是会话里的一个工具，而更像工程系统里的一个工位。

这套思路会把 Agent 列表、适用场景、描述信息、工具边界等内容放进选择逻辑里，让模型判断本轮应该调用哪个角色。这类“模型驱动的委托”会带来更强的自动化：用户不一定每次都显式指定角色，系统可以根据任务类型自己选择。

从机制上看，Claude Code 更强调几类能力。

第一是角色体系。探索、规划、通用处理、验证等角色不是随手加几个名字，而是可以带着用途说明、工具限制、默认模型和运行条件存在。探索型角色可以被限制为只读，规划型角色负责设计方案，验证型角色可以专注检查和汇报。

第二是继承和覆盖。子 Agent 并不是完全自由的，它默认继承主会话的大边界；但在规则允许范围内，也可以通过局部配置调整权限、模式或行为。正确理解不是“全部继承”或“全部覆盖”，而是主会话定义大边界，Agent 在边界内做局部装配。

第三是记忆。记忆不只是“记住一点内容”，而是可以有作用域。用户级记忆更像长期偏好，项目级记忆更像仓库背景知识，本地级记忆更像只留在当前环境里的私人状态。这样某些 Agent 不必每次从零理解项目。

第四是后台和工作区隔离。某些验证任务可以在后台持续跑，主线不用停在原地等待。需要强隔离时，Agent 可以进入独立 worktree，像在主工位旁边分出一张独立桌子：仍然在同一个项目里，但操作空间被明确隔开。

第五是插件生态。只有当 Agent 被视为正式对象时，才会认真考虑它如何被分发、安装、覆盖、排序和接入生态。插件 Agent 可以进入系统，但高风险字段仍应被收口，例如权限模式、hooks、MCP server 等不应该由插件随意声明。

这让 Claude Code 更像一套 Agent 运行时，而不是单次会话里的协作工具。

两种路线的差异

可以把两者理解成两种产品哲学。

Codex 更像受控分工工具：

主会话显式派工。
角色集保持轻量。
控制流清晰。
子任务围绕当前会话展开。
适合强调确定性和人工编排的工作方式。

Claude Code 更像工程工位系统：

Agent 被正式建模。
角色更体系化。
支持记忆、后台、隔离和插件生态。
模型可以参与选择角色。
适合长期项目、复杂工作流和平台化扩展。

这不是谁功能更多谁就更好。真正的差别在于：你希望 Subagent 是“我显式叫来的助手”，还是“系统里长期存在的工位”。

怎么选择

如果你更看重显式控制、轻量分工、当前会话内的安全并行，Codex 的思路更顺手。它让你清楚知道任务什么时候被拆出去，谁在处理，结果什么时候回来。对代码审查、小型改动、明确的实现任务和需要人工节奏控制的场景，这种方式很稳。

如果你更看重体系化角色、长期记忆、后台执行、worktree 隔离、插件扩展和更完整的 Agent 运行时，Claude Code 的路线更合适。它适合把 Agent 当成长期参与项目的成员，而不是临时搬一把的助手。

可以用两个问题判断：

你能不能接受模型自己选择该派谁干活？
你是否需要一套更完整的 Agent 运行时？

如果第一个问题让你不舒服，说明你更适合显式派工。
如果第二个问题答案是肯定的，说明你可能需要平台化的 Agent 工位系统。

使用建议

无论选哪种，都不要把 Subagent 当作“多开几个模型就更强”。

更有效的做法是：

给每个角色明确任务边界。
控制每个角色能用的工具。
让子 Agent 输出结论，而不是搬回全部原始日志。
主会话保留最终决策权。
对后台任务和工作区隔离保持可见性。
对插件 Agent 设置明确安全边界。

工程任务里，Subagent 的价值不在数量，而在分工质量。角色越清楚，上下文越干净，主线判断越稳定。

小结

Codex 和 Claude Code 都在解决同一个问题：单个 Agent 很难独自承载真实工程任务。它们都承认上下文隔离、角色专用、权限边界和局部汇总的重要性。

差异在于实现取向。Codex 更克制，强调显式派工和主会话控制；Claude Code 更体系化，把 Agent 做成可配置、可记忆、可隔离、可后台运行、可进入插件生态的正式工位。

选择哪一个，不是看哪个品牌赢，而是看你的工作方式需要什么：是受控协作工具，还是完整 Agent 运行时。

goose：桌面端、CLI 和 API 一体的开源 AI Agent

Fri, 08 May 2026 13:35:45 +0800

goose 是一个运行在本机的开源 AI Agent。它不只面向代码补全，而是希望覆盖代码、研究、写作、自动化、数据分析等更广的任务。项目 README 里的定位很直接：桌面端、CLI 和 API 都提供，既可以给普通用户使用，也可以嵌入到自己的工作流里。

这个项目已经从 block/goose 迁移到 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）。当前仓库是：

`1`	`https://github.com/aaif-goose/goose`

goose 主要由 Rust 和 TypeScript 编写，许可证为 Apache-2.0。GitHub 项目描述是：一个开源、可扩展的 AI agent，不只给出代码建议，还能安装、执行、编辑和测试，并可接入任意 LLM。

goose 解决什么问题

很多 AI 编程工具只停留在“给建议”或“改代码”这一层。goose 的目标更宽一些：让 AI agent 直接在你的机器上完成任务。

它可以用于：

代码修改和测试。
本地自动化任务。
资料研究和写作。
数据分析。
多步骤工作流。
通过 API 嵌入到其他系统。
通过 MCP 扩展外部工具能力。

如果你只想在编辑器里要几段代码，普通 Copilot 类工具已经够用。goose 更适合想把 AI 放进“本机任务执行链”的用户：它可以使用本地环境、连接模型 provider、调用扩展，并通过桌面端或 CLI 进入不同工作方式。

三种入口：桌面端、CLI、API

goose 的一个特点是入口比较完整。

第一种是桌面端。它支持 macOS、Linux 和 Windows，适合不想一直待在终端里的用户，也适合需要更清晰可视化交互的人。

第二种是 CLI。终端用户可以直接安装命令行工具，把 goose 放进日常开发流程里。

第三种是 API。它可以作为可嵌入的 agent runtime，让其他系统或内部工具调用 goose 的能力。

这三个入口对应不同使用习惯。个人开发机可以先从桌面端或 CLI 开始；团队内部工具、自动化平台或实验型 agent 工作流，则更适合看 API 和自定义分发能力。

安装方式

官方 README 推荐先下载桌面端：

`1`	`https://goose-docs.ai/docs/getting-started/installation`

如果只安装 CLI，可以使用官方脚本：

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases 也提供不同平台的构建产物。当前 latest release 信息显示，v1.33.1 发布于 2026-04-29，包含 macOS、Linux、Windows、deb、rpm、Flatpak 等资产。

安装完成后，建议先按官方 Quickstart 配置 provider，再从一个低风险目录开始测试。由于 goose 可以执行本机任务，不建议一开始就在重要生产仓库里给它过高权限。

支持的模型和 provider

goose 支持 15+ provider。README 中列出的方向包括：

Anthropic
OpenAI
Google
Ollama
OpenRouter
Azure
Bedrock
更多 OpenAI-compatible 或云端 provider

它既可以使用 API key，也可以通过 ACP 使用已有的 Claude、ChatGPT 或 Gemini 订阅。

ACP 这一点值得关注。很多用户已经有模型订阅，但不同工具要么不支持直接复用，要么配置方式很割裂。goose 通过 ACP provider 把订阅模型接入 agent 工作流，能减少“订阅在一边、自动化工具在另一边”的割裂感。

不过 provider 政策变化很快。真正使用前，仍然要确认对应服务是否允许这种接入方式、是否有额度限制、是否适合公司代码或敏感数据。

MCP 扩展能力

goose 支持通过 Model Context Protocol（MCP）连接扩展。README 提到它可以连接 70+ extensions。

MCP 的意义在于：agent 不只会“聊天”和“改文件”，还能通过标准协议接入更多工具，比如文档、数据库、浏览器、内部系统、搜索服务、设计工具或项目管理系统。

对个人用户来说，MCP 可以让 goose 连接常用工具。对团队来说，MCP 更像一个安全边界和集成标准：你可以把内部能力包装成 server，让 agent 通过明确接口访问，而不是直接把所有系统暴露给模型。

与代码助手的区别

goose 不只是代码补全工具。更准确地说，它是一个本机 agent runtime。

代码助手通常重点在：

补全代码。
解释代码。
生成函数。
在编辑器里修改局部文件。

goose 更强调：

本机任务执行。
多步骤工作流。
provider 可切换。
扩展能力。
桌面端和 CLI 并存。
API 可嵌入。
不限定在代码任务。

这也意味着它的复杂度更高。你需要考虑模型配置、权限、扩展、工作目录、日志、凭据管理等问题。它不是“越自动越好”的工具，而是更适合被认真配置和逐步引入。

自定义分发

goose 仓库提供 CUSTOM_DISTROS.md，说明可以构建自己的 goose distro，预配置 provider、extensions 和 branding。

这对团队或组织很有意义。

比如团队可以做一个内部版本：

预置公司允许的模型 provider。
默认连接内部 MCP server。
配好安全策略和日志设置。
限制不允许使用的外部服务。
使用自己的品牌和默认引导。

这样普通成员不需要从零理解所有配置，也能减少把 key、provider、扩展配错的风险。

使用建议

如果你第一次尝试 goose，可以按这个顺序来：

先安装桌面端或 CLI。
配置一个你确定可用的 provider。
在测试目录里运行简单任务。
观察它会读取哪些文件、执行哪些动作。
再接入 MCP extension。
最后再尝试复杂代码仓库或自动化工作流。

不要一开始就把 goose 放进生产仓库、给它全部权限、再让它执行模糊任务。AI agent 的能力越强，越需要明确边界。

建议保持几个习惯：

重要改动前先提交 git。
不把 API key 写进项目文件。
只在可信 workspace 里启用高权限操作。
公司代码先确认数据合规和 provider 政策。
对自动化结果保留人工 review。

适合谁用

goose 更适合这些用户：

想要桌面端和 CLI 都可用的 AI agent。
希望使用多个模型 provider。
想通过 MCP 接入更多工具。
需要把 AI agent 嵌入自动化流程。
想在代码之外处理研究、写作、数据分析等任务。
团队希望构建带预配置的内部 agent 分发版。

如果你的需求只是“在 IDE 里补全代码”，goose 可能显得重。
如果你想要一个可以长期扩展的本机 agent 平台，它的设计会更有吸引力。

小结

goose 是 AAIF/Linux Foundation 旗下的开源 AI Agent，定位比传统代码助手更广。它提供桌面端、CLI 和 API，支持 15+ provider、ACP 订阅接入和 70+ MCP extensions，适合把 AI 放进本机工作流和团队自动化体系里。

它的价值不只是“能写代码”，而是把模型、工具、扩展和执行环境放在同一个 agent 框架下。使用时要特别注意权限、凭据和数据边界：先从小任务开始，确认 provider、扩展和执行行为都符合预期，再逐步扩大使用范围。

参考资料

9Router：把 Claude Code、Codex、Cursor 接到同一个 AI 路由器

Fri, 08 May 2026 13:32:38 +0800

9Router 是一个面向 AI 编程工具的本地路由器。它把 Claude Code、Codex、Cursor、Cline、Copilot、OpenCode、OpenClaw 等工具统一接到一个 OpenAI-compatible endpoint，再由 9Router 负责转发到不同模型和服务商。

它的目标不是再做一个聊天客户端，而是放在 AI 编程工具和模型服务之间，解决几个实际问题：

不同工具的 API 格式不一致。
订阅额度、免费额度和便宜 API 需要手动切换。
git diff、grep、ls、tree 等工具输出会快速消耗 token。
某个模型限流或额度耗尽时，编码流程容易中断。
多账号、多 provider、多模型组合管理成本高。

根据项目说明，9Router 支持 40+ provider 和 100+ 模型，并提供 RTK Token Saver、自动 fallback、额度追踪、多账号轮询、格式转换和请求日志等功能。项目使用 JavaScript 编写，技术栈包括 Node.js、Next.js、React、Tailwind CSS 和 LowDB，许可证为 MIT。

它适合解决什么问题

9Router 最适合的场景，是你同时使用多个 AI 编程工具和多个模型来源。

比如：

Claude Code 用订阅账号。
Codex 或 Cursor 需要接自定义 OpenAI endpoint。
Cline、Continue、RooCode 需要 OpenAI-compatible API。
免费 provider 作为日常尝试。
GLM、MiniMax、Kimi 等便宜 API 作为备用。
某些高质量模型只在复杂任务时使用。

没有 9Router 时，这些配置往往分散在不同工具里。每个工具都要单独写 endpoint、API key、模型名和 fallback 策略。9Router 的思路是让工具都访问同一个本地地址，再在路由器里配置 provider、combo 和优先级。

默认本地地址是：

`1`	`http://localhost:20128/v1`

Dashboard 地址通常是：

`1`	`http://localhost:20128/dashboard`

快速安装

如果只是本机使用，可以直接通过 npm 安装：

1
2

npm install -g 9router
9router

启动后，Dashboard 会在本地打开。项目文档中的默认端口是 20128。

如果想从源码运行：

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

生产模式可以先构建再启动：

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

npm 包当前要求 Node.js >=18.0.0。如果是部署到 VPS 或 Docker，建议按项目 README 配置 JWT_SECRET、INITIAL_PASSWORD、DATA_DIR、API_KEY_SECRET 等环境变量，不要直接暴露默认配置。

接入 AI 编程工具

9Router 对外提供 OpenAI-compatible API，因此大多数支持自定义 OpenAI endpoint 的工具都能接。

常见配置大致如下：

1
2
3

Base URL: http://localhost:20128/v1
API Key: 从 9Router Dashboard 复制
Model: 在 9Router 中配置的模型名或 combo 名

以 Codex CLI 为例，可以使用环境变量：

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

以 Cline、Continue、RooCode 这类工具为例，通常选择 OpenAI Compatible provider，然后填入：

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

模型名取决于你在 9Router 中连接了哪些 provider。README 中示例包括 cc/、cx/、gh/、glm/、minimax/、kr/、vertex/ 等前缀。

RTK Token Saver 的意义

AI 编程工具消耗 token 最快的地方，往往不是普通对话，而是工具输出。

例如：

git diff
git status
grep
find
ls
tree
日志片段
大段文件列表

9Router 内置 RTK Token Saver，会在请求发给模型前压缩这类工具输出。项目说明称，它可以在很多请求中节省 20%-40% input tokens。

这个功能的价值在于：它不要求你更换模型，也不改变上层工具使用习惯，而是在路由层减少无效上下文。对经常让 AI 读 diff、搜代码、看目录结构的人来说，这比单纯换一个更便宜的模型更直接。

不过它不是万能压缩。涉及关键上下文、完整日志或长文件内容时，仍然要留意是否需要保留原始信息。更稳妥的做法是先在本地开发环境里试用，确认回答质量没有明显下降，再把它放到长期工作流里。

自动 fallback 怎么用

9Router 的另一个重点是三层 fallback。你可以把模型按优先级组合起来：

1
2
3

1. 订阅模型
2. 便宜 API
3. 免费 provider

当第一层额度用完、限流或出错时，9Router 自动切到下一层。这样做的好处是减少手动切换模型的次数，也能避免写代码写到一半突然停住。

一个常见组合可以是：

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

如果你追求稳定，可以把付费或订阅模型放前面，把便宜模型作为备用；如果你追求低成本，可以把免费 provider 放前面，把便宜 API 放在后面兜底。

这里要注意：fallback 会影响输出一致性。不同模型的代码风格、推理强度和上下文处理能力不同。对需要严格一致性的任务，比如大型重构、协议实现、数据库迁移，最好固定主模型，只有失败时再手动切换。

免费 provider 要谨慎理解

项目 README 强调 Kiro、OpenCode Free、Vertex 等免费路径，并且提到部分历史免费层已经变化或不再推荐。

这类信息变化很快，使用时要按当时 provider 的官方政策确认：

是否真的免费。
是否有区域、账号或使用场景限制。
是否允许接入第三方工具。
是否可能触发封号或限流。
免费额度是否有到期时间。

9Router 可以帮你管理路由和 fallback，但不能改变上游 provider 的服务条款。尤其是把个人订阅、OAuth token 或免费额度接给自动化工具时，最好只在自己可控的本机环境里使用，并定期检查账号安全。

本地运行和部署建议

本机使用时，最简单的方式是只监听 localhost。这样 Claude Code、Codex、Cursor、Cline 等本地工具可以访问 9Router，但外部网络不能直接连进来。

如果要部署到 VPS 或局域网服务器，建议至少做到：

修改默认登录密码。
设置强 JWT_SECRET。
设置 API_KEY_SECRET。
开启访问控制或反向代理认证。
避免把 Dashboard 裸露到公网。
对 /v1/* 接口启用 Bearer API key。
定期备份 DATA_DIR 下的配置和用量数据。

Docker 运行时可以参考项目文档，把数据目录挂载出来：

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

如果只是个人开发机使用，没有必要一上来就公网部署。先在本地跑通 provider、combo、工具接入和日志，再决定是否迁移到服务器。

适合谁用

9Router 更适合这些用户：

同时使用多个 AI 编程工具。
同时有订阅、免费额度和付费 API。
经常被 provider 限流或额度耗尽打断。
想把模型 fallback 做成统一配置。
想减少工具输出带来的 token 浪费。
愿意自己维护本地代理和 provider 凭据。

如果你只用一个工具、一个模型，而且额度足够，9Router 可能会增加一层不必要的复杂度。它真正有价值的地方，是把“多工具、多模型、多账号、多价格层”的混乱收进一个本地路由层里。

小结

9Router 可以理解为 AI 编程工具的本地网关。它把 Claude Code、Codex、Cursor、Cline 等工具统一接到 http://localhost:20128/v1，再由路由器处理模型选择、格式转换、token 压缩、额度追踪和 fallback。

它适合重度 AI 编程用户，尤其适合已经在多个 provider 之间来回切换的人。最稳妥的使用方式是先本地安装，接入一个常用工具和一个 provider，确认请求、日志、模型名和 fallback 都正常后，再逐步增加账号和模型组合。

如果你只是想省心，单一官方客户端仍然更简单。
如果你想把 AI 编程工具变成一套可配置、可切换、可兜底的工作流，9Router 值得试试。

参考资料

VS Code 切换界面语言的方法：中文、英文和其他语言

Fri, 08 May 2026 13:28:14 +0800

VS Code 支持多种界面语言。常见做法是先安装对应语言包，再通过命令面板选择显示语言；如果需要固定某种语言，也可以手动修改 argv.json 中的 locale。

这套方法不仅适用于简体中文，也适用于英文、繁体中文、日文、韩文、法文、德文、西班牙文等语言。

安装对应语言包

如果要切换到非英文界面，通常需要先安装语言包。

打开 VS Code 左侧扩展面板，也可以使用快捷键 Ctrl+Shift+X。
在搜索框中输入目标语言，例如 Chinese、Japanese、Korean、French。
选择对应语言包，点击 Install。
安装完成后，按提示重启 VS Code。

简体中文常用语言包是 Chinese (Simplified)，繁体中文常用语言包是 Chinese (Traditional)。

通过命令面板切换语言

这是最推荐的切换方式，适合大多数用户。

打开命令面板：Ctrl+Shift+P。
输入 Configure Display Language。
选择 Configure Display Language 命令。
在列表中选择要使用的语言。
按提示重启 VS Code。

重启后，菜单、设置页和常见提示会切换到所选语言。如果列表里没有目标语言，先到扩展面板安装对应语言包。

通过 argv.json 手动指定语言

如果命令面板切换失败，或者想明确固定显示语言，可以直接修改 VS Code 的运行时参数文件。

打开命令面板：Ctrl+Shift+P。
输入并选择 Preferences: Configure Runtime Arguments。
找到或添加 locale 配置项。
把值改成目标语言代码。
保存后重启 VS Code。

例如切换为英文：

1
2
3

{
  "locale": "en"
}

切换为简体中文：

1
2
3

{
  "locale": "zh-cn"
}

切换为日文：

1
2
3

{
  "locale": "ja"
}

argv.json 是 JSON 文件，修改时要注意逗号和引号。配置写错时，VS Code 可能无法正确读取语言设置。

常用界面语言代码

显示语言	locale
English (US)	`en`
简体中文	`zh-cn`
繁体中文	`zh-tw`
French	`fr`
German	`de`
Italian	`it`
Spanish	`es`
Japanese	`ja`
Korean	`ko`
Russian	`ru`
Portuguese (Brazil)	`pt-br`
Turkish	`tr`
Bulgarian	`bg`
Hungarian	`hu`

语言没有生效怎么办

可以按下面顺序排查：

确认目标语言包已经安装。
确认 locale 写的是正确语言代码，例如简体中文是 zh-cn，不是 zh-CN。
修改语言后完整关闭并重新打开 VS Code。
如果手动改过 argv.json，检查 JSON 语法是否正确。
如果配置混乱，可以删除 locale 项，再通过 Configure Display Language 重新选择。

一般来说，通过 Configure Display Language 切换最省事；只有在需要强制指定语言或命令面板切换不生效时，才建议手动修改 argv.json。

参考资料

VScode：将VScode界面的显示语言改为简体中文，切换VScode界面的显示语言

Claude Code 24 个使用技巧：计划模式、回滚、CLAUDE.md、Skills、Agents 和插件

Fri, 08 May 2026 08:54:14 +0800

Claude Code 不只是一个聊天框。它更像一个能进入项目目录、读写文件、执行命令、维护上下文的编程 Agent。

如果只是把需求丢进去让它生成代码，很快会遇到几个问题：计划不够清楚、权限反复确认、上下文越来越长、生成结果不满意、不知道怎么回滚，也不知道怎么把项目规则长期保存下来。

下面整理一组常用操作，适合刚开始使用 Claude Code 的开发者快速建立工作流。

先在项目目录启动

Claude Code 最好在项目目录里启动，而不是随便打开一个终端就开始用。

可以先创建一个文件夹作为项目目录，进入目录后打开命令行，再启动 Claude Code：

claude

首次进入项目时，如果 Claude Code 询问是否信任当前文件夹，确认后再继续。这样它才能围绕当前项目读取文件、创建文件和执行后续操作。

一个简单的练习方式是让它创建一个摄影师个人网站。这个任务足够直观：能看到页面效果，也能练习文件生成、命令执行、回滚和后续重构。

计划模式先把方向想清楚

Claude Code 在面对较复杂任务时会进入计划模式。计划模式的作用是先讨论需求、拆解步骤，再让用户决定是否批准执行。

当它给出计划后，通常会出现几类选择：

批准计划，并允许后续自动使用编辑工具。
批准计划，但后续编辑仍然需要手动确认。
暂停执行，继续和 Claude Code 讨论计划。

如果任务比较明确，可以批准计划并继续。如果任务还不清楚，建议先让它继续补充方案，比如页面风格、技术栈、目录结构、交互效果和验收标准。

计划模式的好处是减少返工。直接让 Agent 动手，可能很快生成一堆文件；但如果方向错了，后面越改越乱。

用 Shift + Tab 切换模式

在 Claude Code 中，可以用 Shift + Tab 在不同工作模式之间切换。常见用途是进入计划模式，或者切换到自动同意编辑工具的模式。

建议的习惯是：

新项目、新功能、大改动：先进入计划模式。
小改动、明确修复：可以直接执行。
涉及删除、批量替换、安装依赖：保持人工确认。

计划模式下，Claude Code 可能会主动询问项目细节。可以用方向键选择选项，用回车确认。提交反馈后，它会根据你的选择更新计划。

权限确认不要一律放开

Claude Code 执行命令、编辑文件或启动程序时，可能会申请权限。

常见选择包括：

只同意本次使用。
在当前会话中以后都同意同类命令。
拒绝或暂停。

如果只是启动本地页面、运行开发服务器、查看文件，可以根据需要允许。但不要为了省事长期使用“自动同意所有权限”的启动方式。

全自动权限适合非常确定、风险很低、项目已经有 Git 备份的场景。日常使用中，涉及删除文件、覆盖目录、安装依赖、联网、提交代码、执行脚本时，最好保留人工确认。

用终端模式执行本地命令

Claude Code 里可以进入终端命令模式，直接执行一些本地命令。

例如页面生成后，可以用系统命令打开 HTML 文件：

`1`	`start index.html`

这里的 start 是 Windows 下打开文件的命令，后面接文件名。这样可以快速查看生成页面，而不用手动去资源管理器里找文件。

终端模式适合执行这些轻量操作：

打开生成的页面。
查看目录内容。
启动本地开发服务器。
运行测试或构建命令。

但高风险命令仍然要谨慎，比如递归删除、移动目录、批量覆盖和修改系统环境。

回滚：结果不满意时及时退回

如果 Claude Code 做出的页面或代码不是你想要的，而且越改越乱，就应该及时回滚。

回滚功能可以把对话或代码退回到某个节点。常见选项包括：

同时回滚代码和对话。
只回滚对话。
只回滚代码。
把某个节点之前的内容压缩成摘要。
取消操作。

更推荐在明显走偏时选择“同时回滚代码和对话”。这样可以让上下文和文件状态一起回到较干净的位置。

需要注意：Claude Code 的回滚通常只能覆盖它通过内置工具创建或修改的文件。如果文件是通过外部命令生成的，未必能完整回滚。因此重要项目仍然要配合 Git 使用。

长提示词用编辑器写

复杂需求不要全挤在一行输入框里。

如果系统支持在文本编辑器中编辑长提示词，可以打开编辑器，把需求写完整后保存，再发送给 Claude Code。

长提示词里建议写清楚：

目标是什么。
使用什么技术栈。
不要做什么。
需要保留哪些文件。
完成后如何验证。
页面或功能的验收标准。

例如让 Claude Code 把一个普通 HTML 页面重构成更现代的技术栈时，不要只写“重构一下”。可以说明希望使用组件化结构、保留视觉内容、增加响应式布局，并要求它运行构建检查。

退出后用历史恢复会话

如果中途需要退出 Claude Code，可以正常退出。之后回到同一个项目目录，再次启动：

claude

如果发现前面的记录没有直接显示，可以使用历史相关命令查看最近会话，并加载之前的会话。

这个功能适合中断后继续工作。不过不要把会话历史当成唯一记忆。项目规则、技术栈、常用命令和注意事项，最好写进项目文件里。

用 CLAUDE.md 保存项目规则

CLAUDE.md 是 Claude Code 很重要的记忆文件。它通常放在项目根目录，用来告诉 Claude Code 项目规则、技术栈、目录结构和协作约束。

可以让 Claude Code 初始化这个文件：

/init

CLAUDE.md 适合记录：

项目目标。
技术栈。
常用启动、测试、构建命令。
目录说明。
代码风格。
不允许执行的操作。
提交和部署规则。

每次对话时，Claude Code 会把这类规则作为上下文的一部分使用。你可以把它理解成“项目说明书”。

一个简单验证方式是：在 CLAUDE.md 里加入一条明显规则，然后再向 Claude Code 提问。如果回答遵循了这条规则，就说明它确实读到了项目记忆。

用 @ 引用文件

在输入框中使用 @，可以选择文件或 Agent，把指定内容加入当前对话上下文。

这适合几类场景：

让 Claude Code 阅读某个配置文件。
让它修改某个指定页面。
让它根据 CLAUDE.md 或其他文档继续工作。
明确告诉它“只看这个文件，不要猜项目结构”。

相比把文件内容复制到输入框里，@ 引用更清晰，也更不容易漏内容。

查看和压缩上下文

长时间对话后，上下文会越来越大。上下文太长时，模型可能变慢，也可能开始忽略早期细节。

可以使用上下文查看命令了解当前占用情况：

`1`	`/context`

如果上下文已经很长，可以压缩历史：

`1`	`/compact`

如果压缩后效果仍然不好，可以考虑清空当前上下文：

/clear

清空上下文后，Claude Code 仍然可以通过项目文件、CLAUDE.md 和当前目录重新理解一部分项目情况，但不会保留完整对话历史。

实用建议是：一个任务完成后就开新会话；项目级规则写进 CLAUDE.md；临时讨论不要无限堆在一个聊天里。

Skills：把固定流程做成说明书

Skills 可以理解为 Claude Code 的工作说明书。它不是一次性提示词，而是一套可复用的任务流程。

例如你经常要生成周报，就可以创建一个周报 Skill，里面写清楚：

输入需要哪些信息。
输出格式是什么。
语气和结构怎么控制。
哪些内容必须保留。
哪些内容不能编造。

Skills 通常由 name、description 和具体指令组成。安装到全局 Skills 目录后，Claude Code 在遇到相关任务时可以识别并加载。

这适合处理重复工作：

周报。
代码审查模板。
文档整理。
图片批处理。
固定格式文章。
项目初始化流程。

如果你发现自己反复复制同一段提示词，就可以考虑把它做成 Skill。

Agents：把子任务交给独立助手

Agents 和 Skills 不一样。

Skill 更像说明书，告诉 Claude Code 怎么做某类任务；Agent 更像一个独立助手，可以在当前主会话之外执行任务，完成后把结果返回。

Agents 的价值在于隔离上下文。比如做代码巡检时，可以创建一个只读 Agent，让它只读取项目并输出报告，不直接修改文件。这样不会污染主会话，也能降低误操作风险。

创建 Agent 时通常要考虑：

是项目级 Agent，还是用户级 Agent。
是否需要 Claude Code 帮你生成配置。
允许哪些工具权限。
使用哪个模型。
是否保存记忆。
Agent 的提示词是否足够明确。

对于代码巡检类 Agent，建议只给读取权限，不给写入权限。先让它输出报告，再由主会话决定是否修改代码。

插件：打包 Skills、Agents、MCP 和 Hooks

插件可以理解为更完整的能力包。它可能同时包含：

Skills
Agents
MCP
Hooks

相比单独安装一个 Skill，插件更适合成套能力。例如前端设计插件可能会把页面审美、布局规则、组件习惯和相关 Agent 一起打包。

安装插件时通常会有几个位置选项：

如果是个人常用能力，可以放在用户目录；如果是团队项目约定，可以放进项目目录；如果只是临时测试，放本地项目目录更稳。

插件能明显改善特定任务效果

在前端页面生成这类任务里，插件往往比裸提示词更稳定。

例如同样是“制作一个摄影师个人网页”，只用普通提示词可能生成一个能看的页面；如果明确使用前端设计插件，页面结构、视觉层次、间距、配色和整体完成度通常会更好。

这并不意味着插件能替代人工审美。更合理的用法是：先让插件生成一个更好的初稿，再由人做细节微调。

一套更稳的 Claude Code 工作流

把上面这些技巧组合起来，可以形成一套比较稳的流程：

在项目目录启动 claude。
先用计划模式讨论需求。
批准计划前确认技术栈和验收标准。
涉及高风险操作时保留手动确认。
用终端模式执行本地预览和测试。
结果走偏时及时回滚。
把项目规则写进 CLAUDE.md。
长对话定期查看和压缩上下文。
重复流程沉淀成 Skills。
巡检、研究、分析类任务交给只读 Agents。
特定领域任务优先用插件。
重要项目始终配合 Git 提交点。

这样使用 Claude Code，会比单纯“发一句需求等它生成”稳定得多。

小结

Claude Code 的效率不只来自模型能力，也来自工作流控制。

计划模式决定方向，权限确认控制风险，回滚减少返工，CLAUDE.md 保存项目规则，/context、/compact 和 /clear 管理上下文，Skills 复用固定流程，Agents 隔离复杂子任务，插件则把成套能力打包进项目。

真正好用的 Claude Code 工作方式，是让它在清楚边界内持续推进任务，而不是把整个项目一次性交给它自由发挥。

opencode、Claude Code、Codex 有什么区别？开源 AI 编程工具使用指南

Fri, 08 May 2026 08:33:37 +0800

opencode 是 anomalyco 开源的 AI Coding Agent。它的定位很直接：让开发者在终端里使用一个可编程、可扩展、可接入多家模型的代码助手。

如果把它和 Claude Code、Codex 放在一起看，三者解决的是同一类问题：让 AI 进入真实代码库，理解上下文，修改文件，运行命令和测试。但它们的产品取向不一样。

opencode 更强调开源、多模型和终端 TUI；Claude Code 更强调 Anthropic 模型生态和本地工程协作；Codex 则是 OpenAI 的 AI coding agent，可以在终端、IDE、Codex app 和云端任务里使用。

opencode 适合谁

opencode 更适合这几类开发者：

想在终端里完成代码修改、项目分析和工程任务的人。
希望 AI Coding Agent 不绑定单一模型提供商的人。
偏好开源工具，想自己审计、扩展或二次开发的人。
已经习惯 Neovim、TUI、命令行工作流的人。
希望以后用桌面端、移动端或其他客户端远程驱动同一个编码代理的人。

它的重点不是做一个聊天窗口，而是把 AI 编程能力放进开发者原本使用的终端和项目目录里。

安装方式

官方 README 提供了多种安装方式。

# 直接安装
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS 和 Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# 其他方式
mise use -g opencode
nix run nixpkgs#opencode

官方也提醒，安装前最好先移除 0.1.x 之前的旧版本，避免旧版本残留造成问题。

安装脚本会按优先级选择安装目录：

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

如果需要指定路径，可以这样写：

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

桌面应用还在 Beta

除了命令行工具，opencode 也提供桌面应用，目前仍处于 Beta。可以从 GitHub Releases 或 opencode.ai/download 下载。

桌面端覆盖这些平台：

平台	文件
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` 或 `.AppImage`

macOS 和 Windows 也可以通过包管理器安装桌面端。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

两种内置 Agent 模式

opencode 内置两种 Agent，可以通过 Tab 键切换。

build 是默认模式，拥有完整开发权限，适合直接修改代码、运行命令和推进工程任务。

plan 是只读模式，更适合分析陌生代码库、理解项目结构、制定修改方案。它默认拒绝文件编辑，并且在运行 bash 命令前会询问。

另外，opencode 还带有一个 general 子 Agent，用于复杂搜索和多步骤任务。用户可以在消息中输入 @general 调用。

这个设计比较实用：真正动手前先用 plan 看清楚项目，需要改代码时再切到 build。对于大型仓库，读写权限分开能减少误操作。

Codex 是什么

Codex 是 OpenAI 的 AI coding agent，用来帮助开发者写代码、审查代码、修复 bug 和交付工程任务。

和单纯的代码补全工具不同，Codex 更接近一个可以操作代码库的 Agent。它可以在本地工具里和你结对，也可以把任务委托到云端执行。OpenAI 官方资料里提到，Codex 可以通过 CLI、IDE、Codex app、ChatGPT/Codex 云端等不同入口使用。

对开发者来说，Codex 的重点有几处：

可以读取代码库、编辑文件、运行命令和测试。
支持终端、IDE、应用和云端等多种使用界面。
适合修 bug、写功能、重构、迁移、代码审查和测试补齐。
更偏 OpenAI 账户、模型和 Codex 产品体系。
云端任务适合并行处理多个相对清晰的工程任务。

如果 opencode 更像一个开放的终端代理框架，Codex 更像 OpenAI 提供的一整套 AI 编程工作台：本地可以结对，云端可以委托，团队可以把它接入更长的工程流程。

三者核心区别

opencode、Claude Code、Codex 都是 AI 编程工具，但选择时可以先看这几个维度。

工具	核心定位	主要优势	更适合
`opencode`	开源 AI Coding Agent	开源、多模型、TUI、客户端/服务器架构	想要开放工具链、可替换模型、偏终端工作流的开发者
`Claude Code`	Anthropic 的命令行编程工具	Claude 模型体验、代码理解、长上下文、工程任务协作	已经使用 Claude/Anthropic 生态，希望本地推进代码任务的开发者
`Codex`	OpenAI 的 AI coding agent	CLI、IDE、Codex app、云端任务、多 Agent 工作流	已经使用 ChatGPT/OpenAI，希望本地结对和云端委托并用的团队

简单说，opencode 的关键词是“开源和可替换”，Claude Code 的关键词是“Claude 生态和本地工程代理”，Codex 的关键词是“OpenAI 生态和多入口协作”。

和 Claude Code 的区别

opencode 的官方 FAQ 直接把 Claude Code 拿来对比。两者能力上很接近，但差异主要在这几处。

第一，opencode 是 100% 开源项目，代码托管在 GitHub，并使用 MIT license。

第二，opencode 不绑定单一模型提供商。它推荐 OpenCode Zen 提供的模型，但也可以搭配 Claude、OpenAI、Google 或本地模型。对开发者来说，这意味着模型成本、能力和可用性变化时，不必被某一个平台锁住。

第三，opencode 内置可选的 LSP 支持。对代码补全、跳转、诊断和项目理解来说，LSP 是非常关键的基础能力。

第四，opencode 更强调 TUI。它由 Neovim 用户和 terminal.shop 的创建者打造，产品重心明显放在终端体验上。

第五，opencode 采用客户端/服务器架构。也就是说，opencode 可以在你的电脑上运行，未来由 TUI、桌面端、移动端或其他客户端来控制。TUI 只是其中一种前端形态。

什么时候选 opencode、Claude Code 或 Codex

如果你已经在使用 Claude Code 或 Codex，opencode 不一定是立刻替换它们的工具。更合理的看法是：它提供了一个开源、可替换模型、偏终端的选择。

可以优先考虑 opencode 的场景包括：

你希望 AI 编程工具尽量开源。
你不想把工作流绑定在某个模型供应商上。
你希望用同一个工具测试 Claude、OpenAI、Google 或本地模型。
你喜欢 TUI，不希望主要工作流被桌面应用或网页应用打断。
你关注客户端/服务器架构带来的远程控制能力。

可以优先考虑 Claude Code 的场景包括：

你主要使用 Claude 模型。
你重视长上下文、代码理解和复杂工程任务协作。
你希望在本地仓库中持续推进修改、测试和重构。
你更信任 Anthropic 对 Claude Code 的默认产品体验。

可以优先考虑 Codex 的场景包括：

你已经在使用 ChatGPT 或 OpenAI 账户体系。
你希望同一个 coding agent 覆盖终端、IDE、桌面应用和云端任务。
你想把较清晰的 bug 修复、功能开发、迁移、测试补齐交给云端并行处理。
你需要代码审查、后台任务、团队协作和多 Agent 工作流。

如果你更看重官方闭环体验、模型默认配置、企业管理和现成集成，Claude Code 或 Codex 可能更省心；如果你更看重可控性、开放性和 provider-agnostic，opencode 更值得关注。

需要注意的地方

opencode、Claude Code 和 Codex 都发展很快，GitHub release、安装命令、桌面端文件名、模型可用性和套餐权限都可能变化。实际安装和选型前，最好直接查看各自官方 README、文档和发布页面。

另外，它的桌面应用仍然标注为 Beta，不适合默认当作稳定生产工具。对于日常工程任务，终端版仍然是更主要的入口。

从工具趋势看，opencode 代表的是 AI Coding Agent 的开放工具链方向：模型可以替换，客户端可以替换，核心代理能力尽量开放。Codex 和 Claude Code 则更像模型公司把 coding agent 做成完整产品入口。对开发者来说，这两条路线会长期并存。

参考链接

opencode GitHub：https://github.com/anomalyco/opencode
opencode 官网：https://opencode.ai
opencode 文档：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

uv 安装指南：macOS、Linux、Windows、pipx、Homebrew 和 WinGet 怎么选

Thu, 07 May 2026 23:02:49 +0800

uv 是 Astral 推出的 Python 工具链管理器，可以用来管理 Python 版本、虚拟环境、依赖、脚本、项目和工具。它的安装方式很多，官方文档提供了独立安装脚本，也支持 PyPI、Homebrew、WinGet、Scoop、Docker、GitHub Releases 和 Cargo。

如果只是想快速安装，优先用官方独立安装脚本。如果你希望通过系统包管理器维护版本，就用 Homebrew、WinGet 或 Scoop。如果你已经习惯 Python 工具隔离安装，可以用 pipx。

快速选择

场景	推荐方式	命令
macOS / Linux 快速安装	官方独立安装脚本	`curl -LsSf https://astral.sh/uv/install.sh \| sh`
macOS / Linux 没有 curl	官方脚本 + wget	`wget -qO- https://astral.sh/uv/install.sh \| sh`
Windows 快速安装	PowerShell 安装脚本	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`
Python 工具隔离安装	pipx	`pipx install uv`
临时或传统 Python 安装	pip	`pip install uv`
macOS 包管理	Homebrew	`brew install uv`
macOS MacPorts 用户	MacPorts	`sudo port install uv`
Windows 包管理	WinGet	`winget install --id=astral-sh.uv -e`
Windows Scoop 用户	Scoop	`scoop install main/uv`
Rust 用户	Cargo	`cargo install --locked uv`

最推荐的通用方案：

macOS / Linux：官方独立安装脚本；
Windows：官方 PowerShell 安装脚本或 WinGet；
已经使用 pipx 管理 Python CLI 工具：pipx install uv。

macOS 和 Linux：官方安装脚本

官方最直接的安装方式是用 curl 下载脚本并交给 sh 执行：

`1`	`curl -LsSf https://astral.sh/uv/install.sh \| sh`

如果系统没有 curl，可以用 wget：

`1`	`wget -qO- https://astral.sh/uv/install.sh \| sh`

如果想安装指定版本，可以把版本号放进 URL。比如官方示例中的 0.11.11：

`1`	`curl -LsSf https://astral.sh/uv/0.11.11/install.sh \| sh`

这个方式适合绝大多数个人开发环境。它的优点是简单、跨平台、和 uv 官方更新机制配合最好。

安装脚本会把 uv、uvx 等二进制文件安装到用户目录下，并可能修改 shell profile，让命令可以直接在终端中使用。如果你不希望安装器修改 PATH，可以参考官方 installer 选项，例如设置 UV_NO_MODIFY_PATH=1。

Windows：PowerShell 安装脚本

Windows 官方安装方式是用 PowerShell 执行安装脚本：

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 \| iex"`

如果要安装指定版本，也可以把版本号放进 URL：

`1`	`powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/0.11.11/install.ps1 \| iex"`

这里的 ExecutionPolicy ByPass 是为了允许从互联网获取并执行安装脚本。安全习惯上，执行前可以先查看脚本内容：

`1`	`powershell -c "irm https://astral.sh/uv/install.ps1 \| more"`

如果你习惯 Windows 包管理器，也可以优先用 WinGet 或 Scoop。

用 pipx 安装

官方文档提到，uv 发布到了 PyPI。如果从 PyPI 安装，推荐放进隔离环境，例如用 pipx：

`1`	`pipx install uv`

这个方式适合已经把 pipx 当作 Python CLI 工具管理器的人。它可以避免把 uv 和当前项目环境混在一起。

如果没有 pipx，也可以直接用 pip：

`1`	`pip install uv`

但要注意：uv 在许多平台上提供预构建 wheel。如果某个平台没有对应 wheel，就会从源码构建，这时需要 Rust 工具链。

我的建议是：个人机器上，pipx install uv 比 pip install uv 更干净；项目环境里，不建议把 uv 当作项目依赖安装。

Homebrew、MacPorts、WinGet 和 Scoop

如果你更喜欢系统包管理器，uv 也支持常见渠道。

macOS 上用 Homebrew：

`1`	`brew install uv`

MacPorts 用户可以用：

`1`	`sudo port install uv`

Windows 上用 WinGet：

`1`	`winget install --id=astral-sh.uv -e`

Scoop 用户可以用：

`1`	`scoop install main/uv`

这些方式的好处是统一交给系统包管理器维护。缺点是升级节奏取决于对应包源，而不是 uv 官方安装脚本。

Docker、GitHub Releases 和 Cargo

uv 还提供 Docker 镜像，地址在 GitHub Container Registry：

`1`	`ghcr.io/astral-sh/uv`

这适合 CI、Dockerfile、构建镜像和临时运行环境。实际使用时，建议再看官方 Docker 集成文档。

如果你想手动下载二进制文件，可以从 GitHub Releases 获取。每个 release 页面通常包含支持平台的二进制文件，也会说明如何用 GitHub 地址调用独立安装器。

Rust 用户也可以从 crates.io 安装：

`1`	`cargo install --locked uv`

但这个方式会从源码构建，需要兼容的 Rust 工具链。除非你明确需要从 Rust 生态安装，否则普通用户不必优先选 Cargo。

升级 uv

如果 uv 是通过官方独立安装脚本安装的，可以用自更新命令：

`1`	`uv self update`

官方提示说，更新 uv 会重新运行安装器，并可能修改 shell profile。如果不希望更新时修改 PATH，可以设置：

`1`	`UV_NO_MODIFY_PATH=1`

如果你是通过其他方式安装的，就应该用对应包管理器升级。比如用 pip 安装，就用：

`1`	`pip install --upgrade uv`

Homebrew、WinGet、Scoop、MacPorts 也应该走各自的升级命令。

启用 shell 自动补全

uv 支持 shell 自动补全。官方文档建议先用下面命令确认当前 shell：

`1`	`echo $SHELL`

Bash：

`1`	`echo 'eval "$(uv generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uv generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uv generate-shell-completion fish \| source' > ~/.config/fish/completions/uv.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uv generate-shell-completion powershell) | Out-String | Invoke-Expression'

如果你也经常用 uvx，可以单独启用 uvx 补全。

Bash：

`1`	`echo 'eval "$(uvx --generate-shell-completion bash)"' >> ~/.bashrc`

Zsh：

`1`	`echo 'eval "$(uvx --generate-shell-completion zsh)"' >> ~/.zshrc`

fish：

`1`	`echo 'uvx --generate-shell-completion fish \| source' > ~/.config/fish/completions/uvx.fish`

PowerShell：

if (!(Test-Path -Path $PROFILE)) {
  New-Item -ItemType File -Path $PROFILE -Force
}
Add-Content -Path $PROFILE -Value '(& uvx --generate-shell-completion powershell) | Out-String | Invoke-Expression'

配置后需要重启 shell，或者重新加载对应配置文件。

卸载 uv

如果要卸载 uv，可以先清理缓存和 uv 存储的数据：

1
2
3

uv cache clean
rm -r "$(uv python dir)"
rm -r "$(uv tool dir)"

然后删除二进制文件。

macOS / Linux：

`1`	`rm ~/.local/bin/uv ~/.local/bin/uvx`

Windows：

1
2
3

rm $HOME\.local\bin\uv.exe
rm $HOME\.local\bin\uvx.exe
rm $HOME\.local\bin\uvw.exe

官方文档还提醒：0.5.0 之前，uv 会安装到 ~/.cargo/bin。如果你从早期版本升级过，旧二进制文件可能仍然留在那里，需要手动删除。

安装后先做什么

安装完成后，建议先确认版本：

`1`	`uv --version`

然后可以从几个常见任务开始：

uv python install
uv venv
uv pip install requests
uvx ruff --version

如果你是新项目，可以进一步学习：

uv init：初始化项目；
uv add：添加依赖；
uv sync：同步环境；
uv run：在项目环境中运行命令；
uvx：临时运行 Python CLI 工具。

我的建议

个人开发机上，优先使用官方独立安装脚本，因为它最贴近 uv 官方文档，也支持 uv self update。

Windows 用户如果不想执行远程脚本，可以用 WinGet 或 Scoop。macOS 用户如果习惯所有工具都交给 Homebrew 管理，可以直接 brew install uv。

已经使用 pipx 管理 Python CLI 工具的人，可以用 pipx install uv。但不建议在具体项目虚拟环境里用 pip install uv，这样容易把工具链和项目依赖混在一起。

如果是 CI 或容器构建，优先看 Docker 和 GitHub Releases，根据镜像构建流程固定版本。

Awesome Codex Skills：给 Codex CLI 扩展技能的社区清单

Thu, 07 May 2026 20:19:15 +0800

ComposioHQ 的 awesome-codex-skills 是一个面向 Codex CLI 的社区技能清单。它的价值不在于再写一堆提示词模板，而是把一类可重复的工作流程整理成可安装、可复用、可维护的 Skill。

如果你已经把 Codex 当成日常开发搭档，这类仓库的意义会很直接：把经常重复讲的规则、命令、资料入口和操作步骤沉淀下来，下次只要调用对应技能，Codex 就能按同一套上下文继续工作。

这个仓库解决什么问题

Codex Skills 可以理解成给 Codex CLI 增加“专门工作模式”的方式。普通提示词适合临时说明一次需求，Skill 更适合长期复用。

比如你经常需要：

按固定格式生成提交信息；
查阅某类 API 文档；
运行特定项目的测试和部署命令；
按团队规范重写文章、翻译文档或整理资料；
调用外部工具完成重复性的开发辅助任务。

这些内容如果每次都重新输入，很快就会变成负担。Skill 的思路是把这些规则放进一个独立目录里，核心通常是一份 SKILL.md，必要时再配合脚本、模板、参考资料或资产文件。Codex 在被触发时读取这份说明，然后按照里面定义的流程执行。

和普通提示词有什么不同

普通提示词更像一次性指令，适合告诉模型“这次怎么做”。Skill 更像一个小型操作手册，适合告诉 Codex“以后遇到这类任务都按这个方式做”。

它的优势主要有三个：

可复用：常用工作流不用反复复制粘贴。
可审查：技能文件通常是本地 Markdown，可以直接打开、修改和版本管理。
可扩展：复杂技能可以带脚本、模板和参考资料，不只是自然语言说明。

这也是 awesome-codex-skills 这类清单的价值所在：它帮你集中发现已经写好的技能，再根据自己的工作习惯挑选、安装和改造。

如何安装和使用

仓库提供了安装脚本，也支持手动安装。典型流程是先克隆仓库，再运行安装脚本：

1
2
3

git clone https://github.com/ComposioHQ/awesome-codex-skills.git
cd awesome-codex-skills
python install.py

如果你只想试用少数技能，建议先看清每个技能目录里的 SKILL.md，确认它会读取哪些资料、运行哪些脚本、修改哪些文件，再安装到本地 Codex skills 目录。

安装之后，Codex 可以在合适的任务中自动匹配技能，也可以通过明确点名的方式调用。对长期使用者来说，更实用的方式往往是：先安装一个社区技能，再把里面的说明改成自己的项目规范。

适合关注哪些技能

这类仓库里最值得优先看的，不一定是名字最酷的技能，而是能稳定减少重复劳动的技能。

我会优先关注几类：

开发流程类：代码审查、测试、提交、发布、依赖检查。
文档处理类：重写、翻译、摘要、结构化整理。
工具集成类：把 Codex 和外部服务、API、命令行工具连接起来。
项目规范类：把团队约定、目录结构、命名规则、部署步骤写进固定流程。

如果一个技能只是把一句提示词包装了一下，价值有限；如果它能把“查资料、判断、执行、验证、输出”串成稳定流程，就值得长期保留。

使用时要注意什么

社区技能虽然方便，但不要把它当成黑盒直接运行。尤其是带脚本的 Skill，安装前最好先检查三件事：

SKILL.md 里要求 Codex 做什么；
是否包含会访问网络、读写文件或调用外部服务的脚本；
默认路径、命令和权限是否适合你的本地环境。

Skill 本质上是在扩大 Codex 的行动边界。写得好，它会让 Codex 更像熟悉你项目的同事；写得粗糙，它也可能把不适合你的规则带进工作流。所以最理想的用法不是“装很多”，而是“装少数、改到顺手、长期维护”。

我的判断

awesome-codex-skills 值得收藏，尤其适合已经开始用 Codex CLI 做真实开发、文档或自动化任务的人。它不是官方能力本身，而是一个社区整理的技能入口：你可以从里面找灵感，也可以把常用流程改造成自己的本地技能库。

对重度用户来说，Codex Skills 的重点不是让 AI 多记一点东西，而是让 AI 在同类任务中少走弯路。把规则写成 Skill，等于把一次次临时沟通沉淀成可复用的工作基础设施。

Warp 开源：从终端到 Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp 是 Warp 的开源客户端仓库。Warp 官方现在把它定位为一个“从终端生长出来的 agentic development environment”，也就是以终端为基础，但把 AI coding agent、代码库索引、任务管理和开发工作流放进同一个环境里。

这不是一个普通的终端模拟器开源仓库。它更像是在回答一个问题：当 Claude Code、Codex、Gemini CLI 这类 agent 越来越常见时，终端本身要不要变成一个能调度、观察和管理 agent 的开发环境？

Warp 的答案是：要。

这个仓库现在是什么状态

截至 2026 年 5 月 7 日查看，warpdotdev/warp 是公开仓库，GitHub 页面显示约 56k stars、4.1k forks。仓库 README 说明，Warp 的客户端代码已经开源，并欢迎社区贡献。

仓库的主语言是 Rust。GitHub 语言统计里，Rust 占比超过 98%。这和 Warp 的定位一致：它不是网页壳，而是一个跨平台的原生开发工具。

README 中有几个信息点很重要：

Warp 是一个 agentic development environment, born out of the terminal。
它可以使用内置 coding agent，也可以接入 Claude Code、Codex、Gemini CLI 等外部 CLI agent。
OpenAI 是新开源 Warp 仓库的 founding sponsor。
仓库中的 agentic management workflows 由 GPT models 驱动。
Warp UI 框架相关 crate 使用 MIT license，其余代码使用 AGPL v3。

这些信息说明，Warp 开源不是单纯把一个终端放出来，而是把它作为“agent 工作流实验场”来运营。

Warp 不只是终端

传统终端主要解决三个问题：

启动 shell。
执行命令。
显示输出。

Warp 早期的差异化，是让终端更现代：命令块、补全、历史、协作、UI 化交互、跨平台体验。现在它的重心继续往前走，开始围绕 AI agent 组织开发流程。

从 README 看，Warp 不再只强调“更好用的 terminal”，而是强调：

内置 coding agent。
支持外部 CLI agent。
issue triage。
spec 编写。
PR review。
contributor coordination。
可观察的 agent sessions。

也就是说，Warp 想把终端从“你输入命令的地方”，变成“你和多个 agent 一起工作的地方”。

Oz 和开源项目管理

README 里多次提到 Oz。

Warp 的贡献概览页面可以看到成千上万个 Oz agents 在做 issue triage、写 specs、实现改动、review PR。这个设计很有意思，因为它把 AI agent 从“帮个人写代码”扩展到了“帮开源项目管理协作”。

传统开源项目最难的不是写代码，而是维护：

issue 太多，没人分类。
bug 和 feature request 混在一起。
新贡献者不知道哪些任务能做。
PR review 压力大。
维护者很难持续跟进社区讨论。

Warp 的思路是，让 agent 先承担一部分项目管理和协作工作。README 中还提到 Oz for OSS，这是面向维护者的合作计划，用于把类似 agentic open-source management workflows 带到其他开源仓库。

这说明 Warp 的野心不只是终端产品本身，也包括探索 AI 时代开源维护的新模式。

仓库结构和技术栈

从仓库结构看，Warp 是一个大型 Rust 项目。

根目录里能看到：

app/：主应用相关代码。
crates/：核心 Rust crates。
assets/：资源文件。
command-signatures-v2/：命令签名相关内容。
docker/、script/、resources/、specs/ 等工程目录。
.claude/、.warp/、.agents/skills 等 agent 相关配置。

WARP.md 里给出了更详细的工程说明。它提到 Warp 是 Rust-based terminal emulator，并使用一个自研 UI 框架 WarpUI。

主要模块可以粗略理解为：

app/：终端模拟、shell 管理、AI 集成、Drive、认证、设置、workspace 和 session。
crates/warp_core/：核心工具和平台抽象。
crates/editor/：文本编辑功能。
crates/warpui/ 和 crates/warpui_core/：自研 UI 框架。
crates/ipc/：进程间通信。
crates/graphql/：GraphQL 客户端和 schema。

WARP.md 还提到几个架构特点：

Entity-Handle system。
模块化 workspace 结构。
macOS、Windows、Linux 跨平台，以及 WASM target。
AI integration，包含 Agent Mode、上下文感知和代码库索引。
Warp Drive 云同步。

这说明 Warp 的复杂度已经接近一个完整 IDE，而不是传统意义上的轻量 terminal。

本地构建方式

README 给出的本地构建方式很简洁：

1
2
3

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

其中：

./script/bootstrap：执行平台相关初始化。
./script/run：构建并运行 Warp。
./script/presubmit：执行格式化、clippy 和测试等提交前检查。

WARP.md 里还列出了更细的命令：

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

如果要给 Warp 提交代码，./script/presubmit 基本是必须跑的。

贡献流程

Warp 的贡献流程不是简单“发 PR 就行”。

README 描述了一个从 issue 到 PR 的轻量流程：

先搜索已有 issue。
没有重复再提交 bug 或 feature request。
维护者会 review issue，并可能打上 readiness label。
ready-to-spec 表示设计可以被贡献者展开成 spec。
ready-to-implement 表示设计已相对明确，可以开始写代码 PR。
贡献者可以认领带标签的 issue。

这个流程适合大型开源项目。它把“想法”“设计”“实现”拆开，减少贡献者一上来就写错方向的风险。

对 AI agent 来说，这也很适合。agent 可以先整理 issue、写 spec、补测试，再进入实现。Warp 自己也在用这种方式展示 agentic project management。

许可：MIT + AGPL v3

Warp 采用双许可结构。

README 说明：

Warp UI framework，也就是 warpui_core 和 warpui crates，使用 MIT license。
仓库其余代码使用 AGPL v3。

这点很重要。AGPL v3 对网络服务和分发有更强的开源要求。如果你只是学习、研究、贡献代码，问题不大；但如果想把 Warp 代码用于商业产品或闭源衍生项目，就必须认真读 license，必要时咨询法律意见。

简单说，Warp 是开源了，但不是“随便拿去闭源商用”的宽松许可。

值得关注的地方

第一，Warp 把终端、agent、项目管理放在一起。

很多 AI coding 工具仍然是 CLI 或编辑器插件。Warp 试图从终端入口出发，把 agent 任务、代码执行、命令输出、PR 工作流和团队协作整合起来。

第二，Warp 的开源方式很适合观察 agent 工作流。

它不只是发布代码，还把贡献概览、agent session、issue triage 和 spec 流程公开出来。对于想研究 AI 如何参与开源协作的人，这个仓库本身就是样本。

第三，Warp 是一个复杂 Rust 桌面应用。

如果你想学习 Rust GUI、终端模拟器、跨平台应用、GraphQL 客户端、云同步和 AI 集成，Warp 仓库有不少可看的结构。但它不是小项目，新贡献者需要先读文档和 issue 流程。

第四，Warp 支持“自带 agent”和“bring your own CLI agent”两条线。

这点很现实。开发者不会只用一个 agent。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 等工具会长期共存。Warp 如果能成为它们的工作台，就比单一终端更有价值。

适合谁关注

如果你是普通终端用户，关注 Warp 的意义在于：终端可能正在从命令行工具变成 AI 工作台。

如果你是 AI coding agent 重度用户，Warp 值得关注，因为它试图管理多个 agent，而不是只做一个聊天入口。

如果你是开源维护者，可以关注 Oz for OSS 这条线。它试图用 agent 做 issue triage、PR review、社区协作和贡献者引导。

如果你是 Rust 开发者，Warp 是一个大型真实桌面应用样本，可以研究它如何组织 UI、终端、云同步、AI 集成和跨平台代码。

如果你只是想找一个能马上替代传统终端的工具，建议先下载正式版使用，再决定是否研究源码。直接从源码构建更适合贡献者和深度玩家。

简短判断

Warp 开源的重点，不只是“一个现代终端开源了”。

更准确地说，Warp 正在把终端升级成 agentic development environment：终端负责连接 shell、代码库、命令执行、agent、issue、PR 和协作流程。

在 AI coding agent 继续增长的背景下，开发环境的入口可能会发生变化。过去是 IDE 统治开发体验，终端负责命令执行；现在终端可能反过来成为 agent 协作的中心。Warp 这个仓库，正是在探索这种可能性。

Codex App 保姆级上手：安装、沙盒、并行任务、Skills 与 MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App 可以理解成一个面向 AI 编程的任务工作台。它不是传统 IDE，也不是单纯聊天窗口，而是把多任务、项目管理、沙盒权限、Git、云端运行、插件、Skills、MCP 和自动化集中到一个界面里。

如果你已经在用 Codex CLI、Claude Code、Cursor 或其他 coding agent，Codex App 最值得关注的地方，是它把“多个 agent 并行干活”做成了一个更清晰的桌面工作流。

Codex App 适合做什么

Codex App 的核心价值不是让 AI 回答问题，而是让 AI 在项目目录里持续执行任务：

修改代码、运行命令、启动开发服务。
管理多个项目和多个任务。
在本地或云端执行长任务。
调用插件、Skills 和 MCP 扩展能力。
通过 Git、worktree 和 PR 管理改动。

OpenAI 官方也把 Codex App 定位成一个用于管理多个 coding agent 的界面。它适合需要同时推进多个代码任务的人，尤其适合前端页面、脚本工具、小型应用、文档整理和自动化工作流。

安装前准备

使用 Codex App 前，建议先准备好三个基础工具：

Git
Node.js
VS Code 或你常用的 IDE

Codex App 支持 macOS 和 Windows。安装后使用 ChatGPT 账号登录，首次进入时可以选择主要使用场景，例如编程或日常工作。Codex 会根据选择预装一部分插件和 Skills，后续也可以在设置和插件市场里调整。

Windows 和 macOS 的主要功能大体一致，但部分电脑自动化能力可能依赖具体平台和插件支持，实际以你当前版本显示为准。

界面结构：项目、任务和对话

Codex App 是典型的三栏布局：

左侧：项目、任务、历史对话、插件和自动化入口。
中间：当前对话窗口。
右侧：文件、浏览器、终端、运行结果等多功能区域。

一个项目通常对应一个本地文件夹。你可以在同一个项目里开多个对话，也可以同时打开多个项目，让不同 agent 并行执行任务。

任务列表会显示不同状态：

正在运行：agent 仍在执行。
等待批准：需要你确认权限、联网、安装依赖或执行高风险操作。
已完成：任务已经结束，可以查看结果或继续追问。

这比在多个终端窗口里来回切换更直观，也更适合同时管理多个 AI 任务。

沙盒与权限控制

Codex App 的权限体系围绕沙盒展开。默认情况下，当前项目文件夹会成为 agent 的主要工作范围。

常见权限边界包括：

可以读取和修改项目目录内的文件。
默认不能随意修改项目外文件。
默认会限制联网或高风险命令。
需要越权时，会向用户申请批准。

比较实用的模式是“自动审查”：低风险操作由系统自动放行，高风险操作再交给用户确认。这样既能减少频繁弹窗，又能避免 agent 在不知情的情况下执行危险操作。

“完全访问”要谨慎开启。它适合你明确知道 agent 要做什么，并且项目已经有 Git 备份、重要文件也有额外备份的场景。日常使用不建议长期保持完全访问。

上下文、模型和额度

Codex App 会显示当前对话的上下文使用情况。对话越长，历史内容越多，模型需要处理的上下文也越大。

实用建议是：

一个任务完成后，优先开新对话。
长对话可以手动压缩，但不要把压缩当成万能记忆。
复杂任务先写清楚目标、边界和验收标准。
不要把大量无关日志、报错和文件一次性塞进对话。

模型选择上，可以根据任务复杂度调整思考强度。简单修改、文案整理、重复任务不一定需要最高规格模型；架构迁移、疑难 bug、跨文件重构则更适合使用更强模型。

如果界面里有快速模式，也要注意它通常会带来更高的额度消耗。赶时间时可以开，日常不必默认开启。

图片生成与多模态输入

Codex App 可以接收图片和文件作为上下文，也可以在合适场景中调用图像生成能力。

这对前端和内容类项目很有用。例如你可以让 Codex：

根据截图修正页面样式。
替换网页中的不合适配图。
生成产品图、轮播图或页面素材。
根据 UI 截图指出需要修改的位置。

更高效的用法是：不要只说“改好看一点”，而是结合截图指出具体问题，例如“这个卡片间距太大”“这里的图和服务场景不匹配”“把地图区域做得更清楚”。

Steer：任务执行中及时纠偏

Steer 可以理解成“执行中接管方向”。当 agent 已经开始执行，但你发现它理解错了方向，不应该等它全部跑完再改。

这时可以使用引导功能，把新的指令插入当前执行流程，让 Codex 及时修正路线。

适合使用 Steer 的场景包括：

agent 误解了需求。
生成的页面风格明显不对。
正在执行的方案成本太高。
你临时补充了关键约束。

一般建议保留默认排队行为，只在确实需要干预时手动使用 Steer。这样既不会打乱正常任务，也能在关键时刻把方向拉回来。

计划模式和内置浏览器

复杂任务建议先开计划模式。计划模式下，Codex 不会马上改代码，而是先输出方案，必要时还会用卡片形式追问关键选择。

适合开计划模式的任务：

框架迁移，例如从普通 React 项目迁到 Next.js。
大范围重构。
涉及数据库、认证、部署的功能。
你还没想清楚技术路线的需求。

Codex App 的右侧区域可以打开内置浏览器，用来预览本地开发服务。你可以在页面上做批注，让 Codex 按具体 UI 位置修改问题。这种“看页面、点位置、让 AI 改”的流程，比纯文字描述更适合前端调试。

Git、IDE 和代码回滚

Codex App 不是完整 IDE。它可以查看代码、批注代码，但真正的手写编辑仍然更适合交给 VS Code、Cursor、Windsurf 等 IDE。

建议每个 Codex 项目都尽早初始化 Git：

让 Codex 创建或检查 .gitignore。
在完成一个可用状态后提交一次。
每次大改前确保有干净提交点。
不满意时用 Git 回滚代码。

如果只回滚对话历史，代码不会自动跟着回滚。比较稳的做法是：对话层面回到合适节点，代码层面用 Git commit hash 回到对应状态。

Worktree：并行开发多个方向

git worktree 是 Codex App 里非常适合并行 agent 的能力。

它的本质是：基于同一个仓库创建多个独立工作目录，每个目录对应不同分支。这样你可以让不同 agent 在不同文件夹里同时开发，不互相覆盖。

典型用法：

一个 worktree 优化客户评价组件。
一个 worktree 调整门店信息和地图布局。
两个任务完成后分别合并回主干。
合并完成后删除临时 worktree。

这比在同一个目录里让多个 agent 同时改代码稳得多。遇到冲突时，也可以按正常 Git 流程 review 和合并。

云端运行环境

Codex 不只能在本机工作，也可以把任务委托到云端环境执行。

云端运行适合这些场景：

出门在外，手边只有手机。
希望 agent 在后台跑长任务。
代码已经同步到 GitHub，需要让 Codex 基于远端仓库修改。
希望通过 PR 形式审查和合并改动。

典型流程是：先把本地代码推到 GitHub，再让 Codex 在云端环境中拉取仓库、执行任务、生成改动，最后以 PR 或 diff 的方式交给你审核。

本地继续开发时，要记得把远端最新改动同步回来。

记忆系统：写好 AGENTS.md

新对话默认没有完整历史记忆。项目一复杂，如果每次都重新解释背景，会很浪费。

最通用的做法，是在项目根目录维护 AGENTS.md。这个文件可以记录：

项目目标和主要技术栈。
常用命令。
目录结构说明。
代码风格和命名约定。
禁止事项，例如不要批量删除文件。
测试、构建和部署规则。

你也可以让 Codex 先通读项目，再生成一版 AGENTS.md，然后人工审一遍。复杂项目里，这个文件非常值得维护。

全局规则也要谨慎。适合写入所有项目都通用的安全约束，例如“不要递归删除目录”“执行破坏性操作前必须确认”。不要把某个项目的细节写进全局规则，否则会污染其他项目。

插件和自动化

插件用于把外部服务接入 Codex，例如 GitHub、Gmail、Google Drive、数据库、部署平台等。

插件的价值在于减少复制粘贴。比如你可以让 Codex：

查看某个 GitHub 仓库的 star 趋势。
整理邮件内容并发给自己。
定期执行某个检查任务。
把结果写成摘要。

自动化则适合重复任务。例如每周五下午检查一次仓库数据，并发送邮件报告。简单自动化任务通常不需要最高规格模型，选择较轻量的模型即可。

Skills：把工作流变成可复用能力

Skills 是 Codex 的“专业说明书”。它不是单次提示词，而是把某类任务的流程、规范、脚本和注意事项沉淀下来，让 Codex 后续稳定复用。

常见来源有三类：

官方 Skills。
第三方 Skills。
自己编写的 Skills。

适合做成 Skill 的工作：

把字幕整理成图文笔记。
按公司规范写周报。
批量处理图片或文档。
固定格式的代码审查。
特定框架的项目初始化。

如果某个提示词你已经复制粘贴了很多次，就值得考虑把它做成 Skill。

MCP：接入外部工具和数据库

MCP 可以理解成给大模型使用的标准化工具协议。通过 MCP，Codex 可以调用外部服务完成更具体的任务。

例如接入 Supabase 后，可以让 Codex：

创建数据表。
读取数据库结构。
修改后端接口。
把前端表单提交到数据库。
根据数据库状态调试问题。

这类能力很强，但也要注意权限边界。数据库、生产环境、部署平台、邮件账号都属于高风险资源。第一次接入时，最好使用测试项目和低权限账号。

部署插件

部署平台插件可以让 Codex 直接完成构建和发布，例如把前端项目部署到 Netlify 一类平台。

这类插件适合小型网站、原型页面、内部工具和展示项目。实际使用时建议注意：

部署前先跑本地构建。
环境变量不要直接写进代码。
发布后检查页面是否能正常访问。
生产项目要保留人工 review。

AI 可以帮你打通发布流程，但发布权限仍然要谨慎管理。

电脑自动化

在支持的平台和插件环境里，Codex 还可以操作浏览器或桌面应用，完成更接近 RPA 的任务。

例如：

打开聊天软件并准备一条消息。
浏览项目看板，汇总任务状态。
生成英文简报。
在你确认后发送给指定对象。
把这套流程做成定时自动化。

这类功能很有想象力，但也最需要安全边界。凡是涉及发消息、发邮件、提交表单、付款、删除数据的操作，都应该保留人工确认。

使用建议

Codex App 的正确打开方式，不是让它一次性全自动接管一切，而是把任务拆清楚，让它在受控环境里高效执行。

推荐习惯：

每个项目先初始化 Git。
复杂任务先开计划模式。
并行任务优先用 worktree。
项目规则写进 AGENTS.md。
高风险操作保留人工确认。
重复流程沉淀成 Skill 或自动化。
插件和 MCP 先在测试环境验证。

参考资料

小结

Codex App 的重点不是“多一个 AI 聊天窗口”，而是把 AI 编程变成一个可管理的工作台：本地项目、云端任务、Git、worktree、插件、Skills、MCP 和自动化都能串起来。

真正用好它的关键，是在“放权”和“控制”之间找到平衡。小任务可以大胆交给 Codex，复杂任务先让它计划，高风险动作必须确认。这样它才会从一个会写代码的助手，变成可以长期协作的工程工具。

如何在 Cline 中调用 DeepSeek V4 Pro

Fri, 01 May 2026 20:59:06 +0800

Cline 本身已经支持 OpenAI Compatible Provider。 DeepSeek API 也兼容 OpenAI SDK 风格的调用方式，所以把 deepseek-v4-pro 接到 Cline 里并不复杂：选 OpenAI Compatible，填 DeepSeek 的 Base URL、API Key 和模型名即可。

下面按 VS Code 插件界面和 Cline CLI 两种方式整理。

准备 DeepSeek API Key

先到 DeepSeek 开放平台创建 API Key。

需要准备三个值：

项目	填写内容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek 官方文档说明，V4 系列使用现有 OpenAI 兼容接口，base_url 保持为 https://api.deepseek.com，调用时把 model 设置为 deepseek-v4-pro 或 deepseek-v4-flash。

在 Cline 插件里配置

如果你用的是 VS Code 里的 Cline 插件，可以按这个路径配置：

打开 VS Code 侧边栏里的 Cline。
进入 Cline 的设置或模型配置页面。
Provider 选择 OpenAI Compatible。
API Key 填入 DeepSeek API Key。
Base URL 填：

`1`	`https://api.deepseek.com`

Model ID 填：

`1`	`deepseek-v4-pro`

保存配置，回到 Cline 对话框测试一次简单任务。

可以先让 Cline 做一个低风险测试：

`1`	`请读取当前项目目录结构，并总结这个项目是什么类型，不要修改任何文件。`

如果能正常读取和回答，说明模型链路已经通了。

在 Cline CLI 中配置

如果你使用 Cline CLI，可以用 cline provider configure openai-compatible 进入交互式配置。

示例：

`1`	`cline provider configure openai-compatible`

交互时填写：

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

配置完成后，可以用一个只读任务测试：

`1`	`cline "Summarize this repository structure without changing files."`

如果你希望先降低成本，也可以把 Model ID 临时改成：

`1`	`deepseek-v4-flash`

等遇到复杂规划、事实核查、多工具协作或高风险代码修改时，再切回 deepseek-v4-pro。

上下文长度怎么填

DeepSeek V4 Pro 和 Flash 都支持很长上下文。在 Cline 里如果需要手动填写 context window，可以按 DeepSeek 官方模型页给出的 1M 上下文来理解。

实际使用时不建议一开始就把所有文件都塞进上下文。 Cline 会按任务读取文件，通常更好的方式是：

先让它看目录结构；
再让它定位相关文件；
最后只围绕目标文件执行修改。

这样更省 Token，也更容易保持任务边界清晰。

常见问题

1. 提示模型不存在

先检查 Model ID 是否写成：

`1`	`deepseek-v4-pro`

不要写成 DeepSeek V4 Pro、deepseek-v4 或其他显示名称。

2. 提示 401 或认证失败

检查 API Key：

是否复制完整；
是否带了多余空格；
是否填到了 Cline 当前正在使用的 provider 配置里；
DeepSeek 账户是否有可用额度。

3. 提示连接失败

检查 Base URL：

`1`	`https://api.deepseek.com`

不要在末尾额外拼 /v1/chat/completions。 Cline 的 OpenAI Compatible Provider 会自己按兼容接口组织请求。

4. Cline 调用很贵怎么办

可以先把日常任务切到 deepseek-v4-flash，只在复杂任务里使用 deepseek-v4-pro。

另外，尽量把任务描述写清楚：

`1`	`只修改登录页相关文件，不要重构无关模块。先给出计划，确认后再改代码。`

Agent 任务最怕边界不清。边界越清楚，读文件越少，工具调用越少，成本也越可控。

5. 报错 reasoning_content must be passed back

如果你看到类似错误：

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

这通常不是 Key、额度或 Base URL 的问题，而是 DeepSeek V4 Pro 的 thinking mode 和当前客户端的多轮工具调用记录没有对齐。

DeepSeek 官方文档说明：

thinking mode 默认是 enabled；
thinking mode 下会返回 reasoning_content；
如果某一轮发生了 tool call，后续请求必须把该轮 assistant message 里的 reasoning_content 一起传回 API；
如果客户端没有正确回传，就会返回 400。

Cline 通过 OpenAI Compatible Provider 接入时，如果当前版本没有完整保留并回传 DeepSeek 的 reasoning_content，就可能在第二轮或工具调用后触发这个错误。

可尝试的处理顺序：

先升级 Cline 到最新版；
确认使用的是 OpenAI Compatible，而不是普通 OpenAI provider；
如果 Cline 支持自定义 request body，尝试关闭 thinking mode：

{
  "thinking": {
    "type": "disabled"
  }
}

如果 Cline 不支持额外 body 参数，暂时改用不触发该问题的模型或服务中转；
等 Cline 适配 DeepSeek V4 的 reasoning_content 回传后，再切回 deepseek-v4-pro。

需要注意：关闭 thinking mode 会牺牲一部分复杂推理能力，但可以绕开客户端没有回传 reasoning_content 的兼容性问题。

一个可直接复制的配置清单

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

如果要低成本模式：

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

小结

在 Cline 中调用 DeepSeek V4 Pro 的关键只有三步：

Provider 选择 OpenAI Compatible；
Base URL 填 https://api.deepseek.com；
Model ID 填 deepseek-v4-pro。

配置完成后，建议先用只读任务测试，再逐步交给它执行真实代码修改。如果你经常跑 Agent 任务，可以把 Flash 和 Pro 分开用：Flash 负责高频轻量任务，Pro 负责复杂判断和兜底。

参考来源：

mattpocock/skills：给 AI 编程 Agent 准备的实用技能集合

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills 是 Matt Pocock 公开的一组 AI 编程 agent skills。

它不是一个完整的应用，也不是一个新的聊天客户端，而是一套可以给 AI 编程助手使用的工作技能。它的思路很实用：把 AI 编程里经常出现的问题拆成一个个小技能，让 Agent 在合适的任务里调用，而不是每次都靠一大段提示词硬撑。

如果你经常使用 Claude Code、Codex、Cursor 或类似的 AI 编程工具，这类 skills 很值得关注。因为真正影响 AI 编程体验的，往往不是“模型会不会写代码”，而是它能不能按你的工作方式推进任务。

它解决什么问题

AI 编程助手很强，但也很容易出问题。

常见情况包括：

还没理解需求就开始改代码
一次性改太多文件
输出解释很多，真正有用的行动很少
遇到报错后盲目尝试
没有及时运行测试或检查
忽略项目里已有模式
为了完成任务引入不必要的抽象
写完代码后没有真正 review 风险

这些问题不一定是模型能力不够，而是工作流没有被约束好。

mattpocock/skills 的价值在于，把这些常见失败模式拆成可以复用的操作方式，让 Agent 在不同场景下更像一个有经验的工程协作者。

Skills 是什么

在 AI Agent 语境里，skill 可以理解成一段可复用的任务说明、工作方法或专业流程。

它不一定是代码插件，也不一定必须调用外部服务。很多时候，一个 skill 就是一套明确规则：

什么时候使用
先做什么
不要做什么
需要输出什么
怎么判断任务完成

这和普通提示词模板有点像，但粒度更接近“任务能力”。

普通提示词模板通常是用户每次临时复制粘贴；skills 则更适合作为 agent 工具箱的一部分，让 Agent 根据任务选择合适流程。

为什么要小而可组合

README 中强调这些 skills 是小而可组合的。

这个方向很重要。

如果一个 skill 试图包办所有事情，它很快就会变成新的大提示词：又长、又模糊、又难维护。小技能的优势是边界清楚。

比如一个 skill 专门负责：

先做计划
修复 TypeScript 错误
运行测试并根据结果修复
做代码 review
总结项目约定
改进提示词
清理无用抽象

这些技能可以按任务组合使用。简单任务只用一个技能，复杂任务再串起来。

这更接近真实工程工作：你不会用同一套流程处理所有问题，而是根据问题选择工具。

保留工程师控制权

这个仓库的一个重要取向，是让工程师仍然掌握控制权。

AI 编程很容易滑向两种极端：

第一种是完全手动。AI 只是帮你写几行代码，所有上下文、计划、验证都靠你自己盯。

第二种是完全放手。你把任务丢给 Agent，让它自己大改一通，最后再面对一堆难以审查的 diff。

skills 的作用是在中间找一个更稳的位置。

它让 AI 承担更多重复流程，但仍然用规则限制它：

先理解任务再动手
先阅读相关文件再改
修改范围要可控
出现不确定时要回报
改完要验证
不能为了炫技重构无关代码

这不是削弱 AI，而是让 AI 的行动更容易被人类审查和接管。

对齐问题

AI 编程失败的第一类问题通常是对齐失败。

用户想要的是一个很具体的改动，但 Agent 可能理解成一个更大的重构；用户只想修 Bug，它却顺手改了样式；用户希望遵守现有架构，它却引入新模式。

Skills 可以在任务开始阶段帮助 Agent 做几件事：

重述目标
找出影响范围
识别已有实现模式
给出计划
明确不做哪些事情

这一步很像工程师开工前的自检。

如果 Agent 连任务边界都没说清楚，就直接写代码，后面很容易越走越偏。

反馈循环问题

AI 写代码不能只靠一次生成。

真实开发里，反馈循环很重要：

改一小步
跑测试或类型检查
看错误
修正
再验证

很多 Agent 失败，是因为它跳过了中间反馈。它一次性改很多内容，然后凭感觉总结“应该可以工作”。

Skills 可以把反馈循环显式写进流程里。比如要求 Agent：

修改后运行相关检查
如果检查失败，先读错误信息
不要盲目改无关文件
每轮修复后重新验证
最后报告验证结果

这会让 AI 编程更像真实调试，而不是一次性作文。

架构控制问题

AI 很擅长生成抽象，也很擅长过度生成抽象。

为了完成一个小需求，它可能新建服务层、工具函数、配置对象、类型包装、适配器，最后让代码比需求本身复杂得多。

这类问题在大型项目里尤其危险。因为 AI 生成的抽象看起来很“专业”，但它可能不符合项目已有风格，也可能增加维护成本。

好的 skills 会提醒 Agent：

优先沿用现有模式
不引入没有必要的新抽象
不顺手重构无关区域
修改要和任务规模匹配
先理解代码再设计结构

这能减少“看起来很工程化，实际上更难维护”的输出。

Review 技能为什么重要

写代码和 review 代码是两种不同状态。

Agent 在写代码时，通常会倾向于证明自己的实现成立。它会解释为什么这样改可以工作，但不一定主动找风险。

Review skill 的意义，是让 Agent 切换角色：

找潜在 Bug
找行为回归
找遗漏测试
找边界条件
找复杂度上升
找和现有约定不一致的地方

这对 AI 编程很重要。因为 AI 生成代码的速度很快，如果没有 review，用户很容易被大量 diff 淹没。

一个好的 review 输出应该优先列问题，而不是先夸实现。它要帮助工程师判断这次改动能不能合并。

和普通 rules 文件有什么区别

很多 AI 编程工具都支持 rules、instructions 或 memory。

这些文件通常记录长期规则，比如：

项目技术栈
命名规范
测试命令
不要修改哪些目录
回答风格偏好

Skills 更偏任务流程。

rules 告诉 Agent “长期应该怎么做”，skills 告诉 Agent “面对某类任务时应该怎么执行”。

两者最好一起用。

比如 rules 里写项目用 pnpm test，review skill 里要求改完后检查测试覆盖。这样 Agent 不仅知道命令，也知道什么时候该用。

适合什么场景

mattpocock/skills 这类仓库适合这些场景：

高频使用 AI 编程工具
经常让 Agent 处理真实代码库
想减少 AI 越界修改
想让 Agent 更主动地验证结果
想把自己的工程习惯沉淀成技能
想学习别人如何设计 agent workflows
想把一堆临时提示词整理成可维护的技能集合

如果你只是偶尔让 AI 写一个小函数，可能不需要专门维护 skills。

但如果你已经把 AI 当成长期开发伙伴，skills 会逐渐变得重要。它们相当于给 Agent 配了一套可复用的工作方法。

怎么借鉴这个仓库

即使你不直接使用其中的每个 skill，也可以从这个仓库学到几件事。

第一，把失败模式写下来。

不要只在 AI 出错时临时抱怨。把它经常出错的模式整理成规则，下一次让 skill 提前防住。

第二，技能要短。

一个 skill 最好解决一个明确问题。越短越容易被正确调用，也越容易维护。

第三，输出格式要清楚。

如果你希望 Agent 先列计划、再执行、最后总结验证结果，就把输出结构写清楚。模糊要求通常会得到模糊结果。

第四，保留人工接管点。

好的 skill 不应该让 AI 独自跑到很远。遇到不确定、影响范围扩大、测试失败或需要产品判断时，应该让它停下来说明情况。

使用时要注意

第一，不要把所有事情都技能化。

太多 skills 会让系统变复杂，Agent 也可能不知道该选哪个。先从最高频、最痛的几个场景开始。

第二，skills 需要迭代。

第一次写出来的 skill 不一定好。看 AI 实际执行效果，再逐步删减、补充和改写。

第三，不要让 skill 替代工程判断。

Skill 可以改善流程，但不能保证实现正确。测试、review、构建检查和人类判断仍然重要。

第四，注意不同 Agent 的差异。

Claude Code、Codex、Cursor、Copilot 对 instructions、skills、rules 的支持方式不同。同一套思想可以复用，但具体格式要按工具调整。

参考

mattpocock/skills

最后一句

mattpocock/skills 值得关注的地方，不是里面某一个神奇提示词，而是它展示了一种更实用的 AI 编程思路：把工程经验拆成小技能，再让 Agent 按场景组合使用。

当 AI 编程从偶尔辅助变成日常工作流，skills 会成为约束 Agent、保留工程师控制权和提升反馈质量的重要工具。

Compound Engineering Plugin：把 AI 编程变成计划、执行、评审的工程循环

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin 是 Every Inc 开源的一个 AI 编程工作流插件。

它关注的不是“让 AI 更快写一段代码”，而是把 AI 编程放进一个更像工程团队的循环里：先计划，再实现，再评审，再把经验沉淀下来。对经常使用 Claude Code、Codex、Cursor、Copilot 这类工具的人来说，这类插件解决的是工作流问题，而不只是提示词问题。

AI 编程工具越来越强，但真实项目里最难的往往不是生成代码，而是让它持续按项目规则做事、理解任务边界、避免重复犯错，并在多轮迭代中积累上下文。

它解决什么问题

很多人使用 AI 编程助手时，流程大概是这样：

直接描述需求
让 AI 改代码
看结果是否能跑
出错后继续补充说明
下次新任务再从头解释一遍

这种方式能完成小任务，但在复杂项目里很容易遇到问题：

需求没有先拆清楚，AI 直接开始改
改完代码后缺少系统性 review
项目规范靠用户反复提醒
同类错误下次仍然出现
多个 Agent 工具之间缺少统一工作方法
经验没有沉淀成可复用规则

Compound Engineering Plugin 想解决的就是这类问题。它把 AI 编程拆成多个阶段，让 Agent 不只是执行命令，而是参与一个更完整的工程流程。

什么是 Compound Engineering

从项目 README 的描述看，Compound Engineering 可以理解为一种 AI 辅助软件开发方法。

它强调一个循环：

计划：先理解目标、拆分任务、确认路径
执行：按计划修改代码、运行命令、处理问题
评审：检查实现质量、风险和测试覆盖
学习：把经验沉淀成后续可复用的规则

这个循环很像真实工程团队的工作方式。

一个靠谱的工程师不会拿到需求就立刻乱改，也不会改完就直接交差。他会先判断影响范围，再动手实现，之后检查风险和测试结果，最后把踩过的坑记录下来。AI Agent 也需要类似约束。

为什么需要插件

提示词可以告诉 AI “请先计划再执行”，但提示词本身不一定稳定。

一旦会话变长、上下文变复杂，模型可能会跳过计划、忽略规则，或者为了完成任务而过度自信。插件的价值在于把流程固化下来，让不同 Agent 环境都能遵循类似方法。

这类插件通常会把工作流拆成命令、规则、模板或子流程。用户不需要每次手写完整提示词，而是通过固定入口触发某个阶段。

比如：

先让 Agent 生成计划
再按计划逐步实现
改完后触发 review
发现问题后返回修正
把值得保留的经验写入记忆或规则

这会让 AI 编程更像“受控协作”，而不是一次性聊天。

支持哪些 Agent 环境

README 中提到，项目支持多个 AI 编程环境，包括：

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

这点值得注意。

很多工作流工具只绑定一个客户端，换工具后规则就不能复用。Compound Engineering Plugin 更像一套跨 Agent 的工程方法，把类似的计划、执行、评审流程带到不同工具里。

如果你同时使用多个 AI 编程助手，这类统一工作流会更有价值。不同工具能力不同，但项目规范、评审习惯和任务拆解方法应该尽量一致。

计划阶段有什么用

计划阶段的价值，是防止 AI 过早动手。

复杂任务里，真正重要的问题通常是：

要改哪些文件
哪些模块可能受影响
现有模式是什么
有没有测试
风险点在哪里
是否需要先阅读文档
能不能拆成更小步骤

如果 Agent 没有先想清楚这些问题，就直接开始写代码，很容易做出看似完成、实际偏离项目结构的实现。

计划并不一定要很长。好的计划应该短、具体、可执行。它的目的不是制造文档，而是让后续实现有边界。

执行阶段要避免什么

AI 执行代码任务时，最容易出现几类问题：

顺手重构无关代码
覆盖用户已有修改
只改 happy path
忽略错误处理
不按项目已有风格写
没有运行必要验证
遇到报错后盲目尝试

工作流插件无法保证这些问题完全消失，但可以通过规则和阶段约束减少发生概率。

比如，执行阶段可以要求 Agent 按计划逐步推进；遇到超出计划范围的发现时，先说明风险；修改共享模块时，补充测试或至少运行相关验证。

这种约束对大型代码库尤其重要。AI 写代码越快，越需要流程来限制它的惯性。

评审阶段为什么重要

很多 AI 编程失败，不是因为代码完全不能运行，而是因为细节有问题：

边界条件没处理
状态更新不一致
API 合约被悄悄改了
测试覆盖不到关键路径
错误提示不清楚
性能或安全风险没有被提到

评审阶段就是把 Agent 从“作者模式”切换到“审查模式”。

作者模式容易为自己的实现找理由；审查模式则要主动找漏洞、回归风险和遗漏测试。把这两个阶段分开，会比让同一个回复里同时完成实现和自我审查更可靠。

对用户来说，评审输出也更有价值。它能帮助你快速判断这次修改是否值得合并，还是需要继续返工。

学习和记忆的意义

项目名字里的 “Compound” 暗示了一个重要想法：工程经验应该复利增长。

如果 AI 每次犯错后只是当场修好，下次又犯同样错误，效率提升就很有限。更好的方式是把有价值的经验沉淀下来：

这个项目的目录约定
某类错误的排查方法
测试命令和注意事项
不要触碰的生成文件
代码风格偏好
常见实现模式

这些经验可以变成规则、记忆、文档或模板。后续任务中，Agent 先读取这些沉淀，再开始工作。

这就是 AI 编程从“单次问答”走向“长期协作”的关键。

适合什么场景

Compound Engineering Plugin 适合这些场景：

长期使用 AI Agent 写代码
一个项目会被多次、多轮修改
希望 AI 先计划再实现
希望改完后自动进入 review 思维
团队想统一 AI 编程流程
同时使用 Claude Code、Codex、Cursor 等多个工具
希望把项目经验沉淀成可复用规则

如果只是偶尔让 AI 写一个小脚本，完整流程可能显得偏重。

但如果你正在把 AI 编程助手当成日常开发伙伴，计划、执行、评审、学习这套循环就会明显有用。

和普通提示词模板有什么区别

普通提示词模板通常解决的是“怎么说清楚任务”。

比如：

请一步步思考
请先阅读文件
请保持代码风格一致
请运行测试
请总结修改内容

这些提示当然有用，但它们还是依赖用户每次正确使用。

Compound Engineering Plugin 更偏工作流层。它把这些要求组织成可重复的过程，并适配不同 Agent 工具。这样你不是每次从零写提示词，而是在一套流程里推进任务。

简单说，提示词模板像提醒，工作流插件像制度。

使用时要注意

第一，不要把流程变成负担。

小任务不一定需要完整计划和长篇评审。好的工作流应该能根据任务复杂度调整，简单问题快速处理，复杂问题再走完整循环。

第二，评审不能替代测试。

Agent review 能发现很多问题，但它仍然可能漏掉真实运行时错误。最终判断还要看测试、类型检查、构建结果和人工审查。

第三，规则要持续清理。

沉淀经验很重要，但规则越积越多也会变成噪声。过时规则、重复规则、只适合某次任务的临时经验，都应该定期整理。

第四，跨工具一致不等于完全相同。

Claude Code、Codex、Cursor、Copilot 等工具能力和交互方式不同。统一的是工作方法，不一定是每个命令、每个配置细节都完全一样。

适合怎样的团队

如果一个团队已经允许 AI Agent 修改真实代码，那么只讨论“哪个模型更强”是不够的。

更应该关心：

AI 修改前是否理解任务
AI 修改中是否遵守项目边界
AI 修改后是否主动审查风险
AI 是否能从历史错误中学习
团队是否有统一的 Agent 使用规范

Compound Engineering Plugin 这类项目的意义就在这里。它把 AI 编程从个人技巧，往团队可复用流程推进了一步。

参考

EveryInc/compound-engineering-plugin

最后一句

Compound Engineering Plugin 值得关注的地方，不是多一个 AI 编程命令，而是把 AI 编程组织成可循环改进的工程流程。

当 AI Agent 开始参与真实项目，计划、执行、评审和经验沉淀会比单次生成代码更重要。

Claude Code Hooks Mastery：13 个 Hooks 生命周期与自动化控制入门

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery 是一个围绕 Claude Code Hooks 的学习项目。

它不是只给几个零散脚本，而是把 Claude Code 的 hooks 生命周期、配置方式、脚本写法和常见自动化场景放在一起讲清楚。对于想让 Claude Code 更可控、更像工程化助手的人来说，这类资料很值得看。

Claude Code 默认已经能读代码、改文件、跑命令。但如果你想让它在特定时机自动检查权限、拦截危险操作、注入项目规范、运行测试、提醒团队规则，单靠聊天指令就不够稳定。Hooks 的价值就在这里：把“每次都要提醒 AI 的规则”变成可执行的流程。

Hooks 解决什么问题

使用 Claude Code 一段时间后，常见痛点大概有这些：

每次新会话都要重复告诉它项目规则
担心它执行不该执行的命令
希望文件修改前后自动做检查
想在提交前自动跑格式化、测试或安全扫描
想把团队规范写成固定流程，而不是靠口头提醒
想在工具调用前后拿到上下文，做记录或拦截
希望复杂任务可以触发子代理或专门脚本处理

Hooks 就是为这些“固定时机的自动动作”准备的。

你可以把它理解成 Claude Code 工作流里的事件钩子：当会话开始、用户提交提示词、模型准备调用工具、工具调用完成、代理即将结束等节点发生时，Claude Code 可以执行你配置的脚本。

13 个 Hooks 生命周期

项目 README 的重点之一，是系统整理了 Claude Code 的 13 个 hook 事件。

这些事件覆盖了从会话开始到工具调用、从用户输入到代理结束的多个节点。按用途可以粗略分成几类：

会话启动相关：用于初始化环境、注入项目上下文
用户输入相关：用于检查提示词、补充规则、做审计
工具调用前相关：用于权限判断、命令拦截、安全检查
工具调用后相关：用于记录结果、触发格式化、运行验证
任务结束相关：用于总结、清理、通知或保存状态

这种生命周期设计让你不必把所有规则都写进一个超长提示词里。

比如，权限控制应该发生在工具调用前；格式化检查更适合发生在文件修改后；项目规范注入适合发生在会话开始或用户输入后。把规则放到正确的 hook 节点，通常比把所有内容塞进 system prompt 更可靠。

配置文件在哪里

Claude Code 的 hooks 通常通过设置文件配置。

常见位置包括：

用户级配置：~/.claude/settings.json
项目级配置：.claude/settings.json

用户级配置适合放个人偏好，比如通用安全规则、命令拦截、日志路径。

项目级配置适合放仓库相关规则，比如这个项目必须跑什么测试、哪些目录不能改、生成文件怎么处理、提交前要做哪些检查。

如果你在团队里使用 Claude Code，更推荐把项目级配置放进仓库。这样每个人打开项目时，拿到的是同一套 AI 协作约束，而不是各自凭记忆提醒。

单文件脚本为什么重要

项目里强调了 UV 单文件脚本的写法。

这类脚本的好处是部署简单。一个 Python 文件就可以声明依赖并运行，不必为了一个 hook 单独维护复杂环境。对 hooks 来说，这很合适，因为很多 hook 只是做一件小事：

检查命令是否允许执行
判断文件路径是否安全
读取项目规范并返回给 Claude
扫描输出中是否包含敏感信息
在修改后运行格式化或测试
把事件写入日志

Hook 脚本越小，越容易维护，也越不容易变成新的复杂系统。

可以做哪些自动化

claude-code-hooks-mastery 展示的方向比较多，实际工作中最常见的是下面几类。

1. 权限和安全控制

这是 hooks 最直接的用途。

比如在 Claude Code 准备执行命令之前，先检查命令内容。如果命令包含删除、重置、清空、覆盖等高风险动作，就阻止执行或要求人工确认。

类似规则还可以用于文件路径：

不允许修改生产配置
不允许写入密钥文件
不允许删除迁移脚本
不允许触碰指定目录
不允许执行未批准的网络命令

这类保护放在工具调用前，比写一句“不要做危险操作”更可靠。

2. 上下文注入

很多项目都有固定背景：

技术栈
编码规范
测试命令
分支策略
目录结构
禁止事项
生成文件处理规则

这些内容每次手动告诉 Claude Code 很麻烦，也容易漏。Hooks 可以在会话开始或用户提交提示词后，把必要上下文自动注入进去。

这相当于给 Claude Code 配一个项目级的工作说明书。它不会替代 README 或开发文档，但能让 AI 在执行任务前更快进入正确状态。

3. 修改后的验证

当 Claude Code 修改文件后，可以通过 hook 自动触发检查。

常见动作包括：

运行格式化
运行 lint
运行单元测试
检查类型错误
扫描生成文件
校验 Markdown 或 JSON 格式

这对减少低级错误很有帮助。尤其是 AI 改动多个文件时，修改后自动跑一轮轻量验证，可以更早发现问题。

不过也要注意，hook 里不适合默认塞太重的任务。每次文件改动都跑完整测试套件，可能会让体验变得很慢。更实用的做法是按文件类型、目录和任务风险选择检查范围。

4. 团队规则验证

如果团队已经有明确约定，可以把一部分约定放进 hooks。

比如：

提交信息格式
代码风格规则
禁止直接修改某些生成文件
文档必须同步更新
API 变更必须改测试
某些目录只能用指定工具生成

这会让 Claude Code 更像团队流程的一部分，而不是一个不受约束的外部助手。

当然，hooks 不应该替代 CI。它更适合做本地快速提醒和前置拦截，真正的最终验证仍然应该交给 CI、review 和测试系统。

5. 子代理和专门任务

README 里还提到子代理相关内容。

这类用法适合把复杂任务拆给更专门的流程处理。比如主会话负责理解需求，hook 或配置触发专门的检查、审计、总结、文档整理任务。

对个人用户来说，最先值得做的不是复杂代理编排，而是把重复、明确、低风险的动作交给 hooks。等规则稳定后，再考虑更复杂的自动化。

Statusline 和输出样式

项目还覆盖了状态栏和输出样式。

这部分看起来像体验细节，但对长期使用 Claude Code 很有意义。状态栏可以展示当前上下文、任务状态、环境信息或提示信息；输出样式则可以让 Claude Code 的回答更符合你的工作习惯。

如果你每天都在同一个终端里和 AI 协作，这些细节会影响效率。好的状态提示能减少误操作，也能让你更快判断当前会话是否处在正确项目、正确分支、正确环境里。

不要把 hooks 写得过重

Hooks 很强，但不适合什么都往里面塞。

比较好的规则是：

高频动作要快
安全拦截要明确
输出要短
失败原因要可读
脚本尽量单一职责
重型检查交给显式命令或 CI

如果一个 hook 每次都执行十几秒，用户很快就会想关掉它。如果一个 hook 拦截规则含糊不清，Claude Code 和用户都会难以理解下一步该怎么做。

Hooks 最适合处理那些边界清楚的事情：允许或拒绝、补充上下文、记录日志、运行轻量检查、提示下一步。

适合怎样的使用者

如果你只是偶尔让 Claude Code 改一小段代码，可能暂时不需要深入 hooks。

但如果你符合下面几种情况，就很适合研究这个项目：

高频使用 Claude Code
经常让 AI 修改真实项目代码
担心 AI 执行危险命令
想把团队规范自动注入 AI 工作流
希望修改后自动跑检查
想把重复提醒变成配置
正在搭建更稳定的 AI 编程流程

尤其是多人协作项目，hooks 的意义会更明显。它可以把一部分团队经验沉淀成脚本，而不是靠每个人临时提醒 AI。

使用时要注意

第一，先从安全类 hook 开始。

相比复杂自动化，命令拦截、路径保护、敏感文件检查更容易落地，也更能立刻降低风险。

第二，项目级规则要谨慎提交。

.claude/settings.json 会影响所有使用这个仓库的人。把规则提交前，最好确认它不会过度限制正常开发，也不会依赖只有你本机才存在的路径。

第三，hook 输出要简洁。

Claude Code 会消费这些输出。输出太长，会污染上下文；输出太模糊，又起不到指导作用。最好只返回必要判断和下一步建议。

第四，保持可调试。

Hooks 一旦变多，问题可能出在配置、脚本、权限、路径、依赖或 Claude Code 本身。给脚本留下清晰日志，会让后续排查轻松很多。

参考

disler/claude-code-hooks-mastery

最后一句

Claude Code Hooks 的价值，是把“希望 AI 每次都记住的规矩”变成真正会执行的流程。

如果你已经开始把 Claude Code 用在真实项目里，hooks 会是从“会聊天的编程助手”走向“可约束的工程协作者”的关键一步。

Claude-Mem：给 Claude Code 加上跨会话长期记忆

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem 是一个给 Claude Code 使用的持久化记忆系统。

它想解决的问题很具体：AI 编程助手每次开新会话时，往往会忘记之前讨论过的架构决策、踩过的坑、项目偏好和实现背景。
如果一个项目做得久，每次都重新解释上下文，非常浪费时间。

Claude-Mem 的思路是：把 Claude Code 的会话内容压缩成记忆，存进本地数据库和向量库，之后再通过搜索工具找回来。

它解决什么问题

Claude Code 很适合处理代码任务，但会话上下文毕竟有限。

常见痛点包括：

新会话不知道旧会话做过什么
项目里的设计决策需要反复解释
曾经排查过的问题容易重复踩
长期任务缺少连续记忆
多次对话之间很难沉淀项目知识

Claude-Mem 就是围绕这些问题设计的。

它不是简单保存聊天记录，而是把会话压缩成更容易检索的记忆片段。这样后续需要时，可以通过语义搜索把相关上下文找回来。

工作方式

从 README 的设计看，Claude-Mem 主要由几部分组成。

第一部分是 hooks。

它会接入 Claude Code 的会话流程，在合适的时机捕获会话数据。

第二部分是后台 worker。

worker 负责把原始会话内容处理成更短、更可检索的记忆。

第三部分是本地存储。

项目使用 SQLite 保存结构化元数据，用 Chroma 保存向量索引。这样既能保留会话记录的基本信息，也能支持语义检索。

第四部分是 mem-search。

这是给 Claude Code 使用的查询入口。需要找回旧上下文时，可以通过它搜索相关记忆。

整体流程可以理解为：

Claude Code 会话产生内容
hooks 捕获会话数据
worker 异步压缩和整理
记忆写入 SQLite 与 Chroma
后续通过 mem-search 检索

适合什么场景

Claude-Mem 适合长期项目，而不是一次性小任务。

比如：

一个仓库持续开发很多天
代码结构复杂，背景说明很多
需要记住项目约定、命名习惯和架构选择
经常让 Claude Code 修 Bug、写功能、整理文档
希望 AI 能记住“之前为什么这么改”

如果你只是临时让 Claude Code 改一行代码，长期记忆意义不大。
但如果你把 Claude Code 当作长期协作者，它就会变得有用。

安装和启动

README 中给出的安装方式很直接：

1
2

npm install -g claude-mem
claude-mem install

启动时可以使用：

`1`	`claude-mem start`

查看状态：

`1`	`claude-mem status`

如果需要停止：

`1`	`claude-mem stop`

这些命令背后的目标，是把记忆系统作为一个长期运行的本地服务接到 Claude Code 工作流里。

`mem-search` 怎么用

mem-search 是找回记忆的关键入口。

它的用途不是替代普通搜索，而是让 Claude Code 能按语义查询过去会话中的内容。

比如你可以让 Claude Code 查询：

某个模块之前为什么这样设计
某个 Bug 当时怎么排查
项目里约定的命名规则
之前讨论过的技术取舍
某次重构的背景原因

这种查询和简单关键词搜索不同。
如果记忆压缩和向量索引做得好，即使你不记得原话，也能找回相近语义的内容。

和普通项目文档有什么区别

项目文档适合记录稳定结论。

比如：

架构说明
部署流程
API 约定
数据库结构
开发规范

Claude-Mem 更适合记录会话过程中产生的上下文。

比如：

为什么某个方案被放弃
某个临时问题怎么绕过
某个实现背后的讨论过程
还没来得及写进文档的项目偏好
多次对话里积累出的任务背景

两者不是互相替代。
比较好的方式是：稳定知识写进项目文档，过程性上下文交给记忆系统辅助检索。

使用时要注意什么

第一，长期记忆不是越多越好。

如果所有对话都无差别保存，后续检索可能会变得嘈杂。真正有价值的是项目决策、实现背景、问题排查和长期偏好。

第二，记忆不能替代代码和文档。

AI 搜到的旧上下文只能作为参考。最终判断仍然要看当前代码、测试结果和最新需求。

第三，隐私和本地数据要注意。

既然它会保存会话内容，就要清楚哪些项目适合接入，哪些敏感信息不应该进入对话。

第四，记忆系统需要维护。

随着项目推进，旧记忆可能过时。过时的上下文如果被误用，反而会误导后续任务。

为什么这类工具值得关注

AI 编程工具正在从“单次问答”走向“长期协作”。

单次问答里，模型只要回答当前问题就够了。
长期协作里，它需要知道项目历史、之前的决策、团队偏好和已经踩过的坑。

Claude-Mem 这类工具的意义就在这里：它把“记住上下文”从临时聊天能力，变成一个可以安装、运行、检索的本地系统。

对真实工程项目来说，这比单纯让模型上下文窗口变长更实用。
因为很多信息不是一次性塞进上下文就好，而是需要在合适的时候被找回来。

适合谁尝试

如果你符合下面几种情况，可以考虑试试：

高频使用 Claude Code
经常跨天处理同一个项目
项目上下文比较复杂
经常需要向 AI 重复解释背景
想把会话里的经验沉淀下来

如果你只是偶尔使用 Claude Code，或者项目很小，暂时不一定需要这类系统。

参考

thedotmack/claude-mem

最后一句

Claude-Mem 的重点不是“保存聊天记录”，而是让 Claude Code 能在后续任务里找回有用上下文。

当 AI 编程从一次性任务变成长期项目协作，记忆系统会越来越重要。
它不能替代文档和测试，但可以减少重复解释，让 AI 更像一个了解项目历史的助手。

编译 UEFI 程序入门：从 uefi-simple 到第一个 .EFI

Thu, 30 Apr 2026 19:53:08 +0800

编译第一个 UEFI 程序并不轻松：环境安装耗时，链接器报错很多，.EFI 程序也不像普通桌面程序那样有成熟直观的编辑和运行体验。

这篇就按入门角度整理一下：如果只是想先编译出自己的第一个 UEFI 程序，应该从哪里开始，哪些概念要先搞清楚，哪些坑最容易遇到。

UEFI 程序是什么

UEFI 程序通常是一个 .EFI 文件。

它不是 Windows 下双击运行的普通 .exe，而是运行在 UEFI 固件环境里的 PE/COFF 可执行文件。常见场景包括：

启动管理器
硬件初始化工具
固件更新工具
引导前诊断工具
自定义启动流程

你在系统启动早期看到的很多功能，本质上都可能和 UEFI 应用、驱动或固件服务有关。

对初学者来说，先不用急着理解完整固件开发。第一步只要完成一个目标：编译出一个能被 UEFI Shell 或模拟器加载的 .EFI 文件。

为什么不建议一开始就上 EDK II

UEFI 正式开发经常会遇到 EDK II。

EDK II 功能完整，也更接近真实固件工程，但它对新手不太友好：

工程结构复杂
构建系统有学习成本
环境变量和工具链配置比较多
编译报错不容易看懂
很容易还没写代码，就先卡在环境上

如果目标只是“先跑起来一个最小 UEFI 程序”，更适合从轻量示例开始。

pbatard/uefi-simple 就是这类项目。它的定位很直接：提供一个简单的 UEFI Hello World 示例，让你先把 .EFI 编译出来。

`uefi-simple` 适合用来做什么

uefi-simple 适合做 UEFI 入门的第一块踏板。

它主要解决三个问题：

给你一个最小可编译的 UEFI 应用结构
帮你避开一开始就接触大型固件工程的复杂度
让你能先验证编译、链接、运行链路是否通

这个项目支持不同构建方式，包括 Visual Studio 2022 和 MinGW/gcc，也可以配合 QEMU 与 OVMF 做测试。

也就是说，你不一定非要准备真实机器反复重启测试。先用模拟器把程序跑起来，会安全很多。

入门前要准备哪些东西

最少需要准备几类工具。

第一类是编译工具链。

如果你在 Windows 上，可以优先考虑：

Visual Studio 2022
或 MinGW/gcc

第二类是 UEFI 运行环境。

可以有两种选择：

用真实机器的 UEFI Shell 运行 .EFI
用 QEMU + OVMF 在虚拟环境里测试

第三类是示例项目。

新手不建议从空目录开始手写构建脚本。直接使用 uefi-simple 这类最小示例，可以少踩很多构建系统的坑。

大致流程

一个最小 UEFI 程序的入门流程可以这样理解。

第一步，拿到示例项目。

`1`	`git clone https://github.com/pbatard/uefi-simple.git`

第二步，选择构建工具链。

如果用 Visual Studio，就按项目里的 Visual Studio 方案构建。
如果用 MinGW/gcc，就按项目提供的 Makefile 或说明走。

第三步，生成 .EFI 文件。

这里最关键的是确认目标架构。常见 PC 一般是 x86_64，也就是 64 位 UEFI 环境。

第四步，把 .EFI 放到可以被 UEFI Shell 访问的位置。

如果用真实机器，通常会准备一个 FAT32 分区或 U 盘。
如果用 QEMU，可以把目录或镜像挂载进去。

第五步，在 UEFI Shell 里运行。

运行效果通常就是一个最小输出，比如打印类似 Hello World 的内容。

最容易卡住的地方

编译 UEFI 程序最容易卡的不是 C 语言本身，而是环境和链接。

常见问题包括：

编译器架构不对
目标格式不对
链接参数不完整
缺少 UEFI 入口点
生成的是普通可执行文件，不是 UEFI 能加载的 .EFI
QEMU 或 OVMF 没配置好
真实机器 Secure Boot 阻止运行未签名程序

尤其是链接器报错，经常会让新手误以为代码写错了。
实际上，很多时候是入口函数、子系统、目标架构或链接脚本配置不对。

所以第一阶段不要急着改复杂逻辑。先确保原始示例能编译、能运行，再一点点改输出内容。

测试时为什么推荐 QEMU + OVMF

真实机器测试 UEFI 程序并不是不行，但新手阶段不太方便。

因为你可能需要反复：

编译
拷贝到 U 盘
重启
进入 UEFI Shell
运行
记录报错
回到系统修改

这个循环很慢。

QEMU + OVMF 的好处是可以在操作系统里直接模拟 UEFI 环境。你可以更快地验证 .EFI 是否能被加载，也不容易影响真实机器启动项。

等程序基本跑通，再放到真实机器上测试，会更稳。

新手应该先改哪里

如果你已经用示例项目编译出了第一个 .EFI，下一步不要马上写复杂功能。

建议按这个顺序改：

先改输出文本，确认重新编译后的程序确实生效。
再尝试读取 UEFI 提供的简单信息。
再理解入口函数、输出协议和基本服务。
最后再考虑文件系统、图形输出、启动项管理等复杂功能。

这样做的好处是每一步都能验证。
如果一上来就改很多东西，出错时很难判断到底是代码问题、编译问题，还是运行环境问题。

和普通 C 程序有什么不同

UEFI 程序虽然可以用 C 写，但它和普通 C 程序的运行环境完全不同。

普通 C 程序通常运行在操作系统里，可以依赖标准库、文件系统、进程模型和系统调用。

UEFI 程序运行在操作系统启动之前，它依赖的是 UEFI 固件提供的服务。很多你在普通程序里习惯使用的东西，在这里并不是天然可用。

所以写 UEFI 程序时，要先适应几个变化：

入口函数不一样
输出方式不一样
可用库不一样
内存和文件访问方式不一样
调试方式不一样

这也是为什么推荐先从最小示例开始，而不是直接照普通 C 程序的习惯写。

一个比较现实的学习路线

如果只是入门，可以按这个路线走：

第一步：编译 uefi-simple
第二步：用 QEMU + OVMF 跑起来
第三步：修改 Hello World 输出
第四步：理解 UEFI Shell 怎么加载 .EFI
第五步：学习 UEFI 的入口函数和基本输出协议
第六步：再看 EDK II 或更完整的 UEFI 开发资料

这条路线的重点是先让反馈闭环跑起来。

只要你能从源码生成 .EFI，再在 UEFI 环境里看到输出，就已经跨过了最难的第一道门槛。

参考

最后一句

编译第一个 UEFI 程序，难点通常不在“写出一段 C 代码”，而在把工具链、链接格式和运行环境串起来。

先别急着做复杂功能。
从 uefi-simple 这种最小示例开始，先得到一个能运行的 .EFI，再逐步理解 UEFI 的入口、协议和构建方式，会轻松很多。

Claude.md 不是越长越好：AI 编程全局记忆文件该怎么写

Wed, 29 Apr 2026 21:07:37 +0800

最近看到一个关于 AI 编程全局记忆文件的讨论：项目里使用 Claude.md、AGENTS.md 这类文件之后，效果不一定会变好，甚至可能让成功率下降，同时推理成本还会上升。

这件事乍一看有点反直觉。我们通常会觉得，给 AI 更多项目背景、更多规则、更多说明，它应该更容易写对代码。
但实际问题在于：Claude.md 不是普通文档，而是每次对话都会被塞进上下文的全局记忆。它写得越多，模型每次都要读得越多；它写得越含糊，模型每次都要多做判断；它写进了不该写的流程，模型还可能在不相关的任务里触发多余动作。

所以，Claude.md 真正难写的地方，不是怎么把内容写全，而是怎么判断哪些内容值得长期占用上下文。

Claude.md 到底是什么

在 AI 编程工具里，Claude.md、AGENTS.md 这类文件本质上都是全局记忆文件。

普通对话会进入上下文，但上下文长度有限。对话长了以后，历史内容会被压缩，部分细节会丢失。全局记忆文件的作用，是把一些重要规则固定下来，让模型在每次任务开始时都能看到。

这意味着两件事：

写进去的内容更不容易被遗忘
写进去的内容也会在每次任务里产生成本

它不像一份 README，只在需要时被阅读。它更像一套长期有效的工作约束。只要放进去，就默认每次都会影响模型的判断。

因此，Claude.md 不是项目介绍，也不是经验合集，更不是把所有开发流程都塞进去的地方。它应该只存放那些模型如果不知道，就容易反复犯错的规则。

为什么写了反而可能变差

全局记忆文件写得不好，主要会带来三类问题。

第一，它会占用上下文。

如果 Claude.md 有一千行，那么这些内容会长期进入模型上下文。真正与当前任务有关的代码、错误信息、需求说明，反而会被挤压。上下文不是免费的空间，越大的全局规则，越容易稀释当前任务的重点。

第二，它会触发多余行为。

比如在全局文件里写：

1
2

每次开始任务前，都要完整阅读项目目录。
每次修改后，都要执行完整链路测试。

这些话看起来很负责，但放在全局记忆里就会变成“所有任务都默认执行”。哪怕只是改一行文案，模型也可能因为这条规则去做不必要的探索和测试。结果就是任务变慢、成本变高，甚至引入新的干扰。

第三，它会增加判断负担。

像“保持代码优雅、简洁、可维护、可扩展”这类话，听起来正确，但实际约束很弱。模型每次生成代码时都要判断什么叫优雅、什么叫可扩展，却没有得到明确边界。

更好的写法不是堆抽象美德，而是写具体禁令或反例。比如：

1
2
3

不要为了单个调用点新增通用抽象。
不要在没有测试覆盖的情况下改动共享解析逻辑。
不要把临时脚本放进业务源码目录。

这些规则更具体，也更容易被执行。

应该写什么

判断一条内容要不要写进 Claude.md，可以用一个简单标准：

如果不写，AI 就会反复犯同一种错误，那它值得写进去。

适合写进全局记忆文件的内容，通常有这些特点：

长期有效
与当前仓库强相关
无法从代码结构自然推断
能明确改变模型行为
最好是约束、禁令、路径规则或固定命令

比如：

所有 Hugo 文章只改 index.zh-cn.md，不自动生成其他语言版本。
文章 front matter 必须包含 title/date/draft/tags/categories/slug/description。
不要修改 public/ 目录里的构建产物。
PowerShell 下执行部署时使用 scripts/deploy.ps1。

这些内容不是泛泛而谈，而是和仓库的真实工作方式绑定。模型如果不知道，就可能做错；模型知道以后，确实能减少误操作。

不该写什么

很多人容易把 Claude.md 写成项目说明书，这通常没有必要。

不太适合写进去的内容包括：

项目愿景和背景介绍
大段目录结构说明
临时任务计划
一次性的调试步骤
抽象的代码审美要求
只在少数情况下才需要执行的长流程

比如“这是一个电商项目，包含商品、订单、用户模块”这种描述，对模型完成具体编码任务帮助有限。真正开发时，模型应该根据当前需求、规格文档、代码结构和测试来判断，而不是靠全局记忆里的粗略介绍。

目录结构也是类似。除非某个目录有特殊约定，比如“共享组件只能从这个目录引用”，否则没必要把整个树形结构写进去。模型可以自己读取项目目录，硬塞一份静态目录说明反而容易过期。

流程更适合做成技能或命令

如果一段内容是“第一步做什么、第二步做什么、第三步做什么”，它未必适合放进 Claude.md。

长期流程可以沉淀成技能、脚本或命令。这样做的好处是：全局记忆里只需要保留名称和触发条件，真正的详细步骤只在需要时加载。

比如：

1
2

当用户要求翻译 Hugo 文章时，使用 post-translate 技能。
当用户要求部署站点时，运行 hugo-rsync-deploy 流程。

这比把完整翻译流程、部署流程都写进 Claude.md 更轻。全局记忆保持短，具体流程交给可触发的工具。

Claude 最近的初始化流程也在往这个方向走：不只是生成一个 Claude.md，还会尝试把可复用流程拆成 skills，把固定事件拆成 hooks。这个变化背后的思路很清楚：全局记忆只做入口，细节按需加载。

Claude.md 需要持续迭代

Claude.md 不应该一次写完就不管。

更合理的方式是先保持简短，让模型在真实任务里暴露问题。某个错误出现一次，可以先人工处理；如果同类错误出现两次以上，就说明它可能值得沉淀为全局规则。

这类迭代比一开始写一大堆规则更有效。因为一开始你不知道哪些规则真的有用，也不知道哪些内容会变成噪音。随着项目变大、协作变多、模型行为逐渐稳定，再慢慢把高频问题写进去。

还有一个重要趋势：模型越强，全局记忆文件反而应该越短。

以前很多需要写进提示词的要求，现在模型已经能自然做到。继续把这些基础要求塞进 Claude.md，只会增加上下文负担。全局记忆应该随着模型能力提升而收缩，只保留这个仓库独有、模型无法自动推断的部分。

一个更实用的写法

写 Claude.md 时，可以按这个顺序思考：

这个仓库有什么特殊约定？
哪些错误模型已经犯过不止一次？
哪些目录、文件或命令绝对不能误用？
哪些流程应该改成技能、脚本或命令，而不是常驻上下文？
哪些内容只是介绍，可以删掉？

最后得到的文件，可能只有几十行。它不需要完整解释项目，而是要精确约束行为。

一个好的 Claude.md，应该像这样：

# 工作规则

- 只改与当前任务相关的文件。
- 不要修改 public/、resources/ 这类构建产物目录。
- Hugo 文章改写只处理 index.zh-cn.md，不生成其他语言版本。
- 如果涉及部署，先运行 hugo 构建，再执行既有 rsync 脚本。
- 遇到已有用户改动时，不要回滚，必须基于现状继续修改。

它短，但每一条都能影响实际行为。这样的内容才值得长期占用上下文。

最后一句

Claude.md 的价值不在于让 AI “知道更多”，而在于让 AI “少犯固定错误”。

它不是知识库，也不是项目百科，而是 AI 编程过程里的长期约束文件。
写得越具体、越短、越贴近真实错误，它越有用；写得越泛、越长、越像项目介绍，它越可能拖慢模型，甚至让结果变差。

把全局记忆当成稀缺资源，而不是无限草稿纸。这大概就是写好 Claude.md 最重要的一条原则。

Codex 开始控制电脑，对以后意味着什么？

Wed, 29 Apr 2026 11:28:25 +0800

Codex 这次最值得关注的变化，不是又多了一个普通按钮，而是它开始往“控制电脑”这个方向走。

以前我们使用 AI，更多是在聊天框里提问、复制、粘贴、再手动操作软件。
现在这个边界开始往外扩：AI 不只是回答你，而是可以根据你的目标去操作桌面应用。

这件事短期看是一个新功能，长期看可能会改变很多人使用电脑的方式。

这个功能是什么

简单说，Codex 的电脑使用能力，就是让它能接触并操作桌面环境。

它可以做的事包括：

可以选择并控制某个应用
可以用自然语言下达任务
可以打开浏览器、AI 工具、本地文件或其他软件
可以输入内容、点击按钮、等待结果
可以把多个步骤串成一个任务
可以在后台继续执行，不需要用户每一步都手动跟着

它的定位不是单纯替你写一段文本，而是替你完成一段操作流程。

这就是 Agent 和普通聊天机器人的关键区别：
聊天机器人主要给答案，Agent 更接近“拿到目标后去执行”。

为什么这件事重要

过去很多自动化都要求你会写脚本。

比如你想完成一个跨软件流程：

打开网页
找资料
复制内容
交给另一个 AI 工具处理
保存文件
再打开本地目录检查结果

如果要自动化这件事，传统做法可能是写浏览器脚本、调用 API、写本地程序，甚至还要处理各种软件窗口。

但很多普通用户不会写这些东西。
就算会写，也未必值得为一个临时任务专门写脚本。

电脑使用能力的意义就在这里：它把“脚本能力”往自然语言方向推了一步。

你不一定要告诉它每一步怎么点。
你可以告诉它你要什么结果，让它自己去尝试完成。

它能改变哪些工作流

我觉得最先被改变的，不会是特别严肃、特别高风险的工作，而是那些“烦、杂、重复、但又不值得专门写程序”的流程。

1. 跨软件搬运

最典型的就是在多个软件之间搬信息。

以前你可能要在浏览器、文档、聊天窗口、本地文件夹之间来回切。
以后可以把这类任务交给 Agent：

去找某类资料
汇总成文档
保存到指定目录
打开结果给你确认

这类工作不难，但很耗注意力。
Agent 的价值就是把这些碎操作吃掉。

2. 多个 AI 工具协同

现在很多人的真实工作流已经不是只用一个 AI。

可能是：

一个工具写代码
一个工具查资料
一个工具生成图片
一个工具整理文档

以前这些工具之间靠人肉复制粘贴。
以后 Agent 可以成为中间层：它负责打开工具、传递上下文、等待输出、整理结果。

这会让“多个 AI 协同”从手工流程变成半自动流程。

3. 办公软件自动化

表格、PPT、文档、邮件，这些软件都有一个共同特点：功能很强，但很多操作很碎。

如果 Agent 能稳定控制这些软件，以后的办公自动化门槛会明显下降。

你不用记菜单在哪里，也不用学复杂快捷键。
你只需要说清楚目标，比如：

把这份表格整理成月报
根据这份文档做一页总结
把这些资料合并成一个结构清楚的说明

真正麻烦的按钮操作，会逐渐被隐藏到自然语言后面。

对普通用户意味着什么

对普通用户来说，这类功能的影响可能比“模型又聪明了一点”更直接。

因为它降低的不是知识门槛，而是操作门槛。

很多人不是不会表达需求，而是不知道软件里该点哪里、怎么组合功能。
Agent 如果能接管这部分，人使用电脑的方式就会变成：

1
2
3

我描述目标
Agent 操作软件
我检查结果

这比单纯聊天更接近真实生产力。

对软件形态的影响

如果这类 Agent 能力继续成熟，软件本身也会被反向影响。

过去软件设计主要服务人类点击。
以后软件可能还要服务 Agent 操作。

这意味着：

界面元素需要更清晰
操作反馈需要更稳定
本地权限需要更细
软件可能会提供更适合 Agent 调用的接口
用户会更在意“能不能被 AI 顺利操作”

长期看，应用之间的边界可能会变薄。
用户关心的不再是“我打开哪个软件”，而是“我要完成什么任务”。

现在还不能过度乐观

当然，现在还不到完全放手的时候。

这类能力目前还有几个明显限制：

稳定性还需要观察
复杂任务可能中途出错
权限边界必须谨慎
涉及账号、支付、删除文件等操作不能随便放权
额度消耗也不是完全可以忽略

所以现阶段最合适的用法，不是让它完全接管电脑，而是让它处理低风险、可检查、步骤繁琐的任务。

比如：

整理资料
生成草稿
跨工具搬运内容
打开和检查文件
做一些可以人工复核的半自动流程

最后一句

Codex 这次更新真正重要的地方，是它把 AI 从“回答问题”推向了“操作环境”。

短期看，它是一个电脑使用功能。
长期看，它可能是个人电脑交互方式的一次转向。

以后我们使用电脑，可能会越来越少地记按钮、找菜单、切窗口。
更多时候，我们只需要说清楚目标，然后让 Agent 去执行，再由人做最后判断。

Codex Skill 明明在目录里，为什么就是不显示？

Wed, 29 Apr 2026 11:18:00 +0800

这次遇到的问题很隐蔽：~/.codex/skills 里明明已经放好了多个 skill，新开 Codex 线程之后，侧边栏却还是只能看到少数几个。

一开始看起来像是缓存或索引问题，但实际原因更具体：几个 SKILL.md 文件开头带了 UTF-8 BOM，Codex 0.111.0 的 skill loader 没有跳过这个字节，于是误判文件没有合法的 YAML front matter。

现象

本地目录里有这些 skill：

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

但新开线程时，实际暴露出来的只有：

1
2

bilibili-speech-transcriber
product-cutout-normalize

也就是说，文件存在不等于当前会话一定能加载成功。Codex 会先解析每个 SKILL.md 的 front matter，解析失败的 skill 会直接被排除。

排查

用 codex exec 启动一个新会话时，可以看到更直接的错误（在vscode等IDE中可能看不到这些log）：

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

这些文件肉眼看起来都有正常的开头：

---
name: post-rewrite
description: ...
---

真正的问题在字节层面。

失败文件的开头是：

`1`	`EF-BB-BF-2D-2D-2D`

能正常加载的文件开头是：

`1`	`2D-2D-2D`

2D-2D-2D 就是 ---。前面的 EF-BB-BF 是 UTF-8 BOM。

原因

Codex 0.111.0 的 skill loader 当前要求 SKILL.md 文件第一个字节就是 --- 的第一个 -。

如果文件前面带了 UTF-8 BOM，那么文件实际开头就不再是 ---，而是：

`1`	`BOM + ---`

于是 loader 会认为它没有以 front matter 分隔符开头，最后报：

`1`	`missing YAML frontmatter delimited by ---`

这不是 skill 内容写错了，也不是目录放错了，而是编码细节让解析器没认出来。

修复

把出问题的 SKILL.md 转成无 BOM 的 UTF-8 即可。

PowerShell 可以这样处理：

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

处理后再检查文件头，应该从：

`1`	`EF-BB-BF-2D-2D-2D`

变成：

`1`	`2D-2D-2D`

验证

重新启动一个 Codex 会话后，可见 skill 恢复为：

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

如果侧边栏仍然只显示旧的列表，可以退出当前 Codex sidebar 或窗口，再重新打开项目。skill 列表通常在会话启动时加载，中途改文件不一定会立刻刷新到当前线程。

最后一句

这类问题最容易误判成“Codex 没重新索引”或“skill 没安装好”。

实际排查时可以先看三件事：

SKILL.md 是否真的在正确目录
文件头部是否有合法的 --- front matter
文件是否是无 BOM 的 UTF-8

这次的关键就是第三点：文件看起来没问题，但第一个字节不是 -，Codex 就没有把它当作一个有效 skill。

Codex 里的 ~/.codex/skills 和项目/.codex/skills 有什么区别

Wed, 29 Apr 2026 11:08:00 +0800

很多人整理 Codex skills 时，最容易卡住的问题就两个：

~/.codex/skills 和 项目/.codex/skills 有什么区别
为什么 skill 明明在目录里，当前会话里却不一定显示

这篇就直接说结论。

两者的区别

先记最短版本：

~/.codex/skills 是你的全局技能库
项目/.codex/skills 是这个仓库的本地技能库

`~/.codex/skills`

适合放：

你自己跨项目反复会用的 skill
跟具体仓库无关的通用流程
很明显属于你个人习惯的工作流

比如：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

这类 skill 的特点就是：离开当前项目也还能用。

`项目/.codex/skills`

适合放：

只对这个仓库成立的流程
跟当前项目目录结构、脚本、模板绑定很深的规则
需要让团队一起共享的 skill

比如：

这个仓库特有的发布流程
只能在这个项目里用的生成模板
跟项目私有脚本强绑定的自动化步骤

这类 skill 的特点是：离开这个仓库就没意义。

什么时候放全局，什么时候放项目里

直接这样判断就够了：

跟你个人习惯有关，放 ~/.codex/skills
跟仓库规则有关，放 项目/.codex/skills
能跨项目复用，优先放全局
要多人共享、跟仓库一起演进，优先放项目里

当前这个仓库是什么情况

按我现在看到的实际状态：

你的本机里有 ~/.codex/skills
当前仓库里没有 .codex/skills

所以你现在主要依赖的是全局 skills。
也就是说，像 post-rewrite、post-translate、git-commit-push 这些流程，现在更多是你个人工作流的一部分，不是这个仓库显式自带的一部分。

为什么磁盘里有，当前会话里却不一定显示

这里要分清两件事：

磁盘存在：说明 skill 文件在本地目录里
会话暴露：说明当前会话把它注册进了可用 skill 列表

这两者不是一回事。

所以会出现这种情况：

~/.codex/skills 里已经有 skill
但 / 后面的列表里没有显示

这通常不代表 skill 坏了，更常见的原因是：当前会话没有把它重新索引进去。

怎样让 skill 被当前会话暴露

最实用的步骤就这几条：

1. 目录放对

全局：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

项目级：

`1`	`项目/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` 头部可识别

最少要有：

---
name: your-skill-name
description: 这个 skill 是干什么的
---

3. 新建或修改后，开新会话

很多时候 skill 没显示，不是文件有问题，而是当前会话启动时就已经把可用 skill 列表定下来了。
所以你中途新建 skill，磁盘里虽然已经有了，这次会话也未必会重新认。

最稳的做法就是：

放好 skill
结束当前会话
重新进入项目
开一个新会话
再看 / 里有没有出现

4. 项目 skill 最好提前放好

如果你想让 项目/.codex/skills 更稳定地被识别，最好在进入仓库、启动会话之前，就把这些 skill 放进项目里。

最后一句

最短结论就是：

~/.codex/skills 是你的个人技能库
项目/.codex/skills 是仓库的本地规则库
skill 在目录里，不等于当前会话一定会显示
想让它显示，最常见的办法就是放对目录、写好 SKILL.md，然后开新会话

GoAccess 最新版自编译与使用记录：从源码安装到实时 HTML 报表

Wed, 29 Apr 2026 00:08:00 +0800

时间点按 2026-04-29 整理，当前官方 README 里给出的最新稳定版是 1.10.2。

1. 先装编译依赖

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. 下载最新版源码包

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. 配置编译参数

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

如果你还想给实时 HTML 报表配 TLS，也可以改成：

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. 编译并安装

1
2

sudo make
sudo make install

5. 确认版本

1
2

goaccess --version
which goaccess

6. 直接看终端报表

Nginx 或 Apache 常见 combined 日志可以先这样跑：

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

如果日志路径是 Apache：

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. 生成静态 HTML 报表

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

输出到当前目录也可以：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. 生成实时 HTML 报表

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

如果要改端口：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

如果只绑定本机：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. 持续追日志

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

从文件开头开始并保持实时：

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. 只看某类请求

例如只看带 firefox 的请求：

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

例如只看 5xx 和 3xx：

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. 多个日志一起分析

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

压缩和未压缩一起读：

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. 开多线程

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

加大 chunk：

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. 增量处理

先持久化一份旧日志：

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

再追加当前日志：

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

只读取已持久化数据：

`1`	`goaccess --restore`

14. 我自己会先跑的一组命令

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

就这样。
如果你的目标很明确，其实只要把最新版源码编译好，再把 --log-format=COMBINED 和 --real-time-html 这两个参数先跑通，后面基本就是围着日志路径、输出文件和端口在改。

模型	适合场景
`deepseek-v4-flash`	日常代码阅读、批量改小问题、生成脚本、整理上下文、低风险前端修改
`deepseek-v4-pro`	架构规划、复杂 bug、跨文件重构、事实核查、多工具调用、高风险改动

开发工具 on KnightLi的博客

Understand-Anything 怎么用？把代码仓库变成可问答知识图谱

为什么需要代码知识图谱

它能做什么

适合哪些使用场景

和 RAG 有什么区别

使用时要注意什么

小结

参考来源

Jimmy：把 Evernote、Notion、Google Keep 等笔记导出转换成 Markdown

Jimmy 解决什么问题

支持的笔记应用很多

也能转换普通文档

两种使用方式

它的几个特点

适合谁使用

使用前的检查建议

我的判断

Google Pay 与 Wallet 推出 Developer MCP Server：把支付集成接入 AI 助手

它解决什么问题

MCP 在这里为什么合适

对 AI 编程工作流的意义

它不会替代开发者判断

我的判断

Remotion：用 React 以编程方式生成视频

Remotion 解决的是什么问题

为什么是 React

快速开始

它适合哪些场景

个性化视频

技术演示视频

数据视频和图表动画

AI 生成视频工作流

对 AI 编程工具的意义

使用前要注意许可

我的判断

RTK：给 AI 编程代理省 token 的命令行代理工具

它解决的是什么问题

RTK 的基本工作方式

支持哪些命令

安装和接入方式

使用时要注意什么

适合谁用

我的判断

Codex 官方文章解读：如何把 Codex 用到极致

持久线程

语音输入

Steering 和 queuing

工具和可触达范围

从任何地方继续工作

自动化

Goals

侧边栏

共享记忆

从代码向外扩展

Codex Goal 设置目标失败：Failed to set goal 怎么处理

先检查 goals 功能开关

如果还有问题，检查配置目录

Windows 上还要留意安全软件

判断是不是 prompt 的问题

小结

oh-my-codex：给 Codex CLI 加上工作流、技能和运行时护栏

它到底是什么

推荐安装方式

默认工作流

skills 和 agents 提供了什么

插件形态和运行时状态

适合谁

使用时要注意什么

小结

参考资料

CLI-Anything：把软件变成 Agent 可用的命令行

它怎么工作

适合什么场景

需要注意的边界

小结

GitHub Spec Kit 是什么？用规格驱动开发约束 AI 编程

Spec Kit 是什么？

基本使用流程

它改变了 AI 编程的入口

`/speckit.constitution`

`/speckit.specify`

`/speckit.clarify`

`/speckit.plan`

`/speckit.tasks`

`/speckit.implement`