什么是 Stanford CS146S？

Stanford 的课程代码 CS146S，课程全名是 The Modern Software Developer，由 Mihail Eric 授课，是一门在 2025 年秋季首次开设的课程。想看课程的官方概览和 syllabus 细节，可以直接访问官方课程站点 https://themodernsoftware.dev。想看作业与配套材料，可以看 GitHub 上 mihail911/modern-software-dev-assignments；其中 mihail911 就是 Mihail Eric，这个仓库的描述是 “Assignments for CS146S: The Modern Software Dev (Stanford University Fall 2025)”，主页同样指向课程官网。简单说，这门课不是泛泛谈 AI，而是在正式定义 Stanford 眼中的现代软件开发者应该会什么。

Stanford 正在把一件真实发生的事制度化

Stanford 现在有一门课叫 CS146S: The Modern Software Developer。这件事本身就已经说明了很多。

过去几年，比较“体面”的说法一直是把 AI coding 当成玩具、捷径，或者只是叠在“真正工程”上面的一层薄薄生产力外壳。这种说法现在已经老化得很快。

从公开的课程介绍和作业安排来看，CS146S 涵盖 prompting、Cursor 和 Warp 工作流、MCP servers、autonomous coding agents、security scanning、AI code review，以及 multi-stack app generation。这不是一门追流行的展示课。它其实是在承认：软件开发本身正在围绕模型重新组织。

Stanford 在这件事上是对的。现代软件开发者确实需要懂怎么写 prompt、怎么和 agents 协作、怎么串工具、怎么检查输出结果，以及怎么在 AI 进入工作循环之后把东西更快交出去。假装这件事不存在，只是在落后市场。

问题从来都不是第一版

但我认为目前整个 AI-development 讨论，仍然低估了真正的问题：AI coding 很少在第一版就失败。

第一版反而是最简单的部分。

登录页面能用，dashboard 也渲染出来，CRUD flow 交付了，demo 甚至还会赢得掌声。真正的麻烦，是从第四、第五、第六次变更开始。那时团队需要替换 auth provider、换掉 analytics、拆解一个早期做错的 styling 决策，或者只是多加一个功能，却不能顺手把另外三个不相关的系统一起弄坏。

这时大多数 AI-generated codebase 才会暴露它真正的本质：生成很快，但修改很贵。

真正的失败模式不是模型写出胡话。真正的失败模式是整个生成出来的系统边界太弱，所以之后每一次变更都带着看不见的影响范围。

会用工具，不等于系统安全

一门课可以教 prompting、AI IDE 工作流、MCP、agent automation、Semgrep、Graphite、multi-stack generation。这些都重要。但没有任何一项，能保证一个 codebase 在一个月持续迭代后仍然保持清醒。

一个团队完全可以很会用 AI-native 工作流，却仍然造出一个系统，让：

  • screens 直接 import implementation details
  • 生成出来的 modules 把 vendor APIs 泄漏进 app code
  • optional services 被当成 hard dependencies 初始化
  • 第二次 LLM 审查被误当成 verification
  • 每一次 refactor 都变成考古工作

所以我不认为 AI-native development 的决定性优势，最后会只来自工具使用能力。

真正的优势会来自一种可以撑过反复变更的 architecture。

真正缺的主题是 replaceability

每一个 AI-generated subsystem，默认都应该被视为可替换的。

这代表 auth 要躲在 interface 后面，analytics 要躲在 interface 后面，storage 要躲在 interface 后面，styling 要躲在 contract 后面，dependency construction 要集中在一个 composition root，validation 要放在 system edges，deterministic checks 要在每次 commit 都跑。

如果一个坏掉的 module 可以在同一个 contract 后面被删掉重写，AI 的速度就会积累成真正的优势。如果每个生成出来的部分都伸手碰其他部分，那么不管 prompts 有多好，团队最后都还是会慢下来。

这就是我希望更多 AI-development 讨论能明讲的主题。

真正的问题不只是“AI 能不能帮我们更快做出第一版？”

真正的问题是“等产品现实出现之后，我们能多便宜地替换掉原本做错的版本？”

现代软件开发者仍然需要 guardrails

现在很多 AI 建议，本质上仍然太依赖品味：

  • prompt 再写好一点
  • 审查再仔细一点
  • 比较多个模型输出
  • 给 agent 更多上下文
  • 再加一个 AI reviewer

这些做法有帮助。但它们不适合作为基础。

人类审查本来就不稳定。模型审查更不稳定。我唯一相信能规模化的模式是：

  • 让 AI 生成
  • 让 deterministic rules 做 enforcement
  • 让人来判断 specification 和 tradeoffs

这也是为什么我一直回到同一组东西：contracts、boundary rules、composition roots、contract tests，以及快速、不可协商的 checks。目标不是让模型完美表现。目标是让整个系统在结构上更难被破坏。

Stanford 是对的。但下一步更难。

CS146S 重要的地方，在于它把一个产业再也不能忽视的事实正式说了出来：AI-native development 现在已经是这门技艺的一部分。

但我不认为现代软件开发者的定义，只是会用 AI tools。

下一个标准更难。

现代软件开发者还需要知道，怎么建出一个 codebase，让 AI-generated parts 可以被约束、被验证、被替换，而不必每次都把整个系统拖进一次 rewrite。

Stanford 正在教现代软件开发者。

很好。

真正还缺的一门课，是那种架构纪律：它能让 AI-native codebase 不会被自己的速度拖垮。