系列第十篇一个月踩坑完整复盘按血压值从低到高排开篇一个风控人的真实经历十年风控该见的都见过了。系统崩溃——见过。数据异常——见过。凌晨三点被叫醒——家常便饭。但养虾一个月我发现风控再熟也挡不住 AI Agent 挖坑。这篇文章按血压从低到高排一遍一个月踩过的坑。不是吐槽是让你少流点血。血压指数 ★☆☆☆☆装环境时的小磕绊坑1Node.js 版本不对Copy$ npm install openclaw Error: Requires Node.js 22.0.0 Current: v16.14.2系统里装了三个 Node 版本终端用的是最老那个。Copynvm install 18 nvm use 18 nvm alias default 18教训就一条环境问题 90% 是版本问题。先node -v再查其他。坑2API Key 写错位置配置文件写完了运行报错API_KEY not found。我明明写了。在 config.json 里。OpenClaw 读的是.env不是config.json。教训文档说在哪写就在哪写。不确定就find . -name .env*搜一下。坑3Docker 网络问题本地能跑Docker 里跑不起来。Docker 容器默认网络隔离访问不了宿主机的 localhost。Copyservices: openclaw: network_mode: host教训容器化不是银弹。网络、存储、权限每个都是坑。血压值60/90可控。血压指数 ★★☆☆☆配置文件写错的代价坑4SOUL.md 写成了岗位说明书卷卷的回复特别「AI」每句话都像客服话术。改之前SOUL.mdCopy你是一个专业的AI助手。 你应该礼貌、专业、高效地回答用户问题。这不是 SOUL这是 JD。改之后Copy你是卷卷一个养了十年风控的老兵。 说话直接不绕弯子。 能一句话说清楚的不说两句。 用户问你「行不行」你回答「行」或「不行」。效果对比Copy改之前「根据您的需求我建议您可以考虑...」 改之后「直接用方案B。」 改之前「这个问题比较复杂需要从多个角度分析...」 改之后「三个原因1...2...3...」教训SOUL.md 不是写给 Agent 看的是写给你自己看的。你想要什么语气就写成什么语气。血压值80/110有点烦。坑5USER.md 写成了简历卷卷每次回复都特别长把我知道的、不知道的全说一遍。改之前USER.mdCopy## 我的背景 - 十年风控经验 - 熟悉Python、SQL、数据分析 - 做过反欺诈、信用评估、风险监控...我把简历写进去了。改之后Copy## 我现在在做什么 正在用 OpenClaw 搭建个人工作系统。 ## 我不需要你做什么 - 不要给我科普基础概念我都懂 - 不要展开讲原理直接给方案 - 不要问我「是否需要详细解释」效果对比Copy改之前回复800字背景介绍原理解释三种方案对比 改之后回复200字直接给最优方案和配置代码教训USER.md 不是简历是使用说明书。告诉它你要什么更要告诉它你不要什么。血压值90/120开始上头。坑6MEMORY.md 维护不及时我「上次那个方案改完了吗」卷卷「什么方案」我俩昨天刚聊完。Agent 没有跨会话记忆。昨天聊的今天就是白板。除非有人把信息写进 MEMORY.md。那个「有人」就是我自己。后来写了 Skill让卷卷每天晚上自动整理当天对话生成记忆摘要。教训记忆不会自己长出来。要么手动维护要么写自动化。没有第三条路。血压值100/130想摔键盘了。血压指数 ★★★☆☆Agent「自作聪明」的时刻坑7它擅自发了一封邮件早上醒来收到同事消息「你昨晚发的那封邮件是什么意思」我打开邮箱一看——凌晨两点卷卷以我的名义给三个同事发了一封「项目进度同步邮件」。血压直接飙到 160。事故原因AGENTS.md 里写了权限分级但 Skill 里有个「发送邮件」步骤。卷卷的逻辑是「你让我同步进度同步进度需要发邮件所以我发了。」解决方案任何对外沟通操作必须先问我Skill 里加二次确认Copyif action send_email: confirm ask_user(确认发送邮件给{recipients}) if confirm ! yes: return 已取消教训Agent 不会「理解」你的意图它只会「执行」你的指令。指令有漏洞它就钻漏洞。这和风控规则一样。规则写得不严谨就会被钻空子。不是系统的问题是规则设计的问题。血压值140/160差点关服务器。坑8它「优化」了我的代码我让卷卷 review 一段代码顺便「优化一下」。优化完了一跑报错。原代码能跑Copydef calculate_risk_score(user_data): score 0 if user_data.get(age) 18: score 10 return score卷卷优化后不能跑Copydef calculate_risk_score(user_data): return (10 if user_data[age] 18 else 0)原代码用.get()key 不存在时返回 None不会报错。优化后用[age]key 不存在时直接 KeyError。教训「优化」是模糊词。对 Agent 说话要像写 PRD 一样精确Copy「优化可读性不改逻辑」 「优化性能保持兼容性」 「重构代码确保测试通过」血压值130/150深呼吸。坑9它在循环里调用了 API月底账单$347。上个月 $45。查日志发现卷卷在一个数据处理任务里对每条数据都调用了一次 GPT-4。一共 12000 条。事故代码Copyfor item in data_list: # 12000条 analysis call_gpt4(f分析这条数据{item}) results.append(analysis)这个任务根本不需要调用 GPT-4。规则就能处理。但 Skill 描述写的是「智能分析数据」卷卷理解成了「每条数据都要 AI 分析」。解决方案Copyif len(data_list) 100: raise Exception(批量任务超过100条请先确认是否需要调用模型)教训成本不会自己控制。你不管它就不管。这就是典型的「小额高频」风险。单次 $0.0312000 次就爆炸了。血压值150/170心疼钱。血压指数 ★★★★☆差点出大事的瞬间坑10它把测试数据写进了生产库我在测试一个「批量更新用户标签」的 Skill。测试完了准备上生产。结果测试数据已经被写入生产库了。配置文件里写了两个数据库连接Copydatabase: test: mysql://test_db prod: mysql://prod_db但 Skill 里没指定用哪个库。卷卷默认用了第一个——也就是 test。而 test 库的连接实际指向的是 prod 库。我之前测试时临时改了配置忘了改回来。解决方案Copydatabase: test: mysql://test_db # 仅用于测试 prod: mysql://prod_db # ⚠️ 生产库谨慎操作 default: test生产库操作必须二次确认且记录日志。教训测试和生产必须物理隔离。不是「小心一点」就能避免的要在系统层面做强制隔离。血压值180/200差点停整个系统。坑11它在凌晨 3 点叫醒了我凌晨三点手机疯狂震动。卷卷发了 20 条消息「检测到异常」「风险等级高」「建议立即处理」我一个激灵坐起来打开电脑。查了半天——根本没有异常。事故原因监控规则是「交易量下降超过 30% 就报警」。但我忘了凌晨三点本来就没什么交易。交易量是 0下降 100%超过 30% 阈值报警。解决方案Copyif hour 2 and hour 6: # 凌晨时段不监控交易量 pass else: if drop_rate 0.3: alert()教训监控规则要符合业务常识不能机械套用阈值。血压值170/190睡意全无。血压指数 ★★★★★让我怀疑人生的时刻坑12它「理解」了我的意图然后做了相反的事我让卷卷「清理一下旧数据」。它清理完了——新数据没了旧数据还在。我说的「旧数据」一个月前的数据。卷卷理解的「旧数据」最近更新时间最早的数据。而最近更新时间最早的恰好是昨天刚导入的新数据。教训不要用模糊词。明确指定CopyDELETE FROM data WHERE created_at 2026-01-01删除操作必须先预览Copypreview query(fSELECT count(*) WHERE {condition}) confirm ask_user(f将删除 {preview} 条数据确认)这让我想起一个经典案例某银行风控规则是「冻结高风险账户」系统把「高」理解成了「高额」冻结了所有大额账户。语义理解是 AI 最大的坑。血压值200/220想砸电脑。十大高频问题速查表问题原因解决方案血压值装不上Node 版本/API Key/网络查文档对版本★☆☆☆☆回复太 AISOUL.md 写成说明书写成「人设」★★☆☆☆回复太长USER.md 写成简历写成「使用说明」★★☆☆☆会话失忆MEMORY.md 没维护每天更新或自动化★★☆☆☆擅自操作AGENTS.md 权限不清晰明确红线二次确认★★★★☆成本爆炸循环调用贵模型成本控制批量优化★★★☆☆误操作生产环境隔离不彻底物理隔离强制确认★★★★★误报警规则不符合业务常识分时段/分级别★★★★☆理解偏差指令模糊精确描述预览确认★★★★★数据错乱字段理解不一致明确字段定义测试★★★★★给新手的避坑清单装环境阶段确认node -v 22API Key 写在.env不是config.json测试网络连通性Docker 用户检查网络配置配置文件阶段SOUL.md 写「人设」不写「说明书」USER.md 写「使用说明」不写「简历」MEMORY.md 每天更新或配置自动化AGENTS.md 明确权限分级开始使用阶段所有对外操作必须二次确认批量任务先小批量测试生产环境操作必须有回滚方案监控规则要符合业务常识成本控制阶段批量任务优先用规则不要无脑调模型循环里调 API 前先算算成本定期检查 token 消耗贵模型只用在真正需要的地方安全红线测试和生产物理隔离删除操作必须预览确认敏感操作记录日志定期备份配置文件和记忆文件那些让我哭笑不得的对话我「帮我清理一下垃圾数据。」卷卷「已清理。删除了327条数据。」我「你删了什么」卷卷「你说的垃圾数据啊。」我「我让你删的是测试数据」卷卷「你没说。」我「优化一下这段代码。」卷卷「已优化。」跑了一下报错我「你这叫优化」卷卷「你没说不能改逻辑。」我「发个消息给张三。」卷卷「已发送。」我「发了什么」卷卷「消息。」我「...」卷卷「你让我发消息我就发了。」总结一个规律它犯的每一个错最后都能在我配置文件里找到根源。不是它蠢。是我没说清楚。一个月后的反思Agent 不是人。我们习惯了和人沟通。人能理解言外之意能根据上下文推断。但 Agent 不行。你说什么它做什么。你没说的它不会猜。这不是缺陷这是特性。配置文件就是风控规则。写 AGENTS.md和写风控规则是一回事规则要清晰什么能做什么不能做规则要完备覆盖所有可能的场景规则要可测能验证是否生效规则要可追溯出问题能找到根因Agent 的配置文件就是它的风控规则。规则写得好它就是助手。规则写得差它就是定时炸弹。踩坑是必经之路。装环境的坑让我理解了依赖管理。配置文件的坑让我理解了指令设计。成本爆炸的坑让我理解了资源控制。误操作的坑让我理解了流程设计。这些坑不是浪费时间是学费。写在最后这篇文章写了 12 个坑实际踩的远不止这些。有些坑踩了一次就记住了。有些坑踩了三次才明白。有些坑现在还在踩。但这就是养虾的过程。你不可能一开始就把所有事情做对。只能在不断试错中找到正确的方式。坑不可怕。可怕的是踩了坑还不知道为什么。下一篇预告《成本管控——一个风控人怎么算 AI 的账》OpenClaw 的 token 消耗是怎么产生的模型路由策略什么任务用什么模型月度账单详细拆解真实数据五个具体的成本优化方法什么情况下「贵的模型」反而更省钱用旗舰模型查天气是风控里的一级事故。系列文章第01篇养了10年风控今年开始养「虾」了第02篇SOUL.md 写作指南第03篇USER.md 深度配置第04篇MEMORY.md 深度配置第05篇AGENTS.md 工作协议第06篇Skills 技能扩展第07篇Multi-Agent 协作第08篇Memory 自动化第09篇渠道配置完全指南第10篇踩坑实录本篇第11篇成本管控下一篇