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/zh-hant/posts/weakly-articles-02/
作者
Amiya_desi
發布於
2026-09-27
許可協議
CC BY-NC-SA 4.0

部分資訊可能已經過時

我眼中的中國大學生羣像
新坑,每週互聯網文章閱讀——出師未捷身先死?