2192 字
6 分钟
每周互联网文章阅读2——Own the Slice
2026-09-27
Amiya_desi

原文链接

解读#

人工智能已经将编写代码的成本降低得比完成产品工作的成本降低得更快,这篇文章将阐述一个单人可以从客户需求到交付结果全程负责的工作单元

文章在开头列出了一个场景,说看上去多任务并行其实并没有什么问题,可是实际上根据这个研究https://contextcost.com/the-research,你每次多任务并行其实都会在中间消耗更多的切换时间,作者引用 Weinberg 的经典经验估计来说明并行项目的上下文切换成本:随着同时承担的项目增加,用于重新载入上下文的时间可能迅速上升

两个项目就会占用你原本总时间的1/5,如果是同时并行5个项目,则几乎会占据你的3/4,而这些只是切换时间,100%减去切换时间后,再除以项目数量,你的开发效率就会变得很低了,需要注意的是,这组百分比本身是经验估计,而非严格实验结果,然后引入本文的核心概念slice

slice在笔者看来是一个纵向切片 / 可交付结果:它不是按技术结构切,而是从一个真实需求出发,贯穿为了完成它所需要的所有层,最后交付一个用户能实际感知到的结果,然后也顺便介绍了INVEST检查清单,是一种敏捷编程的范式之一

然后作者提到了人工智能目前来说真正的作用,在实现的环节大幅减少了时间,但是在决策的的环节节约的时间却很有限,最终的结果反而可能是总体开发时间上升,文章中引用的一个有趣的实验https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/就是如此

作者把数年 DORA 报告排列在一起形成了一条“AI 从扰乱生产系统到逐渐被系统吸收”的叙事线,但这些年度结果并不是严格意义上的同一组对象纵向追踪,因此我更愿意把它看成一种趋势线索,而不是已经被证明的因果过程

我的理解#

其实文中对于 AI 的解释,在今天看来已经算是技术圈中比较常见的认识了:AI 更像是一种极强的提效工具,而不是一个真正意义上的“万能许愿机”

它可以极大压缩实现阶段所需要的时间,但项目开发并不只有实现。需求判断、方案设计、测试、Review、整合、验收,这些环节并没有以相同的速度被压缩

于是问题就出现了

以前开发一个功能,最昂贵的部分可能是“把它写出来”;而现在有了 AI 以后,“写出来”本身越来越便宜,真正昂贵的东西反而逐渐变成了:决定应该做什么、判断生成的东西是否正确,以及把一件事情真正完成

换句话说,AI 并没有消灭开发中的瓶颈,它只是让瓶颈发生了迁移

这也是我觉得 slice 这个概念真正有意思的地方

如果实现成本越来越低,那么人会很容易陷入一种新的陷阱:因为“开始做一件事”太便宜了,所以同时启动越来越多的任务。让 AI 写一个功能只需要一句 Prompt,再开一个 Agent 做另一个功能也几乎没有额外心理成本,看起来所有东西都在同时推进

可是这些产出最终仍然需要有人去理解、测试、修改和决定是否接受,而这个人通常还是自己

于是 AI 带来的生产力提升,可能反而制造出更多尚未验收的代码、尚未完成的功能和需要重新加载的上下文。代码产生得越来越快,但真正完成的东西未必同比增加

从这个角度来看,slice 更像是一种对这种趋势的约束

与其把工作拆成“实现数据库”“写一个 UI”“增加一个 API”这样的技术任务,不如把目标定义成一个完整、可验证的结果,例如“用户现在可以完成以前无法完成的一件事情”

AI 仍然可以帮助实现其中的数据库、UI、API 和测试,但这些东西不再分别被视作几个完成的任务,而只是同一个结果中的不同组成部分

这让我想到自己目前使用 Coding Agent 时的一些体验

以前我需要亲自编写代码,所以能同时推进的东西天然有限。但现在我可以同时让几个 Agent 修改不同的项目:游戏、网站、自动化脚本,甚至同一个项目里的几个功能

表面上看,我的“开发速度”确实变得非常快

但 Agent 完成以后,我如果想要能参与到修改过程中,仍然需要逐个阅读它们做了什么,确认修改有没有破坏已有逻辑,运行测试,再把这些东西重新装进自己脑子里的项目模型中

真正的瓶颈可能已经从“写代码太慢”,变成了“我没有足够的注意力去理解和验收所有 AI 产生的东西”

所以我觉得,AI 时代一个重要的能力可能不是同时驱动多少个 Agent,而是控制自己同时有多少件“尚未真正完成的事情”

这也是我从这篇文章中看到和得到的东西

slice 是否真的是最好的解决方案,我还不确定。有些底层重构、技术债或者性能优化,很难直接对应一个用户可以感受到的结果;而让一个人从需求一直负责到交付,也可能带来另一种认知负担

但它至少提供了一个很有意思的视角:

当代码越来越便宜以后,我们是否应该开始把“完成”而不是“实现”作为衡量开发进度的基本单位?

过去我们很容易把“写完了一段代码”“完成了一个功能模块”理解为进度,但在 AI 大幅降低实现成本之后,这种衡量方式也许正在逐渐失效

真正重要的,可能不再是我们制造了多少代码,而是有多少事情真正穿过了设计、实现、验证和整合,最终成为了一个可以被使用、被体验、被交付的结果

如果是这样的话,那么 AI 时代真正稀缺的东西,也许就不只是实现能力,而是对范围、注意力和“完成”本身的控制能力

尾声#

呼…读文章好累啊…而且还是这种专业性的文章…而且还很长

而且怎么说呢,我的真实阅读感觉,其实要么就是感觉是完全没有必要讲的东西,要么就是一堆根本看不懂的东西

其实也就是知识的诅咒吧,当你了解一个知识后,你就很难去想象你不理解这个知识之前的自己

而如果你想要做这种分享出自己的体悟啊之类的,你又得必须把这些东西很好的用语言表现出来,否则如果只有你一个人才能看懂的文章,这是否也能被叫做文章是存疑的…

分享从来就不是一件简单的事情啊…克服不敢分享的心理,其实也只是最前面的门槛罢了,如何更好的表达自己的观点,展示自己的理解,有理有据,同时文章又能写的引人入胜

有点像这篇文章里说的那样:

“写出来”,并不等于“完成”

打赏
0
打赏
分享
# 读后感 # 文章分享
最后编辑 2026-09-27
每周互联网文章阅读2——Own the Slice
https://blog.sayori.org/posts/weakly-articles-02/
作者
Amiya_desi
发布于
2026-09-27
许可协议
CC BY-NC-SA 4.0

部分信息可能已经过时

新坑,每周互联网文章阅读——出师未捷身先死?