There are several different types of KB.
If you do not want to install it, and you know a little about MSI, of course, you can find out ProductCode if it is MSI KB.
Two common types:
The KB file has the suffix .exe - which contains the .msp (patch) file. You can open the .exe file with the right mouse button with the unpacker, for example. 7zip (do not double click to install it). Then use a tool like Insted (google for it) to look into the .msp file. But patches do not have their own ProductCode, they have their own GUID and fixed full MSIs that have all ProductCodes products fixed. Maybe more for MSI experts, this one. Both GUIDs are in summary information, which is not a regular table. I do not know that the “MsiProductCheck” is to judge what you need to do to use this information.
The KB file has the suffix .msu (yes, not .msi) - Then you can read the ProductCode with any MSI editor, such as Orca (in the SDK platform) or Insted (again). Look at the property table, here it is.
Based on ProductCodes, most of the time is not recommended. If you are sure you want KB to be a prerequisite, everything is in order. For things other than KB, I would not recommend this at all.
It is better. If possible, I would look for file / registry changes that are executed by KBs, and use it myself (for example, the file version or GUID GUID) in the program to check if it is installed. File versions, if changed, are good practice because you are not dependent on a single fix, for example. the next time the change is included in ServicePack or a new version of Windows, etc.
I did things like written programs to provide a number of different prerequisites depending on different versions of Windows, and I can say to be perfect, sometimes it's hard work, you can spend weeks and months.