00:00:00我们正处于软件开发的新时代。开发者们交付产品的速度
00:00:04是前所未有的。然而，一个问题也随之而来。当智能体参与其中时，
00:00:08传统的工作流就失效了。这引出了一个重要的问题：现在的开发者
00:00:13角色是什么样的？最近，Linear 首席执行官的一篇文章引起了我的注意。Linear 是一款
00:00:18专为现代软件开发设计的项目管理工具，旨在帮助团队组织和跟踪工作。
00:00:23这些见解来自一位亲历了从传统工作流向
00:00:27当今 AI 驱动系统转变的人。这篇文章让我重新思考的不仅是我们使用的工具，
00:00:33还有我们构建产品的方式。今天我们有很多内容要聊，
00:00:37因为这些信息从根本上改变了我们利用 AI 进行构建的方式。软件工作的“中间环节”正在消失，
00:00:43软件的核心正在发生转移。为了理解什么是中间环节，让我们先看看
00:00:47在 AI 介入开发之前，工作是如何分配的。首先是起始阶段，这包括
00:00:52所有的需求收集和规划。在这个阶段，我们要为构建目标制定计划。
00:00:57接着是中间环节，也就是将计划转化为实际产品的阶段，
00:01:01其中涉及编写代码。这部分工作最为耗时，
00:01:05往往需要数周、数月甚至一年才能交付一个高质量且完整运行的系统。这
00:01:11也是细节最容易出错的地方，因为涉及意图的转化或人与人之间的想法传递。
00:01:16代码写完后，结束部分包括各种形式的
00:01:20测试以及对照原始需求进行评审。中间环节曾是阻力最大的部分，
00:01:25但那位 CEO 表示，这种情况将不复存在。因为
00:01:30中间环节的工作，即具体实现和编码部分，正逐渐被 AI 取代。
00:01:35现在我们甚至完全不需要亲自动手写代码。这是因为编码智能体已经变得非常强大，
00:01:40它们能够仅根据上下文和任务规划来生成代码。现在的重点在于
00:01:45以正确的方式使用智能体并监督其工作，而不是亲自编写。如果你经常
00:01:50观看我们的视频，会发现我们已经演示了许多利用编码工作流
00:01:55生成生产级应用的不同方法。你只需要监督智能体，无需亲自动手
00:01:59编写一行代码。IDE（集成开发环境）已逐渐演变为代码查看器而非编写工具。这种
00:02:04变化对我来说非常明显，因为作为开发者，我以前用来写代码的工具现在
00:02:09已经变成了评审智能体所产出代码的工具。现在我进入 VS Code 只是为了评审或
00:02:14添加注释，以便 AI 智能体实现注释中的功能。由于智能体极其能干，
00:02:19我几乎很少需要自己动手修改或编写代码。但这
00:02:23仅在智能体能理解意图的前提下才有效。因此，我们作为开发者的工作本质上已从
00:02:28编写代码转向了监督代码。你可能注意到了，我们在这些视频里构建了很多东西。
00:02:33那些你平时需要暂停视频从屏幕上复制的提示词、模板等内容，
00:02:38我们已经把它们全部整合在了一起。我们最近推出了 AI Labs Pro，你可以在那里获取
00:02:43本视频以及过往所有视频中的资源。如果你觉得我们的内容有价值并想支持频道，
00:02:48这是最好的方式。链接就在简介里。既然 AI 已经接管了大部分
00:02:53编码工作，那就产生了一个问题：我们还剩下什么？答案是，专注于打磨
00:02:59“构建意图”这一新工艺。实现这一目标的方法是把规划作为
00:03:03你的主要工作。你需要清晰地理解你要解决的问题，
00:03:07需要知道客户真正的需求以及人们会如何使用你的应用。这在当下
00:03:12变得更加重要。你不再依赖于能够从糟糕的规划中揣摩意图的人类，
00:03:17而是依赖于那些只会盲目执行你指令的 AI 智能体。无论
00:03:23你是构建移动端应用还是 Web 应用，你都必须明确地知道自己想要什么。没有
00:03:27清晰的思路，你就无法利用智能体的规划模式进行有意义的规划。规划至关重要。
00:03:32正如我们在之前的视频中强调的那样，只有好的计划才能带来好的实现。无论
00:03:38你使用哪种智能体，规划都非常重要，因为它控制着智能体的产出结果。为此，你可以
00:03:42花费足够长的时间不断完善计划，直到它完全满足你的需求并达到预期。
00:03:47这将确保你的应用按照你想要的方式呈现。直到三个月前，
00:03:52我们在构建时还不敢依赖“绕过许可模式”，因为即便有好的计划，智能体仍会产生幻觉。
00:03:56而现在，智能体变得非常可靠，以至于在完善计划后，我只需开启
00:04:02“绕过许可模式”，让智能体一次性完成规格说明的开发。我们
00:04:06还注意到，甚至连 Claude Code 的创始人在开始实现时也是从规划模式入手的。如果
00:04:12计划足够出色，你就可以放手让智能体一气呵成地构建应用，而无需担心混乱的
00:04:16代码实现。我还会花大量时间确保我所构建的内容都有
00:04:21完整的文档记录。我不会把所有内容都塞进一个文档里，以便让智能体能够轻松
00:04:26阅读计划。我会针对每个类别使用不同的文档，例如风险评估、缓解措施
00:04:31和技术规范。我会将约束条件和权衡因素列在单独的文档中。这样智能体
00:04:35才能理解在性能、成本和时间方面哪些是可接受的。这种方法能让
00:04:40开发过程更加可控。在所有需求都经过验证后，下一步就是
00:04:45实际管理智能体并获得我们想要的结果。但在讨论那个之前，先听听我们赞助商的一段话。
00:04:50Dart AI。管理复杂的软件项目往往涉及大量的行政开销，
00:04:56甚至超过了实际编码。Dart 不仅仅是一个标准的项目管理工具，它是一个 AI 原生的
00:05:00工作区，旨在为开发者自动化繁琐的工作。凭借具备上下文感知能力的 AI 聊天功能，你
00:05:05甚至可以通过自然对话来创建任务和编辑文档。除了 AI 聊天，你还可以接入
00:05:11像 Cursor 这样的智能体来执行工作。Dart 为它们提供背景信息来编写代码。其
00:05:16核心实力在于其 AI 指南功能。你可以配置全局规则，例如要求 AI
00:05:22始终以特定的目标和需求标题来格式化技术规范，Dart 会在它生成的
00:05:27每一次对话、任务和文档中强制执行这一结构。对我们来说，AI 技能功能改变了游戏规则。
00:05:33你可以定义自定义命令，比如“生成项目”技能，它可以自动创建
00:05:38填充完整的任务列表、分配优先级、估算规模，并在几秒钟内草拟出项目简报。
00:05:44立即访问置顶评论中的链接，试用 Dart AI，开始自动化你的项目管理吧。
00:05:49你不再只是一个写代码的人。你的工作更多是围绕监督智能体，而非
00:05:54实际编写代码。写代码已不再是去构建一个解决方案，而更像是
00:05:58设定好条件，让优秀的解决方案自然产生。那么，如何为智能体
00:06:03创造出产出高质量结果的正确环境呢？答案就是“上下文工程”。你需要
00:06:08学习的下一个核心技能不是像 MERN 或 MEAN 这样的特定开发技术栈。相反，它是
00:06:14“上下文管理”。我们一再看到，如果没有适当的上下文管理，智能体虽然会执行
00:06:18我们提示的功能，但它不会遵循任何本该匹配代码实现的约束或规则。
00:06:22我们需要确保上下文得到妥善管理。当智能体获得了
00:06:27干扰最小的正确信息时，它能更清晰地理解任务，产出更好的
00:06:32实现方案，并交付你完全想要的东西。管理上下文涉及使用一系列
00:06:37组件，如可复用命令、技能、Markdown 文件、MCP 以及子智能体。这里
00:06:43没有唯一的标准方法。你应该结合多种适合你所构建项目的方法。
00:06:47你需要创建一个适合自己项目的流程。我们专门制作了一个
00:06:52完整的视频来演示如何通过上下文管理构建工作流。这能确保你使用的模型
00:06:56获得正确的上下文，并能产出高质量的应用程序。如果你想跟着做，
00:07:01该视频的所有资源都可以在 AI Labs Pro 中找到。智能体的工作
00:07:06质量取决于它运行的上下文驱动环境。它与客户反馈的连接越直接，
00:07:11且有结构化工作流的支持，它的表现就越好。我们需要
00:07:16主动创造这样的环境，因为它不会自动生成。出于这个原因，
00:07:20Claude 与 Slack 建立了连接，以便团队可以直接报告错误。这创建了宝贵的
00:07:25反馈闭环，甚至连 Claude code 的创始人本人也在使用。大型团队已经在产出
00:07:30高质量的 AI 生成代码了。Claude code 的创始人声称，在过去的一个月里，
00:07:35他 100% 的代码贡献实际上都是由 Claude code 编写的。这并非
00:07:41仅靠给一个提示词就能实现，而是需要一套工作流和编排模式来达成。
00:07:46甚至微软的 CEO 也承认，AI 现在生成了微软所有语言中 20% 到 30% 的
00:07:52集成代码。在 Python 和 C++ 方面的进展尤为显著。
00:07:58工具中的结构化对人类和智能体同样有效。它通过
00:08:03明确预期和现有能力来减少不确定性。如果你在使用 AI 智能体时
00:08:08没有结构，那么你只发挥了它们潜力的冰山一角。这种结构可以有多种
00:08:13形式，包括用于整体项目指导的 Claude.md 文件和用于跟踪变更的变更日志。
00:08:19你还可以使用可复用的命令或带有脚本和引用的专门的 skill.md 文件。
00:08:25此外，你还可以使用插件和 MCP 工具来扩展智能体的能力。
00:08:29但仅了解这些工具是不够的。正确的组合至关重要。每个项目
00:08:34都需要不同的配置，因此你必须根据项目需求来构建。通过适当的平衡，
00:08:39你会得到想要的结果。在规划并将任务委托给智能体后，我们的工作并未结束。
00:08:44现在，正如我提到的，我让 Claude code 在“危险跳过许可模式”下工作，
00:08:49这确实节省了大量时间，但它需要我们将时间和精力转向其他地方。
00:08:53压力转移到了开发周期的末尾。代码评审变得更加重要。
00:08:58未经评审的代码可能会导致性能下降和高昂的成本。你可以使用
00:09:02结构化工作流来简化评审工作。这将减少 Bug，并避免后期出现问题。
00:09:07现在，测试不再只是简单地对智能体说“帮我测试应用里的所有问题”。它涉及
00:09:12几种改进流程的方法。其中一种是测试驱动开发（TDD）。我们要求
00:09:17智能体在最初不编写任何代码的情况下，先为我们想要实现的功能编写测试用例。
00:09:22测试写好后，我会清除上下文并开启一个新窗口。这能确保智能体
00:09:26失去关于它是如何编写这些测试的记忆。我让 Claude 运行测试，它们会失败，
00:09:31因为还没写任何代码。既然确认了测试能正常运行，我再要求 Claude
00:09:36去实现对应的路由。我确保它不会修改测试代码。这样，智能体就有了一个
00:09:41清晰的迭代目标。在 TDD 中，测试先于代码，但测试也应在
00:09:46代码写完后进行。为此，有多种测试形式。我使用黑盒测试
00:09:51并创建用户故事。这些故事作为详细指南，描述用户实际将如何
00:09:56与系统交互，以及这些交互可能如何引发错误。黑盒测试
00:10:00根据需求评估应用程序的功能，而不去查看代码本身。
00:10:05然后，我使用 Claude 的 Chrome 扩展程序进行测试，并要求它逐个章节地
00:10:10迭代每个用户故事。黑盒测试主要识别功能问题。而对于
00:10:16性能测试，我们也需要白盒测试。这时我们要实际查看代码，而不仅仅是
00:10:21输出。我们会追踪代码的实现方式，并推敲其架构。对于白盒
00:10:25测试，我使用一个包含多个测试章节和子章节的 XML 文档。该文档
00:10:31作为 Claude 的指南，告诉它如何阅读代码以及如何发现架构问题。
00:10:36为了简化测试，我使用一个自定义命令来执行文档中的测试，
00:10:41我把它放在了 testing 文件夹中。这个命令列出了初始化测试的指令、
00:10:46如何以结构化格式将结果记录到文件中，以及最后如何生成一份最终
00:10:51报告。这个斜杠命令让白盒测试变得简单，因为它包含测试用的
00:10:56结构化提示词。既然中间环节正在消失，重心正更多地向开始和
00:11:01结束阶段转移，我们就需要重新审视优先级。我们现在需要优先考虑的
00:11:05是通过规划和需求评估来形成正确的意图。我们还必须通过彻底的
00:11:10测试和评审过程，确保结果符合预期。那些掌握了这些
00:11:15原则的开发者将成为引领未来的人。视频到这里就结束了。如果你
00:11:20想支持本频道并帮助我们继续制作此类视频，可以点击下方的
00:11:24“超级感谢”按钮。一如既往，感谢观看，我们下期再见。