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

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

什么是提示词？

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

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

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

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

上下文窗口有限：虽然 Cursor 能读取项目文件，但模型能"记住"的上下文是有限的。好的提示词能最大化利用这个上下文窗口。
模式匹配机制：模型通过匹配训练数据中的模式来生成代码。如果你的提示词能触发正确的模式，就能得到更好的结果。
多轮对话能力：Cursor 支持多轮对话，但每轮对话的质量会影响后续对话。第一轮提示词写得好，后续优化就容易。
代码感知能力：Cursor 能理解项目结构，但你需要明确告诉它要关注哪些文件、哪些模式。

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

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

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

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

Cursor 里提示词能干啥？

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

Cursor 到底强在哪？

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

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

为什么提示词这么重要？

提示词写得好，事半功倍

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

一个对比你就明白了

❌ 这样写（太简单）：

复制代码

写个函数

✅ 这样写（清晰具体）：

sql 复制代码

创建一个 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 开发工程师，擅长性能优化和最佳实践。

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

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

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

激活相关模式：模型会优先激活与这个角色相关的训练数据模式
- "React 工程师" → 激活 React 最佳实践、Hooks、性能优化等模式
- "数据科学家" → 激活数据处理、统计分析、机器学习等模式
调整输出风格：不同角色的代码风格不同
- 前端工程师：更关注用户体验、响应式设计
- 后端工程师：更关注性能、安全性、可扩展性
影响技术选择：模型会根据角色选择合适的技术栈
- 前端：React、Vue、Angular
- 后端：Node.js、Python、Go

什么时候需要角色定义？

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

高级技巧：组合角色

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

diff 复制代码

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

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

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

比如：

复制代码

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

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

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

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

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

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

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

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

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

示例对比：

❌ 只有层次 1：

复制代码

重构这个组件

✅ 包含层次 1+2：

复制代码

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

✅✅ 包含所有层次：

diff 复制代码

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

任务描述的常见陷阱：

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

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

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

比如：

css 复制代码

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

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

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

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

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

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

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

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

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

示例：完整的上下文信息

markdown 复制代码

项目上下文：
- 技术栈：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 会自动读取：

css 复制代码

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

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

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

比如：

diff 复制代码

要求：
- 必须使用 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 标准

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

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

markdown 复制代码

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

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

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

❌ 太宽泛：

复制代码

要求：代码质量要高

✅ 具体明确：

diff 复制代码

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

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

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

比如：

markdown 复制代码

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

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

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

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

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

2. 便于后续处理

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

3. 减少歧义

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

高级输出格式示例：

ini 复制代码

请按以下格式输出：

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

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

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

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

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

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

输出格式的常见问题：

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

技巧：根据任务调整格式

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

写提示词的几个黄金法则

法则 1：越具体越好

❌ 太模糊：

复制代码

优化这个函数

✅ 具体明确：

scss 复制代码

优化这个函数的性能，将时间复杂度从 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+"

常见陷阱：假具体

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

❌ 假具体：

复制代码

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

✅ 真具体：

scss 复制代码

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

法则 2：给足上下文

❌ 缺少上下文：

复制代码

修复这个 bug

✅ 提供上下文：

bash 复制代码

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

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

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

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

P0 上下文（必须）：

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

P1 上下文（重要）：

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

P2 上下文（可选）：

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

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

相关性原则：只提供与当前任务相关的上下文
- Bug 修复 → 错误信息、相关代码、复现步骤
- 代码重构 → 当前代码、相关文件、架构模式
- 性能优化 → 性能数据、瓶颈分析、优化目标
最小化原则：提供最少的必要上下文
- 不要复制整个文件，只复制相关部分
- 不要列出所有依赖，只列出关键依赖
- 不要描述整个项目，只描述相关模块

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

ini 复制代码

上下文信息：

## 当前问题
[问题描述]

## 相关代码
[代码片段]

## 错误信息
[错误详情]

## 环境信息
[技术栈、版本等]

高级技巧：动态上下文

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

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

常见陷阱：上下文过载

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

❌ 上下文过载：

css 复制代码

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

✅ 精准上下文：

python 复制代码

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

法则 3：复杂任务分步骤

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

比如：

markdown 复制代码

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

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

深入分析：分步骤的策略

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

策略 1：依赖关系优先

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

策略 2：可验证性优先

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

策略 3：风险控制优先

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

高级分步骤示例：

markdown 复制代码

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

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

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

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

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

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

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

技巧：使用检查点

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

diff 复制代码

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

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

常见陷阱：步骤划分不当

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

法则 4：给示例最管用

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

比如：

arduino 复制代码

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

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

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

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

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

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

arduino 复制代码

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

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

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

css 复制代码

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

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

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

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

arduino 复制代码

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

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

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

csharp 复制代码

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

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

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

markdown 复制代码

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

高级技巧：多示例对比

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

yaml 复制代码

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

场景 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位" } }

常见陷阱：示例不充分

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

法则 5：明确边界

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

比如：

diff 复制代码

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

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

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

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

维度 1：功能边界

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

维度 2：代码边界

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

维度 3：影响边界

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

维度 4：技术边界

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

高级边界定义示例：

markdown 复制代码

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

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

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

## 代码边界
可以修改：
- ✅ 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

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

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

markdown 复制代码

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

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

常见陷阱：边界不明确

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

总结

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

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