M6第 4 课 · 交易研究台M6-L4.2

Delivery Plan：交易研究台

一句话： Trade Recommendation Desk 交付计划把整个构建装进两名工程师的八周时间：拆成 35 个带可核对完成标准的任务，估算 71 天工作量对应 80 天可用时间，并固定了必须按顺序发生的里程碑。

原始文档： Trade Recommendation Desk, Delivery Plan，Azure Partners，Sprint 1 最终版。本页是阅读指南。它是本 Module 的参考交付计划。

计划的整体形态

要素	计划中的内容
产能	两名工程师、八周、每周 40 小时：80 个工作日
工作量	8 个领域 35 个任务，估算 71 天
缓冲	9 天，略高于 10%
最大的任务	财报数据客户端（B1）、run manager（D4）和发布服务（D6），各 4 天；其余任务都不超过 3 天
完成的定义	任务在”完成标准”一栏为真时才算完成，而不是代码写完时

八个领域

领域	天数	工程师 A	工程师 B
A. 环境搭建	5	1	4
B. 数据	11	9	2
C. 策略与回测	14	14	0
D. Agent 与运行流水线	18	0	18
E. 前向交易与跟踪	5	5	0
F. 前端	5	0	5
G. 测试	9	4.5	4.5
H. 收尾	4	2.5	1.5
合计	71	36	35

工程师 A 负责数据、策略和前向交易。工程师 B 负责 agent、后端 API 和前端，以及运行 Puffo 的那台机器。测试和收尾共同承担，第 1 周两人一起工作。

“完成标准”

任务表的最后一栏是这份计划最有用的习惯。比较同一个任务的两种写法：

弱的写法	计划中的写法
做 holdout 锁	没有日志行就不存在任何结果，并且 holdout 拒绝第二次运行
搭好 Puffo	daemon 运行，两个 agent 互发消息，一个 agent 调用了一个测试工具
Run manager	运行按状态推进，Desk Lead 被告知下一步发什么，重复唤醒不改变任何东西

每一条标准都是别人不用问负责人就能核对的。

里程碑及其顺序

时间	里程碑	为什么放在这里
第 1 周末	Puffo 运行两个 agent；供应商、股票、日期和成本记录在案	最大的未知（平台、数据许可、股票池规则）最先确定
第 3 周末	导师批准成功门槛	在任何验证结果出现之前，门槛无法移动
第 5 周末	导师检查规则冻结；规则打上标签	在 holdout 之前，确保 holdout 在冻结的规则上运行
第 6 周	holdout 运行一次；前向模拟交易开始	只在冻结之后
第 6–8 周	三个每周流程	在未见过的数据上获得前向证据
第 8 周	结果报告、演示和交接

这个顺序不是为了方便。把门槛审批挪到验证之后，或把 holdout 放到冻结之前，都会违反产品规则 5。

工作规则

一台机器。 只有工程师 B 的机器运行 Puffo，工程师 A 使用模拟器和样例数据。
真实运行时段。 每天预约两个一小时的时段进行真实 agent 运行，因为六个 agent 共享一个账号和一份额度。
每周流程。 从第 6 周起的每个周一，工程师 A 在美股开盘前运行 desk week；PM 启动审阅；判断在收盘前发布。
互相评审。 到第 8 周，没有任何一块只有一个人懂。

PM 在哪里砍了时间

工程师的估算只是计划的一半，另一半是 PM 为了让估算排得下而移除的东西。这份计划本身没有列出砍掉的内容，但 PRD 的范围外和后续阶段清单显示了范围的边界：定时任务、纯规则对照组合、自动用量跟踪、期权及其他资产类别、电话会议记录和分析师预期。自己写交付计划时，把砍掉的内容也写进计划，免得大家以为它还会来。

常见误区

“缓冲是浪费时间。” 71 天工作量配 9 天缓冲，正是用来吸收那几个 4 天任务超时的。没有缓冲的计划，其实已经延期了。
“两人并行负责意味着双倍风险。” 这种分工让两名工程师各自位于 evidence ID 边界的一侧（数据与策略 vs. agent 与发布），在一个定义好的接口处会合。

典型面试题

客户想在第 4 周加入期权分析。这份计划让你能说什么？

计划只有 9 天缓冲；期权工作需要数据、工具、一个专家 agent 和测试，而这些都不在已验证的规则里。现在加入会危及第 5 周的冻结和第 6 周的 holdout，而这两个节点由产品规则固定。可以把它作为后续阶段提出，或者问客户愿意砍掉哪个现有任务来腾出空间。

为什么成功门槛在第 3 周批准，而不是在最后？

因为它必须在看到验证结果之前设定。如果之后再定，门槛就可能被定成策略碰巧达到的水平，结果也就证明不了任何东西。