吴恩达 AI 工程技能图谱最后一篇：开发者如何塑造构建方向

AI Engineering Skills Map 系列之「塑造构建方向」 吴恩达老师的 AI 工程技能图谱最后一篇详细展开： 1. 构建与部署 AI 应用 2. 软件工程基础 3. 使用 ...

AI Engineering Skills Map 系列之「塑造构建方向」 吴恩达老师的 AI 工程技能图谱最后一篇详细展开： 1. 构建与部署 AI 应用 2. 软件工程基础 3. 使用 Coding Agent 4. 塑造构建方向（本文主题） 吴恩达老师的出发点是一个结构性变化：传统模式下，产品经理和设计师负责定义“做什么”，开发者负责“怎么做”，项目经理推进时间线。而 AI 工具极大扩展了单个开发者的产出能力，这条分工线正在消融——掌握 AI 工程技能的开发者开始参与产品和决策角色（正如 PM 和设计师也在学习工程技能） 而「塑造构建方向」的核心命题就是： 你最好的工作将不再是实现别人写好的规格说明书，是主动塑造构建本身。 这个变化的价值在于速度：不必等待 PM 决定下一步做什么，软件开发被“极大加速”。同时他也指出，前端等专精开发者已在走向更广的全栈角色，而 AI 工程的职能范围甚至超出全栈——延伸至市场、财务、法务等领域。这一判断的底层逻辑与图谱第三层直接呼应：Coding Agents 在“给定清晰 spec 后的交付”上进步飞快，因此工程工作的重心正转向“决定 spec 里应该有什么”。 # 吴恩达老师给出四项子技能 一、驱动构建循环（Driving the build loop） 软件开发本质上是一个循环：写代码 → 获取反馈 → 决定下一步。AI 工程师要成为这个循环的驱动者，以“行动偏好”按 AI 赋予的高速度运转。具体包括： · 选择正确的构建形态：快速原型（验证技术概念或功能假设）、MVP（向用户证明价值）、增量功能、或投入企业级系统建设； · 小批量交付以维持速度节奏； · 判断何时收集何种信息：是找用户/干系人拿反馈，还是跑技术实验（如训练模型）来决定下一步； · 权衡决策输入：产品愿景、项目阶段、技术可行性、关键风险、工作量和预算； · 对成熟项目，定义核心指标并以项目管理方式推动指标改善。 二、做产品决策（Making product decisions） 开发者不必转型为 PM，但必须能处理 spec 未覆盖的决策——如果没有 spec，甚至要能自己写一份。这要求三种感觉： · 产品感：无需事事等 PM，能选出真正满足用户需求的方向； · 设计感：至少是基础层面的——做出既可用又令人愉悦的东西； · 商业感：想清楚 GTM、市场规模、单位经济模型和损益（P&L），做出经济上合理的取舍。 吴恩达老师特别强调，这一切的根基是对用户的同理心，并且需要持续打磨，方法按规模递进：与 2–3 位用户做快速非正式访谈 → 数百人规模的问卷 → 大规模 A/B 测试 → 分析数千至数百万用户的行为数据。 三、沟通与引领（Communicating and leading） 既然 AI 工程师的职责半径扩展到了市场、财务、法务等职能，跨职能沟通与干系人对齐就变得前所未有地重要。 同时存在一个时机性机会：AI 演进太快，工程之外的人都在努力理解它对自身工作和新产品形态的影响，技术上的领先让工程师“占得先机”，比如向组织说明哪些方向在技术上可行，从而在更广的层面引领组织前行。 四、高能动性主导权（High-agency ownership） 这是四项中最具个人主动性色彩的一项。吴恩达老师观察到，许多管理者（包括高管）尚不清楚 AI 能做什么，因此无法识别好的项目方向——这个认知缺口正是技术者的机会：主动发现问题、提出方案并执行，在尊重组织优先级和约束的前提下，不等自上而下的精确指令。 具体要求：识别机会、排定优先级、端到端地主导项目、对问题承担责任、在模糊中行动、在挫折中坚持，并且以创造的价值而非完成的任务来衡量自己的工作。 吴恩达老师最后的结论：塑造构建（而非仅仅构建）让 AI 工程比传统软件开发更激动人心；你被赋予更大权力、拥有更广的职责范围、做出更多决策；但代价是更大的技能集要求。因此最后一项底层要求是持续学习：追踪技术前沿、试用新工具、不断调整工作流。（“持续学习的心态”正是整个技能图谱四层之下的共同地基。） info.deeplearning.ai/driving-the-bu… meng shao @shao__meng AI Engineering Skills Map 系列之「使用 Coding Agent」 吴恩达老师的 AI 工程技能图谱第三篇详细展开： 1. 构建与部署 AI 应用 2. 软件工程基础 3. 使用 Coding Agent（本文主题） 4. 塑造构建方向 吴恩达老师认为：使用 Coding Agent 正在成为 AI 工程师的关键能力，而且它的演进速度比其他顶层技能都快，因为 Agent 本身在 harness 和模型两个层面同时快速迭代。因此，这项技能没有终态，只能靠持续的实验、构建和学习来维持。 # 用 Coding Agent 构建软件的通用工作流 通过访谈数十位顶尖 AI 工程师并复盘自己团队的实践，他归纳出一个一致的高层工作流，分三步： 1. 规划（Planning） 包含两部分：一是头脑风暴，可能涉及研究、实验、理解已有代码库；二是写 spec（规格说明），涵盖需求、技术设计、架构，随后生成执行计划。规划完成后还应审视计划本身：质疑关键假设，检查安全性、过度设计等问题。 2. 执行（Execution） 构建、测试、验证，关键在于把握智能体自主性与人工监督之间的平衡。一是让智能体以"校准过的自主程度"去构建；二是通过自动化和/或人工检查来验证输出。 3. 部署与监控（Deployment and monitoring） 部署可能经由 CI/CD 流水线或额外的人工关卡把关；随后用智能体观察日志、发现问题、提出并执行改进。 这个工作流有两个特别注意： 1. 它与前智能体时代的软件开发流程本质相似。真正变化的是注意力的重心：从写代码转移到决定做什么、设计架构、写 spec、验证输出。 2. 各步骤的时长弹性极大，可以省略。greenfield（从零开始）原型的 spec 可能只是一条快速写下的提示词；而有大量用户的 brownfield（存量）项目的 spec 则需要投入大量精力去撰写和验证。整个流程高度迭代，熟练的开发者知道何时该从后面的步骤退回前面：验证失败就引导智能体重建修复；监控发现问题就让智能体更新系统并重新部署。 # 五项关键技能 1. 指挥工作流（Directing the workflow） 知道如何走完上述每一步，并决定每一步投入多少人力、多少智能体算力，以及何时回退迭代。这背后是对速度、成本、技术风险、人力投入四者权衡的深刻理解，具体体现在：前期研究和规划做到什么程度、哪些关键工作保留人类所有权、如何选择架构、规划产物（如 spec）写多细、如何把工作拆解成可验证的步骤。 2. 赋予智能体自主性（Enabling agent autonomy） 这一节内容最密集，可拆成四个决策点： · 自主程度：盯着它交互式往返，还是委托一大块工作？何时设定明确目标让它循环直到成功？ · 上下文管理：构建过程会经历不同阶段，要判断何时把关键经验、用户反馈、假设（包括中途变化的假设）记录下来供智能体下游使用。 · 并行化：何时把任务拆解后让多个智能体并行，由人或更高层的智能体来编排；以及如何在多个并发会话之间分配人的注意力。 · 安全运行：设置权限、对高风险动作设关卡，在保持开发速度的同时限制泄露、数据丢失等损害。 3. 审查工作成果（Reviewing the work） 出发点是一个基本事实：智能体的输出是不确定的。我们事先不知道它会想出什么好主意，也不知道它会埋下什么 bug。因此审查和验证是拿到想要结果、并在偏离时纠正的关键环节。 具体手段包括： · 设计与任务匹配的测试和验证，按需结合行为验证和功能验证。 · 测试用户流程，可让智能体提供截图作为成功或失败的证据。 · 对定性/行为性评估，可使用评估集（eval sets），可能配合 LLM-as-a-judge。 · 决定测试的自动化程度。某些工作流会把测试完全自动化，让智能体能自行检查、自知何时完成。但必须评估这些测试是否真正对应你的目标，不对应就要演进它们。 · 使用智能体代码审查，运行 AI 驱动的安全和架构审计。 · AI 审查不够时，审慎地插入人工审查——主要审查代码行为，较少审查代码本身——同时探索进一步自动化的可能。 · 验证部署，并用智能体把监控和事故管理运营起来。 这里有一个值得注意的判断：人工审查的对象主要是"代码行为"而非"代码"，这反映了注意力重心的转移。 4. 定制智能体及其环境（Customizing the agent and its environment） 目标是让智能体高效获取所需上下文、访问工具、正确高效地构建。具体包括： · 集成 skills、插件、MCP 服务器，并在不再必要时（如新模型让旧 skill 过时）剪除它们。 · 用 hooks 自动化开发流程中可重复的部分，如触发自动代码审查或 CI/CD。 · 维护常驻上下文（AGENTS.md、CLAUDE.md），记录代码库信息、关键架构假设、代码风格、数据访问模式。 · 跨会话、跨并行智能体保存状态，随时间积累智能体的经验，比如通过运行后复盘记录哪些做法有效、哪些无效。 · 建立一致的约定和结构，让代码库对智能体可导航；定期清理智能体产生的技术债。 · 团队协作时，考虑如何在不同开发者的智能体之间协调上下文。 5. 编码智能体基础原理（Coding agent foundations） 要做好上述所有决策，需要理解智能体的工作机制：如何做代码库搜索/检索、如何管理上下文窗口、不同操作（增加工具调用、MCP 服务器等）如何影响上下文、智能体与子智能体如何交互、智能体是如何通过在 LLM 外包裹 harness 构建出来的。 这种理解让智能体不再是黑箱，帮助你识别典型失败模式： · 把简单方案过度设计 · 因缺乏显式验证流程而丧失严谨性 · 未达目标就停下 · 可能破坏文件或生产数据的动作 同时也帮助你推断智能体的状态、给出正确的指令或上下文来引导它，并在监控运行时更早发现它偏离轨道、需要介入。 # 对行业叙事的批评 结尾处吴恩达老师有一段针对性很强的观点。他认为社交媒体对如何使用编码智能体的描述往往过度简化。让智能体自主运行数小时、消耗数百万甚至数千万 token 有时确实有用，但目前超长时程任务的实际效用——尤其是相对成本而言——被夸大到超出现实。 他的结论是：最有效的编码智能体使用是一个复杂、高度迭代的过程，能够以高水平判断力适时介入，效果远好于放手长跑。 🔗 View Quoted Tweet 💬 1 🔄 1 ❤️ 0 👀 316 📊 1 ⚡