文 / STEM Career 编辑部
最有价值的实习或工作项目，往往不能直接放进公开作品集。代码属于公司、数据涉及客户，或者研究合作对材料使用有约定。面试仍需要证明能力，但可以先把允许说明的内容与受限原件分开。
本文用虚构项目演示证据整理，不判断具体合同效力。真实材料能否使用，应按组织政策、约定和授权确认；删掉名字或换几个数字，并不会自动获得公开权限。
先列材料 再判断能讲到哪里
可以把材料分成公开信息、获准描述的职责、需要确认的内容与明确受限原件。项目介绍、代码、截图、数据、客户名称和结果数字分别检查，不能因为其中一项公开，就默认其他项也可用。
先询问适当负责人允许哪些表达、给谁看、在哪个场景使用，以及是否需要复核版本。得到口头或书面指示后，按实际要求保存记录。涉及不清楚的具体约定，交给相应专业或授权方判断。
能力证据不只是一份代码
你可以证明怎样澄清问题、比较方案、设计检查、处理变化和协作推进。前提是这些内容在允许范围内，且没有通过细节重新暴露敏感信息。
Oxford 的面试准备建议可帮助组织经历。GitHub 的敏感数据处理指南也提醒我们，材料进入仓库后会带来额外处理问题。更合适的起点是先确认可公开范围，再决定展示方式。
原创情境 一个受限的订单异常项目
假设你在虚构公司参与订单异常识别，负责数据检查与报告模块。真实代码、客户记录和内部规则均不能公开；你获准说明自己的职责类型和通用方法，但不能披露具体阈值与经营结果。
可以先讲问题类别：团队需要及时识别记录不一致，自己负责检查输入、定位异常与组织复核。随后用独立构造的小例子解释方法，而不是上传原报表截图再把客户名涂掉。
如果连职责描述也需要审核，就先提交拟用文字确认。面试准备可以继续整理公开课程项目，不必为了证明商业经验冒然展示不确定材料。
一张证据分层表
| 证据层 | 可考虑的形式 | 必须确认的边界 |
|---|---|---|
| 责任说明 | 本人任务与协作关系 | 职责是否允许描述 |
| 方法解释 | 通用问题与判断步骤 | 是否暴露内部规则 |
| 独立示例 | 从零构造的教学数据和代码 | 与原材料保持独立 |
| 结果说明 | 获准的范围或定性观察 | 数字与客户信息权限 |
| 原始材料 | 内部代码、数据、截图 | 没有授权则不展示 |
表格用于安排准备，不是判定某项材料在法律上一定可以公开。真正的边界由适用约定与授权决定。
独立示例怎样做得有用
从公开问题定义重新开始，使用自己构造的教学数据、命名与实现。选择足够小的任务，例如检查三种状态是否一致，让评审能够运行并理解。
明确标注这是独立教学示例，用于说明相似能力，不是原项目代码的脱敏副本，也不代表原业务规模与结果。不要偷偷保留可识别客户、阈值或规则的组合信息。
如果示例借鉴公开资料，注明来源与使用方式。独立重新实现也需要你真正理解，不能用另一个来源不明仓库代替受限原件。
用三分钟讲清个人贡献
第一段说明场景与允许描述范围；第二段讲自己的任务、决定与协作；第三段解释怎样检查及结果边界。涉及不能展开的内容时，简短说明限制，再转到允许讨论的通用方法或独立示例。
例如：“在获准说明的范围内，我负责输入质量检查和异常复核记录。下面用自己构造的订单数据演示检查步骤；它不使用原数据，也不代表公司实际规则。”
这段话建立了真实边界，随后仍需要展示能力。不能把“保密”当成所有追问的统一答案，也不要为了回答一个问题临时透露原本不能展示的信息。
没有获准数字时怎样写结果
可以描述已经确认且允许使用的定性结果或交付状态，例如完成一项模块、建立检查流程或支持团队复核。避免添加无法验证的效率百分比、收入或客户规模。
若获准使用经过处理的数字，仍需准确说明对象、时间与个人贡献。团队总体成果不应自动写成个人直接创造，参与上线也不等于独立负责全部系统。
申请人可以在面试中解释自己怎样观察结果、还缺什么数据。诚实的范围不会替代能力，但能让能力判断建立在可核对事实之上。
技术追问怎样继续
对方问“你具体怎样处理重复记录”，你可以用独立示例解释标识、时间和状态规则，并说明原系统的细节不在可展示范围。选择足够清楚的公开问题，让回答仍有技术深度。
对方要求查看原仓库时，说明当前没有公开权限，提供获准材料或独立示例作为替代。不要承诺事后发送，除非已经确认可以这样做。
如果追问触及无法判断的边界，先暂停该细节，之后向授权方确认。准备时就建立这类替代路径，可以减少现场压力。
作品集入口怎样安排
先给公开概览，说明项目类型与个人角色，再链接允许展示的独立材料。可复现示例需要运行说明、输入、预期结果和检查，不只有几张截图。
可以结合GitHub 项目展示组织阅读路径；有海外工作后回国的经历，也可参考责任与业绩表达整理岗位层级证据。
发布前不要只检查当前页面
需要核对仓库历史、文件元数据、截图边缘和示例输出是否带出原信息。发现问题时，先按组织流程处理，不以删除一张图片就认定所有副本都已消失。
这些检查应在授权范围内进行，不要求求职者自行处理无法访问的系统。对公开范围不清的材料，先换用明确允许的项目，不必为了作品数量承担不必要的信息风险。
让独立示例与原项目保持清楚关系
演示开始时说明示例用于展示某类方法，哪些输入和实现是新构造的，以及它不能代表原业务哪些事实。随后按公开问题深入讨论即可，不需要不断暗示自己掌握无法核对的内部细节。
如果面试官根据示例推断原项目也采用完全相同规则，及时澄清。教学示例能证明你理解一个方法，却不自动证明原系统的技术方案、规模或效果。保持这种区分，也能让项目故事在不同面试中维持一致。
准备时可以列出三种可安全继续的话题，例如公开的接口设计、独立教学检查和本人协作方式。遇到受限细节时有明确替代材料，通常比现场临时改写公司信息更容易保持真实边界。
加微信时先描述任务 不发送敏感原件
如果最有价值的经历不方便公开，可以加微信先说目标岗位和大致责任，不需要发送公司代码、客户数据或内部文件。材料还没整理好，也可以先沟通可讲的经历类型。
蒸汽教育可以通过经历梳理与项目面试准备讨论证据结构、表达和独立示例范围。先把真实贡献讲清，再决定用什么材料支持，能让求职准备更有依据。
常见问题（FAQ）
删掉公司名就能公开代码吗？
不能据此推定授权，应按实际约定和负责人确认。
独立示例就是原项目脱敏版吗？
本文建议从公开问题新构造，并明确它不代表原实现与结果。
咨询需要发送内部原件吗？
不需要，先描述目标岗位与允许说明的大致责任即可。
- Oxford 的面试准备建议· University of Oxford
- GitHub 的敏感数据处理指南· GitHub
如果最有价值的经历不方便公开，加微信先说目标岗位和大致责任即可，不需要发送公司代码或客户资料；可以先讨论怎样梳理可讲的贡献。