Google AI开发课程Day 1精解：从Vibe Coding到Agentic Engineering

当85%的专业开发者已在使用AI Coding Agent、41%的新代码由AI编写时，业界却对Vibe Coding、Agentic Engineering这些词各执一词。有人视Vibe Coding为未来，有人斥之为垃圾代码制造机。Google最近上线的五天AI开发课程，第一次把整个行业正在收敛的共识写成了一套正式框架——仅Day 1讲义就有51页。本文梳理这套课程第一天的核心内容，帮你建立一个完整的AI开发心智模型。

Vibe Coding与Agentic Engineering：不是开关，是光谱

Vibe Coding这个词由Karpathy提出，描述一种全新写程式的方式：完全跟着感觉走，用自然语言告诉AI你要什么，完全不看代码，遇到错误就把报错直接贴给AI让它自己修。这个词之所以爆红，是因为它精准描述了很多人早已在用、却一直没有名字的AI开发方式。

但爆红的代价是被滥用。资深工程师用AI做一个规格明确的功能算不算Vibe Coding？团队用Agent执行规划好的架构算不算？当这个词什么都能套，它也就什么都说不清了。于是Karpathy又补了一个词——Agentic Engineering，用来描述有纪律的那一端。

Google课程的第一个核心主张是：这两者不是二选一的开关，而是一条光谱。光谱上有三个位置：Vibe Coding、Structured AI-Assisted Coding、Agentic Engineering。判断你处在哪个位置的标准，不是你用不用AI，而是AI的输出周围有多少结构、验证和人类判断。

讲义给出了一张对照表：在意图规格化程度上，Vibe Coding是随口的自然语言Prompt，Agentic Engineering是正式的Spec、架构文件、Memory Files；在验证方式上，前者是"看起来会动"，后者是自动化测试、CI/CD Gates加LLM Judges；在错误处理上，前者是把报错贴回去叫AI修，后者是Agent在你定义好的边界内自我诊断，人类只处理架构层级的问题。

站在光谱哪个位置没有对错，取决于场景和出错风险。周末做原型纯Vibe Coding完全合理，跑坏就重来没人受伤；但一个处理金流的Production API，就必须用Agentic Engineering。两端最大的分水岭是验证——Tests验证确定性的部分，Evals验证非确定性的部分（Agent走的路径对不对、工具选得对不对、产出有没有达标）。Google说得很死：没有这两样东西，无论你的Prompt写得多精致，你做的都还是Vibe Coding。

Vibe Coding一词由前OpenAI研究科学家、特斯拉自动驾驶前负责人Andrej Karpathy于2025年2月在X平台首次提出。Karpathy将其描述为一种「完全沉浸于氛围、忘记代码本身存在」的编程方式——开发者的角色从编写代码转变为描述意图，让AI处理所有实现细节。这个概念迅速走红，部分原因在于它捕捉了大量非专业开发者使用ChatGPT、Claude等工具「凭感觉做出可用产品」的真实体验。

CI/CD Gates（持续集成/持续交付门控）是Agentic Engineering端的关键验证机制：在代码合并或部署前，自动运行测试、静态分析、安全扫描等检查，只有全部通过才允许进入下一阶段。LLM Judges则是一种新兴评估手段，用另一个语言模型来评判AI生成内容的质量，常用于无法用硬性规则判断对错的场景，例如「Agent的回答是否符合预期风格」或「工具调用顺序是否合理」。

Context Engineering：比Prompt Engineering更重要的技能

想往Agentic Engineering那端移动，该练的不是把Prompt写得更漂亮，而是Context Engineering。可以把它想成给新员工做入职简报：新人报到你不会只丢一句"帮我把功能做出来"，而是告诉他任务、专案背景、公司规范。AI也一样，产出代码的品质与你给的Context高度相关。

Context分为六种：Instructions（定义角色和边界）、Knowledge（领域知识）、Memory（短期与长期状态）、Examples（行为示范）、Tools（可调用的工具定义）、Guardrails（硬性约束）。这六种又可归为两类：Static Context每次都载入，可靠但贵，因为无论什么问题都要消耗Token；Dynamic Context按需载入，便宜可扩展，但风险是该抓的时候没去抓。

哪些放Static、哪些放Dynamic，这条边界本身就是一个关键架构决策，要像代码一样被Review、被版控。管理Dynamic Context最强的模式是Agent Skills——与其把所有专业知识塞进System Prompt，不如让Agent平常保持通用，需要时再读取Skill变成特定任务专家。这个机制叫Progressive Disclosure：Agent启动时只看到每个Skill一行Metadata，任务匹配了才载入完整指令。结果是一个Agent能带几十种专业能力，却只为正在用的那一个付Token成本。

关于Skill有两点值得强调：一是Skill有复利效应，做一个每天用的Skill，用的过程中不断迭代，一个月后会比最初好用很多；二是Skill要写得Agent友善、人类可维护，不要写一份一万行的Skill，否则产出走歪时你根本找不出是哪份"老鼠屎"把Agent带偏了。

Prompt Engineering是指通过精心设计输入文字来引导语言模型产出更理想的结果，曾被视为AI时代最重要的新技能。然而随着Agent系统复杂度上升，单次Prompt的质量对整体产出的影响被稀释——一个多步骤Agent任务的失败，更常源于上下文缺失或工具定义不清，而非某句话措辞不当。Context Engineering将关注点从「一次对话的输入」扩展到「整个系统在整个任务生命周期中看到的所有信息」，包括System Prompt、记忆管理、工具说明、示例选取与Token预算分配，是一项更接近软件架构的系统性工作。

MCP（Model Context Protocol）是Anthropic于2024年底推出的开放协议，旨在标准化AI模型与外部工具、数据源之间的连接方式，是Dynamic Context和Agent Skills实际落地的重要基础设施之一。

Factory Model：开发者的产出不再是代码

整个软件开发生命周期（SDLC）因AI而被压缩，但压得极不均匀。实作（写代码）从几周变成几小时，但需求访谈、架构决策、验证品质大多仍是人的速度。所以不是旧流程被加速，而是诞生了一个新流程：阶段边界变模糊，迭代周期从周变成分钟，Spec的品质成了新瓶颈。

业界调查说AI带来25%到39%的生产力提升，但METR的一项研究发现资深工程师用AI做某些任务反而慢了19%，因为时间花在了验证和修正上。这两个数据不冲突，它们共同说明：AI不是消灭实作工作，而是把"实作"重写为"Review、引导、验证"。最被低估的是维护阶段——以前那种只有原作者看得懂、没人敢动的Legacy Code，现在AI可以读懂整个Codebase、理解其Pattern，在尊重既有架构的前提下动手改。

把这些变化串起来，Google给出Factory Model（工厂模型）：把整个开发流程想成一座工厂，你是工厂经理，不亲手组装每个零件，而是设计产线、把关品质。开发者的主要产出不再是代码，而是产出代码的系统——包含Spec与Context、负责实作的Agents、验证正确性的测试与品质关卡、把失败导回修正的Feedback Loops、约束行为的Guardrails。你给Agent的是Success Criteria，而不是Step-by-Step指令。

Agent = Model + Harness：出包的锅多半不在模型

很多人把Model当成系统本身，新Model出来就觉得Agent变聪明，用旧Model就觉得Agent变笨。Google指出这个观念是错的，正确公式是：Agent = Model + Harness。一颗裸模型不是Agent，它需要Harness给它状态、执行工具的能力、Feedback Loop和可执行的约束，才能成为Agent。你用Claude Code、Cursor、Codex时感受到的行为差异，很大一部分是Harness决定的。

Harness有六大件：Rule Files（定义Agent是谁、什么绝对不能做）、Tools（可调用的Functions、MCP Servers及使用说明）、Sandbox（代码在哪跑、能摸到什么）、Orchestration（子Agent调度、模型路由、交接规则）、Hooks（生命周期固定点跑的确定性代码，比如Commit前自动拦截硬编码密码）、Observability（Logs、Traces、Evals、成本监控）。

Google给了两个案例证明Harness的重要性：Terminal-Bench 2.0上，有团队完全不换Model、只改Harness，就把成绩从30名外拉进前5；LangChain的实验中，同一颗Model只调整System Prompt、Tools和Middleware，就加了13.7分。大部分Agent失败都源于Configuration——缺一个工具、一条规则太模糊、少一个Guardrail，或Context塞满杂讯。日常习惯上，Agent出包时不要修完Bug就走，多花5分钟问自己"我的Rules、Workflows、Skills哪里可以改，让这种错误不再发生"，把经验写回Harness，错误就从成本变成资产。关键在于：Model你控制不了，但Harness是你唯一能控制、也最值得投资的地方。

Terminal-Bench 2.0是一个专门评估AI Agent在真实终端环境中执行复杂任务能力的基准测试，任务包括文件系统操作、代码调试、多步骤Shell脚本执行等，相比单纯的代码生成测试更能反映Agent在实际工程场景中的综合表现。该榜单的排名差异正好提供了一个自然实验：当不同团队使用相同底层模型却取得悬殊成绩时，Harness设计的重要性便得以量化验证。

Hooks机制值得特别说明：它允许开发者在Agent工作流的特定生命周期节点插入确定性代码（非AI生成的普通程序逻辑），例如在Agent提交代码前自动扫描是否有硬编码的API密钥、在Agent调用外部API前检查速率限制。这种「确定性代码守护非确定性AI行为」的设计模式，是Agentic Engineering中控制风险的核心思路之一。

Token经济学：早投资的人后期更便宜

建Harness、写Evals的时间成本真的值得吗？Google从Token Economics角度，用CAPEX（前期投资）和OPEX（营运成本）来回答。

Vibe Coding看起来超便宜，前期投资趋近于零，但它藏着三个会复利成长的营运成本：一是Token燃烧率，没整理过的Context整包倒进去反复叫模型修，低成功率的回圈每轮都在烧钱；二是维护税，缺乏结构一致性的代码半年后出Bug，工程师要花好几天逆向工程；三是资安补救，Production环境修一个漏洞的成本是设计阶段发现的好几倍。

Agentic Engineering把这套账反过来：前期投工程时间设计API Schema、建测试套件、整理Context，CAPEX高，但每个功能的边际成本大幅下降，因为AI是在一座治理好的工厂里跑。Context Engineering不只是技术，更是财务杠杆——LLM按你送进的每个Token收费，一份精准的Context会直接拉高First Pass成功率，第一次就做对，省掉整条Trial-and-Error的钱。

CAPEX（Capital Expenditure，资本支出）与OPEX（Operating Expenditure，运营支出）本是企业财务概念：CAPEX指购买长期资产的一次性投入（如建厂、采购设备），OPEX指维持日常运营的持续成本（如水电、人工）。将其引入AI开发框架的意义在于：它提供了一个跨越时间维度评估技术决策的思维工具。写一套完整的测试套件需要数天工时（高CAPEX），但它让后续每次AI迭代都能快速验证正确性（低OPEX）；反之，跳过测试直接Vibe Coding看似节省时间（低CAPEX），却在每次功能扩展、Bug修复时支付越来越高的验证与返工成本（高OPEX）。First Pass成功率（即AI第一次生成就直接可用的比例）是连接两者的关键指标——Context质量每提升一分，都会直接体现在这个比率上，进而决定整个项目的Token账单走势。

行动建议与人的新角色

当系统能自己运作，人的角色在Conductor（指挥家）和Orchestrator（协调者）之间切换。Conductor模式下你盯着代码一行行出现、随时修正，适合复杂逻辑和不熟的Codebase；Orchestrator模式下你定义目标、派任务给Agents后台并行跑，隔段时间回来Review，适合定义明确的任务。Orchestrator需要四项技能：Specification（把任务定义到不会误解）、Decomposition（拆成Agent单Session能消化的大小）、Evaluation（快速判断产出过不过关）、System Design（设计约束、测试、Feedback Loop）。

对个人开发者：建立并维护你的Agents.md/Claude.md，把Agent每做一次你不想再看到的事就加一条规则；在生成代码前写好测试和Evals（这是你与AI之间的合约）；要上线的代码每行都Review；Debug、系统设计等基本功不能丢，因为AI是放大你的专业而非替代它。

对团队主管：把AI开发当作工程投资而非生产力功能，导入Coding Agent却不配套Evals、Observability和架构标准，只会产出有速度没品质的代码；把Harness当成团队共用资产，System Prompt、Skills、Eval套件都要版控、Review、有人维护；人机混合团队将成常态，招募重心从实作能力移向判断力——能把Agent指挥得好的，才是最有价值的工程师。

课程讲义的最后一句话总结得很好："Generation is solved. Verification, Judgment, and Direction are the new craft."——生成的效率问题已被解决，验证、判断与方向才是新的手艺。你为工作流打造的Harness是存在Version Control里、会复利的资产；Model越换越强，你的系统跟着水涨船高。这套课程分五天，Day 2讲Agent工具、MCP与A2A，Day 3讲Skills、记忆与Context优化，Day 4讲Security与Evaluation，Day 5讲Spec-Driven的Production级开发。