核对 Python 项目的 TCA 依赖漏洞扫描结果，区分版本命中、部署存在和业务可触达，形成最小兼容升级、回归验证及回退计划。
## 任务目标 任务：Python 依赖漏洞分诊与最小升级验证。基于所提供工程和业务证据完成检查，先读取可访问的工程与证据，可以推进的部分继续完成；仅对查证后仍影响结论的关键缺口提问；不要编造文件、日志、测量结果或已完成的操作。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 漏洞处置范围：以当前工程可找到的 TCA 报告为入口，优先核对部署中存在且报告风险较高的 Python 依赖；没有报告时先建立依赖和扫描覆盖清单。 工程或扫描资料：查找 requirements、项目锁文件、依赖管理配置、TCA 输出、CI 日志及已提供的部署清单，再按漏洞编号查官方公告。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 确定扫描提交、工具规则版本、识别文件和解析失败项，确认传递依赖是否被覆盖。 - 从锁文件与依赖树追踪直接、传递、开发、生产和可选依赖，并核对可取得的部署版本。 - 查阅具体公告的受影响与修复版本、触发条件及业务调用证据，不用风险分值代替适用性判断。 - 读取上层约束、实际调用点、现有回归测试和可回退制品记录。 ### 可采用的默认处理 - 默认只读分诊，先给最小兼容升级方案；只有明确要求修复时才改依赖和锁文件，不自动部署或降级。 - 缺少覆盖或调用证据时分别标为未覆盖、部署未知或可触达性未知，不填零漏洞或无风险。 - 优先兼容的最小修复版本，保留唯一依赖维护入口；责任人和处置期限未给出时列待指定。 ### 必须有依据的事项 - 无法确认真实部署版本或公告对应关系，不能确定该告警对生产的适用性及最终处置结论。 - 是否接受漏洞暂缓或回退后重新暴露漏洞属于业务风险决策，没有明确依据不得代为接受。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有锁文件时交付依赖引入路径、待核验公告清单和扫描覆盖缺口，不声称 TCA 已执行。 - 只有报告时完成告警归并、最小候选升级和实际使用点回归方案，把部署核验单列。 ## 执行要求 适用边界：检查已有依赖清单和 TCA 扫描结果的 Python 项目。先确认扫描工具实际识别的锁文件格式、传递依赖和运行时信息，不预设完整覆盖，也不把零告警等同于无漏洞。实际漏洞版本范围必须由所给官方公告核对，不能依赖记忆。 检查要求：从 TCA 报告提取组件、版本和漏洞详情，有修复信息时一并记录。报告中的低、中、高风险用于初步排序，仍需独立判断部署适用性并制定回归和回退方案。按项目实际版本解释规则，不机械沿用旧示例。 1. 固定本次扫描的提交、依赖文件、工具及规则版本，核对日志中的文件识别情况和失败项。分开列出已扫描、解析失败、未覆盖的依赖；材料不足时不得填成零漏洞，也不得补造扫描完成记录。 2. 将报告组件映射到实际安装环境，区分直接与传递依赖、开发与生产依赖、可选功能与必选组件。追踪是谁引入该版本，确认锁文件和部署环境是否一致；不能仅凭源码未直接导入就判定组件不存在。 3. 逐项核对官方公告的受影响版本、修复版本和触发条件，记录公告编号及核对日期。将版本命中、部署存在和业务可触达分别判断；缺少功能调用或配置证据时标为未知，风险等级仅作为排序输入。 4. 优先给出满足约束的最小兼容升级方案。传递依赖同时评估上层组件约束，说明依赖树和锁文件的变化；不要盲升最新版、直接删除锁文件或通过忽略告警作为修复。暂缓项写明负责人、期限和实际缓解措施。 5. 列出升级可能影响的导入接口、序列化、数据库驱动、网络调用等实际使用点，据此设计构建、单元及集成验证。记录升级前后组件版本、依赖冲突和目标漏洞复扫结果，扫描通过不能代替业务回归。 6. 用已验证的制品和对应依赖锁定状态设计回退。说明回退是否重新引入漏洞，以及触发和停止条件。区分待执行计划与已执行证据，对没有报告的测试和部署不得填写通过。 ## 交付与验收 输出：先给处置优先级；再给分诊表：组件、引入路径、实际版本、公告依据、触发条件、适用性、处置、责任人；附最小升级清单、回归用例和回退条件。 ### 本条完成检查 - 逐项列组件、引入路径、版本、公告、触发条件、适用性和处置优先级，并保留证据日期。 - 给出依赖树与锁文件的预期最小变化、业务回归及回退重新引入风险。 - 如已明确实施升级，分别报告安装冲突、漏洞复扫和业务回归实测，不用一种通过替代另一种。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源核验日期：2026-09-08。 - 腾讯 / 腾讯云代码分析 TCA《依赖漏洞扫描规则包》：https://tencent.github.io/CodeAnalysis/zh/guide/%E4%BB%A3%E7%A0%81%E6%A3%80%E6%9F%A5/%E8%A7%84%E5%88%99%E5%8C%85/dependency_vul.html 验证说明：已核对上述公开来源及具体规则或能力；本模板尚未通过模型对比实验或线上业务实测，不能以来源品牌、仓库热度或扫描分数代替验收。 来源许可说明：Tencent/CodeAnalysis主许可为MIT，LICENSE.txt单列第三方组件许可；该网页未单列文档许可。本条为中文原创整理，来源内容与本模板补充要求已在正文区分。
要求交付完整 Python 源码、依赖清单、示例输入与预期结果、自动化测试文件和中文说明，逐步列出安装、运行示例、处理自己数据及执行测试的命令，普通用户可照着操作。
## 任务目标 请根据下面的需求，开发并交付一个普通用户可以照着说明运行的 Python 程序。直接生成完整文件、示例数据、测试用例和中文操作说明，完成实际功能，不要只给设计方案或零散代码。 在现有授权范围内完成实际改动和验证；缺少外部条件时先完成可独立实现的部分，不能只停留在计划。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 程序用途：从当前对话的明确需求、已有程序入口及已交付样例识别输入、处理规则和预期输出；完全没有业务需求或行为依据时不自创工具，只询问必须解决的实际问题并先整理可用交付条件。 已有程序或样例：在已确认工作区查找 Python 入口、现有说明、依赖维护入口、examples、tests 和配置示例；无工程但业务需求明确时新建最小源码项目。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对现有功能、输入输出格式、CLI 参数和调用场景，保留无关文件及已有改动。 - 从依赖约束、环境配置和实际解释器识别支持版本、操作系统、架构及外部软件需要。 - 检查示例输入、独立预期结果、cases.json 和自动化测试是否齐全，判断哪些资源可以合法随包交付。 - 查明依赖唯一维护入口及启动脚本使用的解释器，检查中文空格路径、退出码和覆盖行为。 ### 可采用的默认处理 - 新建小型程序默认 Windows 10/11 64 位、首次安装可联网、源码交付并优先标准库；已有平台或工程约束优先，不承诺所有电脑通用。 - 交付安装清单统一为 requirements.txt；已有其他锁定入口时由其生成，项目 .venv 内解释器完成安装、示例、业务运行和测试，无需激活或管理员权限。 - 默认不覆盖输入及已有结果，无参数只给中文引导；缺少外部服务时采用明确标记的隔离样例，不自动执行线上副作用。 ### 必须有依据的事项 - 无法从需求或现有程序判断究竟处理什么数据、应产生什么业务结果，或关键转换规则互相矛盾；不得自创业务及期望值。 - 真实联调需要的账号、服务权限或有副作用操作尚未具备，只暂停对应联调，不虚构凭据或执行结果。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 业务明确但缺运行环境时仍交付完整 .py、必要资源、独立预期结果和可执行测试，并将运行验证标为未执行。 - 完全无业务依据时先交付安装与打包条件盘点、文件职责和验证步骤，集中说明唯一必要的业务缺口，不生成冒充实际功能的空程序。 ## 执行要求 普通用户只需要保存或解压文件，按顺序安装，先运行示例，再处理自己的数据。不得要求用户补代码、猜参数、手工逐个安装缺失的库或自己编造用例文件。 ### 先确定可以运行的交付范围 明确程序解决什么问题、接收什么输入、生成什么结果。需求不足以确定业务结果时，只问影响实现的关键问题；其余采用合理默认值并写清楚。不要自行编造业务或把真实接口替换成未说明的假数据。 先检查已有工程，保留与本次任务无关的文件和改动。小型程序优先用标准库，确有必要再增加第三方依赖；不为简单功能搭建复杂框架。默认交付 Python 源码，不要求安装 IDE，不强行打包 exe。 确定支持的 Python 版本、系统和处理器架构，并核对依赖兼容性。运行环境不能确认时标明待验证，不直接承诺所有电脑通用。 ### 必须交付完整文件 新建小型项目默认采用以下结构；文件格式根据真实业务确定，最终文件名和说明必须一致： 项目目录/ main.py 程序入口与实际业务功能 requirements.txt 完整依赖清单；无第三方依赖时留空或仅写 # 注释 安装依赖.bat 检查 Python、创建环境并安装依赖 启动程序.bat 使用项目环境启动 main.py 运行示例.bat 使用项目环境执行示例 运行测试.bat 使用项目环境执行自动化测试 使用说明.txt 安装、运行、测试及常见问题 examples/ input.* 最小可用示例输入，使用业务实际格式 expected.* 对应的预期结果或可核对的期望值 cases.json 正常、异常、边界用例及预期行为 tests/ test_main.py 能执行并作断言的测试代码 output/ 运行结果，允许程序首次运行时创建 logs/ 错误日志，允许程序首次运行时创建 其中 input.*、expected.* 只表示需要按业务选择扩展名；交付时必须给出实际文件，例如 input.csv 和 expected.json，禁止真的创建带星号的文件或留下未替换的名称。 main.py 和其他必要的 .py 文件必须完整，导入路径、函数调用和命令参数前后一致。不得留下省略号、TODO、空函数或“此处自行实现”。有配置需求时提供 config.example.json，并说明如何复制和填写，用户不应修改源代码。 有文件写入能力时，直接创建这些文件；有附件能力时提供可下载的压缩包。无法生成附件时，按“相对路径 + 完整文件内容”逐个输出，明确告诉用户保存位置和编码，不能声称附件已生成。没有明确要求，不额外生成 Markdown 文档。 ### 程序本身要便于普通用户使用 main.py 使用清晰的主入口，将业务逻辑与参数解析分开。提供 --help 中文参数说明；提供 --demo，读取交付包中的示例并输出到独立的演示结果目录。没有参数时显示中文操作入口或交互引导，不直接处理未知目录、不自动执行有副作用的线上操作。 文件处理类程序提供明确的 --input 和 --output 参数；其他类型程序使用符合业务的参数。用户自己的输入通过参数、文件选择或简单配置指定，不靠修改代码切换。交付说明中必须有一条处理实际业务数据的完整命令，不能只有 --help 或 --demo。 路径使用 pathlib 等可靠方式处理。内置资源相对程序目录定位；用户传入的路径按说明中的规则解析。支持中文和空格路径。示例结果放入 output/demo 下，正常业务结果与示例分开；默认不覆盖原始输入或已有结果，重名时生成明确的新路径或要求用户选择。 输入校验要覆盖文件存在性、格式、必要字段和业务边界。成功时显示处理数量、结果文件和完整保存位置；失败时用中文说明问题及下一步操作，详细异常写入日志。成功退出码为 0，失败返回非零，不能捕获所有异常后仍报告成功。 代码命名、缩进、空行和注释统一。注释解释业务规则、参数和边界，不逐行翻译代码。复用已有函数，不堆积重复逻辑、无用依赖和无效分支。 需要外部服务、数据库、浏览器、FFmpeg、模型或账号时单独列明准备条件。真实凭据不得写进源码、示例或日志。演示模式可以使用明确标注的本地样例或模拟服务，但必须说明与真实联调的区别。 ### 统一依赖与安装入口 默认以 requirements.txt 作为交付包唯一的完整安装清单，包含本程序及所附测试实际需要的第三方依赖；默认使用标准库 unittest，不为了测试额外引入框架。固定经过兼容性验证的直接和间接依赖版本，不从开发机混杂的全局环境盲目导出。无第三方依赖时文件留空或只写以 # 开头的说明，不能把普通中文句子写成依赖项；安装命令仍应能正常完成。 已有工程使用其他锁文件时，保留其唯一维护入口，并从该入口生成一致的交付清单，不能手工维护两套冲突版本。开发和打包工具不混入普通用户安装流程；确实需要的测试工具须在安装说明中交代。 源码在项目目录创建 .venv。安装、示例、业务运行和测试都使用该环境内同一个 Python，通过“该解释器 -m pip”安装依赖，不混用全局 pip，也不要求用户先激活环境。 安装依赖.bat 应定位自身所在目录，检查 Python 是否存在及版本是否支持，再创建或复用 .venv、安装清单、执行 pip check。每个关键步骤都检查退出状态；失败立即停止，保留可读提示，不能继续显示“安装成功”。重复安装不得删除用户数据、配置或结果。 没有 Python 时，安装入口应清楚提示缺少的运行环境；使用说明提供 Python 官方下载入口、具体支持版本和架构、对应安装器的安装步骤及安装后的检测命令。若当前提供的是安装管理器，要写清如何安装实际运行时，不能把管理器安装完成当成 Python 运行时已就绪。不要要求用户搜索下载地址，也不要用需要 Python 的脚本解决“未安装 Python”。 默认使用普通用户权限，不要求管理员运行，不修改全局软件源、不关闭证书校验、不修改 PowerShell 执行策略。首次准备环境和以后运行分开；每次启动不重新安装或升级依赖。离线使用时必须实际提供兼容的依赖包及所需资源，并给出离线安装命令；缺少资源时如实说明。 各 .bat 入口使用同一 .venv、同一业务入口和同一套参数规则，正确引用含空格路径，失败窗口不一闪而过。调用 Python 后立即保存退出码，再显示提示或暂停，最后原样返回该退出码，不能因暂停或其他命令把失败变成成功。移动项目后 .venv 可能失效，说明如何只重建环境而保留业务文件，不将开发机的 .venv 当作可移植交付内容。 ### 用例必须有文件、有预期、有断言 examples/input.* 提供小而完整的真实格式样例，明确标注为示例数据；examples/expected.* 独立给出应有的处理结果。字段、编码、分隔符、日期和数值格式与程序一致。预期结果必须根据业务规则确定，不能通过再次调用被测函数来生成期望值。 examples/cases.json 至少包含一条正常用例、一条非法输入用例和一条关键边界用例。每项写清 id、用例名称、输入文件或输入值、执行参数、预期退出码、预期结果或错误提示，以及必要的结果核对方法。引用的文件必须全部交付。案例和命令都不能使用不存在的路径。 tests/test_main.py 必须是真正可执行的测试，读取用例资料、调用业务功能或程序入口并作断言。检查输出内容、退出状态或应发生的异常；不能只打印“通过”，也不能把没有异常当作业务结果正确。 测试输出使用临时目录，与正式 output 和用户输入分开；不修改交付样例或真实业务文件。涉及网络时，分清本地模拟测试和需要凭据的集成测试，未执行的集成测试不能计为通过。 根据项目补充空数据、缺字段、错误格式、重复数据、中文及空格路径、重名输出等相关场景。时间、随机数等不固定字段要固定条件或说明比较规则，不能只删掉全部差异来让测试通过。 ### 把安装和执行写成可以照抄的步骤 使用说明.txt 必须面向第一次使用的人，先说明文件解压到哪里、如何在项目文件夹打开 PowerShell，再按下面的顺序写。每步给出完整命令、预期看到的结果、失败后怎么处理。命令单独一行，不夹杂解释文字，不把终端提示符当成命令的一部分。 以下是新建项目的 Windows PowerShell 命令结构。交付时必须按实际选择的 Python 版本、项目入口和参数核对并生成可执行命令；如果 Python 默认版本不适用，要给出明确的版本选择参数，不能保留 X.Y 之类占位符。 1. 首次安装：安装已确认兼容的 Python，重新打开终端，在项目目录检查解释器、创建环境、安装全部依赖并检查冲突。 ```powershell py --version py -m venv .venv & ".\.venv\Scripts\python.exe" -m pip install -r ".\requirements.txt" & ".\.venv\Scripts\python.exe" -m pip check ``` 如果电脑只有 python 命令而没有 py，须给出检测版本后使用 python -m venv .venv 的完整替代步骤；环境建立后的命令仍统一调用 .venv 中的解释器。某一步失败先解决该步，不要求用户继续执行后续命令。 2. 运行示例：执行下面命令，再打开明确的结果文件，与交付的预期结果核对。说明示例处理了什么、正确结果是什么、再次运行会生成什么文件。 ```powershell & ".\.venv\Scripts\python.exe" ".\main.py" --demo ``` 3. 运行测试：在项目目录执行以下命令，说明应发现的用例数和成功、失败的判断方法；没有发现测试也必须判为验证未完成。 ```powershell & ".\.venv\Scripts\python.exe" -m unittest discover -s ".\tests" -p "test_*.py" -v ``` 4. 处理自己的数据：说明输入文件应放哪里、需要哪些字段、如何填写参数，并给出与真实实现一致的完整命令。文件处理项目必须包含 --input 和 --output 的使用示例，路径包含空格时加引号。除了用户自己的文件路径和业务参数，不让用户修改命令中的解释器、程序名或脚本内容。 ```powershell & ".\.venv\Scripts\python.exe" ".\main.py" --help ``` 上面的 --help 只用于查看帮助，不能替代实际业务执行命令。请根据本次实现另外写出那条命令，并解释它的每个参数、结果位置和覆盖规则。 5. 以后使用：说明哪些安装步骤不必重复，如何通过启动程序.bat、运行示例.bat、运行测试.bat 完成对应操作，或直接使用相同的 PowerShell 命令。说明如何正常退出，以及发生错误时查看哪个日志文件。 仅对用户实际要求的操作系统提供步骤。需要兼容 Linux 或 macOS 时，分别提供经过核对的命令和解释器路径，不混用 Windows 路径或 .bat。 ## 交付与验收 ### 实际验证后再交付 有执行环境时，从干净的项目环境按使用说明逐条执行：依赖安装、pip check、示例处理、结果比对、自动化测试和至少一条正常业务命令。检查 .py 语法、文件是否齐全、说明中的路径和命令是否有效，以及程序失败时是否返回正确状态。 按目标平台检查双击入口、中文和空格路径、重复安装、再次运行、输入错误与输出重名。不能因为开发机能运行就宣称所有用户电脑均已验证；没有目标系统、外部服务或网络条件时，将对应项标为未执行并说明所缺条件。 输出真实验证记录：系统与 Python 版本、执行命令、测试发现数量、通过与失败情况、退出状态、示例结果核对和未验证项。预期输出、实际输出、待执行计划分开写，不伪造运行日志、截图、文件或测试结论。 最后按这个顺序交付： 1. 程序用途与运行条件。 2. 完整文件下载入口；无法附文件时给文件清单和逐文件完整内容。 3. 首次安装步骤及命令。 4. 示例输入、预期结果、运行示例命令。 5. 使用自己数据的执行步骤、完整命令及参数解释。 6. 测试用例文件、测试命令和实际验证结果。 7. 以后启动方式、结果与日志位置，以及与本项目有关的常见问题处理。 ### 本条完成检查 - 提供完整 main.py 及必要源码、实际扩展名的示例输入和 expected 文件、cases.json、tests/test_main.py；区分示例、预期与带断言的测试，不留 TODO。 - 提供唯一依赖清单、项目 .venv、四个 .bat 入口和使用说明.txt，包含未安装 Python 的官方安装路径、可复制 PowerShell 安装及真实业务运行命令。 - 核对双击与命令入口一致，按实际条件报告安装、pip check、示例对比、测试数量和退出码；零测试、未运行及未真机验证均不得写通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 - [Python 官方下载](https://www.python.org/downloads/)：运行环境获取入口。 - [Python Packaging User Guide：隔离环境与依赖安装](https://packaging.python.org/en/latest/guides/installing-using-pip-and-virtual-environments/)。 - [pip：可重复安装](https://pip.pypa.io/en/stable/topics/repeatable-installs/)。 - [Python unittest：测试与用例发现](https://docs.python.org/3/library/unittest.html)。 以上资料用于核对安装与测试方法；文件清单、中文入口、用例组织和交付顺序为本提示词的要求，不代表已替未来生成的程序完成运行验证。
建立 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)
