突然觉得值得回一篇，因为你在问的问题我最近才想过。 当然不是「有了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/cn.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