背景

本文构建了AI术语的三层认知框架（思维层→工具层→应用层），系统解析了token、context、幻觉等底层概念，RAG、Agent、Skill、MCP等工具层能力，以及Gemini、NotebookLM等应用层实践，并强调：理解AI“文字接龙”本质是解构黑话的关键，幻觉不可根治需人机协同校验，掌握分层归类法可从容应对持续涌现的新术语。

主要议题与讨论

主题一：AI术语的三层结构化认知框架

• 思维层（最底层抽屉）：定义AI“如何想”，核心是大语言模型作为概率驱动的“文字接龙高手”——基于前序文本预测下一token；token是AI处理的最小语义单元（中文中“珠穆朗玛峰”“我吃饭”均可为1 token）；context是AI的有限记忆窗口，决定其理解深度与会话长度；幻觉源于接龙过程中的连续微偏移+上下文压缩丢失，本质是概率模型固有缺陷，无法根治，必须依赖人工复核关键数据与来源。

• 工具层（中间抽屉）：定义AI“能帮你做什么”，聚焦能力模块化封装。Prompt是人机交互的“任务说明书”，非魔法咒语，需精准、结构化；RAG（检索增强生成）使AI具备“开卷考试”能力，通过外挂知识库实现可溯源、高精度响应；Agent是工作流自动化载体，能自主规划、调用工具（如Office/白板）、串联input-output模块，实现“长出手脚”式执行；Skill是结构化方法论沉淀（常为Markdown文档），赋予通用大模型特定岗位能力（如“培训专员”），支持跨平台复用；MCP（Model Context Protocol）是Anthropic提出的通用协议，旨在打通不同大模型与应用软件间的调用桥梁，实现跨生态智能操作。

• 应用层（最顺手抽屉）：定义“你具体打开哪个产品用”，即终端工具。高频使用Gemini（含NotebookLM）、Google Slides AI、Gemini for Workspace（用于数据分析洞察）、AI视频工具等；所有应用均依赖底层模型+工具层能力组合，不同产品集成RAG/Agent/Skill的程度各异，用户感知的是开箱即用的功能（如一键生成PPT、万行数据洞察）。

主题二：落地应用的关键原则与典型场景

• PPT生成场景：可行但需前置结构化输入——明确背景、目标受众、大纲逻辑、品牌规范（配色/字体）、参考素材；单句指令（如“生成一套片子”）必然失败，本质是AI辅助“内容生产流水线”而非全自动创作。

• 数据分析场景：Gemini for Workspace可高效处理谷歌表格中上万行数据，自动提炼Data Insight（趋势、异常、关联性），显著提升分析效率，但需人工验证结论合理性。

• 日常协作场景：基于NotebookLM定制SOP查询、合同审查等RAG应用；团队普遍通过Skill封装常用模板（如会议纪要格式、周报框架），通过Agent固化审批流、报告生成等高频工作流。

主题三：应对术语爆炸的理性策略

• 新词（如Loop Engineering）本质是旧范式在新场景的再包装，90%以上仍归属三层框架内：若涉及自主问题解决框架→归入工具层；若指向具体产品功能→归入应用层；若解释模型机制→归入思维层。

• “黑话地图”的核心价值是提供归类锚点：听到新词时先问“它在解决哪一层的问题？”，再结合“文字接龙”底层逻辑判断其技术实质，避免陷入名词焦虑。

• 学习优先级应按工作刚需倒排：应用层工具（Gemini/NotebookLM）→ 工具层核心能力（Prompt/RAG/Agent）→ 思维层基础原理（token/context/幻觉机制），而非追逐所有新词。

背景

“我们删除了 80% 的 Claude Code 系统提示，这是我们从编写系统提示词、Skill 和 Claude.MD 中学到的。”
随着模型变强，很多提示词不需要了

变化

1. 昔：给 Claude 定规则 → 今：让 Claude 自行判断
2. 昔：给 Claude 举例子 → 今：设计好接口
3. 昔：一股脑全写在前面 → 今：渐进式披露
4. 昔：反复强调 → 今：简洁的工具描述
5. 昔：把记忆写进 CLAUDE.md → 今：自动记忆
6. 昔：简单的规格文档 → 今：丰富的参考材料

组装上下文

顺序如下图：

可以尝试 在 Claude.MD 里减少内容，将相关内容放到skill 或 Reference 中去。

背景

我很喜欢 Hexo 的简洁和网页样式，一直用来更新文章，但其实大家都知道，更新 Hexo 的文章官方没有很优雅的方式，需要人工编辑 markdown 文件 后，手工执行部署命令，虽然也不麻烦，但多了个步骤就多了摩擦，有时本来想写一些东西，由于不方便，就过去了，后来也就没有心情写了。

寻找方案

其实解决方案是现成的，只要提供类似 Wordpress 后台编辑功能，让用户可以保存，修改，并发布文章即可。但由于官方没有提供，我看了一下，第三方也没有特别好的方案，就觉得比较遗憾。自己编一个，好像工程量又太大了。

我的方案

想不到AI来了，这个问题就迎刃而解了。我让 Kimi K3 编写后台，几轮下来，就编了一个基本满足我的需求的方案，可以看一下，就是这个界面：

左边是md文件，中间是编辑界面，右边是预览界面。文件写完，保存，发布。完美解决了我的问题。

项目地址

系统架构概览

需要实现一个双端的应用，其中Web端用Clerk，需要实现微信小程序的调用，打算用下面的架构。

1
2
3

Web端 (Clerk) ←→ 统一后端API ←→ 微信小程序 (自建认证)
                     ↓
                用户映射数据库

1. 数据库设计

用户映射表 (user_mapping)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

CREATE TABLE user_mapping (
  id SERIAL PRIMARY KEY,
  clerk_user_id VARCHAR(255) UNIQUE,
  wechat_openid VARCHAR(255) UNIQUE,
  wechat_unionid VARCHAR(255),
  unified_user_id VARCHAR(255) UNIQUE NOT NULL,
  email VARCHAR(255),
  nickname VARCHAR(255),
  avatar_url TEXT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 为常用查询创建索引
CREATE INDEX idx_clerk_user_id ON user_mapping(clerk_user_id);
CREATE INDEX idx_wechat_openid ON user_mapping(wechat_openid);
CREATE INDEX idx_unified_user_id ON user_mapping(unified_user_id);

Requirement

when user input the front, on background, we need to check this word whether in database. If exists, show warning message under the front.

Overview of the Solution

We’ll modify the CardForm component to perform an asynchronous check whenever the user types in the “front” input. To avoid sending a request to your database on every single keystroke, we will “debounce” the input. This means we’ll wait for the user to stop typing for a brief moment before sending the validation request.

The validation logic itself will be passed to the form as a new prop, onCheckFront. This keeps the CardForm component reusable and separates the form’s UI from the specific database logic.

If the check finds that the word already exists, we will use react-hook-form’s built-in setError function to display a warning message right under the input field.

Decide What to Work On

Ever wish you just had like a shortcut, a way to really get how great work happens in any field?
Yeah, that feeling of wanting the uh the secret sauce, the core principles behind amazing achievements. That’s exactly what we’re diving into today.
We are doing a deep dive into Paul Graham’s essay, How to Do Great Work.
Think of it as trying to find the common threads. You know, the DNA shared by breakthroughs in totally different areas,
right? And our mission here isn’t just to summarize. We want to pull out the really practical stuff, the actionable bits you can use um no matter what you actually do.
Exactly. We want you to walk away with some real aha moments. So, let’s start at the beginning, choosing what to work on. Graham says this is well absolutely vital.
It’s foundational. He argues it has to connect with your natural talent, what you’re genuinely interested in, and importantly offer real scope for doing something, you know, great.
And what’s interesting is he points out that ambitious people often sell themselves short here. They underestimate the potential in things they actually love, right? It’s like you might think, “Oh, this thing I’m passionate about isn’t serious enough.” But Graham challenges that, especially for younger people.
Yeah. Because maybe you haven’t seen enough different kinds of work to know what you’re truly good at or what really clicks.
Exactly. So, how do you figure it out then when you don’t have all that experience?
Well, Graham’s advice is pretty straightforward. The way to figure out what to work on is by working. Simple as that.
So, less thinking more doing
pretty much. Get your hands dirty, start projects, even if they’re just guesses, learn from messing up. That’s part of figuring it out.
And he really emphasizes building a habit around personal projects driven by what he calls excited curiosity.
Excited curiosity. I like that. It’s not just mild interest.
No, it’s that deeper pole, that thing you can’t not explore. That’s your compass, basically.
He’s got this great question, too. What are you excessively curious about? Curious to a degree that would bore most other people.
Mhm. That’s the gold you’re looking for, that niche obsession.
And he talks about how these projects evolve, right, from maybe Lego when you’re a kid
to tackling genuinely unanswered questions in a complex field when you’re older. It’s the same drive just scaled up.
And the hope is over time, what excites you starts to line up with what’s actually important. It grows organically.
You don’t chase importance, you let it emerge from your passion.

Two Sense of Good

we’re tackling a really um unexpected idea from Paul Graham.
The notion that writing which actually sounds good is somehow more likely to be right.
Right. That definitely raises an eyebrow, doesn’t it? It sounds, you know, a bit strange at first.
It does. Like how can the flow of a sentence, the rhythm affect whether the idea itself is, you know, solid?
Like they’re two completely separate things.
Exactly. Like saying, I don’t know, a shiny car must have a good engine. Yeah, but that’s what we’re going to dig into today. We’re looking at Grahams as a good writing to see if there’s uh something more to this
and figure out what practical insights you, the listener, can maybe take away for your own work, your own writing.

背景

在编写 NextJS 应用时，经常会出现需要在不同页面跳转，但希望能传输一定的数据，保持页面连续。在 Next.js App Router 中，有几种主要的方式可以在网页之间传输多个数据。选择哪种方式取决于你要传输的数据类型、大小以及是否需要在服务器端或客户端获取数据。

以下是几种常用的方法，我会详细解释并提供代码示例：

1. URL 查询参数 (URL Query Parameters)
2. 动态路由参数 (Dynamic Route Parameters)
3. 客户端本地存储 (LocalStorage / SessionStorage)

3.客户端本地存储 (LocalStorage / SessionStorage)

LocalStorage 和 SessionStorage 是浏览器提供的 Web Storage API，允许你在用户的浏览器中存储键值对数据。LocalStorage 会一直保留数据直到被清除，而 SessionStorage 只在当前会话期间有效（浏览器关闭即丢失）。这种方法适用于需要在页面刷新或导航后仍然保留的数据，但仅限于客户端。

优点:

• 可以存储更多数据，不像 URL 参数有长度限制。
• 数据不会暴露在 URL 中。
• 数据在页面刷新后仍然存在 (LocalStorage)。

缺点:

• 只能在客户端使用，无法在 Server Component 中直接访问存储的数据来渲染初始页面。
• 不适合存储敏感信息。
• 用户可以清空存储。
• 存储容量有限制（通常 5-10MB）。

适用场景:

• 记住用户在上次访问时的选择或状态 (例如，购物车内容 - 更复杂的应用通常用后端或更高级的状态管理)。
• 在多个步骤的表单中暂存数据。
• 存储用户的 UI 偏好设置。

背景

在编写 NextJS 应用时，经常会出现需要在不同页面跳转，但希望能传输一定的数据，保持页面连续。在 Next.js App Router 中，有几种主要的方式可以在网页之间传输多个数据。选择哪种方式取决于你要传输的数据类型、大小以及是否需要在服务器端或客户端获取数据。

以下是几种常用的方法，我会详细解释并提供代码示例：

1. URL 查询参数 (URL Query Parameters)
2. 动态路由参数 (Dynamic Route Parameters)
3. 客户端本地存储 (LocalStorage / SessionStorage)

2.动态路由参数 (Dynamic Route Parameters)

动态路由允许你在 URL 路径中嵌入可变的数据段，用于表示特定资源。例如，/users/[id] 路由可以捕获 /users/1 或 /users/abc 中的 id 部分作为参数。你可以创建多层级的动态路由来传递多个参数 (/products/[category]/[item])。

优点:

• URL 结构更清晰，语义化更好，通常用于表示资源的层级关系。
• 参数直接成为路由的一部分。
• 可以在服务器端和客户端获取参数。

缺点:

• 参数数量和结构需要在文件系统中预先定义好。
• 不适合传递可选的、数量不固定的数据。

适用场景:

• 显示特定用户信息 (/users/123)
• 显示特定产品详情 (/products/electronics/iphone-13)
• 博客文章详情 (/blog/my-first-post)

背景

在编写 NextJS 应用时，经常会出现需要在不同页面跳转，但希望能传输一定的数据，保持页面连续。在 Next.js App Router 中，有几种主要的方式可以在网页之间传输多个数据。选择哪种方式取决于你要传输的数据类型、大小以及是否需要在服务器端或客户端获取数据。

以下是几种常用的方法，我会详细解释并提供代码示例：

1. URL 查询参数 (URL Query Parameters)
2. 动态路由参数 (Dynamic Route Parameters)
3. 客户端本地存储 (LocalStorage / SessionStorage)

1.URL 查询参数 (URL Query Parameters)

这是在页面之间传递少量、非敏感数据的最常见和灵活的方式。数据以键值对的形式附加在 URL 的问号后面 (?key1=value1&key2=value2)。

优点:

• 实现简单，易于理解。
• 可以在服务器端和客户端获取数据。
• 用户可以直接修改 URL 参数，方便分享或书签。
• 可以传递多个不同的数据字段。

缺点:

• URL 长度有限制，不适合传递大量数据。
• 数据暴露在 URL 中，不适合传递敏感信息。
• 只能传递字符串类型的数据（数字、布尔值等需要转换）。

适用场景:

• 搜索结果过滤 (/products?category=electronics&sort=price)
• 分页 (/articles?page=2&limit=10)
• 传递简单的用户偏好或状态 (/settings?theme=dark)
• 在不同页面间传递 ID 或标识符