Loop Engineering - จากการเขียน Prompt สู่การทำงานแบบวนซ้ำ

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

มันจะตื่นขึ้นมาเอง ค้นหางานเอง ระบุปัญหาเอง และบันทึกและนำเสนอผลลัพธ์ไว้บนโต๊ะให้คุณตรวจสอบ

คำนำ

แนวคิดของ Loop ไม่ได้เกิดขึ้นมาจากความว่างเปล่า - ในช่วงสัปดาห์เดียวของเดือนมิถุนายน 2026 ผู้เชี่ยวชาญในอุตสาหกรรมสามคนเกือบจะแสดงความคิดเห็นเดียวกันพร้อมกันว่า ถึงเวลาแล้วที่จะเริ่มพัฒนาในระดับนี้

หนึ่งสัปดาห์ต่อมา Andrew Ng ได้วางบทสนทนานี้ไว้ในบริบทที่กว้างขึ้นของ "การสร้างผลิตภัณฑ์จาก 0 ถึง 1" ซึ่งให้ภาพที่ครอบคลุมมากขึ้น

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

ที่มา: HuaShu Orange Book, Loop Engineering: หยุดถามฉันว่ามันคืออะไร (v260615, มิถุนายน 2026)

สัปดาห์ที่ 3 คนจุดชนวน

มิถุนายน 2026: สามคน ซึ่งไม่ได้ประสานงานกัน กล่าวสิ่งที่เกือบจะเหมือนกันภายในระยะเวลาหลายวัน

Peter Steinberger ผู้สร้าง OpenClaw โพสต์สองประโยคบน X ที่มียอดวิวถึง 8.9 ล้านครั้ง:

https://x.com/steipete/status/2063697162748260627

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

Boris Cherny: ฉันไม่ได้สั่ง Claude อีกต่อไปแล้ว ฉันมีลูปที่กำลังทำงานอยู่ พวกมันคือตัวที่สั่ง Claude และหาว่าต้องทำอะไร

Addy Osmani: วิศวกรรมลูปคือการแทนที่ตัวคุณเองในฐานะคนที่สั่งเอเจนต์ คุณออกแบบระบบที่ทำสิ่งนั้นแทน

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

ดังนั้น ลูปจึงกลายเป็นส่วนสำคัญของวิธีที่เราทำให้เอเจนต์ AI ทำงานซ้ำๆ ในระยะยาวเพื่อสร้างซอฟต์แวร์

Andrew Ng จัดเรียงลูปทั้งสามจากชั้นในสุดไปยังชั้นนอกสุดตามช่วงเวลา: ลูปชั้นในสุดเร็วที่สุด และลูปชั้นนอกสุดช้าที่สุด นอกจากนี้ อินพุตของลูปชั้นนอกสุดมาจากเอาต์พุตของลูปชั้นในสุด:

ลูป

ใครเป็นคนรัน

ความยาวรอบ

มันส่งออกอะไรไปยังชั้นนอก

Agentic coding loop

ตัวเอเจนต์เอง

วินาที - นาที

เวอร์ชันที่ทำงานได้

Developer feedback loop

มนุษย์ + เอเจนต์

สิบนาที - ชั่วโมง

วิสัยทัศน์และสเปกผลิตภัณฑ์ที่ชัดเจนขึ้น

External feedback loop

ผู้ใช้ + ทีม

ชั่วโมง - สัปดาห์

ข้อมูลจริงที่พัฒนาวิสัยทัศน์

Andrew Ng ให้แผนที่ตามเวลาแก่เรา: สามลูปที่ทำงานด้วยความเร็วที่แตกต่างกัน Addy Osmani วาดแผนที่ที่สองตามนามธรรม: prompt -> context -> harness -> loop

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

ข้อมูลเชิงลึกที่สำคัญที่สุดเพียงอย่างเดียว: บั๊กเดียวกันมีต้นทุนที่แตกต่างกันในแต่ละชั้น:

ชั้น

สิ่งที่มันสนใจ

คำถามหลัก

Prompt eng.

เขียน prompt

จะพูดอะไรกับโมเดล

Context eng.

สิ่งที่โหลดอยู่ในหน้าต่าง

จะดึงอะไร สรุปอะไร ล้างอะไร

Harness eng.

เตรียมพร้อมสำหรับการรันครั้งเดียว

เครื่องมืออะไร การกระทำอะไร อะไรนับว่าเสร็จ

Loop eng.

การจัดตารางเวลาบน Harness

จะทำให้มันรันตัวเองได้อย่างไร รอบแล้วรอบเล่า

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

สิ่งที่เกิดขึ้นภายในหนึ่งรอบ:

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

1. การตรวจสอบคือการเคลื่อนไหวที่พูดว่า "ไม่"
2. การจัดตารางเวลาคือการเคลื่อนไหวที่ป้อนรอบนี้ไปยังรอบถัดไป

นั่นคือส่วนที่ทำให้มันเป็นลูป

แมปไปยังโปรเจกต์ที่เรากำลังจะสร้าง: ลูปคัดแยกงานตอนเช้าสำหรับทีมเล็กๆ:

การกระทำ

มันทำอะไร

ใน TRIAGE LOOP

Discovery

หาว่ารอบนี้ควรทำอะไร

skill อ่าน CI / issues / commits ล่าสุด

Handoff

ส่งมอบงาน และแยกมันออกจากกัน

แต่ละสิ่งที่พบจะได้รับ worktree ของตัวเอง

Verification

สลับเอเจนต์อื่นมาพูดว่าไม่

เอเจนต์ย่อยตัวที่สองทำหน้าที่เป็นผู้ตรวจสอบ ทดสอบและตรวจสอบ skills

Persistence

เขียนสถานะนอกเหนือจากการสนทนา

PR + Linear ticket + ./state/triage.md

Scheduling

ปล่อยให้มันทำงานรอบแล้วรอบเล่า

GitHub Actions cron ทริกเกอร์ตอน 06:00 น.

แต่ละบทเรียนจาก 5 บทเรียนด้านล่างนี้จะขยายการเคลื่อนไหวหนึ่งครั้ง

ห้าบทเรียน = หนึ่งลูปที่สมบูรณ์

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

บทเรียนที่ 1 Discovery: เขียน SKILL.md สำหรับ morning-triage

Skills ไม่ใช่กำแพงของ prompt

ลองนึกภาพว่า เป็นวันจันทร์เวลา 6 โมงเช้า แล็ปท็อปของคุณปิดอยู่ และ GitHub Action ตื่นขึ้นมาและเรียกใช้ claude --skill morning-triage: สิ่งที่มันอ่าน สิ่งที่มันตัดสินว่าสามารถดำเนินการได้ ที่ที่มันเขียนผลลัพธ์ - ทั้งหมดนี้อยู่ใน SKILL.md ที่คุณกำลังจะเขียน

คำพูดสำคัญของ Osmani: ระบบอัตโนมัติควรทริกเกอร์ skill - ความรู้ของโปรเจกต์ที่เขียนไว้และอัปเดตได้ ไม่ใช่กำแพงของ prompt ที่วางไว้ใน cron job prompt ที่วางไว้จะเน่าเปื่อยอยู่ที่นั่น เพราะไม่มีใครกลับไปอัปเดตสิ่งที่ฝังอยู่ในตารางเวลา

งานของคุณสำหรับบทเรียนนี้: เขียน skill ที่ .claude/skills/morning-triage/SKILL.md ที่อ่านสามแหล่ง (CI / issues / commits) ด้วยตัวเอง ตัดสินใจว่าอะไรคุ้มค่าที่จะทำด้วยตัวเอง เขียนผลลัพธ์ไปยัง ./state/triage.md - และมีส่วน Stop ที่ชัดเจนซึ่งระบุว่าลูปไม่ได้รับอนุญาตให้ทำอะไร

นี่คือตัวอย่างเริ่มต้น - เปลี่ยนสามสิ่งแล้วมันจะเป็นของคุณ:

1# .claude/skills/morning-triage/SKILL.md
2---
3name: morning-triage
4trigger: ถูกเรียกใช้โดยระบบอัตโนมัติรายวัน
5---
6
7## Read   (อินพุตการค้นหา — เปลี่ยนเป็นแหล่งที่ REPO ของคุณมีจริง)
8- CI runs ที่ล้มเหลวนับตั้งแต่รันครั้งล่าสุด      # gh run list --status failure
9- issues ที่เปิดใน 24 ชม. ที่ผ่านมา               # gh issue list --search "created:>=…"
10- commits ที่ถูก merge ตั้งแต่เมื่อวาน              # git log --since=yesterday
11- ./state/triage.md ก่อนหน้า              # การส่งต่อ "เมื่อวาน → วันนี้"
12
13## Judge  (เพดาน — ปล่อยให้ลูปเลือก อย่าส่งรายการให้มัน)
14สำหรับแต่ละตัวเลือก ให้ตัดสินใจ:
15- มันสามารถดำเนินการได้ NOW หรือเป็นแค่สัญญาณรบกวน?
16- มันบล็อกการปล่อยเวอร์ชันหรือไม่? → ลำดับความสำคัญ = P0
17- มันถูกติดตามอยู่แล้วหรือไม่? → ข้ามไป
18เก็บเฉพาะสิ่งที่คุ้มค่ากับ worktree ใน TODAY
19
20## Write  (ความคงทน — เก็บไว้ใน markdown ไม่ใช่แชท)
21ต่อท้าย ./state/triage.md:
22| finding | source | priority | status |
23commit ไฟล์เพื่อให้พรุ่งนี้อ่านได้
24
25## Handoff  (เตรียมพร้อมสำหรับบทเรียนที่ 2)
26สำหรับแต่ละสิ่งที่ถูกเก็บไว้ ให้สร้างบรรทัดงาน:
27  worktree=fix/<slug>
28  goal=<stop-condition>
29
30## Stop   (ส่วน NON-boilerplate เพียงส่วนเดียว — คิดให้ดีตรงนี้)
31ห้าม merge เด็ดขาด ห้ามลบเด็ดขาด
32อะไรก็ตามที่คุณไม่มั่นใจ → ไปที่ ./inbox/ เพื่อให้มนุษย์จัดการ
33ไม่ใช่ PR

สามส่วนที่ทำงานจริงที่นี่:

Read: นี่คืออินพุตของ Discovery - ระบุแหล่งที่มาที่เป็นรูปธรรม ลงไปจนถึงคำสั่งจริง จำไว้ว่า "อ่านบริบท" ไม่ใช่แหล่งที่มา แต่ gh run list --status failure คือแหล่งที่มา

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

Stop: ส่วนเดียวของไฟล์นี้ที่ไม่ใช่ boilerplate ลูปจะทำทุกอย่างที่ skill บอก และ เฉพาะ สิ่งที่ skill บอกเท่านั้น ถ้าคุณไม่เขียน "ห้าม merge" - สักวันหนึ่งมันจะ merge ให้คุณ

ระบุเส้นสีแดงให้ชัดเจน: ห้าม merge, ห้ามลบ, ห้าม push ไปยัง main, อะไรก็ตามที่ไม่แน่ใจให้ไปที่ ./inbox/ เพื่อให้มนุษย์จัดการ ไม่ใช่เข้าไปใน PR

อีกสิ่งหนึ่งที่ควรรู้: โครงสร้าง skill เดียวกันนี้ใช้ได้มากกว่าแค่ morning triage: สลับส่วน Read เป็น "log การเข้าถึงของเมื่อวาน + issues ใหม่ + เวอร์ชัน deploy ปัจจุบัน" แล้วมันจะกลายเป็นลูปตรวจสอบสุขภาพเว็บไซต์ตอนเย็น เพิ่มหนึ่งบรรทัดใน Judge - "นี่คือ regression จากเมื่อวานหรือไม่?" - แล้วมันจะเพิ่มการเปรียบเทียบข้ามวัน

โรคที่บทเรียนนี้ป้องกัน - Blind Loop:

สิ่งที่พบบ่อยที่สุดที่ "ดูเหมือนลูปแต่ไม่ใช่": ลูปทำงาน แต่คุณยังคงมอบหมายงานทุกเช้า ("เฮ้ ดูบั๊กสามตัวนี้สิ") นั่นคือระบบอัตโนมัติของการดำเนินการ ไม่ใช่ระบบอัตโนมัติของการค้นหา

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

วิธีแก้ไข: ใส่ Judge ไว้ใน skill และปล่อยให้มันเลือกงานของวันนี้ด้วยตัวเอง

ก่อนที่จะไปต่อ ให้ตอบสามข้อนี้:

1/ ส่วน Stop ของคุณมีกี่บรรทัด?

ถ้ามันแค่ "ห้าม merge" - เพิ่มอีกหนึ่งบรรทัด: มีอะไรอีกที่ลูปนี้ไม่ควรทำเพื่อคุณ? (ห้ามปิด issues / ห้าม push ไปยัง main / ห้ามรับงานมากกว่า 3 ชิ้นในครั้งเดียว..)

2/ เขียนบรรทัดแรกของ Read ใหม่เป็นคำสั่งที่ทำงานได้จริงใน PROJECT ของคุณ

**3/ ถ้า skill นี้ไม่มีการเปลี่ยนแปลงเป็นเวลาหนึ่งปี - จะเกิดอะไรขึ้น?

**ทีนี้ลองเปรียบเทียบ: จะเกิดอะไรขึ้นกับกำแพงของ prompt ที่วางไว้ใน cron job เป็นเวลาหนึ่งปี?

บทเรียนที่ 2 Handoff: ส่งมอบงาน และแยกมันออกจากกัน

skill ของบทเรียนที่ 1 เพิ่งทำงานเสร็จ ./state/triage.md ตอนนี้มีสิ่งที่สามารถดำเนินการได้ 5 รายการ ความคิดที่เป็นธรรมชาติที่สุดต่อไป - ส่งเอเจนต์ 5 ตัวพร้อมกัน ไปให้เร็ว ขั้นตอนนั้นคือวิธีที่คุณสร้าง Tangled Loop: เอเจนต์หลายตัวแก้ไขไฟล์เดียวกันในไดเรกทอรีเดียวกัน และวัน merge จะกลายเป็นการขุดค้นทางโบราณคดี

ยาแก้พิษคือหนึ่งบรรทัด: ทุกสิ่งที่พบจะได้รับ worktree ของตัวเอง

git worktree เป็นกลไก git ในตัว: หนึ่ง repo, ไดเรกทอรีการทำงานอิสระหลายไดเรกทอรี แต่ละไดเรกทอรี checkout ไปยัง branch ของตัวเอง git worktree add ../fix-auth fix/auth จะเปิดพื้นที่ทำงานที่แยกออกจากกันอย่างสมบูรณ์ที่ ../fix-auth การ build, แก้ไข, ทดสอบ - ไม่มีอะไรแตะต้องใคร หนึ่ง worktree ต่อหนึ่งสิ่งที่พบ = เอเจนต์แยกจากกันทางกายภาพ

งานของคุณสำหรับบทเรียนนี้: เขียนสคริปต์ที่อ่านแต่ละสิ่งที่พบจาก ./state/triage.md, เปิด worktree ที่แยกออกจากกันต่อหนึ่งสิ่งที่พบ (ตั้งชื่อว่า fix/<slug>), ส่งเอเจนต์ไปร่างการแก้ไขภายในนั้น - และตั้งค่าขีดจำกัดแบบขนานเพื่อไม่ให้มันสร้างงานไม่รู้จบ

1# อ่าน state/triage.md, หนึ่ง worktree ต่อหนึ่งสิ่งที่พบ
2# เปลี่ยน: MAX_PARALLEL เป็นสิ่งที่เครื่อง / ค่าใช้จ่ายของคุณรับไหว
3MAX_PARALLEL=3
4
5# เปลี่ยน: การแยกวิเคราะห์ให้ตรงกับคอลัมน์ triage.md จริงของคุณ
6findings=$(awk -F'|' 'NR>2 && $5 ~ /open/ {print $2}' \
7           state/triage.md | head -n $MAX_PARALLEL)
8
9for finding in $findings; do
10  slug=$(echo "$finding" | tr ' ' '-' | tr -cd '[:alnum:]-')
11
12  # บรรทัดสำคัญ: การแยกทางกายภาพต่อเอเจนต์
13  git worktree add ../wt-$slug -b fix/$slug
14
15  # เปลี่ยน: goal คือเงื่อนไขหยุดที่ผู้ประเมินของบทเรียนที่ 3 จะอ่าน
16  claude --worktree ../wt-$slug \
17    --goal "tests in tests/$slug pass and lint is clean" \
18    "ร่างการแก้ไขสำหรับ: $finding" &
19done
20
21wait   # รอให้เอเจนต์แบบขนานทั้งหมดทำงานเสร็จ
22
23# กฎปิดท้าย: เอเจนต์ไม่เคย auto-merge — worktrees รอ
24# ประตูมนุษย์ในบทเรียนที่ 5
25echo "worktrees ทั้งหมดพร้อมสำหรับการตรวจสอบ:"
26git worktree list

กฎที่สำคัญที่นี่: ห้ามทำงานบน main เด็ดขาด

Main คือลานลงจอดสำหรับการตรวจสอบของมนุษย์ - ไม่ใช่โต๊ะทำงานของเอเจนต์ เอเจนต์ทั้งหมดอาศัยอยู่บน worktree fix/*

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

Merge คือการตัดสินใจของมนุษย์: Stripe รัน PR มากกว่า 1,000 ตัวต่อสัปดาห์ผ่านลูปแบบนี้ และมนุษย์ยังคงตรวจสอบทุกตัว มนุษย์ไม่ได้ออกจากกระบวนการ - พวกเขาเปลี่ยนโต๊ะ: จากการเขียนโค้ดเป็นการตรวจสอบโค้ด

และรายละเอียดหนึ่งจากกรณีของ Stripe ที่ควรค่าแก่การขโมย: พวกเขาใช้โมเดลที่ เล็กกว่า กับเกตที่กำหนดตายตัวอย่างเคร่งครัด แทนที่จะใช้โมเดลที่ใหญ่ที่สุดที่มีอยู่

บทเรียน: เกตการตรวจสอบที่แน่นหนานั้นดีกว่าพลังของโมเดลดิบสำหรับงานลูป

โรคที่บทเรียนนี้ป้องกัน - Tangled Loop:

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

วิธีแก้ไข: ทุกงานได้รับ worktree ของตัวเอง ห้ามแชร์ไดเรกทอรีการทำงานระหว่างเอเจนต์

ก่อนที่จะไปต่อ ให้ตอบสามข้อนี้:

**1/ คุณตั้งค่า MAX_PARALLEL เป็นเลขอะไร - และเพราะอะไร?

**(เงิน? เครื่อง? หรือ "ฉันสามารถตรวจสอบ PR ได้จริงกี่ตัว"?)

**2/ ถ้า worktree พัง - เอเจนต์ออกโดยไม่แตะต้องอะไร

**ไฟล์สถานะของวันพรุ่งนี้ควรบันทึกอะไรเกี่ยวกับมัน?

**3/ Stripe ใช้โมเดลที่เล็กกว่า + เกตที่กำหนดตายตัวอย่างเคร่งครัด

**แทนที่จะใช้โมเดลที่ใหญ่ที่สุด ตัวเลือกนั้นหมายความว่าอย่างไรสำหรับ LOOP ของคุณ?

บทเรียนที่ 3 Verification: ติดตั้งประตูที่พูดว่า "ไม่" (บทเรียนที่หนักที่สุด)

นี่คือการเคลื่อนไหวที่ยากที่สุดในวิศวกรรมลูป และมันสมควรได้รับความพยายามมากกว่าบทเรียนอื่นๆ

Prithvi Rajasekaran วิศวกรของ Anthropic ซึ่งทำงานกับแอปพลิเคชันเอเจนต์ที่ทำงานระยะยาว สังเกตเห็นบางอย่าง: ขอให้เอเจนต์ให้คะแนนโค้ดที่มันเพิ่งเขียน และมันจะชื่นชมตัวเองเกือบทุกครั้ง - แม้ว่ามนุษย์จะมองแวบเดียวก็เห็นว่ามันธรรมดา

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

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

วิธีแก้ไขของ Rajasekaran ในคำพูดของเขาเอง:

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

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

การเปรียบเทียบมาจาก GAN: เครือข่ายหนึ่งสร้าง อีกเครือข่ายหนึ่งโจมตี: ผู้สร้างและผู้ตรวจสอบ กฎการธนาคารเก่าแก่: คนที่โอนเงินและคนที่อนุมัติต้องเป็นคนละคนกัน

งานของคุณสำหรับบทเรียนนี้ - เขียนสองสิ่ง:

1) ระบบ prompt สำหรับผู้ประเมินที่ .claude/agents/reviewer.md โดยมีห้าส่วน: ROLE + ASSUME + CHECK + USE + VERDICT

2) คำสั่ง /goal ที่ประกาศเงื่อนไขหยุดของลูปนี้ - ตัดสินโดย โมเดลใหม่ที่แยกจากกัน ไม่ใช่โดยผู้สร้าง

1# .claude/agents/reviewer.md  (เปลี่ยน 3 สิ่ง)
2ROLE: ผู้ตรวจสอบโค้ดเชิงโต้แย้ง
3ASSUME: โค้ดนี้มีข้อบกพร่องจนกว่าจะพิสูจน์ได้เป็นอย่างอื่น
4อย่าชมเชย หาสิ่งที่ล้มเหลว
5
6# เปลี่ยน: เรียงลำดับ CHECK ตามโหมดความล้มเหลวจริงของโปรเจกต์ของคุณ
7# ตรวจสอบที่รันได้ก่อน
8CHECK, ตามลำดับ:
9  1. มันทำงานได้หรือไม่?  (execute, อย่าอ่าน)
10  2. Tests: รันมัน, วางผลลัพธ์จริง
11  3. Edge cases ที่ผู้เขียนข้ามไป
12  4. พฤติกรรมตรงกับ ticket หรือไม่?
13
14# เปลี่ยน: MCP ใดขึ้นอยู่กับสิ่งที่คุณกำลังทดสอบ —
15# frontend → Playwright, API → curl/httpie
16USE Playwright MCP: เปิดหน้า, คลิก,
17จับภาพหน้าจอ, ตรวจสอบ DOM
18ตัดสินพฤติกรรม ไม่ใช่เจตนา
19
20VERDICT: PASS ก็ต่อเมื่อทุก check ยืนยัน
21         มิฉะนั้น REJECT + แสดงรายการแต่ละเหตุผล

1# เงื่อนไขหยุด — ตัดสินโดยโมเดลขนาดเล็กใหม่ ไม่ใช่ผู้สร้าง
2# เปลี่ยน: สลับเป็นเงื่อนไขที่ตรวจสอบได้จริงของสิ่งที่คุณพบ
3/goal tests ทั้งหมดใน test/auth ผ่านและขั้นตอน lint สะอาด
4
5# ระวัง: /goal และ /loop ไม่ใช่สิ่งเดียวกัน
6#   /loop = รันซ้ำตามช่วงเวลา (ไม่มีการตัดสินหยุด — อันตราย)
7#   /goal = รันจนกว่าโมเดลใหม่จะตัดสินว่าเงื่อนไขเป็นจริง

สองเอเจนต์, ควรเป็นสองโมเดล: "โมเดลเดียวกัน, prompt ต่างกัน" มักจะรักษาจุดบอดเดียวกันไว้ สลับโมเดลด้วยถ้าทำได้

ความสงสัยเริ่มต้น: ฐานเริ่มต้นของผู้ประเมินคือ ASSUME BROKEN - ความไว้วางใจต้องได้รับจากการผ่านการตรวจสอบ ไม่ใช่ให้โดยค่าเริ่มต้น

ตัดสินพฤติกรรม ไม่ใช่เจตนา: "JSX นี้ดูใช้ได้" และ "ฉันคลิกปุ่ม, หน้านำทางไป, นี่คือภาพหน้าจอ" คือสองจักรวาลที่แตกต่างกัน ผู้ประเมินต้อง ลงมือทำ - รัน tests, คลิกหน้า, ไม่อ่านโค้ดและใช้ความรู้สึก

ปฏิเสธพร้อมเหตุผล: REJECT ที่ไม่มีเหตุผลที่ระบุไว้ไม่ใช่การปฏิเสธ - ผู้สร้างไม่มีทางรู้ว่าจะแก้ไขอะไร

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

โรคที่บทเรียนนี้ป้องกัน - Nodding Loop:

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

ก่อนที่จะไปต่อ ให้ตอบสามข้อนี้:

1/ ผู้ประเมินของคุณเป็นโมเดลเดียวกันกับ prompt ที่ต่างกัน หรือเป็นโมเดลที่แตกต่างกัน? เพราะอะไร?

2/ แปล "ตัดสินพฤติกรรม ไม่ใช่เจตนา" เป็นประโยคที่เป็นรูปธรรม

ของโปรเจกต์คุณ: "ผู้ประเมินของฉันไม่อ่านโค้ด มันรัน _____, และจะ PASS ก็ต่อเมื่อมันเห็น _____"

3/ โมเดลใหม่ที่ "ใกล้เคียง" มีโอกาสเท่าไหร่ที่จะ PASS เงื่อนไข /goal ของคุณอย่างผิดพลาด?

ถ้าโหมดความล้มเหลวที่น่ากลัวที่สุดของคุณคือ X - เพิ่ม check สำหรับ X ในเงื่อนไขหยุดเดี๋ยวนี้

บทเรียนที่ 4 Persistence: ทำให้งานของวันนี้อยู่รอดไปถึงวันพรุ่งนี้

บทเรียนที่ 3 เสร็จสิ้น ผู้ประเมินของคุณตัดสินสามสิ่งที่พบ - สอง PASS, หนึ่ง REJECT คำถาม: คำตัดสินสามข้อนั้นอยู่ที่ไหนในตอนนี้?

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

นั่นคือ Amnesiac Loop - ทุกวันเริ่มต้นจากจุดเดิม

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

สองสิ่งนี้สับสนกันตลอดเวลา ดังนั้นให้จำความแตกต่างให้แม่น:

CONTEXT = หน้าต่างที่เอเจนต์เห็นในรอบนี้ -> ถูกล้างทุกครั้งที่รีเฟรช

MEMORY = สถานะที่อยู่ข้ามรอบและข้ามวัน -> เขียนลงดิสก์ (markdown / DB / board)

ลูปเชื่อมต่อวันนี้ -> พรุ่งนี้ผ่าน MEMORY เท่านั้น

งานของคุณสำหรับบทเรียนนี้:

1. สร้าง ./state/triage.md โดยมีอย่างน้อย 4 คอลัมน์ (finding / source / priority / status) - skill ของบทเรียนที่ 1 เขียนมัน, worktrees ของบทเรียนที่ 2 อ่านมัน
2. เชื่อมต่อ connector (MCP): คำตัดสิน PASS จะเปิด PR โดยอัตโนมัติ, คำตัดสิน REJECT จะอัปเดต ticket โดยอัตโนมัติ
3. ตรวจสอบว่าลูปของวันพรุ่งนี้สามารถอ่านสถานะของวันนี้กลับมาได้จริง

1# ./state/triage.md  (หน่วยความจำของลูป — เปลี่ยนตามต้องการ)
2
3| finding         | source       | priority | status     |
4|-----------------|--------------|----------|------------|
5| auth test flaky | CI #4821     | P0       | กำลังแก้ไข |
6| null deref      | issue 92     | P1       | PR เปิดอยู่ |
7| stale dep       | commit a3f9c | P2       | inbox      |
8
9# ขยายคอลัมน์ตามต้องการ: last_seen, retry_count, assigned_to
10# ไฟล์นี้ต้องถูก commit ไปยัง repo —
11# มิฉะนั้น runner บนคลาวด์ของวันพรุ่งนี้จะไม่เห็นมัน

1// .mcp/connectors.json — เสียบปลั๊กลูปเข้ากับโลกภายนอก
2{
3  "github_pr": {
4    "type": "mcp",
5    "on_event": "evaluator.verdict.PASS",
6    "action": "open_pr",
7    "branch": "fix/${slug}",
8    "auto_merge": false        // ← ต้องเป็น false. ประตูมนุษย์ = บทเรียนที่ 5
9  },
10  "linear": {
11    "type": "mcp",
12    "on_event": "evaluator.verdict.REJECT",
13    "action": "update_ticket",
14    "fields": { "status": "Blocked", "reason": "${verdict.reasons}" }
15  }
16}

ทำไมแต่ละคอลัมน์ถึงสำคัญ: ไม่มี source -> คุณไม่สามารถตรวจสอบได้ว่าสิ่งที่พบมาจากไหน ไม่มี priority -> คุณไม่สามารถจัดลำดับงานได้ ไม่มี status -> พรุ่งนี้ไม่สามารถรับไม้ต่อได้

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

วินัยเงียบๆ ที่มาพร้อมกับความคงทน - อ่านตัวอย่าง, เสมอ

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

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

โรคที่บทเรียนนี้ป้องกัน - Amnesiac Loop:

ลูปพบงานที่ดี, ทำมัน, แล้วลืมว่ามันทำ - เพราะผลลัพธ์อยู่ในบริบทที่ถูกล้างเท่านั้น รอบถัดไปมันค้นพบงานเดียวกันอีกครั้ง หรือแย่กว่านั้น - ทำซ้ำและทับการลองครั้งแรก

อาการ: ไม่มีความคืบหน้าสะสม, ทุกวันเริ่มต้นจากที่เดิม วิธีแก้ไข: ไฟล์สถานะบนดิสก์

ก่อนที่จะไปต่อ ให้ตอบสามข้อนี้:

1/ แปล "memory ≠ context" เป็นประโยคที่เป็นรูปธรรมหนึ่งประโยค

จากโปรเจกต์ของคุณเอง: "_____ ของฉันคือ memory, _____ ของฉันคือ context"

2/ ลูปของวันพรุ่งนี้ตื่นขึ้นมา - COLUMN ใดของ state.md ที่

**มันอ่านก่อนเพื่อตัดสินการเคลื่อนไหวแรก? คุณตั้งชื่อคอลัมน์นั้นถูกต้องหรือไม่ หรือคุณแค่ฝังกับระเบิดไว้ให้มัน?

3/ วินัย: คุณจะอ่าน PR ตัวอย่างวันละหนึ่งตัวเวลาไหน?

**ตั้งการเตือนในปฏิทินเดี๋ยวนี้ - นี่คือสัญญากับตัวคุณเอง

บทเรียนที่ 5 Scheduling: ทำให้มันเป็นจริง, ทำให้มันปลอดภัย, เปิดประตูไว้หนึ่งบาน

บทเรียนที่ 1-4 ได้รับการติดตั้งแล้ว แต่ลูปยังคงหยุดทันทีที่คุณหยุดกดปุ่ม การเคลื่อนไหวสุดท้ายคือคำกริยาหนึ่งคำ: แขวนมันไว้บนทริกเกอร์

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

ดังนั้นบทเรียนนี้จึงทำสามสิ่งจริงๆ: แขวนทริกเกอร์, ตั้งค่าขีดจำกัด, เปิดประตูมนุษย์ไว้

อย่างแรก - เลือกตัวจัดตารางเวลาของคุณ:

1Cloud (GH Actions)   Desktop scheduled   /loop (in CC)
2รันที่ไหน          cloud                เครื่องของคุณ        เครื่องของคุณ
3ต้องเปิดเครื่อง?      ไม่จำเป็น           จำเป็น              จำเป็น
4ต้องเปิดเซสชัน?      ไม่จำเป็น           ไม่จำเป็น           จำเป็น
5ช่วงเวลาขั้นต่ำ       1 ชั่วโมง            1 นาที              1 นาที
6เห็นไฟล์ local?      ไม่                  ใช่                 ใช่

คำถามชี้ขาด: งานนี้สามารถออกจากแล็ปท็อปของคุณได้หรือไม่?

1"ตรวจสอบ dev server ในเครื่องของฉันทุกนาที"
2   → ต้องเป็น local + /loop (ช่วงเวลา 1 ชม. ของ cloud ไม่สามารถเข้าถึงได้)
3
4"สแกน GitHub issues ตอนตี 3 และเปิด PR"
5   → ต้องเป็น cloud (แล็ปท็อปของคุณปิดอยู่ — ลูปไม่สามารถ
6     รอมันได้)

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

ภารกิจของคุณในบทเรียนนี้:

1. เขียนไฟล์ .github/workflows/triage.yml พร้อมทริกเกอร์ cron ที่เรียกใช้สกิล morning-triage
2. ตั้งค่าขีดจำกัดสามอย่าง: งบประมาณต่อรอบ, งบประมาณรายวัน, และจำนวนครั้งที่ลองใหม่สูงสุด
3. จบเวิร์กโฟลว์ด้วยกฎ: PR จะไม่ถูกผสานอัตโนมัติ, สิ่งที่ไม่แน่ใจจะถูกส่งไปที่ ./inbox/

1# .github/workflows/triage.yml  (เปลี่ยน 3 อย่าง)
2name: morning-triage
3
4on:
5  schedule:
6    - cron: '0 6 * * *'        # เปลี่ยน: 06:00 น. ตามโซนเวลาของคุณใน UTC
7
8jobs:
9  triage:
10    runs-on: ubuntu-latest
11    timeout-minutes: 45          # ← ขีดจำกัดต่อรอบ · เปลี่ยน
12    permissions:
13      contents: write
14      pull-requests: write
15    steps:
16      - uses: actions/checkout@v4
17
18      - name: morning triage
19        env:
20          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
21          DAILY_BUDGET_USD: '20'   # ← ขีดจำกัดรายวัน · เปลี่ยน
22          MAX_RETRIES: '3'          # ← ขีดจำกัดการลองใหม่ · เปลี่ยน
23        run: |
24          claude --skill morning-triage \
25            --max-retries "$MAX_RETRIES" \
26            --daily-budget-usd "$DAILY_BUDGET_USD"
27
28      - name: เปิด PR (ห้ามผสานอัตโนมัติเด็ดขาด)
29        run: |
30          # PR จะเปิดโดยอัตโนมัติ การผสานยังคงเป็นหน้าที่ของมนุษย์
31          gh pr create --draft --base main \
32            --title "[loop] $(date +%F) triage" \
33            --body-file ./state/triage.md
34          # ไม่มี `gh pr merge` ที่นี่ — ตั้งใจ
35
36      - name: ส่งสิ่งที่ไม่แน่ใจไปที่ inbox
37        run: |
38          ls ./inbox/ && echo "มีรายการรอการตรวจสอบจากมนุษย์"

สามกฎที่จะทำให้ลูปนี้ยังคงทำงานได้ในเดือนที่หก:

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

เพื่อให้เห็นภาพ: Uber จำกัดวิศวกรไว้ที่ $1,500 ต่อคนต่อเครื่องมือต่อเดือนหลังจากใช้งบประมาณ AI หมดภายในสี่เดือน ขีดจำกัดต่อลูปของคุณคือบทเรียนในระดับที่ละเอียดกว่าของเรื่องนั้น

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

ตรวจสอบว่ามันตื่นขึ้นมาจริงๆ รันมันอย่างน้อย 3 รอบ (นับรวมการรันแบบทดสอบด้วย) ความล้มเหลวที่พบบ่อยที่สุด: สวยงามในวันสาธิต แต่ตายภายในวันพฤหัสบดี "การรันครั้งล่าสุดคือวันที่สาธิต" คือสัญญาณวินิจฉัยของ Manual Loop

ใช้ได้เหมือนกันนอก Claude Code - ความสามารถไม่ได้ผูกขาดกับผู้ขายรายใด แค่เปลี่ยนชื่อ:

1ความสามารถ             Claude Code          Codex
2การจัดตารางเวลา          /loop · worker       แท็บ Automations
3รันจนถึงเงื่อนไข         /goal                automation rerun + judge
4การแยกแบบขนาน           --worktree           background worktree
5เอเยนต์ย่อย              .claude/agents/      .codex/agents/
6การเชื่อมต่อภายนอก       MCP + plugins        MCP connector
7สกิลที่ชัดเจน            SKILL.md             $skill-name
8รันโดยไม่ต้องเปิดเครื่อง  Cloud Routines       cloud (ตามแผน)

คำถามไม่เคยเป็น "ผู้ขายรายไหน" แต่เป็น "ครบทั้งหกความสามารถหรือยัง"

โรคที่บทเรียนนี้ป้องกัน - Manual Loop:

สร้างสี่การเคลื่อนไหวได้อย่างสวยงาม แต่ไม่มี cron มันไม่ใช่ลูป - มันคือสคริปต์ที่คุณรันครั้งเดียวแล้วลืม

วิธีแก้: แนบทริกเกอร์ใดๆ ที่ไม่ต้องพึ่งพาคุณในการจำ

ก่อนจะปล่อย ให้ตอบสามข้อนี้:

1/ ตัวเลขที่แน่นอนของขีดจำกัดสามอย่างของคุณคืออะไร?

ถ้าบั๊กทำงานทั้งคืน - ขีดจำกัดไหนจะรับแรงกระแทกก่อน? ถ้าไม่มีเลย... นั่นบอกอะไรคุณ?

2/ ประตูสำหรับมนุษย์ของคุณหน้าตาเป็นอย่างไร?

(การตรวจสอบ PR / อินบ็อกซ์ / ตัวอย่างรายวัน / การกระทบยอดรายสัปดาห์?) เขียนมันลงไป = เซ็นสัญญากับตัวเอง

3/ คำถามปิดท้าย: อีกหกเดือนนับจากนี้ ลูปนี้จะทำให้คุณแข็งแกร่งขึ้น (ความเข้าใจ, การตัดสินใจ, ความรู้สึกต่อระบบ) หรือจะทำให้คุณกลายเป็นคนดูแลเครื่องจักรที่คุณอ่านไม่ออก? แผนของคุณที่จะหลีกเลี่ยงอย่างที่สองคืออะไร?

หนี้ 4 ประการและการคงไว้ซึ่งความเป็นวิศวกร

ลูปของคุณถูกสร้างขึ้นแล้ว: มันตื่นขึ้น, ค้นหางาน, วิจารณ์ตัวเอง, จดจำ, และจัดตารางเวลาสำหรับวันพรุ่งนี้ของมันเอง

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

1หนี้จากการตรวจสอบ        ผลลัพธ์ที่ไม่ถูกปฏิเสธกองสุมกัน
2ความเข้าใจที่เสื่อมถอย    โค้ดเบสเพิ่มขึ้น แผนที่ทางจิตของคุณไม่เพิ่มตาม
3การยอมจำนนทางความคิด     "ฉันไม่อยากตรวจสอบอย่างละเอียดอีกแล้ว"
4โทเค็นทะลัก              บั๊กทำงานทั้งคืน → คุณเห็นมันเป็นบิล

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

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

• ตัวประเมินของฉันปฏิเสธจริงๆ - มันไม่ใช่ของตกแต่ง
• ฉันอ่าน PR ตัวอย่างวันละหนึ่งอันและสามารถอธิบายได้ว่ามีอะไรเปลี่ยนแปลง
• ฉันยังคงนิสัยในการพูดว่า "นี่มันผิด"
• ขีดจำกัดของฉันถูกตั้งค่า ก่อน การรันครั้งแรก ไม่ใช่หลังจากบิลแรก

และนี่คือส่วนที่ตัดสินทุกอย่าง:

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

อีกคนใช้ลูปเดียวกันนี้โดยเฉพาะเพื่อไม่ต้องเข้าใจอะไรอีกเลย - หกเดือนต่อมา คนแรกฉลาดขึ้น และคนที่สองกลายเป็นคนดูแลเครื่องจักรที่พวกเขาอ่านไม่ออก

Addy Osmani: "สร้างลูป แต่สร้างมันเหมือนคนที่ตั้งใจจะคงความเป็นวิศวกร - ไม่ใช่แค่คนที่กดปุ่มเริ่มต้น"

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

ลูปคือตัวคูณที่ซื่อสัตย์:

นำความเข้าใจมา - มันจะขยายความเข้าใจ

นำความขี้เกียจมา - มันจะขยายความขี้เกียจ

ตัดสินใจว่าคุณต้องการให้อะไรถูกขยาย - ก่อนที่คุณจะสร้างมัน

โปรดติดตาม!

ขอให้โชคดี :)