为什么需要“提示词工程”？
- 可迁移：好提示可以模板化，跨团队复用，节省试错成本。
- 可评测：输出质量、准确率、Latency、Token 使用量都可量化。
- 可迭代：结合自动化测试 / RAG / 函数调用，能够形成 Prompt → Model → 评估 → 改进 的闭环。
- 对比优势明显：在企业/科研场景，同样的大语言模型，优化提示能把正确率从 60 % 提到 85 %+，直接影响业务效果与成本
关于大语言模型的一些误解
|
误解 |
现实 |
|---|---|
|
模型很强 → 直接问就行 |
LLM 仍然是“条件生成器”，靠输入的 条件（提示词）决定输出；如果条件含糊、缺失，模型只能猜，从而出现跑题、格式错乱、幻觉。 |
|
只要数据大就一定准确 |
LLM 不是数据库。它用统计相关性来“补全”文本，默认追求流畅而非正确；精确定义任务与约束，才能让它优先满足“正确 / 可执行 / 可复用”。 |
|
一次提问就要拿到最终答案 |
复杂任务往往需要“分解-思考-验证-再迭代”。提示词工程提供了拆分任务、逐步推理、检核结果等模式。 |
本质：Prompt Engineering = 设计一份 输入说明书，让模型在 有限 token 和非确定性 的框架里，更稳定、更符合预期地工作。
好提示词的 6 个核心特征 （“C-P-R-F-E-D”）
|
缩写 |
说明 |
要点 |
|---|---|---|
|
C = Clear |
目标清晰、无歧义 |
“给我一个 JSON，字段 a/b/c” ⬆︎；“帮我分析一下” ⬇︎ |
|
P = Provide context |
提供必要背景 |
行业、受众、约束、例子、输入数据… |
|
R = Role |
指定合适角色/视角 |
医生/Lawyer/DBA/产品经理… |
|
F = Format |
规定输出格式 |
Markdown 段落、表格、代码块、固定字段 |
|
E = Examples |
关键示例 Few-shot |
正向 / 反向例子各 1–2 条，可大幅降低误差 |
|
D = Decomposition |
拆分子任务 & 过程提示 |
“先列步骤，再展开第 2 步”，或“思考后给最终答案” |
示范：普通提示 vs. 优化后提示
|
普通提示 |
存在问题 |
优化后提示（符合 C-P-R-F-E-D） |
|---|---|---|
|
“帮我写一份商业计划书。” |
目标宽泛、格式不定 |
角色：资深创业顾问场景：面向天使投资人，项目=二次元音乐社区输出格式：①项目概述（≤150字）②市场痛点③竞争分析④盈利模型⑤3年财务预测（表格）约束：全中文，避免行话、每段标题加编号 |
|
“解释数据库分层。” |
术语含糊，多种答案 |
背景：公司准备搭建数仓，团队新人多角色：10年经验的数据架构师任务：用类比+示例阐述 ODS→DWB→DWS→ADS 各层含义和依赖格式：Markdown 列表，每层用 2 行示例 SQL |
|
“给我写一段 Python 代码调用 OpenAI 接口。” |
版本、异常处理未知 |
示例输入：API_KEY=“sk-…”，模型=“gpt-4o”要求：Python 3.10，使用 httpx，封装成函数 ask_gpt(prompt:str)->str，包含超时与重试装饰器；给出运行示例 |
提示词常见技巧
Step-by-Step / Chain-of-Thought
“请分步推理，并在最后一行用 【最终答案】 给出结论。”
拒绝幻觉
“若不确定，请回答无法确定并简述原因；不要编造数据。”
迭代式提示
第一轮：产出草稿
第二轮：评审 + 让模型自我校对
第三轮：锁定格式与细节
工具化输出
用代码块包裹 JSON/SQL/CSV，后续可直接解析执行。
上下文压缩（长对话）
让模型先总结历史，再继续；降低 token 消耗、减少忘记前文。
《我们为什么需要“提示词工程” Prompt Engineering？》留言数：0