youkiの博客

现代前端基础：Vanilla 与数据驱动 UI

Mon, 24 Aug 2026 16:00:00 GMT

这篇笔记整理数据驱动 UI 的基础概念：vanilla、数据驱动界面、数据与界面分离、React 状态。

什么是 Vanilla

Vanilla 本义”香草”，软件行业借指”原味的、没有额外包装的版本”。Vanilla 前端即：不依赖 React、Vue 这类框架，只用浏览器原生支持的 HTML、CSS、JavaScript 构建页面。

边界不必较真——“用了第三方库还算不算 vanilla”没有定论，理解为”没有使用前端框架的写法”即可。

数据驱动界面

核心定义：

界面长什么样，不写死在组件里，而是照着”喂进去的值”来显示。值变了，显示就变。

两个例子（示意）：

// PageHeading 只负责排版，标题文字由外部传入
<PageHeading title="关于我" />     // 个人主页
<PageHeading title="文字实验室" /> // 文字实验室页

App 的页面切换同理：用户点导航栏，“当前页面”这个值变成 "home" 或 "textlab"，App 据此决定渲染 HomePage 还是 TextLabPage。区别只在值的来路——前者由外部传入，后者由组件自己持有。

数据与界面分离

问题：文案直接写在组件 JSX 里，改一句”关于我”就得打开组件代码、在一堆标签中间找。而项目建成后数据的变化频率远高于界面结构。

做法：把要显示的内容集中到独立的数据文件：

// src/data/site.js
export const home = {
	heroTitle: "关于我",
	heroSubtitle: "项目，创意，灵感，心得，我的作品",
	featuredWork: {
		kicker: "作品",
		title: "文字实验室",
		copy: "拼音和情绪，挖掘中文里的细节",
		linkLabel: "打开作品",
	},
	identity: {
		motto: "已识乾坤大，尤怜草木青",
		learning: "零到全栈",
	},
};

export const textLab = {
	heroTitle: "文字实验室",
	heroSubtitle: "拼音和情绪，挖掘中文里的细节",
};

这基本是一张纯内容清单——网站上要显示的字都在这儿。它和 JSON 很像，区别在于对象最后一个成员的结尾允许带逗号。

组件不再写死任何文案，只负责到清单里取值显示（示意）：

// HomePage.jsx
import { home } from "../data/site";

<h1>{home.heroTitle}</h1>;

职责划分：

	只管什么
组件	”怎么显示”——排版、样式、结构
`site.js`	”显示什么内容”

收益：

改文案只动 site.js，组件一行不改；
多语言几乎免费：再备一份英文清单，组件按当前语言读对应那张表即可，排版、结构、样式全部复用；
将来引入后端 API，只需把数据来源换成接口返回，组件依然不需要改动。

验证方式：改 site.js 里任意字段并保存，页面当场更新，组件文件一个字没动。

状态驱动 UI

前面例子里的值有两个局限：从外面喂进来（哪怕集中进了 site.js，也是父组件读了再传下去）；本身定死，不主动改就不会变。

有些数据需要在用户操作过程中自己变。这种会变、且一变显示就跟的值，在 React 里称为组件的状态（state）：

由组件自己持有、自己管理，不从外部传入（区别于 props）；
有初始默认值；
界面显示什么，完全照着这个值；
允许被修改，且一改，界面当场跟着变。

典型例子：输入框下方实时显示”已输入 N 字”。输入框内容是一个 state——打字就是在改这个值，字数照着它计算，值一改数字立刻刷新。

实现原理可以先不深究：React 内部负责盯着这个值，值一变就自动刷新界面。需要认出的只有现象：state 一变，界面自动跟变。

前文的导航切换就是一例：App 里”现在在哪一页”就是一个 state。

小结

vanilla = 不依赖框架、只用浏览器原生能力的写法；
数据驱动界面：界面照着”值”来显示，值变则显示变；
数据与界面分离：内容集中进独立数据文件，组件管”怎么显示”、数据表管”显示什么”，多语言这类需求因此近乎免费；
状态驱动 UI：state 是组件自己持有的可变数据，一变界面就跟，是 React 响应式更新的核心机制。

参考

零基础到全栈 · 数据驱动课程原文

现代前端基础：模块化、npm 与 Vite

Sun, 23 Aug 2026 16:00:00 GMT

为什么需要模块化

传统 script 引入

<script src="js/nav.js"></script> 引入的是本地文件的相对路径，含义是把当前目录下 js 目录中的 nav.js 引入页面。

<script> 标签也可以引用发布在互联网上的 .js 文件：

<script src="https://cdn.jsdelivr.net/npm/animejs@4/lib/anime.iife.min.js"></script>

上面这个地址指向 anime.js——一个专门提供动画方案的现成脚本。这类由他人编写、发布到互联网上供复用的脚本，统称为第三方库。

全局污染

cards.js 依赖 anime.animate、anime.stagger 这些名字才能运行。这是传统 <script> 引入方式的固有约定：库向页面全局提供自己的名字，使用者从全局取用。

随着项目变大，引入的库不再只有一个——图表库、日期处理库、ajax 工具库……每个库都靠”往全局挂名字”的方式提供功能。而 JavaScript 的全局空间中，一个名字只能存一个值：一旦两个库挂载了同名成员，后挂载的会静默覆盖先挂载的，没有任何警告。

这种现象称为全局污染（global pollution）。小项目尚能靠记忆规避；项目一旦长大，撞名只是时间问题，而每一次撞名都是一个难以排查的 bug。

出路：工程化

<script> 手动排序与全局污染表面上是两个问题，根源相同：

“全部堆在一起 + 全局名称（变量）+ 手动排序”的传统组织方式，本来就不是为严肃项目设计的。

这不是工程师水平的问题，而是工具本身达到了能力上限。全球前端开发者都撞过这堵墙，并由此发展出一整套跨越它的方法，统称工程化。工程化的第一招，就是模块化。

模块化与 ES 模块

export 与 import

模块化与传统方式只在一个关键点上不同：共享的方式。

	传统方式	模块化
可见性	代码默认”全世界都看得见”（都堆在 `window` 全局空间里）	代码默认”只有自己看得见”
提供功能	库向全局挂名，共享靠”公共”	必须显式标注 `export`，共享靠”明文声明”
使用功能	直接从全局取用	必须显式写 `import`，不写就用不到

export 与 import 是模块化的两个核心关键字：

export：给文件内的某个成员打上”对外可用”的标记；未标记的，外部拿不到。
import：在文件顶部明文声明”要使用某个文件里的某个成员”；不声明的，用不到。

名词：ES 与 ECMAScript

ES 是 ECMAScript 的缩写，即 JavaScript 这门语言的官方标准规范。所有浏览器、所有 JS 引擎都必须按这份规范实现 JavaScript。日常所说的”JavaScript”，本质上就是”按 ECMAScript 规范实现的那套东西”。

由此派生两个常见说法：

ES 模块：JavaScript 标准中定义的那套模块系统。它不是另一种语言，也不是新东西，而是 JavaScript 自带的官方模块方案。
ES6：ECMAScript 的第 6 版（2015 年发布）。import / export 正式定义于这一版。

注意：ES 模块文件必须通过服务器提供才能加载，浏览器不允许直接从 file:// 读取。

构建工具

三方诉求的矛盾

工程治理、开发体验、用户体验，三方在互相拉扯：

工程治理：希望项目规范、安全、好维护、好扩展（模块化、拆文件都是为此服务）；
开发者：希望写得简单、顺手、舒服；
浏览器与最终用户：希望加载更快、资源更少、性能更高。

三者常常彼此冲突：为了规范牺牲开发便利，为了开发便利又影响运行效率，很难同时满足。构建工具就是化解这一矛盾的方案——让一类工具夹在中间做”翻译”：工程的规矩照守，开发者按自己舒服的方式编写，最后由工具把源码转换成浏览器想要的样子。这个转换过程叫前端构建，这类工具叫构建工具（build tool）。

构建工具的职责

本地开发服务器 + 热更新：改完一保存，浏览器自动更新，无需手动刷新；
合并碎文件：多个 CSS 合成 1 个、多个 JS 模块合成 1 个，请求数从十几个降到几个；
文件名加 hash 指纹：内容一变、文件名就变，浏览器立刻知道需要重新拉取，缓存随之失效。

npm：项目级包管理

npm 与 apt 的区别

npm 与 apt 都是”应用商店”，但管辖范围不同：

apt 给整台电脑装东西：装一个 nginx，全系统都能用。
npm 默认给当前项目装东西：A 项目用 anime.js 4.4、B 项目用 anime.js 3.0，两边各装各的、互不干扰。

正因为按项目管理，使用前必须先明确声明”这里有一个项目”，这个动作叫初始化。

初始化与安装

在项目根目录（与 index.html 同级）运行：

npm init -y

该命令生成 package.json 项目档案。有了 npm 与 package.json，安装 Vite 只需一行（在 index.html、package.json 同级目录运行）：

npm install -D vite

-D 即 --save-dev，表示把 Vite 装成开发依赖——只在开发阶段使用，不进入最终产物。

Vite 实操：dev / build / preview

Vite 的可执行文件位于 node_modules/.bin/vite，通过该路径直接运行。

dev：开发服务器

./node_modules/.bin/vite

随改随看，保存即热更新。

build：打包上线版本

./node_modules/.bin/vite build

运行后生成 dist 目录：

dist/
├── index.html
└── assets/
    ├── main-Beya6efK.css     ← 多个 CSS 合并成的 1 个文件
    └── main-_go62SDo.js      ← 多个 JS 模块合并成的 1 个文件

preview：上线前本地预览

./node_modules/.bin/vite preview

启动一个专门伺服 dist 的服务器。打开后按 F12 查看 Network 面板——干净利落，只有寥寥几个请求。

参考

零基础到全栈 · 模块化课程原文

SSH 为什么会连到错误的服务器？一次 FlClash 核心异常排查

Tue, 04 Aug 2026 16:00:00 GMT

最近把一个旧服务器的 CPA/CPAMP 服务完整迁移到了新的服务器。Docker Compose、Caddy、HTTPS、历史数据和插件都已经验证正常，API 也可以正常调用。

服务器迁移完成以后，我准备通过 SSH 继续维护旧服务器，却遇到了一个很奇怪的问题：SSH 有时直接提示连接被关闭，有时提示 Permission denied (publickey)。更奇怪的是，显式指定另一把私钥后，连接似乎又成功了。

后来我发现，问题并不是服务器突然忘记了公钥，也不是 CPA 或 Caddy 的配置错误，而是本地 FlClash 核心异常后，SSH 流量走到了错误的路径。

诡异的错误提示

最开始看到的是：

Connection closed by <SERVER_IP> port <SSH_PORT>
Permission denied (publickey)

这两条信息很容易把排查方向转向到服务器端：检查安全组、检查 SSH 服务、检查 authorized_keys。

但 SSH 的认证错误有一个前提：客户端必须先连接到了正确的服务器。如果连接目标本身就错了，那么服务器返回的认证错误没有分析价值。此时继续修改密钥，只是在错误的机器上重复尝试。

因此，第一步应该是确认服务器身份。

先检查别名最终使用的地址和端口：

ssh -G <ALIAS>

再使用详细模式连接：

ssh -vvv <ALIAS>

重点看三个信息：

最终连接的 IP 地址；
最终连接的端口；
服务器发送的 SSH 主机指纹。

为什么监控网站还是正常的

排查过程中，监控面板和普通网站都可以打开，所以我一度以为服务器网络没有问题。

其实这两个结论并不矛盾。浏览器访问网站通常经过域名解析、HTTPS 和浏览器代理；SSH 别名可能直接连接一个固定 IP 和自定义端口。它们经过的 DNS、规则匹配、代理模式和路由路径都可能不同。

用另一条路径确认问题在哪里

我随后从另一台可以正常连接的服务器发起跳转，使用旧服务器对应的密钥和端口连接。通过跳板机访问时，看到的是旧服务器真实的主机信息，SSH 服务本身也能正常接受密钥。

检查对象	结果	结论
服务器 SSH 服务	正常	不是 `sshd` 故障
服务器公钥认证	通过跳板机正常	不是 `authorized_keys` 丢失
DNS 解析	指向预期地址	DNS 不是主要原因
浏览器监控页面	正常	Web 路径仍可用
本地直连 SSH	指纹和预期不一致	本地连接路径异常

FlClash 核心异常的证据

我导出了 FlClash 的日志。日志中多次出现下面的前端错误：

IPC error: read error: failed to fill whole buffer
IPC Disconnected

这表示 FlClash 前端与核心之间的 IPC 通道没有读完一条完整消息就断开了。能够证明前端与核心之间发生过异常断连。

时间线也能和网络现象对应起来：

IPC 断开时，多条 IP 检查请求同时出现 TLS handshake 失败或连接未收完响应头；
核心重新连接后，IP 检查又恢复成功；
手动重启 FlClash 核心后，SSH 和 HTTPS 连接也恢复正常。

已确认的事实是：FlClash 前端记录到了 IPC 断开，SSH 的实际连接身份异常，并且重启核心后恢复。

尚未确认的是：核心为什么会进入这个状态，以及 TUN 内部具体哪一步没有正确重建。原始故障发生时没能提前保存完整的核心实时流，因此根因没有确定。

最终修复：重启核心

直接重启 FlClash 核心后，问题恢复了。这个动作会让当前核心重新建立 IPC、TUN 和运行时网络状态，清理掉本次异常留下的临时状态。

重启以后：

SSH 服务器主机指纹恢复为预期值；
使用正确的私钥可以完成认证；
HTTPS 请求不再出现握手阶段被重置；
CPA/CPAMP 服务继续正常运行；
没有因为排查而修改历史数据或服务器端密钥。

结语

这次故障最容易误导人的地方，是错误看起来非常像 SSH 密钥失效：先是连接被关闭，然后又出现公钥拒绝（当时真以为服务器被盗了）。最后才发现真正的问题是虚拟网卡导致的 ip 转发（？）错误，正常很难发现。以后遇到问题得先重启核心了。（下次再遇到再补充，目前还是不知道具体核心发生了什么）

如何使用好Codex等ai工具

Sat, 01 Aug 2026 16:00:00 GMT

在我最开始使用 Codex 等 ai 工具时，最先研究的是 Prompt。

应该怎么描述需求？要不要指定角色？要不要让模型先思考？要不要写一份很长的系统提示词？

这些问题当然都有意义，但它们很容易把注意力带到一个不太重要的地方：我们开始研究如何控制模型，却忘了先告诉模型我们在做什么。

一项真实的软件任务，通常不只是“写一个新的组件”这么简单。它可能涉及旧接口、历史数据、部署环境、测试习惯、兼容性要求，以及一些没有写进文档、但团队默认不能碰的东西。

Codex 可以很快写出一段看起来合理的代码，但它不一定知道当前项目的真实边界，也不一定知道什么结果才算完成。

所以，使用 Codex 最重要的能力我觉得应该是把任务变成一个可以被理解、执行和验收的工作。

给上下文，而不是堆 Prompt

OpenAI 当前的 Codex 指南把一个有效任务拆成了几类信息：目标、上下文、约束和完成标准。[1]

这四类信息比“请你扮演一名资深工程师”更重要。

一个简单的任务可以这样写：

目标：修复邮箱登录失败的问题。

上下文：
- 后端入口位于 backend/auth/；
- 错误发生在 POST /api/login；
- 手机号登录目前正常；
- 相关测试位于 backend/tests/auth/。

约束：
- 保持现有 API 响应格式；
- 不更换数据库；
- 不删除或跳过现有测试；
- 不修改与登录无关的页面。

完成标准：
- 正确邮箱和密码可以登录；
- 错误密码返回 401；
- 手机号登录测试仍然通过；
- 完整后端测试套件通过。

这段文字没有什么复杂技巧，但它告诉了 Codex 四件关键的事情：想改变什么，当前实现是什么，哪些东西不能动，以及如何证明任务完成。（其实现在也没必要这么复杂，能力越强的模型对于这些状态的感知越强）

如果任务涉及陌生代码库，不应该一开始就要求 Codex 修改。可以先让它只读调查：

先不要修改文件。

请检查与这个问题有关的入口、配置、依赖、测试和复现步骤，并输出：

1. 已确认的事实；
2. 你的假设；
3. 相关文件；
4. 可能原因；
5. 仍然无法从代码中确定的问题；
6. 建议的下一步。

可以从代码、配置或测试中确认的信息，不要询问我。

Codex 最容易出错的地方，是在错误的上下文里快速写出了局部最优的方案，但是却可能没有真正解决问题。

新模型不缺少规划能力

现在的 Codex 已经可以自己阅读代码、选择工具、安排多个步骤，并根据测试结果继续推进。把每一条命令和中间动作都提前写死，反而可能限制模型寻找更好路径的能力。

更适合当前 Agent 工作流的原则是：

少写操作指令，多提供工作现场；少规定路径，多定义结果边界。

真正需要人类确认的，应该集中在任务范围、兼容性要求、外部副作用和验收标准。具体拆成几个阶段、先读哪一个文件、是否调用工具，尽量留给模型判断。

先让 Codex 研究，再生成 Goal

当任务本身还不清楚时，直接写 /goal 可能会把错误理解固定成持续目标。

因为 Goal 会成为 Codex 持续工作的目标和完成标准。如果一开始写的是“把这个模块优化一下”，模型就很难知道什么叫优化完成。

一个很实用的社区工作流是：先让 Codex 做 requirements gathering 和 research，不要急着人工填写 Goal；等它了解代码、配置和测试后，再让它生成并设置合适的 Goal。这样目标建立在项目事实和真实约束上，通常比一开始凭猜测写目标更可靠。[8]

更稳妥的方式，是先让 Codex 进入 Plan mode，调查代码并采访你：

/plan

我有一个可能不完整的需求，请先不要修改文件。

请先阅读相关代码、配置和测试，了解当前实现。
然后通过提问澄清目标、范围、约束和验收标准。

要求：
- 只询问真正会影响实现的问题；
- 可以从代码中确认的信息不要问我；
- 区分已确认事实、假设和待决定事项；
- 最后生成一段可以直接用于 /goal 的 Goal；
- 在我确认之前不要开始实现。

等 Codex 完成调查后，可以让它整理最终目标：

确认没有问题后，让它输出一段包含 Outcome、Scope、Constraints 和 Verification 的最终目标，并执行 goal（在我自己实践中，发现全让 ai 托管可能会走偏，还是要时不时看一下的）

大型重构或跨多个模块的项目，则可以把执行计划保存为 PLANS.md 或 ExecPlan。这样计划不再只是聊天中的一次性内容，而是一个可以随着技术决策不断更新的项目文档。[3]

官方当前文档也建议，在结果还不明确时，先让 Codex 通过提问识别约束，再把结果变成带有可验证完成标准的 Goal。[2] Goal 不需要写成完整技术设计，只要说明最终结果和判断完成的证据即可。

给模型路径自由，但保留必要边界

新模型拥有更强的自主性，并不意味着人类应该放弃边界。

真正值得保留的边界通常只有几类：不要扩大范围、不要破坏兼容性、不要通过跳过测试制造成功，不要未经确认执行数据删除或生产发布，发现现实约束冲突时暂停询问。

这些边界描述的是交付责任，而不是限制模型思考路径。具体阶段、工具和实现顺序，如果不涉及风险，就不必提前写死。

`AGENTS.md` 是长期上下文

如果每次都要告诉 Codex 项目如何启动、测试如何运行、哪些目录不能修改，那么这些信息就不应该一直停留在聊天记录里。

它们应该进入 AGENTS.md。

AGENTS.md 适合保存仓库布局、启动和测试命令、工程约定、限制条件，以及“什么叫完成”。

它还支持按范围分层。全局默认使用 <CODEX_HOME>/AGENTS.md，默认位置是 ~/.codex；仓库根目录可以存放团队规范；子目录可以存放某个服务或模块的本地规则。[4]

当前 Codex 会从项目根目录向当前工作目录逐级发现指导文件，并按从上到下的顺序拼接。更靠近当前目录的规则出现在后面，因此通常具有更高优先级。全局范围还可以使用 AGENTS.override.md，项目和子目录同样支持 override 文件。

每个目录最多纳入一个指导文件，默认项目指导内容总上限为 32 KiB；如果规则太多，就应该拆到更具体的子目录。

推荐先使用/init 生成初始模板，生成后人工再调整。

Subagent 不是免费的加速按钮

Subagent 更像是用额外 Token 换取并行等待时间。

每个 Subagent 都会独立运行模型和工具调用，因此并行工作流通常比单 Agent 消耗更多 Token。[5]

代码探索、测试检查、日志分析和资料整理都是比较适合并行的读密集型任务（read-heavy tasks）。写密集型任务（write-heavy tasks）则要谨慎，因为多个 Agent 同时修改代码会增加冲突和协调成本；范围明确的局部修改，留在主线程里通常更划算。

可以把判断标准写成一句话：

如果任务的主要成本是等待不同信息被读出来，可以考虑并行；如果任务的主要成本是协调多个修改，就先不要为了并行而并行。

官方文档还用“上下文污染”（Context pollution）描述中间输出淹没关键决策，用“上下文腐化”（Context rot）描述无关内容变多后任务表现下降。[5] Subagent 的价值之一，就是把这些噪音留在其他线程，只把总结带回主线程。

`/compact` 和 `/fork`

/compact会把早期对话压缩成摘要，释放上下文空间，同时保留关键细节。[6] 实践中，在一个里程碑完成并验证通过后再压缩，通常比在关键决策尚未确认时压缩更稳。

如果要探索两条不同的技术路线，可以使用 /fork 保留主线并创建新的聊天副本。原聊天不会被修改，分叉可以用来验证另一个方案。[6]

需要注意，/fork 复制的是聊天上下文，不是自动创建 Git 分支或 worktree。如果两个分叉都要修改代码，还需要额外的工作树隔离，否则两个会话仍然可能修改同一份文件。

Review 是另一个阶段

让 Codex 检查自己刚写的代码，通常不如让它换一个角色重新检查。实现结束后可以使用 /review，或者直接发送：

请以严格 reviewer 的身份检查当前 diff，重点关注回归、边界、错误处理、权限、安全、兼容性、测试遗漏和范围外修改。只报告有具体证据的问题，并给出文件、位置、原因和验证方式。

Review 应该回答哪里可能出错、为什么可能出错，以及如何复现。[7]

Review 没有发现问题，也只说明在当前上下文和检查范围内没有发现问题。

结语

使用 Codex 最容易陷入的误区，是把注意力放在“它能不能写出能运行代码”上。更困难的问题是：它是否理解当前项目，知道哪些东西不能改，知道什么结果才算完成，并且会验证自己的修改。

真正用好 Codex 方法并不是一套神奇 Prompt。我们应该先给上下文，再定义结果；让模型自由选择路径，但保留范围、权限和外部副作用的边界；用测试、真实冒烟和 Review 验收；把长期经验沉淀进 AGENTS.md 和 Skill，并且只在并行真正减少等待时使用 Subagent。

Codex 可以替你写代码，但只有在你把工作现场和完成标准说清楚之后，它才有机会真正替你完成一项工作。

参考资料

本文资料核验于 2026 年 8 月 2 日。

[1] OpenAI，Codex Best practices：https://learn.chatgpt.com/guides/best-practices

[2] OpenAI，Long-running work：https://learn.chatgpt.com/docs/long-running-work

[3] OpenAI Cookbook，Codex Execution Plans：https://developers.openai.com/cookbook/articles/codex_exec_plans

[4] OpenAI，Custom instructions with AGENTS.md：https://learn.chatgpt.com/docs/agent-configuration/agents-md

[5] OpenAI，Subagents：https://learn.chatgpt.com/docs/agent-configuration/subagents

[6] OpenAI，Slash commands：https://learn.chatgpt.com/docs/reference/slash-commands

[7] OpenAI，Code review：https://learn.chatgpt.com/docs/code-review?surface=app

[8] reach_vb，Codex tip：https://x.com/reach_vb/status/2076813989598662816

CTF今后到底会变成什么样子——ISCC赛后总结

Thu, 30 Jul 2026 16:00:00 GMT

初识 CTF

4 月初，我开始知道有 iscc 这个比赛，学校加分多，老师推荐参加。想着既然要参加，那就先查查这个赛事的流程和要点。因为是第一次参加 CTF 这类的比赛，想着做一点准备，就去helloCTF 上看看这个东西的流程，结果是开幕雷击

开场雷击：AI 学习曲线截图

当时的我感觉已经魔怔了，感觉 ai 无所不能，也不太看得起这些技术（当时装系统刚刚被 ai 代装各种环境震惊到）。可能就在下图这个橙线的附近（笑

自信曲线截图

之后也认真看了几天 helloCTF 的每个模块的内容。也和 ai 做了一些题，自己实在是没思路，只能依葫芦画瓢。其实我是知道一些方向的题目类型的，网上冲浪就见过不少，不过系统的学习总归还是不习惯，题目也完全没心思做，脑子全是 ai 怎么秒掉。所以没几天就全部放弃了。之后在 b 站搜索时就看见这个传奇的视频

B站视频截图

对于这个比赛的预期也就降低了很多。到了 5 月 1 日,校赛开始，也是噩梦开始，当时的我还不知道到底面对的是什么恐怖的比赛。

Kali 中的 CodeBuddy 安全提示

图为前一天调试 kali，装的是 codebuddy，想着免费国产 ai 凑合一下，因为感觉 agent 在 pwsh 经常出错，且听说 kali 内置了很多工具，所以选的（但是后来处理 word 给我带来了很多麻烦

ai 挺能做题

校赛开始，首先就是平台进不去，卡住了大部分人，当我 ai 做出 1 题时，看见校榜有人只差 2 题了，开始感觉有点难绷，想着大家都这么强。

AI 长时间卡住的状态

被 ai 逼疯中

校赛题目列表

在下午之前也是靠 ai 顺利完成大部分题，misc 太吃脑电波了，ai 解不动，最后是靠网络的 wp 解的（小众变态比赛特有的渠道）

5 月 2 日，官方群里也是充满了快活的气氛，我也渐渐感觉这个比赛也不是很权威了

校赛群聊截图一

校赛群聊截图二

校赛群聊截图三

群聊整活截图

致敬传奇整活王 z 神

比赛开始越来越抽象

5 月 3 日，官方突发恶疾，在没有任何通知的情况下出了一道机器学习的题

机器学习题目页面

机器学习题规则截图

这个题的评分也十分猎奇，数据量不太足，数据集里感觉还有噪声，用普通的模型准确度都不太高，但是却只能提交 5 次，越做越低这一块

机器学习题提交记录

下午 2 点，突然集体开智

机器学习题排行榜变化

排行榜前面的每个人都是全对了

机器学习题排行榜截图

群里的焚诀，但是我用了还是没过，也不知道是不是真的

群聊中的机器学习解法讨论

群里怨声载道

下午 4 点，又是突然一个公告

机器学习题相关公告

莫名其妙就结束了，浪费大家假期一个下午的时间。

校赛群聊截图

5 月 4 日，这个比赛已经初现端倪了，这时我已经逃离学校，美美旅游了（但是这游戏本是真的重，旅行带太降体验了，比赛挑假期这一块）

省赛—八仙过海

省赛 5 月 9 日 8 点开始，但是 15 分钟还是没进

省赛题目页面

骗你的，进了也看不见题

那几天我捣鼓了中转站，准备用 GPT 大战一番，结果：

GPT 拒绝处理 CTF 请求

5.5 太安全了🤣

省赛做题统计一

省赛做题统计二

这时感觉自己还不赖（GPT 还是强）

官方群欢乐多

官方群聊截图一

官方群聊截图二

官方群聊截图三

官方群聊截图四

官方群聊截图五

官方群聊截图六

这几天虽然没怎么认真做题，但是分数还够看，也开始了 wp 的编写和提交。web 的复现还是比较容易的，我每题都花了 30min 左右，其实自己复现也发现题目也没有很难，只是做的太少，不能第一时间马上想到而已。

群聊中的 ban 讨论

为后来我被 ban 埋下伏笔（不是）

flag 数据异常截图

图为有师傅打到云实例（？）发现 flag 之前没有，但是有 10 多个人已经交成功了

IDA 逆向分析截图

汇编真的好难懂不知道前人是怎么学逆向的有了 IDA 还是得需要借助 agent 分析。自己找好难

题目来源争议公告

草台班子这一块

5 月 13 日，又出现有一波人提前扫端口扫到题目，一大波秒提交。我已经麻木了😴。从省赛过后，每天都有擂台题，已经整不动了，还加上上课，即使做出来也比其他人慢，往往最后只有 70% 60%的分数了（难绷的分数衰减）

临时加题公告

神秘主办方又偷偷加题，且是又没有提前通知，当时真有点受不了了，折磨学生大半个月，每天心惊肉跳。

官方群解散公告

之后直接演都不演了，解散了所有的群聊，像我这样单兵作战的直接没了信息来源，各种题的问题只能自己琢磨了，像是进入了黑暗森林。也因为没有客服的通知，我在国赛当天都忘记开始了这回事，排名马上到后面去了。

Token 消耗统计

当时的 token 消耗（纪念一下）

PWN 服务器遭攻击公告

iscc 笑传之查查爆，这个题从 8 点进不去一直到下午 15 点 30 才开放，让很多人苦苦等在电脑前面浪费时间（包括我）

GPT 能做题，WP 还是得自己写

之后就是痛苦的写 wp 的时间了，因为我只对 web misc 还比较熟悉其他的几乎是看不懂的状态，各种工具我还是借助 agent 一步一步的学习使用的，所以复现非常的痛苦又耗时，最后直接摆烂 ai 写文档我再小改了，在最后有惊无险的提交了 47 篇 wp。

赛后总结？

经过漫长的等待，最终结果是我国赛的成绩 ban 了（随机 ban 人名不虚传），只有省三（差 1.. 省二）这次比赛倒是让我的视野得到了极大的拓展，原来线上 CTF 已经变成科技大赛了，ai 的出现极大的降低了 CTF 的门槛，我这种几乎零基础的新手也可以快速上手各种题目，这也让我的学习的路径变得“ai 原生”。ai 成了不可缺少的一部分，这变相减少了要网上翻各种资料和论坛的麻烦。但是 ai 始终还是不能替代人类的判断，有几次明明 ai 都快拿到 flag 了，但还在做各种校验，这时只要引导一下 ai，马上就可以得到答案。而我缺少的一些经验以及围绕模型建立的工具链（要不然 ai 会降级或者反复尝试安装导致浪费时间）也是和最快的师傅？拉开差距的一部分。 ai 挖洞其实已经有可行性了（现在已经看见批量挖洞的了）。也弱化了我对于 Linux 的刻板印象，ai 在 Linux 简直是如鱼得水，各种配置都能靠命令搞定，有种一切尽在掌握的感觉，且软件间的壁垒也很弱，很容易实现通信协作。

初识 Kubernetes：从 Service 与 CoreDNS 理解服务发现

Tue, 26 May 2026 16:00:00 GMT

最近在 K8s 集群里部署多服务时，最让人意外的是服务之间居然可以不写 IP、不改代码地互相找到对方。这篇笔记拆解这套机制是怎么实现的：Service 如何当稳定的”门牌号”、CoreDNS 怎么当集群内的”黄页”、以及这套设计与单机 localhost 部署的本质区别。

1. 先理清 K8s 的几个基本对象

讲服务发现之前，先把几个会反复出现的对象过一遍，避免后面混在一起。

对象	一句话解释
Pod	K8s 调度的最小单位，里面跑着一个或多个容器。每个 Pod 有自己的 IP，但这个 IP 不稳定——重启就换。
Deployment	用来声明”我要跑 N 个相同的 Pod”，K8s 会自动维护这个数量（挂了会重启）。
Service	一组 Pod 的稳定访问入口。给它一个名字 + ClusterIP，后面所有 Pod 都通过这个名字访问它。
NodePort / Ingress	把 Service 暴露到集群外部的两种方式（前者用节点端口，后者用 HTTP 路由）。

记住一句话：Pod 是临时的，Service 是稳定的。 后面所有机制都围绕这个差异展开。

2. Service：一个虚拟的、稳定的”门牌号”

创建 Service 时，Kubernetes 会在集群内部为它分配一个固定的虚拟 IP（ClusterIP）。这个 IP 永远不会变——只要 Service 存在，它就在那里。

假设后端被部署成 3 份 Pod：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  replicas: 3   # 3 个相同的 Pod
  template:
    spec:
      containers:
        - name: backend
          image: my-backend:1.0

每个 Pod 启动后会被分到自己的随机 IP，比如 10.244.1.5、10.244.2.3、10.244.3.8。如果前端直接写这些 IP，任何一个 Pod 重启，IP 就变了，前端就找不到了。

解决办法是再创建一个 Service：

apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend         # 选中上面那 3 个 Pod
  ports:
    - port: 80
      targetPort: 8080

K8s 会做两件事：

给这个 Service 分一个固定 ClusterIP（比如 10.96.100.1）。
在背后维护一个负载均衡器，把发往 10.96.100.1:80 的请求，均匀转发到那 3 个 Pod 上。

于是前端只需要记住 backend:80（或者 10.96.100.1:80）这一个地址，就能访问到后端的任意副本。后端 Pod 增减、重启、IP 变化，前端完全不感知。

3. CoreDNS：一个内置的”黄页”

让前端去记 10.96.100.1 这种纯数字地址不现实。Kubernetes 内建了一个 DNS 服务（CoreDNS），相当于集群内部的电话本：

创建一个叫 backend 的 Service 后，CoreDNS 会自动注册一条记录：backend → 10.96.100.1。
前端 Pod 里的应用发起 http://backend:80 请求时，容器里的 DNS 解析器会自动把 backend 翻译成 10.96.100.1，流量就精准抵达了后端的 Service。

前端 Pod 里的应用：GET http://backend:80/api
   ↓ DNS 解析
CoreDNS：backend → 10.96.100.1
   ↓ 流量转发
backend Service (10.96.100.1) → 负载均衡到某个后端 Pod

这就是”服务发现”的本质：调用方只需要知道服务名，不需要知道它有几个副本、IP 是什么、跑在哪台机器上。

4. 一个完整的调用链路

假设集群里有 3 个服务：数据库、后端、前端。完整通信过程是这样的：

# 1. 数据库
apiVersion: v1
kind: Service
metadata:
  name: db
spec:
  selector:
    app: mysql
  ports:
    - port: 3306

---
# 2. 后端（3 副本）
apiVersion: v1
kind: Service
metadata:
  name: backend
spec:
  selector:
    app: backend
  ports:
    - port: 80
      targetPort: 8080

---
# 3. 前端（NodePort 暴露给外部）
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  type: NodePort
  selector:
    app: frontend
  ports:
    - port: 80
      nodePort: 30080

后端代码里，数据库连接地址直接写成 db:3306，不用关心 MySQL 的 Pod IP：

# 后端代码示例
import mysql.connector
conn = mysql.connector.connect(
    host="db",       # 直接用 Service 名
    port=3306,
    user="app",
    password="xxx",
    database="app_db"
)

前端代码里，API 请求地址直接写成 backend:80，也不用关心后端有几个副本：

// 前端代码示例
fetch("http://backend:80/api/users")
  .then(res => res.json())
  .then(data => console.log(data));

用户从浏览器访问 http://Master节点IP:30080 时，完整的链路是：

用户浏览器
  ↓ http://MasterIP:30080
前端 Service (NodePort)
  ↓ 负载均衡到某个前端 Pod
前端 Pod 发起 GET http://backend:80/api
  ↓ CoreDNS 解析 backend → 10.96.100.1
后端 Service
  ↓ 负载均衡到某个后端 Pod
后端 Pod 连接 mysql -h db
  ↓ CoreDNS 解析 db → 10.96.x.x
数据库 Service
  ↓ 连上 MySQL Pod

整个过程中，没有一个地方出现了具体的 Pod IP 或节点 IP。 服务之间完全通过 Service 名称通信，K8s 自动处理负载均衡、高可用和故障恢复。

5. 和单机 `localhost` 部署的本质区别

单机上跑多服务时，连接地址通常是这样写的：

# 单机部署：写死 localhost
conn = mysql.connector.connect(
    host="localhost",  # 必须是本机
    port=3306,
    ...
)

要把后端拆到另一台机器上，要改的东西很多：IP 地址、端口、可能还有防火墙、配置中心……

维度	单机 `localhost` 方式	Kubernetes Service 方式
服务地址	固定写死 IP/端口	通过虚拟 IP + DNS 动态发现
扩展性	无法横向扩展（端口冲突）	随时增减副本，前端无感知
故障恢复	进程挂了就断了	副本自动重新调度，Service 自动转发到健康实例
部署灵活性	所有服务绑死在同一台机器	服务可以分布在集群的任何节点上
代码改动	迁移机器要改 IP/配置	一行不用改，Service 名不变即可

用一句话总结这个差异：

单机部署是”我告诉你地址”，Kubernetes 是”告诉我你叫什么，我帮你找到地址”。

后者让服务之间的通信变得松耦合、高可用，也更符合微服务架构的理念。

6. 写给自己的小结

这次在集群里做多服务部署实验，最关键的认知升级不是”我会写 yaml 了”，而是理解了”为什么 Pod IP 不重要”。

只要 Service 还在、名字没变，Pod 怎么重建、IP 怎么换、节点怎么调度，对调用方来说都是透明的。这种”调用方不关心被调用方物理位置”的设计，是分布式系统能横向扩展的基石。

K8s 把这套机制内化到了平台层——调用方一行代码不用改，平台就把寻址、负载均衡、故障恢复全做了。这在单台服务器上根本无法做到：单机部署时，进程地址是写死的、端口是冲突的、机器是绑死的，这套”靠名字找服务”的能力在单台服务器上根本无从发挥。

CLI Agent 实践指南：从 Claude Code 到通用方法论

Fri, 24 Apr 2026 16:00:00 GMT

这一两年里 CLI Agent 编程助手换了好几轮——从 Claude Code 到 Codex ，中间还试过 Copilot CLI——但用久之后发现，三家的”骨架”几乎一样：plan 模式、文件注入、shell、压缩、恢复、回退、模型切换、权限管控。基本是通用的，差异只在命令名。

这篇以 Claude Code 为主线，对照 Codex CLI 和 GitHub Copilot CLI，把用得上的方法整理成 5 节：Plan 模式、命令、上下文管理、安全权限、实践经验。读完之后应该能在任何一个 CLI Agent 上快速上手。

0. 三家命令速查

先把骨架放在一起。下面的表格在三家之间通用，命令名差异不大。

能力	Claude Code	Codex CLI	Copilot CLI
进入 Plan 模式	`Shift+Tab` → `plan`	`Shift+Tab` → `Read-only`（Approval mode）	`Shift+Tab` 或 `/plan <描述>`
外置编辑器写计划	`Ctrl+G`	`Ctrl+G`（`$EDITOR`/`$VISUAL`）	`Ctrl+Y`（Markdown 编辑器）
注入文件	`@文件路径`	`@` + `Tab` 模糊搜索	`@路径` 或 `@图片.png`
会话内跑 shell	`!命令` + `Ctrl+B` 后台	`!命令`（受 Approval mode 约束）	通过 `shell(...)` 权限调用
清空上下文	`/clear`	`/clear`	`/clear` 或 `/new`
侧边问（不污染主历史）	`/btw`	—	—
摘要压缩	`/compact [focus...]`	API 层自动	`/compact`（手动）/ 默认自动
恢复会话	`/resume`、`claude -c`、`claude -r`	`codex resume` / `codex resume --last` / `codex resume <id>` / `codex exec resume`	`/session`
回退 checkpoint	`/rewind` + `Esc+Esc`	`Esc`×2 编辑上一条消息（=fork 入口）	`/session checkpoints` + `双 Esc`
切换模型	`/model` + `Alt+P` + `--effort`	`/model`	`/model`（含 Auto / Opus 4.5 / Sonnet 4.5 / GPT-5.2 Codex）
看上下文用量	`/statusline` 自定义	`/status`	`/context` + `/session files`
权限管理	`/permissions` + `settings.json`	`/permissions` 切 Approval mode + `config.toml`	`--allow-tool/--deny-tool/--available-tools`
跳过所有权限	`--dangerously-skip-permissions`	`--yolo`	`--yolo` / `--allow-all`
多仓库/多目录	`--add-dir`	`codex --cd` + `--add-dir`	`/add-dir` + `/list-dirs`
并行子代理	`claude agents` + agent teams	`codex agents` + `/fork`	`/fleet` + `/task`
会话存档位置	`~/.claude/projects/<project>/`	`~/.codex/sessions/`	`~/.copilot/session-state/{id}/`

后面所有方法论都围绕这张表展开。

1. Plan 模式：所有工作的起点

1.1 决策树：能用一句话描述 diff 吗？

能 → 不用进 Plan，直接让 Agent 改。例：修 typo、加日志、改变量名、调整一个 import。

不能（涉及多文件、跨模块、不熟悉的代码、不确定的方案）→ 必须进 Plan 模式让 Agent 先只读、不写。

Plan 模式的核心价值是把”问题理解”和”动手”在时间上分开——这两件事分得越开，返工率越低。

# Claude Code
Shift+Tab  # 在 default / acceptEdits / plan / auto / dontAsk / bypassPermissions 之间循环

# Codex
Shift+Tab  # 在 Read-only / Auto / Full Access 之间循环，选 Read-only = Plan 模式

# Copilot
Shift+Tab  # 或 /plan Implement password reset flow with email link

1.2 Plan 阶段的 3 个高阶玩法

1）用外置编辑器把计划当合同

三家都能在 Plan 阶段用外置编辑器写计划。意义在于：把”硬约束”直接写进计划文件里，让计划成为可审查的合同。

# Claude Code / Codex
Ctrl+G  # 打开 $EDITOR 编辑当前 plan

# Copilot
Ctrl+Y  # 在 Markdown 编辑器中打开 plan.md

典型约束写法：

## Plan: 实现密码重置流程

### 涉及文件
- src/api/auth.ts
- src/services/email.ts
- tests/auth/test_reset.py

### 约束（必须遵守）
- 保留向后兼容（旧的 /login 流程不能动）
- 先写测试再写实现
- 不要改数据库 schema
- 使用项目里现成的 token-manager.ts，不要引入 passport.js

### 验证
- `pytest tests/auth/ -k reset` 全部通过
- `mypy src/auth/` 无错误

写完之后保存退出，Agent 会按”合同”实现。

2）计划里显式列验证步骤

没写验收标准的计划 = 100% 会变成”看起来做完了”。

### 验证
1. Run `pytest tests/auth/ -k reset` and ensure all 3 new cases pass.
2. Run `mypy src/auth/` to confirm no type errors.
3. Open a PR with title "feat(auth): password reset flow".

Agent 擅长”对照 plan 自检”——前提是把验证步骤写进去。

1.3 三家 Plan 命令对照

步骤	Claude Code	Codex	Copilot
进 Plan	`Shift+Tab` → `plan`	`Shift+Tab` → `Read-only`	`Shift+Tab` 或 `/plan <描述>`
写计划	`Ctrl+G`	`Ctrl+G`	`Ctrl+Y`
让 Agent 继续	”Proceed with the plan"	"proceed” / “go"	"Proceed with the plan”
中止 Plan	再按 `Shift+Tab` 退出	切到 `Auto` 或 `Full Access`	再按 `Shift+Tab` 退出

2. 需要掌握的 7 个命令

按使用频率排序。这 7 个命令覆盖 90% 的日常使用，其余命令是”知道有就行，需要时查 /help”。

2.1 `@文件` / `@路径/` — 精准注入上下文

@src/api/auth.ts       # 单文件
@src/api/auth/         # 整个目录
@../docs/spec.md       # 项目外的文件

也可以直接拖进 cli，都支持得不错

核心原则：让 Agent 按需读相关部分。

CLAUDE.md / AGENTS.md 里也支持 @docs/git-instructions.md 语法引用其他文件，最多 4 层引用。三家都有这个特性，行为一致。

2.2 `!命令` — 会话内跑 shell

! npm test              # Claude Code
! git status
! ls -la src/

# 进阶
! long-running-task     # 长任务
Ctrl+B                  # 转后台（Claude Code 特有），不阻塞主对话

上下文行为：输出会回到主对话——只在确实需要 Agent 看到结果时用；纯查看用 ! 更顺手。
粘贴以 ! 开头的内容会自动进入 shell 模式（Claude Code 行为）。

Codex 和 Copilot 都有 shell 工具，能用 !git diff、!cat file 直接验证。

2.3 `/clear` — 切任务时清空上下文

/clear                  # 清空 + 当前对话进 /resume 选择器
/clear feature-auth-work   # 给被清掉的对话打标签（Claude Code 特有）

使用节奏：每完成一个独立任务 → /clear。一次会话只做一件事。

官方原话警告过一种反模式——“kitchen sink session”：一个会话混入不相关任务，等要清理 context 时已经一团糟。

2.4 `/compact [focus...]` — 长会话摘要压缩

/compact                            # 压缩整个对话
/compact focus on the API design    # 带方向压缩

关键事实（Claude Code 文档原话）：“Project-root CLAUDE.md survives compaction: after /compact, Claude re-reads it from disk and re-inject it.” —— 项目根的 CLAUDE.md 不会因压缩丢失；但子目录的 CLAUDE.md 会丢失，直到下次读到该目录才重新加载。

何时用 /compact：

对话长了但任务没完 → /compact focus on X。
同一任务上修 Agent 同一错误超过 2 次 → 立刻 /clear（用更好的 prompt 重开，不要继续累积修正）。
Codex 隐式做了这件事，没有显式 /compact，但可以 /fork 派生新会话。

2.5 `/resume` — 恢复历史会话

# Claude Code
/resume                       # 打开选择器
/resume feature-auth          # 按名恢复
claude -c                     # 续当前目录下最近对话
claude -r <id>                # 按 ID 恢复

# Codex
codex resume
codex resume --last
codex resume <id>

# Copilot
/resume                       # 打开 ~/.copilot/session-state/ 选择器

配合 git worktree 的高阶用法：每个 worktree 一个 codex resume / claude -r <id> 会话。切分支 = 切会话，context 完全隔离。

2.6 `/rewind` / `/session` — 回退到 checkpoint

# Claude Code
/rewind          # 弹出检查点选择器
Esc+Esc          # 空输入时弹 rewind 菜单（含 "Summarize from here" / "Summarize up to here" 选项）

# Copilot
/session                  # 查看当前会话信息
/session checkpoints      # 列出所有检查点
/session checkpoints 3    # 查看第 3 个检查点内容
/session files            # 列出当前会话临时文件
双 Esc                     # 在 composer 为空时打开 rewind picker

# Codex
Esc × 2（composer 为空时）  # **编辑上一条用户消息** —— 这也是 fork / 分叉的入口

Copilot 警告：“Rewinding cannot be undone. Once you roll back to a snapshot, all snapshots and session history after that point are permanently removed.” —— 回退是不可逆的。

注意：/rewind 会同时回退 Agent 改的、手动改的、shell 命令产生的所有变更，包括之后新增的文件。回退前先 git status 确认工作区状态。

Codex 关键差异：Codex 没有 /rewind 概念，而是把”分叉”和”回退”合在一起——Esc×2 编辑上一条消息后，从那个时间点分叉新会话；不满意就丢，老会话仍在 /resume 里。

2.7 `/model` + `--effort` — 切模型与思考强度

# Claude Code
/model                # 打开选择器
Alt+P                 # 切换模型不丢失当前 prompt（更快的快捷键）
--effort low/medium/high/xhigh/max    # 调节思考强度

# Codex
/model
codex --model gpt-5.5

# Copilot
/model                # 含 Auto / Opus 4.5 / Sonnet 4.5 / GPT-5.2 Codex

核心技巧：让主模型去调度 subagent，subagent 可以指定使用不同的模型，节约用量

2.8 锦上添花

命令	哪家	用途
`/btw`	Claude Code	侧边问题，答案不进入主对话历史；纯提问用，访问不到工具——完美的”等下，X 那个 Y 是否考虑过”场景
`/statusline`	Claude Code	自定义状态栏持续追踪上下文用量
`/goal`	Claude Code	跨会话条件门控（评估器每轮重新检查）
`/diff`	Claude Code	交互式 diff 查看器，左右键切”当前 git diff”和”单 turn diff”，审 PR 前必看
`/code-review`	Claude Code	内置代码评审（在全新子代理中评审当前 diff）
`/recap`	Claude Code	按需生成会话摘要（默认自动每 3 turn 触发）
`/delegate`	Copilot	把当前会话转给 GitHub 云端 Copilot，云端代理会创建 PR
`/fleet`	Copilot	启动并行子代理加速大任务
`/task` / `/review`	Copilot	显式触发子代理（review 有 4 种预设：base branch / uncommitted / commit / custom）
`claude -p "..."`	Claude Code	非交互模式，配 `--output-format json` / `--output-format stream-json --verbose` 给 CI、pre-commit、脚本用
`codex exec "..."`	Codex	非交互执行；`codex exec resume --last "Fix race"` 续上次
`codex cloud exec --attempts 3 "..."`	Codex	云端 best-of-N（1-4 次并发尝试）
`codex features enable unified_exec`	Codex	启用新功能（如 `unified_exec` 执行模式、`shell_snapshot`）
`codex app-server --listen ws://...`	Codex	启动 App Server，远程 TUI 通过 WebSocket 连接
`claude agents` / `codex agents`	三家	打开多代理视图，监控并行后台会话
`claude -c`	Claude Code	续当前目录下最近对话（最快的工作流快捷方式）
`/add-dir`	Copilot / Codex	多仓库/多目录工作流，加额外目录进 Agent 可访问范围

3. 上下文管理：context window

Anthropic 官方：“Most best practices are based on one constraint: Claude’s context window fills up fast, and performance degrades as it fills.”

所有”上下文最佳实践”都围绕”别浪费它”展开。

3.1 4 种”喂”上下文的姿势

从高到低：

@文件路径（最优）—— 引用文件，Agent 按需读相关部分。Claude Code 与 Copilot 支持 @path/to/file 完整路径；Codex 的 @ 触发的是模糊文件搜索（@ + Tab 选中），再 Enter 填入。
粘贴图片/截图/错误堆栈 —— OCR 不必，人类也读图。三家都支持拖放图片到 CLI 输入。
cat error.log | claude（管道输入） —— 适合一次性文本。
整文件复制（最差）—— 1000 行代码塞进 prompt，挤占 context。

Claude Code 特有技巧：/permissions 把常用文档域名（docs.example.com）加白名单，让 Agent 自己去拉。

通用技巧：gh CLI 是 GitHub 上下文最高效的获取方式——Anthropic 文档原话：“Without gh, Claude can still use the GitHub API, but unauthenticated requests often hit rate limits.”

3.2 3 个清理层次

触发场景	操作	效果
Agent 走偏了一点	`Esc+Esc` 局部回退 + 改 prompt 继续	撤回最近几轮（Codex 是 fork 入口）
想问个不相关的边角问题	`/btw`	侧边问，答案不进入主对话历史
对话长了但任务没完	`/compact focus on X`（Claude/Copilot）	保留当前任务，只压缩历史
任务完成要开始新任务	`/clear`	完全清空，原对话进 `/resume`

关键节奏：同一任务上修 Agent 同一错误超过 2 次 → 立刻 /clear 用更好的 prompt 重开。

官方原话：“If you’ve corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches.”

干净会话 + 更好的 prompt 永远胜过”长会话 + 累积修正”。

3.3 4 层记忆文件 + 一键生成

把”每次都要说的事情”挪到磁盘，让 Agent 在每个新会话里”已经知道项目是谁搭的、约定是什么”——这是从”工具”到”协作者”的关键升级。

Claude Code 的一键生成：在项目根跑 /init —— Agent 分析项目结构自动生成 CLAUDE.md 起始模板。

加载顺序（从广到窄）：

作用域	Claude Code	Codex	Copilot
用户全局	`~/.claude/CLAUDE.md`	`~/.codex/AGENTS.md`	`~/.copilot/copilot-instructions.md`
用户全局覆盖	（local 后缀）	`~/.codex/AGENTS.override.md`	（`.override`）
项目共享	`./CLAUDE.md` 或 `./.claude/CLAUDE.md`	`./AGENTS.md`	`.github/copilot-instructions.md`
项目模块化	`./.claude/rules/*.md`（支持 `paths` frontmatter）	每层一个 AGENTS.md	`.github/instructions/*/.instructions.md`
项目个人	`./CLAUDE.local.md`（gitignore）	子目录 `AGENTS.override.md`	本机范围
团队组织	Managed policy 文件	`project_doc_fallback_filenames`	组织托管规则

Copilot 加载顺序的关键规则：“Repository instructions always take precedence over user instructions”（仓库级指令始终优先于全局指令）。

加载行为：不是覆盖而是拼接（Anthropic 原话：“All discovered files are concatenated into context rather than overriding each other”）。子目录的 CLAUDE.md 只在 Agent 读该子目录文件时才按需加载。

CLAUDE.md 里支持 @ 导入语法：可以在 CLAUDE.md 中写 See @README.md for project overview and @package.json for available npm commands.，Agent 会按需展开。最多 4 层引用。

大小上限：

Claude Code MEMORY.md 启动时只加载前 200 行 / 25KB（自动记忆机制）。
Codex 合并总大小上限是 project_doc_max_bytes = 32 KiB（默认）。
复杂规则不要写进 CLAUDE.md，改用 PreToolUse hook 强制约束。

3.4 跨会话：CLAUDE.md vs Auto memory vs Codex Memories

CLAUDE.md（人工写）—— 由开发者维护、每会话完整加载。应只放”普适指令”。

Auto memory（Claude Code v2.1.59+，Agent 自己学） —— Agent 自己记录 build commands、调试经验、架构笔记。存到 ~/.claude/projects/<project>/memory/，首次 200 行 / 25KB 启动时加载，详情文件按需读。默认开启，可用 /memory 命令切换。

Codex Memories / Chronicle（Codex 0.140+ 新增） —— 文档侧栏已列出 /codex/memories 和 /codex/memories/chronicle 入口，对应 OpenAI 的持久记忆子系统。Chronicle 给出”会话历史洞察”。

关键事实（Claude Code 文档原话）：“Both are loaded at the start of every conversation. Claude treats them as context, not enforced configuration. To block an action regardless of what Claude decides, use a PreToolUse hook instead.”

记忆文件只是上下文不是规则——要强制约束必须用 hook，不是写文档。

3.5 长任务的会话状态恢复

方案	适用	说明
A. worktree + 会话隔离	大功能 / 长期任务	每个 git worktree 一个 `codex resume` / `claude -r <id>` 会话。切分支 = 切会话，context 完全隔离
B. CLAUDE.md 写”怎么续”	中等任务	在指令文件里写”如果中断了，请先 `git log -5` 和 `git status` 再继续”——把”怎么续”作为冷启动指令
C. 连续 5 小时不清	强烈不推荐	后期 Agent 必然开始”忘记”早期约束、变笨、产出重复修复

4. 安全：deny 永远第一

永远不要让 Agent 默认拥有破坏性权限。“给它 1 个权限 = 让它能用到 1 个” 是错误模型；正确模型是”默认拒绝 + 显式白名单”。

4.1 三级危险模型

把工具按破坏半径分三档，配权限时心里有数：

等级	例子	配权策略
L1 只读	`Read`、`Grep`、`Glob`、`Bash(ls *)`、`Bash(git status)`	几乎无副作用，可以默认开
L2 局部写	`Edit`、`Write`、`Bash(npm test)`、`Bash(git commit *)`	影响工作区，需要按任务白名单
L3 系统级	`Bash(rm -rf )`、`Bash(curl )`、`Bash(git push )`、`Bash(sudo )`	必须显式拒绝或每次确认

4.2 deny 永远优先于 allow

这是 Claude Code / Codex 共同的关键规则（Anthropic 原话）：“Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity does not change the order.”

核心警告：“提示中的指令或 CLAUDE.md 只能’影响 Claude 尝试做什么’，不能改变 Claude Code 实际允许的内容。”

也就是说，prompt 写”请不要 rm -rf”是无效的；必须在 settings.json 里 deny。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(* --version)"
    ],
    "deny": [
      "Bash(git push *)",
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(sudo *)"
    ]
  }
}

复合命令陷阱：“Claude Code 识别 shell 操作符，因此 Bash(safe-cmd *) 不会授权执行 safe-cmd && other-cmd。” —— 不会被通配符绕过。

4.3 三家权限机制对照

维度	Claude Code	Codex	Copilot CLI
配置文件	`settings.json`（4 层优先级）	`~/.codex/config.toml`	CLI 启动参数 + `.github/copilot-instructions.md`
写规则语法	`permissions.allow/deny/ask`	Approval mode（Auto / Read-only / Full Access）+ `sandbox` 配置	`--allow-tool` / `--deny-tool` / `--available-tools` / `--excluded-tools`
工具模式匹配	`Bash(git:*)`（冒号）	基于前缀 + shell 元字符	`shell(git:*)`（冒号）
优先级	deny > ask > allow（按列表顺序）	Approval mode 是边界 + 是否提示	`--available-tools` 覆盖 `--excluded-tools`；`--deny-tool` 覆盖 `--allow-tool`
沙箱能力	OS 级 sandbox（`/sandbox`，仅 Bash）	`sandbox` 配置（结合 Approval mode）	仅基于规则的 allow/deny
推荐默认	`default` 模式 + 编辑过的 `settings.json`	Approval = `Auto`，按任务加白名单	`--available-tools='bash,edit,view,grep,glob' --allow-tool='shell(git:*)' --deny-tool='shell(git push)'`

4.4 Approval mode 三档

Codex 把审批做成了三档显式状态（通过 /permissions 切换，配置在 config.toml 的 approval_policy）：

Mode	能力	何时用
Auto（默认）	当前工作目录内读/写/执行；越界（目录外、网络）需确认	日常开发
Read-only	只浏览文件，不做修改，需先批准 plan	审 PR、看代码、咨询
Full Access	跨整台机器 + 网络，不再询问	可信仓库的自动化

Claude Code 有 OS 级 sandbox（/sandbox 启用，限制 Bash 文件系统和网络访问）。Copilot CLI 没有真沙箱，只能靠 --deny-tool 黑名单 + --available-tools 白名单缩小可选工具集。

Codex 的 4 层防御（配合使用）：

Approval mode（Auto / Read-only / Full Access）
sandbox 配置（文件系统和网络隔离）
config.toml 的 [permissions] 段（具体规则白/黑名单）
启动旗标 --yolo 完全绕过（最后手段）

4.5 `--yolo` / `--dangerously-skip-permissions` 是最后手段

工具	旗标	备注
Claude Code	`--dangerously-skip-permissions`（`bypassPermissions` 模式）	跳过权限提示，但强制 ask 规则仍然提示；针对根目录与家目录的删除仍会作为熔断机制
Codex	`--yolo` = `--dangerously-bypass-approvals-and-sandbox`	”在生产或共享环境使用 `--yolo`（除非处于专用沙箱 VM）“是被明令禁止的
Copilot CLI	`--yolo` / `--allow-all`	等同于同时启用 `--allow-all-tools`、`--allow-all-paths`、`--allow-all-urls`

官方一致警告：“Only use this mode in isolated environments like containers or VMs”。

替代方案：别用 --yolo，用 --allowedTools "Edit,Bash(git commit *)" 显式限定权限范围——Anthropic 原话：“The --allowedTools flag restricts what Claude can do, which matters when you’re running unattended.”

Claude Code 还有一个新选项：--permission-mode auto（Auto mode）—— 单独的分类器模型审核命令，拦截范围升级、未知基础设施、恶意驱动操作。比 bypassPermissions 更安全：只跳过”低风险”命令的提示，高风险仍询问。注意：Auto mode 在非交互 claude -p 模式下，若分类器反复阻止会中止（无用户兜底）。

5. 做 Agent 的产品经理

Agent 时代编程的本质是”做 Agent 的清晰操作员”。Simon Willison 的原话：

“The ‘agentic’ coding tools we have right now work like this: A skilled individual with both deep domain understanding and deep understanding of the capabilities of the agent…”

价值 = 领域知识 × 工具熟练度。下面 7 条心法按”反人性”程度排序。

5.1 提问要像产品需求文档

反例：“修一下这个 bug”。

正例：“登录在 session timeout 后失败，错误堆栈是 [粘贴]。先写一个失败测试复现，再修根因，不要只 suppress 错误。修改后跑 pytest tests/auth/test_session.py 全部用例验证。”

黄金模板：[症状] + [期望行为] + [验证标准] + [禁止做法]。

Anthropic 原话：“Give Claude a way to verify its work. ‘Looks done’ is not a good signal.”

给 Agent 配 4 种”验证门控”（按设置成本从低到高）

同一个 prompt 内 —— 在指令里直接要求”运行测试并迭代直到通过”。
/goal（Claude Code） —— 跨会话条件门控，评估器每轮重新检查。
Stop hook（Claude Code） —— 脚本执行检查，阻止 turn 结束直到条件满足（注意：连续 8 次阻止后 Claude Code 会强制结束 turn，避免死循环）。
Verification subagent（独立 context）—— 在新上下文中反驳/审阅结论，避免自评偏差。
Browser screenshot（Claude Code + Chrome）—— 截图对比设计稿，验证 UI 改动。

5.2 增量验证：每改 10 行看一次

不要 100 行一次性 commit。每次让 Agent 改完：

git diff 确认范围正确
用 /diff（Claude Code）看每 turn 的具体改动
让 Agent 跑测试
每次提交独立一个 commit（git add -p），便于回退和 review

反模式：“把整个功能一次写完再 review”——一旦 review 出问题，不知道哪 50 行引入的。

5.3 任务拆分：一个会话 = 一件事

反模式：一个会话里做”加 OAuth + 修首页 bug + 重构 utils”，混完后清理 context 极痛苦。

正例：

会话 1 = “实现 password reset”
会话 2 = “加 metrics middleware”
用 git 分支隔离

官方警告：“The kitchen sink session: One session with unrelated tasks. Use /clear between unrelated tasks.”

5.4 两次失败就 `/clear` 重来

Anthropic 原话：“If you’ve corrected Claude more than twice on the same issue in one session, the context is cluttered with failed approaches. Run /clear and start fresh with a more specific prompt that incorporates what you learned.”

干净会话 + 更好的 prompt 永远胜过”长会话 + 累积修正”。

5.5 子代理是 context 的瑞士军刀

“Since context is your fundamental constraint, subagents are one of the most powerful tools available.”

子代理在独立 context 中运行、返回摘要，主对话不被”读了 200 个文件”污染。

典型用法：

让 explore 子代理查 “auth 系统怎么管 token refresh” → 返回一段摘要。
让审查子代理用新 context 复审刚改的 diff —— 关键洞察：“A reviewer running in a fresh subagent context sees only the diff and the criteria you give it, not the reasoning that produced the change, so it evaluates the result on its own terms.”

这是对抗性验证的标准模式：让一个干净的 context 独立判断结果好坏。

Claude Code 的子代理体系（最完整）：

claude agents：内置多代理视图，监控并行后台会话
Agent teams（/agent-teams）：多 session 自动协调 + 共享任务列表
Code intelligence plugin：给 typed language 提供精确符号导航和自动错误检测
子代理配置在 .claude/agents/*.md，frontmatter 指定 tools 和 model

Codex 的子代理：

codex agents 视图
/fork 和 /side：在历史消息节点分叉/并行会话
Codex 关键差异：“Codex only spawns subagents when you explicitly ask it to” —— 不像 Claude Code 那样按需自动派生，token 消耗更可控
子代理配置在 config.toml 的 [agents] 段

Copilot CLI 的子代理：

/fleet：把大任务分解为并行子任务由子代理执行
/delegate：把整个工作转移到 GitHub 云端 Copilot，云端代理会创建 PR
/task、/review：显式触发子代理（/review 有 4 种预设：base branch / uncommitted / commit / custom）
内置子代理（/review、/task、explore、/fleet）自动继承 provider 配置

Writer/Reviewer 模式（Claude Code 强调）：用全新上下文的 Reviewer 子代理审 Writer 子代理的产出，避免自评偏差。

5.6 测试是 Agent 时代的”免费午餐”

Simon Willison 原话：“Good automated tests which the coding agent can run … pytest … 1500 tests … Claude Code is great at selectively running just the relevant tests for a change, and running the full suite at the end.”

关键技巧：“detailed error messages! If a manual or automated test fails the more information you can return back to the model the better” —— 把 assertion 写详细，让 Agent 能”自己读错误自己修”。

差的 assertion：

assert user.is_authenticated()

好的 assertion（Agent 能直接定位问题）：

assert user.is_authenticated(), f"Expected authenticated user, got state={user.state}, session_age={user.session_age}s, token={user.token[:8]}..."

Copilot CLI 的 Plan 流程标准最后一步就是 “Run the tests and fix any failures”——把”跑测试”嵌进标准工作流。

5.7 给 Agent 一个工具齐全的开发环境

Simon Willison 的 HN 回复清单（值得全文照搬）：

好测试（pytest + 详细 assertion message）
开发服务器启动说明（让 Agent 用 Playwright / curl 交互式验证 UI 改动）
Lint + type check + formatter（Agent 会自己用）
GitHub issues 列表（把 issue URL 直接贴进 prompt，“having great results”）

反直觉点：“I have extensive documentation in all of my projects, but I don’t think it’s particularly useful for coding agents. LLMs can read the code a lot faster than you to figure out how to use it.”

文档对 Agent 没用，Agent 读代码比人快；文档的作用反而是”让 Agent 检查文档是否需要更新”。

5.8 5 条必避反模式

反模式	描述	修复
The kitchen sink session	一个会话混入不相关任务	任务间用 `/clear`
Correcting over and over	同一问题多次纠正	2 次失败就 `/clear` 改 prompt
The over-specified CLAUDE.md	规则太多淹没有效指令	严格剪枝（200 行内），复杂规则改 hook
The infinite exploration	”调查”无边界，Agent 读数百文件	缩小范围或用 subagent
The trust-then-verify gap	实现看起来合理但缺边缘场景	始终要求提供验证（测试 / 脚本 / 截图）

6. 参考

Claude Code: https://code.claude.com/docs/en/best-practices
Codex CLI: https://developers.openai.com/codex/cli/features + https://developers.openai.com/codex/cli/reference
Copilot CLI: https://docs.github.com/en/copilot/how-tos/copilot-cli/cli-best-practices
Simon Willison “Setting up a codebase for working with coding agents”（2025-10-25）: https://simonwillison.net/2025/Oct/25/coding-agent-tips/

VSCode + SSH + Docker 完整配置流程

Fri, 24 Apr 2026 16:00:00 GMT

以下是一份完整的、可复用的配置流程，从一台全新的 Linux 机器到 VSCode 免密管理 Docker，按顺序执行即可。

1. Linux 端准备

1.1 开启 SSH 服务

Kali Linux：

# 启动 SSH
sudo /etc/init.d/ssh start

# 开机自启
sudo systemctl enable ssh.service

Ubuntu/Debian：

# 安装并启动
sudo apt-get update
sudo apt-get install -y openssh-server
sudo service ssh start

1.2 查看 IP 地址

ip a

记下 inet 后面的局域网 IP（如 192.168.17.129）。

2. Windows 端准备

2.1 安装 VSCode 插件

打开 VSCode，安装以下扩展：

Remote - SSH
Docker

2.2 生成 SSH 密钥对

打开 PowerShell，执行：

ssh-keygen -t ed25519

保存路径：直接回车（默认 C:\Users\你的用户名\.ssh\id_ed25519）
密码：直接回车（不设密码，实现完全免密）

生成后确认文件存在：

ls $env:USERPROFILE\.ssh\

应看到：

id_ed25519 —— 私钥（留在 Windows）
id_ed25519.pub —— 公钥（放到 Linux）

3. 配置免密登录（公私钥）

3.1 将公钥上传到 Linux

方法一：命令自动上传（推荐） 在 Windows PowerShell 执行（替换 IP 和用户名）：

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh kali@192.168.17.129 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys && chmod 700 ~/.ssh"

输入一次密码后，公钥即上传完成。

方法二：手动复制

用记事本打开 C:\Users\你的用户名\.ssh\id_ed25519.pub，复制全部内容
在 VSCode 连上的 Linux 终端中：
```
nano ~/.ssh/authorized_keys
```
粘贴 → Ctrl+O 回车保存 → Ctrl+X 退出

设置权限：

chmod 600 ~/.ssh/authorized_keys
chmod 700 ~/.ssh

3.2 配置 VSCode SSH 使用私钥

按 Ctrl+Shift+P → Remote-SSH: Open SSH Configuration File → 选择第一个。

添加或修改配置：

Host kali
    HostName 192.168.17.129
    User kali
    IdentityFile C:\Users\你的用户名\.ssh\id_ed25519

注意：IdentityFile 指向的是私钥（id_ed25519），不是 .pub。

3.3 修复 Windows 私钥权限（关键！）

在 PowerShell 执行：

cd $env:USERPROFILE\.ssh

# 移除继承权限，仅保留当前用户读取
icacls id_ed25519 /inheritance:r
icacls id_ed25519 /grant:r "$($env:USERNAME):(R)"

3.4 测试免密连接

在 PowerShell 测试：

ssh -i $env:USERPROFILE\.ssh\id_ed25519 kali@192.168.17.129

如果直接连上，说明配置成功。

然后在 VSCode 中：

点击左下角绿色 >< 图标
选择 Connect to Host... → kali
应直接连上，不再提示密码

4. Linux 端安装 Docker

4.1 安装 Docker

推荐方式（Ubuntu/Debian）：

wget -qO- https://get.docker.com/ | sh

Kali Linux（Docker 官方不支持 Kali，需手动）：

sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 添加 GPG key
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# 使用 Debian 源（Kali 基于 Debian）
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian buster stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 安装
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

4.2 验证安装

sudo docker run hello-world

看到 Hello from Docker! 即成功。

5. 解决 Docker 权限问题

VSCode 连上后，Docker 插件可能提示无法访问 /var/run/docker.sock。

一劳永逸的解法：

在 Linux 终端执行：

# 将当前用户加入 docker 组
sudo usermod -aG docker $USER

# 重启 Docker 服务
sudo systemctl restart docker

然后断开 VSCode SSH 连接，重新连接（或重启 Linux）。

验证：

docker ps

不再提示权限错误即成功。

6. VSCode Docker 插件使用

连接成功后，左侧边栏出现 Docker 图标，常用功能：

功能	操作
拉取镜像	Images → 右键 `Pull` 或终端执行 `docker pull`
运行容器	镜像右键 → `Run`（后台）/ `Run Interactive`（带日志）
进入容器终端	容器右键 → `Attach Shell`
查看日志	容器右键 → `View Logs`
编辑容器文件	展开容器 `Files` 树，直接双击修改
端口转发	容器右键 → `Forward Port`，自动映射到 Windows 本地
浏览器打开	端口转发后，右键 `Open in Browser`

7. 快速检查清单

每次复用或排查问题时，按以下顺序检查：

检查项	命令/操作
Linux SSH 是否运行	`sudo service ssh status`
Windows 私钥权限	`icacls C:\Users\用户名\.ssh\id_ed25519`（应只有当前用户）
Linux 公钥是否正确	`cat ~/.ssh/authorized_keys`
Linux .ssh 权限	`ls -la ~/.ssh`（700 + 600）
用户是否在 docker 组	`groups`（应看到 `docker`）
VSCode 配置路径	`IdentityFile` 指向私钥，不是 `.pub`

8. 配置文件模板

Windows SSH 配置（C:\Users\用户名\.ssh\config）：

Host kali
    HostName 192.168.17.129
    User kali
    IdentityFile C:\Users\你的用户名\.ssh\id_ed25519
    ForwardAgent yes

Linux SSH 配置（/etc/ssh/sshd_config，可选加固）：

PubkeyAuthentication yes
PasswordAuthentication no    # 确认密钥可用后再开启，禁用密码登录

修改后重启 SSH：

sudo service ssh restart

按这个流程走，任何新的 Kali/Ubuntu/Debian 机器都可以在 5 分钟内配置好完整的远程 Docker 开发环境。

Word 排版技巧

Tue, 21 Apr 2026 16:00:00 GMT

本文整理 Word 排版中的实用技巧，包括图片题注、交叉引用、三线表制作等。

1. 图片排版

1.1 粘贴图片显示不全

问题：粘贴图片后只显示一行，图片无法完整显示。

图片显示问题

解决方法：

选中图片所在段落
右键 → 段落
将行间距改为单倍行距或固定值（如 20 磅）

1.2 添加题注

给图片添加题注，方便引用和管理。

添加题注

操作步骤：

右键图片 → 插入题注
点击新建标签，输入”图”
位置选择”所选项目下方”

设置编号格式：

编号设置

点击编号按钮
勾选”包含章节号”
选择章节样式（如”标题 1”）
选择分隔符（如”-“或”.“）

1.3 交叉引用

使用交叉引用，可以在图片增删后自动更新编号。

交叉引用

操作步骤：

光标定位到引用位置
引用 → 交叉引用
引用类型选择”图”
选择要引用的题注

1.4 修改题注样式

修改题注的字体、字号、对齐方式。

修改样式

样式设置

操作步骤：

开始 → 样式右下角展开
找到”题注”样式，右键 → 修改
设置字体（如宋体、五号）
设置对齐方式（如居中）

段落居中设置：

居中设置

右键题注 → 段落
对齐方式选择”居中”

1.5 批量更新编号

当图片增删后，需要批量更新所有编号。

更新编号

操作步骤：

Ctrl + A 全选文档
F9 更新域
所有题注编号自动更新

2. 三线表制作

学术论文中常用的三线表样式。

2.1 新建表格样式

表格样式

操作步骤：

表格设计 → 新建表格样式
设置样式名称（如”三线表”）

样式设置

设置边框：
- 顶线：1.5 磅，黑色
- 中间线：0.5 磅，黑色
- 底线：1.5 磅，黑色

边框设置

应用范围选择”整张表格”
点击确定保存

2.2 应用样式

选中表格
表格设计 → 找到自定义的”三线表”样式
点击应用

3. PDF 编辑

如果需要编辑 PDF 文件，可以使用 Adobe Acrobat。

Acrobat

常用功能：

PDF 转 Word
合并/拆分 PDF
添加水印
表单填写

4. 总结

技巧速查表

技巧	操作
图片显示不全	段落 → 行间距改为单倍行距
添加题注	右键 → 插入题注 → 新建标签
自动编号	插入题注时勾选”包含章节号”
交叉引用	引用 → 交叉引用 → 选择题注
批量更新	Ctrl+A → F9
三线表	新建表格样式 → 设置顶线/底线 1.5 磅
PDF 编辑	使用 Adobe Acrobat

注意事项

题注样式修改后，所有题注会自动更新
交叉引用需要手动更新（F9）
三线表的中间线通常比顶底线细
建议在排版前先设置好样式，避免后期大量修改

Cloudflare 边缘应用：一个 IP 承载数千网站

Thu, 09 Apr 2026 16:00:00 GMT

参考讨论：XTLS/BBS#23

Cloudflare 一个 IP（如 104.16.x.x）能同时承载数千甚至上万个网站，背后是 CDN 的几项核心技术叠加：反向代理 + SNI/Host 路由、Anycast、边缘计算。

1. 反向代理（Reverse Proxy）+ SNI 路由

用户访问 site1.com ──┐
用户访问 site2.com ──┼──→ Cloudflare IP (104.16.x.x) ──→ 根据信息分发到不同源站
用户访问 site3.com ──┘

关键技术：SNI + Host 头双重路由。

第一步：TLS 握手（SNI 决定证书）

你的浏览器 → Cloudflare:443

Client Hello:
  - SNI: "site1.com"  ← 明文传输

Cloudflare 根据 SNI：
  - 找到 site1.com 的证书
  - 返回 site1.com 的 TLS 证书

第二步：HTTP 请求（Host 头决定源站）

HTTP GET / HTTP/1.1
Host: site1.com  ← 决定请求转发给哪个源服务器

结果： 同一个 IP，根据 SNI 和 Host 头的不同，可以服务无限个域名。

2. Anycast 技术（全球共享 IP）

这是 Cloudflare 的独特之处：

传统 DNS：
- site.com → 1.2.3.4（美国服务器）
- 中国用户访问慢

Cloudflare Anycast：
- 104.16.249.249 同时在全球广播：
  - 北京用户访问 → 被路由到北京机房
  - 纽约用户访问 → 被路由到纽约机房
  - 伦敦用户访问 → 被路由到伦敦机房

同一个 IP 地址，物理上对应全球数百个数据中心。

3. 边缘计算（Edge Computing）

对于 Workers/Pages：

用户请求 example.worker.dev
           ↓
到达最近的 Cloudflare 边缘节点
           ↓
不转发到源站，直接在边缘节点执行 JavaScript 代码
           ↓
返回结果

一个 IP 既是反向代理入口，又是代码执行环境。

4. 边缘应用为什么几乎不占资源

边缘应用（Worker）是 Serverless 无服务器架构，特点是：

不是一直开着一台服务器等请求
来一个请求，临时启动一段代码
执行完（通常几毫秒～几十毫秒）直接销毁
不请求时，完全不占资源

一个节点上可以同时跑几万个用户的边缘函数，资源是极度共享、极度轻量化的。对 Cloudflare 来说，这点算力几乎可以忽略不计。

5. 写 API、鉴权、查数据库会不会很耗资源？

并不会，而且架构是这样的：

边缘节点：只做轻逻辑（校验、路由、拼接、简单计算）
数据库：依然放在中心服务器 / 云数据库（比如阿里云、腾讯云、PlanetScale）
边缘节点 → 发请求 → 中心数据库拿数据

不是每个边缘节点都装数据库。只是用户到边缘近，边缘到数据库那一步是厂商优化过的内网专线，整体依然很快。

6. 对比传统后端

传统后端：买 1 台 / 3 台 / 10 台服务器，自己扛所有流量，崩了要自己重启扩容
边缘后端：厂商全球几百个节点自动兜底，流量再大也自动分配，不用管服务器数量

VMware Workstation 下载指南

Tue, 07 Apr 2026 16:00:00 GMT

背景

VMware 于 2023 年 11 月被 Broadcom 收购。2024 年 5 月起，VMware Workstation Pro 个人使用免费（商业用途仍需付费）。原 VMware Workstation Player 已合并进 Pro 版本。

下载步骤

访问 Broadcom 支持门户，注册并登录账号
进入产品页面，找到 VMware Workstation Pro
选择版本（当前最新为 17.6.x）和操作系统（Windows / Linux）
下载安装包

参考：Broadcom 官方说明

安装

运行下载的安装程序，按向导完成安装即可。建议使用默认安装路径，安装过程中勾选”增强型键盘驱动”以获得更好的输入体验。

配置中文界面

安装完成后如需切换为中文界面：

打开 VMware Workstation
菜单栏 → Edit → Preferences → Language
选择 简体中文，重启软件生效

详细图文教程参考：VMware 中文语言配置

注意事项

务必从 Broadcom 官网下载，避免第三方来源的恶意软件
仅限个人非商业用途免费，商业环境需购买许可

校园网 IP 切换原理

Wed, 01 Apr 2026 16:00:00 GMT

很多人会注意到一个现象：在校园网里隔一段时间查一下自己的公网 IP，会发现它在悄悄变化，但自己刷网页、登微信、打游戏却完全没有感知。这篇笔记拆解这背后的原理：NAT 出口为什么频繁换 IP，以及为什么用户感觉不到。

1. 校园网为什么用 NAT

校园网通常只有一个或少数几个公网 IP，但网内可能有成千上万台设备（手机、电脑、平板）。要把这么多设备接上互联网，靠的是 NAT（网络地址转换）：

每台设备拿到的是一个内网 IP（如 10.x.x.x、172.16.x.x、192.168.x.x），这些地址在公网上无法路由。
设备访问外网时，出口的 NAT 设备（路由器/网关）把源地址从内网 IP 改写成公网 IP，并记录一条”内网 IP+端口 ↔ 公网 IP+端口”的映射。
对端回包时，NAT 再根据映射表把目的地址翻译回内网 IP，送到对应设备。

也就是说，所有设备的流量对外都”伪装”成从那几个公网 IP 发出，对外呈现的公网 IP 是 NAT 出口决定的，而不是你的设备决定的。

2. 为什么校园网的公网 IP 会频繁切换

公网 IP 的频繁变化，通常由这几个机制叠加造成：

DHCP 短租约：出口公网 IP 本身可能也是向运营商 DHCP 租来的，租约一过期就可能续到另一个 IP。
多出口负载均衡：大型校园网往往接了多条运营商线路（电信、联通、教育网等），网关根据负载把流量分到不同出口，于是你看到的公网 IP 在不同出口之间跳。
故障/拥塞切换：某条出口线路抖动或拥塞时，网关会自动把流量切到健康线路，公网 IP 跟着变。

所以”公网 IP 变了”在校园网里是常态，而非异常。

3. 为什么已建立的连接不受影响

关键在于：NAT 设备对已经打开的应用、已经建立的 TCP 连接（比如正在刷的网页、登着的微信、打着的游戏），会保留这个会话的映射关系：

哪怕公网 IP 变了，已经建立的连接不会断，应用完全不受影响，用着和平时一模一样。
只有当发起全新的连接（比如新开一个 SSH、重新登录某个服务、新开浏览器标签页），才会使用新的公网 IP。

4. 为什么应用本身不关心源 IP

现在的所有互联网应用（微信、浏览器、视频软件等），只需要「网络通」，完全不依赖固定的源公网 IP：

源 IP 变了，应用不会报错、不会掉线，用户察觉不到任何异常。
只有需要「源 IP 白名单」的服务（比如服务器的安全组、企业 VPN、特定后台系统），才会因为源 IP 变了而被拦截——这就是在校园网里 SSH 突然连不上服务器的一个常见根因。

5. 链路切换是毫秒级的

校园网的负载均衡、故障切换都是毫秒级完成的，几乎感觉不到断网，自然也不会意识到 IP 变了。

小结：校园网公网 IP 频繁变化是 NAT + 多出口的正常行为；已建立的连接靠 NAT 映射表维持不断；普通应用不依赖固定源 IP 所以无感；只有依赖源 IP 白名单的服务（典型如 SSH 白名单、VPN）才会被影响。

虚拟机网络配置

Fri, 06 Mar 2026 16:00:00 GMT

1. 为什么需要固定 IP？最稳妥的规划策略

VMware NAT 默认通过 DHCP 分配 IP，地址会浮动，多台虚拟机同时开机还可能撞 IP，导致 SSH 频繁断连。最彻底的解决办法是：设置静态 IP，并故意选在 DHCP 分配池之外。

以常见的 NAT 网段 192.168.17.0/24 为例，VMware 的 DHCP 通常分配 128-254 这个区间。因此安全可用的静态 IP 范围为 192.168.17.3 ~ 192.168.17.127。

规划示例：

宿主机：192.168.17.1（系统固定）
NAT 网关：192.168.17.2（系统固定）
虚拟机 A：192.168.17.10
虚拟机 B：192.168.17.11
……

这样无论 DHCP 怎么分配，都不会跟你手动的地址冲突。

本文示例均以目标 IP 192.168.17.10、网卡名 ens160 为例。请务必将命令中的 IP 和网卡名替换为你实际规划的值。 不确定网卡名？执行 ip addr 或 nmcli connection show 查看，常见名有 ens33、eth0 等。

2. 前置检查：确保虚拟链路与 VMware 服务正常

很多“配置完不通”的问题，根源不在 Linux 配置，而在虚拟机硬件或 Windows 服务。正式配 IP 之前，先过一遍下面几点。

1. 虚拟机网卡硬件设置（所有方案通用）

关闭虚拟机（不是暂停），打开「虚拟机设置」→「网络适配器」。
必须勾选 ✅「已连接」、✅「启动时连接」。
确认网络连接方式为 「NAT 模式」。

2. 检查宿主机 VMware 核心服务

在 Windows 中 Win+R 输入 services.msc，找到下面两个服务：

VMware NAT Service
VMware DHCP Service

确保它们都是「正在运行」状态。如有异常，右键重新启动。
如果之前修改过虚拟网络编辑器（如恢复了默认设置），可能需要重启这两个服务甚至宿主机。

3. 启动虚拟机，快速确认网卡链路

ip addr show ens160   # 记得替换网卡名

如果输出中包含 state UP，说明链路已通，可以进入下一步。
如果始终是 state DOWN，回第一步重新确认 VMware 设置与服务。

3. 方案 A：NetworkManager 正常时的推荐做法（nmcli 一键搞定）

大多数现代 Linux 发行版（CentOS 7+、Fedora、Ubuntu 等）默认使用 NetworkManager 管理网络。这种情况下 nmcli 是最安全、最不容易产生配置冲突的方式。

直接把下面命令里的 192.168.17.10 和 ens160 替换成你的实际值，整个复制执行即可：

CONN="ens160"  # 先确认网卡名

# 1. 绑定静态 IP 和子网掩码
sudo nmcli connection modify "$CONN" ipv4.addresses 192.168.17.10/24

# 2. 设置网关
sudo nmcli connection modify "$CONN" ipv4.gateway 192.168.17.2

# 3. 设置 DNS（推荐公共 DNS）
sudo nmcli connection modify "$CONN" ipv4.dns "8.8.8.8,114.114.114.114"

# 4. 改获取方式为手动
sudo nmcli connection modify "$CONN" ipv4.method manual

# 5. 可选：禁用 IPv6，避免其干扰连通性测试
sudo nmcli connection modify "$CONN" ipv6.method disabled

# 6. 重启网卡
sudo nmcli connection down "$CONN" && sudo nmcli connection up "$CONN"

执行后验证：

ip addr show ens160 | grep 192.168.17.10   # 确认 IP 已绑定
ping -c 3 baidu.com                        # 确认外网域名解析正常

此后即便重启虚拟机，IP 也不会变，MobaXterm 之类的工具直接用 192.168.17.10 连接即可。

4. 方案 B：当 NetworkManager 罢工时（未托管、device not found）

有时候系统会出现以下症状：

nmcli device status 显示 ens160 为 unmanaged；
尝试 nmcli connection up 提示 No suitable device found；
修改 /etc/NetworkManager/... 的托管配置无效；
甚至 VMware 中「已连接」都勾不上，网卡始终 DOWN。

这就是典型的 NetworkManager 未托管 + 虚拟链路异常，二合一故障。此时最直接的办法是跳过 NetworkManager，用传统 network.service 接管。

⚠️ 兼容性警告
方案 B 依赖传统 network-scripts 包，在 CentOS 7.x 上适用。

如果你的系统是最小化安装，可能未包含此包，需先执行 sudo yum install network-scripts。

如果你使用的是 RHEL 9 / Rocky Linux 9 / CentOS Stream 9 及更新版本，该包已被官方移除，方案 B 不可用。请返回方案 A 排查 NM 的配置问题。

4.1 确保链路恢复（若仍 DOWN）

如果第一节的前置检查已通过，网卡已是 UP 状态可略过。否则先在虚拟机设置中确认「已连接」已勾，并重启 VMware NAT/DHCP 服务，直至 ip addr show 看到 state UP。

4.2 停用 NetworkManager，手动固定 IP

# 1. 彻底停用 NetworkManager
sudo systemctl stop NetworkManager
sudo systemctl disable NetworkManager

# 2. 临时配通 IP（立即生效）
sudo ip addr add 192.168.17.10/24 dev ens160
sudo ip link set ens160 up
sudo ip route add default via 192.168.17.2 dev ens160
echo -e "nameserver 8.8.8.8\nnameserver 114.114.114.114" | sudo tee /etc/resolv.conf

# 3. 排除 IPv6 干扰：若 ping 外网失败，先临时禁用 IPv6 再测
sudo sysctl -w net.ipv6.conf.ens160.disable_ipv6=1

现在测试 ping 192.168.17.2 和 ping baidu.com，应该都能通。

4.3 让配置永久生效（重启后 IP 依旧）

停止 NetworkManager 后，系统会转而使用传统 network 服务读取 /etc/sysconfig/network-scripts/ifcfg-* 文件。我们直接写入正确配置：

sudo tee /etc/sysconfig/network-scripts/ifcfg-ens160 <<'EOF'
TYPE=Ethernet
BOOTPROTO=static
NAME=ens160
DEVICE=ens160
ONBOOT=yes
IPADDR=192.168.17.10
PREFIX=24
GATEWAY=192.168.17.2
DNS1=8.8.8.8
DNS2=114.114.114.114
IPV6INIT=no
PEERDNS=no
EOF

关于 PEERDNS=no 的说明
加上此参数后，网络服务启动时不会自动修改 /etc/resolv.conf，DNS 将严格使用此文件中定义的 DNS1 和 DNS2。这能确保你手动设定的 DNS 不被其他服务覆盖。

然后启用并启动传统网络服务：

sudo systemctl enable network
sudo systemctl restart network

最后，如果之前禁用了 IPv6，可将其设为永久生效：

sudo sysctl -w net.ipv6.conf.ens160.disable_ipv6=1 | sudo tee -a /etc/sysctl.conf

至此，无论是否重启，虚拟机都会固定使用 192.168.17.10，且不会再被 NetworkManager 干扰。

5. 快速验证清单

无论用哪个方案，最后都跑一遍：

ip addr show ens160          # 看到 192.168.17.10/24
ping 192.168.17.2 -c 2       # 网关通
ping www.baidu.com -c 4      # 外网域名解析通

全通则成功。然后就可以打开 MobaXterm，新建 SSH Session，Host 填入 192.168.17.10，享受稳定的连接。

6. 故障速查表

现象	可能原因	快速处置
网卡始终 `DOWN`	虚拟机设置中未勾选「已连接」或 VMware 服务未运行	重启 VMware NAT/DHCP 服务，确认勾选已打
`nmcli` 报 `unmanaged`	NetworkManager 配置禁止管理该网卡	若系统版本支持，直接用方案 B；否则排查 NM 配置文件
`ping` 网关通但域名解析失败	DNS 配置错误或被覆盖	确认 `/etc/resolv.conf` 内容；使用方案 B 时检查 `ifcfg` 中 `PEERDNS` 设置
`ping` IP 通但域名不通	IPv6 路由异常，请求优先走了无响应的 IPv6	尝试 `ping -4 baidu.com` 确认，然后禁用 IPv6
重启后 IP 丢失	配置未持久化或 NM 重新接管	检查 `/etc/sysconfig/network-scripts/ifcfg-ens160` 是否存在且内容正确；若用方案 A，确保 `ipv4.method` 为 `manual`
多虚拟机互相抢 IP	静态 IP 落在了 DHCP 池内	将静态 IP 调整至 DHCP 池外（如 `3~127`）；除非所有虚拟机均已手工配置静态 IP，否则不要关闭 VMware DHCP 服务

让手机连上热点直接使用主机的 Clash

Fri, 06 Mar 2026 16:00:00 GMT

Windows 上实现透明网关/全局路由的方案，核心思路是：让 Windows 热点的上游不是物理网卡，而是 Clash 的 TUN 虚拟网卡。这样手机连上热点后无需任何代理设置，所有流量强制经过 TUN。

原理

Windows 自带热点的默认逻辑是：热点网卡 → 物理网卡（WiFi/以太网）→ 互联网。
我们要改成：热点网卡 → Clash TUN 虚拟网卡 → 互联网。

⚠️ 已知限制：Clash Verge Rev 的 TUN 与 Windows ICS（网络共享）存在兼容性冲突，部分版本下同时开启会导致本机和热点设备都无法上网。以下方案在 Clash Verge Rev 2.5.1 上可行。

操作步骤

1. 先开启 Clash Verge 的 TUN 模式

打开 Clash Verge → 设置 → 开启 TUN 模式
确保已安装服务模式（Service Mode），TUN 网卡正常创建（设备管理器中能看到如 Meta Tunnel 或 Clash 字样的虚拟网卡）
确认电脑本机可以正常翻墙

2. 再开启 Windows 移动热点

设置 → 网络和 Internet → 移动热点 → 开启
记住热点名称和密码，此时先不要连接手机

3. 关键：在 TUN 网卡上配置 ICS 共享

按 Win + R，输入 ncpa.cpl 回车，打开网络连接面板：

找到 Clash 的 TUN 虚拟网卡（名称通常包含 Meta Tunnel、Clash、mihomo 或 Wintun）
右键 → 属性 → 切换到共享选项卡
勾选 “允许其他网络用户通过此计算机的 Internet 连接来连接”
在 “家庭网络连接” 下拉框中，选择刚才开启热点生成的网卡（通常叫 本地连接*、Microsoft Wi-Fi Direct Virtual Adapter 或 Local Area Connection）
确定保存

顺序很重要：必须是 先开 TUN → 再开热点 → 最后设置共享。如果反过来，Windows 的 ICS 会与 TUN 冲突。

4. 手机连接热点

手机直接连接电脑热点，不需要设置任何代理（不要填 IP 和端口）
打开浏览器测试，所有流量应已被 TUN 透明接管

Trap、中断与系统调用详解

Sun, 22 Feb 2026 16:00:00 GMT

陷入 (Trap)

陷入是由程序主动执行特定指令（如系统调用指令 int 0x80 或 syscall）触发的同步事件。它让 CPU 从用户态切换到内核态，执行内核代码。

特点：同步（由程序主动发起）、软件驱动。
目的：实现用户程序向操作系统请求服务（如读写文件、创建进程）。

特权指令 (Privileged Instruction)

特权指令是只能在内核态（最高权限）下执行的指令，如修改页表基址寄存器、开关中断等。如果在用户态执行这些指令，CPU 会触发一个保护异常（属于中断的一种），阻止操作。

特点：权限限制。
目的：保护系统资源不被用户程序随意修改，保证系统安全。

区别总结

维度	中断	陷入	特权指令
本质	事件（Event）	事件（Event）	指令（Instruction）
触发源	硬件/异常	软件（程序）	程序（试图执行）
同步性	异步	同步	同步
作用	响应外部变化	请求系统服务	管理硬件资源

关系与交互

当用户程序需要执行特权操作（如读写磁盘）时，它不能直接执行特权指令，而是通过陷入（系统调用）进入内核，由内核代为执行。
如果用户程序非法执行特权指令，会触发一个中断（保护异常），导致程序被终止。

触发陷入（进入内核）只需要执行一条特定的指令（如 `int 0x80`, `syscall`）。但，这条指令只是一个“门铃”，按下门铃后，执行的是操作系统内核中预先写好的、功能完整且复杂的服务例程

这是一个经典的交互流程，以“写文件”这个系统调用为例：

// 用户程序
int main() {
    write(fd, buffer, size); // 1. 调用库函数
    // ...
}

发生的步骤：

库函数包装：write 是 C 库函数，它的核心工作是：
- 将系统调用号（标识是write）、参数（fd, buffer, size）放到约定好的寄存器或栈中。
- 执行一条 trap 指令（如 syscall）。
- 这条指令是用户态最后一条指令。
陷入与切换：CPU 执行 syscall 指令，硬件自动完成：
- 切换到内核态。
- 保存用户程序现场（寄存器、程序计数器等）。
- 跳转到操作系统内核预先设定好的统一入口（系统调用处理程序）。
内核执行复杂逻辑：现在完全在内核态运行，操作系统开始工作：
- 分发：根据放在寄存器里的系统调用号，查表找到对应的服务函数，比如 sys_write。
- 执行核心服务：sys_write 是操作系统内核里一个复杂的函数，它可能要做：
  - 参数检查（缓冲区是否有效？文件描述符是否合法？）。
  - 从用户态缓冲区拷贝数据到内核（因为内核不能直接操作用户内存）。
  - 文件系统操作：找到文件的 inode，检查权限。
  - 驱动交互：调用硬盘驱动程序，将数据写入缓存或直接写入磁盘。
  - 进程调度：如果需要等待 IO，可能会挂起当前进程，切换到其他进程运行。
- 所有这些，都是在内核态执行的特权代码，功能可以非常复杂。
返回结果：内核函数执行完毕后：
- 将返回值（成功写入的字节数或错误码）放入约定寄存器。
- 执行一条特殊的返回指令（如 sysret 或 iret）。
- CPU 硬件恢复用户态现场，跳回用户程序 syscall 指令之后继续执行。

所以，核心思想是： trap 指令只是一把钥匙，打开了通往内核的大门。门后是一个由操作系统构建的、拥有完整功能和最高权限的“新世界”。用户程序通过“钥匙”请求这个世界里的“居民”（内核函数）来为自己完成复杂的特权工作。

计算机组成原理笔记

Thu, 19 Feb 2026 16:00:00 GMT

1. 计算机系统概述

1.1 冯·诺依曼架构特点

冯诺依曼架构

核心思想：存储程序，即将程序和数据存储在存储器中，CPU 按地址依次取出并执行。

主要特点：

五大部件：运算器、控制器、存储器、输入设备、输出设备
以存储器为中心：早期冯·诺依曼机以运算器为中心，现代计算机以存储器为中心
指令和数据均用二进制表示
指令和数据存储在同一存储器中（区别于哈佛架构）

1.2 软件与硬件的逻辑等价性

计算机软件分类

三个级别的语言：

语言类型	特点	翻译工具
高级语言	接近自然语言，如 C、Python	编译程序（编译器）
汇编语言	用助记符表示指令	汇编程序（汇编器）
机器语言	二进制代码，CPU 直接执行	无需翻译

编译程序：将高级语言一次性全部翻译成汇编语言或机器语言
解释程序：将高级语言翻译成机器语言（翻译一句执行一句）
ISA（指令集体系结构）：定义一台计算机可以支持的指令，以及每条指令的作用

2. 数据表示与运算

2.1 原码、反码、补码

定点整数的编码方式：

编码方式	正数	负数	特点
原码	符号位 0 + 真值绝对值	符号位 1 + 真值绝对值	有+0 和-0
反码	与原码相同	符号位不变，数值位取反	有+0 和-0
补码	与原码相同	反码+1	只有一个 0，范围更大

补码的优势：

消除正负零：原码和反码中+0 和-0 表示不同，补码中只有一个 0
加减法统一：减法可以转化为加法运算
表示范围扩大：8 位补码可表示 -128 ~ +127

符号扩展：

正数扩展：高位补 0
负数扩展：高位补 1

2.2 溢出判断

溢出检测方法：

单符号位法：操作数符号相同，结果符号相反则溢出
双符号位法：结果的两个符号位不同则溢出

3. CPU 组成与功能

各硬件部件

3.1 运算器

部件	全称	功能
ACC	累加计数器	存放操作数、运算结果
MQ	乘商寄存器	乘法运算时存放乘数，除法时存放商
X	通用寄存器	存放操作数
ALU	算术逻辑单元	实现各种算术运算、逻辑运算

3.2 控制器

部件	全称	功能
PC	程序计数器	存放下一条指令的地址
IR	指令寄存器	存放当前正在执行的指令
CU	控制单元	分析指令，给出控制信号

重要说明：

PC 自动指向下一条指令的地址（取指后 PC+1）
IR 保存当前正在执行的指令
CU 是控制器的核心，负责分析指令并产生控制信号

4. 主存储器

主存储器基本组成

4.1 基本组成

存储体：数据在存储体内按地址存储

关键寄存器：

MAR（主存地址寄存器）：用于存放要访问的存储单元的地址，位数反映存储单元的个数
MDR（主存数据寄存器）：用于暂存从存储体读出或写入的数据，位数 = 存储字长

基本概念：

概念	定义
存储单元	每个存储单元存放一串二进制代码
存储字	存储单元中二进制代码的组合
存储字长	存储单元中二进制代码的位数
存储元	存储二进制的电子元件，每个存储元可存 1bit

示例：

MAR = 4 位 → 共有 2^4 = 16 个存储单元
MDR = 16 位 → 每个存储单元可存放 16bit
1 个字（word）= 16bit
1 字节（Byte）= 8bit，1B = 1Byte，1b = 1bit

5. 指令系统

5.1 指令格式

指令由操作码和地址码组成：

字段	内容
操作码（OP）	指明指令的操作类型（如加法、传送）
地址码（Ad）	指明操作数的地址或下一条指令的地址

地址码的结构：

| 操作码 | 地址码1 | 地址码2 | 地址码3 | 地址码4 |

5.2 寻址方式

寻址方式	说明	优点	缺点
立即寻址	地址码即为操作数	速度快	地址码位数限制操作数范围
直接寻址	地址码给出操作数的内存地址	简单	地址码位数限制寻址范围
间接寻址	地址码给出的内存地址中存放的是操作数的地址	寻址范围大	访存次数多，速度慢
寄存器寻址	地址码给出寄存器编号	速度快	寄存器数量有限
寄存器间接寻址	地址码给出的寄存器中存放的是操作数的地址	寻址范围大	需要访存

6. CPU 工作过程

6.1 指令执行流程

CPU工作过程

指令执行的基本步骤：

取指周期：
- (PC) → MAR：将程序计数器的内容送到主存地址寄存器
- M(MAR) → MDR：从存储体读取指令到主存数据寄存器
- (MDR) → IR：将指令送到指令寄存器
- OP(IR) → CU：将操作码送到控制单元分析
执行周期（以取数指令为例）：
- Ad(IR) → MAR：将地址码送到主存地址寄存器
- M(MAR) → MDR：从存储体读取数据
- (MDR) → ACC：将数据送到累加器

6.2 取数指令详解

取数指令执行

“取数”指令的执行（从主存指定地址处取数）：

取指周期（必经步骤）：
    (PC) → MAR
    M(MAR) → MDR
    (MDR) → IR
    (PC) + 1 → PC
    OP(IR) → CU

执行周期（不同指令具体步骤不同）：
    Ad(IR) → MAR
    M(MAR) → MDR
    (MDR) → ACC

取指周期：所有指令都必须经历的阶段
执行周期：根据指令类型不同，具体操作不同
PC+1：在取指周期结束时自动执行，指向下一条指令

6.3 乘法指令执行

乘法指令执行

乘法指令的执行过程：

取指周期：
    (PC) → MAR → MDR → IR → CU

执行周期：
    Ad(IR) → MAR → MDR → MQ    # 取乘数到MQ
    (ACC) × (MQ) → ACC          # 乘法运算
    结果存入主存单元

注意：乘法运算结果可能超出 ACC 的位数，需要 MQ 辅助存储。

6.4 指令周期

CPU 区分指令和数据的依据：指令周期的不同阶段

阶段	取出的内容	用途
取指周期	指令	送到 IR 分析
执行周期	数据	送到 ACC 或其他寄存器

指令周期的组成：

取指周期：从存储器取出指令
间址周期（可选）：如果指令使用间接寻址
执行周期：执行指令的操作
中断周期（可选）：处理中断请求

7. 总结

7.1 核心知识点

冯·诺依曼架构：存储程序，五大部件，以存储器为中心
CPU 组成：运算器（ACC、MQ、X、ALU）+ 控制器（PC、IR、CU）
存储系统：MAR（地址）、MDR（数据）、存储体
指令系统：操作码 + 地址码，多种寻址方式
指令周期：取指周期 → 执行周期，PC 自动+1

7.2 易错点

PC 存放下一条指令的地址，不是当前指令的地址
IR 保存当前正在执行的指令
MAR 的位数决定存储单元的个数
MDR 的位数等于存储字长
取指周期取出的是指令，执行周期取出的是数据

李宏毅机器学习笔记：线性模型与梯度下降

Sat, 27 Dec 2025 16:00:00 GMT

本文是李宏毅机器学习深度学习系列课程第一节课的笔记，从最简单的线性模型一路串到深度学习。

第一节课基本概念

1. 最简单的模型：线性模型

我们要预测的值记为 y，最简单的预测方式是假设它和某个特征 x 成线性关系：

y = b + w * x

b：偏置（bias）
w：权重（weight）
x：输入特征（下标 x_1 表示第一个特征）

2. Loss：衡量一组参数好不好

有了模型，还需要一个标准来评判当前的 w 和 b 好不好，这个标准就是 Loss（损失函数）。

label：正确的值（真实标签）。
计算误差的方式：把模型预测值和 label 做差，累加起来（例如 MAE：e = |ŷ - y|）。

计算误差的方式

Loss 越小，说明这组 w、b 越好。要找到最小的 Loss，就是找到最优的 w 和 b，方法是梯度下降（Gradient Descent）。

3. 梯度下降：怎么更新参数

梯度下降示意

参数更新过程

梯度下降的核心思路：算出 Loss 对每个参数的梯度（偏导），然后让参数沿着梯度的反方向走一小步，Loss 就会下降一点。反复迭代，直到 Loss 不再明显下降。上图展示的就是这个”更新参数”的过程。

4. 用更复杂的模型拟合真实数据

线性模型（一条直线）往往不足以描述真实数据。结合真实情况，需要改进模型，让它具备表达非线性关系的能力。

结合真实情况改进模型

这就引出了下面要讲的 linear model 的扩展。

5. Linear Model 的扩展：用蓝色折线拼出红色曲线

模型名仍叫 linear model，但思路变了：

线性模型扩展

蓝色折线拼红色曲线

核心想法是：用多段蓝色的折线（分段线性函数）组合起来，逼近任意形状的红色曲线。

蓝色折线逼近

这种蓝色折线段的数学名字叫 Hard Sigmoid——形状像一个拉长的 S。

6. Hard Sigmoid 与激活函数

Hard Sigmoid

Hard Sigmoid 可以用一个连续函数 Sigmoid 来近似：

Sigmoid 近似

于是每一小段蓝色曲线可以写成：

y = c / (1 + exp(-(b + w * x)))
    = c * sigmoid(b + w * x)

Sigmoid 公式

问：为什么这里 `c` 要转置？

公式里的 c（以及 b、w）在多个特征/多段曲线堆叠时会变成向量/矩阵，写成 c^T 是为了把行向量转置成列向量，方便和后面的未知向量做矩阵乘法、合并起来。

转置与合并

这一步是在合并未知向量：把多段曲线的参数统一写成一个矩阵运算 y = b + c^T * sigmoid(b + w * x)，形式更紧凑，也便于后续推广到多层网络。

7. 多段曲线堆叠：还是用梯度下降更新参数

把多个 Hard Sigmoid 加起来后，未知参数变多了（每段都有自己的 c、b、w），但更新方法不变——还是梯度下降，只是参数更多。

多段曲线更新参数

8. Batch 与 Epoch：分段处理数据

把一整份训练数据分成多段（batch）逐段计算并更新参数。相关的两个概念：

batch：一次取一小批样本算梯度、更新一次参数。
epoch：把所有训练样本都过一遍叫一个 epoch。

这个概念在 YOLO 等模型的训练里也会用到，是深度学习训练的通用约定。

Batch 与 Epoch

9. 两种激活函数

除了 Sigmoid，还有另一种常用的激活函数。课程里对比了两种：

两种激活函数

（Sigmoid 和 ReLU，后者在现代网络里更常用，因为计算简单、收敛快。）

10. 把结构叠多层：Neural Network → Deep Learning

上面这种”输入 → 一组激活函数 → 输出”的结构可以多次重复堆叠（layers）：

多层堆叠

单个这种计算单元叫 neuron（神经元）。
把很多 neuron 组织起来就叫 neural network（神经网络）。
当层数很多时，换了个名字：Many layers means Deep → Deep Learning（深度学习）。

小结

这节课从 y = b + w*x 出发，一步步展示了：怎么用 Loss 衡量模型好坏、怎么用梯度下降找最优参数、怎么用 Hard Sigmoid/Sigmoid 把线性模型扩展成能拟合复杂曲线的模型，最后通过堆叠 layers 自然引出了神经网络和深度学习。后续课程会在这个基础上讲网络结构、反向传播和具体任务。

二叉树基础笔记

Mon, 15 Dec 2025 16:00:00 GMT

本文整理二叉树的存储方式和线索二叉树的核心知识点。

1. 二叉树的存储

1.1 顺序存储

顺序存储使用数组存放完全二叉树，通过下标表示结点关系。

顺序存储

编号规则（从 1 开始）：

结点	公式
左孩子	`2i`
右孩子	`2i + 1`
父亲	`⌊i/2⌋`

特点：适合完全二叉树，空间利用率高；非完全二叉树会浪费空间。

1.2 链式存储（二叉链表）

链式存储使用指针连接结点，每个结点包含：

data：数据域
lchild：左孩子指针
rchild：右孩子指针

链式存储

重要规律：空指针个数 = 结点数 + 1

1.3 三叉链表

在二叉链表基础上增加 parent 指针，方便向上查找。

三叉链表

类型	指针	特点
二叉链表	lchild, rchild	只能向下查找
三叉链表	lchild, rchild, parent	可双向查找

2. 链式存储代码实现

2.1 C++ 写法

struct BTNode {
    char data;
    BTNode *lchild;
    BTNode *rchild;
};

C++写法

2.2 C 语言写法（typedef）

使用 typedef 给结构体起别名，简化声明：

typedef struct BTNode {
    char data;
    struct BTNode *lchild, *rchild;
} BTNode;

// 使用时不需要加 struct 前缀
BTNode a, *d;
BTNode *b = (BTNode*)malloc(sizeof(BTNode));

C写法

typedef详解

3. 线索二叉树

3.1 为什么需要线索化

二叉链表中存在大量空指针（结点数+1 个），造成浪费。

线索化：利用空指针存储前驱/后继信息，提高遍历效率。

线索化原理

3.2 线索化规则

空指针	指向
左空指针	前驱结点
右空指针	后继结点

3.3 线索标志位

如何区分指针指向的是孩子还是线索？增加 ltag 和 rtag 标志位：

线索标志

标志位	值	含义
ltag/rtag	0	指向左/右孩子
ltag/rtag	1	指向前驱/后继（线索）

结点结构：

typedef struct BTNode {
    char data;
    struct BTNode *lchild, *rchild;
    int ltag, rtag;  // 线索标志
} BTNode;

3.4 中序线索二叉树示例

中序线索二叉树

对二叉树进行中序线索化后：

中序序列：B → D → A → C
空指针被利用为前驱/后继线索

4. 总结

存储方式	优点	缺点
顺序存储	访问简单，适合完全二叉树	非完全树浪费空间
二叉链表	灵活，节省空间	空指针浪费
三叉链表	可双向查找	多一个指针开销
线索二叉树	利用空指针，遍历高效	结构复杂

关键点：

空指针个数 = 结点数 + 1
线索化利用空指针存储前驱/后继
ltag/rtag 用于区分孩子和线索

链队列实现

Thu, 13 Nov 2025 16:00:00 GMT

队列是一种**先进先出（FIFO）**的线性数据结构，只允许在一端（队尾）插入、另一端（队头）删除。链队列用带头结点的单链表实现，相比顺序队列（循环数组）不会存在假溢出问题，空间按需分配。

数据结构定义

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>

typedef char DataType;

typedef struct LQNode {
    DataType data;
    struct LQNode *next;
} LQNode, *LinkedQNode; // 链队列结点的类型

typedef struct {
    struct LQNode *front, *rear; // 头指针和尾指针
} LQueue, *LinkedQueue; // 将头、尾指针封装在一起的链队列

// [算法 3.21]    创建一个带头结点的空队列
void QueueInit(LinkedQueue *Q) {  //构造一个空队列 Q
    *Q = (LinkedQueue)malloc(sizeof(LQueue)); // 分配队列结构体空间
    if (!(*Q)) return; // 分配失败
    (*Q)->front = (LQNode*)malloc(sizeof(LQNode)); // 分配头结点
    if (!((*Q)->front)) {
        free(*Q);
        *Q = NULL;
        return;
    }
    (*Q)->front->next = NULL; // 头结点next置空
    (*Q)->rear = (*Q)->front; // front和rear都指向头结点，表示队列为空
}

// [算法 3.22]    入队列
bool QueueIn(LinkedQueue Q, DataType x) {  //插入元素 x 为 Q 的队尾元素
    if (!Q) return false;
    LQNode *node = (LQNode*)malloc(sizeof(LQNode)); // 新建结点
    if (!node) return false;
    node->data = x;
    node->next = NULL;
    Q->rear->next = node; // 原队尾结点next指向新结点
    Q->rear = node; // rear指向新结点
    return true;
}

// [算法 3.23]    出队列
bool QueueOut (LinkedQueue Q, DataType *x){  //若队列不空 ,则删除 Q 的队头元素
    if (!Q || Q->front == Q->rear) return false; // 队空
    LQNode *p = Q->front->next; // 队头元素
    *x = p->data; // 取数据
    Q->front->next = p->next; // 头结点next指向下一个结点
    if (Q->rear == p) Q->rear = Q->front; // 若出队后队空，rear回到头结点
    free(p);
    return true;
}

// [算法 3.24]    判断队列是否为空
bool QueueEmpty(LinkedQueue Q) {  //判断队列 Q 是否为空
    if (!Q) return true;            // 队列指针为空
    return Q->front == Q->rear;     // 头尾指针相遇即为空
}

//清空队列
void Empty(LinkedQueue Q)
{
    while (Q->front != Q->rear)
    {
        LQNode * p = Q->front->next;    //取得队列第一个元素指针
        Q->front->next = p->next;   //修改队头指针指向
        free(p);
        if(Q->front->next == NULL) //只有一个元素时 ,出队后队空 ,此时还要修改队尾指针
            Q->rear = Q->front;
    }
}

// 释放队列
void FreeQueue(LinkedQueue *Q) {
    if (*Q == NULL) return; // 如果队列为空，直接返回

    LQNode * current = (*Q)->front; // 从头节点开始
    LQNode * temp;

    while (current != NULL) {
        temp = current; // 保存当前节点
        current = current->next; // 移动到下一个节点
        free(temp); // 释放当前节点
    }

    free(*Q); // 最后释放队列结构体本身
    *Q = NULL; // 将队列指针设为NULL，防止悬挂指针
}

//获取队首元素
void GetQueue(LinkedQueue Q)
{
    if (Q->front == NULL)
    {
        printf("None\n");
        return;
    }
    else
       printf("%c\n", Q->front->next->data);

}

int main()
{
    DataType c,x;
    LinkedQueue Q = NULL;
    QueueInit(&Q);
    while (1)
    {
        scanf(" %c", &c);
        if (c == 'E')
        {
            scanf(" %c", &x);
            QueueIn(Q, x);
        }
        else if (c == 'C')
        {
            Empty(Q);
        }
        else if (c == 'G')
        {
            GetQueue(Q);
        }
        else if (c == 'D')
        {
            //dequeue(m);
            if(QueueOut(Q, &x))
             printf("%c\n", x);
          else
             printf("None\n");
        }
        else if (c == 'Q')
        {
            break;
        }
    }
    FreeQueue(&Q);
    return 0;
}

这里详细讲一下 (*Q)-> 的含义和作用：

二级指针解引用 `(*Q)->`

参数类型
QueueInit(LinkedQueue *Q) 里的 Q 是“指向队列指针的指针”。
也就是：LinkedQueue 是 LQueue *，LinkedQueue *Q 就是 LQueue **Q。
解引用
*Q 表示“取出 Q 指向的内容”，也就是实际的队列指针（LQueue *）。
例如：*Q = malloc(...)，就是让外部的队列指针指向新分配的队列结构体。
访问结构体成员
(*Q)->front 表示“队列的头指针”。
因为 *Q 是 LQueue *，所以用 -> 访问结构体成员。
为什么不用 Q->front
如果直接用 Q->front，那 Q 必须是 LQueue *，而不是 LQueue **。
但这里 Q 是指向指针的指针，所以要先解引用，再访问成员。

举例说明：

void QueueInit(LinkedQueue *Q) {
    *Q = (LinkedQueue)malloc(sizeof(LQueue)); // 分配队列结构体
    (*Q)->front = (*Q)->rear = (LQNode *)malloc(sizeof(LQNode)); // 分配头结点
    (*Q)->front->next = NULL; // 头结点next置空
}

*Q：拿到实际的队列指针
(*Q)->front：访问队列的头指针
(*Q)->rear：访问队列的尾指针

总结：(*Q)-> 是先解引用拿到队列指针，再用 -> 访问结构体成员。这样才能正确初始化和操作队列。

用指针返回出队值 `*x = p->data`

出队函数签名是 QueueOut(LinkedQueue Q, DataType *x)，其中 *x = p->data; 这一行不带 * 不行。

原因是：要把出队的元素值“带出来”给主程序用，必须用指针参数（DataType *x），在函数里通过 *x = p->data; 赋值。如果只用值参数（如 DataType x），函数内部的赋值不会影响主程序变量，主程序拿不到出队的值。这就是 C 语言“用指针返回结果”的常规做法——和 scanf("%d", &n) 传 &n 一个道理。

Git 使用指南

Thu, 13 Nov 2025 16:00:00 GMT

安装与配置

安装

Windows：git-scm.com 下载安装包，按向导完成
macOS：brew install git 或安装 Xcode Command Line Tools

用户信息配置

git config --global user.name "你的名字"
git config --global user.email "你的邮箱"

SSH Key 配置

# 生成密钥对
ssh-keygen -t ed25519 -C "你的邮箱"

# 查看公钥，复制到 GitHub/GitLab 的 SSH Keys 设置中
cat ~/.ssh/id_ed25519.pub

# 测试连接
ssh -T git@github.com

基础工作流

# 初始化仓库
git init

# 克隆远程仓库
git clone git@github.com:user/repo.git

# 查看状态
git status

# 添加到暂存区
git add .                # 所有文件
git add file.txt         # 指定文件

# 提交
git commit -m "提交说明"

# 推送到远程
git push origin main

# 拉取远程更新
git pull origin main

# 查看提交历史
git log --oneline

分支管理

# 查看分支
git branch

# 创建并切换分支
git checkout -b feature/xxx
# 或用新版命令
git switch -c feature/xxx

# 切换分支
git checkout main

# 合并分支（在 main 上合并 feature）
git merge feature/xxx

# 删除分支
git branch -d feature/xxx

解决合并冲突

合并时如果出现冲突，手动编辑冲突文件，保留需要的内容，然后：

git add .
git commit -m "解决合并冲突"

常用技巧

.gitignore

在仓库根目录创建 .gitignore 文件，列出不需要跟踪的文件：

# 依赖目录
node_modules/
__pycache__/

# 编辑器配置
.vscode/
.idea/

# 系统文件
.DS_Store
Thumbs.db

# 构建产物
dist/
build/

移除跟踪但保留本地文件

# 从 Git 跟踪中移除（不会删除本地文件）
git rm --cached .obsidian/app.json

# 或移除整个目录
git rm --cached -r .obsidian/

# 加入 .gitignore 防止再次跟踪
echo ".obsidian/" >> .gitignore
git add .gitignore
git commit -m "移除配置文件跟踪"

stash 暂存工作区

# 暂存当前修改
git stash

# 恢复暂存
git stash pop

# 查看暂存列表
git stash list

撤销操作

# 撤销工作区修改（未 add）
git checkout -- file.txt

# 撤销暂存（已 add 未 commit）
git reset HEAD file.txt

# 撤销最近一次提交（保留修改）
git reset --soft HEAD~1

图形化工具

PyCharm 集成：内置 Git 支持，VCS 菜单直接操作
VSCode 集成：左侧源代码管理面板，支持 diff、提交、推送

youkiの博客

现代前端基础：Vanilla 与数据驱动 UI

什么是 Vanilla

数据驱动界面

数据与界面分离

状态驱动 UI

小结

参考

现代前端基础：模块化、npm 与 Vite

为什么需要模块化

传统 script 引入

全局污染

出路：工程化

模块化与 ES 模块

export 与 import

名词：ES 与 ECMAScript

构建工具

三方诉求的矛盾

构建工具的职责

npm：项目级包管理

npm 与 apt 的区别

初始化与安装

Vite 实操：dev / build / preview

dev：开发服务器

build：打包上线版本

preview：上线前本地预览

参考

SSH 为什么会连到错误的服务器？一次 FlClash 核心异常排查

诡异的错误提示

为什么监控网站还是正常的

用另一条路径确认问题在哪里

FlClash 核心异常的证据

最终修复：重启核心

结语

如何使用好Codex等ai工具

给上下文，而不是堆 Prompt

新模型不缺少规划能力

先让 Codex 研究，再生成 Goal

给模型路径自由，但保留必要边界

AGENTS.md 是长期上下文

Subagent 不是免费的加速按钮

/compact 和 /fork

Review 是另一个阶段

结语

参考资料

CTF今后到底会变成什么样子——ISCC赛后总结

初识 CTF

ai 挺能做题

比赛开始越来越抽象

省赛—八仙过海

官方群欢乐多

GPT 能做题，WP 还是得自己写

赛后总结？

初识 Kubernetes：从 Service 与 CoreDNS 理解服务发现

1. 先理清 K8s 的几个基本对象

2. Service：一个虚拟的、稳定的”门牌号”

3. CoreDNS：一个内置的”黄页”

4. 一个完整的调用链路

5. 和单机 localhost 部署的本质区别

6. 写给自己的小结

CLI Agent 实践指南：从 Claude Code 到通用方法论

0. 三家命令速查

1. Plan 模式：所有工作的起点

1.1 决策树：能用一句话描述 diff 吗？

1.2 Plan 阶段的 3 个高阶玩法

1）用外置编辑器把计划当合同

2）计划里显式列验证步骤

1.3 三家 Plan 命令对照

2. 需要掌握的 7 个命令

2.1 @文件 / @路径/ — 精准注入上下文

2.2 !命令 — 会话内跑 shell

2.3 /clear — 切任务时清空上下文

2.4 /compact [focus...] — 长会话摘要压缩

2.5 /resume — 恢复历史会话

2.6 /rewind / /session — 回退到 checkpoint

2.7 /model + --effort — 切模型与思考强度

2.8 锦上添花

3. 上下文管理：context window

3.1 4 种”喂”上下文的姿势

3.2 3 个清理层次

`AGENTS.md` 是长期上下文

`/compact` 和 `/fork`

5. 和单机 `localhost` 部署的本质区别

2.1 `@文件` / `@路径/` — 精准注入上下文

2.2 `!命令` — 会话内跑 shell

2.3 `/clear` — 切任务时清空上下文

2.4 `/compact [focus...]` — 长会话摘要压缩

2.5 `/resume` — 恢复历史会话

2.6 `/rewind` / `/session` — 回退到 checkpoint

2.7 `/model` + `--effort` — 切模型与思考强度

4.5 `--yolo` / `--dangerously-skip-permissions` 是最后手段

5.4 两次失败就 `/clear` 重来