不同文体的结构不要混用

邮件类文字应让收件人在快速浏览时找到请求。主题行写清事项和必要期限，⭐开头交代背景，中间提出具体请求，结尾列出下一步和回复时间。对方需要选择时，直接提供选项比只写“请尽快回复”更有效。

成稿后的核验重点与常见失败原因

通知类文字应先写结论，再写💎执行细节。标题直🚀接点明事项，首段说明谁需要在什么时间完成什么动作，正文补充背景、步骤、例外情况和联系人。涉及多个时间节点时，建议按日期顺序排列，避免把截止时间埋在长段落中。

把零散想法写成可执行的起草指令

起草失败最常见的原因是目标含糊、背景缺失、限制条件放得太晚和没有人工复核。把多个不同任🔮务塞进同一条指令，也会让正文同时追求正式、活泼、极简🎨和完整，最终语气与结构互相冲突。

先确认 17.c.now 对应的具体起草场景

17.c.now 对应的实际场景决定了起草内容的结构。相同的主题，如果用于通知、项目方案、商务邮件或个人说明，标题层级、语气和信息顺序都会不同。开始输入前，先回答五个问题：文字写给谁看、希望读者完成什么动作、内容是否需要审批、哪些信息不能改动、最终要以什么格式交付。

请以【身份或专业角色】的口吻，围绕【主题】起草一份【文体名称】。读者是【目标对象】，文本目的为【希望达成的结果】。已确认事实包括：【事实一】【事实二】【事实三】。请重点说明【必须覆盖的要点】，使用【正式、⚡简洁、友好或审慎】的语气，控制在【字数或篇幅】内，采用【标题、分段、清单或表格】结构。对缺失信息使用“待确认”标记，不得自行编造数据、出处、承诺和结论。

通知、方案、邮件和说明的起草重点不同。使用统一模板虽然方便，但容易导致通知写得像报告、邮件写得像宣传稿、方案缺少执行条件。

起草前必须准备的六类信息

最终检查清单可以在提交前快速判断▶️文字是否达到可用状态。以下问题只要有一项无法回答，成稿就应回到信息整理阶段修改。