我的博客

前言：为什么 PyPA 要自己造一个构建后端？Python 打包世界很长一段时间只有 setuptools。它功能强大，但问题也明显： setup.py 本质是可执行代码，有安全风险 配置分散在 setup.py + setup.cfg + MANIFEST.in 中 构建速度慢（每次都要执行 Python 代码来解析配置） PyPA 的目标是：一个纯声明式的、PEP 621 原生的、快速且可扩展的构建后端。这就是 hatchling。 hatchling 的定位：setuptools 的现代化替代品。不是”又一个新的打包工具”，而是”PyPA 认为 Python 打包该有的样子”。 它与 Hatch 的关系：Hatch 是项目管理器（类似 Poetry），hatchling 是其中的构建引擎。但你完全不需要安装 Hatch，hatchling 可以作为独立构建后端使用。 一、快速开始：3 行配置跑起来1.1 最小 pyproject.toml1234567[build-system]requires = ["hatchling"]build-bac...

前言：setuptools 凭什么统治 Python 打包二十年？打开 GitHub 上任意一个 Python 项目，你大概率会看到一个 setup.py，里面调用了 setuptools.setup()。二十年来，这几乎是 Python 打包的”唯一标准”。 即使2026年的今天，PyPA 力推 pyproject.toml，setuptools 仍是构建 C 扩展的唯一成熟选择，numpy、scipy、pandas、cryptography 等核心库全部依赖它。 本文以 setuptools 官方 Quickstart（v82.0）为基础，先讲透传统的 setup() 函数，再过渡到现代的声明式配置，让你读懂任何 setuptools 项目。 一、快速入门：5 分钟写出第一个 setup.py1.1 最小项目结构123456my-package/├── setup.py # 构建入口├── README.md└── my_package/ # 源码 ├── __init__.py └── core.py 1.2 第...

前言：为什么需要现代化Python打包？如果你写过Python项目，你一定遇到过这些问题： setup.py / setup.cfg / requirements.txt / MANIFEST.in 蔚为壮观，到底用哪个？ 依赖管理器混战：pip、pip-tools、Poetry、Pipenv各不相同 想发布到PyPI，但不知道该怎么开始 换电脑后项目不能一键安装，环境搭建痛苦不堪 项目维护者要维护好几个配置文件，头大如斗 这些问题的根源是：Python打包生态系统长期碎片化。2018年，Python社区通过 PEP 517 和 PEP 518 开启了现代化改革，随后 PEP 621 正式将 pyproject.toml 确立为唯一、统一的项目元数据文件，从此告别了多文件混战的时代。 📋 核心变化: 从 setup.py + setup.cfg + requirements.txt → pyproject.toml 一文档统治 本文基于 Python Packaging Authority (PyPA) 官方指南，将带你从零开始，完成从项目...

写在前面上一篇我们介绍了Qlib的整体架构和核心概念。这篇教程，我们将动手实践，从零开始构建一个完整的量化策略。 你将学到： ✅ 搭建Qlib开发环境 ✅ 获取和准备股票数据 ✅ 构建预测模型（LightGBM） ✅ 设计交易策略 ✅ 执行回测并分析结果 ✅ 优化策略参数 最终目标：构建一个能够预测沪深300成分股收益率的量化策略，并通过回测验证其有效性。 第一部分：环境搭建1.1 创建虚拟环境12345678# 使用conda创建Python环境conda create -n qlib python=3.10conda activate qlib# 或使用venvpython -m venv qlib_envsource qlib_env/bin/activate # Linux/Mac# qlib_env\Scripts\activate # Windows 1.2 安装Qlib1234567# 方式1：通过pip安装（推荐）pip install pyqlib# 方式2：从源码安装（获取最新功能）git clone https://github.com/mic...

前言：为什么选择Qlib？如果你是一名技术开发者，想要进入量化投资领域，你可能会面临这些问题： 数据从哪里来？ 如何高效存储和检索海量金融数据？ 特征怎么构建？ 158个技术因子？360个？还是自己一个个写？ 模型怎么选？ LSTM、LightGBM、Transformer…哪个适合金融预测？ 策略怎么回测？ 如何模拟真实交易环境，考虑滑点、手续费、流动性？ 如何系统化？ 怎么把数据处理、模型训练、策略回测串联成完整流水线？ Microsoft Qlib 正是为解决这些问题而生的AI量化投资平台。它不是一个简单的回测框架，而是一个覆盖量化投资全流程的机器学习研究平台。 Qlib的定位：AI-oriented Quantitative Investment Platform（面向AI的量化投资平台） GitHub: https://github.com/microsoft/qlib Stars: 14K+ 开发者：微软亚洲研究院 一、Qlib架构设计理念1.1 整体架构：四层设计Qlib采用分层架构设计，从底层基础设施到上层用户接口，共分为四层： 1234567891...

简介mattpocock/skills 是由 TypeScript 领域知名专家 Matt Pocock 创建的一套 AI 编码助手技能集合，旨在解决 AI 代理在日常开发中的常见失败模式。 一句话总结：这套技能让你的 AI 编码助手从”能跑就行”变成”真正靠谱”。 项目数据：⭐ 50K+ GitHub Stars | MIT 开源 | Shell 脚本 为什么需要这套技能？AI 编码助手（Claude Code、Codex、Cursor 等）很强大，但经常会遇到这些问题： 问题 表现 代理没按预期执行 你说东，它往西，最后发现是需求理解偏差 代理过于冗长 简单的事说半天，token 烧得心疼 代码无法工作 写完一跑就挂，缺乏测试反馈 代码变成泥球 功能有了，但架构一团糟，难以维护 这套技能正是为解决这些问题而生。 与其他方法的区别 方法 特点 限制 GSD / BMAD / Spec-Kit 拥有整个流程 剥夺控制权，流程 bug 难解决 Skills For Real Engineers 小型、易适应...

引言2026年，软件工程正迎来一场深刻的范式变革。如果说 Prompt Engineering 教会了我们如何与 AI “说话”，Context Engineering 解决了如何给 AI “喂信息”，那么现在，一个更加根本的问题浮出水面：如何让 AI 在生产环境中可靠、持续地运行？ 答案就是——Harness Engineering（驾驭工程）。 AI 模型是一匹拥有无限潜力的野马，Harness 就是那套精密的缰绳、马鞍和护栏。缰绳的目的从来不是为了限制，而是让潜能得到更安全、更彻底的释放。 什么是 Harness Engineering？核心定义 一句话总结：Harness Engineering 就是为 AI 智能体装上”护栏+仪表盘+刹车”，让它在生产环境中跑得快且不翻车。 Harness Engineering 是一套围绕 AI 智能体设计并构建约束机制、反馈回路、工作流控制及持续改进循环的系统工程实践。 其核心公式可以概括为： 12Agent = Model (LLM)Harness = Everything Else (Tools, Permissions...

简介OpenSpec 是一个轻量级的规格驱动开发（Spec-Driven Development, SDD）框架，专为 AI 编码助手设计。 项目数据：42K+ GitHub Stars | 60+ Contributors | MIT 开源 | TypeScript 为什么需要 OpenSpec？AI 编码助手很强大，但当需求只存在于聊天历史中时，它们就变得不可预测。OpenSpec 添加了一个轻量级的规格层，让你在编写任何代码之前就与 AI 达成一致。 核心问题： AI 输出与你期望不符 需求模糊导致实现模糊 聊天历史中的上下文丢失 团队协作时意图传递困难 OpenSpec 的解决方案： 先同意再构建 — 人类和 AI 在编写代码之前对齐规格 保持组织 — 每个变更都有自己的文件夹，包含提案、规格、设计和任务 流畅工作 — 随时更新任何产物，没有刚性阶段门槛 使用你的工具 — 通过斜杠命令支持 25+ AI 助手 核心理念1234→ fluid not rigid （流畅而非僵化）→ iterative not waterfall（迭代而非瀑布）→ ...

简介Spec Kit 是 GitHub 开源的规格驱动开发（Spec-Driven Development）工具包，帮助开发者更快地构建高质量软件。 项目数据：28K+ GitHub Stars | 11+ AI Agents | 2.3K+ Forks | MIT 开源 什么是 Spec-Driven Development？Spec-Driven Development（规格驱动开发）颠覆了传统软件开发方式。 几十年来，代码一直是王 — 规格只是我们构建后就丢弃的脚手架，一旦”真正工作”的编码开始。Spec-Driven Development 改变了这一点：规格变成可执行的，直接生成可工作的实现，而不仅仅是指导它们。 传统开发 Spec-Driven Development 规格是脚手架，编码后丢弃 规格是可执行的第一类产物 从想法直接跳到代码 规格 → 计划 → 任务 → 实现 AI 输出不一致，因为提示模糊 AI 输出一致，因为上下文结构化 一次性代码生成 多步骤精细化流程 为什么需要 Spec Kit？当你使用 AI 编码助手时，常见问...

简介Superpowers 是一个完整的软件开发方法论，专为编码代理（coding agents）设计。它建立在可组合技能（skills）和初始指令之上，确保你的 AI 编码助手能够更智能、更系统地完成开发任务。 为什么需要 Superpowers？当你启动编码代理时，它通常不会停下来思考你真正想要做什么，而是直接跳入编写代码。Superpowers 改变了这一点： 先思考后编码 - 代理会先理解你的需求，提炼出规格说明 分块展示设计 - 将设计分成易于消化的小块供你审阅 制定清晰计划 - 为”热情但缺乏判断力的初级工程师”级别的执行者提供可遵循的实施计划 自主执行 - 代理可以自主工作数小时而不偏离计划 核心理念 原则 说明 测试驱动开发 (TDD) 始终先写测试，永远不跳过 系统化优于临时方案 流程优于猜测，过程优于假设 降低复杂度 简洁是首要目标，小文件优于大文件 证据优于声明 验证后再宣布成功，看到测试失败再写代码 技能优先级Superpowers 技能覆盖默认系统行为，但用户指令始终优先： 用户的显式指令 (CLAUDE.md, GEMI...