Appearance
数字口径待核实
这份文件的存在是因为简历现在不能直接投
简历目前是示例填充版，顶部还挂着你自己写的那句标注：「以下项目规模、评测结果和效率数据为成稿效果示例，正式投递前请替换为本人真实数据」。
也就是说，下面主表里那 20 个数字，现在一个都不能拿去接受追问。
每一条数字只有三种处理路径，必须选一种，不能悬着：
| 路径 | 什么时候选 | 怎么做 |
|---|---|---|
| A · 替换 | 能翻到日志、评测记录、后台数据、工单统计 | 填进主表「真实值」列，并且把算法和证据一起记下来 |
| B · 降级 | 记得大概量级，但没有精确记录 | 按 §3 改成定性或区间表述，去掉小数点级的精确感 |
| C · 删除 | 既没有记录、也说不清口径 | 直接从简历删掉，用「做了什么」替代「做到了多少」 |
路径 C 不丢人，路径 B 也不丢人。 一个只写做法不写数字的项目描述，最多算平淡； 一个写了数字但答不出口径的项目描述，等于在面试官面前挂了一张「这个人的话要打折听」的标签。
顺序提醒
先做这份，再练 10-口述稿。 口述稿里所有数字位置都写着 <待核实>，就是等你这边定稿。 数字没定就开始背稿，等于把错的东西练熟。
1. 主表：逐条过一遍
怎么用这张表
表比较宽，横向滚动看。填「真实值」列时必须同时确认「标准算法」那一列—— 如果你当时算的方式和标准算法不一样，那要么改口径重算，要么在回答时主动说明「我们当时的口径是 XX」。 主动说明不掉分，被问出来才掉分。最后一列 D* 对应 §3 的降级表述编号。
| # | 项目 | 简历表述 | 示例值 | 真实值（待你填） | 这个指标的标准算法 | 证据从哪找 | 面试官会怎么追问 | 查不到怎么改 |
|---|---|---|---|---|---|---|---|---|
| 1 | 知识库 RAG | 支持 N 个知识库 | 6 个 | 上线后实际创建且在用的知识库数，剔除测试库 | 后台知识库列表；select count(*) from knowledge_base where status='active' | 这 6 个分别是哪些部门的？测试库算不算？ | D1 | |
| 2 | 知识库 RAG | N 份文档 | 3,200 份 | 入库状态为「完成」的文档数，不含失败和重复上传 | documents 表按状态分组统计 | 是累计上传还是当前有效？解析失败的算不算？ | D2 | |
| 3 | 知识库 RAG | 约 N 个分块 | 28,000 个 | chunks 表行数，需同时说明平均块长和切分粒度 | chunks 表 count + 平均 token 数 | 平均每份文档多少块？切分粒度多大？ | D2 | |
| 4 | 知识库 RAG | N 条问题-标准答案评测样例 | 120 条 | 人工标注的 QA 对数：问题 + 标准答案 + 应命中的 chunk | 评测集文件/表格，以及标注人 | 谁标的？覆盖哪几类问题？标注一致性怎么保证？ | D3 | |
| 5 | 知识库 RAG | Recall@5 达到 X | 86% | 分母 = 评测问题数；分子 = top5 中至少命中一个标准 chunk 的问题数 | 评测脚本输出、实验记录 | 命中怎么判定，chunk 级还是文档级？哪一版切分和模型跑的？ | D4 | |
| 6 | 知识库 RAG | 引用完整性 X | 91% | 分母 = 需要引用的回答数；分子 = 引用齐全且都能在原文定位到的回答数 | 人工抽检记录表 | 抽检了多少条？「完整」是谁判定的？ | D5 | |
| 7 | 知识库 RAG | 人工检索耗时由 A 降至 B | 10 分钟 → 2 分钟 | 同一批查询任务的人工完成时长中位数，前后必须是同批任务 | 用户访谈、计时记录 | 这两个数怎么测的？多少人多少任务？ | D6 | |
| 8 | BI Agent | N 条评测样例 | 200 条 | 覆盖单表/JOIN/时间范围/TopN 的标注问题数，含标准 SQL 或标准结果 | 评测集文件 | 四类各多少条？标准答案是 SQL 还是结果？ | D3 | |
| 9 | BI Agent | SQL 生成准确率 X | 89% | 分母 = 评测问题数；分子 = 执行结果与标准答案一致的问题数（不是「SQL 跑通了」） | 评测脚本输出 | 你算的是执行成功率还是结果一致率？多表 JOIN 单独看多少？ | D7 | |
| 10 | BI Agent | 覆盖 N 个部门 | 3 个 | 有活跃用户在用的部门数，不是「开通了权限」的部门数 | 用户表/访问日志按部门统计 | 每个部门几个人在用？使用频率多高？ | D1 | |
| 11 | BI Agent | 平均问数响应时间 X | 15 秒 | 端到端 P50：问题提交到结果返回，需说明是否含图表渲染 | APM 或接口耗时日志 | 是平均还是 P50？P95 多少？含不含 SQL 执行时间？ | D8 | |
| 12 | BI Agent | 人工取数占比由 A 降至 B | 60% → 20% | 分母 = 取数需求总数；分子 = 仍需数据组人工处理的需求数 | 需求工单系统统计 | 需求总数从哪来？统计窗口多长？前后窗口一样吗？ | D9 | |
| 13 | 智能客服 | 工具调用成功率 X | 94% | 分母 = 工具调用总次数；分子 = 返回业务成功的次数；重试是否计入要说明 | 调用日志聚合 | 一次重试算一次还是多次？参数校验失败算失败吗？ | D10 | |
| 14 | 智能客服 | 任务完成率 X | 86% | 分母 = 有明确任务意图的会话数；分子 = 任务达成的会话数 | 会话日志 + 人工标注 | 「完成」谁判定？用户中途放弃算哪一类？ | D11 | |
| 15 | 智能客服 | 日均处理约 N 次会话 | 1,500 次 | 统计窗口内的日均会话数；需定义一个会话怎么界定 | 会话表按天 count | 哪段时间的日均？多久不说话算新会话？含测试流量吗？ | D12 | |
| 16 | 智能客服 | 转人工率由 A 降至 B | 35% → 18% | 分母 = 会话总数；分子 = 转人工的会话数 | 会话日志按转人工标记统计 | 35% 是老系统的口径吗？两边口径一致吗？ | D9 | |
| 17 | 政务助手 | N 条评测集 | 180 条 | 三类场景各自的标注问题数之和 | 评测集文件 | 三类各多少条？谁标的？ | D3 | |
| 18 | 政务助手 | 办事指南回答准确率 X | 91% | 分母 = 办事指南类问题数；分子 = 人工判定关键信息全对的问题数 | 人工评分表 | 「准确」的细则是什么？漏一项材料算对还是错？ | D4 | |
| 19 | 政务助手 | 政策引用完整率 X | 93% | 分母 = 需要引用政策的回答数；分子 = 引用文件/条款齐全且都在有效期内的回答数 | 人工抽检记录 | 引用了已废止政策算不算完整？ | D5 | |
| 20 | 政务助手 | 处理时间由小时级缩短至分钟级 | 小时 → 分钟 | 同类任务处理时长的量级对比，最好给出前后各自的中位数 | 用户访谈、试点反馈 | 具体是多少分钟？是谁的时间省了？ | D6 |
1.2 简历没写数值、但一定会被追问的几处
这几句在简历里是定性描述，可它们天然带着一个隐含的数字，面试官顺手就会问一句「那大概是多少」。 没准备就会当场卡住，效果和答错数字一样差。
| 简历原句 | 隐含的追问 | 你至少要准备的 |
|---|---|---|
| 政务助手「分别统计意图路由准确率、Recall@K、引用完整率和任务完成率」 | 那这四个分别是多少？ | 要么给出四个数，要么改成「这四个维度分开统计」，别让人以为你有一套完整数据 |
| 知识库「支持失败重试、异常任务恢复」 | 入库失败率大概多少？失败最多的是哪一类文件？ | 一个量级 + 一个具体的失败类型（例如扫描版 PDF 解析失败） |
| BI「支持有限次数重试」 | 几次？超了怎么办？ | 具体次数 + 超限后的降级动作 |
| 客服「按工具成功率、失败类型做回归分析」 | 多久跑一次？谁看？发现过什么问题？ | 频率 + 一个真实发现的问题 |
| 各项目「SSE 流式输出」 | 首字延迟大概多少？ | 一个量级（秒级/百毫秒级）就行，别精确到毫秒 |
2. 口径详解：这几个指标必须能讲清
为什么要抠这么细
因为追问口径是面试官最省力的验证手段。他不需要看你的代码， 只要问「分母是什么」，三句话之内就能判断你是真跑过评测还是听说过这个指标。
2.1 Recall@5（检索召回率）
标准定义：对每个评测问题，看检索返回的前 5 条里，有没有命中「标准答案所在的那个 chunk」。
| 内容 | |
|---|---|
| 分母 | 评测集里的问题总数 |
| 分子 | top5 中至少命中一条标准 chunk 的问题数（这叫 hit rate 版本的 Recall@K） |
如果一个问题的标准答案分布在多个 chunk 里，还有一种更严格的算法： 分子取「命中的标准 chunk 数 / 该问题的标准 chunk 总数」再对所有问题求平均。 两种算法结果差别很大，你必须知道自己用的是哪种。
常见的错误算法：
- 用「答案对不对」当召回率——那是端到端准确率，跟召回混为一谈会被立刻问住。
- 只在文档级判命中（返回了正确文档就算命中）——比 chunk 级宽松得多，报出来的数会明显偏高。
- 评测集里的问题是拿文档内容让模型生成的，没有人工校验——这种评测集会系统性高估。
- 换了切分策略之后没重跑评测，拿旧数据说新版本。
面试官会追问的三个问题：
- 命中是 chunk 级还是文档级判定的？
- 评测集是谁标的，有没有第二个人复核？
- 这个数是哪一版切分策略、哪个 Embedding 模型跑出来的？
你需要准备的证据：评测集文件本身、跑评测的脚本或记录、至少一次「改了 X 之后这个数从 A 变到 B」的对比。 能说出一次对比实验，比记住一个数字有说服力得多。 原理见 rag-retrieval、agent-eval。
2.2 引用完整率 / 引用完整性
标准定义：回答里给出的引用，是不是「该给的都给了，给的都能对上原文」。
| 内容 | |
|---|---|
| 分母 | 需要引用的回答数（拒答的不算，闲聊类的不算） |
| 分子 | 引用齐全 + 每条引用都能在原文定位到 + 引用内容确实支撑了这句结论 |
这个指标最容易含糊的地方是**「完整」到底指什么**，至少有三层，越往下越严：
- 有引用（只要带了文档名就算）；
- 引用能定位（页码/条款能翻到）；
- 引用能支撑结论（翻到的那段话确实说了这件事）。
常见的错误算法：只统计第 1 层，然后当成第 3 层来讲。这在追问下会崩，因为面试官一定会问「那有没有引对但答错的情况」。
面试官会追问的三个问题：
- 抽检了多少条，谁判定的？
- 政务那个项目里，引用了一条已经废止的政策，算完整还是不完整？
- 有没有出现过「引用是对的但结论是错的」？
你需要准备的证据：抽检记录、判定标准的那几条规则、一个「引用格式改造前后」的对比。 原理见 rag-citation。
2.3 SQL 生成准确率
标准定义：自然语言问题转成 SQL 后，执行结果和标准答案一致的比例。
| 内容 | |
|---|---|
| 分母 | 评测集问题总数 |
| 分子 | 执行结果与标准结果一致的问题数 |
这个指标必须分层看，四层的数会一层比一层低：
| 层次 | 含义 | 你的数是哪一层？ |
|---|---|---|
| 语法通过率 | 生成的 SQL 语法合法 | 最宽松，基本没意义 |
| 校验通过率 | 过了白名单、只读、字段存在性校验 | 反映约束注入做得好不好 |
| 执行成功率 | 真的能在库上跑出结果 | 常被误当成「准确率」 |
| 结果一致率 | 结果和标准答案一致 | 这才是准确率，也是面试官默认理解的那个 |
常见的错误算法：
- 拿「执行成功率」当准确率报出去——SQL 跑通但口径选错、时间边界差一天，结果是错的。
- 评测集只有单表简单查询，多表 JOIN 没进去，数自然高。
- 允许多次重试后取最后一次成功的结果——那要说明是 pass@N 而不是一次通过率。
面试官会追问的三个问题：
- 你算的是执行成功率还是结果一致率？
- 多表 JOIN 那一类单独看是多少？（这题几乎必问，因为行业共识是 JOIN 明显更差）
- 允许重试吗？重试算不算成功？
你需要准备的证据：评测集的分类构成（单表/JOIN/时间/TopN 各多少条）、 分类别的准确率、以及一个典型失败案例和你怎么改的。原理见 agent-text2sql。
2.4 工具调用成功率
标准定义：Agent 发起的工具调用中，返回业务成功的比例。
| 内容 | |
|---|---|
| 分母 | 工具调用总次数 |
| 分子 | 返回业务成功的次数 |
这个指标的口径分歧点全在分母上，你必须明确三件事：
- 重试怎么算：一次调用失败重试两次才成功，是算 1 成功 1 失败，还是 1 成功 3 次调用？
- 参数校验失败算不算：执行前被 Pydantic 挡下来的，算不算一次失败的工具调用？
- 业务失败算不算：「订单不存在」是工具正常返回了正确结果，还是一次失败？
常见错误：把「HTTP 200」当成功。工具返回 200 但业务码是失败，这个数会虚高很多。
面试官会追问的三个问题：
- 重试计入分母吗？
- 「订单不存在」这种业务侧的正常否定结果，你归到哪一类？
- 失败里最大的一类是什么？（答不出这个，说明你没真看过日志）
你需要准备的证据：按工具维度的成功率分布、失败类型的 top3、一次因为分类重试而降低无效调用的改动。 原理见 agent-tool-calling。
2.5 任务完成率
标准定义：有明确任务意图的会话中，任务真正达成的比例。
| 内容 | |
|---|---|
| 分母 | 有明确任务意图的会话数（闲聊、打招呼不算） |
| 分子 | 任务达成的会话数 |
这个指标是四个业务指标里最主观的一个，因为「完成」需要定义。至少要区分这几类结局：
| 结局 | 算完成吗 | 说明 |
|---|---|---|
| Agent 独立完成 | 是 | 唯一无争议的一类 |
| 人工确认后完成（HITL） | 通常算 | 但要说明这是有人参与的完成 |
| 系统兜底转人工后完成 | 一般不算 Agent 完成 | 这类应该单独统计 |
| 用户中途放弃 | 不算 | 但要单独看，因为它反映体验问题 |
| 用户主动要求转人工 | 不算 | 和系统兜底转人工是两件事 |
常见错误：把上面五类粗暴地二分成「完成/未完成」，导致这个数既看不出问题在哪，也没法解释。 主动说出你当时的分类方式，比报一个漂亮的数字加分。
面试官会追问的三个问题：
- 「完成」是谁判定的——规则、模型还是人工？
- 用户自己要求转人工，你归到哪一类？
- 未完成里最大的一类原因是什么？
2.6 转人工率（以及所有 A → B 的对比数字）
标准定义：会话总数中，最终转给人工客服的比例。
| 内容 | |
|---|---|
| 分母 | 会话总数 |
| 分子 | 转人工的会话数（要区分用户主动要求 / 系统兜底触发） |
「从 35% 降到 18%」这类表述的真正风险不在两个数字本身，而在于「前后两个数是不是同一个口径」。 这是所有对比型数字的通病：
- 上线前的 35% 是老系统统计的，会话定义、统计窗口、是否含测试流量，都可能和新系统不一样。
- 上线后只在部分场景灰度，那 18% 是全量还是灰度部分的？
- 两个时间窗口的业务量级如果差很多（比如一个是大促期），对比本身就不成立。
面试官会追问的三个问题：
- 这两个数是同一套统计逻辑算出来的吗？
- 分别是哪段时间的？
- 有没有可能是因为覆盖场景变了，而不是效果变好了？
对比型数字的自保说法
如果口径确实不完全一致，主动说出来： 「这两个数不是完全同口径的，上线前是客服系统那边的统计，我们上线后用的是自己的会话日志， 所以我一般只把它当成一个方向性的参考，不当精确结论。」 这句话说出来，面试官对你的信任度是上升的。
2.7 响应时间 / 处理耗时
标准定义：必须说清三件事——测的是哪一段、用的哪个统计量、含不含哪些环节。
| 要素 | 选项 | 说明 |
|---|---|---|
| 测哪一段 | 首字延迟 / 端到端总时长 | 流式场景下这两个差别巨大，必须分开说 |
| 统计量 | 平均 / P50 / P95 / P99 | 少用「平均」，长尾会把平均值拉得很好看又没意义 |
| 含哪些环节 | 模型推理、SQL 执行、图表渲染、网络 | BI 场景里 SQL 执行经常占大头 |
常见错误：
- 只报平均值。有一半的请求慢到 40 秒、另一半 2 秒，平均 15 秒看起来很正常，但用户体验是崩的。
- 拿本地开发环境的耗时当线上数据。
- 流式场景报「总时长」而不报首字延迟——用户感知的是首字。
面试官会追问的三个问题：
- 是平均还是 P50？P95 多少？
- 这里面 SQL 执行 / 模型推理各占多少？
- 流式的首字延迟是多少？
3. 降级表述对照表
降级的原则
- 把精确度降下来，把过程说上去。 数字模糊一点没关系，「怎么测的」必须清楚。
- 只保留你能解释的。 说「大致八成以上」，前提是你能说出这个八成怎么来的。
- 说清用途。 「这套评测主要用来对比迭代效果，不是对外承诺的准确率」——这句话能救掉一半的追问。
| # | 原表述（示例值） | 降级表述 | 为什么这样说站得住 |
|---|---|---|---|
| D1 | 支持 6 个知识库 / 覆盖 3 个部门 | 「上线时接了几个业务方的知识库，主要是制度和项目资料两类；部门数我记得是三个左右，具体以当时后台为准」 | 强调「接了哪些类型」比数量更有信息量，而且不会被数字追问 |
| D2 | 3,200 份文档、28,000 个分块 | 「文档量在千级，分块是万级；单份最大的是几十兆的扫描 PDF，这类解析最费劲」 | 量级 + 一个具体的技术难点，重心从规模转到能力 |
| D3 | 120 / 200 / 180 条评测样例 | 「我们建了一个百条量级的标注评测集，按问题类型分了几类，主要用来做策略对比」 | 「百条量级」是安全表述；分类构成才是面试官真想听的 |
| D4 | Recall@5 达到 86% | 「用一百多条标注样例做过检索评测，top5 的命中率大致在八成以上。这套评测主要不是为了对外报数，是用来对比切分策略和融合策略的迭代效果——比如换成按标题层级切之后，这个数明显往上走了一档」 | 给了量级、口径、用途和一次真实对比，比一个精确数字更可信 |
| D5 | 引用完整性 91% / 引用完整率 93% | 「我们做过人工抽检，绝大部分回答的引用都能定位到原文；剩下的问题集中在跨页表格，页码会对不上」 | 用「绝大部分」+ 一个具体失败模式，展示你真的检查过 |
| D6 | 10 分钟 → 2 分钟 / 小时级 → 分钟级 | 「业务方的反馈是原来查一份制度要翻半天，现在基本上一次问答就能定位到条款。这个我没有严格计时，是他们的主观反馈」 | 主动标注「这是主观反馈」，把定性数据放回定性的位置 |
| D7 | SQL 生成准确率 89% | 「在我们自己的评测集上，单表和简单聚合的结果一致率明显更高，多表 JOIN 会掉一截。我更关注的是校验拦截率——不合法的 SQL 一条都没跑到库上」 | 承认 JOIN 弱是行业共识，反而显专业；把落点换到你真正做的安全校验上 |
| D8 | 平均问数响应 15 秒 | 「秒级到十几秒，主要取决于 SQL 本身跑多久；模型这块开销是比较稳定的一部分」 | 给区间 + 指出瓶颈来源，比一个平均值更像做过性能分析的人 |
| D9 | 60% → 20% / 35% → 18% | 「上线之后简单的取数需求基本不进数据组了，剩下的是复杂口径的。前后两个数不是同口径统计的，我只当方向性参考」 | 主动声明口径不一致，把风险点自己先说掉 |
| D10 | 工具调用成功率 94% | 「工具调用的失败我是按类型看的，主要是超时和参数校验不通过两类。把可重试和不可重试分开之后，无效重试少了很多」 | 用「失败类型分布」替代「成功率」，信息量更大也更难被问倒 |
| D11 | 任务完成率 86% | 「我们把结局分成 Agent 独立完成、人工确认后完成、兜底转人工、用户放弃几类分开统计。当时独立完成的占大多数，兜底转人工主要出在退款这类需要人工确认的流程上」 | 分类口径本身就是答案，比一个合成指标更能证明你想清楚了 |
| D12 | 日均 1,500 次会话 | 「日均千级会话，工作日明显高于周末；不算内部测试流量」 | 量级 + 一个分布特征 + 一个排除项，听起来就是看过真实数据的人 |
4. 反面警示：编一个数字，是怎么在三分钟里崩掉的
下面这段推演不是夸张，这是技术面里最标准的一套追问节奏。假设你保留了「Recall@5 达到 86%」。
现场推演
面试官（第一层，问口径）：你这个 Recall@5 的 86%，分母是什么？
你：呃……就是评测集里的问题数，120 条。（还行，这层能答）
面试官（第二层，问判定标准）：那「命中」是怎么判的？你标注的是标准答案文本，还是标准 chunk 的 ID？ 如果一个问题的答案跨了两个 chunk，只召回一个算命中吗？
你：……应该是只要召回到相关的就算。（开始含糊，「应该是」这三个字已经暴露了）
面试官（第三层，问证据链）：这个 86% 是哪一版跑出来的？ 你前面提到后来把固定长度切分改成了按标题层级切，那这个数是改之前的还是改之后的？改完之后变了多少？
你：这个我记不太清了，大概……差不多这个水平。（崩了）
面试官（收尾，不再问数字了）：好，那我们换个话题。
注意最后那句话。 面试官不会当场指出你在编，他会直接换话题——因为他已经得到结论了。 这个结论是：这个人简历上的数字不可信，所以他简历上的技术描述也要打折听。
后面会发生三件事，你在现场察觉不到：
- 他不再深挖你的技术亮点了。 既然数据存疑，深挖的性价比就低了，剩下的时间他会问些安全的通用问题。
- 你其他真做过的东西也被连带质疑。 你说你做了 HITL、做了权限下推——这些都是真的， 但在「数据存疑」的滤镜下，它们会被默认理解成「大概接触过」。
- 评价里会出现一句你看不到的话：「项目经历有包装，深度待验证。」
对照一下，如果一开始就用降级表述
你：「我们建了一百多条标注样例做检索评测，top5 命中率大致在八成以上。 这套评测主要是用来对比策略迭代的——比如切分从固定长度改成按标题层级之后，这个数明显往上走了一档。 不过我要说明一下，这不是一个严格的对外指标，标注是我们自己做的，量也不大。」
面试官接下来会问什么？ 他会问「那你切分具体怎么改的」—— 这正好是你最能讲的部分。降级表述不但没让你掉分，还把话题引到了你的强项上。
5. 诚实但不吃亏的表达技巧
核心思路只有一句：用「我知道该怎么测」换掉「我记得那个数」。
面试官真正想验证的从来不是你记性好，而是你有没有量化意识、知不知道口径的坑在哪。 这两点用下面这些句式都能证明，而且不需要任何精确数字。
| 场景 | 可以这样说 | 为什么不掉分 |
|---|---|---|
| 数字记不精确 | 「精确数我记不住了，量级是 XX 级。要不要我说一下这个指标我们当时是怎么算的？」 | 主动把话题从「记性」转到「方法」，而方法才是能力信号 |
| 口径当时定得不严 | 「说实话我们当时的口径定得比较粗，只分了完成和未完成两类。现在回头看应该把用户放弃和兜底转人工拆开。」 | 承认不足 + 给出改进思路 = 反思能力，这是加分项 |
| 数据是别人统计的 | 「这个数是业务侧给的，我这边只能确认我们日志里的部分。」 | 划清边界，比含糊地把别人的成绩说成自己的安全得多 |
| 只有定性反馈 | 「这块我没有严格测过，是业务方的主观反馈，我一般不把它当指标用。」 | 主动降级自己的数据，是可信度最高的一种表达 |
| 完全没测过 | 「这块我们当时没有量化，主要靠人工抽查。如果重来我会先建一个几十条的 golden set 再动手。」 | 没测过不是罪，不知道该测什么才是 |
| 被追问细节到底 | 「这个细节我确实记不准了，我不想编一个数给你。我能确定的是 XX 和 XX。」 | 「我不想编一个数给你」这句话本身就是强信号 |
三条不要
- 不要在数字上硬撑。 一旦开始说「大概」「应该」「差不多」，就立刻切到降级表述，别再往下编。
- 不要过度道歉。 说一次「这个我记不精确」就够了，反复道歉会把一个小问题放大成印象问题。
- 不要在被追问后临时改口径。 第一次说 120 条第二次说 200 条，比一开始就说「百条量级」糟糕得多。
最后一句
这份文件填完之后，回去改简历。 主表里凡是走了路径 B 或 C 的，简历上对应那句话就得改。 改完再回到 10-口述稿，把 <待核实> 换成你最终定稿的说法，然后才开始背。