Career Pivot Research

"Can I move into this role?" is not one question. It is: what is actually required, what of that do I have, and which of my existing work is being described in the wrong vocabulary.

Distinct from resume-jd-matcher (one specific JD, go/no-go for one application) and job-application-screener (ranking a batch of openings).

Step 1 — Collect real JDs, with links

Search the target title plus 校招/应届 if the user is a student. Aim for 5-8 postings, and keep the source URL for every one so the user can check your reading.

Record per posting: 岗位职责 (verbatim) + 任职要求 (verbatim) + source. Verbatim matters — paraphrase is where you start inventing requirements.

Then count term frequency across all of them. The frequency list is the actual bar; any single JD is a sample.

Look for the posting aimed at the user's own graduation year. A JD that says 「2027 届」or 「其他专业不限」changes the whole answer.

Real case (2026-10-21): asking about AI 测试工程师 for a 2027-graduate content-operations candidate. Six JDs collected. Two findings flipped the answer: 中国移动卓望 wrote 「计算机相关专业优先，其他专业不限」(non-CS major was not a hard filter), and 每日互动's JD was explicitly 「2027 届」 — the user's own year. Neither was visible from any single posting.

Step 2 — Three capability tiers

Do not answer "am I qualified" with one verdict. Split it:

The 远超线 is the actual argument for hiring them, and it is usually invisible on the resume because it is expressed in the old domain's language.

Real case: the candidate's 「远超」was not a testing credential. It was: he had defined acceptance criteria for an AI product, owned a real rule set and regression set (15 rules / 14 regression cases / 27 replacement rules), run A/B experiments against metrics, and knew where the human/AI boundary sits. A CS-major test engineer with none of that. Meanwhile his 最低线 was empty: Python by hand, SQL joins, Linux, black-box case design, HTTP status codes.

Step 3 — Find the mislabelled project

The highest-leverage find in a pivot is a project the user already built and described in the wrong vocabulary. Do not add projects. Re-describe what exists.

Search their repos for the shape of the target role: rule engines, case sets, rule versioning, regression runs, validators, evaluation gates.

Real case: ad-compliance-checker was written on the resume as 「带货文案自动三级风险分级」— one line, product language. It is in fact a rule engine + tiered case set + regression suite: 15 graded rules, 14 regression cases, versioned rule file. That is a testing project. It was promoted from 1 line to 4, and it became the only thing on the resume that answers 「你做过什么测试」.

Step 4 — The rewrite table

The user has to paste this into a document themselves. Give them, per location:

• 板块 + 定位（where on the resume）
• 原文 / 改成（both copyable）
• 字数差 — they care about layout breaking
• 为什么这么改
• 风险标记

Character-count discipline

Count with whitespace stripped. Grade the delta:

• |Δ| ≤ 3 green — pastes in, layout unmoved
• ≤ 10 amber
• > 10 red — and for every red one, ship a compressed alternative in the same row

Do not silently pad to hit exact equality; state the delta and offer the short form.

Real case: 26 locations; 20 landed within ±5. The 6 outliers were all deliberate (a 1-line project promoted to 4 lines, a new skills line, a section compressed to free space). Each carried a note on what to delete if the page still overflowed.

Mark the ones that are a promise

If a line claims a skill the user cannot yet answer questions on, tag it 写下即承诺 and say so.

Real case: the new skills line listed SQL / pytest / Postman / Linux. The user had authorised "SQL — you can say I have basics". They had never touched SQL. The line shipped with the rule: finish the study plan before applying. Writing it earlier is a liability, not a shortcut.

Step 5 — Study plan with daily acceptance criteria

Every day needs an artifact, not a topic. "学习 SQL" is not a plan; "手写 20 条，5 分钟内写出『查年龄>20 的女生姓名』" is.

Include one watershed day where the claim on the resume becomes true rather than aspirational.

Real case: Day 21 — convert the 14 regression cases already sitting in the repo into actual running pytest. Before that day the new skills line is a promise; after it, it is a fact.

Step 6 — Growth path and pay

Give stages with what each stage actually does. For pay, separate JD-stated figures from inference and label which is which. Do not present an inferred range as a sourced one.

Red lines

• 🔴 Never add a course, project, or award the user does not have. Reordering the 主修课程 line is fine; inventing 「数据库与 SQL 应用」 is not. A line that gets probed in interview is worse than a gap.
• 🔴 Never invent a JD. Every requirement traceable to a link the user can open.
• 🔴 Do not use two numerical standards in one document. If the resume says 1000+ and your planning page says 2000+, pick one and say which.
• 🔴 Say plainly when a hard gate blocks the pivot. If the gap is a written coding test, the resume rewrite is not the bottleneck and saying otherwise wastes their month.

Example

我能不能转 AI 测试这种岗？照着 JD 帮我改一份能海投的简历，每个地方怎么改发我，最好字数一样。

6 JDs with links → frequency table → three tiers (his 远超 is defining acceptance criteria for an AI product; his 最低线 is empty and that is the real blocker) → ad-compliance-checker promoted from 1 line to 4 → 26-row rewrite table with character deltas and one 「写下即承诺」 tag → 30-day plan whose Day 21 converts existing regression cases into real pytest → growth path with JD-sourced vs inferred pay marked differently.