งานหนึ่งชิ้นใน AI team มันวิ่งผ่านอะไรบ้าง

บทก่อนผมเล่าว่า AI เพียวๆ ยังไม่พอ เพราะมันบอกว่า “ทำแล้ว” ได้ แต่ state จริงๆ ในระบบอาจจะยังไม่ขยับ รอบนี้เลยอยากแกะให้ลึกกว่าเดิมว่าใน SekApp ผมต่ออะไรไว้บ้าง

ถ้าดูจากข้างนอก มันเหมือนมี agent คุยกันใน Discord เฉยๆ แต่ข้างหลังมีหลายชั้นมาก ตั้งแต่ `.md` ที่เป็นเหมือน onboarding doc, skill ที่ถูกเรียกเฉพาะงาน, memory search, Discord thread, subagent, handoff file แล้วค่อยมี script มารับช่วงต่อ

.md คือของที่ทำให้ AI ตั้งหลักได้

ผมไม่ได้อยากให้ AI ตื่นมาแล้วเดาเองทุกครั้งว่าต้องทำตัวยังไง เลยเอาของสำคัญไปเขียนไว้ใน `.md` เหมือน onboarding doc ของทีม เวลา session เริ่ม มันจะมี project context บางส่วนถูกโหลดเข้ามาให้ก่อน

ไฟล์พวกนี้ไม่ได้มีไว้สวยๆ มันเป็นตัวตั้งต้นว่า AI ควรทำงานแบบไหน คุยกับใคร ใช้อะไรเป็น source of truth และอะไรที่ห้ามทำเองถ้ายังไม่ได้ approve

จุดสำคัญคือ `.md` แต่ละตัวไม่ได้ถูกใช้เหมือนกันหมด บางตัวโหลดตอนเริ่ม session บางตัวต้อง search ก่อน บางตัว script อ่านเอง ไม่ได้หวังให้ AI จำเอาเองหมด

skill ไม่ได้ยัดทุกอย่างเข้าหัว AI ตลอด

ถ้าใส่ rule ทุกอย่างเข้าไปใน prompt เดียว มันดูครบดี แต่พอใช้จริง context รกมาก ผมเลยชอบวิธีที่ skill ถูกเรียกเฉพาะตอนงานตรงกับ description มากกว่า

เช่น ถ้าผมขอเขียนบทความ public แบบนี้ มันควรไปอ่าน `sekapp-editorial-article` ก่อน เพราะ skill นั้นเก็บ voice ของผมไว้ว่าไม่ให้เขียนแบบ AI summary ไม่ให้ใช้คำอย่าง “สรุปสั้นๆ” หรือ conclusion ที่ดู report เกินไป

แต่ถ้างานเป็น Docker ก็ไม่ควรโหลด skill บทความเข้ามาให้รก มันควรอ่าน Docker skill แทน ถ้างานสร้าง skill ก็อ่าน skill-creator ถ้างาน GitLab ก็อ่าน GitLab manager อะไรประมาณนี้

ผมมอง skill เหมือน plugin ฝั่ง context มากกว่า ไม่ได้แปลว่ามันต้องไปยิง action ข้างนอกเสมอไป มันช่วยบอก AI ว่า “งานนี้ควรคิดแบบไหน” โดยไม่ต้องยัดทุกอย่างไว้ใน prompt เดียว

thread, context, subagent คือการแบ่ง RAM ของงาน

ผมเริ่มมอง context เหมือน RAM ของทีม AI ถ้าโยนทุกอย่างเข้าไปหมด มันไม่ได้ฉลาดขึ้นเสมอ บางทีมันแค่สับสนขึ้น เพราะใน context มีทั้งเรื่องเก่า เรื่องใหม่ rule หลายชุด และข้อความที่อาจไม่เกี่ยวกับ task นี้เลย

ใน Discord ผมเลยชอบให้มี thread หรือห้องตามงาน/ตาม department มากกว่า ทุกอย่างไม่ควรไหลรวมกันหมด เพราะพอ context ยาวเกินไป agent จะเริ่มจำผิด จับประเด็นผิด หรือเอา requirement คนละงานมาปนกัน

งานใหญ่ก็เหมือนกัน ไม่จำเป็นต้องให้ agent ตัวเดียวแบกตั้งแต่คิด product ยัน deploy ถ้างานใหญ่พอ ก็ควรแตก subagent หรือแยก role ให้ทำเฉพาะส่วน แล้วค่อยส่งผลลัพธ์กลับมาให้ตัวหลักรวมอีกที

ถ้า context คือพื้นที่ทำงาน เราต้องจัดโต๊ะให้มัน ไม่ใช่กวาดทุกอย่างในบริษัทมาเทใส่โต๊ะเดียวแล้วหวังว่ามันจะหยิบถูกชิ้นทุกครั้ง

ส่วน create project ผมไม่ให้ AI ไปสร้างเองมั่วๆ

ตรงนี้ผมตกหล่นใน draft แรกเหมือนกัน ทั้งที่มันเป็น flow สำคัญมาก เพราะตอนสร้าง project ใหม่ ผมไม่ได้ให้ AI ไปกดสร้าง Linear, GitLab, Discord thread แยกเองมั่วๆ แล้วค่อยมาบอกว่าเสร็จ

ของ SekApp ตอนนี้ให้วิ่งผ่าน `project-orchestrator.py` เป็นหลักก่อน ตัวนี้ทำหน้าที่เหมือนตัวคุม ceremony ของการสร้าง project ใหม่ ต้อง plan ก่อน แล้วค่อย create หลัง manager approve

เหตุผลที่ผมชอบ flow นี้คือมันกัน AI ใจร้อน ถ้า project name ซ้ำ, originator ไม่ชัด, sponsor ไม่ชัด, หรือ thread มีโอกาสซ้ำ มันควร fail ตั้งแต่ plan mode ไม่ใช่สร้างไปแล้วค่อยตามลบทีหลัง

ตรงนี้ต่างจาก handoff flow นิดนึง handoff คือส่งงานระหว่างทีมหลัง project มีตัวตนแล้ว แต่ create flow คือทำให้ project เกิดแบบมีหลักฐานตั้งแต่วันแรก มี Linear link, GitLab repo, Discord threads และ transaction/report path ให้ย้อนดูได้

handoff คือจุดที่ AI ส่งไม้ให้ระบบ

เวลา agent ทำงานเสร็จ ผมไม่อยากให้มันจบที่ “เรียบร้อยแล้ว” ในแชท เพราะประโยคนั้นเอาไป sync อะไรต่อไม่ได้ ผมเลยให้ handoff เป็นไฟล์ `.md` ที่มี metadata ชัดๆ

ไฟล์นี้ทำหน้าที่เหมือน interface ระหว่าง AI กับระบบข้างนอก AI เขียน human-readable detail ได้ แต่ script ก็ต้องอ่าน key หลักๆ ได้ด้วย เช่น issue ไหน status จะไปไหน project อะไร ใครเป็น assignee ถัดไป

พอเป็น format แบบนี้ script ไม่ต้องเดาว่า agent หมายถึงอะไร และ manager ก็ยังเปิดอ่านเป็นภาษาคนได้ด้วย มันเลยเป็นจุดกลางที่ผมว่าค่อนข้าง practical

scripts หลังบ้านเป็นตัวรับไม้ต่อจาก AI

หลังจากมีไฟล์ มี context มี handoff แล้ว script จะเป็นคนทำงาน deterministic ที่ไม่ควรให้ AI พูดลอยๆ เช่น sync status, notify ห้อง, audit label, snapshot cost หรือเช็ค health

ตัวที่เป็นแกนสุดตอนนี้คือ `relay.sh` มันอ่าน handoff file จาก shared folder แล้วเอาข้อมูลไปส่งต่อ Discord, sync Linear status/department label แล้วค่อยย้ายไฟล์ไป `processed/` พูดง่ายๆ คือถ้า agent บอกว่าส่งงานแล้ว แต่ไม่มีไฟล์ หรือไฟล์ไม่ถูก processed เราก็ยังไม่ควรเชื่อเต็มที่

ผมชอบแยกแบบนี้เพราะ AI ทำส่วนที่ต้องคิด ส่วน script ทำส่วนที่ต้องเช็คซ้ำได้ อะไรที่ควรตรวจย้อนหลังได้ก็ให้มีไฟล์ มี log มี status ทิ้งไว้ ไม่ใช่เชื่อจากแชทอย่างเดียว

ถ้าเอามาต่อกัน งานหนึ่งชิ้นจะวิ่งประมาณนี้

สมมติ manager สั่ง feature ใหม่ใน Discord งานจะเริ่มจาก agent รับ context ของห้องนั้น อ่าน rule ที่ถูกโหลดมา ถ้าต้องใช้ skill เฉพาะทางก็ไปอ่าน skill ก่อน ถ้ามีเรื่องเก่าต้องอ้างอิงก็ search memory หรืออ่านไฟล์ที่เกี่ยวข้อง

จากนั้น agent อาจไปสร้าง/อ่าน Linear issue ไปดู GitLab repo ทำงานใน branch หรือให้ subagent ช่วยบางส่วน พอจบ stage ของตัวเองก็ไม่ควรแค่บอกว่าเสร็จ แต่ต้องเขียน handoff file ให้ script รับต่อ

พอมองแบบนี้ AI team มันไม่ใช่หลายแชทแล้ว แต่มันเป็น pipeline เล็กๆ ที่มี AI อยู่หลายจุด และมี script คอยทำให้ state ในระบบขยับจริง

อันนี้ยังต้องปรับอีกเยอะ

ตอนนี้ผมยังไม่กล้าพูดว่า flow นี้เนียนแล้วนะ หลายจุดยังต้อง audit เพิ่ม เช่น script บางตัวเป็น soft enforcement มากกว่า hard block, บาง action ยังต้องพึ่ง manager approve, บางครั้ง agent ยังลืมใส่ metadata ให้ครบ

แต่ผมเริ่มชอบทิศทางนี้ เพราะอย่างน้อยมันบังคับให้ AI ทำงานผ่านของที่ตรวจได้ ถ้าทำจริงต้องมีไฟล์ มี status มี link มี log ถ้าไม่มี ก็ไม่ต้องมานั่งเถียงกับ AI ว่ามันทำหรือยัง