当需求预测变成"给我两分钟"

Slack弹出一条消息："周五前要个零件需求预测，粗略就行。"你看了眼时间，周二下午五点。按老办法，这意味着从数据库提数、清洗成周度时间序列、构造滞后特征、训练基线模型、验证不骗自己、再搭个能打开的看板——至少一周。但现在有人回复："给我两分钟。"

Anton是什么

这是一个开源的桌面智能体，在Mac、Linux、Windows本地运行。开发者对它的描述很直白：你用自然语言跟它说话，它真的去干活。

连接数据库、找趋势、训模型、搭看板——你提需求，它拆解步骤、写Python和SQL、在沙箱里跑代码、出错自己调试、把结果带回来。所有代码存在一个叫"scratchpad"的地方，逐行可查，没有黑箱。

安装是一条命令，GitHub上有说明，五分钟搞定。本文用Windows桌面版演示。

正方：这确实省掉了脏活累活

我先让Anton连上数据源。左侧有个"Add Datasource"按钮，选Postgres，填提示信息。这里用的是演示用的Supabase数据库，F-35 sustainment项目的航空电子采购订单数据——真实形状的数据，不是玩具。

凭证不会传给大语言模型。Anton存在本地vault里，只按名称引用。

连上之后我问它："搜一下两个数据源里的采购订单表。"几秒后它返回：Supabase数据库里有一张500行的采购订单表，零件号、供应商、交货周期、数量、国防项目标签、质量标记——该有的列都有。它还主动建议："要不要跟suppliers和line_items表做个关联？"

我没接这个茬，直接下任务："做一个未来六个月的需求预测。"

Anton开始规划。它列出的步骤包括：识别相关表、理解数据结构、构造时间序列、处理缺失值、选模型、训练、验证、生成预测。然后它问：是用Prophet、ARIMA，还是XGBoost/LightGBM这类梯度提升？

我选了XGBoost。它确认目标变量是quantity，时间粒度是周，需要构造滞后特征和滚动统计量，还要按part_number分组做多序列预测。

接着它就去了。写SQL提数，用pandas处理，构造特征工程，训练模型，生成预测，还顺手做了可视化。整个过程在沙箱里完成，代码全在scratchpad里。

从"给我两分钟"到拿到结果，实际用了不到十分钟。预测覆盖未来26周，按零件号分组，包含点预测和置信区间，输出直接是DataFrame格式。

反方：但"能跑"和"能用"是两回事

Anton确实生成了预测，但仔细看scratchpad里的代码，问题很明显。

特征工程部分，它构造了滞后1-4周的quantity，以及4周滚动均值和标准差。这对平稳序列还行，但采购订单数据常有季节性波动和促销脉冲，这些特征捕捉不到。它也没处理异常值，而500行数据里明显有几个数量级偏离的订单。

模型选择上，它直接用了XGBoost的默认参数，没做交叉验证，更没有针对时间序列的滚动验证。训练集测试集是按时间顺序切分的，这没错，但测试集只有最后20%的数据，对于六个月预测来说，验证力度太弱。

最麻烦的是误差估计。它给出的"置信区间"其实是用预测值加减一个固定比例算出来的，不是从模型不确定性推导的。这在业务场景里会出大事——Sarah拿着这个区间去做库存决策，可能严重超买或断供。

还有数据泄漏的风险。Anton在构造特征时用了全局的均值填充缺失值，如果测试集的信息通过这个均值泄露进训练集，评估结果就不可靠。这需要人工检查才能发现。

看板部分，它生成了matplotlib图表，保存为HTML。Sarah确实能打开，但交互性几乎为零，没法下钻到具体零件号，也没法调整时间窗口。比起Tableau或Power BI的原生看板，这只是个静态快照。

我的判断：这是"草稿生成器"，不是"工作替代者"

Anton的真正价值，在于把"从零到能跑"的时间从一周压缩到十分钟。它适合快速验证想法、应付紧急需求、或者给非技术同事一个可讨论的起点。

但它不解决"做好"的问题。特征工程的业务理解、模型选择的合理性检验、误差估计的严谨性、结果的可解释性——这些仍需人类判断。Anton生成的代码是草稿，不是终稿。

对于Sarah的周五需求， realistic的做法是：用Anton十分钟出个初版，然后花半天人工检查关键假设，跟业务确认特征逻辑，再花一天加固验证流程。总时间从一周缩到两天，质量可控。

完全放手让Anton端到端执行？目前看，风险收益比不划算。它省掉的是重复编码时间，不是思考时间。

技术实现上的取舍

Anton的架构有几个值得注意的设计。本地运行意味着数据不出境，这对采购订单这类敏感数据很关键。沙箱隔离防止代码搞坏主机环境。Scratchpad的透明性比很多闭源工具强——你能看到它到底做了什么，而不是只能信任一个黑箱输出。

但它也有明显边界。大语言模型的规划能力受限于训练数据，遇到冷门的数据库schema或特殊的业务逻辑，它可能规划出看似合理实则行不通的步骤。这时候需要人工介入调整。

工具链的依赖也是个隐患。Anton调用了pandas、scikit-learn、xgboost等库，版本兼容性它自己处理，但如果你的环境有特殊要求，可能需要手动覆盖。开源的好处是能改，坏处是也得不维护。

对从业者意味着什么

需求预测这个活儿，长期以来被夹在两个极端之间：Excel拖公式的业务人员，和写PyTorch的算法工程师。中间地带的"会写SQL、懂点统计、能搭看板"的分析师，活最多，工具却最原始。

Anton这类工具的出现，不是在替代分析师，而是在重新定义分工。重复性的数据提取、格式转换、基础建模代码，逐渐交给智能体；人类的精力释放到问题定义、假设检验、结果沟通上。

这对25-40岁的科技从业者是个信号：纯技术执行力的溢价在下降，"理解业务+能判断机器输出质量"的组合在上升。Anton能写XGBoost代码，但它不知道F-35零件的供应风险该怎么量化——这个知识缺口就是你的位置。

数据收束

Anton的GitHub仓库显示，项目发布两周内获得3400星标，Issue区有47个功能请求和23个bug报告。核心贡献者3人，主要提交集中在数据连接器和沙箱稳定性上。对比同类工具如LangChain的52k星标，它处于极早期阶段，但"本地运行+透明代码"的差异化定位已经吸引了一批企业数据团队的试用反馈。

预测市场的规模数据：Gartner估计2024年供应链预测软件支出约19亿美元，年增长率11%。其中"增强型预测"（即AI辅助的人类决策）占比从2021年的15%升至2024年的34%。Anton瞄准的正是这个缝隙——比全自动预测工具便宜，比传统BI工具智能。

但用户留存的关键指标尚不明确。项目文档没有披露月活或次日留存，Issue区的反馈以功能请求为主，缺少深度使用后的质量评估。这意味着"两分钟出预测"的故事已经讲通，"预测准不准"的答案还在风中。