Claude บน Mac Mini: เปลี่ยนผลิตภัณฑ์ Apple ที่ราคาประหยัดที่สุดให้เป็นขุมพลังเบื้องหลังการทำงาน

ระบบอัตโนมัติส่วนใหญ่ตายในแบบเดียวกัน มีคนสร้างของเจ๋งๆ ขึ้นมา ใช้มันครั้งนึงในหน้าต่างแชท ปิดแล็ปท็อปไปกินข้าวเย็น แล้วทุกอย่างก็หายไป สคริปต์ไม่เคยเป็นจุดอ่อน แล็ปท็อปต่างหาก มันต้องเปิดไว้ เสียบปลั๊ก เปิดเครื่องอยู่ตลอด เพื่อให้งานดำเนินต่อไปได้ — และแล็ปท็อปถูกสร้างมาให้ทำตรงกันข้าม

Mac mini ไม่มีปัญหานั้น ราคาประมาณ $599 สำหรับรุ่นเริ่มต้น ใช้ไฟน้อยกว่าโคมไฟตั้งโต๊ะ แทบไม่มีเสียง และมีหน้าที่เดียวคือ: เปิดค้างไว้ คุณสมบัติเดียวนี้คือเหตุผลทั้งหมดที่ทำให้มันกลายเป็นเครื่องที่คนแอบเอาไว้ให้ Claude workflow ทำงาน

บทความนี้จะพาไปดูสาม workflow เหล่านั้น — กล่องจดหมายที่จัดระเบียบตัวเอง, pull request ที่ได้รับการตรวจสอบข้ามคืน, และปฏิทินที่ส่งสรุปให้คุณแทนที่จะเป็นแค่ชื่อประชุม — ทั้งหมดทำงานบน mini ที่วางอยู่ที่ไหนสักแห่งในบ้าน ทำงานโดยที่ไม่มีใครต้องจำต้องเริ่มมัน

ทำไมไม่ใช้แค่ Claude chat อย่างเดียวล่ะ?

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

สิ่งที่เปลี่ยนไปคือใครเป็นคนกดปุ่มเริ่ม

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

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

อะไรอยู่บนโต๊ะจริงๆ

สามชั้น และไม่มีอะไรแปลกใหม่เลย:

เครื่องจักร. Mac mini ที่รัน launchd jobs (ญาติที่นิสัยดีกว่า cron บน macOS) ซึ่งเรียกใช้ Python scripts ตามตารางเวลาหรือเมื่อมีไฟล์เปลี่ยน PC เล็กๆ ที่เปิดตลอดเวลาก็ทำงานแบบเดียวกันได้ — mini แค่เงียบ ถูกและเล็กพอที่จะซ่อนหลังจอภาพ

พื้นที่จัดเก็บ. โฟลเดอร์ธรรมดาและไฟล์ markdown บวกกับอะไรก็ตามที่ workflow เกี่ยวข้องโดยตรง — กล่องจดหมายผ่าน IMAP, GitHub repo ที่ clone ไว้ในเครื่อง, ปฏิทินที่ซิงก์กับ .ics feed ไม่มีอะไรอยู่เบื้องหลังแอปของคนอื่น ถ้า mini หายไปพรุ่งนี้ ไฟล์ทุกไฟล์ที่มันสร้างขึ้นก็ยังเปิดได้ตามปกติบนคอมพิวเตอร์เครื่องใดก็ได้

ตัวประมวลผล. Claude เรียกผ่าน API Sonnet จัดการอะไรก็ตามที่ต้องใช้ดุลยพินิจจริงๆ — ตัดสินใจว่า pull request ปลอดภัยพอจะ merge หรือไม่, ร่างตอบกลับที่ฟังดูเหมือนคุณ Haiku จัดการงานที่ถูกและมีปริมาณมาก — การจัดเรียง, การติดป้าย, การตรวจสอบใช่/ไม่ใช่ การแบ่งงานแบบนี้คือสาเหตุหลักที่ค่าใช้จ่ายรายเดือนยังต่ำกว่าค่าสมัครกาแฟ

ต่อไปเป็น workflow จริงๆ

กิจวัตรที่หนึ่ง: กล่องจดหมายที่ไร้เสียงรบกวนเมื่อคุณเปิดดู

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

1RUN AT:     ทุก 15 นาที ในวันธรรมดา
2WATCH:      อีเมลใหม่ในกล่องจดหมายหลัก
3
4STEPS:
5  1. ดึงข้อความ 10 ฉบับล่าสุดในเธรดเดียวกันเพื่อดูบริบท
6  2. Claude จัดประเภทข้อความใหม่:
7       - งานประจำ (การยืนยัน, จดหมายข่าว, การตอบกลับอัตโนมัติ)
8       - ต้องการการตอบกลับ (คำถามจริง, คำขอ)
9       - ต้องการการตัดสินใจของมนุษย์ (เรื่องเงิน, ความขัดแย้ง, อะไรก็ตามที่คลุมเครือ)
10  3. งานประจำ -> เก็บถาวรโดยอัตโนมัติ, บันทึกในสรุปรายวัน
11     ต้องการการตอบกลับ -> Claude ร่างตอบกลับด้วยสำนวนของคุณ, บันทึกไว้ใน Drafts,
12                     จะไม่ถูกส่งจนกว่าคุณจะเปิดดู
13     ต้องการมนุษย์ -> ปล่อยไว้ไม่แตะต้อง, ทำเครื่องหมายไว้, ไม่มีการร่างตอบกลับ
14
15CHECK:      การจัดประเภทต้องมีเหตุผลหนึ่งบรรทัด หาก Claude
16            ไม่สามารถให้เหตุผลที่อ้างอิงเนื้อหาของข้อความจริงได้
17            รายการนั้นจะตกไปอยู่ในหมวด "ต้องการมนุษย์" โดยค่าเริ่มต้น
18STOP:       ทุกข้อความในชุดนั้นถูกจัดประเภทแล้ว หรือลองซ้ำ 3 ครั้ง
19            สำหรับข้อความใดข้อความหนึ่งก่อนที่จะถูกทำเครื่องหมายให้คุณโดยตรง

กฎที่สำคัญที่นี่คือการถอยฉุกเฉิน อะไรก็ตามที่ Claude ไม่สามารถจัดประเภทได้อย่างมั่นใจจะไม่ถูกเดา — มันจะตกมาที่คุณเหมือนที่มันจะเป็นอยู่แล้ว workflow ไม่ได้พยายามแทนที่ดุลยพินิจใน 10% ที่ยาก มันพยายามหยุดไม่ให้ขโมยความสนใจของคุณใน 90% ที่ง่าย

กิจวัตรที่สอง: pull requests ได้รับการตรวจสอบเบื้องต้นก่อนที่คุณจะตื่น

การตรวจสอบโค้ดมีรูปแบบความล้มเหลวที่แปลก: การตรวจสอบที่สำคัญที่สุด — การตรวจสอบ PR ที่เข้ามาตอน 23:00 น. — มีแนวโน้มมากที่สุดที่จะถูกรีบทำแบบครึ่งหลับครึ่งตื่น หรือแย่กว่านั้นคือถูก merge ด้วยคำว่า "เดี๋ยวพรุ่งนี้ดู" ที่ไม่มีวันเกิดขึ้น

1RUN AT:     ทุกครั้งที่มี pull request ใหม่ ผ่าน GitHub webhook
2
3STEPS:
4  1. ดึง diff และ issue ที่เชื่อมโยง ถ้ามี
5  2. Claude ตรวจสอบตามเกณฑ์ที่กำหนด:
6       - ตรงกับขอบเขตของ issue ที่เชื่อมโยงจริงหรือไม่?
7       - มีการเปลี่ยนแปลง auth, payments, หรือ migrations หรือไม่? (แจ้งเตือน, อย่าตัดสิน)
8       - มี test coverage บนบรรทัดที่เปลี่ยนไปหรือไม่ — มีหรือขาด?
9       - การตั้งชื่อและโครงสร้างสอดคล้องกับส่วนที่เหลือของไฟล์หรือไม่?
10  3. แสดงความคิดเห็นโดยตรงบน PR ให้คะแนน 1-5 ต่อเกณฑ์แต่ละข้อ
11     โดยระบุจุดอ่อนที่สุดสองจุดอย่างชัดเจน
12
13CHECK:      จะแสดงความคิดเห็นก็ต่อเมื่ออ้างอิงหมายเลขบรรทัดที่เฉพาะเจาะจง
14            การตรวจสอบที่ไม่มีการอ้างอิงบรรทัดจะถูกยกเลิกและลองใหม่ —
15            ข้อเสนอแนะที่คลุมเครือไม่คุ้มที่จะส่ง
16STOP:       แสดงความคิดเห็นแล้ว หรือหลังจากลองซ้ำ 2 ครั้ง PR จะถูกปล่อยไว้
17            พร้อมข้อความว่าการตรวจสอบอัตโนมัติไม่สามารถทำได้สำเร็จ

ไม่มีอะไรที่นี่ทำการ merge อะไรเลย มันคือดวงตาคู่ที่สองที่ไม่เคยเหนื่อย มาอยู่บน PR ของคุณก่อนที่ดวงตาคู่แรกของคุณจะมาถึง การให้คะแนนตามเกณฑ์ที่กำหนดคือสิ่งที่ทำให้มันมีประโยชน์ — โมเดลที่ถูกขอให้ "ตรวจสอบโค้ดนี้" แบบไม่มีกรอบมักจะชมทุกอย่างหรือจับผิดแบบสุ่ม โมเดลที่ถูกให้คะแนนตามคำถามตายตัวสี่ข้อจะให้ข้อเสนอแนะแบบเดิมทุกครั้ง ซึ่งเป็นสิ่งที่ทำให้มันคุ้มค่าที่จะอ่านตอน 8 โมงเช้า

กิจวัตรที่สาม: การประชุมมาพร้อมกับสรุป ไม่ใช่แค่ชื่อเรื่อง

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

1RUN AT:     45 นาทีก่อนแต่ละกิจกรรมในปฏิทินที่มีผู้เข้าร่วม 2 คนขึ้นไป
2
3STEPS:
4  1. ดึงเธรดอีเมลล่าสุดและเอกสารที่แชร์ใดๆ ที่เชื่อมโยงกับ
5     ชื่อผู้เข้าร่วมหรือชื่อกิจกรรม
6  2. Claude เขียนสรุปหนึ่งหน้า:
7       - มีอะไรที่ตกลงกันไว้ครั้งที่แล้ว ถ้ามี
8       - คำถามที่ค้างอยู่หนึ่งข้อที่น่าสนใจ
9       - ตัวเลขหรือวันที่ใดๆ ที่ถูกกล่าวถึงในการแลกเปลี่ยนครั้งล่าสุด
10  3. ส่งเป็นการแจ้งเตือนแบบ push 30 นาทีก่อนกิจกรรม
11
12CHECK:      สรุปต้องอ้างอิงข้อความหรือเอกสารก่อนหน้าจริง
13            ไม่พบบริบทย้อนหลัง -> การแจ้งเตือนบอกว่า
14            "ไม่พบประวัติ" ไม่ใช่การสรุปที่สร้างขึ้นมา
15STOP:       ส่งแล้ว หรือข้ามทั้งหมดหากผู้เข้าร่วมเป็นคนใหม่

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

กฎสองข้อที่ทุกอย่างข้างต้นขึ้นอยู่กับ

ตัดรายละเอียดออกไป ทุกกิจวัตรที่นี่มีรากฐานอยู่บนราวกั้นสองอันเดียวกัน

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

เงื่อนไขการหยุดที่แท้จริง ทุกกิจวัตรข้างต้นมีขีดจำกัดสูงสุดในการลองซ้ำ และการถอยฉุกเฉินที่กำหนดไว้สำหรับสิ่งที่เกิดขึ้นเมื่อมันทำงานอย่างสะอาดไม่ได้ หากไม่มีสิ่งนั้น อีเมลที่ผิดรูปแบบเพียงฉบับเดียวหรือ PR ที่มี diff เสียจะเผา API calls ในวงวนลองซ้ำทั้งคืนอย่างมีความสุข และบิลก็มาแสดงก่อนที่รายงานบั๊กจะมา

ทำให้สองอย่างนี้ถูกต้อง งานเฉพาะแทบไม่สำคัญ — กล่องจดหมาย, โค้ด, ปฏิทิน หรืออะไรก็ตาม

ลองทำด้วยมือก่อนที่จะสร้างมัน

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

1คุณจะทำงานนี้เป็นรอบ ตรวจสอบผลลัพธ์ของตัวเอง
2ก่อนที่จะบอกว่าทำเสร็จ
3
4งาน:
5[สิ่งที่คุณต้องการให้จัดการ]
6
7กฎของรอบ:
8- ทำงานให้เสร็จ
9- ตรวจสอบกับ: [เงื่อนไขที่เฉพาะเจาะจงและตรวจสอบได้]
10- ถ้ามันไม่ผ่านการตรวจสอบ ให้บอกว่าอะไรผิด และทำเฉพาะส่วนนั้นใหม่
11- ถ้ามันผ่าน ให้พูดว่า "เสร็จ" แล้วหยุด
12- อย่าถามคำถามเพื่อความกระจ่างกับฉัน — ให้ตั้งสมมติฐานที่สมเหตุสมผลที่สุด
13  ระบุมันในหนึ่งบรรทัด แล้วดำเนินการต่อ
14
15เริ่มต้น.

นั่นคือกลไกทั้งหมดในรูปแบบย่อ ไม่มี mini, ไม่มี webhook, ไม่มีกำหนดการ — แค่ Claude ตรวจสอบงานของตัวเองเทียบกับกฎ แทนที่จะหยุดที่ร่างแรกที่ดูน่าเชื่อถือ ถ้าคุณลองทำด้วยมือสามหรือสี่ครั้งกับงานประเภทเดียวกันและกลับมาใช้มันเรื่อยๆ นั่นคือสัญญาณว่ามันคุ้มค่าที่จะเอาไปไว้บนเครื่องที่ไม่ต้องให้คุณจำต้องรันมัน

ลำดับที่ป้องกันไม่ให้พังตอนตีสอง

ไม่มีใครที่รันสิ่งเหล่านี้อย่างน่าเชื่อถือเริ่มต้นด้วยการเขียน cron job ลำดับที่ใช้ได้จริงคือ:

1. ลองทำด้วยมือในแชทจนกว่าผลลัพธ์จะถูกต้องสม่ำเสมอ
2. เปลี่ยนพรอมต์นั้นให้เป็นสคริปต์ — ไม่มีการเปลี่ยนแปลงตรรกะ
3. เพิ่มการตรวจสอบและขีดจำกัดการลองซ้ำก่อนสิ่งอื่นใด
4. หลังจากนั้นค่อยเชื่อมต่อกับกำหนดการหรือ webhook

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

สิ่งที่คุณได้จริงๆ

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

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

ขอบคุณที่อ่านบทความนี้

ผู้สร้าง: @0xclayn

บันทึกสิ่งนี้