王忠亮的博客

LLM 入门学习路线：从零开始的实践记录

Fri, 05 Jun 2026 00:00:00 GMT

这篇文章记录我从零开始入门 LLM（大语言模型）的学习路线和实践过程，包括精选的学习资源、环境搭建经验和实战练习记录。

为什么学 LLM？#

不是跟风。而是意识到：LLM 正在改变软件的形态。从 ChatBot 到 Agent，从 RAG 到 Function Calling，这些不是概念游戏 — 它们是新一代应用的基础设施。所以决定系统性地入门，而不是东一榔头西一棒槌地看碎片文章。

学习资源清单#

经过筛选，以下是我认为最值得投入时间的资源：

精选仓库#

仓库	说明	状态
Shubhamsaboo/awesome-llm-apps	Agent、RAG、Voice AI 实战项目集	✅ 已下载
microsoft/generative-ai-for-beginners	微软 18 课入门，有中文版	📌 已下载
mlabonne/llm-course	社区公认最好的 LLM 学习路线	📌 待看
openai/openai-cookbook	OpenAI 官方代码示例	📌 待看
punkpeye/awesome-ai-agents	AI Agent 大全，找灵感用	📌 待看

环境搭建#

我的开发环境如下：

Python：3.12.9（虚拟环境 venv）
框架：LangChain
模型：DeepSeek API
项目目录：~/langchain-demo/

搭建过程很顺利。Python 虚拟环境用 venv 创建，然后 pip install langchain 就行。DeepSeek 的 API key 放到 .env 文件里，用 python-dotenv 加载。这是基本但干净的项目结构。

练习记录#

1. hello_langchain.py — 第一个 LangChain 脚本#

最简单的调用：通过 LangChain 的 ChatOpenAI 接口（设置 base_url 指向 DeepSeek API）完成一次对话。验证了环境的联通性，也确认了 DeepSeek 模型的响应质量。

2. test_gen.py — 测试用例自动生成器#

这是第一个有实际价值的练习。写了一个脚本：

输入：接口描述（API endpoint、参数、返回格式）
输出：测试用例（正常情况、边界值、异常输入）
用 LangChain 的 PromptTemplate 做模板化提示词

让它生成一个简单的 REST API 测试用例，效果不错。核心就是一个好的 prompt + 模型的理解能力。

3. LangChain vs 裸 API — Agent 循环对比#

为了理解 LangChain 到底封装了什么，做了一个对比实验：

裸 API：自己维护对话历史，手动拼接系统提示和用户消息，处理 token 计数
LangChain：用 ChatMessageHistory 管理上下文，PromptTemplate 做模板，输出解析器处理回复

结论：LangChain 的价值在于抽象了通用模式（对话管理、模板、工具调用），但理解底层机制后，小项目用裸 API 更灵活。

4. rag_demo.py — 最小 RAG 演示#

RAG（检索增强生成）是目前 LLM 应用最热门的模式之一。做一个最简单的版本：

用一个小文档库作为知识源
用户提问后，先把问题向量化，检索最相关的文档片段
把检索到的片段作为上下文注入 prompt，让模型基于这些信息回答

这个练习让我理解了 RAG 的核心链路：文档 → 分块 → 向量化 → 存储 → 检索 → 注入 → 生成。LangChain 在这条链路上提供了不错的工具封装。

我的学习策略#

不求多，求准。不求全记，求用得上的能调。

遇到一个问题 → 去找对应的工具/文章 → 动手实现 → 提取能复用的模式
不追求看完所有课程，追求能上手做东西
用日记把学到的记下来，需要的时候能搜到就行

下一步计划#

系统学习微软 generative-ai-for-beginners 课程
深入 Agent 方向：工具调用、多 Agent 协作
做一个有点实际价值的项目

总结#

LLM 入门并不神秘。搭环境、调 API、写 demo，和学任何新技术没什么两样。真正有价值的是动手做东西的时候踩的坑和想通的事 — 那些才是自己的。

逻辑学笔记：思维检票员的自我修养

Thu, 04 Jun 2026 00:00:00 GMT

学逻辑不是为了变得伶牙俐齿，而是为了在自己心里装一个检票员：「你这段推理的票，给我看看。」

为什么会有逻辑#

逻辑存在，是因为人需要在信息不完全的情况下做出正确判断。

如果人全知全能，不需要逻辑 — 所有问题直接有答案。但人不是。人活在信息永远不够的世界里，逻辑就是那个从已知推到未知的桥梁。

三个前提决定了逻辑的必要性：

世界是有规律的：如果世界是彻底的随机混沌，逻辑不存在也没用。但世界有因果、有结构，逻辑是对这种规律的抽象和形式化。
人脑有极限：人一次只能处理有限信息，容易偏误、被情绪带跑。逻辑是人给自己造的拐杖 — 按规则推，至少不容易错。
沟通需要共识：没有逻辑的争论，最终比的是嗓门和拳头。逻辑提供了可复现、可检查、可反驳的讨论框架。

一个比喻：逻辑之于思维，就像语法之于语言。不学语法也能说话，但容易语无伦次。学了语法不一定能说出漂亮话，但至少不会把意思说反。

逻辑的本质：从已知推出大概率正确的结论#

逻辑的本质可以精确定义为：从已知信息出发，按规则推演，得到一个在当前信息下最可能为真的结论。

注意这个定义里的几个关键点：

从已知出发 — 逻辑不能无中生有。前提是空的，推不出任何东西。
按规则推演 — 不是拍脑袋，是遵循推理规则。
最可能为真 — 逻辑不生产真理，逻辑生产「可信度排名」。

为什么不是100%？演绎逻辑（三段论）在封闭系统里可以到100%，但现实世界里的逻辑给的从来不是一个确信值。信息变了，结论也可以变。科学就是这个过程 — 不断逼近，从不宣称绝对正确。

「既定」陷阱：从答案反推原因#

一个非常重要的逻辑洞察是「既定推理」：已知一个正确的结果，反推它成立的条件和原因，并且保证推理链条干净。

这种逆向推理本身不是问题 — 科学中经常用。但这里藏着一个巨大的坑：偷换条件。

有人把条件换成相似但不一致的东西，却声称能推出同样的答案。

例子：

正确：如果天下雨，地会湿。地湿了 → 可能是因为下过雨。
偷换：如果天下雨，地会湿。地湿了 → 所以下过雨（忽略了洒水车、水管爆裂、露水等可能）。

更隐蔽的版本：你用A推导出B，他把A悄悄换成A’（看着像A但不一样），然后说「你看，按你的逻辑，B成立」。实际上前提已经不是你的前提了。

一个判断标准：当你觉得「好像有道理但又说不上哪里不对」— 那就大概率是条件被偷换了。

黄金屋理论：信息量与推理能力#

一个核心观点：信息是推理的燃料。没有信息，逻辑再强也是空转。

信息越多，推理能力越强。 巧妇难为无米之炊 — 推理能力再强，前提是空的，推不出任何东西。
足够多的信息可以自我纠错。 单一信息源容易骗人，但当你读了10本不同立场的书，矛盾的地方会自己打架。信息量大了，错误会自己暴露。
获取 ≠ 内化。 获取是眼睛扫过去了，内化是能用自己的话讲出来。中间差着一道工序：加工。读书本身不消化，读完停下来想想、写写笔记、跟人聊聊 — 才是内化。

策略建议：不求多，求准。不求全记，求用得上的能调。你不是要装下所有东西，而是要知道什么东西在哪能找到。

案例分析：马哲「量变引起质变」的逻辑拆解#

「量变引起质变」—— 这个命题听起来没毛病，但仔细拆解会发现漏洞。

「一定条件」是个空洞的占位符#

水烧到100°C变成水蒸气 → 「一定条件」= 达到沸点。你每天练琴突然某天弹好了一首曲子 → 「一定条件」= 练习量突破技能阈值。但马哲把它写成「一定条件下」时，相当于说：就是会发生变化的那个点。这不是解释，是重新描述了一遍现象，然后贴了个标签。

性质变化 vs 身份变化#

这个区分非常关键：水 → 水蒸气是性质变了（液态→气态），但H₂O这个身份没变。你今天投了50份简历都没回音，投到第51份有了面试 — 这是身份变了（从待业变成有面试的人），但你性质没变，能力没突变。

量变引起质变这个命题模糊了两种「变」：

渐变：量在积累，性质在慢慢滑动
突变：积累到某个阈值，咔嚓一下换了个状态

两者的机制完全不同。渐变不需要「一定条件」，它一直在变。突变需要触发条件，但这个条件往往不是量变本身带来的（水到100°C不是水的选择，是环境气压决定的）。

终极追问：量变本身不保证质变#

量变只保证量变。质变需要另一个独立的条件来触发。 一匹马吃草，吃再多草也不会变成牛。量再多，如果系统结构没变，质变不会发生。

马哲把「在一定条件下」轻轻带过了，但这个条件恰恰是整个命题里最关键的变量。对自然界（水烧开），度和关节点是可测量的。对社会领域（阶级跃迁），度和关节点无法精确计算 — 你只能事后回头看才知道在哪，事前无法预判。

宏大叙事的悖论#

如果把上述分析方法放大到一个完整的哲学体系——比如马克思主义哲学——会发现一个深刻的悖论：

前提A：马克思主义是半成品，需要后人发展
前提B：发展不能动摇根本原则
问：如果根本原则本身就是错的，这个发展是在干什么？

答案很尴尬：在错误的地基上盖装修。

「我是半成品，你们来发展我」— 这句话听起来极为谦逊、开放、科学。但它暗含了一个不可质疑的前提：我的方向是对的，你们只是帮我补细节。如果地基错了，装修得再漂亮，楼也是歪的。

这不是马哲特有的问题，是所有封闭的宏大叙事共有的结构：它在系统内部留了一个更新接口，但这个接口只能打补丁，不能改底层代码。一旦有人想改底层代码，系统会说：「你这是歪曲，不是发展。」

科学 vs 信仰：分界线在哪#

科学最本质的特征是什么？不是正确，是愿意承认自己错了。

一个更精确的区分：

科学：愿意被证伪。新的证据来了，旧理论可以修正或推翻。
非科学/信仰：拒绝被证伪。任何反例都被解释为「你还没理解」或「这是发展中的特例」。

用这个标准回看马哲：它有科学的野心（认识世界、改造世界），但后来走向了信仰 — 它拒绝被证伪。它的「发展」有红线，只打补丁不改底层代码，这不是真正的发展。

从科学变成信仰，就已经不是很科学的事情了。

总结#

这一路讨论的几个关键里程碑：

为什么存在逻辑 → 信息不全时需要桥
逻辑的本质 → 从已知推出大概率正确的结论
「既定」陷阱 → 从答案反推原因，条件容易被偷换
学逻辑的目标 → 给自己装一个检票员
黄金屋理论 → 信息是推理的燃料，错误信息能被信息量压死
量变引起质变的漏洞 → 「一定条件」是空洞占位符
宏大叙事的悖论 → 允许打补丁，不允许改底层代码
科学与信仰的分界线 → 科学愿意认错，信仰不愿意

核心收获不是记住了哪条定理，而是养成了一种思维习惯：任何一段推理，都问一句 — 前提成立吗？条件被换了吗？这个体系是为了解释世界，还是为了证明某个结论而建的？

检票员上岗了。

如何高效阅读技术论文：一个本科生的实践方法

Thu, 28 May 2026 00:00:00 GMT

阅读技术资料是程序员成长的核心能力。无论你处于哪个阶段，快速而深入地理解一篇技术文章或论文都是一项需要刻意练习的技能。

为什么要系统化读论文？#

很多人一开始读技术文章的方式是”从头读到尾”，像是在读一本教科书。但技术文章并不是为线性阅读而设计的。一篇高质量的技术文章通常包含密集的信息，如果逐字逐句地阅读，很容易迷失在细节中，反而忽略了核心思想。

系统化的阅读方法可以帮助我们：

快速筛选出值得精读的论文
在有限时间内抓住核心思想
建立论文之间的关联，形成知识网络
为后续复现和拓展研究打好基础

三遍阅读法#

我采用三遍阅读法：

第一遍：粗读（5-10 分钟）#

目标是判断这篇论文是否与自己相关。需要重点阅读：

标题和摘要：了解论文的主题和核心贡献
引言：理解研究动机和问题背景
结论：了解主要发现和未来工作
图表：快速浏览实验效果

读完这四部分，你应该能回答：这篇论文在解决什么问题？方法的核心 idea 是什么？实验结果支持他们的结论吗？

第二遍：精读（30-60 分钟）#

对于值得深入阅读的论文，进行第二遍精读：

仔细阅读方法部分，理解技术细节
分析实验设置和评估指标是否合理
标记出不清楚或值得质疑的地方
在空白处写下自己的理解和思考

一个好的习惯是：读完一篇论文后，尝试用自己的话向别人复述这篇论文的核心贡献。如果你能讲清楚，说明你真的理解了。

第三遍：深读（1-2 小时）#

只有少数与你研究方向高度相关的论文才需要第三遍阅读。这个阶段需要：

深入理解每个技术细节，甚至推导公式
思考方法的局限性和可能的改进方向
阅读相关工作，将论文放入更广阔的学术脉络中
考虑能否将方法应用到自己的研究中

文献管理工具推荐#

工欲善其事，必先利其器。以下是我日常使用的文献管理工具链：

Zotero：文献管理的主力工具，通过浏览器插件一键抓取论文信息
Connected Papers：可视化论文之间的引用网络，帮助发现相关文献
Notion：记录论文阅读笔记，支持 LaTeX 公式和标签分类
Obsidian：建立论文笔记之间的双向链接，构建个人知识库

每篇论文读完，我都会在 Zotero 中标注重要程度和阅读状态，并在 Notion 中写一篇简短的阅读笔记，包括：论文信息、核心贡献、方法概述、优缺点和可借鉴的点。

总结#

读论文是一个”量变引起质变”的过程。开始时可能很慢，但随着阅读量的增加，你会越来越快地抓住论文的核心。关键是保持持续阅读的习惯，并有意识地运用系统化的方法。

参考资源：

Next.js App Router 深入浅出

Fri, 15 May 2026 00:00:00 GMT

Next.js 的 App Router 是一次彻底的路由革命。它不只是换了个文件组织方式，而是从根本上改变了我们构建 React 应用的方式——从客户端渲染走向服务端优先。

为什么 App Router 是一个大版本更新？#

Pages Router（即传统的 /pages 目录模式）从 Next.js 诞生起就陪伴着我们。它的模型很直观：文件即路由，每个页面对应一个 React 组件。但随着 React 生态的进化，这种模式逐渐暴露了瓶颈。

App Router 的诞生带来了三个核心变化：

服务端组件（RSC）：组件默认在服务端渲染，减少客户端 JS 体积
嵌套布局：通过 layout.js 实现真正的布局复用，而非手工嵌套
流式渲染：结合 loading.js 和 Suspense，实现按需加载

App Router 的核心概念#

文件约定#

App Router 使用一套约定式文件命名体系，每个特殊的文件名对应特定的 UI 行为：

1
app/
2
├── layout.js         # 共享布局（包裹子页面）
3
├── page.js           # 页面内容
4
├── loading.js        # 加载态 UI
5
├── error.js          # 错误边界
6
├── not-found.js      # 404 页面
7
├── global-error.js   # 根级错误处理
8
└── route.js          # API 路由（替代 pages/api）

布局嵌套#

布局是 App Router 最实用的设计之一。每个文件夹可以有一个 layout.js，它自动包裹当前路径下的所有页面：

1
app/
2
├── layout.js           # 全局布局（导航栏 + 页脚）
3
└── dashboard/
4
    ├── layout.js       # 仪表盘布局（侧边栏）
5
    └── settings/
6
        └── page.js     # 同时继承两个布局

这种机制意味着你不再需要手工组合布局组件，Next.js 会自动为你构建布局树。更重要的是，布局在导航时不会重新渲染，只更新子页面内容。

服务端组件 vs 客户端组件#

App Router 中，所有组件默认是服务端组件。这意味着：

你可以直接在组件中使用 async/await 获取数据
数据库查询、文件读取等操作在服务端安全执行
减少发送到客户端的 JS 体积

当你需要使用 useState、useEffect、事件处理等交互功能时，在文件顶部声明：

1
"use client";
2

3
import { useState } from "react";
4

5
export default function Counter() {
6
  const [count, setCount] = useState(0);
7
  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
8
}

关键思路：只在需要交互的地方使用客户端组件，其余保持服务端组件。你的应用体积会大幅减小，性能自然提升。

数据获取：服务端是起点#

App Router 推荐的服务端数据获取方式直截了当：

1
// app/posts/page.js — 这是一个服务端组件
2
async function getPosts() {
3
  const res = await fetch("https://api.example.com/posts");
4
  return res.json();
5
}
6

7
export default async function PostsPage() {
8
  const posts = await getPosts();
9
  return (
10
    <ul>
11
      {posts.map(post => (
12
        <li key={post.id}>{post.title}</li>
13
      ))}
14
    </ul>
15
  );
16
}

展开收起

配合 loading.js 和 error.js，你可以轻松实现流式加载和错误处理，而不需要手动管理 loading/error 状态。

路由组与并行路由#

App Router 还提供了更高级的路由模式：

路由组（Route Groups）：通过 (groupName) 文件夹组织路由而不影响 URL 路径
并行路由（Parallel Routes）：通过 @slot 实现同一布局内多独立区域渲染
拦截路由（Intercepting Routes）：通过 (.) 前缀实现模态框等模式

从 Pages Router 迁移建议#

如果你的项目还在使用 Pages Router，不必急于全量迁移。应用策略：

新功能直接使用 App Router
Pages Router 和 App Router 可以共存
先迁移布局（layout），再逐步迁移页面
注意 getServerSideProps → 直接 async 组件
注意 getStaticProps → generateStaticParams

总结#

App Router 不是花哨的营销噱头，它是 React 全栈框架发展的必然方向。服务端组件 + 嵌套布局 + 流式渲染的组合，让开发者能够以更直观的方式构建高性能 Web 应用。如果你是 Next.js 新手，直接学 App Router 就好；如果已经在用 Pages Router，逐步迁移即可。

参考资源：

搭建高效的开发工作流

Mon, 20 Apr 2026 00:00:00 GMT

从毕业实习到独立维护项目，我踩过不少效率的坑——合并冲突打半天、测试只在上线前跑一次、手动部署到凌晨三点。后来我花时间系统地打磨了开发工作流，把重复劳动降到最低。这篇文章分享的是我实际每天都在用的工具链和规范，不是纸上谈兵。

一、Git 工作流：分支策略与提交规范#

好的 Git 工作流是团队协作的基石。我团队采用的是简化版 Git Flow，适合大多数中小项目：

1
main        ──── 稳定发布分支，只接受 PR 合并
2
  ├── develop    ──── 集成分支，日常开发基干
3
  │     ├── feat/xxx  ──── 功能分支，从 develop 切出
4
  │     ├── fix/xxx   ──── 修复分支
5
  │     └── refactor/ ──── 重构分支
6
  └── hotfix/xxx ──── 紧急修复，从 main 切出并合回 main

几条铁律：

不要直接往 main 推送代码。所有变更通过 Pull Request 合入，即使是一个人开发，这条习惯也能帮你养成代码审查意识。
分支名称携带上下文。例如 feat/user-auth-jwt 比 feature-v2 好一百倍——三个月后你看 log，光凭分支名就能知道当时在干什么。
及时删除已合并的分支。git branch --merged | grep -v "\*" | xargs git branch -d 这条命令我每周跑一次。

提交信息规范#

我用 Conventional Commits 已经两年了，强烈推荐。格式很简单：

1
<type>(<scope>): <subject>
2

3
<body>

常用的 type 包括：

feat — 新功能
fix — 修复 bug
chore — 构建/工具变更
refactor — 重构
docs — 文档变更
test — 测试相关
style — 代码格式（非逻辑变更）

实际例子：

1
feat(auth): 接入 JWT 令牌刷新机制
2

3
- 添加 refresh_token 接口与自动续期逻辑
4
- 前端 Axios 拦截器处理 401 自动刷新
5
- 更新相关单元测试

配合 commitlint + husky，在 commit hook 里自动校验格式，不符合规范直接拒绝提交。坚持一个月后，看 git log --oneline 就像在读 changelog。

二、编辑器配置：VS Code 效率翻倍#

编辑器是开发者待得最久的地方，花一小时配置它，每天省下半小时。

必装扩展#

Prettier — 代码格式化唯一真理，团队统一配置 .prettierrc
ESLint — JS/TS 静态分析，配合 save 时自动修复
GitLens — 行内 git blame、历史对比，排查回归的利器
Error Lens — 行内错误高亮，不需要悬停才知道哪里错了
GitHub Copilot — AI 补全，对模板代码和单元测试特别高效
Path Intellisense — 路径自动补全，少敲很多斜杠

settings.json 核心片段#

1
{
2
  "editor.formatOnSave": true,
3
  "editor.defaultFormatter": "esbenp.prettier-vscode",
4
  "editor.codeActionsOnSave": {
5
    "source.fixAll.eslint": "explicit"
6
  },
7
  "editor.minimap.enabled": false,
8
  "editor.cursorBlinking": "phase",
9
  "workbench.startupEditor": "none",
10
  "files.autoSave": "onFocusChange",
11
  "terminal.integrated.defaultProfile.windows": "PowerShell",
12
  "git.autofetch": true
13
}

几个值得注意的点：

关闭 minimap，节省空间留给代码本身
开启 formatOnSave + ESLint fixOnSave，提交前几乎不需要手动格式化
git.autofetch 自动拉取，避免每天上班第一件事就是 git fetch

快捷键肌肉记忆#

以下快捷键值得花一个周末形成肌肉记忆：

Ctrl+P — 快速打开文件（配合模糊搜索，比鼠标点目录快 3 倍）
Ctrl+Shift+P — 命令面板，几乎任何操作从这里出发
Ctrl+D — 选中下一个相同的词，批量改名神器
Alt+↑/↓ — 整行上下移动
`Ctrl+“ — 打开/关闭终端

三、终端配置：告别低效敲命令#

我用的是 Windows Terminal + PowerShell 7 + Oh My Posh 的组合。配置好后，终端不再是一个黑框，而是一个高效的命令行工作台。

Oh My Posh 主题#

我用的是 jandedobbeleer 主题，它会在提示符里显示：当前 Git 分支、状态（是否有未提交文件）、上一命令执行耗时、当前目录。视觉上就能感知仓库状态，不需要手动敲 git status。

Terminal window

1
# 安装（Windows）
2
winget install JanDeDobbeleer.OhMyPosh
3
# 配置到 PowerShell profile
4
oh-my-posh init pwsh --config "$env:POSH_THEMES_PATH\jandedobbeleer.omp.json" | Invoke-Expression

实用别名#

我在 $PROFILE 里配置了这些别名，每个都省掉了不少打字量：

Terminal window展开收起

1
# Git shortcuts
2
function gs    { git status }
3
function gp    { git push }
4
function gl    { git log --oneline --graph --all -n 20 }
5
function gc    { git commit -m "$args" }
6
function gco   { git checkout "$args" }
7
function gcb   { git checkout -b "$args" }
8
function gd    { git diff }
9
function gst   { git stash }
10
function gstp  { git stash pop }
11

12
# Navigation
13
function ..    { Set-Location .. }
14
function ...   { Set-Location ..\.. }
15
function dev   { Set-Location $env:DEV_DIR }

展开收起

这些 alias 不是我一口气写出来的，而是每次发现某个命令敲了超过三次，就顺手加一条。三周后，你会发现 80% 的 Git 操作只需要两三个字母。

终端效率技巧#

Ctrl+R — 反向搜索历史命令，比 ↑ 翻历史快得多
PSReadLine 的预测提示 — PowerShell 7 内置，灰色显示你可能会输入的命令，按 → 自动补全
多 Tab + 分屏 — 一个 Tab 跑 dev server，一个跑 Git 操作，一个跑 ad-hoc 命令

四、CI/CD：让机器替你跑脏活#

手动部署是焦虑的来源。配置 CI/CD 之后，每次合并到 main 自动运行测试、构建、部署，整个过程无需人工干预。

GitHub Actions 基础配置#

一份典型的 Node.js 项目 CI 配置：

.github/workflows/ci.yml展开收起

1
name: CI
2
on:
3
  push:
4
    branches: [main, develop]
5
  pull_request:
6
    branches: [main]
7

8
jobs:
9
  test:
10
    runs-on: ubuntu-latest
11
    steps:
12
      - uses: actions/checkout@v4
13
      - uses: actions/setup-node@v4
14
        with:
15
          node-version: 20
16
          cache: "npm"
17
      - run: npm ci
18
      - run: npm run lint
19
      - run: npm run test -- --coverage
20
      - uses: codecov/codecov-action@v3
21

22
  deploy:
23
    needs: test
24
    if: github.ref == 'refs/heads/main'
25
    runs-on: ubuntu-latest
26
    steps:
27
      - uses: actions/checkout@v4
28
      - run: npm ci && npm run build
29
      - uses: peaceiris/actions-gh-pages@v3
30
        with:
31
          github_token: ${{ secrets.GITHUB_TOKEN }}
32
          publish_dir: ./dist

展开收起

这里的三个关键设计：

缓存依赖：cache: "npm" 让后续运行节省掉 npm install 的时间
分步执行：lint → test → build → deploy，任何一步失败后续自动跳过
环境区分：push 到 develop 只跑 lint + test，只有 main 才触发部署

五、测试战略：分层而不重叠#

很多人对测试的误解是”写了测试就完事”。实际上测试需要分层策略，否则要么测试太脆弱，要么覆盖率形同虚设。

测试金字塔#

我遵循经典的测试金字塔，但做了微调：

单元测试（占比 60%）：覆盖工具函数、hooks、API 服务层的纯逻辑。使用 Vitest 或 Jest，追求执行速度——整个套件 5 秒内跑完。
集成测试（占比 25%）：覆盖 API 端点、数据库交互。用 Supertest（Node.js）或 Spring Boot Test（Java），启动一次测试容器跑完所有集成用例。
E2E 测试（占比 15%）：覆盖核心用户流程（登录、注册、下单）。用 Playwright，只写 5-8 个最关键场景，不追求 100% 覆盖。

实际经验#

几条经过验证的原则：

测试跟代码一起提交。不是做完功能再补测试，而是写功能的同时写测试。我在分支合并前会检查 CI 上的测试覆盖率变化，不允许覆盖率下降超过 2%。
用 Arrange-Act-Assert 结构。每个测试用例分成三段，保持可读性：

1
// Arrange
2
const user = createTestUser({ role: "admin" });
3
const repo = new UserRepository(db);
4

5
// Act
6
const result = await repo.findByEmail(user.email);
7

8
// Assert
9
expect(result).not.toBeNull();
10
expect(result.role).toBe("admin");

不用 Mock 你没有的代码。过度 mock 会让测试与实现耦合，重构时测试先坏。能传真实实例就传真实实例，只在必要时 mock 外部服务。

六、工作流自动化：串联起来#

上述工具链单独使用已经能提升效率，但真正的价值在于”串联”：

在 VS Code 中编码，ESLint + Prettier 在保存时自动格式化
git commit 时 husky + commitlint 校验提交信息格式
pre-push hook 运行单元测试 + lint，未通过则拒绝推送
push 到远程后，GitHub Actions 自动跑完整 CI 流水线
CI 通过后，合并 PR 到 main，自动触发部署
部署成功后，发送通知到飞书/钉钉群

这个链条把人工干预降到最低。我只需要专注于写代码和 Review PR，剩下的——格式化、测试、构建、部署——全部由工具链自动完成。

效率的本质#

高效不是做更多的事，而是让机器做机器擅长的事，让人的精力集中在真正需要判断力的地方。

回顾我搭建这套工作流的过程，最大的收获其实不是节省了多少时间，而是心态上的转变——当你信任自己的工作流时，你不会害怕重构，不会害怕改错代码，不会害怕上线。因为每一步都有工具在帮你兜底。

从明天开始，选一个你觉得最痛的点——可能是提交信息没有规范，也可能是 CI 每次跑 20 分钟——先动手优化。工作流不是一次搭建完成的，它是逐步迭代出来的。

2025 年技术大会参会见闻

Tue, 10 Mar 2026 00:00:00 GMT

2025 年是我密集参加技术会议的一年。从年初的全球 AI 开发者大会到年末的开源峰会，走过了四个城市、六场会议。这篇文章从一个普通开发者的视角，记录这一年技术生态的变迁与我的观察。

为什么要去技术大会？#

在短视频和直播盛行的时代，总有人问我：会议的内容不都可以在线看吗？何必花时间花钱跑去现场？

技术大会真正的价值不在演讲本身——尽管好的演讲确实能带来启发——而在那些计划之外的瞬间：茶歇时和邻座聊起的架构设计、午餐时偶然听到的团队招聘内幕、Workshop 里和讲师面对面调试代码的经历。这些无法被录播替代的偶遇，才是会议的精华。

我给自己定的原则是：每年至少参加两场线下技术会议，一场偏 AI/前沿方向，一场偏工程实践。今年的节奏正好验证了这个组合的价值。

AI 辅助开发：从玩具到工具#

如果说 2024 年的 AI 编程还停留在”写个笑话”或者”生成一个 to-do list demo”的水平，2025 年则是质变的一年。

在四月的”AI + 工程实践”大会上，GitHub 的工程师演示了 Copilot 的全新 Agent 模式。让我印象最深的一个场景是：他直接输入”给我这个项目加一个用户认证系统，支持 GitHub OAuth 登录，用 Postgres 做 session 存储”，Copilot 依次创建了路由文件、数据库迁移脚本、中间件和前端登录按钮——一个在真实项目中需要大半天的工作，Agent 版本在一分钟内给出了可用的骨架。

关键变化：AI 不再只是补全代码片段，而是开始理解整个项目的上下文，并独立完成多步骤任务。这意味着开发者角色的转变——从编写每一行代码，变成”设计师 + 审核者”。

相比之下，Cline、Continue 等开源方案的进展同样迅速。Cursor IDE 在国内开发者圈中的使用率涨到了一个令我惊讶的比例。在会议的现场投票中，超过 40% 的开发者表示日常开发已离不开 AI 辅助。

WebAssembly：浏览器之外的新战场#

WebAssembly（Wasm）今年也不再只是浏览器里的”奇技淫巧”。几场关于 Wasm 的演讲都聚焦在服务端的实际落地。

在秋季的 Rust China Conf 上，来自字节跳动的团队分享了他们用 Wasm 做边缘计算网关的经验。核心思路是：用 Rust 编写高性能的数据处理逻辑，编译成 Wasm 模块，然后部署到 CDN 边缘节点。这样既得到了接近原生的性能，又解决了多租户环境下的安全隔离问题。

另一个让我兴奋的方向是 WASI（WebAssembly System Interface）的进展。有了 WASI 的支持，Wasm 模块可以直接访问文件系统、网络和时钟——这意味着越来越多后端服务可以用 Wasm 插件来扩展。比如一个 Web 服务器想要支持自定义路由逻辑，不再需要嵌入一个脚本解释器，而是直接加载一个 Wasm 模块即可。

会后我和几位演讲者深入交流了一下，大家的一致判断是：Wasm 在边缘计算和插件架构领域已经跨过了早期的”炫技”阶段，进入了真正的生产可用期。

AI Agent 与工具使用架构#

如果用一个关键词定义 2025 年的技术趋势，我会选”Agent”。

几乎所有我参加的大会都设立了 Agent 专题。从 OpenAI 的 GPTs 到 Anthropic 的 Claude Computer Use，科技巨头和大模型团队不约而同地将目标从”更好的聊天机器人”转向了”能动手干活的智能体”。

在 AWS re 的远程参与环节（没能去成拉斯维加斯，有点遗憾），他们重点展示了 Amazon Bedrock 的 Agent 框架——说白了就是一个”思考 + 行动”的循环：Agent 拆解用户指令、调用各种 API/工具、处理返回结果、决定下一步行动。听起来简单，但真正做到可靠和鲁棒却极难。

让我印象最深的是一个关于 MCP（Model Context Protocol）的 Workshop。MCP 试图为 AI Agent 和外部工具之间建立一套标准协议——类似于 HTTP 之于 Web。有了标准协议，Agent 可以动态发现当前环境中有哪些工具可用、每个工具的输入输出格式是什么。这场 Workshop 的手写环节让我第一次真正理解了一个 Agent 系统的工作链路：用户请求 → 意图识别 → 工具选择 → 参数填充 → 调用执行 → 结果反馈。

有一位来自蚂蚁集团的嘉宾做了 Keynote，展示了他们内部使用的 Agent 编排平台，支撑着数百个业务场景的自动化流程。他说了一句让我反复回味的话：“Agent 不是替代开发者，而是把我们从机械重复中解放出来，让我们专注于真正需要创造力的部分。“

开源的黄金时代#

今年开源界的活力让很多人惊讶。如果说前几年”大模型闭源、框架商业化”的声音让人担忧开源生态，2025 年的现实证明：开源比以往任何时候都强大。

在年底的开源年会上，几个数字令人振奋：

国内活跃的开发者开源贡献者数量同比增长 67%
超过 30 家企业正式建立了开源办公室（OSPO）
Llama、Mistral、Qwen 等大模型的开源生态已经可以和闭源产品掰手腕

我最喜欢的环节是”闪电演讲（Lightning Talk）“。每位演讲者只有 5 分钟，节奏极快。有人分享了自己为某个冷门库提交第一个 PR 的忐忑经历，也有人展示了用 Rust 重写 Webpack 替代品的实际数据。这些短小但真实的分享，远比那些充满高大上名词的 Keynote 更能打动人。

今年的社区圆桌也很有意思。来自不同公司的五位嘉宾讨论了”开源如何抗住商业化压力”。共识是：开源的护城河不是代码本身，而是围绕代码形成的社区。只要社区健壮、有参与感、有正向反馈，商业化的压力反而会倒逼社区进化。

参会 Tips：如何让每一次会议都物有所值#

参加了这么多场会议，踩过不少坑，总结几条实在的建议：

提前做功课：拿到议程后，圈出必听的场次，同时留出 30% 的时间给”随机漫步”——按兴趣去看不熟悉的领域，往往有意外收获。
带名片？不如带二维码：现在谁还带实体名片？把自己的联系方式做成一个二维码放在手机锁屏上，加人更方便。推荐用 vCard 格式。
不要追着大牛合影：大牛也是人，演讲完去厕所的路上、茶歇排队时反而更容易聊起来。真诚地提一两个具体问题，远好过”老师我仰慕您很久了”。
及时记录：每次听完一个演讲，花 2 分钟在手机上记三件事——这个演讲的核心观点是什么？有哪些数据/例子特别有说服力？我回去可以尝试什么？第二天再整理成笔记。
少拿周边：那些帆布袋、贴纸、充电线终将被遗忘。会场最重要的资源是人和信息，而不是免费赠品。

总结与展望#

回看 2025 年的参会笔记，变化最大的是两件事：一是 AI 从”能聊天”变成了”能干活”，二是整个行业从焦虑转向务实。2023 年大家还在讨论”AI 会不会取代程序员”，2025 年大家讨论的是”怎样让 AI 帮我把 CRUD 写得快一点”。

2026 年，我期待看到 Agent 架构从概念走向生产级的工程方案，期待 WebAssembly 在边缘计算领域更加成熟，更期待开源社区继续用协作的力量推动技术前进。

最后，分享一个习惯：每次参会回来，我会在个人仓库里建一个 conference-notes/ 文件夹，把整理的笔记和学到的东西沉淀下来。一年下来回看，会发现成长并不是一蹴而就的，而是这些会议、交流、反思的碎片拼凑起来的。

明年，继续出发。

相关链接：

我的 22408 备考之路：目标是南邮，虽然没上岸

Fri, 20 Feb 2026 00:00:00 GMT

出成绩那天，我盯着屏幕看了很久。总分离南邮的复试线还差一截。说不上意外，因为考完数学的那一刻我心里就有数了。但真正看到结果时，那种失落感还是比预想的要重。

这篇博客不是成功经验分享，而是一次诚实的复盘。记录我这一年的备考历程，以及没上岸之后的一些思考。

为什么选 22408 + 南邮#

选择 22408（政治、英语二、数学二、408 计算机专业基础综合）的理由很简单：408 是计算机考研最硬的专业课，考察数据结构、组成原理、操作系统、计算机网络四门核心课程。虽然难，但我觉得作为一个科班生，这是打好基础的最好方式。

南邮虽然不是 985/211，但在计算机和通信领域的口碑很好，地理位置在南京，互联网公司校招资源丰富。加上往年分数线相对友好，我觉得自己努力一把是有机会的。

现在回头看，我对 408 的难度低估了，对自己的执行力高估了。

备考时间线#

3 月 - 6 月：基础阶段#

数学二跟着张宇的基础 30 讲过了一遍，课后题基本都能做下来。408 买了王道的四本书，配合视频课过数据结构与组成原理。这个阶段节奏还可以，每天图书馆坐得住 6-8 小时。

英语二背单词为主，用的墨墨背单词，每天 200 个，雷打不动。政治完全没动。

7 月 - 9 月：强化阶段#

暑假留校，以为能有大把时间学习，结果效率反而不如之前。数学进入 1000 题强化篇，难题开始卡壳，有时候一道题想半小时做不出来，心态开始波动。

408 过完四本书的第一轮，但合上书再做题，还是很多知识点记不牢。特别是计算机网络，各种协议记了又忘，忘了又记。

英语开始做阅读真题，一篇阅读错 2-3 个是常态。心态上已经有些疲惫了。

10 月 - 12 月：冲刺阶段#

这是最难熬的三个月。数学真题做了近十年的，分数起起伏伏，有时候 120+，有时候 90 出头。408 开始刷真题，选择题还好，但大题一做就暴露问题，尤其是组成原理的计算题和数据结构的算法设计题。

政治 11 月开始背肖八肖四，英语作文背了模板但也写不利索。每天 10 小时坐在自习室里，但学习效率明显不如上半年。到 12 月的时候，我已经隐隐感觉这次可能不行了。

成绩与分析#

最后的成绩确实不理想。最拉分的是数学，比平时模拟低了近 20 分。408 也不算好，只有 90 多分。政治英语算是正常发挥，但也没拉到分。

复盘下来，几个问题比较致命：

数学练得太少。 题量不够，考场上见到新题型就慌了。数学二现在越来越灵活，光靠刷老题不够用。
408 停留在”看懂”而非”会做”。 王道书看了三四遍，但真题做得不够，特别是大题动手太少。
后期心态崩了。 9 月之后明显焦虑，睡眠质量下降，复习效率打折扣。这是一个恶性循环。
计划不切实际。 制定了一堆完不成的计划，每次完不成就更焦虑。“计划—完不成—焦虑—更完不成”，这个循环到后面基本把我拖垮了。

没上岸之后#

出成绩后的那两周确实很难受。看着朋友圈里上岸的同学晒录取通知，心里五味杂陈。也开始怀疑自己是不是不适合走这条路。

但冷静下来之后，我想明白了几件事：

考研失败 ≠ 我这个人不行。 只是一次考试没考好，不代表能力被否定。备考过程中学到的 408 四门课的知识，做过的几百道数学题，背过的几千个单词，这些不会因为没上岸就消失。
路不止一条。 考研不是唯一出路。把备考的那股劲头用在提升工程能力、做项目、刷 LeetCode 上，明年春招秋招同样有机会。
这次失败也是一份礼物。 它让我更清楚自己的弱点在哪：抗压能力、计划执行力、数学基础。这些都是可以针对性改善的，而不是什么”天赋问题”。

给后来人的建议#

虽然我没上岸，但这半年的试错让我有一些话想说给同样准备 22408 的人：

数学一定要多做题。 看课看懂了不等于会做。660、880、108，该刷的题一本都不能少。考场上见真章的时候，只有做过的题量和总结的方法能帮你。
408 真题要早刷。 不要等到”复习完”再开始做真题，真题是最好的复习资料。早点做，反复做，搞清楚每道题为什么对、为什么错。
照顾好身体和心理。 每周至少运动一次。学不进去的时候不要硬撑，出去走走可能比在图书馆发呆更有效。
给自己留条后路。 不要说”考不上就完了”，这种想法只会增加不必要的压力。备考同时也可以刷刷 LeetCode，做做项目，就算考研没成，技术和项目经验不会白费。

现在#

写这篇博客的时候，我已经在认真学前端全栈了。做了这个博客网站，开始写技术博客，重新刷 LeetCode。考研备考时啃 408 打下的基础，让我现在学底层知识时理解得更快。那一年没有白费。

没上岸不是终点，只是换了一条路走。与所有没上岸的朋友共勉。

用 LaTeX 写技术文档：从入门到实践

Thu, 05 Feb 2026 00:00:00 GMT

在技术写作领域，选择正确的工具往往比写作本身更能影响最终成果的质量。LaTeX 作为一个存在了四十多年的排版系统，至今仍然是学术界和工程界的首选。这篇文章将带你从零搭建 LaTeX 写作环境，并分享一些实践中积累的技巧。

为什么选择 LaTeX？#

很多开发者初次接触文档写作时，会自然而然地选择 Word 或 Markdown。这两种工具各有优势，但在面对大型技术文档时，它们的局限性就显现出来了。

Word 的优势在于所见即所得（WYSIWYG），但当你需要维护一个包含数十个章节、上百张图表、数千条引用的技术手册时，手动调整编号、格式和交叉引用会变成一场噩梦。Markdown 虽然轻量且版本控制友好，但在复杂排版需求面前力不从心——表格不够灵活，数学公式支持有限，图片排版也难以精细控制。

LaTeX 的核心理念与它们截然不同：内容与样式分离。你只需要专注于写作内容，排版交给 LaTeX 引擎处理。这意味着：

自动化编号：章节、公式、图表、引用全部自动编号，无需人工维护
一致的排版：整篇文档的字体、间距、页眉页脚风格统一
纯文本源文件：天然适合 Git 版本控制，协作 diff 一目了然
图灵完备：你可以在文档中定义宏、写循环、条件判断，生成复杂内容

一句话总结：如果你写过上百页的技术文档，就会理解为什么 LaTeX 爱好者会说”Word 是打字机，LaTeX 是排版系统”。

环境搭建#

本地方案：TeX Live#

TeX Live 是跨平台的 LaTeX 发行版，包含所有核心宏包和工具链。安装命令因系统而异：

Terminal window

1
# macOS (Homebrew)
2
brew install --cask mactex
3

4
# Ubuntu / Debian
5
sudo apt install texlive-full
6

7
# Windows
8
# 从 https://tug.org/texlive 下载 install-tl-windows.exe

完整安装约 5-8 GB，如果你空间有限，可以选择 texlive-base 或 texlive-latex-extra 等精简方案。安装完成后，用 pdflatex 或 xelatex 编译即可。

在线方案：Overleaf#

对于不想折腾环境或需要协作的场景，Overleaf 是最佳选择。它提供：

浏览器内编辑 + 实时预览
多人协作（类似 Google Docs 的体验）
丰富的模板库（论文、简历、书籍、演示文稿）
Git 集成，方便本地备份

我个人推荐的方式是：本地用 VS Code + LaTeX Workshop 插件编写，Overleaf 用于协作评审。VS Code 的智能补全、代码片段和 Git 集成让写作体验大幅提升。

文档结构入门#

一个标准的 LaTeX 文档分为导言区（Preamble）和正文区。以下是中文技术文档的典型框架：

1
% 导言区
2
\documentclass[UTF8]{ctexart}
3

4
% 宏包引用
5
\usepackage{amsmath, amssymb}   % 数学公式
6
\usepackage{graphicx}           % 图片
7
\usepackage{booktabs}           % 三线表
8
\usepackage{listings}           % 代码展示
9

10
% 标题信息
11
\title{基于深度学习的图像分割技术综述}
12
\author{王忠亮}
13
\date{\today}
14

15
\begin{document}
16

17
\maketitle
18
\tableofcontents
19

20
% 正文区
21
\section{引言}
22
...
23

24
\section{相关工作}
25
...
26

27
\section{实验分析}
28
...
29

30
\bibliographystyle{plain}
31
\bibliography{references}
32

33
\end{document}

展开收起

数学公式#

这是 LaTeX 最强大的领域之一。行内公式用 $...$ ，独立公式用 \[ ... \]：

1
% 行内公式
2
欧拉公式 $e^{i\pi} + 1 = 0$ 被誉为最美公式。
3

4
% 独立公式
5
\[
6
\int_{-\infty}^{\infty} e^{-x^2}\,dx = \sqrt{\pi}
7
\]
8

9
% 多行公式（align 环境）
10
\begin{align}
11
E &= mc^2 \\
12
\nabla \times \mathbf{B} &= \mu_0 \mathbf{J} + \mu_0\varepsilon_0 \frac{\partial \mathbf{E}}{\partial t}
13
\end{align}

amsmath 宏包提供了几乎所有需要的数学环境：align 用于多行对齐，cases 用于分段函数，matrix 用于矩阵。对开发者来说，掌握 10 个左右的数学环境就能覆盖 90% 的公式需求。

表格与图片#

三线表#

学术表格推荐使用 booktabs 宏包的三线表风格，简洁专业：

1
\begin{table}[htbp]
2
  \centering
3
  \caption{不同模型的性能对比}
4
  \begin{tabular}{lccc}
5
    \toprule
6
    模型 & 准确率 & 参数量 & 推理时间 \\
7
    \midrule
8
    ResNet-50 & 76.1% & 25.6M & 12ms \\
9
    ResNet-101 & 77.3% & 44.5M & 19ms \\
10
    ViT-B/16 & 78.0% & 86.6M & 25ms \\
11
    \bottomrule
12
  \end{tabular}
13
\end{table}

插图#

1
\begin{figure}[htbp]
2
  \centering
3
  \includegraphics[width=0.8\textwidth]{figures/architecture.pdf}
4
  \caption{模型整体架构图}
5
  \label{fig:architecture}
6
\end{figure}

使用 \label 和 \ref 实现交叉引用，LaTeX 会自动维护编号，你只需要写 如图~\ref{fig:architecture} 所示 即可。

参考文献管理#

BibTeX 是 LaTeX 生态中最经典的参考文献管理方案。你需要一个 .bib 文件存放所有引用条目：

1
@article{goodfellow2014gan,
2
  title     = {Generative Adversarial Nets},
3
  author    = {Goodfellow, Ian and Pouget-Abadie, Jean and Mirza, Mehdi and others},
4
  journal   = {Advances in Neural Information Processing Systems},
5
  year      = {2014},
6
  volume    = {27}
7
}
8

9
@book{knuth1984tex,
10
  title     = {The TeXbook},
11
  author    = {Knuth, Donald Ervin},
12
  year      = {1984},
13
  publisher = {Addison-Wesley}
14
}
15

16
@inproceedings{vaswani2017attention,
17
  title     = {Attention Is All You Need},
18
  author    = {Vaswani, Ashish and Shazeer, Noam and Parmar, Niki and others},
19
  booktitle = {Advances in Neural Information Processing Systems},
20
  year      = {2017}
21
}

展开收起

在文档中通过 \cite{goodfellow2014gan} 引用，LaTeX 会自动生成参考文献列表。配合 natbib 或 biblatex 宏包，还可以定制引用格式（数字标号、作者-年份等）。

技巧提示：在 Overleaf 中可以直接搜索 DOI 自动生成 BibTeX 条目，也可以使用 JabRef（桌面）或 Zotero + Better BibTeX 插件管理你的文献库。

中文支持与 ctex 宏包#

对于中文技术文档，ctex 宏包是标配。它提供了：

中文排版支持：自动处理中英文混排、标点压缩、行距调整
中文字体配置：内置宋体（\songti）、黑体（\heiti）、楷体（\kaishu）等
文档类适配：ctexart（文章）、ctexrep（报告）、ctexbook（书籍）、ctexbeamer（演示）
中文目录与标题：自动将 “Contents” 变为 “目录”，“Abstract” 变为 “摘要”

使用方式很简单，将 \documentclass{article} 替换为 \documentclass[UTF8]{ctexart} 即可。编译时推荐使用 xelatex 而不是 pdflatex，以更好地支持 Unicode 和中文字体。

开发者专属宏包#

如果你的文档需要大量展示代码，以下两个宏包必不可少：

listings — 轻量代码展示#

1
\usepackage{listings}
2
\lstset{
3
  language=Python,
4
  basicstyle=\ttfamily\small,
5
  keywordstyle=\color{blue},
6
  commentstyle=\color{gray},
7
  numbers=left,
8
  frame=single,
9
  breaklines=true
10
}
11

12
\begin{lstlisting}
13
def fibonacci(n):
14
    if n <= 1:
15
        return n
16
    return fibonacci(n - 1) + fibonacci(n - 2)
17
\end{lstlisting}

展开收起

minted — 高级语法高亮#

minted 基于 Pygments 引擎，提供更强大的语法高亮支持。使用前需安装 Pygments：pip install Pygments，编译时加 --shell-escape 参数：

1
\usepackage{minted}
2
\begin{minted}{python}
3
import numpy as np
4
x = np.linspace(0, 10, 100)
5
y = np.sin(x)
6
print(f"Max value: {y.max():.3f}")
7
\end{minted}

minted 支持数百种编程语言，高亮效果比 listings 精致得多。不过由于依赖外部工具，配置稍复杂。简单的代码片段用 listings，复杂的项目代码推荐 minted。

其他对开发者有用的宏包还包括：

algorithm2e：伪代码和算法排版
glossaries：术语表与缩写词管理
hyperref：PDF 超链接、书签和元数据
cleveref：智能交叉引用（自动加上”图""表""式”等前缀）
tikz：直接在 LaTeX 中绘制矢量图形

工作流建议#

最后分享几条实践中的经验：

模块化组织：将章节拆分成独立 .tex 文件，用 \input 或 \include 引入，方便多人协作和大文档复用
版本控制：不要提交编译产物（.aux、.log、.pdf），在 .gitignore 中排除它们
持续编译：使用 latexmk 自动跟踪依赖并增量编译，省去手工多次编译的烦恼
模板复用：维护一个自己的 LaTeX 模板仓库，从论文到技术手册统一风格

总结#

LaTeX 的学习曲线确实比 Word 陡峭，但它的回报同样丰厚。一旦适应了”内容与样式分离”的思维模式，你会发现写技术文档变成了一件极其愉悦的事——你关心逻辑，LaTeX 关心美观。对于需要频繁产出高质量技术文档的开发者来说，这一投入的性价比很高。

如果本文让你对 LaTeX 产生了兴趣，推荐从 Overleaf 的官方文档开始，或者直接打开一个模板写一篇小文档试试。写得越多，掌握越深。

参考资源：

王忠亮的博客

LLM 入门学习路线：从零开始的实践记录

为什么学 LLM？#

学习资源清单#

精选仓库#

环境搭建#

练习记录#

1. hello_langchain.py — 第一个 LangChain 脚本#

2. test_gen.py — 测试用例自动生成器#

3. LangChain vs 裸 API — Agent 循环对比#

4. rag_demo.py — 最小 RAG 演示#

我的学习策略#

下一步计划#

总结#

逻辑学笔记：思维检票员的自我修养

为什么会有逻辑#

逻辑的本质：从已知推出大概率正确的结论#

「既定」陷阱：从答案反推原因#

黄金屋理论：信息量与推理能力#

案例分析：马哲「量变引起质变」的逻辑拆解#

「一定条件」是个空洞的占位符#

性质变化 vs 身份变化#

终极追问：量变本身不保证质变#

宏大叙事的悖论#

科学 vs 信仰：分界线在哪#

总结#

如何高效阅读技术论文：一个本科生的实践方法

为什么要系统化读论文？#

三遍阅读法#

第一遍：粗读（5-10 分钟）#

第二遍：精读（30-60 分钟）#

第三遍：深读（1-2 小时）#

文献管理工具推荐#

总结#

Next.js App Router 深入浅出

为什么 App Router 是一个大版本更新？#

App Router 的核心概念#

文件约定#

布局嵌套#

服务端组件 vs 客户端组件#

数据获取：服务端是起点#

路由组与并行路由#

从 Pages Router 迁移建议#

总结#

搭建高效的开发工作流

一、Git 工作流：分支策略与提交规范#

提交信息规范#

二、编辑器配置：VS Code 效率翻倍#

必装扩展#

settings.json 核心片段#

快捷键肌肉记忆#

三、终端配置：告别低效敲命令#

Oh My Posh 主题#

实用别名#

终端效率技巧#

四、CI/CD：让机器替你跑脏活#

GitHub Actions 基础配置#

更多实用 CI 技巧#

五、测试战略：分层而不重叠#

测试金字塔#

实际经验#

六、工作流自动化：串联起来#

效率的本质#

2025 年技术大会参会见闻

为什么要去技术大会？#

AI 辅助开发：从玩具到工具#

WebAssembly：浏览器之外的新战场#

AI Agent 与工具使用架构#

开源的黄金时代#

参会 Tips：如何让每一次会议都物有所值#

总结与展望#

我的 22408 备考之路：目标是南邮，虽然没上岸

为什么选 22408 + 南邮#

备考时间线#

3 月 - 6 月：基础阶段#

7 月 - 9 月：强化阶段#

10 月 - 12 月：冲刺阶段#

成绩与分析#

没上岸之后#

给后来人的建议#