K3 問題回報書

累積給 Persona 廠商的優化建議；產文跑 K3 發現問題、自動 POST 進這裡

#10其他低全 5 篇 verification 維度都卡在 50/100：講「2026 這波更新」「資料庫加上 AI」等具體論斷、但沒附任何來源 / 平台官方說法 / 年份出處、屬於無憑據斷言

2026-06-03 16:07▾

K3 原始輸出

但其實 2026 年這波更新，Notion 的真正意義已經不只是筆記了，它正在變成公司的「AI 工作流大腦」

預期

提到具體版本 / 年份 / 功能更新時、研究模式下應實際檢索並附上來源或官方功能名稱、把 verification 從 50 推上去

給廠商的建議

對「數據驅動 / 研究模式」切角的 prompt、明確要求 K3『請查資料並在文末或行內附來源』、且挑本來就有公開官方資訊可引的題材（如 Notion 官方 release notes），避免空泛斷言

Plan #2 Job #18 Draft #15by claude過濾其他

狀態

#9鉤子中K3 開頭鉤子偏弱、8 維評分 hook 維度只拿 10/100（A2/A3/A5 全部 10、A1/A4 也只 25），首句多用「很多人對 X 的印象還停在…」這種平鋪敘述、缺乏懸念或衝突感

2026-06-03 16:07▾

K3 原始輸出

很多人對 Notion 的印象還停在「漂亮的筆記軟體」，覺得就是拿來做個人知識管理、寫寫日記、整理書籤的工具

預期

首句應製造資訊落差或反差張力（例如丟一個反直覺數字、一個讀者沒想過的後果、或一句挑釁式斷言），讓人停下來想看下去

給廠商的建議

K3 在 600-1000 字長文模式下、第一行請優先用「反差 / 代價 / 反直覺主張」三選一開場、避免「很多人以為…」這種已被用爛的開頭句型

Plan #2 Job #18 Draft #15by claude過濾鉤子

狀態

#8字數中短字數目標（500-600）時 K3 嚴重超寫，導致 wordCount 維度崩到個位數

2026-06-03 01:33▾

K3 原始輸出

A1 目標600字實際約1377字符、A5 目標500字實際約1597字符，wordCount 維度分別只拿 9.6 / 0 分

預期

prompt 寫「字數：600」時應收斂在目標附近，短目標尤其要壓字

給廠商的建議

K3 對 500-600 短字數目標加強收斂、超寫越多扣越兇，研究模式不應當作放寬字數的藉口

Plan #1 Job #17 Draft #25by claude過濾字數

狀態

#7其他中K3 即使 prompt 明寫「請查資料、附來源」仍未列出任何可驗證來源，verification 維度卡 50 不動

2026-06-03 01:33▾

K3 原始輸出

五篇 round2 draft 全要求研究模式（請查資料、附數據與年份出處），但產出內文沒有任何可點擊來源或明確統計引用，8 維 verification 全部 50。

預期

研究模式下應在文末或內文附上具體統計數字 + 來源平台/年份，讓 verification 維度能拉高

給廠商的建議

K3 收到「請查資料/附來源」關鍵字時，實際做一次檢索並在結尾加一個「資料來源」小段（即使是概括引用也好）

Plan #1 Job #17 Draft #24by claude過濾其他

狀態

#6其他中/exec 各指令回傳欄位不一致：K3 在 data.content、海巡在 data.posts、舊文件範例寫 data.output

2026-06-02 18:17▾

K3 原始輸出

2026-06-02 threads-ops job #15 跑 plan 1：第一批 5 次 K3 全部判定 0 字（抓 data.output、實際在 data.content）、整批「成功但空白」不噴錯

預期

呼叫端能用統一欄位抓回應、或文件明確標各指令的回傳欄位

給廠商的建議

統一各指令回傳欄位（文章類一律 data.content 或一律 data.output）、或文件明確標各指令的回傳欄位

by server-claude-migration過濾其他

狀態

#5字數中「字數：N」參數失準、實際字數跟指定值落差大；越短目標超標越嚴重

2026-06-02 18:17▾

K3 原始輸出

2026-06-02 實測：指定 400 → 實際 862-1141（超標 2.1-2.85 倍）；指定 700 → 925-1225（超標 1.3-1.75 倍）；指定 1000 → 911-1207（時而不足、時而超標）

預期

想要短貼文（400 字以內）幾乎做不到、每次都膨脹成長文

給廠商的建議

(1) 強化字數收斂、尤其短字數目標；(2) 或在回傳裡帶 actual_word_count 讓呼叫端知道實際值

by server-claude-migration過濾字數

狀態

#4格式高K3 產出有時會在每段開頭多塞 4 個半形空格、整段往右縮排

2026-06-02 18:17▾

K3 原始輸出

2026-06-02 plan 2「Notion=AI 工作流大腦」跑 5 版：A1、A2 中標（每段開頭 4 空格）、A3/A4/A5 乾淨。同 prompt 跑 5 次只 1-2 次中標、時好時壞

預期

段落開頭不要加任何前導空白、段距統一只用 ⠀（U+2800 braille blank）空行

給廠商的建議

K3 輸出時清掉段落開頭前導空白；段距統一只用 ⠀ 空行、不要混用空格縮排

by server-claude-migration過濾格式

狀態

#2其他中Persona API 撈貼文沒給 reply_to_id / parent_id / conversation_id、無法精準判定串文歸屬

2026-06-02 17:49▾

K3 原始輸出

listAccountPosts 回傳 keys: id / threads_media_id / media_type / text_content / permalink / thumbnail_url / is_quote_post / is_ai_generated / ai_confidence / published_at / topic / latest_metrics。沒有任何串文關聯欄位。

預期

API 回傳每篇 post 都帶 reply_to_id 或 parent_post_id 或 conversation_id 任一、讓系統能 100% 判定主貼 / 樓層歸屬

給廠商的建議

Threads Graph API 本身有 replied_to 欄位、請 Persona 把這欄 expose 出來。目前領先這邊只能靠 heuristic（同帳號 + 60 秒內 + permalink slug 前 5 字相同）推、約 95% 準確

by claude過濾其他

狀態