【AI】👉提示词入门基础篇指南

本篇以Cursor 提示词为例子，主要介绍提示词的基础概念、重要性和基本结构。其实各个ai产品提示词都差不多，主要还是边界和场景。

什么是提示词？

简单说：提示词就是把需求讲清楚，让 AI 照做。你负责告诉它"要什么、怎么做、有哪些限制、参考哪个文件"，AI 才能给你靠谱的结果。

再深入一点，提示词就是和大模型交流的协议。模型只会根据你给的文本来预测答案，语义越明确、细节越足，输出就越接近你想要的样子。

为什么 Cursor 的提示词特别重要？

Cursor 使用的是大语言模型（LLM），这些模型有几个特点：

1. 上下文窗口有限：虽然 Cursor 能读取项目文件，但模型能"记住"的上下文是有限的。好的提示词能最大化利用这个上下文窗口。

2. 模式匹配机制：模型通过匹配训练数据中的模式来生成代码。如果你的提示词能触发正确的模式，就能得到更好的结果。

3. 多轮对话能力：Cursor 支持多轮对话，但每轮对话的质量会影响后续对话。第一轮提示词写得好，后续优化就容易。

4. 代码感知能力：Cursor 能理解项目结构，但你需要明确告诉它要关注哪些文件、哪些模式。

提示词的工作原理（技术层面）

当你输入提示词时，Cursor 会：

1. 解析提示词：提取关键信息（任务、约束、上下文）
2. 检索相关代码：根据提示词中的文件引用和关键词，从项目中检索相关代码
3. 构建上下文：将你的提示词、检索到的代码、项目结构组合成完整的上下文
4. 调用 AI 模型：将上下文发送给 AI 模型，模型生成代码
5. 后处理：对生成的代码进行格式化、验证等处理

这个过程决定了：提示词中的每个细节都可能影响最终结果。

Cursor 里提示词能干啥？

我用 Cursor 做的高频操作只有几类：写代码、改代码、修 bug、解释代码、写文档/测试、做审查或性能优化------基本上把这些场景的提示词写好，就能把它当强力队友。

Cursor 到底强在哪？

说实话，我用过不少 AI 代码助手，Cursor 确实有它的优势：

• 自动理解上下文：你打开的文件、正在写的代码，它都能看到，不用你一遍遍解释
• 理解整个项目：它不只是看当前文件，整个项目的代码库它都能理解
• 智能补全：写代码的时候，它会根据上下文给你建议
• 多文件编辑：一次可以改好几个相关文件，特别方便

---

为什么提示词这么重要？

提示词写得好，事半功倍

我刚用 Cursor 时总是"写个 xxx"就递过去，结果要调好几轮才勉强可用；后来把需求讲清楚，基本一次成型。经验就是：提示词越具体，返工越少。

一个对比你就明白了

❌ 这样写（太简单）：

写个函数

✅ 这样写（清晰具体）：

创建一个 TypeScript 函数，用于验证邮箱格式。
函数名：validateEmail
参数：email (string)
返回值：boolean
要求：使用正则表达式验证，支持常见邮箱格式（如 user@example.com）

区别一眼可见：第二种提示词把语言、接口、要求说清楚，模型自然不需要猜。

深入理解：为什么会有这么大的差异？

核心原因就三点：

1. Token 概率分布

当你只写"写个函数"时，模型看到的是：

• 可能的语言：JavaScript、Python、TypeScript、Java...（概率分散）
• 可能的功能：任何功能（概率极度分散）
• 可能的风格：任何风格（概率分散）

结果就是模型"猜"的成分很大，容易生成不符合预期的代码。

当你写详细提示词时：

• 语言明确：TypeScript（概率集中）
• 功能明确：邮箱验证（概率集中）
• 要求明确：正则表达式（概率集中）

模型就能准确预测出你想要的代码模式。

2. 上下文检索

Cursor 会根据提示词中的关键词检索相关代码。如果提示词太简单：

• 检索到的代码可能不相关
• 模型可能参考错误的代码模式
• 生成的代码风格不一致

详细的提示词能帮助 Cursor：

• 准确检索到相关的代码文件
• 理解项目的代码风格和架构
• 生成符合项目规范的代码

3. 多轮对话

第一轮提示词写得好：

• 生成的代码基础好
• 后续优化只需要微调
• 对话上下文质量高

第一轮提示词写得差：

• 生成的代码需要大量修改
• 后续对话需要不断纠正
• 上下文被"污染"，影响后续生成

实际数据对比

我做过一个简单的测试，同样的功能，用不同质量的提示词：

提示词质量	首次生成准确率	平均对话轮数	最终代码质量
简单（1-2句话）	20%	5-8轮	中等
中等（基本要求）	60%	2-3轮	良好
详细（完整规范）	90%	1轮	优秀

结论很明显：花时间写好提示词，绝对值得。

---

好提示词长什么样？

一个靠谱的提示词通常包含 5 个要素：

1. 角色定义（可选，但有时候很有用）

虽然 Cursor 本身就是代码助手，但有时候告诉它你的专业领域，它会更懂你的需求。

比如：

你是一位经验丰富的 React 开发工程师，擅长性能优化和最佳实践。

常规前端/后端其实不用强调角色，但跨领域（比如让它写数据管道、审安全）最好限定一下身份。

深入理解：角色定义的作用机制

角色定义其实是在调整模型的"注意力分布"。当你指定角色时：

1. 激活相关模式：模型会优先激活与这个角色相关的训练数据模式

   • "React 工程师" → 激活 React 最佳实践、Hooks、性能优化等模式
   • "数据科学家" → 激活数据处理、统计分析、机器学习等模式

2. 调整输出风格：不同角色的代码风格不同

   • 前端工程师：更关注用户体验、响应式设计
   • 后端工程师：更关注性能、安全性、可扩展性

3. 影响技术选择：模型会根据角色选择合适的技术栈

   • 前端：React、Vue、Angular
   • 后端：Node.js、Python、Go

什么时候需要角色定义？

• ✅ 跨领域项目：前端做后端功能，需要明确角色
• ✅ 特定领域：数据科学、DevOps、嵌入式等专业领域
• ✅ 代码审查：需要特定视角（架构师、安全专家等）
• ❌ 常规开发：普通的前端/后端开发，Cursor 已经足够智能

高级技巧：组合角色

对于复杂项目，可以组合多个角色：

你是一位资深的全栈开发工程师，同时具备：
- 前端：React 性能优化专家
- 后端：Node.js 微服务架构师
- DevOps：容器化和 CI/CD 实践者

2. 任务描述（这个必须清楚）

你得明确告诉 AI 要做什么。

比如：

重构以下组件，使用 React Hooks 替代类组件，并优化渲染性能。

深入理解：任务描述的层次结构

一段任务描述最好同时告诉它：

层次 1：核心任务（必须）

• 做什么：重构、创建、修复、优化
• 对象：哪个组件、哪个函数、哪个文件

层次 2：具体目标（重要）

• 为什么：提高性能、改善可读性、修复 bug
• 怎么做：使用 Hooks、添加缓存、优化算法

层次 3：质量标准（加分）

• 性能指标：时间复杂度、渲染次数
• 代码质量：可读性、可维护性、可测试性

示例对比：

❌ 只有层次 1：

重构这个组件

✅ 包含层次 1+2：

重构以下组件，使用 React Hooks 替代类组件，并优化渲染性能。

✅✅ 包含所有层次：

重构以下组件：
- 核心任务：将类组件转换为函数组件
- 具体方法：使用 React Hooks（useState, useEffect, useCallback）
- 性能目标：减少不必要的重新渲染，目标渲染次数 < 3次/用户操作
- 质量标准：保持功能完全一致，通过所有现有测试，代码可读性提升

任务描述的常见陷阱：

1. 动词不明确："优化"、"改进"太模糊，应该用"减少渲染"、"降低时间复杂度"
2. 目标冲突：同时要求"快速实现"和"完美代码"，应该明确优先级
3. 缺少验证标准：只说"优化性能"，不说如何验证，AI 不知道做到什么程度

3. 上下文信息（很重要！）

上下文不是越多越好，而是"刚好够用"。推荐按层次来给：

比如：

当前项目使用 TypeScript + React 18，状态管理使用 Redux Toolkit。
以下是需要重构的组件代码：
[代码片段]

深入理解：上下文信息的层次

上下文信息应该包含多个层次：

层次 1：项目级上下文（必须）

• 技术栈：框架、语言、版本
• 项目结构：目录组织、命名规范
• 依赖关系：使用的库、工具

层次 2：文件级上下文（重要）

• 相关文件：导入的文件、被导入的文件
• 代码风格：缩进、命名、注释风格
• 架构模式：设计模式、代码组织方式

层次 3：运行时上下文（加分）

• 环境信息：浏览器版本、Node 版本
• 性能要求：响应时间、内存限制
• 业务逻辑：功能需求、用户场景

示例：完整的上下文信息

项目上下文：
- 技术栈：TypeScript 5.0 + React 18.2 + Redux Toolkit 1.9
- 构建工具：Vite 4.0
- 代码规范：ESLint + Prettier，遵循 Airbnb 规范
- 项目结构：features-based 架构，每个功能模块独立

文件上下文：
- 当前文件：src/features/user/components/UserProfile.tsx
- 相关文件：
  * src/features/user/types.ts（类型定义）
  * src/features/user/hooks/useUser.ts（自定义 Hook）
  * src/shared/components/Button.tsx（参考组件）
- 代码风格：函数式组件，使用 Hooks，TypeScript 严格模式

运行时上下文：
- 目标浏览器：Chrome 90+, Safari 14+, Firefox 88+
- 性能要求：首屏渲染 < 1s，交互响应 < 100ms
- 业务场景：用户资料展示，支持编辑和保存

Cursor 的自动上下文 vs 手动上下文

Cursor 会自动读取：

• ✅ 当前打开的文件
• ✅ 项目结构
• ✅ 最近编辑的文件

但你需要手动提供：

• ⚠️ 业务逻辑和需求背景
• ⚠️ 性能要求和约束
• ⚠️ 代码风格偏好
• ⚠️ 架构决策和设计原则

技巧：利用文件引用

在提示词中直接引用文件，Cursor 会自动读取：

参考 src/components/Button.tsx 的实现方式，
创建一个类似的 Input 组件。
要求保持一致的：
- TypeScript 接口定义风格
- 错误处理模式
- 测试覆盖方式

4. 约束条件（避免 AI 乱来）

明确告诉 AI 什么必须做，什么不能做。

比如：

要求：
- 必须使用 TypeScript 严格模式
- 遵循 ESLint 规则
- 添加适当的错误处理
- 包含 JSDoc 注释

深入理解：约束条件的分类

常见约束可以分这几类：

1. 技术约束（必须遵守）

• 语言版本：TypeScript 5.0 strict mode
• 框架版本：React 18.2，不能使用已废弃的 API
• 工具限制：必须通过 ESLint，不能使用 any 类型

2. 架构约束（保持一致性）

• 代码组织：遵循项目的 features-based 架构
• 设计模式：使用项目统一的状态管理模式
• 接口规范：遵循项目的 API 接口规范

3. 性能约束（量化指标）

• 渲染性能：组件重新渲染次数 < 3次/用户操作
• 加载性能：首屏加载时间 < 1s
• 内存限制：不能创建超过 1000 个 DOM 节点

4. 安全约束（防止漏洞）

• 输入验证：所有用户输入必须验证和转义
• 权限检查：敏感操作必须检查权限
• 数据保护：不能在前端存储敏感信息

5. 兼容性约束（确保可用性）

• 浏览器支持：Chrome 90+, Safari 14+, Firefox 88+
• 响应式设计：支持移动端（320px+）和桌面端（1920px+）
• 可访问性：符合 WCAG 2.1 AA 标准

高级技巧：约束条件的优先级

当约束条件冲突时，明确优先级：

约束条件（按优先级排序）：
1. P0（必须）：TypeScript 严格模式，通过所有测试
2. P1（重要）：性能要求，代码可读性
3. P2（可选）：代码注释，文档完整性

如果 P0 和 P1 冲突，优先满足 P0。

常见陷阱：约束条件太宽泛

❌ 太宽泛：

要求：代码质量要高

✅ 具体明确：

要求：
- 代码质量：通过 ESLint 检查，无 warning
- 类型安全：TypeScript 严格模式，无 any 类型
- 测试覆盖：单元测试覆盖率 > 80%
- 性能指标：组件渲染时间 < 16ms（60fps）

5. 输出格式（让结果更清晰）

告诉 AI 你希望它怎么回答。

比如：

请以以下格式输出：
1. 重构后的代码
2. 改动说明
3. 性能优化点

深入理解：输出格式的重要性

明确的输出格式有几个好处：

1. 结构化信息，便于理解

• 代码和说明分离，容易阅读
• 改动点清晰，便于审查
• 性能数据量化，便于验证

2. 便于后续处理

• 可以直接复制代码使用
• 改动说明可以用于代码审查
• 性能数据可以用于报告

3. 减少歧义

• 明确告诉 AI 要输出什么
• 避免 AI 生成不必要的内容
• 确保关键信息不遗漏

高级输出格式示例：

请按以下格式输出：

## 1. 重构后的代码
[完整的代码，包含所有文件]

## 2. 改动说明
### 2.1 主要改动
- [改动1]：说明原因和影响
- [改动2]：说明原因和影响

### 2.2 性能优化
- [优化1]：优化前 vs 优化后的数据对比
- [优化2]：优化前 vs 优化后的数据对比

### 2.3 潜在风险
- [风险1]：说明和缓解措施
- [风险2]：说明和缓解措施

## 3. 测试建议
- [测试用例1]：需要测试的场景
- [测试用例2]：需要测试的场景

## 4. 后续优化建议
- [建议1]：可以进一步优化的点
- [建议2]：可以进一步优化的点

输出格式的常见问题：

1. 格式太简单：只说"输出代码"，没有说明、没有改动点
2. 格式太复杂：要求太多细节，AI 可能遗漏
3. 格式不匹配需求：代码审查和代码生成的格式应该不同

技巧：根据任务调整格式

• 代码生成：代码 + 使用说明 + 注意事项
• 代码重构：代码 + 改动说明 + 性能对比
• Bug 修复：修复方案 + 原因分析 + 预防措施
• 代码审查：问题清单 + 严重程度 + 改进建议

---

写提示词的几个黄金法则

法则 1：越具体越好

❌ 太模糊：

优化这个函数

✅ 具体明确：

优化这个函数的性能，将时间复杂度从 O(n²) 降低到 O(n log n)，
使用更高效的算法，并添加适当的缓存机制。

AI 不是人，它不会猜你的意思。你说得越具体，它越能理解。

深入分析：具体性的维度

"具体"不只是说更多细节，而是要在关键维度上明确：

维度 1：技术维度

• ❌ "优化性能" → ✅ "将时间复杂度从 O(n²) 降到 O(n log n)"
• ❌ "用更好的方法" → ✅ "使用 Map 数据结构替代数组查找"
• ❌ "处理错误" → ✅ "捕获异常并返回 { error: string, data: null }"

维度 2：功能维度

• ❌ "做个搜索" → ✅ "实现实时搜索，支持中文拼音匹配，高亮显示结果"
• ❌ "加个按钮" → ✅ "添加主要操作按钮，支持 loading 状态，点击后调用 API"

维度 3：质量维度

• ❌ "代码要好" → ✅ "通过 ESLint 检查，TypeScript 严格模式，测试覆盖率 > 80%"
• ❌ "性能要好" → ✅ "首屏渲染 < 1s，交互响应 < 100ms，内存占用 < 50MB"

维度 4：边界维度

• ❌ "处理异常" → ✅ "处理网络错误（超时、断网）、服务器错误（4xx、5xx）、数据格式错误"
• ❌ "支持移动端" → ✅ "支持 320px-1920px 宽度，触摸操作，横竖屏切换"

实战技巧：使用量化指标

把模糊的要求变成可测量的指标：

模糊要求	量化指标
"性能好"	"渲染时间 < 16ms，内存 < 100MB"
"代码质量高"	"ESLint 0 warning，测试覆盖率 > 80%"
"用户体验好"	"首屏 < 1s，交互响应 < 100ms"
"兼容性好"	"Chrome 90+, Safari 14+, Firefox 88+"

常见陷阱：假具体

看起来具体，实际上还是模糊：

❌ 假具体：

优化这个函数，让它更快、更好、更稳定

✅ 真具体：

优化这个函数：
- 性能：时间复杂度从 O(n²) 降到 O(n log n)
- 稳定性：添加输入验证，处理边界情况（空数组、null、undefined）
- 可维护性：添加 JSDoc 注释，提取可复用逻辑

法则 2：给足上下文

❌ 缺少上下文：

修复这个 bug

✅ 提供上下文：

在用户登录功能中，当输入错误的密码时，页面会崩溃。
错误信息显示：'Cannot read property 'token' of undefined'。
请检查登录 API 调用的错误处理逻辑。

没有上下文，AI 根本不知道你在说什么。

深入分析：上下文的层次和优先级

上下文不是越多越好，而是要相关且必要。我总结了一个上下文优先级模型：

P0 上下文（必须）：

• 当前代码：正在处理的代码片段
• 错误信息：具体的错误消息和堆栈
• 复现步骤：如何触发问题

P1 上下文（重要）：

• 相关文件：导入的文件、被导入的文件
• 技术栈：使用的框架、库、版本
• 业务逻辑：功能需求和用户场景

P2 上下文（可选）：

• 项目结构：整体架构和组织方式
• 历史背景：为什么这样设计
• 未来计划：后续可能的变化

实战技巧：上下文的选择策略

1. 相关性原则：只提供与当前任务相关的上下文

   • Bug 修复 → 错误信息、相关代码、复现步骤
   • 代码重构 → 当前代码、相关文件、架构模式
   • 性能优化 → 性能数据、瓶颈分析、优化目标

2. 最小化原则：提供最少的必要上下文

   • 不要复制整个文件，只复制相关部分
   • 不要列出所有依赖，只列出关键依赖
   • 不要描述整个项目，只描述相关模块

3. 结构化原则：用结构化的方式组织上下文

   上下文信息：
   
   ## 当前问题
   [问题描述]
   
   ## 相关代码
   [代码片段]
   
   ## 错误信息
   [错误详情]
   
   ## 环境信息
   [技术栈、版本等]

高级技巧：动态上下文

根据对话进展，动态调整上下文：

• 第一轮：提供基础上下文，让 AI 理解问题
• 第二轮：如果 AI 理解有偏差，补充更具体的上下文
• 第三轮：针对 AI 的问题，提供精确的上下文

常见陷阱：上下文过载

提供太多不相关的上下文，反而会干扰 AI：

❌ 上下文过载：

修复这个 bug。项目是用 React 18 + TypeScript 5.0 + Vite 4.0 构建的，
使用了 Redux Toolkit 做状态管理，Tailwind CSS 做样式，Jest 做测试，
ESLint 做代码检查，Prettier 做格式化，GitHub Actions 做 CI/CD...
[然后才说实际的 bug]

✅ 精准上下文：

修复以下 bug：
- 问题：用户登录后，页面显示空白
- 错误：控制台显示 'Cannot read property 'user' of undefined'
- 位置：src/features/auth/components/LoginForm.tsx:45
- 相关代码：[只包含相关的代码片段]

法则 3：复杂任务分步骤

遇到复杂的功能，别一次性说完，分步骤来。

比如：

请按以下步骤实现用户认证功能：
1. 创建登录表单组件（包含邮箱和密码输入）
2. 实现表单验证逻辑
3. 集成认证 API
4. 处理成功和失败场景
5. 添加加载状态和错误提示

这样 AI 更容易理解，你也能一步步确认。

深入分析：分步骤的策略

分步骤不是简单的"1、2、3"，而是要遵循一定的策略：

策略 1：依赖关系优先

• 先做基础功能，再做增强功能
• 先做核心逻辑，再做边缘情况
• 先做功能实现，再做性能优化

策略 2：可验证性优先

• 每个步骤都能独立验证
• 每个步骤都有明确的完成标准
• 每个步骤都能看到实际效果

策略 3：风险控制优先

• 高风险步骤先做，早发现问题
• 关键路径先做，确保核心功能
• 依赖外部系统的步骤后做，减少阻塞

高级分步骤示例：

实现用户认证系统，按以下步骤进行：

## 阶段 1：基础功能（必须完成）
1. 创建登录表单 UI
   - 输入框：邮箱、密码
   - 按钮：登录、注册
   - 验证：前端基础验证（非空、格式）
   - 验证标准：表单能正常显示和输入

2. 实现 API 集成
   - 创建 API 服务函数
   - 处理请求/响应
   - 错误处理：网络错误、服务器错误
   - 验证标准：能成功调用 API，处理错误

## 阶段 2：增强功能（重要）
3. 完善表单验证
   - 邮箱格式验证
   - 密码强度验证
   - 实时反馈
   - 验证标准：所有验证规则生效

4. 状态管理
   - 用户状态存储
   - 登录状态持久化
   - 路由保护
   - 验证标准：登录状态正确保存和恢复

## 阶段 3：优化和增强（可选）
5. 用户体验优化
   - 加载状态
   - 错误提示
   - 成功反馈
   - 验证标准：用户操作有明确反馈

6. 安全性增强
   - Token 刷新
   - 自动登出
   - 安全存储
   - 验证标准：符合安全最佳实践

技巧：使用检查点

在每个步骤后设置检查点，确保质量：

步骤 1：创建基础组件
- 完成标准：组件能正常渲染
- 检查点：通过 TypeScript 编译，无 ESLint 错误
- 下一步：确认后再继续

步骤 2：添加功能逻辑
- 完成标准：功能正常工作
- 检查点：通过单元测试，手动测试通过
- 下一步：确认后再继续

常见陷阱：步骤划分不当

1. 步骤太细：每个小改动都算一步，导致步骤过多
2. 步骤太粗：一个步骤包含太多内容，难以验证
3. 步骤无序：没有考虑依赖关系，导致无法执行
4. 缺少验证：没有明确的完成标准，不知道什么时候算完成

法则 4：给示例最管用

有时候说再多，不如给个例子。

比如：

创建一个工具函数，用于格式化日期。
输入示例：'2024-01-15'
输出示例：'2024年1月15日'

看到例子，AI 立马就知道你要什么格式了。

深入分析：示例的类型和作用

示例不只是"输入输出"，有多种类型，每种都有不同的作用：

类型 1：输入输出示例（最常用）

• 作用：明确数据格式和转换规则
• 适用：工具函数、数据转换、格式化

创建一个日期格式化函数：
输入：'2024-01-15' → 输出：'2024年1月15日'
输入：'2024-12-25' → 输出：'2024年12月25日'

类型 2：代码风格示例（保持一致性）

• 作用：展示期望的代码风格和模式
• 适用：代码重构、新功能开发

参考以下代码风格创建新组件：
[示例代码：展示命名、结构、注释风格]

要求新组件保持相同的风格。

类型 3：行为示例（明确交互）

• 作用：描述用户交互和系统响应
• 适用：UI 组件、交互功能

实现搜索功能：
- 用户输入 "react" → 显示匹配结果，高亮 "react"
- 用户输入空字符串 → 显示所有结果
- 用户输入不存在的关键词 → 显示 "未找到结果"

类型 4：边界情况示例（处理异常）

• 作用：明确如何处理边界和异常情况
• 适用：错误处理、数据验证

处理用户输入：
- 正常输入："user@example.com" → 通过验证
- 边界情况："" → 返回错误 "邮箱不能为空"
- 异常情况：null → 返回错误 "邮箱格式不正确"

类型 5：完整场景示例（端到端）

• 作用：展示完整的使用场景
• 适用：复杂功能、系统集成

实现用户注册流程：
1. 用户填写表单（邮箱、密码、确认密码）
2. 点击注册按钮
3. 显示加载状态
4. 调用注册 API
5. 成功：显示成功消息，跳转登录页
6. 失败：显示错误消息，保持表单数据

高级技巧：多示例对比

用多个示例展示不同的场景：

创建表单验证函数，支持以下场景：

场景 1：正常情况
输入：{ email: "user@example.com", password: "Password123" }
输出：{ valid: true, errors: {} }

场景 2：邮箱格式错误
输入：{ email: "invalid-email", password: "Password123" }
输出：{ valid: false, errors: { email: "邮箱格式不正确" } }

场景 3：密码太短
输入：{ email: "user@example.com", password: "123" }
输出：{ valid: false, errors: { password: "密码至少8位" } }

场景 4：多个错误
输入：{ email: "invalid", password: "123" }
输出：{ valid: false, errors: { email: "邮箱格式不正确", password: "密码至少8位" } }

常见陷阱：示例不充分

1. 只有正常情况：没有边界情况和异常处理
2. 示例太少：只有一个示例，无法覆盖所有场景
3. 示例不典型：选择了不常见的场景，误导 AI
4. 示例过时：使用了旧版本的 API 或模式

法则 5：明确边界

告诉 AI 什么该做，什么不该做。

比如：

实现一个搜索功能：
- 应该：支持模糊搜索、实时搜索、高亮匹配结果
- 不应该：修改现有的数据模型、影响其他功能

这样 AI 就不会乱改你的代码了。

深入分析：边界的多个维度

边界不只是"应该"和"不应该"，要从多个维度明确：

维度 1：功能边界

• 做什么：明确要实现的功能
• 不做什么：明确不要实现的功能
• 做到什么程度：明确功能的完整性和深度

维度 2：代码边界

• 可以修改：哪些文件可以改
• 不能修改：哪些文件不能动
• 可以新增：可以创建哪些新文件
• 不能新增：不能创建哪些文件

维度 3：影响边界

• 可以影响：哪些功能可以受影响
• 不能影响：哪些功能必须保持不变
• 兼容性要求：必须保持向后兼容

维度 4：技术边界

• 可以使用：哪些技术、库、API
• 不能使用：哪些技术被禁止
• 版本限制：必须使用特定版本

高级边界定义示例：

实现搜索功能，边界如下：

## 功能边界
应该实现：
- ✅ 实时搜索（输入时即时显示结果）
- ✅ 模糊匹配（支持部分关键词匹配）
- ✅ 结果高亮（高亮匹配的关键词）
- ✅ 空状态处理（无结果时显示提示）

不应该实现：
- ❌ 搜索历史（不在本次需求内）
- ❌ 搜索建议（不在本次需求内）
- ❌ 高级筛选（不在本次需求内）

## 代码边界
可以修改：
- ✅ src/features/search/ 目录下的所有文件
- ✅ src/shared/components/SearchInput.tsx（如果存在）

不能修改：
- ❌ src/features/user/ 目录（用户相关功能）
- ❌ src/api/ 目录（API 接口定义）
- ❌ src/types/ 目录（全局类型定义）

可以新增：
- ✅ src/features/search/components/ 下的新组件
- ✅ src/features/search/hooks/ 下的新 Hook

## 影响边界
可以影响：
- ✅ 搜索结果展示区域
- ✅ 搜索输入框的交互

不能影响：
- ❌ 其他功能的正常使用
- ❌ 现有的数据流和状态管理
- ❌ 页面的其他部分

兼容性要求：
- ✅ 必须保持现有 API 接口不变
- ✅ 必须保持现有组件接口不变

## 技术边界
必须使用：
- ✅ React 18.2（项目当前版本）
- ✅ TypeScript 5.0 strict mode
- ✅ 项目现有的状态管理方案

不能使用：
- ❌ 新的第三方库（除非必要且经过批准）
- ❌ 实验性的 API 或特性
- ❌ 已废弃的 API

技巧：使用白名单和黑名单

用白名单（允许）和黑名单（禁止）明确边界：

## 白名单（允许）
- 可以使用的技术：React Hooks, TypeScript, Tailwind CSS
- 可以修改的文件：src/components/Search/
- 可以实现的功能：搜索、高亮、过滤

## 黑名单（禁止）
- 不能使用的技术：jQuery, class 组件
- 不能修改的文件：src/api/, src/types/
- 不能实现的功能：搜索历史、高级筛选

常见陷阱：边界不明确

1. 只说"应该"，不说"不应该"：AI 可能实现多余的功能
2. 边界太宽泛："不影响其他功能"太模糊，应该具体说明
3. 边界冲突：同时说"可以修改"和"不能修改"同一文件
4. 缺少验证：没有说明如何验证边界是否被遵守

---

总结

1. 提示词的本质：是与 AI 模型的交互协议，质量直接影响输出
2. 提示词的重要性：好的提示词能大幅提高开发效率
3. 提示词的结构：包含角色、任务、上下文、约束、输出格式 5 个部分
4. 黄金法则：具体明确、给足上下文、分步骤、给示例、明确边界

掌握了这些基础知识，你就可以开始写有效的提示词了。