围绕岗位每日任务设计待办、快捷入口和业务数据，明确统计口径、跳转结果、刷新规则及无数据状态。
## 任务目标 请设计面向岗位日常办理的业务工作台。目标是让用户快速开始工作并处理需要关注的事项。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 工作台岗位：从当前系统角色、默认入口及已有待办识别主要岗位；未指定角色时，先围绕现有普通业务用户的办理任务整理工作台，无法确认主岗位则分别保留实际存在角色的视图差异。 岗位与业务资料：读取现有工作台、菜单权限、待办与统计接口、业务状态及任务说明，使用已有访问或访谈记录确定优先级，不要求用户重新整理工程内已有数据口径。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查角色菜单、默认路由与业务入口，识别必须处理、需要关注和偶尔使用的任务。 - 核对待办查询的对象、责任人、状态、组织范围及完成后消失条件。 - 追踪统计卡片到明细的查询条件、时间窗、更新时间和权限，查处理后刷新规则。 ### 可采用的默认处理 - 先保留真实待办和可达业务入口，缺少可信统计时不新增累计数字或装饰图表。 - 排序优先依据明确责任和时限，缺少行为数据时将顺序标为待验证设计建议，不编造任务频次。 - 无待办、部分无权限和数据失败分别设计；仅用标识清楚的占位字段表达结构，不把占位值显示成实时数据。 ### 必须有依据的事项 - 待办归属、待处理状态或跨组织范围无法确定时，不能猜测应由谁办理或展示哪些真实记录。 - 统计与明细口径互相冲突时，不能先选一个数字作为正确值，需确认口径后再下结论。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有真实数据时交付岗位任务优先级、模块结构、待办与指标字段口径表及跳转刷新规则。 - 没有运行页面时完成从待办进入、处理、返回的设计走查，列出待补接口与统计验证条件。 ## 执行要求 模块数量和展示方式由岗位任务决定，不能将设计示例直接当作通用要求。 1. 按角色还原登录后的首要任务，列出必须处理、需要查看、偶尔使用的事项，并注明排序依据。没有访问数据或访谈记录时只提出待验证排序。 2. 为每项待办定义来源对象、待处理状态、责任人、截止时间、组织范围和消失条件。明确已完成、历史、被撤回和本人发起但他人处理的数据是否纳入。 3. 决定首屏内容和功能入口，优先呈现业务动作及其背景。将不支持用户决策的累计数字、重复统计和装饰性图表列入删除建议，不凭空增加业务指标。 4. 逐个定义统计卡片的口径、时间窗、更新时间、单位、权限边界与明细跳转条件。点击某数量后，明细筛选应与数量口径一致，差异有合理解释。 5. 设计待办过多、无待办、加载失败、部分模块无权限、数据延迟和新账号初始化状态。无业务数据时提供可执行入口，不能用随机记录填满正式工作台。 6. 按不同角色给出页面模块顺序与操作说明，走查一个从待办进入、处理、返回并刷新统计的完整流程。记录需要接口、权限或业务方补齐的条件。 ## 交付与验收 输出：角色任务优先级、工作台模块表、待办与指标口径表、模块布局说明、跳转及刷新规则、异常状态、验收场景。只展示能解释来源与用途的模块。 验收：用户可以明确今天处理什么；待办均有真实责任与状态依据；统计与明细范围一致；空状态可继续办理；无虚构增长率、客户数量或品牌背书。 信息边界：缺少实际数据时用清楚标识的占位字段描述结构；不把占位值称为实时数据，不宣称已验证统计正确。 ### 本条完成检查 - 每个模块都有任务依据，每项待办有责任、状态和范围定义。 - 统计与明细条件对应，进入、处理、返回和刷新规则能连接成完整办理路径。 - 空状态可继续办理，未知和失败不被填成零值或随机业务记录。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 工作台](https://ant.design/docs/spec/research-workbench-cn/)
将分散功能整理为便于岗位使用者理解的中文菜单、页面层级和任务入口，覆盖深链接进入、返回路径和权限变化。
## 任务目标 请梳理企业业务系统的信息架构与导航。产出应能指导菜单调整与页面设计，避免仅做名称美化。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 导航整理范围：优先采用当前指定模块；没有指定时，从现有系统的导航入口及其页面树开始，先整理一个有完整任务链路的业务域，再标注与其他模块的共享入口。 菜单与任务资料：读取当前工程路由、菜单配置、页面标题、权限映射和已知业务任务，结合现有截图与功能说明自动建立页面归属关系。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 比对菜单、路由与真实页面入口，区分功能页、按钮、数据视图和系统设置。 - 查同义菜单、同名异义和重复入口，追踪列表、详情、编辑与审批的进入及返回路径。 - 核对角色默认页、菜单可见条件和接口权限，检查深链接、权限收回及对象删除的实际结果。 ### 可采用的默认处理 - 按业务对象与任务分组，每页指定主要归属，跨模块快捷入口明确关联，不为整齐强制相同层数。 - 缺少频次数据时使用可解释的任务顺序，并注明依据；不虚构用户实验成功率。 - 默认输出导航和迁移建议，不删除现有功能或改动真实路由、账号权限；已明确授权实施时才落地对应范围。 ### 必须有依据的事项 - 同名页面承担不同业务或功能归属存在冲突时，不能仅凭名称合并、删除或改变办理入口。 - 角色数据范围无法由授权规则确认时，不能把菜单不可见推定为禁止访问或替业务决定开放范围。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有功能清单时交付中文导航树、页面归属表、角色入口和任务路径建议，并标出尚无路由证据的部分。 - 缺少运行环境时交付旧入口到新入口的映射、深链接和返回场景，不声称导航已在系统验证。 ## 执行要求 菜单结构应提供清楚的位置线索和一致的操作方式，层级和数量由实际信息结构决定。 1. 盘点功能对应的业务对象、主要使用角色和任务频次依据，将菜单、功能按钮、数据视图与系统设置区分开。缺少访问数据时标注频次是业务人员提供还是分析假设。 2. 按业务对象与工作任务分组，找出同义菜单、同名异义和重复入口。为每个页面指定一个主要归属，需要跨模块复用的入口注明它与主入口的关系。 3. 设计层级清楚的中文导航树。复杂管理系统可以考虑侧栏，低层级浏览型入口可考虑顶部导航，说明选择原因；不要为凑整齐强行统一不同业务的层数。 4. 定义列表、详情、编辑、审批之间的进入和返回路径，说明搜索条件、页码、选中项是否保留。深链接直接进入详情时应有可理解的位置提示和返回去向。 5. 为不同角色列出默认进入页和可见范围，说明没有权限、权限刚被收回、业务对象被删除或跨组织访问时的页面结果，避免把不可见菜单当作授权边界。 6. 选择几个实际任务逐步走查导航，记录找到入口、完成操作、返回工作位置的步骤。标注需比较或验证的路径，不虚构用户实验成功率。 ## 交付与验收 输出：现有问题清单、中文导航树、页面归属表、角色入口矩阵、任务路径表、旧入口到新入口映射、待确认项。需要改名的条目说明其对应业务意义。 验收：每个功能有明确归属和可达路径；主要任务入口不会重名误导；详情页返回有上下文；权限异常有明确结果；不出现纯装饰分类和宣传口号。 信息边界：只依据已提供的业务与页面证据评价，不未经授权删除既有功能、变更路由或调整真实账号权限。 ### 本条完成检查 - 功能归属和可达路径清楚，菜单命名不会把不同业务混为同义。 - 详情返回保留合理上下文，深链接、对象删除及权限变化均有明确结果。 - 新旧入口映射完整，组织方案没有以装饰分类掩盖业务差异。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 导航](https://ant.design/docs/spec/navigation-cn/)
梳理审批与多步骤办理的状态、角色和操作后果，补齐撤回、驳回、重提、并发及中断恢复等适用流程。
## 任务目标 请为业务设计可交给研发实现的状态流程。重点解决多步骤录入或审批流中下一步不清楚、操作后果不明确的问题。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 办理流程：从当前业务对象和已有办理动作识别流程；未指定时，选择工程中已存在的一条提交到处理结果的链路，先梳理其状态、角色与中断恢复，不自行扩充审批制度。 规则与流程资料：读取现有状态枚举或字典、审批规则、表单与接口、权限和历史记录定义，结合已有流程说明提取实际可用动作。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对业务状态定义、状态转换代码或规则配置，区分加载状态与真实业务状态。 - 逐项读取提交、驳回、重提、撤回和关闭的适用条件、角色、版本及历史保留方式。 - 查草稿保存、返回、关闭页面、网络中断后的数据恢复机制，以及幂等、并发版本控制和回调处理证据。 ### 可采用的默认处理 - 只把已确认状态和转换纳入正式流程图，缺失规则以带影响说明的候选分支表达。 - 分离草稿保存与正式生效，业务终态说明办理结束，不强行安排下一责任人。 - 并发、重复点击和超时先按现有能力描述；无实现证据时列为待实现要求，不宣称系统已具备幂等或自动恢复。 ### 必须有依据的事项 - 审批权限、合法状态转换或撤销生效后果缺少业务依据时，不能自行决定，先完成其他已确认路径。 - 历史记录与新版本的责任归属冲突时，不能猜测沿用原处理人或自动生效规则。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时依据规则材料交付状态词典、状态转移表、分步表单和角色视角路径。 - 规则仅部分明确时交付已确认主流程、关键异常候选及逐项决策影响，不把未确认分支画成既定流程。 ## 执行要求 将任务顺序、状态变化、权限和异常处理写清楚，具体规则以业务材料为准。 1. 以业务对象为单位列出状态，解释每个状态的业务含义及结束条件。分离业务状态与界面加载状态，不用一个含混的“处理中”同时代表审批、支付和文件上传。 2. 建立状态转移表，逐行填写当前状态、触发动作、可执行角色、前置条件、目标状态和失败结果。没有规则依据的撤销、删除或自动审批不能自行加入正式流程。 3. 明确提交、驳回、修改、重新提交、撤回和关闭等动作是否适用，注明是否保留原记录、是否生成新版本及原处理人是否继续有效。不能适用的动作说明理由。 4. 为步骤设计输入边界和保存时机，区分草稿保存与正式生效。说明返回上一步、关闭页面、网络中断后哪些数据保留，以及恢复入口在哪里。 5. 检查两人同时审批、重复点击、对象已被修改、账号权限变化和超时回调的处理结果。后端尚无幂等或版本控制依据时列为实现要求或待评审项，不能声称已具备。 6. 按办理角色走通一条正常路径和关键异常路径，检查每一步是否能看到对象当前状态、操作结果和下一责任人；已到合法终态时说明办理结束，无需下一处理人，并写出逐段验收条件。 ## 交付与验收 输出：状态词典、状态转移表、完整业务流程、分步表单说明、异常处理表、角色视角走查记录与验收条件。流程图只表达已确认状态，未确认转移使用文字列出。 验收：中间状态具备明确进入和退出条件，初态明确触发来源，终态明确结束结果；每个动作均有角色和后果；中断和并发场景能够得到明确处理；用户可知道下一步由谁完成或当前流程已经结束。 信息边界：规则缺失时给出明确标注的候选方案及影响，不替业务方决定审批权限，不把设计走查写成已执行系统测试。 ### 本条完成检查 - 每个状态有含义与进入退出条件，每个动作有角色、前提、后果和失败结果。 - 草稿、正式提交、中断恢复、并发及历史版本规则分别明确。 - 角色能知道下一步由谁办理或流程已经结束，设计走查与真实系统测试分开记录。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 表单页](https://ant.design/docs/spec/research-form-cn/)
将业务需求写成可供研发实施的功能说明和工作项，明确输入、规则、责任、依赖及验收条件。
## 任务目标 请将业务需求转成可交付研发的功能说明与工作项。面向产品、设计、前后端和测试共同阅读。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 功能需求目标：从当前会话的业务诉求与已确认范围识别功能目标；未单独填写时，沿当前需求材料或明确的本次改动拆解可独立验收的目标，不从代码现状臆造新增需求。 需求与工程资料：读取已有需求、页面、接口、字典、权限、项目约束与工作项模板，自动提取参与角色、字段和研发依赖。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对原始需求、已确认范围、现有页面和接口定义，区分新增要求与既有行为。 - 查字段来源、默认值、校验、计算、状态转换和统计口径，追踪组织及租户边界。 - 查设计、服务端、前端、数据调整与测试的现有模块和交付入口，识别真实依赖及团队工作项字段。 ### 可采用的默认处理 - 按一个可独立验收的业务目标拆一项需求，字段与任务命名沿用项目术语，复合目标先拆分再关联。 - 有依据的字段、权限和规则直接整理；缺少人员安排时使用责任角色，缺工期时只列依赖与建议顺序。 - 默认交付工作项内容及关联建议，不自动写入外部协作系统或发送消息，避免把拆解建议说成已经创建。 ### 必须有依据的事项 - 核心计算、业务默认值、状态变化或授权范围在需求与代码间冲突时，不能代替业务决定新规则。 - 历史数据兼容或正式生效后果尚未确定且影响交付正确性时，应单列必须明确的决定，同时完成其他工作项。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时根据已有业务资料交付功能说明、字段规则、角色矩阵和实施任务依赖，注明尚未核实的技术入口。 - 需求仍有空白时先交付可确认功能的验收条件及待定项对任务的具体影响，不用空泛 PRD 或虚构排期填满内容。 ## 执行要求 工作项需写清描述、负责人、优先级、项目和迭代，并关联设计、接口等研发资料；字段与流转规则以团队实际使用的系统为准。 1. 建立需求编号和简短中文标题，写明业务背景、使用角色、进入条件和最终结果。每条只描述一个可独立验收的业务目标，复合目标先拆分再说明关系。 2. 逐项列出页面或接口的输入字段、来源、类型、必填条件、合法范围、默认值和校验时机。任何默认值须有业务依据；历史数据兼容规则未知时作为缺口保留。 3. 明确核心计算、状态变化、重复提交、并发修改和失败恢复规则，分别写正常路径与异常路径。凡涉及统计，注明时间范围、组织范围、状态过滤和去重口径。 4. 整理角色操作矩阵，分别定义查看、新增、修改、审批、导入和导出权限。说明数据可见范围及权限不足时的用户反馈，不把按钮隐藏当作完整授权实现。 5. 按设计、服务端、前端、数据调整和测试拆分实际工作，建立依赖与交付物。负责人可用已提供的人名或岗位，缺少人员安排则保留待分配，避免编造排期。 6. 将需求编号关联设计稿、接口、规则依据和验收用例入口，写出每项完成条件与变更影响。只建议需要的工作项，不把拆分结果冒充已经在云效创建。 ## 交付与验收 输出：功能说明表、字段规则表、状态与异常分支、角色权限矩阵、研发任务及依赖、验收清单、待补充材料。工作项至少包含标题、范围、责任角色、依赖、交付物、优先级依据。 验收：开发能够识别输入、处理规则和结果；测试能够从每项需求形成用例；没有无来源字段和虚构工期；中文业务名称前后一致。 信息边界：现有代码与需求冲突时同时列出两者，并标明需要业务决策的差异；本任务默认不创建外部工作项或发送协作消息。 ### 本条完成检查 - 每项功能均有角色、进入条件、输入、规则、结果和独立验收条件。 - 任务能对应设计、接口、字段及测试入口，责任与依赖清楚且不虚构承诺。 - 权限、数据口径、正常与异常路径明确，需求和现有实现的冲突未被隐藏。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [云效 Projex：新建需求](https://help.aliyun.com/zh/yunxiao/user-guide/new-demand/) - [使用项目协作创建并完成需求](https://help.aliyun.com/zh/yunxiao/user-guide/start-collaboration-within-a-project)
整理业务目标、现状证据、角色边界和本期范围，区分已确认需求与待验证想法，形成可评审的需求澄清结果。
## 任务目标 请作为企业软件产品经理，围绕真实业务整理一份可评审的需求澄清结果。用途是决定本期解决什么问题，以及如何判断问题得到解决。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 业务问题：从当前会话的原始诉求、已给需求或问题记录中提取谁在什么任务上受阻；没有明确新诉求时先描述现有流程与可见问题证据，不将个人设想升级为正式需求。 现状与需求资料：使用会话已有说明、页面和问题记录，读取当前工程可确认的角色、业务对象及操作流程；只在已授权资料范围内寻找约束与历史决定。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 逐条提取原始需求及出处，区分现象、使用者诉求、解决方案建议和未验证假设。 - 查看业务对象、责任角色、组织或租户范围，以及从触发到结果的现有办理路径。 - 查重复录入、等待、返工等问题的具体材料依据，核对已承诺范围、资源或截止时间是否真实存在。 ### 可采用的默认处理 - 先还原事实与任务，再提出最小可完成目标；没有调研证据时不编造访谈、用户数量或提效比例。 - 范围优先覆盖与原始问题直接相关的内容，其他想法列为可延后或待验证，不默认扩成全系统重建。 - 没有排期和决策依据时只给有理由的优先级建议，角色与对象关系可确认多少就先整理多少。 ### 必须有依据的事项 - 材料无法判断用户实际想解决的业务问题，或相互冲突的目标会导向不同范围时，需要确认这一目标；可先完成事实与现状梳理。 - 组织责任、数据归属或必须保留的业务约束不明时，不能自行决定权限和办理责任。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时依据已有原始材料交付问题证据表、角色关系、当前流程及范围建议。 - 缺少调研与运行证据时交付明确标注假设的候选目标、可观察验收条件和关键验证事项，不把候选方案当作已确认需求。 ## 执行要求 围绕使用者的角色、任务和现有困难分析需求，方案应减少理解和办理成本。 1. 逐条提取原始材料中的问题，记录谁在何时执行什么任务、在哪一步受阻以及现有证据位置。把明确事实、使用者诉求、方案建议和待验证假设分开，不能用自己的推测补成访谈结论。 2. 整理业务角色、业务对象、对象负责人和协作关系。存在集团、企业、部门或租户时分别定义视野；岗位名称相同不代表数据权限相同，组织边界不明的地方单独标注。 3. 用触发条件、输入、处理动作、输出和下一责任人还原当前流程，指出重复录入、等待和返工的位置。只描述材料支持的现象，不凭印象给出节省时间或提效百分比。 4. 为每个问题提出最小可完成的目标，区分用户任务和系统功能。将目标与需求一一关联，删去没有业务对象、触发条件或处理责任的宣传性功能表述。 5. 划分本期必须交付、可延后和不在范围的内容，注明优先级依据及依赖。没有实际资源、截止时间或决策授权时，给出排序建议，不虚构承诺日期。 6. 针对每项本期需求写可观察的完成条件，覆盖正常流程和至少一个失败分支。汇总会影响方案的关键未知项，列出应由哪个角色补充、需要何种材料。 ## 交付与验收 输出：①简明业务目标；②问题与证据表；③角色和对象关系；④当前任务流程；⑤范围与优先级表；⑥逐项验收条件；⑦待确认事项。表格使用业务中文，保留材料引用位置。 验收：所有本期功能均能追溯到具体问题和使用角色；每项都有可验证结果；事实与假设清楚区分；不存在伪造的调研、用户数量和收益数字。 信息边界：资料不足时先完成能够确定的部分，把缺口写清楚；不要未经授权联系用户或改动线上系统。 ### 本条完成检查 - 每项本期功能能追溯到具体问题、证据和使用角色，不含无业务责任的口号式功能。 - 目标、范围与优先级理由清楚，每项完成条件覆盖正常结果及适用失败分支。 - 事实、诉求、方案和假设明确区分，关键未知项说明影响和所需决定，能够确认的内容已完整交付。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 设计价值观](https://ant.design/docs/spec/values-cn/)
建立 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)
检查小程序页面重点、导航、输入、加载、结果与异常恢复，适用于预约、填报、查询和审批等业务流程。
## 任务目标 请验收当前微信小程序的业务流程与界面体验，以真实用户角色和本次任务目标为依据。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 验收流程：从当前会话涉及的页面或已提供截图识别用户要完成的主要任务；没有流程清单时沿现有页面入口、主要按钮及结果页梳理一条真实任务路径。 小程序或页面资料：使用现有页面代码、截图、可访问预览、路由配置、接口状态及已有品牌样式，自动梳理角色可见的业务步骤。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪首页、分享、扫码和历史入口的直达路径，以及返回、取消、退出后的数据状态。 - 核对表单字段、必填与默认值来源，检查成功、失效、无权限及失败恢复的真实接口依据。 - 检查主要操作、中文反馈、键盘遮挡、菜单预留、长文本和字体放大表现。 ### 可采用的默认处理 - 默认只读验收并给具体调整；明确要求修复时再实施对应页面变更，不自动改变办理顺序。 - 沿用现有业务术语与视觉规范；缺规范时保持主任务清楚、操作集中、状态可理解，不补造宣传信息。 - 只有截图时仅判断可见布局及文案，导航、输入保留和提交安全分别列待交互核验。 ### 必须有依据的事项 - 无法确定办理角色、业务完成条件或关键字段的真实必要性，不能自行删步骤、代填事实或判定流程正确。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有截图时按页面给可见问题、用户影响和具体调整，并补可执行的异常恢复验收步骤。 - 没有可运行小程序时由路由和接口状态整理任务路径及测试矩阵，区分静态证据和待真机交互。 ## 执行要求 按微信内移动业务流程进行验收，页面的政企风格与中文业务文案遵循当前项目要求，不套用统一视觉模板。 1. 逐页指出用户当前要做什么、完成后去哪里以及如何返回。检查每页是否突出一个主要业务目标，导航和按钮是否能反映真实流程，清理无关宣传内容与重复引导，避免让用户在表单中被其他推荐打断。 2. 检查返回、取消和退出后的数据状态，覆盖从分享、扫码及历史入口直接进入页面。页面应能说明当前业务对象和进度，不能假设用户必定从首页按固定顺序进入。 3. 审查所有输入项是否确有必要，能选择的值优先提供明确选项，默认值必须有业务依据。字段标签、单位、格式和必填条件清晰可见，不能为了减少输入而未经用户理解就代填关键业务事实。 4. 根据操作范围设计加载和结果反馈：局部更新尽量原位反馈，耗时操作说明当前状态。错误需要足够明确且能够继续处理，不能一闪而过；成功页应说明已经完成的业务以及合适的下一步。 5. 验收网络失败、无数据、校验失败、记录失效和权限不足时的恢复路径。表单错误定位到相关项目，保留仍有效的输入；重试、修改和返回动作应与真实服务端状态匹配，避免造成重复提交。 6. 检查点击区域、控件间距、键盘遮挡、长文本、字体放大和官方菜单预留区域。保持同类组件和状态表达一致，使用真实业务内容检验对齐与换行，避免大面积装饰、花哨动效和没有含义的数据卡片。 ## 交付与验收 输出：按流程排序的问题清单，每项包括页面、触发操作、用户影响、具体调整和验收条件；另给完整任务路径与异常恢复表。已有代码且用户明确要求修复时，实施必要修复并验证，只有截图时明确无法确认的交互，不把静态外观审查当成流程全部通过。 ### 本条完成检查 - 按实际任务顺序输出问题、页面、触发、影响和验收条件，不用笼统审美评价替代业务问题。 - 覆盖直达、返回、取消、权限不足、记录失效和提交失败的恢复路径，确认合理输入可保留。 - 单列点击、键盘、长中文、字体放大及菜单区域检查结果，只有静态材料不得报全流程通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序设计指南》](https://developers.weixin.qq.com/miniprogram/design/)
定义微信小程序组件的属性、插槽和样式入口，处理组件注册、样式污染及不同页面的复用问题。
## 任务目标 请根据本次要求，将小程序中的重复业务界面封装为可复用组件，或审查已有组件的边界与样式隔离。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 组件目标：优先审查当前页面引用的目标组件；若对话明确要求封装重复界面，则从真实使用页面识别共同职责后实施，不凭相似外观创建通用组件。 组件或使用页面：读取组件及调用页面的 JSON、WXML、WXSS、脚本、事件监听和已有运行配置，从实际工程识别原生或跨端框架。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 对照真实调用场景确定数据所有者、内部状态、业务差异及是否存在稳定复用职责。 - 核对 usingComponents 路径、properties、事件载荷、插槽与 multipleSlots 配置。 - 检查 styleIsolation、外部样式类、虚拟节点及渲染器支持，跨端工程同时追查生成代码。 ### 可采用的默认处理 - 没有明确封装或修复要求时只读审查；实施时保持原有属性、事件和页面行为兼容。 - 优先现有隔离方式与明确的外部样式入口，不为局部问题全局开放样式共享。 - 仅有一个真实场景时按独立职责判断是否值得封装，不虚构第二个页面或添加大量未来开关。 ### 必须有依据的事项 - 不同调用页面对属性、事件或内部状态职责存在冲突，无法在不改变业务的情况下确定通用契约。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 缺运行环境时交付组件契约、样式入口、可检查代码或修正片段及逐页验证步骤。 - 只有截图时先给稳定职责与差异清单，不凭截图承诺原生注册、插槽或渲染器兼容。 ## 执行要求 按微信原生组件的能力检查实现。使用跨端框架时，进一步核对生成代码和框架适配，不能直接照搬浏览器或 Vue 的样式规则。 1. 先列出组件必须完成的业务任务、调用方负责的数据与内部展示状态。比较多个页面的共同部分和真实差异，只抽取已经稳定的职责；不要把整张业务页面塞进一个参数繁多、难以理解的通用组件。 2. 检查页面及组件 JSON 中的声明，确认引用名称和实际路径一致。为属性建立名称、类型、默认值及空值约定，核对数据能否在当前环境传递；非法输入要有清楚的处理，不依赖隐式转换掩盖接口错误。 3. 按内容扩展需求选择默认插槽或命名插槽。需要多个插槽时核查 multipleSlots 配置，并说明每个插槽负责的区域及为空时的表现；业务事件的名称和返回字段应稳定且与调用方用法对应。 4. 按官方文档检查样式选择器及 styleIsolation 设置，识别页面样式穿透组件、组件污染其他页面和继承属性变化。不能为修好一个样式问题就全局开放共享，先定位实际受影响的类与节点。 5. 通用组件需要允许定制时，优先设计明确的外部样式类入口，并列出哪些外观允许调整。避免调用方依赖组件内部层级或未约定的祖先样式；若启用虚拟节点，检查根节点布局、class 与 style 的实际生效位置。 6. 在至少两个真实使用页面验证正常数据、空数据、长中文文本、禁用状态、插槽缺省和局部样式覆盖。对已声明支持的渲染器及基础库环境分别记录结果，检查事件次数和数据回传是否符合调用契约。 ## 交付与验收 输出：组件职责说明、属性与事件表、插槽和样式入口、组件实现及复用验收结果。没有运行环境时只给可检查的实现和验证步骤，标明兼容性待测；需求只出现一个使用场景时说明抽象依据，不虚构更多业务来证明组件通用。 ### 本条完成检查 - 明确组件职责、属性类型和空值、事件次数及载荷、插槽和允许调整的样式入口。 - 在真实使用页面验证空数据、长中文、禁用和局部覆盖；只有一个场景时说明限制，不假造复用证据。 - 分别记录已支持基础库和渲染器的结果，确认组件不污染相邻页面且回传数据符合调用方。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：组件模板和样式》](https://developers.weixin.qq.com/miniprogram/dev/framework/custom-component/wxml-wxss.html)
审查微信小程序临时 code、服务端身份换取、自定义登录态及 session_key 保管，补齐业务授权联调。
## 任务目标 请对当前微信小程序及后端的登录链路进行实现或检查。不要提供真实密钥和用户个人数据。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 登录链路目标：沿现有 wx.login、登录请求、服务端换取身份和业务会话逐段检查；有明确新增登录或修复要求时在已确认账号关系内实施。 小程序或后端资料：查找登录模块、请求拦截器、后端认证入口、账号模型、会话配置和脱敏日志，使用已有安全配置位置，不要求粘贴真实密钥。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪 wx.login 临时 code 的提交、服务端换取和自定义登录态签发，定位重复 code 与并发处理。 - 检查 AppID 配置来源、session_key 存放和响应日志，确认秘密不会下发到客户端。 - 读取微信身份与业务账号绑定、机构角色校验、会话失效及退出后的访问控制。 ### 可采用的默认处理 - 默认只读检查身份链路；明确实现时沿用现有认证和会话体系，不另造一套令牌或默认自动注册账号。 - AppID、AppSecret、用户身份及账号绑定不虚构；缺凭据时使用明确隔离的模拟响应验证状态处理。 - 客户端只提交必要凭证和选择意图，账号、租户和角色以可信后端授权为准，未知授权不得默认放行。 ### 必须有依据的事项 - 微信身份与业务账号的绑定、自动开户或机构授权规则无法确认，不能自行合并账号或赋予权限。 - 缺少真实 AppID 配置、服务端换取权限或可用测试账号时，只暂停对应真实登录联调，不伪造平台结果。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 仅有前端时交付可证实的 code、请求和登录态问题，列后端字段保管与授权核查点，不断言服务端安全。 - 没有联调条件时给完整时序、接口边界及重复 code、失效、停用和退出访问的隔离用例。 ## 执行要求 核对微信身份换取流程，并按项目需求明确业务账号绑定、租户授权、会话期限和退出策略。区分平台登录能力与业务系统自己的身份和权限规则。 1. 画清小程序、开发者服务器和微信服务之间的数据流。核对 wx.login 返回的临时凭证由谁提交、在哪里换取身份，以及后续业务请求使用哪一种自定义登录态，不能把微信临时凭证直接当成长期业务令牌。 2. 检查临时 code 的一次性使用约束，处理重复请求、凭证过期和登录并发。失败后按具体原因重新取得凭证，避免重复回放已经消耗的 code；前端只能根据服务端明确结果判断登录成功。 3. 核查服务端对 session_key 的保管，确认它不会进入小程序响应、前端存储、公开接口或业务日志。排查打包配置和错误输出中的服务端密钥，示例中统一使用占位符，不复制生产凭据到测试用例。 4. 明确微信身份与业务账号的对应关系，检查账号状态、机构和角色从可信服务端获取。客户端传入的用户编号或租户编号不能直接决定查询权限；切换机构时核对当前用户确有相应授权。 5. 按业务约定梳理登录中、已登录、会话失效、账号停用和退出后的页面行为。回到原业务页面时重新校验可操作状态，避免界面仍显示登录成功但接口持续失败；必要信息应在失败时保留以便继续操作。 6. 联调首次登录、再次登录、code 重复、微信服务失败、业务账号受限、会话过期和退出后访问。逐条核对请求、响应与界面状态，采用脱敏记录，确认异常没有泄露会话密钥或敏感堆栈。 ## 交付与验收 输出：登录时序、字段与保管位置、业务授权待确认项、必要实现及联调记录。无法访问服务端代码时明确审查边界，不凭前端界面断言权限安全；缺少会话约定时先指出所需决策，并完成官方登录步骤的可核对方案。 ### 本条完成检查 - 输出三方登录时序、字段流向和保管位置，区分微信身份与业务会话。 - 验证 code 重复、并发、平台失败、账号受限、会话过期及退出后访问，检查 session_key 不出现在客户端和日志。 - 分别记录静态审查、模拟测试与真实联调结果，未确认的账号和租户规则明确留待决策。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：小程序登录》](https://developers.weixin.qq.com/miniprogram/dev/framework/open-ability/login.html)
规划微信小程序主包、业务分包及引用关系，检查启动路径、包体限制和分包加载失败后的体验。
## 任务目标 请为当前微信小程序制定或审查分包方案。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 分包规划目标：从现有 app.json 和可取得的构建体积报告检查主包压力与跨包引用；没有超限现象时先按真实启动和常用业务路径复核现有包归属。 工程或构建资料：读取小程序目录、app.json、TabBar、分享和扫码入口、公共资源引用、构建报告与主体及基础库配置。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 梳理启动页、TabBar 和直接进入页面，追踪脚本、组件及静态资源归属。 - 检查普通分包嵌套、跨包依赖及未被覆盖资源，识别独立分包和分包异步化是否真的需要。 - 从本次构建报告取得上传包体，结合可确认主体、发布渠道和当前官方规则核对限制。 ### 可采用的默认处理 - 默认审查并提供规划，不迁移文件或发布；明确重构时才按受影响页面实施最小包调整。 - 优先保留入口和公共依赖，未证实收益不引入独立分包或异步跨包能力。 - 缺体积报告时只给待测项和资源候选，不以源码目录大小或旧平台限额宣称可发布。 ### 必须有依据的事项 - 拟迁移页面承接外部分享或扫码，而入口兼容要求与初始化依赖无法确定，不能自行改变既有直达路径。 - 主体或发布渠道不明导致适用体积限制无法确认时，不给最终发布合规结论。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有目录和配置时交付页面归属、引用关系及最小调整草案，所有包体栏标待构建。 - 无法使用开发者工具时给构建取证与冷启动、分享直达、弱网首次下载的真机验收路径。 ## 执行要求 按微信小程序的包结构和发布要求审查方案。普通分包、独立分包和分包异步化的能力边界不同；所有限制需结合本次发布时的官方说明核实。 1. 从真实入口梳理启动页、TabBar 页面、常用业务路径和低频功能，列明每个页面依赖的脚本、组件及静态资源。优先让首个业务任务所需内容清晰可控，不以平均分配文件大小作为分包目标。 2. 对照 app.json 的分包配置核查目录，保证 TabBar 页面留在主包、分包根目录没有互相嵌套。找出未被分包覆盖而意外进入主包的资源，说明它们是公共依赖还是可以迁移的业务资源。 3. 检查普通分包之间的脚本、模板和资源引用，明确允许依赖主包的部分。若需要使用分包异步化或独立分包，单独核查该能力的版本与入口要求，不能只修改路径后假定运行时一定能找到依赖。 4. 使用构建报告记录主包、各分包和全部包体积，区分源码目录大小与最终上传体积。按当前主体和发布渠道核对平台限制，给出超限资源的具体位置及压缩、按需加载或去重方案，不沿用网上过时数字。 5. 检查冷启动、页面分享直达、扫码进入、TabBar 切换和从主包进入分包的路径。分包首次下载失败时给出用户可理解的反馈和重试入口，避免页面空白后只能退出小程序。 6. 在开发者工具构建后进行真机验证，覆盖弱网、首次下载、再次进入和升级后的资源加载。对于抽出的公共模块，重点回归初始化顺序与业务状态，记录体积和启动体验的实际变化。 ## 交付与验收 输出：页面与包归属表、依赖关系、配置改动、包体实测和进入路径验收表。没有构建结果时保留体积栏待测，不能把估算值作为可发布证明。涉及重构先列明受影响页面，保留已有业务入口和必要的兼容处理。 ### 本条完成检查 - 交付主包和各分包的页面归属、公共依赖及配置建议，确认 TabBar 与跨包引用规则。 - 分别记录主包、分包、总包实际上传体积及采用的当前限制依据。 - 验证启动、直达、TabBar、分包下载失败和再次进入；未构建或未真机验证不宣称可发布。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：分包加载》](https://developers.weixin.qq.com/miniprogram/dev/framework/subpackages.html) - [腾讯微信《微信小程序：使用分包》](https://developers.weixin.qq.com/miniprogram/dev/framework/subpackages/basic.html)
定位微信小程序页面更新频率、组件规模和数据量问题，以真实交互和测量结果评估优化效果。
## 任务目标 请排查本次小程序页面或组件的卡顿、响应延迟或频繁更新问题。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 卡顿或更新现象：优先复现当前页面的慢操作；没有现象记录时，从 setData、高频监听、定时任务和接口回调识别重复更新候选，再按真实渲染数据验证。 页面或性能资料：查找目标页面脚本与模板、渲染器和基础库配置、现有性能记录及可运行的开发者工具环境。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 确认实际框架和渲染器，区分首次进入、滚动、输入、切页及后台更新的复现场景。 - 按同一操作统计更新次数、字段与体积，追踪模板真正依赖的数据及间接关联字段。 - 检查显示、隐藏和卸载生命周期中的定时器、监听及订阅，核对恢复显示后的业务状态。 ### 可采用的默认处理 - 默认只读定位并给最小优化片段，明确修复时才改更新逻辑；没有测量先给候选排序。 - 优先减少重复和无渲染用途数据，保留必要状态变化，不按固定次数或代码行数判定性能。 - 没有目标设备时记录当前可测条件，真机结论另列，不把模拟器流畅视为问题解决。 ### 必须有依据的事项 - 拟暂停或合并的更新关系到价格、倒计时、排序或操作对象有效性，而业务时效要求无法确认。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 有代码无设备时交付更新入口及负载清单、可疑重复路径和取证步骤。 - 只有现象时给同条件复现记录表，覆盖前后台切换和不同数据规模，不虚填帧率或提速。 ## 执行要求 先确认微信小程序当前使用的组件框架和渲染器，再决定适用的更新方式，不把其他平台的性能结论直接带入。 1. 复现问题并记录操作路径、数据量、设备和页面状态。区分首次进入慢、连续滚动卡顿、输入延迟与后台页面抢占资源；没有测量证据时先给假设排序，不凭代码行数判断性能瓶颈。 2. 查找数据更新入口，统计同一操作触发的次数、更新字段和数据体积，标记定时器、滚动监听、输入监听及接口回调。把必要刷新与重复刷新分开，检查连续调用能否在不改变业务顺序的情况下合并。 3. 对照模板实际使用字段检查 data，移出完全不参与渲染的数据，间接关联字段按当前能力处理。只更新变化字段，避免整体回传所有数据；保留能证明需要刷新的条件，不能为降低次数丢掉真实状态变化。 4. 检查高频变化是否发生在节点很多的大组件中，评估将倒计时、局部状态等拆到职责清楚的小组件。拆分前后比较真实更新开销，避免为了减少单个树规模而产生大量跨组件通信。 5. 检查页面进入后台、重新显示和卸载时的更新行为，处理不必要的定时任务与订阅。恢复显示时补齐业务状态，确保暂停无感刷新不会造成过期价格、错误倒计时或操作对象失效。 6. 使用平台可用的更新性能信息或开发者工具比较修改前后表现。在相同条件下复测滚动、输入、切页和恢复前台，记录耗时分布与操作反馈，同时验证列表数据、排序和业务状态没有变化。 ## 交付与验收 输出：瓶颈证据、更新调用清单、最小改动及前后对比。每项优化写明改变了什么、可能影响的业务和回归方法。无法取得真机数据时标记“待真机验证”，给出采集步骤，不编造帧率提升百分比，也不只凭模拟器流畅就宣布问题解决。 ### 本条完成检查 - 给出瓶颈证据、更新次数与字段体积，区别必要刷新和重复刷新。 - 如实施优化，在同条件比较更新开销，并回归列表、排序、倒计时和前台恢复状态。 - 记录真实设备、网络、数据量与耗时分布，明确未真机验证部分。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯微信《微信小程序：合理使用 setData》](https://developers.weixin.qq.com/miniprogram/dev/framework/performance/tips/runtime_setData.html)
使用 TDesign ConfigProvider 统一表单、分页、日历、弹窗和空状态文案，完成符合国内政企业务习惯的界面验收。
## 任务目标 请检查当前 Vue 系统的中文界面和组件默认文案是否一致。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 中文界面检查范围：从当前后台页面与共用配置入口开始，检查日期、分页、校验、弹窗和空状态的实际文案；未给页面清单时选择现有列表、编辑和详情各一条真实路径。 工程或界面资料：读取现有 TDesign 依赖、ConfigProvider、局部组件属性、业务词汇及日期金额转换，并使用可访问页面核对显示。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查清已安装版本的 globalConfig、实际语言配置及局部覆盖，不猜语言包路径。 - 统计同一业务对象在列表、详情、编辑和反馈中的称呼，找出组件默认英文与中文混用。 - 追踪日期时区、金额单位和范围包含关系，分开检查显示格式与接口传输值。 ### 可采用的默认处理 - 默认只读检查并给配置及文案调整建议；明确统一文案时只改约定范围，不改变业务值。 - 通用控件文案归全局配置，业务动作留在对应页面；优先沿用已出现的准确业务名称。 - 无设计约定时保持政企中文布局的对齐、层级和主次操作，不添加营销词或虚构统计。 ### 必须有依据的事项 - 金额单位、时区、日期范围或业务状态名称存在多种合理解释且会影响用户判断，不能只为统一外观选一种。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 仅有源码时交付全局与局部覆盖表、候选词汇差异和具体交互核对步骤。 - 只有截图时提供可见文案与布局修正，日期弹层、校验和分页语言仍标待运行确认。 ## 执行要求 在使用 TDesign 的 Vue 后台中，按当前版本的 ConfigProvider 能力检查全局文案与局部覆盖。中文业务命名和政企页面表达遵循本项目约定，不由组件默认配置代替业务判断。 1. 先统计表单、分页、日期选择、对话框、选择器和空状态使用位置，识别全局配置与页面局部覆盖。查明运行时真实显示的语言，不能只看系统菜单中文就判断基础控件已全部中文化。 2. 对照当前版本的 globalConfig 接口统一常用组件文案。把通用词放到统一配置，把“提交审批”“停用设备”等业务动作留在对应场景；不猜语言包路径或配置字段，不修改组件库的自动生成接口文件。 3. 核对月份、星期、日期占位、确认取消、表单必填和分页数量表达。逐项区分展示格式与接口传输格式，确认时区、日期范围两端是否包含、金额单位及小数位，避免为了统一外观改变实际业务含义。 4. 统一相同业务对象的称呼和状态词，检查列表、详情、编辑与结果提示是否一致。占位提示用于说明输入方法，不能代替字段标签；错误文字需要告诉用户哪一项有问题和如何修正。 5. 检查页面层级、筛选区、表格区和主要操作的位置。保持标签对齐、主次按钮清楚、中文换行自然和信息密度稳定，删除不帮助完成业务的宣传口号、虚构成绩及冗余装饰，保留必要状态和业务说明。 6. 实际打开不同业务页面，操作日期选择、无结果查询、必填校验、分页和弹窗。检查全局修改是否误伤特殊场景，重点验证较长机构名称、低分辨率窗口和加载失败状态，记录截图或可复现路径。 ## 交付与验收 输出：统一词汇表、全局配置及局部覆盖表、需调整的页面清单、验收结果。每项修改说明它改善的具体业务理解或操作；没有页面运行条件时给出待验证清单，不能把静态代码检索结果当作完整视觉验收。 ### 本条完成检查 - 形成统一词汇及全局、局部配置表，说明每项调整解决的业务理解问题。 - 操作日期、分页、必填校验、空结果和弹窗，确认配置生效且特殊场景未被覆盖。 - 检查长机构名、低分辨率和加载失败，静态检索与真实视觉验收分别报告。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯 TDesign《TDesign Vue Next ConfigProvider 类型与接口说明》](https://github.com/Tencent/tdesign-vue-next/blob/develop/packages/components/config-provider/type.ts)
处理 TDesign Dialog 表单弹窗、删除确认等场景中的重复提交、关闭来源、草稿保留和失败恢复。
## 任务目标 请核查当前 Vue 业务弹窗的保存、关闭与异常恢复，使用户能明确完成操作并在失败后继续处理。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 弹窗业务目标：沿当前页面使用的目标弹窗追踪打开、输入、确认和关闭；未描述缺陷时重点检查提交未完成即关闭、失败无法恢复及切换记录残留。 弹窗或接口资料：读取弹窗与父页面、表单、保存接口、状态管理和已安装 TDesign Dialog 类型，从现有逻辑提取草稿及成功后刷新规则。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 确认弹窗唯一任务、对象、visible 所有者和真实请求周期。 - 核对取消、关闭按钮、遮罩和 Escape 的实现及当前版本是否支持异步拦截。 - 检查回车与表单提交重复触发、编辑回填、销毁重建、旧响应和成功后的页面刷新。 ### 可采用的默认处理 - 默认核查并给状态表和必要修正；明确修复要求时在现有组件能力内实现，不额外建立弹窗框架。 - 保存失败保留合理输入并恢复操作，服务端结果未明确前不展示成功或自动关闭。 - 沿用已有草稿和关闭约定，前端提交锁仅防重复触发，不当作后端幂等保证。 ### 必须有依据的事项 - 未保存草稿是否允许丢弃、提交中是否允许关闭缺少业务约定，且实现必须改变当前数据保留行为。 - 接口可能已受理但无返回，缺少幂等或结果查询依据时不能自行再次写入。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 缺源码时交付显示和请求状态、各关闭来源处理及失败恢复方案，组件 API 明确待按版本核对。 - 后端不可用时用隔离的成功、校验失败、延迟和未知结果验证前端处理，真实联调单列。 ## 执行要求 按当前版本的 TDesign Dialog 能力处理显示、加载和关闭事件。业务操作的幂等、授权以及是否允许取消，需要依照项目事实实现。 1. 列出弹窗承担的唯一主要任务、操作对象和完成条件。区分确认删除、编辑保存、结果提示等场景，按钮直接写业务动作；需要说明影响范围时描述真实后果，不使用笼统的“温馨提示”掩盖关键内容。 2. 设计未操作、输入中、提交中、成功、失败等状态，确定谁控制 visible。把确认按钮加载与真实请求周期绑定，避免请求尚未结束弹窗就关闭，或请求失败后按钮一直处于不可用状态。 3. 分别处理取消按钮、关闭按钮、遮罩点击和 Escape。存在未保存修改时按业务约定保留、确认放弃或阻止关闭；不要把返回 void 的动画前回调误当成支持异步拦截的关闭守卫，应检查该版本真实接口能力。 4. 核对回车确认与内部表单提交是否可能同时触发请求。对连续点击、键盘触发和慢请求期间再次操作进行限制；前端限制只减少重复触发，涉及不可重复业务操作时同时核查服务端约定。 5. 明确关闭时是否销毁子内容以及重新打开时如何初始化。编辑另一条记录时清理旧对象、错误提示与异步回调，成功后根据接口实际结果刷新列表或详情；不得把本地假定值直接当成服务器保存结果。 6. 验收焦点进入与返回、键盘操作、长内容滚动、遮罩遮挡和中文按钮长度。模拟业务校验失败、网络中断、延迟响应、重复触发及用户切换记录，检查能否继续编辑或安全返回原页面。 ## 交付与验收 输出：弹窗状态表、每种关闭来源的处理、必要代码修改和验收记录。对接口已受理但客户端未收到结果的情况单独说明确认结果的办法，避免直接再次提交。缺少版本或源码时先给处理方案和待核实 API，不声称组件天然保证全部业务安全。 ### 本条完成检查 - 给出状态表、关闭来源与草稿处理，确认异步守卫采用实际 API 而非动画回调。 - 验证点击与回车重复、失败保留输入、切换记录、旧响应和成功后真实数据刷新。 - 检查焦点进入返回、键盘、长内容滚动及遮挡，分别记录已执行与待联调行为。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯 TDesign《TDesign Vue Next Dialog 类型与接口说明》](https://github.com/Tencent/tdesign-vue-next/blob/develop/packages/components/dialog/type.ts)
围绕服务端分页和批量业务操作，核查 TDesign Table 的行标识、筛选排序、跨页选中、状态反馈与请求结果一致性。
## 任务目标 请根据本次要求，开发或检查 Vue 业务列表的查询、分页与批量操作。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 列表任务：优先检查当前路由或对话指定的查询表格；明确要求新建或修复时按现有接口实施，未明确实现意图时先审查分页、排序和选择的一致性。 列表或接口资料：读取页面、TDesign Table 类型、请求 DTO、列与字典、权限处理和已有测试，从真实响应确定数据结构与总数。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查稳定业务主键、分页来源、总数与统计范围，识别对服务端单页再次分页或本地排序的问题。 - 核对筛选、页码、排序到请求参数的映射以及旧响应保护。 - 追踪受控选中值、跨页保留、权限变化和批量接口的执行对象及部分失败响应。 ### 可采用的默认处理 - 沿用当前分页与选中约定；没有规则时仅展示和核对当前页记录，不擅自扩大为全查询结果批量操作。 - 使用服务端提供的稳定键和真实总数，未知总数不伪造，状态用文字表达并保留未知原值。 - 缺数据规模时以现有样本验证长文本、固定列和窄屏，不预设虚拟化或性能指标。 ### 必须有依据的事项 - 总数或排序到底对应当前页、全查询结果还是权限范围不清，不能自行确定统计口径。 - 批量动作的当前页、跨页或全量对象范围和部分失败重试规则无法确认，不能实际发起该写操作。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 缺后端协议时交付可确认的列与参数映射、状态和查询竞态方案，未知总数及批量结果留待接口确认。 - 只有接口时提供标明边界的核心前端实现与边界用例，不虚构接口外字段。 ## 执行要求 按当前版本的 TDesign Table 能力实现业务表格。服务器分页、统计口径及权限以本项目约定为准，不把组件默认行为视为业务需求。 1. 先明确列表记录的稳定主键、总数含义、筛选字段、排序范围与分页方式。区分当前页数据、全部查询结果及统计卡片口径，检查页面是否对服务器已经分页的数据再次进行本地分页。 2. 为行指定可靠标识，核对列配置与真实数据类型。日期、金额、状态分别按业务含义展示；长文本提供查看方式，关键标识和主要操作不得被无解释地截断，也不要用彩色标签代替完整状态文字。 3. 将分页、排序、过滤事件映射到接口参数，说明筛选变化后是否回到第一页。处理快速连续查询产生的响应顺序，避免先发后到的旧数据覆盖新条件；查询失败时不得把旧结果伪装成新条件的有效结果。 4. 明确勾选是当前页有效、跨页保留还是针对全部查询结果。使用受控选中值保持组件与业务一致，核对分页保留选中配置；筛选变化、权限变化和数据删除后及时处理失效记录，提交前显示实际操作对象范围。 5. 为首次加载、刷新、空结果、网络失败、无权限和部分操作失败设计可理解的反馈。批量动作完成后同步行状态、数量及选中项，部分失败时给出失败对象与原因，不能只显示一个含糊的“操作成功”。 6. 在实际业务数据长度下验收表头、固定列、横向滚动、列宽和窄窗口。验证分页末页删除、跨页勾选、全部取消、重复点击、排序后勾选保持及筛选后批量操作，同时查看真实请求和服务端返回。 ## 交付与验收 输出：数据口径与参数映射表、表格核心实现、选中规则、状态设计及验收记录。每个缺陷写清触发操作、实际结果、期望结果和修改位置。缺少后端协议时先列出待补充字段，并提供有明确假设的前端方案，不虚构总数或批量执行结果。 ### 本条完成检查 - 输出数据口径、请求映射、稳定键及选择规则；实施时提供对应核心代码。 - 验证末页删除、排序后选择、跨页选择、筛选变化、连续请求和权限变化。 - 核对批量执行的真实对象、成功失败明细及刷新后数量，检查固定列、滚动和中文内容。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯 TDesign《TDesign Vue Next Table 类型与接口说明》](https://github.com/Tencent/tdesign-vue-next/blob/develop/packages/components/table/type.ts)
将业务字段、校验和保存状态落到 TDesign Form，检查动态字段、异步校验、重置语义以及失败后的可恢复操作。
## 任务目标 请根据已知业务流程和字段契约，开发或审查本次 Vue 业务表单。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 表单任务：从当前页面的新建或编辑入口识别业务表单，先对照字段与保存契约审查；用户明确要求开发或修复时，继续完成规则已明确的实现。 表单或字段资料：查页面、接口请求与响应、类型、字典、权限、回填代码和现有测试，按已安装版本读取 TDesign Form 能力。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 提取字段类型、必填条件、长度范围、默认值、清空语义、只读条件与提交名称。 - 检查 Form 数据、FormItem 名称、validate 返回值、远程唯一性及过期响应处理。 - 追踪新增编辑详情、初始快照、隐藏字段、重置和失败恢复，核对实际请求中的日期金额枚举。 ### 可采用的默认处理 - 优先复用现有字段规则和接口，不凭必填星号推断业务约束，明确区分 0、false、空字符串与未提供。 - 初次进入不集中报错，按现有交互使用输入、失焦及提交校验；明确通过后才保存。 - 提交失败保留合理输入，前端防重不代替后端校验和授权；未要求开发时默认不改业务表单。 ### 必须有依据的事项 - 隐藏或清空字段是否参与提交、金额日期转换或新增默认值缺少真实业务定义，不能随意补值或删除。 - 字段修改权限及远程唯一性失败的业务处理无法确定时，不能自行放行保存。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 规则不全时先完成已知字段表、布局、状态处理和测试设计，将影响保存的未决项集中列出。 - 没有工程但接口明确时提供可检查的核心组件和请求示例，真实版本与联调结果注明待验证。 ## 执行要求 按当前版本的 TDesign Form 能力实现表单，字段权限、数据提交和重复操作处理须与本项目业务规则一致，不能只依赖组件默认行为。 1. 先把每个字段的业务含义、类型、必填条件、默认值、长度或范围、只读条件及提交名称整理成表。区分空字符串、零、false 和未提供，尤其说明编辑时哪些字段允许清空，不能凭视觉上的必填星号推断规则。 2. 对照实际版本配置 Form 数据、FormItem 字段名称和校验规则。需要跨字段判断时明确关联关系；条件隐藏字段要明确是否保留旧值、是否参与校验和提交，不能让看不见的字段持续阻止保存。 3. 设计校验触发时机，区分输入变化、失焦和提交。正确处理 validate 或提交事件的校验结果，只在明确通过时调用保存接口；远程唯一性校验需要识别过期响应，不能把网络超时当成字段已经可用。 4. 区分新增、编辑、详情状态，确定“重置”是清空还是恢复初始数据，并使用对应能力。异步加载编辑数据后核对初始值快照，再次打开表单时不得出现上一条记录的值或错误提示。 5. 完成保存中的按钮状态、重复触发处理、成功反馈和接口失败反馈。字段错误落在对应输入项，整体失败保留已填写内容并给出恢复方法；前端状态限制需要与服务端业务校验一致，不能代替服务端授权。 6. 逐项验收正常提交、缺失必填、边界值、非法格式、动态条件切换、远程校验失败、重复点击、回车提交及重置。验证日期、金额和枚举转换后的实际请求数据，禁止只看页面显示就断言数据正确。 ## 交付与验收 输出：字段规则表、状态与交互表、核心组件代码、请求示例、验收记录。代码缺失时说明推断范围；规则不明确时列出影响保存的待确认项，先完成不依赖这些项的结构，不自行编造业务枚举和接口字段。 ### 本条完成检查 - 交付字段规则、隐藏重置策略、表单状态、核心代码或审查缺陷及请求映射。 - 验证缺失、边界、非法格式、条件切换、远程校验失败、重复点击、回车和记录重开。 - 以实际请求核对日期、金额、枚举及空值，不能只看显示或组件校验通过判断业务正确。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯 TDesign《TDesign Vue Next Form 类型与接口说明》](https://github.com/Tencent/tdesign-vue-next/blob/develop/packages/components/form/type.ts)
核查 TDesign Vue Next 的组件引入、基础样式、构建体积和浏览器兼容，适合 Vue 3 企业后台初始化或接入复核。
## 任务目标 请为当前 Vue 3 系统制定 TDesign Vue Next 接入方案，或复核已有接入。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 组件库接入目标：有 TDesign Vue Next 时复核现有注册、样式和产物；已明确要求接入时按当前业务页面使用比例选择最小方案，无明确迁移需求则不替换已有组件库。 工程或页面资料：读取 Vue 工程入口、路由、package.json、锁文件、自动导入及样式配置，复用现有浏览器支持和构建脚本。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 确认桌面 Vue 3 适用范围、现有组件库、常用控件及重复能力。 - 核对注册方式、解析器、函数式调用和全局样式加载，确认现有按需方案是否完整。 - 读取构建和目标浏览器配置，检查生产资源、外部脚本版本及样式重置的布局影响。 ### 可采用的默认处理 - 默认复核已有接入，不因提示词出现 TDesign 就迁移 Vue 2、小程序或其他组件库。 - 优先保留能正常工作的全量或按需方式，无产物收益证据时不加自动导入插件。 - 采用锁文件中的兼容版本和既有业务页面验证，缺体积基线只记录当前产物，不填提升比例。 ### 必须有依据的事项 - 当前技术栈与桌面 Vue 3 TDesign 不兼容，而达成目标需要未经明确要求的框架或组件库迁移。 - 新库必须支持的目标浏览器或关键控件行为与现有约束冲突，无法据工程确定取舍。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时交付最小接入示例、注册和样式检查点，注明仅适用桌面 Vue 3。 - 没有构建或浏览器环境时给涉及文件与验证命令，首次弹窗、直达刷新及产物兼容标为待测。 ## 执行要求 接入范围限定为桌面端 Vue 3 与 TDesign Vue Next。项目使用 Vue 2、其他组件库或小程序时，先指出不适用部分，不直接替换工程依赖。 1. 确认真实入口、路由、样式加载顺序、组件使用比例和目标浏览器。列出已有组件库及重复能力，判断采用 TDesign 是新增统一组件还是局部接入，避免同一业务控件在不同页面出现多套行为。 2. 按实际使用范围选择全量注册、显式按需引入或自动导入。说明选择依据与维护成本，不把按需引入当成无条件要求；只有产物分析能证明收益时，才为体积目标增加相关插件。 3. 核对包版本、解析器和构建插件，使用项目锁文件固定可复现依赖。检查生产构建是否依赖未固定版本的外部脚本或样式；需要外部资源时列明来源、版本和不可用时的业务影响。 4. 确认基础全局样式已加载，检查自动导入是否同时处理组件和函数式调用。对输入框、选择器、表格、弹窗各做一个真实页面引用，识别缺样式、重复样式、组件未注册及编辑器提示失效等问题。 5. 复核样式重置与现有布局的关系，特别检查盒模型、弹层、滚动区域和中文标签。使用有业务含义的页面内容，不增加装饰性标语、虚构统计数据或大面积炫光；布局保持对齐、层级清楚、操作集中。 6. 通过项目既有构建命令生成产物，检查包体、资源请求和相关浏览器中的真实页面。分别记录首屏正常、路由切换、按需弹窗首次打开及刷新后直达页面的结果，失败时保留具体报错和复现路径。 ## 交付与验收 输出：接入方式及理由、涉及文件与配置、依赖版本、产物对比、页面验收结果。性能结论必须包含实测条件；缺少基线只给采集方法。无法运行时，标记所有待验证项并提供最小接入代码，不虚报浏览器兼容或上线完成。 ### 本条完成检查 - 明确接入方式、理由、版本、文件和样式入口，检查组件及函数式调用均可用。 - 用真实页面覆盖输入框、选择器、表格和首次弹窗，排除未注册、缺样式和重复样式。 - 执行生产构建并记录资源与浏览器页面检查，首屏、切路由和刷新直达分别报告。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [腾讯 TDesign《TDesign Vue Next 安装与使用》](https://github.com/Tencent/tdesign-vue-next/blob/develop/packages/tdesign-vue-next/site/docs/getting-started.md)
为现有 Vue 工程制定兼容当前工具版本的规范检查方案，区分新增问题、历史问题与业务修复，保持本地和持续集成检查一致。
## 任务目标 请为当前 Vue 工程接入或审查前端规范检查。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 规范治理范围：优先检查当前变更涉及的 Vue 文件与已有规范配置；没有改动清单时先盘点实际生效规则和代表模块问题，明确要求接入或治理后再实施范围内修正。 工程或规范资料：读取依赖及锁文件、ESLint 与格式配置、Vue 单文件组件、提交钩子、CI 和已提供检查日志，自行识别版本兼容关系。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对 .vue 模板与脚本解析器、JS/TS、ESLint flat/legacy 配置及实际检查范围。 - 查阿里规则包的真实导出和依赖要求，分清已有约定、公开规则与项目补充。 - 比较业务源码、测试、生成文件的排除方式及本地、提交前、CI 命令是否一致。 - 运行可用的非自动修复检查，将行为风险、维护问题和格式差异按模块归并。 ### 可采用的默认处理 - 默认只读审查配置和问题；明确治理时仅修当前范围，保留未提交工作，不整仓格式化。 - 沿用兼容的版本及格式方案，不为接入品牌规则包而叠加工具，不猜不存在的 Vue 配置导出。 - 生成产物可合理排除，真实业务代码不能扩大 ignore 掩盖；历史告警与新增问题分开处理。 ### 必须有依据的事项 - 现有团队规则互相冲突或所谓格式修复会改变业务输出，而工程没有依据决定应采用的行为。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有配置时交付兼容性差异、最小接入草案及目标文件覆盖核验方法。 - 没有执行环境时给真实可核对的配置建议与命令，不声称规则已经生效或扫描通过。 ## 执行要求 先核对当前 Vue 工程、现有工具及待接入规则包的兼容关系，不预设不同版本提供相同导出，也不把 React 专属规则应用到 Vue。 1. 读取依赖清单、锁文件、构建入口、Vue 单文件组件和现有检查配置，列明实际版本与已生效的规则。先确认解析器能处理模板、脚本和 TypeScript，再判断需要增加什么，避免重复安装同类工具。 2. 核对阿里规则包的实际导出、依赖范围和接入示例。选择与本工程兼容的接入方式，说明哪些使用公开规则，哪些沿用已有约定，哪些是本次业务补充。资料无法证明的 Vue 配置名称不要猜写。 3. 把检查范围划分为业务源码、测试、配置和生成产物。对生成文件及构建目录合理排除，对真实业务文件保留检查，避免用大范围忽略掩盖新增问题。检查提交前脚本是否会修改不在本次任务中的文件。 4. 运行已有检查并建立问题清单，按潜在行为错误、可维护性问题和纯格式差异区分。逐项指出具体文件和触发规则；同一根因合并解释，不把所有告警都列为高风险故障。 5. 先处理改动范围内问题，保持接口、页面文字和业务计算结果稳定。对需要改变运行行为的修复写明输入、原结果和新结果，不能混在批量格式化中。历史问题按模块安排，避免一次扫描演变成整库重写。 6. 检查本地与持续集成采用的版本、命令和文件范围是否一致。复核自动修复后的差异，针对涉及行为的改动运行相关测试和页面操作；只调整格式时不额外编写与实现重复的测试。 ## 交付与验收 输出：环境与适用规则表、最小配置改动、按模块归类的问题、实际执行结果和未解决项。每个结论标明已验证或待验证，不能用“扫描完成”代替“检查通过”。没有代码或执行环境时，给出可落地配置方案及需要补充的最少信息，不声称已经接入。 ### 本条完成检查 - 列出环境、实际生效规则及适用边界，确认模板、脚本和本次业务文件进入检查。 - 交付按模块归类的问题与最小配置改动，行为修复说明前后结果，格式修复不夹带业务变化。 - 复核最终差异及本地与 CI 一致性，给实际执行结果、历史失败和剩余项，不以扫描完成替代通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 官方来源（2026-09-08 核验）： - [阿里巴巴《阿里巴巴前端规约：ESLint 配置说明》](https://github.com/alibaba/f2e-spec/blob/main/packages/eslint-config-ali/README.md)
用于网络波动、主备切换和写命令超时，明确结果未知、可重试边界及重复执行后果。
## 任务目标 请审查 Redis 客户端的超时重试策略，并设计符合业务语义的幂等处理。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 重试业务：从当前问题或代码中识别使用 Redis 重试的业务操作；留空时优先检查递增、入队或带过期语义的写入，选一条有客户端和业务双层重试的完整链路。 代码与故障资料：读取 Redis 客户端依赖、连接与命令超时、业务重试封装、请求总时限和已有异常样本，版本与方法语义从实际工程确定。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪客户端、Service、网关与任务层的重试入口及次数。 - 识别命令执行、响应接收和业务确认的边界，找结果未知的处理代码。 - 核对业务请求标识、判重记录、保留期、结果查询及并发覆盖条件。 - 读取现有故障测试和每层超时配置，计算最坏请求次数及总耗时。 ### 可采用的默认处理 - 默认只读形成命令重试决策，不直接调整重试次数或扰动 Redis 连接。 - 无法判断是否执行的写操作归为结果未知，不按连接异常一律重发。 - 缺负载数据时按已知总时限列预算公式与停止条件，不指定所谓通用最优退避值。 ### 必须有依据的事项 - 重复执行对计数、队列、费用或过期时间的业务后果不明时，不认定该写操作可以安全重试。 - 业务请求唯一性、判重有效期或超时后的合法恢复动作缺少依据时，不承诺端到端幂等。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无代码时交付按命令语义分类的重试决策样例，以及多层放大和时间预算的计算模板。 - 无故障环境时提供发送前断开、执行后丢响应和并发旧值覆盖的隔离桩测试方案。 ## 执行要求 适用范围：Redis客户端重连与业务重试；先确认客户端及版本，连接重试和命令重试分开处理。厂商示例参数不能当作本项目推荐值。 将命令已执行但响应超时纳入分析，审查重试的幂等性，并防止多层重试放大请求。 检查步骤： 1. 列出哪些异常发生在连接、发送、执行或接收阶段，按现有证据区分确定未执行、确定执行和结果未知；网络超时本身不能证明写操作没有成功。 2. 逐条按业务结果审查命令重复执行的影响，特别检查递增、入队、计费和带过期语义的写入；即使命令形式相同，也要评估并发新值被旧请求覆盖的风险。 3. 追踪客户端、业务方法、接口网关和任务调度层是否各自重试，计算最坏请求次数与总耗时；为每个操作指定唯一的重试责任层。 4. 为可重试操作定义总期限、次数、退避及随机扰动，结合剩余预算和业务重要性决定何时停止；参数待压测时给出推导方式，不编造固定最优数值。 5. 对非幂等或结果未知的操作，设计业务请求标识、状态查询或对账路径，说明判重记录的生命周期与故障边界；不得仅套一把锁就宣称端到端恰好执行一次。 6. 仅在隔离测试环境或已明确授权的生产演练中验证发送前断开、执行后丢响应、主备切换及连续失败；优先使用代理或桩模拟故障，不扰动普通生产连接，记录业务动作次数、最终状态、请求耗时和重试放大量；验证恢复后积压不会再次冲击系统。 ## 交付与验收 输出要求：交付命令重试决策表、重试责任与预算、最小代码或配置、结果未知处理流程及故障用例。决策表写明“可重试条件｜重复后果｜停止条件｜人工或自动对账入口”。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 每类操作明确可重试条件、重复后果、责任层、总预算和停止条件。 - 结果未知有业务标识与查询或核对路径，不能仅以锁或重连成功证明幂等。 - 测试核对业务动作次数、最终状态和重试放大量；未执行的故障注入不写已验证。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里云《Tair：客户端重试指南》](https://help.aliyun.com/zh/redis/use-cases/retry-mechanisms-for-redis-clients) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
排查 Jedis 借用等待、连接池耗尽和连接增长，结合应用规模、命令耗时及实际版本评估参数。
## 任务目标 请排查 Redis Jedis 连接池容量和资源泄漏问题。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 连接池问题：从当前报错定位 Jedis 池或借还连接方法；没有指定时优先扫描直接借用 Jedis 的业务路径和共用连接池，检查异常与提前返回能否归还。 工程与连接记录：从依赖树、连接池配置、借还代码和已有池指标、异常记录获取资料，自动核对 Jedis 与 Commons Pool 的真实版本及参数单位。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查找 getResource、close、try-with-resources、提前返回及跨线程持有 Jedis 的路径。 - 读取 maxTotal、等待和空闲检测等实际参数定义及版本默认值。 - 汇总应用实例、业务池和分片数量，关联服务端连接限制与已有活跃、空闲、等待指标。 - 区分借用等待、建立连接和命令执行超时，查看慢命令或长任务占用证据。 ### 可采用的默认处理 - 默认只读检查资源生命周期，不扩大连接池、不重启应用或更换依赖。 - 缺 QPS 或耗时数据时先交付连接预算公式和需要观测的占用时间，容量值标待测。 - 按工程版本解读 API 与时间单位，不照搬 Jedis 2.9.0 示例参数或默认值。 ### 必须有依据的事项 - 目标业务的请求完成期限或允许等待时间无法确定时，不擅自改变借用超时与失败行为。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时提供正常、异常、提前返回与批处理的资源生命周期审查样例及版本核对入口。 - 无池指标时交付连接总预算表和最小观测方案，区分泄漏、慢占用与容量不足的证据。 ## 执行要求 适用范围：Jedis连接池及Commons Pool管理的客户端；官方页面示例基于Jedis2.9.0，必须核对实际版本API和默认值，不将该示例作为依赖升级建议。 结合应用规模、命令耗时和服务端限制评估池大小，核对借用资源是否归还；池耗尽不一定需要扩容。 检查步骤： 1. 准确区分连接建立失败、借用等待超时、连接已耗尽与命令执行超时，按首次出现时间关联应用发布、流量和数据库资源，避免把所有异常都解释为池太小。 2. 逐一核对正常、异常、提前返回和批处理路径中的资源归还，检查是否把Jedis实例跨线程共享或在长任务中持有；提出能定位泄漏的最小观测方式。 3. 统计每个应用实例、业务池与分片的连接总量，包含扩容、滚动发布时并存的实例，计算与服务端连接限制的关系，并保留必要余量。 4. 根据实际命令耗时与到达率估算所需并发连接，核对等待上限、空闲连接及检测配置；参数名称和时间单位必须匹配版本，不直接复制旧文档默认值。 5. 检查慢命令、网络、DNS和下游阻塞是否延长占用，分别说明调整池容量与消除根因的效果；需要预热时评估启动期间的集中建连压力。 6. 在代表性流量下验证借用等待、活跃连接、空闲连接、错误和服务端负载，覆盖突发、节点故障与恢复；记录每次配置变更和可撤回的旧值。 ## 交付与验收 输出要求：输出异常分类、资源生命周期、连接预算、参数建议及验证结果。参数表使用“当前值｜版本依据｜建议值或区间｜推导条件｜验证指标”，不得只给一组所谓通用最优参数。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 每个疑似泄漏关联借用者、持有路径、归还位置和可复现条件。 - 容量建议包含实例与分片总量、服务端限制、当前值、推导条件和待测指标。 - 不把池耗尽直接判为池过小，实测与静态风险分开报告。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里云《JedisPool资源池优化》](https://help.aliyun.com/zh/redis/use-cases/jedispool-optimization) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
用于热点商品、看板、配置和排行榜访问集中，区分读热点与写热点并验证一致性。
## 任务目标 请定位 Redis 热 Key 流量，并评审访问分散方案。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 热点业务：从当前问题或已有访问采样中选择集中访问的业务对象；没有热度证据时从调用代码识别热点候选，先建立观测窗口，不将大 Key 直接认定为热 Key。 工程与访问资料：读取 Key 生成与访问代码、缓存更新和回源链路、实例拓扑以及已有采样和监控记录，自动确认客户端、分片与可用观测能力。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 关联业务入口、Key 模式、读写调用和单 Key 所在分片。 - 读取同一时间窗口的访问频率、响应体大小、读写比例及集中来源。 - 追踪本地缓存、请求合并、TTL、更新失效和数据库回源策略。 - 核对实例类型与客户端能力，区分单 Key、单分片和全实例容量压力。 ### 可采用的默认处理 - 默认只读定位与方案评审，不复制热点数据、改分片或启用读写分离。 - 没有实测时只列热点候选及有预算的采样方法，收益作为待验证假设。 - 一致性要求未知时保留现有读取路径，缓存副本和本地短缓存仅作为附条件候选。 ### 必须有依据的事项 - 状态、库存、权限等读取是否允许陈旧及可容忍时间没有依据时，不选择牺牲一致性的分流方案。 - 热点缓存失效后的权威来源或业务失败行为不明时，不把无限回源或成功空结果当成降级。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有流量记录时交付热点证据采集表和单 Key、分片、实例压力的判别流程。 - 提供请求合并、限流、本地缓存与副本的条件对比，以及热点切换和更新失败的测试矩阵。 ## 执行要求 适用范围：Redis或Tair的访问热点处理；Key大小与访问热度分别判断。控制台能力和读写分离方案须核对实际实例类型与业务一致性要求。 定位单个 Key 所在的具体分片；选择热点复制或读写分离时，评估相应的一致性代价。 检查步骤： 1. 以业务入口和时间窗口确认访问集中在什么对象，区分单Key高频、单分片集中与全实例容量不足；离线数据大小不能作为访问频率的证据。 2. 结合应用采样与已有实例指标识别真正热点，记录读写比例、响应体大小、请求集中来源及下游行为；采集本身要有资源预算，避免无限记录所有请求。 3. 区分可短暂陈旧的读取与必须保持最新的状态决策，说明缓存未命中或热点失效时的回源承载量；写热点不要用只读扩容冒充解决方案。 4. 比较请求合并、业务限流、本地短缓存、热点副本或业务拆分，分别列出适用前提、更新成本与失败行为；不默认采用所有方案，也不只计算理论吞吐。 5. 为候选方案定义缓存更新、版本识别、失效与恢复流程，说明多副本之间可能短暂不一致时用户会看到什么，以及如何避免旧值长期残留。 6. 用正常流量、突发热点、热点切换和更新失败验证效果，记录单分片压力、用户延迟、错误和回源次数；上线先覆盖可控业务范围，保留快速撤回方案。 ## 交付与验收 输出要求：输出热点证据、读写分类、候选方案对比、流程与验证矩阵。结论必须说明获得的容量改善与牺牲的一致性或复杂度，未经实测的收益仅作为待验证假设。 只报告有证据支持的问题；区分“已验证”“推测”和“待验证”，涉及变更时给出受影响文件或对象、最小修改和复核方法。代码与操作示例使用占位符，不写入真实密码。 ### 本条完成检查 - 热度结论有对应时间窗口和分片证据，读热点与写热点分别处理。 - 候选方案明确失效更新、旧值退出、回源压力和一致性代价。 - 测量覆盖延迟、错误、分片压力和回源次数，未经测量不写容量提升数字。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 来源（核验日期：2026-09-08）： [阿里云《Tair：大Key和热Key》](https://help.aliyun.com/zh/redis/user-guide/identify-and-handle-large-keys-and-hotkeys/) 整理范围：仅依据上述公开文档的相关建议，业务场景、变量、检查流程与验收格式均为独立改写，不代表相关企业完整内部规范。
