AI Coding 的范式演进：Qoder、Kiro、Claude Code 与 Harness Engineering

前言

这是我”AI Coding 经验总结”系列的第四篇文章，距离上一次分享《Qoder Quest 1.0：把执行交给 AI，把选择留给人类》正好又过去了 2 个月，我对 AI Coding 的认知又进行了一次刷新。

这两个月内，Qoder Quest 依旧是我日常开发的主力，但为了避免自己的认知被单一产品绑定，我也强迫自己试用了很多其他产品：Kiro、Claude Code、Codex 等。这些产品并不是工作在同一维度，我甚至会同时使用它们，本文我也会基于个人使用体验来分析一下。本文所有的对比和评价，都是以 Qoder（Quest + CLI）作为基准参照——它是我最熟悉的工具，也是我衡量其他产品时的默认坐标系。

AI 工具概述

先按照产品的交互形态，把我所接触的 AI 工具分为几类：

• 基于 VS Code 为界面的 IDE 型产品：Qoder、Kiro、Cursor、Trae、Windsurf
• 非 VS Code 的原生 IDE 型产品：Zed、JetBrains（Qoder 插件），和上边同属 IDE 型产品
• 独立 APP：Claude 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 的对接，从实际产品体验出发做更具体的分析。

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，采用 EARS（Easy Approach to Requirements Syntax）标记法，把需求拆解为结构化的验收条件，格式类似 “WHEN [某个条件] THE SYSTEM SHALL [预期行为]”。这一步的目的是把模糊的想法变成可测试、可追踪的需求条目。

第二阶段：Design。基于 Requirements，Kiro 生成 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 truth，Spec 才是。新的需求要先改 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 Spec vs Qoder Quest Spec

我经常跟以十眠为代表的 Qoder 团队研发吐槽：你们 Quest 里面的 Spec 就是一个 Plan。当然每个产品都有自己命名的权利。

但这句吐槽背后其实藏着一个有意思的观察：当前主流的 AI Coding 工作流，按”人机交互的轮次”来看，可以分为三个阶段（或者说三代）：

三种模式的本质差异在于：人在 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，中等任务用 Plan，Feature 级别的工作上 Spec。

Kiro Spec 和 Qoder Quest Spec 的对比绝对不能沦为谁做的更重谁就更优秀的对比，适合自己的才是最好的。但有一点还是要夸一下 Qoder Quest，它将 Vibe 模式和 Spec 模式做了结合，由模型根据任务复杂度动态决策，可以实现在同一 Quest 任务中多次的切换，这相比 Kiro 的 Spec Workflow 更加 Agentic。然而 Qoder Quest 却并没有支持三阶段的 Spec，对于 Feature 级别和 long running 的需求支持还有待完善。值得一提的是，Qoder CLI 已经支持了三阶段的 spec（quest-on 模式），只不过 IDE 中尚未上线。

Kiro 注意事项

其他趋同的能力我就不介绍了，希望体验 Kiro 的用户可以自己查看官方文档。这一点也得夸一下 Kiro，官方文档不仅仅是一个操作手册，也是一个 Kiro AI Coding 实践指南，有非常明确的方向性和实践指导价值。从文档中也可以发现 Kiro 是一个敢于下判断并坚守的产品，这一点让使用者非常舒服。

1. 配置 YOLO 模式，不然频繁要求确认。

2. Kiro 支持 Skill 但不支持软连接，需要完整复制 Skill 文件。

3. Kiro 不支持手动压缩，必须达到 80% 自动触发压缩，Vibe 模式下压缩失忆严重，估计是用小模型压的。

4. Kiro 只有 Vibe 支持多会话，Spec 不支持多会话，会变成入队操作，这会导致生产力陡然下降。所以 Kiro 一直不是我的主力开发工具，但特别适合白天整理 spec、夜里 long running、早上到公司验收的模式。

5. requirements、design、tasklist 在 Kiro 的实现中为了达到最优的效果，每次都会 gather context，这会导致流程很长。我自己实际测试下来发现一个比较顺手的 workflow 是：requirement -> 人类校准并提交 -> design -> 人类校准方案后 -> 输入提示词：生成 required task list 然后直接执行。

Claude Code

如果说 Kiro 代表的是”用流程约束 Agent”的典型 Agent，Claude Code 代表的则是另一个极端：把缰绳完全交给模型。

Steve Yegge 在他的 Gas Town 文章中提出了一个 AI Coding 编程的境界论：

• 阶段 1：零 AI 或接近零 AI。偶尔用用代码补全，有时候问问 Chat，本质上还是自己写代码。
• 阶段 2：IDE 内 Agent，需授权。侧边栏里多了一个 Agent，但每一步操作都要你点”允许”，你还不太信任它。
• 阶段 3：IDE 内 Agent，YOLO 模式。信任度上来了，你关掉了权限确认，让 Agent 自己跑。
• 阶段 4：IDE 内，Agent 全屏。Agent 逐渐占满了你的屏幕，代码区缩成了一个 Diff 视图，你已经几乎不直接写代码了。
• 阶段 5：CLI，单 Agent。你离开了 IDE，开始在终端里用 Claude Code 这类工具。Diff 飞速滚过，你可能看，也可能不看。
• 阶段 6：CLI，多 Agent 并行。你日常同时开 3~5 个实例并行工作，速度飞起。
• 阶段 7：10+ 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.md），Hooks 机制也在被陆续跟进。这种理念上的先进性反映到 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 使用，各种梯子，而我作为那个一般用户，一直都是在用各种其他用法，包括但不限于：

1. 接入阿里云百炼 Coding Plan，个人感受 GLM-5 还行，但肯定达不到 Opus 4.6 的可信任度，在自主性和代码理解深度上表现仍然不及预期，可用作非主力开发场景，或者 Opus Plan + GLM-5 Build 的路线。
2. 各种形式的 2api 反代方案

Harness Engineering 与我的实践

聊完产品，回到一个更本质的问题：怎么让 AI 帮你写出靠谱的代码？

Kiro 的回答是用流程约束——三阶段 Spec，每一步都有人类审查，不确认就不往下走。Claude Code 的回答是把缰绳交给模型——你说清楚要什么，剩下的它自己搞定。两种思路看起来对立，但用下来会发现，它们各自解决了问题的一半：Kiro 解决了”做什么”和”怎么做”的对齐问题，Claude Code 解决了”高效执行”的问题。但两者都没有完整回答一个更本质的问题：AI 写完代码之后，你怎么知道它写对了？

什么是 Harness

今年年初 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 Harness

Harness 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 开放平台项目中：

• 把验证脚本串进 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 了。

品味的延续

上一篇文章我说”品味来源于经验、来源于对业务的理解、来源于你踩过的坑”。两个月后我想补充一点：品味不只是”选择做什么”，还包括”选择用什么方式做”。

选择 Vibe Coding、Plan Mode 还是 Spec 驱动，选择信任模型的自主性还是先搭好验证闭环，选择追求速度还是追求可控——这些都是品味的体现。在这篇文章里，我分析了 Qoder、Kiro 和 Claude Code，讨论了 Harness Engineering 的价值和争议，但最终落回来的结论其实很朴素：没有一种范式是银弹，关键是你在什么场景下选择什么分寸。

小修小补用 Vibe，中等任务用 Plan，Feature 级别上 Spec。验证闭环一定要有，但不必追求全链路自动化。模型能力是地基，工程实践是杠杆——地基不牢的时候多搭脚手架，地基够强的时候学会放手。

代码正在从”目的”变成”媒介”。开发者的核心价值在于定义意图和审核质量，而非编写代码本身。

AI Coding 认知升级还在继续，我在路上，也想听听你的故事，欢迎加入微信交流群交流。