编程笔记

lifelong learning & practice makes perfect

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

默认的必应搜索搜索代码相关的信息很多csdn的文章,质量不行,使用 -*.csdn.net过滤掉

默认

搜索coze,默认为:

国内版 https://cn.bing.com/search?q=coze
国际版 https://bing.com/search?q=coze

屏蔽后

国内版 https://cn.bing.com/search?q=coze%20-site:*.csdn.net
国际版 https://bing.com/search?q=coze%20-site:*.csdn.net

配置

使用 Infinity 插件的可以这样配置:

配置

发表于 更新于
本文字数： 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 中使用该命令。

阅读全文 »