AI编程五大核心概念：Prompt到Harness Engineering完整指南

随着AI编程工具的快速演进，一系列新概念层出不穷——从最初的Prompt Engineering，到Context Engineering、Agent、Skill，再到最近大火的Harness Engineering。这些概念之间到底是什么关系？各自解决什么问题？本文结合实际开发场景，帮你把这五个核心概念逐一梳理清楚。

Prompt Engineering：一切的起点

Prompt Engineering（提示词工程）是AI编程最早也最基础的概念。在ChatGPT刚推出时，想让AI帮你写好代码，核心就是把需求描述清楚。

举个例子，如果你只说"帮我写一个潮汐App"，AI大概率会跑偏，因为它不知道你具体想要什么。但如果你补充约束条件——"iOS 17+、使用某某第三方库、底部有这几个Tab"——AI就能更准确地理解你的意图，生成的代码也更贴近预期。

Prompt Engineering的本质就是：通过精心设计的提示词，让AI准确理解你的需求。它在单次对话、单个任务场景下非常有效，但当项目开始迭代、对话越来越长时，局限性就暴露出来了。

之所以Prompt Engineering能成为一门"工程"，根源在于大语言模型（LLM）的工作原理——它本质上是一个基于概率的下一个Token预测器。模型并不真正"理解"你的意图，而是根据输入的Token序列，在其训练数据形成的概率分布中寻找最可能的输出。因此，输入的措辞、结构、顺序都会显著影响输出质量。业界总结出的常见Prompt技巧包括：Few-shot（给出几个示例让模型模仿）、Chain-of-Thought（要求模型逐步推理）、以及角色设定（如"你是一位资深iOS开发者"）。这些技巧本质上都是在操控模型的注意力分布，引导它进入更有利于生成高质量输出的概率空间。

Context Engineering：解决AI"失忆"问题

随着项目不断迭代，一个棘手的问题出现了：AI会把前面的事情忘掉。它可能前面帮你写好了一套代码风格，后面做着做着就完全变了样；你之前告诉它不要做的事情，它全部忘得一干二净。

Context Engineering（上下文工程）就是为了解决这个问题而生的。它不再只是一段提示词，而是把一系列关键信息系统性地提供给AI：

• 项目目录结构：让AI了解整体架构
• 后端API及字段定义：确保接口对接准确
• 设计稿风格规范：保持UI一致性
• 不可修改的文件清单：防止AI误改核心代码

这里有一个核心文件叫做 agents.md，它是Context Engineering中最重要的载体。以Codex为例，这个文件会在每次会话中自动带给大模型，相当于项目的"宪法"。你可以在里面定义技术约束、第三方库选择、API地址、设计规范、开发原则等所有关键信息。

关键在于：我们不可能把项目全部代码每次都塞给AI（上下文窗口装不下），所以必须精选关键信息，这就是Context Engineering的核心思想。

要理解这一点，需要了解上下文窗口（Context Window）的技术限制。上下文窗口是指模型单次推理时能处理的最大Token数量。早期GPT-3.5的上下文窗口仅有4K Token（约3000个英文单词），即使到了GPT-4 Turbo也只有128K Token，而Claude 3.5则支持200K Token。虽然窗口在不断扩大，但一个中型项目的代码量动辄数十万行，远超任何模型的上下文容量。更关键的是，研究表明模型存在"Lost in the Middle"现象——即使信息在上下文窗口内，位于中间位置的信息也容易被模型忽略。这就是为什么Context Engineering强调"精选关键信息"而非"全部塞入"，信息的筛选、排序和结构化组织同样重要。

Agent：能循环执行任务的AI

Agent与普通聊天模型的本质区别

普通的ChatGPT对话是"一问一答"模式——你问一个问题，它回答，就结束了。而Agent（智能体）完全不同，它能够循环执行任务。

Agent的概念并非AI编程领域的发明，它源自人工智能的经典研究。早在1990年代，AI学者Stuart Russell和Peter Norvig就在《Artificial Intelligence: A Modern Approach》中定义了"理性智能体"——能够感知环境、做出决策并采取行动以最大化目标达成的系统。当前AI编程中的Agent实现，核心依赖于一种叫做ReAct（Reasoning + Acting）的范式，由Google和普林斯顿大学在2022年提出。ReAct让模型在推理过程中交替进行"思考"和"行动"：先推理下一步该做什么，然后调用外部工具执行，再根据执行结果继续推理。OpenAI的Codex、Anthropic的Claude Code、以及Cursor等工具中的Agent模式，都是这一范式的工程化实现。

你可以用一个公式来理解Agent：

Agent = 模型 + 目标 + 上下文 + 工具 + 执行循环 + 反馈机制

当你给Codex一个任务时，它的工作流程是这样的：

1. 拆解问题：把大任务分解为多个小步骤
2. 逐步执行：每一步都把上下文整理好，扔给大模型获取指令
3. 调用工具：执行终端命令、调用浏览器、运行Xcode Build编译项目等
4. 检查反馈：编译是否通过？测试是否成功？把结果再反馈给大模型
5. 循环迭代：如果没通过，继续修复，直到任务完成

Agent读取的上下文有哪些

以Codex为例，Agent每次会话读取的上下文包括：

• 当前任务描述和对话记录（过长会自动压缩）
• agents.md 项目规则文件
• 项目结构和文件树
• 按需读取的代码片段
• 报错日志和调试信息
• MCP Server暴露的工具方法和Skill定义

这里提到的MCP（Model Context Protocol，模型上下文协议）是Anthropic于2024年底推出的开放标准，旨在统一AI模型与外部工具之间的通信方式。在MCP出现之前，每个AI工具都需要为每个外部服务单独编写集成代码，形成M×N的复杂度。MCP通过定义标准化的客户端-服务器协议，将这一复杂度降为M+N——任何支持MCP的AI客户端都能连接任何MCP Server。MCP Server可以暴露三种能力：Tools（可调用的函数）、Resources（可读取的数据源）和Prompts（预定义的提示模板）。在AI编程场景中，常见的MCP Server包括：数据库查询工具、Figma设计稿读取器、Jira任务管理器、浏览器自动化工具等。这使得Agent的工具调用能力可以无限扩展。

工具调用能力是Agent的核心竞争力。它不只是"想"，还能"做"——跑命令、读文件、调API、截图对比，形成一个完整的行动闭环。

Skill：可复用的能力包

Skill（技能）可以理解为Agent的可复用能力模块，类似于程序员封装的工具函数——写好一次，以后直接调用。

Skill的文件结构

一个Skill的标准结构如下：

skill-name/
├── skill.md          # 必须有的核心描述文件
├── scripts/          # 可选的脚本文件
└── assets/           # 可选的资源文件

以Codex自带的 imggen Skill为例，它的 skill.md 文件定义了名称（name）和描述（description）。Codex每次会话时，只会把Skill的名称、路径和简介带入上下文（而不是完整内容），这样既节省Token，又能让大模型在需要时知道该调用哪个Skill。

Skill的两种触发方式

触发Skill有两种方式：

• 显式调用：在Codex中输入 $imggen，直接指定调用
• 隐式触发：直接说"帮我生成一张可爱猫咪的图片"，大模型发现任务描述与Skill的description匹配，就会自动触发

一个实用的细节：在Codex中使用Skill生成图片特别方便，因为Agent已经拥有项目的上下文，你甚至不需要详细描述想要什么风格的图片，它能基于项目信息自动推断。

Harness Engineering：让AI长期稳定干活的框架

什么是Harness Engineering

Harness Engineering是最近两个月最火的AI编程概念。Harness的中文意思是"马具"——大模型是一匹能力很强的马，Harness就是马之外的一切装备。

它要解决的核心问题是：大模型的能力已经足够强了，写代码基本不成问题，但它需要大量人工介入。如果你丢给AI一个需要一两天才能完成的大任务，不去监督的话，它跑着跑着就一定会跑偏。

Harness Engineering超越了Context Engineering的范畴，它是一套完整的运行框架，包括：

• agents.md：项目规则和索引目录
• design.md：UI设计规范
• 测试脚本：自动验收机制
• 构建命令：编译和打包配置
• MCP配置：外部工具集成
• Git worktree、CI/CD等配套设施

其中，Git worktree是Git 2.5版本引入的功能，它允许在同一个Git仓库下同时检出多个工作目录，每个目录对应不同的分支。在Harness Engineering中，Git worktree的价值在于支持多个Agent实例并行工作——每个Agent在独立的worktree中开发不同的功能分支，互不干扰。这类似于一个团队中多位开发者各自在自己的分支上工作，最后通过Pull Request合并。结合CI/CD（持续集成/持续部署）流水线，每个Agent提交的代码都会自动触发构建和测试，只有通过所有检查的代码才能合入主分支。这种模式使得AI编程从"单线程对话"进化为"多线程并行工程"，大幅提升了开发效率。

规范的Harness项目长什么样

在一个较为规范的Harness项目中，agents.md 不再直接写任务描述，而是变成一个索引目录——告诉AI"哪些规范去看哪个文件"。项目的 docs 目录下会有迭代方案、设计规范、技术约束、发包配置等一系列文档；scripts 目录下则有各种验收脚本。

AI每完成一个小任务，都要跑一遍这些验收脚本。比如"冒烟测试"（Smoke Test）——用模拟器把整个页面跑一次，看有没有崩溃。如果崩溃了（"零件冒烟了"），就先修复再继续。

"冒烟测试"是软件工程中的经典概念，名称来源于硬件工程——当新组装的电路板第一次通电时，如果有元件冒烟，说明存在严重缺陷。在软件领域，冒烟测试是最基础的验收测试，只验证核心功能路径是否能正常运行，不深入测试边界条件。在Harness Engineering的语境下，冒烟测试通常包括：编译是否通过（Build Success）、应用是否能正常启动不崩溃、核心页面是否能正常渲染。更完整的验收体系还会包括单元测试（Unit Test）、集成测试（Integration Test）、UI快照测试（Snapshot Test）等。这些自动化测试脚本充当了AI的"质检员"，使得Agent在无人监督的情况下也能保证交付质量。

独立开发者该如何取舍

这里有一个非常实际的建议：对于独立开发者和新项目，不要死板地套用完整的Harness流程。原因很简单——效率太低。可能你五分钟能搞定的事情，走完整套验收流程要一个小时。每改一个按钮，AI都要跑五六分钟的脚本来验收。

推荐的轻量级方案是：

• 一个 agents.md（项目规则）
• 一个 design.md（UI规范）
• 一个冒烟测试脚本（基础验收）

只有当项目做大了、迭代了很久，才有必要构建完整的Harness体系。完整Harness的优势在于执行长任务时非常稳定——每次改动都经过验收，最终交付时偏差很小。

五大概念之间的关系总结

这些概念并非孤立存在，而是层层递进的关系：

概念	解决的问题	核心要素
Prompt Engineering	单次任务的需求表达	精确的提示词
Context Engineering	项目迭代中的上下文管理	agents.md、文档、API定义
Agent	复杂任务的自动化执行	执行循环 + 工具调用 + 反馈
Skill	能力的复用和模块化	skill.md + 脚本 + 资源
Harness Engineering	长期稳定的自动化开发	完整的框架和验收体系

从Prompt到Harness，本质上是AI编程从"对话式辅助"走向"自主化工程"的演进路径。理解这些概念的核心思想，比死记硬背它们的定义重要得多。在实际开发中，根据项目规模和阶段灵活选用，才是最务实的做法。