技术博客的信任状：如何写一份真正有用的“关于我”页面

先交代一下背景吧。以前我把博客里的 About 页面当成一个摆设——放一句“你好我是某某”再丢个邮件地址完事。直到有一次我在文章里写了一个自认为很妙的解决方案底下一堆人留言追问我的技术背景和踩坑经历我才意识到“关于我”这个页面其实是读者判断“这哥们靠不靠谱、这篇内容能不能直接抄”的信任状。你连自己是谁、做过什么、在什么场景下得出的结论都不交代别人凭什么信你这篇就是我的 About me 页面长文版。写给两类人看一是想了解我这个人、判断我的内容值不值得你花时间的老读者二是正在纠结自己博客/主页该怎么写的朋友。我希望通过这篇文章把我自己的成长路径、内容筛选标准、踩过的坑和目前的工作方式全摊开来讲也算是把自己当成一个“项目”来做一次完整复盘。1. 我写这个页面时内心最想坦白的事关于页这种东西最容易写成“简历的复制粘贴版”或者“自我感动版”。我见过很多人的 About 页面列了一堆证书、公司和技能树看完只记得这个人好像很厉害但完全不知道他说话靠不靠谱、跟他交流会不会舒服。我写这个页面的时候给自己定了一个原则不装、不端着把真实经历和真实想法写出来包括那些让我难堪的细节。1.1 我的技术养成的起点我的本科专业不是计算机是自动化。大二那年开始接触单片机那时候纯粹是被“写几行代码就能让一个灯按我的心意闪起来”这件事吸引的。最早的代码写得一塌糊涂一个延时函数能嵌套三层GPIO 初始化顺序靠试错而不是靠手册。真正让我“开窍”的是大三做课程设计的时候。当时要用 STM32 做一个简易的温控系统我没有像其他人一样去淘宝买现成的 PID 温控模块而是自己从 PT100 的调理电路开始搭。那个项目折磨了我一个多月PT100 的非线性误差查表补偿、零漂和温漂的处理、PID 参数试凑每一个环节都让我熬夜到头秃。最后做出来的东西精度一般但从电路到固件全链路都是我亲手弄出来的。这段经历让我形成一个习惯——遇到问题先从底层原理开始推而不是先去搜现成方案。毕业后我进了一家做工业物联网的公司做嵌入式开发。那时候的主要工作是给各种传感器写驱动、做边缘网关的数据采集。听起来很硬核其实大部分时间在和各种 modulus 协议的怪异实现作斗争以及处理掉线重连、数据丢包这些脏活累活。干了两三年我越来越觉得工业现场的需求是稳定的但技术迭代太慢我还是想去更能发挥创造力的环境里折腾。1.2 从嵌入式到全栈的转型阵痛嵌入式转做应用层开发最大的门槛不是语法而是思维方式。嵌入式讲究资源管控、确定性和稳定性写代码要想着 Flash 够不够用、RAM 会不会爆、有没有临界区问题。到了互联网这边讲究快速迭代、灰度发布、刻意容忍不确定性一开始我非常不适应。我记得自己转行以后写的第一个后端接口用了很多状态机式的硬编码来处理前端传来的参数一个 Switch 套一个 Switch。终于有一天翻代码的时候自己都看不下去了那堆代码就像一个叠满 if-else 的俄罗斯方块插一根针进去都会整个坍塌。开始认真学设计模式、领域驱动、编写可测试的代码是转行之后第二年的事。就是这种“先把底层机制搞明白再往上层写业务代码”的习惯让我在后来的全栈开发里走了很少弯路。别人遇到 Redis 阻塞会先怀疑代码 bug我会先去看慢查询日志和内存换页情况别人遇到接口偶发超时会盲目加重试我会先抓包确认是连接池满还是 GC 停顿。这些能力曲线我一直贯穿在用。2. 这个博客具体写什么、不写什么做内容这些年我越来越觉得一个人不可能什么都写、什么都会。一个真正值得关注的博客一定有一个清晰的内容边界。我给自己划了一个范围只写我亲手做过、深挖过、并且还能沉淀出方法论的东西。2.1 内容方向的四个核心赛道技术干货占比最大大约六成。覆盖后端Go、Python、运维Docker、K8s、嵌入式RTOS、低功耗设计、前端React、TypeScript这几个方向。写这类文章的标准是“必须有可复现的操作路径”不写“浅析”“概论”这类浮在表面的文章。实战项目复盘占两成。我每做完一个有意思的项目都会强行要求自己写一篇复盘。比如去年做的那个边缘智能网关从硬件选型、系统裁剪、AI 推理框架落地到远程运维整整写了五篇文章。这类文章的价值在于把项目里那些“当时觉得天塌了后来发现是个低级错误”的瞬间记下来这就是别人花钱都买不来的经验。工具和方法论占一成半。像我一直坚持的“卡片笔记法”用 Buildkite 跑 CI 的技巧Zettelkasten 的内容管理流程Vim 的现代配置方案等。写这些不是我想做工具博主而是这些工具实实在在地改变了我的工作效率我想把这些改变传递给更多人。剩下半成是周报式的碎碎念。记录我这周遇到了什么奇葩 bug、读了什么有意思的书、在哪个知识盲区撞墙了等。很多人觉得这类内容价值不高但我恰恰认为这是博主“人味儿”的来源也是读者建立长期信任的关键。2.2 我坚决不碰的内容类型跟很多博客“什么热写什么”不同我有自己的固执第一类跟风热点但不深挖的内容。今天某个框架出了新版本全网都在写“新特性速览”这类文章根本没有差异化价值我不写。除非我能写透新特性和旧版本的底层差异、迁移时容易踩的坑才值得动笔。第二类涉及隐私和敏感领域的内容。我的博客不聊政治、不聊宗教、不评价任何具体公司的人事变动。不是怕事而是写作本身已经是一个幂等操作——你在公共领域的每一个签名都是永久存在的。第三类标题党和揣测性内容。“震惊某某技术被淘汰了”“必看大厂面试必问的 100 道题”——这类内容本质上是在消费读者的焦虑我不会浪费自己的信用去做这种事。3. 你可能会用到的关于我信息一次问清我经常在邮件和评论里收到下面这几个问题干脆在这个页面里一次性说清楚省的浪费你我的时间。3.1 你用什么工具写作博客用什么技术栈这个问题快被问烂了。有人以为我用了多复杂的工具链其实极简到不行本地用 VSCode Markdown 写作图片统一用 PicGo 上传到云存储。博客框架用的是 Hugo主题是自己改过的部署在云服务器上套了一层 CDN。整个写作流水线用 GitHub Action 自动构建每次git push就能发布一篇文章。很多人一上来就问“用什么写作工具好”我的答案永远是趁手的都行关键是建立“随时随地能记录”的机制。你用什么工具根本不重要重要的是你记录的内容有没有结构、有没有输出后的反馈闭环。3.2 你工作多久了本职做什么我现在是一名全栈工程师兼独立开发者目前在一家做开发者工具的公司上班。平时的工作内容大致分成三块参与核心产品的后端架构设计、带一个前端小团队做 Web 平台、以及做开发者关系的维护和内容输出。业余时间我会接一些技术顾问的活儿也维护着两个工具类的开源项目。时间确实很紧但这也解释了为什么我文章的更新频率不求多而求深。3.3 你是怎么做到持续创作的这是我私信里收到的最多的问题没有之一。说实话持续写作根本不是靠热情写作越多越会发现你得把它变成一种“肌肉记忆”。我的做法是每天中午雷打不动边吃饭边刷当天的技术资讯有触发想法的就扔进收件箱。每周抽固定两个晚上做“写作块”一次三小时两个小时用来梳理素材一个小时用来写初稿。每篇文章在发出来之前至少冷处理三天。写完了先放一放隔三天再回来看基本能发现一半以上的逻辑漏洞和表达瑕疵。偶尔我也会断更一两周但我现在已经不焦虑了。内容创作的底线不是“每天都写”而是“长期来看你输出的密度和质量是稳定的”。4. 我的工作方式和一点可能不中听的实话既然你都看到这里了说明你至少是对我说的内容有一点兴趣的人那就多跟你说说我的工作观和技术观。4.1 我讨厌“猜谜式”协作我最早在团队里接受不了的一类协作模式是这样需求文档写得模棱两可大家靠开会反复“拉齐”但会议基本靠猜、靠气场压制最后靠紧急上线杀出重围。我坚持的协作原则是口头沟通只用来达成共识一切结论最终都必须落到结构化文档里面。每次我负责一个项目的时候都会强制推“三件套”一页纸的需求摘要、技术设计文档、复盘纪要。最短的需求摘要可能只有半页但必须把背景、目标、约束条件、验收标准写清楚。这样做看起来前期的投入变大了但后面省掉的沟通成本远大于前期投入。4.2 工具焦虑是最没必要的一种焦虑我是一个工具的狂热爱好者但我同时也极度反感“工具拜物教”。很多人被安利了 Notion、Obsidian、Logseq先花一个星期把软件的主题、插件、双链结构调得完美无瑕然后就再也不打开了。我的观点是任何工具只有当它解决的是你的具体问题时才是有价值的。如果一个工具无法在你连续三天的真实工作流中存留下来那它对你的意义就是零。我博客里分享了再多的工具推荐内核其实都是怎么把它嵌入到“我现有的流程里”而不是让工具反过来重塑我的生活。4.3 代码写得好不好跟写得快不快是两回事这几年我带过不少新人发现一个明显的趋势很多人以“一周交了 5000 行代码”为荣。但代码量的多寡真的不跟产出价值完全挂钩。我宁可一个功能用两百行写得清晰、可测试、可维护也不愿接受一千行能跑但没人愿意碰的代码。很多新人以为我要求严苛但其实我只是坚持几条最基础的东西函数尽量短、命名尽量直白、副作用尽量隔离、状态变更尽量集中。这些原则每条都不新鲜但坚持十年和知道十年是两件事。5. 一些我踩过的坑希望你没踩过我坚信一个真正有价值的关于页面不应该只是“展示美好”。所以我决定把一些我踩过的、说出来有点丢人的坑也一并放进来。5.1 在博客里写技术文章最容易犯的第一个错误我刚写博客的前两年特别在意“技术难度”这个标签。总想写一些看起来高深的东西文章里充斥着复杂术语却缺乏对问题的解释和上下文铺垫。后果就是数据很惨淡几乎没什么人评论偶尔有留言还是直接质疑“你这段是从哪儿抄的”。后来我意识到内容的颗粒度跟读者的理解成本是有强关联的。你以为你是在“分享高深技术”其实是在“做名词展览”。从那以后我给自己定了一条铁律凡是要写一个技术概念必须用“一个生活场景一个代码示例一个容易踩的坑”的结构来写否则宁愿不发。5.2 把所有事都自己干的后果我一度是个“过度独立”的人。博客从写作到排版到部署到推广全都一个人扛。开源项目的 issue 自己回、PR 自己 review、CI 挂了半夜自己爬起来修。表面上效率很高实际上精力被大量机械性工作吞噬了。直到有一次病了一场断更整整三周才想明白一个问题创作者真正的杠杆不是把自己压榨得更狠而是建立可持续的系统和合适的协作关系。后来我学会了拒绝一部分需求把开源项目的维护权限逐步分给信任的贡献者博客的评论和邮件也学会了一天只集中处理两次。神奇的是这样做了之后我的产出没有变少反而质量更高了。5.3 请谨慎使用“焦虑式学习法”有一段时间我陷入了“学习焦虑”——什么热就学什么容器热就啃 K8s、AI 热就搭 Stable Diffusion、Web3 热又去研究钱包和智能合约。早上看一门课晚上报一个训练营发现自己好像什么都会一点但什么都写不出来。那段时间表面上很充实实际上一直在原地打转。后来我给自己立了一条规则在同一时间段内只准深度研究一个方向其他方向的资讯最多看标题收藏进留档夹。等到当前方向能持续输出三篇以上高质量文章后才允许开启下一个方向。这个规则非常笨但它保证了每一条知识线我都真正“穿过了一遍”。6. 你该如何跟我交流与相处关于页最后一个板块聊聊交流和合作的“约定”。6.1 我最高效的触达方式如果你是要跟我讨论技术问题最好的方式不是直接加微信而是在博客对应文章的评论区留言。因为评论区保留了上下文我回复的效率最高而且同一个问题可以被后来的读者看到减少重复提问。涉及隐私或者合作要约的发邮件最稳妥我在关于页留的邮件每天都会看。6.2 合作的相关边界我现在接的合作大致有三类技术顾问偏系统架构、嵌入式方案评估、公开分享线上/线下技术演讲、独立开发产品的内测反馈与深度评测。不接的内容类型后面这些纯 SEO 导流的外链文章、没有具体技术方案的“软文”、以及任何需要伪装成个人体验的推广。媒介鱼龙混杂我不缺那点稿费不想拿信誉冒险。6.3 我对评论区的态度我现在很少在评论区跟人“对线”。技术领域本来就充满了取舍同一套方案在这个团队是银弹在另一个团队是毒药这是很正常的事。遇到有不同观点的人我欢迎提出事实和逻辑论证但不欢迎无理由的杠。我写文章是分享不是炫耀也不是求你认同。你可以不同意我的观点但请用“我觉得这里可能……”而不是“你根本不懂……”开始你的表达。结语这篇关于我的页面我会定期更新有人会好奇“你一篇 About 页面值得写这么长吗”我觉得值得。因为博客的内容是产品而“关于我”是说明书。说明书不写清楚产品再好也会被误用。我计划每半年到一年把这篇页面重新读一遍、改一遍。把过时的信息清掉把新学到的、新的看待问题的方式更新进去。每一次的更新都是我对“我现在到底是谁”的一次主动确认。如果你从头读到了这里大概率你对我已经有了一些印象。那么就以这篇长文为起点我们随便挑一篇文章开始聊吧。