第一步：安装集成包

打开终端，在你的 Astro 项目里运行：

npx astro add mdx

Astro CLI 会自动帮你安装 @astrojs/mdx 并更新配置文件。这个命令会问你几个问题（要不要更新配置、要不要安装依赖），全部选 Yes 就行。

第二步：验证配置

装完后，打开 astro.config.mjs，应该能看到这样的代码：

import { defineConfig } from 'astro/config';
import mdx from '@astrojs/mdx';

export default defineConfig({
  integrations: [mdx()],
});

如果没有自动添加，手动加上就行。

测试 MDX 是否生效

在 src/pages/ 或 src/content/ 目录下创建一个 test.mdx 文件：

---
title: 测试MDX
---

# 这是 MDX 测试

普通的 Markdown 文本。

export const greeting = "你好";

现在可以用变量了：{greeting}！

<div style="padding: 1rem; background: #f0f0f0;">
  这是一个 JSX 元素
</div>

运行 npm run dev，访问对应页面，如果能看到变量和 JSX 元素正常显示，说明 MDX 已经配置成功了。

关于 .md 和 .mdx 文件的共存

装了 MDX 集成后，你的 .md 文件还是正常工作的。Astro 会根据文件扩展名自动选择处理方式：

.md 文件：按标准 Markdown 处理 .mdx 文件：按 MDX 处理，支持组件和 JSX 我的建议是：普通文章用 .md，需要用组件的文章用 .mdx。

permalink: :year/:month/:day/:title

前往你的Hexo博客根目录，打开cmd命令窗口执行 npm install hexo-abbrlink --save

npm install hexo-abbrlink --save

修改站点配置文件 _config.yml

- permalink: :year/:month/:day/:title/
#修改为
+ permalink: post/:abbrlink.html # post为自定义前缀
+ abbrlink:
+   alg: crc32   #算法： crc16(default) and crc32
+   rep: hex     #进制： dec(default) and hex

如果开会不能产生价值，它就没有意义， 我称之为“虚假繁忙”。

会议必须解决问题

一定要明确，会议不是拿来讨论问题的，会议必须拿来解决问题。

如果你有了解决方案，希望大家表达意见可以开，方案确定以后要通知大家也可以开，除此之外不需要开会。开会是达成共识，而不是讨论问题，因为开会讨论问题不会有结果。

因此，会议必须要有一个很明确的主题，而且所有围绕这个主题的资料要提前准备，没有准备的会议就不要开，这是一个非常明确的要求。

如果这个方法论不做好的话，公司的整个效率都会低下。会议的工作方法决定公司两件事情，一个是效率，一个是品质。工作效率和工作品质就由会议方法论决定，一定不要小看这个会议的方法论。

会议由项目负责人主持

开会谁来做主持人？一般来说解决问题的负责人来做主持人，因为只有他才会想尽办法让这个会议有结果。如果不是对这个问题负责的人来主持，他就按流程把会议主持完，但是他绝对不关心会议的结果。这在方法论上是一个极大的错误。

很多公司开会很喜欢让老板来主持，我建议除了战略会之外，老板都不要主持，因为只有战略会是老板的责任，其他会都是别人的责任，应该让别人去做。比如说产品会、经营会，其实都不需要老板主持，就应该是那个主负责人去主持。

明确4个时间

会议的所有时间要约定下来，这包括4个时间：

• 开始和结束的时间。
• 发言的时间。
• 与会者决议达成共识的时间。
• 行动方案确认的时间。

我最怕大家开工作会议就是只出一个决定，这样远远不够，一定要把行动方案也确定下来，就是做什么不做什么，都要确定下来。

还有一个特别请大家注意的，日常工作中，一个有效的会议最长就是40分钟。

很多公司最喜欢开的都是几个小时的会，什么时候开那么长的会议，一个是战略会议，战略会议一般会封闭两三天，另一个就是半年度会议或者是年度会议。除此之外，日常会议都不要超过40分钟。

为什么要这么短？

两个原因，第一个原因就是来开会的人基本上都在重要岗位，开得越长，公司的成本越高。第二个原因就是解决问题的会议跟时间长度没关系，跟前期准备有关系。前期准备得越充分，会议效率就会越高，所以日常会议一定要短。

开会的核心是谈行动方案

开会的目的是要解决具体问题。因此，开会的核心主要是谈行动方案，不是谈观点，也不是谈问题。

我们在管理工作中遇到最大的问题是，大家陷在问题里。如果你仔细观察，会发现很多公司的会议都是问题导向的——只要有问题，就召开会议，也正因为如此，企业内部的会议非常多，另外，问题层出不穷。

正确的做法是，会议是行动方案导向的，也就是有问题不需要开会，而是明确行动方案才开会。有解决方案希望大家表达意见可以开，方案确定以后要通知大家也可以开，除此之外不需要开会，所有对问题的讨论都在会后做。

开会是达成共识，而不是讨论问题。因为讨论问题的会议往往很难达成共识，同时会耗费时间，需要多人参与，这对解决问题而言，不是最好的解决方式。

要知道，理解和判断问题应该是回到问题发生地，而不是在会议室。所以会议对于问题而言，不是最好的解决路径。

会议要得出结论

会议开完了，一定要下结论。如果议而不决，甚至经常无法把会议进行下去，经常跑题，经常争论并坚持各自的见解，恐怕就无法进行有效的决策了。我建议大家调整成这个样子：日常会议开完，大家都清楚要做什么，然后就去做了。

主要用来记录配置，以便后续自己查阅，不定时更新

修改维基名称

在wiki代码根目录，找到 LocalSettings.php ，修改相应代码为：

$wgSitename = "你的百科名称";

修改logo

现将文件上传到对应目录，即 /opt/lampp/htdocs/wiki/resources/assets/ 图片大小改动可以使用这个网站

在wiki代码根目录，找到 LocalSettings.php ，修改相应代码为：

## The URL path to the logo.  Make sure you change this from the default,
## or else you'll overwrite your logo when you upgrade!
$wgLogo = "$wgResourceBasePath/resources/assets/wiki.gif";

即将原先的 wiki.png 改为 wiki.gif

页面底部显示最后修订人名称

在wiki代码根目录，找到 LocalSettings.php ，增加代码

$wgMaxCredits = 2;

这样一来就可以显示最后修改的2条记录，比如说

本页面由公爵最后编辑于2022年10月18日 (星期二) 17:01。 基于Duke's Knowledge用户帝国执行官的工作。

关闭游客注册/修改/查看权限

在wiki代码根目录，找到 LocalSettings.php ，在最后面附加如下代码：

$wgGroupPermissions['*']['createaccount'] = true;
$wgGroupPermissions['*']['read'] = true;
$wgGroupPermissions['*']['edit'] = false;

即打开游客 注册 / 浏览 权限，关闭 修改 权限

定制侧边栏

进入URL： /index.php/MediaWiki:Sidebar

我们将上面使用的那个分类加入侧边栏，增加一行** 分类:Wiki定制化更好地使用wiki,其中后的文案，即你要显示在侧边栏的文本。

* navigation
** mainpagemainpage-description
** recentchanges-urlrecentchanges
** helppagehelp
** 分类:Wiki定制化更好地使用wiki

* SEARCH
* TOOLBOX
* LANGUAGES