选题先问数据能不能长出来：硬件行情平台是怎么定下来的

立项前我先做了一件事：把手上的采集数据体检一遍，再决定论文讲什么。顺序不能反——先定题目再找数据，最后一定是拿虚构的历史把图表填满。

01四个候选方向各自的软肋

第二个选择之所以是“主推”，理由不是它最强，而是它是母体架构：算法实验能成为它的一章，治理能成为另一章，智能体再成为一章。三种答辩提问风格都能接住，而每个模块的设计文档顺手就是论文附录。

反过来看，如果一开始就选算法方向，后面想补系统就得重做工程；选平台方向则随时可以只写其中几章。选题阶段真正在选的是“能降级”还是“能升级”。

我把所有候选能力按一个标准分了两类：现有数据立刻能出的，和需要时间积累的。

能立刻出结果的：单日全类目的结构化快照、跨源同款配对、参数抽取与规格覆盖率、品牌溢价、截面性价比榜、Hedonic 参数—价格回归。这些都不依赖历史深度。

需要积累的：价格指数、榜单动态、跨源价差趋势、价格粘性。只要横轴是时间，就必须等。

结论写进了立项文档：**时序类能力作为演进项，不作为立论根基。**后面所有“要不要现在就把时序做完”的争论，都靠这句话收口——时序是加分项，链路先跑通、数据每天多攒一天，比把结论押在尚不存在的历史上安全得多。

日粒度看，挂出来的价格几乎不动。原因是这些站展示的是厂商参考挂牌价，成交在别处发生。价格不动 ⇒ 没有可预测的时变信号 ⇒ 预测实验在几十天内撑不起来。

所以措辞改成“走势刻画”。这不是文字游戏：把“预测”写进题目，等于承诺一个数据本身不支持的任务；换成刻画与解释，问题域就落回“跨源价差从哪来、结构怎么变”，而这恰好是数据能回答的。

同时留下两条配套约束：

三个智能体（问数、装机规划、研报生成）从第一天就被要求：输出必须以检索结果或 SQL 结果为事实底座，不做裸生成。

这条不是加分项，是及格线。一旦允许裸生成，答辩时“这个数从哪来”就没有答案；而只要每个数字都能回指一条 SQL 和一张表，智能体做得好不好反而成了次要问题。后来写 Agent 模块时，这条约束直接变成了实现方式：先取数、再组织语言，而不是把问题连同上下文一起丢给模型。

写选题对比那篇文档时，我顺手把“什么会被判不合格”列了出来：模块归属说不清、数据虚构、口径混用、生成不可验证。这四条后来在实现阶段反复被引用——每次犹豫“要不要走个捷径”，都是拿这份清单否掉的。

如果只能给一条建议：**把红线写在动代码之前，写在能改的时候。**等到代码写完再发现某条路线撑不起结论，成本就不是改措辞了。