我如何使用 Agent 编程

David Crawshaw 分享了他如何将编程经验适应到与能够对话的计算机世界中，这是他关于自我教育系列的第二部分。David 首先定义了“agent”一词在 LLM（大型语言模型）背景下的含义：一个 agent 是一个包含 LLM 调用的 for 循环，能够执行命令并查看输出，而无需人工干预。通过这种方式，agent 成为一种反馈驱动的 LLM，能够显著提升编程能力。

David 通过“白板编程”的类比说明了 LLM 在没有外部工具支持时的局限性。例如，在白板上编写代码时，程序员需要依赖记忆来处理复杂的编码任务，而没有编译器反馈、文档查询等辅助手段。类似地，agentless LLM 编写代码时也面临类似挑战。然而，当 LLM 获得更多工具支持时，其表现会大幅提升。例如，agent 可以调用编译器查看错误并修复、使用 grep 和 cat 查看项目文件、修改文件并运行测试等。这些工具使得 agent 能够更好地处理 API 调用、减少语法错误、优化依赖管理以及生成测试代码。

David 还提到，agent 的缺点在于时间成本。一个简单的请求可能会引发大量中间步骤和工具调用，导致整个过程耗时数分钟。此外，目前使用 agent 进行编程的成本较高，但随着硬件性能的提升，这一问题有望得到解决。

David 通过两个实际案例展示了 agent 的强大功能。第一个案例是实现 GitHub App 认证。agent 在实现过程中表现出色，但在安全性方面存在漏洞，允许未经授权的用户访问某些仓库。经过修复后，agent 还解决了性能问题，优化了代码。第二个案例是处理 SQL 数据库中 JSON 数据的约定。agent 在处理这种特殊风格的 SQL 时遇到了困难，但通过在 SQL 模式文件中添加描述性注释，agent 的行为得到了显著改善。

David 进一步探讨了 agent 在编程中的价值，尤其是在维护现有产品方面。尽管有人认为代码生成只是编程成本的一小部分，但 agent 通过其工具集能够读取和修改代码，甚至可以删除代码，从而推动项目的变更。尽管 agent 当前可能还不足以处理大型项目，但其发展方向是积极的。

David 还讨论了 agent 的出现背景，指出其背后的关键在于模型训练过程的优化。2023 年的 LLM 无法有效驱动 agent，而 2025 年的模型已经针对这一功能进行了优化。目前，agent 的使用主要集中在 IDE 或开发机器上的本地仓库中，但这种方式存在安全风险和效率问题。为了解决这些问题，David Crawshaw 正在探索使用容器技术来运行 agent，从而实现并行化操作并提高效率。

David Crawshaw 提出了关于 IDE 在 agent 环境下的未来形态的思考。例如，是否可以通过容器化的方式直接从 GitHub 获取代码并生成分支或拉取请求，而无需传统 IDE 的介入。同时，David Crawshaw 强调了在与 LLM 技术相关的学习和实验过程中保持好奇心和谦逊的重要性，因为这一领域的变化迅速，许多现有的编程规范和工具都需要重新审视和调整。

#AI #Agents #实践

https://crawshaw.io/blog/programming-with-agents

我制作了一架 3D 打印的垂直起降无人机，可以飞行 130 英里

Tsung Xu 分享了他制作的一款 3D 打印的 VTOL（垂直起降）无人机，该无人机单次充电可飞行 3 小时，飞行里程可达 130 英里，这使其成为全球续航里程和耐力最长的 3D 打印 VTOL 无人机之一。Tsung Xu 表示，这是他到目前为止最自豪的项目，甚至得到了 Reid Hoffman 的高度评价，被比作是像莱特兄弟开创动力飞行一样的 “超级代理行动”。

#3D #无人机 #创造

https://www.tsungxu.com/p/i-made-a-3d-printed-vtol-that-can

# Levix 空间站 Weekly #13

#周报

https://levix.notion.site/Levix-Weekly-13-213383a71284801f9119d7ead48210b4

我阅读了 Cloudflare 的所有 Claude 提交

Max Mitchell 分享了 Cloudflare 使用 Claude 生成代码的详细过程。Cloudflare 的 CTO Chris 提到了他们开源的 OAuth 2.1 库，该库几乎完全由 Claude 编写。Cloudflare 团队记录了整个创作过程，每个提示、每次迭代以及每次人工干预都被保留在 Git 提交信息中，形成了一种类似人类与 AI 合作的考古记录。

Cloudflare 的首席工程师 Kenton V 起初对 AI 持怀疑态度，但最终被证明是错误的。在两个月内，Claude 生成了几乎所有的代码，形成了一个可用于生产的认证库。Kenton 在每次提交中都包含了生成代码的提示，这使得人们能够追溯整个开发过程。随着开发中对 AI 工具的依赖增加，这种做法将变得越来越重要。有时，原始提示比生成的代码更有价值，尤其是当工程师提出错误假设而模型盲目跟随时。

这种透明度将 Git 历史从变更记录转变为意图记录，创造了一种新的文档形式，连接了人类推理和机器实现。通过对大约 50 次提交的分析，文章揭示了人类与 AI 合作的一些有趣模式。例如，他们通过示例代码块作为初始提示，展示了库将如何被实现者使用。这种方法消除了关于方法签名的歧义，同时揭示了抽象规范常常忽略的实际考虑。此外，有效的提示遵循一致的模式：清楚地说明当前状态、解释为什么需要更改以及明确的前进方向。这种上下文反馈就像纠正同事一样自然。

AI 在某些任务上表现出色，例如生成全面的文档。然而，AI 也有不足之处。例如，Claude 无法正确移动类声明，需要手动修复。此外，AI 在处理重复代码块时也遇到了困难。尽管 AI 生成了超过 95% 的代码，但人工监督在整个过程中仍然至关重要。

如果使用 AI 编码工具，应专注于交付物，将提示作为版本控制的资产，并准备好进行多次提示迭代。同时，不要害怕手动干预，因为有些问题手动解决比通过提示更快。文章还提出了一个想法：将提示视为实际的源代码。想象一下，版本控制系统中提交的是用于生成功能的提示，而不是最终实现。随着模型的不断改进，可以连接最新版本并重新生成整个代码库，从而提升能力。

目前生成的代码仍然需要部署、测试和维护。但这种想法引发了有趣的问题：如果所有业务逻辑都能包含在自我文档化的提示中，我们是否最终会达到一种状态，即提示提交的历史本身成为“应用程序”，直接在模型中运行，从而完全消除中间的代码生成步骤。

这个 OAuth 库不仅仅是一个技术里程碑，而是新兴的创造性动态的证据。在这种动态中，人工智能负责机械实现，而人类提供方向、上下文和判断。尽管在整个过程中有人类的大量参与，但 AI 生成了该库中绝大多数的功能代码。尽管存在局限性，但 AI 编程工具正在不断改进，从每次互动中学习，并在每次迭代中变得更加强大。

#AI #Claude

https://www.maxemitchell.com/writings/i-read-all-of-cloudflares-claude-generated-commits/

GitHub 计费团队如何使用 GitHub Copilot 中的编码代理持续减少技术债务

GitHub Copilot 的编码代理工具为解决技术债务提供了新的思路和方法。技术债务是软件开发中一个长期存在的问题，随着时间推移，快速修复、“临时”解决方案和截止日期妥协会累积成技术债务，就像财务债务一样，拖延越久解决成本越高。优先处理技术债务面临诸多挑战，因为开发团队通常忙于应对紧迫的截止日期和不断涌现的功能需求，技术债务处理工作往往被搁置。

传统的技术债务管理方法，如“园艺周”（专门用于处理技术债务的冲刺阶段）和延长功能开发时间线，效果并不理想。“园艺周”将技术债务视为例外情况而非持续维护的一部分，导致大问题未得到解决，小问题被推迟处理；延长开发时间线则会破坏工程团队与产品团队之间的信任。

GitHub Copilot 的编码代理工具为解决技术债务提供了新的思路。通过将技术债务任务分配给编码代理，开发人员可以在专注于新功能和架构变更的同时，让代理处理技术债务，无需中断正常的开发流程或影响功能交付时间表。例如，编码代理可以增加代码测试覆盖范围、替换依赖项、标准化代码库中的模式、优化前端加载模式以及识别和删除死代码。这些任务都是实际开发中常见的技术债务问题，而编码代理能够高效地完成这些任务，大大减少了处理技术债务所需的时间。

GitHub Copilot 的编码代理工具并非要取代人类工程师，而是增强工程师的能力。代理可以处理重复、耗时的代码重构、更新依赖项和标准化模式等工作，而人类工程师则可以专注于架构决策、功能创新和解决复杂业务问题。这种分工使得软件能够保持更健康的状态，团队能够更快地交付产品，工程师也能将时间花在更有价值的工作上。

尽管 AI 代理在处理定义明确、重复性的任务上表现出色，但在涉及重大架构决策或复杂业务逻辑变更时，人类的判断仍然不可替代。开发人员需要仔细规划和权衡，确保每个提示都经过深思熟虑，每个代码库的变更都经过彻底审查。AI 代理能够带来速度和一致性，而人类工程师则提供战略思维，决定优先处理哪些技术债务，理解不同方法的业务影响，并识别可能引发更大问题的“快速修复”。

为了更好地利用 GitHub Copilot 的编码代理，开发人员可以采取以下建议：为代码库编写清晰的 Copilot 指令，以获得更好的使用体验；将任务分解为可管理的小块，以便更高效地审查变更；掌握有效的提示技巧，明确传达需求、上下文、约束条件和编码标准；始终彻底审查代码，确保质量。这些方法能够帮助开发人员更好地与 AI 代理协作，提高工作效率。

软件工程正处于一个关键时期，技术债务一直是生产力的隐形杀手。AI 编码代理为解决这一问题提供了新的机会。学会与 AI 代理有效协作的工程师将获得巨大优势，他们能够维护复杂的代码库，处理其他人回避的技术债务，甚至可能消除昂贵且耗时的系统重写需求。然而，这一转变需要有意识的努力，开发人员需要尝试这些工具，了解它们的优势和局限性，并将其整合到工作流程中。

#Github #Copilot #AI #实践

https://github.blog/ai-and-ml/github-copilot/how-the-github-billing-team-uses-the-coding-agent-in-github-copilot-to-continuously-burn-down-technical-debt/

单点登录（SSO）无法保障每一个身份的安全

单点登录（SSO）解决方案旨在管理并保障对 SaaS 应用程序的访问。通过与企业的身份提供商（IdP）集成，SSO 允许团队通过一次登录验证多个应用程序的身份。减少访问点和员工凭据数量，SSO 能够缩小企业的攻击面，并且便于 IT 和安全团队通过 IdP 管理应用程序的访问权限。然而，SSO 并不能保障企业 SaaS 应用程序的所有访问安全。如今的员工随时随地工作，使用自己的 SaaS 和生成式 AI 应用程序，并且与 AI 代理的互动日益频繁。这种自由推动了生产力的飞跃，但也扩大了访问信任差距（Access - Trust Gap）。访问信任差距指的是未经联合的身份、设备、应用程序和 AI 驱动工具在缺乏适当治理控制的情况下访问公司数据所带来的安全风险。

即使采用 SSO 的公司，仍然在与不受信任的访问形式和不断扩大的访问信任差距作斗争。SSO 解决方案在访问管理中仍有一定作用，但仅靠它无法充分应对现代劳文章探讨了影响 SSO 能够保障特定公司用户和身份安全的各种复杂因素，并探索可以补充或替代 SSO 的解决方案，以保障 SSO 未能看到和管理的身份安全。

#SSO #安全

https://blog.1password.com/sso-cant-secure-every-identity/

掌握 Shopify 性能报告

Dan Gayle 介绍了 Shopify 为平台上所有店铺推出的新网页性能报告功能，该功能为商家提供了前所未有的真实用户指标（RUM）访问权限，帮助识别和修复性能瓶颈。

Shopify 提供了 6 个自定义仪表板，展示了新报告的强大功能，商家可以将其保存并用于自己的店铺。这些仪表板可以通过 Shopify 后台的 “Analytics > Reports” 或 “Online Store > Themes” 页面访问，顶部横幅也可进入，同时提供了全面的文档支持。

高级概述仪表板提供了关键页面类型性能的高级概览，允许商家监控核心指标以评估网站的整体健康状况。建议每天检查一次，如果发现指标不是绿色，则需要使用仪表板 2 进一步深入分析。其 ShopifyQL 查询代码可用于生成报告，显示过去 30 天内不同设备类型和页面类型的加载百分比、LCP、CLS 和 INP 等指标。

如果在高级概述仪表板中发现问题，则需要通过此仪表板深入分析 CWV 分数随时间的变化，以查找可能对性能产生负面影响的变化。报告会显示过去 30 天内不同页面类型和设备类型的 LCP、CLS 和 INP 指标，并以时间序列的形式呈现。通过悬停在图表上，可以查看特定时间点的详细信息。此外，事件注释功能会在添加新应用或更新主题时在图表上添加注释，如果注释与图表中的大幅变化相对应，则很可能是引入了导致问题的因素。

LCP 指标与页面上的某个元素（目标）相关，通常是页面上最大的图像，但也可能包括大文本区域和 cookie 同意弹窗。新性能仪表板可以显示目标元素，这为识别潜在问题提供了新的强大功能。该仪表板会生成一个表格，列出需要改进的 LCP 元素的 CSS 选择器（LCP > 2.5s），并按页面类型、设备类型和页面视图百分比排序。通过识别这些元素，商家可以进一步分析如何更快地加载它们，问题可能出在前端（如延迟加载主图像、客户端渲染等）或后端（如服务器响应时间慢，即 TTFB）。

在诊断慢速 LCP 分数时，了解问题是由于服务器响应慢（TTFB）、渲染阻塞资源（FCP）还是 LCP 目标是延迟加载的资产，是非常有帮助的。该仪表板可以将这些因素分解，以便更清晰地看到问题所在。报告会显示过去 30 天内不同页面类型和设备类型的 TTFB、FCP 和 LCP 指标，并以时间序列的形式呈现。通过切换顶部右侧的指标，可以查看每个指标的性能表现。例如，如果 TTFB 比较平稳，但 FCP 在 6 月 2 日左右出现大幅上升，且注释显示主题更新了 192 次，则可能是有人在编辑主题时引入了渲染阻塞脚本或其他阻止屏幕渲染的内容。

CLS 测量页面上意外移动的量，通过测量元素移动的距离来实现。目标选择器只能帮助识别被移动的项目，而不是导致移动的元素。不过，一旦知道哪个项目发生了移动，通常可以轻松地找出相邻的有问题元素（通常是其上方的元素）。该仪表板会生成一个表格，列出过去 30 天内 CLS 值大于 0.1 的页面类型、设备类型和目标选择器，并按页面视图百分比排序。商家可以在浏览器中查看可能导致移动的原因，例如通过在 Chrome DevTools 中限制连接速度来减慢页面加载速度，从而更容易识别问题部分。

INP 测量浏览器对点击的视觉响应时间，因此 INP 目标是被点击项的 CSS 选择器。一旦知道了这一点，就更容易识别导致响应缓慢的 JavaScript 代码。该仪表板会生成一个表格，列出过去 30 天内 INP 值大于 200 毫秒的页面类型、设备类型和目标选择器，并按页面视图百分比排序。尽管有了点击目标，但查找和修复 INP 问题仍然是一个具有挑战性的任务。Google 在 web.dev 上的文档非常有用，Shopify 的网络性能团队也会参考这些文档。

#性能

https://performance.shopify.com/blogs/blog/mastering-web-performance-reports

从 Skeuomorphic 到 Liquid Glass：苹果对 "后触控时代 "的战略押注

在 2025 年全球的开发者大会（WWDC）上，苹果公司推出了 Liquid Glass（液态玻璃）界面设计，这不仅仅是一次视觉上的更新，更是苹果对未来十年人机交互方式的战略性布局。苹果通过 Liquid Glass 为用户营造一种屏幕不再重要的未来世界，其灵感来源于 visionOS，即苹果的增强现实操作系统。在增强现实中，界面元素需要与物理世界共存，因此必须是半透明、分层且具有环境感知能力的。苹果通过在传统屏幕上率先引入这些概念，让用户在使用 AR 眼镜时，界面式范不会显得陌生。

此次设计转变还充分发挥了苹果垂直整合的核心战略优势。Liquid Glass 不仅是视觉上的装饰，更是硬件与软件紧密耦合的技术展示。实时模糊、动态透明效果和上下文感知照明等功能需要强大的 GPU 性能和优化的渲染管线才能实现。这种设计使得苹果设备在运行 Liquid Glass 时能够流畅运行，而竞争对手的设备可能会出现卡顿。这种设计语言的统一性也贯穿于苹果的所有平台，从 Apple TV 到 Vision Pro，开发者可以在整个生态系统中实现一致的视觉语言，用户在切换设备时也能保持认知上的连贯性。

尽管科技媒体对苹果在 WWDC 2025 上相对低调的人工智能故事大加关注，但苹果实际上正在采取一种更为微妙的策略。苹果没有参与当前大语言模型的竞争，而是专注于其擅长的领域：通过设计和整合创造引人入胜的用户体验。苹果的历史表明，他们很少是第一个进入市场的公司，但往往是第一个以精致、整合的方式进入市场的公司。苹果在人工智能领域似乎也在采取类似的策略，通过 Liquid Glass 设计语言为更具情境化的人工智能互动创造了机会。

然而，任何设计决策都涉及权衡。Liquid Glass 早期的反馈引发了关于可读性和认知负荷的合理担忧。半透明界面可能会降低对比度，使文本更难阅读。不过，苹果过去曾成功应对过这些挑战，并且已经在之前的 iOS 版本中提供了诸如“降低透明度”和“提高对比度”等设置。苹果有能力从大胆的愿景出发，并根据反馈进行调整，尤其是当这一愿景服务于更大的战略目标时。

Liquid Glass 的推出还创造了设计语言上的网络效应。当苹果改变方向时，它不仅影响苹果自身，还会影响整个行业。为 iOS 开发的应用程序开发者将采用新的设计模式，其他公司的设计师也会创造类似的美学风格以保持与时俱进。这种行业影响力进一步增强了苹果的战略优势，即使非苹果设备的用户也会接触到受苹果影响的设计模式，使得未来转向苹果产品时感觉更加自然。

苹果引入 Liquid Glass 揭示了其对未来计算的看法：我们正朝着融合数字与物理现实的环境化、空间化界面发展。触摸仍将很重要，但它不会永远是主要的交互模式。语音、手势和情境感知将发挥更大的作用。通过现在建立视觉和概念框架，苹果正在为用户和开发者准备这一转变。当轻量级 AR 眼镜最终成为主流时，界面范式将已经变得熟悉。

从历史来看，苹果的设计变革总是会面临初步的抵制。问题不在于 Liquid Glass 是否会在审美上取得成功，而在于苹果是否能够执行它所代表的更广泛愿景：从以触摸为主向以空间为主计算的无缝过渡，并以苹果的整合生态系统为中心。如果以历史为鉴，未来五年内我们可能都会使用类似玻璃的界面，甚至难以想象没有它们的生活会是什么样子。

#用户体验 #设计 #Apple

https://omc345.substack.com/p/from-skeuomorphic-to-liquid-glass

不要盲目构建多智能体

Walden 探讨了在构建基于大型语言模型（LLM）的智能体时，多智能体架构存在的问题，并提出了一些构建智能体的原则。

目前构建智能体的框架令人失望，而 Walden 希望通过分享自己团队在实践中积累的经验，帮助读者避免一些常见的错误。React 框架之所以成功，是因为它不仅仅是一个代码编写工具，更是一种开发哲学。在当前的 LLM 时代，构建智能体更像是在摸索如何将不同的技术组合在一起，以提供良好的用户体验。目前还没有一种标准的智能体构建方法，而一些像 OpenAI 的 Swarm 和微软的 AutoGen 这样的库，推动了多智能体架构的概念，但 Walden 认为这是错误的方向。

Walden 提出了构建长运行智能体的理论，强调可靠性是核心，而上下文工程是实现可靠性的关键。上下文工程不仅仅是将任务以理想格式写出来，而是要在动态系统中自动完成这一过程。Walden 以构建 Flappy Bird 克隆版为例，说明了多智能体架构的脆弱性。当任务被分解为多个子任务并分配给不同的子智能体时，很容易出现误解和不一致的情况。因此，Walden 提出了两个原则：原则 1 是共享上下文，不仅要共享单独的消息，还要共享完整的智能体轨迹；原则 2 是行动隐含着决策，而冲突的决策会导致不良结果。Walden 认为，这两个原则至关重要，应该默认排除不符合这些原则的智能体架构。

Walden 还讨论了如何应用这些原则。如果是一个智能体构建者，需要确保智能体的每个行动都受到系统中其他部分所做决策的上下文的指导。虽然理想情况下每个行动都能看到其他所有内容，但由于上下文窗口有限和实际的权衡，可能需要决定愿意承担多大的复杂性以实现所需的可靠性。Walden 还提到了一些现实世界中的例子，如 Claude Code 的子智能体和编辑应用模型，说明了在构建智能体时如何避免冲突决策。

尽管多智能体架构在理论上可以提高系统的并行性和效率，但在 2025 年，多智能体协作的系统仍然非常脆弱。决策过于分散，上下文无法在智能体之间充分共享。Walden 认为，随着单线程智能体与人类沟通能力的提高，跨智能体上下文传递问题可能会得到解决。

#AI #Agents #思考

https://cognition.ai/blog/dont-build-multi-agents#principles-of-context-engineering

温柔的奇点

Sam Altman 探讨了人工智能与人类社会的未来发展。他认为人类已经跨越了奇点的事件视界，人工智能的起飞已经开始。尽管目前我们尚未看到机器人在街头行走，人类也仍面临疾病和太空探索的难题，但人工智能已经在许多方面展现出超越人类的智能，并能够显著提升人类的工作效率。以 GPT-4 为代表的系统是来之不易的科学成果，未来将带来深远的影响。

人工智能将通过加速科学进步和提高生产力为世界带来巨大收益。科学进步是整体进步的最大驱动力，而人工智能在推动科学发现和创新方面具有巨大潜力。例如，ChatGPT 已经被数亿人每天用于各种重要任务，其影响力巨大。2025 年出现了能够进行真正认知工作的智能代理，这将彻底改变编程等工作。预计 2026 年将出现能够提出新见解的系统，2027 年可能会出现能够在现实世界中执行任务的机器人。

到 2030 年，人们将能够更高效地完成更多工作，这将是一个显著的变化。尽管如此，人们的生活在最重要的方面可能不会发生巨大变化，人们仍将热爱家人、表达创造力、玩游戏和享受自然。然而，在其他非常重要的方面，2030 年代将与以往大不相同。人类将拥有丰富的智力和能源，这两个因素一直是人类进步的限制因素，而有了它们，人类将能够实现更多目标。

人工智能的发展将使数据处理和智能服务的成本逐渐降低，接近电力成本。随着数据中心生产的自动化，智能成本将进一步降低。技术进步的速度将继续加快，人类将有能力适应这些变化。尽管一些工作岗位可能会消失，但世界将变得更加富有，从而能够探索新的政策理念。

Sam Altman 强调，人类需要解决人工智能的安全问题，确保其与人类的长期目标一致。同时，超级智能应该便宜、广泛可用且不被少数人、公司或国家垄断。社会需要通过集体智慧来适应和利用这项技术，以实现最大利益和最小风险。OpenAI 是一家超级智能研究公司，其目标是为世界打造一个高度个性化且易于使用的智能系统。未来，人工智能将变得如此便宜，以至于人们几乎可以免费使用。尽管这听起来有些疯狂，但如果回顾 2020 年人们对 2025 年的预测，如今的成就可能更令人难以置信。

#AI #OpenAI #思考

https://blog.samaltman.com/the-gentle-singularity

AI 在用户界面中的最佳位置在哪里？

随着大型语言模型（LLMs）和人工智能代理的兴起，熟悉的用户界面模式如聊天机器人得到了升级，但新的界面布局正在逐渐形成。真正的机会在于将人工智能更深入地嵌入复杂、面向任务的界面中。从右侧面板助手、无限画布到语义电子表格，这些空间选择不仅仅是设计决策，它们从根本上塑造了用户发现、信任和与人工智能互动的方式。

Sharang 探讨了七种新兴的用户界面布局以及人工智能代理的感知角色，分析了每种布局如何通过可发现性、用户互动模式和代理能力影响用户行为和期望。

第一种是客户支持聊天机器人，通常位于页面右下角，易于发现且不具侵入性，适用于轻量级、非侵入性的支持场景。现代人工智能聊天机器人能够保持上下文记忆、个性化响应，并自动化后端操作，但不适合主动式、多步骤推理或创造性协作工作流。

第二种是内联覆盖提示，例如在 Notion 和 Grammarly AI 中，这些提示作为交互式、上下文敏感的建议或操作，直接出现在文本或内容区域中，增强用户生产力和编辑效率。内联提示通过用户操作触发，用户可以即时与建议互动，接受、编辑、撤销或重新生成内容。这种代理被视为“精准助手”，提供微观层面的支持，但不适用于开放式创造性探索或需要广泛上下文推理的任务。

第三种是无限画布上的创意合作者，无限画布工具为用户提供了几乎无限的二维工作空间，支持视觉思维和探索性工作流。AI 能力通过上下文触发，用户可以在不打断创意流程的情况下，通过局部、异步的提示输入调用模型。AI 在这里充当“创意合作者”，响应空间上下文，支持创意生成、内容优化、布局建议和视觉增强，但不适合需要严格版本控制或全局上下文感知的场景。

第四种是中心舞台的通用助手，这种界面模型将 AI 置于用户体验的中心，通常是一个全宽、垂直堆叠的面板，以文本输入和对话线程为核心。它支持开放式、自由形式的交互风格，用户通过自然语言发起互动，通过后续问题、澄清或提示工程迭代优化输出。AI 被视为“通用助手”，能够跨多个领域回答问题、生成内容和执行任务，但不适合结构化、多步骤的工作流。

第五种是左侧面板的战略创意伙伴，AI 助手放置在左侧面板中，作为生成内容、代码或结构化输出的协作引擎。这种布局支持多轮次的共同创作，用户可以在持续的反馈循环中提示、细化和测试输出。AI 被视为“战略伙伴或共同创作者”，通过来回互动帮助用户构思、结构化和演变复杂输出，但不适合轻量级任务或移动界面，且模糊的提示可能导致意外行为。

第六种是右侧面板的深度上下文专家，AI 位于可折叠的右侧面板中，作为按需助手，为沉浸于复杂主要任务的用户提供支持。这种布局允许用户专注于中央画布，同时保持助手的易于发现性和非侵入性。AI 被视为“深度上下文专家”，能够提供针对性、推理驱动的支持，但不适合以 AI 为中心的体验，其微妙的存在可能被新手用户忽视。

第七种是网格界面中的分布式研究代理，传统的电子表格网格正在转变为智能表面，用于查询、研究和语义互动。AI 输入通常从顶部提示或查询字段开始，然后单元格自动填充结构化结果。AI 在这里被描述为“分布式研究代理”，每个单元格都像一个智能代理，共同构成一个智能整体，但这些系统最适合研究、分析或结构化内容编译，需要用户对期望输出的结构有清晰的认识。

LLMs 不仅仅是被查询的工具，而是一种新的计算媒介，我们才刚刚开始理解它。正如过去几十年图形用户界面、网络和移动界面重塑了设计一样，LLMs 要求我们重新思考智能在产品中的存在方式，不仅仅是它说什么，还包括它在哪里、如何被触发以及如何引导用户。空间布局如聊天机器人、侧边栏、语义网格和无限画布不仅仅是审美选择，它们定义了用户对 AI 角色的心理模型，其位置塑造了可用性、能力和信任。在这个新时代，设计 AI 的呈现方式将与设计其功能一样重要。

#AI #用户体验

https://uxdesign.cc/where-should-ai-sit-in-your-ui-1710a258390e