Written with AI assistance from the source video. The video is the authority.
18:10Vercel
Log in to leave a comment
No posts yet
非开发人员使用 v0 或 Cursor 这类 Vibe Coding（氛围编程）工具，短短三天就做出了一个相当不错的 Web 应用。老板兴奋不已，嚷嚷着要立刻把它连上生产环境数据库供客户使用。这时，开发团队和 CTO 估计要吓出一身冷汗了。打开 AI 生成的代码一看，里面要么是在客户端组件正中央硬编码了数据库连接字符串（DSN），要么是没有任何校验就直接发送 SQL 查询。
如果就这样直接部署到生产服务器上，出事故只是时间问题。在 OWASP Top 10 for LLM Applications 2025 报告中，也将 AI 生成代码的过度权限授予（LLM06）和输入值未校验（LLM05）列为最危险的安全隐患。实际上，73% 的 Web 应用安全入侵事故都是利用了输入校验缺失这一漏洞。
要想既不打击非开发人员的生产力，又能守住公司的数据库，就必须在原型和数据库之间搭建一层坚固的控制层。
首先要做的是把守住关口，阻止非开发人员制作的应用直接调用数据库。我们需要将 Next.js App Router 的服务端路由处理器（Server Route Handler）作为代理，并在中间使用 Zod 库对传入的数据进行实时校验。TypeScript 的类型检查仅在开发阶段有效，当真实用户发送异常数据时，它并不能防止服务器崩溃。
| 校验项目 | 浏览器 UI 端校验 | 服务端 Zod 代理层 |
|---|---|---|
| 执行位置 | 客户浏览器 | Vercel Serverless 运行时 |
| 安全性 | 极易通过开发者工具绕过 | 在服务端强制拦截以保护 DB |
| 数据校验 | 形式上的文本检查 | 运行时数值范围及类型精细校验 |
| 失败处理 | 页面显示警告文案 | 返回 HTTP 400 并记录 Sentry 错误 |
构建步骤非常简单：
app/api/v1/customer-records/route.ts 文件。companyName 至少 2 个字符以上，contactEmail 必须符合邮箱格式，employeeCount 仅接收正整数。schema.parse() 检查通过 request.json() 接收到的请求。只有通过校验的核心数据才用 Prisma ORM 写入 DB；如果失败，当场抛出 400 错误并直接拦截。除了应用端的校验，数据库本身也要建立防护屏障。如果使用的是基于 PostgreSQL 的 Supabase，Row Level Security (RLS) 设置就是最佳答案。将用户角色信息存入仅管理员可操作的 raw_app_meta_data 中，而不是用户可篡改的 raw_user_meta_data，以此来验证 JWT。
`sql
-- 1. 启用表 RLS
ALTER TABLE public.enterprise_documents ENABLE ROW LEVEL SECURITY;
-- 2. 创建从 JWT 中提取用户角色的函数
CREATE OR REPLACE FUNCTION get_user_role()
RETURNS text AS
LANGUAGE sql STABLE;
-- 3. 仅允许同部门或管理员查询的策略
CREATE POLICY "Department Access Policy" ON public.enterprise_documents
FOR SELECT USING (
get_user_role() = 'admin' OR
department = (current_setting('request.jwt.claims', true)::json->'app_metadata'->>'department')
);
`
做完这项工作后，即使非开发人员不小心将服务角色密钥（Service Role Key）泄露在代码中，其他部门的安全文档也绝不会有泄露的风险。
AI 工具的设计初衷是优先把画面渲染出来，因此它们经常把 API 密钥或 DB 连接字符串写在暴露给浏览器的位置。最常见的错误就是随处加上 NEXT_PUBLIC_ 前缀。在 Next.js 中，带有该前缀的变量会被以明文形式写入浏览器的 JavaScript 文件中。一旦创建了像 NEXT_PUBLIC_OPENAI_API_KEY 这样的变量，任何懂得打开 F12 开发者工具的人都能拿走你的 API 密钥并随意使用。
单看 2026 年 4 月 Vercel 基础设施发生的安全入侵事故就能说明问题。由于集成的第三方 AI 工具权限被攻破，未隐藏的环境变量暴露在外，导致无数团队不得不连夜手动重置 DB 密码和 API 密钥。
靠人工来逐一审核这类错误是不可能的。我们需要在 GitHub Actions 中集成 Gitleaks 静态分析工具，在合并代码前自动进行扫描排查。
`yaml
name: Security Scan
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
gitleaks-scan:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install and Run Gitleaks
run: |
wget https://github.com/gitleaks/gitleaks/releases/download/v8.18.0/gitleaks_8.18.0_linux_x64.tar.gz
tar -xzvf gitleaks_8.18.0_linux_x64.tar.gz
sudo mv gitleaks /usr/local/bin/
gitleaks detect --source=. --verbose --redact --exit-code=1
public-env-check:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Check Unsafe Public Keys
run: |
UNSAFE=(grep -rn "NEXT_PUBLIC_.*\(SECRET\|KEY\|PASSWORD\|TOKEN\|DSN\)" . || true)
if [ -n "UNSAFE" ]; then
echo "클라이언트에 노출된 민감 변수 발견:"
echo "$UNSAFE"
exit 1
fi
`
配置好这个流水线后，只要非开发人员将 API 密钥写进源代码或 NEXT_PUBLIC_ 变量并 Push，部署流程就会被自动拦截。
在 Vercel 控制台注册变量时，也必须明确划分 Development、Preview、Production 作用域。特别是务必勾选 Sensitive Environment Variable 复选框。这样可以对变量进行加密，使其既不会输出在构建日志中，也无法在控制台中复制明文。
当 OpenAI 或 Anthropic 的服务器宕机或响应变慢时，整个 Serverless 处理器都会进入等待状态，从而引发连锁故障。这时需要使用 Node.js 的 opossum 库来设置熔断器（Circuit Breaker）。
`typescript
import CircuitBreaker from 'opossum';
async function callLLM(prompt: string) {
// LLM API 调用逻辑
}
const options = {
timeout: 5000, // 超过 5 秒算作失败
errorThresholdPercentage: 50, // 失败率超过 50% 时打开熔断器
resetTimeout: 30000 // 30 秒后重试
};
const breaker = new CircuitBreaker(callLLM, options);
breaker.fallback(() => ({ error: "AI 响应延迟，请稍后再试。" }));
`
当 API 响应延迟时，可以在 0.1 秒内发送预设好的提示文案，从而防止整个服务崩溃。
为了让非开发人员创作者能第一时间得知故障状况，我们还可以将 Sentry 与 Slack Webhook 连接起来。
`typescript
// app/api/webhooks/sentry-to-slack/route.ts
import { NextResponse } from 'next/server';
export async function POST(request: Request) {
try {
const event = await request.json();
const webhookUrl = process.env.SLACK_INCOMING_WEBHOOK_URL;
if (!webhookUrl) return NextResponse.json({ error: '无 Webhook' }, { status: 500 });
const title = event.data?.issue?.title || '未知系统错误';
const issueUrl = event.data?.issue?.permalink || '#';
await fetch(webhookUrl, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
blocks: [
{
type: 'header',
text: { type: 'plain_text', text: '🚨 生产环境发生错误' }
},
{
type: 'section',
text: { type: 'mrkdwn', text: `*错误内容:*
${title}` }
},
{
type: 'actions',
elements: [
{
type: 'button',
text: { type: 'plain_text', text: '查看 Sentry 报告' },
url: issueUrl,
style: 'danger'
}
]
}
]
})
});
return NextResponse.json({ success: true });
} catch (err) {
return NextResponse.json({ error: 'Webhook 失败' }, { status: 500 });
}
}
`
当错误扩大导致主页无法打开、发生 P1 级别的故障时，甚至不需要等待开发人员。Vercel 会完好地保存历史部署版本，只需点击几次就能恢复到上一个状态。
只需等待 30 秒，域名路由就会切换到之前的版本。只要具备了 Zod 校验、Gitleaks 扫描以及 Vercel 回滚流程，就能在放手让非开发人员尽情制作应用的同时，自己也能高枕无忧了。