首页 on 武成龙

云原生地理空间智能计算系统

Mon, 01 Dec 2025 00:00:00 +0000

项目概述

国家重点研发计划课题「云原生地理空间智能计算系统」前端模块，负责地理空间分析可视化前端开发，基于 React + Mapbox + Bpmn.js 构建知识驱动的智能地理计算交互界面。

核心职责

智能地理计算交互界面：构建模型编排画布，基于 Bpmn.js 实现地理计算工作流的可视化建模与拖拽编排
多源异构模型管理：解决 200+ 地理计算模型的元数据渲染问题，支持模型检索、参数配置与调用链路可视化
空间数据可视化：基于 Mapbox 实现多维地理空间数据的交互式展示与分析
Agent 驱动改造：后期将系统改造为 Agent 驱动架构，基于 LangChain 实现通过对话交互完成基于知识库、数据库和模型库的三位一体地理建模（GEO-TRINITY）

技术亮点

设计统一的模型元数据 Schema，适配 200+ 多源异构地理计算模型
基于 Bpmn.js 扩展自定义建模元素，实现地学领域专用的流程编排器
高性能地图渲染方案，支持大规模空间分析结果的可视化展示
GEO-TRINITY 三位一体建模：知识库 + 数据库 + 模型库智能编排，自然语言驱动地理建模

技术栈

前端框架：React + TypeScript
地图引擎：Mapbox GL JS
流程编排：Bpmn.js
地图服务：GeoServer
空间数据：PostGIS

纳福猫舍智能信息管理系统

Wed, 01 Oct 2025 00:00:00 +0000

项目概述

为山东省邹城市纳福猫舍独立开发的全栈智能信息管理系统，包含 Web 后台管理系统（Next.js） 与 店铺助手小程序（Uni-app） 双端，实现猫舍日常运营的全面数字化。

核心功能

猫咪档案管理：完整的猫咪信息登记、血统追溯、健康记录与成长追踪
品种管理：多品种猫咪的标准化信息模板，支持自定义品种属性
门店管理：多门店统一管理，库存、订单、客户信息一站式维护
LLM 智能录入：集成大语言模型，支持自然语言描述自动填充结构化档案，大幅降低信息录入成本
售前售后支持：小程序方便客户浏览猫咪信息，Web 后台辅助店主高效管理，显著提升售前沟通与售后服务效率

技术亮点

独立完成全栈架构设计与开发，前端到后端到部署全链路
LLM 辅助信息录入，将传统手工填表效率提升 5 倍以上
双端统一数据模型，小程序与 Web 后台实时同步
已上线使用并获得店主认可，实际解决猫舍日常运营痛点

技术栈

Web 前端：Next.js + React
小程序：Uni-app (Vue)
后端：Next.js API Routes + Prisma ORM
数据库：PostgreSQL
AI 能力：LLM API 集成

AICV 简历王小程序

Fri, 01 Aug 2025 00:00:00 +0000

项目概述

智悦云创（湖南）科技有限公司旗下智能简历小程序，参与产品定义并主导整体技术方案设计，带领 3 名前端实习生从 0 到 1 完成开发交付。

核心功能

简历智能评估：调用自研简历评估算法接口，从排版、内容、匹配度等多维度对简历进行评分
智能优化建议：基于评估结果，自动生成针对性的简历优化建议和改进方案
完整闭环流程：用户上传简历 → 系统智能评估 → 输出优化建议，全流程自动化

我的职责

产品定义：参与产品定位与功能规划，输出核心交互流程
技术方案：负责小程序整体技术架构设计，制定敏捷迭代计划并分配开发任务
团队管理：带领 3 名前端实习生，把控代码质量与交付节奏
持续优化：小程序上线后服务 2000+ 用户，基于用户反馈完成 3 轮功能迭代

技术栈

前端：Uni-app + Vue
平台：微信小程序
后端服务：自研简历评估算法 API
项目管理：敏捷开发 + 迭代规划

智能企业人才评估系统

Sun, 01 Jun 2025 00:00:00 +0000

项目概述

智悦云创（湖南）科技有限公司面向大型企业招聘场景的智能人才评估系统。负责核心模块（简历评估）的方案设计与前端整体技术架构，保障前端交付质量。

核心功能

批量简历评估：支持 HR 批量上传简历，系统自动完成多维度智能评估与打分排序，已处理 1000+ 份简历
自反馈进化：评估结果可被人工复核和修正，系统基于反馈持续优化评估模型
企业级权限管理：多角色权限体系，适配企业 HR、部门主管、管理员等不同角色

我的职责

核心模块设计：负责简历评估模块的方案设计，输出落地技术文档，指导后续开发
前端架构：负责 React 前端整体技术架构设计，制定组件规范与工程化标准
质量把控：保障前端交付质量，建立 Code Review 机制与自动化测试体系
文档沉淀：输出技术方案文档与接口规范，降低团队协作成本

技术栈

前端框架：React + TypeScript
UI 组件库：Ant Design
状态管理：Zustand
工程化：Vite + ESLint + Prettier
测试：Vitest + Playwright

给 RAG Agent 加流式输出：SSE 从设计到落地

Fri, 07 Aug 2026 00:00:00 +0000

给一个基于 FastAPI + LangChain/LangGraph 的 RAG Agent 加上"打字机"式流式输出。本文按自顶向下的顺序记录：从方案选型、协议设计，到后端/前端实现，最后是一段曲折的踩坑——dev 代理的 gzip 压缩会把流式悄悄变成一次性响应。

先说结论：

流式对话用 SSE（Server-Sent Events）就够了——方案一（SSE 专用接口）成本可控、标准通用、能满足"打字机效果"的核心诉求。关键实现要点有三个：后端用 agent.astream(stream_mode="messages") 逐 token 产出、前端用原生 fetch + ReadableStream 解析（不能用 EventSource，因为要 POST + Authorization）、以及必须让响应头带 Cache-Control: no-cache, no-transform，否则开发代理的 gzip 会把流缓冲成一大块。

一、为什么需要流式

LLM 生成一段回复通常要 3~10 秒，Agent 场景还会先调工具检索，首字延迟更明显。如果没有流式，用户点击发送后只能盯着转圈，体验很差；而流式下首个 token 往往几百毫秒就到了，后续内容逐字出现，感知延迟大幅下降。

在动手前先明确约束：

现有接口 POST /chat 一次性返回 JSON，前端 await 后整段渲染；
后端已有 create_react_agent(llm, tools) 的 ReAct Agent（含 RAG 检索工具和 MCP 工具）；
前端是 React + umi（axios 封装），需要增量渲染能力。

二、方案选型：SSE / WebSocket / NDJSON

维度	SSE（方案一）	WebSocket（方案二）	NDJSON（方案三）
实现成本	中	高	低
前端改动	中（换 fetch）	大（WS 客户端）	小（axios 参数）
标准性 / 通用性	高	中	低
双向交互（停止 / 确认）	否	是	否
代理 / 负载均衡兼容	好	需要特殊支持	好（但怕压缩）
适用场景	通用聊天流式，首选	需要 Agent 交互控制	快速验证 / 最小改动

选择 SSE 的决定性理由：

单向流正是聊天场景需要的——服务端推，客户端收，不需要上行通道；
HTTP 协议、任何代理/CDN 都能透传，生产部署成本最低；
保留原有 POST /chat 不动，新端点并行存在，向后兼容；
把事件对象设计成与传输协议解耦（{"type", "content", ...}），未来要升级 WebSocket 或加"停止生成"功能时，只换传输层即可。

一个容易踩的坑：EventSource（浏览器原生 SSE API）只支持 GET，而我们的接口需要 POST + Authorization 请求头，所以前端必须用 fetch + ReadableStream 手动解析 SSE 帧。

三、后端设计：事件协议

流式接口把原来的一次性 JSON 响应拆成一串事件，每个事件一行：

data: {"type": "text", "content": "地理信息系统（GIS"} # 增量文本，前端追加渲染

data: {"type": "tool", "name": "info_retriever"} # 工具调用，可展示"正在检索…"

data: {"type": "done", "response": "...", "session_id": "...", "message_count": 6} # 结束

data: {"type": "error", "code": 5010, "message": "聊天调用超时"} # 出错

SSE 帧格式是 data: <JSON>\n\n，一次连接推多个事件，最后自然结束。

四、后端实现

4.1 服务层：async generator 产出事件

核心是 LangGraph 的 agent.astream(..., stream_mode="messages")，它逐 token 产出 (message_chunk, metadata)。这里有个非常优雅的特性：工具调用阶段产出的 AIMessageChunk 内容为空（只有 tool_calls），自然被 elif content: 过滤掉；ToolMessage 单独透出为 tool 事件；最终答案逐 token 到达。这样"文本流"和"工具事件流"自动分离。

async def chat_stream(self, prompt, query, chat_model_name, ...):
 tools, messages = self._build_tools_and_messages(
 prompt=prompt, query=query, use_memory=use_memory,
 history=history, db_name=db_name, mcp_tools=mcp_tools,
 user_id=user_id,
 )
 llm = self._create_llm(chat_model_name)

 if tools:
 agent = create_react_agent(llm, tools)
 async for msg_chunk, _meta in agent.astream(
 {"messages": messages},
 config={"callbacks": [handler]}, # 工具审计回调不变
 stream_mode="messages",
 ):
 msg_type = getattr(msg_chunk, "type", "")
 content = getattr(msg_chunk, "content", "") or ""
 if msg_type == "tool": # ToolMessage → 工具事件
 yield {"type": "tool",
 "name": getattr(msg_chunk, "name", None) or "tool"}
 elif content: # AIMessageChunk → 增量文本
 yield {"type": "text", "content": content}
 else:
 async for chunk in llm.astream(messages): # 纯对话直接流式
 content = getattr(chunk, "content", "") or ""
 if content:
 yield {"type": "text", "content": content}

顺带一个重构收益：把"构建工具 + 消息列表"抽成 _build_tools_and_messages()，普通 /chat 和流式 /chat/stream 共享，避免两套逻辑漂移。

4.2 路由层：StreamingResponse + 完整生命周期

流式不能牺牲原有保障，所以生命周期和一次性接口完全对齐：

先落库：用户消息、ChatRun 审计记录在流开始前写入（超时/断线也能恢复用户输入）；
流转：把 generator 包进 StreamingResponse(media_type="text/event-stream")；
流结束落库：AI 回复、会话标题、记忆、finish_chat_run("succeeded")；
超时：用 asyncio.wait_for(iterator.__anext__(), timeout=...) 对每个 chunk 设超时，超时发 error 事件并记 timed_out；
断线/取消：except asyncio.CancelledError / finally 兜底记 cancelled，防止审计记录永远卡在 running。

def _sse_payload(event: dict) -> str:
 return f"data: {json.dumps(event, ensure_ascii=False)}\n\n"

@router.post("/chat/stream")
async def chat_stream(request: ChatRequest, ...) -> StreamingResponse:
 # ... 会话校验、先落库用户消息、create_chat_run ...
 return StreamingResponse(
 event_generator(), # 内部 while 循环 + asyncio.wait_for 逐块消费
 media_type="text/event-stream",
 headers={
 "Cache-Control": "no-cache, no-transform", # 关键！见踩坑部分
 "X-Accel-Buffering": "no",
 "Connection": "keep-alive",
 },
 )

五、前端实现

5.1 用 fetch 解析 SSE

为什么不用 EventSource：它只支持 GET，且无法自定义 Authorization 头。用 fetch + ReadableStream：

export async function chatStream(body, onEvent, signal?) {
 const headers: Record<string, string> = { 'Content-Type': 'application/json' };
 const token = localStorage.getItem('token');
 if (token) headers['Authorization'] = `Bearer ${token}`;

 const resp = await fetch('/llm/v1/chat/stream', {
 method: 'POST', headers, body: JSON.stringify(body), signal,
 });
 if (!resp.ok) throw new Error(`HTTP ${resp.status}`);
 if (!resp.body) throw new Error('响应体不可用');

 const reader = resp.body.getReader();
 const decoder = new TextDecoder('utf-8');
 let buffer = '';

 while (true) {
 const { done, value } = await reader.read();
 if (done) break;
 buffer += decoder.decode(value, { stream: true });

 let sepIdx: number;
 while ((sepIdx = buffer.indexOf('\n\n')) >= 0) { // 按空行切分 SSE 帧
 const frame = buffer.slice(0, sepIdx);
 buffer = buffer.slice(sepIdx + 2);
 for (const line of frame.split('\n')) {
 if (!line.startsWith('data: ')) continue;
 const payload = line.slice(6).trim();
 if (!payload || payload === '[DONE]') continue;
 onEvent(JSON.parse(payload)); // 交给 React 增量渲染
 }
 }
 }
}

注意：SSE 帧可能跨网络分块到达，所以必须用 buffer 拼接后按 \n\n 切分，不能假设一次 read() 就是一个完整事件。

5.2 增量渲染

状态更新只改最后一条 AI 消息：首个 text 事件创建消息（标记 streaming），后续事件原地追加内容。配合一个闪烁光标，就是完整的打字机效果。

let streamedText = '';
let streamMsgId: string | null = null;

await chatStream(requestData, (ev) => {
 if (ev.type === 'text' && ev.content) {
 streamedText += ev.content;
 if (streamMsgId === null) {
 streamMsgId = String(Date.now() + 1);
 setMessages(prev => [...prev,
 { id: streamMsgId!, type: 'ai', content: streamedText, streaming: true }]);
 } else {
 setMessages(prev => prev.map(m =>
 m.id === streamMsgId ? { ...m, content: streamedText } : m));
 }
 }
 // ev.type === 'tool' 可展示"正在检索…"；ev.type === 'error' 提示错误
});

六、踩坑记录：gzip 把流式变成一次性响应

这是本次最值得记录的一环。

现象

后端直连、甚至通过 dev 代理用 curl 测试，事件都是逐块到达的（实测 31 个事件分布在 10~16 秒内）。但浏览器里就是等全部回复结束后一次性渲染，流式完全没有效果。

定位

在浏览器 Network 面板看 chat/stream 响应头，发现两个可疑项：

Content-Encoding: gzip
X-Powered-By: Express

X-Powered-By: Express 说明请求经过了 Umi dev 代理（Express 中间件）。Express 的 compression 中间件默认对接受 gzip 的客户端启用压缩——浏览器请求头带 Accept-Encoding: gzip, deflate, br，而 curl 不带，所以 curl 正常、浏览器异常，就是这个差异造成的假象。

为什么 gzip 会破坏流式？compression 中间件把响应包进 zlib 流，zlib 默认攒够一个块（约 16KB）才输出。对一段几百字的回复，数据会在流结束时一次性 flush，浏览器拿到的就是一整块压缩数据，解压后一次性渲染。

修复：`Cache-Control: no-cache, no-transform`

Umi 3 的 dev CLI 把 compress: true 写死，devServer.compress = false 覆盖不掉。最稳妥的方案是让后端对这个响应显式声明"不可转换"：

headers={
 "Cache-Control": "no-cache, no-transform",
 ...
}

no-transform 是 RFC 7234 §5.2.2.4 定义的标准指令。Express compression 中间件的 shouldTransform() 正是检查它：

var cacheControlNoTransformRegExp = /(?:^|,)\s*?no-transform\s*?(?:,|$)/

function shouldTransform(req, res) {
 var cacheControl = res.getHeader('Cache-Control')
 // Don't compress for Cache-Control: no-transform
 return !cacheControl || !cacheControlNoTransformRegExp.test(cacheControl)
}

命中后中间件直接跳过压缩，流就能原样逐块透传给浏览器。实测对比：同一代理，请求 /umi.js（普通资源）带 Accept-Encoding: gzip 返回 Content-Encoding: gzip；而 SSE 响应带 no-transform 后不再被压缩。

顺带说明：X-Accel-Buffering: no 是 nginx 的概念，对 Express 代理无效；真正让压缩中间件退场的是 no-transform。

七、验证方法

不要靠"感觉"，用带时间戳的实测脚本验证流是否真的逐块到达：

import time, json, urllib.request

req = urllib.request.Request(url, data=body, method="POST", headers=auth_headers)
t0 = time.time()
with urllib.request.urlopen(req, timeout=120) as r:
 for raw in r: # 逐行读取，天然带到达时间信息
 line = raw.decode().strip()
 if line.startswith("data: "):
 ev = json.loads(line[6:])
 print(f"+{(time.time()-prev)*1000:6.0f}ms {ev['type']}")
 prev = time.time()

判读标准：事件间隔呈几十到几百毫秒的分布、且总耗时接近模型生成时长（而不是第一帧就 0ms、最后一帧才全部出现）→ 流式生效。

八、小结与后续优化

这套实现的三个关键决策，值得带走：

协议选 SSE：单向聊天场景下，比 WebSocket 少 90% 的复杂度，且代理友好；
stream_mode="messages" 让文本流与工具事件自动分离，Agent 的"思考-调用-作答"过程对前端透明化；
no-transform 是流式接口的"免死金牌"——任何中间件只要尊重标准，就不会吃掉你的流。

后续可选优化方向：

取消生成：加一个 AbortController + 后端取消信号（这需要双向通道，届时再考虑 WebSocket 或独立的 cancel 端点）；
工具事件可视化：前端把 tool 事件渲染成"正在检索知识库…“的步骤条；
Agent 状态持久化：用 LangGraph Checkpointer（SQLite/Postgres）替代内存 dict，跨请求保存 Agent 状态；
重连语义：SSE 标准支持 Last-Event-ID，可配合请求 ID 实现断线续传。

Apifox 调试 SSE 接口

Wed, 05 Aug 2026 00:00:00 +0000

SSE 广泛用于 AI 流式响应。Apifox（≥2.3.10）原生支持：

新建 HTTP 接口，填写地址、设置返回类型后发送。
返回 text/event-stream 时自动解析 SSE 事件。
时间线视图实时查看，内置 OpenAI / Gemini / Claude 格式自动合并。
自定义格式配置 JSONPath 提取规则，或用后置脚本处理。

参考：Apifox 官方文档 - SSE 调试

Zed自定义Git命令

Fri, 31 Jul 2026 00:00:00 +0000

Zed自定义Git命令

适用环境：Zed 编辑器 + Git Graph / Git Panel · 配置位置：~/.config/zed/tasks.json

一、核心结论

用 tags: ["git-command"] 定义任务，配合 $ZED_GIT_* 变量，把「查看、派生、分支操作」三类高频 Git 操作变成右键即用的菜单命令，从此告别手敲 SHA 和分支名。

一份配置，三个收益：

零记忆：不用记 SHA、不用复制粘贴，右键即点即用
零输入：分支名 / 标签名 / 提交号全部由变量自动注入
零切换：不离开编辑器，git 操作全部在 Zed 的终端里完成

二、三大机制

理解这三件事，后面所有配置都是它们的排列组合。

2.1 入口：命令从哪来

任务定义在全局 tasks.json（工作区级 .zed/tasks.json 暂不支持）
带 git-command 标签的任务会出现在 Git Graph 的右键菜单里：
- 右键提交行 → 提交菜单（Commit 菜单）
- 右键分支 / 远程引用 / 标签 chip → 引用菜单（Ref 菜单）

2.2 变量：能自动注入什么

变量	含义	可用菜单
`$ZED_GIT_SHA`	选中提交的完整 SHA	Commit + Ref
`$ZED_GIT_SHA_SHORT`	短 SHA（7 位）	Commit + Ref
`$ZED_GIT_REPOSITORY_NAME`	仓库名	Commit + Ref
`$ZED_GIT_REPOSITORY_PATH`	仓库绝对路径（默认 cwd）	Commit + Ref
`$ZED_GIT_REF`	点击的引用名（分支/远程/标签）	仅 Ref 菜单

编辑器类变量（$ZED_FILE、$ZED_SELECTED_TEXT 等）在 Git 任务里不会提供，引用它们的任务会被自动过滤。

2.3 过滤规则：任务怎么"隐身"

任务里用了 $ZED_GIT_REF → 只在右键 chip 时出现
任务里只用 $ZED_GIT_SHA → 提交菜单和引用菜单都出现
任务不用任何变量 → 两种菜单都出现
任务用了不存在的变量 → 不出现

结论：用变量本身做"菜单路由"，想限定场景就引用对应变量。

三、三种写法与两个大坑

3.1 三种写法

写法	适用场景	示例
A. 纯参数：`command` + `args`	参数无空格、无特殊字符	`git branch -d $ZED_GIT_REF`
B. 整行命令：整条 shell 命令放 `command`	含管道 / 重定向 / 交互输入	`git show $ZED_GIT_SHA \| pbcopy`
C. tty 交互：`/dev/tty` + `read`	需要现场输入（起名 / 改名）	见 3.3

3.2 大坑一：args 会被"拆碎"

Zed 会把 command 和所有 args 用空格拼成一条命令行交给登录 shell 执行，不负责转义。所以：

"args": ["-c", "printf 'Branch name: ' > /dev/tty; ..."]

拼接后变成 zsh -c printf 'Branch name: ' > /dev/tty; ...，-c 后面只跟了 printf 一个词 → 报 zsh: printf:1: not enough arguments。

对策：含空格/引号/特殊符号的命令一律用写法 B（整行命令），让登录 shell 原样执行，不经过拼接。

3.3 大坑二：交互输入要绑 `/dev/tty`

任务跑在 PTY 里，标准输入不一定是终端。输入提示的标准姿势：

{
 "label": "Create tag at: $ZED_GIT_SHA_SHORT",
 "command": "printf 'Tag name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git tag \"$name\" \"$ZED_GIT_SHA\"",
 "tags": ["git-command"]
}

三段式：打印提示到 tty → 从 tty 读入 → 非空才执行。注意这里整行命令在 command 字段，天然规避了大坑一。

3.4 平台差异

pbcopy（复制到剪贴板）仅 macOS；Linux 换 xclip -selection clipboard 或 wl-copy
open -a Fork 依赖 Fork 应用，其他平台可换成 GitHub/GitLab 链接

四、命令清单

4.1 提交右键族（Commit 菜单）—— 看、取、派、查

命令	作用	备注
Cherry-pick	摘取提交	已有基础版；`-x` 版会记录来源
Revert	撤销提交	已有；`-m 1` 版专用于合并提交
Show	查看提交 + 文件统计	`git show --stat`
Diff vs parent	只看该提交的改动	`git diff sha^ sha`
Branches containing	哪些分支包含此提交	排查漏合并神器
Copy patch	整段 patch 进剪贴板	macOS 需 `pbcopy`
Create fixup	对旧提交打补丁标记	配合 `rebase --autosquash`
Create tag at	在提交上打标签	tty 交互输入
Bisect bad / good	二分定位回归	右键提交直接标记

4.2 分支标签右键族（Ref 菜单）—— 引用的增删改查

命令	作用	备注
Delete branch	删除本地分支	`-d` 仅删已合并，`-D` 强删
Delete tag	删除本地标签	可选配"删远程标签"版
Check out	切换分支	官方示例同款
Merge	并入当前分支	注意当前分支被保护
Rebase onto	当前分支变基到它
Diff vs HEAD	与当前分支的差异统计
Log	看该引用最近 15 条	`--graph` 带拓扑
Push -u origin	推送并建立上游	新建分支后常用
Rename	重命名分支	tty 交互输入

4.3 通用族（两种菜单都会出现）—— 谨慎添加

git status、git fetch --prune 这类无变量任务两种菜单都显示，容易把菜单刷爆，按需添加。

五、完整配置（可直接粘贴）

合并进 ~/.config/zed/tasks.json 的数组里即可。其中 Create branch at 已修复为整行写法（规避大坑一）。

[
 { "label": "Cherry-pick", "command": "git", "args": ["cherry-pick", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Cherry-pick (-x): $ZED_GIT_SHA_SHORT", "command": "git", "args": ["cherry-pick", "-x", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Revert", "command": "git", "args": ["revert", "--no-edit", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Revert merge: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["revert", "-m", "1", "--no-edit", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Show: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["show", "--stat", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Branches containing: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["branch", "-a", "--contains", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Diff vs parent: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["diff", "$ZED_GIT_SHA^", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Create fixup: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["commit", "--fixup", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Copy patch: $ZED_GIT_SHA_SHORT", "command": "git show $ZED_GIT_SHA | pbcopy", "tags": ["git-command"] },
 {
 "label": "Create tag at: $ZED_GIT_SHA_SHORT",
 "command": "printf 'Tag name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git tag \"$name\" \"$ZED_GIT_SHA\"",
 "tags": ["git-command"]
 },
 { "label": "Bisect bad: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["bisect", "bad", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Bisect good: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["bisect", "good", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 {
 "label": "Create branch at: $ZED_GIT_SHA_SHORT",
 "command": "printf 'Branch name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git branch \"$name\" \"$ZED_GIT_SHA\"",
 "tags": ["git-command"],
 "reveal": "always",
 "use_new_terminal": true
 },
 {
 "label": "Open in Fork",
 "command": "zsh",
 "args": ["-c", "open -a Fork . && sleep 2 && open \"fork://repo/$ZED_GIT_REPOSITORY_NAME/commit/$ZED_GIT_SHA\""],
 "tags": ["git-command"]
 },
 { "label": "Reset --soft to: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["reset", "--soft", "$ZED_GIT_SHA"], "tags": ["git-command"] },
 { "label": "Reset --hard to: $ZED_GIT_SHA_SHORT", "command": "git", "args": ["reset", "--hard", "$ZED_GIT_SHA"], "tags": ["git-command"] },

 { "label": "Delete branch: $ZED_GIT_REF", "command": "git", "args": ["branch", "-d", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Delete tag: $ZED_GIT_REF", "command": "git", "args": ["tag", "-d", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Delete remote tag: $ZED_GIT_REF", "command": "git", "args": ["push", "origin", "--delete", "refs/tags/$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Check out: $ZED_GIT_REF", "command": "git", "args": ["checkout", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Merge: $ZED_GIT_REF", "command": "git", "args": ["merge", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Rebase onto: $ZED_GIT_REF", "command": "git", "args": ["rebase", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Diff vs HEAD: $ZED_GIT_REF", "command": "git", "args": ["diff", "--stat", "HEAD", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Log: $ZED_GIT_REF", "command": "git", "args": ["log", "--oneline", "--graph", "-15", "$ZED_GIT_REF"], "tags": ["git-command"] },
 { "label": "Push -u origin: $ZED_GIT_REF", "command": "git", "args": ["push", "-u", "origin", "$ZED_GIT_REF"], "tags": ["git-command"] },
 {
 "label": "Rename: $ZED_GIT_REF",
 "command": "printf 'New name: ' > /dev/tty; IFS= read -r name < /dev/tty; [ -n \"$name\" ] && git branch -m \"$ZED_GIT_REF\" \"$name\"",
 "tags": ["git-command"]
 }
]

六、收尾：三条心法

写法优先：拿不准就整行写 command，别跟 args 拼接较劲
变量即路由：菜单放哪，由变量决定，别硬塞
标签醒目：Delete branch: / Delete tag: 前缀写清楚，右键前瞄一眼就不手滑

记得刷新Git树验证命令效果，如tag添加和删除需要刷新后才能看到效果。

参考资料

Zed Docs — Custom Git Commands — 官方文档，涵盖 git-command 标签、Git 专属变量（$ZED_GIT_SHA、$ZED_GIT_REF 等）、变量过滤规则和示例配置。

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

Fri, 24 Jul 2026 00:00:00 +0000

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

接手维护年代久远的历史项目时，很多人会借助 Coding Agent （例如Claude Code，Codex）生成 CLAUDE.md、AGENT.md，用来定制本地代码辅助规则。这类文件只服务于我个人本地AI开发，不需要同步给团队、不能提交到远程仓库。但历史仓库的 .gitignore 是团队统一维护的，随意新增规则会打乱原有规范，不适合修改；全局gitignore又会让所有项目都屏蔽这两个文件，灵活性太差。

这时最佳方案：使用 git exclude。

极简使用步骤

进入项目根目录，创建对应目录（不存在则自动新建）

mkdir -p .git/info

编辑私有忽略文件 .git/info/exclude，写入两行规则

CLAUDE.md
AGENT.md

保存后即时生效，无需额外Git命令。

核心优势

文件存放在 .git 目录内，不会被Git追踪、推送远程，仅当前本地这份仓库生效；
全程不动仓库里任何公开文件，.gitignore 零改动，不会影响团队所有人；
语法和gitignore完全一致，上手无学习成本。

简单选型对比

项目.gitignore：改公共配置，全员生效，适合团队通用文件，此处不合适；
全局gitignore：全电脑所有仓库统一屏蔽，会误伤其他需要保留CLAUDE.md的项目；
git exclude：单仓库、个人私有屏蔽，完美适配本地AI配置。

结尾小结

所有仅自己使用、不方便改动团队忽略清单的本地文件，优先交给git exclude管理。

用Code Server随时随地打开你的VS Code

Fri, 24 Jul 2026 00:00:00 +0000

用Code Server随时随地打开你的VS Code

想把家里电脑变成一个永远在线的开发环境，出门用 iPad、公司电脑、酒店商务机，只要能上网就能打开「自己那台 VS Code」继续写代码？开源项目 code-server 就是干这个的：它在你的电脑上跑一个服务，把完整的 VS Code 编辑器通过浏览器渲染出来，任何联网设备打开网址就是熟悉的编辑器界面。

下面按「需求描述 → 解决方案 → 配置过程」三步走。

需求描述

典型场景很明确：

代码、环境、插件、终端全都装在自己电脑上，不想到处同步；
不想被设备绑死——iPad、别人的 Mac、网吧 Windows，只要能开浏览器就想直接接着写；
不想为了"换个地方写代码"去买云服务器、搞 SSH 隧道、装客户端。

换句话说，目标是：把电脑上的 VS Code 变成一个网址，任何联网设备访问即用。

解决方案

code-server 会以服务形式跑在你的电脑上，监听一个端口，对外提供 HTTPS 的编辑器页面。访问端不需要装任何东西，浏览器即是客户端。

对外暴露服务时需要一张 SSL 证书，让浏览器走 https:// 而不是被拦截的 http://。code-server 官方在文档里给出了几种证书路线，其中最省事的是 自签名证书（self-signed certificate），前提是：

你的电脑（实例）需要能被互联网访问到；
你不想买域名、也不想用 SSH 端口转发。

需要提前知道自签名证书的几个限制（来自官方文档，务必留意）：

iPad 不支持自签名证书，iPad 上直接访问会失败，详细情况见官方 ipad.md；
自签名证书可能给 code-server 带来一些意外的小问题；
因此官方把它定位成「最后手段（last resort）」——只有在你确实不想买域名 / 无法做端口转发时才用。

如果你能接受这些限制，自签名这条路就足够轻量，继续看配置过程。

配置过程

以下命令基于 code-server 官方文档，目标是在电脑（实例）上启用自签名证书、监听 443 端口，然后通过 https://<你的IP> 访问。

1. SSH 进入你的电脑 / 实例

确认这台机器对公网开放了 HTTP/HTTPS 流量（防火墙、安全组放行 443）。

2. 修改 code-server 配置

code-server 的配置文件在 ~/.config/code-server/config.yaml。用官方给的两条 sed 一键改：开启自签名证书、把监听地址从本机回环改成全网卡 + 443 端口。

# 把 "cert: false" 改成 "cert: true"
sed -i.bak 's/cert: false/cert: true/' ~/.config/code-server/config.yaml
# 把 "bind-addr: 127.0.0.1:8080" 改成 "bind-addr: 0.0.0.0:443"
sed -i.bak 's/bind-addr: 127.0.0.1:8080/bind-addr: 0.0.0.0:443/' ~/.config/code-server/config.yaml
# 允许 code-server 监听 443 这个特权端口
sudo setcap cap_net_bind_service=+ep /usr/lib/code-server/lib/node

sed -i.bak 会同时生成一个 .bak 备份，方便回滚。

3. 重启 code-server

sudo systemctl restart code-server@$USER

4. 浏览器访问

现在在任意联网设备的浏览器里打开：

https://<你的实例IP>

就会看到 code-server 的登录页，输入 config.yaml 里的密码即可进入编辑器。

5. （可选）消除自签名证书的浏览器警告

自签名证书浏览器会报「不安全」并弹警告。官方推荐用 mkcert 生成一张被本机操作系统信任的自签名证书，然后把证书路径填进 code-server 配置里的 cert 和 cert-key 两个字段即可消除警告。

注意：mkcert 让本机信任这张证书，并不等于让 iPad / 其他设备也信任。跨设备无警告访问仍然需要一张正规证书（域名 + Let’s Encrypt 等）。

小结

code-server = 把本机 VS Code 变成网址，浏览器即客户端；
自签名证书路线最省事，但 iPad 不支持、可能伴随小问题，仅当不想买域名 / 不想端口转发时使用；
核心就改两行配置（cert: true、bind-addr: 0.0.0.0:443）+ 一条 setcap + 重启，之后 https://<IP> 即可访问。

Monorepo 按变更自动部署

Fri, 10 Jul 2026 00:00:00 +0000

Monorepo 项目的按变更自动部署

当一个仓库里放了多个子项目，它们共享同一套底层代码，每次推送如果全部重新构建和部署，既慢又浪费构建额度。更好的做法是：改了哪个项目，就只部署哪个项目。

共享代码的困境

典型的 monorepo 目录结构：

my-project/
├── apps/
│ ├── web/ # 主站
│ ├── admin/ # 后台
│ └── docs/ # 文档站
├── packages/
│ ├── shared-ui/ # 公共组件
│ └── utils/ # 工具函数
└── package.json

apps/ 下的三个项目都依赖 packages/ 里的公共代码。公共代码一改，三个项目都可能受影响；但只改 admin 的业务页面，web 和 docs 就没必要动。

思路

在 GitHub Actions 里加一个"变更检测"步骤，判断这次提交改了哪些目录。如果只改了 apps/web，就只构建和部署 web；如果改了 packages/utils，所有依赖它的项目都触发部署。

推送代码 → 检测哪些目录变了 → 只构建和部署变更涉及的项目 → 未变更的跳过

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 # 第一步：检测变更
 detect-changes:
 runs-on: ubuntu-latest
 outputs:
 web: ${{ steps.changes.outputs.web }}
 admin: ${{ steps.changes.outputs.admin }}
 docs: ${{ steps.changes.outputs.docs }}
 steps:
 - uses: actions/checkout@v4
 with:
 fetch-depth: 0

 - uses: dorny/paths-filter@v2
 id: changes
 with:
 filters: |
 web:
 - 'apps/web/**'
 - 'packages/**'
 admin:
 - 'apps/admin/**'
 - 'packages/**'
 docs:
 - 'apps/docs/**'
 - 'packages/**'

 # 第二步：按条件部署
 deploy-web:
 needs: detect-changes
 if: needs.detect-changes.outputs.web == 'true'
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 # ... 构建和部署 web

 deploy-admin:
 needs: detect-changes
 if: needs.detect-changes.outputs.admin == 'true'
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 # ... 构建和部署 admin

 deploy-docs:
 needs: detect-changes
 if: needs.detect-changes.outputs.docs == 'true'
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 # ... 构建和部署 docs

关键设计

变更规则怎么写

每个子项目的 filters 要同时包含自己的目录和公共包目录：

filters: |
 web:
 - 'apps/web/**' # 自己的业务代码
 - 'packages/**' # 公共依赖
 admin:
 - 'apps/admin/**'
 - 'packages/**'

这样公共包一改，所有子项目都会触发部署，不会遗漏。

如果公共包内部也可以区分为"仅 A 项目用"和"B、C 共用"，可以写得更细：

filters: |
 web:
 - 'apps/web/**'
 - 'packages/shared-ui/**'
 - 'packages/utils/**'
 admin:
 - 'apps/admin/**'
 - 'packages/utils/**'

条件跳过

通过 needs 拿到上一步的输出结果，用 if 决定是否执行：

deploy-admin:
 needs: detect-changes
 if: needs.detect-changes.outputs.admin == 'true'

没变化的项目这个 Job 直接跳过，不浪费 CI 时间。

支持手动全量部署

加一个手动触发入口，允许绕开变更检测，强制部署所有项目：

on:
 push:
 branches: [main]
 workflow_dispatch:
 inputs:
 deploy_all:
 description: '强制全量部署'
 type: boolean
 default: false

然后在 Job 的条件里加判断：

if: |
 needs.detect-changes.outputs.admin == 'true' ||
 github.event.inputs.deploy_all == 'true'

前端自动部署模式对比

Fri, 10 Jul 2026 00:00:00 +0000

前端自动部署的几种方式

维护项目的一大痛点就是希望推送代码后自动触发更新部署，对此可以采用 GitHub Actions 设置自动部署的工作流（Workflow），对于前端来说有三种主流做法：

	直传文件	服务器构建	推送仓库拉取
构建位置	CI	服务器	CI
传输内容	静态产物	完整源码	镜像
服务器需装	Web 服务	Docker + 构建工具	仅 Docker
多服务器部署	逐个上传	逐个构建	各自拉取同一镜像
回滚方式	切备份目录	切旧镜像	拉指定 tag 镜像
主要局限	只能静态文件	服务器负担重、多台不一致	需维护镜像仓库

三种模式遵循同一个核心逻辑：构建 → 替换线上 → 出问题可回退。区别只在于构建在哪发生、中间产物是什么。

模式一：CI 构建 + 直传文件

思路

这是最直接的方式。在 CI 里装依赖、跑构建，把产出的静态文件传到服务器站点目录，用新旧目录互换上线。但它的前提是：构建产物是静态文件，丢到 Web 服务器就能跑。如果项目需要以容器方式运行，光传文件没用，得走 Docker 构建。

流程

推送代码 → CI 构建 → SCP 传文件到服务器 → 备份旧目录 → 替换为新文件 → 刷新服务

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - uses: actions/setup-node@v4
 with:
 node-version: '20'
 cache: 'npm'

 - run: npm ci
 - run: npm run build

 - uses: appleboy/scp-action@v0.1.7
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 source: 'dist/*'
 target: '/www/site/dist_new/'
 strip_components: 1

 - uses: appleboy/ssh-action@v1.0.3
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 script: |
 cd /www/site
 BACKUP="backup_$(date +%Y%m%d_%H%M%S)"
 mkdir -p "$BACKUP"
 find . -maxdepth 1 -mindepth 1 ! -name 'dist_new' ! -name 'backup_*' \
 -exec mv {} "$BACKUP"/ \;
 cp -r dist_new/* . && rm -rf dist_new
 ls -dt backup_* | tail -n +6 | xargs -r rm -rf
 nginx -s reload

模式二：传源码 + 服务器构建

思路

模式一只能传最终的静态产物，碰上需要完整源码环境才能构建的项目（比如容器化部署）就行不通。模式二把整个仓库源码传到服务器，在服务器上现场构建、打包成镜像再启动。但这种方式的问题是：服务器必须装上全套构建工具，而且如果有好几台服务器，每台都得各自构建一遍，费时且结果可能不一致。

流程

推送代码 → SCP 传源码 → 服务器上构建镜像 → 停旧容器 → 启新容器

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 deploy:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - uses: appleboy/scp-action@v0.1.7
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 source: '.'
 target: '/opt/project/build/'
 strip_components: 1

 - uses: appleboy/ssh-action@v1.0.3
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 script: |
 cd /opt/project/build
 docker build -t my-app:latest .
 docker stop my-app 2>/dev/null || true
 docker rm my-app 2>/dev/null || true
 docker run -d --name my-app -p 3000:80 --restart=always my-app:latest
 docker image prune -f

模式三：CI 构建镜像 + 推送仓库 + 服务器拉取

思路

模式二让服务器承担了构建任务，服务器多了就成问题。模式三把构建和部署彻底分开：CI 里构建好镜像，推到镜像仓库；服务器不再参与构建，只需要拉取镜像、替换容器。这样每台服务器拿到的都是同一个镜像，构建环境统一在 CI 里，服务器只管运行。

可以考虑 GitHub Container Registry 托管镜像，其与 Actions 无缝集成，登录直接用 GITHUB_TOKEN 即可。

流程

推送代码 → CI 构建镜像 → 推送到镜像仓库 → 服务器拉取镜像 → 停旧容器 → 启新容器

示例

name: Deploy

on:
 push:
 branches: [main]

jobs:
 build-and-push:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - uses: docker/login-action@v3
 with:
 registry: ghcr.io
 username: ${{ github.actor }}
 password: ${{ secrets.GITHUB_TOKEN }}

 - uses: docker/build-push-action@v5
 with:
 context: .
 push: true
 tags: |
 ghcr.io/${{ github.repository }}:latest
 ghcr.io/${{ github.repository }}:${{ github.sha }}

 deploy:
 needs: build-and-push
 runs-on: ubuntu-latest
 steps:
 - uses: appleboy/ssh-action@v1.0.3
 with:
 host: ${{ secrets.HOST }}
 username: ${{ secrets.USERNAME }}
 key: ${{ secrets.PRIVATE_KEY }}
 script: |
 docker pull ghcr.io/${{ github.repository }}:latest
 docker stop my-app 2>/dev/null || true
 docker rm my-app 2>/dev/null || true
 docker run -d \
 --name my-app \
 -p 3000:80 \
 --restart=always \
 ghcr.io/${{ github.repository }}:latest
 docker image prune -f

后端框架选型：Fastify / FastAPI / Spring Boot / Go 怎么选？

Tue, 30 Jun 2026 00:00:00 +0000

我在为一个小型信息管理 Web 项目做后端选型，候选有 Node.js (Fastify)、Python (FastAPI)、Java (Spring Boot)、Go (Gin)。为了不被"听说"带节奏，我读了两篇风格迥异的性能对比文章，把结论提炼出来，并给出针对这类项目的明确推荐。

先说结论：对小型信息管理系统，我会首选 Python (FastAPI)；如果团队是 JS/TS 背景，选 Fastify；只有当你在意单二进制部署或预期流量会快速增长时，才需要认真考虑 Go (Gin)。Spring Boot 对这个量级偏重，除非你本来就是 Java 栈。下面是依据。

一、第一篇：Travis Luong 的单机 wrk 基准测试

来源：FastAPI vs Fastify vs Spring Boot vs Gin Benchmark

这篇是相对"实验室"式的测试：每个框架写一个接口，从 PostgreSQL 查 100 行数据返回 JSON，用 wrk 压 10 秒。作者非常坦诚，多次更新修正了"进程数不对等"等测试缺陷。它的价值不在于绝对数字，而在于揭示了配置对性能的放大效应。

代表性排名（req/sec，摘自作者的最终榜单）：

排名	配置	req/sec
1	Spring Boot + jdbc（原生）	7886
2	Go + pgx	7517
3	Go + pg + 连接池调优	7388
4	FastAPI + asyncpg + ujson + gunicorn 8w	4831
5	Fastify + pg + cluster 8w（关日志）	4622
8	Express + pg + cluster 8w	4145
10	Gin + database/sql + lib/pq	2966
12	Fastify + pg（单进程）	2184
20	Spring Boot + JPA（ORM）	844

作者自己提炼的几点，比排名本身更值得记：

FastAPI 开箱并不快——必须配上 asyncpg 异步驱动才能发挥，光这一点就能拉开数倍差距。
即使用了 asyncpg，还要换更快的 JSON 库（orjson/ujson） 才能追上 Node.js。
原生 SQL 转 JSON 远快于 ORM——最直观的证据：同样是 Spring Boot，用 jdbc 是 7886，换成 JPA 直接掉到 844，差了近 10 倍。框架的"慢"往往来自 ORM 层，而不是框架本身。
编译型语言（Java/Go）在同等配置下确实比解释型快。
日志会拖性能——Fastify 关掉日志后明显提速。

一句话总结：这篇告诉我们"配置 > 选型"——同一个框架，会不会调，性能能差一个数量级。

二、第二篇：10 亿请求下的"生存测试"

来源：五大主流 Web 框架真实性能对比：10 亿请求下谁能幸存？

这篇更"生产化"：谷歌云 4 核 16G、Docker 部署、PostgreSQL 连接池，用 wrk2 把流量从 100 RPS 一路爬到 10 万 RPS，同时观察吞吐、延迟、内存、CPU、错误率。

核心数据：

框架	持续稳定 RPS	峰值内存	99% 延迟	CPU 峰值	错误率(10万RPS)
Rust (Actix-Web)	110,000	250 MB	7 ms	75%	0.01%
Go (Gin)	105,000	190 MB	10 ms	68%	0.03%
Node.js (Fastify)	60,000	650 MB	35 ms	82%	0.5%
Java (Spring Boot)	40,000	1.4 GB	50 ms	88%	0.3%
Python (FastAPI)	8,000	1.2 GB	150 ms	100%	15%

作者的"幸存者"分级：

绝对幸存者 —— Go (Gin)：性能、开发效率、生态三者最平衡，像"AK47"，易上手、耐造。
极限生存者 —— Rust (Actix)：性能天花板，但学习曲线陡，需专业团队。
主流生存者 —— Fastify / Spring Boot：覆盖大多数公司的常规战场。
限定生存者 —— FastAPI：仅在低并发"安全区"（< 1 万 RPS）表现良好，适合数据管道、AI 模型接口。

一句话总结：这篇把极限高并发的天花板拉了出来——系统级语言（Go/Rust）是降维打击，但前提是你真的有那么多流量。

三、两篇放在一起看

两篇文章结论高度一致，但视角互补：

性能天花板：Go ≈ Java(原生) > Node > Python。压到极限时，编译型语言的优势会随并发上升而放大。
资源效率：Go 最省（190MB），Java 最重（1.4GB + 启动 12 秒）。Python 在高并发下反而吃内存（1.2GB）且错误率飙升。
易用性 / 开发效率：恰好与性能排序相反——FastAPI 开发最快、自动文档最香，但抗并发最弱。

关键陷阱：别把高并发结论直接套到小项目上。 第二篇自己也写明，FastAPI 的"安全区"是 < 1 万 RPS——而一个小型信息管理系统，日常峰值大概率在几十到几百 RPS，离这个阈值有两个数量级。在这种流量下，框架本身的吞吐根本不是瓶颈，开发速度、可维护性、文档自动生成才是。

四、针对"小型信息管理系统"的推荐

信息管理系统的典型特征：以 CRUD 为主、中低并发、前后端分离、追求快速交付。这类项目的真正成本不在服务器，而在开发和对接的人力。所以选型权重应该是：开发效率 > 文档/对接 > 部署运维 > 极限性能。

按这个权重，决策如下：

你的情况	推荐	理由
想最快交付、要自动 API 文档给前端	FastAPI	类型提示 + 自动 OpenAPI 文档，信息管理系统的 CRUD 接口几乎"写模型即得文档"；<1万 RPS 安全区绰绰有余
团队是 JS/TS 背景，想前后端同语言	Fastify	比 Express 快、schema 校验内置，前后端类型可复用
追求单二进制部署、运维简单，或预期流量会涨	Go (Gin)	编译成一个可执行文件扔服务器即可，无运行时依赖；两篇文章里都是"绝对幸存者"，未来不会遇到性能墙
已有 Java 栈 / 复杂事务和权限	Spring Boot	生态最全，但启动慢、内存重，对小项目是"用航母运快递"

我的最终选择是 FastAPI。原因很实在：信息管理系统的价值在于"把数据管起来、把接口暴露清楚"，FastAPI 的 Pydantic 模型 + 自动文档把这两件事的成本压到了最低；性能上配 asyncpg + orjson（第一篇验证可到 ~4800 req/s）对小型系统完全是冗余的富余。等哪天流量真涨上来，再按第二篇的指引用 Go 重写核心接口，成本也可控——技术选型从来不是非黑即白，而是匹配当下的战场。

参考来源：

Travis Luong — FastAPI vs Fastify vs Spring Boot vs Gin Benchmark
51CTO — 五大主流 Web 框架真实性能对比：10 亿请求下谁能幸存？

派生模型

Sun, 01 Mar 2026 00:00:00 +0000

派生模型

派生模型，是一个我师兄博士论文用到的科研术语的简写，指的是能派生出所需数据的模型。得到的数据叫做派生数据。但是存在歧义：派生是模型的目的，数据是派生的结果，但容易被理解为动宾结构，即模型是派生的结果。

如果翻译为英文就没有这个问题，不是被派生的模型 derived model，而是用于派生数据的模型 model for deriving data。就像生成模型，可以理解为生成内容的模型，可以生成文本/图片，还可以理解为有一个东西生成了模型。

派生不应该修饰模型，应该修饰数据，所以不应该这样简写。

AI 应该只是工具

Sun, 15 Feb 2026 00:00:00 +0000

AI应该只是工具，辅助人类

只要LLM的底层还是transformer，那么它的本质仍是预测下一个词元（token）。这虽然能让它通过图灵测试，但是不代表它拥有和人类等同的智能。注意我说的是等同，不是同等。等同是完全相同，而同等是指同一水平。图灵测试结果就是通过与否，而没有人关心是如何通过的。就像高考，即使同一套试卷都考了600分，但得分点也不是完全相同的，而只能说有同等水平。

细究起来，LLM和人脑差异巨大，说明LLM的智能和人类的智能在底层上就是截然不同的。

那么我们也不能把AI Agent（智能体）和人类等同起来。我能接受AI Agent和人都是智能体，但不能接受他们是同一种智能体。换句话说，我不会把AI当做人，也不会反过来。

我不会把AI当做有情感的人，不会把它当做我的伙伴或者下属，更遑论恋人。因为我无论怎么攻击他，怎么辱骂他，他也不会真正愤怒或者罢工，它也不会生病，除了打打喷嚏——而这通常是因为光顾它的人太多了，服务繁忙。

横切与竖切

Sat, 14 Feb 2026 00:00:00 +0000

横切与竖切

有一天千海看完动画EVA，冒出来一个想法：人类要是一个整体就好了，几十亿人共用一个大脑，一副身体，这样就能消除人们之间的隔阂。没有猜忌，没有误解的世界该多好啊，所有人都能齐心协力做同一件事。

但现实并非如此，每个人是独立的个体，有各自的大脑和身体，这就注定了人与人之间的想法千差万别。

于是要想与他人达成合作，千海必须了解他人。

但又不可能去认识、了解每个人的所有想法，那太累了。

千海自然而然地想到，通过一些标签给人分类，这不就方便认识他人了么？

人以类聚物以群分，根据一个人的标签，就可以大概了解TA的性格和习惯，然后推测TA的行为。

那么如何给人分类呢？好比切蛋糕，可以竖切，也可以横切。

假如面前有一块榴莲千层蛋糕，竖切是一视同仁，每个人都能吃到顶层的榴莲、奶油和底层的面包；而横切则是把顶层和底层给分开，这显然是一种不平等的切法。

千海观察到：

典型的竖切有：星座、生肖、血型、人种、性别。最近比较火的竖切有：MBTI、居然人与竟然人。

典型的横切有：阶级、阶层、学历、职称。最近比较火的横切有：苹果人与安卓人（已封杀）。

然后千海意识到，现实中是横切与竖切并存，如果只看到竖切或只看到横切，那么难免过于片面。

走，吃面去！🍜

Tue, 03 Feb 2026 00:00:00 +0000

走，吃面去！🍜

新面店

地下一层开了一家新面店，主打是现做牛肉面。我发现大家都喜欢“现做“二字，八成是受了西贝的影响。

这是几周以来最暖和的一个冬日，我约了一个朋友到新面店，想聊聊创业。我们扫开点餐二维码一看，怎么就三款面条，其他都是小吃？不管他了，我的原则就是先吃招牌菜。如果招牌菜都难以下咽，其他的菜更不用试了——这是我在披萨店点了炸鸡之后得出的教训。

现在还不到12点，客流量还不大。此时店里居然只有吧台一样的区域还有座位，没有小桌了，有点尴尬。我们找了地方坐下，发现桌面上有个白色圆柱状的盒子，我打开一摸，居然是抽式湿巾，有点意思。我们脱了羽绒服，忽然发现不知道放哪，回头一看，有专门的衣架，挺有意思。

我们最终点了两份招牌面，面的名字花里胡哨一长串儿，我没记住。我怀疑他们服务员也记不住。

客源不断，我看到几个熟悉的人在等位。

我们一边等面，一边聊创业团队的上限与下限。也就是说，一个创业团队应该怎么配置，才能保证团队既有发展空间，又有托底能力。

上限与下限

我天天在听创始人在吹嘘产品的前景，就像天天打冰美式鸡血，有点疲了。

“包装和吹嘘之间，是不是应该有个分界线？“我举起左手然后是右手，表示这两个概念。

“创始人对外讲的时候，为了拉投资就必须吹啊。投资人看的都是发展前景，不吹大点怎么能叫前景呢。“

“但是也不能一直吹，不落地吧。“

“你说得对，所以团队里还应该有一个人能托底。“他用右手自下而上做了一个托举的手势。

“托底······“

面上桌了，居然只上了一碗。“怎么是一碗一碗做的啊？“

“他这后厨就两个灶坑，肯定做不快。“

透过玻璃确实能看到只有两名厨子在翻炒。

我们背后传过来一个声音：“还有没有座，要不要排队啊？“

面前的服务员皱着眉头，伸出手指着门口说：“你问下那个服务员。“

我们收回目光，继续聊。

“从装修和菜品等等这些地方能看出来，这家店的老板审美是很好的。但我大胆猜测一下，这位老板可能缺乏创业经验。“

“你是说这可能是他第一次做餐饮品牌？为什么这么说？“我抛出这个问题，还没意识到答案就藏在刚才的场景里。

“别看他们现在刚开业，红红火火的。但是他们的服务员体系不成熟，刚才客人问要不要排队，这位服务员自己不知道，居然还要问其他服务员。还有就是出餐时间超过了15分钟。这两点就很难保证未来持续有健康的客流量。“

魔鬼细节啊！初出茅庐的老板很难做到面面俱到，往往没意识到基本的业务不能低于及格线。

“确实，如果我是一个人来的话，等这么久早都没耐心了，可能以后就不来了。“

“这就是下限，要有人能保证培训的服务员是成熟的，保证15分钟以内上菜，而且是香喷喷的，这样才能达到及格线。毕竟客户的耐心非常有限。“

“审美能影响一家店的上限，而服务员体系、出餐速度能决定它的下限。那么对于互联网或者AI公司来说，上限是吹出去的故事，下限是什么呢？我想应该是能保证项目拆分到各个阶段的具体任务，每个任务谁来负责，每个阶段交付什么。“

“你说得对，就是要对每个节点有把控能力。这是工程化能力。“

面上齐了，这面条好像是用了特殊的酱料炒过，吃起来香喷喷的。

吃面！

第一产业

第一产业其实是最赚钱的，不仅是农业，还有林业、畜牧业、渔业。

因为只要给饲料、养料就能长大，投入产出比是很高的。就看愿不愿意脱下长衫。

我姐在老家小县城里，专门把猫咪卖到大城市里的打工人。已经起飞了，从繁育到猫咖，线上线下联动，还开了宠物摄影业务。

她22年毕业，很早就开始养猫，然后在老家一边备考一边给宠物店打工帮忙。后来店长不干了，她把摊子接过来，引进了优质品种，逐渐把生意盘活了。

不但自己有收入，还带上了她妈妈一起干。还在本地找了个会摄影的小哥，拉上大学闺蜜在苏州开了分店。养活了四口人呢。

我想这和她喜欢小动物的天性也是分不开的。

要是我也有一门小生意该多好啊！

A 出来，B 就死了？我还活得好好的！

AI 时代有自己的震惊体。

Gemini 3 横空出世，前端已死！

看多了真是腻了，祛魅了。

Entrepreneur Review 创业复盘

Mon, 26 Jan 2026 00:00:00 +0000

Entrepreneur Review 创业复盘

创业是什么？我在研究生选修课上学习到：创业是将知识变现。但是通过参与一次尚未成功的创业实践，我对创业的理解更加深刻，现在我认为创业是利用极其有限的资源，将知识快速变现的游戏。

资源包括人才、启动资金、技术、人脉、设备。在 AI 创业领域，人才既包括技术人员（如程序员），也包括管理人员（如项目经理），甚至是顾问（如法律顾问）。启动资金可以是自筹，也可以来自投资（如天使投资人）或贷款。技术指的是生产产品需要的技能（如编码技能）。人脉指生意合作伙伴、校友、亲友，是可以拉来投资、人才、渠道等的贵人。设备就是生产产品的设施或工具，最常见的就是服务器、个人电脑、显示器、键鼠等等，当然现在的 coding agent 也算。在创业早期，这些资源往往都是极其有限的，可能只有两三个核心员工，几万块钱启动资金，稀少的人脉，以及几台配置一般的笔记本电脑。

而知识变现指的就是利用已有知识生产产品，然后通过营销渠道卖出去，获得一定的利润。这里的知识主要来自于书籍、论文、博客，之前知识被高等学校、图书馆等垄断，现在互联网和 AI 的爆炸发展也带来了知识的普及，旧时王谢堂前燕，飞入寻常百姓家。而营销渠道相比 30 年前互联网刚兴起的时候已经大为不同。那时候把自己的网页挂到互联网上，大家就能通过搜索引擎看到你的网页，随之看到你的产品。所以流量是浏览器带来的，联系客户的方式通常是邮箱。但现在，流量是推荐算法带来的，联系客户的方式则变成了社交平台、通讯软件。获得利润的方式除了买断，也发展出了打赏、平台分成、广告费用、以及会员订阅费用等多种方式，真是百花齐放。之所以我还加了一个“快速”限定词，是因为现在的市场变化很快，研发周期越来越短，科技产品层出不穷，你如果不够快，就只能被同行干掉，或者只能不断追求差异化而推迟发布产品。

尤其要注意的是，正因为初创公司规模很小，资源非常有限，所以更应该追求快速的变现，快速的回本。大公司资源相对充裕，可以游刃有余地进行知识变现，具体来说就是前期投入大量的人力物力，用很长的时间研发早期不追求利润的产品，而用其他产品的利润或者投资来补贴。当然，如果你有天降贵人拉来大量的投资，你也可以不追求快速变现。我主要是想说，什么样的体量干什么样的事，3个人的团队和 300 人的团队很难一直保持在同一起跑线上。如果老板说只用 3 个人就可以干掉 DeepSeek，那他该吃点溜溜梅了，他没事吧？

我的角色

下面按照时间顺序梳理一下我在团队中担任过的角色。

前端小兵

我最开始只会React，由于业务需要，接触了 Vue 和 Uniapp。现在，常见的组件库（Tdesign、Ant design、ChatUI）和全栈框架（Next.js ）我都熟悉了。我先后维护着许多团队的前端项目，比如简历优化小程序、智能体记忆云平台。

后来 CEO 拿到了投资，开始激进地招募实习生，他认为每一个实习生配一个 Cursor，其产出效率就相当于一个高级工程师。“反正有了 AI ，活儿都很简单了，谁干不是干呢，嗯哼？”

前端组长

公司来了有十几名后端实习生和 3 名前端实习生。CEO 每天的任务就是 10 点钟起来给这些实习生布置任务，相当于要给 20 个智能体下任务指令。但是他验收不过来，而且到后来，实习生常常因为没有任务做而无法上岗。于是开始让小组长来拆任务和验收任务。

我代替 CEO 给 3 名前端实习生拆任务，他们是小黄、小姜和小鹏。我们共同用 uniapp 开发小程序。一开始我还是干劲十足的，因为得到了管理别人的职能。但是整个工作真的特别累，因为我成了一个保姆，每天和三个人沟通非常繁琐，沟通成本太高了，我也受不了。于是我把 Uniapp 小程序项目给项目经理掌握进度，我只负责审阅代码、合并发布。小黄是大三学生，干劲很足，但是干了2个月国庆节就到期离职了。小姜是本科毕业回到老家，线上接活维持生计，性格比较闷，不会主动找人协助，因为家庭原因暂时退出过，后来又继续做前端。小鹏是计算机专业研二，性格一开始比较闷，后来变得主动了些。他由前端转全栈干了挺长一段时间，到了寒假也离职了。

随着业务调整，简历小程序被逐渐放弃，我转向维护一个智能体记忆云平台的控制台、开发文档、落地页的单仓项目（Monorepo）。

MCP 服务维护者

我负责把写好的记忆云服务包裹成 LLM 可以直接调用的服务，这是一种新的产品形态，直接面向开发者。可以发布到各大开发平台的 MCP 市场，用户通过订阅获得密钥，然后开发者就可以持续收费，躺着挣钱。

我得到的教训

技术

一、谨慎使用 Uniapp 开发。

尽管 Uniapp 声称通过编译可以实现“一次开发，到处运行”，但实际开发过程中发现，用它写的小程序体量一大就变得难以维护。

这主要是因为 H5、微信开发者工具、各个手机客户端都有不同的渲染逻辑，注意，安卓、iOS、鸿蒙也有不同的渲染逻辑！这意味着任何一个交互程度略复杂的组件，都要花大量时间精力来打磨，来适配不同终端。而当组件出现意料之外的行为，也很难判断和底层渲染逻辑有什么关系，只能靠 AI 一遍一遍抽卡修复。

因此我明白为什么 Uniapp 的组件生态很少，而且都很简单。怪不得以前听说 Uniapp 只能用来做玩具。

二、人必须终身学习。

为了不被日渐强大的 AI 牵着鼻子走，就必须向先进的 AI 学习，不然项目埋了雷都不知道。因为现在的 coding 模型经常会给出看似正确的代码，但是经不起细看，可能不符合全局逻辑；修复 bug 方面，经常给出临时性的补丁而忽略了长期维护，造成了技术债务。

管理

一、进度管理永远是一件难事。

假如你是给工作项/需求排期的人，那么你不但要知道研发的水平，而且还要了解需求的复杂程度。这样才能给合适的人安排合适的需求，保证迭代/项目按时交付。如果给实习生安排了过难的任务，可能会打击积极性，而且拖慢任务进度；反过来，假如给一个熟练的研发安排了一些初级需求，可能他很快就做完了，然后就没有事情做。

（1）了解研发。你要知道，研发的基础能力除了编码能力，还包括对需求的理解能力、沟通对齐的能力。也就是说，拿到一个需求描述之后，不论是口头的还是书面的，研发是否能迅速拆解成清晰的步骤，是否能对模糊的部分提出疑问，并且主动去找人对接。对技术的掌握倒是其次，因为 AI 的能力越来越强，架子搭好了很快就能实现。

麻烦就麻烦在，基础能力是会变化的。研发可以从过往实现中学习成长，从而越来越熟练，效率越来越高；但也可能因为没有及时积淀，导致能力滑坡。你要及时跟进研发的能力状态。对研发更高的要求是，用优雅的方法而非复杂的方法实现需求。

（2）了解需求。需求的复杂度倒不会因为熟练程度而变化，但需求有合理与否的区别。这是因为资源并非无限，你需要判断在时间和研发力量有限的情况下，到底哪些需求值得当下去做。

要使用何种方式来判断，来排序？这就是你要精进的技能点。

很遗憾，我不认为现在团队里有人点出了进度管理的高级技能点。

二、职责太多不是好事。

进度管理是一种职责，其实谁都可以来承担，当有专人做进度管理时，这就成了一种职位：项目经理。

但初创公司的资源非常有限，大家都希望尽量用更少的人做更多的事，于是大家通常都是多面手，也就是一个人承担多个角色的职责。比如项目经理同时是研发人员，或者产品经理同时是市场营销， CEO 还可以兼任财务。

问题在于，如果一个人身上集中了太多的职责，比如 CEO 兼任了所有的高管职位，那会带来灾难的。

拿我自己来说，假如我担任了过多职责，首先我的作息会无法保证。我必须牺牲部分睡眠时间才能处理这么多事务，这会导致作息混乱，影响我的身心健康。比如心脏、肝脏受损，甚至是鼻炎。长期下去，我的活力会慢慢丧失，身体机能下降，内分泌失调。例如熬灯夜战时，皮质醇持续分泌，导致我误以为夜里效率高。

同时，我每天还要和小伙伴对接，于是团队沟通就会变得非常低效，因为别人不知道我什么时候在线。如果我凌晨3点才睡，下午下午1点才醒，而其他人作息是正常的。那么我收不到上午的消息，只能下午回复消息——我们失去了半天的沟通窗口！

更麻烦的是，我也不能保证每天作息的稳定，因为有时候我要在白天见客户，下午补觉。而且我也不能要求别人的作息和我一样，这不现实。我只能在约定的会议时间内尽量上线，同时一有空就处理工作消息（异步）。

这时候我要怎么办呢？难道要每天都把自己的时间窗口列出来，告诉团队小伙伴？问题是困意袭来的时候我根本控制不住自己的眼皮。还有一个办法就是放权，但是我放权之后只是减少了沟通次数——我仍然需要和组长沟通呀！

还有，我不可能在所有领域都有很高的决策水平，就算我是创始人，我也不可能面面俱到（否则就不需要团队了）。

当我活力逐渐丧失，每天要和海量的人打交道，再加上和 AI 聊天久了，我会认为一两句话描述需求和下判断是 ok 的！

到最后，我难以做出任何长远决策，哪怕是下一周该干什么，都以“没有时间“来逃避。

人才

宁要一个诸葛亮，也不要三个臭皮匠。

刘关张也相当于早期创业团队，他们当时也不会想找三个臭皮匠来做军师吧。

而且人越多，沟通效率其实越低，沟通成本越高。

情怀

情怀可以打动一部分人，但不能打动所有人，这是因为性格不同。

人脉

更好的学校，意味着更好的平台和更牛逼的校友。我要是能早点明白这个道理，也许我高中或者大学期间会更努力一些。

设备

苹果公司的 Mac 系列产品在 AI 时代获得了巨大成功，这是因为它的定位是面向创意性工作的，所以它的生态位和 Windows 不同，现在的生成式 AI 恰恰是解放了之前由于技术门槛过高而不能实现想法的一类人。如果这类人拥有一台 MacBook，那真的是如虎添翼。别的不说，Mac 的类 Linux 环境使得许多命令可以顺畅执行，而 Windows 就麻烦得多。而且 Mac 运行 Docker 也更丝滑，不需要安装 WSL。

可恶的是，内存涨价带动了一波苹果产品全线涨价，换电脑真是肉疼。

我得到的经验

主动出击，推销自己

恰恰因为一个人做不成大生意，所以有无数的团队渴求人才。而每个人的简历上肯定都有一两个闪光点，遇到气味相投的团队时，把最好的一面拿出来，相信自己！

识别人才，善用人才

把团队成员看成一种资源，不同的人有不同的性格和能力，需要有不同的利用方式。

把团队的变成自己的

假如你已经有团队了，一定一定要把团队的能力沉淀、转化为自己的能力。无论是写文档、写代码，还是沟通协作。

总结

我在技术方面已经走得够远了，是时候把技术变现了。

当我认为我不能从团队中学到更多时，我就可以抽身了。

更新于2026年7月10日。

为 Windows 右键添加 VS Code 快捷打开方式

Sun, 19 Oct 2025 00:00:00 +0000

为 Windows 右键添加 VS Code 快捷打开方式

本文介绍如何在 Windows 右键菜单中添加使用 VS Code 快速打开文件和文件夹的方法。

共可添加三种右键菜单功能：

右键点击文件夹：在文件夹上右键，选择"通过VS Code打开"
右键点击文件：在单个文件上右键，选择"通过VS Code打开"
右键点击空白处：在文件夹内空白处右键，选择"通过VS Code打开当前文件夹"

方法有两种，直接重装 VS Code 并勾选安装选项，或者通过注册表手动添加。

方法一：重新安装 VS Code（推荐）

下载最新的 VS Code 安装包
运行安装程序时，确保勾选"将’通过Code 打开’操作添加到Windows资源管理器上下文菜单“选项
完成安装后即可在右键菜单中看到 VS Code 选项

方法二：修改注册表

如果你不想重新安装，可以通过修改注册表，分为手动添加和使用注册表文件：

手动操作：

打开注册表编辑器
- 按 Win + R 键，输入 regedit，回车
为文件夹添加右键菜单
- 导航到：HKEY_CLASSES_ROOT\Directory\shell
- 在 shell 上右键 → 新建 → 项，命名为 VSCode
- 在右侧窗口双击"默认”，输入显示的名称，如"通过VS Code打开"
- 在 VSCode 上右键 → 新建 → 项，命名为 command
- 在右侧窗口双击"默认"，输入 VS Code 的安装路径：
```
"C:\Users\你的用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe" -n "%V"
```
```
"C:\Users\你的用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe" -r "%V"
```
为文件添加右键菜单
- 导航到：HKEY_CLASSES_ROOT\*\shell
- 重复上述步骤 2 的操作
为文件夹空白处添加右键菜单
- 导航到：HKEY_CLASSES_ROOT\Directory\Background\shell
- 重复上述步骤 2 的操作

注意：

-n 是使用新窗囗打开，-r 是使用当前窗口打开
更改了不需要重启电脑
注意大小写，双引号（英文双引号），句号（英文）空格，路径（自身电脑 vscode 打开路径）
OpenWithVSCode 是右键显示的名称，可自行更改， command 是启动命令，不加会无法执行， Icon 是图标，也可自行更改

常见 VS Code 安装路径：

C:\Users\用户名\AppData\Local\Programs\Microsoft VS Code\Code.exe
C:\Program Files\Microsoft VS Code\Code.exe

使用注册表文件：

创建一个 .reg 文件，内容如下：

Windows Registry Editor Version 5.00

; 右键文件夹用VS Code打开
[HKEY_CLASSES_ROOT\Directory\shell\VSCode]
@="通过VS Code打开"
"Icon"="C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe"

[HKEY_CLASSES_ROOT\Directory\shell\VSCode\command]
@="\"C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%V\""

; 右键文件用VS Code打开
[HKEY_CLASSES_ROOT\*\shell\VSCode]
@="通过VS Code打开"
"Icon"="C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe"

[HKEY_CLASSES_ROOT\*\shell\VSCode\command]
@="\"C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%V\""

; 右键文件夹空白处用VS Code打开当前文件夹
[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode]
@="通过VS Code打开当前文件夹"
"Icon"="C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe"

[HKEY_CLASSES_ROOT\Directory\Background\shell\VSCode\command]
@="\"C:\\Users\\你的用户名\\AppData\\Local\\Programs\\Microsoft VS Code\\Code.exe\" \"%V\""

将文件保存为 .reg 格式，双击运行即可。

注意：请根据你的实际 VS Code 安装路径修改上述路径中的用户名部分。

Windows 11 右键菜单配置

在 Windows 11 中，右键菜单分为两种模式：

现代模式：右键显示简化菜单，需要点击"显示更多选项"才能看到完整菜单
经典模式：直接显示完整的传统右键菜单

使用传统的注册表方法无法直接添加到现代菜单中，导致 VS Code 选项只出现在"显示更多选项"中。对此，不想折腾的话可以直接使用 Shift + 右键打开完整菜单，或者一劳永逸地切换到经典模式。最后，还有一种待验证的方法是使用 PowerToys 工具来管理现代菜单。

切换到经典模式

打开注册表编辑器
导航到：HKEY_CURRENT_USER\Software\Classes\CLSID
新建项：{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}
在该项下新建项：InprocServer32
修改"默认"值为空字符串即可

使用 PowerToys 管理现代菜单

PowerToys（微软官方工具）：

从 GitHub 或 Microsoft Store 安装 PowerToys
在设置中寻找右键菜单管理功能
添加 VS Code 到现代菜单

首页 on 武成龙

云原生地理空间智能计算系统

项目概述

核心职责

技术亮点

技术栈

纳福猫舍智能信息管理系统

项目概述

核心功能

技术亮点

技术栈

AICV 简历王小程序

项目概述

核心功能

我的职责

技术栈

智能企业人才评估系统

项目概述

核心功能

我的职责

技术栈

给 RAG Agent 加流式输出：SSE 从设计到落地

一、为什么需要流式

二、方案选型：SSE / WebSocket / NDJSON

三、后端设计：事件协议

四、后端实现

4.1 服务层：async generator 产出事件

4.2 路由层：StreamingResponse + 完整生命周期

五、前端实现

5.1 用 fetch 解析 SSE

5.2 增量渲染

六、踩坑记录：gzip 把流式变成一次性响应

现象

定位

修复：Cache-Control: no-cache, no-transform

七、验证方法

八、小结与后续优化

Apifox 调试 SSE 接口

Zed自定义Git命令

Zed自定义Git命令

一、核心结论

二、三大机制

2.1 入口：命令从哪来

2.2 变量：能自动注入什么

2.3 过滤规则：任务怎么"隐身"

三、三种写法与两个大坑

3.1 三种写法

3.2 大坑一：args 会被"拆碎"

3.3 大坑二：交互输入要绑 /dev/tty

3.4 平台差异

四、命令清单

4.1 提交右键族（Commit 菜单）—— 看、取、派、查

4.2 分支标签右键族（Ref 菜单）—— 引用的增删改查

4.3 通用族（两种菜单都会出现）—— 谨慎添加

五、完整配置（可直接粘贴）

六、收尾：三条心法

参考资料

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

接手老旧项目不用改公共gitignore：用git exclude静默忽略AI配置文件

极简使用步骤

核心优势

简单选型对比

结尾小结

用Code Server随时随地打开你的VS Code

用Code Server随时随地打开你的VS Code

需求描述

解决方案

配置过程

1. SSH 进入你的电脑 / 实例

2. 修改 code-server 配置

3. 重启 code-server

4. 浏览器访问

5. （可选）消除自签名证书的浏览器警告

小结

Monorepo 按变更自动部署

Monorepo 项目的按变更自动部署

共享代码的困境

思路

示例

关键设计

修复：`Cache-Control: no-cache, no-transform`

3.3 大坑二：交互输入要绑 `/dev/tty`