feat(appendix): 添加多个交互式演示组件，完善 AI/Infra 等章节内容
- 新增 Vibe Coding 全栈相关演示组件 (DeveloperSkillShift, FrontendTriad, BackendCore 等) - 新增 RAG 相关组件 (RAGPipeline, ChunkingStrategy, Retrieval 等) - 新增 Embedding & Vector 相关组件 (EmbeddingConcept, VectorSimilarity 等) - 新增 AI Native App 设计组件 (AINativeArch, PromptDesign 等) - 新增 Infrastructure as Code 组件 (IaCConcept, TerraformWorkflow 等) - 新增 DNS & HTTPS 演示组件 (DnsResolution, HttpsHandshake 等) - 新增 Model Finetuning 组件 (FinetuningPipeline 等) - 更新多个章节的 markdown 内容，集成交互式演示
This commit is contained in:
sanbuphy
@@ -214,7 +214,55 @@ function getPayAmount(employee) {
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
## 5. AI 助力：用大模型提升代码质量
|
||||
|
||||
大模型在代码质量领域已经非常实用，它可以充当你的"24 小时在线的代码审查员"。
|
||||
|
||||
### 5.1 识别代码坏味道
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 请审查以下代码，识别其中的代码坏味道（Code Smell），包括但不限于：
|
||||
> 过长函数、魔法数字、重复代码、过深嵌套、过长参数列表。
|
||||
> 对每个问题给出具体位置、问题描述和改进建议。
|
||||
>
|
||||
> [粘贴你的代码]
|
||||
> ```
|
||||
|
||||
### 5.2 自动重构
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 请对以下代码进行重构，要求：
|
||||
> 1. 不改变外部行为
|
||||
> 2. 使用提炼函数、卫语句替代嵌套等手法
|
||||
> 3. 改善命名，消除魔法数字
|
||||
> 4. 解释每一步重构的理由
|
||||
>
|
||||
> [粘贴你的代码]
|
||||
> ```
|
||||
|
||||
### 5.3 模拟 Code Review
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 请以资深开发者的视角审查这段代码，从以下维度给出反馈：
|
||||
> - 正确性：逻辑是否有 Bug？边界条件是否处理？
|
||||
> - 可读性：命名是否清晰？结构是否易懂？
|
||||
> - 性能：是否有明显的性能问题？
|
||||
> - 安全性：是否有注入或数据泄露风险？
|
||||
> 用"建议"而非"命令"的语气，给出改进方案。
|
||||
>
|
||||
> [粘贴你的代码]
|
||||
> ```
|
||||
|
||||
::: tip AI 使用建议
|
||||
AI 的重构建议需要你自己验证——跑测试确认行为没变。把 AI 当作"提建议的同事"，而不是"无条件信任的权威"。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 6. 总结
|
||||
|
||||
回顾这一路，我们从识别问题到解决问题，建立了一套完整的代码质量改进体系：
|
||||
|
||||
|
||||
@@ -207,7 +207,55 @@ calculatePrice(100, 'svip') // 60
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
## 5. AI 助力：用大模型学习和应用设计模式
|
||||
|
||||
大模型可以帮你识别代码中适合使用设计模式的场景，并给出具体的重构方案。
|
||||
|
||||
### 5.1 识别适用模式
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 分析以下代码，判断是否存在可以用设计模式改进的地方。
|
||||
> 如果有，请说明：
|
||||
> 1. 当前代码的问题
|
||||
> 2. 推荐使用哪种设计模式
|
||||
> 3. 重构后的代码示例
|
||||
> 4. 为什么这个模式适合这个场景
|
||||
>
|
||||
> [粘贴你的代码]
|
||||
> ```
|
||||
|
||||
### 5.2 用具体场景学习模式
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 用一个"外卖点餐系统"的真实场景，分别演示以下设计模式的应用：
|
||||
> - 工厂模式：创建不同类型的订单
|
||||
> - 观察者模式：订单状态变化通知
|
||||
> - 策略模式：不同的配送费计算规则
|
||||
>
|
||||
> 用 JavaScript 代码示例，每个模式先展示不用模式的问题，
|
||||
> 再展示用模式后的改进。
|
||||
> ```
|
||||
|
||||
### 5.3 判断是否过度设计
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 审查以下代码，判断是否存在过度设计的问题。
|
||||
> 是否有不必要的抽象、用不到的设计模式、或过早的优化？
|
||||
> 如果有，请建议如何简化，遵循 KISS 原则。
|
||||
>
|
||||
> [粘贴你的代码]
|
||||
> ```
|
||||
|
||||
::: tip AI 使用建议
|
||||
让 AI 用你熟悉的业务场景来解释设计模式，比看抽象的 UML 图有效得多。但记住：AI 可能倾向于推荐更复杂的方案，你需要自己判断是否真的需要。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 6. 总结
|
||||
|
||||
1. **创建型模式**：解决"如何创建对象"的问题，让创建过程更灵活
|
||||
2. **结构型模式**：解决"如何组织代码"的问题，让结构更清晰
|
||||
|
||||
@@ -142,7 +142,55 @@ git commit -m "fix: 修复 README 中的安装命令拼写错误"
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
## 5. AI 助力：用大模型加速开源贡献
|
||||
|
||||
大模型可以帮你快速理解陌生代码库、写出高质量的 PR 描述、甚至辅助 Code Review。
|
||||
|
||||
### 5.1 快速理解陌生代码库
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 我刚 clone 了一个开源项目，请帮我分析以下目录结构，
|
||||
> 说明每个目录/文件的职责，以及代码的整体架构和数据流向。
|
||||
> 我想修复一个登录相关的 Bug，应该从哪里开始看？
|
||||
>
|
||||
> [粘贴 tree 命令输出或目录结构]
|
||||
> ```
|
||||
|
||||
### 5.2 写 PR 描述
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 根据以下 git diff，帮我写一份 Pull Request 描述，包括：
|
||||
> - 标题（简洁，说明改了什么）
|
||||
> - 改动说明（为什么改、改了什么）
|
||||
> - 测试方法（如何验证改动正确）
|
||||
> - 关联 Issue（如果有）
|
||||
> 用英文撰写，语气专业友好。
|
||||
>
|
||||
> [粘贴 git diff 输出]
|
||||
> ```
|
||||
|
||||
### 5.3 辅助翻译文档
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 将以下中文技术文档翻译为英文，要求：
|
||||
> 1. 技术术语使用业界通用的英文表达
|
||||
> 2. 代码注释和变量名不翻译
|
||||
> 3. 保持 Markdown 格式不变
|
||||
> 4. 语气自然流畅，不要机翻感
|
||||
>
|
||||
> [粘贴中文文档]
|
||||
> ```
|
||||
|
||||
::: tip AI 使用建议
|
||||
用 AI 写 PR 描述时，确保你自己理解了每一行改动。审查者可能会问你为什么这么改——如果你答不上来，说明你还没真正理解。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 6. 总结
|
||||
|
||||
1. **流程**：Fork → Branch → Commit → PR → Review → Merge
|
||||
2. **许可证**：MIT 最宽松，GPL 最严格，根据需求选择
|
||||
|
||||
@@ -148,7 +148,55 @@ Strict-Transport-Security: max-age=31536000
|
||||
|
||||
---
|
||||
|
||||
## 4. 总结
|
||||
## 4. AI 助力：用大模型提升安全防护
|
||||
|
||||
大模型可以充当你的"安全顾问"，帮你审计代码漏洞、生成安全方案。
|
||||
|
||||
### 4.1 代码安全审计
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 请对以下代码进行安全审计，检查是否存在：
|
||||
> - XSS 漏洞（未转义的用户输入）
|
||||
> - SQL 注入（字符串拼接查询）
|
||||
> - CSRF 风险（缺少 Token 验证）
|
||||
> - 敏感数据泄露（硬编码密钥、明文密码）
|
||||
> 对每个问题给出风险等级、具体位置和修复方案。
|
||||
>
|
||||
> [粘贴你的代码]
|
||||
> ```
|
||||
|
||||
### 4.2 生成安全配置
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 我的项目使用 Express.js + PostgreSQL，即将部署上线。
|
||||
> 请生成一份完整的安全配置清单，包括：
|
||||
> - HTTP 安全头配置代码
|
||||
> - CORS 配置
|
||||
> - 数据库连接的安全设置
|
||||
> - 环境变量管理方案
|
||||
> 给出可直接使用的代码片段。
|
||||
> ```
|
||||
|
||||
### 4.3 解释漏洞原理
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 用一个具体的例子，解释 CSRF 攻击的完整流程：
|
||||
> 1. 攻击者如何构造恶意页面
|
||||
> 2. 为什么浏览器会自动携带 Cookie
|
||||
> 3. 服务端如何用 CSRF Token 防御
|
||||
> 用代码演示攻击和防御的完整过程。
|
||||
> ```
|
||||
|
||||
::: tip AI 使用建议
|
||||
AI 的安全审计不能替代专业的安全测试。把它当作第一道筛查，关键系统仍需专业安全团队审计。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
|
||||
1. **安全思维**：永不信任外部输入，最小权限，纵深防御
|
||||
2. **常见攻击**：XSS、SQL 注入、CSRF 是最高频的 Web 安全威胁
|
||||
|
||||
@@ -151,7 +151,58 @@ for (let i = items.length - 1; i >= 0; i--) { ... }
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
## 5. AI 助力：用大模型提升文档质量
|
||||
|
||||
大模型在技术写作领域几乎是"天赋异禀"——生成文档、改善表达、翻译内容都是它的强项。
|
||||
|
||||
### 5.1 生成 API 文档
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 根据以下 Express 路由代码，生成完整的 API 文档，包括：
|
||||
> - 端点路径和方法
|
||||
> - 请求参数（路径参数、查询参数、请求体）及类型
|
||||
> - 成功和错误的响应示例
|
||||
> - 使用 curl 的调用示例
|
||||
>
|
||||
> [粘贴你的路由代码]
|
||||
> ```
|
||||
|
||||
### 5.2 改善技术写作
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 请改善以下技术文档的表达，要求：
|
||||
> 1. 语言简洁清晰，去掉冗余表述
|
||||
> 2. 用主动语态替代被动语态
|
||||
> 3. 专业术语保持准确
|
||||
> 4. 添加必要的代码示例
|
||||
> 保持原意不变，只改善表达质量。
|
||||
>
|
||||
> [粘贴你的文档内容]
|
||||
> ```
|
||||
|
||||
### 5.3 生成 README
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 根据以下项目信息，生成一份高质量的 README.md：
|
||||
> - 项目名称：[名称]
|
||||
> - 一句话描述：[描述]
|
||||
> - 技术栈：[列出]
|
||||
> - 核心功能：[列出]
|
||||
>
|
||||
> 要求包含：项目简介、快速开始、功能特性、
|
||||
> 安装步骤（含代码）、使用示例、贡献指南、许可证。
|
||||
> ```
|
||||
|
||||
::: tip AI 使用建议
|
||||
AI 生成的文档要检查技术细节是否准确——它可能编造不存在的 API 参数或错误的返回值。始终对照实际代码验证。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 6. 总结
|
||||
|
||||
1. **类型匹配**：不同文档有不同的结构和写法
|
||||
2. **清晰优先**：具体、准确、面向读者
|
||||
|
||||
@@ -119,7 +119,55 @@
|
||||
|
||||
---
|
||||
|
||||
## 4. 总结
|
||||
## 4. AI 助力：用大模型辅助技术选型
|
||||
|
||||
大模型可以帮你快速调研技术方案、对比优劣、生成决策报告。
|
||||
|
||||
### 4.1 技术方案对比
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 我需要为一个电商项目选择数据库，候选方案：
|
||||
> MySQL、PostgreSQL、MongoDB。
|
||||
> 项目特点：读多写少、需要复杂查询、数据量预计千万级。
|
||||
>
|
||||
> 请从以下维度对比三个方案：
|
||||
> 性能、生态、学习曲线、运维成本、扩展性。
|
||||
> 用表格形式呈现，并给出最终推荐和理由。
|
||||
> ```
|
||||
|
||||
### 4.2 生成架构决策记录（ADR）
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 帮我写一份架构决策记录（ADR），格式如下：
|
||||
> - 标题：选择 Vue 3 作为前端框架
|
||||
> - 背景：[项目背景和需求]
|
||||
> - 候选方案：React, Vue 3, Svelte
|
||||
> - 决策：Vue 3
|
||||
> - 理由：[基于团队能力、生态、性能等维度]
|
||||
> - 后果：[选择后的影响和风险]
|
||||
> ```
|
||||
|
||||
### 4.3 调研新技术
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 我在考虑是否在项目中引入 Bun 替代 Node.js，请帮我分析：
|
||||
> 1. Bun 相比 Node.js 的核心优势和劣势
|
||||
> 2. 当前生态成熟度（npm 兼容性、主流框架支持）
|
||||
> 3. 生产环境使用的风险点
|
||||
> 4. 适合和不适合使用 Bun 的场景
|
||||
> 给出客观评估，不要只说优点。
|
||||
> ```
|
||||
|
||||
::: tip AI 使用建议
|
||||
AI 的知识有时效性——它可能不了解最新版本的变化。对于快速迭代的技术，用 AI 做初步调研后，务必查阅官方文档确认最新信息。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
|
||||
1. **技术雷达**：了解技术的成熟度，区分采纳/试验/评估/暂缓
|
||||
2. **选型维度**：团队能力 > 社区生态 > 性能需求 > 维护状态
|
||||
|
||||
@@ -149,7 +149,53 @@ TDD 适合逻辑密集的代码（算法、业务规则、数据转换），但
|
||||
|
||||
---
|
||||
|
||||
## 5. 总结
|
||||
## 5. AI 助力：用大模型提升测试效率
|
||||
|
||||
大模型在测试领域的能力已经非常强大——它可以帮你生成测试用例、发现边界条件、甚至写出完整的测试代码。
|
||||
|
||||
### 5.1 生成单元测试
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 请为以下函数编写单元测试，使用 Vitest 框架，要求：
|
||||
> 1. 遵循 AAA 模式（Arrange-Act-Assert）
|
||||
> 2. 覆盖正常路径、边界条件和错误路径
|
||||
> 3. 每个测试用例有清晰的中文描述
|
||||
>
|
||||
> [粘贴你的函数代码]
|
||||
> ```
|
||||
|
||||
### 5.2 发现边界条件
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 分析以下函数，列出所有可能的边界条件和极端输入场景，
|
||||
> 包括：空值、零、负数、超大数、特殊字符、并发情况等。
|
||||
> 对每个场景说明预期行为和可能的风险。
|
||||
>
|
||||
> [粘贴你的函数代码]
|
||||
> ```
|
||||
|
||||
### 5.3 从需求生成测试（TDD 辅助）
|
||||
|
||||
> **提示词**：
|
||||
> ```
|
||||
> 我要实现一个购物车模块，需求如下：
|
||||
> - 添加商品、删除商品、修改数量
|
||||
> - 自动计算总价（含折扣）
|
||||
> - 库存不足时提示错误
|
||||
>
|
||||
> 请按照 TDD 思路，先写出测试用例（不写实现），
|
||||
> 使用 Vitest，覆盖所有核心场景。
|
||||
> ```
|
||||
|
||||
::: tip AI 使用建议
|
||||
AI 生成的测试要检查断言是否有意义——避免 `expect(true).toBe(true)` 这种无效测试。好的测试应该在代码出错时真的能失败。
|
||||
:::
|
||||
|
||||
---
|
||||
|
||||
## 6. 总结
|
||||
|
||||
1. **测试金字塔**：底层多、顶层少，平衡速度与真实度
|
||||
2. **单元测试**：遵循 FIRST 原则和 AAA 模式，测试核心逻辑
|
||||
|
||||
Reference in New Issue
Block a user