BnosK Services stack intro

Service Introduction

BnosK 主要專長在利用現有的穩定低成本技術來達成高準確性且可長期維護的文件系統和知識查詢服務。這個組合下：

• 文件系統：Confluence (html)
• Issue tracker： jira, 以及github (gitlab)
• RAG: AnythingLLM, NotebookLM 

關鍵在於如何正確使用這些服務的特定部份來Confluence (html), Evernote (OCR & Transcription)讓所有人都能理解和流暢操作這個流程到一定精確度以上。而不是想要一套軟體在無人熟練的情況下，能包辦全部疑難雜症。

 

Step 1: 擁有古老.doc文件公司 

想把所有文件整合做成線上，供內部查詢或保持更新。我們提供文件撰寫服務的同時，亦贈送已絕版的Confluence Server 7 正版序號。Confluence 7 是至今Atlassian功能最為完整穩定的版本，而且一次啟用終身可用。對於想做數位轉型的但不確定要選什麼系統的公司來說，這是最好的低成本高可用投資。RAG和LLM則可以透過自己客制的方式達成並建成更大的知識庫，無須付費使用原廠的雲端Rovo且只有限定少數頁面的知識

Step 2  - 適合軟體開發的文件撰寫流程

公司已有工單系統或慣用文件系統，也有資深PM或BD，文件資訊繁多，但書面和截圖等資料統合不佳。常見公司用Office 365，但新人卻習慣用Notion或Google文件導致開發資訊分散。我會集合資訊在主要一處，同時也用社群管理的經驗，讓同仁的意見或最新回報能有效的更新進去。以下是一些將文件實際寫在Confluence後，並去除敏感資訊後的截圖。文件可以被匯出成PDF，編輯則全部在該系統上確保現有資訊統一。

Step 3: Whitepaper 白皮書撰寫 

商業白皮書、Spec 。或是偏向描繪未來規畫 (Prescriptive) 的文件。

規劃的差異化參數，從中調整獲利的收入

將各參數的位置做巢狀結構標示

Step 4: "Doc as Code" approach

IT系工程師兼職維護對外文件說明的常見狀態。文件維護的效果經常未如預期。"doc as code" 會用上git flow或MD語法，甚至是直接引入如slate這樣的library。技術要求上難度高，但關鍵是卻沒有人或流程去確保是否所有文件仍與現狀符合，往往出現數百個橫跨十年以上的舊.md文件，與目前產品和商業目標差異大。目前我用Confluence只能做到像是這樣的程度。

 

An overview for printed doc audit log (not the system editing log)

A red flag to notify manual reader this api is new

Summary and related change log, tickets for this version

Introduction can be easily well-maintained for each project page portal

 成果一覽 

 每次匯出的文件大約壓制在200~300個html以內。更多的話要用AnythingLLM妥善管理才行，且LLM模型要選擇chatpgt 4o而不是gemini，才能減少幻覺。 

目前的限制是AnythingLLM的OCR並不夠足以正確辨識文件，NotebookLM 的OCR雖然好一些但每一個問答都只能有300個資料來源。對於創造一個更大的RAG知識庫其實遠遠不夠。

 

也許有人會說為什麼不用Notion？只要每個月付20usd就有AI search, transcription, 版本控制和無限空間，上萬個template還能做成對外小網站，甚至有內建connector可以爬slack, github 或jira, Google文件等。有幾個關鍵之處

1. 沒有離線查詢

2. 沒有OCR

3. 沒有傳統的issue tracker高效精確

4. 以note (文件）來管理專案是極度低效率且容易因資訊過時出錯的 

5. 內建AI的幻覺仍強，且connector爬搜效果遠遠不如宣稱的那樣符合預期正確性

 AI或任何工具都不能取代人類對內容正確與否的最終判斷和責任歸屬，因此確保人類的負擔是最小化集中在關鍵之處才是重點。Notion用戶有一個傾向是把所有輸入的draft都留存（包含無限嵌套階層），這樣反而嚴重浪費了人類有限的注意力。 技術上的問題也許在未來幾年會漸漸改善，但現在最成熟的作法還是如我們推薦這樣組合。