一问题引入：为什么同一个 Claude Code，有人好用、有人卡壳
这个视频不是从零解释“什么是 AI 编程”，而是把注意力放在一个更具体的问题上：同样打开 Claude Code，为什么有的人能稳定让它理解项目、运行工具、提交代码，有的人却总是在“它忘了规则”“它不知道文件结构”“它缺少工具权限”这些小问题上来回消耗。
Tech With Tim 的核心判断很直接：Claude Code 的效果不只取决于模型本身，还取决于你是否给它一个适合工作的环境。视频里的设置都很低门槛，包括在编辑器里使用 Claude Code、维护项目级 CLAUDE.md、安装常用插件、连接 GitHub MCP、理解模型切换和上下文压缩。这些动作单独看都不复杂，但组合起来能显著减少新会话里的重复解释。
这节课最值得记住的一点是：不要把 Claude Code 当成孤立聊天框，而要把它放进真实项目工作台，让它能看文件、记规则、调用工具、检查自己做过什么。
二核心概念：Claude Code 工作台的五个组成部分
视频里的内容可以整理成五层。第一层是运行位置：终端、VS Code、Cursor、Windsurf 这类编辑器都可以，关键是你要能同步看到 Claude 正在创建或修改的文件。第二层是项目记忆：根目录的 CLAUDE.md 用来存放长期规则。第三层是工具能力：Playwright、Superpowers、Context7、DBHub 等插件或连接器会扩展 Claude 能做的事。第四层是外部系统连接：GitHub MCP 让 Claude 能创建仓库、推送代码、读取远程项目。第五层是会话管理：/model、/compact、/insights 这些命令决定你如何控制成本、上下文和复盘。
对初学者来说，最容易误解的是“插件越多越好”。视频明确提醒：插件可以按项目级或全局级安装，不要为了显得强大而给 Claude 塞一百个工具。真正的目标是让每个项目拥有刚好够用的上下文和能力，避免工具列表本身变成噪声。
| 组成部分 | 解决的问题 | 常见误区 | 建议做法 |
|---|---|---|---|
| 编辑器/终端 | 让 Claude 能在真实项目里改文件 | 只在网页聊天框里复制粘贴代码 | 在 Cursor、VS Code 或终端中直接运行，并随时检查 diff |
CLAUDE.md | 保存项目长期规则和约定 | 每次开新会话都重新解释技术栈 | 把技术栈、命令、目录约定、代码风格写进去，并持续维护 |
| 插件与技能 | 提供浏览器自动化、文档检索、代码评审等能力 | 一次性安装过多工具 | 按项目需要启用，先选高频能力 |
| MCP server | 连接 GitHub、数据库等外部系统 | 把 token 和权限随意暴露 | 使用最小权限 token，并明确 local/project/user 作用域 |
| 会话命令 | 控制模型、上下文和使用情况 | 上下文快满时直接开新会话 | 先用 /compact 压缩，再用 /insights 复盘使用模式 |
三关键步骤：从“能用”到“稳定好用”
1. 在能看见文件的位置运行 Claude Code
视频开头建议把 Claude Code 放在终端或编辑器扩展里使用，例如 Cursor、VS Code、Windsurf 或同类编辑器。这样做的价值不是 UI 更酷，而是你能看到目录结构、生成文件、修改范围和错误反馈。Claude 生成页面、组件或配置时，你不用等到最后才发现它写到了错误目录。
如果你刚开始用 Claude Code，最小可行设置就是打开项目根目录，在编辑器侧边栏保留文件树，同时让 Claude Code 在同一个项目上下文里运行。每次让它做改动前先说明目标文件和边界，改完后检查 diff。
2. 先建 CLAUDE.md，再开始大量开发
视频强调 CLAUDE.md 必须放在项目根目录，并按这个名字拼写。Claude Code 开启新会话时会参考它，因此它适合存放“每次都应该知道”的信息：技术栈、开发命令、测试命令、目录结构、API 约定、代码风格、团队偏好、禁止修改的区域等。
更重要的是，CLAUDE.md 不是一次性文档。视频建议在开发过程中持续让 Claude 把重要经验更新进去。比如一次构建失败后发现必须先运行某个生成命令，就应该把这条规则写回文件。这样新会话不会重踩同样的坑，团队成员也能共享同一套项目记忆。
3. 选择少量高价值插件，而不是堆满工具箱
视频示例推荐了三个方向：Playwright 用于浏览器自动化和 Web 应用测试；Superpowers 类插件提供 brainstorming、sub-agent driven development、systematic debugging、code review 等工作流技能；Context7 用于获取更新的文档，减少模型引用过期 API 的概率。
这组推荐背后的决策逻辑比插件名字更重要：优先补齐 Claude Code 经常缺的能力。Web 项目最常缺的是“真实点击和验证”，所以 Playwright 有价值；新库升级后最常见的是“文档过期”，所以 Context7 有价值；复杂任务容易缺少“流程纪律”，所以工作流型技能有价值。
4. 用 GitHub MCP 打通远程代码流，但要谨慎处理 token
视频中 GitHub MCP 的作用是让 Claude 能帮你创建远程仓库、推送当前代码、访问云端项目。它演示了从 GitHub 个人设置进入 Developer settings，创建 Personal Access Token，并把 token 填入 MCP 安装命令的流程。
这里需要额外注意安全边界：视频面向初学者，演示时会讲“把 token 复制到命令里”。实际工程里更推荐临时环境变量、最小 scope、短有效期 token，避免把 token 写进仓库、日志或共享配置。安装作用域也要区分清楚：local 只在当前项目可见，project 会随项目共享，user 则对当前用户所有项目可用。GitHub 这类通用能力可以考虑 user 级，但包含公司内部系统权限的 MCP 更适合项目级或更严格的环境。
5. 熟悉 /model、/compact 和 /insights
/model 用来切换不同模型。视频提到 Sonnet、Opus、Opus 1 million、Haiku 这类选项，并建议多数日常任务使用 Sonnet，复杂任务才升级到 Opus，大上下文任务再考虑 1 million context，简单快速任务可以用 Haiku。
/compact 用来把当前长上下文压缩成摘要，避免因为上下文窗口变大而失去连续性。视频也提醒，它在接近上下文上限时会自动发生，但你可以主动触发。/insights 则会生成一份使用报告，帮助你看到会话数量、消息行为、并行会话、代码改动等统计，并给出改进建议。对长期使用者来说，这是一种“反向调试自己工作方式”的入口。
四决策矩阵：这些能力该什么时候加
| 能力 | 适用场景 | 优点 | 风险 | 决策建议 |
|---|---|---|---|---|
| 编辑器扩展 | 日常编码、文件生成、组件修改、调试项目结构 | 能直接观察文件树和 diff，反馈闭环短 | 如果不看 diff，仍然可能误改文件 | 几乎所有项目都应该优先使用 |
CLAUDE.md | 有固定技术栈、团队规则、重复命令或禁止区的项目 | 让新会话继承长期规则，减少重复解释 | 写得太长会变成另一个噪声源 | 保留稳定规则，不要塞临时聊天记录 |
| Playwright | 需要登录、点击、表单流、视觉/端到端验证的 Web 项目 | 能把“看起来能跑”变成可复现脚本 | 选择器不稳定时会产生脆弱测试 | 前端应用优先安装；纯后端项目按需 |
| Context7 / 文档检索 | 使用更新很快的库、框架或 API | 减少过期代码和幻觉 API | 文档质量仍需人工判断 | 新框架、新 SDK、云服务接入时很值得 |
| GitHub MCP | 需要远程仓库、issue、PR、代码托管自动化 | 打通从本地生成到远程管理的闭环 | token scope、组织权限和误操作风险更高 | 只给必要权限；敏感组织先用手动审批 |
/compact | 长会话、跨多个功能点、上下文接近上限 | 保留连续性，降低开新会话的重建成本 | 摘要可能丢掉细节 | 在阶段性完成后主动压缩，而不是临界时才救火 |
五关键观点引用块：把 Claude Code 当团队成员管理
Claude Code 默认没有跨会话记忆；如果你希望它遵守项目长期规则，就要把这些规则写进根目录的 CLAUDE.md，并在项目推进中持续维护。
插件和 MCP 的价值不是“让工具列表看起来很长”，而是补齐真实开发链路中缺失的一环：浏览器验证、最新文档、代码评审、数据库访问或远程仓库操作。
把这两句话合在一起，其实就是 Agent 工程里的一个普遍规律：上下文、工具、权限要被明确设计。模型越来越强以后，真正拖慢工作的往往不是“它不会写代码”，而是“它不知道该遵守哪条规则”“它没有可以验证结果的工具”“它拿不到项目外部状态”。