AI 学习笔记（二）：Prompt Engineering 入门，怎么和大模型好好说话

发表于 更新于 分类于 阅读次数： Changyan： 本文字数： 2.7k 阅读时长 ≈ 2 分钟
Prompt Engineering 不是玄学，而是把需求讲清楚的能力。本文从开发者视角拆解 Prompt 的核心结构、常见误区和实战写法，帮助你更稳定地和大模型协作。

第一篇开了个头，先把“为什么我要系统学 AI”这件事说清楚了。
那第二篇，就该落到一个最实际的问题上：我们到底该怎么和大模型说话，才能让它更稳定地帮我们做事？

很多人第一次用大模型时，都会有一种错觉：它好像什么都懂，但又总是“差一点意思”。
有时候回答得很泛，有时候重点跑偏，有时候看起来说得头头是道，结果一落地就发现根本不能用。

我后来慢慢发现，这里面当然有模型能力的差异，但更常见的问题，其实出在输入不够清楚。
你给它一个模糊的问题，它往往就会回你一个模糊的答案。你给它一个带目标、带约束、带上下文的任务，它输出的质量通常会稳定很多。

这也是 Prompt Engineering 的核心：不是研究怎么“施法”，而是研究怎么把需求说明白。

Prompt Engineering 到底是什么

如果用一句最朴素的话来解释，Prompt Engineering 就是：

用更清晰的方式组织你的意图、上下文、约束和预期输出，让模型更接近你真正想要的结果。

它不是咒语，也不是背几个万能模板就能解决所有问题。
更像是你在和一个反应很快、知识面很广、但不会主动追问太多上下文的助手合作。

你说：

1
帮我写一个登录功能

它当然也能回，但大概率会回得很散。
因为这里缺了太多信息：

  • 你用什么技术栈？
  • 是前端页面，还是后端接口？
  • 你要的是示例代码、设计思路，还是排查方案？
  • 你希望输出到什么粒度？
  • 有没有现有项目约束？

所以 Prompt 的本质，不是“让 AI 变聪明”，而是减少理解偏差。

一个好 Prompt 通常包含什么

我现在会把一个实用 Prompt 拆成 5 个部分：

1. 角色

告诉模型，它应该从什么视角回答。

例如：

1
你是一名有前端实战经验的全栈工程师

这不是仪式感，而是在缩小回答范围。
角色越具体，回答越容易贴近场景。

2. 目标

明确这次任务到底要完成什么。

例如：

1
请帮我把一个模糊的需求拆成可执行的开发步骤

比起“帮我看看这个需求”，目标明确得多。

3. 上下文

这是最容易被忽略、但往往最影响结果的一部分。

例如：

  • 当前项目是 React 还是 Vue
  • 接口已经存在还是要一起设计
  • 你面对的是线上问题还是新功能
  • 你现在卡住的点是什么

模型不是没能力，而是它不知道你脑子里已经默认了什么。

4. 约束

约束决定答案能不能落地。

例如：

  • 不要改动现有接口结构
  • 只给最小改动方案
  • 输出用 Markdown
  • 代码示例用 TypeScript
  • 不要引入新依赖

很多时候，AI 输出“看起来不错但不能用”，不是因为它不会，而是因为你没告诉它边界。

5. 输出格式

如果你不指定输出格式，它就会按它认为合适的方式展开。
这在聊天里没问题，但在工作流里会很痛苦。

例如：

1
2
3
4
5
请按以下格式输出：
1. 问题判断
2. 修改建议
3. 风险点
4. 示例代码

一旦格式稳定下来，后续复用和迭代都会轻松很多。

从“会问”到“问得好”：一个对比

先看一个不够好的提问：

1
帮我优化一下首页性能

这个问题太大了。模型很可能会给你一堆正确但空泛的建议，比如懒加载、图片压缩、缓存、减少请求等等。
这些建议没错，但通常也没法直接拿去改项目。

如果换成下面这种写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
你是一名前端性能优化工程师。

我有一个 Vue 3 项目，首页首屏白屏时间偏长。
当前已知情况：
1. 页面包含多个接口请求
2. 有轮播图和若干统计卡片
3. 打包后首屏 JS 体积偏大

请帮我输出一份排查方案，要求：
1. 按优先级排序
2. 区分“先排查”和“可优化”
3. 给出每项优化的收益判断
4. 如果需要代码示例，请使用 Vue 3

这时候模型更容易给出你能直接执行的内容。

这也是我现在最常用的思路：
不要只提问题，要把任务背景一起交代出来。

我自己常用的 Prompt 骨架

为了避免每次都从头想，我现在会先写一个骨架，再根据任务补细节：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
你现在扮演：
[角色]

我当前要做的事情是：
[目标]

背景信息：
- 技术栈：
- 当前现状：
- 已知限制：
- 我已经尝试过的方案：

请按以下要求输出：
- 输出形式：
- 是否需要代码：
- 是否需要分步骤：
- 是否需要指出风险：

额外要求：
- 尽量结合实际工程场景
- 不要泛泛而谈
- 如果信息不足，请先指出缺失项

这个模板不高级，但很实用。
尤其在写代码、排查问题、做技术方案对比时，比一句话硬问稳定得多。

初学者最容易踩的几个坑

1. 把 Prompt 当成搜索框

很多人用 AI 的方式，其实还是在“搜答案”。
但大模型不是搜索引擎，它更像是一个基于上下文生成结果的协作对象。

搜索更像在找“已有结论”，而 Prompt 更像在发“任务说明”。

2. 只说目标，不说限制

比如“帮我重构这段代码”，如果你不说不能改接口、不想引新依赖、不希望大改目录结构，它就可能给你一个理论上更优、实际上更难落地的方案。

3. 一次塞太多任务

让模型同时做分析、设计、编码、测试、总结，结果通常不如拆成几个小步骤。

我的经验是：

  • 先让它分析
  • 再让它给方案
  • 然后让它实现
  • 最后让它自查风险

把复杂任务拆开，质量往往比一把梭高很多。

4. 不做结果校验

Prompt 写得再好，也不意味着结果一定可靠。
尤其在代码、配置、命令、版本差异这些问题上，最后还是要回到“验证”。

AI 可以帮你加速，但不能替你负责。

对开发者来说，Prompt Engineering 真正有用的地方

在我看来，Prompt Engineering 最实用的价值不在“生成一段漂亮文案”，而在下面这几件事：

  • 把模糊需求快速转成执行步骤
  • 把报错信息整理成排查路径
  • 把重复性说明压缩成可复用模板
  • 在技术方案比较时，快速得到多种角度
  • 在写代码前，先让模型帮你补齐思路盲区

如果你本来就有开发经验，会更明显感受到一点：
Prompt 的上限，往往取决于你表达问题的能力。

你越知道自己想要什么，AI 就越容易帮到你。
你越会把边界讲清楚，输出就越可控。

我现阶段的结论

学 Prompt Engineering，第一步不是收集“万能提示词”，而是先建立一个意识：

和大模型协作，本质上是在写一份更清楚的任务说明。

当你开始这样看待 Prompt，很多事情都会顺起来：

  • 为什么上下文这么重要
  • 为什么约束越清楚越好
  • 为什么示例能显著提升输出质量
  • 为什么同一个模型，在不同人手里效果差异会那么大

它没有想象中那么神秘，但确实值得认真练。

参考资料

这一篇先把“怎么提问”讲清楚。
下一篇：Token、上下文窗口和 Temperature，到底在影响什么

本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-prompt-engineering-intro/