AI 时代比以往更需要软件工程
前段时间，我在同时处理一个项目里的几条工作线。
旧版 UI 还有 Bug 要修，新版 UI 正在迁移，新的 Feature 也已经排进来了。除此之外，后台还有一些异步任务在跑。
单独看，每一件事都不算特别复杂。现在有了 AI，写一个页面、改一个接口、补一组测试，速度都比以前快了很多。
我并没有因此更轻松，AI 越快，我反而越忙。
我每天打开项目以后，有大量的任务需要我重新搞清楚：这几条工作线下面，它们分别到了哪一步。
-
新版 UI 重构究竟拆出了哪些任务？
-
哪些页面已经迁移，哪些还在开发？
-
哪些结果等待 Review，哪些已经完成测试？
-
Agent 刚刚交回来的结果，对应的到底是哪一张任务？
Worktree 解决并发，但不管理项目进度
我之前做过一期视频，也整理了一篇文章，讲我怎么用 Worktree 同时推进两到三个 Agent 任务。
谈谈我对 Worktree 的使用感受：如何在 AI 时代并发多个任务
与其等待一个 Agent 完成，不如用 Git Worktree 隔离两到三个任务，把等待时间变成可控的并发时间。
Worktree 很适合让多个 Agent 同时工作。
但最近我发现，Worktree 只解决了问题的一半：它让任务并发执行，却不会替我掌控整个项目的进度。
由人或者工具提前创建几个独立的 Worktree，然后在每个目录里启动一个新的 Agent 会话。每个 Agent 都有自己的目录和分支，不需要在同一个工作区里互相干扰。
这个思路没有问题。
Worktree 解决的是执行环境的隔离。Git 会记录每个分支修改了什么，也会在合并时处理代码之间的冲突。
真正没有被解决的，是整个项目接下来应该怎么推进。
比如说，“迁移新版 UI”听起来像一件事，真正开始做以后，却会继续拆成商品列表、商品详情、规格选择、数据适配和回归测试。每一张任务都可能在不同的 Worktree 里由不同的 Agent 执行。
当 Agent 陆续交回结果，我需要知道的不是谁先修改了代码，而是：
-
现在究竟有多少张任务；
-
每张任务属于哪一条工作线；
-
哪些还在开发，哪些等待 Review；
-
Agent 实际交付了什么；
-
哪些只是说“Done”，哪些已经真正验收。
这些信息不会自动出现在 Git 历史里，也不会因为创建了几个 Worktree 就形成一套能够推动项目向前的流程。
如果只靠聊天记录、随手写的文档和自己的记忆，任务少的时候还能应付；当一条工作线拆成十几张 Ticket，几条线又同时推进时，我很快就会分不清哪个任务是哪个任务。
所以 Worktree 和项目管理工具解决的不是同一件事。
Git 记录代码发生了什么，Worktree 解决 Agent 在哪里执行；项目管理工具控制任务怎么向前推进，测试和验收决定它什么时候才算真正完成。
一个人有了一支队伍的执行力
以前做一个完整的项目，工作通常分散在不同角色之间。
产品经理梳理需求，设计师负责界面和交互，前端写页面，后端写接口，测试负责验证，项目经理统筹进度和协调各方。
每个人只负责其中一部分。谁负责什么、做到哪一步，通常都有比较明确的分工和交接。
现在有了 AI，一个人可以同时承担很多角色。
我可以让一个 Agent 修改前端，让另一个 Agent 补接口，再让第三个 Agent 写测试。以前需要几个人分工完成的事情，现在一个人确实可以同时推进。
表面上看，这是一种非常大的效率提升。
但与此同时，原本分散在团队里的判断、协调和验收，也全部集中到了一个人身上。
AI 扩大了我的手脚，却没有扩大我的工作记忆。我可以同时启动更多任务，但没有办法仅靠大脑，长期记住一张不断变化的任务清单。
一个 UI 重构拆出了哪些任务，每张任务属于哪条工作线，现在处于什么状态，Agent 交付过什么，什么只是回复了一句“Done”，这些信息很快就会混在一起。
这也是为什么我现在越来越认同一个观点：写代码从来不是软件开发里唯一的瓶颈。
写出代码只是第一步。理解已有系统、审查修改、测试、调试，持续掌握项目状态，以及确认结果能不能安全进入生产环境，往往才是更耗时间的部分。
AI 把第一步加速以后，后面的这些工作反而变得更加明显。
传统软件工程的回归
我的解决办法不是少开几个 Agent，也不是回到所有事情都由自己慢慢做。
我重新把传统软件工程的工作节奏拿了回来。
以前一个需求会经过产品、设计、开发、测试、验收和上线。现在这些角色可以合并到一个人和一群 Agent 身上，但这些阶段不能跟着角色一起消失。
这些阶段串起来，构成的就是软件工程最重要的能力：不是偶尔完成一次修改，而是持续把需求变成可以验证、可以上线、可以继续迭代的软件。
我开始重新使用项目管理工具。
我现在用的是一个本地部署的工具，功能上和 Linear、Jira 差不多。具体使用哪一个其实无所谓，重要的是项目需要一个能够掌控进度的控制台。
简单写一份文档不够。文档可以说明“我们正在重构 UI”，却不会形成任务队列，也不能通过状态流推动开发、Review、测试和返工。项目必须进入一个能够持续判断下一步、调度 Agent 并完成验收的推进系统。
每一次修改都会变成一张 Ticket。里面需要写清楚：
-
这个任务为什么要做；
-
它属于哪一条工作线；
-
当前处于什么状态；
-
它依赖哪些任务；
-
这次允许修改什么，不应该修改什么；
-
需要运行哪些测试；
-
最后用什么证据证明完成。
这样做并不是为了把简单的事情变复杂。把项目状态从脑子里移出来只是第一步，更重要的是让每张任务都有明确的下一步。
聊天会结束，Agent 的上下文会丢失，Worktree 完成以后也会被删除。但 Ticket 会继续保留任务为什么开始、Agent 交付了什么，以及我根据什么通过验收；状态流则负责把它继续推向 Review、Test、返工或者 Done。
它不是另一份待办清单，也不只是一份外部记忆。对一个人和多个 Agent 来说，它是掌控整个项目进度的控制台。
状态不是装饰
很多项目管理工具都有类似的状态：Backlog、Todo、In Progress、Review、Test 和 Done。
如果只是为了拖动卡片或者保存记录，这些状态确实没有什么意义。
我现在更关心的是，每一次状态变化背后有没有新的事实和证据，以及它是否真的允许任务进入下一步。
Todo 到 In Progress
代表任务已经定义清楚，依赖条件满足，可以正式开工。
Agent 开工以前，要先说明这次准备修改什么、不修改什么，以及完成前需要运行哪些测试。这样即使我切到另一条工作线，回来以后也不用重新猜它正在做什么。
In Progress 到 Review
代表 Agent 已经交付，但还没有得到人工确认。
它不能只回复一句“已经完成”，而是需要把自验收证据写进评论：修改范围、测试结果、预期结果和实际结果分别是什么。
如果是一个能够直接看到的页面，还要提供截图和可以打开的验证链接。
Review 到 Test
代表人工复核已经通过。
我会打开 Agent 提供的链接，按照评论里的步骤重新操作，再对照截图检查页面状态。必要的时候还要继续检查 Diff，确认它没有顺手修改其他范围。
如果发现问题，我会继续在同一张 Ticket 下面留下评论，然后先去检查这一轮其他等待 Review 的任务。等这一轮全部看完，再统一让各个 Agent 根据评论继续修改。
Test 到 Done
才代表最终回归和验收完成。
它不只需要证明当前 Bug 修好了，还要证明旧功能没有被破坏，而且最终结果符合一开始定义的需求。
所以这里真正重要的不是看板有多少列，而是每一次状态变化都对应新的项目事实，并且决定这张任务下一步可以去哪里。
为什么 AI 越强，越需要软件工程
一次性的 Demo，或者一个很小的个人项目，当然没有必要建立这么完整的流程。
但当一个项目开始出现旧系统和新系统并行、Bug 和新功能同时推进、一条 UI 重构继续拆出十几张 Ticket 的情况，这个转折点会来得非常快。
以前流程帮助一个团队完成分工和交接。现在团队可能变小了，甚至很多事情只由一个人完成，但原本由不同角色承担的工程职能并没有消失。
需求仍然需要被定义，设计仍然需要确定边界，开发仍然需要明确范围，测试仍然需要验证行为，项目进度仍然需要被控制，最终结果仍然需要有人验收。
一个人可以同时扮演产品经理、设计师、开发、测试和项目经理，但不能假装这些工作已经不存在了。
从这个角度看，AI 时代不是不再需要软件工程，而是比以前更需要软件工程。
因为 AI 让变化产生得更快了。
Worktree 是执行层，让多个 Agent 可以同时工作；项目管理工具是控制层，让任务按照状态和证据持续向前推进；架构、测试和验收则保证推进的结果仍然可靠。
过去，是产品经理、设计师、开发、测试和项目经理，围绕同一套工程系统持续交付。现在，这些工作可能集中到一个人身上，由多个 Agent 分别执行。
人数变少了，执行主体变了，但把需求变成可验证、可上线、可继续迭代的软件工程系统没有消失。
AI 改变了软件由谁来做，但软件工程决定了这些变化能不能被持续交付。
AI 时代比以往更需要软件工程，因为我们正在把原本属于一支团队的持续交付，压缩到一个人和多个 Agent 身上。