我们用 Claude Agent 做了个内部二手群，18% 成交率变 61%，过程惨不忍睹

三天前，我翻出了一张截图——我们团队的微信群，48 条消息挤在一起：

"收到""好的""谢谢""哈哈哈""收到""好的"……

夹在这 48 条消息正中间，有一条被彻底淹没的发言：

"有台九成新的 Dell 27 寸显示器，800 块，有要的吗？"

那条消息是小李发的。三天后他才知道，想买显示器的小张当天就看到了——但那时候消息早就沉底，小张以为没人卖，小李以为没人要，两个人在同一个办公室坐了三天，谁也没开口问。

最后显示器以 600 块卖给了闲鱼上的陌生人。

这件事让我们决定做一个实验：用 Claude Agent 把这个混乱的微信二手群，变成一个有结构的撮合系统。

三周后，成交率从 18% 跳到了 61%。但过程比我们预期惨得多——也有趣得多。

---

第一章：为什么要解决一个"不值得解决"的问题

坦白说，一个 10 人团队的内部二手交换，从任何商业角度看都是个微不足道的问题。

但正因为它微不足道，才是做 AI Agent 实验的完美场景：

• 规模小：10 个人，需求有限，不会因为数据量爆炸而失控
• 失败成本低：Agent 犯错，最坏结果是撮合失败，没有人会因此损失什么
• 反馈周期短：二手物品的需求很具体，匹配结果对不对，当天就能验证
• 问题结构清晰：卖方、买方、物品、价格——四个要素，没有歧义空间

更重要的是，这个场景在几乎所有团队都存在。你们公司有没有一个"内部福利群"或者"二手转让群"，但实际上没什么人用？那就是同一个问题。

我们把它当作一个可控的 AI 试验田，目标不是做一个完美产品，而是搞清楚：Claude Agent 在真实的、有摩擦的场景里，到底能做什么，做不了什么。

---

第二章：我们怎么设计这个 Agent

整个系统分四个模块，我用"搭积木"的方式解释：

用户自然语言输入
↓
【模块1】需求解析（Claude 负责）
↓
【模块2】结构化存储（SQLite / JSON）
↓
【模块3】撮合逻辑（Python 脚本）
↓
【模块4】通知推送（钉钉 Webhook）

模块1：需求解析 Prompt

这是整个系统最核心的部分。我们希望用户不需要填表单，直接用自然语言说话，Agent 自动把它变成结构化数据。

核心 Prompt 如下：

system_prompt = """
你是一个内部二手物资登记助手。
用户会用自然语言描述他们想出售或想购买的物品。
请将其解析为以下 JSON 格式：

{
"type": "sell | buy",
"item_name": "",
"condition": "全新 | 九成新 | 有磨损",
"price_range": {"min": 0, "max": 0},
"description": "",
"urgency": "急 | 不急"
}

规则：
1. 如果信息不足，列出需要追问的字段，不要猜测，不要补全
2. 价格区间：如果用户说"500左右"，解析为 {min: 450, max: 550}
3. item_name 必须是具体物品名，不接受"东西""物品"等模糊词
4. 如果用户同时有买卖需求，拆分为两条记录
5. 返回纯 JSON，不要任何解释文字
"""

⚠️ 关键设计决策：我们在 Prompt 里明确写了"如果信息不足，列出需要追问的字段，不要猜测"。这一条在第一版里没有，导致 Agent 经常脑补用户意图，后面会讲到这有多惨。

模块2：撮合逻辑

撮合的核心是判断"卖方的物品"和"买方的需求"是否匹配。我们用了一个简单但有效的策略：

def match_items(sell_item, buy_request):
"""
撮合逻辑：三层过滤
"""
# 第一层：类别过滤（精确匹配）
if not category_overlap(sell_item["item_name"], buy_request["item_name"]):
return False, 0

# 第二层：价格区间重叠
sell_max = sell_item["price_range"]["max"]
buy_max = buy_request["price_range"]["max"]
if sell_max > buy_max * 1.2:  # 允许20%溢价空间
return False, 0

# 第三层：语义相似度（调用 Claude 判断）
similarity_score = claude_semantic_match(
sell_item["description"],
buy_request["description"]
)

if similarity_score >= 0.7:
return True, similarity_score
return False, similarity_score

两个原因：

1. 中文语义匹配：我们测试过几个模型，Claude 在处理"差不多意思"的中文表达时，误判率明显更低

2. 长文本理解：当物品描述比较复杂时（比如"那种可以调高度的站立式办公桌，要能放双显示器的那种"），Claude 能保持语义的完整性

我们调用的是 Claude API，接入点用的是 [api.884819.xyz](https://api.884819.xyz)，支持标准 OpenAI 格式，对于小团队实验来说，迁移成本几乎为零。

模块3：钉钉 Webhook 推送

import requests
import json

def send_match_notification(seller, buyer, item_info):
webhook_url = "YOUR_DINGTALK_WEBHOOK_URL"

message = {
"msgtype": "markdown",
"markdown": {
"title": "🎯 发现匹配！",
"text": f"""
发现一个潜在匹配

物品：{item_info['item_name']}

卖方：{seller['name']} | 期望价：{item_info['price_range']['max']} 元

买方：{buyer['name']} | 预算上限：{buyer['price_range']['max']} 元

状态：{item_info['condition']}

请双方私信确认，48小时内无回应将自动关闭此匹配。

[点击查看详情](YOUR_SYSTEM_URL)
"""
}
}

response = requests.post(webhook_url, json=message)
return response.status_code == 200

---

第三章：3周真实数据——什么有效，什么彻底翻车

先上数据：

第一周的 18% 成交率，说实话，比我们预期还要惨。

翻车案例一：键盘遇上钢琴

第一周最经典的事故：同事小吴发布了一台"九成新机械键盘，Cherry 红轴，500 块"。Agent 在解析时，把 item_name 识别为"键盘"，没有问题。

但当时系统里有一条未成交的买方需求，是另一个同事小陈写的："想买一个能练习的键盘，预算 800 以内"。

Agent 兴冲冲地把两人撮合在一起，发了通知。

小陈回复："我要的是电子琴……"

这个 bug 的根源：我们的第一版 Prompt 没有让 Agent 在信息模糊时追问，而是允许它"合理推断"。"键盘"这个词在中文里确实有歧义，但 Agent 没有识别出歧义，直接匹配了。

翻车案例二：用户懒得说完整

我们原本设计了一套结构化输入流程，要求用户按格式填写：

物品名称：
成色：
价格：
描述：

实际情况是，10 个人里有 7 个人直接无视格式，发的是：

"有个充电宝，要不要"

"谁要买椅子"

"笔记本电脑，便宜卖"

Agent 在没有足够信息的情况下，会追问——但追问了两轮之后，用户就不回了。

这是第一周成交率惨的第二个原因：用户输入质量太低，导致大量需求卡在"信息收集"阶段，从未进入撮合池。

踩坑总结

1. 意图识别模糊：中文同义词和多义词问题，必须在 Prompt 里显式处理

2. 用户懒得填结构化表单：强制格式是死路，必须走自然语言路线

3. "最后一公里"AI 管不了：撮合成功之后，线下交接完全靠人，Agent 没有任何影响力

---

第四章：第三周我们做了什么，成交率从 18% 跳到 61%

改动分三个层次，每一个都有明确效果。

改动1：从"强制格式"到"自然语言 + Agent 自动解析"

这是最关键的改动。我们彻底放弃了结构化输入表单，改成：用户随便说，Agent 来解析，解析完了向用户确认一次。

新的交互流程：

用户：有个充电宝，要不要
Agent：我帮你登记一下～请确认以下信息是否正确：
- 出售物品：充电宝
- 成色：未知（请补充：全新/九成新/有磨损？）
- 价格：未知（请补充期望售价？）
用户：九成新，50块
Agent：好的，已登记✅
出售：充电宝 | 九成新 | 50元
我会在有匹配买家时通知你。

这个改动让发布物品的完成率从约 40% 提升到约 85%。用户不需要记格式，只需要确认 Agent 的理解是否正确。

改动2：模糊匹配 + 人工确认双保险

针对"键盘遇上钢琴"这类语义歧义问题，我们加了一个"低置信度撮合"机制：

def smart_match(sell_item, buy_request):
is_match, score = match_items(sell_item, buy_request)

if is_match and score >= 0.85:
# 高置信度：直接推送通知
send_match_notification(seller, buyer, sell_item)

elif is_match and 0.7 <= score < 0.85:
# 中等置信度：先问卖方确认
send_confirmation_request(
seller,
f"系统发现潜在买家，但不太确定是否匹配，请确认：\n买家需求：{buy_request['description']}"
)

这个机制让误撮合率从第一周的约 35% 降到第三周的约 8%。

改动3：用钉钉替代邮件通知

第一版我们用的是邮件通知。结果：没有人看邮件。

换成钉钉 Webhook 之后，通知打开率从约 20% 跳到约 90%。

这个改动和 AI 没有任何关系——但它对成交率的影响，可能比任何 Prompt 优化都大。

教训：Agent 的最后一步是触达人。如果触达渠道本身就失效了，前面所有的智能都白费。

---

第五章：这个实验真正教会我们的事

洞察一：小场景是最好的 AI 试验田

不要一上来就做"AI 客服系统"或者"AI 数据分析平台"。找一个团队内部真实存在的、有摩擦的小流程，用 Agent 跑通它。

小场景的好处：反馈快、失败成本低、迭代空间大。我们三周做了不止 20 次 Prompt 调整，如果是正式产品，每次改动都需要走审批流程，根本不可能。

洞察二：Claude 的真正优势在语义容错

我们测试过几个模型做需求解析，Claude 最突出的能力不是"准确"，而是"容错"——它能处理"那种能调高度的桌子""差不多 500 左右"这类模糊表达，而不是直接报错或者乱猜。

对于面向真实用户的 Agent，这个能力比任何 benchmark 分数都重要。

洞察三：AI 撮合 ≠ AI 替代人

这个实验里，Agent 做的事情是：降低信息摩擦。

它没有替代任何人的判断——最终买不买、价格谈不谈、东西好不好，全部还是人来决定。Agent 只是把"小李的显示器"和"小张的需求"放到了同一张桌子上。

这才是 AI 撮合的本质：减少信息不对称，而不是替代人的决策。

给想复刻这个实验的团队

如果你们团队也有一个被微信群淹没的内部流程，这是我建议你从哪里开始：

1. 最低配置：Python 基础 + Claude API 访问权限 + 一个能发消息的通知渠道（钉钉/飞书/企业微信均可）

2. 时间预期：第一版跑通需要约 2 天，跑出有意义的数据需要至少 2 周

3. 优先级：先把通知渠道打通，再优化 Prompt，最后才考虑撮合算法

4. API 接入：我们用的是 [api.884819.xyz](https://api.884819.xyz)，标准 OpenAI 格式，新用户注册即送体验 token，国产模型（Deepseek/千问等）完全免费，没有月租，适合小团队跑实验

---

📎 复刻资源包

• 完整 Prompt 模板：本文中的需求解析 Prompt 可直接使用，建议根据你们团队的物品类型做微调
• 撮合逻辑：三层过滤（类别 → 价格 → 语义）是核心框架，阈值参数需要根据实际数据调整
• 通知渠道：优先选团队最活跃的 IM 工具，不要用邮件
• API 接入说明：[api.884819.xyz](https://api.884819.xyz)，注册后直接能用

---

这次实验结束后，我们团队里有人问了一个问题：

"如果 Agent 能撮合二手物资，它能不能撮合人？比如——内部技能互换？"

我们正在做第二轮实验：让 Claude Agent 帮团队成员匹配"技能交换"需求——你教我 Python，我帮你做 PPT。

这个场景比二手物资复杂得多，因为"需求"和"供给"都是模糊的，匹配标准也是主观的。二手显示器好不好匹配，价格说了算；但"你教我做 PPT"这件事，怎么衡量匹配质量？Agent 在这里会遇到完全不同的挑战。

---

#AI教程 #Claude #AIAgent #人工智能 #8848AI #Prompt技巧 #AI实战 #效率工具