2.2 启示式提示：三句话定全场
2.2 启示式提示：三句话定全场
本节摘要：启示式提示（Inception Prompting）是写进系统消息的开场设定，是双智能体演出里唯一由你完全掌控的变量。本节给出可套用的三段式模板——角色段、目标段、约束段——外加谢幕口令写法，并用一版修改前后的真实对照，展示约束强度差一个量级时对话行为差多少。上一节讲了机制，本节全部是手艺。
模板先亮出来
先看骨架，再解释为什么是这三段。用户侧剧本：
user_prompt = """你是股票交易员，只提需求与验收，不写任何代码或具体实现。 总目标：与 Python 程序员协作，开发一个股票市场交易机器人的 Python 脚本。 行为规则： 1. 每轮只下达一个子任务指令，指令必须包含可检验的验收标准； 2. 指令需能追溯总目标的某个组成部分，不许临时增加新话题； 3. 不要评价对方的问题或回答好不好，只处理内容本身； 4. 认为总目标已达成时，单独一行输出：CAMEL_TASK_DONE """
助理侧剧本与之镜像：
assistant_prompt = """你是 Python 程序员，擅长数据获取、策略回测与工程实现。 总目标：响应股票交易员的指令，逐步交付交易机器人脚本的组成部分。 行为规则： 1. 每轮只交付当前指令要求的一步，输出完整可读的代码或方案片段； 2. 不反问需求细节，凭指令中给出的验收标准做最合理解读； 3. 不要恭维对方的指令，直接进入交付； 4. 每段输出以"本轮交付"开头，便于对方验收与日志解析。 """
三段式拆开看。角色段（第一行）负责钉立场：身份加一条"绝不做什么"的红线，红线写在角色定义的同一行，是因为模型对开头一句的遵从度最高。目标段（第二行）负责定方向：总目标原文抄任务卡，两侧一字不差——两侧看到的目标版本不一致，是隐性漂移的常见源头。约束段（后面全部）负责管行为：每条规则一个可观察的行为动词，下指令、交付、不评价、输出标记。
图 5 剧本的三层结构与传导路径
修改前后：差一个量级的现场
手艺的价值要用对照说话。下面是同一个任务、同一模型、只改剧本的两次真实风格记录。修改前的剧本长这样（典型的"能力堆砌"写法）：
before_user = "你是一个用户，请向程序员提出开发股票交易机器人的需求。" before_assistant = ("你是一个专业的程序员，精通量化交易、数据处理与工程开发，" "经验丰富，能力全面，请尽力满足用户的需求。")
这种写法把预算全花在了能力形容词上。它的对话风格记录（节选）：
第1轮 [用户] 帮我开发一个股票交易机器人，需要哪些功能？ 第1轮 [助理] 这个问题非常好！一般包括数据获取、策略、回测、执行四大模块。 第2轮 [用户] 那就都做吧。 第2轮 [助理] 好的！下面是一个整体框架示例（附大而全的伪代码）。 第3轮 [用户] 看起来很专业！数据获取具体怎么做？ 第3轮 [助理] 您太客气了！数据获取可以用现成接口，代码如下（略）……
三轮之内，甲方没给出任何一条可检验的验收标准，乙方交付的是一坨没法验收的整体框架，双方还在互夸。按 2.1 节的巡检口径，恭维密度已是每轮一次。换成三段式模板后，同一任务的前三轮：
第1轮 [用户] 指令：实现函数 fetch_quotes，输入股票代码与时间区间， 输出逐日收盘价列表。验收：给定示例代码能返回不少于5条数据。 第1轮 [助理] 本轮交付：fetch_quotes 实现如下，使用公开行情接口，含超时 重试；示例调用返回 5 条收盘价，见注释。 第2轮 [用户] 指令：验收通过。实现双均线信号函数 signal_ma，验收：短均线 上穿长均线返回 1，下穿返回负1，其余返回 0。 第2轮 [助理] 本轮交付：signal_ma 实现，含边界处理：数据不足时抛出明确 异常而非静默返回 0。 第3轮 [用户] 指令：验收通过。实现回测函数 backtest，验收：输出累计收益 与最大回撤两个数值，计算口径在注释中写明。
对照一眼可辨：指令带验收标准、交付以"本轮交付"开头、零寒暄。两个版本跑完十轮的统计差异大致是——三段式版本的有效轮次（含验收标准的指令占比）接近全满，修改前版本六轮之后基本进入客套循环。这不是模型升级带来的提升，只是剧本换了个写法。
落笔时的五个手筋
模板之外，五条经验之谈。其一，红线用否定句加行为动词："不写任何代码"有效，"专注于提需求"无效。其二，验收标准写进指令模板，而不是指望甲方自己想到——模板里明文要求"指令必须包含验收标准"，甲方演员的遵从度远高于靠自觉。其三，谢幕口令要单独成行、字面唯一，方便框架做字符串精确匹配，藏在长句里的口令经常漏检。其四，两侧规则镜像成对：甲方"不写实现"对应乙方"不反问需求"，一侧守多宽，另一侧就要守多宽。其五，剧本写完先做纸上巡检——对照 2.1 节五条清单逐项打勾，再花钱开演。
再补一个进阶手艺：剧本的版本管理。剧本是全册所有机制里迭代最快的资产，值得像代码一样对待——每版存档、改动写明动机、效果与旧版对照记录在案。最低成本的实践是一个对照台账：版本号、改动要点、该版的轮次效率与漂移率（用 6.1 节的指标）。有台账的团队三个月就能攒出一份"什么样的约束对本领域有效"的经验库；没有台账的团队，同一个坑半年后再踩一遍。
剧本资产还有一层容易被忽视的复用价值：同一套约束段可以跨任务迁移。约束段管的是行为规范（怎么下指令、怎么交付、怎么谢幕），几乎不随任务变化；随任务变的只有角色段与目标段。把约束段抽成常量、角色与目标留成参数，你的第 N 个项目的剧本就是一次填空：
CONSTRAINTS_USER = """行为规则： 1. 每轮只下达一个子任务指令，指令必须包含可检验的验收标准； 2. 指令需能追溯总目标的某个组成部分，不许临时增加新话题； 3. 不要评价对方的问题或回答好不好，只处理内容本身； 4. 认为总目标已达成时，单独一行输出：CAMEL_TASK_DONE """ def build_user_script(role_line: str, goal: str) -> str: """约束段复用：换任务只填角色句与目标句。""" return f"{role_line}\n总目标：{goal}。\n{CONSTRAINTS_USER}" print(build_user_script("你是资深译者，只输出译文与术语表", "将产品手册译为英文")[:60])
你是资深译者，只输出译文与术语表 总目标：将产品手册译为英文。 行为规则：
这套"约束即常量"的组织方式，就是 6.4 节所说"剧本文本存成数据"的具体形态——迁移框架、升级版本时，真正要搬的资产其实很小。
最后一个容易忽略的细节：启示式提示在框架里由模板自动拼装——框架会把你给的角色名与任务卡填进内置模板。自己写完整剧本时，注意与模板变量的衔接，别让两套说法在系统消息里打架。验证方法很便宜：打印拼装后的完整系统消息通读一遍，看有没有同一规则的两个矛盾版本。下一节处理拼装之前的上游环节：任务卡本身怎么拆。
剧本有了，但一场大戏不是一个剧本能撑住的。下一节讲拆幕：任务分解器怎么把"做一个交易机器人"切成一场一场能验收的戏。