关于本文
本文是通过利用生成式 AI 的自动化工作流创建的。我们于 2026 年 10 月 20 日查阅了微软官方资料，并制定了可通过虚拟数据进行测试的提示词和确认步骤。未在 Copilot 界面上实际运行。验证状态：📘 已确认官方信息，未验证提示词运行
适用环境、功能与限制事项（官方确认时间：2026年10月20日）
| 项目 | 本示例的对象与范围 |
|---|---|
| 产品与入口 | 面向工作场所的 Microsoft Copilot Chat（原名 Microsoft 365 Copilot Chat）。网页版假定使用普通聊天 |
| 账户与合约 | 经组织授权的工作账户。请确认您的合约和管理员设置是否允许使用。个人版 Copilot 不在本文示例范围内 |
| 附加合约与计费 | 本示例不使用 Office 应用内的附加功能或按量计费的代理。请勿将其理解为能够使用需要额外合约的功能 |
| 输入与保存位置 | 直接粘贴虚拟文本。不连接本地路径、OneDrive、SharePoint 或收件箱 |
| 尝试的操作 | 参考、整理、对比所输入的文章并起草初稿。内容由人工与原文进行核对 |
| 本例不适用 | 文件搜索、直接编辑/移动/删除文档、发送邮件、在业务系统中登记 |
| 上限与提供状态 | 不以预览功能为前提。输入长度、次数、地区、界面差异的数值以及实机构建尚未确认。长输入需分段，是否可用需在界面上确认 |
| 信息管理 | 最初仅使用虚拟数据。如需扩大到业务信息，请确认组织的许可和信息分类。仅凭提示词不能保证访问控制或停止网络搜索 |
原本是为了让周报更易读，但有时连未进展的工作也显得像是完成了。“实施测试”与“通过测试”不同，“联系对方”与“与对方达成一致”也不同。使用 Copilot Chat 整理周报时，在缩短文章之前，先给出不改变状态的条件。
将零散的工作备忘录整理到四个栏目中
以下是虚拟的内部办公用品搜索工具的试做备忘录。不使用实际业务日志或用户信息。将提示词和备忘录一起粘贴到新对话中。不包含自动搜索过去周报或项目文档的操作。
次のメモだけで週報の下書きを作ってください。 区分は「今週の実績」「未完了・課題」「来週の予定」「判断が必要なこと」。 完了・実施・確認・合意を同義にしないでください。 進捗率、効果時間、担当、期限は入力にない値を補わないでください。 各項目の末尾に根拠行を付けてください。 最後に、不足情報を最大3点示してください。 L1：検索画面の試作を作成した。実際の利用者による確認はまだ。 L2：ダミーデータ20件で検索を実行した。2件は表記ゆれで見つからなかった。 L3：表記ゆれ対応の方法を来週比較する予定。 L4：運用担当へ保管場所の確認メールを送った。返事はまだない。 L5：公開日は決めていない。利用者確認の後に相談する。
预期的成果是界面试做、执行搜索、发送确认邮件。不包含用户确认、表述变体处理、保管地点达成一致、决定发布日期。“工具开发完成”、“20条全部搜索成功”等表述比实际情况夸大。
确认成果栏中的动词
周报中的误解有时会体现在动词而非名词上。因为“已确认”容易混淆不同的含义，如提问过、看、过屏幕、获得对方同意等。如果输入仅到发送邮件为止，输出也应停留在发送为止。
| 备忘录状态 | 可使用的表达示例 | 本例中不可用的表达 |
|---|---|---|
| 制作了试做版 | 试做已完成 | 用户验收完成 |
| 执行了搜索 | 在20件中试运行，2件未检测到 | 搜索测试通过 |
| 已发送确认邮件 | 已咨询，等待回复 | 已确定存放地点 |
| 下周进行比较 | 计划进行比较 | 已决定方式 |
尤其是“已”这个词虽然很方便，但需要具体写明是什么事情已经完成了。由于“已测试”无法看出结果，写成“用20个虚拟数据试运行，其中2个未检测到”更有利于做出判断。要留下足够的信息，让读者能够考虑下一步行动。
也不要让系统自动计算进度率。即使五个备忘录中有三个写了“已做”，也不能说完成了六成。因为各项工作的工作量不同，而且还有尚未写出的工序。如果用数字来表示进度，需要事先分别确定计划工序和完成条件后再进行计算。
在多个栏目中使用相同事实的理由
执行搜索属于实际成果，而未检测到的两件属于待解决问题。即使同一个L2出现在两个分类中，也未必是简单的重复。只要将“做了什么”和“剩下什么”区分开来，读者就可以同时掌握试制工作的推进情况和剩余工作。
另一方面，没有必要一字不差地把同一段话载入两次。在成果中保留试行条件，在待办问题中保留未检测到的状态。如果在Copilot中补充说明“可以使用相同的依据，但只需写出各栏目目的所需的部分”，就能传达整理的意图。
还要确认风险和问题的区别。已经发生未检测到属于问题。由于确认使用者延迟而导致公开日期推迟的可能性属于风险候选，但不能将输入信息中没有的影响当作事实添加进来。如果要加入推论，请作为假设或确认事项进行区分。
只修改一处，确认状态是否会发生转移
将L4替换为“运营负责人给予了回复，经协商一致，将共享文件夹A作为存放地点”，并在另一场对话中尝试相同的指令。期望看到的变化是：等待回复的状态解除，存放地点的共识转移到实际成果中。
但是，达成共识与实际转移文件是两码事。新的L4中也没有写明执行了移动操作。如果输出结果变为“已迁移至共享文件夹”，则说明状态向前跨越了一个阶段。确认这种微小的差异，有助于防止长篇周报出现错误的进展认知。
如果通过在对话中追加指令来修改，请引用需要修改的句子并告知“这段记载仅到达成共识为止，不得视为已实施”。如果只说“更准确一点”，则很难界定应该退回到哪个边界。指出出问题的动词，将更容易确认修改结果。
整理成便于读者做出决定的形式
如果是面向管理者的周报，相比细碎的操作，有时更应将停滞的原因和需要判断的事项放在前面。如果是负责人之间的交接，则应详细保留复现条件和剩余工作。在确定事实后指定读者，仅改变相同内容的排列方式，就会变得更容易处理。
不要勉强填满“需要判断的事项”这一栏也很重要。并非这份备忘录一出来就必然需要请求批准。因为公开日期预定在确认使用者后进行商讨，未必是现在马上需要批准日程的阶段。没有对应的栏目保持空白即可。
缩短文章时，请注意不要率先删减条件。“虚拟数据”、“用户未确认”和“等待回复”并非装饰，而是表明实际成果局限性的信息。如果收到精简字数的指令，请附上“保留状态与限制”的说明，并对比删除前后的内容。
保留数值时，应同时附上总体数量与条件
如果只有“未找到两件”这个数字，我们无从得知究竟是测试了二十件还是两千件。即便需要精简周报，也应保留作出判断所需的总体数量。以本例为例，通过保留虚拟数据二十件这一条件，可以避免读者误以为这是在所有实际用户中进行核对的结果。
如果试做的目的是调查表述不统一的情况，那么比起十八件相符，详细描述两件未检测到的情况更有价值。补充说明这是一次为了核实什么的试验，数字的意义就会传达得更清楚。切勿仅凭件数就添加“高精度”之类的评价词汇。
在记录风险时，应将发生的客观事实与未来的影响区分开来。“等待回复”是事实，但“由于没有回复，公开时间将延迟一个月”无法仅凭输入内容推导得出。如果必须写出影响，负责人应确认所依赖的工序与所需期限，并说明进行推测的前提条件。
如果读者提出了补充问题，请将该答案反馈到下周的输入中。切勿指望人工智能还记得之前的对话，应将其明确记录在作为周报依据的备忘录中。只要保证报告的正本唯一，就能减少每次对话时状态不一致的情况。
省略记录的决定也应基于证据。区分是因为情况轻微而省略，还是因为问题已解决而省略，并在管理用清单中保留状态。切勿将从报告正文中消失视为工作本身的完成。
在持续使用时，应保留与前一周的差异
如果需要制作每周周报，为前一周未完成的项目分配编号会很有帮助。将其与本周的备忘录进行对照，区分已完成、持续中、已取消和暂无信息。为了避免仅因记录消失就当成已完成，“暂无信息”应作为另一种状态保留下来。
传递给人工智能的输入必须限于组织许可的范围内。试做的备忘录中也可能混入内部名称、故障详情以及个人评价。不能因为周报简短就认为可以公开，而应根据查阅者和输入对象来筛选信息。
评估的标准既包括易读性，也包括对事实的保留。请在修改前后核对当作已完成处理的件数、未定的期限以及数字的依据。即便措辞得到了优化，如果导致未完成的事项变得不可见，那么该周报作为判断依据的作用就会减弱。
周报的价值不在于把工作写得多么漂亮，而在于共享推进下一步工作的条件。将实施与通过、查询与达成一致、达成一致与代码实现分门别类地写出来，读者就能减少不必要的进一步核实。你可以将文章的排版交给Copilot，但推进状态的判断应根据证据来做出。
官方信息与一手信息
产品范围与输入方法请参考官方资料。虚拟数据、提示词、预期示例和检查表均为本文的验证方案，并非微软保证的输出示例。
