# Claude Code提示词工程与四层定制决策：从高效交互到架构级扩展
> **学习目标**：掌握 Claude Code 的提示词交互模式与四层定制化体系（Rules → Skills → Subagents → MCP），学会在"随手一问"与"系统化扩展"之间做出正确决策，将 Claude Code 从聊天工具升级为工程化开发平台。
>
> **适用人群**：已有 Claude Code 基础使用经验，希望提升交互效率和定制化深度的开发者；正在评估 Claude Code 扩展架构选型的技术团队负责人。
---
## 一、核心认知：提示词工程≠上下文工程
2026年，AI编程领域最核心的范式转变是从 **Prompt Engineering** 到 **Context Engineering**。两者并非替代关系，而是分层互补：
| 维度 | 提示词工程 (Prompt Eng.) | 上下文工程 (Context Eng.) |
|------|------------------------|------------------------|
| 关注点 | 单次对话怎么说清楚 | 系统性管理模型的所有输入信息 |
| 范围 | 一条消息的措辞与结构 | CLAUDE.md + Rules + Skills + MCP + Hooks |
| 时效性 | 即时、单次有效 | 持久、跨会话生效 |
| 类比 | 写一封好邮件 | 搭建整个邮件系统 |
**Claude Code 的独特之处**在于它提供了从提示词到上下文工程的完整光谱——你可以在对话中直接用自然语言描述需求，也可以通过四层定制体系将知识固化到系统深处。
```mermaid
graph LR
A[随手提问
Ad-hoc Prompt] --> B[规则固化
Rules/CLAUDE.md]
B --> C[技能封装
Skills]
C --> D[子代理委派
Subagents]
D --> E[外部工具
MCP Servers]
style A fill:#e1f5fe
style B fill:#b3e5fc
style C fill:#81d4fa
style D fill:#4fc3f7
style E fill:#29b6f6
```
---
## 二、高效提示词交互：七种核心模式
### 模式1：精确指令模式（Precise Instruction）
最基础也最容易被忽视的模式。关键原则：**给 Claude Code 足够的约束，而不是足够多的自由**。
```markdown
# ❌ 低效写法
帮我改一下这个函数，让它更快
# ✅ 高效写法
重构 src/utils/parser.ts 中的 parseConfig() 函数：
1. 当前瓶颈：正则匹配在 10MB+ 文件上 O(n²) 复杂度
2. 目标：流式解析，内存占用 < 50MB
3. 约束：保持 API 签名不变，保留现有测试用例
4. 参考：可使用 Node.js 的 readline 模块逐行处理
```
**要点**：
- 指定文件路径（Claude Code 能直接读取，减少猜测）
- 说明当前问题和目标（而不仅仅是"改好"）
- 列出硬约束（保持 API 兼容等）
### 模式2：上下文引用模式（Context Reference）
用 `@` 符号主动将文件拉入上下文窗口，避免 Claude Code 自行搜索浪费 Token：
```markdown
# 查看 @src/types.ts 中的 User 类型定义，
# 然后基于它改写 @src/api/handlers/user.ts 中的 createUser 函数，
# 确保 input validation 使用 zod schema 并和 User 类型保持同步
```
**适用场景**：多文件关联修改、需要类型同步的重构、跨模块引用更新。
### 模式3：计划先行模式（Plan-First）
对于超过 3 个文件或涉及架构变更的任务，强制 Claude Code 进入 Plan Mode：
```markdown
# 方式1：使用 Shift+Tab 切换到 Plan Mode 后输入需求
# 方式2：在提示词中明确要求
我需要将当前的 REST API 迁移到 GraphQL。请先制定迁移计划：
1. 列出需要变更的所有文件
2. 标注依赖关系和迁移顺序
3. 识别风险点
不要写任何代码，只给计划。
```
**为什么重要**：Plan Mode 下 Claude Code 只分析不修改，节省大量 Token 消耗，同时让你在实施前审查方案。
### 模式4：渐进细化模式（Iterative Refinement）
不追求一次性完美，而是通过多轮对话逐步收敛：
```
第1轮：写一个基本的 Express 中间件，负责 JWT 验证
第2轮：加上 token 黑名单机制，用 Redis 存储
第3轮：添加速率限制，同一个 token 每分钟最多 60 次请求
第4轮：写集成测试，覆盖正常/过期/黑名单/限流四种场景
```
**核心原则**：每轮只增加一个关注点，让 Claude Code 聚焦完成。
### 模式5：示例驱动模式（Example-Driven）
给 Claude Code 具体的输入输出示例，比抽象描述高效 10 倍：
```markdown
为以下数据结构写一个 TypeScript 格式化函数：
输入示例：
{ "user_name": "张三", "create_at": "2026-06-12T08:30:00Z", "is_active": 1 }
期望输出：
{
"displayName": "张三",
"createdAt": "2026年6月12日 08:30",
"active": true
}
规则：
- snake_case → camelCase
- ISO 8601 → 中文日期格式
- 0/1 → boolean
```
### 模式6：角色赋予模式（Role Assignment）
让 Claude Code 扮演特定角色，改变其输出风格和关注点：
```markdown
# 以安全审计员的角色审查以下代码：
@src/auth/login.ts
关注点：
- SQL 注入风险
- XSS 攻击面
- 密码处理流程
- Session 管理漏洞
输出 OWASP Top 10 对照检查清单。
```
### 模式7：约束清单模式（Constraint Checklist）
对复杂任务，用清单方式明确所有约束：
```markdown
实现一个文件上传 API 端点 /api/upload：
硬约束：
- [ ] 文件大小 ≤ 10MB
- [ ] 仅允许 .pdf, .docx, .png
- [ ] 存储到 S3 兼容对象存储
- [ ] 返回唯一文件 ID (UUID v4)
- [ ] 异步处理，不阻塞 HTTP 响应
性能要求：
- [ ] 单文件上传 < 2s (100MB 带宽)
- [ ] 并发 100 无异常
代码规范：
- [ ] TypeScript strict mode
- [ ] 使用项目现有的 Logger
- [ ] 遵循 @src/api/patterns/ 中的 Handler 模式
```
---
## 三、四层定制体系全景图
Claude Code 提供四个扩展层次，从轻到重，对应不同的复用频率和复杂度：
```mermaid
graph TB
subgraph "第一层：规则层 Rules"
R1[CLAUDE.md
项目级主配置]
R2[".claude/rules/*.md
领域规则文件"]
R3["CLAUDE.local.md
个人本地配置"]
end
subgraph "第二层：技能层 Skills"
S1[".claude/commands/*.md
斜杠命令"]
S2["SKILL.md
技能说明文件"]
end
subgraph "第三层：代理层 Subagents"
A1[".claude/agents/*.md
子代理定义"]
A2["独立上下文
隔离执行"]
end
subgraph "第四层：工具层 MCP"
M1["MCP Servers
外部工具集成"]
M2["stdio/SSE 传输
标准化协议"]
end
R1 --> S1
S1 --> A1
A1 --> M1
style R1 fill:#fff3e0
style S1 fill:#e8f5e9
style A1 fill:#e3f2fd
style M1 fill:#fce4ec
```
### 第一层：规则层（Rules）—— 写一次，每次生效
**文件位置与加载优先级**：
| 文件 | 作用域 | 是否提交 Git | 加载时机 |
|------|--------|-------------|---------|
| `~/.claude/CLAUDE.md` | 全局（所有项目） | 否 | 每次会话 |
| `项目根/CLAUDE.md` | 项目级（团队共享） | **是** | 每次会话 |
| `项目根/CLAUDE.local.md` | 项目级（个人） | 否 | 每次会话 |
| `.claude/rules/*.md` | 模块级规则 | 视情况 | 条件触发 |
| `子目录/CLAUDE.md` | 子目录级 | 视情况 | 操作该目录时 |
**规则文件写作四原则**：
1. **指令式语气**：用"必须"、"禁止"、"优先"等确定性语言
2. **每条规则可验证**：写完后问自己"Claude Code 能判断是否遵循了吗？"
3. **控制总长度**：CLAUDE.md 每行都消耗上下文 Token，控制在 200 行以内
4. **分层组织**：先架构约束，再编码规范，最后工具偏好
```markdown
# 示例：一个精炼的 CLAUDE.md
## 项目架构
- 单体应用，Express + TypeScript + PostgreSQL
- 入口：src/index.ts，路由：src/routes/
- 数据层使用 Drizzle ORM，schema 在 src/db/schema.ts
- 禁止直接写 SQL，必须通过 ORM
## 编码规范
- 使用 pnpm，禁止 npm/yarn
- 测试框架 Vitest，测试文件放在 __tests__/ 目录
- 错误处理统一使用 src/utils/errors.ts 中的 AppError 类
- API 响应格式：{ success: boolean, data?: T, error?: string }
## Git 规范
- commit message 遵循 Conventional Commits
- 禁止直接 push 到 main 分支
- 每次变更必须有对应测试
```
**模块化规则（.claude/rules/）**：当项目很大时，用规则文件按领域拆分：
```
.claude/
rules/
frontend.md # React 组件规范，仅操作 src/frontend/ 时加载
database.md # 数据库操作规范，仅操作 src/db/ 时加载
api-design.md # API 设计规范
security.md # 安全相关硬规则
```
### 第二层：技能层（Skills）—— 固化常用流程
规则层解决"告诉 Claude Code 应该怎么做"，技能层解决"一键执行标准流程"。
**何时从 Rules 升级到 Skills**：
- 同一个操作你手动执行了 3 次以上
- 操作涉及 3 个以上步骤且有固定顺序
- 需要接受参数（如项目名、组件类型）
**创建方式**：
```bash
# 在项目根目录创建斜杠命令
mkdir -p .claude/commands
```
```markdown
# 文件：.claude/commands/create-component.md
# 创建一个新的 React 组件
参数：
- $ARGUMENTS = 组件名称（PascalCase）
请执行以下步骤：
1. 在 src/components/$ARGUMENTS/ 目录下创建：
- $ARGUMENTS.tsx（组件主体）
- $ARGUMENTS.styles.ts（样式，使用 styled-components）
- $ARGUMENTS.test.tsx（测试，使用 @testing-library/react）
- index.ts（导出入口）
2. 组件模板：
- 使用 React.forwardRef 支持 ref 转发
- Props 接口命名为 ${ARGUMENTS}Props
- 包含 displayName 设置
3. 在 src/components/index.ts 中添加导出
4. 运行 pnpm test 确认测试通过
```
使用时在 Claude Code 中输入 `/create-component UserProfile` 即可。
### 第三层：代理层（Subagents）—— 隔离执行复杂任务
子代理是 Claude Code 最被低估的能力。它的核心价值是**上下文隔离**——在独立空间完成任务，只返回结果摘要给主对话。
**何时使用 Subagents**：
- 需要大量探索代码但不希望污染主上下文
- 多个独立任务可以并行执行
- 任务需要不同模型（如用 Haiku 做初步探索，Opus 做深度分析）
```markdown
# 文件：.claude/agents/code-reviewer.md
你是一位严格的高级代码审查员。审查给定的代码变更，输出结构化报告：
## 检查维度
1. **正确性**：逻辑错误、边界条件、空指针风险
2. **安全性**：注入、敏感信息泄露、权限绕过
3. **性能**：N+1 查询、内存泄漏、不必要的计算
4. **可维护性**：命名清晰度、函数复杂度、重复代码
## 输出格式
对每个发现：
- 严重级别：🔴 Critical / 🟡 Warning / 🔵 Info
- 位置：文件:行号
- 问题描述 + 修复建议
最后给出总体评分 (A/B/C/D) 和是否建议合并。
```
**调用方式**：在 Plan Mode 中，Claude Code 会自动将探索性工作委派给子代理。你也可以在对话中明确指示：
```
请启动一个子代理来探索 src/legacy/ 目录的结构，
总结每个模块的职责和依赖关系，然后回来告诉我。
```
### 第四层：工具层（MCP）—— 连接外部世界
MCP（Model Context Protocol）是 Claude Code 连接外部系统的标准协议。前三层都在 Claude Code 内部运作，MCP 则打开了通向外部的大门。
**何时需要 MCP**：
- 需要读写外部系统（数据库、API、文件服务）
- 需要调用专业工具（浏览器、图像处理、数据分析）
- 团队有多个 AI 工具需要共享工具层
```json
// 文件：.claude/settings.json 中的 MCP 配置
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/mydb"]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "${GITHUB_TOKEN}" }
}
}
}
```
---
## 四、决策框架：五问选型法
面对一个需求，问自己五个问题，即可确定应该用哪一层：
```mermaid
flowchart TD
Q1{"Q1: 这个需求是
一次性的吗？"}
Q1 -->|是| PROMPT["直接提示词
交互即可"]
Q1 -->|否| Q2{"Q2: 需要访问
外部系统吗？"}
Q2 -->|是| MCP["第四层：MCP"]
Q2 -->|否| Q3{"Q3: 任务独立且
可能并行吗？"}
Q3 -->|是| SUB["第三层：Subagent"]
Q3 -->|否| Q4{"Q4: 有固定步骤
且需参数化？"}
Q4 -->|是| SKILL["第二层：Skill"]
Q4 -->|否| Q5{"Q5: 需要每次会话
都遵守吗？"}
Q5 -->|是| RULE["第一层：Rule"]
Q5 -->|否| PROMPT
style PROMPT fill:#e1f5fe
style RULE fill:#fff3e0
style SKILL fill:#e8f5e9
style SUB fill:#e3f2fd
style MCP fill:#fce4ec
```
### 实战决策案例
| 场景 | 决策 | 理由 |
|------|------|------|
| "这次修个 bug" | 直接提示词 | 一次性任务 |
| "项目禁止用 any" | Rule (CLAUDE.md) | 每次会话必须遵守 |
| "每周创建 Sprint 报告" | Skill (斜杠命令) | 有固定步骤、需参数化 |
| "审查所有 PR" | Subagent | 独立任务、需上下文隔离 |
| "查数据库验证数据" | MCP Server | 需访问外部系统 |
| "组件开发标准+自动生成" | Rule + Skill 组合 | 规则定义标准，技能执行流程 |
---
## 五、上下文窗口管理：Token 预算意识
Claude Code 的上下文窗口是最宝贵的资源。随着上下文填满，模型性能会显著下降。以下是管理策略：
### 5.1 主动压缩：`/compact` 命令
```bash
# 在 Claude Code 对话中
/compact
# 或带指示的压缩
/compact 保留数据库 schema 和 API 路由信息，丢弃探索过程中的中间文件内容
```
`/compact` 会将当前对话摘要压缩，释放 Token 空间。**建议每完成一个子任务就执行一次**。
### 5.2 精准引用：减少不必要的上下文加载
```markdown
# ❌ 浪费 Token
请阅读整个 src/ 目录然后告诉我用户的认证逻辑在哪里
# ✅ 精准引用
查看 @src/middleware/auth.ts 中的 JWT 验证逻辑，
对比 @src/config/auth.ts 中的 token 过期时间配置
```
### 5.3 会话隔离：不同任务用不同会话
```bash
# 任务1：前端组件开发
claude
# 任务2：数据库迁移（开新会话）
claude
# 任务3：CI/CD 配置（又一新会话）
claude
```
避免在同一个会话中切换不相关的任务，防止上下文污染。
### 5.4 模型选择策略
| 任务类型 | 推荐模型 | 原因 |
|---------|---------|------|
| 快速探索、文件搜索 | Haiku | 速度快、成本低 |
| 日常编码、重构 | Sonnet | 性价比最优 |
| 架构设计、复杂调试 | Opus | 推理能力最强 |
```bash
# 使用指定模型启动
claude --model haiku # 快速探索
claude --model opus # 深度思考
```
---
## 六、完整实战案例：为 React 项目搭建四层定制体系
### Step 1：项目初始化
```bash
mkdir my-react-app && cd my-react-app
npx create-react-app . --template typescript
claude init # 初始化 Claude Code 配置
```
### Step 2：编写规则层
```markdown
# 文件：CLAUDE.md
## 技术栈
- React 18 + TypeScript 5 + Vite
- 状态管理：Zustand
- 样式方案：Tailwind CSS
- 测试：Vitest + @testing-library/react
## 架构约定
- 组件放在 src/components/，按功能模块分目录
- 自定义 Hook 放在 src/hooks/，以 use 前缀命名
- API 调用封装在 src/services/，统一使用 src/services/http.ts 中的 axios 实例
- 禁止在组件中直接调用 axios
## 编码规范
- 函数组件优先，禁止 class 组件
- Props 必须定义独立的 TypeScript interface
- 每个组件必须有对应的测试文件
- 使用 cn() 工具函数合并 Tailwind 类名
## Git 规范
- feat/fix/refactor/test/docs 前缀
- 每个 PR 必须通过 CI 检查
```
```markdown
# 文件：.claude/rules/api-patterns.md
---
description: API 服务层开发规范
globs: src/services/**/*.ts
---
- 所有 API 函数返回 Promise>
- 错误处理使用 services/errors.ts 中定义的 ApiError
- 请求/响应拦截器在 http.ts 中统一配置
- 接口路径常量定义在 services/endpoints.ts
```
### Step 3：创建技能层
```markdown
# 文件：.claude/commands/add-feature.md
---
description: 创建新的功能模块（含组件、Hook、服务、测试）
arguments: $ARGUMENTS = 功能模块名称（camelCase）
---
为 $ARGUMENTS 功能模块创建完整结构：
1. 创建 src/features/$ARGUMENTS/ 目录，包含：
- components/ — 功能相关组件
- hooks/use$ARGUMENTS.ts — 功能相关 Hook
- services/$ARGUMENTSService.ts — API 调用封装
- types.ts — 类型定义
- index.ts — 导出入口
2. Hook 模板：
- 使用 Zustand store 管理状态
- 包含 loading / error / data 三态
- 导出 reset 方法
3. Service 模板：
- CRUD 四个基本方法
- 使用 http.ts 的 axios 实例
4. 在 src/features/index.ts 中添加导出
5. 运行 pnpm test 确认无报错
```
```markdown
# 文件：.claude/commands/add-page.md
---
description: 创建新的页面组件和路由
arguments: $ARGUMENTS = 页面名称（PascalCase）
---
1. 在 src/pages/ 创建 $ARGUMENTS.tsx
- 使用 React.lazy 懒加载
- 包含 Suspense fallback
2. 在 src/router/ 的路由配置中添加新路由
- 路径：将 PascalCase 转为 kebab-case
- 例如 UserProfile → /user-profile
3. 如果需要认证保护，用 @src/components/ProtectedRoute 包裹
4. 创建对应的测试文件
```
### Step 4：配置子代理
```markdown
# 文件：.claude/agents/test-writer.md
---
description: 为指定文件或目录生成全面的测试用例
---
你是测试工程师。接收目标文件路径后：
1. 读取目标文件，分析所有导出函数/组件
2. 为每个导出生成测试用例，覆盖：
- 正常路径（Happy Path）
- 边界条件（空值、极大值、特殊字符）
- 错误路径（异常处理）
- 用户交互（如果是组件）
3. 测试规范：
- 使用 Vitest + @testing-library/react
- Mock 外部依赖（API、Router、Store）
- 测试描述用中文，清晰表达意图
- 目标覆盖率 ≥ 80%
4. 运行测试确认全部通过
5. 输出覆盖率报告
```
### Step 5：配置 MCP 工具层
```json
// 文件：.claude/settings.json
{
"permissions": {
"allow": [
"Bash(pnpm test:*)",
"Bash(pnpm lint:*)",
"Bash(pnpm build:*)"
]
},
"mcpServers": {
"browser": {
"command": "npx",
"args": ["-y", "@anthropic-ai/mcp-browser"]
},
"filesystem": {
"command": "npx",
"args": ["-y", "@anthropic-ai/mcp-filesystem", "./src"]
}
}
}
```
### Step 6：验证完整工作流
```bash
# 启动 Claude Code
claude
# 使用技能创建功能模块
> /add-feature shoppingCart
# 使用技能创建页面
> /add-page ShoppingCart
# 委派子代理写测试
> 请使用 test-writer 子代理为 src/features/shoppingCart/ 生成全面测试
# 使用 MCP 浏览器验证页面
> 启动浏览器，访问 localhost:5173/shopping-cart，截图确认页面渲染正常
# 压缩上下文，准备下一个任务
> /compact 保留 shoppingCart 功能模块的架构信息
```
---
## 七、常见反模式与修复
### 反模式1：CLAUDE.md 写成文档
```markdown
# ❌ 文档式 CLAUDE.md（浪费 Token）
## 项目介绍
本项目是一个基于 React 的电商平台，目标用户是...
## 技术选型原因
选择 React 而不是 Vue 是因为团队...
# ✅ 指令式 CLAUDE.md（高效）
## 硬约束
- React 18 + TypeScript strict mode
- 禁止使用 any，禁止 @ts-ignore
- API 错误码映射表在 src/constants/error-codes.ts
```
### 反模式2：所有逻辑都塞进 CLAUDE.md
CLAUDE.md 每行都消耗 Token。解决方案：使用 `.claude/rules/` 按条件加载：
```markdown
# .claude/rules/testing.md — 仅操作测试文件时加载
---
description: 测试编写规范
globs: ["**/*.test.ts", "**/*.test.tsx", "**/__tests__/**"]
---
- 测试框架：Vitest
- 组件测试：@testing-library/react
- Mock 工具：vi.mock()
- 命名：describe/it 使用中文描述
```
### 反模式3：在长对话中做不相关的事
```bash
# ❌ 同一会话中混合任务
claude
> 帮我写登录页面的组件...
> (写完登录) 现在帮我优化数据库查询...
> (优化完) 帮我配置 GitHub Actions...
# ✅ 每个任务独立会话
claude # 会话1：登录页面
claude # 会话2：数据库优化
claude # 会话3：CI 配置
```
### 反模式4：过度定制，忽视直接提示词
不是所有需求都需要定制层。**能用一句话解决的，不要创建 Skill**。
```markdown
# 这些不需要定制，直接问就好：
- "这个函数的时间复杂度是多少"
- "帮我把这段代码从 JavaScript 转成 TypeScript"
- "这个报错是什么意思：TypeError: Cannot read property..."
# 这些值得定制：
- "每个新功能都要创建5个文件、3个测试" → Skill
- "项目禁止使用 moment.js" → Rule
- "代码审查要检查5个维度" → Subagent
```
---
## 八、四层体系与其他 AI 工具的对比定位
理解四层定制体系后，可以更清晰地看到 Claude Code 相比 Cursor、Copilot 的差异化定位：
| 能力 | Claude Code | Cursor | GitHub Copilot |
|------|------------|--------|---------------|
| 提示词交互 | ✅ 终端对话 | ✅ 编辑器内 | ⚠️ 有限 |
| 规则层 (CLAUDE.md) | ✅ 完整层级 | ✅ .cursorrules | ⚠️ .github/copilot-instructions |
| 技能层 (斜杠命令) | ✅ 可自定义 | ⚠️ 内置为主 | ❌ 不支持 |
| 子代理 (隔离上下文) | ✅ 原生支持 | ❌ 不支持 | ❌ 不支持 |
| MCP (工具协议) | ✅ 原生支持 | ⚠️ 部分支持 | ❌ 不支持 |
| 无头模式 (CI/CD) | ✅ -p 模式 | ❌ | ⚠️ 有限 |
**选择建议**：轻量级补全选 Copilot，IDE 深度集成选 Cursor，复杂工程化任务选 Claude Code，三者并不互斥——最高效的工作流往往组合使用。
---
## 九、性能优化清单
将提示词工程与四层定制结合的优化要点汇总：
1. **CLAUDE.md 控制在 100-200 行**：超过 200 行考虑拆分到 rules/
2. **rules/ 使用 globs 条件加载**：避免无差别加载所有规则
3. **频繁使用 `/compact`**：每完成一个子任务就压缩一次
4. **子代理处理探索性任务**：保护主上下文不被无关信息污染
5. **MCP 按需启用**：不在 settings.json 中配置用不到的 MCP 服务器
6. **模型分级使用**：Haiku 探索 → Sonnet 编码 → Opus 设计
7. **会话及时切换**：不同任务用不同会话，避免上下文串扰
---
## 十、延伸阅读与参考资源
### 官方文档
- [Claude Code Best Practices](https://code.claude.com/docs/en/best-practices) — Anthropic 官方最佳实践指南
- [Extend Claude Code - Features Overview](https://code.claude.com/docs/en/features-overview) — 扩展能力全景图
- [Claude Code Settings](https://code.claude.com/docs/en/settings) — 配置文件完整参考
- [Claude Prompting Best Practices](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices) — 提示词工程官方指南
### 社区优质资源
- [Claude Code Customization Guide: Rules vs Skills vs Subagents vs MCPs](https://marioottmann.com/articles/claude-code-customization-guide) — 四层定制体系深度对比
- [CLAUDE.md Best Practices: The Complete 2026 Guide](https://dev.to/nishilbhave/claudemd-best-practices-the-complete-2026-guide-435j) — CLAUDE.md 写作完整指南
- [Context Engineering 2026 实战指南](https://blog.xidao.online/posts/context-engineering-2026/) — 从提示词工程到上下文工程的范式跃迁
- [Claude Code Best Practices: 15 Tips from 6 Projects](https://aiorg.dev/blog/claude-code-best-practices) — 来自 6 个生产项目的实战经验
- [50个 Claude Code 日常使用技巧与最佳实践](https://developer.aliyun.com/article/1728645) — 阿里云社区的系统性技巧汇总
---
## 训练营适用性评估
| 训练营类型 | 适用性 | 预计时长 | 说明 |
|-----------|--------|---------|------|
| AI 编程入门营 | ⭐⭐⭐⭐ | 3小时 | 上午学提示词七种模式，下午实操四层定制 |
| 前端工程师提效营 | ⭐⭐⭐⭐⭐ | 2小时 | 直接套用 React 项目实战案例 |
| 团队工程化培训 | ⭐⭐⭐⭐⭐ | 4小时 | 重点讲规则层与技能层的团队共享策略 |
| AI Agent 开发营 | ⭐⭐⭐ | 1.5小时 | 作为 Agent 定制化架构的前置知识 |
> **核心收获**：提示词决定单次交互质量，四层定制体系决定长期工程效率。从随手提问到规则固化，从技能封装到工具集成，每一层都解决一个量级的问题——关键是知道什么时候该上哪一层。
> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。
