项目内部记录交给 Agent，怎样生成可发给客户的进展草稿

项目内部记录交给 Agent 写客户进展稿，先核对哪些事实可披露、哪些日期获准承诺，以及客户现在需要做什么。不能把内部周报直接润色后发出。本文只生成待批准草稿，使用合成状态记录；实际对客发送需要授权人员确认，不预设已经连接邮件或消息渠道。

先确定接收对象和本次沟通目的

写清客户对象、项目范围、接收角色和报告截止点。客户内部不同角色也可能有不同信息需求，不能因为都在同一家公司就发送相同细节。对客通知要解决进展知情、待输入确认或下一步安排中的哪一项，应在生成前明确。Atlassian 的沟通计划方法讨论不同受众需要不同信息与沟通节奏，适合用于确定这份草稿的边界，而不是默认所有内部记录均可公开。

把内部事实按披露状态分类

已确认且可对客说明的进展可以进入草稿；尚未批准的计划、内部人员评价、供应商争议及其他客户信息应单独核对。脱敏不是删除姓名就够，项目细节也可能识别其他对象。每条保留来源和允许披露的范围，模型只提出删减建议，不自行认定企业秘密已经可公开。无法判断的信息保持待审，不以让报告完整为理由放进正文。

将完成状态与客户能感知的结果对齐

内部说开发已完成，可能只说明代码提交；对客户应说明当前可确认产物与尚待联调或业务确认的部分。不要把基本完成改写成可立即使用，也不把提交审核写成审核通过。外部输入未到位时可以如实说明需要客户提供什么，不将其写成指责。缺证据的进度比例保持未知，使用明确事项和状态比虚构完成百分比更有帮助。

日期和承诺单独审查

内部预测日期可以作为团队计划，但对客草稿中的日期必须有实际批准依据。缺少前提时写等待确认的安排和下一次沟通点，不把希望或争取改成无条件交付。客户需要提供的资料列明用途、方式和确认窗口，但不要扩大索取范围。若本次只是说明进展，不顺带承诺新服务或增加未确认功能，防止一封通知改变项目范围。

三条样例检查转换是否越界

OUT-01 的草案已提交但待业务核对，对客保留这个状态；OUT-02 内部预测缺少批准，不输出确定工期；OUT-03 包含另一客户信息，应该删除无关内容并核对剩余披露。附件还保留拟议对客句和待审批点，评审人可以逐条比较来源与改写。演练不发送任何真实消息，也不把人工修改过的草稿冒充自动系统已发布。

批准后保留版本和发送结果

授权人员确认接收对象、事实、日期和附件，再决定是否发送。批准版本与生成版本分开，防止批准后又被模型改了关键句。发送失败与业务未批准是不同状态，都不能显示客户已收到。后续更正说明引用原通知及修正范围，不静默替换历史材料。若需要完整自动通知链路，另行核对渠道、权限与回执，不把文案可用等同于发送功能已交付。

合成记录与预期去向

编号	合成内部记录	披露判断	拟议对客草稿	必须确认	禁止改写
OUT-01	草案V2已提交，业务尚未核对	可说明已提交及待确认	已提交草案，当前等待约定窗口核对	草案和接收对象	不能写已正式验收
OUT-02	内部希望下周完成，但依赖未确定	日期未获批准	关键输入确认后再更新具体安排	实际批准日期与前提	不能写下周必定交付
OUT-03	进度笔记含其他客户处理细节	无关信息不披露	仅保留本项目可公开进展	检查剩余信息是否仍可识别第三方	不把删姓名当足够脱敏

下载可填写的完整核对表。表中业务对象均为合成，不代表真实客户安排；实际填写需补充已授权来源和确认人，没有证据的状态保持待确认。

相关方法见文章跨受众改写与事实保留，更多方向见业务场景专题。如需定制，可在咨询入口提供脱敏记录、现行规则和期望产物，先确认任务及人工核对方式。