规范样例：八份文件
下面是 CampusClaw 项目八份规范文件的索引与用法说明；点开八份文件中的任意一份即为完整原文，可直接照抄。
这是 CampusClaw 项目的一组规范样例文件。它们不是模板，而是「一个真实项目会把规范写成什么样」的实物：每条都带着这个项目的具体事实（目录、接口、命令、阈值），所以每条都能被执行一次来检验。
项目背景
按班级隔离的知识库与解题助手。教师上传本班资料，学生只检索本班的资料并提问，回答必须带出处。
| 形态 | 事实 |
|---|---|
| 部署链路 | 浏览器 → Nginx（web）→ Go（api）→ MySQL（db）与 Qdrant（qdrant） |
| 后端 | backend/cmd/server 入口；backend/internal/{auth,db,materials,knowledge,search,assistant,homework,mcpbridge,httpx,config,openapi} |
| 前端 | React + TypeScript 单页应用，目录 frontend/src/{pages,components,api} |
| 接口测试 | apitest/cases/<URL 路径>/<方法>.json，报告落在 apitest/reports/ |
| 本机入口 | http://localhost:8092/week07/（端口取自 .env 的 WEB_PORT） |
| 启动 | 复制 .env.example 为 .env，填 SESSION_SECRET、SEED_*_PASSWORD、EMBEDDING_API_KEY，然后 docker compose up --build -d |
| 门禁 | 一条命令 make check，任一子项非零退出码即未通过 |
八份文件落在哪里
前五份是必修，后三份是补充（AI 应用、数据、评审与完成定义），视项目性质选择。
| 文件 | 建议位置 | 被谁读到 |
|---|---|---|
01-产品设计规范.md | .cursor/rules/product.mdc | 改 frontend/src 时按 globs 命中 |
02-后端开发规范.md | .cursor/rules/backend.mdc | 改 backend/ 时命中 |
03-安全开发规范.md | AGENTS.md 的「三条硬约束」段 + .cursor/rules/security.mdc | 每次会话都读（常驻） |
04-测试规范.md | .cursor/rules/testing.mdc + 技能「按规范补测试」 | 改 *_test.go 与 apitest/ 时命中 |
05-部署运维规范.md | .cursor/rules/ops.mdc + 技能「按规范发一次版本」 | 改 Dockerfile*、deploy/、docker-compose.yml 时命中 |
06-AI应用规范.md | .cursor/rules/ai.mdc + 技能「改一次提示词并跑评测」 | 改 assistant/、模板与技能文件时命中 |
07-数据规范.md | .cursor/rules/data.mdc + 技能「按规范做一次数据变更」 | 改 db/、knowledge/、uploads/ 时命中 |
08-评审与完成定义规范.md | AGENTS.md 的「门禁 / 提交与评审」段 | 每次会话都读（常驻） |
放法取决于生效时机，不取决于篇幅长短：每次改代码都要遵守的写成规则，只在某个动作里走一遍的写成技能。
怎么用这套样例
- 先不看样例，挑其中一类（建议先做安全开发），按自己的理解写一份规范，每条都带检查方式；
- 再打开同类的样例文件逐条对比：自己的写法缺的是「判据」还是「项目事实」，两类缺失各有几条；
- 最后挑一条，按样例列出的判据在自己的代码上实际执行一次——多数差距在这一步才暴露。
八份样例文件
点开即是一份完整规范文件；建议先自己写，再对照样例。