OPPO产品面试

1.【自我介绍】同学你好，请先介绍一下自己吧。

回答：我从教育背景、实习经历、项目经历和自我评价四个部分向面试官进行介绍。

项目一：xx平台AI买点数字化系统

2.【项目介绍】可以介绍一下你在xx平台的xx产品项目中的工作内容吗？

回答：可以。我从背景、目标、动作和结果四部分来回答。

背景：产品经理为页面、功能或活动写买点方案时，往往需要先理解产品方案，再根据页面结构提炼卖点、确定展示点位并形成文档。这个过程重复度高，但不同页面的内容、布局和重点又不完全相同，直接把页面和需求交给通用对话工具，常会出现买点遗漏、格式不统一、同类页面产出风格差异很大的问题。一份方案如果漏掉关键买点，后续设计、研发和评审都要返工，周期可能被拉长到xx周左右。团队希望把这类经验沉淀下来，让更多产品经理不必每次从零写起。

目标：项目面向内部产品经理，目标是把买点方案的生成和复用做成一套可稳定使用的云端能力。对个人而言，希望减少重复撰写和反复对齐；对团队而言，希望让经过验证的方案、模板和表达规范能被授权复用。我们重点看生成结果是否覆盖关键买点、格式是否符合规范、是否仍需大幅人工修改，以及从输入页面信息到获得可用方案的整体效率。

动作：

动作一：先验证最轻量方案的边界。项目早期我们直接用对话式工具，根据页面截图或页面信息生成买点方案。试用后发现，换一个页面，输出的风格和点位就容易漂移；即使输入类似页面，结果也不够稳定。这一步让我们确认问题不只是“让模型写一段话”，而是需要给模型更明确的输入结构、模板约束和复用机制。

动作二：把共性流程沉淀成标准模板。我参与梳理产品经理写买点时共同需要的信息，例如页面类型、功能目标、目标用户、核心能力、展示区域和表达规范，并把这些内容收束成标准化输入和买点框架。差异很大的页面仍允许补充说明，但高频共性步骤不再靠每个人临场组织，减少了遗漏和格式不一致。

动作三：用Skill承接方案生成与复用。在标准页面上验证可用后，我们将买点方案和规范沉淀到Skill中，让系统按统一流程读取输入、生成结构化方案，再把可复用的成果上传云端。这样新使用者不需要重新搭一套提示词或从头写文档，可以基于已有模板和相近方案继续完成自己的工作。

动作四：补齐权限与审核机制。买点方案会被不同业务线复用，因此云端能力增加了员工权限、方案申请和作者审核。使用者根据需求检索对应方案，作者或维护方确认后再授权使用。这个机制既避免没有边界地复制旧方案，也让有效经验能够在组织内沉淀，而不是只留在个人电脑里。

结果：项目以云端能力形式上线到内部Agent平台，产品经理可以在买点功能区按需提取方案和模板。材料中给出的整体效率结果是提效约xx倍；更关键的是，原来分散在个人经验和文档里的买点规则被收拢成可复用资产，后续可以继续通过页面样本和使用反馈完善覆盖范围。

3.【项目细节】为什么直接用提示词生成买点方案效果不稳定？

回答：因为买点方案同时受页面结构、业务重点和表达规范影响，单次对话难以持续携带这些约束。

【页面之间存在真实差异】不同页面的功能、信息层级和展示区域不同，即使两个页面看起来相似，应该突出的位置和卖点也可能不同。只给页面信息让模型自由生成，容易得到格式相近、内容却不适配的方案。

【上下文越长越容易漂移】为了让提示词覆盖历史案例、规范和页面细节，输入会变得很长。模型可能抓住部分要求，却遗漏另一些限制，最终出现重点不全、描述风格变化或字段缺失。

【重复场景缺少可复用入口】单次提示词能帮一个人完成一次工作，但下一位产品经理还要重新组织输入、重新调试。将共性步骤和标准模板沉淀下来，才能让稳定性从个人经验变成团队能力。

4.【项目细节】那如何保证不同产品经理使用后，生成方案仍然稳定可用？

回答：稳定性来自输入规范、过程约束和结果回收三层控制。

【输入先明确边界】系统会收集页面类型、功能目标、核心能力和展示区域等必要信息，缺少关键信息时先补齐。输入质量不够，后面的模型能力再强也很难保证产出可靠。

【生成过程遵循统一模板】买点的标题层级、字段和表达框架由模板约束，模型在固定范围内组织内容。这样能降低不同页面、不同使用者带来的输出风格漂移，也便于后续比较和维护。

【用审核和反馈持续收敛】方案上传云端后，通过权限申请和作者审核控制复用范围。对于被频繁修改、被退回或无法适配的页面，回看是输入缺失、模板不全还是页面类型超出边界，再更新规范和样本，而不是只靠一次生成结果判断系统好坏。

项目二：xx平台新闻生产Agent

5.【项目介绍】可以介绍一下你在xx平台新闻生产Agent项目中的工作内容吗？

回答：可以。我会从业务问题、项目目标、具体动作和结果四部分来讲。

背景：xx产品的内容生产覆盖选题、资料整理、结构搭建、写作、质检和发布。跟访编辑后我们发现，耗时主要集中在补背景、拼结构和调整标题、导语、摘要。单篇解释科普稿从选题确定到发布通常要xx分钟，其中结构化拆解和初稿组织占xx分钟。遇到地震等突发事件，内容很容易错过第一波发布窗口。

目标：团队希望让热点稿件在xx分钟左右完成可发布初稿，同时守住内容准确性和可控性。衡量效果时，同时看初稿可用率、编辑改稿率和单篇平均时长，确保编辑能够直接接手、小幅修改后发布。

动作：

动作一：先还原编辑的真实耗时。我和mentor按编辑工作流做影子跟访，分别记录选题、检索背景、搭结构、写作和质检耗时。资料整理和结构组织最适合优先改造；直接追求“一键出全文”常导致编辑推倒重来，反而拖慢发布。

动作二：按稿件结构拆开生成。我们把初稿生产设计成分阶段流程：先基于选题形成信息底座，再分别生成标题、导语、正文摘要和结构化正文草稿。编辑拿到的是可分别选择、替换和修改的稿件组件，既贴合原有工作习惯，也便于定位具体问题，减少整篇重写。

动作三：把编辑控制权留在关键节点。产品侧支持编辑一次提交选题后，集中查看多个标题和正文方案，再做局部取舍与润色。对于事实不充分、表达风险高的内容，仍要求编辑人工确认后再发布。这里的取舍很明确：速度必须服务于热点响应，不能以牺牲内容安全为代价。

动作四：补齐图文混排的后半段。找图、判断相关性和安排图文位置同样耗时。我们把配图做成独立链路，依次完成候选图片提取、相关性判断、去重和图文混排建议，让编辑在同一流程内完成内容成稿。

结果：项目先在解释科普类稿件中落地，服务对应新闻编辑。初稿可用率达到xx%以上，单篇平均时长从xx分钟缩短到xx分钟，已能覆盖多数热点内容的时效要求。我的收获是，内容生产类AI产品的价值要放在编辑工作节奏中判断。

6.【项目细节】为什么你们把热点稿件的目标时间定在xx分钟左右，而不是继续压到更短？

回答：这个时间是业务时效、内容质量和建设成本之间平衡出来的，不是单纯追求越快越好。

【先看窗口期是否还能承接用户需求】突发事件里，用户需要尽快获得可信、清楚的解释。xx分钟的人工链路偏慢，xx分钟以内可赶上大部分热点的第一波需求。地震会更紧，政策解读可稍宽一些；xx分钟是MVP阶段兼顾覆盖面和可实现性的基线。

【再看编辑是否还有足够校验空间】继续压缩时间，往往意味着更少的事实核查和人工校对，内容风险会上升。Agent承担结构化准备和初稿生成，编辑仍完成必要判断，这样的效率提升才可持续。

【也要考虑系统投入是否匹配收益】把响应从xx分钟继续压到xx分钟，需要更高频的信息更新、更复杂的调度和更高的人机协同成本。对解释科普稿件而言，业务收益未必能覆盖这部分投入。所以项目先把可用率和平均时长做稳，再根据不同热点类型决定是否需要做更细的时效分层。

开放题目

7.【业务理解】你怎么看AI内容生产中“效率”和“内容安全”的关系？

回答：我认为两者不是对立关系，但内容安全一定是效率设计的边界。

【先定义AI应该替代什么】在新闻场景里，AI比较适合承担资料整理、结构草拟、标题候选和配图筛选等重复工作。这些动作耗时高、规则相对清楚，交给系统后可以显著缩短编辑的准备时间。

【把事实判断和发布责任留在人工侧】热点内容的事实准确性、表述分寸和最终发布判断，仍需要编辑把关。尤其在信息未充分确认、事件敏感或可能引发误解的场景，产品应当主动提醒、限制自动发布，而不是鼓励模型用看似完整的表达填补未知信息。

【用人机协作而非全自动来衡量成败】好的内容生产工具应该让编辑把精力从机械劳动转向专业判断。项目里我们用可编辑的分阶段结果和人工确认节点来保证这一点。对业务而言，真正有价值的是既赶上窗口期，又持续交付可信内容，而不是单次把生成速度做到极限。

8.【业务理解】你认为手机厂商做AI，相比用户直接打开一个通用AI应用，最值得发挥的优势是什么？

回答：我认为手机厂商最值得发挥的优势，是在用户正在做事的位置理解需求，并把服务接到下一步操作里。

【缩短从需求到使用的路径】通用应用往往需要用户主动打开、复制材料、重新说明背景。我会优先寻找阅读、相册、日程等已有场景，让用户通过选中文本或主动唤起获得帮助，减少切换，也避免为了展示AI增加新的操作负担。

【把理解延伸到任务完成】例如用户读到活动信息后，希望继续保存时间、设置提醒。我会先确认必要信息，再提供可预览、可修改的操作建议；涉及写入或发送时让用户确认，不默认跨应用就一定能执行成功。

【让系统能力建立在信任上】我会和研发确认授权范围、端云分工及耗电约束，只读取当前任务必要的信息。判断价值时，我更关注用户是否少走步骤、能否完成任务，以及误触发和打扰是否可控、用户是否愿意再用。

9.【自我评价】从互联网产品转向手机产品，你认为你有哪些经验可以迁移？

回答：我能迁移的是拆解用户任务、约束AI输出和推动协作的能力，同时也清楚手机产品有需要重新学习的部分。

【先把真实问题找准】在买点方案和内容生产项目里，我都需要看使用者具体卡在哪一步，再决定改造范围。这种方法可以用于手机场景，但我会重新观察普通用户的使用环境，不能把内部员工愿意学习工具当成所有人的习惯。

【把生成结果做成可接手的产品】我参与过输入规范、模板约束和分阶段输出设计。迁移到手机端时，我会关注结果是否一眼能懂、能否局部修改，以及失败后能不能顺畅回到原操作，而不是直接搬用内部工作台。

【把协作方法带过去，把终端知识补起来】我可以整理问题样本、明确验收口径，和算法及研发讨论取舍；但端侧资源、系统权限、机型适配仍是短板。我会跟着实际需求理解限制，在联调和用户反馈中逐步补齐。

1.【自我介绍】同学你好，请先介绍一下自己吧。

回答：我从教育背景、实习经历、项目经历和自我评价四个部分向面试官进行介绍。

项目一：xx平台AI买点数字化系统

2.【项目细节】关于xx平台这个项目，你在这个项目里具体做了什么？

回答：我在项目里更偏前期问题梳理、模板设计、验证和联调推进，而不是单独完成底层模型能力。

【参与梳理产品经理的真实工作流】我会从一份买点方案怎样开始、哪些信息必须收集、哪里最容易反复修改入手，识别哪些步骤在不同产品和页面间具有共性，哪些仍要由使用者补充判断。

【参与标准化框架和页面试用】在直接对话生成结果不稳定后，我参与把常用买点整理成框架，并在若干标准页面上试用，观察内容覆盖、格式和页面适配问题。这里的产出是让需求能被工程侧理解和实现的结构化规则。

【和算法、后端一起定位输出问题】当方案出现内容格式不一致、字段缺失或页面适配差时，我会整理问题样本和复现条件，再和算法、后端同学沟通调整。上线后也关注复用时的权限和审核流程，确保系统不只是一份Demo。

3.【项目细节】你们如何划分提示词、Skill和Agent各自适合解决的问题？

回答：我会从任务复杂度、是否需要复用、以及是否需要多工具协同三个角度判断。

【提示词适合单次、低复杂度任务】如果只是根据明确输入生成一份初稿，且使用者愿意人工调整，提示词成本最低，适合快速验证想法。项目初期我们就先用它确认买点生成是否有价值。

【Skill适合固定流程的标准化复用】当输入、步骤和输出格式已经比较稳定时，Skill可以把页面信息整理、模板调用和方案生成封装成固定流程。对多数买点场景而言，这种方式能够降低使用门槛，也方便维护规范和案例。

【Agent用于需要统筹与回路的场景】如果流程要调多个工具、读取权限、检索云端案例，或在字段缺失和结果异常时回到前一步补充，Agent更适合承担统筹角色。架构选择不应追求复杂，能用轻量方案解决时优先用轻量方案，复杂能力要和业务价值匹配。

项目二：xx平台新闻生产Agent

4.【项目细节】关于xx平台的xx产品这个项目，目前市面上已有内容生成工具，为什么还要围绕编辑工作流做这套产品？

回答：核心差异不在于能不能生成一篇文章，而在于能不能把编辑从实际最耗时的环节里解放出来。

【通用工具不了解内部生产上下文】新闻编辑拿到选题后，还要处理已有素材、事实来源、栏目要求和表达规范。通用工具可以辅助写作，但难以自然接入信息底座、稿件结构和发布前校验。

【编辑卡在结构和背景，不只卡在写字】跟访发现，编辑耗时最多的是找背景、整理信息和组织结构。只让模型输出全文，一处不合适就可能带来大段修改；围绕真实流程拆开，AI才能替代最重复的工作。

【产品形态要服务编辑的接管方式】编辑需要一次看到多个标题、摘要和正文选择，再做局部调整。我们按组件交付生成结果，方便编辑比较和取舍，让AI成为可接管的生产助手。

5.【项目细节】为什么要采用分阶段的稿件生成，而不是一步直接生成全文？

回答：分阶段的价值主要体现在可控、可改和可定位三个方面。

【让每一步有明确输入输出】选题先沉淀为信息底座，再进入标题、导语、摘要和正文等模块，每个环节都能检查来源是否够、表达是否偏、结构是否完整。这样即使某一步效果不理想，也可以局部调整，不会把问题带到最终成稿里。

【降低编辑推倒重写的概率】一步生成全文时，只要标题风格、背景信息或正文逻辑有一项不符合要求，编辑往往需要大段重写。分阶段后，编辑可以保留可用部分，只替换不合适的标题或段落，更接近人工编辑原本“搭框架再填内容”的节奏。

【便于后续做类型化迭代】地震、政策、科普等选题的写作要求不同。分阶段链路建立后，后续可以把编辑对不同稿件的修改经验沉淀成相应规则或Skill，在结构、语气和核验要求上做差异化处理，而不用每次重新改一套全链路。

6.【项目细节】你怎么和研发对齐“生成效果好”这件事？

回答：我会把抽象的模型效果翻译成编辑可以感知、业务可以验证的结果。

【先统一用户是谁】这个产品的直接用户是编辑，所以“好”的第一层含义是编辑能否用、是否愿意用，而不是只看生成文本在技术指标上的表现。研发同学更关注模型输出是否通顺、稳定，产品侧还要把这种稳定落实到编辑的实际操作里。

【把讨论落到业务指标】我们用初稿可用率、编辑改稿率和单篇平均耗时来共同判断。初稿可用率高，说明输出已经能进入编辑的工作台；改稿率低，说明它不是表面通顺却需要大改；平均时长下降，才代表整个生产链路真的缩短了。

【用失败样本反推问题环节】如果编辑频繁改标题，就看标题模块的表达约束；如果事实补充多，就回到信息底座和资料来源；如果全文重写多，就检查结构化输出是否贴合栏目要求。这样研发和产品能围绕具体模块、优化动作和验证指标协作。

开放题目

7.【业务理解】你做过xx产品的新闻生产Agent项目，假设让你为OPPO手机设计一个AI阅读功能，帮助用户快速看懂一篇热点新闻，你会怎样去做经验迁移？

回答：我会把编辑生产稿件的经验，转成帮助普通用户理解信息的流程，先验证用户到底在哪个阅读环节需要帮助。

【围绕当前文章减少理解负担】我会从用户主动选中或分享的一篇文章切入，优先解决文章太长、背景陌生和观点难分的问题。首版提供事件概括、关键进展和必要背景，不急着扩展成信息流，也不默认读取用户其他内容。

【保留分阶段思路，调整交付方式】我会先提取人物、时间和事件，再组织摘要，并让关键结论能跳回原文。事实、作者观点和待确认信息分开展示；需要外部补充时注明来源与时间，资料不足就提示缺失，不把推测补成事实。

【验证理解效果和阅读体验】我会让用户完成相同的信息查找任务，比较有无辅助时的耗时与答题准确性，同时看摘要失真、原文回查及退出反馈。涉及热点变化时提醒文章时效，后续再结合反馈决定是否增加追问功能。

8.【职业规划】未来两到三年的规划是什么？你最希望深入哪类业务？

回答：未来两到三年，我希望在手机AI应用方向持续积累，成长为能独立负责一个场景、把需求推进到上线并持续迭代的产品经理。

【先补齐终端产品的基本功】入职初期，我会先熟悉用户、系统能力和团队协作方式，把需求澄清、方案设计、验收跟进做扎实。尤其要理解权限、时延、耗电和机型差异怎样影响体验，避免只从模型能做什么来提需求。

【优先深入信息理解与任务辅助】两段项目让我对内容理解、结构化表达和人机协作比较有兴趣。我希望从阅读理解或信息整理这类具体场景切入，观察用户从看到结果到采取行动的完整过程，但也会结合团队需求确定负责方向。

【用承担责任的范围检验成长】后续我希望能独立判断需求优先级，协调算法与研发处理体验问题，并对上线后的使用效果负责。我不会只以职级或接触多少新技术衡量进步，更看重能否把一个场景持续做深。