软件工程师模拟申请报告

基于Adobe的Senior Software Engineer, Meta Factory Agent Harness职位和公开简历生成的软件工程师模拟申请示例。查看职位匹配度、经历证据缺口、修改建议和面试问题。

查看点评示例

查看适合你职位的报告。

选择或搜索职位，查看相应的分析与面试问题。

领域

职位

软件工程师. 报告示例已更新。

按岗位浏览模拟申请示例

软件开发

云与基础设施

安全

安全工程师

IT支持

数据与AI

产品与项目管理

设计与品牌

营销与增长

内容与媒体

销售与客户支持

经营与战略

财务与会计

人力资源与培训

法务、合规与政策

制造与工程

运营、物流与供应链

环境与安全

建设、建筑与房地产

医疗、卫生与制药

教育与社会工作

酒店、餐饮与零售

维修与技术服务

Senior Software Engineer, Meta Factory Agent Harness · Adobe

节选自公开简历与实际职位的分析。申请问题保持未回答。

你的申请会如何被理解？

概括职位与简历中体现的优势和证据缺口。

Adobe Senior Software Engineer, Meta Factory Agent Harness

值得申请，先补核心证据

前 32-46%

总结

以下是您向 Adobe 的 Senior Software Engineer, Meta Factory Agent Harness 岗位提交的模拟申请分析。简历中最突出的优势是您在 CookApps (8Y) 对全公司业务系统的端到端负责，将人事与行政流程覆盖到12类业务，并整合了4种分散的可视化服务。更深入的审阅者希望看到一份基于现有数据分析助手的设计说明，明确您亲自做出的接口、失败恢复和权限决策，并附上可复核的测试结果。

评分、比较排名、面试官与招聘阶段属于AI分析和模拟，并非企业的实际评价或招聘结果。

判断现在是否准备好投递。

查看申请建议及提交前需要完善的内容。

前 32-46%

与相似申请者对比的基准

位于相似申请者、相邻岗位的被录用者、相似角色的在职者所构成基准范围的 前 32-46%，意味着你的履历具备争取初筛讨论的竞争力，但这不是 Adobe 的实际录用概率，也不保证通过 Senior Software Engineer, Meta Factory Agent Harness 的专门筛选。你在 CookApps (8Y) 交付全公司人事与数据平台、带领四名成员，并用 AWS Bedrock Tool Use 实现自然语言到 SQL、数据加工和图表呈现，这些比单纯使用 AI 编码工具更有说服力。申请前应优先补清 Harness Template 与实际运行时职责的边界，把可核实的工具调用设计和个人架构决策写到首屏，同时如实保留约 11.2 年经验，不将其改写成满足十二年以上要求。

依据

AWS Bedrock Tool Use 的完整数据分析链路，加上企业平台的长期交付责任，是你进入 前 32-46% 的主要支撑。这种组合同时提供 AI 实作和生产运营证据，比只有工具使用清单或短期演示项目更能支撑岗位相关性。

申请前要修改的内容

将简介中的 AWS Bedrock Tool Use 经历移到首屏，补充实际负责的调用链、接口决策和已验证结果，并明确尚未实现的运行时能力。

重写 사내 BI 시스템 的领导经历，区分四人团队管理、本人架构决策以及其他团队实际采用的成果。

更可能收到的招聘邮件

差一点通过

基于当前报告信号生成的真实下一步示例。

9:41

●●●●○

🔋

←

📥

⋮

Regarding your Senior Software Engineer, Meta Factory Agent Harness application

David Chen

david.chen@adobe.com

刚刚

Hi, Thank you for your interest in the Senior Software Engineer, Meta Factory Agent Harness role at Adobe. We appreciate the time you put into your application and the context you shared through your resume and answers. The strongest signal we saw was 您对全公司业务系统承担了从需求到运营的完整责任. At the same time, this search needs clearer evidence around 约11.2年的已记录经历尚未达到 12年以上要求, and that gap made it difficult to move forward for this specific opening. We have decided to continue with candidates whose recent experience more directly matches the current needs of the team. This is a role-specific decision, not a broader judgment on your overall potential. We appreciate your interest in Adobe and hope you will consider future roles that align more closely with your experience. Best, Adobe Recruiting Team

每个招聘阶段关注的证据不同。

查看各招聘阶段关注的优势与疑虑。

首屏有吸引力，核心证据待补

前三十秒里，Adobe AEM、AWS Bedrock Tool Use、长期平台交付和四人领导经历足以形成值得查看的技术履历。建议先把工程职责和 AI 实作移到首屏，再让招聘人员判断年限弹性，而不是靠增加 Harness 关键词掩盖责任边界。

“基于 AWS Bedrock Tool Use，将自然语言问题连接到 SQL 生成、数据加工和图表呈现。”

“这份简历有我愿意继续问的内容：长期负责内部平台，还做过 AWS Bedrock Tool Use 数据分析服务，也有 Adobe AEM 背景。我需要先确认约 11.2 年经验是否在团队可接受范围内，再请经理判断 Harness Template 到底覆盖了多少实际系统责任，不能只凭这个名称认定符合核心平台岗位。”

与相似申请者的对比基准

招聘人员初筛

结果不明

Adobe 的招聘人员初步沟通常核对履历匹配、工作地点和时间安排，你的长期任职与 Adobe AEM 背景有利于快速建立上下文。先统一日期、明确实际开发责任，并由你本人确认 San Jose 工作安排；现有资料不能替你回答这些问题。

招聘经理审阅

结果不明

招聘经理会把 사내 BI 시스템 的全公司覆盖和四人团队领导，与 Meta Factory 面向大量 Adobe 工程师的平台责任作比较。准备一项 BI 整合中的真实决策，说明业务价值、分歧处理和其他团队采用结果，才能让经理评估范围是否可迁移。

技术面试

可能止步

Adobe 常见技术面试包含编码、系统设计和项目深挖，但 Meta Factory 专属题目与轮次尚未确认。简历未提供这些机制的实现证据，若回答仅停留在 API 使用和流程串接，就难以支撑岗位对运行时设计深度的要求。

💭

招聘经理真正的想法

毫不避讳

我先看您是否真正负责过系统交付，再追问智能体底层的实现证据，最后决定这份申请是否值得推进。

😬

扫过履历

嗯，CookApps (8Y) 加上 Springworks (3Y)，已记录经历约11.2年，离要求的 12年以上还有差距。我招的是 Adobe 的 Senior Software Engineer, Meta Factory Agent Harness，得继续看技术深度，不能只看年限。

🚫

暂缓推进 — 已记录年限未达要求，智能体运行时、隔离执行及跨团队技术领导仍缺直接证据

我先把申请留在待澄清名单，请招聘人员核实年限和 San Jose 现场工作安排，并请您补充实际做过的执行机制、设计评审和工程师培养案例。我拿到这些证据后，再决定是否安排技术初筛。

不只看总分，也看每项依据。

查看报告14个评估维度中4项的评分与依据。

维度	分数	说明
招聘者可读性	85 总分	经历、技能和项目分区清楚，10秒降至1–2秒、12类业务及4人带领范围都容易被快速识别，项目部分也明确区分了职责与技术改进。面向这一岗位，最有价值的工具调用与 Harness Template 经历却分散在简介和技能部分，招聘人员需要自行拼接关联；建议在开头集中呈现相关项目、个人职责和可验证结果，同时压缩重复出现的人事系统与团队带领描述。
证据·可信度	76 总分	您的业务范围和性能基线较具体，包括约150名员工、12类流程、4种可视化服务及加载时间变化，也有明确的任职公司和项目名称作为核对入口。需要先统一 pokepoke.gg 的1300人口径：简介写最大同时在线，项目部分写单日最高访问，两者不能互换；此外，性能测试条件和活跃用户统计周期尚未说明，这些问题影响证据精度，但不足以推断成果存在夸大。
技术深度	73 总分	简历列出了 FastAPI BFF 与聚合查询优化、多数据存储、Next.js App Router 迁移、共享图表抽象和 ECS 部署等具体工程内容，技术深度已有可追问的入口。当前主要缺少方案取舍与失败边界：为什么采用这些结构、排除了什么方案、如何验证收益，以及异常情况下怎样保持正确性尚未展开；补充现有助手的一条完整调用链及错误处理设计，比继续增加技术名称更有助于技术面试判断。
职位匹配度	62 总分	您的 AWS Bedrock 工具调用实践、全公司业务系统建设和部署运维经历，与岗位的工具使用、平台交付及可靠性要求存在直接联系；Springworks (3Y) 的 Adobe AEM 项目也提供了产品接触背景。该职位明确聚焦智能体底层执行框架，现有材料尚未覆盖运行时、模型上下文协议、多智能体协调和隔离执行等主要职责，约11.2年的记录也低于12年以上要求，因此不能仅按通用软件工程技能判断为高度匹配。

区分加分依据与失分原因。

对比得分最高与最低项目的评估依据。

为什么会是这个分数

这里会一起说明拉高这个分数的因素，以及还没能进入更高梯队的原因。

最强优势

最弱环节

主导性·决策力

您在 사내 HR 시스템 和 사내 BI 시스템 中明确承担 PO 및 메인 개발자，并写明从需求定义到部署运营的单独负责范围，个人交付责任相当清楚。公共组件与交付流程建设也说明您不只完成页面功能，而是在维护可持续交付的基础；要进一步贴近目标岗位，应补充一项真实架构决定的备选方案、参与者与验收依据，让招聘经理看到您如何在安全、交付速度和维护成本之间作出选择。

+10 对比同类申请者

回答质量

保存回答区域为空，没有可评分的深度回答，因此没有额外证据解释工具调用设计、复杂技术取舍或跨团队推进过程，分数反映材料缺失而非实际表达能力。也没有文本足以触发模板化或人工智能代写判断，下一步应围绕 真实项目的决策与验证准备回答，用已发生的事实区分本人贡献、团队成果和仍未实现的能力；由于未提供题目，不能声称您跳过了某一道已知必答题。

+0 对比同类申请者

干系人·影响意识

简历明确说明 管理层、业务人员与子公司员工如何使用系统，工时成本分析服务于资源配置，BEP·Retention 模拟服务于游戏上线和目标设定，技术结果与受益对象之间的关系清楚。目标岗位的主要使用者转为 内部工程团队与平台合作方，因此下一步应解释共享图表组件、设计系统和开发流程如何影响其他开发者的工作；已有业务意识是优势，但工程师体验与接入成本仍需要独立证据。

+13 对比同类申请者

申请完整度

您提供了经历、教育、技能和项目主体，但 保存回答完全缺失，本次模拟申请缺少用来核验动机、技术决策和岗位理解的补充材料，因此按回答包大量缺失的档位暂定评分。由于题目列表同样未提供，不能把它解释为实际申请表已经漏填；正式投递前还需由您核实 San Jose 非远程安排、赴当地工作的条件及真实可入职时间，这些内容均不能从过往任职地点代为推断。

+5 对比同类申请者

招聘者可读性

经历、技能和项目分区清楚，10秒降至1–2秒、12类业务及4人带领范围都容易被快速识别，项目部分也明确区分了职责与技术改进。面向这一岗位，最有价值的 工具调用与 Harness Template 经历却分散在简介和技能部分，招聘人员需要自行拼接关联；建议在开头集中呈现相关项目、个人职责和可验证结果，同时压缩重复出现的人事系统与团队带领描述。

+12 对比同类申请者

职位匹配度

您的 AWS Bedrock 工具调用实践、全公司业务系统建设和部署运维经历，与岗位的工具使用、平台交付及可靠性要求存在直接联系；Springworks (3Y) 的 Adobe AEM 项目也提供了产品接触背景。该职位明确聚焦 智能体底层执行框架，现有材料尚未覆盖运行时、模型上下文协议、多智能体协调和隔离执行等主要职责，约11.2年的记录也低于12年以上要求，因此不能仅按通用软件工程技能判断为高度匹配。

+6 对比同类申请者

找到值得放在前面的经历。

找出简历与自我介绍中值得优先呈现的经历。

亮点

以下是从简历中提炼出的核心亮点，可作为自我介绍或面试时重点强调的优势参考。

端到端业务系统责任，为该岗位提供了 贯穿交付与运营的判断基础。

AWS Bedrock 工具调用经历，为执行框架工作提供了 真实应用侧验证入口。

把职位用语与自己的经历连接起来。

查看连接职位要求与你的经历的关键词。

主要 ATS 关键词匹配结果

这些是与岗位紧密相关的关键词。建议在面试或自我介绍中自然嵌入，突出重点。

软件工程

系统设计

故障排查

工具调用

保留已经有效的优势。

对照需要保留的优势与需要补充的弱点。

优势

您对全公司业务系统承担了 从需求到运营的完整责任。

数据分析助手提供了 真实工具调用交付证据。

待改进

约11.2年的已记录经历尚未达到 12年以上要求。

尚缺 智能体运行时与隔离执行的直接实现证据。

了解与相近申请的差异。

通过基准比较查看优势与证据缺口，并非真实申请者排名。

你的相对位置

与相似申请者相比，你的优势是把 AI 工具调用放进了真实企业服务，并同时承担部署、运营和业务结果。以相似申请者、相邻岗位的被录用者、相似角色的在职者构成的基准范围来看，你处于 前 32-46%，相对位置为高于基准范围的中间水平。最能推动位置上移的一项修改，是把真实的 AWS Bedrock Tool Use 经历展开为一段可追问的架构决策证据，同时明确 Harness Template 的实现边界。

你已经具备的

你已将 AWS Bedrock Tool Use 用于自然语言提问、SQL 生成、数据加工和图表呈现，提供了实际工具调用链证据。它与 Meta Factory 的工具使用方向相邻，但应保持应用层与核心运行时的职责区分。

🎯

最接近的成功画像

你长期负责 사내 HR 시스템 和 사내 BI 시스템，具备内部平台从需求到运营的完整经验。该责任链与成功画像中的生产所有权相近，而不是只有研究或演示。

🚀

更强申请者常见的信号

更强的可比申请会把 智能体运行时责任 写成明确的组件、边界和故障处理决策。你的 Harness Template 目前只说明输出一致性与流程化，尚不足以支撑同等深度。

🏆

相邻录用画像常见的信号

以岗位要求构建的成功画像应同时拥有 生产 AI 系统与核心执行机制 的证据，而非仅有模型调用经验。你的 AWS Bedrock Tool Use 可作为前一部分的起点，但这里并无已核实的 Adobe 被录用者个人履历。

📈

资历

展示这份申请目前在级别维度上大致被读成什么水平，以及在技术表达再打磨一点后最接近的下一个级别。

Junior

Mid

Senior

Staff

Principal

当前 · Senior

你在 사내 HR 시스템 中独立承担需求定义、设计、开发、部署和运营，覆盖约 150 名员工使用的十二类业务。这样的完整责任链支持高级工程师定位，因为你不仅实现功能，还持续承担上线后的业务与运行结果。

下一级 · Staff

사내 BI 시스템 的全公司使用范围是良好起点，但使用人数和组织覆盖本身不等于跨团队技术治理。需要补充真实发生过的接口分歧、决策权边界、迁移推进方式，以及其他团队为何接受你的方案。

相似申请者多数停留在 Senior 级别 · 只有前 32-46% 能达到 Staff

找出评审者可能产生疑问的地方。

找出模糊成果与缺失背景等可能引起疑问的内容。

建议复核的要点

简历中发现的潜在风险信号。投递前重新审视，有助于提升可信度与说服力。

中风险

细节不足

AWS Bedrock 相关条目已经给出具体工具和交付场景，但尚未解释 工具执行的可靠性边界，包括参数校验、权限限制、失败恢复及结果验证分别由什么组件承担。目标岗位要建设可复用的执行框架，技术面试很可能追问这些实现细节与个人贡献；请补充实际做过的机制，并将尚未实现的能力明确保留为设计提案，避免把数据分析功能链直接等同于完整运行时。

"• AWS Bedrock, Tool Use API, 스키마 라우팅 등을 활용한 대화형 데이터 분석 서비스 구현"

细节不足

简介把1300描述为同时在线人数，项目部分则使用单日最高访问人数，统计口径尚未统一，两种指标对应的负载模型并不相同。Adobe 的系统设计与项目深挖可能据此追问容量和连接处理，您应核对原始统计定义、观察区间与来源后保留准确表述；这里需要澄清指标，而不是因为人数较大就怀疑项目真实性。

"• 이 기간 동안 활성 사용자 수 1.3만 명 및 하루 최대 접속자 수 1300명을 기록 (관련 게임 한국 커뮤니티 1위 달성)"

让主张具体，精简无关内容。

结合修改建议，查看需要补充依据的主张与可删减的句子。

⚠️

有风险的表述

Harness 名称容易被读成运行时所有权

Depth

“Harness Template”与目标岗位名称高度接近，容易让技术面试官直接进入运行时设计追问。但简历只说明结果一致性与开发流程化，没有说明执行器、上下文、状态和生命周期是否由你实现；若回答实际只是模板规范，读者会认为表述边界过宽。

→

将 AI / Claude 段拆成实际实现的工具调用应用、团队模板规范和个人 AI 工作流三类，并用 已实现的职责边界 替代含混的平台暗示。

✂️

建议删掉的句子

删去无法区分个人贡献的泛化表述

Gap

AI를 활용한 GitHub PR 코드리뷰, 운영 로그 분석 스케줄러 등 실제 업무의 다양한 영역 사용 경험

→

收紧为 将 AI 用于 GitHub PR 代码审查及定时运行日志分析，仅保留原文支持的事实。把节省时间或自动化覆盖率留待有记录时再补，不把使用经验改写成基础设施建设。

把职位差距转化为准备事项。

查看尚未满足的要求及短期、长期的补充准备。

AWS Bedrock 数据分析助手提供了工具调用经验，但尚未证明目标岗位要求的运行时状态、生命周期、模型上下文协议及多智能体协调能力。

短期弥合

以 AWS Bedrock 数据分析助手的自然语言到图表链路为基础，对照 Adobe 对上下文、状态和生命周期管理的要求区分现有实现与未知环节，形成含组件责任及失败出口的《助手执行链路事实图》。

长期提升

在 AWS Bedrock 助手的独立复现实验中实现可持久化任务状态与恢复入口，对应 Adobe 的状态和生命周期管理职责，交付覆盖重启、超时与恢复行为的状态转换测试矩阵。

ECS 部署、安全编码与查询优化能支持平台可靠性，但尚缺针对智能体隔离执行、安全边界及反馈改进的可验证设计。

短期弥合

将 사내 BI 시스템 已有的 ISO 27001 应对与安全编码工作按输入、权限和数据出口重新整理，对应 Adobe 的安全架构要求，交付区分已实施措施与待验证项的《工具执行威胁模型》。

长期提升

在 AWS Bedrock 助手的独立复现版本中注入工具超时、无效返回和进程退出，对应 Adobe 的反馈改进与可靠性要求，交付包含检测、恢复行为和未解决问题的故障实验报告。

预判面试可能深入追问的部分。

预判围绕个人职责与决策依据的深入追问。

系统设计面试官会追问 AWS Bedrock Tool Use 背后的执行边界与失败恢复

Technical

→ 准备 AWS Bedrock 数据分析服务的三分钟讲解，以问题→备选方案→实际取舍→已知结果为顺序，先说明真实数据访问需求，再画出模型、模式路由、工具和图表呈现之间的边界。选择一项你确实做过的调用设计，解释另一方案为何不合适；若没有重试、沙箱或持久状态实现，就明确指出，随后将设计建议与既有经历分开。带一张根据真实实现重绘并去除敏感信息的调用时序图，标明哪些节点由你实现、哪些由 AWS Bedrock 提供。演练时让对方连续追问工具超时与输出无效两类情况，检查自己的回答是否始终回到可核实的实现。

用经历故事准备可能的问题。

查看面试官关注点、可能的问题及可用于回答的经历。

预计面试官与面试安排

招聘人员

招聘人员初步沟通

45 分钟（占位，待确认）

会被验证的点

这一席位对应 Adobe 常见的“履历与岗位匹配、求职动机、工作地点、时间安排及薪酬预期”沟通，会先判断你的企业平台经历与 Senior Software Engineer, Meta Factory Agent Harness 是否值得进入技术讨论。约 11.2 年经验、Springworks (3Y) 的 Adobe AEM 背景及 San Jose 工作安排，都是比运行时实现更早出现的核对点。

回答方向

用一分钟串联 사내 BI 시스템 的全公司责任、AWS Bedrock Tool Use 实作与四人团队领导，再用 pokepoke.gg 的独立开发和 1.3 万活跃用户补充产品所有权。年限如实陈述，工作安排和资格由你本人作答；不要把 Adobe AEM 项目经验表述为曾受雇于 Adobe。

软件工程师

技术面试：编码与项目深挖

45 分钟（占位，待确认）

会被验证的点

这一席位对应 Adobe 常见的“解题过程、边界条件、测试思路，以及既往项目中的实现细节和个人贡献”，会把你的性能和实时系统主张变成可执行的追问。对于 Senior Software Engineer, Meta Factory Agent Harness，AWS Bedrock Tool Use 的调用边界可作为项目入口，但不应将具体运行时题目视为已经确认的安排。

回答方向

准备 pokepoke.gg 的 SSE 事件处理示例，练习用代码解释重连、重复事件与状态更新，并明确哪些处理实际存在。再用 FastAPI BFF 与查询优化说明十秒到一至两秒的测量条件，让 Adobe 面试官能区分你的实现贡献、平台提供的能力和未验证的假设。

💬

预测问题

在 AWS Bedrock 数据分析服务中，SQL 由模型直接生成与经结构化工具参数生成之间，你实际选了哪条路径；面对越权查询或工具超时，校验与恢复边界 放在哪里，为什么没有采用另一种方案？

你写到 10초 → 1~2초대 개선；请拆分 FastAPI BFF、集计查询和数据模型各自的作用，说明 测量口径与替代方案，并解释缓存失效或查询分布变化时，哪项优化最先失效。

📖

面试故事包

AWS Bedrock Tool Use 数据分析服务

这段经历最适合回答 Adobe 系统设计与项目深挖中关于工具接口、输入输出边界和本人实现范围的问题。它也是连接 Senior Software Engineer, Meta Factory Agent Harness 的最直接材料，但应明确 AI 应用与运行时基础设施的差别。

问题起点是让自然语言问题进入数据分析流程，你实际实现的链路覆盖 SQL 生成、数据加工和图表呈现。

围绕 AWS Bedrock、Tool Use API 与模式路由，解释一项真实接口选择及其约束，并明确哪些能力由服务提供、哪些由你实现。

🔁

你应该反问的问题

好问题能让你像同事而不是应聘者。挑一个最自然贴合这位面试官的就好。

Meta Factory 希望保持模型独立；最近一次模型能力差异迫使团队调整工具接口或上下文策略时，哪些变化留在适配层，哪些进入公共 Harness，最终怎样决定维护责任？

原因

这个问题将你的 AWS Bedrock Tool Use 经验连接到岗位明确提出的模型独立要求，并体现你关注接口寿命而不只关注调用成功。回答能帮助你判断 Meta Factory 的公共层是否已有稳定边界，以及新成员需要承担多少兼容性与迁移责任。

确定先修改什么。

先看2项优先改进内容及修改方向。

正式申请前优先补强的点

这些是正式投递前最值得先修的高杠杆项。

将技能部分的 AWS Bedrock 数据分析助手条目扩展为独立案例，按自然语言输入、模式路由、工具调用、数据处理和图表输出的顺序交代现有实现，并明确每一步由您负责的部分。重点补充确实存在的 接口契约、失败处理与结果验证，没有实施的机制应列为待验证问题，而不是加入成果描述；这能让 Adobe 的 Senior Software Engineer, Meta Factory Agent Harness 审阅者判断您与底层执行框架之间的实际距离。

请依据我简历中技能部分的 AWS Bedrock 数据分析助手条目和简介，输出一个项目小节，包含3条事实要点及一张“实现环节／已有证据／待补充信息”表。保留现有产品名称，只使用已给出的工具调用、模式路由、SQL生成、数据处理与图表功能，缺少的权限、重试、状态管理或评测机制一律写为待确认，不要替我生成已完成经历。

重写 사내 BI 시스템 的技术改进部分，以共享图表抽象、设计系统公共包和 Next.js App Router 迁移为核心，分别说明解决了哪个重复问题、哪些开发者使用，以及维护边界如何确定。为每项改变补上您能核实的 技术取舍与采用证据，不凭空增加开发提速百分比；这样更贴近 Adobe 的 Senior Software Engineer, Meta Factory Agent Harness 对可复用架构、接口标准和跨团队采用的要求，也为设计面试提供可展开的事实。

请把我在 사내 BI 시스템 中的公共组件、设计系统和框架迁移经历整理成3条重写要点，再列出最多5个需要我回答的事实问题。每条要点采用“原有问题—本人决定—已知结果”的结构，保留 Next.js App Router、Turborepo 和 ECharts 的原始名称；采用团队数量、备选方案和提速数据若未提供，请放入问题列表而非成果正文。

安排投递前30分钟的准备。

从报告的30分钟准备计划中选择可立即开始的任务。

先用十分钟重写首屏工程主线

把简介调整为企业平台所有权、AWS Bedrock Tool Use、四人团队领导的顺序，并保留 사내 HR 시스템 十二类流程及性能改善等具体事实。将 Adobe AEM 放在 Springworks (3Y) 经历中作为产品背景，避免它挤占最相关的 AI 工程证据。

再用十分钟拆清智能体实现边界

在 AI / Claude 段将 AWS Bedrock 应用、Harness Template 和 GitHub PR 辅助工作流分开，分别写明真实实现与使用范围。给最相关的一项补上接口或失败处理决策；没有现成事实时标记待核实，不用岗位关键词填空。

把分散的经历串成职业故事。

梳理经历中的共同优势与下一份工作的衔接。

职业故事

您在 Springworks (3Y) 参与 Adobe AEM 网站与资产管理项目，处理不同客户的需求，并推动公共组件复用。进入 CookApps (8Y) 后，您通过 사내 HR 시스템承担从需求到运营的完整交付，将12类业务流程转为约150名员工使用的服务。下一步先整理现有数据分析助手的执行链路，明确已实现机制与未知边界，再选择一个失败恢复场景完成可复现验证。