把任务拆成环节，再谈用了什么工具

有观点提到，工具调用本身可以分解为分类加动作；AI 程序可以被设计成在分类、结构化数据、确定性代码和小型代理式追加聊天循环之间切换的流水线。注意，这是一位开发者的设计建议，不是招聘方的统一标准，也不代表岗位都在按这个方式出题。它给面试表达的一点启发是：与其报一串框架名，不如先讲任务被拆成哪几类环节、每类为什么这样处理。

哪些环节交给确定性代码，哪些留小循环

判断起点不是“哪个更先进”，而是这一步需不需要稳定可复现。金额计算、权限校验、状态流转这类步骤，结果必须一致，交给确定性代码更合适；意图归类、字段抽取这类步骤，输入表达多样，可以先让模型分类或结构化，但输出要落到固定格式再交给代码。只有目标不明确、需要多轮澄清的任务，才值得开一个小循环。

假设场景：同一段“用户想改预约”的请求，一种做法是让模型直接决定调用哪个接口；另一种是先分类为“改期”，抽取新时间并校验格式，再由代码判断该时间是否可约，只有信息缺失时才追问。后者每一步失败点可见，也更容易写测试。要提醒的是，读岗位描述时，还要确认团队实际用的是哪类编排方式、有没有评测环节、失败后如何回退，这些都需要向面试官确认，而不是自行假定。

没有实际项目时，怎么展示流程判断

可以用模拟设计，但要明确标注是假设。比如：“假设做一个会议改期助手，我会先分类意图，再抽取时间字段，用代码校验可用性，只有信息不全时才进入追问循环。验证上，我会为分类准备一批边界表达，为结构化字段检查缺失和格式，为确定性代码写单元测试，再单独看追问轮数是否收敛。” 延伸阅读：技术面试通关秘籍：系统设计题如何应对？

不要编造上线效果或数字成果，用[实际记录]这类占位说明你会在真实项目中补上哪类证据。表达重点是自己为什么这样拆、哪一步最容易出错、打算怎么发现它出错。想练的话，挑一个日常任务，按环节写成一页流程草图，标出每步输入输出和验证方式，面试前讲一遍。