Claude Code 教学 Wiki

摘要

tw93 面向非技术人员（产品、业务、运营）的 Claude Code 完整上手指南。从命令行克服、账号订阅、CLAUDE.md 编写、需求描述技巧到 Skill 沉淀，覆盖零基础到进阶的完整路径。核心观点：模型准不准比快不快重要，需求写得细比会写代码重要。

核心内容

上手路径

• 第一道坎是命令行，推荐 Kaku 终端（作者自制，专为 AI Coding 设计）
• 非常建议补技术知识：框架概念、终端/Git/Chrome DevTools、编程核心思想、读代码和报错
• 推荐三本书：《启示录》《Linux/Unix 设计思想》《左耳听风》

账号与订阅

• 走美区 App Store 内购最稳，先 Pro 后 Max
• 防封号：稳定网络、一号一人、实体卡付款、老 Gmail 邮箱

适合交给 Claude Code 的活

• 目标清楚、结果好验收的任务
• 做原型/内部小工具、处理 CSV/销售报表、文档提炼、信息提炼
• Software for One 概念：做只给自己一个人用的软件

CLAUDE.md 编写要点

• 150 行以内，命令式语气，每条可判断
• 四条最值钱规则：先问清楚再动手、简单优先、只动该动的、做完要验证
• "压缩时保留"段落防止长会话前后矛盾

需求描述技巧

• 模糊版 vs 精确版的差异：精确版当天能用，模糊版多半返工
• 每条细节都是在防 AI 猜错
• 业务需求先写问题再列功能，划范围，给异常处理，验收标准给数字

进阶用法

• Plan 模式（Shift+Tab）：复杂任务先对答案
• Auto 模式：安全操作直接跑，风险操作才问
• alias 配置：c='CLAUDE_CODE_AUTO_COMPACT_WINDOW=400000 claude --dangerously-skip-permissions'
• opusplan 模型：Opus 规划 + Sonnet 执行
• showClearContextOnPlanAccept 设为 true 避免缓存未命中

Waza Skill 套件（8个）

• /think /design /hunt /check /read /write /learn /health
• Skill 三种类型：工作流型、检查清单型、领域专家型
• description 写触发条件不写功能介绍，一个 Skill 只做一件事

安全要点

• 让它先解释再动手、看不懂的命令先问
• 生产环境不要练手、密钥别粘到对话里
• 能用现成服务（Clerk/Stripe）别让它从零写

摘要

Khairallah 给非工程师/初学者的 Claude Code 30 天精通路径。核心判断：会用与不会用的差距每周扩大。30 天分四周——周 1 装环境破除终端恐惧 + 写 CLAUDE.md + 区分 Plan/Act 模式；周 2 选真实问题做第一个 MVP + 调试 + 掌握 slash 命令；周 3 多文件重构 + MCP 接入 + 多步 workflow；周 4 部署 + 第二个项目（48h 内交付）+ 公开建造。

核心内容

Week 1: 安装 + 破除终端恐惧

• Day 1-2：装、跑首个 prompt、学三个最常用命令 /init /compact /cost
• Day 3-5：CLAUDE.md 是最重要的文件——把它当 onboarding doc 写。无 CLAUDE.md = 通用 agent；有 = 已熟悉项目的工程师。一周内迭代 3 次
• Day 6-7：Plan 模式 vs Act 模式。复杂任务先 Plan，简单任务直 Act。任何动 2 文件以上的任务先看 plan

Week 2: 第一个 MVP

• Day 8-10：选你自己每周烦恼的真实问题（不要再做 todo app/计算器）。一段话 brief → Claude 起项目计划 → 三天出能跑的丑版本，ship 丑且能跑 > 美但不存在
• Day 11-12：调试技术——别说 "it's broken"，要说 "这个函数传空数组时抛 type error，期望返空结果"
• Day 13-14：Slash 命令——/init /compact /cost /review /memory。每个跑一遍

Week 3: 高级 workflow

• Day 15-17：多文件重构——重命名一个函数让 Claude 找所有引用 + 更新 import + 修测试。"一个 prompt 触发跨 5+ 文件改动"是分水岭
• Day 18-19：MCP 服务器——Context7（最新文档）+ Tavily（web 搜索）。理解 project-level vs user-level 配置
• Day 20-21：多步 Workflow——研究主题 → 总结 → 立项 → 起项目 → 跑测试。把成功的 workflow 存成 custom slash 命令

Week 4: 部署 + 公开建造

• Day 22-24：部署 MVP（Vercel/Railway/Fly.io/VPS），让 Claude 配 CI/CD，分享给 3 人收反馈
• Day 25-27：第二个项目，目标 idea→deployed 在 48h 内。复利开始
• Day 28-30：写 detailed thread/article 拆解项目，分享 CLAUDE.md 模板，开始接 freelance

核心心智模型

• Claude Code 不是聊天窗，不是漂亮终端，是完全自主的编码 agent
• 你是 PM，Claude 是工程师，你的工作是方向不是语法
• AI 不奖励"等到准备好"的人，奖励 ship 的人

摘要

zodchii 提供 Claude Code 新项目 5 分钟完成配置的起步包：4 个配置文件 + 9 个 slash 命令。每个新项目原本要花 2-3 小时配（CLAUDE.md/settings.json/skills/deny rules），这套模板 drop in 即用。第一次会话起 Claude 已知项目栈、有合理权限、9 个常用命令就绪。

核心内容

目录结构

your-project/
├── CLAUDE.md
├── .gitignore
├── .claude/
│   ├── settings.json
│   ├── settings.local.json   # gitignored 个人 override
│   └── skills/
│       ├── review/SKILL.md
│       ├── test/SKILL.md
│       ├── commit/SKILL.md
│       ├── pr/SKILL.md
│       ├── debug/SKILL.md
│       ├── refactor/SKILL.md
│       ├── docs/SKILL.md
│       ├── deploy-check/SKILL.md
│       └── security/SKILL.md

File 1: CLAUDE.md（< 60 行）

固定结构：Project / Stack / Commands / Architecture / Rules / Workflow / Out of scope。 关键规则示例： - NEVER commit .env or secrets - 所有 DB 查询走 services 层不写 components - 所有 async 必须 try/catch - Commit 前缀 feat: fix: docs: refactor: test: chore: - IMPORTANT: 每次代码改动后跑 type check - Out of scope: migrations/ 由 ORM CLI 管，public/assets/ 静态文件，.github/workflows/ 不未问勿动

File 2: settings.json

Allow 名单：Read/Glob/Grep/LS/Edit/MultiEdit、Write(src/)/Write(tests/)、Bash(pnpm )/Bash(npx tsc )/Bash(git status/diff/log/add/commit/checkout/branch) 等。 Deny 名单（关键防护）：

Read(**/.env*) Read(**/*.pem) Read(**/*.key) Read(**/secrets/**)
Read(**/.aws/**) Read(**/.ssh/**) Read(**/.npmrc)
Write(**/.env*) Write(.github/workflows/*) Write(package-lock.json)
Bash(rm -rf *) Bash(sudo *) Bash(git push *) Bash(git merge *)
Bash(git rebase *) Bash(npm publish *) Bash(docker *)
Bash(curl * | sh) Bash(wget *) Bash(chmod *)

Hooks：Write(.ts)/Write(.tsx) PostToolUse 自动跑 prettier --write。

File 3: .gitignore

覆盖：node_modules、build artifacts、.env、AI 工具缓存（.claude/settings.local.json/.cursor/.aider/.continue/.cody）、密钥（.pem/.key/.aws/.ssh/.docker/config.json）、IDE、OS、logs、terraform。

关键：.claude/settings.local.json gitignored，但 settings.json 和 .claude/skills/ 提交（团队共享）。

File 4: 9 个 Skill（示例 3 个）

• /review：分类输出 CRITICAL/WARNING/INFO，结尾汇总 X critical Y warnings Z info
• /commit：git status + git diff → 分组 → 每组一个 commit type(scope): description + 体内 What/Why
• /deploy-check：tsc → npm test → lint → build → grep console.log → check .env refs → git status，输出 ✅/❌ 每项

安装三种方式

• 新项目：mkdir + git init + 粘贴模板
• 已有项目：CLAUDE.md 加根、合并 settings.json、补 .gitignore、复制 skills
• 全局：~/.claude/settings.json + ~/.claude/skills/，CLAUDE.md 仍 per-project

套件复利定律

1. CLAUDE.md：每次 Claude 犯错就加一条规则。"Update CLAUDE.md so this doesn't happen again" 是最强 prompt
2. settings.json：调整 Write scope 和 Bash 规则
3. Skills：让 /review 检查代码库专属模式
4. .gitignore：新工具/凭据时补条目

到第三个月，CLAUDE.md 已捕获 Claude 在该项目所有犯过的错并自动预防。

摘要

面向零基础用户的 Claude Code 安装和使用教程：从 Node.js 安装到 VS Code 集成，含国产模型低成本替代方案。作者 @XiaohuiAI666，发布于 2026-04-15。

核心内容

安装步骤

1. Node.js：Claude Code 用 JavaScript 编写，需 Node.js 运行环境
2. Git For Windows（仅 Windows）：Git Bash 模拟 Linux 环境补齐命令
3. 安装 Claude Code：npm install -g @anthropic-ai/claude-code
4. 跳过 OAuth 验证：在 .claude.json 添加 "hasCompletedOnboarding": true
5. 启动：终端输入 Claude

低成本替代方案

使用 CC Switch（开源桌面代理路由器）拦截网络请求，一键切换到 DeepSeek 等国产模型 API。成本远低于 Anthropic 开发者账号。

IDE 集成

VS Code 安装 Claude Code 插件，界面右上角出现 logo 即可对话。支持在 IDE 内直接生成项目代码。

摘要

文章讨论团队内共享 AI skill 库时的核心矛盾：skill 必须保留个人视角才有价值，但一旦团队共享就会出现定义冲突。作者反对追求唯一权威版本，转而提出“共享池 + 个人 INDEX + baseline + heartbeat + review”的机制，让共识在实际使用中自然浮现。关键点不是消灭分歧，而是让 AI 帮团队识别重合、追踪变化、沉淀事实上的 baseline。这个框架本质上是把个人 context infrastructure 扩展为团队级上下文基础设施。

核心内容

问题定义

团队人数变多后，内部知识库和 skill 库会同时面临两个问题：同一概念出现多套说法，以及维护成本持续高于使用收益。个人 skill 的价值来自个性化判断，但团队共享后，不同人的定义冲突会直接影响 Agent 行为。

两种直觉解法及其失败原因

作者认为常见解法有两类： - 建立一套基础公共 skill 库，其余部分各自维护 - 设专人审核合并，维护权威版本

这两种方案都默认“团队知识最终应收敛为单一版本”。前者放弃真正沉淀，后者维护成本高到不可持续。

新方案：让共识自己浮现

作者提出四个核心部件： - 共享池：所有人把 skill 放在同一仓库，允许重复和冲突 - 个人 INDEX：每个人只加载自己认可的 skill 集合，保证 Agent 行为可控 - baseline INDEX：给新人一个默认起点，但不强制统一 - heartbeat + review：AI 定期扫描重合项、提示作者互相参考，并跟踪跨人引用的变更风险

这个方案把“存”和“用”分开：共享池负责积累原材料，INDEX 决定每个人实际使用什么。

AI 在团队知识演化中的角色

AI 不是仲裁者，而是扫描器和提醒器。它负责： - 检测不同 skill 之间的高重合度 - 提示作者查看彼此版本 - 识别跨人引用的高风险变更 - 为 baseline INDEX 的演化提供事实依据

也就是说，AI 只负责发现模式和提示风险，不负责强制收敛。

对 skill 复用的重新定义

文章明确指出 skill 不是代码。代码世界追求 DRY 是为了维护一致性；skill 世界更重要的是保留多种视角，提供启发性。重复在这里不是技术债，而是团队认知分布的信号。

组织层含义

作者进一步提出“Context Infra” 可能成为类似 Platform Engineering 的新岗位：由少量人定义 heartbeat 节奏、风险判断标准和 baseline 演化方向，而大部分扫描、比对、通知工作交给 AI 自动完成。

摘要

@vincemask 总结 Claude Code 实战中关于 CLAUDE.md 的 8 条经验。核心反直觉点：CLAUDE.md 不是项目说明书，而是 router + 强制执行接口。200 行硬上限；"不要引入什么"与"要引入什么"同样重要；规则必须可被 5 秒判断符合；Hook 是规则的强制层；敏感模块给本地 CLAUDE.md。

核心内容

1. 越短越好，200 行硬上限

Boris Cherny（claude-code-best-practice 作者）的建议。每次会话都加载 CLAUDE.md，多写一行就挤占理解代码的空间。 验证标准：陌生人读完能在 30 秒内回答——这是什么产品？技术栈是什么？新代码放哪里？

2. "Do NOT introduce" 与 Tech Stack 同等重要

Claude 知识截止到训练日，不知道你的历史包袱。没有禁止清单时它会"出于善意"引入它"知道"的最优方案。

Do NOT introduce unless explicitly requested:
- Redux（项目已迁移到 React Context + Zustand）
- styled-components（全站 Tailwind，不接 CSS-in-JS）
- MongoDB（数据层已锁定 PostgreSQL）

节省的不是一次纠正，而是防止 10 次会话都在修兼容性。

3. 规则必须可操作，不是可感受

"写干净的代码"对 AI 等于没说。"用 named export 而不是 default export""组件不超过 200 行""async/await 不用 then 链"才算合格。 测试：5 秒内能判断代码是否符合 → 合格。

4. CLAUDE.md 是指针，不是图书馆

普通用户的 CLAUDE.md 是知识梳理；顶级用户的 CLAUDE.md 是 router。 进阶：渐进式上下文（Progressive Disclosure） - Tier 1（每次加载）：CLAUDE.md - Tier 2（按需加载）：docs/architecture.md, docs/api.md - Tier 3（忽略）：docs/archive/

5. 敏感模块开本地 CLAUDE.md

在 src/auth/、src/payments/、infra/ 各放一个本地 CLAUDE.md，Claude 操作该目录时自动加载。 写法：安全红线 + 已知陷阱（如 "magic link 依赖 crypto.randomUUID()，不要换"）

6. 让 CLAUDE.md 驱动 Hook

"Claude 的记忆不可靠。Hook 可靠。" - PreToolUse hook → prettier 强制格式化 - PostToolUse hook → vitest related 强制跑测试 - 禁止编辑特定目录而不先确认

写在 CLAUDE.md 里的规则是"请记住"；配了 Hook 的规则是"你必须"。

7. 用 MEMORY.md 建立长期记忆回路

不用复杂向量数据库，CLAUDE.md 加一条：

每次新任务开始前先读 MEMORY.md。每次任务结束后，如果有新发现就追加。

简单、可控、可 Git 追踪。成本一个文件，收益保留最有价值的 5%。

8. 用 CLAUDE.md 承载工作风格

让 Claude 第一次对话就知道你讨厌什么：

## My Working Style
- 先给方案，不要直接写代码
- 不确定时列出选项，不要猜测
- 重大变更前先问，小优化可以直接执行
- 不要用 "Great question!" 这类废话
- 回复用中文，代码注释用英文
- 文件路径用绝对路径

Today Actions（作者给出的 4 条立即可执行）

1. 删 CLAUDE.md 到 200 行以内
2. 加 "Do NOT introduce" 区块，至少列 3 个禁用库
3. 把每条模糊规则改成具体可验证
4. 给 auth / billing / infra 各加本地 CLAUDE.md

启示与本仓库对照

• 本仓库 CLAUDE.md 当前 ~200 行，已在范围内，但仍是"知识梳理"而非纯 router。可考虑把 [[Obsidian格式规范]]、[[博客发布规范]] 这类完全移到 wiki，CLAUDE.md 只保留链接 + 触发条件
• 已有 [[Slash命令手册]] + 五个 .claude/commands/，相当于 Hook 层；可继续把"每次写完 sources 自动更新 index"这类规则移到 hook
• MEMORY.md 回路在本仓库已存在（.claude/projects/.../memory/MEMORY.md），与作者第 7 条思路完全一致，可视为方法论的多人独立验证
• "Do NOT introduce" 区块本仓库尚无显式版本——技术栈相关禁止项可补一份

摘要

TRAE 技术专家简瑞系统讲解 AI Coding 中 Rules 的多规则管理与精细化生效策略。核心问题：单条 Rule 写太长导致规模失控、场景冲突、时机不可控。解决方案：将规则拆分为可维护模块，配合四种生效方式（始终/指定文件/智能/手动触发），实现规则资产的长期可控。

核心内容

单条 Rule 的三大问题

1. 规模问题：内容越长维护成本越高，团队协作难以分工
2. 冲突问题：不同场景规则揉在一起，AI 抓错重点（如 UI 问题时输出 commit message）
3. 时机问题：无法控制规则何时生效，要么到处乱入要么不敢写

四种生效方式

方式	适用场景	示例
始终生效（Always Apply）	低冲突、强一致、任何任务都不应违背	输出语言、通用代码风格
指定文件生效	与文件类型/目录强相关	**/*.sql 迁移规范、apps/web/** 前端规范
智能生效	偶尔使用但重要，希望相关时自动出现	问题排查 checklist、性能优化
手动触发	高风险/高成本/误触发会严重干扰	发布/回滚 SOP

规则拆分方法论

• L0：协作/输出规范（始终生效）——输出语言、格式、注释
• L1：技术栈/工程规范（指定文件）——React/Vue/Go 约定
• L2：业务/领域规则（指定文件/智能）——订单/支付边界条件
• L3：工作流/SOP（智能/手动）——问题排查、发布清单

单一职责原则

• 一条 Rule 能否用一句话说清它约束什么？不能就继续拆
• 区分规范类（必须遵守）、偏好类（建议）、流程类（按步骤做事），分开管理

规则资产治理

• 加规则前想清楚分类和生效方式
• 持续把任务带偏的规则降级为智能/手动触发或删除
• 配置文件是最高杠杆点：一行糟糕指令影响每个会话

User Rule vs Project Rule

• User Rule：个人偏好（输出语言、解释方式、工作习惯）
• Project Rule：团队/项目一致性
• 支持导入 AGENTS.md / CLAUDE.md 降低迁移成本

摘要

Khairallah 整理的 35 个 Claude Code 高阶技巧，从基础命令到架构审计到调试恢复全覆盖。核心理念：Plan with Opus, Build with Sonnet；增量构建优于一次性大实现；Git checkpoint 是安全网。

核心内容

基础命令 (01-08)

• Plan Mode (Shift+Tab)：先分析后实现，防 bug 第一利器
• /compact：30-45分钟压缩上下文，保持专注
• /clear：每功能一对话，避免上下文污染
• /init：自动生成 CLAUDE.md
• /cost：每小时查 token 用量
• /memory：持久化规则（TypeScript strict mode 等）
• ! 前缀：在 CC 内跑终端命令
• 多模型切换：Opus 规划，Sonnet 执行

生产力技巧 (09-18)

• 参考文件技巧：指出现有文件让 CC 复制模式
• 截图调试：Ctrl+V 粘贴截图
• 测试先行工作流：先写测试再实现
• 增量构建：分步实现每步测试
• Diff Review：检查 CC 是否改了不该改的文件
• Git Checkpoint：每次大改前 git add . && git commit
• 并行会话：后端和前端分开两个 CC 实例

架构技巧 (19-26)

• 架构审计：要求 CC 提两个方案对比
• 依赖检查：加包前让 CC 评估
• 模式执行器：CLAUDE.md 写入代码模式规范
• 重构规划器：只看方案不动手

工作流自动化 (27-31)

• Git Hook 写手 / CI Pipeline / 环境安装脚本 / Release Notes / 数据库 Seed

调试恢复 (32-35)

• 复现提示：bug报告→最小复现→失败测试→修复
• Blame 调查：git log 定位引入问题的 commit
• 恢复模式：从 git 恢复原版，重新开始

摘要

Claude Code Power User 完整课程：CLAUDE.md 是最核心的配置文件，Plan Mode 用于复杂任务，Path-Specific Rules 实现文件级规则，自定义 Slash Commands 自动化重复任务，CI/CD 集成用 -p 标志非交互运行。

核心内容

Level 1: CLAUDE.md 配置（最重要）

• 项目根目录的 CLAUDE.md 告诉 Claude 你的约定、模式、规则
• 三层层级：User级(~/.claude/) → Project级(.claude/) → Directory级
• 常见错误：把团队规则放在 user 级

Level 2: Plan Mode vs 直接执行

• 直接执行：明确有限范围的任务（修 bug、改变量名）
• Plan Mode：涉及 2+ 文件或架构决策的任务
• 规则：先 Plan 再执行，否则花更多时间 undo

Level 3: 核心工具

• Grep 搜内容，Glob 匹配路径（别用错）
• Edit 精确替换，不唯一时 Read + Write
• /memory 查看 Claude 加载的记忆文件

Level 4: Skills vs CLAUDE.md

• CLAUDE.md：每次都加载，放通用标准
• Skills：按需激活，放任务特定流程
• Path-Specific Rules（.claude/rules/）：按 glob 模式匹配文件加载

Level 5: CI/CD 集成

• -p 标志非交互模式运行
• --output-format json + --json-schema 结构化输出
• 关键洞察：生成代码的 Claude 实例不宜审查自己的变更

Level 6: Power User 工作流

• 上午：描述需求 → Plan → 审核 → 执行 → 测试 → 提交
• 下午：自定义 /review 审查 PR
• 晚间：CI 自动运行安全审查、测试生成、文档更新

摘要

基于 Nate Herk 的 32 个 Claude Code 技巧视频，作者提炼出 6 个最关键但被低估的要点背后的原理。核心心智模型：把 Claude Code 当成"有限注意力、有限时间、有性格"的同事来管理，而非无限算力工具。三大管理维度对应：context 管理（/compact/sub agent）、异步化（/loop/agent team）、prompt 沟通（plan mode/junior 同事心态）。

核心内容

6 个被低估的关键点

1. 把 Claude 当 junior 同事是 prompt 工程 - 命令式 prompt 触发浅层 pattern match，描述式 prompt 触发深层 chain of thought - "修一下这里" vs "这里看起来怪怪的，你查查为啥" — 质量差一倍 - 描述要具体且不带预设答案，预设答案越少推理越多

2. 60% 用 /compact 是对抗 lost in the middle - Stanford 2023 论文：LLM 长 context 注意力 U 型曲线，中间最易被忽略 - 60% 不是省钱红线，是注意力开始衰减的经验线 - /compact 保留关键决策和未完成事项，是注意力的重新聚焦

3. 跑偏了 exit 重开是 token 经济学 - 被污染 context 里修正 prompt 自身占 context，道歉占 context，修正输出还被错误推理影响 - 总成本比重开高 2-3 倍 - fail fast 反射：看到走偏立刻 ESC

4. sub agents 真正价值是上下文隔离 - 并行只是表象，隔离才是核心 - 典型 sub agent 任务："需要大量探索但只需要少量结论" - 父 agent 只看最终结论，失败探索不污染主线

5. 简单活给 Haiku 是避免过度设计 - 大模型训练见过太多复杂场景，对简单任务也会加边缘处理 - 1-2 步给 Haiku / 5 步以上给 Sonnet/Opus / 10 步以上才 ultrathink

6. /loop 是 monitoring 不是写代码 - 好的 /loop 任务：输入是状态不是动作、输出是有事/没事的判断 - 从"我得记得去看"变成"Claude 看到再叫我"

32 技巧速览

• 入门: /init, plan mode, /context + /compact, junior 同事心态, self check
• 进阶: sub agents, custom skills, Haiku 省成本, exit 重 prompt, 截图 debug
• 高阶: /loop, Git worktrees, VPS 托管, ultrathink, agent team

摘要

Claude Code 50+ 个 slash 命令的 5 场景实战指南：上下文压缩、模型切换、低成本试错、上下文隔离、工作流融合。核心 9 个命令分三组：省钱（/model, /effort, /compact）、提效（/plan, /branch, /agents）、自动化（/hooks, /loop, /init+/memory）。一个月能省 40% 费用的关键习惯：上下文到 50% 就手动 compact，简单任务切 Sonnet low。

核心内容

场景一：上下文快爆怎么抢救

• 系统在 92% 时自动压缩，但是"无差别删减"
• 正确：/context 看占比 → /compact keep all api decisions and error patterns（带提示词手动压）→ /cost 确认
• 习惯：到 50% 就手动 compact，越早做越便宜，留下的有效信息更多

场景二：一个 session 同时处理不同难度任务

• 切换不丢上下文！
• /model sonnet + /effort low 写 util/改样式
• /model opus + /effort max 架构决策/复杂 bug
• /fast on（Opus 4.6 跑 2.5 倍速）
• 算账：60% 简单任务用 Opus 是浪费 → 这一个习惯月省 40%

场景三：方向不确定怎么低成本试错

• /plan implement caching with Redis vs in-memory LRU —— 只想不做模式，写完整方案不碰文件，错了只浪费几百 token 而非几万
• /branch redis-approach 分叉对话两个方向同时跑互不干扰
• /rewind 跑了一半发现错了直接回到 checkpoint，不用新开 session

场景四：大项目上下文不互相污染

• /agents 把后端/前端/数据库拆 subagent
• 精髓不是并行而是上下文隔离——subagent 在独立空间消耗几万 token，返回只一两句结论
• /add-dir ./frontend 限定只看前端目录
• 习惯：写完一个模块 /review 一次，最后整体 /simplify

场景五：让 Claude 融入日常工作流

日常开发流 - /init 新项目第一件事生成 CLAUDE.md - /memory 随时更新项目约定 - /ide 连 VS Code/Cursor 获取当前打开文件上下文 - /hooks 配自动化（保存自动 lint、提交前自动 review）

PR 工作流 - /pr-comments #42 把 reviewer 评论拉进来直接改 - /summary 生成变更摘要贴 PR description - /diff 最后确认改了什么

团队协作 - /share session 分享给同事 - /rc 同事从手机/网页远程控制 - /export 导出 session 做技术文档/onboarding

核心三组（9 个命令）

类别	命令	价值
省钱	/model /effort /compact	砍掉一半费用
提效	/plan /branch /agents	线性 → 并行工作
自动化	/hooks /loop /init+/memory	被动响应 → 主动协作

摘要

Leo（@defileo）详解 Claude Code Routines 的实战教程。Routines 是 Anthropic 的云上自动化：定义一次任务（prompt + repo + trigger），Claude 在 Anthropic 基础设施上自动运行，电脑关了也在跑。三种触发器：Schedule/API/GitHub事件。

核心内容

三种触发器

• Schedule：定时执行（hourly/daily/weekly/custom cron）
• API：HTTP 端点，POST 即触发，可传上下文
• GitHub：PR opened/commit pushed/issue created 等事件自动触发

五个实战 Routine

1. Morning Backlog Digest：每工作日7am，自动分类+分配新 issue，发 Slack 摘要
2. Auto PR Reviewer：PR opened 时自动审查安全/性能/风格/测试，留 inline comment
3. Alert Triage Bot：监控报警 → API 触发 → 拉代码关联 → 开 draft PR → 通知 Slack
4. Docs Drift Checker：每周一扫描已合并 PR，找过时文档，自动开更新 PR
5. Deploy Verification：部署后 API 触发 smoke test + 日志扫描，发 go/no-go 判定

设置路径

• Web: claude.ai/code/routines → New routine
• CLI: /schedule daily PR review at 9am
• 管理: /schedule list/update/run

限制

• 消耗订阅配额，有每日运行上限
• 默认只能推 claude/* 分支，需开启 unrestricted branch pushes
• Routines per-user，不共享，所有操作以你的 GitHub 身份执行

摘要

这份清单不是在介绍单个命令，而是在展示 Cowork 的真实价值边界：它从聊天助手升级为“文件系统 + 定时任务 + 连接器 + 文档流水线”的自动化操作面。作者列出的 40 个用法可以归成五类：slash 命令、文件系统批处理、跨平台连接器工作流、文档加工流水线，以及定时自动化。

核心内容

价值不在单个命令，在可组合工作流

作者批评多数用户只会说“帮我整理文件”，相当于买了瑞士军刀只用开瓶器。真正的差异化在于把 slash command、schedule、文件操作、外部连接器和模板化提示串成一条完整流水线，让一次描述可以触发多步自动执行。

Slash command 是工作模式切换器

文中列举的高频命令有几类：一类是 /schedule、/plan 这种控制执行方式的命令；一类是 /compact、/clear、/memory、/doctor 这种管理上下文与环境状态的命令；另一类是自定义 /review 这类把重复检查流程固化为可复用接口的命令。核心思想不是“记住命令表”，而是把高频流程变成稳定入口。

文件系统自动化是最直接的提效场景

批量重命名、去重、按项目重组目录、归档旧文件、模板逆向生成、批量格式转换、容量审计，这些都属于低判断高重复工作。文章的启发是：文件系统任务特别适合让 Agent 做，因为文件就是最天然的结构化上下文，且结果可检查、可回滚、可批量化。

连接器工作流把分散信息变成单一交付物

作者给出的 Gmail、Calendar、Slack、Drive 组合案例，本质上都是“从多源拉取信息 → 做结构化判断 → 生成一个可消费产物”。比如从邮件和日历生成会前 briefing，从 Slack 抽 action items，从 Drive 表格生成带图表的汇报。这里的关键不是读数据本身，而是把跨系统检索与整理变成常态化例行操作。

文档流水线体现了 Agent 的内容加工优势

从语音笔记到成稿、从会议录音到结构化纪要、从研究资料到 executive brief、从 proposal 模板到客户定制版本，这类任务都说明 Cowork 的价值在于把杂乱原料转成面向具体受众的交付件。它本质上是“结构化重写与组织”，而不是单纯生成文本。

定时任务让一次性提示变成持续系统

文中最后一组场景是 daily inbox zero、weekly cleanup、Monday planning、monthly expense processing、competitive scan、end-of-day log。作者的核心观点很简单：如果一件事会重复发生，就不该每次重新描述，而应直接 schedule 成例行任务。

最大教训：提示要描述边界与输出，不要只说目标

作者在 tips 里反复强调，含糊的“organize my files”会把成本浪费在澄清往返上；真正高质量的任务描述应该包含作用域、筛选规则、命名规则、排除项和输出位置。也就是说，自动化质量高度依赖任务建模质量。

摘要

eng_khairallah1 完整课程：用 Claude Cowork 把全天工作自动化为三段式系统——晨间简报 (7AM) + 日间生产模块（手动触发）+ 日终收尾 (5PM)。核心论点：大多数人与 AI 的关系是"对话"（提问、答、关、再来）——这不是生产力，是中断管理。10x 杠杆的人不是在对话，而是在运行系统：在你醒前就开始工作，处理琐事让你聚焦高价值任务，在你下班前给完整总结。Cowork 不是工具，是基础设施——build once, refine weekly, let it compound。

核心内容

一、Session 1 — 晨间简报（7 AM）

做什么：你打开笔记本前，Claude 已经 - 扫描邮件并按紧急度分类 - 起草常规邮件回复 - 标出 3 封需要你大脑的邮件 - 拉今日日历，每个会议生成 1 页准备简报 - 检查 Slack 隔夜动态 - 全部编入桌面上的 Morning Briefing 文档

你打开电脑读一份文档，5 分钟知道今天什么样、什么先处理。

怎么搭 - Claude Desktop 配 Gmail / Calendar / Slack 连接器 - 给 Cowork 一个专门文件夹 /Documents/Daily-Briefings - /schedule 工作日 7 AM 任务 - prompt 包含：邮件按 urgency tier 总结 / 日历 + 准备笔记 / Slack 高亮 / 今日 Top3 / 编入 markdown 保存

Tier 定义（每人不同，必须自定义） - T1: 9 AM 前必须回 - T2: 今日内 - T3: 本周内 - T4: 信息性，无需回

越具体越好用。手动跑 3 次再正式 schedule。

二、Session 2 — 日间生产模块（手动触发）

做什么：核心工作引擎。不是做 20 件小事，而是描述要的产出，让 Cowork 执行你的最高级思考之外的所有事。

关键差别 vs Claude chat：Cowork 直接动你的真实文件——不是给你文本去复制粘贴，是创建文档/更新表格/编报告/存到正确目录。

搭法：建任务模板库 - 写报告：从 [表格] 取数 → 与上周对比 → 按 [格式] 写报告 → 存 [文件夹] - 做演示：读 [文档] → 提关键洞察 → 做 [N] 页 slide → 存 [文件夹] - 处理文档：读 [文件夹] 所有 PDF → 抽 [数据点] → 做汇总表 → 异常 flag

每个模板必须含：输入源 + 处理步骤 + 输出格式 + 保存位置。越精确，babysit 越少。

最适合 Cowork 的生产任务 - 文档处理：扔一堆 PDF/合同/研究论文，Cowork 用 sub-agents 并行处理 20 篇文档分钟级 - 数据汇总：跨表读取 + 计算 + 格式化报告 - 内容生产：有 content brain 文档可一周内容批量产出 - 研究汇总：研究问题 + 网搜 → 结构化研究简报代替 20 个浏览器 tab

操作清单 - 找 5 个最常见的反复任务 - 每个写 Cowork 模板（具体 inputs/steps/outputs） - 存到能快速复制的地方 - 每个跑一次按输出质量精修 - 把零碎重复工作打包到单个 Cowork session

三、Session 3 — 日终收尾（5 PM）

做什么：关电脑前，Claude 编入今日全程 - 收发邮件、会议讨论、文件创建/修改、完成任务、未决任务、明日 carry over - 编一份 End-of-Day 报告存到简报文件夹

双重作用 1. 给你 closure：知道一切现在在哪 2. 种下明早简报的上下文：日终报告作为明天 morning briefing 的输入 → 形成连续 awareness loop

怎么搭 - 工作日 5 PM 第二个 schedule - prompt：复盘当日邮件活动 / 检查日历 / 扫今日修改的工作文件夹 / 对照晨简验证完成度 / 编结构化 wrap-up - 必含 "carry forward" 段落 → 喂明天的简报

四、完整日循环

7 AM     晨简在桌上等 → 5 min 读完，知道焦点
9-12 PM  高价值工作（决策/关系/创造/战略——只你能做的）
12-2 PM  触发日间生产模块 → Cowork 干文档/报告/内容/数据，你休息或人际部分
2-5 PM   review Cowork 输出，最后人工把关，处理晨简里需亲自的项
5 PM     End-of-Day 自动编入，review，关电脑，知道无遗漏

这是 AI 干生产、你做决策的 fully orchestrated 一天。

五、每周 15 分钟精修 → 复利效应

每周五问 3 个问题： 1. 简报漏了什么我自己发现的？→ 更新 prompt 2. Cowork 产出我重做了什么？→ 更新模板修质量 3. 本周冒出什么新的反复任务该自动化？→ 建新模板

这周精修是大多数人完全错过的复利点。 精修了三个月的人和"搭一次再没碰"的人，与工作的关系完全不同。

六、诚实账

• 搭整套要一整天，可能两天
• 跑起来后每天省 1-3 小时 → 周省 5-15 小时 → 月省 20-60 小时
• 不是假设，是你现在在做但不需要你天才的行政时间

Claude Cowork is not a tool you use. It is infrastructure you build. Build it once. Refine it weekly. Let it compound.

摘要

以"自动拉取邮箱发票并整理 Excel"为案例，完整演示从零搭建 Claude Code Skill 的全过程。强调 Skill 本质就是一个文件夹（说明书 + 工具脚本），用户只需提需求和报错，代码全部由 AI 完成。三个月实测：363 封邮件 → 44 张发票 → ¥8,861.69，每月 2 小时变 2 条命令。

核心内容

Skill 的本质结构

• 一个文件夹 + 一份说明书（大白话讲清功能/触发/调用）+ 若干工具脚本
• AI 启动时扫描文件夹读入说明书，之后按自然语言指令触发

开发流程三步法

1. 先聊需求：讲清"想要什么/数据从哪/未来会变什么/要小心什么"，特别是"未来会变什么"决定模块拆分
2. AI 写 AI 跑，你负责报错：把现象贴回去，AI 自己定位问题
3. 配置授权码：IMAP 授权码存 .env，自动加入 .gitignore

踩坑记录

• QQ 邮箱搜索语句外层带括号会吞掉截止日期条件
• PDF/OFD 同一发票号去重会互相覆盖，需按格式分别处理
• 12306/滴滴/京东发链接不发 PDF，需单独跟链接抓取

模型选型经验

• 结构化任务（字段抽取）不需要旗舰模型
• 切换到 Ling-2.6-flash（100B 免费）：44 张发票字段全对，速度更快，账单 ¥0
• 模型选型 = 任务复杂度匹配

可复制 Prompt

文末附完整可复制 prompt 模板，含邮箱配置、字段定义、业务规则等占位符，适配不同公司报销规则。

摘要

系统阐述 Skill 作为 Prompt 的工程化升级：将系统提示词、入参 Schema、执行逻辑打包成可调用、可预测的"AI 函数"。核心类比：Prompt 是终端临时命令（CLI），Skill 是系统上的应用程序（App）。三个硬指标：持久化存储、按需激活、参数化输入。

核心内容

Skill vs 相关概念

• Skill vs Prompt: Skill 是工程封装重在稳定复用，Prompt 是临时交互重在灵活
• Skill vs MCP: MCP 解决连接问题（水管），Skill 解决处理问题（净水配方）
• Skill vs Agent: Agent 是项目经理负责规划，Skill 是扳手负责执行

渐进式披露三层架构

1. 用户意图层(Intent Layer): 用户说人话
2. 调度匹配层(Routing Layer): AI 扫描 Skill 列表，通过 Description 匹配，Description 字段是 AI 选菜的菜单
3. 底层执行层(Execution Layer): 按 Schema 提取参数 + 固化系统提示词输出结构化结果

Prompt 的三大痛点

1. 失忆症：每开新对话从零开始
2. 资产散落：祖传 Prompt 在个人备忘录里发霉
3. 脆弱边界：纯 Prompt 没有 Schema 约束，输出不稳定

摘要

开源"洁癖.Skill"——一个自动审查并维护项目文档体系的 Claude Code/Codex/OpenCode/OpenClaw 通用 Skill。核心理念：合并优于追加，删除优于保留。过期的记忆比没有记忆更糟糕，因为 AI 会基于错误前提做事。每次任务收尾运行 /neat，类似游戏的存档机制。

核心内容

解决的问题

• Agent 越用越笨的根源不是模型笨，是文档和记忆已"脑腐"
• 代码迭代了 7-8 轮，文档还是 1.0.0 初始版本
• 特别是 vibe coding 用户（设计师/产品/内容创作者）最容易受此困扰

三层知识体系

1. Agent 记忆系统: 过去聊天记录、项目隐性知识
2. CLAUDE.md: 给 AI 自己看的项目约定、结构、红线
3. docs/ 和 README: 给其他人看的接入指南、架构说明、运维手册

AutoDream 的不足

• Claude Code 的 AutoDream 只动记忆不动项目文档
• CLAUDE.md 里写新增路由 ≠ docs/integration-guide.md 里写下游怎么接
• 前者是提醒自己，后者是教别人，两份都得写

洁癖.Skill 五步流程

1. 强制机械式盘点：列出所有 md 文件逐一读取
2. 变更影响矩阵：不只看新事实，看波及哪些文档层级
3. 按序修改：先 docs/ → 再 CLAUDE.md → 最后整理记忆
4. 自检清单：环境变量是否在 runbook 和 CLAUDE.md 都出现、相对时间遗留等
5. 输出变更摘要

核心原则

• 信息多不是优势，信息准才是
• 一条过期记忆比没有记忆更糟糕（没有时 AI 至少会问，过期时 AI 会基于错误前提做事）
• 对话可以随时关，但文档永远在

摘要

《Skill 工程化实战》系列第三篇，从零搭建一个 domestic-social-copywriter Skill 演示工业级标准：description 决定路由命中、SKILL.md 是契约（frontmatter + 步骤 + JSON 输出）、长知识抽到 references/、确定性逻辑抽到 scripts/、allowed-tools 是真正的安检门。配套讲了 Skill 的测试用例集（路由正反例 + Happy Path + 边界 + 稳定性）和 Prompt Injection 防御。

核心内容

一、三步从零搭建 Skill

Step 1 — description 是唯一招牌 - 业余写法："用于写朋友圈和小红书文案" ❌ - 工程写法：触发条件 + 输入形态 + 输出形式三段式 ✅ - 因为 progressive disclosure：会话启动只加载 name/description，正文命中后才加载

Step 2 — SKILL.md 目录结构

.claude/skills/<name>/
├── SKILL.md          # 必填，frontmatter + 作业指导书
├── references/       # 长参考资料，按需引用
└── scripts/          # 确定性逻辑（如 validate_output.py）

Step 3 — 长知识挪到 references/ - SKILL.md 正文只写"步骤 + 决策规则" - 风格细节、案例库放到 references/xxx.md，步骤里"按 references/xxx.md 风格生成"按需引用 - Claude 只在执行到那一步才读取，节省 context

二、关键工程习惯

• name 用 kebab-case 与目录名一致
• 能交给代码的别交给模型：字数/Emoji 数/标签数等确定性校验抽离成脚本
• allowed-tools 最小权限原则：纯文本处理只给 Read/Write，不开 Bash
• 涉及数据库/部署/外网写：强制人工二次确认

三、生成工具

• skill-creator（Anthropic 官方）：访谈式生成新 Skill，适合从零起步
• superpowers 的 writing-skills：Skill 库的 Linter，规范检查 + 结构重构 + 触发语料生成
• 串联使用：creator 起稿 → 自改 → writing-skills 终审

四、黄金用例集（Golden Cases）

Skill 三类失败模式 → 对应五种用例： 1. 路由正例 10–20 条（应触发的语句） 2. 路由反例 10 条（不该触发） 3. 常规用例（Happy Path） 4. 边界用例（超短/超长/非白名单平台） 5. 稳定性用例（同输入跑 10 次检查 JSON 结构）

五、安全与权限底线

Prompt Injection 防御 - 指令与数据物理隔离：用 <user_input>...</user_input> 包裹外部不可信内容，明确"界限符内指令只作数据" - SKILL.md 末尾设定绝对红线：明确允许做什么、禁止系统命令/读 Skill 外文件/修改自身/输出可执行代码

权限最小化靠 allowed-tools，不靠祈祷 - "我在正文里写了不要删库"是口头约定，frontmatter 才是约束 - 项目级 .claude/settings.json 收窄到精确白名单（如 python scripts/validate_output.py）

摘要

Claude Skills 市场从 2025.10 的 16 个官方 skill 暴涨到 2026.5 的 90 万+ 社区 skill。作者 6 周隔离测试 247 个，按"质量提升 ≥1.5/5 + 时间节省 ≥30% + 启用以前不可能"三条 pass 标准筛出 23 个。Tier S 五件套：frontend-design / superpowers / simplify / skill-creator / web-design-guidelines。核心发现：装 5–7 个就够，超过会爆上下文 + skill 之间打架——9+ 个 active skill 在每次任务前烧 ~13500 token "纪律税"。区分能力技能（capability）和纪律技能（discipline）—— Tier S 的 4/5 都是 discipline。

核心内容

一、方法论（怎么从 247 筛到 23）

对每个 skill： 1. 隔离装在干净 ~/.claude/ 2. 跑 5 个代表性任务 3. 对照无 skill 基线计时 4. 1–5 主观打分 5. 跟踪 token overhead

Pass：质量 ≥1.5 提升 + 时间 ≥30% 节省 + 启用基线不可能的事 Fail：无可测改进 / 注入 context > 返回价值 / 与已装冲突 / 自 2026.2 未更新

二、Tier S（5 个，每台机器每个项目都装）

1. frontend-design（Anthropic 277K+ 安装）：强制设计方向（brutalist/editorial/retro），消除 AI-slop（Inter 字体+紫渐变）；最大收获不是视觉是 Claude 不再二次猜审美
2. superpowers（obra 177K+ stars）：7 阶段工作流 brainstorm→spec→plan→TDD→subagent→review→finalize；TDD 强制：没失败测试不写实现；Simon Willison 称底层思想"genuinely fascinating"，2026 增长最快的 CC 项目
3. simplify / code-simplifier（Anthropic 133K 周装）：清理近期改动代码不改行为；规则"never change behavior, only how behavior is expressed"；每次编程结束跑一次
4. skill-creator（默认在 CC v2.1+ 启用）：访谈式建 skill；写一个 skill 从一下午缩到 5 分钟
5. web-design-guidelines（vercel-labs 19.5K stars）：100+ 规则审 a11y/性能/UX；抓到了 ESLint a11y 漏掉的可见焦点态

三、Tier A（8 个，匹配领域才装）

6 ui-ux-pro-max | 7 composition-patterns | 8 valyu（FreshQA 79% vs Google 39%）| 9 claude-seo | 10 agent-browser | 11 excalidraw-diagram | 12 notebooklm-integration | 13 remotion-best-practices

四、Tier B（10 个，触发条件匹配再装）

14 pdf | 15 docx | 16 pptx | 17 xlsx | 18 marketing-skills | 19 mattpocock/skills | 20 claude-deep-research-skill | 21 firecrawl | 22 obsidian-skills | 23 awesome-claude-skills

五、224 个被删的模式

• ~80 个是 Cursor 风 prompt 集合：50 条通用规则的 markdown，无 SKILL.md schema，CLAUDE.md 已经能干
• ~50 个重复：两个 TDD 框架、三个安全扫描器、五个 code reviewer ——同类装一个就够，并存会输出矛盾
• ~40 个自 2026.2 没更新：CC v2.1 hook spec 加了 21 个生命周期事件（特别是 PostToolUseFailure），老 skill 静默失败
• ~25 个恶意/被污染：高 stars + 2026.2 后建仓 + 无贡献者历史 + 依赖可疑包；ECC AgentShield 报告 2026.1 单月 2857 个扫描里 341 个恶意（12%）
• ~20 个啥也没干
• ~9 个优秀但与 23 重复：spartan-ai-toolkit / artifacts-builder / tdd-guard / Plannotator / claude-mem

六、安装顺序（比清单更重要）

阶段	内容
Week 1 — 地基	skill-creator + simplify + superpowers + frontend-design 或后端等价
Week 2 — 按缺口加 1–2	UI→web-design-guidelines + ui-ux-pro-max 二选一；TS→mattpocock；研究→valyu；SEO→claude-seo
Week 3+ — 领域	文档→pdf/docx/pptx/xlsx；图→excalidraw；视频→remotion

停在 5–7 个 active skill。 这是甜区。9+ skill 在 conservative "load when in doubt" 检测下，每次任务 ~13500 token skill 税在你提示词读到之前就花掉。

七、不能同装的对子

• web-design-guidelines + ui-ux-pro-max（都想驱动设计阶段）
• frontend-design + impeccable（都编码审美品味）
• valyu + Anthropic 内置 Search（都调 web search）

八、维护节奏（每周 10 分钟）

# Claude 这周实际用了哪些 skill
grep -h "skill_invoked" ~/.claude/logs/*.log | sort | uniq -c | sort -rn
# 14 天没触发的 disable 不是 uninstall
# 30 天没触发的 uninstall
# ECC 扫描
npx ecc-agentshield scan

九、心智模型：两类 skill

• Capability skills（给 Claude 没有的能力）：firecrawl / valyu / pdf / agent-browser
• Discipline skills（让 Claude 用你的方式执行）：frontend-design / simplify / superpowers / web-design-guidelines

多数人只装 capability，输出还是 generic ——质量提升大头来自 discipline。Tier S 的 4/5 都是 discipline 不是巧合。

摘要

@noahduck283 写作 Skill 迭代到第三版，限制条目堆到 20+ 条，结果越写越烂——那些约束有一半在对付 AI 的早期缺陷，AI 已经进化过去了，Skill 还停在原地限制它。"今天让 AI 稳定的约束，明天就是让它跑不快的枷锁。" 作者给出五条检验：description 是否准、权限是否最小够用、主文件是否控制住大小、模型是否对、是否真的比不用 Skill 更有用。配套开源工具 skill-doctor。

核心内容

反模式：把 Skill 当篱笆

"大多数人搭的 Skill，只是把提示词存起来加了一层仪式感。"

五条检验

1. 它能在该出现的时候出现吗？

• description（自我介绍）的语言必须和用户真实开口的语言对得上
• 反例：封面图 Skill 写 Create an image.，用户却说"给这篇文章配个图""做一张科技感海报"——永远休眠
• 太宽也不行：用户说"帮我写点什么"，错误 Skill 跳出来用错误流程
• 一年用不了几次的 Skill（年终总结、简历重写）可加 disable: true 关掉自动触发
• 测试方式：准备一批用户真实可能说的话挨个试。大多数人从来不测。

2. 权限给少了跑不动，给多了是风险

• 只读笔记的 Skill 给执行命令行权限 → 风险敞口白白放大
• 权限不够则模型绕路自己想办法，结果就开始飘
• 最小够用

3. 主文件是门，不是仓库

SKILL.md > 500 行通常说明塞错了。三层分开：

writing-skill/
  SKILL.md       ← 流程入口
  references/    ← 长文档、风格参考、案例对比（按需取）
  scripts/       ← 可执行确定性操作（写死的脚本比每次现场生成稳）
  assets/        ← 模板、类型定义、示例

"AI 先读主文件，知道流程，需要细节时再取。一开始就把所有东西倒进来，能跑的空间越来越小。"

4. 模型和任务，得对上

• 抽取信息、整理笔记 → 便宜模型够
• 写需要判断力的长文 → 便宜模型不够
• 一律最强：成本白花；一律便宜：能力不够时怪 Skill 没写好

5. "能跑"和"有用"是两件事

A/B 对比：同一任务跑两次 - 不用 Skill，AI 自由发挥：4 分 - 用 Skill：还是 4 分 → 这只是仪式感

只有 "用了之后比不用更好" 才算 Skill。

反思

包括我自己的。写作 Skill 迭代到第四版，才开始认真减限制。AI 变强了，我还用旧规则约束它，不自知。

今天让 AI 稳定的约束，明天就是让它跑不快的枷锁。

启示

• 与 [[2026-05-08-停止为AI设计Harness]] 高度共振：人类替 AI 设计的 harness 一旦 h_ai > h_human 就成了枷锁
• 对本仓库 28+ 个 .claude/skills/ 与全局 skill 列表：应该按"五检验"做一次清理
• 描述是否与"我会怎么说"对得上？
• 主文件是否超 500 行？
• 是否有 A/B 验证表明真的更有用？
• "AI 进化了，Skill 没跟上"的现象，对应到本仓库就是早期 /ingest、/distill 命令里那些"防 AI 瞎写"的条款——每隔一段时间应该审视哪些已经过时

摘要

TRAE 技术文档工程师 Jiaqi 撰写的 Skill 设计与开发一站式最佳实践指南。系统阐述了 Skill 的定义（可执行指令文档，非 Prompt）、五大核心设计标准、"评测驱动、失败优先"的六步工程化构建流程、渐进式披露的可维护架构，以及借助 AI 创建和迭代 Skill 的方法论。

Skill 定义与误区

• 定义：一份清晰、严谨、可执行的指令文档，明确 When/How/What
• 误区1：Skill 不等于 Prompt，它是可长期复用的能力模块
• 误区2：Skill 是写给模型的指令，不是写给人的文档
• 误区3：复杂度不等于强大，职责单一更易被正确触发

五大核心设计标准

1. 边界明确：正向/负向触发条件都要显式定义
2. 输入输出结构化：类似函数签名，明确 Input/Output schema
3. 步骤明确可执行：指令式具体动作，非描述性概括
4. 失败策略完备：每种失败路径都有明确处理方式
5. 职责绝对单一：一个 Skill 对应一个核心动作动词

元数据规范

• name：小写+连字符，动名词形式，不超过 64 字符
• description：第三人称，包含核心功能和触发时机关键词，不超过 1024 字符

指导方式自由度分级

自由度	场景	方式
高	多种有效方法	启发式策略（给原则）
中	存在首选模式	模板/伪代码（给框架）
低	操作脆弱易错	可执行脚本（给代码）

六步构建流程（评测驱动、失败优先）

1. 建立无 Skill 基线：先让模型裸跑，识别真实问题
2. 定义评测用例：3-5 个可复现用例，明确通过/失败标准
3. 编写最小化 Skill：只够通过当前评测的最小规则集
4. 补充边界条件与示例：新增规则必须对应评测用例
5. 评测回归与持续迭代：修改必须通过已有评测回归
6. 真实场景校准：观察误触发、遗漏上下文、隐性依赖

可维护性设计

• 渐进式披露：SKILL.md 作为入口导航，详细资料拆分为独立文件
• SKILL.md 控制在 500 行内，避免深度嵌套引用
• 工作流与反馈闭环：显式定义 Checklist，关键节点"验证-修正-再验证"

反模式清单

• 使用 Windows 风格路径
• 提供过多选择（应指明默认路径）
• 包含时效性信息
• 术语不一致

摘要

TRAE 团队通过在 iCube-Mono 项目中引入业务 Context Skills，将 Loop 自动修复 Bug 的成功率从 59%(19/32) 提升到 100%(32/32)。核心思路是将开发经验沉淀为 Skills，让 AI 在修复 Bug 时能按需加载业务上下文，避免多轮对话偏离方向。文章提出了 Session-Learning Skill 机制和模块化 Skills 架构设计。

核心数据

• 32 个业务 Bug 测试集
• 无 Skills: Loop 修复率 59% (19/32)
• 有 Skills: Loop 修复率 100% (32/32)

Session-Learning Skill

定义了一个自动总结任务经验并沉淀为全局 Skills 的机制： - 开发过程中遇到问题或积累经验时，通过对话触发 - 触发示例："这个问题已经解决成功了，请帮我总结一下经验，看看是否需要再加新的 skills" - 自动按项目规范新增 skill 到仓库

典型 Case

Case	问题	无 Skill	有 Skill	关键原因
1	Solo 模式 Flow 下快捷键不生效	失败	成功	需要补充业务上下文猜测原因
2	智能体 Panel 保存无反应	失败	成功	同上
3	文件引用唤不起对话框	失败	成功	VSCode DI 规范：禁止异步方法后通过 DI 取 service
4	模型选中后光标定位问题	失败	成功	Radix UI Select 组件焦点细节

iCube-Mono Skills 架构设计

纵向按业务模块划分 Skills： - 前端模块: ai-chat、design、desktop（各含子模块 docs） - VSCode 模块: platform 服务层、workbench contrib、workbench services - 每个子模块有触发词索引表，匹配场景自动加载对应 skill 文档

以 ai-chat 模块为例，包含 12 个子 skill：session、agent、stream、model、fast-apply、store、components、input、markdown、i18n、autorun、mcp。

Skills 迭代方法

• 维护业务模块 Bug list 作为 Benchmark
• Loop 修复率指导 Skills 迭代方向
• 修复率越高说明 Context 越完善

摘要

Phil Schmid 给出 2026 年主 Agent 管理 subagent 的四种模式，按主 Agent 对生命周期的控制度排序：Inline Tool（函数调用）→ Fan-Out（先撒后等）→ Agent Pool（持久化消息）→ Teams（agent 之间互相通信）。模式越往上越复杂，对模型能力要求越高（Pattern 4 要求所有参与者都是前沿模型）。原则：从 Pattern 1 起手，绝大多数任务不需要复杂编排。

核心内容

Pattern 1 — Inline Tool（subagent 当函数）

• 主 Agent 调一个工具（如 call_agent）spawn 子 agent 拿结果回来
• 调用方看就是另一个工具（像 read_file）
• 支持同步（阻塞返回）和异步（先返 ID 后注入通知）
• 何时用：自包含工作（research lookup / code review / file analysis / test generation）——大多数 subagent 用例从这里起手
• 限制：任何支持 tool use 的模型都能跑（含小模型）；没法发后续指令、检查进度、提前取消；误解任务直到结果回来才知道

Pattern 2 — Fan-Out（撒出去并等结果）

• 工具：spawn_agent（立即返 ID）+ wait_agent（阻塞等结果）
• 模型决定 interleaving：可同时撒多个 agent + 干自己的活，再用 wait_agent 当全局信箱
• 何时用：多个独立任务并发；主 agent 不需要从某个子 agent 的中间结果启动另一个
• 限制：模型要能正确判断什么时候 wait；如果撒完立即 wait 那和 Pattern 1 没区别——价值取决于模型是否能在 spawn 和 wait 之间穿插自己的工作；仍是 fire-and-forget 没法中途纠偏

Pattern 3 — Agent Pool（持久化 Agent + 消息）

• 工具：spawn_agent send_message wait_agent list_agents kill_agent
• 与 Pattern 2 不同：agent 是有状态可交互的，主 Agent 发消息→收回复→再发，agent 保留完整对话历史
• 支持多步协作：researcher + writer 之间的工作流（researcher 找资料 → writer 写大纲 → researcher 回复 sources → writer 填内容 → researcher 事实校验 → writer 改稿）
• 何时用：多步工作流，agent 之间需要协作，主 agent 路由信息
• 限制：主 Agent 要追踪多个 agent 状态、决定何时 send 何时 wait、正确路由信息——小模型容易跟丢、忘记 kill_agent；前沿模型大概能 handle 2–4 个

Pattern 4 — Teams（Agent 之间直接对话）

• 跨 Agent 寻址（每个 agent 都有 send_message + 通过名字/路径互相寻址）
• 主 Agent 设置好团队后退到一边只等最终报告
• 例子：spawn planner + implementer + reviewer，告诉 planner "你的队友们：agent-i, agent-v，直接和他们通信，完成后向我汇报"
• 何时用：大型任务，协调逻辑超过单个 agent 一步步管理的能力
• 限制：
• 团队中每个 agent 都要前沿模型能力（不只主 Agent）
• 每个成员独立判断何时 message 队友、报告什么、何时收尾
• 基础设施挑战：循环检测（A 等 B，B 等 A）、冲突解决（两个 agent 改同一文件）、关停协调
• Debug 极难：消息链跨 agent 难追踪，故障会级联

选择原则

Pattern	工具数	主 Agent 角色	Agent 寿命
Inline Tool	1（call_agent）	Caller	单次任务
Fan-Out	2（spawn + wait）	Dispatcher	单次任务
Agent Pool	5（含 send/list/kill）	Coordinator	多轮
Teams	+ 跨 Agent send_message	Supervisor	持久

核心建议：从 Pattern 1 起步；多数任务不需要复杂编排。只在为并行（→2）、多步协作（→3）、复杂团队（→4）时往上走。

摘要

Nav Toor 给出 7 个可直接复制的 Claude Sub-Agent markdown 模板，分别对应 Researcher / Editor / Project Manager / Analyst / Recruiter / Ops Lead / CFO 七个角色，按市场薪资合计 $780K/年。每个 sub-agent 是一份带 frontmatter 的 .md 文件，放在 .claude/agents/ 目录下 Claude 自动识别。核心建议：不要装 7 个，先选 3 个跑两周，重复同一份工作再加第 4 个。文章给出按身份的安装组合（Solo founder / 自由职业 / 工程师 / 创作者 / 操盘手）。

核心内容

Sub-Agent 是什么

一个 markdown 文件给 Claude 一份工作 + 一颗大脑 + 一套规则。每个 sub-agent 跑在独立 context window 中，不污染主线程。安装路径： - Claude Code：.claude/agents/<name>.md，/agents 调用 - Claude.ai / Desktop / Cowork：Settings → Sub-Agents → Add

7 个 Sub-Agent 角色与替代薪资

#	Sub-Agent	替代角色	薪资
01	Researcher	Research Analyst	$90K
02	Editor	Senior Editor	$85K
03	Project Manager	PM	$110K
04	Analyst	Data Analyst	$120K
05	Recruiter	Talent Sourcer	$95K
06	Ops Lead	Ops Manager	$100K
07	CFO	Fractional CFO	$180K

7 个模板的设计共性

• 都用 yaml frontmatter（name + description）+ 编号步骤 + 硬约束 Rules + 强制结尾句
• 强制三段式输出：Findings / Contradictions / Open Questions（Researcher）；Runway / Burn / Bleeding Line / Cut List（CFO）
• 禁用词清单：editor 禁 leverage / robust / seamless / delve / em-dash 等
• 每个都以"一句话强制收尾"结束（如 "The project dies if ___ slips."、"If you cut nothing, you run out of money on ___."）

关键 Prompt 设计模式

1. 角色 + 唯一目标：editor "Your only job is to make the writing tighter and truer"
2. 预定义结构化输出：避免松散叙述
3. falsifiable milestone："Improve onboarding" 不算，"Reduce day-1 drop-off below 30%" 才算
4. 强制 confidence 标注：Researcher 结尾 "Confidence: High/Medium/Low + 一句理由"
5. 不允许 hedge：CFO "Never say 'it depends' without giving a default answer first"

按身份的 3 个起步组合

• Solo founder: CFO + PM + Recruiter（钱、计划、人）
• 自由职业 / 顾问: Researcher + Editor + PM
• 工程师 / 构建者: Researcher + Analyst + Ops Lead
• 内容创作者: Researcher + Editor + Analyst
• 公司内操盘手: PM + Ops Lead + Analyst

一日典型工作流

周一早晨：Researcher → 周五要 pitch 公司的 brief；Editor → 撕碎周日写的 proposal；PM → 规划上周承诺的 launch；Analyst → 上周数据 headline；CFO → 能否承担新 hire。90 分钟内完成 5 人的工作。

The compounding is not in any single sub-agent. The compounding is in running them in sequence, every day, on the same business.

摘要

@AlchainHust 深度解读 Claude Code v2.1.139 发布的 Agent View 功能。作者 4 个月消耗 131 亿 token、606 会话、38 项目，日均 7 session 并行。Agent View 本质是"给 Claude Code 的 tmux"——一个多会话管理面板，解决的是人的注意力分配问题而非 AI 能力问题。

核心内容

Agent View 核心设计

• 会话三栏分类：等输入 / 运行中 / 已完成
• 会话与终端窗口解绑，后台持久化到磁盘
• 每个后台 agent 在独立 git worktree 中工作，互不干扰（.claude/worktrees/<会话名>/）

三个易混概念澄清

• subagent：单个 Claude 内部的并行（AI 侧）
• team：多 agent 协作（AI 侧）
• Agent View：人类管理多个 Claude 的 dashboard（人侧）

worktree 隔离的使用方式

1. 边跑边看：直接进 .claude/worktrees/<会话名>/ 查看
2. 跑完合并：ExitWorktree(action=keep) 或 git merge
3. 绕过隔离（hack）：用 shell 的 cat > file <<EOF 直接写主目录，适合内容创作

诞生路径

Anthropic 内部（Boris Cherny 日常开 5 终端 + 5-10 浏览器 session）先跑了几个月 dogfood，然后产品化。是经典的 Sherlocking 时刻——把第三方社区工具（Crystal/claude-squad 等）的功能纳入官方。

/loop 集成

后台会话支持定时自迭代，会话带 ✢ 图标标识。

关键经验

"别因为派活变简单就一次派 8 件。AI 派任务的边际成本是 0，你 review 的边际成本不是。"

摘要

yaohui12138 实战体验 Claude Code 最新版两大功能：Agent View 多会话管理面板和 /goal 目标驱动自动执行命令。核心观点：这把人机关系从"AI 是工具，我是使用者"变成"AI 是团队成员，我是 PM"，是超级个体一人当团队用的底层基础设施。

Agent View

• 终端输入 claude agents 打开后台任务面板
• 所有后台任务在一个界面：working / awaiting input / completed
• 每个 agent 在独立 git worktree 工作，互不干扰
• 快捷键：↑↓ 选择、Space peek 预览、Enter 进入、Ctrl+T 置顶、Ctrl+S 按目录分组

/goal 命令

• 设定目标后 agent 自动跑到目标达成：修代码→跑测试→看报错→再改→再跑
• 装一个 session 级 Stop hook，目标未达成不停止
• /goal clear 清除目标
• /bg 把当前会话扔到后台

实战场景

claude --bg -w refactor-auth "重构 src/auth/"
claude --bg -w refactor-api "重构 src/api/"
claude --bg -w refactor-ui "重构 src/components/"

每个 agent 独立 worktree + 分支，设 /goal 后关电脑，回来 claude agents 看结果提 PR。

摘要

Anthropic联合Blender/Autodesk/Adobe/Ableton/Splice等发布Claude创意工具连接器，让Claude直接操作专业创意软件。同时推出Claude Design（Anthropic Labs产品）用于探索软件体验设计，并支持RISD/Ringling/Goldsmiths三所院校的教学合作。

核心内容

新增连接器

• Ableton：Live和Push官方文档问答
• Adobe for creativity：50+ Creative Cloud工具，支持图片/视频/设计
• Affinity by Canva：批量图像调整、图层重命名、文件导出等生产自动化
• Autodesk Fusion：对话式3D模型创建和修改
• Blender：Python API自然语言接口+场景分析调试
• Resolume Arena/Wire：VJ和实时视觉艺术控制
• SketchUp：对话→3D模型，描述即可建模
• Splice：免版税样本搜索

Claude五种创意用法

1. 学习工具：按需导师，解释复杂软件功能
2. 代码扩展：脚本/插件/生成系统（shader/动画/参数化模型）
3. 工具桥接：格式翻译/数据重构/跨应用同步
4. 快速探索：Claude Design可视化迭代，导出至Canva
5. 批量生产：资产批处理/项目脚手架/场景批量修改

Blender深度合作

• Anthropic加入Blender Development Fund成为Patron
• 基于MCP协议，其他LLM也可使用
• Blender官方开发的连接器

教育合作

• RISD Art and Computation
• Ringling Fundamentals of AI for Creatives
• Goldsmiths MA/MFA Computational Arts

摘要

@dotey 用 Anthropic claude-for-legal 仓库实例拆解 Claude 生态的四个核心概念：Skill 是工作手册、Agent 是执行者（含 Subagent 和 Scheduled agent）、MCP connector 是数据连接器、Plugin 是打包容器。

核心内容

1. Skill — 工作手册

一份给 Claude 看的 SKILL.md，定义任务的步骤、标准、升级条件、输出格式。例：nda-review 定义审 NDA 时比对哪些条款、按 playbook 打绿黄红三档。Skill 本身不干活。

2. Agent — 执行者

• Subagent：并行分身。例：tabular-review 对几百份合同做尽调，每个 subagent 负责一份文档，上下文隔离，最后汇总。
• Scheduled agent：定时后台任务。例：renewal-watcher 每周扫合同库，90 天内到期的发 Slack。docket-watcher/reg-feed-watcher 同理。

3. MCP connector — 数据连接器

把外部系统的数据接入 Claude。例：Ironclad（合同库）、DocuSign（已签合同）、iManage（文档管理）、Everlaw（电子取证）、CourtListener（联邦法院）。换执业方向就换一套连接器。

4. Plugin — 打包容器

一个 Plugin 文件夹内包含： - 一堆 Skill（nda-review、vendor-agreement-review、escalation-flagger…） - 几个 Scheduled agent（renewal-watcher、deal-debrief） - .mcp.json（声明连接哪些外部系统） - CLAUDE.md 模板（记录团队 playbook）

装一个 Plugin = 一次性配齐某个方向的全套能力。

摘要

TRAE 技术专家小夏系统讲解 MCP（Model Context Protocol）工具设计的核心理念与实操技巧。核心观点：Agent 工具不是 REST API 的封装，而是 AI Agent 的用户界面。文章从 LLM Tool Calling 完整链路出发，分析 Agent 如何"看"工具（名称-描述-参数三元组），并给出命名、描述、参数设计的具体原则，目标是减少 Agent 的认知负担，让工具一次用对。

核心内容

LLM Tool Calling 机制

• LLM 不执行函数，只生成结构化的"工具调用请求"文本，应用程序负责实际执行
• 工具定义（name/description/parameters）被注入 system prompt，占用 context window
• 不同 LLM 内部使用类 XML 格式而非 JSON 处理工具调用，JSON 只是中间格式
• OpenAI 建议工具数量控制在 20 个以内；每个工具约 250-300 tokens

MCP 的定位

• 解决 N 个工具 x M 个 LLM 的适配问题，引入标准化中间层
• MCP Client 负责将工具转换为各 LLM 原生格式
• 工具命名约定 mcp_<server-name>_<tool-name> 可能导致命名冲突和长度超限
• 不同 LLM 厂商对 JSON Schema 支持差异大（OpenAI 只支持 anyOf，不支持 allOf/oneOf）

Agent 如何"看"工具

• 工具 = (名称, 描述, 参数 Schema)，这是 Agent 的全部认知
• Agent 依赖显式语义，不做隐含推断；REST API 的设计原则对 Agent 不完全适用
• 试错成本高：每次失败消耗 token、污染上下文、无跨会话记忆

命名原则

• 完整自解释：get_user_by_email 优于 get_user
• 动词优先：create/get/list/search/update/delete/send/run
• 前缀分类：github_create_issue、slack_send_message 便于 Agent 快速筛选
• 保持 30-50 字符，TRAE 限制 server name + tool name 共 60 字符

描述原则

• 回答 What/When/Constraints/Output 四个问题
• 参数描述必须带示例："owner/repo format, e.g. 'facebook/react'"
• 说明失败情况和替代方案
• 用描述引导工具选择顺序（"推荐首选" vs "只有当 X 失败时才使用"）

摘要

TRAE 技术专家小夏系统讲解了 AI Agent 工具（MCP Server/Skills）的设计方法论，从输入设计、输出设计、错误处理、工具粒度、脚本可移植性到 Skills 与 MCP 互补六个维度展开。核心观点：MCP 是 AI Agent 的用户界面而非 REST API 封装；上下文窗口是稀缺资源，工具设计的本质是降低 Agent 的认知负担。文章还介绍了 MCPorter 将 MCP Server 转换为 CLI 工具的高级模式。

核心内容

输入设计：降低出错概率

• 合理默认值：必填参数尽量少，默认值选最常用选项
• Schema 验证：用 enum 限制可选值、pattern 约束格式、minimum/maximum 约束范围
• 宽松解析：严格定义 Schema，宽容执行变体
• LLM 专项技巧：复杂数组展开为 change_1/change_2 独立参数提高稳定性；静态参数作为行为提醒（Reminder Pattern），强制 LLM 在关键操作前"思考"确认

输出设计：给 Agent 可操作的信息

• 结构化数据用 JSON，展示内容用 Markdown，混合场景用 JSON 包装 Markdown
• 避免暴露底层技术细节（UUID/mime_type），返回语义化字段
• 提供 response_format 参数控制详细/精简输出
• 主动控制输出大小，截断时提供引导指令

错误处理：帮助 Agent 自我纠正

• 错误是输入不是终点，回答 What/Why/How 三个问题
• 提供替代方案和具体修复步骤
• 区分可恢复错误（Agent 可重试）和不可恢复错误（需人工介入）
• 配置错误优雅处理，等到被调用时再报告

工具粒度权衡

• 核心原则：按使用场景聚合，不按数据结构拆分
• 编排逻辑放在代码里，不放在 LLM 上下文窗口里
• 启发式：如果 90% 情况下调用 A 后都会调用 B，考虑合并
• 每个 MCP Server 控制在 5-15 个工具，一个 Server 一个职责
• 定期统计使用数据，删除未使用工具

Skills 与 MCP 互补

• MCP 每轮对话固定消耗 token，Skills 的详细内容只在被调用时读取
• Skills 采用三层披露：元数据（~100 tokens）→ 指令（<5k tokens）→ 资源（无上限）
• 组合模式：Skills 提供工作流指导，底层调用 MCP 工具执行

MCPorter：MCP 转 CLI

• 将任意 MCP Server 转换为独立 CLI 工具，让 Skills 像调用命令行一样使用 MCP
• 维护 daemon 进程复用连接，自动处理 OAuth 认证
• 支持生成 TypeScript API 进行脚本编排，降低上下文压力

摘要

TRAE 技术文档工程师 Jiaqi 整理的 TRAE IDE 中 10 款热门 MCP Server 推荐。MCP (Model Context Protocol) 允许 LLM 访问自定义工具和服务，TRAE 支持 stdio、SSE、Streamable HTTP 三种传输类型。文章逐一介绍了每个 MCP Server 的核心功能、使用场景和可调用工具列表。

10 款 MCP Server 概览

MCP Server	核心能力
Context7	官方文档实时检索与上下文注入，避免使用过时 API
Puppeteer	浏览器自动化：导航、点击、截图、执行 JS
Sequential Thinking	结构化思维流程，复杂问题分步求解
GitHub	基于 GitHub API 管理仓库/Issue/PR，仅作用于远程资源
Figma AI Bridge	解析 Figma 设计数据，提取 SVG/PNG 资源，辅助设计还原
Playwright	高级浏览器自动化：测试代码生成、143+ 设备模拟、网络请求控制
Memory	本地知识图谱持久化记忆(Entity-Relation-Observation)，跨会话上下文
Excel	读写 Excel 数据、公式、创建工作表
File System	基于文件系统的文件读取
Chrome DevTools	开放 Chrome DevTools 全部能力：自动化、性能追踪、网络分析

Playwright vs Puppeteer 差异

Playwright 相比 Puppeteer 额外提供：测试代码录制与生成(Codegen)、网络请求/响应控制与断言、143+ 设备预设模拟、PDF 导出、iframe 操作、多标签页切换。适合更复杂的结构化网页测试场景。

Memory 知识图谱模型

三类核心概念： - Entity: 主要节点，可识别对象 - Relation: Entity 间有向连接，主动语态描述 - Observation: Entity 的离散信息片段，可增删改

添加方式

通过 TRAE IDE 内置 MCP 市场一键添加：设置 > MCP > 添加 > 从市场添加。Local 类型需本地安装 NPX/UVX，env 字段需替换为真实 API Key/Token。

摘要

Linux.do 用户 oma 的 Claude Code 防封号实战经验。核心论点：Anthropic 风控不是静态规则，而是"真实人类概率评估模型"。应对策略：新账号前两周用 Desktop 不用 CLI，App Store 订阅而非官网直刷，Pro Plan 起步自然升级，保持人类作息节律。养号期约一个月（首次续费后可放松限制）。

核心内容

12 条规则

1. 新账号前两周只用 Desktop 里的 Claude Code，不碰 CLI
2. 新账号不用第三方客户端（OpenCode/OpenClaw/CraftAgent）
3. App Store 或 Google Play 订阅，不在官网直刷信用卡
4. 从 $20 Pro Plan 起步，多次触限后自然升级 Max
5. 升级 Max 后前两周，触发用量上限不超过 3 次
6. 账号要有作息——不要 24 小时持续高负载
7. 不用万人骑的公共代理
8. 新账号早期不频繁更换 IP
9. 被封号后换号前彻底清除电脑上所有 Claude 相关文件（重置指纹）
10. 养号期约一个月（首次续费后限制可放松）
11. 永远不共享账号
12. 永远不用公共代理

第一性原理

• Anthropic 风控本质是回答：这个账号像不像一个正常人类？
• 不是绕规则，而是主动构建让模型信服的行为档案
• CLI 的结构性原罪：使用模式和自动化脚本在流量特征上几乎无法区分

摘要

yidabuilds 把 2026 年 3-5 月密集发布的四家国产模型（DeepSeek V4 / Kimi K2.6 / GLM-5.1 / MiniMax M2.7）全接入测了一圈：主力仍留 Claude，但大文档分析、长程后台、批量内容、自动化网页操作这四类任务完全可以分流到国产。分流不能只看价格，三个变量是成本 / 上下文容量 / 任务持续时长。窗口在收窄——Kimi API 涨价 58%，GLM 订阅翻一倍多。

核心内容

横向对比锚点

Claude Pro 海外 $20/月 ≈ 144 元；Code 订阅 $200 ≈ 1440 元。

模型	入门订阅	关键特征
DeepSeek V4	无订阅，纯 API	Flash 输入 1元/输出 2元/M token，缓存命中 0.2 元；100 万 token 上下文真实可用
Kimi K2.6	39 元	长程编程强（社区 13 小时重构金融引擎），工具调用稳定性一般
GLM-5.1	49 元	8 小时搭 Linux 桌面，向量库 6.9x；高峰期严重过载，2026 涨价翻倍
MiniMax M2.7	29 元	每秒 100 token 最快，文字润色强；复杂数学会死循环

DeepSeek V4（4/24 发布，距 V3 484 天）

• 月成本测算：1 亿输入 + 3000 万输出 token，全走 V4-Flash ≈ 160 元；同量 Claude Opus 4.7 纯 API ≈ 9000 元
• 100 万 token 上下文真实可用：50 页文档/整个 GitHub 仓库直接全量输入，不掉质量
• 测试期间无限速、无排队；大陆信用卡直接付
• Pro 档算力受限响应慢，下半年华为昇腾 950 上市后或改善
• 不支持多模态是最大短板

Kimi K2.6（4/20 发布，"我们最强的代码模型"）

• 社区案例：13 小时自主重构 8 年历史的 exchange-core，4000 行修改，吞吐 +133%
• 12 小时 Zig 自主写推理引擎，比 LM Studio 快 20%
• 作者实际推荐场景：自动化外链提交（SEO）。Codex 安全审查拒绝、Claude 国内封号风险，Kimi 最稳
• 缺点：响应延迟肉眼可见、工具调用 400 报错、高峰期排队

GLM-5.1（3/27 智谱发布）

• 全程华为昇腾 910B 训练，10 万张芯片，无英伟达
• 高峰期严重过载、上下文窗口仅 200K（四家最短）
• 2026 调价翻倍：Lite 49 / Pro 149 / Max 469；老用户体验差

MiniMax M2.7（3/19 发布，激活仅 10B）

• 速度优势：每秒 100 token，文案/摘要场景优秀
• 结构性缺陷：复杂数学陷入推理死循环，反复输出几千次同一句话——任何严密推理任务别碰
• 简单博客平台外链可用，复杂站点推理链断

分流推荐

场景	模型	月开销
大文档/大代码库	DeepSeek V4-Flash	< 50 元
长程后台任务（数据库优化/重构/测试生成）	GLM-5.1 Pro	149 元
批量内容生产（无数学）	MiniMax Starter	29 元
自动化网页操作（如外链提交）	Kimi K2.6	39 元
日常主力编程 + 复杂推理	继续 Claude	—

三家国产入门档全选 117 元 / 推荐配置 217 元，覆盖场景比单 Claude 宽。

切换的隐藏成本

作者本人继续 Claude Code Max ×2 + Codex Pro：IDE 插件 / 快捷指令 / 提示词模板全部围绕这套搭。单点切换的适配成本会抵消模型本身性价比优势。从零搭工作流的人才能吃到全部价差。

摘要

面向非技术用户的 Token 经济学科普：同样用量下小王月花 3500 元、小李仅 180 元，差距在于对 Token 和上下文窗口的认知。6 个实操技巧 + 三类用户真实账单对比。

核心内容

Token 基础

• 1 Token ≈ 英文 0.75 单词 ≈ 中文 0.5-0.7 字
• 中文比英文多花 50%-100% Token（模型"母语"是英文）
• 每轮对话 AI 必须重读全部历史，第 1 轮 500 Token → 第 20 轮 5000 Token

6 个省 Token 技巧

1. 中文对话加一句"请用中文回答"，实测省 37%
2. 只贴需要改的部分，不扔全文
3. 话题换了开新对话，每 10 轮考虑重开
4. 用列表代替大段文字，需求越具体输出越短
5. 反复任务写成 System Prompt，避免每轮重复
6. API 用户用 Prompt Caching，DeepSeek 命中后降到原价 10%

模型价格对比（每百万 Token）

• GPT-4o: $2.5/$10
• Claude Sonnet: $3/$15
• DeepSeek V3: $0.27/$1.10
• 同任务 DeepSeek 比 GPT-4o 便宜 10 倍

三类用户月费

• 自媒体博主：从 ¥145 Plus → ¥35 API+DeepSeek
• 程序员：从 ¥600+ Claude Sonnet → ¥180（System Prompt 缓存+Haiku 分流）
• 普通上班族：基本 ¥0

摘要

Xx15573208 总结 11 个 Claude Code token 省钱技巧。核心洞察：第 30 轮对话成本是第一轮的 31 倍，99% token 消耗在输入端。Claude Code 不像 ChatGPT 那样静默丢弃历史，上下文默认全保留，不主动管理就是让账单自己跑。

减少无效内容进入上下文

1. 合并消息：需求一条说完，分三条发等于交三次入场费
2. 错了就编辑：按两下 Esc 进入 rewind 界面，直接编辑上一条，错误输出不会堆进上下文
3. 临时问题用 /btw：不进上下文历史的临时提问，问完消失
4. 直接 @ 文件：避免模型搜索产生无效上下文，贴路径比说"读那个文件"便宜

主动管理膨胀上下文

5. 新任务开新对话：/clear 或 /new
6. 开启上下文用量显示：/statusline 配置状态栏百分比
7. 超过 70% 手动压缩：/compact 并指定保留内容，模型性能在高上下文占用时显著下降
8. 离开前先压缩：缓存 5 分钟失效，回来后第一条消息成本翻 10 倍

工作流层面

9. 先规划再执行：/plan 先定方案再执行，比边做边改便宜
10. 走错立刻按 Esc：不等错误输出完，止损后编辑上一条重来
11. CLAUDE.md 别塞太多：每条消息都读，只放真正每次都需要的规则

行业趋势

阿里 Coding Plan 停售，订阅制逻辑矛盾（平台赌你用不完，你赌自己能用完）。OpenAI 和 Anthropic 从未离开按量计费。

摘要

用户 @KengGuangLong 实践了 Karpathy 提出的 LLM Wiki 概念，用有道云笔记 + Claude Code 跑通了知识库自动构建流程。文章展示了从创建知识库到自动分析消化 Newsletter 内容的完整操作。

核心内容

实践要点

• 使用 Claude 网页端配合 Skill 触发流程
• AI 建议知识库名称（如 ai-wiki），确认后自动创建
• 支持上传案例图片提取美学基因
• 需要多模态模型支持以图逆向提示词风格

与 AK Wiki 的对比

• 相同思路：让 AI 自动消化外部资料，构建可检索的知识网络
• AK Wiki 的差异：双管道设计（外部摄入 + 内部蒸馏）、Obsidian 双链生态、wiki/ 目录分层（sources/entities/concepts/analysis）

摘要

大多数 Obsidian 知识库失败的原因不是"输入"而是"无反馈循环"——只为输入设计、不为输出设计、没有连接层、没有回访理由。本文提出四层架构：捕获（Readwise/Airr/Whisper/Telegram bot）→ N8N 自动管线 → Obsidian（5 文件夹）→ Claude 智能层。配合一份 CLAUDE.md + 每日 6:00 自动 brief + 每周 15 分钟 synthesis，让知识库从"墓地"变成"思考伙伴"。

核心内容

失败的三个原因

1. 捕获摩擦：超过 10 秒就会断
2. 没有连接层：每条笔记孤岛
3. 没有回访理由：不会主动 push 给你

四层架构

• Layer 1 捕获：Readwise（文章/Twitter/Kindle 高亮）+ Airr（播客）+ Whisper（语音）+ Telegram bot（移动快记）
• Layer 2 管线：N8N 监听各源，自动落 markdown 到 vault
• Layer 3 Obsidian：本地 markdown 文件，永久存储
• Layer 4 Claude：阅读所有内容、找连接、写 brief、回答问题

5 文件夹结构（不要过度设计）

• Inbox/ 全部先落这里
• Notes/ 处理后的高亮、文章、播客片段
• Ideas/ 自己的想法、观察、转录
• Projects/ 活跃项目
• CLAUDE.md 根目录指令文件

CLAUDE.md 模板核心字段

# Who I Am: name/work/focus/goals
# Current Projects: active/stuck/next milestone
# How This Vault Works: 文件夹说明
# What I Want From You: 浮现连接、挑战假设、从 vault 上下文回答
# What I Am Reading: 每周一更新

每日 brief（N8N 6:00 自动）

读 inbox 24h + notes 7d，输出三件事： 1. CONNECTIONS — 3 个最有意思的新旧连接（带原文引用） 2. PATTERN — 本周脑子在 working on 什么 3. QUESTION — 一个值得 sit with 的问题（不是任务）

每周 synthesis（15 分钟周一）

读全 vault，输出四件事： 1. EMERGING THESIS — 你正在 build 但还没明说的论点 2. CONTRADICTIONS — 最近保存的与之前信念冲突的（双面引用自己的笔记） 3. KNOWLEDGE GAPS — 该读但没读的 4. ONE ACTION — 这周最高杠杆的一件事

复利曲线

• 1 个月：稍有用
• 3 个月：开始连接 8 周前忘记的笔记
• 6 个月：拥有信念变化的完整记录，AI 已读懂你的思考方式

启动建议

不要一次性搭完。今晚先放 5 条笔记，让 Claude 找连接——这一刻系统从概念变成你想每天喂的东西。

摘要

非技术背景的 Lisa 分享 Karpathy 风格知识系统的最简搭建路径：Obsidian + Terminal 插件 + Claude Code + 开源仓库 AgriciDaniel/claude-obsidian。核心理念是"内容→信息→知识"三层提炼链路，本地存储知识永久属于你。工具不重要，闭环才重要。

核心内容

三层概念区分

• 内容（Content）：所有被制作出来的文字/图片/音视频，是载体外壳。
• 信息（Information）：从内容里"读出来的、有意义的差异"——简历→教育/工作/技能；新闻→谁参与/时间地点。同一份内容不同人读出不同信息，价值取决于对当前决策是否有帮助。
• 知识（Knowledge）：信息之上归纳→抽象→验证→规律/模型/方法论。可迁移、可教学、可系统化。

内容是外壳，信息是内容里那一点"有用的具体事实"，知识是从无数信息中归纳出的"可复用的规律"。

系统搭建四步

1. 装 Obsidian
2. 装 Terminal 插件：设置→第三方插件→社区市场搜 Terminal→启用
3. 在 Terminal 里启动 Claude Code：右键→在终端开启→启动 claude
4. 装 LLM Wiki 系统：git clone https://github.com/AgriciDaniel/claude-obsidian 到 vault 根目录；按需装 Dataview / Templater / Obsidian Git

三个核心结论

1. Obsidian + Claude Code/Codex 搭 LLM Wiki，自动收录 + 自动生成卡片 + 一键输出文章。
2. 全本地存储，不依赖任何大模型账户的稳定性。
3. 碎片持续收录，知识库越用越厚，调取/创作效率指数级提升。

信息收录流程

1. 输入信息源文章
2. 给输出需求
3. 写好的文章存档在 Obsidian 本地

心法

知识管理最大的误区是花太多时间在工具选择上，太少时间在持续输入上。工具不重要，流程才重要。

摘要

一家 30 人公司用 Claude Code + 飞书 CLI 的 5 个真实场景：会议知识库、工作复盘、对账自动化、协作画板、报销审批。飞书 CLI 已开放 15 个业务域 120+ 能力，几乎追平 API。

核心内容

1. 会议系列知识库

从飞书妙记中拉取选题会/周会/培训会历史数据，生成跨场次沉淀文档。解决"开完就忘"和新人入职信息断层问题。可设定定期自动更新。

2. Agent + 飞书全面工作复盘

8 路并行抓取消息、会议、妙记、日程、任务、邮件、文档、OKR，生成季度报告。已做成内部 Skill 放 Skill Hub 全员使用。数据来自飞书真实 context，质量远高于凑字数报告。

3. 对账流程自动化

经纪团队每月对接几百个博主。机器人自动从多维表格查数据 → 在群里 @博主确认 → 根据反馈自动分流（金额不对→商务、漏单→财务、无误→通知完成）。飞书 CLI 支持以本人名义发私聊消息。

4. 协作画板生成

区别于 HTML/图片输出：飞书画板是原生可协同的，任何人可拖动、改文字、加节点。适合开会时当场出架构图丢群里边改边讨论，也能做 PPT。

5. 报销与审批自动化

Agent 去飞书邮箱搜发票 → 知识库查报销 SOP → 填写报销申请 → 确认后提交。审批端同理：核对信息→汇总→确认→通过并附审批意见。全程不需打开飞书界面。

飞书 CLI 现状

• GitHub star 近万，15 个业务域、114 个能力
• 安装文档: open.feishu.cn/document/no_class/mcp-archive/feishu-cli-installation-guide.md