做AI邮件助手最憋屈的往往不是模型效果拉胯而是“明明已经自动处理了用户还是不敢信甚至投诉乱回复”。我参与某邮件产品团队的项目时前期把宝全押在“全自动总结自动代回复”上上线后数据却很难看。AI代发出去的邮件被用户撤回、被收件人当成垃圾营销后台体验数据里“已由AI代理回复”的提示带来的不是惊喜而是惊吓。后面复盘结论很统一AI在邮件场景里缺的不是聪明是确定性。用户要的也很简单——由他决定什么时候让AI介入并且每一步结果都看得见、改得动。于是就有了这份PRD的重新设计核心是把AI从“抢答者”变成“被提问者”新增一套完整的手动触发机制来驱动AI总结与回复。这条链路看起来只是加个按钮真正做起来牵扯到任务状态机、上下文编排、Prompt设计、异常兜底、灰度评估一环扣一环踩过的坑值得拆开来聊一聊。这篇文章会把整份方案从需求逻辑、接口设计到上线指标完整讲透适合正在做邮件助手、客服AIGC、或任何“AI代操作”类产品的产品经理、后端研发和测试同学参考。1. 需求背景与方案选型逻辑1.1 原来的“全自动代操作”为什么走不通先说清楚最原始的场景。某邮件产品的用户每天会收到几十封非订阅类邮件其中大量是会议确认、项目同步、客户问询内容重复度高、回复套路相对固定。团队最初的设想是做一个全自动的AI邮件助手后端定时扫描新邮件命中关键词或规则后自动生成总结再结合历史回复风格自动生成回复并直接发送。理想状态下这确实省事但实际操作中暴露了三个核心问题用户完全失去控制感。AI什么时候动了邮件、会不会把不该发的发出去用户一概无法掌控一旦出现一次误发信任就彻底崩塌。自动触发的准确率扛不住长尾场景。垃圾广告、陌生客户、多语言混杂、含敏感信息的邮件规则引擎和模型判断都很容易误判自动处理越积极错得就越离谱。犯错的成本远高于省下的时间。发错一封商务邮件后续解释、撤回、道歉的代价远超手动处理十封邮件。所以需求重新定调AI一定要介入但介入的开关必须握在用户手里。加上手动触发机制用“人机协同”替代“全自动遥控”是这个方案最核心的出发点。1.2 为什么最终选了“手动触发”而不是命令式或半自动当时内部讨论过三个备选方案不只是手动按钮这一条路。方案A是全自动加事后通知也就是AI处理完再告诉用户“我已经回复了”。这个方案开发量最小但用户反馈最差。方案B是命令式触发比如在邮件标题里加“#AI”或“#summary”标记让系统识别后处理。这个方案看着很极客实际上学习成本高用户还得记特殊语法在手机端输入尤其别扭。方案C就是最终采用的手动按钮触发用户主动点击“AI总结”或“AI回复”生成结果后先预览、可编辑确认后才发送。三个方案放在一起对比感受会更直观对比维度全自动事后通知命令式标记手动按钮触发用户掌控感低容易崩塌中依赖学习成本高完全自己决定误操作风险高缺少确认环节中标记容易输错低必须先预览确认开发成本低中需解析语法中需做状态轮询多端体验统一性好差输入习惯不统一好按钮天然适配对AI能力容错低中高结果可编辑选型的判断依据也很直白邮件处理是高频但非紧急的场景用户愿意多花十几秒换取“不错、不乱发”的安全感。手动触发牺牲了一点自动化率换来了信任和可解释性这笔账非常划算。用户发起、AI生成、用户确认的闭环才是产品能长期跑下去的结构。2. 整体流程设计与任务状态机2.1 从点击按钮到发送邮件的完整链路手动触发机制设计之前我先画了一遍端到端流程把它切成四个阶段触发阶段。用户在邮件列表或详情页点击“AI总结”“AI回复”按钮前端记录点击来源和邮箱标识生成一个全局唯一的requestToken然后调用后端接口。校验与入队阶段。后端做三件事校验用户是否有权限、模型配置是否可用、该邮件是否在短时间内重复触发。校验通过后创建AI任务记录进入待处理队列。处理阶段。编排层负责拉取邮件原始内容、清洗HTML、过滤签名和引用段、执行敏感信息脱敏然后按邮件长度选择Prompt模板并截断长文本再调用模型服务生成结果。回传与确认阶段。前端轮询任务状态拿到结果后展示“摘要卡片”和“回复草稿框”。草稿不是直接发送而是等用户编辑、确认后点击“发送”才会真正调发送接口。其中最关键的设计边界是AI永远只负责生成草稿发送权始终保留在用户手上。这一点必须在PRD里写死否则下游开发很容易“为了体验优化”跳过确认环节把半成品直接发出去。2.2 任务状态的定义、流转与数据模型手动触发机制的稳定性很大程度上取决于任务状态机的设计。我在方案里定义了六种状态状态含义进入条件PENDING已入队等待处理用户触发成功后创建RUNNING正在拉取邮件或调用模型队列调度到该任务SUCCEED生成结果成功等待用户确认模型结果通过校验FAILED处理失败超时、接口异常、内容校验失败CANCELLED用户主动取消用户在等待期间点击取消EXPIRED结果过期草稿生成超过24小时未确认发送状态流转看起来简单真正要关注的是“超时”和“取消”这两个分支。比如任务卡在RUNNING超过90秒不能一直转圈让用户干等必须主动置为FAILED并提示重试用户点击取消后如果模型已经返回结果后端也要把结果丢弃并标记CANCELLED避免脏数据影响后续统计。数据模型上我建议任务表至少包含这些字段字段名类型说明task_idstring任务唯一ID建议UUIDuser_idstring发起用户email_uidstring原邮件唯一标识mailbox_channelstring邮箱渠道标识trigger_sourcestring触发来源详情页/列表页/批量操作request_tokenstring幂等键防重复触发statusstring当前状态retry_countint重试次数prompt_versionstring使用的Prompt版本号model_namestring使用的模型名称latency_msint模型调用耗时error_codestring失败错误码created_atdatetime创建时间updated_atdatetime更新时间requestToken是这里最重要的一个字段。用户快速双击按钮、网络重试、前端轮询重发等场景全部依赖它做幂等判断否则同一个任务会被后端重复执行浪费模型调用费是小事重复生成草稿导致状态错乱才是大问题。3. 触发入口与交互细节设计3.1 不同入口的交互方案与反馈机制手动触发机制要覆盖的入口不能只有一个详情页按钮。用户看邮件的习惯差异很大我按场景拆成了三类入口一是邮件详情页的“AI总结”和“AI回复”两个按钮。这是最自然的主入口用户在阅读邮件时最需要辅助。按钮常驻右上角点击后立即置灰并展示“正在分析”状态防止重复点击。二是邮件列表页的单条操作。用户在列表页勾选一封邮件从底部操作栏点“AI总结”不需要进详情页就能快速了解核心内容。这里要注意的是列表页入口必须与详情页共用同一个任务通道不能各做一套逻辑否则同一个requestToken会被生成两次或状态会串。三是批量多选模式。用户勾选多封邮件后点“批量AI总结”最多允许一次处理10封后端会创建多子任务并行处理。交互上要明确展示“第2/10封处理中”的进度而不是一个笼统的loading否则用户很快会失去耐心。用户点击触发按钮后的反馈节奏也做了明确要求300毫秒内必须给出按钮反馈包括置灰、文案变化或轻量 loading超过3秒的任务必须显示进度条或“预计30秒内完成”的预估文案。这是因为模型调用通常需要5到10秒如果前端没有任何进度反馈用户会以为系统没响应而反复点击后面会引发一堆重复任务。3.2 接口设计与关键参数说明手动触发入口的前端请求和后端响应需要提前定清楚。核心接口我设计为两个POST /v1/ai-mail/trigger用于创建任务。{ request_token: uuid-xxxx, email_uid: msg-192829, mailbox_channel: imap_work, action_type: summary, summary_scope: detail, reply_tone: neutral, need_draft: true, model_id: default_v2 }GET /v1/ai-mail/tasks/{task_id}用于轮询任务结果。{ task_id: task-xxx, status: SUCCEED, summary: 会议确认邮件时间下周三15:00, draft_content: 收到会议时间确认无误。, need_human_confirm: low, prompt_version: summary_v3, latency_ms: 4500 }这里几个参数的取舍值得单独说。action_type只有summary和reply两种分别对应对邮件“总结”和“生成回复”两个诉求不要在初期做成“summarize_and_reply”这种复合动作阶段越大画得越糙用户反而不知道该看哪个结果。summary_scope有short和detail两个选项short只生成三行以内摘要detail允许生成带结构化要点的长摘要。这个参数要允许前端在按钮上通过“长按”或“展开”透出满足不同阅读深度需求。reply_tone控制回复语气可选supportive、neutral、direct三类对应商务场景里的温和、中立、直接。这个参数是后续Prompt工程的重要输入后端要原样透传给模型服务不能在前端被丢弃。need_draft是一个开关表示是否生成可编辑的邮件正文草稿。如果用户只想快速看摘要不打算AI代回那就不需要生成草稿能省一轮模型调用成本。接口层面有一个很重要的约定就是创建任务和确认发送必须严格分离。确认发送使用独立接口POST /v1/ai-mail/send并且只接受用户在草稿框里最终编辑过的内容绝不能在后端把“任务里生成的草稿”直接自动发送。这是整条交互链路里不能妥协的边界。4. 模型编排与Prompt设计实战4.1 总结与回复双通道的Prompt结构手动触发机制确定之后真正的技术天花板就落在Prompt设计上。这里最重要的经验是不要试图用一个万能Prompt同时完成总结和回复两个通道必须独立设计。总结通道的核心目标是“把一封邮件压缩成用户能快速理解的信息”指令结构我按这个顺序组织你是商务邮件助理。用户需要快速把握一封邮件的核心内容。 请按以下顺序输出 1. 一句话概括邮件主题 2. 关键信息点每点不超过20字最多列5点 3. 需要用户关注的行动项如果没有输出无 注意事项 - 忽略邮件签名、免责声明、广告推广段落 - 只输出中文结果 - 输出格式为纯文本列表回复通道的Prompt更复杂因为回复要考虑语气、上下文历史、收件人身份结构上要有更细的约束你是商务邮件助理。请基于原始邮件内容为用户生成一封合适的回复草稿。 背景信息 - 用户与收件人的关系{relation_context} - 用户期望的语气{reply_tone} - 历史往来邮件摘要{history_summary} 原始邮件内容 {email_content} 输出要求 - 开头称呼礼貌结尾有合适署名占位符 - 核心段落回应用邮件中的关键问题 - 如果原始邮件中存在不明确信息必须在草稿中标注[待确认] - 正文不要超过150字 - 输出纯文本不要输出JSON或额外说明两个Prompt都刻意要求“输出纯文本”而不是“输出JSON”。在实际测试中让模型直接输出tructured JSON虽然方便解析但用户查看草稿时会看到大括号和字段名体验非常糟糕。我的方案是让模型输出纯文本后端再对关键位置做规则补全和格式整理这样既保留了用户的阅读体验又能在后端拿到稳定字段比如把末尾的“[待确认]”提取出来生成提示标签。4.2 长邮件截断策略与上下文拼接邮件正文长度差异极大短则几十字长则上万字。直接全文塞给模型有两个问题一是Token上限扛不住二是越长注意力越分散摘要质量反而下降。我设计了“保留关键段”的截断策略而不是简单从开头截取前N个字符。具体做法分为三步第一步把邮件内容按空行拆成段落过滤掉签名区、免责声明区、公司模板脚注区这些区域经常超过正文长度的40%过滤后文本立刻缩小一大截。第二步给段落打重要度分。邮件开头两段通常包含完整背景结尾前两段通常包含行动项和结论中间内容往往是在补充细节。打分规则是标题段落权重3开头两段权重3结尾三段权重2中间段落按是否包含“需要”“请在本周”“答复”“确认”这类行动词加权。第三步按分数从高到低选择段落直至累计字符达到预设窗口。窗口大小按模型Token估算我预设8000字符约占2000Token留出足够余量给Prompt模板和输出。截断完成后要保留一份完整邮件正文存到任务表里后续用户点击“查看完整原文”时不需要重新拉取。这背后的逻辑可以类比成读长邮件人也不会逐字读完全文先看起头搞清楚背景再扫结尾找行动项中间快速跳过。截断策略本质上是把这个阅读习惯显式建模减少模型被无关段落干扰的概率。4.3 让模型输出“不确定感”——置信度与人工确认标记手动触发机制还有一个容易被忽略的设计点AI生成的结果必须能表达“我并没有把握”。如果模型对邮件的理解本身就不确定却还违心输出一个自信满满的摘要用户一旦发现错误信任立刻归零。我在Prompt结尾增加了一条输出要求最后一行单独输出confidence:high/medium/low 含义如下 - high邮件内容清晰可以放心使用 - medium部分信息来自推测建议人工核对 - low邮件内容残缺或依赖大量推断强烈建议人工确认后再发送后端拿到confidence标记后会决定结果卡片上是否展示黄色提醒条。low置信度的草稿发送按钮还需要二次确认弹窗。这个设计对模型幻觉的约束效果显著尤其在处理转发链很长的邮件时模型生成的总结经常和真正的问题不符有了low标记用户至少知道“这个结果别直接用”。5. 异常处理与质量兜底5.1 超时、并发与限流设计手动触发机制意味着用户每次点击都会消耗一次模型调用一旦用户量起来并发问题必须提前评估。我按10000日活的业务量做了简单估算假设人均每天触发5次全天任务量约5万次分散到10小时平均QPS约1.4高峰集中在上午10点和下午3点峰值约3到4QPS再考虑到批量触发的一次性并发后端至少需要支持15QPS的吞吐预留5倍缓冲比较稳妥。超时参数我设置为连接超时5秒模型调用超时30秒总体任务超时90秒。选这个数是因为主流模型P95延迟通常不超过8秒30秒给足余量但又不会让用户等到麻木90秒覆盖了邮件拉取、清洗、调用、校验的完整链路超过即FAILED。限流规则按用户维度控制每人每分钟最多触发10次每天最多100次。批量任务按邮件数量折算一次10封批量任务算10次配额。这样既能防止用户误操作刷爆队列也能避免某个高频用户的异常行为拖垮整体资源。实际检查时超过负载的业务节点要及时告警因为邮件拉取还可能受外部邮箱服务商的接口频控限制多通道叠加时必须统一监控。5.2 内容安全与隐私脱敏邮件是最敏感的数据之一。AI处理邮件时会把正文内容发给模型服务这个环节必须做脱敏。脱敏规则要覆盖邮箱地址、手机号、身份证号、银行卡号、IP地址和具体的内部项目代号。脱敏的实现要在两处做第一处是在构造Prompt之前对原始邮件正文执行正则替换第二处是在模型结果返回后再扫描一次脱敏标记防止模型把标记原样抄回来。例如正则将[email protected]替换为[EMAIL]模型如果只是照抄内容输出里会残留[EMAIL]后端再替换成“对方邮箱”这类中性表达避免把真实邮箱展示给用户。还要额外考虑隐私场景如果用户触发AI回复的收件人地址本身出现在原文里生成草稿时收件人信息只展示在界面上不允许出现在草稿正文里。这个约束要在Prompt系统指令中明确写入不是靠规则兜底能解决的。5.3 失败重试与幂等控制模型调用不可能100%成功手动触发场景下的失败处理比自动处理更敏感因为用户是盯着屏幕等结果的。重试策略我定义为第一次失败立即自动重试一次第二次失败进入退避队列分别延迟1分钟、3分钟、10分钟重试超过三次则标记FAILED并提示用户手动重新触发。这里必须强调重试的幂等控制。每次重试都必须携带原始requestToken后端收到重试请求时先查任务表里是否存在同token且状态为RUNNING的任务如果存在就直接复用不另起新任务。否则一个网络抖动就会导致同一封邮件被处理两三遍用户会看到多个一模一样的结果卡片数据统计也会全部失真。另一个容易踩的坑是模型返回结果“成功但并不合法”。比如返回了空字符串、未按Prompt要求输出confidence、或输出内容只是一段重复文本。这些情况后端要做质量校验至少要检查非空、长度大于10、不包含明显重复的大段占位符校验不通过同样走FAILED流程而不是直接把垃圾内容展示给用户。6. 测试要点与灰度上线评估6.1 核心测试用例的设计思路手动触发机制的功能测试不能只测“正常点击后生成草稿”这条主线。我整理测试用例时会刻意覆盖几类容易被忽略的边界场景测试场景用例说明预期结果正常单封总结点击详情页AI总结按钮生成摘要卡片状态SUCCEED超长邮件邮件正文超过20000字符按截断策略生成不超时重复点击用户3秒内连点5次仅创建一个任务接口幂等生效模型超时模拟模型接口等待35秒任务FAILED前端提示可重试模型返回非合规内容返回空字符串或纯标点校验拦截状态FAILED多语言邮件英文/日文邮件触发总结输出中文摘要特殊字符不丢失批量触发勾选12封邮件点批量总结超过10封限制前端拦截提示取消任务处理中点击取消任务CANCELLED结果丢弃草稿修改后发送用户增删草稿内容后点发送发送的必须是草稿框最终内容能看出测试重点并没有放在模型生成文本的“质量”上因为质量是灰度阶段用数据评估的功能测试阶段要保证的是流程的正确性和系统的容错性。把状态流转和幂等控制测稳后面迭代调Prompt才敢放手改。6.2 灰度发布策略与效果指标手动触发机制上线不能全量铺开我采用的是四步灰度内部5人体验小组先跑一周再开放给1000人白名单确认稳定后放10%流量最后观察48小时再全量。每一步的退出条件都要提前定好不能凭感觉。评估的核心指标有五项指标计算方法目标值任务成功率SUCCEED任务数 / 总触发任务数≥ 95%总结采纳率用户直接复制/采用总结次数 / 总结生成次数≥ 45%回复修改率生成草稿后被修改后发送的数量 / 回复草稿发送总数≤ 60%端到端耗时用户点击到结果展示的平均耗时≤ 12秒用户主动反馈率提交纠错或负反馈的用户数 / 灰度用户数≤ 0.5%如果灰度期间任务成功率低于90%或负反馈率持续升高就立即停止放量回到功能层面排查任务失败原因和Prompt输出质量问题。回复修改率这个指标要看得动态一些新功能上线初期用户总会习惯性地改几笔等熟悉之后修改率会自然下降如果连续两周仍在60%以上说明Prompt生成内容距离用户真实表达习惯还有差距需要回炉调参。这里补充一个估算案例假如灰度10%覆盖了约1000个用户人均每天触发5次单日任务量5000次当任务成功率从98%下降到90%时意味着每天多出400个失败任务对应数百次体验投诉这种情况下做灰度决策的置信度就非常高了。7. 落地过程中的避坑心得7.1 Prompt版本管理比模型参数更重要手动触发机制跑通以后团队最容易陷入一个误区每次效果不好就去调模型参数或者换模型。我发现真正的杠杆在Prompt版本管理。我要求每一次Prompt改动都要带上版本号比如summary_v3、reply_v5每个版本上线前必须用同一批历史邮件做回归测试不能让模型效果在一个月内悄悄退化而毫无察觉。我的做法是建立两条Prompt资产一条是稳定的线上版本只在固定版本上迭代另一条是实验版本跑批量离线回放。只有离线回放的采纳率、置信度分布均优于线上版本才允许切换。模型参数反而很少动保持一个默认配置即可这样问题排查起来会非常快出问题时只需要对比Prompt版本不用同时怀疑参数、模型和服务状态。7.2 不要把模型返回内容直接展示给用户最初版本里AI回复草稿就是模型返回原文结果用户反馈“看起来太像机器写的”。后来排查发现模型输出的换行、称谓、空行格式非常不稳定有的回复以“邮件内容如下”开头有的漏掉了开头称谓。这类问题不适合靠模型“自觉”修正而是要在后端做一层模板后处理。我在后端定义了回复草稿的格式化流程提取模型输出中的正文首行作为第一段统一添加占位符“尊敬的[收件人]”再对段间空行做规整最后检查末尾是否有署名没有则加上“[你的名字]”占位符。用户看到的是一个标准商务邮件结构而不是模型原生输出的半成品这个体验差异很大。7.3 全链路日志与任务回放能力手动触发机制上线后用户反馈问题比自动模式下多得多因为用户是主动发起对结果的预期更高一旦不满意就会直接提工单。没有全链路日志排查问题就等于大海捞针。我在每个任务的创建、调度、拉取邮件、脱敏、截断、模型调用、结果校验、前端轮询八个关键节点都打了一条带taskId的日志。线上出现任何问题先按taskId把时间轴拉出来每段耗时和返回值一目了然三分钟就能定位是模型慢、脱敏正则写错还是前端轮询断了。这个能力在建任务表时就应该规划好而不是等出了问题再补否则漏打日志的历史任务会变成永远查不清的悬案。执行下来还有个体会是手动触发机制看着像一个不起眼的交互按钮实际它撬动的是AI产品可控性的设计范式。大模型能力越强产品上越要把它当成“需要被监护的实习生”什么时候让他干活、干完的活谁来验收这些规则必须由产品结构和工程机制来保障。手动触发、状态机、确认发送本质上都是在解决同一件事——AI生成内容必须建立人类确认闭环这也是这个方案最值得被其他AI代操作类产品拿走的那部分。后面做类似功能的同学建议从小范围真实邮件回放开始验证Prompt效果再投入资源做交互和状态机能少走不少弯路。