写在前面

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

学习资料

https://www.digitalocean.com/community/conceptual-articles/s-o-l-i-d-the-first-five-principles-of-object-oriented-design
https://www.reddit.com/r/cscareerquestions/comments/13otvbb/could_you_explain_the_5_solid_principles_off_the/?tl=zh-hans
https://www.explainthis.io/zh-hans/swe/solid

写在前面

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

75个顶级思维模型与落地工具全景图

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

在商业决策、创业管理和个人成长中，我们常犯的错误不是不够聪明，而是思维维度的单一。

所谓的“高手”，往往建立了一个跨学科的**“多元思维模型格栅” (Latticework of Mental Models)**。他们不只懂技术，还懂心理学；不只懂管理，还懂系统动力学。

但知道理论只是第一步，如何将抽象的“模型”转化为可执行的“动作”？

本文为您整理了 8大类、75个核心思维模型，并一一映射了业界最成熟的实战方法论与工具。这不仅是一份认知清单，更是创业者和管理者的实战核对表。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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开始一个项目，有这个是很省心的。

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

写在前面

Cursor 有哪些使用技巧？

核心目标：用最少的 Request 消耗，换取最准确的代码产出。
核心原则：AI 不懂就问（Interactive Feedback），人要想好再说（PVE 模式）。

🚀 第一部分：省流攻略 (Save Requests & Tokens)

1. 拒绝 “Auto” 模式，手动分级

痛点：默认的 “Auto” 模式经常在简单问题上杀鸡用牛刀，浪费宝贵的 Fast Request。

• ✅ 最佳实践：
  • **日常开发 (80%)**：强制使用 GPT-4o-mini 或 Claude 3.5 Haiku。用于改 Bug、写注释、简单函数。
  • **攻坚时刻 (20%)**：手动切换到 Claude 3.5 Sonnet。仅用于架构设计、复杂重构。
• 操作：使用快捷键 Cmd + / (Mac) 或 Ctrl + / (Win) 快速切换模型，不要依赖自动路由 1。

2. 启用 Interactive Feedback (MCP) —— 关键技巧

痛点：需求模糊时，AI 靠猜。猜错 = 重写 = 浪费 2-3 次 Request。
原理：利用 MCP 协议，让 AI 在同一个请求内暂停并向你提问，直到确认清楚再写代码。

• ✅ 最佳实践：
  • 配置 interactive-feedback-mcp 服务。
  • Rule设置：在 .cursorrules 中加入：“如果指令不明确，必须调用 interactive_feedback 询问，禁止盲目猜测。”
• 收益：将原本需要 3 轮“生成-纠错-再生成”的交互，压缩为 1 次请求 [User Input, 13]。

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

# 1. clone interactive-feedback-mcp
git clone https://github.com/noopstudios/interactive-feedback-mcp.git
cd interactive-feedback-mcp

# 2. 使用 Python 3.11 创建标准虚拟环境
/opt/homebrew/bin/python3.11 -m venv .venv

# 3. 激活环境（为了确保 pip 指向正确）
source .venv/bin/activate

# 4. 新建requirements.txt，安装依赖
pip install requirements.txt

# 5. 检查是否能成功运行
./.venv/bin/python feedback_ui.py --project-directory "." --prompt "环境安装完毕测试" --output-file "debug_output.json"

# 6. cursor配置mcp
 "interactive-feedback-mcp": {
      "command": "/xxxx/interactive-feedback-mcp/.venv/bin/python",
      "args": [
        "/xxxx/interactive-feedback-mcp/server.py"
      ],
      "cwd": "/xxxx/interactive-feedback-mcp",
      "timeout": 600,
      "autoApprove": [
        "interactive_feedback"
      ]
    }

3. PVE 工作流 (Plan-Verify-Execute)

痛点：想到哪写到哪（Vibe Coding），导致 AI 反复修改同一段代码，Token 爆炸。

• ✅ 最佳实践：
  • **P (Plan)**：先用免费模型（或 mini）让 AI 列出修改计划。
  • **V (Verify)**：人工确认计划无误。
  • **E (Execute)**：开启 Composer (Cmd+I)，一次性把确认好的计划发给 Sonnet 执行。
• 收益：一次成型，拒绝返工 3。

⚡ 第二部分：上下文工程 (Context Management)

1. 必须配置 .cursorignore

痛点：AI 读了 node_modules 或 lock 文件，导致 Token 耗尽且回答变慢。

• ✅ 操作：
  • 在根目录新建 .cursorignore。
  • 填入：node_modules/, dist/, *.json (大文件), logs/。
  • 效果：强制 AI 只看源码，Token 节省 30% 以上 4。

2. 精通 .cursorrules (配置即代码)

痛点：每次都要重复喊“用 TypeScript”、“不要用 Class 组件”。

• ✅ 操作：
  • 根目录新建 .cursorrules 文件。
  • 由简入繁：
    1. 角色：You are a senior expert in [技术栈].
    2. 绝对禁止：No class components. No placeholder comments.
    3. 格式：Only output changed lines. (只输出修改行，极大节省 Output Token) 6。

3. “一次性” 会话原则

痛点：在一个 Chat 窗口聊几天，上下文充满了过时的旧代码，导致 AI 变笨且极其费钱。

• ✅ 操作：
  • Task 完成即销毁：一个功能点 = 一个 Chat。功能做完，立刻 Cmd+L 开新窗口。
  • 及时 Unpin：如果文件不再需要修改，立刻取消 Pin 状态 8。

🛠️ 第三部分：核心工具与技巧 (Tools & Tricks)

1. Composer (Cmd + I) > Chat (Cmd + L)

• Chat 是咨询师（只看不写）：用于问原理、查 Bug。
• Composer 是工程师（直接写）：用于多文件编辑。
• 技巧：
  • Combo 连招：不要分三次改。直接在 Composer 输入：“在 User 表加字段，同步更新 API DTO，并修改前端类型定义。” —— 3 个文件变动，只需 1 次 Request 1。

2. 善用 Plan Mode (Shift + Tab)

• 场景：大功能开发。
• 操作：在 Composer 输入框按 Shift + Tab 进入 Plan Mode。AI 会先扫描代码库，生成 Markdown 格式的待办清单，你确认后它再动手。这比直接写代码更稳，更省重试次数。

📝 总结：开发者自查清单

在开始 coding 前，请确认：

1. [ ] 模型对了吗？ 简单问题切回 mini 了吗？
2. [ ] 规则有了吗？ .cursorrules 和 .cursorignore 配置了吗？
3. [ ] 模式选对了吗？ 多文件修改是否使用了 Composer？
4. [ ] 反馈机制：是否启用了 Interactive Feedback 以防止 AI 瞎猜？
5. [ ] 会话清理：上个任务结束了吗？结束了请开新 Chat。

参考资料

1. Pricing | Cursor Docs
2. Models | Cursor Docs
3. In Cursor, Context is King - DEV Community
4. Codebase Indexing | Cursor Docs
5. Ignore files | Cursor Docs
6. How to Use Cursor More Efficiently - r/ChatGPTCoding
7. .cursorrules · GitHub Gist
8. Understanding Cursor Token Usage - Reddit
9. 4 hacks to turbocharge your Cursor productivity | LaunchDarkly