AI 项目没上线，面试时怎么讲才不显得虚？

“这个 AI 项目有多少真实用户？”如果答案是还没上线，前面讲得再热闹也不能补一个用户数。项目面试最重要的是把做过什么、验证过什么、尚未验证什么分开。 GitHub 的责任使用文档强调对生成工作进行复核。本文聚焦未上线项目的表达，不再重复完整作品集清单。

用贡献地图拆开团队与个人工作

为每个重要功能记录问题、你的设计决策、AI 帮助、人为修改和核验方式，并把决策连到 diff、issue、测试或截图。敏感信息和客户数据必须脱敏。

讲清一个未采用的方案

挑一个看起来合理但没有上线的建议，说明它违反了什么要求、你做了什么最小验证、最后采用了什么更安全的替代。它通常比声称每一行生成代码都正确更有说服力。

把可复现性限制说在前面

提供环境假设、一条最小测试路径和已知限制。如果项目依赖会变化的模型，要说明哪些行为取决于模型。可复现性是很直接的负责信号。

推演：因为权限问题停止上线的文档助手

假设你做了一个内部手册问答原型，借助 AI 完成导入、检索和回答界面。演示时能回答选定问题，但团队发现文档访问权限没有接到检索链路，于是停止上线。这是虚构例子，请用自己的真实情况替换。

第一层包装是“搭建了企业级 AI 知识平台”。更准确的说法是：“完成并测试了手册问答原型，但因为跨权限检索问题没有上线。”后者给了你讨论工程判断的空间，也不会暗示已经有真实用户或生产流量。

让未完成的边界可以被检查

用脱敏样本设置两个用户，各自只能访问不同文档，展示不应出现的跨用户结果，再解释缺少哪个控制、应该加在哪一层。如果已修复，就展示测试；如果只画过方案，就标为待实现建议。方案能证明思考，不能证明权限真的已经执行。

同样要分开模型和人的贡献。也许 AI 起草了解析器，你设计了测试样本、定位了权限泄露并建议暂停上线。不要为了显得厉害说所有代码都是手写，也不必把这些判断贬成“只是用了工具”。

追问“没上线，有什么业务价值”怎么答？

只主张观察到的结果：产出了可复现原型、发现阻止发布的缺陷，或明确了下一阶段必须实现的边界。选定题目的演示，无法证明规模化成本收益、真实采用率或生产可靠性。

测量名称也要准确：固定样本下的本地响应时间、两位评审认可的答案、回放案例数量。不要把这些描述成线上指标。如果没有可量化改善，就说明项目帮助团队做出了什么决定。

可以按九十秒骨架练习：问题、范围、个人贡献、一个验证结果、停止原因、下一项验收条件。上述例子需要先保证检索结果进入模型前已通过文档级权限校验，正向与越权负例都要测。

最后落到能迁移到新岗位的认识：“我学会把访问控制放在生成答案之前。”这有证据；“我证明 AI 可以替代整个客服团队”则没有。一个边界诚实的小项目，往往比一问证据就散架的大叙事更适合展开技术讨论。

常见问题

要不要隐藏 AI 参与？

不要误导。遵守雇主的披露政策，并把重点放在你的决策和核验上。

哪些材料最有用？

一份贡献地图、关键 diff、针对性测试、一条取舍记录和一个你能解释的限制。

项目不能公开怎么办？

用脱敏架构图、合成数据和口述核验路径，不泄露机密代码。

参考来源

• https://docs.github.com/en/copilot/responsible-use/copilot-coding-agent
• https://www.nist.gov/itl/ai-risk-management-framework

下一步

接着阅读完整的 AI 协作作品集证据指南。练习时可以把自己的案例整理进 Interview AiBox 面试档案，但工具不会自动替你核实项目成果。

• 功能全景
• 产品路线图
• 当前版本说明
• 下载 Interview AiBox