每周报告最容易失控的地方，不是写作，而是数据边界：谁能看到哪些文件，报告引用了哪一版数据，草稿是否有人复核，以及 Slack 中发出去的内容能不能追溯。
一种更稳妥的做法，是把存储、知识库、报告生成和发布拆成明确的治理环节：用 Amazon FSx for NetApp ONTAP 保存受控文件，用 Amazon S3 access point 只暴露批准的文件夹给 Amazon Quick Desktop 的知识库，再用 custom skill 起草带引用的周报和 Slack 摘要。任何外发动作都停在人手中。
先划清数据边界，再谈检索
FSx for NetApp ONTAP 适合承载需要文件系统语义、权限控制和企业级数据管理能力的工作负载。周报流程可以把原始数据、已批准数据和历史报告分开存放，例如：
/reports
/approved-inputs/
/drafts/
/published/
/archive/
关键点不在目录名称，而在于知识库只接触 approved-inputs/。不要把整个共享盘或包含草稿、临时导出和个人备注的目录直接交给检索系统。这样做可以减少无关内容进入上下文，也让审计人员更容易回答“这份报告允许使用哪些材料”。
S3 access point 可以作为访问边界：为报告知识库创建专用 access point，限定到批准的 S3 前缀，并通过策略拒绝其他路径。下面是一个需要按实际账户、区域和资源名称改造的策略骨架；它表达的是治理思路，不是可以直接套用的完整生产策略。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowQuickKnowledgeBaseApprovedFolder",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/QuickKnowledgeBaseRole"
},
"Action": ["s3:GetObject"],
"Resource": "arn:aws:s3:us-east-1:123456789012:approved-reports/approved-inputs/*",
"Condition": {
"StringEquals": {
"s3:DataAccessPointArn": "arn:aws:s3:us-east-1:123456789012:accesspoint/weekly-report-kb"
}
}
}
]
}
部署前应核对 access point policy、bucket policy、IAM role、KMS 权限和网络路径。尤其要确认知识库角色没有意外的 s3:ListAllMyBuckets 或其他前缀的读取权限。
让报告草稿必须“有据可查”
custom skill 的职责应当是起草，不是替业务负责人做最终判断。一个可操作的提示词需要把输入范围、时间窗口、引用格式和不确定性处理写清楚：
你是每周运营报告助手。
任务：根据知识库中“approved-inputs/”目录内、报告周期为 {{week_ending}} 的文件，生成周报草稿。
要求：
1. 只使用知识库检索到的内容；找不到证据时写“未找到证据”，不得补猜。
2. 每个关键数字后标注来源文件名、路径和页码或表格行（如果可用）。
3. 区分事实、推断和待确认事项。
4. 对环比变化给出计算式，并保留原始数值。
5. 输出固定章节：摘要、指标变化、异常、风险、待确认问题。
6. 结尾添加“人工复核清单”，列出需要负责人确认的数字和结论。
输出格式：Markdown。不要发送消息，不要调用外部发布动作。
如果系统支持结构化输出，可以把报告草稿拆成 facts、citations、inferences 和 review_items 字段。这样比只生成一段自然语言更容易做校验，也便于后续把引用渲染到 Slack 或文档中。
一个最小的工作流可以长这样：
# 1. 仅上传已批准的输入文件
aws s3 cp ./approved-inputs/ \
s3://approved-reports/approved-inputs/2025-W10/ \
--recursive \
--sse aws:kms \
--sse-kms-key-id alias/weekly-report
# 2. 触发知识库同步或按平台配置的摄取任务
aws bedrock-agent start-ingestion-job \
--knowledge-base-id KB123456 \
--data-source-id DS123456
命令中的服务接口和参数需要根据实际使用的 Amazon Quick Desktop 集成方式调整。示例的重点是顺序：先完成批准和加密上传，再让知识库摄取，最后生成报告。不要让生成任务读取尚未经过批准的本地导出目录。
Slack 只是发布出口，不是复核环节
生成 Slack 摘要时，custom skill 可以限制长度并保留关键引用，但不应直接发送。建议把结果先写入 drafts 区域或待审批队列，由负责人确认以下内容：
- 数字是否来自本周批准的数据，而不是旧报告中的复制值。
- 引用是否能打开，并且没有暴露超出收件人权限的路径。
- “增长”“下降”“异常”等判断是否有明确计算依据。
- 摘要是否包含客户、员工或内部项目的敏感信息。
- 报告周期、时区和截止时间是否一致。
通过复核后，再由一个权限更窄的发布步骤写入 Slack。发布身份不应同时拥有原始文件的广泛读取权限。这样可以把“能生成内容”和“能把内容发送给一群人”分成两个独立的权限问题。
一套适合落地的检查清单
上线前，可以用下面的最小检查集验证流程：
- 用测试身份确认知识库只能读取
approved-inputs/。 - 上传一份带唯一标记的批准文件，确认报告能够引用它。
- 放入一份同名的旧文件或草稿文件，确认它不会被检索。
- 故意制造缺失数据，确认输出会标记“未找到证据”，而不是补全数字。
- 检查每条引用是否包含文件标识和足够的定位信息。
- 验证生成身份无法发送 Slack，发布身份无法读取不必要的原始目录。
- 保留输入版本、提示词版本、生成时间、复核人和最终发布内容。
这套架构的代价是流程多了一步人工等待，且文件权限、S3 策略、知识库摄取和引用质量需要持续维护。但对于财务、运营和合规相关周报，这个代价通常换来了更清晰的责任边界：系统负责整理证据和起草，人负责判断和发布。先从一个指标范围、一个批准目录和一个 Slack 频道开始，确认引用与复核记录稳定后，再逐步扩展报告覆盖面。