自动下单执行虾

自动下单执行虾 — 规则驱动的采购自动化执行引擎。达到触发条件后自动执行支付采购，完成从发现到付钱的闭环。 当以下情况时使用此 Skill： (1) 需要根据库存水位自动触发补货采购 (2) 需要监控价格并在跌破目标价时自动下单 (3) 需要配置定期自动续订（办公用品、SaaS 订阅等） (4) 需要生产线缺料时...

Security Scan

功能与“自动采购并执行支付”描述大体一致，但清单与实现存在若干不一致与敏感凭据处理问题——在部署到生产环境前需要进一步审查与修正。

Purpose & Capability

技能名/描述与脚本行为总体一致（监控规则 → 生成订单 → 下单/支付 → 通知归档）。需要访问数据库、供应商 API、通知 webhook，这与自动采购目的合理匹配。但 registry 元数据声明“无需环境变量/凭据”，与脚本和参考文档中明确需要大量凭据（DB、支付/供应商 API keys、飞书 webhook 等）不一致。

Instruction Scope

SKILL.md 与脚本指示会访问数据库、读取 config/suppliers.json、调用外部 HTTP API（供应商、飞书）并执行支付流程——这些都属于预期范围，但脚本调用了未包含在清单中的文件 (evaluate_condition.py)；参考模板 (config/suppliers.json) 也未随包提供。脚本将数据库凭据通过命令行参数传给 mysql 和 Python 子进程（提高凭据被进程列表或审计日志泄露的风险），并将执行/错误日志写入磁盘，且缺少在实现中显式掩码敏感字段的逻辑（尽管 references/payment-security.md 提到了掩码原则）。

Install Mechanism

无安装脚本；技能为说明 + 可执行脚本，未下载或执行外部二进制，安装面较小。

Credentials

脚本和参考文档需要多个敏感环境变量和凭据（DB_HOST/DB_USER/DB_PASSWORD/DB_NAME、PAYMENT_GATEWAY_URL/PAYMENT_API_KEY、SUPPLIER_* 环境变量、FEISHU_WEBHOOK_URL 等），但 registry 元数据未声明任何必需 env vars 或主凭据，造成权限与信任决策缺失。此外，凭据通过命令行/环境直接使用且有在日志/进程列表泄露的实现细节，权限请求与保护措施不成比例。

Persistence & Privilege

没有设置 always:true，默认允许自主调用（平台默认）。脚本会写日志和 PID 文件到磁盘并期望长期运行，但未修改其它技能或系统范围配置。

What to consider before installing

这个 Skill 的功能描述与代码大体一致，但在部署前请做以下检查： - 不要在生产环境直接启用自动支付流程，先在隔离测试环境完全验证。 - 要求发布者/维护者把清单（registry metadata）与实现对齐：声明所有必需的环境变量（DB_*, PAYMENT_*, SUPPLIER_*，FEISHU_WEBHOOK_URL 等）。 - 缺失文件：脚本引用 evaluate_condition.py 和期望的 config/suppliers.json，但它们未包含在包内；确认这些文件来自何处并审计其内容。不要猜测。 - 凭据处理：当前脚本通过命令行参数和环境变量将 DB 密码传给 mysql 和 Python 子进程，会在进程列表中泄露；改用更安全的凭据注入方式（如从受管密钥库动态读取、使用 unix socket 或 .my.cnf、避免在命令行中明文传递密码）。 - 日志与掩码：虽然文档提到掩码敏感字段，实际脚本没有确保日志不会泄露账号/金额/凭据，需实现并验证日志掩码和受限日志访问。 - 审批与阈值：确认预算与人工复核阈值配置正确，不要启用可能导致大额自动支付的规则（例如默认允许 ≤5000自动执行是可以，但大型支付应默认人工审批）。 - 网络目标白名单：核对所有外部 HTTP 目标（供应商 api_base_url、支付网关、飞书 webhook），并在网络层做白名单限制以降低泄露风险。 如果你 lack access to the missing files or the maintainer cannot provide explanations and fixes, consider classifying this skill as unsafe to install in production. If you still want to test it, run it in a sandboxed environment with fake credentials and network isolation first.

规则驱动的采购自动化执行引擎，让采购决策从"人工审批"变成"规则驱动"。

核心工作流

[监控数据源] → [条件判断] → [规则匹配] → [预算校验] → [生成订单] → [执行支付] → [通知归档]
                   ↓                              ↓
             [未触发：继续监控]              [记录日志]

执行步骤

Step 1 — 理解采购规则

• 收集用户的触发条件（库存阈值 / 价格目标 / 时间周期）
• 确认商品编码、供应商 ID、采购数量、预算上限
• 如有配置表（Excel/CSV），解析字段：商品编码、触发条件、采购数量、供应商ID、预算上限

Step 2 — 条件判断引擎

• 数值比较：库存 < 安全库存阈值 / 价格 < 目标价
• 时间条件：定时触发 / 周期触发
• 逻辑组合：AND / OR / NOT，支持多维度联合判断
• 多规则冲突时按优先级排序（紧急 > 常规，主供应商 > 备选）
• 详细规则配置语法见 references/purchase-rules.md

Step 3 — 预算校验

• 单笔金额不超过预设上限
• 检查月度预算余额
• 超限时暂停自动采购并通知财务

Step 4 — 生成采购订单 生成包含完整信息的订单：商品明细、供应商信息、价格条款、交货要求。 供应商 API 对接规范见 references/supplier-api.md。

Step 5 — 执行支付 支持：企业网银、支付宝/微信企业付款、账期支付、加密货币（跨境）。 安全规范与权限矩阵见 references/payment-security.md。

Step 6 — 通知与归档

• 通过飞书/邮件/短信通知采购负责人、财务、仓库
• 订单详情、支付凭证、触发日志存档
• 异常处理：支付失败自动重试，供应商无响应切换备选

核心脚本

scripts/monitor-and-execute.sh — 监控与执行主脚本

# 启动后台监控
./scripts/monitor-and-execute.sh monitor --daemon

# 手动执行单笔采购（测试/紧急）
./scripts/monitor-and-execute.sh execute --rule-id <RULE_ID>

# 查看监控状态
./scripts/monitor-and-execute.sh status

依赖：bash + curl + jq + python3 + mysql-client 首次运行需配置数据库连接和 API 密钥。

安全原则

• 每笔订单设置预算上限和人工复核阈值
• 完整记录触发原因、决策依据、执行结果（可审计）
• 支付失败自动重试，供应商无响应切换备选
• 增加订单去重机制，防止短时间内重复下单

与其他虾的协作

上下游	虾名	数据流向
上游	库存预警虾 (inventory-alert)	提供库存数据 → 触发补货
上游	价格监控虾 (price-monitor)	提供价格数据 → 触发低价采购
上游	供应商评估虾 (supplier-evaluator)	提供供应商优先级
下游	财务对账虾 (finance-reconciliation)	接收支付记录自动对账

局限说明

• 依赖供应商 API 稳定性
• 不支持需要复杂谈判的采购
• 支付金额受企业网银单笔限额约束
• 无法处理需要人工判断的特殊情况（质量纠纷、价格异常波动）