以前，我们试图通过无休止地堆砌和调优“提示词（Prompt Engineering）”，来约束和掌控 AI 的行为边界。然而，这种“把所有规则塞进同一个大喇叭里”的粗暴做法，很快就遇上了两大瓶颈：

• 上下文污染（Context Pollution）带来的“指令失焦”。 为了防范各种极端的边界 Case，开发者的 System Prompt 动辄膨胀到数万 Token。结果大模型的注意力被严重稀释，常常顾此失彼，出现严重的“指令漂移”甚至幻觉。

• 业务资产被“死锁”，复用成本极高。 那些耗费大量精力打磨的复杂业务逻辑，被死死地硬编码在了特定的代码仓库或对话记录中。跨项目迁移、跨团队共享几乎是不可能完成的任务。

Agent Skill 是 Anthropic 于 2025 年确立的开放式 AI 代理构建标准。其本质是将复杂的 Prompt 工程、外部知识库（Reference）与执行逻辑（Script）封装为标准化的本地文件结构（通常以 SKILL.md 为核心）。

它的核心技术突破在于渐进式披露（Progressive Disclosure）架构：模型不再需要一次性读取所有背景设定，而是仅在推理过程中，根据当前任务的意图动态挂载必要的规则片段或数据引用。

在前端开发中，一次性渲染大批量数据的列表是性能杀手。一次性创建数万个 DOM 节点，导致浏览器样式计算和布局耗时巨大，会造成首屏加载白屏、滚动严重掉帧。可以使用虚拟滚动 进行优化。

1.核心思想：只渲染用户“看得见”的那部分 DOM 元素

想象一个滚动的长条，虽然数据有 10000 条，但用户的屏幕（视口）只能看到 10 条。我们只需要创建这 10 个节点的 DOM，随着滚动动态更新它们的内容和偏移量。

在前端开发中，经常会有大批量文件上传的需求。在面对“数千张高清图片批量上传”的需求时，传统的前端上传方案往往会出现各种各样的问题：

• 一次性全部上传：极易触发服务器 413 Payload Too Large 报错，且巨大的 HTTP 包体容易导致连接超时。
• 暴力循环：瞬间发起数千个 HTTP 请求，不仅会挤爆浏览器的并发限制，导致大量请求排队挂起，还可能瞬间压垮后端服务。

针对这些问题，就需要前端分批上传，下面介绍一下一种支持分组、控制并发、且具备自动重试机制的大批量文件上传策略

1. 核心设计思路

• 分批： 将 大批量文件切分成若干个小批次（比如每批 50-100 个），

时间：2025.10.25 分享人：赵文琦

1 理论体系背景

1.1 问题域

问题：有了LLMs，为什么需要开发大模型应用？

在大语言模型（LLM）如 ChatGPT、Claude、DeepSeek 等快速发展的今天，开发者不仅希望能“使用”这些模型，还希望能将它们灵活集成到自己的应用中，实现更强大的对话能力、检索增强生成 （RAG）、工具调用（Tool Calling）、多轮推理等功能。

最近在训练一个图像篡改检测网络时，为了提升模型的鲁棒性，我对数据集进行了随机 JPEG 压缩作为预处理手段。本以为这只是一个常规的数据增强操作，没想到却引发了一场艰难的 Debug 之旅——模型训练过程中 Loss 突然变成了 NaN。

经过一系列常规排查无果后，最终锁定了混合精度训练与数据分布之间的问题。在此记录下排查思路和解决方法。

训练设置：我使用MMSeg框架的自动混合精度AmpOptimWrapper。

1.代理模式：

代理模式通过引入一个代理对象来控制对原对象的访问。代理对象在客户端和目标对象之间充当中介，负责将客户端的请求转发给目标对象，同时可以在转发请求前后进行额外的处理。

使用场景：

• 当需要在访问一个对象时进行一些控制或额外处理时。

时间：2025.04.21 分享人：赵文琦

1 理论体系背景

1.1 问题域

​ 某些场景下，我们在直接访问对象时可能遇到问题，例如，当需要访问的对象位于远程机器上时，或者某些对象的创建开销很大，又或者某些操作需要安全控制，直接访问这些对象可能会给使用者或系统结构带来诸多不便。代理模式能够处理远程访问、创建开销高、访问安全控制等问题，实现灵活的系统结构。

在 ChatGPT 出现之前，大部分 Web 接口都是“请求-响应”模式：用户发一个请求，服务器处理完（可能需要几秒），然后一次性把结果扔回来。但在大模型时代，生成一段长文本可能需要 10 秒甚至更久。如果让用户盯着空白屏幕等 10 秒，体验会非常糟糕。于是，SSE (Server-Sent Events) 再次回到了聚光灯下。它允许服务器一边生成内容，一边通过长连接把数据“推”给前端，也就是我们看到的“打字机效果”。

1.什么是 SSE？

SSE（Server-Sent Events）是一种基于 HTTP 的单向通信机制。

方案：后端返回完整路由结构，前端动态组件映射

1. 设计思路

1. 初始状态： 路由表中只有“登录页”、“404”等基础静态路由页面。
2. 登录： 用户登录，获取 Token。
3. 获取权限： 前端拿着 Token 请求后端接口，后端返回该用户的菜单树（路由表）。

在 HTTP协议中，客户端必须先发起请求，服务器才能响应。这就像发邮件，你发一封，对方回一封。但如果需要开发一个即时聊天室、股票大盘或者实时视频监控的功能，让客户端每隔几秒钟问一次服务器“有新消息吗？”（轮询），既浪费带宽，延迟又高。WebSocket是解决这个问题的最优解。

一、 什么是 WebSocket？