版本管理发布记录教程：跨部门团队实操方法，避坑指南

版本管理发布记录教程：跨部门团队实操方法，避坑指南

同一版本上线后，客服拿到的更新说明、销售发给客户的版本承诺、研发提交的变更清单，常常不是同一份内容：客服说“已支持批量导出”，实际只对部分租户开放；销售说“周五发布”，但审批还没完成；研发则认为代码早已合并，发布记录已经写完。跨部门团队真正需要管理的，不只是“这次改了什么”，而是每一项变更的状态、影响范围、责任人和对外口径。本文给出一套从需求进入、变更评估、发布审批到上线后复盘的操作方法，并用明确标注的情景模拟数据演示如何落地。

一、先讲核心结论：发布记录不是版本说明，而是变更的共同事实源

1. 先分清“版本管理”和“发布记录”

版本管理解决的是产品如何被切分、识别和追溯，例如版本号、分支、构建产物和发布日期。发布记录解决的是一次交付发生了什么：哪些能力上线、哪些缺陷修复、哪些用户受影响、哪些事项延后，以及谁确认了这些信息。

两者有关联，却不能互相替代。版本号写得规范，不代表客户知道自己是否受影响；发布记录写得很长，也不代表研发能追溯变更对应的提交、需求和测试结果。我更倾向于把版本号当作“地址”，把发布记录当作“可审计的变更账本”。

2. 一条记录至少要回答六个问题

• 改了什么：用用户或业务能理解的话描述结果，不只复制技术提交说明。
• 为什么改：指出对应需求、客户问题、风险整改或合规要求。
• 谁会受影响：明确用户角色、租户范围、地区、端、权限或数据边界。
• 何时生效：区分计划时间、实际发布时间和分批开放时间。
• 如何验证：列出测试结果、监控信号、验收条件或回滚触发条件。
• 谁负责后续：确定产品、研发、测试、运维、客服或客户成功的责任人。

这些字段不是为了把表格做复杂，而是为了减少“发了但没说清”“说了但没上线”“上线了却找不到责任人”三类返工。团队规模越大、发布频率越高、客户差异越明显，信息缺失的代价越高。

3. 发布记录应有三个视图，而不是三份互相冲突的文档

同一项变更通常需要服务三类读者：研发与测试需要追溯依据，内部业务团队需要理解影响和准备事项，客户需要快速知道功能变化与使用方式。正确做法不是让三组人各自维护一套事实，而是建立一份结构化记录，再按受众生成不同视图。

我的判断标准很简单：如果一个字段在发布后可能改变客服回答、客户操作或回滚决策，它就应该有明确来源和责任人；如果一个字段仅仅让记录看上去更专业，却不会改变任何决策，它不一定要成为必填项。

二、跨部门发布为什么容易失控：问题通常出在交接处

1. 同一项变更会经历多次“翻译”

一项改动从需求提出到客户使用，至少会经过产品、研发、测试、运维和业务沟通等环节。产品写“提升导出效率”，研发拆成异步任务和队列调度，测试关注边界条件，客服要知道失败时如何指导用户。每次翻译都可能丢失一个关键限制。

典型例子是功能开关。研发确认代码已部署，业务人员就把它理解为“所有客户都能用”；实际情况可能是只对试点租户开放，或需要管理员主动启用。于是，所谓“版本发布完成”可能只代表程序已部署，并不等于功能对全部用户可见。

2. 版本日期、上线日期和生效日期经常被混为一谈

跨时区 SaaS、分批部署、移动端应用商店审核和企业客户私有部署，都可能让同一个版本有多个时间点。版本构建完成时间、生产环境部署时间、功能开关开启时间、客户实际可用时间，分别对应不同事件。只写一个“发布日期”，容易在客服解释和事故追溯时制造歧义。

因此我建议给时间字段加上语义，而不是只记录一个日期。对于滚动发布，写“开始分批部署时间”和“预计全量完成时间”；对于开关控制，写“部署完成时间”和“功能启用范围”；对于客户自行升级的交付模式，则注明“可下载时间”与“客户实际升级时间”。

3. 部门目标不同，信息缺口也不同

研发最关心变更是否可追溯、是否可回滚；客服最关心用户会问什么、如何判断是否受影响；销售最关心承诺是否兑现；安全与合规团队关心数据处理、权限和审计变化。若记录只围绕研发提交列表设计，其他部门只能在发布前临时追问。

这种追问不是协作态度问题，而是记录结构没有覆盖决策场景。减少沟通不能靠“多开一次会”，而要把容易导致误解的字段提前写入流程，确保每个团队在需要信息时能找到同一版本的答案。

4. 用小型流程图代替口头猜测

对于跨部门发布，我会先要求团队把“代码进入生产”与“用户获得能力”画成两个节点。两者之间若存在租户筛选、权限配置、客户端升级、数据迁移或人工操作，就要明确执行人和确认方式。

三、常见误区：记录写得多，不等于发布管理做得好

1. 把提交日志直接复制成发布说明

提交日志适合研发追溯，通常包含代码模块、实现细节或内部简称。客户需要的是“在哪个场景下能做什么”，而不是“重构了某服务的分页接口”。复制提交信息会把技术事实误当成用户价值，还会让重要限制淹没在细节中。

改写时不必夸大功能，只需把主语换成用户任务，并补足适用边界。例如，不要写“优化导出模块”；写“管理员现在可以按部门筛选成员后导出名单，最多支持一次导出两万条记录；超出范围时请分批导出”。

2. 把“开发完成”误认为“发布完成”

代码合并、测试通过、生产部署、功能开放、用户可用，是不同状态。一个项目如果只设置“进行中”和“已完成”，很容易把未做完的迁移、文档、开关确认和支持准备挤到“已完成”之前，发布记录便失去判断价值。

我通常把状态拆成“待评估、已纳入、开发中、待验证、待发布、分批发布、已全量、已回滚、已取消”。不必在每个工具里照搬全部状态，但至少要能区分“工程完成”和“用户可用”。

3. 用一个版本号承载所有发布节奏

周更、紧急修复、移动端发版和客户独立升级，可能采用不同节奏。若强行用单一编号表达所有产品形态，团队会在版本号里塞进发布日期、渠道和环境信息，最终变成只有原作者看得懂的暗号。

语义化版本规范适用于需要明确表达兼容性影响的场景，常见形式为主版本、次版本和修订版本。但它并不能自动解决“这项功能对谁开放”或“客户何时获得”的问题。版本号策略应该由发布模式决定，而不是为了看起来整齐而追求统一。

4. 把延期变更从记录里删掉

延期项不是“没发生”，而是发布计划发生变化的证据。若删除延期记录，内部人员无法解释承诺变动，后续也很难看出估算偏差来自依赖、需求变更、质量问题还是审批等待。

更好的做法是保留原计划版本、实际去向、延期原因、重新评估日期和对外沟通状态。写原因时避免只写“资源不足”；进一步区分关键人员冲突、上游接口未交付、测试数据不可用或风险评审未通过，才有改进价值。

5. 一味追求“零缺陷记录”

发布记录不是营销稿，也不是团队绩效海报。若只留下成功项、不记录已知限制和回滚信息，表面上更好看，实际却会让支持人员无法预判用户问题。诚实记录限制不是削弱产品，而是帮助用户做正确选择。

对外说明可以按风险分层：普通使用限制明确展示；安全敏感或尚未确认的内部细节不公开；影响客户决策的重要问题，则由产品和支持团队共同审核措辞与通知范围。

四、专业判断逻辑：怎样设计一条真正能用的发布记录

1. 先定义记录对象，而不是先挑工具

开始配置表单之前，先决定团队记录的对象是什么：一个版本、一次部署、一个功能变更，还是一次客户可见的发布事件。对象定义不清，工具字段很快会重复。例如，一个版本包含多次分批部署，就不适合把每次部署时间塞入单一版本记录；一个客户专属热修复，也不应伪装成所有客户统一可用的版本。

我建议把“变更项”作为基础对象，把它关联到版本、部署批次和发布公告。变更项描述具体内容；版本聚合本次交付；部署批次记录环境与时间；公告面向特定受众。这种拆分让一个变更可以对应多个客户批次，也允许同一版本形成内部和外部两种呈现。

2. 让字段服务于决策，避免“字段越多越成熟”

字段可以分为三层。第一层是追溯必需项，如变更编号、来源、责任人、版本和状态；第二层是发布判断项，如影响范围、兼容性、测试结论、回滚方式；第三层是特定场景字段，如数据迁移窗口、监管审批号、客户通知批次。

不同团队的必填字段不应完全相同。普通文案调整不需要迁移计划；涉及权限模型的变更则不能没有安全评估和验证记录。可以采用“按变更类型触发字段”的方式，而不是所有字段无差别必填。

3. 用风险等级决定审核强度

我不会让所有变更走同一套审批。低风险、可逆、影响范围小的修复，可以使用轻量审核；涉及数据结构、权限、计费、外部接口或大规模用户体验变化的事项，需要增加专项确认和回滚演练。审批的目标不是收集更多签名，而是确认关键风险已经有人评估。

4. 建立发布门槛，而不是依赖“感觉差不多”

每个团队可以有不同门槛，但必须清楚写出触发条件。比如：未关联需求或缺陷，不进入版本；没有测试结论，不进入待发布；回滚方案未确认，高风险变更不得全量；客户可见说明未审核，不向外发送公告。这些门槛应能被团队实际执行，而不是写进流程后无人检查。

对于中大型组织，可借助某项目管理平台把需求、缺陷、测试任务、发布版本和责任人关联起来。以 PingCode 这类面向中大型企业及百人以上组织的协作场景为例，配置时应先验证团队是否能把项目对象、状态与审批责任串起来，再决定是否启用更多字段和自动化。选工具不是先看功能列表有多长，而是看跨团队追溯是否顺畅、权限是否符合组织边界、维护成本是否可承受。

5. 让审核人确认事实，不让审核人代替作者写记录

常见流程设计把发布说明交给最后一位审批人“把关”，结果审批人既要查数据又要改文案，责任不清、等待时间变长。更有效的分工是：变更责任人提供事实，产品确认用户价值和范围，测试确认验证结论，运维确认部署与恢复条件，沟通负责人确认对外表达。

审批人不必逐字润色所有记录。他应检查自己负责的事实是否正确、风险是否可接受、缺失项是否会影响决策。这样既能保留责任链，也能避免把发布审核变成无止境的文案往返。

五、实操流程：从需求进入版本到上线后关账

1. 需求进入时先做“可发布性”登记

许多团队到发布前才第一次整理变更，导致影响范围、限制条件和验收方式只能临时追问。我的建议是在需求进入开发阶段时就建立最小记录：变更类型、业务目的、受影响角色、依赖项、验收标准和初步风险。此时信息可以标为“待确认”，但不应完全缺席。

（1）入口登记的最小字段

• 唯一编号及来源链接，避免同一事项在不同文档中出现多个名字。
• 业务目的与用户任务，说明解决的问题，而非预先写营销结论。
• 变更分类：新功能、改进、缺陷、安全、合规、运维或弃用。
• 潜在影响范围，包括角色、端、租户类型、地区和权限条件。
• 验收条件和依赖方，避免“完成”只有主观解释。

2. 开发中维护状态和范围变化

开发过程中，需求范围可能因技术发现而变化。不要把变更都压到上线前统一整理；应记录新增、删除或延期的事项，以及发生变化的原因和批准人。若一个功能从“所有管理员可见”变成“仅企业管理员可见”，这是影响发布说明和培训的实质变化，不应只留在聊天记录里。

对于多人协作，建议规定更新责任：任务负责人更新工程状态，产品负责人确认用户影响，测试负责人更新验证结论。记录时间不必追求实时逐字更新，但关键状态改变时应同步，避免“临近发布才发现记录仍是旧口径”。

3. 发布前做一次“事实冻结”

发布窗口前需要一个明确的事实冻结点：本次包含哪些变更、哪些已排除、哪些仍有风险、谁负责执行、何时开始观察。冻结不等于绝不允许变更，而是要求任何新增或移除都有明确的重新评估，不允许在口头上悄悄改变发布范围。

（1）发布前检查清单

• 纳入版本的每项变更都有关联编号、负责人和状态。
• 测试结果与适用环境一致，关键路径有可复现的验证记录。
• 发布范围、租户条件、功能开关和用户可见时间已经确认。
• 数据迁移、兼容性和外部依赖均有负责人及失败处置方式。
• 内部支持人员拿到可用说明，客户公告经过相应审核。
• 回滚或降级触发条件明确，不以“必要时处理”代替执行标准。

4. 发布时记录“发生了什么”，不要只保留计划

计划时间是预期，实际时间才是事实。发布执行人应记录开始、完成、暂停、恢复和回滚等事件，并关联环境、批次、部署版本和操作人。若发生延期，记录原因与新时间；若只对部分用户开放，写清批次和判定规则。

发布期间最实用的字段不是“发布成功”四个字，而是成功的定义：服务健康检查通过、核心业务链路完成验证、错误率没有超过团队阈值、首批用户可访问，还是所有客户均已开放。不同定义对应不同责任，必须在发布前约定。

5. 上线后留出观察和关账时间

发布动作完成，不意味着记录立即关闭。团队需要观察核心指标、处理用户反馈，并将发现的问题关联回对应版本。关账时确认实际影响范围、遗留问题、回滚情况和客户沟通是否完成。没有反馈也可以记录“观察窗口内未发现指定异常”，但要说明观察时长与检查指标。

发布后复盘不必每次开会。低风险变更可以由责任人补齐记录；高风险、发生回滚或客户影响明显的变更，才需要跨部门复盘。复盘聚焦可改进的流程原因，而不是把事故写成某个个人“忘了做”。

六、具体案例与数据观察：用一个模拟发布验证字段是否够用

1. 场景设定：一项导出改进，实际包含三个不同决策

以下是情景模拟，不代表某家企业的真实运营数据。假设一家约 300 人的 B2B 软件团队准备上线成员名单批量导出：产品希望减少管理员逐页复制；研发实现异步导出；测试发现超大范围导出会排队；客服担心用户把“提交导出任务”误解为文件立即生成；销售则已经把“周五可用”写进客户沟通。

如果发布记录只有“增加批量导出”，至少遗漏四个关键事实：哪些角色可以操作、单次处理上限、文件何时生成、未完成时用户去哪里查询。它们不只是文案细节，而是决定客户是否能成功使用功能的操作条件。

2. 把同一变更拆成事实、影响和表达

我会把这项变更记录为一个工程事项，再拆出与发布决策有关的子信息。工程事实由研发和测试确认；可见范围由产品确认；客户话术由支持与客户成功确认。销售不能单独确定发布日期，研发也不应单独决定对外承诺。

3. 为什么不能用一个“发布成功率”概括结果

假设试点阶段观察 10 个工作日，内部记录中有 120 个导出任务，114 个成功、6 个失败。这只能说明任务层面的结果，不能直接推断 95% 的用户都能顺利完成操作：同一管理员可能重复提交多次，样本也可能集中在少数租户。要判断体验，至少还要看独立使用者数、失败原因分布、任务耗时和支持咨询量。

比如 6 次失败中，若 4 次来自超过上限、2 次来自权限配置，优化方向完全不同。前者可能需要更清晰的限制提示或分批操作建议；后者可能是权限模型、配置文档或授权流程的问题。记录的价值不是把一个数字放进周报，而是让数字可以追到具体情境和可行动的原因。

4. 用假设数据展示如何做判断，不冒充真实基准

下表为情景模拟的观察结果，用来示范团队该如何记录口径。它不代表行业平均水平，也不应直接作为绩效目标。若团队实际使用，应标明统计周期、去重规则、试点范围和数据来源。

5. 发布说明示例：把技术事实写成用户可执行的信息

内部追溯记录可以保留实现细节，但对外说明应优先写清适用人群、操作位置、限制与异常处理。不要把“已经上线”写成所有用户都能使用，尤其在灰度期间，公告必须说明开放范围或生效条件。

成员名单批量导出

企业版管理员可在成员管理页面筛选成员并发起导出。系统会在后台生成文件，完成后可在导出任务列表中下载。单次最多处理两万条记录，超出时请分批导出。该能力目前先对指定试点租户开放；如页面暂未显示入口，请联系管理员或客户支持确认开通状态。

这个版本不夸大速度，也没有隐藏试点范围。它把用户最可能遇到的问题提前回答了：谁可以用、去哪里操作、文件何时出现、数量上限是多少、找不到入口怎么办。若这些信息还没有确认，就应将公告标为待审核，而不是用含糊措辞抢先发布。

七、不同规模、发布模式与风险下的行动建议

1. 小团队：先建立轻量事实源

十几人团队通常不需要复杂审批链。可以用一个共享版本页面或项目工具建立变更清单，至少维护负责人、来源、变更说明、状态、发布日期和风险。关键不是工具是否先进，而是每次发布结束后能回答“谁做了什么、哪些用户受影响、出问题时如何定位”。

小团队适合把维护动作嵌入现有例会或发布检查中，而不是再设一个独立会议。低风险发布由负责人确认，高风险变更才拉相关人评审；如果字段长期无人更新，先删掉无用字段，而不是继续增加提醒。

2. 中大型组织：把记录关联到组织责任，而非个人记忆

百人以上组织常有多个产品线、业务单元、区域或客户交付方式。此时需要稳定的对象关联、权限控制、变更审批和统一查询，否则跨部门协作会依赖“找熟人问一下”。可以用某项目管理平台建立统一索引，并按团队差异配置表单和状态。

以 PingCode 这类面向中大型组织及百人以上团队的项目管理场景为例，适合重点评估需求、缺陷、测试、版本与责任人的关联能力，以及不同部门查看信息的权限边界。具体配置应以当前产品能力和组织流程验证为准，先选一条真实发布链路试运行，再决定扩大范围，避免把工具上线等同于管理问题已经解决。

3. SaaS 持续交付：把“部署”和“开放”分开记录

持续交付团队可能每天部署多次，但用户感知的功能变化由开关、租户配置或分批策略控制。建议保留部署批次、代码或构建标识、功能开关状态、开放范围和观察结果。对外发布说明不一定每次部署都发布，但面向用户的变化必须能追溯到相应记录。

如果不同客户看到的功能不同，公告要说明适用条件，内部支持视图则需要可查询某租户的当前状态。不要为了让版本号整齐而隐去差异，也不要把所有开关变化都当作普通技术细节。

4. 私有化交付：把客户环境差异变成明确字段

私有化部署中，同一产品版本可能因客户环境、插件、数据库版本或升级窗口而出现不同结果。发布记录要包含最低依赖、兼容性说明、升级步骤、备份要求、回退方法和已验证环境。客户是否已经升级，应记录为客户环境状态，不能仅凭产品包发布就推断。

在这类场景里，支持团队需要按客户环境追踪版本，而不是只查一个全局版本表。若升级由客户自行执行，应明确由谁确认升级完成、出现问题如何采集信息、哪些操作可能影响数据，避免把内部发布时间误作客户生效时间。

5. 高风险变更：少追求速度，多确认恢复能力

数据迁移、身份认证、计费规则、权限调整和外部接口变更，不能只用“测试通过”作为全量发布条件。需要关注备份可恢复性、兼容窗口、观察指标、停止条件、回滚影响和业务联系人。若变更无法真正回滚，应准备前向修复方案，并在记录中清楚标注。

高风险不意味着所有事项都要经过高层审批。应让真正能判断风险、能执行恢复的人参与决策，并把确认事项具体化。例如，“运维已确认”不如“已在预发布环境验证恢复流程，恢复校验由某责任角色执行”更可核查。

八、工具、指标与取舍：自动化能减少漏项，不能替团队作判断

1. 先用低成本方式验证流程，再决定是否自动化

如果团队还不知道变更记录由谁维护、哪些字段有用，直接搭建复杂工作流只会把混乱固化。先选最近一次真实发布，用表格或现有项目系统跑完整个流程；观察哪些字段反复缺失、哪些审批没有改变结论、哪些信息被不同部门重复填写。两三个周期后，再自动化稳定且高频的部分。

自动化适合做字段提醒、状态同步、版本归档、公告草稿生成和变更关联检查；不适合替人判断业务影响、风险可接受性或客户是否应该被通知。尤其是生成式工具参与文案整理时，必须要求它只基于已确认字段改写，并由负责人核对范围、数字和承诺。

2. 工具选型看“追溯链”与“维护负担”

选择工具时，我会拿一项真实变更做演练，而不是只看功能演示。要求从需求跳到测试结论，再到版本、部署记录和对外说明；同时检验是否能看出责任人、最新状态和客户适用范围。若需要复制多次数据、依赖特定人员维护、权限过于粗糙，工具功能再丰富也可能难以持续。

3. 指标应连接决策，不要只追求漂亮的周报数字

发布管理可以观察记录完整率、发布延期原因分布、从代码完成到用户可用的等待时间、发布后回滚次数、支持咨询量和变更关联完整度。指标都需要清楚口径：按版本、变更项、任务还是客户统计？按自然日还是工作日？按所有发布还是高风险发布？口径不一致，趋势图只会放大争论。

不建议把“记录完整率”单独用于绩效。团队为了达到目标，可能把字段填满却不提高信息质量。更有用的做法是联合观察：缺字段是否导致审批退回，公告修改是否导致客户误解，延期原因是否反复集中在相同依赖，回滚后是否能快速确定受影响范围。

4. 建议设置的几个度量口径

• 发布记录完整率：发布时必需字段齐全的变更项数 ÷ 本次纳入变更项总数。
• 影响范围确认率：具有明确角色、租户或适用条件的变更项数 ÷ 需要范围判断的变更项总数。
• 发布后问题关联率：能够关联到具体版本或变更项的问题数 ÷ 发布后发现的相关问题总数。
• 发布准备提前量：对外说明首次完成审核的时间与实际开放时间之间的间隔，按工作时长统计。
• 状态偏差率：记录为“已全量”但抽查发现仍未对目标用户生效的发布项比例。

这些指标没有通用的合格线。新流程初期，重点是找出缺失模式；稳定运行后，再结合业务风险和历史表现设定目标。若某团队一年只有少量大版本，不应照搬高频 SaaS 团队的发布节奏指标。

九、最后的避坑清单：从一项变更开始，逐步形成团队习惯

1. 先选一个真实发布做试运行

不要先花几周设计完美模板。挑一项跨部门参与、风险适中、近期要交付的版本，按本文的字段记录一次。发布后找研发、测试、客服和产品各问一个问题：哪条信息帮你做了决定？哪条信息缺失导致你再次追问？哪些字段根本没有人看？答案比模板评审会上“看起来很全面”更有价值。

2. 试运行时只盯三个结果

• 用户可见范围能否被准确说清，是否有人把计划当成已上线。
• 发布异常能否定位到对应变更和责任人，是否需要到聊天记录里找线索。
• 客服与业务团队能否在发布前拿到可执行说明，是否仍需临时口头补充。

若这三件事有所改善，再讨论更细的指标和自动化。如果表单填写率提高了，但仍然答不出用户是否受影响，说明流程改善的是形式，不是决策质量。

3. 明确维护责任和关闭条件

每个版本要有一位发布负责人，负责收集完整性、组织关键确认和关闭记录；但每个事实仍由最接近事实的人负责。研发不替客服定义客户话术，产品不替测试确认覆盖结果，销售不替发布负责人宣布全量开放。

关闭条件至少包括：实际发布时间已更新，实际影响范围已核实，发布后问题已关联，待办和延期项有去向，对外沟通已完成或明确无需沟通。只有“部署完成”而没有这些收尾信息，版本仍然处于未关账状态。

4. 每季度回看一次“流程有没有制造新成本”

流程建立后也要定期检查。若一个审批长期只增加等待、不改变风险判断，应缩短或取消；若某个字段每次都要人工从其他系统抄来，应考虑自动关联；若客户范围差异是事故常见原因，则应提升其记录和审核优先级。流程不应该因为最初设计得完整，就永久保持不变。

团队成熟的标志不是所有发布都经过同样多的表单，而是能根据变更风险调整控制强度，同时不丢失追溯能力。能快速发布，也能准确说明；能及时暂停，也能在事后说清发生了什么，才是有效的版本管理。

5. 下一步行动：在一周内完成最小闭环

1. 选定一个近期发布，列出所有纳入和延期的变更项。
2. 为每项变更补上来源、负责人、影响范围、验证结论和用户可见状态。
3. 把计划发布时间、实际部署时间与用户生效时间分开记录。
4. 让客服或业务人员用发布记录回答“谁能用、怎么用、有哪些限制”。
5. 发布后复核异常、咨询和回滚信息，并删除或调整没有决策价值的字段。

版本管理发布记录最容易被误解成一项文档工作，实际上它是一套跨部门共享事实的机制。我的核心判断是：记录是否优秀，不看写了多少字段，而看它能否让不同角色在关键时刻基于同一事实做出一致行动。先把变更、状态、范围和责任连接起来，再根据组织复杂度选择工具与自动化；下一次发布，就从一条能被研发追溯、能被客服解释、也能被用户正确使用的记录开始。