🌿 简化 Git 分支工作流（个人 / 小团队） 本工作流基于 Git Flow 精简而来，适合个人或小团队，既规范又不复杂。 🚀 1. 主分支（长期分支） main 永远保持稳定、可发布的状态。 部署到生产环境的代码都来自这里。 对于小团队，通常只需要 main，不需要维护 develop。 🛠️ 2. 功能开发（Feature Branch） 分支命名：feature/<功能名> 用途：开发新功能，完成后合并回 main。 示例： feature/login-api feature/user-profile 流程： # 从 main 创建功能分支 git checkout -b feature/login-api main # 开发完成后，合并到 main git checkout main git merge feature/login-api git branch -d feature/login-api 🐞 3. Bug 修复（Bugfix Branch） 分支命名：bugfix/<问题名> 用途：修复测试或开发环境的 bug。 示例： bugfix/fix-login-redirect 流程同 feature 分支，完成后合并回 main。 🔥 4. 紧急修复（Hotfix Branch） 分支命名：hotfix/<问题名> 用途：生产环境出现严重问题时的快速修复。 示例： ...

在本地使用 Git 裸仓库实现开发环境和测试环境隔离 在全栈开发的过程中，我们常常遇到一个问题：开发环境和测试环境如何隔离？ 很多人第一反应是用 GitHub 或 GitLab 来托管代码，但如果项目涉及隐私，不方便放在公共仓库，那该怎么办呢？ 其实，Git 是分布式的，我们完全可以在 本地电脑上建立一个“裸仓库 (bare repo)”，当作“远程仓库”来用，从而实现 开发环境 → 测试环境 的代码迁移和同步。 什么是裸仓库 (bare repository) 普通 Git 仓库（git init）包含 工作区 + .git 元数据，可以直接编辑文件。 裸仓库（git init --bare）只有 Git 的版本信息，没有工作区，不能直接编辑文件，通常作为 远程仓库 来存储和同步代码。 简单理解： 开发仓库：我在这里写代码。 裸仓库：我用来存放代码历史，作为远程同步点。 测试仓库：从裸仓库克隆出来，模拟运行环境。 步骤一：创建裸仓库 在本机某个目录（比如 ~/.repos）下创建裸仓库： mkdir -p ~/.repos cd ~/.repos git init --bare scrapy.git 这样你得到一个路径 ~/.repos/scrapy.git，它就是本地的远程仓库。 步骤二：在开发仓库里添加远程 假设你的开发仓库在 ~/scrapy： cd ~/scrapy git remote add local ~/.repos/scrapy.git 检查一下远程是否添加成功： git remote -v 输出类似： local /home/gong/.repos/scrapy.git (fetch) local /home/gong/.repos/scrapy.git (push) 说明配置成功。 ...

Python 日志与追踪 Python 日志追踪实践 结构化日志与追踪 副标题/摘要： 结合 logging + OpenTelemetry 实现结构化日志并把 trace_id 注入日志，便于在生产环境串联调用链与定位问题。 TL;DR： 设置 json 格式日志并通过 OpenTelemetry 在每条日志里注入 trace_id/span_id。关键步骤：安装依赖 → 配置 logging（JSON）→ 配置 TracerProvider → 用 Filter 从当前 span 提取 trace 信息并添加到日志记录中。 目录 背景与动机（为什么需要） 关键概念与术语解释 环境与依赖（安装命令） 逐步实战示例（可直接运行） 原理与实现要点 常见问题与注意事项 最佳实践总结 结论与下一步建议 可视化建议 参考与延伸阅读 可复制示例代码 背景与动机（为什么需要） 现代后端服务分布式部署后，单靠文本日志很难把一次请求链路从入口到后端串起来。结构化日志（JSON）便于聚合与查询；而分布式追踪（tracing）给出调用链与 span 信息。二者结合能快速定位延迟与错误根因：日志告诉你“发生了什么”，trace 告诉你“这个请求经过了哪些服务/操作”。 关键概念与术语解释（简明） 日志（Logging）：程序运行时的事件记录，通常按级别（INFO/ERROR）输出。 结构化日志：以 JSON 等结构化格式输出，便于机器处理与检索。 Trace/Span：一次分布式操作（trace）由若干子操作（span）组成，span 含有 trace_id 与 span_id。 Context Propagation：在不同服务/线程/协程中传递 trace context 以串联调用链。 环境与依赖（列出安装命令） 推荐环境：Python 3.8+ 安装依赖： pip install python-json-logger opentelemetry-api opentelemetry-sdk ...

Introduction 对于typescript以.ts为后缀的文件,我们是不能直接编译运行的,我们需要把typescript文件转译为js文件然后再进行运行 我们可以选择两种方式,把ts文件传到服务器上使用ci工具进行编译,或者直接在本地转译后上传js文件到生产环境,如果我们想要在开发环境中直接进行运行测试的话,可以使用ts-node进行运行,但是开发环境之中还是需要编译

Introduction 我现在想要构建一个可以树状,或者图状进行问答的ai系统,而不是传统的单线式对话流程 探索 开源框架探索 flowise

如何尽可能掌握一篇论文中的所有知识 结论 我们要真正"掌握"一篇论文,不是读一遍就行,而是按照现有结构把论文进行拆解,验证,重构并把关键点转化为你自己的表述或者实现.目标是:可以在5分钟内讲清楚核心贡献,可以手推关键公式,可以实现并复现一个核心实验 原理和背景 论文是作者对问题的压缩表达：省略背景、实验细节、直觉和失败。要掌握，需要把这种高密度信息“解压”回你自己的知识网络：理解背景假设、数学推导、工程实现、以及结论的适用范围。这样才能判断什么时候能用，什么时候不能用，什么时候要改进。 具体步骤 不要把论文当成“权威”，把它当成一个可以测验的主张：把声明分解成可验证的小断言，然后去验证它。掌握不是记住论文的文字，而是把它变为你自己能用的工具。不要偷懒 — 真正的理解需要做事：推导、实现、对比、解释。现在就挑一篇，按上面的三天计划开始。 准备与预读（30–60 分钟） 读题目、摘要、结论、图表（不必细读正文）。目的：抓住“这篇论文到底解决了什么问题、给出了什么结果”。 快速扫一遍引言和贡献列表，记录作者声称的三个关键点。 检查参考文献，确定是否需要补读哪些基础材料（比如某个经典算法或证明）。 精读（2–6 小时） 逐段细读方法/理论部分。遇到公式，尝试手推关键推导（用纸和笔）。 把每个重要符号写成表格，免得混淆。对算法，写伪代码。 标注不理解/可疑的地方，形成问题清单。 解构与重构（半天到几天） 把论文分解为：问题定义、关键假设、方法/算法、主要定理、实验设置、结论与限制。 为每一部分写一段 2–3 句的“我能讲给同领域的人”的解释（用你自己的话）。 将算法实现为最小可运行版本（See 实现建议）。 实现与复现（几小时到几天） 优先实现最能体现贡献的部分（一个算法/一个模型/一个关键实验）。 用小规模合成数据先做调试，再跑论文的设置。 必要工具/模板示例： 推荐环境：Python + Jupyter/Colab，或 C++/Rust（如果是系统/性能论文）。 常用库：numpy/pandas/matplotlib/scikit-learn/torch/tensorflow。 示例：把论文算法写成 Python 函数（伪代码转实现）。 逐行注释已写在函数 docstring 和代码中。把论文中的符号映射到代码变量，记录在注释里。 绘图与结果对比 重现关键图表（训练曲线、误差表）。如果不能一次跑出论文结果，先验证趋势和相对对比（例如比基线高多少）。 加入断言和单元测试：例如，对已知问题（合成数据）的行为应与理论一致。 消化与输出（持续） 把关键点写成一页“cheatsheet”或一篇短博客，目标：在五分钟内让人理解。 将难点做成 Anki 卡片（问题：关键假设、定理条件、公式推导步骤）。 尝试解释给陌生人或写读书报告。 工具推荐（实操） 文献管理：Zotero / Mendeley 笔记与知识库：Obsidian / Notion / org-mode 代码与实验：Git + Jupyter/Colab + Docker（必要时复现环境） 文本处理：pdftotext、pdfgrep、grep、ripgrep 常见错误 错误：只读不做（只看结论，不推导、不实现）。 调试：强制自己实现或至少写伪代码并手推一遍。 错误：忽视假设/边界条件（在不满足假设的地方直接使用方法）。 调试：列出所有假设，构造违反假设的测试用例，观察失败模式。 错误：把作者的实现等同于论文中的方法（代码细节、超参常被省略）。 调试：阅读作者代码（如开源），比对论文描述，记录差异。 错误：过早追求论文结果的数值精确复现。 调试：先验证可复制的趋势，再逐步细化超参/实现细节。 错误：数学推导只看结论公式，未验证每一步是否合法。 调试：逐行手推，找出隐含步骤或引用的引理，补读来源。 验证方法 能在五分钟内口述论文的核心贡献、适用场景与限制（不看稿）。 能手动推导关键公式或重写证明的主要步骤（纸笔完成）。 能实现一个最小工作例子，得到与论文一致的趋势或数值（至少在合成数据上）。 能回答以下问题：作者的关键假设是什么？结果如何依赖这些假设？有哪些潜在失败模式？ 能把论文的想法应用到一个稍有不同的问题上并观察结果（迁移能力）。

Introduction Mermaid是一个用于使用代码创建图像的框架,今天的博客,我们将会简单介绍如何在自己的服务器上安装相关的框架,并对代码进行渲染生成图像 具体步骤 如何安装渲染框架 使用 npm install -g @mermaid-js/mermaid-cli 就可以安装 需要注意的是该框架使用的npm版本需要大于20,所以我们需要切换npm版本,推荐使用nvm管理npm的版本 如果没有nvm的话,使用下列命令进行安装 curl -o https://raw.githubusercontent.com/nvm-sh/nvim/v0.39.4/install.sh | bash 然后对shell进行重启 然后使用 nvm install 20 nvm use 20 nvm alias default 20 进行安装,并把默认npm切换为20 可以使用 node -v npm -v 确认版本 如何进行渲染 将需要渲染的代码放置在以.mmd结尾的文件中 然后使用 mmdc -i diagrams/example.mmd -o images/example.svg 即可

这篇论文解决了什么问题,给出了什么结果 首先我们知道AI系统现在广阔发展,可以像人类一样解决很多通用问题,但是现在发展中的ai agent系统所制作的大量应用作用于一些很小的任务,然后nvidia在这篇文献中提出了小语言模型(SLMs) 有着足够的能力,更适合,而且也更廉价,对于很多agent系统,也应该作为后来ai agent的一个主要发展方向 然后针对与其提出的这个论点,该论文进行了以下几点讨论 1.当前小语言模型可以做到的任务 2.在某些通用语言能力是重要的部分 3.讨论了小模型作为agent系统的潜力界限 结论,介绍了不管是从能力还是经济价值方面,从LLMs移动到SLMs的优势