构建自定义 Ghost 主题 - 文档 基本概念 * Handlebars 是 Ghost 的模板语言，用于创建模板。 * index.hbs 、 post.hbs 和 package.json 这三个必填文件构成了主题的基本结构。 * 上下文将网站数据与正确的模板连接起来。 * GScan 工具用于验证 Ghost 主题。 模板语言 Ghost 主题使用标准 HTML 、CSS 和 JavaScript 创建，在需要呈现动态数据时使用 Handlebars 表达式， Handlebars 是一种模板语言，因此页面扩展名为 .hbs，该语言将动态数据渲染为静态 HTML 的形式发送到浏览器。 Ghost 还使用了一个名为 express-hbs 的附加库为 Handlebars 添加了一些附加功能，如布局和局部。 基本helper语法
交流群：博客右上角"账号-联系支持服务"，发送邮件获取Matrix房间邀请。 服务器要求 3种需求： 1. 只本地聊天 性能要求：2核2G，25G SSD。 网络要求：可拉取Docker Hub镜像和GitHub仓库。 推荐搭建环境：家庭NAS。 2. 异地使用+少数联邦 性能要求：2核4G，50G SSD。 网络要求：公网IPv4（用内网穿透也行）。可拉取Docker Hub镜像和GitHub仓库。联邦网络需要能访问指定域名。 推荐搭建环境：家庭NAS（具有透明代理环境）或海外VPS。 3. 全球无障碍通信 性能要求：至少2核4G，50G SSD。如果有大房间聊天和保存大量媒体文件的需求，则推荐2T以上 SSD，或者一台独立的数据库服务器和S3存储盘。 网络要求：可访问全球互联网的服务器
花了很多时间解决家庭路由问题。 最一般的用途上，电信运营商提供光猫，光猫兼路由功能，上门安装的师傅包办了，稍微大户一点的家庭，会需要路由器，乃至AP、交换机，这些产品都是出厂配置好了的，照着说明书几步就搞定。 难在想要自定义路由，想要有软件的功能。 我实际需求中得路由器上解决的，包括并不限于： 1. 网络代理和分流 2. 异地组网 3. 网络监控和上网保护 4. 游戏加速器 5. 网络容灾（这个范围很广，例如路由器一级的ddns、内网穿透） 不在路由上解决行不行？可以，但通常更复杂，使用起来更麻烦，也有更多不可预知的故障。举例来说：网络代理和异地组网，这些本质上要接管全局的网关流量，如果不用路由器上的透明化方案，那得在每个设备上都安装客户端（如果有相应软件的话），并且有些功能可能无法使用，例如24小时在线的服务，这很重要，例如家里的NAS服务器掉线了，在外地可以登录到路由器检查情况，并重新唤醒设备。 既然网关上的软件功能必不可少，针对不同的路由拓扑又产生了很多不同的实施方案，这里不探讨各种方案，而是直接给出我认为目前家庭（包括个人）
交流群：博客右上角"账号-联系支持服务"，发送邮件获取Matrix房间邀请。 Matrix 通信网络协议最常用的客户端 Element 过去一直使用免费的 Jitsi 作为群组视频会议组件。一对一音视频通话则相对复杂：如果双方客户端具有公网 IP，则可以建立点对点连接；否则需要通话发起方的服务端托管 TURN 服务来绕过网络地址转换 (NAT)，中继 WebRTC 连接。 现在这一情况已得到改善。Elment.io 开源了原生的 Matrix 视频会议应用程序 element-call。它的优势在于端到端加密、流畅性，以及基于 LiveKit 的可扩展后端；缺点是与 Jitsi 相比功能仍较为简陋，例如缺少背景虚化、主持功能等。 Element Call 客户端组件现已内置于 Element 桌面和网页端，并在新一代移动端 Element X 上作为唯一的通话组件。这意味着从
关于人工智能，有这么一则寓言：一辆加速的列车，一经抵达就远远地把人甩在身后。 幸运的是，列车似乎已经抵达，并没有把人甩在身后。因此，我们只需要回答好三个问题： * 列车是否仍在加速？ * 应该上车吗？ * 怎么上车？ 上一篇文章《构建人工智能应用的底层逻辑》展望了下AI应用的前景，然而现实的反馈是：应用很难落地。这同时指向了上述三个问题。 这篇文章将尝试回答头两个问题，对于第三个问题，也许将来有更多实践分享。 列车是否仍在加速？ 这个问题尚未在技术上得到很好的解答。从历史的角度却很容易找到线索，只需观察两条曲线。 第一条曲线代表了对AI的投资和研究以及能力随时间的变化 A Critical Historic Overview of Artificial Intelligence: Issues, Challenges, Opportunities and Threats InfoQ：2023 中国人工智能成熟度模型报告 中间有波峰和波谷，说明人工智能也有退潮期，如果贸然跟风，也可能踩坑（后面再谈论这个）。但总体
大语言模型是个黑盒，GPT-4 在早期版本中就如真人一般，而大量使用之后又不禁怀疑：它真的理解了对话吗？ AI也许是以我们不同的方式理解，之所以表现相似，是因为神经网络是一种模拟，人脑也是神经网络，正如我们搞不明白人脑怎么冒出意识那样，模型的生成过程也无法解释。 Stephen Wolfram 提出了叫做计算不可约和计算等价性的思想，用在AI上来说，要弄明白为什么模型输出那些内容，就得做不少于它参数量的运算，这就叫不可约，而它输出的结果，人脑也能产生，某种程度上就叫等价，所以至少对于非研究者而言，不必纠结于原理是什么，只需从外部测试这个盒子的能力，重点在于应用。 宇宙中有大把未知的存在，存在即合理，假设我们将存在和可能的存在都当作一种意义，就有了意义空间，从这个出发点可以推断出很多东西。 一点浅见！ 我以为意义是一种主观判定因果关系的方式，例如，小路上散步，一阵小风，不是朝这儿吹就是朝那儿吹，吹到树身上，种子飘到别处生根发芽了，吹到人身上，引起一阵惬意，这就是意义，它们的意义是在人身上体现的，所以： * 意义是一种组合，来源可能并不相干； * 意义是基于判
AI+Workflow是当前比较流行的Agent应用开发方式，本博客之前重点对比了：Dify vs FastGPT两个开源项目，也演示了Coze的案例，本文继续分享这两款产品的开发实践，借此对拖控件编排工作流这种低代码开发方式进行阶段性总结，读者顺便也能体会到它们之间的差异。 特别强调的是，这几款产品迭代得很快，文章仅作参考而非为了评价它们的优劣。同样优秀开源项目还有：bisheng（支持autogen和lanchain）和 ragflow（提供更丰富的RAG方式）等，你如果了解 langchain 的话，它也有 workflow 的开发方式可供选择。 言归正传！ 图形界面仍然是我们大部分用户首选的人机交互方式，例如，下图是我用FastGPT实现的一个下载器前端： 目前AI在实现智能生成UI、自动提参的交互能力上还比较弱，一方面，开发应用需要先对图形界面（GUI）进行布置，这受限于平台自身提供的UI组件；另一方面，AI更广泛的应用场景是作为其他软件的辅助形式，所谓副驾驶，例如代码编辑器中的插件，聊天软件中的机器人，而软件是各自独立的，多数软件接入第三方AI的形式