AI 时代，软件工程基础为什么更关键了
现在用 Cursor 这类工具写代码，流程大致是：描述需求，按几下 Tab，一个功能就跑起来了。代码不是自己逐行敲的，开发速度比以前快不少。
但有一个问题会逐渐浮现：当代码不再由你逐行产出，你怎么判断系统上线后不会出状况？
Andrew Ng 最近在 AI Engineering Skills Map 里梳理了一个判断：理解软件如何工作，正在成为你能不能用好 coding agent 的分水岭。
一个不懂软件基础、纯粹依赖 vibe coding 的开发者确实能搓出能跑的应用，但在你完全没意识到的维度上——延迟、可用性、一致性、可靠性、可维护性、成本和简单性——coding agent 会替你做出默认选择。你不知道这些选择存在，也就没法告诉 agent 应该往哪个方向偏。
问题不在 agent 本身，问题在于你不知道自己不知道什么。
下面五个方向，是 Andrew Ng 认为 AI 工程技能体系里当前最值得补强的软件工程基本面。
Agentic Coding 如何改变开发角色
agentic coding 的普及让过去分工明确的角色——前端专属、移动端专属——开始向全栈靠拢。
agent 能帮你补齐不熟悉的短板，前提是你对整个应用的全貌有概念。你不需要记住每个 API 的签名，但需要知道前后端之间有哪些组件在起作用：UI 组件、缓存机制、页面渲染方式、API 设计选型、认证逻辑、状态管理、会话控制、异步任务处理、数据持久化、测试策略、安全防护、无障碍支持。
这些不是要求你亲手写，而是当 agent 给出方案时，你能判断在当前用户规模和延迟要求下，这个选择是否合理。
数据管理：选错架构，AI 救不了你
数据值得单独拿出来讲。原因很直接：软件建在数据之上，数据架构一旦定型，比代码难改得多。agent 能帮你跑迁移脚本，但迁移带来的停机和数据一致性问题，agent 不会替你承担后果。
熟练的 AI 工程师在数据这件事上会做几层功课。
第一层，想清楚访问模式。 哪些查询最频繁？哪些字段读写比例是 10:1 还是 1:1？这些模式直接决定你存什么、存多久。
第二层，选对存储类型。 关系表、文档库、键值对、图数据库各有各的适用场景。选错了，速度、扩展性、可用性、可靠性、成本全部跟着跑偏。
第三层，理解事务、并发、数据一致性、数据新鲜度。 这些概念落实到具体业务场景里怎么取舍，需要你能提供上下文给 agent。
Andrew Ng 点了一个很关键的角度：AI 系统的输入上下文来自你的数据源。如果数据架构本身选得差，AI 根本不知道它自己不知道什么。它拿到的是歪的输入，输出不可能正。
数据生命周期管理、隐私合规、治理——这些东西在 AI 应用里只会更重，不会更轻。
另外有一个正在快速变化的领域：为 agent 构建数据基础设施，而不是只为传统软件或人类服务，目前还没有固定答案。这个领域的实践会持续更新，需要保持关注。
系统架构：合适的架构是移动靶
知道全栈有哪些组件、知道数据怎么管，接下来才真正开始搭系统。
好的系统设计从一组问题出发：这个软件要做什么？用户量级在什么范围？对延迟敏感还是对成本敏感？前后端边界划在哪里？系统怎么拆分？应用状态放哪？架构粒度选什么——单体还是微服务？
Andrew Ng 提到一个容易被忽略的点：合适的架构是移动靶。快速原型阶段最简单的设计，不一定是第一个生产版本该用的；第一个生产版本的设计，又不一定能撑到用户量翻十倍的时候。你需要有意识地评估当前处于哪个阶段，再做出对应调整，而不是一套架构打到底。
选技术栈这件事，现在可以让 agent 跑小实验来评估备选方案，但最终拍板仍然依赖于你对应用上下文的理解。
安全与可靠性：左移，再左移
可靠性不是上线后再补救的。
测试策略是第一道防线。 单元测试和集成测试怎么配比？用什么框架？覆盖率卡在多少？这些判断需要根据系统风险点来定，而不是照抄模板。
然后是失败设计。 假设你依赖的 API 今天开始限流，系统会怎样？Andrew Ng 提到的思路是：显式设计降级路径，控制故障的爆炸半径。这些逻辑可以在 agent 生成代码时以注释或约束的形式传给它，但前提是你脑子里有这个意识。
安全方面有一个明确的趋势：shift left，安全左移。 不是在软件写完后才让安全团队扫一遍，而是在开发周期早期就把安全考量加进来。现在的 AI 工具已经能帮你扫描代码里的漏洞、检查依赖项有没有供应链投毒风险、审查云配置是否存在攻击面。工具是放大镜，你得知道往哪看。
生产环境：部署、运维与扩展
最后一步，把软件交到用户手上。
部署涉及这些环节：环境配置、发布策略选哪种（灰度还是全量）、CI/CD 流水线怎么搭、IaaS 怎么理解。
上线之后是另一套工作：埋好可观测性工具、设好告警规则、定好故障响应流程。
扩展性方面，Andrew Ng 列了几条路径：理解真实负载、水平扩展服务器、负载均衡、数据层调优（分片、索引、复制），乃至必要时调整整体架构。
还有一类知识贯穿整个生命周期：版本控制怎么走、代码评审什么流程、依赖怎么维护、技术债务怎么管。这些在 agent 生成代码量越来越大的情况下，重要性反而更高了——管理代码的演进方向，最终是人的事。
操作清单
-
用 agent 写代码之前，先确认自己对当前模块的全栈组件有基本认知 -
选数据存储类型前，先列出 3-5 个最频繁的查询模式 -
每次架构决策时，记录当前阶段（原型/生产/规模化）和选型依据 -
为每个外部依赖设计降级路径，至少想清楚“如果这个挂了怎么办” -
部署前用 AI 工具扫一遍依赖漏洞和云配置风险 -
上线后第一天就配置好可观测性和告警 -
每个迭代周期留出 20% 时间处理技术债务和依赖更新
FAQ
Q：我现在用 vibe coding 写个人项目，也必须学这些吗？
如果你只做自己用的工具，不涉及用户数据和稳定性，可以不学。一旦要上生产环境、面向真实用户，这些就是选择题——要么你提前选好，要么 agent 替你默认选，后者的结果通常不是你想要的。
Q：数据架构选错了，agent 能帮我重构吗？
agent 能帮你写迁移脚本，但迁移期间的停服时间、数据一致性问题、新旧字段映射逻辑，这些决策需要你来做。而且迁移过程中如果数据模型改了，上层的 AI 应用输入格式也得跟着改，这是一串连锁反应。
Q：我不做运维，生产环境扩缩容这块怎么补？
不用从头学运维。从两个点切入：理解你的应用当前每秒处理多少请求，以及数据库连接池、缓存命中率、API 响应时间这三个数字。看懂这三个指标，你就知道什么时候该扩容、什么时候该调索引了。
Q：安全左移具体怎么移？
原来安全团队在代码写完后才介入，现在你在写代码阶段就做两件事：用 SCA 工具扫依赖库漏洞，用 SAST 工具扫代码里的硬编码密钥和 SQL 注入风险。这些工具现在大多有 AI 加持，扫一遍几分钟的事。
Q：架构是移动靶，我怎么知道什么时候该重构？
Andrew Ng 给的判断维度：用户量级变化一个数量级、延迟要求变了、成本结构变了，这三条任意触发一条，就该重新评估当前架构是否还合适。不需要主动重构，但要主动评估。
Q：这些基础现在学还来得及吗？
不用从头啃《计算机组成原理》。按上面五个方向，每个方向找一份实操指南，一边用 agent 写代码一边补对应的判断依据。agent 负责写，你负责判断写出来的东西对不对，这是目前最有效的分工方式。
