跳转至

工程实践与运维

告别 Xcode IDE:用 VS Code + SweetPad + XcodeGen 开发 iOS 应用的完整指南

本文以一个真实的小项目 FloatingBottomSheetsApp(一个 SwiftUI 底部浮层 Demo)为例,手把手带你搭好一套完全不打开 Xcode IDE 的 iOS 开发环境:工程生成、构建运行、调试、代码补全、格式化、热重载,一次讲清。

配套示例代码:cyub/sweetpad-demo,文中所有配置文件都可以直接对照源码查看。

为什么是 VS Code + SweetPad?

很多从其他技术栈转来、或者常年写前端的开发者,对 Xcode 那套 IDE 并不亲近——窗口繁重、编辑器手感一般、和 git 工作流的结合也别扭。SweetPad 是一个 VS Code 扩展,它把 Xcode 的核心能力(构建、运行、调试、热重载)全部搬进了 VS Code,底层驱动的仍然是苹果官方的 xcodebuild 和 lldb,所以构建产物、签名行为和 Xcode IDE 完全一致,团队成员可以混用两种开发方式,互不影响。

再配上 XcodeGen,.xcodeproj 不再是一个需要手工维护(和 git merge 时痛苦)的二进制格式文件,而是一个几十行的 YAML 清单。

一句话总结这套组合的分工:

工具 职责
XcodeGen 用 project.yml 声明工程,生成 .xcodeproj
SweetPad 在 VS Code 里构建、运行、调试、热重载
VS Code + Swift 扩展 编辑器、代码补全(SourceKit-LSP)、格式化

Kimi官方 Prompt 最佳实践指南

本文转载自 Kimi 官方文档入门指南：Prompt 最佳实践一文。

System Prompt最佳实践：system prompt（系统提示）指的是模型在生成文本或响应之前所接收的初始输入或指令，这个提示对于模型的运作至关重要

大模型中 system prompt指的是什么，为什么它很重要？

在大型机器学习模型，尤其是自然语言处理（NLP）模型中，"system prompt"（系统提示）指的是模型在生成文本或响应之前所接收的初始输入或指令。这个提示对于模型的运作至关重要，原因如下：

  1. 指导生成内容：系统提示为模型提供了生成文本的起点，帮助模型理解用户的需求和上下文。
  2. 确定响应类型：提示可以明确告诉模型需要生成哪种类型的响应，比如回答问题、撰写文章、进行翻译等。
  3. 设定上下文：通过包含必要的上下文信息，系统提示可以帮助模型更好地理解问题，并生成更准确的回答。
  4. 影响生成文本的风格和语气：系统提示还可以设定文本的风格和语气，比如正式、非正式、幽默、严肃等。
  5. 控制生成文本的长度：在某些情况下，系统提示可以包含对生成文本长度的要求。
  6. 避免不当内容：通过精心设计系统提示，可以减少模型生成不当或不安全内容的风险。
  7. 提高效率：一个好的系统提示可以提高模型的效率，因为它减少了模型需要猜测的内容，从而加快了生成过程。
  8. 用户交互：在交互式应用中，系统提示是用户与模型之间沟通的桥梁，确保了用户意图的准确传达。

在设计系统提示时，需要考虑到这些因素，以确保模型能够生成高质量、相关且符合预期的输出。

编写清晰的说明

为什么需要向模型输出清晰的说明？

模型无法读懂你的想法，如果输出内容太长，可要求模型简短回复。如果输出内容太简单，可要求模型进行专家级写作。如果你不喜欢输出的格式，请向模型展示你希望看到的格式。模型越少猜测你的需求，你越有可能得到满意的结果。

ConnectRPC：下一代 Protobuf RPC 框架——当 gRPC 遇见现代 Web 开发

为什么我们需要"更好的 gRPC"？

自 2016 年 Google 开源 gRPC 以来，它凭借 Protocol Buffers 的高效序列化和 HTTP/2 的多路复用，迅速成为微服务间通信的事实标准。然而，随着云原生架构的演进和前后端分离开发的普及，gRPC 的一些设计局限日益凸显：

  • 浏览器兼容性：gRPC 依赖 HTTP/2 的底层特性，浏览器无法直接调用，必须借助 grpc-web + Envoy 代理
  • 调试困难：二进制协议让 curl 和浏览器开发者工具束手无策
  • 部署复杂：需要特殊的负载均衡器支持 HTTP/2 trailers
  • 代码冗长：生成的客户端代码模板化严重，与现代开发体验脱节

ConnectRPC（简称 Connect）正是 Buf 团队为解决这些痛点而打造的现代化 RPC 框架。它不仅完全兼容 gRPC 生态，更带来了浏览器原生支持、HTTP/1.1 回退、以及 REST 般的调试体验。

Material Design 3 (Material You) 完整开发指南

概述与核心变革

Material Design 3（代号 Material You）是 Google 于 2021 年 I/O 大会发布的第三代设计系统，随 Android 12 正式推出。它代表了从"统一设计"到"个性化表达"的范式转变。

与 Material Design 2 的关键差异

特性 Material 2 Material 3
颜色哲学 固定品牌色（Primary/Secondary） 动态个性化（从壁纸/种子色生成）
颜色数量 12个基础色槽 26+个语义化颜色角色
表面层级 阴影海拔（Elevation） 色调表面（Tone-based Surfaces）
排版体系 6种样式（Headline 1-6等） 15种令牌化样式（Display/Headline/Title/Body/Label）
形状系统 固定圆角 7级可配置圆角体系
个性化 无 核心特性（壁纸取色、算法生成）

核心设计原则

  1. 个性化优先：系统从用户壁纸提取颜色，生成独一无二的主题
  2. 算法驱动美学：基于 HCT 颜色空间的科学算法确保配色和谐
  3. 无障碍内置：所有颜色组合默认满足 WCAG 2.1 AA 对比度标准
  4. 跨平台一致：提供跨平台实现规范，Android（Compose/View）与 Flutter 为官方完整实现，Web 与 iOS 通过 Material Color Utilities 支持配色算法

Python 项目结构与打包完全指南：从入门到实践

当你完成一个 Python 项目，想要发布到 PyPI 供全球开发者下载时，你是否遇到过这些困惑：

  • pip install 背后到底发生了什么？
  • 为什么安装 beautifulsoup4 却要 import bs4？
  • 项目代码应该放在根目录还是 src 目录？
  • python -m build 和 uv build 有什么区别？

本文将从依赖安装的底层机制出发，逐步深入到 WHL 文件构建流程，最后探讨现代化项目结构的最佳实践。无论你是刚接触 Python 打包的新手，还是希望迁移到现代工具链的开发者，这篇文章都能给你清晰的指引。

依赖安装机制：当你执行 pip install 时发生了什么？

软件包从哪来？——PyPI 与 WHL 文件

当你执行 pip install flask 时，工具背后做了三件核心的事：

  1. 查询元数据：向 PyPI（Python Package Index，Python 官方的软件包仓库）请求 flask 的包信息
  2. 下载 WHL 文件：根据你的 Python 版本和操作系统，选择最合适的 .whl 文件下载
  3. 解压安装：将 WHL 文件解压到当前 Python 环境的 site-packages 目录

WHL（Wheel） 是 Python 的二进制分发格式标准（由 PEP 427 定义）。它本质上就是一个 ZIP 压缩包，里面包含了：

  • 预编译的代码（或纯 Python 源代码）
  • 包的元数据（依赖关系、版本信息等）

让我们以 Flask 3.1.1 为例，看看 WHL 文件的真面目：

# 下载 Flask 的 WHL 文件（不安装）
pip download flask==3.1.1 -d ./downloads

# 查看 WHL 内容（WHL 就是 ZIP）
unzip -l ./downloads/flask-3.1.1-py3-none-any.whl

pkg-config快速入门指南

pkg-config 是一个帮助开发人员在编译和链接程序时发现和使用库的辅助工具。它提供了一种方法来获取库的编译和链接参数，使得在编译时链接库变得更加容易和一致。pkg-config 通常用于Unix-like系统，并且支持多种编程语言。

pkg-config 的工作原理是查询一个名为.pc的文件，这些文件包含了关于库的元数据，例如库的安装位置、编译器标志、链接器标志等。当你安装一个库时，通常会在/usr/lib/pkgconfig或/usr/share/pkgconfig目录下安装相应的.pc文件。

如何使用 pkg-config

查询库的编译和链接标志

使用pkg-config查询库的编译和链接标志是最常见的用途。例如，如果你想使用libopus库，你可以使用以下命令来获取编译和链接标志：

pkg-config --cflags --libs opus

这个命令会输出类似以下内容：

-I/usr/include/opus -lopus

这些标志可以直接在编译命令中使用。

uv 快速入门指南

uv 是一款由 Astral 团队（创始人 Charlie Marsh）使用 Rust 语言开发的高性能 Python 包管理器。它旨在解决传统工具如 pip 和 venv 在依赖解析、安装速度和整体效率上的瓶颈。

作为 Python 生态的现代化核心组件，uv 不仅提供数倍于 pip 的安装速度，还支持无缝兼容现有工具（如 pip、poetry 和 setuptools），让开发者能轻松过渡到高效的工作流。

无论你是初学者还是资深开发者，uv 都能简化项目管理、减少环境冲突，并加速开发迭代。

安装 uv

uv 的安装过程简单快捷，支持多种方式。推荐使用脚本安装，以获取最新版本和自动配置。

通过安装脚本

curl -LsSf https://astral.sh/uv/install.sh | sh

此命令会下载并执行安装脚本，将 uv 添加到你的 PATH 中。安装后，重启终端或运行 source ~/.bashrc（或对应 shell 配置）以生效。

vcpkg快速入门指南

Vcpkg 是由 Microsoft 和 C++ 社区维护的免费开源 C/C++ 包管理器，可在 Windows、macOS 和 Linux 上运行。 它是核心的 C++ 工具，使用 C++ 和 CMake 脚本编写。 它旨在解决管理 C/C++ 库的独特难题。

为什么使用 vcpkg？

  • 在特选注册表中有超过2300 个开源库可供选择，这些库会定期生成，用于验证 ABI 兼容性
  • 支持使用自己的自定义库包创建自定义库注册表
  • 适用于 Windows、macOS 和 Linux 的一致的跨平台体验
  • 使用任何生成和项目系统都可以轻松将库添加到项目
  • 从源生成依赖项或下载预生成的 ABI 验证二进制文件，默认提供 70 多个配置，并可针对特定要求进行无限自定义
  • 通过独特的版本控制设计，防止依赖项之间出现版本冲突和菱形依赖问题
  • 对于 MSBuild 和 CMake 用户：自动与生成环境集成，打造无缝获取依赖项的体验

CMake快速上手指南

CMake是一个跨平台的自动化构建系统，它使用配置文件（CMakeLists.txt）来生成标准的构建文件，如Unix的Makefile或Windows的Visual Studio工程文件。CMake旨在支持多平台源代码编辑和管理，并且可以用于管理复杂项目和大型代码库的构建过程。

CMake的主要特点包括：

  1. 跨平台: 支持在多种操作系统上构建项目，包括Windows、Linux、macOS等。

  2. 生成构建系统: 根据CMakeLists.txt文件生成适用于不同平台的构建系统或IDE项目文件。

  3. 可扩展: 允许用户通过编写自己的CMake模块和脚本来扩展其功能。

  4. 查找依赖: 能够自动查找并配置项目所需的外部库和依赖项。

  5. 配置选项: 提供丰富的配置选项，允许用户自定义构建类型、编译选项等。

  6. 安装规则: 支持定义安装规则，方便软件的打包和分发。

  7. 集成测试: 支持集成测试，确保代码质量。

  8. 社区支持: 拥有一个活跃的社区和丰富的在线资源，包括文档、教程和论坛。

  9. 适用于大型项目: 特别适合于大型项目和多语言支持的项目。

CMake通过提供一套统一的构建和配置接口，简化了在不同平台上编译和构建项目的复杂性，是许多开源项目和商业软件所采用的构建工具之一。

k8s环境下部署grpc的几种方案

笔者前段时间负责所在广告部门的ssp系统核心的几个grpc服务由虚拟机部署迁移到k8s环境下的技术方案设计与实施。本篇博文就专门介绍下k8s环境的部署grpc几个方案。这里面不涉及具体实施细节。我们k8s环境是采用华为云的k8s集群服务，我们ssp系统都是go语言开发的，这里面的grpc专指grpc-go。

容器是微服务的基石，可以做到每个服务快速autoscale，但随之带来的是服务的消亡是任意不定的，服务如何能够被调用方找到的难题。为了解决这个问题，就需要系统支持服务的注册和服务的发现。对于grpc来说，就是服务提供者grpc server会部署到多个k8s的Pod上，Pod的创建和消亡是任意时刻，不可预测，那就需要有一套机制能够发现grpc server所有Pod的端点信息，保证调用方(grpc client)能够及时准确获取服务提供方信息。所以grpc部署在k8s的方案也必要解决服务的注册和服务的发现。

此外调用方(grpc client)会维持grpc长连接，以及grpc底层使用HTTP/2协议，负载均衡不同与http和tcp，这一点在设计方案时候，也需要特别关注。

k8s service直连

K8s service是一个命名负载均衡器，它可以将流量代理到一个或多个Pod（这里面的service指的是ClusterIP类型的service)。grpc-go可以通过拨号直连到service，让service进行服务发现和负载均衡处理。

k8s service直连方案部署和开发简单，Pod扩容和缩容都可以及时感知。但是由于service负载均衡工作在4层，无法识别7层的HTTP/2协议，会导致负载均衡不均匀的问题。