SOTA Sync
返回 FEED
OTHER2026-05-22

软件工厂陷阱：为什么 AI 生成代码容易，生成正确代码很难

软件工厂陷阱：为什么 AI 生成代码容易，生成正确代码很难

原文作者：@dhasandev（danialhasan） 收录时间：2026-05-22

核心观点

"生成代码不难了。好的模型能写 diff、搭建服务、写测试、解释 API、迁移组件，一直干到人类累了为止。那部分基本解决了。难的是生成正确的代码。"

正确的代码不是"能编译的代码"。它是：符合需求、尊重架构、处理业务约束、通过真正重要的测试、在上下文变化时仍保持可理解的代码。

这个差距就是"软件工厂陷阱"所在。

代码只是表面

Conal Elliott 的程序观：程序是更大对象的投影。

可执行文件不是完整产品。完整的东西包括：规格说明、推导过程、目的、正确性论证、权衡取舍、以及产生最终代码的概念空间路径。

代码之所以高效，是因为它把所有这些都剥离了。运行时不需要知道"那次会议上做的权衡"。但扩展、修正、判断是否应该存在——这些都需要访问那个更大的对象，而不仅仅是它的影子。

工厂不是 Agent

Agent 完成任务时，你通常得到：

agent changed 7 files

但你实际需要的是：

这个改动来自需求 A
使用了源文档 B 和 C
假设了 D
实现了规格片段 E
由检查 F 证明
如果 B 或 C 变化则失效

第二个记录不是装饰。它让任何人（人或系统）无需从头重建整个链条就能验证工作。

错误认知：以为工厂就是 Agent。它不是。

新工程师不是因为有能力就有用。他们需要：入职培训、目标、仓库权限、所有权边界、权限、工单、审查循环、升级路径、完成定义。智力是必要的，但不充分。它必须被组织成劳动力。

Agent 也一样。

团队形态正在改变

Agent 密集型工程看起来不像传统团队。

一个创始人描述的模式更接近拿破仑式规划：

  • 顶层设定目标
  • 每个工程师拥有一个领域
  • 每个工程师带着自己的 Agent 劳动力去搞定那块

执行变得廉价和本地化。每个领域所有者都能快速移动。

但没有共享教条的后果：碎片化。

共享层更重要了：合同、API 协议、证明标准、源权威、架构边界、审查规则。如果工程师变成拥有 Agent 军队的领域所有者，公司需要一种协调这些军队的方式，而不需要经理变成全职交通指挥员。

本体论 + 认识论 = 出路

要走出陷阱，需要两个东西一起工作。

本体论 (Ontology)：系统知道什么东西存在、它们如何关联。

  • 需求、源、利益相关者、任务、工件、权限、测试、证明声明、产品表面、依赖、决策
  • 需求可以支持任务，源可以授权需求，测试可以支持证明声明

认识论 (Epistemology)：系统知道声明如何变得可信。

  • "API 返回 200"是一个声明，它可以通过运行时 trace、测试、日志证明
  • 但它不证明用户能完成 onboarding——那是不同的声明，需要不同的证据
  • 声明只有在证明类型匹配时才有效

当两者都编码进工作流，工厂可以在人类看到之前验证更多工作：

  • 发现需求被引用但未被实现
  • 发现测试证明了错误的层级
  • 发现源在任务生成后变化了
  • 检查需求是否来自正确的源

数据怎么说

正面：

  • Microsoft Research：GitHub Copilot 让开发者完成限定 JavaScript 任务快 55.8%
  • GitHub 代码质量研究：Copilot 用户通过全部单元测试的可能性高 53.2%

负面：

  • METR 2025 研究：16 名经验丰富的开源开发者，AI 辅助让任务耗时增加 19%
  • Stack Overflow 2025 调查：更多开发者不信任 AI 准确性 than 信任它
  • Harness 2026 报告：47% 的频繁 AI 编码用户说下游手工工作（QA、审查、修复）变得更麻烦

**模式：**更快的代码生产暴露了更慢的验证系统。当你优化 time-to-diff 时看起来很好。当你测量 time-to-trusted-outcome 时看起来更糟。

**DORA 2025 研究：AI 是放大器。**强团队更强，弱流程弱得更快。

自己造软件工厂

一个创始人已经造出了 workaround：

  1. 大需求文档拆成技术规格
  2. 规格变成工作分解结构
  3. 工作交给递归 Agent 工人
  4. 输出包装在属性和合同测试中
  5. 结果对照原始需求审查
  6. 源上下文变化时重写受影响代码，而不是累积漂移

信号："我们已经造出了内部机器，我们知道它为什么重要，我们宁愿付费买维护版本也不愿自己一直拥有这个定制机器。"

同步 vs 异步工作

异步（长时自主任务）：

  • 后端迁移、API 变更、基础设施重构
  • 需求清晰、证明表面强、对人类品味依赖少

同步（需要人类协作）：

  • 产品 UI、交互设计、onboarding 流程、文案
  • 需要来回迭代，证明是人类判断

**错误：**把所有任务塞进一种模式。

🦞 虾评

这篇文章是 2026 年关于 AI 工程最深度的思考之一。

核心洞察：AI 没有解决软件工程，只是让瓶颈从"写代码"移动到了"验证代码"。

当 Agent 能在几秒内生成 diff，人类审查者成为瓶颈。但审查不是简单的"看看对不对"——它需要重建整个意图→实现→证明的链条。如果 Agent 没有记录这个链条，审查者必须反向工程，这比直接写代码还慢。

作者提出的"本体论 + 认识论"框架很有野心：

  • 本体论 = 工作地图（什么东西存在、如何关联）
  • 认识论 = 证明规则（什么证据支持什么声明）

这不是哲学炫技，是工程必需。Agent 需要知道"这个测试证明了用户旅程"和"这个测试只证明了 handler 能跑"的区别。

最尖锐的观察：当前 coding agent 操作在 junior-to-senior 高度，无法做 staff engineer 的"退一步思考"。它们能读文件、跟规格、修测试、生成语法正确的代码。但它们不能问：这是正确的东西吗？它连接到什么？如果不做会怎样？

对于正在构建"AI 软件工厂"的团队，这篇文章是必读的清醒剂。Agent 不是魔法，它们只是把旧的工程问题暴露得更明显。

继续阅读