就此AI
课程页面：南京大学《生成式软件工程》第四讲
当一个 Agent 几十秒就能改完代码，多个 Agent 又能同时推进不同任务时，软件项目的变化速度便不再符合传统版本管理的节奏。版本控制仍要保存快照、支持回退、整合并行修改，但提交历史、冲突处理和团队协作所依赖的假设都值得重新检视。
开放式的“会成长的个人助手”作业把问题落到项目实践中：需求可以指向学习资料、个人信息、邮件或后台 Agent，技术选择也几乎没有限制。这样的自由度既给了探索空间，也让一次性生成完整系统更容易偏离真正要解决的问题。项目要保持可控，既需要为变化留下历史，也需要把每一步缩小到能够验证的范围。
一、版本控制记录的是协作方式
Git 的快照、分支、提交、合并与变基，不只是命令集合，也对应着一套适合人类协作的工作节奏。开发者先讨论任务、划分范围，再各自修改项目；一段时间后，变化通过提交和合并重新汇总。小步提交让项目保留可回退的状态，也把每项改动与当时的目标联系起来。
对人来说，提交说明、git blame 和历史记录可以帮助复原一个决定为何出现：当时要解决什么问题、改动如何演进、错误又是在哪一步引入的。历史因此既是备份，也是经验的载体。即使某条路线最后失败，保留快照仍能让项目退回到较早状态，再从不同方向继续尝试。
Git 的分支、合并和变基也不是需要机械记忆的仪式，而是把各自独立的修改重新接回同一条项目历史的办法。学生作业里很少需要处理复杂的多人 rebase，但开源项目的 CONTRIBUTING.md 往往会明确要求分支、提交和合并规范；理解这些规范，才能真正进入已有项目协作。使用 Agent 可以降低试验新工作流的门槛，前提是先明白这些规则解决的是什么问题。
Agent 改变了这一节奏。代码可以在秒级生成，任务也能同时交给许多执行单元。若这些 Agent 修改重叠的范围，合并与复查可能赶不上生成速度。与此同时，如果 Agent 可以重复执行、快速修复，记录“谁写错了”的价值可能下降；更重要的可能是保留哪些尝试有效、问题怎样被修正，以及项目下一步应往哪里走。速度提高并没有消除历史的作用，而是改变了历史需要回答的问题。
二、从 Git 到 Jujutsu：把变更本身看得更清楚
不同版本管理工具可以理解为对不同协作摩擦的回应。Git 用快照和提交组织历史；显式的暂存区让开发者先选择哪些差异进入一次提交，但也增加了工作区、暂存状态和提交之间的切换。
课程把这条演进线索从手工复制项目目录讲起：V1、V2 和最终版散落在不同压缩包里，很难可靠地比较、合并和追溯；SVN 一类工具开始集中管理版本变化，Git 则把完整项目状态作为快照来记录，让分支探索和本地提交更自然。每一代工具都改善了旧模型的摩擦，也留下了新的抽象边界。
Jujutsu（jj）提供了另一种思路：把当前工作状态直接作为一个变更来管理，并用独立的 change 概念追踪改动。这样，变基改写提交历史时，逻辑上的变更仍能保持辨识；冲突也可以被记录下来，稍后再集中处理。工作区不再要求开发者先把内容放入暂存区，才能形成一个可管理的状态。
这个差异来自底层抽象。Git 的提交 ID 标识一个快照及其父提交；变基把一项改动接到新的基础上时，通常会重写出新的提交。若把“提交”与“逻辑变更”分开表示，历史即使重排，原来的变更身份仍可跟踪，冲突也不必马上阻断其后的操作。jj 把这种工作方式做成工具能力，减少在暂存区和未提交工作之间来回切换的负担。
这不是要把一个工具说成适合所有项目。关键是看清楚工具里的抽象如何影响人的工作：Git 把文件树的快照作为中心，Jujutsu 进一步强调正在进行的 change。先理解这些设计针对什么问题，再比较它们在冲突、提交粒度和多人协作中的取舍，才能判断哪种模型更适合手头的任务。
三、Agent 并行需要明确边界
人类协作常采用乐观并发：各自先推进认为不会冲突的工作，等变化汇总时再处理少数冲突。这个做法成立，一部分原因是人会提前沟通、认领任务，而且提交速度有限。多个 Agent 却可能在很短时间内同时改动同一模块，尤其当任务描述宽泛、共享状态和接口没有定义清楚时，冲突和返工会更频繁。
当前可行的做法之一，是让不同 Agent 在隔离的工作树或容器中工作，再由负责整合的一方检查、测试和合并。隔离能减少工作区互相覆盖，却不会自动消除语义冲突；改动最终仍要回到同一项目中协调。
Git worktree 就是一个轻量的隔离办法：多个工作目录可以各自检出不同分支，同时共享同一个本地仓库。Agent 在自己的工作树里写文件，不必争用同一份工作区；完成后仍须确认各自的接口、测试和目标兼容，再把修改整合起来。若把 Agent 放进各自独立的容器或远程仓库，隔离会更强，交换提交和处理冲突的成本也随之增加。
另一种可能方向，是在开始执行前声明任务范围，对可能相互影响的文件、模块或资源设置锁定。重叠范围需要排队，不相交的工作仍可并行。这样可以降低冲突率，但锁得越粗，可并行的空间越小；锁的粒度越细，协调和维护锁本身又越复杂。因此，锁不是一句“多加并发”的解决方案，它要求项目先把任务边界表达清楚。这属于面向 Agent 工作流的设计设想，和现有工具提供的隔离工作区应当区分开来。
这与数据库里的乐观并发和操作系统里的锁有相似之处。乐观方法先让操作运行，提交时再检查是否冲突；锁则要求执行前声明将使用的资源。人类团队往往能通过会议预先切分任务，提交频率又较低，因此“先做，冲突时再解”通常有效。Agent 执行更快、任务拆分更密集时，提前协调资源可能更划算。锁仍会降低重叠工作的并行度，是否值得取决于冲突成本、锁的粒度和项目整体吞吐量。
四、项目的可追踪性不止代码
软件项目通常把需求、设计文档、测试和代码放在不同文件里。它们之间却存在很多隐含关系：一项需求对应哪些实现，哪条测试验证了哪条约束，某处设计变更又要求更新哪些文档。文件系统让这些内容容易保存，却不会自动维护它们之间的联系；如果代码已经改了，文档还保留旧假设，项目便积累了技术债。
例如，优化性能时把链表实现替换成树结构，代码可能已经改变，设计文档却仍写着“数据由链表维护”；相关测试也可能没覆盖新的约束。代码、文档和测试之间的关系没有消失，只是散落在仓库文件、提交记录和已经丢失的聊天历史里，后来的维护者与 Agent 都可能无法判断哪一处才是准绳。
面向未来的项目表示方式可以更明确地记录这些关系，把需求、实现、测试和说明视作相互关联的对象。一次改动只需要查看其中相关的部分时，Agent 可以根据任务生成一个更小的工作视图：列出受影响的设计、代码和测试，完成变化后再检查它们是否仍然一致。这类似数据库视图按问题组织同一批数据，也可以呈现成只含当前改动相关信息的看板，减少每次修改都必须重新理解整个仓库的负担。
这样的结构化仓库仍是探索方向，不是所有项目现在都需要迁移到数据库。它强调的是一个长期问题：项目越复杂，越需要知道不同产物之间的对应关系；Agent 能帮助维护这些关系，但前提是任务和验收标准足够清晰。
五、先说清楚个人助手要解决什么
“会成长的个人助手”可以延伸出很多功能：整理课程资料、检索研究文献、填写表格、处理邮件、从外部网站收集信息，或在后台持续运行。每个方向都能讲出合理理由，却不代表它们都应该进入第一个版本。
把一段宽泛描述直接交给 Agent，它可能迅速补齐数据库、接口层、对象存储、任务队列和复杂业务流程。这样的方案符合常见信息系统的形状，解释起来也头头是道；但如果核心需求是让学生更高效地学习，真正有用的第一步也许是浏览器里的研究助理：能收集外部资料、结合个人进度整理知识，再提供合适的复习入口。把每个可选例子都当成硬性规格，会让 Agent 忙着搭建基础设施，却没有验证这项核心能力。
问题不在于描述越详细越好或越短越好，而在于规格是否表达了优先级。宽泛的意图需要进一步澄清，过多而没有层次的要求也会把模型注意力分散到次要实现细节上。可以先标出必须解决的问题、验收结果与暂缓范围，再让 Agent 讨论可能方案；当方案偏离了目标时，回到意图和成功条件，而不是继续追加更多实现指令。
要缩小意图与实现之间的距离，第一步是判断真正要解决的痛点，再把成功条件写成可以检验的结果。个人助手首先要在哪件具体任务上帮到用户？怎样的输出足以证明它有用？哪些能力可以留待验证之后再加入？明确这些问题，往往比继续堆叠功能描述更能约束实现方向。
六、用最小版本验证价值，再为变化留路
最小可行产品（MVP）的作用，是尽早验证“是否有人需要这个结果”，而不是把系统缩小成一个仍然无法使用的半成品。课程里的教育产品例子展示了这个差别：一个围绕汉诺塔练习的产品，可以先让学生写代码、运行程序、观察可视化结果；确认这条学习路径成立后，再加入按需调用的 AI 助教和更完整的服务。
汉诺塔的变体要求盘子只能沿一个方向移动，学生需要理解递归、观察运行结果并找出程序中的错误。最先值得验证的产品能力，是代码能不能运行、错误能不能被看见、可视化是否帮助理解。AI 助教可以作为用户主动请求的下一层服务，根据这次尝试给出有针对性的提示；如果学生还没验证基础练习是否有用，就先搭建完整付费系统，风险只是被更华丽的界面掩盖了。
如果产品的核心价值在于保存学生每次尝试、回看代码变化，并让 AI 对某个状态给出反馈，那么早期设计就应该围绕这些需求展开。学生每次运行或阶段性修改，都可以形成可回溯的 Git 记录；助教的反馈可以关联到当时的提交，必要时作为分支或评注保留。这样，学生能比较不同尝试，产品也能解释一条建议针对的是哪一个版本。
相比一开始就引入完整数据库、对象存储和异步任务系统，先用熟悉的文件与版本历史组织数据，可能更便于快速调整目录和记录格式。文件夹和文件是多数人已经熟悉的模型；数据库 schema、迁移和任务状态则要求更多前置设计。早期数据结构经常变化时，后者可能让每次试验都背上迁移负担。
这并不是说文件系统永远胜过数据库。数据量、查询需求、并发规模或持久化要求发生变化后，迁移到数据库可能变得值得；可以先用代码库里的真实访问模式确认哪些查询和一致性要求已经出现，再为它们选择存储结构。重点在于不要预先为尚未验证的规模支付架构成本。项目初期可以从最容易理解和调整的表示方式开始，等数据关系与使用模式稳定，再选择更合适的存储和服务结构。
七、项目进度来自任务设计与持续整合
版本控制提供快照、隔离和合并机制，真正困难的仍然是决定下一步做什么、由谁完成、怎样证明完成，以及哪些变化可以安全整合。多加 Agent 并不会自动生成一支高效团队；如果架构、共享接口和任务范围都没有理清，执行单元越多，冲突和返工也可能越快累积。
更稳妥的顺序，是先由人和能力较强的 Agent 共同澄清目标、讨论架构和验收条件，再把边界明确的工作交给多个执行单元。负责人需要确定哪些接口是共享的、哪些文件由不同任务负责、完成条件如何检查，以及什么时候汇总变更。比如一个 Agent 改数据格式，另一个 Agent 同时按旧格式写页面，如果没有约定接口和整合点，两个任务单独看都可能正确，合在一起却无法运行。
每一项变化都应当足够小，可以单独检查、测试和回退；整合时确认它与其他工作兼容。版本历史仍然重要，但团队是否能向前走，更取决于任务拆分和反馈周期。人类沟通的成本会随参与者增加而上升，Agent 虽然可以更快执行，也仍需要明确的边界、共同接口和集成策略。这样，Agent 的速度才会变成项目的进度，而不是更快地产生一批彼此难以解释的改动。
版本控制是工具，不是工程判断的替代品。Agent 越能并行执行，人越需要决定哪些事情应该并行、哪些状态必须共享，以及当前阶段最值得验证的产品价值。可靠的软件不是一次生成后自然成形的，而是在清楚的意图、可追溯的变化和持续验证中逐步长出来的。