在与 Zed 的三位联合创始人 Nathan、Max 和 Antonio 进行的第三次对话中（点击此处阅读前一次对话），我想向他们询问他们对协作的看法。一般而言，在软件团队中的协作，特别是 Zed 现在和未来所提供的协作模式。理想的协作模式是什么？您对异步与同步工作有何看法？如果我们将 Zed 的协作愿景贯彻到底，我们是否还会保留 Git、提交和拉取请求？
这次对话比前两次要平静得多。这不仅是因为我和 Antonio 在欧洲时已是深夜，而且我认为，我们所谈论的——人们如何一起工作以及我们希望如何一起工作——是抽象的、个人的，甚至比我们之前的技术性对话更加细致入微。但尽管可能更内敛，这仍然是一次非常有趣的对话，自上周录制以来，我每天都在回想。
以下是一小时对话的编辑稿。我尽量保留意图和含义，同时删除了深入对话中常见的“嗯”、“比如”、“你知道”以及停顿和修正。
（您可以在我们的 YouTube 频道上观看完整对话。）
Thorsten：协作是 Zed 愿景的重要组成部分。你们从零开始构建它，就是为了在 Zed 中实现 CRDTs 和协作式文本编辑。所以我的问题是：我们今天的工具缺少什么，让你们想要去改进协作？
Max：想到这个问题，我脑海中浮现的是一个我一直设想的工作流程，它比我们现在拥有的更流畅：拉取请求、Slack 和屏幕共享——当今协作工具的“三驾马车”。
举个例子：我喜欢在咖啡馆里独自编码，专注于某事，然后突然意识到我需要你的帮助。我不确定你现在是否在，我不想离开编辑器，我想留下一条评论，大致解释我有什么问题要问你，Thorsten。“你能解释一下这段代码吗？”我不需要去 GitHub 上找到与该代码对应的 Git Blob。没有那种跳转。然后我可以继续我正在做的事情。如果你在线，比如你也在咖啡馆，你想用文字回复，你就可以直接进来，说：“哦，我们修改了这个 API。现在你需要这样做。”你和我一起编码了一会儿，你把这些输入到聊天中。这是一种轻量级的方式。
然后我意识到，“等等，我对此有一个更深层次的问题。我需要和你谈谈。”我说，“嘿，你能聊聊吗？”然后，哔哔，你就在我的编辑器里了，我们正在交谈，我们正在结对编程。你会说“好的，我们在这里做了修改，这里是这样，这就是为什么这里是这样。”我带你浏览一遍，我们进行一些深入的协作，然后我们分道扬镳。
你显然没有看我的屏幕。这对你我来说都是流畅的体验。然后将来，有人看到这个变化，会说，“嗯，这段代码怎么回事？”他们会看到 Max 和 Thorsten 在这里有过一次对话。他们可以看到文本交互，追溯到他们进行对话时代码的样子。
这就是我想要的。我觉得我们现在已经构建了其中非常重要的一部分，但还缺少异步的部分。
Thorsten：我可以说，你提到的所有这些，Slack、Zoom、GitHub 等等，现在都已经可能实现。但你提到的流畅性似乎是重要的一部分，你不需要去 GitHub 留下评论，然后检查邮件回复。相反，你仍然在你的代码中。所有这些都在一个地方。
Max：是的，让我们回顾一下那个故事，谈谈今天可能但很痛苦的事情。今天，在我最初意识到我有一个问题要问你的那一刻，我当时想，好吧，我该如何链接到这段代码，以便能够引用它并与 Thorsten 讨论它？我现在正在代码中。我的分支已经更改。我有一些未推送的内容。我必须做出决定。要么我推送一个进行中的提交，以便 GitHub 上有一些东西可以链接给你，要么我回溯并找到这段代码在另一个分支上的位置，然后使用 GitHub 的代码浏览界面来查找这段代码并链接到它。然后我切换到 Slack 说，这是链接。
所以也许到那时我可能已经决定：嗯，算了，我不会那么做了。我会再忍受一会儿这种痛苦，然后才决定这是否值得做。
所以那是第一个时刻，非常非常开始的时刻。然后，假设你刚刚收到我的消息说我需要帮助。今天，你会得到一个指向 GitHub 的链接。再说一次，它可能是一个指向不完全是我正在处理的代码的链接，只是因为我没有办法告诉你我正在处理的精确代码。所以你会有这样的摩擦，“好吧，我在我的代码编辑器里。我很有可能正在同一个项目上工作。但是我要跳转到 GitHub 去查看这段代码，因为那是你发给我的链接。我必须使用 GitHub 的代码导航或 Sourcegraph 的代码导航或除了我的编辑器之外的其他工具来查看这段代码。所以也许在那个时候，你会想：“我不会深入研究我给出的答案，因为那样做太痛苦了。”这是第二个时刻。
而最重要的是，如果我决定，“好吧，这样一来一回的文字交流有点低效，我想现在就和你谈谈。”今天，使用 Zed 之前的工具，你通常会选择像 Slack huddle 这样的东西。Slack huddle 很好，但它的代码部分，屏幕共享，这才是最大的问题。你现在正在看我的屏幕，你感觉，“哦，我怎么才能摆脱这个屏幕共享？我不得不看这个像素化的屏幕，它不是我的主题。我什么都做不了。快点结束吧。”所以也许在那个时候，你就会放弃。不值得这么做。
最后，那些想在以后了解这次对话的人，因为他们碰巧遇到了同一段代码。我想说，这可能是最糟糕的部分。假设 Antonio 后来查看这段代码，遇到了我发现的一些类似问题。我的意思是，如果是我今天，我会做的是，对文件进行 git blame，但对话不在 git 中，它在 GitHub 上。从 git blame 中获取 SHA，将其粘贴到网络浏览器中，看看这是否是拉取请求的一部分？对话在哪里？也许我能找到，转到拉取请求，但没有对话。哦，有一个对另一个问题的引用。
现实是，我可能已经放弃了，决定自己想清楚，因为不值得去寻找。或者我在 Slack 中搜索关键词。但两者都很痛苦。所以对我来说，所有那些时刻，你可以用今天的工具交换信息，但有很多地方今天不值得这样做。一个问题需要有多难才值得这样做，这个门槛太高了。
我想我们想要做的是，通过提供不阻碍你的工具，让它始终值得去做。
Thorsten：谁想补充一些？因为我有很多后续问题，但我也想听听其他人的意见。
Nathan：对我来说，我想要一个共享的环境。一个涵盖代码开发过程完整生命周期的共享环境。所以有了 Git，你就有了某种共享环境。这个环境就是仓库环境。但我认为，提交的粒度确实扭曲了我们围绕代码进行沟通的行为。
什么是提交？提交是某个时间点的静态快照。而现在，你真正能讨论的只有提交。但是如果你只能讨论某个时间点的快照，那么随着时间的推移，那次对话的相关性就会逐渐消失，对吗？因为你正在讨论一段过时的代码。
这意味着我们倾向于只讨论新代码，但有很多代码可能值得讨论。只是链接到它们实在太麻烦了。我可以提交一个“WIP”提交，然后链接到那个快照并进行对话。但是，同样，随着时间的推移，那次对话的相关性就会逐渐消失，因为它锚定在旧代码上。
因此，能够将对话随着时间的推移向前推进，将对话真正链接到一段代码，而不是一段代码的快照，真正将锚点投放到一个字符上，只要那个字符存在，就能够携带它并看到有一个对话与之相关联——这对我来说是一个很大的缺失。
Antonio：除此之外，我觉得每个人都曾有过这样的经历，我不知道……对我来说，很多次我都会做一些事情，创建一个分支，推送一个 PR，典型的工作流程是你会请求审查，通常，PR 越长，审查就越糟糕。PR 越长，你得到“看起来不错，发货”的机会就越大，而 PR 越短，人们就越有可能挑剔。
而如今 PR 的问题，我真正不喜欢它们的是，如果你很擅长，你就会非常擅长你的提交信息，对吧？你会把它们描述得非常完美，最后，你会在 PR 描述中写一个总结，对吧？但那个总结只是你对事情进展的回忆。但从你写第一个提交到你输入那个总结之间，可能已经过了一周。所以这是一个问题。
另一个问题是你在看一个差异，但是当你阅读那个差异时，它是按字母顺序排列的。这不是我向另一个人展示我的差异的方式。我会告诉他们，嘿，你知道，这些是主要部分，然后……
Nathan：向他们呈现一个叙述，而不仅仅是一个差异。
Antonio：你知道，Max 描述的那些互动，在您编写代码时确实发生了，因为也许您确实有过屏幕共享会话，或者您与同事交谈过，对吗？而能够捕获这些对话并让它们与代码共存——这些对话与代码本身一样重要。
从某种意义上说，代码几乎是这些对话的产物。它是这些知识的产物。而现在，这两者是分离的，它们分散在多个数据库中——GitHub、Slack、人们的头脑里。
能够将它们统一起来并捕获所有这些知识，这让我非常兴奋，当我们谈论协作以及 Zed 能做什么时。
Nathan：关于代码的对话太多了，但它们并没有发生，我认为如果我们有更好的工具支持，它们就会发生。总的来说，我发现拉取请求的氛围有点像一场对抗性对话。就像你试图让它通过审查，而人们却设置了这些障碍让你去清除和解决。当然，有些情况下这很适用，尤其是当你们都已达成共识，而这主要是一些调整或其他小改动时。
但如果更深入，我更喜欢一种更具协作性的动态，我们只是共同完成事情。我的意思是，这正是 Zed 目前做得很好的地方。仍然有改进的空间，但它正在从那种对抗性动态转向协作性动态，真正的协作。
Thorsten：听起来你们在协作方面都有共同的价值观。你们认为理想的协作是大家都在办公室里坐在一起，而不是发消息，我们会直接指着屏幕说：“嘿，Nathan，过来看看这个。”你们认为这会是理想的情况吗，我们正在讨论的问题仅仅是由于远程工作带来的问题吗？或者你们认为，五个人围着一个屏幕在办公室里进行结对编程，所有代码都直接推送到主干，这也不是理想的？
Nathan：不，我不认为所有人都在主干上进行结对编程是合理的。对我来说，能够拥有独立的同步开发流是合理的。但我要说的是，我在 Pivotal 的办公室里花了很多时间进行结对编程。我宁愿拥有自己的屏幕、自己的键盘和自己的显示器，但坐在旁边的人也有他们自己的屏幕。因为这样我就可以独立导航了。我们不必争抢键盘。
所以，我认为，在我们可以实际互相看到，可以从别人的肩膀上看过去，在共享环境中讨论代码的现场设置中，它不是那么必不可少。但在远程设置中，我们需要一个共享环境。而现在，我们的共享环境是 GitHub，它有这些限制，你必须拍摄快照并推送，并且共享那个特定的环境涉及所有这些摩擦。
或者还有其他工具，比如 Slack，它不是为代码设计的。或者各种形式的屏幕共享，也不是为代码设计的，所以它是像素化的，而且只能一个人操作。
所以在远程环境下，我不知道远程团队是如何生存的。我的意思是，我确信它会发生，但我只是觉得我们作为一个团队的运作要好得多，因为我们有能力实际——不是 100% 的时间，但至少在某些时候——一起工作。
Thorsten：回到 Max 所说的，他在咖啡店里坐着，你给我发消息，然后等待回复的场景。如果我们在办公室里坐在一起，你有了问题，也不会只是拍拍我的肩膀，你仍然会注意不要打扰别人，对吗？
Max：如果我必须在办公室里坐在某人旁边，或者只在拉取请求中异步互动之间做出二选一的决定，我会选择前者。但我认为我们正在努力构建的比两者都好。
仍然有这种专注的时间，你只与其他人异步处理事情，但当你需要时，你也可以跳入同步互动。
Thorsten：我听到的信息是你们都对协作有着共同的价值观。对你们来说，协作不仅仅是“我需要有人在拉取请求上给我打个勾，然后我就可以把它发出去”。你们想和别人一起工作。你们想一起工作，你们认为与他人作为团队一起工作很重要，并且你们认为软件的历史很重要，它如何演变成今天这个样子。这源于哪里？是你们在大公司工作的背景吗？还是在小公司工作的背景？或者是开源和与众多贡献者合作的经验？还是你们三位已经一起工作了 10 年，并且看到了这种工作方式的效果？
Antonio：对我来说，与他人一起写代码更有趣。我在智力上受到了更多的刺激。当然，我对我们正在构建的产品感到兴奋，但与其他人一起构建它给我带来了同样多的乐趣。这是我写代码时获得乐趣的一部分。而且我也认为这能写出更好的代码。
我通过与人一起写代码结交了朋友。在我工作过的每一家公司都是如此。这两个家伙 [Max 和 Nathan] 显然是一个很好的例子，但在其他公司也是如此，与所有我结对编程和合作过的人，我都建立起了关系。
我认为这作为人类非常重要。这是我真正感到兴奋的事情。与其他人一起工作，与他们成为朋友，并一起构建你能构建的最好的东西。
Nathan：如果你有一个团队，你迟早要和这些人交谈。这只是时间问题和方式问题。因为是的，你可以独自一人写大量的软件，但如果你有一个团队，大概你拥有团队的原因是，有比一个人独自能写的更多的软件要写。这意味着总体的软件将是多人编写的软件的组合，抱歉，但你将不得不沟通。所以现在问题是如何沟通。对我来说，GitHub 的协作模式一直感觉像是在发电子邮件。它是异步流程。这适用于某些问题。但其中一些，我不知道，我们今天早上处理的关于绘制顺序的问题，就像……我不会以电子邮件的速度和别人讨论这个问题。我要么独自一人坐着思考，要么我在一个能够围绕这个问题进行更细粒度沟通的工具中。
Thorsten：那么，如果我们将您的愿景贯彻到底，今天的工具还剩下什么？我们还会保留拉取请求吗？我们还会保留 Git 吗？我们还会保留 Git 提交、分支吗？
Nathan：我的意思是，从足够长的时间范围来看，我认为让协作比使用 Git 更方便会很好。
我的意思是，我确实认为我们会拥有分支。因为分支是一种促进异步工作的工具，而这仍然是一种重要的工作方式。你必须能够做到这一点，即使是两组人在两个不同的事物上同步工作，但彼此之间是异步的。这是一种根本上重要的工作方式。
但我认为异步在 GitHub 出现时是一场革命，因为在此之前，在 SVN 上分支非常麻烦。所以我仍然认为分支会存在，异步工作流会存在。我只是认为它将是你可以对代码进行的潜在交互谱系上的一个点。你选择谱系上的那个点，不是因为它唯一可用的工具，而是因为它对于你所处的情况最有意义的方法。
Thorsten：那么这种开发方法有多少是文化因素，又有多少是工具因素呢？为了解释我提出这个问题的缘由，看看过去 15 年的 DevOps：有些人说，“哦，一旦我们有了云计算和不可变基础设施，DevOps 就开始大放异彩。”而另一些人则说，“这是一种心态。这是你思考开发以及如何让其他团队参与的方式。”你们三位对协作有着共同的理解。你们认为如果我们构建能够实现这种协作的工具，其他人也会接受吗？或者你们认为这同时也是一种文化因素，其他人必须接受作为团队构建软件的理念？
Nathan：我一直以来的希望是，通过大幅减少这种沟通方式的摩擦，我们能帮助人们在文化上向这个方向成功迈进。
Max 和我都有幸在 Pivotal 进行结对编程，在那里，那就是工作方式。每个工作站都为结对编程而设置。整个世界都围绕着你将进行结对编程的假设而设计。我们学会了与人实时合作是多么酷。我不知道如果我没有那段经历，我是否会克服屏幕共享的麻烦，或者在我们构建 Zed 之前我们所做的一切。
Antonio：我的意思是，我没有在 Pivotal 有过那样的经历，对吧？在加入 Atom 之前，我没有和任何人结对编程过，对吧？我想我第一个真正深入结对编程的人是 Nathan。我的意思是，我记得那些最初的会话，我当时想，天哪，这太激烈了。现在仍然如此。以一种好的方式。所以，我想 Nathan 和 Max 让我接触到了这种文化，你可以这么说，但我想对我来说，从第一天起就水到渠成了。它在技术层面对我来说很激烈，但从未在情感或人际关系层面上激烈。从第一天起就更有趣了。我不是一个人在做这件事。我正在和别人一起做。
我觉得……Thorsten，我们已经结对编程了，嗯，你加入多久了？
Thorsten：五，五，六，五周，我想。
Antonio：我觉得如果我们不每天结对编程，我永远无法在远程的情况下与你建立起关系。它根本不在同一个水平上。
所以，是的，这里面有一些文化因素，但同时，也不是说人们没有进行对话。人们确实会求助于工具进行那些对话。所以我认为存在这种需求。而且我认为，是的，拥有一款工具，它能让你进行更多对话，或者只是简化你已有的对话。是的，那会很好。
Max：是的，我认为结对编程有一个内涵。人们认为它有点小众或什么的。它与所有这些东西相关联，连接到电脑上的两个键盘，与之相关的工具，因为输入设备是同一个而不得不停止打字，因为另一个人想打字。
人们会说，“我不想在写代码的时候有人盯着我的肩膀。”我想我听过这种说法。但就像 Antonio 刚才说的，除非你只解决非常简单的问题，否则你必须和某人进行一些对话。你必须有一个可以交谈的团队。所以这只是何时以及如何的问题。
我甚至不知道一旦它变成这样 [Zed 的协作方式]，我们是否还需要“结对编程”这个词。它只是另一种非常自然的工作方式。它没有两个键盘的内涵。它没有两个人做一条工作流，以及人们有时谈论结对编程时所说的这种低效的内涵。
因为我们实际上可以同时在同一个缓冲区中修复编译错误。所以我不知道我们是否还需要结对编程的概念。一旦我们完成，我想它会像你们一起在 Slack 中聊天一样自然——我们不会说我们在“结对文档”。
这只会是一种协作方式：你可以实时协作，也可以分开协作，你可以在不同的缓冲区中，也可以在同一个缓冲区中。它只是更多的短暂状态。在你的共享环境中，有更多的协作方式。
Nathan：我要说一件事，我们谈论了很多关于结对编程或实时协作，我认为这很合理，因为那是我们在 Zed 中构建的第一件事。那是 Zed 现在支持的功能。但现实是，尤其是在我的角色中，我只是做了很多交谈。有时我只想——这很有趣，我只想不和任何人交谈，只是保持沉默，这就是我兴奋于 CRDB [有关更多信息，请参阅此处，关于将代码和 CRDTs 存储在数据库中的想法] 和注释的原因，这是一种基于文本的与人交互模式，也是实时的，但我不需要说话，或者至少不需要立即说话，我可以直接在我的代码中提问。
Max 早期提出的那个观点，我也仍然非常兴奋。作为这个协作编辑器的创始人之一，有时我只想安静地听音乐或做其他事情，这听起来很讽刺。但这是真的。而且我认为这没什么不对。但我也不一定非要推送一个 WIP 提交才能进行简单的代码文本对话。所以这是我们下一阶段要做的事情。
Thorsten：作为一名非提问者，我想插入一下：我确实认为你所说的它是一个“频谱”是最重要的一点，它不是二元的，不是在办公室里坐在一起和邮件列表之间做出选择。在过去的 10 分钟里，我一直在想，当我第一次作为软件工程师实习时，我做了很多结对编程。这是我第一次这样做。当我第一次听说结对编程时，我认为这太疯狂了，但后来我做了，你所拥有的带宽和吞吐量以及共享的理解——如果你从未体验过或从未构建过这样的软件，很难传达。当我后来加入下一家公司时，我仍然是一名初级工程师，我经常会被一位高级工程师带着，他会让我坐在他旁边，然后说，今天我们要写 SQL 查询，你会爱上它的。从那以后，这些年结对编程越来越少，但我一直知道这是一种可以使用的模式，比如“嘿，我们打个电话吧，或者我们一起做这个吧。接下来的三个小时，就你和我，我们一起做。”所以我确实认为，知道存在这个频谱，并且它不是二元对立的，是非常强大的，而且你实际上可以每天和人们一起工作五个小时并进行协作。嗯，我没有问题，抱歉。但这是否反映了你的想法，你希望在不同模式之间无缝切换？有时协作意味着异步，有时意味着同步，有时我希望独处。但它总是触手可及，没有任何摩擦。
Nathan：是的。而要做好这件事的唯一方法，以及我们想构建 Zed 的一个重要原因——不是唯一原因，我想构建 Zed 的第一原因是，就是为了构建地球上最棒的代码编辑器，句号——但另一个重要的理由，至少在早期，是我真的认为要做好软件协作，你必须将它集成到你用来编写软件的工具中。这是一种沉浸式体验。所以这是一个有争议的观点。我知道要真正推销这个观点，编辑器必须非常棒。对吧？我不会仅仅为了协作而使用一个糟糕的编辑器。它必须是我本来就想使用的编辑器，因为它很棒。但如果我能直接将代码视为这种共享的产物，作为体验中固有的无缝部分，那我就成功了。
Thorsten：你为什么认为这有争议？
Nathan：嗯，这意味着要将 Zed 作为协作工具使用，你作为团队需要全面投入 Zed。但我认为，我不知道，我认为这很好。有些人可能只会以更单人模式使用 Zed，或者他们可能更选择性地使用 Zed，与团队中其他使用它的成员一起，但也许整个团队没有使用这个编辑器，他们同时仍然使用传统的异步协作工具。
但我确实认为，以 VS Code 为例存在的模式是，一个人采用了它，然后逐渐整个团队都趋于标准化。但这确实是一件大事，这就是它引起争议的原因。我认为这种想法有点像苹果的方法，垂直整合。我们将拥有整个体验。
Antonio：是的。我完全可以看到未来，这种协作体验可以作为……Zed 不是唯一可以与之集成的东西。
构建编辑器的主要原因之一，就像 Nathan 所说，是它垂直集成。这意味着我们真的可以提供我们想要的用户体验。我们不需要受限于 VS Code 或 Atom 中扩展的制作方式。我们曾经尝试过一次，对吧？在 Atom 中，我们尝试构建了 Teletype。Teletype 是一个软件包，它的最大问题是编辑器的核心数据结构不是协作式的。所以我们有这个扩展，它基本上复制了整个缓冲区。它是缓冲区的并行版本，而且……你可以做很多事情，但你肯定能感受到其中的局限性。
因此，构建编辑器的主要原因是不受这些限制，但我完全可以看到未来，我们构建的这种协作框架可以与其他编辑器交互。只是它不会是第一流的体验。
Nathan：或者也许可以，但我们想要构建一流的体验，而做到这一点的唯一方法就是自己构建。但如果有人不想使用我们最终构建并标准化和推广的 GPUI 界面来获得协作体验，那也没关系。但要实现这一点还需要一段时间。
Thorsten：你认为为什么大多数软件世界仍然依赖拉取请求？在过去几年里，人们一直在说：“我想要更好的代码审查，这不是我想要的，让我们用其他工具吧。”然后人们尝试不同的东西，但它并没有真正流行起来。那么你认为这是为什么？我们是否达到了一个局部最大值，还是技术缺乏，或者是其他原因？
Nathan：我只是不认为其他任何替代方案足够好。我们使用拉取请求。去看看 Zed 的仓库。大量的拉取请求，包括我们团队内部提交的。现在，其中的许多提交可能有两个作者，但我们仍然使用它们。因此，对于这种异步模式，让我们看看差异，留下一些评论，我的意思是，也许你可以围绕这种体验的边缘进行一些改进。
但现实是，GitHub 对这种工作流程的呈现对大多数人来说已经足够好，不值得额外付出切换到一些不太熟悉的工具，或者代码不是托管在其中的工具等等的开销。
但 Zed 今天能实现什么，以及当我们实现我们正在努力的目标时，它将能实现什么——我想我仍然在 Zed 频道中直播这场对话。
Thorsten：哈哈哈。
Antonio：哈哈哈
Nathan：好的，我离开。是的。
我们正在努力实现的目标，用快照是无法做到的，对吗？我们谈论的更多是面向操作的 CRDT，或者更细粒度的交互。在我看来，这些替代的拉取请求审查工具或分支审查工具并没有从根本上改变范式。
Antonio：关于拉取请求有很多可说的。我认为 GitHub 不仅对快照的展示很好，而且 PRs 也附带了很多东西，对吧？有 CI，对吧？这也是很大一部分。
Nathan：我并不反对拉取请求，我会继续使用它们，或者，你知道，如果我们最终决定将它整合到 Zed 中，我也会继续使用异步工作流。只是，我认为我们迫切需要同步工作流。
Thorsten：Nathan，你提到了整个软件开发生命周期，其常见定义通常包括部署、调试等，甚至事件和类似的东西。但到目前为止，我们只谈论了共同编写代码的部分。
Nathan：对。那么那段代码之后会发生什么？
Thorsten：是的。在你的愿景中，你也会改变其他部分吗？我们如何调试生产软件，我们如何一起查看事件等等？
Nathan：嗯，我确实会，是的。没有那么多，但 Antonio 和我在深入研究 Zed 之前曾稍微研究过这个想法——GitHub 以前有 Hubot，它是在 Slack 频道中进行操作的。我想，有一个协作终端会不会更好？它是一个共享终端，一个 shell 环境，你可以在其中聊天，有点像把聊天带到 shell，而不是把 shell 带到聊天。所以这是我想做的一件事，拥有这种协作式情况室/操作/共享终端类型的东西。
关于开发生命周期的其他部分，我还有另一个想法，就是让你的编辑器成为你许多这些事情的指挥中心。但我还没有对此进行深入思考。我的意思是，我曾梦想过使用一些锚定设施，比如将代码几乎视为一个数据库。所以当异常开始涌入时，你几乎可以将它们写入代码库，作为“生产环境中此处发生了异常”，这种元层漂浮在一切之上。然后这会在编辑器中浮现出来。因此，真正开始将代码库本身作为所有关于生产中发生的事情、性能信息、抛出的异常等信息的基础，可以进行注释，然后浮现给开发人员，你在那里可以看到。你打开一个文件，你会看到，不是在这个确切的代码版本中，而是在生产环境中，昨天，这里抛出了一个异常。这不是很令人感兴趣吗？所以更多的是将它们整合在一起。
这绝不会在下周发布，但我真的很想看到它。
Thorsten：最后一个问题，我之所以提出这个问题，是因为我对此改变了看法。所以，当我加入时，我说：“Nathan，我们什么时候给 Zed 添加视频通话功能？我需要在 Zed 中进行视频通话。”现在我不确定我是否想要视频通话，因为当我不需要担心我的样子，或者我的手和脸在做什么时，对我来说改变了很多。而且仅仅和人们进行电话通话感觉非常好。你认为这很重要吗？这是一种幸运的巧合吗，你们只是没有时间实现视频通话，但现在它就这样工作了。或者你认为我高估了音频通话与视频通话的重要性？
Max：Thorsten，我感觉和你一模一样。视频通话不开启时，至少默认不开启时，对我来说感觉更轻量。看到你们所有人的脸也有一些不错的地方。所以我还没有形成一个坚定的哲学，但我有点喜欢我可以，我不知道，吃着墨西哥卷饼，然后只是查看别人的代码，然后……
Nathan：对我来说，添加它似乎没问题。不会增加太多额外的复杂性。所以我们可以添加它。只是它不是优先事项，因为我们不需要它。
Antonio：我这周和我的治疗师聊了聊，我们谈到在治疗中，你坐在那儿，有张椅子，还有什么来着？沙发？是的。她基本上向我解释说，不看治疗师，只是凝视虚空，会让你进入意识流模式。
我有点喜欢没有视频的这种感觉，我想。我可以只是盯着某个东西，然后把想法倾吐出来。
Nathan：但我会说的是，我买了一个 Vision Pro。我可能会把它退回去，因为它太重了。我可能会留下它。我不知道。我正在努力决定。但我想要的是，如果我能在我周围设置一个虚拟办公室。我想要一种情境感知，我认为视频并不能真正增加这种感知。我正在寻找其他东西。
我记得在 Pivotal，他们会有很宽的桌子，他们会把四张甚至有时六张桌子拼在一起，形成一个大工作区。你会一起工作，你会感受到周围人的能量。你会听到这边人们在谈论什么。所以，了解人们在做什么，他们在哪里，这很重要。
我们正试图在频道面板中稍微复制一下，你可以在那里看到面孔。
而且我认为 Antonio 的脸的视频对我来说并没有那么有用。我只是需要那个 GPtonio 编码输出，你知道吗？但如果我能看到 Max 和 Conrad，或者你和 Julia……
Antonio：……吃墨西哥卷饼。
Nathan：……那样会很酷。但是，你知道，我们还是先让 Following [Zed 协作模式中的一个功能] 正常工作吧。