init: Hugo + Stack 主题 + 首批 3 篇文章 + Gitea Actions 自动部署
- Stack 主题 + 自定义 padding 与标题样式 (assets/scss/custom.scss) - 内容: HTTPS 旅程 / AI 工程师地图 / Xray Reality - 页面: 首页 / 文章 / 归档 / 关于 / 搜索 - CI: Gitea Actions push → hugo --minify → rsync 到 NAS 应用 Gitea Actions 模板 §4.4-4.5 经验: paths-ignore (注意不排除 **.md) + concurrency cancel-in-progress + summary
This commit is contained in:
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: 陶政辰的科普笔记
|
||||
toc: false
|
||||
---
|
||||
|
||||
技术、科普、和一些不太成熟的思考。
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
title: 关于
|
||||
description: 关于陶政辰
|
||||
date: 2026-05-03
|
||||
---
|
||||
|
||||
## 你好 👋
|
||||
|
||||
我是**陶政辰（Zhengchen Tao）**，1996 年生人，山东济南人，现居上海。
|
||||
|
||||
C# / .NET 工程师，9 年+ 后端经验，从 .NET Framework 4.0 一路写到 .NET 10，做过金融系统（前美国 GreenDot 研发中心）、游戏后端、模块化单体架构。前端 React / Vue 也写得动。业余做点自己的小项目。
|
||||
|
||||
## 关于这个站
|
||||
|
||||
这里是我的**笔记 + 科普**外发地。Obsidian 写 markdown 推到 Gitea，Hugo 自动构建到 NAS，nginx 服文件——一条无运行时依赖的静态流水线。
|
||||
|
||||
写的内容大致几类：
|
||||
|
||||
- **科普长文**——拿读者熟悉的东西打比方，把一件事的"全链路"说清楚。比如[一次 HTTPS 请求的完整旅程](/posts/https-journey/)
|
||||
- **技术分析**——读源码、踩坑、做选型时的思路记录
|
||||
- **工程笔记**——HomeLab、网络架构、AI 落地的工程实践
|
||||
- **不太成熟的思考**——大部分被我自己骂回去了
|
||||
|
||||
不追热点，不写"X 分钟看懂 Y"。一篇技术文如果两小时读不完，我宁可先不发。
|
||||
|
||||
## HomeLab
|
||||
|
||||
主力机是一台群晖 DS925+ NAS，跑着 NPM、Immich、Gitea + Actions、Container Registry、Passwall 透明代理、ezBookkeeping + MCP、本地 Ollama 等一堆容器。这个博客本身就跑在它上面（nginx:alpine 容器 + NAS 直挂静态目录）。
|
||||
|
||||
## 联系
|
||||
|
||||
- 邮箱：zhengchen.tao@outlook.com
|
||||
- GitHub：[zhengchentao](https://github.com/zhengchentao)
|
||||
- RSS：[订阅](/index.xml)
|
||||
|
||||
如果文章里有事实/逻辑问题，直接发邮件糊我脸，我喜欢被纠正。
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: 归档
|
||||
description: 文章归档
|
||||
layout: archives
|
||||
slug: archives
|
||||
---
|
||||
@@ -0,0 +1,270 @@
|
||||
---
|
||||
title: "Xray Reality 协议:消除 TLS 指纹的现代代理方案"
|
||||
date: 2023-04-11
|
||||
lastmod: 2026-05-03
|
||||
slug: xray-reality
|
||||
tags: ["TLS", "Xray", "VLESS", "Reality", "X25519", "代理协议"]
|
||||
categories: ["网络协议"]
|
||||
description: "REALITY 协议通过 TLS 1.3 key_share 字段嵌入身份标记 + 主动探测时透明回放真站,从协议层消除 TLS 指纹特征。本文从协议设计到服务端 / 客户端完整搭建。"
|
||||
draft: false
|
||||
---
|
||||
|
||||
> 整理自 [bandwh.com](https://www.bandwh.com/net/994.html)(原文 2023-04-11),本文于 2026-05 重新整理发布。
|
||||
> 适用系统:Debian 11 | Xray 版本:>= 1.8.0
|
||||
> 文中所有 UUID / X25519 密钥均为示例值,实际部署务必使用 `xray uuid` / `xray x25519` 重新生成。
|
||||
|
||||
---
|
||||
|
||||
## 一、背景与原理
|
||||
|
||||
### 1.1 为什么需要 Reality？
|
||||
|
||||
传统 v2ray 方案需要购买域名并生成 TLS 证书,通过各种流量伪装来规避检测。然而随着 DPI 检测能力的升级,**v2ray 的 TLS/XTLS 协议特征已可被精准识别**,导致 VPS 的 443 端口频繁被封锁或阻断。
|
||||
|
||||
Xray 1.8.0 版本推出了全新的 **REALITY 协议**，配合此前的 **Vision 流控**，组成了当前最新的协议组合：
|
||||
```
|
||||
VLESS + Vision + uTLS + REALITY
|
||||
```
|
||||
|
||||
### 1.2 REALITY 的核心优势
|
||||
|
||||
| 特性 | 说明 |
|
||||
|------|------|
|
||||
| 消除 TLS 指纹 | 消除服务端 TLS 指纹特征，令流量与真实网站无异 |
|
||||
| 前向保密 | 仍保有 TLS 前向保密性，历史流量无法被解密 |
|
||||
| 抗证书链攻击 | 证书链攻击无效，安全性超越常规 TLS |
|
||||
| 无需域名 | 指向他人网站的 SNI，无需自己购买域名或配置 TLS |
|
||||
| 中间人防御 | 即使客户端配置泄露,审查方也无法进行有效中间人攻击 |
|
||||
| SNI 阻断消失 | 据实测，使用 Reality 后 SNI 阻断现象消失 |
|
||||
|
||||
### 1.3 使用前提
|
||||
|
||||
- 一台可访问的 VPS（无需域名）
|
||||
- 服务端与客户端 **Xray 均需 >= 1.8.0 版本**
|
||||
- 443 端口不被 Nginx、Caddy 等其他程序占用
|
||||
- **不支持 CDN 代理**(如 Cloudflare 橙云,会终止 TLS 让 Reality 的端到端伪装失效)。CF **灰云(DNS only)** 只做 DNS 解析、不接管流量,等价于直连 VPS,可正常使用
|
||||
|
||||
官方 GitHub：https://github.com/XTLS/REALITY
|
||||
|
||||
---
|
||||
|
||||
## 二、服务端搭建
|
||||
|
||||
### 2.1 安装 Xray
|
||||
|
||||
通过官方脚本安装指定版本：
|
||||
```bash
|
||||
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install --version 1.8.0
|
||||
```
|
||||
|
||||
> `--version 1.8.0` 可按需替换为更新版本号。
|
||||
> 安装完成后，Xray 可执行文件位于 `/usr/local/bin/xray`，配置文件位于 `/usr/local/etc/xray/config.json`。
|
||||
|
||||
### 2.2 生成 UUID
|
||||
|
||||
UUID 用于客户端身份认证：
|
||||
```bash
|
||||
cd /usr/local/bin/
|
||||
./xray uuid > uuid
|
||||
cat uuid # 查看生成的 UUID
|
||||
```
|
||||
|
||||
### 2.3 生成 X25519 公私钥对
|
||||
|
||||
REALITY 使用非对称密钥替代传统 UUID 认证，安全性更高：
|
||||
```bash
|
||||
cd /usr/local/bin/
|
||||
./xray x25519 > key
|
||||
cat key # 查看生成的公钥（PublicKey）和私钥（PrivateKey）
|
||||
```
|
||||
|
||||
> - **PrivateKey（私钥）**：填入服务端配置，务必保密
|
||||
> - **PublicKey（公钥）**：填入客户端配置，可多端共享
|
||||
|
||||
### 2.4 编写服务端配置文件
|
||||
|
||||
**关键要求：** 回落目标网站（`dest`）必须支持 TLSv1.3，建议使用国外知名大站，本例使用 `www.amazon.com`。
|
||||
|
||||
配置文件参数说明：
|
||||
|
||||
| 参数 | 必填 | 说明 |
|
||||
|------|------|------|
|
||||
| `id` | ✅ | 客户端 UUID，由 `xray uuid` 生成 |
|
||||
| `flow` | ❌ | 使用 TCP 时填 `xtls-rprx-vision`；H2 协议留空 |
|
||||
| `dest` | ✅ | 回落的真实境外网站，格式 `域名:443` |
|
||||
| `serverNames` | ✅ | 客户端可用的 SNI 列表，需与 dest 匹配 |
|
||||
| `privateKey` | ✅ | 服务端私钥（Private key） |
|
||||
| `shortIds` | ✅ | 客户端 ID 列表，十六进制，长度为 2 的倍数，上限 16 位 |
|
||||
| `maxTimeDiff` | ❌ | 允许的最大时间差（ms），`0` 为不限，建议设 10000~60000 |
|
||||
| `show` | ❌ | 是否输出调试信息，默认 `false`，排查问题时改为 `true` |
|
||||
|
||||
完整配置示例：
|
||||
```json
|
||||
{
|
||||
"inbounds": [
|
||||
{
|
||||
"listen": "0.0.0.0",
|
||||
"port": 443,
|
||||
"protocol": "vless",
|
||||
"settings": {
|
||||
"clients": [
|
||||
{
|
||||
"id": "94b60beb-a0fd-4aff-9c7c-9a36f74022db",
|
||||
"flow": "xtls-rprx-vision"
|
||||
}
|
||||
],
|
||||
"decryption": "none"
|
||||
},
|
||||
"streamSettings": {
|
||||
"network": "tcp",
|
||||
"security": "reality",
|
||||
"realitySettings": {
|
||||
"show": false,
|
||||
"dest": "www.amazon.com:443",
|
||||
"xver": 0,
|
||||
"serverNames": [
|
||||
"amazon.com",
|
||||
"www.amazon.com"
|
||||
],
|
||||
"privateKey": "UCWnsGnHIqsCgb10JzaL7TaC9pZKJSSax9vW-QbaVkM",
|
||||
"minClientVer": "",
|
||||
"maxClientVer": "",
|
||||
"maxTimeDiff": 0,
|
||||
"shortIds": [
|
||||
"88",
|
||||
"888888"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
],
|
||||
"outbounds": [
|
||||
{
|
||||
"protocol": "freedom",
|
||||
"tag": "direct"
|
||||
},
|
||||
{
|
||||
"protocol": "blackhole",
|
||||
"tag": "blocked"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### 2.5 写入配置并启动
|
||||
|
||||
**写入配置文件：**
|
||||
```bash
|
||||
nano /usr/local/etc/xray/config.json
|
||||
# 粘贴上方配置，Ctrl+X 退出，按 Y 确认保存
|
||||
```
|
||||
|
||||
**服务管理命令：**
|
||||
```bash
|
||||
service xray start # 启动 Xray
|
||||
service xray stop # 停止 Xray
|
||||
service xray restart # 重启 Xray
|
||||
service xray status # 查看运行状态
|
||||
```
|
||||
|
||||
### 2.6 排错方法
|
||||
|
||||
若服务启动报错，可将配置中 `"show": false` 改为 `"show": true`，然后手动运行查看详细日志：
|
||||
```bash
|
||||
/usr/local/bin/xray -c /usr/local/etc/xray/config.json
|
||||
```
|
||||
|
||||
常见问题排查：
|
||||
- 检查 443 端口是否被其他程序占用：`ss -tlnp | grep 443`
|
||||
- 检查配置文件 JSON 格式是否有误（注释需删除）
|
||||
- 确认 `dest` 目标网站支持 TLSv1.3：`curl -v --tlsv1.3 https://www.amazon.com`
|
||||
|
||||
---
|
||||
|
||||
## 三、可选：BBR 加速
|
||||
|
||||
VPS 到国内线路较差时，可安装 BBR 拥塞控制算法提升 TCP 吞吐量：
|
||||
```bash
|
||||
wget --no-check-certificate https://github.com/teddysun/across/raw/master/bbr.sh \
|
||||
&& chmod +x bbr.sh \
|
||||
&& ./bbr.sh
|
||||
```
|
||||
|
||||
安装完成后按提示重启 VPS 即可生效。
|
||||
|
||||
---
|
||||
|
||||
## 四、客户端配置
|
||||
|
||||
### 4.1 客户端通用参数
|
||||
|
||||
连接服务端时需填写以下关键参数：
|
||||
|
||||
| 参数 | 说明 |
|
||||
|------|------|
|
||||
| 地址（Address） | VPS 的 IP 地址 |
|
||||
| 端口（Port） | `443` |
|
||||
| 用户 ID | 服务端配置中的 UUID |
|
||||
| 流控（Flow） | `xtls-rprx-vision` |
|
||||
| 加密（Encryption） | `none` |
|
||||
| 传输协议（Network） | `tcp` |
|
||||
| 安全类型（Security） | `reality` |
|
||||
| SNI | 与服务端 `serverNames` 一致，如 `www.amazon.com` |
|
||||
| 公钥（PublicKey） | 服务端生成的 Public key |
|
||||
| ShortId | 服务端 `shortIds` 中的任意一项，如 `88` |
|
||||
| uTLS 指纹（Fingerprint） | 建议填 `chrome` 或 `firefox` |
|
||||
|
||||
### 4.2 Windows 客户端（V2rayN）
|
||||
|
||||
- 下载地址：https://github.com/2dust/v2rayN/releases
|
||||
- 需使用最新版本，确保内置 Xray-Core >= 1.8.0
|
||||
- 若版本不足，进入「设置」→ 勾选「检查 Pre-Release 版本更新」后更新核心
|
||||
- 操作路径：「服务器」→「添加 [VLESS] 服务器」→ 按上表填写各参数
|
||||
|
||||
### 4.3 Android 客户端（V2rayNG）
|
||||
|
||||
- 下载地址：https://github.com/2dust/v2rayNG/releases
|
||||
- 同样需使用支持 Reality 的最新版本
|
||||
|
||||
### 4.4 路由器端（OpenWrt）
|
||||
|
||||
- 适用于 2023 年 4 月后编译的含 ShadowSocksR Plus+ 的固件
|
||||
- 在插件设置界面中选择 VLESS 协议，填写对应的 Reality 参数
|
||||
|
||||
---
|
||||
|
||||
## 五、安全性深度解析
|
||||
|
||||
### 5.1 为什么使用公私钥而非仅 UUID？
|
||||
|
||||
传统方案若使用对称密钥(UUID),攻击者一旦获取客户端配置,即可实施中间人攻击。
|
||||
|
||||
REALITY 使用 **X25519 非对称密钥 + TLSv1.3 key_share** 机制：
|
||||
- 即使攻击者获取到客户端公钥,也**无法验证某条连接是否属于 REALITY**
|
||||
- 更无法进行有效的中间人攻击
|
||||
|
||||
> REALITY 的设计原则是:**默认假设客户端配置已泄露**,将安全边界收敛至服务端私钥。只要服务端私钥不泄露,流量就是安全的。即使私钥泄露,攻击者也无法直接解密历史流量(前向保密),只能尝试中间人攻击,但中间人需要持有 Reality 私钥才能伪装服务端,这做不到。
|
||||
|
||||
建议：**定期更换公私钥对**，公钥可在多个客户端间安全共享。
|
||||
|
||||
### 5.2 如何解决 TLS in TLS 问题？
|
||||
|
||||
"TLS in TLS" 指内层 TLS 握手特征暴露的问题（即加密套娃特征）。
|
||||
|
||||
REALITY 本身就是 TLS，可直接复用 **XTLS Vision** 的成熟解决方案：Vision 会对内层 TLS 握手包进行**填充处理（不加密，直接发送）**，从而消除 TLS 套 TLS 的可识别特征。
|
||||
|
||||
此外，HTTP/2 与 gRPC 自带多路复用，也可配合 REALITY 使用，进一步优化网络性能。
|
||||
|
||||
---
|
||||
|
||||
## 六、注意事项
|
||||
|
||||
- Reality **不支持 CDN 代理**（如 Cloudflare 橙云），请勿将域名套 CDN 代理使用；CF **灰云（DNS only）**仅做 DNS 解析不接管流量，等同直连 VPS，可以用（CF 在链路里只起 DNS 提供商作用）
|
||||
- `dest` 目标网站必须支持 TLSv1.3，建议选用 `www.amazon.com`、`www.microsoft.com` 等国际知名站点
|
||||
- 服务端 443 端口在使用期间不能被其他程序（Nginx、Caddy 等）占用
|
||||
- 80 端口无特殊要求
|
||||
- 技术持续更新，请关注 Xray 官方仓库获取最新版本信息
|
||||
|
||||
---
|
||||
|
||||
*本文整理自 [bandwh.com](https://www.bandwh.com/net/994.html)，如有更新请以原文为准。*
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,640 @@
|
||||
|
||||
---
|
||||
title: "一份 AI 工程师的知识地图（2026 版）"
|
||||
date: 2026-05-02
|
||||
slug: ai-engineer-map
|
||||
tags: ["AI", "LLM", "Prompt", "RAG", "MCP", "Agent", "Claude", "Cursor", "Ollama"]
|
||||
categories: ["AI"]
|
||||
description: "从大模型 / Prompt / RAG / MCP / Agent / 多模态 / 成本控制 / 编码工具一路捋下来,适合有技术背景的开发者快速建立 AI 知识框架。"
|
||||
draft: false
|
||||
---
|
||||
|
||||
> 适合有一定技术背景的开发者快速建立 AI 知识框架。涵盖核心概念、工程实践、工具选型,持续更新。
|
||||
|
||||
---
|
||||
|
||||
## 一、基础层：大模型
|
||||
|
||||
一切的起点。Claude（Anthropic）、GPT（OpenAI）、Gemini（Google）、DeepSeek、Qwen（阿里）都是"引擎"，通过 API 对外提供服务，上层所有应用都建立在这些模型之上。
|
||||
|
||||
**主流模型对比：**
|
||||
|
||||
| 模型 | 厂商 | 特点 |
|
||||
|------|------|------|
|
||||
| Claude 系列 | Anthropic | 长上下文强、指令遵循准确、代码能力突出 |
|
||||
| GPT-4o / o 系列 | OpenAI | 生态最成熟、多模态能力强、工具链完善 |
|
||||
| Gemini 系列 | Google | 原生多模态、超长上下文（1M token）、深度集成 Google 工具 |
|
||||
| DeepSeek | 深度求索 | 推理能力强、API 价格极低、开源友好 |
|
||||
| Qwen 系列 | 阿里 | 中文效果好、有本地部署版本、国内访问友好 |
|
||||
|
||||
模型能力差距在收窄，但复杂推理、超长上下文、低幻觉率这几个维度顶尖模型依然领先。选型时不能只看价格，要结合实际任务类型判断。
|
||||
|
||||
---
|
||||
|
||||
## 二、理解模型的工作方式
|
||||
|
||||
在用 AI 之前，有两件事必须先搞清楚，否则会踩很多莫名其妙的坑。
|
||||
|
||||
### 上下文窗口（Context Window）
|
||||
|
||||
模型每次能"看到"的文本总量是有上限的，这个上限叫上下文窗口，输入和输出加在一起不能超过这个数。
|
||||
|
||||
**各模型上下文窗口：**
|
||||
|
||||
| 模型 | 上下文窗口 |
|
||||
| ----------------- | ---------- |
|
||||
| GPT-4o | 128K token |
|
||||
| Claude Sonnet 4.6 | 200K token |
|
||||
| Gemini 1.5 Pro | 1M token |
|
||||
| DeepSeek-V3 | 128K token |
|
||||
|
||||
1 token 大约是 0.75 个英文单词，中文每个字大约 1～2 token。200K token 大概是一本 30 万字的书。
|
||||
|
||||
**两个重要的坑：**
|
||||
|
||||
第一，超出窗口后，模型不会报错，而是"忘掉"最早的内容。如果你把一段很长的代码库塞给 AI，它可能已经把最开始的文件内容忘了，给出的建议会出现前后矛盾。
|
||||
|
||||
第二，"Lost in the Middle"问题——研究发现，模型对窗口开头和结尾的内容记忆最好，中间部分最容易被忽略。所以关键信息要放在 prompt 的开头或结尾，而不是埋在中间。
|
||||
|
||||
### AI 幻觉
|
||||
|
||||
模型生成文字的本质是**预测下一个概率最高的 token**，不是在查找事实。这意味着它在不确定的时候不会说"我不知道"，而是倾向于生成一段"听起来合理"的内容。
|
||||
|
||||
**减少幻觉的主要手段：**
|
||||
|
||||
- **RAG**：把真实文档片段塞进 prompt，给模型"答题材料"（详见第四节）
|
||||
- **降低 temperature**：temperature 越低，输出越保守、越确定；越高，越有创意但越容易编造
|
||||
- **Chain of Thought**：让模型先一步步推理，再给结论，减少跳步错误
|
||||
- **引用溯源**：要求模型回答时标注来源段落，可验证
|
||||
- **RLHF 训练**：厂商通过人类反馈训练模型，让它学会说"我不确定"
|
||||
|
||||
幻觉目前无法彻底消除。法律、医疗、财务等高风险场景无论模型多强，都必须有人工审核兜底。
|
||||
|
||||
---
|
||||
|
||||
## 三、Prompt Engineering
|
||||
|
||||
Prompt 是和 AI 沟通的唯一渠道。写得好和写得差，效果差距可以很大。几个立竿见影的技巧：
|
||||
|
||||
### 系统提示词（System Prompt）
|
||||
|
||||
在对话开始前，用系统提示词定义 AI 的角色、能力边界和输出要求。这是最基础也最重要的一步。
|
||||
|
||||
```
|
||||
你是一个游戏后端开发专家，熟悉 .NET 和 SQL Server。
|
||||
回答时：
|
||||
- 使用 C# 代码示例
|
||||
- 指出潜在的性能问题
|
||||
- 如果不确定，直接说不确定，不要猜测
|
||||
```
|
||||
|
||||
### Few-shot 示例
|
||||
|
||||
与其描述你想要什么，不如直接给 2～3 个输入-输出的例子，模型会自动理解规律。
|
||||
|
||||
```
|
||||
将以下日志条目格式化为 JSON：
|
||||
|
||||
输入：[2026-03-18 14:23:01] ERROR UserService 用户登录失败 uid=10234
|
||||
输出：{"time":"2026-03-18 14:23:01","level":"ERROR","service":"UserService","msg":"用户登录失败","uid":10234}
|
||||
|
||||
输入：[2026-03-18 14:25:43] INFO PayService 支付成功 orderId=88765
|
||||
输出：
|
||||
```
|
||||
|
||||
### Chain of Thought（思维链）
|
||||
|
||||
在 prompt 里加上"请一步一步思考"，让模型把推理过程写出来再给结论。对复杂问题效果显著，错误率明显下降。
|
||||
|
||||
```
|
||||
请一步一步分析这段 SQL 的性能问题，然后给出优化建议。
|
||||
```
|
||||
|
||||
### 指定输出格式
|
||||
|
||||
明确告诉模型输出的结构，否则格式会很随意，后续解析麻烦。
|
||||
|
||||
```
|
||||
请用以下 JSON 格式返回结果，不要有其他内容：
|
||||
{
|
||||
"issue": "问题描述",
|
||||
"severity": "high|medium|low",
|
||||
"suggestion": "修复建议"
|
||||
}
|
||||
```
|
||||
|
||||
### 反面示例（告诉模型不要做什么）
|
||||
|
||||
光说"要做什么"有时候不够，同时说"不要做什么"往往更有效。
|
||||
|
||||
```
|
||||
分析这段代码，不要重复我已知的内容，不要给出明显的建议，
|
||||
直接定位最可能导致线上 bug 的地方。
|
||||
```
|
||||
|
||||
### 常见误区
|
||||
|
||||
- **Prompt 越长越好**：不对，冗余信息会稀释关键指令，模型容易抓不住重点
|
||||
- **"请帮我"、"谢谢"有用**：没有，礼貌词不影响输出质量
|
||||
- **一次写好 prompt**：Prompt 是需要反复调试的，像调代码一样迭代
|
||||
|
||||
---
|
||||
|
||||
## 四、核心技术
|
||||
|
||||
### RAG（检索增强生成）
|
||||
|
||||
**解决的问题：** AI 不知道你的内部数据，也不了解你业务的最新状态。
|
||||
|
||||
解法不是训练模型（成本高、周期长、数据泄露风险大），而是在每次查询时，把相关文档片段检索出来，临时塞进 prompt 一起发给 AI。
|
||||
|
||||
**完整流程：**
|
||||
|
||||
```
|
||||
【离线】文档切片 → Embedding 向量化 → 存入向量数据库
|
||||
|
||||
【在线】用户提问 → 问题向量化 → 检索相关片段 → 拼 prompt → AI 生成回答
|
||||
```
|
||||
|
||||
**检索方式要按场景选：**
|
||||
|
||||
| 场景 | 推荐方式 |
|
||||
|------|---------|
|
||||
| 语义模糊查询 | 向量检索 |
|
||||
| 精确关键词匹配 | 全文检索（ES / BM25）|
|
||||
| 结构化数据 | 直接 SQL |
|
||||
| 实时状态数据 | 直接调接口 |
|
||||
|
||||
生产环境通常用**混合检索**（向量 + 关键词并行），再加 **Reranker** 对两路结果重排融合，效果比单一检索稳定得多。
|
||||
|
||||
**RAG 效果差的常见原因：**
|
||||
- 切片粒度不合适：太大检索不精准，太小上下文断裂
|
||||
- Embedding 模型语言不匹配：中文内容要用中文模型
|
||||
- 缺 Reranker：向量相似度不等于语义相关，需要二次排序
|
||||
|
||||
---
|
||||
|
||||
### Function Calling / Structured Output
|
||||
|
||||
**解决的问题：** 默认情况下模型输出自由文本，开发者要从中解析结构化数据很麻烦，而且不稳定。
|
||||
|
||||
Function Calling 让模型直接输出结构化的函数调用参数，或者严格按 JSON Schema 输出。这是开发者在系统里接入 AI 时几乎必用的能力。
|
||||
|
||||
**三种形式：**
|
||||
|
||||
**JSON Mode**：告诉模型必须输出合法 JSON，但不约束具体字段。
|
||||
|
||||
**Function Calling**：你预先定义一组函数和它们的参数 Schema，模型自己判断什么时候调哪个函数，以什么参数调用。
|
||||
|
||||
```csharp
|
||||
// 定义函数供模型选择调用
|
||||
var tools = new[] {
|
||||
new Tool("get_player_info", "查询玩家信息", new {
|
||||
type = "object",
|
||||
properties = new {
|
||||
playerId = new { type = "string", description = "玩家ID" }
|
||||
}
|
||||
})
|
||||
};
|
||||
|
||||
// 模型判断需要查询玩家时，会返回：
|
||||
// { "name": "get_player_info", "arguments": { "playerId": "10234" } }
|
||||
// 你的代码执行后，把结果再传回给模型
|
||||
```
|
||||
|
||||
**Structured Outputs**：最严格的形式，模型输出必须完全符合你指定的 JSON Schema，字段和类型都有保证，不会多也不会少。
|
||||
|
||||
**适合使用的场景：**
|
||||
- 从非结构化文本中提取信息（日志分析、邮件解析）
|
||||
- 让 AI 决策后直接触发业务逻辑
|
||||
- 任何需要程序化处理 AI 输出的场景
|
||||
|
||||
---
|
||||
|
||||
### 多步骤编排
|
||||
|
||||
AI 作为整个流程的指挥者，自主判断下一步做什么、调哪个工具，直到任务完成。
|
||||
|
||||
```
|
||||
用户："分析上个月的流失情况并发报告给运营"
|
||||
↓
|
||||
AI → 调 GetChurnData(month=3)
|
||||
↓
|
||||
AI → 调 GetChurnByServer()
|
||||
↓
|
||||
AI 整合数据，生成分析报告
|
||||
↓
|
||||
AI → 调 SendEmail(to="运营组")
|
||||
```
|
||||
|
||||
Semantic Kernel 的 Plugin 机制就是干这件事的。
|
||||
|
||||
---
|
||||
|
||||
### Fine-tuning（微调）vs RAG
|
||||
|
||||
两者经常被混淆，但解决的是不同问题：
|
||||
|
||||
| 维度 | RAG | Fine-tuning |
|
||||
|------|-----|-------------|
|
||||
| 解决的问题 | 模型不知道你的数据 | 模型不擅长你的任务风格 |
|
||||
| 数据要求 | 文档即可 | 需要大量高质量的输入-输出对 |
|
||||
| 更新成本 | 低，随时更新文档 | 高，每次更新需要重新训练 |
|
||||
| 适合场景 | 知识库问答、文档检索 | 特定领域语气/格式/专业术语 |
|
||||
| 费用 | 低 | 高 |
|
||||
|
||||
**结论：** 绝大多数企业场景先上 RAG，Fine-tuning 只在 RAG 效果不够好、且有大量标注数据的情况下考虑。
|
||||
|
||||
---
|
||||
|
||||
## 五、接入方式
|
||||
|
||||
### 直接调 API
|
||||
|
||||
本质就是一个 HTTPS POST，传 prompt，拿结果。简单、可控、成本透明。
|
||||
|
||||
适合的场景：活动文案生成、内容翻译、用户评论分析、客服自动回复、日志摘要生成等固定业务场景。
|
||||
|
||||
如果公司只用一个模型、场景固定，直接封装一个 `AiService` 类就够了，不需要引入额外框架。
|
||||
|
||||
---
|
||||
|
||||
### Semantic Kernel（编排框架）
|
||||
|
||||
微软出品，支持 .NET / Python / Java，对 .NET 技术栈的团队非常友好。
|
||||
|
||||
类比为 AI 领域的 EF Core——屏蔽不同模型间的 API 差异，业务代码面向接口编程，换模型只改配置。
|
||||
|
||||
```csharp
|
||||
// Program.cs
|
||||
builder.Services.AddKernel()
|
||||
.AddAnthropicChatCompletion("claude-sonnet-4-6", apiKey);
|
||||
|
||||
// Service 层注入使用
|
||||
var result = await kernel.InvokePromptAsync("分析这个玩家的充值行为：{{$input}}");
|
||||
```
|
||||
|
||||
适合场景：多步骤 AI 编排、RAG、需要支持多模型切换的团队项目。
|
||||
|
||||
---
|
||||
|
||||
### MCP（Model Context Protocol）
|
||||
|
||||
Anthropic 于 2024 年 11 月发布的开放协议，定义了"AI 如何标准化调用外部工具"，现已成为全行业事实标准。
|
||||
|
||||
- 2025 年 3 月 OpenAI 全面跟进
|
||||
- 2025 年 12 月捐给 Linux 基金会，OpenAI、Google、微软均为成员
|
||||
- 目前 10,000+ MCP Server，月下载量 9700 万
|
||||
|
||||
```
|
||||
AI 客户端（Claude / Cursor / Antigravity）
|
||||
↓ MCP 协议
|
||||
MCP Server ← 你来实现这一层
|
||||
↓
|
||||
你的业务系统 / 数据库 / 内部接口
|
||||
```
|
||||
|
||||
MCP Server 是独立进程，和现有系统完全解耦，任何语言都能写。写好之后，所有支持 MCP 的 AI 客户端都能调用你的系统。
|
||||
|
||||
**和直接调 API 的本质区别：** 直接 API 是"你的代码决定每一步，AI 只是执行节点"；MCP 是"AI 自己决定走几步、调哪个工具"——控制权从代码转移到了模型。
|
||||
|
||||
---
|
||||
|
||||
### 本地部署（Ollama）
|
||||
|
||||
**解决的问题：** 数据不能出公司网络，或者不想持续付 API 费用。
|
||||
|
||||
Ollama 是一个工具，把主流开源模型打包成可以在本地直接运行的形式，接口和 OpenAI API 完全兼容，切换成本接近零。
|
||||
|
||||
```bash
|
||||
# 安装后一行命令拉模型并启动
|
||||
ollama run qwen2.5:14b
|
||||
|
||||
# 用标准 OpenAI 格式调用本地模型
|
||||
curl http://localhost:11434/v1/chat/completions \
|
||||
-d '{"model":"qwen2.5:14b","messages":[{"role":"user","content":"你好"}]}'
|
||||
```
|
||||
|
||||
**可运行的主流模型：**
|
||||
|
||||
| 模型 | 参数量 | 最低显存 | 特点 |
|
||||
|------|--------|---------|------|
|
||||
| Qwen2.5 | 7B / 14B | 8GB / 16GB | 中文效果好，阿里出品 |
|
||||
| DeepSeek-R1 | 7B / 14B | 8GB / 16GB | 推理能力强，开源 |
|
||||
| Llama 3.3 | 70B | 48GB+ | Meta 出品，综合能力强 |
|
||||
| Mistral | 7B | 8GB | 速度快，适合简单任务 |
|
||||
|
||||
**适合的场景：**
|
||||
- 处理公司内部敏感数据（数据库连接串、用户信息）
|
||||
- 代码补全类任务（质量接近商业模型）
|
||||
- 高频调用、成本敏感的场景（本地跑不计 token 费用）
|
||||
|
||||
**不适合的场景：** 复杂推理、多语言翻译、需要最新知识——这些目前本地模型和顶尖商业模型还有明显差距。
|
||||
|
||||
---
|
||||
|
||||
## 六、多模态
|
||||
|
||||
多模态指模型能同时处理多种类型的数据。目前最成熟的是**文本 + 图像**，主流模型（GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro）都已全面支持。
|
||||
|
||||
**实际能做什么：**
|
||||
|
||||
- **截图转文字**：把 UI 截图发给 AI，让它描述问题或生成对应代码
|
||||
- **图表分析**：把折线图、柱状图截图发给 AI，它能读懂数据并给出分析
|
||||
- **文档图片解析**：扫描件、截图中的表格、合同内容提取，不需要 OCR 前处理
|
||||
- **设计稿转代码**：把 UI 设计图发给 AI，让它生成 HTML/CSS 框架（不是完美的，但能省很多时间）
|
||||
|
||||
**在代码里调用视觉能力：**
|
||||
|
||||
```python
|
||||
import anthropic, base64
|
||||
|
||||
with open("screenshot.png", "rb") as f:
|
||||
img_data = base64.standard_b64encode(f.read()).decode("utf-8")
|
||||
|
||||
client = anthropic.Anthropic()
|
||||
message = client.messages.create(
|
||||
model="claude-sonnet-4-6",
|
||||
messages=[{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{"type": "image", "source": {"type": "base64", "media_type": "image/png", "data": img_data}},
|
||||
{"type": "text", "text": "这个页面的布局有什么问题？"}
|
||||
]
|
||||
}]
|
||||
)
|
||||
```
|
||||
|
||||
**当前局限：** 视频理解在部分模型上支持，但效果不稳定；实时音频目前只有 GPT-4o 的 Realtime API 支持，成本较高。
|
||||
|
||||
---
|
||||
|
||||
## 七、成本控制
|
||||
|
||||
用 API 很容易不知不觉花很多钱，几个实用的省钱方法：
|
||||
|
||||
### 模型路由（按任务难度选模型）
|
||||
|
||||
不是所有任务都需要最贵的模型。建立一个简单的路由规则，根据任务复杂度选不同模型：
|
||||
|
||||
| 任务类型 | 推荐模型 | 大约成本比 |
|
||||
|---------|---------|-----------|
|
||||
| 简单分类、关键词提取 | Claude Haiku / GPT-4o-mini | 1x |
|
||||
| 普通问答、代码补全 | Claude Sonnet / GPT-4o | 10x |
|
||||
| 复杂推理、长文档分析 | Claude Opus / o3 | 50x+ |
|
||||
|
||||
### Prompt 缓存（Cache）
|
||||
|
||||
如果你每次请求都带着相同的系统提示词或大段文档，Anthropic 和 OpenAI 都支持 Prompt Cache——相同内容只计算一次，后续请求的这部分最多打 9 折，最高可省 90% 的输入 token 费用。
|
||||
|
||||
```python
|
||||
# Anthropic Cache Control 示例
|
||||
messages = [{
|
||||
"role": "user",
|
||||
"content": [
|
||||
{
|
||||
"type": "text",
|
||||
"text": very_long_system_doc, # 长文档
|
||||
"cache_control": {"type": "ephemeral"} # 标记为可缓存
|
||||
},
|
||||
{"type": "text", "text": user_question} # 每次变化的问题
|
||||
]
|
||||
}]
|
||||
```
|
||||
|
||||
### Batch API
|
||||
|
||||
对于不需要实时响应的任务（比如批量分析日志、批量生成文案），使用 Batch API 可以享受约 50% 的价格折扣，代价是处理时间延迟到几小时内完成。
|
||||
|
||||
### 控制 Output 长度
|
||||
|
||||
输出 token 的价格通常是输入的 3～5 倍。明确告诉模型输出长度：
|
||||
|
||||
```
|
||||
请用不超过 3 句话回答，不要有多余解释。
|
||||
```
|
||||
|
||||
### Token 计算工具
|
||||
|
||||
OpenAI 和 Anthropic 都提供 Tokenizer 工具，可以在发送前估算费用，避免意外超支。
|
||||
|
||||
---
|
||||
|
||||
## 八、工具生态
|
||||
|
||||
### LlamaIndex
|
||||
|
||||
专注 RAG 场景的 Python 框架，文档处理、向量检索、多路检索融合都做得很深。上手快，适合快速搭 RAG 原型。
|
||||
|
||||
```python
|
||||
# 建索引（离线，跑一次）
|
||||
documents = SimpleDirectoryReader("./docs").load_data()
|
||||
index = VectorStoreIndex.from_documents(documents)
|
||||
|
||||
# 查询（在线，每次请求）
|
||||
query_engine = index.as_query_engine()
|
||||
response = query_engine.query("这个接口的限流规则是什么？")
|
||||
```
|
||||
|
||||
**向量库选型：**
|
||||
|
||||
| 选项 | 适合情况 |
|
||||
|------|---------|
|
||||
| PostgreSQL + pgvector | 已有 PG，成本最低，省事 |
|
||||
| Qdrant | 自部署，高性能，适合大规模 |
|
||||
| Pinecone | 不想运维，直接用云托管 |
|
||||
|
||||
---
|
||||
|
||||
### OpenClaw
|
||||
|
||||
2025 年底爆火的开源 AI Agent，60 天内积累 24.7 万 GitHub Star。核心理念是：**以消息平台作为操作界面，让 AI 替你在本机或服务器上自主执行任务**。
|
||||
|
||||
你不需要打开任何 App，直接在 Telegram、Slack、微信里发一条消息，AI 就能完成文件操作、调接口、发邮件、查数据——完全跑在你自己的机器上，数据不出去。
|
||||
|
||||
**支持 50+ 消息平台：** WhatsApp、Telegram、Slack、Discord、微信（WeCom）、钉钉、飞书、Teams、Signal、iMessage……
|
||||
|
||||
**两种能力扩展机制：**
|
||||
|
||||
- **Skills（技能包）**：结构化的"操作手册"，明确告诉 AI 在特定场景下按什么顺序调哪些工具。社区已有 100+ 预置 Skills，可以自己写，甚至让 AI 来写新的 Skill
|
||||
- **MCP**：对外连接标准协议，把公司内部系统接进来。Skills 解决"什么时候怎么调"，MCP 解决"能不能调"
|
||||
|
||||
**典型使用场景：**
|
||||
- 在 Telegram 里发"帮我拉今天的错误日志，整理成表格"
|
||||
- 定时任务：每天早上自动查数据库、生成日报、发给指定群
|
||||
- 接入公司内部系统，变成团队共用的 AI 助手机器人
|
||||
|
||||
**部署：** 支持 Windows / macOS / Linux 本地部署，也支持阿里云、腾讯云一键部署，国内中文社区资料丰富。底层默认接 Claude，也支持 GPT、DeepSeek、Qwen。
|
||||
|
||||
2026 年 2 月原作者加入 OpenAI，项目移交开源基金会，仍在活跃维护。
|
||||
|
||||
**MiMo Claw（小米）** 是同类产品，深度接入小米生态，一键部署，适合已在用小米设备的用户。
|
||||
|
||||
---
|
||||
|
||||
## 九、企业级 AI 应用场景
|
||||
|
||||
| 场景 | 推荐方案 | 备注 |
|
||||
|------|---------|------|
|
||||
| 智能客服 | 直接调 API + RAG | AI 先回答，答不了查知识库，再不行转人工 |
|
||||
| 活动文案生成 | 直接调 API | 给模板和关键词，批量生成 |
|
||||
| 内部知识库问答 | RAG | 开发文档、运营手册、配置说明 |
|
||||
| 代码 Review | 直接调 API | 提交 PR 时触发，自动给出评审意见 |
|
||||
| 日志分析 / 排障 | 直接调 API + Structured Output | 从非结构化日志提取关键信息 |
|
||||
| 数据分析 | 直接调 API + SQL | 自然语言转 SQL，结果解释成人话 |
|
||||
| 合同 / 文档审查 | RAG | 检索相关条款 + AI 比对分析 |
|
||||
| 跨系统自动化任务 | 多步骤编排 + MCP | 自动拉数据、生成报告、发通知 |
|
||||
| 图片内容审核 | 多模态 API | 截图、UGC 图片内容检测 |
|
||||
| 游戏内容生成 | 直接调 API | NPC 对话、任务描述、世界观文本 |
|
||||
|
||||
---
|
||||
|
||||
## 十、AI 编码工具
|
||||
|
||||
> 模型能力溢出之后，竞争从"谁的模型更聪明"转移到"怎么把模型能力接进工作流"。AI 编码工具是开发者目前最直接感受到生产力变化的地方。
|
||||
|
||||
### ⚠️ 使用前必看：翻墙说明
|
||||
|
||||
**Claude 系（claude.ai、Claude Code）：必须虚拟网卡模式**
|
||||
|
||||
普通代理（SSR、V2Ray 仅配系统代理）大多数情况下无法使用，Claude 会检测 IP 质量。必须使用 **TUN 模式**（虚拟网卡），让所有流量走网卡层，比如 Clash Verge 开启 TUN 模式，或者使用 Warp。
|
||||
|
||||
**其余工具：普通代理即可**
|
||||
|
||||
Cursor、GitHub Copilot、Antigravity、Codex 对代理要求没那么严，配置好系统代理即可。
|
||||
|
||||
---
|
||||
|
||||
### IDE 派
|
||||
|
||||
#### GitHub Copilot
|
||||
|
||||
最老牌的 AI 编码助手，GitHub 出品，深度集成进 VS Code、JetBrains 全家桶、Visual Studio，不需要换编辑器。
|
||||
|
||||
- **行内补全**：预测下一行或下一段，Tab 接受
|
||||
- **Copilot Chat**：侧边栏对话，解释代码、找 Bug、生成测试
|
||||
- **Copilot Edits**：跨多文件批量修改
|
||||
- **Copilot Agent**：自主完成较复杂任务，可以发 PR
|
||||
|
||||
底层以 GPT 系列为主，近期加入 Claude 和 Gemini 可选。
|
||||
|
||||
**价格：** 免费版（2000 次补全 + 50 次 Chat）/ Pro $10/月 / Pro+ $39/月 / 学生免费
|
||||
**翻墙：** 普通代理即可
|
||||
|
||||
---
|
||||
|
||||
#### Cursor
|
||||
|
||||
最早把 AI 深度集成进编辑器的产品，2024 年爆火，目前是这个赛道标杆。基于 VS Code fork，迁移成本接近零。
|
||||
|
||||
- **Tab 补全**：预测整段要改的内容，改了函数签名，调用处参数一并改好
|
||||
- **Cmd+K**：选中代码 + 描述，直接内联修改
|
||||
- **Chat 侧边栏**：带完整代码库索引，跨文件理解逻辑
|
||||
|
||||
底层模型可选：Claude、GPT-4o、DeepSeek 都支持。
|
||||
|
||||
**价格：** 免费版 / Pro $20/月 / Pro+ $60/月（积分制，月积分 = 套餐价美元数）
|
||||
**翻墙：** 普通代理即可
|
||||
|
||||
---
|
||||
|
||||
#### Google Antigravity
|
||||
|
||||
Google 2025 年 11 月随 Gemini 3 发布，VS Code fork，理念比 Cursor 更激进。
|
||||
|
||||
- **Editor 模式**：类似 Cursor，Tab 补全 + 内联改 + 侧边 Agent
|
||||
- **Manager 模式**：同时派发多个 Agent 并行处理不同任务，统一监控
|
||||
|
||||
AI 拥有直接操作文件系统、终端、内置浏览器的权限，同时支持 Claude 和 GPT。
|
||||
|
||||
**价格：** 免费版（重度使用 2-3 小时触达限额，7 天刷新）/ Pro $20/月 / Ultra $250/月
|
||||
**翻墙：** 普通代理即可
|
||||
|
||||
---
|
||||
|
||||
### CLI Agent 派
|
||||
|
||||
> 你说清楚要做什么，AI 自己去读代码、改文件、跑命令，完事汇报。
|
||||
|
||||
#### Claude Code
|
||||
|
||||
Anthropic 出品，目前公认 Agent 能力最强的 CLI 工具。
|
||||
|
||||
```bash
|
||||
claude "找出所有数据库查询超过 500ms 的接口，加上耗时日志并写单元测试"
|
||||
```
|
||||
|
||||
- 完整的文件读写和终端执行权限
|
||||
- 擅长跨文件理解和大范围改动
|
||||
- 支持 MCP，可接入自定义工具
|
||||
- SSH 进服务器也能用
|
||||
|
||||
**价格：** Claude Pro $20/月 起（无免费版），重度用 Max $100/$200/月；也可 API Key 按 token 计费
|
||||
**翻墙：** ⚠️ 必须 TUN 模式虚拟网卡
|
||||
|
||||
---
|
||||
|
||||
#### Codex（OpenAI）
|
||||
|
||||
OpenAI 2025 年 4 月发布，沙箱隔离运行，多任务并行，token 效率约为 Claude Code 的 4 倍。
|
||||
|
||||
**价格：** 工具开源免费，走 ChatGPT Plus（$20/月）或 OpenAI API 额度
|
||||
**翻墙：** 普通代理即可
|
||||
|
||||
---
|
||||
|
||||
### 综合对比
|
||||
|
||||
| 工具 | 类型 | 价格 | 翻墙要求 | 亮点 |
|
||||
|------|------|------|---------|------|
|
||||
| GitHub Copilot | IDE 插件 | 免费 / $10 / $39 | 普通代理 | 不换编辑器，企业管控友好 |
|
||||
| Cursor | IDE（VS Code fork）| 免费 / $20 / $60 | 普通代理 | Tab 补全体验最好，主流首选 |
|
||||
| Antigravity | IDE（VS Code fork）| 免费 / $20 | 普通代理 | 多 Agent 并行，最激进 |
|
||||
| Claude Code | CLI Agent | $20~$200/月 | ⚠️ 必须虚拟网卡 | Agent 能力最强，支持 MCP |
|
||||
| Codex | CLI Agent | API 按量 / $20+ | 普通代理 | token 效率高，沙箱隔离 |
|
||||
|
||||
两个流派不互斥：日常用 Cursor，复杂重构或批量任务丢给 Claude Code。
|
||||
|
||||
---
|
||||
|
||||
## 十一、关键判断：什么时候用什么
|
||||
|
||||
**直接调 API 就够了，当：**
|
||||
业务场景固定、输入输出明确、公司只用一个模型、团队规模小不需要统一抽象。
|
||||
|
||||
**需要引入 Semantic Kernel，当：**
|
||||
需要多步骤编排、做 RAG、在多模型间切换、有多个团队共用 AI 能力。
|
||||
|
||||
**需要 MCP，当：**
|
||||
想让 AI 主动操作你的系统、想让 Cursor / Claude Desktop 直接访问内部数据、在构建 Agent 类产品。
|
||||
|
||||
**需要 RAG，当：**
|
||||
AI 需要访问内部文档或私有知识库、不想训练模型、回答结果需要能溯源到具体文档。
|
||||
|
||||
**用本地部署（Ollama），当：**
|
||||
数据不能出公司网络、高频调用成本敏感、对推理质量要求不是极高。
|
||||
|
||||
**用多模态，当：**
|
||||
需要处理图片内容、截图分析、UI 稿转代码、图表数据提取。
|
||||
|
||||
---
|
||||
|
||||
## 十二、现状与趋势
|
||||
|
||||
**已经发生的：**
|
||||
- MCP 在 16 个月内成为 AI 工具调用的事实标准，速度远超以往任何协议
|
||||
- AI 编码工具从"补全代码"进化到"自主完成任务"，Cursor 的 Tab 到 Claude Code 的 Agent 只用了不到两年
|
||||
- 多模态从实验功能变成了主流模型的标配能力
|
||||
- 模型各家差距在收窄，工具层和工程实践的差异越来越重要
|
||||
|
||||
**正在发生的：**
|
||||
- 多 Agent 并行协作（一个任务拆给多个 AI 同时跑）从实验室走向产品
|
||||
- "Vibe Coding"——用自然语言描述，让 AI 生成整个功能模块——正在成为部分开发者的主力工作方式
|
||||
- 本地部署模型质量快速追赶商业 API，轻量任务本地跑已经够用
|
||||
- 各大云厂商开始把 AI Agent 能力直接内置进开发平台
|
||||
|
||||
**还没解决的：**
|
||||
- 真正落地的企业级 AI 产品依然不多，大部分还在 POC 阶段
|
||||
- 生产环境的效果稳定性、成本控制、幻觉处理依然是难点
|
||||
- AI 有了文件和终端权限之后，安全和误操作风险如何防控
|
||||
- 长上下文场景下的效果一致性：窗口大了不代表记忆力变好
|
||||
@@ -0,0 +1,6 @@
|
||||
---
|
||||
title: 搜索
|
||||
description: 站内搜索
|
||||
layout: search
|
||||
slug: search
|
||||
---
|
||||
Reference in New Issue
Block a user