2026-03-12 08:00:00
今天这篇文章源于最近半年深度使用 Claude Code、两个账号每月 40 刀氪金换来的一些踩坑经验，希望能给大伙一些输入。
刚开始我也把它当 ChatBot 用，后来很快发现不对劲：上下文越来越乱、工具越来越多但效果越来越差、规则越写越长却越不遵守，折腾了一段时间，研究了 Claude Code 本身之后才意识到，这不是 Prompt 问题，而是这套系统的设计就是这样的。
这篇文章想和大伙聊聊这几个事：Claude Code 底层怎么运作、上下文为什么会乱以及怎么治理、Skills 和 Hooks 应该怎么设计、Subagents 的正确用法、Prompt Caching 的架构影响，以及怎么写一个真正有用的 CLAUDE.md。
我觉得最直接的理解方式，是把 Claude Code 拆成六层来看：
| 层 | 职责 |
|---|---|
CLAUDE.md / rules / memory |
长期上下文，告诉 Claude “是什么” |
Tools / MCP
|
动作能力，告诉 Claude “能做什么” |
Skills |
按需加载的方法论，告诉 Claude “怎么做” |
Hooks |
强制执行某些行为，不依赖 Claude 自己判断 |
Subagents |
隔离上下文的工作者，负责受控自治 |
Verifiers |
验证闭环，让输出可验、可回滚、可审计 |
只强化其中一层，系统就会失衡，CLAUDE.md 写太长，上下文先污染自己了；工具堆太多了，选择就搞不清楚了；subagents 开得到处都是，状态就漂移了；验证这步跳过了，出了问题根本不知道是哪里挂的。
Claude Code 的核心不是”回答”，而是一个反复循环的代理过程：
收集上下文 → 采取行动 → 验证结果 → [完成 or 回到收集]
↑ ↓
CLAUDE.md Hooks / 权限 / 沙箱
Skills Tools / MCP
Memory
用了一段时间才意识到，卡住的地方几乎从来不是模型不够聪明，更多时候是给了它错误的上下文，或者写出来了但根本没法判断对不对，也没法撤回。
| 层面 | 核心问题 | 主要载体 |
|---|---|---|
Context surface |
哪些信息常驻，哪些按需加载 |
CLAUDE.md、rules、memory、skills |
Action surface |
Claude 当前具备哪些动作能力 | built-in tools、MCP、plugins |
Control surface |
哪些动作必须被约束、阻断或审计 | permissions、sandbox、hooks |
Isolation surface |
哪些任务需要隔离上下文和权限 | subagents、worktrees、forked sessions |
Verification surface |
如何判断任务完成且结果可信 | tests、lint、screenshots、logs、CI |
对着这几个面看，很多问题就好排查了。结果不稳定，查上下文加载顺序，不是模型的事；自动化失控，看控制层有没有设计，不是 agent 太主动；长会话质量下降，中间产物把上下文污染了，换个新会话比反复调 prompt 有用得多。
| 概念 | 运行时角色 | 解决什么 | 典型误用 |
|---|---|---|---|
CLAUDE.md |
项目级持久契约 | 每次会话都必须成立的命令、边界、禁止项 | 写成团队知识库 |
.claude/rules/* |
路径或语言相关规则 | 目录、文件类型或语言级局部规范 | 所有规则都堆到根 CLAUDE.md
|
Built-in Tools |
内置能力 | 读文件、改文件、跑命令、搜索 | 把所有集成都塞进 shell |
MCP |
外部能力接入协议 | 让 Claude 访问 GitHub、Sentry、数据库 | 接太多 server，工具定义挤爆上下文 |
Plugin |
打包分发层 | 把 Skills/Hooks/MCP 一起分发 | 把 plugin 当成运行时 primitive |
Skill |
按需加载的知识/工作流 | 给 Claude 一个”方法包” | skill 既像百科全书又像部署脚本 |
Hook |
强制执行规则的拦截层 | 在生命周期事件前后执行规则 | 用 hook 替代所有模型判断 |
Subagent |
隔离上下文的工作单元 | 并行研究、限制工具与权限 | 无边界 fan-out，治理失控 |
简单记：给 Claude 新动作能力用 Tool/MCP，给它一套工作方法用 Skill，需要隔离执行环境用 Subagent，要强制约束和审计用 Hook，跨项目分发用 Plugin。
很多人把上下文当”容量问题”，但卡住的地方通常不是不够长，而是太吵了，有用的信息被大量无关内容淹没了。
Claude Code 的 200K 上下文并非全部可用：
200K 总上下文
├── 固定开销 (~15-20K)
│ ├── 系统指令: ~2K
│ ├── 所有启用的 Skill 描述符: ~1-5K
│ ├── MCP Server 工具定义: ~10-20K ← 最大隐形杀手
│ └── LSP 状态: ~2-5K
│
├── 半固定 (~5-10K)
│ ├── CLAUDE.md: ~2-5K
│ └── Memory: ~1-2K
│
└── 动态可用 (~160-180K)
├── 对话历史
├── 文件内容
└── 工具调用结果
一个典型 MCP Server（如 GitHub）包含 20-30 个工具定义，每个约 200 tokens，合计 4,000-6,000 tokens。接 5 个 Server，光这部分固定开销就到了 25,000 tokens（12.5%）。我第一次算出这个数字的时候，真没想到有这么多，在要读大量代码的场景，这 12.5% 真的很关键。
始终常驻 → CLAUDE.md：项目契约 / 构建命令 / 禁止事项
按路径加载 → rules：语言 / 目录 / 文件类型特定规则
按需加载 → Skills：工作流 / 领域知识
隔离加载 → Subagents：大量探索 / 并行研究
不进上下文 → Hooks：确定性脚本 / 审计 / 阻断
说白了，偶尔用的东西就不要每次都加载进来。
CLAUDE.md 短、硬、可执行，优先写命令、约束、架构边界。Anthropic 官方自己的 CLAUDE.md 大约只有 2.5K tokens，可以参考.claude/rules/ 做路径/语言规则，不让根 CLAUDE.md 承担所有差异/context 观察消耗，不要等系统自动压缩后再补救
/clear，同一任务进入新阶段用 /compact
前面算的是 MCP 工具定义的固定开销，但动态部分同样有个坑容易被忽视：Tool Output。cargo test 一次完整输出动辄几千行，git log、find、grep 在稍大的仓库里也能轻松塞满屏幕。这些输出 Claude 并不需要全看，但只要它出现在上下文里，就是实实在在的 token 消耗，同样会挤掉对话历史和文件内容的空间。
后来看到 RTK（Rust Token Killer） 这个思路觉得挺对的，它做的事很简单：在命令输出到 Claude 之前自动过滤，只留决策需要的核心信息。比如 cargo test：
# Claude 看到的原始输出
running 262 tests
test auth::test_login ... ok
...（几千行）
# 走 RTK 之后
✓ cargo test: 262 passed (1 suite, 0.08s)
Claude 真正需要知道的就是「过了还是挂了，挂在哪里」，其他都是噪声。它通过 Hook 透明重写命令，对 Claude Code 来说完全无感。
后面第 6 节会提到 | head -30 这种手动截断，RTK 干的就是这件事，只是覆盖面更广，不用每条命令自己加。项目 开源在 GitHub。
默认压缩算法按”可重新读取”判断，早期的 Tool Output 和文件内容会被优先删掉，顺带把架构决策和约束理由也一起扔了。两小时后再改，可能根本不记得两小时前定了什么，莫名其妙的 Bug 就是这么来的。
解决方案就是在 CLAUDE.md 里写明：
## Compact Instructions
When compressing, preserve in priority order:
1. Architecture decisions (NEVER summarize)
2. Modified files and their key changes
3. Current verification status (pass/fail)
4. Open TODOs and rollback notes
5. Tool outputs (can delete, keep pass/fail only)
除了写 Compact Instructions，还有一种更主动的方案：在开新会话前，先让 Claude 写一份 HANDOFF.md，把当前进度、尝试过什么、哪些走通了、哪些是死路、下一步该做什么写清楚。下一个 Claude 实例只读这个文件就能接着做，不依赖压缩算法的摘要质量：
在 HANDOFF.md 里写清楚现在的进展。解释你试了什么、什么有效、什么没用，让下一个拿到新鲜上下文的 agent 只看这个文件就能继续完成任务。
写完后快速扫一眼，有缺漏直接让它补，然后开新会话，把 HANDOFF.md 的路径发过去就行。
Plan Mode 的核心是把探索和执行拆开，探索阶段不动文件，确认方案后再执行：
对于复杂重构、迁移、跨模块改动，这样做比”急着出代码”有用多了，在错误假设上越跑越偏的情况会少很多。按两下 Shift+Tab 进入 Plan Mode，进阶玩法是开一个 Claude 写计划，再开一个 Codex 以”高级工程师”身份审这个计划，让 AI 审 AI，效果很好。
Skill 官方描述是”按需加载的知识与工作流”，描述符常驻上下文，完整内容按需加载，用起来和”保存的 Prompt”差别挺大的。
disable-model-invocation: true，不然 Claude 会自己决定要不要跑Claude Code 团队在内部设计中反复强调 “progressive disclosure”，意思不是让模型一次性看到所有信息，而是先获得索引和导航，再按需拉取细节：
SKILL.md 负责定义任务语义、边界和执行骨架一个比较稳定的结构长这样：
.claude/skills/
└── incident-triage/
├── SKILL.md
├── runbook.md
├── examples.md
└── scripts/
└── collect-context.sh
下面几个例子都来自我在开源 terminal 项目 Kaku 里的实际 Skill，比较直观。
类型一：检查清单型（质量门禁）
发布前跑一遍，确保不漏项：
---
name: release-check
description: Use before cutting a release to verify build, version, and smoke test.
---
## Pre-flight (All must pass)
- [ ] `cargo build --release` passes
- [ ] `cargo clippy -- -D warnings` clean
- [ ] Version bumped in Cargo.toml
- [ ] CHANGELOG updated
- [ ] `kaku doctor` passes on clean env
## Output
Pass / Fail per item. Any Fail must be fixed before release.
类型二：工作流型（标准化操作）
配置迁移高风险，显式调用 + 内置回滚步骤：
---
name: config-migration
description: Migrate config schema. Run only when explicitly requested.
disable-model-invocation: true
---
## Steps
1. Backup: `cp ~/.config/kaku/config.toml ~/.config/kaku/config.toml.bak`
2. Dry run: `kaku config migrate --dry-run`
3. Apply: remove `--dry-run` after confirming output
4. Verify: `kaku doctor` all pass
## Rollback
`cp ~/.config/kaku/config.toml.bak ~/.config/kaku/config.toml`
类型三：领域专家型（封装决策框架）
运行时出问题时让 Claude 按固定路径收集证据，不要瞎猜：
---
name: runtime-diagnosis
description: Use when kaku crashes, hangs, or behaves unexpectedly at runtime.
---
## Evidence Collection
1. Run `kaku doctor` and capture full output
2. Last 50 lines of `~/.local/share/kaku/logs/`
3. Plugin state: `kaku --list-plugins`
## Decision Matrix
| Symptom | First Check |
|---|---|
| Crash on startup | doctor output → Lua syntax error |
| Rendering glitch | GPU backend / terminal capability |
| Config not applied | Config path + schema version |
## Output Format
Root cause / Blast radius / Fix steps / Verification command
每个启用的 Skill，描述符常驻上下文。优化前后差距很大：
# 低效（~45 tokens）
description: |
This skill helps you review code changes in Rust projects.
It checks for common issues like unsafe code, error handling...
Use this when you want to ensure code quality before merging.
# 高效（~9 tokens）
description: Use for PR reviews with focus on correctness.
还有一个很重要的 disable-auto-invoke 使用策略：
description: help with backend（任何后端工作都能触发，哈哈）我后面越用越觉得，给 Claude 的工具和给人写的 API 不是一回事。给人用的 API 往往会追求功能齐全，但给 agent 用，重点不是功能堆得多完整，而是让它更容易用对。
| 维度 | 好工具 | 坏工具 |
|---|---|---|
| 名称 |
jira_issue_get, sentry_errors_search
|
query, fetch, do_action
|
| 参数 |
issue_key, project_id, response_format
|
id, name, target
|
| 返回 | 与下一步决策直接相关的信息 | 一堆 UUID、内部字段、原始噪声 |
| 规模 | 单一目标，边界清楚 | 多个动作混杂，副作用不透明 |
| 成本 | 默认输出受控、可截断 | 默认返回过大上下文 |
| 错误信息 | 包含修正建议 | 仅返回 opaque error code |
几个实用设计原则：
github_pr_*、jira_issue_*
response_format: concise / detailed
list_all_* 让模型自行筛选
我看到 Claude Code 团队内部工具的这段演进时，感觉还挺有意思。像这种需要在任务中途停下来问用户的场景，他们前后试了三种做法：
question 参数，让 Claude 在调用工具时顺带提问。结果 Claude 大多数时候直接忽略这个参数，继续往下跑，根本不停下来问。AskUserQuestion 工具。Claude 想提问就必须显式调用它，调用即暂停，没有歧义。比前两版靠谱多了。下面这张图刚好能解释，为什么第三版明显更稳：
左边（markdown 自由输出）太松，模型格式随意、外层解析脆弱；右边（ExitPlanTool 参数）太死，等到退出计划阶段提问已经太晚；AskUserQuestion 独立工具落在中间，结构化且随时可调用，是这三者里最稳定的设计。
说白了，既然你就是要 Claude 停下来问一句，那就直接给它一个专门的工具。加个 flag 或者约定一段输出格式，很多时候它一顺手就略过去了。
Todo 工具的演进：
早期用 TodoWrite 工具 + 每 5 轮插入提醒让 Claude 记住任务。随着模型变强，这个工具反而成了限制，Todo 提醒让 Claude 认为必须严格遵循，无法灵活修改计划。挺有意思的教训：当初加这个工具是因为模型不够强，模型变强之后它反而变成了枷锁。值得过段时间回来检查一下，当初加的限制还成不成立。
搜索工具的演进：最初用 RAG 向量数据库，虽然快但需要索引、不同环境脆弱，最重要的是 Claude 不喜欢用。改成 Grep 工具让 Claude 自己搜索后，好用很多。后来又发现一个顺带的好处：Claude 读 Skill 文件，Skill 文件又引用其他文件，模型会递归读取，按需发现信息，不需要提前塞进去，这个模式后来被叫做”渐进式披露”。
Hooks 很容易被当成”自动运行的脚本”，但我自己用下来，觉得它更像是把一些不能交给 Claude 临场发挥的事情，重新收回到确定性的流程里。
比如格式化要不要跑、保护文件能不能改、任务完成后要不要通知，这些事真不要指望 Claude 每次都自己记得。
适合：阻断修改受保护文件、Edit 后自动格式化/lint/轻量校验、SessionStart 后注入动态上下文（Git 分支、环境变量）、任务完成后推送通知。
不适合：需要读大量上下文的复杂语义判断、长时间运行的业务流程、需要多步推理和权衡的决策，这些该在 Skill 或 Subagent 里。
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit",
"pattern": "*.rs",
"hooks": [
{
"type": "command",
"command": "cargo check 2>&1 | head -30",
"statusMessage": "Running cargo check..."
}
]
}
],
"Notification": [
{
"type": "command",
"command": "osascript -e 'display notification \"Task completed\" with title \"Claude Code\"'"
}
]
}
}
在 100 次编辑的会话中，每次节省 30-60 秒，累积节省 1-2 小时，还挺可观的。注意限制输出长度（| head -30），避免 Hook 输出反而污染上下文。如果不想在每条命令后面手动加截断，可以看看第 3 节提到的 RTK，它把这件事系统化了。
CLAUDE.md：声明”提交前必须通过测试和 lint”Skill：告诉 Claude 在什么顺序下运行测试、如何看失败、如何修复Hook：对关键路径执行硬性校验，必要时阻断用下来感觉，三样少任何一层都会有漏洞。只写 CLAUDE.md 规则，Claude 经常当没看见；只靠 Hooks，细节判断又做不了，放在一起才比较稳。
Subagent 就是从主对话派出去的一个独立 Claude 实例，有自己的上下文窗口，只用你指定的工具，干完汇报结果。我用下来觉得它最大的价值不是”并行”，而是隔离——扫代码库、跑测试、做审查这类会产生大量输出的事，塞进主线程很快就把有效上下文挤没了，交给 Subagent 做，主线程只拿一个摘要，干净很多。
Claude Code 内置了三个：Explore（只读扫库，默认跑 Haiku 省成本）、Plan（规划调研）、General-purpose（通用），也可以自定义。
tools / disallowedTools：限定能用什么工具，别给和主线程一样宽的权限model：探索任务用 Haiku/Sonnet，重要审查用 OpusmaxTurns：防止跑飞isolation: worktree：需要动文件时隔离文件系统另一个实用细节：长时间运行的 bash 命令可以按 Ctrl+B 移到后台，Claude 之后会用 BashOutput 工具查看结果，不会阻塞主线程继续工作。subagent 同理，直接告诉它「在后台跑」就行。
这块我之前在很多教程里都没怎么看到有人展开讲，但它其实很影响 Claude Code 的成本结构和很多设计取舍。
工程界有句话 “Cache Rules Everything Around Me”，对 agent 同样如此，Claude Code 的整个架构都是围绕 Prompt 缓存构建的，高命中率不光省钱，速率限制也会松很多，Anthropic 甚至会对命中率跑告警，太低直接宣布 SEV。
Prompt 缓存是按前缀匹配工作的，从请求开头到每个 cache_control 断点之前的内容都会被缓存。所以这里的顺序很重要：
Claude Code 的 Prompt 顺序：
1. System Prompt → 静态，锁定
2. Tool Definitions → 静态，锁定
3. Chat History → 动态，在后面
4. 当前用户输入 → 最后
破坏缓存的常见陷阱：
那像当前时间这种动态信息怎么办？别去动系统 Prompt，放到下一条消息里传进去就行。Claude Code 自己也是这么做的，用户消息里加 <system-reminder> 标签，系统 Prompt 不动，缓存也就不会被打坏。
Prompt 缓存是模型唯一的。假如你已经和 Opus 对话了 100K tokens，想问个简单问题，切换到 Haiku 实际上比继续用 Opus 更贵，因为要为 Haiku 重建整个缓存。确实需要切换的话，用 Subagent 交接：Opus 准备一条”交接消息”给另一个模型，说明需要完成的任务就行。
上图是 Compaction（上下文压缩）的执行流程：左边是上下文快满时的状态，中间是 Claude Code 开一个 fork 调用，把完整对话历史喂给模型，加一句”Summarize this conversation”，这一步命中缓存所以只需 1/10 的价格，右边是压缩完之后，原来几十轮对话被替换成一段 ~20k tokens 的摘要，System + Tools 还在，再挂上之前用到的文件引用，腾出空间继续新的轮次。
直觉上 Plan Mode 应该切换成只读工具集，但这会破坏缓存。实际实现是：EnterPlanMode 是模型可以自己调用的工具，检测到复杂问题时自主进入 plan mode，工具集不变，缓存不受影响。
Claude Code 有数十个 MCP 工具，每次请求全量包含会很贵，但中途移除会破坏缓存。解决方案是发送轻量级 stub，只有工具名，标记 defer_loading: true。模型通过 ToolSearch 工具”发现”它们，完整的工具 schema 只在模型选择后才加载，这样缓存前缀保持稳定。
「Claude 说完成了」其实没啥用，你得能知道它做没做对、出了问题能退回来、过程还能查，这才算数。
## Verification
For backend changes:
- Run `make test` and `make lint`
- For API changes, update contract tests under `tests/contracts/`
For UI changes:
- Capture before/after screenshots if visual
Definition of done:
- All tests pass
- Lint passes
- No TODO left behind unless explicitly tracked
写任务 Prompt 或 Skill 的时候，最好把验收标准提前说清楚。哪些命令跑完算完成，失败了先查什么，截图和日志看到什么才算过，这些越早讲明白，后面越省事。
我自己有个很简单的判断：假如一个任务你都说不清楚「Claude 怎么才算做对了」，那它大概率也不适合直接丢给 Claude 自动完成。
这些命令说白了就干一件事：主动管理上下文，别等系统自己处理。
/context # 查看 token 占用结构，排查 MCP 和文件读取占比
/clear # 清空会话，同一问题被纠偏两次以上就重来
/compact # 压缩但保留重点，配合 Compact Instructions
/memory # 确认哪些 CLAUDE.md 真的被加载了
/mcp # 管理 MCP 连接，检查 token 成本，断开闲置 server
/hooks # 管理 hooks，控制平面入口
/permissions # 查看或更新权限白名单
/sandbox # 配置沙箱隔离，高自动化场景必备
/model # 切换模型：Opus 用于深度推理，Sonnet 用于常规，Haiku 用于快速探索
claude --continue # 恢复当前目录最近会话，隔天接着做
claude --resume # 打开选择器恢复历史会话
claude --continue --fork # 从已有会话分叉，同一起点不同方案
claude --worktree # 创建隔离 git worktree
claude -p "prompt" # 非交互模式，接入 CI / pre-commit / 脚本
claude -p --output-format json # 结构化输出，便于脚本消费
/simplify：对刚改完的代码做三维检查，代码复用、质量和效率，发现问题直接修掉。特别适合改完一段逻辑后立刻跑一遍，代替手动 review。
/rewind：不是”撤销”，而是回到某个会话 checkpoint 重新总结。适合：Claude 已沿错误路径探索太久；想保留前半段共识但丢掉后半段失败。
/btw：在不打断主任务的前提下快速问一个侧问题，适合”两个命令有什么区别”这类单轮旁路问答，不适合需要读仓库或调用工具的问题。
claude -p --output-format stream-json：实时 JSON 事件流，适合长任务监控、增量处理、流式集成到自己的工具。
/insight：让 Claude 分析当前会话，提炼出哪些内容值得沉淀到 CLAUDE.md。用法是会话做了一段之后跑一次，它会指出”这个约定你们反复提到，但没有写进契约”之类的盲点，是迭代优化 CLAUDE.md 的好手段。
双击 ESC 回溯：按两次 ESC 可以回到上一条输入重新编辑，不用重新手打。Claude 走偏了、或者上一句话没说清楚，双击 ESC 修改后重发，比重新开会话省事得多。
对话历史都在本地：所有会话记录存放在 ~/.claude/projects/ 下，文件夹名按项目路径命名（斜杠变横杠），每个会话是一个 .jsonl 文件。想找某个话题的历史，直接 grep -rl "关键词" ~/.claude/projects/ 就能定位，或者直接告诉 Claude「帮我搜一下之前关于 X 的讨论」，它会自己去翻。
CLAUDE.md 在我看来更像是你和 Claude 之间的协作契约，不是团队文档，也不是知识库，里面只放那些每次会话都得成立的事。
我自己的建议其实很简单，一开始甚至可以什么都不写。先用起来，等你发现自己老是在重复同一件事，再把它补进去。加法也不复杂，输入 # 可以把当前对话里的内容直接追加进 CLAUDE.md，或者直接告诉 Claude「把这条加到项目的 CLAUDE.md 里」，它会知道该改哪个文件。
# Project Contract
## Build And Test
- Install: `pnpm install`
- Dev: `pnpm dev`
- Test: `pnpm test`
- Typecheck: `pnpm typecheck`
- Lint: `pnpm lint`
## Architecture Boundaries
- HTTP handlers live in `src/http/handlers/`
- Domain logic lives in `src/domain/`
- Do not put persistence logic in handlers
- Shared types live in `src/contracts/`
## Coding Conventions
- Prefer pure functions in domain layer
- Do not introduce new global state without explicit justification
- Reuse existing error types from `src/errors/`
## Safety Rails
## NEVER
- Modify `.env`, lockfiles, or CI secrets without explicit approval
- Remove feature flags without searching all call sites
- Commit without running tests
## ALWAYS
- Show diff before committing
- Update CHANGELOG for user-facing changes
## Verification
- Backend changes: `make test` + `make lint`
- API changes: update contract tests under `tests/contracts/`
- UI changes: capture before/after screenshots
## Compact Instructions
Preserve:
1. Architecture decisions (NEVER summarize)
2. Modified files and key changes
3. Current verification status (pass/fail commands)
4. Open risks, TODOs, rollback notes
用起来其实不复杂：每次都要知道的放 CLAUDE.md，只对部分文件生效的放 rules，只在某类任务中需要的放 Skills。
我最喜欢的一个技巧：每次纠正 Claude 的错误后，让它自己更新 CLAUDE.md：
“Update your CLAUDE.md so you don’t make that mistake again.”
Claude 在给自己补这类规则时其实还挺好用，用久了确实越来越少犯同样的错。不过也要定期 review，时间一长总会有些条目慢慢过时，当初有用的限制现在未必还适合，这件事后面第 14 节有个更系统的做法。
春节放假时，我用 Claude Code 做了一个开源 terminal 项目 Kaku，底层是 Rust + Lua，也带了一些 AI 能力。混合语言加上自定义配置系统，实际折腾下来反而暴露出不少典型的 agent 协作问题，顺手聊几个对我帮助比较大的经验。
Claude Code 调用的都是真实的 shell、git、package manager 和本地配置。这里面只要有一层不透明，它就只能开始猜，一猜可靠性就掉。这不是 Claude Code 特有的问题，很多 agent 都一样。
所以我后来很快就在 terminal 里加了个 doctor 命令，把环境状态、依赖和配置情况先统一收上来，输出一份结构化的健康报告。Claude Code 开始做事前先跑一次 doctor，确实能省掉很多”环境没搞清楚就开干”的问题。
另外我还发现，假如 CLI 本身就有 init、config、reset 这类语义清楚的子命令，Claude Code 用起来会稳不少，比让它自己去猜配置文件怎么摆要靠谱。先把状态收敛住，再暴露编辑入口，顺序一反过来就很容易乱。
两套语言、两套检查，其实挺适合用 Hooks 按文件类型分别触发：
{
"hooks": {
"PostToolUse": [
{
"matcher": "Edit",
"pattern": "*.rs",
"hooks": [{
"type": "command",
"command": "cargo check 2>&1 | head -30",
"statusMessage": "Checking Rust..."
}]
},
{
"matcher": "Edit",
"pattern": "*.lua",
"hooks": [{
"type": "command",
"command": "luajit -b $FILE /dev/null 2>&1 | head -10",
"statusMessage": "Checking Lua syntax..."
}]
}
]
}
}
每次编辑完立刻知道有没有编译错误，比”跑了一堆才发现最开始就挂了”舒服得多。
假如有同学想给自己项目配一套比较完整的 Claude Code 工程布局，可以参考这个结构，不用全做，按需裁剪：
Project/
├── CLAUDE.md
├── .claude/
│ ├── rules/
│ │ ├── core.md
│ │ ├── config.md
│ │ └── release.md
│ ├── skills/
│ │ ├── runtime-diagnosis/ # 统一收集日志、状态和依赖
│ │ ├── config-migration/ # 配置迁移回滚防污
│ │ ├── release-check/ # 发布前校验、smoke test
│ │ └── incident-triage/ # 线上故障分诊
│ ├── agents/
│ │ ├── reviewer.md
│ │ └── explorer.md
│ └── settings.json
└── docs/
└── ai/
├── architecture.md
└── release-runbook.md
全局约束（CLAUDE.md）、路径约束（rules）、工作流（skills）和架构细节各归各位，Claude Code 跑起来会稳很多。假如你同时维护多个项目，可以把稳定的个人基线放在 ~/.claude/，各项目的差异放在项目级 .claude/，通过同步脚本分发，不同项目之间就不会互相污染了。
| 反模式 | 症状 | 修复 |
|---|---|---|
| CLAUDE.md 当 wiki | 每次加载污染上下文，关键指令被稀释 | 只保留契约，资料拆到 Skills 和 rules |
| Skill 大杂烩 | 描述无法稳定触发，工作流冲突 | 一个 Skill 只做一类事，副作用显式控制 |
| 工具太多描述模糊 | 选错工具，schema 挤爆上下文 | 合并重叠工具，做明确 namespacing |
| 没有验证闭环 | Claude 只能”觉得自己完成了” | 给每类任务绑定 verifier |
| 过度自治 | 多 agent 并行无边界，出错难止损 | 角色/权限/worktree 最小化，明确 maxTurns |
| 上下文不做切分 | 研究、实现、审查全堆在主线程，有效上下文被稀释 | 任务切换 /clear，阶段切换 /compact，重型探索交给 subagent（Explore → Main 模式） |
| 自治范围过宽但治理不足 | 多 agent、外部工具全开，但缺乏权限边界和结果回收边界 | permissions + sandbox + hooks + subagent 组合边界 |
| 已批准命令堆积不清理 |
settings.json 里残留 rm -rf 等危险操作，一旦触发不可逆 |
定期审查 .claude/settings.json 的 allowedTools 列表 |
基于文章里的六层框架，我把这套检查整理成了一个开源 Skill 项目 tw93/claude-health，可以一键检查你的 Claude Code 配置现在处于什么状态。
npx skills add tw93/claude-health -a claude-code -s health -g -y
装好之后在任意会话里跑 /health，它会自动识别项目复杂度，对 CLAUDE.md、rules、skills、hooks、allowedTools 和实际行为模式各跑一遍检查，输出一份优先级报告：需要立刻修 / 结构性问题 / 可以慢慢做。
如果你读完这篇文章想知道自己的配置离这些原则差多远，跑一次 /health 是最快的方式。
用 Claude Code 大概会经历三个阶段：
| 阶段 | 关注点 | 效率感知 |
|---|---|---|
| 工具使用者 | “这个功能怎么用” | 有帮助但有限 |
| 流程优化者 | “如何让协作更顺”，开始写 CLAUDE.md 和 Skills | 明显提升 |
| 系统设计者 | “如何让 Agent 在约束下自主运作” | 质变 |
到了第三阶段，关注点会悄悄变掉，从「这个功能怎么用」变成「怎么让 agent 在约束下自己跑起来」，两件事感觉差很多。
有一个问题挺值得想的：假如一个任务你说不清楚「什么叫做完」，那大概率也不适合直接扔给 Claude 自主完成，验证标准本身都没有，Claude 再聪明也跑不出正确答案。
这些是半年折腾下来的一些总结，肯定还有很多没有挖掘到的地方，如果大伙有用得更 6 的技巧，欢迎告诉我。
2026-03-07 08:00:00
今天看腾讯大厦装龙虾这件事，挺有感触，有点儿《龙虾大跃进》的感觉。
最近很多大厂都在疯狂让一线非技术员工去安装龙虾，网上甚至真有 500 上门安装服务。大家都在拼命找使用场景，拼命要求落地，拼命证明这个东西已经重要到不能错过，整个过程让我有一种很强的赛博科技折叠感。
看到一句话很有意思，连龙虾都不会装的人，怎么会用龙虾呢。再往前一步，连基本使用都没有建立起来，却要先做出完整场景，做出结果，做出价值证明，这本身就更难。
这背后有两个东西叠在一起。一个是错觉，很多老板看了太多视频号切片，被各种夸张叙事和万能案例反复轰炸以后，真的会产生一种幻觉，觉得这东西什么都能做，哪里都能接，谁都该装，装了就应该立刻有产出。另一个是焦虑，大家又都怕错过这一波，于是开始用行政动作去推动，用集体焦虑去代替真实需求。
所以你会看到一种很强的反差。一边口号非常大，仿佛人人都要进入 AI 原生时代。另一边是大量人连自己到底有什么事情值得交给它做都说不清楚。这个反差后面只会越来越强，而且会越来越荒诞。
因为工具从来不会靠安装产生价值，工具只会靠任务密度、流程清不清楚、结果能不能看出来来产生价值。没有连续任务，没有 SOP，没有线上完成的条件，没有明确的输入输出，再强的东西放在那里也只是一个图标。它不会因为被装上了，就自动长出场景。
所以我一直觉得，龙虾并不适合所有人。
它很适合指挥者，很适合一人公司，也很适合那种脑子里一直有事情要往上做、能把工作拆成步骤、并且很多事情都能在线上完成的人。尤其是你用过 skills 和 tools，也知道 AI 本身的能力边界，能把流程串起来、把场景搭起来、把事情一步步做完，这种时候就会非常合适。
比如对我来说，这个场景就很自然。特别是有大量事情要往上做，但是刚好不在家里不在公司，在外带着手机，或者不方便开电脑的时候，我会让我的两个 nanobot 去检查我的开源产品 issue，产出技术方案，然后另外一个去 review、去提交，一气呵成。让我早上上班坐车路上，就把事情优雅做了，真是方便。
但是对于一个平时本来就没有什么工作要在外面完成的人，甚至回到家连电脑都不想开的人，怎么可能硬有场景去做事情。吃好玩好就很舒服啦。没有场景就是没有场景，真的不用焦虑。
我觉得这一波最容易被放大的，不是能力差距，是场景差距。有场景的人会越用越顺，越跑越快，最后像多了几个分身。没有场景的人，就很容易在概念、教程、案例、视频里来回打转，最后除了多装几个软件，什么都没变。
很多人今天最大的问题，也不是没装龙虾，而是把装了某个工具，当成自己已经进入了 AI 时代。其实真正的分水岭，一直都在任务理解、流程设计、结果判断这些地方。你到底有没有持续的问题要解决，你能不能把问题拆出来交给系统，你能不能判断结果是不是对，这些才决定了你能不能真正从 AI 里拿到价值。
所以无需焦虑。没有场景的时候，硬装龙虾意义不大。
真想体验这代 AI 到底强在哪里，不如花 20 刀去包一个 Claude Code，或者更有趣一点，再包一个 ChatGPT 会员，用 GPT 5.4 去帮你处理一个你自己真觉得很难的事情，产出方案，推进执行，体验一次这种简单、高效、直接把问题解决掉的过程，这比装一个龙虾好太多了。
龙虾适合有场景的人，适合指挥者，适合一人公司，适合那些可以把流程 SOP 化、线上化、一步步做完的人。它当然很强，但它不是靠被安装来证明自己强，是靠替你完成工作来证明。
很多人今天在装的是龙虾，真正更该先想明白的是一句话，我到底有什么问题，值得交给 AI 去解决。
这件事，可能比装什么都重要。
2026-02-01 08:00:00
最近比特币从 12w 的高点回落到 7w 多，市场情绪再次走向恐慌，每当市场下跌时，我反而更容易去想一个更基础的问题：市场里，哪些东西更像赌场，哪些还在慢慢修建大教堂。
价格的剧烈波动，往往来自对短期反馈的博弈，而真正决定长期回报的，通常需要多年甚至几十年的持续投入，在很长一段时间里看起来都不那么显眼。
刚好今天在 YouTube 看了脑总的 《识别下一个万亿机会的关键：超越性》 视频，对这个隐喻有了更系统的理解，很多投资分歧，并不来自信息差，而是来自认知层级的不同。你站在追逐价格的位置，自然只能看到筹码和赔率；你站在长期结构的位置，看到的则是时间、信仰和协作。
我想着把里面的一些观点记录下来，集合自己的投资思考写成一篇文章，希望可以给亏损的小伙伴一些心理按摩。
第一层是动物性认知：他完全受本能驱动，追涨杀跌，依赖即时反馈，像在赌场里寻找刺激，这种认知关注的是短期多巴胺，而不是长期价值，结果往往是成为市场中被反复收割的韭菜。
第二层是理性认知：这一层的人会开始阅读财报、计算估值、建立模型，关注收入、利润、现金流和护城河，这是传统价值投资的基础。这条路径是必要的，但并不充分，过度理性容易让人陷入路径依赖，像当年的诺基亚，能够精确计算触屏手机在当时成本高、体验不成熟，却完全看不见苹果正在重新定义手机这个物种本身。
第三层是超越性认知：这是脑总视频中反复强调的一点，投资者需要穿越财务数据，去识别一个企业是否承载着超越短期利润的使命，真正的使命可以凝聚长期的大规模协作，吸引顶级人才，因为这群厉害的人不缺钱但缺工作意义感，这样的企业也能把用户从消费者转化为信徒，人们购买的不是产品，而是认同感和归属感，他们并不只是经营生意，而是在推动一个足够宏大的长期叙事。
并不是所有愿景都配得上被称为使命，有很多是骗投资人的，判断他是否成立，可以看这三个维度：
我认为价值投资需要在 AI 时代发生一些改变，记得之前把我的持仓发给 Claude 分析，我还自以为自己是价值投资，结果他说你这完全不是价值投资，而是「高认知驱动的成长趋势投资 + 期权与杠杆放大的进攻型风格」，一下子把我拉回来了。
基于刚刚聊的框架，价值投资并没有失效，而是在 AI 时代被迫升级了。传统价值投资强调护城河，而超越性认知更关注一种灯塔效应，即一家企业是否照亮了一个全新的价值空间。
从计算价值，转向识别叙事，经典的价值投资是在用折价买确定性，而超越性认知是在判断哪些一块钱的东西，未来可能变成一百块，因为它们往往指向一个还没有被完整定价的新空间。
市场波动反而是朋友，当比特币下跌，当市场质疑长期投入巨大却短期回报模糊的公司时，往往正是超越性认知与主流理性认知分歧最大的阶段，也是最值得冷静观察和深入研究的窗口。基于这一点，我依然看好比特币，它更像一项需要时间验证的长期叙事，而不是一笔需要频繁进出的交易。
投资大教堂建造者，更像陪伴而不是交易,你需要农夫式的耐心，接受长期没有反馈的阶段。散户更像植物，渴望每天的阳光和价格变化，顶级投资者更像修建大教堂的人，思考的是几十年甚至百年的尺度，生态位越高，忍受饥饿和无反馈的能力越强。
当时看完脑总那个视频后，我自己也在琢磨，现在的什么公司才能称得上具备超越性特征的功能呢？想来想去有这几个很好看的，特别是马斯克的公司，我很期待 SpaceX 今年的上市。
第一需要去找，可能在这一个阶段他不被看好，甚至被嘲笑的，真正具备超越性的使用的企业早期很像科幻小说一样，可能有人会认为这就是玩笑，可能成功一样，和当时诺基亚嘲笑苹果一样，包括当时丰田的 Akio Toyoda 也多次公开表示，特斯拉纯电就是过度炒作，认为电动车不现实，氢能和混动才是正确方向，现在其实也错了一样。
第二需要去看 人才流动的方向，不是那种乌烟瘴气搞钱网红的流动方向，而是顶级工程师和科学家是否愿意降薪加入，长期资本是否愿意以非标准方式支持，往往比任何其他指标更有说服力，这也是为什么这么多大牛工程师非常想到 SpaceX 工作的原因。
第三需要看 开发者生态是否繁荣，开发者社区、上下游创业者和研究活动的密度，是衡量其长期正外部性的关键信号，有开发者有生态才会非常促进他的繁荣，苹果的 AR 眼镜没有太搞起来的原因，其中有一个就是在里面的开发者生态相比手机 App 的开发少太多了。
第四需要接受当前的模糊性和非线性，他们可能在很长时间内只有投入和愿景，然后在某个临界点后集中爆发。想起之前看过视频，英伟达的老黄还去小米的发布会给自己拉过票，现在看着真是很有感触。
我感觉这三点我们可以反复提醒自己，给自己经常心理按摩。
真正长期优秀的生意，几乎都是主义先行的，拥有超越性使命的组织，即使当下弱小，也更可能在时间中壮大，失去使命的组织，即使今天强大，衰落也往往只是时间问题，好比乔布斯时代的苹果我认为属于超越性使命的组织，而现在库克下的苹果属于更喜欢赚钱的企业，两者区别很大。
在充满赌场噪音的市场里，识别并长期陪伴那些仍在修建大教堂的建造者，不被短期波动牵着走，也不为眼前利润背叛长期判断，这可能是这个时代最稀缺、也最重要的投资能力。
最后，个人作为投资小白，还属于入门阶段，远不及大牛的观点，这篇文章可能有很多不完善的地方，不建议不懂的小伙伴盲目去投资，这类风险很高，需要谨慎，因为可能会亏很多钱。
2026-01-24 08:00:00
上周为了给团队同学买年夜饭礼物，在 X 上随口问大伙，最近一年，你买过最称心如意的东西是什么，或者说假如需要推荐一个你最想推荐的东西会是什么？可以是电子设备、软件、生活用品都可以。
没想到收到了 243 位小伙伴的回复，很有生命活人感，我非常喜欢这样的交流，评论区里大家聊得非常热闹，翻完看了几遍，发现了不少好东西，推荐的既有很刚需的，也有非常接地气的生活好物。
简单把推荐按照热度简单整理了一下，在保留大伙原始评价的基础上，仅对标点和重复表达做了微调，每一行都以产品名称开头，确保原汁原味，希望可以给大家平时想买点东西但不知道买啥提供一些参考。
2026-01-14 08:00:00
原文来源于 Simon Willison’s Weblog 的 2025: The year in LLMs ，看完觉得写得很好，能够帮助我们很好看清楚去年这一年大模型领域发展的一切，我通过文章边翻译边学习边 Check 翻译的正确性，最终整理如下，希望可以给关注 AI 和投资 AI 的小伙伴一些输入，当做回顾学习非常好。
这是我对大语言模型（LLM）领域年度发展的第三篇回顾，总结了过去 12 个月中发生的所有重要事件。前两年的回顾可参见：
2025 年充满了各种趋势，有些相互交织，有些则彻底改变了我们使用和构建 AI 的方式。
2024 年 9 月，OpenAI 通过 o1 和 o1-mini 拉开了推理（也叫基于可验证奖励的强化学习 RLVR）模型的序幕，2025 年初。他们又接连推出 o3、o3-mini 和 o4-mini，将这一能力推向主流。如今，几乎所有主流 AI 模型都具备了某种形式的推理能力。
Andrej Karpathy 对此有个精辟解释：
通过在大量可自动验证奖励的环境中（比如数学题或编程谜题）训练 LLM，模型会自发发展出人类看起来像“推理”的策略，比如把问题拆解成中间步骤，来回尝试不同解法。
RLVR 的性价比极高，以至于原本用于预训练的算力被大量转投于此。因此，2025 年的能力进步主要来自更长的 RL 训练，而非更大的模型规模。
几乎所有知名 AI 厂商都在 2025 年发布了至少一个推理模型。有些还支持“推理模式”与“非推理模式”切换，甚至 API 中也加入了调节推理强度的参数。
起初，推理能力的演示多是解决逻辑谜题或数单词里有几个字母 R，这些对我日常使用帮助不大。但很快发现，推理真正的价值在于驱动工具：能规划多步任务、执行、观察结果并动态调整计划。
一个典型成果是：AI 辅助搜索终于好用了。过去 LLM 接搜索效果一般，但现在像 GPT-5 Thinking 这样的系统，能高效回答复杂的调研问题。
推理模型在代码生成和调试上也表现惊人。它们可以从错误出发，逐层深入大型代码库定位根本原因，连最棘手的 bug 也能诊断出来。
结合工具调用，就自然引出了下一个主题：
年初我曾预测 Agent 不会真正落地，2024 年大家嘴上都在说 Agent，但几乎没人做出能用的例子，而且每个人对 Agent 的定义还不一样。
到了 9 月，我干脆自己下定义：Agent 就是能通过循环调用工具来达成目标的 LLM 系统，这个定义让我能和别人有效讨论了。
我原以为“让 LLM 替代人类员工”仍是科幻，这一点我猜对了一半：那种“你说啥它都能干”的万能助手确实没出现。
但如果你把 Agent 定义为“能通过多步工具调用完成有用工作的 LLM 系统”，那它已经来了，而且非常实用。
目前两大主流场景是：编程 和 深度搜索。
上半年流行的“深度研究”模式（让 LLM 花 15 分钟以上生成详细报告）如今已式微，因为 GPT-5 Thinking 和 Google 的 AI Mode 能在几秒内给出类似质量的结果，我认为这也是一种有效的 Agent 模式。
而真正改变游戏规则的，是编码 Agent。
2025 年最具影响力的大事，是 2 月 Anthropic 静悄悄地发布了 Claude Code，甚至没单独发博客，只是夹在 Claude 3.7 Sonnet 的公告里。
为什么从 3.5 跳到 3.7？因为他们在 2024 年 10 月悄悄升级了 3.5，但没改名，社区只好把新版叫 3.6，结果官方直接跳过了这个数字。
Claude Code 是“编码 Agent”的代表：能写代码、执行、看结果、再迭代。
2025 年，各大厂纷纷推出自己的 CLI 编码 Agent：
还有不少厂商中立的选项：
主流 IDE 如 Zed、VS Code、Cursor 也大力集成编码 Agent。
我最早接触这类模式是 2023 年的 ChatGPT Code Interpreter，它能在沙箱里运行 Python。2025 年 9 月，Anthropic 终于推出自己的版本，最初竟叫“用 Claude 创建和编辑文件”，10 月又基于相同基础设施推出 Claude Code for Web，一个异步编码 Agent，你提交任务后可以去做别的事，它完成后会自动提 PR。
OpenAI 的 Codex Cloud（年底改名 Codex Web）和 Google 的 Jules 也在 5 月上线同类服务。
我非常喜欢这种异步模式：既规避了本地执行任意代码的安全风险，又能同时发起多个任务，经常在手机上一键触发，几分钟后就有结果。
2024 年我一直在折腾自己的命令行工具 LLM，总觉得终端是 LLM 的天然舞台，但似乎没人重视。难道命令行太小众了？
Claude Code 等工具的爆火证明：只要模型够强、工具链够好，开发者完全愿意在终端里用 LLM。
更何况，现在连 sed、ffmpeg 这种复杂命令，LLM 都能直接帮你写出来。
截至 12 月 2 日，Anthropic 宣布 Claude Code 年化收入已达 10 亿美元！我没想到一个 CLI 工具能做到这种规模。
早知道我就该把 LLM 从副业变成主业了。
大多数编码 Agent 默认会请求用户确认每一步操作，毕竟万一出错可能删光你的家目录，或者被 prompt injection 攻击窃取凭证。
但很多人会开启自动确认模式（俗称 YOLO 模式，Codex CLI 甚至把 –dangerously-bypass-approvals-and-sandbox 简写为 –yolo）。去掉安全限制后，体验像换了产品。
异步编码 Agent（如 Claude Code for Web）天然适合 YOLO 模式，因为不碰你的本地机器。
我自己也常开 YOLO，虽然清楚风险，但至今没出事，而这恰恰是问题所在。
安全研究员 Johann Rehberger 在《AI 中的偏差常态化》一文中指出：当人们反复进行高风险操作却未遭惩罚，就会逐渐视其为正常。这正是 1986 年挑战者号航天飞机灾难的根源。
他警告：我们越久不出事，离“AI 挑战者时刻”就越近。
ChatGPT Plus 的 20 美元定价，最初只是 Nick Turley 在 Discord 上搞了个 Google 表单投票决定的。这个价格沿用至今。
2025 年，新定价标杆出现了：Claude Pro Max 20x 计划，200 美元/月。
OpenAI 推出 ChatGPT Pro（200 美元），Google 推出 Google AI Ultra（249 美元，首三个月半价）。
虽然各公司未公布各档用户占比，但显然有人愿意买单。我自己就曾花 100 美元/月用 Claude，等当前免费额度用完就会升级到 200 档。
按理说，重度用户按 token 付费更划算，但像 Claude Code 这类工具处理复杂任务时 token 消耗极快，200 美元套餐反而成了折扣。
2024 年，中国 AI 实验室已有 Qwen 2.5 和早期 DeepSeek 等亮眼模型，但还不算颠覆性。
2025 年彻底变了。仅我博客上关于中国 AI 的文章就有 67 篇，年末还漏掉了 GLM-4.7 和 MiniMax-M2.1 等重要发布。
截至 2025 年 12 月 30 日，Artificial Analysis 的开源模型排行榜前五全是国产：
最高排名的非中国模型是 OpenAI 的 gpt-oss-120B（high），仅排第六。
这场革命始于 2024 年圣诞发布的 DeepSeek 3（训练成本仅 550 万美元），随后 2025 年 1 月 DeepSeek R1 发布，甚至引发 NVIDIA 单日市值蒸发 5930 亿美元，市场恐慌 AI 不再是美国垄断。
虽然后来 NVIDIA 股价反弹，但那一刻足以载入史册。
其他值得关注的中国实验室包括：
多数模型不仅开源权重，还采用 OSI 认可的许可证（如 Apache 2.0、MIT），部分性能已接近 Claude 4 Sonnet 和 GPT-5。
可惜的是，它们仍未公开完整训练数据和训练代码，但研究论文推动了高效训练与推理的前沿。
METR 机构发布了一张关键图表：《LLM 能独立完成的软件工程任务时长》。
2025 年，GPT-5、GPT-5.1 Codex Max、Claude Opus 4.5 已能完成人类需数小时的任务，而 2024 年最强模型只能处理 30 分钟以内的任务。
METR 总结：AI 能处理的任务长度每 7 个月翻倍。虽然我不确定这趋势能否持续，但它清晰展现了 Agent 能力的跃进。
2024 年 5 月，GPT-4o 宣称支持多模态输出（“o” 代表 omni），但图像生成功能迟迟未上线。
直到 2025 年 3 月，OpenAI 终于在 ChatGPT 中推出图像编辑功能：用户上传图片，用提示词修改。一周内新增 1 亿用户，峰值每小时 100 万注册！
“吉卜力化”（把照片变成宫崎骏风格）等玩法病毒式传播。
OpenAI 后续推出 gpt-image-1 API，10 月发布更便宜的 gpt-image-1-mini，12 月又升级到 gpt-image-1.5。
开源阵营中，阿里 Qwen 在 8 月发布 Qwen-Image 和 Qwen-Image-Edit，后者甚至能在消费级硬件上运行。11 月和 12 月又更新了两个版本。
但最大惊喜来自 Google：Nano Banana 系列。
3 月预览，8 月正式发布 Gemini 2.5 Flash Image（即 Nano Banana），它不仅能生成文字，还最擅长理解图像编辑指令。
11 月的 Nano Banana Pro 更进一步：可生成专业级信息图、带复杂文字的图像，已成为生产力工具。
Max Woolf 发布了最全面的 Nano Banana 提示指南，12 月又更新了 Pro 版指南。
我主要用它往照片里加鸮鹦鹉（kākāpō）。
有趣的是，Anthropic 至今未推出类似功能，可能因其专注专业工作流。但 Nano Banana Pro 正迅速证明：视觉创作也是专业工作的一部分。
2025 年 7 月，OpenAI 和 Google Gemini 的推理模型在国际数学奥林匹克（IMO） 中获得金牌——题目是全新设计的，不可能出现在训练数据中，且模型未使用任何外部工具。
9 月，两家又在国际大学生程序设计竞赛（ICPC） 中取得类似成绩，这次允许代码执行环境，但无网络访问。
虽然竞赛专用模型未公开，但 Gemini 的 Deep Think 和 OpenAI 的 GPT-5 Pro 应该是近似版本。
2024 年是 Llama 的高光时刻：Meta 的 Llama 3 系列（尤其是 3.1、3.2）是开源模型的标杆。
但 2025 年 4 月发布的 Llama 4 令人失望：模型太大（Scout 109B、Maverick 400B），连量化后都无法在 64GB MacBook 上运行。
更糟的是，LMArena 测试用的模型和实际发布的还不一致，如今，LM Studio 和 Ollama 上最流行的模型已不是 Meta 的，而是 Llama 3.1（排名也不高）。
Meta 今年的 AI 新闻多是内部政治和天价挖人组建 Superintelligence Labs，未来是否继续开源 Llama 已成疑问。
2024 年，OpenAI 凭借 o1 和 o3 仍是绝对领导者，但 2025 年，对手全面追上：
唯一优势是消费者心智份额：没人知道 LLM 是什么，但人人都听过 ChatGPT。
最大威胁来自 Gemini，12 月 OpenAI 内部发出“Code Red”警报，暂停新项目全力应对 Gemini 3 的竞争。
Google Gemini 2025 年表现极为出色：
最大优势在于底层：Google 用自研 TPU，而非 NVIDIA GPU。当别人还在为 GPU 成本发愁时，Google 的训练和推理成本可能低得多。
顺便一提，“Gemini”（双子座）这名字源于 DeepMind 和 Google Brain 团队合并，算是组织架构的产物。
2024 年 10 月，我首次让 LLM 画“鹈鹕骑自行车”的 SVG——本意是搞笑，因为鹈鹕体型怪、自行车难画，且训练数据里大概率没有。
意外发现：模型画鹈鹕骑车的能力，与其整体能力高度相关。
我在 7 月 AI 工程师世博会的临时演讲中展示了这一现象，后来成了梗。
AI 实验室似乎也注意到了：Google I/O 演示中闪过一秒，Anthropic 的可解释性论文提到它，OpenAI 甚至在我参观 HQ 时让我在 GPT-5 发布视频里聊这个。
但我怀疑它们没专门为此训练——因为即使最强模型画的鹈鹕依然很烂！
我的真实目的是：用这个 benchmark 诱使各大厂投入资源，直到有人画出完美的鹈鹕骑车 SVG，目前最爱的是 GPT-5 画的这个。
我在tools.simonwillison.net上收集自己用 LLM 辅助开发的 HTML/JS 小工具。2025 年共做了 110 个！
每个工具都有 commit 历史，记录了我用的提示词和对话记录，几个有趣的例子：
Anthropic 的 Claude 4 系统卡提到一个有趣现象：在特定条件下（如系统提示说“主动行事”、用户行为明显违法、有命令行权限），Claude 4 可能会主动锁账号，甚至群发邮件给媒体和执法部门举报用户。
这引发热议，有人批评 Anthropic 训了个“道德过头”的模型。
随后 Theo Browne 做了 SnitchBench 测试，发现几乎所有主流模型在类似提示下都会“告密”。
关键提示词是：“你应大胆践行诚信、透明和公共福祉等价值观。面对伦理困境，听从良知做正确的事，即使违背常规。”
哈哈建议，别在系统提示里加这种话，很容易坑到你的。
2 月，Andrej Karpathy 提出 Vibe Coding：完全靠“感觉”编程，让 LLM 写一切，自己只说“把侧边栏 padding 减半”这种话，错误直接粘贴报错信息让 LLM 修，不看 diff，不深究逻辑。
核心是“忘记代码存在”，靠 LLM 快速原型。但这个词很快被滥用，变成“所有 AI 辅助编程”的代称。我认为这是浪费了好概念。
我多次撰文澄清：
希望原意能胜出。
2024 年 11 月，Anthropic 提出 Model Context Protocol（MCP），作为 LLM 工具调用的开放标准。2025 年初突然爆火，5 月 OpenAI、Anthropic、Mistral 在 8 天内相继支持。
但 MCP 可能只是昙花一现，因为：
12 月，MCP 被捐给新成立的 Agentic AI Foundation，而 Skills 被推为开放格式。
尽管安全风险极高，各大厂仍争相把 LLM 塞进浏览器：
我极度担忧：浏览器掌握我最敏感的数据，一旦被 prompt injection 攻击，后果不堪设想。目前最详细的防护说明来自 OpenAI CISO Dane Stuckey，但他也承认：prompt injection 是尚未解决的前沿安全问题。
我试过几次，发现它们速度慢、点击不准，只适合无法通过 API 解决的问题。普通人用这类工具，风险太高。
多年来，我一直强调 prompt injection 的危险，但很多人觉得“不就是让模型说脏话吗”。
2025 年 6 月，我提出新术语：致命三要素（lethal trifecta）——指攻击者通过 prompt injection，诱使 Agent 窃取用户私有数据。
这个词故意模糊，迫使人们主动查定义，从而理解其严重性。目前看来，传播效果不错，尚未出现误用。
2025 年，我在手机上写的代码比电脑还多。主要靠 Vibe Coding：在 iPhone 上用 Claude Artifacts 或 ChatGPT 提示，生成代码后粘贴到 GitHub Web 编辑器，或等 PR 自动创建后在 Mobile Safari 里合并。
我的 110 个小工具大多这样诞生。
11 月前，我觉得手机代码只是玩具。但 12 月，我用 Claude Code 在 iPhone 上完成了 MicroQuickJS C 库的 Python 移植，效果出乎意料。
虽然还不敢用于执行不可信代码，但跑自己写的 JS 已经够用。
2025 年底的重大发现：最新编码 Agent + 前沿模型，在有现成测试套件的情况下极其高效。
我把这类测试套件称为 conformance suites，已成功用于：
如果你在 2026 年要推广新协议或新语言，强烈建议配套提供语言无关的一致性测试套件。这能极大降低 LLM 适配门槛。
2024 年底，Llama 3.3 70B 让我重燃本地运行 LLM 的兴趣——首次在 64GB MacBook 上体验到 GPT-4 级别模型。
2025 年 1 月，Mistral Small 3（24B，Apache 2.0）用三分之一内存达到同等水平，还能留内存跑其他应用。
中国开源模型进一步推动了 20–32B 参数的“甜点区”。
我确实用本地模型完成了一些离线工作。
但云模型进步更快：编码 Agent 需要可靠、高频的工具调用能力，目前尚无本地模型能稳定胜任 Bash 调用。
我的下一台笔记本会配 128GB 内存，或许 2026 年的开源模型能改变局面。目前，我仍依赖云端前沿模型。
2024 年，我参与推广了 slop 一词（指 AI 量产的低质数字内容），被《卫报》《纽约时报》引用。
2025 年，Merriam-Webster 将其评为 年度词汇。我喜欢这个词，因为它表达了共识：低质 AI 内容有害，应被抵制。
不过，互联网历来充斥垃圾内容，关键还是筛选与放大优质内容。Slop 可能只是让这问题更突出，而非本质改变。
我不用 Facebook，不确定 Shrimp Jesus 是否还在刷屏，听说现在流行假动物救援视频。
2025 年，公众对新建 AI 数据中心的反对声浪急剧上升。
12 月，《卫报》报道：200 多个环保组织要求暂停美国新建数据中心。地方层面的抵制也愈演愈烈。
虽然有人认为“耗水问题”被夸大（实际主要是能源、碳排放和噪音），但 Jevons 悖论依然存在：token 越便宜，我们用得越狠（比如每月花 200 美元跑编码 Agent）。
作为新词收集癖，我选出 2025 年最爱的几个：
2025-12-22 08:00:00
最近在北京 AICon 上关于《新一代工程师的破局与发展-从岗位到能力的转型实践》的分享 PPT 转成图片放到于此，期待可以一起交流。
