aioff.
EN
产品设计
产品设计·7 分钟

Querri：把反复问的数据问题，变成可核对的业务口径

Querri 是面向运营和分析团队的 AI 数据分析工具。它能整理文件与连接的数据，把常用计算保存成可复用的表，帮助团队用同一套定义回答业务问题。

先尝试拆解问题、设计和实现，再展开思路，检查状态、边界与取舍，并设计验证用例。思路提供分析路径，不给出完整实现。

01
代码思考进阶

让派生表按同一代发布

设计一个简化的派生表调度器，这是从文章机制出发的工程练习，不代表 Querri 内部实现。源表 S 生成匹配表 A，A 再生成汇总表 B。一次同步称为一代，用递增整数 g 标识；同一代的 A 和 B 必须使用该代 S 的数据。

初始 g=1 已完整发布。随后收到 g=2 和 g=3；工作任务可能重复回报、乱序完成或失败。

  1. 定义输入事件、任务状态和对外可见的发布状态。读者只能看到完整同代的 A、B；旧代任务晚到不得覆盖新代。
  2. 推演：A2 成功、B2 启动；A3 与 B3 成功；最后 B2 成功。说明每一步能否发布及读者看到哪一代。
  3. 说明 S 同步失败、A 失败、重复完成事件、空表成功和进程重启时的处理。空表是有效结果，不能和失败混淆。
  4. 交付状态转换图、关键不变量和可执行的测试清单，不需要完整代码。
查看思路

  1. 先区分“计算完成”与“可供读者读取”。每个任务至少绑定视图、代号和输入版本；A3 只能依赖 S3，B3 只能依赖 A3。某代完整之前，读者继续看到上一个完整发布代，并能知道它的时间。

  2. 对题给顺序，A2 成功不能单独切换整组；g=3 的 A、B 都成功后才可能发布 3；晚到的 B2 不得把当前代从 3 改回 2。若 2 先完整而 3 尚未完整，可以先发布 2，随后再发布 3。规定发布代只增不减，并让整组可见版本一次切换。

  3. 重复完成事件用任务身份去重；重试须区别同一任务的不同尝试，失效尝试的晚回报不能改变当前尝试。源同步失败不启动后续链；A 失败不启动 B。空输入成功应得到合法空表；它与失败没有同一含义。

  4. 为重启保留任务结果与已发布代，恢复时对账后再调度。让测试分别在“结果已写但发布指针未改”和“指针已改但回执未发”处中断，验证重放不会降代或重复发布。讨论整组等待带来的延迟与一致性的取舍；这里选择严格同代读取，是题目约束而非厂商承诺。

02
界面实现进阶

批准前守住预览版本

你在做一个规则确认面板。用户编辑“已付款金额”的定义，服务返回预览，包括请求编号、规则版本、排除记录和汇总值。预览 A 的请求先发出，用户修改定义后发出 B；网络却可能先返回 B，再返回 A。

  1. 设计 editing、loading、ready、error 和 submitting 状态，解释每个状态能否批准。
  2. 用“B 返回 140 元、A 随后返回 160 元”的序列说明屏幕和批准请求必须携带哪一版规则；编辑或关闭面板后返回的请求如何处理？
  3. 批准请求也携带版本，服务若发现版本过期应拒绝。设计冲突、失败重试与键盘焦点恢复的表现。
  4. 交付状态图、用户可见文案和交互测试清单；不需要实现代码，也不要把这个面板当成 Querri 的现有界面。
查看思路

  1. 先把编辑草稿、最后一次有效预览和已批准结果当成三个不同对象。发出预览时保存请求身份与规则版本；只接收仍对应当前编辑版本的最新请求。B 生效后，A 晚到不能覆盖 140 元；再次编辑时，即使旧预览仍可显示作参考，也必须明确标旧并禁用批准。

  2. 点击批准时冻结当前有效版本并进入 submitting，避免重复点击。请求携带规则版本和预览身份；前端拦截不能代替服务端版本检查。服务拒绝过期版本后，保留草稿、说明原因、重新取得预览，再让用户确认，不能自动批准新内容。

  3. 测试加载中编辑、关闭后返回、网络失败重试、重复点击和冲突回包。关闭后不应更新卸载的面板；取消请求可以减少工作，但正确性仍靠身份检查。错误说明要能被辅助技术读到，关闭后焦点回到打开面板的控件；验证时用键盘走完一次成功与冲突路径。