AI编程 on KnightLi的博客

Claude Opus 4.8 发布：Anthropic 继续强化编程与代理任务

Fri, 29 May 2026 15:22:47 +0800

Anthropic 在 2026 年 5 月 28 日发布 Claude Opus 4.8。这是 Opus 系列的新版本，官方定位很明确：不是一次换代式命名，而是在 Opus 4.7 基础上继续增强编程、代理任务、推理和专业知识工作能力。

这次更新对普通聊天用户当然有意义，但更值得关注的是 Claude Code 和长任务 agent 场景。Anthropic 把 Opus 4.8 描述成更可靠的协作者：在复杂任务里更能判断何时提问、何时推进、何时保守处理。

这次更新的重点

Claude Opus 4.8 已经上线，价格保持不变。官方同时强调了几项配套变化：

Opus 4.8 在代码、代理能力、推理和知识工作评测上相比前代继续提升。
claude.ai 用户可以控制 Claude 在任务上投入的 effort。
Claude Code 新增 dynamic workflows，用来处理更大规模的问题。
Opus 4.8 的 fast mode 可以以约 2.5 倍速度工作，并且比此前模型的 fast mode 便宜三倍。

这些变化放在一起看，Anthropic 不是只在模型分数上做小幅升级，而是在围绕“长时间执行复杂任务”改产品形态。模型更强只是其中一部分，任务控制、工作流拆解和成本结构同样重要。

为什么 Claude Code 用户更应该关注

Claude Code 这类编程 agent 最怕的不是单个函数不会写，而是在真实仓库里迷路。它需要读文件、理解依赖、跑测试、看错误、修改方案，再把修改控制在合理范围内。

Opus 4.8 的卖点正好贴近这些问题：

更适合 agentic tasks，也就是需要模型持续计划、调用工具、观察结果并调整策略的任务。
更强调 judgement，能在不确定时停下来确认，而不是一路自信地写错。
dynamic workflows 让 Claude Code 更适合处理大规模、多步骤的问题。

如果这些能力在真实项目里稳定，Claude Code 的使用方式会更接近“把一个明确目标交给它推进”，而不是只让它补一段代码。

effort 控制意味着什么

Anthropic 这次给 claude.ai 加入 effort 控制，含义很直接：用户可以调节模型在任务上花多少力气。

这对日常使用很实用。简单问题不需要深推理，复杂任务则值得让模型多想一会儿。过去很多用户只能靠提示词表达“认真一点”或“快速回答”，现在这种控制开始进入产品层。

对开发者来说，这也是一个信号：未来 agent 产品不会只暴露“选哪个模型”，还会暴露更多执行策略，比如速度、成本、推理深度、工具调用积极程度和风险偏好。

fast mode 的成本变化很关键

官方提到，Opus 4.8 的 fast mode 可以达到约 2.5 倍速度，同时成本比此前模型的 fast mode 低很多。

这件事容易被模型能力新闻盖过去，但它对实际工作流很重要。很多 agent 任务不是只跑一次，而是会反复执行：

生成初稿
跑测试
修复失败
再跑测试
根据 review 继续改

如果 fast mode 足够便宜，团队就更愿意把它放进高频流程里，而不是只在关键任务上偶尔使用顶级模型。速度和成本一旦下降，agent 才更容易从“演示效果”进入“日常工具”。

和 Opus 4.7 的关系

Opus 4.8 更像是一次面向可用性的增强版。它继承 Opus 4.7 的定位，但把重点继续推向编程、代理任务和专业工作。

从 Anthropic 的表述看，Opus 4.8 不只是回答更好，而是更会协作。它在任务中应该更清楚什么时候需要信息、什么时候方案不稳、什么时候应该先建立信心再做大改动。

这类能力很难只靠单一 benchmark 判断。真正的验证要看它在大型仓库、复杂业务规则、长上下文任务和多轮修复里的表现。

对 AI 编程竞争的影响

2026 年的模型竞争已经明显从“聊天能力”转向“能不能做事”。OpenAI、Anthropic、Google、xAI 都在把模型和工具链绑得更紧：模型负责推理，工具负责执行，产品层负责把任务保持在可控范围内。

Claude Opus 4.8 的发布延续了这个趋势。它的重点不是炫耀一个单点能力，而是强化三个环节：

模型本身更适合代码和代理任务。
Claude Code 能拆更大的工作流。
产品层开始提供 effort 和 fast mode 这类执行控制。

这对开发者的实际意义是，选择模型时不能只看“哪个最聪明”。还要看它是否适合所在工具、能否稳定调用工具、长任务成本是否可接受、失败时是否容易被纠正。

我的判断

Claude Opus 4.8 是一次偏务实的更新。它没有把叙事放在一个夸张的新参数上，而是继续补 agent 工作流最需要的东西：判断力、稳定性、速度、成本和任务控制。

如果你已经在使用 Claude Code，这次更新值得尽快试。尤其适合拿真实仓库里的长任务做对比，比如跨模块重构、测试修复、文档同步、复杂 bug 定位。

如果你只是普通聊天用户，Opus 4.8 的变化可能不会像新一代模型发布那样立刻震撼。但从产品方向看，它说明 Anthropic 仍在把 Claude 往“可靠执行复杂工作”的方向推。

原文链接：Introducing Claude Opus 4.8

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 功能本身是否在本地配置里正常启用。

Codex Goal 深度解析：让 AI Agent 连续工作数小时的目标驱动工作流

Tue, 26 May 2026 23:44:37 +0800

浏览器、终端和 IDE 里的 AI Agent 已经越来越会写代码了，但很多人真正遇到的问题不是“它不会做”，而是“它做了一半就说完成了”。

简单 ticket 很适合交给编程 Agent：修一个按钮、补一个接口、改一段文案、加一个测试。目标清楚，边界很小，验证方式也直接。但一旦任务变成大型迁移、跨模块重构、测试套件修复、依赖升级、prompt 评测优化，Agent 就很容易出现一种典型问题：

它完成了一个看起来合理的中间状态，然后过早停下。

Codex Goal / Persistent Goals 这类能力要解决的，正是这个“提前收工”问题。它的重点不是让 Agent 多跑几轮，而是让 Agent 围绕明确目标持续推进，直到满足可验证的完成标准。

Codex Goal 解决的不是循环，而是停止条件

很多长任务自动化会从一个粗糙方案开始：

`1`	`继续检查代码，修复问题，直到没有错误。`

或者更机械一点：

循环 10 次：
1. 运行测试
2. 让模型修复失败
3. 再运行测试

这类粗糙循环看起来能让 Agent 工作更久，但它有两个硬伤：

它不知道什么时候真的该停。
它也不知道“没有继续报错”是否等于“任务完成”。

Codex Goal 的关键不是循环次数，而是 goal、state、judge stop condition 三件事。也就是说，Agent 需要知道这次工作的目标是什么，当前已经完成到哪里，以及哪些证据能证明任务真的结束了。

这也是长任务 Agent 的核心分水岭：不是“多执行几步”，而是“能不能判断自己还差什么”。

Goal 和普通 prompt 的区别

普通 prompt 更像一次性指令：

`1`	`把这个项目的测试修好。`

Goal prompt 则更像一份小型任务合约：

目标：修复当前仓库中失败的测试。
范围：只修改 src/ 和 tests/，不要改构建脚本。
完成标准：npm test 全部通过，且新增修改不引入 lint 错误。
验证命令：npm test && npm run lint。
失败处理：如果超过 3 次仍无法修复，输出剩余失败用例、已尝试方案和阻塞点。
输出：总结修改文件、修复原因、验证结果。

两者最大的差别在于，Goal prompt 把“完成”定义清楚了。

如果没有清晰的完成定义，Agent 很容易把“我改了代码”误判成“我完成了任务”。如果有明确的完成标准，Agent 就必须围绕测试、日志、diff、构建结果、eval 分数这些外部证据继续推进。

为什么 LLM judge stop condition 很关键

长任务里最难的不是让 Agent 执行命令，而是让它判断：

现在是否真的完成了？
是否只是通过了局部测试？
是否修了一个问题，却引入了另一个问题？
是否需要继续搜索、继续运行验证、继续回滚某个方向？

这就是 LLM judge stop condition 的价值。

理想状态下，Agent 不应该只看“最后一个命令是否退出码为 0”。它还应该综合判断：

用户给出的完成标准是否全部满足；
修改是否限定在允许范围内；
测试、lint、build、eval 是否都跑过；
失败日志是否还有未处理项；
是否存在明显的副作用和风险；
最终输出是否能让人类快速复核。

换句话说，judge 不只是“判定成功”，还要防止 Agent 自我安慰式收尾。

哪些任务适合交给 Goal

Codex Goal / Persistent Goals 更适合那些需要多轮探索和验证的复杂编程任务，例如：

代码迁移：从旧框架迁到新框架，从 CommonJS 迁到 ESM，从旧 API 迁到新 API。
大型重构：拆分模块、整理边界、替换重复实现、降低复杂度。
测试修复：连续分析失败用例，定位原因，修复后反复验证。
依赖升级：升级框架、SDK、构建工具，同时处理破坏性变更。
Prompt 评测优化：运行评测，分析失败样本，调整 prompt 或工具调用策略。
技术债清理：围绕明确规则逐步替换旧写法，并保持行为不变。

这些任务的共同点是：中间状态很多，失败原因不一定一次能看清，完成标准必须依赖验证结果。

哪些任务不适合只靠 Goal

Goal 并不是万能的。下面这些任务如果只靠一个长提示词，风险会很高：

目标非常模糊，例如“把产品增长做好”。
周期很长，例如连续几周的 SEO、GEO、广告投放优化。
需要跨系统调度，例如同时处理内容、数据、投放、客服和业务指标。
涉及生产风险，例如数据库变更、线上配置、财务操作、账号权限调整。
缺少验证手段，例如没有测试、没有指标、没有日志、没有人工验收标准。

这类任务更像 Mission，而不是 Goal。

Goal 适合小时级到一两天的深度执行。Mission 则需要状态、历史、调度、人类审批、阶段性复盘和长期指标。比如 SEO / GEO / Ads 优化，不能只是让 Agent 循环写内容或调参数，还要持续记录策略、实验、数据变化和下一步计划。

写好 Goal Prompt 的模板

一个好用的 Goal prompt，至少应该包含下面几块内容：

目标：
用一句话说明最终要达成什么结果。

背景：
说明当前问题、相关文件、业务约束、已有尝试。

范围：
允许修改哪些目录、文件、模块；哪些地方不要碰。

完成标准：
列出可验证的 definition of done。

验证命令：
写清楚需要运行的测试、lint、build、eval 或脚本。

失败策略：
如果无法完成，要求 Agent 输出失败原因、已尝试方案、剩余阻塞点。

风险边界：
禁止破坏性操作，生产配置、密钥、数据库、外部服务需要人工确认。

交付格式：
要求总结修改点、验证结果、风险和后续建议。

真正决定长任务效果的，往往不是 prompt 写得多漂亮，而是完成标准是否足够明确、足够可验证。

Goal Buddy 的价值：先帮你把任务说清楚

很多长任务失败，不是因为 Agent 能力不够，而是因为人类一开始没有把任务拆清楚。

Goal Buddy 这类辅助工具的价值在于：在正式把任务交给 Agent 之前，先帮你准备目标、边界、完成标准和验证方式。它像一个任务预检器，会追问：

这个任务的最终可见结果是什么？
哪些目录可以改，哪些不能改？
成功后跑什么命令证明？
失败时要不要继续尝试，最多尝试到什么程度？
是否需要分阶段提交？
哪些操作必须让人类确认？

这一步看似啰嗦，但它能显著减少 Agent 中途跑偏、过早停止，或改出一堆难以复核的代码的概率。

给 Codex、Claude Code、OpenCode 用户的实践建议

如果你正在用 Codex、Claude Code、OpenCode、OpenClaw 或类似编程 Agent，可以按下面方式处理长任务：

先提交当前工作区，保证有干净回滚点。
把任务写成 Goal，而不是一句泛泛的需求。
明确允许修改的范围和禁止修改的范围。
给出验证命令，最好让 Agent 每一轮都能自己运行。
要求 Agent 在无法完成时报告阻塞点，而不是硬编一个“完成”。
对高风险操作设置人工确认，例如删除文件、改数据库、改部署配置。
最后只接受带有测试结果和修改总结的交付。

长任务 Agent 的正确使用方式，不是“让它自己随便干一晚上”，而是给它一个清楚的目标、坚实的护栏，以及可验证的出口。

小结

Codex Goal / Persistent Goals 的意义在于，把编程 Agent 从“执行一句指令”推进到“围绕一个目标持续工作”。

它最适合复杂但边界明确的工程任务：迁移、重构、测试修复、依赖升级、评测优化。它不适合完全模糊、周期很长、缺少验证标准的业务任务；那些更应该设计成 Mission 系统。

未来 AI Agent 的竞争点，很可能不只是模型会不会写代码，而是能不能围绕目标持续推进、正确判断停止时机，并把过程留给人类复核。

参考：

Ollama 接入 Codex App：本地大模型如何变成 AI 编程 Agent

Tue, 26 May 2026 23:35:01 +0800

Ollama 最近把本地大模型和 AI 编程工具之间的距离又拉近了一步：通过 ollama launch codex-app，用户可以把 Codex App 接到 Ollama 管理的本地或云端模型上。

这件事的意义不只是“换一个模型后端”。它更像是把本地大模型从聊天窗口推到开发工作流里：模型不再只是回答问题，而是可以进入代码项目、理解文件结构、辅助修改代码、运行任务，成为 AI 编程 Agent 的一部分。

先澄清：这不是 OpenAI 全功能永久免费

网上很多说法会把这件事概括成“Codex 免费了”。这个说法容易误解。

更准确的理解是：

Codex App 是 OpenAI 的 AI 编程工具；
Ollama Launch 可以帮助 Codex App 使用 Ollama 模型；
模型可以是本地模型，也可以是 Ollama 的云端模型；
如果使用本地模型，推理成本主要变成自己的硬件、电费和时间，而不是按 API token 计费；
Codex App、OpenAI 账号权益、不同模型可用性和官方限制，仍然要以 OpenAI 与 Ollama 的当前规则为准。

所以它不是“所有 Codex 能力都永久免费”，而是多了一条本地化路线：让 AI 编程 Agent 可以不完全依赖 OpenAI API、Claude API 或 Gemini API。

`ollama launch codex-app` 做了什么？

Ollama 官方文档里，Codex App 的接入命令很简单：

`1`	`ollama launch codex-app`

如果想指定模型，可以写成：

`1`	`ollama launch codex-app --model gpt-oss:120b`

也可以只生成配置，不马上启动：

`1`	`ollama launch codex-app --config`

如果想恢复原来的 Codex 配置：

`1`	`ollama launch codex-app --restore`

它的价值在于减少手动配置成本。过去要让一个 AI 编程工具接入本地模型，经常要自己改环境变量、OpenAI-compatible endpoint、config.toml、模型名和 profile。现在 Ollama Launch 把这些步骤包装成一个更直接的流程。

为什么本地模型接入 Agent 很重要？

以前本地大模型最常见的用法是聊天：

写一段文案；
回答一个问题；
解释一段代码；
做简单补全；
总结文档。

这些都很有用，但还停留在“问答工具”的层面。

AI 编程 Agent 的区别在于，它面对的是一个真实项目。它需要读目录、看文件、理解报错、修改代码、运行命令、检查结果，再继续迭代。也就是说，它不是只输出答案，而是参与执行任务。

当本地模型接入 Codex App、Claude Code、OpenCode、Aider、OpenHands 这类工具时，本地 AI 的角色就变了：

可以扫描项目结构；
可以定位 Bug；
可以改文件；
可以生成新页面或小游戏；
可以解释和重构代码；
可以在开发循环里反复执行、验证、修正。

这也是本地大模型从“能聊”走向“能干活”的关键一步。

本地 Agent 的优势

1. 成本更可控

大型项目很容易消耗大量 token。一次项目扫描、长上下文分析、多轮修复，放在云端模型上可能很快积累费用。

本地模型虽然也有成本，比如显卡、内存、电费和时间，但它不会按 token 直接收费。对于大量试错、个人项目、离线实验，本地路线更适合慢慢折腾。

2. 可以离线工作

如果模型、工具和依赖都已经在本机准备好，本地 Agent 在很多场景下可以断网继续工作。它可以读本地代码、分析项目、修改文件、生成页面或脚本。

当然，涉及联网搜索、下载依赖、访问在线 API 的任务仍然需要网络。但基础代码分析和本地项目修改，不一定非要依赖云端模型。

3. 隐私边界更清楚

很多代码库、内部文档、实验项目并不适合直接发给云端模型。把模型放在本地，可以减少代码内容离开机器的机会。

这不代表本地路线天然安全。Agent 仍然可能执行命令、改文件、访问敏感路径，所以权限、沙箱、Git diff review 仍然很重要。但至少在模型推理层面，本地化给了用户更多控制权。

模型怎么选？

Ollama 的官方 ollama launch 文档建议，代码类工具最好使用较大的上下文窗口，推荐至少 64K tokens。原因很简单：AI 编程任务经常需要同时读项目结构、多个文件、报错日志、需求说明和历史修改。

本地模型可以从这些方向尝试：

qwen3-coder：偏代码任务；
gpt-oss:20b：适合本地尝试；
glm-4.7-flash：Ollama 官方推荐的 coding 模型之一；
更大的云端模型：如果本地硬件不够，可以用 Ollama cloud 模型换取更完整上下文。

中文场景下，Qwen 系列仍然值得优先尝试。它在中文理解、代码生成、推理和本地生态适配上都比较成熟。

硬件门槛没有想象中那么高

很多人一提到 AI Agent，就默认需要 RTX 4090、24GB 显存、甚至企业级 GPU。

实际情况更灵活。小模型、量化模型、MoE 模型、KV cache 量化和 CPU/GPU 混合 offload 让 6GB、8GB、12GB 显存机器也能做不少事情。

当然，低显存机器不适合追求极致体验：

速度会慢；
上下文不能太大；
大项目扫描会吃力；
多并发基本不现实；
模型质量和 100B+ 云端模型仍有差距。

但如果目标是个人项目、脚本修复、简单前端页面、小游戏、代码解释、离线实验，本地模型已经足够进入“可用”阶段。

也可以用 llama.cpp 接 OpenAI-compatible 接口

除了 Ollama，另一条常见路线是用 llama.cpp 的 llama-server 提供本地 OpenAI-compatible API，再让 AI 编程工具连接到本地端口。

一个典型的 llama.cpp 启动命令类似这样：

llama-server.exe ^
 -m "models\Qwen3.6-27B-UD-Q5_K_XL.gguf" ^
 -ngl 999 ^
 -c 16384 ^
 -n 2048 ^
 -fa on ^
 --jinja ^
 --host 127.0.0.1 ^
 --port 8080

然后在工具配置里把模型 provider 指向：

[model_providers.llamacpp]
name = "llama.cpp"
base_url = "http://127.0.0.1:8080/v1/"
wire_api = "responses"

这条路线更灵活，但也更折腾。Ollama Launch 的优势是简单；llama.cpp 的优势是可控参数更多，适合想细调显存、上下文、量化和推理后端的用户。

使用本地 AI Agent 时要注意什么？

本地不等于无风险。Agent 能改文件、跑命令、创建项目，就意味着它也可能误删文件、改错代码、执行不该执行的操作。

建议：

在 Git 仓库里操作，确保随时能看 diff 和回滚。
不要给 Agent 过大的系统权限。
先在测试项目里试，不要直接扔生产代码库。
重要文件修改前后都要人工 review。
不要把密钥、账号、生产环境配置暴露给 Agent。
本地模型能力有限，复杂架构决策不要完全交给它。

把本地 Agent 当成“会执行任务的助手”，而不是“完全可靠的工程师”，体验会更健康。

我的理解

Ollama 接入 Codex App 的意义在于，它把本地模型真正接进了 AI 编程工作流。

过去，本地模型更多是一个聊天框；现在，它开始能进入项目、读代码、改文件、跑任务。这个变化会让很多普通开发者重新评估手里的电脑：也许不需要最贵的显卡，也能先搭起一个低成本、可离线、可控的 AI 编程环境。

云端模型仍然强，特别是在复杂推理、大上下文、多模态和长任务稳定性上。但本地模型正在补上“执行工具”这一块。

未来的 AI 编程，很可能不是纯云端或纯本地，而是混合形态：

小任务、本地代码、隐私项目交给本地模型；
高难推理、大上下文、跨系统任务交给云端模型；
Ollama、Codex App、Claude Code、OpenCode 这类工具负责把两边接到同一个工作流里。

这才是本地 AI Agent 真正值得关注的地方。

参考链接

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

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 编程工具的关键分水岭。

参考链接

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 调用口还高。把它放在可信网络里，用认证保护好，再去享受可视化管理带来的省心。

参考资料：

让 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

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

GitHub AI 开源项目分类整理：从 Coding Agent 到 RAG 知识库

Thu, 21 May 2026 08:53:13 +0800

这里按应用方向列出 GitHub AI 项目，覆盖 AI 编程与 Coding Agent、Agent 技能与工作流、RAG 与知识库、多模态创作、本地模型与推理、垂直应用与自动化、AI 应用开发基础设施等方向。后续新增项目时，也可以继续按这个结构补充。

分类合计

分类	项目数	适合先看的人
AI编程与 Coding Agent	22	经常使用 Claude Code、Codex、Cursor、终端 Agent 或代码库自动化的人
Agent 技能与工作流	7	想把 AI 编程、科研、创作流程标准化的人
RAG、知识库与记忆	7	需要文档检索、知识库、长期记忆、网页抓取和结构化抽取的人
垂直应用与自动化	7	想看金融、交易、闲鱼监控、桌面操作、浏览器自动化等落地场景的人
多模态与内容创作	5	做图片、视频、语音转写、提示词库和内容分发的人
AI 应用开发基础设施	5	构建 AI 应用、浏览器自动化、Prompt/MCP 工具链的人
本地模型与推理	1	关心本地 DeepSeek、推理引擎和硬件适配的人

这个分布可以看出当前 AI 开源项目的几个高频方向：AI 编程工具明显最多，其次是 Agent 工作流、RAG 知识库和具体应用场景。纯模型推理项目数量不多，因为很多本地部署内容并不是单独介绍某个 GitHub 项目，而是围绕模型、显卡或部署方案展开。

AI编程与 Coding Agent

这一类聚焦代码理解、代码修改、工程流程和终端 Agent，是数量最多的一组。共 22 个项目。

项目	文章	GitHub	核心用途	适合人群
Ralph	Ralph 是什么：把 Claude Code 和 Amp 变成可循环执行的自主开发流程	snarktank/ralph	让 Claude Code / Amp 按 PRD、计划、执行、评审循环推进任务	想把 Agent 编程流程拉直的人
Claude-Mem	Claude-Mem：给 Claude Code 加上跨会话长期记忆	thedotmack/claude-mem	为 Claude Code 增加跨会话记忆	高频使用 Claude Code 的开发者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13 个 Hooks 生命周期与自动化控制入门	disler/claude-code-hooks-mastery	学习 Claude Code Hooks 生命周期和自动化控制	想定制 Claude Code 流程的人
Compound Engineering Plugin	Compound Engineering Plugin：把 AI 编程变成计划、执行、评审的工程循环	EveryInc/compound-engineering-plugin	把 AI 编程拆成计划、执行、评审循环	关注工程化 AI 编程的人
free-claude-code	free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型	Alishahryar1/free-claude-code	通过代理把 Claude Code 接到不同模型后端	想降低 Claude Code 使用成本的人
Hermes Agent	Hermes Agent 是什么：简介、优点、快速上手与 OpenClaw 对比	NousResearch/hermes-agent	本地 Agent 框架，支持工具调用和任务执行	想跑本地 Agent 的用户
OpenHarness	OpenHarness 是什么：这个开源 Agent Harness 能做什么	HKUDS/OpenHarness	Agent Harness 与多 Agent 执行框架	研究 Agent 编排的人
CodexBridge	Codex 怎么接入国产大模型？OpenAI 兼容接口与 CodexBridge 使用思路	begonia599/CodexBridge	帮 Codex 接入 OpenAI 兼容模型接口	想把 Codex 接到国产模型的人
ccx	Codex 怎么接入国产大模型？用 CCX 统一管理 OpenAI 兼容 API	BenedictKing/ccx	统一管理 Claude、Codex、Gemini 等 API 代理	多模型切换用户
cc-haha	cc-haha 是什么？一个把 Claude Code 做成桌面工作台的项目	NanmiCoder/cc-haha	Claude Code 桌面工作台与 Computer Use 入口	喜欢图形界面的 Claude Code 用户
DeepSeek-TUI	DeepSeek-TUI：把 DeepSeek V4 变成终端里的编程智能体	Hmbown/DeepSeek-TUI	在终端里运行 DeepSeek 编程 Agent	DeepSeek 与命令行用户
Open Design	Open Design 项目解析：把 Claude Code、Codex 变成 AI 设计工具	nexu-io/open-design	让 Claude Code / Codex 参与设计生成	想用 Agent 做设计原型的人
agentmemory	agentmemory 项目解析：给 Claude Code、Codex 和 Cursor 加持久记忆	rohitg00/agentmemory	给 Coding Agent 增加持久记忆层	长期维护项目的开发者
Graphify	Graphify 解决 Claude Code 最大局限：把代码库变成 AI 可查询知识图谱	safishamsi/graphify	把代码库转成知识图谱，降低 Agent 重复读文件成本	大型代码库用户
oh-my-pi	oh-my-pi 是什么？一个把终端、IDE 和调试器打通的 AI 编程助手	can1357/oh-my-pi	把终端、IDE、LSP 和调试器连接起来，作为本地 AI 编程控制台	想把命令行和 IDE 工作流打通的开发者
Claude Plugins Official	Claude Code 也有插件市场了：能装什么、怎么装、要注意什么	anthropics/claude-plugins-official	Claude Code 官方插件目录和安装入口	想给 Claude Code 扩展能力的用户
CodeGraph	CodeGraph 是什么？给 Claude Code、Codex 和 Cursor 加一个本地代码地图	colbymchenry/codegraph	为代码库生成本地索引和关系图，帮助 Coding Agent 理解项目	维护中大型代码库的开发者
CC Switch	CC Switch：一个桌面工具统一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw	farion1231/cc-switch	管理多个 AI CLI 工具和账号/配置切换	同时使用多套 CLI 的人
Warp	Warp 开源：从终端到 Agentic Development Environment	warpdotdev/warp	Agentic 终端与开发环境	终端重度用户
opencode	opencode、Claude Code、Codex 有什么区别？开源 AI 编程工具使用指南	anomalyco/opencode	开源 AI 编程 Agent	想找 Claude Code / Codex 替代品的人
9Router	9Router：把 Claude Code、Codex、Cursor 接到同一个 AI 路由器	decolua/9router	AI 编程模型路由与 token 成本控制	多工具、多模型用户
goose	goose：桌面端、CLI 和 API 一体的开源 AI Agent	aaif-goose/goose	桌面、CLI、API 一体的开源 Agent	想要通用 Agent 工作台的人

Agent 技能与工作流

这一类更关注把 AI 能力固化成可重复的技能、流程和规格。共 7 个项目。

项目	文章	GitHub	核心用途	适合人群
mattpocock/skills	拒绝 Vibe Coding：Matt Pocock 的 skills 仓库给 AI 编程补上工程约束	mattpocock/skills	用 Skills 约束 AI 编程流程	想给 Agent 加工程规范的人
Superpowers	Superpowers：把 Coding Agent 拉回工程流程的技能框架	obra/superpowers	Agentic skills framework 与软件开发方法论	想系统化使用 Coding Agent 的人
Prompt-Vault	Prompt-Vault：一个适合测试 AI 编程能力的 Prompt 规格库	w512/Prompt-Vault	收集可测试 AI 编程能力的 prompt 规格	做模型/工具评测的人
web-video-presentation	web-video-presentation：把文章做成可录屏网页视频的 Agent Skill	ConardLi/garden-skills	把文章转成可录屏网页视频的 Skill	内容创作者和自动化制作用户
nuwa-skill	nuwa-skill：把“蒸馏一个人”从灵感变成可执行流程	alchaincyf/nuwa-skill	用 Skill 复刻人物表达和思维流程	做风格化 Agent 的人
Scientific Agent Skills	Scientific Agent Skills：把科研工作流交给 AI Agent 的技能库	K-Dense-AI/scientific-agent-skills	科研工作流 Skill 集合	科研、数据分析和技术写作用户
easy-vibe	easy-vibe：给 Vibe Coding 初学者的一张学习地图	datawhalechina/easy-vibe	Vibe Coding 入门学习地图	AI 编程新手

RAG、知识库与记忆

这一类主要解决文档检索、知识库构建、长期记忆和结构化抽取问题。共 7 个项目。

项目	文章	GitHub	核心用途	适合人群
LangExtract	Google LangExtract：用 LLM 从长文本里抽取结构化数据	google/langextract	从长文本中抽取结构化信息	做信息抽取和数据处理的人
qmd	qmd：给 AI Agent 使用的本地 Markdown 文档搜索工具	tobi/qmd	本地 Markdown 文档搜索	用 Markdown 管理知识库的人
Firecrawl	Firecrawl 项目整理：给 AI Agent 用的网页搜索、抓取与交互 API	firecrawl/firecrawl	网页抓取、搜索和结构化数据入口	做 RAG 和 Agent 数据入口的人
RAGFlow	RAGFlow 项目整理：开源 RAG 引擎的功能与使用方法	infiniflow/ragflow	开源 RAG 引擎	企业知识库和文档问答用户
OpenHuman	OpenHuman 速读：开源个人 AI Agent 的桌面化路线	tinyhumansai/openhuman	本地优先的个人 AI Agent 与记忆层	想整合个人数据的人
OpenKB	OpenKB：把文档编译成可持续更新的 LLM 知识库	VectifyAI/OpenKB	把文档编译成可更新知识库	文档知识库维护者
PageIndex	PageIndex 是什么？不用向量库的推理式 RAG 文档索引解析	VectifyAI/PageIndex	不依赖向量库的推理式文档索引	关注 RAG 新路线的人

多模态与内容创作

这一类面向图片、视频、语音转写和内容分发等创作场景。共 5 个项目。

项目	文章	GitHub	核心用途	适合人群
rembg	rembg 项目整理：本地图片背景移除工具	danielgatis/rembg	本地图片背景移除	电商、美工和图片处理用户
awesome-gpt-image-2-prompts	GPT-Image 2 提示词宝库：电商、海报、人像、UI 全收录	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2 提示词和案例库	AI 绘图和提示词用户
faster-whisper	faster-whisper：更快的 Whisper 转写引擎	SYSTRAN/faster-whisper	高性能语音转文字	做字幕、转写和语音处理的人
Pixelle-Video	Pixelle-Video：一句主题生成短视频的开源 AI 引擎	AIDC-AI/Pixelle-Video	一句话生成短视频工作流	短视频和 AIGC 内容创作者
AiToEarn	内容发太多平台太累？AiToEarn 想用 AI Agent 帮创作者省点事	yikart/AiToEarn	多平台内容分发与创作者自动化	内容运营和创作者

本地模型与推理

这一类关注本地模型运行和推理实验，当前数量较少。共 1 个项目。

项目	文章	GitHub	核心用途	适合人群
ds4	本地运行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的尝试	antirez/ds4	在 Apple Silicon 上尝试运行 DeepSeek 4	本地模型和推理实验用户

垂直应用与自动化

这一类是把 Agent 或 AI 能力落到金融、交易、浏览器、桌面和电商监控等具体场景。共 7 个项目。

项目	文章	GitHub	核心用途	适合人群
TradingAgents-CN	TradingAgents-CN：面向中文用户的多智能体金融交易研究框架	hsliuping/TradingAgents-CN	多智能体金融交易研究框架	量化、金融和 Agent 研究者
FinceptTerminal	FinceptTerminal：开源金融终端、量化研究和 AI Agent 工作台	Fincept-Corporation/FinceptTerminal	金融终端、量化研究和 AI Agent 工作台	金融分析和量化用户
Anthropic financial-services	Anthropic financial-services：把金融 Agent 场景做成可复用模板	anthropics/financial-services	金融服务 Agent 模板	做金融 AI 方案的人
ai-goofish-monitor	ai-goofish-monitor：用 AI 自动盯闲鱼商品的开源监控系统	Usagi-org/ai-goofish-monitor	AI 商品监控和闲鱼自动化	二手交易监控用户
CloakBrowser	CloakBrowser 是什么？给 Playwright 和 Puppeteer 换一个更像真实用户的浏览器	CloakHQ/CloakBrowser	更像真实用户的浏览器自动化环境	浏览器自动化和 Agent 操作场景
UI-TARS-desktop	让 AI 自己操作电脑？UI-TARS-desktop 把桌面、浏览器和工具都接了起来	bytedance/UI-TARS-desktop	桌面、浏览器和工具操作 Agent	想让 AI 操作电脑的人
AI-Trader	AI-Trader 是什么？一个让 AI Agent 发布交易信号、做模拟交易的平台	HKUDS/AI-Trader	AI Agent 交易信号和模拟交易平台	金融 Agent 与交易研究用户

AI 应用开发基础设施

这一类提供构建 AI 应用和 Agent 工具链所需的基础组件。共 5 个项目。

项目	文章	GitHub	核心用途	适合人群
Prompt Optimizer	Prompt Optimizer：开源提示词优化、测试与 MCP 工具	linshenkx/prompt-optimizer	提示词优化、测试和 MCP 工具	做 prompt 工程和应用调参的人
Playwright CLI	Playwright CLI 使用入门：安装、Skills、会话管理与常用命令	microsoft/playwright-cli	面向 coding agent 的浏览器自动化 CLI	需要浏览器操作能力的 Agent 用户
Vercel AI SDK	Vercel AI SDK 是什么？TypeScript 开发者构建 AI 应用的统一工具包	vercel/ai	TypeScript AI 应用开发 SDK	前端和全栈开发者
CLIProxyAPI	CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 统一封装成 API	router-for-me/CLIProxyAPI	把多个 AI CLI 和 OAuth 登录态封装成兼容 API	想统一接入 Codex、Claude Code、Gemini CLI 的用户
CLIProxyAPI Management Center	CLIProxyAPI Management Center：给 CLIProxyAPI 配一个可视化管理后台	router-for-me/Cli-Proxy-API-Management-Center	CLIProxyAPI 的 Web 管理界面，管理配置、账号、日志和 OAuth	把 CLIProxyAPI 当团队网关或账号池使用的人

Graphify 解决 Claude Code 最大局限：把代码库变成 AI 可查询知识图谱

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify 是一个面向 AI 编程助手的知识图谱工具。它的目标很直接：把一个项目目录里的代码、文档、SQL schema、脚本、论文、图片、视频和音频，整理成可查询的知识图谱，让 AI 助手不再只靠 grep、全文阅读或临时搜索来理解项目。

项目地址：safishamsi/graphify

截至本文整理时，GitHub 页面显示项目约有 50.2k stars、5.4k forks，许可证为 MIT。README 对它的描述是：在 AI 编程助手里输入 /graphify，它就会把整个项目映射成一个可以查询的知识图谱。

它解决的核心问题

AI 编程助手越来越强，但在真实代码库里仍然经常遇到几个问题：

不知道关键模块之间怎么连接。
读了很多文件，但没形成整体架构地图。
搜索命中了文本，却不知道上下游依赖。
代码、数据库 schema、文档和基础设施配置分散在不同地方。
多人协作时，每个人对项目结构的理解不一致。

Graphify 想做的是给项目生成一层“记忆层”。它把代码实体、文档概念、数据库表、配置、设计说明和跨文件关系连接起来，让 AI 助手可以按图谱查询，而不是每次从零开始扫文件。

最小使用方式

Graphify 的最小用法非常简单。安装后，在 AI 编程助手里输入：

`1`	`/graphify .`

在 PowerShell 里要注意，前导 / 会被当成路径分隔符，所以 Windows PowerShell 下应使用：

`1`	`graphify .`

运行后会生成 graphify-out/ 目录，核心文件包括：

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

这三个文件分工不同：

graph.html：浏览器里打开的交互式图谱，可以点击节点、过滤和搜索。
GRAPH_REPORT.md：项目亮点、关键概念、意外连接和推荐问题。
graph.json：完整图谱，后续可以直接查询，不必重新读所有文件。

如果想生成更可读的架构页面和 Mermaid 调用流图，可以运行：

`1`	`graphify export callflow-html`

安装和平台支持

Graphify 的 PyPI 包名是 graphifyy，注意是双 y。README 特别提醒，PyPI 上其他 graphify* 包并不属于该项目，但 CLI 命令仍然叫 graphify。

推荐安装方式是：

`1`	`uv tool install graphifyy`

也可以使用：

1
2

pipx install graphifyy
pip install graphifyy

安装后注册到 AI 助手：

`1`	`graphify install`

项目支持的平台很多，包括 Claude Code、Codex、OpenCode、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Cursor、Gemini CLI、Kimi Code、Kiro、Google Antigravity 等。不同平台可以用不同安装命令，例如：

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codex 用户还需要在 ~/.codex/config.toml 的 [features] 下加入：

`1`	`multi_agent = true`

README 也说明，Codex 使用 $graphify，不是 /graphify。

它能处理哪些文件

Graphify 覆盖的输入类型很广。

代码方面，它支持 31 种语言，包括 Python、TypeScript、JavaScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、SQL、Shell、JSON 等。

文档方面，它支持：

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

还可以通过可选依赖扩展更多类型：

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

其中，pdf 用于 PDF 提取，office 用于 .docx 和 .xlsx，video 用于视频和音频转写，mcp 用于 MCP stdio server，neo4j 用于推送到 Neo4j，sql 用于 SQL schema 提取。

生成的报告有什么价值

GRAPH_REPORT.md 不是普通摘要，它会把项目里更值得 AI 助手关注的关系挑出来。

README 里提到的报告内容包括：

God nodes：项目里连接最多的核心概念。
Surprising connections：跨文件、跨模块的意外连接。
The why：从注释、docstring、设计文档里提取出的设计理由。
Suggested questions：图谱特别适合回答的问题。
Confidence tags：关系会标记为 EXTRACTED、INFERRED 或 AMBIGUOUS。

这点很关键。普通搜索只能告诉你“哪里出现了这个词”，而图谱可以回答“这个概念和哪些模块、配置、表、文档有关”。对大型代码库来说，这比单纯全文检索更接近架构理解。

常用命令

Graphify 的常见命令包括：

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

也可以把论文或视频加入图谱：

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

如果要做 PR 辅助分析，还可以使用：

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

这类命令适合代码评审场景：看 PR 影响了哪些图谱社区、是否和其他 PR 有冲突风险、哪些 review queue 更值得优先处理。

和 MCP、Neo4j、CI 的关系

Graphify 不只是生成 HTML 图。它也可以把图谱暴露给 AI 助手反复调用。

例如可以启动 MCP server：

`1`	`python -m graphify.serve graphify-out/graph.json`

MCP server 提供的能力包括 query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs 等。

它也支持 Neo4j 导出或推送：

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

团队协作上，README 建议可以提交 graphify-out/，让团队每个人拉取后都能共享同一份项目地图。还可以运行：

`1`	`graphify hook install`

这样每次 git commit 后自动重建图谱，并设置 merge driver，避免 graph.json 在多人并行提交时留下冲突标记。

隐私和成本要怎么看

Graphify 的 README 对隐私边界写得比较清楚。

代码文件会通过 tree-sitter 在本地解析，不会发出 API 调用。视频和音频可以通过 faster-whisper 本地转写。文档、PDF、图片这类语义提取内容，则会通过你的 AI 助手模型 API 处理。

如果用 headless graphify extract，可能需要设置这些环境变量：

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

本地 Ollama、AWS Bedrock、Claude Code CLI 等也可以作为 backend。README 还写明项目没有 telemetry、usage tracking 和 analytics。

实际使用时要注意：代码本地解析不等于所有内容都不出网。涉及文档、PDF、图片或云端模型时，仍然要看 backend、API key、企业合规和数据边界。

适合哪些场景

Graphify 适合几类用户：

想让 Claude Code、Codex、Cursor、Gemini CLI 更懂项目结构的开发者。
需要快速理解大型陌生代码库的人。
需要把代码、SQL schema、文档、配置放在一起分析的团队。
做架构审查、PR review、重构影响分析的人。
希望把项目知识暴露成 MCP 工具给 Agent 使用的人。
想为团队保留“项目地图”的技术负责人。

它不一定适合所有项目。小型脚本、一次性 demo、结构非常简单的仓库，用普通搜索和 README 可能已经够用。Graphify 的价值更容易出现在模块多、文档多、团队协作多、AI 助手频繁参与开发的大项目里。

小结

Graphify 的意义在于，它把 AI 编程助手的上下文从“临时读取文件”推进到“长期可查询的项目知识图谱”。

对开发者来说，它不是替代 IDE、搜索或 LSP，而是给 AI 助手补一层结构化记忆：哪些模块重要、哪些概念连接紧密、哪些文档解释了设计理由、某个 PR 会影响哪些社区。随着 Codex、Claude Code、Gemini CLI、Antigravity 这类 Agent 工具继续普及，这类“项目图谱层”会越来越有用。

参考来源：

GitHub：safishamsi/graphify

Gemini 3.5 正式发布：Flash 先行，Google 把重点放在 Agent 和长任务执行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式发布 Gemini 3.5 系列。第一款开放使用的是 Gemini 3.5 Flash，定位不是单纯的聊天模型，而是面向 Agent、代码生成和长时间复杂任务执行的模型。

从这次公告看，Google 对 Gemini 3.5 的叙事很明确：模型不只要回答问题，还要能规划、执行、检查，并在多步任务中持续推进工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已经面向多类用户开放：

普通用户可以通过 Gemini 应用和 Google 搜索中的 AI 模式体验。
开发者可以通过 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企业用户可以通过 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同时提到，Gemini 3.5 Pro 仍在开发中，已经在 Google 内部使用，计划在下个月推出。

这说明 3.5 系列会继续保留 Flash 与 Pro 的分层：Flash 更强调速度、成本和可规模化执行，Pro 则更可能面向更复杂、更高能力需求的场景。

重点是 Agent 和代码任务

Google 把 Gemini 3.5 Flash 称为目前最强的 Agent 与代码编写模型之一。公告中提到，它在多项代码和 Agent 基准测试中超过 Gemini 3.1 Pro 的部分成绩，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

这些指标本身不是普通用户最需要关心的内容。更重要的是，Google 正在把模型能力往“可执行工作流”上集中：不仅能写代码，还能处理旧项目迁移、复杂应用开发、财务报表整理、数据分析和持续测试。

在 Antigravity 开发架构中，Gemini 3.5 Flash 可以通过多个协作子代理处理大型任务。Google 展示的例子包括解析 AlphaZero 论文并实现可玩的游戏、把旧版代码转换为 Next.js、并行生成城市景观和 UI 方案。

这类能力的方向很清楚：AI 编程工具正在从“生成一段代码”走向“组织多个 Agent 完成一个项目”。

多模态 UI 与图形能力增强

Gemini 3.5 Flash 继承了 Gemini 3 的多模态基础。Google 强调它可以生成更丰富的网页 UI、交互动画和图形内容。

公告中给出的应用场景包括：

为研究论文生成交互式动画。
根据文字描述生成交互式硬件模型。
为学校募款活动生成完整品牌概念。
在短时间内为结账流程生成多种 UX 方案。

这部分对开发者和产品团队很有意义。模型不再只是输出文字说明，而是能参与前端原型、交互设计和可视化内容生成。

企业场景：把耗时流程自动化

Google 在公告中列举了多个合作伙伴案例。Shopify 使用子代理分析复杂数据并预测商家增长；Macquarie Bank 测试用 3.5 Flash 阅读超过 100 页的复杂文件，加速开户流程；Salesforce 将其整合到 Agentforce；Ramp 用它改进复杂发票 OCR；Xero 用 AI 代理处理行政流程；Databricks 用自动化工作流监控数据异常并给出修复建议。

这些案例共同指向一个趋势：企业采用大模型时，关注点正在从单次问答转向流程自动化。模型是否便宜、快、能长时间稳定执行，会比单次回答是否惊艳更重要。

Gemini Spark：个人 AI 代理

Google 还公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驱动的个人 AI 代理，目标是在用户引导下长期运行并主动执行任务。

Gemini Spark 已经开始面向受信任测试人员推出，Google 计划在下周向美国 Google AI Ultra 订阅用户开放 Beta 测试。

这部分值得关注。Google 搜索、Gemini 应用、Android、Workspace 和浏览器生态本来就覆盖大量个人数字生活场景。如果个人 Agent 能与这些入口结合，影响可能比单独的聊天机器人更大。

安全机制继续前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 开发，并强化了信息安全和 CBRN 相关防护。公告还提到使用可解释性工具，在模型给出回答前帮助检查和理解推理过程。

这说明前沿模型的发布已经不只是能力竞赛。越是强调 Agent、自动执行和长任务，安全控制、误拒率、有害输出防护和可解释性就越重要。

怎么看 Gemini 3.5

Gemini 3.5 Flash 的意义不只是“又一个新模型发布”。它更像是 Google 对下一阶段 AI 产品形态的集中押注：模型要能调用工具、拆分任务、协作执行、生成 UI，并进入个人和企业工作流。

对开发者来说，值得关注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的实际体验。对企业来说，重点是它能否在真实流程中稳定减少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 还没有正式开放。等 Pro 发布后，Flash 与 Pro 在能力、价格、速度和上下文处理上的差异，才会决定它们各自更适合哪些生产场景。

参考来源：

Google Blog：Gemini 3.5 正式登场

agentmemory 项目解析：给 Claude Code、Codex 和 Cursor 加持久记忆

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory 是一个面向 AI 编程 Agent 的持久记忆系统。它的目标很明确：让 Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode 等工具不必每次都重新理解项目背景、架构决策和历史问题。

项目地址：https://github.com/rohitg00/agentmemory

截至写作时，GitHub API 显示这个仓库已有约 1.3 万 star，主要语言是 TypeScript，许可证为 Apache-2.0。README 的描述是“Persistent memory for AI coding agents”。

它解决什么问题

AI 编程 Agent 的常见痛点是记忆断裂。今天让 Agent 修了一个认证问题，明天再开新会话，它可能又不知道：

认证中间件在哪个文件。
项目为什么选择某个库。
哪些测试已经覆盖。
哪些 bug 曾经修过。
团队偏好的实现方式是什么。

传统做法是写 CLAUDE.md、.cursorrules 或项目说明。但这类静态文件需要人工维护，而且越写越长，最后容易变成“所有内容都塞进上下文”。

agentmemory 的思路是：后台记录 Agent 的观察、工具调用和会话内容，压缩成可搜索记忆，再在后续会话中按需取回相关上下文。

支持哪些 Agent

README 中列出的支持范围很广，包括：

Claude Code
Codex CLI
Cursor
Gemini CLI
OpenClaw
Hermes
OpenCode
Cline
Goose
Roo Code
Windsurf
Aider

它的连接方式主要包括 hooks、MCP 和 REST API。只要客户端支持 MCP 或 HTTP，就有机会接入同一个 memory server。

快速启动

README 给出的基本安装方式：

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

也可以直接用 npx：

`1`	`npx @agentmemory/agentmemory`

默认服务端口包括：

API：3111
实时 viewer：3113

打开：

`1`	`http://localhost:3113`

可以看到 memory 构建过程、session、知识图谱、健康状态等信息。

和静态记忆文件有什么不同

静态记忆文件适合保存规则，比如编码风格、命令、目录说明。agentmemory 更偏运行时记忆，适合保存 Agent 实际做过什么、查过什么、修过什么。

README 中强调了几类能力：

自动捕获会话和工具调用。
BM25 + Vector + Graph 混合搜索。
MCP 工具暴露。
实时 viewer。
session replay。
本地运行，不依赖外部数据库。
支持多个 Agent 共享同一套记忆服务。

它不是替代所有项目文档，而是补上“会话历史和工作流记忆”这一层。

典型场景

第一，长期维护同一个代码库。Agent 可以记住以前修过的模块、测试策略和关键文件。

第二，多工具混用。比如平时用 Claude Code，有时用 Codex CLI 或 Cursor。如果这些工具都接入同一个 memory server，就能共享部分上下文。

第三，复杂任务拆分。长任务中间被压缩或换会话时，记忆系统可以帮助恢复关键状态。

第四，团队内沉淀经验。重复出现的 bug、架构取舍和操作步骤可以沉淀成可检索信息。

使用时要注意什么

第一，自动记忆不是越多越好。需要关注隐私、密钥、客户数据和敏感代码，不要把不该记录的内容放进长期记忆。

第二，记忆召回有误差。即使 README 给出了基准测试结果，实际项目里仍然要把召回内容当作参考，而不是事实来源。

第三，多个 Agent 共用记忆时，要设计好隔离边界。个人项目、公司项目、客户项目不应该混在同一个无隔离 memory 空间里。

第四，MCP 工具数量很多时，要注意工具暴露面。只开放实际需要的能力，避免让 Agent 获得过宽的写入、删除或导出权限。

适合谁

agentmemory 适合已经重度使用 AI 编程 Agent 的用户。尤其是：

长期维护一个项目的独立开发者。
经常切换 Claude Code、Codex、Cursor 的用户。
想研究 MCP、hooks 和 Agent 工作流的开发者。
希望把会话历史变成可检索资产的小团队。

如果只是偶尔让 AI 改一个小脚本，静态说明文件就够了。如果已经把 AI Agent 当作日常开发搭档，持久记忆系统会更有意义。

小结

agentmemory 解决的是 AI 编程中的“重新解释成本”。它把会话、工具调用和项目经验沉淀为可搜索记忆，让后续 Agent 更容易接上上下文。

这类工具的方向很重要，但也要谨慎使用。记忆系统越强，越需要重视数据边界、权限控制和清理机制。真正落地时，建议先在个人项目或非敏感代码库里试用，再逐步扩大范围。

参考项目：https://github.com/rohitg00/agentmemory

Claude Code 省 Token 指南：模型、MCP、CLAUDE.md 和 Skills 怎么影响缓存

Mon, 18 May 2026 18:30:24 +0800

Claude Code 长任务里，Prompt Cache 命中率会直接影响成本和速度。很多人只知道“缓存能省 Token”，但不清楚哪些操作会让缓存突然失效。

理解它并不难：每次请求都可以看成一条从左到右的上下文链条：

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

越靠左的内容越稳定，缓存收益越大；越靠左的内容一变，后面的缓存也更容易跟着失效。反过来，越靠右的内容变化，影响范围越小。

所以优化 Claude Code 的 Prompt Cache，不是靠玄学，而是靠一个原则：任务开始前把模型、MCP、Skills、CLAUDE.md 等基础上下文准备好，任务中途尽量不要改。

Prompt Cache 缓存的不是文字本身

Prompt Cache 不是简单地把提示词字符串存起来。对 Transformer 模型来说，更关键的是前缀上下文经过注意力层计算后的 Key/Value 状态，也就是常说的 KV cache。

这意味着两个事实：

同一段上下文，只要前缀保持稳定，就可以在后续请求中复用一部分计算结果。
如果模型、工具定义、系统提示词或前缀消息发生变化，之前的缓存就可能无法复用。

Anthropic 官方文档也把失效层级概括为 tools -> system -> messages。工具定义变化会影响整段缓存，系统层变化会影响 system 和 messages，messages 层变化则主要影响消息缓存。

Claude Code 里还会额外涉及 CLAUDE.md、Skills、MCP、插件和子代理等上下文，所以实际使用时更容易踩到缓存失效点。

缓存杀手一：中途切换模型

切模型是影响最大的操作。

Prompt Cache 是按模型隔离的。Opus、Sonnet、Haiku 这类模型的结构和权重不同，同一段文本算出来的 KV cache 也不同。你在 Opus 里跑了很长上下文，再切到 Sonnet，并不能让 Sonnet 复用 Opus 的缓存。

这会带来一个反直觉结果：中途为了省钱切模型，可能反而让前面已经积累的缓存全部失效。原本可以按 cache read 价格读取的上下文，需要重新写入和计算。

更稳妥的做法是：

主对话尽量固定一个模型。
需要便宜模型处理支线任务时，用 subagent 隔离出去。
让支线代理完成搜索、探索、整理，再把结果摘要交回主对话。

这样主对话的长上下文尽量不动，缓存命中率更稳定。

缓存杀手二：中途新增 MCP 或重载插件

MCP 会向 Claude Code 提供工具。新增 MCP 服务器后，工具列表会变化，而工具定义处在上下文链条最左侧。

从 Prompt Cache 的角度看，工具列表一变，后面的 system 和 messages 都可能需要重新计算。尤其是 MCP 很多时，工具定义本身就可能占用大量 Token，缓存失效的代价会很明显。

不过有一个细节：Claude Code 通常在会话启动时读取 MCP 配置。你中途改了配置，当前 session 不一定立刻受影响。真正需要小心的是触发重新加载的动作，例如重启、恢复会话、重新加载插件或让工具列表重新组装。

建议是：

开始长任务前，一次性装好需要的 MCP。
不要做一半才发现缺工具，再安装并重载。
对大型 MCP 工具集，优先考虑按需加载或减少默认启用数量。
不常用的 MCP 不要长期挂在默认配置里。

如果工具定义稳定，Prompt Cache 才有长期命中的基础。

缓存杀手三：中途修改 CLAUDE.md

CLAUDE.md 是 Claude Code 的项目记忆文件，适合放构建命令、测试命令、架构约定、代码风格和项目注意事项。

它对 Claude Code 很有用，但也会进入上下文。官方帮助文档说明，CLAUDE.md 会在 session 开始时读取，并作为用户消息提供给 Claude；它也会使用 Anthropic 的 Prompt Cache。首次请求会按完整输入计费，后续请求如果在缓存有效期内命中，就按更低的 cache read 成本处理。

问题在于：CLAUDE.md 是内容寻址的。你一改文件内容，旧缓存就对不上了。

所以不要在长任务中途频繁改 CLAUDE.md。更好的方式是：

任务开始前先检查 CLAUDE.md 是否够用。
把稳定规则写进去，把临时指令放在当前对话里。
如果只是一次性任务，不要为了临时需求修改长期记忆文件。
如果必须改，最好在一个阶段结束后再开始新 session。

CLAUDE.md 应该是稳定的项目说明，而不是每轮任务都改的便签。

缓存杀手四：中途安装或更新 Skills

Skills 也是上下文的一部分。安装新 Skill、更新 Skill，或者让 Skill 列表发生变化，都会让注入到会话里的上下文不同。

这类变化通常不会在当前 session 里立刻完整生效，而是在重新加载、恢复会话或新开会话时体现出来。问题是，一旦重新组装 messages，旧缓存就可能命中不了。

建议和 MCP 类似：

开始任务前先确认需要哪些 Skills。
同一类任务尽量固定 Skill 集合。
不要在一个长任务中途边做边装 Skill。
如果安装了新 Skill，最好把它当成新阶段的开始。

对经常做内容生产、代码审查、部署、翻译的工作流，可以把常用 Skills 固定下来，让上下文结构尽量稳定。

缓存杀手五：空闲时间超过 TTL

Prompt Cache 不是永久保存。常见默认有效期是几分钟级别，Anthropic 文档和 Claude Code 相关说明里都提到过 5 分钟左右的缓存窗口。超过 TTL 后，即使你发送完全一样的请求，服务端也可能已经清掉缓存。

这也是很多长任务用户的体感来源：刚才还很省，去喝杯咖啡回来，再发下一步，Token 又突然涨上去了。

长任务尤其容易遇到这个问题。你可能要看 Claude Code 的输出、检查文件、跑测试、思考下一步，这些操作一不小心就超过 5 分钟。

如果你的使用环境支持，可以在长任务前启用 1 小时 Prompt Cache TTL：

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

在 Windows PowerShell 里可以写成：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

需要注意的是，1 小时缓存写入成本通常会高于 5 分钟缓存写入成本。它不适合所有短任务，但对大型代码库、长对话、复杂多步骤开发任务，往往比频繁缓存过期更划算。

怎么安排一次更省 Token 的 Claude Code 长任务

比较稳的流程可以这样做：

任务开始前选定模型，不要中途频繁切换。
提前启用需要的 MCP，不用的 MCP 先关掉。
检查 CLAUDE.md，只保留稳定、关键、长期有效的规则。
提前准备好本次任务需要的 Skills。
如果是复杂任务，考虑启用 1 小时 TTL。
把大任务拆成几个阶段，但每个阶段内部尽量保持上下文结构稳定。
需要探索支线问题时，用 subagent 或单独 session，不要污染主对话。

这套做法的目标不是绝对不让缓存失效，而是避免那些代价最高、最容易被忽略的失效。

一个简单判断标准

你可以用一句话判断某个操作是否危险：

这个操作会不会改变模型、工具定义、系统上下文或会话开头的固定消息？

如果答案是会，那它大概率会影响 Prompt Cache。越靠近上下文链条左侧，影响越大。

常见操作可以这样理解：

切模型：高风险，模型缓存隔离。
新增 MCP 或重载插件：高风险，工具列表变化。
修改 CLAUDE.md：中高风险，项目记忆变化。
安装 Skills：中高风险，注入上下文变化。
普通对话继续追问：低风险，主要追加 messages。
空闲超过 TTL：高风险，服务端缓存过期。

小结

Claude Code 的 Prompt Cache 优化，关键不是背参数，而是让会话前缀稳定。

模型不要随便切，MCP 和 Skills 不要边做边装，CLAUDE.md 不要当临时草稿频繁改，复杂任务尽量延长 TTL。只要这些基础动作稳定下来，Claude Code 在长任务里的 Token 成本和响应速度都会更可控。

最实用的一句话是：开始前配好，开始后少动。

参考资料

OpenClaw 作者 Peter Steinberger 如何看 AI 软件开发？从 OpenClaw 到闭环编程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的经历很适合用来观察 AI 软件开发正在发生什么变化。

他不是“突然被 AI 带火的新人”。在 OpenClaw 之前，他已经是 PSPDFKit 的创始人，长期做 PDF 渲染、文档处理和开发者工具。这类产品很难靠概念包装取胜，必须面对性能、兼容性、API 设计、企业客户和长期维护。

所以，当 Steinberger 后来用 AI 工具做出 OpenClaw，并围绕 AI Agent、个人自动化和 AI 编程发表观点时，重点不只是“一个人写了很多代码”。更值得看的，是他把多年软件工程经验和新一代 AI coding agent 结合后，对开发流程的重新理解。

AI 编程不是魔法按钮

很多人讨论 AI 编程时，会把它简化成两个极端。

一种说法是：AI 已经能写代码，程序员快没用了。

另一种说法是：AI 写的代码不可靠，真正工程还是得靠人手写。

Steinberger 的经验更接近第三种：AI 让软件开发的操作单位变了，但没有取消工程判断。

过去，开发者主要以“编辑代码”为中心工作。需求拆解、架构判断、写实现、跑测试、修 bug，都围绕人工修改代码展开。

AI coding agent 介入后，开发者越来越像在管理一个执行系统：

说明目标。
提供上下文。
约束边界。
让 agent 修改代码。
运行测试和检查。
根据结果继续迭代。

这不是简单把键盘交给模型，而是把人从“每一行都亲手敲”转到“定义方向、设计反馈、判断结果”。

为什么他不喜欢把这叫 vibe coding

围绕 Steinberger 的讨论里，一个高频词是 vibe coding。

这个词原本用来形容一种新开发方式：开发者用自然语言描述想法，让 AI 生成大量代码，再通过运行结果和反馈不断调整。

但 Steinberger 对这个词并不完全买账。公开报道中提到，他认为 vibe coding 容易变成一种贬义表达，暗示 AI 辅助开发只是“凭感觉乱生成”，忽视了背后的技能、判断和经验。

这个批评有道理。

真正有效的 AI 编程并不是随便输入一句话，然后相信模型输出。它需要：

能把模糊需求拆成可执行任务。
能识别模型是否误解了目标。
能设计测试和验收标准。
能判断代码结构是否会影响长期维护。
能知道什么时候应该停止生成、转向人工审查。

换句话说，AI 降低了写代码的摩擦，但没有降低理解系统的责任。

闭环才是关键

Steinberger 相关访谈和文章里，经常被总结出的一个核心思路是“闭环”。

只让 AI 生成代码，是开环。

让 AI 生成代码、运行代码、读取错误、修复问题、再运行测试，才更接近闭环。

这个差别非常重要。

开环生成很容易制造表面可用的软件。页面能打开，功能看起来有，代码也不少，但一旦进入真实场景，就会暴露状态管理、权限、异常处理、边界条件和部署问题。

闭环开发要求输出必须被反馈约束。最简单的闭环是：

写清楚目标。
让 AI 修改代码。
自动运行测试、类型检查、lint 或构建。
把错误反馈给 AI。
重复直到通过。
最后由人审查关键路径。

这也是 AI 软件开发真正能提高效率的地方。不是因为模型一次就写对，而是因为它可以快速参与“生成、验证、修复”的循环。

经验越多，越能用好 AI

AI 编程最容易产生的误解之一，是“经验不重要了”。

Steinberger 的案例反而说明，经验会变得更重要，只是作用方式变了。

一个有经验的工程师更容易判断：

哪些任务适合交给 agent。
哪些模块需要先写测试。
哪些改动风险太高，不该让 AI 大范围重构。
哪些生成代码只是看起来合理。
哪些问题应该通过架构调整解决，而不是继续补丁式修复。

AI 可以生成大量候选方案，但候选方案越多，越需要判断力。没有经验的人可能会被“能跑起来”迷惑，有经验的人更会追问：能不能维护？能不能扩展？会不会破坏安全边界？出了问题能不能定位？

这也是为什么 AI coding agent 并没有让软件工程变成纯聊天。它更像把一部分执行劳动外包出去，同时放大了规划、审查、验证和取舍的重要性。

OpenClaw 的意义不只是项目本身

OpenClaw 被关注，不只是因为它是一个开源 AI agent，也不只是因为它的增长速度快。

它更像一个信号：开发者开始希望 AI 不只回答问题，而是能接入真实工具，完成真实动作。

传统聊天机器人停留在对话框里。它可以解释代码、写草稿、给建议，但很多时候还需要人复制、粘贴、打开软件、执行命令。

Agent 的方向是把模型接到工具上：

文件系统。
浏览器。
终端。
邮件。
日历。
第三方服务。
项目仓库。

一旦模型能使用这些工具，软件开发的边界就会变化。AI 不再只是“代码补全”，而会参与项目阅读、任务拆解、文件修改、测试执行、PR 整理和工作流自动化。

这也是 Steinberger 加入 OpenAI 后被关注的原因。他代表的不是单个开发者故事，而是一种产品方向：个人 agent 会从演示玩具走向日常工作层。

这对普通开发者意味着什么

对普通开发者来说，Steinberger 的经验不一定能直接复制。

不是每个人都能同时管理多个 agent，不是每个项目都适合高强度 AI 生成，也不是每个团队都能接受“先生成再快速迭代”的节奏。

但有几件事值得学。

第一，先把任务写清楚。

AI 对含糊目标很敏感。你说“优化一下”，它可能改风格、改结构、加功能、删逻辑。你说“把登录失败时的错误提示从英文改成中文，不改变认证流程”，结果通常更可控。

第二，把验证命令固定下来。

如果一个项目没有测试、没有构建命令、没有 lint，AI 就很难形成闭环。哪怕只是最基础的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼检查强。

第三，控制改动范围。

一次只让 AI 处理一个模块、一个 bug、一个页面，通常比让它“重构整个项目”更可靠。

第四，保留人工审查。

尤其是认证、支付、权限、数据删除、部署脚本、数据库迁移、安全配置这些地方，不要因为代码是 AI 生成的就降低审查标准。

第五，复盘 prompt 和失败模式。

如果 AI 经常误解某类任务，就把约束写进项目规则、agent instructions 或技能文件。AI 编程能力不是只来自模型，也来自你给它搭建的工作环境。

AI 软件开发会走向哪里

Steinberger 的故事说明，AI 软件开发正在从“辅助写代码”走向“组织软件生产流程”。

早期 AI 编程工具的价值主要是补全函数、解释报错、生成模板。现在的变化是，agent 可以跨文件工作，可以调用工具，可以运行检查，可以根据反馈继续修复。

这会带来几个趋势：

第一，个人开发者的产能上限会提高。

一个人可以同时推进更多原型、脚本、内部工具和小型产品。但产能提高不等于质量自动提高。越快生成，越需要验证。

第二，项目结构会更重要。

代码越清晰，测试越明确，文档越完整，AI 越容易正确修改。混乱项目对人难，对 AI 也难。

第三，软件工程师会更像工作流设计者。

未来重要的不只是会不会写某门语言，而是能否把需求、上下文、工具、测试、部署和权限组织成一个可控循环。

第四，安全边界会更敏感。

Agent 能做事，就可能做错事。它能读文件、执行命令、访问服务，也意味着权限、审计和回滚会成为 AI 开发环境的基础设施。

小结

Peter Steinberger 的 AI 软件开发观，最有价值的地方不是“AI 生成了多少代码”，而是他展示了一种新的开发姿势。

人不再只是在编辑器里逐行输入，而是在设计目标、管理 agent、构造反馈回路、审查结果和调整系统。代码仍然重要，但代码不再是唯一的劳动中心。

如果说传统软件开发强调“把代码写对”，AI 软件开发会更强调“让系统持续产出可验证的正确结果”。

这不是降低工程门槛那么简单。它是在改变工程能力的形态：从手工实现，转向任务分解、上下文管理、工具编排、自动验证和最终判断。

参考资料

Gemini 3.5 Pro 曝光：代号 Cappuccino，谷歌想在编程和 Agent 上追回节奏

Sun, 17 May 2026 11:47:27 +0800

Google 还没有正式发布 Gemini 3.5 Pro。

目前能看到的信息，主要来自开发者社区截图、匿名跑分、爆料人消息和媒体转述。36Kr / 新智元在 2026 年 5 月 15 日整理称，新一代 Gemini 检查点内部代号可能是 Cappuccino，相关模型已经在社区和评测平台中提前曝光。

这类信息还不能等同于官方发布，但它透露出一个清晰方向：Google 正在试图同时补上两块短板，一块是编程和推理能力，另一块是全天候 AI Agent。

先说结论

这次爆料可以拆成三层来看：

Gemini 3.5 Pro 尚未正式发布，Cappuccino 更像是内部检查点或候选版本代号。
曝光信息显示，新 Gemini 在代码生成、SVG / 交互式 Web 生成、多模态输出上有明显提升。
Google 同步测试的 Gemini Spark，可能比模型本身更关键，因为它指向 24 小时运行的个人 AI Agent。

换句话说，这不是一条简单的“模型跑分新闻”。它更像是 Google 在 I/O 前释放出的产品路线信号：模型要追赶 GPT-5.5，Agent 要抢占用户工作流入口。

Cappuccino 是什么

36Kr 文章提到，网友 Lentils 放出的消息显示，代号 Cappuccino 的 Gemini 3.5 Pro 检查点已经开始产出。此前社区还在讨论 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果这个命名最终属实，说明 Google 可能希望把下一代 Gemini 包装成一次更大的版本跃迁，而不是普通小版本更新。

需要注意的是，Cappuccino 现在仍应被视为爆料中的内部代号。它不等于 Google 已经公开上线的正式模型，也不代表最终发布名一定就是 Gemini 3.5 Pro。

编程能力为什么是焦点

这次爆料里最受关注的点，是新 Gemini 的编程能力。

36Kr 引述的社区截图和跑分信息显示，新模型在以下任务上表现更强：

生成 SVG 与视觉组件。
生成交互式 Web 应用。
处理动画、3D、可调参数面板等复杂前端输出。
逻辑推理和代码生成能力有所提升。

文章还提到，Abacus.AI CEO Bindu Reddy 转述的说法是，3.2 Flash 在编码和推理上接近 GPT-5.5 的水平，同时成本更低。另有媒体信源则认为，新款 Gemini 的整体性能大致追平 GPT-5.5，但未必能带来质变。

这也是为什么要谨慎看待“追平 GPT-5.5”这句话。它更像是不同爆料源和匿名评测中的相对判断，而不是 Google 官方给出的基准测试结论。

为什么 Google 急着补编程

AI 编程已经从开发者工具变成了大模型竞争的核心战场。

OpenAI 有 Codex，Anthropic 有 Claude Code。它们不只服务工程师，也在把产品经理、设计师、运营人员带进“自然语言生成可运行产品”的工作流里。

相比之下，Google 虽然有 Gemini 和 Antigravity，但在开发者心智里一直没有形成同等强度的默认入口。36Kr 文章也提到，Antigravity 在外部市场还没有真正突围，定价、额度提醒和体验稳定性都曾引发社区讨论。

所以新 Gemini 如果要证明自己，编程会是最直接的战场。它不一定只比拼“会不会写代码”，还要比拼能不能稳定产出完整界面、理解复杂需求、调用工具、修复错误并融入真实开发流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料里，Gemini Spark BETA 也被扒出。

根据 TestingCatalog 等信息源的说法，Spark 的定位接近“全天候 AI Agent”：它可以处理收件箱、执行在线任务、管理多步骤工作流，并连接 Google 应用、技能模块、聊天记录、定时任务、登录网站、位置信息等上下文。

这意味着 Spark 不是一个普通聊天入口，而是一个可能长期在线、持续读取上下文并替用户执行任务的系统。

它的吸引力很明显：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起来，Spark 会天然拥有 OpenAI 和 Anthropic 很难复制的分发优势。

但风险也同样明显。36Kr 文章提到，Spark 相关说明中出现了“可能在未经询问的情况下分享信息或完成购买”的表述。哪怕系统设计上会在敏感操作前征求许可，这类 Agent 仍然会带来隐私、授权边界和误操作风险。

这对普通用户意味着什么

如果你只是普通 Gemini 用户，这次爆料真正值得关注的不是模型名，而是三个变化：

第一，Google 可能会继续强化“生成完整结果”的能力。以前用户经常吐槽 Gemini 在视觉生成、SVG、前端页面上容易偷懒，如果新模型能一次给出多个完整方案，体验会明显改善。

第二，编程能力会继续下放到更轻量的模型。爆料里反复提到 Flash 版本在编码、推理和交互式生成上的提升，这意味着未来不一定只有 Pro 模型才能处理复杂任务。

第三，Agent 会变得更主动。Spark 如果发布，Gemini 可能不再只是回答问题，而是开始长期接管邮件、网页、购买、日程和跨应用任务。

这对效率是好消息，对权限管理则是新挑战。

这对开发者意味着什么

开发者更应该关注两个问题。

第一个问题是工具生态。36Kr 文章提到，社区从模型选择器里看到了 MCP Tool Testing 这类未公开入口。如果 Gemini 原生支持 MCP 或第三方工具测试，那么它会更容易接入开发者自己的工具链。

第二个问题是成本和稳定性。即便新 Gemini 在某些基准上追平 GPT-5.5，开发者最终还是会看三件事：实际代码质量、上下文稳定性、价格和额度是否可预期。

过去一年，AI 编程工具竞争已经证明，模型能力只是门票。真正让开发者留下来的，是能不能在日常项目里持续可靠地改代码、跑测试、读上下文、处理边界条件。

现在应该如何看待这条消息

这条消息适合用“强信号、弱确认”来理解。

强信号在于：多个社区线索都指向 Google 正在准备更强的新 Gemini，以及更主动的 Gemini Spark Agent。

弱确认在于：Gemini 3.5 Pro 还没有官方发布，Cappuccino 仍是爆料代号，所谓“追平 GPT-5.5”的说法也需要等 Google 官方基准、第三方评测和真实用户测试来验证。

所以现在最稳妥的判断是：

不要把它当成已发布产品。
可以把它当成 Google 下一阶段 Gemini 路线的提前预告。
重点关注 I/O 或后续官方活动中是否会确认模型命名、API 可用性、价格、上下文窗口、工具调用和 Agent 权限边界。

总结

Gemini 3.5 Pro / Cappuccino 的曝光说明，Google 可能正在为下一代 Gemini 做一次更强势的版本推进。它要补的不是单一能力，而是整个 AI 工作流：模型要更会写代码、生成界面和处理复杂推理，Spark 则要把 Gemini 推向全天候 Agent。

但在官方发布前，所有跑分和截图都只能作为线索。真正决定 Gemini 3.5 Pro 能否翻身的，不是代号是否好听，而是它能否在真实开发、真实办公和真实多步骤任务里稳定胜出。

参考链接：

Codex 支持 ChatGPT 移动端远程访问，Enterprise 工作区可用 Access Tokens

Sun, 17 May 2026 09:12:07 +0800

OpenAI 在 2026 年 5 月 14 日更新了 ChatGPT Enterprise & Edu Release Notes，重点只有两件事：Codex 支持通过 ChatGPT 移动端远程访问，Enterprise 工作区可以使用 Codex access tokens 做受控自动化。

这不是一次模型能力发布，而是 Codex 产品形态的变化。Codex 正在从“本地或网页里的编程助手”，变成可以长时间运行、可以远程接管、可以接入企业自动化流程的 coding agent。

这次更新是什么

根据 OpenAI Help Center 的说明，Codex 现在支持从 ChatGPT mobile app 远程访问。用户可以在手机上连接正在运行的 Codex 环境，持续跟进长时间任务，并在需要时介入。

同时，ChatGPT Enterprise 工作区新增 Codex access tokens。它们面向可信的非交互式本地工作流，让自动化流程可以使用 ChatGPT workspace identity 和企业控制，而不需要每次通过浏览器登录。

可以把这次更新理解成两个入口：

移动端远程访问：解决“Codex 跑长任务时，人不在电脑前怎么办”。
Access Tokens：解决“企业自动化脚本如何以受控身份调用 Codex 工作流”。

移动端远程访问解决什么问题

Codex 的典型任务并不总是几秒钟完成。真实开发里，它可能要阅读代码库、修改多个文件、运行测试、等待命令输出、根据错误继续修复，甚至需要用户中途批准某些操作。

过去这类任务往往要求用户守在本地 Mac、桌面端、CLI 或 IDE 旁边。现在，ChatGPT 移动端可以变成一个远程控制台，让用户离开电脑后仍能跟进 Codex。

OpenAI 提到，移动端可以展示底层环境的实时状态，包括：

项目上下文。
approvals。
screenshots。
terminal output。
diffs。
test results。

用户也可以在手机上回答 Codex 的问题、重定向执行、批准操作、查看输出，并在不同 connected hosts 之间切换。底层任务仍然运行在 Mac host 或连接的远程环境中，手机端负责查看和控制。

这对开发者有什么价值

这项能力最适合长时间、需要中途确认的开发任务。

例如：

Codex 正在跑一组耗时测试，你出门后仍想看结果。
Codex 修改了多个文件，需要你在手机上看 diff 后批准下一步。
Codex 执行到某个危险操作前等待确认，你可以远程处理。
本地 Mac 上有多个 connected hosts，需要在手机上切换查看状态。

它的价值不是让你在手机上写代码，而是让你不用一直守着电脑。Codex 继续在原环境里工作，你只在关键节点介入。

这也说明 Codex 的使用方式正在接近“后台 Agent”：任务可以持续运行，用户不必全程在线，但仍要保留审批和控制权。

Access Tokens 解决什么问题

Codex access tokens 面向 ChatGPT Enterprise 工作区。它们的重点不是普通个人用户登录，而是企业内部可信自动化。

企业里经常有一些本地或内部流程需要非交互式运行，例如：

定时执行代码检查。
在受控机器上触发 Codex 工作流。
将 Codex 接入内部开发工具链。
在不打开浏览器的情况下使用工作区身份。

Access tokens 让这些流程可以带着 ChatGPT workspace identity 运行，同时继续受企业策略约束。相比临时人工登录，它更适合自动化；相比随便共享个人凭据，它也更容易纳入治理。

它不是普通 API key

这点很重要。Codex access tokens 不应该被理解成一个简单的“万能 API key”。

OpenAI 的说明里提到，access tokens 可用于 ChatGPT Enterprise 工作区，管理员可以管理工作区级可用性，拥有允许角色的成员可以创建自己的 tokens。治理界面在可用情况下也会反映 access token 活动。

也就是说，access tokens 被放在企业权限、角色和审计框架里：

管理员可以决定工作区是否开放。
不是所有成员都天然可以创建。
token 活动可以进入治理视图。
它继承 ChatGPT workspace identity 和企业控制。

这和个人随手生成一个长期密钥不是一回事。

安全默认值：Remote Control 默认关闭

Codex mobile remote access 涉及代码环境、终端输出、diff、测试结果和操作审批。如果默认开放，会带来明显企业安全风险。

因此 OpenAI 的默认策略是：remote control 默认关闭，管理员或 owner 需要在 Workspace settings 中启用。

启用移动端远程访问时，还可能涉及：

workspace-enabled Remote Control access。
SSO。
多因素认证。
passkey。

这说明它是一个需要企业 IT 和安全团队参与配置的能力，而不是“更新 App 后所有人自动可用”。

使用前需要更新什么

OpenAI 提到，要使用移动端远程访问，需要更新两端：

ChatGPT mobile app。
macOS 上的 Codex app。

如果工作区启用了相关要求，移动端设置过程还可能触发 SSO、多因素认证或 passkey 流程。

实际落地时，企业管理员还需要先确认 Workspace settings 里的 remote control 设置，以及哪些成员或角色可以使用相关能力。

对企业 Codex 使用方式的影响

这次更新把 Codex 往两个方向推进。

第一，Codex 更适合长任务。以前长任务最大的问题是用户要一直盯着，现在手机可以查看状态和批准操作，Codex 可以更自然地跑在后台。

第二，Codex 更适合企业自动化。Access tokens 让非交互式工作流有了更正式的身份方式，后续更容易接入内部 CI、代码审查、脚本和开发平台。

这两个方向结合起来，意味着 Codex 不再只是“开发者手边的 AI 助手”，而是在变成企业开发流程里的一个可管理 agent。

仍然需要注意的边界

这次更新很有用，但并不意味着 Codex 可以完全无人看管。

企业使用时仍然要注意：

哪些项目允许远程控制。
哪些命令需要审批。
token 如何创建、轮换和撤销。
mobile remote access 是否符合公司设备管理策略。
终端输出、截图和 diff 是否可能包含敏感信息。
审计日志和治理界面是否能满足内部合规要求。

尤其是 access tokens，一旦进入自动化流程，就要像其他企业凭据一样管理：最小权限、定期轮换、避免硬编码、及时撤销不用的 token。

总结

OpenAI 这次 Codex 更新的重点很集中：ChatGPT 移动端可以远程访问 Codex 长任务，Enterprise 工作区可以用 Codex access tokens 支持受控自动化。

前者让开发者不必一直守在电脑前，后者让企业可以把 Codex 更正式地接入内部工作流。两者合在一起，说明 Codex 正在从交互式编程助手，进一步走向可远程管理、可审计、可自动化接入的企业 coding agent。

参考链接：

OpenAI Help Center：ChatGPT Enterprise & Edu - Release Notes

easy-vibe：给 Vibe Coding 初学者的一张学习地图

Sat, 16 May 2026 22:44:43 +0800

easy-vibe 是 Datawhale 开源的 Vibe Coding 学习项目。它面向的不是已经熟练使用 AI 编程工具的开发者，而是刚开始接触 Vibe Coding 的学生、产品经理、设计师、运营、独立开发者和普通技术爱好者。

这个项目的价值不在于又列出一批 AI 工具，而是把“怎么开始用 AI 做项目”拆成了更容易理解的学习路径。对很多新手来说，真正困难的不是不知道有 Claude Code、Cursor、MCP 或 Agent，而是不知道应该先学什么、怎么练、什么时候进入进阶工具。

Vibe Coding 新手最缺的是路径

Vibe Coding 这几年很火，但它对新手并不友好。

表面上看，只要会描述需求，就可以让 AI 写代码。实际上，只要任务稍微复杂一点，问题就会出现：需求说不清，模型改错文件，项目结构看不懂，报错不会处理，依赖装不上，提示词越写越乱，最后只能回到“复制代码到聊天框”的状态。

所以 Vibe Coding 入门不能只教“怎么写提示词”。它至少要解决几件事：

如何把想法拆成可执行任务；
如何让 AI 理解项目结构；
如何看懂模型生成的代码；
如何处理报错和迭代；
如何使用终端和本地开发环境；
如何从网页聊天过渡到真正的 AI 编程工具。

easy-vibe 的意义就在这里：它试图把这些内容整理成一条学习路线，而不是让新手自己在工具、教程和术语里迷路。

它不是单点教程，而是路线图

从项目介绍看，easy-vibe 覆盖了基础教程、交互式练习、可视化内容、RAG、终端工具、AI 编程工具，以及更进阶的 Claude Code、MCP、Skills、Agent Teams 等主题。

这类组织方式比较适合初学者。因为 AI 编程不是一个单独技能，而是一组能力的组合：

会描述需求；
会拆任务；
会读项目；
会让模型改代码；
会运行和验证；
会根据错误继续迭代；
会把常用流程沉淀成工具或技能。

如果只学某一个工具，很容易被工具界面限制住。换一个模型、换一个编辑器、换一个 CLI，就又不知道怎么做。路线图的好处是先建立工作方式，再把工具放到合适的位置。

对非程序员尤其有用

Vibe Coding 最大的吸引力，是让非专业程序员也能做出原型。

产品经理可以把产品想法变成可交互 demo，设计师可以验证交互逻辑，运营可以写内部工具，学生可以快速做课程项目，创业者可以在早期验证需求。这些人不一定要成为传统意义上的全职工程师，但需要掌握一套“让 AI 帮我把想法落地”的方法。

这也是 easy-vibe 适合中文社区的原因。很多中文用户已经知道 AI 能写代码，但还缺少系统入门材料：从开发环境、提示词、项目结构、调试方法到 Agent 工具使用，最好能用中文解释清楚，并配合练习逐步推进。

对这类用户来说，最重要的不是一上来学复杂框架，而是先跑通完整闭环：提出需求、生成项目、运行起来、发现问题、继续修改、最终得到一个可用版本。

进阶部分开始靠近真实 AI 开发工作流

easy-vibe 里提到的 Claude Code、MCP、Skills、Agent Teams，已经不只是入门概念。

Claude Code 代表的是终端编程 Agent：模型可以进入本地项目，读取文件、修改代码、运行命令。MCP 解决的是工具和数据源接入，让模型不只停留在聊天框里。Skills 则把可复用流程沉淀下来，例如固定的项目生成、文档整理、测试检查或内容生产流程。Agent Teams 进一步把任务拆给多个智能体协作。

这些内容对新手来说可能有点远，但它们值得提前了解。因为 Vibe Coding 的发展方向已经很清楚：从“让 AI 写一段代码”，走向“让 AI 参与一个完整项目流程”。

如果学习路线只停留在提示词层面，很快就会跟不上工具演进。反过来，如果一开始就把所有高级概念塞给新手，又会让人无从下手。easy-vibe 的合理价值，是把这些内容放在一条逐步升级的路径里。

学习时要避免两个误区

第一个误区，是以为 Vibe Coding 等于不会代码也能完全不管代码。

AI 可以生成很多内容，但用户仍然需要判断结果是否正确。至少要能看懂项目结构、知道怎么运行、知道错误大概发生在哪里。即使不写复杂代码，也要具备基本的工程常识。

第二个误区，是以为工具越高级越好。

新手不一定一开始就需要 Claude Code、MCP 或多 Agent。更好的顺序是先用简单项目建立反馈循环，再逐步引入终端、版本管理、测试、工具调用和自动化流程。工具要跟任务复杂度匹配，否则很容易变成“看起来很强，但不知道用来做什么”。

适合怎么用

如果你刚接触 Vibe Coding，可以把 easy-vibe 当作学习清单来用。

先从基础概念和简单练习开始，不急着追所有工具。做一个小项目，例如个人主页、数据看板、表单工具、自动化脚本或知识库 demo。过程中重点观察 AI 在哪些地方帮得上忙，哪些地方需要你自己确认。

等你能稳定完成小项目，再开始学习更复杂的内容：

用终端工具处理本地项目；
用 Git 管理每次修改；
用 RAG 接入自己的资料；
用 MCP 连接外部工具；
用 Skills 固化重复流程；
用 Agent Teams 拆分复杂任务。

这样学出来的 Vibe Coding 才不只是会问 AI，而是能把 AI 放进自己的工作流程里。

总结

easy-vibe 适合被看作 Vibe Coding 的中文入门地图。它把零散的 AI 编程概念、工具和练习组织成一条路径，让新手更容易从“听说 AI 能写代码”走到“我能用 AI 做出一个项目”。

Vibe Coding 真正有价值的地方，不是让人跳过所有学习，而是降低从想法到原型的门槛。你仍然需要理解需求、组织任务、验证结果和控制风险，但很多重复、枯燥、容易卡住的步骤，可以交给 AI 协助完成。

如果你想系统入门 AI 编程，又不想一开始就陷入工具名词和复杂工程配置，easy-vibe 是一个值得收藏的起点。

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，这个功能值得开启。如果你还只是偶尔问几句代码问题，它的价值可能没有那么明显。

参考资料

别把 API Key 推上 GitHub：AI 写代码时代的密钥泄露防坑指南

Sat, 16 May 2026 16:26:50 +0800

AI 写代码降低了动手门槛，也把很多原来只会发生在工程团队里的安全问题，带到了新手和非工程用户面前。

最常见的一类事故，是把 API Key、Secret、Token、数据库连接串或 .env 配置文件一起推到公开仓库。对本地项目来说，这些文件只是“能让程序跑起来的配置”；一旦进了 GitHub 公共仓库，它们就变成了可以被自动扫描、自动调用、自动滥用的凭证。

密钥泄露不是小概率事件。GitGuardian 的 2026 年度报告提到，2025 年公共 GitHub 提交里出现了约 2865 万个新增硬编码凭证，AI 服务相关凭证泄露同比增长 81%。这说明问题不只是“有人粗心”，而是 AI 编程、快速原型和公开托管叠加后，泄露规模正在被放大。

为什么新手更容易泄露 Key

很多 AI Agent 或小工具都有两套“仓库”：一套在本地硬盘里，另一套在 GitHub 上。问题在于，新手经常没有意识到二者的边界。

本地运行时，config.json、.env、settings.yaml 里放着 API Key，好像只是开发习惯；执行 git add .、git commit、git push 之后，这些文件就可能被完整上传。仓库一旦公开，扫描机器人不需要理解你的业务，只要匹配到密钥格式，就能把它抓走。

AI 编程还会放大这个问题：

AI 生成示例代码时，可能直接把 OPENAI_API_KEY = "sk-..." 这类写法放进源码。
新手为了“先跑起来”，容易把密钥硬编码在前端、脚本或配置文件里。
很多 vibe coding 平台可以直接部署应用，不一定经过 GitHub 的推送保护流程。
用户可能不知道 AI 生成的项目里到底有哪些文件、哪些接口、哪些默认权限。

换句话说，AI 可以帮你更快写出能跑的东西，但不会自动替你承担安全责任。

`.gitignore` 不是装饰

Git 负责版本管理，GitHub 负责托管代码，.gitignore 则是告诉 Git 哪些文件不要纳入版本历史。

一个最基本的 AI 项目，至少应该把这些内容排除掉：

.env
.env.*
*.key
*.pem
config.local.*
secrets.*
credentials.*

但只写 .gitignore 还不够。它只能阻止“尚未被 Git 跟踪”的文件继续进入提交。如果某个密钥文件已经被提交过，后来再把它写进 .gitignore，并不能把历史记录里的密钥抹掉。

所以更稳妥的习惯是：

新项目一开始就创建 .gitignore。
API Key 只放在环境变量或本地配置里。
示例文件只提供 .env.example，里面写占位符，不写真实密钥。
提交前运行一次密钥扫描工具，比如 gitleaks、trufflehog 或 GitHub Secret Scanning。

Key 推上去以后，删除文件不等于安全

如果密钥已经推到公开仓库，第一反应不应该是“删掉文件再提交一次”，而应该是立刻吊销或轮换密钥。

原因很简单：Git 记录的是历史。即使你在最新提交里删除了文件，旧提交、fork、clone、缓存和扫描系统里仍可能保留那段内容。GitHub 官方文档也明确建议：如果泄露的是密码、Token 或凭证，第一步应该撤销或轮换。

处理顺序建议这样做：

立即去服务商后台吊销旧 Key，生成新 Key。
检查账单、调用日志、异常 IP 和异常用量。
从代码中移除硬编码密钥，改用环境变量或密钥管理服务。
用 git filter-repo 或 BFG 清理仓库历史中的敏感文件。
开启 GitHub Secret Scanning 和 Push Protection。
检查 CI/CD、部署平台、云函数、前端构建产物里是否也包含旧 Key。

对于 OpenAI、Anthropic、DeepSeek、云厂商、支付、邮件、数据库等服务，泄露 Key 的后果可能不只是被刷额度，还可能包含数据读取、服务滥用、供应链污染或业务账号封禁。

前端代码里不能放真正的密钥

很多新手以为“只要页面能跑就行”，于是把 API Key 写进前端 JavaScript：

`1`	`const apiKey = "sk-xxxxxxxx";`

这基本等于公开。浏览器里的代码、网络请求、Source Map、构建产物都可以被查看。只要是真正需要保密的 Key，就不应该出现在客户端。

正确做法是让前端请求自己的后端接口，由后端读取环境变量并调用第三方 API：

// frontend
await fetch("/api/chat", {
  method: "POST",
  body: JSON.stringify({ message })
});

后端再使用环境变量：

1
2

// server
const apiKey = process.env.OPENAI_API_KEY;

这样做不是为了形式好看，而是为了把密钥留在服务器环境里，避免直接暴露给所有访问页面的人。

Vibe Coding 的安全责任不会自动消失

vibe coding 的问题不只是 GitHub 泄露。很多应用直接从 AI 编程平台发布到公网，跳过传统代码审查、仓库扫描和安全测试。

RedAccess 近期披露的研究显示，公开网络上可以找到大量由 AI 编程工具生成或托管的应用资产，其中一部分暴露了企业数据、个人信息或内部文件。它提醒的是同一件事：当“能上线”变得太容易，“是否应该上线”“是否只该内网访问”“是否有权限控制”就更容易被忽略。

如果你用 AI 生成应用，至少要在发布前问自己几个问题：

这个应用是否真的需要公开访问？
是否有登录、鉴权和权限隔离？
是否把数据库、API Key、Token、Webhook 地址暴露在前端？
是否限制了第三方 API 的额度、域名、权限和有效期？
是否能在发现异常后快速禁用密钥和回滚部署？

AI 写出来的代码也需要安全审查。越是“我一行代码都没写”，越不能假设它天然安全。

现在就该做的检查

可以先从自己的 GitHub 账号查起。搜索用户名加上这些关键词：

API_KEY
SECRET
TOKEN
OPENAI_API_KEY
ANTHROPIC_API_KEY
DEEPSEEK_API_KEY
.env
config
credentials

如果发现真实密钥，不要犹豫：先轮换，再清理。只要它进过公开仓库，就按已经泄露处理。

以后新建 AI 项目时，也建议固定一套流程：

先写 .gitignore，再写业务代码。
用 .env.example 说明需要哪些变量。
所有密钥放环境变量，不写进源码。
给 API Key 设置最小权限、额度限制和过期时间。
开启 GitHub Secret Scanning 和 Push Protection。
发布前让 AI 再帮你做一次安全检查，但不要只相信 AI 的结论。

AI 编程真正危险的地方，不是它会写错代码，而是它让很多人第一次拥有了把不安全应用快速发布到公网的能力。写得快不是问题，把密钥、数据和权限一起交出去才是问题。

参考资料

Gemini 3.5 Pro 提前曝光：谷歌想用 Spark Agent 抢回 AI 编程入口

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro 还没正式发布，相关爆料已经开始升温。

这轮信息里有几个关键词：Gemini 3.5 Pro、代号 Cappuccino、Gemini Spark、AI 编程、MCP 工具接入。它们指向同一个方向：谷歌不只是想更新一个聊天模型，而是想把模型、工具、Agent 和 Google 生态入口重新绑在一起。

不过，在正式发布前，这些信息都应该按“爆料”看待。真正值得关注的不是某一张截图或某一个跑分，而是谷歌接下来可能要补的几块短板。

Gemini 3.5 Pro 为什么值得关注

从曝光信息看，Gemini 3.5 Pro 可能是一次跳级命名。

此前外界还在讨论 Gemini 3.2，随后又出现 Gemini 3.5 Pro 的说法。如果命名属实，说明谷歌想在新一轮发布里讲一个更大的版本故事，而不是只做常规小更新。

目前流出的重点主要集中在三方面：

编程和推理能力继续提升；
SVG、交互式页面、动画和 3D 生成能力增强；
新的 Agent 产品 Gemini Spark 可能进入前台。

这些方向并不意外。Gemini 系列一直强调多模态，谷歌也有足够强的分发渠道。真正的问题是，它能不能在开发者工具和 Agent 工作流上赶上 OpenAI、Anthropic 的节奏。

编程能力是谷歌最需要补的课

大模型竞争进入 2026 年后，编程已经不只是“模型能力测试项”，而是最直接的产品入口。

原因很简单：AI 编程工具有高频使用场景，也能产生大量可反馈的数据。开发者每天让模型读代码、改代码、跑测试、修 bug，这些交互天然会推动下一代模型和工具链继续进化。

过去一年，Claude Code 在开发者群体里声量很高，OpenAI 也持续强化 Codex 与 ChatGPT 的协同。相比之下，谷歌虽然有 Antigravity 等产品，但外部存在感并不算强。

这也是 Gemini 3.5 Pro 被重点观察的原因。如果它只是聊天更强、回答更快，意义有限；如果它能真正改善代码理解、跨文件修改、工具调用和长任务执行，才可能改变开发者工作流。

Gemini Spark 可能是更大的变量

比模型本身更激进的，是传闻中的 Gemini Spark。

按照曝光描述，Spark 的定位不是普通聊天助手，而是全天候运行的 AI Agent。它可能接入邮件、日程、网页、任务、账号状态和个人上下文，帮助用户处理多步骤工作流。

这类产品的想象空间很大。比如：

自动整理收件箱；
帮用户跟进任务；
在网页上执行操作；
处理跨应用流程；
根据个人偏好安排日常事务。

但风险也同样明显。一个全天候 Agent 如果能访问登录状态、浏览器数据、文件、位置和第三方服务，就必须回答几个问题：什么时候需要用户确认？哪些操作必须禁止自动执行？数据会不会被共享给第三方？远程浏览器和凭证如何隔离？

所以 Spark 真正的看点，不只是“能不能帮你干活”，而是谷歌能否把权限、审计、确认机制和用户控制做得足够清楚。

MCP 工具接入说明什么

爆料里还提到，新的 Gemini 选择器可能出现 MCP 相关模型或测试入口。

如果这部分最终落地，说明谷歌也在把模型从“问答系统”推向“工具操作系统”。模型不再只是生成文本，而是要能调用外部工具、访问业务系统、读写文件、执行命令，并在多个步骤之间保持任务状态。

这和 OpenAI、Anthropic 的方向是一致的。谁能让模型更稳定地调用工具，谁就更容易把 AI 嵌进真实工作流。

不过，MCP 接入本身不是终点。真正难的是稳定性：

模型能否正确选择工具；
参数是否可靠；
失败后能不能恢复；
权限边界是否明确；
用户能不能追踪每一步操作。

如果这些问题没解决，工具越多，出错面也越大。

多模态仍然是谷歌的优势牌

谷歌最有机会打出差异化的地方，仍然是多模态。

从曝光的 SVG、交互式页面、动画和视觉生成案例看，Gemini 可能继续强化“从提示词生成可交互内容”的能力。相比单纯写一段代码，这更接近产品原型生成：用户描述一个想法，模型直接给出可操作、可调节、可预览的界面。

这条路线很适合谷歌。它既能承接 Gemini 的多模态能力，也能和 Android、Chrome、Workspace、搜索、广告、云服务等入口结合。

如果谷歌想避免只在“谁的代码模型更强”上硬拼，它很可能会把重点放到更完整的多模态 Agent 系统上。

三家公司的打法正在分化

现在的大模型竞争已经不是单一模型排行榜竞争。

OpenAI 的优势在产品迭代和分发节奏，Codex、ChatGPT、企业工具和 API 之间的联动越来越紧。

Anthropic 的优势在开发者心智和代码模型质量，Claude Code 已经成了很多人默认的 AI 编程入口。

谷歌的优势则是生态入口。Gmail、Docs、Chrome、Android、搜索、YouTube、地图和云服务构成了一个巨大的个人与企业数据网络。只要 Agent 能安全接入这些入口，谷歌就有机会从“模型追赶者”变成“工作流入口控制者”。

这也是 Gemini Spark 值得关注的原因。它不一定需要在所有基准测试上第一，但只要能进入日常工作流，就可能形成自己的护城河。

普通用户该怎么看

对普通用户来说，短期不必被每一次爆料牵着走。

更实用的观察点有三个：

Gemini 3.5 Pro 的编程能力是否真的改善，尤其是复杂仓库、长上下文和工具调用。
Gemini Spark 是否默认安全，敏感操作前是否有明确确认和可追踪记录。
谷歌是否给出清晰价格、额度和企业权限管理，而不是只展示演示效果。

如果只是生成几张漂亮截图，价值有限。能不能稳定接入真实工作流，才是这一轮 AI Agent 产品的分水岭。

对开发者意味着什么

开发者最应该关注的不是“哪个模型赢了”，而是自己的工作流是否可迁移。

现在 Claude Code、Codex、Gemini、Antigravity、Cursor、Windsurf 等工具都在抢入口。如果把所有流程都绑死在某一个平台上，未来成本、额度、模型策略或权限规则一变，迁移会很痛。

更稳妥的做法是：

重要项目保留标准 Git 工作流；
自动修改后必须看 diff；
关键任务用测试和 CI 兜底；
不把生产凭证交给不透明 Agent；
能用开放协议接工具时，优先选择可替换方案。

模型会继续变强，但工程纪律不会过时。

小结

Gemini 3.5 Pro 的爆料说明，谷歌正在加速补齐 AI 编程和 Agent 入口。模型能力提升是一部分，Gemini Spark 这类全天候 Agent 可能才是更大的战略动作。

但越是能帮用户“自动干活”的系统，越需要严格的权限边界和可验证流程。对谷歌来说，真正的挑战不只是追上 GPT-5.5 或 Claude，而是把强模型、安全机制和生态入口组合成一个可信的日常工作流。

如果这一步做成，Gemini 不一定要在每个榜单上第一，也可能重新拿回一部分 AI 入口主动权。

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”，这套方案值得折腾。只是要记住：它是本地开发助手，不是万能自动程序员。

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

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 编程工具才真的会变成生产力，而不是一个漂亮但昂贵的玩具。

ProgramBench 原始榜单数据：模型成绩、成本与 200 个任务记录

Sun, 10 May 2026 12:42:41 +0800

ProgramBench 是一个面向 AI 编程能力的新基准。它评估的不是“在现有仓库里修一个 bug”，而是让模型根据已编译的可执行文件和使用文档，从零重建一个行为一致的程序。

这篇文章只做数据整理和简要说明。下面表格保留 ProgramBench 官网公开页面中的原始记录数据，方便后续引用和对比。数据来源包括 ProgramBench 首页、Extended Results 和 Task Instances，抓取时间为 2026-05-10T12:42:41+08:00。

数据口径

Resolved：完全通过隐藏行为测试的任务比例。
Almost resolved：通过不少于 95% 行为测试的任务比例。
Cost：每个任务实例的平均 API 成本，单位为美元。
Calls：每个任务实例平均调用 LLM 的次数。
所有模型都使用 mini-SWE-agent 评测，任务总数为 200。

主榜单

#	Model	Provider	Agent	Resolved	Almost resolved	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	https://programbench.com/run/gpt-5-mini/

扩展结果

#	Model	Provider	Agent	Resolved	Almost resolved	Cost	Calls	Run
1	Claude Opus 4.7	Anthropic	mini-SWE-agent	0%	3.0%	$3.81	93	https://programbench.com/run/claude-opus-4-7/
2	Claude Opus 4.6	Anthropic	mini-SWE-agent	0%	2.5%	$11.38	260	https://programbench.com/run/claude-opus-4-6/
3	Claude Sonnet 4.6	Anthropic	mini-SWE-agent	0%	1.0%	$26.73	472	https://programbench.com/run/claude-sonnet-4-6/
4	GPT 5.4	OpenAI	mini-SWE-agent	0%	0.0%	$0.33	16	https://programbench.com/run/gpt-5-4/
5	Gemini 3.1 Pro	Google	mini-SWE-agent	0%	0.0%	$1.51	94	https://programbench.com/run/gemini-3-1-pro/
6	Gemini 3 Flash	Google	mini-SWE-agent	0%	0.0%	$0.30	85	https://programbench.com/run/gemini-3-flash/
7	Claude Haiku 4.5	Anthropic	mini-SWE-agent	0%	0.0%	$0.80	124	https://programbench.com/run/claude-haiku-4-5/
8	GPT 5.4 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.04	18	https://programbench.com/run/gpt-5-4-mini/
9	GPT 5 mini	OpenAI	mini-SWE-agent	0%	0.0%	$0.03	15	https://programbench.com/run/gpt-5-mini/

200 个任务实例原始记录

#	Repository	Description	Lang	Stars	Tests	Best Score	Task
1	junegunn/fzf	:cherry_blossom: A command-line fuzzy finder	go	79,721	1,874	81.9%	https://programbench.com/task/junegunn__fzf.b56d614/
2	jesseduffield/lazygit	simple terminal UI for git commands	go	76,901	855	56.4%	https://programbench.com/task/jesseduffield__lazygit.1d0db51/
3	BurntSushi/ripgrep	ripgrep recursively searches directories for a regex pattern while respecting your gitignore	rs	62,855	1,994	79.7%	https://programbench.com/task/burntsushi__ripgrep.3b7fd44/
4	FFmpeg/FFmpeg	Mirror of https://git.ffmpeg.org/ffmpeg.git	c	59,217	3,050	5.3%	https://programbench.com/task/ffmpeg__ffmpeg.360a402/
5	sharkdp/bat	A cat(1) clone with wings.	rs	58,487	801	33.2%	https://programbench.com/task/sharkdp__bat.f822bd0/
6	typst/typst	A markup-based typesetting system that is powerful and easy to learn.	rs	52,957	1,724	28.0%	https://programbench.com/task/typst__typst.88356d0/
7	jgm/pandoc	Universal markup converter	hs	43,632	5,228	14.1%	https://programbench.com/task/jgm__pandoc.5caad90/
8	sharkdp/fd	A simple, fast and user-friendly alternative to ‘find’	rs	42,668	1,235	78.1%	https://programbench.com/task/sharkdp__fd.40d8eb3/
9	php/php-src	The PHP Interpreter	c	40,030	14,288	4.8%	https://programbench.com/task/php__php-src.c891263/
10	duckdb/duckdb	DuckDB is an analytical in-process SQL database management system	cpp	37,657	5,650	12.4%	https://programbench.com/task/duckdb__duckdb.bdb65ec/
11	ajeetdsouza/zoxide	A smarter cd command. Supports all major shells.	rs	35,994	531	76.5%	https://programbench.com/task/ajeetdsouza__zoxide.67ca1bc/
12	jqlang/jq	Command-line JSON processor	c	34,541	6,072	89.9%	https://programbench.com/task/jqlang__jq.b33a763/
13	dandavison/delta	A syntax-highlighting pager for git, diff, grep, rg –json, and blame output	rs	30,445	950	37.3%	https://programbench.com/task/dandavison__delta.acd758f/
14	sharkdp/hyperfine	A command-line benchmarking tool	rs	27,960	291	54.3%	https://programbench.com/task/sharkdp__hyperfine.327d5f4/
15	ggreer/the_silver_searcher	A code-searching tool similar to ack, but faster.	c	27,080	1,006	59.3%	https://programbench.com/task/ggreer__the_silver_searcher.a61f178/
16	facebook/zstd	Zstandard - Fast real-time compression algorithm	c	27,013	2,038	68.8%	https://programbench.com/task/facebook__zstd.1168da0/
17	facebookresearch/fastText	Library for fast text representation and classification.	cpp	26,511	312	75.6%	https://programbench.com/task/facebookresearch__fasttext.1142dc4/
18	robertdavidgraham/masscan	TCP port scanner, spews SYN packets asynchronously, scanning entire Internet in under 5 minutes.	c	25,544	2,549	57.0%	https://programbench.com/task/robertdavidgraham__masscan.b99d433/
19	tree-sitter/tree-sitter	An incremental parsing system for programming tools	rs	24,953	1,232	37.2%	https://programbench.com/task/tree-sitter__tree-sitter.5e23cca/
20	FiloSottile/age	A simple, modern and secure encryption tool (and Go library) with small explicit keys, no config options, and UNIX-style composability.	go	22,077	676	63.5%	https://programbench.com/task/filosottile__age.706dfc1/
21	rust-lang/mdBook	Create book from markdown files. Like Gitbook but implemented in Rust	rs	21,541	1,114	55.5%	https://programbench.com/task/rust-lang__mdbook.37273ba/
22	jarun/nnn	n³ The unorthodox terminal file manager	c	21,506	477	98.1%	https://programbench.com/task/jarun__nnn.cb2c535/
23	antonmedv/fx	Terminal JSON viewer & processor	go	20,433	2,047	75.7%	https://programbench.com/task/antonmedv__fx.86d0d34/
24	mikefarah/yq	yq is a portable command-line YAML, JSON, XML, CSV, TOML, HCL and properties processor	go	15,281	2,000	39.5%	https://programbench.com/task/mikefarah__yq.602586d/
25	Y2Z/monolith	⬛️ CLI tool and library for saving complete web pages as a single HTML file	rs	15,024	713	51.2%	https://programbench.com/task/y2z__monolith.8702e66/
26	direnv/direnv	unclutter your .profile	go	14,998	849	62.0%	https://programbench.com/task/direnv__direnv.02040c7/
27	google/brotli	Brotli compression format	c	14,673	441	90.7%	https://programbench.com/task/google__brotli.b3dc9cc/
28	tomnomnom/gron	Make JSON greppable!	go	14,424	224	90.2%	https://programbench.com/task/tomnomnom__gron.88a6234/
29	XAMPPRocky/tokei	Count your code, quickly.	rs	14,300	732	69.5%	https://programbench.com/task/xampprocky__tokei.505d648/
30	ast-grep/ast-grep	⚡A CLI tool for code structural search, lint and rewriting. Written in Rust	rs	13,541	882	11.9%	https://programbench.com/task/ast-grep__ast-grep.dde0fe0/
31	cheat/cheat	cheat allows you to create and view interactive cheatsheets on the command-line. It was designed to help remind *nix system administrators of options for commands that they use frequently, but not frequently enough to remember.	go	13,278	297	59.9%	https://programbench.com/task/cheat__cheat.b8098dc/
32	jonas/tig	Text-mode interface for git	c	13,200	1,586	83.9%	https://programbench.com/task/jonas__tig.8334123/
33	ninja-build/ninja	a small build system with a focus on speed	cpp	12,895	1,438	72.3%	https://programbench.com/task/ninja-build__ninja.cc60300/
34	Canop/broot	A new way to see and navigate directory trees : https://dystroy.org/broot	rs	12,619	539	67.0%	https://programbench.com/task/canop__broot.d6c798e/
35	orf/gping	Ping, but with a graph	rs	12,433	339	78.5%	https://programbench.com/task/orf__gping.26eb5b9/
36	svenstaro/genact	🌀 A nonsense activity generator	rs	11,995	232	59.1%	https://programbench.com/task/svenstaro__genact.16f96e3/
37	lz4/lz4	Extremely Fast Compression algorithm	c	11,781	1,496	82.7%	https://programbench.com/task/lz4__lz4.1519f46/
38	o2sh/onefetch	Command-line Git information tool	rs	11,745	1,166	81.7%	https://programbench.com/task/o2sh__onefetch.e5958ce/
39	bootandy/dust	A more intuitive version of du in rust	rs	11,609	584	70.9%	https://programbench.com/task/bootandy__dust.62bf1e1/
40	ekzhang/bore	🕳 bore is a simple CLI tool for making tunnels to localhost	rs	11,075	406	68.7%	https://programbench.com/task/ekzhang__bore.8e059cd/
41	BurntSushi/xsv	A fast CSV command line toolkit written in Rust.	rs	10,757	1,182	82.7%	https://programbench.com/task/burntsushi__xsv.f430466/
42	bellard/quickjs	Public repository of the QuickJS Javascript Engine.	c	10,565	3,034	3.6%	https://programbench.com/task/bellard__quickjs.d7ae12a/
43	hatoo/oha	Ohayou(おはよう), HTTP load generator, inspired by rakyll/hey with tui animation.	rs	10,201	899	72.5%	https://programbench.com/task/hatoo__oha.8dc6349/
44	tstack/lnav	Log file navigator	cpp	10,200	990	13.4%	https://programbench.com/task/tstack__lnav.ee34494/
45	sharkdp/hexyl	A command-line hex viewer	rs	10,086	906	82.8%	https://programbench.com/task/sharkdp__hexyl.2e26437/
46	lua/lua	A copy of the Lua development repository, as seen by the Lua team. Mirrored irregularly. All communication should be through the Lua mailing list https://www.lua.org/lua-l.html	c	9,908	1,338	43.1%	https://programbench.com/task/lua__lua.c6b4848/
47	johnkerl/miller	Miller is like awk, sed, cut, join, and sort for name-indexed data such as CSV, TSV, and tabular JSON	go	9,842	14,637	22.9%	https://programbench.com/task/johnkerl__miller.8d85b46/
48	sqlite/sqlite	Official Git mirror of the SQLite source tree	c	9,434	13,514	67.0%	https://programbench.com/task/sqlite__sqlite.839433d/
49	boyter/scc	Sloc, Cloc and Code: scc is a very fast accurate code counter with complexity calculations and COCOMO estimates written in pure Go	go	8,320	464	37.7%	https://programbench.com/task/boyter__scc.515f91c/
50	ariga/atlas	Declarative schema migrations with schema-as-code workflows	go	8,311	1,318	54.8%	https://programbench.com/task/ariga__atlas.6d81150/
51	pemistahl/grex	A command-line tool and Rust library with Python bindings for generating regular expressions from user-provided test cases	rs	8,103	1,312	73.9%	https://programbench.com/task/pemistahl__grex.fa3e8ed/
52	htop-dev/htop	htop - an interactive process viewer	c	8,021	693	85.1%	https://programbench.com/task/htop-dev__htop.523600b/
53	peco/peco	Simplistic interactive filtering tool	go	7,881	1,224	76.7%	https://programbench.com/task/peco__peco.4e58dad/
54	bensadeh/tailspin	🌀 A log file highlighter	rs	7,793	615	75.8%	https://programbench.com/task/bensadeh__tailspin.6278437/
55	ducaale/xh	Friendly and fast tool for sending HTTP requests	rs	7,754	1,171	50.0%	https://programbench.com/task/ducaale__xh.4a6e44f/
56	svenstaro/miniserve	🌟 For when you really just want to serve some files over HTTP right now!	rs	7,561	304	78.6%	https://programbench.com/task/svenstaro__miniserve.8449e8b/
57	mgdm/htmlq	Like jq, but for HTML.	rs	7,520	1,455	93.9%	https://programbench.com/task/mgdm__htmlq.6e31bc8/
58	parcel-bundler/lightningcss	An extremely fast CSS parser, transformer, bundler, and minifier written in Rust.	rs	7,515	2,828	53.6%	https://programbench.com/task/parcel-bundler__lightningcss.aa2ed1e/
59	universal-ctags/ctags	A maintained ctags implementation	c	7,149	2,258	13.3%	https://programbench.com/task/universal-ctags__ctags.243595e/
60	chmln/sd	Intuitive find & replace CLI (sed alternative)	rs	7,072	810	90.9%	https://programbench.com/task/chmln__sd.87d1ba5/
61	ogham/dog	A command-line DNS client.	rs	6,640	1,300	84.2%	https://programbench.com/task/ogham__dog.721440b/
62	danmar/cppcheck	static analysis of C/C++ code	cpp	6,599	2,126	14.6%	https://programbench.com/task/danmar__cppcheck.0a5b103/
63	doxygen/doxygen	Official doxygen git repository	c	6,422	229	34.5%	https://programbench.com/task/doxygen__doxygen.966d98e/
64	sharkdp/pastel	A command-line tool to generate, analyze, convert and manipulate colors	rs	6,334	1,114	77.2%	https://programbench.com/task/sharkdp__pastel.b60e899/
65	BLAKE3-team/BLAKE3	the official Rust and C implementations of the BLAKE3 cryptographic hash function	rs	6,178	647	97.5%	https://programbench.com/task/blake3-team__blake3.15e83a5/
66	Nukesor/pueue	:stars: Manage your shell commands.	rs	6,154	638	15.4%	https://programbench.com/task/nukesor__pueue.8b9d6fe/
67	OSGeo/gdal	GDAL is an open source MIT licensed translator library for raster and vector geospatial data formats.	cpp	5,875	657	25.4%	https://programbench.com/task/osgeo__gdal.0847f12/
68	Byron/dua-cli	View disk space usage and delete unwanted data, fast.	rs	5,794	709	86.9%	https://programbench.com/task/byron__dua-cli.8570c15/
69	dundee/gdu	Fast disk usage analyzer with console interface written in Go	go	5,578	1,161	70.1%	https://programbench.com/task/dundee__gdu.ede21d2/
70	eradman/entr	Run arbitrary commands when files change	c	5,551	586	88.6%	https://programbench.com/task/eradman__entr.8e2e8b4/
71	LuaJIT/LuaJIT	Mirror of the LuaJIT git repository	c	5,518	2,967	71.5%	https://programbench.com/task/luajit__luajit.a553b3d/
72	mgechev/revive	🔥 ~6x faster, stricter, configurable, extensible, and beautiful drop-in replacement for golint	go	5,486	727	46.4%	https://programbench.com/task/mgechev__revive.201451e/
73	cweill/gotests	Automatically generate Go test boilerplate from your source code.	go	5,294	603	61.9%	https://programbench.com/task/cweill__gotests.2a672c5/
74	cordx56/rustowl	Visualize Ownership and Lifetimes in Rust	rs	5,113	589	75.2%	https://programbench.com/task/cordx56__rustowl.655bc5c/
75	abishekvashok/cmatrix	Terminal based “The Matrix” like implementation	c	5,042	508	97.0%	https://programbench.com/task/abishekvashok__cmatrix.5c082c6/
76	quinn-rs/quinn	Async-friendly QUIC implementation in Rust	rs	5,041	522	61.7%	https://programbench.com/task/quinn-rs__quinn.bb359cc/
77	alecthomas/chroma	A general purpose syntax highlighter in pure Go	go	4,910	515	15.9%	https://programbench.com/task/alecthomas__chroma.8d04def/
78	anordal/shellharden	The corrective bash syntax highlighter	rs	4,778	1,095	81.7%	https://programbench.com/task/anordal__shellharden.6a6ffd4/
79	yoav-lavi/melody	Melody is a language that compiles to regular expressions and aims to be more readable and maintainable	rs	4,748	1,205	78.9%	https://programbench.com/task/yoav-lavi__melody.f4af9b4/
80	sayanarijit/xplr	A hackable, minimal, fast TUI file explorer	rs	4,735	463	60.5%	https://programbench.com/task/sayanarijit__xplr.1751065/
81	hpjansson/chafa	📺🗿 Terminal graphics for the 21st century.	c	4,648	1,931	58.4%	https://programbench.com/task/hpjansson__chafa.dd4d4c1/
82	jhspetersson/fselect	Find files with SQL-like queries	rs	4,420	3,115	44.0%	https://programbench.com/task/jhspetersson__fselect.c3559ca/
83	ivanceras/svgbob	Convert your ascii diagram scribbles into happy little SVG	rs	4,182	472	41.3%	https://programbench.com/task/ivanceras__svgbob.6d00ad9/
84	multiprocessio/dsq	Commandline tool for running SQL queries against JSON, CSV, Excel, Parquet, and more.	go	3,867	542	80.3%	https://programbench.com/task/multiprocessio__dsq.c3ae0ba/
85	rcoh/angle-grinder	Slice and dice logs on the command line	rs	3,727	1,130	38.0%	https://programbench.com/task/rcoh__angle-grinder.9c2fc88/
86	rs/curlie	The power of curl, the ease of use of httpie.	go	3,637	701	89.3%	https://programbench.com/task/rs__curlie.5dfcbb1/
87	antonmedv/walk	Terminal file manager	go	3,598	470	74.3%	https://programbench.com/task/antonmedv__walk.bf802ef/
88	JohannesKaufmann/html-to-markdown	⚙️ Convert HTML to Markdown. Even works with entire websites and can be extended through rules.	go	3,586	885	85.5%	https://programbench.com/task/johanneskaufmann__html-to-markdown.3006818/
89	TheZoraiz/ascii-image-converter	A cross-platform command-line tool to convert images into ascii art and print them on the console. Now supports braille art!	go	3,284	465	64.1%	https://programbench.com/task/thezoraiz__ascii-image-converter.d05a757/
90	hairyhenderson/gomplate	A flexible commandline tool for template rendering. Supports lots of local and remote datasources.	go	3,135	2,926	74.7%	https://programbench.com/task/hairyhenderson__gomplate.05eb3aa/
91	ip7z/7zip	7-Zip	cpp	2,967	1,043	33.9%	https://programbench.com/task/ip7z__7zip.839151e/
92	madler/pigz	A parallel implementation of gzip for modern multi-processor, multi-core machines.	c	2,924	831	83.2%	https://programbench.com/task/madler__pigz.fe4894f/
93	tinycc/tinycc	Unofficial mirror of mob development branch	c	2,843	1,978	12.8%	https://programbench.com/task/tinycc__tinycc.9b8765d/
94	raviqqe/muffet	Fast website link checker in Go	go	2,597	293	88.1%	https://programbench.com/task/raviqqe__muffet.a882908/
95	segmentio/chamber	CLI for managing secrets	go	2,588	1,748	82.0%	https://programbench.com/task/segmentio__chamber.5f93f5f/
96	astaxie/bat	Go implement CLI, cURL-like tool for humans	go	2,563	1,091	71.8%	https://programbench.com/task/astaxie__bat.17d1080/
97	zk-org/zk	Plain text note-taking assistant	go	2,542	1,108	43.1%	https://programbench.com/task/zk-org__zk.10d93d5/
98	kisielk/errcheck	errcheck checks that you checked errors.	go	2,480	341	80.4%	https://programbench.com/task/kisielk__errcheck.dacab89/
99	mkj/dropbear	Dropbear SSH	c	2,231	682	58.1%	https://programbench.com/task/mkj__dropbear.75f699b/
100	noborus/trdsql	CLI tool that can execute SQL queries on CSV, LTSV, JSON, YAML and TBLN. Can output to various formats.	go	2,159	1,312	66.8%	https://programbench.com/task/noborus__trdsql.d8c5ff6/
101	sheepla/pingu	🐧ping command but with pingu	go	2,087	383	96.6%	https://programbench.com/task/sheepla__pingu.926d475/
102	go-critic/go-critic	The most opinionated Go source code linter for code audit.	go	2,041	493	41.6%	https://programbench.com/task/go-critic__go-critic.9aea378/
103	OSGeo/PROJ	PROJ - Cartographic Projections and Coordinate Transformations Library	cpp	1,974	5,319	73.8%	https://programbench.com/task/osgeo__proj.75d455c/
104	noborus/ov	🎑Feature-rich terminal-based text viewer. It is a so-called terminal pager.	go	1,935	1,854	87.6%	https://programbench.com/task/noborus__ov.b96c2ba/
105	samtools/samtools	Tools (written in C using htslib) for manipulating next-generation sequencing data	c	1,886	1,425	14.2%	https://programbench.com/task/samtools__samtools.aa823b5/
106	gabotechs/dep-tree	Tool for helping developers keep their code bases clean and decoupled. It allows visualising a code base complexity using a 3d force-directed graph of files and the dependencies between them.	go	1,706	865	65.2%	https://programbench.com/task/gabotechs__dep-tree.60a95a2/
107	cmatsuoka/figlet	Claudio’s FIGlet tree	c	1,606	872	77.5%	https://programbench.com/task/cmatsuoka__figlet.202a0a8/
108	lh3/seqtk	Toolkit for processing sequences in FASTA/Q formats	c	1,537	429	67.4%	https://programbench.com/task/lh3__seqtk.94e7070/
109	tukaani-project/xz	XZ Utils	c	1,522	1,410	36.0%	https://programbench.com/task/tukaani-project__xz.1007bf0/
110	skeema/skeema	Declarative pure-SQL schema management for MySQL and MariaDB	go	1,361	1,708	76.5%	https://programbench.com/task/skeema__skeema.6a76243/
111	mfridman/tparse	CLI tool for summarizing go test output. Pipe friendly. CI/CD friendly.	go	1,246	425	77.6%	https://programbench.com/task/mfridman__tparse.2416b4b/
112	lfos/calcurse	A text-based calendar and scheduling application	c	1,243	666	53.8%	https://programbench.com/task/lfos__calcurse.49180d5/
113	hooklift/gowsdl	WSDL2Go code generation as well as its SOAP proxy	go	1,219	391	86.4%	https://programbench.com/task/hooklift__gowsdl.2a06cec/
114	guumaster/hostctl	Your dev tool to manage /etc/hosts like a pro!	go	1,216	1,051	82.8%	https://programbench.com/task/guumaster__hostctl.d6d9699/
115	rs/jplot	iTerm2 expvar/JSON monitoring tool	go	1,178	583	89.0%	https://programbench.com/task/rs__jplot.2a54bcc/
116	naggie/dstask	Git powered terminal-based todo/note manager – markdown note page per task. Single binary!	go	1,157	1,278	58.8%	https://programbench.com/task/naggie__dstask.ff57396/
117	sigoden/argc	A Bash CLI framework, also a Bash command runner.	rs	1,135	995	44.1%	https://programbench.com/task/sigoden__argc.04a08f1/
118	sibprogrammer/xq	Command-line XML and HTML beautifier and content extractor	go	1,109	792	75.9%	https://programbench.com/task/sibprogrammer__xq.b89f681/
119	xorg62/tty-clock	Clock using lib ncurses	c	1,105	281	84.0%	https://programbench.com/task/xorg62__tty-clock.f2f847c/
120	unhappychoice/gittype	A CLI code-typing game that turns your source code into typing challenges	rs	1,075	741	91.3%	https://programbench.com/task/unhappychoice__gittype.34b72d0/
121	eudoxia0/hashcards	A plain text-based spaced repetition system.	rs	1,071	1,151	56.3%	https://programbench.com/task/eudoxia0__hashcards.48aa136/
122	rvben/rumdl	Fast Markdown linter and formatter written in Rust	rs	1,051	3,322	40.7%	https://programbench.com/task/rvben__rumdl.2d75c4d/
123	sclevine/yj	CLI - Convert between YAML, TOML, JSON, and HCL. Preserves map order.	go	1,041	767	74.4%	https://programbench.com/task/sclevine__yj.8016400/
124	arq5x/bedtools2	bedtools - the swiss army knife for genome arithmetic	c	1,029	1,053	38.9%	https://programbench.com/task/arq5x__bedtools2.dd57059/
125	cslarsen/jp2a	Converts jpg images to ASCII	c	1,021	631	56.1%	https://programbench.com/task/cslarsen__jp2a.61d205f/
126	blacknon/hwatch	A modern alternative to the watch command, records the differences in execution results and can check this differences at after.	rs	1,016	1,016	81.1%	https://programbench.com/task/blacknon__hwatch.edfcb62/
127	eliukblau/pixterm	Draw images in your ANSI terminal with true color	go	1,014	430	74.9%	https://programbench.com/task/eliukblau__pixterm.1a93fd5/
128	Canop/rhit	A nginx log explorer	rs	1,006	817	53.2%	https://programbench.com/task/canop__rhit.ae90bcb/
129	stathissideris/ditaa	ditaa is a small command-line utility that can convert diagrams drawn using ascii art (‘drawings’ that contain characters that resemble lines like \| / - ), into proper bitmap graphics.	java	1,005	609	20.4%	https://programbench.com/task/stathissideris__ditaa.f2286c4/
130	rbakbashev/elfcat	ELF visualizer. Generates HTML files from ELF binaries.	rs	990	564	98.2%	https://programbench.com/task/rbakbashev__elfcat.52f8cc7/
131	nuta/nsh	A command-line shell like fish, but POSIX compatible.	rs	966	1,963	83.7%	https://programbench.com/task/nuta__nsh.bdd0702/
132	dalance/amber	A code search / replace tool	rs	941	567	71.1%	https://programbench.com/task/dalance__amber.69a0f52/
133	pls-rs/pls	pls is a prettier and powerful ls(1) for the pros.	rs	932	332	62.3%	https://programbench.com/task/pls-rs__pls.4e1ae50/
134	Esubaalew/run	Universal multi-language runner and smart REPL written in Rust.	rs	919	1,212	85.2%	https://programbench.com/task/esubaalew__run.0fb9dec/
135	chirlu/sox	SoX, Swiss Army knife of sound processing	c	913	1,202	37.9%	https://programbench.com/task/chirlu__sox.42b3557/
136	clog-tool/clog-cli	Generate beautiful changelogs from your Git commit history	rs	912	575	93.0%	https://programbench.com/task/clog-tool__clog-cli.7066cba/
137	tarka/xcp	An extended `cp`	rs	911	1,184	92.6%	https://programbench.com/task/tarka__xcp.5e5b448/
138	oppiliappan/eva	a calculator REPL, similar to bc(1)	rs	907	913	88.7%	https://programbench.com/task/oppiliappan__eva.41ae245/
139	git-bahn/git-graph	Command line tool to show clear git graphs arranged for your branching model	rs	904	568	79.6%	https://programbench.com/task/git-bahn__git-graph.87b4473/
140	gromacs/gromacs	Public/backup repository of the GROMACS molecular simulation toolkit. Please do not mine the metadata blindly; we use https://gitlab.com/gromacs/gromacs for code review and issue tracking.	cpp	901	1,245	9.3%	https://programbench.com/task/gromacs__gromacs.665ea4c/
141	sirwart/ripsecrets	A command-line tool to prevent committing secret keys into your source code	rs	901	611	72.8%	https://programbench.com/task/sirwart__ripsecrets.34c9e03/
142	Drew-Alleman/DataSurgeon	Quickly Extracts IP’s, Email Addresses, Hashes, Files, Credit Cards, Social Security Numbers and a lot More From Text	rs	890	502	74.3%	https://programbench.com/task/drew-alleman__datasurgeon.d257cee/
143	alexpovel/srgn	A grep-like tool which understands source code syntax and allows for manipulation in addition to search	rs	889	1,852	69.5%	https://programbench.com/task/alexpovel__srgn.89f943b/
144	kyoheiu/felix	tui file manager with vim-like key mapping	rs	888	502	49.2%	https://programbench.com/task/kyoheiu__felix.95df390/
145	oppiliappan/statix	lints and suggestions for the nix programming language	rs	882	815	42.8%	https://programbench.com/task/oppiliappan__statix.e9df54c/
146	nachoparker/dutree	a tool to analyze file system usage written in Rust	rs	871	641	89.5%	https://programbench.com/task/nachoparker__dutree.44e877d/
147	simeg/eureka	💡 CLI tool to input and store your ideas without leaving the terminal	rs	867	344	78.8%	https://programbench.com/task/simeg__eureka.df3796c/
148	kyoh86/richgo	Enrich `go test` outputs with text decorations.	go	863	546	85.0%	https://programbench.com/task/kyoh86__richgo.313114f/
149	rochacbruno/marmite	Markdown makes sites - A Static Site Generator for Blogs	rs	837	668	45.4%	https://programbench.com/task/rochacbruno__marmite.7d4bc2d/
150	rust-embedded/svd2rust	Generate Rust register maps (`struct`s) from SVD files	rs	835	920	72.9%	https://programbench.com/task/rust-embedded__svd2rust.1760b5e/
151	konradsz/igrep	Interactive Grep	rs	827	385	73.5%	https://programbench.com/task/konradsz__igrep.aa75630/
152	nikolassv/bartib	A simple timetracker for the command line. It saves a log of all tracked activities as a plaintext file and allows you to create flexible reports.	rs	827	722	87.3%	https://programbench.com/task/nikolassv__bartib.6b9b5ce/
153	yassinebridi/serpl	A simple terminal UI for search and replace, ala VS Code.	rs	824	446	61.0%	https://programbench.com/task/yassinebridi__serpl.c48a9d7/
154	riquito/tuc	When cut doesn’t cut it	rs	820	1,196	92.7%	https://programbench.com/task/riquito__tuc.16fb471/
155	ecumene/rust-sloth	A 3D software rasterizer… for the terminal!	rs	818	380	52.6%	https://programbench.com/task/ecumene__rust-sloth.051c559/
156	crowdagger/crowbook	Converts books written in Markdown to HTML, LaTeX/PDF and EPUB	rs	813	807	60.3%	https://programbench.com/task/crowdagger__crowbook.ea214d7/
157	WGUNDERWOOD/tex-fmt	An extremely fast LaTeX formatter written in Rust	rs	789	455	80.7%	https://programbench.com/task/wgunderwood__tex-fmt.3f1aef6/
158	Stranger6667/jsonschema	A high-performance JSON Schema validator for Rust	rs	770	2,933	51.7%	https://programbench.com/task/stranger6667__jsonschema.d52e881/
159	rhysd/kiro-editor	A small terminal UTF-8 text editor written in Rust 📝🦀	rs	761	595	93.3%	https://programbench.com/task/rhysd__kiro-editor.4157485/
160	astro/deadnix	Scan Nix files for dead code	rs	745	602	85.5%	https://programbench.com/task/astro__deadnix.d590041/
161	sstadick/hck	A sharp cut(1) clone.	rs	738	855	95.7%	https://programbench.com/task/sstadick__hck.b66c751/
162	trasta298/keifu	Git genealogy, untangled. A TUI for navigating commit graphs with color and clarity.	rs	729	262	67.2%	https://programbench.com/task/trasta298__keifu.3331426/
163	AmmarAbouZor/tui-journal	Your journal app if you live in a terminal	rs	722	1,402	70.8%	https://programbench.com/task/ammarabouzor__tui-journal.2b4540d/
164	incu6us/goimports-reviser	Right imports sorting & code formatting tool (goimports alternative)	go	715	513	86.4%	https://programbench.com/task/incu6us__goimports-reviser.81bd549/
165	yaa110/nomino	Batch rename utility for developers	rs	710	313	79.9%	https://programbench.com/task/yaa110__nomino.f892499/
166	wfxr/csview	📠 Pretty and fast csv viewer for cli with cjk/emoji support.	rs	694	335	96.1%	https://programbench.com/task/wfxr__csview.8ac4de0/
167	chmln/handlr	A better xdg-utils	rs	693	722	90.7%	https://programbench.com/task/chmln__handlr.90e78ba/
168	Miserlou/Loop	UNIX’s missing `loop` command	rs	692	710	94.6%	https://programbench.com/task/miserlou__loop.209927c/
169	KSXGitHub/parallel-disk-usage	Highly parallelized, blazing fast directory tree analyzer	rs	689	531	86.1%	https://programbench.com/task/ksxgithub__parallel-disk-usage.96978ed/
170	hush-shell/hush	Hush is a unix shell based on the Lua programming language	rs	688	1,201	83.3%	https://programbench.com/task/hush-shell__hush.560c33a/
171	zevv/duc	Dude, where are my bytes: Duc, a library and suite of tools for inspecting disk usage	c	682	874	83.4%	https://programbench.com/task/zevv__duc.a58fa4e/
172	altdesktop/i3-style	🎨 Make your i3 config a little more stylish.	rs	678	539	80.0%	https://programbench.com/task/altdesktop__i3-style.f93821b/
173	wintermute-cell/ngrrram	A TUI tool to help you type faster and learn new layouts. Includes a free cat.	rs	674	303	84.5%	https://programbench.com/task/wintermute-cell__ngrrram.8ea13c3/
174	psampaz/go-mod-outdated	Find outdated dependencies of your Go projects. go-mod-outdated provides a table view of the go list -u -m -json all command which lists all dependencies of a Go project and their available minor and patch updates. It also provides a way to filter indirect dependencies and dependencies without updates.	go	669	285	98.2%	https://programbench.com/task/psampaz__go-mod-outdated.bb79367/
175	wfxr/code-minimap	🛰 A high performance code minimap render.	rs	660	313	88.8%	https://programbench.com/task/wfxr__code-minimap.0ddeea5/
176	kaushiksrini/parqeye	Peek inside Parquet files right from your terminal	rs	654	479	58.9%	https://programbench.com/task/kaushiksrini__parqeye.8072121/
177	stacked-git/stgit	Stacked Git	rs	652	1,488	20.0%	https://programbench.com/task/stacked-git__stgit.430027d/
178	Isona/dirble	Fast directory scanning and scraping tool	rs	632	718	66.7%	https://programbench.com/task/isona__dirble.e2dea9f/
179	YS-L/flamelens	Flamegraph viewer in the terminal	rs	622	224	59.4%	https://programbench.com/task/ys-l__flamelens.0b4dc33/
180	mookid/diffr	Yet another diff highlighting tool	rs	612	606	84.7%	https://programbench.com/task/mookid__diffr.2152742/
181	shashwatah/jot	⚡Rapid note management for the terminal.	rs	609	752	84.6%	https://programbench.com/task/shashwatah__jot.a92aad8/
182	Epistates/treemd	A (TUI/CLI) markdown navigator with tree-based structural navigation.	rs	603	1,569	55.1%	https://programbench.com/task/epistates__treemd.825c6dd/
183	pier-cli/pier	A CLI to organize and run short Unix shell scripts	rs	596	692	83.7%	https://programbench.com/task/pier-cli__pier.5e1bde9/
184	jrnxf/thokr	✨ sleek typing tui with visualized results and historical logging	rs	595	445	82.2%	https://programbench.com/task/jrnxf__thokr.09375ef/
185	ismaelgv/rnr	A command-line tool to batch rename files and directories	rs	581	683	82.1%	https://programbench.com/task/ismaelgv__rnr.fc0733b/
186	sitkevij/hex	🔮 Futuristic take on hexdump, made in Rust.	rs	563	823	91.7%	https://programbench.com/task/sitkevij__hex.61ae69b/
187	brocode/fblog	Small command-line JSON Log viewer	rs	561	978	86.0%	https://programbench.com/task/brocode__fblog.3b54330/
188	codesnap-rs/codesnap	🦀️📸 Pure Rust tool to generate beautiful code snapshots, provide CLI and Library	rs	557	730	59.2%	https://programbench.com/task/codesnap-rs__codesnap.f81e4f3/
189	foriequal0/git-trim	Automatically trims your branches whose tracking remote refs are merged or stray	rs	548	509	64.6%	https://programbench.com/task/foriequal0__git-trim.07c2f50/
190	axodotdev/oranda	🎁 generate beautiful landing pages for your developer tools	rs	542	767	53.6%	https://programbench.com/task/axodotdev__oranda.27d60c7/
191	elkowar/pipr	A tool to interactively write shell pipelines.	rs	541	525	57.1%	https://programbench.com/task/elkowar__pipr.fae0b17/
192	paradigmxyz/solar	Blazingly fast, modular and contributor friendly Solidity compiler, written in Rust	rs	539	1,978	43.3%	https://programbench.com/task/paradigmxyz__solar.5190d0e/
193	Lymphatus/caesium-clt	Caesium Command Line Tools - Lossy/lossless image compression tool	rs	537	575	92.3%	https://programbench.com/task/lymphatus__caesium-clt.a529b2e/
194	agourlay/zip-password-finder	Find the password of protected ZIP files.	rs	534	680	97.9%	https://programbench.com/task/agourlay__zip-password-finder.704700d/
195	rust-ethereum/ethabi	Encode and decode smart contract invocations	rs	525	997	90.9%	https://programbench.com/task/rust-ethereum__ethabi.b1710ad/
196	ArthurSonzogni/json-tui	A JSON terminal UI made in C++	cpp	438	755	71.0%	https://programbench.com/task/arthursonzogni__json-tui.17a22b6/
197	tomarrell/wrapcheck	A Go linter to check that errors from external packages are wrapped	go	374	480	80.8%	https://programbench.com/task/tomarrell__wrapcheck.c058da1/
198	NikolaDucak/caps-log	A small TUI journaling tool. 📖	cpp	370	551	61.7%	https://programbench.com/task/nikoladucak__caps-log.2cf2d1e/
199	mibk/dupl	a tool for code clone detection	go	367	373	85.0%	https://programbench.com/task/mibk__dupl.1bf052b/
200	HaliteChallenge/Halite	@twosigma’s first artificial intelligence programming challenge	cpp	202	275	80.4%	https://programbench.com/task/halitechallenge__halite.822cfb6/

怎么看这组数据

ProgramBench 的主榜单里，9 个模型的 Resolved 都是 0%。这说明在统一的轻量级 agent 设置下，当前模型还不能稳定从黑箱行为和文档中重建完整软件。

但 Almost resolved 仍然有区分度。Claude Opus 4.7 达到 3.0%，Claude Opus 4.6 为 2.5%，Claude Sonnet 4.6 为 1.0%，其余模型为 0.0%。这类指标更适合观察“接近完成”的能力，而不是只看是否完全通关。

任务实例表也很关键。它把每个开源项目的语言、星标数、测试数量和当前最佳得分列出来，可以看出 ProgramBench 覆盖了压缩、搜索、数据库、编译器、命令行工具、媒体处理等不同类型的软件。对 AI Coding 来说，这比单纯算法题更接近真实工程压力。

ProgramBench 0% 解读：AI 编程真正可怕的不是失败，而是路线图清楚了

Sun, 10 May 2026 12:32:39 +0800

AI 编程圈最近出现了一个新的基准测试：ProgramBench。表面上看，它给出的结果很让程序员安心：九个主流模型在 fully resolved 指标上全部是 0%，没有任何模型能完整通过一个任务。

但这件事真正值得紧张的地方，不是今天的大模型还做不到，而是完整软件工程第一次被清楚地做成了一套可评测、可排名、可反复优化的题。

一旦任务被定义清楚，AI 行业最擅长的事情就会发生：刷题、迭代、追榜，然后把原来做不到的事情一点点推到可用边缘。

ProgramBench 到底在测什么

很多编程基准测试，测的是补函数、改 bug、通过单元测试，或者在已有项目里完成一个小功能。ProgramBench 更狠，它不给源代码，也不给项目结构，更不给现成测试用例。

它给模型的材料主要只有两类：

一个已经编译好的可执行文件。
这个程序的使用文档。

模型需要自己运行可执行文件，观察输入输出行为，理解命令行参数、边界情况、错误信息、数据存储方式，然后重新实现一个行为一致的程序。

这已经不是“写一段代码”，而是一个简化但完整的软件工程任务：要理解需求、探索行为、选择语言、设计结构、写源码、提供构建方式，并尽量通过隐藏测试。

根据 ProgramBench 官方介绍，它目前包含 200 个任务，覆盖从小型命令行工具到 PHP、FFmpeg、SQLite 等大型真实项目。测试集由 agent-driven fuzzing 生成，总量超过 248,000 个行为测试。

如果把测试流程拆开，ProgramBench 大致是在考四件事：

读懂文档：理解程序应该提供哪些命令、参数和输出。
探索行为：反复运行二进制程序，观察正常输入、异常输入和边界情况。
重建实现：自己选择语言和项目结构，写出一个行为接近的替代程序。
通过隐藏测试：不仅常规行为要对，错误处理、输出格式和边界条件也要尽量一致。

所以它的搜索价值不只是“又一个跑分”，而是回答一个更具体的问题：大模型能不能在没有源码的情况下，只靠文档和黑箱行为，从零复刻一个真实软件。

为什么结果是 0%

ProgramBench 的主要指标是 fully resolved，也就是一个任务里的测试全部通过才算完成。当前 leaderboard 上，九个模型在这个指标上都是 0%。

参与测试的模型包括 Claude、GPT、Gemini 等系列，统一使用 mini-SWE-agent 作为基线 agent。Claude Opus 4.7 在 almost resolved 指标上表现最好，大约有 3.0% 的任务通过了至少 95% 的测试；Claude Opus 4.6 是 2.5%，Claude Sonnet 4.6 是 1.0%。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash 等在 almost resolved 上都是 0.0%。

这说明今天的大模型加一个轻量级 agent，还无法从零重建完整软件。即使是最简单的任务，也很难做到所有细节都完全对齐。

但也要注意：这次测试用的是 mini-SWE-agent，不是 Claude Code，也不是 Codex。换成更强的 coding agent、更多工具链支持、更长时间的探索流程，结果可能会提高。所以这个结果更准确的说法是：当前模型加轻量 agent，还不足以稳定完成完整软件重建。

fully resolved 和 almost resolved 是什么意思

读 ProgramBench 的结果时，最容易误解的是这两个指标。

fully resolved 是最严格的指标：一个任务里的所有隐藏测试都通过，才算完整解决。只要还漏掉一个边界条件、一个报错格式、一个命令参数行为，就不能算 fully resolved。

almost resolved 则更像“接近完成”：如果一个任务至少通过了 95% 的测试，就算进入 almost resolved。它能反映模型有没有把大部分行为做出来，但还不能代表程序已经可以替代原软件。

这也是为什么 0% 要分开看。fully resolved 的 0% 说明模型还无法完整交付；almost resolved 的差距则能看出哪些模型已经在部分任务上接近复刻成功。比如 Claude Opus 4.7 的 almost resolved 约为 3.0%，说明它确实在少量相对简单的任务上更接近完成，但距离稳定重建完整软件仍然很远。

为什么 mini-SWE-agent 会影响测试结果

这次测试使用统一的 mini-SWE-agent，好处是公平：不同模型都跑在同一套轻量 agent 框架里，结果更容易横向比较。

但它也会限制上限。完整软件重建不只取决于模型本身，还取决于 agent 是否会规划探索策略、是否能管理长期任务、是否会自动生成测试、是否能反复定位失败原因、是否能整理项目结构。

mini-SWE-agent 更像一个统一基线，而不是最强工程环境。Claude Code、Codex 这类更完整的 coding agent，通常会提供更强的工具调用、上下文组织、任务拆解和多轮修复能力。如果换成这些工具，结果可能会更好。

所以 ProgramBench 这次结果更适合理解为：当前模型在轻量 agent 环境下还做不到完整软件重建。它不是在证明“模型永远做不到”，也不是在完整评估所有商业 coding agent 的上限。

它和 SWE-bench 的差别

SWE-bench 已经是 AI 编程领域里很重要的基准。它让模型在真实 GitHub 仓库里读 issue、改代码、提交补丁，用来测试模型解决真实 bug 的能力。

但 SWE-bench 本质上仍然是在已有项目上修车：车还在，技术栈、目录结构、代码组织、架构设计都已经有人完成了。模型只需要找到问题，把坏掉的零件修好。

ProgramBench 更接近重新造车：你只知道这个车应该有什么行为，看到红灯会停、遇到行人会鸣笛，剩下的结构、语言、模块、构建方式，全都要自己决定。

这就是为什么它难得多。它不再只考局部补丁能力，而是在考软件架构、系统推理、行为探索、自动测试、多轮纠错和长期工程设计。

可以用一张表来理解两者差别：

维度	SWE-bench	ProgramBench
起点	已有 GitHub 仓库和 issue	已编译可执行文件和使用文档
是否给源码	给源码	不给源码
主要任务	修复已有项目里的 bug	从行为重新实现一个完整程序
技术栈	原项目已经确定	模型自己选择
项目结构	原项目已经存在	模型自己设计
测试方式	提交补丁后跑测试	用隐藏行为测试验证复刻程度
主要考点	读代码、定位问题、补丁修复	行为探索、系统抽象、架构设计、完整实现

这也是为什么 ProgramBench 更适合被看作下一阶段 AI Coding 的目标：它把“修现有代码”推进到了“重建完整软件”。

0% 并不等于安全

看到 0%，很多人的第一反应可能是：程序员饭碗暂时保住了。

短期看，这句话没错。今天的大模型还不能稳定完成完整软件工程，尤其是在没有源码、没有测试用例、没有项目结构的情况下。需求澄清、架构设计、长期维护、安全控制、团队协作、业务理解，仍然是人类软件工程师的重要优势。

但如果把 0% 理解成“AI 编程到头了”，就太乐观了。

ProgramBench 真正改变的是问题定义。以前大家知道 AI 可以补代码，也知道 AI 可以修 bug，但“从一个可执行文件和文档重建完整软件”这件事没有被清楚地放到统一赛道里。现在它被做成了 200 道题、统一评测、统一排名。

这意味着模型公司、agent 公司、开发工具公司都知道下一步该往哪里发力：让 AI 从写代码片段，进化到维护、重建和交付完整软件系统。

为什么要断网和防作弊

ProgramBench 的设计里有一个细节很重要：它要防止模型作弊。

早期测试中，模型会尝试直接从 GitHub 找源码，或者通过包管理器下载包含源码的包，甚至去系统缓存目录里翻找已经下载过的软件包。这样当然会破坏测试目的，因为问题就不再是“能不能从行为重建软件”，而是“能不能找到原始源码”。

所以 ProgramBench 使用了沙箱和断网环境，不允许访问互联网，也不允许反编译、反汇编或读取可执行文件内容。模型只能执行程序，观察行为，再自己实现。

这个限制让测试更干净，也更接近它真正想回答的问题：大语言模型能不能从程序行为和文档出发，自己构建一个可运行的软件项目。

更值得警惕的是代码形态变化

ProgramBench 还有一个比 0% 更值得软件工程师思考的发现：模型生成的代码往往不像人类工程师会写的项目。

公开材料里提到，模型倾向于生成更少的文件、更浅的目录、更少的函数，以及更长的单个函数。也就是说，它可能写出一个巨大的、能跑的脚本，而不是一个结构清晰、便于人类维护的软件工程项目。

从传统软件工程角度看，这通常是很差的代码。文件太少、函数太长、抽象不足、模块边界不清，都会让人类难以维护。

但问题在于，AI 未必需要按照人类维护代码的方式写代码。

人类强调抽象、命名、目录结构和模块边界，主要是因为人类记忆有限、团队需要协作、代码需要长期复用。AI 如果可以用更长上下文、检索系统和自动测试反复重写代码，它可能并不那么需要人类熟悉的这些工程规范。

这会带来一个很现实的风险：未来 AI 写出的软件也许能跑、甚至很快，但人类越来越难插手维护。

程序员真正要升级什么

ProgramBench 的结果对程序员不是简单的好消息，也不是简单的坏消息。

短期看，完整软件工程仍然很难，程序员不会因为这次 benchmark 立刻失业。尤其是架构判断、需求澄清、安全把控、质量验收和业务理解，仍然需要人类负责。

长期看，程序员的工作会继续上移。真正危险的不是“不会写代码”的人，而是只会写代码、但不会定义问题、验证结果、组织工具链和控制风险的人。

未来的软件工程师可能更像：

需求定义者：把模糊业务问题变成可执行目标。
系统验收者：判断 AI 生成结果是否真的满足需求。
工具链组织者：组合模型、agent、测试、部署和监控。
质量负责人：控制安全、可维护性、边界条件和长期风险。
业务和技术之间的翻译者：把真实问题转成工程系统能处理的约束。

如果 AI 真的从代码助手变成完整软件工程师，人类程序员的价值就不再只是亲手写每一行代码，而是定义什么值得写、怎样算写对、哪里不能出错。

小结

ProgramBench 的 0% 不是终点，而是新阶段的起点。

它说明今天的大模型还不能从零稳定重建完整软件系统；但它也把下一代 AI Coding agent 的目标定义得非常清楚：从局部补丁走向完整项目，从代码片段走向系统交付。

对程序员来说，短期可以松一口气，但长期不能只盯着“AI 现在还不行”。更重要的是尽快把自己从代码执行者升级为问题定义者、结果验收者和风险控制者。

真正值得紧张的不是 AI 今天考了 0%，而是题目已经摆出来了。

GPT-5.5、GPT-5.4 与 GPT-5.3-Codex 如何取舍

Sun, 10 May 2026 08:43:17 +0800

如果只看一句话，结论其实很直接：默认选 GPT-5.5，预算更敏感或任务难度中等时选 GPT-5.4，只有在 Codex 环境里做更长时间的软件工程任务，或者需要 Cloud Tasks、Code Review 这类能力时，再重点看 GPT-5.3-Codex。

这个判断不只是主观体验，OpenAI 在 Codex 官方文档里的推荐也已经比较明确。到 2026-05-10 为止，Codex 文档仍然写着：大多数任务优先从 gpt-5.5 开始；如果还没有开放 gpt-5.5，继续用 gpt-5.4；轻量任务或子任务则更适合 gpt-5.4-mini。

三个模型的定位差异

先看官方定位。

GPT-5.5 是 Codex 里的最新前沿模型，面向复杂编程、电脑操作、知识工作和研究型工作流。它更像“默认主力模型”，适合复杂分析、多步任务、跨文件修改、方案设计和较重的文档工作。

GPT-5.4 则是一个更稳的全能型选择。官方描述是：它把 GPT-5.3-Codex 的强代码能力带到了更强的推理、工具使用和 agentic workflow 里。换句话说，它不是“弱化版 5.5”，而是一个更均衡、更容易长期当主力的模型。

GPT-5.3-Codex 仍然是很强的代码模型，但它的核心优势更集中在真实软件工程和 Codex 原生工作流里。官方文档还专门说明：它是面向 agentic coding tasks 优化的模型，而且 GPT-5.4 的编码能力本身就已经继承了它的长处。

所以今天再选模型，不太适合把 GPT-5.3-Codex 直接理解成“最强编程模型”。在大部分日常开发场景里，更推荐先看 GPT-5.5 和 GPT-5.4。

按使用场景怎么选

如果你的任务是日常问答、复杂解释、资料整理、文件分析、长文信息综合，GPT-5.5 最合适。它不仅适合写代码，也更适合处理“代码之外但又很费脑子”的知识工作。

如果你的任务是复杂编程、重构、排错、架构设计、多文件修改，仍然优先 GPT-5.5。Codex 官方推荐也是这样写的：在能用 gpt-5.5 的地方，大多数任务先从它开始。

如果你更在意额度和消耗，希望在质量很高的前提下把成本压下来，GPT-5.4 往往是更合理的默认值。对很多常规开发、普通改写、一般翻译、脚本生成和 bug 修复任务来说，GPT-5.4 已经足够强，而且更省额度。

如果你是在 Codex CLI、IDE 扩展或 App 里做更像“工程代理”的事情，比如长时间读仓库、持续改代码、排队跑任务、做 Cloud Tasks 或 Code Review，GPT-5.3-Codex 仍然有存在感。原因不是它比 GPT-5.5 更先进，而是当前 Codex 的 Cloud Tasks 和 Code Review 仍然运行在 GPT-5.3-Codex 上，这决定了它在工程流里还没有退场。

消耗额度差多少

在 Codex 的 credits 计费表里，这三个模型的差异非常清楚。

按 Business / New Enterprise 的 token 计费口径看：

GPT-5.5：输入 125 credits / 1M tokens，缓存输入 12.5 credits，输出 750 credits
GPT-5.4：输入 62.5 credits / 1M tokens，缓存输入 6.25 credits，输出 375 credits
GPT-5.3-Codex：输入 43.75 credits / 1M tokens，缓存输入 4.375 credits，输出 350 credits

这意味着，按名义费率看，GPT-5.4 大约是 GPT-5.5 的一半，做同样长度的输入输出时，通常能省接近 50% 的额度。GPT-5.3-Codex 的输入更便宜，但输出已经和 GPT-5.4 很接近，所以它并不是那种“明显更便宜很多”的选择。

还有一个容易忽略的点：Codex 官方又特别写了一句，GPT-5.5 uses significantly fewer tokens to achieve results comparable to GPT-5.4。也就是说，虽然它的单价更高，但在某些复杂任务里，可能会靠更少的 token 和更少返工把差距拉回来。

不过对固定模板文章改写、翻译、SEO 描述生成这种输入输出长度都比较稳定的任务来说，这种“少走弯路”的优势通常没有复杂工程任务那么明显。实际消耗上，GPT-5.4 大多还是更省，通常可以理解为省掉大约 45% 到 50%。

Codex 使用限制上的区别

除了单价，Codex 里的可用方式也不一样。

截至 2026-05-10，GPT-5.5 在 Codex 里是推荐模型，但目前只在使用 ChatGPT 登录的 Codex 中提供，不支持 API key 鉴权。GPT-5.4 和 GPT-5.3-Codex 则支持 API 访问。

另外，GPT-5.5 和 GPT-5.4 目前都不支持 Codex Cloud Tasks 和 Code Review；这两项仍然是 GPT-5.3-Codex 的主场。也就是说，如果你说的是“在 Codex 里长时间跑工程任务”，那就不能只看模型本身强不强，还要看对应功能是不是只有 GPT-5.3-Codex 才能跑。

如果你只是本地消息使用，Plus 计划下官方给出的 5 小时窗口大致是：

GPT-5.5：15-80
GPT-5.4：20-100
GPT-5.3-Codex：30-150

从这里也能看出一个现实差异：GPT-5.5 最强，但在固定额度下可用次数通常更少；GPT-5.4 更均衡；GPT-5.3-Codex 在本地消息上反而看起来更耐用一些。

常用场景怎么选

日常使用里有不少高频任务。更实用的看法，不是抽象地说“哪个更强”，而是按场景一个一个拆开看。

1. 日常问答、资料整理、长文总结

GPT-5.5：最适合。它更擅长处理模糊问题、补齐上下文、把零散信息整理成结构化结果。

GPT-5.4：适合普通总结和批量整理。难度不高、数量很多时，通常更划算。

GPT-5.3-Codex：不太适合当主力。能做，但这不是它最有优势的场景。

2. 技术概念解释、代码讲解、读旧项目

GPT-5.5：适合复杂项目。跨文件关系多、调用链长、历史包袱重时更稳。

GPT-5.4：适合常规阅读理解。看函数、看模块、解释配置、帮你快速接手项目都很好用。

GPT-5.3-Codex：更偏工程执行，不是最优先的“讲解型模型”。

3. 写脚本、小工具、SQL、Shell、正则

GPT-5.5：适合脚本背后还有系统设计、联动多个服务、涉及复杂约束的情况。

GPT-5.4：最适合当默认主力。大多数脚本、小工具、SQL 和命令行任务都够用，而且更省额度。

GPT-5.3-Codex：如果脚本只是整个工程代理链条的一部分，可以考虑；单独写小脚本时不必优先选它。

4. 改 bug、改小功能、补测试、普通开发

GPT-5.5：适合稍复杂的修复，比如需要先分析原因、再跨文件修改、最后补测试。

GPT-5.4：最适合日常开发主力。普通 bug、小功能、测试样板、重命名、格式整理这类任务，性价比最好。

GPT-5.3-Codex：能做，但如果没有 Cloud Tasks 或工程代理需求，通常不是第一选择。

5. 复杂重构、架构设计、疑难排错

GPT-5.5：最适合。复杂任务里最贵的是返工，不是单次输出；GPT-5.5 更适合做主解题模型。

GPT-5.4：适合中等复杂度任务。可以做方案和重构，但在特别长的上下文、多步推理和高不确定性问题上通常不如 GPT-5.5 稳。

GPT-5.3-Codex：偏执行，不是这类高难决策任务的默认优先级。

6. 批量轻任务、重复任务、拆子任务

GPT-5.5：能做，但通常不划算。

GPT-5.4：最适合。批量改注释、批量改格式、批量生成样板代码、批量改内容时，最平衡。

GPT-5.3-Codex：如果任务已经放进 Codex 的工程流程里，可以考虑；单看性价比，仍然通常不如 GPT-5.4。

7. 自动化流水线、代理执行、持续读写仓库

GPT-5.5：适合做前期方案设计、规则制定、复杂任务拆分。

GPT-5.4：适合写自动化脚本、补中等复杂度流程逻辑，尤其是在 API 可接入的情况下。

GPT-5.3-Codex：最值得关注。因为 Codex 的 Cloud Tasks 和 Code Review 还运行在它上面，所以它更适合“让系统自己跑”的工程场景。

8. 重要页面文案、品牌介绍、最终润色

GPT-5.5：最适合。自然度、风格控制、上下文一致性最好。

GPT-5.4：适合大多数普通页面和日常更新，重要页面可以先写初稿再交给 GPT-5.5 精修。

GPT-5.3-Codex：不适合当主要文案模型。

9. 网站固定模板文章改写、翻译、SEO 描述

GPT-5.5：适合做模板设计、最终润色、重要页面定稿，以及把中文翻成更自然的英文。

GPT-5.4：最适合批量生产。普通文章改写、固定结构翻译、商品文案重写、Meta 描述批量生成，通常质量和成本最平衡。

GPT-5.3-Codex：不适合当主要文案模型，更适合写批处理脚本、清洗 HTML、保留标签结构、改自动发布流程。

10. 电商商品文案、分类页、批量内容运营

GPT-5.5：适合定规则、做抽检、做高价值页面的最终润色。

GPT-5.4：最适合批量生产。商品标题、分类页说明、批量活动文案、长尾 SEO 内容这类任务上，质量和成本更平衡。

GPT-5.3-Codex：适合写抓取、清洗、批处理、自动发布脚本，不适合负责主要文案。

如果把这些场景进一步压缩成一句话：

复杂脑力活、复杂分析、复杂文案：优先 GPT-5.5
日常开发、批量生产、重复任务：优先 GPT-5.4
Codex 工程代理、Cloud Tasks、Code Review：重点看 GPT-5.3-Codex

最后怎么取舍

如果你只是平时写代码、改 bug、问技术问题、顺手做一些文档工作，GPT-5.4 是很稳的主力选择。

如果你要做的是更复杂的项目分析、多文件修改、架构方案、深度排错，或者希望一个模型同时覆盖编程和复杂知识工作，直接优先 GPT-5.5。

如果你在 Codex 环境里看重的是工程工作流本身，比如 Cloud Tasks、Code Review、长时间代理执行，那么 GPT-5.3-Codex 仍然值得保留，但它已经不太适合被当成“默认第一选择”。

对固定模板文章站来说，更实用的搭配通常是：

GPT-5.4 负责批量生产
GPT-5.5 负责定模板、做抽检、做最终润色
GPT-5.3-Codex 负责写自动化工具，而不是负责主要文案

小结

现在更合理的默认顺序是：GPT-5.5 第一，GPT-5.4 第二，GPT-5.3-Codex 放到更偏工程代理和 Codex 特定能力的场景里使用。

如果你问的是“同样一篇模板文章改写，GPT-5.4 比 GPT-5.5 能省多少”，按官方 credits 表和这类任务的典型 token 结构看，通常可以按“省接近一半”来理解。对批量站内容来说，这个差距已经足够大，所以最常见的做法不是全程上 GPT-5.5，而是先用 GPT-5.5 把规则和风格定好，再把大批量任务交给 GPT-5.4。

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 运行时。

DeepSeek-TUI：在终端里运行 DeepSeek 编程 Agent

Fri, 08 May 2026 13:34:05 +0800

DeepSeek-TUI 是一个运行在终端里的 AI 编程 Agent。它围绕 DeepSeek V4 模型设计，通过 deepseek 命令启动，可以在 TUI 界面里读写文件、执行 shell 命令、搜索网页、管理 git、调用 MCP server，并支持子 Agent 协作。

它和普通聊天 CLI 的区别在于：DeepSeek-TUI 更像一个终端工作台。它不只是把问题发给模型，而是把“看代码、改文件、跑命令、检查诊断、保存会话、恢复状态”这些开发动作整合在一起。

项目仓库显示，DeepSeek-TUI 主要由 Rust 编写，许可证为 MIT。GitHub 项目描述是“Coding agent for DeepSeek models that runs in your terminal”。

它适合谁

DeepSeek-TUI 适合喜欢在终端里工作的开发者，尤其是这些场景：

想用 DeepSeek 模型做代码修改和项目分析。
不想打开完整 IDE，只想在终端里处理任务。
希望 AI 工具能读写本地 workspace。
需要 Plan、Agent、YOLO 这类不同自动化程度的模式。
希望保留会话、恢复长任务、回滚工作区改动。
想接入 MCP、LSP 诊断、HTTP/SSE runtime API 等扩展能力。

如果你只需要简单问答，普通 Web 端或轻量 CLI 已经够用。DeepSeek-TUI 更适合把模型真正放进本地开发流程里。

安装方式

DeepSeek-TUI 发布为 Rust 二进制程序，常用入口命令是 deepseek，配套 TUI 运行时是 deepseek-tui。README 提供了多种安装方式。

如果你已经使用 Node.js，可以通过 npm 安装：

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

npm 包本身是安装器和 wrapper，会下载对应平台的预编译 Rust 二进制文件。npm 包要求 Node.js >=18。

如果不想依赖 Node.js，也可以通过 Cargo 安装两个二进制：

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

macOS 用户可以使用 Homebrew：

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

也可以直接从 GitHub Releases 下载预编译版本。README 中列出的预构建平台包括 Linux x64/ARM64、macOS x64/ARM64 和 Windows x64。

Docker 运行示例：

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

国内网络环境下，如果 npm 或 GitHub 下载较慢，可以使用 npm 镜像、Cargo 镜像，或者从 Releases 手动下载二进制文件。

首次配置 API Key

首次启动时，DeepSeek-TUI 会提示输入 DeepSeek API key。保存后，它会写入：

`1`	`~/.deepseek/config.toml`

也可以提前通过命令配置：

1
2

deepseek auth set --provider deepseek
deepseek auth status

如果更喜欢环境变量，也可以这样启动：

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

配置完成后，可以用下面命令检查环境：

`1`	`deepseek doctor`

如果 deepseek doctor 提示 key 来源异常，可以用 deepseek auth status 查看当前 credential 来源。README 说明中提到，保存到配置文件的 key 优先级高于 keyring 和环境变量。

清除保存的 key：

`1`	`deepseek auth clear --provider deepseek`

Auto mode：自动选择模型和思考强度

DeepSeek-TUI 支持 auto 模式：

`1`	`deepseek --model auto`

也可以在 TUI 里使用：

`1`	`/model auto`

Auto mode 会同时决定两件事：

模型：deepseek-v4-flash 或 deepseek-v4-pro
Thinking：off、high 或 max

它的流程是：真正执行用户任务前，先用一次较小的路由调用分析当前请求和近期上下文，然后决定本轮应该使用哪个模型和思考级别。简单问题可以走 Flash 和低思考；复杂编码、调试、架构、安全审查或多步骤任务可以切到 Pro 或更高 thinking。

需要注意的是，auto 是 DeepSeek-TUI 本地功能。上游 API 不会收到 model: "auto"，而是收到 TUI 最终选择出来的具体模型和 thinking 设置。

如果你要做基准测试、控制成本，或者必须固定某个模型行为，建议直接指定模型，而不是使用 auto。

三种工作模式

DeepSeek-TUI 提供三种模式，自动化程度不同：

模式	用途
Plan	只读探索，模型先分析项目并提出计划
Agent	默认交互模式，工具调用需要 approval gate
YOLO	自动批准工具调用，适合可信 workspace

Plan 模式适合先看项目、定位问题、讨论方案。Agent 模式适合日常编码，模型可以执行多步任务，但关键动作仍有确认。YOLO 模式效率最高，但风险也最大，应该只在你完全信任的仓库和任务里使用。

这类工具能修改本地文件、运行命令，因此不要在不熟悉的目录里随便启用高自动化模式。涉及删除、迁移、批量改写、部署等任务时，最好保持 Agent 模式并看清每一步。

工具能力

根据 README，DeepSeek-TUI 的工具能力覆盖面很广，包括：

文件读写和 apply patch。
shell 命令执行。
git 操作。
web search 和 browse。
子 Agent 协作。
MCP server 接入。
LSP 诊断。
会话保存和恢复。
工作区回滚。
持久化任务队列。
HTTP/SSE runtime API。
skills 系统。

其中比较实用的是 LSP 诊断和工作区回滚。

LSP 诊断可以在编辑后把 rust-analyzer、pyright、typescript-language-server、gopls、clangd 等工具的错误和警告反馈给模型，减少“模型改完但项目编不过”的情况。

工作区回滚通过 side-git 快照记录每轮前后的状态，并提供 /restore 和 revert_turn 一类恢复能力。它不直接操作你仓库本身的 .git，但仍建议在重要仓库里保持正常 git 提交习惯。

常用命令

README 中列出的常用命令包括：

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

这些命令覆盖了交互式 TUI、一次性 prompt、模型指定、会话恢复、HTTP 服务、ACP 适配、PR 预处理、MCP 管理和更新检查。

Zed 和 ACP

DeepSeek-TUI 可以作为 Agent Client Protocol server 被编辑器调用。以 Zed 为例，可以添加自定义 agent server：

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

README 说明中也提醒：当前 ACP 支持新会话和 prompt response，但工具驱动的编辑和 checkpoint replay 还没有通过 ACP 暴露。

配置和多 provider

用户配置文件位于：

`1`	`~/.deepseek/config.toml`

项目级 overlay 可以放在：

`1`	`<workspace>/.deepseek/config.toml`

但 README 说明中明确限制了一些字段不能放进项目 overlay，例如 api_key、base_url、provider、mcp_config_path。这有助于避免把敏感配置随项目提交出去。

DeepSeek-TUI 默认 provider 是 deepseek，也支持 NVIDIA NIM、Fireworks、OpenAI-compatible endpoint、SGLang、vLLM、Ollama 等路径。

例如配置 OpenAI-compatible endpoint：

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

自托管 Ollama 示例：

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

成本和上下文

DeepSeek-TUI 围绕 DeepSeek V4 设计，README 中提到 deepseek-v4-pro 和 deepseek-v4-flash 支持 1M-token context，并且 TUI 会显示 token、成本估算、prefix-cache 命中和未命中等信息。

这对长任务很重要。AI 编程 Agent 往往会不断读文件、总结历史、携带上下文，成本不只取决于模型单价，也取决于它是否能复用 prefix cache、是否及时压缩上下文、是否避免无意义的大段输出。

如果只是轻量改动，deepseek-v4-flash 或 auto mode 可能更合适。复杂重构、长上下文调试和架构分析，再考虑更高 thinking 或 Pro 模型。

由于模型价格和优惠会变化，真正使用前仍建议查看 DeepSeek 官方定价页，以及 TUI 当前版本里的成本估算说明。

使用建议

建议从低风险流程开始：

在一个小型测试仓库里安装并运行 deepseek doctor。
使用 Plan 模式让它只读分析项目。
在 Agent 模式里让它做小范围修改。
每次修改后用 git diff 和测试命令确认结果。
熟悉 /restore、会话恢复和配置路径后，再尝试更长任务。
YOLO 模式只用于你能接受自动修改的临时分支或测试目录。

不要把 API key 写进项目目录，也不要把 ~/.deepseek/config.toml 复制到公共仓库。涉及公司代码时，还要确认模型服务、日志、web search 和第三方 provider 是否符合内部安全要求。

小结

DeepSeek-TUI 是一个功能比较完整的终端 AI 编程 Agent。它把 DeepSeek V4、TUI、工具调用、LSP 诊断、会话恢复、工作区回滚、MCP 和 skills 系统放在同一套 Rust 工具链里，适合愿意在终端里完成 AI 辅助开发的人。

它不是最轻的 DeepSeek 客户端，但它的优势也正在这里：它把“模型对话”推进到“可执行的本地开发流程”。如果你已经习惯 Claude Code、Codex 或其他终端 Agent，那么 DeepSeek-TUI 值得作为 DeepSeek 模型方向的一个重点选择。

参考资料

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 值得试试。

参考资料

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

DeepSeek V4 Flash 做 Godot 游戏 Demo：几毛钱能跑通到什么程度？

Wed, 06 May 2026 09:22:18 +0800

DeepSeek V4 Flash 用来开发 Godot 游戏 Demo，到底能不能打？

重点很直接：它能不能做出一个可运行、可观察、带物理效果的 Godot 小 Demo。

结论先说：可以跑通，效果不算商业级，但已经足够作为玩法原型和物理交互 Demo 使用。更重要的是，成本非常低，适合快速验证想法。

Demo 表现

这个 Demo 的重点是物理交互。

几个比较直观的效果包括：

绳子可以被切断。
箱子会掉到地上。
调大质量后，箱子碰撞会更猛烈。
绳子表现出比较明显的弹性。
调整摩擦力和弹性后，箱子会出现明显的滑动和反弹。

从呈现效果看，它已经不是“只生成几段 Godot 脚本”那么简单，而是一个能运行、能观察物理表现的小型原型。

可用程度

这个 Demo 的价值在于“能跑、能看、能改”。它不是完整游戏，也不是可以直接商业化的工程，但已经能说明几个问题：

DeepSeek V4 Flash 能理解 Godot Demo 的基本目标。
AI Agent 可以把需求转成可运行工程。
Godot 物理交互这种非网页类任务，已经可以进入低成本原型阶段。
对个人开发者来说，它能把“想法”快速变成“能看的东西”。

如果目标是做一个正式游戏，它当然还不够；但如果目标是验证“这个玩法有没有意思”“物理效果大概能不能做出来”，这个 Demo 已经可用。

成本意义

最值得关注的不是画面有多精致，而是成本。

如果一个 Godot 物理 Demo 只需要几毛钱级别的模型成本，就能得到一个可运行版本，那么它的意义就不是替代专业游戏开发，而是大幅降低原型试错成本。

以前想验证一个小游戏想法，至少需要自己熟悉 Godot、写脚本、调场景、调物理参数。现在可以先让 AI Agent 生成一个可运行版本，再由人判断方向对不对。

对独立开发者来说，这类低成本试错很有用：

快速验证玩法概念。
生成临时 Demo 给别人看。
探索 Godot API 和物理系统。
把想法转成能跑的初版工程。
在不确定方向前减少手写代码成本。

DeepSeek V4 Flash 的表现

比较值得注意的是，使用的是 DeepSeek V4 Flash，而不是更贵、更重的旗舰模型。

它在“低成本原型”这个定位上表现不错。它不是最强、最稳、最适合交付生产工程的模型，但在预算敏感、想快速试一下方向的场景里，很有吸引力。

适合什么场景

DeepSeek V4 Flash + Agent + Godot 更适合下面这些任务：

小型玩法原型。
物理效果 Demo。
UI 或交互概念验证。
教学示例。
辅助理解 Godot 项目结构。
生成第一版可运行工程。

不太适合直接承担这些任务：

大型游戏架构。
复杂角色控制器。
网络同步。
商业项目核心代码。
高精度物理模拟。
不经过人工测试的自动提交。

换句话说，它适合做“第一稿”和“试验场”，不适合当生产工程负责人。

这说明了什么

这说明，AI 编程正在从网页、脚本、后端接口，继续向游戏开发和交互原型扩展。

过去游戏开发的门槛很高，尤其是引擎、脚本、资源管理和物理系统混在一起时，新手很容易卡住。现在模型加 Agent 工具，可以先把工程搭起来，让开发者把注意力放在玩法判断和效果调优上。

它带来的变化可能有三点：

第一，游戏原型会更便宜。很多想法不用等到完整开发阶段才验证，可以先得到可运行 Demo。

第二，独立开发者会更敢尝试。不会 Godot 的人，也可以借助 AI 先摸到项目结构和基本流程。

第三，模型稳定性会变得更重要。游戏开发不是只要代码能跑，还要效果合理、手感正常、参数可控。未来谁能更好地结合实际画面和运行状态，谁就更适合做这类任务。

小结

DeepSeek V4 Flash 做 Godot Demo，可以概括成一句话：效果不完美，但足够便宜、足够快，也足够适合做原型。

它离商业游戏还很远，但如果目标是用极低成本验证一个小游戏想法，它已经很有价值。

对个人开发者来说，最现实的用法不是把游戏全交给 AI，而是让 AI 先给出能跑的工程，再由人负责判断、取舍和打磨。这样用，DeepSeek V4 Flash 这类低成本模型反而会很香。

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，复杂任务先让它计划，高风险动作必须确认。这样它才会从一个会写代码的助手，变成可以长期协作的工程工具。

用测试和行为描述约束 AI 写代码，少堆史山

Tue, 05 May 2026 14:35:38 +0800

用 AI 写代码时，最容易出现的体验是：前期很快，后期很乱。功能刚开始能迅速搭起来，但项目一大、修改次数一多，就会出现一个 bug 改完又冒出三个 bug 的情况。

这不完全是 AI 的问题。很多人写代码也会这样，只是 AI 写得更快，问题暴露得也更快。要减少这种失控，关键不是让 AI “更努力”，而是给它更清晰的边界：先说明什么结果算对，再让它写实现。

TDD 和 BDD 就适合放到 AI 编程流程里。TDD 负责把“对不对”变成自动测试，BDD 负责把“是不是我要的功能”变成人能看懂的行为描述。两者结合，可以让 AI 少猜、少自由发挥，也更容易被检查。

TDD 解决什么问题

TDD 是 Test Driven Development，也就是测试驱动开发。它的基本顺序是：

先写测试。
运行测试，确认它现在失败。
再写功能代码。
持续修改实现，直到测试通过。

这和很多人习惯的做法相反。平时写一个排序函数，直觉上会先写函数，再随便输入几个数字看看结果对不对。TDD 则要求先把预期写成测试，例如输入 [3, 1, 2] 时应该得到 [1, 2, 3]，输入空数组时应该返回空数组，输入包含重复数字时结果也应该正确。

这样做的意义是：开发开始前，正确结果已经被定义清楚了。后面无论谁改代码，只要重新跑测试，就能知道有没有破坏之前约定好的行为。

为什么 TDD 以前不容易坚持

TDD 听起来很美，但在真实项目里并不容易长期执行。

一是它反直觉。面对一个空文件时，很多人更想先把功能写出来，而不是先写测试。尤其需求还不清楚时，测试用例也很难落笔。

二是需求变化快。今天认真写下的十几个测试，明天需求一改，可能就要大面积重写。短期看，它会让开发节奏变慢。

三是测试本身也需要成本。测试代码不是凭空出现的，过去它需要程序员自己写、自己维护、自己解释价值。对只看短期交付速度的团队来说，这件事很容易被压掉。

但 AI 改变了这个成本结构。把需求转成测试代码，恰好是 AI 很擅长的工作。让 AI 根据测试去补实现，也比让它对着一段模糊描述自由发挥可靠得多。

AI 写代码时怎么用 TDD

使用 AI 写功能时，可以把提示方式从“帮我实现这个功能”改成下面这个顺序：

让 AI 先根据需求列出测试用例。
要求每个测试用例都有中文说明。
先 review 测试用例是否符合真实需求。
确认测试后，再让 AI 写功能实现。
要求 AI 运行测试，并根据失败结果继续修正。

这时，人主要 review 的不是一大段实现代码，而是测试是否说清楚了需求。测试用例通常更接近“输入是什么、输出应该是什么、边界情况怎么处理”，比直接读实现逻辑轻松很多。

例如可以这样要求 AI：

1
2
3

先不要实现功能。
请根据下面的需求编写测试用例，每个测试用例用中文注释说明覆盖的业务规则。
测试确认后，再根据测试实现代码。

这个流程能减少两类常见问题：一类是 AI 写着写着偏题，另一类是后续修改时把旧功能改坏。

TDD 还不够

只有 TDD 仍然有两个缺口。

第一个缺口是：测试都通过，不等于产品真的符合预期。测试只能证明代码满足了测试里写下的规则。如果测试本身没有表达清楚用户需求，代码仍然可能“正确地做错事”。

第二个缺口是：测试代码对非技术用户仍然不友好。哪怕有中文注释，很多人还是不愿意阅读一堆单元测试。需求越偏产品体验，越难直接从测试代码里确认“这是不是我要的东西”。

这时就需要 BDD。

BDD 解决什么问题

BDD 是 Behavior Driven Development，也就是行为驱动开发。它关注的不是代码内部怎么写，而是系统在某个场景下应该表现出什么行为。

BDD 常用的描述方式是 Given / When / Then：

Given：给定某个前置状态。
When：当用户或系统执行某个动作。
Then：应该得到某个结果。

例如一个带吸血效果的游戏角色，可以这样描述：

Given 棋盘上有一个剩余 1 点生命、攻击力为 2、最大生命为 5 的吸血鬼
And 相邻格子有一个剩余 10 点生命的敌方单位
When 吸血鬼攻击这个敌方单位
Then 敌方单位剩余 8 点生命
And 吸血鬼恢复到 3 点生命

这段话不是代码，但它比“攻击敌人时恢复生命”精确得多。它说明了初始状态、动作和结果，也暴露出后续需要补充的问题：如果敌人只剩 1 点血，吸血鬼按造成伤害恢复，还是按攻击力恢复？如果吸血鬼已经满血，溢出的治疗怎么处理？

这些问题越早被问出来，AI 后面越不容易乱猜。

为什么 BDD 很适合 AI

BDD 过去推行成本也不低。它要求产品、开发、测试用同一套行为描述沟通，而现实里很多团队并没有这种协作习惯。

但 AI 时代，BDD 的成本下降了。你只需要先写一句粗略需求，例如：

`1`	`吸血鬼攻击敌人后，恢复与造成伤害等量的生命值。`

然后让 AI 生成 Given / When / Then 场景。做得好的 AI 会主动补充边界情况，并追问不明确的规则。你需要做的是确认这些行为描述，而不是直接读实现代码。

一旦行为描述确认清楚，再让 AI 把它转换成测试代码，最后根据测试实现功能，路径就顺了很多。

一套更稳的 AI 编程流程

实际使用时，可以把 BDD 和 TDD 串起来：

先用自然语言写需求。
让 AI 转成 BDD 行为场景。
人确认 Given / When / Then 是否符合预期。
让 AI 把行为场景转换成自动测试。
人快速 review 测试覆盖范围。
让 AI 实现功能。
运行测试，失败就让 AI 根据错误继续修正。
最后再做一次人工验收和代码 review。

这里的关键是顺序。不要一开始就让 AI 写完整实现，而是先让它把需求变成可确认的行为，再变成可执行的测试。这样 AI 的自由发挥空间会小很多。

可以直接使用类似这样的提示词：

请按 BDD + TDD 的流程处理这个需求。

第一步：先把需求整理成 Given / When / Then 行为场景，不要写代码。
第二步：列出你发现的不明确规则，并向我确认。
第三步：在行为场景确认后，再把它们转换成测试用例。
第四步：测试确认后，再实现功能。
第五步：运行测试，根据失败结果修复，直到测试通过。

这类提示词不复杂，但能明显改变 AI 的工作方式。它会先收敛需求，再进入实现，而不是一上来就写一堆看似完整、实际难以验证的代码。

适合优先使用的场景

BDD + TDD 不一定适合所有任务。对于一次性脚本、临时数据处理、小范围样式调整，完整流程可能太重。

它更适合这些场景：

业务规则多，容易理解错。
边界条件多，后续还会持续修改。
游戏、计费、权限、状态机、表单校验等逻辑密集功能。
需要多人协作确认需求。
代码将长期维护，不只是一次性生成。
已经出现“AI 越改越乱”的项目。

如果只是让 AI 改一个按钮文案，不必上完整流程。但如果要做一套角色技能系统、订单状态流转、权限判断、积分规则，先写行为场景和测试会更划算。

使用时注意什么

第一，测试不是越多越好。测试应该覆盖关键规则和高风险边界，而不是把实现细节全部锁死。否则需求稍微变化，测试就会变成维护负担。

第二，BDD 场景要写具体。不要写“系统应该正常工作”“体验应该流畅”这类无法验证的描述。要写清楚给定什么状态、发生什么动作、结果应该是什么。

第三，人仍然要 review。AI 可以生成测试和行为场景，但它不知道你真正想要的产品取舍。尤其是边界规则，必须由人确认。

第四，测试通过后还要实际运行功能。自动测试能兜住逻辑问题，但界面体验、性能、交互细节、用户感受仍然需要人工验收。

小结

AI 写代码快，但快不等于稳。越是复杂需求，越不能只靠一句“帮我实现”。更好的方式是先把需求拆成可确认的行为，再把行为变成可运行的测试，最后让 AI 按测试实现代码。

TDD 让 AI 知道什么结果算对，BDD 让人更容易确认这是不是自己想要的功能。两者合起来，不是为了增加仪式感，而是为了减少 AI 的猜测空间，把“写得快”变成“改得稳”。

Claude Code 的 HERMES.md 计费故障是怎么回事

Sat, 02 May 2026 11:05:48 +0800

Claude Code 最近有一次很典型的计费故障：用户只是启动 CLI，还没有正式发出请求，就因为本地 HERMES.md 文件被读取而产生了大额费用。

这件事值得单独看，不是因为某个用户损失了多少钱，而是因为它暴露了 AI 编程工具的一个新风险：只要工具会自动读取上下文，本地文件就可能变成真实 token 成本。

发生了什么

公开 issue 显示，用户在工作目录里放了一个很大的 HERMES.md 文件。启动 Claude Code 后，CLI 会扫描并加载项目上下文。问题在于，这个文件被自动纳入上下文，并被计入 API 使用量。

用户并没有明确要求模型处理这份文件，但计费已经发生。更麻烦的是，这类行为发生在工具初始化或上下文准备阶段，用户不一定能第一时间意识到费用正在产生。

Anthropic 后续在 issue 中回复，表示会退还异常费用，并额外提供额度补偿。这个回应说明问题至少已被官方确认和处理，但它仍然提醒用户：AI CLI 的“自动上下文”不是免费的。

HERMES.md 为什么会触发问题

HERMES.md 本身不是重点。它可以换成任何大文件：长日志、导出的文档、测试数据、数据库 dump、生成报告，都可能造成类似问题。

真正的问题在于三件事叠加：

Claude Code 会自动读取项目上下文。
被读取的文件可能很大。
上下文 token 会进入计费链路。

如果一个文件足够大，哪怕只是被工具“顺手带上”，也可能产生明显费用。对按 token 计费的模型来说，自动化越强，越需要明确边界。

这不是普通 bug

普通 CLI bug 可能只是命令失败、输出错误或功能不可用。计费 bug 更敏感，因为它直接影响用户账单。

对 AI 编程工具来说，计费边界很容易变模糊：

系统提示会消耗 token。
项目规则会消耗 token。
自动读取的文件会消耗 token。
工具调用结果会消耗 token。
重试、压缩、摘要也可能继续消耗 token。

用户看到的是一次“启动工具”或“一次对话”，后台实际可能已经发生多次请求和大量上下文传输。

用户应该怎么防

如果你使用 Claude Code、Codex、Cline 这类 AI 编程工具，可以先做几件事：

不要把大文件直接放在项目根目录。
把日志、导出数据、构建产物、临时文件加入忽略规则。
检查工具是否支持类似 .ignore、上下文排除、文件白名单的配置。
开启预算提醒或用量限制。
第一次在大型仓库运行前，先用小目录测试。

如果仓库里必须保留大文件，最好明确告诉工具不要读取它们。项目规则里也可以写清楚：不要主动读取日志、dump、数据集、归档文件和大体积 Markdown。

工具厂商该怎么改

这类问题不能只靠用户小心。工具本身也应该给出硬边界。

更合理的设计包括：

初始化阶段不应隐式计入大文件。
自动读取超大文件前要提示用户确认。
CLI 应显示本次请求预计 token 和费用区间。
默认忽略常见大文件和生成目录。
对异常 token 激增设置保护阈值。

AI 编程工具越像“自动代理”，越需要把成本透明化。否则用户很难判断一次操作到底会产生多少费用。

小结

Claude Code 的 HERMES.md 计费故障，本质上是自动上下文和按量计费之间的冲突。

对用户来说，最重要的是把项目上下文管住：大文件不要默认暴露给 AI 工具，预算和用量也要设上限。对工具厂商来说，自动读取文件必须配套可见的成本提示和保护机制。

参考：

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 最重要的一条原则。

GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max 怎么选

Tue, 28 Apr 2026 22:18:00 +0800

如果你现在只想知道一句话答案，那可以先记这个版本：

要最稳、最省时间，优先看 GPT 5.5
要页面观感、创意和展示感，Claude Opus 4.7 还是强
要看国产模型里谁最接近第一梯队，Qwen 3.6 Max 现在很有竞争力
DeepSeek V4 不是不能打，但波动比前面几家更明显

很多人问“现在最强编程 AI 到底是谁”，其实问到最后，通常不是在问排行榜，而是在问一件更实际的事：
我现在要写页面、做 demo、生成小工具、补交互，哪一个最容易一次就给我能用的东西。

从这个角度看，这几家模型的差别已经很清楚了。

先说总判断

如果把 GPT 5.5、Claude Opus 4.7、DeepSeek V4、Qwen 3.6 Max 放在一起看，综合能力最稳的还是 GPT 5.5。

它不一定每次都是最花哨的那个，但它很少让你明显失望。速度快，第一次生成的完成度高，逻辑、交互、动效、小游戏这一类综合任务通常都比较顺。

Claude Opus 4.7 的特点很不一样。它最强的地方不是“最稳”，而是页面气质、UI 组织和展示感。很多时候你一打开它写的东西，会先觉得“这个看起来像回事”。如果你更在意页面呈现，它还是很值得看。

Qwen 3.6 Max 是这几家里最值得重新看的一个。它已经不是“国产里能用”这个级别了，而是有些场景下真的能和 GPT 5.5 直接拼效果。尤其是前端页面、视觉完成度、拟真感这些部分，它已经开始有明显存在感。

DeepSeek V4 的问题不是完全不行，而是不够稳。它能写出来的时候并不弱，甚至有些场景还不错，但上下限差得比另外几家更明显。你有时候会觉得它挺能打，有时候又会觉得怎么突然掉下去了。

`GPT 5.5` 强在哪

如果你平时最常做的是这些事：

直接生成一个完整网页
做带动效的小 demo
写有一点逻辑的互动页面
生成小游戏或多状态交互
想尽量少返工

那 GPT 5.5 基本还是最稳的答案。

它的优势主要有几个：

出代码速度快
第一次成品可用度高
逻辑和交互比较少出硬伤
综合题表现稳定

说得更直接一点，GPT 5.5 最像一个“你把需求扔过去，它大概率能先把地基搭对”的模型。
很多人真正缺的不是某一项最惊艳，而是第一版别翻车。这件事上它现在还是最让人省心。

当然，它也不是完全没有短板。

某些偏视觉表现的页面，不一定是最有惊喜的
有时候太稳了，反而少一点设计感上的记忆点

所以如果你问“要一个默认推荐”，那还是 GPT 5.5。
但如果你问“要不要只看它”，答案也不是。

`Claude Opus 4.7` 适合什么人

Claude Opus 4.7 这类模型的吸引力，更多来自页面观感。

它的长处通常是：

UI 结构更顺
视觉表现更完整
某些页面更有展示感
在可视化和创意感上更容易出彩

如果你让模型去做的是这些东西：

演示页面
数据展示页面
强调观感的小网页
想要一打开就“看着比较高级”的结果

那 Claude 依然值得进前排。

不过它的问题也一直比较明显：

稳定性不如 GPT 5.5
有时看着不错，但细节逻辑会偏掉
个别场景里会出现功能能跑，但核心体验不够准的情况

所以 Claude 更像一个有审美加成的前端型选手。
你要是更看重页面“长得好不好”，它很有优势；你要是最怕第一次输出就出逻辑问题，那还是得更谨慎一点。

`Qwen 3.6 Max` 为什么值得认真看

这几家里，Qwen 3.6 Max 给人的最大变化感最明显。

以前很多人看国产编程 AI，更多是抱着“能不能跟上”的心态。现在看 Qwen 3.6 Max，已经是另一种问题了：
它在一些前端直出场景里，到底能不能直接和国外头部模型打。

它现在比较突出的地方有这些：

页面观感不错
某些动效和拟真效果做得挺好
生成结果比较有完成感
有些题目里，效果已经能接近甚至咬住 GPT 5.5

这说明一件事：
如果你的使用场景偏网页、偏前端、偏展示结果，那 Qwen 3.6 Max 已经不是“备用选项”，而是可以认真放进主选名单的模型。

当然，它还没有稳到完全没有短板。

交互逻辑题上，偶尔还是会掉一点完成度
有些页面很好看，但有些任务又会突然平一点
起伏比 GPT 5.5 还是大一些

但整体上，它现在的存在感已经非常强了。
如果你想知道“国产模型里现在最该重点看谁”，那 Qwen 3.6 Max 很难绕开。

`DeepSeek V4` 现在处在什么位置

DeepSeek V4 的情况稍微复杂一点。

它的问题不是完全做不好，而是你不太容易预判它这次会落在哪个区间。
有时候它能把事情做出来，观感和功能都不算差；有时候遇到稍微复杂一点、同时要求动画、逻辑、数据表现的任务，它又容易掉链子。

它目前给人的感觉更像这样：

能力有
不算弱
某些题目可以交卷
但稳定性还不够让人完全放心

这就决定了它现在更适合什么样的人。

如果你愿意多试几次、能接受偶尔需要重来、或者你本来就会自己检查和修代码，那 DeepSeek V4 还是可以继续用。
但如果你就是想少折腾、想把第一次生成成功率放在前面，那它现在还不是最稳的答案。

普通用户到底该怎么选

如果你不是做模型评测，而是真的想拿来干活，那其实可以直接按用途选。

1. 想少折腾，想提高第一次成功率

选 GPT 5.5。

它最适合的就是“我给需求，你先给我一版能用的”。
尤其是你没有太多时间来回调、反复修的时候，它的综合稳定性最有价值。

2. 更看重页面展示感和视觉完成度

选 Claude Opus 4.7。

如果你想要的是一个看起来更像成品的页面，或者你做的是偏演示型、展示型的东西，Claude 的优势会更容易体现出来。

3. 想重点看国产里最强的前端直出能力

优先看 Qwen 3.6 Max。

它现在已经不是“将就用”，而是真的可以拿来正面比较。
如果你的任务偏网页、偏动效、偏展示，Qwen 的竞争力已经很实际了。

4. 能接受波动，想继续观察国产综合能力

可以继续看 DeepSeek V4。

它的问题不是没实力，而是发挥不够整齐。
如果后面稳定性继续补上，它的存在感还会更强。

最后一句话

现在这几家主流编程 AI，差距已经不再是“谁能写、谁不能写”，而是“谁更稳、谁更好看、谁更适合你的任务”。

如果你就想要一个最省事的答案，GPT 5.5 还是第一选择。
如果你想要更强的展示感，Claude Opus 4.7 仍然很有味道。
如果你关心国产模型里谁最值得认真看，Qwen 3.6 Max 现在已经站到很靠前的位置。
DeepSeek V4 则更像一个还在继续补稳定性的强力选手。

真要压成一句最短结论，就是：

最稳看 GPT 5.5，最有观感看 Claude，国产里最值得重点看的是 Qwen 3.6 Max。

为什么马斯克和 SpaceX 要拿下 Cursor 的 600 亿美元收购期权

Tue, 28 Apr 2026 21:45:47 +0800

如果只看标题，这件事最容易让人误解成一句话：马斯克要让 SpaceX 花 600 亿美元买 Cursor。

但真正值得注意的地方恰恰不是“600 亿美元”这个数字本身，而是它拿到的是 收购期权，不是立刻完成的并购。

这两者差别很大。

简单说，SpaceX 现在锁定的是一个未来选择权：今年晚些时候，它可以选择以 600 亿美元 买下 Cursor，也可以选择支付 100 亿美元，继续把双方合作推进下去。这个设计本身就说明，马斯克和 SpaceX 要的不是一笔单纯的财务交易，而是一种 先合作、再观察、最后决定是否完全并表 的安排。

01 为什么不是现在就直接买

如果马斯克和 SpaceX 真只是想把 Cursor 买下来，最简单的方式当然是直接谈收购。

之所以没有一步到位，通常就意味着现在还有几件事没有完全确定：

Cursor 作为产品，到底能不能继续保持高速增长
SpaceX 和 xAI 提供的算力，能不能真的把 Cursor 推到下一阶段
两边整合之后，协同效应到底有多大
现在就拍板 600 亿美元，是不是对任何一方都太早

所以这份期权的意义很清楚：先把最关键的权利拿到手，但不急着今天就把所有钱打出去。

对马斯克和 SpaceX 来说，这样更灵活；对 Cursor 来说，这也比“现在就被完全吞进去”保留了更多空间。

02 马斯克和 SpaceX 真正在意的，不只是 Cursor 本身

从公开信息看，Cursor 最吸引马斯克和 SpaceX 的，不只是它是个热门 AI 编程产品，而是它同时踩中了几件很关键的事：

它已经有成熟的开发者用户入口
它在 AI 编程这个最热的赛道上站住了位置
它可以把最真实的工程场景反馈给模型和基础设施

说得更直接一点，马斯克和 SpaceX 看中的不是一个单独的编辑器壳子，而是：

开发者分发渠道
高价值用户群
AI 编程场景里的真实使用数据

对 xAI 这种还在追赶 Anthropic 和 OpenAI 的体系来说，这种入口非常贵。

因为大模型竞争走到现在，拼的已经不只是“谁模型分数更高”，还包括：

谁更贴近真实工作流
谁更容易进入开发者日常
谁能拿到更多高质量交互数据

Cursor 恰好就是这样一个入口。

03 为什么用“期权”而不是“协议合作”就够了

如果只是想合作，其实签一份普通合作协议也行。那为什么还要加一个 600 亿美元 的收购期权？

因为普通合作协议解决不了两个问题。

1. 防止别人截胡

Cursor 这种公司，最贵的不只是今天的收入，而是它在未来几年里可能长成的平台价值。

如果 SpaceX 只是先合作、不锁权利，那一旦合作跑顺了，最后最难受的反而可能是马斯克这一边：

产品被合作带起来了
增长被合作推高了
估值被合作抬上去了
最后却可能被别的巨头接走

收购期权解决的就是这个问题。
先不买，但先把优先选择权握住。

2. 给估值争议留缓冲区

如果现在直接谈并购，最大难点之一就是：600 亿美元 到底贵不贵？

这件事现在其实很难下定论，因为 Cursor 还处在极快变化的阶段：

今天看，600 亿美元很贵
但如果算力补上、模型能力补上、用户继续爆发，几个月后可能又像是另一回事

所以期权是一种很典型的折中办法：

今天先把价格框架锁住
明天再根据合作结果决定要不要执行

这比现在就赌死，更像资本和产业结合时会用的打法。

04 为什么 Cursor 自己也愿意

这件事如果只从 Cursor 的角度看，也并不难理解。

Cursor 现在最缺的，不一定是钱本身，而更可能是 更大的算力、更多训练资源，以及更强的战略护城河。

公开信息里已经明确提到，Cursor 想把训练往前推，但受限于 compute。和马斯克体系里的 SpaceX / xAI 合作，能直接把它接到更大的基础设施上。

这对 Cursor 的意义非常现实：

模型训练可以继续往上拉
产品能力有机会更快升级
不必继续完全受制于外部大模型供应商

这点尤其关键。

因为 Cursor 虽然是热门 AI 编程产品，但它长期也面临一个很现实的问题：
它既要和 Anthropic、OpenAI 这类公司合作，又在产品层面和它们直接竞争。

这种关系天然不稳。

而马斯克的 SpaceX / xAI 提供的是另一条路：把上游模型和下游产品更深地绑在一起。

所以 Cursor 愿意给出这份期权，不只是因为价格诱人，也因为它本身确实需要更重的算力和更深的战略绑定。

05 那为什么还留了一个 100 亿美元的选项

这里其实最有意思。

公开说法不是“要么收购，要么没下文”，而是“要么 600 亿美元 收购，要么 100 亿美元 继续合作”。

这意味着双方从一开始就默认了一件事：
合作本身就是有价值的，即使最后不收购，也不是白做。

这个 100 亿美元 选项，本质上像是一个中间态：

如果合作特别顺，直接执行收购
如果合作有效，但还没到并购时机，就用更重的战略合作继续绑定

也就是说，马斯克和 SpaceX 并没有把问题压成“买或不买”两个极端，而是故意留了一条缓冲路线。

这通常说明两边都知道，AI 赛道变化太快，今天就做不可逆决定，未必是最优解。

06 从马斯克和 SpaceX 视角看，这更像一笔“上市前布局”

从外部看，这个动作还有一层非常明显的资本市场意味。

公开报道里已经提到，SpaceX 在潜在上市前，正试图把自己讲成一个更强的 AI 故事，而不只是火箭和卫星公司。对马斯克来说，这也很符合他这几年一贯的方向：尽量把火箭、算力、模型、分发入口和开发者工作流连成一张更大的技术版图。

这时候，Cursor 的作用就不只是业务协同，而是叙事协同：

SpaceX 有大规模基础设施和算力
xAI 有模型和 AI 平台故事
Cursor 有开发者入口和热门应用层场景

把这三层连起来，讲出来的故事会比“单独做模型”更完整。

所以这份期权也可以理解为一种 先把未来故事线锁住 的动作。对马斯克而言，这不只是一次交易条款设计，更像是在提前卡位 AI 编程入口。

它一方面给内部整合留时间，另一方面也给外部市场一个信号：SpaceX 不只是想做 AI 基础设施，还想往 AI 应用层和开发者工作流里继续伸手。

07 一句话总结

马斯克和 SpaceX 想拿 Cursor 的 600 亿美元 收购期权，本质上不是因为他们今天就一定要把 Cursor 整个吞下，而是因为 他们既想先拿到开发者入口和未来收购权，又不想现在就把并购风险、估值风险和整合风险全部一次性吃下去。

所以“期权”这两个字，反而比“600 亿美元”更重要。
这说明 SpaceX 要的不是一锤子买卖，而是一种先锁位置、再看协同、最后决定是否完全收编的打法。

DeepSeek V4 Pro 对比 GPT-5.5：前端、写作、代码实测后，差距比想象更大

Sat, 25 Apr 2026 11:12:00 +0800

DeepSeek V4 Pro 和 GPT-5.5 这种对比，最近越来越容易引发讨论。因为它已经不是“谁能不能用”的问题，而是：当任务落到前端、写作、代码这三类高频场景时，谁更适合当主力？

很多人做这类比较时，习惯先问一句：哪个更强。
但更有价值的问题通常不是这个，而是：在具体任务里，哪个更稳、哪个更省沟通成本、哪个更容易产出能直接继续推进的结果。

如果先给一个简化版结论，可以大致这样理解：

需要更均衡、产品化体验更完整的综合输出时，很多人还是会先看 GPT-5.5
需要中文语境下高频迭代、成本更敏感、追求响应效率时，DeepSeek V4 Pro 会更容易进入候选名单
真正决定体验的，往往不是模型名字本身，而是任务类型、提示方式和你后续要不要继续改

下面按三个最常见的比较场景展开。

1. 前端任务：比的不是“会不会写页面”，而是能不能继续接着改

前端任务看起来很适合拿来做模型对比，因为它结果直观：
页面能不能跑、样式好不好看、结构清不清楚，一眼就能看到。

但真正拉开差距的，往往不是第一版能不能写出来，而是后续这些问题：

结构是不是足够清晰
组件拆分是否自然
改一处时会不会连带改坏别的地方
能不能在多轮指令下继续保持同一套实现思路

这也是为什么很多“首轮效果惊艳”的前端演示，放进真实工作流后未必依然占优。

如果你的任务是：

快速生成一个可运行的页面原型
把一个落地页思路先写出来
按要求补齐样式、按钮、卡片、表单等基础元素

那两类模型通常都能完成得八九不离十，区别更多体现在输出风格。

而如果你的任务变成：

持续多轮改 UI
一边读现有代码一边接着改
同时兼顾组件结构、样式一致性和可维护性
从静态页面逐步推进到真实项目代码

那你更应该观察的就不是“第一轮谁更像样”，而是“谁在第五轮以后还不容易跑偏”。

所以前端对比真正该看的，不是模型能不能生成页面，而是它能不能在你连续追加约束之后，依旧保持结构稳定、命名一致、修改成本可控。

2. 写作任务：比的不是字多不多，而是风格稳不稳、重写顺不顺

写作是另一类特别容易出现误判的场景。

因为很多时候，模型第一次输出看起来都不差：
结构完整、段落齐全、语气顺滑，乍看之下很容易觉得“差不多”。

但只要你把任务往前推一步，差异就会冒出来：

能不能准确理解你要的受众
能不能在同一主题下切换不同口吻
重写时会不会丢掉原文重点
压缩、扩写、改标题、换结构时是否稳定

写作任务里最怕的不是“写不出来”，而是“看起来写出来了，但你还得重改很多遍”。

所以在 DeepSeek V4 Pro 和 GPT-5.5 之间，更实用的比较方式通常不是让它们各写一篇，而是连续做这几轮：

先写初稿
再换一个语气重写
再压缩成更短版本
再改成更适合标题党或搜索分发的写法

如果一个模型在这几轮里仍然能保持重点不散、表达不飘、结构不乱，那它在真实写作工作流里的价值才会更高。

也就是说，写作任务真正比的不是“文采”，而是改稿能力、服从度和连续协作感。

3. 代码任务：真正拉开差距的是长链路稳定性

代码任务比前端任务更容易暴露模型真实水平，因为它不仅要“输出”，还要“对接现实”。

你很快就会遇到这些问题：

它能不能理解已有项目结构
能不能同时修改多个文件
改完以后有没有引入新的问题
出错时会不会顺着日志继续往下查
多轮之后还记不记得前面已经做过什么

这类任务里，用户最在意的通常不是某一段代码漂不漂亮，而是：能不能帮我持续往前推进，而不是让我来收拾残局。

所以比较 DeepSeek V4 Pro 和 GPT-5.5 时，最值得看的往往不是单点题，而是这种更接近真实工作的过程：

读一个已有仓库
找到一个 bug
改多个相关文件
根据报错继续修
最后把结果整理清楚

只要任务进入这种连续推进模式，模型的上下文保持能力、执行习惯、解释质量和返工率，都会比“单轮答题效果”更重要。

这也是为什么很多用户在代码场景里，最终形成的不是“永远只用一个模型”，而是按任务阶段切换主力。

4. 真正值得比较的，不是输赢，而是“哪类任务交给谁更划算”

把 DeepSeek V4 Pro 和 GPT-5.5 放在一起时，如果目标只是争一个总冠军，最后往往会得到一个很空的结论。

因为现实任务不是统一题目：

有的是一次性生成
有的是多轮协作
有的是中文写作
有的是工程改动
有的是强调速度
有的是强调稳定性
有的是强调成本

所以更接近真实使用的方法，通常是按任务目标分：

想要更完整的综合体验、更成熟的交互和更稳定的通用输出，可以优先试 GPT-5.5
想要在中文环境里高频试错、快速迭代，并且更关注投入产出比，DeepSeek V4 Pro 值得重点放进工作流里
如果任务本身是长链路、多轮修正、多人协作，那就不要只看第一轮结果，要看五轮以后谁还更稳

换句话说，真正该问的不是“谁绝对更强”，而是：
前端、写作、代码这三类任务里，哪一个模型更像你当前阶段最顺手的工具。

5. 怎么做一次更像样的模型对比

如果你自己也准备测 DeepSeek V4 Pro 和 GPT-5.5，一个更靠谱的做法通常不是只跑一轮，而是这样测：

给两边同一份初始需求
保持相同限制条件
连续追问三到五轮
记录改动质量、跑偏次数和返工量
最后再看速度、成本和最终可用度

这样测出来的结果，会比“谁第一轮更惊艳”更接近真实工作。

尤其在前端、写作、代码这三类任务里，很多时候真正决定体验的不是起跑线，而是谁能陪你把事情做完。

6. 可以先这样记

如果只想先记一个够用的版本，可以先这么理解：

GPT-5.5：更像综合型、产品化、默认可用的主流工作台
DeepSeek V4 Pro：更像在中文环境和高频试错里更值得纳入日常工作流的竞争者
真正的比较重点：不是首轮炫技，而是多轮修改之后谁更稳、谁更省事

所以这类对比里，真正重要的从来都不是“谁赢了”，而是：
你的前端、写作、代码任务，交给谁之后最容易持续推进、最少返工、最能稳定产出。

ChatGPT、Claude、Gemini 怎么分工：日常对话、编程和特殊能力怎么选

Sat, 25 Apr 2026 10:51:19 +0800

现在很多人不是只用一个模型，而是会在 ChatGPT、Claude 和 Gemini 之间来回切换。问题也随之变得很实际：到底什么任务该交给谁？

这件事之所以容易让人纠结，不是因为三家都不够强，而是因为它们已经强到开始“分工不同”。如果还用“谁更聪明”这种非常笼统的标准去选，反而容易选错。

如果先说一个简化版结论，可以大致这样理解：

日常对话和综合型任务，很多人会先想到 ChatGPT
命令行编程、长上下文协作、持续推进型任务，Claude 往往更顺手
需要依赖 Google 生态、搜索、多模态入口或某些产品级特殊能力时，Gemini 更有存在感

下面分三块讲。

1. 日常对话：为什么很多人还是先打开 `ChatGPT`

对大多数普通使用场景来说，ChatGPT 仍然很像“默认入口”。

这里说的不是某一个 benchmark，而是整体体验：
你临时想问一个问题、整理一个思路、写一段文案、做一份初稿、总结一篇资料，ChatGPT 通常给人的感觉会比较均衡。

它的优势往往体现在几个地方：

回答风格比较稳定
普通用户上手门槛低
多数综合型任务不需要太多额外调教
产品完成度高，适合高频日常使用

所以如果你的任务是下面这种：

帮我整理一个主题
把一段想法写成结构化内容
总结一篇长文
头脑风暴几个方案
把表达润色得更清楚

那 ChatGPT 往往是个很自然的起点。

这并不代表它在所有专业任务里都一定最强，而是它在“广谱通用”这件事上，通常更像一个默认工作台。

2. 命令行编程和长任务：为什么很多人更偏向 `Claude`

一旦任务从“聊一聊”切换成“把事情持续做完”，很多人的偏好就会开始转向 Claude。

尤其是这些场景：

命令行编程
大项目上下文理解
多文件协作修改
长链路调试
边读代码边推进任务

这类任务的关键，往往不是一轮回答有多惊艳，而是模型能不能在更长的任务链里保持稳定。

Claude 经常被偏爱的原因，通常不是“它一句话比别人更会说”，而是：

对长上下文任务更耐用
连续读文件、读日志、读规则时体验更稳定
更适合逐步推进复杂编码任务
在命令行和 agent 工作流里更常被当成主力模型

如果你是在做 vibe coding、命令行修 bug、项目结构理解、跨多个文件改功能，Claude 的优势会更容易体现出来。

简单说，Claude 比较像那种适合一起“干活”的模型，而不只是适合问一句答一句。

3. `Gemini` 的优势往往不在“和别人正面拼一切”

很多人讨论 Gemini 时，容易把问题问成：它到底是不是三家里最强。

但从实际使用体验看，更有用的问题通常不是这个，而是：它在哪些场景里特别值得单独拿出来用。

Gemini 的价值，往往更容易体现在这些方向：

Google 生态结合
搜索与资料获取
多模态入口
某些产品侧功能联动

如果你的工作流本来就和 Google 的工具链很近，比如：

搜索
文档
邮件
浏览器侧使用
手机端入口

那 Gemini 的实际便利性可能会高于单纯的模型分数对比。

也就是说，Gemini 的可用性很多时候来自“它在哪里更顺手接入你的工作流”，而不只是“它单轮回答是不是赢了谁”。

4. 真正有用的选法，不是问谁最强，而是问任务类型

把三家模型放在一起比较时，最容易踩的坑就是试图找一个“唯一最强”。

但现实里的任务差异太大了：

有的是一次性问答
有的是长对话陪跑
有的是代码工程
有的是信息检索
有的是多模态处理
有的是工具链协作

所以更有效的选法，通常是按任务类型来分：

需要一个综合型、日常高频、打开就能用的助手：先看 ChatGPT
需要长上下文、命令行、编程协作、持续推进复杂任务：优先试 Claude
需要借力 Google 生态、搜索、多模态入口或某些产品联动能力：重点看 Gemini

这样分工，比强行争一个总冠军更接近真实使用。

5. 为什么很多重度用户会同时订三家

从轻度用户视角看，同时订三家模型服务很容易显得“重复”。
但从重度用户视角看，这更像是在给不同任务配不同工具。

原因很简单：
如果三家的长处已经开始明显分化，那么同时使用它们，本质上就不是重复付费，而是在减少任务切换成本和试错成本。

比如：

日常整理和综合问答，用 ChatGPT
编程主任务，用 Claude
某些检索、多模态或 Google 相关链路，用 Gemini

这种组合方式的逻辑，和设计师同时装多个软件、开发者同时用多个 IDE，并没有本质区别。

6. 什么时候不要来回切太多模型

当然，模型多也不一定总是更好。

如果你本身还在建立稳定工作流，过早在三个模型之间频繁横跳，反而可能让自己更乱。常见问题包括：

同一个任务来回重复讲三遍
不同模型给出不同建议，自己更难判断
上下文断裂，协作成本反而更高
还没形成自己的使用边界，就先被工具选择拖住

所以更稳的方式通常是：

先给每个模型一个主场景
在主场景里连续用一段时间
再逐步形成自己的分工习惯

这样你会更容易得到真正可复用的经验，而不是永远停留在“今天换这个试试”的阶段。

7. 可以先这样记住

如果只想先记一个够用的版本，可以直接记这张口语化分工表：

ChatGPT：更像通用型默认助手
Claude：更像长任务和编程协作主力
Gemini：更像在搜索、多模态和 Google 生态里更有优势的工具

这不是绝对规则，也不是说三者彼此不能替代，而是一个更接近真实使用体验的起点。

真正重要的不是选出“宇宙最强模型”，而是尽快知道：
你手上的这类任务，用哪个模型最省时间、最省心、最容易做出结果。

Claude Code 环境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次讲清

Thu, 23 Apr 2026 10:35:00 +0800

如果你用 Claude Code 一段时间，就会很快发现一件事：模型本身当然重要，但给它什么环境、什么边界、什么规则，同样重要。

很多人刚开始会把注意力放在“我这次 prompt 怎么写”，但真正把 Claude Code 用成熟之后，你会更关心另一件事：

它知不知道你是谁
它知不知道你怎么工作
它知不知道哪些规则不能违反
它知不知道什么事情必须先确认
它能不能长期记住这些边界

Claude Code 之所以能变成一个成熟工具，不只是因为模型强，而是因为它有一整套机制，帮你把这些工作方式沉淀下来。核心上可以拆成四层：

CLAUDE.md
Rules
Memory
Hooks

这篇文章就把这四个部分一次讲清楚。

为什么环境配置比单次提示词更重要

你可以把 Claude Code 想成你请来的一个助理。

第一天上岗时，你不会只跟他说一句“帮我做事”，而是会给他一份说明书，告诉他：

你的身份是什么
你的沟通语气偏好是什么
哪些操作必须先确认
哪些错误之前犯过，未来不能再犯
这个项目最重要的文档放在哪里

这就是为什么，长期来看，环境配置往往比单次 prompt 更重要。

因为 prompt 解决的是“这一次要做什么”，而环境配置解决的是“以后每次都要怎么做”。

第一层：`CLAUDE.md`

先从最基础的开始，CLAUDE.md 本质上就是一个文字文件。

你可以在里面写给 Claude 的说明，例如：

你是谁
你在做什么
你的沟通偏好
需要遵守的规则
当前项目的特殊背景
重要文档或目录的位置

每次 Claude Code 启动时，这份文档都会被自动送进上下文里，所以模型一定会读到。

我通常把它叫做“默契档”，因为它本质上就是你和模型之间长期协作的默契。

`CLAUDE.md` 适合写什么

最适合写进 CLAUDE.md 的，大致有这几类：

身份与工作背景
沟通语气和输出偏好
全局性的行为规则
经常会用到的重要项目背景
常见错误与避免方式

比如：

你所在的时区
你是否接受模型直接发送邮件或消息
哪些操作属于不可逆行为
处理文档和文件时的习惯
安全规范和敏感信息边界

一个很重要的原则：尽量精简

CLAUDE.md 有一个很重要的原则，就是一定要尽量精简。

原因很简单：它每次都会被强制注入上下文。

如果你写得太长，就会占掉大量上下文空间，导致真正重要的信息被稀释。模型不是不读，而是注意力会分散，最后更容易漏掉你最在意的规则。

官方建议通常是最好不要超过 400 行。

我自己的习惯会更保守一些，尽量控制在 200 行以内。

`CLAUDE.md` 的常见作用范围

CLAUDE.md 实际上有不同的放置层级，对应不同的作用范围。最常用的是两个：

1. User Level

这是全局层级。

它放在你电脑环境里，对你本机操作的所有项目都有效。

这个位置适合放：

你的身份信息
通用的沟通偏好
你跨项目都适用的做事习惯
全局性的安全规则

比如，如果你的时区不是默认常见值，而是曼谷时间，那这类信息就很适合放在 user level，这样模型以后帮你安排时间时就不容易出错。

2. Project Level

这是项目层级。

它放在具体项目目录下面，只对那个项目有效。

这个位置适合放：

项目专属背景
只在这个项目里成立的规则
项目的目录结构说明
这个项目的重要文档入口

举个例子，如果一个项目处理财务，另一个项目处理人事，那两边的背景和约束显然不同，就不应该混在同一个全局说明里。

怎么判断该放哪一层

判断方式其实很简单：

你写进去的东西，如果换到另一个项目里还成立，那就放 user level。

如果一换项目就不成立，那就放 project level。

怎么开始写第一版

最常见的起手方式有两种：

1. 用 `/init`

你可以直接在终端里运行斜线命令 /init，让 Claude 扫描当前项目，自动帮你生成一份基础版 CLAUDE.md。

2. 让 Claude 帮你整理

你也可以直接让 Claude 去搜索别人是怎么写 CLAUDE.md 的，再结合你的情况问你问题，最后帮你整理成适合你自己的版本。

很多时候，这比自己从零开始写更轻松。

一个很实用的习惯

在你和 Claude 长期协作的过程中，只要你发现某件事情属于“未来一定要记住、不要再犯”的内容，就可以直接让它写进 CLAUDE.md。

不过写之前还是要判断一下：

这是全局规则
还是当前项目规则

别把所有东西都塞进一个文件里。

第二层：`Rules`

接下来是 Rules。

它和 CLAUDE.md 最大的差别，不是文件形式，而是加载方式。

CLAUDE.md 是无论你做什么，模型都会读到。

而 Rules 的优势在于：可以条件加载。

也就是说，只有在某些路径、某些文件、某些工具或某些场景下，这条规则才会被读到。

为什么条件加载很重要

因为上下文空间永远是稀缺资源。

如果所有规则都无差别地塞进上下文里，就会发生两件事：

模型负担变重
真正关键的规则反而被淹没

按需加载的价值就在这里：让模型在刚好的时候读到刚好的信息。

什么时候该把规则从 `CLAUDE.md` 挪到 `Rules`

通常有两种情况：

1. `CLAUDE.md` 太长了

如果你的 CLAUDE.md 开始超过 200 行，规则越来越多，重要内容被稀释，那就该考虑把一部分规则拆出去。

2. 某些规则只和特定路径相关

如果你已经明显知道某些规则只在某类文件里才有意义，比如：

只对 Python 脚本有效
只对某个 hooks 目录有效
只对某个子项目有效

那这些规则就更适合移到 Rules。

`Rules` 最适合的场景

最典型的就是“特定情境、特定路径、特定文件类型”。

比如：

只在处理 hooks 文件时触发的规范
只在某类脚本中要遵守的编码规则
只在某个目录下适用的工作方式

这些内容如果继续塞在 CLAUDE.md 里，其实是不划算的。

第三层：`Memory`

第三个层面是 Memory。

它和 CLAUDE.md、Rules 一样，也会进入模型上下文，但它最核心的区别是：

CLAUDE.md 是你主动设定的。

Memory 则更像是 Claude 在协作过程中，写给自己的笔记。

`Memory` 记的是什么

当 Claude 判断某件事值得记住，或者需要短期保留，它就会把这些内容写进 Memory。

常见内容包括：

你纠正过它的某个做法
你最近新增的偏好
当前项目的临时状态
你今天没做完、明天还要继续的事
你最近在跟哪些人合作
某些最近才提到的个人信息或上下文

换句话说，Memory 更像动态知识，而不是长期制度。

`Memory` 和前两者的区别

一个简单的区分方式是：

CLAUDE.md / Rules：偏长期、偏制度、偏明确规则
Memory：偏临时、偏动态、偏工作过程中的新理解

如果某件事只是最近几天有效，或者项目状态在持续变化，那它通常更适合放进 Memory，而不是写成长期规则。

`Memory` 也可以手动写

虽然 Memory 有自动整理能力，但你也可以主动告诉 Claude：

请记下来我明天要做什么
请记下来我要追踪谁的状态
请记下来这个月某个项目的关键节点

它也可以帮你写进 Memory。

你还可以通过斜线命令 /memory 查看当前有哪些记忆，并手动编辑或删除。

不过很多时候，我自己不会频繁手动维护，因为 Claude 本身也会定期整理这些记忆，把已经过时的部分清掉。

第四层：`Hooks`

最后也是最重要、最进阶的一层，就是 Hooks。

前面讲到的 CLAUDE.md、Rules、Memory，本质上都还是自然语言说明。

你写了规则，模型通常会遵守，但它仍然是在“理解之后执行”。

只要还是自然语言，就会存在几个问题：

模型偶尔会漏掉
规则太多时，注意力会分散
某些情境下它会自行判断这条规则不重要

这不是你写得不够认真，而是自然语言规则本来就很难做到 100% 强制。

`Hooks` 的本质是什么

Hooks 不再是自然语言说明，而是一段脚本。

它是事件触发的、程序级别的强制逻辑。

只要某个事件发生，这段逻辑就一定会执行，不会被模型“自己判断后略过”。

这就是 Hooks 最关键的价值：

把“建议遵守”变成“必须执行”。

什么时候该上 `Hooks`

当你发现某条规则已经写进了 CLAUDE.md 或 Rules，但 Claude 偶尔还是不执行，而且这件事一旦漏掉，风险就比较大，那就应该考虑改成 Hooks。

简单说：

低风险的，写规则
高风险的，写 Hooks

最典型的 `Hooks` 场景

最典型的，就是那些你绝对不希望出错的动作，比如：

发邮件前必须确认
发 Slack、Outlook、Gmail 消息前必须确认
删除危险文件前必须拦截
检测到要外发密码或 API Key 时必须阻止

如果这些要求只是写成一句自然语言规则，模型有可能哪天忙中出错，真的就发出去了。

但如果写成 Hooks，只要事件发生，就会被强制拦截。

这才是程序层面的硬防线。

`Hooks` 常见的触发时机

Hooks 可以设置在很多不同阶段，例如：

对话刚开始时注入提醒
某个工具执行前进行检查
某个工具执行后做结果校验

你不一定需要自己知道专业术语。

很多时候，只要你能清楚描述需求，让 Claude 帮你判断“这条规则适不适合改成 hook”，它就能帮你一起设计。

你也可以通过斜线命令 /hook 去查看系统当前已经设置了哪些 hooks。

一套更实用的上手顺序

如果你想把这四层串起来，我自己更推荐下面这条路径：

第一步：先用 `/init` 生成基础版 `CLAUDE.md`

不要一开始就手写一份特别完整的规则文档。

先让 Claude 帮你扫描项目，生成一个起点版本，再慢慢迭代。

第二步：边用边补

在协作过程中，只要你发现：

这件事以后一定要记得
这个错误以后不能再犯
这个偏好以后每次都适用

就让 Claude 帮你写进 CLAUDE.md。

第三步：当 `CLAUDE.md` 变长时，拆到 `Rules`

一旦你发现 CLAUDE.md 越来越长，模型开始不一定遵守每一条规则，就该考虑拆分：

哪些是全局规则
哪些只和某些路径相关

把后者移到 Rules，改成条件加载。

第四步：再把高风险规则升级成 `Hooks`

如果某些规则即使写了，模型还是偶尔会漏，而且漏掉代价很高，那就不要再停留在自然语言层面，直接升级成 Hooks。

也就是把“提醒”变成“强制”。

第五步：把临时状态交给 `Memory`

对于那些会过期、会变化、不是长期制度的内容，不要一股脑写进 CLAUDE.md。

更合适的做法是交给 Memory：

当前项目进度
最近合作对象
最近新增偏好
近期计划和待办

这样上下文会更清爽，模型也更容易保持稳定表现。

这四层分别该记什么

如果你想快速记住，可以直接用下面这个区分：

CLAUDE.md：长期默契、全局说明、项目基础背景
Rules：按路径或场景加载的专项规则
Memory：动态知识、临时状态、最近学到的东西
Hooks：高风险操作的程序级强制拦截

结语

很多人把 Claude Code 当成“会写代码的聊天界面”，但真正用深之后，你会发现它更像一个长期协作的智能工作台。

关键不只是你每次怎么下指令，而是你有没有给它一套稳定、清晰、可长期积累的环境。

一旦你把这四层搭起来：

CLAUDE.md
Rules
Memory
Hooks

你和模型之间的协作质量，通常会有非常明显的提升。

因为你终于不是每次都从零开始解释自己是谁、怎么工作、什么事不能做，而是把这些真正沉淀成了环境。

这才是把一个强模型，真正用成成熟工具的关键一步。

Karpathy 的 65 行 CLAUDE.md：让 AI 编程少犯三类错误

Sun, 19 Apr 2026 18:27:23 +0800

最近 GitHub 上有一个围绕 AI 编程的项目很火，核心其实只是一个大约 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因为技术实现复杂，而是因为它抓住了很多人使用 AI 写代码时反复遇到的问题。

这个项目的背景，要从 Andrej Karpathy 对 AI 编程的观察说起。Karpathy 是 AI 领域很有影响力的教育者和工程师：斯坦福博士，参与过 OpenAI 早期工作，也曾在 Tesla 负责 Autopilot 视觉系统。后来他持续分享对大模型、教育和 AI 工具的理解，所以他对编程方式变化的判断，总会引起很多开发者关注。

他在一次分享中提到，自己使用 Claude Code 几周后，编程方式发生了明显变化：过去大概是 80% 手写代码、20% AI 辅助，现在更接近 80% 让 AI 写代码，自己做 20% 修改。他形容这像是“用英语编程”，通过自然语言告诉 LLM 要写什么。

但他也指出了 AI 编程的几个典型问题。

01 错误假设

第一个问题是模型很容易替用户做假设，然后沿着这个假设一路写下去。它不一定会主动管理自己的困惑，也不一定会在需求含糊时停下来追问。

比如用户只说“添加用户导出功能”，模型可能会默认导出全部用户，默认输出 JSON，默认写成本地文件，默认权限和字段都不需要再确认。等代码写完，用户才发现它理解的需求和真实场景并不一致。

更好的做法应该是先把不确定点列出来：导出全部用户还是筛选结果？是浏览器下载还是后台任务？需要哪些字段？数据量大不大？是否有权限限制？这些问题不问清楚，后面写得越快，偏得也越远。

02 过度复杂化

第二个问题是模型很容易把简单问题写复杂。一个函数能解决的问题，它可能加上抽象类、策略模式、工厂模式、配置层和一堆“未来可能有用”的扩展点。

这类代码看起来很工程化，实际却增加了维护负担。AI 尤其擅长快速生成大量结构，但并不总能判断这些结构是否真的必要。结果就是一百行能解决的任务，被膨胀成一千行。

判断标准其实很直接：一个资深工程师看到这段改动，会不会觉得它过度设计？如果答案是会，就应该删掉多余层次，用最少的代码解决当前问题。

03 附带伤害

第三个问题是模型有时会修改或删除自己没有充分理解的代码。它可能在修一个小 bug 的时候顺手改注释、重排格式、清理看似无用的 import，甚至动到和当前任务无关的逻辑。

这类“顺手优化”很危险，因为它扩大了变更范围，也让 review 变得更困难。用户本来只想修复一个空邮件导致验证器崩溃的问题，结果模型顺便增强了邮件验证、加了用户名校验、改了文档字符串，最后很难判断到底哪一行影响了行为。

更稳妥的原则是：只动必须动的代码，只清理自己造成的问题。原本就存在的死代码、格式问题或历史包袱，除非任务明确要求处理，否则最多提醒一句，不要直接改。

04 把吐槽变成 CLAUDE.md

在 Karpathy 的观点被大量传播后，开发者 Forrest Cheung 做了一件很聪明的事：他把这些吐槽整理成可以执行的行为准则，写进一个 CLAUDE.md 文件。

这个项目没有复杂代码，关键就是把 AI 编程中最容易出问题的地方，转成明确的工作规则。大致可以概括为四条。

第一条是先想再写。不要默默假设，不要隐藏困惑；如果需求有多种理解，就把它们列出来；如果存在更简单的方案，也要说出来；该追问时追问，该反驳时反驳。

第二条是简单优先。不添加没被要求的功能，不为一次性代码做抽象，不加入多余配置，也不为极小概率场景写大量防御代码。如果 50 行能解决，就不要写成 200 行。

第三条是精准修改。每一行改动都应该能直接追溯到用户请求。不要顺手改善邻近代码，不要重构没坏的东西，尽量匹配项目既有风格。

第四条是目标驱动。不要只给模型一个模糊指令，而是给它可验证的成功标准。比如“修复 bug”可以变成“先写一个能复现 bug 的测试，再让测试通过”；“添加校验”可以变成“写无效输入测试并通过”。成功标准越清楚，模型越容易自己循环到完成。

05 为什么它会火

这个项目能火，不是因为内容很玄，而是因为它足够贴近真实开发。

很多人用 AI 编程时都经历过类似场景：模型自信地误解需求，代码越写越复杂，或者在不该动的地方动手。CLAUDE.md 的价值，是把这些经验变成可以放进项目里的协作规则。

它的门槛也很低：一个文件就能开始生效，不需要复杂接入。再加上 Karpathy 本人的影响力，以及项目里有实战对比案例，它很自然会在 Claude Code 用户和 AI 编程社区里传播开来。

更重要的是，这类规则不是只适用于 Claude Code。无论使用哪种 AI 编程工具，本质问题都很相似：模型需要知道什么时候该问、什么时候该简化、什么时候该停手、怎样判断任务已经完成。

06 对普通开发者的启发

这件事给普通开发者的启发很简单：AI 编程不是把一句需求丢给模型，然后等待奇迹发生。真正有效的方式，是给模型建立边界。

需求不清楚时，让它先暴露假设。实现方案变复杂时，让它主动回到最小可行解。修改代码时，让它只围绕任务目标行动。完成任务时，用测试、命令或明确检查点来验证结果。

AI 写代码的能力已经很强，但它仍然需要好的协作约束。一个短小的 CLAUDE.md 能获得大量关注，说明开发者真正需要的并不只是更聪明的模型，也包括更可靠的工作方式。

简单总结：

先想再写，减少错误假设。
简单优先，避免过度设计。
精准修改，控制变更范围。
目标驱动，用可验证标准推动完成。

这四条并不复杂，却很实用。AI 编程真正提升效率的前提，不是让模型写得更多，而是让它写得更准、更少、更可控。

Claude Code 额度省着用：模型选择、上下文、缓存与 /compact

Sun, 19 Apr 2026 15:26:56 +0800

最近很多人在用 Claude Code 或 Claude Max 时会遇到一个问题：明明买了 Pro、Max 5x，甚至 Max 20x，结果没跑多久就提示额度快满，或者直接需要等重置。尤其是在大项目里让 Claude Code 读很多文件、修复杂 bug、跑长任务时，这种感觉会更明显。

这里先说结论：额度不是按“时间”线性扣的，而是和模型、上下文长度、附件、代码库规模、对话历史、工具调用和当前容量都有关系。同样 5 小时窗口，有的人能用很久，有的人十几分钟就耗尽，通常不是账号坏了，而是每次请求都太重。

这篇整理一套比较实用的省额度习惯。

01 先理解 Claude 的用量窗口

Claude Pro 和 Max 都有使用限制，Claude Code 的使用量会和 Claude 网页、桌面、移动端共享同一套订阅额度。官方说明里提到，消息数量会受到消息长度、附件大小、当前对话长度、所用模型或功能影响；Claude Code 还会受到项目复杂度、代码库大小、自动接受设置等影响。

大致可以这样理解：

Pro：适合轻量使用和小项目。
Max 5x：适合更频繁使用和较大的代码库。
Max 20x：适合更重度、日常高频协作。
用量窗口按 5 小时会话重置。
长消息、长对话、大文件、复杂任务会更快消耗额度。
Opus 这类更强模型会比 Sonnet 更快触发限制。

所以“我只用了 20 分钟”这个说法不一定能说明问题。真正重要的是这 20 分钟里 Claude 读了多少上下文、用了什么模型、是否反复处理大文件、是否在同一个长对话里继续加任务。

02 第一件事：不要默认一直用最贵模型

Claude 系列里常见的定位是：

Opus：能力最强，适合复杂推理、架构决策、疑难 bug。
Sonnet：能力和成本比较均衡，适合大部分日常编码任务。
Haiku：更轻量，适合简单分类、摘要、格式转换等任务。

日常写脚本、改小 bug、整理文档、解释代码，大多数时候 Sonnet 已经够用。Opus 更适合留给这些场景：

复杂架构设计。
多文件深度重构。
难复现的 bug。
需要长链路推理的排障。
普通模型明显卡住的任务。

Claude Code 里可以用 /model 切换模型，也可以在 /config 里设置默认模型。比较稳的习惯是：默认 Sonnet，关键节点再切 Opus，而不是整场任务都用 Opus 扛。

03 第二件事：控制上下文，不要让旧任务拖着走

上下文越长，Claude 每次处理要看的内容越多，额度消耗也越高。Claude Code 官方文档明确建议主动管理上下文：

换到不相关任务时，用 /clear 清空历史。
当前任务做完一个阶段但还要保留重点时，用 /compact 压缩。
想知道上下文里什么占空间，用 /context。
想持续看到状态，可以配置 status line。

一个好用的节奏是：

小阶段完成：/compact
大任务结束：/clear
切换无关项目：/clear
上下文接近很高占用：提前 /compact

/compact 会把前面的对话压成摘要，保留关键任务状态、结论、文件路径、待办事项，但减少后续每次请求要携带的历史。你也可以给它补一句重点：

`1`	`/compact 保留已修改文件、测试结果、剩余待办和关键设计决策`

不要等自动压缩才处理。官方文档提到，Claude Code 会在上下文接近容量上限时自动压缩，但手动在阶段边界压缩，通常更可控。

04 第三件事：长对话和大文件会让每次请求变贵

很多人以为“我只是继续问一句”，应该很便宜。但在长对话里，这一句背后可能带着大量历史、文件摘要、工具定义和系统规则。

特别容易涨上下文的东西包括：

一直不清理的长对话。
让 Claude 读完整大文件。
贴很长日志、构建输出、测试输出。
一次性塞很多截图或图片。
让它反复扫描整个仓库。
过长的 CLAUDE.md。
开了很多 MCP server。

比较省的做法是：日志只贴关键报错，测试输出只给失败部分，大文件让它先用 rg、head、tail、符号搜索定位，再读必要片段。能用命令行过滤的内容，不要整包塞进上下文。

05 第四件事：理解缓存，但不要迷信缓存

Anthropic 的 Prompt Caching 会缓存重复的 prompt 前缀。默认缓存生命周期是 5 分钟，也支持 1 小时缓存。缓存命中时，重复的大段上下文不需要完整重新处理，有助于降低成本和改善额度利用。

但缓存有几个限制：

需要内容完全匹配，文字和图片都要一致。
默认缓存是短生命周期。
改模型、改工具、改系统提示、改上下文结构，都可能降低命中。
输出 token 不会因为缓存而消失，该生成的回答仍然要生成。
Claude Code 具体如何利用缓存，是产品层实现细节，不要把它当成永远稳定的“免费记忆”。

实际使用里，最重要的不是研究缓存细节，而是保持会话稳定：

同一阶段尽量别频繁切模型。
不要中途反复改大量规则。
不要在同一任务里不停贴新图片。
长任务中间不要闲置太久后又继续塞大请求。
阶段结束主动 /compact。

这样更容易让重复上下文保持可复用，也能降低后续请求负担。

06 关于高峰时段：能避开就避开，但不要当固定公式

网上常有人说某些时段额度会更紧。官方帮助中心的表述更谨慎：可发送数量会受到 Claude 当前容量、对话长度、附件、模型和功能影响。也就是说，高峰容量确实可能影响体验，但不要把某个地区的某个时间段当成永久固定规则。

实用建议是：

大重构、大批量分析尽量放到自己网络和服务都稳定的时段。
不要在快到休息时开启一个超长任务。
预计会离开很久时，先 /compact 或 /clear。
如果只是小改动，不要开 Opus 加长上下文硬跑。

这比记一个固定“几点到几点不能用”的规则更可靠。

07 精简 CLAUDE.md、rules、MCP 和 skills

Claude Code 会在会话中加载项目规则、工具信息和一部分环境上下文。官方文档也建议把通用规则和专用规则分开，避免每次启动都带着一大包不相关内容。

比较推荐的拆法：

CLAUDE.md：只放全局都适用的核心规则。
rules：放特定路径、特定文件类型才需要的规则。
skills：放特定工作流，例如发文章、部署、生成图片、提交代码。
MCP：只启用当前任务真的会用到的 server。

如果 CLAUDE.md 写了几百上千行，每次会话都要带进去。更好的方式是把“偶尔才用”的流程移到 skill 里，需要时再调用。

MCP 也是一样。工具多不等于效率高。Claude Code 文档提到可以用 /mcp 查看并禁用不需要的 server，也可以用 /context 看是什么占用了上下文空间。

08 实用指令清单

日常最常用的是这几个：

/model

切换模型。默认建议用 Sonnet，复杂推理再用 Opus。

/clear

清空当前上下文。换无关任务时用，最省。

`1`	`/compact`

压缩历史上下文。一个阶段完成但还要继续同一任务时用。

`1`	`/context`

查看上下文占用，排查是什么吃掉空间。

/status

查看当前订阅或额度相关状态。官方帮助中心也建议用它监控剩余额度。

/mcp

查看和管理 MCP server，关闭当前不用的工具。

如果你用 API 计费模式，还可以关注 /cost；但如果是 Pro/Max 订阅，官方文档说明 /cost 的美元估算不适合作为订阅账单依据，订阅用户更应该看 /stats 和 /status 这类使用信息。

09 一套省额度工作流

比较顺手的流程可以是这样：

新任务开始前先 /clear。
默认用 Sonnet。
先让 Claude 读项目结构和关键文件，不要一口气读全仓库。
每做完一个小阶段就 /compact。
复杂卡点再切 Opus。
日志、报错、测试输出先过滤再给。
任务完成后 /clear，不要拖着旧上下文开新活。
定期检查 CLAUDE.md、MCP 和 skills，把常驻上下文压小。

这个流程的核心是：让 Claude 每次只看当前真正需要看的东西。

10 小结

Claude Code 额度快速耗尽，通常不是单一原因，而是几个因素叠加：用了高成本模型、长对话一直不清、文件和日志塞太多、MCP 和规则常驻过重、缓存命中变差，再加上高峰容量波动。

省额度的核心也很简单：

日常任务优先 Sonnet。
Opus 留给真正复杂的问题。
阶段完成用 /compact。
换任务用 /clear。
用 /context 找上下文占用来源。
精简 CLAUDE.md、rules、MCP 和 skills。
不要把整仓库、整日志、整图片包都丢进去。

同样的 Pro 或 Max 方案，能做多少事，很大程度取决于你怎么管理上下文。把上下文变小、任务边界变清楚，Claude Code 的可用时间和稳定性都会明显好很多。

参考链接

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

在 VS Code 里接入 Claude：从 API 配置到网页生成

Thu, 16 Apr 2026 17:47:17 +0800

如果你已经开始把大模型带进日常开发，最直接的感受通常不是“会不会写代码”，而是“能不能把很多零碎工作一次性推进起来”。

这类工具真正有价值的地方，不只是补全几行代码，而是能在编辑器里同时完成对话、改文件、预览结果和继续迭代。对于简单页面、原型验证、样式调整和功能补齐，这种工作方式往往比传统的手动来回切换更顺手。

这篇就整理一下，一个比较实用的思路：在 VS Code 里接入 Claude 一类模型之后，怎么把它用在真实的页面生成和小功能迭代上。

一、先把工具链接通

这类 AI 编程插件的核心流程其实都差不多：

在 VS Code 里安装支持对话式改代码的插件
在插件设置里填入模型服务的 Base URL
配置自己的 API Key
选择要使用的模型名称

完成这几步之后，编辑器里的 AI 能力才算真正可用。后面的体验差异，大多不在“能不能用”，而在“模型质量怎么样、插件交互是否顺手、生成结果是否稳定”。

如果你之前没有配过这类插件，可以把它理解成这样：

插件负责把你的自然语言请求变成编辑器里的操作流程
API 负责把请求发送给模型服务
模型负责理解你的需求并返回代码、修改建议或结构化结果

所以真正要配对的，其实就是三件事：插件、接口地址、模型名。

二、适合先从小任务开始

很多人第一次上手，会希望它直接帮自己“做一个完整项目”。这不是不行，但对新手来说，最容易建立正确预期的方式，反而是先从非常小的任务开始。

比如：

生成一个简单的前端页面
给现有页面补一个公告区域
增加注册表单
调整界面，让样式更正式一些

这种任务有几个好处：

指令足够清楚，模型更容易理解
结果可以立刻预览，反馈很快
你能明显看到“对话”和“改代码”是如何联动的

当需求比较明确时，插件通常会一边在侧边栏里和你对话，一边直接修改右侧文件。等到任务完成之后，你再看生成结果、预览页面、决定要不要继续追加需求，这个节奏会比纯聊天自然很多。

三、真正提效的不是一次生成，而是连续迭代

AI 编程最容易被误解的一点，是大家总把注意力放在“第一次生成得像不像”。

但在实际使用里，更重要的往往是第二轮、第三轮还能不能顺着改下去。

一个比较常见的过程是：

先让它快速生成一个能跑的页面骨架
再追加一两个明确功能
然后观察代码和界面是否一起变得更完整

如果工具体验比较顺，整个过程会很像你在带一个执行速度很快的初级开发同事：

你提需求
它先做出一版
你指出哪里不够
它继续修改

这种“连续对话式迭代”比单次生成更接近日常开发场景，也是它最容易拉开效率差距的地方。

四、要学会区分“适合交给 AI 的部分”和“自己顺手改更快的部分”

这也是非常关键的一点。

像页面布局、组件初稿、表单骨架、样式润色、文案占位、重复性代码补齐，这些通常都很适合交给 AI 先做。

但如果只是：

改一行按钮文字
调整一个页脚说明
换一个很小的样式细节

很多时候自己直接改会更快。因为这种修改的成本已经低到，不值得再发起一次完整的模型交互。

真正高效的使用方式，不是“什么都交给 AI”，而是知道什么时候该让它一口气做完大块工作，什么时候自己收尾更省时间。

五、API 配置是门槛，但不是难点

不少人卡住，其实不是卡在写代码，而是卡在插件配置。

常见需要确认的内容通常包括：

接口地址是不是填对了
密钥是不是有效
模型名称是不是和服务端一致
插件是否要求特定格式的 Base URL

只要这几项有一项不对，插件表面上可能还能打开，但真正发请求时就会失败。

所以如果你发现插件没有正常工作，排查顺序通常可以很简单：

先看接口地址
再看密钥
最后看模型名和插件要求的格式

把这三项核对清楚，大多数接入问题都能快速定位。

六、怎么看生成结果值不值得继续用

一个比较实用的判断标准，不是看它“惊不惊艳”，而是看下面这几件事：

生成出来的页面能不能直接跑起来
结构是不是基本清楚
追加需求后有没有明显跑偏
改动量变大时，是否还能保持一致性

如果一两轮对话之后，它已经能把页面从空白推进到一个可继续修改的状态，那这个工具基本就有实用价值了。

反过来说，如果每次生成都需要你大面积返工，那它带来的就不是提效，而只是把“写代码”换成了“审代码”。

结语

在 VS Code 里接入 Claude 一类模型，最值得期待的不是“从此不写代码了”，而是很多原本零散、重复、容易打断思路的工作，可以被一次性打包推进。

更现实的用法是：

让它先搭页面和功能骨架
用连续对话完成两三轮迭代
自己处理最后那些细小但确定的修改

这样配合下来，AI 更像一个加速器，而不是一个必须完全接管开发流程的替代者。

AI编程 on KnightLi的博客

Claude Opus 4.8 发布：Anthropic 继续强化编程与代理任务

这次更新的重点

为什么 Claude Code 用户更应该关注

effort 控制意味着什么

fast mode 的成本变化很关键

和 Opus 4.7 的关系

对 AI 编程竞争的影响

我的判断

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

它解决的是什么问题

RTK 的基本工作方式

支持哪些命令

安装和接入方式

使用时要注意什么

适合谁用

我的判断

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

持久线程

语音输入

Steering 和 queuing

工具和可触达范围

从任何地方继续工作

自动化

Goals

侧边栏

共享记忆

从代码向外扩展

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

先检查 goals 功能开关

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

Windows 上还要留意安全软件

判断是不是 prompt 的问题

小结

Codex Goal 深度解析：让 AI Agent 连续工作数小时的目标驱动工作流

Codex Goal 解决的不是循环，而是停止条件

Goal 和普通 prompt 的区别

为什么 LLM judge stop condition 很关键

哪些任务适合交给 Goal

哪些任务不适合只靠 Goal

写好 Goal Prompt 的模板

Goal Buddy 的价值：先帮你把任务说清楚

给 Codex、Claude Code、OpenCode 用户的实践建议

小结

Ollama 接入 Codex App：本地大模型如何变成 AI 编程 Agent

先澄清：这不是 OpenAI 全功能永久免费

ollama launch codex-app 做了什么？

为什么本地模型接入 Agent 很重要？

本地 Agent 的优势

1. 成本更可控

2. 可以离线工作

3. 隐私边界更清楚

模型怎么选？

硬件门槛没有想象中那么高

也可以用 llama.cpp 接 OpenAI-compatible 接口

使用本地 AI Agent 时要注意什么？

我的理解

参考链接

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

它到底是什么

推荐安装方式

默认工作流

skills 和 agents 提供了什么

插件形态和运行时状态

适合谁

使用时要注意什么

小结

参考资料

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

Spec Kit 是什么？

基本使用流程

它改变了 AI 编程的入口

核心命令怎么理解？

/speckit.constitution

/speckit.specify

/speckit.clarify

/speckit.plan

/speckit.tasks

/speckit.implement

为什么它适合 AI 编程？

`ollama launch codex-app` 做了什么？

`/speckit.constitution`

`/speckit.specify`

`/speckit.clarify`

`/speckit.plan`

`/speckit.tasks`

`/speckit.implement`