一台跑着 9 个自托管服务的 AI 工作机，可用空间从 46G 回到 62G；11 天后复验，又掉回 26G；候选处置完，最终回到 86G。这是完整账本、判定框架与一套可以抄给 agent 的执行纪律。

虚拟卡时代结束后，2026 年国内订阅 ChatGPT Plus 还剩五条路。逐条对比成本、风险与适用人群，附黑卡识别与避坑要点。

网络工具NetCat简介 NetCat（简称nc）是一个网络工具，用于在计算机网络之间传输数据。它能够创建TCP/UDP连接、监听端口，并支持文件传输等功能。下面是一些常用的Netcat命令和用法。 安装Netcat 在大多数 Linux 发行版中，你可以使用包管理器来安装 Netcat。例如，在 Ubuntu 上，可以使用以下命令： # 安装Netcat sudo apt-get update sudo apt-get install netcat-openbsd # 或者旧版 netcat-traditional 要查看安装的Netcat版本和路径，可以使用以下命令： # 查看版本和路径 readlink -f $(which nc) 测试连接 TCP连接 # 测试TCP连接 nc -vz 127.0.0.1 5244 UDP连接 # 测试UDP连接 nc -vz -u 127.0.0.1 5244 超时设置 # 设置超时为3秒 nc -vz -w3 127.0.0.1 8000 范围扫描 # 扫描端口范围 nc -vz -w3 127.0.0.1 8000-8100 运行服务 单次服务 # 启动TCP服务 nc -v -l 8080 # 启动UDP服务 nc -uv -l 8080 持续服务 # 启动持续TCP服务 nc -kv -l 8080 文件传输 从服务端接收文件 # 从服务端接收文件 nc -v -l 8080 > img.

基于WebHook实现Gitee自动化部署 大纲 1.起因和思路 2.WebHooks服务 3.自动化部署脚本 4.配置和完成 1.起因和思路 前段时间在写一个小的Web项目, 部署到了租的云服务器上, 后续也进行了一些开发和优化, 每次开发完都要进行手动登录服务器部署, 感觉整个过程有点麻烦, 就想实现一个简化的自动化部署流程. 目前自动化部署主要有两种方式 通过项目下的增加CI配置的方式触发, 使用Runner服务执行 (类似GitLab CI的方式, 在项目里增加 .gitlab-ci.yml 文件) 通过WebHook事件请求, 发送到专门的CI/CD服务进行处理 (像Jenkins) 看了Gitee目前支持的方式, 第一种一般需要付费, 或者是用三方服务, 登录私有服务器执行命令; 第二种方式应该更合适我, 不过我不需要太复杂的功能. 目前来说, 简单流程就是: Gitee收到git提交事件, 发送WebHook请求到WebHook服务 WebHook服务进行校验并执行相应的部署命令 需要一个接收WebHook请求的服务, 解析并处理相应的事件, 在GitHub上找了下, 发现了一个合适的项目https://github.com/adnanh/webhook 2.WebHooks服务 该WebHook项目简介: webhook是一个用Go编写的轻量级可配置工具，它允许您在服务器上轻松创建HTTP端点（hook），您可以使用它执行配置的命令。您还可以将HTTP请求中的数据（例如头、负载或查询变量）传递给您的命令。webhook还允许您指定触发钩子必须满足的规则。 项目基本能满足需求, 通过配置文件的方式, 设定触发条件的规则, 以及执行的命令 使用也很简单, 下载Release文件, 解压后执行: /path/to/webhook -hooks hooks.json -verbose 访问地址:

Git工作流程 大纲 1.Git工作流程是什么 2.为什么需要Git工作流程 3.有那些广泛的Git工作流程 4.如何使用Git工作流程 1.Git工作流程是什么 Git工作流程是有关如何使用Git以一致且富有成效的方式完成工作的秘诀或建议。 Gitflow 工作流定义了一个围绕项目发布的严格分支模型。 Gitflow 工作流没有用超出功能分支工作流的概念和命令，而是为不同的分支分配一个很明确的角色，并定义分支之间如何和什么时候进行交互。 2.为什么需要Git工作流程 Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称”快照”）的指针，因此非常快捷易用。 Git 作为一个源码管理系统，不可避免涉及到多人协作。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。 协作必须有一个规范的工作流程，让大家有效地合作，使得项目井井有条地发展下去。”工作流程”在英语里，叫做”workflow”或者”flow”，原意是水流，比喻项目像水流那样，顺畅、自然地向前流动，不会发生冲击、对撞、甚至漩涡。 清晰可控，使多人项目协作开发更加规范。 3.有那些广泛的Git工作流程 软件业界常用的软件分支流程有多种，但本质上可以分为两类： 主干开发模式（Trunk Based Development） 特性分支开发模式（Feature Branch Development） 3.1-主干开发模式 主干开发，是指开发人员直接向主干（习惯上主干分支通常为：trunk 或 master）提交/推送代码。通常，开发团队的成员1天至少1次地将代码提交到主干分支。在到达发布条件时，从主干拉出发布分支（通常为 release），用于发布。若发现缺陷，直接在主干上修复，并根据需要 cherry pick 到对应版本的发布分支。 流程： 优点： 分支模型简单高效，开发人员易于掌握不容易出现错误操作 避免了分支合并、冲突解决的困扰 随时拥有可发布的版本 有利于持续集成和持续交付 缺点： 基础架构要求高：合入到主干的代码若质量不过关将直接阻塞整个团队的开发工作，因此需要高效的持续集成平台进行把关； 自动化测试要求高：需有完备单元测试代码，确保在代码合入主干前能在获得快速和可靠的质量反馈； 最好有代码评审：若代码质量要求高，需要配套代码评审（CR）机制，在代码提交到主干时，触发CR，通过 Peer Review 后才能正式合入； 最好有特性开关：主干开发频发合入主干的情况下，特性拆分得很小，可能是半成品特性，需要配套特性开关（Feature Toggle），只有当特性整体开发完才通过灰度发布等手段逐步打开； 适用环境： 对迭代速度要求高，希望需求快速交付上线 基础架构强，持续集成工具高效； 团队成员习惯TDD（测试驱动开发），代码自动化测试覆盖率高（至少增量代码的自动化测试覆盖率高）； 3.2-特性分支开发模式 也称为“功能驱动式开发”（Feature-driven development，简称FDD），它指的是，需求是开发的起点，先有需求再有功能分支（feature branch）或者补丁分支（hotfix branch）。完成开发后，该分支就合并到主分支，然后被删除。 一般流程就是创建一个或多个特定的需求/缺陷/任务创建代码分支（branch），在其上完成相应的开发（一般经过增量测试）后，把它合并（merge）到主干/集成分支。 通常这种分支生命期会持续一段时间，从几天到几周不等，极少数情况甚至以月算。 流程：