AI Coding 工具的讨论很容易滑向品牌比较：哪个补全更快，哪个模型更强，哪个界面更顺手，哪个 Agent 更会自己修错。

这种比较有用，但不够。真正影响团队落地效果的不是单个工具的功能清单，而是三个更底层的问题：产品形态默认鼓励什么工作流，任务方法论如何控制风险，Harness 能不能把验证、状态、权限和恢复托住。

把这三层拆开后，AI Coding 工具的差异会清楚很多。IDE、CLI、Spec 工作流、云端 Agent 并不是互相替代的银弹，它们只是把人的注意力放在不同位置。

先看产品形态，不先看品牌

AI Coding 工具大致可以抽象成四类形态。

形态 默认入口 强项 代价
IDE 辅助型 当前文件、光标、选区 低摩擦、适合局部修改 容易停留在补全和问答
CLI Agent 型 任务描述、仓库、命令行 端到端闭环、天然适合自动验证 需要更强的权限和环境治理
Spec-first 型 需求、设计、任务清单 适合 Feature 级需求和长任务 小修小补显得偏重
混合型 IDE 协同加 Agent 执行 能在编辑体验和任务闭环之间切换 产品边界复杂，容易两头都重

IDE 的优势是贴近代码现场。开发者正在看哪个文件，模型就能看到哪个文件；选中一段代码，模型就能局部解释、重构、补测试。它的摩擦最低，所以适合高频小任务。

CLI Agent 的优势是任务闭环。它天然可以读仓库、改文件、跑命令、看失败、再修改。只要权限、沙箱和验证设计得足够稳，CLI 更容易把“帮忙写一点”推进到“替人跑完一轮任务”。

Spec-first 工具把意图锁定放在编码之前。需求、设计、任务拆解先被显式化，Agent 执行时不再只依赖一句模糊指令。它适合中大型 Feature，也适合需要离线长跑的任务。代价是仪式感更重，不适合每个小问题都走完整流程。

混合型工具试图同时保留编辑器里的即时协同和 Agent 的长任务能力。这个方向很自然，但产品设计难度也更高：如果 IDE 侧太重，Agent 会变成高级补全；如果 Agent 侧太重，编辑器协同会变成附属入口。

CLI 和 IDE 的差异是默认工作流

CLI 与 IDE 的争论不该停在“界面不同”。真正的差异是默认工作流。

IDE 默认围绕当前编辑动作组织。它关心当前文件、当前符号、当前错误、当前 diff。这个局部性非常适合日常开发，但也容易让 Agent 被限制在“看见哪里改哪里”的模式里。

CLI 默认围绕任务闭环组织。输入通常是一段任务描述，输出可以是一组文件修改、验证日志和报告。它不天然绑定某个打开的编辑器状态，因此更适合端到端执行、长时间自治、多 Agent 并行和自动化验证。

小范围修复、解释代码、补一个测试，IDE 更顺手。跨模块改造、批量修复、夜间运行、自动回归，CLI 或云端 Agent 更自然。

工程判断应该落在任务形状上，而不是工具信仰上。

Vibe、Plan、Spec 是风险分级

AI Coding 的方法论可以简单分成三档。

方法 适合任务 控制点
Vibe 小修小补、低风险探索 短指令交给 Agent，完成后快速看 diff
Plan 中等复杂度修改 先产出方案，人审一次，再执行
Spec Feature 级需求、跨模块改造 需求、设计、任务拆解分别审查

Vibe 的价值是低摩擦。它适合那些失败成本低、上下文简单、容易通过测试发现问题的任务。比如改一个命名、补一个边界条件、解释一个函数、生成一段临时代码。

Plan 多了一次校准。Agent 先描述理解、拆解步骤、列出会改哪些文件和如何验证。人只需要在执行前审一次方向，就能挡住大部分“理解错任务”的失败。

Spec 把控制点继续前移。需求阶段确认“做什么”，设计阶段确认“怎么做”，任务阶段确认“按什么顺序做”。它不一定最快，但适合那些一旦做偏就很难回滚的需求。

这三档不是成熟度阶梯，而是风险分级。小任务走 Spec 会拖慢节奏，大任务只走 Vibe 会把风险藏到最后。

Harness Engineering 的四条基本功

模型能力是地基，Harness 决定这块地基能承多重的楼。

一个实用的 AI Coding Harness，至少要做四件事。

实践 核心做法 解决的问题
地图式导航 用仓库内的指导文件描述目录、命令、边界和惯例 Agent 不必靠猜来理解项目
知识嵌入仓库 把规范、坑点、脚本和案例放进 repo 经验不散落在聊天记录和外部文档里
机械化验证 lint、typecheck、build、test、smoke check 自动阻塞 质量不靠人工记忆兜底
迭代自愈 失败后自动读错误、修复、重跑，连续失败再升级 把常见失败留在自动循环里

地图式导航不应该写成百科全书。太长的指导文件会污染上下文，也会让关键规则被稀释。更好的结构是：顶层文件像地图，只放目录、入口、禁区和常用命令；详细规则放到 docs、scripts 或专题文档里，让 Agent 按需读取。

知识嵌入仓库的重点是可执行性。团队常犯的坑点、部署前检查、测试数据生成、接口契约、迁移流程，如果只存在外部文档里，Agent 很难稳定找到。放进 repo 后，它们才会跟代码一起演化，也能被 CI 和脚本引用。

机械化验证是最便宜的质量杠杆。只要一个错误能被脚本稳定发现，就不应该留给人工审查。人工审查应该集中处理意图、架构、业务语义和风险，而不是反复指出格式错误、编译错误和明显的测试失败。

迭代自愈让 Agent 从“生成一次答案”变成“跑一个闭环”。改完、验证、读错误、再改，这是 Agent 真正开始替代一部分工程劳动的位置。连续多轮失败时再升级给人，既保留效率，也避免无限循环。

Big Model 和 Big Harness 都不够

AI Coding 里有两个容易极端化的判断。

一种判断认为，所有关键能力都在模型里。模型足够强，框架、提示词、工作流都只是薄壳。

另一种判断认为，模型只是可替换部件，真正壁垒在 Harness、Workflow 和平台。

实际落地更像中间状态。弱模型放进再强的 Harness，也会在理解、规划和代码质量上拖后腿。强模型放进松散的 Harness，也会被权限、状态、验证和上下文管理问题拖垮。

模型决定下限，Harness 决定上限。

模型越强，越会暴露 Harness 的不足。一个只能补全几行代码的模型，不太需要复杂的沙箱、回滚和审计；一个可以连续运行几十分钟、跨多个文件修改、自动调用工具的 Agent，就必须被 Harness 严格托住。

投入产出比不是线性的

AI Coding 工程化有明显的边际收益递减。

第一阶段的收益通常很高：写清楚项目入口、补齐常用命令、建立最小验证、把禁区和注意事项写进仓库。很多团队只要做到这些，Agent 的可用性就会显著提高。

第二阶段开始进入体系化：任务模板、Spec 流程、自动测试矩阵、审查规则、trace、失败归因、权限策略、沙箱隔离。这一阶段适合高频使用 Agent 的团队。

第三阶段是平台化：Cloud Agents、统一任务队列、会话持久化、组织级 Skill、集中审计、跨项目复用、自动评测和回归。它的投入更大，收益也更依赖规模。

不是每个团队都需要一开始就做第三阶段。更稳的路径是从最便宜的验证闭环开始，把 Agent 产出的坏结果先挡住，再逐步把经验沉淀成 Harness 能力。

工具选择可以变成决策表

工具选择不需要变成信仰问题。按任务风险和任务形状拆开，判断会简单很多。

场景 更适合的形态 原因
单文件小改动 IDE 辅助型或 Vibe 低摩擦比流程控制重要
中等范围重构 CLI Agent 加 Plan 需要任务闭环，也需要执行前校准
Feature 级需求 Spec-first 或 Plan -> CLI 需求和设计偏差要尽早发现
夜间长跑任务 Cloud Agent 或强 Harness CLI 需要状态、恢复、验证和产物回收
多 Agent 并行探索 CLI/Cloud 加结构化汇总 重点是合流、裁判和去重
高风险生产操作 建议位 Agent Agent 产出候选，人执行关键动作

这个表背后的原则很简单：任务越小，越应该降低流程摩擦；任务越大，越应该提前显式化意图；风险越高，越应该加强验证和权限边界。

开发者价值迁移到意图和质量

AI Coding 让代码从目的变成媒介。

过去的主要劳动是把意图翻译成代码。现在越来越多代码可以由 Agent 生成，人的价值就迁移到更上游和更下游：上游是定义意图、压缩上下文、选择任务边界；下游是验证质量、判断风险、决定是否进入主干。

这并不意味着代码能力不重要。恰恰相反，越懂代码，越能写出好验收标准，越能看出 Agent 生成结果里的微妙问题，也越能判断哪些工作应该自动化、哪些工作必须保留人工门禁。

AI Coding 工具如果只停在“更快写代码”，上限并不高。更有价值的方向，是让工程系统持续产生候选方案，并且有能力把坏候选挡在主干之外。

模式速查表

关键词 对应模式 判断
小改动、低风险 Vibe 快速生成，快速看 diff
中等任务、不想跑偏 Plan 执行前加一次方案审查
Feature、跨模块 Spec 需求、设计、任务拆分分别锁定
长任务、离线执行 Harness 状态、沙箱、验证和回收先建好
多工具选择 任务形状优先 不按品牌选，按风险和闭环选
团队规模化 知识进仓库 规则、坑点、脚本和验证跟代码一起演化

AI Coding 工具真正要比较的，不是哪个按钮更漂亮，也不是哪个 Agent 更像真人。关键是它能否把意图锁住，把执行托住，把错误挡住，把结果送到可以判断的位置。