1. 数据泄露不是“会不会发生”，而是“在哪一刻被触发”OpenClaw 在企业级落地中最容易被低估的，不是它写代码有多快，而是它读代码时有多“不设防”。我见过三个项目在上线前安全扫描中被标记高危漏洞，原因全出在同一个地方：AI 编程助手把数据库连接字符串、API 密钥、内部服务地址这些本该藏在.env或 KMS 中的敏感信息，直接写进了config.py、settings.yaml，甚至更隐蔽地——塞进了CLAUDE.md的上下文注释里。这不是模型“故意”泄露，而是它根本分不清“这段文字是配置说明”和“这段文字是真实凭证”的边界。关键在于 OpenClaw 的上下文机制：它不区分“你告诉它的知识”和“它正在处理的代码”。当你在CLAUDE.md里写：# 数据库配置（仅供开发环境参考） DB_URL=postgresql://admin:dev123@10.20.30.40:5432/prod_db它不会加个括号标注“这是示例，别当真”。它会把dev123和10.20.30.40当作有效上下文，在后续生成数据库操作函数、SQL 查询构造器、甚至日志打印逻辑时，无意识地复用、拼接、暴露。我们团队在一次灰度发布后，通过日志审计发现，一个本该只打印user_id的调试接口，实际返回了完整DB_URL的 base64 编码片段——因为 AI 在生成日志格式