摘要
2025 年下半年以来，前沿大模型在需求明确、一次交付的专业任务上已接近甚至超过资深从业者，工程组织的整体产出却没有同步增长。本文梳理 2025 至 2026 年公开的评测、实验、行业调查、招聘与裁员数据和从业者自述，分析这一落差从何而来，以及软件行业的分工因此如何重组。执行成本下降以后，瓶颈转移到任务定义和结果验收。分工的调整沿两条线展开：在人与人之间，产品、设计、开发和管理的职能边界正在融合，企业更需要复合型人员；在人与 AI 之间，执行越来越多地交给 AI，人转而负责定义任务和验收结果，底层算子开发这类深度技术岗位也不例外。行业还没有形成统一的新岗位，各家公司的职位名称各不相同，由谁来驾驶 AI 尚无定论，但这些岗位有共同要求：保留一项主要专长，借助 AI 覆盖相邻职能，并负责定义任务、验收结果。文章以退款流程为例，说明产品与工程交界处的规格与验收具体要做什么，最后讨论这些判断的局限。
1 引言
2026 年 9 月 3 日，OpenAI 发布 GPT-6 Astra。据 VentureBeat 报道，OpenAI 总裁 Greg Brockman 在当天的非公开媒体吹风会上以 “Welcome to the AGI era” 收尾；被问到 Astra 是否已经是 AGI，他说 “For me personally, I do think we’re there”，并强调这是个人看法。[1]
AGI 如何定义，不在本文讨论之列。本文关注的问题更具体：代码和其他工作成果越来越便宜以后，软件行业原有的产品、设计、开发、测试、管理分工会怎样变化，组织里又由谁来指挥 AI 干活。
资料以一手来源为主，包括学术论文、研究机构和企业的原始报告、公司公告，以及主流媒体对原始文件的报道；厂商对自家产品的说法和厂商主导的调查都单独注明。第 2、3 节分别整理模型能力和组织产出两方面的证据，第 4 节分析二者为何脱节，第 5 节整理分工重组的证据，第 6 节讨论驾驶 AI 的共同要求，第 7 节以退款流程为例，第 8、9 节是实践建议和局限。
2 执行层：模型与人类从业者的能力对比
2.1 基准测评
GDPval 是 OpenAI 2025 年推出的评测，论文当年 10 月发布在 arXiv 上。评测覆盖 44 个职业，其中包括软件开发人员（Software Developers）和项目管理专员（Project Management Specialists）；任务取自平均从业 14 年的专业人士的实际工作，由同行业专家对模型和人类的交付物做盲评对比。论文测试的模型中，Claude Opus 4.1 表现最好，47.6% 的交付物被评为不逊于人类专家。[2]
2025 年 12 月 11 日，OpenAI 在 GPT-5.2 发布页上称，根据人类专家的评审结果，GPT-5.2 Thinking 在 GDPval 70.9% 的对比中优于或持平顶尖行业专业人士，GPT-5 的这一数字是 38.8%；在 GDPval 任务上，GPT-5.2 Thinking 的输出速度比专家快 11 倍以上，成本不到专家的 1%，这两项是基于历史指标的估算。[3] 评测由 OpenAI 自行组织，方法已在论文中公开，数值还没有第三方复核。
进入 2026 年，以人类专家为基准的对比反而少了。Artificial Analysis 维护的 GDPval-AA 排行榜改由 LLM 担任评审，把模型交付物两两比较后计算 Elo 分，截至 2026 年 9 月排名第一的是 Claude Fable 5.1。[4] 改用模型评审能省下成本，代价是榜单只比模型之间的高下，不再和人对照。
METR 的时间跨度（time horizon）指标衡量的是：模型有 50% 把握独立完成的任务，人类专家通常要做多久。METR 在 2026 年 5 月 8 日把 Claude Mythos Preview 加入榜单，同时注明现有任务集下超过 16 小时的测量结果不可靠。[5] 前沿模型已经逼近这套方法的测量上限。
从这些结果看，在任务定义清晰、无需交互的前提下，2026 年的前沿模型已能达到或超过多数从业者的水平。GDPval 的对照组是平均从业 14 年的专家，换成全体从业者，这个判断只会偏保守。
2.2 开发者的使用行为
Sonar 2026 年 1 月发布的调查覆盖 1100 多名开发者。受访者估计 AI 生成的代码已占其提交量的 42%；96% 的人不完全相信这些代码功能正确，但只有 48% 每次提交前都会检查。[6] Sonar 本身出售代码质量检查工具，“检查不足”的结论正合其商业利益。打些折扣来看，约半数开发者不再逐次审查 AI 代码，这与第 6 节讨论的验收方式变化相吻合。
3 组织层：产出增长跟不上能力增长
3.1 随机对照实验
METR 2025 年做过一项随机对照实验：16 名有经验的开源开发者在自己平均参与了 5 年的成熟项目中完成 246 个真实任务，每个任务随机决定是否允许使用 AI。开发者事先预计 AI 能把耗时缩短 24%，事后估计缩短了 20%，实测却是允许使用 AI 的任务耗时增加了 19%。[7] 实验用的主要是 Cursor 和 Claude 3.5/3.7 Sonnet，代表 2025 年初的工具水平。[7]
METR 在 2026 年 2 月公布了后续结果。2025 年底的第二轮实验中，参加过第一轮的开发者估计提速 18%，置信区间从提速 38% 到减速 9%；新招募的开发者估计提速 4%，区间从提速 15% 到减速 9%。两组区间都包含零。[8]
METR 也承认实验出现了明显的选择偏差。越来越多开发者表示，即使有报酬，也不愿意一半工作不用 AI；30% 至 50% 的开发者说会故意不提交部分任务，因为不想在不能用 AI 的条件下做；第二轮时薪又从 150 美元降到 50 美元，筛选因此更严重。METR 由此认为，在被筛掉的开发者和任务上，真实提速可能高得多，并决定改变实验设计。[8]
3.2 行业调查
Google Cloud 旗下 DORA 团队 2025 年 9 月发布的年度报告调查了近 5000 名技术从业者。与上一年不同，这次 AI 采用与软件交付吞吐量、产品表现都呈正相关，与交付稳定性则仍是负相关。报告的说法是，AI 修不好一个团队，只会放大团队原有的长处和短处。[9]
3.3 大规模观测研究
Murphy-Hill 等人 2026 年 7 月在 arXiv 发布的研究，分析了微软数万名工程师在 2026 年初推广 Claude Code 和 GitHub Copilot CLI 期间的数据。使用者合并的拉取请求（PR）比不使用时的预期多出约 24%，四个月观察期内保持稳定。作者也提醒，合并的 PR 数量不等于交付的价值。[10]
3.4 小结
GPT-5.2 的 70.9% 与微软研究的约 24% 前后只差几个月，但衡量的是不同的东西，不能直接比大小。能确定的是，在同一时期，模型在单项专业任务上的表现和工程组织整体产出的增幅之间差距很大。
更新一代的模型还没有这类组织层面的数据。Claude Fable 5 于 2026 年 6 月 9 日发布[11]，GPT-6 Astra 于 9 月发布，而一项实证研究从设计到发表通常要半年以上。所以这里不用上述数据评价最新模型，只取其中的结构性规律：模型在明确任务上的能力增长，快于组织整体产出的增长。
4 瓶颈：规格与验收
4.1 评测范围的限定
GDPval 论文明确限定了评测范围：任务 “precisely-specified and one-shot, not interactive”，即需求精确、一次交付、中途不交互；依赖大量隐性知识或需要人际沟通的任务不在其中。论文还发现，给模型更多任务上下文能提高成绩。[2] 可见 70.9% 这样的结果，前提是有人已经把任务定义清楚、把上下文备齐，而在实际软件工作中，这一步往往最耗时间。OpenAI 在 GPT-5.2 发布页上对这一结果的解读也带着前提：在有人类监督的情况下，GPT-5.2 能有效辅助专业工作。[3]
4.2 单人团队案例
Vilas Boas 等人 2026 年 5 月发布了一项案例研究：在一家受监管行业的企业里，一名 staff engineer 借助四个 AI agent，按规格驱动开发（Spec-Driven Development）流程，接手了原本按四人小组规划的存量系统项目。项目用计划时间的一半交付，AI 生成代码首次评审通过率 90%，集成测试全部通过，直接人力成本下降超过 85%。[12]
作者认为，AI 放大了留下来的资深工程师的产出，并没有取代团队成员；单人团队能否成功，取决于规格质量和组织内部知识（institutional knowledge），模型能力不是主要约束。[12] 这项研究只有一个案例，主角又是资深工程师，结论能推广多远并不清楚。
4.3 行业观点与工具演进
以上证据都指向软件工作的两个环节：把模糊的问题转成可执行的规格，以及判断产出是否正确。
关于前者，Andrew Ng 在 2025 年 1 月的 The Batch 中写道，只要规格清晰，AI 正让构建本身变得更快、更便宜；[13] 同年 7 月他进一步指出，决定做什么已成为新的瓶颈，早期项目尤其如此。[14]
工具也在朝这个方向变。GitHub 于 2025 年 9 月开源 Spec Kit，把开发拆成编写规格、制定技术方案、拆分任务、实现四个阶段，由 coding agent 按规格实现。介绍文章出自 GitHub 的一位首席产品经理，他描述的问题是：开发者说明目标后拿到的代码看似正确，却无法完全正常运行；他认为开发的依据正从代码转向意图，人主要负责把握方向，大部分代码交给 agent。[15] 截至 2026 年 9 月 15 日，该仓库在 GitHub 上约有 13.7 万个星标，最新版本是 9 月 10 日发布的 1.0.6。[16] 星标数说明不了多少团队在生产环境中使用它，但能看出规格优先的做法在开发者中关注度很高。
关于后者，现有讨论较少，放在第 6 节展开。
5 分工的重组
5.1 岗位数据
Lenny’s Newsletter 2026 年 3 月 24 日发布的分析，依据 TrueUp 对 9000 多家科技公司的职位统计。当时全球科技公司在招的产品经理职位超过 7300 个，比 2023 年初的低点增加 75%，是 2022 年以来的最高水平；在招工程职位超过 6.7 万个；设计职位自 2023 年初以来基本没有增长，约 5700 个。[17] 这组数字统计的是在招职位，与在职人数口径不同，时间也在 2026 年 5、6 月的集中裁员之前，样本只含科技公司。
2026 年 5 至 6 月，多家科技公司宣布裁员，公告中都提到了 AI。表 1 列出 TechCrunch 整理的部分案例。[18] 更早在 2 月，Salesforce 裁撤了不到 1000 个岗位，涉及市场、产品管理和数据分析。[18]
表 1 2026 年 5 至 6 月部分科技公司的裁员情况
| 公司 | 时间 | 规模 | 公告中与 AI 相关的表述 |
|---|---|---|---|
| Coinbase | 5 月 5 日 | 约 700 人，占 14% | 工程师借助 AI 几天完成过去一个团队几周的工作，将试验单人团队 |
| Intuit | 5 月 20 日 | 约 3000 人，占 17% | 将资源重新分配到 AI |
| Meta | 5 月 20 至 21 日 | 约 8000 人，占 10% | 在 AI 时代，成功并非必然 |
| GitLab | 6 月 3 日 | 约 350 人，占 14% | agent 类工作负载带来百倍增长的需求 |
| Oracle | 6 月 22 日披露 | 过去 12 个月共 21000 人，占 13% | AI 技术的采用与部署导致员工人数减少 |
公告中提到 AI，不代表裁员主要因为 AI，宏观经济、成本控制和业务调整都可能是主因。
Mind the Product 2026 年 6 月 25 日的文章引用了 Live Data Technologies 的在职数据：截至 2026 年 6 月，美国科技公司产品经理在职人数比 2022 年峰值减少 28%；管理层级降幅最大，副总裁级减少 38%，总监级减少 35%，经理级（Manager）减少 31%，绝对人数少了约 4000；资深个人贡献者降幅较小，为 21%。[19] 该媒体 5 月 11 日的另一篇文章汇总了社区投票：60% 的受访者所在组织有过不同程度的缩减，28% 缩减幅度较大；45% 的产品经理感到过去三年岗位的技术门槛在提高；52% 的受访者需要把更多时间花在执行工作上。[20] 投票对象是自愿参与的社区成员，样本量不详。
Indeed 的职位发布数据补上了资历这一维度。Indeed Hiring Lab 2026 年 7 月 8 日的分析显示：对比 2022 年 5 月与 2026 年 5 月，美国职业受 AI 影响越深，职位发布量降得越多，之后这一关系发生反转；自 2025 年 2 月底 Claude Code 发布以来，美国软件开发职位发布量增长近 15%，同期全部职位下降 7%；2025 年 5 月至 2026 年 5 月软件开发职位的增量中，71% 来自高级职位，37% 来自标题含 AI 的职位。[21] 7 月 23 日的另一篇分析显示，2026 年第一季度美国软件开发职位中高级职位占 69.3%；在全部职业中，截至 2026 年 5 月，初级职位发布量同比下降 7.5%，高级职位同比上升 14.7%。[22]
5.2 职能边界的交叉
Figma 于 2025 年 9 月 10 日发布一份角色变化调查，数据来自 1199 份问卷和 51 次访谈，受访者包括设计师、产品经理、开发者、研究员、数据专员和市场人员。64% 的受访者认为自己身兼两个或更多角色，超过三分之一的人职责跨越三个或更多角色；72% 认为 AI 工具是角色变化的首要原因。具体来看，56% 的非设计师大量参与至少一项设计类任务，70% 的产品经理在做低保真原型或线框图，59% 在做交互原型；55% 的受访者接手了过去由别人负责的工作。[23] Figma 是设计协作工具厂商，职能交叉扩大与其业务方向一致，而且这是 2025 年的调查。
Figma 首席执行官 Dylan Field 2025 年 10 月接受 Business Insider 采访时说，参与产品开发的设计师、工程师、产品经理和研究员都在涉足彼此的领域，他预计过去五年开始的角色迁移与合并，未来五年还会加快。他的概括是 “We’re all product builders, and some of us are specialized in our particular area”。[24]
5.3 组织层面的合并
一些公司已经明确调整了产品、设计与工程的分工。据 Business Insider 2025 年 12 月报道，LinkedIn 首席产品官 Tomer Cohen 宣布停办运行多年的助理产品经理（APM）项目，从 2026 年 1 月起改为助理产品构建者（Associate Product Builder）项目，同时教授编程、设计和产品管理；LinkedIn 还推行全栈构建者（Full Stack Builder）模式，要求员工无论来自哪个职能，都能把产品从想法做到上线。[25]
Coinbase 首席执行官 Brian Armstrong 在 2026 年 5 月 5 日的裁员邮件中说，公司将组建 AI 原生小组，其中可能出现一人指挥 agent、同时承担工程师、设计师和产品经理职责的单人团队；公司还将用兼做一线工作的 player-coach 取代纯管理岗位，并把首席执行官以下的管理层级压到五层以内。[26] 据 The Next Web 援引路透社报道，Meta 设立了 AI builder、AI pod lead、AI org lead 等新职位名称，已有约 1000 名员工改用这些头衔。[27]
管理与执行的界限也在变模糊。Coinbase 用 player-coach 替代纯管理岗位，[26] 第 5.1 节中产品经理管理层级的降幅也高于资深个人贡献者。[19] 在团队层面，第 4.2 节的案例是一个具体样本：一名工程师借助 agent 吸收了跨职能小组中的多个角色。[12] 也有公司直接把跨职能要求写进岗位定义，PostHog 的产品工程师手册要求产品工程师与用户交流、决定做什么，并对定价、收入和用户体验负责。[28]
5.4 人与 AI 之间的分工：深度技术岗位
DeepSeek 于 2026 年 9 月 10 日发布 V4.1 Flash。[29] 几天后，DeepSeek 机器学习系统工程师刘胜与在个人微信公众号发表《我不得不把才华埋葬在昨天》。他在文中说 V4.1 的主 Attention 算子出自他手，并在脚注中说明范围只包括 head dim 为 512 的 MQA attention，不含用于选出 top-k 重要 token 的 indexer。[30]
按他的描述，一年之内，AI 在算子设计与编写上从帮忙查文档、读代码、找 bug 的助手，变成了能独立阅读 CUDA 等底层代码、用专业工具逐条分析指令性能、独立优化算子的角色。他估计再过半年到一年，AI 写的算子大概率会追上甚至超过他本人。[30]
对自己的处境，他的判断是“不至于会‘失业’，但必须要‘转业’”：从亲手设计、编写、优化算子，转为 Agent 的“机甲驾驶员”。他的解释是，过去他的兴趣、所长与工业界需求基本一致；如今 AI 把他的所长变成了 AI 更擅长的事，工业界要的也从“会写高性能算子的人”变成了“能用 AI 更快地产出高性能算子的人”。他相信转向之后，自己仍能凭借对工程、上层模型需求和底层硬件的理解，继续高质量、高效率地产出算子。[30]
这是一个人的经历和判断，不能代表整个领域。它展示的是分工的另一条线：这位工程师仍在算子领域工作，没有去承担产品或设计的职能，改变的是他和 AI 之间的分工，执行交给 AI，他负责指挥和把关。转向之后留下来的价值，是贯通模型需求、工程实现和硬件的理解。
5.5 小结
3 月的招聘数据与 6 月的在职数据并不矛盾：前者是某个时点的在招职位，后者是相对 2022 年峰值的累计变化，中间还隔着一轮集中裁员。从本节的证据看，软件行业的分工正沿两条线重组。在人与人之间，职能边界在融合：产品经理做原型和设计，非设计岗位承担设计任务，工程师吸收跨职能小组的角色，管理者兼做执行。在人与 AI 之间，执行越来越多地交给 AI，连高性能算子开发这样的深度技术岗位也转向指挥 AI 实现。另外，新增的软件开发职位集中在高级岗位。
新的岗位形态还没有定型。LinkedIn 的 Full Stack Builder、Meta 的 AI builder、Dylan Field 说的 product builder、PostHog 的 product engineer、刘胜与说的“机甲驾驶员”，描述的工作方式相近，名称、职责范围和职业路径却各不相同。[25][27][24][28][30] 组织里由谁来驾驶 AI，还没有定论。
6 驾驶 AI 的共同要求：规格与验收
这些新岗位名称和范围不一，但对照第 4 节的分析，它们都要负责定义任务和验收结果。本节先讨论验收方式的变化，再讨论不同岗位各自要补的知识。
6.1 验收方式的迁移
Sonar 的调查中只有 48% 的开发者每次检查 AI 代码。这可以看作审查不足，也可以看作验收方式在变。同一调查里，38% 的受访者觉得审 AI 代码比审同事的代码更费力。[6] 代码生成的速度远超人读代码的速度，逐行审查很难再当主要的验收手段，重心会转向运行结果、自动化测试和业务规则比对。设计稿、需求文档由 AI 生成时也是如此，验收越来越依赖对目标和约束的判断。
6.2 通用能力与具体上下文
AI 对各职能的冲击，可以按能力类型区分。一类是通用能力，比如写需求文档、做竞品分析、出常规设计稿、写常见功能的代码。本文认为 AI 在这些工作上已能达到多数从业者的水平。代码和专业文档有第 2 节的测评作部分依据；产品管理还没有直接比较 AI 与产品经理的一手测评，GDPval 中的项目管理专员和产品经理不是同一个职业。[2] 这一判断还需要后续研究检验。
另一类是具体上下文，比如某类用户卡在哪个环节、某个功能之前为什么失败、法务和财务有哪些约束。这些信息通常不在模型的训练数据里，也不会自动进入模型的上下文，和第 4.2 节说的组织内部知识是一回事。[12] Andrew Ng 在 2025 年 7 月的文章里也强调，产品经理要有很强的用户同理心，用数据形成对用户的认识，然后快速决策。[14]
只掌握通用能力的从业者，工作内容和 AI 重合得最多。在人与 AI 的分工中，人的价值在于把具体上下文带进任务定义和结果验收。
6.3 非工程岗位要补的系统理解
对产品、设计等非工程岗位来说，职能融合意味着要懂代码和系统。Ng 谈 AI 产品经理时，把判断技术可行性列为必备能力；[13] Mind the Product 的社区投票中，45% 的产品经理感到技术门槛在提高；[20] LinkedIn 的构建者项目同时教编程、设计和产品管理。[25]
需求的实现路径也在推高这一要求。越来越多需求直接交给 AI 实现，过去由开发者承担的追问需求、补全边界情况的工作少了。现在的 agent 会主动提问，但只会问它意识到的模糊之处；没意识到的，它会自己选一种理解来实现，不同文件里的选择还未必一致。不懂代码的需求方，很难写出足够精确的规格，也很难发现实现与意图之间的偏差。
这里说的懂代码，不要求会写生产级代码，主要是读得懂数据模型，知道实体有哪些状态、由谁修改；能用 AI 做出可运行的原型，拿原型和团队对齐；大致看得懂 AI 生成的代码在做什么，能发现其中没人要求过的假设。
6.4 工程岗位要补的业务理解
对工程岗位来说，职能融合意味着要掌握业务规则和用户需求。拿业务规则比对，前提是懂规则。退款审核期间商家能不能发货，客服重复点击通过会不会导致重复退款，答案由业务决定，从代码里推不出来。开发者既不逐行读代码，又不了解业务规则，交付的东西实际上没有经过有效验收。
开发者手里的上下文，是系统实际怎么运行、业务规则在代码里如何实现，这些 AI 很难直接拿到；要补的是基于这些上下文做产品判断的能力，包括理解用户需求、处理边界情况、权衡功能取舍。DORA 的研究支持这一点。DORA 把以用户为中心列为影响 AI 效果的能力之一，定义为团队理解用户需求、重视用户体验、根据反馈持续调整工作优先级的程度；结论是，用户意识强的团队用上 AI 工具后，效能和团队表现都会提升，缺少用户意识的团队用 AI 反而可能拖累表现。[31]
深度技术岗位也类似，要补的是上下游知识。刘胜与认为自己转向后的价值在于对工程、上层模型需求和底层硬件的理解，[30] 这同样是把具体上下文带进任务定义和验收的能力。
7 案例：产品与工程交界处的规格与验收
本节用“用户可申请退款，由客服审核”这个需求，说明产品与工程交界处的规格与验收具体要做什么。
刘胜与在同一篇文章里还有一层担忧：学生越来越可能用 AI 完成偏重实践的作业，组织代码、构建系统、预判潜在需求并提前在设计上应对、抽象等工程能力因此得不到锻炼；工程能力差的人用上 AI，产出低质量代码的效率可能成倍提高，给系统埋下隐患。[30] 下面讨论的领域建模、状态机和不变量，就是这类抽象与系统设计能力的具体形式，AI 写代码越快，它们越重要。
7.1 状态-事件表
把这个需求整理成状态-事件表（表 2）：行是订单当前状态，列是可能发生的事件。
表 2 退款需求的状态-事件表
| 状态＼事件 | 用户申请退款 | 用户撤销申请 | 客服点击通过 | 商家发货 |
|---|---|---|---|---|
| 已支付 | 进入审核中 | 拒绝 | ？ | 进入已发货 |
| 审核中 | ？ | 回到已支付 | 进入已退款 | ？ |
| 已发货 | ？ | 拒绝 | 拒绝 | 拒绝 |
| 已退款 | 拒绝 | 拒绝 | ？ | 拒绝 |
填表规则是每一格都必须填：要么写明转到哪个状态，要么写明如何拒绝、提示什么。为了让表简洁，这里省略了客服通过之后、退款到账之前支付渠道的异步回调，真实系统中这一段需要单独的状态。
原需求对表里五个问号都没有规定。其中三个比较直观：审核中的订单再次申请退款，算重复提交还是更新理由；审核期间商家能否发货；已发货的订单申请退款，是转入退货流程还是直接拒绝。
另外两个问号容易被当成“不会发生”。已支付的订单收到客服通过，可能是客服打开审核页后用户撤销了申请，客服页面没刷新就点了通过；已退款的订单再次收到客服通过，可能是网络延迟导致重复点击。前一种处理不当，会给已撤销的申请退款；后一种处理不当，会重复退款。用户、客服和商家会同时操作，所以填表规则不允许填“不可能发生”。
状态-事件表是状态机方法的落地形式。对需求方，它提供了检查需求是否完整的标准；对实现方，每个单元格都能转成一条测试用例。
7.2 领域模型
填表还会反过来改变模型。如果审核期间允许发货，就要新增“已发货且退款审核中”这个状态。再往下想，把退款建成有独立生命周期的对象可能更合适。
退款独立出来后，一笔订单可以对应多笔退款，比如先退运费、再退部分商品；每笔退款有申请、审核、退款中、已到账、失败等状态；订单只需记录还剩多少可退金额。原来挂在订单上的“审核中”“已退款”移到退款对象上，订单的状态表变简单了，部分退款也不用额外处理。选哪种模型，取决于业务是否允许部分退款，要找业务方确认。
订单有哪些状态、谁能改变状态、退款和订单是什么关系，都是领域建模要回答的问题。领域驱动设计（DDD）里的聚合、限界上下文等概念正是为此提出的。做这项工作的人不一定要会这些术语，但要把这些问题想清楚。
7.3 不变量与验收
状态-事件表描述的是什么状态下允许什么操作。还有一类规则它表达不了，就是不变量：无论经过什么操作都必须成立的条件，例如一笔订单的累计退款不得超过实付金额。退款独立建模后，这条规则落在订单上，约束它名下所有退款。AI 能照着状态表写出不错的代码，却未必会主动发现这类约束，也难以确定约束的边界，比如运费算不算实付金额，要由业务方决定。
状态表和不变量可以直接用来验收。状态表的每一格对应一条测试用例，例如：对已退款订单再发一次客服通过事件，订单状态不变，退款流水仍只有一条。不变量适合用随机测试：随机生成几千组用户、客服、商家交错操作的序列，每组跑完检查一次累计退款有没有超过实付金额。这类测试不需要读实现代码，只检查业务规则有没有被打破，可以部分替代逐行审查。
传统产品经理很少接触领域模型、状态-事件表和不变量，传统开发者会一部分，但通常不认为这是自己的职责。在产品与工程的交界处，这三样是定义任务和验收结果的基础。
8 实践建议
以下是基于前文分析的建议，没有实证数据支撑。
开发者可以在把任务交给 agent 之前，先写出这次改动涉及的状态-事件表和不变量，写在 PR 描述里即可；出现返工时，回头看问题是否出在表里没写清楚的格子。开发者也可以读客服工单、旁听用户访谈，多接触用户。一个简单的自检办法是：不看代码，说清楚这次改动让用户多了或少了哪些操作，哪些操作会被拒绝。
产品经理和设计师可以从读数据模型入手：让 AI 梳理系统的表结构和状态字段，对照已有的需求文档或设计稿，列出其中没有覆盖的状态，作为下次评审的补充。用 AI 做原型时，尽量接入真实的数据结构，这样才能暴露静态设计稿看不出的状态问题。审阅 AI 提交的代码改动时，重点看新增的状态、接口和判断分支与需求是否一致。
团队层面，一个可行的做法是把需求评审的对象从文字描述换成状态-事件表：需求方带表来，实现方在评审中找出空着或填错的格子。
9 局限性
职能融合不等于人人全能。Dylan Field 说大家都是 product builder，同时也说其中一些人专精于特定领域。[24] 基础设施、安全、性能、数据等方向的价值主要在技术深度；第 5.4 节的个案显示，这类岗位的工作方式在变，但专长本身仍然有价值。
复合型岗位有资历门槛。第 4.2 节案例的主角是 staff engineer，研究把组织内部知识列为约束条件之一。[12] Indeed 的数据显示，美国软件开发职位的增量主要来自高级职位，全部职业的初级职位发布量同比下降。[21][22] 如果复合型岗位普遍要求丰富经验，新人入行的路可能变窄，这对人才培养的长期影响，本文没有展开。
第 4.2 节的研究只有一个案例，能否推广到其他公司和项目还不确定。第 6.2 节认为 AI 在通用能力上已达到多数从业者的水平，但产品管理等领域缺少直接测评，如果后续研究得出相反结论，相关论证需要修改。
第 5 节的数据在口径和来源上有限制。公司在裁员公告中提到 AI，不代表裁员主要因为 AI；[18] 在招职位和在职人数口径不同；在职人数和 Indeed 数据只覆盖美国；社区投票样本量不详；Figma 的调查由设计工具厂商主导，时间是 2025 年。[23] 测试岗位的变化没有找到一手数据，所以没有讨论。岗位数据主要来自美国市场和英文来源，中国等其他市场没有覆盖。
最有力的反对意见是，模型本身也可能学会产品判断。现在的 agent 已经能读客服工单、分析访谈记录和埋点数据，后续模型在判断做什么上可能超过多数人。对此有两点保留。定义问题需要的许多信息从没被记录下来，比如管理层在会上表达的顾虑、大客户私下的反馈、某项合规要求的来龙去脉。另外，功能取舍需要有人为决定负责，负责的人必须理解自己决定的是什么。如果这两点限制都被突破，人在分工中承担的部分还会继续缩小。
Brockman 关于 AGI 的说法，他本人明确限定为个人看法。[1] 本文引用它，只是把它当作模型厂商能力预期的一个例子。
组织层面的实证数据总是落后于模型发布。等 Fable 5、GPT-6 Astra 和 DeepSeek V4.1 这一代模型的落地研究发表，如果组织产出的增幅追上了模型能力的增幅，就说明规格和上下文已经不是主要瓶颈，本文的核心判断也就不再成立。
10 结论
2025 至 2026 年的公开证据显示，在任务定义清晰的前提下，前沿模型在专业任务上的表现已接近或超过资深从业者，工程组织整体产出的增幅却小得多，差距主要出在任务定义和结果验收上。
岗位数据和企业实践显示，软件行业的分工正在重组。在人与人之间，独立的产品经理岗位在收缩，产品经理做原型和设计，非设计岗位承担设计任务，工程师吸收跨职能角色，管理者兼做执行；在人与 AI 之间，执行越来越多地交给 AI，底层算子开发这样的深度技术岗位也在转向指挥 AI。新增的软件开发职位集中在高级岗位。
行业还没有形成统一的新岗位，各家公司的职位名称和职责范围不一，由谁来驾驶 AI 仍无定论。能驾驶 AI 的人却有共同要求：保留一项主要专长，借助 AI 覆盖相邻职能，负责定义任务和验收结果。在产品与工程的交界处，这些要求体现为领域建模、状态-事件分析、不变量设计和按业务规则验收。这些判断可以用后续的组织层面数据来检验。
写作说明
本文写于 2026 年 9 月，所引数据截至 9 月 15 日。
写作中使用了 Anthropic 的 AI 工具 Claude。这次写作本身也是人与 AI 分工的一个例子：检索、起草和逐条核对由 AI 完成，论点取舍和各版草稿的审阅由作者承担。文章观点和内容的准确性由作者负责。
参考文献
[1] VentureBeat. “Welcome to the AGI era”: OpenAI launches GPT-6 Astra. 2026-09-03.
[2] Patwardhan, T. et al. GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks. arXiv:2510.04374, 2025-10.
[3] OpenAI. Introducing GPT-5.2（中文版：隆重推出 GPT-5.2）. 2025-12-11.
[4] Artificial Analysis. GDPval-AA Leaderboard. 2026-09 访问.
[5] METR. Task-Completion Time Horizons of Frontier AI Models. 页面更新于 2026-05-08.
[6] Sonar. Sonar Data Reveals Critical “Verification Gap” in AI Coding（新闻稿）. 2026-01-08.
[7] Becker, J., Rush, N., Barnes, E., Rein, D. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. arXiv:2507.09089, 2025-07.
[8] METR. We are Changing our Developer Productivity Experiment Design. 2026-02-24.
[9] Google Cloud. Announcing the 2025 DORA Report. 2025-09-23.
[10] Murphy-Hill, E., Butler, J., Savelieva, A. Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft’s Early 2026 Rollout of Claude Code and GitHub Copilot CLI. arXiv:2607.01418, 2026-07.
[11] Anthropic. Claude Fable 5 and Claude Mythos 5. 2026-06-09.
[12] Vilas Boas, M., Pinto, G., Monteiro, E. R., Carida, V. F., Ribeiro, D. One Developer Is All You Need: A Case Study of an AI-Augmented One-Person Squad in a Brownfield Enterprise. arXiv:2605.18461, 2026-05.
[13] Ng, A. AI Product Managers Will Be In-Demand. The Batch, 2025-01-15.
[14] Ng, A. How to Get Through the Product Management Bottleneck. The Batch, 2025-07-16.
[15] Delimarsky, D. Spec-driven development with AI: Get started with a new open source toolkit. The GitHub Blog, 2025-09-02.
[16] GitHub. github/spec-kit 仓库. 2026-09-15 访问.
[17] Rachitsky, L. State of the product job market in early 2026. Lenny’s Newsletter, 2026-03-24.
[18] TechCrunch. Monday.com is the latest tech company to blame AI for layoffs, here are 20 others. 2026-07-25.
[19] Ciufudean, A. What the data tells us about tech and PM lay offs in 2026. Mind the Product, 2026-06-25.
[20] Pratt, L. How is AI restructuring product teams?. Mind the Product, 2026-05-11.
[21] Gallacher, G. AI and Job Postings: From Destruction to Creation?. Indeed Hiring Lab, 2026-07-08.
[22] Aidala, F., Puri, S. The Labor Market Is Tilting Toward Seniority. Indeed Hiring Lab, 2026-07-23.
[23] Figma. Are Roles and Responsibilities a Thing of the Past?. Figma Blog, 2025-09-10.
[24] Business Insider（Yahoo Finance 转载）. Figma CEO says job titles are merging thanks to AI, and everyone is a ‘product builder’. 2025-10-17.
[25] Business Insider（AOL 转载）. LinkedIn is scrapping its associate product manager program and rebuilding around full-stack talent. 2025-12-05.
[26] Fortune. Coinbase didn’t just lay off 14% of its staff due to AI. It replaced managers with ‘player-coaches’ and turned its org chart upside down. 2026-05-05.
[27] The Next Web. Meta to cut 8,000 jobs on 20 May with more layoffs planned for second half of 2026. 2026-04-19.
[28] PostHog. What is a product engineer?. Product Engineer Handbook.
[29] DeepSeek. Change Log（2026-09-10：DeepSeek-V4.1-Flash 发布）. DeepSeek API Docs.
[30] 刘胜与. 我不得不把才华埋葬在昨天. 作者个人微信公众号, 2026-09-14.
[31] DORA. Capabilities: User-centric focus. 页面日期 2026-01-12.