AI 作品集如何证明真实工程能力

到了 2026 年，一个打磨得很漂亮的仓库已经不足以说明你的工作方式。评审者自然会问：哪些部分是你设计的，哪些是助手建议的，你又如何确认最终行为正确。这不是要求表演“绝不用 AI”，而是要求工程证据。

AI 辅助 Take-home 的代码来源指南 讲的是作业过程中如何记录；本文把同样的思路整理成招聘经理几分钟就能检查的作品集格式。

先说结论： 可信的 AI 协作作品集至少要有贡献边界、决策记录、可读 Diff、验证证据和一次被拒绝的建议。披露重要协作，同时不要把敏感 Prompt 放进公开仓库。

用贡献边界替代“全部都是我写的”

每个项目开头先写一段说明：

• 由人负责：问题定义、架构、数据模型、安全决策和最终验收；
• 得到 AI 协助：头脑风暴、重复代码脚手架、解释陌生 API、生成测试候选；
• 由人验证：代码 Review、测试、性能检查、威胁检查和手动复现。

“AI 写了 30%”并不能说明剩下 70% 是否包含最危险的判断。用动作和产物描述边界，比给一个百分比更有用。

准备五件套证据

1. 问题简报。 写清用户、约束、非目标和成功信号。一页纸就能证明方案不是从一句模糊 Prompt 直接生成的。

2. 决策记录。 记下两三个考虑过的方案，以及为什么放弃。注明真正改变你判断的约束：延迟、成本、隐私、迁移风险或运维简单性。

3. 有意义的 Diff。 链接可阅读的提交或 Patch，把生成的样板和你做取舍的文件分开。不要把无法阅读的“AI 初稿提交”当作证据。

4. 验证凭证。 列出定向测试、一个手动场景和一条失败路径。如果基准或截图重要，要写清环境和限制，让别人能复现。

5. 复盘。 点名一次你拒绝的建议，或助手犯过的一个错误，说明是什么信号暴露了问题、你怎样修正。这通常是最能证明你真正负责的部分。

在不表演的情况下展示可复现能力

做作品集 Walkthrough 时，选一个重要行为，在不打开助手对话的情况下重新讲清楚。画出数据流，指出信任边界，再展示一个能在关键假设错误时失败的测试。

如果你用助手调试，描述假设循环：观察、候选原因、最小实验、结果和下一步决策。不要只展示神奇的最终 Patch；让 Patch 可信的是过程。

保护机密上下文

发布前删除密钥、客户数据、私有 Issue 文本和雇主专属 Prompt。原始对话可能比代码暴露更多信息，公开时只总结意图。

还要检查代码所有权与第三方许可证。助手可能复现你尚未核对来源的片段。AI 面试审计轨迹指南 可以帮助你把 Prompt、Diff 和测试关联起来，同时不暴露秘密。

被问“这段是 AI 写的吗？”怎么答

可以这样说：“我用助手做了脚手架和方案发散，架构和数据边界由我负责。我拒绝过一个会泄露用户上下文的建议，并用这些测试验证了最终路径；不打开原始会话，我也能解释和复现关键部分。”

如果项目完全没有使用 AI，就直接说明。如果雇主禁止 AI，不能通过作品集文字暗示自己获得过许可。可信度来自披露与真实规则一致。

发送作品集前自检

• AI 使用边界具体、真实；
• README 写了约束与非目标；
• 至少一个决策包含被拒绝的替代方案；
• 测试覆盖评审者最关心的行为；
• 敏感 Prompt 和数据已移除；
• 不依赖在线助手也能讲清关键流程。

AI 能加快生产，但不会替你承担决策。一个小而可检查的证据包，能让评审者看见仍然属于你的工程能力。

常见问题

披露使用 AI，会让作品集变弱吗？

只要披露具体，并和你的决策、验证证据放在一起，通常会提升信任。真正容易引发怀疑的是含糊其辞或隐瞒重要协作。

应该公开多少 Prompt 历史？

只公开安全且有用的部分。简短总结目标和约束，通常比包含密钥、私有上下文和大量噪音的原始对话更好。

雇主明确禁止 AI，作品集披露能解决吗？

不能。必须遵守测评规则，另外准备一条不使用 AI 的限时练习路径。

参考来源

• GitHub：负责任地使用 Copilot coding agent
• NIST：AI 风险管理框架
• OpenSSF：AI 生成代码最佳实践

下一步

• 使用 AI Take-home 代码来源指南
• 练习 Plan–Build–Review 仓库面试
• 学习 拒绝低质量 AI 建议
• 下载 Interview AiBox