别再打磨完美提示词：把要改的地方展示给 Loom 看

问题一眼就能看出来。原型里的按钮位于表单下方，应用里的按钮却在旁边，而手机上的错误消息又把两者都挤出了视野。要把这些解释得足够清楚，让 AI 编码智能体理解，可能比直接展示给另一个人看花费更久。

2026 年 10 月 22 日，Atlassian 介绍了一组 Loom 更新，其中包括 Record for agent。这种录制模式，可以将带讲解的屏幕演示转为 AI 智能体指令。Loom 是用来异步向同事展示工作情况的视频工具，现在正把同一种习惯扩展到能够执行下一项任务的软件。支持文档将该功能列为面向 Business + AI 与 Enterprise 套餐的公开测试版，录制上限为五分钟。公告；当前要求。

值得关注的进展，不是智能体能够接收视频，而是熟悉的录制流程，现在会生成一份可以检查、编辑并交给智能体的任务说明。这让交接质量成为一个实际问题，而不再是比谁的提示词写得最长。

用于识别产品的 Loom 官方标志。这是品牌标志，并非 Record for agent 的截图。标志：Loom / Atlassian；商标使用政策。

录制能够带上文字描述遗漏的部分

有用的缺陷报告，需要的不只是“表单坏了”这句话。它需要起始状态、引发问题的操作、预期结果，以及实际看到的结果。当这些细节散落在独立截图、复制的 URL 和聊天消息里时，修复之前总得有人重新拼出它们之间的关系。

Loom 文档中的流程，将口头指令与屏幕关键帧、交互事件和访问链接结合起来。Chrome 扩展还可以收集控制台消息，以及网络请求或响应的元数据。桌面版本提供选择和绘图工具，让注意力集中到相关屏幕区域。这些是生成任务说明的输入，并不是建议修复一定有效的证据。捕获详情。

我们认为，这改变了最有用的沟通单元。截图展示状态，句子描述意图，而简短演示能够解释，一个状态应该如何变成另一个。生成的任务说明，是这段解释与可执行任务之间的桥梁。

不妨把录制看成一包上下文。包里应包含所需变更的一切必要信息，除此之外尽量少带。五分钟限制或许能促成这种自律：展示一个问题，解释其后果，并指出清晰的完成标准。

原创交接流程解释图。审查任务说明与智能体执行工作，是两个独立步骤。

预期行为可见时，设计反馈更容易表达

设想团队正在调整结账界面。在一个示例演示中，设计师可以打开已批准版式，展示当前应用，并指出三项差异：窄视口下配送选项消失，总价更新过迟，确认消息的重点错误。价值来自两个界面之间的关系，而不仅是它们的外观。

审查生成提示词的人，应把每个观察转为行为描述。一旦智能体不再看着同一个瞬间，“把这个移一下”就变得含糊。“窄视口下更改配送选项后，保持订单总价可见”，则为实施者提供了可验证的结果。

当变更跨越设计文件和运行页面时，这尤其有用。Loom 支持文档中的示例，描述了在 Figma 与网站之间切换，同时讲解 UI 变化。功能可以帮助捕获可见参考，但决定哪个参考才是权威依据，仍然是团队的工作。精美原型也可能遗漏加载、错误和权限状态。受支持的工作流程。

因此，还应补充一句话，说明什么必须始终成立。在结账示例中，可能是总价必须与所选配送方式一致，或键盘焦点必须留在已修改字段上。这些约束往往不在视觉稿中，却比边框的位置更重要。

同一种方法也适用于产品文案。展示句子所在的真实场景，解释谁会读，以及它应帮助读者作出什么决定。录下引导流程，可以传达一处令人困惑的衔接，而独立文字片段可能掩盖这种问题。

缺陷报告，需要可复现的起点与可观察的终点

第二个有用场景，是反复出现的客服问题。设想客户可以在桌面上传文档，却在小屏幕上看到空白进度指示器。简短录制可以展示文件类型、所选操作、状态过渡，以及反馈消失的位置。

生成的任务仍需完成定义。“修复上传”并不能告诉智能体，问题究竟是文件被拒绝、网络响应缺失，还是 UI 未显示已经成功的结果。更有用的任务说明，会把观察到的症状与怀疑的原因分开。

我们会让最初任务保持狭窄：复现反馈缺失，找出责任层，并提出包含回归检查的变更。如果智能体随后发现服务端错误，这项发现可以依据证据扩大调查。但不应悄悄把一项布局投诉，变成对整个上传系统的全面重写。

对于不习惯阅读日志的人，这有一个实际优势：他们不必先诊断，就能展示出错过程。工程师或智能体可以利用捕获的上下文调查，而原始观察仍然可供修复后比较。

但这不意味着录制可以替代测试用例。两者目的不同。录制保留某个人遇到的情况，测试描述软件必须持续满足的行为。成功的流程，会把前者转成适当形式的后者。

复制提示词与创建 Jira 任务，是不同入口

Loom 的公开测试版可以从 Chrome 扩展或 2.0 及以上桌面应用中使用。文档也区分了基础提示词流程与 Jira 工作项创建，后者需要 Atlassian 管理的账户和有效 Jira 订阅。对于不想重组项目管理、只想尝试交接的小团队，这一区别很重要。可用范围与设置。

最简单的试用，是在已经熟悉的项目中选择一项低影响任务：

1. 打开相关设计、公开测试页或开发环境，准备一个能够解释清楚的起始状态。
2. 在受支持的 Loom 录制器中选择 Record for agent，一边展示相关交互，一边描述一项变更。
3. 在五分钟限制之前停止，并从头到尾阅读生成的行动计划。
4. 纠正含糊引用，移除无关材料，并加入具体的验收条件。
5. 将 Markdown 提示词复制到所选智能体中，或使用账户支持的交接或 Jira 流程。
6. 接受变更之前，对照原始场景审查智能体结果。

这套步骤让首次实验容易理解，也提供了清晰的判断方法：比较准备一项明确任务所需的时间，以及它引发了多少澄清问题。

智能体完成得快还不够。如果同事无法解释改了什么，或为何它解决了原始观察，交接就仍需改进。最有价值的收获，是减少重新拼凑上下文，而不是减少审查。

上下文更丰富，也意味着分享决定更要谨慎明确

额外的技术上下文之所以有价值，是因为屏幕本身未必能解释发生了什么。失败请求、意外重定向或控制台错误，可能指向与可见症状不同的原因。同样的细节，也可能包含你不想发送到另一工具的信息。

录制前，使用相关测试页面，并让任务范围保持明确。录制后，检查生成说明中的账户专属 URL、客户标识，以及不必要的日志内容。文档列出的捕获数据清单，意味着这项检查应该具体落实，而不是把录制当成普通图片附件。

重点是保留解决问题所需的信息。如果请求标识能帮助同事找到获授权的服务端跟踪，它就可能有用。完整的无关 URL 清单，或录制时碰巧弹出的个人通知，对 UI 任务几乎没有价值。

这些是编辑层面的审查问题，并非额外的产品权限，也不是承诺每项捕获细节都会出现在每个生成任务中。目的在于帮助团队决定，实际发送的任务说明中应该包含什么。

有用的审查，会检查智能体可以修改什么、会收到哪些信息，以及如何评判结果。

第一项有用指标，是有多少解释被保留下来

这项功能至少可以通过三种方式节省工作。设计师无需写冗长描述，就能传达视觉差异；客服专员可以趁记忆清楚时保留操作过程；开发者可以给智能体一个参考更明确、预期结果更具体的任务。

每种用途都有不同的失败方式。设计反馈可能遗漏正常路径之外的行为；客服演示可能依赖其他人无法复现的账户状态；开发者的录制可能塞入太多细节，以至真正请求难以识别。

首次评估时，挑选几个熟悉的任务，保持智能体和仓库不变。记录生成说明需要多少编辑，有多经常需要人澄清，以及最终变更是否满足所述条件。这些指标，比孤立展示一个移动光标，更能说明沟通质量。

也值得区分输出质量与任务难度。简单文案修改，用几乎任何说明都可能成功。更有启发的试用，是上下文重要的小任务：加载状态、窄屏布局，或两个工具之间的过渡。任务仍然应当可逆，而且方便负责人审查。

Loom 很适合把这种习惯带给更多人，因为大家已经在用录制向别人解释工作。机会在于把这种清晰带进智能体流程；风险则是以为输入更丰富，就不再需要说明希望智能体实现什么。

更好的任务说明，仍然让另一个人读得懂

Record for agent 作了一个合理判断：展示，可以比逐像素描述更高效地成为起点。最理想的结果，是让智能体和同事都更容易理解任务，并让原始观察与获接受变更之间的联系清晰可见。

发送下一段录制之前，问一个问题：没有看过你录制过程的人，能否仍然解释成功是什么样子？如果可以，你就有了有用的任务说明；如果不行，下一项改进应该先发生在指令里，再发生在代码里。

来源

• Atlassian：在 AI 时代展示你的真实意图，2026 年 10 月 22 日。
• Loom：为 AI 智能体录制，可用范围、捕获与工作流程文档，于 2026 年 10 月 26 日查阅。

把来源与你审查过的笔记放在一起

对于你自己获授权的录音，Telli.sh 提供独立空间，将来源材料与审查过的笔记一起保留。从音频笔记开始。