spinny:~/writing $ vim codex-multi-agent-workflows.md
1~2ครั้งแรกที่ตัวแทนเขียนโค้ดแก้ไขข้อบกพร่องให้กับคุณ ปฏิกิริยาจะเหมือนเดิมเกือบทุกครั้ง: เป็นส่วนผสมของความกระตือรือร้นและความสงสัย เยี่ยมเลย แต่แล้วคุณก็มองความแตกต่างแล้วถามตัวเองว่า "โอเค แต่เขาสัมผัสอะไรกันแน่? ฉันจะเชื่อใจเขาได้หรือเปล่า? พรุ่งนี้เขาจะทำแบบเดิมอีกไหม"3~4นั่นคือจุดที่ฉันคิดว่าส่วนที่น่าสนใจเริ่มต้นขึ้น ไม่ใช่ตอนที่เอเจนต์เขียนฟังก์ชัน แต่เมื่อมีความสามารถเพียงพอที่จะทำงานทั้งชิ้น: อ่านพื้นที่เก็บข้อมูล สร้างแพตช์ รันการทดสอบ เปิด PR กลับมาอีกครั้งหลังจากแสดงความคิดเห็นในการรีวิว Codex กำลังเคลื่อนไปในทิศทางนั้นอย่างแม่นยำ: งานเบื้องหลัง, แผนผังงานแยก, เบราว์เซอร์แบบรวม, ระบบอัตโนมัติ, ปลั๊กอิน, หน่วยความจำ และการควบคุมสิทธิ์ที่ชัดเจนยิ่งขึ้น5~6ประเด็นไม่ใช่การจินตนาการถึงอนาคตที่ไม่มีใครอ่านโค้ดอีกต่อไป มันจะเป็นอนาคตที่เลวร้ายและค่อนข้างไร้เดียงสา ประเด็นคือการหาวิธีทำงานร่วมกับตัวแทนที่สามารถทำอะไรได้มากมายโดยไม่ต้องปล่อยให้พวกเขาทำทุกอย่าง7~8## การเปลี่ยนแปลงนิสัย9~10ด้วยการเติมข้อความอัตโนมัติแบบเดิม คุณจะควบคุมพวงมาลัยอยู่เสมอ AI แนะนำบรรทัด คุณตัดสินใจแล้ว อย่างไรก็ตาม ความสัมพันธ์ระหว่างตัวแทนเปลี่ยนไป คุณตั้งเป้าหมายให้เขา และเขาก็ต้องผ่านหลายขั้นตอนด้วยตัวเขาเอง11~12สิ่งนี้ทรงพลัง แต่มันเปลี่ยนปัญหา คำถามไม่ได้มีแค่ "โปรแกรมโมเดลสามารถได้หรือไม่" อีกต่อไป คำถามกลายเป็น:13~14- ฉันให้ขอบเขตที่เล็กพอกับเขาหรือไม่?15- คุณรู้วิธีตรวจสอบผลลัพธ์หรือไม่?16- ฉันทำงานในสภาพแวดล้อมที่โดดเดี่ยวหรือไม่?17- การตรวจสอบขั้นสุดท้ายยังคงมีมนุษยธรรมและระมัดระวังหรือไม่?18~19ขั้นตอนการทำงานที่ดีจะมีลักษณะเช่นนี้มากกว่าไม้กายสิทธิ์:20~21```mermaid22flowchart LR23 Idea[งานของมนุษย์] --> Scope[วัตถุประสงค์ขนาดเล็กที่ตรวจสอบได้]24 Scope --> Agent[เจ้าหน้าที่ในเวิร์คทรีที่แยกออกจากกัน]25 Agent --> Checks[ทดสอบ, ขุย, สร้าง, เบราว์เซอร์]26 Checks --> Review[การตรวจสอบโดยมนุษย์]27 Review --> Merge[ผสานหรือทำซ้ำใหม่]28 Review --> Iterate[ความคิดเห็นที่แม่นยำเกี่ยวกับความแตกต่าง]29 Iterate --> Agent30```31~32ฟังดูโรแมนติกน้อยกว่า "ตัวแทนสร้างทุกอย่าง" แต่ได้ผลดีกว่ามาก และยังเป็นวิธีการทำงานของทีมที่ดีกับมนุษย์อีกด้วย เช่น งานที่ชัดเจน การตอบรับอย่างรวดเร็ว และความรับผิดชอบที่ชัดเจน33~34## พรอมต์ที่ดีเกือบจะเป็นตั๋วที่ดี35~36ข้อความแจ้งที่อันตรายที่สุดคือข้อความที่คลุมเครือแต่มั่นใจ: "แก้ไขหน้าใบแจ้งหนี้", "ปรับปรุงสถาปัตยกรรม", "ล้างโมดูลการตรวจสอบสิทธิ์" คำขอเหล่านี้เป็นคำขอที่ฟังดูมีประสิทธิภาพและสร้างความแตกต่างอย่างมาก แต่แล้วคุณจะพบว่าตัวเองกำลังทำวิชาโบราณคดี37~38ข้อความที่เป็นประโยชน์นั้นน่าเบื่อกว่า ตัวอย่างเช่น: ใช้การส่งออก CSV สำหรับหน้าใบแจ้งหนี้ โดยรู้ว่าตารางอยู่ใน `app/(dashboard)/invoices/page.tsx` ข้อความค้นหาอยู่ใน `src/server/invoices.ts` และมีรูปแบบที่คล้ายกันอยู่แล้วใน `app/(dashboard)/reports`39~40จากนั้นเพิ่มข้อจำกัดที่ชัดเจน: อย่าเปลี่ยนสคีมาฐานข้อมูล อย่าเพิ่มการพึ่งพาหากยูทิลิตี้ขนาดเล็กเพียงพอ คงสไตล์ UI ที่มีอยู่ไว้ และปิดด้วยการยืนยัน: `npm test -- invoices` และ `npm run build`41~42บรีฟประเภทนี้ไม่ใช่การ "อธิบายให้ AI เข้าใจได้ดีขึ้น" มันทำหน้าที่เหนือสิ่งอื่นใดเพื่อให้คุณชัดเจนยิ่งขึ้นว่าคุณกำลังมอบหมายอะไร หากคุณไม่สามารถจดบันทึกไว้อย่างเป็นรูปธรรม อาจเป็นไปได้ว่างานยังไม่พร้อมสำหรับตัวแทน43~44## สามงานที่ฉันเต็มใจมอบหมาย45~46อย่างแรกคืองานที่ทำซ้ำแต่ตรวจสอบได้: การเพิ่มการทดสอบ การย้ายการเรียกไปยัง API ภายในใหม่ การอัปเดตการนำเข้า การแทนที่ส่วนประกอบที่เลิกใช้แล้ว แก้ไขข้อผิดพลาด TypeScript ที่นี่ตัวแทนสามารถประหยัดเวลาหลายชั่วโมงและสามารถควบคุมความเสี่ยงได้47~48ประการที่สองคืองานสำรวจ: "ค้นหาตำแหน่งที่คำนวณผลรวมนี้" "อธิบายให้ฉันฟังว่าทำไมการทดสอบนี้จึงเปราะบาง" "สร้างข้อผิดพลาดขึ้นมาใหม่และบอกฉันว่าไฟล์ใดดูเหมือนจะได้รับผลกระทบ" แม้ว่าจะไม่สร้างแพตช์ในทันที แต่ก็สามารถทำการลาดตระเวนที่เป็นประโยชน์ได้49~50ประการที่สามคืองานบำรุงรักษาที่เกิดซ้ำ: การอัปเดตการพึ่งพาเล็กน้อย การล้างแฟล็กฟีเจอร์เก่า สรุป PR ที่ถูกบล็อก การตรวจสอบ TODO ที่ถูกลืม มันไม่หรูหรา แต่เป็นงานที่มีแนวโน้มที่จะกองพะเนินเทินทึก51~52## สามอาชีพที่มนุษย์เก็บเอาไว้53~54การตัดสินใจเกี่ยวกับผลิตภัณฑ์ยังคงเป็นมนุษย์ หากการเปลี่ยนแปลงเปลี่ยนวิธีการชำระเงินของผู้ใช้ ลบข้อมูล ดูราคา หรือทำความเข้าใจการอนุญาต ฉันต้องการผู้รับผิดชอบ55~56ขอบเขตด้านความปลอดภัยยังสมควรได้รับความสนใจจากมนุษย์ เช่น การรับรองความถูกต้อง บทบาท โทเค็น การบันทึกข้อมูลที่ละเอียดอ่อน การย้ายฐานข้อมูล ตัวแทนสามารถช่วยดำเนินการได้ แต่ไม่จำเป็นต้องเป็นผู้มีอำนาจตัดสินใจแต่เพียงผู้เดียว57~58ในที่สุดฉันก็เก็บทุกสิ่งที่ต้องใช้รสนิยมทางสถาปัตยกรรมของมนุษย์ เจ้าหน้าที่สามารถเสนอการปรับโครงสร้างใหม่ได้ แต่การทำความเข้าใจว่าสิ่งที่เป็นนามธรรมนั้นมีความจำเป็นจริง ๆ หรือว่าเราเพียงแค่แก้ไขปัญหาที่ไม่มีอยู่จริงหรือไม่นั้นยังคงเป็นงานอยู่59~60## การตรวจสอบนี้ไม่ใช่ทางเลือก61~62สิ่งล่อใจเมื่อตัวแทนเก่งก็คือการเชื่อถือสีเขียวของ CI มันเข้าใจได้ เมื่อปัญหาเริ่มต้นขึ้นเช่นกัน63~64ฉันมักจะดูอย่างน้อยห้าสิ่ง:65~661. แพตช์แก้ไขเฉพาะงานที่ร้องขอหรือไม่?672. เขาสัมผัสไฟล์ที่ไม่เกี่ยวข้องกับมันหรือไม่?683. การทดสอบครอบคลุมถึงพฤติกรรมใหม่ๆ หรือแค่โอกาสแห่งความสุข?694. รหัสเป็นไปตามรูปแบบท้องถิ่นหรือไม่705. มีการจัดการข้อผิดพลาดเช่นเดียวกับส่วนที่เหลือของโครงการหรือไม่71~72เมื่อมีสิ่งผิดปกติเกิดขึ้น คำติชมจะต้องมีความเฉพาะเจาะจง “ซ่อมมัน” ขี้เกียจ ดีกว่า: ยูทิลิตี้นี้ทำซ้ำ `parseMoney` ลงใน `src/lib/money.ts`; ใช้ฟังก์ชันนั้นซ้ำ เพิ่มการทดสอบสำหรับกรณี EUR และไม่เปลี่ยน API สาธารณะของโมดูลการเรียกเก็บเงิน73~74ตัวแทนจะตอบสนองต่อความคิดเห็นเล็กๆ น้อยๆ และตรวจสอบได้ดีกว่ามาก ประชาชนก็เช่นกัน75~76## Guardrails คุ้มค่ากับความพยายาม77~78หากตัวแทนสามารถอ่านไฟล์ เขียนโค้ด และดำเนินการคำสั่งได้ ก็ควรถือเป็นกระบวนการที่มีประสิทธิภาพ ไม่จำเป็นต้องหวาดระแวง คุณต้องการสุขอนามัย79~80ใช้แผนผังหรือสาขาแยกกัน คุณจึงสามารถเปรียบเทียบความแตกต่าง ทิ้งการทดลองที่ล้มเหลว และไม่ปะปนงานของตัวแทนกับสิ่งที่คุณกำลังทำอยู่81~82จำกัดสิทธิ์ คำสั่งเช่น `rg`, `git diff`, `npm test` และ `npm run build` นั้นค่อนข้างจะฟรี การปรับใช้ การย้ายฐานข้อมูล การเข้าถึงข้อมูลลับ และคำสั่งทำลายล้างจะต้องชัดเจน83~84ลดการเข้าถึงเครือข่ายเมื่อคุณไม่ต้องการมัน สำหรับงานหลายอย่าง เอกสารอย่างเป็นทางการ การลงทะเบียนแพ็คเกจ และบริการภายในเฉพาะก็เพียงพอแล้ว พื้นที่ผิวน้อยลง ความประหลาดใจน้อยลง85~86ติดตามการกระทำ เมื่อแพตช์มาถึงในการตรวจสอบ คุณควรจะสามารถสร้างพรอมต์ คำสั่งที่ดำเนินการ การทดสอบที่ผ่านการทดสอบ และไฟล์ที่แก้ไขใหม่ได้ ไม่ใช่เพื่อสร้างระบบราชการ แต่เพื่อให้สามารถเข้าใจสิ่งที่เกิดขึ้นหากมีอะไรผิดพลาด87~88## วิธีง่ายๆ ในการเริ่มต้นเป็นทีม89~90หากผมแนะนำเจ้าหน้าที่เข้าสู่ทีมเล็กๆ ผมจะเริ่มโดยไม่มีการปฏิวัติครั้งใหญ่91~92ฉันจะสร้างป้ายกำกับ `agent-ready` สำหรับปัญหาที่มีขอบเขตชัดเจน ฉันจะเพิ่มเทมเพลตที่มีคำสั่งบริบท ข้อจำกัด และการยืนยัน ฉันจะขอประชาสัมพันธ์เล็กๆ น้อยๆ ควรจะไม่เกินร้อยบรรทัด ฉันจะต้องมีการทดสอบหรือภาพหน้าจอเพื่อดูการเปลี่ยนแปลงที่มองเห็นได้ และเหนือสิ่งอื่นใด ฉันจะให้บุคคลที่รับผิดชอบในการควบรวมกิจการ93~94หลังจากผ่านไปสองสัปดาห์ ฉันจะดูข้อมูล: งานไหนที่เร็วขึ้นจริงๆ, งานไหนที่รีวิวหนักมาก, ซึ่งการแจ้งเตือนนั้นสร้างความสับสน, ส่วนไหนของโค้ดเบสที่เปราะบางเกินกว่าจะมอบหมายได้95~96เป็นแนวทางที่น่าตื่นเต้นน้อยกว่า "ตั้งแต่วันนี้เราจะทำทุกอย่างกับตัวแทน" แต่เป็นวิธีที่ช่วยให้คุณเข้าสู่สัปดาห์ที่สามได้โดยไม่ต้องเสียใจ97~98## ส่วนที่เป็นมนุษย์มากที่สุด99~100สิ่งที่น่าตลกก็คือ ยิ่งตัวแทนที่เป็นอิสระมากขึ้น ทักษะคลาสสิกก็มีความสำคัญมากขึ้นเท่านั้น: การเขียนตั๋วที่ดี การตัดทอนเล็กๆ การสร้างการทดสอบ การอ่านความแตกต่าง การสื่อสารการแลกเปลี่ยน ตัวแทนเร่งคนที่รู้วิธีทำงานได้ดีอยู่แล้ว ยังขยายความโกลาหลของผู้ที่มอบหมายไม่ดีด้วย101~102ไม่ ฉันไม่เห็นว่าเวิร์กโฟลว์แบบหลายตัวแทนเป็นทางลัดในการหยุดทำงานด้านวิศวกรรม ฉันมองว่าสิ่งเหล่านี้เป็นวิธีในการเปลี่ยนพลังงานไปยังส่วนต่างๆ ที่มีความสำคัญมากขึ้น เช่น การตัดสินใจว่าจะสร้างอะไร ตรวจสอบให้แน่ใจว่ามันใช้งานได้ ทำให้ระบบเข้าใจได้103~104เจ้าหน้าที่สามารถสร้างเพื่อนร่วมงานแบบอะซิงโครนัสที่ยอดเยี่ยมได้ แต่เพื่อให้เป็นประโยชน์สำหรับเพื่อนร่วมงานที่ไม่พร้อมกัน จำเป็นต้องมีบริบท ขอบเขต และการทบทวน เช่นเดียวกับคนอื่นๆ105~106## แหล่งข้อมูลที่เป็นประโยชน์107~108- [Codex สำหรับ (เกือบ) ทุกอย่าง - OpenAI](https://openai.com/index/codex-for-almost-everything/)109- [ใช้งาน Codex อย่างปลอดภัยที่ OpenAI](https://openai.com/index/running-codex-safely/)110- [ขอแนะนำ Codex - OpenAI](https://openai.com/index/introducing-codex/)111- [มีอะไรใหม่ในตัวแทนการเข้ารหัส GitHub Copilot](https://github.blog/ai-and-ml/github-copilot/whats-new-with-github-copilot-coding-agent/)112~
NORMAL · codex-multi-agent-workflows.md [readonly]112 lines · :q to close