为了让您轻松上手 GitLab，这里列出了一些推荐的后续步骤。
已经是专家了？只需编辑此 README.md 并使其成为您自己的。想更简单？使用底部的模板！
cd existing_repo
git remote add origin https://gitlab.com/guardia-ai/gitlab-component.git
git branch -M main
git push -uf origin main
使用 GitLab 内置的持续集成功能。
当您准备好让这个 README 成为您自己的时，只需编辑此文件并使用下面的方便模板（或者自由地以您想要的任何方式组织它——这只是一个起点！）。感谢 makeareadme.com 提供此模板。
每个项目都是不同的，所以请考虑哪些部分适用于您的项目。模板中使用的部分是对大多数开源项目的建议。同时请记住，虽然 README 可能过长过细，但过长总比过短好。如果您认为您的 README 过长，请考虑使用其他形式的文档，而不是删减信息。
为您的项目选择一个自解释的名称。
让人们知道您的项目具体能做什么。提供背景信息，并添加一个指向访客可能不熟悉的任何参考资料的链接。也可以在此处添加功能列表或背景子部分。如果您的项目有替代方案，这里是列出差异化因素的好地方。
在某些 README 上，您可能会看到传达元数据的小图像，例如项目是否通过了所有测试。您可以使用 Shields 向您的 README 添加一些徽章。许多服务也提供了添加徽章的说明。
根据您制作的内容，包含屏幕截图甚至视频可能是个好主意（您经常会看到 GIF 而不是实际视频）。像 ttygif 这样的工具可以提供帮助，但也可以查看 Asciinema 以获得更高级的方法。
在特定的生态系统中，可能存在通用的安装方式，例如使用 Yarn、NuGet 或 Homebrew。但是，请考虑阅读您 README 的人可能是新手，需要更多的指导。列出具体步骤有助于消除歧义，让人们尽快使用您的项目。如果它只在特定上下文中运行，例如特定的编程语言版本或操作系统，或者有需要手动安装的依赖项，请同时添加一个“要求”子部分。
广泛地使用示例，并尽可能展示预期的输出。在 README 中直接包含您可以展示的最小示例是很有帮助的，同时提供指向更复杂示例的链接，如果它们太长而无法合理包含在 README 中。
告诉人们他们可以去哪里寻求帮助。可以是问题跟踪器、聊天室、电子邮件地址等的任意组合。
如果您对未来版本有想法，最好在 README 中列出它们。
说明您是否接受贡献以及接受贡献的条件。
对于想要对项目做出更改的人，提供一些如何开始的文档会很有帮助。也许他们应该运行一个脚本或设置一些环境变量。使这些步骤明确。这些指令也可能对未来的您有用。
您还可以记录用于代码检查或运行测试的命令。这些步骤有助于确保高代码质量并降低更改意外破坏某些内容的可能性。如果有运行测试的说明会特别有帮助，尤其是当它需要外部设置时，例如启动一个 Selenium 服务器以在浏览器中进行测试。
向为项目做出贡献的人表示感谢。
对于开源项目，说明其许可证。
如果您对项目失去了精力或时间，请在 README 顶部添加一条注释，说明开发已放缓或完全停止。有人可能会选择 fork 您的项目或自愿成为维护者或所有者，让您的项目继续发展。您也可以明确请求维护者。
除了检测您使用了哪些 AI 库之外，扫描器还会读取您的源代码并报告特定行上的具体义务：
| 规则 | 检查内容 |
|---|---|
GA-ART50-001 | 一个到达模型并面向用户的端点，且在仓库中没有任何地方披露响应是由 AI 生成的 |
GA-ART12-001 | 调用模型时没有日志记录、审计或追踪调用在范围内 |
发现结果以三种方式呈现：作为合并请求的评论、通过代码质量报告作为合并请求差异上的标记，以及（使用 API 密钥时）作为 Guardia 仪表板中的记录，跟踪您每次提交修复了什么和引入了什么。
include:
- component: gitlab.com/guardia-ai/gitlab-component/scan@main
inputs:
guardia_api_key: $GUARDIA_API_KEY # 可选 — 保留记录
code_analysis: 'true'
fail_on_findings: 'none'
发现结果会自行解决。修复代码——无论是我们的补丁还是您自己的——下一次扫描就会停止报告它。无需点击任何东西。
如果想接受一个发现结果，请在代码中这样说明：
# guardia: ignore GA-ART50-001 — notice is rendered by the chat UI shell
这永远不会导致构建失败，并且它会作为记录在案的风险接受出现在您的仪表板中，作者信息来自 git blame，这正是审计员希望看到的。
一个已有五年历史的仓库会有一些当前团队成员不负责的发现结果。一次性冻结它们，只有新的工作需要保持干净：
guardia-scan . --write-baseline .guardia/baseline.json
提交该文件。基线化的发现结果在报告和仪表板中仍然可见——它们只是永远不会导致检查失败。之后引入的任何内容才会。
每次运行都可以写入一个防篡改的记录——发现了什么、在哪个提交上、在哪个规则包版本下发现的，以及每个规则在当时经过了多少法律审查：
- uses: GharbiiAhmed/guardia-ai-action@v1
with:
evidence-file: guardia-evidence.json
evidence-signing-key: ${{ secrets.GUARDIA_EVIDENCE_KEY }} # 可选
记录通过哈希链连接，因此更改过去的记录会破坏之后的所有记录。没有签名密钥时证明内部一致性，而非真实性——记录本身会说明这一点，而不是让您去猜测。
发现结果陈述您的代码做了什么并引用相关义务。它们不会断言您违反了规定——某项义务是否适用取决于您系统的目的和部署环境，这是任何代码扫描都无法确定的。规则逐字引用(EU) 2024/1689 规定，以便您可以自己核对推理过程。
检测完全离线运行。您的源代码永远不会离开运行器。