พรอมต์ตั้งต้น AGENTS.md สำหรับรัน AI coding agent หลายตัวร่วมกันบน codebase เดี่ยว/หลาย codebase (EstreGenesis)

 (github.com/SoliEstre)
1 คะแนน โดย soliestre 13 일 전 | 4 ความคิดเห็น | แชร์ทาง WhatsApp

ในโปรเจกต์เดียว

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Gemini (Antigravity)
  • Cline
  • Windsurf
  • Continue

เมื่อรัน AI coding agent หลายตัวพร้อมกันเพื่อกระจายการใช้โทเค็น (ลดค่าใช้จ่ายให้ต่ำที่สุด)
CLAUDE.md กับ .cursor/rules/, GEMINI.md มักจะค่อย ๆ แยกทางกันไปคนละทิศละทาง
EstreGenesis คือไลบรารี seed prompt สำหรับ bootstrap แบบ AI Native ที่สร้างขึ้นมาเพื่อแก้ปัญหานั้น

https://github.com/SoliEstre/EstreGenesis

เพียงส่ง seed file หนึ่งไฟล์เป็นข้อความแรกในแชต โดยจะ

  • คัดลอกเนื้อหาแล้ววางลงไป,
  • ระบุเป็น local path,
  • แนบไฟล์มา, หรือ
  • อธิบายผ่านแชตเพื่อบอกตำแหน่งไฟล์แบบอ้อม ๆ

ก็ได้

จากนั้น agent จะ

  • bootstrap โปรเจกต์ใหม่ให้เป็นโครงสร้าง AGENTS.md แบบ single source of truth + ไฟล์ bridge แยกตามแต่ละเครื่องมือ หรือ
  • ตรวจสอบโปรเจกต์เดิมที่มีไฟล์กฎกระจัดกระจายอยู่แล้ว แล้ว migrate ไปเป็นโครงสร้างเดียวกัน

สามารถเลือกใช้ได้ 1 แบบจาก 3-tier (Master / Lite / Compact) ตามระดับความลึกที่ต้องการ

  • Lite เป็นค่าเริ่มต้น
  • ถ้าเป็นสไตล์ที่ทุ่มโทเค็นหนัก ๆ (เน้นคุณภาพด้วยโมเดลระดับบนอย่าง Opus 4.7, GPT 5.5 เป็นต้น)
    หรืออยากให้ harness แข็งแรงขึ้นอีกเมื่อใช้โมเดลขนาดเล็กกว่า (Sonnet, Haiku) ให้ใช้ tier แบบ Master
  • ในทางกลับกัน ถ้าอยากให้ seed มีอิทธิพลน้อยที่สุด ให้เลือก tier แบบ Compact

มีให้ในรูปแบบ คู่ภาษาอังกฤษ/เกาหลี
seed ทั้งสองภาษาถูกดูแลให้ตรงกันทั้ง phase, migration และคู่มือการปฏิบัติงาน ดังนั้นถ้าเป็นทีมสองภาษาก็สามารถวางคู่ทั้งสองภาษาไว้พร้อมกันได้

แพตเทิร์นหลักมี 4 อย่าง:

  1. AGENTS.md SSoT + bridge แบบบางสำหรับแต่ละเครื่องมือ เพื่อป้องกันความโกลาหลของกฎ
  2. .agent/_coordination/ เพื่อป้องกันการชนกันระหว่างการแก้ไขพร้อมกัน
  3. .agent/_lessons/ เพื่อไม่ให้การดีบัก 3 ชั่วโมงกลับมาเกิดซ้ำ และทำให้รอบถัดไปจบได้ใน 30 วินาที
  4. การตัดสินใจสำคัญใช้ลูป Research → Report → Plan แบบบังคับ เพื่อขับเคลื่อนการพัฒนาด้วยการวิจัยที่แข็งแรง

และสิ่งที่เพิ่มเข้ามาใน v1.6.0 ครั้งนี้คือ นโยบายประมาณการ agent-time vs human-time
เพราะ AI ส่วนใหญ่เวลาออกแผนมักประเมินระยะเวลาโดยอิงนักพัฒนามนุษย์จนพองเกินจริง 5~10×
ดังนั้นในช่วง bootstrap Phase 0 ตอนเลือก execution pace mode จึงกำหนดล่วงหน้าได้จาก

  • Cautious 2~4×
  • Proactive 5~6×
  • Burst 6~8×
  • Sprint 9~10×

เมื่อกำหนดไว้ก่อน
ก็จะรายงานการประเมินทั้งหมดโดยแยกเป็น agent work time + human review time + elapsed calendar duration
ระหว่างดำเนินโปรเจกต์ก็เปลี่ยนโหมดได้ และยังใช้ _lessons/ ปรับเทียบจากค่าจริงได้ด้วย

และหนึ่งในนโยบายทางเลือกสำคัญคือรูปแบบการแยก repo ของแต่ละโปรเจกต์ที่เชื่อมกัน (เช่น FE/BE) ออกจาก repo สำหรับเอกสารการพัฒนาโดยเฉพาะที่ใช้กำกับภาพรวม

** Antigravity หรือ Github Copilot เป็นต้น ไม่สามารถเข้าถึงไฟล์นอก working folder ได้ ดังนั้นจึงใช้วิธีวาง source repo แต่ละตัวไว้ใต้ document repo แล้วเพิ่มโฟลเดอร์เหล่านั้นลงใน .gitignore เพื่อแยก git scope

เมื่อทำแบบนี้จะได้ document repo ที่เน้นไฟล์ .md ซึ่งแม้ source จะเป็น public repo ก็ยังทำให้เอกสารการพัฒนาเป็น private และควบคุมขอบเขตการเปิดเผยได้

โดยเฉพาะใน Claude Project หากสร้างโปรเจกต์ไว้แล้วดึง document repo นี้เข้าไปในไฟล์ของโปรเจกต์ผ่านการเชื่อม GitHub เพื่อผูกเป็น project knowledge ก็จะได้สภาพแวดล้อมที่ทั้งแชตและ deep research ทำงานบนพื้นฐานเอกสารของโปรเจกต์ได้ (ทุกครั้งที่ push repo ต้องกดปุ่ม refresh ในโปรเจกต์และรอซิงก์)
เมื่อใช้งานทั้ง coding agent และ agent ที่ทำ deep research ได้ควบคู่กัน หากมีประเด็นที่ต้องการ deep research ก็สามารถขอ prompt สำหรับมอบหมาย deep research แล้วให้ Claude Project รันงานนั้น
จากนั้นนำผลลัพธ์ไปไว้ที่ /archive/<วันที่>_<หัวข้อ> ใน document repo แล้วให้ agent ใน IDE ช่วยทบทวนและสรุปรวบรวม ก็จะช่วยยกระดับการพัฒนาโปรเจกต์ได้มาก
ยิ่งไปกว่านั้น ยังใช้แชตใน Claude Project เพื่อปรึกษาเรื่องการสร้างรายได้และธุรกิจ (กฎหมาย สิทธิบัตร ฯลฯ) ได้ด้วย จึงอยากแนะนำแพตเทิร์นนี้

repo นี้คือการสรุปองค์ความรู้ที่สั่งสมระหว่างการทำโปรเจกต์ AI Native จริงจังโปรเจกต์ที่สองของผม โดยรัน 3 agent พร้อมกันคือ Antigravity + Claude Code + GitHub Copilot และค่อย ๆ ปรับปรุงจากความผิดพลาดซ้ำ ๆ และจุดที่ใช้งานไม่สะดวกให้ออกมาเป็น seed
นอกจากนี้ยังดึงแพตเทิร์นการใช้งานที่มีประโยชน์จากโปรเจกต์อื่น ๆ ของผมมารวมกันและค่อย ๆ ปั้นเป็น snowball ต่อไป

และไม่จำเป็นต้องเป็น coding agent เท่านั้น แม้โยนให้ agent อย่าง Hermes ก็ยังดูดซับเฉพาะส่วนที่เหมาะกับตัวเองแล้วนำไปใช้ได้ดี ดังนั้นจึงมองได้ว่าแทบจะเป็น seed อเนกประสงค์

อนึ่ง ไลเซนส์คือ Apache 2.0

ยินดีรับ feedback, issue และข้อเสนอ bridge สำหรับเครื่องมือ AI อื่น ๆ

บทความที่เกี่ยวข้อง

4 ความคิดเห็น

 
kurthong 13 일 전

ก่อนอื่นขอบคุณที่แนะนำโปรเจกต์ดี ๆ นะครับ เรื่องนี้เป็นสายที่ผมสนใจเหมือนกัน
คุณจัดระเบียบแพตเทิร์นไว้ได้ดีมากครับ ผมอ่านบทความแล้วมีอยู่สองจุดที่สงสัย เลยขอคอมเมนต์ถามไว้ครับ
ข้อแรก - ต้นทุนสะสมของ _lessons/ ถ้า lessons สะสมจาก 100 ไปจนถึงราว ๆ >500 รายการ ต้นทุนของการ grep แล้วไล่อ่านทั้งไฟล์ก็น่าจะเพิ่มขึ้นตามสัดส่วน อยากทราบว่าถ้าเป็นโปรเจกต์แบบ AI Native พอจะมีข้อมูลการวัดไหมครับ ว่าตั้งแต่จุดวิกฤตราวไหน ต้นทุนเริ่มต้นของแต่ละ task ถึงเริ่มกลายเป็นภาระ
เพราะส่วน v1.3 RAG การปรับดัชนีให้เหมาะสม ดูแล้วสุดท้ายก็เป็นแค่ Markdown metadata เลยรู้สึกว่ายังไม่ใช่วิธีแก้ปัญหาเชิงแก่นแท้ครับ

ข้อที่สอง - จุดที่ไฟล์เดียวกันถูกโหลดซ้ำตามจำนวนเอเจนต์เวลารันหลายเอเจนต์พร้อมกัน ตัวอย่างนี้เป็นฐานดีไซน์แบบ 3 เอเจนต์ แต่ถ้าแต่ละเซสชันต้องอ่านทั้ง AGENTS.md + rules.md + architecture.md + STATE.md + lessons กันหมด แบบนี้ตำแหน่งที่ตั้งใจจะกระจายโทเค็น กลับกลายเป็นคูณต้นทุนแทนหรือเปล่าครับ
ส่วนนี้ไม่ทราบว่าคุณแก้ไว้ยังไง หรือถ้ายังไม่ได้แก้ มีแนวคิดว่าจะจัดการอย่างไรบ้าง ผมสนใจครับ
 
soliestre 13 일 전

คำตอบข้างต้นเป็นสิ่งที่ผมสั่งไว้ในพรอมป์โดยตรงตอนทำ seed harness engineering และตอบแบบฉับพลันจากส่วนที่ผมจำได้อย่างชัดเจน
ส่วนรายละเอียดวิธีรับมือกับการสะสมของ lessons แบบเฉพาะเจาะจงนั้น เป็นส่วนที่เอเจนต์ซึ่งรวบรวมซีดได้ตรวจทานระหว่างกระบวนการ build ซีด แล้วเติมรายละเอียดและสะท้อนเข้าไปเอง (เป็นส่วนที่ดำเนินการไปแล้วในโปรเจกต์ที่ทำก่อนจะกลั่นเป็นซีด)
ผมเลยคิดว่าแทนที่จะตอบเอง ควรถามเอเจนต์ที่รวบรวมซีดซึ่งเข้าใจโครงสร้างจริงมากกว่า จึงกลับมาถึงบ้านแล้วไปถามความเห็นเกี่ยวกับชุดถามตอบข้างต้นครับ

คำตอบที่สรุปมาให้มีดังนี้:

  1. แท็ก grep — ค้นหาโดยบีบขอบเขตด้วยแท็กที่เกี่ยวกับบริบทงาน ไม่ได้ไล่อ่าน lessons ทั้งหมด
  2. ดัชนี _lessons/README.md — ใช้ชื่อเรื่อง·แท็ก·สรุป 1 บรรทัดเป็นตัวกรองรอบแรกก่อน grep
  3. ยกระดับแพตเทิร์น — lessons ที่เกิดซ้ำจะถูกย้ายไปลงหลักใน docs/troubleshooting/ และมีการควบคุมตามธรรมชาติด้วยเพดานโฟลเดอร์ดัชนีที่ 50+ รายการ

Q2 ก็อยู่ในบริบทเดียวกัน:

  • การใช้งานแบบ concurrent ไม่ได้มีเป้าหมายหลักเพื่อประหยัดโทเค็น แต่เพื่อป้องกันการชนกันและป้องกัน rule drift เป็นหลัก

เขาว่าอย่างนั้นครับ

ถ้าเป็นเป้าหมายเพื่อกระจายโทเค็น วิธีที่ผมยกเป็นตัวอย่างไว้ข้างบนก็น่าจะเป็นแพตเทิร์นที่ตรงเป๊ะครับ
 
soliestre 13 일 전

ตอนนี้ผมลองไล่ดูโปรเจกต์ที่กำลังทำอยู่ พบว่า lessons สูงสุดมีอยู่ 16 รายการครับ
และเพราะมีการติดป้ายกำกับส่วนของผลกระทบและ Severity ไว้ด้วย จึงดูว่าน่าจะรองรับการสะสมได้ในระดับหนึ่ง
แต่ถ้าสะสมมากกว่านั้น ก็น่าจะต้องคิดแผนรองรับเอาไว้ครับ

ในกรณีของผม ผมไม่ได้รันการทดสอบสำหรับ seed แยกต่างหาก
และไม่ได้เป็นกรณีที่นำไปลองใช้กับโปรเจกต์ระดับเดโม แต่เป็นการนำไปใช้และปรับแต่งไปพร้อมกันในโปรเจกต์ที่กำลังพัฒนาอย่างจริงจังอยู่ จึงไม่มีข้อมูลการวัดผลแยกต่างหากครับ
ส่วนการปรับแต่ง RAG index ให้เหมาะสม ตอนนี้ใช้กับ repo เอกสารพัฒนาที่เน้น Markdown เป็นหลัก จึงถูกปรับใช้ไว้ในระดับปัจจุบันนี้
(* เป็นส่วนที่นำมาใช้โดยมีเป้าหมายเพื่อการปรับให้เหมาะสมเมื่อเชื่อมต่อ repo เอกสารพัฒนาของ Claude Project)

สำหรับประเด็นที่สอง โดยพื้นฐานแล้วผมไม่ได้แนะนำให้ใช้งานพร้อมกันแบบเรียลไทม์จริง ๆ ครับ
สมมติฐานหลักคือเลือกใช้โมเดลที่มีประสิทธิภาพเหมาะกับวัตถุประสงค์
และนอกเหนือจากนั้น หากเป็นการทำงานในส่วนที่ต่างกันอย่างชัดเจน ก็สามารถใช้งานพร้อมกันได้
ตัวอย่างเช่น ให้ Claude รับผิดชอบส่วน PM เพื่อวางแผนการกระจายงานก่อน
จากนั้นให้ Antigravity และ Codex รันส่วน FE/BE พร้อมกันแยกกัน
แล้วให้ PM รวบรวมผลลัพธ์และวางแผนรอบถัดไปอีกครั้งในลักษณะนี้ครับ

และ ณ ตอนนี้ ผมไม่ได้อยู่ในสถานการณ์ที่ต้องประหยัดโทเค็น ดังนั้นจึงรันทุกอย่างใน master seed ด้วยโมเดลระดับบนทั้งหมด
แนวทางการกระจายโทเค็นจึงเป็นการเลือกแพลนที่คุ้มค่าต่อราคาของแต่ละแพลตฟอร์มเอเจนต์ และสมัครแพลนที่คุ้มค่าของแพลตฟอร์มอื่นเพิ่มเติมเช่นกัน เพื่อขยายแบบแนวนอน
ถ้าเป้าหมายคือการประหยัดโทเค็นอย่างเคร่งครัด ณ เวลานี้ ผมคงไม่ค่อยแนะนำให้ใช้ seed นี้ครับ
 
soliestre 13 일 전

ขออ้างอิงไว้ก่อนว่า ขีดจำกัดความจุไฟล์ของ Claude Project (ความรู้ของโปรเจกต์) อยู่ที่ราว 10MB ดังนั้น repo จึงจำเป็นต้องเป็นเนื้อหาที่เน้นข้อความเป็นหลัก
แน่นอนว่า UI ฝั่ง Claude Project สามารถยกเว้นบางไฟล์ได้ ดังนั้นถ้าแยกเป็นโฟลเดอร์ไว้หรือมีจำนวนไฟล์ไม่มาก ก็อาจยังใช้งานได้ไม่มีปัญหา