突然覺得值得回一篇，因為你在問的問題我最近才想過。 當然不是「有了AI之後，還需要 XXXX？」 這種換個 XXXX ，就能重新發一篇的格式廢文。 我還順便看了你在版上的其他文章，我覺得你其實有感受到真正的問題， 缺乏的是問出好問題的能力。 說的是#1cUZCuPN (Soft_Job) [ptt.cc] [討論] FP正在殺死設計模式嗎？ 零基礎知識的 vibe coder 需不需要 git 我不知道， 但有基礎知識的世界第一個 vibe coder → Linus Torvalds 就是發明 git 的人。 每個人工作的方式跟目的都不同， 你要論證這個題目可能得去找沒 git 知識的初學 vibe coder， 分成兩組：一組補充簡單 git 概念，一組限制不能知道什麼是 git。 我相信最終你根本得不到什麼結論。 個人認為軟體工程的直覺會破壞大腦的運作， 讓你容易認定工作的結果跟工作的模式有直接關聯。 你花大把的時間改善的只是效率或品質，(可能間接影響你能不能產出結果，) 但這跟是不是能走向預期的結果不是同一個問題。 這說的是你把使用工具的知識跟解答問題的知識綁在了一起， 如果能清楚的拆開，那這題根本不需要討論。 直覺是一個簡單判斷條件： 如果產出結果必定需要某個工具，那使用工具的知識是必須的。 如果要開發 ios 程式是不是要學 swift？ 如果要開發一個在 ios 上做健康管理的 app 是不是要學 swift? 很顯然你問的問題很像後者，大部分的人會回答你健康管理的知識比學 swift更重要。 而今天，「學 swift」的位子可以用 AI 一詞替上。「健康管理的知識」也可以。 這才是現在每個人都在面對的問題，而且他沒有答案。 ＝＝＝＝＝ 其實想回答的是抽象語意的這題，這跟我最近在做的題目有關， 而我覺得我手上有你要的答案。 要先搞清楚的一點是 git 其實很複雜，這也是我一直覺得他很難使用的原因。 git 的底層實作是快照(snapshot)，那是資料/資料庫領域的東西。 但它的心智模型卻是補丁(patch) 和增量。 最初我猜這原因來自：早期大家熟悉的版本控制都是補丁模型。但這好像沒真正解釋。 AI 給我的答案是因為分散式協作需要 Code Review 和 Branch (尤其是Long-lived)。 Code Review 需要的就是 diff △ (也就是patch)，看看這次變更了哪裡。 而 Branch 最終要 Merge 和 Rebase，你要解決衝突時也是 diff。 這觀念最後影響了 Dolt — 把 Git 的增量概念套上了 SQL。 你推文舉的 Jujutsu (jj/咒術) 很顯然是在解我說的「git 很難用」的問題。 因為在 push 到 remote 之前，對我來說(或大部分不習慣多人協作的人)， patch 模型是殺雞用牛刀。 沒有 jj 之前，你需要 stash、rebase、cherry-pick 等高級操作。 而 jj 用的正好就是資料庫的那套模型—ACID、Operation Log(Undo)...。 ＝＝＝＝＝ 最後你說的語意，那是第三種—CRDT 或 CvRDT。 這你平常就有在用但可能無感，Google Docs 和改版後的Notion。 他背後是一個漂亮的抽象代數—格(lattice)，CRDT 是 join-semilattice (上半)， CvRDT 是 meet- (下半-)。 而格偏偏被用在詞彙、命題、概念甚至程式狀態， 利用格的偏序與上下確界結構，來對概念的包容、特異性與真值進行嚴格的數學建模。 你最熟的是指稱語意， 說的是在 Domain Theory 中，熟悉的程式計算(Lambda Calculus) 被轉換成完備格， 來證明遞迴、迴圈語義是有意義且可收斂的。 所以語意的概念有了，版本控制有了，那一個(抽象)語意的版本控制是什麼？ 這就是我在做的題目。 而我必須告訴你的是，他很可能必須是一種新的程式語言，因為現有語言很難做到。 一個貼近的語言叫 Unison，能做到基於語意的版控， 而他的實作叫做 Content-addressed AST(語法樹)。 你需要能從語法層級... 不對。 這其實很簡單： res = create( model="gpt-5.5", instructions="分析這兩個程式版本的差異?", input=[ {"content": [file1 file2] } ], ) print(res.text) --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.224.73.199 (臺灣) ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1785855433.A.252.html 回一下好了: Unison 的內容定址想解的問題不是語意版本控制，他的重心在建置與重構。 因為名稱改變雜湊不變，且依賴的是雜湊不是名稱。 兩個具有相同功能，僅變數命名不同的函式會被視為相同，這大大減少建置時間。 這被稱作「漸進式編譯與共用快取」。 起初看起來像是解效率問題，但這幾年看起來更重要，因為他能有效防止供應鍊攻擊。 但防不住命名/別名污染(像釣魚攻擊騙走你的簽章)，那是中心化套件發佈系統的原罪。 說到大部份的指令都是marco，補個可以做的練習。 git 主要物件只有內容(blob)、目錄樹(tree)和節點(commit)。 而多數時候你操作的都是指標: HEAD、branch、tag...， 和處理三個主要空間的同步: 工作區、暫存區(staged)、儲存庫(repo)。 先不管遠端操作，設計一個 git 精簡指令集會長怎樣? 1. add [file]: 檔案從工作區進入暫存區 2. snapshot: 檔案從暫存區進到儲存庫 (類似commit但不移動指標) 3. point <name> <commit-id>: 操作指標，這個最難懂 <name> 放 branch name 就是 git branch <name> 放 HEAD 就是 git checkout <name> 放 branch name 但 <commit-id> 放 HEAD~2 之類的指標，就是 git reset 4. extract <commit-id>: 從儲存庫或暫存區取東西出來 5. diff <commit-A> <commit-B>: 產生 patch -. apply: 把 patch 套用到工作區 (這不是git功能，所以不算) 說的練習就是自己組回原本的 git 指令: commit = snapshot -> point HEAD + point branch merge = apply (diff <parent> <current>) + (diff <parent> <target>) -> add -> commit rebase = (diff commit => patch) -> point <branch> <new-target> -> extract -> apply patch -> add -> commit stash = add -> snapshot (孤兒) 好像沒練習到，因為我寫出來了。 ※ 編輯: galic (125.224.100.176 臺灣), 08/07/2026 22:48:29