AI 编程真正改变的,不是写代码,而是软件公司的产能

BLACK CROW / SYSTEM PROFILE ◎

ISSUE 17 / 国内 / BLACK CROW NIGHT TALK

编程变成产能系统

AI 编程真正改变的，不是写代码，而是软件公司的产能

黑鸦夜谈 / 17 / 黑曜叙事

凌晨一点，线上故障已经定位，修复代码却还在排队。第二天，团队用 coding agent 生成了补丁，测试、审查、发布也跟着被重新安排。真正的变化不是“代码写得更快”，而是原本串行的等待被拆开了。

软件公司的瓶颈，很多时候不在键盘前，而在需求澄清、环境准备、测试反馈和上线审批之间。代码只是流水线中最显眼的一段。

当写代码变快，所有被代码掩盖的等待都会浮上来。

需

求

拆

分

之

后

，

A

g

e

n

t

才

能

真

正

参

与

排

期

。

一

个

任

务

若

无

法

在

短

周

期

内

被

验

收

，

就

很

难

知

道

是

模

型

没

做

好

，

还

是

目

标

本

来

就

没

有

说

清

楚

。

颗

粒

度

决

定

反

馈

速

度

。

如果需求仍然模糊，Agent 只会更快地产生错误方向；如果测试覆盖不足，生成速度越快，返工越多；如果发布权限没有调整，代码堆积只会变成新的等待。

所以 AI 编程首先改变的是分工。工程师从逐行实现者，转向任务拆解者、约束设计者和结果审查者。产品、测试、运维也不能继续把自己的环节当作“交给开发之后再说”。

软件产能不是提交了多少行代码，而是有多少可靠变化真正到达用户手里。

测

试

不

应

只

是

最

后

的

门

卫

，

而

要

成

为

生

成

过

程

的

一

部

分

。

让

A

g

e

n

t

在

写

完

代

码

前

先

读

现

有

测

试

、

补

边

界

用

例

，

再

提

交

变

更

，

能

把

不

少

“

看

起

来

完

成

”

的

工

作

挡

在

前

面

。

高产能团队会把需求改写成一组可验证的任务：输入是什么，输出长什么样，边界在哪里，如何测试，失败如何撤回。Agent 在这样的约束里工作，才不会把“完成”误解成“生成了一段代码”。

同时建立四个反馈环：需求验收、代码审查、自动测试、线上观测。每个环节都要能把结果返回给 Agent 和人，而不是只在最后一次性发现问题。

产能检查表：需求是否可验收；任务是否可拆分；测试是否自动化；权限是否分级；发布后是否可观测。

新

的

分

工

也

会

改

变

管

理

方

式

。

主

管

不

必

盯

每

个

人

写

了

多

少

，

而

要

看

团

队

是

否

有

足

够

清

晰

的

上

下

文

、

足

够

快

的

反

馈

和

足

够

安

全

的

发

布

权

限

。

工

具

升

级

，

管

理

指

标

也

要

升

级

。

组织还要重新定义“完成”。代码生成出来，只能算实现完成；通过测试，才算质量完成；被用户使用并可观测，才算交付完成。几个完成不是一回事。

Agent 让并行工作更容易，但并行并不自动带来协同。任务之间的依赖、接口约束和负责人仍要被明确，否则只是把等待从一个队列搬到另一个队列。

对新人来说，AI 既降低了写出第一版的门槛，也提高了理解系统的要求。团队更应把架构、决策和失败案例沉淀成可读的上下文。

软件公司的新产能，是机器速度和组织记忆叠加后的结果。缺任何一层，所谓提速都可能只是一阵短暂的兴奋。

一家公司的流程如果靠口头记忆、私人脚本和某个老员工的经验维持，AI 只会把这种脆弱更快地复制。看起来提交更多，实际上知识债务和维护债务同时增长。

因此，组织必须把隐性规则写出来：目录约定、接口契约、检查命令、回滚方式、谁拥有最终批准权。文档不是为了培训新人，而是为了让机器和新人都不必猜。

AI 编程最先淘汰的，可能不是某一种语言，而是那些只能靠等待和传话维持的流程。

产

能

提

升

会

带

来

更

多

尝

试

，

这

是

好

事

，

也

会

带

来

更

多

废

弃

代

码

。

仓

库

需

要

更

明

确

的

生

命

周

期

、

负

责

人

和

清

理

机

制

，

否

则

速

度

产

生

的

资

产

会

很

快

变

成

噪

音

。

管理者可以每周不看提交量，先看三件事：从想法到可测试版本用了多久，从发现问题到修复用了多久，从修复到安全发布又等了多久。时间链条缩短，才叫产能提升。

工程师也需要保留自己的判断权。把重复实现交给 Agent，把架构边界、风险取舍和业务语义留给人。机器负责扩大手，人负责决定方向。

AI 编程的终点不是没人写代码，而是软件公司终于开始管理“变化如何可靠地产生”。

最

好

的

团

队

不

会

把

A

g

e

n

t

当

作

替

代

某

个

人

的

按

钮

，

而

会

把

它

当

作

一

名

执

行

力

很

强

、

但

必

须

被

约

束

和

复

核

的

协

作

者

。

这

样

，

效

率

和

工

程

纪

律

才

不

会

互

相

抵

消

。

因此，团队应把节省下来的时间投向更高杠杆的工作：澄清边界、补齐测试、重构接口、理解用户。若只是用机器把旧任务做得更快，却不改变任务本身，产能红利很快会被新的需求吞掉。

当团队开始用结果而非代码量衡量产能，很多被忽略的工作会重新获得位置：删除无用接口、降低维护复杂度、改善错误提示、补齐监控。这些工作不一定产生更多提交，却会让软件更容易持续变化。

产能系统还会改变招聘和培养。团队需要更多能读懂业务、拆解问题、验证结果的人，而不只是熟悉某个框架的人。基础编码能力仍然重要，但它会与测试意识、系统思维和沟通能力一起，决定一个人能否把机器的速度转化成可靠交付。

黑曜叙事 / END

黑鸦夜谈 · 黑鸦