从单点提示到自主循环的范式转变

随着大语言模型能力的提升，开发者对 AI 代理（Agent）的依赖正在发生深刻变化。传统的交互模式往往需要大量的方向指引、严格的约束条件以及丰富的示例，但现在的模型已经能够处理更复杂的长期任务。为了实现这一目标，Claude Code 团队引入了 /loop、/goal 以及工作流（Workflows）等机制，旨在让代理能够在无人工干预的情况下持续运行较长时间。这种转变的核心在于从“单次指令”向“自主执行”的演进，让 AI 不再仅仅是一个问答工具，而是一个能够独立完成任务的执行者。

“随着模型变得越来越聪明，它们需要的方向更少，约束更少，示例也更少。我们有了 /loop、/goal 和工作流，这些都是为了让代理能够长时间运行。”

这种能力的提升使得开发者可以将精力集中在任务的设计上，而不是每一步的微观控制。通过提供明确的退出条件和反馈机制，代理可以在遇到复杂情况时自行判断是否继续执行，从而大大提高了工作效率。这种自主性是未来 AI 辅助开发的重要趋势，它允许代理在更长的时间跨度内处理非确定性的任务，而不仅仅是瞬间的响应。

/goal 与 /loop 的核心机制解析

在 Claude Code 的工具集中，/goal 和 /loop 是两种不同但互补的机制，用于控制代理的行为模式。/goal 的主要作用是帮助代理明确其退出条件（Exit Condition）。在许多复杂任务中，代理可能会因为遇到未预见的困难或不确定因素而过早停止。通过 /goal，用户可以明确指定任务完成的标准，告诉代理“只要达到这个目标，就可以停止”，从而防止代理在任务尚未完成时就放弃。这种机制特别适用于那些需要长时间探索或执行的任务，例如代码重构或复杂的数据处理。

“/goal 帮助代理提醒自己的退出条件，只有在满足条件时才允许退出。这对于防止代理过早停止非常有效。”

相比之下，/loop 则更侧重于反馈循环。它允许代理在执行过程中不断接收反馈，并根据反馈调整后续的行动。这种机制类似于人类在学习过程中的“试错”过程，代理可以通过不断的迭代来优化其输出。/loop 特别适用于那些需要精细调整的任务，例如代码调试或内容生成。通过结合 /goal 和 /loop，用户可以构建出既具有明确目标又具备灵活调整能力的自动化流程。

工作流：非确定性任务的确定性分解

工作流（Workflows）被认为是这三种机制中最强大的一种形式。它允许用户启动多个子代理（Sub-agents），分别负责执行任务、并行处理工作以及验证结果。这种架构特别适用于非技术性或非确定性的任务，例如视频编辑、设计审核或内容创作。在这些任务中，传统的线性指令往往难以保证最终结果的质量，而工作流通过引入验证代理（Verification Agent）来确保每一步的输出都符合预期。

“工作流可能是最强大的形式，你可以启动子代理来并行工作并验证工作，特别是对于非技术性工作，这可以将非确定性任务分解为确定性任务。”

在实际应用中，工作流可以将一个复杂的任务分解为多个子任务，每个子任务由专门的代理负责。例如，在视频编辑中，一个代理负责转录，另一个负责生成字幕，第三个负责添加特效，最后一个负责验证最终效果。这种并行与验证相结合的模式不仅提高了效率，还显著提升了结果的准确性和一致性。对于设计类任务，工作流还可以结合特定的工具（如 Figma MCP）来验证渲染结果是否符合设计规范，从而减少人工审核的成本。

实战案例：自动化视频编辑工作流

为了展示这些机制的实际应用，Thariq 分享了一个具体的视频编辑案例。他录制了一段简短的视频，并在其中口头描述了编辑需求，包括转录、字幕高亮、叠加层（Overlay）添加以及淡出效果。通过一个单一的提示（Prompt），他启动了 Claude Code 的工作流，要求代理使用 Whisper 进行转录，使用 Reotion 创建 UI 以显示逐字高亮的转录文本，并确保视频完全渲染。

“这是一个单一的提示，它转录了视频，创建了字幕和叠加层，然后淡出到黑色。虽然它不知道我的名字是 Thariq，但整体流程非常流畅。”

在这个案例中，代理成功执行了转录、字幕生成、特效添加和最终渲染等一系列复杂操作。尽管代理在识别特定人名（如 Thariq）时出现了小错误，但整体工作流的自动化程度和执行效率令人印象深刻。这个案例展示了如何将非技术性的创意工作转化为可执行的数字化流程，通过明确的指令和自动化工具，实现了从原始素材到最终成品的快速转换。这种模式不仅适用于视频编辑，还可以推广到其他类型的创意内容生产中，极大地提升了内容创作者的生产力。

视频编辑工作流的初步构建与技能沉淀

在当前的视频编辑工作流中，作者首先利用 Whisper 工具将视频转录为文本，并生成了相应的 Reotion 素材。这一过程构成了非技术性工作在 Claude Code 中应用的基础起点。虽然初期可以通过手动提示词（prompts）完成操作，但作者强调，将流程固化为“技能”（Skill）并非第一步。相反，作者倾向于先通过探索明确需求，识别边缘情况（edge cases），待逻辑清晰后再进行封装。例如，在转录过程中，作者发现模型在判断手势指向时存在不足，这促使他思考如何引入更多元数据（如手指或面部追踪）以优化后续的字幕叠加效果。

“我现在还没有技能。我想做的第一件事是真正弄清楚我想要什么，然后再把它变成一种技能。”

这种迭代式的探索不仅限于功能实现，更包括对工具局限性的认知。作者指出，了解工具的边界比盲目构建复杂工作流更为重要。通过预先识别 Whisper 可能出现的错误（如静音被误识别为“谢谢观看”、单词被拆分等），作者能够建立对工具的信心，避免在后期遇到“未知的未知”（unknown unknowns）时陷入被动。这种先探索后固化的策略，确保了工作流的稳健性和可维护性。

规划的本质：消除未知与迭代探索

作者重新定义了“规划”的概念，认为规划并非一次性写下的静态文档，而是一个动态的、迭代式的探索过程。在这个过程中，核心目标是消除未知数（getting rid of your unknowns）。无论是学习技术规格、制作原型，还是进行视觉探索，规划的本质在于发现“我不知道什么”以及“我真正想要什么”。作者以更新 UI 设计为例，展示了他如何通过给 Claude Code 提供参考链接（如 Peter Yang 的博客），让 AI 抓取 HTML 并生成多种设计变体。这种基于参考的探索不仅是一种规划手段，更是一种验证想法的方式。

“我认为规划更像是一个迭代的过程：探索、调查、发现你不知道什么、你想要什么……最终它会简化下来。”

在这一阶段，作者特别强调参考材料的重要性。通过提供具体的 URL 或设计示例，AI 能够更准确地理解意图并生成可交互的 HTML 工件（artifact）。这种可视化探索使得抽象的需求变得具体，帮助作者在实施前就明确设计方向。作者指出，规划的价值在于其过程性，它允许用户在执行前进行多次“试错”和“修正”，从而降低最终实施时的风险。这种以消除未知为核心的规划方法，适用于从技术调研到视觉设计等多种场景。

深入理解技术细节与避免常见陷阱

在规划过程中，作者花费大量时间深入理解底层技术细节，特别是 Whisper 转录的工作原理及其边缘情况。他利用 Claude Code 生成了详细的解释文档，重点分析了可能导致错误的场景。例如，Whisper 缺乏说话人识别能力，且对静音和断句的处理存在局限性。这些技术规格的认知直接影响了后续工作流的设计。作者强调，提前了解这些限制可以避免构建出看似复杂但实际脆弱的流程。通过这种深度调研，作者不仅掌握了工具的能力边界，还建立了应对潜在问题的预案。

“了解这些边缘情况和限制，真的帮助我避免了那种情况：我构建了一个复杂的 Whisper 工作流，然后发现有些东西出错了，而我却没有任何‘未知的未知’。”

这种对技术细节的执着体现在作者对“计划”文档的重视上。他使用前端设计插件生成了包含图像的可视化计划，确保文档不仅内容详实，而且易于阅读和理解。作者警告说，忽视计划和解释文档是一个常见的失败模式，因为 AI 生成的 Markdown 文件往往冗长且枯燥，容易导致用户产生惰性，直接跳过规划阶段进入执行。因此，保持对规划文档的主动阅读和更新，是确保项目成功的关键。这种对细节的关注和对文档质量的坚持，体现了作者严谨的工程思维。

迭代式探索优于一次性交付

在利用 AI 辅助开发时，试图通过单次指令完成复杂任务往往会导致效率低下和成本增加。Thariq 指出，虽然“懒惰按钮”看似便捷，但在处理严肃项目时，这种一步到位的策略通常会延长整体耗时。相反，采用迭代式工作流更为有效：先提出初步需求，学习相关背景知识，再要求 AI 制定更详细的计划，最终形成一个可共享且成熟的方案。这种循环往复的过程有助于在动手前厘清“想要什么”以及“技术上是否可行”。例如，他在研究视频识别算法时，曾尝试探索视频分割技术以实现“文字置于主体后方”的效果，但发现当时缺乏足够可靠的方案。通过这种逐步深入的技术调研，他避免了在不可行路径上的无效投入，确保了后续开发的稳健性。

利用 HTML 原型快速验证设计概念

在团队协作中，HTML 制品（Artifacts）已成为分享计划、PR 状态报告及事故报告的核心载体。尽管目前该功能主要面向 Teams 和 Enterprise 用户，但 Thariq 认为其价值在于将抽象需求可视化。由于他并非专业设计师，“只有看到具体设计才能理解其优劣”，因此他倾向于让 Claude 生成多种 HTML 样式供团队评估。在生成“叠加层样式”时，AI 可能更倾向于 Stack Overflow 或 Substack 的品牌风格，而非用户特定的红白配色。这种可视化的迭代允许团队在投入高成本的 React 开发前，先通过简单的 HTML 原型验证概念。如果原型效果不佳，只需调整提示词重新生成；若满意，再进入更昂贵的代码重构阶段。这种最小化可行步骤（MVP）策略极大地降低了试错成本。

动态规格说明书与双端工作流

传统的静态产品规格说明书（Spec）正在被动态演进的“活文档”所取代。Thariq 拥有十年撰写产品文档的经验，但他认为现代开发中，人类阅读与 AI 代理阅读的需求已融合。规格说明书不再是一次性交付物，而是随着 AI 实施过程中的意外发现而不断调整。AI 在实现过程中会反馈未预见的技术细节，团队据此更新规格，形成“人类需求 -> AI 技术探索 -> 原型验证 -> 迭代实施”的闭环。这种双向反馈机制取代了传统的“手递手”交接模式。在工作流分布上，多代理协作（Multi-clotting）主要在 Claude Code 的云端界面进行，用于并行探索、PR 规格制定和理解复杂问题；而当进入单一焦点的迭代实施阶段时，则转向本地终端。这种云端并行探索与本地深度实施相结合的模式，适应了不同阶段的任务需求。

Slack 作为多智能体协作的操作系统

Thariq Shihipar 展示了如何将 Claude Code 从单线程的编码工具扩展为基于 Slack 的多智能体协作平台。他不再维持五个独立的 Claude Code 会话，而是采用一个活跃的 Claude Code 主会话配合多个 Claude Tag 后台会话的模式。这种架构允许他在处理 Pull Request 时，让后台智能体负责修复测试并自动标记审查者，而审查者会在同一个 Slack 频道中收到通知，从而实现无缝的协作闭环。

"Slack 现在就是多玩家的 Claude 体验，因为大家本来就在那里。"

这种工作流的核心在于利用 Slack 现有的频道结构来管理不同的智能体身份。Thariq 拥有私有的 thoric-claude 频道处理个人工作，同时在团队频道或项目特定的工程频道中部署智能体。他认为，目前的编码应用本质上是单人体验，通过 Slack 的线程机制，Claude 能够以主动式代理的身份介入工作流，这种集成方式比强行构建新的协作界面更为自然且高效。

智能体身份、记忆与协作隐喻

在讨论人机交互的未来时，Thariq 提出了一个关键问题：是否应将 AI 智能体视为普通员工进行“入职”管理？ 他观察到，Claude Tag 中的每个频道都拥有独立的记忆空间，这赋予了智能体某种形式的持久身份。虽然将智能体比作同事有助于理解，但这种隐喻也存在局限性。智能体具备超越人类的记忆能力，但这种记忆是非线性的、波动的（spiky），有时准确有时遗忘，这与人类同事的连续性记忆有本质区别。

"它们比任何人类都有更好的记忆，但有时也更差。你知道的，它们是波动的。"

Anthropic 目前的策略并非将智能体框死在固定的“员工”角色中，而是探索模型能力进化的可能性。Thariq 指出，虽然可以通过 Slack 与智能体对话或“打电话”（隐喻调用），但智能体的主动性（proactive）和上下文记忆使其超越了传统同事的定义。这种设计允许用户根据任务需求灵活分配智能体的职责，而不是受限于僵化的职场层级结构。

播客生产技能的实际应用与局限

Thariq 展示了一个他构建的播客生产技能（Skill），该技能旨在自动化从采访转录到内容分发的全过程。他输入采访转录文本（例如对他同事 Jess 的采访），智能体随即生成多种内容资产，包括点击率导向的 YouTube 缩略图、新闻帖子文案以及视频剪辑建议。为了保持输出质量，Thariq 会提供示例以约束智能体的风格，确保生成内容符合其品牌调性。

此外，他还演示了另一个名为“视频发布技能”的工具，该工具能提取 YouTube 视频内容并生成剪辑创意，甚至能自动制作带有字幕的视频片段。然而，Thariq 坦诚地指出了当前技术的局限性：智能体目前无法智能地插入 B-roll（空镜）或自动从网上检索特定素材（如 Claude 的标志）进行叠加。他计划下一步指示 Claude Code 完善这一流程，通过脚本自动化解决素材检索和后期制作中的细节问题，从而提升最终成品的专业度。

"我希望它能智能到知道如何拉入视频剪辑所需的素材，比如你能在网上找到的 Claude 标志。"

技能复用与图像生成的局限性

在构建自动化工作流时，技能（Skills） 是提升效率的核心资产。作者建议将技能存储在用户级别的“个人操作系统”文件夹中，这样每次启动新会话时，代理（Agent）无需从零开始，而是直接调用已有的脚本和指令集，从而大幅减少重复劳动。这种结构化的知识管理方式使得代理能够像拥有长期记忆一样，持续积累和优化工作流。

"I have all my skills at the user level... the more you know scripts and sort of like things that you build up the more the agent can the less it has to do from scratch."

在视频缩略图生成的具体案例中，作者分享了使用 AI 图像生成 API（如 Gemini 或 OpenAI）的实际体验。虽然这些工具在更换背景或调整文本方面表现良好，但在面部特征保持上存在显著缺陷。当要求 AI 将一张微笑的照片改为震惊表情时，生成的图像往往严重失真，导致人物外观丑陋。这表明当前的图像生成模型在处理特定人脸的一致性上仍有局限，需要更精细的交互和迭代调整。

工作流（Workflows）与多代理协作

为了应对更复杂的任务，如批量生成短视频，工作流（Workflows） 提供了比简单扩展更强大的解决方案。工作流本质上是一个 JavaScript 文件，可以打包为可复用的技能。其核心优势在于能够分离子代理（Sub-agents），让主代理负责协调，而多个子代理并行处理具体任务（如生成 5 个不同的短视频片段）。

这种架构解决了两个关键问题：一是上下文管理，避免主代理因任务过多而混淆；二是验证机制。通过引入独立的验证代理，并设定明确的评估标准（Rubric），可以确保每个子代理的输出符合预期。工作流允许为每个子任务分配最大计算量，确保质量，而不是像并行处理多个简单任务那样可能因资源分散而导致质量下降。

消除自我参照偏差与上下文隔离

在工作流设计中，验证与执行的分离至关重要。作者指出，如果由同一个代理既生成内容又验证内容，会产生自我参照偏差（Self-referential bias），即模型倾向于对自己生成的结果更加宽容，导致验证流于形式。通过工作流，主代理协调任务，子代理执行生成，而独立的验证代理依据标准进行审核，三者使用不同的上下文和模型状态，从而有效降低偏差。

"You want to have a separate cloud doing the work versus verifying the work... separate cloud coordinating the work so that your main agent is coordinating it, each one doing the work and then verifying."

这种分离不仅减少了偏见，还促使模型投入更多计算资源进行深度思考，降低了提前停止（Stop early）的风险。每个代理都在其特定的上下文中运行，确保了任务的专注性和输出的高质量，这是简单并行处理无法比拟的优势。

生产力策略：单点聚焦与工具选择

在使用 Claude Code 时，作者混合使用终端和桌面应用，具体取决于测试需求。面对多线程任务带来的精力耗竭，作者提出了“少工作，多产出”的生产力哲学。他建议每年设定一个核心聚焦项目，即使有其他紧急任务需要解锁，也要保持主要精力的集中。

"My goal for this year is to be more productive but work less... I try to have like one project I'm focusing on."

作者发现，多任务切换是时间管理中的最大杀手。当人们因为懒惰或分心而同时处理多个项目时，上下文切换的成本极高。通过强制自己专注于单一核心项目，可以显著减少因任务切换导致的效率损失。这种策略虽然看似简单，但在实际执行中能有效对抗多任务处理带来的认知负荷，实现更可持续的高效工作。

多任务处理的适度原则与代码质量担忧

在利用 Claude Code 进行多任务并行处理时，不存在一个放之四海而皆准的最佳并发数量，这高度依赖于个人的工作习惯和具体任务类型。作者 Thariq Shihipar 指出，他倾向于在同一时间内只专注于一个核心任务，让 AI 代理（Agents）去处理其余的辅助工作。这种策略有助于避免因为过度分散注意力而导致的效率浪费。

然而，这种高度依赖 AI 代理持续工作的模式也带来了潜在的代码质量风险。作者坦言，他并不总是仔细审查 AI 生成的每一行代码，这让他担心如果缺乏定期的清理和维护，整个代码库可能会逐渐变成难以维护的“垃圾”（slop）。为了缓解这一问题，他依赖像 Boris 开发的 simplify 工具来定期简化仓库结构，或者直接在对话中要求 AI 对代码进行简化和整理。

"I worry that... the whole repo will just turn to slop at some point like if I don't... do you have any like uh routines or jobs that clean this stuff up periodically"

对于不同的应用场景，代码质量的要求也有所不同。例如，当 AI 用于生成视频输出相关的代码时，代码本身的优雅程度可能不如最终输出结果重要。在这种情况下，AI 代理的持久性和解决问题的能力比代码的组织结构更为关键。但即便如此，保持工作区的整洁仍然能带来心理上的舒适感，因此作者认为主动组织代码库依然是必要的习惯。

上下文窗口的精简策略：从约束到原则

随着大模型智能程度的提升，减少系统提示词（System Prompt）的长度已成为优化工作流的关键。作者团队发现，他们可以将 Claude Code 的系统提示词削减 80%，因为更聪明的模型不再需要大量的方向指引、约束条件或示例。过去，系统提示中会包含大量关于如何使用特定工具（如 batch tool）的示例，并明确列出“永远不要”做的情况。

然而，作者指出，过多的示例实际上可能限制模型的创造力。当模型被提供特定示例时，它可能会倾向于模仿这些示例，而不是探索更灵活的解决方案。相反，如果移除这些示例，模型反而能更自由地发挥。此外，解释“为什么”某些操作不可取，比单纯下达“禁止”指令更有效。例如，告诉模型“因为性能原因不要这样做”，比说“永远不要这样做”更能让模型理解背后的逻辑，从而在类似场景中做出更合理的判断。

"The examples are almost constraining it... if you remove the examples it actually can be more free format and like the constraints can also constrain it too"

因此，作者建议用户主动缩短上下文窗口，包括精简 Claude Code 的系统提示、技能描述（Skills）以及 MCP（Model Context Protocol）的配置。虽然 MCP 团队在工具搜索等方面做了大量优化，但总体上，给模型留出更多的“运行空间”，往往能获得更好的结果。这意味着在编写指令时，应减少硬性约束，转而提供背景信息和原则。

提示工程的核心：背景与原则优于硬性规则

在具体的提示工程实践中，提供背景信息和原则比设定硬性规则更能激发模型的灵活性。以撰写 Twitter 帖子为例，虽然 280 个字符的限制是硬性约束，但仅仅告诉模型“写一个少于 280 字符的帖子”可能不是最佳策略。作者建议，首先应向模型介绍使用者的身份和背景（例如：“我是 Anthropic 的 Claude Code 开发者”），并列出所遵循的核心原则。

这种基于背景和方法论的提示方式，赋予了模型更多的自主权。例如，如果目标是传播某个观点，模型可能会发现，将其拆分为两条推文组成的线程（Thread）比单条推文效果更好。如果用户只设定了“单条推文”的硬性限制，模型就无法探索这种更优的表达形式。通过设定“我更喜欢单条推文，但如果线程更好也可以”这样的原则，用户既保留了控制权，又允许模型在必要时突破限制，以找到质量最高的输出方案。

"Giving it the sense of like hey I want to write a tweet thread... gives us more freedom and flexibility. Yeah. To find something good."

这种策略的核心在于平衡约束与自由。硬性规则（如字符限制）是必须的，但在这些规则之上，通过提供背景、身份和原则，可以让模型在更广阔的搜索空间中寻找最优解，而不是在狭窄的规则框架内机械执行。

技术深度的价值：了解“未知的未知”

面对“编码已解决”的观点，作者认为保持技术敏感度对于有效使用 AI 代理至关重要。对于希望更深入理解 AI 工作方式的开发者来说，学习技术不仅仅是为了记忆语法，更是为了识别“未知的未知”（unknown unknowns）。如果缺乏技术背景，开发者可能无法判断 AI 生成的代码是否合理，或者无法在 AI 遇到瓶颈时提供有效的指导。

作者强调，学习技术重点不在于掌握具体的语言语法，而在于理解系统约束、权衡取舍以及不同技术方案的底层逻辑。例如，了解不同后端服务的优缺点、视频加密库的工作原理、本地与远程加密的区别等，这些知识能帮助开发者判断 AI 当前的做法是否最优，以及是否有更好的替代方案。

"The goal of learning to be more technical is to know my unknown unknowns... knowing like what are the trade-offs of different backend services... these are all like I think pretty helpful"

通过深入理解这些技术细节，开发者可以更好地与 AI 协作，利用 AI 的头脑风暴能力来学习和探索新的可能性。当开发者能够提出更精准的问题并提供更准确的背景时，AI 就能提供更高质量的建议和解决方案。因此，持续学习技术原理是提升 AI 协作效率、避免被 AI 牵着鼻子走的关键。

学习的本质：痛苦是成长的必经之路

在探讨如何利用 Claude Code 进行高效开发时，对话深入到了教育与学习的核心矛盾。虽然尝试新事物并感到“有趣”是人之常情，但真正的学习过程往往伴随着痛苦和工作量。正如 Kaparthi 所强调的观点，教育应当被视为一种工作，而非单纯的娱乐。这种观点挑战了大众对于“轻松学习”的幻想，指出只有当学习者愿意付出额外的努力时，才能掌握深层技能。

"Education should feel like work more than fun."

这种理念在 AI 辅助编程的场景中尤为关键。许多用户倾向于过度依赖 AI 的输出，即简单地提示 Claude 完成任务，然后直接查看结果，而不去理解背后的逻辑。这种做法虽然高效，但会导致知识积累的缺失。相反，通过生成详细的 HTML 报告并仔细阅读，用户被迫去审视代码结构和执行流程，这种主动的阅读与反思才是提升技能的关键。大多数用户可能不会这样做，但这正是区分普通使用者与精通者的分水岭。

从合格到卓越：主动构建反馈闭环

对于希望从制作“不错的短视频”进阶到“顶级制作质量”的用户来说，被动接受 AI 结果是不够的。必须主动学习视频制作、编辑以及相关的技术概念，并不断自我施压。这种自我驱动的提升过程，不仅是为了速度，更是为了质量与深度的双重突破。

为了实现这一目标，对话中提出了一个具体的工程化建议：为 Claude 添加自定义指令（Custom Instructions），强制要求其在每次任务后生成详细的 HTML 报告。这一策略将 AI 的输出从简单的代码片段转化为可阅读、可分析的结构化文档。通过阅读这些报告，开发者可以清晰地看到 AI 的思考路径和实现细节，从而在潜移默化中内化最佳实践。这种“让 AI 生成报告供我阅读”的模式，是一种高效的逆向学习机制，它迫使开发者从旁观者转变为参与者。

"Make sure you generate HTML reports for everything so I can read that."

未来工作流：从微观管理到宏观协作

随着 Claude Tag 等功能的推出，Anthropic 内部的工作方式发生了根本性转变。未来的协作模式将不再是对 AI 进行微观管理（Micromanagement），而是将其视为一位能力极强的员工。在这种模式下，开发者只需通过 Slack 等工具将任务指派给 AI，然后等待结果，或者在需要时进行迭代式的对话与协作。

这种转变意味着开发者需要建立更高的信任机制。正如对话中所比喻的，你不会去微观管理一位优秀的同事，而是通过明确的指令和后续的沟通来确保任务完成。甚至有人开玩笑说，未来的工作流可能像是一个机器人坐在旁边，随时准备回答问题。这种人机协作的新范式，要求开发者从“执行者”转变为“架构师”和“审核者”，重点关注系统的设计、逻辑的验证以及最终结果的评估，而非每一行代码的编写。这种角色的转换，是适应 AI 时代开发效率提升的必由之路。

"If you have a really capable employee you're not going to like micromanage them."

高光时刻：核心观点摘录

  • "Education should feel like work more than fun."
  • "Make sure you generate HTML reports for everything so I can read that."
  • "If you have a really capable employee you're not going to like micromanage them."