Candidate GTM Pipeline
更新紀錄
改善面向
已收錄的改善
40 筆 · 自 2026 年 1 月起
本頁只收錄 Candidate GTM Pipeline 已完成且有意義的改善；例行同步、格式整理與私人紀錄不收錄。
2026-08-10
-
技術查證頁現在直接說明自己提供什麼
發布前 review 發現入口承諾超過 route 實際提供：「證據與資料」讀起來像一個廣泛的證據頁，但這條 route 真正的 contract 是 PostgreSQL lifecycle model 與系統架構。改名為「系統與資料」後，導覽標籤、頁面標題與 metadata 都對齊這份 contract，讀者能預期自己即將打開什麼，也能驗證抵達的正是名稱所說的地方。
2026-08-02 – 2026-08-05
-
公開導覽現在直接說明讀者下一步能做什麼
四個公開視圖不再使用內部區段名稱，而是改成「從這裡開始、怎麼運作、證據與資料、更新紀錄」。陌生讀者不必先理解網站架構，就能判斷下一步該看哪一頁。
-
證據與資料頁現在串起求職 lifecycle、CRM 紀錄與每日工作檯
證據頁不再堆放彼此分離的架構圖，而是沿同一條營運故事閱讀。每個求職階段先對到熟悉的 CRM 紀錄，再說明 Johanna、Skills、PostgreSQL 與私有 Decision Workbench 如何協作；想深入查證的人仍可查看完整資料模型。
-
公開網站可以呈現營運資料，但不能改動它
公開網站已移除對 27 張可寫核心表的存取權，只透過四個專用的唯讀物件取得展示所需證據，啟動時也不再依賴登入資料庫。公開案例因此可以使用真實營運資料，同時沒有改動正式紀錄系統的權限。
-
私有 Decision Workbench 把申請紀錄整理成今天的營運畫面
登入後的工作檯把申請判斷、資料源健康、已存履歷證據與面試時間放進同一個每日畫面。判斷用真人句子呈現，不是資料庫代碼；每個區塊都唯讀對接同一套正式紀錄。Johanna 不必再從分散查詢與檔案重新拼出今天該注意什麼。
-
手機讀者現在看得出畫面外還有其他視圖
過去手機視圖列看起來已經結束，即使螢幕邊緣外還有其他頁面。現在列尾加入明顯提示，讓讀者知道可以繼續滑動，不會因 viewport 截斷而漏掉「證據與資料」或「更新紀錄」。
-
私有工作檯現在使用正式登入與分層存取檢查
私有側從瀏覽器彈窗密碼改成獨立登入流程。Cookie session、route authorization、原子化鎖定、登入速率限制與長度優先的密碼政策，從多層保護工作檯；公開頁仍可正常閱讀，不會繼承私有工作檯權限。
2026-07-27 – 2026-08-01
-
每個進行中的 JD 現在都有一頁策略、人脈與證據缺口工作檯
每個正在投入的職缺都有一頁工作檯，集中呈現職務策略、stakeholder map、來源新鮮度與尚未解決的缺口。狀態由底層 receipts 推導，不靠手動寫一句結論；經過十多輪可讀性打磨後，其他人也能直接接手，不必從資料夾重新拼回整個 campaign。
-
引薦證據現在可以被轉述，也不會失去來源
Buyer-pitch workflow 把完整證據包壓成引薦人能準確重述的兩句核心版本，同時保留讀者認得出的 project context，以及每個 claim 背後的 source receipt。內容變短不等於變成無根據的稱讚；交給 router、advocate 或 evaluator 時，也不必每次重新發明 Johanna 是哪種候選人。
-
資料模型頁現在直接從資料庫本身產生
公開資料模型不再另外手工維護圖表，而是從 PostgreSQL 的 table 與 column comments 生成。欄位選擇、CRM 翻譯、funnel metrics 與 lineage 都來自 runtime 使用的同一份 schema；結構改變時，文件 drift 會被抓到，不會讓頁面悄悄停在舊版本。
-
公司名稱先對帳，才會寫入 sponsorship 判定
一輪職缺掃描曾因同一家公司使用不同法定名稱與公開名稱，而誤讀 sponsorship 證據。現在 identity resolution 會先對齊 aliases，且每家公司都要完成個別核對才能寫入 slate 判定；名稱對不上時系統會保留不確定性，不會把它變成有把握的 eligibility 結論。
-
多份履歷現在可以並行 tailor，不會互相覆蓋
每個 application 在履歷 tailor 期間都有隔離工作副本與專屬 export path，完成後再透過明確 handoff 合併回主線，不與其他輪共用檔名。並行工作因此能提高處理量，又不會把 PDF、版面量測或 payload 寫進錯誤的申請工作包。
2026-07-20 – 2026-07-26
-
公開證據數字現在會交代分母，也保留真實空窗週
冷讀發現幾個 headline 數字雖然看起來亮眼，卻無法在第一眼自行校準。Proof strip 因此補上明確分母，週投遞圖也保留沒有活動的週次，不再壓縮時間軸；讀者可以分清規模與轉換，也能直接看到真實營運節奏。
-
雇主需求現在直接使用雇主自己的原文
市場需求區不再由 Johanna 代替 hiring teams 摘要，而是直接展示真實 JD 原句。引言以雙軌呈現，只有讀者手動捲動才會移動；實際使用發現定時輪播不利閱讀後，已將它移除。讀者因此有足夠時間把 buyer language 與旁邊的能力證據互相比對。
-
投遞回應讓 SDR／BDR 退出預設目標人池
數週的回覆、沉默與拒絕 pattern 顯示，SDR／BDR 並不是產生有效動能的人池。這些職種因此退出預設搜尋、推薦、投遞與 networking 路徑，不再因為舊履歷素材存在就持續投入；注意力改投向有較強回應訊號的 Marketing／GTM／Customer Signal Analytics 與相鄰 campaigns。
-
Networking 狀態現在只能跟在已保存的訊息證據之後
每封送出的 LinkedIn 邀請都會先進入 evidence ledger，之後才允許改變 networking 狀態。接受時間保留來源、profile aliases 會對回同一個人，訊息同步也補強了頁面 race 與跨 thread 污染問題；關係紀錄因此能從真實互動回查，不必相信憑記憶填入的 status label。
-
投遞狀態信現在會自動更新求職 Pipeline
系統會增量抓取新的拒絕信、面試通知與申請狀態信，再用語意判讀把每封信對到正確的 application。Deterministic write gate 只允許高信心結果寫回正式狀態；無法確定的訊息保留待查，不會覆蓋 pipeline。確認後的變更會自動進入下一輪每日 routing，減少人工對帳，也不讓 automation 猜答案。
-
公開案例改按 Hiring Manager 下判斷的順序重建
首頁不再照系統的建置順序介紹內容，而是改按 Hiring Manager 會問的問題排列：Johanna 是誰、她在運轉什麼、是否真的在用、這份工作為何重要，以及哪些證據可以查。新結構完成 prototype、同步到正式 app，並成為網站主閱讀路徑。
2026-07-14 – 2026-07-19
-
2,976 筆 live postings 重新校準目標市場與進入路徑
六個官方 job boards 共提供 2,976 筆 live postings，其中 145 筆命中目標 lane，並逐字讀完八份完整 JD。這輪讀數釐清了 AI-forward 公司把這類工作放在哪些組織、有哪些 entry routes，以及哪些 senior openings 應當作市場訊號而非立即投遞目標；搜尋語言與 company watchlist 因此改用真實證據，不再只靠 Marketing Analyst title。
-
網站流量現在要先分類，才能算進讀者證據
流量分析成為正式 Skill，並固定先排除 Johanna 自己的造訪、bot 與疑似投遞流程 automation，再判讀外部注意力。只有通過這些檢查的 visits 才能升級成讀者證據或市場學習，避免把單純 page view 包裝成好看但不真實的 audience claim。
-
每個候選人門面現在都從同一份系統身份真本 derive
Candidate Go-to-Market Pipeline 成為 Resume、LinkedIn、公開網站、public repo 與面試敘事共用的名稱與故事來源。每個 surface 仍會依讀者改寫表層語言，但不再各自發明不同身份或 claim ceiling；exact-set validator 與精簡後的憲法，也讓 Skill library 擴張時仍能查清路由與責任。
-
Email 與 networking sync 現在共用一份資料新鮮度 ledger
Email 與 networking sync 改用共用的 sync_state ledger，不再各自定義 freshness。自動 schema snapshot 成為結構真本，能抓出資料庫與文件之間的 drift；即使某次成功抓信但沒有新郵件，freshness 也會正確前進，不再把健康來源誤判成過期。
-
JD 資格化現在保留來源，規則修改前後還要通過回歸考卷
每個篩選判定都會連同產生它的 query、source material 與時間一起保存，之後可以回查當時究竟讀了什麼。批次 qualification 也保留 per-query attribution，不再把多次搜尋壓成一份無法解釋的 slate；治理這段流程的 Skill 同時加入 cold-read exam，規則變更必須先和舊版比較，才能取代它。
2026-07-10 – 2026-07-13
-
網站現在能從閱讀旅程學習，但不追蹤個人
第一方量測會記錄匿名閱讀深度、頁面順序與 referral source，不使用 cookie，也不做瀏覽器指紋辨識。Likely-human traffic 會先與 bot、self-visit 分開分類，再進入內容 readout；網站因此能學習哪些 proof paths 真正被使用，又不會把單一訪客建立成個人 profile。
-
英文成為公開主稿，中文保留為等值自檢版
英文頁改為直接寫給美國 hiring readers，不再等中文定稿後逐句翻譯。中文仍保留完整等值版本，用來檢查意思與 claim boundary；這套雙文稿 workflow 能抓到「在一種語言裡 technically correct，換到另一種語言卻不自然或易誤讀」的句子。
-
首頁現在同時看得到真人、Skills，以及守住兩者的測試
公開案例加入 Johanna 的真實肖像與支撐 workflow 的 Skill roster，並用 visual contract test 檢查改版後這些身份與證據元素仍然存在。系統因此被讀成 Johanna 親自設計、持續運轉的工作，而不是一個沒有主人的 AI interface。
-
公開區塊現在要通過冷讀，才能留在頁面上
兩個已完成區塊雖然技術上正確，卻無法說服沒有背景的讀者。一條公開 route 因此刪除，一份 loss-analysis readout 則留在內部，沒有再加更多文字替它辯護；公開內容必須真的提升 hiring confidence，不是只證明又多了一份 artifact。
-
旗艦 AI Project 現在直接說明實際做了哪些求職工作
履歷 project 改用具體 live case 說明：依 Johanna 的 rubrics 篩選 job-market signals、診斷 shortlisted JD、為買方重組證據、交給零背景 cold reader 驗證草稿，再把 miss 寫回規則。可重用的 experience anchor 保存這段故事背後的 proof、metrics 與 claim ceilings；不同履歷可以前移相關能力，不必每次重新發明另一個 AI project。
更早的里程碑——最初六個月，壓縮呈現。
2026-07-01 – 2026-07-09
-
候選人、方法與證據現在共用同一個公開網址
公開 pipeline 定版 johannafan.com，成為 Resume、LinkedIn、outreach 與面試素材共用的單一連結。Hiring reader 不必再從不同目的地拼回 Johanna 的身份、operating method 與 evidence；網址也指向持續維護的正式 application，不是臨時 preview。
2026-06
-
第一版 Candidate GTM 公開首頁正式上線 Azure
自訂網域切換完成後，第一版持續維護的首頁正式發布到 Azure。候選人故事、workflow 與 proof 從本機檔案變成外部讀者真的能打開查看的頁面；release receipts 同時記錄 domain 與 hosting cutover，不把 deployment 當成沒有留下證據的最後一步。
-
Resume tailor 建立三種受治理的起手 lens
履歷 tailor 不再從過往文件中隨意挑一份開始，而是固定由三個具名 source 起手：MKT 對應 signal-to-decision 工作、CORE 對應 CRM／pipeline／workflow／handoff、SDR 對應 prospecting 與 outbound。每次先由其中一份 baseline 擁有整頁結構，再依 JD 重排證據，避免同一份申請混入多種候選人身份。
-
投遞從偶發衝刺改成每日營運迴圈
Marketing-analysis applications 建立可重複的每日路徑，不再依賴偶爾一次的 search-and-apply 衝刺。這條迴圈把機會檢視、準備、投遞與下一個 follow-up decision 接起來，未完成工作有清楚的續做位置；daily cadence 成為系統的一部分，不必每天早上重新提醒自己。
2026-05
-
市場閱讀讓搜尋重新對準 GTM／Revenue Ops & Analytics
幾個月的 JD 閱讀顯示，Johanna 的可遷移工作主要透過 GTM、revenue operations 與 analytics work objects 被市場購買，不是 broad generic-data identity。Search presets 因此在正確 lane 內重建廣召回，再由 qualification rules 決定哪些職缺值得投入；定位改變來自市場證據，不是因為某個新 title 聽起來更好。
-
申請表現在使用單一事實來源，送出前保留真人 gate
受控 browser workflow 會從同一份已驗證 personal profile 填寫申請表，不再靠記憶重複輸入事實。Workflow 可以導覽、填欄位與檢查頁面，但最後送出仍是明確的人類決定；可重複的表單工作與不可逆的正式投遞因此被清楚分開。
2026-04
-
LinkedIn 回覆與跟進現在依寫下來的關係判斷運轉
專用 Skill 會先讀 relationship stage、眼前 open loop 與完整前文，再起草 LinkedIn 回覆或 follow-up。判斷邏輯在每日使用中持續打磨，不再每封訊息都從零即興；workflow 也能區分現在該回覆、等待、接住承諾或收口，而不是把每個 connection 都當成同一套 outreach sequence。
2026-03
-
Resume 不再是一次性檔案，並建立 evidence-first 單一真本
可重用的候選人事實與 proof 進入持續維護的 resume sources，不再從上一份申請複製。Evidence-first tailoring Skill 會從受治理 baseline 起手、讀完整 JD，再依買方改變證據順序與強度；跨職缺仍成立的改善可以回到 source，不會消失在單一 exported PDF 裡。
-
求職紀錄系統從 SQLite 搬上 PostgreSQL
Jobs、applications 與營運狀態移到 PostgreSQL，active runtime 也停止維護第二條 SQLite 路徑。PostgreSQL 成為下游 Skills 與 reporting surfaces 共用的讀取來源，移除雙 runtime 後，不同電腦或工具不容易再對同一個 pipeline 問題給出不同答案。
2026-02
-
職缺清單從單一 JSON 檔搬進可查詢的資料庫
持續成長的 job list 從 jobs.json 移入 SQLite，之後可以用 structured data 查詢與更新，不必每次變更都重寫整個大型檔案。這是正式紀錄系統的第一步，後來才有能力承接 applications、status history、reporting 與自動檢查。
2026-01
-
招聘判斷成為可重用 Skill，候選人事實也有了固定 source
第一個 hiring-judgment Skill 把「如何讀一份職缺」寫下來，不再讓推理只存在單次對話中；同時建立 candidate-truth 專用資料夾，讓 Resume 與其他產出從持續維護的事實 derive，不必每次重新創造一個 Johanna。可重複判斷與可重用證據因此成為兩種分開、可版本管理的資產。
-
Initial release：求職成為有版本的營運 project
求職進入單一 repository，決策、artifacts 與 workflow changes 都開始由版本控制管理。早期 specs 讓工作可檢查、可回復，不再只散落在 chat history 與本機檔案；後來的 Skills、databases、public proof 與 learning loops 都從這個地基長出來。