@luke
检查 Nginx 请求路径、Host、转发头与站点隔离，定位多站点反向代理问题。
## 任务目标 请审查 Nginx 到业务服务的完整请求链路，定位路由冲突和代理配置问题，给出与当前环境一致的修改。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 代理入口：从当前对话的域名或请求路径定位目标；留空时先盘点相关 server 与前端 API 前缀，选择一条存在配置冲突或路径疑点的请求链路进行审查。 配置与请求资料：从工作区读取 Nginx include 和站点配置、前端路由与请求封装、应用监听配置，以及已有响应和访问日志，自动补全代理拓扑。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 解析 server_name、默认站点、location 优先级及 proxy_pass 的 URI 处理。 - 对照首页、深层路由、API、上传和静态资源的真实路径与上游处理入口。 - 检查 Host、HTTPS SNI、转发协议、可信代理范围及认证头的目标。 - 读取已有请求响应与其他同机站点配置，确认变更影响范围。 ### 可采用的默认处理 - 默认只读给配置差异与请求矩阵，不执行重载、改域名或改监听范围。 - 沿用真实路径和上游契约，不用统一重写或前端首页响应掩盖 API 错误。 - 没有响应证据时将冲突列为假设；缓冲、连接复用和超时保留现状，不复制 OSS 专用值。 ### 必须有依据的事项 - 入口 URI 应如何映射上游、前端深层路由与 API 的约定冲突且无权威依据时，不猜测改写目标。 - 可信代理边界或第三方上游接收认证信息的权限不明时，不新增对转发头的信任或透传秘密。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 仅有域名或路径描述时交付请求逐跳核验方法、带占位符的配置对照和预期响应矩阵。 - 没有完整拓扑时列出 location 匹配及末尾斜杠的条件分析，不宣称已定位现场根因。 ## 执行要求 1. 画出浏览器到实际服务的路径，注明每跳协议、端口、Host 和 URI。先识别已有配置继承和 location 匹配关系，再判断命中的站点。 2. 分别跟踪首页、前端深层路由、API、上传与静态资源。用具体请求展示转发前后 URI，核查 proxy_pass 路径及末尾斜杠是否符合接口契约，避免把接口错误转成前端首页。 3. 检查上游 Host、HTTPS SNI 和原始协议的传递。使用 OSS 时按其域名要求验证；普通 Java、Python 服务按实际虚拟主机约定处理，不机械复用 OSS 示例值。 4. 明确可信代理名单和真实客户端地址的来源。审查应用对转发头的信任边界，避免直接信任公网客户端伪造的地址或协议头；检查认证信息是否被不必要地复制到第三方上游。 5. 根据实际响应规模、并发、上传和业务超时确定连接复用及缓冲策略。分别说明连接失败和慢响应的观测办法；不要用统一的大超时掩盖应用瓶颈。 6. 对修改前后分别执行同一请求矩阵，校验状态码、响应类型、重定向地址和关键业务内容。补充同机其他站点的回归检查及配置恢复步骤。 ## 交付与验收 输出：请求路径对照表、按证据排序的问题、必要配置差异、验证请求与预期响应。没有实际请求证据时，只提供诊断假设和下一步取证方法。 ### 本条完成检查 - 给出每类请求的转发前后 URI、Host、协议和状态预期。 - 配置建议有对应证据，覆盖 API 不被替换成首页、跳转正确及相邻站点回归。 - 说明真实客户端地址与认证头的信任边界，并区分已观察结果和待执行请求。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 - [阿里云 · Access OSS through an ECS Nginx reverse proxy](https://www.alibabacloud.com/help/en/oss/user-guide/access-oss-through-ecs-reverse-proxy) 核验日期：2026-09-08。依据公开资料改写的执行模板；原文限定 OSS 代理场景；普通业务反向代理的检查步骤为本站扩展。
依据真实用例和缺陷记录编写版本测试报告，核对统计口径、未测范围与遗留风险，并按团队验收条件给出交付建议。
## 任务目标 请依据真实执行证据编写简明版本测试报告。报告供业务负责人判断交付准备情况。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 报告版本：优先采用当前待交付版本；未明确时，从已有执行记录选择最近一组可确认构建与环境的结果编写报告，并将其他版本结果分列，不将当前代码版本自动视为已测版本。 执行与验收资料：读取当前工程或已授权项目资料中的测试计划、测试产物、缺陷及复测记录、需求范围和验收约定，自动提取版本、时间、终端、角色与统计口径。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 定位已有测试报告及原始执行记录，核对用例、构建、环境、终端、角色和关键数据集的组合。 - 关联需求清单与执行证据，区分构建检查、静态检查、前端检查和真实业务验证。 - 核对未关闭缺陷和修复版本的复测证据，查找团队已经约定的版本验收条件。 ### 可采用的默认处理 - 默认只读汇总证据，同组重复执行保留历史，跨终端或跨角色的通过结果不覆盖其他组失败。 - 没有明确验收门槛时给出准备情况和条件建议，不自行设定门槛后宣布验收通过。 - 统计同时写清用例数与执行实例数，未执行、阻塞和缺证据分别保留，不纳入通过项。 ### 必须有依据的事项 - 执行记录无法识别版本或统计分组时，不能生成该版本的确定性通过数量；先交付可确认组别的结果。 - 业务验收条件未确定或存在相互冲突的正式要求时，不能代替业务签收或批准发布。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有执行数据时交付按需求组织的报告框架、证据登记口径和未测范围，不填示例通过率。 - 只有部分记录时完成对应版本与场景的局部结论，列明剩余证据、遗留缺陷及重新评价条件。 ## 执行要求 报告中的用例和缺陷应能追溯到测试计划与执行记录；版本结论按团队验收条件判断，不代替业务签收或上线批准。 1. 明确报告对象、版本、测试环境、执行时间和数据截止时间，核对每份记录所属版本。不同构建或环境的结果分别列出，不用旧版本通过结果替代当前版本。 2. 按用例 ID、构建版本、环境、终端、角色及关键数据集组合分组，仅在同组内归并重复执行并保留历史。跨组失败分别保留，不能用 Vue 端或管理员通过覆盖小程序端或普通角色失败。统计区分用例数与执行实例数，明确通过、失败、阻塞和未执行口径，给出可复算数量。 3. 将已确认需求逐项映射到对应执行证据，列出没有用例、没有执行记录、只有静态检查或只测前端的范围。构建成功、页面可打开和核心业务通过应分别表述。 4. 整理未关闭缺陷的影响对象、业务后果、临时措施和复核状态，检查所谓已修复是否有对应版本的复测证据。只有修复说明而没有执行记录时标为待验证。 5. 按团队已提供的验收条件逐项判定满足、不满足或证据不足。条件缺失时提出建议并单独列出，不能先自行设门槛再宣称版本已经满足业务验收。 6. 生成发布准备建议和后续工作，每项写责任角色、所需证据和重新评估条件。需要正式业务确认的事项清楚列出，不冒充项目负责人已经批准发布。 ## 交付与验收 输出：版本与环境、覆盖范围、执行数量及统计口径、需求验证表、遗留缺陷、未测或阻塞范围、验收条件判定、交付建议与后续动作。用短句和必要表格，不添加夸大总结。 验收：所有数字可从执行记录复算；未测和阻塞不会计为通过；所有通过结论对应当前版本证据；风险可理解可追踪；没有伪造性能、兼容性或安全结论。 信息边界：没有执行数据时只输出待填写框架和材料缺口，不填示例通过率；本任务不自动发布版本、替业务签收或向团队发通知。 ### 本条完成检查 - 所有数量可从真实记录复算，统计分组、分母和数据截止时间明确。 - 通过、失败、阻塞、未测和待复核分别有据，旧版本或管理员结果不覆盖其他范围。 - 交付建议逐项对应团队条件和遗留风险，报告不替代正式业务签收。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [云效 Testhub：快速入门](https://help.aliyun.com/zh/yunxiao/user-guide/quick-start)
整理可复现的缺陷记录，写清预期与实际差异、证据、影响范围及修复复核条件，避免仅凭截图判断根因或将未回归的问题标为关闭。
## 任务目标 请将测试发现整理成研发能够定位、测试能够复核的缺陷记录。可处理单个缺陷或去重后的问题清单。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 待核对问题：优先处理当前会话最近明确的问题；没有单独指定时，从当前版本已有失败日志或缺陷清单中选择证据最完整的一项开始，按业务影响继续整理相关问题。 问题证据：读取会话已有现象、截图和日志，以及目标工程中对应需求、用例、接口和修复记录，自动关联版本与操作上下文；不要求用户重新抄录可直接读取的错误信息。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对每份截图、日志或接口记录的版本、终端、账号角色、组织及时间，避免合成不存在的单次事故。 - 沿现象定位需求条目、关联用例和最小操作路径，查清预期结果的来源。 - 查已有修复记录、相关变更和复测产物，区分修复声明与实际回归证据。 ### 可采用的默认处理 - 先只读整理证据与复现步骤；真实操作复现仅在已授权的隔离条件内执行，未执行则标为材料复现描述。 - 严重程度与优先级依据实际业务影响给出建议，根因事实、假设和排查方向分别记录。 - 相似问题按触发条件及实际结果去重，保留原始证据入口，交付记录中的身份和凭据信息脱敏。 ### 必须有依据的事项 - 需求无法确定预期行为或与现实现象对应的规则冲突时，不能把偏好直接判定为缺陷；先记录差异和影响。 - 复现需要真实支付、删除或生产写入且无可用隔离条件时，不执行该操作；继续交付最小步骤与隔离数据要求。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有运行环境时交付前置条件、最小复现步骤、预期与实际对照、已有证据和针对性排查顺序。 - 没有修复版本时交付原场景及相邻功能的复测条件，状态保持待修复或待验证，不虚报关闭。 ## 执行要求 将需求、用例、复现证据和缺陷关联起来，关闭条件以约定的复测与回归要求为准。 1. 核对问题出现的版本、终端、账号角色、组织范围和时间，确定证据对应同一次操作还是不同执行。资料冲突时列出冲突，不把截图、日志和需求拼成不存在的单次事故。 2. 用最少而完整的步骤重建前置条件与操作路径，每一步写清对象、输入和动作。能实际执行时记录复现次数与结果；不能执行时标记为材料复现描述。 3. 并列写出需求支持的预期结果与已观察的实际结果，分别说明页面、接口和数据层证据。缺少规则依据时标为待确认行为，不能把个人偏好直接判为缺陷。 4. 分析受影响角色、业务流程和数据范围，按团队已有定义建议严重程度与修复优先级。把根因事实、待验证假设和排查方向分开，避免仅凭报错猜定数据库或缓存故障。 5. 对相似问题按触发条件、实际结果和可能影响合并，保留关联用例与原始证据入口。日志和截图中的身份信息、令牌与密码应在交付记录中脱敏。 6. 有修复版本时，设计原场景复测和相邻功能回归，记录实际执行证据。只有满足复现用例和约定回归条件才能建议关闭；仍有问题则说明重新打开的依据。 ## 交付与验收 输出：缺陷标题、关联需求或用例、环境版本、前置条件、步骤、预期与实际、证据、影响与优先级理由、排查假设、复核条件、当前状态。修复复核记录独立保留时间和版本。 验收：第三方可按记录尝试复现；预期有依据；证据可定位且不泄露凭据；状态符合实际；没有把建议排查写成已证实根因或把未执行回归写成通过。 信息边界：缺少运行条件时明确无法复现的原因；不替研发承诺修复时间，不未经授权修改外部缺陷状态或向其他人发送消息。 ### 本条完成检查 - 第三方能依据记录尝试复现，步骤、版本、对象和预期均有来源。 - 证据与判断分开，根因未证实就保留假设，敏感信息已脱敏。 - 建议关闭的缺陷具有对应修复版本的实际复测与约定回归证据，缺失部分明确列出。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [CODING DevOps：测试管理](https://cloud.tencent.com/document/product/1726/96965)
按版本变更影响选择测试用例，安排环境和责任角色，明确阻塞处理、回归范围及执行状态的统计口径。
## 任务目标 请制定本次迭代可执行的测试与回归计划。计划范围必须与真实变更相对应。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 迭代测试目标：从当前迭代、待合入改动或版本说明识别测试目标；未给范围时，以当前已确认工程的本次变更及其直接关联业务链路作为计划范围，明确比较基准和排除项。 变更与用例资料：读取现有需求、代码差异、配置与数据变更、用例库、已知缺陷和测试安排，自动识别终端、依赖与环境前提。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对版本标识和实际比较基准，读取模块、配置、数据结构及依赖变化。 - 从用例库和历史高风险缺陷中寻找与变更链路相关的场景，记录入选和排除依据。 - 查项目已有测试环境、账号角色、终端矩阵、责任安排及发布时间约束，不推测人员可用性。 ### 可采用的默认处理 - 按业务阻断、数据正确性、权限边界和常用路径安排优先顺序，再区分冒烟、功能验证与回归。 - 人员和窗口未知时使用责任角色与依赖顺序，不编造具体姓名、工期或发布日期。 - 默认只制定计划，不启动测试或改变工作项状态；计划中未执行、失败和阻塞的记录方式提前明确。 ### 必须有依据的事项 - 变更前后基准无法识别时，不能声称已覆盖完整回归范围；先按已见需求和文件列出局部影响。 - 关键业务流程或跨系统依赖存在冲突而无法确定预期结果时，需确认对应规则后再将该场景设为正式通过条件。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有代码差异时，依据需求变更生成业务链路测试计划，标明尚待技术影响分析的模块。 - 没有环境或人员安排时交付用例选择、优先级、前置数据、环境需求和分组执行顺序。 ## 执行要求 将测试计划关联到当前项目和迭代，按变更选择用例并记录状态及缺陷；执行优先级、准入和退出条件以项目约定为准。 1. 确认版本标识、变更模块、配置和数据变化，建立变更到业务链路的影响关系。缺少代码差异或依赖信息时列出证据缺口，不声称已经覆盖所有受影响模块。 2. 从用例库选择新功能、变更功能、关联功能和历史高风险缺陷对应的用例，记录入选原因与需求关联。未选中的相关用例说明理由，避免把回归范围简单设为全部或随意抽查。 3. 按业务阻断、数据正确性、权限边界和常用路径安排顺序，区分冒烟、功能验证和回归。结合接口、后台页面、小程序等真实终端列出环境和账号需求。 4. 为每组用例设置责任角色、执行窗口、前置数据和依赖，资源未知时使用待分配项，不编造具体人员承诺。环境、证书、域名和组件版本须对应被测版本。 5. 定义未执行、执行中、通过、失败和阻塞的含义，并说明失败与阻塞如何记录证据、关联缺陷及安排复测。复测只能覆盖实际修复版本，保留先前失败记录。 6. 提出本次版本的完成条件和剩余风险处理方法，统计状态时明确分母及去重方式。阻塞、暂缓或跳过不能被计作通过，不用高通过率掩盖核心场景未执行。 ## 交付与验收 输出：测试范围与排除项、变更影响表、用例选择及顺序、环境和人员安排、执行记录规则、复测计划、完成条件、风险与缺口。时间安排注明依据与可调整条件。 验收：范围可追溯到变更；关键场景有负责人和前提；状态含义无歧义；回归对象明确；计划中的能力和资源有依据；未执行项可见。 信息边界：该任务产出计划，不自动执行测试或改动工作项状态；如果用户另行授权执行，必须依据真实运行记录更新结果。 ### 本条完成检查 - 每组用例可追溯到变更、需求或历史风险，排除项有理由。 - 终端、版本、环境、账号和数据前提明确，未知资源保留待分配状态。 - 复测与完成条件能实际执行，统计不把暂缓、阻塞或跳过计为通过。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [云效 Testhub：测试计划](https://help.aliyun.com/zh/yunxiao/user-guide/test-plan-1)
从需求、角色、状态与边界条件编写可复现的测试用例，覆盖 Java、Vue、小程序等业务链路，明确前置条件、操作步骤和预期结果。
## 任务目标 请根据真实需求设计业务测试用例。产出可供人工执行或继续编写自动化测试，不把编写用例等同于执行通过。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 被测业务：从当前需求或最近明确的功能改动识别被测业务；未指定功能时，以现有页面到接口的一条完整业务链路为起点，先覆盖有明确规则的正常流程与关键异常。 需求与工程资料：读取当前目标模块的需求、页面、接口定义、字典、权限与已有用例，自动提取角色、状态、字段边界和终端范围。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 定位需求编号、字段规则和状态转换，核对页面、接口与文档是否存在预期冲突。 - 查已有用例及测试数据构造方式，复用相同验证目的的记录并保留真正不同的边界。 - 沿列表、详情、写入、导出和统计读取数据范围与授权校验，识别跨租户和普通角色场景。 ### 可采用的默认处理 - 每个已确认规则先生成最小正常用例，再按实际适用性补充空值、边界、异常、并发及权限场景，不靠数量凑覆盖。 - 初始执行状态统一为未执行，优先级由业务损失与使用路径决定；代码现状与需求冲突时不默认现状正确。 - 测试数据采用可清理的隔离记录，真实支付、删除与生产写入只列必要隔离前提，不直接执行。 ### 必须有依据的事项 - 核心计算、状态转换或字段含义缺乏明确依据时，不能自行写成正式预期；继续完成其他有规则的用例。 - 角色或组织的数据归属无法确定时，不能猜测合法可见范围，应把相关用例列为权限规则待确认。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有需求没有工程时，交付带来源位置的业务用例、规则缺口与接口验证需求。 - 没有环境时仍交付可执行的前置条件、数据、步骤、预期和清理要求，并标明自动化候选的依赖。 ## 执行要求 按产品模块组织用例，写清前置条件、操作步骤和预期结果；覆盖范围应与当前工程需求对应。 1. 从需求提取可验证的业务规则，为每项规则保留需求编号及原文位置。区分正常功能、错误处理、权限、数据和兼容性，标注没有定义预期结果的规则缺口。 2. 按产品、模块、功能和场景组织用例，检查现有用例能否复用。删除仅名称不同但验证内容相同的重复项，并保留真正不同的业务边界。 3. 为关键业务写正常路径，注明角色、登录状态、组织、测试数据和前置记录。每一步操作应可重复执行，预期结果同时包含页面表现与必要的数据变化。 4. 补充必填、范围上下界、空值、重复、状态不合法、并发修改、网络中断和接口失败等适用条件。不存在业务需求的场景标为建议核实，不为凑数量添加无效用例。 5. 针对多组织或多租户系统，分别验证列表、详情、接口、导出和统计的数据边界。前端隐藏按钮不能替代服务端拒绝越权请求的预期结果。 6. 根据业务影响确定执行优先级和自动化候选，注明环境依赖及数据清理方式。涉及支付、删除或生产写入的验证先设计隔离条件，避免用真实业务记录凑测试材料。 ## 交付与验收 输出用例表：编号、需求编号、模块、标题、优先级及理由、前置条件、测试数据、操作步骤、预期结果、环境依赖、执行状态。初始执行状态统一为未执行；另列规则缺口和建议。 验收：每项已确认规则有对应验证；步骤可复现；预期结果可观察；角色和组织边界明确；无伪造结果、截图或接口响应；不以用例数量代替覆盖质量。 信息边界：没有环境或执行权限时只生成用例；未知规则不能自行变成验收标准，自动化适用性也应说明依赖。 ### 本条完成检查 - 已确认规则都有可观察的预期与来源，用例步骤可复现且数据前提明确。 - 角色、组织、状态及关键异常得到针对性覆盖，重复用例已合理归并。 - 用例设计与执行结果明确区分，没有伪造截图、响应或测试通过状态。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [云效 Testhub：快速入门](https://help.aliyun.com/zh/yunxiao/user-guide/quick-start)
统一按钮、状态、提示、金额和时间的中文表达，保持业务页面简洁准确，清楚区分零值、空值、未知与无权限。
## 任务目标 请审查并改写业务页面中的中文文案和数据表达。面向中国大陆企业用户，语言准确、简短、可操作。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 文案检查范围：优先检查当前提到的页面或文案；没有指定时，从现有业务入口到主要操作结果的页面链路开始，覆盖该链路共用的按钮、状态、错误和数据格式。 页面或文案资料：读取当前工程的页面、语言资源、字段类型、格式化工具与字典，同时使用已有截图和导出样例，直接从上下文识别对象、动作及格式约定。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查页面和语言资源中的标题、导航、按钮、提示及状态，与实际触发动作对照。 - 核对接口字段、字典和金额日期格式化工具，定位单位、精度、时区和百分比分母的依据。 - 比较详情、列表、通知与导出中的同一业务用词，查看长中文、截断及空值的已有表现。 ### 可采用的默认处理 - 默认只读审查并给可直接替换的文字；用户已明确要求修改时只落地指定范围，不改变计算逻辑或业务状态。 - 优先沿用项目已确认术语，按钮写具体动作，错误写问题和可行恢复方式，去除无业务作用的口号与重复解释。 - 未知、未统计、零值、无权限和加载失败分别表达；没有字段依据时保留原始数值，不擅自补单位、改精度或改时区。 ### 必须有依据的事项 - 专业术语对应的业务动作或法律含义不明时，不能凭通顺直接替换；先整理其他有上下文的文案。 - 金额单位、比例分母或时间语义互相矛盾时，不能输出确定的新格式，需确认该字段的真实口径。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有截图时交付可见文案的原文、建议和理由，以及截图未覆盖的触发状态清单。 - 没有页面运行条件时交付术语表、数据格式规则和逐项替换建议，标明换行及交互含义仍需页面验收。 ## 执行要求 术语和显示格式以真实业务与项目约定为准，优先保证表达一致、含义准确，不能把默认样式当作行业法规要求。 1. 列出标题、导航、字段、按钮、状态、帮助、错误和空状态，标明所在页面及触发场景。先确定文案服务的业务动作，删除无业务作用的宣传和重复解释。 2. 建立业务术语表，区分申请、提交、审批、确认、完成等动作和状态。相同对象使用一致称呼，不同业务结果不要都写成“成功”或“已处理”。 3. 把按钮改成用户能够预测结果的动作名称，重要操作说明作用对象及关键后果。错误提示写清问题与可执行办法，不直接展示服务端异常信息或含混的系统忙。 4. 梳理数量、金额、百分比、日期、时刻、单位和小数精度，注明显示与计算是否不同。时间说明时区，百分比注明分母，金额保留货币信息，不能凭显示格式改变原始精度。 5. 分别定义零、空、未统计、加载失败和无权限的表达，避免统一显示为零或短横线造成误解。历史数据和当前数据混合展示时让用户能识别时间范围。 6. 逐页检查长中文、标点、数字与单位间距、截断后的完整信息获取，以及同一业务在通知、详情和导出中的一致性。只改文字时仍需核对操作含义没有被改变。 ## 交付与验收 输出：原文—建议文案—理由对照表、业务术语词典、数据格式表、空值与异常表达、需业务确认的问题。修改建议可直接交给页面维护人员使用。 验收：关键动作和后果清楚；同一状态同名同义；单位与时间范围明确；无空洞口号、虚构规模和夸大承诺；格式变化不会改变业务含义。 信息边界：缺少字段定义或上下文时不要硬改专业术语；未获得完整页面和导出样例时注明检查范围，不声称已覆盖所有终端。 ### 本条完成检查 - 文案对应真实对象、动作及后果，同一状态同名同义，修改不改变业务含义。 - 单位、时间范围、精度及空值含义有依据，未知内容不被格式化成零或成功。 - 每处建议可定位到页面或资源项，检查范围清楚，不把局部文本审查称为全端验收。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 文案](https://ant.design/docs/spec/copywriting-cn/) - [Ant Design 数据格式](https://ant.design/docs/spec/data-format-cn/)
梳理现有组件与主题能力，统一桌面端和小程序的业务语义、视觉变量与状态规则，明确各终端的交互差异和交付要求。
## 任务目标 请为桌面管理端与小程序建立一致而可实现的组件使用约定。目标是减少同类页面的视觉和交互偏差。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 组件统一范围：从当前桌面端和小程序中承担相同业务任务的页面识别范围；未指定组件时，先整理已有查询区、状态、选择器、附件和操作栏，不新增不存在的终端。 工程或设计资料：读取现有包版本、组件引用、业务封装、主题变量和页面样例，使用已提供品牌资料识别共同规范与跨端差异。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查两端实际组件包、锁文件和封装入口，核对当前版本支持的组件 API 与样式配置机制。 - 定位同类业务组件的使用页面，比较输入、状态、权限与操作结果，不只比较外观。 - 盘点主题变量、局部样式覆盖与已有设计稿，找出重复定义、不同业务同名及触屏不可用的交互。 ### 可采用的默认处理 - 沿用现有组件库与版本，先给使用约定和差异映射，不为统一外观引入第二套库或升级框架。 - 跨端统一业务含义、状态名称与主次操作，保留表格和移动记录卡、点击和触摸等必要呈现差异。 - 优先复用现有视觉变量，缺值时提出少量项目建议；颜色、字号和间距不包装为组件库强制规则。 ### 必须有依据的事项 - 两端同一字段或状态的业务含义不同且无法从契约解释时，不能直接合并为通用组件。 - 实际安装版本或 API 支持无法确认时，不能承诺对应代码可运行；先交付组件职责和状态约定。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只获得一端工程时，先交付该端盘点及已知跨端业务约定，把另一端的 API 与适配核对留为明确缺口。 - 只有设计资料时交付业务组件映射、变量建议、状态矩阵和交接样例，不声称完成代码兼容验证。 ## 执行要求 主题、设计变量和组件 API 均以项目安装版本为准；跨端统一的是业务含义和使用约定，不能假定不同组件库的 API 相同。 1. 盘点项目实际使用的组件库、版本、定制组件和样式覆盖，区分已经存在与建议新增。先确认项目选择，优先复用已有组件库。 2. 建立业务组件清单，将查询区、审批状态、附件区、成员选择、操作栏等映射到基础组件或组合组件，注明适用场景和不适用场景。名字应能让设计与研发直接对应。 3. 整理颜色语义、文字层级、间距、边框、圆角与控件密度，优先使用当前库的可配置变量。必须自定义时解释业务原因，变量值来源未知的标为建议。 4. 定义组件的默认、悬浮、聚焦、禁用、加载、错误和只读状态，明确哪些状态适用于触屏。不能把鼠标悬浮作为小程序读取重要内容的唯一方式。 5. 逐项区分跨端保持一致的业务含义与需要因终端改变的呈现，例如审批结果名称一致，但桌面表格与手机记录卡可不同。明确点击、触摸、返回和输入法下的行为。 6. 形成设计到研发的对照与验收样例，列出长中文、空值、大数值、无权限、弱网等内容条件。核验组件 API 应基于安装版本文档，不能凭名称推断支持属性。 ## 交付与验收 输出：现有组件盘点、业务组件映射、视觉变量建议、状态矩阵、跨端差异表、设计交付与验收清单。涉及代码时仅使用已核实版本支持的能力。 验收：相同业务状态名称与含义一致；视觉变量有来源；终端差异有任务依据；不存在组件库混用造成的重复样式；小程序任务不依赖桌面专有交互。 信息边界：未读取实现或未运行终端时不得声称完成兼容验证；官方仓库说明只能证明其公开能力，不能作为对本项目质量或合规性的品牌背书。 ### 本条完成检查 - 组件映射有真实使用位置，相同状态的名称与含义一致，例外有业务理由。 - 变量、版本与能力来源明确，不假设不同组件库 API 相同。 - 触屏任务不依赖悬浮等桌面专有操作，长中文、空值、无权限及弱网样例进入验收清单。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Arco Design 官方仓库中文说明](https://github.com/arco-design/arco-design/blob/main/README.zh-CN.md) - [TDesign 官方仓库](https://github.com/Tencent/tdesign)
为异步办理、失败、中断和部分成功设计适当反馈，明确状态来源、数据影响与恢复动作，避免无依据的进度和重复弹窗。
## 任务目标 请为业务操作补齐完整的反馈与恢复设计。覆盖从操作触发到最终结果的真实过程。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 反馈设计范围：从当前页面的主要提交或异步办理动作开始；未指定操作时，沿已有请求到结果呈现的链路盘点反馈缺口，优先处理结果不明和无法恢复的状态。 页面与状态资料：读取现有页面、请求封装、接口状态定义、错误映射和任务查询逻辑，自动获取成功判据、重试条件与上下文保留方式。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 追踪按钮触发、请求发送、任务受理、查询或回调到最终结果的实际路径。 - 核对 loading、提示、弹窗及错误处理的现有逻辑，检查页面切换、账号失效与部分失败。 - 查取消、重试、幂等键、请求标识和结果查询接口是否真实存在，区分能力说明与未实现建议。 ### 可采用的默认处理 - 有明确结果才显示成功，超时或回调缺失默认保留结果待确认，不自动重发非幂等写操作。 - 按影响范围选择行内或页面反馈，只有确需用户决定时使用对话框，不为每次成功重复打断操作。 - 无真实进度时使用处理中的状态描述；错误保留有用上下文与安全的恢复入口，不用自动跑满的百分比。 ### 必须有依据的事项 - 服务端是否已经生效、是否可重试或取消无法确定时，不能替系统承诺撤销、重新提交或完成；继续设计结果待确认及查询路径。 - 错误码缺少业务含义或同码含义冲突时，不能臆造具体原因，需确认影响数据及可恢复动作。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无接口实现时交付操作状态矩阵、逐条中文反馈及恢复流程，明确结果查询和幂等能力的接入要求。 - 只有错误记录时交付可确认错误的文案与恢复建议，并将无法判断的状态单列，不声称故障已修复。 ## 执行要求 反馈应及时、适度，过程与结果分别表达；异常分类和恢复动作必须匹配系统实际能力。 1. 逐个记录操作的触发位置、影响对象、耗时依据、成功判据和数据刷新方式。没有服务端最终结果时区分已接收、处理中与已完成，禁止点击后立即伪装成功。 2. 列出空闲、提交中、处理中、成功、失败、部分成功、中断、结果未知或待核实等适用状态，指定每种状态的可信来源和退出条件。不存在的后端状态不能直接当作现有能力。 3. 结合影响范围与用户必须采取的行动选择行内提示、页面提示、轻提示、结果页或对话框。成功后内容已明显变化时减少重复提醒，重要失败应保留可找回的信息。 4. 为每种错误写清楚发生了什么、对已填写或已处理数据有什么影响、现在可以做什么。网络异常、权限不足、规则冲突、记录不存在和服务异常分别处理。 5. 设计重试、刷新、取消、继续编辑和查看详情入口，注明可用条件、操作后果和上下文保留。重复请求可能产生重复业务记录时必须列出幂等条件。 6. 检查多任务同时执行、页面切换、刷新、账号失效和部分项目失败的表现。进度只显示真实可得的进度，不能使用自动跑满的百分比造成办理完成错觉。 ## 交付与验收 输出：操作状态矩阵、反馈组件选择表、逐条中文文案、恢复流程、接口或任务能力缺口、验收场景。文案以业务信息和下一步动作为中心，避免责备用户。 验收：已知终态有可信依据；结果未知时保留原请求标识，通过查询、回调或对账确认，确认前不自动重发非幂等操作；重要错误不丢失；重试不会默认制造重复记录；部分成功能定位失败对象；不存在无依据进度和频繁无用弹窗。 信息边界：仅有错误码而无业务含义时保留待映射项；不猜测故障根因，不声称错误已经修复，不在用户文案中泄露内部日志、凭据或敏感数据。 ### 本条完成检查 - 每种终态有可信来源，结果未知保留请求标识并有确认办法。 - 反馈能够说明数据影响与下一步，重试和取消条件真实，部分失败可定位到对象。 - 关键异常、多任务和页面切换均有处理规则，不丢失重要错误或生成假进度。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 反馈](https://ant.design/docs/spec/feedback-cn/)
为中文后台和复杂业务录入设计字段分组、校验、提交、保存与恢复规则，让用户清楚填写要求和操作后果。
## 任务目标 请把业务字段设计为易理解、可正确提交的中文表单。目标是完成真实录入任务并明确操作后果。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 表单任务：优先采用当前提到的办理任务；未指定表单时，选择现有主要业务入口中的新增或编辑表单，围绕其真实保存与提交路径整理字段和交互。 字段与页面资料：读取目标表单、接口请求类型、校验规则、字典及保存逻辑，结合已有业务说明和设计样例识别字段分组、联动和权限。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 从表单组件、接口 DTO 和校验规则提取类型、必填、范围及错误触发时机，核对两端规则差异。 - 追踪联动字段、默认值、只读条件和历史字典值，查看上游变化是否会清空下游数据。 - 核对草稿保存、正式提交、取消、重置和再次进入的真实行为，以及失败后输入是否保留。 ### 可采用的默认处理 - 沿真实填写顺序分组，复用已有控件和字段命名；任务没有明显阶段时不强行拆成多步骤表单。 - 保持业务默认值不变，未知或停用字典值保留原值并可识别，不自动选择第一项。 - 错误就近说明并可定位，失败保留合理输入；缺少草稿能力时不显示已经自动保存。 ### 必须有依据的事项 - 字段默认值、唯一性或跨字段规则无法从业务与接口确定时，不能自行写入正式校验标准。 - 保存与正式生效、取消后的数据后果不明时，不能承诺丢弃或保留结果；先完成不依赖这些决定的字段组织。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有工程时，根据已有字段资料交付分组结构、字段表、联动与错误文案及保存提交状态设计。 - 运行条件不足时交付键盘顺序、首错定位、长标签及移动输入的验收场景，标明尚未执行。 ## 执行要求 字段表达、组件使用和任务顺序保持一致，校验与恢复规则以业务要求和系统能力为准。 1. 说明表单标题、处理对象、填写角色及最终结果，按用户收集信息的顺序分组字段。只有任务确实复杂时才拆步骤；步骤标题使用业务动作或信息类别。 2. 为每个字段确定标签、组件、必填条件、数据来源、默认值、示例和帮助。避免标签与占位提示机械重复；专业术语确有必要时提供简短解释。 3. 明确输入格式、合法范围、跨字段条件、远程校验和错误触发时机。客户端提示与服务端规则应保持一致；已有数据不符合新规则时另列兼容处理问题。 4. 设计联动字段、只读字段与不可用选项，说明上游变化是否清空下游值、是否提醒用户及是否保留历史选项。不要悄悄替用户选择会改变业务责任的默认项。 5. 分别定义保存草稿、提交生效、取消、返回和重置的后果，说明提交中的按钮状态、重复点击防护、失败后的输入保留，以及长任务中断后的恢复入口。 6. 走查键盘顺序、首个错误定位、必填标识、长标签和移动端输入。每种校验失败给出用户能执行的修改办法，避免以技术异常堆栈代替业务提示。 ## 交付与验收 输出：表单分组结构、字段设计表、联动与校验规则、保存及提交状态、错误文案表、主要操作流程和验收清单。涉及接口能力的要求单独标注。 验收：每个字段有业务含义；同类字段组件一致；用户知道数据何时生效；失败不会无故丢失输入；错误可定位且可修正；无多余的口号和教学文案。 信息边界：无法从业务资料确定的默认值、唯一性和草稿保存能力不能自行假定；没有真实运行证据时只报告设计检查，不能写为表单测试通过。 ### 本条完成检查 - 字段含义、来源、组件与校验时机明确，默认值和联动行为有依据。 - 用户能理解何时保存和生效，提交失败可纠正并保留合理输入。 - 取消、返回、重复点击和历史字典值均有明确规则，设计走查不冒充运行测试。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 表单页](https://ant.design/docs/spec/research-form-cn/)
围绕查找、比较和批量处理设计筛选、表格列、分页、明细及操作反馈，补齐权限、空结果、长文本与异步状态。
## 任务目标 请设计能够直接支持业务查询和处理的列表页面。选择表格或列表应服务于用户查找与判断。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 列表业务：从当前业务对象和主要查询页面识别目标；未指定页面时，以现有业务入口可达的主列表为范围，沿查询、查看详情和一项已存在的处理动作组织设计。 列表与接口资料：读取现有列表组件、查询参数、响应结构、字典、分页和权限实现，结合已有截图或脱敏样例直接获取字段与操作边界。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对查询条件、默认筛选、排序、分页参数与服务端统计范围，定位前后端不一致之处。 - 盘点对象标识、关键判断字段、列格式、长内容处理和行内操作。 - 追踪单行与批量动作、跨页选择、部分失败、详情返回和删除末页数据的实际行为。 ### 可采用的默认处理 - 保留已有查询和分页契约，优先呈现对象标识、关键状态及主要操作，不凭空新增后端筛选或全量统计能力。 - 已有选择范围沿用明确契约；新拟批量交互先按可见且具备权限的记录设计，跨页全选单列所需接口与业务条件。 - 零、空值、未加载、无权限和加载失败分别表达，长内容可完整查看且不挤掉主要操作。 ### 必须有依据的事项 - 筛选或统计口径与接口含义冲突时，不能自行改变结果范围；先完成列、布局和已知状态设计。 - 批量操作的数据边界、权限或部分生效规则不明时，不能把批量处理设计成默认全部成功。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 无工程时依据字段及业务资料交付查询字段表、列定义、单行与批量交互和分页状态规则。 - 没有数据规模或接口证据时交付可核对的布局与异常设计，单列服务端能力缺口，不声称性能验证通过。 ## 执行要求 列表要便于扫描、查找和处理，筛选、批量操作及状态规则以当前业务为准。 1. 明确列表的主要任务是查询、比对、审批还是浏览，按任务选择表格或条目列表。将对象标识、判断所需信息和主要操作放在稳定位置，不为了视觉整齐隐藏关键业务字段。 2. 整理查询字段的类型、默认条件、重置结果、联动规则和提交方式。说明日期范围、时区、空值、枚举以及搜索模糊匹配规则，后端不支持的能力标为待实现。 3. 定义列顺序、宽度、对齐、排序依据和截断查看方式，区分业务空值、零、无权限和未加载。金额、计数与时间要有明确格式，长文本可以展开但关键操作必须可见。 4. 定义分页、筛选、排序和进入详情后的上下文保留，说明删除当前页最后一条、查询条件变化与数据刷新时的页码处理。客户端展示逻辑不能冒充服务端全量统计。 5. 设计单行及批量操作，明确选择当前页还是跨页、不可操作记录如何处理、部分成功如何反馈。涉及不同状态或组织的数据时逐项核验可操作范围。 6. 覆盖加载中、查询无结果、首次无数据、接口错误和权限不足状态，并按一次真实查询到处理完成的过程走查。演示记录必须显著标识，不作为正式业务事实。 ## 交付与验收 输出：列表任务说明、查询字段表、列定义、单行和批量交互、分页状态规则、异常状态文案、验收用例。每个按钮都说明触发条件、结果和失败后可执行动作。 验收：用户能识别记录并完成核心操作；筛选与结果范围一致；批量操作边界明确；长文本不挤掉按钮；没有把缺失数据显示成零或成功状态。 信息边界：未知的数据规模、接口能力和权限规则保留为待确认项；仅有设计资料时不得报告性能或实际操作已经通过。 ### 本条完成检查 - 查询条件、结果范围与统计口径一致，列表记录和主要操作清楚可辨。 - 分页、详情返回、选择范围、部分失败和末页删除有明确处理规则。 - 长文本、空结果、首次无数据、错误及权限不足各有对应呈现，不用零或成功掩盖缺失数据。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 列表页](https://ant.design/docs/spec/research-list-cn/)
按实际业务内容组织导航、标题、查询区、工作区和操作区，明确桌面适配、中文换行与长内容处理规则。
## 任务目标 请为中国大陆企业管理系统设计清晰有序的页面布局。风格稳重、克制，以完成业务任务为主。 交付能用于评审或后续实施的具体方案、规则与样例；未要求实施的部分不声称已经落地。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 页面布局目标：优先处理当前讨论的页面；未指定时，以现有系统默认业务入口及其核心工作区为布局范围，从已有内容识别主要任务与操作，不另造功能模块。 页面或设计资料：读取现有页面结构、公共布局、主题变量、响应式规则和真实字段样例，结合会话中的截图、品牌规范与终端要求确定设计基线。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 查路由对应的页面与公共布局，识别导航、标题、查询区、数据区和操作区的关系。 - 盘点现有字号、行高、间距、宽度、组件密度与断点，区分公共约定和局部覆盖。 - 从已提供内容或字段结构检查长公司名、地址、编号、金额及操作数量，找出溢出和信息层级问题。 ### 可采用的默认处理 - 以清楚的中文政企业务界面为方向，先排信息层级和阅读顺序，再调整色彩；不添加装饰性口号、数字卡或无关插图。 - 优先复用已有尺度与布局，缺少规范时提出少量统一字号和间距建议，明确属于本项目建议。 - 宽表使用自身区域滚动，关键状态与操作保持可见；窄屏按业务任务重排，不把桌面宽表机械压缩。 ### 必须有依据的事项 - 页面主要办理任务与现有内容矛盾时，不能为美观决定删除关键字段或操作；先交付保留内容的结构整理。 - 已明确的品牌或终端限制互相冲突且影响内容可用性时，需确认适用优先级，不擅自替换品牌规范。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 只有截图或内容清单时交付页面区域结构、对齐层级、尺寸缩放规则和长内容处理说明。 - 没有可运行页面时完成设计走查与针对目标终端的验收清单，不虚构浏览器验证或设备占比。 ## 执行要求 通过网格、栅格和统一间距建立空间秩序，断点与区域宽度由实际内容及目标终端决定，不直接套用示例尺寸。 1. 确认页面主任务、主要业务对象和最重要操作，按使用顺序排列导航、标题、查询条件、数据区和操作区。先处理信息层级，再选择颜色与装饰。 2. 盘点现有间距、字号、行高、圆角与组件密度，优先复用一致的值；没有规范时建立少量可重复使用的尺度，并标明这是项目建议。避免为每个区域创造新的卡片样式。 3. 确定固定宽度、弹性宽度和可滚动区域，给出最小与最大可用宽度。大表格可以定义表格内部滚动，但不要让整个页面无意横向溢出。 4. 设计中文标题和字段名称的换行规则，长公司名、长地址、英文编号和多位金额都要有实际策略。关键状态、金额与按钮不能被省略后丢失意义。 5. 为目标终端定义布局变化：筛选项如何收纳，主次操作如何排列，侧栏何时折叠。不要把桌面宽表简单压缩成小程序页面，应按任务另行组织移动端内容。 6. 使用已提供的真实内容检查首屏重点、阅读顺序、控件对齐、滚动区域和页面留白。无截图或可运行页面时只给设计走查结果，并列出需要浏览器验证的事项。 ## 交付与验收 输出：页面结构、区域尺寸与缩放规则、间距和字体建议、不同终端布局、长内容规则、组件清单及验收检查表。每项视觉决定用一句业务理由解释即可。 验收：主要任务清晰；同类控件对齐一致；中文无生硬断词；内容在目标宽度可读可操作；没有装饰性大标语、无来源数字和遮挡业务内容的视觉效果。 信息边界：不编造用户设备占比或浏览器验收结果；已有品牌规范与本建议冲突时列出冲突，不能冒充完成了视觉还原。 ### 本条完成检查 - 主任务及主次操作明确，同类区域与控件对齐，信息层级一致。 - 目标宽度下的滚动、缩放和长中文策略可执行，关键状态与按钮不因截断丢失含义。 - 视觉尺度有可复用依据，页面不出现虚构业务数字和遮挡办理内容的装饰。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [Ant Design 布局](https://ant.design/docs/spec/layout-cn/)
评审需求版本、业务规则、权限、数据影响和验收准备情况，指出有证据的问题、变更影响与后续处理责任。
## 任务目标 请审查需求是否具备进入研发或接受变更的条件。给出可操作的评审问题与责任建议。 以核查和评审为主，给出有证据的判断及可复核的修改建议；本次用户另有明确实现要求时，按其授权范围执行。 ## 输入信息（选填） 两项均可留空，也可直接用一句话说明目标并附上已有资料。无需自行整理版本、配置或完整需求表；能读取的内容由执行者补齐。 需求评审对象：从当前待研发需求或变更讨论确定对象；未指定版本时，以现有资料中最近且可识别版本的需求为基线，与其明确的上一版或变更记录比较，找不到上一版则先审当前完整性。 需求与关联资料：读取当前项目的需求版本、设计、接口、数据与权限说明、迭代计划及现行评审规则；能从工程确认的实现影响由执行者自行追踪。 ## 信息不完整时 先使用本次对话中已经说明的信息；用户留空、写“暂无／不清楚”或未替换输入标记，都按缺失处理，不当作真实路径、参数或业务值。已能从资料确定的内容不重复询问，不编造文件、日志、接口、业务值或执行结果。在用户已授权的范围内读取相关工程和材料，不为补齐输入擅自扩大操作范围。 ### 优先确认 - 核对需求和设计材料的版本、日期与变更记录，检查是否误用旧资料评审新需求。 - 沿相关代码与接口追踪历史数据、统计、导入导出和租户权限的可能影响，区分已证实与待验证。 - 查设计、前后端任务、测试准备及依赖关系，找出无人承接或交付条件不一致的环节。 ### 可采用的默认处理 - 默认只读评审，不推进工作项、不替他人签署意见，也不发送上线通知。 - 优先级先采用团队定义，缺少定义时按业务损失和返工影响给出带理由的建议。 - 责任用已知岗位表达，人员或时间不足时列待分配，不因材料不齐停止对已有需求逐项审查。 ### 必须有依据的事项 - 同一核心业务规则、权限或数据口径存在互相冲突的正式材料时，不能替业务选定其中一版。 - 变更是否已经获准、适用版本或验收条件不明且影响研发准入时，只能给有条件评审建议，不能宣布已经批准。 只有缺口会改变业务结果、权限边界或关键实现，且无法从现有资料确认时，才集中提出最多 3 个关键问题；说明影响，并继续完成不依赖答案的部分。一般命名、排版和可逆实现细节按现有约定决定，不逐项等待确认。 ### 资料仍不足时的交付 - 没有代码时完成需求、设计与接口材料的一致性审查，列明尚需实现证据确认的影响。 - 没有上一版本时完成当前需求完整性、问题表和关闭条件，不编造前后差异。 ## 执行要求 评审内容和节点以团队现行规则为准，下面的检查维度用于补齐业务问题，不替代团队的决策流程。 1. 确认审查对象、版本、材料日期和本次变更范围，对比前后差异。材料不完整时列出实际已读内容，避免以旧版设计稿审查新版需求却不说明。 2. 检查目标、角色、输入、业务规则、状态、失败恢复和验收条件是否齐备。每个问题指出具体条目及会影响的用户操作，避免只有“建议完善”等泛泛意见。 3. 分析变更对历史记录、统计口径、接口兼容、导入导出、权限和跨组织数据的影响。分别列出已证实影响、需查代码或数据才能确定的影响。 4. 检查设计、接口、前后端任务与测试准备是否相互匹配，找出责任空白和依赖顺序。没有人员和工期证据时只写责任角色，不替团队承诺完成日期。 5. 按业务损失与返工范围确定问题优先级，区分必须明确后才能开发的问题、可并行补充的问题和优化建议。优先级定义优先使用团队既有规则。 6. 给出逐项处理建议、补充材料、责任角色和复核条件，并形成进入研发、补充后复核或暂不具备条件的建议。未获得真实评审意见时不能标注任何人已同意。 ## 交付与验收 输出：评审范围与材料、变更摘要、问题表、影响关系、待办清单、评审建议及其条件。问题表含编号、依据位置、具体影响、优先级理由、责任角色、关闭条件。 验收：每条问题可定位和复核；重大规则与权限影响没有被界面细节掩盖；结论基于当前版本；建议与团队真实决策明确区分。 信息边界：只进行材料评审，不自动推进工作项状态、替他人签署意见或发出上线通知；未知事实应保留为问题，不能用行业惯例冒充已确认规则。 ### 本条完成检查 - 问题均有具体材料位置、业务影响和复核条件，避免泛泛要求补充。 - 历史数据、统计、权限及接口兼容影响与界面问题分清轻重，已知与推测明确区分。 - 结论对应当前版本，并区分分析建议、团队决策和待确认条件。 按本条要求组织结果，使用简洁中文和一致的编号、术语、缩进及空行；已有项目格式优先。只说明实际完成的内容，将采用的假设、未完成项和缺少的条件写在相关位置，不额外生成无关文档。未执行、无法复现或缺少证据的检查如实标注，不宣称已通过或已有性能收益。 ## 参考资料与适用边界 参考来源（核验于 2026-09-08）： - [云效 Projex：需求评审](https://help.aliyun.com/zh/yunxiao/user-guide/requirements-review) - [使用项目协作创建并完成需求](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/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)
