飞行的蜗牛

vuePress-theme-reco 极客学长    2013 - 2026
飞行的蜗牛 飞行的蜗牛

Choose mode

  • dark
  • auto
  • light
首页
分类
  • Database
  • 技术杂谈
  • 前端开发
  • PHP
  • Docker
  • Jekyll
  • 随笔杂谈
  • FunnyTools
  • 读书笔记
  • Java
  • SpringBoot
  • 区块链技术
  • IPFS
  • C/C++
  • Filecoin
  • Golang
  • Sharding-JDBC
  • 分布式存储
  • Lotus-源码系列
  • Lotus
  • Spring-源码系列
  • 框架源码系列
  • AI
  • ChatGPT
  • Stable Diffusion
  • DeepSeek-R1
  • DeepSeek-V3
  • 商业
  • 教育
  • 编程
  • 缩放定律
  • 大模型
  • 创业
  • 工具
  • 逆向学习法
  • 递归学习
标签
时间抽
关于作者
开源项目
GeekAI (opens new window)
author-avatar

极客学长

170

文章

336

标签

首页
分类
  • Database
  • 技术杂谈
  • 前端开发
  • PHP
  • Docker
  • Jekyll
  • 随笔杂谈
  • FunnyTools
  • 读书笔记
  • Java
  • SpringBoot
  • 区块链技术
  • IPFS
  • C/C++
  • Filecoin
  • Golang
  • Sharding-JDBC
  • 分布式存储
  • Lotus-源码系列
  • Lotus
  • Spring-源码系列
  • 框架源码系列
  • AI
  • ChatGPT
  • Stable Diffusion
  • DeepSeek-R1
  • DeepSeek-V3
  • 商业
  • 教育
  • 编程
  • 缩放定律
  • 大模型
  • 创业
  • 工具
  • 逆向学习法
  • 递归学习
标签
时间抽
关于作者
开源项目
GeekAI (opens new window)
  • Prompt Engineering、Harness Engineering、Loop Engineering 一次给你讲透

    • Prompt Engineering,先把话说明白
      • Harness Engineering,给 AI 套上缰绳
        • Loop Engineering,让 AI 进入工作循环
          • 三个阶段不是替代,是一层层往外长
            • 未来的程序员,编的不只是代码

            Prompt Engineering、Harness Engineering、Loop Engineering 一次给你讲透

            vuePress-theme-reco 极客学长    2013 - 2026

            Prompt Engineering、Harness Engineering、Loop Engineering 一次给你讲透


            极客学长 2026-06-16 0 Prompt Engineering Harness Engineering Loop Engineering 提示词工程 缰绳工程 循环工程 AI 编程 AI Agent Claude Code Cursor Codex ReAct SWE-agent AGENTS.md feedforward feedback Mitchell Hashimoto Martin Fowler Agentic Loop

            先说结论: AI 编程正在经历三阶段演进——Prompt Engineering(会说话)、Harness Engineering(会干活,给 Agent 套缰绳:规则、测试、CI)、Loop Engineering(会持续干活,设计可收敛的计划-行动-观察循环)。三者不是替代关系,而是输入 → 约束 → 迭代,一层层往外长;很多小白卡住,是因为拿错了阶段的工具。下文为概念梳理与作者判断,截至 2026-06。

            头图,AI 编程从对话走向自动化系统

            最近我有个很强烈的感觉。

            很多人聊 AI 编程,其实聊的不是一件事。

            有人说 AI 编程就是会写 Prompt。

            有人说不是,现在关键是 Claude Code、Codex、Cursor 这些 Agent。

            还有人说,真正厉害的不是让 AI 写一段代码,而是让它自己开工、自己测试、自己修 Bug、自己交付。

            这三种说法都对。

            但它们不在同一个层级。

            如果硬要用一句人话概括,我觉得 AI 编程正在经历三个阶段。

            第一个阶段,提示词工程。

            第二个阶段,缰绳工程。

            第三个阶段,循环工程。

            听着有点抽象对吧。

            我换个更土的比喻。

            一开始,你是在和一个特别聪明但没有上下文的人聊天。

            后来,你开始给他工位、电脑、项目文档、代码规范、测试环境和审批流程。

            再后来,你不是每一步都盯着他了,而是设计一套工作机制,让他可以一轮一轮往前推进。

            从会说话,到会干活,再到会持续干活。

            这就是 AI 编程从 Prompt,到 Harness,再到 Loop 的变化。

            说真的,这个变化挺重要的。

            因为很多小白卡住,不是因为不会用 AI,而是拿错了阶段的工具。

            你明明需要的是一套工作流,却还在纠结一句 Prompt 怎么写得更漂亮。

            这就像你想开工厂,结果天天研究怎么把招聘话术写得更感人。

            方向就偏了。

            # Prompt Engineering,先把话说明白

            最早的 AI 编程,大概就是这么开始的。

            你打开 ChatGPT,对它说,帮我写一个 Python 爬虫。

            它给你一段代码。

            你复制到本地,跑一下,报错。

            你再把错误复制回去,说这里错了,帮我改。

            它再给你一段。

            你再复制。

            来来回回。

            这就是提示词工程的典型形态。

            所谓 Prompt Engineering,其实就是研究怎么把你的意图,翻译成模型更容易理解、更容易执行的输入。

            OpenAI、IBM、Google Cloud、Prompt Engineering Guide 这些资料里,对 Prompt Engineering 的解释都差不多。

            它不是玄学。

            它主要做几件事。

            把任务说清楚。

            把上下文补齐。

            把输出格式规定好。

            给几个例子。

            让模型一步一步推理。

            把边界条件讲明白。

            比如你不要只说,帮我写个登录功能。

            你要说,我用 Next.js,数据库是 PostgreSQL,认证用 JWT,需要邮箱密码登录,要有输入校验,要返回统一错误格式,给我生成前端表单、后端接口和测试用例。

            这两句话的结果差别会很大。

            因为大模型不是读心术。

            它看到的是 token。

            你给它的信息越模糊,它只能越靠猜。

            你给它的任务越具体,它越容易沿着你铺好的路走。

            所以提示词工程的底层逻辑,其实是压缩歧义。

            概念图,Prompt 把模糊需求压缩成清晰指令

            把「你脑子里知道,但模型不知道」的东西,尽量写进输入里。

            这一步对小白非常有用。

            因为它逼你把需求讲清楚。

            很多人以为自己不会写代码,其实更早一步,是不会描述需求。

            你让他讲自己想要什么,他讲不出来。

            你让他拆功能,他拆不动。

            你让他说验收标准,他更懵。

            于是他就只能问一句,帮我做个小程序。

            然后等 AI 猜。

            猜对了就觉得 AI 真神。

            猜错了就骂 AI 真蠢。

            但问题在于,Prompt Engineering 有一个明显天花板。

            它主要发生在一次对话里。

            你问。

            它答。

            你再问。

            它再答。

            它可以生成代码,但它看不到你真实项目里的全部约束。

            它可以解释错误,但错误日志要你贴过去。

            它可以建议测试,但测试要你自己跑。

            它像一个很聪明的场外顾问。

            顾问再聪明,也不是坐在你电脑前干活的人。

            这就是为什么很多人用 AI 写 Demo 很爽,一到真实项目就痛苦。

            Demo 的世界很干净。

            真实项目的世界很脏。

            老代码、奇怪依赖、历史包袱、团队规范、CI、部署脚本、权限、环境变量、数据库迁移、测试覆盖率。

            这些东西不是一句神级 Prompt 能解决的。

            于是第二阶段来了。

            # Harness Engineering,给 AI 套上缰绳

            Harness 这个词很有意思。

            它可以理解成马具,也可以理解成安全带,还可以理解成测试架。

            我更喜欢翻译成「缰绳」。

            不是因为 AI 是马,而是因为这个词很准确。

            你不是把 AI 关起来。

            你是在让它能跑,但跑在你允许的轨道里。

            2026 年前后,Harness Engineering 这个词开始在 AI 编程圈变热。

            Mitchell Hashimoto 在自己的 AI 使用历程里提到,要把 Agent 每次犯错都变成环境和工具的改进。

            OpenAI 的 Ryan Lopopolo 写过一篇 Harness Engineering 的文章,讲他们怎么让 Codex 在一个内部项目里写应用代码、测试、CI、文档、观测和内部工具。

            Martin Fowler 网站上 Birgitta Böckeler 也写了一篇很系统的文章,把 Harness 讲成一套围绕编码 Agent 的外部控制系统。

            这些文章有一个共同判断。

            当 AI Agent 开始参与真实软件开发时,关键不再只是模型有多聪明,而是你给它什么环境。

            这句话很反常识。

            很多人以为 AI 编程的进步,全靠模型升级。

            GPT 更强,Claude 更强,Gemini 更强,所以代码就会更好。

            当然,模型升级很重要。

            但如果你真的用过编码 Agent,就会发现另一件事。

            同一个模型,在不同项目环境里,表现会差很多。

            有的项目,AI 改起来很顺。

            有的项目,AI 一进去就迷路。

            差别不只是代码难度。

            还包括项目有没有清晰结构,测试好不好跑,错误信息清不清楚,文档有没有过期,命令是不是统一,架构边界是不是明确,代码风格有没有自动检查。

            这些东西合起来,就是 Harness 的一部分。

            缰绳工程,规则、测试、文档和 CI 共同围住 AI Agent

            Martin Fowler 那篇文章里用了一个很好懂的框架,叫 feedforward 和 feedback。

            我用人话翻一下。

            Feedforward 是提前引导。

            Feedback 是事后纠偏。

            提前引导是什么?

            比如 AGENTS.md、CLAUDE.md、项目规则、架构说明、代码风格、目录约定、禁止事项、常用命令、任务模板。

            它们的作用是让 AI 在动手之前少走歪路。

            事后纠偏是什么?

            比如 lint、typecheck、单元测试、集成测试、CI、代码审查、架构检查、安全扫描、LLM-as-judge。

            它们的作用是让 AI 做完之后,能看到自己哪里错了,然后自己修。

            这就很像教一个新人程序员。

            你不会只对他说,去写吧。

            你会给他项目文档,告诉他哪里不能动,告诉他怎么跑测试,告诉他 PR 要过哪些检查。

            你也不会每一行都盯着他写。

            你会让他提交,然后让测试、review、CI 帮你拦住一部分问题。

            AI Agent 也是一样。

            没有 Harness 的 Agent,很像一个天赋很高但没有组织纪律的新人。

            它会写。

            但它不知道你们这个项目为什么这么写。

            它会改。

            但它不知道哪些地方不能碰。

            它会跑命令。

            但它可能跑错环境,删错文件,或者陷在一个错误里疯狂尝试。

            Harness Engineering 做的事,就是把人的经验沉淀成环境。

            注意这句话。

            不是把人的经验写成一句更长的 Prompt。

            而是沉淀成环境。

            比如你发现 AI 每次都忘记跑测试。

            你不要每次都在对话里提醒它,记得跑测试。

            你应该把「修改后必须运行 npm test」写进项目规则,或者做成 hook,或者让 CI 必须通过。

            比如你发现 AI 经常改错架构边界。

            你不要每次都骂它,你要把模块职责写清楚,补架构测试,或者把不该访问的路径通过 lint 规则拦住。

            比如你发现 AI 总是读错文档。

            你要让文档变短,变准,变成离代码更近的说明,而不是让它去翻三年前没人维护的 Wiki。

            这就是缰绳工程最重要的变化。

            工程师的工作,从「亲自写每一行代码」,变成「设计一个让 AI 更容易写对代码的系统」。

            这话听着有点刺耳,但我觉得它很真实。

            以前好的工程师,是自己能写出好代码。

            现在更进一步,好的 AI 编程工程师,要能设计出一个环境,让 AI 也更容易写出好代码。

            这不是偷懒。

            这是工程能力换了形态。

            SWE-agent 那篇论文也很能说明这个趋势。

            它提出 Agent-Computer Interface,也就是给语言模型专门设计一套使用计算机的界面,让模型更容易浏览代码、编辑文件、执行测试。

            它在 SWE-bench 和 HumanEvalFix 上取得了当时很强的结果。

            这里的重点不是某个数字多漂亮。

            重点是,论文把一个问题讲清楚了。

            AI Agent 不是普通人类用户。

            它需要自己的工具界面。

            你给人类用的 IDE,不一定适合模型。

            你给模型设计更合适的命令、更清楚的反馈、更可控的动作空间,模型就更容易完成软件工程任务。

            所以 Harness Engineering 背后的原理,不是「写更神的咒语」。

            而是控制论。

            给系统输入约束。

            观察输出结果。

            把错误反馈回系统。

            持续修改环境,让下一次错误更少。

            到这里,AI 已经不只是回答问题了。

            它开始在一个被设计过的工作环境里干活。

            但还差一步。

            因为再好的缰绳,也只是让它每次干活更稳。

            真正的自动化,需要它能一轮一轮跑下去。

            这就到了 Loop Engineering。

            # Loop Engineering,让 AI 进入工作循环

            循环工程这个词,现在还没有 Prompt Engineering 那么成熟,也没有 Harness Engineering 那么有行业共识。

            但它指向的东西非常清楚。

            AI 编程正在从「一次生成」,走向「持续迭代」。

            早期你让 AI 写代码,它给你一段答案。

            这叫一次生成。

            后来你让 Agent 读文件、改文件、跑测试、看报错、再修改。

            这就进入循环了。

            Loop Engineering 研究的,就是怎么设计这种循环。

            一个最基本的 Agent 循环,大概是这样。

            计划。

            行动。

            观察。

            再计划。

            再行动。

            再观察。

            直到完成,或者触发停止条件。

            循环工程,计划、行动、观察、修正不断闭环

            学术上,很多现代 Agent 循环可以追溯到 ReAct。

            ReAct 是 2022 年的一篇论文,全称是 Reasoning and Acting。

            它的核心想法是,让语言模型不要只在脑子里推理,也不要只盲目行动,而是在推理和行动之间来回切换。

            想一步。

            做一步。

            看结果。

            再想一步。

            这件事放到 AI 编程里,特别自然。

            因为写代码本来就是循环。

            你写一段。

            跑一下。

            报错。

            看日志。

            改一下。

            再跑。

            测试通过。

            再重构。

            再跑。

            人类工程师每天就是这么干的。

            所以一个不会循环的 AI 编程助手,天花板一定很低。

            它可以帮你写一段看起来对的代码。

            但它不知道这段代码在你的机器上能不能跑。

            它不知道测试是否通过。

            它不知道改了 A 会不会炸掉 B。

            它不知道自己刚才的假设是不是错的。

            这就是为什么「能执行」比「能生成」重要。

            一个 AI 如果只能生成代码,它还停留在文本世界。

            一个 AI 如果能执行代码、读取错误、修改代码、再次执行,它才进入了软件工程世界。

            MindStudio 关于 Loop Engineering 的文章,把循环说成 action、observe、reason、repeat。

            Addy Osmani 的 Agentic Engineering Glossary 里也有 Plan-Act-Observe loop 的说法。

            这些表达不完全一样,但指向同一个东西。

            AI Agent 的能力,不是只看单次回答质量,而是看它能否在环境反馈里持续收敛。

            这里有个很关键的词。

            收敛。

            一个好的循环,不是无限转圈。

            它应该越来越接近目标。

            一个烂循环,就是 AI 在那里疯狂跑命令,报错,修,报错,修,最后 token 烧光,项目还烂了。

            很多人第一次用 Agent 的时候,应该都见过这种场面。

            它看起来很努力。

            终端一直在滚。

            文件一直在改。

            但你越看越害怕。

            因为它不是在解决问题,它是在制造更多问题。

            所以 Loop Engineering 不是让 AI 自己瞎循环。

            它要设计四个东西。

            第一个,目标。

            任务要足够清楚,完成标准要足够明确。

            比如不是「优化这个项目」,而是「让登录接口支持邮箱验证码,并保证现有 auth.test.ts 全部通过」。

            第二个,动作空间。

            AI 能做什么,不能做什么。

            可以读哪些文件,可以改哪些文件,可以运行哪些命令,是否允许联网,是否允许删除文件,是否需要用户批准。

            第三个,观察信号。

            AI 怎么知道自己做得好不好。

            测试结果、类型检查、构建日志、浏览器截图、接口响应、性能指标、用户验收标准,这些都是观察信号。

            第四个,停止条件。

            什么时候算完成。

            什么时候必须停下来问人。

            什么时候判断自己卡住了。

            什么时候回滚。

            没有停止条件的 Agent,很吓人。

            就像一个新人半夜三点还在生产库上改配置,而且他觉得自己很负责。

            你敢信???

            循环工程真正要解决的,就是让 AI 的持续行动变得可控。

            # 三个阶段不是替代,是一层层往外长

            到这里,你会发现三阶段之间的关系越来越清楚。

            Prompt Engineering 是把任务说清楚。

            Harness Engineering 是把环境搭清楚。

            Loop Engineering 是把过程跑清楚。

            一个解决输入。

            一个解决约束。

            一个解决迭代。

            这三个东西组合在一起,才是今天 AI 编程真正的样子。

            不是一句 Prompt 打天下。

            也不是买个 Agent 工具就完事。

            更不是把人完全踢出去。

            恰恰相反,人的位置更重要了。

            只是人的位置变了。

            人从写代码的人,变成定义目标、设计环境、检查结果、升级系统的人。

            这就是发展规律。

            AI 编程的重心,正在从「表达」迁移到「系统」。

            第一阶段拼表达能力。

            谁更会写 Prompt,谁拿到的答案更好。

            第二阶段拼工程环境。

            谁的项目更清晰,测试更完整,规则更明确,AI 就更容易写对。

            第三阶段拼过程设计。

            谁能把任务拆成可循环、可验证、可停止的流程,谁就能让 AI 做更长链条的工作。

            这跟工业史有点像。

            手工业时代,最重要的是师傅的手艺。

            工厂时代,最重要的是生产线、模具、质检和流程。

            自动化时代,最重要的是闭环控制系统。

            AI 编程也在走类似的路。

            Prompt 像手艺。

            Harness 像工厂。

            Loop 像自动化产线。

            三阶段演进,手艺、工厂和自动化产线

            但我不想把这个说得太玄。

            对普通人来说,最实际的建议其实很简单。

            如果你还是小白,不要一上来就追求什么全自动 Agent。

            先把 Prompt 练好。

            学会讲清楚需求,学会给上下文,学会规定输出,学会让 AI 解释代码,学会让 AI 帮你拆任务。

            这是地基。

            如果你已经能用 AI 写一些小功能,就开始搭 Harness。

            给项目写一份 AGENTS.md。

            把常用命令写进去。

            把代码规范写进去。

            把测试跑通。

            把 lint、typecheck、单元测试都接起来。

            让 AI 每次改完都能自己验证。

            这是从玩具走向工程的关键一步。

            如果你已经能让 Agent 稳定完成小任务,再考虑 Loop。

            把任务拆成小循环。

            每轮有目标,有动作,有观察,有停止。

            让 AI 先做低风险、可回滚、可测试的任务。

            比如修一个测试、补一个接口、改一个页面、生成一份迁移脚本。

            不要一开始就让它重构整个系统。

            这不是勇敢。

            这是把方向盘拔了还踩油门。

            # 未来的程序员,编的不只是代码

            我现在越来越觉得,AI 编程最有意思的地方,不是程序员会不会被替代。

            这个问题太粗糙了。

            真正有意思的是,软件工程这门手艺正在被重新分层。

            以前我们觉得,写代码就是核心。

            现在看,写代码只是其中一层。

            需求表达是一层。

            上下文管理是一层。

            工程约束是一层。

            测试反馈是一层。

            循环控制是一层。

            人机协作是一层。

            AI 把代码生成的成本打下来了,于是以前被我们忽略的那些东西,反而变得更贵。

            清晰的需求更贵。

            好的测试更贵。

            可理解的架构更贵。

            稳定的流程更贵。

            能把混乱系统整理到 Agent 可工作状态的人,更贵。

            这也是为什么我觉得,小白现在学 AI 编程,不要只学「怎么让 AI 写代码」。

            你要学的是,怎么让 AI 在一个真实工程里可靠地工作。

            这两件事差很多。

            前者像变魔术。

            后者像做工程。

            魔术看起来爽,但工程才能交付。

            所以回到开头那三个词。

            Prompt Engineering,是你学会和 AI 说话。

            Harness Engineering,是你学会给 AI 搭工作环境。

            Loop Engineering,是你学会让 AI 在反馈里持续往前跑。

            三者合在一起,才是 AI 编程从玩具到生产力的完整路径。

            我自己也还在摸索。

            很多东西也没完全跑通。

            但有一点我越来越确定。

            未来最厉害的程序员,不一定是手写代码最快的人。

            而是最会设计「人和 AI 一起工作的系统」的人。

            他知道什么时候该自己写。

            什么时候该让 AI 写。

            什么时候该补规则。

            什么时候该补测试。

            什么时候该停下来,不要让循环继续发疯。

            这听起来不像传统编程。

            但它仍然是编程。

            只是我们编的不再只是代码。

            我们开始编流程,编约束,编反馈,编循环。

            说真的。

            这才是 AI 编程真正刺激的地方。

            结尾图,人和 AI 共同设计一套可运行的软件系统

            本站博文如非注明转载则均属作者原创文章,引用或转载无需申请版权或者注明出处,如需联系作者请加微信: geekmaster01

            claude-fable-5 两小时重构十几万行代码后:当效率不再稀缺,意义变贵了