吴恩达：Agentic Coding时代，基本功为何更重要？

这两年只要聊到 AI 编程，开发者群里总绕不开两个话题：一是 AI 会不会让我失业，二是既然 AI 能写代码，我是不是不用再背 API、不用再死磕算法了？

吴恩达最近关于 Agentic Coding 的一系列表态，恰好把这个问题推到了一个更实际的层面。他的核心判断并不是“AI 要取代程序员”，而是：当编程从“手写每一行”变成“指挥 AI 写每一行”，基本功反而变得更值钱了。

这个观点和很多人的直觉相反。乍一看，AI 都帮你写代码了，基础还重要吗？但如果真正上手过 Agent 模式的开发，你会发现一个扎心的事实：AI 写代码的能力越强，对开发者判断力的要求就越高。你不需要背语法，但你需要比 AI 更懂业务、更懂架构、更懂什么是“正确”。否则你连 AI 给出的错误代码都看不出来，更别提让它修正了。

这篇文章不打算泛泛聊趋势。我会先讲清楚 Agentic Coding 到底是什么、和普通 AI 编程助手有什么区别，然后重点拆解吴恩达这个判断背后的技术逻辑：为什么基本功在 Agent 时代不是被削弱了，而是被放大了。最后，我会给出一套可落地的实践思路，包括任务拆解、上下文管理、验证反馈闭环，以及一个最小可运行的 Agentic 工作流示例。

如果你正在用 Cursor、Copilot、通义灵码这类工具，或者正准备拥抱 Agentic Coding，这篇文章值得你读完并收藏。

1. Agentic Coding：从“补全代码”到“自主完成任务”

很多人对 AI 编程的印象还停留在“自动补全”。你写个函数名，AI 帮你补全函数体；你写个注释，AI 帮你生成对应代码。这是 Copilot 时代的能力，核心是代码补全（Code Completion）。

Agentic Coding 则是完全不同的一层。它的核心不是“补全”，而是任务执行（Task Execution）。你交给它的不是一个函数、一个文件，而是一个完整的目标，比如“重构用户模块的鉴权逻辑，并补全单元测试”。AI Agent 会自己拆解任务、读取代码、修改文件、运行测试、根据报错修复、再跑测试，直到任务完成或资源耗尽。

用吴恩达的话说，他更看好的不是 AI 补全（Copilot），而是 AI Agent。补全只是“辅助换挡”，Agent 才是“自动驾驶”。这个类比挺贴切：

• Copilot 模式：你开车，AI 帮你踩油门、打方向盘，但路线和决策还是你来。
• Agent 模式：你说“去机场”，AI 自己规划路线、变道、加油、处理堵车，你只需要在关键时刻接管。

这个变化对开发者的要求是结构性的。以前写代码是“打字”的过程，你的瓶颈在打字速度、语法熟悉度和 API 记忆量。现在写代码是“拆解和管理任务”的过程，你的瓶颈变成了：能不能把需求拆清晰、能不能给 AI 足够的上下文、能不能判断 AI 的输出是否正确。这每一项，都是基本功。

1.1 Agent 的典型工作方式

一个典型的 Agentic Coding 工具，工作流程大致如下：

用户下达任务 -> Agent 感知代码库结构 -> 拆解子任务 -> 读取相关文件 -> 编写代码/修改文件 -> 执行测试 -> 检查输出 -> 失败则读取报错并修复 -> 重复直到通过或放弃

这个过程非常像带一个能力很强、但经验不足的新人开发：你需要给它清晰的任务描述、相关的背景资料、验收标准，它才能交出像样的结果。如果需求本身就模棱两可，它给出的代码大概率也是“看似正确，实则跑偏”。

理解了这一点，你就会明白吴恩达为什么强调基本功。因为AI Agent 不会替你理解业务，不会替你设计架构，更不会替你对代码质量负责。它只是在执行你的意图。你的意图越清晰、越正确，它的执行结果才越有价值。

2. 吴恩达的观点为何引发热议：编程教育的重心正在迁移

吴恩达在多个场合表达过一个类似的观点：AI 不会取代程序员，但使用 AI 的程序员会取代不使用 AI 的程序员。而在 Agentic Coding 的语境下，这句话的潜台词更加明确：懂得如何正确使用 AI 的程序员，核心竞争力恰恰是传统的基本功。

他的这一表态之所以引发热议，是因为它直接冲击了两拨人。

第一拨是焦虑的初学者。他们刚学编程就发现 AI 能写代码，于是怀疑自己是不是入错行。吴恩达的潜台词其实是：正因为 AI 能写代码，新人的学习路径反而应该更扎实，因为“调用 AI 写代码”这件事本身就需要你理解代码。

第二拨是观望的技术管理者。他们不确定是否该在团队里推行 AI 编程，担心引入 AI 后代码质量失控。吴恩达的观点给了他们一个方向：AI 编程工具不是用来降低招聘标准的，而是用来放大优秀工程师产出的。根基不稳的工程师，用 AI 只会更快地制造灾难。

2.1 AI 不会取代程序员，但会重构程序员的能力模型

传统程序员的日常工作可以粗略拆成四块：理解需求、设计实现、编写代码、验证修复。Agentic Coding 对这四个环节的影响力度完全不同：

你会发现，基本功并没有消失，只是换了形态。以前编码能力体现在“写得出”，现在体现在“看得出对不对”；以前调试能力体现在“一步步查”，现在体现在“告诉 AI 查哪里、怎么查”。这不是降低门槛，而是把门槛从“体力活”挪到了“脑力活”。

这正好回应了吴恩达的核心判断：在 Agentic Coding 时代，那些容易被量化的技能（比如记住某个 API 的写法）确实不再值钱，但那些需要深厚积累的能力（比如系统设计、代码审查、调试推理）反而成为程序员的核心竞争力。

3. 基本功到底是什么：Agent 时代真正值钱的四种能力

很多文章一说到基本功就笼统地说“数据结构、算法、操作系统、网络”。这些确实重要，但不够具体。结合 Agentic Coding 的实际工作流，我认为真正被 AI 放大的基本功是下面四种。

3.1 代码审查能力：AI 写代码，你来当评审

在 Agent 工作流里，AI 是“写代码的人”，但你才是“对代码负责的人”。这意味着你必须有很强的代码审查能力。AI 生成的代码可能语法完全正确、逻辑也能跑通，但在边界处理、并发安全、资源释放、安全漏洞这些方面，它并不比你更懂你的业务场景。

这里真正容易踩坑的地方是：AI 生成的代码往往看起来非常专业，甚至比大多数初级工程师写得还规范。这种“看起来很对”的代码，恰恰是最危险的。因为你会本能地降低警惕，跳过审查直接合并。等线上出问题，你才发现 AI 没考虑幂等、没处理分布式锁的失效、没有兼容历史数据。

所以，基本功里的“读代码能力”会变得空前重要。你需要能在几十行 AI 生成的代码里，快速识别出潜在的问题，知道哪些地方需要加锁、哪些接口需要做幂等、哪些异常不能吞掉。这没有捷径，只能靠大量阅读、大量 review、大量踩坑积累。

3.2 调试与根因分析能力：AI 高效报错，你来定位方向

Agent 在运行过程中会频繁遇到报错。很多 Agent 工具具备自动修复循环：跑测试、看报错、改代码、再跑。但它能不能修好，取决于它对根因的判断准不准。

这里有一个非常现实的问题：AI 的修复策略往往是“症状修复”，而不是“根因修复”。比如测试报了一个空指针异常，AI 最常见的修法是加一个判空。但真正的原因可能是上游数据没做校验、数据库查询返回了 null、或者序列化配置有误。如果你不具备调试能力，你大概率会接受 AI 的“表面修复”，然后留下一个价值连城的隐藏 Bug。

因此，Agent 时代的调试基本功不是“会打日志、会断点”，而是“能通过现象反推链路、能判断 AI 的修复方向是否正确”。这要求你对系统架构、数据流、调用链有清晰的整体认知。你的系统越是复杂，这种能力就越值钱。

3.3 系统设计与抽象能力：AI 写实现，你来定边界

AI 可以帮你写出一个类、一个函数、一个模块，甚至一个微服务，但它不会替你想清楚“这个模块的边界在哪里”“接口怎么定义才能兼顾未来的扩展”“哪些逻辑应该抽成公共组件”。这些恰恰是软件工程里最难、最值钱的部分。

吴恩达在强调基本功时，实际上是在提醒开发者：如果你依赖 AI 生成代码，但你自己没有系统设计能力，你得到的就是一堆无法维护的“AI 屎山”。因为 AI 擅长生成局部代码，不擅长保持全局一致性。今天是这个风格，明天是那个模式，过两周你可能收获一个风格混乱、抽象层次不清的项目。

真正的 Agentic Coding 高手，会把 AI 当成“高级外包”来用：自己负责总体架构、模块边界、接口契约、数据模型，AI 负责具体的实现代码。外包能不能用好，取决于发包人的设计能力。这个类比放到 AI 编程上再合适不过。

3.4 需求拆解与表达能力：AI 执行力再强，也需要正确指令

这一点经常被忽略，但在 Agentic Coding 里极其致命。Agent 不像人，它不会在你话说一半时帮你补全理解。你描述得模糊，它就执行得随意。

举个实际例子。你让 AI “优化一下登录接口的性能”。这个指令在 Agent 看来可以有十几种理解：是优化数据库查询？是加缓存？是改并发模型？是削峰？还是换算法？如果你不把“优化方向”“性能指标”“约束条件”讲清楚，AI 给出的方案大概率不是你要的。

需求拆解能力，恰恰是很多程序员在职场上最容易忽视的基本功。以前你可以边写边想，写错了再改成本也低。但在 Agent 模式下，指令下达后 AI 会沿着它自己的理解执行很久，等你发现方向错了，浪费的时间和计算资源都很大。

正确做法是：把一个大需求拆成多个小任务，每个任务都有明确的目标、验收标准和约束条件，让 AI 逐个完成，你逐步审核。这种“小步快跑 + 频繁验证”的方式，才是 Agentic Coding 的正确姿势。

4. 四变四不变：Agentic Coding 改变了什么，又没改变什么

为了更清楚地理解“基本功更重要”这个判断，我们做一个系统的对比：Agent 到底改变了什么，又坚持了什么。

4.1 Agent 真正改变的四个层面

第一，改变了编码的产出形式。从“手写代码”变成“编写指令 + 审查代码”。你的时间分配会从 80% 写代码 + 20% 调试，反转为 20% 写指令 + 40% 审查 + 40% 调试验证。这个比例变化是结构性的。

第二，改变了上手新项目的效率。以前接手一个新项目，光读代码就要好几天。现在你可以让 Agent 帮你生成项目结构说明、梳理核心调用链、标记 TODO 位置。你省去的是“阅读理解”环节，得到的是更高纬度的“系统认知”。

第三，改变了编程学习的反馈节奏。以前写完代码要等编译、等测试，反馈周期以分钟计算。现在 Agent 可以秒级给出修改建议、分钟级跑通测试。反馈周期短了，学习效率本来应该更高，但前提是你真的能看懂反馈。

第四，改变了软件工程的协作边界。以前协作是“人和人”，现在协作是“人和 AI”。Code Review 的对象从“同事的代码”扩展到了“AI 的产出”。团队需要建立新的 review 标准和验收规范。

4.2 Agent 没有改变的四个层面

第一，没有改变“代码要正确”这个硬标准。不管代码是人写的还是 AI 写的，上线报错就是失败。AI 不会降低正确的标准，它只是让“生产错误代码”的速度变快了。

第二，没有改变“系统要演进”这个长期挑战。AI 能生成单个文件，但不能替你做长期的技术规划。系统怎么演进、技术债怎么还、依赖怎么升级，这些依然是人的责任。

第三，没有改变“安全与合规”的底线。AI 生成的代码可能包含安全漏洞、许可证风险、数据隐私问题。这比人工写的代码更难发现，因为 AI 可能会“合理”地使用一个高危依赖，或者“合理”地记录敏感日志。

第四，没有改变“业务理解”的核心价值。代码是手段，业务是目的。AI 不懂你的行业，不懂你的用户，不懂你老板的真实意图。能在代码和业务之间做翻译的人，永远是团队里最稀缺的人。

这个对比告诉我们：Agent 改变的是效率和工具，不变的是标准和责任。工具越强，你对标准和责任的把握就越重要——这就是基本功价值被放大的底层逻辑。

5. 用 Agentic 思路改造自己的开发流程：一套可落地的实践框架

空谈趋势没意义。接下来我给出一套实际的实践建议，帮助你把 Agentic Coding 真正嵌入到日常开发里。这套框架建立在上面讨论的能力模型之上：任务拆解、上下文管理、验证闭环。

5.1 第一步：学会把需求写成 PRD 级别的任务描述

Agentic Coding 最大的敌人是模糊。你给 AI 的任务描述，应当尽可能接近一份微型 PRD：背景、目标、范围、约束、验收标准。

这里有一个反直觉的经验：任务描述写得越详细，AI 完成质量越高，但完成时间并不会线性增加。因为多写几句话的边际成本，远低于 AI 因为误解而返工的时间成本。

一份好的任务描述，可以参考下面这个模板：

任务目标：为订单模块新增“导出 CSV”功能。 背景：运营同学需要定期导出订单明细，当前没有现成导出能力。 范围：仅导出当前筛选条件下的订单数据，不涉及权限改造。 约束： - 导出文件需包含表头，字段与列表展示一致。 - 单次导出最多 5 万条，超出需分批生成。 - 使用异步任务，完成后通过站内信通知用户。 验收标准： 1. 点击“导出”按钮后，生成下载任务。 2. 任务完成后，用户可下载合法的 CSV 文件。 3. 同一用户同时最多只能有 3 个导出任务在运行。

把这样的任务描述交给 Agent，和你只写一句“帮我加个导出 CSV”，结果是完全不同的。请注意，这个模板里没有任何代码，但每一个约束都体现了系统设计、性能边界、并发控制的基本功。

5.2 第二步：管理好给 AI 的上下文

Agent 的性能在很大程度上取决于它能看到的信息。如果你在一个较大的项目里使用 Agent 工具，请务必管理好上下文。

具体来说，有三类信息是最有价值的：

第一类是当前任务相关的代码结构。告诉 Agent“登录逻辑在auth/login.py，用户表定义在models/user.py”。这能避免 AI 在代码库里乱猜。

第二类是历史决定的约束。比如“项目里统一用Result<T>包装返回值，不用裸对象”。这类隐性约束是 Agent 最容易违反的，必须在任务描述里显式给出。

第三类是测试命令和运行方式。告诉 Agent“本项目用 pytest，运行单测用make test”。这能让 Agent 在修改完代码后自主验证，而不是把验证留给你。

上下文管理能力，本质上是对项目熟悉度的外部表现。一个不熟悉项目的人，连哪些文件相关都说不清，让他去指挥 Agent 就是灾难。最终还是要靠你平时对项目结构的积累。

5.3 第三步：建立“写代码-跑测试-审查”的闭环

在 Agentic 工作流里，最常见的问题是“信任过度”。把任务交给 Agent 后，看一眼测试通过就合入，这是非常危险的。

正确做法是：

1. Agent 完成编码后，你必须做一次 code review，而不是只跑测试。
2. 审查时重点关注：边界条件、异常处理、安全风险、是否符合项目既有模式。
3. 对生产环境敏感的代码，跑完测试后要做一次本地基于真实数据的验证。

这意味着：Agent 可以帮你干 80% 的活，但剩下的 20% 才是决定质量的关键。而这 20% 涉及的正是代码审查、调试推理、系统设计这些基本功。

6. 最小示例：一个 Agentic 编码任务的完整过程

为了让上面的思路更加具体，下面用一个最小示例展示 Agentic Coding 的实际工作流。假设我们要在 Python 项目里新增一个工具函数，并用 pytest 写测试。

6.1 任务描述

我先写好任务描述，这是给 AI 的输入：

在项目 utils.py 中新增一个 get_week_range(date) 函数。 功能：给定一个日期，返回该日期所在周的周一和周日。 要求： - 以 ISO 8601 标准计算周一为一周开始。 - 返回类型为 tuple[date, date]。 - 如果入参不是 date 类型，抛出 TypeError。 - 在 test_utils.py 中为这个函数补全单元测试。 项目使用 pytest，请在实现后运行 pytest test_utils.py 验证。

这份描述包含了：文件路径、函数名、功能定义、类型约束、异常行为、验证命令。即使是一个初级工程师接到这个任务，也知道怎么做。对 Agent 来说，这更是一份“可以立刻开工”的指令。

6.2 AI 生成的代码

假设 Agent 给出了如下实现：

# 文件路径：utils.py from datetime import date, timedelta def get_week_range(d: date) -> tuple[date, date]: if not isinstance(d, date): raise TypeError("d must be a date") monday = d - timedelta(days=d.weekday()) sunday = monday + timedelta(days=6) return monday, sunday

这个实现逻辑很直接：weekday()返回 0 到 6，0 表示周一。用当前日期减去weekday()天就能得到周一，再加 6 天得到周日。看起来没问题。

6.3 对应的单元测试

# 文件路径：test_utils.py from datetime import date import pytest from utils import get_week_range def test_get_week_range_normal(): monday, sunday = get_week_range(date(2024, 10, 16)) assert monday == date(2024, 10, 14) assert sunday == date(2024, 10, 20) def test_get_week_range_monday(): monday, sunday = get_week_range(date(2024, 10, 14)) assert monday == date(2024, 10, 14) assert sunday == date(2024, 10, 20) def test_get_week_range_type_error(): with pytest.raises(TypeError): get_week_range("2024-10-16")

6.4 运行验证

在终端里运行：

pytest test_utils.py -v

预期输出：

test_utils.py::test_get_week_range_normal PASSED test_utils.py::test_get_week_range_monday PASSED test_utils.py::test_get_week_range_type_error PASSED

到这里，一个 Agentic 编码任务的最小闭环就完成了。请注意，整个过程中，最关键的环节不是 AI 生成代码，而是你的任务描述和结果审查。你认为“周一是一周开始”这个需求合理吗？你真的要 ISO 标准而不是普通日历吗？为什么要抛 TypeError 而不是返回 None？这些问题，AI 不会替你想——它们考验的是你的基本功和你对业务的理解。

7. 常见误区与排查思路：为什么你的 Agent 总是不听话

在实际使用 Agent 编程工具时，开发者经常会遇到“AI 不听话”的情况。大多数情况下，问题不在 AI，而在使用方式。下面这些是我的观察总结。

7.1 Agent 常见的四类问题

7.2 排查 Agent 问题时应该做的三件事

第一，查看 Agent 的操作轨迹。大多数 Agent 工具会记录它读取了哪些文件、修改了哪些文件、执行了什么命令。这是你判断它是否“迷失方向”的第一手资料。

第二，缩小任务范围。如果 Agent 执行一个大型任务表现不佳，试着把它拆成几个小型任务。比如“重构用户模块”可以拆成“拆分 UserService”“抽取鉴权逻辑”“补全测试”三个独立任务。

第三，提供更明确的错误信息。如果你给 Agent 的反馈只是“还是不对”，它确实很难改进。你应该把完整的堆栈、期望的行为、实际的行为都写清楚。AI 编程和带人是一样的，反馈越具体，改进越到位。

7.3 判断 Agent 是否适合你的团队

并不是所有项目都适合马上全面引入 Agentic Coding。从一些实践反馈来看，下面这些情况更适合使用 Agent：

• 项目有完善的单元测试和集成测试。Agent 最擅长“改完代码自动跑测试”，如果你的项目根本没有测试保护，它出错的风险会显著上升。
• 代码库结构清晰、模块边界明确。Agent 在混乱的代码库里会迷失方向。
• 团队成员有较强的代码审查能力。这需要时间培养，不是一蹴而就的。

如果既没有测试保护，也没有清晰的模块边界，成员审查能力又一般，那引入 Agent 的优先级不如先把这两件事补上。工具是放大器，不是替代品。你的工程基本功越扎实，Agent 放大的效果才越正面。

8. 面向 Agentic 时代的基本功训练建议

如果读到这里，你认可“基本功更重要”，那下一步的问题就是：具体该练什么、怎么练。这里给出几条实用建议，不需要全部做到，挑你缺的补即可。

8.1 练代码审查：看别人的代码，不看答案

这是提升 Agent 协作能力最直接的方式。你可以找一些开源项目，先读代码，然后判定哪些地方存在隐患，再对照注释和讨论看自己的判断是否准确。这个习惯能锻炼你在没有“标准答案”的情况下做风险判断的能力。

8.2 练调试推理：不要急着让 AI 修，先自己定位

遇到 Bug 时，不要第一时间丢给 Agent。先自己花五分钟分析根因：这个报错是哪一层抛的？数据从哪来？在哪个环节状态发生了变化？当你形成自己的判断后，再让 Agent 验证和修复。久而久之，你对 Root Cause Analysis 的能力会明显提升。

8.3 练需求拆解：把大需求写成可执行的规范

日常工作中，接到需求时先不要急着写代码。试着写一份“给 AI 的任务描述”，把目标、范围、约束、验收标准写清楚。如果你发现自己写不清楚，说明你还没真正理解需求。这也是 AGI 时代程序员最值钱的能力之一。

8.4 练系统设计：给 AI 指定边界，而不是让它自由发挥

在项目里刻意练习“模块划分”和“接口设计”。自己先定义一个模块的边界和数据模型，再让 AI 去实现具体代码。不要直接丢一个大项目让 AI 自由发挥。保持“人设计、AI 实现”的分工模式，能让你逐步建立系统设计的手感。

9. 总结与后续学习方向

吴恩达关于 Agentic Coding 时代基本功更重要的判断，并不是一句空洞的鼓励，而是对技术发展方向的精准观察。AI 的编码能力越强，它就越像一个能力很强但需要正确指导的协作者。你需要懂代码才能审查它的产出，需要懂系统才能为它划定边界，需要懂业务才能为它定义目标。这些能力，全部来自基本功。

对于正在学习编程的开发者，我的建议是：不要因为 AI 能写代码就跳过基础。相反，你应该把 AI 当成“陪练”，让它帮你更快地通过反馈验证自己的理解。对于已经工作的工程师，更好的策略是主动把 Agentic 工作流引入日常开发，从任务拆解、上下文管理、验证闭环这些具体实践开始，逐步建立自己的 AI 协作方法论。

下一步值得深入的方向包括：

• 学习 Agent 底层的工作机制，理解提示词、工具调用、上下文窗口对最终效果的影响。
• 在你的项目里搭建一套完整的测试保护网，让 AI 可以安全地在你的代码库上“工作”。
• 研究团队级 AI 协作规范，包括代码审查标准、指令模板、上下文管理策略。

Agentic Coding 的门票不是“会用某个 AI 工具”，而是“具备扎实的工程基本功 + 与 AI 高效协作的方法”。前者是消费，后者是生产。用吴恩达的观点来收尾：在这个时代，拥有深厚基本功的开发者，不会失业，只会更贵。