AI Coding：从古至今

AI Coding 历史

• 2022 年：仅能完成单条代码补全
• 2023 年：可处理完整代码片段
• 2024 年：扩展至跨文件协作，可构建简单应用
• 2025 年：已能独立构建并重构完整代码库

1. 快思考/直觉 -> 慢思考/推理
2. 通过RAG把代码切碎了喂给 AI，AI 像管中窥豹，经常因为找不到上下文而改错 -> 百万级 Token 上下文 -> 全量代码库加载
3. 只读文本 -> 多模态(具备了工具使用能力)

随着 AI 编程的普及，我们的开发模式经历了从“直觉探索”到“工程落地”的演进：

手写代码 -> 代码补全 -> Vibe Coding -> Spec-Driven

2025，中国AI-里程碑事件：

1. 深度求索发布并永久开源DeepSeek-R1推理大模型，性能对标GPT-4o、Claude 3等国际顶尖模型，训练成本仅为后者的1/50，彻底摆脱行业「唯算力论」的路径依赖

2. 人形机器人彻底走进大众视野，从宇树机器人登春晚扭秧歌，到全球首场机器人马拉松比赛，再到机器人格斗与辩论赛轮番出圈

3. 中国团队自研的全球首个通用AI智能体Manus发布，可自主完成订票、数据分析、跨平台协同等复杂任务，最近已被Meta以数十亿美元完成全资收购

4. 字节跳动旗下豆包App达成历史性突破，日活用户破亿，这是中文互联网首个亿级用户的原生AI助手，让AI从「科技尝鲜」变成「全民刚需」

5. 豆包与中兴联手推出人类首款真正意义上的AI手机，核心突破是将大模型从应用层嵌入系统层，专属物理按键一键唤醒、屏幕感知交互、跨应用自动执行任务，让手机从通讯工具，升级为能读懂需求的个人智能助理

6. MiniMax与智谱相继通过港交所聆讯，同步冲击「全球大模型第一股」，MiniMax深耕C端多模态产品，海外收入占比超70%，智谱聚焦B端MaaS服务，本地化部署收入达84.8%

7. 中国大厂AI转型的经典教科书：阿里躬身入局重仓AI，整合核心资源推出独立「千问」AI App，直面对标豆包打造核心入口；灵光、阿福、夸克等AI产品同步迭代，阿里系AI矩阵全面爆发

8. 可灵&生数：视频生成「双子星」，改写全球格局；二者凭借自研技术，实现超高清、高帧率视频一键生成，效率提升百倍、成本直降90%；不仅替代国内大量影视广告团队，更获得好莱坞顶级创作者的规模化应用

Vibe Coding(氛围编程)

这是一种目前非常流行的、以结果验证为核心的交互式开发模式

Vibe Coding概述：

它指的是一种 “凭感觉、重交互、轻形式” 的 AI 编程方式

开发者使用自然语言（Human Language）作为主要的编程接口：

给 AI 一个模糊或大致的指令（Vibe），AI 生成代码，开发者运行并检查，如果不行就再聊两句修正

核心在于：快、流畅、低认知负担，适合写脚本、小工具或探索性代码

核心逻辑：由人类提供意图，AI 黑盒执行，并在项目环境中验证边界

工作流：抛弃逐行编写，直接下达指令 -> 观察运行结果 -> 感觉不对则调整指令 -> 感觉跑通了则提交

局限性：虽然它极速启动，能带来心流体验，非常适合原型开发

但它有“三大诅咒”，导致其无法构建生产级系统：

1. 非确定性：同样的 Prompt，下次生成的代码结构可能完全不同
2. 上下文遗忘：项目一旦变大，AI 记不住之前的逻辑，开始胡乱修改已有功能
3. 隐性债务：为了快速获得“Good Vibe”，AI 可能会引入极其拙劣的实现方式，而在不做深度 Review 时很难发现

Vibe Coding发展时间线：

Vibe Coding分类体系：

Spec-Driven(规范驱动)

为了解决 Vibe Coding 的不可维护性，Spec-Driven Development (SDD) 应运而生

它是更传统的软件工程与 AI 的结合

它强调在写代码之前，先定义规范（Specification）、需求文档、接口定义或测试用例

核心在于：严谨、可控、适合复杂系统

单纯靠“聊”很难构建一个几万行代码的稳定系统，必须要有 Plan（计划）和 Spec（规范）

它强调“结构化方法”、“正式化”、“详细的实施计划”

它强迫你在生成代码前，先由 AI 辅助生成一份“蓝图”或“规范”，然后再去执行

核心定义：用形式化、详尽的文档（Spec）作为唯一事实来源，驱动 AI 生成代码

思维转变：在传统思维中，文档是代码的注释

而在 SDD 思维中，文档 (Spec) 是源代码，具体的代码 (Go/Java/Python) 只是 Spec 经过 AI 编译后的产物

SDD 的价值：

• 锁定上下文：Claude/Gemini 等模型能完美理解几十页的 Spec，保证逻辑一致性
• 前置质量把关：修改文档的成本远低于重构代码
• 可协作：Spec 是人类可读的显性知识，解决了“只有 AI 和上帝知道这代码怎么跑的”问题

工作流：

1. Spec（定义规范）：编写 Markdown：定义目标、API 接口、数据结构，以及最重要的测试标准(告诉 AI 如何才算“做完了”)
2. Plan（生成计划）：AI 根据 Spec 生成技术方案，例如：先建表 -> 再写 Service -> 最后写接口
3. Tasks（拆解任务）：将计划拆解为原子的、可执行的 Task 列表
4. Implementation（执行与验证）：AI 逐个 Task 执行代码编写，并自动运行测试用例，测试通过即任务完成

SDD 工具推荐： Spec Kit (GitHub 官方)：提供了 /specify (想法转PRD)、/plan (PRD转计划)、/tasks (计划转任务) 的完整工具链

核心思想是“规范即通用语言”

业务逻辑与人的价值

AI 懂 Go 语法，但它不懂“为什么充电桩的上报同步时间是 60秒 而不是 10秒”

业务逻辑包含大量未形成文档的隐性知识、历史妥协和人情世故

人月神话的预言在今天依然振聋发聩：

软件开发存在 根本困难 和 次要困难

“必要的是构思概念上的结构，次要指它的实现过程。”

AI 极大地消除了次要困难：语法细节、API 调用、样板代码、繁琐配置文件的编写

这是技术实现带来的附加复杂性，AI 对此是降维打击

但 AI 无法解决根本困难：对复杂业务概念的构思、对模糊需求的界定、对系统边界的划分

这是问题域固有的复杂性

引入 AI 后，这对人的要求反而更高了—我们需要更清晰的问题定义能力

AI 无法取代人，因为 AI 无法维护系统的概念完整性，无法对结果负责，也无法理解业务深处的语境

开发者角色的转变

• 从“实现者”变为“决策者”：
• 传统模式是：“思考逻辑 -> 查文档 -> 敲键盘 -> 调试”
• AI 模式则是：“定义意图 -> AI 生成 -> 审查逻辑 -> 验证测试”
• AI 更擅长的是实现，而人真正需要负责的，是：把一件事的边界、规则和目标说清楚
• 大量的写工作已经可以交给AI去处理
• 人更应该把精力放在 定义问题的边界、规则和目标，管理不确定性，提出有约束的创新方案上
• 以前我们 80% 的时间在做 Translator(把业务意图翻译成代码)，处理的是“次要困难”
• 现在 AI 负责 Translation，我们必须回归 Architect 和 Product Owner 的角色，去解决“本质困难”

架构扩展

大模型训练概述：

Coding Agent架构：

Coding Agent能力列表：

Coding Agent的反馈循环框架：

商业AI辅助开发软件概述：

• Previous
  Anthropic-feature：MCP