2.5 KiB
2.5 KiB
用户给UI流程是为说明API需求，不是授权切换到UI自动化
触发与失误
用户一开始已说只需理解Opera操作要素，按钮/顺序与接口未必有关。Agent虽记录了该边界，后续却将 “平台未暴露原生XML报告API”当成主要阻碍，转向计划报表/SFTP，并反复要求用户点页面、给截图。 用户明确指出这不是所要求的接口研究。浏览器工具超时是另一个事实，不能掩盖先前已发生的任务方向偏离。
纠正
- 把UI动作转成筛选语义、必需字段、权限/可见性、顺序和完整性要求，再去catalog/OpenAPI逐项映射。
- 数据格式与获取途径分别判断：现有XML入口不等于必须存在同名XML下载接口；先核对多API组合的覆盖。
- 没有找到整份报表API时，清楚说明这一具体缺口，不放大成平台数据API不可用，也不擅自替换为另一条运维路线。
- 只有实际需用户决定的取舍才提问；查询接口定义、返回字段和已授权技术研究由Agent完成，不反复转交页面操作。
- 当前停止UI/SFTP分支，保持原始样本、固定规则、完整日提交和独立校验，继续API字段/参数/组合研究。
该边界已写入源报表契约、当前状态与接入README。原交付草案保留为停止推进的历史材料，未实施任何计划或传输。
后续同类纠正：页面标签不要求与XML内部值字面相同
用户始终给出Note Types=Resv.-GEN，Agent在XML看到RES_COMMENT_TYPE=CAS、说明GENERAL后将其表述为 “口径差异”，再次要求确认是否正确文件。用户提供准确的新文件并重申选项；新旧文件逐字节相同。 内部字段事实没有错，但由此暗示用户可能选错，证据不足，也把技术映射问题转交了用户。
- 区分页面标签、报表内部字段、API枚举及酒店配置，不能只因字面不同就认定用户输入矛盾。
- 解释内部值时先给准确字段名和源文件行号，明确不是页面控件名称，不让用户去页面寻找不存在的字面值。
- 用户明确确认的文件和选项应成为样本基准。技术映射继续验证，但不重复质疑同一业务输入， 也不未经同源证据将另一环境API筛选改成XML内部代码。
- 相同摘要/相同字节继续沿用已验证的处理基准，避免无意义的重复处理。
本次确认记录与源契约已保存这一边界。