หลายทีมเริ่มทำ Live Document กันมากขึ้น เอา README, meeting note, decision log, task board, runbook, architecture, evidence และ incident report มาเก็บไว้ใน repo เดียวกัน เพื่อให้ repo ไม่ได้เป็นแค่ที่เก็บ source code แต่เป็น source of truth ของงานจริงด้วย แนวคิดนี้ดีมาก เพราะมันทำให้ context ไม่กระจายอยู่แค่ในแชท ในหัวคน หรือในไฟล์ที่ไม่มีใครรู้ว่าอัปเดตล่าสุดอยู่ตรงไหน
แต่พอ repo เริ่มโตขึ้น ปัญหาใหม่ก็เริ่มโผล่ขึ้นมา คือเราไม่สามารถคาดหวังให้คน หรือแม้แต่ AI อ่าน repo ทั้งก้อนแล้วเข้าใจสถานะล่าสุดได้ดีเสมอไป ใน repo หนึ่งอาจมีข้อมูลเก่า ข้อมูลใหม่ draft ที่ยังไม่สรุป decision ที่ถูกยกเลิกแล้ว meeting note ที่ซ้ำกัน evidence ที่ไม่มีคำอธิบาย และ task ที่เคย active แต่ตอนนี้ไม่เกี่ยวแล้ว ถ้าโยนทุกอย่างให้ AI อ่านตรง ๆ AI อาจไม่ได้ฉลาดขึ้น แต่มันอาจสับสนขึ้นแทน
บางคนอาจถามว่า ถ้า repo เป็น source of truth อยู่แล้ว ทำไมไม่ให้ AI หรือคนที่เกี่ยวข้องต่อ repo ตรง ๆ ไปเลย สำหรับคนสาย technical คำตอบนี้อาจดูสมเหตุสมผล เพราะเขาคุ้นกับ README, folder structure, commit, issue, decision log และการไล่ context จากไฟล์จำนวนมากอยู่แล้ว แต่ปัญหาคือคนที่ต้องใช้ความรู้ของโครงการไม่ได้มีแค่ engineer และไม่ได้ทุกคนควรต้องอ่านความจริงในรูปแบบเดียวกัน
AE หรือ PM ที่ดูแลความสัมพันธ์กับลูกค้า อาจต้องรู้ว่างานนี้อยู่สถานะไหน มี blocker อะไร ลูกค้ารออะไร และมีประเด็นไหนควร follow-up แต่เขาไม่จำเป็นต้องเห็น task เชิงลึกทุกตัว ไม่จำเป็นต้องเห็น customer information ที่ละเอียดเกินหน้าที่ และไม่ควรต้องเข้า repo เพื่อกวาดหา status จากเอกสารหลายสิบไฟล์ ทีมบัญชีหรือการเงินก็คล้ายกัน เขาอาจต้องรู้ว่า deliverable ไหนขยับแล้ว งานไหนใกล้ billing-ready งานไหนยังติด acceptance หรือ evidence อะไรยังไม่ครบ แต่เขาไม่ได้ต้องการอ่าน architecture, incident log, technical decision หรือรายละเอียด implementation ทั้งหมด เขาต้องการ business delivery view ไม่ใช่ raw project repository
ระดับ ExCom หรือผู้บริหารยิ่งชัด เขาอาจแค่อยากรู้ว่าเรื่องนี้ไปถึงไหน ติดอะไร มี risk อะไร กระทบลูกค้า เงิน หรือ delivery ไหม และต้องการ decision จากใครหรือเปล่า การให้ผู้บริหารไปอ่าน live document ทั้งก้อนจึงไม่ใช่ความโปร่งใสที่ดีเสมอไป มันอาจกลายเป็นการผลักภาระการสรุปกลับไปให้คนอ่านเอง ดังนั้น Knowledge Build Pipeline ไม่ได้มีไว้แค่ทำให้ AI อ่านง่ายขึ้น แต่มันมีไว้เพื่อแปลง source of truth ชุดเดียวกันออกมาเป็น knowledge view ที่เหมาะกับแต่ละบทบาทด้วย
Source of truth ควรมีที่เดียว แต่ knowledge view ควรมีหลายแบบตามบทบาทของคนที่ต้องใช้มัน คน technical อาจยังอ่าน repo ได้เต็ม AE/PM อาจเห็น customer-facing summary ทีมการเงินอาจเห็น billing และ delivery status ผู้บริหารอาจเห็น executive brief ส่วน AI อาจเห็น structured knowledge package ที่ตัดข้อมูลซ้ำ เก่า ไม่เกี่ยวข้อง หรือไม่ควรถูกเปิดให้ทุกบทบาทเห็นออกไปแล้ว
ผมเริ่มมองเรื่องนี้คล้ายกับการ build software เราไม่ได้เอา source code ดิบไปส่งให้ user ใช้ตรง ๆ แต่เรามีกระบวนการ build, bundle, test และ package ให้กลายเป็นของที่พร้อมใช้งาน เอกสารของทีมก็ควรคิดแบบเดียวกัน Repository คือ source layer ส่วนสิ่งที่ส่งให้ NotebookLM, Codex, Claude, Gemini หรือ internal RAG อ่าน ควรเป็น generated knowledge package ที่ผ่านการจัดระเบียบแล้ว
Knowledge Build Pipeline จึงเป็นกระบวนการเปลี่ยน live document ใน repo ให้กลายเป็น AI-ready knowledge package เช่น .ai-knowledge/ ที่ประกอบด้วย project overview, project context, architecture summary, decision log, current work, runbook, evidence, meeting summary และ AI briefing เอกสารชุดนี้ไม่ใช่ source of truth ตัวใหม่ แต่เป็น output ที่สร้างใหม่ได้เสมอจาก source จริงใน repo
จุดสำคัญคือ generated knowledge folder ไม่ควรถูกแก้ด้วยมือ ถ้าข้อมูลผิด ต้องกลับไปแก้ที่ source document เช่น context, decision, meeting, task หรือ runbook แล้วค่อย build ใหม่ วิธีนี้ช่วยลดปัญหาเอกสารสองชุดไม่ตรงกัน เพราะ .ai-knowledge/ ถูกมองเหมือน dist/ หรือ build/ ไม่ใช่พื้นที่ที่คนไปแต่งข้อมูลเองตามใจ
อีกเรื่องที่สำคัญมากคือเวลา publish เข้า NotebookLM หรือ AI knowledge tool ไม่ควร append source ใหม่ไปเรื่อย ๆ เพราะจะทำให้ข้อมูลเก่าและใหม่ปนกัน Task ที่ปิดแล้วอาจถูกมองว่ายัง active Decision ที่ถูกแทนที่แล้วอาจยังถูกอ้างอิง Meeting summary อาจซ้ำซ้อนจน AI ตอบไม่ตรงกับสถานะปัจจุบัน วิธีที่ควรกว่าคือ build knowledge version ใหม่ แล้ว replace source เดิม ให้ AI อ่าน knowledge ชุดล่าสุดเป็นหลัก
Manifest ก็เป็นส่วนที่ไม่ควรมองข้าม เพราะมันบอกว่า knowledge ชุดนี้สร้างจาก commit ไหน สร้างเมื่อไร ใช้ source path อะไร และมี warning หรือ conflict อะไรบ้าง ถ้าวันหนึ่ง NotebookLM ตอบไม่ตรงกับ repo เราจะ debug ได้ว่าปัญหาเกิดจาก source document ไม่ดี, build pipeline ไม่ครบ, หรือ knowledge ที่ upload เข้าไปไม่ใช่ version ล่าสุด
สำหรับผม นี่คือ evolution ถัดไปของ Live Document ถ้าระยะเริ่มต้นคือการทำให้งานมีที่อยู่ มี context มี decision และมี evidence ระยะถัดไปคือการทำให้ความรู้นั้นถูก build ออกมาในรูปแบบที่ AI ใช้ได้ดีขึ้น ไม่ใช่ปล่อยให้ AI เดินอ่านทุกซอกทุกมุมของ repo แล้วหวังว่ามันจะเข้าใจเอง
AI ที่ดีต้องการ context ที่ดี และ context ที่ดีไม่ได้เกิดจากการโยนข้อมูลทั้งหมดเข้าไป แต่เกิดจากการออกแบบ pipeline ที่รู้ว่าอะไรคือ source of truth อะไรคือ generated output อะไร outdated อะไร active อะไร conflict และอะไรควรถูกใช้เป็น briefing สำหรับคนหรือ AI ที่เข้ามาใหม่
สุดท้าย Knowledge Build Pipeline ไม่ได้มีไว้เพื่อ NotebookLM อย่างเดียว แต่มันคือรากฐานของ AI-first engineering knowledge system ชุดเดียวกันนี้อาจถูกใช้กับ Codex, Claude Code, Gemini, internal RAG, search index, MCP server หรือ onboarding portal ในอนาคตได้ ถ้าทุก project publish ความรู้ของตัวเองออกมาใน format ที่เป็นมาตรฐาน องค์กรจะไม่ได้มีแค่ repo ที่เก็บงาน แต่จะมีระบบความรู้ที่ AI อ่านได้ คนอ่านได้ และทีมส่งต่อกันได้จริง