我以前写项目页时，很容易先列功能：支持什么、用了什么技术、页面有哪些模块。写完看起来很完整，但换成一个第一次打开页面的人，往往还是不知道该从哪里进入。
后来我给自己加了一个顺序：先写使用场景，再写解决方式，最后才放细节功能。这样页面会更像一次介绍，少一点清单感。
项目页常见的问题
很多页面开头就说“支持 A、B、C”。这些信息有用，只是出现得太早。读者还没确认这个项目和自己有关，功能就已经排满了屏幕。
我会先把场景压到几句话里：谁会碰到这个麻烦，它为什么会消耗时间，这个项目打算把哪一步变轻。读者能对上自己的经历，再看功能细节就自然很多。
我会先回答 3 个问题
- 这个项目解决了什么具体情境里的问题？
- 读者为什么应该在意这个问题？
- 打开它之后，读者能立刻做什么？
标题和摘要
标题可以朴素一点，但要让人知道页面要带他去哪里。摘要也别重复标题，我更愿意让它补一层上下文。
比如“效率工具集合”太宽了。我会写成“一组小而实用的网页工具，用来减少开发和创作里的重复劳动”。后一种写法没那么响亮，但读者更快知道自己用不用得上。
CTA 不要生硬
行动按钮最好接住读者刚产生的兴趣。查看日志、打开工具集、阅读过程，这些动作比“了解更多”清楚，也更像我自己会点的下一步。
后来
现在这个网站的作品页，每个案例都按「起因 → 成果 → 过程与取舍 → 现状与下一步」来写。起因先交代场景，取舍讲当时选了什么、代价是什么——算是把这篇里的顺序再往下推了一步。