第一篇:AI 写代码之后,软件工程师到底该学什么?

第一篇：AI 写代码之后，软件工程师到底该学什么？

我见过一个很典型的项目。

团队想做一个“导出报表”的小功能，本来估半天。有人把需求丢给 AI：加一个导出按钮，支持 CSV。二十分钟后，代码真的出来了。按钮有了，接口有了，文件也能下载。

但接下来一看，麻烦全在后面。

权限没接上，普通成员也能导出全量数据；大数据量会把接口打爆；CSV 里没有处理换行和逗号；测试只覆盖了一个 happy path；产品原来想要的是“当前筛选条件下的导出”，AI 写成了“导出全部”。

最尴尬的是，没人能说 AI 没干活。它确实写了很多代码。

问题是：它完成的是“文字里的任务”，不是“系统里的交付”。

这就是我想写这组 CS146S 连载的原因。Stanford CS146S《The Modern Software Developer》公开课程把 AI 辅助开发放进完整软件交付链路里讲，而不是只讲某个工具怎么用。课程公开页面显示，它是 2025 年秋季课程，3 学分，围绕 Coding LLM、Agent、AI IDE、测试、安全、上线后支持和未来开发者角色展开。
[1]

我会把它拆成中文开发者能直接使用的十二篇文章。

但第一篇先不讲工具。

先回答一个更硬的问题：AI 都能写代码了，软件工程师到底还该学什么？

代码正在变便宜，交付没有

过去很多开发者的核心训练，是把需求翻译成代码。

理解需求，设计结构，写实现，调 bug，补测试。代码能力越强，产出越快，越像一个可靠工程师。

AI 出现之后，这个等式被改写了。

现在，很多“把想法变成第一版代码”的工作，确实快了。你可以让模型生成组件、写脚本、补测试、解释日志、查 API 用法。哪怕写得不完美，也足够让一个想法快速落地。

于是很多人会得出一个简单结论：以后会写提示词的人就够了。

我不太同意。

提示词当然重要，但它只是入口。真正决定结果的，是你能不能把一个模糊意图变成可执行、可验证、可回滚的工程任务。

AI 让代码变便宜，但没有让下面这些东西变便宜：

• 判断什么才是正确需求
• 知道哪些上下文必须提供
• 约束 AI 不要乱改
• 设计验收标准和测试证据
• 识别安全、权限、性能和维护风险
• 在出错后定位问题、回滚和复盘

以前，这些能力常常藏在“会写代码”后面。现在代码产出速度上来了，它们反而被放大了。

一句话：

AI 时代的软件工程师，不是少学工程，而是必须更早进入工程。

你不能等代码写完再问“这是不是我要的”。你要在 AI 动手前，就把目标、边界和验收说清楚。

CS146S 的价值：它讲的是一条链路

CS146S 的课程描述里有一个关键判断：软件开发正在从“0 到 1 写代码”，变成“计划、用 AI 生成、修改、再重复”的迭代工作流。这个判断很重要，因为它把 AI 编程从“神奇写代码”拉回了工程现场。

这门课的公开周纲大致是十周：

Coding LLM 和 AI Development
Coding Agents 的结构
AI IDE
Coding Agent Patterns
Modern Terminal
AI Testing and Security
Modern Software Support
Automated UI and App Building
Agents Post-Deployment
AI Software Engineering 的未来

你会发现，它不是从“装哪个插件”开始，也不是停在“生成一个网页”结束。

它真正关心的是：当 AI 参与整个软件生命周期时，开发者如何重新组织工作。

这正好避开了中文技术内容里常见的两个极端。

一个极端是工具说明书：今天教你按钮在哪，明天教你命令怎么敲。短期有用，但工具一改版，文章就过期。

另一个极端是宏大叙事：AI 要替代程序员，未来人人都是 CTO。听起来刺激，落到手里的东西很少。

这组连载会走中间路线：每篇讲一个课程概念，但必须交付一个工程资产。模板、清单、矩阵、SOP、评审表，至少有一个能被你复制到项目里。

现代开发者的四个新基本功

如果只保留四个关键词，我会把 AI-native 开发者的基本功写成这样：

定义问题 → 供给上下文 → 设计约束 → 验证结果

这四件事听起来普通，但用不好，AI 产出的代码就会越来越像“热心但没边界的同事”。

第一，定义问题。

不是“帮我做个登录”，而是“给现有后台管理系统增加邮箱验证码登录；不改密码登录；验证码 10 分钟有效；失败 5 次锁定；管理员和普通用户沿用现有权限模型”。问题定义越含糊，AI 越会替你脑补。

第二，供给上下文。

AI 不知道你的团队约定，不知道哪些模块不能动，不知道线上事故的历史，也不知道你们为什么不用某个库。你不给，它就猜。项目说明、架构边界、历史决策和当前任务背景，都会变成开发材料。

第三，设计约束。

很多 AI 任务失败，不是因为目标不清楚，而是因为“不要做什么”没说清楚。不要重构无关文件，不要改数据库结构，不要引入新依赖，不要访问生产数据。这些负约束会直接影响风险。

第四，验证结果。

“看起来能跑”不等于完成。你需要验收清单、测试、日志、截图、diff 说明、风险声明。AI 可以帮你生成证据，但不能替你承担判断。

一个自测表：你现在在哪一层？

下面这张表可以当作本系列的起点。

能力	初级用法	进阶用法
任务定义	一句话让 AI 写功能	写清目标、非目标、验收和边界
上下文组织	粘贴一堆文件	给出项目说明、相关路径和决策背景
Agent 协作	让 AI 自己看着办	设定权限、检查点、停止条件
终端自动化	复制命令让 AI 跑	使用 dry-run、日志和可回滚脚本
测试安全	让 AI “补点测试”	建立需求、风险、测试、证据矩阵
Review 支持	让 AI 看有没有问题	让 AI 找风险，最终由人批准
上线后支持	让 AI 解释报错	给 AI 受限日志、Runbook 和审计边界

你不需要每项都满分。

更现实的做法是：选一个真实功能，从“让 AI 写代码”升级成“让 AI 参与交付闭环”。哪怕只是多写一个任务说明书、多加一个验收矩阵，效果都会很明显。

反模式：把 AI 当成便宜外包

很多团队现在的问题，不是不会用 AI，而是把 AI 当成便宜外包。

任务扔出去，代码拿回来，出了问题再骂。

这个模式短期很爽，长期很危险。因为外包至少会问你需求，AI 很多时候不会。它会用最顺滑的方式把空白补完，然后把风险藏进 diff 里。

更好的类比是：AI 是一组速度很快、经验不稳定、需要明确边界的执行单元。它能放大你的判断，也能放大你的疏忽。

所以开发者要学的，不是“如何让 AI 更听话”这么简单。

你要学的是如何设计一套工作系统，让 AI 的速度进入轨道。

30 分钟练习：建立你的能力基线

找一个你最近想让 AI 做的小功能，按下面的问题写一页纸。

# AI-native 开发能力基线

## 任务
- 我想让 AI 完成什么？
- 哪些事情明确不做？

## 上下文
- 它必须阅读哪些文件？
- 哪些项目规则不能违反？

## 约束
- 不能改哪些模块？
- 不能引入哪些依赖或外部服务？
- 哪些动作需要先问我？

## 验收
- 做到什么算完成？
- 需要哪些测试、截图、日志或人工检查？

## 风险
- 这个任务最可能出什么错？
- 出错后如何回滚？

写完之后，不要急着把它喂给 AI。

先自己看一眼：如果你是一个完全不了解项目的新同事，只凭这页纸，能不能做对第一版？

如果不能，AI 大概率也不能。

下一篇我们就从这里开始：让 AI 写对第一版代码，关键不是提示词魔法，而是一份合格的 task-brief.md。

1.
参考 Stanford CS146S 公开课程页面与 Stanford Bulletin，核验日期：2026-07-20。课程链接：https://themodernsoftware.dev/；Bulletin 链接：https://bulletin.stanford.edu/courses/2274401。
↩︎