这两天我看了一个小而完整的项目：NavSphere。

项目在线地址也已经有了：

https://nav.myls.top/

它不是那种只有一个首页截图能看的"演示型项目"，而是一个已经具备完整使用链路的开发者导航站：

• 前台导航首页
• GitHub 登录
• 后台管理
• JSON 批量导入
• Chrome 书签导入脚本
• Supabase RLS 权限控制
• 可直接接到 Vercel 部署

如果只看最终界面，会觉得这只是一个"收藏夹网站"。 但从工程角度看，它其实是一个很典型的 AI 时代小型全栈项目样本：

需求不算大，但链路完整，足够检验 Codex 和 Claude Code 到底能不能把一个项目从想法快速推进到可部署状态。

这篇文章就从几个角度来复盘它：

• 用到了哪些技术
• 项目是怎么组织的
• 实际怎么部署
• 如果用 Codex 和 Claude Code 做，速度大概有多快
• 人工出力主要还剩下什么

NavSphere 是什么 ​

先用一句话概括：

NavSphere 是一个面向开发者和团队内部工具场景的导航站。

它不是单纯展示一堆链接，而是把"公开导航"和"个人私有导航"放在同一个系统里：

• 未登录用户可以看到公开分类和公开链接
• 登录用户可以看到自己的私有分类和私有链接
• 后台可以维护分类、链接、排序和导入
• 分类支持路径式命名，例如 研发 / AI工具

这类项目非常适合做成一个轻量化内部产品，或者作为个人工作台的入口层。

这个项目用了哪些技术 ​

从仓库来看，NavSphere 的核心技术栈非常清晰：

• Next.js 16
• React 19
• TypeScript
• Tailwind CSS 4
• Supabase Auth + Database
• Vercel Analytics / Speed Insights

如果再细分一层，可以看到它是一个标准的 Next.js App Router + Supabase SSR 架构。

1. 前端层 ​

项目使用的是 Next.js App Router。 路由结构很直观：

• app/page.tsx 负责前台导航首页
• app/login 负责登录页
• app/admin 负责后台页面
• app/auth/callback/route.ts 负责 GitHub OAuth 回调
• app/api/import 和 app/api/ai-import 负责导入接口

前台导航页并不是一个纯静态页面，它会在服务端读取导航数据，然后交给客户端壳组件做交互。

这里有几个做得比较顺手的点：

• 用 useDeferredValue 和自定义 debounce 处理搜索
• 用 IntersectionObserver 跟踪当前可见分类
• 用 useTransition 处理后台跳转和搜索输入的过渡状态
• 用 router.prefetch('/admin') 提前预取后台页面

也就是说，这不是"能跑就行"的 React 页面，而是已经开始用 React 19 的交互能力去优化体验了。

2. 数据层 ​

数据层是 Supabase PostgreSQL。

数据库里只有两张核心表：

• categories
• links

另外定义了一个枚举：

• link_environment，值为 test 和 prod

这个建模很克制，但已经够用：

• 分类有名称、描述、排序、公开状态、创建者
• 链接有名称、URL、环境、描述、图标、排序、公开状态、所属分类、创建者

整个 schema 里还有几个值得注意的细节：

• 用触发器自动维护 updated_at
• 给公开数据和个人数据分别建了索引
• 给 name 和 description 建了 pg_trgm GIN 索引
• 通过 (created_by, name) 和 (created_by, category_id, name) 做唯一约束

这说明作者并不是只想把东西存进去，而是已经考虑到搜索、排序和多用户隔离这些真实使用问题。

3. 权限层 ​

这个项目最像"正式产品"的一点，在于它不是前端自己判断权限，而是把权限下沉到了数据库层。

Supabase schema 里启用了 RLS，并且分别定义了：

• 匿名用户只能读公开分类和公开链接
• 已登录用户可以读公开数据和自己的私有数据
• 插入、更新、删除只能操作自己的数据
• 链接写入时还会检查所属分类是不是当前用户自己的分类

这一层很关键。

因为很多小项目在早期最容易偷懒的地方，就是权限只做在页面上，数据库其实没有真正拦住。 但 NavSphere 这套写法，已经是比较稳的做法了。

4. 认证层 ​

认证采用的是：

Supabase Auth + GitHub OAuth

这套组合非常适合开发者工具项目。

原因也很简单：

• 目标用户本来就有 GitHub 账号
• 不需要自己维护密码体系
• 登录链路短
• 后续如果要和开发工具生态结合，也更自然

项目里当前只保留了 GitHub 登录方式，这其实是对的。

在这类小型项目里，过早支持邮箱、短信、多个 OAuth Provider，往往只会把复杂度抬高，但对早期价值没有明显帮助。

5. 运维辅助层 ​

这个项目还有一个很实用的小设计：Chrome 书签导入脚本。

仓库自带 scripts/export-chrome-bookmarks.mjs，可以把本地 Chrome 书签导出成项目可导入的 JSON 格式。

这件事看起来不大，但很有产品意识。

因为导航站最常见的问题不是"系统做不出来"，而是：

第一批数据怎么进来。

如果每个人都要手动录入几十上百个链接，系统的可用性会下降很多。 而书签导入脚本一加，迁移成本马上就低了一截。

这个项目的结构为什么适合 AI 协作 ​

NavSphere 很适合拿来说明一个问题：

不是所有项目都同样适合 AI 辅助开发。

它之所以适合，是因为它同时满足了几个条件：

• 目录结构清晰
• 模块职责分明
• 技术栈主流
• 依赖链不复杂
• 数据模型简单但真实
• 页面数量不多，但闭环完整

仓库的主结构大概是这样：

app/                    路由、页面、API、OAuth 回调
components/             前台和后台组件
lib/data/               导航查询、后台查询、导入逻辑
lib/supabase/           Supabase 客户端封装
data/                   导入示例数据
scripts/                Chrome 书签转换脚本
supabase/schema.sql     数据库结构与 RLS 策略

对 Codex 或 Claude Code 来说，这种项目有几个天然优势：

• 很容易快速扫清全局上下文
• 很容易定位修改点
• 很容易做端到端的小闭环改动
• 很容易把"页面、接口、数据库"串起来理解

换句话说，这不是那种需要先读三天历史包袱才能动手的项目。 AI 工具能直接进入高价值区。

它是怎么部署的 ​

从仓库信息看，NavSphere 当前的部署思路很明确：

前端部署在 Vercel，数据和认证放在 Supabase。

当前线上访问地址是：

• https://nav.myls.top/

这是现在做小型 Next.js 全栈项目非常顺手的一套组合。

1. Vercel 部署前端 ​

仓库里已经存在 .vercel/project.json，并且依赖中也接入了：

• @vercel/analytics
• @vercel/speed-insights

这基本说明项目已经按 Vercel 的方式在跑了，或者至少已经完成了绑定。

对 Next.js App Router 项目来说，Vercel 的好处非常直接：

• 零配置支持 Next.js
• Route Handler、SSR、静态资源都能自然托管
• 预览部署方便
• 和 GitHub 工作流贴合

2. Supabase 承担数据与登录 ​

部署这个项目时，真正需要先准备好的其实不是 Vercel，而是 Supabase。

最小步骤大概是：

1. 新建一个 Supabase 项目
2. 在 SQL Editor 执行 supabase/schema.sql
3. 在 Auth 里启用 GitHub Provider
4. 配置 GitHub OAuth 回调地址
5. 准备环境变量

项目当前需要的关键环境变量非常少：

NEXT_PUBLIC_SUPABASE_URL=...
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_DEFAULT_KEY=...

也就是说，它的部署门槛其实不高。

3. 一条比较实际的上线链路 ​

如果我来部署这个项目，我会按这个顺序：

1. 先把 Supabase 项目和 schema 跑起来
2. 配 GitHub OAuth，确认本地登录回调正常
3. 在本地导入一批样例数据
4. 再把仓库接到 Vercel
5. 在 Vercel 配同样的环境变量
6. 把 GitHub OAuth 回调地址补上生产域名

这样做的原因是：

这个项目真正复杂的不是前端构建，而是"登录 + 数据权限 + 数据初始化"这三件事要一次打通。

前端页面本身反而是最好部署的部分。

用 Codex 和 Claude Code 做，这个项目到底有多快 ​

这部分是我觉得最值得聊的。

从 Git 提交记录看，NavSphere 的时间线非常集中：

• 首个提交：2026-04-07 16:22
• 最新提交：2026-04-08 13:06
• 共 14 次提交

如果只看活跃提交窗口，这个项目的主开发期基本就集中在两段时间里：

• 4 月 7 日傍晚
• 4 月 8 日上午到中午

而从代码变化量看，在首个提交之后又累计发生了：

• 56 个文件变更
• 6397 行新增
• 757 行删除

这个规模说明它不是单纯改个 landing page，而是实打实把一个小型全栈产品骨架补全了。

我的判断：这是一个典型的"0.5 到 1 人日 AI 项目" ​

如果把 Git 时间线、项目范围和实现复杂度放在一起看，我会这样判断：

在 Codex + Claude Code 的帮助下，这个项目做到当前程度，大概率属于 0.5 到 1 人日可以完成的范围。

这里说的不是"上线运营级产品全部完成"，而是：

• 能跑
• 能登
• 能管
• 能导
• 能部署
• 权限基本正确

这个版本已经具备了。

如果完全手写，时间大概率会拉长 ​

如果换成传统纯手工开发，我对这个项目的估算会更接近：

• 经验熟练的全栈开发者：2 到 4 人日
• 如果还要一边查文档一边搭：可能更久

因为它虽然不大，但有几类事情其实都挺花时间：

• Next.js App Router 路由和页面组织
• Supabase SSR 客户端封装
• GitHub OAuth 回调接通
• RLS 策略写对
• 后台管理页和导入流程串通
• 数据导入格式和校验逻辑统一
• 本地验证 + 部署验证

这些事情单个看都不大，但凑在一起很容易把开发时间拉长。

而 AI 工具最擅长的，就是把这些"中等复杂、模式清晰、重复度高"的工作一段段吞掉。

Codex 和 Claude Code 各自适合干什么 ​

如果让我把这类项目拆成两种 AI 工具的优势，我会这样理解：

Codex 更适合：

• 直接进仓库做结构化修改
• 读现有代码后补齐缺口
• 把页面、接口、数据层一起串起来改
• 做验证、构建、查错、收尾

Claude Code 更适合：

• 快速展开方案
• 推导页面和模块结构
• 起草一版较完整的实现
• 做较长链路的代码生成和说明

当然，现实里它们往往不是二选一，而是接力关系：

Claude Code 更像高吞吐的第一轮实现，Codex 更像强执行和强收口的第二轮工程化推进。

这也是为什么现在很多项目做起来，速度会明显比过去快。

人工出力还剩多少 ​

这也是很多人最关心的问题。

我的答案是：

人工出力并没有消失，但已经从"大量敲代码"转移成了"做决策、给约束、验结果"。

如果以 NavSphere 这种项目为例，我会把人工出力大致理解成下面几个部分。

1. 人来定义边界 ​

比如这些事，仍然非常需要人来定：

• 这个项目到底是公开导航站，还是带私有空间的导航站
• 登录方式为什么只保留 GitHub
• 分类是否支持路径式命名
• 数据导入到底采用什么 JSON 结构
• 后台要做到什么程度算够用

这些不是代码生成问题，而是产品决策问题。

2. 人来确认权限和安全 ​

AI 可以写出 RLS 策略，但最后最该负责的人还是开发者自己。

尤其是像这种涉及：

• 匿名可读
• 登录后可读私有数据
• 用户只能写自己的分类和链接

这种边界，一定要人工做最终确认。

3. 人来做验收 ​

真正影响项目质量的，往往是这些最后一公里：

• 登录回调是不是正常
• 导入的数据有没有脏格式
• 排序是不是符合预期
• 空分类到底显不显示
• 生产环境回调地址有没有漏配

这些检查 AI 能辅助，但很难完全替代人工判断。

4. 一个比较现实的占比判断 ​

如果只是问"代码体力劳动"的占比，我会觉得在这类项目里，AI 已经可以吃掉大约 60% 到 80%。

但如果问的是整个项目交付过程里的总出力，我的判断会更保守一点：

人工仍然要承担大约 20% 到 40% 的关键工作量。

这些工作主要不是敲代码，而是：

• 需求取舍
• 环境配置
• 数据准备
• 权限确认
• 验收和收口

所以今天真正高效的开发方式，不是"AI 全做，人什么都不管"，而是：

人负责方向和边界，AI 负责高密度执行。

我觉得这个项目最有代表性的地方 ​

NavSphere 这个项目有代表性，不是因为它多复杂，而是因为它刚好落在一个很有现实意义的区间里：

• 足够小，个人开发者能在短时间推进
• 足够完整，不是只能截图展示
• 足够真实，已经有权限、导入、后台、部署这些实际问题
• 足够标准，AI 工具很容易介入

这类项目特别适合现在的 AI 编程工具。

因为它既不是过于简单的 demo，也不是充满历史包袱的大型遗留系统。 它属于那种：

AI 能真正把开发速度提升到肉眼可见程度的黄金区间。

最后 ​

如果只看结果，NavSphere 像是一个"普通的导航站项目"。

但如果把它放到开发流程里看，它其实更像一个信号：

现在做一个有登录、有数据库、有后台、有导入、有部署链路的小型全栈应用，真的已经进入了"周末可做完"的阶段。

前提不是 AI 会魔法，而是你要选对项目形态：

• 技术栈主流
• 结构清晰
• 业务边界明确
• 能快速验证

当这些条件满足时，Codex 和 Claude Code 这样的工具，确实能把项目推进速度提升到过去很难想象的程度。

而人最重要的价值，也会越来越集中在那几件事上：

• 想清楚做什么
• 判断什么是对的
• 决定什么先做、什么不做
• 把项目收口到可交付状态

这可能才是 AI 开发真正开始成熟的标志。

转载声明：本文翻译转载自 Affaan Mustafa（@affaanmustafa）的文章《The Longform Guide to Everything Claude Code》。

原文链接：https://x.com/affaanmustafa/article/2014040193557471352

Claude Code 深度指南（长篇版） ​

在《Claude Code 速查指南》中，我涵盖了基础设置：技能与命令、钩子、子代理、MCP、插件，以及构成高效 Claude Code 工作流骨干的配置模式。那是一份设置指南和基础设施说明。

这篇长篇指南则深入探讨那些将高效会话与浪费时间的会话区分开来的技巧。如果你还没读过速查指南，请先回去配置好你的设置。以下内容假设你已经配置好了技能、代理、钩子和 MCP，并且它们正常工作。

本文的主题包括：Token 经济学、记忆持久化、验证模式、并行化策略，以及构建可复用工作流的复合效应。这些是我经过 10 多个月的日常使用提炼出来的模式，它们决定了你是在第一个小时内就被上下文腐化困扰，还是能维持数小时的高效会话。

速查指南和长篇指南中涵盖的所有内容都可以在 GitHub 上找到。

跨会话共享记忆 ​

对于跨会话共享记忆，最好的方法是使用一个技能或命令来总结和检查进度，然后保存到 .claude 文件夹中的 .tmp 文件，并在会话结束前持续追加内容。第二天它可以以此为上下文，从上次停下的地方继续。为每个会话创建一个新文件，这样就不会将旧上下文污染到新工作中。最终你会积累一大堆会话日志——定期备份或清理不需要的会话对话。

Claude 创建一个总结当前状态的文件。检查它，如果需要可以要求修改，然后重新开始。对于新对话，只需提供文件路径。这在碰到上下文限制需要继续复杂工作时特别有用。这些文件应包含：

• 哪些方法有效（有证据可验证）
• 尝试过但无效的方法
• 尚未尝试的方法以及待办事项

战略性清除上下文 ​

一旦计划确定并清除了上下文（现在是 Claude Code 计划模式的默认选项），你就可以基于计划工作。这在积累了大量探索性上下文但已不再与执行相关时非常有用。对于战略性压缩，禁用自动压缩。在逻辑间隔点手动压缩，或创建一个技能来为你执行或根据定义的条件建议压缩。

#!/bin/bash
# Strategic Compact Suggester
# 在 PreToolUse 上运行，在逻辑间隔建议手动压缩
#
# 为什么手动优于自动压缩：
# - 自动压缩在任意时间点发生，经常在任务中途
# - 战略性压缩通过逻辑阶段保留上下文
# - 在探索后、执行前压缩
# - 在完成里程碑后、开始下一个前压缩
COUNTER_FILE="/tmp/claude-tool-count-$$"
THRESHOLD=${COMPACT_THRESHOLD:-50}

# 初始化或递增计数器
if [ -f "$COUNTER_FILE" ]; then
  count=$(cat "$COUNTER_FILE")
  count=$((count + 1))
  echo "$count" > "$COUNTER_FILE"
else
  echo "1" > "$COUNTER_FILE"
  count=1
fi

# 达到阈值工具调用后建议压缩
if [ "$count" -eq "$THRESHOLD" ]; then
  echo "[StrategicCompact] $THRESHOLD tool calls reached - consider /compact if transitioning phases" >&2
fi

将它挂载到 Edit/Write 操作的 PreToolUse 上——当你积累了足够的上下文需要压缩时，它会提醒你。

高级：动态系统提示注入 ​

我采纳并正在试用的一种模式是：不仅仅将所有内容放在 CLAUDE.md（用户范围）或 .claude/rules/（项目范围，每次会话都加载），而是使用 CLI 标志动态注入上下文。

claude --system-prompt "$(cat memory.md)"

这让你能更精确地控制何时加载什么上下文。你可以根据正在做的工作在每个会话中注入不同的上下文。

为什么这比 @ file 引用更重要：

当你使用 @ file.md 或将内容放在 .claude/rules/ 中时，Claude 在对话过程中通过 Read 工具读取——它作为工具输出进入。当你使用 --system-prompt 时，内容在对话开始前被注入到实际的系统提示中。

区别在于指令层级。系统提示内容的权威性高于用户消息，用户消息的权威性高于工具结果。对于大多数日常工作来说，这个差异是微小的。但对于严格的行为规则、项目特定约束或你绝对需要 Claude 优先处理的上下文——系统提示注入确保了它被适当地加权。

实用设置 ​

一种有效的做法是利用 .claude/rules/ 作为基线项目规则，然后为特定场景创建 CLI 别名：

# 日常开发
alias claude-dev='claude --system-prompt "$(cat ~/.claude/contexts/dev.md)"'

# PR 审查模式
alias claude-review='claude --system-prompt "$(cat ~/.claude/contexts/review.md)"'

# 研究/探索模式
alias claude-research='claude --system-prompt "$(cat ~/.claude/contexts/research.md)"'

• dev.md 专注于实现
• review.md 专注于代码质量/安全
• research.md 专注于行动前的探索

同样，对于大多数情况，使用 .claude/rules/context1.md 和直接将内容追加到系统提示之间的差异是微小的。CLI 方法更快（无需工具调用）、更可靠（系统级权威）、且稍微更节省 token。但这是一个小优化，对很多人来说可能得不偿失。

高级：记忆持久化钩子 ​

有一些大多数人不知道或知道但没有真正利用的钩子可以帮助记忆：

SESSION 1                          SESSION 2
──────────                         ──────────
[Start]                            [Start]
    │                                  │
    ▼                                  ▼
┌──────────────┐              ┌──────────────┐
│ SessionStart │ ◄── reads ───│ SessionStart │◄── 加载之前的
│    Hook      │  nothing yet │    Hook      │    上下文
└──────┬───────┘              └──────┬───────┘
       │                              │
       ▼                              ▼
   [Working]                      [Working]
       │                          (有信息的)
       ▼                              │
┌──────────────┐                      ▼
│ PreCompact   │──► 保存状态     [继续...]
│    Hook      │   压缩前
└──────┬───────┘
       │
       ▼
  [Compressed]
       │
       ▼
┌──────────────┐
│  Stop Hook   │──► 持久化到 ──────────►
│ (session-end)│   ~/.claude/sessions/
└──────────────┘

• PreCompact 钩子：在上下文压缩发生前，将重要状态保存到文件
• SessionComplete 钩子：会话结束时，将学习成果持久化到文件
• SessionStart 钩子：新会话开始时，自动加载之前的上下文

钩子配置：

{
  "hooks": {
    "PreCompact": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/pre-compact.sh"
      }]
    }],
    "SessionStart": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/session-start.sh"
      }]
    }],
    "Stop": [{
      "matcher": "*",
      "hooks": [{
        "type": "command",
        "command": "~/.claude/hooks/memory-persistence/session-end.sh"
      }]
    }]
  }
}

这些脚本的功能：

• pre-compact.sh：记录压缩事件，用压缩时间戳更新活跃会话文件
• session-start.sh：检查最近的会话文件（最近 7 天），通知可用的上下文和已学习的技能
• session-end.sh：用模板创建/更新每日会话文件，跟踪开始/结束时间

将这些链接在一起实现无需手动干预的跨会话持续记忆。这建立在第一篇文章中的钩子类型（PreToolUse、PostToolUse、Stop）之上，但专门针对会话生命周期。

持续学习 ​

我们讨论过以更新代码地图的形式进行持续记忆更新，但这同样适用于其他方面，比如从错误中学习。如果你不得不多次重复一个提示，而 Claude 遇到相同的问题或给了你之前听过的回答，这就适用于你。

最可能你需要发出第二个提示来"重新引导"并校准 Claude 的方向。这适用于任何此类场景——那些模式必须被追加到技能中。

你可以通过简单地告诉 Claude 记住它或将其添加到你的规则中来自动完成这个操作，或者你可以有一个专门做这件事的技能。

问题：浪费 token、浪费上下文、浪费时间，你的皮质醇水平飙升，因为你沮丧地对 Claude 大喊不要做你已经在之前会话中告诉它不要做的事情。

解决方案：当 Claude Code 发现非琐碎的东西——一种调试技术、一个变通方案、某个项目特定的模式——它将该知识保存为新技能。下次类似问题出现时，技能会被自动加载。

为什么用 Stop 钩子而不是 UserPromptSubmit？ UserPromptSubmit 在你发送的每条消息上运行——这开销很大，给每个提示增加延迟，坦率地说对此目的是杀鸡用牛刀。Stop 在会话结束时运行一次——轻量级，不会在会话中拖慢你，并且评估完整会话而非零散片段。

安装方法：

# 克隆到 skills 文件夹
git clone https://github.com/affaan-m/everything-claude-code.git ~/.claude/skills/everything-claude-code

# 或者只获取持续学习技能
mkdir -p ~/.claude/skills/continuous-learning
curl -sL https://raw.githubusercontent.com/affaan-m/everything-claude-code/main/skills/continuous-learning/evaluate-session.sh > ~/.claude/skills/continuous-learning/evaluate-session.sh
chmod +x ~/.claude/skills/continuous-learning/evaluate-session.sh

{
  "hooks": {
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/skills/continuous-learning/evaluate-session.sh"
          }
        ]
      }
    ]
  }
}

Stop 钩子在你的会话结束时触发——脚本分析会话中值得提取的模式（错误解决方案、调试技术、变通方案、项目特定模式等），并将它们保存为可复用技能到 ~/.claude/skills/learned/。

使用 /learn 手动提取 ​

你不必等到会话结束。该仓库还包括一个 /learn 命令，你可以在会话中刚解决了非琐碎问题时运行。它会提示你立即提取模式，起草技能文件，并在保存前要求确认。

会话日志模式 ​

该技能期望 .tmp 文件中的会话日志。模式是：~/.claude/sessions/YYYY-MM-DD-topic.tmp——每个会话一个文件，包含当前状态、已完成项目、阻塞项、关键决策和下次会话的上下文。

其他自我改进记忆模式 ​

一种方法涉及对会话日志进行反思，提炼用户偏好——本质上是建立一本关于什么有效什么无效的"日记"。每次会话后，反思代理提取什么顺利、什么失败、你做了什么纠正。这些学习成果更新一个在后续会话中加载的记忆文件。

另一种方法让系统每 15 分钟主动建议改进，而不是等你发现模式。代理审查最近的交互，提出记忆更新建议，你批准或拒绝。随着时间推移，它从你的批准模式中学习。

Token 优化 ​

我从价格敏感的用户或作为高级用户经常遇到限制问题的人那里收到了很多问题。在 token 优化方面有几个技巧。

主要策略：子代理架构 ​

主要优化你使用的工具和设计为将最便宜的足够完成任务的模型分配工作的子代理架构来减少浪费。你有几个选择——你可以尝试试错法并随着时间适应。一旦你了解了什么是什么，你可以委托给 Haiku 而不是 Sonnet，委托给 Sonnet 而不是 Opus。

基准测试方法（更复杂） ​

另一种更复杂的方法是让 Claude 设置一个基准测试，你有一个定义明确的目标和任务的仓库，以及一个定义明确的计划。在每个 git worktree 中，让所有子代理都使用同一个模型。在完成任务时记录日志——理想情况下在你的计划和任务中。你至少需要使用每个子代理一次。

完成一整轮并从 Claude 计划中勾选任务后，停止并审计进度。你可以通过比较 diff、创建在所有 worktree 中统一的对单元、集成和 E2E 测试来实现。这将根据通过的用例与失败的用例给你一个数字基准。如果所有测试在所有 worktree 上都通过，你需要添加更多测试边缘情况或增加测试的复杂性。这是否值得取决于这对你的真正重要性。

模型选择快速参考 ​

默认使用 Sonnet 完成 90% 的编码任务。在以下情况升级到 Opus：首次尝试失败、任务跨越 5 个以上文件、架构决策或安全关键代码。在以下情况降级到 Haiku：任务重复、指令非常清晰，或在多代理设置中用作"工作者"。

坦率地说，Sonnet 4.5 目前处于一个奇怪的位置，每百万输入 token 3 美元，每百万输出 token 15 美元，与 Opus 相比节省约 66.7%，绝对来说这是一个不错的节省，但相对而言对大多数人来说微不足道。Haiku 和 Opus 的组合最有意义，因为 Haiku 与 Opus 相比有 5 倍的成本差异，而与 Sonnet 相比只有 1.67 倍的价格差异。

在你的代理定义中，指定模型：

---
name: quick-search
description: Fast file search
tools: Glob, Grep
model: haiku # Cheap and fast
---

工具特定优化 ​

考虑 Claude 最频繁调用的工具。例如，用 mgrep 替换 grep——在各种任务中，与传统 grep 或 ripgrep（Claude 默认使用的）相比，平均 token 减少约一半。

后台进程 ​

在适用时，如果你不需要 Claude 处理整个输出并实时流式传输，可以在 Claude 之外运行后台进程。这可以通过 tmux 轻松实现。获取终端输出然后仅总结或复制你需要的部分。这将节省大量输入 token——Opus 4.5 每百万 token 5 美元（输入），输出每百万 token 25 美元。

模块化代码库的收益 ​

拥有更模块化的代码库，具有可复用的工具、函数、钩子等——主文件在数百行而不是数千行——既有助于 token 优化成本，又有助于第一次就正确完成任务，两者是相关的。如果你不得不多次提示 Claude，你就在消耗 token，特别是当它在很长的文件上反复阅读时。你会注意到它需要做很多工具调用来完成文件读取。在中间过程中，它让你知道文件很长并会继续读取。在这个过程中的某个环节，Claude 可能会丢失一些信息。而且停止并重新读取会消耗额外的 token。这可以通过拥有更模块化的代码库来避免。

root/
├── docs/              # 全局文档
├── scripts/           # CI/CD 和构建脚本
├── src/
│   ├── apps/          # 入口点 (API, CLI, Workers)
│   │   ├── api-gateway/  # 路由请求到模块
│   │   └── cron-jobs/
│   │
│   ├── modules/       # 系统核心
│   │   ├── ordering/  # 自包含的"订单"模块
│   │   │   ├── api/         # 面向其他模块的公共接口
│   │   │   ├── domain/      # 业务逻辑与实体（纯）
│   │   │   ├── infrastructure/  # DB、外部客户端、仓储
│   │   │   ├── use-cases/   # 应用逻辑（编排）
│   │   │   └── tests/       # 单元和集成测试
│   │   │
│   │   ├── catalog/   # 自包含的"目录"模块
│   │   │   ├── domain/
│   │   │   └── ...
│   │   │
│   │   └── identity/  # 自包含的"认证/用户"模块
│   │       ├── domain/
│   │       └── ...
│   │
│   ├── shared/        # 每个模块都使用的代码
│   │   ├── kernel/    # 基类 (Entity, ValueObject)
│   │   ├── events/    # 全局事件总线定义
│   │   └── utils/     # 深度通用辅助函数
│   │
│   └── main.ts        # 应用引导
├── tests/             # 端到端 (E2E) 全局测试
├── package.json
└── README.md

精简代码库 = 更便宜的 Token ​

这可能是显而易见的，但你的代码库越精简，token 成本就越低。使用技能持续清理代码库、通过重构来识别死代码至关重要。在某些时候，我喜欢通览整个代码库，寻找突出或看起来重复的内容，手动拼凑那个上下文，然后连同重构技能和死代码技能一起喂给 Claude。

系统提示瘦身（高级） ​

对于真正关注成本的人：Claude Code 的系统提示占用约 18k token（200k 上下文的约 9%）。这可以通过补丁减少到约 10k token，节省约 7,300 token（静态开销的 41%）。如果你想走这条路，参见 YK 的指南。个人我不做这个。

评估与 Harness 调优 ​

根据项目，你会想要使用某种形式的可观测性和标准化。

可观测性方法 ​

一种方法是将 tmux 进程挂接到跟踪思维流并在技能触发时输出。另一种方法是使用 PostToolUse 钩子记录 Claude 具体执行了什么以及确切的更改和输出。

基准测试工作流 ​

与在没有技能的情况下要求同样的事情并检查输出差异来基准测试相对性能：

[Same Task]
        │
   ┌────┴────┐
   ▼         ▼
┌────────┐ ┌────────┐
│Worktree│ │Worktree│
│  A     │ │  B     │
│有技能  │ │无技能  │
└───┬────┘ └───┬────┘
    │          │
    ▼          ▼
[Output A] [Output B]
    │          │
    └─────┬────┘
          ▼
      [git diff]
          │
          ▼
   ┌──────────────┐
   │比较日志、     │
   │token 使用、   │
   │输出质量       │
   └──────────────┘

分叉对话，在其中一个中启动一个没有技能的新 worktree，最后拉出 diff，看看记录了什么。这与持续学习和记忆部分相关联。

评估模式类型 ​

更高级的评估和循环协议在此进入。分为基于检查点的评估和基于 RL 任务的持续评估。

基于检查点的评估：

• 在工作流中设置显式检查点
• 在每个检查点根据定义的标准验证
• 如果验证失败，Claude 必须在继续之前修复
• 适用于有清晰里程碑的线性工作流

持续评估：

• 每 N 分钟或重大更改后运行
• 完整测试套件、构建状态、代码检查
• 立即报告回归
• 在继续之前停止并修复
• 适用于长时间运行的会话、探索性重构或维护

决定因素是你工作的性质。基于检查点适用于有清晰阶段的功能实现。持续适用于探索性重构或没有清晰里程碑的维护。

我想说通过一些干预，验证方法足以避免大多数技术债。让 Claude 在完成任务后通过运行技能和 PostToolUse 钩子来验证有助于此。持续的代码地图更新也有帮助，因为它保留了变更日志以及代码地图如何随时间演变，作为仓库本身之外的真相来源。通过严格的规则，Claude 会避免创建随意的 .md 文件弄得一团糟，以及相似代码的重复文件和留下死代码的荒原。

评分器类型 ​

• 基于代码的评分器：字符串匹配、二进制测试、静态分析、结果验证。快速、便宜、客观，但对有效变化脆弱。
• 基于模型的评分器：评分标准、自然语言断言、成对比较。灵活且能处理细微差别，但不具确定性且更昂贵。
• 人工评分器：主题专家审查、众包判断、抽查抽样。黄金标准质量，但昂贵且缓慢。

关键指标 ​

pass@k：k 次尝试中至少有一次成功

k 越高 = 成功概率越高

pass^k：k 次尝试必须全部成功

k 越高 = 越难（一致性）

当你只需要它工作且任何验证反馈就够时使用 pass@k。当一致性至关重要且你需要近乎确定性的输出一致性（在结果/质量/风格方面）时使用 pass^k。

构建评估路线图 ​

1. 尽早开始——从真实失败中获取 20-50 个简单任务
2. 将用户报告的失败转换为测试用例
3. 编写明确的任务——两位专家应达成相同结论
4. 构建平衡的问题集——测试行为应该和不应该发生的情况
5. 构建稳健的 harness——每次试验从干净环境开始
6. 评估代理产生了什么，而不是它采取的路径
7. 阅读多次试验的记录
8. 监控饱和度——100% 通过率意味着需要添加更多测试

并行化策略 ​

在多 Claude 终端设置中分叉对话时，确保分叉和原始对话中的操作范围定义明确。在代码更改方面争取最小重叠。选择彼此正交的任务以防止干扰的可能性。

我的偏好模式 ​

个人而言，我更喜欢让主聊天处理代码更改，而我做的分叉用于我对代码库及其当前状态的问题，或研究外部服务（如拉取文档、搜索 GitHub 寻找有帮助的开源仓库），或其他有帮助的通用研究。

关于任意终端数量 ​

Boris（Claude Code 的创建者，传奇人物）有一些关于并行化的建议，我有些同意有些不同意。他建议过像本地运行 5 个 Claude 实例和 5 个上游实例这样的事情。我建议不要设置像这样的任意终端数量。添加终端和添加实例应该是出于真正的必要性和目的。如果你能用脚本完成任务，就用脚本。如果你能在主聊天中让 Claude 在 tmux 中启动一个实例并在单独的终端中流式传输，就那样做。

你的目标应该是：用最少的可行并行化完成最多的事情。

对于大多数新手，我甚至建议远离并行化，直到你掌握了只运行单个实例并在其中管理一切的技巧。我不是在提倡限制自己——我是在说要小心。大多数时候，甚至我也总共只使用 4 个终端左右。我发现通常用 2 或 3 个 Claude 实例就能完成大部分事情。

扩展实例时 ​

如果你确实要开始扩展实例并且有多个 Claude 实例处理彼此重叠的代码，使用 git worktree 并为每个实例制定非常明确的计划是必须的。此外，为了避免在恢复会话时对哪个 git worktree 用于什么感到困惑（除了树的名称），使用 /rename <name> 命名为你的所有聊天命名。

使用 Git Worktree 进行并行工作 ​

# 为并行工作创建 worktree
git worktree add ../project-feature-a feature-a
git worktree add ../project-feature-b feature-b
git worktree add ../project-refactor refactor-branch

# 每个 worktree 获得自己的 Claude 实例
cd ../project-feature-a && claude

好处：

• 实例之间没有 git 冲突
• 每个都有干净的工作目录
• 容易比较输出
• 可以在不同方法间基准测试相同任务

级联方法 ​

运行多个 Claude Code 实例时，用"级联"模式组织：

• 在右边的新标签页中打开新任务
• 从左到右扫描，从最旧到最新
• 保持一致的方向流
• 根据需要检查特定任务
• 一次最多关注 3-4 个任务——超过这个，心智负担增长速度比生产力更快

从头开始：两实例启动模式 ​

从头开始时，实际的基础很重要。这应该是显而易见的，但随着代码库复杂度和规模增加，技术债也会增加。管理它非常重要，如果你遵循一些规则并不那么困难。

两实例启动模式 ​

对于我自己的工作流管理（不是必须的但有帮助），我喜欢用 2 个打开的 Claude 实例启动一个空仓库。

实例 1：脚手架代理

• 搭建脚手架和基础工作
• 创建项目结构
• 设置配置（CLAUDE.md、规则、代理——速查指南中的所有内容）
• 建立约定
• 搭建骨架

实例 2：深度研究代理

• 连接到你所有的服务、网络搜索等
• 创建详细的 PRD
• 创建架构 mermaid 图
• 编译来自实际文档的参考

启动设置：左终端用于编码，右终端用于提问——使用 /rename 和 /fork。

你最初需要的最低限度就够了——这比每次都使用 Context7 或喂入链接让它抓取或使用 Firecrawl MCP 站点更快。当你在某事中已经深陷其中，Claude 明显在语法上出错或使用过时的函数或端点时，所有这些方法都有效。

llms.txt 模式 ​

如果可用，你可以在许多文档参考上找到 llms.txt，方法是到达它们的文档页面后加上 /llms.txt。这会给你一个干净的、LLM 优化的文档版本，你可以直接喂给 Claude。

哲学：构建可复用模式 ​

我完全认同的一个洞察："早期，我花时间构建可复用工作流/模式。构建很繁琐，但随着模型和代理 harness 改进，这产生了疯狂的复合效应。"

值得投资的：

• 子代理（速查指南）
• 技能（速查指南）
• 命令（速查指南）
• 规划模式
• MCP 工具（速查指南）
• 上下文工程模式

为什么它会复合："最好的部分是所有这些工作流都可以转移到 Codex 等其他代理。" 一旦构建，它们跨模型升级工作。对模式的投资 > 对特定模型技巧的投资。

子代理上下文问题 ​

子代理的存在是为了通过返回摘要而不是转储所有内容来节省上下文。但编排器拥有子代理缺少的语义上下文。子代理只知道字面查询，不知道请求背后的目的/推理。摘要经常遗漏关键细节。

比喻："你的老板派你去开会并要求一份摘要。你回来给了他一个概要。十有八九，他会有后续问题。你的摘要不会包含他需要的一切，因为你没有他拥有的隐式上下文。"

迭代检索模式 ​

┌─────────────────┐
│   ORCHESTRATOR  │
│  (has context)  │
└────────┬────────┘
         │ dispatch with query + objective
         ▼
┌─────────────────┐
│   SUB-AGENT     │
│ (lacks context) │
└────────┬────────┘
         │ returns summary
         ▼
┌─────────────────┐    ┌─────────────┐
│   EVALUATE      │──no─►│ FOLLOW-UP   │
│  Sufficient?    │       │  QUESTIONS  │
└────────┬────────┘    └──────┬──────┘
         │ yes               │
         ▼                   │ sub-agent
      [ACCEPT]          fetches answers
         │                   │
         ◄───────────────────┘
                         (max 3 cycles)

修复方法是让编排器：

• 评估每个子代理的返回
• 在接受之前提出后续问题
• 子代理回到源，获取答案，返回
• 循环直到足够（最多 3 个循环以防止无限循环）

传递目标上下文，而不仅仅是查询。分派子代理时，包含特定查询和更广泛的目标。这有助于子代理在摘要中优先包含什么。

编排器顺序阶段模式 ​

Phase 1: RESEARCH (use Explore agent)
- 收集上下文
- 识别模式
- 输出: research-summary.md

Phase 2: PLAN (use planner agent)
- 阅读 research-summary.md
- 创建实现计划
- 输出: plan.md

Phase 3: IMPLEMENT (use tdd-guide agent)
- 阅读 plan.md
- 先写测试
- 实现代码
- 输出: code changes

Phase 4: REVIEW (use code-reviewer agent)
- 审查所有更改
- 输出: review-comments.md

Phase 5: VERIFY (use build-error-resolver if needed)
- 运行测试
- 修复问题
- 输出: done 或 loop back

关键规则：

1. 每个代理获得一个清晰的输入并产生一个清晰的输出
2. 输出成为下一阶段的输入
3. 永远不要跳过阶段——每个都增加价值
4. 在代理之间使用 /clear 保持上下文新鲜
5. 将中间输出存储在文件中（不仅仅是内存）

代理抽象层级 ​

第一层：直接增益（易于使用）

• 子代理——防止上下文腐化和临时专业化的直接增益。效果约为多代理的一半，但复杂度低得多
• 元提示——"我花 3 分钟提示一个 20 分钟的任务。" 直接增益——提高稳定性并验证假设
• 一开始多问用户——通常是增益，虽然你需要在计划模式中回答问题

第二层：高技能门槛（更难用好）

• 长时间运行的代理——需要理解 15 分钟任务与 1.5 小时与 4 小时任务的形状和权衡。需要一些调整，显然是非常长的试错过程
• 并行多代理——方差很高，只对高度复杂或良好分割的任务有用。"如果 2 个任务各需要 10 分钟，而你花任意时间提示或者更糟的合并更改，那是适得其反的"
• 基于角色的多代理——"模型演进太快，除非套利非常高，否则硬编码的启发式规则不适用。" 难以测试
• 计算机使用代理——非常早期的范式，需要磨合。"你让模型做它们一年前绝对不是设计来做的事情"

要点：从第一层模式开始。只有在掌握了基础并有真正需求时才晋升到第二层。

MCP 替代策略 ​

一些 MCP 是可替代的，会释放你的上下文窗口。方法如下。

对于版本控制（GitHub）、数据库（Supabase）、部署（Vercel、Railway）等 MCP——这些平台大多数已经有强大的 CLI，MCP 本质上只是在包装它们。MCP 是一个不错的包装器，但需要付出代价。

要让 CLI 像 MCP 一样运行而不实际使用 MCP（以及随之而来的减少上下文窗口），考虑将功能打包到技能和命令中。将 MCP 暴露的工具剥离出来，把它们变成命令。

例如：与其一直加载 GitHub MCP，不如创建一个包装 gh pr create 的 /gh-pr 命令，加上你偏好的选项。与其让 Supabase MCP 消耗上下文，不如创建直接使用 Supabase CLI 的技能。功能相同，便利性类似，但你的上下文窗口被释放用于实际工作。

自从我发布原文以来的过去几天，Boris 和 Claude Code 团队在记忆管理和优化方面取得了很多进展，主要是 MCP 的延迟加载，这样它们不再从一开始就消耗你的窗口。之前我会建议尽可能将 MCP 转换为技能，通过以下两种方式卸载执行 MCP 的功能：在当时启用它（不太理想，因为需要离开并恢复会话）或拥有使用 MCP 的 CLI 类似物的技能（如果存在）并让技能成为它的包装器——本质上是让它充当伪 MCP。

有了延迟加载，上下文窗口问题基本解决了。但 token 使用和成本并没有以同样的方式解决。CLI + 技能方法仍然是一种 token 优化方法，效果可能与使用 MCP 相当或接近。此外，你可以通过 CLI 而不是在上下文中运行 MCP 操作，这显著减少了 token 使用，特别适用于重型 MCP 操作如数据库查询或部署。

参考资源 ​

• Anthropic：《Demystifying evals for AI agents》（2026 年 1 月）
• Anthropic：《Claude Code Best Practices》（2025 年 4 月）
• Fireworks AI：《Eval Driven Development with Claude Code》（2025 年 8 月）
• YK：《32 Claude Code Tips》（2025 年 12 月）
• Addy Osmani：《My LLM coding workflow going into 2026》
• 子代理上下文协商模式
• 代理抽象层级
• 复合效应哲学
• RLanceMartin：Session Reflection Pattern
• 自我改进记忆系统

转载声明：本文翻译转载自 Affaan Mustafa（@affaanmustafa）的推文《The Shorthand Guide to Everything Claude Code》。

原文链接：https://x.com/affaanmustafa/status/2012378465664745795

Claude Code 速查指南 ​

这是我经过 10 个月日常使用后的完整配置：技能（Skills）、钩子（Hooks）、子代理（Subagents）、MCP、插件（Plugins），以及真正有效的工作流。

我从 2025 年 2 月实验性推出时就开始使用 Claude Code。从那时起，我用它构建了自主交易代理（其中一个达到了 3800 万美元 FDV，7 万并发观众看我直播编码）、为 elizaOS（17000+ Star 框架）做出了贡献，并在 2025 年 9 月赢得了 Anthropic × Forum Ventures 在纽约举办的黑客马拉松。

以下是我真正在用的配置。

技能与命令（Skills & Commands） ​

技能是 Markdown 文件，为 Claude 提供特定工作流的专业知识。可以理解为可复用的提示词。

• 全局技能存放在 ~/.claude/skills/
• 项目级技能存放在 .claude/skills/
• 可以在单次提示中链式调用

# 技能目录结构示例
~/.claude/skills/
  coding-standards.md    # 编码最佳实践
  tdd-workflow/          # 多文件技能，包含 README.md
  security-review/       # 基于检查清单的技能

实际用法：长时间编码会话后，运行 /refactor-clean 自动清理死代码和松散的 Markdown 文件。

钩子（Hooks） ​

钩子是基于事件触发的自动化。技能提供知识，钩子执行动作。

共有 6 种钩子类型：

1. PreToolUse — 工具执行前（验证、提醒）
2. PostToolUse — 工具执行后（格式化、类型检查）
3. UserPromptSubmit — 发送消息时触发
4. Stop — Claude 完成响应时触发
5. PreCompact — 上下文压缩前
6. Notification — 处理权限请求

实际示例：一个钩子提醒你在运行 npm install 或 pytest 等长命令前使用 tmux。

{
  "PreToolUse": [
    {
      "matcher": "tool == \"Bash\" && tool_input.command matches \"(npm|pnpm|yarn|cargo|pytest)\"",
      "hooks": [
        {
          "type": "command",
          "command": "if [ -z \"$TMUX\" ]; then echo '[Hook] 建议使用 tmux 保持会话持久' >&2; fi"
        }
      ]
    }
  ]
}

进阶技巧：使用 hookify 插件通过对话方式创建钩子，无需手动编写 JSON。

子代理（Subagents） ​

子代理是你的主 Claude 实例可以委派任务的独立进程。它们运行在有限的作用域内，拥有独立的上下文，让主代理专注于编排。

# 子代理目录结构
~/.claude/agents/
  planner.md           # 功能实现规划
  architect.md         # 系统设计决策
  tdd-guide.md         # 测试驱动开发
  code-reviewer.md     # 代码质量/安全审查
  security-reviewer.md # 漏洞分析
  build-error-resolver.md
  e2e-runner.md
  refactor-cleaner.md

关键原则：限制子代理的工具权限。一个拥有 5 个工具的子代理比一个拥有 50 个工具的更快、更聚焦。

规则与记忆（Rules & Memory） ​

规则是你的护栏。用 .rules 文件夹中的 Markdown 文件定义 Claude 应始终遵循的最佳实践。

~/.claude/rules/
  security.md      # 禁止硬编码密钥，验证输入
  coding-style.md  # 不可变性，文件组织
  testing.md       # TDD 工作流，80% 覆盖率
  git-workflow.md  # 提交格式，PR 流程
  agents.md        # 何时委派给子代理
  performance.md   # 模型选择，上下文管理

记忆系统通过 CLAUDE.md 文件在三个层级工作：

• 项目级：./CLAUDE.md（与团队共享）
• 用户级：~/.claude/CLAUDE.md（个人，适用于所有项目）
• 项目级用户：.claude/CLAUDE.md

MCP（模型上下文协议） ​

MCP 将 Claude 连接到外部服务。不是 API 的替代品，而是一个更灵活的提示词驱动封装。

最重要的洞察：

你 200k 的上下文窗口在压缩前可能只有 70k —— 如果启用了太多工具的话。性能会显著下降。

经验法则：配置 20-30 个 MCP，但任何时刻保持启用不超过 10 个。活跃工具数不超过 80 个。

{
  "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] },
  "firecrawl": { "command": "npx", "args": ["-y", "firecrawl-mcp"] },
  "memory": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-memory"] },
  "sequential-thinking": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
  }
}

插件（Plugins） ​

插件将工具打包以便安装。一个插件可以是技能 + MCP 的组合，也可以是钩子和工具的捆绑。

# 添加插件市场
claude plugin marketplace add https://github.com/mixedbread-ai/mgrep

# 然后在 Claude 中运行 /plugins，找到新的市场并安装

LSP 插件特别有用 —— 如果你不在编辑器中运行 Claude Code，Language Server Protocol 可以提供实时的类型检查、跳转到定义和智能补全。

键盘快捷键 ​

并行工作流 ​

两种方法同时运行多个 Claude 实例：

1. /fork — 分叉对话，并行执行不重叠的任务

2. Git Worktrees — 用于重叠的并行工作，每个 worktree 是独立的检出

git worktree add ../feature-branch feature-branch
# 现在在每个 worktree 中运行独立的 Claude 实例

tmux 用于长运行命令 ​

tmux new -s dev
# Claude 在这里运行命令，你可以分离和重新连接
tmux attach -t dev

其他实用命令 ​

• /rewind — 回到之前的状态
• /statusline — 自定义显示分支、上下文百分比、待办事项
• /checkpoints — 文件级撤销点
• /compact — 手动触发上下文压缩

我的实际配置 ​

插件（通常同时启用 4-5 个） ​

ralph-wiggum@claude-code-plugins       # 循环自动化
frontend-design@claude-code-plugins    # UI/UX 模式
commit-commands@claude-code-plugins    # Git 工作流
security-guidance@claude-code-plugins  # 安全检查
code-review@claude-code-plugins        # 代码审查
context7@claude-plugins-official       # 实时文档
mgrep@Mixedbread-Grep                  # 更好的搜索

关键钩子配置 ​

{
  "PreToolUse": [
    { "matcher": "npm|pnpm|yarn|cargo|pytest", "hooks": ["tmux 提醒"] },
    { "matcher": "Write && .md file", "hooks": ["除非是 README/CLAUDE 否则阻止"] },
    { "matcher": "git push", "hooks": ["打开编辑器审查"] }
  ],
  "PostToolUse": [
    { "matcher": "Edit && .ts/.tsx/.js/.jsx", "hooks": ["prettier --write"] },
    { "matcher": "Edit && .ts/.tsx", "hooks": ["tsc --noEmit"] },
    { "matcher": "Edit", "hooks": ["grep console.log 警告"] }
  ],
  "Stop": [
    { "matcher": "*", "hooks": ["检查修改文件中的 console.log"] }
  ]
}

关于编辑器 ​

我使用 Zed —— 一个基于 Rust 的轻量级编辑器。

工作流：

1. 分屏：一边终端运行 Claude Code，另一边编辑器
2. Ctrl+G 快速打开 Claude 正在编辑的文件
3. 启用自动保存，确保 Claude 读取的文件始终是最新的
4. 使用编辑器的 Git 功能在提交前审查变更

VSCode 和 Cursor 也可以正常工作。

核心原则 ​

1. 不要过度复杂化 — 把配置当作微调，不是架构设计
2. 上下文窗口很宝贵 — 禁用未使用的 MCP 和插件
3. 并行执行 — 分叉对话，使用 Git Worktrees
4. 自动化重复任务 — 用钩子处理格式化、Lint、提醒
5. 限定子代理的作用域 — 有限的工具 = 聚焦的执行

相关资源：

• 速查指南原文：x.com/affaanmustafa/status/2012378465664745795
• 长篇指南原文：x.com/affaanmustafa/article/2014040193557471352
• GitHub 仓库：github.com/affaan-m/everything-claude-code

为什么不是 NotionNext ​

NotionNext 更像内容同步方案，不像源码优先方案。

为什么是 VitePress ​

因为它对 Markdown 和 Git 工作流更友好，也更容易让 AI 直接修改文件。

Tailwind 在这里的作用 ​

它不负责"提供现成博客系统"，它负责让页面更容易做出你想要的视觉风格。

过去一段时间，我一直在用 NotionNext 写博客。 它并不是不能用，但越往后用，越能感觉到一个问题：

它更像"内容同步方案"，而不是"源码优先的博客方案"。

尤其是现在已经进入 AI 编码时代，像 Codex 这样的工具真正发挥价值的前提，不是内容放在哪里都行，而是：

• 内容最好是纯文本
• 结构最好稳定
• AI 能直接批量改
• 发布链路尽量短
• 工程化能力要足够强

从这个角度看，NotionNext 并不算最合适的选择。 所以我最后把博客方案切换成了：

Obsidian 写作 + Codex 辅助 + VitePress 构建 + 阿里云 ESA 部署

这套组合用下来，最大的感受就是：AI 终于能真正参与博客生产，而不是只能帮我写一段文案。

为什么我觉得 NotionNext 不够顺手 ​

NotionNext 的优点很明显：

• 上手快
• Notion 写作体验还不错
• 对非技术用户友好
• 主题和现成方案很多

但它的问题也很明显。

1. 内容不是"真正的源码资产" ​

虽然最终博客会生成静态页面，但平时写作的内容核心还是在 Notion 里。 这意味着：

• 内容结构依赖 Notion block
• 迁移成本不算低
• AI 很难精确修改
• 批量处理文章不方便

对于普通写作者，这可能不是大问题。 但对于开发者来说，这会越来越别扭。

因为开发者真正想要的是：

文章就是 Markdown 文件，文件就是资产，Git 就是版本历史。

2. AI 不适合改 block 型内容 ​

现在很多人都在说 AI 写作很强，但这句话有个前提：

AI 最擅长处理的是"结构清晰、纯文本、规则明确"的内容。

Markdown 就非常符合这个特点。

Notion 的 block 结构更适合"编辑器体验"，但不适合 AI 精细化地做这些事：

• 批量补 frontmatter
• 统一 tags
• 统一标题层级
• 修复图片路径
• 自动生成归档页
• 自动生成 RSS
• 自动做 SEO 优化

这些操作一旦换成 Markdown 文件，Codex 的发挥空间会大很多。

3. 发布链路长，调试不够直接 ​

NotionNext 的工作流通常会变成这样：

Notion
→ API 拉取内容
→ 转换
→ 构建
→ 发布

这个链路不是不能接受，但一旦哪一步有问题，排查起来就不够"源码直觉"。

而我更喜欢的是：

Markdown
→ Git
→ 构建
→ 发布

简单、明确、可控。

我最后选择的博客方案 ​

最后我定下来的方案是：

Obsidian（写作）
+ Codex（生成、优化、批量处理）
+ VitePress（站点构建）
+ TailwindCSS（界面样式）
+ 阿里云 ESA（部署）

这套方案不是为了"追新"，而是因为它刚好解决了我最在意的几个问题：

• 写作要舒服
• AI 要能参与
• 页面要能改
• 部署要简单
• 后期要能持续扩展

为什么是 Obsidian，而不是继续用 Notion ​

我现在更愿意把 Obsidian 理解成：

本地 Markdown 写作 IDE

它最适合的地方，不是"知识管理有多强"，而是它天然兼容 Git 和文本工作流。

对我来说，Obsidian 有几个好处 ​

1. 写的就是 Markdown 源文件 ​

这一点特别重要。

文章不是"同步出来的结果"，而是从一开始就是博客源码的一部分。

2. 本地写作速度快 ​

没有网络依赖，没有 block 层层嵌套，也没有复杂的内容同步。

3. 和 AI 配合更自然 ​

我可以直接让 Codex：

• 帮我扩写大纲
• 帮我补 frontmatter
• 帮我统一格式
• 批量扫描 docs/posts/*.md
• 自动生成标签页、分类页、RSS

这一套放在 Notion 里会非常拧巴，放在 Obsidian + Markdown 里就非常顺。

为什么是 VitePress，而不是其他博客框架 ​

我不是没看过别的方案，比如 Astro、Rspress、Docusaurus。 但最后还是选了 VitePress，原因很简单：

它是我现阶段最稳、最轻、最适合 AI 改造的方案。

VitePress 最适合我的几个点 ​

1. Markdown 驱动，非常适合博客 ​

文章天然就是 Markdown，不需要额外心智负担。

2. 上手快 ​

你不需要一上来就进入完整前端框架开发状态。 配置和目录结构都比较轻。

3. 支持 Vue 组件嵌入 Markdown ​

这点很关键。 它意味着首页、文章列表、标签页这些地方，我可以：

• 继续写 Markdown
• 但在需要的时候插入 Vue 组件

这让博客不会"死板"，又不至于太重。

4. AI 很容易理解和修改 ​

VitePress 的项目结构通常很清晰：

docs/
  .vitepress/
  posts/
  index.md
  about.md

Codex 非常容易理解这种目录结构，也很适合做批量修改。

为什么还要加 TailwindCSS ​

VitePress 默认主题是够用的，但如果你想把博客做得更像"自己的站"，就需要做一层样式增强。

我最后没有选 Element 这种组件库，而是用 TailwindCSS，原因也很明确：

博客站的核心需求是"样式定制"，不是"重型业务组件"。

博客真正需要的是：

• 卡片列表
• Hero 区
• 标签样式
• 分类区块
• 深色模式兼容
• 内容页细节优化

这些事情，TailwindCSS 比组件库更灵活，也更适合 AI 生成和修改。

对 Codex 来说，下面这种代码是很好处理的：

<div class="rounded-2xl border bg-white p-5 shadow-sm dark:bg-slate-900">
  ...
</div>

它比"套一层组件库 API 再二次改样式"更直接。

这套方案里，Codex 到底解决了什么问题 ​

很多人说 AI 可以写博客，但我现在更在意的是：

AI 能不能参与整个博客工程，而不是只写段正文。

在这套方案里，Codex 最有价值的地方，不是"帮我凭空写一篇文章"，而是能真正承担这些工作：

1. 生成文章初稿 ​

我给一个主题和结构，它可以先出完整 Markdown。

2. 批量补 frontmatter ​

比如统一补：

• title
• description
• tags
• category
• draft

3. 改博客模板 ​

比如直接让它：

• 增加标签页
• 增加分类页
• 增加 RSS
• 增加评论系统
• 增加搜索
• 优化首页布局

4. 批量整理历史文章 ​

像这些机械活，AI 非常适合：

• 统一标题层级
• 检查文章摘要
• 修复路径
• 过滤草稿
• 归类标签

所以我越来越觉得，AI 对博客最大的价值，不是"代写"，而是：

把博客从"手工维护"变成"可工程化维护"。

我现在的博客项目长什么样 ​

我现在更倾向于这样的结构：

blog/
├─ docs/
│  ├─ .vitepress/
│  │  ├─ config.mts
│  │  ├─ data/
│  │  │  ├─ posts.data.ts
│  │  │  ├─ tags.data.ts
│  │  │  └─ categories.data.ts
│  │  └─ theme/
│  │     ├─ index.ts
│  │     ├─ style.css
│  │     └─ components/
│  ├─ index.md
│  ├─ about.md
│  ├─ posts/
│  ├─ tags/
│  └─ categories/
├─ scripts/
│  └─ gen-rss.mjs
├─ package.json
└─ esa.jsonc

这个结构最大的好处就是：

• 文章层很清晰
• 主题层很清晰
• 数据层很清晰
• 构建脚本很清晰

不管是我自己维护，还是让 Codex 介入，都不容易乱。

为什么部署选阿里云 ESA ​

部署这一层，我最后更倾向于选边缘静态托管，而不是继续折腾一堆中间环节。

VitePress 的产物本质上就是静态文件：

docs/.vitepress/dist

这意味着它非常适合直接部署到边缘 Pages 平台。

我现在更喜欢的链路是：

Git Push
→ ESA 自动构建
→ 边缘节点发布
→ 域名访问

这样做的好处是：

• 不需要单独维护服务器
• 不需要自己手工上传静态文件
• 发布流程短
• 静态站点和 CDN 模式天然契合

这和我想要的博客形态是匹配的：

博客应该轻、快、稳定，而不是再养一个服务端系统。

这套方案的真正优势，不是"新"，而是"顺" ​

回头看这次切换，我觉得最大的收获不是换了工具，而是整个博客链路终于顺了。

以前更像是：

• 我在内容平台里写
• 再想办法同步成博客
• AI 只能帮一点点局部内容

现在变成了：

• 我在 Obsidian 里直接写 Markdown
• Codex 可以直接读写文章和站点代码
• VitePress 直接构建
• ESA 直接发布

整条链路都更贴近"开发者工作流"。

这时候 AI 才不再是一个"会聊天的辅助工具"，而是真的成了项目协作者。

适合谁用这套方案 ​

如果你符合下面这些情况，这套方案大概率会比 NotionNext 更适合你：

• 你本身就是开发者
• 你愿意把博客当成代码仓库维护
• 你希望 AI 能参与批量处理和工程化工作
• 你想要更高的页面可控性
• 你不想让内容绑定在某个平台结构里

反过来说，如果你更看重的是：

• 零门槛
• 完全不碰代码
• 团队协作式文档编辑
• 所见即所得编辑体验

那 Notion 系方案依然有它的合理性。

所以这不是谁一定更高级，而是：

你到底是把博客当"内容平台"，还是当"可维护的项目"。

我接下来会继续补的东西 ​

目前这套方案已经能满足日常写作和发布，但还有几个方向很值得继续补：

1. Pagefind 搜索 ​

让博客具备静态全文搜索能力。

2. sitemap 和 SEO 细节 ​

方便搜索引擎收录和社交平台展示。

3. OG 图自动生成 ​

让每篇文章都能有更统一的分享封面。

4. Obsidian 模板 + Codex Prompt 模板 ​

把"写一篇博客"进一步流程化。

这些东西一旦继续补齐，这套博客就不只是"能用"，而是真正能长期维护。

最后的结论 ​

我不是单纯因为 NotionNext 不好，才转向这套方案。

更准确地说，是因为当我开始真正把 AI 纳入日常写作和站点维护之后，我发现：

Markdown、Git、静态站点、可脚本化，这些东西的重要性一下子被放大了。

所以最后我选择了：

• Obsidian 负责写作
• Codex 负责生成、整理、改造
• VitePress 负责构建
• TailwindCSS 负责样式
• ESA 负责部署

这套方案未必适合所有人，但对一个希望把博客做成"长期项目"的开发者来说，它确实比 NotionNext 更舒服，也更适合 AI 时代。

如果你也正在折腾博客，而且已经开始用 Codex、Claude Code 这类工具，那我很建议你试一次：

把博客彻底 Markdown 化、Git 化、工程化。

你会发现，整个写作和发布过程都会轻很多。

最近配了IPV6，发现中兴5228F上的设备无法获取IPV6地址，网上搜刮了两条指令，解决IPV6无法使用问题。

ZXR10(config)#ipv6 nd-snooping link-local enable

ZXR10(config)#ipv6 nd-snooping global enable

配置完记得输入 write 保存

参考 ​

设备的用户手册。根据设备背面的说明，上 ZTE 的 support 网站，用提供的用户名密码登录，然后下载对应的用户手册/说明书。.zed 格式的，需要额外再下载中兴e读来进行阅读。（其实 .zed 解压缩出来就是 HTML 文档，应急时可以解压后打开阅读。小技巧，从内部人士获知）

• ZXR10 5200F系列（V3.05.10）全千兆智能交换机用户手册文档包：https://support.zte.com.cn/support/docCenter/ItemdocumentList.aspx?sid=179665&id=30648281
• 中兴e读下载：https://support.zte.com.cn/support/DownloadZTEeReader.aspx

网站的登录用户名密码贴在交换机的背面（switchzte / Switch_99895960）

PlayCover ​

PlayCover的Github页面地址：https://github.com/PlayCover/PlayCover

百度网盘下载地址：

通过网盘分享的文件：金铲铲之战 链接: https://pan.baidu.com/s/1HXbFBnVDLBUdMwg1MViy8w?pwd=tdkv 提取码: tdkv

金铲铲之战 ​

金铲铲之战IPA文件下载地址：https://decrypt.day/app/id1478101301

百度网盘下载地址（2025年06月19日更新）：

通过网盘分享的文件：com.tencent.jkchess_1.10.26_1108_und3fined.ipa 链接: https://pan.baidu.com/s/15l9uzYFsUUUsgigxWMMzcA?pwd=61iv 提取码: 61iv