draft-interview-intro-answers

name	draft-interview-intro-answers
description	读取指定公司岗位的常见问题文档、岗位分析与经历匹配文档，以及项目根目录的共享事实库，以岗位分析确定回答方向、以共享事实库约束个人事实，逐题撰写面试回答，并生成两分钟中文和一分钟英文自我介绍，最终输出经过渲染和视觉检查的 DOCX 文档。用于用户要求准备自我介绍、回答面经问题、生成岗位定制回答、制作面试话术文档或执行“自我介绍和回答”任务时。

自我介绍和回答

目标

将岗位分析、常见问题和个人事实整合成可以直接开口表达的面试材料。回答要岗位定制、事实可信、口语自然，并明确区分“可直接说的答案”和“仅供准备的依据或提示”。

输入与优先级

1. 确定目标岗位

1. 从主控命令中取得公司文件夹、岗位名称，以及用户指定的文件名、版本、风格或输出名称。
2. 如果公司文件夹或岗位无法唯一确定，停止并向用户确认，不根据相似名称猜测。
3. 将项目根目录视为包含共享事实库和公司文件夹的目录。

2. 定位三类必需输入

按以下顺序定位文件：

1. 岗位分析文档：优先读取用户点名文件，其次读取公司文件夹中的 岗位分析与经历匹配.md，再查找名称包含“岗位分析”或“经历匹配”的 DOCX、Markdown 或文本文件。
2. 常见问题文档：优先读取用户点名文件，其次读取公司文件夹中的 常见问题与面经汇总.md，再查找名称包含“常见问题”“问题清单”或“面经汇总”的 DOCX、Markdown 或文本文件。
3. 共享事实库：优先读取用户点名文件；否则查找项目根目录的 共享事实库.md 或 共享事实库.docx。

如果任一必需输入缺失，停止生成并明确指出缺少哪个文件。建议先运行对应的岗位分析或面经搜寻 skill，不使用其他相似材料静默代替。

如果同类文件有多个版本且内容可能不同，优先服从主控命令；仍无法判断时向用户确认。

3. 完整读取并建立依据表

1. 完整读取三类输入，不根据文件摘要或局部页面直接写作。
2. 需要读取 DOCX 时，调用文档能力并遵循其完整读取要求。
3. 建立内部依据表，至少包含：问题、岗位考察点、建议经历、事实库证据、可用数字、证据缺口。
4. 不需要重新联网研究；只有用户明确要求更新外部信息，或输入文档存在必须核验的时效性事实时才联网。

事实与定位规则

严格应用以下优先级：

1. 共享事实库是个人事实的最高依据：个人经历、身份、角色、行动、工具、数字、结果、奖项和时间必须能在事实库中找到支持。
2. 岗位分析文档决定方向：用它判断核心能力、主卖点、经历优先级和岗位语言，但不得让其覆盖或修改事实库。
3. 常见问题文档决定范围和优先级：回答其中的全部问题组，并保留其考察点、直接相关度和可信度排序。

遇到冲突时：

• 个人事实与共享事实库不一致时，以共享事实库为准并列入“待确认事项”。
• 岗位分析建议使用事实库没有的经历或数字时，不采用该内容，并明确标注证据缺口。
• 公司或岗位信息冲突时，不自行选择有利版本；在文档中标注冲突并使用不会造成错误的谨慎表述。

严禁创造、补全、合理化或夸大个人事实。不得把“参与”改成“主导”，不得虚构数字、工具、客户、职责、奖项或结果。

撰写自我介绍

1. 两分钟中文版本

围绕岗位分析文档确定的 2–3 个核心卖点组织：

1. 简短身份与应聘岗位；
2. 与岗位最相关的经历和能力证据；
3. 关键行动或量化结果；
4. 为什么这些经历能支持目标岗位；
5. 简洁的岗位动机和收束。

以约 400–500 个汉字作为初始长度参考，最终必须按自然面试语速朗读校准到约两分钟。不要堆砌全部经历、形容词或 JD 关键词。

2. 一分钟英文版本

根据同一定位重新组织英文表达，不逐句直译中文版本。使用自然、清晰、适合口头表达的英语，保留相同的个人事实和核心卖点。

以约 120–150 个英文单词作为初始长度参考，最终必须朗读校准到约一分钟。避免复杂长句、罕见词和难以稳定发音的表达。

3. 自我介绍检查

• 开头直接，不写空泛寒暄。
• 每个卖点至少有一项事实或结果支撑。
• 核心卖点与岗位分析的优先级一致。
• 中文和英文事实完全一致，但允许结构和措辞不同。
• 文本能自然说出口，不像书面报告或 JD 复述。

回答常见问题

1. 覆盖与排序

1. 按常见问题文档的可信度和直接相关度顺序处理全部问题组。
2. 若原文已将不同问法合并为同一考察点，保留为一个回答单元，并列出代表性问法，不重复写相同答案。
3. 按考察主题分组，例如岗位动机、公司与业务理解、经历深挖、专业能力、行为问题、压力问题和反问环节。
4. 不因篇幅较长而遗漏低优先级问题；可以缩短回答，但必须有明确处理结果。

2. 回答结构

每个问题组包含：

1. 代表性问法：列出同一考察点下的主要变体。
2. 考察意图：说明面试官希望验证什么。
3. 建议回答：给出可以直接口述的完整答案。
4. 事实依据/使用经历：注明答案依赖的事实库经历和关键数字；此部分仅供准备，不作为口述内容。
5. 可能追问与准备点：仅列高概率且能帮助准备的追问，保持简洁。
6. 风险或待补充：指出容易夸大、证据不足或需要用户补充的信息。

3. 选择表达结构

• 行为与经历题：优先使用精简的 STAR 或“结论—情境—行动—结果—复盘”结构。
• 动机与匹配题：使用“明确结论—岗位理解—个人证据—未来贡献”结构。
• 公司与业务题：以岗位分析中的已核验信息为范围，连接岗位职责，不背诵公司介绍。
• 优缺点、失败、冲突等反思题：给出真实具体的情境、改进动作和结果，不使用伪装成缺点的优点。
• 开放题或案例题：说明思考框架、关键假设和执行步骤；没有实际数据时不得编造结论。

4. 口语质量

• 先回答问题，再提供证据，避免长篇铺垫。
• 使用第一人称、短句和自然连接词。
• 一般问题控制在约 45–90 秒；重点经历深挖可适当更长，但避免把所有细节塞进首轮回答。
• 同一经历用于多个问题时改变切入角度，并避免大段重复措辞。
• 将岗位关键词转化为具体行动和结果，不机械复述 JD。
• 不使用无法自证的宏大表述、行业黑话或过度包装。

5. 证据不足的处理

如果共享事实库不足以支撑某个问题：

1. 能用已有事实谨慎回答时，使用最接近且不夸大的证据，并说明匹配边界。
2. 必须依赖缺失个人信息时，不编造完整答案；在建议回答处写出安全的回答框架，并用 [待补充：具体信息] 标记。
3. 将所有待补充项集中列入文档末尾，便于用户一次性完善。

生成 DOCX

1. 最终文件必须为 DOCX，并保存在目标公司文件夹。
2. 默认文件名为 自我介绍和回答.docx。若同名文件已存在且用户没有明确要求覆盖，先询问是更新还是另存，不得静默覆盖。
3. 调用可用的文档创建能力，并完整遵循其新建文档流程：
   • 加载工作区提供的文档依赖环境；
   • 阅读其新建/编辑、设计预设和渲染验证指引；
   • 为高密度面试准备手册选择合适的紧凑参考型设计；
   • 使用真正的标题、列表和一致的段落样式，不用伪造项目符号；
   • 避免用宽表格承载长篇回答，优先使用标题、标签段落和简洁提示框；
   • 将 DOCX 渲染为逐页图片；
   • 以 100% 缩放检查每一页，并修复截断、重叠、乱码、断页、拥挤或大面积空白；
   • 每次影响布局的修改后重新渲染，直到所有页面通过视觉检查。
4. QA 生成的图片、PDF 和临时文件只用于内部检查，不放入公司岗位文件夹，不作为最终交付物。

文档结构

按以下顺序组织最终 DOCX：

1. 标题与岗位信息：公司、岗位、生成日期、使用的输入文件。
2. 面试定位摘要：核心能力、主卖点、回答策略和主要风险，保持一页内可快速浏览。
3. 两分钟中文自我介绍。
4. 一分钟英文自我介绍。
5. 常见问题与建议回答：按优先级和主题组织所有问题组。
6. 待补充与待确认事项：集中列出缺失事实、输入冲突和需要用户确认的信息。

不要把外部网页来源或内部工具信息混入可口述答案。需要保留依据时，放在对应的“事实依据/使用经历”部分。

完成前检查

• 确认三类必需输入均已完整读取。
• 确认岗位分析只影响定位，个人事实全部受共享事实库约束。
• 确认常见问题文档中的每个问题组都有对应处理结果。
• 确认重复问法已合并，没有复制重复答案。
• 确认中文自我介绍朗读约两分钟，英文版本朗读约一分钟。
• 确认中英文版本与所有回答中的个人事实一致。
• 确认所有数字、角色、行动和结果均可追溯到共享事实库。
• 确认证据不足处使用待补充标记，没有虚构内容。
• 确认 DOCX 位于目标公司文件夹，文件名正确且可以打开。
• 确认最终版本已渲染，并逐页完成视觉检查。