AI 会写代码了,你的作品集还在证明＂这个我能做＂?

面试官翻着你的作品集，问了一句你没想到的话：

"这里为什么先做导入和去重，不做权限？"

你愣住了。

三个网页、两个小程序，还有一个 AI 帮你搭好的后台——每一个都能打开，界面也不难看。但你能顺畅讲出来的，只有"让 AI 继续改一版"的过程。

不是你项目做得不好——是你在用"我做出来了"，回答一个"你为什么这么做"的问题。而当 AI 让"做出来"变得越来越容易，后者，才是面试官真正在找的东西。

10 月 27 日，Anthropic 的招聘经理 Felix Rieseberg 在个人博客说，他停止使用传统的小型编码面试。这是他对自己团队的做法，不是公司政策，也不代表所有企业都不再考代码基础——你不必因此丢掉原来的准备计划。但其中有个问题值得想一想：除了应付目标公司的面试，你还能用什么材料，证明自己会解决真实问题？

同一天，Cognition 发布的 FrontierCode 2.0，把"是否值得合并""有没有遗漏约束"放进了编码评测。

一个讲怎么选人，一个讲什么是好的交付。两件事指向同一个变化：

模型能帮你更快写出一个东西，但别人仍然需要知道，你是否理解它为什么值得做、哪里还不能用。

这不是说 AI 辅助的项目没有价值。恰恰相反，它让新人更早接触完整的产品过程。

问题在于：当做出一个界面的门槛降低，只展示界面，就更难解释你的能力。

作品集要增加的，不是更夸张的技术名词，而是别人能检查的判断与工作证据。

用一句话说，这是一次转变——从"这是我做的"，走到"这是我解决的问题，以及证据"。

具体来说，是四个"证据"。

证据一：问题的来历。

不要只写"使用某框架完成全栈开发"。先解释：原来的流程哪里麻烦、谁受影响、为什么现有的办法不够用。

假设你做了一个活动报名工具——是因为群接龙经常漏人、核对名单要花一晚上，而不是"因为我想练手"。

如果没有访问过真实用户，就坦白这是个人假设。把练习项目包装成商业客户案例，是作品集里最容易被识破的漏洞。

证据二：你主动放弃了什么。

一个小工具不可能什么都有。

为什么先做导入与去重，而不是复杂权限？为什么先支持一种文件，而不是十种格式？

这些边界，有时比新增功能更能说明思考。把取舍写出来，也方便别人判断你是不是知道风险在哪里。

记录你放弃了什么，和记录你实现了什么，同等重要。

证据三：验证的过程。

能启动，不等于能交付。

拿一些你有权使用的样例：重复记录、空输入、异常文件、中断重试。保留测试结果，包括失败的截图。

不是要求每个练习都达到企业级标准，而是你能说清：哪些功能真正检查过，哪些只是演示。

证据四：AI 与人的分工。

诚实写明：哪些部分由模型起草，哪些由你设计，哪些错误是你发现并修复的。

不要用大量生成代码，掩盖你无法解释的部分。

承认工具参与，不会自动削弱项目；无法解释关键决策，才会让别人怀疑你能不能接手维护。

一个容易执行的做法：给每个项目补一页说明——目标用户与问题、范围与取舍、实现和验证、已知限制与下一步。附上真正来自你自己测试的截图，最好再准备一个短演示。

没有真实用户或商业指标，就展示技术与流程证据，不编造增长率或节省金额。

如果你已经在公司工作，先确认试验的授权范围。看到一条鼓励原型的建议，不等于可以私自连接生产数据、替同事改系统、跳过上线流程。从模拟数据、隔离环境和获得认可的小问题开始——让原型帮你沟通，而不是给团队增加风险。

选择项目时，也要匹配目标岗位：前端更在意交互和可访问性，后端更关心数据一致性与故障处理，数据岗需要解释指标和来源。一个通用的大而全 Demo，未必比一项与你应聘岗位相关、解释得清楚的小成果更有帮助。

也别把这件事变成新的焦虑：不是每个周末都必须做出一家公司。

你可以从给已有项目补一条失败记录、一次用户反馈、一项边界测试开始。

展示能力是逐渐积累证据，而不是连续制造惊艳。

AI 可能让实现更容易，但让别人放心把事情交给你，靠的仍然是清楚的责任与判断。

下一次更新作品集，除了告诉别人"这个我能做"，再回答一句：我为什么这样做，怎样知道它做对了，还有哪里需要谨慎？

这句话，才会把一个 Demo，变成关于你的可信证据。

你现在的作品集里，最想补上哪一份证据？评论区聊聊。

如果不知道从哪写起，我把上面说的"一页说明"整理成了《项目说明页模板》：填空版加一个完整示例，可以直接套在自己的项目上。在公众号对话框回复【项目说明页】领取。