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

最近跟几个做独立开发的朋友聊天，发现一个特别有意思的现象——大家都在用AI写代码，但聊起来的时候，有人还停留在跟ChatGPT一问一答的阶段，有人已经在搞什么Harness Engineering了。中间这些概念，Prompt Engineering、Context Engineering、Agent、Skill，好多人其实是一锅粥的状态。今天咱们就来好好捋一捋，这五个概念到底是什么关系。 对，这几个概念确实容易搞混，因为它们不是并列的，而是层层递进的。你可以想象成盖楼，每一层都是在上一层的基础上往上搭。最底层就是Prompt Engineering，也就是提示词工程。这个概念其实最早也最基础——核心就一件事：怎么把需求跟AI说清楚。 这个我有体会。比如你跟AI说'帮我写一个潮汐App'，它大概率给你整出来一个四不像。但你要是说清楚——iOS 17以上、用SwiftUI、底部有四个Tab、用某某第三方库——结果就靠谱多了。 没错，这就是Prompt Engineering的精髓。但你得理解它为什么能成为一门'工程'。根本原因在于大语言模型本质上是一个概率预测器，它不是真的'理解'你说的话，而是根据你输入的内容，在概率分布里找最可能的输出。所以你措辞不一样、结构不一样、甚至信息的顺序不一样，输出质量可能天差地别。业界总结出来的那些技巧，什么Few-shot给几个示例、Chain-of-Thought让它一步步推理、角色设定说'你是资深iOS开发者'，本质上都是在操控模型的注意力分布。 嗯，这个在单次对话里确实够用了。但问题是，项目一旦开始迭代，对话越来越长，AI就开始'失忆'了对吧？ 对，这就引出了第二层——Context Engineering，上下文工程。你有没有遇到过这种情况？前面跟AI说好了代码风格，后面它写着写着就完全变了；你明确说过不要动某个文件，它转头就给你改了。 太常见了，简直是AI版的金鱼记忆。 哈哈，对。这背后有个技术限制叫上下文窗口，就是模型一次能处理的信息量是有上限的。早期GPT-3.5只有4K Token，大概三千个英文单词，现在Claude 3.5虽然到了200K，但一个中型项目代码量动辄几十万行，根本塞不下。而且研究还发现一个'Lost in the Middle'现象——就算信息在窗口里，放在中间位置的内容也容易被模型忽略。所以Context Engineering的核心思想不是'全塞进去'，而是'精选关键信息'。 那具体怎么精选呢？ 这里有个核心文件叫agents.md。以Codex为例，这个文件每次会话都会自动带给模型，相当于项目的'宪法'。你在里面定义技术约束、第三方库选择、API地址、设计规范、哪些文件不能动，等等。除此之外还有项目目录结构、后端API字段定义、设计稿风格规范这些，都是系统性地提供给AI的关键上下文。 好，Prompt解决了单次怎么说，Context解决了项目记忆问题。那第三层Agent呢？我感觉这个词现在到处都在用，但很多人理解得比较模糊。 Agent和普通聊天最本质的区别就一个字——循环。普通ChatGPT是一问一答，问完就结束了。但Agent能循环执行任务。你可以用一个公式来理解：Agent等于模型加目标加上下文加工具加执行循环加反馈机制。 能展开说说这个循环具体是怎么跑的吗？ 比如你给Codex一个任务，它首先会把大任务拆成小步骤，然后逐步执行——每一步都整理好上下文扔给模型拿指令，接着调用工具，比如跑终端命令、编译项目、调API，然后检查反馈，编译过了没？测试通了没？如果没过，就继续修复，直到完成。这背后依赖的是Google和普林斯顿2022年提出的ReAct范式，就是让模型交替进行'思考'和'行动'。关键是，Agent不只是'想'，它还能'做'——跑命令、读文件、截图对比，形成完整的行动闭环。 你刚才提到工具调用，这里面有个MCP的概念，能简单说说吗？ MCP是Anthropic去年底推出的一个开放标准，全称Model Context Protocol。以前每个AI工具要对接每个外部服务都得单独写集成代码，复杂度是M乘N。MCP定义了一套标准协议，把复杂度降到了M加N。任何支持MCP的AI客户端都能连接任何MCP Server，可以调数据库、读Figma设计稿、操作Jira，Agent的工具能力就可以无限扩展了。 明白了。那第四层Skill又是什么？ Skill你可以理解为Agent的可复用能力包，就像程序员封装的工具函数——写一次，以后直接调。比如Codex自带一个imggen的Skill，专门用来生成图片。每个Skill有一个核心的skill.md文件定义名称和描述。巧妙的是，Codex每次会话只把Skill的名称和简介带入上下文，不是完整内容，这样既省Token，又能让模型知道什么时候该调用哪个Skill。 触发方式呢？是得手动指定还是能自动识别？ 两种都行。你可以显式输入比如$imggen直接调用，也可以隐式触发——你说'帮我生成一张App图标'，模型发现这跟imggen的描述匹配，就自动触发了。而且因为Agent已经有项目上下文，你甚至不用详细描述想要什么风格，它能自己推断。 好，终于到最顶层了——Harness Engineering。这个名字挺有意思的，Harness是马具的意思？ 对，这个比喻特别形象。大模型是一匹能力很强的马，写代码基本没问题，但你不给它套上马具，它就会到处乱跑。Harness就是马之外的一切装备。它要解决的核心问题是：你丢给AI一个需要一两天才能完成的大任务，不去监督的话，它一定会跑偏。 所以Harness具体包含哪些东西？ 它是一套完整的运行框架。agents.md变成了索引目录，告诉AI哪些规范去看哪个文件；还有design.md定义UI规范；各种验收测试脚本，比如冒烟测试——这个名字来自硬件工程，新电路板通电冒烟就说明有问题。在软件里就是跑一遍核心功能看会不会崩溃。再加上CI/CD流水线、Git worktree支持多个Agent并行工作，每个Agent在独立分支上开发，最后通过Pull Request合并。这就把AI编程从单线程对话进化成了多线程并行工程。 听起来很完善，但我有个疑问——对于独立开发者来说，搞这么一套会不会太重了？ 你这个问题问到点子上了。其实对独立开发者和新项目，真不建议死板套用完整流程。可能你五分钟能搞定的事，走完整套验收要一个小时，改个按钮AI都要跑五六分钟脚本。我的建议是轻量级起步：一个agents.md、一个design.md、一个冒烟测试脚本，够了。等项目真做大了、迭代久了，再逐步搭建完整的Harness体系。 嗯，这个建议很务实。其实回过头来看这五个概念，从Prompt到Harness，本质上就是AI编程从'对话式辅助'走向'自主化工程'的一条演进路径。理解每一层解决什么问题，比死记它们的定义重要得多。根据自己项目的规模和阶段灵活取舍，这才是正道。 完全同意。而且这些概念还在快速演进中，可能半年后又会冒出新东西。但底层逻辑不会变——怎么让AI更准确地理解需求、更稳定地执行任务、更可靠地交付成果。抓住这条主线，新概念出来你也不会迷路。