文章总结： 文章指出软件研发正从手工艺模式转向工厂模式，AI和Agent将接管编码、测试等流程，使执行成本大幅降低。作者认为Scrum等传统管理方法因信息同步和产能预测问题被AI化解而失效，未来瓶颈将集中在需求定义和架构设计。同时提到AI工具带来100%效率提升可能导致企业通过裁员优化团队规模，决策层和Agent驾驭者将成为组织核心。 综合评分： 76 文章分类： 安全开发,解决方案,安全运营

分享下最近 AI Coding 的顿悟时刻。

原创

阿颖 阿颖

AI产品阿颖

2026年6月2日 19:25 北京

在小说阅读器读本章

去阅读

写一些最近我们公司 AI Coding 的真实感触。我能明显感觉到，我们现在确实在一个十字路口。

#01

软件研发正在告别手工时代

软件研发正在从手工艺模式走向工厂模式。

手工艺模式下，工程师亲自写代码、亲自 review、亲自测试，像手工造一辆车，灵活但是慢，质量也不稳定，大部分知识都散落在每个人的脑子里。

工厂模式则像现代车厂，有一条标准化的生产线。

从写代码到 review、测试、部署、监控，大量步骤交给 AI 和 Agent 来跑，人退到后面，负责设计这条生产线、设定规则、处理例外。

这已经是大势所趋了。Software Factory 接下来半年内，一定会成为所有软件公司的标配。

#02

我们的软件开发流程

所以，要把工程生命周期当成工厂来看。做汽车有装车门、装方向盘、喷漆这些独立工序，软件工程也可以拆成小的、可组合的环节。

比如分支命名、API 的 service-repository pattern、analytics 埋点、测试、QA，都可以沉淀成 skill。

这里的 skill 不是随便拿别人写好的模板来用，因为不同公司有自己的工程口味和产品手感。

真正重要的是，把自己团队长期形成的模式和护栏，固化进 Agent 能执行的流程里。

我们团队的流程是：

先写 spec，然后让 Agent 反向采访人，把需求问清楚。接着由 Agent 生成 LDD，也就是 Lightweight Design Document。

这个 LDD 会参考公司过去的设计文档，尽量保持同一种工程风格；然后系统自动生成 tickets，再生成 PR。

#03

SCRUM 已经没什么用了

AI Native 的研发团队里，过去很多流程其实都值得重新审视了。比如 Scrum、站会、Sprint、Story Point，甚至项目经理这样的角色。

这些东西当年出现的时候当然有价值，而且价值很大。

因为它们解决的是当时软件工程最大的瓶颈，诸如团队怎么高效协同，怎么做信息同步，以及尽量减少执行过程中的不确定性。

拿 Scrum 来说。

很多人会觉得它是在管理项目。其实不是。它本质上是在管理不确定性。

过去的软件开发里，最大的未知数是工程师什么时候能把东西做出来，一个需求应该拆成多少任务，哪些任务先做，哪些任务后做，需要投入多少人。

为了管理这些不确定性，于是才有了 Sprint、Story Point、Standup、Project Manager 这些概念。

但 Agent 出现之后，一个特别大的变化发生了。软件开发里最不确定的部分，正在变成最确定的部分。

过去最难预测的是执行。今天最容易预测的反而是执行。

很多原本需要多个角色协同推进的工作，开始变成了一条自动化流水线。

这时候再回头看 Scrum，会发现它依赖的很多前提已经开始变了。

站会存在的前提，是信息不同步。Sprint 存在的前提，是产能有限，需要提前规划。Story Point 存在的前提，是执行成本难以预测。项目经理存在的前提，是大量依赖关系需要协调。

但今天，这些问题都在快速被 Agent 消解。

Scrum 诞生的时候，软件行业最稀缺的资源是工程师的时间。Agent 时代，最稀缺的资源已经变成了正确的判断。

当稀缺资源发生变化，围绕旧资源建立起来的管理体系，自然也到了该重构的时候。

#04

架构设计非常重要

当执行成本越来越低之后，团队的瓶颈其实开始往前移动了。

我觉得未来研发团队最大的瓶颈，大概只剩下两个。一个是需求定义。一个是架构设计。

需求定义很好理解。

Agent 可以很快把一个功能做出来。但它没办法替我们判断这个功能到底该不该做。很多团队今天最大的浪费，已经不是开发太慢，而是做错了需求。

方向错了，执行越快，反而离正确答案越远。

架构设计也是一样。

说实话，这件事我暂时还不太愿意完全交给 Agent。

因为决定一个系统未来几年命运的，从来都不是代码量。而是架构。

数据库怎么设计，服务怎么拆分，模块边界怎么划分，哪些地方需要解耦，哪些地方需要提前预留扩展能力。

这些决策一旦做错了，后面代码写得再快都很难补救，或者补救起来比较麻烦。

Agent 可以在极短时间内生成大量代码。但如果架构方向错了，那几十万行代码很多时候只是技术债务。

架构能力依旧重要。

#05

AI 裁员是真实的

我们团队最近已经全面切到 Codex 了。

从日常使用来看，一个工程师每个月至少需要 200 美金的额度，而且很多时候 200 美金其实都不太够。

但用下来之后，我慢慢意识到一件事。200 美金确实能带来非常明显的效率提升。甚至提效 100% 都不夸张。

问题在于，提效 100%，不等于收入增长 100%。

这两件事完全不是一回事。

举个简单例子。

以前一个团队 10 个人，一个月能做 10 个功能。

现在有了 Codex、Claude Code 这些工具。同样 10 个人，一个月可能能做 20 个功能。

对于公司来说，会出现两个选择。

第一种选择。保持 10 个人，把功能开发速度提升一倍。

第二种选择。把团队缩减到 5 个人，继续维持原来的开发速度。

这也是为什么这两年越来越多公司一边疯狂采购 AI，一边裁员。

很多人觉得这是因为 AI 把人替代了。

我觉得不完全是。

更准确地说，是 AI 提高了单位员工的产出能力。

当一个工程师能够完成过去两个工程师的工作时，公司自然会重新思考团队规模。

以前一个工程师一年成本假设 50 万。

现在公司额外给他买 2400 美元一年（约 1.7 万人民币）的 Agent 额度。

如果这个工程师因此能够顶两个人。

那公司实际上是在用不到 4% 的额外成本，换取接近 100% 的产出提升。

这笔账对于老板来说太容易算了。

我越来越觉得，未来企业组织的变化，是组织结构开始向两端收缩。

中间大量负责执行和传递信息的岗位会越来越少。留下来的，要么是负责方向和决策的人。要么是能够驾驭 Agent 的人。

很多公司裁员，本质上不是因为业务变差了。而是因为过去需要十个人完成的工作，现在五个人加一堆 Agent 就能完成。

这才是 AI 对组织结构真正的影响。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：AI产品阿颖 阿颖 阿颖《分享下最近 AI Coding 的顿悟时刻。》