AI 时代，为什么还要学编程基础？

能做的事	没基础的人	学过基础的人
让 Claude 写一个 RSS 抓取器	✅ 能	✅ 能
看懂 Claude 写的 `Promise.allSettled` 在干嘛	❌ 只能盲信	✅ 知道是“并发抓取且容错”
判断方案合不合理	❌ Claude 说啥是啥	✅ 能反驳“这里该用流式而非全量”
Bug 出现时定位现象	❌ 说不清是网络/逻辑/数据问题	✅ 能说“是 RSS 解析阶段挂了”
知道哪些需求技术上不现实	❌ 容易提一堆做不出来的需求	✅ 能在需求阶段就排掉坑

你细品一下就发现：有基础的人用 AI，是把判断力放大了几十倍；没基础的人用 AI，相当于闭着眼睛接一个黑盒的输出，运气好能用，运气不好光剩撞墙。

前段时间同事让 AI 帮忙写了个批量处理文件的脚本，跑完发现少了一大半文件，他盯着日志半天只憋出一句“它好像没全部处理”。如果稍微懂点异步和错误处理，就能直接问：“你是不是用错方法了，是不是哪个异常被静默吞了？”——找准问题再让 AI 修，效率天差地别。

二、Python / 前端知识到底起什么作用

不学基础，这些知识在你眼里可能只是一堆关键字；学了基础，它们就变成了你指挥 AI 的“手刹和方向盘”。

1. 能看懂方案，能反驳

比如 AI 跟你说“这里用 Promise.allSettled ”，你不懂的话就直接点确定。

但如果看过一丁点 JS 基础，马上就能反应过来：allSettled 的意思是“即使一个源挂了，其他源还能正常返回”；如果 AI 哪天悄悄给换成了 Promise.all（任何一个失败全挂），你也能一眼揪出来。

拿代码说话：

JavaScript

// AI 给的方案 —— 并发抓取，单独失败不影响全局
const results = await Promise.allSettled([
  fetchRSS('https://source1.com/feed'),
  fetchRSS('https://source2.com/feed'),
  fetchRSS('https://source3.com/feed')
]);
// 你能读懂这里：每个源独立，拿到的 results 里有 status 字段区分成功/失败

JavaScript

// 某天聊天上下文丢失，AI 换成了这个
const results = await Promise.all([
  fetchRSS('https://source1.com/feed'),
  fetchRSS('https://source2.com/feed'),
  fetchRSS('https://source3.com/feed')
]);
// 有基础的人：等下，all 的话任何一个源网络抽风，整个功能就瘫痪了，赶紧改回来

2. 描述现象准确，不用死磕代码行

基础好的开发者跟 AI 对话，很少上来就问“这段代码哪里错了”，而是先描述现象：

“现在是 3 个源只有 1 个返回了数据，另外 2 个好像超时了，看日志 ETIMEDOUT。”

要说出这句话，你得知道“源”是什么、“超时”属于网络层的问题、日志里那个错误码大概代表什么——这些都是基础。

3. 校验输出，不当甩手掌柜

让 AI 写完 RSS 抓取器你跑起来，输出 35 条新闻。对不对？格式乱不乱？有没有重复标题？没基础你连对错都掂量不出来。

我一个朋友让 AI 写了个日报汇总系统，跑了一个月才发现日期排序全是乱的，因为 AI 把日期当成字符串排了。要是见过 new Date() 和字符串比较的坑，瞟一眼输出就知道了。

4. 架构判断，不被 AI 带节奏

你肯定听过“杀鸡别用牛刀”这句话。架构就是选型 + 取舍，全建立在基础上。

比如日报系统，存数据库还是存 Markdown 文件？AI 可能会给出一个看着很高级的 PostgreSQL 方案，但如果你了解数据库运维成本和实际场景，马上就能判断：一个个人用的日报，用文件存储反而更轻量，省得折腾环境。

三、学习重心确实要变

既然基础的价值变了，学法也得跟着变。

以前的学法（不太适合现在）

死记 Python 语法、背 React 生命周期
刷算法题刷到吐
目标是“能手写一切”

现在更适合这么学

读得懂 > 写得出：能看懂主流代码在干什么，远远胜过自己能默写。你不需要徒手撸一个 Promise 实现，但你要能一眼认出 async/await 和回调地狱的区别。
概念优先于语法：先搞清楚“什么是异步”“什么是状态管理”“什么是数据库索引”，再去接触具体写法。比如你知道索引是给查询加速的，那就算不记得 CREATE INDEX 的精确语法，也能指挥 AI 加索引。
从项目反推知识：遇到 Promise.allSettled 不懂就去查，比从头刷 JS 教程高效十倍。做日报时遇到文件读写权限问题，顺带把 Linux 权限模型学了，驱动式学习反而记得牢。
架构思维在做项目里养：不是上来就学设计模式，而是做着做着自然会问：“这块为什么这么拆？为什么这里要加缓存？”这时候让 AI 解释设计动机，比自己硬啃《架构整洁之道》上头多了。

四、可执行的行动建议

如果你现在正在用 AI 辅助开发，下面几条可以直接落地：

每个由 AI 生成的文件，都要求它解释一遍
对着 fetcher.ts 问：“这个文件的设计模式是什么？每个函数的职责是什么？错误处理是怎么设计的？”别只当代码接收器，要当代码审阅者。
故意改一改试试
想加一个 RSS 源就动手加，挂了再问 AI，比看 10 集教学视频学得都快。亲手踩的坑，基础才长在肉里。
关注“为什么”而不是“怎么写”
别问“怎么写一个并发限流”，要问“为什么这里要限流？如果不限流会有什么后果？”，然后让 AI 给你画图解释。
架构感靠看别人项目练
去 GitHub 找 1-2 个 star 多的 AI 应用仓库，让 AI 带你逛一圈目录，解释每个目录的职责、技术选型的考量，很快你就能建立起项目全局观。

面试常见问题醒醒脑

面试官：“如果让你设计一个支持多源抓取的 RSS 阅读器，你会怎么处理不同源的错误隔离？”

这种题就是在考你基础知识迁移能力。没基础的人可能说“加 try-catch 就行了”，有基础的人会分析：用 Promise.allSettled 做并发控制、用队列管理超时重试、对不稳定的源做降级处理——每个点都对应一个基础知识块。

五、和课程观点的关系

很多课程里都强调一个核心理念：“信任但验证”，放到 AI 辅助开发里尤其重要。

可以把协作过程拆成四个节点，每个节点都需要基础托底：

节点	你要做的事	需要的基础能力
方案阶段	仔细看方案，大方向是否正确	能判断技术选型合理性
编码阶段	扫文件结构，框架是否清晰	能识别常见架构模式
运行阶段	检查输出是否符合预期	知道“正确输出”长什么样
改进阶段	测试边界场景（空数据、超时、异常）	能预想哪些场景容易出错