写在前面

几个月前，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永远无法外包的能力。

写在前面

对于 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 寻找适合你的那款“超能力”。

写在前面

说实话，刚开始接触SOLID原则的时候，我觉得这些都是些”虚头巴脑”的理论。直到临时接手一个离职同事的代码——一个类上千行，改一行bug到处冒，而且代码完全没有秩序，我才真正体会到这些原则的价值。

SOLID原则是我CLAUDE.md其中一个规范，是由Robert C. Martin（Uncle Bob）提出的五个面向对象设计原则。简单来说，它们能帮我写出更好维护、更好扩展、更好测试的代码。

因为在软件开发的早期，我们往往更关注功能的实现，而忽视了代码的设计质量。随着项目规模的增长，糟糕的代码设计会变得越来越难以维护，每一次修改都可能引发意想不到的问题。SOLID原则正是为了解决这些问题而诞生的。

为什么要学习SOLID原则？

SOLID原则能够帮助我们：

1. 降低代码耦合度：让模块之间的依赖关系更加清晰
2. 提高代码可维护性：单一职责让修改更加聚焦
3. 增强代码可扩展性：开闭原则让功能扩展更安全
4. 改善代码可测试性：依赖倒置让单元测试更容易编写

学习资料

• DigitalOcean: S.O.L.I.D The First Five Principles
• ExplainThis: 什么是SOLID原则
• Reddit讨论: 求职时被问SOLID原则怎么办

单一职责原则（Single Responsibility Principle，SRP）

原则定义

一个类应该只有一个引起它变化的原因，换句话说，一个类应该只有一个职责。

直观理解

想象一个瑞士军刀，它有太多功能：刀、剪刀、开瓶器等。虽然功能强大，但当你只需要用刀的时候，带着整个军刀就显得笨重了。同样，一个类承担太多职责时，任何职责的变化都可能影响其他职责，导致系统变得脆弱。

反例代码

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

/**
 * 违反单一职责原则的用户服务类
 * 该类同时负责用户业务逻辑和日志记录
 */
public class UserService {

    // 职责1：用户管理
    public void register(String username, String password) {
        // 注册逻辑
        System.out.println("用户注册：" + username);
    }

    public void login(String username, String password) {
        // 登录逻辑
        System.out.println("用户登录：" + username);
    }

    // 职责2：日志记录 - 这不应该属于用户服务
    public void logToFile(String message) {
        try {
            FileWriter writer = new FileWriter("app.log", true);
            writer.write(message + "\n");
            writer.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }

    // 职责3：邮件发送 - 这也不应该属于用户服务
    public void sendEmail(String to, String subject, String content) {
        System.out.println("发送邮件给：" + to);
        System.out.println("主题：" + subject);
        System.out.println("内容：" + content);
    }
}

正例代码

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
40
41
42
43
44
45
46
47
48
49
50
51

/**
 * 符合单一职责原则的用户服务类
 * 只负责用户相关的业务逻辑
 */
public class UserService {
    private Logger logger;
    private EmailService emailService;

    public UserService(Logger logger, EmailService emailService) {
        this.logger = logger;
        this.emailService = emailService;
    }

    // 只关注用户管理职责
    public void register(String username, String password) {
        logger.log("用户注册：" + username);
        // 注册逻辑
        emailService.sendEmail(username, "注册成功", "欢迎注册");
    }

    public void login(String username, String password) {
        logger.log("用户登录：" + username);
        // 登录逻辑
    }
}

/**
 * 专门的日志服务类
 */
public class Logger {
    public void log(String message) {
        try {
            FileWriter writer = new FileWriter("app.log", true);
            writer.write(message + "\n");
            writer.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

/**
 * 专门的邮件服务类
 */
public class EmailService {
    public void sendEmail(String to, String subject, String content) {
        System.out.println("发送邮件给：" + to);
        System.out.println("主题：" + subject);
        System.out.println("内容：" + content);
    }
}

开闭原则（Open-Closed Principle，OCP）

原则定义

软件实体（类、模块、函数等）应该对扩展开放，对修改封闭。

这意味着当我们需要添加新功能时，应该通过扩展现有代码来实现，而不是修改已有的代码。

直观理解

想象一个插线板，它有多个插座。当你需要使用新电器时，你只需要插上新的插头，而不需要拆开插线板重新布线。开闭原则就是让我们的代码像插线板一样，能够轻松”插入”新功能而不需要修改核心代码。

反例代码

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

/**
 * 违反开闭原则的折扣计算器
 * 每次新增折扣类型都需要修改这个类
 */
public class DiscountCalculator {

    public double calculateDiscount(String discountType, double price) {
        switch (discountType) {
            case "NONE":
                return price;
            case "TEN_PERCENT":
                return price * 0.9;
            case "TWENTY_PERCENT":
                return price * 0.8;
            // 每次新增折扣类型都需要在这里添加新的case
            // 这违反了开闭原则
            default:
                return price;
        }
    }
}

正例代码

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86

/**
 * 折扣策略接口
 */
public interface DiscountStrategy {
    double calculate(double price);
}

/**
 * 无折扣策略
 */
public class NoDiscount implements DiscountStrategy {
    @Override
    public double calculate(double price) {
        return price;
    }
}

/**
 * 10%折扣策略
 */
public class TenPercentDiscount implements DiscountStrategy {
    @Override
    public double calculate(double price) {
        return price * 0.9;
    }
}

/**
 * 20%折扣策略
 */
public class TwentyPercentDiscount implements DiscountStrategy {
    @Override
    public double calculate(double price) {
        return price * 0.8;
    }
}

/**
 * 符合开闭原则的折扣计算器
 */
public class DiscountCalculator {
    private DiscountStrategy discountStrategy;

    public DiscountCalculator(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }

    public double calculate(double price) {
        return discountStrategy.calculate(price);
    }

    // 可以动态切换折扣策略
    public void setDiscountStrategy(DiscountStrategy discountStrategy) {
        this.discountStrategy = discountStrategy;
    }
}

// 使用示例
public class Main {
    public static void main(String[] args) {
        DiscountCalculator calculator = new DiscountCalculator(new NoDiscount());
        System.out.println("无折扣价格：" + calculator.calculate(100));

        // 切换到10%折扣
        calculator.setDiscountStrategy(new TenPercentDiscount());
        System.out.println("10%折扣后价格：" + calculator.calculate(100));

        // 切换到20%折扣
        calculator.setDiscountStrategy(new TwentyPercentDiscount());
        System.out.println("20%折扣后价格：" + calculator.calculate(100));

        // 添加新的折扣类型只需创建新的策略类，无需修改DiscountCalculator
        calculator.setDiscountStrategy(new ThirtyPercentDiscount());
        System.out.println("30%折扣后价格：" + calculator.calculate(100));
    }
}

/**
 * 新增30%折扣策略 - 无需修改任何现有代码
 */
public class ThirtyPercentDiscount implements DiscountStrategy {
    @Override
    public double calculate(double price) {
        return price * 0.7;
    }
}

里氏替换原则（Liskov Substitution Principle，LSP）

原则定义

所有引用基类的地方必须能够透明地使用其子类的对象，子类可以替换父类出现在父类能够出现的任何地方，而不破坏程序的正确性。

直观理解

如果你有一个正方形和一个长方形，从几何上讲，正方形是特殊的长方形。但在编程中，如果让正方形继承长方形类，可能会出现问题。因为正方形的长宽必须相等，这违反了长方形”长宽可以不同”的基本约定。

反例代码

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80

/**
 * 长方形类
 */
public class Rectangle {
    protected double width;
    protected double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    public void setWidth(double width) {
        this.width = width;
    }

    public void setHeight(double height) {
        this.height = height;
    }

    public double getWidth() {
        return width;
    }

    public double getHeight() {
        return height;
    }

    public double getArea() {
        return width * height;
    }
}

/**
 * 正方形类继承长方形
 * 这违反了里氏替换原则
 */
public class Square extends Rectangle {

    public Square(double size) {
        super(size, size);
    }

    @Override
    public void setWidth(double width) {
        this.width = width;
        this.height = width; // 正方形长宽必须相等
    }

    @Override
    public void setHeight(double height) {
        this.width = height;  // 正方形长宽必须相等
        this.height = height;
    }
}

/**
 * 测试类
 */
public class LSPTest {
    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle(5, 10);
        System.out.println("长方形面积：" + rectangle.getArea()); // 50

        rectangle.setWidth(10);
        rectangle.setHeight(5);
        System.out.println("长方形面积：" + rectangle.getArea()); // 50

        // 使用正方形替换长方形
        Rectangle square = new Square(5);
        System.out.println("正方形面积：" + square.getArea()); // 25

        square.setWidth(10);
        square.setHeight(5);
        System.out.println("正方形面积：" + square.getArea()); // 25, 而不是50！

        // 这里违反了里氏替换原则
        // 当使用Square替换Rectangle时，程序的行为发生了变化
    }
}

正例代码

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81

/**
 * 形状接口
 */
public interface Shape {
    double getArea();
}

/**
 * 长方形类实现形状接口
 */
public class Rectangle implements Shape {
    private double width;
    private double height;

    public Rectangle(double width, double height) {
        this.width = width;
        this.height = height;
    }

    public void setWidth(double width) {
        this.width = width;
    }

    public void setHeight(double height) {
        this.height = height;
    }

    @Override
    public double getArea() {
        return width * height;
    }
}

/**
 * 正方形类实现形状接口
 */
public class Square implements Shape {
    private double size;

    public Square(double size) {
        this.size = size;
    }

    public void setSize(double size) {
        this.size = size;
    }

    @Override
    public double getArea() {
        return size * size;
    }
}

/**
 * 形状工具类 - 可以处理任何实现Shape接口的对象
 */
public class ShapeUtils {
    public static void printArea(Shape shape) {
        System.out.println("形状面积：" + shape.getArea());
    }
}

/**
 * 测试类
 */
public class LSPTestCorrect {
    public static void main(String[] args) {
        Rectangle rectangle = new Rectangle(5, 10);
        Square square = new Square(5);

        // Rectangle和Square可以透明替换
        ShapeUtils.printArea(rectangle); // 形状面积：50.0
        ShapeUtils.printArea(square);    // 形状面积：25.0

        // 使用多态
        List<Shape> shapes = Arrays.asList(rectangle, square);
        for (Shape shape : shapes) {
            ShapeUtils.printArea(shape);
        }
    }
}

接口隔离原则（Interface Segregation Principle，ISP）

原则定义

客户端不应该被迫依赖于它不使用的接口，接口应该被拆分为更小和更具体的部分，这样客户端只需要知道它们所需的部分。

直观理解

想象一个万能遥控器，上面有电视、空调、音响等各种设备的按钮。当你只需要控制电视时，面对这么多无关的按钮会很困扰。接口隔离原则就是让每个接口都专注于特定的功能，避免”胖接口”。

反例代码

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

/**
 * 臃肿的机器接口 - 包含所有可能的操作
 */
public interface Machine {
    void print(String document);
    void fax(String document);
    void scan(String document);
    void photocopy(String document);
}

/**
 * 打印机类 - 被迫实现不需要的方法
 */
public class OldPrinter implements Machine {

    @Override
    public void print(String document) {
        System.out.println("打印：" + document);
    }

    @Override
    public void fax(String document) {
        // 老式打印机不支持传真，但被迫实现这个方法
        throw new UnsupportedOperationException("不支持传真功能");
    }

    @Override
    public void scan(String document) {
        // 老式打印机不支持扫描，但被迫实现这个方法
        throw new UnsupportedOperationException("不支持扫描功能");
    }

    @Override
    public void photocopy(String document) {
        // 老式打印机不支持复印，但被迫实现这个方法
        throw new UnsupportedOperationException("不支持复印功能");
    }
}

正例代码

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112

/**
 * 打印接口
 */
public interface Printer {
    void print(String document);
}

/**
 * 传真接口
 */
public interface Fax {
    void fax(String document);
}

/**
 * 扫描接口
 */
public interface Scanner {
    void scan(String document);
}

/**
 * 复印接口
 */
public interface Photocopier {
    void photocopy(String document);
}

/**
 * 简单打印机 - 只实现打印功能
 */
public class SimplePrinter implements Printer {
    @Override
    public void print(String document) {
        System.out.println("打印：" + document);
    }
}

/**
 * 多功能打印机 - 实现多个接口
 */
public class MultiFunctionPrinter implements Printer, Fax, Scanner, Photocopier {

    @Override
    public void print(String document) {
        System.out.println("打印：" + document);
    }

    @Override
    public void fax(String document) {
        System.out.println("传真：" + document);
    }

    @Override
    public void scan(String document) {
        System.out.println("扫描：" + document);
    }

    @Override
    public void photocopy(String document) {
        System.out.println("复印：" + document);
    }
}

/**
 * 打印扫描一体机 - 只实现需要的接口
 */
public class PrintScanCombo implements Printer, Scanner {

    @Override
    public void print(String document) {
        System.out.println("打印：" + document);
    }

    @Override
    public void scan(String document) {
        System.out.println("扫描：" + document);
    }
}

// 使用示例
public class ISPTest {
    public static void main(String[] args) {
        // 简单打印机只需要Printer接口
        Printer simplePrinter = new SimplePrinter();
        simplePrinter.print("简单文档");

        // 多功能打印机可以实现所有功能
        MultiFunctionPrinter mfp = new MultiFunctionPrinter();
        usePrinter(mfp);
        useFax(mfp);
        useScanner(mfp);

        // 打印扫描一体机只需要打印和扫描功能
        PrintScanCombo combo = new PrintScanCombo();
        usePrinter(combo);
        useScanner(combo);
    }

    // 客户端只需要依赖它需要的接口
    public static void usePrinter(Printer printer) {
        printer.print("使用打印机");
    }

    public static void useFax(Fax fax) {
        fax.fax("使用传真机");
    }

    public static void useScanner(Scanner scanner) {
        scanner.scan("使用扫描仪");
    }
}

依赖倒置原则（Dependency Inversion Principle，DIP）

原则定义

高层模块不应该依赖低层模块，两者都应该依赖抽象。抽象不应该依赖细节，细节应该依赖抽象。

直观理解

想象一个公司组织架构，总经理（高层）不应该直接管理员工（低层）的每一个具体工作。相反，总经理应该制定标准和接口，员工按照这些标准工作。这样，更换员工不会影响公司的整体运作。

反例代码

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

/**
 * MySQL数据库连接类 - 低层模块
 */
public class MySQLConnection {
    public void connect() {
        System.out.println("连接到MySQL数据库");
    }

    public void executeQuery(String sql) {
        System.out.println("在MySQL中执行查询：" + sql);
    }
}

/**
 * 用户服务类 - 高层模块
 * 直接依赖具体的MySQLConnection
 */
public class UserService {
    private MySQLConnection dbConnection;

    public UserService() {
        this.dbConnection = new MySQLConnection(); // 高层依赖低层具体实现
    }

    public void getUser(String userId) {
        dbConnection.connect();
        dbConnection.executeQuery("SELECT * FROM users WHERE id = " + userId);
    }
}

正例代码

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
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98

/**
 * 数据库连接接口 - 抽象层
 */
public interface DatabaseConnection {
    void connect();
    void executeQuery(String sql);
}

/**
 * MySQL数据库连接实现
 */
public class MySQLConnection implements DatabaseConnection {
    @Override
    public void connect() {
        System.out.println("连接到MySQL数据库");
    }

    @Override
    public void executeQuery(String sql) {
        System.out.println("在MySQL中执行查询：" + sql);
    }
}

/**
 * PostgreSQL数据库连接实现
 */
public class PostgreSQLConnection implements DatabaseConnection {
    @Override
    public void connect() {
        System.out.println("连接到PostgreSQL数据库");
    }

    @Override
    public void executeQuery(String sql) {
        System.out.println("在PostgreSQL中执行查询：" + sql);
    }
}

/**
 * MongoDB数据库连接实现
 */
public class MongoDBConnection implements DatabaseConnection {
    @Override
    public void connect() {
        System.out.println("连接到MongoDB数据库");
    }

    @Override
    public void executeQuery(String sql) {
        System.out.println("在MongoDB中执行查询：" + sql);
    }
}

/**
 * 符合依赖倒置原则的用户服务类
 * 依赖抽象接口，而不是具体实现
 */
public class UserService {
    private DatabaseConnection dbConnection;

    // 通过构造器注入依赖
    public UserService(DatabaseConnection dbConnection) {
        this.dbConnection = dbConnection; // 依赖抽象而非具体实现
    }

    public void getUser(String userId) {
        dbConnection.connect();
        dbConnection.executeQuery("SELECT * FROM users WHERE id = " + userId);
    }

    // 也可以通过setter注入
    public void setDbConnection(DatabaseConnection dbConnection) {
        this.dbConnection = dbConnection;
    }
}

// 使用示例
public class DIPTest {
    public static void main(String[] args) {
        // 可以轻松切换不同的数据库实现
        DatabaseConnection mysqlConnection = new MySQLConnection();
        DatabaseConnection pgConnection = new PostgreSQLConnection();
        DatabaseConnection mongoConnection = new MongoDBConnection();

        UserService userService1 = new UserService(mysqlConnection);
        userService1.getUser("1");

        UserService userService2 = new UserService(pgConnection);
        userService2.getUser("2");

        UserService userService3 = new UserService(mongoConnection);
        userService3.getUser("3");

        // 运行时切换数据库实现
        userService1.setDbConnection(mongoConnection);
        userService1.getUser("4");
    }
}

面试中被问到SOLID原则怎么办？

有次在Reddit上看到一个吐槽帖，说某公司招聘人员让候选人”凭空解释5个SOLID原则”，结果博主直接拒绝回答。其实这问题挺常见的，尤其是面试初级到中级岗位的时候。

答题思路

别死记硬背。先说总体理解，然后逐个简述：

然后补一句：”这些原则我实际项目里也在用，比如最近做的XX项目，用策略模式实现XX功能，就体现了开闭原则…”

这样回答既展示了理论知识，又证明了实践经验。

记忆技巧

• SRP：Single Responsibility → 单一职责
• OCP：Open/Closed → 对扩展开放，对修改封闭
• LSP：Liskov Substitution → 里氏替换
• ISP：Interface Segregation → 接口隔离
• DIP：Dependency Inversion → 依赖倒置（依赖抽象）

总结

SOLID原则的关系图

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

┌─────────────────────────────────────────────────┐
│                   SOLID 原则                      │
├─────────────────────────────────────────────────┤
│                                                 │
│  SRP ──────── 单一职责 ───────── 一个类只有一个职责  │
│    ↓                                        │
│  OCP ──────── 开闭原则 ────── 对扩展开放，对修改封闭  │
│    ↓                                        │
│  LSP ──────── 里氏替换 ──── 子类可以透明替换父类     │
│    ↓                                        │
│  ISP ──────── 接口隔离 ──── 接口应该小而专注        │
│    ↓                                        │
│  DIP ──────── 依赖倒置 ── 依赖抽象而非具体实现       │
│                                                 │
└─────────────────────────────────────────────────┘

实践建议

如何在项目中应用SOLID原则：

1. 逐步重构：不要试图一次性重构所有代码，逐步应用这些原则
2. 识别坏味道：学会识别违反SOLID原则的代码坏味道
3. 设计优先：在编写新代码时，优先考虑SOLID原则
4. 团队共识：确保团队成员都理解并认同这些原则
5. 适度应用：不要过度设计，根据实际情况灵活应用

架构师学习系列 敬请期待下一篇

写在前面

我评审了团队里几位研发程师提交的《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/

设计模式 (Design Patterns)

• 核心概念与原则

  • 定义：一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
  • 目的：提高代码的可重用性，使代码更容易被他人理解，保证代码可靠性。
  • 核心原则
    • 针对接口编程：客户无须知道对象的特定类型，只需知道对象有客户所期望的接口。
    • 优先使用对象组合：优先使用对象组合（黑箱复用），而不是类继承（白箱复用）。
  • MVC模式案例：Smalltalk中的MVC（模型/视图/控制器）体现了观察者、组合和策略模式的综合应用。

• 一、创建型模式 (Creational Patterns)

  • 关注点：对象的创建过程，将对象的创建与使用分离。
  • 1. 工厂模式 (Factory)
    • **简单工厂 (Simple Factory)**：(非GoF标准，但常用) 定义一个用于创建对象的接口，由工厂类决定创建哪一种产品实例（如“司机开车”的例子）。
    • **工厂方法 (Factory Method)**：定义创建对象的接口，让子类决定实例化哪一个类。使实例化延迟到子类。
    • **抽象工厂 (Abstract Factory)**：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
  • 2. 单例模式 (Singleton)
    • 定义：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
    • 实现方式：
      • 饿汉式：类加载时初始化。
      • 懒汉式：第一次使用时初始化（需注意线程同步）。
      • 注册表方式：通过HashMap维护实例。
  • 3. 建造者模式 (Builder)
    • 定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。
    • 角色：指导者 (Director)、抽象建造者 (Builder)、具体建造者 (ConcreteBuilder)、产品 (Product)。
  • 4. 原型模式 (Prototype)
    • 定义：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
    • 特点：利用Java的clone()方法，分为深克隆和浅克隆。

• 二、结构型模式 (Structural Patterns)

  • 关注点：类或对象的组合，形成更大的结构。
  • 1. 适配器模式 (Adapter)
    • 定义：将一个类的接口转换成客户希望的另外一个接口，解决接口不兼容问题。
    • 分类：类适配器（继承）、对象适配器（组合）。
  • 2. 桥接模式 (Bridge)
    • 定义：将抽象部分与它的实现部分分离，使它们都可以独立地变化。
    • 应用：如Java AWT框架，将组件与其在不同操作系统下的实现分离。
  • 3. 组合模式 (Composite)
    • 定义：将对象组合成树形结构以表示“部分-整体”的层次结构，使用户对单个对象和组合对象的使用具有一致性。
    • 应用：文件系统、JUnit中的TestCase与TestSuite。
  • 4. 装饰模式 (Decorator)
    • 定义：动态地给一个对象添加一些额外的职责。比生成子类更为灵活。
    • 特点：透明围栏，客户分不出组件和装饰后的组件的区别。
  • 5. 外观/门面模式 (Facade)
    • 定义：为子系统中的一组接口提供一个一致的界面，定义高层接口使子系统更易使用。
    • 目的：降低客户与子系统之间的耦合。
  • 6. 享元模式 (Flyweight)
    • 定义：运用共享技术有效地支持大量细粒度的对象。
    • 关键：区分内蕴状态（共享）和外蕴状态（不共享）。
  • 7. 代理模式 (Proxy)
    • 定义：为其他对象提供一种代理以控制对这个对象的访问。
    • 类型：远程代理、虚拟代理、保护代理、智能引用等。

• 三、行为型模式 (Behavioral Patterns)

  • 关注点：对象间的交互和职责分配。
  • 1. 责任链模式 (Chain of Responsibility)
    • 定义：使多个对象都有机会处理请求，将这些对象连成一条链，并沿着这条链传递请求，直到有对象处理它。
  • 2. 命令模式 (Command)
    • 定义：将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化；支持排队、日志和撤销操作。
  • 3. 解释器模式 (Interpreter)
    • 定义：给定一个语言，定义它的文法表示，并定义一个解释器来解释语言中的句子。
  • 4. 迭代器模式 (Iterator)
    • 定义：提供一种方法顺序访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。
  • 5. 中介者/调停者模式 (Mediator)
    • 定义：用一个中介对象来封装一系列的对象交互，使各对象不需要显式地相互引用。
  • 6. 备忘录模式 (Memento)
    • 定义：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。
  • 7. 观察者模式 (Observer)
    • 定义：定义对象间的一种一对多的依赖关系，当一个对象状态改变时，所有依赖者都得到通知并自动更新。
    • 模型：推模型（广播详情） vs 拉模型（观察者主动获取）。
  • 8. 状态模式 (State)
    • 定义：允许一个对象在其内部状态改变时改变它的行为。
    • 对比：与策略模式结构相似，但意图不同（状态是内在变化，策略是外部选择）。
  • 9. 策略模式 (Strategy)
    • 定义：定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。
  • 10. 模板方法模式 (Template Method)
    • 定义：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。
  • 11. 访问者模式 (Visitor)
    • 定义：表示一个作用于某对象结构中的各元素的操作，使你可以在不改变各元素的类的前提下定义新操作。
    • 机制：依赖于“双重分派”技术。

常用的设计模式(10个)

一、 创建型模式 (Creational Patterns)

这类模式主要关注对象的创建过程，旨在将对象的创建与使用分离。

1. 单例模式 (Singleton)

• 概念：保证一个类仅有一个实例，并提供一个访问它的全局访问点。通常用于代表系统中本质上唯一的组件。
• 示例：
  • 系统资源管理：如文件系统、打印机假脱机程序或窗口管理器，在系统中通常只应有一个实例存在。
  • 代码实现：可以通过私有化构造函数，并提供一个静态方法（如 getInstance）来返回唯一的实例（可以是饿汉式或懒汉式实现）。

2. 工厂方法模式 (Factory Method)

• 概念：定义一个用于创建对象的接口，让子类决定实例化哪一个类。这使得一个类的实例化延迟到其子类。
• 示例：
  • 文档应用框架：一个抽象的 Application 类负责管理文档，但它不知道具体的文档类（如 DrawingDocument 或 TextDocument）。它定义一个 CreateDocument 的工厂方法，由子类来实现具体的文档创建逻辑。
  • 暴发户坐车：在这个例子中，工厂方法模式用来创建不同品牌的汽车（如奔驰、宝马），不同的司机子类（工厂子类）负责创建对应的汽车实例。

3. 抽象工厂模式 (Abstract Factory)

• 概念：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。主要用于处理产品族的问题。
• 示例：
  • 多视感标准 UI：支持多种界面风格（如 Motif 和 Presentation Manager）的工具包。定义一个 WidgetFactory 接口，包含创建滚动条、窗口、按钮的操作。具体的子类 MotifWidgetFactory 创建 Motif 风格的组件，而 PMWidgetFactory 创建 PM 风格的组件，客户仅需通过抽象接口与工厂交互。

二、 结构型模式 (Structural Patterns)

这类模式关注类和对象的组合。

4. 适配器模式 (Adapter)

• 概念：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
• 示例：
  • 绘图编辑器：想要复用一个已有的 TextView 类来显示文本，但它的接口与编辑器期望的 Shape 接口不匹配。可以定义一个 TextShape 类（适配器），它继承 Shape 的接口并持有一个 TextView 的实例，将 Shape 的请求（如 BoundingBox）转换为 TextView 的对应操作（如 GetExtent）。
  • USB 转接口：给只提供 USB 充电口的 MP3 播放器配一个充电器转接头，使其能通过普通电源充电。

5. 装饰模式 (Decorator)

• 概念：动态地给一个对象添加一些额外的职责。相比生成子类，这种方式更为灵活。
• 示例：
  • 图形界面组件：一个文本显示视图 TextView 缺省没有滚动条。如果需要添加滚动条或边框，无需创建子类，而是将 TextView 放入 ScrollDecorator 或 BorderDecorator 中。对客户而言，装饰后的对象仍是可视组件，但拥有了新功能。
  • JUnit 测试：TestDecorator 可以给测试用例添加额外行为，例如 RepeatedTest 装饰器可以让一个测试用例重复运行多次。

6. 代理模式 (Proxy)

• 概念：为其他对象提供一种代理以控制对这个对象的访问。代理可以在访问实体前进行预处理或控制。
• 示例：
  • **图片懒加载 (虚代理)**：文档编辑器打开包含大型图片的文档时，为了速度不立即加载图片，而是先创建一个 ImageProxy 替代。只有当用户滚动到该图片需要显示时，代理才真正创建并加载图像对象。
  • **权限控制 (保护代理)**：在论坛系统中，通过代理对象判断用户权限（如注册用户与游客），控制是否允许执行“发帖”等操作。

7. 组合模式 (Composite)

• 概念：将对象组合成树形结构以表示“部分-整体”的层次结构，使用户对单个对象和组合对象的使用具有一致性。
• 示例：
  • 图形系统：Picture（组合对象）可以包含 Line、Rectangle（基本对象）或其他 Picture。用户可以对整个 Picture 调用 Draw 操作，它会自动递归调用所有子部件的 Draw。
  • JUnit：TestSuite 可以包含多个 TestCase 或其他 TestSuite，运行 TestSuite 时会自动运行其包含的所有测试。

三、 行为型模式 (Behavioral Patterns)

这类模式关注对象间的通信、职责分配和算法封装。

8. 策略模式 (Strategy)

• 概念：定义一系列算法，把它们封装起来，并且使它们可相互替换。该模式让算法独立于使用它的客户而变化。
• 示例：
  • 文本换行算法：一个文本排版系统可能支持多种换行策略（如简单换行、TeX 优化换行、数组式换行）。将这些算法封装在不同的 Compositor 子类中，排版对象 Composition 可以根据需要动态切换使用的策略。
  • 布局管理器：Java AWT 中的 LayoutManager 接口有多种实现（FlowLayout, GridLayout），容器将布局行为委托给具体的策略对象。

9. 观察者模式 (Observer)

• 概念：定义对象间的一种一对多的依赖关系，当一个对象状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。
• 示例：
  • 数据与图表：一个电子表格数据对象（目标）可能有多个展示图表（观察者，如柱状图、饼图）。当数据改变时，数据对象通知所有图表，图表自动重绘以反映最新数据。
  • JUnit：TestResult 维护一个 TestListener 列表。当测试失败或结束时，它会通知所有注册的监听器（如打印结果的界面）。

10. 模板方法模式 (Template Method)

• 概念：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
• 示例：
  • 打开文档：抽象类 Application 定义了 OpenDocument 的流程（检查文档、创建对象、读取数据），其中具体的步骤如 DoCreateDocument 或 DoRead 由子类实现，但整体流程由父类控制。
  • JUnit 测试运行：TestCase 类定义了 runBare 方法，依次执行 setUp（初始化）、runTest（运行测试）、tearDown（清理）。用户只需要重写这三个步骤的具体实现，而无需改变执行顺序。

资料

https://refactoringguru.cn/design-patterns
https://design-patterns.readthedocs.io/zh-cn/latest/
https://jueee.github.io/design-patterns/

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

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

按顺序执行

生成结果

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

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