「问对问题，比得到答案更重要。」
开场：同一个 AI，为什么别人用起来比你强
小维和他的同事老李，都在用 Cursor 做 Vibe Coding。
两个人都让 AI 帮忙写一个"用户登录功能"。
老李的提示词：
写一个用户登录功能
小维的提示词：
用 Express.js + JWT 实现用户登录接口：
POST /api/auth/login
请求体：{ email: string, password: string }
处理逻辑：
1. 检查 email 格式是否合法
2. 查询数据库验证用户是否存在
3. 用 bcrypt 验证密码
4. 生成 JWT Token（有效期 7 天）
5. 返回：{ token: string, user: { id, email, username } }
错误处理：
- 用户不存在 → 401 { error: "邮箱或密码错误" }
- 密码错误 → 401 { error: "邮箱或密码错误" }（不区分，防止枚举攻击）
- 参数缺失 → 400 { error: "参数错误" }
使用已有的 User Model（文件在 models/user.js）
结果可想而知：老李得到了一个不完整的、需要大量修改的实现；小维得到了一个可以直接使用的完整接口。
两个人用的是同一个 AI——差别在提示词。
全局视角：提示词工程的知识体系
mindmap
root((提示词工程))
第07讲-本讲
提示词的本质
为什么会被误解
信息完整性理论
第08讲
结构化提示词
黄金公式
第09讲
上下文管理
第10讲
迭代式提示词
第11讲
系统提示词
第12讲
提示词模板库
第13讲
元提示词
核心知识点一：AI 误解提示词的三个根本原因
原因一：歧义性——同一句话有多种理解
人类在交流时，依赖大量的"默认共识"来消除歧义。
比如："帮我做一个登录功能"——我们脑子里有很多默认假设：
- 是 Web 登录？还是 App 登录？还是 CLI 登录？
- 用什么技术栈？
- 密码要加密吗？
- 需要"记住我"功能吗？
- 需要多因素认证吗？
这些默认假设在不同人、不同场景下完全不同。
AI 没有这些默认共识——或者更准确地说，它有自己的默认假设，但那些假设未必和你一样。
解决方案：在提示词里明确消除歧义——把你的"默认假设"写出来。
原因二：不完整性——缺少关键上下文
人类的大脑非常擅长"脑补"——即使信息不完整，我们也能推断出说话者的意图。
AI 的脑补能力远不如人类，特别是在技术细节上。
典型场景：
你说："帮我优化这个数据库查询，让它更快"
AI 给你了几个优化方案，但它不知道：
- 你的数据量是多大？（100行 vs 1亿行的优化策略完全不同）
- 哪些字段已经有索引了？
- 查询现在的执行时间是多少？
- 你能接受多大的代码复杂度增加？
解决方案：在提示词里提供关键上下文信息。
原因三：抽象层次不匹配
有时候提示词太抽象，AI 不知道你想要什么；有时候提示词太具体，AI 的回答反而变窄了。
太抽象：
帮我优化这段代码
（AI 不知道从哪个维度优化：性能？可读性？安全性？代码量？）
太具体（但具体点选错了）：
把第 47 行的 for 循环改成 map
（如果问题不是在 for 循环上，这个改动毫无意义）
恰当的抽象层次：
这段代码的执行时间在数据量 10 万条时超过了 3 秒，
帮我分析性能瓶颈在哪里，并给出优化方案，
目标是将执行时间降到 1 秒以内，
允许增加适当的代码复杂度
解决方案：用"目标+约束"的方式描述需求，而不是"具体操作"。
核心知识点二：提示词的信息完整性理论
一个好的提示词，需要包含以下四个维度的信息：
graph TD
A["完整的提示词"] --> B["意图 (What)\n你想要什么结果"]
A --> C["上下文 (Context)\n相关的背景信息"]
A --> D["约束 (Constraints)\n不能做什么、限制是什么"]
A --> E["格式 (Format)\n你希望输出是什么形式"]
B --> B1["功能需求\n业务逻辑\n预期效果"]
C --> C1["已有代码\n技术栈\n数据结构\n业务背景"]
D --> D1["不使用X框架\n不改变Y接口\n必须兼容Z版本\n性能限制"]
E --> E1["代码？文档？\n步骤说明？\n对比表格？"]
框架记忆：意图 + 上下文 + 约束 + 格式 = ICCE
不是每个提示词都需要所有四个维度，但复杂任务通常都需要。
核心知识点三：信息密度 vs 提示词长度
很多人有一个误区：提示词越长越好。
错。提示词的质量不在于长度，而在于信息密度——每一句话是否都包含了对 AI 有用的信息。
低信息密度的提示词（长但没用）：
我是一个 Python 程序员，我在做一个项目，这个项目需要处理一些数据。
我有一个需求，就是需要对一些数据进行处理，具体来说是要把这些数据从
一种格式转换成另一种格式。希望你能帮我实现这个功能，谢谢。
高信息密度的提示词（短但有用）：
把 JSON 格式的用户数据转换成 CSV 格式。
输入：[{"name": "John", "age": 30}, ...]
输出：CSV 文件，第一行是 name,age 的列头
用 Python，使用 csv 模块，不用第三方库
原则：去掉所有对 AI 没有指导意义的废话，保留所有具体的、有用的信息。
深度拆解：解析 5 种常见的糟糕提示词
类型一：纯任务型（缺少上下文）
帮我写一个排序函数
问题：排序什么数据？升序还是降序？什么语言？有没有性能要求？
改进：
用 Python 写一个函数，对字典列表按某个键排序：
- 函数签名：sort_by_key(data: list[dict], key: str, reverse: bool = False)
- 如果 key 不存在，该元素排到最后
- 时间复杂度要求：O(n log n)
类型二：抽象型（缺少具体需求）
帮我优化用户体验
问题：哪个页面？哪个流程？什么样的用户体验问题？
改进：
我的用户注册流程目前是三步页面跳转，
用户反馈感觉很慢，想要更流畅的体验。
帮我把它改成单页面的步骤组件（类似 GitHub 注册的那种），
用 React，不用引入额外的 form 库
类型三：矛盾型（约束互相冲突）
帮我写一个函数，要求代码简洁，但同时要处理所有可能的异常情况
问题："简洁"和"处理所有异常"在很多情况下是矛盾的。AI 不知道哪个优先级更高。
改进：
写一个文件读取函数，优先考虑代码简洁性，
只处理最常见的异常（文件不存在、没有权限），
其他异常可以直接抛出
类型四：多任务型（一个提示词里塞了太多需求）
帮我做用户注册、登录、找回密码、修改密码、注销账号这些功能
问题：这是 5 个独立的功能，一起做质量会很差。
改进：分开来说，一次一个功能。
类型五：假设型（假设 AI 知道你知道的）
按照上次的方式，帮我再做一个类似的功能
问题：AI 没有"上次"的记忆（每次对话都是全新开始），不知道"上次的方式"是什么。
改进：每次都提供完整的上下文，不依赖 AI 记住历史。
案例解析：一个提示词的逐步升级过程
需求：写一个发送邮件的功能
版本一（糟糕）：
帮我写一个发送邮件的功能
版本一的问题：
- 不知道用什么邮件服务（SMTP？SendGrid？AWS SES？）
- 不知道用什么语言
- 不知道邮件内容是什么格式
- 不知道是否需要 HTML 邮件
版本二（好一点）：
用 Node.js 写一个发送邮件的功能，使用 Nodemailer 库
版本二的问题：
- 虽然指定了语言和库，但仍缺少：邮件服务器配置方式、错误处理、是否支持 HTML、异步处理方式
版本三（好很多）：
用 Node.js + Nodemailer 写一个发送邮件的工具函数：
函数签名：sendEmail({ to, subject, html, text })
- to: 收件人（字符串或字符串数组）
- subject: 邮件标题
- html: HTML 格式的邮件内容（可选）
- text: 纯文本格式的邮件内容（可选，html 不存在时使用）
- 返回: Promise<{ messageId: string }>
SMTP 配置从环境变量读取：
- SMTP_HOST, SMTP_PORT, SMTP_USER, SMTP_PASS
- 发件人用 SMTP_USER
错误处理：
- 连接失败时抛出 Error('SMTP connection failed')
- 发送失败时抛出 Error('Email send failed: [原始错误信息]')
额外要求：
- 用 async/await，不用回调
- 包含 TypeScript 类型定义
最终效果：版本三得到的代码几乎可以直接使用，版本一得到的代码还需要大量补充。
实操指南：提示词自检清单
在发送每个提示词之前，用这个清单检查一遍：
基础检查（每次都做）：
- 意图清晰了吗？AI 能知道你要做什么吗？
- 技术栈指定了吗？（语言、框架、库）
- 有没有关键的上下文缺失？
完整性检查（复杂任务）：
- 输入/输出格式说清楚了吗？
- 错误处理要求说了吗？
- 不能做什么（负向约束）说了吗？
- 和已有代码的集成方式说了吗？
质量检查（高要求任务）：
- 性能要求说清楚了吗？
- 测试要求说清楚了吗？
- 代码风格要求说了吗？
本讲小结
mindmap
root((提示词本质))
误解的三个原因
歧义性
不完整性
抽象层次不匹配
完整提示词四要素
意图What
上下文Context
约束Constraints
格式Format
信息密度原则
去掉废话
保留具体信息
长度服从质量
五种糟糕提示词
纯任务型
抽象型
矛盾型
多任务型
假设型
思考题
-
回顾你过去一周用 AI 编程的经历，找一个 AI 给你的结果和你期望不符的案例。用这一讲的框架分析，是什么原因导致了误解？
-
有人说"会写提示词是一种新的编程语言"，你同意这个类比吗？提示词和编程语言有哪些相似之处，哪些根本不同？
-
在这一讲里，我们强调了"信息完整性"。但有些情况下，给 AI 太多信息也会让它表现变差（比如会被无关信息分散注意力）。你怎么判断一个信息应不应该放进提示词？
下一讲预告
这一讲我们搞清楚了提示词为什么会失败。
下一讲，我们来讲最实用的工具：结构化提示词的黄金公式——角色 + 任务 + 上下文 + 约束的组合方式。
这是一个可以立刻套用的模板，能让你的提示词质量提升一个等级。
