现场工程师听到的，通常先是一种解决方案
客户说“给这个界面加一个自动审核按钮”，并不一定意味着真正需要一个新按钮。背后可能是资料审核重复，也可能是审批规则没有整理，或者现有系统入口太分散。FDE 如果直接把这句话转交产品团队，双方很容易围绕界面讨论，却没有解决业务问题。
OpenAI 的公开 FDE 岗位说明把客户部署、实际工作流影响与评估驱动的产品反馈放在同一职责范围。本文据此分析现场需求如何形成产品输入，不把招聘说明当作全部行业的统一标准，也不宣称它代表某项已经发布的新功能。
对提供企业 AI 服务的团队，这种职责连接值得重视。现场发现的问题不应只消耗在临时处理里，但也不能把每一次客户要求都升级成产品承诺。需要一套轻量记录，让业务目标、现有能力和未来可能改动之间保持清楚关系。
先问工作为什么卡住，再记录客户希望怎么改
可以先还原一次具体任务：谁发起、用了什么资料、卡在哪一步、人工怎样补救、结果影响什么。记录这些事实后，再保留客户提出的功能建议。两者都重要，但应该分别写，避免把用户设想的实现方式当作唯一正确答案。
例如客户要求自动审核，实际困难可能是每位审核者判断标准不一致。如果直接加自动按钮，分歧只是被埋进系统；如果先整理规则与例外，现有工具也许已经能支持一部分工作。这里是方法示例，不代表任何真实客户项目。
现场记录还应说明发生条件。某个问题只在一个旧系统的特殊数据格式中出现，与多个团队都无法表达相同业务规则，所需处理方式可能不同。把条件写清楚，不是降低客户诉求的重要性，而是让后续判断有事实基础。
用三个问题区分临时调整与产品机会
第一，现有能力是否已经能完成任务，只是配置或使用方法不清楚？如果答案为是，应优先验证现有路径，并检查文档与引导是否需要改进。不要为了显得响应迅速，先创建一项其实不需要的新功能。
第二，这个需求是否高度依赖单个客户的内部规则？若依赖强，可能更适合作为项目内配置或独立集成处理。团队应说明维护责任和变化条件，避免把客户特例悄悄放进公共能力，随后让所有用户承担复杂性。
第三，是否存在多个场景中的相同缺口？这里要比较实际任务，而非统计相似的功能名称。不同客户都说“要自动化”，不代表需求相同；若都需要在提交前核对同类约束，才更有理由讨论可以复用的能力。
给产品团队的材料，应当可以独立复现
有用的反馈包不一定很长，但应包含脱敏输入、当前输出、预期行为和复现步骤，并说明差异怎样影响业务。涉及模型判断时，还需要保存相关版本和必要的运行条件，避免团队无法重现现场现象。
同时记录尝试过的替代方案。哪个配置可以绕开问题，代价是什么，哪些方式已经验证不可行。这样产品团队能比较“继续提供使用指导”“改进已有能力”和“新增能力”的成本，而不是只收到一个必须实现的结论。
反馈中也要保留不确定性。只有一次观察、数据尚不完整或业务口径尚未确认，都应直接注明。暂时无法证明是产品缺陷的问题，可以进入调查清单；不需要为了争取排期，把尚未核实的影响写成确定事实。
改进完成后，回到原场景关闭反馈
产品团队交付改进以后，现场问题还需要再核对一次。可以使用原先保存的脱敏样本与运行条件检查差异，并请实际使用者确认原任务是否已经顺畅完成。功能进入版本说明，不代表原来的业务障碍一定已经消失。
若问题只得到部分解决，应把剩余范围写清楚。原先影响多个条件，改进只覆盖其中一种，就不能把整条反馈统一标成完成。可以拆分已验证结果与待处理事项，让客户及产品团队都看得出下一步还有什么工作。
最后把结果反馈给提出需求的人，并更新临时绕行方案的状态。旧方案是否仍需保留、说明文档是否需要修改，都应有人负责确认。这种闭环能减少同一问题反复进入不同沟通渠道，也让现场团队知道提交的证据确实被用到了。
面向客户，把四种状态说清楚
已记录需求、正在评估、已经排期和正式承诺交付，是不同状态。FDE 在现场沟通时应使用团队认可的表述，并把承诺与相应负责人、范围和条件联系起来。一次产品讨论不应在客户会议纪要里变成确定上线时间。
如果短期无法解决，也应说明可用替代方案及其限制。让客户知道当前能怎样继续工作，比只说“已经反馈总部”更有帮助。替代方案需要实测，尚未验证时就写成拟验证路径，避免临时建议再次形成新的交付承诺。
一路凯歌建议，为现场需求保留从业务事实到处理决定的短链路。FDE 负责把问题带得足够清楚，产品团队负责做能力与资源判断，客户能够看见当前状态与下一步。这样现场经验才有机会积累成产品改进，而不是不断增长的口头待办。
要点总结
- 不应该直接这样处理。需要区分独有流程、可通过现有能力解决的问题，以及具有复用价值的共性缺口。
- 不代表。反馈、评估、排期和承诺属于不同状态，需要对客户明确说明。
- 能说明业务目标、现有做法、复现条件、影响范围和替代方案的反馈，比只有一句功能名称更容易讨论。
参考来源说明
本文为岗位与交付分析。来源时间：公开岗位页未显示发布日期；2026-10-22核对。官方资料用于核对文中对应事实，实践建议为本站分析；假设场景不代表真实客户案例或效果。