当一条个人项目条目向读者提供与工作条目相同的四项信息时，它读起来才像真实、可信的工作：这个项目做什么、你用什么技术构建它、你在其中的具体角色是什么，以及因为它而发生了什么变化或取得了什么成效。一行只有代码仓库名称，或者标题旁边写着"个人项目"的字样，读起来只会像是一个爱好提及，因为它没有给任何人留下可评估的内容。解决办法不是多写关于项目的内容，而是写出你为一份有薪工作会写的那四项信息，只是按项目的规模缩小。
个人项目与爱好提及的区别
一条爱好式的表述只是给出一个名字：一个标题，或许一个链接，仅此而已。一条可信的条目会描述一件事：它为用户做了什么，用什么技术栈或工具构建，以及你具体做了什么，这一点在团队项目中尤为重要，因为同一个代码仓库上可能挂着不止一个名字。规模同样重要。"一个自动化人工对账步骤的工具"或"一个处理来自浏览器扩展请求的服务"，一句话就比一个巧妙的项目名称传达更多信息，而且不需要一个官方指标来支撑。
把每条条目结构化得像工作条目一样
把项目条目当作一条压缩版的工作条目来处理：一行说明它是什么、面向谁，一行说明所用技术栈，再用一行，至多两行，说明你的具体贡献及其规模。省略安装说明、徽章，以及任何读起来更像项目自己的README而非简历条目的内容。招聘人员或用人经理只会用几秒钟浏览简历，项目条目与工作条目争夺的是同一份有限的注意力，因此它理应遵守同样的纪律：先给出成果，而不是先给出所用工具。
个人项目在简历中应放在哪里
一条项目条目应该放在哪里，取决于它是从某份工作中衍生出来的，还是完全独立存在的。像Developer模板这样的模板，会把项目打印在它所属的工作条目下方，因此，一个在某份工作期间、利用自己的业余时间但与该工作实际内容相关而构建的个人项目，可以附在那条工作条目下，而不是脱离上下文独自漂浮。而一个完全不依附于任何工作的项目，通常更适合被归入简历末尾附近的一个简短、标注清晰的独立部分，与工作经历分开，这样它读起来像是有意添加的内容，而不是随意贴在你最后一份工作下面的事后补充。
示例说明：从一个仓库链接到一条项目条目
模糊写法："invoice-tool，github.com/example/invoice-tool"
具体写法："发票对账工具：编写了一个脚本，将银行对账单条目与发票记录进行匹配，并自动标记不一致之处。使用Python和一个小型SQLite数据库构建。用一次同事可以触发的自动化运行，取代了每周的人工对账工作。"
第二个版本回答了项目做什么、用什么构建、以及因它而发生了什么变化，而没有编造第一个版本永远无法诚实支撑的数字或成果。如果一个项目确实没有可衡量的前后对比结果，那么描述它所解决问题的规模同样能起到相同的作用。
几个会白费功夫的错误
把你曾经开始过的每一个个人项目都列出来，而不是挑出最能支持你想要的职位的两三个，会稀释那些强有力的条目，并把读者的注意力从最重要的条目上引开。只用技术栈描述一个项目，而没有一句话说明它实际做什么，会让读者完全猜不透它的用途。而在团队项目中把功劳全部归于自己、却不说明你具体负责的部分，一旦有人追问细节，就会显得像是在夸大其词。如何写一份简历中提到的总体结构和板块顺序，同样适用于项目板块，不亚于适用于一条工作条目。
把它加进你的简历
一个描述得当的个人项目，能为简历真正发挥作用，尤其是在有薪经验还比较薄弱的职业生涯早期。从一个为工程类工作设计的模板开始，把你的项目条目直接加进一份你可以持续完善的文档。