企业官网建设流程全解析

• 文档
• 教程
• AI 技能

本指南对应仓库 tutorial/day1/README.md（Day 1 教程），面向已经完成 Day 0 安装与登录 的读者。它用一个贯穿始终的"天气查询"示例，讲清 Claude Code 的三层控制能力：Prompting（直接提问）、Agents（专家角色）、Skills（专项训练）。读完本文，你将理解三者的区别与适用场景，并能在 claude-code-best-practice 仓库中亲手体验一个真实的weather-agent+weather-fetcher组合，为后续搭建自己的可复用工作流打下基础。

为什么需要三个层次？

你已经装好了 Claude Code（Day 0 已覆盖node --version与claude --version的验证、以及 Claude.ai 账号 / API Key 两种登录方式）。现在的问题是：你该如何控制 Claude 干活的方式？

把使用 Claude Code 想象成"雇人办事"，三个层次对应三种不同力度的控制：

1. Prompting= 向路人问路，得到什么答案全凭运气；
2. Agents= 雇一个"永远按固定方式做事"的专家；
3. Skills= 这位专家还接受了针对特定任务的专项训练。

每一层都比上一层多控制一个变量：先是"问什么问题"，再是"谁来回答"，最后是"他具体怎么回答"。下面逐层展开。

Level 1：Prompting（直接提问）——入门的第一步

打开终端输入claude，你就进入了一次对话。试着输入：

what is the weather in Karachi?

Claude 会给出答案——但它是怎么得出答案的，完全不可预测。它可能：

• 从训练数据里检索（数据可能已过时）；
• 联网搜索（如果 Web 工具可用）；
• 给出一个通用回答而非实时数据。

对快速、一次性的问题，这完全够用。Prompting 适合以下场景：

• 询问代码库相关问题（"这个文件是做什么的？"）；
• 撰写或改写文档（"把这封邮件改得更专业一些"）；
• 头脑风暴（"给这个活动想 5 个主题文案"）；
• 概念解释（"用一个非程序员也能懂的方式解释这条报错"）。

Prompting 的局限

核心局限是方法不可复现：每次问"今天天气如何"，Claude 都可能用不同的数据源、不同的方式去获取——甚至根本不取真实数据。没有机制保证它两次使用同一来源、同一方法。当你需要稳定、可靠的结果时，仅靠 Prompting 是不够的，这就引出 Level 2。

Level 2：Agents（专家）——把"怎么干活"固定下来

Agent 就是让 Claude 扮演一个特定角色，相当于给它一个"职位头衔"。

🧠厨房类比：没有 Agent 时，你走进一个陌生厨房大喊"做份意面！"——听到的人可能煮出方便面，也可能端出一桌五道菜的意大利大餐。而雇一位意面主厨，他的岗位描述写着："永远用新鲜食材、永远煮到 al dente、永远用同一种摆盘。"于是每一次你都知道自己会得到什么。

同一思路套用到 Claude：

没有 Agent：你问 "What's the weather in Dubai?"，它可能查训练数据、可能联网、也可能凭记忆猜，你无从得知。

有 Agent：weather-agent有一份清晰的岗位描述："永远查询 Open-Meteo API 获取迪拜天气，永远以指定格式返回温度。"同样的问题，同样的方法，每次如此。

仓库中的真实示例：weather-agent

这个仓库就实现了一个weather-agent，它的全部工作就是获取迪拜的实时温度（源码见 .claude/agents/weather-agent.md）。它与纯 Prompting 的差异一目了然：

这个 Agent 的真实配置（来自 implementation/claude-subagents-implementation.md）长这样：

--- name: weather-agent description: Use this agent PROACTIVELY when you need to fetch weather data for Dubai, UAE. This agent fetches real-time temperature from Open-Meteo using its preloaded weather-fetcher skill. allowedTools: - "Read" - "Skill" model: sonnet color: green maxTurns: 5 permissionMode: acceptEdits memory: project skills: - weather-fetcher ---

值得注意的字段：

• description：用"PROACTIVELY"提示词时，Claude 会在合适时机自动调用该 Agent——这是把"职责"固定给它的关键；
• allowedTools：限定该 Agent 只能使用Read和Skill两个工具，缩小动作范围以换取可预测性；
• skills：预加载weather-fetcher技能（下一节详解）；
• model/maxTurns/memory：分别控制模型档位、最大轮数与记忆范围。

关于 Agent frontmatter 的 16 个完整字段说明，见仓库的 best-practice/claude-subagents.md。

核心收获

Agent 带来的核心价值是可预测性（predictability）：同一个问题 → 同一种方法 → 同一种质量。Agent 的优势不在于"更聪明"，而在于一致。

Level 3：Skills（训练）——把"具体怎么做"写成说明书

Skill 是 Agent（或 Claude 本身）可以调用的一项具体能力。

🧠培训手册类比：新员工入职时有职位（Agent），也要通过一系列培训模块——怎么用 CRM、怎么写方案、怎么开站会。每个培训模块就是一个Skill。职位决定他"是什么"，技能决定他"能具体做什么"。

回到天气例子。weather-agent拥有一个叫weather-fetcher的技能（源码见 .claude/skills/weather-fetcher/SKILL.md）：

• Agent（weather-agent）= 职位叫"天气播报员"的人；
• Skill（weather-fetcher）= 关于"如何获取天气数据"的具体训练。

技能内容包含精确指令（来自 implementation/claude-skills-implementation.md）：

--- name: weather-fetcher description: Instructions for fetching current weather temperature data for Dubai, UAE from Open-Meteo API user-invocable: false ---

1. Fetch Weather Data: Use the WebFetch tool to get current weather data - Celsius URL: https://api.open-meteo.com/v1/forecast?latitude=25.2048&longitude=55.2708&current=temperature_2m&temperature_unit=celsius - Fahrenheit URL: https://api.open-meteo.com/v1/forecast?latitude=25.2048&longitude=55.2708&current=temperature_2m&temperature_unit=fahrenheit 2. Extract Temperature: From the JSON response, extract `current.temperature_2m` 3. Return Result: Return the temperature value and unit clearly.

注意其中的user-invocable: false：这个技能不出现在/命令菜单里，它只作为领域知识预加载进weather-agent的上下文，供 Agent 在内部遵循——这正是"技能服务于 Agent"的典型写法。

为什么要分离 Agent 和 Skill？

因为一个 Agent 可以拥有多个 Skill，一个 Skill 也可以被多个 Agent 复用。例如你可以创建：

• 一个daily-report-agent（每日总结 Agent）；
• 它同时使用weather-fetcher（天气）+calendar-reader（日程）+email-summarizer（邮件摘要）三个技能。

Skill 是可复用的积木，Agent 是使用积木的人。这个仓库还演示了第二种技能模式：weather-svg-creator（见 .claude/skills/weather-svg-creator/SKILL.md）——它不预加载进任何 Agent，而是由命令通过 Skill 工具直接调用，用于把温度渲染成 SVG 天气卡片。两种模式的对比：

Skill frontmatter 的 20 个完整字段（name、description、when_to_use、arguments、disable-model-invocation、context: fork等）见仓库的 best-practice/claude-skills.md。

串起来看：三层模型全景图

Level 1: PROMPTING You → "What's the weather?" → Claude figures it out somehow (unpredictable method) Level 2: AGENTS You → Weather Agent → Always uses the same approach (predictable method) Level 3: SKILLS You → Weather Agent → Uses weather-fetcher skill (predictable method with specific instructions)

每一层都增加一档控制力：

进阶：仓库中的完整工作流（Command → Agent → Skill）

weather-agent和weather-fetcher并不是孤立的。在本仓库里，它们共同组成了一个完整的编排示例：Command → Agent → Skill，入口是/weather-orchestrator命令（见 .claude/commands/weather-orchestrator.md），完整文档在 orchestration-workflow/orchestration-workflow.md。

一次完整的执行过程如下（仓库文档记录的示例执行）：

Input: /weather-orchestrator ├─ Step 1: 询问：Celsius or Fahrenheit? → 用户回答 Celsius ├─ Step 2: Agent 工具 → weather-agent │ ├─ 预加载 Skill: weather-fetcher（领域知识） │ ├─ 从 Open-Meteo 获取 → 26°C │ └─ 返回: temperature=26, unit=Celsius ├─ Step 3: Skill 工具 → weather-svg-creator │ ├─ 生成: orchestration-workflow/weather.svg │ └─ 写入: orchestration-workflow/output.md └─ 输出: 单位、温度、SVG 与摘要文件位置

这个示例完美体现了三层的分工原则：

1. Command 做编排：处理用户交互（询问摄氏度/华氏度）、依次调用 Agent 和 Skill；
2. Agent 负责取数：靠预加载的weather-fetcher技能稳定地从 Open-Meteo 拿到数据；
3. Skill 负责产出：weather-svg-creator独立把数据渲染成可视化的 SVG 天气卡片。

可见 Day 1 的三层模型并不是抽象概念——它就是这个仓库真实可运行的架构。仓库根目录的 CLAUDE.md 与 README.md 也把这条工作流列为"如何上手"的第一示例。

怎么创建自己的 Agent 和 Skill？

在终端运行claude后，你可以：

• 使用/agents命令创建自定义 Agent，它会生成带 YAML frontmatter 的 Markdown 文件到.claude/agents/<name>.md；
• 也可以直接让 Claude 帮你创建——它会生成.claude/skills/<skill-name>/SKILL.md这类文件。Agent 文件的最小骨架是：

--- name: my-agent description: PROACTIVELY use this agent when ... skills: - my-skill ---

而 Skill 文件的最小骨架是：

--- name: my-skill description: What this skill does --- Instructions for what the skill does.

下一步建议

Day 1 的核心建议是：先花时间待在 Level 1——直接在终端里多和 Claude 对话、多提问。用得越多，你越能敏锐地察觉哪些任务值得升级成 Agent（甚至再加一层 Skill）。当你遇到"同一个问题需要反复用同一种方法回答"的场景时，就是创建 Agent 的信号；当你发现"某个方法本身值得写成固定说明"时，就是提炼 Skill 的信号。

继续学习可回到 Day 0 安装教程，或查阅仓库中更深入的最佳实践文档：Agents 最佳实践、Skills 最佳实践，以及完整的 编排工作流示例。

• 文档
• 教程
• AI 技能