AI编程助手（如GitHub Copilot）已经成为开发者日常不可或缺的工具，但它究竟能做到什么程度？是只能写写简单的函数，还是能真正作为一个“能够独立交付项目的同事”？ 抱着这个疑问，我给自己设定了一个挑战：利用业余时间，在5天内，和一个AI编程助手结对，从零开始开发并上线一个完整的Web应用MVP（最小可行性产品）。 与之相关的核心原则是：拒绝“False Hope”的氛围编程（Vibe Coding）。不仅仅是让AI生成代码然后跑起来，而是要求生成的代码必须经过Review，必须有完善的单元测试（UT）和功能验证测试（FVT），必须符合工业级的代码规范与架构设计。我要保持对每一行代码的掌控力。 项目概览：Awsome Prompt人员配置： 我的技术栈：Linux、云计算、AI Infra、Web全栈、Devops 编程助手：Github copilot 大语言模型：Gemini 3 Skill: /ui-ux-pro-max 产品定义： 实现一个提示词管理工具，用户可以创建和管理提示词模板，提示词模板中的$$表示占位符。 在提示词模板详情页里，用户可以输入真实的变量内容 ...

在大模型（LLM）推理服务中，如何高效地进行流量调度是一个核心挑战。不同于传统的微服务，LLM请求具有长耗时、高并发、对GPU显存敏感等特点。Aibrix 作为一款专为 GenAI 设计的云原生基础设施，巧妙地结合了 Envoy Proxy 的强大流量治理能力，实现了一套智能的 LLM 流量转发机制。 本文将深入探讨 Aibrix 是如何利用 Envoy 及 Envoy Gateway 构建其流量转发层的。 Envoy 基础Envoy ProxyEnvoy Proxy 是一个开源的高性能边缘和服务代理，最初由 Lyft 开发。它专为云原生应用设计，已成为现代服务网格（Service Mesh）和 API 网关的事实标准。通俗来讲，它就是一个类似于Nginx的反向代理服务器，只不过支持更加贴合Kubernetes的配置，成为云原生时代的宠儿。 在 v1.36.2 版本中，Envoy 继续巩固了其作为“通用数据平面”的地位。对于 LLM 场景，Envoy 的以下特性尤为关键： 动态配置更新：利用xDS协议，支持动态配置更新（利用文件系统inotify机制或配置服务器） 高性能：基于 C+ ...

在项目中，我们使用 Go 语言开发核心功能，同时使用 Python 编写功能验证测试（FVT）。随着代码库的增长，CI/CD 流水线的执行时间逐渐变长，特别是在依赖安装和代码检查阶段。为了提升开发效率，我们最近对 GitLab CI 配置进行了优化。 优化方案1. 依赖缓存策略通过 GitLab Runner 的缓存机制，我们为不同语言的依赖项设置了独立的缓存： 1234567891011121314151617181920212223variables: GIT_CLONE_PATH: "${CI_BUILDS_DIR}/${CI_PROJECT_NAME}-build-${CI_JOB_ID}-${CI_PIPELINE_ID}" PIP_CACHE_DIR: "${CI_PROJECT_DIR}/.cache/pip" GOLANGCI_LINT_CACHE: "${CI_PROJECT_DIR}/.cac ...

虚拟化基础虚拟化技术是云计算与 AIInfra 的基石，其本质是通过虚拟机监控器（VMM/Hypervisor） 这一软件抽象层，将物理硬件资源（CPU、内存、设备）抽象为多个隔离的虚拟环境，实现资源的高效复用与安全隔离。 要构建稳定、高效的虚拟化系统，需突破三大核心技术瓶颈：CPU 特权级隔离、内存地址转换嵌套、设备 I/O 性能损耗。本章将从这三大维度切入，系统解析虚拟化基础原理，为后续 GPU 虚拟化技术的深入分析铺垫底层逻辑。 CPU 虚拟化：解决特权指令的 “权限冲突”CPU 是虚拟化的核心内容，x86 架构的设计历史导致其天然存在 “特权指令未完全隔离” 的问题，这也是 CPU 虚拟化需要突破的首个关键卡点。 CPU虚拟化需要解决的问题：特权指令设计无法满足虚拟化权限隔离需求虚拟化要求实现 “双重权限隔离”： Hypervisor 必须运行在最高特权级（Ring 0），完全控制物理硬件 虚拟机中的客户操作系统（Guest OS）需运行在非特权级（Ring 1-3），其操作需经过 Hypervisor 的监管 然而，x86 架构在设计时未考虑虚拟化场景，早期的CPU存在 ...

在Linux系统中，内核是“操作系统的核心”，负责管理硬件资源、进程调度、网络交互等核心功能。但长期以来，内核的可编程性一直是个难题——如果想自定义内核行为（比如监控进程、过滤网络包），传统方式要么依赖内核模块（风险高、兼容性差，内核模块加载后拥有与内核相同的权限，错误的代码可能导致系统崩溃或安全漏洞。），要么只能修改内核源码重新编译（成本极高）。 eBPF（extended Berkeley Packet Filter）的出现彻底改变了这一局面。它是一种运行在Linux内核中的动态追踪与可编程技术，允许用户在不修改内核源码、不重启系统的情况下，安全地向内核注入自定义逻辑，实现对系统行为的细粒度观测、控制与优化。 如今，eBPF已成为云原生、性能分析、网络安全等领域的“基础设施”，被Google、Facebook、Netflix等企业广泛用于生产环境，是理解和优化Linux系统的“瑞士军刀”。 eBPF是什么？eBPF起源于Linux网络子系统（最初用于数据包过滤），经过多年发展，已成为一套通用的内核可编程框架。简单来说，eBPF是一种“运行在内核中的安全沙箱”，允许用户编写小型程序并 ...

从去年用上WCA(Watsonx Code Assistant)起，到Copilot、Deepseek及智能终端工具Warp，使用AI编程助手快一年左右的时间了。亲眼见证了AI一步一步变强大的过程。作为一个从业十多年的老家伙，今天跟大家分享一下我对AI工具的一些看法。 AI会不会取代程序员？个人观点：不会。我觉得AI作为编程助手是AI和人类程序员合作的最好模式。为什么这么说呢？这是软件的本质和LLM(Large Language Model)的本质决定的。软件的本质是逻辑的产物。众所周知，计算机程序是由算术逻辑运算和流程控制语句等组成的。它具有幂等性，给定特定的输入就会100%得到确定的输出。所以程序员编写程序实际是在利用自己的逻辑思维加上计算机语言来解决问题。然而，LLM则是基于对海量数据的统计来根据上下文来猜测下一个词的概率。尽管它的能力越来越强，编写出正确的程序的概率也越来越大，但它永远具有不确定性，很有可能会一本正经的胡说八道（幻觉）。 其次，AI的创造能力远远不如人类，它是一个很好的、升级版的搜索引擎，它通过学习海量的代码掌握的编程范式远远超越了普通程序员，然而它却无法创造新 ...

今天和同事争论为什么Bug fix不能先进release分支再进主分支，我只能干巴巴的回答这样做不优雅，不能先CD再CI。问了问大模型，发现AI确实比较擅长做以理服人的事，哪怕它是幻觉，都让你觉得好有道理的样子。 看看AI是怎么回答的： 这是个非常棒的问题！这触及了 Linux 内核开发流程的核心设计哲学：稳定分支的纯洁性和主线的权威性。 简单来说，稳定分支只接受经过主线验证的、最小化的、必需的修复。让修复先进稳定分支再进主线，违背了这个核心原则，并会带来一系列严重问题： 破坏“稳定分支”的“稳定”定义： 代码冻结： 当一个版本被标记为稳定分支（如 6.1.y）时，就意味着它的代码基础（除了必要的修复）是冻结的。不允许添加新功能或进行大的重构。 最小化变更： 进入稳定分支的唯一东西应该是针对已知问题的、经过主线充分验证的、尽可能小的修复。目标是最大程度地减少引入新问题的风险。 如果修复先进入稳定分支： 这个修复本身就是一个新的、未经主线充分验证的变更。它可能会引入新的、更严重的 Bug，或者与主线正在进行的其他开发产生冲突，从而直接破坏了稳定分支的稳定性。 绕过主线 ...

在敏捷开发和DevOps实践中，持续集成与自动化发布已成为提升团队效率的关键。然而，传统手动管理软件版本的方式常面临诸多挑战：分支繁多导致版本追溯困难，人工更新版本号易出错，且变更日志的编写耗时耗力。尤其在多成员协作的项目中，版本兼容性管理不当可能引发“依赖地狱”，影响交付效率。 为解决这些问题，semantic-release应运而生。该工具通过分析符合规范的Git提交信息（如Angular Commit规范），自动遵循语义化版本（SemVer）规则升级版本号，并生成变更日志与Git标签，实现从代码提交到版本发布的端到端自动化。结合GitLab CI/CD，这一流程进一步无缝集成至持续交付管道：开发者只需推送代码至特定分支（如main），即可触发自动化版本发布、生成文档并推送至仓库，甚至通过插件扩展至npm包发布等场景。这种组合不仅减少了人为操作风险，还确保版本迭代透明可追溯，尤其适用于追求高效、规范化的敏捷团队。 语义化版本(Semantic Versioning)语义化版本控制规范（SemVer）是为软件版本号赋予明确含义的标准格式。其版本号采用X.Y.Z（主版本号.次版本号.修 ...

问题场景与需求分析1.1 核心挑战在隔离网络环境下构建企业级Kubernetes集群时面临三大挑战： 资源隔离：无法直接访问DockerHub、GitHub等公共资源库 安全合规：需通过私有镜像仓库（Harbor）实现镜像生命周期管理 生产级要求：需满足高可用架构、持久化存储、网络策略等企业特性 1.2 解决方案要点 跳板机设计：通过双网卡笔记本实现： 外网侧：下载RKE2二进制文件、Harbor安装包、依赖镜像 内网侧：搭建HTTP文件服务器同步资源 离线资源池： RKE2 v1.26.5+ 离线包 Harbor v2.7.0+ 离线安装包 预下载Kubernetes组件镜像（约300个） 网络规划： 架构设计与组件分布2.1 逻辑架构图 2.2 节点规格建议 角色类型 CPU 内存 磁盘 数量 网络要求 Server 4+ 8G+ 100GB+ x3 3 1Gbps 内网 Agent 8+ 16G+ 200GB+ N 10Gbps 内网 Harbor 4 8G 1TB 1 独立存储网络 关键配置与问题排查3.1 RKE2数据目录迁移修 ...

Kubernetes要解决什么问题？手动部署容器难以维护，使用容器编排技术可以解决如下问题： 容器崩溃的时候可以自动部署新的容器来代替 可以自动增加或者减少容器的数量来满足高可用和自动伸缩的需求 可以使用负载均衡来将流量分配到不同的容器中 不依赖于云服务提供商的通用配置 Kubernetes核心概念及架构Kubernetes架构图 Work node架构图 Master node架构图 Pod: kubernetes管理的主要对象，可以由一个或者共享资源的一组容器组成kubelet: 管理worker node和master node之间的通信kube-proxy: 运行在work node上，用于管理Node和Pod的网络通信API Server: 提供API服务Scheduler: 选择worker node运行PodController: 监控Pod数量，控制worker nodeWorker node: 运行Pod的机器或者虚拟机Master node: 运行Control Plane的机器或者虚拟机 Kubernetes核心对象 Pod: Kubernetes管理的最小单 ...