英文原题：Claude Full Tutorial for beginners in 2026 | Beginner to Pro
这个视频的价值不在于展示一个“更聪明的聊天机器人”，而是把 Claude 当成一个可组合的工作台来看：同一个入口里有普通对话、代码任务、Co-work 自动化、项目记忆、设计生成和外部连接器。对刚开始使用 Claude 的人来说，最容易踩的坑是把所有事情都塞进一次聊天里，然后抱怨模型没有上下文、输出太散、不能自动跟进。
视频里反复出现的主线是：先把任务类型分清，再选择对应的 Claude 能力。临时问答适合 Chat；需要围绕代码、仓库和变更落地时进入 Code；需要每天触发、整理邮件日历、跨应用执行时再使用 Co-work 或连接器。这样做的收益，是把“会回答问题”推进到“能维护一个工作流”。
可以把 Claude 当成一个工作系统：简单问题用聊天，工程任务用代码区，重复任务交给 Co-work 和连接器。
视频开头先介绍模型选择：重推理、长链路、复杂编码任务应该交给更强的模型；日常问答、轻量研究、文案整理可以用成本更低的模型。这里的关键不是追最新名字，而是理解“能力、速度、费用和上下文消耗”之间的取舍。越强的模型越适合负责不确定性高的决策，但不应该被浪费在每个小问题上。
对工程师来说，实用做法是把模型选择写进工作习惯：架构方案、迁移计划、复杂调试用高能力模型；接口命名、测试样例、摘要和格式化用轻量模型；最终提交前再让强模型做一次审查。视频中提到的低、中、高 effort，也可以理解为“让模型花多少推理预算来思考”。
Claude 的普通聊天区适合快速澄清概念、比较方案或生成初稿。Code 面板面向开发工作，适合把需求连接到具体文件、命令、测试和版本管理。Co-work 更像自动化任务入口，适合“每天早上给我发简报”“整理收件箱”“根据日历提醒我”等持续性动作。
这三个入口的区别，是很多入门用户容易忽略的地方。聊天可以解决一次性问题，但不负责长期记忆和触发；Code 能处理仓库内的具体修改，但需要边界、测试和验收；Co-work 需要明确数据源、频率、时区和连接权限。视频中的示例把这三类能力串起来，帮助用户判断什么时候该换工作模式。
视频后半段讲到 Projects：如果你经常写同一种内容、维护同一个产品、或有固定语气与格式，应该把材料、示例和指令沉淀到项目里。比如视频中的创作者脚本例子，可以把过去几十条脚本、语气要求、时长限制、禁用表达和目标受众都作为上下文保存下来。
这样做比每次重新解释需求更稳定。项目不是简单文件夹，而是一个可复用的上下文容器：它告诉 Claude “我是谁、我要什么、什么算合格、什么不要出现”。对团队来说，这相当于把隐性偏好变成可执行的操作标准。
视频中作者用 Whisper Flow 口述一个系统设计问题：为印度二线城市的外卖应用做实时订单追踪，面对骑手网络不稳定、每天五万订单、两人小团队，需要比较 PostgreSQL 轮询、WebSocket 和离线优先同步。这个例子说明，高质量提示词往往不是“短”，而是一次性说清背景、约束、候选方案和输出要求。
如果手打提示词很慢，用户会倾向于偷懒，只写“帮我设计订单系统”。语音输入的意义，是降低补充上下文的成本。真正让 Claude 输出变好的，不是输入方式本身，而是提示词里包含了规模、故障条件、团队人数、比较维度和决策要求。
作者在示例里明确要求“写代码前先比较方案”。这是很重要的工程习惯。直接让模型写代码，往往会得到一个看似可运行但前提不清的实现；先要求它列出方案、约束、风险和选择理由，才能暴露设计假设。视频里的 Claude 会先对小团队、订单规模和网络稳定性做现实检查，再建议更轻量的轮询加薄离线队列方案。
把这套模式迁移到日常开发，可以使用固定提示：先复述问题和约束；列出至少三种方案；说明每种方案的维护成本和失败模式；最后只选择一个并给出数据模型或接口草案。这样 Claude 会更像设计评审伙伴，而不是只会补全代码的工具。
视频展示了一个每日 AI 简报任务：每天早上 9 点，根据过去 12 小时发生的 AI 事件整理邮件，要求内容简洁、避免空泛表达，并询问可用的数据源。这个例子适合理解自动化任务的四个必要字段：触发时间、数据来源、输出格式、失败时的澄清方式。
这里尤其要注意权限边界。如果 Claude 看不到邮件、日历或消息，它应该先询问要连接哪些应用，而不是假装已经读取了数据。可靠的 Co-work 任务必须把“我能访问什么”和“访问不到时怎么办”写清楚，这比漂亮的总结更重要。
作者把内容创作脚本作为例子：如果希望 Claude 按自己的语气写 Instagram 或短视频脚本，需要提供历史样本、受众、长度限制、不要使用的表达，以及“看起来不像 AI 生成”的具体标准。Claude Projects 可以把这些要求长期保存，下一次生成时就不必重新说明。
对软件团队也一样。可以为某个仓库建立项目，把架构文档、测试命令、代码风格、PR 模板、常见故障和发布检查表放进去。每次让 Claude 参与改动时，它都能从同一个标准开始，而不是随机发挥。
视频还展示了 Claude Design：根据政策议题生成演示文稿，并通过追问补齐受众、时长、语气和诉求。它提醒我们，Claude 的输出不一定只是文本，也可以是幻灯片、界面草图、研究简报和跨工具动作。连接器则把 Gmail、Notion、Gamma、浏览器等外部工具纳入流程。
但连接器越多，越需要治理。用户应该只连接任务真正需要的应用，并明确哪些数据可以读取、哪些动作需要确认。否则自动化会从“省时间”变成“难审计”。
| 能力入口 | 适用场景 | 优点 | 风险 | 决策建议 |
|---|---|---|---|---|
| Chat | 概念解释、方案比较、临时写作、轻量研究 | 启动成本最低，适合快速澄清问题 | 上下文容易散，长期任务难复用 | 用于一次性问题；复杂任务先让它产出计划 |
| Code | 仓库阅读、代码修改、测试、调试、Git 工作流 | 能把自然语言目标落到文件和命令 | 如果需求边界不清，可能改动范围过大 | 先要求它读代码和列验收项，再允许修改 |
| Co-work | 每日简报、邮件整理、日历提醒、跨应用跟进 | 适合周期性、可触发的工作流 | 依赖连接器权限和数据源稳定性 | 写清触发时间、数据源、输出格式和失败处理 |
| Projects | 固定风格内容、团队规范、长期上下文、领域知识库 | 可复用样例、指令和记忆，降低重复说明成本 | 旧资料可能污染新任务，规则过多会冲突 | 只放稳定标准，定期清理过期示例 |
| Design 与连接器 | 幻灯片、UI 草图、邮件、Notion、浏览器和第三方工具 | 把输出从文本扩展到真实工具动作 | 权限过宽会带来误操作和隐私风险 | 从只读权限开始，对发送、发布、删除保留确认 |
不要只说“帮我做一个方案”。更好的提示是：这是我的业务背景、规模、限制和候选路径，请先比较，再选一个，并给出数据模型或执行计划。
这句话是整支视频最值得带走的工作法。Claude 的强项不是替你猜隐含条件，而是在你给出足够约束后帮你做结构化权衡。提示词越接近真实的工程评审，输出就越接近可执行方案。
因此，使用 Claude 的第一步不是背模板，而是养成“把任务讲完整”的习惯：目标是什么、谁使用、规模多大、有哪些资源、不能做什么、希望输出成什么格式。视频里的食物配送系统、每日简报、内容脚本项目和政策演示稿，其实都是同一个方法的不同应用。
如果你已经理解 Claude 的基础工作面板，下一步可以继续看更偏工程落地的课程：如何在 Claude Code 里组织 Skills、MCP、子智能体和本地开发环境。