Agentic Coding 最近讨论得很多。这个方向的核心不是“给个单词补全一行代码”，而是让 AI 从一个自然语言任务出发，自行规划、查资料、改代码、跑测试、按反馈迭代。很多人看到的第一反应是：程序员是不是可以少写代码了？但吴恩达那个流传很广的判断——Agentic Coding 时代基本功更重要——恰恰指向相反的方向。为什么工具更强了，反而更要求基础能力？因为 Agent 只是执行层，规划、验收、纠偏、兜底仍然在人的手里。工具把可编码的劳动逐渐外包出去之后，剩下的那部分工作，几乎全是判断工作。这篇文章想把这个观点拆开讲：基本功到底指什么、为什么在 Agentic Coding 下变重要、怎么在日常工作中持续练、以及如何自查。
1. 为什么 Agentic Coding 越热，越要回头补基本功
1.1 Agentic Coding 到底改变了什么
Agentic Coding 和传统 IDE 补全最大的区别，在于 AI 不再是“跟着你的输入补出下一段”，而是从任务层面接管一段完整工作流。比如你告诉它“把这个服务里的订单导出逻辑改成支持批量查询，并补上超时处理”，它会去读相关文件、理解现有实现、生成修改、跑测试、把结果汇报回来。
这带来一个直接变化：程序员的一部分工作，从“写代码”变成了“给任务、看结果、纠偏差”。从效率上看，这是好事。重复性编码、样板代码、接口包装、测试补全，都适合交给 Agent 做。但问题也在这里：当 AI 能自动完成越来越长的执行链时，链条里的每个判断点，仍然需要人来把关。
Agent 可以告诉你“我已经改完了”，但它不能替你判断“这处改动是否符合业务预期”“是否会破坏兼容性”“失败重试是否会把幂等性打破”“错误日志是否足够定位线上问题”。这些判断，全部依赖基本功。
我举一个简单的例子。你让 Agent 优化一个列表查询接口，它可能会把原来的同步查询改成异步，让接口响应时间看起来变好了。但是如果调用方依赖查询完成后的缓存更新结果，这个优化就会在特定场景下引入脏数据。能看出这个风险的人，一定对数据流、接口契约有基础理解，而不是只会看运行结果。
1.2 工作流变了，但验收、责任、边界没有消失
传统编码里，基本功体现在“你亲手写出来的代码质量”。Agentic Coding 时代，基本功体现在你是否能识别 AI 生成代码里的风险点。
我见过不少团队引入 AI 编程工具后，前两周效率提升明显，第三周开始出现线上问题。问题几乎都不是“代码写不出来”，而是“代码太容易写出来了”。有人把需求描述得不精确，AI 生成了逻辑错误但看起来结构完整的代码；有人没有补测试，重构后行为悄悄变了；有人不理解现有模块的数据流，让 AI 贸然改了核心函数，影响面完全失控。
这些都是基本功问题。不是语法不会，而是对系统的理解不够，对验证流程不够重视，对责任边界没有建立清楚。
我一般会这样看：Agent 是一个能力很强、但没有领域常识和执行记忆的新同事。你带一个新人，不会因为对方 Python 写得好就让他直接改核心支付模块，至少要先让他读代码、画数据流、写测试，确认行为后再说。对 Agent 也应该保持同等的确认习惯。
传统编码和 Agentic Coding 的关键差异，可以简单对比一下：
| 环节 | 传统编码 | Agentic Coding |
|---|---|---|
| 需求理解 | 人 | 人 |
| 代码生成 | 人 | AI 为主，人审查 |
| 代码理解 | 人 | AI 辅助，人负责 |
| 验证 | 人 | 人主导，AI 辅助 |
| 问题定位 | 人 | AI 尝试，人兜底 |
| 最终责任 | 人 | 人 |
所以，编码这件事不会因为 Agent 加入就失去对基本功的要求，它只是把要求从“会写”转移到了“会判断”。
关键判断：AI 工具让“写出代码”变得便宜，让“判断代码是否正确”变得昂贵。越便宜的环节越容易替代，越贵的环节越需要基本功。
2. 基本功不是背语法，而是“读懂代码”和“验证代码”
很多程序员把基本功等同于背 API、熟练语法、会写算法题。这些在 Agentic Coding 时代的重要性其实在下降，因为 AI 的语法和 API 记忆比人强。真正无法外包的，是读懂代码和验证代码。
2.1 读懂代码：给 AI 下指令的前提
让 Agent 修改一个模块，前提是你能把需求描述清楚。什么是“描述清楚”？不是只说“把订单模块优化一下”，而是说清楚：入口在哪里、当前用的哪个查询方法、返回格式是什么、兼容哪些调用方、优化后允许什么行为变化、不允许什么变化。
这些信息从哪里来？从读代码里来。如果你看不懂现有模块的数据流，看不懂接口的依赖关系，你就写不出这样的提示。AI 再强，也只能按照你的描述去行动；描述模糊，它就只能猜，猜出来的代码表面完整，但往往埋着坑。
所以 Agentic Coding 时代，第一基本功是读代码，尤其是快速理解一个陌生模块的能力。我会用几个问题检验自己是否真的读懂了：
- 这个模块的输入和输出分别是什么？
- 它被哪些服务或页面调用？
- 数据从哪里来，经过哪些处理，最后落在哪里？
- 如果某个字段为空，会发生什么？
- 如果并发量翻十倍，瓶颈在哪里？
能用几句话回答这些问题，才具备给 Agent 下准确指令的基础。
2.2 验证代码：能跑通不等于能上线
AI 生成代码有个显著特征：结构完整，看起来合理，单测可能也过，但边界处理经常不到位。典型例子包括：日期边界、空数组、超时后的状态、重试时的幂等、敏感信息是否打进日志、异常时资源是否释放。
这些都不是语法问题，而是工程判断问题。要拦截这些问题，必须建立验证习惯。
我的建议是，任何 Agent 生成的代码，至少在四个层面过一遍：
- 功能层面：核心路径是否符合需求。
- 边界层面：空值、超长、重复、并发、异常分支。
- 集成层面：改动是否影响调用方，接口契约是否变化。
- 运维层面：日志是否足够定位问题，是否有监控指标，失败是否能恢复。
如果一个程序员能够熟练补齐这些验证，他就能把 AI 的效率放大很多倍；如果验证能力缺失，AI 产出的代码会变成一台制造线上问题的机器。
2.3 定位问题：AI 输出报错时的兜底能力
Agentic Coding 工作流里，最常出现的情况是：Agent 改了代码，测试报错，Agent 尝试修复，又报了另一个错。这时真正决定效率的，是你能否快速定位根因。
我会按这样的顺序排查：先看第一个报错是不是由改动引起，再回退到最小范围，确认输入输出，再看依赖、环境、权限这些外围因素。这个顺序就是基本功。
如果基本功不扎实，常见处理方式是让 AI 反复“再试一次”。生成、报错、再生成、再报错，循环几次后不仅浪费时间，还可能把原本正确的代码改坏。更稳的做法是，把你看到的报错、当时的输入、预期输出整理清楚，给 AI 一个完整的上下文，而不是只说“报错了帮我修”。
这一层能力，恰恰是 AI 无法替你建立的，因为它需要你对真实系统有理解。
3. Agentic Coding 时代，真正需要练的是工程判断力
3.1 任务拆解与指令表达基本功
Agent 再聪明，也需要有人把大任务拆成可执行的小任务。任务拆解能力，本质上是对产品和系统理解能力的体现。
举个例子，做一个“导出每月订单报表”的功能。如果你直接让 AI 写，它可能很快生成一套代码，但往往漏掉以下几点：时间范围按什么时区计算、是否包含退款订单、大文件是否需要分页导出、失败时是否支持重试、导出权限怎么控制。真正有经验的开发者，会先把这些决策点理清楚，再把任务拆成“数据查询”“报表生成”“文件存储”“通知用户”几个小步骤，分步给 Agent 执行。
所以任务拆解不是把自然语言细分，而是把业务逻辑、技术约束、验收标准一起写清楚。做得好的人，给 AI 提出的不是一个模糊愿景，而是一份可验收的开发说明。这也是一种基本功，而且比背 API 更难练。
一个相对完整的提示，可以参考这样组织：
任务：把订单导出功能改成支持按时间范围批量查询。 背景： - 当前实现每次导出只查单天，调用方在 service/order_export.py。 - 数据库表 order 使用 create_time 分区，按天分区。 约束： - 时间范围采用东八区，默认最近 7 天。 - 退款订单默认排除，提供参数可以包含。 - 导出文件超过 5 万行时按日期拆分成多个文件。 - 失败时支持重试，重试不影响幂等。 - 需要补核心路径和异常分支测试。这种描述方式，已经把大多数决策点暴露出来了。AI 生成的结果更可控，后续验收也更容易。
3.2 什么时候让 AI 写，什么时候自己动手
基本功的另一种体现，是知道边界在哪。不是所有代码都值得用 AI 手写，也不是所有代码都应该交给 AI。
对于一次性脚本、原型验证、样例代码、低风险模块，让 Agent 生成很合适。对于核心业务链路、高频变更、对性能和资源敏感的地方、涉及资金和安全逻辑的模块，我通常会让 AI 做辅助生成，但设计、关键逻辑、测试策略必须自己把握。
这里有一个比较容易踩的坑：AI 写出来的代码看起来简洁优雅，但不一定符合你的工程约束。比如它可能忽略既有代码风格，可能引入一个间接依赖，可能选择了一个你不想用的第三方库。基本功好的开发者，会在保留 AI 效率的同时，把约束明确写进提示里，并且审查最终产出。
3.3 质量兜底：评审、测试、监控和日志
Agentic Coding 并不意味着“交给 Agent 就不需要 review 了”，反而更需要 review。因为 AI 产出的代码，你至少要能看懂、能解释、能在出问题时恢复。
质量兜底可以从几件事做起：
- 要求 AI 生成代码的同时补测试，至少覆盖核心路径和异常分支。
- 对改动过的模块，跑一遍原有测试，观察是否有行为变化。
- 在代码审查中，坚持按“数据流是否清晰、错误处理是否完整、日志是否可定位”来提问。
- 上线前确认监控和告警，而不是只看“能跑”。
这些都是老生常谈，但当 AI 生成代码成为常态后，它们会重新变成稀缺能力。因为愿意做、能做、能做对的人反而少了。
4. 用一套可复现的方法，在 AI 工作流里练基本功
聊完原因，说点能落地的训练方法。基本功不是靠看文章补回来的，要靠固定节奏的练习。
4.1 第一步：从真实项目里挑一个模块做复盘
我建议每周挑一个现存模块，做一次深度复盘。步骤很简单：
- 不看 AI，自己先读一遍代码。
- 画一张简单的数据流程图，标出输入、处理、输出、依赖。
- 记录你认为有风险的地方，比如隐藏状态、可变参数、异常处理缺失。
- 让 Agent 生成一个替代实现。
- 对比你自己的理解和 AI 实现，找出差异，复盘为什么会产生差异。
这套动作核心不是比较谁写得好，而是训练“读懂系统”和“识别风险”两种能力。做够十次之后，你给 AI 下指令的质量会明显提升。
4.2 第二步：每天留一段“无 AI 重建”时间
我理解很多人在工作中已经离不开 AI 工具，但可以用一种“无 AI 重建”的方式来练基本功。选一个你以前写过的功能，关掉 AI，手动重写一遍。重点不是重新发明轮子，而是重新走一遍完整流程：从需求理解、数据设计、函数拆分、测试编写到日志补充。
这个过程能暴露基本功空缺。如果你发现自己脱离 AI 后连一个清单任务都拆不清楚，说明之前依靠工具完成了太多“表面工作”。这时补的不是语法，而是系统思考能力。
时间不用太长，每天 30 到 60 分钟就够。关键是持续。
4.3 第三步：建立错误案例库，记录定位链路
基本功扎实与否，很多时候体现在“遇到没见过的报错怎么处理”。有一种长期有效的训练方法：每次遇到一个难缠问题，把报错信息、触发条件、定位过程、根因、修复方案记录到自己的笔记里。
不要只记“解决了”，要记“怎么定位到的”。比如：
- 是依赖版本问题还是运行环境问题？
- 是通过日志发现的还是通过对比代码发现的？
- 如果再遇到一次，第一步会先查什么？
这个案例库积累到一定数量，就是你判断 AI 修改是否正确的重要依据。你会发现很多 Agent 生成的“合理修改”，实际上在重复历史上已经踩过的坑。
4.4 第四步：代码审查回到“人读代码”模式
现在很多团队用 AI 做代码审查，这没问题，但别完全替代“人读”。我会建议每个改动至少有一次真人 review，标准不是“有没有 bug”，而是“如果三个月后这个模块出问题，接手的人能不能看懂”。
你在 review 时，也可以故意让 AI 生成一个不那么符合规范的版本，然后手把手修正。用这个方式来训练自己识别顺序问题、命名问题、错误处理缺失的能力。
5. 基本功过不过关，用这五个自查点判断
5.1 自查点一到五
我不太建议用“能不能背出某个 API”来测试基本功，更有效的判断标准是：
- 能否在没有 AI 的情况下，向团队讲清楚一个陌生模块的数据流和关键风险？
- 能否在 15 分钟内定位一个“看起来像 AI 改坏”的问题，并给出最小修复？
- 能否给 AI 写一份包含需求、边界、验收标准的提示，而不是一句“帮我优化”？
- 能否在 AI 生成的代码中，快速指出至少一个边界或异常处理遗漏？
- 能否在 AI 反复修复失败时，主动说“我先回退到改动前，重新确认输入输出，再动手”？
前四条很好理解，第五条尤其重要。这是判断你有没有基本功兜底的标志：你能够主动打断无效循环，回到最小可控状态，而不是让 AI 在错误方向上越走越远。
5.2 遇到问题时的排查顺序
如果你在 Agentic Coding 工作流里遇到问题，建议按下面的顺序排查：
- 先看输入。给 Agent 的描述是否完整，字段、边界、预期结果是否明确。
- 再看差异。对比 AI 改前和改后，哪些文件变了，哪些逻辑被替换了。
- 再看测试。核心路径有没有测试，报错是功能问题还是环境问题。
- 再看运行环境。依赖版本、配置、权限、外部服务是否正常。
- 最后回到代码。逐行理解改动的真实含义，再决定保留还是回退。
这个排查顺序一旦养成习惯，你会少很多无效尝试。很多 Agent 生成代码导致的问题，根源都是第一步输入没描述清楚，结果在第二步、第三步反复绕圈。
6. 边界提醒：基本功重要，不等于拒绝 AI 和手写一切
6.1 基本功的价值在于用好工具，不是替代工具
强调基本功，并不是让你拒绝 AI 工具，更不是回到“所有代码都要手写”的原教旨状态。恰恰相反，基本功好的开发者，能更快识别 AI 的优缺点，把它用在最适合的位置。
比如你懂数据流和错误处理，你就知道哪些模块适合让 AI 先出第一版，哪些必须自己主导设计。你懂测试和日志，你就知道怎么要求 AI 补测试、补日志，让产出更接近可上线状态。基本功是放大器，不是替代品。
6.2 别掉进“基本功原教旨主义”的坑
另一种误区是，因为有人强调基本功，就否定 AI 工具的价值，甚至觉得用 AI 写代码是不专业。这种观点同样有问题。
工具迭代是不可逆的。初学者完全可以用 AI 做脚手架，这没有任何问题；关键是搞清哪些部分必须自己掌握。如果只停留在“AI 写了就行”，长期看风险很高；如果完全拒绝工具，则会在效率上吃亏。正确做法是找到一个稳定的训练节奏，把基本功和 AI 使用结合起来。
6.3 适合放开让 Agent 做的任务长什么样
最后给一个更具体的边界判断。我自己比较愿意交给 Agent 的任务，通常满足这几个条件：
- 一次性或低风险，出错影响可控。
- 输入输出非常明确，不需要大量隐藏业务知识。
- 代码量中等，生成后我能快速 review 完。
- 自动测试覆盖充分，行为变化可以被及时发现。
反过来，涉及核心数据、资金、安全、多系统协作、旧代码兼容、高并发性能的关键模块，我会把设计把握在自己手里，AI 只做实现辅助。
这样既能享受效率红利，又不会把工程质量完全交给一个没有领域常识的工具。你可以从今天开始，挑一个旧模块做一次复盘，把它的数据流和风险点写清楚，再让 Agent 试着改一遍。连续做一个月，你会发现，自己对这个工具的判断力，比单纯用工具写一千行代码更值钱。
