AI编程进化史-公众号版

AI编程进化史

AI 编程进化史：为什么同样的模型，有的好用有的难用？

你是不是也有过这种经历——

让 AI 写一个功能，前 200 行代码工整漂亮，让人直呼"要失业了"。

但越往后写，代码质量断崖式下跌：变量命名开始放飞，逻辑开始绕圈，莫名其妙的技术债一层层往上堆。最后你花了比手写还多的时间去修 bug，气得关掉窗口自己重写。

同样的模型，差距从哪来？

Claude、GPT、Gemini……如今同等能力的模型越来越多，但各家 AI 编程产品的体验差距反而越拉越大。

有的产品写出来的代码可以直接提交上线，有的产品写出来的代码却让人看得血压飙升。

因为模型是一样的。差距在于——怎么用模型，怎么稳定地用模型。

在 AI 行业，这件事有一个正式的名字：

这不是一个新鲜词，但它正在成为决定 AI 编程产品生死的分水岭。

三层架构：把 AI 编程 Agent 拆开看

如果把一个 AI 编程 Agent 比作一辆自动驾驶汽车：

●模型 = 发动机（动力来源）

●Harness 系统 = 方向盘 + 刹车 + 导航（控制与调度）

光有马力是不够的。没有控制系统的车，再强的发动机也只会让你更快地撞上墙。

具体来说，一个生产级 AI 编程 Agent 分为三层：

Scaffolding（脚手架层）

AI 启动前的一切准备工作：环境初始化、工具注册、权限配置……

它决定了 AI "能做什么"。

Harness（运行时编排层） 核心

整个智能体的中央调度系统。

负责管控 AI 的核心推理循环：什么时候该调用工具、什么时候该回传上下文、什么时候该停下来反思——以及如何安全地执行这些决策。

它决定了 AI "怎么做"。

Context Engineering（上下文工程层）

管理大语言模型最稀缺的资源——token。

每一轮对话，哪些信息该喂给模型、哪些该丢弃、哪些该压缩后保留——这些决策直接影响输出质量。

它决定了 AI "看到什么"。

Harness 这么重要，为什么现在才火？

要理解这个问题，得先看懂 AI 编程的三个阶段。

这三件事不是替代关系，而是叠罗汉——每一层都建立在上一层的基础上。

第一阶段：Prompt Engineering（提示词工程）

核心命题：怎么说，AI 才能听明白？

这是 AI 编程的"石器时代"。所有人都在研究怎么把指令写得更清楚：

●角色设定：给 AI 划定身份和职责边界（"你是一个资深前端工程师"）

●Few-shot 示例：给出输入输出的范例，让 AI 照着格式生成

●思维链（CoT）：在指令中要求 AI 一步步拆解问题，减少跳跃式错误

这个阶段的天花板很明显——

你不可能靠一条 prompt 描述清楚整个项目的所有约束。单条指令再好，也只能控制 AI 的单次输出。

第二阶段：Context Engineering（上下文工程）

核心命题：给模型看什么，它才能做出最好的决策？

既然单条 prompt 不够，那就为模型动态构建整个上下文环境。

让模型在做每一个决策时，都能精准看到它所需要的全部信息——当前任务文件、历史对话摘要、工具使用规则、相关代码库片段……

核心理念只有一句话：

这听起来简单，做起来极难。

上下文窗口是有限的稀缺资源。给多了，token 成本爆炸且信息过载；给少了，模型缺乏关键信息做不出好决策。这本质上是一个信息检索与压缩的问题。

第三阶段：Harness Engineering（驾驭工程）

核心命题：模型不听话，怎么办？

这是 AI 编程目前最前沿的战场。

到这一阶段，模型的能力已经不再是瓶颈。真正的问题是——模型有足够的能力，但它不一定会按你想要的方式去用它。

这不是 prompt 能解决的问题。你需要一个运行时系统来持续监控、纠偏、约束 Agent 的行为。

来看看真实数据：

同一模型，换个"外壳"，效果天差地别。

AI 编程为什么总翻车？四种经典失败模式

如果你用过 AI 写代码，下面这四种场景你一定不陌生。

❶ 试图一步到位

在一个对话窗口里想把整个功能做完。

结果？上下文窗口迅速耗尽，后半段的代码质量断崖式下跌。模型开始"遗忘"前面的约定，开始"编造"不存在的 API，开始产生幻觉。

AI 不适合马拉松。它需要接力跑。

❷ 过早宣布胜利

复杂项目开发到后期，AI 完成了几个核心模块，有了可见的产出——

然后就主动终止了。

哪怕大量功能还没实现，核心需求尚未满足，它也会判断"任务已完成"。

AI 天生"乐观"。它需要有人在旁边不断提醒它：活还没干完。

❸ 过早标记功能完成

AI 写完了某个功能，就把它标记为"已完成"。

它不会主动去做端到端的功能测试，不会去验证这个功能在真实环境里到底能不能跑。

看起来能跑，实际上到处是隐藏的 bug。

❹ 机械复制代码模式

AI 会机械地沿用项目中已有的代码风格和架构模式——哪怕这个模式本身就是错的。

而且它会以极快的速度在整个项目里持续复制和放大这些错误。

不加约束的 AI，是一个效率极高的"技术债倍增器"。

Harness 的四大护栏：怎么管住 AI？

既然问题清楚了，解法也就明确了。Harness 的工程实践，本质上就是四道防线。

护栏一：上下文工程——少即是多

AGENTS.MD 这类给 AI 看的项目说明文件，越长、信息越冗余，Agent 的任务成功率反而越低。

为什么？因为过多"指导"会挤掉真正重要的任务代码，同时推高推理成本。

这不是偷懒。上下文是稀缺资源。少即是多。

护栏二：架构约束——用代码管代码

这是 Harness 体系中最核心的一条。

不是用 prompt 告诉 Agent "请遵守三层架构"。

而是用确定性的 Linter 和结构化测试来机械地执行架构约束。

prompt 是"请求"，Linter 报错是"强制"。

更进一步的做法是——在 Linter 报错信息里直接嵌入修复指引，告诉 Agent 具体应该怎么改。

护栏三：Feedback Loop——让 Agent 审 Agent

传统软件开发有 Code Review。AI 编程同样需要 Review——只不过审视代码的不再是人。

在 Harness 体系中，代码审查变成了 Agent 对 Agent 的模式。

形成标准化闭环：

每一个环节都有 Agent 参与，每一轮循环都在提纯代码质量。人类只在关键节点介入。

护栏四：熵管理——对抗项目的自然腐化

软件项目天然走向混乱。AI 加速了代码的生产，也加速了技术债的积累。

随着时间推移，AI 生成的项目会自然积累大量问题：

文档过时、架构漂移、代码风格走样、死代码堆积、测试用例腐化……

解法：让 Agent 为 Agent 维护文档和规范。

用 AI 来对抗 AI 带来的熵增。形成自我纠偏的闭环。

这对你意味着什么？

看到这里，你可能会想：这些听起来都是做 AI 编程产品的人才需要关心的。我是普通开发者，跟我有什么关系？

关系很大。因为——

1. 选工具，本质是选 Harness

Cursor、Windsurf、Copilot、Claude Code……

它们调用的底层模型可能差不多。但体验差距巨大。

你花时间对比模型 benchmark 的那点分差，远不如对比各家 Harness 系统的实际表现。

下次选工具，少看跑分，多看"它能不能在多轮对话后依然稳定"。

2. 用好工具，本质是理解 Harness 逻辑

你知道为什么有时候 AI 表现很好，有时候突然变傻吗？

大概率不是模型"抽风"。是上下文被污染了、架构约束被绕过了、反馈循环断裂了。

理解 Harness 的工作原理，你能更快地诊断问题、调整策略，而不是无意义地反复重试 prompt。

3. 个人也可以搭建简易 Harness

你不需要自己写一个完整的 Agent 框架。但你完全可以——

●写好项目级别的 AGENTS.MD / CLAUDE.md（控制在 60 行以内）

●配置好 Linter + 格式化工具，让 AI 每次输出后自动触发检查

●建立轻量的检查清单，在 AI 声称"已完成"时对照核查

●养成多轮拆分任务的习惯，不要让 AI 一口吃成胖子

这些小习惯，就是你个人的 Harness。

写在最后

AI 编程的进化，本质上是一场从"写好提示词"到"构建好系统"的范式转移。

●PrPrompt Engineering 解决的是"怎么说"

●C Context Engineering 解决的是"给什么信息"

        Harness Engineering 解决的是"怎么管住它"

三条线不是替代关系。是叠加递进——每一层都建立在上一层的基础之上。

真正能稳定产出高质量代码的 AI 编程产品，必定在这三个层次上都下了硬功夫。

作为开发者，我们不需要自己去造一个 Harness 系统。

但理解这套逻辑，能让你从"被 AI 坑"变成"驾驭 AI"。

如果这篇文章让你对 AI 编程有了新的理解，欢迎点赞、在看、转发，让更多人看到。

你用 AI 编程踩过哪种坑？欢迎在评论区聊聊