技能提升网“测试都通过了，可以发版。”这句话只说明自有代码在既定测试里工作，并不说明第三方依赖安全、许可证允许分发，也不说明历史提交里没有留下密钥。交付前还需要一张软件供应链体检表。
AI在这类任务中负责整理资料、执行重复检查并生成可复核的中间结果，负责人仍然掌握规则和最终决定。本文使用虚构案例说明做法，示例中的人员、数字和文件均不对应真实组织。
先把失败代价写在任务开头
本场景的直接触发是项目依赖很多第三方包，团队只跑了单元测试，却没有统一检查漏洞、许可证和仓库秘密信息。负责人最终要判断的是哪些问题必须阻断发布，哪些可带补偿措施上线，哪些属于误报。如果只追求快速生成而没有检查点，最可能的后果是已知漏洞、许可证冲突或泄露凭据进入生产后，可能造成入侵、下架、索赔和紧急回滚。因此，任务说明要把决策、交付物、截止时间和不能越过的人工边界一起写清。
输入资料不齐时不要急着运行
建议先建立一份输入登记表，至少包括以下内容：
- 锁定版本的源码和依赖清单
- 构建文件、锁文件与制品信息
- 允许和禁止的许可证政策
- 漏洞数据库与扫描时间
- 秘密信息规则及发布风险阈值
每份资料都要注明来源、版本、数据截止时间和负责人。多个系统里的同名字段未必采用同一口径；如果没有先做映射，AI输出越整齐，后续误用的风险反而越大。
本篇使用的工作能力来自玄甲代码供应链安全审计负责生成SBOM并审计漏洞、许可证和秘密信息。这些 Skill 承担的是结构化整理、检查和生成中间产物，不替代业务负责人、财务、HR、安全或法务人员的最终审批。
把工作拆成能够逐段检查的步骤
1. 先锁定提交和构建环境，避免扫描对象与最终制品不同
把输入文件和数据截止时间写进记录。后续发现资料换版时，负责人可以判断哪些结果需要重做。
2. 生成依赖树和SBOM，识别直接依赖、传递依赖与来源
先处理重复、空值和口径冲突。无法确认的内容进入问题清单，并注明由谁补充。
3. 合并漏洞、可达性、许可证和秘密信息结果并去重
同时保存规则、计算过程和异常样本。复核人员需要看到结果如何得出，而不是只看最终状态。
4. 按可利用性、影响、修复成本和暴露范围确定优先级
这一步涉及业务取舍。AI列出选项和影响，负责岗位确认采用哪条规则并留下理由。
5. 阻断项修复后重扫，例外项记录批准人、期限和补偿措施
换一位未参与整理的同事反查关键结论。对不上来源或无法重算的项目退回上一环节。
哪些省事做法会留下隐患
- 只看漏洞数量不判断代码是否可达
- 升级依赖后没有重新测试兼容性
- 把误报忽略掉却没有留下证据和例外期限
AI可以扩大检查范围，但它不知道组织内部没有写进资料的约定。处理记录应保留“事实、推断、待确认”三种状态：事实指向原始记录，推断写明采用的规则，待确认项指定负责人和期限。未知内容保持为空，比填入一个顺眼的答案更安全。
发布或交付前怎么复核
最终交付应是可追溯的SBOM、风险分级报告和带责任人的修复计划。至少逐项确认：
- 扫描对应最终提交和制品
- 高危项有处置结论
- 许可证政策有明确负责人
- 泄露凭据已撤销而非只删除文件
复核最好由没有参与首次整理的人完成。他应能从任一结论回到来源，重新执行关键计算或判断，并看懂异常为什么被保留。如果只能看到一个漂亮结论，却找不到依据、版本和责任人，这项工作还没有完成。
AI和负责人分别做什么
AI负责读取、归类、比对、计算和生成初稿；业务人员负责规则、例外、权限和最终决策。写操作、对外发送、薪资影响、投标提交与发布阻断等高影响动作，应在预览后明确确认。团队由此可以把讨论集中到少数有争议的项目，减少整批返工。
验收时检查答案的来源、限制和下一步。输入版本可追溯，异常保留在记录中，人工责任也放在正确岗位，这套流程才适合在下一批数据或下一个项目中复用。
