Azalea - 一个全新的现代博客/个人站点系统(构思阶段)

[pluvet]

废话不多说, 你可以直接看下一个标题

目前的博客存在的问题:

1. Hexo, Ghost, Hugo 等静态博客: 不能在线编辑, 不能手机编辑. 对于非专业人群难以快速实现搭建. 维护难度大.
2. Wordpress, Typecho: 没有完整 API, 同时不支持文集, 动态, 相册等刚需, 除此之外, 前者还过于, 后者则官方文档不明, 开发者必须阅读源码才能深入开发, 增加了开发难度, 而主题制作者能利用的接口太少, 一般情况下所有额外功能都只能塞在一个 function.php 文件.

总之, 现有的博客程序,

特性(你可以只看粗体字)

• RESTFUL API, 前后端分离, 以一套 API 为基准.
• 基于第一点, 可以自由设计各种前端, 如网页客户端, 移动客户端, 甚至基于短信或邮件的客户端.
• 基于第一点, 可以用任意语言开发后端, 只要提供相同的 API 行为. 无论是虚拟主机还是 VPS 都能运行.
• 基于第一点, 可以开发出博客社区, 让个人博客不再是孤岛.
• 部署简易化. 能够做到官方正式版本下载之后30s 搭建完成. 支持但不强制使用 composer, git, npm 等包管理器, 简化一切能简化的流程, 细化一切能细化的文档, 让任何初中以上文化的人都能使用.
• 支持扩展多种模块, 包括但不限于:
  • 文集, 文章模块: 适用于各种人群. 现在的博客系统只能用分类或标签来归类, 文集模块可以让你能更好地书写系列文章. 可以用来记录代码, 笔记, 也可以用来写作. 可以把文集导出为书.
  • 图集, 图片模块: 适用于绘画爱好者 /摄影爱好者, 也可以用来建立曲谱网站或壁纸站.
  • 链接集, 链接模块: 能够用于管理友情链接, 或者建立导航站, 还可以用来做网络收藏夹.
  • 动态, 分享模块: 可以表达灵感, 捞出旧文, 也可以分享 Bilibili 的视频, 分享网易云的音乐等.
• 支持插件扩展, 如:
  • 数学公式
  • 代码高亮
  • TOC(目录, 不但是文章目录, 还要支持到文集级别)
  • 投稿. 可自定义表单和验证规则.
• 支持主题.
• 支持自动静态 git/ftp 部署.
• 免费, 开源.
• 支持自定义解析引擎, 如 reST, markdown 等

上面的各种模块, 主题, 插件各自独立, 使用者可以抽取需要的, 在简洁的基础上完成特定需求.

后话

已经筹备良久, 预计七月正式开始开发. 当然, 这个项目的难度非常大, 正式版本的推出时间至少要一两年, 也随时有弃坑的可能性.

相关信息将在Azalea.moe和 QQ 群 107349757 进行更新. 欢迎关注. 也欢迎提出建议.

最后如果觉得不错, 请点个赞, 这将成为这个计划是否实施的决定性因素 因为如果预料到用的人不会多的话, 我只能开发我需要的部分, 只集成我个人需要的功能.

## 针对一些人的质疑进行的说明

### Q: Wordpress 什么都能实现.

A: 首先, Wordpress 确实强大, 我们也并没有打算取而代之. 然而, 对于我们普通用户, 甚至一些只有几百兆空间, 共享 CPU 的虚拟主机的普通站长而言, Wordpress (相对于 Typecho 等)**强大到了过于臃肿的地步**, 甚至一度被空间商抱怨[^1]. 这是我们反对使用 Wordpress 的主要原因. 其次, Wordpress 界面复杂, 不容易操作, 没有教程是很难快速掌握使用的. 我们希望用户多**表达自我**而不是**折腾程序**

### Q: 可选择程度倒是大, 但是部署后端太笨重

A: 我们打算先用使用门槛最低的 php + MySQL 开发后端, 任何人都能一键安装.

### Q: 可以直接用现成的 Github Api 拉取省事

A: 我们的方案并不与此冲突, 你可以利用插件自动从 Github 同步文章. 或者直接利用我们的 API 进行静态 Github Page 或 FTP 部署. (这样门槛其实已经降低到服务器只要能展示静态页面就能访问)

### Q: 现在博客已经不火了, 这个是否落后时代了?
A: 博客的热度不如从前是事实[^2], 但是, **自我表达的需求永远不会过时.** 与其只看到现象, 不如想想其背后的原因. 同样是自我表达的载体, 为什么微博更火, 贴吧更火, 知乎更火? 其**关键在于交互**, 马斯洛的需求层次理论[^3] 认为人有社交的需求, 尊重的需求和自我实现的需求. 博客之所以不火了, 是因为如今的个人博客太过于孤立, **无法满足人社交的需求**, 而像简书这样的平台, 虽然称不上真正的个人博客(因为远远足够的自我定制权), 但是凭借其社交优势, 获得了博客无法企及的热度[^4]:

所以说, 自我表达的需求永远不会过时, 而之所以博客不火, 在于其缺乏互动性. **没有了社交这一环, 自我表达的需求便无法实现**. 我在前面就说道: **API 为纽带**, 统一 API 之后, 就如同我们便可以在不同博主之间建立关联, **博客不再是孤岛**

其实, 我们要做的严格来说已经不是传统意义上的博客, 而是**超越了博客**. 以往的博客, 更像是一个笔记本或者日记本, 而**我们却要让博客升级为高度个性化站点, 变成你的家, 变成你的创作中心**.


以后补充的内容将在这里: https://www.azalea.moe/ 建议大家加群, 我们欢迎支持者, 更欢迎来泼冷水的人

[^1]: [https://lusongsong.com/upload/526-2.jpg]( https://lusongsong.com/upload/526-2.jpg)
[^2]: [https://trends.google.com/trends/explore?date=all&geo=US&q=blog]( https://trends.google.com/trends/explore?date=all&geo=US&q=blog)
[^3]: [https://zh.wikipedia.org/wiki/%E9%9C%80%E6%B1%82%E5%B1%82%E6%AC%A1%E7%90%86%E8%AE%BA]( https://zh.wikipedia.org/wiki/%E9%9C%80%E6%B1%82%E5%B1%82%E6%AC%A1%E7%90%86%E8%AE%BA)
[^4]: [https://trends.google.com/trends/explore?date=today%205-y&q=简书]( https://trends.google.com/trends/explore?date=today%205-y&q=%E7%AE%80%E4%B9%A6)

[laoertongzhi]

标记下

[ningfeng]

Wordpress 万物起源，你说的这些他都可以实现

[pluvet]

@ningfeng Wordpress 直接否决, 太过臃肿.

[pluvet]

文章中漏掉的几个字(貌似被锁定了, 不能修改):

>前者还过于臃肿(指 Wordpress)

>总之, 现有的博客程序, 已经不能满足人们表达自我的需要

[oblivious]

插眼！我也觉得 hexo 好不方便（部署在 github pages 上的确很方便）。

数学公式真心是硬需求，点赞点赞！

[pluvet]

想要参与开发的同学, 也可以入群, 不会写项目的, 虽然本人不才但也可以现教, 我一个人恐怕要的时间会非常多

[ShangJixin]

typecho 这边 肥皂群里有个大佬总结了一份手册之类的那种东西，基于官方文档改的，然后又加了些其他人总结的东西。感觉折腾 typecho 起来能方便不少
https://docs.qqdie.com

[dixeran]

Ghost 不是静态的，能在线编辑，也提供 API。另外，博客系统的吸引力很大程度上相关于优秀主题的数量。

[pluvet]

@dixeran 谢谢你的回复, 我没有用过 Ghost, 这里是我的错

[Newbing]

contentful

[Kilerd]

跟我现在自己写的那个博客系统很像了。
其实最重要一点就是提供完善的 API 就完事了。

[4IoNut698v3Xgc2p]

看你说的不赖啊，感觉我可以帮写主题

[pluvet]

@Kilerd 求详情，我个人的刚需是 api，toc，文集和数学公式

[pluvet]

@praming 带佬群里请

[liangzi]

wikijs 你值得拥有

[agdhole]

楼主这个系统我以前搞了一半放弃了，当时还是多语言多框架同步搞方便用户选择，后面发现如果要部署后端，太笨重，遂弃之，现在在搞基于 github api 的纯前端文档中心，只需要一个前端程序并输入项目地址即可解析 GitHub 上的 md 文件，兼容类 gitbook 目录结构，部署也方便，不需要单独购买服务器，GitHub page 直接就能跑。

[ningfeng]

@agdhole 你这个靠谱

[pluvet]

@agdhole 谢谢回复, 后端打算先用 php 做一份, 相较于 nodejs 更容易跑起来, 关键是要让**虚拟主机**都能安装, 门槛越低越好

[Akkuman]

我倒是越来越懒了，我倒是直接想写个 shell 脚本自用，自动查看我的博客园然后同步到我的 github pages （ github pages 也是用的 TravisCI)，之前也考虑过上面的所说的直接用 api 去搞，不过感觉这样来说的话，都是 json 数据，收录很不友好感觉会

[pluvet]

@Akkuman 这个我也考虑过，打算支持多端同步，并不只是做个博客，什么微博啊，推特啊，甚至贴吧发帖，b 站，还有博客园都要有自动同步的选项或者插件，最终目标就是彻底的个性化，沉浸式，同时多端备份，确保个人的东西能保存好，像不久前贴吧就出事了，多少人辛辛苦苦写的东西就没了

[Kilerd]

@pluvet #14 我现在的逻辑是这样的

完善的 RESTFUL API （施工中）
简单的本地模版，用于脱离云使用。

有了 API，就可以做这些事情了。

一个云管理平台（依赖 API CURD 文章），甚至可以做到多个网站一起管理
文法的话，这个在系统实现好这些，然后在新建文章的时候指定某一种就好了。反正 JS 很多 math 和 latex 的插件。 这个也不是难事


支持主题.
支持自动静态 git/ftp 部署.
这两个就是做不做的问题了，有了 API，简直不要太简单。github + ci => github page 也就是几分钟的事情。

[Mayuri]

前景真心不错，赞！！

[RYAN0UP]

点赞！ 顺便推推 https://github.com/halo-dev/halo.git

[pluvet]

@Kilerd 没错, 你 GET 到我的点了, 关键就在于利用 API 增强交互性

[FrankFang128]

你不如先定 spec，而不是先去实现

[d5n]

说的这些功能都是我想要的！期待楼主大作！

[sama666]

@pluvet wp 用了两三年了，的确太过臃肿，有时候回归本心直接 typecho jelly 和 hexo 了

[Cbdy]

说出来你可能不信，我用 Confluence

[SuperMild]

api 设计是重中之重，一定要考虑周全。

[sanmmmm]

额。。跟汤不热有点像？

[gz911122]

支持一下
我也想过做个这种东西

[edsheeran]

先了解一下 wp 和 ghost 再來做你要做的替代品，你這樣顯得很不專業

[mzsongyan]

https://github.com/agentejo/cockpit

[hing]

可以了解一下 JAMStack

[lotosbin]

https://github.com/birkir/prime
Open Source GraphQL CMS
可以了解一下

[pluvet]

@lotosbin
@hing
@mzsongyan
@edsheeran
@Cbdy
@sama666
@RYAN0UP

感谢你们的回复，不过你们推荐的产品，没有一个能实现我个人当前的需求。一个软件的作用，只能是满足特定时期的特定人群的需求。每个人的需求有所不同，如果一个人没有这样的需求，可能就会觉得我这个想法没有多少价值，可能会因为它存在其它项目的共性，同时其独特性不是此人所需，而忽略了其独特和不可替代的功能。这种情况，你当然可以拒绝使用。需要指出的是，我也并不打算取代市面上的某个已有的东西，而是打算提供一个新的选择。

[flxxy]

……你和我去年开始整的一样

[designer]

这个工程很大，而且以后流行组件拖拽形式创建页面样式。

[pluvet]

@flxxy 出成果了吗？求 Github 地址

[looking0truth]

说起部署简单 就不得不提一句 Go 了 /狗头

[hcs66]

Writeathon 也在考虑提供开源版本，这方面经验不足，可以探讨下
附介绍： https://www.writeathon.cn/share/5c0df586e893e179e9f944dd

[pluvet]

@hcs66 试用了一下，UI 比较美观，编辑界面样式不错，比 VSCODE 美观好用，书写体验很不错。但是没有 stackeditor 和 typora 直观。比较特色的一点是个人主页和分享功能，目录大纲漂亮，还可以导出，让用户更放心。

以后希望能考虑和我们合作，实现一些像是直推到博客的之类的功能。

[alan0405]

给客户一个空间，让他自己写

[woahishui]

楼主的意思是让客户选择一个随时可能被放弃的程序用到自己的公司中，脑子瓦特掉了

[woahishui]

如果一个客户连一年的空间费用都要考虑，那你的意思是大家都要跟着你给这些吝啬到极点人提供安心的服务了

[huiyadanli]

既然前后端完整分离，且语言不限制的话，先出一个 API 的设计与约定吧。。

[woahishui]

有很多人很奇怪，说是做项目积累经验，以后可以找到好工作，我希望大家真正体会积累的意思，希望大家积累项目而不是项目经验，项目永远是你的，即使别人否定了他也是你的，但如果你只积累经验，被否定你剩下的只有。。。。

[pluvet]

@woahishui 你是个聪明人

[cifermail]

也遇到过题主的问题，觉得想法很好，不过难以落地。
1. 首先开发量很大，做这个的目的是什么，毕竟时间比金钱还贵，这么做能获得什么样的收益？
2. 支持前端自由模板，后端自由语言，这个想法非常好。前端可以让用户选一些默认模板，后端如果让用户自己写的话，是不是对用户会有一点要求，这与先前的 30s 搭建完成有冲突。那就相当于要有一个默认后端语言开发好的东西，而自由后端语言只是扩展，这个 RESTFUL 也只是扩展下的一个标准（ PS：好奇为什么用 RESTFUL 而不是 GraphQL ），然后，自己能写后端与前端的用户，已经可以随意的订制个人博客了，本人博客就是自己订制的。
3. 支持在线公式、图形，这个应该是亮点了，这个难度较大。
4. 代码高亮，这是个难题，十有八九还是可能会选择一个现成的库。
5. 对于新手是否需要一个富文本? 如需，也是一个麻烦，这是个大坑。
6. 如何让博客不是孤岛，这些博客都是用户自己安装到自己的服务器上了，本来就是独立的。话说，买域名，域名解析，买服务器（ wall 外），配置搭建难以一键化，新手搞上一天都有可能。如果完成做成注册制写死的话，又不自由了，只要数据库与代码不在用户手上，都是不自由的。
7.上面有人说了，从 api 拉取数据自定义解析成 html 的话，解析过程放在前端的话，就无法 SEO。
8.上面功能较多，但还是不全，不同的用户会有不同的需求。与此同时，现有的功能已经有点“重”了。
9. 真的，真的有这么多用户写博客吗？他们缺的可能不是笔，而是动力。缺的不是博客网站，而是写博客本身的需求。

[ylsc633]

"Hexo, Ghost, Hugo 等静态博客: 不能在线编辑, 不能手机编辑. 对于非专业人群难以快速实现搭建. 维护难度大."

非专业人群难以快速实现搭建..

我觉得.. 最简单的 lnmp 很多非专业人士也搭不起来.....

另外, 后面说到前后端分离.. 我不知道 题主打算怎么做 seo...

我觉得最简单的方式(我没用过), 好像是那种直接 markdown 编辑直接发布. 连后端服务都不要的是最简单的..

如果想要 UI 好看的.. 但是不会写很多代码的. 还是现成的博客系统比较好用.. 因为主题够多.. 下载后会点 html 就可以改..

如果想要不一样的.. 那就只能自己上手自己写了...

最后弱弱问下.. 玩博客的.. 还喜欢独特 UI 界面的.. 大多都应该会自己写吧...

[pluvet]

@cifermail 感谢你的回复，下面我说说我的想法，如有不明白的，欢迎加群或 slack，然后进入我们的 trello 讨论组讨论。

1. 做这个的目的很简单，就是满足需求，这个项目本身不指望也不在乎盈利的，它是对现状不满的产物，即使我现在不做，只要需求还在，以后也会有其它人做。

要完成一切的功能，我一个人鼓捣几年绝无可能，而且现在的设想也只是头脑风暴而已，理论和实际上都不可能全部实现，仔细看看就会发现，光是需求之间就有矛盾。我的打算是先出一个精要的版本，作为内测版本，此版本首先解决的核心需求就是：a. 创造的同时博客间社交的需求 b. 多客户端的优质书写体验的需求 c. 数据安全、数据同步的需求 。这些需求实际上各有现成的实现，甚至可以和已有的服务对接，因此在这一阶段，工作量并不算大，也就是几个月的事情。

2. 后端如果让用户自己写的话，是不是对用户会有一点要求？

这个项目的纽带其实在于 API，它更像是一个规范。我们打算用门槛最低的 php + sqlite 作为官方示例后端。而有能力的开发者，也可以用 go，nodejs，python 等等实现。（不过说实话，这里存在大量有待进一步考虑的问题）。用户的行为是这样的：域名和主机的绑定->上传程序->打开安装页面->设置管理员账号密码->安装完毕。对于官方后端，可以保证安装的便捷性。而对其它语言的后端，我们无法左右开发者的选择。至于 restful 的问题，其实现在还没有拿定主意，选择 Restful，Graphql 或者传统的 service.Action （ rpc ），各有优劣都有可能。GraphQL 的话后端用 nodejs 写会更好，但目前决定用 php，个人更偏好 rest 是因为 rest 比较成熟，工具也多（指 php 上）

3. 这些属于前端插件，是否实现，如何实现取决于前端工程师。统一用现成的 js 库是最快的方法。我们的能力做不到连这个都造轮子。官方前端的话，自然会选现有库。

4. 代码高亮这种自然也是丢给前端和用户去选择。官方前端的话，自然会选现有库。

5. 仍然是前端的事情。到时候应该会有各种编辑器的插件可供选择。由于前后分离，切换起来非常方便。

6. 博客互联并不是强制的。站长同意接入之后，先注册一个账号，验证所有权，互相分配密钥，就可以接进来了。

7. SEO 本质上就是输出 HTML 的问题，正文部分用后置解析器解析为 HTML，然后统一一个输出格式就行。比如 discuz archiver，收录效果就比较好。当然，服务端渲染也是一个选择，但不是一个好的选择。

8. 有插件机制。模块是可拆解的，你可以做出庞然大物，也可以做得小巧。这取决于用户，我们会提供灵活度。

9. 这个问题我已经详细回答过了，不重复了。

[d5]

mark，netlifycms 对静态博客的可视化编辑支持得挺好的

[pluvet]

@ylsc633 在云主机搭建 lnmp/lamp 是比较困难，甚至比 nodejs 和 golang 搭建都难。所以选择 php 开发，虚拟主机就可以运行。虚拟主机是不需要你搭建什么的，只要设置域名，绑定域名，上传安装就行。

[gonnacai]

楼主，CPU 和内存不值钱。真正值钱的是写博客的、发照片的和维护人员的时间。

根据摩尔定律，宽带和硬件只会越来越便宜。

发射阿波罗的计算机性能，不如今天一台 iPhone 的 CPU。

不要重复发明轮子

[pluvet]

@gonnacai 你说的都对

[guixiexiezou]

重复发明轮子

[dsnake1984]

毕业论文？

[AlloVince]

我的 blog https://avnpc.com/ 基本实现了 lz 的大部分想法

后端 （ https://github.com/AlloVince/avnpc.js ）支持将 Github repo 作为数据存储，支持 RESTFul 和 GraphQL 两种格式的 API

前端 （ https://github.com/AlloVince/avnpc.front ） 基于 next.js ，使用 SSR 渲染后端 API。 使用了 markdown-it 系列，因此可以支持 markdown、语法高亮、数学公式，mermaid 图表 （ https://avnpc.com/pages/markdown-render-demo ）

评论使用 gitalk，直接用 github issue 作为评论组件

当然现在只是我个人自用的，不过应该可以作为参考

[nn1023]

标记

[LokiSharp]

数据库别用 MySQL 了 直接 Postgresql 吧

[ccino]

少打字了？

[maemolee]

我其实很期待楼主的作品，或者说，符合楼主这个设想的作品。

[OysterQAQ]

建议先设计出一套真正经用巧妙的、可扩展的博客 api 规范，这一点先完成吧。足够好，就会有人愿意遵守。才有可能有生态

[UIXX]

经历过 Web1.0、2.0 时代，并且做过大大小小博客以及论坛系统的人说几句。

通常一个想要开发新博客系统的人，包括以前的我，都有一个误区，那就是站在自身技术的角度来设计程序。
博客是一个重内容、重运营的自媒体形式，其系统的大部分设计都是偏向创作者的内容产出，而不是技术运维。

知道了这一点就不难理解，为什么这么多年，大部分人都还在用 wordpress。（论坛系统在这方面尤为突出，Discuz、动网、phpWind、phpBB 这些十几二十年前的程序至今仍占领着互联网论坛系统的百分之九十以上。）
是否前后端分离，怎么设计前端，怎么开发后端这些东西，作为被服务对象的创作者，他们不关心也不应该去关心。
他们在意的是，有没有足够多的功能以及插件可以用，能不能支持社区建设以及 RMB 打赏...这类系统越来越重恰恰是说明了它们想跟创作者靠得更近。
当我们自以为是的这些技术特性无法在博客运营当中产生效益，它们自然也变成了可有可无的东西。

试问，重新设计系统的产出与获得的利益不成正比，谁还会去花大力气地去发明轮子。

-----------------------论点分割线-----------------------

从现在的硬件角度来看，云主机 /VPS、独立主机价格越来越便宜，（博客经营者的）运维成本越来越低。只要维持“博客产生收入--收入支持（ IT ）服务--服务支撑博客”这个链条，在硬盘、内存、IO、带宽等资源绰绰有余的情况下，即使 Wordpress 再大一倍，使用者也不会有任何差异感知。当然访问量上百万是另一个话题了，但这个用户比例很低。

-----------------------论点分割线-----------------------

博客的衰落也不是单单一句“缺乏互动性”就可以概括的，事实上，博客本身并不缺乏互动性。
博客的问题并不是技术上能解决的，根本原因是它的经营理念（初衷）落后于时代。

1. 自我表达的欲望一直都在，不过表达的门槛在随着时代逐步降低，当今互联网得草根（屌丝）者得天下
博客时代对于创作者来说是有文字门槛的，它隐性地要求创作者必须要有自己的消化产出，且这类产出必须是要书面的。
从微博->直播->短视频媒体这个媒体爆红链条可以看到，文字创作成分减少，所见既得的要素越来越多，媒体服务的受众也越来越广。
“（门槛低导致的）创作者多--产出内容多--促进更多创作者加入”良性循环，大大挤压了博客时代的受众。（不过内容质量平均是在下降，这是另一个话题了。）

2. 泛娱乐产业更加成熟，内容的创作与运营更趋于专业化
博客在 Web2.0 的使用跟运营都很单一，无非是写文字、发表、链接转发，可以由创作者一个人完成，效果也常常跟创作者自身的条件（声望、文字功底）相挂钩。
现在的媒体表达更加多样化，媒体大咖有自己的团队，包括策划文案、视频拍摄、后期剪辑、经纪法务。创作的内容偏视觉感受，更能调动读者的感性思维，用户粘性更强。

3. 博客的效益转化很低
文字创作创作周期长，对读者有要求的同时版权保护力度小。
而现在的媒体偏视觉化，内容带有明显的个人或者团队的印记，有大众监督且平台参与维权。另外受众面广，粉丝经济效应明显。

并不是说改一下博客系统的实施，让用户有更强大的定制能力就可以完成时代复兴。

-----------------------论点分割线-----------------------

我始终认为下一个大众媒体的转折点还会回到内容本身上。没错，这与内容载体（背后用的什么技术）并无太大关联。
如果非要改进旧的博客系统，我有几个比较硬的需求方向。

1. 以 IM 来替代旧的评论系统

2. 运用更人性化的排版系统（大部分博客这一点做得很差），不需要让创作者去记什么 MD 语法，做到真正的所见即所得

3. 增加版权保护机制

[songkeys]

@UIXX #64 我觉得说得非常好。
另外请问「以 IM 来替代旧的评论系统」具体表现是？

[UIXX]

@songkeys
增加实时互动，有点类似于 gitter 的方式。

现在一些技术性的博客，对于用户反馈的处理方式都是将其导向 QQ 群或者微信公众号，那为什么不能直接在博客里面开一个 IM channel 来做这个事呢，还免去了加群关注等繁琐操作。

不过贴出二维码吸引粉丝加群是无可厚非的，毕竟那样更容易巩固粉丝群。所以才说要想办法提升博客机制的转化量，技术效能跟运营等非技术因素是息息相关的。

[pluvet]

@UIXX 非常感谢你的回复, 你是少有的真正思考问题的人. 我也说说我的看法.


写博客的行为属于**创作或记录**, 而**后者**的目的可以分为以下几个方面(及其交叉和综合):

- 经济效益. 获得稿费, 或者获得流量, 然后把流量变现.
- 心理满足. 得到读者的关注和认同, 增加自身的知名度. 或者是为了让他人了解自己的内心世界, 对孤独的反抗. 或者是为了一种责任感, 一种使命感.
- 寻求意义. 记录笔记或日记, 证明自己曾经学习过, 生活过, 经历过, 从而找到一种意义感. (我写作,是为了让光阴的流逝使我心安。——博尔赫斯 )
- 巩固知识. 更好地掌握知识, 获得能力. 从而能做更多的事情, 获得报酬或乐趣.
- 其他目的, 如政治目的, 辩论的目的

博客的话, 对于第一类人来说, 并不是一个好的选择. 我打算造轮子, 主要是为了服务后几类人. 不过, 如果能实现博客的互联化, 能为其带来流量, 那么也将自然称为第一类人的选择之一.

[songkeys]

@UIXX #66
> 为什么不能直接在博客里面开一个 IM channel 来做这个事呢，还免去了加群关注等繁琐操作。

可能触及性不如微信、QQ 那么强。用户没法主动每天都登录你网站。
不过我假想未来可能实现「万物」互联，任何博客、IM 等工具之间的也都有一套统一的通讯协议，这样大家都可以随时方便地触及任何不同的媒介。

[UIXX]

@songkeys
所以我才说博客系统的落后是一个时代的选择。

越来越多的人把发声渠道交由独立的 IM 系统，大众产出内容在 QQ、微信等工具上积累。这不是单独改善程序的某个点可以逆转的。

但如果想在原有博客系统上做文章，这的确是一个方向。

[headwindx]

比起做一个新博客，相信你更应该提前设计好 “社区技术协议”