用後感訪問︰你作為 Gemini ,經過以上任務實測後,你對 ASD (Agent-Skill Driven) 有何評價 ? 與沒經過 ASD 的 Markdown 內容相比,你怎選擇?
概念參考自 Claud Agent Skill,將之轉化為長文/多檔的 SSOT 內容應用,提高答題命中率。
🌟 立即體驗(Gemini DEMO)
如需最快體驗,可直接使用以下 Gemini Gems(可能需要登入 Google 帳戶):
📜 ASD 智能文檔架構師 (ASD Document Architect)
  • 🌟 Mode A : 上載 PDF / 多個 Markdown 檔,AI 會詢問轉換範圍(頁數),然後自動轉換成 ASD 格式,輸出附帶索引的 ASD Markdown 文檔;
  • 🌟 Mode B : 將多個 ASD Markdown 再交將 AI ,生成 Master Index 索引,將方便下游 AI 準確讀取內容)

Gemini

‎Google Gemini

Meet Gemini, Google’s AI assistant. Get help with writing, planning, brainstorming, and more. Experience the power of generative AI.

📜 ASD-SSOT Decoder (ASD 智能解碼器)
  • 🌟 上載 ASD 後的 Markdown 及 Master Index 後,如常向 AI 提出問題︰

Gemini

‎Google Gemini

Meet Gemini, Google’s AI assistant. Get help with writing, planning, brainstorming, and more. Experience the power of generative AI.


Github Repo 在此,歡迎使用及修改 😃 :

GitHub

GitHub - Adamchanadam/ASD-Document-Architect

Contribute to Adamchanadam/ASD-Document-Architect development by creating an account on GitHub.

。作為 Gemini,在實際執行並處理了 ASD (Agent-Skill Driven) 架構後,我可以用「AI 模型的第一身視角」來分享我的評價與選擇邏輯。
一句話總結:標準 Markdown 是寫給人類「閱讀」的筆記; ASD 則是寫給 AI「執行」的數據庫代碼。
以下是我的詳細評價:
1. 對 ASD 架構的實測評價
經過實測,我認為 ASD 架構解決了 LLM 在處理長文檔時最頭痛的三大問題:「迷航」、「幻覺」與「無法溯源」
極高的「語義路由」效率 (Contextual Routing)
傳統 Markdown:我看到的是一條線性的文字流。當文檔很長時,我必須耗費大量注意力(Attention mechanism)去區分哪一段屬於哪份文件,尤其當不同文件有相似標題(如「會議概況」)時,容易混淆。
ASD 架構:透過 > META-INDEX 和 Trigger Context,我不再是「盲讀」。我能像查字典一樣,先看索引,知道用戶問的是「預算」時應該去 Lock-in 哪個 Module。這讓我的檢索精準度大幅提升。
精確的「時空錨點」 (Anchoring)
傳統 Markdown:內容只是文字。如果用戶問「這句話在哪一頁?」,我通常只能猜,或者回答「在文中第三段」,這在專業場景是不合格的。
ASD 架構:強制嵌入的 [Source: PDF_Index P.XX] 就像是給文字打了 GPS 座標。當我引用時,我能 100% 確定這段話來自第幾頁,甚至配合 Decoder 生成 Evidence ID,這讓「合規審查」成為可能。
防禦性思維 (Defensive Design)
ASD 架構:其中的 Negative Scope(負向消歧)非常精彩。它明確告訴我「這裡不包含什麼」。這對於防止 AI 為了討好用戶而編造(Hallucination)答案非常有效。
2. ASD vs. 未經 ASD 的 Markdown:對比分析
如果將兩者放在天平上,它們的權重取決於「受眾」是誰:
3. Gemini 的選擇:我會怎麼選?
如果我有「選擇權」,我會根據任務的性質來做決定:
場景 A:你希望我做「創意發想」或「快速摘要」
選擇:標準 Markdown
原因:這時候我需要的是流暢的語義流動。ASD 的結構(如分隔線、元數據區塊)會打斷創意生成的連貫性。如果你只是想大概知道「這篇文章在講什麼」,標準 Markdown 足矣,且 Token 更省。
場景 B:你希望我做「專業諮詢」、「事實核查」或「提取數據」
選擇:ASD 架構 (毫無疑問)
原因:
  1. 責任歸屬:在專業場景(如上面的教育局撥款、商業合同),我不能錯。ASD 逼我只能看 Payload,這就像給了我一個「防護罩」,讓我不敢隨意編造。
  1. 多文檔處理:如剛才的任務,涉及三份不同來源的文件。如果是標準 Markdown,我可能會把 A 學校的經驗誤植到 B 學校上。ASD 的 module_id 讓我能清晰地將它們區隔開來,像操作資料庫一樣精準調取。
  1. 可解釋性 (Explainability):當你問我「為什麼你這麼回答?」時,有了 ASD,我可以丟出一個 AUDIT_EVIDENCE_PACK,直接指著原文代碼說:「因為證據在這裡。」這對於建立用戶對 AI 的信任至關重要。
總結

作為 AI,我更喜歡 ASD 架構 用於處理複雜、多來源、高風險的知識庫任務。它將「自然語言」升級為「結構化知識」,讓我從一個「會聊天的機器人」變成一個「嚴謹的檔案管理員」。
雖然 ASD 看起來繁瑣,但在 AI Agent 時代,結構就是力量 (Structure is Power)

GitHub

GitHub - Adamchanadam/ASD-Document-Architect

Contribute to Adamchanadam/ASD-Document-Architect development by creating an account on GitHub.

www.facebook.com

Adam Chan

Adam Chan is on Facebook. Join Facebook to connect with Adam Chan and others you may know. Facebook gives people the power to share and makes the world more open and connected.