【AI编程】软件 2.0：从规范驱动到验证驱动的效率革命|dtsola

配套视频：https://www.bilibili.com/video/BV1jEw5zsEc4/

"限制因素不是编码智能体的能力，而是你的组织的验证标准。" —— Eno Reyes, Factory AI

引言：软件开发正在经历范式转变

大家好，我是 Eno，Factory AI 的创始人。两年半前我们创立公司时，明确了一个使命：将自主性引入软件工程。这听起来可能有些抽象，但我希望通过这篇文章，让你带走一些可以立即应用于你的组织、团队和产品的实用洞见。

无论你是在构建 AI 产品，还是在指导公司采用 AI 工具，这些原则都适用于所有涉及 AI 的开发工具——不仅限于我们的产品，也包括市面上所有优秀的编码助手。

一、软件 2.0：验证能力决定 AI 的边界

从规范到验证的转变

Andre Karpathy 在一条极具洞察力的推文中提出了"软件 2.0"的概念。他指出，验证能力是 AI 系统能力边界的决定因素。这个观点在当下尤为重要，因为最前沿的 AI 模型正在采用后训练（post-training）技术，大量使用可验证的任务进行训练。

AI 系统能解决的问题边界，本质上取决于两个因素：

能否明确设定目标
能否在可能的解决方案空间中进行搜索

我们习惯于通过规范（specification）来构建软件：定义算法、指定输入 x 和输出 y。但如果转变思维，考虑通过验证（verification）来实现自动化，你会发现这是一个全新的世界。

易于验证的问题具有哪些特征？

最适合 AI 自动化的问题通常具有以下特点：

✅ 存在客观真相：有明确的对错标准
⚡ 验证速度快：可以快速判断结果是否正确
📈 可扩展性强：可以并行验证大量结果
🎯 低噪音：验证成功率非常高
📊 连续信号：不是简单的二元对错，而是有 30%、70%、100% 这样的准确度梯度

为什么软件开发是 AI 的理想战场？

软件开发是高度可验证的领域——这正是为什么编码智能体成为当今世界最先进的 AI 代理。

过去二三十年，软件行业在自动化验证方面投入了大量工作：

单元测试（Unit Tests）
端到端测试（End-to-End Tests）
质量保证测试（QA Tests）
代码检查工具（Linters）
格式化工具（Formatters）

而且这个前沿还在不断扩展。像 Browserbase 这样的公司正在利用计算机视觉和浏览器代理，让复杂的视觉或前端变更更容易验证。文档工具（如 OpenAPI 规范）也在让 API 的验证变得更加自动化。

二、当前代码库的致命缺口

人类可以应对，但 AI 不行

这里有一个关键洞察：大多数代码库的验证标准对人类来说足够了，但对 AI 智能体来说远远不够。

让我给你一个自检清单：

基础验证清单

❓ 你有代码格式化的自动验证吗？
❓ 你有 Linters 吗？
❓ 你的测试覆盖率是多少？

对于专业软件工程师来说，这些问题的答案通常是"当然有"。但我认为你可以更进一步：

高级验证清单

🤔 你的 Linters 是否足够严格，能让编码智能体始终写出与资深工程师水平完全一致的代码？
🤔 你有测试能在低质量 AI 代码被引入时失败，而在高质量 AI 代码引入时通过吗？
🤔 你有 agents.md 文件吗？（这是一个几乎所有编码代理都支持的开放标准）
🤔 你的构建系统稳定吗？还是每三次构建就失败一次，公司里每个人都暗自讨厌它却无人提及？

50-60% 的陷阱

现实情况是：

大多数公司的测试覆盖率只有 50-60%
存在不稳定的构建系统
依赖人工手动测试来填补缺口

这对人类来说可能足够了，因为人类擅长处理没有明确自动验证的情况。资深工程师可以凭直觉判断代码质量，可以在代码审查中发现问题。

但当你在软件开发生命周期中引入 AI 智能体时——不仅仅是交互式编程，而是全面应用于审查、文档、测试等环节——这些缺口会严重限制智能体的能力。

顶尖公司的秘密

你们大多数人可能只见过在具备一定验证机制的代码库中运行的 AI 智能体。但我认为，当今全球许多顶尖公司实际上都引入了极为严格的验证标准。

这意味着他们使用智能体的能力远超普通开发者。这不是因为他们使用了更好的 AI 工具，而是因为他们的环境更适合 AI 工作。

三、开发流程的根本性转变

传统开发循环

传统的软件开发流程是这样的：

理解问题 → 设计解决方案 → 编写代码 → 测试

这是一个线性的、人类驱动的流程。

AI 驱动的新循环

当你拥有严格的验证标准时，流程会发生根本性转变：

明确验证约束 → 生成解决方案 → 自动验证 + 人工直觉 → 持续迭代

这是一个规范驱动（specification-driven）的流程。你会发现：

🎯 你的角色从"编写代码"转变为"定义约束"
🤖 AI 在约束范围内探索解决方案空间
✅ 自动化验证提供即时反馈
🔄 快速迭代成为可能

许多工具已经在朝这个方向发展：

Droids（我们的编码智能体）有 Specification Mode 和 Plan Mode
有专门的 IDE 围绕规范驱动流程设计
各种编码助手都在增强规范理解能力

四、八大验证支柱：实践清单

如果你想让你的代码库为 AI 做好准备，这里有一个系统化的框架：

1. 代码格式化（Code Formatting）

✅ 是否有自动化的格式验证？
✅ 格式标准是否足够明确，让 AI 无需猜测？

2. 代码检查（Linters）

✅ Linters 是否足够严格？
✅ 能否确保 AI 生成的代码符合团队标准？
✅ 是否有针对常见 AI 错误的特殊规则？

3. 测试覆盖（Test Coverage）

✅ 测试覆盖率是否足够高（建议 80%+）？
✅ 测试能否区分高质量和低质量的 AI 代码？
✅ 是否有针对边界情况的测试？

4. 文档（Documentation）

✅ 是否有 OpenAPI 规范？
✅ 是否有 agents.md 文件？
✅ 关键函数和模块是否有清晰的文档？

5. 前端验证（Frontend Validation）

✅ 是否有视觉回归测试？
✅ 是否使用浏览器自动化工具（如 Browserbase）？
✅ UI 变更是否可以自动验证？

6. 代码审查（Code Review）

✅ 是否有明确的审查标准？
✅ AI 能否理解这些标准？
✅ 是否有自动化的审查工具？

7. 构建稳定性（Build Stability）

✅ 构建系统是否稳定可靠？
✅ 是否消除了不稳定的测试？
✅ CI/CD 流程是否快速且可靠？

8. 持续集成（Continuous Integration）

✅ 验证流程是否在每次提交时运行？
✅ 反馈是否足够快？
✅ 是否可以并行运行验证？

五、组织策略：正确的投资方向

❌ 错误的做法

很多组织在做这样的事情：

花 45 天比较市面上所有可能的编码工具
仅因某工具在 SWE-bench 上准确率高 10% 就选择它
陷入无休止的工具评估和采购周期

✅ 正确的做法

更好的策略是：

改变组织实践，让所有编码智能体都能成功
选择开发者喜欢的工具
允许团队从众多优秀工具中自由选择

为什么？因为当你有了严格的验证标准，所有好的 AI 工具都会表现出色。

投资回报的巨大差异

这里有一个关键问题：作为组织，你应该把资源投入到哪里？

传统思维：OpEx（运营支出）= 增加人手

"要解决这个问题，我们需要 10 个人"
投资的是人力资源

新思维：投资于环境和验证标准

"要解决这个问题，我们需要更好的验证基础设施"
投资的是系统能力

结果差异：

传统方法：1.5x - 2x 的效率提升
新方法：5x - 6x - 7x 的效率提升

六、复杂 AI 工作流的可能性

前提条件：严格的验证

如果你无法自动验证一个 PR 是否合理成功，或代码是否不会导致生产环境崩溃，你就无法：

❌ 并行运行多个智能体
❌ 将大型现代化项目拆解为子任务
❌ 实现真正的自动化代码审查
❌ 让 AI 自主处理客户问题

但如果你有严格的验证标准，这些都变得可能。

"Slop test is better than no test"

我们有一位工程师 Alvin 说过一句话："粗糙的测试总比没有测试好"（A slop test is better than no test）。

这句话略有争议，但核心观点是：

有总比没有好：即使是 AI 生成的不完美测试，也提供了基本的验证
会被改进：人类和其他 AI 会不断增强和升级这些测试
建立模式：其他智能体会注意到这些测试并遵循其模式

关键是：只要有东西存在，并且在正确的变更时通过，就能启动正向反馈循环。

高级应用场景

想象一下这个场景：

客户报告了一个问题
自动创建 bug ticket
编码智能体接单并执行修复
代码通过所有自动化验证
开发者审查并批准
1-2 小时内部署到生产环境

这在技术上今天就是可行的。限制因素不是编码智能体的能力，而是你的组织的验证标准。

七、正向反馈循环：复利效应

循环机制

当你投资于验证标准时，会启动一个强大的正向反馈循环：

更好的验证环境
    ↓
更强的智能体能力
    ↓
更多时间优化环境
    ↓
更好的验证环境
    ↓
...

这是一个复利效应。每一次改进都会让下一次改进更容易。

新的 DevEx（开发者体验）循环

这也是组织可以投资的新型开发者体验循环：

🔧 投资验证基础设施
🤖 所有 AI 工具都受益（编码、审查、测试、文档）
👥 开发者生产力提升
💰 有更多资源继续投资

重要的是：这不仅仅让一个工具变好，而是让整个工具生态系统都变好。

无论你使用的是代码审查工具、编码智能体，还是其他 AI 辅助工具，它们都会从严格的验证标准中受益。

个人影响力的放大

这里有一个令人兴奋的观点：

一个有主见的工程师可以改变整个企业的速度。

以前，一个工程师的影响力受限于他们能写多少代码。现在，如果你能够：

明确表达你的观点
定义软件应该如何构建
建立验证标准

你的能力可以通过 AI 智能体放大到前所未有的程度。

八、Google 和 Meta 的启示

新手也能安全发布

想想 Google 和 Meta 这样的公司与一个 2000 人工程团队的公司有什么区别？

区别在于：在 Google，一个应届毕业生，几乎没有任何背景知识，可以：

修改 YouTube 的点赞按钮，让它稍微更圆润
有相当的把握不会让 YouTube 为十亿用户瘫痪

这怎么可能？

答案是：代码发布前必须通过的大量自动化验证。

验证标准 = 安全网

这些大公司花了数年时间建立：

全面的测试套件
严格的代码审查流程
自动化的性能监控
金丝雀发布（Canary Deployment）
快速回滚机制

这些验证标准就像一张安全网，让即使是初级工程师也能安全地做出改变。

现在，AI 智能体也需要同样的安全网。

九、未来愿景：完全自主的开发流程

理想场景

想象一下这样的世界：

⚠️ 客户问题出现
🎫 自动创建 bug ticket
🤖 编码智能体接单并执行修复
✅ 代码通过所有自动化验证
👀 开发者快速审查
👍 点击批准
🚀 1-2 小时内部署到生产环境

这今天就是可行的

让我明确一点：这在技术上今天就是可行的。

我们都对"完全自主"的流程有些怀疑，但关键是：

✅ 编码智能体的能力已经足够
✅ 自动化验证技术已经成熟
❌ 限制因素是组织的验证标准

软件开发者的角色不会消失

有人担心 AI 会取代软件开发者。我的观点是：软件开发者将继续深度参与软件构建过程，但角色会发生转变。

从：

编写代码
实现功能
解决 bug

到：

策划环境
设定约束
构建自动化
定义验证标准

你的角色逐渐转向策划你的软件构建的环境和花园。你在：

🎯 设定限制
🔧 构建自动化
📋 引入持续的主观判断

这是一个更高层次的工作，需要更深的系统思考和架构能力。

十、立即行动：实施路线图

第一步：评估现状

使用八大验证支柱对你的代码库进行评估：

## 验证成熟度评估

### 1. 代码格式化
- [ ] 有自动化格式验证
- [ ] 格式标准明确
- [ ] AI 可以理解标准

### 2. 代码检查
- [ ] 有 Linters
- [ ] Linters 足够严格
- [ ] 有针对 AI 的特殊规则

### 3. 测试覆盖
- [ ] 覆盖率 > 80%
- [ ] 可以区分高低质量代码
- [ ] 有边界情况测试

### 4. 文档
- [ ] 有 OpenAPI 规范
- [ ] 有 agents.md 文件
- [ ] 关键模块有文档

### 5. 前端验证
- [ ] 有视觉回归测试
- [ ] 使用浏览器自动化
- [ ] UI 变更可自动验证

### 6. 代码审查
- [ ] 有明确审查标准
- [ ] AI 可理解标准
- [ ] 有自动化审查工具

### 7. 构建稳定性
- [ ] 构建系统稳定
- [ ] 无不稳定测试
- [ ] CI/CD 快速可靠

### 8. 持续集成
- [ ] 每次提交都验证
- [ ] 反馈快速
- [ ] 可并行验证

第二步：识别缺口

问自己这些问题：

哪些验证标准缺失？

我们的测试覆盖率是多少？
我们的 Linters 有多严格？
我们有文档吗？

哪些验证标准不够严格？

初级开发者使用 AI 工具时遇到什么问题？
资深开发者使用 AI 工具时遇到什么问题？
差异在哪里？

哪些验证标准可以自动化？

我们现在依赖人工判断的是什么？
这些判断可以编码为规则吗？
我们可以用 AI 生成这些规则吗？

第三步：使用 AI 修复缺口

这里有一个美妙的递归：你可以使用编码智能体来改进你的验证标准。

例如：

提示：请分析我们的代码库，找出哪些地方的 Linters 
规则不够严格。特别关注：
1. 命名约定的一致性
2. 错误处理的模式
3. 代码复杂度的限制
4. 导入语句的组织

然后为每个问题生成相应的 Linter 规则。

或者：

提示：为我们代码库中测试覆盖率低于 50% 的模块
生成单元测试。确保测试：
1. 覆盖主要功能路径
2. 包含边界情况
3. 遵循我们现有的测试模式
4. 使用清晰的测试名称

第四步：建立持续改进机制

不要把这当作一次性项目。建立一个持续改进的流程：

每周审查：哪些 AI 生成的代码需要人工修正？为什么？
每月评估：验证标准的覆盖率提升了多少？
季度规划：下一个要攻克的验证支柱是什么？

第五步：衡量影响

建立指标来跟踪进展：

📊 AI 代码接受率：AI 生成的代码有多少比例不需要修改就被接受？
⏱️ 从问题到部署的时间：平均需要多长时间？
🐛 生产环境 bug 率：是否因为 AI 代码而增加？
👥 开发者满意度：开发者对 AI 工具的评价如何？

十一、竞争优势：为什么现在行动至关重要

1-5% 的俱乐部

如果你现在就开始投资验证标准，我保证你将进入：

工程速度前 1-5% 的组织

你将在该领域远超竞争对手。

这不是 AI 自动给予的

这里有一个不舒服的真相：

AI 不会凭空给你生产力提升。

这是一个组织必须做出的选择。你需要：

投入时间
投入资源
改变流程
培训团队

但好消息是：这些投资会带来复利效应。

早期行动者的优势

现在我们还处于软件开发智能体应用的早期阶段。大多数组织还在观望，还在比较工具。

早期行动者将获得巨大优势：

更快的学习曲线
更成熟的验证标准
更强的正向反馈循环
更高的团队熟练度

从 OpEx 到 CapEx 的转变

传统上，软件开发被视为运营支出（OpEx）：

雇佣更多工程师
增加人力成本
线性扩展

但投资验证标准更像资本支出（CapEx）：

一次性投资
长期受益
指数级回报

这是一个战略性的投资决策。

十二、常见问题与误解

Q1: "我们的代码库太大/太旧/太复杂了"

答：这恰恰是你最需要严格验证标准的原因。

大型、复杂的代码库：

人类更难理解全局
更容易引入 bug
更需要自动化验证

AI 智能体在大型代码库中的价值更大，而不是更小。

Q2: "这会花费太多时间"

答：短期投资，长期回报。

初期投资：2-3 个月建立基础验证标准
持续投资：每周几小时改进
回报：5-7x 的长期效率提升

而且，你可以使用 AI 智能体来加速这个过程本身。

Q3: "我们的开发者会抵制"

答：如果做得对，开发者会喜欢。

严格的验证标准意味着：

✅ 更少的生产环境 bug
✅ 更快的代码审查
✅ 更自信的部署
✅ 更少的深夜紧急修复

这些都是开发者想要的。

Q4: "AI 工具还不够成熟"

答：限制因素不是 AI，而是你的环境。

即使 AI 工具还在快速进化，投资验证标准永远不会过时。

而且，更好的验证标准会让所有AI 工具（现在和未来的）都表现更好。

Q5: "我们应该等待更好的工具"

答：等待是最大的风险。

工具会不断改进
但验证标准需要时间积累
早期行动者会建立难以逾越的优势

现在就开始，使用现有的工具。

十三、案例研究：从理论到实践

案例 1：初创公司的快速迭代

背景：一家 50 人的 SaaS 初创公司

问题：

测试覆盖率只有 30%
每次部署都很紧张
AI 工具使用率低

行动：

第一个月：建立严格的 Linters 和格式化规则
第二个月：使用 AI 生成测试，将覆盖率提升到 70%
第三个月：建立 agents.md 文件和文档标准

结果：

AI 代码接受率从 40% 提升到 85%
部署频率从每周 2 次提升到每天 5 次
生产环境 bug 减少 60%

案例 2：大型企业的现代化

背景：一家 2000 人工程团队的传统企业

问题：

遗留代码库庞大
文档缺失
AI 工具只有资深工程师能用

行动：

选择 3 个关键模块作为试点
为这些模块建立完整的验证标准
培训团队使用 AI 工具
逐步扩展到其他模块

结果：

试点模块的开发速度提升 4x
初级工程师也能安全地使用 AI 工具
为全公司推广建立了蓝图

案例 3：开源项目的社区贡献

背景：一个流行的开源框架

问题：

贡献者水平参差不齐
代码审查负担重
维护者精力有限

行动：

建立严格的 CI/CD 流程
创建详细的贡献指南（agents.md）
使用 AI 进行初步代码审查

结果：

PR 合并时间从平均 7 天减少到 2 天
贡献者满意度提升
维护者可以专注于架构决策

十四、工具和资源推荐

验证工具生态系统

代码质量

ESLint / Pylint / RuboCop：语言特定的 Linters
Prettier / Black：代码格式化
SonarQube：代码质量分析

测试

Jest / Pytest / RSpec：单元测试框架
Cypress / Playwright：端到端测试
Browserbase：浏览器自动化

文档

OpenAPI / Swagger：API 文档
agents.md：AI 智能体指南（新兴标准）
Docusaurus / MkDocs：文档站点

CI/CD

GitHub Actions / GitLab CI：持续集成
ArgoCD / Flux：持续部署
Datadog / New Relic：监控和可观测性

AI 编码工具

Factory AI：企业级编码智能体
GitHub Copilot：代码补全
Cursor：AI 驱动的 IDE
Codeium：免费的 AI 助手

学习资源

Andre Karpathy 的软件 2.0 博文
Jason 关于验证不对称性的博文
Factory AI 博客：关于代码库准备的深度文章
SWE-bench：评估编码智能体的基准

结论：选择的时刻

让我用一个清晰的对比来总结：

传统路径

花 45 天评估工具
选择"最好"的 AI 编码助手
期待 1.5-2x 的效率提升
发现工具不如预期
继续寻找下一个"更好"的工具

新路径

花 2-3 个月建立验证标准
让所有 AI 工具都能成功
实现 5-7x 的效率提升
建立持续改进的正向循环
在竞争中建立难以逾越的优势

你会选择哪条路径？

核心要点回顾

🎯 验证能力决定 AI 的边界：软件开发是高度可验证的，这是编码智能体成为最先进 AI 的原因
🔍 大多数代码库有致命缺口：50-60% 的验证标准对人类够了，但对 AI 远远不够
🔄 开发流程的转变：从"编写代码"到"定义约束和验证标准"
📋 八大验证支柱：格式化、Linters、测试、文档、前端、审查、构建、CI/CD
💡 投资方向的选择：不是比较工具，而是改变组织实践
🚀 5-7x 的效率提升：通过严格的验证标准实现，而不是通过"更好"的工具
🔁 正向反馈循环：更好的环境 → 更强的智能体 → 更多时间优化 → 更好的环境
🎓 角色的升级：软件开发者不会消失，而是升级为"环境架构师"
⏰ 现在就行动：早期行动者将进入工程速度前 1-5% 的组织
🌟 这是一个选择：AI 不会凭空给你生产力，这是组织必须做出的战略投资

最后的思考

想象一下一年后的你的团队：

场景 A（没有投资验证标准）：

还在比较不同的 AI 工具
开发者对 AI 的使用仍然谨慎
效率提升有限
竞争对手开始拉开差距

场景 B（投资了验证标准）：

客户问题在 1-2 小时内自动修复
初级工程师和资深工程师都能高效使用 AI
开发速度是竞争对手的 5-7 倍
团队有更多时间专注于创新

你想要哪个未来？

选择权在你手中。这不是 AI 会神奇地给你的东西——这是你作为组织必须做出的选择。

现在就开始。投资于验证标准。让你的代码库为 AI 智能体做好准备。

未来属于那些今天就行动的人。

如果这篇文章对你有帮助，欢迎点赞、收藏、转发。也欢迎在评论区分享你的经验，我们一起交流学习！

我是 dtsola【IT解决方案架构师 | 一人公司实践者】；专注AI创业、商业、技术、心理学、哲学内容分享。

提供服务：AI项目咨询 | 技术解决方案 | IT项目实施 | 企业技术顾问

博客：https://www.dtsola.com

公众号&VX：dtsola

需提供服务，加微信 dtsola，备注：IT咨询，并说明来意。

#独立开发者 #AI编程 #个人开发者 #一人公司 #程序员 #软件开发者 #创业者 #数字游民 #AI创业 #软件工程