到了周五例行汇报时，你的一项工作落后了，还在等待品牌素材。请模型“把这次更新写得积极又专业”，它往往会写成“各项工作进展顺利”，再把卡点放进脚注。客户会根据这封邮件安排上线。粉饰不是礼貌，而是对排期的威胁。
这是内部团队文章无粉饰的异步更新写作面向自由职业者的对应版本。方法相同，读者不同：这里面对的是付费客户，而不是Slack上的经理。
为什么模型偏爱积极措辞
生成式系统往往被调校为输出友好、听起来有帮助的文字。OpenAI曾公开讨论并回滚2025年4月GPT-4o更新中的谄媚倾向（OpenAI, “Sycophancy in GPT-4o”）。当客户要据此作出规划时，风险管理框架会把这种偏差视为可预见的失败模式，而不是可以忽略的小毛病（NIST AI Risk Management Framework）。如果提示词含糊，例如“为Orion项目写一份客户更新”，模型不了解真实状态，只能编造一个貌似合理的叙述。貌似合理不等于经得起追责。
不要让AI起草的客户更新把“受阻”或“落后”升级成暗示按期交付的语言。若诚实状态是延误，就说延误，并写清你需要什么来解除阻塞。
个人经营者工作流
步骤1：先填事实卡（不用AI）
用白话填写：
- 自上次更新以来已交付 / 完成
- 受阻于（或“无”）
- 你已实际核对过的下一步具体行动与日期
- 信心：按期 / 有风险 / 受阻 - 需在某日前得到X
- 自上次更新以来的范围变更（链接你的范围变更日志）
步骤2：仅排版提示
把这些事实变成一封简短的客户状态邮件。
语气保持平实、专业。
不要添加我未写的进展、信心或时间线。
若有事项受阻，把它放在靠前位置，而不是脚注。
事实：
[粘贴事实卡]
步骤3：粉饰词扫描
| 需要检查的短语 | 替换为 |
|---|---|
| 进展顺利 / 干得很猛 | 仅具体已交付项 |
| 快到了 / 差不多完成 | 你相信的日期，或“尚无可靠预计完成时间” |
| 按期（实际受阻时） | 先写阻塞 + 请求 |
| 应该没问题 | 你真实的信心行 |
步骤4：发送前检查隐私
若你用AI排版邮件，确认你没有把凭证、客户的终端用户个人数据或机密附件贴进聊天。状态事实很少需要那些细节。
步骤5：需要升级沟通的情形
如果同一事项连续三次更新都处于“有风险”状态，就应提议通话或作出范围决定。不要用一封又一封周报掩盖迟迟未决的问题。当AI对交付物提供了实质性协助时，请遵循相关披露规范，并继续以你的姓名承担责任（在AI协助的工作上保留你的姓名）。
在邮件工具中保存“事实卡”片段。五条未填完之前，拒绝打开AI标签页。
示意情景（已标注）
示意情景，非实测案例： 一位自由项目经理发送了一封由AI润色的更新，称集成工作“可按期在周五完成”。但他明知客户的API密钥尚未提供。客户却在周三发出了上线宣传。事后补救的成本，比一开始发送一封直白邮件更高。
长期服务与固定项目更新
在长期服务合同下，即使一周没有明显进展，也应如实说明哪些事项有变化、哪些没有，以及你需要客户提供什么。沉默会让客户习惯性地假定工作正在推进。对于固定项目，更新应沿用SOW中的里程碑措辞，确保双方对“完成”的理解一致。如果SOW含糊，应在下一次变更时修正文案，而不是在邮件里编造确定性。
事实到邮件的示意形态
仅示意：
事实：已交付首页线框v2。受阻于客户设计负责人的最终品牌图标。下一步：图标到达后做UI套件；没有它们无法承诺周五视觉QA。信心：受阻 - 需周三前拿到图标以保住周五。
只做格式整理后的邮件，仍应先写明卡点和周三前需要的事项。如果草稿把这些内容埋在“首页取得扎实进展”之后，就拒绝这份草稿。
验证与回退
验证：让一个不了解背景的人只读这封邮件，他不会据此作出超出事实卡支撑的安排。
回退：直接把事实卡整理成项目符号邮件发送，不经过AI处理。朴素但清楚，胜过漂亮却错误。
当你向消费者销售时，误导性的商业沟通可能引发消费者保护问题（FTC advertising overview；FTC crackdown on deceptive AI claims；EU UCPD）。即使只是状态邮件，也可能让客户形成对交付的预期。对于B2B长期服务，实务要求仍然相同：不要制造虚假的确定性。
案头版：客户更新事实卡。
