从 Prompt 到 Harness：AI 工程化的三年跃迁与实战解码

从 Prompt 到 Harness：AI 工程化的三年跃迁与实战解码

当大模型不再是黑盒玩具，而成为可治理、可迭代的"数字员工"，我们如何为其搭建舞台、系好缰绳？

---

一、引言：AI 工程化的分水岭已至

如果你从 2022 年就开始使用 ChatGPT，你一定经历过这种场景：花半小时雕琢一段"完美"的提示词，满怀期待地发送，结果 AI 却还你一本正经的胡说八道 。那时我们称之为 Prompt Engineering，它像一门玄学------靠不断的试错、措辞调整、角色扮演来"哄骗"模型给出正确答案。

然而到了 2025-2026 年，风向彻底改变。你不再需要事无巨细地教 AI 怎么做，只需给它一个场景、一些约束、几项工具，它就能自己"理解"并给出可靠结果。这个转变背后，是 Context Engineering（上下文工程） 和 Harness Engineering（缰绳工程） 的逐步成熟。

本文结合我自己整理的笔记和一个真实的 Node.js 代码案例，梳理 AI 工程化三年间的演进脉络，并深度解析"上下文"如何从一段文字升级为结构化的工程系统。你会发现，写提示词早已不再是核心技能，搭建可治理的 AI 运行环境才是未来的主战场。

---

二、第一阶段（22-23）：Prompt Engineering ------ 正确的胡说八道

2.1 基于预训练的概率游戏

那时，GPT-3.5 是主流。它的回答全部来自预训练数据中的统计模式 ，模型本质上是一个高级的"文字接龙"机器。即使你给了详尽的指令，它依然可能因为缺乏真实理解而胡编乱造，这就是幻觉问题。

为什么"完美提示词"也不一定有用？

因为 Transformer 架构的生成机制是条件概率预测 ，它不知道"对错"，只知道"哪个词接在后面最自然"。因此，早期的 Prompt Engineering 主要围绕如何让概率分布更偏向你想要的答案，方法包括：

• 赋予清晰的身份（"你是一位资深 Java 架构师"）
• 分解步骤（"第一步...第二步..."）
• 提供示例（Few-shot）
• 加上各种"禁止"条款（"不要编造事实"）

2.2 典型应用：ChatGPT 与 GitHub Copilot

ChatGPT 让大众见识了生成式 AI 的威力，而 GitHub Copilot 则让开发者第一次感受到 AIGC 辅助编程 的便捷。Copilot 会读取你当前的代码文件（即有限上下文）来推荐补全，但它仍局限于当前编辑器窗口的内容，缺乏对整个项目架构的理解。

这个阶段的"工程化"仅停留在提示词模板化------写一套标准指令，然后复制粘贴。但它的不确定性始终存在，你永远不知道下一轮输出是否靠谱。

---

三、第二阶段（24-25）：Context Engineering ------ 让 AI 先查资料再回答

3.1 RAG 补齐知识短板

人们逐渐发现：AI 胡说，往往不是因为它不听话，而是因为它缺少完成任务所需的"外部知识"。比如，你要它回答公司内部 API 的用法，它只见过公开文档，当然会编造。

于是 RAG（检索增强生成） 成为主流方案------在调用 LLM 之前，先根据用户问题去检索一个外部知识库（企业文档、数据库、代码仓库），将检索到的相关片段动态拼接到 prompt 中 ，再发给模型。这样，AI 的回答就有了事实依据，更靠谱、更准确。

代码注释中也提到："通用性大模型大而全，可能在某些专业领域，还需要补充知识 RAG" 。这正是本阶段的核心思想------不用训练模型，而是教它如何查询外部资料。

3.2 上下文工程萌芽：Cursor 干掉 VS Code

Cursor 是一个基于 VS Code 的 AI 编程 IDE，但它"干掉了"VS Code，因为它把整个代码库当作上下文------不仅是当前文件，还包括项目架构、代码风格、历史提交、依赖关系等。开发者只需一句简单的自然语言（"帮我实现一个用户登录接口"），Cursor 就能自动分析已有代码并生成符合项目规范的新代码。

这就是 上下文工程 的雏形：不是写好一段 prompt，而是为 AI 构建一个丰富、结构化、动态更新的背景信息集合。那时的法律行业也开始出现"法律专家 RAG"系统，将法规、判例作为上下文供给模型。

---

四、第三阶段（25-26）：Harness Engineering ------ 给千里马配上鞍和缰绳

4.1 LLM 已成千里马，但需要"马具"

到了 2025-2026 年，大模型本身的能力已经进化到令人惊叹：Claude 4.6、Gemini 3、GPT-5 的推理能力、长文本记忆（上下文窗口）都远超从前。笔记中比喻为 "千里马" ，而 Claude Code、Codex 这类工具相当于已经配备了一定马具。

但光有强大模型还不够，我们还需要一套工程化体系 来保证它在生产环境中安全、可靠、稳定地输出。笔记里提到"小龙虾 记忆力不如 (token 太费) 爱马仕 hermes"------这暗指早期模型上下文窗口小（如"小龙虾"），记忆有限，而现在的大模型如 Hermes（爱马仕）级别已经有长记忆，但我们仍需要"马鞍、缰绳"来引导它。

4.2 缰绳工程的四大支柱

• 规则（Rules）与围栏（Guardrails） ：设定明确的输出边界，比如禁止生成违法内容、强制输出 JSON 格式、价格必须为正数等。这是安全和合规的底线。
• 循环（Loop）：多轮交互、自我反思、错误修正机制。比如模型先生成草稿，然后自我审查修改，最后再输出。
• 技能（Skills）：预封装的功能模块，如计算器、数据库查询、发送邮件等。当模型需要这些能力时，直接调用 Skill，而不是让模型"猜"结果。
• MCP（Model Context Protocol） ：一种标准化协议，用于不同工具、服务、模型之间传递上下文信息。它让整个系统像传统软件一样拥有清晰的接口和可组合性。

有了这些，AI 开发就从"写提示词"转变为类似传统软件工程的确定性交付 。笔记中说："llm 工程化终于在 25-26 年成熟了，各个企业都拥抱 AI 数字化，FDE 被大量需要"------FDE（AI 工程落地工程师） 成为新兴热门岗位，他们负责将 AI 能力集成到业务系统中，确保稳定、可观测、可迭代。

---

五、为什么"最完美的提示词"也救不了你？

你可能仍有疑惑：如果我把所有技巧都用上，写一段长而详细的任务描述，难道不能保证质量吗？ 笔记里给出了两方面的回答：

5.1 模型本质仍是概率预测

Transformer 架构的根基是基于预训练知识预测下一个 token ，它没有"理解"能力。即使你给了极详细的指令，模型依然可能在概率分布上偏向错误路径。所以，即便早期写出完美的提示词，也可能得不到好结果。

5.2 模型进化 + 自动优化改变了游戏规则

但现在的 LLM（如 GPT-5、Gemini 3）已经进化了：

• 更强的推理链（CoT）能力：模型能自行拆解复杂问题。
• 海量 Prompt 数据训练 ：OpenAI、Google、Anthropic 收集了过去数年人类与 AI 的对话数据，并用它们训练新模型。这使得模型已经预见到了人类常见的需求模式。
• 自动 Prompt 优化：现在你输入一句简单的"帮我写个登录接口"，模型内部可能会自动扩展成一个结构化的提示词，再进入生成流程。

因此，如今在 Cursor / Trae / Claude Code 这类工具中，一句简单的 prompt 就能胜过当年长篇大论。原因有三：

1. LLM 自身更强大（推理、记忆、知识覆盖）。
2. IDE 或 Agent 在后台自动替你做了上下文组装（读取项目文件、调用 MCP、注入 Skills）。
3. 上下文技术成熟，它将"背景、约束、规则"从纯文本中分离出来，以结构化数据动态供给。

正如笔记中所画的链路：

用户 prompt → (LLM 优化过的 prompt、上下文技术、MCP、Skills) → Transformer 生成 → Loop Engineer + Harness Engineer → FDE (AI 工程落地)

这个链路表明，最终生成的质量已经不是单靠"写提示词"能控制的了，而是由一整套工程环节共同决定。

---

六、上下文工程的本质：搭台，而非写词

上下文工程（Context Engineering）的精髓是：不是写出一句完美的提示词，而是为 AI 搭建一个包含"背景、约束、规则"的完整工作台。

• 背景（Background）：你是谁？你的客户是谁？当前要解决什么问题？
• 约束（Constraints）：有哪些硬性限制？（预算、技术栈、时间、法规）
• 规则（Rules）：必须遵守的流程或输出格式。
• 参考资料（Reference）：文档、代码、数据库记录等。

当你把这些结构化地交给 AI，它就从"通才"变成了你专属领域的"专家"。代码注释中写道："上下文的结构化思想"、"构成上下文的，在不同的地方，不同的形式"------这正说明上下文不是一段固定文字，而是可以从数据库、API、文件系统等不同源头动态组装的信息。

---

七、代码实战：一个奶茶研发的上下文工程示例

我们来看一份简洁但极具代表性的 Node.js 代码（index.mjs），它演示了如何用工程化手段为大模型搭建上下文，并调用 DeepSeek API 完成一次"新品研发"任务。

7.1 环境与客户端初始化

import 'dotenv/config';
import OpenAI from 'openai';

const client = new OpenAI({
    apiKey: process.env.DEEPSEEK_API_KEY,
    baseURL: process.env.DEEPSEEK_API_BASE_URL
});

• dotenv 加载环境变量，避免 API Key 硬编码，这是工程化的基本安全实践。
• 实例化 OpenAI 客户端，但通过修改 baseURL 指向 DeepSeek 的兼容接口。这体现了可插拔设计------同一套代码可以对接不同厂商的大模型，只需更换环境变量。

7.2 结构化上下文对象

const context = {
    // 需求背景：你是谁？做这事的目的
    background: 
        "我是大学附近的奶茶店老板，客户多是17-22岁学生， 客单价15-20元",
    // 约束 相关事实， 限制条件
    constraints: "夏季要清爽， 成本控制在8元内 ",
    outputRequirements: `要颜值高（适合拍照发朋友圈）, 请输出JSON格式，包含
    饮料名、配料、成本、定价。
    `
}

注释明确点出这里的三个维度：

• 背景：业务描述、目标人群、价格带。
• 约束：季节和成本硬性限制。
• 输出要求：格式（JSON）和必须包含的字段。

采用这种键值对结构的好处：

• 可维护：修改背景或约束时不影响其他部分。
• 可复用：同样的结构可以用于其他商品研发（如菜品、营销文案）。
• 可扩展 ：未来可增加 examples、references、tools 等字段。

代码注释还提到："补充上下文 context pre-trained api 订单服务AI客服 动态的" ------这暗示在真实业务中，background 可能来自用户画像 API，constraints 可能来自库存系统，上下文是动态获取而非静态写死的。

7.3 工程化拼接 System Prompt

const systemPrompt = `
你是一个专业的饮品研发专家，请根据以下上下文信息完成任务。
【背景】 ${context.background}
【约束】 ${context.constraints}
【要求】${context.outputRequirements}
`

这里我们把结构化信息"编织"成一段自然语言指令，但保留了清晰的段落标记（【背景】等）。注释说"工程角度"，意即我们视 prompt 为代码产物，而非临时发挥。System prompt 定义了 AI 的角色（研发专家）和工作依据（上下文），之后所有对话都建立在这个基础之上。

7.4 核心函数：调用 API 并处理响应

async function generateNewTea() {
    // 容错， 代码工程的重要部分
    try {
        console.log(`正在请求大模型，上下文工程已就绪...`);
        const completion = await client.chat.completions.create({
            model: "deepseek-v4-flash",
            messages: [
                {
                    role: "system",
                    content: systemPrompt
                },
                {
                    role: "user",
                    content: "请开始你的研发设计"
                }                
            ],
            temperature: 0.7
        });
        const aiResponse = completion.choices[0].message.content;
        console.log("\n AI 研发成果:");
        console.log(aiResponse);
        try {
            const jsonData = JSON.parse(aiResponse);
            console.log("成功解析为JSON 对象", jsonData);
        } catch(err) {
            console.log("返回的格式不是JSON, ")
        }

    } catch(err) {
        console.error(err.message);
    }
}

关键工程细节：

• 容错（try-catch） ：外层捕获网络异常、API 错误等，避免程序因异常崩溃，这是工程化代码的基本素养。注释也明确强调"容错，代码工程的重要部分"。
• Temperature = 0.7：平衡创意性与确定性。0 是保守，1 是大胆，0.7 适合创意设计类任务。
• 用户消息极简 ：只写"请开始你的研发设计"，因为所有关键上下文已在 system prompt 中。这正是 "简单用户指令 + 丰富系统上下文" 的设计模式。
• JSON 解析尝试 ：我们明确要求输出 JSON，但模型可能不遵守。因此代码尝试解析，若失败则只打印原文并继续，不阻断流程------这属于防御性编程。

另外，注释提到："补充上下文 context pre-trained api 订单服务AI客服 动态的，资料，文档静态的" ------这说明真实场景中，我们需要同时处理动态数据 （如订单信息）和静态资料 （如产品手册），并将它们一并注入上下文。本例中的 context 是静态的，但完全可以改造为从数据库或 API 实时获取。

7.5 执行与结果

调用 generateNewTea() 后，模型会基于我们提供的背景、约束、输出要求生成一款新茶饮。例如输出：

{
  "饮料名": "薄荷青柠气泡水",
  "配料": "薄荷叶、青柠汁、气泡水、蜂蜜",
  "成本": 6.5,
  "定价": 16
}

如果解析成功，我们就可以直接将该 JSON 用于业务系统（如菜单更新、成本核算、营销文案生成），实现了 AI 输出到业务落地的无缝对接。

---

八、从上下文到缰绳：AI 工程化的完整链路

结合笔记和代码，我们可以勾勒出当前 AI 工程化的完整流程：

1. 用户输入（简短的自然语言）
2. 上下文组装（从多个来源动态拉取背景、约束、规则、参考资料）
3. Prompt 优化（LLM 自身或 Agent 自动重写为更结构化的指令）
4. 工具调用（通过 MCP 或 Skills 执行外部操作，如查数据库、调用 API）
5. 模型生成（Transformer 推理）
6. Loop 反馈（自我检查、修正、多轮迭代）
7. Harness 校验（围栏检查、格式验证、合规过滤）
8. 最终交付（由 FDE 集成到业务系统）

在这个链路中，每一个环节都可被工程化治理------可监控、可回滚、可 A/B 测试。这正是它超越"玄学提示词"的本质所在。

---

九、总结与展望

时期	核心范式	关键手段	代表产物
22-23	Prompt Engineering	身份、步骤、示例	ChatGPT、Copilot
24-25	Context Engineering	RAG、动态上下文、代码库感知	Cursor、Trae、法律 RAG
25-26	Harness Engineering	规则、循环、Skills、MCP	Claude Code、Codex、FDE 岗位

我们正站在 AI 从"玩具"走向"工具"再到"平台"的历史节点。对于开发者而言，最重要的不再是研究如何写出"完美提示词"，而是设计一套可扩展、可观测、可治理的上下文供给与运行时环境。这需要：

• 软件工程素养（异常处理、配置管理、模块化）
• 领域知识（理解业务约束）
• 对 LLM 能力边界的清醒认识（知道何时该用 RAG，何时该用 Skills，何时该人工介入）

最后，回到代码注释中那句点睛之笔："上下文的结构化思想" 和 "构成上下文的，在不同的地方，不同的形式"------未来的 FDE 日常，就是从 Git 拉取代码规范，从 CRM 拉取客户画像，从 Wiki 拉取业务规则，然后将这一切打包成模型可消化的上下文，让 AI 在指定的赛道里跑出千里马的速度，同时又不偏离我们设下的缰绳。

提示词会过时，但工程思维永不过时。

---

如果你也在实践 AI 工程化，欢迎在评论区分享你的经验，一起探讨这条充满挑战和机遇的新赛道。