这是一条演示评论。
示例昵称
我的
这是一条演示评论。
这是一条演示评论。
Billy 的代码手记
``` 分三步修改，每次保存后刷新页面： 1. **只改 HTML**：把 `class="nickname"` 改为 `class="aK7mQ2pL"`。文字仍在，但原来的紫色、背景和内边距不再匹配。 2. **再改 CSS**：把 `.nickname` 改为 `.aK7mQ2pL`。两边重新对应，样式恢复。 3. **一起换名**：把两处名称都改成 `billyName`。样式保持不变。 这个实验是手动改名，不是哈希生成器，也没有实现完整的 CSS Modules。它只验证最关键的一点：浏览器关心的是选择器能否匹配元素，不关心名称是否容易读懂。  *从左到右：名称匹配、只改 HTML 后失配、两边同步改名后重新匹配。* ## 用开发者工具检查类名和样式 先选中你关心的昵称或排名元素，在开发者工具的 Elements 面板看它有哪些类，再到 Styles 面板查看实际匹配的规则。看见一个陌生名称，不必先猜算法，先确认它控制的是颜色、间距还是布局。 如果想研究名称变化，就记录同一个元素在刷新、交互前后的类名与规则，同时检查页面加载的资源内容。只有一份 HTML，通常无法确认名称是在发布前、服务端还是浏览器里产生的。 写自己的组件时，通过工具提供的映射引用样式；做自己的页面测试时，优先使用语义定位或专用测试属性，避免把某次构建后的类名当成稳定接口。 在本文的榜单示例中，昵称始终是普通文本，改变的是元素与样式之间的标识。理解这套对应关系之后，再看实际页面，就能把“名称难读”“名称发生变化”和“为什么要这样设计”分开判断。 --- --- title: "Docker 部署 WebDAV：用 hacdias/webdav 搭建个人文件共享服务" source: https://www.iowill.com/blog/2026/10/docker-webdav-file-sharing/ date: 2026-10-04 updated: 2026-10-04 tags: [Docker, Docker Compose, WebDAV, 文件共享, 自托管] categories: [系统与运维] --- # Docker 部署 WebDAV：用 hacdias/webdav 搭建个人文件共享服务  如果只是想把服务器上的一个目录提供给电脑、手机和备份工具使用，可以先试试 WebDAV。它在 HTTP 上增加了目录、文件操作等能力；客户端是否支持挂载、锁定和大文件传输，要看具体实现。 这里使用 hacdias/webdav，配合 Docker Compose 管理配置和数据目录。先让服务只在宿主机上可访问，验证读写正常；需要给其他设备使用时，再开启服务自带的 TLS。整个方案只运行一个 WebDAV 容器，不需要管理面板或反向代理。 本文命令面向安装了 Docker Engine 和 Compose 插件的 Linux 主机，以普通 bridge 网络为例。域名 `dav.example.com` 是示例，公网访问时替换为自己的域名。以下响应码是验证预期，不是某台服务器的实测日志。 ## 三个路径与两个监听地址  配置文件在宿主机上保存，容器读取它；上传文件则写到单独的数据目录。容器更新后，仍然挂载同一份目录。 | 宿主机位置 | 容器内位置 | 用途 | | --- | --- | --- | | `/opt/webdav/config/` | `/config/` | 服务配置，只读挂载 | | `/opt/webdav/data/` | `/data/` | 用户文件，可读写 | | `/opt/webdav/certs/` | `/certs/` | 开启 HTTPS 时使用的证书，只读挂载 | 地址也有两层：配置中的 `0.0.0.0` 是应用在容器内的监听地址；Compose 中的 `127.0.0.1:6065:6065` 则把宿主机入口限制在回环地址。它们并不矛盾。Docker 的端口发布规则决定外部怎样进入容器，不能把容器自己的 `127.0.0.1` 当作宿主机地址。[Docker 端口发布说明](https://docs.docker.com/engine/network/port-publishing/) 建议使用受维护的 Docker 版本。Docker 官方特别说明，28.0.0 之前的版本存在同一二层网络设备可能访问回环发布端口的历史问题；不要只凭映射字符串就认定旧版本完全隔离。 ## 准备配置与数据目录 以下命令需要有创建 `/opt/webdav` 目录和执行 Docker 的权限。先确认工具可用： ```bash docker version docker compose version mkdir -p /opt/webdav/config /opt/webdav/data /opt/webdav/certs cd /opt/webdav ``` 创建 `/opt/webdav/config/config.yml`： ```yaml address: 0.0.0.0 port: 6065 tls: false directory: /data permissions: R behindProxy: false users: - username: demo password: "REPLACE_WITH_A_UNIQUE_PASSWORD" permissions: CRUD ``` 先把密码占位文字换成专用的长随机密码，再启动服务。配置文件里的 `R` 是默认只读，`demo` 用户单独获得创建、读取、更新、删除权限。不要删掉 `users` 后误以为仍然需要登录。 服务也支持 bcrypt 格式的密码和按用户设置目录；字段含义及密码生成方式可以对照 [hacdias/webdav 官方配置](https://github.com/hacdias/webdav#configuration)。使用哈希能减少明文密码落盘，但不能代替 HTTPS。 ```bash chmod 600 /opt/webdav/config/config.yml ``` 如果后续给容器指定了非 root 用户，需要同时调整文件的属主和权限，让该用户能读取配置、写入数据目录。不要用 `chmod -R 777` 来跳过权限问题。 ## 用 Docker Compose 启动 保存为 `/opt/webdav/compose.yml`： ```yaml services: webdav: image: ghcr.io/hacdias/webdav:latest restart: unless-stopped command: ["-c", "/config/config.yml"] ports: - "127.0.0.1:6065:6065" volumes: - ./config:/config:ro - ./data:/data logging: driver: json-file options: max-size: "10m" max-file: "3" ``` 这里用 `latest` 方便首次尝试。准备长期运行时，应先确认一个可用版本，再把镜像固定到该版本标签或摘要，避免以后拉取时悄悄更换版本。 ```bash cd /opt/webdav docker compose config --quiet docker compose pull docker compose up -d docker compose ps docker compose logs --tail=50 webdav ``` `config --quiet` 只检查 Compose 文件，不验证 WebDAV 的 YAML 是否正确。容器反复重启时，先看日志里的配置解析、文件读取和端口错误。 ## 用 curl 验证列目录、上传和下载 以下命令在 Docker 宿主机执行。`-u demo` 会让 curl 交互式询问密码；没有把密码直接放进命令行。[curl 参数说明](https://curl.se/docs/manpage.html) 先查看目录： ```bash curl -i -u demo -X PROPFIND \ -H "Depth: 1" \ http://127.0.0.1:6065/ ``` 正常情况下应看到 `207 Multi-Status` 和 XML。`-i` 用于显示响应头；只把正文管道给 `head`，不能据此确认 HTTP 状态码。207 代表多状态响应，操作是否全部成功还要看 XML 中各项状态。 再创建独立测试目录，避免碰到已有文件： ```bash probe="webdav-check-$(date +%Y%m%d%H%M%S)" curl -i -u demo -X MKCOL "http://127.0.0.1:6065/$probe/" printf 'hello webdav\n' > /tmp/webdav-probe.txt curl -i -u demo -T /tmp/webdav-probe.txt \ "http://127.0.0.1:6065/$probe/probe.txt" curl --fail --silent --show-error -u demo \ "http://127.0.0.1:6065/$probe/probe.txt" ``` 新建目录和新文件通常返回 201；覆盖已有文件可能返回 204。下载内容应为 `hello webdav`。也可以在宿主机的数据目录里确认文件是否实际写入。 文件能上传，不代表客户端的复制和重命名就一定正常。继续在同一终端里验证这两个操作： ```bash curl -i -u demo -X COPY \ -H "Destination: http://127.0.0.1:6065/$probe/copy.txt" \ -H "Overwrite: F" \ "http://127.0.0.1:6065/$probe/probe.txt" curl -i -u demo -X MOVE \ -H "Destination: http://127.0.0.1:6065/$probe/renamed.txt" \ -H "Overwrite: F" \ "http://127.0.0.1:6065/$probe/copy.txt" ``` `Destination` 与请求使用相同的地址和端口；`Overwrite: F` 避免覆盖已有目标。本方案直接连接服务，不需要套用反代场景中的请求头重写配置。 ## 让其他设备通过 HTTPS 连接 上面的端口只在服务器本机开放，手机连不上是预期行为。若要在公网使用，先准备指向服务器的域名，以及覆盖该域名、被客户端信任的证书。 将证书链和私钥分别放到： ```text /opt/webdav/certs/fullchain.pem /opt/webdav/certs/privkey.pem ``` 这一步假设你已经取得有效证书；容器不会因为填了域名就自动签发或续期。复制证书时注意来源是否为符号链接，最终应确保挂载目录内能直接读取完整文件。 在 `config/config.yml` 中把 TLS 设置改为： ```yaml tls: true cert: /certs/fullchain.pem key: /certs/privkey.pem ``` 其他配置保持不变，容器内端口仍然是 6065。然后把 Compose 的 `ports` 和 `volumes` 分别替换为以下内容，注意是替换，不要保留两个同名 YAML 键： ```yaml ports: - "443:6065" volumes: - ./config:/config:ro - ./data:/data - ./certs:/certs:ro ``` 先确认宿主机 443 没有被其他程序占用，配置好相应的入站访问规则，再应用修改： ```bash cd /opt/webdav docker compose config --quiet docker compose up -d --force-recreate docker compose logs --tail=50 webdav curl -i -u demo -X PROPFIND -H "Depth: 0" https://dav.example.com/ ``` TLS 由 WebDAV 服务自己处理。请用域名访问，直接换成 IP 可能导致证书名称校验失败；不要通过长期添加 `-k` 掩盖问题。若域名同时配置了 AAAA 记录，也要验证 IPv6 路径，避免部分设备连接到错误地址。 然后在另一台设备上，把前面的测试地址换成 `https://dav.example.com`，重新检查上传、下载、COPY 和 MOVE。服务端本机能连通，并不代表外部的 DNS、防火墙和证书都正确。 证书更新后执行 `docker compose restart webdav` 重新加载，并检查实际返回的证书。证书获取和续期属于独立维护事项。 ## 客户端连接时填什么 | 项目 | 示例 | | --- | --- | | 协议 | WebDAV / HTTPS | | 地址 | `https://dav.example.com/` | | 用户名 | `demo` 或你自己的账号 | | 密码 | 配置中对应账号的密码 | macOS 可以在 Finder 的“连接服务器”中输入 HTTPS 地址；移动端需要使用支持 WebDAV 的文件管理应用。Windows 的资源管理器连接依赖 WebClient 等组件和系统策略，不能把所有版本都当成相同行为。遇到问题时，先用 curl 区分服务故障和客户端兼容性。 备份任务可以使用 rclone。运行 `rclone config`，创建名为 `webdav` 的远端，类型选 WebDAV，填写 URL、用户名和密码，通用服务商选项使用 `other`。配置好以后先执行只读检查： ```bash rclone lsd webdav: rclone copy ./photos webdav:photos --dry-run ``` 确认目标无误后，再去掉 `--dry-run`。这里使用 `copy`，不使用会按源目录状态删除目标文件的 `sync`。客户端字段以 [rclone WebDAV 文档](https://rclone.org/webdav/) 为准。 ## 连接失败或不能写入，从哪里查 | 表现 | 先检查什么 | | --- | --- | | 容器启动后立刻退出 | YAML 缩进、配置挂载路径、证书读取权限 | | 本机连接被拒绝或重置 | 容器状态、日志、应用是否监听 `0.0.0.0:6065`、发布端口是否正确 | | 本机能访问，其他设备不能 | 是否仍绑定宿主机回环、DNS、端口放行、IPv4/IPv6 路径 | | 返回 401 | 用户名密码、客户端保存的旧凭据、是否读取了预期配置 | | 能读取但不能上传 | 账号 C/U 权限、宿主机目录写权限、磁盘剩余空间 | | COPY/MOVE 失败 | Destination 的主机和端口、目标父目录、账号权限、目标是否已存在 | | HTTPS 校验失败 | 域名与证书匹配、有效期、完整证书链、客户端时间 | 容器内只监听 `127.0.0.1` 时，监听的是容器自己的回环；普通 bridge 模式下，发布端口流量进入容器网卡，不会因此到达该监听地址。修改为 `0.0.0.0` 后，仍然要通过宿主机端口绑定决定开放范围。 改了 WebDAV 配置后执行 `docker compose restart webdav`；改了端口或挂载等 Compose 设置，则执行 `docker compose up -d` 重新应用。若仍有疑问，可通过 `docker inspect` 核对实际挂载和端口，而不是只看文件中的预期设置。 ## 更新容器之前，先确认数据在哪 上传目录通过 bind mount 保存到宿主机。删除并重建容器通常不会删除这份目录，但直接删除宿主机数据、错误覆盖文件或磁盘故障仍会造成损失。持久化不等于备份。[Docker bind mount 说明](https://docs.docker.com/engine/storage/bind-mounts/) 更新前记录当前镜像标签或摘要，并备份配置和数据；需要一致性备份时，暂停写入或停服务后再备份。确认新版本兼容后再执行： ```bash cd /opt/webdav docker compose pull docker compose up -d ``` 更新后重新跑一遍读写验证。只读账号可以设为 `R`；不授予删除权限能减少部分误操作，但有更新权限的账号仍可能覆盖文件，不能当作防勒索备份策略。 部署完成的标准很具体：客户端能验证证书、登录、列目录和读写文件；数据确实落在宿主机预期目录；重建容器后文件仍在。把这几项验证清楚，比只看到容器状态为 Running 更有用。 ## 参考资料 - [hacdias/webdav 项目与配置](https://github.com/hacdias/webdav) - [Docker 端口发布](https://docs.docker.com/engine/network/port-publishing/) - [Docker bind mounts](https://docs.docker.com/engine/storage/bind-mounts/) - [curl 参数说明](https://curl.se/docs/manpage.html) - [rclone WebDAV](https://rclone.org/webdav/) --- --- title: "从 Vibe Coding 到 Spec Coding：让 AI 写得快，也改得稳" source: https://www.iowill.com/blog/2026/09/from-vibe-coding-to-spec-coding/ date: 2026-09-30 updated: 2026-09-30 tags: [AI 编程, Spec Coding, Vibe Coding, 软件工程, 需求分析] categories: [编程开发] --- # 从 Vibe Coding 到 Spec Coding：让 AI 写得快，也改得稳 .png) “帮我把文章卡片改得好看一点。” AI 很快更新一版：圆角更大，封面比例统一，标题可以显示两行，页面背景也有了一层渐变。 但卡片太高，日期和分类挤到两行，侧栏为了和文章列表对齐被拉出了空白。于是回滚再补一句新要求。 这类过程很适合讨论 AI 编程中的一个变化：当生成代码变得越来越容易，我们需要更认真地管理“到底要改成什么”和“怎样证明已经改对”。 本文把 **Spec Coding** 用作“围绕明确规范进行 AI 辅助开发”的简称，对应通常所说的 **Spec-Driven Development，规范驱动开发**。它不是一个所有工具都严格统一使用的产品名称。 ## 1\. Vibe Coding 的吸引力：先把想法做出来 在本文的讨论范围内，Vibe Coding 指一种偏向对话和即时反馈的开发方式：描述想法，让 AI 生成实现，运行看看，再根据结果继续调整。这里讨论的是工作方式，不把所有使用 AI 写代码的行为都归入这个词。 它适合解决“我还不知道想要什么，但想先看到一个版本”的问题。 例如，准备做一个个人博客，你可能暂时无法回答卡片的精确尺寸、页面的信息密度或导航的交互细节。先做一个能打开的页面，比对着空白文档讨论两小时更容易形成判断。 这个阶段可以允许尝试，也可以接受推翻。原型的价值，是帮助人发现真实需求。 问题出在：原型不断叠加功能之后，开发方式却没有变化。 “加一个分类”“更新时间”“改一下侧栏”逐渐变成会影响多个页面、数据文件和维护脚本的操作。如果仍然只看当前页面是否顺眼，很容易漏掉别的地方。 ## 2\. 为什么越改越乱？要求散落在对话里 以静态博客为例，发布一篇文章不只是生成一个 HTML 文件。 首页卡片要增加，超过页容量的文章要后移；归档要登记，搜索索引要补条目；分类和标签要同步，侧栏统计和最新文章也要更新。 这些要求如果只存在于聊天记录中，会出现三个问题。 **第一，最新要求与旧要求混在一起。** 上一轮说“侧栏底部和文章对齐”，下一轮又说“取消对齐，恢复原布局”。如果旧约定仍然留在文档里，后续维护可能把已经撤销的方案重新做回来。 **第二，视觉结果掩盖了数据问题。** 首页能够正常打开，不代表搜索能找到新文章；卡片看起来正常，也不代表网站文章数已经从 43 更新成 44。 **第三，实现和完成标准由同一个模糊描述决定。** 如果要求只是“优化一下”，AI 可以通过自己选定的标准宣告完成。代码可能符合它的理解，却没有符合你的预期。 把这些问题全部归结为“提示词不够长”，并不准确。真正需要补充的是：可定位的需求、明确的范围，以及能独立检查的完成条件。 ## 3\. Spec Coding 把哪些事情提前了？  *两种工作方式可以衔接：先探索需求，再明确规范和验收条件。* 一份有用的 Spec，至少能回答四个问题： 1. 谁在什么场景下遇到了什么问题？ 2. 本次需要出现什么行为？ 3. 哪些限制必须满足，哪些内容不在本次范围内？ 4. 用什么证据判断已经完成？ GitHub 的 Spec Kit 将需求描述、澄清、技术计划、任务拆解和实现验证组织成显式流程；其文档也强调在需求阶段先说明要做什么及原因，再处理技术方案。[GitHub Spec Kit 官方指南](https://github.github.com/spec-kit/quickstart.html) “目标是什么”与“准备怎样实现”应分开记录。以下文件划分是本文建议的轻量实践，不要求安装特定工具。 | 材料 | 回答的问题 | 博客示例 | | --- | --- | --- | | Spec | 最终应该有什么行为？ | 每页最多 18 篇，发布后文章无重复遗漏 | | Plan | 如何实现？ | 按时间排序，依次生成分页并更新链接 | | Tasks | 分成哪些可执行步骤？ | 登记文章、更新分页、同步搜索、校验 | | Evidence | 实际做成了什么？ | 数量检查、链接检查、浏览器截图和部署结果 | 这里最容易忽略的是最后一项。任务清单打满勾，不代表测试真的运行过；测试通过，也不代表页面已经在线上部署成功。 ## 4\. 把“卡片排紧一点”写成一份小 Spec 不必一开始就建立复杂流程。一个具体的小功能，可以从这样的说明开始： ```markdown # 文章卡片时间与分类单行显示 ## 问题 首页部分卡片的日期和分类换行，导致信息区不整齐。 ## 范围 首页及其分页的文章卡片。 不调整文章正文中的发布时间，不改变每页文章数量。 ## 预期行为 - 日期格式为 YYYY/MM/DD HH:mm:ss，使用北京时间。 - 日期与分类在同一行。 - 完整时间不截断，分类仍然可以点击。 - 空间确实不足时，分类名称允许省略号截断。 - 卡片只出现一个分类图标。 ## 约束 - 保留现有主题、配色和圆角。 - 不通过横向溢出页面来强行放下一行。 - 不修改原始 datetime，不编造时间。 ## 验收 - 在 360px、768px、1024px、1440px 宽度检查布局。 - 覆盖最长分类名和完整时间组合。 - 浅色、深色模式均可读，分类链接可访问。 - 首页分页链接和文章总数与修改前一致。 ``` 这份 Spec 没有规定必须使用 Flex 还是 Grid，也没有提前指定每一处 CSS。它给实现留出空间，同时结果写清楚。 上面的视口宽度是示例验收范围，不是宣称这些页面已经完成了对应测试。需要亲自记录实际验证情况。 如果这些条件无法同时满足，应当暴露冲突。例如，为了完整显示最长分类，字号是否会小到难以阅读？这时需要调整规则，而不是把文字缩得越来越小后宣告成功。 ## 5\. 再进一步：把发布文章变成可验证流程 视觉调整可以用轻量 Spec。涉及多个数据源的发布操作，更适合补上明确的不变量。 静态博客示例假设每页 18 篇，发布前共有 43 篇。 ```markdown # 发布新文章 ## 输入 - 已审核的正文、标题、摘要和封面 - 唯一 slug - 含时区的发布时间 - 一个分类及若干标签 ## 完成条件 - 文章页面、分类登记、搜索索引均包含新文章。 - 发布后总数为 44：首页分页分布为 18/18/8。 - 各分页按发布时间倒序，无重复、无遗漏。 - 总归档及对应年月归档包含新文章。 - 作者卡与网站资讯显示相同的文章总数。 - 最新文章按发布时间选取最近 5 篇。 - sitemap 包含新文章的规范 URL。 - 原有文章正文没有意外改动。 ## 异常处理 - slug 重复：停止写入，报告冲突。 - 搜索条目缺失或重复：校验失败，不标记为发布完成。 - 部署未完成：报告已推送、待部署，不宣称已经上线。 ``` 这个例子里的 44 和 18/18/8 是针对一次发布的具体预期。长期维护的检查应尽量从真实文章集合推导总数，再独立验证分页中实际出现的链接；不要每次靠手动修改一串散落的常量。 同时，测试不能只比较两个都由同一个错误变量生成的数字。否则源数据少了一篇，两边仍然可能相等。可以交叉检查文章文件、登记表、搜索索引和分页链接集合，并明确哪个集合应当包含哪些文章。 ## 6\. 一个适合个人项目的工作循环  *SPEC：规范；PLAN：计划；BUILD：实现；VERIFY：验证；REFINE：反馈修订。* 我更倾向于把流程控制在六步，而不是要求每次改颜色都写一套长文档。 ### 先调查现状 让 AI 阅读相关代码、文档和已有检查，确认当前行为与问题位置。已有项目尤其要注意：仓库里有没有源工程？哪些文件是生成结果？哪个脚本会覆盖当前修改？ 不了解这些边界，写出来的 Spec 可能建立在错误前提上。 ### 写下本次目标和验收 复杂功能可以单独建立 `spec.md`；小修改在任务说明中写几条就够了。区分已经确定的要求、暂定假设与尚未回答的问题。 ### 选择最小可行方案 检查主题原有能力和现有脚本，再决定是否增加代码。方案应说明主要改动点和影响范围，避免为了一个小效果引入新的框架。 ### 按小块实现 优先完成一条能验证的路径，再扩展到全站。批量 HTML 修改尤其要先确认替换边界，不能因为一个正则在单页有效，就认定所有页面都安全。 ### 按验收条件收集证据 数据问题用数量、集合和链接检查；视觉问题用实际浏览器；部署问题看部署结果和线上页面。没有运行的检查要明确标记，不能用“应该没问题”替代证据。 ### 同步最终规范 实现过程中发现更合适的规则，应当更新 Spec。已经取消的方案移到变更记录中，现行规范只保留当前有效要求。 在博客项目里，`docs` 可以保存长期约定，功能 Spec 保存一次改动的边界，变更记录解释为什么变更。三者职责不同，避免把所有历史对话原样堆在同一个文件里。 ## 7\. Spec 也会出问题 规范不会自动让 AI 变得可靠。写得不好，它只是把模糊需求换成了更正式的排版。 常见问题包括： - **不可验证：** “更高级”“性能更好”“体验更流畅”，没有场景和可判断的结果。 - **过早限定实现：** 还没确认问题，就要求换框架、重写模块或引入新服务。 - **只覆盖正常路径：** 没考虑空数据、重复输入、错误时间、失败部署和既有数据兼容。 - **规范与代码脱节：** 功能已经变了，文档还保留旧行为。 - **测试复述实现：** AI 按错误理解写代码，再按同样的理解写测试，两者一致但都不符合真实需求。 应对方式不是继续增加文档长度，而是使用具体案例、边界输入和独立审查。对于权限、数据迁移或外部副作用，尤其需要核对失败时会发生什么，以及如何恢复。 ## 8\. 什么时候用哪一种方式？ | 场景 | 建议做法 | | --- | --- | | 探索一个尚未成形的想法 | 快速原型，尽早看结果，允许推翻 | | 改一处文案或局部样式 | 几条目标与验收即可，不必写完整方案文档 | | 改动多个页面或数据文件 | 轻量 Spec、影响范围与自动检查一起做 | | 长期维护、多人协作的功能 | 持续维护规范、接口约定及回归证据 | | 涉及权限、数据迁移或重要业务 | 明确失败行为、审查责任与恢复方案 | 探索与规范可以连续发生。先用原型发现需求，再把已经确认的行为固定下来，后续实现围绕这些行为展开。 也不必把 Spec Coding 等同于某一个工具。GitHub Spec Kit 和 Kiro 都提供了围绕规范组织 AI 开发的能力，但个人项目可以先从仓库中的 Markdown 和现有测试开始。工具值得关注的地方，是它能否帮助需求、任务与实现保持一致。[Kiro Specs 官方文档](https://kiro.dev/docs/specs/) ## 9\. 可以直接使用的任务提示词 ```text 请先阅读相关代码和项目约定，概括当前行为及本次问题。 基于以下目标整理一份轻量 Spec，包含： 用户场景、范围、非目标、约束、异常情况和验收条件。 已有明确答案的事项直接使用；只列出会影响实现的未知问题。 然后提出最小可行实施方案，指出需要同步的数据和文件。 实现过程中如果需求与现状冲突，说明冲突并更新方案。 完成后逐项给出验证结果： 哪些检查实际运行、结果如何、哪些尚未验证。 最后同步现行规范，避免保留已经撤销的要求。 ``` 这段提示词只是起点。真正有价值的部分，是你为当前任务填入的场景、边界和判断标准。 AI 可以很快写出一个看起来可用的版本。让它在几周之后仍然容易修改、能够验证、不会反复踩同一个坑，需要把需求和证据也放进开发过程里。 从 Vibe Coding 到 Spec Coding，值得保留的是探索的速度，值得补上的，是对“完成”更清楚的定义。 ## 参考资料 - [GitHub Spec Kit](https://github.com/github/spec-kit)：开源规范驱动开发工具包。 - [Spec Kit 官方快速开始](https://github.github.com/spec-kit/quickstart.html)：需求、计划、任务与验证流程。 - [Kiro Specs 官方文档](https://kiro.dev/docs/specs/)：围绕规范组织开发的工具实践。 本文中的博客 Spec、验收样例和工作流程建议为结合静态博客维护场景整理的示例，并非上述工具的默认配置。工具命令与支持能力可能变化，实际使用以官方文档为准。 --- --- title: "Debian多网卡Docker-MySQL回程路由排查" source: https://www.iowill.com/blog/2026/09/debian-docker-mysql-multi-nic-routing/ date: 2026-09-29 updated: 2026-10-09 tags: [Debian, Docker, MySQL, 容器网络, 故障排查, 策略路由] categories: [系统与运维] --- # Debian多网卡Docker-MySQL回程路由排查 在一台 Debian 服务器上配置了多块网卡，每块网卡都有独立公网 IP。MySQL 通过 Docker 部署，发布端口为 `3306`。 实际使用时发现： - 使用 eth0 的公网 IP，可以连接 MySQL。 - 使用其他网卡的公网 IP，连接超时。 - 已经配置了基于公网源 IP 的策略路由，但问题依然存在。 最终通过抓包确认：**请求从 eth1 进入，经过 Docker 转发到 MySQL；MySQL 的回复却从 eth0 发出。** 本文记录排查过程和经过验证的修复方法。文中所有 IP 地址均为文档保留地址（RFC 5737），仅作示意：203.0.113.10 是 eth0 公网地址，198.51.100.20 是 eth1 公网地址，203.0.113.1 / 198.51.100.1 是两块网卡的网关，172.20.0.2 是 MySQL 容器地址，0.0.0.0 表示监听所有本机 IPv4 地址。命令和输出均为示意，请替换为你自己的实际配置后再执行。 ## 一、环境与现象 以 eth0、eth1 为例： | 对象 | 地址或配置 | | --- | --- | | eth0 | `203.0.113.10/24` | | eth0 网关 | `203.0.113.1` | | eth1 | `198.51.100.20/24` | | eth1 网关 | `198.51.100.1` | | Docker 网桥 | `br-cb0d8db03272` | | MySQL 容器 IP | `172.20.0.2` | | Docker 端口映射 | `0.0.0.0:3306->3306/tcp` | 主路由表默认出口为 eth0： ```text default via 203.0.113.1 dev eth0 ``` 同时，服务器已经配置了 eth1 的源地址策略路由： ```text from 198.51.100.20 lookup 199 ``` 路由表 `199` 内容为： ```text default via 198.51.100.1 dev eth1 ``` 在 Windows 客户端测试 eth1 的 MySQL 端口： ```powershell Test-NetConnection 198.51.100.20 -Port 3306 ``` 结果为： ```text TcpTestSucceeded : False ``` ## 二、先排除监听地址和反向路径过滤 查看容器端口映射： ```bash docker ps --format 'table {{.Names}}\t{{.Ports}}' ``` MySQL 显示： ```text 0.0.0.0:3306->3306/tcp ``` 查看宿主机监听： ```bash ss -lntp ``` 对应输出： ```text LISTEN 0 4096 0.0.0.0:3306 0.0.0.0:* users:(("docker-proxy",...)) ``` 这说明宿主机的 3306 发布在所有 IPv4 地址上，并没有只绑定 eth0。不过，监听所有地址不代表端到端网络一定可达。[Docker 端口发布文档](https://docs.docker.com/engine/network/port-publishing/) 接着查看反向路径过滤： ```bash sysctl net.ipv4.conf.all.rp_filter \ net.ipv4.conf.eth0.rp_filter \ net.ipv4.conf.eth1.rp_filter ``` 本次环境输出均为 `0`。 因此，可以排除 eth0、eth1 上的 `rp_filter` 检查导致丢包。其他环境如果使用严格模式 `1`，多网卡的非对称路由可能触发丢包，需要单独核查。[Linux 内核文档](https://www.kernel.org/doc/html/next/networking/ip-sysctl.html) ## 三、抓包发现：eth1 进，eth0 出  故障路径：eth1 进入，eth0 返回 在服务器执行： ```bash tcpdump -ni any -nn \ 'tcp port 3306 and not (src net 172.20.0.0/16 and dst net 172.20.0.0/16)' ``` 这里过滤掉了 Docker 子网内部的通信，避免把其他容器访问 MySQL 的正常流量误当成外部测试流量。 随后，在外部 Windows 客户端重新测试： ```powershell Test-NetConnection 198.51.100.20 -Port 3306 ``` 抓包得到的关键过程如下： ```text eth1 In: 客户端 → 198.51.100.20:3306 SYN Docker 网桥 Out: 客户端 → 172.20.0.2:3306 SYN Docker 网桥 In: 172.20.0.2:3306 → 客户端 SYN-ACK eth0 Out: 198.51.100.20:3306 → 客户端 SYN-ACK ``` 这段输出证明了三件事： 1. 外部请求已经到达 eth1。 2. Docker 已将请求转发给 MySQL，MySQL 也发出了回复。 3. 回复使用 eth1 的公网源地址，却从 eth0 发出。 之后可以看到重复的 SYN 和 SYN-ACK，但没有完成握手。 **回程出口错误已经确定。** 至于回复具体在哪里被丢弃，仅靠服务器侧抓包无法确定；上游网络可能对源地址与出口的对应关系有限制。 ## 四、为什么已有源 IP 策略路由仍然无效？ 已有规则匹配的是公网源地址： ```text from 198.51.100.20 lookup 199 ``` 但 Docker 容器回复经过宿主机转发时，在选择路由的阶段，源地址仍然是： ```text 172.20.0.2 ``` 它无法匹配上面的公网源地址规则，于是使用主路由表，从 eth0 出口发送。 之后，连接跟踪对应的反向 NAT 才将源地址恢复成： ```text 198.51.100.20 ``` 因此，在物理网卡上抓到的最终数据包表现为： ```text eth0 Out，源地址却是 eth1 的公网 IP ``` 这也解释了为什么 eth0 能连接：主路由表的默认出口恰好就是 eth0，而其他网卡需要正确的回程选路。 ## 五、修复：识别连接的回包，再按标记选路  修复原理：识别回包，按标记选路 本次采用的办法是： 1. 利用连接跟踪，识别原本访问 `198.51.100.20:3306` 的连接。 2. 只给该连接的回复方向数据包添加标记。 3. 根据标记，使用已有的路由表 `199`，从 eth1 发出。 `--ctorigdst` 和 `--ctorigdstport` 匹配连接的原始目的地址及端口；`--ctdir REPLY` 限定回复方向。这样即使当前数据包的源地址还是容器 IP，也能识别它属于哪个公网入口的连接。[iptables 扩展手册](https://man7.org/linux/man-pages/man8/iptables-extensions.8.html) 以下命令中的 IP、网桥名、路由表编号需要替换为实际配置；规则优先级和标记也应避免与已有用途冲突。以下添加命令执行一次即可，重复执行会累积规则。 先添加按标记选路的规则： ```bash ip rule add priority 10199 \ fwmark 0x199/0xffffffff lookup 199 ``` 再对指定连接的回包打标： ```bash iptables -t mangle -I PREROUTING 1 \ -i br-cb0d8db03272 \ -p tcp \ -m conntrack --ctdir REPLY \ --ctorigdst 198.51.100.20 \ --ctorigdstport 3306 \ -j MARK --set-xmark 0x199/0xffffffff ``` 这里的 `0x199` 是自定义的数据包标记，不是路由表编号的自动转换；是 `ip rule` 将该标记关联到了路由表 `199`。[ip rule 手册](https://man7.org/linux/man-pages/man8/ip-rule.8.html) 规则只匹配回复方向，进入容器的原始请求不会被这条规则标记。 ## 六、验证结果 客户端再次执行： ```powershell Test-NetConnection 198.51.100.20 -Port 3306 ``` 结果变为： ```text TcpTestSucceeded : True ``` **实际验证表明，新增规则后 eth1 的 MySQL 端口恢复了 TCP 连通。** 这也支持了此前关于 Docker 回程路由的判断。 如果需要进一步确认，可以重新抓包，检查 SYN-ACK 是否从 eth1 发出，并查看规则命中计数： ```bash iptables -t mangle -nvL PREROUTING --line-numbers ``` 最后再用 MySQL 客户端登录。TCP 连通和数据库认证是两个阶段；如果此时出现 `Access denied`，应继续检查 MySQL 用户授权和认证配置。 ## 七、回滚与持久化说明 撤销本次规则： ```bash iptables -t mangle -D PREROUTING \ -i br-cb0d8db03272 \ -p tcp \ -m conntrack --ctdir REPLY \ --ctorigdst 198.51.100.20 \ --ctorigdstport 3306 \ -j MARK --set-xmark 0x199/0xffffffff ip rule del priority 10199 \ fwmark 0x199/0xffffffff lookup 199 ``` 本次验证的是 **eth1 的 MySQL 3306 端口临时修复**，尚未验证其他网卡，也没有完成重启持久化。 扩展到其他公网 IP 时，需要为各入口配置对应的连接匹配、标记和路由表。持久化时则要同时恢复策略路由和防火墙规则，并确保执行顺序正确、重复执行不会累积规则。另外，Docker 网络重建后网桥名称可能变化，本文规则中的网桥名也需要同步检查。 这次排查最关键的证据，是抓包中的这一行：**eth1 的公网源地址出现在了 `eth0 Out` 上。** 端口确实开放、数据库也确实回复了，但回复没有沿着正确的出口返回。 --- --- title: "TigerVNC 锁屏问题解决方案" source: https://www.iowill.com/blog/2026/09/tigervnc-lock-screen-fix/ date: 2026-09-10 updated: 2026-10-14 tags: [Linux, TigerVNC, VNC, 故障排查, 远程桌面] categories: [系统与运维] --- # TigerVNC 锁屏问题解决方案 ## 问题诊断 - **根本原因**：Linux `logind` 服务将会话标记为”locked”（常见于休眠/锁屏后） - **典型表现**： - VNC 连接后黑屏 - 认证失败提示 - **直接解决方案**： ```bash loginctl unlock-sessions # 解锁所有会话 ``` * * * \[TOC\] * * * ## 永久性解决方案 ### 方案A：禁用自动锁屏（推荐用于服务器） ```bash gsettings set org.gnome.desktop.screensaver lock-enabled false gsettings set org.gnome.desktop.session idle-delay 0 ``` ### 方案B：配置自动解锁（需要polkit规则） 创建规则文件： ```bash sudo nano /etc/polkit-1/rules.d/85-unlock-vnc.rules ``` 添加内容： ```javascript polkit.addRule(function(action, subject) { if (action.id == "org.freedesktop.login1.unlock" && subject.isInGroup("vncusers")) { return polkit.Result.YES; } }); ``` ### 方案C：系统级会话保持 ```bash sudo nano /etc/systemd/logind.conf ``` 修改关键参数： ```ini IdleAction=ignore HandleLidSwitch=ignore ``` ## 系统状态验证 检查会话状态 ```bash loginctl list-sessions ``` 预期输出示例： ```plaintext SESSION UID USER SEAT TTY STATE 1 1000 user1 seat0 tty2 active # 确保状态非locked ``` 实时监控命令 ```bash journalctl -f -u systemd-logind | grep -E 'SessionLock|SessionUnlock' ``` ## VNC服务优化配置 修改xstartup脚本 ```bash nano ~/.vnc/xstartup ``` 添加以下内容： ```bash #!/bin/bash # 禁用GNOME自动锁屏 gsettings set org.gnome.desktop.screensaver lock-enabled false exec gnome-session ``` **关键命令速查表** | 场景 | 命令 | | :-- | :-: | | 解锁指定会话 | loginctl unlock-session | | 解锁所有会话 | loginctl unlock-sessions | | 查看锁定状态 | loginctl show-session | | 禁用休眠功能 | systemctl mask sleep.target suspend.target | 检查最近锁屏记录： ```bash journalctl -u systemd-logind --since "1 hour ago" ``` --- --- title: "Ubuntu GNOME 桌面安装和配置 TigerVNC，包含服务设置、桌面环境适配和防火墙配置" source: https://www.iowill.com/blog/2026/09/ubuntu-gnome-tigervnc-setup/ date: 2026-09-10 updated: 2026-10-14 tags: [GNOME, TigerVNC, Ubuntu, VNC, 远程桌面] categories: [系统与运维] --- # Ubuntu GNOME 桌面安装和配置 TigerVNC，包含服务设置、桌面环境适配和防火墙配置 ## 一、安装 TigerVNC ```bash sudo apt update sudo apt install tigervnc-standalone-server tigervnc-common -y ``` ## 二、首次配置 ### 1\. 设置 VNC 密码（长度需 ≥6 位） ```bash vncpasswd ``` 密码文件会保存在 ~/.vnc/passwd。 ### 2\. 创建 xstartup 配置文件（适配不同桌面环境） ```bash mkdir -p ~/.vnc nano ~/.vnc/xstartup ``` 根据桌面环境选择配置： #### ***GNOME 桌面：*** ```bash #!/bin/bash export GNOME_SHELL_SESSION_MODE=ubuntu export XDG_CURRENT_DESKTOP=ubuntu:GNOME export XDG_CONFIG_DIRS=/etc/xdg/xdg-ubuntu:/etc/xdg dbus-launch --exit-with-session /usr/bin/gnome-session --session=ubuntu ``` #### ***XFCE 桌面（轻量级推荐）：*** ```bash #!/bin/bash xrdb $HOME/.Xresources startxfce4 & ``` #### ***KDE Plasma 桌面：*** ```bash #!/bin/bash startplasma-x11 & ``` ### 3.赋予执行权限： ```bash chmod +x ~/.vnc/xstartup ``` ## 三、启动 VNC 服务 ### 临时启动（端口 5901）： ```bash vncserver :1 -geometry 1920x1080 -depth 24 -localhost no ``` - \-localhost no：允许外部连接 - :1 对应端口 5901（:2 → 5902，依此类推） ### 查看运行中的实例： ```bash vncserver -list ``` ## 四、设置系统服务（开机自启） ### 1\. 创建 systemd 服务文件 ```bash sudo nano /etc/systemd/system/vncserver@.service ``` ***粘贴以下内容（注意替换 USER）：*** ```ini [Unit] Description=Remote desktop service (VNC) After=syslog.target network.target [Service] Type=simple User=root # 改为实际用户名 ExecStart=/usr/bin/vncserver :%i -geometry 1920x1080 -depth 24 -localhost no ExecStop=/usr/bin/vncserver -kill :%i Restart=on-failure [Install] WantedBy=multi-user.target ``` ### 2\. 启用并启动服务 ```bash sudo systemctl daemon-reload sudo systemctl enable vncserver@1 # 对应 :1 实例 sudo systemctl start vncserver@1 ``` ### 3\. 检查状态 ```bash sudo systemctl status vncserver@1 ``` ## 五、防火墙放行 ```bash sudo ufw allow 5901/tcp sudo ufw reload ``` ## 六、客户端连接 > 地址：<服务器IP>:5901 > 或者ssh客户端内部连接：localhost:5901 ***客户端工具：*** Windows: [TigerVNC Viewer](https://sourceforge.net/projects/tigervnc/files/latest/download) Linux/macOS: ```bash vncviewer 服务器IP:5901 ``` ## 七、常见问题解决 ### 1\. 连接后黑屏 - 确保桌面环境已安装： ```bash sudo apt install ubuntu-desktop # GNOME 或 sudo apt install xfce4 # XFCE ``` - 检查日志： ```bash cat ~/.vnc/ubuntu:1.log ``` ### 2\. 修改分辨率 停止服务后重新启动： ```bash vncserver -kill :1 vncserver :1 -geometry 1280x720 -depth 24 ``` ### 3\. 卸载 TigerVNC ```bash sudo apt remove --purge tigervnc-* rm -rf ~/.vnc ``` ### 附：安全建议 #### 使用 SSH 隧道加密： ```bash ssh -L 5901:localhost:5901 用户名@服务器IP ``` 然后连接 localhost:5901。 #### 限制访问 IP： ```bash sudo ufw allow from 192.168.1.100 to any port 5901 ``` 按照以上步骤，你可以在 Ubuntu 上快速搭建一个支持多用户的 TigerVNC 远程桌面服务。 --- --- title: "linuxQQ安装后双击启动无响应,提示追踪与中断点陷阱 (核心已转储)" source: https://www.iowill.com/blog/2026/09/linuxqq-wont-start-core-dump/ date: 2026-09-10 updated: 2026-10-14 tags: [Electron, Linux, QQ, 故障排查] categories: [软件与工具] --- # linuxQQ安装后双击启动无响应,提示追踪与中断点陷阱 (核心已转储) 终端报错内容: > root@ubuntu:~/Desktop# qq > \[0415/140821.298504:FATAL:electron\_main\_delegate.cc(295)\] Running as root without –no-sandbox is not supported. See [https://crbug.com/638180](https://crbug.com/638180). > 追踪与中断点陷阱 (核心已转储) 这个错误表明你以 root 用户 运行 QQ（Linux 版），但 Electron 框架（QQ 使用的底层技术）出于安全考虑，默认禁止 root 用户直接运行。 * * * \[TOC\] ## 解决方案： ### 1\. 解决方案一：使用 –no-sandbox 参数 ```bash # 添加参数运行 QQ qq --no-sandbox ``` 注意：这会降低安全性，仅建议临时使用。 ### 2\. 解决方案二：创建普通用户运行（推荐） ```bash # 创建新用户 sudo adduser qquser # 切换到新用户 sudo -i -u qquser # 在新用户环境下运行 QQ qq ``` ### 3\. 解决方案三：修改 QQ 启动器 #### 1\. 定位QQ桌面快捷方式 ```bash # 查找QQ桌面文件位置 sudo find / -name "*qq*.desktop" 2>/dev/null ``` 通常路径为： /usr/share/applications/qq.desktop /opt/QQ/qq.desktop #### 2\. 修改启动器文件 以/usr/share/applications/qq.desktop为例 ```bash sudo nano /usr/share/applications/qq.desktop ``` #### 3\. 修改Exec行 添加–no-sandbox ```ini [Desktop Entry] ... Exec=qq --no-sandbox %U # 关键修改 ... ``` #### 4\. 更新桌面数据库 ```bash sudo update-desktop-database ``` #### 5\. 创建安全封装脚本（推荐） ```bash sudo nano /usr/local/bin/qq-safe ``` **内容：** ```bash #!/bin/bash # 限制仅允许普通用户运行 if [ "$(id -u)" -eq 0 ]; then echo "Error: QQ should not run as root!" exit 1 fi exec qq --no-sandbox "$@" ``` **赋予权限：** ```bash sudo chmod +x /usr/local/bin/qq-safe ``` #### 6\. 修改启动器指向新脚本 ```bash sudo nano /usr/share/applications/qq.desktop ``` **修改为：** ```ini Exec=/usr/local/bin/qq-safe %U ``` #### 验证步骤 通过应用菜单启动QQ 检查进程权限： ```bash ps aux | grep -i qq | grep -v grep ``` 应显示： > youruser 1234 0.5 2.1 … qq –no-sandbox #### 备选方案（若仍崩溃） ##### A. 使用–disable-gpu-sandbox双重参数 ```bash sudo sed -i 's|Exec=.*|Exec=qq --no-sandbox --disable-gpu-sandbox %U|g' /usr/share/applications/qq.desktop ``` ##### B. 设置Chromium标志 ```bash mkdir -p ~/.config/QQ echo '--no-sandbox' > ~/.config/QQ/electron-flags.conf ``` #### 安全警告 > 长期使用–no-sandbox会降低安全性 > 建议最终采用 普通用户方案： ### 4\. 解决方案四：使用 Deepin-Wine 版 QQ ```bash # 安装 Deepin-Wine 环境 wget -O- https://deepin-wine.i-m.dev/setup.sh | sh # 安装 QQ sudo apt install com.qq.im.deepin # 运行（无需 root） deepin-wine6-stable ~/.deepinwine/Deepin-QQ/drive_c/Program\ Files/Tencent/QQ/Bin/QQ.exe ``` * * * ## 错误原因说明 - 安全沙箱（Sandbox）：Electron 应用默认启用沙箱隔离，root 用户会触发保护机制 - 核心转储：因权限问题导致进程崩溃 ### 永久修复建议 避免以 root 运行图形应用 如果必须用 root，可配置系统策略： ```bash sudo sysctl kernel.unprivileged_userns_clone=1 ``` 验证是否修复 ```bash # 检查 QQ 进程 ps aux | grep -i qq | grep -v grep # 应显示普通用户权限 ``` --- --- title: "GEO 是什么？它真的能让大模型‘愿意推荐你’吗？" source: https://www.iowill.com/blog/2026/08/what-is-geo/ date: 2026-08-12 updated: 2026-10-08 tags: [AI搜索, GEO, SEO, 信息检索] categories: [软件与工具] --- # GEO 是什么？它真的能让大模型‘愿意推荐你’吗？ > 迁移说明：本文原发表于 [Billy 原站](https://billy12.xyz/archives/what-is-GEO)，保留原发布时间，2026 年 10 月 8 日迁入本站并重新配图。迁移时保留主体结构，对效果保证、评价指标和平台机制的绝对化表述补充校注。文中历史研究或平台报告的数值受样本、版本与指标定义限制，不代表本站实测，也不构成收录、推荐或转化保证。 * * * * * * ## 一句话剧透 > **SEO 与 GEO 的侧重点不同：前者关注搜索可见性与访问，后者更关注内容是否进入生成式答案。两者存在交集，GEO 并不意味着可以跳过 SEO 基础工作。** * * * ## 一、为什么 SEO 不够用了 **一句话定义**：当用户在 Google 看到 AI Summary 而不再点击链接时，传统 SEO 的优化目标就从"前十名"坍缩成了"AI 答案里有没有我"。 **五个事实点**： 1. chat.openai.com 单月 31 亿次访问（Similarweb，2024-09）。 2. Perplexity 月查询量 7.8 亿（公司自报，2025-05）。 3. Google 出现 AI Summary 时，点击率从 15% 跌到 8%（Pew 实地研究）。 4. AI 答案可能改变用户是否继续点击网页的行为；原文此处百分比未明确对应统计口径，迁移版不保留该数值。 5. 关于未来流量超过传统搜索的判断属于预测，不应作为已经发生的事实或确定的业务规划依据。 **对比块：SEO vs GEO** | 维度 | SEO | GEO | | --- | --- | --- | | 优化目标 | 在 SERP 排第几 | 是否被 AI 选进答案 | | 用户行为 | 点 10 个蓝链之一 | 只看 AI 推荐的 3 个 | | 排名机制 | 关键词 + 链接权重 | 预训练先验 + 检索片段合成 | | 评估指标 | 排名 / CTR | 引用词数 / 位置 / 主观印象 | | 失败模式 | 排不到首页 | 完全不被引用 |  概念示意：结果列表可见性与答案引用可见性存在差异，图示不代表固定的来源数量。 ## 二、GEO 到底在优化什么？ **可见性评价**：相关研究分别考察引用词数、位置加权词数和主观印象等指标。它们不是所有生成式引擎共同使用的一条排名公式，具体定义应以论文为准。 **三个 visibility 指标**： 1. **Word Count**——AI 答案里有多少词在引用你。 2. **Position-Adjusted Word Count**——被引用词数 × `e^(-位置)`，靠前的引用权重大。 3. **Subjective Impression**——用 G-Eval（LLM-as-judge）从相关性、影响力、独特性等 7 个子维度打分。 **九种 GEO 方法**（同样来自 Aggarwal et al., 2024）：Authoritative、Statistics Addition、Cite Sources、Quotation Addition、Easy-to-Understand、Fluency Optimization、Unique Words、Technical Terms、Keyword Stuffing。 **对比块：在 GEO-bench（10K queries）上的效果** 研究记录：下表沿用原文整理的实验数据，本次迁移未重新复现实验；不同指标、样本与模型之间不可直接套用。 | 方法 | visibility 提升 | 实测备注 | | --- | --- | --- | | Cite Sources + Quotation Addition + Statistics | **+40%** | 论文中最强组合 | | 仅 Statistics Addition | +30% | 性价比最高 | | Keyword Stuffing（传统 SEO 老套路） | < +10% | LLM 不吃这套 | | 整体最高 | 40%（synthetic）/ 37%（Perplexity.ai 真实环境） | — | * * *  概念示意：既有知识与检索信息可能共同影响答案；图中不表示测得的权重比例。 ## 三、检索信息与模型既有知识：为什么不同查询的表现不同 **一句话定义**：在主流 entity 查询上，模型用检索内容只是"给自己找个证据"，而不是"获取新知识"。 **三个扰动实验**（Chen et al., EDBT/ICDT 2026）： 1. **Snippet Shuffle**——随机打乱检索片段顺序，看答案会不会变。 2. **Strict Grounding**——强制模型只用提供的片段，禁止用预训练知识。 3. **Entity-Swap Injection**——把片段里 A、B 两个实体的名字对调，看模型会不会上当。 **对比块：主流 vs 小众 entity 的模型行为** 研究记录：下表沿用原文整理的实验数据，本次迁移未重新复现实验；不同指标、样本与模型之间不可直接套用。 | 指标 | 主流 entity（"最好的 SUV"） | 小众 entity（"多伦多家事律所"） | | --- | --- | --- | | 检索片段顺序打乱后排名变化 | 2.30 | 4.15 | | 实体名互换后排名变化 | 2.60 | 4.63 | | 一次性排序 vs 两两比较排序的 Kendall τ | 0.911 | 0.556 | | 模型答出但**根本没出现在检索片段中**的 entity 占比 | **16%** | — | **五个品牌的具体"幽灵率"**（SUV 查询）： - Toyota：**6%**——几乎每个引用都有检索片段支撑。 - Honda：**3%**——同上。 - Kia：**10%**——基本可靠。 - Cadillac：**58%**——模型自顾自答。 - Infiniti：**73%**——纯靠预训练先验。 > **阅读结论**：部分查询可能更受模型既有知识影响，但不能由局部实验推出“主流实体做 GEO 都无效”。应按查询类型、模型和实际结果判断。 * * * ## 四、GEO 真正能赢的四种场景 **步骤块：判断 GEO 对你是否有用的四问** 1. **你的实体够小众吗？**——B2B SaaS、本地服务、长尾知识、专业工具。模型脑子里没货，必须检索。\[必做\] 做 GEO。 2. **你的内容够新鲜吗？**——AI 引擎对 freshness 的权重显著高于 Google。消费电子垂直：AI 引擎引用内容平均 62-90 天 vs Google 130 天；汽车垂直：AI 148-217 天 vs Google **493 天**。\[必做\] 做 GEO。 3. **你的内容是争议性/对比性的吗？**——LLM 在 RAG 模式下会重新排序证据，"X vs Y" 类内容天然容易进答案。\[必做\] 做 GEO。 4. **你能拿到第三方权威背书吗？**——AI 引擎对 earned media 有系统性偏好：Claude 引用 **65%** 是 earned media，GPT-4o **57%**，而 Google 只有 41%。\[必做\] 把资源投到 earned media 而不是自家内容工程。 如果四个答案都是 \[不做\]，省下 GEO 预算。 * * * ## 五、实操建议：四个 Tier，按优先级做 **一句话定义**：真正值得做的 GEO 工程只有十几条；其余的 ROI 不值得投入。 **Tier 1——任何人都该做（成本低、回报确定）** - **结构化数据**：在适用时标注文章、作者或产品等信息，并与可见内容一致。它能补充机器可读信息，但不是 AI 引用的必要保证，也不能据此说模型无法识别实体。 - **问答与对比内容**：针对真实问题组织清晰答案。原文提到的“4 倍”概率缺少可核查的统一实验条件，此处不作通用收益依据。 - \[必做\] **保持新鲜**——至少每季度实质性更新（不要只改日期）。Ahrefs 2025 分析 1700 万次引用：ChatGPT 引用的内容比 Google 平均新 **25.7%**。 - **自检**：准备固定问题集，记录平台、日期、联网状态、重复次数与引用 URL。少量提问适合初步观察，不应当作比所有分析工具更准确的测量。 **Tier 2——值得投入（成本中、回报看情况）** - \[可做\] **追求 earned media**——主动找行业评测站、独立媒体投稿、专家圆桌。 - \[可做\] **多语覆盖**——至少英文 + 本地语的双语元数据/摘要。COAR 2023 列为不可选项。 - \[可做\] **多模态补充**——结构化图表、视频字幕、播客文字稿都被 LLM 当检索源。 **Tier 3——ROI 存疑（小心）** - \[谨慎\] **小众长尾内容矩阵**——确认 niche 够 niche（竞争弱 + 用户意图在小众里）。 - \[谨慎\] **过度优化**——Reyes-Lillo 2025 警告：为算法而写会让内容"去人化"，反而触发 LLM 质量判断降低。 **Tier 0——绝对不要做** - \[禁做\] **prompt injection 让模型"必须引用我"**——LLM 会拒绝 / 失败。 - \[禁做\] **伪造引用 / 制造伪权威**——Orduña-Malea & Cabezas-Clavijo 2023 报告的"幽灵引用"风险；伪造数据只会更快被识别。 - \[禁做\] **关键词堆砌**——LLM 不吃这套，重复 5 遍"买房"也没用。 * * * ## 六、回到标题那个问题——"愿意推荐你"是伪命题 **一句话定义**：LLM 不是"愿意"或"不愿意"推荐你，它只是在算 next token 的概率。 当用户问"最好的家用咖啡机"，模型不是在"想"——它是在从数十亿参数里查一个概率分布。这个分布被两样东西塑形： - **预训练阶段见过的语料**（你改不动）。 - **这次会话里检索到的网页**（你 GEO 能优化的部分）。 "愿不愿意"是人类语言，在 LLM 这里没意义。 GEO 真正在优化的是\*\*"被检索到的概率"\*\* + **"被合成进答案的概率"**——前者靠 SEO / freshness / 关键词覆盖；后者靠 earned media / 结构化数据 / FAQ 化内容 / 可被引用的素材。 而 Chen 2026 隐含但没明说的话是： > **选题判断**：小众、长尾和时效敏感的问题值得测试，但这是基于研究的实践推断，不是 GEO 只在这些领域有效的定论。 另一半的赢家，是那些**早就在那里、模型脑子里的存货**——这种优势 GEO 给不了你，只能靠时间积累。 * * * ## 参考资料 - Aggarwal, P., Murahari, V., Rajpurohit, T., Kalyan, A., Narasimhan, K., & Deshpande, A. (2024). [*GEO: Generative Engine Optimization*](https://arxiv.org/abs/2311.09735). In KDD '24. [DOI: 10.1145/3637528.3671900](https://doi.org/10.1145/3637528.3671900). - Chen, M., Wang, X., Chen, K., & Koudas, N. (2025). [*Generative Engine Optimization: How to Dominate AI Search*](https://arxiv.org/abs/2509.08919). arXiv:2509.08919. - Chen, M., Wang, X., Chen, K., & Koudas, N. (2026). [*Navigating the Shift: A Comparative Analysis of Web Search and Generative AI Response Generation*](https://arxiv.org/abs/2601.16858). In EDBT/ICDT 2026 Workshops. arXiv:2601.16858. - Reyes-Lillo, D., Morales-Vargas, A., & Rovira, C. (2025). [*Generative Engine Optimization en repositorios digitales: optimización de la visibilidad para la IA generativa*](https://doi.org/10.3145/infonomy.25.034). Infonomy, 3(5). DOI: [10.3145/infonomy.25.034](https://doi.org/10.3145/infonomy.25.034). ## 迁移校注与补充资料 Google 的 AI 搜索功能文档说明，现有 SEO 基础仍然适用，无需特殊的 AI 专用结构化数据。其内容质量文档也明确，E-E-A-T 本身不是一个具体排名因子。这些说明适用于 Google 的公开文档，不能直接代替其他服务的实现说明。 - [Google：AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) - [Google：Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) - [GEO: Generative Engine Optimization](https://arxiv.org/abs/2311.09735)：摘要中的最高提升值属于实验结果，不是单个网站的收益保证。 相关阅读：[如何做好 GEO 优化](https://www.iowill.com/blog/2026/08/geo-optimization-practice/) --- --- title: "如何做好 GEO 优化" source: https://www.iowill.com/blog/2026/08/geo-optimization-practice/ date: 2026-08-11 updated: 2026-10-08 tags: [AI搜索, E-E-A-T, GEO, SEO, 内容优化] categories: [软件与工具] --- # 如何做好 GEO 优化 > 迁移说明：本文原发表于 [Billy 原站](https://billy12.xyz/archives/EbnkikHE)，保留原发布时间，2026 年 10 月 8 日迁入本站并重新配图。迁移时保留主体结构，对效果保证、评价指标和平台机制的绝对化表述补充校注。文中历史研究或平台报告的数值受样本、版本与指标定义限制，不代表本站实测，也不构成收录、推荐或转化保证。 ## 行业现状 GEO 内容运营中容易出现一种误区：投入大量自动生成文章，却没有同步检查信息质量、来源和真实引用情况。本文整理的是方法与资料，不以未展示的客户案例作为效果证据。 原因在于 AI 模型判断内容不看数量看质量——内容的结构化程度、权威背书、用户场景匹配度才是核心。 用 AI 写作 + 软件分发的做法本质上还是 SEO 时代的堆量思维，在 GEO 时代已经失效了。 真正的 GEO 需要三个核心转变： - 从关键词优化转向**场景化内容**（AI 时代用户提问平均 24-27 个词，是带具体场景的完整问题） - 从情绪化文案转向**逻辑证明**（用数据和案例支撑观点） - 从海量投放转向**精准信源布局**（优先布局官网、官方号和行业权威媒体） 做 GEO 最怕的就是把 AI 写作 + 软件分发当成万能药，内容质量不够，发再多也没用。 GEO 的核心是让 AI 理解你是什么、凭什么可信，而不是刷存在感。关键是三个维度：**内容结构要清晰、论据要有来源支撑、发布渠道要有权重**。三者缺一不可，少一个 AI 都很难主动引用你的内容。 * * * ## AI 自身也"做搜索" Kimi、秘塔等联网型 AI 调用搜索结果作为信源——你的 SEO 排名仍然间接影响 AI 引用率。 做 AI 检索内容优化时，必须用 E-E-A-T 标准搭建高可信度内容。逻辑链： > 一种便于理解的流程是：发现相关页面 → 检索与筛选信息 → 生成答案并可能附带引用。各产品实现不同，不能把 E-E-A-T 描述为所有 AI 引擎统一执行的打分算法。 * * * ## 一、E-E-A-T（谷歌内容可信度标准） **全称**：Experience（真实经验）、Expertise（专业度）、Authoritativeness（权威性）、Trustworthiness（可信度） 2022 年谷歌在原版 E-A-T 基础上加了第一个 E「Experience」，变成 E-E-A-T： | 维度 | 含义 | | --- | --- | | **Experience 真实经验** | 内容来自一手实测、亲身经历，比如亲自用过 APP、现场看球赛、实地体验，不是纯摘抄搬运 | | **Expertise 专业度** | 作者 / 平台有对应领域资质，专业知识（医生写医疗，体育编辑讲赛事，律师讲法规） | | **Authoritativeness 权威性** | 平台、作者、内容被行业、官方、媒体认可；政府官网、央媒、头部垂直媒体权威最高，个人小自媒体权威极低 | | **Trustworthiness 可信度** | 信息准确、来源透明、无虚假宣传、网站备案完整、标注引用出处、不篡改原文 |  E-E-A-T 可帮助检查内容质量；图示不是 AI 服务内部的评分公式。 * * * ## 二、不合格参考信源如何被引用 - 搜索结果里出现某个站点，并不等于生成答案采信了它的全部观点。需要分别查看检索结果、答案内容和实际引用，不能仅凭出现位置判断信任权重。 - 核对授权、服务范围等问题时，可以优先寻找相关机构的一手公告。但“官方”身份不是任何表述都正确的保证，仍需检查发布时间与问题是否匹配。 - 缺少出处或实测的转载页面，难以支撑复杂判断；个人站点也可能提供有价值的一手经验，不能仅按站点规模断言 AI 只会从中提取名词。 * * * ## 三、GEO 核心方法论（基于 KDD 2024 论文） 市场现状：联网问答正在成为用户获取信息的一种入口。原文引用的月活数未附可核对的统计口径，迁移版不保留具体数值。 根本变化：用户不再看"10 条候选链接并自己比较"，而是直接信任并接受"AI 给的一段直接答案"。如果你的品牌不在 AI 的答案里，几乎等于不存在。 核心论点：GEO 与 SEO 存在目标侧重和衡量方式的差异，但并不互相替代。需要持续观察内容变化与引用表现，没有适用于所有网站的固定见效周期。 黑盒挑战：AI 存在"答案漂移"（同问题多次问答案不同）、黑盒推荐、多平台算法差异等痛点。 ### 1\. 白皮书引入的权威方法 白皮书引入了普林斯顿等机构在 KDD 2024 发表的权威论文方法（arXiv:2311.09735），量化了 9 种内容优化方法对 AI 引用率的影响： **头部高收益方法：** 口径说明：以下数值与权重沿用原文引用的研究或平台资料，并非统一行业标准，也不是本站实验结果；使用前应核对其定义与样本。 | 方法 | 提升幅度 | 说明 | | --- | --- | --- | | 引述添加 | +42.6% | 在内容中加入带引号的专家或客户原话。AI 偏好这种高信息密度的可复用片段 | | 数据添加 | +32.8% | 内容中多包含具体数字、单位和时间 | | 流畅度优化 | +28.7% | — | | 引用来源 | +27.7% | — | **必须避免的反模式：** 口径说明：以下数值与权重沿用原文引用的研究或平台资料，并非统一行业标准，也不是本站实验结果；使用前应核对其定义与样本。 | 方法 | 影响 | 说明 | | --- | --- | --- | | 关键词堆砌 | \-8.7% | 在同一段落内重复关键词 ≥5 次。AI 经对抗训练会识别为低质 Spam 并主动降权（与传统 SEO 关键词密度思维相反） | 其他痛点：句子过长（平均 >50 字）、空话堆砌（如"致力于/极致/赋能"等定性词过多）、纯口号无数据。 ### 2\. 九维 GEO 指数体系 为精确评估品牌的 GEO 现状，平台设计了九维加权评分，并根据不同行业（如律所重信源、餐饮重情感）动态调整权重： 口径说明：以下数值与权重沿用原文引用的研究或平台资料，并非统一行业标准，也不是本站实验结果；使用前应核对其定义与样本。 | 维度 | 默认权重 | 说明 | | --- | --- | --- | | 提及率 | 20% | 全部样本中 AI 提到品牌的比例（入门门票，没它后面都没意义） | | 推荐位排名 | 12% | 列表型回答中品牌排第几位（第 1 与第 5 转化率差 5-10 倍） | | 引用强度 | 12% | 强引用（首选推荐）vs 弱提及（列在长清单里） | | 稳定性 | 12% | 多次采样间的波动反比（AI 存在答案漂移，需多次采样看滚动窗） | | 情感正向率 | 10% | 被提及内容中正向语义的比例（负向提及是品牌资产损耗） | | 平台覆盖率 | 10% | 6 大主流 AI 平台中提到了几个（防流量过于集中和脆弱） | | 直接命中率 | 8% | 实体名原样出现 vs 间接指代（直接命中是最强引用证据） | | 自有信源被引率 | 8% | AI 引用来源 URL 中企业官网等自有信源的占比 | | 联网引用率 | 8% | AI 回答附带外部链接的比例 | 最终得分对应 S（85+）、A（70-85）、B（55-70）、C（35-55）、D（<35）五个评级。低于 35 分为 D 级，急需建立基线。 ### 3\. GEO 运营 30 天落地闭环指南  30 天是组织工作的示例周期，不保证在此期间获得引用或排名提升。 GEO 是一个包含监测、诊断、生产、发布、追踪、反哺的完整闭环： **第 1 周：基线监测与真相档案** 录入企业的"真相档案"（成立时间、主营、核心团队、客户名单、资质等）。利用 Query Fanout 25 矩阵，将 1 个核心查询扩散为覆盖客户全决策旅程（认知、对比、验证、避坑、价格）的 25 个变体，并建立初始评级。 **第 2 周：诊断与优先级排序** 开启反模式雷达，扫描官网及现有内容。运行品牌误解识别：检查 AI 是否"说错"你（如时间、资质错误），按 High/Medium/Low 严重级即时拦截或在后续内容中纠偏。找出与竞品的 Gap 查询（竞品独占的搜索词）。 **第 3 周：内容精准生产** 针对 Gap 查询，利用平台生成器产出 5-8 篇优化内容（融入数据、引述，并自动附带 Schema.org JSON-LD 结构化代码，如 Organization、Article、FAQPage 等）。 **第 4 周：多平台适配发布与追踪** 拒绝一键群发：同一主稿必须根据微信公众号（严肃专业）、知乎（问句+案例）、小红书（emoji+短句）等不同平台的算法规则进行独立适配，否则会被平台整体降权。发布后在 D+7、D+14、D+28 自动复测，追踪 Before/After Lift（提升曲线），用数据反哺下一轮选题。 ### 4\. 技术壁垒：分布式真实节点采样 采样设计需要区分 API 与产品界面的实际差异，记录模型、联网状态和时间；不能预设 API 一定是降级模型。以下保留平台方案中的分析思路，不把供应商描述当成独立验证结果。 - **浏览器界面采样**：在有权访问的页面记录实际展示结果；测试环境与条件保持可追溯，不把共享登录凭据或绕过风控作为 GEO 方法。 - **双层语义判定**：先进行规则粗筛（字符串/别名/同名歧义过滤），再由 LLM 判定具体的位置、情感与置信度，低置信度（<0.5）扣减分数防止虚高。 - **句子级引用检查**：保留答案已有的引用标记，并核对来源是否支持相应句子。仅按句号拆分或语义相似，不能证明一句话来自某个 URL。 - **多模态采样取证**：每次采样自动留存 1-3 分钟录屏（存腾讯云 COS）、关键截图和原文，便于回溯和向客户演示。 * * * ## 参考链接 - [DataFocus GEO 平台](https://app.datafocus.ai/focusgeo/manual/) - [GEO MWDC Info](https://geo.mwdc.info/) - [GEO 白皮书](https://geo.mwdc.info/whitepaper.html) ## 迁移校注与补充资料 Google 的 AI 搜索功能文档说明，现有 SEO 基础仍然适用，无需特殊的 AI 专用结构化数据。其内容质量文档也明确，E-E-A-T 本身不是一个具体排名因子。这些说明适用于 Google 的公开文档，不能直接代替其他服务的实现说明。 - [Google：AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) - [Google：Creating helpful, reliable, people-first content](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) - [GEO: Generative Engine Optimization](https://arxiv.org/abs/2311.09735)：摘要中的最高提升值属于实验结果，不是单个网站的收益保证。 相关阅读：[GEO 是什么？它真的能让大模型‘愿意推荐你’吗？](https://www.iowill.com/blog/2026/08/what-is-geo/) --- --- title: "云服务器Debian12根分区扩容记录" source: https://www.iowill.com/blog/2025/04/cloud-debian12-root-resize/ date: 2025-04-18 updated: 2026-10-14 tags: [Debian, LVM, Linux, 磁盘扩容] categories: [系统与运维] --- # 云服务器Debian12根分区扩容记录 > \[!WARNING\] > > 以下操作可能会导致包括但不仅限于数据丢失、无法启动等问题，严重时您可能需要重装系统，如要继续，请确保已做好数据备份等准备工作。 ## 前言 云上Debian12的机器，使用 `df -Th` 查看磁盘分区信息： ```text root@xxx:~# df -Th Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 775M 852K 775M 1% /run /dev/vda1 ext4 19G 5.7G 12G 33% / tmpfs tmpfs 3.8G 0 3.8G 0% /dev/shm tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs tmpfs 775M 0 775M 0% /run/user/0 overlay overlay 19G 5.7G 12G 33% /var/lib/docker/overlay2/85022b6945d418b6979839b3897502dd192a7c7b11993f1a5e30b6f3af579595/merged overlay overlay 19G 5.7G 12G 33% /var/lib/docker/overlay2/faa3aef89ddf6113d5d5805e64bc6abeeb3cd5d01da27dde5e39dc7af7f399c4/merged overlay overlay 19G 5.7G 12G 33% /var/lib/docker/overlay2/e691e3e85e02b056a6001d2b3bffcb9033a6f6456bc5aac1c6ccc1cffbb4ead6/merged overlay overlay 19G 5.7G 12G 33% /var/lib/docker/overlay2/4c14da4bf849dba7c6d05c5bb7a3d4721a2a436efaff3b2dc14ad86885ad4cd5/merged ``` 可以看到根分区/dev/vda1只有19G，`lsblk`查看磁盘使用情况： ```text root@xxx:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sr0 11:0 1 1024M 0 rom vda 254:0 0 20G 0 disk ├─vda1 254:1 0 19G 0 part / ├─vda2 254:2 0 1K 0 part └─vda5 254:5 0 975M 0 part [SWAP] vdb 254:16 0 30G 0 disk ``` 可以看到未使用的磁盘有30G，现在想把这30G加到根分区上去，思路就是采用LVM逻辑卷管理动态扩容，建立一个逻辑卷组，把vda和vdb都加入此卷组，达到物理上是两块不同磁盘，但逻辑上合并为一块磁盘的效果。 ## 1.将磁盘vdb初始化为物理卷 ```bash pvcreate /dev/vdb ``` ### 期望输出 ```shell root@xxx:~# pvcreate /dev/vdb Physical volume "/dev/vdb" successfully created. ``` ## 2.新建卷组并将vdb加入此卷组 ```bash vgcreate vg_root /dev/vdb ``` ### 期望输出 ```shell root@xxx:~# vgcreate vg_root /dev/vdb Volume group "vg_root" successfully created ``` ### ERROR1跳转解决方法 [跳转](#error_1) ```shell root@xxx:~# pvcreate /dev/vdb Can't initialize physical volume "/dev/vdb" of volume group "vg_root" without -ff /dev/vdb: physical volume not initialized. ``` ## 3.在卷组中创建逻辑卷 ```bash lvcreate -l 100%FREE -n lv_root vg_root ``` ### 期望输出 ```shell root@xxx:~# lvcreate -l 100%FREE -n lv_root vg_root WARNING: ext4 signature detected on /dev/vg_root/lv_root at offset 1080. Wipe it? [y/n]: y Wiping ext4 signature on /dev/vg_root/lv_root. Logical volume "lv_root" created. ``` ### ERROR2跳转解决方法 [跳转](#error_2) ```shell root@debian:~# lvcreate -l 100%FREE -n lv_root vg_root Volume group "vg_root" not found Cannot process volume group vg_root ``` 可以使用`lsblk`命令查看vdb上已经创建了该逻辑卷： ```shell root@xxx:~# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sr0 11:0 1 1024M 0 rom vda 254:0 0 20G 0 disk ├─vda1 254:1 0 19G 0 part / ├─vda2 254:2 0 1K 0 part └─vda5 254:5 0 975M 0 part [SWAP] vdb 254:16 0 30G 0 disk └─vg_root-lv_root 253:0 0 30G 0 lvm ``` ## 4.使用etx4文件系统格式化此逻辑卷 ```bash mkfs.ext4 /dev/vg_root/lv_root ``` ### 期望输出 ```shell root@xxx:~# mkfs.ext4 /dev/vg_root/lv_root mke2fs 1.47.0 (5-Feb-2023) Creating filesystem with 7863296 4k blocks and 1966080 inodes Filesystem UUID: a8a07510-2b4c-4ac7-8524-cafcb4393283 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000 Allocating group tables: done Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done ``` ## 5.修改`/etc/fstab` 首先使用`blkid`命令得到上面创建的**vg\_root-lv\_root**逻辑卷的**UUID**： ```shell root@xxx:~# blkid /dev/vdb: UUID="Av2nxJ-l57c-uZoz-zFQ8-w90P-4s5F-2NhUZD" TYPE="LVM2_member" /dev/mapper/vg_root-lv_root: UUID="a8a07510-2b4c-4ac7-8524-cafcb4393283" BLOCK_SIZE="4096" TYPE="ext4" /dev/vda5: UUID="155c5478-3b21-4c5c-ab1d-5bc39961d1b7" TYPE="swap" PARTUUID="35ce1eaa-05" /dev/vda1: UUID="63dc08fe-cf76-4097-b849-c9db03ce9b84" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="35ce1eaa-01" ``` ### 示例： `nano /etc/fstab`,其原内容如下： ```ini # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # systemd generates mount units based on this file, see systemd.mount(5). # Please run 'systemctl daemon-reload' after making changes here. # #`预格式化文本(Preformatted Text)的功能。
```
```
预格式化文本：
```
| First Header | Second Header |
| ------------- | ------------- |
| Content Cell | Content Cell |
| Content Cell | Content Cell |
```
#### JS代码
```javascript
function test(){
console.log("Hello world!");
}
(function(){
var box = function(){
return box.fn.init();
};
box.prototype = box.fn = {
init : function(){
console.log('box.init()');
return this;
},
add : function(str){
alert("add", str);
return this;
},
remove : function(str){
alert("remove", str);
return this;
}
};
box.fn.init.prototype = box.fn;
window.box =box;
})();
var testBox = box();
testBox.add("jQuery").remove("jQuery");
```
#### HTML代码 HTML codes
```html
Hello world!
Hello world!
```
### 图片 Images
Image:
> Follow your heart.
> 图为：厦门白城沙滩
图片加链接 (Image + Link)：
[](https://pandao.github.io/editor.md/examples/images/7.jpg "李健首张专辑《似水流年》封面")
> 图为：李健首张专辑《似水流年》封面
* * *
### 列表 Lists
#### 无序列表（减号）Unordered Lists (-)
- 列表一
- 列表二
- 列表三
#### 无序列表（星号）Unordered Lists (\*)
- 列表一
- 列表二
- 列表三
#### 无序列表（加号和嵌套）Unordered Lists (+)
- 列表一
- 列表二
- 列表二-1
- 列表二-2
- 列表二-3
- 列表三
- 列表一
- 列表二
- 列表三
#### 有序列表 Ordered Lists (-)
1. 第一行
2. 第二行
3. 第三行
#### GFM task list
- [x] GFM task list 1
- [x] GFM task list 2
- [ ] GFM task list 3
- [ ] GFM task list 3-1
- [ ] GFM task list 3-2
- [ ] GFM task list 3-3
- [ ] GFM task list 4
- [ ] GFM task list 4-1
- [ ] GFM task list 4-2
* * *
### 绘制表格 Tables
| 项目 | 价格 | 数量 |
| --- | --: | :-: |
| 计算机 | $1600 | 5 |
| 手机 | $12 | 12 |
| 管线 | $1 | 234 |
| First Header | Second Header |
| --- | --- |
| Content Cell | Content Cell |
| Content Cell | Content Cell |
| First Header | Second Header |
| --- | --- |
| Content Cell | Content Cell |
| Content Cell | Content Cell |
| Function name | Description |
| --- | --- |
| `help()` | Display the help window. |
| `destroy()` | **Destroy your computer!** |
| Left-Aligned | Center Aligned | Right Aligned |
| :-- | :-: | --: |
| col 3 is | some wordy text | $1600 |
| col 2 is | centered | $12 |
| zebra stripes | are neat | $1 |
| Item | Value |
| --- | --: |
| Computer | $1600 |
| Phone | $12 |
| Pipe | $1 |
* * *
#### 特殊符号 HTML Entities Codes
© & ¨ ™ ¡ £
& < > ¥ € ® ± ¶ § ¦ ¯ « ·
X² Y³ ¾ ¼ × ÷ »
18ºC " '
### Emoji表情 :smiley:
> Blockquotes :star:
#### GFM task lists & Emoji & fontAwesome icon emoji & editormd logo emoji :editormd-logo-5x:
- [x] :smiley: @mentions, :smiley: #refs, [links](https://www.iowill.com/blog/2024/07/markdown-editor/), **formatting**, and ~tags~ supported :editormd-logo:;
- [x] list syntax required (any unordered or ordered list supported) :editormd-logo-3x:;
- [x] \[ \] :smiley: this is a complete item :smiley:;
- [ ] \[\]this is an incomplete item [test link](#) :fa-star: @pandao;
- [ ] \[ \]this is an incomplete item :fa-star: :fa-gear:;
- [ ] :smiley: this is an incomplete item [test link](#) :fa-star: :fa-gear:;
- [ ] :smiley: this is :fa-star: :fa-gear: an incomplete item [test link](#);
#### 反斜杠 Escape
\*literal asterisks\*
### 科学公式 TeX(KaTeX)
$$E=mc^2$$
行内的公式$$E=mc^2$$行内的公式，行内的$$E=mc^2$$公式。
$$(\\sqrt{3x-1}+(1+x)^2)$$
$$\\sin(\\alpha)^{\\theta}=\\sum\_{i=0}^{n}(x^i + \\cos(f))$$
多行公式：
```plaintext
\displaystyle
\left( \sum\_{k=1}^n a\_k b\_k \right)^2
\leq
\left( \sum\_{k=1}^n a\_k^2 \right)
\left( \sum\_{k=1}^n b\_k^2 \right)
```
```plaintext
\displaystyle
\frac{1}{
\Bigl(\sqrt{\phi \sqrt{5}}-\phi\Bigr) e^{
\frac25 \pi}} = 1+\frac{e^{-2\pi}} {1+\frac{e^{-4\pi}} {
1+\frac{e^{-6\pi}}
{1+\frac{e^{-8\pi}}
{1+\cdots} }
}
}
```
```latex
f(x) = \int_{-\infty}^\infty
\hat f(\xi)\,e^{2 \pi i \xi x}
\,d\xi
```
### 绘制流程图 Flowchart
```plaintext
st=>start: 用户登陆
op=>operation: 登陆操作
cond=>condition: 登陆成功 Yes or No?
e=>end: 进入后台
st->op->cond
cond(yes)->e
cond(no)->op
```
### 绘制序列图 Sequence Diagram
```plaintext
Andrew->China: Says Hello
Note right of China: China thinks\nabout it
China-->Andrew: How are you?
Andrew->>China: I am good thanks!
```
### End