AI 为什么还取代不了软件工程师,也不会取代

Vibe Coding 现在主要靠什么技术

看 AI 会先冲击谁，软件工程是个很合适的样本：这里的 AI 进展最快，落地速度也特别快。

现有证据已经足够反驳这样一种叙事：一旦 AI 能力达到某个阈值，就会引发大规模裁员。既然这一点在监管壁垒极少的行业里都成立，那么其他大多数职业大概率只会更有缓冲空间。

原因其实也不难理解。很多知识工作——软件开发也在内——都像一个“决策—执行—交付”的三层结构。AI 现在主要压缩的是中间这层执行；前面的决策和后面的交付，对自动化的抗性，不会因为模型能力继续上涨就自己消失。

所以我们对软件工程需求的长期走势，还是审慎乐观。

软件业的 AI 裁员叙事，更像一种“AI 洗白”

• 正如 Aaron Levie 所说，CEO 很容易高估 AI 的实用性：他们能很快做出原型，却看不到把原型磨成交付成品还要补上 90% 的工作量。Dorsey 公开谈 AI 的方式，看起来就是这个路数。
• 4 月，Snap  裁员^[2]  约 1000 人，CEO Evan Spiegel 在裁员备忘录里主要把原因归到 AI 上。他还表示，AI 生成了  65% 的新代码^[3]。但这轮裁员实际发生在一名激进投资者发起  行动^[4]  、要求削减成本之后。（Snap 自 2017 年 IPO 以来，每个完整财年都录得净亏损，且 2026 年股价下跌超过 30%）。更说明问题的是裁员的具体落点：比如增强现实部门多个岗位合计 150 个职位被裁。这和我们预期中的 AI 驱动裁员对不上。真要是 AI 在驱动，受影响的应该是编程和其他“暴露于 AI”风险的岗位，并且会在全公司更普遍地出现，而不是集中压在某一个部门。
• 5 月，Intuit 宣布裁员 3000 人，同时与 Anthropic 和 OpenAI 达成合作。媒体把两件事连在一起，  塑造出^[5]  一种  叙事^[6]  ，把这轮裁员写成 AI 驱动的重组。这一次，CEO 倒是明确  反驳了^[7]  这种省事说法，直接表示“这件事与 AI 毫无关系”，并称被裁撤的是“协调成本高的岗位”和过多的管理层级。

我们看的每一则“AI 驱动软件工程裁员”报道，叙事偏差都差不多。把裁员包装成“AI 驱动”，本来就是整个经济里的普遍做法，很多调查都指向这一点：

• 59% 的美国招聘经理承认^[8]，在解释招聘冻结或裁员时，他们会强调 AI，因为比起财务约束，这套说法更容易让利益相关方接受。
• Forrester 首席分析师 J. P. Gownder 在谈到那些据称由 AI 驱动的裁员公司时表示^[9]：“当我们问他们，是否已经有成熟且经过验证的 AI 应用可以接手这些岗位时，十次里有九次，答案都是否定的——他们甚至还没开始。”
• 在 HBR 的一项调查^[10]中，超过 1,000 名全球高管里有 21% 表示，他们因为“预期” AI 会带来影响，已经做了大规模裁员；另有 39% 做了低到中等程度的预防性裁员。相对地，只有 2% 是因为 AI 已经实际落地，才进行了大规模裁员。这里有 10 倍差距，说明高管和其他人一样，也很容易被“AI 将取代工作”的叙事带偏。 另一个更直接的数据来自 WARN Act。该法案要求企业在关闭工厂或进行影响超过 100 名员工的大规模裁员时披露相关信息。2025 年 3 月，纽约成为美国第一个在 WARN Act 申报中加入 AI 披露复选框的州。在完整的第一年里，超过 160 家公司提交了 WARN 通知。没有一家^[11]勾选 AI 这一项。1^[12] 我们联系了纽约州劳工部，对方确认截至 5 月下旬，只有一家公司 Nespresso 勾选了该项。2^[13] 如果这些申报准确，那么在相关时期内，纽约州大约 25,000 名被裁员工中，只有 46 人受到 AI 影响，占比约为 0.2%。

对“AI 驱动大规模裁员”这套叙事，更致命的问题是：裁员本身就不是衡量 AI 潜在生产率收益的正确信号。研究已经明确指出，这种影响是通过“招聘放缓，而不是离职增加^[14]”体现出来的。直接解雇现有员工，反而会丢掉那些让员工真正用好 AI 的隐性知识和组织资本。裁员本身也很贵，包括遣散费用、士气受损，以及重新招聘的风险^[15]。算上这些成本，多数情况下根本没必要这么做，因为靠自然流失，几年内也能达到类似结果。 那如果不盯着裁员，而是看整体就业趋势，数据在说什么？美联储经济学家的一篇重要论文^[16]汇总了美国背景下的相关证据。软件工程师就业还在增长，但他们发现，和“没有 AI”的反事实情境相比，ChatGPT 出现之后，这个增长速度变慢了，每年大约少 3 个百分点。这项研究有个重要局限：它的方法无法捕捉自雇就业。所以，一部分增速放缓也可能是被创业吸收了。我们也有来自其他^[17]研究^[18]的证据表明，AI 让创业更容易。因此，真实情况很可能比美联储研究显示的还要健康。3^[19]

最后要分清一件事：软件工程领域确实有两类岗位流失会被 AI 间接推动，但这不等于“AI 取代了软件工程师”。一类是 AI 直接打掉了产品需求。Chegg（作业辅导）和 Stack Overflow（技术问答）都已经裁员，原因不是 AI 去做了这些员工原本的工作，而是这类工作的需求本身变得没必要了。历史上的对应案例也很清楚：1950 年美国人口普查统计的 270 种职业里，被自动化直接消灭的只有一种——电梯操作员^[20]。但还有很多职业是被新技术淘汰的，比如电报操作员。另一个可信的 AI 驱动裁员案例，出现在那些卖 AI、而不是买 AI 的公司里。所以，IBM 或 SAP 这类公司因为 AI 宣布裁员时，更准确的说法是：“我们把人力从传统职能重新分配到了增长最快的产品线。”这属于围绕收入机会做的常规企业重组，不是技术直接取代了员工。

为什么 AI 还没大规模替代程序员：决策-执行-交付三明治

瓶颈从来都不是写代码。比如，一篇 2019 年论文^[21] 汇总了已有研究，结论是：“开发者花在编码上的时间少得出人意料，具体占比因研究而异，在 9% 到 61% 之间。”这一点也和基于 Microsoft 6,000 名开发者数据的论文一致。随着编码代理开始被采用，到了 2025 年底，相关博客文章大量出现，反复指出写代码不是瓶颈，因为开发者发现，即便让代理写掉大部分代码，整体生产力提升依然很有限 [1^[22]， 2^[23]， 3^[24]， 4^[25]， 5^[26]， 6^[27]， 7^[28]， 8^[29]]。那真正卡住开发者的是什么？任务拆解类调研通常会指向会议、调试之类的活动。但问题不会停在这里：开发者在这些会议里到底在做什么，为什么这些事不能交给 AI？如果 AI 能力继续提升，调试难道不会被自动化吗？要回答这些问题，还是得做定性分析，去看软件工程师自己如何理解“哪些工作天然抗自动化”。

这项分析把真正的瓶颈收敛到三件事上：（1）决定要构建什么，并把它规格化；（2）验证交付结果，并为结果负责；（3）完成前两者所需的深层人类理解——对代码库、业务和运行环境的理解。

换句话说，软件工程师的工作更像一个“决策-执行-交付”的三明治，而“理解”是这三层的前提。AI 压缩的主要是中间那层执行，两端基本没动。只要软件开发团队还要负责做决策，并对交付结果承担责任，工程师就仍然得花时间建立对系统的深度理解。真正的瓶颈就在这三点上。

***图：软件开发由三层组成：（1）决策——问题界定、规格说明、规划；（2）执行——设计与实现；（3）交付——测试、验证、集成、维护等。注意，这些是概念层，而不是时间阶段。在一个项目推进过程中，在这些层之间来回切换是很常见的。***关于 AI 对生产力影响的“三明治模型”，最近一篇《编写代码 vs. 交付代码^[30]》论文给了证据。研究者分析了 GitHub 上 10 万名开发者，发现 AI agent 让代码编写行数增长了 8 倍，这和“三明治”里 Execute 层几乎被 AI 完全压缩的判断一致。但发布次数只增加了 30%，这说明人的瓶颈，也就是 Decide 和 Deliver 两层，依然还在。4^[31]

这个“三明治”还能继续压缩吗？我们认为不能。在流程的一端，开发团队必须先决定要构建什么。初级软件工程师很快就会学到一件事：需求规格说明——这是这个层面的行业术语——往往比预期更耗时；这里压得太狠，后面通常会更痛苦。这一层难自动化，因为它要同时处理用户需求、市场信号、组织优先级，以及某些情况下的监管约束。

随着 AI 能力继续提升，可以委托给 AI 的决策类型会越来越多。但这不会让“决策”层变薄：一旦某类决策可以稳定交给 AI，它就不再是竞争优势的来源，人类决策的价值会继续往更高层迁移。软件系统本身还会持续变复杂，所以这个过程没有上限。

“三明治”的另一端，人类团队得对自己交付的东西负责。也许未来某一天，团队会在没有完全测试、也没有完全理解的情况下发布关键任务代码；但按今天 AI 的可靠性，这种草率做法对软件团队和客户都是生存级威胁。 AI as Normal Technology 的一个核心判断是：就算未来技术门槛消失，控制权也不必交给 AI。我们可以靠共享规范、法律和政策，集体决定继续由人类承担责任。和试图放慢技术能力发展相比，这条路在控制 AI 影响扩散速度和提高安全性上更可靠。这样的速度屏障其实已经大体存在于责任法和行业专项监管里，只是还可以继续加固。（更完整的论述见 原文^[32]。）

按这幅图景，随着越来越多的执行层交给 AI，未来软件工程师的角色会更像起重机操作员。AI agent 会扛下大部分认知上的重活；人类最主要的职责，则是盯住 agent，确保它始终处在可控状态。

有些评论者觉得，让人类持续掌控的未来不太会出现，因为让人参与监督太贵了。此前确实已经有一些 广泛传播的案例^[33]，比如监管不力的编码 agent 删除生产数据库，或者造成别的破坏。但我们更倾向于把这些看成“人咬狗”式新闻，不是正在形成的新常态。它们会爆红，恰恰因为这种做法既不负责任，也不寻常，冲击性很强；同时也在反复提醒社区从中吸取教训，不要对 AI 产生过度依赖。正如那句格言所说：“如果它上了新闻，那就不用太担心。”不过，怎么判断高风险任务里对 AI 监管不力的使用是否正在增加——而且是放到整个经济体系里看，不只是软件工程——仍然是今天最关键的数据缺口之一。 顺带一提，“三明治被压扁”不是什么新趋势，也不只是 AI 带来的。二十多年前，美国劳工统计局就开始把编程和软件工程分开统计。粗略地说，程序员主要负责执行，软件工程师则管理这块“三明治”里更大的一部分。编程岗位不但一直在收缩，而且因为被当作基础执行工作，薪资也低得多。AI 只是把这个长期趋势又往前推了一把，进一步压低了纯技术技能的价值。

这种模式的重点是：哪怕 AI 越来越多地自动化“决策-执行-交付”三明治的中间层，人类仍然深度留在两端。它看起来不只适用于软件行业，只是软件行业最容易看清楚。毕竟，复杂决策和问责在大多数领域都很常见。很多人之所以会对大规模失业的到来过度自信，问题就在于没看到这一点，于是才会做出 AI 会取代放射科医生^[34]之类的预测。

Vibe coding 不是智能体工程

人们之所以会搞不清软件工程到底变了多少，一个直接原因是“vibe coding”这个词被用得太 含糊^[35] 了。很多做法都被塞进这个词里，但这些做法在两端的含义其实差得很远，相似之处反而没那么多。

严格说，真正的 vibe coding 是另一回事：用户只告诉智能体要做什么，不会在它运行时监督，也不会审查代码——甚至可能根本没有这个能力——除了在明显出问题时注意到异常，平时也不会评估输出结果。

这和大多数软件工程师实际使用智能体的方式正好相反：他们把智能体当工具，由人类继续掌控过程，并对输出负责。好在， agentic engineering^[36] 这个术语现在越来越多地被拿来描述这种做法。

智能体工程越来越常见后，工程师很快发现，监督编码智能体本身就很耗时。比如，知名开发者、也是 AI 转型过程记录者的 Simon Willison 提到，持续监督智能体会让他到上午 11 点就已经 精神疲惫^[37]。这也和我们的经验一致。更多量化证据来自 SWE-chat^[38]。这个数据集记录了编程代理交互，来源于自愿接入日志工具的开源开发者。研究发现，代理生成的代码里，最终保留在用户提交中的只有 44%；vibe coding 产生的提交引入漏洞的比例是纯人工提交的九倍；而用户最常见的意图是理解现有代码，不是生成新代码（19% 对 13%）。这个数据集本身有自选择偏差，我们不能只靠这一项研究下强结论；但它和其他证据放在一起，至少说明一件事：vibe coding 和 agentic engineering 不是一回事。

Agentic engineering 不是 vibe coding

再说一次，这不是两个截然分明的类别，而是一个光谱的两端，中间还有一片 模糊地带^[39]。不是每个项目都非得归入一次性项目或关键任务项目，也不是每种工作流都能精确落在表格左列或右列。但对“工作岗位会怎样”这个问题，有个判断很明确：企业不可能靠雇佣不合格的 vibe coder 来替代软件工程师，并据此交付生产级软件。

未来走向

AI 的鼓吹者可能会说，大规模裁员快来了；之所以还没发生，只是因为具备人类水平的软件工程能力是最近才出现的，或者还根本没实现。但如果“三明治模型”成立，这个预测就站不住。AI 已经 在很大程度上压缩了三明治的中间层，而且这种压缩其实几十年前就开始了。所以，就算把执行层变成即时且完美，相比现状也只是一次很小的变化。其他两层一直没有被 AI 撼动，并不是 因为能力受限。

事实可能正相反：软件工程岗位不但不会因为 AI 消失，甚至还可能继续增长。技术提高生产率后，软件和其他商品一样，创造成本会下降；成本降下来，人们就会买更多软件。用经济学的话说，软件的“价格弹性”很高。而且如前所述，AI 并不会替代软件工程师，也就是“替代弹性”很低，因此，对更多软件的需求，最后会变成对更多软件工程师的需求。还有一个和这里关系没那么紧、但更吸睛的词——“杰文斯悖论（Jevons’ paradox）”——也经常在 AI 讨论里被拿来^[40]反复提起^[41]。历史上一直是这个模式。美国程序员就业人数在 1950 年前后几乎为零，后来增长到今天的数百万人。这和农业等职业很不一样：后者的劳动力需求因机械化和自动化而大幅萎缩。差别在于，人摄入的卡路里总量大致是有限的——哪怕只增加 25%，都足以引发肥胖流行——而软件产出已经增长了百万倍。现代汽车的各种车载计算机上，运行的代码规模大约有 一亿行^[42]。

如果代码需求真有天花板，我们现在也还远没碰到。几乎所有认知型工作都能从软件中受益。随着 AI 继续压低编码成本，人们开始为工作或个人用途做各种一次性小工具；放在以前，这些东西根本不值得做。

未来的软件会多得多，软件工程师很可能也会更多，但这不等于大型科技公司会继续无限做大。现在，大多数软件工程师本来就在非软件公司内部任职，这个占比以后可能还会继续上升。另一个相关概念是“AI rollups^[43]”，指的是风险投资或私募股权机构收购“Main street”企业——比如牙科诊所、会计师事务所——然后把软件工程师或 AI 工程师嵌进去，从底层重建业务，把它们变成“AI-native”公司。当然，这最后也可能只是炒作，现在下结论还太早。也有人预测，随着软件工程被“民主化”，对软件工程技能的需求会下降。他们的判断是，软件产出会比以前更多，人类投入在软件生产上的时间也会更多，但这些工作会由并非软件工程师的人完成。核心观点是，AI 会把软件工程民主化到这样的程度：比如，受过法律训练而不是软件工程训练的人，也能更容易地创建法律软件。

也许吧，但我们不这么看。这里还是把 vibe coding 和 agentic engineering 混在了一起，也把执行层和“决策-执行-交付”整条链路混在了一起。回头看编程史，这类“我们正站在民主化门槛上”的说法并不新鲜。FORTRAN、COBOL 和 SQL 刚出现时，也都伴随着这种广为流传的期待^[44]。结果并没有变成这样。真正的门槛从来不只是学会语法，而是有没有足够成熟的判断力，能在保持可追责性的前提下做出正确决策。

归根结底，这种区别也许只是语义问题。可以确定的是，人们未来会花更多时间让计算机去完成新的任务。形式可能是构建软件，借助 agents 管理复杂工作流，或者别的东西，但都离不开软件能力、AI 能力和领域专长的组合。至于今天的软件工程师是不是最可能适应并填上这些新角色，现在还说不准。 AI 会改变软件的生产方式，而且是结构性的改变。这会直接影响 哪些 软件工程师受益，哪些人受损：取决于他们所在的公司类型、所处地理位置、资历层级，以及他们适应变化的速度。

延伸阅读

Deena Mousa 指出，用“AI 暴露度”这类指标去做宽泛的、全经济层面的 AI 影响分析，最后往往只会落到 表面^[45]。她主张把研究做细，按职业分别看。我们此前还和 Justin Curl 合写过一篇分析 AI 在法律服务中的应用^[46] 的论文，重点讨论监管和其他瓶颈为什么让这个职业变得特殊。 40 年前那篇很有代表性的文章 No Silver Bullet^[47]，Fred Brooks 区分了软件里的“本质复杂性”和“偶然复杂性”。他的判断很直接：一部分复杂性是偶然的，来自当时技术不顺手，比如编程语言不好用；工具进步后，这部分会慢慢下降。但另一部分是本质的，因为光是准确规定软件该怎么行为，本身就很难。这也解释了，为什么这个“三明治”里“决策”这一层这么厚，而且不容易自动化。有意思的是，当时大家就已经在期待 AI 提高程序员生产力了。Brooks 的看法是，AI 和其他技术都只能削掉偶然复杂性，所以带不来数量级上的生产力提升。（Brooks 也是 The Mythical Man Month^[48] 的作者，这本文集几乎肯定是软件工程里最知名、影响力最大的作品。No Silver Bullet 后来也收进了这本书。）

1^[49]

这个复选框实际写的是“technological innovation or automation”。

当前的 WARN Act 数据问题不少。它只覆盖纽约州；公司也可能因为表述含糊，或者因为勾选与不勾选这个选项的风险并不对称，而少报把 AI 作为裁员原因的情况——虽然我们没有具体证据说明它确实发生了。联邦和州两个层面都在推进更严格的透明度要求，这个数据缺口也该尽快补上。 3^[50]

论文用了 coder 这个词，但它的定义按技能算，不按岗位角色算，所以覆盖的工作范围比“编程”大得多。问题也在这里：按行业、职称和技能来衡量，本来就很难直接对齐。

4^[51]

有意思的是，这篇论文在一个针对移动应用的子研究里发现，生成出来的应用并没有带来更高的使用量。消费级软件和企业软件的差别，在这里很明显。前者争的是一块相对固定的注意力池：应用发得更多，不等于用户会花更多时间去用。但企业软件还有增长空间，因为原本靠人工完成的流程，仍然可以继续被软件承接，或者进一步自动化。

#人工智能 #软件工程师 #就业影响 #AI裁员 #生产力

                                                               1. “AI 生成的 PR 几乎都是'垃圾'” - Zig 作者采访 原创                                    

                                                               2. 对话 Boris：打造 Claude Code 原创                                    

                                                               3. MCP 现状与技术反思 原创                                    

                                                               4. 当面试者使用AI：大模型辅助作弊的检测盲区与人才评估体系的结构性溃败 原创                                    

                                                               5. 2025 年 Go 开发者调研报告 原创                                    

引用链接

1. https://www.normaltech.ai/
2. https://deadline.com/2026/04/snap-layoffs-ceo-evan-spiegel-ai-1236861335/
3. https://finance.yahoo.com/sectors/technology/articles/snap-ceo-praises-ai-writing-090500386.html
4. https://www.businesswire.com/news/home/20260331059373/en/Irenic-Sends-Letter-to-Snap-Inc.-Co-Founder-and-CEO-Evan-Spiegel-and-Issues-Presentation-Outlining-Actionable-Steps-to-Unlock-Value
5. https://techcrunch.com/2026/05/20/intuit-to-lay-off-over-3000-employees-to-refocus-on-ai/
6. https://qz.com/intuit-layoffs-workforce-reduction-ai-restructuring-052026
7. https://www.cnbc.com/2026/05/20/intuit-ceo-says-companys-17percent-workforce-cut-had-nothing-to-do-with-ai.html
8. https://www.resumetemplates.com/the-great-turnover-9-in-10-companies-plan-to-hire-in-2026-yet-6-in-10-will-have-layoffs-2/
9. https://hrexecutive.com/the-truth-behind-ai-driven-layoffs-90-of-companies-arent-ready/
10. https://hbr.org/2026/01/companies-are-laying-off-workers-because-of-ais-potential-not-its-performance
11. https://www.hunton.com/hunton-employment-labor-perspectives/new-york-warn-act-no-ai-related-layoffs-reported-in-first-year-of-adding-ai-related-disclosure-to-the-system
12. https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers#footnote-1
13. https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers#footnote-2
14. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5425555
15. https://www.forbes.com/sites/quickerbettertech/2025/05/18/business-tech-news-klarna-reverses-on-ai-says-customers-like-talking-to-people/
16. https://www.federalreserve.gov/econres/feds/ai-and-coder-employment-compiling-the-evidence.htm
17. https://arxiv.org/abs/2605.10291
18. https://arxiv.org/abs/2512.06506
19. https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers#footnote-3
20. https://cepr.org/voxeu/columns/how-computer-automation-affects-occupations-technology-jobs-and-skills
21. https://www.microsoft.com/en-us/research/wp-content/uploads/2019/04/devtime-preprint-TSE19.pdf
22. https://ordep.dev/posts/writing-code-was-never-the-bottleneck
23. https://leaddev.com/velocity/writing-code-was-never-the-bottleneck
24. https://nkdagility.com/resources/blog/are-we-still-pretending-coding-was-the-bottleneck/
25. https://www.blundergoat.com/articles/ai-makes-the-easy-part-easier-and-the-hard-part-harder
26. https://www.infoq.com/news/2026/03/agoda-ai-code-bottleneck/
27. https://www.htmlallthethings.com/podcast/writing-code-was-never-the-bottleneck
28. https://www.linkedin.com/pulse/bottleneck-never-writing-code-andrew-little-6o1le/
29. https://www.scrum.org/resources/blog/bottleneck-was-never-code
30. https://www.nber.org/papers/w35275
31. https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers#footnote-4
32. https://knightcolumbia.org/content/ai-as-normal-technology
33. https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/
34. https://www.understandingai.org/p/ai-isnt-replacing-radiologists
35. https://x.com/GergelyOrosz/status/2011001698370699374
36. https://simonwillison.net/guides/agentic-engineering-patterns/what-is-agentic-engineering/
37. https://www.lennysnewsletter.com/p/an-ai-state-of-the-union
38. https://arxiv.org/pdf/2604.20779
39. https://simonwillison.net/2026/May/6/vibe-coding-and-agentic-engineering/
40. https://fortune.com/2026/04/28/will-ai-kill-jobs-why-not-jevons-paradox-torsten-slok/
41. https://x.com/levie/status/1971226298786906490
42. https://spectrum.ieee.org/this-car-runs-on-code
43. https://www.generalcatalyst.com/stories/the-future-of-services
44. https://cacm.acm.org/research/50-years-of-queries/
45. https://newsletter.deenamousa.com/p/the-leading-indicator-graveyard
46. https://www.lawfaremedia.org/article/ai-won-t-automatically-make-legal-services-cheaper
47. https://www.cs.unc.edu/techreports/86-020.pdf
48. https://en.wikipedia.org/wiki/The_Mythical_Man-Month
49. https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers#footnote-anchor-1
50. https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers#footnote-anchor-3
51. https://www.normaltech.ai/p/why-ai-hasnt-replaced-software-engineers#footnote-anchor-4