RFI(信息请求)问卷经常以 Excel 工作簿流转:不同主题分散在多个工作表里,表头位置不统一,还夹杂说明文字、合并单元格和空行。真正费时间的往往不是读取文件,而是判断哪些行属于问题、如何统一字段,以及怎样输出可供后续系统消费的结构化数据。
Amazon Quick Automate 提供了一条更短的实现路径:从 Amazon S3 读取多工作表 RFI 文件,通过自然语言提示词提取并规范化问题,在对话中修正边界条件,再把干净的 CSV 写回 S3。这个过程把大量一次性解析代码转化为可检查、可迭代的工作流。
工作流应该明确哪些边界
一个端到端流程可以拆成四个稳定阶段:
- 从指定的 S3 输入前缀读取 Excel 工作簿。
- 遍历所有可见工作表,识别问题、编号、分类和回答要求。
- 将不同版式映射到统一的数据契约,并过滤标题、说明和空行。
- 生成 UTF-8 CSV,写入独立的 S3 输出前缀。
输入和输出最好分开存放,例如:
s3://acme-rfi-automation/incoming/vendor-security-rfi.xlsx
s3://acme-rfi-automation/output/vendor-security-rfi.csv
不要只告诉自动化工具“把 Excel 转成 CSV”。这样的要求缺少语义边界,容易把章节标题识别成问题,也无法稳定处理跨工作表重复编号。更可靠的做法是先定义输出字段:
| 字段 | 含义 |
|---|---|
source_sheet |
原始工作表名称 |
question_id |
原始问题编号;缺失时留空 |
section |
问题所属章节或主题 |
question |
清理后的完整问题文本 |
response_type |
text、yes_no、single_choice 或 multi_choice |
required |
是否必须回答 |
notes |
约束条件或补充说明 |
source_sheet 不应省略。它既能帮助采购或安全团队追溯原始位置,也能在自动提取出现偏差时缩小排查范围。
用提示词约束提取,而不是描述愿望
可以在 Quick Automate 的工作流中使用下面这类提示词。具体节点名称和文件绑定方式应以实际环境为准,但数据契约和判断规则可以直接改造:
读取输入的 Excel 工作簿,并检查所有非隐藏工作表。
目标:提取需要供应商回答的 RFI 问题,输出为结构化记录。
每条记录必须包含:
- source_sheet:原始工作表名称
- question_id:原始编号,没有编号时为空字符串
- section:最近且适用的章节标题
- question:去除多余换行和首尾空格后的完整问题
- response_type:只能是 text、yes_no、single_choice、multi_choice
- required:只能是 true 或 false;无法确定时使用 false
- notes:回答限制、选项或补充说明,没有时为空字符串
规则:
1. 忽略封面、填写说明、版权文本、纯标题、空行和示例答案。
2. 不要补写源文件中不存在的问题、编号或要求。
3. 合并因单元格换行而拆开的同一个问题,但不要合并两个独立问题。
4. 不同工作表出现相同编号时仍保留两条记录,并通过 source_sheet 区分。
5. 保持问题原有顺序:先按工作表顺序,再按工作表内行顺序。
6. 输出 UTF-8 CSV,列顺序严格按照上述字段顺序。
第一次运行后,不必立即修改整个工作流。先检查一两个有代表性的工作表,再通过对话补充规则。例如:
复查 Security Controls 工作表:以“Control family:”开头的行是章节标题,
不应成为问题。将其值写入后续问题的 section,直到出现下一个章节标题。
其他提取规则和输出字段保持不变。
这种增量修正比不断扩张一个巨大提示词更容易验证。每次只调整一种误判,并保留对应的输入样本作为回归用例。
可以这样实践:准备 S3 输入并检查结果
下面假设已经配置 AWS CLI,并且当前身份对目标桶拥有必要的读写权限。先设置变量,再上传测试工作簿:
export AWS_REGION="us-east-1"
export RFI_BUCKET="acme-rfi-automation"
export INPUT_FILE="vendor-security-rfi.xlsx"
export OUTPUT_FILE="vendor-security-rfi.csv"
aws s3 cp "$INPUT_FILE" \
"s3://$RFI_BUCKET/incoming/$INPUT_FILE" \
--region "$AWS_REGION"
aws s3api head-object \
--bucket "$RFI_BUCKET" \
--key "incoming/$INPUT_FILE"
工作流运行完成后,下载并检查输出:
aws s3 cp \
"s3://$RFI_BUCKET/output/$OUTPUT_FILE" \
"./$OUTPUT_FILE" \
--region "$AWS_REGION"
python - "$OUTPUT_FILE" <<'PY'
import csv
import sys
from collections import Counter
from pathlib import Path
path = Path(sys.argv[1])
required_columns = [
"source_sheet",
"question_id",
"section",
"question",
"response_type",
"required",
"notes",
]
allowed_types = {"text", "yes_no", "single_choice", "multi_choice"}
with path.open("r", encoding="utf-8-sig", newline="") as handle:
reader = csv.DictReader(handle)
if reader.fieldnames != required_columns:
raise SystemExit(
f"Unexpected columns: {reader.fieldnames}; expected: {required_columns}"
)
rows = list(reader)
errors = []
for line_number, row in enumerate(rows, start=2):
if not row["source_sheet"].strip():
errors.append(f"line {line_number}: source_sheet is empty")
if not row["question"].strip():
errors.append(f"line {line_number}: question is empty")
if row["response_type"] not in allowed_types:
errors.append(f"line {line_number}: invalid response_type")
if row["required"].lower() not in {"true", "false"}:
errors.append(f"line {line_number}: required must be true or false")
if errors:
raise SystemExit("\n".join(errors))
counts = Counter(row["source_sheet"] for row in rows)
print(f"validated {len(rows)} questions")
for sheet, count in sorted(counts.items()):
print(f"{sheet}: {count}")
PY
运行前需要把桶名、区域和文件名换成自己的值。验证脚本不仅检查 CSV 能否打开,还会检查列顺序、必填内容和枚举值,能及时发现“文件生成成功,但数据契约已经漂移”的问题。
上线前要处理的工程问题
自然语言工作流减少了开发工作量,但不意味着可以省略工程控制。至少要考虑以下事项:
- 权限最小化:执行身份只应读取输入前缀、写入输出前缀,并使用所需的加密密钥。
- 敏感数据:RFI 可能包含架构、安全控制和供应商信息,应确认 S3 加密、日志留存与组织的数据处理要求。
- 幂等性:明确同名输出是覆盖、版本化还是按运行时间生成新对象,避免重跑产生含糊结果。
- 回归样本:保存几份经过脱敏的典型工作簿,覆盖合并单元格、重复编号、多行问题和不同表头。
- 人工复核:对高风险问卷保留抽样或全量审核,尤其关注否定句、条件问题和选项范围。
- 可观测性:记录输入对象版本、输出对象位置、处理时间、记录数和失败原因。
判断流程是否成熟,不应只看它能否产生 CSV。更有意义的验收标准是:相同输入能得到稳定结构;新增版式可以通过有限规则调整;错误能够定位到工作表和记录;输出能够被采购平台、工单系统或分析任务直接消费。
采用建议
从一份真实但已脱敏的 RFI 开始,先固定七个左右的核心字段,再选择版式差异最大的两个工作表进行迭代。提示词规则稳定后,再扩展到整本工作簿和更多供应商模板。
Amazon Quick Automate 适合把这类以文档理解为主、规则会持续演化的流程从脚本堆栈变成可对话调整的自动化。但确定性的校验仍应放在流程末端:让自然语言负责理解,让代码负责验证契约,这样才能在缩短交付周期的同时控制数据质量。