静态标记指出某一行代码可能出问题，并给出它认为的原因，但它从不执行代码。要把这份怀疑变成证据，得配一个能走到同一条路径的真实请求，打到线上端点，再对响应和副作用做断言。标记告诉你风险在哪，请求告诉你风险是否真的发生，单靠任何一个都给不出有把握的答案。
为什么缺一个就弱
静态分析快且便宜，不用跑起运行环境就能读完所有改动文件，但它的产出只是一个假设。它推理的是代码结构，遇到守卫已经处理掉的情况会误报，遇到依赖真实数据的缺陷又会漏报。一个孤立的标记，不携带任何运行时证据。
真实请求的强项正好相反。它能确认端点实际产生的行为，但盲目给每一行都写请求很慢，而且没有标记，你根本不知道该优先检查哪些路径。把两者配对，就是用静态扫描来瞄准请求，用请求来确认标记。
各自贡献什么
配对后的那一行才是目标：一个不再只是模型断言的怀疑，因为背后有可复现的请求撑着。
怎么跑这套配对
- 读被标记的那一行，把触发条件用具体的话讲清楚。
- 构造一个请求，带着触发条件需要的数据走到同一个分支。
- 打到线上端点，断言状态码、响应体和契约。
- 检查副作用，比如是否写入了一行、是否删掉了一条记录，不能只看响应。
- 请求复现了问题，就把标记标为已确认；守卫挡住了，就标为已排除。
- 请求没能走到那条路径的，记为不确定，而不是记为通过。
举个例子：有个标记说，归档笔记可能在一次选择变更中被删除。请求发出一个删除动作，选择范围排除了归档笔记，但可见列表里包含它们。响应返回 200，看上去没问题，可副作用检查显示有一行归档记录被删掉了，标记由此确认。如果请求显示归档行被保留，静态标记就被证据排除，而不是靠争论排除。
可复现的证据
每个确认项都该带上可复现的请求和原始响应，作为信任的基础，这样检查能重跑，而不是依赖一次性的观察。证据按类型分类，纯 AI 给出的断言在动态检查或契约检查背书之前，始终停留在假设状态。
判定保持确定性，不引入大模型：证据失败就是失败，部分验证就是部分，空结果不算通过。
Powerduck 把静态标记和请求工作流连在一起，评审者可以用一次真实调用确认每个怀疑，而不必在互不相通的工具之间来回切换。
哪些标记值得配一个请求
不是每个静态标记都需要完整请求，配对流程从一次快速分诊开始。改变了行为或数据路径的标记，值得一次真实调用；纯结构性的标记，比如命名问题或死导入，看代码就能定论，记录下来即可，不必发请求。风险在于检查不足，所以标记含义模糊时，宁可发请求，也不要靠静态分析直接排除。确认一个标记的请求，相对于它能抓到的缺陷来说很便宜；排除一次误报的请求，也仍然留下了证据。让请求支撑的发现聚焦在行为风险上，结构性的发现单独走一遍，动态工作才能保持有的放矢。
诚实的边界
配对结果只覆盖请求实际走过的路径，这些请求之外的边界情况仍然敞着。动态加载和外部消费者可能让某个分支对静态扫描不可见，模型也仍会提出错误的怀疑。
当请求走不到被标记的分支时，把这一项当作不确定处理，调整输入，而不是把空结果算作验证。
常见问题
为什么不直接信静态标记？因为它是一个从不运行的假设，而且守卫可能已经挡住了触发条件。
为什么不抛开标记直接发请求？可以，但静态扫描能瞄准高风险路径，让请求集保持小而聚焦。
200 响应能确认标记吗？不能。要断言响应体和副作用，因为 200 仍可能破坏契约或数据。
结论
用静态标记找到风险，用真实请求确认它，断言响应和副作用，而不是单独信任任何一方。标记在可复现的请求复现或排除它之前，都只是假设；一次从未走到那条分支的检查，始终是不确定。这套配对把快速的静态覆盖变成经过验证的行为，而不假装其中一方能替代另一方。
热门跟贴