เวิร์กโฟลว์การเขียนโค้ดด้วย AI คืออะไร
เวิร์กโฟลว์การเขียนโค้ดด้วย AI คือวิธีที่ทำซ้ำได้ในการใช้ AI ตลอดงานเขียนซอฟต์แวร์โดยไม่ต้องละทิ้งดุลยพินิจทางวิศวกรรม นักพัฒนาเป็นผู้กำหนดความหมายของความสำเร็จและตรวจสอบการเปลี่ยนแปลงที่สำคัญแต่ละครั้ง Agent เขียนโค้ดจะตรวจสอบโปรเจกต์ก่อนแล้วเสนอแนวทาง หลังจากได้รับการอนุมัติ มันจึงสามารถแก้ไขไฟล์ที่เกี่ยวข้องและรันการตรวจสอบของโปรเจกต์ได้
เหตุใดการเขียนโค้ดด้วย AI แบบไม่มีโครงสร้างจึงสร้างงานเพิ่มมากขึ้น
การเขียนโค้ดด้วย AI แบบไม่มีโครงสร้างให้ความรู้สึกรวดเร็ว เพราะโค้ดปรากฏขึ้นทันที แต่ต้นทุนที่ซ่อนอยู่จะมาทีหลัง เมื่อนักพัฒนาต้องคลี่คลายสมมติฐานหรือซ่อมแซมการเปลี่ยนแปลงที่ลุกลามเกินขอบเขตของคำขอเดิม
การวางแผนและการดำเนินการเกิดขึ้นพร้อมกัน
เมื่อคำขอคลุมเครือ Agent จะต้องตัดสินใจว่าฟีเจอร์ควรทำงานอย่างไรในขณะที่กำลังเขียนโค้ดอยู่แล้ว การตัดสินใจเหล่านั้นอาจไม่ตรงกับสิ่งที่นักพัฒนาตั้งใจไว้ ตัวอย่างเช่น หากคุณบอกว่า “เพิ่มปุ่มสลับโหมดมืด” Agent จะไม่รู้ว่าปุ่มนี้ควรอยู่ตรงไหน หรือควรจดจำตัวเลือกนี้ไว้หลังจากผู้ใช้ปิดแอปหรือไม่
พรอมป์ที่กว้างเกินไปทำให้ตรวจสอบการเปลี่ยนแปลงได้ยาก
คำขอที่กว้างจะกระตุ้นให้ agent เปลี่ยนแปลงส่วนต่าง ๆ ที่เชื่อมโยงกันในโปรเจกต์พร้อมกันหลายจุด แพตช์ที่ได้อาจใหญ่เกินกว่าที่นักพัฒนาจะเข้าใจได้อย่างมั่นใจ แม้ว่าแต่ละไฟล์จะดูสมเหตุสมผลเมื่อพิจารณาแยกกัน ตัวอย่างเช่น “สร้างหน้าตั้งค่า” อาจส่งผลกระทบทั้งต่ออินเทอร์เฟซและวิธีการจัดเก็บค่ากำหนด
บริบทที่ขาดหายทำให้ได้โค้ดทั่ว ๆ ไป
coding agent ไม่สามารถทำตามข้อกำหนดของโปรเจกต์ที่มันไม่เคยเห็นมาก่อนได้ หากไม่มีไฟล์ที่เกี่ยวข้องหรือคำสั่งของ repository มันอาจสร้าง abstraction ใหม่ขึ้นมาทั้งที่มีอยู่แล้ว หรืออาจใช้ API ที่ไม่ตรงกับเวอร์ชันของ dependency ที่ติดตั้งไว้
การสร้างโค้ดที่รวดเร็วซ่อนต้นทุนของการแก้ไขซ้ำ
เวลาในการสร้างโค้ดไม่ใช่เวลาในการส่งมอบงาน แพตช์ที่ได้ภายในหนึ่งนาทีอาจยังต้องใช้เวลาทั้งบ่ายในการดีบัก ตัวชี้วัดที่ดีกว่าคือเวลาตั้งแต่มีข้อกำหนดที่ชัดเจนจนถึงการเปลี่ยนแปลงที่ผ่านการตรวจสอบและทีมงานยินดีจะดูแลรักษาต่อ
ภาพรวมของเวิร์กโฟลว์การเขียนโค้ดด้วย AI
เวิร์กโฟลว์ด้านล่างนี้ให้นักพัฒนาเป็นผู้ควบคุมการตัดสินใจ ในขณะที่มอบหมายงานตรวจสอบและงานพัฒนาที่ทำซ้ำได้ให้กับ agent
| ขั้นตอน | หน้าที่ของมนุษย์ | หน้าที่ของ AI | ผลลัพธ์ |
|---|---|---|---|
| กำหนดเป้าหมาย | กำหนดเป้าหมายและข้อจำกัด | ระบุจุดที่ยังคลุมเครือ | ข้อกำหนดที่ผ่านการยอมรับ |
| สำรวจ | ยืนยันขอบเขตงาน | ตรวจสอบไฟล์และดีเพนเดนซีที่เกี่ยวข้อง | แผนที่บริบท |
| วางแผน | อนุมัติสถาปัตยกรรมและข้อแลกเปลี่ยน | สร้างแผนงานตามลำดับขั้น | แผนที่ผ่านการตรวจทาน |
| ลงมือทำ | ควบคุมขอบเขตงาน | แก้ไขโค้ดอย่างตรงจุด | ดิฟฟ์ที่พร้อมให้ตรวจสอบ |
| ตรวจสอบความถูกต้อง | กำหนดพฤติกรรมที่คาดหวัง | รันการทดสอบและตรวจดูข้อผิดพลาด | หลักฐานผลการทดสอบ |
| ทบทวน | ตัดสินใจขั้นสุดท้าย | เปิดเผยความเสี่ยงและความไม่สอดคล้อง | การเปลี่ยนแปลงที่อนุมัติแล้ว |
| ปล่อยใช้งาน | อนุมัติการผสานรวม | สรุปงานที่ทำและความเสี่ยงที่เหลืออยู่ | ตรวจสอบการเปลี่ยนแปลงพร้อมหลักฐานการปล่อยใช้งาน |
Kimi Code สามารถรองรับลูปการทำงานนี้ได้ด้วยการตรวจสอบไฟล์ใน repository ทำการแก้ไขที่ได้รับการอนุมัติ และรันคำสั่งตรวจสอบของโปรเจกต์
ขั้นตอนที่ 1: กำหนดผลลัพธ์ก่อนขอให้เขียนโค้ด
อธิบายพฤติกรรมที่ต้องการก่อนที่จะกำหนดวิธีการ implement ระบุผู้ใช้หรือระบบที่ได้รับผลกระทบ กำหนดขอบเขตของงาน และเพิ่มเกณฑ์การยอมรับที่สามารถตรวจสอบได้หลังการเปลี่ยนแปลง
ลองพิจารณาตัวอย่างง่าย ๆ สมมติว่าคุณต้องการเพิ่ม dark mode ให้กับเว็บแอปที่มีอยู่แล้ว คุณอาจให้คำขอนี้กับ coding agent:
agent สามารถดำเนินการตามนั้นได้ แต่มันต้องเติมข้อกำหนดที่ขาดหายไปด้วยตัวเอง มันอาจวางปุ่มสลับไว้ผิดตำแหน่งในอินเทอร์เฟซ หรือใช้ dark mode กับเพียงหน้าเดียว โค้ดที่สร้างขึ้นอาจทำงานได้ในทางเทคนิค แต่กลับให้ประสบการณ์ผู้ใช้ที่ผิดพลาด
พรอมป์ที่มีประโยชน์มากกว่าจะกำหนดผลลัพธ์ไว้ก่อนที่ agent จะเริ่มแก้ไข:
เวอร์ชันนี้ให้เป้าหมายที่ชัดเจนแก่ agent และป้องกันไม่ให้มันตัดสินใจเรื่องผลิตภัณฑ์เองโดยไม่รู้ตัว นอกจากนี้ยังให้นักพัฒนามีวิธีตรวจสอบงานที่เสร็จแล้วอย่างเป็นรูปธรรม แทนที่จะถามว่าฟีเจอร์นั้น “ดูเหมือนเสร็จแล้ว” หรือไม่ คุณสามารถตรวจสอบพฤติกรรมของมันเทียบกับข้อกำหนดที่ระบุไว้ได้
ขั้นตอนที่ 2: เลือก coding harness และโมเดลที่เหมาะสม
โมเดลเป็นตัวกำหนดว่า AI เข้าใจและให้เหตุผลเกี่ยวกับโค้ดได้ดีเพียงใด ส่วน coding harness เป็นตัวกำหนดว่าการให้เหตุผลนั้นจะกลายเป็นการเปลี่ยนแปลงที่ผ่านการตรวจสอบภายในโปรเจกต์ของคุณได้หรือไม่ การเลือกทั้งสองอย่างตั้งแต่แรกจะช่วยป้องกันไม่ให้คุณสร้างเวิร์กโฟลว์ขึ้นมารอบเครื่องมือที่ไม่สามารถรับมือกับงานได้
เลือก harness ที่สามารถทำงานให้ครบลูปได้
coding harness ที่มีประโยชน์ควรทำได้มากกว่าการสร้างโค้ดชิ้นเล็ก ๆ มันต้องมีสิทธิ์เข้าถึง repository สิทธิ์ในการแก้ไขไฟล์ และความสามารถในการรันคำสั่งที่มีอยู่แล้วของโปรเจกต์ การรองรับการวางแผนและการควบคุมการอนุมัติที่ชัดเจนก็สำคัญเช่นกันเมื่องานส่งผลกระทบต่อหลายไฟล์
จับคู่โมเดลให้เหมาะกับงาน
งานแก้ไขเล็กน้อยอาจต้องการเพียงโมเดลเขียนโค้ดที่รวดเร็ว ส่วนการดีบักที่ซับซ้อนหรือการ refactor ข้ามหลายไฟล์จะได้ประโยชน์จากความสามารถในการให้เหตุผลที่แข็งแกร่งกว่าและบริบทที่เพียงพอต่อการเข้าใจโค้ดโดยรอบ โมเดลควรทำงานได้อย่างน่าเชื่อถือกับเครื่องมือที่ harness เปิดให้ใช้งานด้วย
ใช้ Kimi Code ร่วมกับ Kimi for Coding
Kimi Code มอบ harness ที่ครบถ้วนสำหรับการพัฒนาระดับงาน มันสามารถสำรวจ repository ที่ไม่คุ้นเคย สร้างแผนก่อนแก้ไข อัปเดตไฟล์ที่เกี่ยวข้อง และรันการทดสอบกับโปรเจกต์จริง คุณสามารถใช้งานได้จาก terminal เบราว์เซอร์ หรือ IDE ที่รองรับ
สำหรับเครื่องมือเขียนโค้ดของบุคคลที่สาม แพลตฟอร์ม Kimi Code มอบโมเดลที่เสถียรอย่าง Kimi K3 โมเดลนี้สามารถอัปเกรดได้โดยไม่ต้องเปลี่ยนการตั้งค่าฝั่งไคลเอนต์ เมื่อการทำซ้ำที่รวดเร็วเป็นสิ่งสำคัญ โมเดล highspeeed จะให้ความสามารถในการเขียนโค้ดแบบเดียวกันแต่มีความเร็วในการตอบสนองสูงกว่า
Kimi Code และโมเดล Kimi เมื่อทำงานร่วมกันจะครอบคลุมทั้งสองด้านของเวิร์กโฟลว์ กล่าวคือ โมเดลรับผิดชอบการให้เหตุผลเกี่ยวกับโค้ด ในขณะที่ harness เปลี่ยนการให้เหตุผลนั้นให้เป็นการเปลี่ยนแปลงที่ตรวจสอบได้
ขั้นตอนที่ 3: ให้ coding agent ตรวจสอบโปรเจกต์
เมื่อผลลัพธ์ที่ต้องการชัดเจนแล้ว ให้ agent ค้นหาโค้ดที่ควบคุมพฤติกรรมปัจจุบัน การสำรวจควรช่วยจำกัดขอบเขตของงานก่อนที่จะมีการเปลี่ยนแปลงไฟล์ใด ๆ
เริ่มต้นด้วยคำสั่งของ repository
ให้ Agent ดูคำแนะนำของรีโพซิทอรีเองก่อนเป็นอันดับแรก ซึ่งอาจอยู่ในไฟล์ต่างๆ เช่น README.md, CONTRIBUTING.md หรือไฟล์คำสั่ง Agent รายละเอียดที่มีประโยชน์คือคำสั่งที่โปรเจกต์ใช้จริง แบบแผนของโค้ด และการกระทำที่ห้ามทำ
ใช้ prompt เช่น:
คำตอบควรระบุชื่อไฟล์คำสั่งที่อ่าน และยกคำสั่งที่เกี่ยวข้องมาอ้างอิง หากมีการเสนอคำสั่งที่ไม่ปรากฏในรีโพซิทอรี ให้ถามก่อนว่าคำสั่งนั้นมาจากไหนก่อนที่จะรัน
หาโค้ดที่เกี่ยวข้องก่อนแก้ไข
แผนที่บริบทที่มีประโยชน์ต้องระบุชื่อไฟล์เฉพาะเจาะจงและอธิบายว่าทำไมแต่ละไฟล์จึงสำคัญ การแสดงรายการไดเรกทอรีกว้างๆ นั้นไม่เพียงพอ หากคำตอบละเว้นยูทิลิตี้ที่ใช้ร่วมกันซึ่งคุณรู้ว่าเกี่ยวข้องอยู่ ให้แก้ไขแผนที่นั้นก่อนเริ่มวางแผน Agent ควรตามรอยพฤติกรรมจากจุดเริ่มต้นไปยังโมดูลที่มันพึ่งพา และควรหาการทดสอบที่มีอยู่แล้วรวมถึงการนำไปใช้งานที่คล้ายกันหากมี
เพิ่มบริบทภายนอกเมื่อจำเป็นเท่านั้น
นำเอกสารประกอบภายนอกมาใช้เมื่อโค้ดเบสไม่สามารถตอบคำถามได้ ให้ URL ของเอกสารทางการที่ถูกต้อง หรือขอให้ Agent ค้นหาแหล่งที่มาทางการเอง จับคู่เอกสารให้ตรงกับเวอร์ชันที่ติดตั้งในรีโพซิทอรี บันทึกข้อผิดพลาดและคำอธิบายปัญหาก็มีประโยชน์เช่นกัน แต่ควรลบข้อมูลรับรองตัวตนหรือข้อมูลผู้ใช้ส่วนตัวออกก่อนใส่ลงใน prompt
ก่อนอนุญาตให้แก้ไขใดๆ ให้ตรวจสอบ working tree และบันทึกการเปลี่ยนแปลงที่มีอยู่แล้ว ขั้นตอนการทำงานกับระบบควบคุมเวอร์ชันแบบเต็มรูปแบบจะกล่าวถึงใน Step 8
Step 4: แยกการวางแผนออกจากการลงมือทำ
การวางแผนและการเขียนโค้ดต้องใช้คำถามในการตรวจสอบที่ต่างกัน ระหว่างการวางแผน คุณตัดสินใจว่าทิศทางที่เสนอมาเหมาะกับระบบหรือไม่ ระหว่างการลงมือทำ คุณตรวจสอบว่าทิศทางที่อนุมัติไปแล้วนั้นถูกปฏิบัติตามอย่างถูกต้องหรือไม่
ใช้ prompt สำหรับวางแผนที่ระบุชัดเจนว่าไม่ต้องเขียนโค้ด:
ตรวจสอบแผนก่อนที่จะอนุมัติ ยืนยันว่าแผนใช้ abstraction ที่มีอยู่แล้วของโปรเจกต์ในจุดที่เหมาะสม มองหาขอบเขตที่ซ่อนอยู่ โดยเฉพาะ dependency ใหม่หรือการเปลี่ยนแปลง public API ที่ไม่ได้อยู่ในความต้องการเดิม ตรวจสอบว่าการทดสอบที่เสนอมานั้นแสดงพฤติกรรมที่ร้องขอจริงๆ ไม่ใช่แค่ทดสอบฟังก์ชันที่เพิ่งเขียนขึ้นใหม่
ผลลัพธ์ของขั้นตอนนี้คือแผนที่ได้รับการอนุมัติ มันยังไม่ถือว่า “เสร็จ” เพียงเพราะ Agent สร้างคำตอบที่ละเอียดออกมา ให้คุณแก้ไขแผนเองหรือขอให้แก้ไขใหม่จนกว่าสมมติฐานและขอบเขตไฟล์จะถูกต้อง
Step 5: แบ่งแผนออกเป็นงานย่อยที่ตรวจสอบได้
งานการลงมือทำแต่ละงานควรมีเป้าหมายที่ชัดเจนหนึ่งอย่าง และมีวิธีตรวจสอบผลลัพธ์หนึ่งวิธี วิธีนี้ช่วยให้การเปลี่ยนแปลงมีขนาดเล็กพอที่จะตรวจสอบได้ และทำให้หาสาเหตุได้ง่ายขึ้นเมื่อมีอะไรผิดพลาด
ตัวอย่างเช่น ฟีเจอร์ dark mode จาก Step 1 อาจแบ่งออกเป็นงานต่างๆ ดังนี้
ตรวจสอบ color token ที่มีอยู่และสไตล์ที่เกี่ยวข้องกับธีม
เพิ่มการตั้งค่าธีมและบันทึกตัวเลือกที่ผู้ใช้เลือก
นำธีมมืดไปใช้กับเลย์เอาต์และคอมโพเนนต์ที่ใช้ร่วมกัน
เพิ่มปุ่มสลับธีมไปยังเมนูการตั้งค่า
เพิ่มการทดสอบสำหรับการสลับและบันทึกธีมที่เลือก
ตรวจสอบหน้าหลักว่ามีปัญหาด้านภาพหรือการเข้าถึงหรือไม่
ทำงานผ่านงานเหล่านี้ตามลำดับ แทนที่จะให้ Agent implement ฟีเจอร์ทั้งหมดในครั้งเดียว สำหรับงานการ implement หนึ่งงาน ให้ใช้ prompt แบบนี้:
ผลลัพธ์ที่คาดหวังคือการเปลี่ยนแปลงโค้ดที่มีจุดมุ่งหมายชัดเจน พร้อมกับการทดสอบที่รันจริง ให้ตรวจสอบทั้งสองอย่างก่อนไปยังงานถัดไป หาก Agent เพิ่มปุ่มตั้งค่าหรือแก้ไขคอมโพเนนต์ที่ไม่เกี่ยวข้องด้วย ให้แยกหรือย้อนกลับการเปลี่ยนแปลงเหล่านั้นก่อน
เมื่อ Agent ทำงานติดขัดซ้ำๆ กับงานใดงานหนึ่ง ให้แบ่งงานนั้นให้เล็กลง ตัวอย่างเช่น ให้มันเพิ่มเฉพาะการตั้งค่าธีมก่อนที่จะ implement การบันทึกข้อมูลถาวร งานที่แคบลงจะลดจำนวนสมมติฐานที่ Agent ต้องตั้งขึ้นเอง และให้จุดตรวจสอบที่ชัดเจนขึ้นก่อนดำเนินการต่อ
Step 6: Implement ทดสอบ และตรวจสอบในลูปที่กระชับ
เมื่อแผนถูกแบ่งเป็นงานที่จัดการได้แล้ว ให้ทำทีละงานให้เสร็จ ตรวจสอบการเปลี่ยนแปลงแต่ละอย่างในขณะที่จุดประสงค์และขอบเขตของมันยังชัดเจนอยู่
ใช้ลูปต่อไปนี้สำหรับทุกงาน:
เริ่มจากการตรวจสอบ diff ยืนยันว่า Agent เปลี่ยนแปลงเฉพาะไฟล์ที่จำเป็นสำหรับงานปัจจุบันเท่านั้น หาก patch มีการ refactor ที่ไม่เกี่ยวข้องหรืองานที่วางแผนไว้สำหรับขั้นตอนถัดไปรวมอยู่ด้วย ให้ลบหรือแยกการเปลี่ยนแปลงเหล่านั้นออกก่อนรันการทดสอบ
จากนั้นให้ใช้คำสั่งตรวจสอบที่รีพอสิทอรีกำหนดไว้อยู่แล้ว ซึ่งมักพบได้ใน package.json เอกสารประกอบโปรเจกต์ หรือการตั้งค่า CI ตัวอย่างเช่น โปรเจกต์ JavaScript หรือ TypeScript ที่ใช้ npm scripts อาจมีคำสั่งลักษณะนี้:
เรียกใช้เทสต์เฉพาะจุดก่อนเพื่อให้ได้ผลตอบกลับเร็วขึ้น หากผ่าน ให้ทำการตรวจสอบในวงกว้างต่อไป การรันที่สำเร็จควรจบลงโดยไม่มีข้อผิดพลาด:
คำสั่งเหล่านี้เป็นเพียงตัวอย่างเท่านั้น อย่าคัดลอกไปใช้ในรีพอสิทอรีโดยไม่ตรวจสอบก่อนว่าโปรเจกต์นั้นใช้ package manager และสคริปต์แบบใด โปรเจกต์ Python หรือ Go จะมีกระบวนการตรวจสอบที่แตกต่างออกไป และแม้แต่โปรเจกต์ JavaScript สองโปรเจกต์ก็อาจใช้ชื่อสคริปต์ต่างกันได้
เคล็ดลับพิเศษ: นำเวิร์กโฟลว์ไปใช้จริงกับ Kimi Code
Kimi Code ทำงานในระดับงาน ไม่ใช่แค่ระดับบรรทัดถัดไป เพียงอธิบายผลลัพธ์ที่ต้องการ มันสามารถหาโค้ดที่เกี่ยวข้อง เสนอแผนการพัฒนา อัปเดตไฟล์ที่จำเป็น และรันการตรวจสอบของโปรเจกต์ได้ คุณจะได้รับการเปลี่ยนแปลงที่โฟกัสไว้ให้ตรวจสอบ แทนที่จะต้องประกอบขั้นตอนทั้งหมดด้วยตัวเอง
ทำความเข้าใจโค้ดเบสที่ไม่คุ้นเคยได้เร็วขึ้น
Kimi Code สามารถเริ่มต้นจากจุดเริ่มการทำงานแล้วไล่ตามลำดับการทำงานผ่านโมดูลที่เกี่ยวข้อง มันระบุเทสต์ที่เกี่ยวข้องและรูปแบบเดิมของโปรเจกต์ได้ ช่วยลดเวลาที่ต้องเสียไปกับการรวบรวมไฟล์ด้วยตนเองหรืออธิบายว่ารีพอสิทอรีทำงานอย่างไร
นำสิ่งอื่นนอกเหนือจากโค้ดเข้ามาในงาน
บริบทของการพัฒนามักประกอบด้วยภาพหน้าจอข้อผิดพลาด เอกสารอ้างอิงการออกแบบ แผนภูมิ หรือพฤติกรรมที่บันทึกไว้ Kimi Code สามารถใช้ข้อมูลนำเข้าแบบหลายรูปแบบควบคู่ไปกับซอร์สโค้ด ช่วยให้การพัฒนาสอดคล้องกับหลักฐานที่ใช้กำหนดงานตั้งแต่ต้น
ทดสอบการเปลี่ยนแปลงในโปรเจกต์จริง
Kimi Code สามารถรันคำสั่งเทสต์และตรวจสอบคุณภาพที่มีอยู่แล้วของรีพอสิทอรีหลังจากแก้ไข หากการตรวจสอบใดล้มเหลว มันจะอ่านข้อความข้อผิดพลาดจริงและทำงานต่อจากผลตอบกลับนั้น ทำให้คุณมั่นใจได้มากกว่าคำแนะนำโค้ดเดี่ยวๆ ที่ไม่เคยถูกรันมาก่อน
เปลี่ยนเวิร์กโฟลว์ที่ดีให้เป็นกระบวนการที่ทำซ้ำได้
Skills สามารถเก็บคำสั่งไว้สำหรับงานที่เกิดซ้ำ ขณะที่ Hooks จะเรียกใช้การกระทำที่กำหนดไว้ล่วงหน้าในจุดสำคัญ MCP เชื่อมต่อ Kimi Code เข้ากับเครื่องมือที่ทีมของคุณใช้อยู่แล้ว และ Plugins สามารถรวมความสามารถเหล่านี้เข้าด้วยกันเป็นชุดที่นำกลับมาใช้และแชร์ได้ง่ายขึ้น
ทำให้งานที่ยาวขึ้นเดินหน้าต่อไปได้
สำหรับงานที่ไม่สามารถทำให้เสร็จได้ในเซสชันสั้นๆ เดียว /goal จะกำหนดวัตถุประสงค์และเกณฑ์ความสำเร็จให้ Kimi Code ทำงานไปสู่เป้าหมายนั้น มันติดตามความคืบหน้าข้ามหลายรอบการทำงานต่อเนื่อง ช่วยให้งานเดินหน้าต่อไปได้โดยไม่ต้องระบุวัตถุประสงค์ทั้งหมดซ้ำทุกครั้ง
ขั้นตอนที่ 7: ตรวจสอบโค้ดที่สร้างโดย AI ในฐานะผู้ดูแล
ก่อนยอมรับการเปลี่ยนแปลง ให้อ่านดิฟฟ์สุดท้ายด้วยตัวเอง ตรวจสอบว่าโค้ดทำงานตามที่ร้องขอและเข้ากับโปรเจกต์เดิมหรือไม่
ความถูกต้อง
โค้ดตรงตามเกณฑ์การยอมรับหรือไม่ ตรวจสอบขั้นตอนการใช้งานปกติและกรณีข้อผิดพลาดอย่างน้อยหนึ่งกรณี ตรวจให้แน่ใจว่าเทสต์ครอบคลุมพฤติกรรมที่คุณต้องการ
สถาปัตยกรรม
โค้ดปฏิบัติตามรูปแบบที่ใช้อยู่แล้วในโปรเจกต์หรือไม่ ควรวางตรรกะไว้ในโมดูลที่เหมาะสมและหลีกเลี่ยงการทำ abstraction ที่ไม่จำเป็น
ความปลอดภัย
ตรวจสอบว่าข้อมูลนำเข้าใหม่ได้รับการตรวจสอบความถูกต้อง และมีการบังคับใช้สิทธิ์อนุญาต ตรวจให้แน่ใจว่าล็อกไม่เปิดเผยข้อมูลลับหรือข้อมูลส่วนบุคคล ตรวจสอบดีเพนเดนซีใหม่ทุกตัวก่อนยอมรับ
ความสามารถในการบำรุงรักษา
โค้ดควรเข้าใจได้โดยไม่ต้องอาศัยคำอธิบายจาก agent ชื่อควรชัดเจน และคอมเมนต์ควรอธิบายเฉพาะการตัดสินใจที่ไม่ชัดเจนอยู่แล้วจากตัวโค้ด
ขอบเขต
ยืนยันว่าดิฟฟ์มีเฉพาะการเปลี่ยนแปลงที่จำเป็นสำหรับงานปัจจุบันเท่านั้น ตัดการรีแฟกเตอร์ที่ไม่เกี่ยวข้อง การเปลี่ยนแปลงอินเทอร์เฟซที่ไม่คาดคิด และการแก้ไขรูปแบบที่ไม่จำเป็นออกไป
สรุปที่สร้างโดย agent อาจช่วยในการตรวจสอบได้ แต่ไม่สามารถทดแทนการอ่านโค้ดจริงได้ อย่าปล่อยโค้ดที่คุณอธิบายไม่ได้ออกไปใช้งาน
ขั้นตอนที่ 8: ใช้ระบบควบคุมเวอร์ชันตลอดทั้งเวิร์กโฟลว์
ระบบควบคุมเวอร์ชันช่วยให้ตรวจสอบและกู้คืนงานที่ทำร่วมกับ AI ได้ง่ายขึ้น แม้ว่าที่นี่จะแสดงเป็นขั้นตอนเฉพาะขั้นหนึ่ง แต่การป้องกันของมันเริ่มต้นก่อนที่ agent จะแก้ไขไฟล์ใดๆ เสียอีก ตรวจสอบ working tree ตั้งแต่ต้น เพื่อให้คุณสามารถแยกแยะงานที่มีอยู่เดิมออกจากการเปลี่ยนแปลงที่เกิดขึ้นระหว่างงานนี้ได้
รันคำสั่งเหล่านี้ในเทอร์มินัลที่เปิดจากรากของ repository:
git status --short
git diff --stat
git diffต้นไม้ที่เริ่มต้นสะอาดจะไม่มีผลลัพธ์ใดๆ จาก git status --short หากมีไฟล์ที่ถูกแก้ไขอยู่แล้ว ให้บันทึกไว้และแจ้ง agent ไม่ให้เขียนทับไฟล์เหล่านั้น หลังจากแต่ละงาน ให้ตรวจสอบ diff อีกครั้ง นักพัฒนาควรเป็นผู้ตัดสินใจว่าสถานะที่ตรวจสอบแล้วพร้อมสำหรับการทำ checkpoint ในระบบควบคุมเวอร์ชันหรือไม่
ใช้ branch หรือ worktree แยกต่างหากเมื่อการทดลองอาจกระทบไฟล์จำนวนมาก agent ที่ทำงานพร้อมกันไม่ควรแก้ไข working directory เดียวกัน กำหนดความเป็นเจ้าของไฟล์ที่ชัดเจนให้แต่ละสายงาน แล้วรวมเข้าด้วยกันหลังจากการตรวจสอบผ่านแล้วเท่านั้น
อย่าอนุญาตให้ coding agent เขียนประวัติใหม่ ทิ้งงานที่ทำในเครื่อง force-push หรือเผยแพร่การเปลี่ยนแปลงโดยไม่ได้รับการอนุมัติอย่างชัดเจน การกระทำเหล่านี้มีผลกระทบในวงกว้างกว่าการแก้ไขไฟล์ทั่วไป และต้องมีการตัดสินใจแยกต่างหาก
ขั้นตอนที่ 9: รักษาบริบทระหว่างเซสชันการเขียนโค้ด
งานที่ใช้เวลานานมักอยู่นานกว่าการสนทนาหนึ่งครั้ง ให้เก็บรักษาสถานะทางวิศวกรรมไว้ใน artifact ของ repository แทนที่จะพึ่งพาประวัติแชท
เก็บเอกสารฟีเจอร์แบบสั้นที่มี:
ข้อกำหนดที่ได้รับการยอมรับ
แผนการดำเนินการที่ได้รับการอนุมัติ
งานที่เสร็จแล้วและรายการ TODO ปัจจุบัน
การตัดสินใจที่เปลี่ยนแปลงแนวทางเดิม
คำสั่งที่รันไปแล้วและผลลัพธ์ล่าสุด
ความเสี่ยงที่ทราบหรือคำถามที่ยังไม่มีคำตอบ
เริ่มเซสชันใหม่ด้วย prompt สำหรับส่งต่องาน:
คำตอบควรสอดคล้องกับเอกสารและสถานะปัจจุบันของ repository แก้ไขความไม่สอดคล้องใดๆ ก่อนที่จะขอให้เซสชันใหม่ทำงานต่อ การส่งต่องานนี้ช่วยลดความจำเป็นที่ ai coding agent ต้องประกอบสถานะโปรเจกต์ขึ้นใหม่จากประวัติการสนทนาที่ไม่สมบูรณ์
วิธีการทำงานของ multi-agent AI coding workflow
multi-agent AI coding workflow กำหนดบทบาทที่แตกต่างกันให้กับ agent แต่ละตัวแยกจากกัน agent ตัวหนึ่งอาจสำรวจ repository ในขณะที่อีกตัวหนึ่งตรวจสอบ diff ที่เสร็จสมบูรณ์แล้ว คุณค่าเกิดจากการแบ่งความรับผิดชอบ ไม่ใช่จากการเปิดหลายแชทพร้อมกัน
การตั้งค่าที่ใช้งานได้จริงอาจประกอบด้วยบทบาทเหล่านี้:
Planner: เชื่อมโยงความต้องการเข้ากับโค้ดเบส และเสนอแผนการที่เรียงลำดับไว้โดยไม่แก้ไขไฟล์
Implementer: ทำงานที่มีขอบเขตแคบให้เสร็จสมบูรณ์ในพื้นที่ทำงานที่แยกออกมา
Tester: ตรวจสอบเกณฑ์การยอมรับและทำซ้ำความล้มเหลวด้วยตัวเองอย่างอิสระ
Reviewer: ตรวจสอบ diff เพื่อดูความถูกต้องหรือความเสี่ยงที่ซ่อนอยู่โดยไม่สมมติว่าการดำเนินการนั้นถูกต้อง
Human integrator: อนุมัติการตัดสินใจ ควบคุมลำดับการ merge และตรวจสอบผลลัพธ์ที่รวมกันแล้ว
multi-agent workflow จะทำงานได้ดีที่สุดเมื่องานสามารถแยกออกจากกันได้อย่างชัดเจน ให้ agent ทุกตัวใช้ข้อกำหนดที่ได้รับการอนุมัติเดียวกัน กำหนดความเป็นเจ้าของที่ชัดเจน และใช้ branch หรือ worktree ที่แยกออกมาเพื่อป้องกันความขัดแย้ง สำหรับการแก้ไขเล็กน้อยหรืองานที่ขึ้นอยู่กับไฟล์ที่เปลี่ยนแปลงเพียงไฟล์เดียว การใช้ agent ตัวเดียวมักมีประสิทธิภาพมากกว่า
Kimi Code สามารถแบ่งงานขนาดใหญ่ออกเป็น sub-agent ที่มี context อิสระจากกันได้ ด้วย Agent Swarm sub-agent หลายตัวสามารถทำงานในส่วนต่างๆ ของงานพร้อมกัน แล้วส่งผลลัพธ์ที่พบกลับไปยัง workflow หลักเพื่อตรวจสอบและรวมเข้าด้วยกัน ซึ่งช่วยลดเวลาในการทำงานในขณะที่ยังคงรักษาขอบเขตของงานและการอนุมัติขั้นสุดท้ายไว้ในการควบคุมของคุณ
เลือก workflow ตามลักษณะของงาน
ไม่ใช่ทุกงานเขียนโค้ดที่ต้องการการวางแผนในระดับเดียวกัน การแก้ไขที่เรียบง่ายสามารถดำเนินไปได้อย่างรวดเร็ว ในขณะที่การเปลี่ยนแปลงที่ซับซ้อนหรือมีความเสี่ยงต้องการการตรวจสอบมากขึ้นก่อนเผยแพร่
การเปลี่ยนแปลงเล็กน้อย: ตรวจสอบโค้ดที่เกี่ยวข้อง แก้ไขจุดเดียวอย่างเจาะจง รันการทดสอบที่เกี่ยวข้อง และตรวจสอบ diff
ฟีเจอร์ขนาดกลาง: เขียนข้อกำหนดแบบสั้น อนุมัติแผนการดำเนินการ และทำงานให้เสร็จเป็นงานย่อยๆ หลายงาน รันชุดทดสอบที่กว้างขึ้นก่อนการตรวจสอบ
การเปลี่ยนแปลงที่มีความเสี่ยงสูง: เพิ่มขั้นตอนตรวจสอบการออกแบบและแผนสำรองสำหรับการย้อนกลับ การเปลี่ยนแปลงที่เกี่ยวข้องกับการยืนยันตัวตน การชำระเงิน หรือการย้ายข้อมูล อาจต้องมีการตรวจสอบด้านความปลอดภัยและการปล่อยใช้งานแบบเป็นขั้นตอนด้วย
โปรเจกต์ที่ใช้ agent หลายตัว: ให้ agent ทุกตัวใช้สเปกเดียวกันและกำหนดความรับผิดชอบต่องานให้ชัดเจน หลังจากรวมงานของแต่ละตัวเข้าด้วยกันแล้ว ให้รันชุดทดสอบที่เกี่ยวข้องทั้งหมดอีกครั้ง
Kimi Code รองรับ workflow เหล่านี้ได้ทั้งหมด ใช้กระบวนการที่เรียบง่ายสำหรับงานง่าย ๆ แล้วเพิ่มการวางแผนและตรวจสอบมากขึ้นเมื่อการเปลี่ยนแปลงนั้นย้อนกลับได้ยากขึ้นหรือมีแนวโน้มจะส่งผลต่อผู้ใช้งานมากขึ้น
prompt สำหรับ workflow การเขียนโค้ดด้วย AI ที่นำกลับมาใช้ซ้ำได้
ใช้เทมเพลตนี้กับ coding agent ตัวใดก็ได้ ส่งให้ agent หลังจากแทนที่แต่ละช่องในวงเล็บแล้ว
คุณสามารถใช้สิ่งนี้เป็นคำสั่งเริ่มต้นใน Kimi Code ได้ อัปเดต Current phase และ Task ตามความคืบหน้าของงาน แทนที่จะใช้ prompt เดียวครอบคลุมฟีเจอร์ทั้งหมด
บทสรุป
workflow การเขียนโค้ดด้วย AI ที่เชื่อถือได้ ไม่ได้มุ่งเน้นที่การสร้างโค้ดให้ได้มากที่สุด แต่ช่วยเปิดเผยสมมติฐานที่ผิดพลาดตั้งแต่เนิ่น ๆ และทำให้แต่ละการเปลี่ยนแปลงสามารถตรวจสอบได้ Kimi Code สนับสนุนกระบวนการนี้ด้วยการอ่านและแก้ไขโค้ด รันคำสั่ง shell ดึงข้อมูลจากหน้าเว็บที่เกี่ยวข้อง และปรับการทำงานตามความคืบหน้าของงาน นักพัฒนายังคงเป็นผู้รับผิดชอบด้านสถาปัตยกรรมและการตัดสินใจปล่อยใช้งานขั้นสุดท้าย เริ่มต้นจากงานเล็ก ๆ ที่ตรวจสอบได้ แล้วเพิ่มกระบวนการเมื่อความเสี่ยงของโปรเจกต์ต้องการเท่านั้น
คำถามที่พบบ่อย
kimi, kimi web และ kimi acp