技能条先别画了，给我看看你做过什么

个人网站很容易长出一排技能条：JavaScript 85%，Python 80%，Linux 75%。

每次看到我都会想，剩下那 15% 是什么。闭包？构建工具？还是星期一早上不想写代码？

“热爱技术、持续学习、全栈开发”也差不多。不能说是假话，但复制到另一个人的主页上，多半照样成立。

百分比解释不了排错

一篇导航 Bug 的记录，反而能看出不少：

• 是否会先确认事实；
• 是否能区分现象与根因；
• 是否理解 History API；
• 是否会避免修改系统网络这种扩大问题的操作；
• 是否能把排查过程讲清楚。

这些东西不用作者在结尾宣布“我擅长调试”。读到的人会自己判断，而且往往比技能条判断得准。

项目介绍别只写用了什么

“使用 HTML、CSS、JavaScript 制作个人网站”，差不多等于介绍房子时说它用了水泥。没错，但也就到这了。

我现在更想看到四件事：

1. Context： 为什么要做？约束是什么？
2. Decision： 有哪些选择？为什么选现在这个？
3. Execution： 最难的部分如何落地？
4. Result： 用什么信号确认它有效？

技术栈可以放在旁边，别让它抢走真正发生过的事。

没做成，也不是不能写

我写过错域名，也怀疑过其实没犯错的 Fake-IP。都不漂亮，但删掉以后，排错过程反而只剩一条从开头直达答案的假路。

复盘当然也不能把每一次敲命令都贴上来。我通常只留下这几样：

• 哪个信号最早暴露了错误？
• 为什么当时没有注意到？
• 下次如何更早发现？
• 哪条规则可以进入长期工作流？

写过一次，下次少绕一点

特效首页最擅长第一次见面，文章要慢得多。旧文章能被搜到，新文章能接着它写，项目也不会只剩一个已经想不起用途的仓库名。

所以 Arcuid 现在有几条不成文的规矩：

• 写做过的事，不伪造经历；
• 写具体判断，不堆抽象正确话；
• 给出必要代码，但不让代码淹没故事；
• 标注更新时间，让旧结论可以被修正；
• 如果某个内容无法提供价值，就不要为了更新频率发布。

写到最后也不必再补一句“这次经历让我成长”。坑已经在那里了，读者看得见。