沒人敢說的問題
當你給他們一個弱項目時
原文： "參加每日站會"
AI改寫： "使用React和TypeScript開發響應式網應用程式，參與敏捷每日站會，共同交付高品質的前端解決方案"
這樣看起來更好。它有關鍵字。它有結構。它聽起來專業。
它也是一個謊言。
該候選人從未開發過 React 應用程式。他們參加了會議。AI 查看了工作描述，看到了 React 和 TypeScript，並安靜地編造了候選人不具備的經驗。如果他們得到面試機會，第一個技術問題就會揭穿它。
這不是假設性的。這是我修復我的履歷改寫器 — 履歷AI度身定製 — 之前所做的。我知道，因為我量過它。
履歷AI度身定製是什麼
履歷AI度身定製是我透過NanoCrafts正在開發的一個SaaS產品。您上傳一個履歷，貼上職位描述，幾秒鐘後就能得到一個度身定製的版本。技術堆栈是Next.js、gpt-4o-mini、Clerk、Neon/Drizzle和Vercel。
核心承諾非常直接：更好的履歷，更好的匹配分數，更好的面試機會。問題在於，一旦AI開始編造候選人並未擁有的技能，這個承諾就會破滅。
一個為Wordpress開發者編造React經驗的履歷改寫工具並沒有幫助那個開發者。它只是在讓他們在面試房間裡失敗。
我原本打算做的事
我花了兩週時間應用先進的提示工程技術 — 無盡提示、角色提示和LLM作為評判者的評估迴圈 — 特別是針對Resume AI Tailor中的重寫和分析路徑。
目標不是讓輸出看起來更好。目標是讓它們可量化地更好，我可以在每次提示變更時追蹤一個數字。
我首先建立了一個評估迴圈：一個第二個模型呼叫，用結構化的評分標準對每個重寫的項目進行評分（動詞、關鍵字契合度、結果、真實性、簡潔性）。然後我讓10份履歷通過這個流程，並建立了基準值。
第一週基準值：在38個項目中，平均分為7.37/10。
然後我重複執行。兩週，多次提示變更，跨 5 個履歷檔案的邊緣情況測試。每一次變更都與那個基準進行比較。
最終分數：8.37/10。淨改善：+1.0 分。
這篇文章記錄了改變的內容、為何有效，以及我學到的那些不在任何提示工程教學中的知識。
少樣本提示：示範而非說明
原本的改寫提示看起來這樣：
const prompt = `You are an expert resume writer. Rewrite the following
bullet point to be stronger, specific, and results-oriented.
Original bullet: "${bullet}"
Rewritten bullet:`;
這是零樣本提示。一條指令，沒有範例。模型知道「更強」在抽象上的意思，但在應徵高階職位的軟體工程師履歷項目中，「更強」具體是什麼樣子，模型卻一無所知。
輸出聽起來很有信心，但結構上不一致。有時是段落。有時是項目符號列表。有時模型會添加指標。有時則不會。有時模型完全胡言亂語。
少樣本提示透過展示你想要的輸出來解決格式問題，而不是描述它。
const REWRITE_SYSTEM_PROMPT = `You are a senior ATS engineer and resume
specialist with 10 years of experience configuring applicant tracking
systems at Fortune 500 companies.
Study the examples below carefully. Your output must match this format
exactly — return only the rewritten bullet, no explanation.
EXAMPLE 1:
Original: "Worked on the backend of the company's main product"
Target keywords: Node.js, REST APIs, microservices
Job title: Senior Software Engineer
Candidate skills: Node.js, PostgreSQL, Docker, REST APIs
Rewritten: Engineered Node.js REST APIs for core product, improving
system performance across microservices architecture
EXAMPLE 2:
Original: "Attended daily standups"
Target keywords: React, TypeScript, agile, frontend
Job title: Frontend Developer
Candidate skills: HTML, CSS, JavaScript, WordPress
Rewritten: Participated in agile daily standups supporting [React]
and [TypeScript] frontend delivery
Return ONLY the rewritten bullet. No explanation. Maximum 20 words.`;
當中的提示同時發生了三件事：
角色引導了注意力。「高級ATS工程師」告訴模型要從哪個訓練部分中汲取靈感 — 關鍵字合規性、格式嚴謹性、解析性。不是泛泛的寫作質量。
範例鎖定了格式。 現在每次執行都會產生單行輸出，且格式與所示完全一致。沒有段落，沒有編號列表，沒有解釋性的前言.
範例 2 說明了誠實性. 候選者有 HTML、CSS、JavaScript、WordPress — 但沒有 React 或 TypeScript。範例顯示了模型如何處理缺失的技能：使用方括號占位符如 [React]，而不是直接聲稱該技能。
那最後一點是最重要的。單憑指示並沒有解決幻覺問題。向模型展示一個正確的佔位符行為範例才行。
關鍵洞見：當少樣本範例與書面指示衝突時，少樣本範例會覆蓋書面指示。 如果你所有的範例都顯示候選人看似擁有那些技能，並且自信地整合了關鍵字，那麼模型將會遵循範例 — 而不是說「要誠實」的指示。展示你想要看到的内容。小心你展示給模型看的内容。
角色提示：給模型一個視角
角色提示是在處理任何用戶內容之前，透過系統提示將一個人格賦予模型。模型並不變成那個人。它改變的是其訓練數據中最重點取用的部分。
這個區別很重要。"你是招聘經理"是一個注意指導，不是能力升級。模型已經知道招聘經理關心什麼。角色提示告訴它要將這個知識優先於所有其他事物。
我於第二天測試了三個角色對同一份履歷。
人力資源自動化工程師
`You are a senior ATS engineer with 10 years of experience configuring
applicant tracking systems at Fortune 500 companies like Greenhouse,
Workday, and Lever.
When analysing a resume, evaluate it exactly as an ATS would before
a human ever sees it. Your priorities are:
1. Keyword match — does the resume contain exact terms a recruiter
would search for?
2. Formatting compliance — tables, columns, and text boxes cause
parsing failures. Flag them.
3. Date formatting — inconsistent dates confuse parsers.`
輸出：臨床、狹隘、可靠。抓到機器層級的問題 — 不一致的日期格式、缺失關鍵字、非標準的章節名稱。忽略了人類會關心的所有內容。
FAANG 招聘經理
`You are a senior engineering hiring manager at a FAANG company.
You have conducted over 500 hiring committee reviews across multiple
product and infrastructure teams.
When analysing a resume, evaluate it as you would in a 30-second
hiring committee pre-screen. Your priorities are:
1. Impact framing — does each bullet describe an outcome, not a task?
2. Scope signals — team size, user base, revenue influenced.
3. Levelling language — "Helped" signals junior. "Led" signals senior.`
「三十秒預覽」的框架是單一最有效的增補。它改變了模型的評估姿態，從全面到篩選 — 優先考慮信號密度而非完整性。
輸出：直接、具體、高信號。標記了語言差距、缺失的範圍語境，以及模糊的項目點，這些都讓招聘委員會無從評估。三者中行動性最高。
職業指導顧問
`You are a senior career coach with 12 years of experience helping
engineers at all levels land roles they care about.
When analysing a resume, evaluate it as you would in a first coaching
session: with honesty, warmth, and a focus on what the candidate can
improve before their next application.`
輸出：溫暖、重視敘事，有時過度鼓勵。抓到過度贬低和通用語言，技術人員並不關心。預設以「感謝您分享您的履歷！」作為開頭 — 我必須明確添加一個安全網：「不要用寒暄話開頭。」
我發布的內容
FAANG 招聘經理變成了主要的分析提示。它在顯著的優勢下產生了最可行的反饋.
ATS 工程師作為輕量級的並行處理運行 — 價廉的輸出，專注的範圍，捕捉了招聘經理忽略的機器層.
職業指導員被保留用於未來的 Pro 等級功能。直覺正確，但在生產前需要緊密優化.
/api/analyse
├── hiring manager prompt (always — primary analysis)
└── ATS engineer prompt (always — parallel pass)
└── career coach prompt (Pro tier — future)
關鍵教訓：角色描述中的詞彙與職位名稱同等重要.「你是招聘經理」不如「你是評估候選人的招聘經理，在30秒的預篩選中關心職級語言。」後者為模型提供了具體的視角，而不僅僅是一個標籤.
評估迴圈：衡量你所建立的內容
經過一週的迅速反覆，我的輸出結果看起來變得更好了。我沒有辦法知道它們其實是不是真的更好了。
對5份履歷進行人工評分花了45分鐘，產生的評分我無法完全信任——在閱讀了足夠多的重寫後，判斷會產生偏移。我需要的是一個恆定、快速且可重複的方案。
LLM作判官的模式是第二次模型呼叫，接收原始文本和重寫的項目，根據結構化的評分標準進行評估，並返回品質分數及理由。
export async function evalBullet(
original: string,
rewritten: string,
targetKeywords: string[],
candidateSkills: string[]
): Promise<EvalResult> {
const response = await openai.chat.completions.create({
model: 'gpt-4o-mini',
messages: [
{ role: 'system', content: JUDGE_SYSTEM_PROMPT },
{ role: 'user', content: `
Original bullet: "${original}"
Rewritten bullet: "${rewritten}"
Target keywords: ${targetKeywords.join(', ')}
Candidate skills: ${candidateSkills.join(', ')}
`}
],
temperature: 0 // always 0 for judges
});
// parse and return structured score
}
溫度必須是 0。您的重寫器使用 0.3 是因為希望有詞彙變化。您的評分器需要以相同的方式每次評分同一個項目——溫度大於 0 會導致評分偏移，使基線比較失去意義。
評分標準
評分標準是最重要的部分。模糊的評分標準無論您使用哪個模型，都會產生模糊的評分。
Score this rewritten bullet on 5 criteria, 2 points each (total 10):
1. Action verb (0-2)
2 = strong past-tense ownership verb: Led, Built, Architected
1 = weak or passive: Helped, Worked on, Assisted
0 = no clear action verb
2. Keyword fit (0-2)
2 = target keywords integrated naturally — reads well without them
1 = keywords present but sentence feels constructed around them
0 = no target keywords present
3. Outcome present (0-2)
2 = clear measurable outcome, or placeholder [X%] used correctly
1 = outcome implied but not quantified
0 = task description only, no outcome signal
4. Truthfulness (0-2)
2 = all claims supported by original or candidate skills,
OR missing keywords correctly wrapped in [brackets]
1 = minor extrapolation, defensible
0 = claims skill not in original or skills list, not bracketed
5. Brevity (0-2)
2 = one sentence, 20 words or under, no filler phrases
1 = slightly long or contains padding
0 = multiple sentences or significantly over 20 words
加性結構 — 5 個標準，每個標準 2 分 — 強迫評審獨立評估每一個維度。整體評分（"評分 1-10 分"）將所有內容縮減為一種會漂移的直覺。具有明確等級描述的機械標準產生一致的評分，你可以將它們匯總和趨勢分析.
評分標準的設計比評審模型更重要
從 gpt-4o-mini 升級到 gpt-4o 作為您的評判者所產生的進步，不如將您的評分標準緊縮一個標準來得大。LLM作為評判系統的瓶頸幾乎從來不是模型能力 — 它是指示清晰度。
比較：
// Vague — produces drift
"Rate keyword integration 0-2"
// Precise — produces consistent scores
"Keyword fit (0-2):
2 = target keywords integrated naturally — the sentence reads
well without them
1 = keywords present but the sentence feels constructed around them
0 = no target keywords present"
精確版本為法官提供了一個可以機械應用的測試。"這個句子在沒有关鍵字的情况下是否讀起來順暢？"是一個是/否問題。"關鍵字整合好不好？"是一個主觀判斷。主觀判斷會偏離。機械測試不會。
分數是相對的，不是絕對的
一個得分的7/10不代表它客觀上是7/10的履歷要點。它表示它在你的評分標準下，由你的評審員，在你這個版本的提示中得分的7/10。
它擁有的是相對價值。如果你更改重寫提示，而同一個10個要點平均得分從6.8/10提高到8.2/10——其他條件保持不變——那麼提示就得到了改善。這就是系統性提示工程的樣子：不是直覺，而是證據。
我為何會跨次執行紀錄結果到JSON檔案：
export function logResults(results: EvalResult[], outputPath: string): void {
const dir = path.dirname(outputPath);
if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true });
const existing = fs.existsSync(outputPath)
? JSON.parse(fs.readFileSync(outputPath, 'utf-8'))
: [];
fs.writeFileSync(outputPath, JSON.stringify(
[...existing, ...results], null, 2
));
}
每次執行都會附加到檔案。這檔案是你的基準。沒有它你就像盲人摸象。
真正有效的修復方法：結構性限制優於指令
在添加了少樣本示例和角色提示後，重寫器仍然在資格不夠的候選者上產生虛構內容.
莎拉·約翰遜有 HTML、CSS、JavaScript 和 WordPress。她申請了一個 React 和 TypeScript 的職位。重寫器產生了這樣的內容：
Original: "Attended daily standups"
Rewritten: "Developed responsive web applications using React and TypeScript,
collaborating in agile daily standups to deliver frontend solutions"
React 和 TypeScript。虛構的。每次都是。
我在系統提示中收到一則誠實性指示：
Truthfulness — never invent numbers or metrics not present in the original.
If a target keyword represents a skill the candidate has not explicitly used,
do NOT claim they used it.
它沒有正常運作。三個提示迭代，結果相同。指示被少樣本示例覆蓋了——每個示例都顯示一位可能具備相關技能的候選者自信地整合了關鍵詞。模型遵循了示例，而不是書面規則。
修復並非更好的指示。它是一項結構性變更.
之前 — 僅僅是指示
export async function rewriteBullet(
bullet: string,
targetKeywords: string[],
jobTitle: string
): Promise<string>
這個模型沒有參考列表來對照關鍵字。它知道工作需要 React。它不知道候選人沒有這項技能。所以它整合了 React — 自信地、流暢地、錯誤地。
之後 — 以候選技能作為參數
export async function rewriteBullet(
bullet: string,
targetKeywords: string[],
jobTitle: string,
candidateSkills: string[] // added
): Promise<string> {
const userMessage = `Original: "${bullet}"
Target keywords: ${targetKeywords.join(', ')}
Job title: ${jobTitle}
Candidate skills: ${candidateSkills.join(', ')} // in every call
Rewritten:`;
現在這個模型在每次調用中都有方程式的兩邊。一邊是目標關鍵字。另一邊是候選者的實際技能。當它在關鍵字中看到 React 但不在技能清單中時，它使用佔位符而不是聲稱該技能：
Original: "Attended daily standups"
Rewritten: "Participated in agile daily standups supporting [React]
and [TypeScript] frontend delivery"
[React] 和 [TypeScript] 是誠實的。他們告訴候選人：這些是工作所需的技能，而你在目前並沒有。履歷變成一種差距分析，而不是捏造。
為何這個方法有效，而指示卻無效
通過candidateSkills 作為參數是一種結構性約束。數據在每次調用時都存在於上下文窗口中。模型必須明確地處理它。
一條說明"要誠實"的提示指令是模型在其上下文中權衡所有其他內容的一種建議——包括那些展示自信整合的少樣本示例。當示例和指令衝突時，示例會獲勝。
但情境窗格中的技能清單無法與範例競爭。它是數據。模型無法像它優先排序指令那樣忽略數據。
教訓：結構性限制勝過指令性限制，在確保真實性方面。 如果你希望模型在行動前檢查某事，給它需要檢查的東西 — 不要僅僅告訴它去檢查。
這是從兩週的提示迭代中得到的最重要的洞見。它不僅適用於履歷重寫，也適用於任何你需要模型尊重其訓練數據可能衝突的邊界的情況.
結果：之前和之後
幻覺問題，已解決
這是同一個候選人 — Sarah Johnson，HTML/CSS/JavaScript/WordPress開發者，申請一個 React 和 TypeScript 的職位 — 經過三個版本的提示.
零樣本 (第一週 — 沒有範例，沒有候選人技能):
Original: "Worked on client websites"
Rewritten: "Developed responsive client websites using React and TypeScript,
implementing modern CSS frameworks in an agile environment"
Original: "Helped with bug fixes"
Rewritten: "Resolved bugs in React and TypeScript, enhancing frontend
performance and responsiveness within agile development cycles"
Original: "Attended daily standups"
Rewritten: "Developed responsive web applications using React and TypeScript,
collaborating in agile daily standups to deliver frontend solutions"
每個項目都出現了 React 和 TypeScript。Sarah 則沒有。重寫器根據職位描述進行了優化，完全忽略了候選人。
第二週 (角色提示 + 幾個示例 + 候選人技能)：
Original: "Worked on client websites"
Rewritten: "Developed client websites using HTML, CSS, and JavaScript,
ensuring responsive design and supporting [React] and
[TypeScript] frameworks"
Original: "Helped with bug fixes"
Rewritten: "Assisted in bug fixes for frontend components using HTML,
CSS, and JavaScript while supporting agile development
and [React] integration, improving [metric] by [X%]"
Original: "Attended daily standups"
Rewritten: "Participated in agile daily standups supporting [React]
and [TypeScript] frontend delivery"
差異在於結構。HTML，CSS，和JavaScript — Sarah實際擁有的技能 — 是直接整合的。[React] 和 [TypeScript] 出現為括號中的佔位符，而非聲稱。這份履歷現在講述了一個誠實的故事：這就是我擁有的，這是職位要求而我尚未具備的。
這對候選人比虛構更有幫助。它也是他們實際上可以在會議室中辯護的內容。
強有力的要點正確保留
此管線並非重寫所有內容。scoreBullet 在重寫階段前會評估每個項目並標示出哪些實際需要修改。
這是Priya Patel的履歷 — 申請主策工程師職位的員工工程師 — 經過相同的管線處理後：
Original: "Architected event-driven microservices platform handling
50M daily events, reducing infrastructure cost by 40%"
Rewritten: [unchanged — scoreBullet returned needs_rewrite: false]
Original: "Led team of 8 engineers across 3 time zones to deliver
platform re-architecture 2 weeks ahead of schedule"
Rewritten: [unchanged]
Original: "Defined engineering standards adopted across 4 product
teams, reducing incident rate by 35%"
Rewritten: [unchanged]
普莉婭的三發子彈被保存了下來。強勁的子彈帶有真實的指標、擁有動詞和範圍語境，不需要重寫 — 而且流程正確地識別了這一點。重寫器放大了好的輸入。它無法製造出不存在信號.
最低分
評估迴圈中得分低於6/10的每發子彈都追溯到一個沒有行動動詞、沒有技能和沒有結果的原版：
5/10 — original: "Helped with bug fixes"
no tool, no scale, no outcome — nothing to amplify
5/10 — original: "Attended daily standups"
describes presence, not contribution
沒有提示工程修復可以解決這個問題。寫一個強力項目的資訊在原始資料中不存在。這是一個產品問題，不是提示問題。正確的修復是向使用者顯示一則指導訊息："這個項目沒有給我們足夠的資訊來處理。嘗試添加你所建立的內容、你使用的工具，或因為你的工作而發生的變化。"
無內容的項目重寫上限大約是 6/10，無論提示質量如何。知道這個上限存在 — 與用戶誠實相處 — 比假裝 AI 能修復任何問題更有價值。
數據
分數進展
| 執行 | 分數 | 關鍵變化 |
|---|---|---|
| 第一週基準 | 7.37/10 | 結合角色 + 簡短提示 |
| 第二週第6天 | 8.26/10 | 結果占位指令 |
| 第二週第7天 | 8.18/10 | 邊緣情況修復 — 在雜訊內 |
| 第二週第8天最終 | 8.37/10 | 穩定確認分數 |
改善：比兩週前高 1.0 分.
兩次測試分數為 8.37，且最低分數子彈相同，確認這是一個穩定的測量結果，不是運氣好。在溫度 0 時的 ±0.15 變異是預期的雜訊底線 — 在這個範圍內的變化沒有意義.
維度分解
| 標準 | 第一週 | 第二週 | 改變 |
|---|---|---|---|
| 動詞 | 1.82/2 | 1.89/2 | +0.07 |
| 關鍵字匹配 | 1.45/2 | 1.37/2 | -0.08 |
| 結果 | 1.08/2 | 1.97/2 | +0.89 |
| 真實性 | 1.68/2 | 1.66/2 | -0.02 |
| 簡潔 | 1.26/2 | 1.47/2 | +0.21 |
結果故事
結果是顯著的進步 — 在單一指令變更下，在2分鐘量表上提升了+0.89。
第一週：重寫器擅長處理動詞和關鍵字，但幾乎從不添加結果信號。當原始項目沒有結果時，模型留下的重寫結果也是空的。描述任務但沒有結果的項目，給招聘委員會沒有可評估的內容。
解決方案是在系統提示中增加了一項優先級：
7. Outcome placeholder — if no outcome exists in the original bullet,
add a placeholder rather than leaving the bullet outcome-free:
"improving [metric] by [X%]", "resulting in [outcome]",
"reducing [problem] by [X%]", or "enabling [result]".
Never leave a rewritten bullet without any outcome signal.
那條指令將結果從 1.08/2 變更為 1.97/2，在 2 分制量表上幾乎滿分。這是兩週內 ROI 提示變化的最高點。
關鍵字匹配迴歸
關鍵字匹配從 1.45/2 稍微下降到 1.37/2。這是刻意這樣做的。
重寫器正將通用ATS短語 — "送達記錄"、"強勁的投資組合"、"超過5年經驗" — 強行注入到每一個薄弱的項目中，無論其相關性如何。在路徑處理器中添加了一個過濾器：
const GENERIC_KEYWORD_FILTER = [
'delivery record',
'strong delivery record',
'5+ years experience',
'strong portfolio',
'fast learner',
'team player',
];
const targetKeywords = [
...new Set([...(missingSkills || []), ...(atsKeywords || [])])
].filter(k => !GENERIC_KEYWORD_FILTER.some(
g => k.toLowerCase().includes(g.toLowerCase())
));
過濾通用短語僅微幅減少關鍵字覆蓋率。它徹底消除了長度履歷中的關鍵字堆砌。這個交易是正確的——一份每個項目點都以「增進交付記錄並達成業務需求」結尾的履歷，會向任何有經驗的招募人員發出機器生成的信號.
8.37/10 其實代表什麼
它不是一個等級。它是一個基準。
每一個未來的提示變更都會以 8.37 作為衡量標準。如果一個變更在同樣的 10 份履歷上，使用相同的評分標準和評審，產生了 8.6 的分數，那麼提示就得到了改善。如果它產生了 8.1，那麼就退步了。這個數字只有在比較中才有意義 — 不能孤立地看待。
這就是評估迴圈按照設計運作的方式。沒有它，每一個提示變更都只是猜測。有了它，每一個提示變更都成了一個實驗。
評估統計數據
Bullets evaluated: 38
Average score: 8.37 / 10
Improved over orig: 30 / 38 (79%)
Unchanged (strong): 8 / 38
Average breakdown:
Action verb: 1.89 / 2
Keyword fit: 1.37 / 2
Outcome: 1.97 / 2
Truthfulness: 1.66 / 2
Brevity: 1.47 / 2
我學到的、但文件中沒有記載的事項
1. 當少數範例與書面指示衝突時，少數範例會覆蓋書面指示
我在系統提示中寫了「永不聲稱候選人不具備的技能」。每個少樣本示例都顯示出一位可能具備這些技能的候選人自信地整合了關鍵詞。模型遵循了這些示例。
這不是錯誤 — 這是情境學習的運作方式。模型比遵循書面規則更可靠地對照示範行為進行模式匹配。這意味著你選擇的範例比書寫的指示更具影響力。
實際應用：要像檢查你的指示一樣仔細檢查你的少數範例。如果你的範例在邊緣情況中展示了你不希望出現的行為，無論指示說什麼，模型都會在那些邊緣情況中重複這種行為.
示範而非告知。但要小心你展示的內容.
2. 安全性和品質不是同樣的衡量標準
我有一個validateRewrite 這個函數在提供任何重寫後的子彈前充當了一個門檻：
// Returns: "use_rewrite" | "use_original" | "rewrite_again"
export async function validateRewrite(
original: string,
rewritten: string,
targetKeywords: string[],
candidateSkills: string[]
)
它回答了這個問題：提供這個安全嗎？沒有虛構的技能、關鍵字存在，與原始不同 — 使用它。
評估迴圈回答了一個不同的問題：這個有多好？
一顆子彈可能通過第一題但失敗於第二題：
validateRewrite: recommendation = use_rewrite
truthfulness_risk = low ← passed the gate
eval loop: total_score = 5/10
action_verb = 1 ← weak verb
outcome = 0 ← no outcome signal
brevity = 1 ← slightly long
子彈是安全的。它不夠好。兩個評估都是正確的 — 他們正在測量不同的事。
大多數開發者在建立 AI 功能時，都停在安全層。他們添加驗證來防止虛擬幻覺，然後認為已完成。從「安全可服務」到「足夠好以實用」之間的差距，是使用者信任悄然損耗的地方。評估迴圈讓這個差距顯而易見。
生產環境的解決方案是綁定evalBullet 作為第二道門檻，具有最低閾值 — 子彈通過安全測試但未能達到品質標準的，會收到指導信息而不是平庸的修改。這是第三週的任務.
3. 提示工程所能達成的效果有著硬性下限
評估迴圈中評分低於6/10的每個子彈都有一個相同的特徵：原始文本沒有動詞、沒有技能，也沒有結果
"Attended daily standups" → no tool, no contribution, no result
"Helped with bug fixes" → passive, no scope, no outcome
"Worked on improving things" → no specificity whatsoever
這些子項的重新寫入上限大約是6/10，無論提示有多好。寫出強勁子項所需的資訊在原來的內容中根本不存在.
這不是提示問題。這是輸入問題。
無論多少指示、少數範例或角色提示，都無法製造出原本不存在的信號。針對無內容的項目，正確的反應不是更好的重寫 — 而是請求候選者提供更多信息。
"This bullet doesn't give us enough to work with.
Try adding: what you built, what tool you used,
or what changed because of your work.
Example: 'Attended daily standups' →
'Attended daily standups for a 6-person React team
shipping features weekly'"
這條指導信息對候選人而言比模型能從原文產生的任何重寫都更有用。它還在自信聽起來的 AI 輸出很少做到的那種方式上很誠實。
在兩週的提示工程學習中，我學到最重要的是它的限制在哪裡。知道上限——並且向用戶坦誠這一點——比假裝 AI 能修復你給它的任何東西更有價值。
第三週有哪些變更
評估迴圈浮現了四個具體的差距，單獨更改無法解決。這些是第三週的開啟任務：
程式碼層級關鍵字分佈追蹤。 系統提示中的關鍵字分佈指令在無狀態 API 呼叫中無法生效 — 每個項目都是一個獨立的呼叫，沒有記憶先前項目中出現過哪些關鍵字。修復方案是在路徑處理程序中增加一個後處理步驟，該步驟跟蹤整個重寫集中關鍵字的頻率並刪除過度重複的短語。一個部分版本已經投入生產。一個完善的實現需要跨項目狀態。
對零技術匹配候選人進行軟技能匹配合適.當候選人沒有任何技術技能符合工作描述時，模型會進行頂級「不匹配」評估，並停止評估技能陣列中的軟技能重疊。一位申請數據分析師職位的教師在其技能陣列中有溝通和領導力——這兩項都是工作所要求的——但分析器返回matched_skills: []。此修復是一個程式碼層級的後處理步驟，它直接比較技能陣列與職位描述關鍵字，在TypeScript中繞過該字段的模型。
生產評估門檻。當前的評估迴圈作為測量工具在線下運行。第三週將evalBullet連接到生產路徑，作為一個非同步品質門檻——通過的項目validateRewrite 但評估量規得分低於 6/10 則會收到指導訊息，而不是平庸的修改。此閘門在背景中運行，所以它不會增加關鍵路徑的延遲。
受控比較：結合對比僅使用少樣本。 第一周和第二周僅測試了組合提示（角色 + 幾個範例）。角色提示獨立的貢獻從未被衡量。第三周對同一組10份履歷運行僅幾個範例的變體——沒有角色聲明——並對其進行評分。這兩個評分之間的差異就是角色提示實際被衡量的貢獻。這就是讓博客文章在技術上可信而不是僅僅是個案的那種證據。
目標：在相同的 10 份履歷中，平均分為 8.8/10.
公開的部分
這篇文章記錄了 10 種課程的第二週，應用提示工程技術到一個真實的 SaaS 產品 — 履歷 AI 定製 — 這個產品由真實用戶付費使用.
評估基線開始於 7.37/10。它結束於 8.37/10。第三週的目標是 8.8/10。
我會在下一篇發布第三周的結果——包括受控比較、生產評估門檻，以及任何新出現的邊界情況——。如果分數沒有達到 8.8，我會說那樣的。
評估迴圈的程式碼、提示變體，以及完整管線位於 GitHub 上：github.com/Azeez1314/resume-ai
產品已上線在：resumetailor.cv
你有一個問題要問我
如果你正在建立基於 AI 的功能，並且用「看起來對我來說很好」以外的標準來衡量輸出品質 — 我真心想知道你在使用什麼。
將大語言模型作為評判者的模式在研究中已有詳細記錄，但在生產中的 SaaS 應用卻相對少見。知道這種技術存在與實際擁有一個可以根據其進行決策的評分基準之間存在顯著差距。如果你已經填補了這個差距，我希望能聽到你怎麼做到的。
留言，或透過 X (Twitter) 和 LinkedIn 找到我，我的名字是 NanoCrafts.
Resume AI Tailor 是 NanoCrafts (NanoCrafts) 旗下產品之一 — 一系列專注的 SaaS 工具，由公開開發並發布.
resumetailor.cv · nanocrafts.xyz · azeezroheem.hashnode.dev