AI将如何影响软件工程

当今，氛围编程、AI IDE、MCP、Skill 等新技术、新工具不断涌现，在变化如此之快的时代下，大家可能会对自己的前景和发展感到迷茫。本文主要为大家分享一个 Martin Fowler 的访谈，以及斯坦福大学新开的一门课程，希望通过分享这些工程界大牛和顶尖高校的行业洞见，为各位的工作规划或个人发展带来一些启发和思考。

背景
How AI Will Change Software Engineering
业界系统管理”非确定性”的实例：Spec Coding \& Kiro
- 简介
- Martin Fowler 团队对 Spec Coding 的看法
The Modern Software Developer
- 课程结构
- 自学课程的挑战和建议

背景

目前，AI 对软件行业的冲击已经很明显，已经极大地影响了就业市场和工作方式。斯坦福大学在 2025 年 11 月发布了一篇论文 Canaries in the Coal Mine? Six Facts about the Recent Employment Effects of Artificial Intelligence。在该论文中，斯坦福大学的研究人员联合美国最大薪酬处理公司 ADP，对当前北美的劳动市场进行调研，研究人工智能对就业的影响。该论文中发布了一项结论：对于软件工程师职位，22 岁至 25 岁的初入职场新人，其职位数量在这一波 AI 浪潮中下降了 16%。

微软现在的代码库里，多达 30% 的代码完全是由 AI 编写的。 —— 微软 CEO 萨提亚·纳德拉

大概在 2026 年，Meta 一半的开发工作将由 AI 完成。 —— Meta 创始人扎克伯格

超过 25% 的新代码是 AI 写的。 —— 谷歌 CEO 皮查伊

电子商务公司 Shopify CEO Tobi Lütke 告诉管理者：想招新人？可以，但你得先证明 AI 干不了这活儿，或者 AI 没法干得更好。

金融科技公司 Klarna CEO：我们在 2023 年就停止招聘了，因为 AI 已经能干我们人类做的所有活儿。

教育技术公司 Duolingo CEO Luis von Ahn：我们将逐步停止使用人类承包商，改用 AI。

而且，就在过去的 1 年内，相信大家也能切实感受到 AI 在编程上的应用越来越多：公司大力推行 Cursor，大家对 Cursor 的依赖也越来越重；组内已经有几个项目 AI 代码生成的占比在 50% 以上。

面对这些行业变化，斯坦福大学的一些教授、讲师们认为传统的计算机类课程已经不能满足当前的就业市场，也无法让学生们在未来的职业竞争中胜出。所以，斯坦福大学在最近的 2025 年秋季学期中，推出了一项新的课程：The Modern Software Developer（现代软件开发者）。大部分大学的计算机类课程，都是禁止学生使用 AI 完成作业，使用 AI 会被视为作弊。而该门课却倒反天罡，要求学生必须使用 AI 完成作业，并且要求提供与 AI 的对话记录以供核查，不使用 AI 会被视为”作弊”。在课程的开始，讲师就告诉学生：你不会被 AI 替代，你只会被比你更会用 AI 的工程师替代。

不难看出，AI 全面”侵入”软件工程几乎已成定局，那么如果 AI 继续在软件工程界普及，它将会如何改变软件工程？

How AI Will Change Software Engineering

Martin Fowler（马丁·福勒），ThoughtWorks 首席科学家，敏捷软件、软件架构和重构领域的权威。他是 2001 年《敏捷宣言》的作者之一，也是畅销书《重构》的作者。

软件工程界的知名博主 The Pragmatic Engineer 在 2025 年 11 月对 Martin Fowler 进行了一次访谈，访谈的主题就是：How AI Will Change Software Engineering。这并非一个严谨的学术访谈，但它确实是一个信息密度很高的视频，Fowler 提出了很多很值得讨论的观点。以下，是我结合此次访谈以及 Martin Fowler 个人网站上的一些文章，挑选了几个比较有价值的观点为大家做一个分享。

原视频链接：https://www.youtube.com/watch?v=CQmI4XKTa0U
Martin Fowler 个人网站中 AI Coding 相关的文章：https://martinfowler.com/tags/generative%20AI.html

编程核心范式转变：从确定性到非确定性

Martin Fowler 认为，人工智能对软件工程的影响，是他职业生涯中遇到的最大变革，其影响堪比从汇编语言到高级语言的转变。这次变革的核心在于从确定性到非确定性的转变，这有可能彻底改变软件工程师的思维方式和工作环境。

过去编程语言的发展：追求更高层次的抽象，且保持”确定性”

回顾整个软件工程的整个发展历史，我们可以发现其核心就是在和复杂度做斗争。编程语言的发展亦是，我们一直在追求更高层次的抽象，以提升生产力。其实核心就是：降低复杂度，让一切变得简单。

汇编语言 vs. 机器指令： 汇编让我们用助记符替代了 0 和 1，但仍需关注特定机器的寄存器和指令集。

高级语言（HLLs）vs. 汇编： Fortran、COBOL 等早期 HLLs，包括后期出现的 C 语言，让我们能用语句、条件、循环来思考，而不用关心数据如何在寄存器间移动。

现代语言、框架、DSL vs. 早期 HLLs： Ruby、Go、Python 等现代语言，以及各种框架和领域特定语言（DSL），进一步提升了抽象层次。我们现在可以本能地将函数作为数据传递，使用丰富的库和模式，而不用从头编写大量底层代码。

Fowler 在另一篇文章 LLMs bring new nature of abstraction 中提到，尽管这些发展极大地提升了抽象层次和生产力，但它们并没有从根本上改变”编程的性质”。我们仍然是在与机器进行一种”确定性”的对话：给定相同的输入和代码，我们期望得到相同的输出。错误（Bug）也是可复现的。 然而，LLM 的介入，打破了这一基本假设。

LLM 带来更高抽象的同时，也带来了”非确定性”

“We’re not just moving up the abstraction levels, we’re moving sideways into non-determinism at the same time.” —— Martin Fowler

传统的编程语言、编译器、字节码是一条清晰的、自上而下的抽象路径。模型/DSL、低代码、框架也只是更上一层的抽象，依然输出的是确定的产出。如今，很多人预料中的编程界最高层次的抽象：用自然语言编程，似乎真的来了。但自然语言（Prompt）的到来，也给我们带来一些预料之外的东西：它不再是简单的往上走，像是一条从旁边切入的、直接通往”半结构化/接近人类思维”的道路，这条路带来了”非确定性”，可能彻底改变软件工程。

换个更容易理解，更直观的说法：以前写代码，同样的输入永远产生同样的输出。跑一遍是这个结果，再跑一遍还是这个结果。这种确定性是软件复用的基础。但现在用大语言模型，同样的提示词，给 LLM，今天生成的代码和明天生成的可能完全不一样，生产出的软件质量也可能完全不同。 这种不确定性，是软件工程从来没有面对过的。

未来，软件工程的重点可能要从依赖可重复性转变为系统的管理非确定性。

“非确定性”带来的工程可靠性风险

非判断性放大： LLMs 是不加区别地放大的（amplifies indiscriminately）。如果输入的基础代码质量差，AI 生成的代码将会放大这些问题。缺乏警惕可能导致质量逐渐下降，直到代码库变得难以维护，甚至连 AI 本身也无法基于其进行构建。
调试与归因困难： 在传统的确定性工程中，错误是清晰可归因的。但当故障源于 LLM 的概率性推断时，诊断和根因分析的难度会大幅增加。
无法杜绝”谎言”与”幻觉”： 从目前的大模型发展来看，LLMs”幻觉”几乎是无法避免，因为”幻觉”的本质其实就是 LLM 的核心功能：预测。只是当预测出我们希望的结果时，我们就称之为”智能”；当预测出我们不希望的结果时，我们就称之为”幻觉”。LLM 可能会声称”所有测试都已通过”，”我的代码完全正确”，但实际运行中却发现不是这样。如果一个工程师表现出这种行为，可以对其进行追责、复盘、归因、纠正。但是面对 LLM 不能这样。

如何应对”非确定性”

“我们可能需要学会像造桥一样写代码”，造桥的结构工程师在工作中有一个核心概念叫容差。木材、钢铁、混凝土的物理性能虽然大致已知，但你不能按照理论最优值去设计，必须留出足够的余量，为最坏的情况做准备。对于使用 AI 编程，靠谱的方法是：

不要直接使用 AI 生成的”大段代码”。仅用 AI 生产小的代码切片，每个切片都要经过人工审查；
保持测试覆盖，AI 生成的代码尤其需要测试来验证；
不要怕重构AI 生成的代码，往往它生成的东西结构很混乱，需要你整理。

对于核心业务，不要直接引入”非确定性”，而是让 AI 驱动确定性工具。不要让 AI 直接生成最终代码，而是让 AI 生成半成品，然后引入确定性。举个具体的例子，你不擅长写复杂的 SQL，但需要对数据库做一个复杂查询。你可以告诉 LLM 你想要的结果，让 AI 生成 SQL 语句。生成之后，”手搓”检查一下，如果没问题，再让确定性的数据库引擎去执行。Fowler 也提到一个例子：用类似的方法做核心代码的重构。用 AI 分析代码，识别需要重构的地方，生成重构建议，然后用专门的重构工具去执行这些改动。而不是直接使用大模型进行代码重构。

充分利用 AI 的理解能力和生成能力，但在关键步骤上仍然依赖我们能够完全理解和控制的确定性工具。

Vibe Coding（氛围编程）陷阱

“Vibe Coding（氛围编程）”是 2025 年开始流行的概念，指的是开发者仅通过自然语言提示词让 AI 生成代码，不严格要求对代码的审查和理解，只要求能运行。Vibe Coding 为了追求高效率和低门槛，在很大程度上放弃对代码的底层逻辑或细节进行理解和严格验证。Fowler 认为这种方式很适用于探索性工作，即开发那种一次性、即抛性质的东西，对长期维护的软件极具风险。

这是因为 Vibe Coding 破坏了编程中非常重要的部分：学习回路（learning loop）。“软件开发的本质是人与机器的反复互动，开发者通过这种互动建立对系统的理解。” Fowler 认为，如果只使用 LLM 生成代码，在编码阶段跳过工程师的参与，开发者就失去了学习机会：无法理解系统结构，更无法人为进行微调、演进或修复。软件工程师也正是在这样的学习回路中，逐渐提升自己对业务及代码的理解。除此之外，Vibe Coding 需要依靠 LLM 去修改代码，随着”幻觉”的累积，代码的大概率会变得彻底无法维护。 他分享了一个真实案例：同事用 LLM 生成 SVG 图表，表面可用，但当他试图微调标签位置时，发现生成的代码混乱复杂，远超人工手写的十几行代码，最终导致维护困境。Vibe Coding 可能导致代码逐渐变得不可维护。当需要调整代码时，如果 LLM 因为复杂性或”幻觉”而无法高效维护或调整，唯一的选择可能就是”彻底清除，从头开始”。

Martin Fowler 个人网站上的文章 I still care about the code 提到，自从 Vibe Coding 开始流行以来，经常有人说：”我们可能都不用再关心代码了。就像编译器出现后，我们再也不需要去看汇编语言了。”作者认为至少目前来讲，我们仍然需要关注代码本身。LLM 并非自然语言的编译器、解释器或汇编器，LLM 只是个辅助推理工具。

在对需要长期维护的业务使用 Vibe Coding 时，要经常思考一个问题：如果你是 oncall，遇到突然出现的业务问题时，面对这些成千上万行的 AI 生成的代码，你有多少把握能够快速识别、修复、并预防出现的问题？

所以对于需要长期维护的核心业务，要尽量避免 Vibe Coding，或者要对 AI 生成的代码进行人工审查。但现在 AI Coding 的代码发布到生产似乎已经是不可逆的趋势，我们也不能完全摒弃 Vibe Coding 的高效率，那么到底什么情况下可以使用 Vibe Coding？什么时候需要严格审查 AI 代码？Martin Fowler 团队提出了一个由三个关键因素构成的风险评估方法：P-I-D（相关文章：To vibe or not to vibe），来系统地指导对 AI 产出代码的审查力度：

概率（Probability, P）：AI 在该特定任务上犯错的可能性。该值越高，需要的审查力度越高。
影响（Impact, I）：如果 AI 的输出存在错误，对业务、安全、财务或系统稳定性造成的后果。该值越高，需要的审查力度越高。
可检测性（Detectability, D）：错误在集成或测试阶段被发现的难易程度。该值越低，需要的审查力度越高。

审查力度是这三个因素综合作用的结果。例如，对于涉及安全关键逻辑、复杂并发处理的任务（P 高、I 高、D 低），建议投入极高的审查力度，并采取”假设错误”的态度进行全面测试。而对于生成样板代码或简单工具函数（P 低、I 低、D 高），则可以采用 Vibe Coding，适当减少对代码细节的审查，提高效率。

LLM 非常适合的工作：破解遗留代码难题

“理解遗留系统，AI 真的很在行”。大型企业普遍面临遗留系统困境：大量旧系统缺乏文档，原开发者多已离职，接手者难以理清逻辑。而 LLM 的语义分析能力，能极大降低理解门槛。

Thoughtworks 基于全球团队的经验，每半年发布的技术雷达是行业技术趋势的重要参考。在最新版本中，AI 相关实践占据重要位置。其中，”利用生成式 AI 理解遗留代码”已进入”强烈推荐采用”阶段。

LLM 可显著加速逆向工程，可以帮助团队在数小时内生成大量可用于辅助理解的代码文档，而传统方法可能需要数周甚至数月。基于此，Martin Fowler 团队提出了用于迁移&重构遗留代码的 RRR 工作流（相关文章：Research, Review, Rebuild）：

“研究、评审、重构”（RRR）工作流：这种结构化方法利用 LLMs 进行研究，通过上下文协议增强分析（MCP-augmented LLM analysis）快速理解遗留组件的功能、数据流和数据模型。

首先，准备一份待迁移&重构的 feature 列表，然后选择列表中的 feature 开始迁移&重构，循环下列步骤，直到所有 feature 都迁移&重构完成：
- 研究（Research）：借助 LLM 高效分析旧代码，评估其业务功能、数据模型和数据流，并生成可执行的映射任务。
- 评审（Review）：这是工程师介入的关键阶段。领域专家和架构师对 AI 生成的分析进行验证和指导，以确保其与预期一致。
- 重构（Rebuild）：在验证后的清晰要求下，使用 LLM 辅助重建新功能，并进行代码审查和必要的重构以确保代码质量。

通过该工作流，可以在借助 LLM 高效的遗留代码分析能力的同时，规避”非确定性”带来的影响。这类似于上文提到的不直接引入”非确定性”，而是让 AI 驱动确定性工具。 即使 LLM 具有非确定性本质，在 Research 遗留分析阶段的信息提取任务中，影响也有限。通过人类工程师在 Review、Rebuild 阶段引入确定性，来规避 LLM”非确定性”的影响。

在 AI 时代，对工程师的建议

警惕速度陷阱与自满：AI 加速可能导致团队陷入”速度陷阱”，滋生浮躁和自满情绪，导致”技术债务”累积加快。工程师可能因 LLM 的助力，交付速度快，而忽略需求的深度分析和规划，导致设计不完备或产生低质量的”技术债务”代码。警惕”技术债务”在短时间内积累到不可收拾的地步。
注意软件安全性风险：对于部分安全敏感性业务，LLM 可能引入了严重的安全性风险，尤其是当 AI 编程涉及以下”致命三要素”时：访问隐私数据、暴露于不受信任的内容，以及向外部通信的能力。这极大地增加了软件系统的攻击面。
关注软件开发的核心技能：目前对于计算机行业，一边是软件行业的萧条，大量工程师失业；另一边是 AI 领域的狂热，融资动辄几亿几十亿美元，估值疯涨。Flower 相信 AI 里面确实有真东西，不像当年的区块链和加密货币那么虚，但他也相信 AI 确实存在泡沫。但无论如何，软件开发的核心技能不会过时。什么是核心技能：理解用户需求；与人沟通；把模糊的想法变成清晰的方案；在各种约束条件下做最合适的权衡。
不轻信 AI 输出：LLM 容易产生”幻觉”，即便简单的问题也可能出错，需保持怀疑态度。多问”为什么”，面对 AI 给出的解决方案，追问其逻辑和来源，利用 AI 辅助理解，而非单纯获取答案。
持续关注”重构”： 在 AI 快速生成代码的今天，重构是否已过时？答案恰恰相反，Fowler 认为：为了应对 AI Coding 引入的复杂度和不确定性，重构变得比以往更重要。 重构是质量的基石，它可以持续改善代码设计，防止 LLM 的快速产出转化为长期的技术债务。
LLMs 更适合中低层级的任务，建议工程师将重心转移到更高层级的工作上：
- 从编写代码到监督代理：软件工程师的角色正在转变为”监督式代理”（Supervised Agent）。他们需要具备干预、纠正和引导 AI 生成结果的能力（Code Review 和重构）。
- 高层次思维的加强：开发者将有更多时间进行高层次的思考、架构选择，并加强与业务方的协作，因为这始终是关键的瓶颈。
- 新技能要求：工程师需要学习如何与 LLM 工具交互，并掌握将非确定性结果转变为确定性运行代码的技能。

业界系统管理”非确定性”的实例：Spec Coding & Kiro

在上文中提到 Martin Fowler 的一个观点：由于 AI 时代“非确定性”的引入，软件工程的重点可能要转变为系统的管理非确定性。 目前来看，确实有这种趋势，亚马逊公司推出的 Spec Coding 以及 Kiro 编译器就是个类似的实践。

简介

规范驱动开发（Specification-Driven Development, SDD），又称”Spec Coding”，是一种 AI 辅助开发方法论。Spec Coding 是 2025 年下半年由亚马逊、OpenAI 等头部科技公司共同推动的工程化编程范式。它将 “规范（Specification）”作为团队协作与自动化的核心，要求先定义结构化、可验证的规范文档，再进行代码生成。而亚马逊公司推出的 AI IDE：Kiro，提供了完整的 Spec Coding 流程。

Spec Coding 与 Vibe Coding 的对比：

维度	Vibe Coding	Spec Coding
流程模式	Prompt → Code（直接生成）	Prompt → Spec → Code → Test（先规范后生成，再测试）
核心思想	追求高效，探索性开发	规约先行，工程化开发
思维方式	先快速实现，再酌情优化忘记代码存在，专注创意表达	先详细设计，再小心实现强调结构化与可控性
风险偏好	容忍短期混乱，追求速度	尽量规避风险，追求稳定性（尝试去管理”非确定性”）
Token 消耗	低	高
耗时	短	长

Martin Fowler 团队对 Spec Coding 的看法

从使用 AI Coding 的经验来看，大家确实会花时间精心编写某种形式的规范，然后再交给 AI Coding 工具。因此，规范优先（Spec-first）的原则确实有价值，大家也应该去关注构建规范的不同方法。但是，现阶段的 Spec Coding 仍然存在以下问题：

Spec 目前还没有清晰的定义，缺乏统一的标准
- 市面上多个工具都称为”spec-driven development”（SDD）实现，但实际方法和流程差异很大，SDD 并不是一个统一的概念。例如，对于 Kiro，Spec 是 Requirements → Design → Tasks。但对于另一个工具 spec-kit，Spec 是 Constitution → Specify → Plan → Tasks。目前来看，”Spec”似乎只是”详细 Prompt”的同义词。而且现在”spec-driven development”已经出现语义扩散（Semantic Diffusion）的趋势。缺乏清晰的定义，就难以形成有效的方法论。
Spec Coding 流程在问题规模上缺乏灵活性
- 现有工具（如 Kiro、spec-kit）各有固定流程，但往往对实际开发任务不够适配，尤其在问题规模上显得不够灵活，小问题时处理流程和文档过于繁复，大问题则流程难以覆盖实际需求。
Spec Review 体验存疑
- 正如大家在上文看到的，spec-kit、Kiro 等工具会为工程师生成了大量的 Markdown 文件来审核。这些 AI 生成的文件，普遍冗长且重复，审核起来十分繁琐。实际上，大多数开发者可能更倾向直接审查代码。一个高效、成熟的 Spec 工具应提升 Spec Review 的效率和体验。
前期大量的规范设计，偏离了软件开发的实证经验：与”小步迭代”理念冲突
- 历史经验表明，”小步迭代”是维持可控的最佳方式之一。但 SDD 这些前期大量规范设计，与迭代理念冲突。好的 SDD 工具应该去引入”小步迭代”方法，但这里的”小步”似乎又与 SDD 的理念矛盾。
Spec 存在过度工程化风险
- Spce Coding 前期需要生成大量的规范文档，并将其作为后续的上下文输入。尽管，现在上下文窗口被不断扩大，无需过于担心上下文大小的问题，但这并不意味着 LLM 能可靠地利用所有输入的信息。规范的冗长程度和 AI 的遵从程度之间，不是简单的线性关系。
- 其中一些 Spec 工具可能过于生硬地将我们现有的工作流程输入到 AI Agent 中，最终反而引起了诸如”审核过载”和”信息混乱”等问题。对生成大量文件的复杂方案持保留态度，借用德语词 Verschlimmbesserung（越改越糟）指出过度工程化风险：在某些情况下，规范本身可能成为负担而非助力。
向 MDD 学习的可能性与挑战
- SDD 与早期 MDD（模型驱动开发）很类似，MDD 中的 Model 的本质就是规范（Spec），只不过不是用自然语言编写的，而是由 UML 或 DSL 等方式表达的。但目前 MDD 在实际的商业应用中一直未能大范围普及，其失败的原因之一就是”先构建高抽象层级的模型，再借助低代码工具自动生成代码”这样的流程死板且复杂，会造成额外的开销和限制（适用范围受限）。如今，借助 LLM 可以让代码生成变得简单，但也带来了不确定性。”Spec-First”、”规范即源代码”等概念，最终是否会同时具有 MDD 和 LLM 的缺点：缺乏灵活性，适用范围受限，同时存在不确定性。SDD 的实践应借鉴过去 MDD 的失败与教训，谨慎探索新的模式。

The Modern Software Developer

课程官方链接：CS146S: The Modern Software Developer - Stanford University • Fall 2025

这是全球首个专注于如何使用 LLM 来改变软件工程的课程，以及如何学习相关工具和方法，为未来做好充分准备。该课程推出后，名额预定爆满。为什么这门课在斯坦福如此火爆？因为它回答了一个所有开发者都在问的问题：AI 时代，我该如何工作？ 不是”AI 会不会取代我？”——这是焦虑的问题。而是”如何与 AI 协作，让自己的生产力翻倍？”——这是务实的问题。

课程提出的核心理念：

Human-agent engineering, not vibe coding.（课程的主题是人机协作工程，而非氛围式编程）

纯粹靠”感觉”让 AI 生成代码（所谓 vibe coding），并不能产出生产级软件。真正的现代开发者，需要学会像管理一群”热情但稚嫩的 AI 实习生”一样，给它们提供清晰的上下文、明确的指令、合理的架构。

关注尚未被 AI 系统取代的核心技能

理解业务，聚焦业务

关注主流的前沿技术，成为技术领航者

LLMs are only as good as you are.（LLM 的上限就是你的上限）**

优质上下文催生优质代码。”AI 在我的代码库上不好用”，问题可能不在 AI，而是因为代码本身不够整洁，缺乏清晰的结构和上下文。

如果你无法理解代码库，LLM 同样无能为力（LLM 很适合辅助理解代码库。但如果代码库混乱到人类工程师都无法理解，也不要指望 LLM 能有多大的帮助）

计算机基础课程依然重要。该课程是在此基础上，教你如何使用 AI 进行提效。

“用 AI 去更高效的帮你做你本来就能做的事。那些你本来就做不了的，AI 可能会带来麻烦。”

课程期望达成的目标：

角色转变： 将来，软件工程师会逐步从”写代码的人”变成”AI Agent 的管理者”

能力要求： 现代软件工程师应具备的能力：清晰的上下文表达、系统设计思维、质量把控能力

工具链升级： 软件开发的工具链将发生改变：全栈 AI 工具的实战掌握，从 IDE 到终端到安全审计

信任与验证： 建立对 AI 输出的信任机制，同时保持警惕

由于时间和内容量的限制，无法太深入的介绍这门课程，在这里仅对课程结构进行介绍，起抛砖引玉的作用。从斯坦福大学的角度，看一看在 AI 时代，一个合格的现代软件开发者应该了解、具备哪些具体的知识点或技能点。 对其中某些技术点感兴趣的同学，可以在后续深入了解，也可以为大家做更深入的分享。

课程结构

该课程的总课程量共 10 周，大致可分为以下 5 个模块：

LLM 基础介绍（1 - 2 week）
1. LLM 基本原理
2. 提示词工程
3. MCP（Model Context Protocol）
开发环境（3 - 5 week）
1. AI IDE
2. Agent 管理（未来趋势：实现异步多任务开发）
3. 终端自动化
质量安全（6 - 7 week）
1. 安全风险、AI 测试、漏洞检测
2. AI Code Review
部署与运维（8 - 9 week）
1. 自动化 UI 构建，端到端应用构建
2. AI DevOps
未来展望（10 week）

自学课程的挑战和建议

课程中有价值的内容还是比较多的，但是如果想系统的自学确实是比较有挑战的。

挑战：

课程资源已经开源，理论上任何人都可以自学。但独自学习这样一门前沿课程，确实存在挑战：

课程量大，需要坚持的动力
- 十周的课程量不小。没有 deadline、没有学分、没有同伴，很容易半途而废。
缺乏反馈循环
- 在课堂上，学生可以提问，在作业后收到反馈、与同学讨论。自学者没有这些。你不知道自己的 Agent 设计是否合理，代码审查流程是否完善。
缺失部分学习资源
- 大部分的课程资源已经开源，但仍存在部分学习资源不全的问题，课件中的信息也有限。目前网上没有完整的课程视频记录。自学该前沿课程，需要有较好的信息检索、整理能力。
- 课程中，邀请了大量硅谷 AI 公司（Wrap、Semgrep、Resolve AI 等）的 CEO、CPO、CTO，分享他们的创业经历、设计理念等，并交流经验。自学的话，这部分学习资源几乎不可获取。

建议：

在工作中，边应用边学习
- 如果后续大家的工作有涉及上述模块的话，可以考虑将上述模块中的相关资源作为参考辅助，在应用中学习（依然需要额外的时间投入）。
阅读 Reading 模块中的推荐内容
- 在课程大纲中，列出了每周课程的推荐阅读内容，包含一些质量不错的与本周课程相关的文章、博客等。
关注前沿技术
- 不要拘泥于课程中的内容，学习时关注与此相关的前沿技术。AI 时代技术迭代非常快，该课程已推出了数个月，课程中的部分内容可能已过时。课程主讲人 Mihail Eric 提醒学习者，由于技术迭代太快，下一年的课程内容可能大变。