陈冠男Claude 的完整工作流，用一句话概括就是：提示词决定模型怎么想，Projects 决定上下文放在哪，Skills 决定重复步骤怎么复用，连接器决定数据从哪来。很多人把这四个功能当成四个独立按钮去学，结果提示词会写几句、Project 建了一堆、Skill 目录也放好了，但真正干活时还是靠手动复制粘贴。
这篇文章把四条线串起来讲一遍，覆盖提示词结构、Projects 知识库、Skill 文件格式、连接器授权流程，并给出一套可以先照着复现的步骤。适合开发者、内容创作者、研究者和需要长期维护团队知识库的人。我建议的学习顺序是：先写稳一条提示词，再开 Project，最后再上 Skills 和连接器。下面按这个顺序展开，所有配置和判断标准都是实际使用时会遇到的细节。
1. 先看四个模块的分工，不要一上来就开连接器
1.1 提示词是地基，其他功能都在给提示词“喂材料”
很多人以为提示词只是在对话框里写一段话，其实真正的提示词工程有三层作用。
第一层是控制输出格式。让 Claude 输出 JSON、Markdown 表格、会议纪要还是代码审查意见，完全取决于提示词里的约束。
第二层是控制思考方式。你可以让 Claude 先拆解任务再给出结论，也可以让它直接给答案，还可以要求它列出假设和风险。
第三层是稳定复现。一个好的提示词应该做到：同一个输入，跑三次，结果差异不大。如果做不到，问题往往在提示词，而不在模型本身。
Projects、Skills、连接器本质上是给提示词服务的。Projects 提供稳定的背景材料，连接器拉外部数据，Skills 让 Claude 能调用脚本完成固定步骤。地基没有打牢就上 Skills 和连接器，问题会叠加出现。
1.2 四个模块的定位差异
| 模块 | 解决的问题 | 适合场景 | 学习门槛 |
|---|---|---|---|
| 提示词 | 让输出更准确、更稳定 | 所有对话、写作、分析、代码任务 | 低，但需要反复迭代 |
| Projects | 沉淀项目上下文，避免重复贴背景 | 同主题多次会话、长期项目、团队知识库 | 低，界面操作 |
| Skills | 把重复步骤封装成可执行技能包 | 文档处理、批量转换、固定流程 | 中，需要文件结构和脚本基础 |
| 连接器 | 对接外部数据源，减少复制粘贴 | 读取 GitHub 仓库、Google Drive、Notion 数据 | 中，涉及授权和权限 |
如果只是日常聊天和写文章，提示词加 Projects 足够。如果做开发，Skills 值得花时间。如果要在团队里长期处理业务数据，连接器才是关键。
1.3 推荐的启动顺序
先写提示词。把一个高频任务做到“格式稳定、内容可用”。
再建 Project。把背景知识、角色设定、输出规范沉淀到 Project Instructions 和知识库里。
然后试 Skills。挑一个重复性最高、规则最明确的任务，封装成技能包。
最后连数据。在 Project 里接入连接器，让 Claude 直接读取外部文件。
顺序反了会很痛苦。我见过有人先接好了 GitHub 连接器，结果提示词写得不够清晰，连接器拉进来的代码反而被模型理解错了方向。问题根本不在连接器，而是前置指令没做好。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 提示词工程：先把“指令”和“材料”分开
2.1 提示词的基本骨架
一段稳定的提示词通常包含五部分：身份、任务、背景、输出格式、约束条件。
身份解决“模型站在什么角度说话”。任务解决“这一步到底要做什么”。背景解决“处理的对象是什么”。输出格式解决“结果长什么样”。约束条件解决“绝对不能做什么”。
一个通用模板是：
code复制<role>
你是一名资深 Python 开发者，负责代码审查。
</role>
<task>
请审查下面的代码，按可读性、错误处理、性能三个维度给意见。
</task>
<input>
[在这里粘贴代码]
</input>
<output>
- 问题列表：每条带上代码行号
- 严重程度：高/中/低
- 修复建议：一句可执行描述
</output>
Anthropic 的提示词文档里特别强调，用 XML 标签把不同语义的部分分开。原因是 Claude 对结构化内容理解更稳定，指令是指令，数据是数据，混淆的概率会明显降低。
2.2 为什么用 XML 标签而不是自然段落
很多人习惯把需求写成一整段话，例如“帮我看看下面这段代码有什么问题，重点关注可读性和性能，最好用表格列出来，代码在这里”。
这样写不是不行，而是边界模糊。模型需要自己判断哪里是任务、哪里是输入、哪里是格式要求。一旦输入内容变长，或者任务本身包含多个步骤，模型就容易抓错重点。
用 XML 标签之后，语义边界被显式标记出来。指令归指令，输入归输入，示例归示例。这就像给文章加了标题层级，读者不用猜你哪句话是重点。
在 API 场景里，还可以把长期约束放进 system 字段，把具体任务放进 user 内容。system 优先于 user，适合放角色、语气、禁止事项这些不想被覆盖的规则。
2.3 用示例和步骤约束提高稳定性
如果提示词里只有一个任务描述，没有示例，Claude 第一次可能输出 A 格式，第二次可能输出 B 格式。解决方式很简单：给一到三个 few-shot 示例。
举例：
code复制<example>
输入：登录后白屏
输出：{"category": "bug", "reason": "页面渲染异常导致白屏"}
</example>
<example>
输入：希望增加深色模式
输出：{"category": "feature", "reason": "用户提出界面外观改进需求"}
</example>
给完示例之后，Claude 会倾向于跟着示例的格式走。示例不在多，而在明确。
如果需要模型做多步推理，可以明确要求“先列出推理步骤，再给结论”。但要注意，不是所有任务都需要展示推理过程。如果你只关心最终结果，可以加一句“只输出结论，不要展示推理过程”，避免回答越来越长。
2.4 参数怎么调，先看你缺的是格式还是内容
| 参数 | 取值范围 | 适用场景 | 说明 |
|---|---|---|---|
| temperature | 0 到 1 | 代码生成、数据提取用低值；创意写作用高值 | 低值输出更稳定，高值更随机 |
| max_tokens | 按模型上限 | 需要长输出时调大 | 输出截断不代表模型跑错 |
| top_p | 0 到 1 | 通常保持默认 | 与 temperature 不冲突，不建议同时大幅调整 |
| system | 一段文本 | 放长期约束 | 比 user 里的指令更稳定 |
很多人在输出不稳定时第一反应是调低 temperature，然后发现没用。原因是格式问题通常由指令不清晰导致，不是随机性导致。先检查提示词里有没有明确输出格式，有没有给示例。如果都有问题还在，再考虑调参数。
2.5 中英双语提示词到底该怎么写
标题里有“中英双语”，并不是说整篇文章都要翻译成英文。对 Claude 来说，中英双语的实用价值在于关键指令和格式约束可以中英并列，减少歧义。
一个面向双语团队的提示词可以这样写：
code复制你是技术文档整理助手。
You are a technical documentation assistant.
整理下面的会议纪要，输出为 Markdown 表格。
Convert the meeting notes below into a Markdown table.
约束 / Constraints:
- 只输出 Markdown 表格，不要附加说明。
- Output only the Markdown table, no extra commentary.
- 对每项决议标注负责人和截止日期。
- For each decision, include the owner and due date.
如果只是你自己在中文环境使用，保留中文即可。不要为了双语而双语，提示词越长，占用上下文越多，必要的信息反而可能被淹没。双语并列适合用来让模型区分“哪些是硬性格式要求”，不适合用来堆砌无意义重复。
如果走 API，完整的调用结构大致是：
bash复制curl https://api.anthropic.com/v1/messages \
--header "x-api-key: $ANTHROPIC_API_KEY" \
--header "anthropic-version: 2023-06-01" \
--header "content-type: application/json" \
--data '{
"model": "claude-sonnet-4-20250514",
"max_tokens": 1024,
"system": "你是代码审查助手。只输出 Markdown 表格。",
"messages": [
{"role": "user", "content": "审查下面的代码：..."}
]
}'
注意 model 字段只是示例，实际要用你账号里可用的模型名。如果先确认依赖版本和模型列表，能少踩很多坑。
3. Projects 实操：把零散会话变成有上下文的工作空间
3.1 创建 Project 前先想清楚用途
Project 不是聊天文件夹，而是一个“有常驻指令和知识库的工作空间”。新建会话时，Claude 会自动带入 Project Instructions，并允许你检索 Project 中的文档。
创建入口一般在 Claude 网页端左侧栏的 Projects，点 New Project 后填写名称和指令。命名我建议按“目标”而不是按“时间”。例如“毕业论文写作”“竞品分析报告”“前端组件库文档整理”，比“2025年5月记录”更有用。
建太多 Project 也会分散注意力。同一个项目下，先建一个，跑一段时间发现问题，再考虑拆分。
3.2 Project Instructions 写什么，不写什么
Project Instructions 相当于这个 Project 的常驻 system prompt。每次在此项目的会话里，Claude 都会看到这段指令。
适合放的内容：
- 项目目标：一句话说清楚这个项目要产出什么。
- 固定角色：你是技术顾问、内容编辑还是代码审查者。
- 输出规范：回答必须包含哪些部分，禁用哪些表达。
- 背景信息：技术栈、客户背景、文档层级等不容易变化的信息。
不适合放的内容：
- 大段代码或全文内容。这类应该放到知识库里。
- 频繁变动的临时要求。例如“今天先分析第一季度数据”，应该写在当前对话里。
- 过于宽泛的口号式描述。例如“做一个高效靠谱的助手”，模型无法据此判断你的真实需求。
一个简单的模板：
code复制你是“售后服务知识库整理小组”的长期助手。
每次回答前，先列出你使用的知识库文档名称。
输出结构固定为：
1. 结论
2. 依据（引用文件名或章节）
3. 待确认事项
不要输出与售后流程无关的方案。
3.3 知识库上传之后的正确使用方法
在 Project 设置里可以上传文档。支持哪些格式取决于当前客户端，常见有 PDF、Word、Markdown、TXT 等。
上传之后，Claude 不会自动把全部内容塞进上下文，而是在回答时按需检索。所以有一个很常见的误解：上传了文档，结果 Claude 没答出来，就以为功能坏了。实际上，更可能是问题太宽泛，检索不到相关内容。
更稳妥的做法是在提问时明确指定文档。例如：
code复制请先阅读知识库中的“01-需求文档.md”，然后列出里面所有未确定事项。
这里的判断标准是：Claude 的回答是否引用了具体文件名或章节。如果回答里出现“根据《01-需求文档.md》第 3 节”，说明检索命中了。如果回答泛泛而谈，就换更具体的问题，或者直接要求它先列出知识库里有哪些文档。
3.4 一个 Project 拆不拆，关键看任务之间是否共享上下文
拆 Project 的标准不是任务数量，而是任务之间是否共享同一套背景知识和输出规范。
例如，你同时在维护“产品周报”和“代码仓库文档”，这两个任务的背景、输出格式、目标读者差别很大，拆成两个 Project 更合适。但如果你只是做“量化比赛项目”，从需求分析到数据清洗到模型调参都用同一套项目背景，那一个 Project 就够了。
拆得太细会导致知识库文档分散，每次都要重新建立上下文。不拆则容易让背景文档互相干扰，Claude 可能把 A 项目的文档内容当成 B 项目的上下文。
最简单的判断方式是问自己：如果连续开了两个会话，第一个会话背景和第二个会话背景完全无关，就拆；如果只是进度不同，不拆。
3.5 Projects 的容量和使用边界
不同账号套餐能使用的 Project 数量和知识库容量不一样。不要在高容量场景下盲目依赖免费额度。
另外，Project Instructions 越长，每轮对话用于处理任务的上下文就越少。指令写得像小作文，Claude 会把注意力放在“遵守指令”上，而不是“解决当前任务”。一般建议指令控制在 300 字以内，知识放文档，角色和输出规范留在指令里。
如果发现回答速度变慢，或输出变得简短，优先检查 Project Instructions 是否太长，知识库里有没有塞入大量无关文件。
4. Skills 工作流：从官方技能仓库到自定义技能包
4.1 Skills 和普通提示词的最大区别
Skills 是近期比较值得关注的机制，中文常称为技能。它和提示词的区别在于：提示词只是一段文字，Skills 是“说明文件加可执行脚本”的组合。
一个技能包通常长这样：
code复制skills/
└── pdf-utils/
├── SKILL.md
├── extract_text.py
└── requirements.txt
SKILL.md 里面写清楚这个技能什么时候用、怎么用。脚本负责具体操作，比如提取 PDF 文本、批量重命名、格式化时间等。Claude Code 在对话中遇到合适任务时，会读到 SKILL.md，然后按里面的步骤执行脚本。
这样设计可以解决一个核心问题：复杂的固定流程不需要每次都在提示词里写一遍。你把步骤写进 SKILL.md，脚本放好，之后每次触发技能，模型自己会按流程走。
4.2 跑 Skills 之前先确认环境
Skills 主要面向 Claude Code 用户。你至少需要：
- 已经安装并登录的 Claude Code，能够通过命令行进入对话界面。
- 一个项目目录，用于存放技能包和输入输出文件。
- 技能涉及的运行时。例如脚本用 Python 就提前装好 Python 和依赖，用 Node 就装好 Node。
不需要我在这里给出具体安装命令，因为不同系统的安装方式有差异。按官方文档把 Claude Code 装好，进入项目目录后能看到命令行提示符，再继续下一步。
如果只是网页版 Claude 聊天，先跳过 Skills。界面端有没有技能入口、叫什么名字，要看你使用的客户端版本。这里不假设所有版本都有，只讨论 Claude Code 场景。
4.3 引入官方技能仓库
官方有公开的 skills 仓库，里面包含一些现成技能，例如文档格式转换、PDF 处理、PPT 生成等。
使用时先把对应技能目录下载到你的项目里。目录结构通常以技能名为文件夹，内部包含 SKILL.md 和辅助脚本。然后在项目的 CLAUDE.md 中引用技能目录：
code复制@skills ./skills
或者直接把技能目录放到 .claude/skills/ 下。具体引用方式以你使用的 Claude Code 版本为准。
验证方式很简单：选一个最小的文件跑一次。例如给一个 PDF 技能，先拿一页测试文档，在对话里说“用 pdf 技能提取这个文件的内容”，看它是否正确调用脚本并生成输出。不要一上来就塞一个几百页的 PDF。
4.4 写一个最简单的自定义 Skill
自己写技能包时，SKILL.md 是核心。基本结构包含 YAML 头部和正文说明。
下面是一个把时间格式统一成 YYYY-MM-DD HH:mm 的技能示例：
markdown复制---
name: timestamp-formatter
description: 当用户需要把多种日期时间写法统一为 YYYY-MM-DD HH:mm 格式时使用。适合处理导出日志、表格中的时间字段。
---
# 时间格式化
处理逻辑：
1. 读取输入文件。
2. 调用 `format_time.py` 脚本处理。
3. 输出到指定目录，文件名加 `formatted_` 前缀。
对应脚本可以写成：
python复制#!/usr/bin/env python3
import re
import sys
from pathlib import Path
def format_datetime(text: str) -> str:
# 将 2024/1/5 10:2 格式统一为 2024-01-05 10:02
return re.sub(
r"(\d{4})/(\d{1,2})/(\d{1,2}) (\d{1,2}):(\d{1,2})",
lambda m: (
f"{m.group(1)}-{int(m.group(2)):02d}-{int(m.group(3)):02d} "
f"{int(m.group(4)):02d}:{int(m.group(5)):02d}"
),
text,
)
if __name__ == "__main__":
input_file = Path(sys.argv[1])
output_file = Path(sys.argv[2])
output_file.write_text(format_datetime(input_file.read_text()), encoding="utf-8")
脚本和 Claude 之间怎么传参数，由你在 SKILL.md 里约定。通常的做法是：让 Claude Code 构造命令，传入输入文件和输出文件路径。
需要注意 name 使用短横线命名。description 要写清“什么场景触发”，不要写“一个高可用工具”这种空话。触发描述越具体，Claude Code 越容易在你需要时调用技能。
4.5 Skills 批量处理时的边界
单条文件跑通后，再考虑批量。
批量场景常见的坑有三个：
第一，输出文件名覆盖。多个文件都输出成同一个名字，后跑的结果会覆盖前面的。建议文件名加入原文件前缀或时间戳。
第二，失败任务没有日志。脚本要有异常处理和日志输出，否则某个文件编码有问题时，你只能看到没结果，不知道哪一步失败。
第三，依赖环境不一致。SKILL.md 里写的依赖版本如果和当前环境不匹配，脚本会报错。批量跑之前，先另开一个空目录，用一份干净依赖环境做冒烟测试。
注意：Skills 不是“装了就自动生效”。它的核心是让 Claude Code 在合适场景下读到 SKILL.md，而不是把脚本放在目录里就算完。第一次使用一定要在对话里明确触发一次，确认模型能正确调用。
5. 连接器工作流：把外部数据接进对话，但不等于绕过权限
5.1 连接器能做什么，不能做什么
连接器解决一个非常实际的问题：数据源不在 Claude 里面，每次都要靠复制粘贴导入，效率低且容易出错。
接通连接器之后，Claude 可以读取外部系统里你有权限访问的内容。常见的有 GitHub 仓库文件、Google Drive 文档、Notion 页面、Slack 频道讨论等。
但连接器不是万能后台。它有几个明显边界：
- 它只能读取你当前账号有权访问的数据。
- 它通常不能替你在外部系统执行所有管理操作。
- 连接器数据会进入对话上下文，敏感信息需要你自行判断是否适合传入。
不同账号类型开启的连接器范围不同，具体以你登录后的设置面板为准。
5.2 常见连接器与典型用途
| 连接器 | 典型用途 | 授权方式 |
|---|---|---|
| GitHub | 读取代码文件、Issue、仓库信息 | OAuth 授权，可控制仓库范围 |
| Google Drive | 检索并读取文档、表格、幻灯片 | OAuth 授权 |
| Notion | 读取页面和数据库内容 | OAuth 授权 |
| Slack | 检索公开频道讨论内容 | 管理员审批配合 OAuth |
接入入口通常在账号设置里的连接器或集成面板，也可能在对话框的 @ 菜单中。不同客户端版本差异较大，最稳妥的方式是在对话框输入 @ 或打开设置面板看已接入的数据源列表。
5.3 授权时保留最小范围
授权连接器时，一定要给最小权限。
以 GitHub 为例，如果只是分析某个仓库的代码，就只授权那一个仓库，不要顺手授权整个账号的读写权限。Google Drive 同理，选择指定文件夹，不要给全部文件。
原因有三层：一是数据安全，连接器读到的内容会进入模型上下文，暴露面越小越好；二是输出稳定性，数据源太乱会让 Claude 检索到无关内容，拉低结果质量；三是管理成本，权限越细，出问题时越容易定位。
在团队场景，建议先和管理员确认哪些数据源可以接、哪些必须关。不要每个人都去开一遍企业级数据源。
5.4 在对话里引用连接器资源的写法
连接器启用后，在对话框里输入 @，通常会弹出数据源选择列表。选到一个具体文件或仓库后，再输入指令。
可以这样组合：
code复制请基于 @github owner/repo 中的 docs/API.md，写一个接口测试计划。
请分析 @google-drive 2025年Q2运营报表 中的关键指标，并列出三条异常波动。
请从 @notion 产品需求文档 中提取所有待办事项，按优先级排序。
判断连接器是否真正生效，看两点：一是 Claude 是否引用了具体文件名或路径；二是回答里是否能复现外部数据的细节。如果只是泛泛而谈，没有引用具体内容，说明检索没有命中。
5.5 连接器加 Project 加 Skills 的完整链条
把四件事串起来之后，一个稳定的工作流可能是：
- 在 Project 里写好长期指令，定义数据来源和输出规范。
- 用连接器把外部数据拉进对话，让 Claude 直接读取真实文件。
- 用提示词控制分析思路，例如先提取指标、再找异常、后给建议。
- 遇到固定处理步骤时调用 Skills，例如统一日期格式、批量生成 Markdown 表格。
注意：连接器读取到的数据会进入对话上下文，不要在连接器里挂载包含密钥、内部口令或敏感身份证号的文件。即使文件本身有权限保护，也应该先评估是否适合让 Claude 读取。
6. 四个常见问题的排查顺序
6.1 提示词好像没有效果
现象：输出格式不稳定，或者某条指令明明写在提示词里，模型没有遵守。
排查顺序：
- 先看输出格式是否和指令一致。如果不一致，不是调参问题，是指令冲突或表述不清晰。
- 检查任务说明是否自然段落混在一起。用 XML 标签把任务、输入、示例分开。
- 检查你是否给了两个互相矛盾的约束。例如“要详细说明”和“限制在 100 字以内”同时出现。
- 检查 temperature 是否过高。代码和结构化输出建议 0 到 0.3。
- 最后再看示例。给一个输出示例往往比加十条规则更有效。
经验是：不要第一次就重写整个提示词。先在新会话里保留原始输入，逐句删减，定位改变行为的关键句。
6.2 Project 回答没有使用知识库内容
现象：你上传了文档，但 Claude 回答时不引用文档，内容像凭空生成。
排查顺序：
- 确认当前会话是在对应 Project 下新建的，而不是普通聊天里开的。
- 确认知识库文件确实上传成功，且格式受支持。
- 在提问时明确要求“先阅读知识库中的 XXX”，不要只给一个模糊问题。
- 让 Claude 先列出它找到的文件清单，再回答。
- 如果换了文档版本，旧内容还在，新内容没读进去，就关闭旧会话，开一个新会话验证。
很多情况下不是知识库没生效，而是提问没有触发检索。模糊提问会让模型直接凭常识回答。
6.3 Skill 没有触发或脚本报错
现象：你说“用技能处理”，但 Claude 没有读取 SKILL.md，或者读取了但脚本运行失败。
排查顺序：
- 检查技能目录是否被 CLAUDE.md 正确引用。
- 检查 SKILL.md 的 name 和 description 是否具体，是否包含你能说出的触发词。
- 检查脚本路径和参数约定。SKILL.md 里如果写了
python xx.py, 但脚本实际不在该路径，就会失败。 - 检查脚本依赖。缺少依赖时先看报错信息，再决定安装依赖还是换运行时。
- 检查文件编码。中文内容如果出现乱码，优先确认输入文件是 UTF-8。
一次只跑一个文件，成功后再跑第二个。如果连续失败，先把日志输出到单独目录，从中找共性。
6.4 连接器找不到文件
现象：连接器已经授权，但对话框里搜不到目标文件。
排查顺序：
- 先到外部数据源里确认文件真实存在，路径正确。
- 检查授权范围是否包含了该文件所在仓库或文件夹。
- 检查文件名拼写，尤其是空格、连字符和大小写。
- 确认搜索语法。有的连接器支持按文件名搜索，有的支持按路径搜索，使用方式不一样。
- 在浏览器中刷新外部系统的缓存，再回到 Claude 里重新授权。
如果反复找不到，不要一直试。先手动复制一份文件到已授权的目录，确认连接器能读到，再排查原目录的权限问题。
7. 最后想说的实操建议
组合逻辑比单个功能更重要。提示词管“怎么说”，Projects 管“上下文怎么沉淀”，Skills 管“重复步骤怎么复用”，连接器管“数据从哪里来”。
真正用顺之后，一个稳定的流程应该是：Project 先定义背景和输出规范，连接器拉数据，提示词控制分析方式，遇到固定处理步骤就调用 Skill。
我更建议先把单任务跑稳，再拼流程。第一次尝试时，选一个最常用、最不复杂的任务，把四步完整走一遍，然后回头清理指令里的废话和重复约束。踩过几次坑之后会发现，多数问题不是模型不聪明，而是上下文、输入格式和权限没有提前理清楚。
如果只是学习，默认参数和少量文档够用。如果要长期维护生产流程，日志、输出命名、失败重试和目录权限要提前设计好，否则等项目跑起来再补，成本会高很多。