大家好我是你们的技术博主朋友。最近 AI 编程工具越来越强不少朋友开始焦虑既然 AI 都能自动写代码了我是不是不用再花时间学基础了是不是直接让 AI 生成整个项目就行恰好最近看到吴恩达关于 Agentic Coding 时代基本功更重要的一些观点我深有感触。作为一个从手工写 SQL、手动配 Spring 走到今天的老开发我想结合自己的项目经验认真聊聊这个话题并且给出一套在 Agentic Coding 时代依然非常实用的基本功学习路径。这篇文章会围绕三个核心问题展开Agentic Coding 到底是什么它和普通 AI 辅助编程有什么区别。为什么 AI 越强开发者的基本功反而越重要。具体怎么做才能让基本功成为你驾驭 AI 的核心竞争力。文章后半部分会给出大量代码示例、调试案例、测试思路和工程实践建议不管你是刚入门的新手还是已经在用 AI 提效的开发者都能从里面找到有用的东西。1. 背景与核心概念1.1 什么是 Agentic Coding在讨论基本功之前先要把 Agentic Coding 这个概念说清楚。Agentic Coding翻译过来可以理解为“代理式编程”或“智能体编程”。它和我们平时用的代码补全工具不太一样。传统的 AI 辅助编程比如自动补全、代码提示、单行生成本质上是“你写一句AI 接一句”。你仍然掌握着整体方向AI 只是帮你加快打字速度。而 Agentic Coding 强调的是AI 作为一个智能体Agent能够接收一个相对完整的任务目标然后自主规划步骤、编写代码、运行测试、检查结果甚至根据失败信息自动修改代码直到完成任务。通俗点说以前你问 AI“这个 Python 函数怎么写” AI 给你一段代码。这是被动辅助。现在你告诉 Agent“请帮我实现一个用户注册接口包含参数校验、密码加密、重复注册检查并编写单元测试跑通后把结果告诉我。” Agent 自己拆任务、自己写代码、自己跑测试、自己修 bug。这是主动代理。听起来很美好对吧但在实际项目落地时你会发现一个问题Agent 确实能写出很多代码但你自己能不能看懂它写的代码能不能判断它写的方案是否符合项目规范能不能在它跑偏的时候及时纠正这些能力恰恰就是基本功。1.2 吴恩达观点的核心含义吴恩达的观点并不是“AI 编程不重要”也不是“大家不要用 AI”。他的核心意思是在 Agentic Coding 时代开发者对底层原理、编程基础、代码质量的理解变得比以往更重要。为什么因为 AI 生成代码的效率提高之后代码审查Code Review、问题定位、系统设计、质量把控这些环节变成了开发者的主要工作。你不再只是“写代码的人”而是“指挥 AI 并验证结果的人”。如果你基本功不扎实会出现什么情况AI 生成的代码运行报错你完全不知道从哪排查。AI 生成了一个看似正确的函数但存在严重性能问题你没有发现。AI 生成的 SQL 没有加 WHERE 条件你直接执行了数据全没了。AI 按它的理解实现了一个功能但和你的业务需求完全是两码事你却没有立刻察觉。这些问题的根源不是 AI 不够聪明而是开发者缺少足够的基本功去判断、纠正和把控 AI 的输出。所以吴恩达说基本功更重要其实是在提醒我们工具越强大使用工具的人越需要有判断力。1.3 为什么 AI 编程时代依然需要扎实基本功我们再从技术演进的视角看一眼。过去十年软件开发经历了几个阶段手工编码时代所有代码必须自己写不懂语法就写不出程序。框架封装时代Spring Boot、MyBatis、Django 这类框架帮你省掉大量重复代码你只需要懂配置和业务逻辑。AI 辅助时代Copilot、ChatGPT 帮你生成模板代码、工具函数、测试用例。Agentic Coding 时代AI 主动帮你规划、实现、测试、修复整个功能模块。你会发现每一轮工具升级确实都降低了“写出代码”的门槛。但同时每一轮升级对开发者的“判断力”要求反而变高了。框架帮你省事但你必须理解框架的运行机制否则遇到诡异 bug 完全无从下手。AI 帮你写代码但你必须理解代码为什么这么写否则连怎么改都不敢动。如果把软件开发比作开车那基本功就是交通规则、车辆原理和驾驶技术。AI 是自动辅助驾驶能帮你减轻操作负担但你不能因为开了辅助驾驶就完全不懂刹车失灵该怎么处理。2. 环境准备与工具说明聊完概念我们进入实操环节。既然要讨论 Agentic Coding 时代的基本功那我们需要一套可以实际动手的环境。2.1 开发环境版本说明本文示例以常见环境为例版本需要根据你的实际项目情况调整重点演示思路。操作系统Windows 10/11、macOS、Linux 均可。编程语言Python 3.8 或 Java 8开发工具VS Code、IDEA 或 PyCharm版本管理工具Git构建工具MavenJava或 pipPython测试框架JUnit 5Java、pytestPython注意如果你已经在企业中使用了特定的技术栈不要为了跟随本文示例而强行更换版本关键是理解思路。2.2 关于 AI 编程工具目前常见的 AI 编程工具有很多例如 GitHub Copilot、Cursor、通义灵码、CodeGeeX 等。它们的能力各有差异但整体趋势都是朝着 Agentic Coding 的方向演进。在本文中我不会针对某一款工具做详细教学而是围绕“基本功如何配合 AI 使用”这个主题展开。即使你使用的工具和我的不同底层的方法论仍然适用。建议你可以准备两个环境一个用于 AI 辅助编码实验体验 Agent 自动写代码、跑测试。一个用于纯手工练习基本功确保自己离开 AI 也能完成核心开发任务。这两个环境并不冲突实际上它们是互补的。2.3 准备一个示例项目为了便于后续实战演示我准备了一个非常简单的业务场景用户注册模块。这个模块包含以下功能接收用户名、密码、邮箱。校验参数合法性。密码加密存储。检查用户名是否重复。保存用户信息。编写单元测试。这是一个非常经典的入门级业务模块覆盖了参数校验、异常处理、数据访问、单元测试等基本功点非常适合用来练习也非常适合用来观察 AI 在实现过程中的表现。3. 基本功到底包含哪些能力很多人一提“基本功”第一反应是语法、数据结构、算法。这些当然是基本功但只有这些远远不够。在 Agentic Coding 时代我认为基本功应该包括以下六个方面。3.1 需求拆解与问题定义能力这是很多人忽视的一项基本功。AI 编程工具最擅长的是“接到明确任务后执行”而不是“帮你搞清楚你到底想要什么”。如果你无法把一个模糊的业务需求拆解成清晰、可验证的小任务AI 就没法给你有用的输出。举个例子。不好的需求描述帮我写一个用户注册功能。这个描述太宽泛了。AI 可能给你生成一套复杂的 Spring Security 方案也可能给你一个最简单的表单提交完全取决于它的训练数据。好一些的需求描述帮我实现一个用户注册接口接收 username、password、email 三个参数。要求username 长度 4-20 个字符只能包含字母数字下划线。password 长度至少 8 位必须包含字母和数字。username 不能重复重复时返回错误码 1001。密码使用 BCrypt 加密存储。保存成功返回用户 ID。 请给出接口定义、实现代码、单元测试。这个描述包含了输入、输出、约束、错误码、安全要求。AI 才能给出接近你预期的结果。所以需求拆解能力是你和 AI 协作的第一道基本功。3.2 代码阅读与理解能力很多人觉得写代码难其实读代码更难。在传统开发模式下你的主要任务是写代码。但在 Agentic Coding 模式下AI 写出大量代码之后你需要快速判断这些代码是否符合需求、是否存在隐患。这就需要很强的代码阅读能力。代码阅读能力包括快速理解函数的作用。追踪数据在代码中的流转。识别隐藏的副作用。判断异常处理是否充分。理解设计模式的应用。我建议每个开发者都养成一个习惯AI 生成的每一段核心代码都要自己读一遍读不懂的地方要追问、要查文档、要打断点调试而不是直接信任。3.3 调试与问题定位能力这是基本功中的基本功。AI 生成的代码一定会出错。这不是能力问题而是概率问题。大型语言模型根据概率生成代码难免会有逻辑错误、边界遗漏、API 误用等问题。当你拿到一段有问题的代码时如何定位问题我自己的排查顺序通常是这样先看报错信息定位是哪一行出的错。沿着调用链确认传入的数据是否合法。查看关键变量的值确认是否符合预期。缩小范围用一个最小示例复现问题。修复后再跑一遍完整测试。这套排查过程不依赖任何 AI 工具但它决定了你用 AI 时的效率。如果 AI 生成的代码一直报错你不会调试就只能反复把报错贴给 AI效率非常低。3.4 测试与验证能力Agentic Coding 时代测试能力的重要性被大幅提高了。原因很简单AI 生成代码的速度快但正确性需要验证。如果你不会写测试就没办法快速、自动化地验证 AI 的输出质量。很多同学会说“我可以让 AI 自己写测试呀。”没错AI 确实能写测试。但问题来了AI 写的测试可能和 AI 写的功能代码存在同样的错误假设。也就是说它可能从错误的逻辑出发写出的测试刚好验证了错误的实现。这时候就需要你自己来设计测试用例补充边界情况甚至要能判断“哪些测试是有意义的哪些是自欺欺人”。基本的测试能力包括能写单元测试覆盖正常流程。能测试边界条件比如空字符串、超长字符串、特殊字符。能测试异常路径比如重复注册、数据库连接失败。能阅读测试覆盖率判断薄弱环节。3.5 架构设计与代码组织能力AI 擅长生成函数、类和模块但它很难替你做全局规划。一个大型项目的架构风格、模块边界、依赖关系、错误处理策略、日志规范这些都需要人来决定。AI 只是在你的架构框架内帮助填充代码。如果基本功不够你很可能被 AI 的输出牵着走。AI 生成一个类你就加一个类AI 生成一种风格你就接受一种风格。最后项目变成一个大杂烩技术债越来越重。真正扎实的开发者会给 AI 设定边界明确哪些模块由 AI 生成哪些必须自己控制。明确统一异常处理方式。明确命名规范。明确事务边界。明确日志输出规范。3.6 安全意识与性能意识这两个意识往往被忽视但非常重要。AI 生成的代码在语义上可能是正确的但在安全和性能上可能存在隐患。安全方面常见问题包括SQL 拼接导致注入风险。密码明文存储。越权访问未校验。敏感信息写入日志。文件上传未校验类型。性能方面常见问题包括在循环中查询数据库。大量数据一次性加载到内存。缺少数据库索引。正则表达式死循环。使用 N1 查询模式。如果你不懂这些AI 生成的代码看起来跑得通但一旦上线轻则性能告警重则安全事故。4. 实战案例基本功如何提升 AI 协作效率下面我们通过几个实战场景看看基本功是如何实际影响 AI 协作效率的。4.1 场景一给 AI 一个清晰的问题描述我们先用一个 Python 函数来演示。假设你要实现一个函数把一个字符串中的手机号中间四位用星号隐藏。如果你直接问 AI写一个手机号脱敏函数。AI 可能会给出这样的代码def mask_phone(phone): return phone[:3] **** phone[7:]这个函数看起来没错但存在很多问题没有校验手机号长度。没有处理空值。没有校验是否真的是手机号。如果用户传入一个 11 位但不是手机号的字符串也照样脱敏。如果业务上手机号可能包含国家区号比如 86就会出错。但如果你的需求拆解基本功足够好你会这样描述请实现一个 Python 函数 mask_phone输入参数为手机号字符串。要求如果输入为空或 None返回空字符串。如果输入长度不是 11 位抛出 ValueError。只保留前 3 位和后 4 位中间 4 位用 * 代替。参数只接受字符串类型。AI 给出的代码就会严谨很多def mask_phone(phone: str) - str: if phone is None or phone : return if not isinstance(phone, str): raise TypeError(phone must be a string) if len(phone) ! 11: raise ValueError(phone length must be 11) return phone[:3] **** phone[7:]看到了吗同样的工具同样的模型需求的清晰程度决定了输出的质量。这不是 AI 能力的问题是你的基本功问题。4.2 场景二读懂 AI 生成的代码并发现问题下面是一段 AI 生成的 Java 代码片段用于从数据库查询用户列表。假设 AI 给出的代码如下// 文件路径src/main/java/com/example/demo/service/UserService.java public ListUser getUsersByAge(int age) { String sql SELECT * FROM users WHERE age age; ListUser users jdbcTemplate.query(sql, new UserRowMapper()); return users; }这段代码能跑吗能跑。但这显然存在 SQL 注入风险。如果你具备扎实的 SQL 基本功和安全意识你会立刻发现问题并改造成这样// 文件路径src/main/java/com/example/demo/service/UserService.java public ListUser getUsersByAge(int age) { String sql SELECT * FROM users WHERE age ?; ListUser users jdbcTemplate.query(sql, new Object[]{age}, new UserRowMapper()); return users; }改动很小但安全性完全不同。AI 能生成前一种写法是因为互联网上有大量不安全的示例代码。你的基本功就是识别并纠正这些问题的最后一道防线。4.3 场景三调试 AI 生成的代码这是一个非常常见的场景。AI 写了一段代码运行报错我们把例子简化一下。假设 AI 生成了如下 Python 代码def calculate_average(scores): total sum(scores) return total / len(scores)我们调用它scores [90, 85, 100] print(calculate_average(scores))输出结果91.66666666666667看起来没问题。但如果我们传入空列表呢scores [] print(calculate_average(scores))程序直接崩溃ZeroDivisionError: division by zero如果基本功扎实你就会知道除法运算前必须检查除数是否为 0。修复方式很简单def calculate_average(scores): if not scores: return 0 total sum(scores) return total / len(scores)这个例子很基础但它揭示了一个核心逻辑AI 生成的代码通常覆盖的是“正常路径”而边界条件的处理需要靠你的基本功去补充。在实际工作中AI 生成的代码可能比这个复杂得多比如处理分布式事务、消息队列重试、缓存穿透等问题。如果你连最基础的边界处理都意识不到就更不可能发现那些深层问题。4.4 场景四用测试验证 AI 的输出我们再来看一个测试的例子。假设你让 AI 实现一个判断闰年的函数AI 给出了如下代码def is_leap_year(year): return year % 4 0 and (year % 100 ! 0 or year % 400 0)这个实现是正确的。但你的任务不是直接信任它而是用测试用例来验证。如果你具备扎实的测试基本功你会设计这些用例import pytest def test_is_leap_year(): assert is_leap_year(2000) is True # 世纪年能被 400 整除是闰年 assert is_leap_year(2024) is True # 普通年份能被 4 整除是闰年 assert is_leap_year(1900) is False # 世纪年能被 100 整除但不能被 400 整除不是闰年 assert is_leap_year(2023) is False # 普通年份不能被 4 整除不是闰年运行测试pytest test_leap_year.py -v预期结果test_leap_year.py::test_is_leap_year PASSED这个测试用例集合就验证了 AI 输出在边界情况上的正确性。如果你没有一个“用测试验证代码”的习惯AI 生成的代码即使有问题你也很难第一时间发现。4.5 场景五重构 AI 生成的代码AI 生成的代码往往能实现功能但在可维护性上可能不够好。假设 AI 生成了一段代码用来处理订单状态流转def process_order(order, action): if action pay: order.status PAID order.paid_time datetime.now() send_notification(order.user_email, 支付成功) elif action ship: if order.status ! PAID: raise Exception(订单未支付不能发货) order.status SHIPPED order.shipped_time datetime.now() send_notification(order.user_email, 已发货) elif action complete: if order.status ! SHIPPED: raise Exception(订单未发货不能完成) order.status COMPLETED else: raise Exception(未知操作)这段代码功能基本正确但是所有逻辑堆在一个函数里可读性差扩展性也差。如果业务上要增加“退款”“取消”等操作这个函数会越来越臃肿。基本功扎实的开发者会考虑用状态模式或者至少拆分成独立函数class OrderService: def pay(self, order): order.status PAID order.paid_time datetime.now() send_notification(order.user_email, 支付成功) def ship(self, order): if order.status ! PAID: raise Exception(订单未支付不能发货) order.status SHIPPED order.shipped_time datetime.now() send_notification(order.user_email, 已发货) def complete(self, order): if order.status ! SHIPPED: raise Exception(订单未发货不能完成) order.status COMPLETED这个重构并不复杂但它体现了一个开发者对代码结构、职责划分、可维护性的理解。AI 可以帮你生成初始版本但让代码变得好维护、好扩展依然需要你的基本功。5. 常见问题与排查思路在学习和使用 AI 编程的过程中很多同学会遇到一些共性问题。这里我整理了一张排查表供大家参考。问题现象常见原因解决思路AI 生成的代码运行报错当前上下文不完整AI 基于错误假设编码检查报错信息补全缺失变量和方法缩小问题范围后重新提问AI 生成的代码能用但看不懂基础语法不熟缺乏代码阅读训练先拆解函数结构逐行理解多阅读开源项目源码逐步提升阅读能力AI 一直生成同一种错误写法需求描述中缺少约束条件在提示中明确禁止使用的 API、必须遵守的规范、边界条件项目越写越乱AI 改了一处又坏一处缺少架构边界和依赖管理先明确模块结构规定 AI 只能改哪些文件不允许改哪些文件自动化测试无法覆盖关键逻辑测试设计能力不足只测正常路径学会画测试矩阵正常分支、异常分支、边界值、空值、重复提交对 AI 生成结果盲目信任导致线上事故缺少代码审查和验证环节建立强制 Code Review 流程核心代码必须人工审查并补安全用例以“AI 生成的代码能用但看不懂”为例这里我多说几句。很多初学者在遇到这种情况时习惯性地选择跳过。但如果你真的想长期在编程这条路上走下去我建议你采用以下策略把 AI 生成的代码复制到编辑器里。逐行打断点观察变量变化。把不认识的语法或 API 单独查询。尝试在不改变功能的前提下用自己的方式重写一遍。这个过程可能会比较慢但它带来的提升是非常明显的。你会发现一旦你真正理解了一段代码后续使用 AI 的效率会成倍提高。6. 最佳实践与工程建议结合我自己的开发经验这里分享几条在 Agentic Coding 时代非常实用的工程建议。6.1 明确 AI 的职责边界在实际项目中不要把所有代码都交给 AI 生成也不要完全拒绝 AI。建议如下模板代码如 Controller 层增删改查、DTO 转换、简单的工具函数交给 AI。核心业务逻辑必须自己先设计清楚再让 AI 辅助实现。架构设计由人完成AI 只提供参考建议。异常处理和边界条件AI 生成后需要人工补充。测试用例AI 可以生成初版但核心用例必须自己设计和补充。6.2 建立代码审查习惯无论 AI 生成的代码多么顺眼都要经过审查。审查时重点关注业务逻辑是否与需求一致。是否存在越权、注入、敏感信息泄露等安全问题。是否存在明显的性能问题。异常处理是否完整。命名是否清晰结构是否合理。如果团队有条件建议强制要求所有 AI 生成代码也必须走 Code Review 流程。6.3 用测试保护 AI 重构AI 在重构代码时可能会引入隐藏问题。解决办法是在重构前确保测试覆盖率达到一定水平。这样 AI 重构后跑一遍测试就能发现大部分问题。这也是为什么测试基本功如此重要的原因。它不仅能验证你的代码也能验证 AI 的代码。6.4 持续做基础训练不要因为有了 AI 就放弃基础训练。我的建议是每周抽出时间不用 AI手写一个完整的业务模块。每周阅读一段开源项目源码写阅读笔记。每周练习一个调试场景尝试不用 AI 独立定位问题。每周做一次安全审查检查项目中是否有常见漏洞模式。这些训练会不断强化你的基本功让你在使用 AI 时更游刃有余。6.5 关注提示词设计但不迷信提示词提示词工程确实是提升 AI 输出质量的重要手段但提示词只是基本功的补充而不是替代品。如果你对一个技术领域没有基本的理解你再怎么优化提示词也很难准确判断 AI 输出是否正确。反过来如果基本功扎实即使提示词稍微差一点你也能快速发现并修正 AI 的错误。所以我的建议是把提示词优化看作基本功的自然延伸而不是独立技能。7. 总结与后续学习方向Agentic Coding 时代已经来了。AI 正在从一个“代码补全工具”进化成“能够独立完成开发任务的智能体”这确实会改变我们的工作方式。但正如吴恩达所说越是在这样的时代基本功越重要。工具越强使用工具的人的判断力就越关键。这篇文章中我重点讲了六项基本功需求拆解与问题定义能力。代码阅读与理解能力。调试与问题定位能力。测试与验证能力。架构设计与代码组织能力。安全意识与性能意识。还用 Python 和 Java 的示例演示了基本功如何直接影响 AI 协作效率。接下来你可以从这几个方向继续学习深入学习数据结构与算法这是所有基本功的底层支撑。学习数据库原理包括索引、事务、锁这对理解 AI 生成的数据库代码非常关键。学习设计模式提升代码组织能力。学习安全编程掌握常见 Web 漏洞的原理与修复方式。多参与实际项目在真实业务中打磨调试和测试能力。如果你也想在 Agentic Coding 时代保持竞争力我建议你从今天开始制定一个“基本功训练计划”每天留出半小时专门做基础练习。相信我这些时间投入的回报会超乎你的想象。如果这篇文章对你有帮助可以收藏备用也欢迎在评论区分享你使用 AI 编程时遇到的坑。我们下篇文章再见。