先直接上链接。GitHub repo: GitHub - haddock-development/claude-reflect-system: Self-improving skills system for Claude Code - learn from corrections, never repeat mistakes

什么是 Reflect skill ?

核心逻辑是让 AI 在反复的对话过程中，能够 “记住” 你的偏好和纠错，从而实现自我进化相关的其它 Skills。

常见的实现方式？

手动 / 自动

Reflect skill 的简单实例

直接看这个片子。https://youtu.be/-4nUCaMNBR8?si=jIUlnm7KuJ6GXjcQ

里面提到了 Authentication 模块忘了使用 SQL injection。 Reflect skill 可以从当前的 code review skill 的对话里面，抽取相关的纠正，完善 code review。原文提到 corrections the signal。

自动化程度可调节（参考 Github repo)

如何自动化？

自动化的流程是一个 cloud code hooks，在一个对话停止之后，它会自动执行一个 shell 脚本。

此外，这个功能可以打开或者关闭。

有兴趣的佬友帮忙点点 star

项目地址：

原贴地址：[开源自荐] 基于 AI 的股票分析系统

某强大佬友接入微信后的效果反馈

爱你们

Datawhale 开源生态驱动的大模型与 Agent 应用开发工程师全景深度研究报告

第一章 绪论：开源精神下的 AI 工程化教育新范式

1.1 Datawhale 的教育哲学与技术愿景

在人工智能技术以指数级速度迭代的当下，技术知识的半衰期显著缩短，传统的教育体系往往难以跟上工业界的步伐。Datawhale 作为成立于 2018 年的专注于 AI 领域的开源组织，其 “For the Learner” 的核心价值观不仅是一种口号，更是一种应对技术变革的系统性方法论。该组织通过汇聚具备开源与探索精神的理想主义者，构建了一个去中心化、高响应速度的知识生产与传播网络。

对于渴望成为大模型（Large Language Model, LLM）应用开发工程师或智能体（Agent）开发者的学习者而言，Datawhale 提供了一个独特的生态位：它既不完全等同于学术界的纯理论研究，也不同于商业公司的封闭技术栈。Datawhale 的项目矩阵通常呈现出 “元认知” 的特性 —— 不仅教授如何使用工具，更深入工具背后的原理与设计哲学。通过对 Datawhale 开源仓库的全面梳理，我们可以清晰地通过其项目演进看到 AI 工程化范式的转移：从早期的模型训练（Training-centric），过渡到以提示工程（Prompt Engineering）为核心的应用开发，最终演进至 2024-2025 年爆发的智能体（Agentic）系统构建。

1.2 大模型与 Agent 开发者的能力模型重构

本报告旨在为学习者规划一条详尽的进阶路径，该路径严格基于 Datawhale 的开源项目构建，旨在培养具备 “全栈 AI 思维” 的工程师。一个合格的大模型 / Agent 应用开发工程师，其能力图谱已发生根本性重构：

1. 交互层（Interaction Layer）：不再仅限于 GUI 设计，而是转向提示工程（Prompt Engineering）与自然语言交互设计。
2. 编排层（Orchestration Layer）：掌握 LangChain、LlamaIndex 等工具，以及更进阶的 Agent 框架（如 AutoGen、LangGraph、CAMEL）。
3. 认知层（Cognitive Layer）：理解模型推理、规划（Planning）、记忆（Memory）与反思（Reflection）机制。
4. 数据层（Data Layer）：精通 RAG（检索增强生成）架构，管理向量数据库与非结构化知识。
5. 协作层（Collaboration Layer）：构建多智能体系统（Multi-Agent Systems），实现 Agent 间的社会化分工。

本报告将摒弃版本过旧或简单的搬运类项目，聚焦于 Datawhale 生态中具备系统性、原创性及前沿性的核心仓库，规划出一条长达数千小时的深度学习路线。

第二章 认知基石：提示工程与大模型应用开发初探

任何复杂的 Agent 系统，其原子单元皆为单次的大模型调用。因此，理解如何与模型高效沟通，即 “提示工程”，是所有后续开发的基石。Datawhale 在此领域提供了两套互补的 “教材”，分别侧重于交互逻辑与工程落地。

2.1 交互逻辑重塑：面向开发者的 LLM 入门教程

• 项目核心标识：llm-cookbook
• GitHub 地址：GitHub - datawhalechina/llm-cookbook: 面向开发者的 LLM 入门教程，吴恩达大模型系列课程中文版 1

该项目是吴恩达（Andrew Ng）与 OpenAI 合作推出的系列课程的中文版。Datawhale 团队不仅进行了翻译，更针对中英文模型在理解 Prompt 时的细微差异进行了大量的 “本地化” 调优。这使得该项目成为了解 LLM 思维方式的最佳起点。

2.1.1 提示工程的核心原则与迭代范式

在这一模块中，学习者将深入探究控制大模型输出质量的底层逻辑。这并非简单的 “说话技巧”，而是一种编程思维。

• 原则一：清晰具体的指令（Clear and Specific Instructions）。这不仅仅意味着 “把话说清楚”，更涉及到结构化思维。学习者需掌握使用分隔符（Delimiters）来隔离指令与数据，防止提示注入攻击；利用结构化输出（如 JSON、HTML）来强迫模型生成可被代码解析的响应。项目中展示的通过系统消息（System Message）设定角色（Persona）的技巧，是后续构建 Agent “人设” 的雏形。
• 原则二：给予思考的时间（Give the Model Time to Think）。这是链式思维（Chain of Thought, CoT）的早期形态。学习者将通过实战案例理解，为何在要求模型输出最终答案前，强制其列出计算步骤或推理过程，能显著降低 “幻觉”（Hallucination）率。这揭示了 LLM 作为自回归模型，其生成的每一个 Token 都在为下一个 Token 提供上下文的本质。
• 迭代开发（Iterative Development）。Prompt 开发绝非一蹴而就。本项目强调 “Idea → Prompt → Error Analysis → Refined Prompt” 的闭环。学习者将学会如何建立测试用例，量化评估 Prompt 的表现，这种工程化思维是将 Prompt 从 “玄学” 变为 “科学” 的关键。

2.1.2 系统级应用的构建逻辑

从单一 Prompt 进阶到系统构建，项目涵盖了 Building Systems with the ChatGPT API 的核心内容。

• 输入监控与分类：在真实应用中，用户输入是不可控的。学习者将学习使用 Moderation API 进行内容审查，并构建分类 Prompt 来识别用户意图（Intent Recognition），这是 Agent 中 “路由（Routing）” 模块的前身。
• 多轮对话管理：LLM 本身是无状态的（Stateless）。项目详细解析了如何通过手动维护 messages 列表来构建对话历史（History），以及如何处理上下文窗口限制，为后续理解 Agent 的 Memory 模块打下基础。

2.1.3 LangChain 框架的原理解析

虽然 Datawhale 有更复杂的 Agent 教程，但 llm-cookbook 中关于 LangChain 的章节提供了最纯粹的原理解读。

• Chains（链）：学习者将理解如何将多个 LLM 调用串联（Sequential Chain），实现 “先总结评论，再撰写回复” 的流水线逻辑。
• Document Loading 与 Splitting：初步接触非结构化数据处理，理解为何需要将长文档切片，以及重叠（Overlap）参数对上下文连贯性的影响。

2.2 全栈工程落地：动手学大模型应用开发

• 项目核心标识：llm-universe
• GitHub 地址：GitHub - datawhalechina/llm-universe: 本项目是一个面向小白开发者的大模型应用开发教程，在线阅读地址：https://datawhalechina.github.io/llm-universe/ 3

如果说 llm-cookbook 是注重理论的 “计算机科学导论”，那么 llm-universe 就是注重实操的 “软件工程实验课”。该项目致力于帮助小白开发者从零开始构建一个完整的、可部署的个人知识库助手。

2.2.1 多源异构 API 的统一封装

在实际的国内开发环境中，开发者往往面临 OpenAI 访问受限或成本过高的问题。llm-universe 的一个核心贡献是提供了一套统一的接口设计模式，涵盖了百度文心（Ernie）、讯飞星火（Spark）、智谱 AI（ZhipuAI）等主流国产大模型。

• 适配器模式应用：学习者通过阅读源码，将深入理解如何继承 LangChain 的 LLM 基类，将不同厂商的 SDK（如 zhipuai、dashscope）封装为统一的_call 接口。这种能力对于企业级应用中实现 “模型热切换” 至关重要，也是构建模型无关（Model-Agnostic）Agent 框架的前提。

2.2.2 检索增强生成（RAG）的端到端实现

RAG 是目前解决大模型知识截止和私有数据访问最成熟的技术方案。本项目通过由浅入深的实战，剖析了 RAG 的每一个环节。

• 数据清洗与向量化：项目详细介绍了如何处理 PDF、Markdown 等格式的文档。学习者将亲手实践使用 Embedding 模型（如 OpenAI Embedding 或 HuggingFace 开源模型）将文本转化为高维向量。
• 向量数据库实战：不仅涵盖了轻量级的 Chroma，也涉及了生产级的 Milvus。学习者将掌握向量存储（Vector Store）的构建、持久化以及基于余弦相似度（Cosine Similarity）的检索逻辑。
• Prompt 模板注入：如何将检索到的 Top-K 片段优雅地嵌入到 Prompt 中，并提示模型 “仅根据已知信息回答”，是减少幻觉的关键。项目中的 Prompt 模板设计经过了大量验证，极具参考价值。

2.2.3 前端交互与 Web 部署

为了完成工程闭环，项目引入了 Streamlit 框架。学习者不再停留于 Jupyter Notebook 的黑底白字，而是能够快速构建具备侧边栏配置、聊天气泡界面的 Web 应用。这对于展示 Agent Demo、进行用户测试（User Testing）具有重要意义。

第三章 理论深潜：Transformer 架构与模型微调原理

在掌握了 API 调用与基础应用开发后，真正的专家级工程师必须具备 “打开黑盒” 的能力。理解 Transformer 架构、训练过程及微调（Fine-tuning）原理，是优化复杂 Prompt、调试模型异常表现以及进行私有化部署的前提。

3.1 深度解析 Transformer：HuggingLLM（蝴蝶书）

• 项目核心标识：hugging-llm
• GitHub 地址：GitHub - datawhalechina/hugging-llm: HuggingLLM, Hugging Future. 5

此项目被称为 “蝴蝶书”，意在阐述微小的代码变动可能引发的模型行为的巨大蝴蝶效应。它连接了深度学习理论与 Hugging Face 开源生态。

3.1.1 自然语言处理（NLP）范式的演进

学习者将通过该项目，梳理 NLP 从 RNN/LSTM 到 Transformer 的范式转移。

• Attention Is All You Need：项目对 Transformer 论文进行了逐行代码级的复现与解析。学习者需深刻理解 Self-Attention（自注意力机制）如何解决长距离依赖问题，以及 Positional Encoding（位置编码）如何赋予模型序列感。
• BERT vs GPT：对比 Encoder-only（BERT）、Encoder-Decoder（T5）与 Decoder-only（GPT）架构的优劣。理解为何生成式任务最终收敛于 Decoder-only 架构，这对于理解当前主流大模型（如 Llama, Qwen）的结构至关重要。

3.1.2 Hugging Face 生态与开源模型实战

Hugging Face 已成为 AI 领域的 GitHub。本项目手把手教导如何利用 transformers 库加载开源模型。

• Tokenizer 的奥秘：学习者将发现，Tokenizer 不仅仅是分词，更涉及到词表（Vocabulary）构建、特殊 Token（如 <|endoftext|>）的处理。不同模型的 Tokenizer 实现差异（如 SentencePiece vs Byte-Pair Encoding）直接影响 Prompt 的 Token 计算与上下文窗口利用率。
• Pipeline 与 Model Head：掌握如何根据任务（文本分类、生成、命名实体识别）选择不同的 Model Head，这对于需要结合传统 NLP 任务与 LLM 能力的复合型 Agent 系统非常有用。

3.2 训练与对齐机制：Happy-LLM

• 项目核心标识：happy-llm
• GitHub 地址：GitHub - datawhalechina/happy-llm: 📚 从零开始的大语言模型原理与实践教程 7

该项目从更加底层的视角，剖析了大模型全生命周期的训练过程。

3.2.1 从预训练到指令微调

• Pre-training（预训练）：理解模型如何通过海量文本的自监督学习获得世界知识。
• Instruction Tuning（指令微调 / SFT）：这是让模型听懂人话的关键。项目展示了如何构建 <Instruction, Input, Output> 格式的数据集，将预训练模型转化为 Chat 模型。这对于开发者想要在特定垂直领域（如医疗、法律）微调模型以获得更好表现极具指导意义。

3.2.2 RLHF 与人类价值观对齐

Reinforcement Learning from Human Feedback（RLHF）是大模型安全性的核心。虽然大多数应用开发者不需要亲自进行 RLHF，但理解其原理（奖励模型 Reward Model、PPO 算法）有助于理解模型为何会拒绝某些请求，以及如何通过 Prompt 设计规避过度的防御机制。

第四章 智能体元年：Agent 架构与开发实战

2024 年与 2025 年被普遍认为是 “Agent 元年”。大模型的能力焦点从单纯的文本生成（Chatbot）转移到了具备自主感知、规划、工具使用能力的智能体（Agent）。Datawhale 的 hello-agents 项目是目前开源社区中最系统、最前沿的 Agent 学习资料，是本报告的核心推荐内容。

4.1 智能体通识与核心范式：Hello-Agents（Part I & II）

• 项目核心标识：hello-agents
• GitHub 地址：GitHub - datawhalechina/hello-agents: 📚 《从零开始构建智能体》—— 从零开始的智能体原理与实践教程 8

该项目立意高远，旨在培养 “AI Native” 的 Agent 开发者。它不仅介绍了如何使用工具，更从第一性原理出发，探讨 Agent 的本质。

4.1.1 智能体的定义与演进

学习者首先需要建立对 Agent 的科学认知。

• 从 Copilot 到 Agent：明确区分辅助驾驶（Copilot，人主导，AI 辅助）与智能体（Agent，AI 主导，人监督）的边界。
• 演进史：项目梳理了从符号主义 Agent（Symbolic Agent）到强化学习 Agent（RL Agent），再到如今基于 LLM 的 Agent 的演变路径。理解这一历史，有助于明白当前 LLM Agent 虽然在通用性上通过了图灵测试，但在长期规划和确定性执行上仍存在挑战。

4.1.2 经典 Agent 范式的代码级复现

在这一部分，hello-agents 展现了极高的教学价值：它拒绝直接使用封装好的框架，而是引导学习者用原生 Python 复现经典论文。

• ReAct (Reasoning + Acting)：这是当前 Agent 最主流的范式。学习者将亲手编写一个 While 循环，模拟 “Thought（思考） → Action（行动） → Observation（观察）” 的过程。通过解析模型输出的字符串，提取工具调用指令，执行工具函数，并将结果拼接到 Prompt 中进入下一轮循环。这种 “手搓 ReAct” 的经历，能让开发者对 Agent 的 Token 消耗、延迟来源及错误恢复机制有刻骨铭心的理解。
• Plan-and-Solve：针对 ReAct 在复杂长链条任务中容易跑偏的问题，学习者将实现 “先规划，后执行” 的范式。即让模型先生成完整的 Step-by-Step 计划，再逐一执行。
• Reflection（反思）：学习如何构建一个 “双我” 系统，即一个 Agent 负责生成，另一个 Agent 负责批评（Critique）和建议，从而实现自我进化。这在代码生成（Self-Debugging）任务中尤为重要。

4.2 打造自主可控的框架：HelloAgents Framework

• 项目章节：hello-agents 第七章 8

在掌握了原理后，Datawhale 鼓励学习者造一个属于自己的轮子。这一章指导学习者构建名为 HelloAgents 的轻量级框架。

4.2.1 框架设计哲学与架构

• 组件解耦：学习者将设计 Agent 基类、ToolRegistry（工具注册表）、Memory（记忆模块）等核心组件。
• 统一接口：为了兼容 OpenAI、Anthropic 及本地模型，需要设计统一的 LLM 适配层。
• 消息路由：设计高效的消息传递机制，确保 System Message、User Message 和 Tool Output 能在多轮对话中正确拼接，不丢失上下文。

4.2.2 高级工具系统的实现

• 工具链管理：实现工具的自动发现与注册。学习者将学习如何利用 Python 的装饰器（Decorator）将普通函数转化为带有 JSON Schema 描述的 Agent 工具。
• 多源搜索聚合：实战开发一个聚合了 Tavily（AI 专用搜索）、SerpApi（Google 搜索）的超级搜索工具，并实现故障转移（Failover）机制。

第五章 进阶工程：多智能体协作与复杂社会模拟

当单一 Agent 受限于上下文窗口或能力瓶颈无法解决复杂问题时，多智能体系统（Multi-Agent Systems, MAS）应运而生。Datawhale 通过 handy-multi-agent 和 hello-agents 的高级章节，深入探索了这一前沿领域。

5.1 多智能体协作框架：Handy Multi-Agent

• 项目核心标识：handy-multi-agent
• GitHub 地址：GitHub - datawhalechina/handy-multi-agent: This is a multi agent tutorial based on the CAMEL framework, aimed at understanding how to build an Agent Society from the ground up! 10

该项目基于 CAMEL（Communicative Agents for “Mind” Exploration of Large Scale Language Model Society）框架，重点展示了 Agent 社会的构建。

5.1.1 角色扮演（Role-Playing）与 Inception Prompting

CAMEL 框架的核心创新在于 “角色扮演”。

• Inception Prompting：学习者将深入研究这种特殊的 Prompt 技术，它在对话开始前对两个 Agent（如 “Python 程序员” 和 “股票交易员”）进行深度催眠，设定其职责、禁忌和交互协议，从而实现全自动的对话推进，无需人类作为中间人。
• 任务特化（Task Specialization）：通过案例（如 “开发一个交易机器人”），观察两个 Agent 如何通过不断的指令下达与代码交付，逐步逼近任务目标。

5.1.2 异构 Agent 社会的构建

• Agent Society：项目展示了如何不仅限于两个 Agent，而是构建一个包含多种角色的 “社会”。学习者将理解在这种网络拓扑中，信息如何流动，以及如何避免死循环对话。

5.2 主流框架横向评测与实战：Hello-Agents（Part II Advanced）

除了自研框架和 CAMEL，hello-agents 还深入剖析了工业界主流框架。

5.2.1 AutoGen 的对话式编程

微软推出的 AutoGen 是目前最火的框架之一。

• UserProxyAgent：学习者需掌握这一特殊 Agent 的使用，它充当人类代理，可以在代码执行前请求人类批准，通过 Docker 沙箱安全执行代码。
• GroupChat 与 Manager：理解 AutoGen 如何通过一个 “群聊管理员” 来动态选择下一个发言的 Agent，这对于构建非线性协作流程（如头脑风暴）至关重要。

5.2.2 LangGraph 的图论编排

LangGraph 代表了 Agent 编排的另一方向 —— 基于图（Graph）。

• Cyclic Flows（有环流）：不同于传统的 DAG（有向无环图），LangGraph 原生支持循环。这对于实现 ReAct 循环或长周期的 Human-in-the-loop 流程非常自然。学习者将学习定义 Nodes（节点）和 Edges（边），构建状态机。

5.3 跨平台轻量级方案：Wow-Agent

• 项目核心标识：wow-agent
• GitHub 地址：GitHub - datawhalechina/wow-agent: A simple and trans-platform agent framework and tutorial 12

作为一个更轻量级的选择，wow-agent 提供了一个跨平台的视角。其中的 Zigent 模块展示了极简主义的 Agent 设计。学习者可以对比其与庞大的 LangChain/AutoGen 的差异，理解在资源受限或需要快速原型开发时如何取舍。

第六章 综合应用：RAG 进阶与 Agent 生态互联

在掌握了单个和多个 Agent 的构建后，最后阶段将聚焦于数据的深度利用与生态互联，这是构建具备商业价值应用的关键。

6.1 下一代检索增强：Wow-RAG

• 项目核心标识：wow-rag
• GitHub 地址：GitHub - datawhalechina/wow-rag: A simple and trans-platform rag framework and tutorial 13

基础的 RAG（如 llm-universe 中所述）往往面临检索精度不足、多跳推理困难的问题。wow-rag 聚焦于 Advanced RAG 技术。

6.1.1 混合检索与重排序（Rerank）

• Hybrid Search：学习者将实践结合关键词检索（BM25，擅长精确匹配）与向量检索（Embedding，擅长语义匹配）的策略，以提高召回率（Recall）。
• Rerank 模型：在检索回 Top-50 文档后，使用专门的 Cross-Encoder 模型（如 BGE-Reranker）进行精细排序，筛选出 Top-5 给 LLM。这是提升 RAG 系统准确率（Precision）性价比最高的手段。

6.1.2 GraphRAG 与知识图谱

项目触及了最前沿的 GraphRAG 技术。利用知识图谱（Knowledge Graph）捕捉实体间的关系，解决 “跨文档推理” 难题。学习者将了解如何将非结构化文本转化为图谱，并利用图算法增强检索上下文。

6.2 基础设施支持：Easy-VectorDB

• 项目核心标识：easy-vectordb
• GitHub 地址：GitHub - datawhalechina/easy-vectordb: 📚 从零开始的向量数据库原理与实践教程，在线阅读地址：https://datawhalechina.github.io/easy-vectordb/ 15

为了支持上述 RAG 系统，对向量数据库的深入理解不可或缺。该项目专注于向量数据库的原理与实践，填补了数据库层面的认知空白，是构建大规模知识库 Agent 的基石。

6.3 毕业设计与未来展望：Hello-Agents（Part IV & V）

• 项目章节：hello-agents 第 13-16 章 8

学习的终点是创造。本部分提供了多个企业级复杂度的案例，涵盖了当前最热门的应用方向。

6.3.1 智能旅行助手：MCP 协议实战

• 案例详解：构建一个包含景点搜索、天气查询、酒店推荐、行程规划四个 Agent 的协作系统。
• Model Context Protocol (MCP)：这是 Anthropic 等巨头推动的下一代标准。学习者将实战如何使用 MCP 协议，标准化 Agent 与外部数据源（如高德地图 API、Unsplash 图片库）的连接。掌握 MCP 意味着开发的 Agent 天然具备跨平台互操作性。

6.3.2 自动化深度研究 Agent (Deep Research)

• 案例详解：复现类似 OpenAI Deep Research 的功能。
• 递归任务分解：学习如何让 Agent 自主进行长周期的互联网探索。它需要自己提出搜索关键词，阅读网页，判断信息是否足够，如果不足则生成新的关键词继续搜索（递归），最后阅读数十个网页并生成万字长文报告。这考验了 Agent 的显存管理、长上下文处理及逻辑一致性。

6.3.3 赛博小镇 (Cyber Town) 社会模拟

• 案例详解：基于斯坦福 “Generative Agents” 论文，构建一个包含多个 NPC 的虚拟小镇。
• 记忆流（Memory Stream）：这是本案例的核心。学习者将实现包含 “感知、记忆检索、反思、规划” 的完整认知架构。观察 NPC 之间如何涌现出八卦传播、选举拉票等社会行为。

6.3.4 毕业设计：从 Idea 到开源

最后，学习者需完成一个完整的开源项目。hello-agents 提供了详细的指南，包括选题（如代码审查 Agent、数据分析师）、项目结构规范（src, tests, docs）、以及如何撰写 requirements.txt 和 README.md。这不仅是技术的总结，更是开源礼仪与工程规范的实战。

第七章 总结与学习路径规划表

7.1 学习路径总览表

7.2 给学习者的最后建议

Datawhale 的开源项目群构建了一座宏大的 “AI 工程学院”。从掌握 Prompt 这一原子能力，到构建复杂的 Agent 社会，这条路径既漫长又充满挑战。

1. 代码至上：切勿止步于阅读文档。务必 Clone 每一个仓库，运行每一个 Jupyter Notebook。Agent 的许多微妙之处（如 Prompt 的微小差异导致的执行失败）只有在 Debug 中才能体会。
2. 关注数据流：在学习多智能体系统时，时刻关注 “消息（Message）” 是如何在 Agent 之间流转的。消息即 Agent 的血液。
3. 拥抱开源：Datawhale 的核心是 “和学习者一起成长”。在学习过程中，如果发现代码过时或有 Bug，请积极提交 Issue 或 PR。这不仅是对社区的回馈，也是证明你已从 “Learner” 成长为 “Builder” 的最佳勋章。

愿这份基于 Datawhale 生态的详尽报告，能成为你在大模型与智能体开发之路上最坚实的导航图。

附录：引用项目清单

• 1 llm-cookbook: GitHub - datawhalechina/llm-cookbook: 面向开发者的 LLM 入门教程，吴恩达大模型系列课程中文版
• 3 llm-universe: GitHub - datawhalechina/llm-universe: 本项目是一个面向小白开发者的大模型应用开发教程，在线阅读地址：https://datawhalechina.github.io/llm-universe/
• 5 hugging-llm: GitHub - datawhalechina/hugging-llm: HuggingLLM, Hugging Future.
• 7 happy-llm: GitHub - datawhalechina/happy-llm: 📚 从零开始的大语言模型原理与实践教程
• 8 hello-agents: GitHub - datawhalechina/hello-agents: 📚 《从零开始构建智能体》—— 从零开始的智能体原理与实践教程
• 10 handy-multi-agent: GitHub - datawhalechina/handy-multi-agent: This is a multi agent tutorial based on the CAMEL framework, aimed at understanding how to build an Agent Society from the ground up!
• 12 wow-agent: GitHub - datawhalechina/wow-agent: A simple and trans-platform agent framework and tutorial
• 13 wow-rag: GitHub - datawhalechina/wow-rag: A simple and trans-platform rag framework and tutorial
• 15 easy-vectordb: GitHub - datawhalechina/easy-vectordb: 📚 从零开始的向量数据库原理与实践教程，在线阅读地址：https://datawhalechina.github.io/easy-vectordb/

1月11日，供应链知情人士透露，闪迪已向部分下游客户提出了一项被业界称为“前所未闻”的供应合同：要求客户支付100%现金预付款，以锁定未来1至3年的存储芯片配额。

通常情况下，半导体供应链合作多采用分期付款或信用账期模式，闪迪此次推出的“100%全额预付”制度彻底打破了行业惯例，对买方的现金流提出了极端挑战。

尽管条款极为严苛，但在AI基础设施建设对存储设备产生“刚性需求”的背景下，部分急需扩充算力的云服务供应商不得不考虑接受这一条款。

此外，闪迪也将此类合同谈判范围扩大到了PC、智能手机及模组厂商。

除了付款方式上的强硬，野村证券在最新的客户报告中明确指出：“闪迪用于企业级SSD的NAND报价，在3月份期间可能环比上涨超过100%。”

目前尚不清楚企业级产品价格翻倍将在多大程度上波及消费级市场，但野村证券警告称，由于智能手机和PC使用的3D NAND与企业级芯片产自同一晶圆厂，通常情况下，消费级产品价格会跟随企业级产品上涨。

我推荐的食用方法：
根据 PPT/PDF 生成对应的思维导图 & 闪卡 & 测验
具体步骤为
1，先根据思维导图进行学习，不会的就点击思维导图的某个部分
2，然后再利用闪卡巩固记忆
3，在纸上记一下重点内容，消化吸收
4，做一下测验，完成最后的验收
过程大约半个小时，可以保证知识 90~100%（因人而异，我基本是 100%）的掌握
至少生物是这样的

RT

其实我很疑惑为什么死了么火了这个反而没火。

还是悲伤的故事

很早前就遇到 feadback-mcp 失败的问题了
也测试了大佬们的三术和寸止好像都会出现问题
不知道是我配置的问题，还是什么原因，猜测可能是 wf 对 mcp 工具的描述进行了检测？
所以我 fork 项目给提示词都换成 "变形金刚" 了，好家伙，现在我是可以正常用了，佬友们也可以试试看艾

sso_tokens.txt
可搭配 grok2api 使用

RenewHelper 迎来发布以来最大规模的升级 ——v2.0 版本。

除了完善的多渠道通知提醒以外，本次更新重构了核心逻辑，引入了多币种汇率自动换算、支出趋势分析、历史账单管理。无论你是管理几台 VPS，还是几十个订阅，v2.0 都能让你对每一笔数字支出如指掌。

v2.0 核心亮点：三大维度升级

1. 财务看板：钱花在哪里，一目了然

v2.0 不再只是告诉你 “什么时候过期”，而是告诉你 “花了多少钱”。

• 多币种自动汇率换算

• 功能：支持 USD, CNY, EUR, GBP 等主流货币。系统接入了免费的汇率 Frankfurter API（该 API 服务也支持用户自建），并利用 KV 缓存机制优化性能，每天自动更新汇率。

• 体验：你购买的是美元支付的服务器，是日元支付的游戏会员？没问题。系统会自动将它们换算为你设置的 “默认币种”（如 CNY），并统计总资产规模。

• 双模式支出分析 (Dashboard)

• 点击首页的 “视图切换” (View Switch) → “支出分析”，你将看到全新的可视化图表。

• 账单金额模式 (Bill Amount)：按服务的订阅周期统计，包含开启了自动续费的未来预测账单统计，适合做预算规划。

• 实际支出模式 (Actual Cost)：按你实际付款的操作日期统计，适合查看每月的现金流压力。

• 交互式图表：支持查看 “月度趋势” 曲线、“月度平均支出” 和 “年度汇总” 柱状图，也可以点击某个月份查看当月的详细消费明细。

2. 账单管理：全生命周期记录

以前的版本只记录 “下一次到期日”，v2.0 开始记录每一次 “续费历史”。

• 完整的续费历史 (Renewal History)

• 现在，你可以为每一个服务记录无限条历史账单。

• 补录功能：老用户的福音。点击服务菜单中的 “历史记录” → “+”，可以补录过去几年的续费记录，系统会自动计算历史总花费。

• 智能续费：点击 “手动续期” 时，系统会自动根据你的周期设置（如：月付、年付、农历周期）预填充开始和结束日期，并自动填入价格。

• 未来账单预测 (Upcoming Bills)

• 左上角的 铃铛图标 变得更聪明了。

• 它不仅显示即将到期的服务，还会根据你的 “自动续期” 设置，预测未来 N 天内需要支付的金额总和。

• 自定义阈值：你可以在设置中调整 “待付款提醒天数”（默认为 7 天），提前规划资金。

3. 体验与部署：更自由，更强大

• 高级筛选器 (Smart Filters)
• 服务太多找不到？v2.0 增加了强大的筛选栏。
• 按状态：已过期、n 天内到期、30 天内到期。
• 按稳定性：新服务 (<30 天)、长期服务 (>1 年)。
• 按标签：点击标签即可快速聚合查看。
• 自动更新：支持 Watchtower，镜像更新后自动拉取，保持最新，懒人福音。
• 自定义通知标题：现在的推送通知（Telegram, PushPlus 等）支持自定义标题。你可以把它改为 “我的财务日报” 或任何你喜欢的名字，让提醒更具个性化。

v2.0 快速上手教程

如果你是新用户且想一次部署并保持更新建议按 README 中，方式三：GitHub Actions 部署并启用 sync 上游同步（注意必须设置完 secrets 才会部署成功）。

场景一：从 v1.x 升级与数据迁移

如果你是老用户，更新代码后，可能会发现很多项目没有历史账单数据。

1. 部署新代码：将 _worker.js 替换为 v2.0.20 版本。
2. 数据迁移工具：

• 进入 设置 (Settings) → 数据管理。
• 点击 “升级旧数据 (Migrate Old Data)”。
• 作用：系统会自动扫描所有旧项目，根据它们当前的 “上次续费时间” 和 “周期”，自动生成一条初始的账单记录。这能让你立刻看到财务统计数据，而无需手动一个个添加。（除了手动操作，系统也每日会自动扫描并提醒一次）

场景二：如何记账？

假设你刚续费了一台年付 $50 的 VPS。

1. 在列表中找到该 VPS，点击 “手动续期” (Renew) 按钮。
2. 系统会弹出对话框：

• 续费日期：自动填入今天。
• 账单周期：自动根据去年的结束日期往后推算一年（例如 到 ），无需手动计算。
• 金额：自动填入预设的 $50（你也可以根据实际修改金额）。

3. 点击 “确认”。
4. 结果：服务的 “到期日” 自动更新，同时在后台生成了一笔历史账单。你的 “支出分析” 看板中，今年的支出会自动增加 $50（对应的汇率换算金额）。

场景三：查看 “我今年在订阅上花了多少钱？”

1. 点击主界面右上方的 “视图切换”，选择 “支出分析”。
2. 在右侧的 “年度汇总” 区域，你将看到本年度的总支出柱状图。
3. 点击 “2026” 柱状条，左侧的趋势图将展示 2026 年每个月的消费分布。
4. 看一眼左上角的数字，那就是你今年的 “订阅总账单”。

Docker 部署指南 (支持自动更新)

对于不想依赖 Cloudflare Workers 的用户，现在可以直接使用 Docker compose 部署：

services:
  renewhelper:
    image: ieax/renewhelper:latest
    container_name: renewhelper
    restart: unless-stopped
    ports:
      - "9787:9787"
    volumes:
      - ./data:/data
    environment:
      # 1. 设置登录密码
      - AUTH_PASSWORD=admin
      
      # 2. 设置 Cron 定时任务 (Cron 表达式)
      - CRON_SCHEDULE=0,30 * * * *
      
      # 3. 容器时区 (影响日志和本地时间计算)
      - TZ=Asia/Shanghai

  # 若需自动更新保留以下watchtower配置
  watchtower:
    image: containrrr/watchtower
    container_name: watchtower
    restart: unless-stopped
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    command: --interval 86400 --cleanup
    environment:
      - TZ=Asia/Shanghai

• 数据持久化：建议挂载 /app/data 目录以保存 KV 数据。
• 多架构支持：镜像支持 amd64 和 arm64。

结语

RenewHelper v2.0 不仅仅是一个记录工具，它试图解决的是数字时代的 “订阅焦虑”。通过自动化的计算、清晰的图表和精准的提醒，它让你从被动的 “等待扣费”，变为主动的 “财务掌控”。

立即升级，开启你的订阅资产管理 2.0 时代！

项目地址: GitHub - RenewHelper
演示站地址：https://lostfree.de5.net
演示站密码：demo
演示站千万不要保存你推送渠道的各种 TOKEN 和 API KEY！！！
代码完全开源，MIT 协议。
如果觉得好用，求大佬们给个 Star 支持一下！
有 Bug 或建议欢迎提 Issue 或在楼里反馈。

这是一款通过 Vibe Coding 完成的项目。想法来源于在做毕设的时候迭代我自己项目里的提示词，然后辗转 Gemini 和 GPT 复制修改，感觉非常的不方便，所以冒出了这个项目开发的想法。
论坛里也看到有佬友实现 / 开源了，但是似乎后续也没有跟进，目前我这个项目应该至少会在近半年以内跟进更新一些需要的功能。以及现在 V1.0 也是还有一些功能没实现，近段时间会先慢慢补全。
项目链接～
具体的操作流程：
config/providers.example.yaml 内配置好 API 和 URL（目前只支持 OPENAI 格式，也是有待继续开发）之后删除.example 即可使用
设置栏里可以自行配置增加模型，也可以修改提示词
后端使用 FastAPI，端口默认 8000，配备了启动脚本，会默认清理一些端口，如果有需要避免的问题可以自行修改。
欢迎大家提 issue 和 pr~ 有什么问题也欢迎在评论区指出～
以下是效果展示：

很多佬友都想购买一个心仪的服务器，但是市面上太多了，不知道该如何下手，我就来简单推荐一些各个地区常见的线路机器 / 落地机器 / 家宽机器，包含 MJJ 常用的主流机器和评价不错的服务商，你可以通过这个来简单筛选适合自己的机器

• 线路机器：拥有 CN 大陆方向的优化线路机器，延时低稳定性高
• 落地机器：国际互连优秀 / 流媒体解锁优秀的机器，注意：落地适合与否和 ip 质量并无关系
• 家宽机器：IP 质量优秀的机器，不容易被风控

叠个甲：一般说不要轻易随便给别人推荐机器，因为大家的本地网络情况大不相同，有些地区舒服的机器有些地区就是不行，这个没什么办法，网络实在是太复杂，所以这个推荐你可以看成是一个概率推荐，即最有可能最多人满意的机器，本推荐也会着重说明机器的缺点而不是优点，因为优点总是能找到的，但缺点往往是致命的、可以影响决策的。VPS 信息繁琐，这个推荐注定是要多次修改的，也欢迎大家指出问题分享体验，常看常新～

本文无 AFF，有必要说明的是：建站机器的推荐将会缺失，因为我真的不玩建站机器，什么斯巴达 /ovh/netcup 都用的不多，就不强行推荐了。当然了，如果你不知道线路 /ip 质量，或许你可以看看常见线路的科普和 IP 质量检测方法。

本文最后更新于 2026/1/11，测评与推荐结果在此日期附近有较强参考性，原文链接。

HK (香港)

HK 因为常年被 ddos 攻击，线路质量非常不稳定，防御成本高昂，绝大部分商家的 HK 线路机器都是搞的一地鸡毛，最后只剩下几家高端机器，HK 廉价线路机器基本不存在了 (除了小口子 10Mbps 这种)，电信联通基本没有便宜的 HK 机器了，移动还能玩玩一些移动快乐机。不过作为亚太的中转核心，有需要的还是有必要买一台强力的 HK 线路机，拉 TW/SG 都是很好的选择。

线路机器

Gomami (狗妈咪)

三网各自顶级优化 (CTGGIA/9929/CMIN2) 的 HK 线路机器，单线程轻松稳定 500Mbps + 甚至 1Gbps (移动上行 qos 严重伴随断流，下行正常)，国际互连优秀；ip 质量还不错，流媒体基本解锁，完全可以直出；机器性能非常强劲，恐怖如斯。毫无疑问，如果你能接受它的价格，它就是 HK 的顶端机器。

缺点：移动上行低 (直播等需要大量上传的移动用户慎选)

常见产品线：

• HKG.Turin.Mini：2C4G 100GB 1T 单向 / 月 2Gbps 69 刀 / 月
• HKG.Pulse.Mini：2C4G 40GB 1T 单向 / 月 1Gbps 49 刀 / 月

Gomami 详细测评

Neburst (奶爸)

三网各自优化 (高 q163/10099/CMIN2) 的 HK 线路商家，电信联通的表现都相当优秀，上下行单线程都有稳定 500Mbps+，但移动去程主干 CMI 表现相当一般，非晚高峰都 q 的厉害，长时间上行都达不到 100Mbps 还伴随断流，不适合需要上传 (直播) 的用户，回程 CMIN2 倒是极致，随便跑到 500Mbps+；ip 质量不错，直出完全够用无需落地，国际互联也很强力；7Y43 的 CPU 性能不错，较为强劲，大部分应用都能满足了。相比起 Gomami 而言，这个机器相当便宜起步价低。

缺点：移动上行低 (直播等需要大量上传的移动用户慎选)

常见产品线：

• Hong Kong (HKG)：1C1G 20GB 500GB (单向)/ 月 55.92 刀 / 季

Neburst 详细测评

DMIT (大妈)

三网 CN2GIA 优化，电信用户很舒适，联通移动也不错 (虽然二者面临跨网延时会偏高)，单线程电信用户可以跑到 300-500Mbps，联通 300Mbps+，移动也有 300-500Mbps+，速度都是比较极致的；ip 质量不错，直出完全够用无需额外落地，国际互联比较不错；机器性能较为强劲，绝大部分应用可以满足。

缺点：联通移动跨网延时可能会略微升高 + 近期被 ddos 攻击导致不稳定

常见产品线：

• HKG.Pro.Victoria (维多利亚)：1C2G 60G 800G (双向)/ 月 298.88 刀 / 年

DMIT 详细测评

RFCHOST (花卷科技)

三网各自优化 (高 q163/10099/CMI) 的 HK 线路商家，电信相当极致，晚高峰单线程上下行 500Mbps，联通去程部分地区 (济南) 拉跨，多次测试都卡在 100Mbps，回程 400Mbps 很极致，其他地区不错，移动少部分地区拉跨 (哈尔滨 / 沈阳 / 大连 / 天津)，其他地区很极致，单线程有 500Mbps，广移都有 300Mbps；ip 质量中规中矩，该解锁的都解锁；机器性能较差。

缺点：移动部分地区爆炸 + 部分地区联通上传拉跨 + 性能较差 (不是建站的选择)+ 经常被 ddos 攻击导致不稳定

常见产品线：

• HK-CO-Mini：1C1G 15GB 1.5T (双向)/ 月 18.9 刀 / 月

RFC 详细测评

ISIF

ISIF 的 HK 拥有两款产品线，COM (CN2/9929/CMIN2) 和 COP (高 q163/10099/CMIN2) 系列，前者对标高端机，后者对标中端机，由于这家的详细测评并没有完成，所以此处先不评价具体到某个运营商的情况，机器已在测试中，具体情况后补。

不主流但值得一看的产品

• VMISS 的 CN.HK.BGP.DC3.Basic：20r 左右 / 月的 HK 优化 (CTGGIA/10099/CMI) 线路，虽然只有 100Mbps，虽然只有 300GB 流量，虽然联通上行 q 麻了，虽然 ip 质量一般 (甚至送中)，但是只要 20r / 月啊，你看看跟上面的动辄 10 刀 30 刀的一比，是不是这些缺点都能接受了？当然了，如果你是移动单线，他家 14CAD / 年的 CN.HK.INTL 也很不错。VMISS 详细测评
• Zouter 的 HK BGP Global - Standar：9.9r / 月的移动 + 教育网快乐机器，电联完全爆炸无法直连，但是移动 + 教育快乐让他在特定情形下是个优秀的选择，毕竟只要 9.9r (最近一个月他家被同行 ddos 打的生活不能自理了，最好过段时间再买)
• YXVM 不做散户了，就不推荐了；Fxtransit 速度跑不起来，和价格有点不匹配；yunyoo 这类小水管 10M20M 的 CN2 就不推了，实在是食之无味弃之可惜；BWH 的 90 刀 / 月实在是太贵太贵，机器好是好，但是价格和配置严重不匹配了；technovm 的大小包高手不要跑出来吓我哈。

家宽机器

港仔

亚太顶级家宽服务商，提供 HKT/HKBN/i-Cable/CMHK/HGC 等的几乎所有 HK 家宽产品，顶级的家宽质量，标准化稳定产品，主要面向中高端用户。这个机器本身是几乎完美的，只要你能接受价格，那 HK 家宽就是这家了。

常见产品线：

• HKT：2C2G 8GB 500Mbps (5TB 双向) 38 刀 / 月
• i-Cable： 2C2G 8GB 1000Mbps (5TB 双向) 38 刀 / 月

港仔详细测评

kazecloud

HK 地区较大的 HK 家宽服务商，提供 i-Cable/HKBN/CMHK/HKT/HGC 等几乎所有 HK 家宽产品，顶级的家宽质量，这家主打的是 VDS，独享带宽无限流量，面板比较简陋，产品标准化和便捷性较差，相比起港仔没这么成熟，oneman 了一点，但是产品相对价格也会低点。

常见产品线：

• CMHK FTTx VDS - 200Mbps：1C2G 10GB 200Mbps (无限流量) 38 刀 / 月
• HKT FTTx VDS - 200Mbps：1C2G 10GB 200Mbps (无限流量) 38 刀 / 月

不主流但值得一看的产品

• Bestvm 的香港 HGC-Special-2：价格确实是便宜其他家一大截，质量也不错，平均下来 70r / 月就有一个独立 ipHGC 家宽，流量还多。
• Yinnet 的香港双 ISP 产品：同样的 HGC 家宽，搭配活动的 5 折券，竟然可以 5 刀 / 月买到一个独立 HK 家宽 ip，这个价格更是重量级，是真便宜啊，把价格战贯彻到底。不过这么便宜，ip 质量容易崩坏呢
• NAT 机器 ip 质量都挺差劲的，除了港仔的 NAT 好点 (有人数限制)，其他无一例外都是超售 + 不稳定的小垃鸡，什么速达云，喵云诸如此类，我是不太推荐的。

落地机器

DMIT (大妈)

无优化，电信丢包绕路严重，移动联通部分地区快乐，整体还是不可直连的机器，不建议直连使用；ip 质量一般；机器性能中规中矩，大部分应用都足够使用。DMIT 有独特的超量限速不限量政策，如果流量较大的话性价比就比较高。

缺点：同段机场较多，沦为纯粹的流媒体解锁和国际互联机器，该跳盾还得跳盾

常见产品线：

• HKG.T1.WEE： 1C1G20G 1T (单向)/ 月 超量限速 50Mbps 36.9 刀 / 年

DMIT 详细测评

RFCHOST (花卷科技)

三网不可直连，RFC 拥有 CTC+JINX 的强力上游，国际互连优秀；ip 质量一般；机器性能一般。这家最大的特点不仅是国际优秀，而且 JINX 系列还拥有免费的 DNS 解锁和 EMBY 服务 (CTC 系列没有)，性价比进一步上升。

缺点：同段机场较多，沦为纯粹的流媒体解锁和国际互联机器，该跳盾还得跳盾 + 经常被 ddos 攻击导致不稳定

常见产品线：

• T1ION-Unlimited speed-Balance：1C1G 10GB 2TB (双) 29.9 刀 / 年

RFC 详细测评

BageVM

熟悉的 CTC 上游啊，国际互连很不错啊，直连电联基本爆炸，移动相当快乐，去程能跑 500Mbps，回程也有 200Mbps，虽然 CMI 晚高峰波动大，但用还是能用的，性价比一下就很不错了；ip 质量不错，合格的落地机器；机器性能比较强劲，EPYC 7663 的 CPU，IO 也不错，可惜还是配置低，1c1g 掀不起大浪。

缺点：同段机场较多，沦为纯粹的流媒体解锁和国际互联机器，该跳盾还得跳盾 + 经常被 ddos 攻击导致不稳定

常见产品线：

• Hong Kong Standard - TINY：1C1G 20GB 2TB (双) 3.99 刀 / 月

BageVM 详细测评

不主流但值得一看的产品

• bestvm 的香港 BGP-Standard：akari 的机器互联拉 TW 有一手的，互联还不错，比直接从 akari 买便宜太多了
• Nube 的国际轻量：牛肉佬的 1.6 刀 / 月的 HK 性能机器，落地互联不错，带宽大，而且按流量计费，十分灵活。Nube 详细测评
• 剩下没想到有啥值得一看的，要么超售到爆炸要么互联差要么毫无特色，等待评论区 MJJ 补充算了

JP (日本)

JP 应该是亚太最难搞的区域，无论是线路还是落地，价格都相当高昂，大部分线路机器直出就是不错的选择了，落地机器大多也是主打国际互连的，没有那种很干净的非家宽落地机器，需要干净还得是家宽，但是家宽价格很高昂，就导致这个区域的 NAT 机器满天飞，各家的软银 NAT 其实质量都大差不差，也就是超售多少和价格的区别而已，如果你让我给你一个省钱建议：那就是别玩日本机器。(美西组一个优质线路 + 优质家宽的价格)*2 < 日本优质家宽的价格

线路机器

Gomami (狗妈咪)

三网各自顶级优化 (CTGGIA/9929/CMIN2) 的 JP 线路机器，单线程 400Mbps+(移动上行 qos 严重，下行正常)，国际互连优秀，对 ip 质量没要求的可以直出；ip 质量还行，常规流媒体基本解锁，但是日本本土网站解锁很差，DMM 倒是解锁，meta 不出意外的不能用；机器性能比较强劲。整体而言是相当优秀的建站业务机器。

缺点：ip 质量差，有需要还是要套家宽 + 移动上行低 (直播等需要大量上传的移动用户慎选)

常见产品线：

• JPN.Pulse.Nano：2C2G 40GB 500GB 单向 / 月 29 刀 / 月

Gomami 详细测评

Neburst (奶爸)

三网优化，电信双程 163pp (高 q163) 表现比较极致，联通则是双程 10099，移动去程 CMI 回程 CMIN2。电信表现都相当优秀，上下行单线程都有稳定 300Mbps-400Mbps，联通速率偏低但也还行，移动去程主干 CMI 表现相当一般，非晚高峰都 q 的厉害，长时间上行都达不到 100Mbps 还伴随断流，不适合需要上传 (直播) 的用户，回程 CMIN2 倒是极致，可以跑到 300-500Mbps+；ip 质量不错，直出基本够用，无需落地 (解锁有点混合，ip 地区还没更新，有 US 解锁有 JP 解锁)，当然很多 JP 专属的流媒体解锁失败，国际互联也很强力，无需求可以直出；机器性能比较强劲。整体而言是相当优秀的建站业务机器。

缺点：ip 质量差，有需要还是要套家宽 + 移动上行低 (直播等需要大量上传的移动用户慎选)

常见产品线：

• Tokyo (NRT)：1C1G 20GB 500GB (单向)/ 月 55.92 刀 / 季

Neburst 详细测评

DMIT (大妈)

三网 CTGGIA 的线路 (CTGGIA 和 CN2GIA 基本无差异，CN2GT 才是比较烂的)，IPV6 可以直连，电信单线程基本可以跑到 500Mbps，移动联通基本也有 300~400Mbps，三网都很不错。ip 质量中规中矩；机器性能比较强劲。

缺点：ip 质量一般，有本土流媒体需求还是要套家宽 + 联通移动跨网延时可能会略微升高 + 近期被 ddos 攻击导致不稳定

常见产品线：

• TYO.Pro.Shinagawa (品川)：1C2G 60G 840G (双向)/ 月 199.99 刀 / 年

DMIT 详细测评

RFCHOST (花卷科技)

去程回程优化的 JP 线路，高 q163+10099+cmi，实测下来电信上行 (去程) 确实是优化，但是这个优化也仅仅到不丢包而已，去程并不算优秀，多次测试都卡在 50Mbps，下行很极致，有 400Mbps，联通上下行都很极致，单线程 400Mbps + 低重传，移动大部分地区比较优秀，单线程有 300Mbps，少部分地区拉跨，丢包丢飞了，在这些地区 (查看详细测评中的 ITDOG 可见) 的用户需要慎重考虑上车；ip 质量很差，送中 + 大量流媒体被 ban，要靠 DNS 解锁救一下了；机器性能中规中矩。

缺点：ip 质量差，有需要还是要套家宽 + 电信上行低 (直播等需要大量上传的移动用户慎选)+ 部分地区移动爆炸

常见产品线：

• JP2-CO-Micro：1C0.5G 10GB 1T (双向)/ 月 10.40 刀 / 月

RFC 详细测评

不主流但值得一看的产品

• ISIF 的 COM 系列：三网优化机器，应该是对标中端机器，经常看到 MJJ 说它家 JP 速度不行，我因为并没有长期使用，而且这家的详细测评并没有完成，所以此处先不评价具体到某个运营商的情况，先挖个坑，机器已在测试中，具体情况后补。
• Bagevm 的 Japan Standard：3.99 刀 / 月，2T 双向 / 月，本质上是一台落地机器，流媒体解锁比较完整，同段机场多导致 ip 质量差，线路方面是三网软银，神就神在这个机器联通移动基本快乐，联通可以跑 1000Mbps 上下对等，移动也有 300Mbps 上下对等，电信晚高峰爆炸丢包用不了，联通移动依旧比较快乐，作为一个落地还送线路，它真的我哭死。BageVM 详细测评
• 绿云软银：绿云三网软银线路表现和 BageVM 差不多，都是移动联通比较快乐，电信爆炸，这家的机器我没有持有过，也没有太关心，因为 MJJ 用的很多，所以加进来了，评价实在是不知道怎么评价，先空着吧…
• 小秘书的 Gen2：没有持有过，看测试和 MJJ 的评价来看是一台三网极致的高端机器，正价高昂，活动款溢价夸张，正常来说我觉得这个应该在上面，不过没有进行过详细测试而且 MJJ 持有量也并不大，不主流，所以放在这个板块里。
• Nube 的 JP 国际优化：1 刀 / 月起步的日本三网直连 + 性能强劲机器，直连的电联 IIJ + 移动 softbank，三网延时都很好看，实测下来电信基本只有 50Mbps，联通移动倒是很不错，有 200~300Mbps 的速度，值得注意的是：IIJ 和 softbank 晚高峰波动较大，时不时会断流卡住，这个机好就好在价格上，它才要 1 刀… 小流量用户福音啊。Nube 详细测评
• VMISS 的 JP.TKY.TRI：JP 地区的三网优化 (CTGGIA/10099/CMI)，12CAD 也就是 60r / 月，平常有 8 折活动入手就是 50r 左右每月，口子偏小只有 100Mbps，流量倒还行，在 JP 地区三网优化这个价格很不错，个人使用完全足够，也可以作为过渡时期的机器。网络质量比较优秀，三网基本都能跑满 95Mbps，带宽冗余不错，部分地区有丢包 (例如深电)，大部分地区稳定低重传；ip 质量中规中矩；机器性能较强，EPYC-Milan 的 CPU 基本够用。VMISS 详细测评
• Skyline 的 JP 产品：正价性价比一般，活动款 12.5 刀 / 年一下就很有诚意了，1T 流量 / 月联通移动快乐机 (虽然产品名叫中国路由优化，实际上电信基本用不来了的，丢包太猛)，流媒体解锁基本完整，meta 送中了用不了；机器性能羸弱。
• BWH 好是好，但是 90 刀 / 月的售价未免有点太夸张了… 并非主流产品，你要是说的是那个 CMI 樱花盒子就拉倒吧

家宽机器

SOSOSO

老牌 JP 家宽商家了，提供 Rakuten (乐天)/Biglobe/KDDI/sony 等多种家宽，包含独立 IPV4/NATIPV4 / 独立 IPV6-only 等多种产品，各种产品常年缺货，工单 /tg 响应都非常快，比较特色的是这个商家是有 SLA99 保证的，不达标会免除费用 (低于 99% 免除 50%，低于 95% 免除 100%)，少数的家宽机器提供稳定性保障的商家，独立 ip 的家宽质量非常不错，但是共享 NAT 质量有点一眼难尽了，大部分都有送中的现象导致 google 系使用不了，总体而言还是非常不错的商家。

缺点：NAT 机器送中严重

常见产品线：

• 日本 A 区独立 IPV6 + 共享 NAT：1C0.5G 7GB 1T (双向)/ 月 9.99 刀 / 月
• 日本乐天独享：2C4G 30GB 20T (单向)/ 月 99 刀 / 月

Radonet

也是老牌 JP 家宽商家了，提供 UCOM/NURO/Rakuten/KDDI/So-net/ 甚至还有星链等多种家宽，部分产品自带 DNS 解锁分流防止送中，产品整体价格较高，ip 质量优秀，机器性能中规中矩。你能接受价格的话，这家是个不错的选择。注：这家可以全额退款 (只要你对服务不完全满意，但不一定成功)。

常见产品线：

• NURO M Package：2C4G 20GB 10T (双向)/ 月 50 刀 / 月
• Starlink Shared Package：1C1G 10GB 1.5T (双向)/ 月 25 刀 / 月

港仔

港仔在 JP 地区的新产品线，主营 CPE 4G/5G 蜂窩網絡 Mobile 4G/5G 产品，包含 KDDI/NTT/Rakuten/SoftBank 等产品，ip 质量优秀，也是少数直接可以购买蜂窩網絡 VPS 的商家，相当不错，就是起步价格较高，面向高端用户了。

常见产品线：

• KDDI/au 5G Mobile VPS:2C2G 8GB 1T (双向)/ 月 98 刀 / 月
• Rakuten 5G Mobile VPS:2C2G 8GB 1T (双向)/ 月 98 刀 / 月

学长网络

这个商家相对 oneman 一点，提供 Softbank/biglobe 的便宜量大 NAT 机器，还有樱花 / GMO 的机器代开，ss/vmess/socks5 屏蔽了国内方向，多次收到反馈说机器速度达不到标称，风评两极分化，应该是超售严重导致的，最好就不要当成直连机器了，本土内基本都跑不满，晚高峰波动严重，毕竟价格便宜，只能说是一分钱一分货了。还有，有几个大户也和我说它家独享机器速度不达标，让我怀疑到底是超售问题还是网络架构问题了… 这家机器正在测试，详细测评后补

缺点：稳定性一般，超售严重 + 速度不达标

常见产品线：

• 软银 SoftBank-nat 机：1C0.5G 3GB 1T (双向)/ 月 35r / 月
• Biglobe 家宽 nat：1C0.5G 5GB 2T (双向)/ 月 35r / 月

不主流但值得一看的产品

• AaiTR 的软银 NAT:30r / 月的 JP NAT 机器，超售相对不严重，因为要实名验证… 光看机器还是划得来的，就是这个实名有点搞…
• lala 的代开服务：有独享软银家宽产品和 GMO / 樱花 / Webarena 代开服务，就是服务费有点高，其家宽产品我没持有过，我对它家的印象只剩下它家常年通报的各种专线机器了
• tokyoonline：提供 sonet/KDDI 的家宽产品，对于小户而言价格较贵，对于大户而言就比较便宜，不过这家的 ip 长年累月的被大户蹬，现在已经不太行了
• zorocloud 的 GLBB 家宽：价格中档的 GLBB 家宽产品，也是少数几家提供 GLBB 家宽的服务商，ip 质量还行，这个是真家宽啊，不是伪家宽，测了下流媒体本土解锁不错，这个应该是所有家宽里独立 ip 最便宜的，但是延时偏高而且他家有多次被 MJJ 冲烂 IP 的前科导致 IP 不稳，所以放在这个板块里，
• AWS Wavelength：极少数人的选择，ip 池子是真干净，贵也是真贵，它是真的贵啊

落地机器

RFCHOST (花卷科技)

电信联通 IIJ + 移动软银线路的落地机器，直连情况下：电联晚高峰丢包严重，几乎不可用，移动相当快乐，低重传单线程能到 200~300Mbps，相互不错。这个机器的优秀之处在于国际互连，接入 IIJ + 软银 + NTT 等多线的组合相当炸裂，JP 落地互联的相当棒的选择；ip 质量出乎我意料的居然还不错，配合 DNS 解锁更好；机器性能中规中矩。

缺点：同段机场较多，沦为纯粹的流媒体解锁和国际互联机器，该跳盾还得跳盾 + 经常被 ddos 攻击导致不稳定

常见产品线：

• JP2-T1ION-Balance：1C0.5G 10GB 1TB (双) 29.9 刀 / 年

RFC 详细测评

BageVM

SAKURA 上游，国际互连很不错啊，这款机器三网软银回程，JP 地区相当有性价比的回程，电信就爆炸了，但是联通移动基本快乐，联通可以跑 1000Mbps 上下对等，移动也有 300Mbps 上下对等这个机器，而且这个机器我持有很久了，相当不错啊，联通晚高峰多线程可以跑到 900Mbps，一个落地还送线路他真的我哭死，联通好机这就是；ip 质量不错，合格的落地机器；机器性能比较强劲，小型应用随便跑，CPU 不会成为瓶颈，可惜总体还是配置低，1c1g 掀不起大浪，能加到 2c4g 这就是建站神机啊。

缺点：同段机场较多，沦为纯粹的流媒体解锁和国际互联机器，该跳盾还得跳盾 + 经常被 ddos 攻击导致不稳定

常见产品线：

• Japan Standard - SMALL：1C1G 10GB 2TB (双) 3.99 刀 / 月

BageVM 详细测评

DMIT (大妈)

无优化线路，电信联通基本不可用，移动部分地区快乐，整体还是不可直连的机器，不建议直连使用，国际互连不错；ip 质量一般；机器性能中规中矩，大部分应用都足够使用。DMIT 有独特的超量限速不限量政策，如果流量较大的话性价比就比较高。

缺点：同段机场较多，沦为纯粹的流媒体解锁和国际互联机器，该跳盾还得跳盾

常见产品线：

• TYO.T1.WEE： 1C1G20G 1T (单向)/ 月 超量限速 50Mbps 36.9 刀 / 年

DMIT 详细测评

不主流但值得一看的产品

• Fxtransit 的大流量落地：ip 质量一搬，但是国际路由优化不错，它家的回国是个动态路由啊，有时候直有时候绕路，推荐当成纯落地用，虽然官方标注了超量限速不限量，实际上超量后基本达不到标称，如果你是看重超量后的带宽劝你慎重，不超量倒是速度倒是拉满
• yunyoo 的量大管饱 iij：10r/T 站起来蹬 (这家正在详测，测完后补其他信息)
• 想了一圈好像没啥别的特殊的落地了，backwave 的单线 GSL 国内又绕路没啥优势，Nube 的 1 刀 / 月起手 + 10r2T 流量还行，还有一批 wap/aki/alice 的便宜小拉机网路波动大，以后再慢慢补充吧

官方链接

Cloudflare One

dash 控制面板登录

目的

• 搭建 3xui 的 vless + ws + tls 后，使用 Gemini 的过程中容易访问失败
• 基础 warp 容易遇到质量差的问题，出现风控的问题
• 隐藏真实的 ip

Teams 注册

• 登录 cf 的 Zero Trust 之后，选择 cf one plan 计划

• 50 个的 warp 用户是免费的，但是需要有 visa 卡，我这里用的是 bybit 的卡 → 首次会直接扣 0 美元，所以要保证卡的可用
• 填写的团队网站会指向这里，后续也可以修改

warp 登录规则

入口

规则填写

• 说明：规则一般都是做限制注册用的，所以我这里的规则就是 使用邮箱 → value 是我的邮箱信息 （完整的）
  
  

服务器配置

官方的 warp-cli 下载教程

官方注册

1. 使用一个能够打开网页的机器，并打开以下链接

   https://{team-name}.cloudflareaccess.com/warp
   

2. 填写相关信息之后，会到达该页面，并使用 f12，选择 图中的元素位置，需要 获取的是 com.cloudflare.warp://xxxxxx

邪修注册

链接

Sign in ・ Cloudflare Access

方法

1. 输入对应的 team-name 和账号信息

2. 之后会有 Team Token

3. 前面拼接以下内容即可

   com.cloudflare.warp://{team-name}.cloudflareaccess.com/auth?token={team-token}
   

回到服务器上，输入 warp-cli registration token com.cloudflare.warp://{team-name}.cloudflareaccess.com/auth?token={team-token}，会显示 Success 即可。 此时，会进行账号注册，显示在

到达 one.dash 页面上，点击 Device Profiles 选项，会有一个 Default 默认配置，点击 config 进入配置信息页面，并打开以下配置之后下拉到最底进行保存

• Mode switch
• Service mode 选择 Proxy mode [默认会走端口号 40000]

佬友的指正
设备隧道协议要选 MASQUE，才能开启代理模式，最好也提醒大伙儿一下
以及建议用 curl --socks5 127.0.0.1:40000 https://cloudflare.com/cdn-cgi/trace 来测试，因为这样能清楚的看到是否有 warp=plus 结果（原来 team 是走的 plus 哎）

回到服务器上，输入 warp-cli settings，会有一大堆配置信息。等待出现显示为
(network policy) Mode: WarpProxy on port 40000
说明 warp 注册完毕。输入 warp-cli connect, 链接服务。

验证

服务器输入： curl -x socks5://127.0.0.1:40000 ifconfig.me 得到 非本机 ip 地址，说明配置完毕

3xui 配置 warp

1. 进入 3xui 面板，选择 Xrap 设置
2. 直接选择高级配置
3. 找到 outbounds 这个 dict，并输入以下配置信息 [port 就是 warp 的端口号]

   {
         "tag": "WARP",
         "protocol": "socks",
         "settings": {
           "servers": [
             {
               "address": "127.0.0.1",
               "port": 40000,
               "users": []
             }
           ]
         }
       }
   

4. 找到 routing.rules 这个 list，并输入以下配置，让服务直接走 warp 即可

   { "type": "field", "outboundTag": "WARP", "domain": [ "geosite:google", "geosite:youtube", "geosite:openai", "geosite:netflix", "geosite:disney", "gemini.google.com" ] 

5. 保存，并重启 Xray，即可

开源地址：GitHub - xueayi/XiaoXue-Video-Tools: 基于 ffmpeg 的视频图像处理和检查工具箱

本项目推荐给需要快速完成压制、素材规格筛选、投稿违规风险素材检查的部分视频创作者和 UP 主。

此前团队 B 站投稿前一直用小丸工具箱压制，但是转眼一看小丸工具箱已经十年没更新了，ffmpeg 的版本已经跟不上时代了，而且眼下团队内也有一些特定的新需求，于是一拍脑门把之前酝酿许久的 “ffmpeg 套壳计划” 搬了出来。
前端用的 Gooey，后端用的 python（别问为什么是 python，问就是别的不会）。从周五写到周日，爆肝腰酸背痛脖子疼。总算用我蹩脚的开发能力和强大的 AI 赋能搞定了这个小工具箱，自己还是挺满意的。“我们两个真厉害！”
基本算是榨干了 antigravity 每五个小时更新的 Claude 额度。
这里顺便推荐一下 antigravity 额度监控插件、以及隔壁佬友开发的不用 tun 就能强制代理 antigravity 的插件

• GitHub - wusimpl/AntigravityQuotaWatcher: Google Antigravity AI 模型配额监控插件 (Antigravity AI Model Quota Watching)
• https://linux.do/t/topic/1422119

虽然也是个重复造轮子的工程，市面上确实已经有很多 FFmpeg 的图形界面工具了，比如 ShanaEncoder、HandBrake 等等。不过果然还是根据自己的需求做的工具用起来能最直接地解决痛点，有一些在实际团队协作过程中需要用到的功能还是自己加上来得实在。

工具名称：小雪工具箱

核心特色

1. 预设压制预设，也允许高级输入

• 内置了多档预设。
• 预设常用编码方式和参数选项。

因为团队流程中一些压制参数比较固定，比如 B 站投稿的最终压制，或是一些时候需要快速导出预览，所以预设常用配置就很关键。有时候也需要做一些优化调整，所以保留自由度也是很重要的。

2. 字幕兼容模式（参考小丸工具箱的处理方案）

• 很多时候压制用 ffmpeg 原生的 libass 压制带字幕的视频，字体显示会出问题。这是因为原生滤镜不能识别多字重字体文件的不同字重，而 Windows 系统却能识别，因此需要用一种所见即所得的方案替代原生模式的压制。
• 内置 AviSynth + VSFilter，无需安装任何额外插件，开启 “兼容模式” 就能渲染大部分出现上述问题的字幕。

3. 素材质量检测 (QC)

• 团队协作时，经常收到格式不对的素材或者质量不达标的素材，分辨率、码率一个一个检查太费时间。
• 工具箱可以一键检测视频的码率、分辨率、兼容性，并生成检测报告，把控素材质量。

4. 实用的效率小工具

• 批量管理：文件夹批量创建、序列重命名（治愈强迫症）。
• 通知系统：长时间的压制任务做完了支持飞书通知或自定义 Webhook，不用一直盯着屏幕。任务完成可以自动发送消息到飞书或 QQ。
• Shield 增强版：甚至集成了有过审风险图片识别功能，帮团队预判 B 站 / 平台的过审风险。

有一些不合理的地方或者可改进的建议欢迎大佬们提出，希望能把这个工具做好！
（求各路大佬们顺手给个 star）

个人用差不多能用，多人蹬可能会慢一点，
加了监控流量，防止鸡炸掉，一定时间段滥用超出一定流量自动停止服务，我看到稍后会在解开，
各位可以蹬慢点，快了都用不了

我今天又试验了一遍，其实上周就试过，15 分钟从注册到验证完成一路丝滑，并且没有要手机验证码或者扫码。

先上图，可以看下我的步骤，我的时间设置是美国时间，我先注册了，一分钟都没耽误，立马去验证学生资格，绑卡，然后再回来绑两步验证的，可以看到我的注册时间是 16 点 19，绑卡成功订阅的时间是 16 点 30，然后再绑的两步验证。

接下里就是讲操作，我是安卓手机，首先节点要纯净，我用的家宽，提前几天把手机的语言设置成英语，时区设置成美国，不要临时设置，临时设置我试过有可能不奏效，设置了几天之后，然后保证有已经登录的稳定的账号，在 play 商店或者其他谷歌的产品账号那里直接点添加，就很大概率是不要手机号，直接注册成功，比如像这样，我今天和上周的都没要手机号，直接注册成功。

然后注册成功后，我两步验证都没做，直接去浏览器，我用的 edge. 直接去登录，看有没有学生资格。，https://gemini.google/students，点 get offer 出现下图。

然后就就用 u 佬的 1Key 过验证，https://batch.1key.me/, 订阅绑卡就成功了

然后再回去设置两步验证。完成，

操作流程是按照佬友的教程，感谢佬友 @guokai_cao。
【保姆级教程】2026 最新 Gemini 学生会员十分钟申请（无视 ip 100% 成功版）

绑定虚拟卡是参照佬友的申请教程，感谢佬友的分享
没有申请实体卡，虚拟卡可以直接绑
[海外支付] ready 人人卡相关信息分享（无 aff）

google 账号一共试了三个，前两个是上周新注册的美区账号，但是一直没有验证资格，建议佬友还是使用老号进行验证。
我的验证过程：
这个号是自己平时一直在用的号，在手机的 Google Play 上看，地区一直是中国（当时没截图，现在已经改到美国了），然后资格验证一直没有验证资格。

但是在网页上查看，说账号的关联地区已经是美国了，百思不得其解。

反复尝试后，发现了最终没有修改对的地方：【管理 google 账号】 → 【个人信息】 → 【其它地址】，这里面有一个法定地址，我很早之前注册 google 账号的时候填的是一个中国地址，点进去之后修改法定地址，按照提示一步步操作，完成修改法定地址。最后在付款资料中切换到新增的美国地址，完成。

老号一直没有验证资格的佬友可以检查下这个设置。

以下 prompt 能一定程度上解决模型不说人话的情况，信息密度合理，看起来舒服一些。目前测试了哈基米 3pro，感觉指令遵循得还比较到位，能改善模型聊着聊着开始打比方或者猛猛用引号的情况。

效果还可以，chatgpt 还没怎么测试，佬们可自行使用反馈一下

NFTables NAT Rust

基于 nftables 的高性能 NAT 端口转发管理工具，使用 Rust 语言开发。

核心特性

• 动态 NAT 转发：自动监测配置文件和目标域名 IP 变化，实时更新转发规则
• IPv4/IPv6 双栈支持：完整支持 IPv4 和 IPv6 NAT 转发
• 灵活配置：支持传统配置文件和 TOML 格式，满足不同使用场景
• 精准控制：支持单端口、端口段、TCP/UDP 协议选择
• 本地重定向：支持端口重定向到本机其他端口
• Docker 兼容：与 Docker 网络完美兼容
• 高性能轻量：基于 Rust 编写，仅依赖标准库和少量核心库
• 开机自启：支持 systemd 服务管理，开机自动启动
• 域名解析：支持域名和 IP 地址，自动 DNS 解析和缓存
• Web 管理界面：提供可视化的 WebUI 管理配置和查看规则

系统要求

适用于以下 Linux 发行版：

• CentOS 8+ / RHEL 8+ / Fedora
• Debian 10+ / Ubuntu 18.04+
• 其他支持 nftables 的现代 Linux 发行版

系统准备

CentOS / RHEL / Fedora

# 关闭 firewalld
systemctl disable --now firewalld

# 关闭 SELinux
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config

# 安装 nftables
yum install -y nftables

Debian / Ubuntu

# 安装 nftables
apt update && apt install -y nftables

# 禁用 iptables（可选）
systemctl disable --now iptables

快速安装

升级也使用相同的安装命令

方法一：TOML 配置文件版本（推荐）

bash <(curl -sSLf https://us.arloor.dev/https://github.com/arloor/nftables-nat-rust/releases/download/v2.0.0/setup.sh) toml

方法二：传统配置文件版本

bash <(curl -sSLf https://us.arloor.dev/https://github.com/arloor/nftables-nat-rust/releases/download/v2.0.0/setup.sh) legacy

WebUI 管理界面

本项目现已支持 Web 管理界面，可以通过浏览器方便地管理 NAT 配置。

• 基于 JWT 的安全认证
• 支持 HTTPS/TLS 加密传输
• 可视化编辑配置文件（支持传统格式和 TOML 格式）
• 实时查看 nftables 规则
• 现代化的用户界面

安装管理界面 WebUI

bash <(curl -sSLf https://us.arloor.dev/https://github.com/arloor/nftables-nat-rust/releases/download/v2.0.0/setup-console.sh) # -p 5533  -k /root/.acme.sh/arloor.dev/arloor.dev.key -c /root/.acme.sh/arloor.dev/fullchain.cer 

1. 安装过程会交互式提示输入用户名和密码。密码会保存在 systemd 文件中，注意安全。
2. 通过 -p 参数可以指定 WebUI 监听端口，默认端口为 5533。
3. 通过 -c 和 -k 参数可以指定自定义 TLS 证书和私钥文件路径，如果未提供，将自动生成自签名证书。
4. 安装脚本会自动检测现有 NAT 服务的配置格式，并根据配置格式生成相应的 systemd service 文件。

安装完成后，访问 https://your-server-ip:5533 即可使用管理界面。详细文档请查看 nat-console/README.md

升级 WebUI

bash <(curl -sSLf https://us.arloor.dev/https://github.com/arloor/nftables-nat-rust/releases/download/v2.0.0/setup-console-assets.sh)
systemctl restart nat-console

配置说明

TOML 配置文件（推荐）

配置文件位置：/etc/nat.toml

优势：

• 支持配置验证，保证格式正确
• 支持注释，便于维护
• WebUI 可视化编辑和验证
• 结构化配置，可读性更好

# ============ 基础转发示例 ============ # 1. 单端口转发 - HTTPS 流量转发 [[rules]] type = "single" sport = 10443 # 本机监听端口 dport = 443 # 目标服务端口 domain = "example.com" # 目标域名或 IP 地址 protocol = "all" # 协议: all, tcp 或 udp ip_version = "ipv4" # IP 版本: ipv4, ipv6 或 all comment = "转发 HTTPS 到 example.com" # 2. 端口段转发 - 批量游戏端口 [[rules]] type = "range" port_start = 20000 # 起始端口 port_end = 20100 # 结束端口（含） domain = "game.example.com" protocol = "tcp" # 仅 TCP 协议 ip_version = "all" # 同时支持 IPv4 和 IPv6 comment = "游戏服务器端口段" # 3. UDP 专用转发 - DNS 服务 [[rules]] type = "single" sport = 5353 # 本机 DNS 端口 dport = 53 # 目标 DNS 端口 domain = "8.8.8.8" # 也可以直接使用 IP 地址 protocol = "udp" # 仅 UDP 协议 ip_version = "ipv4" comment = "DNS 查询转发" # ============ 本地重定向示例 ============ # 4. 单端口重定向到本机服务 [[rules]] type = "redirect" sport = 8080 # 外部访问端口 dport = 3128 # 本机实际服务端口 protocol = "all" ip_version = "ipv4" comment = "代理服务端口重定向" # 5. 端口段重定向到本机 [[rules]] type = "redirect" sport = 30001 # 起始端口 sport_end = 30100 # 结束端口 dport = 45678 # 本机目标端口 protocol = "tcp" ip_version = "all" comment = "批量端口重定向到本机" # ============ 高级场景示例 ============ # 6. 强制 IPv6 转发 [[rules]] type = "single" sport = 9001 dport = 9090 domain = "ipv6.example.com" protocol = "all" ip_version = "ipv6" # 仅使用 IPv6 进行转发 comment = "IPv6 专用服务" # 7. 双栈支持示例 - 自动选择 IPv4/IPv6 [[rules]] type = "single" sport = 10080 dport = 80 domain = "dual-stack.example.com" # 域名同时有 A 和 AAAA 记录 protocol = "tcp" ip_version = "all" # 根据客户端 IP 版本自动选择 comment = "双栈 Web 服务" 

传统配置文件

配置文件位置：/etc/nat.conf

基础格式：

• SINGLE,本机端口,目标端口,目标地址[,协议][,IP版本] - 单端口转发
• RANGE,起始端口,结束端口,目标地址[,协议][,IP版本] - 端口段转发
• REDIRECT,源端口,目标端口[,协议][,IP版本] - 重定向到本机端口
• REDIRECT,起始端口-结束端口,目标端口[,协议][,IP版本] - 端口段重定向

参数说明：

• 协议可选值：tcp、udp、all（默认为 all）
• IP 版本可选值：ipv4、ipv6、all（默认为 all）
• 以 # 开头的行为注释

配置示例：

# ============ 基础转发 ============ # 单端口转发 - HTTPS 流量
SINGLE,10443,443,example.com

# 端口段转发 - 游戏服务器端口（20000-20100）
RANGE,20000,20100,game.example.com

# ============ 协议指定 ============ # 仅转发 TCP 流量 - Web 服务
SINGLE,10080,80,web.example.com,tcp

# 仅转发 UDP 流量 - DNS 查询
SINGLE,5353,53,8.8.8.8,udp

# ============ 本地重定向 ============ # 单端口重定向到本机服务
REDIRECT,8080,3128

# 端口段重定向到本机（30001-30100 → 45678）
REDIRECT,30001-30100,45678

# TCP 专用重定向
REDIRECT,7000-7100,8080,tcp

# ============ IPv6 支持 ============ # 强制使用 IPv6 转发
SINGLE,9001,9090,ipv6.example.com,all,ipv6

# 双栈支持（根据客户端自动选择）
SINGLE,10080,80,dual-stack.example.com,tcp,all

# 禁用的规则（以 # 开头） # SINGLE,3000,3000,disabled.example.com 

使用方法

启动 / 停止服务

# 启动服务
systemctl start nat

# 停止服务
systemctl stop nat

# 重启服务
systemctl restart nat

# 查看服务状态
systemctl status nat

# 开机自启
systemctl enable nat

# 取消开机自启
systemctl disable nat

修改配置

修改配置文件后，程序会在 60 秒内自动应用新配置，无需手动重启服务。

# TOML 版本
vim /etc/nat.toml

# 传统版本
vim /etc/nat.conf

查看日志

# 实时查看日志
journalctl -fu nat

# 查看详细日志
journalctl -exfu nat

# 查看最近 100 行日志
journalctl -u nat -n 100

查看 nftables 规则

# 查看所有规则
nft list ruleset

# 仅查看 NAT 表
nft list table ip self-nat
nft list table ip6 self-nat6

高级配置

自定义源 IP（多网卡场景）

默认使用 masquerade 自动处理 SNAT。如需指定源 IP：

# 设置自定义源 IP echo "nat_local_ip=10.10.10.10" > /opt/nat/env

# 重启服务
systemctl restart nat

Docker 兼容性

本工具已与 Docker 完全兼容。程序会自动调整 nftables 规则以适配 Docker 网络。

说明：Docker v28 将 filter 表 forward 链默认策略改为 DROP，本工具会自动将其重置为 ACCEPT 以确保 NAT 规则正常工作。

注意事项

REDIRECT 类型限制

REDIRECT 类型工作在 PREROUTING 链，仅对外部流量有效：

• 有效：外部机器访问重定向端口 → 成功重定向
• 无效：本机进程访问重定向端口 → 不会重定向

原因：本机流量直接进入 OUTPUT 链，不经过 PREROUTING 链。

示例：

# 配置：REDIRECT,8000,3128
curl http://remote-server:8000  # ✅ 成功重定向到 3128
curl http://localhost:8000      # ❌ 不会重定向，直接访问 8000 

TLS/Trojan 转发

转发 TLS/Trojan 等加密协议时，常见问题是证书配置错误。

解决方案：

1. 简单：客户端禁用证书验证
2. 推荐：正确配置证书和域名，确保证书域名与中转机匹配

许可证

本项目采用 MIT License 开源协议。

相关链接

• 项目地址：GitHub - arloor/nftables-nat-rust: nftables nat 规则生成器
• 问题反馈：GitHub · Where software is built
• 前代项目：arloor/iptablesUtils（不兼容）

注意：与旧版 iptablesUtils 不兼容，切换时请先卸载旧版或重装系统。

最近看到佬友们在聊看广告用模型的 AMP code
让我想起来这一款一样是看广告用模型的方案
Villson 支持 iOS 及安卓端
桌面版本支援 Mac
官网号称有 500 种模型可以用
大部分模型都可以在官网看到

不过最新的模型只能在应用里看

有兴趣的可以玩看看

（免费方案可以去看看，我觉得付费就不用了，这家的价格不算便宜）

应该也有人注意到，skills 和 commands 文件夹中的定义都会被追加到 / 命令列表中。将两者拆分开来的目的，就是为了在结构上保持清晰，便于后续维护与扩展。

说到这里，我也顺便附上一个具体示例

commands 文件夹下的

检测到复杂场景
    ← 调用 sequential-thinking (nextThoughtNeeded=true)
    ← 分析工具返回的思考内容
    ← 判断：是否需要继续推理？
    ← 是  → 调用 sequential-thinking (thoughtNumber+1)
    ← 循环直到 nextThoughtNeeded=false
    ← 输出最终结论

thought: "开始分析：[用户问题]..." thoughtNumber: 1 totalThoughts: [初始估计，可动态调整]
nextThoughtNeeded: true 

# 调用 1/5 thought: "分析目标：评估 API 设计的合理性和潜在问题..." nextThoughtNeeded: true # 调用 2/5 thought: "维度1：接口语义 - 检查 RESTful 规范..." nextThoughtNeeded: true # 调用 3/5 thought: "维度2：安全 - 认证/授权/输入校验..." nextThoughtNeeded: true # 调用 4/5 thought: "维度3：性能 - 分页/缓存/查询优化..." nextThoughtNeeded: true # 调用 5/5 thought: "综合结论：发现 3 个问题（无分页、缺少限流、返回字段冗余），修复建议..." nextThoughtNeeded: false # 输出最终结论给用户 

Thought 1/8: 明确业务需求的核心约束... Thought 2/8: 识别关键模块与依赖关系... Thought 3/8: 评估技术栈选型的优劣势... Thought 4/8: [分支] 探索方案 A：单体架构 Thought 5/8: [分支] 探索方案 B：微服务架构 Thought 6/8: 对比两种方案的可扩展性... Thought 7/8: 验证方案选择的安全性... Thought 8/8: 综合结论：推荐方案及实施步骤 

Thought 1/6: 复现问题并收集症状... Thought 2/6: 假设生成：可能是数据库查询慢... Thought 3/6: 验证假设：检查查询日志... Thought 4/6: [修正] 假设不成立，转向网络层面... Thought 5/6: 发现根本原因：N+1 查询... Thought 6/6: 设计修复方案... 

skills 文件夹下的 code-think 模块的

检测到复杂场景
    ↓
调用 sequential-thinking (nextThoughtNeeded=true)
    ↓
分析工具返回的思考内容
    ↓
判断：是否需要继续推理？
    ↓ 是
    ↓
调用 sequential-thinking (thoughtNumber+1)
    ↓
循环直到 nextThoughtNeeded=false
    ↓
输出最终结论

thought: "开始分析：[用户问题]..." thoughtNumber: 1 totalThoughts: [初始估计，可动态调整]
nextThoughtNeeded: true 

# 调用 1/5 thought: "分析目标：评估 API 设计的合理性和潜在问题..." nextThoughtNeeded: true # 调用 2/5 thought: "维度1：接口语义 - 检查 RESTful 规范..." nextThoughtNeeded: true # 调用 3/5 thought: "维度2：安全性 - 认证/授权/输入验证..." nextThoughtNeeded: true # 调用 4/5 thought: "维度3：性能 - 分页/缓存/查询优化..." nextThoughtNeeded: true # 调用 5/5 thought: "综合结论：发现3个问题（无分页、缺少限流、返回字段冗余），修复建议..." nextThoughtNeeded: false # 输出最终结论给用户 

Thought 1/8: 明确业务需求的核心约束... Thought 2/8: 识别关键模块与依赖关系... Thought 3/8: 评估技术栈选型的优劣势... Thought 4/8: [分支] 探索方案A：单体架构 Thought 5/8: [分支] 探索方案B：微服务架构 Thought 6/8: 对比两种方案的可扩展性... Thought 7/8: 验证方案选择的安全性... Thought 8/8: 综合结论：推荐方案及实施步骤 

Thought 1/6: 复现问题并收集症状... Thought 2/6: 假设生成：可能是数据库查询慢... Thought 3/6: 验证假设：检查查询日志... Thought 4/6: [修正] 假设不成立，转向网络层面... Thought 5/6: 发现根本原因：N+1 查询... Thought 6/6: 设计修复方案... 

他俩实际上作用都是同一个 只是为了举例说明开头说的 这是定义了一套规范 便于维护
如果要使用当前的 任选其中一个也行

claude.zip

说到最后

• 至少对于我是有一定可用性的 (使用它们能大大降低全局 token 的消耗 毕竟可以按需使用嘛
• 至于 commands 通常只负责一个明确的动作，而 skills 则能包含更复杂、可复用的功能