第一个作品集案例常见错误和修正方法

第一个作品集案例不需要华丽，但一定要经得起追问。新手最容易犯的错误，是把案例写成宣传稿：很多形容词、很少证据；很多工具名、很少验证；很多结果描述、很少限制说明。

这篇专门整理常见错误和修正方法。它和 第一个作品集案例怎么做才真实 搭配使用，适合写完草稿后自查。

适合谁

适合已经有一个练习项目、案例草稿或截图素材的新手。你不确定能不能公开、不确定标题是否夸大、不确定 AI 工具要不要写出来，就可以按本文逐项检查。

也适合准备把本地练习项目放进简历、个人网站或 Proposal 的人。案例写得朴素一点没关系，关键是来源、范围和验证要清楚。

不适合谁

不适合还没有任何项目记录，只想先写一个漂亮案例的人。没有问题、过程和证据，案例很容易变成空话。

也不适合处理客户敏感项目的公开展示。涉及未公开产品、后台截图、用户数据、订单信息、支付配置或私密代码时，先确认授权；不能确认就不要公开。

风险提醒

不要伪造客户经历、平台订单、评价截图、收入结果或上线数据。新手可以展示练习项目，但不能把练习项目说成真实客户交付。

不要把 AI 输出直接当成自己的完整成果。可以写 AI 辅助，但要说明人工做了哪些判断和验证。否则读者会看不出你的实际能力。

具体步骤

先把案例草稿打印成几个小问题：来源真实吗，范围清楚吗，有截图吗，有验证命令吗，有限制说明吗，有版权或授权问题吗。任何一个问题答不上来，就先修草稿，不要急着发布。

修正时按低成本顺序来：先改标题和来源说明，再补截图和命令记录，然后删掉夸大表达，最后补充下一步。不要为了让案例显得更大而扩大范围。

错误一：把练习项目写成客户项目

很多新手担心“个人练习项目”听起来不够专业，于是写成“为客户完成某某网站优化”。这是不必要也不稳妥的。作品集可以来自练习，但来源必须真实。

修正方法：把标题或开头改成“个人练习项目”“模拟需求”“本地复现案例”。然后重点写你怎么拆问题、怎么修改、怎么验证。真实的学习过程，比虚构客户更可信。

错误二：范围写得太大

“优化整站体验”“重做官网”“完成从 0 到 1 搭建”这些说法很容易被追问。新手第一个案例最好小一点，例如一个页面、一个组件、一个报错、一个移动端问题。

修正方法：把范围压缩成可验证句子。例如：将“优化首页”改成“修复首页价格卡片在 375px 宽度下按钮溢出”。范围越具体，越容易证明。

错误三：没有改动前证据

只有改动后截图，读者看不出你解决了什么。尤其是 CSS、响应式和报错案例，改动前证据很重要。

修正方法：补一张原始截图，或者补一段原始报错文本。如果没有原图，就在案例里说明“原始截图缺失，本案例仅保留修复后验证记录”。不要补假截图。

错误四：没有验证命令

作品集里只写“已修复”不够。至少要说明你怎么确认它修好了。对代码项目来说，常见证据是 build、lint、测试命令、浏览器截图和移动端检查。

修正方法：增加一个“验证”小节。写清楚运行了什么命令，结果是什么。如果项目没有自动化检查，就写手动检查范围，例如桌面端、移动端、按钮点击、导航跳转。

错误五：忽略版权和授权

很多案例会使用图片、图标、字体、模板或客户截图。新手容易只看视觉效果，不看能不能公开。公开作品集时，这一步不能省。

修正方法：把不确定授权的素材换成自己的截图、占位图或可使用素材。客户项目要先确认是否允许公开。需要客户回复的事项，写入明日待办。

错误六：只写工具，不写判断

“我用 Codex 完成”“我用 Cursor 修改”这类句子不够。工具只是过程的一部分。读者更想知道你如何判断改动是否合理。

修正方法：补充“我让工具定位相关文件，然后人工检查 diff；我拒绝了大范围重写建议，只保留局部样式修改；最后运行 build 并检查移动端”。这能展示你的决策。

错误七：没有限制说明

限制说明不是扣分项。它能让案例更可信。比如未部署生产环境、未做真实用户测试、未接入支付、未处理后端。

修正方法：在案例结尾加“限制和下一步”。写清楚本案例到哪里为止，后续还可以补什么。这样别人不会误解你的交付范围。

可以复制的修正文案

This is a self-initiated practice case, not a client project. The goal was to demonstrate a small, reviewable website fix.

I used AI assistance for file discovery and draft changes, then manually reviewed the diff and verified the result with the available project commands.

Limitations: this case does not include backend work, payment integration, production deployment, or real client data.

这段文案能把来源、工具和限制说清楚。发布前还要替换成你的真实项目细节。

CTA：下一步

拿出你的案例草稿，先删掉夸大句，再补来源、范围、证据、验证和限制。需要结构模板可以去 模板下载，需要拆项目边界可以用 项目报价助手。

免责声明

本文只用于学习和作品集自查，不构成职业、法律或收入承诺。公开案例前必须人工确认事实、授权、版权、隐私和平台规则。