SDLC Bottleneck in AI

在大模型（LLM）与代码智能体（Coding Agents）全面介入软件工程的背景下，传统的软件开发生命周期（SDLC）面临重构。编写代码（Coding）的执行成本正无限趋近于零，导致软件流水线中的“生产瓶颈”发生了结构性转移。

1. 软件开发生命周期（SDLC）的瓶颈转移

• 传统 SDLC 瓶颈：程序员的绝大部分精力和工作时间消耗在“把需求逐行（Character by character）用键盘打出来”这一步。由于实现（Implementation）非常昂贵，团队必须在前期通过大量的 PRD、调研和低交互模型来“去风险”。
• AI 时代 SDLC 瓶颈：随着大模型自动编写代码能力的快速迭代，编写代码步骤被极大压缩。在 Spotify 3000 人工程团队中，AI 覆盖率达到 99% 的周活跃度，PR 提交频次暴增 76%。依据阿姆达尔定律（Amdahl’s Law），原有的写代码瓶颈被瓦解后，瓶颈全面级联转移到了“人类进行 PR 评审与集成部署（Validation & Critique Loops）”上（面临 “too many PRs to review” 的窘境）。为此，SDLC 重心被迫重组为两端：
  1. 规划与定义（Planning & Architecture）：在动手前，想清楚“为什么要写、写什么、以及系统整体架构该如何设计”。
  2. 验证与审视（Validation & Critique Loops）：对 AI 生成的大量代码进行严密的逻辑验证、测试和多模型合议审查。Spotify 指出，**代码库的标准化（Standardization）**是 Agent 成功率的决定性支柱。在一个统一规范、拥有 Soundcheck 与 Golden State 标准框架的代码库中，模型能自动通过静态编译和 Lint 检查实现自我纠偏，甚至直接自动合并（Auto-merge）数百万个日常维护 PR；而在一个严重碎片化的代码库中，Agent 的理解与生成质量会呈断崖式下跌。
• 开发流程逆转与“Prototype 泛滥”：实现的零边际成本导致传统的瀑布流去风险机制失效。团队极易产生“既然 10 分钟能写好，那我们就直接动手写”的盲目倾向，从而制造出大量“界面高度 polished，但根本不符合核心业务意图或底层架构规范”的原生代码。
• PRD（产品需求文档）的新使命：PRD 并没有死。在 AI 开发时代，它的核心职责不再是规定细枝末节的按钮和交互样式，而是专注于**“高空意图对齐 (Intentional Alignment)”**——明确我们为什么要做这个功能，底层的商业和技术边界在哪里。

2. 程序员与产品设计核心价值重构

Shopify 研发主管与 OpenAI 桌面端负责人指出，当编写代码本身成为廉价的自动化操作时，程序员与设计者的核心溢价和价值创造来源发生了转移：

• Taste and Judgment（品味与判断）：高阶团队的护城河不再是敲键盘的速度或对特定语法 API 的记忆，而是对于产品体验的审美、判断、宽上下文融合（Systems Thinking），以及对于业务逻辑和系统边界的深度理解。
• Learning is the Collateral, not the code（学习是核心资产，代码不是）：在 AI 时代，代码只是解决问题的易耗副产品。真正的企业与个人资产是团队在理解业务和试错过程中积累的“认知与学习（Learning）”。
• 基建优先 (Infrastructure Over Features)：优先选择开发一劳永逸的底层基础设施，使得未来的新特性开发成本降至 1 小时，而不是临时用两周堆砌 Feature。
• 模型智能跃升与产品引爆时机：许多优秀的产品构想（如 OpenAI 原有的 Operator 智能体和 Atlas 浏览器项目）在旧模型时代被证实为失败体验。然而在智能跨越临界点后（例如 GPT 或 Claude 模型升级），相同的交互形态会突然引爆。团队切不可因为落后模型上的失败而将产品的交互设想全盘抹杀，需紧盯“ intelligence threshold (智能临界点)”。
• 可扩展性原语 (Extensibility Primitives) 胜于垂直功能：Codex 能够控制 Premiere 等专业软件，并不是因为团队专门为其写了视频编辑算法，而是写了底层控制插件作为通用可扩展原语（Connectors/Computer Use）。在系统设计时，创造通用的、能与外部系统桥接的原语（Primitives），比不断在产品内垂直堆叠特定 feature 更具高维度的颠覆性。

3. 大模型开发选型与管理策略

• 高阶模型首选论：在工程研发中，应当默认且只允许团队使用最大、最昂贵的推理/思考大模型（如 Opus / GPT-5 等级）。虽然高阶模型 API 较贵，但一旦在低级模型生成的代码中引入一个微小的隐藏 Bug，人类排查并修复该 Bug 消耗的时间与精力成本（Human time）将远超大模型 API 差价的千百倍。
• 代码评审 Council of LLMs：使用多个垂直大模型建立“AI 评审合议庭（Council of LLMs）”，分别从代码安全性、可访问性（Accessibility）、规范度等维度进行交叉自动评审。
• 代码责任归属：AI 可以编写大部分代码，但责任不可代理。程序员的名字会签在 PR（Pull Request）的提交者一栏，承担最终的生产安全责任。

Source: 2026-06-28-xiaohongshu-xhslink-com-o-8tm2iXt5adk（来源未公开）

Source: 2026-06-29-xiaohongshu-xhslink-com-o-9XMBQ7YYBkg（来源未公开）

4. Ship 模式 vs. Learn 模式：AI 时代的两种编程心态

Source: 2026-07-05-youtube-youtu-be-FkeLbE6Q22A-si-Q3b7Nf19_z4FmO5Y（来源未公开）

每次坐下来写代码，你都处于以下两种模式之一：

Ship 模式（交付模式）：只想让东西跑起来，不在乎过程。
Learn 模式（学习模式）：核心目标是结束后比开始时更强。

两者都完全合理——只要你对自己诚实。问题在于许多人以为自己在 Learn，实际上全程在 Ship：让 AI 写好代码，划一下，看着它运行，感觉自己”在进步”——实际什么都没学到。

自我检验方法：如果 AI 交给你一段代码，你无法自己独立写出来，那你就是在 Ship 模式。

真正想学时，翻转 AI 的使用方式

不是”让 AI 写代码，然后理解它”，而是：

1. 自己先写代码（可以查文档、Stack Overflow、YouTube，但不要复制粘贴代码）
2. 卡住了再去问 AI：不是”帮我写”，而是**“我的方法为什么不对？（Why didn’t my approach work?）”**

“Ask why your approach didn’t work — that’s the healthiest way to use AI when you really want to learn.”

给代码建立”大脑”（Code Brain）

随着项目增长，多对话 AI 工作会导致上下文碎片化。AI 不会自动知道项目状态——它会填充”合理”的猜测，产生重复逻辑、删除代码、发明已存在的函数。

解决方案：为代码维护一个”大脑”文件（可以用 Obsidian 或项目内 Markdown）：

• 你在构建什么以及为什么
• 整体架构与关键设计决策
• 当前在做什么

关键规则：不要让 AI 来更新这个文件。 更新文件的过程本身就是在测试你是否真正理解代码。

开始新对话时，先把”代码大脑”给 AI，它就不需要再猜测了。更重要的是：这个文件让你保持诚实——一旦你无法写清楚某个设计决策的原因，通常就意味着你根本没有好的理由。

Taste（品味）：AI 时代最难替代的核心能力

“AI can write any function you describe. But can you tell if a piece of code is actually good or not? That part is still up to the developer.”

品味（Taste）是能感知代码好坏的直觉——你读了足够多的代码，尤其是烂代码，才能感觉出什么时候不对劲。品味无法从 AI 获得，也无法从看视频获得。唯一的来源是：大量地写和读代码。

加速建立 Taste 的方法：

• 阅读别人写的代码，尤其是比你好的人写的（开源仓库：VS Code、TypeScript 等严格规范项目）
• 阅读 Pull Request，包括被拒绝的 PR——拒绝的 PR 是”有人的工作代码被维护者说不，并详细解释了原因”——那个”为什么”就是品味的来源
• 精读工程书籍：《The Pragmatic Programmer》（如何像工程师一样思考）、《A Philosophy of Software Design》（如何管理复杂性，什么使一个设计更深刻）

这与 Taste and Judgment 一节高度一致：AI 时代，编码本身的溢价消失，“能判断代码是否真的好”的审美直觉成为不可替代的护城河。