AI 时代比以往更需要软件工程
添加新的 Feature、修 Bug、重构新的网站 UI，再检查一下后台正在跑的异步任务。
四条任务线同时需要我去推进，而且在推进的过程中，还会不断产生新的问题。
这是我最近在公司遇到的难题。我正在给公司的网站重构新的 UI，但重构的过程中，我又需要去改旧版 UI 的 Bug，以及添加新的 Feature；这两块做完之后，我还需要把它同步到新的重构后的 UI 上面。
听起来是不是很乱？
这就是我们用 AI Agent 并发大量任务时会遇到的难题。
Worktree 解决并发，但不管理项目进度
我在上一期视频里讲过，可以用 Git Worktree 来并发任务。
谈谈我对 Worktree 的使用感受：如何在 AI 时代并发多个任务
与其等待一个 Agent 完成，不如用 Git Worktree 隔离两到三个任务，把等待时间变成可控的并发时间。
当时我提到了一个数字上限：3 个任务。这刚好是人脑可以理解、可以管理、可以清晰认知到任务全流程的一个上限。
Worktree 这种形式确实解决了并发问题。每个 Agent 在自己的目录和分支里工作，代码不会挤在一起，谁先修改、最后怎么合并，也有 Git 帮我记录。
但它没有解决另一个问题：这个项目走到哪了，改了多少东西，还剩多少任务没做。
当不同 Worktree 里的 Agent 把任务结果陆续交回来的时候，我还需要停下来想一想，到底发生了什么。
一个人扛下了一支队伍的活
在 AI 之前，大量的工作被分给不同的人，落在不同的职位上。
产品经理写需求，设计师画画面，前端写页面，后端写接口，测试做验证，项目经理管进度。
但在 AI 时代，这些工作大部分都集中到了一个人身上。
当然，随着 AI 的发展，AI 的能力一定会越来越强，一个人能做的事情也会越来越多，这是不可逆的趋势。
真正的问题是：当原本属于一个团队的大量任务，落到了一个人和多个 Agent 身上，我们应该怎么有序地推进，并且形成持续交付？
把传统软件工程重新带回来
我的解决方式，不是减少几个 Worktree 并发任务，也不是回到慢慢做的节奏，而是把传统软件工程这一套方法论重新带回来。
原本一个需求需要写需求、设计、开发、验收，最后再上线。现在这些全部落在一个人和多个 Agent 身上，并不意味着这个流程需要消失。
把这些流程串起来，正是传统软件工程方法论的作用。
所以我们需要引入一个新的帮手，也是以前大家在公司里非常熟悉的东西：项目管理工具。
它可以是 JIRA，也可以是 Linear，甚至可以是 GitHub Issue。
为什么我用 Plane
这里我用的是一个自己部署的工具，叫做 Plane。
为什么选 Plane 而不用 JIRA 或者 Linear？因为 Plane 本身免费，而且开源，你可以自己部署，Linear 则需要付费。如果你有特殊需求，需要在上面做定制，用 Plane 也比较方便。
并且在可以自定义的前提下，你去用接口操控你的任务、操控这个平台，让你的 AI Agent 和它沟通，是比较方便的。
我在自己的 Plane 里定义了多个状态，从 Todo 到 In Progress，再到 Review、Test、Done。它完整地匹配了前面说的软件工程生命周期。
Plane 不仅提供了分类的 List 视图，还提供了看板视图、Calendar 和 Timeline 等视图。你还可以按任务属于哪个 Module 来查看，甚至可以根据不同的 Label 筛选出来，形成一个新的 View。
Plane 大概就讲这么多。它其实就是一个普通的项目管理工具，只不过把通常所有项目管理工具需要的功能都提供了。
外科医生、漫画家，和被释放的认知带宽
在录这条视频之前，我看到了一条比较有趣的帖子。
宝玉发了一条帖子，说了《人月神话》里的一个例子。作者 Brooks 试图给出解决方案，他从外科手术里得到了灵感：把整个系统的决策集中在一个人，也就是外科医生的大脑中。
看到这里，其实和我举的例子差不多：一个人做决策，其他人做支持，也就是去执行。沟通路径从网状变成了星状，层级减少，平方值也大幅降低。
这个例子我以前在自己写的文章里也举过另外一个版本：漫画家。
大家都知道，漫画家画出来的漫画其实不是他一个人完成的。他只负责定下画风、设计剧情，以及画原画。最后真正出品的作品，其实是有助手帮他做了很多额外的操作，比如填网格纸、比如填色、比如画一些非常耗体力的场景。
这和《人月神话》里举的例子是非常像的。
一个 10 个人的小团队，真正做决策的只有一个人，但整个团队的产出却远超一个人所能达到的上限。因为外科医生的认知带宽被释放出来，专注于最核心的事情：思考与决策。
这也就是我们在和 AI Agent 对话时发生的一模一样的事情。执行交给 AI Agent，我们来做思考、来做决策。而项目管理工具负责管住任务，最后的思考和决策交给我们来做。
当年为什么没流行，现在为什么反过来了
宝玉后面又说到，当年为什么这个模式没有流行，很多人甚至没有听说过。
第一，外科医生级别的人才极其稀缺，而且这种模式高度依赖个人，如果这个人离开或者判断失误，整个团队就会瘫痪。
其实现在已经有这样的情况了，不过是反过来了：外科医生级别的人才在程序员里其实并不稀缺，稀缺的是算力。
第二，随着软件规模和领域复杂程度的爆炸，要求一个人掌握整个系统的所有设计细节，变得越来越不现实。
这一点我们可以回顾一下。最开始我们是不分前端后端的，大家就一把梭，什么 jQuery、JSP 就直接写。再到后来需求爆炸了，前端需要更精细的页面，有视频、有音频、有 3D、有各种乱七八糟的交互，所以专门分出来前端这个单独的职位。后端里面又要去运维、又要处理并发、又要处理各种各样的安全问题，所以又单独分出来一个后端的岗位。
第三，工具的进步。 要掌控的工具又多了：需要掌控 Git，需要使用某个 IDE，需要使用某个平台的持续部署能力，比如 K8s 这种就要人专门做运维，所以又专门单独分出来一个运维的角色。团队结构也随之进化成了我们今天更熟悉的敏捷模式。
但 AI 时代来了，Coding Agent 的能力越来越强，这个模式倒是可以拿出来讨论，也许变得可行。
一个人加 AI，正在逼近 Brooks 想象中的外科手术团队的产出。
写代码从来不是瓶颈
除了宝玉那篇帖子以外，我又想起我在去年看过的另一篇文章。
早在 2025 年 6 月 30 号，有人写了一篇文章叫《Writing Code Was Never The Bottleneck》。
在做项目的时候，写代码并不是最累的一件事情，也不是主要的瓶颈，真正的瓶颈是整个流程：
首先产品经理提出需求，然后和开发进行评审，评审完之后又要做原型，做完原型之后交给设计，设计之后又交给开发，开发做完，前端去写页面、后端去写接口，他们两个同时进行；写完之后他们又要对接口，对接口又要花大量的调试时间；调试完之后部署到测试环境，交给测试；测完之后你拿到问题，又开始 debug。
中间其实有大量的思考、沟通、交流、开会的过程。所以整个流程特别长，做一个需求需要特别慢。
那现在好了，大部分的任务都交到一个人身上，就没有这些沟通成本了。什么对接口、提需求、画原型，这些全部没有了，直接 Coding Agent 一把梭。
所以他在后面又写了一句：
The biggest cost of code is understanding it — not writing it.
代码最大的成本是理解它，而不是写出它。
大多数时间其实我们都在理解需求，而不是在写代码。我们并不像电影里面一样，代码打得特别快；我们其实就是一指禅在慢慢地打、慢慢地 debug、慢慢地看这个代码。
这句话又回到了上个视频我提到的那点：我们不能并发太多任务。
一旦并发太多任务，我们就会忘记任务的具体细节——
-
我提出了什么问题；
-
我是去修 Bug，还是添加新的功能；
-
AI Agent 是怎么提供解决方案的；
-
它的解决方案是否是对的；
-
它执行的流程有没有执行歪；
-
我该怎么测试，测试要考虑到什么；
-
它有没有影响到其他的模块。
所以写代码的瓶颈不在写代码，而在理解怎么写这个代码、怎么用这个代码。
怎么让 AI Agent 和项目管理工具打通
下面我演示一下我怎么用 Plane 这类项目管理工具和我的 AI Agent 做交互。不管你用的是 JIRA 还是 Linear，都可以用同样的思路。
首先，如果你使用这类工具，去找到官方的 MCP，或者他们提供的接口，然后拿到授权的 Token、授权这个接口，再把这一系列东西交给你的 AI，让它去帮你安装 MCP，或者安装这个 Skill。
由于我用的是 Plane，它没有提供官方的 Skill 或者 MCP，所以我自己根据它的接口，让 AI 去生成了一个，非常简单。
所有类似的软件和你的 AI 交互，都是这个逻辑。
实际跑一个任务
我创建了一个 Demo 项目和一个 Demo 任务来演示：在商店的验证页增加当前的选择摘要，也就是在这个页面上加点东西。
我看到它的任务编号是 AI Demo 7，把它复制下来，打开我的 Codex 发送给它，说「请你执行一下这个任务」。
发过去之后，它就会读取我前面生成的 Plane 技能，按照里面定义的工作流程去处理。
在它处理的时候，我稍微解释一下怎么让它更高效。
Todo：任务要写清楚
如果是 Todo，一定要让它在创建任务的时候写清楚要做什么任务，或者附上图片之类的。
Comment：过程和证据都留在这里
每个任务其实有很多 Thread Comment。你在做这个任务的过程中需要提供的一些证据，就让它提供在 Comment 里面。
以一个做完的任务来举例子：做完之后，它会说这个开发是怎么做的、它是怎么去修的，就 Comment 在这里；开发完成需要确认的东西，也写到这里。
最重要的是，如果你开发的是网页，它会给你提供链接和图片。
图片就是一个很好的、给你快速验证的机制；当图片不是很明确、你需要交互的时候，你就点到这个链接里面去看。看了之后，你就会看到它改的内容是什么。
Review 和 Test 分别在管什么
我再解释一遍这几个状态是什么。
Todo 就是要做的任务，In Progress 是正在做的任务。那为什么还要有 Review 和 Test 呢？
Review 就是等待我去 Review。我看一下这个任务到底有没有完成、有没有问题、是不是需要重新去做。
这里就要提到前面那个 Comment 了：如果你有大量待 Review 的任务，有些需要返工怎么办？那我们就先在 Comment 这里留下问题。最后等 Review 全部完成之后，我们再统一交给 AI，让它去找这种有新 Comment 的任务重新返工。
做完 Review 之后，我们一般会把状态改成 Test，也就是进入到正式测试环境。当我们在 Test 环境里验证完成之后，再移到 Done，就表明这个任务正式完成了。
所以这里真正重要的不是看板有多少列，而是每一次状态变化都对应新的项目事实，并且决定这张任务下一步可以去哪里。
回来看结果
好了，现在这个任务完成了。
我们回到这个地方刷新一下，点开刚刚的 7 号任务，它已经进入到 Review 状态。往下看，它已经做好了，留下了 Comment，说明了加了什么、做了什么，然后还有验证地址。
我点开一下，就到了这个验证页，然后就可以看见它在下面加了这个摘要。
为什么 AI 越强，越需要软件工程
一次性的 Demo，或者一个很小的个人项目，当然没有必要建立这么完整的流程。
但当一个项目开始出现旧系统和新系统并行、Bug 和新功能同时推进、一条 UI 重构继续拆出十几张 Ticket 的情况，这个转折点会来得非常快。
以前流程帮助一个团队完成分工和交接。现在团队可能变小了，甚至很多事情只由一个人完成，但原本由不同角色承担的工程职能并没有消失。
需求仍然需要被定义，设计仍然需要确定边界，开发仍然需要明确范围，测试仍然需要验证行为，项目进度仍然需要被控制，最终结果仍然需要有人验收。
一个人可以同时扮演产品经理、设计师、开发、测试和项目经理，但不能假装这些工作已经不存在了。
从这个角度看，AI 时代不是不再需要软件工程，而是比以前更需要软件工程。
因为 AI 让变化产生得更快了。
Worktree 是执行层，让多个 Agent 可以同时工作；项目管理工具是控制层，让任务按照状态和证据持续向前推进；架构、测试和验收则保证推进的结果仍然可靠。
过去，是产品经理、设计师、开发、测试和项目经理，围绕同一套工程系统持续交付。现在，这些工作可能集中到一个人身上，由多个 Agent 分别执行。
人数变少了，执行主体变了，但把需求变成可验证、可上线、可继续迭代的软件工程系统没有消失。
AI 改变了软件由谁来做，但软件工程决定了这些变化能不能被持续交付。
AI 时代比以往更需要软件工程，因为我们正在把原本属于一支团队的持续交付，压缩到一个人和多个 Agent 身上。