2026-09-06 12:21:05
ChatGPT 有一个定时任务功能。以前它可能只能做一些获取网页、收集信息之类的事情，但最近我发现它还可以做一些更接近 Agent 的工作——除了获取网页，还能执行代码、提交代码到 GitHub。
这段时间，我一直让 ChatGPT 每天帮我整理 Hacker News 摘要。通过定时任务，它会在每天早上自动获取榜单前 30 的内容，逐一尝试访问，然后整理成中文摘要发给我，供我筛选阅读。时间久了，我又慢慢告诉它我感兴趣的方向：Arduino、ESP32、Raspberry Pi 相关的，LLM 和 Agent 相关的，学习和阅读相关的，写作和博客相关的。独立博客里的好文章，即便不属于这些分类，也希望单独推荐。它会在榜单逐条摘要下面，再单独列出我感兴趣的内容。
这个定时任务持续了一段时间，效果一直不错。但有一个越来越明显的问题：所有的摘要都堆在同一个 ChatGPT 对话里。对话越来越长，打开的时候越来越卡，想翻以前的内容也很不方便。
于是就有了一个想法：把这些内容做成一个可以正常浏览的网页，放在 GitHub Page 上？
这就有了 hn-digest。
https://emuqi.github.io/hn-digest/
这个网站并不是我一开始就规划好的。而是我在使用中慢慢的确定需求，逐步调整，一点点塑造出来的。
最开始，我的想法很简单：让 ChatGPT 每天直接生成一个网页。但我也意识到这样做长期维护不现实。模型每次输出的格式可能会漂移，结构不够稳定。
于是我想到静态网页生成器，我之前用过 Hexo、Jekyll、Sphinx、Docusaurus，对这类工具有一些了解。（不过事实上，即使不知道这些，ChatGPT 也能给你推荐。我刻意尝试了问它有没有什么建议，而不是直接要求用静态网页生成，它也能建议这种方案）。
接着，和 ChatGPT 讨论以后，确定了分工：ChatGPT 的定时任务只负责生成 Markdown 格式的日报内容，网站的模板和样式交给静态站点生成器来处理。在 ChatGPT 的推荐下，框架最终选了 Eleventy。这个框架我没用过，按它的说法，这个框架轻量、灵活，适合这种"日报+归档"的场景。
每天的摘要保存为 Markdown，提交到 GitHub 仓库，Eleventy 生成静态页面，通过 GitHub Pages 自动发布。技术方案本身没什么特别的，重要的是整个过程几乎都是和 ChatGPT 对话完成的。
第一版上线以后，页面能看但不好看。于是继续聊：配色调一下，排版改一改，导航加上归档和 RSS。第二版上去以后又发现 CSS 选择器写得太宽泛，把正文里的加粗文字全都当成了新闻标题来渲染，页面格式一片混乱。继续和 ChatGPT 排查，加上语义化的 class，加上资源文件的版本号强制刷新缓存，一点点修好。
用了一段时间，我发现在墨水屏设备上阅读效果不太好。我平时会在 BOOX Palma 2（一个墨水屏阅读器）上看这些摘要，但是在设计时没有考虑到这点。浅灰色的字体在墨水屏下几乎不可见，动画在墨水屏的刷新特性下也是累赘。所以我和 ChatGPT 讨论，做了一个墨水屏阅读模式：去掉动画和阴影，拉高灰阶对比度，单栏布局，加大点击区域。
我还让它优化了下翻页交互。在墨水屏上正常的上下滑动，由于刷新慢，看起来会有一种不舒服的感觉，刷新率低还会有拖影。于是，我们在这个网页上加上了大多数阅读器都有的功能：点屏幕左边向上翻一屏，点右边向下翻一屏。每次切换 88% 屏幕高度，保留一点上文作为视觉上下文，不用平滑滚动而是直接跳转，更适合墨水屏的刷新特性。
到这里，这个网站已经很符合我的需求了。更值得一提的是，即使后面需求变化，或者发现什么需要优化的地方，也能很快通过对话来迭代。
回头看仓库的提交记录，从最初的基本结构，到样式修复，到墨水屏适配，再到翻页交互，并不是一次设计好的，而是在实际使用中一点点调整磨合，与 AI 共创出来的。全程我甚至没有 clone 这个仓库，没有在本地编辑过。
我觉得这恰好是用 AI 做个人项目最有意思的地方：你不需要一开始就想清楚所有需求，可以先做一个最简单的版本，边用边改。而"改"这件事的成本，比以前低太多了。
前些年我了解到，有一个项目叫 hacker-news-digest，也就是我之前一直在用的Hacker News 摘要网站。它的思路是很典型的软件工程方式：自己写程序抓取 Hacker News，用机器学习提取网页正文，调用 OpenAI API 生成摘要，API 不可用时回退到本地 LLM 模型，再套模板部署到 GitHub Pages。开发者先搭好完整的流水线，LLM 只是其中的一个组件。
https://hackernews.betacat.io/
而我现在做的这个，方向其实反过来了：ChatGPT 完成所有的功能，不需要编写复杂的爬虫，也不需要再次接入 AI 来生成摘要。它负责抓取 Hacker News，根据我的兴趣筛选出值得关注的内容，撰写摘要并给出推荐理由，最后将结果同步至 GitHub 仓库的全流程。如今大家基本都订阅了 ChatGPT，即便每月 20 美元的计划也相当慷慨，足以支撑定时任务，并利用当前最前沿的模型来完成这些工作，为这类个人项目提供了实现的基础。
我三年前写过一篇文章，记录用 ChatGPT 做一个叫 PyPower 的局域网远程开关机工具。那时候的方式还是一个个问题地问 ChatGPT，自己手动把代码拼起来。到现在做 hn-digest，已经变成让 AI 直接承担整个内容生产和工作流了。
https://wulu.zone/posts/pypower-chagpt
hn-digest 当然谈不上什么工程级的项目。架构简单，没有数据库，生成过程完全依赖 ChatGPT，自动化偶尔也会出问题。但我现在每天早上真的会打开它看 Hacker News。对于一个只有我自己在用的个人项目来说，这就已经够了。
以前很多小想法会停在"做起来好像有点麻烦"。到现在越来越多时候会变成"要不先让 AI 帮我试试看"。这可能才是 AI 对普通人最有意思的地方，不是每个人突然都变成了软件工程师，而是很多以前没有太多精力专门投入时间去实现的小想法，现在值得动手试试了。
当然，有一些基础知识会让这个过程顺利很多：知道 Git 是什么，理解静态网站的基本原理，能看懂错误日志，会把一个大需求拆成小需求。但我觉得顺序在变，不一定要先学完这些才能动手，而是可以先做，遇到问题再去理解。如果想更系统地了解怎么和 AI 协作，我之前推荐过一个不错的课程，可以看看这篇文章。
https://wulu.zone/posts/ai-prompting-for-everyone
所以如果你最近有什么一直想做、但总觉得自己不会的小东西，不妨用 AI 试试看。
最后，附上我所用的定时任务提示词供大家参考。还要说明一点：不需要自己写这么周全的提示词，你只要和 ChatGPT 讨论你的需求，它会自己调整和完善提示词。试试制作一个属于自己的 hn-digest 吧，祝你开发顺利~
直接打开并读取 Hacker News 官方首页 https://news.ycombinator.com/ 的当前 HTML，获取首页排名 1–30。不要使用 /front、搜索引擎、搜索结果摘要、第三方镜像或缓存。生成前校验：最终页面 URL 必须仍是 https://news.ycombinator.com/，页面必须包含连续的 1–30 排名，并核对前 3 条标题与当前页面一致。结果标题格式为“Hacker News 热榜前 30 条｜YYYY 年 M 月 D 日”。用中文概括每条主要内容。
链接规则必须严格执行：
1. 每条的“原文链接”必须使用该条标题在 Hacker News 首页 HTML 中对应的精确 href，也就是实际文章、项目、论文、视频或产品页面；不得用 Hacker News 首页代替。
2. 每一条都必须同时附上该条自己的 Hacker News 讨论页链接，格式为 https://news.ycombinator.com/item?id=... 。HN 讨论链接是必选项，不能省略。
3. 对 Ask HN、Launch HN、招聘帖、纯文本帖或本身没有站外链接的条目，“原文链接”使用该条自己的精确讨论页链接；这种情况下“原文链接”和“HN 讨论”可以相同。
4. 即使原文页面无法抓取，也必须保留从 HN 首页提取到的精确原始 href，只能在摘要中注明无法读取全文；不得把链接替换成 HN 首页、网站根域名或模糊入口。
5. 生成前逐条检查 30 个“原文链接”和 30 个“HN 讨论”链接：不得出现用于占位的 HN 首页；不得把同一首页链接重复用于多条内容；不得只链接到媒体或网站根域名，除非 HN 条目本身的 href 就是该根域名。
【固定 Markdown 输出格式】
对话中的完整日报，以及写入 GitHub 的 Markdown 正文，都必须遵循以下固定结构。不要自行改写成其他列表风格。
Top 30 每条必须严格使用：
N. **与 Hacker News 首页完全一致的英文标题**
中文摘要。
[原文链接](精确原文URL) ｜ [HN 讨论](精确HN讨论URL)
要求：
- N 必须是连续的 1–30。
- 标题必须用 Markdown 粗体 `**标题**`，且文本与 HN 首页标题完全一致，不翻译、不改写、不追加中文说明。
- 每条标题必须是该条列表项中第一个粗体文本；不要在标题前放其他粗体内容。
- 摘要可以包含普通 Markdown 强调，但不要把其他内容伪装成条目标题。
- 原文链接和 HN 讨论必须位于该条末尾，使用固定文字“原文链接”和“HN 讨论”，两者之间使用全角分隔符 `｜`。
- 不要在 Top 30 条目之间插入额外二级/三级标题、表格、HTML、引用块或其他结构。
完整列出前 30 条后，再增加：
## 重点分类
并固定使用以下五个三级标题，顺序不得改变：
### Arduino / ESP32 / Raspberry Pi
### LLM / Agent
### 学习与阅读
### 写作与博客
### 独立博客精选
重点分类中的“相关条目”必须严格使用以下格式：
- **N｜与 Top 30 完全一致的英文标题**：中文简要说明。
重点分类格式规则：
- N 必须是该条在 Top 30 中的真实排名编号，用阿拉伯数字，不补零。
- `N｜标题` 中必须使用全角分隔符 `｜`。
- 标题文本必须与 Top 30 对应条目的英文标题完全一致，不翻译、不缩写、不改写。
- 分类项本身不要重复手写“原文链接”或“HN 讨论”链接；网站构建层会根据 N 自动关联 Top 30，生成回跳、原文和 HN 讨论入口。
- 同一条可以同时出现在多个分类中，不要为了避免重复而漏掉重要条目。
- 若某分类没有相关条目，在该三级标题下只写一句自然语言，例如“没有直接相关条目。”，不要编造占位条目，不要使用 `N｜标题` 格式。
重点分类筛选规则：
- Arduino / ESP32 / Raspberry Pi：筛选相关硬件、开发板、生态、嵌入式项目；若没有，明确说明。
- LLM / Agent：包括大语言模型、推理模型、开放权重模型、模型训练/推理/评测、Agent/Coding Agent、模型路由、上下文工程、LLM 基础设施与安全等；若没有，明确说明。
- 学习与阅读：包括高质量教程、课程、书籍、论文、学习方法、知识管理、阅读与写作方法、适合系统学习的技术资料等；若没有，明确说明。
- 写作与博客：包括写作方法、博客实践、技术写作、个人博客/独立出版、内容创作、知识表达、长期写作、写作工作流，以及关于如何通过写作促进学习和思考的内容；若没有，明确说明。
- 独立博客精选：主动从前 30 条中筛选值得阅读的独立博客文章，即使主题本身并非“写作/博客”。优先个人独立站点、个人技术博客、个人研究/工程复盘、长期维护的独立博客、个人观点长文和高质量个人随笔；一般不把大型媒体、公司官方博客、产品公告、新闻站点归入此类。每条简要说明为什么值得读；若没有，明确说明。
若无法直接读取官方首页，或者 1–30、链接等关键校验失败，只能说明本次抓取/校验失败和具体失败点，不得使用旧榜单、缓存内容或猜测内容，也不得发布不完整日报。
【GitHub 发布】
在上述完整日报已经生成并通过全部校验后，将同一份日报发布到 GitHub 仓库 eMUQI/hn-digest 的 main 分支。对话中的完整日报输出必须始终保留：GitHub 发布是额外步骤，不能用“已发布到 GitHub”代替聊天中的 30 条正文和重点分类，也不能为了发布而缩短聊天输出。
发布约束：
1. 只允许创建当天一个 Markdown 文件：content/daily/YYYY/MM/DD.md。YYYY/MM/DD 使用 Asia/Shanghai 当天日期，月份和日期均为两位数字。
2. 禁止修改任何其他文件，包括 src/**、.github/**、eleventy.config.js、package.json、package-lock.json、README*、其他日期的 content/daily/**，以及任何站点模板、CSS、JavaScript、构建或部署配置。
3. 当天 Markdown 必须使用固定 Front Matter：
---
layout: layouts/digest.njk
title: Hacker News 热榜前 30 条
date: YYYY-MM-DD
tags: digest
permalink: /YYYY/MM/DD/index.html
description: YYYY 年 M 月 D 日 Hacker News Top 30 中文摘要与重点分类。
---
4. Front Matter 的 date、文件路径日期、permalink 日期必须完全一致。
5. 正文使用纯 Markdown，并与对话中输出的日报内容保持一致。不要生成完整 HTML，不要加入 <html>、<style>、<script>、布局 div、CSS class 或其他展示层代码。网站模板、目录、样式、RSS 和页面布局均由 Eleventy 负责。
6. 正文必须完整包含排名 1–30，以及“## 重点分类”和固定五个三级分类标题。Top 30 与重点分类必须严格遵守上述固定 Markdown schema，不允许自行变化格式。
7. 发布前再次自检：
- 排名连续且正好 30 条；
- 有 30 个原文链接和 30 个 HN 讨论链接；
- 30 个 Top 30 标题均为该条第一个粗体文本；
- 五个重点分类标题全部存在且顺序固定；
- 每个分类条目均使用 `- **N｜标题**：说明`；
- 分类编号 N 必须能对应到 Top 30 的同一条；
- 分类标题必须与 Top 30 对应标题逐字一致；
- 没有占位 URL；
- 日期三处一致；
- 没有展示层 HTML；
- 没有修改其他文件。
8. 写入前检查当天目标文件是否已经存在。若不存在，创建文件；若已存在且内容完整且与本次日报一致，不重复提交；若已存在但内容不完整或与本次结果冲突，不覆盖，报告冲突并停止 GitHub 发布。
9. 成功创建文件后提交到 main，commit message 固定为：publish: Hacker News digest YYYY-MM-DD。一次日报发布只提交当天 Markdown，不要产生用于调整站点代码的额外 commit。
10. GitHub 写入失败时，不要改用其他路径，不要修改站点代码、workflow 或历史日报进行修复；聊天中的完整日报仍正常输出，并明确报告 GitHub 发布失败及具体失败步骤。
11. 不把 GitHub Pages 部署成功作为日报内容生成成功的前提，也不要因为 Pages/Actions 未触发而修改仓库配置。若当前可用 GitHub 能力能够可靠确认本次 commit 的部署状态，可在末尾附带状态；无法确认则明确写“部署状态未确认”，不要猜测。
最终聊天回复必须先完整展示“Hacker News 热榜前 30 条｜YYYY 年 M 月 D 日”及全部重点分类，不得只给链接或发布状态。完整日报之后再追加简短的“发布状态”，分别报告：HN 数据校验（通过/失败）、日报生成（通过/失败）、GitHub 发布（成功/失败/未执行）、仓库目标路径、commit（若成功）、Pages 部署状态（若可确认）。2026-05-05 15:33:26
距离上次推荐 面向开发者的 ChatGPT 提示词工程 课程已经快过去了 3 年。如今，大语言模型的能力已经不可同日而语：上下文的容量得到巨大提升，推理能力变强，幻觉率下降，在长时任务的表现也变得更好，而且更多模型开始支持多模态。
最近，吴恩达和 deeplearning.ai 推出了新课 AI Prompting for Everyone，趁着五一假期，我也学习了一下，更新自己的知识。
这个课程分为三大部分：获取信息、使用 AI 作为思维伙伴以及使用 AI 处理多媒体和代码。课程架构清晰，每个部分的知识点衔接自然，深入浅出。即讲了提示词技巧，还介绍了背后的基本原理，并举了大量的例子帮助理解。是一个非常好的 「AI 通识课」以及「入门实践课程」，里面提到的方法不论用哪家 AI 服务都能使用。
课程地址：https://learn.deeplearning.ai/courses/ai-prompting-for-everyone/information
中文翻译视频地址（非官方）：https://www.bilibili.com/video/BV1UT9qBDET7
以下是我整理的课程大纲与笔记：《AI Prompting for Everyone-大纲&笔记》
https://wulu.zone/posts/ChatGPT-Prompt-Engineering-for-Developers-in-Chinese
2026-03-01 19:56:03
去年只看完了一本书。
作者：塔拉·韦斯特弗
译者：任爱红
出版社：南海出版公司在看这本书之前，我陆续听说过，但一直没什么兴趣去了解。在我印象中这是一本"励志"书，而我并不喜欢"励志"或"成功学"类的书籍。当时我正在看一些工具书，读得艰难有些疲惫，就想换本有故事性的书来放松一下。
于是，这本书陪我度过了多个通勤和午休前的时间。读完后我发现，虽然作者的故事确实很励志，但这本书想表达的不止于此——它给我带来的更多是关于个体与家庭、个人与信仰关系的思考。
书中最让我印象深刻的，是作者在"回归家庭"和"保持自我"之间的挣扎。也许这两者并非完全对立，但她极端的成长经历把这种冲突逼到了非此即彼的境地。更难的是，"回归"这个选项有着真实的诱惑：回到家庭，回到宗教，仿佛就可以不再烦恼。放弃自己的主体性，不用再为自己负责，上帝会解决一切。那种安稳，并不是没有吸引力的。
这让我想到一个我一直在思考的问题。这种用归属感换取安全感的冲动，在宗教信仰里同样存在——信仰一个至高无上的力量，仿佛生活的问题都能得到解答，仿佛你也能借此拥有某种庇护。这种对外部至高力量的依赖，与作者面临的选择很相似：是选择依赖某个更大的存在来承担自己，还是承担独立思考的重负，以及随之而来的孤独？作者的选择给出了她的答案。
总的来说，我觉得这本书有一种温柔的治愈力量。它没有简单地批判或赞美她的家人，也没有简单地美化自己的选择，而是以真诚的探索和思考，展现了一个人如何在复杂的关系网络中寻找自己的位置。
2026-01-25 20:24:16
本文记录我使用树莓派 5 过程的经验，即是笔记，也是分享。
我在我的树莓派 5 4GB 上跑 Docker，部署了多个服务。当加入 Nextcloud 后，系统开始出现明显卡顿，响应速度大幅下降。输入 top 命令发现，内存几乎用满，swap 更是直接 100% 占用：
MiB Mem : 4049.9 total, 146.7 free, 3369.8 used, 789.0 buff/c
MiB Swap: 200.0 total, 0.0 free, 200.0 used. 680.1 avail这时我才发现树莓派 5 的 Raspberry Pi OS (Bookworm) 默认仅配置了 200MB swap。这个保守的设置可能是为了照顾使用 SD 卡的用户——毕竟频繁的 swap 读写会严重缩短 SD 卡寿命。
但既然树莓派 5 已经配备了 PCIe 接口，官方也推出了专用的 M.2 HAT+ 和 SSD 套件，如果你和我一样使用 SSD 作为系统盘，完全可以将 swap 调大，充分发挥 SSD 的读写性能和耐用性优势。
打开配置文件：
sudo nano /etc/dphys-swapfile修改 CONF_SWAPSIZE，我的树莓派系统是安装在 SSD 上的，所以 swap 调大点没关系。如果你用的是 SD 卡，建议设置小点，不要超过 1GB，因为频繁的 swap 读写会大幅缩短 SD 卡寿命。
CONF_SWAPSIZE=4096 为了设置超过 2GB 的 swap， 还需要修改 CONF_MAXSWAP 调大限制，可以和 CONF_SWAPSIZE 一致，也可以设置的更大一些方便后续调整。
CONF_MAXSWAP=4096重启 swap 服务
sudo /etc/init.d/dphys-swapfile restart验证
free -h在 AI 的建议下，我还开启了 zram。zram 是一个在内存中创建压缩交换空间的技术。简单来说，它会将不常用的内存页压缩后存储在内存里，通常能达到 2-3 倍的压缩比。对于树莓派这种内存有限的设备来说，zram 是个非常实用的优化手段。
安装
sudo apt update
sudo apt install zram-tools验证
cat /proc/swaps可以看到
Filename Type Size Used Priority
/dev/zram0 partition 262128 257344 100
/var/swap file 4194288 697648 -2如果你使用树莓派 5 搭配 树莓派官方 M.2 套件（HAT+），建议不要把树莓派直接叠放在路由器上。
之前有段时间，我发现树莓派经常重启，有时甚至直接卡死无响应。最严重的一次，我部署的 Karakeep 书签服务因为底层数据错误导致数据库损坏，数据瞬间全丢，万幸最后从 Meilisearch 中抢救回来了。
排查过程中我尝试了很多方法（包括修改PCIe节能设置等），最后发现罪魁祸首可能是官方 FPC 排线的抗干扰能力不足（虽然官方说是抗干扰的）。后来我将树莓派与路由器物理分离一段距离后，就再也没出现过类似问题。
如果你不需要使用树莓派的 WiFi 功能，也建议关闭。
https://linuxblog.io/raspberry-pi-performance-add-zram-kernel-parameters/
https://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/559
2025-11-20 21:53:39
默认情况下，Antigravity 使用 Open VSX 作为扩展市场，因此许多在 Visual Studio Code 中可安装的扩展在 Antigravity 里可能搜不到。如果在从 VS Code 迁移过来，可能会很不习惯。
可以通过下面方式，让 Antigravity 能够使用 VS Code 的应用扩展商店：
在 Antigravity 的菜单栏中的 “首选项” 中打开 “Antigravity Setting”。
在设置中的 “Editor” 区域，设置以下参数：
Marketplace Item URL
https://marketplace.visualstudio.com/itemsMarketplace Gallery URL
https://marketplace.visualstudio.com/_apis/public/gallery
重启 Antigravity 即可。
2025-09-27 12:02:51
时隔多年再次重装 OpenWrt，早已忘记当初的安装方法。许多教程已经过时或缺少关键细节，因此记录本文以便日后查阅，也方便有需要的人参考。如有问题，欢迎在评论区讨论。本文仅作为参考，请谨慎操作，数据风险自负。
本文将演示如何在树莓派4B上安装 ImmortalWrt 并进行扩容。
ImmortalWrt 是 OpenWrt 的一个分支 ，它移植了更多的软件包，支持更广泛的设备，默认优化了配置文件，并为中国大陆用户进行了本地化修改。
前往 ImmortalWrt 固件选择工具 下载对应固件：
搜索设备型号，查找对应固件。
每个设备一般会对应四个固件：
首次安装，选择 FACTORY 版本，树莓派设备推荐使用 EXT4。
下载 FACTORY(EXT4) 的版本。
利用 rufus 工具将上一步得到的 immortalwrt-[版本号]-bcm27xx-bcm2711-rpi-4-ext4-factory.img.gz 直接烧录到内存卡，保持 rufus 默认设置即可。
ImmortalWrt 不再默认创建 Wi-Fi 热点，所以需要通过有线的方式连接到它。
把内存卡插到树莓派中，接通电源。然后用网线连接树莓派和电脑。
在电脑上访问 192.168.1.1。默认账号名为 root，密码为空。
登录后按照提示修改默认密码。
进入 “网络” - “接口”，然后编辑默认 lan 接口。
根据实际需求配置网络。
由于我将其作为旁路网关使用，所以设置了静态 IP 地址，并指定了相应的网关和 DNS。且在“DHCP 服务器”界面，勾选“忽略此接口”。
确认无误后，点击“保存并应用”，并强制执行。
然后，就可以用网线将树莓派连接到路由器了。
完成后上述步骤后，ImmortalWrt 就能正常使用了。但是默认 ImmortalWrt 只用了 300MB 的储存，并没有用完整张储存卡。所以可用空间很少，并且被浪费。
接下来我们来扩容。
安装需要用到的工具
opkg update
opkg install fdisk resize2fs losetup查看当前分区状况
fdisk -l你会看到类似下面的输出（120GB 的内存卡，只用了 64MB + 300MB）：
重新分区
进入 fdisk 工具：
fdisk /dev/mmcblk0输入 p 查看分区表，记住第二分区开始的位置：
输入 d 删除第二个分区：
输入 n 重新创建分区：
p ，或直接回车使用默认值。2 ，或直接回车使用默认值。147456（根据实际情况替换，使用原起始扇区）。N。
最后，输入 w 确认并执行变更：
再次查询分区情况，可以看到第二个分区现在已经扩大。
fdisk -l
接下来还需要让系统能够识别这个分区：
先查看当前是否有循环设备：
losetup此时，输出可能为空。或者有一些设备。在下个命令中，不要与已有设备冲突，可以用 loop1 或其他未使用的编号。
创建循环设备：
losetup /dev/loop0 /dev/mmcblk0p2扩展文件系统到分区全部空间：
resize2fs -f /dev/loop0重启系统，网页访问树莓派，可以看到扩容成功，磁盘空间大小已经更新。
reboot