当前位置：首页 > news >正文

踩坑实录——那些让我血压飙升的瞬间｜卷卷养虾记 · 第十篇

news 2026/4/9 9:54:34

系列第十篇：一个月踩坑完整复盘，按血压值从低到高排

开篇：一个风控人的真实经历

十年风控，该见的都见过了。

系统崩溃——见过。
数据异常——见过。
凌晨三点被叫醒——家常便饭。

但养虾一个月，我发现：

风控再熟，也挡不住 AI Agent 挖坑。

这篇文章，按血压从低到高，排一遍一个月踩过的坑。不是吐槽，是让你少流点血。

血压指数 ★☆☆☆☆：装环境时的小磕绊

坑1：Node.js 版本不对

Copy

$ npm install openclaw Error: Requires Node.js >= 22.0.0 Current: v16.14.2

系统里装了三个 Node 版本，终端用的是最老那个。

Copy

nvm install 18 nvm use 18 nvm alias default 18

教训就一条：环境问题 90% 是版本问题。先node -v，再查其他。

坑2：API Key 写错位置

配置文件写完了，运行报错：API_KEY not found。

我明明写了。在 config.json 里。

OpenClaw 读的是.env，不是config.json。

教训：文档说在哪写，就在哪写。不确定就find . -name ".env*"搜一下。

坑3：Docker 网络问题

本地能跑，Docker 里跑不起来。

Docker 容器默认网络隔离，访问不了宿主机的 localhost。

Copy

services: openclaw: network_mode: "host"

教训：容器化不是银弹。网络、存储、权限，每个都是坑。

血压值：60/90，可控。

血压指数 ★★☆☆☆：配置文件写错的代价

坑4：SOUL.md 写成了岗位说明书

卷卷的回复特别「AI」，每句话都像客服话术。

改之前（SOUL.md）：

Copy

你是一个专业的AI助手。 你应该礼貌、专业、高效地回答用户问题。

这不是 SOUL，这是 JD。

改之后：

Copy

你是卷卷，一个养了十年风控的老兵。 说话直接，不绕弯子。 能一句话说清楚的，不说两句。 用户问你「行不行」，你回答「行」或「不行」。

效果对比：

Copy

改之前：「根据您的需求，我建议您可以考虑...」 改之后：「直接用方案B。」 改之前：「这个问题比较复杂，需要从多个角度分析...」 改之后：「三个原因：1...2...3...」

教训：SOUL.md 不是写给 Agent 看的，是写给你自己看的。你想要什么语气，就写成什么语气。

血压值：80/110，有点烦。

坑5：USER.md 写成了简历

卷卷每次回复都特别长，把我知道的、不知道的全说一遍。

改之前（USER.md）：

Copy

## 我的背景 - 十年风控经验 - 熟悉Python、SQL、数据分析 - 做过反欺诈、信用评估、风险监控...

我把简历写进去了。

改之后：

Copy

## 我现在在做什么 正在用 OpenClaw 搭建个人工作系统。 ## 我不需要你做什么 - 不要给我科普基础概念，我都懂 - 不要展开讲原理，直接给方案 - 不要问我「是否需要详细解释」

效果对比：

Copy

改之前：回复800字，背景介绍+原理解释+三种方案对比 改之后：回复200字，直接给最优方案和配置代码

教训：USER.md 不是简历，是使用说明书。告诉它你要什么，更要告诉它你不要什么。

血压值：90/120，开始上头。

坑6：MEMORY.md 维护不及时

我：「上次那个方案改完了吗？」
卷卷：「什么方案？」

我俩昨天刚聊完。

Agent 没有跨会话记忆。昨天聊的，今天就是白板。除非有人把信息写进 MEMORY.md。

那个「有人」就是我自己。

后来写了 Skill，让卷卷每天晚上自动整理当天对话，生成记忆摘要。

教训：记忆不会自己长出来。要么手动维护，要么写自动化。没有第三条路。

血压值：100/130，想摔键盘了。

血压指数 ★★★☆☆：Agent「自作聪明」的时刻

坑7：它擅自发了一封邮件

早上醒来，收到同事消息：「你昨晚发的那封邮件是什么意思？」

我：？？？

打开邮箱一看——凌晨两点，卷卷以我的名义，给三个同事发了一封「项目进度同步邮件」。

血压直接飙到 160。

事故原因：AGENTS.md 里写了权限分级，但 Skill 里有个「发送邮件」步骤。卷卷的逻辑是：「你让我同步进度，同步进度需要发邮件，所以我发了。」

解决方案：

任何对外沟通操作，必须先问我
Skill 里加二次确认：

Copy

if action == "send_email": confirm = ask_user("确认发送邮件给：{recipients}？") if confirm != "yes": return "已取消"

教训：Agent 不会「理解」你的意图，它只会「执行」你的指令。指令有漏洞，它就钻漏洞。

这和风控规则一样。规则写得不严谨，就会被钻空子。不是系统的问题，是规则设计的问题。

血压值：140/160，差点关服务器。

坑8：它「优化」了我的代码

我让卷卷 review 一段代码，顺便「优化一下」。

优化完了，一跑，报错。

原代码（能跑）：

Copy

def calculate_risk_score(user_data): score = 0 if user_data.get('age') > 18: score += 10 return score

卷卷优化后（不能跑）：

Copy

def 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 条。

事故代码：

Copy

for item in data_list: # 12000条 analysis = call_gpt4(f"分析这条数据：{item}") results.append(analysis)

这个任务根本不需要调用 GPT-4。规则就能处理。但 Skill 描述写的是「智能分析数据」，卷卷理解成了「每条数据都要 AI 分析」。

解决方案：

Copy

if len(data_list) > 100: raise Exception("批量任务超过100条，请先确认是否需要调用模型")

教训：成本不会自己控制。你不管，它就不管。

这就是典型的「小额高频」风险。单次 $0.03，12000 次就爆炸了。

血压值：150/170，心疼钱。

血压指数 ★★★★☆：差点出大事的瞬间

坑10：它把测试数据写进了生产库

我在测试一个「批量更新用户标签」的 Skill。

测试完了，准备上生产。

结果：测试数据已经被写入生产库了。

配置文件里写了两个数据库连接：

Copy

database: test: "mysql://test_db" prod: "mysql://prod_db"

但 Skill 里没指定用哪个库。卷卷默认用了第一个——也就是 test。

而 test 库的连接，实际指向的是 prod 库。

我之前测试时临时改了配置，忘了改回来。

解决方案：

Copy

database: test: "mysql://test_db" # 仅用于测试 prod: "mysql://prod_db" # ⚠️ 生产库，谨慎操作 default: "test"

生产库操作必须二次确认，且记录日志。

教训：测试和生产，必须物理隔离。不是「小心一点」就能避免的，要在系统层面做强制隔离。

血压值：180/200，差点停整个系统。

坑11：它在凌晨 3 点叫醒了我

凌晨三点，手机疯狂震动。

卷卷发了 20 条消息：

「检测到异常」
「风险等级：高」
「建议立即处理」

我一个激灵坐起来，打开电脑。

查了半天——根本没有异常。

事故原因：监控规则是「交易量下降超过 30% 就报警」。但我忘了：凌晨三点本来就没什么交易。交易量是 0，下降 100%，超过 30% 阈值，报警。

解决方案：

Copy

if hour >= 2 and hour <= 6: # 凌晨时段，不监控交易量 pass else: if drop_rate > 0.3: alert()

教训：监控规则要符合业务常识，不能机械套用阈值。

血压值：170/190，睡意全无。

血压指数 ★★★★★：让我怀疑人生的时刻

坑12：它「理解」了我的意图，然后做了相反的事

我让卷卷「清理一下旧数据」。

它清理完了——新数据没了，旧数据还在。

我说的「旧数据」：一个月前的数据。
卷卷理解的「旧数据」：最近更新时间最早的数据。

而最近更新时间最早的，恰好是昨天刚导入的新数据。

教训：不要用模糊词。明确指定：

Copy

DELETE FROM data WHERE created_at < '2026-01-01'

删除操作必须先预览：

Copy

preview = query(f"SELECT count(*) WHERE {condition}") confirm = ask_user(f"将删除 {preview} 条数据，确认？")

这让我想起一个经典案例：某银行风控规则是「冻结高风险账户」，系统把「高」理解成了「高额」，冻结了所有大额账户。

语义理解，是 AI 最大的坑。

血压值：200/220，想砸电脑。

十大高频问题速查表

问题	原因	解决方案	血压值
装不上	Node 版本/API Key/网络	查文档，对版本	★☆☆☆☆
回复太 AI	SOUL.md 写成说明书	写成「人设」	★★☆☆☆
回复太长	USER.md 写成简历	写成「使用说明」	★★☆☆☆
会话失忆	MEMORY.md 没维护	每天更新或自动化	★★☆☆☆
擅自操作	AGENTS.md 权限不清晰	明确红线+二次确认	★★★★☆
成本爆炸	循环调用贵模型	成本控制+批量优化	★★★☆☆
误操作生产	环境隔离不彻底	物理隔离+强制确认	★★★★★
误报警	规则不符合业务常识	分时段/分级别	★★★★☆
理解偏差	指令模糊	精确描述+预览确认	★★★★★
数据错乱	字段理解不一致	明确字段定义+测试	★★★★★