红旗法案：通过历史之镜分析AI时代的人机协同范式

Notion创始人在 X 平台发表了一篇题为《蒸汽、钢铁与无限心智》（Steam, Steel, and Infinite Minds）的文章，其中提出"人类介入循环"（human in the loop）并非是AI交互的理想状态，并引用了一个十分有趣的案例------"红旗法案"。这一观点与我的看法高度一致。特别展开谈谈我的理解和思考。

"红旗法案"的来龙去脉

英国作为工业革命的先驱、曾经的"日不落帝国"，却在汽车产业------这一工业的明珠上------显得并不领先。许多人将此归咎于"红旗法案"。

事实上，英国曾是世界上最早制造汽车的国家之一。1825年，英国人斯瓦底·嘉内便制造了一辆蒸汽公共汽车，并开展了世界上最早的公共汽车运营。然而，随后于1865年颁布的《红旗法案》给英国的汽车产业按下了刹车。

该法案具体内容包括：

蒸汽车辆时速不得超过4英里（约6.4公里），经过城镇与村庄时不得超过2英里（约3.2公里）；
车辆至少需由3人驾驶，一人负责添煤，一人操控车辆，另一人则需在车前50米外步行并摇动红旗，为其开道。

如今对"红旗法案"主要有两种解读：

一种观点认为，法案源于当时利益阶层（例如马车夫）对失业的担忧与反对，导致英国丧失了汽车产业的先发优势，使美、德等国后来居上；
另一种观点则认为，早期蒸汽汽车犹如"行走的锅炉"，噪音大、烟尘多，易惊扰马匹，法案在当时具有一定合理性，只是未随内燃机技术进步而及时调整，直至1896年才在舆论压力下被废除。

当然，我相信实际上上肯定2个原因都有。这个案例带给我们两点启示：

任何新技术在诞生初期，其功能、法规与技术本身必然不完善；
用旧体系的思维与方法去应对新事物带来的新问题，往往是错误的。新技术所引发的问题，最终仍需依靠新的技术手段来解决。

AI时代面临的相似困境

当前，AI在软件研发等领域已被大规模应用，但"人与AI如何协作"成为核心难题。"程序员"作为自己免费割自己命的伟大阶层，完全没有因为自己的生存考虑限制AI 的发展，但是，"是否在用旧思维看到新问题"，是我们面临的调账。

AI生成的代码是否存在问题？------ 是的。
那该怎么办？------ 目前常见的做法是交由人类审核。
这样做对吗？------ 对许多产品和公司而言，这或许是当前不得不采取的策略，但从根本上说，并非长远之策。真正的解决方案应当是：完善AI自身能力，使其具备自我检查与修正的机制。

这是否意味着人类完全放手？并非如此。人类应当"升维"------在更高的维度上进行监督与审核。

分析软件开发中的人机协同层次

我们可以将软件开发过程分为以下四个抽象层次，并分析各自的人机协作模式：

理想的人机协作演进方向是：逐步提升AI能力，然后将各层次任务逐层（代码->设计->规范）交由AI负责。

抽象层次	核心问题	人类的独特价值	AI的当前能力与优势	理想的"人机协作"模式
1. 代码层（Implementation）	"如何实现这个功能？"	架构决策、把握非功能性需求（安全、性能等）、对代码质量的直觉。	极其熟练。精通语法、模式与常用库，能快速生成、解释、重构与调试代码。	人类作为审核者与架构师： • 启发式编程：提出想法，由AI生成多个方案供探索； • 代理编程：委托AI实现完整功能模块，人类负责评审与集成。
2. 模型/设计层（Design & Modeling）	"系统由哪些部分组成？如何交互？"（领域建模、架构图）	业务洞察、抽象思维、权衡判断、识别隐含的领域概念与约束。	良好且快速进步。能将需求转化为初步的类图、ER图；能从代码反推设计；能应用设计模式。	人类作为领域专家与总架构师： • AI作为设计伙伴：人类提出核心概念，AI生成初步模型或架构选项，人类进行批判性修正与确认。
3. 规范/需求层（Specification & Requirements）	"系统具体要做什么？"（用户故事、验收标准、API规范）	同理心、与利益相关者沟通、将模糊意愿转化为精确表述、识别隐含及未来需求。	强大但有盲点。能将模糊描述转为结构化需求；可生成详细API规范；能发现需求矛盾。	人类作为需求分析师与产品负责人： • AI作为超级助手：人类提供原始意图与背景，AI输出详细规范草案，人类负责验证、完善与终审。
4. 意图/问题层（Intent & Problem）	"我们要解决什么问题？为谁解决？"	真正的创新、发现市场机会、理解人性与情感、定义愿景与战略、承担最终责任。	非常有限。本质是关联与扩展现有知识，缺乏真正的"灵光一现"与原创洞察。	人类作为源头与决策者： • AI作为灵感扩音器：人类提出原始意图，AI可提供市场分析、竞品汇总与风险提示，辅助人类完善与验证想法，但不能替代人类定义问题的过程。