可展示的项目材料,不是把博客源码打包发出去,而是让看的人能在几分钟内判断:这个博客做了什么、你怎么做的、遇到问题怎么处理。准备时以“读者能否独立看懂并验证”为标准,而不是以材料数量为标准。
把当前已有的东西列出来,通常包括:源码仓库、线上页面、几篇文章、若干截图。然后逐项问三个问题:
如果第二问的答案是否定的,说明缺少可访问的成品入口;如果第三问模糊,说明缺少分工说明。这两处是最常见的缺口。
判断依据是“它能否支撑一个具体结论”。例如一张首页截图能支撑“布局已完成”,但支撑不了“响应式适配正常”;后者需要窄屏与宽屏两张截图,或一个可访问的链接。
可以按下面三类取舍:
与这三类无关的内容,比如大段环境安装日志、重复的报错截图,删掉即可。它们会稀释重点。
在仓库根目录放一份说明文件,按固定顺序写。下面是一个假设示例,用于说明结构,不代表任何真实项目:
项目简介:个人技术博客,含文章列表、详情页、标签页
线上地址:见仓库 About 栏
技术构成:静态生成器 + 模板主题 + 自写样式覆盖
我完成的部分:栏目规划、样式调整、部署配置
本地运行:安装依赖后执行构建命令
其中“我完成的部分”这一行最关键。模板主题、插件、教程参考都应当写明来源,这不会削弱成果,反而让边界清晰,避免被追问时说不清。
如果博客涉及页面结构改动,可以在说明里用文字描述标签层面的调整,例如把文章摘要容器从 <div> 改为 <article>,并说明这样改是为了语义清晰。这类细节比“优化了代码”更有说服力。
整理完后做一次实际检查,按顺序执行:
任何一步失败,就回到对应材料补充说明,而不是在说明里写“可能需要注意环境差异”。判断结果只有两种:读者能复现,或不能复现。不能复现就继续改。
挑一个你已有的博客页面,按上面的四步走一遍:先列出材料清单,再删掉与三类证据无关的内容,然后补写说明文件里缺失的那一行,最后用无缓存浏览器和手机宽度各打开一次。做完这一步,材料是否可展示就有明确答案了。