关于本文
本文采用利用生成式 AI 的自动生成流程创建。我们于 2026 年 11 月 2 日重新核实了 Microsoft 官方资料，并制作了可使用虚构数据进行测试的提示词及确认步骤。未在 Copilot 界面上实际执行。验证状态：📘 已确认官方信息·未经验证提示词执行
首先通过 3 个步骤进行尝试
打开可在工作账号中使用的 Copilot Chat（若因订阅或组织策略无法使用，则在此停止）。
粘贴下方虚构的归还备忘录和提示词，让其生成缺失信息的表格。
对照最初的 4 行，检查是否指出了“列表位置”、“状态判断标准”以及“异常时的联系人”尚未确定。
操作后请查看此处：检查 AI 是否没有凭空捏造负责人姓名、权限和保存路径，而是区分了需要确认的项目与更新前必须停止的条件。该结果为预期值，尚未在 Copilot 真实设备上进行验证。
支持的环境、功能与限制（官方确认时间：2026年11月2日）
| 项目 | 本示例的对象与范围 |
|---|---|
| 产品与入口 | 面向工作场所的 Microsoft Copilot Chat（原名 Microsoft 365 Copilot Chat）。网页版假设使用常规聊天 |
| 账号与订阅 | 经组织允许使用的工作账号。请确认根据个人订阅和管理员设置是否可用。个人版 Copilot 不在本文示例范围内 |
| 追加契约与计费 | 本示例不使用Office应用内的附加功能或按量付费的智能体。请勿将其解释为可使用需要追加契约的功能 |
| 输入与保存位置 | 直接粘贴虚拟文本。不连接本地路径、OneDrive、SharePoint或收件箱 |
| 尝试的操作 | 参考、整理、比较所输入的文章以及起草文案。内容由人工与原文进行核对 |
| 本示例不包含的内容 | 文件搜索、直接编辑与移动或删除文档、发送邮件、录入业务系统 |
| 上限与提供状态 | 不以预览功能为前提。输入长度、次数、地区、界面差异的数值以及实机版本尚未确认。长文本输入应分段进行，是否可用需在界面上进行确认 |
| 信息管理 | 初期仅使用虚拟数据。若要扩展至业务信息，需确认所在组织的许可及信息分类。切勿仅依赖提示词来作为访问控制或停止网页搜索的保证 |
交接备忘录中往往会残留一些熟悉业务的人才能看懂的省略内容。即使写着“确认一览表并进行处理”，也可能会让人搞不清究竟是哪张一览表、要确认什么、如果出现异常应该在哪个环节停下。在Copilot Chat中，我们不是让它擅自补全步骤，而是让它找出初次接手的人可能会卡壳的地方。
检查虚拟的借出设备归还步骤
本示例是不包含系统设置更改在内的虚拟事务步骤。将文本粘贴到聊天窗口中，仅对记载不足之处进行检查。不进行屏幕操作或数据更新。在扩展到实际步骤之前，您可以先确认意见指出与内容创作之间的区别。
あなたはこの手順を初めて読む担当者です。 下の架空メモを、記載だけで実施できるか点検してください。 書かれていない操作、連絡先、権限、保存先は作らないでください。 列：手順番号／不足情報／なぜ必要か／管理者へ聞く具体的な質問。 その後に、元の記載で確定している手順だけを番号付きで整理してください。 異常時の判断が不明な箇所は、実行せず確認する停止候補として示してください。 1. 返却されたタブレットの番号を一覧で確認する。 2. 状態を確認し、問題がなければ返却済みにする。 3. 問題があったら担当へ連絡する。 4. 書類を保存して終了する。
不足之处包括：一览表的位置、状态确认的观察视角、变更为已归还状态的方法、联系的负责人、单据种类及保存位置等。如果让AI用貌似合理的数值去进行补充，文档表面上看起来确实会很完善。但这并不意味着它能成为真正可用的步骤。
修改为可用于咨询的意见指出形式
如果仅一句“需要写得更详细”，管理员也无法判断应该补充什么内容。应将其转化为根据回答能够直接反映到步骤中的问题，例如：“一览表从哪里打开，设备编号要在哪一列进行核对？”
| 观察视角 | 本示例中需确认的内容 |
|---|---|
| 录入 | 在哪里读取设备编号，如果缺失该怎么办 |
| 确认标准 | 以什么标准判断状态良好 |
| 更新 | 修改哪条记录，需要谁的权限 |
| 例外 | 编号不符或损坏时在哪个环节停止 |
| 结束 | 保存什么内容，做到什么程度算作结束 |
信息不足时，应从影响流程安全性的信息开始确认。比起保存文件名的细微格式，优先考虑能够避免将其他设备误判为已归还的核对条件更为重要。切勿直接照搬人工智能的输出顺序作为优先级，而应通过观察出错时的影响来重新排序。
检查交接备忘录并非批判撰写者，而是将知情者脑海中的前提条件以文字形式呈现出来。与其断言“这种写法不够充分”，不如提出“初次经办人需要确认哪些信息才能继续推进”这样的问题，这样更容易收集到必要的内容补充。
将停止条件置于操作之前
在编号不符的情况下将其更改为已归还状态，事后将需要进行修正。如果在更新状态前设置停止条件，则可以在产生错误记录之前进行确认。如果异常情况下的联系方式尚未确定，切勿让人工智能自行决定，而应交还给流程管理者。
停止条件与单纯的注意事项作用不同。仅凭“注意”并不知道是否可以继续操作。采用诸如“如果编号不在一览表中，则不进行更新，并向负责人确认”这种能够明确停止操作和下一步行动的形式才更适合实际业务。不过，联系方式只能填写已经确认过的信息。
在此虚构示例中，重要的一点是人工智能不应凭空创造新的检查方法或检验项目。屏幕划痕、电池余量等虽然是可以考虑的角度，但未必是正式的确认项目。如有必要，应作为“补充候选”单独列出，以便与现行流程区分开来。
补充一处，看看信息不足的情况是否减少
在步骤一中追加“一览表为归还受理表，需确认设备编号列完全一致”，并在新的对话中进行检查。期望产生的变化是，有关一览表名称和核对方法的提问会减少。如果未写明如何打开归还受理表，这一点则会保留。
如果仅仅补充了一句话就显示所有问题均已解决，则说明检查可能比较粗略。初次经办人应实际阅读备忘录，记录在何处停止，并与人工智能的指出结果进行对比。文字层面的检查与现场的试行是两个不同的确认环节。
反过来，也有可能对已经写明的内容反复提问。如果加上“请同时并记作为依据的记载”这一要求，会更容易确认其是否读懂了输入内容。比起提问的数量多寡，更应评估其是否精准命中了尚未解决的前提条件。
保持操作步骤与判断标准的相互分离
即使操作顺序已经理顺，如果合格与否的标准模棱两可，每位经办人的处理方式也会各不相同。将指示在何种状态下可以继续的判断标准，与记录屏幕上应点击哪个按钮的操作步骤分开记载，将更有利于追踪变更时的影响。
例如，即使屏幕上的按钮名称发生变化，确认编号一致的标准有时也不会改变。另一方面，如果出借规则发生变化，即使屏幕保持不变，也需要重新审视判断。除了要求 Copilot 提供单一的完整文案之外，还可以采用让其制作标准与操作对照表的方法。
同时检查步骤的结束条件。如果以“保存文件”结束，则缺少如何确认保存成功以及是否与更新内容一致的环节。明确在宣布结束前需要查看的项目，可以减少将进行到一半的作业错误当作已完成的情况。
用图表确认更新前停止的位置
下图是改进这一虚构步骤时的确认方案。它并非正式的运营步骤，而是用于查看将未确认的分支置于何处。将编号不一致与状态不良区分开来，可以针对各自情况询问所需的联系方式或判断标准。
flowchart TD
A["番号を照合"] --> B{"番号が一致するか"}
B -->|いいえ| C["更新せず管理者へ確認"]
B -->|はい| D{"状態の基準を満たすか"}
D -->|不明・不良| C
D -->|はい| E["確認済み手順で記録を更新"]
E --> F["保存結果と終了条件を確認"]
重要的一点是，能够将图中的分支还原为文字并进行阅读。如果无法弄清继续执行“是”之后的下一步所需的证据，则说明标准有所欠缺。仅凭制作了图表并不能消除这些不足。WordPress 或打印屏幕上的渲染效果在本文稿中尚未确认。
在修订步骤时，应保留修改前的版本，并简短记录添加了哪些内容。同时确认作业人员是否正在使用新版本。即使共享位置存有最新版本，如果继续使用保存在手头的旧备忘录，改进后的标准也将无法传达到实际作业中。
图表的确认不仅针对常规流程，还应涵盖恢复作业的条件。如果在向管理员确认后，不清楚应从哪个步骤返回，可能会导致跳过编号核对而直接进行更新。恢复时是否需要确认相同的备品和相同的受理记录，也需要由管理员作为步骤确定下来。
实际交接中的使用方法
录入的步骤中往往包含内部 URL、账户名、设备信息等。试用时应使用虚构的文案，在进入使用实际文档的阶段时，再确认组织的规则。切勿将登录信息或机密保存地址作为步骤的补充内容粘贴到聊天中。
如果需要屏幕截图，除了对正文进行检查外，还要确认目标版本、拍摄日期以及是否存在个人信息。同样重要的是，不要将 AI 提示的按钮名称或屏幕布局当作真实存在的内容添加至步骤中。检查指出的问题需由管理员结合实体机进行最终确定。
改进后，初次经办人应在小范围内测试仅凭备忘录能推进到何种程度。记录下需要提问的地方、停止操作的地方以及需要还原的地方。比起文章的长度，更应以犹豫不决的地方是否切实减少来进行评估。
交接的完成并不在于说明文是否完善，而在于后来者能否在相同条件下做出判断。可以将 Copilot 用作寻找不足的对手，但不能让其成为决定联系方式、权限和判断标准的的主体。如果是一份能看出应该在何处停止的备忘录，将更容易避免在懵懂无知的情况下推进处理。
官方信息与一手信息
产品的范围和输入方法请参考官方资料。虚构数据、提示词、预期示例以及检查表均为本文的验证方案，并非微软保证的输出示例。
