从 GPT-2 到 Kimi K3：大模型记忆系统演进（小白版）
从 GPT-2 到 Kimi K3：大模型记忆系统演进（小白版） [!summary] 一句话理解从 GPT-2 到 Kimi K3，变化不只是模型参数越来越多，更重要的是：AI 逐渐学会了如何保存信息、修改旧信息、忘掉无关信息，以及在需要时找回细节。 一、先把大模型想象成“超级秘书”假设有一名秘书，负责记录一场持续很久的会议。 会议刚开始时，内容不多，秘书可以把每句话都完整保存下来。可是会议越来越长，记录可能达到几万页。此时会出现几个问题： 记录占用的空间越来越大； 每回答一个新问题，都要翻阅大量旧资料； 重要内容和无关内容混在一起； 新信息出现后，旧信息可能已经过时； 只做摘要又可能丢失关键细节。 大模型架构的演进，很大一部分就是在解决这些问题。 二、GPT-2：所有聊天记录都保留下来GPT-2 使用经典的 Transformer 注意力机制。 可以把它理解成： 回答当前问题时，回头查看前面说过的内容，判断哪些信息最重要。 后来，大模型通常会使用 KV Cache。它像一个“聊天记录缓存区”，把已经计算过的信息保存下来，避免每生成一个新词都从头计算。 举个例子用户...
22580: From GPT2 to Kimi3, Explained
Twenty-two thousand five hundred and eighty. That’s how many GPT-2 (2019) models fit inside KimiK3 (2026). We scaled up by a factor of 22,580 in seven years. But is it just… scale? In this worklog, I’ll walk through how we got here and how much, or how little, has actually changed since then. We’ll trace the major architectural developments leading to KimiK3. GPT-2GPT-2 is a decoder-only architecture: 12345678tok_emb = self.transformer.wte(idx) # token embeddings of shape (b, t, n_embd)pos...
客户端Tab预热分析
结论：Android 可行，鸿蒙可行，只预热部分 Tab 更推荐。但三端不要简单照搬 iOS 的实现方式，应该抽象成统一策略：Tab 预热策略层 + 各端 WebView/ArkWeb 适配层。 1. Android 是否可行？可行。 Android 上可以提前创建 WebView，提前执行 loadUrl()，用户切 Tab 时直接复用这个 WebView 或承载它的 Fragment/容器。 但 Android 和 iOS 有几个关键差异： 点 iOS WKWebView Android WebView 提前创建实例 可行 可行 不上屏就加载 URL 可行 可行，但要注意页面尺寸、JS、渲染时机 真正“预渲染” 可以离屏加载 传统方案不稳定，推荐结合 AndroidX WebKit 新能力 多个 WebView 内存压力 高 更高，尤其低端机明显 生命周期释放 stopLoading / nil 必须 removeView 后 destroy() Android 官方 WebView.loadUrl() 就是加载指定 URL...
DevSpace_ChatGPT_MCP_接入指南_脱敏版
DevSpace 接入 ChatGPT：本地项目 MCP 连接指南 适用目标：将指定的本地代码目录通过 DevSpace 暴露为 MCP 服务，并连接到 ChatGPT，使其能够在明确授权范围内读取文件、检索代码、执行终端命令与修改代码。 本文已移除实际项目名、本机用户名、真实目录、真实公网地址与密码，统一使用占位符表示。 1. 接入架构与边界12345678910ChatGPT 自定义 MCP 应用 │ HTTPS（公网） ▼Cloudflare Tunnel / 其他 HTTPS 隧道 │ 转发至本机 127.0.0.1:<LOCAL_PORT> ▼DevSpace MCP Server │ 仅允许访问 configured roots ▼<PROJECT_ROOT> DevSpace 是运行在开发机上的本地 MCP 服务。它允许 MCP 客户端在已授权的项目根目录内进行文件读写、代码搜索和 Shell 命令执行。 因此，应将它视为“受限的远程开发权限”，而不是普...
别只研究 Prompt 了，AI Agent 真正的变化在 Loop
最近 Latent Space 的 AINews 提到一个词：Loopcraft，直译过来大概是“设计循环的手艺”。这个说法听起来有点新，但它指向的问题并不玄。 很多人使用 AI 工具，第一反应还是去找更好的 Prompt：怎么描述更清楚，怎么让模型少废话，怎么让它一次输出更完整。Prompt 当然重要。但到了 Agent 工具这里，真正影响效率的，往往不再是一句话写得多漂亮，而是任务有没有被组织成一个可以反复执行、可以检查、可以修正的循环。 举个开发里的小场景。 你可以对 AI 说：“帮我修这个 Bug。”它可能会读一段代码，给出一个修改建议。但更稳定的做法不是一句话结束，而是把任务设计成一条循环：先复现问题，确认失败测试；再定位原因，修改最小范围代码；然后跑测试；如果测试失败，就带着错误信息回到上一轮；如果测试通过，再输出变更说明，交给人 Review。 这时 AI 不再只是回答问题，而是在一个受约束的流程里持续推进。这里的差别，就是 Prompt 和 Loop 的差别。 本文基于 Latent Space 的 Loopcraft 讨论、Anthropic 关于 agenti...
客户端隐私合规治理方案一页纸
一、从客户端角度，重点解决四类问题1. 采集前是否合法解决用户未同意前采集、SDK 偷跑、H5 提前调用原生能力、敏感信息未单独同意等问题。重点确保：先告知、再同意、后采集。 2. 采集中是否最小必要解决权限提前申请、频繁申请、场景不匹配、SDK 超范围或高频采集等问题。重点确保：当前场景需要什么，客户端才申请什么、采集什么。 3. 采集后流向是否透明解决采集数据不必要回传、发往第三方不可见、实际采集与隐私政策不一致等问题。重点确保：采了什么、传给谁、是否已声明，都能说清楚、查得到。 4. 用户选择是否真实有效解决默认勾选、诱导话术、误导跳转、自启动、关联启动、剪切板静默读取等问题。重点确保：用户可感知、可选择、可拒绝。 二、整体实施分四个阶段第一阶段：先梳理，建立合规底账先把客户端现状摸清楚。主要做： 梳理业务场景：登录、开户、人脸、扫码、定位、H5 活动等。（业务配合） 梳理每个场景用到的客户端能力：权限、SDK、JSBridge、剪切板、外跳、网络接口。 梳理采集信息和数据流向：采什么、传哪里、是否第三方。 对照隐私政策、SDK 清单、个人信息清单，找出差异。 阶段产...
Claude 用户五级进阶：从搜索框到可编程系统
先把 credit 放前面：这篇整理来自 NerdHack / Nate Herk 的 YouTube 视频《Every Level of Claude Explained in 21 Minutes》。 https://www.youtube.com/watch?v=ZRb7D6R64hM&t=17s 最近看了 Nate Herk 这个 21 分钟视频，受益匪浅。他自己在 Claude 里泡了 400 小时，把用户分成了 5 级。下面是我看完之后的整理和思考，credit 全归 Nate。分级本身没什么稀奇，真正值得讲的是「卡点」。每一级跨到下一级，卡住的往往不是技能，而是心智模型。 Level 1：一次性问答能解决当下问题，但不会形成长期杠杆。 Level 1：把 Claude 当搜索引擎 典型用法是一次性问答：你问，它答。关掉页面，关系结束。下一次再来，又从零开始解释背景。这一层不是不好，大部分人第一次接触 AI 本来就是从「更会说话的搜索框」开始。但如果一直停在这里，Claude 只能回答当下问题，不能持续理解你是谁、你在做什么、你怎么判断好坏。卡点...