北京
一个严重支持工单关闭之后，想知道"到底发生了什么"的其实是两拨人。自己团队要的是完整故事，好让同样的事不再发生；客户要的是三件事——什么坏了、修好没有、还值不值得信任。
这是两份文档。把它们混成一份，内部服务名和半确认的猜测就会出现在客户的收件箱里。
动手写之前，先回答一个问题：你有多确定？原因要如实打标签——已确认，由工程师、修复或测试证明，并写明是谁或什么证明的；可能，证据指向一个方向但没人证实，那就叫它假设；未知，症状修好了但不知道为什么，就照实说。
只有"已确认"才能作为原因写进客户版本，其余一律变成"我们仍在确认"。
内部版：给团队看的完整链条
内部版按固定字段填：工单号、客户、严重级别、时间窗口（含时区）、客户看到的症状（用他们自己的话）、影响范围（谁受影响、持续多久）。
时间线要逐条列，每条带上时间戳和它来自的日志行或工单消息。证据部分原样引用关键日志。原因一栏后面必须跟状态：由谁确认、还是假设、还是未知。还要写清排除了什么、为什么不是它。
修复写清改了什么、何时到达客户；预防写清改动、负责人和截止日期；最后留一栏"仍未解决"，放那些暂时没人能回答的问题。
客户版：一分钟能转述给老板
客户版要短、要平实。客户那边不懂技术的人，应该能在一分钟内把它讲给自己老板听。
结构就四块：发生了什么，比如"定时导出在 UTC 9:20 到 10:05 之间失败"；谁受影响，是只有你这个账户还是用了某功能的账户；为什么，只有确认了才写一句大白话，否则就写"我们仍在确认原因，将于某日前更新"；我们做了什么，修复内容以及何时恢复正常；我们正在改什么，只写已经商定并有归属的改动。
要拿掉的东西很明确：内部服务名、堆栈信息、对个人或团队或供应商的归责、未确认的原因，以及任何未经批准的日期或补偿承诺。
AI 能帮哪一段，会在哪一段坑你
AI 模型擅长的是慢活：从日志和工单里对齐时间线、引用证据。它同样擅长的是——对自己猜出来的原因说得像真的一样。所以提示词要把它摁在事实层面。
粘贴任何内容前，先去掉密码、密钥、令牌和个人数据，并使用公司批准的工具处理这类数据。
建时间线时，让它按指定时区和时间窗口，用给定日志行和工单逐条输出：时间戳加原文，不带时区的时间戳一律标为待确认，不许添加日志和工单里没有的事件。时区这一行比看上去重要：日志常用 UTC，客户报的是本地时间，差一小时就可能让错误的事件看起来像触发点。
起草内部摘要时，要求原样引用证据，除非记录写明由谁确认，否则每个原因都标为假设，宁可留"未知"也不要猜，并注明这是草稿。
写客户版时，先按客户模板改写，禁止内部名称、禁止归责、禁止未确认原因、禁止承诺日期或补偿；然后让它自己检查——列出文中每一句不被内部摘要支持的表述。最后一句最有用：自检不能替代你自己的通读，但它会先把最弱的句子指给你。
两份文档，两套读者，一条底线：确认过的才出门。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
