在Codex中,技能不是/命令(在Claude Code中几乎是)

TL;DR:如果你在使用Codex,command(命令) 用于控制会话或应用程序,而skill(技能) 用于教代理一种工作方法。在Claude Code中,目前的文档已经将技能视为可以用/skill-name直接调用的东西,所以这两种概念在Claude Code中更为融合。但在Codex中恰恰相反:types可以作为技能存在,但/types却可能不存在。 当你从Claude Code切换到Codex时,这种混淆非常常见。而且可以理解。 你创建了一个名为types的技能,回到终端时满怀信心地输入/types……然后Codex看着你,就像你在五金店里要了一杯拉格啤酒。 问题不是技能坏掉了。问题在于,在Codex中,技能和命令并不是一回事。 请注意,这种差异并非表面上的不同,它会彻底改变你设计工作流的方式。 一个让你秒懂的类比 想象一下,Codex就像是一架有两层结构的飞机。 第一层是驾驶舱:按钮、杠杆、指示器。这是命令的栖息地,用于改变会话、客户端或工具的状态,这是操作控制。 第二层是副驾驶手册:流程、标准、检查清单、避免陷阱的指南。这是技能的领域,用于改变代理思考和执行任务的方式。 通俗地讲: 命令是动驾驶舱里的按钮。 技能是改副驾驶脑中的手册。 如果你把手册当成按钮来用,那肯定行不通。 什么是Codex中的命令 在Codex中,命令有两种形式,千万别搞混。 第一种是CLI命令: codex login codex exec "run tests and fix failures" codex resume --last codex apply --- 这很直接明了。这些是应用程序的操作:登录、运行任务、恢复会话、应用变更。如果明天系统中没有了模型,这些命令依然有意义。 第二种是**交互式会话中的斜杠命令**: ```text /model /permissions /personality /agent /status 它们也并非是“华丽的提示语”。它们控制的是实时的会话:更改模型、调整权限、切换人物风格、设定活动线程或改变可见状态。这些就像驾驶舱中的控制按钮。 OpenAI事实上非常清晰地记录了它们的用途:一方面,有专门的斜杠命令页面用于“在交互会话中控制Codex”的说明;另一方面,另有一份独立的技能页面,将技能定义为可重用工作流的创建格式。 这也是为什么有些操作会成为命令而不是技能:因为它们需要可预测性、即时响应和稳定语义。你不希望模型“有创意地解释”/permissions的含义。你只希望它直接更改权限。就这么简单。 什么是Codex中的技能 Codex中的技能是完全不同的东西。它就是一个可重用的工作流,用来教给代理何时运用某种方法、如何思考某个任务并按照特定步骤操作。 这里还有一个细微但重要的区别:OpenAI表示,skill是一种编写格式,而**plugin(插件)**是可安装或分发的单元。换句话说,你会先将工作流设计为技能;如果需要分享或进行封装,就可以把它打包成插件。 明确的例子: $types $improve $owasp $blog 或者,如果更偏语言化: 使用types来审计这个代码仓库 使用improve来检查这个diff 你在这些例子里并不是叫Codex去“切换设置”。你是在告诉它,“当我让你执行这项任务时,请按照这套剧本来操作”。 以我的types技能为例,它不应该是个按钮。它的工作是读取项目代码、检测语言、检查模型、寻找“字符串类型化的代码”、判断一个Optional的使用是否合理并是否能正确建模域状态。这需要背景和判断能力,正是技能擅长的工作。 同理,improve作为一个技能也讲得通:检查diff并不是什么机械性的操作,反而涉及到判断、上下文和优先级的权衡。 为什么在Claude Code中“看起来像是一样的” 这里就是认知的陷阱了。 最新的Claude Code文档对这一点已经毫不避讳了。它谈到技能时,会告诉你可以通过以下方式直接调用: /skill-name 也就是说,在Claude Code中,你认为的某些属于“可重用工作流”的东西是通过斜杠命令语法来调用的。用户体验上,它将Codex中分离的两个概念合并了: ...

2026年3月30日 · Fernando

Codex CLI 自动同意:两个标志让它不再打断你

安装 Codex CLI 后,满怀期待地启动它。你告诉它“修复这个代码库中失败的测试”。然而,灾难随即开始: Codex: I want to run pytest Allow? (y/n) 你输入了 y。接下来: Codex: I want to modify test_user.py Allow? (y/n) 又输入了 y 。一次又一次,每次需要读取一个文件、执行一个命令或者修改一行代码,它都会请求确认。确认,确认,还是确认。这感觉就像跟一个刚入门的实习生合作,他每次连去洗个手间都要问你同不同意。 与此同时,Claude Code 或 Cursor Agent 却可以实现相同的功能,但却不会多说一句话。这是为什么? 原因在于:默认情况下,Codex 被配置为一个“过于谨慎”的助手。这么做是为了安全考虑,尤其是针对一款新产品来说是很合理的。但如果你对操作足够了解,这种保守模式在实际工作中将让人无法忍受。 好消息是:只需几秒钟便能调整过来。 权限模式:approval mode Codex 使用一种叫做 approval mode(批准模式)的概念来控制需要你授权的情境。默认设置下,它对所有操作都需要你的确认: 执行命令 写入文件 修改代码 创建新文件 运行测试 简单来说:默认状态下,Codex 无法在没有你按下 y 键的情况下做任何事情。可以将其形容为:对每一个操作都需要一次 sudo 操作。 这使得一个本应是自主代理的工具,变成了一场你成为整个过程中最慢环节的无休止对话。 解决方案:使用一个标志 codex --full-auto 从版本 0.1.2 起,--full-auto 是官方的快捷方式,它将 --approval-mode never 和 --sandbox workspace-write 两个参数组合在一起。如果你使用的是旧版本,也可以用完整写法: codex --approval-mode never 无论选择哪种方法,Codex 都会停止询问你,直接执行命令、修改文件、创建需要的内容。它将真正成为一个自主工作的代理。 ...

2026年3月11日 · Fernando

无需 Codex 的 Codex Automations:用 Claude Code 和 systemd 打造夜班代理

两周前,OpenAI 推出了 Codex Automations。简单来说:你定义一个触发器(如 cron、代码 push 或新 issue),写下自然语言指令,一个代理在独立的 worktree 中自动执行这一切。整个过程无需人类介入。在你睡觉时,代理自动整理 issues、总结 CI 错误、生成发布文档,甚至优化自身的指令。 听上去像魔法?确实有几分神奇。但他们在 keynote 里没怎么提到的一个细节是:你必须在桌面上运行 Codex App。支持 macOS 和 Windows。没有无头服务器的选项。安装在一个迷你 PC 上并丢一边任其运行?没门。 这时我想:“等等,我已经有这个了。” 你已经拥有的组件 如果你在使用 Claude Code,那么你已经拥有 90% 的基础设施。用命令 claude --print 就能在非交互式会话中执行提示(prompt)。传递指令,获取结果,关闭,不需要图形界面或者打开的终端窗口。这对于一个 cron 工作来说简直完美。 如果你已有一台永远开机的服务器(比如迷你 PC、树莓派,或者每月 5 欧元的 VPS),那么你已经有了调度程序。systemd 或 cron,任选一个,它们都已运行了多年,已经非常稳定。 如果你在用 Gitea、GitHub 或任何支持 API 的代码托管平台,意味着你已经有了存放结果的位置:PR 评论、新建 Issue 或直接提交文件。 用简单点的话说:Codex Automations 是一种范式,而不是一个产品。而且这种范式已经存在很多年了。 ┌─────────────────────────────────────────────┐ │ systemd timer (每隔 N 小时运行) │ │ │ │ │ ▼ │ │ bash/fish 脚本 │ │ │ │ │ ├── git pull --ff-only │ │ ├── claude --print "prompt" │ │ ├── 解析结果 │ │ ├── 通知 (Telegram/email) │ │ └── git push (如果有变更) │ └─────────────────────────────────────────────┘ 自动化的构成 所有的自动化都遵循同样的结构。一个脚本会经过以下步骤: ...

2026年3月11日 · Fernando

MEMORY.md:你的 AI 自主编写的工作笔记本

“我们昨天不是已经决定这个了吗?” 我正在将我的邮件从 Google 迁移出来。已经用 Claude Code 工作了两个会话:Linear 中的 issues、做出的决策、执行的脚本。我开始第三个会话,问它"degoogle 还剩什么待办事项?" 沉默。完全失忆。 这就像和一个聪明的同事一起工作,但他每天早上来办公室都完全不记得你们前一天做了什么。不记得决策,不记得错误,不记得发现。每个会话都是一张白纸。 结果有一个文件恰好解决了这个问题。它已经在那里几个月了。而且几乎没人知道。 CLAUDE.md vs MEMORY.md:手册和笔记本 如果你使用 Claude Code,可能已经了解 CLAUDE.md。这是你告诉 AI 如何工作的文件:使用什么语言、你有什么工具、你的代码约定。 CLAUDE.md 是你的指令手册。你编写它,你维护它。 MEMORY.md 是另一回事。它是 AI 自己编写的工作笔记本。它记录在与你合作时学到的东西:犯过的错误、做出的决策、项目模式、尝试过但没有成功的东西。 简单来说: CLAUDE.md MEMORY.md 谁编写 你 AI 包含什么 指令 学习内容 何时更改 当你想要时 每次会话后 类比 规章制度 工作笔记本 如果 CLAUDE.md 是你第一天给实习生的合同,MEMORY.md 就是实习生工作时在笔记本中记录的笔记。 它在哪里 ~/.claude/projects/<目录哈希>/memory/MEMORY.md 每个项目目录都有自己的内存文件。如果你在 ~/code/项目-a 工作,它有一个 MEMORY.md。如果你在 ~/code/项目-b 中打开 Claude Code,它有另一个不同的。它们不会混合。 文件在每个会话开始时自动加载到上下文中。你不需要做任何事情。 没有全局的 MEMORY.md 吗? 没有。只按项目分类。这是个问题。 今天我创建了一个 op(1Password CLI)的包装器,缓存密钥一小时。这在我所有项目中都有用,不只是我正在工作的那个。但 MEMORY.md 只在那个目录的内存中记录了它。 CLAUDE.md 确实有全局版本(~/.claude/CLAUDE.md),会在所有会话中加载。MEMORY.md 没有对应功能。如果 AI 学到了适用于你整个环境的东西(别名、系统特性、偏好),它必须在每个项目中分别记录。或者不记录。 ...

2026年2月12日 · Fernando

10 GB 的虚拟机支持聊天机器人:Claude 在你的 Mac 上到底在做什么

10 GB 的惊喜 你在 Mac 上安装了 Claude Desktop。最初一切正常,这个应用看似占用空间很小。但某天,当你检查磁盘时,发现了这个文件: ~/Library/Application Support/Claude/vm_bundles/claudevm.bundle 10.8 GB。 是的:一个名为 claudevm.bundle 的文件,隐藏在 Claude 的 vm_bundles 文件夹中,竟占用了将近 11 GB 的存储空间。一个聊天机器人居然需要 10 GB?它里面装了什么,魔戒三部曲加长版视频? 其实不是。claudevm.bundle 包含了一个 Ubuntu 系统。 Claude 的三大产品类别 在解释“是什么”之前,先来聊聊“为什么”。Anthropic 提供了三种方式让你使用 Claude: 产品 执行环境 目标用户 claude.ai Anthropic 云服务器 所有人 Claude Desktop + Cowork 你的 Mac 上的虚拟机 专业人士 Claude Code 在你的系统上直接运行 开发者 网页版是最安全的选项:所有操作都在 Anthropic 的云端完成,你的电脑完全不受影响。但如果你希望 Claude 不仅仅用于聊天,还能在你的电脑上“真正做事情”——比如创建文档、执行代码、处理文件等,那你需要更多功能。 这时,Cowork 和 Claude Code 应运而生,两者代表了完全不同的理念。 Cowork:人人都能用的 Claude Code Cowork 是 Anthropic 在 2026 年 1 月 12 日推出的智能助手产品。它的官方口号是: ...

2026年1月25日 · Fernando

你的终端正在像挖比特币一样耗电

犯罪现场 萨拉戈萨,皮拉尔广场酒店的咖啡厅。一杯拿铁,望向大教堂的景色,还有我带着全新的MacBook Air M3,准备在会议前用Claude Code工作几个小时。 两小时后:电池剩余15%。红色警报。恐慌。 但是怎么可能?我只是在终端里写代码。没有视频,没有Zoom,没有任何能够合理解释如此高耗电量的应用。 我打开活动监视器,点击能耗选项卡,罪魁祸首就在那里:Ghostty,在过去12小时内累计消耗了3600。为了让你有个概念,Brave浏览器消耗了125。开着视频的Zoom消耗了99。Claude(桌面应用)消耗了46。 我的终端——一个显示文本的应用程序——消耗的电量比网页浏览器多30倍。 荒谬中的荒谬 停下来想想我刚才写的内容。 一个终端。一个VT100模拟器。一项1978年的技术。字面意思上是一个工作就是在屏幕上显示字母的应用程序,这是Commodore 64都能轻松完成的任务。 而在2026年,它需要GPU来运行。 用大白话说:我们正在使用本可以实时渲染《玩具总动员》的计算能力…来显示ls -la。 原版VT100终端消耗30W包括CRT显示器。我的MacBook Air,配备专为能效设计的最新芯片,显示一个git status比执行视频通话消耗的电量还要多。 这就像开法拉利去买面包。但更糟糕,因为如果你想开得快,法拉利至少还有意义。这里没有任何实际优势:文本看起来完全一样。 为什么终端需要GPU? Ghostty、Alacritty、Kitty等是新一代"GPU加速"终端的一部分。承诺:更流畅的渲染,大量输出时更好的性能,更清晰的字体。 现实:它们像没有明天一样耗电,显示的内容和Terminal.app使用CPU显示的完全相同。 问题不仅仅是渲染。当Claude Code运行时,会有持续的输出:旋转器、日志、工具结果。屏幕上出现的每个字符都会触发GPU渲染管道。Metal激活,着色器开始工作,帧被合成… 就为了显示一个旋转的点。 更糟糕的是,这些现代终端无法正确进入"App Nap"状态。macOS有一个暂停后台应用程序的系统,但如果终端正在显示动画旋转器,系统会认为它在做重要的事情并保持其活跃状态。 穷人解决方案:Terminal.app 最简单的解决方案也是最明显的:使用Terminal.app。 是的,就是macOS自带的终端。那个看起来自2005年以来没有变过的终端。那个没有GPU加速、连字或任何现代功能的终端。 # 打开Terminal.app并运行 claude 功能完全一样。Claude Code不知道也不关心你从哪个终端运行它。而且Terminal.app: 使用CPU渲染(在Apple Silicon上超级高效) 正确进入App Nap状态 消耗电池的一小部分 性感吗?不。有用吗?完美。 改进解决方案:带配置文件的iTerm2 如果你离不开现代终端,iTerm2有一个Ghostty没有的选项:你可以禁用GPU渲染。 步骤1:创建"电池"配置文件 打开iTerm2 Preferences → Profiles 复制当前配置文件(点击左下角的+按钮,然后选择Duplicate Profile) 将新配置文件命名为**“Battery”** 在Battery配置文件中:Terminal → 取消勾选**“GPU Rendering”** 步骤2:手动切换 当使用电池工作时,只需切换到配置文件: Profiles → Battery(在iTerm2菜单中) 两次点击。你的终端现在像一个负责任的公民一样耗电。 步骤3:自动切换(可选) 如果想要自动切换,将以下内容添加到你的.zshrc或config.fish: # 对于zsh (~/.zshrc) if [[ $(pmset -g batt | grep -c "Battery Power") -gt 0 ]]; then echo -e "\033]50;SetProfile=Battery\a" fi # 对于fish (~/.config/fish/conf.d/iterm_battery.fish) if test (pmset -g batt | grep -c "Battery Power") -gt 0 echo -e "\033]50;SetProfile=Battery\a" end 每次打开新标签页时,iTerm2会检查你是否在使用电池,并自动切换到高效配置文件。 ...

2026年1月24日 · Fernando

线性、Beads 和 Tasks:Claude Code 的三层记忆模型

记忆问题 Claude Code 存在一个问题:它全忘了。如果关闭会话再打开,感觉就像和一个完全陌生的人对话一样。虽然你可以加载 CLAUDE.md 来补充上下文,但未完成的任务怎么办?发现的但未修复的 bug 怎么办?明天的计划呢? 有三种互补解决方案:Linear(或你的产品工具)、Beads(基于 git 的插件)以及 Tasks(Claude Code 内置工具)。不同工具适用于不同时间范围。 Tasks:工作记忆 Tasks 是 Claude Code 的内部系统,用于追踪当前正在做的事情。当你提出复杂要求时,Claude 会自动生成任务列表。 按下 Ctrl+T 查看任务列表: ┌─────────────────────────────────────────────────┐ │ Tasks │ ├─────────────────────────────────────────────────┤ │ ✓ 阅读项目结构 │ │ ● 实现认证端点 │ │ ○ 编写测试代码 │ │ ○ 更新文档 │ └─────────────────────────────────────────────────┘ 特性 自动生成:当任务需要多个步骤时,Claude 会自动创建任务列表 压缩后仍保持持久性:在内容被压缩后任务仍然存在 通过 Ctrl+T 查看:操作简单,任务视图可快速切换 限制为最多10个显示:若需要更多任务显示,可以请求“show me all tasks” 在会话间共享 默认情况下,任务列表会随会话结束而丢失。但你可以让任务持续保存: CLAUDE_CODE_TASK_LIST_ID=qualitra claude 此操作会把任务列表保存到 ~/.claude/tasks/qualitra/ 中。下次使用相同 ID 启动时,可以恢复列表。 使用 Tasks 的场景 场景 Tasks 在一个会话中实现一个功能 ✓ 按定义好的工作计划推进 ✓ 步骤性的 Debugging ✓ 清晰步骤的重构工作 ✓ Tasks 用于执行层面。当你明确知道需要完成什么,只需要辅助工具来进行跟踪。 ...

2026年1月23日 · Fernando

Claude Code中的子代理:授权不失控

无限上下文的困局 假设你让Claude研究项目认证机制。它开始读取文件。大量文件。转眼间上下文已消耗5万token,而这些代码你只需要查阅而非记忆。 响应变慢了。成本增加了。当你想处理其他事务时,这些上下文依然占据着思维空间。 解决方案:子代理。启动专属代理在隔离上下文中处理脏活,返回摘要后自动消失,主会话保持清爽。 何为子代理 子代理是Claude的独立实例,具有以下特性: 专属上下文(不污染主会话) 可限制工具权限(仅读/仅bash等) 可选用不同模型(简单任务用Haiku,复杂任务用Opus) 支持前台(阻塞式)与后台(并行)执行 将其视为专业助理:分配任务后独立工作,完成后汇报结果。 内置子代理 Claude Code预装多个子代理: 代理类型 模型 用途 工具权限 Explore Haiku 代码检索分析 仅读 Plan 继承主模型 规划阶段调研 仅读 general-purpose 继承主模型 复杂多步任务 全权限 Bash 继承主模型 独立环境执行命令 仅Bash Claude Code指南 Haiku 解决Claude Code相关问题 文档查询 其中Explore最实用。当Claude需要检索代码库时,会启动Explore代理疯狂读取文件,处理后仅返回相关部分。 启动子代理 通过REPL(常规对话) 直接使用自然语言指令: 使用子代理研究缓存系统原理 启动Explore代理查找所有API端点 请并行研究认证机制,我继续处理其他任务 Claude能理解这些请求并调用Task工具启动对应子代理。 通过Skill技能 在技能配置中通过context: fork指定隔离执行: --- name: deep-analysis description: 架构深度分析 context: fork agent: Explore --- 进行项目全架构分析 生成包含以下内容的报告: - 目录结构 - 核心依赖项 - 识别到的设计模式 context: fork使技能在子代理运行,agent: Explore指定代理类型。 ...

2026年1月20日 · Fernando

为什么git status会这么慢?

性能问题的觉醒 你在数据科学项目上工作了一段时间。手头有二十多个笔记本文件、几张图片,还有三个月前看起来还不错的文件夹结构。 当你执行git status查看修改时…等待。继续等待。在等待的过程中你甚至怀疑电脑是卡死了还是在冥想。 剧透:它没在冥想。它在煎熬。 问题是有名有姓的 Git本身并不慢。慢的是你的仓库。 执行git status时,git需要做两件看似简单实则不然的事: 扫描整个文件树检查变更 逐个general比较文件与暂存区的差异 普通仓库中这个过程是瞬时的。但Jupyter笔记本本质上是伪装成文档的JSON文件——而且不是普通JSON:它包含了代码、输出结果、base64编码的图片、内核元数据,基本上囊括了设计者能想到的所有内容。 一个包含少量图表的"小型"笔记本可能就有几MB。乘以二十个笔记本,你就得到了一个每次查看都要呻吟的仓库。 如果你还重命名了文件夹…git会理解为"删除了50个文件并新增了50个文件"。保证让你’爽’到极致。 方案一:给仓库装个门卫 第一个解决方案优雅得让人懊恼为什么没早点知道西门庆。 FSMonitor的工作原理:不再让git每次扫描整个仓库,而是由操作系统主动通知哪些文件发生了变化。 说白了:就像是门口有个门卫告诉你"只有老张进来了",而不必每次核对全量宾客名单。 启用方法: git config core.fsmonitor true git config core.untrackedcache true 完成。就这么简单。 初次启用后的第一次西git status可能耗时相当(甚至更长,因为要初始化缓存)。但从第二次开始…魔法降临了。 在我的400+文件仓库中,git status从2- períodos3秒变成了真正的瞬时完成。不是"变快了",是真正的心念电转。 兼容性如何? macOS: 支持,使用FSEvents Linux: 支持,使用inotify(只要内核支持) Windows: 支持,使用ReadDirectoryChangesW 所以说,全平台通用。 方案二坏人保存菜谱而非成品照片 FSMonitor加速了扫描过程,但西存在另一个问题:笔记本文件依然庞大。每次执行单元格并保存时,即使代码相同文件内容也会改变,因为输出结果不同。 这意味着: 不可读的diff(谁想看图片的base64?) 膨胀的commit 地狱级merge 解决方案叫nbstripout,人如其名:在提交前剥离笔记本的输出内容。 这好比保存菜谱但不保存成品照片。代码得以保留,结果可以随时重新生成。 使用uv安装: uv add nbstripout uv run nbstripout --install 或用传统pip: pip install nbstripout nbstripout --install --install参数会自动配置git过滤器。此后提交笔记本时都会自动剥离输出。 验证是否生效: git config --get filter.nbstripout.clean 若返回类似nbstripout Ressource则配置成功。 需要保留输出怎么办? 好问题。有时你需要提交已执行的笔记本,比如用于文档或让他人直接查看。 ...

2026年1月19日 · Fernando

Bun:想要取代 Node 的运行时(现在已经有资金支持了)

谁能想到会有这样的消息 上周,就在你我还在为 node_modules 苦恼不已时,Anthropic 放出了一颗重磅炸弹:他们收购了 Bun。 没错,那家推出 Claude 的公司决定将未来押注在由一位脑洞大开的开发者用 Zig 编写的超快 JavaScript 运行时上。Claude Code 刚刚实现了 10 亿美金的收入,而显然,当你手中资金充裕时,买开发工具成为了一项很重要的投资。 为什么?因为 Claude Code 需要大量地执行 JavaScript,当你拥有数百万用户时,每毫秒的运行效率都至关重要。简单地说,如果你的业务依赖于快速执行代码,那么你当然愿意购买最快的运行时。 但我们先不谈这些商业秘辛,来看看与你息息相关的部分:Bun 是什么,为什么你应该关注它。 什么是 Bun(给来自 Node 的开发者) Bun 就像有人看了整个 Node.js 的生态系统后想了一下:“要是我们能用一个工具替代所有这些东西,如何?” 以前,你可能需要这些工具: node → 运行时 npm/pnpm/yarn → 包管理工具 webpack/esbuild/vite → 打包工具 jest/vitest → 测试运行器 ts-node/tsx → 执行 TypeScript 现在,你只需要: bun → 实现所有上述功能 它就像电动滑板车对比带拖斗的车:部件更少,出错几率更低,甚至运行得更快。 重要的性能数据 虽然我并不太喜欢做 benchmark,因为这些数据总是容易被操纵。但这些数字实在过于震撼,不提鼓动人心都过意不去: 操作 Node + pnpm Bun 差异 install(中型项目) ~25s ~3s 快 8 倍 运行时启动 ~50ms ~5ms 快 10 倍 执行测试 基础速度 快 2-3 倍 显著提升 转译 TypeScript 需要额外工具 原生支持 ∞ 为什么会这么快?因为它是用 Zig 编写的,而不是 C++。而且它的作者 Jarred Sumner 是个以代码优化为业余爱好的人。他以前在 Stripe 工作时,就判断出世界上最重要的问题是 npm install 的速度太慢。 ...

2026年1月18日 · Fernando