หยุดเขียน Newsletter — ให้ 3 Claude Agent ทำแทน (Full Version)

R Dilip Kumar เล่า system อัตโนมัติที่แทนที่การเขียน newsletter รายสัปดาห์ — 3 Claude agent ทำงานเชื่อมกันผ่าน 1 shared document รันทุกวันพฤหัส 6 โมงเช้าก่อนเจ้าตัวเช็คอีเมล

เรื่องเปิด: พฤหัส 6:30 น.

ก่อนเจ้าตัวเช็ค reply แม้แต่ฉบับเดียว — 1 อีเมลรอใน inbox อยู่ใน voice ของเขาแล้ว, 3 subject line ให้เลือก, 1 send time ที่แนะนำจากข้อมูลที่ work จริงในอดีต

เจ้าตัวไม่เขียนอะไรเลยเช้านั้น — Claude agent 3 ตัว + 1 automation ทำหมด ทำงานจาก research ที่ scrape จาก audience ตอนเจ้าตัวหลับ

ทำไมไม่ยอมแลกเวลาให้งานซ้ำ

เคย freelance Fiverr ทำได้ $2,424 ใน 45 วัน แต่เลิก — ไม่ใช่เพราะเงินไม่ดี แต่ทุกดอลลาร์ต้องแลกเวลาบน schedule ของคนอื่น ไม่มี ceiling ที่คุมได้

เลือก system แทน — สิ่งที่ผลิต output ไม่ว่านั่งอยู่ที่โต๊ะหรือไม่. ตอนนี้ manage podcast 5 รายการ 2 รายการยอด rebuild เกิน 5M download ต่อรายการ podcast income เกิน corporate salary เก่า. ไม่ได้มาจากทำ hour เพิ่ม — มาจาก build system แต่ต้น จนชั่วโมงหยุดเป็นข้อจำกัด

Email รายสัปดาห์ = task เล็ก แต่ task เล็กที่ซ้ำ = จุดที่ system pay off เร็วสุด. 3 decision เดิมทุกสัปดาห์ — automate หรือไม่ก็ต้องทำเอง

Email broadcast รายสัปดาห์ = task ที่กลาย เป็น “freelance ให้ตัวเอง” โดยไม่รู้ตัว — research เหมือนเดิม, draft เหมือนเดิม, เดา subject line เหมือนเดิม, พฤหัสคนละวันแต่ manual grind เดิม

ความต่างที่ทำให้ทำงานได้: Skill ≠ Automation

คนส่วนใหญ่ที่พยายาม automate ข้าม step ไปที่ “make this happen for me” แล้วผิดหวังตอนไม่ stick

Skill = instruction สำหรับ 1 task เขียนครั้งเดียว รันเมื่อต้องการ · Automation = สิ่งที่เรียก Skill รันแล้วส่ง output ให้ตัวถัดไปในสาย

วิธีที่สะอาดสุด: build แต่ละส่วนเป็น Skill ก่อน แล้ว chain Skills ใน automation

Agent 1: Broadcast Angle Finder

ตัวที่ตัดสินว่าอีเมลจะเรื่องอะไร — ไม่เดา อ่านสิ่งที่ work จริงในสัปดาห์นี้ + ทำไม

Prompt:

“Spin up an agent called ‘Broadcast Angle Finder.’ This agent should use Apify to scrape my Threads account, read my top-performing Threads post from this week, and any reader replies or DMs. Find the one angle getting the most reaction, and one story that proves it. Give me the angle, the proof, and why it’s the strongest pick. Save the information into a document with the title in the format ‘EMAIL-WEDDMMYY.'”

2 อย่างที่ทำให้ agent นี้ทำงานจริงไม่ใช่เดา:

1. Apify scrape = อ่านสิ่งที่เกิดจริงในสัปดาห์ ไม่ใช่ที่จำได้
2. Saved document ไม่ใช่ nice-to-have — ไฟล์ dated นี้คือ handoff point ที่ agent ถัดไปอ่าน ทำให้ 3 agent ทำงานเป็น pipeline ไม่ใช่ 3 chat แยก

ก่อนมี agent นี้ ผู้เขียนเลือก topic ด้วย feel ทุกพฤหัส. Feel = research method ที่แย่. Reaction จริงของสัปดาห์ที่ scrape มา ไม่ใช่

Agent 2: Email Drafter

รับ angle มาแล้วส่งกลับ broadcast ครบ พร้อม send หลัง light edit

Prompt:

“Spin up an agent called ‘Email Drafter.’ This agent has to pick up the angle saved inside the file that the Broadcast Angle Finder hands over to it and write the full broadcast: subject line, opening hook, body, and one clear call to action. Match my voice from [paste 2 to 3 past emails]. Keep paragraphs under 3 lines. Format it and save the email inside the document that it picked the angle from.”

สังเกต — ไม่สร้างไฟล์ใหม่. เปิดไฟล์ dated เดียวกันที่ Agent 1 เขียนไว้แล้วเขียน draft ทับ. พอ 3 agent รันจบ ไฟล์เดียวนี้เก็บ research ทั้งสัปดาห์ + finished email — ไม่กระจายอยู่ 3 บทสนทนาที่ต้อง hold ในหัว

Voice-matching ไม่ optional — paste real email ไม่ใช่ description ของ tone

Describing your voice gives Claude an interpretation.
Pasting your actual writing gives it evidence, and evidence produces a draft that sounds like you on the first attempt instead of the fifth.

Agent 3: Subject Line + Send Optimizer

ตัวที่ตัดสินว่าคนจะเปิด email ที่คุณเพิ่งเสียเวลาเขียนหรือไม่

Prompt:

“Spin up an agent called ‘Subject Line and Send Optimizer.’ This agent is an expert in email copywriting and knows how to write subject lines that get opens. Take the drafted email that the Email Drafter hands over. Write 3 subject line variants, flag any spam-trigger words, and recommend a send time based on my past open data. Research and analyze the open rates from my [autoresponder name] connected here and all the data saved inside the workspace, before it runs.”

Send-time recommendation ไม่ใช่การเดาที่แต่งเป็น advice — agent ถูกสั่งให้ดึง real open-rate history จาก autoresponder ก่อน เขียน subject line — grounded ในสิ่งที่ work จริงกับ list เฉพาะ ไม่ใช่ generic best-practice

3 variant ไม่ใช่ 1 — subject line เดี่ยว = decision ที่ไม่มี evidence. 3 variant + check กับ open-rate history จริง = choice จริง

ทำไม Order ข้ามไม่ได้

Angle กำหนดอีเมล. อีเมลกำหนด subject line. Reverse หรือข้าม step ใด — chain พังใน pattern เฉพาะ:

• Run Optimizer โดยไม่มี angle จริง = เดาว่า subject line แบบไหนเหมาะกับ content ที่ไม่มี proof
• Run Drafter โดยไม่มี Angle Finder = กลับไปเขียนจาก feel + formatting ดีขึ้นเฉย ๆ

3 agent work as system ได้เพราะแต่ละตัว hand ไฟล์จริงให้ตัวถัดไป. นิยามจริงของ automation ไม่ใช่ prompt ใหญ่ตัวเดียว แต่คือ chain ที่ทุก link พึ่ง link ก่อนหน้า

Test แต่ละตัวก่อน Chain

Build + run แต่ละ agent เดี่ยว 2 สัปดาห์ก่อนต่อสาย. ฟังดูช้ากว่า build ทั้ง chain รวดเดียว แต่ไม่ใช่ — เมื่อคำนวณเวลาที่ประหยัดตอนรู้ว่า agent ไหนพัง

Angle Finder เดี่ยว หลายพฤหัส: เช็คว่า angle ที่เลือกตรงกับ reaction จริงมั้ย หรือ default ไปที่ post ที่มี like เยอะสุดโดยไม่ดู reply ข้างล่าง. ต้อง correct 1 ครั้ง — weight reply + DM สูงกว่า like count (like = passive, reply = proof ว่าคน care พอจะตอบ)

Drafter รันถัด ป้อน saved document ด้วยมือ + เช็ค voice match กับ email จริง. Draft แรก ๆ ใกล้ แต่ formal กว่านิด. เพิ่ม email ตัวอย่างที่ 4 = แก้ได้ — evidence ชนะ description ทุกครั้ง

Optimizer + chain ทั้ง 3 เข้ามาเฉพาะหลังตัวอื่นถือได้เอง — ถ้า build full automation วันแรก, bad angle pick → bad draft → subject line optimize สิ่งผิด — ไม่รู้ว่าตัวไหนใน 3 พัง

Automation ที่มัดทุกอย่างเข้าด้วยกัน

เมื่อ 3 agent ทำงานเดี่ยวได้ — 1 prompt เพิ่มเปลี่ยน chain เป็นสิ่งที่รันโดยไม่ต้องมีเจ้าตัว

“Use these three agents and build an automation that runs every Thursday at 6 AM: Firstly run the Angle Finder. Once its run is completed, hand its angle and proof to the Email Drafter. Finally hand the finished draft to Subject Line and Send Optimizer. Send me the final email, three subject lines, and a recommended send time in one message.”

นี่คือ automation ทั้งหมด — ไม่ใช่ developer workflow ไม่ใช่ API ที่ต้อง configure ด้วยมือ. 5 ประโยคอธิบาย order of operation เป็นภาษาปกติ

สิ่งที่เปลี่ยนจริงในเช้าวันพฤหัส

ก่อนมีระบบ — พฤหัสเริ่มด้วยการนั่งนึกว่าสัปดาห์นี้เกิดอะไรที่ควรเขียน

ตอนนี้ 6:30 น. ก่อนเจ้าตัวเช็ค reply แม้แต่ฉบับเดียว — 1 อีเมล in voice เจ้าตัวแล้ว, 3 subject line ให้เลือก, 1 send time จากสิ่งที่ work จริง. ไม่เดาอะไร ทุกอย่าง sourced จาก audience ตัวเอง

Research มีอยู่แล้ว — นั่งอยู่ใน reply + top-performing post ตลอดเวลา. เจ้าตัวแค่ไม่ turn มันเป็นอีเมลก่อนพฤหัสมาถึง

สิ่งที่ Surprise ที่สุด

คาดว่าจะประหยัดเวลาเขียน — สิ่งที่เปลี่ยนจริงคือการเดา

ก่อนหน้านี้ ทุก part ของ broadcast email มี small guess: เขียนเรื่องอะไร, voice ถูกมั้ย, subject line ไหน land. 3 small guess ทุกสัปดาห์ — จุดที่ email อาจพัง 3 จุด

ตอนนี้แต่ละ decision ทำโดย agent ที่ build มาเฉพาะ decision นั้น + feed real data จาก Threads + autoresponder แทน intuition ตอน 6 โมงเช้า

ระบบไม่ได้ฉลาดกว่าผม — แค่ consistent กว่าผมที่ 6 AM

เมื่อ Agent พลาด

ระบบพังเล็ก ๆ หลายครั้ง แต่ละครั้งสอนอะไรที่ run success ไม่มีทางสอน:

สัปดาห์หนึ่ง: Angle Finder เลือก post ที่ like เยอะแต่ reply แทบไม่มี. Email อ่าน OK แต่ไม่มี proof หรือ story ให้อ้าง. Trace กลับไปเจอว่า Angle Finder weight signal ผิด — แก้ instruction ไม่ใช่ทิ้งทั้งระบบ

อีกสัปดาห์: Drafter สร้าง draft ที่ match voice ถูก แต่พลาด point ของ angle — turn specific story เป็น generic advice. ปัญหาคือ angle ใน saved document ไม่ละเอียดพอ — Angle Finder ส่ง topic โดยไม่ attach proof พอ. แก้ handoff ระหว่าง 2 agent ไม่ใช่แก้ Drafter

ไม่มี failure ไหนแปลว่าระบบไม่ work — แปลว่า link 1 ตัวใน chain ต้อง correct เล็ก. เพราะแต่ละ agent รันเดี่ยวก่อน automation call — หา link นั้นใช้เวลาเป็นนาที ไม่ใช่ full rebuild

Build Version ของคุณเอง

ไม่ต้อง technical. ผู้เขียนไม่ใช่ dev + ทุก prompt ข้างบนเป็น plain English ไม่ใช่ code

สิ่งที่ต้องมี = โครง 3 ส่วนเดียวกัน:

1. ตัวหา angle
2. ตัว draft จาก angle
3. ตัวตัดสินว่าส่งยังไง

+ 1 shared document ที่ให้พวกมัน handoff กัน. ข้ามส่วนใด = กลับไปเดาที่ agent ตัวนั้นควรจะ own

ผู้เขียน build 3 ตัวจากศูนย์ — 1 agent ต่อครั้ง test เดี่ยวก่อน chain. ถ้าอยากเริ่มจาก Skill ที่ build แล้ว: Content Creator’s Claude Skill Stack มี pre-built Skill สำหรับ chain นี้ตรง ๆ — research, writing, optimization ครบ

สรุป

3 agent. 1 automation. ทุก prompt เขียนภาษาปกติ. Research มีอยู่แล้วใน reply + best-performing post — คุณแค่ไม่ turn มันเป็นอีเมลก่อนพฤหัส

แหล่งที่มา: “I Stopped Writing My Newsletter. Here Are the 3 Claude Agents Doing It Instead!” โดย R Dilip Kumar ตีพิมพ์ 4 ก.ค. 2026 บน Medium · อ่านต้นฉบับ