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 生成的文件可以属于我的项目，但不会自动转化为我的能力。
技术真正被掌握，至少需要做到以下几点：
如果这些都做不到，我获得的只是一次生成结果，而不是可以迁移到下一个项目的能力。
三、大模型越强，开发者的优势到底在哪里？
随着模型能力提升，“做出一个能运行的 Demo”正在变得越来越容易。
一个不会写代码的人，只要能说清目标，也可以借助最新模型和 Agent 完成很不错的原型。如果开发者的优势只是“比别人更会写提示词”，这种优势会迅速缩小。
但 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 开发的验收标准从“能运行”提高到：
八、总结
AI 并没有让基础知识失去价值，它只是改变了基础知识发挥价值的方式。
过去学 Python、数据库和网络，可能更多是为了亲自实现功能；现在学这些，还是为了审核 AI 的实现、设计可靠的系统，并在问题出现时做出正确判断。
AI 降低了执行的门槛，却提高了判断的价值。
所以我决定暂时放慢一点，把那些只是“听说过”的概念，真正变成自己能够解释、实现和验证的能力。
