AI Coding 范式演进全攻略：Qoder、Kiro、Claude Code 深度解析，从入门到精通，收藏这一篇就够了！

本文从产品形态、工作流设计和验证体系三个维度分析了 Kiro、Claude Code 和 Qoder 三款 AI Coding 工具。产品判断Kiro用 Requirement → Design → Task List 三阶段 Spec 在编码前强制对齐意图适合 Feature 级需求和夜间 long runningClaude Code代表 CLI 形态的极致模型厂商亲自下场形成模型 × Agent双飞轮是当前最前沿的 AI Coding 产品Qoder以 CLI 为内核、IDE 为皮在 Editor 协同和 Quest 自主之间自如切换是兼容性和前沿性平衡最好的选择。形态之争CLI 天然以任务闭环为中心端到端执行、长时自治、多 Agent 并行都是默认路径IDE 做同样的事需要额外的产品代价。差异不在功能多少而在默认工作流是否围绕 Agent 设计。方法论小修小补用 Vibe中等任务用 PlanFeature 级别上 Spec– 三种模式对应不同的任务粒度不是互相替代而是按需切换。Harness Engineering的核心是四条实践地图式导航AGENTS.md、知识嵌入仓库、机械化验证、迭代自愈。态度是认同实践警惕教条 – 模型能力是地基验证闭环是杠杆AGENTS.md Rules Hooks Verification 是任何 AI Coding 工作流的基础设施。AI Coding 范式跃迁前言这两个月内Qoder Quest 依旧是我日常开发的主力但为了避免自己的认知被单一产品绑定我也强迫自己试用了很多其他产品Kiro、Claude Code、Codex 等。这些产品并不是工作在同一维度我甚至会同时使用它们本文我也会基于个人使用体验来分析一下。本文所有的对比和评价都是以 QoderQuest CLI作为基准参照——它是我最熟悉的工具也是我衡量其他产品时的默认坐标系。AI 工具概述先按照产品的交互形态把我所接触的 AI 工具分为几类基于 VS Code 为界面的 IDE 型产品Qoder、Kiro、Cursor、Trae、Windsurf非 VS Code 的原生 IDE 型产品Zed、JetBrainsQoder 插件和上边同属 IDE 型产品独立 APPClaude Desktop、Codex以终端为界面的 CLI / TUI 形态产品Claude Code、Qoder CLI、Open Code、Qwen Code壳子不同内核也不同。值得注意的是Qoder 在 IDE 内就提供了两种协作形态Qoder Editor偏人机协同你依然在写代码AI 在旁辅助补全、生成和解释Qoder Quest则偏自主执行底层由 Qoder CLI 驱动交互模式更接近终端形态的 Agent。这意味着你可以在同一个 IDE 中根据任务特点自如切换——小改动用 Editor 精准操作大任务用 Quest 全权委托。这也是我选择 Qoder 为主力工具的原因。以下几个维度可以帮助理解这些产品之间的真实差异人机协作模式从辅助补全到全自主执行这些产品落在一条自主性光谱的不同位置上。IDE 型产品中人依然在写代码终端形态则让 AI 直接操作文件系统和 shell人的角色更偏向指挥官。Qoder 本身就是这条光谱的缩影——Editor 模式落在协同端Quest 模式落在自主端。没有绝对更好的位置取决于任务类型和你对 AI 的信任程度。模型接入各家绑定的模型不同直接决定能力上限。一个值得关注的趋势是模型厂商正在亲自下场做 AI Coding 产品——这一点我会在 Claude Code 章节详细展开。上下文工程这是当下各产品差距最大的地方。早期 IDE 型产品靠语义索引和向量检索召回上下文Claude Code 则直接让 Agent 用bash、grep、find搜代码库——精心设计的 RAG 管线被一个会用 grep 的 Agent 打败了。当然前提是模型本身要足够强强到能自己决定该搜什么。工作流定义大部分 IDE 型产品不太干预工作流但 Kiro 推崇 Spec 驱动开发强制你走需求 → 设计 → 实现的路径终端产品则天然支持 shell 脚本和编排工具串联多个 Agent。后文我会重点展开聊Kiro、Claude Code这两个我最近深度使用的产品结合跟 Qoder 的对接从实际产品体验出发做更具体的分析。三款 AI Coding 工具对比Kiro在熟悉了 Qoder 之后我对其他 IDE 型产品的尝试意愿度其实是不高的在概述中我也提及 IDE 类型的产品我认为大多是同质化的各个厂商的 IDE 型产品代差不超过 0.5 代。但接触 Kiro 本身还是因为一个很现实的原因Kiro Teams 版正在公司内部内测Opus 4.6 不限量使用谁能拒绝 Opus 4.6 呢。对不起 Qoder我投敌了暂时。Spec Workflow聊 Kiro 很难不聊到它的 Spec 模式。说实话我对 Kiro 的 Spec 一开始是有偏见的Plan 已经够用了Spec 这一套流程显得太重了。我也在重新校准自己的认知避免今后在面对一些新的 AI Feature 的时候因为自己不愿意尝试就草率下结论。特别是在 AI 噪音很多的当下我更愿意相信自己体验过后的真实感受。Kiro 的 Spec 遵循的是一套Requirement → Design → Task List三阶段的工作流每个阶段都会生成一份独立的文档存放在项目的.kiro/specs/目录下。第一阶段Requirements。Kiro 会基于你的需求描述生成一份requirements.md采用 EARSEasy Approach to Requirements Syntax标记法把需求拆解为结构化的验收条件格式类似 “WHEN [某个条件] THE SYSTEM SHALL [预期行为]”。这一步的目的是把模糊的想法变成可测试、可追踪的需求条目。第二阶段Design。基于 RequirementsKiro 生成design.md记录技术架构、数据流、关键组件之间的交互关系。这一步解决的是怎么实现的问题——选什么技术方案、模块怎么划分、接口怎么定义。第三阶段Task List。最后Kiro 基于前两份文档拆解出离散的实现任务列表。每个任务足够小、足够具体可以直接交给 Agent 逐个执行。整个流程是串行且不可跳过的——你必须先确认上一阶段的产出才能推进到下一步。每个阶段你都可以审查、修改、追加确认无误后再继续。Kiro 最初只有这一种 Requirement-First 的流程。在后来的一次更新中Kiro 加入了Design-First变体调整了前两个阶段的顺序先写技术设计再反推需求最后生成任务列表。这个变体适用于你已经有明确技术方案的场景——比如你很清楚要改哪些模块、用什么方案只是需要把实现计划结构化地落下来。Spec 模式的体验感受实际用下来我对 Spec 模式的态度从偏见变成了有条件的认可。Spec 解决的是一个真实问题在没有约束的情况下AI Agent 拿到一个模糊的需求就直接开写代码写出来的东西经常跑偏。模型已经足够聪明问题不在于写代码能力而在于对需求的理解——你可能只是想做个 POC它给你造了个生产级工程。Spec 模式强制在编码之前插入一个对齐环节让你和 AI 先就要做什么和怎么做达成共识再动手。无论是澄清需求边界还是校准技术方案的轻重程度这个对齐过程都是必要的。Requirement 和 Design 阶段的价值超出预期。AI 生成的需求文档会帮你把很多没想到的边界情况列出来——错误处理、空状态、权限校验这些容易遗漏的点。审查 Requirements 的过程本身就是一次需求梳理即使你最终删掉一半条目这个思考过程也有价值。Design 阶段则确保技术方案在动手之前就被校准过而不是写到一半才发现方向跑偏。过年期间我形成了一套稳定的使用节奏每晚睡前花数十分钟设计一个 Feature 级别的 Spec仔细打磨 Requirements 和 Design 的细节然后让 Kiro 自动执行 Task List第二天早上起来验收结果。大块的 Task List 通常会运行数小时包含 Verification 环节只要 Spec 的细节到位验收结果通常令人满意。这种这种睡前设计、醒来验收的开发模式带来了全新的体验——它把人的注意力集中在最有价值的设计决策上把执行完全交给了 Agent。但 Spec 的问题在于流程的刚性。三个阶段串行且不可跳过即使是一个你非常清楚怎么做的小功能也要走完整套流程。对于复杂功能这个投入产出比是正的但对于日常的小需求和 bug fix这套流程就太重了。现实中的开发不是所有任务都值得写一份 Spec所以 Kiro 也提供了 Vibe 模式和 Bugfix 模式以应对小需求。Spec 的本质是 Prompt Context Engineering 的结构化封装。Requirements 和 Design 文档最终都会作为上下文喂给 Agent让它在执行 Task List 时有更充分的信息。从这个角度看Spec 和你手动在 Prompt 里写清楚需求、贴上设计思路效果是类似的——Kiro 只是把这个过程产品化了降低了门槛但也降低了灵活性。Spec 的价值体现在两个层面对于人类来说它是一个审查节点可以在 Agent 动手之前就校准方向避免 Agent 写完代码再以代码为基准来调整。对于 Agent 来说Spec 提供了一个明确的执行路径和目标而且使得后续的 Verification 有据可依在上下文压缩后可以强制注入也避免了 Agent 失忆。总的来说Spec 模式适合两类场景一是需求不够清晰、需要先梳理的复杂功能二是你希望设置好之后让 Agent 长时间自主运行的场景。如果你是一个对项目足够熟悉、习惯快速迭代的开发者Spec 的仪式感可能会拖慢你处理小任务的节奏——但对于 Feature 级别的工作它确实能帮你把设计和执行干净地分离开。Spec 文档管理的抉择Spec 文档应该提交到 Git 吗这个问题看似简单实际上牵扯出一系列关于团队协作流程的深层抉择。我曾跟我的好友芋艿某团 AI Coding 产品负责人交流他与 AWS Kiro 的工程师有过直接沟通。AWS 内部的实践是Spec 文档被强烈推荐提交到 Git 中。也就是说Spec 不仅仅是 Agent 执行前的临时上下文而是和代码同等重要的版本化资产。团队不仅要做 Code Review还要做Spec Review——在代码动手之前先审查需求和设计是否合理。这个实践背后的逻辑是成立的如果代码是 Agent 写的那么审查代码本身的价值在下降真正需要审查的是指导 Agent 写代码的那份 Spec。代码可以重新生成但 Spec 中的需求理解和设计决策才是不可替代的人类判断。但一旦 Spec 文档不再是一次性产物而是需要长期维护的资产问题就来了它要求团队中所有人都遵循同一套 Spec 实践。代码不再是唯一的 source of truthSpec 才是。新的需求要先改 Spec 再改代码Bug fix 也要回溯到对应的 Spec 去修正 Requirement 或 Design。这意味着团队的 AI Coding 协作流程在某种程度上被 Kiro 的 Spec workflow 绑定了——只有所有人都用 Kiro、都遵循这套三阶段流程Spec 作为团队资产才能真正发挥价值。这样的 trade-off 在实际团队中很难落地尤其是当团队成员对 AI 工具的偏好和熟练度参差不齐的时候。而且一旦 Spec 成为存量资产Agent 的行为也需要随之变得更复杂面对一个新需求它需要先检索项目中已有的 Spec判断这是应该新建一份 Spec还是修正某份既有 Spec 的 Requirement 或 Design。事实上 Kiro 也确实在往这个方向走——它已经能够识别和关联存量 Spec。但这也意味着 Spec 的管理本身成了一项需要持续投入的工程而不仅仅是写完就跑的一次性成本。反观 Qoder Quest 的做法就轻量得多Plan 是一次性的执行上下文任务完成即弃不需要长期维护也不会对团队的工具选择产生绑定。团队协作的规范依然沉淀在 AGENTS.md 和 Rules 中而不是某种特定格式的 Spec 文档里。这种无状态的设计虽然牺牲了 Spec 作为团队知识资产的可能性但换来了更低的协作成本和工具自由度。Kiro SpecKiro Spec vs Qoder Quest SpecVibe / Plan / Spec 三种工作模式我经常跟以十眠为代表的 Qoder 团队研发吐槽你们 Quest 里面的 Spec 就是一个 Plan。当然每个产品都有自己命名的权利。但这句吐槽背后其实藏着一个有意思的观察当前主流的 AI Coding 工作流按人机交互的轮次来看可以分为三个阶段或者说三代vibe/plan/spec三种模式的本质差异在于人在 Agent 执行前介入了多少次决策。Vibe Coding是最轻量的——你说一句话Agent 全权处理。它自己决定技术方案自己拆任务自己写代码。适合你非常清楚要什么、或者不在乎实现细节的场景。代价是你放弃了过程中的所有校准机会结果好不好全看运气和 prompt 质量。Plan以 Qoder Quest Spec 为例在中间插入了一次刹车——Agent 先进行一次需求澄清模型概率性决策 生成一份 Plan技术方案你审查确认后它再执行。相比 Vibe Coding你多了一次在动手前校准方向的机会相比 Kiro Spec它将需求澄清简化了成了 Ask User Question 的卡片选择以及任务拆解阶段流程更轻。本质上Quest 的 Spec 把 Kiro 三阶段模式做了一个投入产出比最优的折中。Spec以 Kiro Spec 为例 则是最重的——三个阶段各自都有一轮用户输入 Agent 执行 用户审查的循环。你在需求、设计、任务拆解上都有明确的校准点。它最适合复杂功能和需要长时间自主运行的场景但对于小需求来说这套仪式的成本太高了。换个角度理解这三种模式不是互相替代的而是对应不同大小的任务粒度。一个成熟的 AI Coding 工作流应该是在不同场景下自如切换——小修小补用 Vibe中等任务用 PlanFeature 级别的工作上 Spec。Kiro Spec 和 Qoder Quest Spec 的对比绝对不能沦为谁做的更重谁就更优秀的对比适合自己的才是最好的。但有一点还是要夸一下 Qoder Quest它将 Vibe 模式和 Spec 模式做了结合由模型根据任务复杂度动态决策可以实现在同一 Quest 任务中多次的切换这相比 Kiro 的 Spec Workflow 更加 Agentic。然而 Qoder Quest 却并没有支持三阶段的 Spec对于 Feature 级别和 long running 的需求支持还有待完善。值得一提的是Qoder CLI 已经支持了三阶段的 specquest-on 模式只不过 IDE 中尚未上线。quest-onKiro 注意事项其他趋同的能力我就不介绍了希望体验 Kiro 的用户可以自己查看官方文档。这一点也得夸一下 Kiro官方文档不仅仅是一个操作手册也是一个 Kiro AI Coding 实践指南有非常明确的方向性和实践指导价值。从文档中也可以发现 Kiro 是一个敢于下判断并坚守的产品这一点让使用者非常舒服。配置 YOLO 模式不然频繁要求确认。Kiro 支持 Skill 但不支持软连接需要完整复制 Skill 文件。Kiro 不支持手动压缩必须达到 80% 自动触发压缩Vibe 模式下压缩失忆严重估计是用小模型压的。Kiro 只有 Vibe 支持多会话Spec 不支持多会话会变成入队操作这会导致生产力陡然下降。所以 Kiro 一直不是我的主力开发工具但特别适合白天整理 spec、夜里 long running、早上到公司验收的模式。requirements、design、tasklist 在 Kiro 的实现中为了达到最优的效果每次都会 gather context这会导致流程很长。我自己实际测试下来发现一个比较顺手的 workflow 是requirement - 人类校准并提交 - design - 人类校准方案后 - 输入提示词生成 required task list 然后直接执行。IDE vs CLI 形态之争Claude Code如果说 Kiro 代表的是用流程约束 Agent的典型 AgentClaude Code 代表的则是另一个极端把缰绳完全交给模型。AI Coding 阶段论Steve Yegge 在他的 Gas Town 文章中提出了一个 AI Coding 编程的境界论阶段 1零 AI 或接近零 AI。偶尔用用代码补全有时候问问 Chat本质上还是自己写代码。阶段 2IDE 内 Agent需授权。侧边栏里多了一个 Agent但每一步操作都要你点允许你还不太信任它。阶段 3IDE 内 AgentYOLO 模式。信任度上来了你关掉了权限确认让 Agent 自己跑。阶段 4IDE 内Agent 全屏。Agent 逐渐占满了你的屏幕代码区缩成了一个 Diff 视图你已经几乎不直接写代码了。阶段 5CLI单 Agent。你离开了 IDE开始在终端里用 Claude Code 这类工具。Diff 飞速滚过你可能看也可能不看。阶段 6CLI多 Agent 并行。你日常同时开 3~5 个实例并行工作速度飞起。阶段 710 Agent手动管理。你开始同时管理十几个 Agent已经触及手动管理的极限。阶段 8构建自己的编排器。你站在了前沿开始构建自动化的 Agent 工作流编排系统。IDE vs CLI在我把工作方式从 Qoder 切换到 Claude Code 时最初我并没有感觉两者有什么大的能力差距使用相同模型仅讨论 Agent 能力Claude Code 开多窗口Qoder Quest 也支持并发多会话Claude Code 支持 vibe/plan 动态切换模型自主决策Qoder Quest 也同样支持Claude Code 让人更加关注任务而非文件变更对话流占据整个窗口保持心流Qoder Quest 的设计也是如此只不过是终端展示和 IDE 全屏展示的区别但为什么我依旧认为 CLI 形态相比 IDE 形态有优势呢需要大家切换一下角色把自己代入到 AI Coding 产品研发团队的视角而非使用者的视角来分析这个话题。Claude Code 是典型的 CLI 形态 AI 工具CLI 形态天然适合 Agent 的工作方式这不是功能多少的问题而是默认路径的问题。CLI 能实现的功能IDE 形态当然也可以实现但 IDE 形态交付相同能力往往要付出更高的产品代价。这构成了 Claude Code 的结构性竞争力。具体来说CLI 是一等公民。同一套 CLI Agent 能在你的本地终端跑也能扔到远程机上跑甚至塞进 CI 流水线里跑环境和能力是一致的。IDE 产品想补齐这条链路就得重新处理权限模型、会话管理、无头模式这些问题——不是做不到但每一步都是额外的产品工程量。端到端任务闭环是默认路径。Claude Code 跑一个完整的任务——读仓库、改代码、跑测试、看报错、再改——这就是它的主路径不需要额外配置打开就是这么用的。但你在 IDE 里想做同样的事就会发现这套读-改-跑-修的闭环和编辑器原有的交互范式是冲突的编辑器的心智模型是人在写代码AI 来辅助而不是AI 在干活人在旁边看。要把后者做好产品和界面都得大改。长时自治执行。Claude Code 可以一个任务跑几十分钟甚至几个小时失败了重试上下文断了续跑你去喝杯咖啡回来它还在干活。IDE 的前台交互场景下做这件事就很别扭——你的编辑器被占着你想手动改个别的文件都不方便更不用说会话中断和资源占用的问题了。人类和 Agent 的分工更清晰。在 Claude Code 的工作模式下人就是指挥官定目标、看结果、给反馈。Agent 负责全部执行。但在 IDE 模式下人始终是高频操作者——你还是要点按钮、确认 Diff、手动跑命令——很难真正从微操里抽身出来。所以差异不在有没有功能而在默认工作流是否以任务闭环为中心。Claude Code 的优势不在于功能更多而在于它把 AI 从编辑器里的能力点升级成了可被管理的执行系统。这件事 Cursor、Qoder 不是做不到而是要付出更高的产品重构和组织迁移成本。结果就是最前沿的 AI Coding 特性几乎都是在终端形态中率先涌现的——无论是 Claude Code 的自主工具调用、多文件编辑、Agent Teams还是后来各产品跟进的 Agent 模式源头都在 CLI。IDE 型产品往往是把这些能力翻译成图形界面后再交付给用户天然慢了一步。这也是我为什么一直使用 Qoder Quest 作为主力工具的原因。Quest 的架构选择代表了一种品味以 IDE 为皮以 Qoder CLI 为内核驱动。它不是一个加了 AI 功能的编辑器而是一个套了编辑器壳子的 Agent。产品的迭代重心在 Agent 内核而不是交互形态。这意味着 Qoder CLI 获得的每一项新能力Quest 用户都能第一时间享受到而不需要等 IDE 团队重新设计一套 UI 来承载它。当然并非所有场景都需要 Agent 全权接管——精细到一个函数、一段逻辑的修改Qoder Editor 模式的人机协同反而更高效你保持对代码的直接掌控AI 只在你需要的时候介入。两种模式在同一个 IDE 中共存让你不必在工具之间切换就能覆盖从微调一行代码到重构整个模块的全部场景。现在再把视角切回到 AI 工具使用者视角现在分别有两家厂商一家厂商提供 CLI 形态另一家提供 IDE 形态他们都可以使用相同的 SOTA 模型都拥有世界一流的工程师团队保持相同的投入你会觉得哪一个厂商能够提供给你更强的 AI 工具模型厂商做 Agent 的优势模型厂商亲自下场做 AI Coding 产品是当下最值得关注的趋势之一Claude Code 是这个趋势的典型代表。产品能力可以粗略拆解为一个公式产品能力 模型能力 × Agent 架构。以 Qoder CLI 为例它的 Agent 架构本身没有问题贴着 SOTA 模型去实现。但它永远需要等到模型厂商发布最新版本之后再去摸索新模型的特性和最佳实践。这注定了它比 Claude Code 至少落后 1~2 个月。Claude 模型在 Claude Code 面前是白盒——API 行为、能力边界、最佳提示策略产品团队和模型团队是同一拨人而在 Qoder CLI 面前Claude 是黑盒优化复杂度不可同日而语。这是所有非模型厂商做 Agent 的通用痛点。这个趋势还在加速。国外 Anthropic 做 Claude Code、OpenAI 做 Codex、Google 做 Gemini CLI国内阿里做 Qwen Code、月之暗面做 Kimi CLI——这些 CLI 本质上都是贴着自家模型去优化的形成模型能力与 Agent 架构的双飞轮模型更新直接反映在产品体验上产品反馈直接指导模型迭代。未来可预见的一种范式是模型厂商的 CLI 负责对接自家模型Skill/Plugin 解决行业 Know-How 问题用户接入仅需一层薄薄的适配层。Agent 不再需要从零构建而是组合即用。开发者视角Claude Code 的日常优势Anthropic 的工程理念在行业中有一种定义标准的能力。MCP、Skill 现在已经成了工具扩展的事实标准CLAUDE.md 的思路被所有产品抄了一遍各家换了个名字叫.cursorrules、Steering、AGENTS.mdHooks 机制也在被陆续跟进。这种理念上的先进性反映到 Claude Code 这个产品里意味着一件事你几乎总能在 Claude Code 中率先体验到 AI 开发的最新范式。别的产品还在跟进上一个特性的时候Claude Code 已经在玩下一个了。对于想站在前沿的开发者来说这本身就是选择 Claude Code 的理由。不过公允地说Qoder 在跟进这些范式上是最积极的——MCP、Hooks、Rules、Skill、Agent Teams 这些能力 Qoder 都已经支持而且因为 Qoder CLI 本身的架构灵活性跟进速度在第三方产品中算是最快的一梯队。如果你不想被 Claude 生态锁定Qoder 是目前兼容性和前沿性平衡得最好的选择。另一个很难被复制的优势是 Claude Code 和 Opus 模型之间的配合。Opus 4.6 拥有极佳的代码理解和推理能力以及在同级模型中最强的自主性——它敢做决策、敢连续执行、敢在遇到问题时自己调整方案而不是停下来问你。但这种自主性是一把双刃剑边界情况处理不好就会跑飞。Claude Code 是最理解 Opus 秉性的产品——哪些场景该放手让它跑哪些场景该收紧约束什么时候该触发 compact上下文快溢出时怎么优雅降级——这些细节只有模型厂商自己的产品才能做到极致。Opus 4.6 在第三方产品里也能用但只有搭配 Claude Code 才能把它的实力完全发挥出来。还处于实验阶段的 Agent Teams 则代表了 Claude Code 在多 Agent 协作上的探索。它不是传统的 subagent 模式——不是一个主 Agent 派任务给子 Agent 然后收集结果Qoder Quest 和 Experts 都是在使用 subagent 来实现 Agent Teams而是多个独立的 Agent 进程之间通过 mailbox 机制进行点对点通信每个 Agent 都是平等的 peer。这意味着 Agent 之间可以直接协商、分工、同步进度而不需要经过一个中心调度器。这和我之前在 Gas Town 那篇文章里看到的 Steve Yegge 用 Beads 搭建的邮件通信系统思路不谋而合——行业正在从单 Agent 干活走向多 Agent 协作而 Claude Code 又一次走在了前面。Claude Code 的现实门槛说了这么多优势也得聊聊现实。Claude Code 对于一般人来说最大的痛点是必须接入 Claude Max 订阅才能发挥出最大的能力如果不通过 ssh 使用各种梯子而我作为那个一般用户一直都是在用各种其他用法包括但不限于接入阿里云百炼 Coding Plan个人感受 GLM-5 还行但肯定达不到 Opus 4.6 的可信任度在自主性和代码理解深度上表现仍然不及预期可用作非主力开发场景或者 Opus Plan GLM-5 Build 的路线。各种形式的 2api 反代方案Harness Engineering 与我的实践聊完产品回到一个更本质的问题怎么让 AI 帮你写出靠谱的代码Kiro 的回答是用流程约束——三阶段 Spec每一步都有人类审查不确认就不往下走。Claude Code 的回答是把缰绳交给模型——你说清楚要什么剩下的它自己搞定。两种思路看起来对立但用下来会发现它们各自解决了问题的一半Kiro 解决了做什么和怎么做的对齐问题Claude Code 解决了高效执行的问题。但两者都没有完整回答一个更本质的问题AI 写完代码之后你怎么知道它写对了什么是 HarnessHarness Engineering 四大实践今年年初 OpenAI 发了一篇文章讲他们用 Codex GPT-5 从零构建了一个百万行代码的产品全程没有一行人工代码。他们给这套方法论起了个名字叫Harness Engineering——人类不再写代码而是设计环境、明确意图、构建反馈回路让 Agent 在这套体系中可靠地工作。Harness 通常翻译为驾驭者工程负责连接和编排各个组件但不直接下场干活。说实话这不是什么新发明。任何认真做 AI Coding 的人用上几个月都会自己摸到类似的路上。但 OpenAI 的贡献在于给了它一个名字、一套叙事以及一个百万行代码的案例佐证。剥掉包装来看他们做了这几件事Map, not Manual地图而非手册。AGENTS.md 应该是大约 100 行的导航地图告诉 Agent去哪里找什么详细内容放在链接的文档里。塞太多信息反而适得其反一切都重要的时候一切都不重要。Anthropic 官方博客中也有相同的论述不仅 Skill 应当采取渐进式披露CLAUDE.md 也应当存放引用而非手册全文。嵌入而非外挂。架构规范、编码约定、常见坑点放在代码仓库的docs/和scripts/里不放 Notion、不放 Confluence。Agent 看不到的东西对它来说就不存在。存在 Slack 讨论里的技术决策、记在人脑子里的架构判断——如果不写进仓库Agent 就像一个迟到三个月的新员工对这些一无所知。机械验证而非人工检查。代码规范写到 rules 里可能表达不清Agent 也未必自觉遵守但变成 lint 规则跑在验证阶段就能明确阻塞。OpenAI 更进一步把 Chrome DevTools Protocol 接入 Agent 运行时让 Agent 能自己打开应用、操作 UI、截屏对比把日志和 Metrics 暴露给 Agent让它直接用 LogQL 和 PromQL 定位性能问题。验证不仅仅是测试通过而是 Agent 能直接观察产品行为。迭代自愈而非等待评审。改完代码自动跑验证失败了自动分析修复1~3 轮收敛反复失败才升级给人类。不阻塞在 Pull Request 上等人来看。这在传统开发流程里是不负责任的但 Agentic 时代逻辑反过来了——Agent 吞吐量高、纠错成本低反而是等待变得昂贵。他们甚至还搭建了垃圾回收机制后台 Agent 定期扫描代码库发现偏离团队规范的模式就自动开 PR 修复像持续偿还小额技术债而不是等它累积成大山。Big Model vs Big HarnessHarness Engineering 的文章发布后引发了行业讨论。一边是 Claude Code 的主创 Boris Cherny他在播客里几乎是在炫耀 Claude Code 有多薄“所有秘方都在模型里我们的框架是技术上能构建的最精简的东西。我们大约每三到四周就从头重写一次 Claude Code。” OpenAI 研究员 Noam Brown 更激进直接说很多 Agent 脚手架最终都会被更强的模型替代——没错同一家公司的员工也不见得有相同的认知。AI 安全评测机构 METR 的测试也站在这边Claude Code 和 Codex 并没有显著超越最基本的脚手架。AI 数据公司 Scale AI 旗下的 SWE-Atlas 基准测试数据更狠——框架选择带来的性能差异基本就是噪音。另一边是框架厂商们。LlamaIndex 创始人 Jerry Liu 说从 AI 获得价值的最大障碍是你自己对模型进行上下文和工作流工程的能力AI 工程社区 Latent Space 展示了仅靠改进框架就让 15 个模型编码能力全面提升的结果。说白了模型厂商强调模型能力框架厂商强调工程实践。这和当年要不要用 ORM、要不要上微服务的争论没什么本质区别——利益相关方各执一词真相在中间。但这场争论让我想到一个问题前面我说 Claude Code 最强的时候我到底在夸模型还是在夸产品诚实讲大概率是在夸模型。如果把 Claude Code 的壳套在一个弱模型上体验会断崖式下跌反过来把 Opus 4.6 塞进任何一个还过得去的框架里体验都不会太差这本身就说明了模型能力的重要性。我的实践抛开争论回到自己的项目里。Harness Engineering 的那几条原则我不仅认可而且已经在用了——只不过形式不同、深度不同。我自己的 AGENTS.md 就是按 Map not Manual 写的——项目结构、构建命令、验证脚本的入口写清楚具体的架构文档通过链接指向docs/目录编码规范写到 Qoder Rules。知识全部嵌入仓库不依赖任何外部文档平台。验证闭环是我实践中感触最深的一环也是 Qoder 的工具链发挥最大价值的地方。在 HiMarket AI 开放平台项目https://github.com/higress-group/himarket中把验证脚本串进 Agent 的工作流——lint、spotless check、maven build 在每次代码变更后自动触发不需要在 Prompt 里反复提醒 Agent记得跑测试。验证不止于编译通过我还要求 Agent 通过start.sh把应用真正启动起来用 curl 和 websocat 跑接口验证确保新增功能可用。在调试极端前端缺陷时使用 Qoder 的 Agent Browser 自行操作浏览器获取完善上下文来定位疑难杂症。这是 Qoder 一个优势——它能让 Agent 看到页面上发生了什么而不只是读日志猜问题。在 spec 的 design 文档里我也会写入验证方案告诉 Agent写完代码不算完自测过功能才算完并给出 Verification 方案。为此我还要提供配套的基础设施数据库、K8s 环境信息、沙箱信息等运行环境配置——光告诉 Agent要验证是不够的你得让它能验证。有了这套端到端的验证Agent 的产出从代码能编译提升到了功能能跑通夜间执行的验收质量完全不同。回过头看Qoder 的 AGENTS.md Rules Skill Spec Agent Browser 这套组合思路和 Harness Engineering 所说的设计环境、构建反馈回路 类似Qoder 的产品设计天然适配这套工作方式。当然我的实践和 OpenAI 的完整方案之间还有差距我还没有对接 Metrics 和 Trace 让 Agent 直接定位性能问题没有做到 7×24 无人值守也没有实现垃圾回收式的代码库自动清理。但这些已经进入了我未来的尝试清单Harness Engineering 告诉了我可以这么做。所以我对 Harness Engineering 的态度是认同实践警惕教条。模型能力是地基Harness 是上层建筑。那四条实践——地图式导航、知识嵌入仓库、机械化验证、迭代自愈——是任何 AI Coding 工作流都绑定的基础设施和你站哪个派无关。但 Harness 的投入产出比是递减的最初的 AGENTS.md 加验证闭环能带来巨大的质量提升从80 分到95 分需要的工程量可能是前面的十倍。把精力花在写好 Spec 和跑通验证闭环上剩下的信任模型——这大概是一个 Big Model 偏好者能接受的最大限度的 Harness 了。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】