安全与信任

AnswerLens 的安全叙事起点，是没有托管控制平面。

AnswerLens 的设计目标，是让团队能在 GitHub-native 工作流中审计公开产品站点并审阅结果，而不必把仓库历史或 provider key 发给单独的 AnswerLens SaaS。它也把边界写得很明确：不抓取消费级 AI UI、不承诺排名、不做 dashboard-first 重写。

哪些内容仍由你掌控

信任模型

Provider API key 会保留在你自己的 shell、CI 环境或 GitHub Actions secrets 中。
核心 `audit` 工作流可以完全不依赖 provider key。
AnswerLens 会把 `share-summary.md`、`scorecard.md`、`recommendations.md` 这类可审阅 artifacts 写进你自己的 run 目录。
对外分享时优先使用 summary artifacts，而 raw provider payload 应保持私有。

操作细节

审阅与部署模型

关注点	AnswerLens 方式
密钥	provider key 保留在你自己的 shell、CI 环境或 Actions secrets 中。
托管控制平面	无论 CLI、GitHub Action 还是静态报告流，都不需要托管式 AnswerLens SaaS。
审阅轨迹	把 pull request、Action 日志、上传的 artifacts 与 repo history 当作审计轨迹。
公开分享	公开分享时优先使用 `share-summary.md` 或 `pr-snippet.md`，原始 payload 保持私有。

边界与约束

已知限制

由于当前并不存在托管版 AnswerLens SaaS，项目不会宣称自己具备 SOC 2、ISO 27001、HIPAA 等托管服务合规能力。
项目不会通过抓取消费级 AI 界面来制造可见性声明。
产品不会承诺答案面的排名或展示位置。
团队在把 artifacts 发到公开 issue、PR 或 release notes 前，仍然应该先自行审阅。

这能让信任叙事保持直接：使用你自己的部署路径、密钥处理方式和仓库审阅流程。

由 YSCJRH 基于仓库内文档、发布记录与产物构建。无消费级 AI 界面抓取，不承诺答案面排名。