วิธีเชี่ยวชาญ Dynamic Workflows ใน Claude Code: 6 รูปแบบและ 14 ขั้นตอนที่วิศวกรของ Anthropic ใช้จริง

ผู้ใช้ Claude Code ส่วนใหญ่ยังคงเขียนเวิร์กโฟลว์ด้วยมือ พวกเขาเชื่อมต่อพรอมต์ คัดลอกผลลัพธ์ วางลงในพรอมต์ถัดไป แก้ไขสิ่งที่ผิดพลาด แล้วทำซ้ำ

9 ใน 10 คนที่สร้างเวิร์กโฟลว์ไม่เคยลองใช้ Dynamic Workflows แม้แต่ครั้งเดียว ถึงแม้ว่ามันจะเปิดตัวเมื่อสองสัปดาห์ก่อนก็ตาม

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

ติดตาม Substack ของฉันเพื่อรับข้อมูล AI ล่าสุด:

movez.substack.com

Dynamic Workflows เปิดตัวใน Claude Code เมื่อวันที่ 28 พฤษภาคม 2026 โครงสร้างพื้นฐานของ Claude Code ถูกสร้างมาสำหรับการเขียนโค้ด - และมันทำงานได้ดีสำหรับงานเขียนโค้ดส่วนใหญ่ แต่มีงานบางประเภทที่หน้าต่างบริบทเดียวเริ่มทำงานได้ไม่ดี: งานที่ใช้เวลานาน, ทำงานแบบขนานขนาดใหญ่, มีโครงสร้างสูง, หรือเป็นปฏิปักษ์

สำหรับงานเหล่านั้น ก่อนหน้านี้ Anthropic เคยสร้างโครงสร้างพื้นฐานแบบกำหนดเองขึ้นมาเอง (งานวิจัย, การตรวจสอบโค้ด, ทีมเอเจนต์) ด้วย Dynamic Workflows Claude จะเขียนโครงสร้างพื้นฐานนั้นให้คุณทันที ซึ่งสร้างขึ้นเฉพาะสำหรับงานของคุณ ในภาษา JavaScript

14 ขั้นตอน. 6 รูปแบบ. เวิร์กโฟลว์เดียวแทนที่จะเป็น 50 พรอมต์.

ส่วนที่ 1 · แนวคิดหลัก

01. เวิร์กโฟลว์คือโครงสร้างพื้นฐานที่ Claude เขียนขึ้น

โครงสร้างพื้นฐานของ Claude Code เริ่มต้นให้ Claude วางแผนและดำเนินการในหน้าต่างบริบทเดียวกัน สำหรับงานเขียนโค้ดส่วนใหญ่ นี่เป็นเรื่องที่ดี แต่สำหรับงานที่ใช้เวลานาน, ทำงานแบบขนาน, หรือเป็นปฏิปักษ์ มันเริ่มทำงานได้ไม่ดี

Dynamic Workflow คือการที่ Claude เขียนโครงสร้างพื้นฐานแบบกำหนดเองสำหรับงานนั้น - ไฟล์ JavaScript ที่มีฟังก์ชันพิเศษสองสามฟังก์ชันที่สร้างและประสานงานเอเจนต์ย่อย พร้อมกับ JavaScript มาตรฐาน (Math, JSON, Array) เพื่อประมวลผลข้อมูลที่ไหลระหว่างพวกมัน

สามสิ่งที่สิ่งนี้มอบให้คุณซึ่งโครงสร้างพื้นฐานเริ่มต้นไม่สามารถทำได้:

• การแยกเอเจนต์ต่อตัว. เอเจนต์ย่อยแต่ละตัวจะได้รับหน้าต่างบริบทของตัวเองพร้อมเป้าหมายที่โฟกัสเดียว ไม่มีการปนเปื้อนข้ามกัน
• การเลือกโมเดลต่อเอเจนต์. เวิร์กโฟลว์จะเลือกโมเดลที่เอเจนต์ย่อยแต่ละตัวใช้ - Opus สำหรับการใช้เหตุผลยาก, Haiku สำหรับการสำรวจราคาถูก, Sonnet สำหรับงานระดับกลาง
• ระดับการแยกต่อเอเจนต์. Worktree (การเช็คเอาต์ git แบบแยก) หรือ remote (ไม่มีการเช็คเอาต์) เวิร์กโฟลว์จะตัดสินใจว่าเอเจนต์แต่ละตัวต้องการอะไร

เริ่มต้นโดยการถาม Claude โดยตรง ("สร้างเวิร์กโฟลว์ที่...") หรือใช้คำสั่งกระตุ้น ultracode หากเวิร์กโฟลว์ถูกขัดจังหวะ - การกระทำของผู้ใช้, การปิดเทอร์มินัล - การกลับมาเซสชันต่อจะเริ่มจากจุดที่ค้างไว้

02. 3 รูปแบบความล้มเหลวที่เวิร์กโฟลว์แก้ไขได้

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

• ความเกียจคร้านของเอเจนต์ - Claude หยุดก่อนที่จะทำงานที่ซับซ้อนและหลายส่วนเสร็จ และประกาศว่าเสร็จหลังจากทำงานไปบางส่วน จัดการ 20 จาก 50 รายการในการตรวจสอบความปลอดภัยและเรียกส่วนที่เหลือว่า "จัดการแล้ว"
• อคติชอบตนเอง - Claude ชอบผลลัพธ์ของตัวเองเมื่อถูกขอให้ตรวจสอบหรือตัดสินตามเกณฑ์การให้คะแนน ผู้ตรวจสอบที่มีส่วนได้ส่วนเสียไม่สามารถเป็นผู้ตรวจสอบที่ยุติธรรมได้
• การเบี่ยงเบนเป้าหมาย - การสูญเสียความเที่ยงตรงต่อวัตถุประสงค์ดั้งเดิมอย่างค่อยเป็นค่อยไปในหลายๆ รอบ โดยเฉพาะอย่างยิ่งหลังจากการบีบอัด ขั้นตอนการสรุปแต่ละครั้งจะสูญเสียข้อมูล ข้อจำกัด "อย่าทำ X" จะหายไปอย่างเงียบๆ ในรอบที่ 47

เวิร์กโฟลว์แก้ไขทั้งสามอย่างนี้ในเชิงโครงสร้าง: Claude ที่แยกจากกันพร้อมบริบทของตัวเอง, เป้าหมายที่โฟกัส, และสถานะที่แยกออกจากกัน หากงานของคุณประสบปัญหารูปแบบใดรูปแบบหนึ่งเหล่านี้ - นั่นคือสัญญาณให้ใช้เวิร์กโฟลว์

03. เวิร์กโฟลว์แบบคงที่ vs แบบไดนามิก

คุณอาจเคยสร้างเวิร์กโฟลว์แบบคงที่โดยใช้ Claude Agent SDK หรือ claude -p - เพื่อประสานงานอินสแตนซ์ Claude Code หลายตัวเข้าด้วยกัน

• เวิร์กโฟลว์แบบคงที่นั้นเป็นแบบทั่วไป: เขียนครั้งเดียวเพื่อจัดการทุกกรณีขอบ มันใช้งานได้ แต่ต้องอนุรักษ์นิยม
• เวิร์กโฟลว์แบบไดนามิกนั้นแตกต่าง: Claude เขียนเวิร์กโฟลว์ นี้ สำหรับงาน นี้ โครงสร้างพื้นฐานถูกสร้างขึ้นโดยเฉพาะ ด้านล่างนี้เป็นคำถามเดียวกันที่จัดการทั้งสองวิธี:

เหตุผลที่เวอร์ชันไดนามิกชนะไม่ใช่ขั้นตอนการค้นหา - ทั้งคู่สามารถค้นหาได้

แต่มันเป็นเพราะเวิร์กโฟลว์สามารถ ปรับเปลี่ยนรูปร่างตามบริบทของคุณ: อ่านโค้ดการเรียกเก็บเงินของคุณ, ตรวจสอบแต่ละฟีเจอร์กับเอกสารของผู้ให้บริการรายใหม่จริง, กำหนดราคาตามปริมาณธุรกรรมของคุณ, และรันการตรวจสอบแบบเป็นปฏิปักษ์ "ทำไมไม่ย้าย" กับคำตอบที่เกิดขึ้นใหม่ของมันเอง

โครงสร้างพื้นฐานแบบคงที่ไม่สามารถทำเช่นนี้ได้เพราะมันไม่รู้ว่าโค้ดของคุณมีอยู่

04. API หลัก. agent(), parallel(), pipeline()

สามฟังก์ชันทำงานส่วนใหญ่ในเวิร์กโฟลว์ การรู้จักมันก็เพียงพอที่จะอ่านเวิร์กโฟลว์ใดๆ ที่ Claude เขียนให้คุณ และเพื่อกระตุ้น Claude เมื่อคุณต้องการรูปร่างที่เฉพาะเจาะจง

parallel() เป็น สิ่งกีดขวาง: มันกระจายออกไป จากนั้นรอทุกอย่างก่อนที่จะส่งคืน pipeline() เป็น สตรีมมิ่ง: แต่ละรายการไหลผ่านทุกขั้นตอนอย่างอิสระ

เลือกโดยพิจารณาจากคำถาม: ฉันต้องการผลลัพธ์ทั้งหมดก่อนที่จะทำสิ่งใดต่อไปหรือไม่? ใช่ → parallel ไม่ → pipeline (ถูกกว่า, โดยรวมเร็วกว่า)

05. จัดประเภทและดำเนินการ. กำหนดเส้นทางงานก่อนที่จะทำ

เอเจนต์ตัวจำแนกประเภทจะตัดสินใจเกี่ยวกับประเภทของงาน จากนั้นเวิร์กโฟลว์จะกำหนดเส้นทางไปยังเอเจนต์หรือพฤติกรรมต่างๆ ตามคำตอบ หรือตัวจำแนกประเภทจะทำงานในตอน ท้าย โดยจัดเรียงผลลัพธ์ดิบลงในกลุ่มสำหรับสิ่งที่จะเกิดขึ้นต่อไป

เมื่อรูปแบบนี้คุ้มค่า:

• งานมีความหลากหลาย - ประเภทย่อยที่แตกต่างกันต้องการการจัดการที่แตกต่างกัน
• คุณต้องการใช้โมเดลราคาแพงเฉพาะในที่ที่ความซับซ้อนต้องการ (ตัวจำแนกประเภทบนโมเดลราคาถูก จากนั้นกำหนดเส้นทางไปยัง Opus เฉพาะเมื่อจำเป็น)
• การแยกย่อยงานนั้นไม่ใช่เรื่องเล็กน้อยและได้รับประโยชน์จากการที่โมเดลตัดสินใจรูปร่าง

ตัวอย่าง: "อธิบายว่าโมดูล auth ทำงานอย่างไร" เอเจนต์ตัวจำแนกประเภทจะอ่านโค้ดเบสก่อน ประมาณความซับซ้อน จากนั้นกำหนดเส้นทางงานอธิบายจริงไปยัง Sonnet สำหรับโมดูล 10 ไฟล์หรือ Opus สำหรับโมดูล 100 ไฟล์ โมเดลที่เหมาะสมสำหรับงาน หลังจากที่เข้าใจงานแล้ว

06. กระจายและสังเคราะห์. หลายขั้นตอนเล็กๆ, ผลลัพธ์ที่รวมกันหนึ่งเดียว

แบ่งงานออกเป็นหลายขั้นตอนเล็กๆ รันเอเจนต์ในแต่ละขั้นตอนแบบขนาน สังเคราะห์ผลลัพธ์เป็นคำตอบเดียว

ขั้นตอนการสังเคราะห์เป็น สิ่งกีดขวาง - มันรอเอเจนต์ที่กระจายออกไปทุกตัว จากนั้นรวมผลลัพธ์ที่มีโครงสร้างของพวกมัน

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

แต่ละขั้นตอนได้รับประโยชน์จากหน้าต่างที่สะอาดของตัวเองเพื่อไม่ให้เกิดการปนเปื้อนข้ามกัน

ใช้สิ่งนี้เมื่อ:

• คุณมีรายการงานที่สามารถแจกแจงได้อย่างชัดเจน (50 ไฟล์, 200 เอนด์พอยต์, 100 รีวิว)
• แต่ละรายการเป็นอิสระ - ไม่มีรายการใดต้องการผลลัพธ์ของรายการอื่นเพื่อเริ่มต้น
• คุณต้องการคำตอบที่รวบรวมเป็นหนึ่งเดียวในตอนท้าย ไม่ใช่กองรายงานบางส่วน

1// กระจาย: หนึ่งเอเจนต์ต่อหนึ่งไฟล์ สิ่งกีดขวาง: รอทั้งหมด
2const reviews = await parallel(
3  files.map(file => () => agent(
4    `ตรวจสอบ ${file} สำหรับปัญหาด้านความปลอดภัย`,
5    { model: "haiku", schema: IssueList }
6  ))
7)
8
9// สังเคราะห์: เอเจนต์ Opus หนึ่งตัวรวมทุกอย่าง
10const report = await agent(
11    `รวมรีวิวเหล่านี้เป็นรายงานที่มีลำดับความสำคัญเดียว:\n${JSON.stringify(reviews)}`,
12  { model: "opus" }
13)

07. การตรวจสอบแบบเป็นปฏิปักษ์

นี่คือการแก้ไขเชิงโครงสร้างสำหรับอคติชอบตนเอง สำหรับเอเจนต์ที่สร้างขึ้นแต่ละตัว ให้รันเอเจนต์ที่สร้างขึ้นแยกต่างหากซึ่งตรวจสอบผลลัพธ์ของมันแบบเป็นปฏิปักษ์ตามเกณฑ์การให้คะแนน ผู้ตรวจสอบไม่เคยเห็นงานต้นฉบับ มันไม่สามารถชอบมันได้

รูปแบบนี้สำคัญที่สุดสำหรับ:

• การตรวจสอบข้อกล่าวอ้าง - ทุกข้อความที่เป็นข้อเท็จจริงในรายงานจะได้รับเอเจนต์ผู้ตรวจสอบของตัวเอง โดยตรวจสอบกับแหล่งที่มาดั้งเดิม
• การตรวจสอบโค้ด - เอเจนต์ผู้เขียนเขียนการแก้ไข เอเจนต์ผู้ตรวจสอบ (บริบทแยกต่างหาก) ตรวจสอบมัน ไม่เคยมี Claude คนเดียวกันตัดสินตัวเอง
• ประตูคุณภาพ - ก่อนที่สิ่งประดิษฐ์ใดๆ จะถูกส่งออกไป ผู้ที่เป็นปฏิปักษ์จะพยายามหากรณีที่อ่อนแอที่สุดที่ต่อต้านมัน หากผู้เป็นปฏิปักษ์ทำไม่ได้ คุณก็ส่งออกไป

กฎการจับคู่: ผู้ตรวจสอบควรรู้ เฉพาะ เกณฑ์การให้คะแนนและสิ่งประดิษฐ์เท่านั้น ไม่ใช่ใครเป็นผู้ผลิต มิฉะนั้นความชอบตนเองจะกลับมาแอบแฝงผ่านคำใบ้ในพรอมต์

08. สร้างและกรอง

สร้างแนวคิดจำนวนหนึ่งในหัวข้อ จากนั้นกรองตามเกณฑ์การให้คะแนนหรือโดยการตรวจสอบ ลบรายการที่ซ้ำกัน ส่งคืนเฉพาะแนวคิดที่มีคุณภาพสูงสุดและผ่านการทดสอบแล้ว

ที่ซึ่งรูปแบบนี้โดดเด่น:

• การระดมสมอง - ชื่อผลิตภัณฑ์ 30 ชื่อ จากนั้นผู้ตรวจสอบจะกำจัดคำซ้ำซาก, ความขัดแย้งของเครื่องหมายการค้า, และสัทศาสตร์ที่อ่อนแอ คุณเห็น 3 ชื่อ
• การสร้างสมมติฐาน - 5 แนวทางที่แตกต่างกันสำหรับปัญหา จากนั้นแต่ละแนวทางจะได้รับคะแนนตามข้อจำกัดของคุณ ผู้ชนะสมควรได้รับมัน
• การออกแบบโซลูชัน - 5 แนวทางที่แตกต่างกันสำหรับปัญหา จากนั้นแต่ละแนวทางจะได้รับคะแนนตามข้อจำกัดของคุณ ผู้ชนะสมควรได้รับมัน

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

09. การแข่งขัน. การเปรียบเทียบแบบคู่ดีกว่าการให้คะแนนแบบสัมบูรณ์

แทนที่จะแบ่งงาน ให้เอเจนต์แข่งขันกันในงานนั้น สร้างเอเจนต์ N ตัวที่แต่ละตัวพยายามทำงานเดียวกันโดยใช้วิธีการที่แตกต่างกัน จากนั้นตัดสินผลลัพธ์แบบคู่จนกว่าจะมีผู้ชนะหนึ่งเดียว

การตัดสินเชิงเปรียบเทียบมีความน่าเชื่อถือมากกว่าการให้คะแนนแบบสัมบูรณ์ - โดยเฉพาะอย่างยิ่งสำหรับงานที่ขึ้นอยู่กับรสนิยม

เหตุใดสิ่งนี้จึงดีกว่าการเรียงลำดับตามคะแนน: การพยายามเรียงลำดับ 1,000 รายการในพรอมต์เดียวล้มเหลวในสองด้าน - คุณภาพลดลง และมันจะไม่พอดีกับบริบท การแข่งขันจะแบ่งสายการแข่งขันออกเป็นเอเจนต์ใหม่ๆ โดยแต่ละตัวเปรียบเทียบเพียงสองรายการ

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

10. วนซ้ำจนเสร็จ

สำหรับงานที่มีปริมาณงานที่ไม่ทราบแน่ชัด ให้วนซ้ำการสร้างเอเจนต์จนกว่าจะตรงตามเงื่อนไขการหยุด - ไม่มีการค้นพบใหม่, ไม่มีข้อผิดพลาดในบันทึกอีกต่อไป, ทฤษฎีได้รับการยืนยัน - แทนที่จะรันจำนวนรอบที่แน่นอน

รูปแบบนี้คือคำตอบสำหรับ "ทำต่อไปจนกว่าจะเสร็จจริง":

• การดีบักการทดสอบที่ไม่แน่นอน - ทำซ้ำ, สร้างทฤษฎี, ทดสอบพวกมัน, จนกว่าทฤษฎีหนึ่งจะยืนหยัด
• การล่าบั๊ก - ค้นหาบั๊กต่อไปจนกว่าการรันเต็มหนึ่งครั้งจะส่งคืนศูนย์
• การขุดหารูปแบบ - จัดกลุ่ม, ระบุกฎ, จนกว่าจะไม่มีกลุ่มใหม่ปรากฏขึ้น

จับคู่รูปแบบนี้กับ /goal เพื่อตั้งค่าข้อกำหนดการเสร็จสิ้นที่เข้มงวด ("อย่าหยุดจนกว่าทฤษฎีหนึ่งจะใช้ได้") และกับ /loop หากคุณต้องการให้เวิร์กโฟลว์ทั้งหมดทำงานตามกำหนดเวลาที่เกิดซ้ำ

สายการแข่งขันและเงื่อนไขการหยุดอยู่ในโค้ด มีเพียงการวนซ้ำที่ทำงานอยู่เท่านั้นที่อยู่ในบริบท

11. รวมรูปแบบสำหรับกรณีการใช้งานจริง. หนึ่งเวิร์กโฟลว์, หลายรูปแบบ

6 รูปแบบนั้นแทบจะไม่ปรากฏเพียงลำพัง เวิร์กโฟลว์จริงจะรวม 2-4 รูปแบบเข้าด้วยกัน เมทริกซ์ด้านล่างจับคู่กรณีการใช้งานแต่ละกรณีจากเอกสารเปิดตัวของ Anthropic กับรูปแบบที่มักจะใช้:

• การย้ายระบบและการปรับโครงสร้างใหม่. กระจาย (หนึ่งเอเจนต์ต่อ callsite/การทดสอบที่ล้มเหลวใน worktree) → การตรวจสอบแบบเป็นปฏิปักษ์ (เอเจนต์แยกต่างหากตรวจสอบการแก้ไขแต่ละครั้ง) → วนซ้ำจนเสร็จ นี่คือรูปแบบที่ Anthropic ใช้เขียน Bun ใหม่จาก Zig เป็น Rust
• การวิจัยเชิงลึก (ทักษะ /deep-research). กระจาย (การค้นหาเว็บแบบขนาน) → การตรวจสอบแบบเป็นปฏิปักษ์ (แต่ละข้อกล่าวอ้างได้รับการตรวจสอบอย่างอิสระ) → สังเคราะห์ (รายงานที่มีการอ้างอิงหนึ่งฉบับ)
• การตรวจสอบเชิงลึกของร่าง. ระบุข้อกล่าวอ้างที่เป็นข้อเท็จจริงทั้งหมด (หนึ่งเอเจนต์) → กระจาย (หนึ่งผู้ตรวจสอบต่อข้อกล่าวอ้าง, แต่ละเอเจนต์ตรวจสอบกับแหล่งที่มา) → ผู้ตรวจสอบเมตา (ตรวจสอบว่าแหล่งที่มาของผู้ตรวจสอบมีคุณภาพสูง)
• การเรียงลำดับ 1,000+ รายการ. การแข่งขัน (ขั้นตอนที่ 5-9) - การเปรียบเทียบแบบคู่, การจัดอันดับแบบกลุ่ม, หรือสายการแข่งขัน การตัดสินเชิงเปรียบเทียบ ไม่ใช่การให้คะแนนแบบสัมบูรณ์
• การปฏิบัติตามหน่วยความจำและกฎ. ผู้ตรวจสอบต่อกฎ (กระจาย) → บุคลิกภาพผู้คลางแคลงตรวจสอบกฎด้วยตนเองเพื่อหลีกเลี่ยงผลบวกลวง
• การสอบสวนสาเหตุที่แท้จริง. สร้างทฤษฎีจากหลักฐานที่ไม่เกี่ยวข้องกัน (เอเจนต์ต่างๆ อ่านบันทึก, ไฟล์, ข้อมูล) → คณะผู้ตรวจสอบและผู้โต้แย้งสำหรับแต่ละทฤษฎี → วนซ้ำจนกว่าทฤษฎีหนึ่งจะอยู่รอด
• การคัดแยกในวงกว้าง. จัดประเภทและดำเนินการ → ลบรายการที่ซ้ำกับตั๋วที่มีอยู่ → พยายามแก้ไขหรือยกระดับ จับคู่กับ /loop สำหรับการคัดแยกอย่างต่อเนื่อง
• การสำรวจและรสนิยม (การออกแบบ, การตั้งชื่อ, ตัวเลือก UI). สร้างและกรอง (5-20 ตัวเลือก) → การแข่งขันพร้อมเกณฑ์การให้คะแนน → จัดอันดับหรือเลือก
• การประเมินผลแบบเบา. รันผู้สมัครใน worktree → เอเจนต์เปรียบเทียบให้คะแนนตามเกณฑ์การให้คะแนน → ปรับปรุงและให้คะแนนใหม่ รูปร่างเดียวกับการแข่งขัน แต่สำหรับการให้คะแนน ไม่ใช่การจัดอันดับ

วิธีที่ถูกต้องในการซึมซับสิ่งเหล่านี้: ระบุว่ารูปแบบความล้มเหลวใดที่งานปัจจุบันของคุณกำลังประสบอยู่ จากนั้นเลือกรูปแบบที่ป้องกันมันในเชิงโครงสร้าง

การเบี่ยงเบน → กระจาย. ความชอบตนเอง → การตรวจสอบแบบเป็นปฏิปักษ์. ปลายเปิด → วนซ้ำจนเสร็จ. ให้คะแนนยาก → การแข่งขัน.

12. จับคู่กับ /goal, /loop, และงบประมาณโทเค็น

เวิร์กโฟลว์อาจมีราคาแพง การควบคุมสามอย่างเปลี่ยนพวกมันจาก "เจ๋งแต่แพง" เป็น "เครื่องมือที่ฉันรันโดยไม่มีคนดูแล"

• /goal ตั้งค่าข้อกำหนดการเสร็จสิ้นที่เข้มงวด จับคู่กับรูปแบบการวนซ้ำ: "อย่าหยุดจนกว่าทฤษฎีหนึ่งจะใช้ได้" หากไม่มี /goal เวิร์กโฟลว์จะหยุดที่จุดเสร็จสิ้นแบบอ่อน หากมี /goal มันจะวนซ้ำจนกว่าจะตรงตามเงื่อนไขสิ้นสุดจริง
• /loop รันเวิร์กโฟลว์ทั้งหมดตามกำหนดเวลาที่เกิดซ้ำ ใช้สำหรับเวิร์กโฟลว์ที่คุณต้องการให้ทำงานอย่างต่อเนื่อง - การคัดแยก, การอัปเดตการวิจัยรายสัปดาห์, การตรวจสอบที่เกิดซ้ำ
• งบประมาณโทเค็นที่ชัดเจน บอก Claude ในพรอมต์: "ใช้ 10k โทเค็น" สิ่งนี้กำหนดขีดจำกัดในการรันเวิร์กโฟลว์ หากไม่มีขีดจำกัด เวิร์กโฟลว์ที่ทะเยอทะยานอาจขยายเป็น 5–10 เท่าของโทเค็นที่คุณคาดหวัง

1> ultracode ตรวจสอบแบบเป็นปฏิปักษ์อย่างรวดเร็วของสมมติฐานนี้:
2  "การย้ายไป Postgres ช่วยลดความจำเป็นในการปรับสมดุลชาร์ดของเรา"
3  ใช้ 5k โทเค็น /goal อย่าหยุดจนกว่าคุณจะมี
4  ตัวอย่างค้านหรือการยืนยันอิสระสามครั้ง

อ้างอิงจากทีม Claude Code โดยตรง: "แนวทางปฏิบัติที่ดีที่สุดยังคงพัฒนาอยู่ เวิร์กโฟลว์แบบไดนามิกมักใช้โทเค็นมากกว่า ดังนั้นควรคิดให้รอบคอบว่าเมื่อใดและอย่างไรที่จะใช้มัน" งานเขียนโค้ดแบบดั้งเดิมส่วนใหญ่ ไม่จำเป็นต้องมีคณะผู้ตรวจสอบ 5 คน

ถามตัวเองว่า: งานนี้ต้องการการคำนวณเพิ่มเติมจริงหรือไม่? หากเซสชัน Claude Code ปกติจะทำให้เสร็จภายในห้านาที คุณไม่จำเป็นต้องมีเวิร์กโฟลว์

13. ใช้รูปแบบการกักกันสำหรับอินพุตที่ไม่น่าเชื่อถือ

เวิร์กโฟลว์ใดๆ ที่อ่านเนื้อหาสาธารณะที่ไม่น่าเชื่อถือ - ตั๋วสนับสนุน, รายงานบั๊ก, ข้อเสนอแนะจากผู้ใช้, ข้อมูลที่ขูดมา - จำเป็นต้องถือว่าเนื้อหานั้นอาจมีการฉีดพรอมต์

วิธีแก้ไข: การกักกัน ห้ามเอเจนต์ที่ อ่าน เนื้อหาที่ไม่น่าเชื่อถือดำเนินการใดๆ ที่มีสิทธิ์สูง เอเจนต์ที่แยกต่างหาก ซึ่งไม่เปิดเผยเนื้อหาดิบ จะเป็นผู้ดำเนินการ

เวิร์กโฟลว์ใดๆ ที่ประมวลผลเนื้อหาที่ผู้ใช้ส่งมา (ตั๋วสนับสนุน, รายงานบั๊ก, ข้อเสนอแนะจากลูกค้า, โซเชียลมีเดีย), ขูดหน้าเว็บสาธารณะ, หรือรันกับผลลัพธ์จาก API ของบุคคลที่สาม

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

14. บันทึกเวิร์กโฟลว์. ส่งเป็น Skill

เมื่อเวิร์กโฟลว์ใช้งานได้ ให้บันทึกมัน: กด s ในเมนูเวิร์กโฟลว์ เวิร์กโฟลว์ที่บันทึกไว้จะไปที่ ~/.claude/workflows จากนั้นคุณมีสองเส้นทาง:

• เก็บไว้ในเครื่อง - นำมาใช้ซ้ำในโปรเจกต์ของคุณเอง
• ส่งเป็น Skill - รวมไฟล์ JavaScript ไว้ในโฟลเดอร์ Skill, อ้างอิงใน SKILL.md, และใครก็ตามที่ติดตั้ง Skill จะรันเวิร์กโฟลว์เดียวกัน

ความแตกต่างในทางปฏิบัติอย่างหนึ่งที่ควรรู้: เมื่อคุณบรรจุเวิร์กโฟลว์ลงใน Skill ให้บอก Claude ให้ถือว่าเวิร์กโฟลว์เป็นเทมเพลต ไม่ใช่สคริปต์ที่จะรันตามตัวอักษร

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

ข้อผิดพลาดที่ทำให้เสียโทเค็นในเวิร์กโฟลว์

• ใช้เวิร์กโฟลว์เมื่อเซสชัน Claude Code ปกติก็เพียงพอ งานเขียนโค้ดแบบดั้งเดิมส่วนใหญ่ไม่จำเป็นต้องมีคณะผู้ตรวจสอบ 5 คน
• ไม่มีงบประมาณโทเค็น เวิร์กโฟลว์ที่ทะเยอทะยานขยายเป็น 5–10 เท่าของที่คุณคาดหวังโดยไม่มีขีดจำกัดที่ชัดเจน
• เอเจนต์ตัวเดียวทำงานทั้งงานและการตรวจสอบ อคติชอบตนเองทำให้ผู้ตรวจสอบชอบผู้ปฏิบัติงาน พวกมันต้องแยกจากกัน
• ถือว่า parallel() และ pipeline() ใช้แทนกันได้ สิ่งกีดขวางมีความสำคัญ - parallel รอทั้งหมด, pipeline สตรีม
• ข้าม /goal ในรูปแบบการวนซ้ำ เวิร์กโฟลว์หยุดเร็วที่จุดเสร็จสิ้นแบบอ่อนแรก /goal บังคับให้เสร็จสิ้นแบบเข้มงวด
• ปล่อยให้เนื้อหาที่ไม่น่าเชื่อถือเข้าถึงผู้ดำเนินการ การกักกันไม่ใช่ทางเลือกเมื่อคุณประมวลผลสิ่งที่ผู้ใช้ส่งมา
• เรียงลำดับด้วยคะแนนสัมบูรณ์ การตัดสินเชิงเปรียบเทียบมีความน่าเชื่อถือมากกว่า ใช้การแข่งขัน
• ไม่เคยบันทึกเวิร์กโฟลว์ที่ใช้งานได้ การถามพรอมต์รูปร่างเดิมซ้ำทุกสัปดาห์ บันทึกด้วย s, ส่งเป็น Skill

สรุป:

https://x.com/_catwu/status/2060054180379689074