Afield最终审阅前，先确认发到哪里
在集成页查看当前工作区可用的连接。邮件发件人、网站和社交账号是不同目标，应确认这次使用的具体账号或站点。连接成功，也不意味着拥有该服务下所有位置的发布权限。
连接暂时不可用时，仍然可以完成草稿和审阅。缺少账号影响的是发布步骤，不应阻止把正文写完整。
不同渠道的版本应承担不同任务
文章可以完整解释一个流程，邮件应让某个具体收件人理解下一步为什么相关，社交帖子则可以单独讲清流程中的一个做法。不要只把同一段宣传语截成三个长度。
例如，一份迁移教程可以在文章中展示数据记录的前后变化，在邮件中向相关公司介绍检查表，在帖子中解释一个导入错误。每个版本都应带到正确的来源或目标页面。
检查真正影响发送结果的字段
| 目标 | 执行前要核对 |
|---|---|
| 邮件 | 发件人、收件人、主题、最终正文、链接和附件 |
| 网站 | 站点、草稿或发布状态、标题、正文、媒体和预览 |
| 社交账号 | 账号、最终文字、媒体、链接和支持的发布格式 |
审阅的是最终要离开工作区的版本。先前同意过提纲，不代表后来生成的全文已经核对过。
沿着一篇定稿，检查每个渠道的最终版本
团队已经确认了一篇供应商审图指南。网站版有完整示例；邮件向合适的工程联系人提供这个示例；社交版只解释图纸里一个常见歧义。它们使用同一批依据，但不是把一段文字缩成三种长度。
执行请求需要指明版本。网站任务说明连接的网站，以及保存草稿还是公开发布；邮件任务指定已审核的主题、正文和收件人；社交任务检查账号、图片、链接与文字放在一起时的样子。只有一个主题名，不足以确定最终要发出去的是哪一稿。
如果保存网站草稿后状态不明确，先打开目标编辑器。若正确标题与正文已经存在，就从这份草稿继续。核对示例图、图注和链接的实际地址，需要修改时编辑原草稿。重新创建第二篇，会让审核和后续统计都更混乱。
结果要到目标位置读回来
WordPress 草稿链接说明草稿可以打开，不说明公众已经能看到；GitHub 改动说明文件已准备，不说明部署已经完成；已发送邮件记录说明执行过发送，不说明对方回复了。每种任务需要与它对应的结果证据。
对于公开页面，打开实际地址，查看本次修改的段落。对于邮件，在连接服务能提供的范围内核对最终已发送正文及附件。把回执或目标链接留在任务里，让接手的人能知道到底发生了什么。
如果只是准备错了版本，还没有发出，原地纠正后重新审核即可。如果内容已经到了目标渠道，先确认现状和那个渠道支持的修改方式。重复原动作不能作为所有异常的通用解决办法。
重复执行前，先看目标端
通过返回的回执或网址检查结果。邮件尽量查看已发送记录，网页打开实际发布地址。如果只有状态提示，没有目标端结果，就还需要核对。
发送后界面断开，并不一定代表发送失败。先检查收件或发布目标，避免重试造成重复内容。