机器人工厂收到了三次螺栓

一句话总结

FDE 的第一项交付物不是快速写出的脚本，而是一份把客户的话转化为可验证业务规则的契约。

为什么需要这些知识

一家虚构的机器人工厂联系了我们：“重新上传订单文件后，仓库里出现了相同的预留。我只是以为失败了，又点了一次。”客户要求消除重复。但究竟什么算重复？是文件中的同一行、同一个事件，还是同一份订单？订单编号相同但数量变化时，属于修改还是错误输入？如果不回答这些问题就开始写代码，只会快速造出错误的自动化。

在本课程中，你将扮演与客户共同交付一个小型集成项目的工程师。课程假定你能够阅读 Python 函数、字典、CSV 和 HTTP 请求。如果这些内容还不熟悉，请先完成前面的 FDE 数据与 API 实操。这不是对真实物流事故的复现，而是使用合成数据和虚拟仓库制作的教学场景，不涉及真实发货、支付或库存移动。

它是如何运作的

先把客户简报拆成三个问题：自动化可以修改什么？哪些信息可以发送？判断不明确时由谁决定？本次范围止于仓库预留。发出配送指令，或由工程师从数量冲突中擅自选择一个值，都超出范围。原始数据中虽然有电子邮箱地址，但预留业务并不需要，因此不会发送。

每行的 event_id 是传递事件编号，order_id 是业务订单编号。同一订单通过不同事件再次到达，并不会变成一笔新采购。反过来，如果仅因 SKU 相同就合并不同订单，就会丢失正常订单。因此，本次与客户约定的重复判定标准是 order_id 及该订单的内容。这并不意味着它是适用于所有公司的万能键。需要拆分发货或修改订单的公司，必须先就版本号和发货编号建立契约。

交付的 CSV 有七行数据。把表头计为第 1 行时，分类如下。

数据行	观察结果	处理方式
2·3·4	三份彼此不同的正常订单	分别作为发送候选
5	与第 4 行的订单、SKU 和数量相同，但事件不同	记录为重复传递
6	数量为 two	因数据不良而暂缓
7·8	同一订单的数量分别为 1 和 3	两行都因冲突而暂缓

结果是 3 个候选项、1 行重复传递和 3 行暂缓项。不能把七行数据发送七次。“消除了重复，所以丢弃了三行”也是错误说法。暂缓不是删除，而是等待人工判断的状态，必须保留行号和原因。

如果逐行读取后立即发送，就会在发送第 7 行后才发现第 8 行的冲突。已经建立的预留无法通过简单地从 CSV 中删掉一行来撤销。因此，必须先验证整个文件，收集同一订单的全部行并完成判断，然后再发送。只要某个有效订单编号下存在一行不良数据，就要暂缓整份订单。错误订单编号不会原样复制到报告中，而是以 null 表示，并通过行号定位。

数量只接受 CSV 中的字符 1～5。把 02 或 2.0 自动改成数字 2 看似方便，但这是客户没有授权的输入修正。最多 100 行、256KiB 也是本练习的输入契约。如果要处理更大规模的业务，就必须重新设计流式验证、批次边界以及重复记录的保留期限等事项。

可以发送的行与应该发送的订单

再设想一行数据作为练习：ORD-EXTRA 订购两个 ROBOT-BOLT，另一个 ORD-SECOND 也订购同样的两个螺栓。只比较 SKU 和数量时，两行看起来相同，但业务订单共有两份，所以都属于候选项。反之，如果只是 ORD-EXTRA 的事件换了新编号再次到达，就不应增加候选项。把这两个例子并列写下，能帮助团队确认“去重”一词背后隐藏的不同含义。

另一个错误是静默跳过无效行。如果客户预期的订单没有出现，执行结束后可能会再次上传文件，届时连已正常处理的订单也会重复执行。在暂缓清单中留下行号和简短原因，并非给错误报告作装饰，而是决定下一步业务行动的信息。无需把暂缓行的完整原文写入日志。保留原始文件，报告只需指明应检查的位置。

实现之前，先写出三句话：“同一订单的相同内容只预留一次。”“出现冲突或不良数据时，不发送整份订单。”“记录暂缓原因，但不传递不必要的客户信息。”这三句话可分别转化为检查候选清单、暂缓清单和实际请求的测试。如果客户不同意这些表述，应先修改契约，而不是调整代码实现细节。

在实际工作中会是什么样

2026-09-11 查阅的 OpenAI FDSWE 职位说明涵盖理解客户需求、迭代实现，以及界定 PoC 和生产部署的工作范围。Palantir FDSE 职位说明描述了从模糊问题出发，推进设计、原型开发和数据集成的工作。本课程把其中一部分工作转化为小型实操。它不是招聘考试，也不保证通过招聘；这两份说明只是美国特定岗位的案例，不能代表整个韩国招聘市场。

接下来要确认什么

下一次测验将区分发送前必须约定的边界和暂缓标准。实现前，请尝试用一句话说明“什么结果能让客户确认处理正确”。在本练习中，标准是只有未被暂缓的订单各自形成且仅形成一条预留，其余订单都连同原因保留下来。