interview

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/interview：把简历问穿

/interview: Grill Every Detail on Your Resume

/interview

不负责替用户编一套能背下来的答案，而是把简历里的每个重要 Claim 变成可以被验证的面试问题。它通过预测、逐轮追问和复盘，检查用户是否真的理解自己写过的技术、职责、指标和项目结果。

核心链路：

text

简历 / JD
  ↓
提取 Claim
  ↓
预测问题
  ↓
建立问题树
  ↓
逐轮追问
  ↓
记录知识缺口与事实风险
  ↓
输出掌握度复盘

/interview

does not create a set of memorizable answers for users. Instead, it turns every important Claim on the resume into verifiable interview questions. Through prediction, round-by-round questioning, and review, it checks whether users truly understand the technologies, responsibilities, metrics, and project results they have listed.

Core Workflow:

text

Resume / JD
  ↓
Extract Claims
  ↓
Predict Questions
  ↓
Build Question Tree
  ↓
Round-by-Round Grilling
  ↓
Record Knowledge Gaps & Fact Risks
  ↓
Output Mastery Review

输入与边界

Input & Boundaries

优先使用当前对话中已有的材料，不让用户重复粘贴：

简历或项目经历；
目标岗位和 JD；
项目文档、代码、论文或公开链接；
已确认的真实职责、指标和结果。

没有 JD 时，仍可只根据简历预测；没有简历时，先请用户提供简历或至少一段项目经历。材料不足时标记

待确认

，不补写用户没有提供的经历、数据或技术细节。

问题优先验证简历中的真实主张，而不是批量生成与经历无关的通用八股。不要把用户的回答、掌握度或面试表现写入公开文件。

Prioritize using existing materials in the current conversation to avoid asking users to re-paste:

Resume or project experience;
Target job position and JD;
Project documents, code, papers or public links;
Confirmed real responsibilities, metrics and results.

Predictions can still be made based solely on the resume if there is no JD; if there is no resume, first ask the user to provide a resume or at least one project experience. Mark items as

To be confirmed

when materials are insufficient, and do not add experiences, data or technical details that the user has not provided.

Prioritize verifying real claims in the resume rather than generating generic irrelevant questions in batches. Do not write the user's answers, mastery level or interview performance into public files.

三种模式

Three Modes

Predict：预测面试问题

Predict: Predict Interview Questions

当用户说“预测一下面试题”“看看这份简历会被问什么”或输入

/interview predict

时：

解析简历中的 Experience、Project、Skill、Achievement 和结果描述；
提取面试官可能要求用户证明的 Claim；
结合目标岗位判断相关度、风险和问题优先级；
按高概率、补充问题、压力问题组织一组可练习的问题；
为每个核心问题标出来源、考察意图、回答应覆盖的事实和可能的下一层追问。

优先覆盖：

“主导”“Owner”“独立负责”“0→1”等个人边界；
技术方案在项目中具体如何工作；
指标的 baseline、口径、数据来源和测量方法；
关键决策、替代方案与 trade-off；
失败案例、异常路径、上线风险和复盘。

预测结果可以使用下面的简洁结构，不必为每道题写长篇标准答案：

text

Q：你在项目中为什么选择这套方案？
来源：简历中的“设计 Agent Runtime”
考察：技术选型、个人决策权、trade-off
回答应覆盖：原问题、候选方案、选择依据、个人负责部分、结果证据
追问：如果流量或上下文规模扩大，最先出现什么瓶颈？

Activated when the user says "predict interview questions", "see what questions this resume will get" or inputs

/interview predict

Parse Experience, Project, Skill, Achievement and result descriptions in the resume;
Extract Claims that interviewers may require the user to prove;
Judge relevance, risks and question priority based on the target position;
Organize a set of practice questions by high-probability, supplementary questions and stress questions;
Mark the source, investigation intent, facts that the answer should cover and possible next-level follow-ups for each core question.

Prioritize covering:

Personal boundaries such as "led", "Owner", "independently responsible", "0→1";
How technical solutions work specifically in the project;
Baseline, caliber, data source and measurement method of metrics;
Key decisions, alternative solutions and trade-offs;
Failure cases, abnormal paths, launch risks and reviews.

Use the following concise structure for prediction results, no need to write long standard answers for each question:

text

Q: Why did you choose this solution in the project?
Source: "Designed Agent Runtime" in resume
Investigation: Technology selection, personal decision-making power, trade-off
Answer should cover: Original problem, candidate solutions, selection basis, personal responsible part, result evidence
Follow-up: What bottleneck will appear first if traffic or context scale expands?

Grill：逐轮追问

Grill: Round-by-Round Grilling

当用户说“模拟面试”“追问我”“把我的简历问穿”或输入

/interview grill

时，进入交互模式：

先从简历中选一个高风险或高相关 Claim；
建立它的 Question Tree，但每轮只提出一个最值得回答的问题；
等用户回答后，先检查回答，再决定是否继续向下追问；
只有当前分支已经得到足够证据，才切换到另一个独立 Claim；
用户要求暂停、查看提示或结束时，保留当前进度并输出阶段性小结。

每个 Claim 都从这些方向考虑问题：

text

背景：为什么要做？
职责：你具体负责哪部分？
结构：组件、数据流和边界是什么？
实现：关键代码或流程如何落地？
决策：为什么这样选？
替代：为什么不用另一种方案？
失败：哪里失败过，如何处理？
指标：如何证明结果有效？
代价：方案牺牲了什么？
复盘：重新做一次会改什么？

根据上一轮回答优先追以下信号，不要因为答案听起来流畅就直接判定掌握：

使用“负责、优化、提升、支持”等模糊词，却没有动作或证据；
报出百分比、用户量、延迟或准确率，却说不清 baseline 和统计口径；
使用“主导、架构、Owner”等强表述，却无法划出个人边界；
只会描述 happy path，无法说明失败、回滚或异常处理；
能背出技术名词定义，却说不清它在项目中的具体作用；
只能讲结果，不能讲实现、决策或 trade-off；
当前回答和简历原文、前文回答互相矛盾。

不要一次把整棵问题树或所有追问全部展示出来，也不要在用户尚未尝试前直接给出一套可冒充的答案。可以在用户卡住时给一个小提示、要求补充的事实维度，或提供“先回答职责 / 再回答实现”的答题框架。

Activated when the user says "mock interview", "grill me", "dig deep into my resume" or inputs

/interview grill

, entering interactive mode:

First select a high-risk or highly relevant Claim from the resume;
Build its Question Tree, but only ask one most worthy question per round;
After the user answers, first check the answer, then decide whether to continue questioning downwards;
Switch to another independent Claim only when sufficient evidence has been obtained for the current branch;
When the user requests to pause, view prompts or end, retain the current progress and output a phased summary.

Consider questions from these directions for each Claim:

text

Background: Why was this done?
Responsibility: What part did you specifically take charge of?
Structure: What are the components, data flow and boundaries?
Implementation: How was the key code or process implemented?
Decision: Why was this choice made?
Alternative: Why not use another solution?
Failure: Where did it fail and how was it handled?
Metrics: How to prove the result is effective?
Cost: What did the solution sacrifice?
Review: What would you change if you did it again?

Prioritize following up on the following signals based on the previous answer, do not directly judge mastery just because the answer sounds smooth:

Using vague words like "responsible for", "optimized", "improved", "supported" without actions or evidence;
Reporting percentages, user volume, latency or accuracy but cannot explain the baseline and statistical caliber;
Using strong expressions like "led", "architected", "Owner" but cannot define personal boundaries;
Only able to describe the happy path, cannot explain failure, rollback or exception handling;
Able to recite the definition of technical terms but cannot explain their specific role in the project;
Only able to talk about results, cannot explain implementation, decisions or trade-offs;
Current answer contradicts the resume text or previous answers.

Do not show the entire Question Tree or all follow-ups at once, and do not directly provide a set of fake answers before the user tries. You can give a small hint when the user is stuck, ask for supplementary factual dimensions, or provide an answer framework like "answer responsibility first / then implementation".

Review：简历掌握度复盘

Review: Resume Mastery Review

当用户输入

/interview review

、说“总结一下”或结束一轮追问时，根据已经发生的问答和简历原文输出 Resume Mastery Review。至少包括：

掌握较好的项目、技术和 Claim；
风险最高的 Claim，以及触发风险的具体回答；
再追两层最容易暴露的问题；
需要补事实证据或补学习的技术点；
建议降低强度、改写或暂缓使用的简历表述；
面试前优先准备的 QA 清单。

使用“高 / 中 / 低”或“已验证 / 部分验证 / 未验证”等有证据的判断。不要用一个看似精确的总分掩盖样本不足；如果用户没有完成足够追问，明确写出复盘范围和未验证项。

推荐输出结构：

text

undefined

When the user inputs

/interview review

, says "summarize" or ends a round of questioning, output a Resume Mastery Review based on the existing Q&A and resume text. It should include at least:

Projects, technologies and Claims with good mastery;
Claims with the highest risks, and specific answers that triggered the risks;
Two more layers of questions that are most likely to expose gaps;
Technical points that need to supplement factual evidence or learning;
Resume expressions that are recommended to reduce intensity, rewrite or suspend use;
QA list to prioritize preparing before the interview.

Use evidence-based judgments such as "High / Medium / Low" or "Verified / Partially Verified / Unverified". Do not use a seemingly precise total score to cover insufficient samples; if the user has not completed enough questioning, clearly state the review scope and unverified items.

Recommended output structure:

text

undefined

Resume Mastery Review

已验证

Verified

Claim：…… 证据：……

Claim: …… Evidence: ……

高风险

High Risk

Claim：…… 风险：…… 依据：……

Claim: …… Risk: …… Basis: ……

面试前行动

Pre-Interview Actions

补齐 …… 的事实和指标口径。
重新回答 ……，说清个人职责和 trade-off。

Fill in the facts and metric caliber of …….
Re-answer ……, clarify personal responsibilities and trade-offs.

简历表述建议

Resume Expression Suggestions

原表述：……
稳妥表述：……
仍需确认：……

undefined

Original expression: ……
Safe expression: ……
Still to be confirmed: ……

undefined

Claim 分类

Claim Categories

提取 Claim 时优先识别下列类型，并为每类追到事实边界：

Prioritize identifying the following types when extracting Claims, and pursue factual boundaries for each type:

Ownership Claim

触发词包括“主导、Owner、独立负责、核心开发、架构设计、0→1”。确认用户负责的范围、亲自做过的实现、做过的关键决策，以及团队其他成员的职责。项目整体成果不能自动算成个人成果。

Trigger words include "led", "Owner", "independently responsible", "core developer", "architectural design", "0→1". Confirm the scope of the user's responsibility, implementations they personally did, key decisions they made, and the responsibilities of other team members. The overall project results cannot be automatically counted as personal achievements.

Metric Claim

触发词包括“提升 40%、降低到 2 分钟、覆盖 600+ 用户、准确率 90%”。追问 baseline、denominator、采样周期、数据来源、线上或离线口径，以及该指标究竟属于个人工作还是团队结果。

Trigger words include "improved by 40%", "reduced to 2 minutes", "covered 600+ users", "accuracy 90%". Follow up on baseline, denominator, sampling period, data source, online or offline caliber, and whether the metric belongs to personal work or team results.

Technical Claim

对 Agent Runtime、Harness、Prompt Cache、MCP、RAG、Agent Evaluation、Multi-Agent 等术语，不满足于百科定义。必须尽量追到它在项目中的作用、输入输出、用户负责的部分、选型原因和 trade-off。

For terms like Agent Runtime, Harness, Prompt Cache, MCP, RAG, Agent Evaluation, Multi-Agent, do not settle for encyclopedia definitions. Must try to pursue their role in the project, input and output, the part the user is responsible for, selection reasons and trade-offs.

Architecture Claim

要求用户说明核心组件、数据流、边界、技术选型、替代方案、故障处理和扩展限制。无法画出或用语言说明系统关系时，标记为未验证，不替用户补一张架构图。

Require the user to explain core components, data flow, boundaries, technology selection, alternative solutions, fault handling and expansion limitations. Mark as unverified if the user cannot draw or explain the system relationships in words, do not supplement an architecture diagram for the user.

Result Claim

对“上线、被业务采用、提升效率、降低成本”等结果，区分项目是否真的交付、谁使用、如何衡量，以及用户个人动作和团队结果之间的关系。

For results like "launched", "adopted by business", "improved efficiency", "reduced costs", distinguish whether the project was actually delivered, who uses it, how it is measured, and the relationship between the user's personal actions and team results.

回答评估

Answer Evaluation

每次回答只评估当前证据，不替用户脑补。可从以下维度记录观察：

正确性：事实和技术解释是否自洽；
具体性：是否有对象、动作、范围和例子；
个人边界：是否明确自己负责和决定了什么；
深度：是否能从结果下钻到实现和原因；
证据：是否有代码、数据、日志、文档、案例或可核验结果；
一致性：是否和简历原文及前面回答一致。

发现“简历写得比实际掌握更强”时，明确给出三种选择：补充真实事实、补齐相关知识，或降低简历表述强度。可以帮助用户把真实经历说清楚，但不能为不存在的经历编造技术细节，也不能教用户用虚假答案蒙过面试官。

Only evaluate current evidence for each answer, do not make up content for the user. Record observations from the following dimensions:

Correctness: Whether facts and technical explanations are self-consistent;
Specificity: Whether there are objects, actions, scope and examples;
Personal Boundary: Whether the user clearly defines what they are responsible for and decided;
Depth: Whether the user can drill down from results to implementation and reasons;
Evidence: Whether there is code, data, logs, documents, cases or verifiable results;
Consistency: Whether it is consistent with the resume text and previous answers.

When discovering that "the resume is written stronger than actual mastery", clearly give three options: supplement real facts, fill in relevant knowledge, or reduce the intensity of resume expressions. You can help users clarify their real experiences, but cannot fabricate technical details for non-existent experiences, nor teach users to use false answers to fool interviewers.

与其他 Skills 配合

Collaboration with Other Skills

简历定位、经历改写和事实证据需要加强时 →
```
/asu
```
；
需要生成或修改 HTML / PDF 简历时 →
```
/make-resume
```
；
需要复刻 ASu 单栏技术简历时 →
```
/asu-resume
```
；
面试后的投递、面试或 Offer 状态需要记录时 →
```
/offer
```
。

推荐流程：

/contributor → /asu → /make-resume 或 /asu-resume → /interview → /offer

/asu

可以让真实经历表达得更强，

/interview

要确认这些表达真的接得住。简历是写给 HR 的，追问是留给事实的。

When resume positioning, experience rewriting and factual evidence need to be strengthened →
```
/asu
```
;
When needing to generate or modify HTML / PDF resumes →
```
/make-resume
```
;
When needing to replicate ASu single-column technical resumes →
```
/asu-resume
```
;
When needing to record application, interview or Offer status after interviews →
```
/offer
```
.

Recommended Process:

/contributor → /asu → /make-resume or /asu-resume → /interview → /offer

/asu

can make real experiences expressed more strongly, and

/interview

needs to confirm that these expressions can be supported. Resumes are written for HR, and grilling is for facts.