对外讲技术时，最有说服力的材料常常就是上班做过的项目。架构图、排障路径、仓库结构一拿出来，发出去之前又会发虚：合同有没有卡住、许可证允不允许展示、截图里会不会带出不该出门的数据。心里没底的时候，把这几层边界过一遍更稳妥。下面是一份职场自查清单，不是法律意见，也不教人怎么绕开保密安排。
劳动合同和随合同走的保密条款，通常是该先打开的文本。里面有没有把客户名称、架构、源码、故障细节、未公开方案写成不得对外披露，直接决定案例能不能以原貌出场。写得宽还是写得窄，以你手里的合同原文为准，不要靠同事转述或口头「应该没问题」就定稿。客户侧的合同是另一层约束：即便劳动关系那份看起来留了口子，对客户承担的保密、知识产权和宣传限制仍可能更严。涉及对方系统截图、账号体系或业务数据的案例，尤其要核这一层。
仓库本身也有许可证这一层。内部仓库如果从未按开源方式发布，默认不要当成可以公开讲解的附件。已经对外开源的仓库，也要对照所用仓库的许可证文本，看它允许什么、要求保留哪些声明、有没有对再分发或公开演示的条件。未打开官方许可证文本，就不要把某条条款写死，更不要把常见开源许可证清单当成法规来套。许可允许使用源码，不等于允许你把客户数据和未脱敏的运行环境一并亮出来。
幻灯片和现场演示是另一处容易漏的地方。终端录屏、配置片段、监控面板里，常常夹着密钥、内网地址、客户库名、真实订单号。讲技术路径时，把这些换成占位符或虚构样例，比事后补救省事。拿不准某张图、某一段日志能不能用，就改成脱敏后的示意，或者换成个人练习项目、公开样本，不要为了「看起来更真」去试探边界。即便起初只是公司内部的技术交流，一旦录像要外放、稿件要发到社区或投给会议，听众范围就变了，合同和截图要按「可能被更大范围看到」再核一遍。公司若有对外发言或品牌审阅流程，把大纲和拟用材料走一遍，比讲完再改稿稳妥。
这和把代码或数据送进外部模型不是同一类问题。上云和仓库出站要谈的是数据和审批闸门，对外演讲要过的是合同、许可证和现场材料能不能公开。需要技术侧对照时，可看站内 外部模型进业务仓库的边界讨论，这里不复述那份清单。
若条款读起来有歧义，应该问公司里负责法务或合规的同事，而不是在分享稿里自行解释合同。这份清单只帮你把该打开的文本和该检查的截图列出，不能代替正式咨询，也不能当成「怎样才算没违规」的结论。
上一次对外分享，案例是直接用了工作项目，还是最后改成了脱敏或个人练习？