器库yueser.com

用接口变更检查卡住破坏性改动

收录 2026-10

有人悄悄改了字段类型或删了必填项,在流水线里对比接口描述并拦下来

希望在流水线里自动发现破坏性的接口变更。请基于 [接口描述文件],设计一次对比检查:哪些变化算破坏性(删字段、改类型、加必填、改枚举取值)、哪些算兼容、发现破坏性变更时如何提示替代做法。输出:判定规则表、检查在流水线中的位置、误报的处理方式、以及例外情况的审批流程。
本站原创

中文原文

使用示例

示例输入

想在流水线里自动拦破坏性接口变更,基于现有接口描述文件设计一次对比检查。

输出应包含

  • 判定规则表分清破坏与兼容
  • 指明检查插在流水线哪一步
  • 给出误报处理和例外审批流程

复制前替换这些占位符 1

把方括号里的内容换成你的具体信息,替换后再粘贴给 AI。

  • [接口描述文件]
使用建议

标记为实验性的接口可以放宽,但要在描述文件里显式标出来。

可以这样改

  • 要求它先复述需求与约束,确认无误再写代码。
  • 让它给出最小改动 + 回滚方式,而不是整文件重写。

交付物(这次应拿到什么)

  • 可运行的最小改动(含直接可用的代码块)
  • 影响面清单:改了哪些文件、哪些调用点要跟着改

常见错法

  • 一次让它改十个文件,最后分不清哪处改动导致了新问题。
  • 只贴报错不贴代码和版本,拿到无法落地的修法。

输出验收(怎么判断能用)

  • 改动可运行、可回滚,且没顺手改无关代码。
  • 边界条件(空值、超长、并发)有说明或测试。

适用场景与注意

  • 适合:让它先复述需求和约束,再给最小可运行改动。
  • 注意:贴报错时同时给版本号与最小复现,否则它容易给出看似合理但不适配的写法。

同方向的其他提示词