Prompt Engineering 是什么

Prompt Engineering 是设计输入给模型的指令方式。它解决的是「怎么把任务说清楚」，但不是 AI 系统设计的全部。

Prompt Engineering 曾经是使用大模型的核心能力。

当 AI 主要停留在网页聊天框里时，你能控制的东西很少：一段输入、一段上下文、一轮回答。于是「怎么写提示词」变得非常重要。

好的 prompt 可以让模型更清楚目标、角色、格式、约束和评价标准。坏的 prompt 则会让模型自由发挥，产出看似完整但无法使用的内容。

但随着 Agent、工具调用、MCP、Skills、文件系统和工作流出现，Prompt Engineering 的位置发生了变化。它仍然重要，但不再是全部。

Prompt Engineering 解决什么

Prompt Engineering 主要解决四类问题。

第一，明确任务目标。

比如不要只说「帮我分析一下」，而要说「请从商业模式、用户需求、技术壁垒和风险四个维度分析」。

第二，定义角色和视角。

比如让 AI 作为研究员、编辑、产品经理、代码审查者或事实核查员来工作。

第三，规定输出格式。

比如表格、清单、文章大纲、JSON、Markdown、报告结构。

第四，提供评价标准。

比如什么叫好答案、什么不能出现、哪些地方必须引用来源。

Prompt 的局限

Prompt 的最大问题是：它只是一段指令。

复杂任务不是靠一句话完成的。

如果任务需要读取文件、查资料、调用工具、反复修改、保存中间结果、交给不同角色执行，那么 prompt 就不够了。

你可以写出很长的提示词，但它仍然会遇到几个瓶颈：

• 上下文很快变乱。
• 输出标准无法稳定复用。
• 中间过程难以追踪。
• 任务状态无法长期保存。
• 模型只能临场理解你的需求。

所以，Prompt Engineering 更适合单次任务；复杂系统需要更高层的设计。

和 Context Engineering 的区别

Prompt Engineering 关注「怎么说」。

Context Engineering 关注「让 AI 看到什么」。

举例来说，让 AI 写一篇文章。

Prompt Engineering 会优化这句话：请用专业但通俗的语气，写一篇面向知识工作者的文章。

Context Engineering 会设计：AI 应该看到哪些旧文章、哪些读者画像、哪些素材、哪些风格标准、哪些禁忌、哪些输出模板。

前者是指令，后者是环境。

和 Skills 的关系

Skills 可以理解为把 prompt 升级成可复用的专业能力包。

一个 prompt 往往只描述一次任务。

一个 Skill 则可以包含：

• 任务适用场景。
• 操作步骤。
• 判断标准。
• 输入输出格式。
• 示例。
• 常见错误。
• 质量验收方式。

所以，Skills 不是更长的 prompt，而是把专业方法变成 Agent 可以调用的 SOP。

和 Harness Engineering 的关系

Harness Engineering 进一步超越 prompt。

它不只关心模型看到什么、听到什么，还关心模型能操作什么。

比如：

• 能不能读写文件？
• 能不能运行命令？
• 能不能访问浏览器？
• 能不能调用 MCP？
• 能不能保存日志？
• 能不能回滚错误？
• 能不能通过测试验收结果？

Prompt Engineering 是语言层。

Harness Engineering 是环境层。

什么时候 Prompt Engineering 仍然重要

Prompt Engineering 并没有过时。

它在以下场景仍然很重要：

• 单次问答。
• 快速生成。
• 角色设定。
• 输出格式控制。
• 给 Agent 明确当前任务目标。
• 给 Skills 写清楚触发条件和操作标准。

区别在于：今天的 prompt 更像系统中的一个部件，而不是整个系统。

一个实用原则

如果任务一次就能完成，先优化 prompt。

如果任务需要反复做，写成 command 或 Skill。

如果任务需要文件、工具、记忆和多人协作，就设计 workflow 和 harness。

AI 使用的演进路径大致是：

Prompt → Context → Skill → Workflow → Harness → AI OS

Prompt Engineering 是入口，但不是终点。