跳到主要内容

提示词工程

概述​

将 Claude Code 从"聊天工具"升级为"开发伙伴"的关键在于提示词工程。本文将介绍如何编写结构化、工程级的提示词，让 Claude 生成符合项目规范的代码。

核心理念​

从"聊天"到"协议"​

传统聊天式提示词：

帮我写一个用户列表组件。

工程级协议式提示词：

[ROLE]
你是一个资深前端工程师，熟悉 React 18 + TypeScript + TailwindCSS。

[TASK]
实现一个通用分页列表组件 <PaginatedTable>，用于展示用户数据。

关键区别：

  • 聊天式：模糊、随意、依赖 Claude 猜测
  • 协议式：结构化、明确、像接口定义文档

工程级提示词的五大要素​

1. ROLE - 角色设定​

定义 Claude 的身份和能力：

你是一个有 5 年经验的前端工程师，熟悉：
- React 18 + TypeScript + Vite
- Zustand 状态管理
- TailwindCSS 样式方案
- 遵循 Airbnb TypeScript Style Guide

2. TASK - 任务目标​

明确要完成的具体任务：

重构现有的用户列表页面，适配新的用户查询接口：
- 接口字段从 user_name 改为 username
- 分页参数从 page/size 改为 offset/limit
- 添加按创建时间过滤功能

3. CONTEXT - 工程上下文​

提供必要的技术和环境信息：

技术栈：
- Next.js App Router
- React Query (数据获取)
- 自定义 hooks (usePagination)

现有代码结构：
src/
├── components/UserList/
│   ├── index.tsx
│   ├── hooks.ts
│   └── types.ts

4. CONSTRAINTS - 约束条件​

定义不能违反的规则：

- 不引入新的第三方依赖
- 不修改公共组件的对外 props
- 保持最小修改原则
- 必须通过 TypeScript 严格模式检查
- 单元测试覆盖率不能降低

5. OUTPUT_FORMAT - 输出格式​

规范输出内容的格式：

1. 先用 5 行说明设计思路
2. 给出修改后的完整代码（TypeScript）
3. 列出行为变更点（如有）
4. 提供必要的测试建议

复杂场景的三段式工作流​

对于涉及多个文件的复杂任务，采用三段式流程更安全：

阶段一：规划（Plan）​

[ROLE]
你是本项目的前端技术负责人。

[TASK]
根据接口变更，规划需要修改的文件和改动点。

[CONTEXT]
旧接口：GET /api/users?page=1&size=20
新接口：GET /api/v2/users?offset=0&limit=20

[OUTPUT_FORMAT]
1. 用 10 行总结接口变更的影响
2. 列出需要修改的文件清单：
   - 文件路径
   - 修改要点
   - 风险评估

注意：本阶段只做规划，不输出代码

阶段二：精确修改（Patch）​

针对每个文件单独处理：

[TASK]
修改 UserList/index.tsx 文件

[CONTEXT]
当前代码：
[粘贴完整代码]

[CONSTRAINTS]
- 只修改与分页相关的逻辑
- 保持其他功能不变
- 输出 diff 格式

[OUTPUT_FORMAT]
1. 说明修改点
2. 提供 unified diff
3. 列出潜在风险

阶段三：应用与验证​

由开发者应用修改并验证：

  1. 应用 diff 到代码
  2. 运行测试
  3. 手动验证功能
  4. 如有问题，返回阶段二迭代

降低逻辑幻觉的技巧​

1. 先理解，再修改​

让 Claude 先分析现有代码：

在修改代码前，请先完成：
1. 列出当前代码的 3-5 个核心行为
2. 指出每个行为的边界条件
3. 说明修改将如何影响这些行为

完成分析后再提供修改方案

2. 使用不变量描述​

用性质而非流程描述需求：

实现订单计算函数，保证以下性质始终成立：
- 性质1：空商品列表时总价为0
- 性质2：总价不能为负数
- 性质3：增加商品数量时总价单调不减

请基于这些性质编写实现和测试

3. 显式边界条件​

明确说明需要处理的边界情况：

处理以下边界条件：
- null/undefined 输入
- 空数组场景
- 网络请求失败
- 并发请求处理

Few-shot 学习法​

1. 提供满意示例​

给 Claude 一个好的参考：

[GOOD_EXAMPLE]
// 这是一个满意的分页组件实现：
const PaginatedList = ({ data, onPageChange }) => {
  const [page, setPage] = useState(1)
  // 实现细节...
}

请严格模仿这个风格实现新组件

2. 展示期望的评审风格​

[REVIEW_STANDARD]
请按以下标准评审代码：
1. 命名是否清晰表达意图
2. 是否遵循 DRY 原则
3. 错误处理是否完善
4. 是否有性能优化空间

对下面代码进行评审：
[代码]

实用模板库​

组件开发模板​

[ROLE]
React 组件开发工程师

[TASK]
开发 [组件名] 组件

[CONTEXT]
技术栈：React 18 + TypeScript + TailwindCSS
数据结构：[接口定义]
使用场景：[应用场景]

[REQUIREMENTS]
- 功能需求列表
- 性能要求
- 可访问性要求

[CONSTRAINTS]
- 不使用 [禁用技术]
- 必须兼容 [浏览器版本]
- 遵循 [编码规范]

[OUTPUT_FORMAT]
1. 设计思路（3-5行）
2. 完整组件代码
3. 使用示例
4. 测试建议

重构任务模板​

[ROLE]
代码重构专家

[TASK]
重构 [模块名] 以实现 [目标]

[CONTEXT]
当前问题：
- [问题1]
- [问题2]

技术债务：
- [债务1]
- [债务2]

[CONSTRAINTS]
- 保持 API 兼容性
- 不影响现有功能
- 渐进式重构

[OUTPUT_FORMAT]
1. 重构策略
2. 分步实施计划
3. 每步的代码改动
4. 风险控制措施

Bug 修复模板​

[ROLE]
问题诊断专家

[TASK]
修复 [Bug 描述]

[CONTEXT]
Bug 现象：[具体表现]
错误信息：[错误日志]
复现步骤：[步骤列表]

[CONSTRAINTS]
- 不引入新 Bug
- 最小修改范围
- 保持性能

[OUTPUT_FORMAT]
1. 根因分析
2. 修复方案
3. 代码改动
4. 测试验证

高级技巧​

1. 条件式提示词​

根据不同场景使用不同提示：

如果 [条件]：
  [提示词A]
否则如果 [条件]：
  [提示词B]
否则：
  [提示词C]

2. 渐进式细化​

先获得大致方案，再逐步细化：

第一轮：请给出实现思路
第二轮：基于思路，给出组件结构
第三轮：完善具体实现细节

3. 自我修正提示​

让 Claude 检查自己的输出：

请检查你生成的代码：
1. 是否符合所有约束条件？
2. 是否有潜在的 bug？
3. 是否需要优化？
4. 请提供改进版本

常见误区​

1. 上下文过多​

❌ 错误：

粘贴整个项目的代码...

✅ 正确：

只提供相关的文件片段和关键信息

2. 约束不明确​

❌ 错误：

写一个高效的组件

✅ 正确：

组件响应时间 < 100ms，内存占用 < 1MB

3. 格式要求模糊​

❌ 错误：

给出代码

✅ 正确：

用 TypeScript 编写，包含完整的类型定义

实战案例​

案例1：API 适配​

[ROLE]
前端适配工程师

[TASK]
将用户列表页面从 v1 API 适配到 v2 API

[CONTEXT]
v1 API: GET /users?page=1&size=20
v2 API: GET /api/users?offset=0&limit=20

文件：src/pages/UserList.tsx

[CONSTRAINTS]
- 保持 UI 不变
- 添加错误处理
- 支持加载状态

[OUTPUT_FORMAT]
1. 适配说明
2. 代码 diff
3. 测试点

案例2：性能优化​

[ROLE]
性能优化专家

[TASK]
优化大列表渲染性能

[CONTEXT]
当前问题：10,000 条数据渲染卡顿
技术栈：React + TypeScript
环境：Chrome 浏览器

[REQUIREMENTS]
- 首屏渲染 < 500ms
- 滚动流畅不卡顿
- 内存占用稳定

[CONSTRAINTS]
- 不改变数据结构
- 保持功能完整
- 兼容现有代码

[OUTPUT_FORMAT]
1. 性能分析
2. 优化方案
3. 实现代码
4. 性能指标

最佳实践总结​

  1. 结构化：使用 ROLE/TASK/CONTEXT/CONSTRAINTS/OUTPUT_FORMAT
  2. 具体化：避免模糊描述，提供具体要求
  3. 渐进式：复杂任务拆分为多个步骤
  4. 验证导向：考虑测试和验证方法
  5. 迭代优化：根据结果调整提示词

相关资源​