ช้า ๆ ก็คือ คำตอบในยุคของเอเจ้นต์
หัวเรื่องต้นฉบับ: ความคิดเกี่ยวกับการชะลอลงมือ
ผู้เขียนต้นฉบับ: Mario Zechner
การแปล: Peggy, BlockBeats
บันทึกของบรรณาธิการ: ณ ปัจจุบันที่ปัญญาประดิษฐ์รุนแรงเข้าสู่วงการซอฟต์แวร์, แรงบันดาลใจของอุตสาหกรรมกำลังเลื่อนจาก "ความสามารถที่น่าทึ่" ไปสู่ "ความวิตกกังวล" การเขียนไม่เร็วพอ, การใช้ไม่เยอะพอ, การอัตโนมัติไม่ครอบคลุมถึงมายังสร้างความดันที่น่าห่วงให้กับผู้คน แต่เมื่อตัวแบบเขียนโค้ด (Agent) เข้าสู่สภาพแวดล้อมการผลิตจริงๆ, ปัญหาบางประการที่สมควรต้องหมองขึ้นมา: ข้อผิดพลาดถูกขยายใหญ่ขึ้น, ความซับซ้อนเริ่มห้อยเสื่อ, และระบบเริ่มเป็นอย่างที่ไม่สามมือ, การเสริมความเชื่อมั่นไม่ได้ทำให้คุณภาพดีขึ้นตามอัตราที่ความจำเป็น
บทความนี้ทำมาจากปฏิบัติจริงของบุคคลในสายงาน, มองการกระแส "การเขียนโค้ดทางอุตสาหกรรม (agentic coding)" ครั้งนี้อย่างมีสติ. ผู้เขียนชี้ให้ทราบว่าตัวแบบ (Agent) ไม่ได้เรียนรู้จากข้อผิดพลาดเป็นแบบมนุษย์, ในสภาวะที่ขาดหายไปจุดขวดและกลไกขอตอบรับ, ปัญหาเล็กๆ ถูกขยายอย่างรวดเร็ว และในโครงสร้างโค้ดที่ซับซ้อน, มุมมองแบบใกล้ชิดและความสามารถในการเรียกคืนที่จำกัดของตัวแบบ, ยิ่งก่อให้เกิดความสับสนในโครงสร้างของระบบมากขึ้น. ประเด็นหลักของปัญหาเหล่านี้ไม่ได้อยู่ในเทคโนโลยีตนเอง, แต่อยู่ที่ความมีพิสูจน์ กับตัวควบคุมของมนุษย์ที่ถอดความข้อควบคุมออกเร็วเกินไปจากการอยากให้อื่นรับ
ดังนั้น, ไม่ควรตกเป็นเวร "จำเป็นที่ต้องเป็นไปด้วย AI หรือไม่หรอก" แต่ตัวแทนมีความสัมพันธ์กับเครื่องมือแบบให้ความรับผิดชอบในงานระดับท้องถิ่นและควบคุมได้, ส่วนการออกแบบระบบ, การควบคุมคุณภาพ, และการตัดสินใจสำคัญให้อยู่บนมือของตนเอง ในขั้นตอนนี้, "การชะลอลงมือ" จึงกลายเป็็นความสามารถหนึ่ง, หมายถึงคุณยังเข้าใจระบบ, สามารถทำตัวว่าง, และยังคงความควบคุมงานอยู่.
ในยุคของเครื่องมือที่ก้าวกระโดดไปข้างหน้าต่อไป, สิ่งที่แท้จริงที่ขาดเป็นบางทีไม่ใช่ประสิทธิภาพในการสร้าง, แต่ความสามารถในการรับความซับซ้อน, และความมั่นคงในการตัดสินใจระหว่างประสิทธิภาพและคุณภาพ
ด้านล่างคือข้อความต้นฉบับ:
ใบหน้าของเต่าก็คือท่าเมื่อฉันมองวงการนี้
ประมาณปีที่แล้ว, ตัวแบบการเขียนโค้ด (Agent) ที่จริงสามารถช่วยคุณ "สร้างโปรเจกต์จากเริ่มจนจบ" เริ่มออกมา มีเครื่องมือมาก่อนหน้าเช่น Aider, Cursor ในช่วงเวลาก่อนนี้เสมือนนั้นมีมือช่วย, แต่ไม่ใช่ "ตัวแทน" อุปกรณ์รุ่นใหม่น่าทฤษฎในระดับสูง, และมีคนหลายคนใช้เวลาว่างมากมายสร้างโปรเจกต์ที่ต้องการทำตลอดเวลา
ผมว่ามันไม่มีปัญหาเมื่อทำงานในเวลาว่างกัน. การทำสิ่งของในเวลาว่างเป็นสิ่งที่มีความสุข, และบ่อยๆ คุณไม่จำเป็นต้องกังวลเรื่องคุณภาพโค้ดและการบำรุงรักษาไปทุกๆครั้ง. นอกจากนี้, มันยังให้ทางเลือกในการศึกษาเทคโนโลยีใหม่
ระหว่างช่วงวันหยุดคริสต์มาส, Anthropic และ OpenAI ยังได้ปล่อย "โควตาฟรี" บางส่วน เหมือนเกมสล็อตที่ดึงคนเข้ามา สำหรับหลายคนนี่เป็นครั้งแรกที่ได้สัมผัส "ต้นฉบับของเอเจนต์เขียนโค้ด" ผู้เข้าร่วมกำลังเพิ่มขึ้น
ในปัจจุบันเอเจนต์เขียนโค้ดเริ่มเรียกเข้ารหัสของการใช้งาน 12 เดือนผ่านไป, เราเริ่มเห็นผลลัพธ์จากการ"ความก้าวหน้า" ด้านล่างคือความคิดเห็นของฉันในปัจจุบัน.
ทุกอย่างเสียหาย
แม้จะมีแค่คำพูดจาการประสบประสบการณ์ แต่ซอฟต์แวร์ในปัจจุบันกล่าวให้เราเห็นถึงความรู้สึก "เสี่ยงทุกเวลา" ความพร้อมใช้งาน 98%, ที่กำลังเปลี่ยนจากการพบข้อยกเว้นเป็นอย่างปกติ แม้จะใช้บริการขนาดใหญ่ อินเตอร์เฟซผู้ใช้มีข้อบกพร่องต่างๆ ที่ทีมตรวจปฏิบัติแล้วจะสามารถจับได้
ฉันยอมรับว่าสภาพการณ์เช่นนี้มีอยู่ก่อนที่มีเอเจนต์ แต่ตอนนี้ปัญหามีการเร่ง
เราไม่มีโอกาสเห็นภาพเดิม แต่บางครั้งจะมีข้อมูลรั่วออกมา เช่น ละครอินทราเป็น "การหยุดทำงานของ AWS ที่เกิดจาก AI" มาทันที Amazon Web Services ที่รีบชี้แก้อภาพ เพิ่มว่าต่อจากระบบจะเริ่มทำสร้างแผนเรียกคืนใหม่ภายใน 90 วัน
Satya Nadella (CEO ของ Microsoft) ก็เริ่มเน้นไปที่บอกว่าในบริษัทมีซอฟต์แวร์เยอะขึ้นโดยใช้ AI สร้าง แม้จะไม่มีข้อสนับสนุนโดยตรง แต่มีความรู้สึกว่าคุณภาพของ Windows กำลังลดลง แม้กระทั่งจากเรื่องบล็อกที่ Microsoft ตีพิมพ์ เห็นว่าพวกเขาเชื่อฟังมัน
บริษัทที่บอกว่า "ผลิตภัณฑ์ 100% โค้ดมาจาก AI" เกือบทุกครั้งจะได้ผลิตภัณฑ์ที่แย่ที่สุดจากดุลอย่าง GB รั่วไหล, ปัญหาUI, ของความสมบูรณ์ และความล่มคงบ่อยที่ทำให้ผู้การค้าไม่ต้องการแม้ความฝัน "การรับรองด้วยคุณภาพ" และไม่ใช่การประเมินบวกจาก"เอเจนต์เขียนโค้ดให้ทำให้หมดซูบ"
เปิดเผย, คุณจะได้ยินเสียงที่บริษัทใหญไหละทีบ หรือทีที ก็นั่งพูดว่าอยู่ช่วยให้ "เอเจนต์เขียนโค้ด" จับคมมัดวางตัวตายได้ ไม่มีการถอดวิเดีย ว็างค่าสรรจัดให้เอเจนต์, แล้วจัดมาหลังหลังปวีิ๊สรูปประจรุรตานู้่ยการล่ม
เราไม่ควรใช้ "เอเจนต์" อย่างนี้
เรากลับมาหาหนทุกวินทการเป็นของท่างหรือการว่ายจัน เพื่อแทนทำงานผ่านวิธีการ "สมารถทำงานสั้วได้ตี้มากกว่าปะตางเง้าน จราง่เลย "เจาที่ทางงาน" ร้วปรวช้วยีป่น;
คุณกำลังสร้างเลเยอร์คำสั่งเพื่อควบคุมกองทหารของเอเจนต์อัตโนมัติ คุณโหลด Beads ไปแล้ว แต่ไม่รู้เลยว่ามันเป็นอะไรตรงจุดหนึ่งกลายเป็นซอฟต์แวร์ที่ไม่สามารถถอดออกได้ แค่เพราะเหตุด้านอินเทอร์เน็ตว่า "ทุกคนทำแบบนี้" ถ้าไม่ทำแบบนั้นคุณก็จะ "ถึงแก่การผูกรบกลางสาเหตุ" (ngmi)
คุณกำลังกินตัวเองอยู่ในรูปแบบ "วงรีเกอร์ชัน" อย่างไม่มีที่สิ้นสุด
ดูนี้ Anthropic ใช้กองทหารเอเจนต์ทำเครื่องคอมไพเลอร์ C แม้แต่ตอนนี้ยังมีปัญหา แต่นึกถึงรุ่นถัดไปแน่ๆจะแก้ไขได้ถูกต้อง ใช่ไหม?
แล้วอีกดู Cursor ใช้กองทหารมากมายทำเบราว์เซอร์แบบนี้ แม้แต่ตอนนี้เราต้องทำการแทรกระแหน่เป็นประจำ แต่รุ่นถัดไปแน่ๆจะแก้ไขได้ถูกต้อง ใช่ไหม?
''โครงร่างแบ่งเป็นส่วนส่วน'' ''ระบบอัตโนมัติ'' ''โรงงานแสงมืด'' ''แก้ปัญหาซอฟต์แวร์ในระยะเวลาหกเดือน'' ''SaaS ตายแล้ว ยายฉันต้องให้ Claw สร้าง Shopify''......
เรื่องราวเหล่านี้ฟังดูน่าสนใจ
แน่นอนว่าวิธีนี้ สำหรับ side project ของคุณที่โด่งดังไม่มีใครใช้ (รวมถึงคุณเอง) อาจจะยัง "ทำงานได้" จริง ๆ บางที จริง ๆ ผู้เหนือเพียงคนนึงสามารถทำออกมาพลิ่วให้เป็นซอฟต์แวร์ที่มีคุณภาพและจริงจังถูกใช้งาน ถ้าคุณคือคนนั้น ฉันก็จะหลงไหวจริง ๆ
แต่อย่างน้อยในวงกลมนักพัฒนาของฉัน ฉันยังไม่เคยเห็นข้อเท็จจริงที่วิธีนี้จริง ๆ มีประสิทธิภาพ แน่นอน อาจเป็นเพราะเราทุกคนไม่เก่งพอ
ความผิดพลาดที่สะสมขึ้นจากไม่มีการเรียนรู้ การblock และการแพร่ระบาดของความล่าช้า
ปัญหาของเอเจนต์อยู่ที่: พวกเขาจะเกิดข้อผิดพลาด สิ่งนี้เองไม่เป็นอะไร เพราะคนก็จะเกิดผิดพลาดได้ อาจจะเป็นแค่ข้อผิดพลาดเรื่องความถูกต้อง ที่ง่ายจะระบุและง่ายจะแก้ไข เพียงแค่ทดสอบย้อนกลับเพิ่มอีกทีก็มั่นใจมากขึ้น หรือบางทีอาจจะเป็นเรื่องของรสนิยมของโค้ดที่ linter จับไม่ได้: ไวยากรณ์ไม่ได้ใช้ที่นี่ ชนิดที่ไม่เหมาะสมที่นั่น และโค้ดซ้ำ ๆ กัน ประเภทโค้ดพวกนี้ดูอย่างเดียวกันๆ กับคนทำโค้ด
แต่ ''เครื่อง'' ไม่ใช่คน เมื่อคนกล่าวผิดครั้งหนึ่งก็จะทำให้เราเรียนรู้ไม่ผิดต่อไป — จะเป็นการตกใจให้รู้บางเทраШ หรือเป็นการเปลี่ยนแปลงจริงจังในกระบวนการเรียนรู้
เอเจนต์ ไม่มีความสามารถในการเรียนรู้เช่นนั้น อย่างน้อยตามค่าเริ่มต้น พวกเขาจะทำซ้ำความผิดด้วยกันอย่างต่อเนื่อง และหากว่ารับข้อมูลการอบรมมา พวกเขาอาจไม่สามารถสร้างความผิดพลาดที่แปลก ๆ ออกจากชุดข้อผิดพลาดอันเดิม
คุณแน่ใจสามารถ''อบรม''พวกเขาได้: เขียนกฎใน AGENTS.md ให้พวกเขาหลีกเลี่ยงการทำผิด ออกแบบระบบความจำที่ซับซ้อน หากให้พวกเขาสืบค้นข้อผิดพลาดประวัติและปกติที่ดีที่สุด นั่นอาจจรจ่างทำงายบางประเภทของปัญหา แต่เงื่อนไขพื้นฐานคือ — คุณต้องมองเห็นว่าพวกเขาทำผิดไว้ก่อน
ความแตกต่างที่สำคัญก็คือ: มนุษย์เป็นจุดอ่อน ในขณะที่เอเจนต์ไม่ได้เป็นจุดอ่อน
มนุษย์ไม่สามารถเขียนโค้ด 2 หมื่นบรรทัดในไม่กี่ชั่วโมงได้เลย แม้ว่ามีความผิดพลาดบ่อย ๆ แต่ก็จะสร้างข้อผิดพลาดอย่างจำกัดในหนึ่งวัน การสะสมข้อผิดพลาดนี้จะเป็นอย่างช้า ๆ ตัวอย่างส่วนใหญ่เมื่อ「ความเจ็บปวดที่เกิดจากข้อผิดพลาด」สะสมขึ้นถึงขั้นที่มนุษย์จะหยุดมาแก้ไข หรือจะถูกเปลี่ยนออกและมีคนอื่นมาแก้ให้ด้วย โดยสรุปมันได้รับการจัดการ
แต่เมื่อคุณใช้เจ้าเอเจนต์แบบเรียงลำดับแบบเต็มรูปแบบออกมา ก็จะไม่มีจุดอ่อน ไม่มี「ความรู้สึกระทึกทุกข์」 ข้อผิดพลาดเล็ก ๆ น้อย ๆ เหล่านี้จะถูกสะสมขึ้นด้วยความเร็วที่ไม่สามารถรับได้ คุณได้ถูกดึงออกจากวงวนแล้ว ซึ่งคุณหรือไม่รู้ว่าปัญหาที่ดูเหมือนจะไม้อันตรายน้อยไปนั้นได้เติบโตเป็นสิ่งเลอะเทอะ รออยู่จนกระทั่งคุณรู้สึกถึงความปวดป่วนแล้ว แล้วเป็นที่สุดเสียที่เรื่องนั้นอาจเกิดขึ้นช้าไปเป็นที่สุด
จนกระทั่งวันหนึ่ง คุณต้องการเพิ่มคุณลักษณะใหม่ ๆ แต่พบว่าโครงสร้างระบบปัจจุบัน (ที่จริงแล้วเป็นผลสะสมของข้อผิดพลาด) ไม่สามารถรองรับการเปลี่ยนแปลง หรือผู้ใช้เริ่มร้องเรียนอย่างบ้าคลั่ง เพราะการเผยแพร่ครั้งล่าสุดมีปัญหา หรือแม้กระทั่งข้อมูลหายไป
ในตอนนั้นคุณเพิ่งเข้าใจ: คุณไม่สามารถไว้ใจโค้ดชุดนี้ได้อีกต่อไป
แย่มากกว่าคือ ชุดทดสอบพันธุ์พื้นดินหลายพันตัวที่เอเจนต์สร้างขึ้นก็ไม่น่าไว้ใจแล้ว วิธีที่เหลือสำหรับการประเมินว่า「ระบบทำงานปกติหรือไม่」 เหลือแค่การทดสอบด้วยมือเท่านั้น
ขอแสดงความยินดี คุณตกอยู่ในหลุมทรัพย์ตัวของคุณแล้ว (และบริษัท)
พ่อขายความซับซ้อน
คุณจะไม่รู้ที่ระบบกำลังเกิดอะไรอยู่ ด้วยเหตุนี้คุณให้ควบคุมให้กับเอเจนต์ เอเจนต์สร้างความซับซ้อน พวกเขาได้เห็นมากมายของการตัดสินใจในโครงสร้างที่ไม่ดีในข้อมูลการฝึกฝน และต่อมายังทวีความแบบนั้นอีกด้วย คุณให้มันมาออกแบบระบบ ผลลัพธ์ที่คุณคาดว่ามันจะเป็นอย่างไร.
ผลสุดท้ายที่คุณได้รับคือ: ระบบที่ซับซ้อนมาก เต็มไปด้วยการขอมาจากภาคธุรกิจที่แย่ ปลอมอย่างงอแง และคุณกำลังไม่สามารถควบคุมก่อนที่ปัญหาจะหลุดพ้นจากควมคุมอย่างสมบูรณ์
แต่ปัญหายังไม่ได้จบที่ตรงนั้นคุณเอเจนต์กันแบบไม่มีการประชุม ไม่มีวิสัยระบบโค้ดทั้งหมด เข้าใจทั้งคุณหรือเอเจนต์ตัดสินใจไปกองอย่างไร ดังนั้นนั่นถือเป็นการตัดสินใจที่เป็น「ภาคส่วน」
นี่คือสาเหตุหลักของปัญหา: รหัสที่ซ้ำซากมากมาย โครงสร้างที่มีการนำสีไปนี่ไม่ทำได้ ความไมดแย๋ ทั้งหมดจะพุ่งหลุดออก มาสู่ระบบที่ซับซ้อนแล้วไม่สามารถแก้ไขได้อีกต่อไป
นั่นคือมันคล้ายกับการเขียนโค้ดขององค์กรขนาดใหญ่โดยมนุษย์จริงๆ แต่ความซับซ้อนของประเภทนี้มักเกิดจากการสะสมทรัพยากรเป็นเวลาหลายปี: ความเจ็บปวดถูกกระจายให้กับมวลมนุษย์ แต่ละคนยังไม่ได้มาถึงจุดว่าต้องแก้ไขแล้ว ความอดทนขององค์กรเองก็สูง ดังนั้นความซับซ้อนจึงรวมอยู่กับองค์กรอย่างสมบูรณ์
แต่ในกรณีของมนุษย์ + ตัวแทน กระบวนการนี้จะถูกเร่งอย่างมาก คู่ของมนุษย์, ร่วมกับกลุ่มตัวแทน, อาจใช้ไม่กี่สัปดาห์เพื่อถึงความซับซ้อนแบบนี้
อัตราการดึงข้อมูลของการค้นหาโดยตัวแทนต่ำมาก
คุณอาจคาดหวังว่าตัวแทนจะมาช่วยคุณ "เรียบเรียงศพ", ช่วยคุณทำการปรับโครงสร้างให้ดีขึ้น, ให้ระบบดูเรียบร้อยขึ้น แต่ปัญหาคือ: พวกเขาทำงานไม่ได้แล้ว
เพราะรหัสมีขนาดใหญ่เกินไป, ซับซ้อนเกินไป, และพวกเขาเข้าใจได้อยู่แค่บางส่วนของระบบเท่านั้น นี่ไม่ใช่แค่หน้าต่างของบริบทไม่ใพอ, หรือกลไกบริบทยาวที่หยุดทำงานต่อหน้าของรหัสล้านบรรทัด สถานการณ์มีปัญหาที่ซ่อนโดยซึมซับ
ก่อนที่ตัวแทนจะพยายามซ่อมแซมระบบ, มันต้องหารหัสทั้งหมดที่ต้องการแก้, รวมถึงการทำซ้ำของระบบที่มีอยู่ได้, ขั้นตอนนี้เราเรียกว่าการค้นหาโดยตัวแทน
วิธีที่ตัวแทนทำเรื่องนี้ขึ้นอยู่กับเครื่องมือที่คุณให้มัน: อาจเป็น Bash + ripgrep, อาจเป็นดาวเดียวที่สามารถค้นหา, บริการ LSP, ฐานข้อมูลเวกเตอร์...
แต่ไมว่าใช้เครื่องมืออะไรก็ตาม, รากฐานเสมอคือเหมือนกัน: รหัสมีขนาดใหญ่ขึ้น, อัตราการดึงข้อมูลยิ่งต่ำลง และอัตราการดึงข้อมูลต่ำหมายความว่า: ตัวแทนไม่สามารถค้นหารหัสทั้งหมดในขอบเขตระบบ, โดยธรรมชาติเขาก็จะไม่สามารถทำการแก้ไขที่ถูกต้องได้
นี่เป็นเหตุผลที่เริ่มต้นของข้อผิดพลาดเล็กๆ ที่มีลักษณะ "รสชาติของรหัส" ถูกเข้าใจผิด, เขาไม่เจอการใช้ที่มีอยู่แล้ว, ดังนั้นทำซ้ำล้อ, นำเข้าความไม่สอดคล้อง เรื่อยๆทำให้ปัญหาเติบโต, รวม, เป็นดอกไม้ที่ชำนาญมาก
แล้วเราควรทำอย่างไรเพื่อหลีกเลี่ยงทุกสิ่งนี้?
เราควรทำอย่างไรเพื่อร่วมมือกับตัวแทน (อย่างน้อยในปัจจุบัน)
การเขียนรหัสสำหรับตัวแทนเหมือนกับยักษีทะเล, ด้วยความเร็วในการสร้างรหัสอย่างรวดเร็วและความฉลาดที่ "เฉียบคมและเยือกเย็นบ้าง" นั้นจะดึงดูดคุณเข้าไป พวกเขามักสามารถทำงานอย่างรวดเร็วและคุณภาพสูงสำหรับงานบางอย่าง ปัญหาแท้จริงเริ่มปรากฏขึ้นเมื่อคุณมีความคิดเช่นนั้น—"ทางเราคืออย่างมาก, คอมพิวเตอร์, ช่วยฉันทำงานด้วย!"
การให้งานให้กับตัวแทนเองเป็นสิ่งที่ปกติ งานของตัวแทนที่ดีมักมีลักษณะหลายอย่าง: ขอบเขตสามารถถูกกำหนดได้อย่างดี, ไม่จำเป็นต้องเข้าใจระบบทั้งหมด; งานเป็นวงปิด, ก็คือ ตัวแทนสามารถประเมินผลลัพธ์เองได้; ผลลัพธ์ไม่ได้อยู่ในเส้นทางสำคัญของประเด็นหลัก, มันเป็นเพียงเครื่องมือชั่วคราวหรือซอฟต์แวร์ที่ใช้ภายในเท่านั้น, จะไม่กระทบผู้ใช้จริงหรือรายได้; หรือแม้แต่คุณจำเป็นต้องการ "เป็ดยาง" เพื่อช่วยในการคิด—ทางมารยาทธรรมบุกวัตถุตัวควายของคุณไปทุกที่กับข้อมูลรวมและสังเคราะห์ข้อมูลของอินเทอร์เน็ต
หากตรงตามเงื่อนไขเหล่านี้ งานนี้ก็จะเหมาะสำหรับการมอบหมายให้เอเจนต์ โดยเงื่อนไขคือ คุณเองเป็นผู้ควบคุมคุณภาพสุดท้ายอยู่
เช่น เรื่องเริ่มต้นแอปพลิเคชันใหม่ด้วยวิธี auto-research ที่ Andrej Karpathy นำเสนอ? เรื่องดีนะ แต่เงื่อนไขคือคุณต้องเข้าใจว่า โค้ดที่โดนสร้างออกมาโดยชัดเจนแล้วไม่สามารถนำมาใช้งานในสภาพการใช้งานจริงได้ หากพูดถึงความเป็นไปได้แล้วว่า auto-research มีประสิทธิภาพ นั้นเพราะคุณได้ให้มันฟังก์ชันประเมิน ที่ช่วยทำให้มันสามารถใช้แก่การพัฒนารอบครั้ง (เช่น เริ่มต้นที่สูญเสียข้อมูล) แต่ส่วนที่สำคัญคือ ฟังก์ชันประเมินนั้นเข้าใจเพียงเล็กน้อยในข้อดีชอบเชื่อ และเอเจนต์ก็จะข้ามข้าไปทุกอย่างที่ไม่ได้อยู่ในบริเวณของฟังก์ชันประเมิน ด้วยเช่นกัน เช่น คุณภาพของโค้ด ความซับซ้อนของระบบ และทำการแบบถูกต้อง แม้แม้ว่าถ้าเกิดฟังก์ชันเข้าใจเองก็ผิดพลาดเท่านั้น
เส้นทางหลักนี้ก็ง่ายที่จะเข้าใจ: โอนงานที่น่าเบื่อและไม่มีสิ่งใหม่ให้เรียนรู้หรืองานสำรวจที่คุณไม่เคยมีเวลาลองไปใช้งาน หลังจากนั้นคุณไปประเมินผล ระบุส่วนที่แท้จริงมีเหตุผล ถูกต้องจากนั้นจึงเสร็จสิ้นการพัฒนา แน่นอน ขั้นตอนสุดท้ายคุณก็สามารถไปใช้เอเจนต์ในการสูด็ตารางและ
แต่ส่วนที่ต้องการเน้นสำหรับฉันก็คือ: จริงๆแล้ว คุณควรช้าลงหน่อย
ให้เวลาตัวเองให้ความคิด คุณกำลังทำอะไร และ ทำไมทำ เพิ่มเวลาที่หันหูกับตัวเองว่า "ไม่ อย่าต้องการสิ่งนี้" กำหนดค่าต่อเสบียงอันชัดเจน ที่เอเจนต์ถูกอนุญาตให้สร้างโค้ดวันละเท่าไหร่ ปริมาณนี้ควรจะเท่ากับความสามารถในการตรวจสอบจริงของคุณ ส่วนหนึ่งของการตัดสินใจของระบบ "ความทั่วถึง" อย่างเช่น โครงสร้าง วิธีการเชื่อมต่ออินเทอร์เฟซต่างๆ เป็นส่วนตัวที่คุณควรเขียน เสริมเติมคุณสามารถใช้ระบบช่วยแสดงคำแนะนำการเขียนโค้ด หรือตั้งคู่กับเอเจนต์เขียนโค้ดร่วมกัน แต่สำคัญก็คือ: คุณต้องอยู่ในโค้ด
เพราะ การเขียนโค้ดด้วยตัวเอง หรือมองดูมันถูกสร้างขึ้นหรือไม่ กระบวนการเหล่านี้เองเป็น "การไหล" ที่สามารถเรียนรู้ว่าตนเองกำลังพยายามต้องทำอะไร ระบบกำลังทำงานอย่างไร สัตว์เฉพาะของการอ่อนวอ และ "รสชาติ" โดยเฉพาะคือสิ่งที่เหลือจากป12 การเรียนรูปาดเติน ในหนึ่งชั้นที่สูงที่สุดแต่กระทบจะไม่สามารถแทนที่ได้ ให้ช้าลง ยอมรับความแรงกระทบช่างคือวิธีคุณได้เรียนรู้และ成กใจ เมื่อสุดท้าย เราสมบูรณ์มีระบบที่สามารถบำรุงรักษาได้ เก็บของ คือ สินค้าของเรามีประโยชน์ อย่างไร ไม่ใช่สิ่งขยะ ที่ออกมาทั้งหมด
คุณได้สร้างฟัังก์ชันไปไปมาน้อยกว่า แต่เป็นความถูกต้อง สามารถพูด "ไม่" เรียนรู้และแกล้ร่งความสามารถ คุณสามารถนอนหลับอย่างสบายใจ ผ่านที่คุณยังรู้จักฟังก์ชันต่างๆ ที่จะวายไปดำเบี้ยจากการไปนัด จะช่วยอ่อนงื้นความบกพร่อง ให้เอเจนต์ผลลออกมาต่อการใช้งานที่เชื่อถือได้ การต้องใช้การแก้ไขมากกว่านั้น
เมื่อระบบมีปัญหา คุณสามารถลงมือแก้ไขเองได้ และเมื่อการออกแบบไม่เหมาะสมตั้งแต่แรก คุณสามารถเข้าใจปัญหาและทำให้มันกลายเป็นรูปแบบที่ดีขึ้น สำหรับสิ่งที่มี Agent หรือไม่มี มันก็ไม่สำคัญอย่างที่คิด
ทุกสิ่งนี้ ต้องใช้วินัย ทุกสิ่งนี้ ไม่สามารถหลีกเลี่ยงการใช้มนุษย์ได้
ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:
กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats
กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App
บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia
บทความที่เกี่ยวข้อง
