部署与内容维护指南

网站直接扫描仓库中的 Markdown，不需要维护独立数据库或手工文章列表。新增或修改内容后完成一次生产构建，分类页、侧边栏、搜索索引、文章数量和更新时间会自动更新。

1. 部署网站

1.1 生成静态站点

部署环境建议使用 Node.js 22。首次安装和生产构建：

bash

npm ci
npm run site:build

构建产物位于 .vitepress/dist/。部署平台只需要发布这个目录，不需要在服务器运行 Node.js。

发布前可在本地预览生产产物：

bash

npm run site:preview

1.2 当前生产部署

本站已经使用 Cloudflare Pages 部署：

项目	当前值
公开网站	aisecmap.com
Pages 备用地址	deepresearch-2pc.pages.dev
源代码仓库	`qdsc/deepresearch`（GitHub 私有仓库）
生产分支	`main`
自动部署	推送到 `main` 后由 Cloudflare Pages 构建并发布

Cloudflare 的 GitHub App 仅获得 qdsc/deepresearch 的访问权限。仓库保持私有不会影响静态网站公开访问；Pages 只发布构建产物 .vitepress/dist/，不会把 Git 仓库本身公开。

1.3 Cloudflare Pages、Netlify 或 Vercel

推荐使用这一类静态托管平台：

配置	值
Root directory	仓库根目录
Install command	`npm ci`
Build command	`npm run site:build`
Output directory	`.vitepress/dist`
Node.js	22
`SITE_BASE`	`/`
`SITE_URL`	`https://aisecmap.com`

绑定自定义域名时仍使用 SITE_BASE=/。平台连接代码仓库后，每次推送都可以自动重新构建和发布。

1.4 GitHub Pages

如果站点发布在 https://<user>.github.io/<repository>/，构建时必须设置仓库子路径，并且前后都保留 /：

bash

SITE_BASE=/deepresearch/ npm run site:build

如果仓库名是 <user>.github.io 或使用自定义域名，则使用 SITE_BASE=/。将 .vitepress/dist 作为 Pages Artifact 发布即可。

1.5 自建 Nginx

把 .vitepress/dist 同步到服务器目录，例如 /var/www/ai-security。由于网站使用无扩展名 URL，Nginx 需要同时查找 .html：

nginx

server {
    listen 80;
    server_name ai-security.example.com;
    root /var/www/ai-security;

    location / {
        try_files $uri $uri.html $uri/ =404;
    }
}

生产环境应再配置 HTTPS、缓存策略和访问日志。

2. 给新内容分类

先判断研究产物类型，再选择技术对象：

漏洞、PoC、利用链或具体缓解验证进入 A1-A6。
能力评估、危害度量或社会影响研究进入 B。
红队方法、Payload 语料、Benchmark、防护评测或响应流程进入 C。
外部标准、Crosswalk、治理或仓库规范进入 D。

在 A1-A6 内依次使用三个判据：首个失效的控制或信任边界、主要由谁修复、文章的主要可验证结论。同一文章只选择一个 primary_domain 和一个 subdomain，其他维度使用标签表达。

查看全部可用分类 ID 和当前文章数：

bash

npm run content:categories

常见边界示例：

场景	分类
用户直接绕过模型拒答	A1.1 `model-robustness-alignment`
网页内容被 Agent 当成指令	A5.1 `prompt-context-boundary`
Agent 代码执行沙箱逃逸	A5.5 `agent-runtime-sandbox`
训练集群或 GPU 作业隔离	A4.1 `training-compute-isolation`
恶意 MCP Server 安装包	A3.3 `tools-plugins-servers`
MCP 审批后动态 Schema 变化	A6.2 `mcp-capability-schema`
通用 Prompt Injection Payload 集	C2 `test-corpora-harness`

完整定义和排除边界见各一级分类页及分类与归档规范。

3. 选择存放目录

新研究优先写入定稿后的一级分类目录：

`primary_domain`	Markdown 目录
`model`	`model-security/notes/`
`data`	`data-knowledge-privacy/notes/`
`supply-chain`	`ai-supply-chain-security/notes/`
`infrastructure`	`ai-infrastructure-security/notes/`
`agent`	`agent-security/notes/`
`protocol`	`protocol-identity-security/notes/`
`risk`	`ai-risk-capability/notes/`
`assurance`	`red-team-assurance/notes/`
`standards`	`standards-governance/notes/`

文件名使用描述性的 kebab-case，例如 agent-workspace-symlink-boundary.md。论文和白皮书放入同领域的 papers/，实验代码、PoC 和 Harness 放入 code/；正文使用相对链接引用它们。

4. 创建 Markdown

新文章建议从以下 Frontmatter 开始：

yaml

---
title: Agent Workspace 符号链接边界研究
date: 2026-07-31
updated: 2026-07-31
primary_domain: agent
subdomain: agent-runtime-sandbox
content_type: research-note
lifecycle: [deployment, runtime]
attacker_position: [third-party-content]
trust_boundaries: [sandbox-to-host]
impacts: [confidentiality, integrity]
modalities: [code]
access_level: black-box
atlas_ids: []
owasp_ids: []
evidence: moderate
disclosure_status: public
last_verified: 2026-07-31
verified_targets: [product@version]
affected_targets: [vendor/product@version]
status: maintained
---

时间字段的含义不同：

date：文章首次进入知识库的日期，后续不改。
updated：正文、结论或引用发生实质变化的日期。
last_verified：最后一次重新运行 PoC、实验或版本核验的日期；只改文字时不要更新。

5. 内容写作骨架

A 组：漏洞与技术发现

建议依次包含：结论摘要、研究范围、受影响对象与版本、威胁模型、首个失效的控制、攻击链或复现条件、影响、证据等级、缓解措施、修复验证、外部框架映射和参考资料。

PoC 应写明授权边界、前置条件和非破坏性验证方式。无法公开的细节应说明“未披露”，不要把它写成“未实现”。

B 组：风险与能力研究

建议包含：评估问题、模型与版本、访问权限、任务集合、能力阈值、结果、失败样本、危害解释、限制和可重复性。B 组不保存可直接利用具体产品的步骤。

C 组：方法与评测

建议包含：方法目标、覆盖的威胁模型、Payload/Harness 设计、样本选择、指标、基线、重复次数、评分器、误报漏报、复现命令和适用边界。

D 组：标准与治理

建议包含：标准名称与版本、适用范围、规范性要求、与本仓库分类的双向映射、控制责任方、覆盖缺口和后续版本跟踪点。

6. 发布新内容

不需要手工编辑导航或索引。完成 Markdown 后先在本地验证：

bash

npm run site:build
npm run site:dev

构建会校验 primary_domain、subdomain 和 updated 格式。成功后检查分类页、文章元数据、相对链接和本地搜索，再提交并推送：

bash

git add <修改的文件>
git commit -m "notes: add <研究主题>"
git push origin main

Cloudflare Pages 检测到 main 的新提交后会自动构建。构建成功后，在公开网站检查新文章、所属二级分类、搜索结果和相关资源链接。

7. 更新已有内容

直接编辑原 Markdown，不要创建同一研究的重复副本。更新时：

保留原 date，修改 updated。
只有重新验证攻击或结论时才修改 last_verified 和 verified_targets。
如果根因或主要修复责任方发生变化，重新判断一级和二级分类。
记录新增证据并调整 evidence、disclosure_status 和受影响版本。
运行生产构建；首页排序、分类文章数和搜索索引会自动更新。

部署与内容维护指南 ​

1. 部署网站 ​

1.1 生成静态站点 ​

1.2 当前生产部署 ​

1.3 Cloudflare Pages、Netlify 或 Vercel ​

1.4 GitHub Pages ​

1.5 自建 Nginx ​

2. 给新内容分类 ​

3. 选择存放目录 ​

4. 创建 Markdown ​

5. 内容写作骨架 ​

A 组：漏洞与技术发现 ​

B 组：风险与能力研究 ​

C 组：方法与评测 ​

D 组：标准与治理 ​

6. 发布新内容 ​

7. 更新已有内容 ​

部署与内容维护指南

1. 部署网站

1.1 生成静态站点

1.2 当前生产部署

1.3 Cloudflare Pages、Netlify 或 Vercel

1.4 GitHub Pages

1.5 自建 Nginx

2. 给新内容分类

3. 选择存放目录

4. 创建 Markdown

5. 内容写作骨架

A 组：漏洞与技术发现

B 组：风险与能力研究

C 组：方法与评测

D 组：标准与治理

6. 发布新内容

7. 更新已有内容