编程笔记

lifelong learning & practice makes perfect

发表于 更新于
本文字数： 5.6k 阅读时长 ≈ 5 分钟

逐步走读 Linux 的启动过程：从按下电源到进入内核的第一行 C 代码，涵盖 CPU 复位、BIOS/UEFI、引导加载器、内核 setup 阶段与内存映射等关键环节。

阅读全文 »

发表于
本文字数： 405 阅读时长 ≈ 1 分钟

独立开发的AI图生图工具“即梦”获得了第一位付费用户，并且现在支持在线支付了。

收款方式

最开始为了快速打通，是在定价页面上贴了微信二维码，让用户加群支付，这种方式过于复杂，用户体验也不是很好。

从多个渠道了解了独立开发的收款方式，最终选择了微信支付。微信支付在国内用户中足够流行，目前也是最容易接入的几种可靠支付方式之一，并且使用起来也比较方便。

现在可以在“AI图生图”的官方网站上直接购买服务啦。

效果如下：

支付样例

其他方式

国外的Stripe，lemonsqueezy很流行，但搜了很多资料，目前看都是需要以公司为主体才能申请，个人很难通过。

参考

发表于 更新于 分类于
本文字数： 6.1k 阅读时长 ≈ 6 分钟

Go 1.25 在标准库中引入了一个新的中间件 http.CrossOriginProtection。这让我思考：我们是否终于可以在不依赖基于令牌的检查（如双重提交 Cookie）的情况下防止 CSRF 攻击？是否可以在不引入第三方包（如 justinas/nosurf 或 gorilla/csrf）的情况下构建安全的 Web 应用？

答案是一个谨慎的 “是” —— 只要满足一些重要条件。

http.CrossOriginProtection 中间件

该中间件通过检查请求中的 Sec-Fetch-Site 和 Origin 头来判断请求来源。它会自动拒绝来自非同源的 非安全请求（如 POST、PUT），并返回 403 Forbidden。

工作原理

  • 现代浏览器 会自动在请求中包含 Sec-Fetch-Site 头。
  • 如果请求来源与目标页面同源，则头部为 same-origin。
  • 如果不同源，则 http.CrossOriginProtection 会拒绝请求。
  • 如果没有 Sec-Fetch-Site，则回退检查 Origin 与 Host 是否匹配。
  • 如果两者都不存在，则认为请求不是来自浏览器，允许通过。
  • 仅对 非安全方法（POST、PUT 等）进行检查，GET/OPTIONS 等安全方法始终允许。

使用示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package main

import (
    "fmt"
    "log/slog"
    "net/http"
    "os"
)

func main() {
    mux := http.NewServeMux()
    mux.HandleFunc("/", home)

    slog.Info("starting server on :4000")
    err := http.ListenAndServe(":4000", http.NewCrossOriginProtection(mux))
    if err != nil {
        slog.Error(err.Error())
        os.Exit(1)
    }
}

func home(w http.ResponseWriter, r *http.Request) {
    fmt.Fprint(w, "Hello!")
}

如果您愿意，也可以配置 http.CrossOriginProtection 的行为。配置选项包括能够添加受信任的来源（允许来自这些来源的跨域请求），以及能够为被拒绝的请求使用自定义处理程序，而不是默认的 403 Forbidden 响应。

想自定义行为时，可以使用如下模式：

文件: main.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
package main

import (
	"fmt"
	"log/slog"
	"net/http"
	"os"
)

func main() {
	mux := http.NewServeMux()
	mux.HandleFunc("/", home)

	slog.Info("starting server on :4000")

	err := http.ListenAndServe(":4000", preventCSRF(mux))
	if err != nil {
		slog.Error(err.Error())
		os.Exit(1)
	}
}

func preventCSRF(next http.Handler) http.Handler {
	cop := http.NewCrossOriginProtection()

	cop.AddTrustedOrigin("https://foo.example.com")

	cop.SetDenyHandler(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusBadRequest)
		w.Write([]byte("CSRF check failed"))
	}))

	return cop.Handler(next)
}

func home(w http.ResponseWriter, r *http.Request) {
	fmt.Fprint(w, "Hello!")
}

限制

http.CrossOriginProtection 的主要限制是它只对阻止来自现代浏览器的请求有效。您的应用程序仍然容易受到来自不包含 Sec-Fetch-Site 或 Origin 头（通常是 2020 年之前的）的旧版浏览器的 CSRF 攻击。

目前，浏览器对 Sec-Fetch-Site 头的支持率为 92%，对 Origin 头为 95%。因此，通常情况下，仅仅依靠 http.CrossOriginProtection 不足以作为您唯一的 CSRF 防护措施。

还需要注意的是，只有当您的应用程序具有“可信来源”时才会发送 Sec-Fetch-Site 头——这基本上意味着您的应用程序在生产环境中使用 HTTPS（或开发期间使用 localhost），http.CrossOriginProtection 才能充分发挥作用。

您还应该知道，当请求中不存在 Sec-Fetch-Site 头，并且回退到比较 Origin 和 Host 头时，Host 头不包含方案。这个限制意味着当不存在 Sec-Fetch-Site 头但存在 Origin 头时，http.CrossOriginProtection 会错误地允许从 http://{host} 到 https://{host} 的跨域请求。为了减轻这种风险，您理想情况下应该配置您的应用程序使用 HTTP 严格传输安全 (HSTS)。

强制使用 TLS 1.3

深入研究这个问题让我开始思考… 如果您已经计划使用 HTTPS 并强制使用 TLS 1.3 作为最低支持的 TLS 版本呢？您能否确信所有支持 TLS 1.3 的网络浏览器也支持 Sec-Fetch-Site 或 Origin 头之一呢？

据我从 MDN 兼容性数据和 Can I Use 网站的表格来看，答案是“是”，适用于（几乎）所有主流浏览器。

如果您强制使用 TLS 1.3 作为最低版本：

  • 不支持 TLS 1.3 的旧版浏览器根本无法连接到您的应用程序。
  • 对于支持 TLS 1.3 并可以连接的现代主流浏览器，您可以确信至少支持 Sec-Fetch-Site 或 Origin 头之一——因此 http.CrossOriginProtection 将有效工作。

我能看到的唯一例外是 Firefox v60-69 (2018-2019)，它不支持 Sec-Fetch-Site 头，并且不为 POST 请求发送 Origin 头。这意味着 http.CrossOriginProtection 将无法有效阻止来自该浏览器的请求。Can I Use 显示 Firefox v60-69 的使用率为 0%，因此这里的风险似乎非常低——但世界上某个地方可能仍然有一些计算机在运行它。

此外，我们只掌握了主流浏览器（Chrome/Chromium、Firefox、Edge、Safari、Opera 和 Internet Explorer）的信息。但当然，还存在其他浏览器。它们大多数是 Chromium 或 Firefox 的分支，因此很可能没问题，但这里没有保证，并且很难量化风险。

因此，如果您使用 HTTPS 并强制使用 TLS 1.3，这是确保 http.CrossOriginProtection 有效工作的一大步。然而，Firefox v60-69 和非主流浏览器仍然存在非零风险，因此您可能希望增加一些纵深防御并同时使用 SameSite Cookie。

我们稍后会更多地讨论 SameSite Cookie，但首先我们需要快速绕道讨论“源 (origin)”和“站点 (site)”这两个术语之间的区别。

跨站点与跨源

在 Web 规范和 Web 浏览器的世界中，跨站点 (cross-site) 和跨源 (cross-origin) 是细微不同的概念，在这样的安全上下文中，理解它们之间的区别并确切地表达我们的意思非常重要。

我将快速解释。

如果两个网站共享完全相同的方案 (scheme)、主机名 (hostname) 和端口（如果存在），则它们具有相同的源 (origin)。因此 https://example.com 和 https://www.example.com 不是相同的源，因为主机名 (example.com 和 www.example.com) 不同。它们之间的请求将是跨源的。

如果两个网站共享相同的方案和可注册域 (registerable domain)，则它们是“同站 (same site)”的。

注意：可注册域是主机名中紧邻（并包括）有效顶级域 (effective TLD) 的部分。以下是一些示例：

  • 对于 https://www.google.com/，顶级域是 com，可注册域是 google.com。
  • 对于 https://login.mail.ucla.edu，顶级域是 edu，可注册域是 ucla.edu。
  • 对于 https://www.gov.uk，顶级域是 gov.uk，可注册域是 www.gov.uk。

您可以在此处找到有效顶级域的完整列表。

因此，https://example.com、https://www.example.com 和 https://login.admin.example.com 都被认为是同站的，因为方案 (https) 和可注册域 (example.com) 相同。它们之间的请求不会被认为是跨站的，但会是跨源的。

注意：某些浏览器版本使用不同的同站定义，它不要求相同的方案，只要求相同的可注册域。对于这些浏览器版本，https://admin.example.com 和 http://blog.example.com 也将被视为同站。

如今，这通常被称为无方案同站 (schemaless same-site)，但在历史版本或文档中，它可能只被称为同站。

那么，我在这里想要表达的要点是什么呢？

Go 的 http.CrossOriginProtection 中间件的命名是准确且恰当的。它阻止跨源请求。它比只阻止跨站请求更严格，因为它也阻止来自同一站点（即可注册域下的其他源）的请求。

这很有用，因为它有助于防止您的老旧、十多年未更新的 WordPress 博客 https://blog.example.com 被攻破，并被用来向您的重要网站 https://admin.example.com 发起请求伪造攻击的情况。

当大多数人——包括我自己在内——随意谈论“CSRF 攻击”时，我们大多数时候指的是实际上是跨源请求伪造 (cross-origin request forgery)，而不仅仅是跨站请求伪造 (cross-site request forgery)。很遗憾 CSRF 是描述这类攻击的常用和已知缩写，因为大多数时候 CORF 会更准确和恰当。但嘿！这就是我们所处的混乱世界。

然而，在本文的其余部分，当我的意思确实是跨源请求伪造时，我将使用 CORF 代替 CSRF。

SameSite Cookie 属性自 2017 年起普遍受到网络浏览器的支持，Go 自 v1.11 起也支持。如果您在 Cookie 上设置 SameSite=Lax 或 SameSite=Strict 属性，则该 Cookie 将仅包含在发送到设置它的同一站点的请求中。反过来，这可以防止跨站请求伪造攻击（但不能防止来自同一站点内的跨源攻击）。

这里有一些好消息——所有支持 TLS 1.3 的主流浏览器也都完全支持 SameSite Cookie，据我所知没有例外。因此，如果您强制使用 TLS 1.3，您可以确信所有使用您应用程序的主流浏览器都会遵守 SameSite 属性。

这意味着通过在 Cookie 上使用 SameSite=Lax 或 SameSite=Strict，您可以消除我们之前谈到的 Firefox v60-69 引起的跨站请求伪造风险。

综合考量

如果您结合使用 HTTPS，强制将 TLS 1.3 作为最低版本，适当使用 SameSite=Lax 或 SameSite=Strict Cookie，并在您的应用程序中使用 http.CrossOriginProtection 中间件，据我所知，主流浏览器只剩下两个未被缓解的 CSRF/CORF 风险：

  1. Firefox v60-69 中来自同一站点的 CORF 攻击（即来自您的可注册域下的另一个子域）。
  2. 从您的源的 HTTP 版本发起的 CORF 攻击，来自不支持 Sec-Fetch-Site 头的浏览器。

对于第一个风险，如果您在可注册域下没有任何其他网站，或者您确信这些网站是安全的且未被攻破，那么鉴于 Firefox v60-69 的使用率极低，这可能是一个您愿意接受的风险。

对于第二个风险，如果您的源根本不支持 HTTP（包括重定向），那么您无需担心这一点。否则，您可以通过在 HTTPS 响应中包含 HSTS 头来缓解风险。

在本文的开头，我提到在某些条件下不使用基于令牌的 CSRF 检查可能是可以的。那么，让我们回顾一下这些条件是什么：

  • 您的应用程序使用 HTTPS 并强制将 TLS 1.3 作为最低版本。您接受使用旧版浏览器的用户将根本无法连接到您的应用程序。
  • 您遵循良好实践，绝不响应使用安全方法 GET、HEAD、OPTIONS 或 TRACE 的请求来更改重要的应用程序状态。
  • 您同时使用 http.CrossOriginProtection 中间件和 SameSite=Lax 或 SameSite=Strict Cookie。使用 SameSite Cookie 对于一般的纵深防御很重要，更具体地说，是为了缓解来自 Firefox v60-69 的 CSRF 攻击。
  • 由于来自 Firefox v60-69 的未受保护的同站 CORF 攻击风险，您要么在您的可注册域下没有任何其他网站，要么您确信它们是安全且未被攻破的。
  • 您的应用程序源根本没有 HTTP 版本，或者您在 HTTPS 响应中包含 HSTS 头。
  • 最后，您愿意接受来自非主流浏览器（支持 TLS 1.3 但不支持 Origin 或 Sec-Fetch-Site 头或 SameSite Cookie）的 CSRF/CORF 攻击的难以量化的风险。是否存在这样的浏览器？我不知道，我也不确定是否有办法 100% 确定地回答这个问题。因此，您需要在此处进行自己的风险评估，这可能是一个您只愿意接受的风险，如果您的应用程序是一个低价值目标，并且成功进行 CSRF/CORF 攻击的影响既孤立又轻微。

原文

发表于 更新于
本文字数： 1.5k 阅读时长 ≈ 1 分钟

在数字创意的浪潮中，人工智能（AI）正以前所未有的方式赋予我们表达自我的力量。曾经需要专业技能和昂贵软件才能实现的视觉艺术，如今AI 的进步，变得触手可及。今天，我们向您隆重介绍一款强大而易用的在线工具——AI图生图，它将彻底改变您的创作流程，让每个人都能轻松成为艺术家。

最重要的是，这款工具限时免费试用，并且无需注册登录，您可以立即开始您的创意之旅！

立即访问 AI图生图，开启无限创造力

核心功能亮点

“AI图生图”不仅仅是一个简单的图像生成器，它集成了多种强大功能，旨在满足从初学者到专业人士的各种需求。

1. 强大的“文生图”与“图生图”模式

无论您是想将脑海中的奇幻场景变为现实，还是希望在现有图片的基础上进行二次创作，我们都能满足您。

  • 文生图 (Text-to-Image): 只需输入一段描述性的文字（我们称之为“提示词”），AI 就能为您绘制出对应的图像。您的想象力是唯一的边界！
  • 图生图 (Image-to-Image): 您可以上传一张自己的图片作为参考，AI
    将智能地理解其内容、风格和构图，并根据您的新提示词进行创新性地重绘或风格迁移。

AI生成的奇幻景观

AI图生图：将简单的文字提示变为复杂的视觉作品

2. 丰富的内置预设风格

灵感枯竭？没关系！网站内置了上百种精心调校的预设风格，涵盖3D、动漫、现实主义、纸艺、水墨画等多种艺术形式。只需一键点击，即可将您的想法应用到不同风格上，轻松探索多种可能性。

3. 极致简单的三步操作流程

我们坚信，强大的功能不应以牺牲易用性为代价。整个创作过程被简化为三个直观的步骤：

  1. 描述您的想法： 在输入框中填写您的提示词，或上传参考图，并选择您喜欢的风格。
  2. AI 魔法生成： 点击“生成”按钮，我们强大的 AI 模型将立即开始工作。
  3. 下载与分享：
    短短几十秒后，一幅高质量的图像便会呈现眼前。您可以立即下载高清版本，或在历史记录中随时回顾。

无限的应用场景

“AI图生图”的潜力覆盖了各行各业，无论您的身份是什么，都能从中受益。

  • 设计师与艺术家： 快速生成概念原型，探索不同视觉风格，为您的项目注入源源不断的灵感。
  • 营销与运营人员： 无需再为寻找配图而烦恼。轻松生成独特、免版权风险的社交媒体帖子、博客文章配图和广告素材。
  • 内容创作者： 为您的视频、播客或小说创作引人入胜的封面和插图。
  • 普通爱好者： 制作个性化的手机壁纸、社交媒体头像，或者仅仅是享受将奇思妙想变为现实的乐趣。

AI生成的专业美食摄影

无论是商业广告还是个人创作，AI都能胜任

立即开始您的创作之旅！

创意不应被技术门槛所束缚。“AI图生图”致力于将最前沿的AI技术以最简单的方式带给每一位热爱生活、充满想象力的人。

忘记复杂的参数和昂贵的订阅费吧。现在就打开浏览器，访问我们的网站，释放您被压抑已久的创造力！

官方网站： https://seedreamt.programnotes.cn/

我们期待看到您独一无二的精彩作品！

创意作品

阅读全文 »

发表于 更新于
本文字数： 1.8k 阅读时长 ≈ 2 分钟

以下是2025年9月15日至16日过去24小时内最重要的AI和技术发展总结，优先关注模型发布、新论文和开源项目。信息基于网络搜索和X平台数据，包含来源链接。内容聚焦于关键公告、工具更新和创新。

模型发布与更新

  • OpenAI 升级 Codex，使用新版 GPT-5：OpenAI于9月15日发布Codex的升级版本，集成新GPT-5模型，支持更复杂的编码任务，并引入gpt-realtime功能，提升实时交互能力。 来源：TechCrunch 和 OpenAI News.
  • Alibaba 发布 Qwen 3-Next-80B：这是一个高效混合模型，仅激活约30亿参数，支持10倍速度提升和更低成本，适用于任务优化。 来源：PaleBlueDot AI on X.
  • ByteDance 发布 Seedream 4.0：融合图像生成与编辑，支持2K分辨率输出，生成时间不到2秒。 来源：PaleBlueDot AI on X.
  • Kimi Moonshot AI 发布 K2-0905：1万亿参数MoE模型，支持256k上下文长度，针对代理开发任务，如全代码库处理。 来源：PaleBlueDot AI on X.
  • Meta 发布 MobileLLM-R1：小型LLM模型，针对非商业研究，提升移动设备上的语言处理效率。 来源：merve on X.
  • Tencent 发布 SRPO：高分辨率图像生成模型，以及Points-Reader OCR模型，提升文本识别准确性。 来源：merve on X.
  • ByteDance 发布 HuMo：视频生成模型，支持任意输入生成视频。 来源：merve on X.
  • xAI 发布新AI模型：专注于增强对物理世界的理解和操作，推动机器人和自治系统进步。 来源：Daily 5 Minutes News on X.
  • AnthropicAI 更新 Claude 3.7：聚焦自然语言处理改进和实时应用延迟降低。 来源：Daily 5 Minutes News on X.

新论文

  • arXiv 上新AI论文（9月16日）：包括266篇新论文，亮点如“Is the ‘Agent’ Paradigm a Limiting Framework for Next-Generation Intelligent Systems?”（质疑代理范式对下一代智能系统的限制），以及其他涉及诊断精神患者、生成AI故事等主题。 来源：arXiv Artificial Intelligence Recent.
  • 机器学习论文更新：焦点包括使用大语言模型诊断精神患者，以及其他如模拟酵母着丝粒、诊断一维CNN等。 来源：arXiv Machine Learning Current.
  • 新兴技术论文：45篇新作，如新西兰房屋能源效率AI工具原型。 来源：arXiv Emerging Technologies Current.
  • Harvard AI论文：PDGrapher：AI工具发现逆转细胞疾病的药物组合。 来源：jeromekjerome on X.

开源项目与工具

  • MistralAI 发布新开源模型：旨在民主化高性能语言处理工具访问。 来源：Daily 5 Minutes News on X.
  • HuggingFace 更新模型仓库：新增50+ NLP和计算机视觉AI模型。 来源：Daily 5 Minutes News on X.
  • StabilityAI 扩展文本到图像功能：提供更高分辨率和更快处理。 来源：Daily 5 Minutes News on X.
  • Replit Agent 3：自主代理工具，用于构建生产级应用，支持10倍自治能力。 来源：AI News on X.
  • NVIDIA 发布 Physics Nemo：物理模拟开源模型。 来源：AI News on X.
  • Switzerland 发布 Apertus：国家级开源AI模型。 来源：The AI Track.

其他重要公告与更新

  • OpenAI 与 Microsoft 重组：签署非约束性谅解备忘录，推动OpenAI向营利性转型，非营利部门保留1000亿美元以上股权。 来源：PaleBlueDot AI on X.
  • OpenAI 获得66亿美元融资：加速AI研发。 来源：Daily 5 Minutes News on X.
  • NVIDIA Rubin CPX 发布：新加速器用于推理预填充阶段，减少对HBM依赖。 来源：PaleBlueDot AI on X.
  • DeepMind 发布新AI伦理框架：指导全球AI系统的负责开发和部署。 来源：Daily 5 Minutes News on X.

发表于 更新于
本文字数： 3.7k 阅读时长 ≈ 3 分钟

介绍如何使用gemini-cli自定义斜杠命令,该功能允许用户定义可重用的提示，以简化交互并提高效率。这些斜杠命令可以在本地 .toml 文件中定义，也可以通过模型上下文协议 (MCP) 提示定义。如何使用 .toml 文件创建自定义斜杠命令?将以一个用于审查 GitHub pull request 的 .toml 文件示例，重点介绍了在提示中使用参数和执行 shell 命令。还介绍了命名空间，它允许使用子目录将相关命令分组在单个命名空间下。文章提供了构建斜杠命令的分步指南，包括创建命令文件、添加命令定义以及在 Gemini CLI 中使用该命令。

阅读全文 »

发表于 更新于
本文字数： 5.5k 阅读时长 ≈ 5 分钟

discusses the new support for custom slash commands in Gemini CLI, a feature that allows users to define reusable prompts for streamlining interactions and improving efficiency. These slash commands can be defined in local .toml files or through Model Context Protocol (MCP) prompts

阅读全文 »

发表于 更新于
本文字数： 2k 阅读时长 ≈ 2 分钟

以下介绍一种减少LLM在执行复杂任务过程中产生幻觉的技巧,让ai更好完成任务,示例需结合gemini-cli使用,在其他工具中使用方法类似

提示词

指定ai能使用的工具,定义好输入/输出格式,拆分步骤,设定好笔记格式,让ai分步执行,并在每步完成后记到笔记文件中直到完成任务.

如下是一个翻译网页提示词:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
输入：
文章URL：https://cloud.google.com/blog/topics/developers-practitioners/gemini-cli-custom-slash-commands

输出：
1. 格式化后的原文article.md
2. 中英文双语版article-en-cn.md
3. 中文版article-cn.md
4. 文章中所有的图片资源

每完成一步，都必须更新progress.md

步骤0: 生成笔记
- 仿照例子和当前任务生成笔记 progress.md

步骤1: 访问网站
- 访问上文输入中网址
- 必须使用 "lynx -dump -image_links URL"命令访问网站
- 网站内容保存在raw.txt中

步骤2：下载图片
- 从raw.txt中提取文章相关图片链接
- 把图片链接写入 progress.md
- 逐一下载到 resources/ 文件夹
- 每下载完成一个图片，必须更新图片下载进度
- 你必须使用curl命令进行下载

步骤3：改写成markdown
- 把raw.txt改写成markdown格式
- 保存在article.md中
- 将article.md中的图片链接指向 resources/ 文件夹

步骤4：翻译成中英文
- 把article.md翻译成中英文对照
- 保存在article-en-cn.md中

步骤5：翻译成中文
- 提取article-en-cn.md中的中文
- 保存在article-cn.md中

----
progress.md 笔记格式

## 任务
[x] xxxxx
[ ] yyyyy
[ ] zzzzz
...

## 图片下载进度
[x] https://xxxx/yyy.png
[ ] https://foo/bar.png
...

## 当前任务
正在下载https://foo/bar.png

封装为gemini-cli命令

将提示词写到文件中 ~/.gemini/commands/translate.toml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
prompt = """
输入：
文章URL：{{args}}

输出：
1. 格式化后的原文article.md
2. 中英文双语版article-en-cn.md
3. 中文版article-cn.md
4. 文章中所有的图片资源

每完成一步，都必须更新progress.md

步骤0: 生成笔记
- 仿照例子和当前任务生成笔记 progress.md

步骤1: 访问网站
- 访问上文输入中网址
- 必须使用 "lynx -dump -image_links URL"命令访问网站
- 网站内容保存在raw.txt中

步骤2：下载图片
- 从raw.txt中提取文章相关图片链接
- 把图片链接写入 progress.md
- 逐一下载到 resources/ 文件夹
- 每下载完成一个图片，必须更新图片下载进度
- 你必须使用curl命令进行下载

步骤3：改写成markdown
- 把raw.txt改写成markdown格式
- 保存在article.md中
- 将article.md中的图片链接指向 resources/ 文件夹

步骤4：翻译成中英文
- 把article.md翻译成中英文对照
- 保存在article-en-cn.md中

步骤5：翻译成中文
- 提取article-en-cn.md中的中文
- 保存在article-cn.md中

----
progress.md 笔记格式

## 任务
[x] xxxxx
[ ] yyyyy
[ ] zzzzz
...

## 图片下载进度
[x] https://xxxx/yyy.png
[ ] https://foo/bar.png
...

## 当前任务
正在下载https://foo/bar.png

"""

即可这样使用

1
2
3
gemini

/translate https://cloud.google.com/blog/topics/developers-practitioners/gemini-cli-custom-slash-commands

参考

  1. video
  1. prompt