编程 Prompt 的核心原则

编程 Prompt 的核心原则

本节摘要:跟 AI 写代码和跟同事沟通需求本质相同——你表达得越精准,对方交付得越接近预期。但编程 Prompt 有其独特性:它需要技术约束(框架、版本、风格)、需要代码上下文(相关文件、接口签名)、需要可验证的输出标准。本节提炼出四大核心原则——角色设定、上下文注入、约束明确、分步拆解——并对比编程场景与通用对话的关键差异,帮你建立「下需求单」而非「闲聊」的思维模式。

一、编程 Prompt 与通用对话的本质差异

很多人把跟 AI 编程当成「高级版搜索引擎」——丢一句话过去,等它给答案。这是效率最低的方式。

通用对话:「帮我写个排序算法」→ AI 给你一段教科书代码,可能跟你的项目毫无关系。

编程 Prompt:「在 src/utils/sort.ts 中,给 sortByDate 函数加上降序排列选项,参数名为 desc,默认 false。使用项目现有的 compareDates 工具函数。不要引入新依赖。」→ AI 给你一段能直接用的代码。

差异在哪?后者提供了:位置(哪个文件)、上下文(现有函数)、约束(不引入新依赖)、规格(参数名和默认值)。

关键概念:编程 Prompt 的本质不是「提问」,而是「下需求单」。你是在给一个能力极强但完全不了解你项目的「远程开发者」写技术需求文档。

二、原则一:角色设定

让 AI 进入特定的技术视角,输出会更专业、更聚焦。

不用角色:「帮我写个 API」→ 可能给你 Flask、可能给你 Express、可能给你 Spring Boot。

用角色:「你是一个资深 FastAPI 开发者,熟悉 Pydantic v2 和 SQLAlchemy 2.0 的异步模式。请帮我写一个用户注册接口。」→ 输出会严格遵循 FastAPI 的最佳实践。

常用角色模板:

• 「你是一个 {框架} 专家,熟悉 {版本} 的 API」
• 「你是一个注重代码质量的 reviewer,关注 {安全/性能/可维护性}」
• 「你是一个 {前端/后端/DevOps} 工程师,项目技术栈是 {具体技术}」

💡 技巧:角色设定不需要每次都写。如果你用 .cursorrules 或项目级指令(第 4 章详讲),可以把角色设定写进配置文件,一劳永逸。

三、原则二:上下文注入

AI 不知道你项目的细节——除非你告诉它。上下文注入是编程 Prompt 中最影响输出质量的因素。

需要注入的上下文类型:

Cursor 中的上下文注入方式:

• @file:src/api/user.ts — 引用特定文件
• @folder:src/components — 引用整个目录
• @codebase — 让 AI 自动搜索(适合不确定相关文件时)
• 直接选中代码后按 Cmd+K — 选中内容自动成为上下文

⚠️ 注意:上下文不是越多越好。塞入 20 个不相关的文件,反而会「稀释」关键信息,让 AI 输出质量下降。原则是:精准喂入相关的 3~5 个文件,胜过模糊地 @codebase 全项目。

四、原则三:约束明确

没有约束的 Prompt,AI 会按「统计上最常见的写法」输出——这可能跟你的项目风格完全不一致。

需要明确的约束:

• 技术选型:「用 Tailwind CSS,不要写自定义 CSS」
• 代码风格:「函数式组件,不用 class;变量用 camelCase」
• 版本限制:「用 Pydantic v2 语法,不要用 v1 的 class Config」
• 禁止事项:「不要引入新的 npm 包」「不要修改公共接口签名」
• 输出格式:「只给修改的部分,不要重复未改动的代码」

好的约束示例:

约束:
- 使用 TypeScript strict 模式
- 错误处理用 Result 模式,不要 try-catch
- 组件文件用 PascalCase 命名
- 不要使用 any 类型
​

💡 技巧:约束越具体越好。「写好代码」不是约束;「所有公开函数必须有 JSDoc 注释,包含 @param 和 @returns」才是约束。

五、原则四:分步拆解

大任务一次性丢给 AI,它容易「顾头不顾尾」。把大任务拆成可验证的小步,每步确认后再进行下一步。

反面示例:「帮我做一个完整的用户系统,包括注册、登录、权限管理、邮箱验证、密码重置。」

正面示例:

1. 第一步:「先设计 User 数据模型,包含 email、password_hash、role、verified 字段」→ 确认
2. 第二步:「基于这个模型,写注册接口,包含邮箱格式验证和密码强度检查」→ 确认
3. 第三步:「写登录接口,返回 JWT token,用项目现有的 generateToken 工具函数」→ 确认
4. ...

分步的好处:

• 每步输出量小,质量更可控
• 发现问题可以立刻纠正,不会「错上加错」
• AI 的上下文窗口不会被一次性撑满
• 你可以在每步之间插入自己的判断和调整

⚠️ 注意:分步不意味着「每行代码都要问 AI」。一个合理粒度是:每步对应一个「可独立验证的功能单元」——一个接口、一个组件、一个工具函数。

六、四原则的组合运用

一个高质量编程 Prompt 的完整结构:

[角色] 你是一个 React + TypeScript 前端专家。

[上下文] 项目用 Next.js 14 App Router,状态管理用 Zustand。
@file:src/stores/userStore.ts
@file:src/components/UserProfile.tsx

[任务] 给 UserProfile 组件加上「编辑头像」功能:
- 点击头像弹出文件选择器
- 选择图片后预览,确认后上传到 /api/avatar
- 上传成功后更新 userStore 中的 avatarUrl

[约束]
- 用 Next.js 的 Image 组件做预览
- 文件大小限制 2MB,格式限 jpg/png
- 不要引入新的 UI 库,用现有的 Tailwind 样式
- 上传失败时显示 toast 提示

[输出] 只给需要修改/新增的代码,标注文件路径。
​

这个 Prompt 大约 200 字,但信息密度极高。AI 拿到后,输出基本能直接用。

本节要点回顾

1. 思维转换:编程 Prompt 是「下需求单」,不是「搜索引擎提问」
2. 角色设定:让 AI 进入特定技术栈视角,输出更专业聚焦
3. 上下文注入:精准喂入 3~5 个相关文件,胜过模糊的 @codebase
4. 约束明确:技术选型、代码风格、版本限制、禁止事项——越具体越好
5. 分步拆解:大任务拆成「可独立验证的功能单元」,逐步确认
6. 组合运用:角色 + 上下文 + 任务 + 约束 + 输出格式 = 高质量 Prompt

掌握了核心原则后,下一步是了解这些原则在不同交互模式中如何落地。下一节我们讲 Chat 模式和 Inline Edit 的使用时机与操作技巧。