福特把造车压到 93 分钟，AI 正在把“软件生产线”重做一遍

作者 | 彭友顺，AI 爱好者

AI 时代的研发基础设施重构

工厂不会消失，但每一个工位上坐着的，已经不再是同一种存在。

01 一条流水线的启示

1913 年，亨利·福特在密歇根州高地公园的工厂里，把汽车生产拆解成 84 道工序，每个工人只负责其中一道，T 型车的生产时间从 12.5 小时压缩到了 93 分钟。这不是因为工人变强了，而是因为系统被重新设计了。一个多世纪后，AI 正在对研发团队做同样的事情。不是让程序员消失，而是把整条"软件生产线"重新拆解、重新设计。那些还在用 2019 年的方式管理研发团队的公司，正在重蹈柯达的覆辙——不是死于无知，而是死于"暂时还没出大问题"。

02 文档的本质变了：不再是给人看的

过去的逻辑

过去，文档是给人看的。

产品经理写PRD，研发读PRD，然后凭借经验、沟通、猜测，把需求翻译成代码。这条链路里充满了信息损耗：模糊的表述、遗漏的边界条件、各自理解不同的字段含义。

一个需求，往往要经过3轮以上的对齐会议，才能进入开发阶段。

现在的逻辑

现在，文档是给机器看的。

AI写代码，速度不是瓶颈，理解才是。当你扔给AI一份语义模糊的Word文档，它给你生成的代码质量，约等于你给一个第一天入职的实习生讲需求。

但当你给AI一份结构化、分层清晰的规格描述，它能在几分钟内生成可运行的代码、测试用例、技术方案——误差率接近于零。

这就是规格驱动开发（Spec-Driven Development，SDD）的核心思路。

GitHub上有一个叫OpenSpec的项目，目前已有超过25000颗星，它把这个思路做成了工具：你用/opsx:propose描述你想构建的功能，AI 立刻为你生成一套结构化的规格目录——

└── tasks.md      # 实现清单

然后你跑一句/opsx:apply，AI 按照规格逐项实现，每一步都有迹可循。

它的设计哲学是：先对齐，再动手（Agree before you build）。人和AI在写第一行代码之前，就把"做什么"和"怎么做"讲清楚了。

这和过去的需求评审会议有本质区别。评审会是在说服彼此，而规格驱动开发是在给AI喂一份它能直接消化的"施工图纸"。

文档的受众变了，文档的写法就必须变。

给人看的文档，追求的是易读；给机器看的文档，追求的是结构化、可执行、无歧义。

03 工厂隐喻：人与 AI，谁做什么

流水线上的分工

回到福特工厂。流水线上每个工人的价值，不是"全能"，而是在正确的位置做正确的事。今天的研发团队，也在经历类似的分工重构。

三个核心动作：输入、分拣、质检

工厂流水线的本质，是三件事：输入原材料、分拣加工、确认质量。人与AI的协作，同样是这三件事：

输入

你需要给AI喂进去的不只是"需求"，而是上下文完整、边界清晰、格式标准化的"指令包"。AI生成结果的质量上限，是你输入质量的上限。

分拣

AI会生成大量内容：代码、方案、文档、测试用例。你的工作是判断哪些可用、哪些需要调整、哪些是幻觉。这需要的是判断力，而不是执行力。

✅ 质检

AI不会告诉你它错了。它会自信地写出有bug的代码，会言之凿凿地引用一个不存在的数据。最终的质量把关，永远是人的责任。

AI是高速运转的机器，但机器不负责对结果负责。人负责。

AI 不下班

工厂里有一条铁律：机器比人更耐用。一台冲压机可以每天24小时运转，不需要换班，不需要年假，不会因为情绪不好而出错。流水线的真正革命，不只是把工序分开了，还把"时间"这个维度彻底改写了——生产不再受制于人的精力。

你的团队每天工作8小时，周末休息，需要睡觉、吃饭、开会。但AI不需要。它可以在你睡觉时跑完所有自动化测试，在你吃饭时完成代码初稿，在你开会时处理完三个需求的规格文档。

Cursor、Claude Code、GitHub Copilot——这些工具的本质，是把研发工作流从"人的工作时间"扩展到了"全天候"。一个合理搭建了AI工作流的团队，有效产出时间可以逼近24小时。

人需要休息，这是人的局限，也是人的权利。AI不需要休息，这是它的本质。真正的问题不是AI能不能工作，而是你有没有为它搭好可以持续运转的流水线。

04 人的角色没有消失，而是跃迁了

导演不上台，但电影是他的

克里斯托弗·诺兰拍《星际穿越》，他没有亲自操作摄影机，没有设计特效渲染算法，没有配乐。这些都由专业团队完成。

但那部电影，是他的。因为他定义了它应该是什么。

这正是AI时代工程师角色的本质变化——不是从台前退到幕后，而是从"执行者"跃迁为"定义者"。

现在，AI接管了"手"的部分。但AI没有意图，没有判断，没有对业务的理解。它无法决定应该做什么，无法判断做出来的东西对不对，无法在几个方向里选出更值得走的那条路。

这些，只有人能做。

从"How"到"What"和"Why"

Andrej Karpathy（特斯拉前AI总监，OpenAI联合创始人）说过一句话："英语正在成为最热门的编程语言。"

他是在说，清晰地定义问题、描述意图、设定边界，正在成为比手写代码更核心的工程能力。

这是一种更高阶的能力，需要更深的业务理解、更强的系统视野、更敏锐的判断力。它比"写代码"难，也比"写代码"更值钱。

数据说话

GitHub 2023年的研究显示，使用 Copilot 的开发者完成任务速度平均提升55%。而那些真正掌握"人机协作"的工程师——能精准定义任务、快速判断AI产出质量、高效修正偏差——产出效率提升达到3到10倍。

差距不在于谁更会用工具，而在于谁更清楚要用工具做什么。

AI是一支随时待命、执行力极强的团队，但它没有方向感。 给它方向的人，才是真正的核心资产。

05 重构基础设施：让 AI 成为一等公民

这是最容易被忽视、但影响最深远的一层。

数据和流程，要为AI而生

过去，我们设计系统是为了让人方便操作：

文档写在石墨文档、Confluence，格式随意 接口文档写完就不更新 ️ 测试用例存在个人电脑里 部署流程靠口口相传的SOP

这套东西，AI几乎没有办法消化。

AI友好的研发基础设施，长这个样子：

️ 结构化数据

需求、接口、错误日志、监控指标，都以机器可读的格式存储和流转。PRD不是自由发挥的文章，而是有固定字段的结构体。

标准化接口

内部服务之间的调用，遵循统一的契约标准。AI可以通过读取这些契约，自动生成调用代码、Mock、测试用例。

可观测性

系统的运行状态、错误链路、性能瓶颈，需要以结构化日志和指标的形式暴露出来。AI进行根因分析的前提，是能看到清晰的数据。

⚡ 自动化优先

CI/CD、测试、代码审查、档更新，任何可以自动化的环节，都应该是自动化的。AI需要一个可以反复调用、快速反馈的执行环境。

你今天的基础设施，决定了你明天能从AI那里借多大的力。

06 互联网研发团队的适应之道

团队层面：从"人力堆砌"到"杠杆思维"

过去，研发团队扩张的逻辑是：需求多 → 招更多人 → 产出更多。这个逻辑正在失效。

AI提供的是杠杆，不是替代。1个工程师 + AI工具链，在某些场景下的产出可以超过5个没有AI工具的工程师。

不是"我需要多少人来完成这件事"，而是"我如何设计工作流，让AI承担其中最重复的部分，人只做不可替代的部分"。

小而精、工具化、高杠杆，将会是AI时代研发团队的主流形态。

协作层面：统一语言，才能共用AI

单个工程师和AI协作，相对简单。但当一个10人、20人的团队都在和AI协作时，问题就来了：每个人和AI的对话都是孤立的、碎片化的，AI在每次对话里重新理解一遍上下文，效果参差不齐，结果互相打架。

AI读不懂"你们内部的默契"，它只能读懂写下来的规范。

多人团队与AI协作的前提，是先建立一套所有人共同遵守、AI能直接消化的统一规范：接口契约怎么描述、需求规格用什么格式、错误码如何定义、字段命名遵循什么约定。

一个没有统一规范的团队让AI写代码，就像一个没有乐谱的乐队——每个人都在演奏，但合在一起是噪音。

个人层面：三种能力的重新排序

文化层面：从"掌控代码"到"信任流程"

工程师有一种根深蒂固的心理：我自己写的代码，我最放心。这种心理，在AI时代是一种阻力。

你需要建立的新信任，不是对某个人，而是对流程——对你设计的自动化测试体系、对你建立的代码审查机制、对你定义的质量门禁。当流程可靠时，谁生成的代码已经不重要了。

07 不适应，不是选项

2023年，Salesforce CEO马克·贝尼奥夫说："我们不会再招聘软件工程师了。"不是因为软件不需要人，而是因为他认为，新的工作方式将让现有团队做到过去两倍的事。

这是一个信号，不是终点。

互联网研发团队正站在一个不可逆的转折点上。那些提前重构基础设施、重新定义工作方式、培养AI时代核心能力的团队，将在接下来的竞争中获得结构性优势。

福特工厂的工人，没有因为流水线的出现而消失。但那些拒绝站上流水线的人，确实消失了。

参考资料：

OpenSpec - Fission-AI（github.com/Fission-AI/OpenSpec）

GitHub Copilot研究报告（2023）

Andrej Karpathy "Software 2.0"

Marc Benioff采访（2023）