技术口述改写

把技术知识改写成工程师能直接说出口的回答：用自然的因果句讲清问题、处理办法和限制。主答方便记忆，详细机制仍有查阅入口。

先读 认可的示例 理解表达尺度。需要调用外部模型或批量更新题库时，再读 模型与批量处理。

工作方法

从事实重新组织

不要沿着原文逐句换同义词。先提取技术事实，再根据问题重写答案。

把材料分成两部分：

• 主答必须讲清：直接回答题目的机制、原因、处理办法，以及省略后会改变结论的条件。
• 适合追问展开：完整字段、参数、算法目录、版本矩阵、代码和测试细节。题目本身就在问某个参数或版本时，它仍属于主答。

原资料有错误或关键前提不明时，先核实或明确标注，不把疑点改写成确定结论。缺少事实就保留未知，不补造个人经历、实现能力和性能数字。

按问题组织口述

开头直接回答具体技术问题，随后解释为什么这样处理、在哪些条件下有效。不要统一套用“背景—挑战—方案—收益”或每题都分成相同的三点。

一般用两三段短段落，约 200–450 个汉字；复杂架构题可适当增加，简单题可以更短。每段说明一个具体问题，长度服从信息需要，不为凑字数增加结尾总结。

优先使用具体动作：谁读取什么、请求到哪里、状态怎样更新、失败后怎样处理。必要术语保留，能够用熟悉表达讲清的地方减少抽象名词和缩写堆叠。例如“同时有多少调用还没结束”，往往比反复说“在途资源约束”更好记。

保持技术表达自然

只讲技术，不用比喻、段子、刻意语气词，也不把答案改成泛泛的生活化解释。

避免用“首先、其次、最后”“核心在于”“本质上”“形成闭环”“赋能”“兜底”等固定连接词组织整篇。删掉“回答时要注意”“可以从以下几个维度展开”这类讲义和点评语气，直接写回答本身。

主答以连贯文字为主；大量字段、配置清单、代码和表格放到技术参考。不要为了减少术语而删掉决定行为的 API、状态或条件。

校对含义，再校对语气

逐题核对改稿是否仍然准确表达原事实，尤其检查：

• 条件、作用范围、时序、阈值、所有权和协议版本有没有被改变。
• 机制成立是否需要额外前提，有没有从“可以”变成“一定”。
• 接受请求、写入成功、业务完成是否被混为一谈。
• 建议设计是否被写成亲自上线过的事实。

用“能否顺着因果说出来”判断可读性，不用“是否足够随意”判断口语化。只有换词、换标点而大部分原句未变时，应回到事实重新组织。

交付方式

少量试稿直接展示题目与新主答。详细追问按任务需要附后；用户只看效果时，不必同时输出事实卡、提示词和完整原文。

修改现有题库时，保留题号、来源、代码和关键技术参考，把认可的主答放在主要阅读位置。不要因为调整措辞顺手改变学习优先级、删除题目或重写历史评分记录。

遵循当前任务已授权的保存、替换和发布范围。试稿不自动变成全库替换；用户已授权全量修改时，按项目规则完成生成、校验和发布，不重复请求确认。