marcelrapold/auditor
GitHub: marcelrapold/auditor
一套将 AI 编程 agent 转化为多领域专家审计群体的主提示词库，通过证据绑定和对抗性验证生成高质量的工程审计报告与可操作的修复路线图。
Stars: 0 | Forks: 0
# 审计员
将任何 AI 编程 agent 转化为专家 auditor 群体的主提示词 —— 涵盖安全、
工程、前端、API、性能、数据、基础设施、AI/LLM、合规性、可访问性、
文档、内容和精益。
[](https://github.com/marcelrapold/auditor/releases)
[](LICENSE)
[](https://github.com/marcelrapold/auditor/commits)
[](audit-prompts)
[](DOCUMENTATION-STANDARD.md)
[](ISSUE-OUTPUT-STANDARD.md)
[](https://auditor.rapold.io)
*图 1. auditor 的工作原理：一个标准加上一个模板，引导 AI agent 群体在目标上工作，
生成评分报告和 GitHub issues（德语或英语）。*
```
flowchart LR
Standards["Standards
(documentation,
issue-output)"] --> Prompt Target["Target repo / app / API"] --> Agent Prompt["Audit template
(1 of 13)"] --> Agent["AI agent swarm
(parallel + adversarial)"] Agent --> Report["Report +
scorecard"] Agent --> Issues["GitHub issues
(tracker + findings, DE/EN)"] ``` ## 目录 - [概述](#overview) - [审计库](#the-audit-library) - [从你的 AI agent 运行](#run-it-from-your-ai-agent) - [实战示例：审计此代码库](#worked-example-auditing-this-repo) - [快速入门](#quickstart) - [工作原理](#how-it-works) - [Issue 输出](#issue-output) - [标准](#standards) - [只读与授权](#read-only-and-authorization) - [仓库布局](#repository-layout) - [贡献](#contributing) - [更新日志与许可证](#changelog-and-license) ## 概述 本仓库中的每个提示词都强制执行顶级审查委员会所要求的工程规范： - **没有证据就等于没发生。** 每个发现都引用了具体的工件 —— `file:line`、query 计划、请求/响应、配置值、测量指标。没有证据的发现将被丢弃。 - **对抗性自我挑战。** 只有在独立的怀疑者 agent 尝试反驳之后，发现才能成立。这是抵御导致大多数 AI 审计 毫无意义的误报的最强有力防御。 - **盲点搜寻。** 完整性审查员在每一轮都会询问哪些表面、用例或 假设未被检查。未检查的区域会被声明，绝不隐藏。 - **最大化并行。** 工作同时分发给许多专家 agent（Claude Code `ultracode` / Workflow 模式），然后通过流水线进行逐个发现的验证。 - **标准化流程。** 每次审计都运行相同的阶段，并将发现映射到公认的 标准（OWASP、CWE、MITRE ATT&CK、WCAG、CIS、DORA、RFC、GDPR）。 - **可操作输出。** 严重性评分登记表、30/60/90 路线图以及由优先级排序的 tracker 主导的 GitHub issues（德语 或英语）。 这里的门槛是“Google 级别”：精准、可重现、不恐慌、不忽悠，每一条建议 都能立即付诸实践。 ## 审计库 所有模板都不受技术栈、框架和产品的限制，并共享同一种方法论，因此当你在同一目标上 运行多个审计时，发现可以完美组合。 | 模板 | 审计范围 | 映射至 | 输出 | |---|---|---|---| | [`security`](audit-prompts/security-audit-master-prompt.md) | 跨 14 个领域的安全性：注入、authN/authZ、机密、供应链、IaC、CI/CD、API、业务逻辑、隐私、LLM | OWASP Top 10 / API / ASVS / LLM, CWE-25, MITRE ATT&CK, CIS, GDPR | Issues + 评分卡 (DE/EN) | | [`repo`](audit-prompts/repo-audit-master-prompt.md) | 全仓库工程：架构、技术栈一致性、文档、测试、依赖、CI/CD、可观测性、git 卫生 | Google 工程实践, SRE, SLSA, OWASP | 面板级报告 | | [`frontend`](audit-prompts/frontend-audit-master-prompt.md) | 16-agent 前端扫描：可用性、心理学、视觉设计、a11y、性能、SEO、文案、CRO、IA、表单、信任 | Nielsen, WCAG 2.2, Core Web Vitals | 优先级排序的 backlog + 评分卡 | | [`api`](audit-prompts/api-audit-master-prompt.md) | API 设计：资源建模、HTTP 语义、错误模型、版本控制、幂等性、速率限制、schema、DX | RFC 9110/9457, OpenAPI 3.1, GraphQL, Google AIP | 契约偏差矩阵 + 路线图 | | [`performance`](audit-prompts/performance-audit-master-prompt.md) | 性能与可扩展性：热点、N+1、缓存、并发、泄漏、负载行为、弹性、FinOps | SRE 实践, DORA, 负载/延迟 SLOs | 瓶颈图 + 单项修复指标提升 | | [`data`](audit-prompts/data-audit-master-prompt.md) | 数据与数据库：建模、类型、约束、迁移安全性、事务、完整性、备份/灾难恢复 | 规范化, ACID/CAP, RLS, expand/contract | 实体风险图 + 安全迁移计划 | | [`infrastructure`](audit-prompts/infrastructure-audit-master-prompt.md) | 基础设施/DevOps/SRE：IaC、云安全、IAM、机密、容器、k8s、CI/CD、HA、灾难恢复、可观测性、成本 | CIS Benchmarks, Well-Architected, SLSA, DORA | 影响范围图 + 路线图 | | [`ai-llm`](audit-prompts/ai-llm-audit-master-prompt.md) | AI/LLM：prompt 注入、越狱、输出处理、agent/工具安全、RAG、幻觉、评估、成本 | OWASP LLM Top 10, NIST AI RMF | 信任边界图 + 防护/评估轨道 | | [`compliance-privacy`](audit-prompts/compliance-privacy-audit-master-prompt.md) | 隐私：合法依据、同意/cookies、数据主体权利、保留、传输、违规响应准备 | GDPR, ePrivacy/TTDSG, EU AI Act, CCPA, HIPAA/PCI | RoPA/数据流图 + 条款映射的路线图 | | [`accessibility`](audit-prompts/accessibility-audit-master-prompt.md) | 深度 a11y：语义、键盘、焦点、屏幕阅读器、对比度、表单、缩放、运动、动态、认知 | WCAG 2.2 AA/AAA, EAA 2025, EN 301 549, ADA/508 | WCAG 合规表 + 路线图 | | [`documentation`](audit-prompts/documentation-audit-master-prompt.md) | 对照标准检查文档质量：元数据、新手引导、文档与代码的偏差、写作、Diátaxis、代码库健康度 | DOCUMENTATION-STANDARD.md, Diátaxis, Google 风格 | 评分量表 + 德语 issues | | [`content`](audit-prompts/content-audit-master-prompt.md) | 内容与信息传达：论点挑战、受众契合度、证据与原创性、结构、语调、行级重写 | E-E-A-T, BLUF, 认知阶段, 修辞 | 评分卡 + 修改前后重写对比 | | [`lean`](audit-prompts/lean-audit-master-prompt.md) | 仓库精简度：死代码、未使用/幽灵依赖、重复、AI 垃圾内容、依赖透明度、安全精简 —— 防止过度删除 | SWE@Google (废弃/依赖), OWASP Component Analysis, SLSA, YAGNI, Chesterton's Fence | 移除登记表 (4 级) + 评分卡 | ## 从你的 AI agent 运行 将任何有能力的 agent 指向实时入口点 —— 无需安装： agent 将获取编排器 ([`full-audit-master-prompt.md`](audit-prompts/full-audit-master-prompt.md)，位于 [`auditor.rapold.io/llms.txt`](https://auditor.rapold.io/llms.txt))，询问你的输出语言 (Deutsch / English) 以及要运行哪些审计（或整个代码库），然后提交一个合并的、 按优先级排序的 issue backlog。 ## 实战示例：审计此代码库 该库在自身上进行了内部测试。针对 `auditor` 端到端运行编排器产生了 一个跨审计的合并 backlog —— 这是输入到 issues 循环的具体追踪记录： - **输入。** 将 agent 指向该仓库。Phase 0 侦察选择了七个适用的审计，并 声明了四个**不适用，并附有原因**（无运行时 API、无数据库、无仓库内 LLM 运行时、无个人数据），而不是默默地跳过它们。 - **评分卡。** documentation A (94), accessibility A (93), performance A (92), security A (91), repo / frontend / infrastructure A- (90) —— 零个 P0，一个 P1。 - **跨审计去重。** “`CHECKSUMS.txt` 未在 CI 中验证”被 repo、infrastructure 和 security 视角独立发现，并合并为一个包含所有三个 引用的单个 backlog 项目 —— 这是协同运行审计的成果。 - **输出。** 一个主追踪 issue，加上每个发现对应一个 issue，每个都包含管理摘要、 证据 (`file:line`)、修复前后的对比、工作量预估和重新审计标准。 在 GitHub 上查看运行结果：[master tracker #97](https://github.com/marcelrapold/auditor/issues/97) （评分卡、合并的 backlog 以及 30/60/90 路线图）及其链接的各个发现 issue。 ## 快速入门 **前提条件：** 一个强大的 AI 编程 agent；如果你目标是 GitHub URL 或希望审计提交 issues，则需要安装并验证 [GitHub CLI](https://cli.github.com) (`gh`)； 并且对目标仓库具有写入权限以进行 issue 阶段。 1. **在目标的工作目录中打开你的 AI 编程 agent**，或者提供一个 GitHub URL。 2. **完整粘贴所选的主提示词**（在 GitHub 上打开文件并选择“Copy raw file”）， 然后在其顶部的配置块中填空 —— 每个提示词都以下面的内容开始： TARGET: <本地仓库路径或 GitHub URL> SCOPE: <整个仓库 | 特定流程/路径> STACK: <语言、框架、云 —— 或让 Phase 0 推断> AUDIENCE: <目标受众，如果已知> DATA_ACCESS: <可以运行 / 主动测试？还是只读> OUTPUT_LANG:
ISSUE_TARGET:
3. **让它运行。** 它会构建事实表，分发专家 agent，进行交叉融合和
去重，对抗性地验证每一个严重发现，与最佳实践进行基准对比，然后
综合报告和路线图。
4. **审查 issues。** 每次审计都会预览一个按优先级排序的追踪 issue 以及每个发现对应的 issue
（使用你选择的语言），并且只有在你的明确批准下才会创建它们。
要全面了解生产系统，请运行 `repo` + `security` + `performance` + `data` +
`infrastructure`（以及适用的 `frontend` / `api` / `ai-llm` / `compliance-privacy` / `accessibility` /
`documentation`）。每项都会产生独立的报告和 issue 集。
## 工作原理
每个模板都运行相同的阶段：
```
Phase 0 Reconnaissance factual inventory + attack/surface map (no opinions yet)
Phase 1 Specialist swarm many domain experts run IN PARALLEL, each evidence-bound
Phase 2 Cross-pollination merge + dedupe + surface compound findings
Phase 3 Adversarial verify independent skeptics try to REFUTE each P0/P1; ≥2/3 to survive
Phase 4 Benchmark compare against named best-in-class references & standards
Phase 5 Synthesis report, scorecard, issues, 30/60/90 roadmap
```
*图 2. 六阶段方法：并行专家参与，然后在进行报告之前进行
对抗性验证。*
```
flowchart LR
P0["Phase 0
Recon &
surface map"] --> P1 subgraph P1["Phase 1 — parallel specialist swarm"] direction TB A1["Specialist A"] A2["Specialist B"] A3["Specialist C"] A4["Specialist …N"] end P1 --> P2["Phase 2
merge ·
dedupe ·
compound"] P2 --> P3{"Phase 3
adversarial
verify · ≥2/3?"} P3 -- "refuted" --> KILL["Killed
(appendix +
refutation)"] P3 -- "survives" --> P4["Phase 4
benchmark vs
best-in-class"] P4 --> P5["Phase 5
report · scorecard ·
issues · roadmap"] P5 -. "blind-spot critic:
what did we miss?" .-> P1 ``` 严重性是标准化的（从 P0 致命到 P3 优化），每个发现都带有工作量预估和 ICE/优先级评分，路线图 始终是 Quick Wins → 30 → 60 → 90 天，感知依赖关系，并贯穿追踪发现 ID。每份 报告都以诚实的“覆盖范围与局限性”部分结束；将未审计的区域报告为 “良好”将被视为审计失败。 ## Issue 输出 验证后，每次审计都会根据 [`ISSUE-OUTPUT-STANDARD.md`](ISSUE-OUTPUT-STANDARD.md) 生成 GitHub issues： 1. **首先是追踪 issue** —— 所有子任务的索引，按优先级 (P0→P3) 排序，包含 管理摘要、评分卡和 30/60/90 路线图。每个清单行都链接到其子 issue。 2. **每个确认的发现对应一个 issue** —— 德语，顶尖的文档质量，每一个都以自己的 管理摘要开头，然后是严重性、证据、具体的修复前后对比、工作量和 重新审计标准。 Issues 默认为德语（每次运行可配置），先预览，仅在明确 授权后创建。 ## 标准 两项规范性标准约束着审计，并且可以独立重用： - [`DOCUMENTATION-STANDARD.md`](DOCUMENTATION-STANDARD.md) (德语) 和 [`DOCUMENTATION-STANDARD.en.md`](DOCUMENTATION-STANDARD.en.md) (英语) —— 一个 Google 级别的 文档，包含五种仓库配置文件和 0–100 的评分量表。`documentation` 审计将其作为衡量标准。 - [`ISSUE-OUTPUT-STANDARD.md`](ISSUE-OUTPUT-STANDARD.md) —— 强制性的追踪 issue + 每次审计都遵循的每个发现对应 issue 的契约。 随时可用的 README 骨架位于 [`templates/README.template.md`](templates/README.template.md)。 ## 只读与授权 这些审计默认是非破坏性和只读的： - 对代码、配置、schema 和 IaC 的静态分析不需要特殊权限。 - 主动或动态测试（DAST、负载测试、注入/越狱探测、实时云或 DB 访问）需要所有者的明确、书面授权。如果没有授权，提示词将 回退到静态推理并标记出该限制。 - 不使用破坏性技术，不进行 DoS，不进行数据窃取。真实的机密和 PII 永远不会被复制 到报告中 —— 引用位置并隐去值。 - 创建 issues 是先预览，并受限于明确批准。 仅在你拥有或被授权评估的系统上使用这些审计。 ## 仓库布局 ``` auditor/ ├── README.md you are here ├── ARCHITECTURE.md monorepo structure + design decisions ├── DOCUMENTATION-STANDARD.md the doc standard (German, canonical) ├── DOCUMENTATION-STANDARD.en.md the doc standard (English mirror) ├── ISSUE-OUTPUT-STANDARD.md mandatory issue output for all audits ├── CONTRIBUTING.md how to contribute templates and docs ├── CODE_OF_CONDUCT.md Contributor Covenant ├── SECURITY.md how to report a vulnerability ├── CHANGELOG.md Keep a Changelog format ├── templates/ │ └── README.template.md canonical README skeleton ├── .github/ │ ├── workflows/docs.yml docs CI (markdown lint, link-check, emoji guard) │ ├── PULL_REQUEST_TEMPLATE.md │ └── ISSUE_TEMPLATE/ findings + new-template + chooser config ├── web/ landing page (Next.js 16) → auditor.rapold.io └── audit-prompts/ ├── full-audit-master-prompt.md (orchestrator) ├── security-audit-master-prompt.md ├── repo-audit-master-prompt.md ├── frontend-audit-master-prompt.md ├── api-audit-master-prompt.md ├── performance-audit-master-prompt.md ├── data-audit-master-prompt.md ├── infrastructure-audit-master-prompt.md ├── ai-llm-audit-master-prompt.md ├── compliance-privacy-audit-master-prompt.md ├── accessibility-audit-master-prompt.md └── documentation-audit-master-prompt.md ``` 着陆页位于 `web/` —— 其技术栈、本地开发和部署记录在 [`web/README.md`](web/README.md) 中。 ## 贡献 新模板遵循内部结构，以便它们与其余部分组合：使命 + 通用性、 操作原则、P0–P3 严重性等级、Phase 0–5 流水线、共享的发现 schema、 强制性的 issue 输出块以及 Definition of Done。保持它们与提供商无关，将发现 映射到公认的标准，并使每一条建议都能立即付诸实践。参见 [`CONTRIBUTING.md`](CONTRIBUTING.md)，并遵循 [`DOCUMENTATION-STANDARD.md`](DOCUMENTATION-STANDARD.md) 处理所有 Markdown —— 包括标题中不使用表情符号。 ## 更新日志与许可证 更改记录在 [`CHANGELOG.md`](CHANGELOG.md) 中（Keep a Changelog；SemVer）。根据 MIT 许可 —— 参见 [`LICENSE`](LICENSE)。
(documentation,
issue-output)"] --> Prompt Target["Target repo / app / API"] --> Agent Prompt["Audit template
(1 of 13)"] --> Agent["AI agent swarm
(parallel + adversarial)"] Agent --> Report["Report +
scorecard"] Agent --> Issues["GitHub issues
(tracker + findings, DE/EN)"] ``` ## 目录 - [概述](#overview) - [审计库](#the-audit-library) - [从你的 AI agent 运行](#run-it-from-your-ai-agent) - [实战示例：审计此代码库](#worked-example-auditing-this-repo) - [快速入门](#quickstart) - [工作原理](#how-it-works) - [Issue 输出](#issue-output) - [标准](#standards) - [只读与授权](#read-only-and-authorization) - [仓库布局](#repository-layout) - [贡献](#contributing) - [更新日志与许可证](#changelog-and-license) ## 概述 本仓库中的每个提示词都强制执行顶级审查委员会所要求的工程规范： - **没有证据就等于没发生。** 每个发现都引用了具体的工件 —— `file:line`、query 计划、请求/响应、配置值、测量指标。没有证据的发现将被丢弃。 - **对抗性自我挑战。** 只有在独立的怀疑者 agent 尝试反驳之后，发现才能成立。这是抵御导致大多数 AI 审计 毫无意义的误报的最强有力防御。 - **盲点搜寻。** 完整性审查员在每一轮都会询问哪些表面、用例或 假设未被检查。未检查的区域会被声明，绝不隐藏。 - **最大化并行。** 工作同时分发给许多专家 agent（Claude Code `ultracode` / Workflow 模式），然后通过流水线进行逐个发现的验证。 - **标准化流程。** 每次审计都运行相同的阶段，并将发现映射到公认的 标准（OWASP、CWE、MITRE ATT&CK、WCAG、CIS、DORA、RFC、GDPR）。 - **可操作输出。** 严重性评分登记表、30/60/90 路线图以及由优先级排序的 tracker 主导的 GitHub issues（德语 或英语）。 这里的门槛是“Google 级别”：精准、可重现、不恐慌、不忽悠，每一条建议 都能立即付诸实践。 ## 审计库 所有模板都不受技术栈、框架和产品的限制，并共享同一种方法论，因此当你在同一目标上 运行多个审计时，发现可以完美组合。 | 模板 | 审计范围 | 映射至 | 输出 | |---|---|---|---| | [`security`](audit-prompts/security-audit-master-prompt.md) | 跨 14 个领域的安全性：注入、authN/authZ、机密、供应链、IaC、CI/CD、API、业务逻辑、隐私、LLM | OWASP Top 10 / API / ASVS / LLM, CWE-25, MITRE ATT&CK, CIS, GDPR | Issues + 评分卡 (DE/EN) | | [`repo`](audit-prompts/repo-audit-master-prompt.md) | 全仓库工程：架构、技术栈一致性、文档、测试、依赖、CI/CD、可观测性、git 卫生 | Google 工程实践, SRE, SLSA, OWASP | 面板级报告 | | [`frontend`](audit-prompts/frontend-audit-master-prompt.md) | 16-agent 前端扫描：可用性、心理学、视觉设计、a11y、性能、SEO、文案、CRO、IA、表单、信任 | Nielsen, WCAG 2.2, Core Web Vitals | 优先级排序的 backlog + 评分卡 | | [`api`](audit-prompts/api-audit-master-prompt.md) | API 设计：资源建模、HTTP 语义、错误模型、版本控制、幂等性、速率限制、schema、DX | RFC 9110/9457, OpenAPI 3.1, GraphQL, Google AIP | 契约偏差矩阵 + 路线图 | | [`performance`](audit-prompts/performance-audit-master-prompt.md) | 性能与可扩展性：热点、N+1、缓存、并发、泄漏、负载行为、弹性、FinOps | SRE 实践, DORA, 负载/延迟 SLOs | 瓶颈图 + 单项修复指标提升 | | [`data`](audit-prompts/data-audit-master-prompt.md) | 数据与数据库：建模、类型、约束、迁移安全性、事务、完整性、备份/灾难恢复 | 规范化, ACID/CAP, RLS, expand/contract | 实体风险图 + 安全迁移计划 | | [`infrastructure`](audit-prompts/infrastructure-audit-master-prompt.md) | 基础设施/DevOps/SRE：IaC、云安全、IAM、机密、容器、k8s、CI/CD、HA、灾难恢复、可观测性、成本 | CIS Benchmarks, Well-Architected, SLSA, DORA | 影响范围图 + 路线图 | | [`ai-llm`](audit-prompts/ai-llm-audit-master-prompt.md) | AI/LLM：prompt 注入、越狱、输出处理、agent/工具安全、RAG、幻觉、评估、成本 | OWASP LLM Top 10, NIST AI RMF | 信任边界图 + 防护/评估轨道 | | [`compliance-privacy`](audit-prompts/compliance-privacy-audit-master-prompt.md) | 隐私：合法依据、同意/cookies、数据主体权利、保留、传输、违规响应准备 | GDPR, ePrivacy/TTDSG, EU AI Act, CCPA, HIPAA/PCI | RoPA/数据流图 + 条款映射的路线图 | | [`accessibility`](audit-prompts/accessibility-audit-master-prompt.md) | 深度 a11y：语义、键盘、焦点、屏幕阅读器、对比度、表单、缩放、运动、动态、认知 | WCAG 2.2 AA/AAA, EAA 2025, EN 301 549, ADA/508 | WCAG 合规表 + 路线图 | | [`documentation`](audit-prompts/documentation-audit-master-prompt.md) | 对照标准检查文档质量：元数据、新手引导、文档与代码的偏差、写作、Diátaxis、代码库健康度 | DOCUMENTATION-STANDARD.md, Diátaxis, Google 风格 | 评分量表 + 德语 issues | | [`content`](audit-prompts/content-audit-master-prompt.md) | 内容与信息传达：论点挑战、受众契合度、证据与原创性、结构、语调、行级重写 | E-E-A-T, BLUF, 认知阶段, 修辞 | 评分卡 + 修改前后重写对比 | | [`lean`](audit-prompts/lean-audit-master-prompt.md) | 仓库精简度：死代码、未使用/幽灵依赖、重复、AI 垃圾内容、依赖透明度、安全精简 —— 防止过度删除 | SWE@Google (废弃/依赖), OWASP Component Analysis, SLSA, YAGNI, Chesterton's Fence | 移除登记表 (4 级) + 评分卡 | ## 从你的 AI agent 运行 将任何有能力的 agent 指向实时入口点 —— 无需安装： agent 将获取编排器 ([`full-audit-master-prompt.md`](audit-prompts/full-audit-master-prompt.md)，位于 [`auditor.rapold.io/llms.txt`](https://auditor.rapold.io/llms.txt))，询问你的输出语言 (Deutsch / English) 以及要运行哪些审计（或整个代码库），然后提交一个合并的、 按优先级排序的 issue backlog。 ## 实战示例：审计此代码库 该库在自身上进行了内部测试。针对 `auditor` 端到端运行编排器产生了 一个跨审计的合并 backlog —— 这是输入到 issues 循环的具体追踪记录： - **输入。** 将 agent 指向该仓库。Phase 0 侦察选择了七个适用的审计，并 声明了四个**不适用，并附有原因**（无运行时 API、无数据库、无仓库内 LLM 运行时、无个人数据），而不是默默地跳过它们。 - **评分卡。** documentation A (94), accessibility A (93), performance A (92), security A (91), repo / frontend / infrastructure A- (90) —— 零个 P0，一个 P1。 - **跨审计去重。** “`CHECKSUMS.txt` 未在 CI 中验证”被 repo、infrastructure 和 security 视角独立发现，并合并为一个包含所有三个 引用的单个 backlog 项目 —— 这是协同运行审计的成果。 - **输出。** 一个主追踪 issue，加上每个发现对应一个 issue，每个都包含管理摘要、 证据 (`file:line`)、修复前后的对比、工作量预估和重新审计标准。 在 GitHub 上查看运行结果：[master tracker #97](https://github.com/marcelrapold/auditor/issues/97) （评分卡、合并的 backlog 以及 30/60/90 路线图）及其链接的各个发现 issue。 ## 快速入门 **前提条件：** 一个强大的 AI 编程 agent；如果你目标是 GitHub URL 或希望审计提交 issues，则需要安装并验证 [GitHub CLI](https://cli.github.com) (`gh`)； 并且对目标仓库具有写入权限以进行 issue 阶段。 1. **在目标的工作目录中打开你的 AI 编程 agent**，或者提供一个 GitHub URL。 2. **完整粘贴所选的主提示词**（在 GitHub 上打开文件并选择“Copy raw file”）， 然后在其顶部的配置块中填空 —— 每个提示词都以下面的内容开始： TARGET: <本地仓库路径或 GitHub URL> SCOPE: <整个仓库 | 特定流程/路径> STACK: <语言、框架、云 —— 或让 Phase 0 推断> AUDIENCE: <目标受众，如果已知> DATA_ACCESS: <可以运行 / 主动测试？还是只读> OUTPUT_LANG:
Recon &
surface map"] --> P1 subgraph P1["Phase 1 — parallel specialist swarm"] direction TB A1["Specialist A"] A2["Specialist B"] A3["Specialist C"] A4["Specialist …N"] end P1 --> P2["Phase 2
merge ·
dedupe ·
compound"] P2 --> P3{"Phase 3
adversarial
verify · ≥2/3?"} P3 -- "refuted" --> KILL["Killed
(appendix +
refutation)"] P3 -- "survives" --> P4["Phase 4
benchmark vs
best-in-class"] P4 --> P5["Phase 5
report · scorecard ·
issues · roadmap"] P5 -. "blind-spot critic:
what did we miss?" .-> P1 ``` 严重性是标准化的（从 P0 致命到 P3 优化），每个发现都带有工作量预估和 ICE/优先级评分，路线图 始终是 Quick Wins → 30 → 60 → 90 天，感知依赖关系，并贯穿追踪发现 ID。每份 报告都以诚实的“覆盖范围与局限性”部分结束；将未审计的区域报告为 “良好”将被视为审计失败。 ## Issue 输出 验证后，每次审计都会根据 [`ISSUE-OUTPUT-STANDARD.md`](ISSUE-OUTPUT-STANDARD.md) 生成 GitHub issues： 1. **首先是追踪 issue** —— 所有子任务的索引，按优先级 (P0→P3) 排序，包含 管理摘要、评分卡和 30/60/90 路线图。每个清单行都链接到其子 issue。 2. **每个确认的发现对应一个 issue** —— 德语，顶尖的文档质量，每一个都以自己的 管理摘要开头，然后是严重性、证据、具体的修复前后对比、工作量和 重新审计标准。 Issues 默认为德语（每次运行可配置），先预览，仅在明确 授权后创建。 ## 标准 两项规范性标准约束着审计，并且可以独立重用： - [`DOCUMENTATION-STANDARD.md`](DOCUMENTATION-STANDARD.md) (德语) 和 [`DOCUMENTATION-STANDARD.en.md`](DOCUMENTATION-STANDARD.en.md) (英语) —— 一个 Google 级别的 文档，包含五种仓库配置文件和 0–100 的评分量表。`documentation` 审计将其作为衡量标准。 - [`ISSUE-OUTPUT-STANDARD.md`](ISSUE-OUTPUT-STANDARD.md) —— 强制性的追踪 issue + 每次审计都遵循的每个发现对应 issue 的契约。 随时可用的 README 骨架位于 [`templates/README.template.md`](templates/README.template.md)。 ## 只读与授权 这些审计默认是非破坏性和只读的： - 对代码、配置、schema 和 IaC 的静态分析不需要特殊权限。 - 主动或动态测试（DAST、负载测试、注入/越狱探测、实时云或 DB 访问）需要所有者的明确、书面授权。如果没有授权，提示词将 回退到静态推理并标记出该限制。 - 不使用破坏性技术，不进行 DoS，不进行数据窃取。真实的机密和 PII 永远不会被复制 到报告中 —— 引用位置并隐去值。 - 创建 issues 是先预览，并受限于明确批准。 仅在你拥有或被授权评估的系统上使用这些审计。 ## 仓库布局 ``` auditor/ ├── README.md you are here ├── ARCHITECTURE.md monorepo structure + design decisions ├── DOCUMENTATION-STANDARD.md the doc standard (German, canonical) ├── DOCUMENTATION-STANDARD.en.md the doc standard (English mirror) ├── ISSUE-OUTPUT-STANDARD.md mandatory issue output for all audits ├── CONTRIBUTING.md how to contribute templates and docs ├── CODE_OF_CONDUCT.md Contributor Covenant ├── SECURITY.md how to report a vulnerability ├── CHANGELOG.md Keep a Changelog format ├── templates/ │ └── README.template.md canonical README skeleton ├── .github/ │ ├── workflows/docs.yml docs CI (markdown lint, link-check, emoji guard) │ ├── PULL_REQUEST_TEMPLATE.md │ └── ISSUE_TEMPLATE/ findings + new-template + chooser config ├── web/ landing page (Next.js 16) → auditor.rapold.io └── audit-prompts/ ├── full-audit-master-prompt.md (orchestrator) ├── security-audit-master-prompt.md ├── repo-audit-master-prompt.md ├── frontend-audit-master-prompt.md ├── api-audit-master-prompt.md ├── performance-audit-master-prompt.md ├── data-audit-master-prompt.md ├── infrastructure-audit-master-prompt.md ├── ai-llm-audit-master-prompt.md ├── compliance-privacy-audit-master-prompt.md ├── accessibility-audit-master-prompt.md └── documentation-audit-master-prompt.md ``` 着陆页位于 `web/` —— 其技术栈、本地开发和部署记录在 [`web/README.md`](web/README.md) 中。 ## 贡献 新模板遵循内部结构，以便它们与其余部分组合：使命 + 通用性、 操作原则、P0–P3 严重性等级、Phase 0–5 流水线、共享的发现 schema、 强制性的 issue 输出块以及 Definition of Done。保持它们与提供商无关，将发现 映射到公认的标准，并使每一条建议都能立即付诸实践。参见 [`CONTRIBUTING.md`](CONTRIBUTING.md)，并遵循 [`DOCUMENTATION-STANDARD.md`](DOCUMENTATION-STANDARD.md) 处理所有 Markdown —— 包括标题中不使用表情符号。 ## 更新日志与许可证 更改记录在 [`CHANGELOG.md`](CHANGELOG.md) 中（Keep a Changelog；SemVer）。根据 MIT 许可 —— 参见 [`LICENSE`](LICENSE)。
标签：AI编程助手, 代码审查, 提示词工程, 策略决策点, 自动化攻击, 质量保证, 防御加固