提示词工程——为什么你写了 500 字提示词，AI 还是不懂你？

症状

先讲一个我闭着眼都能复述的画面：你把需求写成了 500 字的小作文，角色、背景、要求、注意事项全部安排上，满怀期待地发给 AI，结果它给你吐出一段"看起来什么都说了，其实什么都没说"的答案。你追问"不对，我要的不是这个"，它道歉、重来，然后给你一段换汤不换药的版本。你开始怀疑人生：是我没说清楚，还是这 AI 真的不行？

还有更常见的一种：你跟 AI 说"帮我写一个订单模块"，它真的给你写了一个——用你根本没用过的框架、你项目里根本不存在的依赖、你完全没提过的假设。你问它为什么这么写，它说"根据最佳实践"。那一刻你想把它从屏幕上拽出来摇醒：**这个项目是 Java 8 + Spring Boot 2，不是你说的那个"现代技术栈"！**

也有人在另一个极端：觉得提示词就是聊天，想到哪说到哪。结果同一个任务，上午跑出来一个样，下午跑出来一个样；改一个词，输出全变；不改词，输出也变。你没法复现、没法调试、没法把"上次那个好结果"稳定地再要一次。于是你觉得 AI 就是个碰运气的玩具，弃了。

还有一群人走在中间：他们抄了一堆"万能模板"——什么"你是一位资深专家""请一步一步思考"——但换到自己的场景就失效。模板里的角色是"资深前端工程师"，你的需求是"帮我看一下这段 SQL 为什么慢"；模板要求"输出 Markdown 表格"，你的下游程序要的是 JSON。抄来的模板像借来的西装，穿着不合身，又不知道哪里改。

如果你正在经历这些——提示词越写越长 AI 越跑越偏、同一个任务每次结果都不一样、抄了模板不会改、或者干脆觉得"提示词工程就是玄学"——这篇文章是写给同类人的。它不是 Prompt 大全，是那些真把提示词当工程做过的人，用几千次无效对话换来的共识：**提示词不是聊天，是给 AI 写的接口文档——你有结构化、可复用、可迭代的输入，才有稳定、可靠、可预测的输出。**

原因

先想清楚：为什么提示词这么难写？四个原因，每个都指向同一件事——**模糊的输入，必然得到概率的输出。**

**第一，大模型是概率机器，不是搜索引擎。** 它的训练目标是"预测下一个词"，输出质量直接取决于输入提示词的清晰度与结构。你给它模糊的指令，它就只能做概率猜测——猜测你的业务背景、猜测你要的格式、猜测你没说的约束。猜得多了，"幻觉"和"答非所问"就是必然结果。不是它笨，是你给它的信息熵太高了。

**第二，上下文不在提示词里，AI 就只能替你编。** 你的项目用什么技术栈、哪个文件是干嘛的、这个功能要兼容什么历史行为——这些你脑子里有，提示词里没有，AI 就只好凭文件名猜、凭模板经验改、凭局部页面判断全局规则。它"看起来能跑"，是因为它把所有你没说的假设都替你做了，而你的真实业务规则，恰恰藏在那些你没说的部分里。

**第三，没有评估，就没有迭代。** 写代码你有一万种方式验证对不对：编译、测试、跑一遍看结果。写提示词呢？大多数人"写完即用、用完即忘"——这次好还是坏，为什么好为什么坏，没有任何记录。没有评估标准，就没有迭代依据，提示词水平就永远停在"碰运气"。

**第四，把提示词当"写作"而不是"工程"。** 一次写一大段、每次都从头写、改全靠手感——这是写作思维。工程思维是：拆结构（角色/任务/约束/示例/输出）、建模板（可复用）、做版本（可对比）、定指标（可评估）。写作思维让提示词永远是一次性消耗品，工程思维才让它变成可积累的资产。**提示词工程的核心不是"会说话"，是"把话说成可维护的系统"。**

解法

下面每条经验都按「现象 → 做法 → 为什么」展开。它们不是一家之言，而是多篇独立实践里反复出现的共识。

### 经验 0（L1 一句话结论）：提示词 = 角色 + 任务 + 约束 + 示例 + 输出格式

**五件套说全，AI 才不用猜。** 赶时间只看这一条：下次写提示词，先检查这五样缺不缺——角色（以谁的视角做）、任务（做什么）、约束（不能做什么/边界是什么）、示例（长什么样算对）、输出格式（交什么形状的东西）。下面经验 1~6 是为什么和怎么做。

### 经验 1：分层写，别写小作文——上下文、任务、格式三件套

现象：我见过最典型的失败提示词，是"帮我写一个 Express 的错误处理中间件"——一句话，什么都没说。AI 当然能写，但它会写一个"通用版本"：不知道你的项目是 JavaScript 还是 TypeScript、不知道你有没有自定义错误类、不知道你要不要日志、要不要测试。于是你拿到一个哪都不挨着的中间件，改的时间比自己写还长。

反过来，也有人走向另一个极端：把 500 字小作文一次砸给 AI，背景、情绪、要求、历史、注意事项全搅在一起——AI 照样跑偏，因为信息挤成一团，它分不清哪个是约束、哪个是背景、哪个是任务。

做法：把提示词分成清晰的三层，每层只说一件事：①**上下文（Context）**——项目背景和技术栈、当前文件的作用、相关代码片段；让 AI 知道"你在什么世界里工作"；②**任务（Task）**——具体要做什么、输入输出是什么、有什么约束条件；让 AI 知道"你要它干什么"；③**格式（Format）**——代码风格、注释规范、测试要求、输出结构；让 AI 知道"交给你什么东西"。

有个更完整的版本叫 CRISP：Context（背景）+ Role（角色）+ Instruction（指令）+ Specificity（细节）+ Presentation（呈现）——角色回答"以谁的视角做"，指令回答"做什么"（要单一、具体、简洁、有上下文），细节回答"做到什么程度"（格式/长度/风格），呈现回答"如何交付"（JSON、Markdown、表格）。

为什么：AI 解析结构化输入的能力远强于解析散文。分层的作用不是好看，是**把信息损耗率压下去**——同样的需求，无结构提示的信息损耗可能接近一半，结构化之后能降到很低：任务边界清晰了、专业度上来了、输出可控了。你每说清一层，AI 就少猜一层；它猜得越少，输出越稳。记住那个原则：**先给上下文，再给具体任务**——AI 和人都一样，不知道背景的任务，做出来必然四不像。

### 经验 2：建模板库——把提示词当代码管理

现象：有个人写了 200 多篇提示词之后总结出一个公式："角色 + 任务 + 约束 + 示例 + 输出格式"。

但更有价值的不是这个公式，而是他随后做的事：把常用场景的提示词固化成模板，存进项目的 `.ai-templates/` 目录——new-component.md、refactor-code.md、write-tests.md、debug-error.md、explain-code.md，每个模板留好占位符，用的时候填参数。

从此他写提示词不是"从零开始想"，是"打开模板填参数"。

做法：①**为高频场景建模板**——新建组件、重构代码、写测试、调试报错、解释代码，这些场景你每周都会遇到，每个建一个模板文件，角色、上下文、任务、要求、输出格式全部预设好，只留 `{变量}` 占位符；②**从抄模板到改模板**——新手先抄模板没问题，但要有意识分析模板的结构：为什么这个模板要设角色？为什么约束写在这里？

分析三五个模板之后，你就能自己组装了；长期依赖别人的模板有三个副作用：满足不了个性化需求、用不到 AI 的深层能力、产出和所有人同质化；③**像管理代码一样管理提示词**——版本控制（改了什么、为什么改）、模板化（常用场景固化）、测试（用 A/B 对比不同版本的效果，建立量化指标）；

④**每日复盘更新模板**——晚上花十分钟记录今天的 AI 使用心得，哪类提示词效果好、哪类总是翻车，更新到模板库里。

为什么：写提示词最大的浪费是"每次都从零开始"。模板库把一次性的好提示词变成可复用的资产——你今天调好的一个模板，未来每次用都省一次试错。更重要的是，**模板化倒逼你思考结构**：你能把提示词固化成模板，说明你真的理解了它为什么有效；不能，说明你还在凭感觉。提示词和代码一样，是资产，不是消耗品。

### 经验 3：迭代与评估——没有完美的提示词，只有不断调优的提示词

现象：大多数人写提示词是一次性的：写完就用，用坏就重写。而真正把提示词当工程的人，会告诉你一句反直觉的话：**完美的提示词很少一蹴而就，它是试出来的。** 第一次输出不满意，不是失败，是数据——它告诉你哪里没说清楚。我有一个朋友接手一个用 AI 重构的活，第一次让 AI 改页面，AI 把整个按钮交互都换了，他回复"这里不对"，AI 又改了一版，还是不对。

后来他把反馈写成约束："按钮位置必须与源项目保持一致""这个入口需要保留历史行为"——AI 立刻对了。

**"这里不对"是情绪，不是约束；"必须保持 X 一致"才是约束。**

做法：①**把反馈变成约束，而不是情绪**——"这里不对""这个不好看"没有信息量；"按钮位置必须与源项目一致""字段必须保留""这个流程不能简化"才有；每次反馈，都把它沉淀成下一轮的显式约束；②**迭代要有记录**——同一任务的提示词改了三版，每版输出了什么、哪里不行，记下来；没有记录，你就是在同一个坑里反复跳；③**用 A/B 对比评估**——两个版本提示词各跑几次，对比输出质量；

质量怎么量化？

定义你的指标：格式正确率、首次通过率、返工次数、人工修改量；④**给 AI 设"确认闸门"**——遇到高风险决策（鉴权流程、权限模型、数据契约、是否引入新依赖），要求 AI 先停下来给 2-3 个方案、等确认，而不是让它替你拍板；⑤**要求 AI 先读、先问、先设计**——复杂任务的开局提示词不是"开始做"，是"先读上下文，整理出事实清单，在完成这一步之前不要修改任何文件"；

先让它证明自己看过上下文，再让它动手。

为什么：提示词的质量不是写出来的，是迭代出来的。**没有评估就没有迭代，没有迭代就没有进步**——这条对提示词和对代码一样成立。把反馈变成约束，是把"人机对话"变成"人机协作"的关键一步：情绪化的反馈只能让 AI 猜，结构化的约束能让它校准。"确认闸门"则把 AI 从"执行者"变成"调查员"——它先证明自己懂，再动手，防止它在关键位置替你做业务决策。

### 经验 4：复杂任务拆着做——设计先行，地基先打，一次只搬一块

现象：很多人第一次让 AI 做复杂任务，习惯把需求压缩成一句话："帮我把这个项目重构一下。"这句话能启动对话，但很难启动一场可靠的工程协作。AI 最容易出的问题不是不会写代码，是**太快开始写代码**：凭文件名猜业务含义，凭模板经验改接口，凭局部页面判断全局规则，最后得到一个"看起来能跑，但关键契约已经变了"的结果。

一个大型重构，如果让 AI 一次性把所有页面搬过去，你会发现搬着搬着，请求协议不一致、权限判断不一致、数据结构不一致、路由规则不一致——全部返工。

做法：①**先写设计文档，再写代码**——要求 AI 先输出重构设计文档：保留什么、迁移什么、哪些规则以接口文档为准、参考实现能复用哪部分、风险清单、分阶段计划；设计文档通过之前，不修改业务代码；②**先做地基，再搬业务**——请求封装、鉴权状态、权限导航、分页协议、通用组件，这些基础设施先落地，再用一个低风险模块当样板，跑通之后才大规模迁移；

③**一次只迁移一个模块，且三线对齐**——视觉交互向新项目靠拢、业务字段向源项目靠拢、数据契约向接口文档靠拢，三条线缺一不可；

发现冲突就让 AI 停下来说明，不要自行选择；④**差异审查比"我完成了"重要**——每批改完，要求 AI 按源项目做差异审查：列表字段、操作流程、权限判断、详情展示，逐项核对，先不改代码，只报差异；⑤**复杂推理用思维链**——让 AI 分步思考："请一步步分析，先写步骤，再给答案"；给一个带推理过程的示例，比给十个干巴巴的结果管用。

为什么：复杂任务的失败模式永远是"一次性做完"，成功模式永远是"分批做、批批验证"。**AI 的速度是优势，但前提是你给它画好边界**——设计文档是边界，地基是边界，三线对齐是边界，差异审查是边界。没有边界的 AI 重构，是把速度变成风险放大器；有边界的 AI 重构，才是真正的效率杠杆。思维链则利用了模型"先推理后作答"的能力——你把推理过程要过来，就能看到它哪里想错了，而不是只看到错误结论。

### 经验 5：知道提示词的边界——它决定"怎么想"，不决定"能做什么"

现象：有人用纯提示词让 AI"查一下北京的天气"，AI 回答"抱歉，我无法实时查询"。这不是提示词写得不好，是**能力边界**问题：提示词只能调用模型知识库里的东西，查不了实时数据。还有人遇到更隐蔽的边界问题：让 AI 写代码，它写出来了，但用的是你没见过的依赖、没验证过的 API——因为它的"知识"截止在某个时间点，新版本的库它可能根本不知道。提示词再完美，也突破不了这些边界。

做法：①**分清"怎么想"和"能做什么"**——提示词决定 AI 怎么想（角色、思路、风格），工具/Skills 决定 AI 能做什么（查天气、发博客、操作浏览器、调用 API）；需要实时数据、外部操作、专有接口时，别只写提示词，要给它配工具；②**记住优先级：提示词优先于微调**——能靠提示词解决的问题，不要先上微调：写提示词成本低、可解释、可迭代；

如果提示词都达不到基本要求，微调成功的可能性也很低；

反过来提示词达标后，微调可以再进一步；③**AI 生成的代码必须过审查**——AI 写代码很快，但它对"你的系统"的理解永远是局部的；关键逻辑、安全边界、性能细节必须人审，样板代码和重复逻辑可以交给 AI；④**别把 AI 当最终答案**——它是"第二大脑"，不是"外包大脑"：架构决策、边界条件、业务约束这些，永远是人的责任。

为什么：**所有工具都有能力边界，提示词也不例外。** 知道边界在哪里，比知道技巧更重要——在边界内使劲，是提效；在边界外使劲，是浪费。提示词与工具的正确关系是互补：提示词把"要什么"说清楚，工具把"能做到什么"补齐。而"AI 生成必须人审"这条，是所有 AI 编程经验里最不性感但最保命的一条：AI 的正确率再高，在关键路径上，它的错误率也是你无法承受的。

### 经验 6：人是最终负责人——AI 负责样板，你负责架构

现象：有个使用 Copilot、Cursor、Codex、Claude Code 等一堆工具、累计生成超过 50 万行代码的人，总结出一个反直觉的结论：**真正让效率提升的不是工具本身，而是一套可复用的工作流。** 他的工作流是：AI 生成代码骨架 → 人手写核心逻辑和边界条件 → AI 补充单元测试 → AI 做代码审查 → 人工最终确认。

他踩过最大的坑，是让 AI 从零开始写整个功能——代码能跑，但难以维护，调试时间远超手写。

做法：①**人机分工要明确**——AI 负责样板代码、重复逻辑、测试生成、PR 描述；人负责架构、边界条件、性能、安全；②**别让 AI 从零写整个功能**——从零开始意味着 AI 替你做了所有架构决策，而它对你的业务一无所知；正确姿势是"骨架给 AI，血肉自己填"；③**关键路径必须人审**——AI 生成的代码要当"实习生代码"看：值得复用，但必须 review；

线上 bug 的排查成本，永远高于写代码时多花的那五分钟；

④**把 AI 当协作者，不是生成器**——让它先读、先问、先设计，再分批改、分批验证；它越了解上下文，产出越接近你要的；⑤**沉淀工作流，而不只是提示词**——晨间规划、功能开发、代码审查、晚间复盘，把 AI 嵌进流程的固定环节，而不是想起来才用。

为什么：**工具放大的是人的能力，不是替代人的判断。** AI 生成代码的速度是人的十倍，但"什么是好代码"的判断力，仍然是人的。把架构和边界交给 AI，等于把方向盘交给一个从没开过这条路的人——它可能开得很快，但拐错一个弯，返工成本远超省下的时间。分工明确的团队效率高，人机协作也一样：各干各擅长的事，才是杠杆；让 AI 干你不放心的事，是赌。

### 怎么开始用（落地清单，L1 执行层）

1. **今天**：把你最常用的一个场景（比如"写测试"或"解释代码"）写成一个模板，存进项目的 `.ai-templates/`；下次直接用，用坏了就改模板，不改正文；

2. **本周**：每次写提示词前检查五件套——角色、任务、约束、示例、输出格式，缺哪个补哪个；复杂任务一律拆成"先读上下文 → 确认方案 → 分批做 → 批批审查"四步；

3. **每次反馈**：把"这里不对"改成"必须保持 X 一致"；把新约束写进下一轮提示词，而不是口头纠正；

4. **每个任务结束**：记一行评估——这次用了什么提示词、输出质量几分、下次怎么改；攒够 10 条记录，你会看到自己的提示词水平曲线；

5. **长期**：像管理代码一样管理提示词——模板进版本库、版本做对比、效果定指标；AI 生成的代码永远过审查，关键逻辑永远人写。

### 怎么迁移到你的场景（L3 深入层）

- **个人日常（写文章/学习/查资料）**：用模板库管你的常用提示词——写作模板、总结模板、翻译模板各一个；把"请一步步分析"变成肌肉记忆；每次输出不满意，先改提示词再改脾气。

- **开发者（AI 辅助编程）**：三层结构 + 模板库 + 审查纪律三件套；复杂重构必须设计先行、确认闸门、分批验证；AI 生成代码当实习生代码 review，关键路径人写。

- **团队（多人用 AI）**：把提示词模板收进仓库，团队共用；新人入职先看模板库，而不是自己从零摸索；定期做提示词分享，把个人经验变成团队资产。

- **API 集成（提示词进产品）**：输出格式必须强制指定（JSON Schema 级别）；用 A/B 测试对比不同版本；建立量化评估指标（格式正确率、首次通过率）；像管理代码一样做版本控制和回滚。

- **学生/入门者**：从抄模板开始没问题，但每周分析一个模板"为什么这样写"；三个月后你会发现自己能组装了；记住：提示词是技能，不是天赋——它靠练习和复盘，不靠灵感。

- **如果你正卡在"AI 总是不听话"**：从最小的闭环开始——今天把五件套写全一个提示词；明天建一个模板；本周给每个任务记一行评估。提示词工程不是玄学，是手艺：手艺靠的是反复练，不是一次顿悟。

收尾：写了几年提示词，我最深的体会是：五百字的小作文，不如五行的结构。AI 不需要你的文学才华，需要你的工程纪律——角色、任务、约束、示例、输出格式，五件套摆齐，比任何修辞都管用。把常用提示词收进模板库、像代码一样管版本，你的输出质量会稳定到连你自己都惊讶。最后永远记住：AI 负责样板，你负责架构。输出不对，先改自己的输入，别急着骂模型。