建立 Python API 的参数、边界、异常和数值对比测试矩阵，按项目支持范围选择运行环境，并保留真实测试证据。
## 任务目标 请为本次指定的 Python 接口补齐有意义的测试并完成验收。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 待补测试接口：优先选择对话中的接口、当前改动影响的公开函数或已失败用例；未给缺陷时按已有调用契约补齐正常、非法参数和关键边界测试。 接口或测试资料：读取目标模块、调用方、docstring、现有测试、依赖与运行矩阵，从实际实现和业务说明提取可观察行为。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 对照函数签名、实现分支和调用方确认默认值、空值、返回结构及异常约定。 - 检查已有测试遗漏、缺陷复现和独立参考结果，确定数值精度或金额计数规则。 - 读取最低 Python 版本、测试命令及设备条件，仅对实际 Paddle 接口识别动态图、静态图或梯度要求。 ### 可采用的默认处理 - 沿用现有测试框架和支持矩阵，以业务承诺为单位新增用例，不追求无意义的行数或组合数量。 - 没有性能或数值容差依据时不设置任意门槛；确定性计数、字段及异常先做精确断言。 - 随机和时间相关场景固定可控条件，测试用临时资源并隔离副作用，不污染生产数据。 ### 必须有依据的事项 - 业务或数学定义缺失，导致数值期望、合法范围或误差阈值没有可信依据；不能用被测实现反算期望来证明自己正确。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 缺设备时仍补齐可检查测试代码和输入矩阵，将设备相关用例注明待运行。 - 缺接口实现时按已知契约给出用例及断言设计，单列无法确定的数值期望，不伪造执行结果。 ## 执行要求 按接口实际支持范围确定测试要求。针对 Paddle API 时核对相应运行模式、硬件和精度；普通服务仅采用适用的参数、边界及断言原则，不强加飞桨特定的覆盖率、梯度或耗时门槛。 1. 先列出接口可观察行为、输入约束、输出结构和异常约定，指出当前测试实际覆盖的部分。每个新增测试必须验证一项业务承诺或曾经出现的缺陷，不为提高行数而复制同一条正常调用。 2. 为必选与可选参数建立测试矩阵，包含合法值、默认值、边界、无效类型、空值及有意义的组合。解释哪些组合受业务限制而不成立，不能用任意字符串堆出与真实接口无关的用例。 3. 对数值计算选取可信参考结果或独立实现，检查形状、数据类型和数值误差。误差阈值必须有算法、精度或项目规范依据，不能在测试失败后直接放宽到通过；普通业务计数和金额按其精度规则断言。 4. 根据支持范围选择解释器、依赖、运行模式及硬件。Paddle 特有的动态图、静态图或梯度检查只在相应接口适用时加入；未支持环境明确列为不适用，不能跳过后仍写全部平台通过。 5. 对异常输入断言错误类型和必要上下文，测试命名写出触发条件与预期结果。避免只断言“不为空”或“未抛错”，同时检查是否意外修改输入、遗留文件或污染全局状态，保证测试可独立复现。 6. 运行受影响测试并检查失败原因，修复后复跑对应范围。将偶发失败与稳定缺陷区分，记录随机源、环境和执行条件；只有出现新变更或未解决风险时才扩大回归，不用重复执行掩盖不稳定性。 ## 交付与验收 输出：测试矩阵、关键测试代码、已发现缺陷、实际执行结果及尚未覆盖的风险。缺少数学定义或业务契约时标出无法确定的期望值，先完成其他可判定测试；没有环境时只交付测试方案与代码，不声称验收通过。 ### 本条完成检查 - 测试矩阵覆盖真实合法值、默认值、非法类型、空值和关键组合，每条对应明确业务承诺。 - 断言输出、异常及输入不被意外修改；数值参考与容差依据独立且可追查。 - 交付测试代码、实际执行条件、通过失败与未覆盖项，不能将跳过设备计为该平台通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [百度飞桨《API 单测开发及验收规范》](https://www.paddlepaddle.org.cn/documentation/docs/zh/dev_guides/api_contributing_guides/api_accpetance_criteria_cn.html)
编写输入明确、输出可核对、设备条件清晰的 Python 接口示例，检查复制运行、资源准备和使用说明是否完整。
## 任务目标 请为本次指定的 Python 接口或模块编写或修正可运行示例。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 示例目标：优先修正对话中提到的不可运行示例；未指定时从模块主要公开入口选择现有最小用例，补齐输入、调用和可核对输出。 模块或示例资料：读取接口源码、docstring、已有示例、资源引用和检查脚本，从项目依赖与测试矩阵识别实际运行条件。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查清示例的必要导入、初始化、参数和结果含义，排查前序示例遗留的隐式状态。 - 追踪数据文件、下载地址、许可及设备选择，判断能否用合法的小样本替代大资源。 - 核对解释器、依赖、随机源及现有示例检查流程；Paddle 专属条件仅在相应项目中采用。 ### 可采用的默认处理 - 默认编写能说明既有接口用途的最小完整示例，不附加训练、部署或无关框架。 - 优先合法可构造的小数据和现有设备，明显标记示例数据；不把本地私有路径写成交付条件。 - 正文内给代码与说明，未被要求时不新建独立文档；预期输出和实测输出分开记录。 ### 必须有依据的事项 - 接口用途或输出含义无定义，无法判断哪种样例能代表正确业务行为。 - 必要数据许可或访问资格不明且无法构造等价小样本时，不擅自下载或分发该资源。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无执行设备时提供完整示例、资源准备及运行命令，列出结果核对点和待执行项。 - 无法取得真实资源时交付明确标注的小样本示例，并说明其不覆盖的真实数据或设备条件。 ## 执行要求 示例应能复现并核对结果，运行条件须与目标项目一致。编写 Paddle 示例时，单独说明飞桨专用检查指令、执行时限与设备要求；普通 Python 项目不直接套用这些条件。 1. 选取能够解释接口主要用途的最小业务场景，明确输入、调用和输出。补齐必要导入与初始化，去掉与理解本接口无关的大段训练、部署或数据下载代码，确保读者复制后知道从哪里开始运行。 2. 使用小而有代表性的数据，列出每个输入字段、单位或形状。需要外部文件时说明取得方式与许可条件，不能引用本机私有路径；无法取得资源时提供合法可构造的小样本，不伪装成真实生产数据。 3. 明确展示用户需要核对的结果，区分实际输出与解释性注释。随机场景设置相关随机源并说明仍可能存在的环境差异；不承诺只设置一个种子就能让所有设备和版本得到逐位一致结果。 4. 写清解释器、依赖、CPU 或加速设备要求及运行步骤。需要特定硬件时不要隐含依赖默认设备；需要联网时列出资源用途和可替代方式，避免基础使用示例因大型下载长期没有反馈。 5. 用项目支持的方式执行示例或加入已有示例检查流程，核对输出的关键属性。优先修复可检查性问题，确实需要跳过时标明原因与缺失验证，不能通过跳过全部断言声称示例可靠。 6. 从空目录或干净环境复跑关键示例，检查上下文是否依赖前一个例子留下的变量、文件或全局状态。为最常见的非法输入增加短小的错误说明，使读者知道问题来自输入、环境还是接口限制。 ## 交付与验收 输出：可复制示例、必要环境与资源说明、预期输出、实际运行记录及已知限制。只在用户要求时生成独立文档，其余直接给代码和说明。没有执行环境时明确标注示例尚未实跑，不能伪造输出或把手工推导写成实测结果。 ### 本条完成检查 - 示例具备完整导入、初始化、输入及调用，外部文件可取得且没有私有路径依赖。 - 给出关键预期结果、字段单位或形状，以及常见非法输入的解释，不只展示函数调用。 - 从干净环境核对关键示例的独立运行，说明随机及硬件差异；没有运行记录不写实测通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [百度飞桨《Python 文档示例代码书写规范》](https://www.paddlepaddle.org.cn/documentation/docs/zh/dev_guides/style_guide_and_references/code_example_writing_specification_cn.html)
核对 Python 项目的本地检查与持续集成配置，解决本地通过、流水线失败及自动格式化改动未复核的问题。
## 任务目标 请检查当前 Python 工程的本地代码规范与持续集成是否一致。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 检查不一致现象：从最近已提供的 CI 失败、本地命令差异或当前变更开始；没有失败说明时比较现有本地检查入口与流水线的解释器、工具、参数和文件范围。 仓库或检查日志：自动读取 pyproject、锁文件、pre-commit、CI 定义、脚本与可访问的本地或远端检查记录，不要求用户重新抄写配置。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 逐项比较 Python 与工具版本、工作目录、安装步骤、配置加载位置及实际检查文件。 - 识别提交钩子是否安装、哪些 hook 会自动修改文件，以及本次未提交内容可能受到的影响。 - 定位排除规则、换行、缓存和失败日志的证据，区分环境错误、自动格式化与源码问题。 ### 可采用的默认处理 - 默认只读比较与非改写检查，不安装 hook 或执行会自动改写文件的修复命令；明确修复时仅处理已定位差异。 - 沿用工程工具和版本，优先修复加载、范围或环境不一致，不升级全部依赖或删除全部缓存。 - 无法访问远端日志时仅判断本地可证实事实，不声称流水线已恢复或自动推送改动。 ### 必须有依据的事项 - 本地与流水线对同一文件采用互相冲突的团队规则，且没有权威配置可确定应保留哪套行为。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有远端权限时交付本地复现命令、配置差异和需要定位的具体 CI 步骤，远端结论保留待核验。 - 只有失败日志时提取工具、路径、规则与候选根因，给最小复现检查顺序。 ## 执行要求 按本项目的工具版本、启用规则和检查范围核对本地与流水线配置。使用 pre-commit 时同时检查提交钩子和流水线的执行方式；不要把其他工程的贡献检查要求直接当成本项目配置。 1. 读取真实检查配置和流水线定义，记录检查工具、版本、文件范围、解释器及运行目录。比较本地和远端是否使用同一套参数与依赖，不根据开发者电脑上“已经安装”推断持续集成环境一致。 2. 确认提交钩子是否生效，以及哪些工具会自动修改文件。区分格式化导致的检查失败与真实代码缺陷，复核修改后的差异再继续检查，不能把工具修改悄悄覆盖到用户尚未提交的其他工作上。 3. 审查排除项和忽略规则，合理排除生成产物与外部代码，保留本次业务源码检查。需要临时豁免时写明具体文件、原因和影响范围，不用大范围关闭规则换取流水线变绿。 4. 逐条定位失败来源，判断是版本差异、配置加载错误、文件换行差异、缓存问题还是源码问题。为每个判断提供日志位置或复现步骤，避免一遇失败就升级所有依赖或删除全部缓存。 5. 形成最小配置或代码改动，处理真实问题并保留既有接口行为。若引入新工具，说明它补充的检查能力及与已有工具的边界；不要把格式工具的通过结果当成业务测试或安全审查结论。 6. 在与流水线相同的条件下执行受影响检查，查看自动修复后的最终差异，再运行关联业务验证。记录退出结果、检查文件及剩余告警；只有实际执行成功才能标记通过。 ## 交付与验收 输出：环境差异表、根因与证据、配置或代码修复、复验记录。源码本身无问题时明确是环境或配置导致，避免无意义改动。不能访问远端日志时提供需要补充的最少信息和本地排查路径，不宣称持续集成已恢复，也不自动推送或提交未授权改动。 ### 本条完成检查 - 输出版本、命令、工作目录与文件范围差异表，每个根因附日志或配置位置。 - 如实施修复，复核自动改写差异并保留无关内容，用与 CI 一致的条件复验。 - 明确格式检查、业务测试及远端 CI 各自结果，未运行或仅本地通过不得合并宣称全部恢复。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [百度飞桨《代码风格检查指南》](https://www.paddlepaddle.org.cn/documentation/docs/zh/dev_guides/git_guides/codestyle_check_guide_cn.html)
改进 Python 接口异常和运维报错，写清错误事实、实际与预期的差异及处理建议，便于调用方处理和维护人员定位。
## 任务目标 请改进本次 Python 模块或服务的异常处理和错误信息。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 异常改进对象：沿对话中的报错或当前模块公开入口追踪异常链；没有具体异常时优先处理吞错、宽泛捕获、不可定位提示和重复日志，同时保留已有对外错误协议。 代码或报错资料：读取目标模块、调用方、异常类、接口响应封装、日志配置和已有失败测试；使用已提供脱敏日志定位实际问题。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 区分输入、数据不存在、前置条件、外部依赖和程序缺陷，确认哪一层具备恢复上下文。 - 追踪错误码、异常类型、客户端处理和日志记录，识别接口兼容约束及重复堆栈。 - 检查错误中的实际值、令牌或个人信息，以及可依据的重试、修改输入和维护处理路径。 ### 可采用的默认处理 - 优先修正现有错误文案和异常传播，保留错误码、HTTP 约定及业务成功条件，不批量更换异常体系。 - 普通用户看到简短中文事实和下一步，内部保留必要因果链与请求标识，敏感原值默认脱敏。 - 无法证明可重试时不建议自动重试；不以空列表、默认值或捕获全部异常伪装成功。 ### 必须有依据的事项 - 调用方依赖的错误码、异常类型或失败重试约定不清，而目标修正必须改变这些对外行为。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有日志时交付异常分类、脱敏文案对照和应取证的调用层，不臆造源码根因。 - 有代码无运行条件时给出完整局部实现及非法参数、超时等断言用例，标记复现待验证。 ## 执行要求 错误信息应清楚描述错误事实、实际与预期的差异，并给出有依据的处理方向。面向 C++ 宏的长度限制和专用宏规则不作为普通 Python 项目的强制要求。 1. 先沿调用链区分输入错误、数据不存在、前置条件不满足、外部依赖失败和程序缺陷。明确谁能够处理每种错误，不把所有异常归为一个“系统错误”，也不能用宽泛捕获把失败变成空列表或默认成功。 2. 为每个对外入口列出需要验证的条件和合适的 Python 异常类型。优先在有足够上下文的位置报错，说明出错对象和具体约束，避免仅输出内部变量缩写或用户无法理解的内部函数名。 3. 能够安全给出差异时，显示实际类型、数量、范围或维度与预期的区别。日志中的值必须按敏感等级处理，不把令牌、密码、个人完整信息及大段业务原始数据直接拼到错误中。 4. 只给有证据支持的恢复建议，区分可重试、需要修改输入和必须联系维护人员的情况。不要在未知原因下建议反复重试或提高资源配置；外部服务报错应保留必要原因，便于定位故障发生在哪一层。 5. 核查错误传播与记录方式，保留有价值的异常因果关系，避免每一层重复记录同一堆栈。面向普通用户的中文提示应短且可操作，内部日志另保留请求标识和排查信息，二者不直接互相复制。 6. 通过非法参数、空数据、超时、外部服务失败和意外异常验证结果，断言异常类型、关键上下文及调用方处理行为。确认调整错误信息没有改变业务成功条件，也没有破坏已有错误码协议。 ## 交付与验收 输出：异常场景表、旧新文案对照、传播与记录策略、必要实现和测试结果。每条建议写明适用条件；无法复现的异常保留待验证状态。缺少业务错误格式时先指出接口兼容风险，不自行批量更改客户端依赖的错误码。 ### 本条完成检查 - 交付异常场景、可处理层、旧新提示与恢复条件，保留必要原因且避免多层重复记录。 - 验证非法输入、外部失败和意外异常的类型、上下文及调用方响应，检查秘密和个人信息不会进入提示。 - 说明实际修改与测试结果，确认成功条件和已知错误协议保持兼容。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [百度飞桨《报错信息文案书写规范》](https://www.paddlepaddle.org.cn/documentation/docs/zh/dev_guides/style_guide_and_references/error_message_writing_specification_cn.html)
审查 Python 公开接口的参数类型、返回值与文档是否一致，并验证类型标注对最低支持解释器版本的兼容性。
## 任务目标 请审查或完善本次 Python 模块的类型契约。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 类型契约对象：从当前模块的公开导出、对话指定函数或本次改动接口开始，对照实现、调用方和文档检查类型；未明确要求修改时先报告确定差异。 模块或契约资料：查找模块、公开导出、docstring、外部调用示例、最低 Python 约束和现有静态检查配置。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 划分公开接口、内部辅助与动态扩展，记录参数默认值、空值、集合元素和所有返回分支。 - 比对调用方实际传值、文档示例及运行时校验，识别可用协议类型与兼容边界。 - 查最低解释器、检查器能力、注解反射及类型别名使用点，排查循环导入和 TYPE_CHECKING 风险。 ### 可采用的默认处理 - 默认只读核对，明确要求完善时只补有契约证据的公开边界，不为注解覆盖率修改业务签名。 - 沿用最低 Python 和现有检查工具支持的语法，不因类型提示升级解释器。 - 动态入口保持已知能力并说明不确定部分，不用大面积 Any 或忽略错误宣称类型完备。 ### 必须有依据的事项 - 实现、调用方和文档对同一参数或返回值存在业务歧义，无法确定收紧类型是否会拒绝合法调用。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有调用方时完成可观察分支与文档差异表，对调用兼容结论单独标记限制。 - 不能运行最低版本时提供候选注解和导入、反射及关键调用检查命令，不声称兼容性已验证。 ## 执行要求 以真实调用契约为准完善类型标注，并用项目现有工具验证。检查 Paddle 公开 API 时核对对应接口要求；普通 Python 工程按自身兼容范围选择类型语法，不直接套用框架专属约定。 1. 先区分公开接口、内部辅助函数和动态扩展入口，记录真实调用方依赖的参数与返回值。优先完善公开边界，不为了追求覆盖率给所有局部变量堆叠注解，更不能通过修改业务签名制造表面上的类型统一。 2. 将函数签名、类公开属性和说明文档逐项对照，检查可为空、默认值、集合元素和返回分支。对字典结构尽量描述明确字段，对返回结果写出调用方实际拿到的具体类型，避免用 Any 掩盖已知契约。 3. 检查参数是否需要接受更通用的集合协议，以及实现是否真的支持这些输入。保留必要的运行时校验，类型提示不能替代用户输入验证；如果使用枚举、字面量或重载，说明它们与真实运行行为的对应关系。 4. 核对最低解释器和静态工具支持的语法，区分注解上下文与运行时类型别名。仅为类型服务的导入可以评估放入 TYPE_CHECKING，但需要运行时反射或解析注解的代码必须另外验证，不能盲目移动导入。 5. 检查文档示例、外部调用和异常分支是否同时符合新类型，识别循环导入、可变容器与泛型参数缺失。只在有明确契约的地方收紧类型，并列出可能影响调用方的变化及迁移办法。 6. 使用项目现有静态检查和相关运行测试验证，在最低支持环境做导入与关键调用检查。对每个无法准确标注的动态入口说明原因和收敛方案，禁止大量忽略错误后宣称类型已经完整可靠。 ## 交付与验收 输出：公开接口契约表、类型与文档差异、必要代码修改、兼容性说明及检查结果。缺少调用方或版本信息时记录假设和待确认项；没有执行条件就提供验证命令与预期检查目标，不虚报静态检查已通过。 ### 本条完成检查 - 公开契约表覆盖参数、空值、默认值、集合元素、返回和异常，差异可定位到实现或示例。 - 如实施标注，保持运行时校验，验证类型导入、反射及最低版本关键调用。 - 分别给静态检查和运行测试结果，列出仍无法准确描述的动态入口及影响。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [百度飞桨《Python 类型提示标注规范》](https://www.paddlepaddle.org.cn/documentation/docs/zh/dev_guides/style_guide_and_references/type_annotations_specification_cn.html)
