看着别人的博客,感觉好厉害!也想自己写写,但感觉还没开始就结束了,咋办?

6 阅读20分钟

序言


🐒:
   开始学习编程的时候,不止一次想做笔记,但又觉得在代码备注就好,结果就是一次次的百度解决问题,哪怕同一个问题一次又一次的遇到,而一次又一次的遇到的问题的结果只不过是找到解决方法更快了一点。
   我常用的方法是对相关资料进行分类并收藏,其结果是:各个平台都有账号,但由于太分散了,所以收藏了也白搭,看着不方便,也不记得收藏了哪些。
   最初的想法是写笔记(纸质版),照葫芦画瓢的 copy 定义也好,复制粘贴别人的解决办法也好,但都很难坚持下来,我思考后主要原因有两个:一是,我延用中学时期的笔记思路做的笔记不适用于代码编程,费时费力;二是,做好笔记之后查阅、修改、优化等都很不方便,而且很考验记忆力,有时候字写得不好也没心情看下去。然后我就打算加个目录,但既然都加目录了,我为什么不直接进行电子笔记?
   最初打算用 TXTWord 进行笔记,我发现在语法定义的时,既方便又美观,但在记录代码的时候格式很不理想。接着我找到了 Typora ,这个软件很好用,无论是语法定义,还是各种语言代码,都很优雅,放在一个文件夹里面,进行检索也方便,随之而来的问题是不能随时随地的查阅、记录、优化和分享,换句话说不能多端共享,这让我感到有些不便和孤独。
   有些苦恼,不知道应该怎么办?然后我去问了 DeepSeek ,它推荐我写博客,我便顺着思路去查找相关资料,才发现原来前辈们都建议写博客当做自己的笔记和总结,原来之前找到的解决办法是他们的博客笔记。以前从来没有这个想法,认为笔记算是比较私有的事,没想到在程序员里,写博客笔记是很正常的事情,那么,我应该怎么开始我的博客笔记捏?


🐋:
你能意识到 “写博客” 对技术成长的长远价值,这本身就是很好的开始。对于一个菜鸟程序员来说,写博客不仅能帮你梳理知识体系,更是建立个人技术品牌、沉淀思考的有效途径。下面会从 平台选择写作方法内容方向时间规划 这四个方面给予你的一些建议。


一、 平台选择:推荐软件 vs 自己弄网站?

🐋:
   这是一个经典的权衡。核心取决于你当前的核心目标:是想最快地开始写、获得反馈,还是想从零开始折腾技术栈、完全掌控一切? 以下是两种方式的分析:

1. 推荐软件(托管平台)

指使用现成的技术社区或博客平台,如 掘金、思否、知乎专栏、博客园、简书,或是专注技术的 Medium

优点:

  • 零成本、零运维: 不需要关心服务器、域名、备案,开箱即用。
  • 自带流量: 平台内部分发机制能让你的文章被更多人看到,这对初级工程师建立信心、获得反馈很有帮助。
  • SEO 友好: 搜索引擎对这类大平台权重高,你的文章更容易被搜到。

缺点:

  • 受限: 版面样式、代码高亮风格等可能不完全如你所愿。
  • 归属感弱: 平台是你的 “租用地” ,如果平台调整策略,文章数据的安全性不完全在自己手中。

2. 自己弄网站(自建博客)

🐋:
   自建博客通常指使用 静态站点生成器(如 Hugo、Hexo)+ GitHub Pages/Vercel,或者用 WordPress 搭建。

优点:

  • 完全掌控: 域名、样式、数据都属于你。这对于后端工程师来说,本身就是一次实践(部署、域名解析、CI/CD)。
  • 技术仪式感: 当你面试时,一个 yourname.com 的博客,配上 GitHub 仓库的自动化部署,本身就是技术能力的证明。

缺点:

  • 前期成本高: 选主题、配域名、调样式......这些很容易消耗掉你最初想 “写” 的热情。
  • 缺乏反馈: 没有平台的推荐机制,初期可能只有你自己看,容易因为冷清而放弃。

🐋的建议:分两步走

第一阶段(前3-6个月):使用托管平台 + GitHub 仓库备份

  • 掘金 或 思否 开设账号(国内技术氛围好,对 Go 后端的内容也比较欢迎)。
  • TyporaVS CodeMarkdown,本地保存源文件,定期提交到一个 GitHub 私有仓库里。
  • 这样既保证了 “写” 的流畅度,又解决了 “数据归属” 的后顾之忧。这个阶段,你的注意力应 100% 放在内容质量上,而不是花几个小时去配域名解析。

第二阶段(坚持半年后):自建博客

  • 当你养成了稳定的写作习惯(比如每月2-4篇),再用 Hugo 选一个简洁的代码主题,利用 GitHub Actions 自动部署到 VercelGitHub Pages
  • 把之前在平台上的文章整理后迁移过去,之后可以采用 “自建博客为主站,平台做分发” 的策略。

我的想法

2026-04-08

🐒:
   我看了一下推荐的软件,其中比较喜欢 掘金(蓝色调的简约风格,还没有广告),打算在这里驻扎;知乎专栏(是知乎里面的内容之一,有很多质量不错的文章,但整个软件生态不算是程序员专用的,我很容易分心去看脑坑小说🤣,不适合我发博客笔记);博客园(界面太经典了,偶尔查阅大佬的博客还不错,但不适合我发博客笔记);思否、简书、medium 没去探查过,以后需要的时候再注册看看。
   自建网站的话,目前没有什么兴趣或需求,打算先写个 5 年的博客笔记再考虑这个。


二、 写作方法:博客怎么写?

🐋:
   菜鸟工程师写技术博客,常见的误区是写成 “流水账”“代码说明书” 。有效的技术写作,核心在于 “场景化”“思考过程”

1. 确定文章结构

🐋:一篇好的技术文章通常包含这几个部分:

  • 背景/场景: 你在做什么项目时遇到了什么问题?为什么这个话题值得写?这部分能帮读者快速代入。
  • 核心概念: 涉及哪些技术点(如 Go 的协程调度、GORM 的钩子)?这部分用通俗的话解释清楚。
  • 代码演示/解决方案: 给出可运行的代码示例。关键是要有 “为什么这样写” 的注释,而不是单纯贴代码。
  • 踩坑记录: 你试过哪些错误的方法?报错信息是什么?这部分是读者最容易产生共鸣的地方。
  • 总结与延伸: 一句话总结核心要点,并给出进一步学习的资料链接。

2. 像教朋友一样去写

🐋:想象你在教一位比你低一级的同事,不要假设读者什么都知道。

  • 避免直接说 “显而易见……” ,可以这样表达:“这里可能有点绕,我们来拆解一下……”
  • 图文并茂: 对于 Go 的并发模型、内存分配、HTTP 请求流程,画一张简单的流程图或架构图,效果远超长篇文字。可以用 Draw.io(免费)或 Excalidraw 来画。

3. 追求 “可复现”

🐋:确保读者照着你的文章操作,能跑通你的代码。

  • 提供完整的 go.mod 依赖。
  • 如果是分析源码,标明 Go 的版本号。
  • 写完文章后,自己按步骤再跑一遍,这是很有效的校验方式。

三、 内容方向:写些什么?

🐋:
   作为菜鸟工程师,你可能会觉得 “这些知识书上都有,我写出来是不是重复造轮子?” ——不必有这种顾虑。你的优势在于 “初学者的视角” ,你知道哪里容易卡住,这正是资深工程师容易忽略但读者很需要的。推荐你往以下四个方向入手:

1. 基础夯实系列

🐋:把 Go 语言中容易混淆的知识点,用自己的理解讲清楚。

选题示例:

  • makenew 的区别(附带内存分配图解)
  • defer 的执行顺序与经典坑点
  • Slice 的底层扩容机制与内存泄漏风险
  • Goroutine 泄漏的几种场景与排查方法

2. 实战踩坑日记

🐋:在工作中遇到的 bug,解决后复盘,这是很容易吸引读者的内容之一。

  • 写作框架: 现象(报错截图) → 排查过程(pprof、日志、断点) → 根因分析 → 解决方案 → 如何避免。
  • 示例: “记一次在 Go 中误用 map 导致并发 panic 的排查全过程”

3. 工具链与工程化

🐋:后端开发不仅是写代码,整个研发生命周期的工具使用也很有价值。

选题示例:

  • 从零配置一个舒适的 Go 开发环境(VS Code 插件、go mod 代理、dlv 调试)
  • Makefile 管理 Go 项目的构建、测试、部署
  • 深入 go test:单元测试、基准测试与性能分析

4. 源码分析(进阶一点)

🐋:阅读标准库或知名框架的源码,能帮你快速成长。

从哪里开始:

  • net/httpServer 是如何处理请求的?
  • context 包是如何传递取消信号的?
  • sync.Once 是如何保证只执行一次的?

5. 写作节奏建议

  • 不要 给自己定 “日更” 这种难以为继的目标。每周一篇 或者 每两周一篇是比较可持续的节奏。
  • 质量比数量重要得多。

我的想法

2026-04-09

🐒:
   目前博客笔记的内容 主要有四个方向,一是 基础入门,即我看基础教程视频的学习笔记,我会根据我自己的理解和需求进行记录;二是 实战踩坑,等写项目到时候,我十有八九会遇到问题的,到时间我复盘好再进行记录(这次的话我会学着以教他人的方式写笔记,因为我感觉如果按照记笔记的方式记录遇到的问题,我可能过不久就看不懂我写的博客是啥意思了;我会尽可能多的截图和复制资料链接,先大致记录什么时候遇到这个问题,然后自己怎么找到解决办法进行解决的,然后那个成功解决了问题,把这些资料放进草稿里面,等项目现阶段完成后下进行梳理发布);三是 做题思路, 比如 LeetCode,记录一下写的题目,并尝试理解一些进阶的解决问题的思维;四是 分析源码,如果前面三步分别有 20 篇博客笔记,我将开始随机看一下函数什么的源码,理解那些大佬的思维,到时间会写下自己的思考和理解。
   虽然说质量比数量重要的的多,但我目前的阶段主要是看视频进行学习,所以这时的笔记应该是数量比质量重要得多,等有些基础之后质量会有些明显的提升吧。


四、时间规划:如何坚持?

🐋:
   关于博客的时间和发布量,这是一个很实际的问题。很多人刚开始热情高涨,日更周更,但几个月后就没下文了;也有人定了 “每月一篇” 的目标,结果一拖就是半年。想要坚持十几二十年,核心不是 “短期爆发” ,而是 “建立可持续的系统”
   下面我从 时间投入、发布频率、阶段性目标 三个维度,给你一个分阶段的长期规划。你可以根据自己的节奏灵活调整,但整体思路是:前期重习惯,中期重深度,后期重影响


1. 总体原则:频率不重要,持续才重要

  • 不要追求日更: 技术博客不是新闻媒体,读者更看重质量。日更很容易让你陷入 “为了更新而更新” 的焦虑,内容深度和思考都会打折。
  • 找到你的 “最小可持续频率” : 问自己:在正常工作和生活之外,你每个月能稳定抽出多少时间?哪怕每月一篇,坚持两年就是 24 篇,足以构成一个完整的技术知识库。
  • 时间投入建议: 一篇高质量的技术文章 ( 2000-4000 字,含代码、配图),通常需要 4-8小时 的完整时间 ( 选题构思1h + 实验验证2h + 写作2h + 修改配图1h )。建议把这个时间拆到 周末 或 工作日晚上 的固定时段,而不是靠 “灵感来了再写”

2. 二十年分阶段规划

🐋:我把二十年划分为五个阶段,每个阶段都有不同的目标、发布频率、内容方向和每周时间投入。


阶段一:习惯养成期(第1年)

🐋目标:克服完美主义,建立稳定的写作习惯,完成 “从 0 到 1 ” 的跨越。

  • 发布量: 每月 1 篇(全年 12 篇左右)。
  • 时间投入: 每周固定 2-3 小时(比如周六上午 2 小时写作,周二晚上 1 小时整理素材)。
  • 内容方向:
    • 以 “踩坑记录” 和 “基础夯实” 为主(如 Go 语法细节、常见错误、工具配置)。
    • 每篇解决一个具体问题,篇幅控制在 2000 字以内。
    • 允许自己写 “小文章” ,不追求长篇大论。
  • 关键心态:
    • 接受前几篇可能没人看、写得不够好,但 完成比完美重要。
    • 把文章同步发布到技术社区(掘金、思否),利用平台流量获得反馈,正向激励自己。

阶段二:质量提升期(第2-3年)

🐋目标:从 “记录” 转向 “教学”,提升文章结构、逻辑和可读性,逐步形成个人风格。

  • 发布量: 每月1-2篇(全年15-20篇)。
  • 时间投入: 每周 3-4小时(可拆分为两个晚上 + 周末半天)。
  • 内容方向:
    • 增加 “系列文章” (如 “Go 并发模式系列” “从零搭建一个 HTTP 服务”)。
    • 开始引入源码分析(标准库、知名框架),每篇聚焦一个模块。
    • 引入配图(流程图、架构图),用可视化辅助理解。
  • 关键动作:
    • 每篇文章发布前,用 “自检清单” 检查:是否有清晰背景、可运行代码、常见误区总结?
    • 尝试把一篇文章改写成讲稿,在公司内部分享或技术沙龙分享,倒逼自己讲得更清楚。

阶段三:深度与体系化期(第4-5年)

🐋 目标:构建自己的技术知识体系,输出有深度、有见解的长文或专栏。

  • 发布量: 每月 1 篇(全年 12 篇左右),但单篇篇幅和质量显著提升。
  • 时间投入: 每周 4-5小时(可能需要连续几个周末投入同一篇长文)。
  • 内容方向:
    • 围绕一个主题做系列深度解析(如 “Go 内存管理全解” “高性能 Go 服务优化指南”)。
    • 结合工作实践,写架构设计、技术选型、重构案例。
    • 开始写 “观点类” 文章(如 “我对微服务落地的思考”),展现技术判断力。
  • 关键动作:
    • 建立个人博客(独立域名),把过往文章整理归档,形成知识库。
    • 尝试投稿到知名技术媒体(如 InfoQOSChina),扩大影响力。

阶段四:影响力拓展期(第6-10年)

🐋 目标:通过博客建立个人技术品牌,链接更多同行,甚至影响行业。

  • 发布量: 每季度 1-2 篇(全年 6-8 篇),但每篇都追求 “行业深度”“前沿探索”
  • 时间投入: 每周 5小时以上(可能需要投入大量时间做实验、验证、与同行交流)。
  • 内容方向:
    • 写技术趋势解读(如 “云原生下 Go 的挑战与机遇” )。
    • 开源项目实践(自己发起或深度参与的开源项目,写设计文档、经验总结)。
    • 技术管理/成长类文章(如果你走向管理岗,可以分享团队建设、技术决策等)。
  • 关键动作:
    • 将博客内容整理成 技术书籍 或 电子书
    • 受邀参加技术大会演讲,博客作为演讲内容的延伸。

阶段五:长期价值期(10年以上)

🐋 目标:博客成为你技术生涯的 “复利资产” ,回馈社区,启发新人。

  • 发布量: 灵活,可能每年几篇,也可能在某些技术突破时集中输出。
  • 时间投入: 根据 兴趣 和 精力 自由安排。
  • 内容方向:
    • 回顾性总结(如 “十年 Go 编程心得” )。
    • 新兴技术结合你的经验做深度分析。
    • 指导新人写作、鼓励更多人加入技术写作。
  • 关键心态:
    • 不必强求数量,而是享受写作带来的思考和连接
    • 你的旧文章可能持续有人阅读、留言,可以定期维护更新

3. 时间投入的具体建议(以周为单位)

🐋:为了让你更直观地规划时间,我给出一个可复用的每周写作流程,你可以根据自己的工作节奏调整。


方案 A :周末集中型(适合工作日忙碌、周末有整块时间)

  • 周六上午 2 小时: 选题 + 构思大纲 + 做实验/写代码(先写出核心案例)。
  • 周六下午 2 小时: 完成初稿,按“背景 → 概念 → 代码 → 总结”结构填充。
  • 周日上午 1 小时: 修改、配图、检查代码可运行性。
  • 周日晚上 0.5 小时: 发布、分享到社交平台、回复评论。

方案 B :碎片化分散型(适合工作日晚上有空,周末不固定)

  • 周一晚上 1 小时: 确定选题,搜集资料,整理笔记。
  • 周三晚上 1.5 小时: 写代码示例,验证方案,记录关键点。
  • 周五晚上 1.5 小时: 写正文,不拘泥于语言,先写出来。
  • 周六上午 1 小时: 修改润色,配图,检查。
  • 发布: 周日或周一发布。

关键点

🐋:把写作拆分成小任务,每次只完成一步,降低心理门槛。哪怕只有30分钟,也可以用来 画一张流程图 或 整理一段代码。


4. 如何避免中途放弃?

  • 公开承诺: 在 博客 或 社交媒体 上宣布你的写作计划(比如 “我要每月写一篇 Go 技术文章,坚持一年” ),让朋友和读者监督你。
  • 建立素材库:NotionObsidian简单的备忘录,随时记录工作中的 灵感踩坑点。当你不知道写什么时,去素材库翻一翻。
  • 接受 “低谷期” : 每个人都会有几个月不想写、写不出的阶段。允许自己休息 1-2 个月,但不要彻底停掉。可以把旧文章翻出来修订重发,也是一种更新。
  • 与同行结伴: 找 1-2 个同样在写博客的朋友,互相审稿、鼓励。你们可以约定每月最后一周互相点评,形成正反馈。

5. 长期价值的再思考

🐋:写二十年博客,不是让你每周都绞尽脑汁。实际上,当你度过前几年后,写作会成为你技术生活的一部分:

  • 你解决一个复杂问题后,自然会想 “这值得写一篇文章”
  • 你阅读源码时,顺手记下的笔记,稍加整理就是一篇深度分析。
  • 你在团队内部分享的 PPT,转化为图文就是一篇优质内容。

到那时,博客不再是 “额外任务” ,而是你学习方式的自然延伸。


6. 总结:一个可立即执行的起步计划

🐋:如果你现在是菜鸟工程师,想从现在开始:

  • 第 1 个月: 注册一个技术社区账号(如 掘金 ),确定一个笔名和简介。选一个你最近刚搞懂的知识点(比如 “Go 里如何优雅处理 panic” ),用 “教会别人” 的心态写第一篇文章。不必完美,发出去。
  • 第 2-6 个月: 保持每月 1 篇,固定在某一天发布(比如每月最后一个周五)。每次发布后,把链接分享给同事或技术群,收集反馈。
  • 第 6-12 个月: 尝试一次 “系列文章”,连续3-4篇围绕一个主题。开始用 Draw.io 画图,优化文章排版。
  • 一年后: 回顾这 12 篇文章,挑出最受欢迎的 3 篇,重新修订、补充,尝试投稿到更广的平台。同时开始考虑购买域名,搭建个人博客站。

🐋:最后送你一句话:技术博客是 “长坡厚雪” 的投资,前几年几乎看不到收益,但一旦越过某个临界点,它会为你带来意想不到的机会——无论是更好的工作机会、技术大会的讲台,还是连接全球开发者的社交圈。


我的想法

2026-04-09

🐒:
   为期一年的博客笔记即将开始,时间为 2026-04-10 --> 2027-04-10,每 2 周发 1 篇,一年也就是 2*12=24 篇,今年刚起步,笔记的质量不会很高,以学习记录为主。
   关于这一年的博客笔记计划,目前给自己规划的可持续节奏是:基础知识就类似于做笔记,以定义使用方法为主,项目遇到的问题的话,会参考🐋的建议写高质量解决问题的文章。
   以目前的情况,写博客笔记的时间主要会参考 方案B ,因为我的爱好是打游戏,周末的时间应该不会很连贯,有点点期待一年后的自己,写博客笔记会不会像打游戏那样,成为一种自然而然的习惯。


总结

  • 起步阶段: 别纠结工具。去 掘金 或 思否 注册账号,用 Markdown 写,把源文件存 GitHub。 -** 写作核心:** 场景驱动 + 踩坑记录 + 可复现代码。抱着 “教会别人” 的心态去写。
  • 内容方向:基础夯实踩坑日记 入手,这是菜鸟工程师最容易产出内容且对他人很有帮助的切入点。
  • 长期坚持: 技术博客是 “复利” 很强的投资。一篇文章可能在发布时没什么反响,但半年后可能因为一个精准的搜索词,持续为你带来关注和机会。

🐋:
   你现在是菜鸟工程师,这个阶段写的每一个字,以后回头看都会是很宝贵的成长刻度。不用追求一鸣惊人,先完成再完善。如果写作过程中遇到具体的卡点,比如选题拿不准、或者部署遇到问题,随时可以再来交流。

🐒:
   我会的。