AI 时代为什么还要学编程基础？从 Agent 依赖到 AI 应用工程能力

本文是一次个人学习反思：当 Agent 已经能完成需求分析、编码、测试和修复时，开发者为什么还要学习 Python、后端、数据库和大模型基础？我的结论是：AI 降低了生成代码的门槛，却没有替我们完成理解、判断、验证和负责。

一、我从“用 AI 开发”变成了“等 AI 交付”

我算是一个 AI 高度依赖者，每月使用量可以达到 200 多亿 Token，高峰时一天会消耗近 10 亿 Token。

这不是在展示我有多会使用 AI，而是说明一个背景：AI 已经深度进入了我的开发流程。

我现在开发一个项目，往往只需要：

找一个开发 Skill
    ↓
把想法和约束交给 AI
    ↓
让 Agent 制定目标和计划
    ↓
Agent 自动开发、测试、修复
    ↓
获得一个可运行的项目

流程越来越高效，但我对项目的理解却越来越少。

以前 AI 帮我写完代码后，我还会打开文件看一遍。后来 AI 连测试和修复都能一起完成，我开始只关心最终结果能否运行。

最后就出现了一个很奇怪的状态：

• 项目在我的电脑上。
• 代码也提交到了我的仓库。
• 但我无法讲清架构、数据流和关键技术取舍。
• 一旦脱离 Agent，我甚至不知道该从哪个文件开始修改。

这已经不是“AI 帮我开发”，而是“AI 完成了开发，我等它交付”。

二、AI 生成的项目，为什么还不算我的能力？

更准确的说法是：AI 生成的文件可以属于我的项目，但不会自动转化为我的能力。

技术真正被掌握，至少需要做到以下几点：

1. 能解释系统的核心流程。
2. 能理解关键设计背后的取舍。
3. 能判断 AI 给出的方案是否可靠。
4. 能在出错时定位原因，而不是只会重新生成。
5. 能对性能、安全、成本和维护性负责。

如果这些都做不到，我获得的只是一次生成结果，而不是可以迁移到下一个项目的能力。

三、大模型越强，开发者的优势到底在哪里？

随着模型能力提升，“做出一个能运行的 Demo”正在变得越来越容易。

一个不会写代码的人，只要能说清目标，也可以借助最新模型和 Agent 完成很不错的原型。如果开发者的优势只是“比别人更会写提示词”，这种优势会迅速缩小。

但 Demo 和可靠软件之间，仍然有明显差距：

Demo 阶段	真实应用阶段
完成一次正常调用	处理超时、重试、限流和降级
少量手工测试	自动化评测、回归测试和可观测性
模型能返回答案	答案有引用、可溯源、可验证
工具能被调用	工具有权限、参数校验和错误边界
项目可在本机运行	可部署、可监控、可维护、成本可控

因此，AI 时代的开发者不一定要逐行手写所有代码，但必须有能力判断代码是否正确，以及系统能否稳定运行。

基础知识正是这种判断力的来源。

四、AI 应用开发到底需要掌握哪些基础？

如果目标是 AI 应用开发，重点不是一开始就训练大模型，而是能将模型做成可靠的软件。

4.1 Python 与后端工程

需要掌握：

• Python、类型标注、异常处理和模块化。
• async/await、并发、网络请求。
• FastAPI、Pydantic、REST API。
• SQL、PostgreSQL、Redis 基础。
• Git、Linux、Docker、pytest。

这些知识最终应该组成一条完整链路：

接收请求 → 校验参数 → 调用模型
→ 保存结果 → 处理异常 → 返回响应

4.2 大模型基础

不一定要一开始就手写 Transformer，但需要理解：

• Token、上下文窗口、Temperature。
• Prompt 与消息角色。
• Embedding、Transformer 和 Attention 的基本原理。
• 流式输出、超时、重试与限流。
• Function Calling / Tool Calling。
• 结构化输出和 JSON Schema。

这些概念能帮助我解释：为什么模型会丢失上下文，为什么会产生幻觉，为什么输出会不符合约定格式，以及为什么 Token 成本会突然上升。

4.3 RAG

RAG 不是只调用一个向量数据库 API，完整链路至少包括：

文档解析
→ 文本分块与元数据
→ Embedding
→ 关键词 / 向量 / 混合检索
→ Rerank
→ 上下文组装
→ 带引用的答案
→ 检索与生成评测

还需要理解 Recall@K、MRR、忠实度和答案相关性等评估思路。否则，系统虽然“接了 RAG”，但无法知道检索是否找对资料，答案是否忠于来源。

4.4 Agent 与工作流

使用 LangGraph 等框架不难，难的是理解框架之下的运行机制：

• ReAct、Plan-and-Solve 等基本模式。
• 工具注册、参数校验和权限边界。
• 多步骤编排、状态管理和记忆。
• 重试、回滚、超时和幂等性。
• 死循环防护和 Token 预算。

如果只会给 Agent 一个目标并让它持续运行，就很容得到一个成本不可控、失败后难以恢复的系统。

4.5 AI 工程化

真正决定 AI 应用能否上线的，往往是模型调用之外的部分：

• Prompt、模型和数据集版本管理。
• Trace 和完整调用链记录。
• Token、延迟、错误率和成本统计。
• 离线评测与回归测试。
• 缓存、降级、批处理、Prompt 注入防护和敏感信息保护。

这些能力决定了问题出现时是否能回放请求、找到退化原因，以及更换模型或 Prompt 后效果是变好还是变差。

五、AI 应用岗和算法岗的学习路线不同

学习之前还需要区分目标。

AI 应用开发

数学先掌握足够理解应用的部分：

• 线性代数基础。
• 概率与统计基础。
• Cosine Similarity。
• Precision、Recall、F1。
• LoRA 和量化的用途。

学习重点是后端、模型 API、RAG、Agent、评测、可观测性与部署。

算法或模型训练

如果目标是算法岗，则需要继续深入：

• PyTorch、机器学习与深度学习。
• Transformer 源码和训练原理。
• 微调、预训练与分布式训练。
• CUDA、推理加速与模型优化。

对我当前的 AI 应用开发方向，更合理的顺序是：

Python / FastAPI
→ LLM API
→ RAG
→ Agent
→ Trace 与评测
→ Docker 部署

六、21 天重建基础：不追求掌握全部，先完成最小闭环

我为自己设定的第一个阶段是 21 天：

时间	学习内容	阶段输出
第 1 周	Python、类型标注、异常、文件处理、异步	一个可测试的 Python 小程序
第 2 周	FastAPI、Pydantic、REST API、SQLAlchemy	一个带参数校验和数据持久化的 API
第 3 周	PostgreSQL、pytest、Docker	一个可通过 Docker 启动的 AI 实验管理 API

21 天并不能让人熟练掌握这些技术。这个计划的作用是恢复一个最小完整链路，让后续学习 RAG 和 Agent 时不再只是跟着教程调 API。

判断自己是否学会的标准，也不是“视频看完”，而是能否独立完成：

接收请求
→ 校验参数
→ 写入数据库
→ 调用模型
→ 记录结果和 Trace
→ 处理异常
→ 编写测试
→ Docker 启动

这条链路可以继续扩展为一个更完整的 AI 应用工程项目：

用户提问
→ 检索资料
→ Agent 调用工具
→ 模型生成答案
→ 记录 Trace
→ 自动评测
→ 展示质量、延迟和成本指标

七、不需要停用 AI，需要改变验收标准

学基础不等于拒绝 AI，也不等于所有代码必须手写。

问题不是“代码是不是 AI 写的”，而是“我是否对这些代码有足够的理解和控制”。

我准备将 AI 开发的验收标准从“能运行”提高到：

1. 我能用自己的话讲清架构和核心数据流。
2. 我能解释关键方案为什么这样选。
3. 我能为主要失败场景设计测试、超时和降级。
4. 我能通过日志和 Trace 回放问题，而不是只会要求 Agent 重写。
5. 我能说清这个系统的准确性、成本、安全和维护边界。

八、总结

AI 并没有让基础知识失去价值，它只是改变了基础知识发挥价值的方式。

过去学 Python、数据库和网络，可能更多是为了亲自实现功能；现在学这些，还是为了审核 AI 的实现、设计可靠的系统，并在问题出现时做出正确判断。

AI 降低了执行的门槛，却提高了判断的价值。

所以我决定暂时放慢一点，把那些只是“听说过”的概念，真正变成自己能够解释、实现和验证的能力。