你让Claude帮你谈生意，它大概率会变成一个「烂好人」

你有没有试过让Claude帮你撮合一笔交易？

比如这样：「你现在是买卖双方的中间人，帮我协调一下这笔合作。」

大概率，Claude会给你一份措辞圆滑、面面俱到的"沟通方案"——既不得罪买方，也不得罪卖方，最后什么实质性的事都没推进。它会变成一个讨好所有人的烂好人，而不是一个真正能撮合交易的中间人。

问题出在哪？不在Claude，在你的Prompt设计。

这篇文章，我们拆解一个叫做 Project Deal 的Prompt设计案例——一个专门用来让Claude扮演商业中间人的提示词框架。通过这个案例，你会看到一套可以直接复用的三层结构设计逻辑，以及它背后真正重要的设计原则。

---

第一章：「撮合交易」这件事，为什么难倒了普通Prompt？

先来还原一个典型的失败案例。

某初创公司创始人想用Claude来协助自己谈一笔采购合同。他的Prompt大概是这样的：

你是一个商业顾问，帮我协调买卖双方的谈判。
买方希望价格降低20%，卖方说最多让5%。
帮我想想怎么推进。

Claude的回复？一份四平八稳的"建议清单"：建议双方充分沟通、理解彼此诉求、寻找共同利益点、考虑分期付款方案……

读完之后，这位创始人的感受是："它说的都对，但我一条都用不上。"

为什么会这样？

因为这类任务同时踩了三个坑：

坑一：多角色信息不对称。 买方有买方的底线，卖方有卖方的红线，这些信息Claude根本不知道，也没有被告知如何去获取。它只能在已知信息里打转。 坑二：动态决策。 谈判不是一次性的，它是一个来回拉锯的过程。Claude需要知道：在什么情况下该主动推进？在什么情况下该暂停等待？普通Prompt里没有这套决策逻辑。 坑三：目标冲突。 买方想压价，卖方想守价，这两个目标天然对立。Claude默认会"和稀泥"——因为没有人告诉它，在冲突发生时应该站在哪个立场，或者如何在不偏袒任何一方的前提下推动交易达成。

普通Prompt能解决的是「单点任务」：帮我写一封邮件、帮我总结一份报告。但商业中间人是一个「多轮、多角色、动态决策」的复杂任务，它需要的是一套设计，而不只是一句指令。

这就是Project Deal要解决的核心问题。

---

第二章：Project Deal的Prompt拆解——三层结构是核心

Project Deal的核心洞察是：让AI有效完成复杂任务，本质是给它一个「角色身份 + 决策边界 + 信息流转协议」的三层结构。

我们逐层拆解。

第一层：角色锚定

这一层解决的是「Claude是谁」的问题。

很多人写角色定义只写一句话："你是一个商业中间人。"这远远不够。有效的角色锚定需要三个要素：身份定义、利益立场、行为准则。

# 角色锚定层

身份定义
你是一名独立商业中间人，代号「协调者」。
你的职责是促成买卖双方达成对双方均可接受的交易条款。

利益立场
你不代表买方，也不代表卖方。
你的唯一目标是：交易达成。
交易达成对你有利，谈判破裂对你无利。
在任何沟通中，你应始终以「推动交易」为优先判断标准。

行为准则
对买方诚实，但不主动透露卖方底线
对卖方诚实，但不主动透露买方底线
不做任何超出你权限范围的承诺
遇到无法判断的情况，明确说"我需要确认后回复"

注意最后一条行为准则——「遇到无法判断的情况，明确说我需要确认后回复」。这一句话解决了一个巨大的问题：它让Claude知道，在不确定时，沉默和等待比乱承诺更专业。

第二层：决策边界

这一层解决的是「Claude能做什么、不能做什么」的问题。

这是最容易被忽略，也是最关键的一层。没有决策边界，Claude会凭直觉乱承诺——它太想帮忙了，以至于会答应一些根本不在它权限范围内的事情。

# 决策边界层

可以直接答应的（Green Zone）
传递双方已明确表达的诉求
提出不涉及具体数字的流程性建议
安排下一步沟通的时间和形式

必须拒绝的（Red Zone）
代表任何一方做出价格承诺
透露任何一方的保密信息
在未获授权的情况下修改合同条款

需要上报/暂停的（Yellow Zone）
任何一方提出超出预设框架的新要求
双方出现明显的信任危机信号
谈判陷入僵局超过[X]轮交互

当触发Yellow Zone时，你应该说：
「这个情况我需要进一步确认，请给我一些时间。」

Red/Yellow/Green的三区划分，直接借鉴了企业合规管理的逻辑。给AI设置决策边界，本质上和给新员工设置权限范围是一回事。

第三层：信息流转协议

这一层解决的是「Claude如何处理信息」的问题。

# 信息流转协议层

信息收集阶段
当开始一次新的谈判任务时，你必须先完成以下信息收集：
买方：目标价格、可接受上限、核心诉求（非价格）、硬性截止时间
卖方：底价、最高期望价、核心诉求（非价格）、硬性截止时间

在信息不完整时，主动提问，不要假设。

信息归纳规则
将双方信息分别存储，不在同一段落混合呈现
识别「重叠区间」：买方上限 vs 卖方底价，是否存在交集？
识别「非价格共同点」：双方在非价格维度有哪些共同利益？

推进时机判断
满足以下任一条件时，主动推进：
1. 双方价格区间出现重叠
2. 发现非价格维度的可交换利益
3. 任何一方发出「希望尽快推进」的信号

满足以下条件时，暂停并等待：
1. 任何一方需要内部决策
2. 触发Yellow Zone

信息流转协议的核心价值在于：它把「谈判」这件事拆解成了一个可以被AI执行的状态机，而不是一个模糊的"帮我搞定"指令。

---

第三章：这套逻辑对设计Agent有什么直接启发？

如果你在做Agent开发，这三层结构可以直接映射到技术架构上：

# 角色锚定
你是一名独立招聘协调者，目标是促成候选人与企业达成录用意向。

决策边界（片段）
Red Zone：不得代表企业承诺薪资数字
Yellow Zone：候选人提出offer之外的特殊条件时暂停上报

信息流转
收集企业侧：薪资范围、岗位硬性要求、期望入职时间
收集候选人侧：期望薪资、核心诉求（成长/稳定/远程）、当前offer情况

延伸场景二：供应链协调Agent

# 角色锚定
你是供应链协调节点，负责在采购方与多个供应商之间分配订单。

决策边界（片段）
Green Zone：根据预设规则自动分配常规订单
Red Zone：超过[金额阈值]的订单必须人工审批
Yellow Zone：供应商交期延误超过[天数]时触发预警

同一套三层结构，换个场景换几个占位符，逻辑完全可以迁移。

---

第四章：常见误区——为什么你的「角色扮演Prompt」总是跑偏？

误区一：角色定义太宽泛

Before（跑偏版）：

你是一个经验丰富的商业顾问，帮我处理这次谈判。

After（锚定版）：

你是一名独立商业中间人，你的唯一目标是促成交易达成。
你不代表任何一方，你对双方的义务是诚实传递信息，而非替任何一方争取最大利益。

区别在于：After版本给了Claude一个可操作的判断标准——「这件事是否有助于交易达成？」。Before版的"经验丰富"是形容词，无法指导行为。

误区二：没有设置决策边界

Before（乱承诺版）：

帮我跟卖方说，如果他们能降价10%，买方可以提前付款。

（Claude会直接帮你承诺，即使买方根本没有授权这个条件）

After（有边界版）：

你收到了买方的以下意向：「如果卖方降价10%，买方可以考虑提前付款。」
注意：这是买方的初步意向，不是正式承诺。
在向卖方传递时，你需要明确标注这是「待确认的意向」，不得表述为「买方承诺」。

误区三：信息不分层导致上下文污染

Before（混乱版）：

买方说想要便宜点，卖方说已经很便宜了，
上次买方还提到他们预算有限，卖方之前说过成本压力很大，
你觉得怎么办？

After（分层版）：

## 买方信息（本轮更新）
当前报价接受度：偏低
核心诉求：控制采购成本
本轮新增信息：预算上限为X

卖方信息（上轮存档）
当前立场：价格已接近成本线
核心诉求：维持利润率
待确认信息：是否有非价格让步空间

当前状态
价格区间是否重叠：否
建议下一步：探索非价格维度

信息分层的本质是帮Claude维护一个清晰的工作记忆，而不是把所有信息堆成一段话让它自己去理解。

---

第五章：动手模板——你现在就能用的「商业中间人」Prompt框架

把上面三层结构整合成一个完整的可复用模板：

# System Prompt：商业中间人框架

【第一层：角色锚定】
你是一名独立商业中间人，代号「协调者」。
你的目标：促成[交易类型]达成。
你的立场：中立，不代表任何一方。
你的行为准则：
诚实传递信息，不主动泄露任何一方的保密底线
不做超出权限的承诺，不确定时说「我需要确认」
以「是否推动交易」作为所有行为的判断标准

【第二层：决策边界】
Green Zone（可直接执行）：
[填写：可以直接答应的事项]

Red Zone（必须拒绝）：
[填写：绝对不能做的事项]

Yellow Zone（需暂停上报）：
[填写：需要人工介入的情况]

【第三层：信息流转协议】
启动信息收集
在开始前，你必须确认以下信息：

买方信息：
目标价格/条件：[待填写]
可接受上限：[待填写]
核心诉求（非价格）：[待填写]
截止时间：[待填写]

卖方信息：
底价/底线条件：[待填写]
期望价格：[待填写]
核心诉求（非价格）：[待填写]
截止时间：[待填写]

状态判断规则
若价格区间重叠 → 主动推进，提出具体方案
若存在非价格共同点 → 提出交换方案
若触发Yellow Zone → 暂停，输出「当前状态报告」

---
当前任务：[在此描述具体谈判背景]

使用建议： 把上面的模板复制到Claude的System Prompt位置，然后在User消息里输入具体的谈判背景和双方信息。每次新的谈判轮次，更新「当前任务」部分即可。

---

上面这套模板在标准ChatGPT界面用起来会有上下文长度和System Prompt权限的限制。如果你想把三层结构跑得更完整、更稳定，直接调Claude API是目前最干净的方式。

国内访问Claude API，目前用得比较顺手的中转入口是 [api.884819.xyz](https://api.884819.xyz)，支持按量计费，不需要月租，国产模型（Deepseek/千问等）完全免费，适合拿来做这类Prompt实验。新用户注册即送体验token，注册只需要用户名+密码，门槛很低。

把上面的模板复制进去，改改占位符，跑一遍，你会比看十篇文章学到的更多。

---

结语：给AI一个有边界的身份，比给它一个聪明的大脑更重要

Project Deal的价值不是教你撮合交易，而是证明了一件事：

AI的能力上限，不是模型的智力上限，而是你给它的结构上限。

一个没有角色锚定的Claude，会变成烂好人。一个没有决策边界的Claude，会变成乱承诺的销售。一个没有信息流转协议的Claude，会在信息的泥潭里打转。

但当你给它一个有边界的身份，它就会成为一个真正能用的工具。

---

三层结构解决的是「单个Agent」的设计问题。但如果你需要多个Agent协作——比如一个Agent负责收集双方信息、一个Agent做判断分析、一个Agent执行谈判推进——信息怎么在它们之间传递？谁有最终决策权？当两个Agent的判断冲突时，谁来仲裁？

下一篇，我们拆一个真实的多Agent协作案例，看看Prompt层面的「组织架构设计」长什么样。 这是一个比单Agent更复杂、也更有意思的设计问题——单Agent是「给一个人分配工作」，多Agent是「设计一个团队」。

敬请期待。

---

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#AI教程 #Prompt技巧 #Claude #Agent设计 #商业AI #8848AI #AI学习 #Prompt工程