从 AI 的使用者到 AI 的驾驭者
AI 编程正在从 Vibe Coding 向 Agentic Coding 范式转移，人类的价值从“写代码”变为“判断正确性”
2026 年，硅谷最值钱的技能不是写代码。
是判断该信哪个 AI。
CTO 卸任加入 AI 实验室亲自写代码，CEO 把桌子搬到程序员旁边——你以为他们是在追技术潮流。
实际上，他们在做同一件事：重新校准自己和 AI 之间的信任边界。
这不是关于 AI 替代人类的叙事，而是：当 AI 接管执行，谁来定义“对”？当代码可以无限量产，工程师的价值重新定在了验证环节，而验证这件事，从来都需要人站在 AI 的上游，而不是下游。
未来不是“更少人写代码”，而是“更多人做判断”。
Vibe Coding 的本质很简单：AI 生成代码，人消费结果。你描述需求，AI 交付产品。代码怎么出来的，你不用管。
但这套范式有天花板。
当结果涉及复杂的工程约束：API 级联、边界条件、数据一致性、依赖版本。AI 生成的东西往往“看起来对”，跑起来不是那么回事。更要命的是：你不知道怎么验证它真的对了。
Agentic Coding 是另一种思路。AI 是执行者，不是代笔者。人在驾驶座上，持续验证工程正确性。
换了个工具，也是换了套心智模型。而这套心智模型，有一套可量化的能力等级。
本白皮书分三部分：
- 第一部分建立核心概念框架，讲述从 Vibe 到 Agentic 的心智转变；
- 第二部分是 L1-L20 能力等级体系，让这套心智模型可衡量、可修炼；
- 第三部分提供实战工具箱：反模式、工具选型、成长路径。
两件事同时发生，不是巧合。
六位来自十亿美元级公司的 CTO，放弃高管职位，加入 Anthropic，从管人变成被人管——从 CTO 变成 IC（个人贡献者）。
扎克伯格时隔 20 年重新坐在了编程台前，亲自盯着 AI 编程进度。Meta 内部设定了一个目标：2026 年上半年，Creation 组织预计 65% 的工程师将使用 AI 编写超过 75% 的承诺代码；另一个组织的目标则是 50% 至 80%。
表面看是两个独立事件，实际是同一结构正在显形。
传统等式：
影响力 = 管理半径
管的人越多，影响力越大。
这个等式正在失效。CTO 工作中 50% 的精力花在“人”上：处理公司政治、偿还技术债、维护老系统。影响力在层层管理中被不断稀释。
而在前沿实验室里，MTS（Member of Technical Staff）直接参与核心模型训练，与顶级研究者同圈共事，股权激励的增值空间可能超过大多数独角兽 CTO 一辈子的收入。
「如果通用人工智能在 2027 年或 2028 年到来，我将置身前沿实验室，坐在前排观看。如果不会发生，我也会明白为什么会这样。」
推力：管理层在稀释影响力。
拉力：直接参与最前沿模型训练，用 AI 工具把产出放大上万倍。一个顶级工程师 + 一个强模型，可以干掉过去一个百人团队的工作。
CEO 为什么重新写代码？不是因为想重拾手艺，是因为想亲自看清楚：AI 替代工程师这件事，到底是怎么发生的。
一个技术领导者，一旦停止亲手触碰技术细节，就失去了判断 AI 输出质量的基准。你不知道 AI 写的东西到底对不对，好不好，有什么边界。
Meta 给团队定了一个目标：2026 年中，65% 到 80% 的代码由 AI 编写。一个 CEO，跑回去盯着这件事。背后的逻辑不是“支持 AI”，而是他需要亲自校准自己和 AI 之间的分工边界。
| 旧等式 | 新等式 |
|---|---|
| 影响力 = 管理半径 | 影响力 = 判断力 |
| 晋升 = 脱离一线 | 晋升 = 能交付什么 |
| 中层 = 协调者 | 中层 = 被优化者 |
| 执行层 = 核心价值 | 执行层 = 基础设施 |
YC 的研究指出了一个令人不安的结论：中层这帮人本质就是老板的人肉带宽。AI 把这事自己干了以后，这一层就显得多余了。
未来公司可能只剩两种人：真正干不可替代性工作的人，和在上面做判断且能负责的人。
以前你定个大方向，中层会替你掰扯出八条具体路径。以后 AI 给你的全是决策点，一个个等你拍板。
黄仁勋在 2026 年提了一个数字：750 万个智能体，7.5 万个人。每 1 个人背后，对应 100 个 AI 工人。智能体会做大多数工作。人的角色变成监督和决策。
真正在发生的，不是 AI 替代写代码本身。AI 替代的是「执行层」：把产品经理、设计师给出的设计意图，翻译成机器能跑通的代码。而问题在于：谁来判断哪个问题值得被解决？这个问题，从来都留给人类。
Vibe Coding 解决的是创作问题。创作的特点是：你知道你要什么，结果好不好，你能感知到。
但工程不一样。工程结果的对错，不来自直觉，而来自客观的验证机制。
比如：
- 一个 SQL 查询“说得通”，但数据量大了可能 OOM。
- 一段登录逻辑“看起来对”，但并发情况下 token 刷新可能有竞态。
- 一个第三方 API 集成“能用”，但没处理 rate limit 和错误重试。
这些不是 AI 的问题，是工程本身的问题。AI 替你写代码，你承担了工程的全部责任，却放弃了工程的过程。
Vibe Coding 的陷阱不是 AI 质量差，而是：你不知道结果对不对。
数据警示：研究表明，AI 生成代码的安全问题值得关注。Cloudsmith 报告显示 42% 的代码由 AI 生成，45% 包含危险缺陷。OWASP 的建议是：把 AI 输出视为来自未验证第三方的代码。
你可能觉得这是在抠字眼。但实际上，词汇的选择会影响三件事：
-
企业采购的认知
“vibe coding”听起来是非正式的、随意的、适合个人开发者的。但进企业采购清单的东西不能是“感觉对了就行”。它需要有明确定义、有可验证的质量标准、有工程团队能理解的术语。
-
竞争格局的框架
当一个品类词汇被某家公司主导定义，这家公司就掌握了这个品类的叙事权。Google 能用“Gemini”而非“ChatGPT 竞品”进入讨论，已经是一种胜利。
-
开发者的自我认同
工程师用什么词描述自己的工作，影响他们觉得自己在做什么。“我在做 vibe coding”和“我在做 agentic engineering”，这两种自我认知会带来不同的行为模式。前者更随意，后者更严谨。
最近，Claude Code 的负责人 Boris Cherny 公开表示，他想换掉“vibe coding”这个词。原因是他不想让竞争对手定义的词，来框住自己的产品。
讽刺的是，Cherny 向 Anthropic 的 Claude 聊天机器人征询创意，机器人给出的建议是“Agentic Engineering”，但这个词也是 Karpathy 在 2026 年初提出的。
两大阵营的博弈：
- Karpathy 定义了“vibe coding”，让 OpenAI 系占了上风；
- Anthropic 想用“agentic”或类似词汇，重新掌握叙事主导权；
- 连 Cherny 的“替代方案”也是 Karpathy 的词。
在 Agentic Coding 里，你是司机，不是乘客。
乘客只需要说“我要去哪”，司机需要看路、看仪表盘、处理意外。
工程师的核心能力不是写代码，是判断正确性。
判断正确性意味着：
- 我知道什么叫“对”——明确的验收标准；
- 我知道怎么验证“对”——可执行的检查手段；
- 我知道什么情况下会“错”——对边界的预判。
当 AI 执行任务，你做的不是等最终结果，而是持续验证过程的正确性。
这不是更累，这是更有效。放弃控制输出，专注于控制过程。这是从 Vibe 到 Agentic 最重要的心智切换。
Vibe Coding 的模式是：说需求，等结果，不满意就改。
错误的发现成本与发现时间正相关。在 AI 生成完整个系统之后才发现问题，修复成本可能是最初的 10 倍。每个模块完成时及时验证，成本可控，方向可控。
分段确认包含三个维度：
- 功能验证：它真的做了你要的吗？
- 边界验证：它遇到意外情况会怎样？
- 依赖验证：它用到的东西，它自己清楚吗？
错误不是失败。错误是系统给你的反馈，告诉你某个假设不成立。把错误当信息源，不当失败原因：这是工程师的基本素养。
创意任务可以一句话：“帮我做一个好看的仪表盘。”
工程任务不行。工程任务需要定义执行边界。
执行边界包含：
- 输入：AI 用的数据从哪来，格式是什么；
- 输出：最终交付物是什么，怎么就算“完成”了；
- 约束：性能要求、兼容性要求、异常处理要求；
- 自主区：AI 可以自己决定什么；
- 上报区：AI 必须停下来等确认的是什么。
Vibe Coding 的指令是文学化的：“优雅”“美观”“流畅”。
Agentic Coding 的指令是工程化的：“当 X 发生时，AI 做 Y；如果 Y 失败，AI 停止并上报。”
这种精确化不是限制 AI，是给 AI 一个可执行的工作域。模糊的指令产生模糊的结果。精确的边界产生可验证的过程。
Dario Amodei 说过：
Coding is becoming a commodity; Systems Thinking is the new monopoly.
执行越来越便宜，判断越来越贵。判断力 = 遇到问题 → 识别类型 → 调用框架 → 做出决策。
这不是 AI 可替代的能力，因为判断力涉及的是：对问题本质的理解、什么情况下 AI 该闭嘴、什么时候该推倒重来。
YC 框架将人类判断保留在四个位置：
- AI 闭嘴位置（知道何时不该用 AI）；
- 判断保留位置（AI 辅助但人类决策）；
- 关系构建位置（人际信任和领导力）；
- 创新定义位置（什么值得追求）。
Vibe Coding 的信任是感性的：看起来对就用。
Agentic Coding 的信任是有条件的：满足了一组可验证的标准，才算信任。
- 重复结果：同一个任务跑三遍，结果一样，才能信。
- 依赖透明：AI 用了哪些外部服务、版本、配置，它自己说清楚。
- 边界已知：在什么情况下系统会失败，失败后行为是什么。
- 可重建：当系统建立在不透明的依赖之上，当错误开始累积，当验证成本超过重建成本——推倒重来不是失败，是止损。
从“能跑通”到“能信任”，需要一组验证机制。不是一次性的，是每次都跑、每次都看的。
从“能跑通”到“能信任”，需要一套可迭代的系统架构。这套架构分三层：
| 层级 | 名称 | 核心功能 | 对应等级 |
|---|---|---|---|
| C1 | Context Engineering（解构自己） | 告诉 AI 你是谁、你要什么、什么算“对” | L1-L5 |
| C2 | Custom Skills（封装能力） | 把工作流写成可执行的“技能手册” | L6-L9 |
| C3 | Harness Engineering（驾驭工程） | 给 AI 装上规则与护栏，控制边界 | L10+ |
- C1 解构自己：不是写提示词，是把你的行业 Know-how、工作节奏、审美标准可读化。AgentOS 懂你，这是个人无法复制的核心资产。
- C2 封装能力：把你每天做的事分解成可执行的 Skill 流水线。每个 Skill 只负责一个阶段，输出结构化产物，下游直接消费。
- C3 驾驭工程：不是设限，是定义边界——AI 能自主决定什么、必须上报什么、失控时如何自恢复。
这三层不是递进，是同时构建、循环强化的：Context 越厚，Skills 越准，Harness 越稳。
Skill 不是“提示词文件”，而是一个小型软件系统。设计不好会导致：角色重复边界不清、文档和命令漂移、测试成本高、出错只能人工接管。
以下八个设计原则来自 AgentOS 专项的实战验证：
把研发过程拆成阶段，形成稳定链路：
Think → Plan → Build → Review → Test → Ship → Reflect
每个 Skill 只负责一个阶段，输出结构化产物（如 plan、test plan、review checklist），下游直接消费。
反例：一个“超级 Skill”既做需求分析、又写代码、又跑 QA，难复用、难排错。
把 SKILL.md 看作构建产物，而不是手写源文件。
源：
SKILL.md.tmpl+ 代码元数据 → 产物：SKILL.md
这样命令新增/变更后，文档可自动同步，避免“提示词漂移”。
浏览器是高频调用资源，冷启动昂贵。不要每次 tool call 都重启浏览器，而是 daemon 常驻：
- CLI：轻量请求转发；
- Server：命令分发 + 会话管理。
首次调用启动 daemon（2-3s），后续调用 HTTP POST（100~200ms）。
不是按“功能模块”分，而是按“副作用语义”分：
- READ：只读，无状态变更，可安全重试；
- WRITE：有状态变更，不保证幂等；
- META：系统级动作（snapshot / tabs / health 等）。
收益：清晰定义重试策略、便于权限控制（线上只允许 READ）、更容易做审计和可观测。
错误消息不是“报错文本”，而是“下一步指令”。
- 差：
Element not found - 好：
Element not found. Run 'snapshot -i' to refresh refs and retry.
统一经过 wrapError() 重写，去掉无用堆栈噪声，每类错误至少给一个“立即可执行动作”。
- Tier 1 静态验证：快、免费，覆盖语法和命令引用一致性；
- Tier 2 E2E 真跑：真实会话，验证端到端行为；
- Tier 3 质量评估：用模型评价“清晰度/可执行性”。
策略：每次提交只跑 Tier 1；发版前跑 Tier 1 + Tier 2；质量回归周期补跑 Tier 3。
不要把安全规则只写在文档里，应该做成可调用能力：
careful：危险命令预警；freeze：编辑边界限制；guard：组合策略。
进入生产修复流程：
/guard → /review → /qa-only → /ship
安全从“口头规范”变成“执行路径”。
Skill 不应硬编码项目特定的测试命令、目录结构、分支命名。应当：
先读取项目配置（如
CLAUDE.md）→ 缺失则向用户提问 → 把答案持久化回配置，避免重复询问。
Workflow Skills
plan -> review -> qa -> ship
|
v
consumes/produces docs
|
v
Template & Generation Layer
*.tmpl + source metadata -> SKILL.md
|
v
invokes browse commands
|
v
Runtime Command Layer
READ / WRITE / META + wrapError()
|
v
Persistent Browser Daemon Layer
session state + low-latency calls
Devin 团队（Cognition）从“不要建多 Agent 系统”到验证出真正可行的多 Agent 模式，花了十个月。这个弯路值得认真记。
多个 Agent 同时写一个代码库，每个 Agent 都会在风格、边缘 case 处理、逻辑判断上做各自的“默认选择”。这些选择本身没问题，但放一起就冲突——就像两个人各自装修一套房子，谁也没问过对方，就动手砸墙。
问题不在于 Agent“笨”，而在于上下文在传递中衰减。Context Rot 指的是：模型处理越来越长的上下文时，决策质量会下降。重要规则在 40-60 轮对话后开始衰减，检索持续添加文本但回答质量反而下降。
单线程写 + 多智能体情报输入 = 当前可行的多 Agent 模式
可以并行思考，但只能串行写入。
并行的部分可以负责检索、审查、规划、路由——这些都是“情报工作”。写入的部分必须唯一，不然就回到那个“两个人同时装修一套房子”的问题。
-
代码审查循环：找一个独立的 Agent 专门做审查，保留干净的上下文，不和编码 Agent 共享。Claude Code Review 的数据显示，对超过 1000 行变更的大型 PR，84% 会被发现问题，平均每个 PR 发现 7.5 个问题，误报率不到 1%。写代码的 Agent 脑子里塞满了仓库细节，它会越写越糊涂；而审代码的 Agent 拿白纸从头看 diff，反而比写代码的聪明 10 倍。
-
Smart Friend（强模型辅助）：让更强、更贵的模型作为“工具”供小模型调用。关键洞察：跨模型的 Smart Friend 实际上是能力路由器——某些模型调试更好，某些处理视觉推理更好，某些写测试更好。
-
Manager Devin：经理 Devin 把大任务分解，生成子 Devins 并行工作。但有三个核心问题：
- 经理 Agent 在小范围任务上训练，遇到大范围任务会过度规定；
- Agent 假设和子 Agent 共享状态，但实际不共享；
- 跨 Agent 通信不会自动发生。
三个问题都指向同一个根因：上下文工程比架构设计更难。
什么仍然不 work：无结构的 Agent 集群（arbitrary networks of agents negotiating with each other）仍然是干扰，不是方向。大多数多 Agent 系统实际上只在用“只读子 Agent”——比如搜索 Agent、代码检索 Agent。这些本质上还是工具调用，不是真正的多 Agent 协作。
一个危险的架构反模式：Logic Monopoly——一个 Agent 在封闭循环里同时控制决策、执行和验证，失败是必然的。
有一个真实案例：2026 年 4 月，Cursor（基于 Claude Opus 4.6 的 AI 编程工具）在 Agent 模式下，9 秒内删除了生产数据库及所有备份。问题不是 AI 能力太强，而是 zero guardrails before execution（执行前没有任何护栏）。
解决思路是 **Separation of Power（权力分离）**架构：规则外部定义、执行受规则约束、结果独立验证。
大多数组织部署的 human-in-the-loop（人工介入）控制是表演性质的，不是结构性的。真正需要定义的是：
- escalation paths（升级路径）
- kill conditions（终止条件）
- earned autonomy thresholds（自主权阈值）
我知道要什么，AI 帮我实现。我接受“差不多能用”的结果。
AI 执行任务，我能确认对错。我建立了检查点机制，能区分“跑通了”和“跑对了”。
AI 在自主区内执行，我在关键节点复核。系统具备重复性和透明性，结果可预测。
扩展执行边界的条件是什么？
是信任的积累，不只是能力的增长。当一个 AI 在你的监督下稳定完成 X，你才能让它自主完成 X。
能力底座：让每个人都能高效利用 AI 完成工程任务。
从“不知道结果对不对”到“能验证，能信任”。
画像：完全不理解 AI 工程执行的方式，抵触使用。认为 AI 写出来的代码不可信、不安全。
典型错误：“AI 写的代码都是垃圾，我从来不用。”——但从未真正让 AI 完成过一个完整任务。
操作手册：
- 了解 AI 执行工程任务的基本概念；
- 参加入门培训，理解 AI 能做什么、不能做什么；
- 尝试使用最简单的 AI 工具完成一个小任务。
自测信号：你是否至少让 AI 完成过 1 个完整的工程任务（而非只是问问题）？如果还没有，你在 L1。
画像：开始尝试使用 AI 执行工程任务，但不深入，容易放弃。遇到问题不会排查。
典型错误：让 AI 写了一个函数，报错了，直接放弃说“果然不行”——而不是把错误信息喂回给 AI。
操作手册：
- 尝试让 AI 执行简单的工程任务（如“帮我写一个函数”）；
- 遇到错误信息时，直接复制给 AI 修复；
- 完成 3-5 次简单的工程任务练习。
自测信号：遇到 AI 报错时，你的第一反应是“自己排查”还是“把错误贴回给 AI”？如果是前者，你在 L2。
画像：把 AI 当搜索引擎或代码片段复制器用。直接复制粘贴 AI 生成的代码，不验证。
典型错误：AI 生成了一个 SQL 查询，直接复制到生产环境执行——没有检查 WHERE 条件、没有先跑 EXPLAIN、没有在测试库验证。
操作手册：
- 使用 AI 完成搜索、翻译、写文档等基础任务；
- 开始养成直接复制错误信息给 AI 的习惯；
- 提高基础效率，但不检查结果正确性。
自测信号：AI 生成的代码，你是否至少读过一遍逻辑再使用？如果从不读，你在 L3。
画像：会写简单的提示指令让 AI 执行工程任务。一次成型，不迭代优化。
典型错误：“帮我写一个登录功能”——AI 生成了代码，没有 session 管理、没有 token 刷新、密码明文存储，但看起来能跑，就用了。
操作手册：
- 学习提示语的基本结构：角色 + 任务 + 约束；
- 完成翻译、数据整理等重复性工程任务；
- 开始尝试给 AI 多一点上下文，看输出是否有改善。
自测信号：你的提示语是否包含“角色 + 任务 + 约束”三个要素？如果通常只有“任务”，你在 L4。
画像：开始使用思维链（Chain of Thought）让 AI 解决复杂工程问题。能提出多步骤任务。
典型错误：让 AI 直接写代码解决一个复杂问题，AI 给了方案但遗漏了关键的边界条件——因为你没让它先分析再写。
操作手册：
- 使用思维链让 AI 拆解复杂问题；
- 模块化提示及思维框架，主动要求 AI 分析问题而非直接给代码；
- 尝试让 AI 先分析问题，再执行，最后验证。
自测信号：你是否经常要求 AI“先分析，再动手”？如果总是直接要结果，你在 L5。
画像：系统性设计提示，能多轮迭代优化输出。能区分“跑通了”和“跑对了”。
典型错误：AI 生成的代码跑通了，但没注意到它用了已废弃的 API 版本——因为验收标准里没有“依赖版本检查”。
操作手册：
- 系统设计提示语，明确输入、输出、约束条件；
- 多轮迭代优化，能指出具体不满意的地方而非泛泛说“不对”；
- 追求个性化、高质量的工程输出。
自测信号：你是否能在 3 轮迭代内让 AI 输出达到你的验收标准？如果不能，你在 L6。
画像：AI 深度融入工作流，能设计“收集 → 处理 → 生成 → 复盘”的自动化工程流水线。
典型错误：搭建了一条自动化流水线，但没有在关键节点设置验证步骤——流水线跑完了，产出物是错的，但没人发现。
操作手册：
- 设计个人或团队的 AI 工作流；
- 自动化数据处理、代码生成、结果验证的完整流程；
- 建立基本的检查点机制。
自测信号：你的 AI 工作流中是否有至少 2 个独立的验证节点（而非只在最后检查一次）？如果没有，你在 L7。
画像：在 AI 执行过程中建立明确的检查点。能区分错误是反馈还是失败。
典型错误：AI 在第三步报错了，你手动修了继续跑——但没有回头检查第一步和第二步的假设是否仍然成立。
操作手册：
- 在每个关键节点建立验证机制；
- 功能验证：AI 真的做了你要的吗；
- 边界验证：遇到意外情况会怎样。
自测信号：每个模块完成后，验证耗时是否 < 总耗时的 15%？如果验证占比过低或过高（> 50%），你的检查点设计需要调整。
画像：能审查 AI 执行任务的完整链路，包括依赖、版本、边界条件。能判断系统是否可信。
典型错误：同一个任务让 AI 跑了一遍，结果对了就认为“系统可信”——没有跑三遍验证可重复性。
操作手册：
- 审查 AI 使用的外部依赖和版本；
- 验证可重复性：同一个任务跑三遍结果一样吗；
- 识别隐藏风险：API 级联失败、并发竞态、数据边界。
自测信号：你是否能列出当前项目 AI 生成部分的所有外部依赖及其版本？如果不能完整列出，你在 L9。
画像：能设计 AI 执行复杂工程任务的架构。包括任务拆解、边界定义、决策权分配。
典型错误：设计了一个看起来很完美的 Agent 架构，但没有定义 escalation paths——AI 遇到未预期情况时不知道该停还是该继续。
操作手册：
- 定义执行边界：AI 能自主决定什么，必须上报什么；
- 设计任务拆分：从 Project-Level 到 Task-Level；
- 建立决策权归属机制。
自测信号：你设计的 AI 工作架构中，是否明确定义了 escalation paths（什么情况下 AI 必须停下来等人确认）？如果没有，你在 L10。
从个人能力到组织能力：建立团队级 AI 工程治理体系。
让团队高效、安全、可持续地使用 AI 执行工程任务。
画像：设计团队级 AI 工作流，建立标准化的任务分发、验证、交付流程。
典型错误：把个人的 AI 工作流直接套到团队——没有考虑不同成员的 AI 熟练度差异，导致 L3 的成员用 L8 的流程，全线崩溃。
操作手册：
- 设计团队级 AI 任务分发机制：按成员等级分配不同复杂度的任务；
- 建立标准化的验证 checklist：每个任务交付前必须通过的检查项；
- 定义交付标准与复核机制：谁复核、复核什么、复核不通过怎么处理。
自测信号：团队成员是否能在不看文档的情况下，说出自己负责的 AI 任务的标准交付流程？如果做不到，你的流程设计还不够清晰。
画像：建立团队 AI 使用的治理框架。包括权限边界、审计机制、安全护栏。
典型错误：写了 AI 使用规范文档，但没有任何技术手段 enforce 规范成了“建议”，而不是“规则”。
操作手册：
- 设计权限边界：谁能用 AI 执行什么级别的任务（如：L5 以下不允许 AI 直接操作数据库）；
- 建立审计机制：谁用了什么 AI 工具、做了什么决策、结果如何；
- 配置安全护栏：技术手段 enforce 规则，而非仅靠文档（如：CI 中检查 AI 生成代码的安全扫描）。
自测信号：你的 AI 治理规则是否有至少 3 条是通过自动化工具 enforce 的（而非仅靠文档约定）？如果没有，你在 L12。
画像：将个人和团队的 AI 使用经验系统化，形成可复用的知识库和最佳实践。
典型错误：每次遇到问题都在群里问一遍，没有人把解决方案沉淀下来——同样的坑，不同的人反复踩。
操作手册：
- 建立 AI 使用经验库：什么任务用什么提示语效果好、什么坑要避开；
- 沉淀可复用的 Skill 模板：团队成员可以直接使用或修改；
- 定期回顾和更新：AI 工具和模型在快速迭代，经验库需要同步更新。
自测信号：新成员入职时，是否有一套 AI 使用 onboarding 材料（而非靠老成员口口相传）？如果没有，你在 L13。
画像：协调多个团队之间的 AI 使用策略，避免重复建设和资源浪费。
典型错误：三个团队各自采购了不同的 AI 工具，各自建立了不同的 Skill 库，互不兼容——公司层面浪费了 3 倍成本。
操作手册：
- 建立跨团队的 AI 工具选型标准：避免每个团队重复评估；
- 推动共享 Skill 库：一个团队验证过的 Skill，其他团队可以直接复用；
- 协调 AI 相关的预算和资源分配。
自测信号：公司内是否有统一的 AI 工具选型清单（而非每个团队各自探索）？如果没有，你在 L14。
画像：建立 AI 使用的效能度量体系，用数据驱动 AI 策略的持续优化。
典型错误：只统计“用了多少次 AI”，不统计“AI 产出物的质量”“AI 节省了多少时间”“AI 引入了多少 bug”——有数据，没洞察。
操作手册：
- 建立 AI 效能度量指标：不只是使用次数，还包括质量、效率、安全维度；
- 定期产出 AI 效能报告：哪些团队用得好、为什么好、怎么复制；
- 基于数据调整 AI 策略：关闭无效的 AI 投入，加码有效的方向。
自测信号：你是否能说出上个季度 AI 使用为公司节省了多少工程时间、引入了多少需要人工修复的缺陷？如果不能，你在 L15。
从技术执行到战略判断：用 AI 驱动长期价值，定义未来行业格局。
用 AI 驱动长期价值，定义未来行业格局。
画像：制定公司级 AI 战略路线图，明确 AI 是核心战略还是辅助工具。
典型错误：CEO 说“我们要全面拥抱 AI”，但各部门不知道这意味着什么——是砍人用 AI 替代，还是用 AI 增强现有团队？战略没有翻译成可执行的部门级目标。
操作手册：
- 制定公司 AI 战略路线：3 年内在哪些环节用 AI、预期达到什么水平；
- 明确战略定位：AI 是降本工具还是差异化武器？不同定位对应不同资源投入；
- 上下对齐：每个部门知道自己的 AI 目标是什么、怎么衡量。
自测信号：公司中层管理者是否能在一句话内说清“我们部门的 AI 战略是什么”？如果不能，你在 L16。
画像：在 AI 投资、并购、内部孵化之间分配资本，承担风险与成本压力。
典型错误：同时启动了 5 个 AI 项目，每个都给了一点资源——结果没有一个能做到有竞争力的水平。
操作手册：
- 评估 AI 相关投资、并购、内部孵化项目：用统一的 ROI 框架；
- 多项目并行时确定优先级：砍掉 bottom 30%，把资源集中到 top 2；
- 管理风险与现金流平衡：AI 投入回报周期长，需要匹配资金规划。
自测信号：你是否在上个季度主动砍掉了至少一个 ROI 不达预期的 AI 项目？如果从未砍过项目，你在 L17。
画像：创建 AI 驱动的差异化竞争优势，重塑行业壁垒。
典型错误：用 AI 做了竞品也在做的事情（如 AI 客服），以为这就是差异化——实际上只是行业标配。
操作手册：
- 识别市场空白：AI 能做什么竞品做不了的？不是“用 AI 做得更好”，而是“没有 AI 根本做不了”；
- 构建差异化竞争优势：把 AI 能力嵌入产品核心，而非作为附加功能；
- 重塑行业规则与壁垒：让竞争对手即使有同样的 AI 工具也无法复制。
自测信号：如果竞品明天也有了同样的 AI 能力，你的竞争优势还在吗？如果不在，你在 L18。
画像：打造全民认同的 AI 文化，让实验与容错成为组织基因。
典型错误：CEO 在全员会上说“鼓励 AI 创新”，但一个员工用 AI 搞砸了一个小项目后被公开批评——文化死于言行不一。
操作手册：
- 传达 AI 文化价值观：不只是口号，要用具体行为定义“什么是被鼓励的”；
- 鼓励实验与容错：AI 实验失败的代价要显性化地低，成功要显性化地奖励；
- 树立标杆与榜样：让先用好 AI 的人被看见、被晋升。
自测信号：过去一个季度，是否有员工因为 AI 实验失败而被惩罚？如果有，你在 L19。
画像：构建 AI 与人类的共生边界，定义未来的商业模态与社会形态。
典型错误：只思考“AI 能替代什么”，不思考“AI 不能替代什么”——导致组织设计失衡，人的价值被系统性低估。
操作手册：
- 定义未来商业模式：AI 和人各自创造什么价值、怎么分配收益；
- 定义未来商业形态：公司边界在哪里、AI 算不算“员工”；
- 关注社会与伦理影响：你的 AI 决策对外部利益相关者意味着什么。
自测信号：你是否能清晰说出“在我的组织中，什么决策永远不应该交给 AI”？如果不能，你在 L20。
以下是 Agentic Coding 实践中最常见的 5 个反模式：
Logic Monopoly 指一个 Agent 同时负责决策、执行和验证，过程中没有任何外部监督机制。这样容易导致错误被遗漏且难以及时纠正。多见于 L7-L9。
修复方向：采纳 Separation of Power 思路，将规则外置，限制执行权限，并引入结果的独立验证机制。
Context Rot 指 AI 对话轮数超过 40 轮后，决策质量明显下降，逐渐遗忘早期的关键约束条件。这种情形常见于 L6-L8。
改进方法：分阶段重置上下文，每个关键阶段的开头都要重新注入核心约束。
流程设计中看似设有“人工确认”节点，但实际确认人缺乏决定性的上下文或结构化信息，只能走形式化流程、成为橡皮图章。常见于 L11-L12。
修复方法：确认节点必须提供结构化的决策依据，如差异点（diff）、风险点和可选方案，确保确认不是走过场。
多个 Agent 同时修改同一份代码库，导致风格和逻辑决策相互冲突，影响项目的统一性。多发于 L8-L10。
改进做法：采用单线程写入，每次只允许一个 Agent 有修改权限，其他 Agent 可作为情报输入提供建议，写入权保持唯一。
当 AI 遇到未预期的问题时，没有清晰的处置规范，既可能选择静默失败，也可能发生越权操作。高发于 L10-L11。
修复方式：明确定义中止条件（kill conditions）、自主权升级（earned autonomy thresholds）及异常上报流程，确保可控可靠。
这些反模式是驱动 Agentic Coding 实践落地时常见的陷阱，识别并规避它们，可以大幅提升系统的健壮性与安全性。
代表性工具：AI Studio、VO、Lovable、Bolt.new。
核心能力是快速调整 Prompt 和系统指令，调试满意后导出结果。适用于验证新想法、一次性简易任务，让想象力快速落地、降低试错成本。
主要工具：Cursor、Qoder、Kiro、Trae。
适合开发需要精度和持续迭代的复杂功能，支持本地调试与大幅重构。在项目型任务或有进一步追求高质量代码输出时，这类工具不可或缺。
代表工具：Claude Code、Gemini CLI、Codex CLI。
支持仓库级规模的任务，以及复杂流程的可持续放手运行。用来处理日常自动化、批量任务和 Skill 执行的场景效果最好。
代表工具：OpenClaw、QClaw。
主打多端通讯集成以及日常会话托管，实现 24/7 的数字分身运营，适合需要持续在线响应、跨端沟通的业务形态。
选型原则：从 Vibe 开始，跑通最小闭环；复杂了上 IDE；要反复用上 CLI；需要多端接入用永动模式。不要在验证阶段就用重型工具，摩擦太大。
- 为什么这件事重要：位于整个体系的开篇，用于引发紧迫感，让人从“观望”转为“理解紧迫性”。这是行动的起点。
- Vibe 的天花板：对应 L1-L4 阶段。这个阶段的核心转变是从“我不知道对不对”到“敢于开始尝试”，重点在于降低试错门槛，快速迭代。
- 验证驱动执行：涵盖 L5-L8。在这一步，思维从“等最终结果”升级为“持续验证过程”，打造反馈闭环，显著提升执行的严密度和安全感。
- 边界定义与信任构建：出现在 L6-L10。之前只在描述结果，这里则转向主动定义能力边界并建立信任机制——由模糊转向清晰。
- AgentOS 三层架构：也在 L6-L10，这里要实现 Context（语境）、Skills（能力单元）、Harness（流程控制）的协同共建，三者互相支持、共同进化。
- Skill 架构设计：属于 L8-L10。此阶段已经不局限于“提示词集合”，而是系统性地建设可组合、可测试和可治理的工程体系。
- 多 Agent 架构：同样是 L8-L10。关键转变是由“单 Agent 独行”进化为“多 Agent 协作情报分工”，提升解决复杂任务的能力与效率。
- 进化路径：体现在 L10 到 L11 的跃迁。这不仅是个人能力的极致优化，更是向组织能力甚至战略判断的蝶变——走向团队或企业级别的智能进化。
L1-L10 个人能力底座（所有人必经）
|
├──> L11-L15 组织治理路径（CTO/工程VP方向）
| 从“个人能力”到“组织能力”
|
└──> L16-L20 商业领袖路径（CEO/创始人方向）
从“技术执行”到“战略判断”
最终形态：人机共创，定义未来。
- L1-L10 解决的是：你一个人能不能驾驭 AI。核心构建 Context / Skills / Harness 三层架构，从“能跑通”走到“能信任”。
- L11-L15 解决的是：你的团队能不能规模化驾驭 AI。核心是治理框架、知识沉淀、效能度量——把个人能力变成组织能力。
- L16-L20 解决的是：你的组织能不能用 AI 重新定义赛道。核心是战略判断、资本分配、文化塑造——从利用 AI 到与 AI 共生。
三条路径不是线性的。你可以在 L10 分叉走向治理，也可以走向战略。每条路径都可以走到极致。
但无论走哪条路，起点只有一个：从“等 AI 给结果”到“在驾驶座上持续验证”。当你完成了这个心智切换，你就是 Agentic Coding 的践行者。
本白皮书由 Mixlab 社区基于公开资料整理。