10 min remaining
0%
AI

655到14的压缩:当AI取代开发团队时实际发生了什么

每个人都认为AI编码是关于更好的提示。他们错了。我们将655个工作日的企业开发压缩到14天,只用了一个工程师。这里是实际使其成功的系统工程蓝图。

10 min read
Progress tracked
10 分钟阅读·
AI Generated Cover for: The 655-to-14 Compression: What Actually Happens When AI Replaces a Development Team

AI Generated Cover for: The 655-to-14 Compression: What Actually Happens When AI Replaces a Development Team

655到14的压缩:当AI取代开发团队时实际发生了什么

TL;DR:我们进行了一个标准的655人天企业构建——两年半的典型人类产出——并在14天内由一名工程师完成。不是因为我们找到了魔法提示,而是因为我们把AI当作劳动力,而不是巫师。公式:220页规格 → 基于冲刺的逆向文档 → 每3个冲刺进行一次严格的集成测试 → 具有对抗检查的多模型委员会。停止把AI当作自动补全。开始把它当作需要蓝图、工头和质量控制的施工队。

这里是James,水星科技解决方案的首席执行官。

来自我在香港湾仔的办公室——2026年7月

几周前,我告诉我们的首席建筑师做一件在大多数董事会中会让我被嘲笑的事情:将一个范围为655人天的项目在两周内交付。

不是原型。不是最小可行产品。是一个完整的企业系统——数据库架构、微交互、安全层、集成API,所有内容。

传统工程经理的反应是可以预测的。"你不能那样压缩软件开发。" "质量会受到影响。" "总会有人需要重构整个系统。"

他们不明白的是:限制从来不是打字速度。限制是决策。

当你消除人类犹豫不决的瓶颈时——当架构锁定、范围冻结、劳动力不眠不休时——你得到的不是10倍的速度。你得到的是一个相变

这不是一个关于提示技巧的故事。这是一个关于人工智能时代的系统工程的故事。

杨文里陷阱(或者:为什么大多数人工智能项目失败)

《银河英雄传说》的粉丝们知道杨的名言:"赢得胜利的最有效方法是让敌人失去战斗的意志。"

大多数人工智能开发项目以同样的方式失败——不是因为技术故障,而是因为 意志侵蚀。团队开始时势头强劲,在一个周末生成了 10,000 行代码,然后发现人工智能出现了漂移,架构不一致,没人能分辨什么是有效的,什么是幻觉。

他们失去了战斗的意志。

原因很简单: 他们把人工智能当作编码助手,而不是生产系统。

你不会要求建筑队在建筑师仍在绘制草图时开始浇筑混凝土。但这正是大多数 "氛围编码者" 所做的——他们通过提示向前推进,发现矛盾,修补它们,并以机器速度创造技术债务。

我们做了相反的事情。我们将 系统工程学科 应用于人工智能劳动力。结果是荒谬的。

第一步:220页蓝图(以规格为先的架构)

在生成第一行代码之前,我们的架构师花了一周时间编写一份 220页的规格文档

不是用户故事。不是线框图。一个 完整的建筑蓝图涵盖:

• 每个数据库架构和关系

• 每个API端点、请求/响应格式和错误案例

• 每个微交互和状态转换

• 每个安全边界和访问控制矩阵

• 每个冲刺交付物及验收标准

传统的反对意见:"但那是瀑布!那太慢了!"

胡说。在人工智能时代,瓶颈不是执行——而是问题定义。人工智能可以在定义良好的问题上以大约50-100倍于人类的吞吐量进行代码生成。但如果给它模糊性,它会自信地为你建造一座在微风中就会倒塌的教堂。

把它想象成核聚变与煤炭。聚变的能量无限强大——但前提是你要控制它。规格就是你的磁约束。没有它,你得不到能量。你得到的是一次爆炸。

**655对14的方程:** AI执行速度(~50倍)× 规格清晰度(~0.95)× 人类监督(~0.3)= ~14倍日历压缩

人类充当主建筑师。AI是施工队。蓝图必须完美无缺,因为施工队不会质疑它——它只是建造。

步骤2:反向文档循环(强制问责)

大多数AI项目出问题的地方在于:AI编写代码,而没有人验证它实际构建了什么。

我们通过我称之为的一个过程解决了这个问题反向文档

在每个冲刺之后,我们将原始代码输入到一个单独的 LLM 中,给出一个指令:“记录这段代码实际做了什么。”

然后我们将反向工程的文档与我们的 220 页规范进行了比较。

如果它们匹配?冲刺接受,进入下一个。

如果它们不一致?我们在它加剧之前捕捉到了幻觉AI误解了一个需求,走了捷径,或者引入了违反架构的逻辑。我们立即修复了它。

这不是测试。这是机器速度下的对齐验证。AI编写。AI记录。人类比较。冲洗,重复。

在14天内,我们大约进行了40次。试试用人类工程师做到这一点。

步骤3:消除AI漂移(集成为不可谈判)

人工智能开发中最危险的失败模式并不是明显的错误。它是漂移

大型语言模型在长时间对话中会失去上下文。当它们在编写第12个冲刺时,会忘记第2个冲刺的约束。架构缓慢而不易察觉地衰退——直到你有六种不同的身份验证实现、三种数据库连接模式,以及一个认为自己在与一个不再存在的API对话的前端。

传统测试在最后阶段捕捉到这一点。到那时,你正在解开一个比最初构建成本更高的混乱。

我们每3个冲刺进行严格的集成和安全测试。不是软检查。完整的测试套件:

• API 合同验证

• 数据库完整性检查

• 安全边界测试(认证、授权、注入)

• 端到端工作流验证

如果测试失败,我们会停止。我们修复。我们验证。然后我们继续。

**漂移预防规则:** 在漂移发生之前进行测试。在机器速度下,技术债务呈指数级增长——而不是线性增长。

这就是氛围编码系统工程。一个人感觉快速,直到第三个月。另一个人感觉缓慢,直到你意识到你在两周内完成了交付。

步骤 4:多模型委员会(对抗性质量控制)

人工智能开发中最大的错误? 使用一个模型来处理所有事情。

单一模型有盲点。它们在可预测的方式上自信地错误。它们优化一致性,而不是正确性。并且它们永远不会说 "我对这一部分不确定。"

我们使用了三种不同的模型,每种都有特定的任务:

| 模型 | 角色 | 任务 | |-------|------|------| | 模型 1 (代码) | 构建者 | 从规范生成执行代码 | | 模型 2 (红队) | 攻击者 | 编写旨在破坏模型 1 代码的集成/安全测试 | | Model 3 (记录者) | 翻译器 | 阅读代码库,生成可读文档 |

这不仅仅是并行处理。它是对抗性质量控制

Model 2 的整个工作是找出 Model 1 的错误。Model 3 的工作是揭示人类需要理解的复杂性。人类架构师进行协调、裁决和决策。

把它看作是机器速度下的 OODA 循环:观察(模型 3),定位(人类),决策(人类),行动(模型 1)——模型 2 不断对循环进行压力测试。

没有单点故障。没有单一模型的幻觉不受挑战。委员会自我检查,因此人类不必捕捉所有内容。

模式:从编码员到系统工程师

这是没人想听到的:纯粹的编码员时代正在结束。

并不是因为 AI 写出更好的代码——虽然确实如此。因为 AI 使执行自由,而自由执行改变了人类需要擅长的技能。

当混凝土昂贵时,泥瓦匠很有价值。当混凝土变便宜时,建筑师变得有价值。软件领域也正在发生同样的变化。

**新的价值层次结构:** 1. **问题定义**(规格) 2. **系统集成**(使各部分协同工作) 3. **风险管理**(捕捉漂移、安全、边缘情况) 4. **执行**(代码——现在已商品化)

整天编写 CRUD 端点的工程师正在被自动化。设计系统、管理 AI 劳动力并验证集成的工程师正变得不可替代。

停止管理语法。开始管理系统。

这对您的组织意味着什么

如果您是首席技术官、工程副总裁或正在考虑 AI 开发的创始人,这里是您的行动手册:

停止:询问 "我们如何更快地编写代码?" 开始:询问 "我们如何精确地定义问题,以便 AI 能够完美执行?"

停止:让工程师随意编码以应对架构。开始:在任何 AI 生成的代码进入你的代码库之前,要求详细的规格。

停止:项目结束时的测试。开始:每2-3个冲刺运行严格的集成测试,至少。

停止:对所有事情使用一个AI模型。开始:建立一个具有对抗性检查的多模型委员会。

停止:招聘打字快的程序员。开始:招聘在架构、集成和风险方面思考的系统工程师。

655到14的压缩不是噱头。这是一个正常的预览

掌握以规范为先的多模型对抗性人工智能工程的组织将在几周内交付其竞争对手几年才能交付的产品。而那些没有掌握的组织将在2027年向他们的董事会解释为什么他们的人工智能计划“没有取得预期效果”。

底线

我们之所以实现47倍压缩,并不是因为我们是天才。我们之所以能做到,是因为我们把人工智能当作它实际的样子:一个需要管理的劳动力,而不是一个需要更好提示的魔法棒。

220页的规范是困难的部分。反向文档循环是纪律。多模型委员会是安全系统。14天的交付只是当你把系统做对时发生的事情。

未来属于系统工程师,而不是语法打字员。问题是你是否会成为其中之一。

水星科技解决方案:加速数字化。