Google Conductor รองรับ Antigravity: ย้าย Project Context ออกจากแชตมาไว้ใน Repo

ข่าวนี้คืออะไรในภาษาคนทำงาน

Google ประกาศว่า Conductor กำลังเปลี่ยนจาก Gemini CLI extension เป็น Conductor Plugin สำหรับ AI coding agents ครับ

Plugin แบบใหม่นี้รองรับ Antigravity CLI และ Claude Code โดย package เดียวสามารถรวม Skills, Rules, MCP servers และ Hooks ได้

แต่ส่วนที่น่าสนใจกว่าคำว่า Plugin คือวิธีเก็บ Project Context

Conductor ไม่ได้หวังให้ Agent จำทุกอย่างจาก Chat History มันย้ายข้อมูลสำคัญของงานมาอยู่ในไฟล์ Markdown ที่เก็บใน Repo และ version control ได้ เช่น:

• product.md สำหรับเป้าหมายและผู้ใช้ของ Product
• tech-stack.md สำหรับ Technology และข้อจำกัด
• workflow.md สำหรับวิธีทำงานของทีม
• spec.md สำหรับสิ่งที่จะสร้างและเหตุผล
• plan.md สำหรับขั้นตอน Implementation และสถานะงาน

Flow หลักจึงเป็น Context -> Spec & Plan -> Implement

แปลเป็นภาษาง่าย ๆ คือ ก่อนให้ Agent ลงมือเขียน Code เราทำให้มันเห็นแผนที่ของงานก่อน และแผนที่นั้นยังอยู่แม้จะปิดแชตหรือเปลี่ยน Tool

ทำไม founder/operator และทีมเล็กควรสนใจ

ทีมเล็กมักไม่ได้ขาด Tool ครับ เราขาด บริบทที่ส่งต่อได้

ตัวอย่างเช่น Founder คุยกับ AI ตอนเช้าว่าอยากเพิ่มระบบ Coupon ในหน้า Checkout อธิบายไป 20 ข้อ แล้วตอนบ่ายให้ Coding Agent อีกตัวลงมือทำ

ถ้าข้อมูลทั้งหมดอยู่ในแชตแรก Agent ตัวที่สองอาจรู้แค่ว่า “เพิ่ม Coupon” แต่ไม่รู้ว่า:

• Coupon ใช้กับ Product ไหน
• ลดแบบเปอร์เซ็นต์หรือจำนวนเงิน
• ใช้ร่วมกับโปรอื่นได้หรือไม่
• ใครมีสิทธิ์สร้าง Code
• ต้องเก็บ Audit อะไร
• Test Case ไหนห้ามพลาด
• งานแบบไหนต้องหยุดถามคนก่อน

ปัญหานี้ไม่ได้แก้ด้วย Model ใหญ่ขึ้นอย่างเดียวครับ เพราะต่อให้ Model ฉลาดมาก ถ้า Context ที่ได้รับไม่ครบ มันก็ยังตัดสินใจจากภาพที่ขาดอยู่ดี

Conductor ทำให้เห็น pattern ที่ยืมไปใช้กับ Agent ตัวอื่นได้ทันที:

ให้ Chat ใช้คุย แต่ให้ Repo ใช้จำงาน

สิ่งที่ Conductor Plugin เปลี่ยน

1) จาก Extension เฉพาะ Tool เป็น Plugin ที่พก Workflow ไปได้

ก่อนหน้านี้ Conductor ผูกกับ Gemini CLI เป็นหลัก รุ่นใหม่ถูกจัดเป็น Agent Plugin ที่รองรับ Antigravity และ Claude Code

ข่าวนี้สำคัญเพราะ Project Context ไม่ควรต้องเขียนใหม่ทุกครั้งที่ทีมเปลี่ยน Coding Agent ครับ

Tool เปลี่ยนได้ แต่ Product Goal, Architecture, Constraint และ Definition of Done ควรอยู่ที่เดิม

2) จากคำสั่งหลายขั้น เป็นการคุยที่ยังสร้าง Artifact

Google บอกว่า Conductor รุ่น Plugin ลดความจำเป็นในการจำลำดับ Command แบบแข็ง ๆ ผู้ใช้สามารถคุยเรื่อง Feature ตามธรรมชาติ ขณะที่ Plugin ช่วยอัปเดต Context, Spec และ Plan ในเบื้องหลัง

จุดนี้ต้องอ่านให้ถูกครับ

“คุยง่ายขึ้น” ไม่ได้แปลว่า “ไม่ต้องมีโครงสร้าง” สิ่งที่ทำให้ Workflow นี้ต่างจากการคุยเล่นกับ Chatbot คือ สุดท้ายต้องมีไฟล์ที่เปิดอ่าน Diff และ Review ได้

3) จาก Chat History เป็น Repository Memory

Chat History เหมาะกับการคิดสด แต่ไม่เหมาะเป็นแหล่งข้อมูลหลักของโปรเจกต์ระยะยาว

Repo มีข้อได้เปรียบชัดกว่า:

• คนในทีมเปิดอ่านได้
• Agent หลายตัวใช้ Context ชุดเดียวกันได้
• ดู Diff ได้ว่า Requirement เปลี่ยนตรงไหน
• ย้อนกลับได้เมื่อแผนเริ่มหลุด
• ผูกกับ Code Review และ Test ได้

นี่คือเหตุผลที่ spec.md และ plan.md มีค่ามากกว่าคำตอบยาว ๆ ในแชตครับ

ทดลองกับ Workflow วันนี้อย่างไร

ไม่ต้องย้ายทั้งทีมไปใช้ Spec-Driven Development เต็มรูปแบบในวันแรก

เริ่มจาก Feature หรือ Bug หนึ่งงาน แล้วทำ 5 ขั้นนี้

ขั้นที่ 1: เลือกงานที่มีของส่งชัด

ตัวอย่างที่เหมาะ:

• เพิ่ม Field ใหม่ใน CRM
• แก้ Checkout ที่ Coupon ใช้ผิด Product
• เพิ่ม Export CSV ให้หน้า Report
• ทำหน้า Admin สำหรับ Preview บทเรียน

อย่าเริ่มจากงานกว้างอย่าง “ปรับระบบให้ดีขึ้น” เพราะ Spec จะกว้างจน Review ไม่ได้

ขั้นที่ 2: เขียน Project Context สั้น ๆ

บันทึกอย่างน้อย 5 เรื่อง:

1. Product นี้ช่วยใคร
2. ปัญหาของงานนี้คืออะไร
3. Tech Stack และข้อจำกัดคืออะไร
4. ไฟล์หรือระบบไหนแตะได้
5. งานไหนต้องให้คนอนุมัติก่อน

ถ้า Context ชุดนี้ยังตอบไม่ได้ อย่าเพิ่งให้ Agent Implementation ครับ

ขั้นที่ 3: แยก Spec ออกจาก Plan

spec.md ควรตอบ ทำอะไรและทำไม

plan.md ควรตอบ ทำอย่างไรและตรวจอย่างไร

ตัวอย่าง:

spec.md
ผู้ใช้ต้องใส่ Coupon ใน Checkout ได้
Coupon ต้องใช้ได้เฉพาะ Product ที่กำหนด
ถ้า Code ไม่ถูกต้อง ต้องเห็นข้อความที่เข้าใจได้

plan.md
ตรวจ Price/Product mapping
เพิ่ม Server-side validation
เพิ่ม Error state ที่ Checkout
เขียน Test สำหรับ valid, invalid, expired และ wrong-product coupon
รัน Test และแนบผลก่อนส่ง Review

การแยกสองไฟล์นี้ช่วยให้คน Product ตรวจ Requirement ได้ โดยไม่ต้องอ่าน Implementation ทุกบรรทัด

ขั้นที่ 4: ให้คน Review ก่อนเริ่ม Code

AI ทำ Plan เร็วมาก แต่ความเร็วตรงนี้มีประโยชน์ก็ต่อเมื่อ Plan ถูกทิศ

ก่อนกด Implement ให้ถาม 4 ข้อ:

• Scope ครบหรือยัง
• มี Edge Case สำคัญหายไปไหม
• Test Plan พิสูจน์ Requirement ได้หรือไม่
• มี Action ไหนแตะ Production, Customer Data หรือ Billing หรือเปล่า

ถ้ายังตอบไม่ได้ ให้แก้ Plan ก่อน Code ครับ ถูกกว่าแก้ระบบทีหลังเยอะ

ขั้นที่ 5: จบงานด้วย Artifact ไม่ใช่คำว่า Done

ตอน Agent บอกว่างานเสร็จ ให้รับงานอย่างน้อย 5 อย่าง:

• รายการไฟล์ที่เปลี่ยน
• Test Result จริง
• Screenshot หรือ API Response ที่เกี่ยวข้อง
• Caveat หรือสิ่งที่ยังไม่ได้ทดสอบ
• สถานะใน plan.md ที่อัปเดตแล้ว

จากนั้นลองเปิด Session ใหม่ ให้ Agent อีกตัวอ่าน Context, Spec และ Plan แล้วสรุปว่างานอยู่ตรงไหน

ถ้ามันรับช่วงต่อได้โดยไม่ต้องเล่าใหม่ทั้งหมด แปลว่า Project Context เริ่มทำงานแล้วครับ

Operator Kit: Project Context Handoff Pack

Copy Template นี้ไปวางใน Repo แล้วใช้กับงานหนึ่งชิ้นได้เลย

A. Project Context Card

ชื่อ Project:
ผู้ใช้หลัก:
ปัญหาที่ Product แก้:
Tech Stack:
ระบบหรือไฟล์ที่เกี่ยวข้อง:
ข้อมูลที่ห้ามนำออก:
Action ที่ Agent ทำได้เอง:
Action ที่ต้องถามก่อน:
Test Command หลัก:
คนรับ Review:

B. Feature Spec

ชื่อ Feature หรือ Bug:
ทำเพื่อใคร:
ปัญหาปัจจุบัน:
ผลลัพธ์ที่ผู้ใช้ต้องเห็น:
In scope:
Out of scope:
Business rules:
Edge cases:
Definition of Done:

C. Implementation Plan

Phase 1, สำรวจ:
- ไฟล์และระบบที่ต้องอ่าน
- Assumption ที่ต้องยืนยัน

Phase 2, ลงมือ:
- งานย่อยตามลำดับ
- ไฟล์ที่คาดว่าจะเปลี่ยน

Phase 3, ตรวจ:
- Test ที่ต้องรัน
- Screenshot หรือ API proof
- Security หรือ Data check

Phase 4, ส่งต่องาน:
- สิ่งที่เสร็จแล้ว
- สิ่งที่ยังไม่เสร็จ
- Caveat
- คนที่ต้อง Approve

D. Handoff Test

ก่อนปิดงาน ให้เปิด Session ใหม่แล้วสั่งว่า:

อ่าน Project Context, spec.md และ plan.md ของงานนี้
สรุปเป้าหมาย ขอบเขต สถานะล่าสุด สิ่งที่ยังไม่เสร็จ และ Test ที่ต้องผ่าน
ห้ามแก้ Code จนกว่าจะสรุปครบและให้คน Review ก่อน

Checklist ผ่านเมื่อ:

• [ ] Agent ใหม่บอกเป้าหมายได้ถูก
• [ ] Agent ใหม่แยก In scope กับ Out of scope ได้
• [ ] Agent ใหม่รู้ว่าไฟล์หรือระบบไหนเกี่ยวข้อง
• [ ] Agent ใหม่รู้ว่า Action ไหนต้องถามก่อน
• [ ] Agent ใหม่บอก Test และ Definition of Done ได้
• [ ] คนในทีมเปิด Repo แล้วเข้าใจสถานะโดยไม่ต้องย้อนอ่านแชตทั้งหมด

ข้อจำกัดที่ควรรู้

Conductor Plugin ยังใหม่ครับ ควรลองใน Branch หรือ Repository ที่ย้อนกลับได้ก่อน ไม่ควรติดตั้งแล้วปล่อยให้แก้ Production workflow ทันที

README ของ Project ระบุด้วยว่า Spec-Driven workflow อาจใช้ Token เพิ่ม โดยเฉพาะโปรเจกต์ใหญ่ เพราะ Agent ต้องอ่าน Context, Spec และ Plan หลายไฟล์ นี่เป็นต้นทุนที่ต้องเทียบกับเวลาที่ลดลงจากการอธิบายงานซ้ำและแก้ Code ผิดทิศ

Google บอกว่า Conductor Plugin ทำผลงานดีขึ้นใน subset ที่ซับซ้อนของ TerminalBench แต่ Blog ไม่ได้ให้คะแนนหรือรายละเอียด Methodology ครับ ผมจึงมอง Claim นี้เป็นเหตุผลให้ลอง ไม่ใช่หลักฐานว่าทุกทีมจะได้ผลดีขึ้นแน่นอน

สุดท้าย Spec-Driven Development ไม่ได้ช่วยถ้า Spec เขียนกว้าง คลุมเครือ หรือไม่มีคน Review

Artifact ที่มีคุณค่าไม่ใช่ไฟล์ Markdown ที่ยาวที่สุด แต่คือไฟล์ที่ทำให้คนและ Agent ตัวถัดไปตัดสินใจได้ถูกขึ้น

สรุป

ข่าว Conductor รองรับ Antigravity ดูเหมือนข่าว Plugin สำหรับ Developer ครับ แต่บทเรียนจริงใช้ได้กับทุกทีมที่เริ่มให้ AI Agent รับงานต่อเนื่อง

อย่าฝาก Product Goal, Constraint และ Definition of Done ไว้ในแชตอย่างเดียว

ให้ Chat เป็นที่คุย ให้ Repo เป็นที่จำ และให้ spec.md กับ plan.md เป็นสะพานส่งต่องานระหว่างคน, Session และ Agent

Tool เปลี่ยนได้ครับ แต่งานไม่ควรลืมว่ากำลังทำไปเพื่ออะไร