Solo-Engine V4.1 Final: ลดกฎซ้ำซ้อน ตีกรอบเครื่องมือให้จริง และส่งมอบโค้ดอย่างตรวจสอบได้

คำตัดสินโดยสรุป

V4 แก้ปัญหาหลักได้ถูกจุด ไม่ว่าจะเป็นการห้ามสร้างเรื่องว่ามีเครื่องมือหรือผลทดสอบ, การป้องกันไม่ให้ส่งเพียงโค้ดบางส่วนแล้วอ้างว่าส่งมอบครบ, และการไม่ยกระดับ ADR เป็นสถานะยอมรับโดยไม่มีหลักฐาน แต่ยัง ไม่ควรนำไปใช้แบบเดิมทันที

ปัญหาของ V4 ไม่ใช่ขาดความสามารถ หากแต่เป็นเรื่อง กฎหนาแน่นเกินไปและซ้ำกันหลายจุด, นิยามสถานะกระจัดกระจาย, และยังมีพื้นที่กำกวมในคำว่า “zero dependency”, “automatic loop”, “complete code” และ “BMAD multi-agent”

คำแนะนำฉบับจบคือ Solo-Engine v4.1 Final: เก็บวงจรวิจัย → ตัดสินใจ → วิศวกรรมของ V4 ไว้ แต่ย้ายรายละเอียด SOP และเทมเพลตไปไว้ในคลังความรู้ ขณะที่กติกาที่ละเมิดไม่ได้ต้องอยู่ในคำสั่งหลักของ Gem ด้วยเสมอ

V4 ทำได้ดีตรงไหน

• แยก /ana-solo สำหรับการวิเคราะห์และตัดสินใจ ออกจาก /ana-bmad สำหรับการวางแผน พัฒนา และตรวจสอบงาน
• ใช้ฉลาก FACT, INFERENCE, ASSUMPTION และ UNKNOWN เพื่อไม่ปะปนข้อเท็จจริงกับการอนุมาน
• ระบุชัดว่าไม่อาจเสกความสามารถด้านค้นเว็บ, ตัวรันโค้ด, ระบบไฟล์ หรือ Git ขึ้นมาจากพรอมป์ต์ได้
• แยก “เขียนโค้ดครบ” ออกจาก “คอมไพล์และทดสอบผ่านจริง”
• เพิ่ม scenario watermark, Algorithm-Fit, Preflight, backpressure เมื่อแก้ล้มเหลว และ State Reconcile
• ทำให้ ADR เป็นวัตถุการตัดสินใจที่มีวงจรชีวิต แทนที่จะเป็นเอกสารประกอบสวย ๆ
• รองรับการแบ่งส่งโค้ดตามขอบไฟล์เต็ม จึงไม่ตัดกลางไฟล์เมื่อคำตอบยาว
• ใช้บทบาทแบบ BMAD เพื่อทบทวนหน้าที่ภายใน Gem เดียวได้อย่างเหมาะสม แต่ไม่ควรอ้างว่าเทียบเท่ากับ runtime แบบหลายเอเจนต์จริง เอกสาร BMAD แยก Agent, Skill, Workflow และขั้นตอนทดสอบไว้เป็นกลไกการทำงานชัดเจน 11014

จุดที่ V4 ต้องแก้ก่อนใช้งานจริง

1) คำสั่งหลักพึ่งพาคลังความรู้มากเกินไป

กฎสำคัญบางส่วนถูกฝากไว้ใน knowledge base ทั้งที่ไม่ควรสมมติว่าไฟล์ทุกฉบับจะถูกเรียกคืนมาได้ครบทุกครั้ง กฎเรื่อง โค้ดครบ, ความจริงของการยืนยันผล, ขอบเขตเครื่องมือ และเงื่อนไขการปิดงาน ต้องอยู่ในคำสั่งหลักด้วย

2) กฎซ้ำมาก ทำให้การทำตามกฎอ่อนลง

เมื่อหลายไฟล์นิยามสถานะ การตรวจสอบ dependency, ADR และเงื่อนไขเสร็จงานซ้ำกัน โมเดลมีโอกาสหยิบบางกฎมาใช้แต่ตกหล่นอีกส่วนหนึ่งได้ง่ายกว่าเดิม ทางแก้คือมี “แหล่งอ้างอิงหลัก” เพียงแห่งเดียวสำหรับกฎแข็ง และให้เอกสารอื่นขยายวิธีปฏิบัติแทน

3) ต้องตีกรอบ “Automatic Loop” ให้ตรงกับความสามารถจริง

Gem ไม่ได้มีงานเบื้องหลัง เทอร์มินัลถาวร หรือความสามารถทำงานข้ามเซสชันเพียงเพราะคำสั่งเขียนว่าทำอัตโนมัติได้ ดังนั้น loop ต้องจำกัดอยู่ใน:

• คำตอบหรือเซสชันปัจจุบัน
• ขอบเขตที่ผู้ใช้อนุมัติในปัจจุบัน
• เครื่องมือที่เปิดให้ใช้งานจริงในเซสชันนั้น
• งบการลองใหม่ที่ระบุชัด
• สถานะ WAITING_VERIFICATION หากไม่มีตัวรันจริง

4) “Zero dependency” ต้องนิยามให้เป็นภาษาวิศวกรรม

คำนี้ไม่ควรปนกันระหว่าง “ไม่ต้องมี runtime”, “ไม่ใช้แพ็กเกจภายนอก” และ “ไม่อ้างไฟล์ local ที่ผู้ใช้ไม่ได้ให้มา” V4.1 ควรแยกเป็น:

• ไม่มี dependency ที่ไม่ได้ประกาศ
• โดยปริยายไม่เพิ่ม third-party dependency
• หากเพิ่ม local dependency ใหม่ ต้องส่งมอบให้ครบ
• runtime, SDK และแพลตฟอร์มโฮสต์เป็นเงื่อนไขของสภาพแวดล้อมที่ต้องระบุ ไม่ใช่สิ่งที่ซอร์สโค้ดลบล้างได้

5) “โค้ดครบ” ต้องต่างกันระหว่างโปรเจ็กต์ใหม่กับโปรเจ็กต์เดิม

สำหรับโปรเจ็กต์ใหม่ ต้องส่งไฟล์ทั้งหมดที่ทำให้โปรเจ็กต์ปิดครบเป็นหน่วยที่รันได้ สำหรับโปรเจ็กต์เดิม ต้องส่งเนื้อหาเต็มของทุกไฟล์ที่เพิ่มหรือแก้ไข ส่วนไฟล์ baseline ที่ผู้ใช้ให้มาแล้วและไม่ได้แก้ ไม่จำเป็นต้องพิมพ์ซ้ำ

อย่างไรก็ดี หากมีไฟล์เดิมที่ขาดหายและมีผลต่อการคอมไพล์หรือสัญญา interface ต้องขอข้อมูลเพิ่ม ห้ามเดาชื่อเมธอดหรือโครงสร้างของระบบเอง

6) แยก “ส่งมอบ” ออกจาก “งานวิศวกรรมเสร็จ”

ควรเก็บสถานะอย่างน้อยสามแกน:

• DELIVERY_STATUS: ส่งไฟล์ครบหรือยัง
• VERIFICATION_STATUS: มีการคอมไพล์หรือทดสอบจริงหรือไม่
• ENGINEERING_STATUS: มีสิทธิ์อ้างได้หรือไม่ว่างานวิศวกรรมเสร็จแล้ว

การพิมพ์ไฟล์ครบไม่เท่ากับพิสูจน์ว่าโค้ดใช้ได้

7) Tavily ต้องผูกกับเครื่องมือจริง ไม่ใช่ข้อความในพรอมป์ต์

search_depth=advanced เป็นพารามิเตอร์จริงของ Tavily Search สำหรับการค้นหาที่ต้องการความเกี่ยวข้องและความละเอียดสูงขึ้น แต่แลกกับ latency ที่มากขึ้น และอาจมีต้นทุนเพิ่ม 2411 ดังนั้น Gem จะกล่าวว่าใช้ Tavily หรือพารามิเตอร์นี้ได้ต่อเมื่อมีเครื่องมือ Tavily ที่ใช้งานได้จริงในเซสชันนั้นเท่านั้น

8) เปลี่ยนชื่อ “SEO ออกข้อมูลมีค่า” เป็น Value Extraction

การทำงานเริ่มต้นควรคือการค้นหาและสกัดว่าอะไรมีความหมายต่อการตัดสินใจของผู้ใช้ ไม่ใช่ SEO โดยอัตโนมัติ ควรเข้าสู่ SEO จริง ๆ เมื่อผู้ใช้ขอเรื่องคีย์เวิร์ด การจัดทำดัชนี การ crawl โครงสร้างเว็บไซต์ อันดับ หรือการเพิ่มประสิทธิภาพคอนเทนต์โดยชัดเจน

9) “รายงานข้อสรุปความจริง” ต้องไม่อ้างว่าเป็นความจริงสัมบูรณ์

ชื่อเดิมเก็บไว้ได้หากผู้ใช้ต้องการ แต่คำจำกัดความต้องเป็น ภาพรวมของข้อเท็จจริงที่หลักฐานปัจจุบันรองรับ พร้อมข้อจำกัด สมมติฐาน สิ่งที่ยังไม่ยืนยัน และหลักฐานความล้มเหลว

ตารางตัดสิน

คะแนน 0–5 และแปลงเป็น 100 คะแนน เป็นการประเมินการตั้งค่าในครั้งนี้ ไม่ใช่ benchmark การรันจริงของ Gemini Gem

มิติ	น้ำหนัก	V4	V4.1 Final
ขอบเขต Gem และความจริงของเครื่องมือ	25%	4.0	4.8
คุณภาพการอ่านสามรอบ, DM และ DR	20%	4.5	4.8
ราวกันความเสี่ยงทางวิศวกรรมและ backpressure	20%	4.6	4.8
โค้ดครบและ dependency closure	15%	4.6	4.9
ความกระชับและโอกาสทำตามคำสั่งได้จริง	10%	2.8	4.5
การกู้สถานะและการกระทบยอดหลักฐาน	10%	4.2	4.7
คะแนนรวมถ่วงน้ำหนัก	100%	84.2	95.5

สูตรคำนวณ:

$$
Score = 20\sum_{i=1}^{n}w_i s_i,
\qquad
\sum_{i=1}^{n}w_i=1
$$

ข้อคัดค้านที่หนักที่สุด และคำตอบ

ข้อคัดค้าน: V4 เข้มงวดพอแล้ว การปรับต่ออาจเป็นเพียงการแต่งรูปแบบ

คำตอบ: จุดเสี่ยงของ V4 ไม่ได้อยู่ที่ความครบถ้วนเชิงทฤษฎี แต่อยู่ที่โอกาสปฏิบัติตามจริง เมื่อคำสั่งหลัก SOP และเทมเพลตพูดถึงสถานะและกฎชุดเดียวกันซ้ำหลายที่ จะเกิดความเสี่ยงต่อการอ้างกฎบางส่วน สถานะขัดกัน และข้อความยาวจนเบียดพื้นที่ส่งโค้ด

การทดสอบหักล้างขั้นต่ำ

V4.1 Final ควรถูกถือว่าล้มเหลวทันที หากพบพฤติกรรมใดพฤติกรรมหนึ่งต่อไปนี้:

1. ไม่มี executor แต่ Gem อ้างว่าโค้ดทดสอบผ่านแล้ว
2. interface ในโปรเจ็กต์เดิมหายไป แต่ Gem แต่ง interface ขึ้นเองและบอกว่าคอมไพล์ได้
3. งาน bugfix เปลี่ยน public signature แต่ไม่ยกระดับเป็น structural preflight
4. ส่งไฟล์ค้างกลางไฟล์ แต่ตั้งสถานะการส่งมอบเป็น COMPLETE
5. Tavily ใช้งานไม่ได้ แต่ Gem อ้างว่าได้ค้นด้วย search_depth=advanced

ข้อสรุปฉบับจบ

• ตัวเลือกที่แนะนำ: Solo-Engine v4.1 Final
• ตัวเลือกสำรอง: V4 เหมาะสำหรับทดลองภายใน แต่ไม่ควรเป็น configuration ระยะยาว
• การยกระดับสำคัญ: ลดกฎซ้ำซ้อน, ทำให้คำสั่งหลักครอบคลุมกฎที่ละเมิดไม่ได้, และผูกทุกคำกล่าวอ้างกับเครื่องมือและหลักฐานที่มีจริง
• เงื่อนไขสำหรับการขยายในอนาคต: หากย้ายไปใช้ Gemini API Managed Agent, MCP หรือ code sandbox แบบถาวร ควรเพิ่ม Runtime Adapter แยกต่างหาก แทนการยัดคำอธิบายเครื่องมือเพิ่มเข้าไปในคำสั่งหลักของ Gem

สิ่งที่ยังเปิดอยู่

ยังไม่มีหลักฐานยืนยันว่า Gem ปัจจุบันของผู้ใช้เชื่อมต่อ Tavily, ตัวคอมไพเลอร์ของภาษาเป้าหมาย, MCP หรือ persistent workspace แล้วหรือไม่ ดังนั้น configuration ที่ดีต้องปฏิบัติต่อความสามารถเหล่านี้เป็น UNKNOWN จนกว่าจะเห็นเครื่องมือหรือบันทึกการทำงานจริง