最近看到一篇关于规范驱动开发的文章，作者指出一个有趣的现象：规范也是文档，而文档总是过时的。

这话说的没错，但我有一点点不同看法。规范驱动开发不是过时了，而是在AI时代进化了。

不过，在讲怎么进化之前，我想先聊一个更底层的问题——为什么有时候规范是最新的，效率还是没提升？

写在前面

几个月前，Lovable增长负责人Elena Verna在播客中提到，她和一个“专业的Vibe Coding师”一起工作——全职，拿工资，却不写代码。这个人叫Lazar。

两周前，主持人终于把Lazar请到了麦克风前。一个半小时的对话，我记了六千字笔记。聊完只有一个感受：关于“AI会不会取代程序员”的争论，其实问错了问题。

真正的问题是：当“把东西做出来”变得无比廉价，什么能力会变得无比稀缺？

Lazar的答案非常直接：清晰度、品味、判断力。下面是他完整的工作流和心法——一个从来没写过一行代码的人，如何成为顶尖的AI原生构建者。

一、一个“Vibe Coder”到底在做什么？

Lazar的职位描述听起来像个玩笑：每天用Lovable把想法推到生产环境，从营销模板到内部工具，从Shopify集成的模版到公司的周边商城——你在官网上买的那件衬衫，就是从他自己搭的商店里卖出去的。

“我做的是我愿意免费做的事情，世界上最好的工作。”Lazar说。

他的角色在公司内部像个“游牧者”：今天在增长团队，明天帮企业组做内部工具，后天又在社区组捣鼓新东西。没有固定的汇报线，只有一个模糊的指令：“这是一个想法，最快速度把它变成现实。”

这听起来像极了一个拿着锤子到处找钉子的疯子。但Lazar说，这恰恰是AI时代的稀缺能力——把模糊的想法，翻译成机器能执行的指令。

二、“我没写过一行代码”——优势还是劣势？

Lazar非常坦诚：在加入Lovable之前，他这辈子没写过代码。最多手敲过几次console.log。

“没有技术背景反而是种优势，”他说，“因为我根本不知道自己‘不该做什么’。”

他讲了个例子：六个月前，社区有人说希望Lovable能做Chrome扩展。技术人员立刻开始解释：我们是React栈，架构不兼容，这很麻烦……但非技术的人只会想：嗯？为什么不行？Lazar直接对着工具说：“基于这个应用给我做一个Chrome扩展。”

结果做出来了。

类似的事还有：社区经理在做演示文稿时随口说了句“如果这是个视频会很酷”，就直接用提示词在Lovable里生成了一个真正的视频——当时连这个功能都没正式上线。

Lazar把这种心态叫做 “积极的妄想”：在被证明不行之前，默认一切皆有可能。

但他也承认，没有技术背景的人容易掉进两个陷阱：

1. 卡住了不知道怎么排障。
2. 搭了个摇摇欲坠的系统，某天突然崩掉，自己完全不知道为什么。

所以他在做的，并不是鼓吹“不学编程”，而是重新定义“学什么”。

三、清晰度，才是真正的编程语言

Lazar反复强调一个观点：AI输出比人类快得多，瓶颈早就不在“写代码”上，而在“你知道自己想写什么”上。

他把80%的时间花在规划和聊天上，只有20%在执行计划。

“我在优化‘正确的速度’，大多数人在优化‘错误的速度’。”他说。

那什么是“正确的速度”？

Lazar用了一个阿拉丁与灯神的比喻：你一次只能许三个愿望，不是三万个。 LLM的上下文窗口就是你的token预算——你用多少来理解问题、多少来搜索、多少来思考、多少来执行代码，完全取决于你的输入质量。

“如果你只丢一句‘帮我做个应用’，然后抱怨AI生成的东西太丑、太烂、全是bug——那是你自己的问题。你没给工具足够的清晰度，却指望它读心。”

那么，如何获得清晰度？

Lazar的工作流让我大开眼界：

方法一：并行五个项目，让AI自己卷自己

这可能是最反常识的一步。

大多数人的习惯是：一个项目，反复改，反复调，越调越乱。Lazar的做法是：同时开五个Lovable窗口，从五个完全不同的角度起手。

• 第一个：大脑倾倒。想到什么说什么，纯粹探索。
• 第二个：稍微清晰一点，列出大概要哪些页面、哪些功能。
• 第三个：找一张Dribbble截图，丢进去，“做成这个风格”。
• 第四个：找一个现成的代码片段，精确复刻某个组件。
• 第五个：把前四个的“赢家”要素揉在一起。

“很多人问我为什么发货这么快，”Lazar说，“因为我从来不一次只做一个项目。我等一个智能体跑完的时间，足够另四个窗口同时推进。”

等五个版本都跑出来，哪个对、哪个错、哪个好看、哪个好用，一目了然。清晰度不是在脑子里想出来的，是在对比中长出来的。

方法二：用PRD给AI当“导航系统”

一旦方向确定，Lazar会做一件更反直觉的事：停掉所有构建，花一整天写文档。

他至少写四个文档：

1. 主计划（Master Plan）：10,000英尺视角，为什么做这个、为谁做、希望用户有什么感受。
2. 实施计划（Implementation Plan）：高层顺序，先从后端还是前端？表结构怎么设计？API什么时候接？
3. 设计指南（Design Guide）：具体到CSS变量、颜色梯度、字体系统。
4. 用户旅程（User Journey）：用户注册后第一步做什么？第二步做什么？什么算“完成”？

这些文档汇总成一个plan.md或tasks.md，成为项目的“真理源”。

“之后我的提示词就只剩一句话：继续下一个任务。”Lazar说，“我不需要再重复上下文，因为上下文已经全在文档里了。智能体每次启动任务，先读最新版的tasks.md，然后执行，执行完告诉我做了什么、应该怎么测试。”

这就是他说的 “动态上下文迁移”：不是靠聊天窗口的滚动记忆，而是靠持续更新的文档，让token永远分配在“解决问题”上，而不是“回忆我们在干什么”上。

四、卡住了怎么办？Lazar的4x4调试框架

不管你计划得多好，总会遇到bug。Lazar有个简单的 “4x4脱困框架” ，每种方法只试一次：

第一层：让工具自己修。 Lovable、Cursor、Claude Code都有“尝试修复”按钮。很多时候只是个小错，工具自己就能纠正。

第二层：加日志，让它看见问题。 如果工具不知道自己在犯错，它就永远修不好。Lazar的做法是：让工具在关键路径上加console.log，运行一遍，把日志拷回聊天窗口。99%的情况下，这就够了。

第三层：引入外部顾问。 他会把代码库导出到GitHub，然后丢给Codex（或者Claude + RepoMix），只做诊断，不改代码。拿到诊断结论，再回Lovable修复。

第四层：回滚。 很多时候是你自己的问题——提示词写歪了，前提设错了，或者只是累了。回退三步，深呼吸，重写提示。有时候同样的请求再跑一遍，它就过了。

最后还有 “第4.5层”：等bug修好，切到聊天模式问它：“我刚才用了四层才修好。你教我，下一次我该怎么提示，才能一次到位？”

99%的时候，它会给你一个非常好的答案。然后你把答案写进rules.md或项目知识库，从此它就知道“你这个人容易在哪些地方犯错”，下次自动帮你避坑。

五、技术栈不再重要，重要的是品味

访谈后半段，主持人问了一个很多人关心的问题：职业标签会不会失效？程序员、设计师、PM，以后还有区分吗？

Lazar的回答很直接：

“我如果现在有个18岁的弟弟问我该学什么，我可能会说：去当水管工。别读CS了。”

“不是因为工程不重要——我们比以往任何时候都更需要精英工程师来撑住基础设施。而是因为，对于一个18岁的人来说，四年的机会成本太高了。”

他的逻辑是：当“把东西做出来”变得极其廉价，“做出好东西”就变成了稀缺能力。而“好东西”的判断标准，99%与代码无关——是设计、是品味、是对人类情感的理解。

他承认自己最大的成长，来自和Lovable的设计师们一起工作。

“我以前觉得一个渐变就是三个颜色。直到我点开Figma，发现一个看起来‘很简单’的背景，用了50层——不同梯度、不同不透明度、不同叠加模式。那一刻我才明白，原来我一直以为的‘够用’，离‘世界级’有多远。”

他现在甚至会专门做一个应用来“学习设计风格”：波普艺术、玻璃拟态、新粗野主义……每个风格配一组可复制的提示词，公开分享。

“我的安全感不来自职位，也不来自公司，”他说，“来自我知道自己能快速学会新工具、快速理解需求、快速做出有美感的产品。”

六、给每一个想入局的人：从构建开始

访谈的最后，主持人问：如果只能给听众一条建议，你会说什么？

Lazar几乎没有犹豫：

“今天就去构建点什么。”

“不要等自己想清楚。你的想法永远不会自己变清楚。开五个窗口，同时试五个方向。让AI帮你试错，帮你迭代，帮你把模糊变成具体。”

“然后，把你的过程公开。不用等完美，不用等大作品。真实持续的输出，比任何简历都管用。”

他说自己当初进入Lovable，没有投简历，没有内推，只是在X上持续发自己做的小项目、踩过的坑、试过的提示词。公司的人看到了，主动找过来。

“作品就是机会。”他说。

尾声：魔法与够用之间

这场访谈让我印象最深的，是Lazar对“未来竞争力”的定义。

他说，我们正在快速进入一个 “人人都能产出够用”的世界。任何人花两小时，都能用AI搭出一个能跑通的SaaS、一个像模像样的官网、一个带数据库的小工具。

“够用”不再是护城河。

真正拉开差距的，是你能不能做出 “魔法感” ——让用户第一次点开页面时，心里“哇”一声；让同事用你做的内部工具时，感觉“这比市面上的商业软件还顺手”。

而这种魔法感，不来自你会不会写React，不来自你用Supabase还是Firebase，也不来自你的代码有没有遵循SOLID原则。

它来自你的判断力——知道什么该留，什么该砍，什么该磨三天，什么该一键生成。

它来自你的清晰度——能把脑子里那团模糊的、兴奋的、不确定的感觉，翻译成一行行工具能理解的指令。

它来自你的品味——能区分“还行”和“惊艳”，能为了一个渐变叠加层多试二十次，能在所有人都满足于“跑通了”的时候，对自己说：

“还可以更好。”

而这，是AI永远无法外包的能力。

写在前面

最近发现个项目叫 PAI（Personal AI Infrastructure），看了下挺有意思。

核心想法很简单：**把 AI 从”临时工具”变成”持久基础设施”**。

不像 ChatGPT 那种问完就忘，PAI 让 AI 记住你是谁、你在做什么、你之前怎么处理类似问题。用下来最大的感受是：AI 终于不用每次都当陌生人重新认识了。

这篇文章不谈虚的，直接讲怎么搭起来。

说明：以下步骤都是我实际搭建时验证过的，遇到的问题和解决方法也都记录在「踩坑」章节。

一、核心概念（两分钟看完）

1.1 PAI 是什么

1.2 工具栈

关于 Obsidian：用 Obsidian 管理 TELOS 文件的好处是有双向链接和图谱视图，能更直观地看到各文件之间的关系。不过如果你习惯用 VS Code 或 vim，也没问题。

二、安装实战（重点）

我的建议是：先跑起来，再慢慢调。别想着一次把所有配置都搞完美。

路径 A：官方安装器（推荐）

适合想要完整 PAI 功能的用户（Hooks、Skills、Agents、Voice Server 全套系统）。

1
2
3
4
5
6
7
8

# 1. 克隆仓库
git clone https://github.com/danielmiessler/PAI.git ~/Personal_AI_Infrastructure

# 2. 复制配置
cp -r ~/Personal_AI_Infrastructure/Releases/v3.0/.claude ~/

# 3. 运行安装器（8 步向导）
cd ~/.claude && bash install.sh

安装器会自动完成：

• 安装 Bun（如果缺失）
• 创建 TELOS 文件模板
• 注册所有 Hooks 到 settings.json
• 配置 pai 命令别名
• （可选）配置 ElevenLabs 语音服务

路径 B：轻量 DIY（本文重点）

适合只想快速上手核心身份功能的用户——手动创建 TELOS + 配置 CLAUDE.md + Obsidian 可视化。

2.1 创建目录结构

1
2
3
4
5
6
7
8
9
10

# 创建 PAI 基础目录
mkdir -p ~/.claude/USER/identity
mkdir -p ~/.claude/MEMORY/WORK
mkdir -p ~/.claude/MEMORY/LEARNING/SYSTEM
mkdir -p ~/.claude/MEMORY/LEARNING/ALGORITHM
mkdir -p ~/.claude/MEMORY/LEARNING/SYNTHESIS
mkdir -p ~/.claude/MEMORY/LEARNING/SIGNALS
mkdir -p ~/.claude/MEMORY/RESEARCH
mkdir -p ~/.claude/MEMORY/SECURITY
mkdir -p ~/.claude/MEMORY/STATE

创建后的结构：

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

~/.claude/
├── CLAUDE.md         # 主入口
├── settings.json      # 配置文件
├── skills/           # PAI 技能系统
├── hooks/            # 20 个生命周期钩子
├── agents/           # 13 个专用代理
├── MEMORY/           # 记忆系统
│   ├── WORK/         # 工作跟踪
│   ├── LEARNING/      # 学习记录
│   ├── RESEARCH/      # 研究输出
│   ├── SECURITY/      # 安全审计
│   └── STATE/         # 运行时状态
└── USER/
    └── identity/      # TELOS 文件

2.2 配置 Obsidian（可选但推荐）

如果你用 Obsidian 管理 TELOS：

1. 打开 Obsidian，点击「创建新 Vault」
2. Vault 名称：PAI-Identity（或其他你喜欢的）
3. 文件夹路径选择：~/.claude/USER/identity
4. 点击「打开」

这样你的 TELOS 文件就能在 Obsidian 中可视化编辑，还能看到图谱关系。

2.3 创建 TELOS 文件

TELOS 是 5 个核心 Markdown 文件，定义”你是谁”。

先填这 5 个核心文件。下面是我的示例，你可以参考着写自己的：

IDENTITY.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

# Identity

## 基本信息

我是 Gamehu，技术 Leader / 架构师 / 全栈开发者。

## 技术栈

**核心能力**：
- 后端：Java 专家，多年架构设计经验
- 前端：React 为主，熟悉现代前端工程化
- 全栈：能独立完成从数据库到 UI 的完整开发

## 职业定位

- 技术 Leader：负责团队技术方向和决策
- 架构师：关注系统设计、可扩展性、代码质量
- 技术影响力：想建立个人技术 IP，做有影响力的人

## 兴趣领域

**技术前沿**：
- AI / LLM / Agent 开发
- 新技术趋势跟踪和评估
- 工具链优化和工程实践

## 性格特质

- 总想走在技术前沿
- 喜欢了解新事物，但注重实用性
- 不满足于"够用"，追求"优秀"
- 想做一款属于自己的产品（网站/软件）

## 沟通风格

- 简洁直接，不绕弯子
- 实战导向，少谈理论多动手
- 喜欢用代码和示例说话
- 中文思考，中文对话

GOALS.md：

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

# Goals

## 长期愿景（3-5 年）

- 建立技术影响力，做有 IP 的人
- 做一款属于自己的产品

## 中期目标（1 年内）

- 掌握 AI 原生开发能力
- 持续输出高质量技术内容

## 当前项目

- [ ] 完成 PAI 搭建和优化
- [ ] AI Agent 开发实践
- [ ] 技术文章持续输出

SKILLS.md：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# Skills

## 技术能力

### 后端 - 专家级

- **Java**：多年实战经验，Spring 生态深入
- **架构设计**：DDD、微服务、分布式系统
- **数据库**：PostgreSQL、MySQL、Redis
- **DevOps**：Docker、K8s、CI/CD

### 前端 - 精通

- **React**：主技术栈，Hooks 生态
- **前端工程化**：Webpack、构建优化
- **CSS**：Styled Components、Tailwind

### 全栈

- 能独立完成完整功能开发
- 前后端联调、部署都在行

## 正在学习

### AI / LLM

- Prompt Engineering
- Agent 开发（Claude Code、自定义 Agent）
- RAG 原理和实现

### 技术前沿

- 持续关注新框架、新工具

VALUES.md：

1
2
3
4
5
6
7
8
9
10
11
12

# Values

## 核心价值观

- **实用主义**：不折腾，快速验证想法
- **技术追求**：关注代码质量而非炫技
- **影响力**：通过技术输出建立个人品牌

## 决策原则

- **简单优于复杂**：能用简单方案就不过度设计
- **实用优于完美**：先跑起来再优化

BELIEFS.md：

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

# Beliefs

## 关于技术

- 技术是手段，不是目的
- 架构比实现重要
- 代码质量是长期价值

## 关于学习

- 深度大于广度
- 实践驱动学习
- 记笔记，建立知识体系

## 关于 AI

- AI 是增强，不是替代
- 上下文是关键
- 个人 AI 基础设施是未来方向

2.4 更新 CLAUDE.md 主入口

在 ~/.claude/CLAUDE.md 开头添加 TELOS 引导：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

# 你是 Gamehu 的个人 AI 助理

## 你的身份

- 我是 Gamehu，技术 Leader / 架构师 / 全栈开发者
- 核心技术栈：Java（专家级）、React（精通）、架构设计
- 目标：建立技术影响力，做有 IP 的人，梦想做一款自己的产品

## TELOS 数字身份

**在每次对话开始时，先阅读以下 TELOS 文件了解我**：

1. `~/.claude/USER/identity/IDENTITY.md` - 我是谁
2. `~/.claude/USER/identity/SKILLS.md` - 我会什么
3. `~/.claude/USER/identity/GOALS.md` - 我想达成什么
4. `~/.claude/USER/identity/VALUES.md` - 我重视什么
5. `~/.claude/USER/identity/BELIEFS.md` - 我相信什么

## Memory 记忆系统

- 对话中的重要决策和学习，由 Hooks 自动捕获并保存到 `~/.claude/MEMORY/LEARNING/`
- 主动从我过去的对话中学习，记住我的偏好和决策模式
- 当我重复问类似问题时，参考我之前的答案

---
# 任何项目都务必遵守的规则（极其重要！！！）

2.5 配置 pai 命令别名（可选）

在 ~/.zshrc 末尾追加：

1
2

# PAI 命令别名
alias pai='cd ~/.claude && claude'

然后重新加载配置：

1

source ~/.zshrc

2.6 验证配置

重启 Claude Code，然后问：

1

你知道我是谁吗？

如果 AI 能正确回应你的身份信息（根据 IDENTITY.md），说明配置成功了。

三、核心组件详解

3.1 Memory 系统 v7.0

PAI v3.0 使用新的 Memory 架构（取代旧的 hot/warm/cold 模型）：

数据流：

1
2
3
4
5
6
7
8
9

用户请求
    ↓
Claude Code projects/ (原生会话存储)
    ↓
Hooks 自动捕获：
    ├── AutoWorkCreation → WORK/
    ├── ResponseCapture → WORK/, LEARNING/
    ├── RatingCapture → LEARNING/SIGNALS/
    └── WorkCompletionLearning → LEARNING/

3.2 Skills 系统

PAI 内置 39 个 Skills，涵盖思考、研究、开发、安全等全领域：

使用方式：在对话中直接调用，例如 /science、/telos、/fabric。

3.3 Hooks 系统

Hooks 在特定生命周期事件时触发，自动执行相应逻辑。PAI v3.0 有 20 个 Hooks：

Hooks 是 TypeScript 脚本，需要 Bun 运行时来执行。这就是为什么安装 Bun 是必需的。

3.4 Agents 系统

PAI 提供 13 个专用 Agent，每个都有明确的 persona 和专长：

四、日常使用

4.1 常用 Skills

4.2 典型工作流

1

启动 Claude Code → AI 加载 TELOS → 执行任务 → Hooks 自动捕获学习

五、踩坑记录（实战验证）

5.1 Bun 未安装

问题：Hooks 是 TypeScript 脚本，执行需要 Bun。如果 Bun 没有安装，Hooks 无法运行。

解决：

1
2
3

curl -fsSL https://bun.sh/install | bash
source ~/.zshrc
bun --version  # 验证安装

5.2 Memory 目录未创建

问题：首次使用时，MEMORY/ 下的子目录（WORK/、LEARNING/ 等）不存在，Hooks 会报错。

解决：

1
2
3
4
5
6
7
8
9

# 创建完整的 Memory v7.0 目录结构
mkdir -p ~/.claude/MEMORY/WORK
mkdir -p ~/.claude/MEMORY/LEARNING/SYSTEM
mkdir -p ~/.claude/MEMORY/LEARNING/ALGORITHM
mkdir -p ~/.claude/MEMORY/LEARNING/SYNTHESIS
mkdir -p ~/.claude/MEMORY/LEARNING/SIGNALS
mkdir -p ~/.claude/MEMORY/RESEARCH
mkdir -p ~/.claude/MEMORY/SECURITY
mkdir -p ~/.claude/MEMORY/STATE

5.3 Hooks 未注册

问题：Hooks 文件存在但没有在 settings.json 中注册，导致不会触发。

解决：确保 settings.json 中包含完整的 hooks 配置（参考官方模板）。

5.4 TELOS 路径错误

问题：CLAUDE.md 中引用的 TELOS 文件路径与实际位置不符。

检查：

1
2

ls ~/.claude/USER/identity/
# 应该看到 IDENTITY.md, SKILLS.md, GOALS.md, VALUES.md, BELIEFS.md

5.5 图片文件名不匹配

问题：Hexo 的 asset_img 标签引用的文件名与实际文件名不一致。

解决：确保引用名称与实际文件名完全一致（包括扩展名）。

六、Obsidian 进阶配置

如果你用 Obsidian 管理 TELOS，有几个插件值得装：

一个小技巧：在 Obsidian 中设置 [[GOALS]] 为首页，每次打开都能看到当前目标。

七、延伸思考

PAI 让我重新思考了 AI 的使用方式。

以前把 AI 当”临时工”，用完就扔。现在更像”长期助理”，相处越久越懂你。

关键区别：不是模型更强，而是上下文更完整。

当 AI 知道你的背景、理解你的目标、记住你的决策历史，它给出的建议就不再泛泛而谈，而是真正贴合你的情况。

这才是”个人” AI 的含义。

八、参考资源

• PAI 官方仓库
• 原推文 - @vista8 对 PAI 概念的深入解析
• PAI v3.0 Release Notes
• Obsidian 下载

最后

没有银弹。

PAI 不是万能药，它只是一个框架，让你更系统地使用 AI。

真正有价值的是：你有意识地构建自己的数字基础设施，而不是每次都从头开始。

写在前面

对于 AI 的重度用户或初级开发者来说，经常会混淆：到底什么是“规则”，什么又是“技能”？ 当 Anthropic 推出 MCP 协议后，这层关系变得更加扑朔迷离。
这篇旨在尽量简单生动的理清这四个概念。

一、概念定义：AI Agent 的四层架构模型

构建成熟可用的 AI 智能体应用，核心在于协调四大要素形成闭环链路。各层级各司其职、层层支撑，既明确边界又深度协同，共同构成智能体稳定运行的核心骨架。

1. Skills（能力层）—— 破解“做得到”的可行性难题

• 技术定义：Skills 是 AI 智能体的显性能力外延，核心落地形态为 Function Calling（函数调用） 与 External Tools（外部工具集成），是智能体突破自身能力边界、落地实际操作的关键载体。

• 核心职能：大语言模型（LLM）通过 JSON Schema 描述符，精准解析工具的功能范围、参数规范及返回格式，打破自身训练数据的时空限制，实现从“文本生成”到“落地执行”的核心跨越。

2. Rules（控制层）—— 筑牢“不越界”的合规性底线

• 技术定义：Rules 是智能体的运行准则与风格锚点，通常通过 System Prompt（系统提示词） 硬编码或 Guardrails（护栏系统） 部署，形成刚性约束框架，划定运行边界。

• 核心职能：以确定性逻辑约束随机性模型的输出，在生产环境中承担三大核心职责——安全性防护（Safety）、品牌调性统一（Tone）、输出格式标准化，从根源上规避模型“幻觉”与违规风险。

3. Prompt（调度层）—— 打通“懂需求”的意图性链路

• 技术定义：Prompt 是用户意图与模型上下文的实时动态组合体（Context Window），是指令传递、需求转化与场景激活的核心媒介。

• 核心职能：在 Rules 划定的约束框架内，精准捕捉并转化用户需求，按需激活对应 Skills 工具，实现“需求-能力”的精准匹配，驱动任务全流程推进。

4. MCP（协议层）—— 破解“连得上”的连接性瓶颈

• 技术定义：Model Context Protocol（模型上下文协议，简称 MCP） 由 Anthropic 牵头发起，是聚焦智能体与异构数据源互联适配的开放技术标准。

• 核心职能：实现数据源（Resources）与模型端的解耦设计，通过标准化接口让 AI 智能体“即插即用”访问各类数据资源（数据库、本地文件、SaaS 应用等），是 Context-as-a-Service（上下文即服务） 模式落地的核心基础设施。

二、场景推演：以“AI 数字化导游”为例

为具象化四大模块的协同逻辑，我们以“AI 商务出行助手”（原“数字化导游”适配场景）为例，拆解智能体响应商务需求的全流程运行链路：

用户输入（Prompt）：“我下周三要去上海出差，帮我结合日程表规划通勤路线，并订一张符合要求的机票。”

三、架构特征对比表

为进一步明确四大维度的定位差异，通过核心特征对比，助力开发者精准把握各模块的设计重点与落地优先级：

现在，有一个更优雅的解决方案：**Skills.sh**。它正在把 AI 的能力标准化，让你像安装 npm 包一样，一键给你的 AI 助手增加“神技”。

🚀 什么是 Skills.sh？

Skills.sh 是一个开放的 AI 智能体技能生态系统。它允许开发者将特定的领域知识、操作指令和最佳实践封装成“Skills（技能）”。

通过一行简单的命令，你就可以把这些技能安装到你的 AI 开发环境（如 Cursor, Trae, Windsurf, Claude Code 等）中。

核心操作命令

1
2
3

# 安装一个特定的技能
npx skills add <owner/repo>

💎 GitHub 明星技能库大盘点

Skills.sh 本身是一个聚合器，真正的力量来自于 GitHub 上那些被“开源精神”填满的仓库。以下是目前最值得关注的三个顶级仓库：

1. 📂 everything —— 全能的工具箱

如果你不知道装什么，先看 everything。它致力于覆盖开发者日常的方方面面。

• 核心价值：从文件处理、代码重构到 UI 组件设计，它试图通过一套标准让 AI 处理“任何事情”。
• 推荐技能：everything/refactor, everything/ui-polish

2. 😎 awesome-agent-skills —— 精选推荐集

类似于我们熟悉的 GitHub Awesome 列表，这里汇集了社区中经过验证的高质量技能。

• 核心价值：它是技能界的“米其林指南”。如果你追求稳定和官方认可的实践，这里是首选。
• 推荐内容：涵盖了针对 React、Rust、PostgreSQL 等各个领域的专家级配置。

3. ⚡ superpowers —— 赋予 AI “思考逻辑”

这是我个人最推崇的库。它不只是教 AI 写代码，而是教 AI “如何思考”。

• 核心价值：注入了深度的工程化思维。
• 明星技能：
• superpowers/systematic-debugging: 让 AI 按照逻辑排除法寻找 Bug，而不是乱猜。
• superpowers/planning: 强制 AI 在动工前先写技术方案，这对于复杂重构至关重要。

🛠️ 如何集成到你的工作流？

作为一名研发负责人，我推荐以下集成路径：

A. 针对个人开发者（Cursor 用户）

在你项目根目录下执行：

1
2

npx skills add vercel-labs/agent-skills

这会在你的项目里生成或更新 .cursorrules 文件，让 Cursor 自动感知并遵循 Vercel 级别的开发标准。

B. 针对团队协作

你可以创建自己公司的专属 skills 库。

1. 将常用的 API 异常定义、多租户处理逻辑封装成 Skill。
2. 团队成员统一安装。
3. 效果：AI 写的每一行代码，都像是你团队的老员工写出来的。

结语

Skills.sh 的出现标志着 AI 辅助开发进入了“模块化”时代。我们不再需要去记复杂的 Prompt 技巧，而是通过社区共建，直接复用全球最顶尖开发者的思维模型。

如果你还没试过，建议现在就去 skills.sh 寻找适合你的那款“超能力”。

写在前面

我评审了团队里几位研发程师提交的《xx详细设计》。

在评审数据库设计（Schema Design）部分时，我们针对“资产表的独立性”、“复杂 JSON 的存储策略”以及“列表查询性能”展开了几轮讨论。起初他的设计偏向于“开发省事”，而我更强调“业务边界”和“长期可维护性”。这样的场景在我职业生涯中其实遇到好多次，虽然每次可能都稍有不同但是我个人认为核心考量规则是不变的。

这次讨论非常有代表性，不仅解决了一个具体的业务场景，更折射出 SaaS 系统设计中通用的取舍逻辑。复盘如下，与大家分享。

摘要：在现代 SaaS 架构中，越来越多的业务场景需要依赖“外部异步工作流”来生成核心数据（例如：调用一个耗时的分析流、审批流或数据处理管道）。本文复盘了一个垂直领域 SaaS 系统的数据库演进过程，探讨在异步任务与复杂结构化数据的双重挑战下，如何进行合理的数据库建模。

一、 业务场景与技术挑战

我们正在开发一套垂直领域的 SaaS 系统，核心业务链路是：**客户 (Customer) -> 资产 (Asset, 如宠物/设备) -> 业务记录 (Record)**。

核心痛点：
系统的核心记录（Record）不是由用户简单的 CRUD 生成的，而是依赖一个**外部异步工作流 (External Workflow)**。

1. 触发：用户上传基础素材（如音频/文件）。
2. 处理：系统调用外部 Workflow 引擎进行处理（耗时不定）。
3. 结果：Workflow 回调返回一个包含多板块、多维度的复杂 JSON 数据。

架构师面临的三个核心问题：

1. 资产定义的独立性：当核心记录依赖工作流生成时，资产信息（如宠物/设备基础信息）应该包含在记录里，还是独立建表？
2. 结构化与灵活性的平衡：工作流返回的是一个大 JSON，数据库设计是该“打散成列”还是“整存整取”？
3. 历史数据的不可变性：资产状态会随时间改变（如改名、升级），如何保证历史记录的准确性，同时兼顾列表查询性能？

二、 架构演进：从“耦合”到“解耦”

1. 资产的独立性：解耦业务边界

最初的想法：
“既然每次调用工作流都是针对某个对象的，能不能直接把对象信息存在记录表里？减少表关联。”

架构决策：坚决剥离资产表（如 t_pet），建立星型拓扑。

• 战略考量：
  • 业务解耦：资产是核心实体，它可能会被未来的其他业务模块（如电商、预约、CRM）复用。如果强绑定在当前这个“工作流记录表”中，新业务将无法复用该资产数据。
  • 生命周期分离：资产的生命周期（长期、可变）与工作流记录的生命周期（一次性、不可变）完全不同，必须物理分离。

2. Workflow 数据的落地：混合存储策略

面临挑战：
工作流返回的数据极其复杂，既包含核心指标（如数值、状态），也包含大量的描述性文本和嵌套结构。

架构决策：“核心指标列式存储” + “业务载荷 JSONB 存储”。

• 计算层 (SQL)：将工作流返回结果中，后续需要参与计算、统计、全局搜索的字段（如 weight, status, result_summary），提取为独立的数据库列。
• 展示层 (NoSQL)：将工作流返回的完整业务载荷（Payload），直接以 JSONB 格式存入 form_data 字段。这既应对了工作流输出结构的潜在变化，又简化了前端渲染逻辑。

3. 历史快照与性能优化：反范式化设计

面临挑战：
列表页需要展示资产当时的名称、客户的联系方式。如果采用完全范式化设计（Join Asset Join Customer），不仅查询性能受限，且一旦资产发生变更（如过户），历史记录的展示就会失真。

架构决策：在记录表中引入“快照冗余” (Snapshot Redundancy)。

在工作流完成并写入数据库的那一刻，将当时的 关键资产属性（如名称、归属人）冗余写入记录表。

• 性能收益：列表查询实现 0 JOIN，单表极速返回。
• 业务收益：保留了“业务现场”，记录了工作流执行时的真实状态，不受后续资产变更影响。

4. 存储容量评估：单表足矣

面临挑战：
是否需要将记录表拆分为 Record_Master 和 Record_Detail？

架构决策：回归“单表设计”。

经过评估，外部工作流返回的结果主要是结构化数据，不包含巨大的二进制文件（BLOB）或超长文本（Log）。单行数据量控制在合理范围内（< 2KB）。在 PostgreSQL 等现代数据库中，单表完全足以支撑百万级业务数据，拆分反而增加了事务复杂性。

三、 最终架构方案 (PostgreSQL)

1. 领域模型设计 (ER Diagram)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

erDiagram
    %% 核心资产：独立存在，作为公共底座
    t_asset {
        bigint id PK
        varchar name
        jsonb current_properties "当前属性(可变)"
    }

    %% 业务记录：承载工作流结果
    t_asset ||--|{ t_workflow_record : "1:N"
    t_workflow_record {
        bigint id PK
        
        %% 冗余快照 (Snapshot)
        varchar snapshot_asset_name "当时名称"
        varchar snapshot_owner_info "当时归属人"
        
        %% 核心指标 (Structured Columns)
        decimal key_metric_a "用于计算"
        varchar key_status_b "用于统计"
        
        %% 柔性载荷 (Flexible Payload)
        jsonb workflow_result "完整结果数据"
        
        %% 流程状态
        varchar process_status "INIT, PROCESSING, DONE"
    }

2. 生产级 SQL DDL

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

-- 1. 资产表：核心实体，支撑多业务线
CREATE TABLE t_pet (
    id BIGSERIAL PRIMARY KEY,
    owner_id BIGINT NOT NULL, 
    name VARCHAR(64) NOT NULL,
    current_weight DECIMAL(5,2), -- 资产当前状态
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 2. 记录表：存储工作流结果
CREATE TABLE t_medical_record (
    id BIGSERIAL PRIMARY KEY,
    pet_id BIGINT NOT NULL REFERENCES t_pet(id),
    
    -- 【快照区】冗余字段，确保列表页 0 JOIN，且保留历史原貌
    snapshot_owner_phone VARCHAR(20),
    snapshot_pet_name VARCHAR(64),
    
    -- 【核心指标区】独立列，用于后续的报表统计与逻辑计算
    diagnosis_code VARCHAR(50),  -- 诊断编码
    recorded_weight DECIMAL(5, 2), -- 当时记录的数值
    
    -- 【柔性载荷区】存储工作流返回的完整复杂结构
    -- 利用 JSONB 存储，适应 Schema 的动态变化
    form_data JSONB DEFAULT '{}',
    
    process_status VARCHAR(32) DEFAULT 'INIT', -- 状态机
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- 索引优化：针对快照字段建立索引，加速搜索
CREATE INDEX idx_record_search ON t_medical_record(snapshot_owner_phone varchar_pattern_ops);

四、 方法论总结：五维数据建模法

针对“SaaS + 复杂外部工作流”场景，我们总结了以下决策模版：

1. 业务边界维 (Extensibility)

• 决策点：该对象未来是否会被其他业务模块复用？
• 法则：如果可能，必须独立建表，下沉为公共数据底座。

2. 时间属性维 (Asset vs Event)

• 决策点：数据是“会变化的状态”还是“不可变的历史”？
• 法则：资产（Asset）独立存最新状态；记录（Record）存工作流执行时的历史切片。

3. 数据使用维 (Column vs JSON)

• 决策点：字段是否用于 SQL 筛选、聚合统计或后端计算？
• 法则：要算、要搜的做成列；只用于展示、结构易变的扔进 JSON。

4. 查询性能维 (Normalization vs Snapshot)

• 决策点：列表页是否高频？业务是否需要追溯“发生当时”的状态？
• 法则：在记录表中冗余关键搜索字段和历史状态快照。

5. 存储容量维 (Split vs Merge)

• 决策点：单行数据量是否显著过大（如含原始长文本/大图）？
• 法则：存原始大素材 -> 拆主子表；只存处理后的结构化数据 -> 单表搞定。

结语

无论是对接 AI、IoT 设备还是审批流，架构设计的本质是不变的：**厘清资产与事件的边界，在结构化与灵活性之间找到平衡。**这套设计模式能有效降低系统的复杂性，并为未来的业务扩展预留充足的空间。

写在前面

最近读了 Naval Ravikant 的新作《Curate People》，有一种醍醐灌顶的感觉。

作为一名负责一线交付的技术团队负责人（Tech Lead），“招人”是我工作中极高频、也极痛苦的一环。很多时候，我很难向 HR 或其他协作方解释，为什么我拒绝了一个履历光鲜、技术看似合格的候选人，仅仅是因为“感觉不对”。

Naval 的这篇文章，给了这种“直觉”一个精准的理论支撑。他提出招聘不仅仅是填补空缺，而是一种“策展”（Curate）——像博物馆馆长挑选艺术品一样，审慎地甄选每一位团队成员。

这让我意识到，虽然我不是公司的创始人，但我实际上是这个研发团队的“创始人”。我所坚持的那些看似玄学的“闻味道”标准，其实正是为了对抗团队的平庸化。

这篇博客，既是对 Naval 顶级认知的深度梳理，也是对自己经手过百人面试后总结出的“闻味道”招聘法的复盘。希望能给同样在为打造“特种部队”而焦虑的技术管理者们一些启发。

第一部分：Naval 的核心观点——招聘是公司的 DNA

硅谷知名投资人、AngelList 创始人 Naval Ravikant 曾说过：“你建立的团队，就是你建立的公司。”（引用自 Vinod Khosla）。

对于早期创业者而言，很多人认为这是一场技术游戏或产品游戏，但 Naval 在他最近的分享《Curate People》中直言不讳地指出：这实际上是一场招聘游戏。

为什么招聘如此重要？为什么创始人绝对不能外包这一职能？以下是对 Naval 核心观点的深度解析。

1. 招聘是公司的 DNA，不可外包

Naval 提出一个核心论断：创始人可以授权一切，唯独除了招聘、融资、战略和产品愿景。 而这其中，招聘又是重中之重。

早期员工构成了公司的 DNA。如果你把招聘外包给猎头或 HR 部门，你就等于是在引入“中间层”和“机械传动装置”。外部人员或中层管理者永远无法像创始人那样保持极高的选择标准。

一旦创始人不再直接参与每一个人的招聘和管理，公司就开始变质。无论这时公司是 20 人还是 40 人，当你失去了对“谁在车上”的直接控制权，你就失去了对公司文化和产品灵魂的控制权。

2. A 类人才只愿与 A 类人才共事

招聘之所以不能妥协，有一个非显性的原因：最优秀的人，只愿意和最优秀的人一起工作。

对于一个顶尖人才来说，与平庸之辈共事是一种巨大的认知负担（Cognitive Load）。如果他们发现周围的人不如自己，他们会敏锐地意识到自己“来错了地方”。

Naval 提供了一个极其犀利的招聘测试标准：

当你面试一个新人时，问自己：如果让这个人走进隔壁房间，随机挑选团队里的任何一个人进行 30 分钟的谈话，你会感到放心吗？如果你担心他会随机挑到那个“不够好”的员工，那就说明那个员工本就不该留在团队里。

好的团队是互相激励的。如果你允许平庸存在，你就在驱逐天才。

3. “只招天才” (Geniuses Only)

在早期阶段，你的目标不应该是扩张规模，而是浓缩密度。

Naval 提到他和联合创始人设立的一个新标准：“Geniuses Only（只招天才）”。这听起来很刺耳，也不切实际，但这是一种态度的宣示。

你要找的不仅是“聪明且能干”的人（Smart and Get Things Done），更是能创造新知识的人。在 AI 时代，重复性的工作终将被自动化，唯有创造力无法被替代。

早期投资人看团队时，往往不看你的商业计划书，甚至不看早期的微小进展，他们只看一件事：你有多强？ 而证明你有多强的最好方式，就是看你能招募到多少比你更强、或者和你一样强的“天才”。

4. 为了得到最好的人，你必须“打破规则”

这是 Naval 非常反直觉的一个建议：不要做标准化的 HR。

为了得到最顶尖的人才，你必须打破所有规则。

• 薪资结构不合理？改。
• 需要远程办公？准。
• 头衔不符合层级？换。
• 想在这个项目上工作而不是那个？行。

最优秀的人不是机器上的齿轮，他们往往是多面手，有着独特的怪癖和需求。如果你用死板的“公司制度”去套他们，你只能招到平庸的“齿轮型”员工。创始人相对于 HR 的最大优势，就在于你有权力为了一个人才去重写规则。

5. 剔除“高自我”（High Ego），保持极简沟通

在性格特质上，Naval 推崇巴菲特的“智慧、精力、正直”三要素，但他加了一个极其重要的第四点：低自我（Low Ego）。

• 低自我：关注工作本身，而非办公室政治或抢功劳。你可以管理 40 个低自我的人，却可能搞不定 5 个高自我的人。
• 拒绝 Slack 文化：Naval 甚至提到在他的新公司不使用 Slack。因为群聊容易退化为噪音、表演和低效的忙碌。他倾向于更高门槛的沟通方式（如文档或直接解决问题），强迫员工独立思考，而不是把问题抛进群里制造“虚假的工作感”。

第二部分：我的思考——作为技术团队的“创始人”

我不是创始人而是技术团队负责人（Tech Lead / Manager）的角色，但是吹牛逼的说我也可以称为是这个研发团队的“创始人”。
我将从技术管理者的角度，将 Naval 的“创始人思维”转化为更落地的“Team Lead 思考”。

作为技术管理者的思考

读完 Naval 的这篇文章，作为一个在一线带队的技术管理者（而非公司创始人），我深有感触。虽然我不能像创始人那样重写公司的底层规则，但在我的“局部环境”里，Curate People（甄选人才） 的逻辑同样适用，甚至更为紧迫。

以下是我作为技术 Team Lead 的几点反思：

1. 我是自己团队的“策展人”

Naval 说“创始人不能外包招聘”，对于研发主管来说，这意味着不能把技术把关的责任完全丢给 HR 或面试题库。
在我的团队里，我必须是那个最终的“策展人”。所谓的“策展”，不仅仅是看候选人的技术栈（Java 熟不熟，架构懂不懂），更是看他的代码品味和工程素养。

• 代码如展品：如果我允许一段糟糕的代码合入主干，或者允许一个写出“能跑但不可维护”代码的人进入团队，我就实际上是在降低整个团队的审美标准。
• 红线思维：Naval 提到的“让新人随机挑选老员工交流”的测试非常残酷但有效。作为管理者，我必须时刻警惕：团队里是否存在那个“我不敢让新人见到”的短板？如果有，那就是我管理的失职。

2. “低自我（Low Ego）”是技术进化的前提

在技术团队中，”Low Ego” 尤为珍贵。软件开发是一个需要高频协作和快速试错的领域。

• 我们提倡 “Fail Fast”（快速试错），这就要求工程师不能有太强的“面子包袱”，承认错误要快，调整方向要快。
• 我们推崇 “Teach Back”（反向教学/分享），这也要求资深成员愿意分享，资浅成员敢于提问。
  如果招进来一个技术很强但“高自我”的人，他会把代码评审（Code Review）变成一场自尊心保卫战，这对于团队文化的破坏是毁灭性的。Naval 说得对，低自我的人才能专注于“创造新知识”，而不是“争夺功劳”。

3. 在规则之内，寻找“破局者”

Naval 建议为了人才“打破所有规则”。作为中层管理者，我或许无法随意打破公司的薪酬体系或期权池，但我可以在我的权限范围内打破常规：

• 打破面试流程：对于有特殊专长（比如极其擅长解决硬件底层 Bug 或精通 Prompt Engineering）的偏才，我是否敢于通过非标准化的面试流程录取他？
• 打破分工边界：Naval 提到最好的人才往往是多面手。在项目中，我是否允许后端开发去尝试前端，或者让架构师去写具体的业务逻辑？
  为了留住最优秀的人，我必须在团队内部创造一个相对自由的“特区”，让他们感觉到自己不是流水线上的螺丝钉，而是**”Pro First”（专业优先）**的创造者。

4. 只有 A 类人才，才能抗住熵增

在复杂的软硬件结合项目或高并发系统中，系统的“熵”（混乱度）是自然增加的。
平庸的工程师（B 类或 C 类）在解决问题时，往往会引入新的复杂度，导致系统越来越臃肿，变成“屎山”。只有 A 类人才（Naval 口中的 Geniuses），才具备把复杂问题简单化、把代码写得像工业设计一样优雅的能力。
招聘不仅仅是为了填补 HC（人力预算），而是为了引入对抗系统熵增的负熵流。

第三部分：我的实战——“闻味道”招聘法

我在公司电话面试+线下面试应该超过了100人，我的面试方法其实比较简单，首先我认为 “闻味道” (Sniff Test / Culture Fit) 往往比单纯的“做题”更重要。

因为技术栈（Spring Cloud, PostgreSQL, Python 等）是可以学的，但一个人的底层操作系统（性格、沟通方式、价值观、思维习惯）是很难重装的。

我的“闻味道”招聘法——当直觉成为最高效的算法

在技术圈，大家习惯谈论算法、架构和硬技能。但在我的招聘逻辑里，有一个看似不科学却极其精准的权重，称之为——“闻味道”（我之前没想到这个词，是在公司老板提出来的我觉得很贴切）。

这并不是忽视技术，而是我认为：技能决定了一个人的下限，但“味道”决定了一个人的上限，以及我们能一起走多远。

我的面试流程通常分为两轮：电话初筛和线下深聊。这其实就是我“闻味道”的两个步骤。

第一阶段：电话面试 —— “频段”对不对？ (Frequency Check)

电话面试看不到表情，排除了视觉干扰，反而让我更能专注于思维的逻辑性和沟通的信噪比。

我在这一轮“闻味道”主要闻的是：逻辑闭环与沟通成本。

1. 听“清晰度”而非“术语量”：

   • 我不看重他背了多少八股文，我看重他能否把一个复杂的技术点（比如多线程问题或硬件交互Bug）用最朴素的大白话讲清楚。
   • 味道不对的信号：顾左右而言他，堆砌大词，或者问A答B。
   • 味道对的信号：直击要害，逻辑线性，不仅告诉你怎么做，还能顺口说出“为什么不那样做”。

2. 听“真诚度”：

   • 电话里声音的微小迟疑是非常明显的。
   • 味道不对的信号：不懂装懂，试图用模糊的语言掩盖盲区。
   • 味道对的信号：坦率地说“这个细节我没接触过，但我的推测是……”。Intellectual Honesty（智识上的诚实） 是我非常看重的味道，这直接关联到未来的团队信任成本。

第二阶段：线下面试 —— “化学反应”有没有？ (Chemistry Check)

到了线下，技术细节往往已经不是唯一的重点，我在观察这个人的能量场和协作潜质。

这一轮，我寻找的是：**同理心、好奇心与低自我 (Low Ego)**。

1. **看“眼里的光” (Curiosity & Energy)**：

   • 当聊到他曾经解决的一个棘手难题，或者聊到我们正在攻克的软硬结合场景时，他的状态是怎样的？
   • 味道不对：像是在完成任务，只想知道薪资和加班情况，对技术本身没有兴奋感。
   • 味道对：眼睛会亮，身体会前倾，会反问我“那你们当时是怎么解决这个延迟问题的？”——这种好奇心是技术人员自我驱动的源动力。

2. **测“抗压与复盘” (Resilience & Fail Fast)**：

   • 我会故意追问一个他答不上来的盲区，或者指出他方案里的漏洞。
   • 味道不对：表现出防御性（Defensive），急于辩解，或者面露不悦（High Ego）。
   • 味道对：停顿思考，然后承认“确实，这块我没考虑到，如果是这样的话，也许可以……”——这对应了我推崇的 “Fail Fast” 文化，只有敢于面对错误的人，才能快速迭代。

3. 甚至看“非正式时刻”：

   • 面试结束送他出门的那两分钟，闲聊几句生活或爱好。这时候最能看出一个人的真实底色。他是否是一个有趣的人？是否是一个如果项目上线熬夜时，我愿意和他一起吃外卖的人？

核心逻辑：为什么“感觉”比“技术”更重要？

Naval 说“只招天才”，但我认为的“天才”不一定是现在的技术大牛，而是具备“成长型思维”的潜力股。

我之所以敢说“技术不一定要很牛逼”，是因为：

1. 技术是显性知识：Java 的并发库、PostgreSQL 的调优、嵌入式的协议，这些只要智商在线，给足文档和时间，谁都能学会。
2. “味道”是隐性素养：责任心（Ownership）、沟通时的换位思考（Empathy）、面对困难时的韧性（Grit），这些是教不会的。

“闻味道”，本质上是在寻找那一类：

• 无需鞭策（Self-managing）：不需要我天天盯着进度；
• 能够背靠背（Trustworthy）：我可以放心把后背交给他；
• 能够互相激发（Inspiring）：甚至未来在某个领域能反过来做我的老师。

总结来说，我招的不是代码机器，而是能够在这个充满不确定性的世界里，一起解决问题的伙伴。

结语：甄选是为了“背靠背”的信任

Naval 在文中建议创始人要保持极高的“不耐受度（Intolerance）”，把每一个候选人都视为可能摧毁公司的变量。

这听起来很残酷，但无论是创始人还是像我这样的技术管理者，本质目标是一致的：我们在寻找那些无需鞭策（Self-managing）、能够背靠背信任（Trustworthy） 且能够互相激发（Inspiring） 的伙伴。

在这个 AI 杠杆率极高的时代，一个小型的、由“味道相同”的天才组成的特种部队，远胜过一支庞大却平庸的正规军。

归根结底，The team I build is the product I build.（我建立的团队，即是我最终交付的产品。）

原文链接：Naval: Curate People

写在前面

“手中只有锤子的人，看什么问题都像钉子。” —— 查理·芒格

🧠 第一部分：底层逻辑与认知操作系统

核心目标：提升思考质量，避免愚蠢的错误。

这些是思考“思考本身”的模型，是所有决策的基础。

♟️ 第二部分：战略规划与竞争博弈

核心目标：找准方向，建立壁垒。

不要用战术上的勤奋，掩盖战略上的懒惰。

📈 第三部分：系统动力学与增长

核心目标：理解业务如何变大、变乱或崩溃。

系统不仅仅是零件的堆砌，而是零件之间的关系。

💰 第四部分：财务、经济与资源配置

核心目标：算账、搞钱、提升效率。

商业的本质是价值交换，而财务是商业的语言。

🛠️ 第五部分：产品、创新与工程

核心目标：做出用户真正需要的东西。

从“制造”思维转向“设计”思维。

👥 第六部分：组织管理与领导力

核心目标：带好队伍，分好钱。

管理是关于人类行为的杠杆。

🧠 第七部分：心理学与人性误判

核心目标：洞察人性，营销与说服。

查理·芒格最推崇的领域，理解人类误判心理学。

🌊 第八部分：自然与物理隐喻

核心目标：从大自然借智慧。

📝 结语：如何使用这份清单？

不要试图一次性背诵所有模型。建议将本文收藏或打印，作为您的“案头词典”。

1. 遇到管理难题时（如团队内耗）：查阅第六部分，尝试用 RACI 和 SBI 解决。
2. 制定年度战略时：查阅第二部分，用 VRIO 和 PESTEL 进行扫描。
3. 产品推不动时：查阅第五部分，看看是否满足了 JTBD 或卡在了 跨越鸿沟 阶段。

思维模型不是为了让你看起来更聪明，而是为了让你在关键时刻，做出那个胜率更高的决定。

掌握大型语言模型：50道面试题终极指南

本文基于一篇优秀的Medium文章，解析并提炼了50道经典LLM面试题。我对内容进行了润色和优化，使其更简洁、实用，同时保留了核心知识点。此次版本特别结合了相关图示，帮助你更直观地理解复杂概念。无论你是求职者、面试官，还是AI爱好者，这份指南都能帮你快速掌握LLM的核心概念、机制和应用。

这些问题涵盖了从基础原理到高级技巧的方方面面，每个问题后附带简明解释，帮助你获得“顿悟”时刻。让我们一起来探索吧！

1. 什么是分词（Tokenization），为什么它对LLM至关重要？

分词是将文本分解成更小的单位（如单词、子词或字符）的过程。例如，“artificial”可能被拆分成“art”、“ific”和“ial”。这对LLM至关重要，因为模型处理的是数字而非原始文本。分词能处理多种语言、稀有词汇，并优化词汇表大小，提高计算效率和模型性能。

2. Transformer模型中的注意力机制是如何工作的？

注意力机制允许LLM在生成或解释文本时，权衡序列中不同token的重要性。它通过查询（query）、键（key）和值（value）向量计算相似度分数（如点积）。例如，在“The cat chased the mouse”中，它能将“mouse”与“chased”关联起来，提升上下文理解，使Transformer在NLP任务中表现出色。

3. LLM中的上下文窗口是什么，为什么重要？

上下文窗口是指LLM一次能处理的token数量上限（如32,000个token），它定义了模型的“记忆”范围。更大的窗口能提升如摘要生成的任务连贯性，但会增加计算成本。在实际部署中，平衡窗口大小与效率是关键。

4. LoRA和QLoRA在LLM微调中的区别是什么？

LoRA（Low-Rank Adaptation）通过添加低秩矩阵来高效微调模型，减少内存开销。QLoRA在此基础上引入量化（如4-bit精度），进一步降低内存需求。例如，QLoRA能让70B参数模型在单GPU上微调，适合资源有限的环境。

5. 束搜索（Beam Search）如何比贪婪解码（Greedy Decoding）更好地生成文本？

束搜索在生成文本时保留前k个（例如k=5）最佳序列，探索更多路径，而贪婪解码只选最高概率词。这能产生更连贯的输出，尤其在机器翻译或对话生成中，平衡概率与多样性。

6. 温度（Temperature）在控制LLM输出中扮演什么角色？

温度是一个超参数，用于调整文本生成的随机性。低温度（如0.3）偏好高概率token，输出更可预测；高温度（如1.5）增加多样性。通过设置如0.8，能在创意任务如讲故事中平衡创造力和连贯性。

7. 什么是掩码语言建模（Masked Language Modeling），它如何辅助预训练？

掩码语言建模（MLM）是将序列中随机token隐藏，并训练模型基于上下文预测它们。如BERT模型中使用，这促进双向语言理解，捕捉语义关系，为情感分析或问答等任务打下基础。

8. 序列到序列（Seq2Seq）模型是什么，在哪里应用？

Seq2Seq模型将输入序列转换为输出序列（长度可不同），由编码器处理输入、解码器生成输出。应用包括机器翻译（如英文到西班牙文）、文本摘要和聊天机器人，处理变长输入输出。

9. 自回归模型和掩码模型在LLM训练中的区别是什么？

自回归模型（如GPT）基于先前token顺序预测，擅长生成任务如文本补全。掩码模型（如BERT）使用双向上下文预测掩码token，适合分类等理解任务。训练目标决定了它们在生成 vs. 理解上的优势。

10. 什么是嵌入（Embeddings），在LLM中如何初始化？

嵌入是将token表示为连续空间中的稠密向量，捕捉语义和句法属性。通常随机初始化或用预训练如GloVe，然后在训练中微调。例如，“dog”的嵌入可能在宠物相关任务中演化，提升模型准确性。

11. 什么是下一句预测（Next Sentence Prediction），它如何提升LLM？

下一句预测（NSP）训练模型判断两句是否连续（50%正样本，50%负样本）。如BERT中使用，这改善如对话系统或文档摘要的任务连贯性，通过理解句子关系。

12. Top-k和Top-p采样在文本生成中的区别是什么？

Top-k采样选择前k个最高概率token（如k=20）随机采样，确保控制多样性。Top-p（核采样）选择累积概率超过阈值p（如0.95）的token，更灵活。在创意写作中，Top-p能产生多样且连贯的输出。

13. 为什么提示工程（Prompt Engineering）对LLM性能至关重要？

提示工程是设计输入以引发理想响应的艺术。例如，“用100字总结这篇文章”比模糊指令更有效。在零样本或少样本设置中，它让LLM无需大量微调就能处理翻译或分类任务。

14. LLM如何在微调中避免灾难性遗忘（Catastrophic Forgetting）？

灾难性遗忘是微调抹除先前知识的现象。缓解方法包括：重放（混合旧新数据）、弹性权重整合（保护关键权重）、模块化架构（添加任务特定模块）。这些确保LLM在多任务中保持多功能性。

15. 什么是模型蒸馏（Model Distillation），它如何益处LLM？

模型蒸馏训练“小学生”模型模仿“大老师”模型的输出，使用软概率而非硬标签。这减少内存和计算需求，让模型能在智能手机上部署，同时保留近似性能，适合实时应用。

16. LLM如何处理词汇表外（OOV）词？

LLM使用子词分词如字节对编码（BPE），将OOV词拆分成已知子词。例如，“cryptocurrency”拆成“crypto”和“currency”。这确保处理稀有或新词，增强语言理解和生成鲁棒性。

17. Transformer如何优于传统Seq2Seq模型？

Transformer通过并行处理（自注意力同时处理token）、捕捉长距离依赖、位置编码（保留顺序）来改进。相比RNN的顺序处理，这些提升了可扩展性和如翻译任务的性能。

18. 什么是过拟合（Overfitting），在LLM中如何缓解？

过拟合是模型记忆训练数据但无法泛化。缓解包括：正则化（L1/L2惩罚）、Dropout（随机禁用神经元）、早停（验证性能停滞时停止）。这些确保对未见数据的鲁棒泛化。

19. NLP中的生成模型和判别模型有什么区别？

生成模型（如GPT）建模联合概率，创建新数据如文本。判别模型（如BERT分类）建模条件概率，区分类别如情感分析。生成模型擅长创建，判别模型聚焦准确分类。

20. GPT-4与GPT-3在功能和应用上的区别是什么？

GPT-4超越GPT-3的多模态输入（文本+图像）、更大上下文（25,000 vs. 4,096 token）、更高准确性（减少事实错误）。这扩展了其在视觉问答和复杂对话的应用。

21. 什么是位置编码（Positional Encodings），为什么使用？

位置编码为Transformer输入添加序列顺序信息，因为自注意力无固有顺序。用正弦函数或学习向量，确保如“king”和“crown”基于位置正确解释，关键于翻译任务。

22. 什么是多头注意力（Multi-Head Attention），它如何提升LLM？

多头注意力将查询、键、值拆分成多个子空间，同时关注输入的不同方面。例如，一头关注句法，另一头关注语义。这提升模型捕捉复杂模式的能力。

23. Softmax函数在注意力机制中如何应用？

Softmax将注意力分数规范化成概率分布：在注意力中，将原始相似分数（查询-键点积）转为权重，强调相关token，确保模型聚焦上下文重要部分。

24. 点积在自注意力中如何贡献？

在自注意力中，查询（Q）和键（K）向量的点积计算相似分数：高分表示相关token。尽管高效，但其二次复杂度（O(n²)）促使研究稀疏注意力。

25. 为什么在语言建模中使用交叉熵损失（Cross-Entropy Loss）？

交叉熵测量预测与真实token概率的差异：它惩罚错误预测，鼓励准确token选择。在语言建模中，确保模型为正确下一token分配高概率，优化性能。

26. LLM中嵌入的梯度如何计算？

嵌入梯度通过链式法则在反向传播中计算：这些梯度调整嵌入向量以最小化损失，精炼语义表示，提升任务性能。

27. Jacobian矩阵在Transformer反向传播中的作用是什么？

Jacobian矩阵捕捉输出对输入的部分导数。在Transformer中，它帮助计算多维输出的梯度，确保权重和嵌入的准确更新，优化复杂模型。

28. 特征值和特征向量如何与降维相关？

特征向量定义数据主方向，特征值表示方差。在PCA中，选择高特征值的向量减少维度，同时保留大部分方差，便于LLM输入处理。

29. 什么是KL散度（KL Divergence），在LLM中如何使用？

KL散度量化两个概率分布的差异：在LLM中，它评估模型预测与真实分布的接近度，指导微调改善输出质量和数据对齐。

30. ReLU函数的导数是什么，为什么重要？

ReLU函数f(x) = max(0, x)的导数为：1 (x > 0)，0 (x ≤ 0)。其稀疏性和非线性防止梯度消失，使ReLU在LLM中高效且广泛使用。

31. 链式法则如何应用于LLM中的梯度下降？

链式法则计算复合函数导数：在梯度下降中，它启用反向传播逐层计算梯度，高效更新参数，最小化深度LLM架构的损失。

32. Transformer中注意力分数如何计算？

注意力分数计算为：缩放点积测量token相关性，Softmax规范化分数，聚焦关键token，提升如摘要的上下文生成。

33. Gemini如何优化多模态LLM训练？

Gemini通过统一架构（结合文本和图像）、高级注意力（提升跨模态学习稳定性）、数据效率（自监督减少标签需求）来优化。更稳定、可扩展于如GPT-4。

34. 基础模型有哪些类型？

基础模型包括：语言模型（BERT、GPT-4用于文本）、视觉模型（ResNet用于图像分类）、生成模型（DALL-E用于内容创建）、多模态模型（CLIP用于文本-图像）。它们利用广泛预训练适用于多样应用。

35. PEFT如何缓解灾难性遗忘？

参数高效微调（PEFT）仅更新小部分参数，冻结其余以保留预训练知识。如LoRA，确保LLM适应新任务而不丢失核心能力，维持跨域性能。

36. 检索增强生成（RAG）的步骤是什么？

RAG包括：检索（用查询嵌入获取相关文档）、排序（按相关性排序）、生成（用检索上下文生成准确响应）。提升如问答的任务事实准确性。

37. 专家混合（MoE）如何提升LLM可扩展性？

MoE用门控函数激活特定专家子网络，减少计算负载。例如，每查询仅用10%参数，让亿级参数模型高效运行，同时保持高性能。

38. 思维链（Chain-of-Thought）提示是什么，它如何辅助推理？

CoT提示引导LLM逐步解决问题，模仿人类推理。例如，在数学问题中分解计算，提升复杂任务如逻辑推理的准确性和可解释性。

39. 判别AI和生成AI的区别是什么？

判别AI（如情感分类器）基于输入特征预测标签，建模条件概率。生成AI（如GPT）创建新数据，建模联合概率，适合文本或图像生成，提供创意灵活性。

40. 知识图谱集成如何改善LLM？

知识图谱提供结构化事实数据，通过减少幻觉（验证事实）、改善推理（利用实体关系）、增强上下文来提升LLM。适用于问答和实体识别。

41. 什么是零样本学习（Zero-Shot Learning），LLM如何实现？

零样本学习让LLM使用预训练通用知识执行未训练任务。例如，提示“将此评论分类为积极或消极”，无需特定数据即可推断情感，展示其多功能性。

42. 自适应Softmax如何优化LLM？

自适应Softmax按频率分组词，减少稀有词计算。降低大词汇表成本，加速训练和推理，同时保持准确性，尤其在资源有限环境中。

43. Transformer如何解决梯度消失问题？

Transformer通过自注意力（避免顺序依赖）、残差连接（直接梯度流）、层规范化（稳定更新）来缓解。与RNN不同，确保深度模型有效训练。

44. 什么是少样本学习（Few-Shot Learning），其益处是什么？

少样本学习让LLM用少量示例执行任务，利用预训练知识。益处包括减少数据需求、快速适应、成本效率，适合利基任务如特定文本分类。

45. 如何修复LLM生成偏见或错误输出？

解决方法：1. 分析模式（识别偏见来源）；2. 增强数据（用平衡数据集和去偏技术）；3. 微调（用精选数据或对抗方法重训）。改善公平性和准确性。

46. Transformer中编码器和解码器的区别是什么？

编码器将输入序列处理成抽象表示，捕捉上下文。解码器生成输出，使用编码器输出和先前token。在翻译中，编码器理解源语言，解码器产生目标语言，实现有效Seq2Seq任务。

47. LLM与传统统计语言模型的区别是什么？

LLM使用Transformer架构、海量数据集和无监督预训练，而统计模型（如N-gram）依赖简单监督方法。LLM处理长距离依赖、上下文嵌入和多样任务，但需大量计算资源。

48. 什么是超参数，为什么重要？

超参数是预设值，如学习率或批次大小，控制模型训练。它们影响收敛和性能；例如，高学习率可能导致不稳定。调优超参数优化LLM效率和准确性。

49. 什么是大型语言模型（LLM）？

LLM是训练于海量文本语料的AI系统，能理解和生成类人语言。拥有亿级参数，在翻译、摘要和问答中卓越，利用上下文学习广泛适用。

50. LLM部署面临哪些挑战？

挑战包括：资源密集（高计算需求）、偏见（延续训练数据偏见）、可解释性（复杂模型难解释）、隐私（数据安全担忧）。解决这些确保LLM的伦理和有效使用。

参考来源

https://transformers.run/c1/transformer/

https://github.com/github/spec-kit

我选用的Cursut-agent，我的建议是一定要按照官方的这几个命令顺序执，按顺序执行你才能真正体现这个工具的强大之处：

按顺序执行

生成结果

我个人觉得，从0到1开始一个项目，有这个是很省心的。

• 想的全面
• 代码结构化
• 使用得当不容易出现屎山代码