PTT職涯區 / Soft_Job (軟體人)

[討論] AI的陷阱。認知債(Cognitive Debt)

看板Soft_Job (軟體人)作者 (3d)時間3周前 (2026/02/20 08:37), 編輯推噓56(58推 2噓 170→)
留言230則, 31人參與, 2天前最新討論串1/1
寫軟體的，之前有所謂的技術債(Technical Debt)。AI時代，現在又多了個認知債(Cognitive Debt) 認知債應該是去年mit的研究人員的創詞 https://www.brainonllm.com/ 隨便一個中文摘要 https://www.managertoday.com.tw/articles/view/70533 雖然研究的課題是寫作，但其實是關於思考(Thinking) 然後今年一月29日Anthropic贊助的研究。 https://www.anthropic.com/research/AI-assistance-coding-skills https://arxiv.org/abs/2601.20245 使用ai輔助寫程式的，比不用ai的人，程式碼的理解能力顯著下降。尤其除錯能力(debugging)下降最多。 然後Margaret-Anne Storey分享她的經驗 https://margaretstorey.com/blog/2026/02/09/cognitive-debt/ "Student teams were building software products over the semester, moving quickly to ship features and meet milestones. But by weeks 7 or 8, one team hit a wall. They could no longer make even simple changes without breaking something unexpected.When I met with them, the team initially blamed technical debt: messy code, poor architecture, hurried implementations. But as we dug deeper, the real problem emerged: no one on the team could explain why certain design decisions had been made or how different parts of the system were supposed to work together" 是認知債不是技術債的問題，修好一個錯誤但會創造其他錯誤。整個案子就卡住了。 Simon Willison，如果他說他是ai coding的鼓吹者第二名，那沒人敢說第一。也回應了 https://simonwillison.net/2026/Feb/15/cognitive-debt/ "I've experienced this myself on some of my more ambitious vibe-code-adjacent projects. I've been experimenting with prompting entire new features into existence without reviewing their implementations and, while it works surprisingly well, I've found myself getting lost in my own projects. I no longer have a firm mental model of what they can do and how they work, which means each additional feature becomes harder to reason about, eventually leading me to lose the ability to make confident decisions about where to go next." 早說 為什麼不早說 -------------------- 其實我也講很久了，ai是有幫助的，但用ai寫程式大概是最糟糕的方式。前面就算進展快，但後面反而會更慢。 最近win11 updates一堆奇怪嚴重的bugs，我都懷疑是微軟all in AI造成的結果。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 58.114.66.74 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1771547845.A.92C.html
→
02/20 08:45, 3周前 , 1F
我是覺得 vibe coding 本質上是幻覺
02/20 08:45, 1F
→
02/20 08:45, 3周前 , 2F
即使用 ai 寫程式完全不意味著你就不需要了解它了
02/20 08:45, 2F
→
02/20 09:10, 3周前 , 3F
就像讀書需要練習，只是背過，但實習，你能了解多少。
02/20 09:10, 3F
→
02/20 09:11, 3周前 , 4F
coding其實是一邊寫，一邊在想也在學習。
02/20 09:11, 4F
推
02/20 09:13, 3周前 , 5F
有這種發現不令人意外啊。想想老闆就知道了，自從他們
02/20 09:13, 5F
→
02/20 09:13, 3周前 , 6F
不再碰程式碰系統，只負責提供目標和驗收標準後，出了
02/20 09:13, 6F
→
02/20 09:13, 3周前 , 7F
問題是不是急著叫你修而很難自己當黑手伸進去修？
02/20 09:13, 7F
→
02/20 09:16, 3周前 , 8F
當初內部邏輯是你構建的，你完善的，你會比較有印象，
02/20 09:16, 8F
→
02/20 09:18, 3周前 , 9F
有狀況會比較容易分析問題。我不知道別人用法保守的
02/20 09:18, 9F
→
02/20 09:19, 3周前 , 10F
考量，但我即便知道CLI突飛猛進，但暫時也只把AI當顧問
02/20 09:19, 10F
→
02/20 09:19, 3周前 , 11F
之一，考慮的點就是這個。不過這是工作模式的取捨，
02/20 09:19, 11F
→
02/20 09:20, 3周前 , 12F
對規模小，設計模式經常重複，風險又很低的開發工作，
02/20 09:20, 12F
→
02/20 09:22, 3周前 , 13F
如果LLM已針對情境最佳化，那交給AI寫也未嘗不可。
02/20 09:22, 13F
→
02/20 09:35, 3周前 , 14F
這種比較是叫AI寫出能跑的後，沒在管spec和review
02/20 09:35, 14F
推
02/20 09:37, 3周前 , 15F
就像看書一樣，你不用想的想出來，只有用看的很快就忘記
02/20 09:37, 15F
→
02/20 09:37, 3周前 , 16F
自己在衝三小，基本上除了coding 應該很多事都會有這問題
02/20 09:37, 16F
→
02/20 09:37, 3周前 , 17F
，總結：人類快沒有錄用了
02/20 09:37, 17F
→
02/20 09:39, 3周前 , 18F
其實單純看spec review 也跟你自己想出來的差別很大，自
02/20 09:39, 18F
→
02/20 09:39, 3周前 , 19F
己用AI開始寫程式後，真的對程式碼的掌控力下降很多
02/20 09:39, 19F
→
02/20 09:40, 3周前 , 20F
所以天天還是會透過Leetcode來訓練大腦，我覺得在這個時
02/20 09:40, 20F
→
02/20 09:40, 3周前 , 21F
代反而這種鍛鍊變得好重要，防止腦殘lol
02/20 09:40, 21F
推
02/20 10:15, 3周前 , 22F
大部分東西太久沒碰能力多少會下降
02/20 10:15, 22F
→
02/20 10:16, 3周前 , 23F
但產出增加的話 即使認知下降 市場還是會傾向如此
02/20 10:16, 23F
推
02/20 10:17, 3周前 , 24F
個人是感興趣的topics 就動手寫，動手才比較容易思考各個
02/20 10:17, 24F
→
02/20 10:17, 3周前 , 25F
面向，至於不感興趣只需要交差的，AI 輔助只做review
02/20 10:17, 25F
推
02/20 10:30, 3周前 , 26F
和導航一樣，用久了方向感也會變弱，大腦就用進廢退
02/20 10:30, 26F
推
02/20 10:44, 3周前 , 27F
絕大部分人只負責一小部分，我很少看到一個人負責幾百萬
02/20 10:44, 27F
→
02/20 10:44, 3周前 , 28F
行代碼的。一個人通常最多只負責幾萬到十幾萬行代碼。當
02/20 10:44, 28F
→
02/20 10:44, 3周前 , 29F
責的部分這麼小用AI幾乎不會有問題
02/20 10:44, 29F
推
02/20 10:54, 3周前 , 30F
跟我想的一樣，人類的認知變得非常重要
02/20 10:54, 30F
推
02/20 11:07, 3周前 , 31F
覺得正常，我長時間沒寫C++後也會退化
02/20 11:07, 31F
推
02/20 11:12, 3周前 , 32F
第二個她說她沒有review，會lost掉也很正常，像我每行ai
02/20 11:12, 32F
→
02/20 11:12, 3周前 , 33F
寫的代碼都有review，掌握度就比較高
02/20 11:12, 33F
推
02/20 11:16, 3周前 , 34F
只審核不用親手寫，同時可以保有速度和掌握度，而且量變
02/20 11:16, 34F
→
02/20 11:16, 3周前 , 35F
終究會產生質變，以前手刻時代一年一萬行，平均每天就手
02/20 11:16, 35F
→
02/20 11:16, 3周前 , 36F
刻三十行。AI時代我一個月大概三五萬行，一天看代碼就要
02/20 11:16, 36F
→
02/20 11:16, 3周前 , 37F
一千行，完全可以抵掉沒手寫那三十行的熟悉度
02/20 11:16, 37F
推
02/20 11:20, 3周前 , 38F
其實SOC或是5G也是，像手機晶片越做越大，spec越來越厚
02/20 11:20, 38F
→
02/20 11:20, 3周前 , 39F
，已經很難有人說他可以掌握全局了
02/20 11:20, 39F
還有 151 則推文
→
02/22 00:13, 3周前 , 191F
秒寫一個貪食蛇耶
02/22 00:13, 191F
→
02/22 00:13, 3周前 , 192F
有bug就重寫大前提是可以承受prod bug再修 或是有超級完
02/22 00:13, 192F
→
02/22 00:13, 3周前 , 193F
整的測試
02/22 00:13, 193F
→
02/22 00:13, 3周前 , 194F
你還是看不懂我想表達的喔？
02/22 00:13, 194F
→
02/22 00:13, 3周前 , 195F
有bug是測試期發現的 馬上發現 馬上修 馬上更新迭代
02/22 00:13, 195F
→
02/22 00:14, 3周前 , 196F
而需要重寫的專案99.87%都沒有足夠完整的測試 AI也寫不
02/22 00:14, 196F
→
02/22 00:14, 3周前 , 197F
出來
02/22 00:14, 197F
→
02/22 00:14, 3周前 , 198F
在你人為都還沒發現bug的狀況下 AI早就已經發現然後修掉了
02/22 00:14, 198F
→
02/22 00:14, 3周前 , 199F
我看得懂你講的工作環境和一般狀況大相逕庭
02/22 00:14, 199F
→
02/22 00:14, 3周前 , 200F
測試也全是AI 當然安全性也全是AI Antropic昨天剛出了安全
02/22 00:14, 200F
→
02/22 00:15, 3周前 , 201F
性的產品 全自動一條龍
02/22 00:15, 201F
→
02/22 00:15, 3周前 , 202F
這就是軟體的未來
02/22 00:15, 202F
→
02/22 00:15, 3周前 , 203F
那除非你是2080來的
02/22 00:15, 203F
→
02/22 00:16, 3周前 , 204F
02/22 00:16, 204F
→
02/22 00:16, 3周前 , 205F
現在說AI補測試可以比小修現有code安全那就沒人會信的
02/22 00:16, 205F
→
02/22 00:16, 3周前 , 206F
反正推文就留著 一年後回來 全自動會是顯學 我話就放這裡
02/22 00:16, 206F
→
02/22 00:17, 3周前 , 207F
一年前 也沒人相信AI agent寫程式會寫出什麼鬼出來
02/22 00:17, 207F
→
02/22 00:17, 3周前 , 208F
資安漏洞修補和這個話題有個屌關係
02/22 00:17, 208F
→
02/22 00:17, 3周前 , 209F
現在包括Linus uncle bob一票大神通通都在用agent
02/22 00:17, 209F
→
02/22 00:17, 3周前 , 210F
現在在講業務邏輯可能會被改壞
02/22 00:17, 210F
→
02/22 00:18, 3周前 , 211F
AI企業他們最終的目標 就是將所有產品串起來 全自動化
02/22 00:18, 211F
→
02/22 00:19, 3周前 , 212F
喔我也可以推文留在這裡 10年後全世界銀行醫院etc.超過8
02/22 00:19, 212F
→
02/22 00:19, 3周前 , 213F
7%還是不會為了修bug把舊專案直接重寫
02/22 00:19, 213F
→
02/22 00:25, 3周前 , 214F
很好 讓時間證明一切 等著瞧
02/22 00:25, 214F
推
02/22 01:01, 3周前 , 215F
不用跟他吵啦 講出什麼言論的就是什麼水準XD
02/22 01:01, 215F
→
02/22 01:02, 3周前 , 216F
我第一份也是管這種可有可無 出事沒啥差的專案
02/22 01:02, 216F
→
02/22 01:03, 3周前 , 217F
這種妳讓AI隨便爆改確實沒差 因為 nobody cares
02/22 01:03, 217F
→
02/22 01:13, 3周前 , 218F
叫ai修就好了 修不好 大不了換一間公司
02/22 01:13, 218F
推
02/22 07:13, 3周前 , 219F
如果是工具性質且可以透過測試確保符合需求的東西，我認
02/22 07:13, 219F
→
02/22 07:13, 3周前 , 220F
同出bug時可以乾脆砍掉重寫，AI讓這個迭代成本低很多
02/22 07:13, 220F
→
02/22 07:16, 3周前 , 221F
反之如果是維護性質、沒有快速測試手段的大型服務就不適
02/22 07:16, 221F
→
02/22 07:16, 3周前 , 222F
合這麼做，砍掉重練會帶來大量的不確定性，炸掉就完了
02/22 07:16, 222F
→
02/22 12:49, 3周前 , 223F
所以這完全是中文的問題
02/22 12:49, 223F
→
02/22 12:56, 3周前 , 224F
問題是有人要為了修壞負責嗎
02/22 12:56, 224F
→
02/22 12:57, 3周前 , 225F
尤其是法規要求嚴苛的金融和醫療
02/22 12:57, 225F
→
02/22 14:37, 3周前 , 226F
對喔醫療修壞就慘了@@
02/22 14:37, 226F
推
02/22 16:24, 3周前 , 227F
講的好像每個環境都能搞全AI開發一樣XD
02/22 16:24, 227F
→
02/22 16:25, 3周前 , 228F
目前就還在發展階段...
02/22 16:25, 228F
→
02/22 21:05, 3周前 , 229F
幫欠債不要不是被追殺都無所謂吧XD
02/22 21:05, 229F
→
03/14 21:00, 2天前 , 230F
敢讓ai這樣速成的八成出事也不用賠多少錢
03/14 21:00, 230F
‣ 更多 oopFoo 的文章
文章代碼(AID): #1fbwp5ai (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 oopFoo 的文章
文章代碼(AID): #1fbwp5ai (Soft_Job)