ซอฟต์แวร์แฟกทอรี (Software factories) กำลังเป็นที่นิยมอย่างมากในช่วงไม่กี่สัปดาห์ที่ผ่านมา ดังนั้นฉันจึงสร้างขึ้นมาเอง
นี่คือสิ่งที่ฉันได้เรียนรู้ มันทำงานอย่างไร และคุณสามารถสร้างขึ้นมาได้ในบ่ายวันเดียว
เป้าหมายของฉัน
มันต้องเรียบง่ายมาก เป็นสิ่งที่ใช้งานได้ทันที โดยไม่ต้องคอยดูแลมากมาย ในอุดมคติแล้ว มันจะทำงานทั้งหมดโดยใช้การสมัครสมาชิก Claude ที่ฉันมีอยู่
มันฟังดูไร้เดียงสา แต่โดยพื้นฐานแล้ว ถ้ามันผสานรวมเข้ากับ workflow ที่มีอยู่ของฉันได้ง่าย มันก็จะไม่ใช่สิ่งที่อยู่ได้นาน ฉันไม่อยากสร้างสิ่งนี้แล้วต้องเปลี่ยนนิสัยเดิมๆ ทั้งหมดของฉันเพื่อใช้ระบบใหม่นี้ ฉันรู้จากประสบการณ์ว่าถ้าเป็นแบบนั้น มันจะไม่เวิร์กสำหรับฉันในระยะยาวและจะค่อยๆ เลือนหายไป
ดังนั้น แทนที่จะทำสิ่งนี้เป็นความพยายามใหญ่ครั้งเดียว ฉันจึงแบ่งมันออกเป็นสองเฟสที่ชัดเจน:
- Pre-triage - กำหนดสิ่งที่ต้องทำ
- Implementation - ลงมือทำสิ่งต่างๆ จริงๆ
ตรงกลางคือ Linear ซึ่งเป็นแหล่งความจริงของงานที่ต้องทำ
ทุกซอฟต์แวร์แฟกทอรีจำเป็นต้องมีพื้นที่เก็บข้อมูลงานที่ต้องทำแบบรวมศูนย์ ไม่ว่าจะเป็น GitHub issues, Linear หรืออะไรก็ตาม ควรเป็นสิ่งที่คุณใช้อยู่แล้ว เพื่อให้ระบบใดๆ ก็สามารถเพิ่มงานให้ตัวแทน (agents) หรือมนุษย์รับไปทำในภายหลังได้อย่างง่ายดาย
Linear พร้อม issue ที่สร้างอัตโนมัติผ่าน System Health Check loop
ไปป์ไลน์มีรอยต่อที่กำหนดไว้อย่างจงใจ ซึ่งทำให้กระบวนการสร้างซอฟต์แวร์แฟกทอรีจัดการได้จริง:
- สร้างงาน (loops กับ MCPs)
- จัดเก็บงาน (linear)
- ทำงานให้เสร็จ (SDLC agent)
การแบ่งแยกแบบนี้ทำให้คุณไม่จำเป็นต้องสร้างทั้งฝั่ง pre-triage และ implementation พร้อมกัน (และฉันขอแนะนำให้หลีกเลี่ยงเพื่อไม่ให้ over-engineer) Linear ทำให้ส่วนต่อประสานระหว่างสิ่งที่ต้องทำกับสิ่งที่กำลังทำอยู่นั้นชัดเจนและขยายได้ง่าย
ขั้นตอน Pre-Triage
ในแผนภาพด้านบน งานดำเนินจากซ้ายไปขวา ด้านซ้ายคือที่ที่งานถูกสร้างขึ้นและประกอบด้วยระบบต่างๆ (ไม่ว่าจะเป็นมนุษย์ ตัวแทน หรือ API) ที่เพิ่มสิ่งที่ต้องทำ ผลลัพธ์ทั้งหมดที่สร้างในขั้นตอน pre-triage นี้จะถูกใส่เข้าไปใน Linear ของเรา
loops สองสามตัวที่ทำงานในสภาพแวดล้อมคลาวด์ของ Claude
ในขั้นตอนนี้ เรามี loop หลักสามตัว:
- System Health Check Loop (เช่น ตัวค้นหาบั๊ก) - loop นี้ทำงานทุกวันเวลา 5 โมงเช้า (05.00 น.) และเชื่อมต่อกับ MCP server หลายตัว: Posthog สำหรับติดตามข้อผิดพลาด; Vercel สำหรับวินิจฉัยระบบ; และ Linear สำหรับสร้าง issue
- UX Improvements and Customer Feedback Loop - loop นี้ทำงานทุกสัปดาห์ในวันจันทร์เวลา 9 โมงเช้า (09.00 น.) และสแกนทุก feedback ใหม่, แชทฝ่ายสนับสนุนลูกค้าทั้งหมดจาก Intercom/Fin, และบันทึกการเล่นซ้ำเซสชั่น Posthog ทั้งหมด Session replays เป็นเหมืองทอง คุณจะเห็นว่ามี rage clicks เกิดขึ้นที่ไหน หรือผู้ใช้กำลังดิ้นรนและสับสนตรงไหน
- Churn Analysis Loop - loop นี้ทำงานทุกวันเวลา 6 โมงเช้า (06.00 น.) และตรวจสอบลูกค้าทุกคนที่คลิกยกเลิกใน 24 ชั่วโมงที่ผ่านมา มันดึงข้อมูลการชำระเงินและข้อมูลผู้ใช้จาก Stripe (รวมถึงอีเมล/ที่ตั้งของพวกเขา) จากนั้นดูบันทึกการเล่นซ้ำเซสชั่นของลูกค้ารายนี้ใน Posthog เพื่อดูว่าพวกเขากำลังทำอะไรก่อนที่จะยกเลิก เราดึงข้อมูลการใช้งานจาก Supabase เพื่อดูว่าเป็น ICP ที่ผิด, ไม่เคยพบช่วงเวลา "ว้าว" หรือเจอบั๊ก รายงานจะถูกส่งไปที่ Slack และตัวแทนจะสร้าง (หรือแสดงความคิดเห็นใน) issue หากเกี่ยวข้องกับการที่ลูกค้าหยุดใช้เพื่อเพิ่มความสำคัญ
เพื่อให้ตัวแทนเหล่านี้ทำงานได้อย่างสม่ำเสมอ ฉันทำให้มันเรียบง่ายและใช้ Claude Code Cloud Routines
ไม่ต้อง over-engineer ด้วย Hetzner VPS, mac mini ที่กินคาเฟอีน ฯลฯ มันเป็นวิธีที่ง่ายที่สุดที่ฉันเคยพบในการใช้ประโยชน์จากการสมัครสมาชิก Claude Code ที่มีอยู่และสร้างตัวแทนที่ทำงานตลอดเวลา ซึ่งสามารถทริกเกอร์ตามกำหนดเวลาหรือผ่านเหตุการณ์ webhook และสำหรับทุกคนที่พูดว่า "แต่แล้ว vendor lock in ล่ะ!!" - มันก็แค่ข้อความบางส่วน รู้สึกอิสระที่จะคัดลอก prompt ไปที่ไหนก็ได้ ฉันแค่อยากได้สิ่งตั้งค่าที่ง่ายที่สุดและถูกที่สุดที่ทำงานได้อย่างน่าเชื่อถือ
อีกเหตุผลที่ใช้ Claude Code Cloud Routines คือสภาพแวดล้อมคลาวด์ของ Anthropic มีความเท่าเทียมใกล้เคียงกับ Claude ที่ทำงานบนเครื่องท้องถิ่น
Cloud Claude Routines
แน่นอนว่ามันไม่มี env vars ของคุณ (ซึ่งสามารถเพิ่มเข้าไปในการตั้งค่าสภาพแวดล้อมคลาวด์ได้ถ้าจำเป็น) แต่ถ้าคุณตั้งค่าการเชื่อมต่อ MCP ผ่านคอนเน็กเตอร์ของ Desktop App, ทั้ง Claude cli ในเครื่องและ Claude ระยะไกลสามารถใช้มันได้ ต่างจาก Codex นี่คือฟีเจอร์ที่เด็ดมากสำหรับฉันและเป็นสิ่งที่ทำให้ pre-triage agent loops ทำงานได้ดีขนาดนี้ มันยังทำให้สามารถรันหลายๆ เซสชันพร้อมกันได้โดยไม่ต้องกังวลเรื่องหน่วยความจำของแล็ปท็อป
ถ้าคุณใช้แค่ขั้นตอน pre-triage นี้ คุณจะยังได้รับประโยชน์มากมาย แม้ว่าคุณจะไม่ได้สร้างขั้นตอนถัดไปที่งานจะเสร็จสมบูรณ์
เริ่มต้นเล็กๆ ด้วย loop เดียว ทดลองใช้ ปรับแต่ง แล้วเพิ่มมากขึ้น ค้นหาว่าคุณสามารถสร้าง routines อะไรได้บ้างในวันนี้ที่เพิ่มงานใหม่ที่มีคุณภาพสูงลงใน issue tracker ที่มีอยู่ จากนั้นก็ทำสิ่งที่คุณทำอยู่ทุกวันนี้สำหรับการดำเนินการ
ขั้นตอน Implementation
เวอร์ชันพื้นฐานที่สุดของขั้นตอนที่สองคือให้ issue ID แก่ตัวแทนของคุณแล้วบอกให้ไปทำให้เสร็จ นี่คือสิ่งที่คนส่วนใหญ่ทำอยู่แล้วในปัจจุบันเมื่อทำงานกับตัวแทน อย่างไรก็ตาม มันอาจไม่ใช่สิ่งที่คุณต้องการถ้าคุณกำลังอ่านข้อความนี้ เพราะตอนนี้คุณกลายเป็นคอขวดใน loop แล้ว โดยต้องเริ่มตัวแทนโดยตรงในเซสชัน
แทนที่ฉันจะทำแบบนั้น ฉันสร้างวิธีในการทริกเกอร์เซสชัน Claude Code ระยะไกลโดยตรงจาก Linear
จาก linear issue ไปยัง Claude
มันทำงานดังนี้:
- ขั้นแรก ระบุว่าคุณต้องการทริกเกอร์เซสชัน Claude ใหม่อย่างไร สำหรับเรา เราเพิ่ม label 'auto' ให้กับ Linear issue เพื่อเริ่มงานใหม่นี้
- จากนั้น Linear ส่งเหตุการณ์ webhook ไปยังบริการ API webhook ภายในของเรา (แอป Hono ภายในที่สร้างขึ้นใหม่) ซึ่งแยกวิเคราะห์เหตุการณ์แล้วส่งข้อมูลที่ถูกต้องต่อไปยัง Claude Routine
- สุดท้าย บริการ API น้ำหนักเบานี้ทำคำขอ POST ไปยัง Anthropic ที่ทริกเกอร์ Claude routine ด้วย prompt เริ่มต้น
การใช้ label 'auto' เป็นทริกเกอร์ช่วยให้เราควบคุมการดำเนินการอัตโนมัติของเซสชัน Claude ใหม่
ตามค่าเริ่มต้น เราไม่มีขั้นตอน pre-triage ที่รวม label 'auto' เหล่านี้ และต้องให้มนุษย์เพิ่ม label ที่ทริกเกอร์ให้ตัวแทนเริ่มทำงาน (คงมนุษย์ไว้ใน loop) นั่นเป็นสาเหตุที่เราเรียกขั้นตอนที่ 1 ว่า pre-triage step เพราะยังมีบางสิ่งที่กำลังพิจารณาว่าจะทำงานอะไรจริงๆ ไม่ว่าจะผ่านการมีส่วนร่วมของมนุษย์ หรือตัวแทนบางตัวที่ loop และคอยดู issue ใหม่ที่ถูกเพิ่ม และเริ่มเซสชัน implementation ใหม่
อย่างไรก็ตาม เนื่องจากการเพิ่ม label ก็ทำได้ง่ายโดยตัวแทน เราจึงสามารถให้ pre-triage loops สร้าง issue ใหม่ที่มี label 'auto' เป็นค่าเริ่มต้น ซึ่งจะเริ่มเซสชัน Claude ใหม่ การใช้ label กลายเป็นวิธีที่ยืดหยุ่นมากในการเริ่มงาน implementation ใหม่ ไม่ว่าจะโดยอัตโนมัติโดยตัวแทน หรือโดยมนุษย์อย่างเรา
บริการกำหนดเส้นทางน้ำหนักเบาเพื่อเริ่มเซสชัน Claude
เพราะ Linear รองรับ webhooks ทั้งระบบ "push เมื่อเพิ่ม label" จึงทำงานได้ ข้อเสียเพียงอย่างเดียวคือเราจำเป็นต้องมี API สาธารณะที่รับ webhooks เหล่านี้และจัดรูปแบบเหตุการณ์และข้อมูล payload เพื่อทริกเกอร์ Claude Code บริการใหม่นี้ยังเพิ่ม headers การรับรองความถูกต้องที่ถูกต้อง ซึ่งเป็นสาเหตุที่คุณไม่สามารถให้ Linear ทริกเกอร์ routine โดยตรงได้
อีกทางเลือกหนึ่ง คุณสามารถมี routine ตามกำหนดเวลาที่เริ่มเป็นระยะและพยายามดำเนินการ issue ใหม่ใดๆ ที่ไม่ได้ดำเนินการอยู่โดยมี label auto
สำหรับ prompt routine จริง ฉันแนะนำให้สร้างสกิลที่ใช้ซ้ำได้ซึ่งพาผ่าน SDLC ทั้งหมด ตั้งชื่อเช่น /implement หรือ /do ที่ทำให้ง่ายต่อการพูดว่า "/do ISSUE-NNN" ซึ่งบันทึกวิธีการดำเนินการผ่านขั้นตอนต่างๆ อย่างถูกต้อง เช่น การดึงบริบท issue, การนำงานไปปฏิบัติ, การตรวจสอบในเบราว์เซอร์, การสร้าง PR, และการติดตามความคิดเห็น
จากนั้น prompt Claude routine ที่ทริกเกอร์โดยเหตุการณ์ Linear ก็สามารถมี prompt ที่เรียบง่ายมาก นี่คือของฉัน:
ดึง issue ที่ให้มาและใช้สกิล /do เพื่อดำเนินการเปลี่ยนแปลงที่ร้องขอและสร้าง pull request ให้ดึงเฉพาะ issue ที่ระบุเท่านั้น ถ้ามันเสร็จสมบูรณ์แล้วหรือกำลังดำเนินการอยู่ ให้หยุด
การอ้างอิง issue ไม่ปรากฏในข้อความนี้ — มันมาถึงเป็นข้อความติดตามแยกต่างหากที่ห่อหุ้มด้วยแท็ก \
<routine-fire-payload>\ส่งทันทีหลังจากข้อความนี้ ในเซสชันเดียวกัน รอจนกว่าข้อความนั้นก่อนตัดสินใจว่า issue ถูกระบุหรือไม่ สรุปได้ว่า issue ไม่มีอยู่จริง หรือไม่ได้ให้มาก็ต่อเมื่อตรวจสอบในข้อความ \<routine-fire-payload>\แล้วยืนยันว่า issue ที่อ้างอิงนั้นไม่มีอยู่จริงเมื่อคุณเริ่มทำงาน ให้แสดงความคิดเห็นใน issue ตั้งค่าเป็น "In Progress" และอัปเดต issue ด้วยสิ่งที่มีความหมายเมื่อคุณดำเนินการ นำหน้าความคิดเห็น Linear issue ด้วย [Claude] เสมอ
ดังนั้น ณ จุดนี้คุณมีเซสชัน Claude Remotion แบบขนานที่ถูกทริกเกอร์ผ่าน API ดำเนินการ issue เปิด PR (และหวังว่าพวกเขาจะตรวจสอบงานของพวกเขาผ่าน Playwright หรือ Agent Browser)
โดยพื้นฐานแล้วมันคือซอฟต์แวร์แฟกทอรีที่สมบูรณ์ที่สังเกตได้อย่างเต็มที่ ทำงานในขณะที่คุณหลับ และทำงานทั้งหมดโดยใช้การสมัครสมาชิก Claude Code ของคุณ
