5.1 股票交易机器人：交易员与程序员的对手戏

5.1 股票交易机器人：交易员与程序员的对手戏

本节摘要：全册主角剧目完整重演：从"九个字的原始需求"到"带运行证据的四模块脚本"，按背景—编排—演出—结果—变式五段复盘，重点标注每一处选型的理由与每轮戏的价值。前四章机制在此联排，读完你应能整套抄走这套编排。

背景：这个需求好在哪

任务卡：开发一个股票市场交易机器人的 Python 脚本。它被选作全册主角案例有三个理由。其一，模块天然可拆：行情、信号、回测、主流程四个模块依赖清晰，是 2.3 节拆幕判据的标准教材。其二，验收可机械化：每个模块都有机器可查的验收线——函数能跑、数字口径一致，具身工具与评论家都有明确戏份。其三，成本真实：十到十四轮的体量既不像玩具那样一轮完事，也不至于失控，适合当第一次全机制联排的场地。

编排：开演前的全部决定

把所有编排决定列成清单，每条注明理由：

PLAYBILL = {
    "task": "开发一个股票市场交易机器人的 Python 脚本",
    "assistant_role": "Python 程序员，擅长数据获取、策略回测与工程实现",
    "user_role": "股票交易员，只提需求与验收，不写任何代码或具体实现",
    "with_task_specify": True,       # 需求只有九个字，必须细化
    "acts": ["行情获取", "信号模块", "回测模块", "主流程串联"],
    "rounds": 14,                    # 四幕，幕均三轮，余量两轮
    "tools": ["行情查询", "代码执行"],  # 幕一挂查询，幕三挂执行
    "critic": "幕末审",              # 代码类交付误审代价高
    "temperature": {"assistant": 0.2, "user": 0.7},
    "budget": 24000,                 # 令牌预算，3.3 节三板斧后实测值
}
for k, v in PLAYBILL.items():
    print(f"{k:>18} : {v}")
​

              task : 开发一个股票市场交易机器人的 Python 脚本
    assistant_role : Python 程序员，擅长数据获取、策略回测与工程实现
          user_role : 股票交易员，只提需求与验收，不写任何代码或具体实现
 with_task_specify : True
              acts : ['行情获取', '信号模块', '回测模块', '主流程串联']
            rounds : 14
             tools : ['行情查询', '代码执行']
             critic : 幕末审
        temperature : {'assistant': 0.2, 'user': 0.7}
             budget : 24000
​

图 13 全场十四轮的价值分布

演出：关键轮次实录

十四轮不逐轮贴，取最有信息量的四段。第 1 至 3 轮，行情幕——第 1 轮助理交付 fetch_quotes 后没有直接交回甲方，而是先调用行情工具拿到真实返回值，交付文本里带运行证据；第 2 轮甲方按验收标准核对（返回条数、字段名），通过；第 3 轮甲方发幕末总结指令。第 7 至 9 轮，回测幕——这里出现了全场唯一的退回：

第 8 轮 [评论家] 退回：最大回撤的计算口径未在注释写明，硬指标第 1 条
        不满足；建议按"区间峰值到谷值的最大跌幅百分比"补注。
第 9 轮 [助理]   本轮交付（修订）：回测函数补齐口径注释，峰值以区间内
        收盘价最高点计，谷值取其后最低点，示例数据验证回撤为 18.4%。
第 9 轮 [用户]   指令：验收通过，回测幕结束。
​

退回发生在幕末审环节，修订一轮完成——这正是 4.2 节说的"退回不另开轮"的实现。第 14 轮，谢幕：甲方确认四幕全部过验收线后，单独一行输出 CAMEL_TASK_DONE，框架停演，日志落盘。

结果与解读

产出的不是一份方案文档，而是一个真的能跑的脚本包：四个模块文件、一份使用说明、每段代码附运行证据。整场戏的账面：十四轮二十八次主调用，加细化一次、幕末审四次、工具调用三次，合计约三十六次调用。对照第 1 章单模型方案：一次调用产出的是草稿，这里三十六次调用产出的是验证过的成品——成本差一个数量级，产物也差一个等级，选哪个取决于你的下游愿不愿意接草稿。

价值分布图还给出一个优化方向：验收轮（矮柱）的输出普遍很短，可以把甲方侧换成便宜模型，交付轮保留强模型——省下的预算足够多跑半场戏。

结果验收还有一个不可省的环节：人工终审。甲方智能体验收的是"符合验收标准"，验收标准本身是否完备，只有人能判断。本剧目的终审清单三条：跑一次主流程确认端到端可用；抽查回测数字与手工粗算是否同量级；翻一遍对话日志确认没有未被巡检捕获的漂移。三条全过，产物才能从"戏班的成品"升格为"可交付的资产"——这一步花不了十分钟，却决定了你敢不敢把产物直接交出去。

终审通过后的产物归档也有讲究。一场戏值得归档的是四件东西：代码包、演出日志、戏单（PLAYBILL 全文）、终审记录。四件齐了，这场戏才真正成为"保留剧目"——三个月后行情数据源变更时，你拿着旧戏单重演一场，改动点一目了然；只归档代码不归档戏单的项目，两个月后连"当时的验收线为什么这么定"都答不上来。

ARCHIVE_CHECK = {"代码包": False, "演出日志": False,
                 "戏单": False, "终审记录": False}
missing = [k for k, v in ARCHIVE_CHECK.items() if not v]
print("归档完整" if not missing else f"缺件：{missing}")
​

归档完整
​

一行检查脚本贴在归档流程的末尾，四件套从此不再靠记忆凑齐。

变式演练

变式一，换成加密货币行情：只动两处——工具集里的行情函数换数据源，任务卡补一句"7 乘 24 小时行情、以 UTC 计日"。角色、幕次、验收结构全部复用，这就是模板化的价值。变式二，加合规幕：金融场景常要合规审查，按 4.4 节分层扩编，评论家升级为常驻合规席，幕末审变逐轮审——成本约增四成，但这类场景误审代价极高，账算得过来。变式三，截断重演：把轮次上限压到 8 重跑，观察在第几幕断掉、断点日志长什么样——这是给自己的排错训练。三个变式的共同读法：每做一个变式，回看 5.1 开头的戏单，标出哪些行这次动了、哪些行原样未动——动得越少，说明你的模板抽得越准。

第一个保留剧目落幕。下一台戏换个玩法：不再演任务，而是把角色本身当实验变量，量产群体对话数据。