FDE: ตำแหน่งงานใหม่ที่ขับเคลื่อนการนำ AI ไปใช้ในองค์กร

👦🏻 ผู้เขียน: เฮนรี (ทีม DeerFlow)^[1]

ในเดือนที่ผ่านมา ผู้เขียนได้พบเพื่อนสี่คนที่กำลังวางแผนเปลี่ยนสายอาชีพ—นักพัฒนาฟรอนต์เอนด์ ผู้ออกแบบสถาปัตยกรรมโซลูชัน ผู้จัดการผลิตภัณฑ์ และวิศวกรอัลกอริทึมแบบดั้งเดิม ซึ่งมีพื้นหลัง อายุ และเมืองที่ต่างกัน แต่ต่างก็ถามถึงตัวย่อภาษาอังกฤษเดียวกัน: FDE^[2]คุ้มค่าที่ฉันจะไปไหม

FDE ย่อมาจาก Forward Deployed Engineer^[2]มันเคยเป็นศัพท์เฉพาะในวงการ Palantir เมื่อสองปีก่อน แต่วันนี้มันได้กลายเป็นประโยคเปิดตัวของผู้จัดหางาน ตำแหน่งที่พบบ่อยในประกาศรับสมัครงาน และหนึ่งในคำตอบที่ถูกเสนอว่าเป็นตำแหน่งที่มีมูลค่าสูงสุดในยุค AI บนโซเชียลมีเดีย OpenAI ได้จัดตั้งบริษัท Deployment Company ด้วยชื่อนี้โดยตรงในเดือนพฤษภาคม 2026^[3]ด้วยการลงทุนเริ่มต้น 4 พันล้านดอลลาร์สหรัฐ ได้ระบุชัดเจนว่าจะส่งวิศวกรไปทำงานในสถานที่จริงของลูกค้า และเข้าไปอยู่ในกระบวนการทำงานของลูกค้า; ทีม Applied AI ของ Anthropic ก็กำลังรับสมัคร FDE แบบพร้อมกันในสี่เขตเวลา ประเด็นนี้ใช้เวลาเพียงหนึ่งปีกว่าๆ ในการเปลี่ยนจากศัพท์แลบภายในวงการให้กลายเป็นคำที่เปิดเผย

บทความก่อนหน้าของผู้เขียน 《ถึงบุคคลอันยิ่งใหญ่》[4] พูดถึง “เครื่องยนต์ของมนุษย์” — ความอยากรู้อยากเห็น การเรียนรู้ด้วยตนเอง ความมุ่งมั่นภายใน และทักษะการลงมือทำ ว่าจะถูกกระตุ้นได้อย่างไรภายใน Closed-loop ที่สมบูรณ์ แต่มนุษย์ไม่ได้ลอยอยู่ในอากาศ มนุษย์ต้องได้รับการรองรับโดยระบบพิกัดตำแหน่งงานที่ชัดเจน หากบุคคลอันยิ่งใหญ่เป็น “วัตถุดิบ” ของความสัมพันธ์การผลิตในยุค AI แล้ว FDE ก็คือรูปแบบตำแหน่งงานที่เด่นชัดที่สุดที่ตลาดได้พัฒนาขึ้นในปีนี้

ในมุมมองของผู้เขียน FDE ไม่อยู่ในช่องที่ปรึกษา หรือช่องผู้รับจ้างภายนอก มันใกล้เคียงกับบุคคลเหนือชั้นมากที่สุด ความแตกต่างเพียงอย่างเดียวคือ FDE เป็นบุคคลเหนือชั้นที่ถูกจัดระเบียบอยู่ในช่องว่างระหว่าง “บริษัทโมเดล × ลูกค้า”

คุณรู้ไหม—คำว่า Forward Deployed มาจากไหน? มันเดิมทีเป็นศัพท์ทางทหารของสหรัฐฯ คือ Forward Deployed Forces ซึ่งหมายถึงกองกำลังที่ถูกส่งไปประจำการต่างประเทศหรือแนวหน้า เพื่อสามารถตอบสนองได้อย่างใกล้ชิด โดยเปรียบเทียบกับกองกำลังที่ยังคงอยู่ที่ฐานหลักในประเทศ Palantir นำคำนี้เข้าสู่อุตสาหกรรมซอฟต์แวร์ในช่วงปลายทศวรรษ 2000 เพื่ออธิบายรูปแบบการทำงานที่ “ส่งวิศวกรออกจากสำนักงานใหญ่ไปอยู่ที่ไซต์ลูกค้า” แม้แต่ทีมภายในก็ถูกตั้งชื่อตามรหัสเสียงทางทหารว่า Delta และ Echo ครั้งนี้ OpenAI และ Anthropic ได้รับคำนี้กลับมาอีกครั้ง ไม่ใช่เรื่องบังเอิญ—การส่งวิศวกรไปแนวหน้า แก่นแท้ของสิ่งนี้ยังคงไม่เปลี่ยนแปลง

บทความนี้จะตอบคำถามสามข้อที่ผู้เขียนถูกเพื่อนทั้งสี่คนถามเมื่อเร็วๆ นี้:

FDE คือบริษัทที่ปรึกษาที่สวมรอยปัญญาประดิษฐ์หรือไม่? ขอบเขตของมันเมื่อเทียบกับการให้คำปรึกษาแบบดั้งเดิมอยู่ที่ไหน?

FDE คือการรับจ้างพัฒนาซอฟต์แวร์ที่มีความซับซ้อนกว่าไหม? มันต่างจากงานที่ฉันทำในฐานะผู้รับจ้างอย่างไร?

ฉันเหมาะกับงาน FDE ไหม? ผู้ที่มีลักษณะใดจะได้รับการเสริมแรงจากตำแหน่งนี้ และผู้ที่มีลักษณะใดจะถูกบดขยี้?

ทัศนคติของผู้เขียนคือมองโลกในแง่ดีอย่างระมัดระวัง: FDE กำลังเติบโตขึ้นจริง แต่มันยังห่างไกลจากทางออกสำหรับทุกคน การอธิบายมันให้ชัดเจนสำคัญกว่าการทำให้มันดูน่าตื่นเต้น

หากต้องเลือกเพียงเหตุการณ์เดียวเพื่อระบุจุดเริ่มต้นของรอบการกลับมาอีกครั้งของ FDE ผู้เขียนจะเลือกวันที่ 11 พฤษภาคม 2026 — วันที่ OpenAI ประกาศก่อตั้ง Deployment Company^[5]COO Brad Lightcap ออกจากสายธุรกิจเดิมและย้ายไปรับผิดชอบโครงการพิเศษโดยรายงานต่อ Sam Altman โดยตรง และทำงานเต็มเวลาเพื่อดูแลเรื่องนี้ ในสัปดาห์เดียวกัน OpenAI ได้เข้าซื้อกิจการบริษัทที่ปรึกษา AI ของอังกฤษชื่อ Tomoro โดยรับพนักงาน 150 คนซึ่งเป็น Forward Deployed Engineer และ Deployment Specialist เข้ามาในบริษัทใหม่ทันที

值得一提的是，OpenAI 的招聘页面同时在挂出十几个 FDE 岗位：旧金山、纽约、华盛顿，外加按行业切的 Life Sciences、Semiconductor、Gov 等垂直方向，连 FDE 招聘官^[6]ตำแหน่งนี้กำลังรับสมัครอยู่ นักวิเคราะห์คาดการณ์ว่าทีมนี้จะขยายตัวเป็น 2,000–4,000 คนภายในสามปี นี่ไม่ใช่ขนาดของทีมวิจัย แต่เป็นกองทัพที่เป็นทางการ

ที่ Anthropic นั้นแทบจะเป็นการกระทำที่สะท้อนกันกลับ ตำแหน่ง Forward Deployed Engineer ภายใต้ทีม Applied AI^[7]พร้อมเปิดตัวพร้อมกันในหกเมือง ได้แก่ บอสตัน นิวยอร์ก เซแอตเทิล ซานฟรานซิสโก วอชิงตัน และลอนดอน โดยต้องการให้ลูกค้า 25%–50% เดินทางไปยังสถานที่จริง ตัวอย่างล่าสุดที่ถูกอ้างอิงบ่อยครั้งคือบริษัทฟินเทค FIS — ซึ่งในประกาศของบริษัทได้ระบุโดยตรงว่า “ทีม Applied AI และวิศวกรที่ถูกส่งไปล่วงหน้าของ Anthropic ได้ผนวกเข้ากับ FIS เพื่อร่วมกันออกแบบ Financial Crimes AI Agent และถ่ายทอดความรู้ให้กับ FIS เพื่อให้สามารถขยายตัว agent เพิ่มเติมได้ด้วยตนเองในอนาคต”

ข้อความนี้เปิดเผยภาพจริงของงาน FDE มันไม่ใช่สถาปนิกก่อนการขาย ไม่ใช่ SDR และไม่ใช่ผู้เผยแพร่ที่มาฝึกอบรมลูกค้า มันคือวิศวกรที่นำโมเดลมาอยู่ภายในรหัสของลูกค้า Brad Lightcap พูดตรงไปตรงมากว่านั้นว่า: “ลูกค้าของเราบอกเราว่าพวกเขาต้องการความสามารถในการย้ายจาก pilot ไปสู่ production Deployment Company คือการส่งวิศวกรของเราเข้าไปอยู่ในทีมของพวกเขา และจัดสรรทรัพยากรเพียงพอเพื่อให้สามารถส่งมอบได้”

วาดเรื่องนี้เป็นภาพ กราฟจะแสดงความสัมพันธ์ของสามฝ่ายได้อย่างชัดเจน:

โปรดสังเกตเส้นสองเส้นที่มีข้อมูลมากที่สุดในภาพนี้ คือข้อมูลย้อนกลับที่ FDE ส่งไปยังทั้งสองทิศทาง ไปทางลูกค้า FDE ไม่ได้ขายโมเดลเป็น SaaS แต่รวมข้อมูล สิทธิ์ การปฏิบัติตามกฎระเบียบ และระบบภายในของลูกค้าให้เป็นท่อเดียวที่สามารถรันโมเดลได้ ไปทางบริษัทโมเดล FDE นำปัญหาจริงและตัวอย่างความล้มเหลวของลูกค้ากลับไปยังผลิตภัณฑ์และการวิจัย เพื่อส่งผลต่อเส้นทางการพัฒนา—รูปแบบการเรียกเครื่องมือที่ผิดพลาดซ้ำๆ อาจกลายเป็นการจัดระเบียบแบบฝังตัวถัดไปของ SDK

นี่คือเหตุผลที่ FDE ถูกบริษัทโมเดลชั้นนำสองแห่งเปิดใช้งานอีกครั้งในรอบนี้ ซึ่งไม่ได้เรียบง่ายเพียงว่า “เราเองก็ต้องเรียนรู้จาก Palantir ในการให้คำปรึกษา” มันเป็นอุปกรณ์รับสัญญาณของบริษัทโมเดล—ปัญหาของลูกค้าที่หนาแน่นที่สุดบนแนวหน้า ต้องมีคนของตัวเองอยู่ตรงนั้นจึงจะจับได้ ความต้องการที่ผ่านการแปลจากพันธมิตรมักจะมีช่องว่างอยู่หนึ่งชั้น Anthropic เดินทางแบบผสมผสาน: ทั้งดำเนินการ FDE เองและร่วมสร้างเครือข่ายการติดตั้งกับบริษัทให้คำปรึกษาและผู้เล่นรายใหญ่ด้าน PE หนึ่งข้างเน้นการดำเนินการเอง อีกข้างเน้นระบบนิเวศ แต่แก่นหลักเหมือนกันทั้งคู่: บริษัทโมเดลไม่ได้เป็นเพียงผู้ให้บริการ API อีกต่อไป มันต้องส่งวิศวกรเข้าไปในผลิตภัณฑ์ของลูกค้าโดยตรง

คำถามถัดไปที่จะตอบคือ คำถามเปรียบเทียบที่พบบ่อยที่สุดสองข้อ — ขอบเขตของ FDE กับการให้คำปรึกษาแบบดั้งเดิม (เช่น แมคคินซีย์ เอเซนเนอร์) อยู่ที่ไหน? มันเหมือนหรือต่างจากบริการรับจ้างพัฒนาซอฟต์แวร์ที่เราคุ้นเคยหรือไม่?

หลายคนเมื่อได้ยินคำอธิบายงานของ FDE เป็นครั้งแรก มักตอบกลับว่า: “นี่ไม่ใช่แมคคินซีย์หรืออีแวนซ์เวอร์ชันใหม่หรือ?”

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

วางทั้งสองอย่างไว้ข้างกันในตารางเดียวกัน ความแตกต่างจะปรากฏทันที

ในตารางนี้ จุดที่ควรหยุดพิจารณาเป็นพิเศษคือแถว “การเสื่อมค่าของสินทรัพย์”

ตรรกะที่ทำกำไรสูงสุดในการให้คำปรึกษาแบบดั้งเดิมคือการใช้ทรัพย์สินซ้ำ—แผนที่จัดทำให้ธนาคารแห่งหนึ่ง สามารถปรับเล็กน้อยแล้วขายอีกครั้งให้ธนาคารถัดไป; คู่มือดิจิทัลสำหรับอุตสาหกรรมค้าปลีกสามารถนำไปใช้ซ้ำกับลูกค้าสามสิบรายได้ นี่คือแบบจำลองทางเศรษฐกิจพื้นฐานที่ทำให้ Accenture, Deloitte และ McKinsey Digital เติบโตมาตลอดสามทศวรรษที่ผ่านมา

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

คุณรู้ไหม—Product Overhang คืออะไร? ผู้เขียนในบทความก่อนหน้า ถึงบุคคลเหนือชั้น^[4]ได้อธิบายคำนี้ไปแล้ว: ความสามารถของโมเดลเกินกว่ารูปแบบผลิตภัณฑ์ปัจจุบัน แต่ยังขาดช่องทางการเข้าถึง สิทธิ์ และบริบทเพื่อแปลงมันให้เป็นจริง คุณค่าของตำแหน่ง FDE 本质上 คือการแปลง Overhang ที่ยังค้างอยู่ในสถานการณ์ของลูกค้าให้กลายเป็นผลิตภัณฑ์ที่สามารถดำเนินการได้จริง ลูกค้าไม่ได้ซื้อปริมาณการเรียกใช้ API ของโมเดล แต่ซื้อ “ความสามารถของบุคคลที่สามารถนำ Overhang ชุดนี้ไปใช้งานจริงในธุรกิจของฉัน”

สิ่งนี้ยังอธิบายความแตกต่างในแถว “โครงสร้างโครงการ” โครงสร้างมาตรฐานของโครงการที่ปรึกษาคือ SOW (Statement of Work) + WBS (Work Breakdown Structure) + การรับรองตามระยะ: ระบุชัดเจนในสัญญาถึงสิ่งที่ต้องจัดส่ง เวลาที่ต้องจัดส่ง และเกณฑ์การรับรอง โครงสร้างนี้มีเงื่อนไขเบื้องต้นว่าเป้าหมายต้องถูกกำหนดไว้ชัดเจนก่อนลงนามสัญญา

โครงการของ FDE ไม่ได้ใช้วิธีนี้ ลูกค้ามักพูดว่า: “ฉันรู้ว่า AI ควรจะช่วยฉันทำบางอย่างได้ แต่ฉันไม่รู้ว่าควรทำอะไร” เป้าหมายเองก็เป็นส่วนหนึ่งของโครงการ ดังนั้น FDE จึงไม่รับ SOW แต่รับ mission—ทิศทางที่ค่อนข้างคลุมเครือ—แล้วใช้การวนซ้ำแต่ละรอบเพื่อทำให้ทิศทางชัดเจนขึ้น ในที่สุดในรอบหนึ่ง โมเดลที่สะสมไว้จะถูกแปลงเป็นรูปแบบผลิตภัณฑ์

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

แถว “รั้วป้องกัน” เป็นสิ่งที่ละเอียดอ่อนที่สุด รั้วป้องกันของ FDE คือความรู้สึกแบบเรียลไทม์เกี่ยวกับขอบเขตของความสามารถของโมเดล—คุณได้ดำเนินการสถานการณ์ลูกค้าจริงกี่กรณีในเดือนนี้ คุณก็จะรู้ดีกว่าคนอื่นว่า Claude 4.7 ทำอะไรได้บ้าง และอะไรต้องรอ Claude 5 ความรู้สึกนี้ไม่สามารถเขียนลงใน PPT หรือใส่ลงในฐานความรู้ได้ มันเติบโตอยู่ในสมองของวิศวกรที่เคยลงมือทำในช่วง 90 วันที่ผ่านมาเท่านั้น

ดังนั้น ครั้งหน้าหากมีใครพูดว่า “FDE ไม่ก็แค่เวอร์ชันใหม่ของ Accenture” คุณสามารถตอบได้ว่า: วิศวกรของ Accenture ไปออกแบบกระบวนการของลูกค้าใหม่ ขณะที่ FDE ไปค้นหาขอบเขตของโมเดลอีกครั้ง ทรัพย์สินของฝ่ายแรกสามารถสะสมได้นานสิบปี แต่ทรัพย์สินของฝ่ายหลังต้องเติบโตใหม่ทุก 90 วัน

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

แต่เพียงแค่ดูที่วงจรป้อนกลับ ความแตกต่างก็ซ่อนไม่ได้

ความแตกต่างที่สำคัญที่สุดในภาพนี้ ไม่ใช่ส่วนบนของภาพที่เรียบง่ายเพียงใด แต่คือการมีสาย反馈ที่ยืดออกไปยังบริษัทโมเดลในส่วนล่างของภาพ สายเชื่อมนี้ไม่ใช่ของตกแต่ง มันคือเหตุผลที่แท้จริงที่ตำแหน่ง FDE มีอยู่ เมื่อแยกความแตกต่างนี้ออกเป็นส่วนๆ จะมีการเปรียบเทียบอย่างน้อยสี่ชุด

สิ่งที่รับมาต่างกัน การจ้างภายนอกรับ SOW—รายการความต้องการที่ถูกกำหนดไว้ล่วงหน้าก่อนลงนามสัญญา: ต้องทำฟีเจอร์อะไร ใช้เทคโนโลยีอะไร รับรองตามมาตรฐานใด และหากผิดสัญญาจะชดเชยอย่างไร ส่วน FDE รับ mission—ลูกค้าเองก็ยังไม่ชัดเจนว่าต้องการอะไร รู้แค่ว่า “AI ควรจะช่วยฉันทำบางอย่างได้” SOW มีพื้นฐานอยู่บนความแน่นอน ในขณะที่ mission มีพื้นฐานอยู่บนการสำรวจ ทั้งสองแบบมีท่าทีเริ่มต้นโครงการที่ต่างกันโดยสิ้นเชิง

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

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

ทิศทางของข้อเสนอแนะต่างกัน นี่คือกลุ่มที่ลึกที่สุดในสี่กลุ่ม ในโครงการจ้างภายนอก ข้อเสนอแนะจากลูกค้าจะหยุดเพียงแค่ที่บริษัทจ้างภายนอก และไม่ส่งผลกระทบต่อผลิตภัณฑ์ที่บริษัทจ้างภายนอกจะขายให้ผู้อื่นในอนาคต แต่ข้อเสนอแนะจาก FDE จะไหลย้อนกลับไปยังเส้นทางการพัฒนาของบริษัทโมเดล — ปัญหาทุกข้อ ความล้มเหลวของ Prompt ทุกครั้ง และบั๊กในการเรียกใช้งานเครื่องมือที่ลูกค้าพบในสถานการณ์จริง ล้วนกลายเป็นข้อมูลป้อนสำหรับชุดข้อมูลการฝึกอบรมรุ่นถัดไป การออกแบบเครื่องมือรุ่นถัดไป และฟีเจอร์ผลิตภัณฑ์รุ่นถัดไป กล่าวอีกนัยหนึ่ง ลูกค้าแต่ละรายที่ติดตั้ง FDE สำหรับบริษัทโมเดล ถือเป็นพันธมิตรด้านการออกแบบโดยธรรมชาติ

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

คุณรู้ไหม—ค่ารวม FDE ของ OpenAI และ Anthropic อยู่ที่เท่าไหร่? จากข้อมูลที่เปิดเผยของวิศวกรซอฟต์แวร์ของ Anthropic บน Levels.fyi^[8]ค่าเฉลี่ยของแพ็กเกจทั้งหมดสำหรับ SDE ระดับประสบการณ์สูง已达 710,000 ดอลลาร์สหรัฐฯ FDE เป็นตำแหน่งที่มีความเสี่ยงสูงกว่า—ต้องเผชิญกับความไม่แน่นอนของความสามารถของโมเดล ความไม่แน่นอนของธุรกิจลูกค้า และความไม่แน่นอนของรูปแบบผลิตภัณฑ์ ดังนั้น ข้อมูลอุตสาหกรรม^[9]ที่กล่าวถึง ค่าจ้างระดับสูงของห้องปฏิบัติการ AI ชั้นนำ FDE โดยทั่วไปอยู่ที่ 350K - 550K โดยระดับ Staff ขึ้นไปสามารถสูงถึง \$630K+ ค่าจ้างนี้ไม่ได้จ่ายให้กับ “ชั่วโมงงานรับจ้าง” แต่จ่ายให้กับผู้รับผิดชอบต่อความเสี่ยงรวมสามประการ ได้แก่ “ผลิตภัณฑ์ + ลูกค้า + โมเดล” > ย้อนกลับไปปี 2006 ผู้เขียนเพิ่งเริ่มงานที่บริษัทรัฐวิสาหกิจแห่งหนึ่ง ซึ่งขณะนั้นกำลังดำเนินการเปลี่ยนผ่านสู่ระบบสารสนเทศ ในยุคนั้น กลุ่มบริษัทของเราเชิญที่ปรึกษาจาก Accenture มาประจำที่สำนักงาน และต้องจ่ายค่าที่ปรึกษาให้ Accenture วันละ 3,500 หยวน เป็นเวลาหลายปี ถูกสื่อในยุคนั้นเรียกว่า “กลุ่มผู้บริหารระดับสูง” ต่อมาผู้เขียนย้ายไปทำงานที่บริษัท SAP ของเยอรมนี โดย SAP ได้กำหนดชื่อสำหรับอุตสาหกรรมที่ปรึกษา และที่ปรึกษา SAP กลายเป็นสัญลักษณ์ของ “กลุ่มผู้บริหารระดับสูง” ดังนั้น ดูเหมือนว่าค่าจ้างของ FDE จะยังคงเพิ่มขึ้นอย่างต่อเนื่องภายในระยะเวลา 24 - 36 เดือน และความต้องการก็ยังคงเพิ่มขึ้นอย่างมั่นคง

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

หลายคนเข้าใจผิดว่าคำว่า FDE เป็นคำที่ OpenAI คิดขึ้น แต่จริงๆ แล้วไม่ใช่ มันมีรากฐานสองสาย สายหนึ่งมาจาก Palantir อีกสายหนึ่งมาจากบริษัทโมเดลรุ่นใหม่หลังปี 2023 การวางรากฐานทั้งสองสายไว้ข้างๆ กัน จะช่วยให้เข้าใจได้ชัดเจนยิ่งขึ้นว่าตำแหน่ง FDE ทำหน้าที่อะไรจริงๆ

ดูเส้นเวลาแรก

รากแรกคือ Palantir.

Palantir ก่อตั้งขึ้นในปี 2003 โดย Peter Thiel, Alex Karp, Joe Lonsdale และคนอื่นๆ โดยลูกค้ารายแรกคือหน่วยงานข่าวกรองของสหรัฐฯ Karp ไม่มีพื้นฐานด้านวิทยาการคอมพิวเตอร์—he ศึกษาปริญญาเอกกับนักปรัชญา Jürgen Habermas ที่แฟรงก์เฟิร์ต และกลับมาสหรัฐฯ จึงถูก Thiel ชวนให้มาเป็นซีอีโอ ตำแหน่ง FDE นี้เกิดขึ้นจากความผสมผสาน “ซีอีโอที่ไม่ธรรมดา + ลูกค้าที่มีความลับสูง” ของ Karp — การทบทวนโดย 36Kr^[10]ที่นั่นเขียนอย่างตรงไปตรงมา ว่า Palantir ในช่วงแรกถูกหน่วยงานข่าวกรองวิจารณ์อย่างหนัก เพราะวิศวกรไม่สามารถเข้าถึงสถานการณ์ทางธุรกิจจริงได้ ความต้องการถูกถ่ายทอดผ่านหลายชั้นจนเบี่ยงเบนไปจากเดิม ต่อมา Palantir สามารถเจรจาให้วิศวกรของตนเองเข้าไปทำงานร่วมกับนักวิเคราะห์ข่าวกรองในสถานที่ของลูกค้า รูปแบบนี้ต่อมาถูก Shyam Sankar ระบบ化 และกลายเป็นรูปแบบเริ่มต้นของ FDE

จนถึงปี 2009 FDE ได้ขยายตัวเข้าสู่ภาคธุรกิจ เมื่อ JPMorgan ใช้งานแพลตฟอร์ม Metropolis ของ Palantir นักวิเคราะห์ FDE จำนวน 120 คนถูกส่งไปติดตั้งเพื่อเฝ้าระวังภัยคุกคามภายใน ตั้งแต่นั้นมา FDE จึงไม่ใช่แค่ “ส่งวิศวกรไปเยี่ยมลูกค้า” อีกต่อไป แต่กลายเป็นกลยุทธ์การฝังตัวกับลูกค้าอย่างเป็นระบบ: การนำ Foundry / Gotham ไปผสานเข้ากับกระบวนการดำเนินงานของลูกค้าอย่างแท้จริง ไม่ใช่แค่ส่งใบอนุญาตแล้วจากไป

การรับสมัคร FDE ของ Palantir มีเกณฑ์ที่ขัดกับสัญชาตญาณ—ไม่ต้องการใบปริญญาด้านวิทยาการคอมพิวเตอร์ สามารถนำเรื่องนี้ไปใส่ใน “คุณรู้ไหม”

คุณรู้ไหม—Palantir FDE ไม่ต้องการใบปริญญาด้านวิทยาการคอมพิวเตอร์? ตามเกณฑ์การรับสมัครของ Palantir ที่ SkillScouter รวบรวม^[11]และหน้า careers อย่างเป็นทางการของ Palantir^[12]Palantir 诚挚欢迎非计算机科学背景的候选人，近期被录用的 FDE 来自机械工程、经济学、哲学等专业。真正关键的两点是：能在信息不完整的情况下采取行动，以及能直接与 C 级客户沟通。计算机科学学位是加分项，而非入场券。Karp 本人正是这一标准的最早典范——一位哲学背景的 CEO，带领着一群来自物理、数学和哲学领域的 FDE。

บริษัทโมเดลรุ่นใหม่หลังปี 2023

หลังจากที่ ChatGPT เปิดตัวปลายปี 2022 OpenAI รีบตระหนักถึงสิ่งหนึ่ง: การติดตั้ง API ของโมเดลไว้บนเอกสารและให้ลูกค้าเชื่อมต่อเองนั้นไม่สามารถทำได้จริง ลูกค้าไม่ได้ไม่อยากใช้ แต่ไม่รู้ว่าจะใช้อย่างไร—พวกเขามีปัญหาทางธุรกิจ แต่ไม่มีรูปแบบผลิตภัณฑ์ ดังนั้นบริษัทเหล่านี้ เช่น OpenAI, Anthropic, Cohere, Scale, Glean, Sierra, Hebbia, Decagon จึงเริ่มรับพนักงาน FDE จำนวนมาก

ช่วงนี้ FDE เรียนรู้จาก playbook ของ Palantir — ส่งวิศวกรไปที่ไซต์ลูกค้าเพื่อดำเนินการกระบวนการทั้งหมดตั้งแต่ต้นจนจบ แต่ตัวผลิตภัณฑ์ได้เปลี่ยนไปอย่างสิ้นเชิง: ในยุค Palantir FDE ทำหน้าที่รวมข้อมูลและปรับแต่ง UI ขณะที่ FDE รุ่นใหม่ทำหน้าที่ออกแบบ Prompt การจัดการ Agent การเรียกใช้เครื่องมือ และการฝังกระบวนการ

บทความเฉพาะเรื่อง FDE ของ Pragmatic Engineer^[13]ในที่นี้เรียกเวอร์ชันใหม่นี้ว่า “ฝังตัวกับองค์กรเพื่อให้ Claude แก้ปัญหาที่แท้จริง เฉพาะเจาะจง และมีมูลค่าสูง” — การระบุนี้คล้ายกับที่ Palantir เคยใช้ในอดีตอย่างมาก เพียงแต่เปลี่ยนคำว่า “ข้อมูล” เป็น “โมเดล”

เมื่อดูรากทั้งสอง这条ร่วมกัน คุณจะเห็นจุดร่วมและจุดแตกต่างที่ชัดเจนชุดหนึ่ง

จุดร่วม: ลูกค้าไม่ได้ซื้อซอฟต์แวร์ ลูกค้าซื้อ “วิศวกรที่สามารถแก้ปัญหาของฉันได้ พร้อมชุดเครื่องมือ” สิ่งนี้เป็นเรื่องผิดปกติในประวัติศาสตร์ซอฟต์แวร์องค์กรตลอดสามทศวรรษที่ผ่านมา SAP, Oracle, Salesforce ขายซอฟต์แวร์เอง—วิศวกรเป็นทรัพยากรสนับสนุนที่มีอยู่เพื่อ “ทำให้ลูกค้าสามารถใช้ซอฟต์แวร์นี้ได้” Palantir กลับกัน: เครื่องมือมีอยู่เพื่อเป็นแรงผลักดันให้ FDE สามารถแก้ปัญหาให้ลูกค้าได้ บริษัทรุ่นใหม่เหล่านี้สืบทอดความสัมพันธ์ที่กลับด้านนี้—OpenAI ไม่ได้ขายใบอนุญาต GPT-4 แต่ขาย “FDE ของเราที่สามารถใช้ GPT-4 ช่วยให้คุณดำเนินการอัตโนมัติบริการลูกค้าได้”

ความแตกต่าง: ยุค Palantir เน้นการผสานรวมด้าน OPS — จุดเด่นอยู่ที่การผสานรวมข้อมูล การสร้างแบบจำลองออนโทโลยี และการจัดการสิทธิ์ รุ่นใหม่เน้นการประยุกต์ใช้ความสามารถของโมเดล — จุดเด่นอยู่ที่การออกแบบ Prompt การจัดเรียง Agent และการเพิ่มประสิทธิภาพการรักษาผู้ใช้ ยุคแรกเหมือนเวอร์ชันที่พัฒนาขึ้นของผู้ให้บริการผสานรวมระบบ ส่วนยุคหลังเหมือนการขยายบทบาทของวิศวกรผลิตภัณฑ์

ข้อเท็จจริงที่น่าสนใจอีกข้อหนึ่งคือ: ผู้ที่เคยเป็น FDE รุ่นแรกของ Palantir จำนวนมากต่อมาได้กลายเป็นผู้ประกอบการ หรือเข้าร่วมบริษัทโมเดลรุ่นใหม่โดยตรง ทีมงานรุ่นแรกของ Anthropic, OpenAI, Sierra และ Hebbia ล้วนมีชื่อของอดีตพนักงาน Palantir อยู่เป็นจำนวนมาก นี่ไม่ใช่เรื่องบังเอิญ—ตำแหน่ง FDE นั้นบังคับให้บุคคลหนึ่งต้องรับผิดชอบต่อความเสี่ยงด้านผลิตภัณฑ์ ความเสี่ยงด้านลูกค้า และความเสี่ยงด้านวิศวกรรม แทบจะเหมือนเป็นหลักสูตรฝึกอบรมผู้ประกอบการ ผู้เขียนขอมอง Palantir เป็นโรงเรียนฝึกอบรมผู้ประกอบการที่ซ่อนตัวอยู่: มันไม่ได้ผลิตเพียงวิศวกรเท่านั้น แต่ยังผลิตบุคคลที่รู้วิธีขับเคลื่อนสิ่งใดสิ่งหนึ่งจากศูนย์เป็นหนึ่งแม้อยู่ในสภาวะข้อมูลไม่สมบูรณ์ รากทั้งสองเส้นสุดท้ายก็มาบรรจบกันหลังปี 2023

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

สองต้นกำเนิดในท้องถิ่น

คนแรกเคยเป็นสถาปนิกโซลูชันของผู้ให้บริการคลาวด์ แอร์ลีคลาวด์ ทencent Cloud และ Huawei Cloud ได้พัฒนาทีมสถาปนิกโซลูชัน (SA) ที่สมบูรณ์ในช่วงสิบปีที่ผ่านมา โดยนำเสนอโครงสร้างให้กับลูกค้า เขียน POC จัดทำแผนการย้ายระบบ และร่วมมือในการส่งมอบจนถึงการเปิดใช้งาน ในภายใน Huawei ยังมีลำดับตำแหน่ง “วิศวกรส่งมอบ” ที่รับผิดชอบในการดำเนินโครงการให้ลงตัวในศูนย์ข้อมูลของลูกค้า ระบบนี้ได้ดำเนินงานประมาณ 80% ของงาน FDE แต่ยังคงเน้นที่ระยะก่อนขายและการติดตั้ง — ความรับผิดชอบในการพัฒนาผลิตภัณฑ์แบบครบวงจรไม่อยู่ในมือของ SA หากมีการเปลี่ยนความต้องการต้องผ่านกระบวนการเปลี่ยนแปลง หากเปลี่ยนโมเดลต้องรอตารางเวลาจากสำนักงานใหญ่

ต้นกำเนิดที่สองคือลำดับใหม่ที่เกิดขึ้นในบริษัทสตาร์ทอัพด้าน AI MiniMax ลงประกาศตำแหน่ง “ผู้เชี่ยวชาญด้านโซลูชันก่อนการขายด้าน AI” บน BOSS Zhipin บริษัทโมเดลต่างๆ เช่น Moonshot, Zhipu, Tongyi และ Hunyuan ก็ลงประกาศตำแหน่งคล้ายกัน ชื่อตำแหน่งอาจแตกต่างกันเล็กน้อย แต่เนื้อหา JD มีความคล้ายคลึงกันอย่างมาก: เข้าใจบริบทของลูกค้า ทำ demo ปรับ Prompt รัน RAG เขียนแผนการจัดส่ง และประสานงานกับทีมวิศวกรรมของลูกค้าจนถึงการเปิดใช้งาน ตำแหน่งเหล่านี้คือ FDE ของจีนในความหมายที่แท้จริง

สามความแตกต่างของดินและน้ำ

การปรับใช้งานแบบเฉพาะตัวและการปฏิบัติตามกฎระเบียบข้อมูลกดดันรูปแบบการเรียกใช้โมเดลเพียงอย่างเดียว ลูกค้าภาค B ในประเทศจีนมีความต้องการสูงกว่าตลาดสหรัฐฯ อย่างมากในเรื่องข้อมูลไม่ออกนอกเขต น้ำหนักโมเดลสามารถควบคุมได้ และสามารถตรวจสอบการตรวจสอบได้ ในโครงการ FDE หนึ่งโครงการ ปริมาณงานในการเรียก API และรัน Prompt อาจมีเพียงสามสิบเปอร์เซ็นต์ ส่วนอีกเจ็ดสิบเปอร์เซ็นต์คือการย้ายโมเดลไปยังศูนย์ข้อมูลของลูกค้า การเชื่อมต่อการรับรองตัวตน การเชื่อมต่อกับแพลตฟอร์มข้อมูล และการจัดทำเอกสารการปฏิบัติตามกฎระเบียบ

ความสามารถของโมเดลยังคงตามทัน SOTA และพื้นที่ในการแสดงศักยภาพถูกบีบให้เหลือเพียงระดับวิศวกรรม บริษัทในสหรัฐอเมริกาอย่าง OpenAI และ Anthropic สามารถดึงดูดลูกค้าด้วยความสามารถของโมเดลเอง ในขณะที่บริษัทในจีนอย่าง Tongyi, DouBao, Kimi, GLM และ DeepSeek มีความแตกต่างของความสามารถไม่ชัดเจนนัก ดังนั้นการตัดสินใจของลูกค้าจึงมุ่งเน้นไปที่ความสามารถทางวิศวกรรม เช่น การจัดเรียง Agent คุณภาพของการค้นหา RAG การรวมเครื่องมือ และการออกแบบ Workflow สำหรับ FDE ในจีน สิ่งที่แข่งขันกันไม่ใช่ “โมเดลของฉันเก่งแค่ไหน” แต่คือ “ฉันสามารถทำให้ธุรกิจนี้ทำงานได้จริงหรือไม่”

ความตั้งใจในการจ่ายเงินและการกำหนดราคาของฝั่ง B ไม่สอดคล้องกับสหรัฐอเมริกา รูปแบบของ Palantir ที่ “ส่ง FDE เข้าไปก่อน แล้วค่อยเรียกเก็บค่าสมัครรายเดือนในราคาสูง” ยากที่จะลอกเลียนแบบโดยตรง งบประมาณของลูกค้าในประเทศตามวงจรการจัดซื้อประจำปี มักเน้นไปที่รูปแบบโครงการ โมเดลธุรกิจของ FDE มักเป็นรูปแบบผสมผสานระหว่างการสมัครสมาชิก การอนุญาตให้ใช้งานแบบเฉพาะตัว และการจัดส่งโครงการ

ตำแหน่งที่เฉพาะเจาะจง: FDE ภายใน

ทีม AI ภายในบริษัทขนาดใหญ่หลายแห่งเริ่มใช้รูปแบบ FDE เพื่อให้บริการแก่ “ลูกค้าภายใน” 阿里云 PAI ส่งวิศวกรไปประจำที่ Taobao ขณะที่ Tencent HunYuan ก็มีกลไกคล้ายกันในการเชื่อมต่อกับ WeChat และทีมโฆษณา บน JD ระบุตำแหน่งว่า “วิศวกรการประยุกต์ใช้งานในอุตสาหกรรม” “วิศวกรการประยุกต์ใช้ AI” และ “ผู้เชี่ยวชาญด้านธุรกิจอัจฉริยะ” ซึ่งโดย本质 คือ FDE ภายใน—การนำความสามารถของทีมโมเดลไปใช้งานแบบครบวงจรบนฝั่งธุรกิจ สิ่งนี้เปิดมุมมองใหม่ให้กับผู้นำบริษัทขนาดใหญ่: แค่มี FDE ภายในไม่กี่คนไปประจำอยู่บนฝั่งธุรกิจ สร้าง demo แรกให้สำเร็จ และส่งข้อมูล ROI ให้กับผู้บริหารฝั่งธุรกิจ กำแพงระหว่างแผนกจะหายไปเร็วกว่าการจัดประชุมประสานงานสิบครั้ง

ผู้เขียนในบทความก่อนหน้า 《ถึงบุคคลอันยิ่งใหญ่》^[4]เคยกล่าวไว้ว่ามีเครื่องยนต์ห้าตัวของบุคคลพิเศษ: มีความอยากรู้อยากเห็นสูง มีจิตวิญญาณในการสำรวจและสร้างสรรค์สูง มีความสามารถในการเรียนรู้ด้วยตนเองสูง มีแรงจูงใจในตัวเองสูง และมีทักษะในการลงมือทำสูง ห้าสิ่งนี้เป็นตั๋วเข้าสู่ตำแหน่ง FDE แต่ไม่ใช่ทั้งหมด ตำแหน่ง FDE ยังมีคุณลักษณะเพิ่มเติมที่เฉพาะเจาะจงอีกชุดหนึ่ง และมีบุคลิกภาพบางประเภทที่ไม่เหมาะกับตำแหน่งนี้อย่างชัดเจน ผู้เขียนเคยเห็นวิศวกรที่เก่งหลายคนเปลี่ยนมาเป็น FDE แล้วปรับตัวไม่ได้ ปัญหาส่วนใหญ่ไม่ได้อยู่ที่ความสามารถ แต่อยู่ที่บุคลิกภาพและรสนิยมในการทำงาน

คุณลักษณะห้าประการที่เหมาะกับ FDE

ไม่กลัวการขายและการสื่อสาร งานประจำวันของ FDE ไม่ใช่การปิดประตูเขียนโค้ด แต่เป็นการติดต่อโดยตรงกับ CTO ผู้บริหารธุรกิจ ผู้ซื้อ ผู้เชี่ยวชาญด้านการปฏิบัติตามกฎระเบียบ และ IT ของลูกค้า จังหวะทั่วไป: CTO ของลูกค้าขัดจังหวะระหว่างการสาธิต ปฏิกิริยาของ FDE ไม่ควรเป็น “ฉันจะกลับไปแก้เวอร์ชันใหม่แล้วมาใหม่สัปดาห์หน้า” แต่ควรเปิด IDE ทันทีเพื่อแก้ Prompt และรันใหม่ให้ดูทันที “ลูกค้าอยู่ตรงนี้ ฉันกำลังแก้ไข” เป็นเรื่องปกติของ FDE

สนุกกับพื้นที่ที่ไม่ชัดเจน FDE ไม่ได้รับ PRD ที่ชัดเจน แต่ได้รับเพียงประโยคเดียวว่า “เราอยากใช้ AI ทำบางอย่าง” ลูกค้าเองก็ยังไม่สามารถอธิบายได้ว่าต้องการอะไร จึงต้องการให้ FDE ช่วยร่วมกันพัฒนาความคาดหวังที่คลุมเครือให้กลายเป็นรูปธรรม หากคุณรอจนกว่าจะมีความต้องการที่ชัดเจนถึงจะเริ่มทำงาน ทุกวัน FDE จะทำให้คุณรู้สึกกังวล

มีพื้นฐานด้านวิศวกรรมที่มั่นคง แต่ไม่จำเป็นต้องเป็น 10x FDE ไม่ได้ต้องการให้คุณเป็นคนที่เขียนโค้ดสะอาดที่สุดหรือมีความลึกของอัลกอริทึมสูงสุดในบริษัท แต่ต้องการให้คุณสามารถทำงานแบบครบวงจรได้: ฝั่งฟรอนต์เอนด์สามารถสร้างหน้าเว็บที่คลิกได้ ฝั่งแบ็กเอนด์สามารถตั้งค่าบริการที่ทำงานได้ และโมเดลสามารถเชื่อมต่อกับแหล่งข้อมูลธุรกิจ ในโลกของ FDE “พอใช้ก็เพียงพอ” ไม่ใช่ข้อเสีย แต่เป็นคุณสมบัติที่ดี

ชอบให้ข้อเสนอแนะช่วยปรับปรุง ในงานของ FDE มีช่วงเวลาจำนวนมากที่ต้องถูกลูกค้าตำหนิและให้กลับไปทำใหม่: demo วันนี้ พรุ่งนี้ฝ่ายธุรกิจบอกว่า “นี่ไม่ใช่สิ่งที่ฉันต้องการ”; แผนที่เคยประสานงานกันเมื่อสัปดาห์ที่แล้ว สัปดาห์นี้ลูกค้าเปลี่ยนผู้บริหารและต้องทำใหม่ทั้งหมด คนที่เหมาะกับงาน FDE จะมองข้อเสนอแนะเหล่านี้เป็นเชื้อเพลิง รับผิดชอบแบบครบวงจร และไม่ผลักความผิดให้กับ “ฝ่ายขอความต้องการพูดไม่ชัด”

ไวต่อขอบเขตของโมเดล นี่คือข้อที่มีความเทคนิคสูงที่สุดและซ่อนเร้นที่สุด FDE ต้องสามารถตัดสินได้ว่าภารกิจใดเหมาะกับ LLM และภารกิจใดไม่เหมาะ รวมถึงควร fallback อย่างไร — ความไวต่อเรื่องนี้ไม่สามารถเห็นได้จากบทความวิจัย แต่ต้องถูกสร้างขึ้นจากกรณีล้มเหลว เมื่อสะสมตัวอย่างล้มเหลวไปเรื่อยๆ FDE จะพัฒนาความจำเชิงกล้ามเนื้อเกี่ยวกับขอบเขตของโมเดล: สถานการณ์ใดควรใช้ RAG สถานการณ์ใดควรใช้กฎ และสถานการณ์ใดต้องมีช่องทาง fallback สำหรับมนุษย์

ผู้ที่ไม่เหมาะกับ FDE จำนวนสี่ประเภท

ผู้ชื่นชอบเทคโนโลยีบริสุทธิ์ที่อยากซ่อนตัวอยู่ในโค้ด FDE ใช้เวลาประมาณ 50% ไปกับการประชุมลูกค้า การประสานงานภายใน การอภิปรายผลิตภัณฑ์ และการผลักดันสัญญา ถ้าความสุขของคุณมาจากการเขียนโค้ดโดยไม่มีใครรบกวนต่อเนื่องเป็นเวลาสี่ชั่วโมง FDE จะทำให้คุณเผชิญกับภาวะหมดไฟทางจิตใจในระยะยาว

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

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

ผู้ที่ต่อต้านบริบททางธุรกิจ FDE ต้องเข้าใจ P&L ของลูกค้า ROI กระบวนการจัดซื้อ และข้อกำหนดด้านการปฏิบัติตามกฎหมาย หากคุณรู้สึกไม่ชอบการพูดถึงเงิน การทำสัญญา หรือตรรกะทางธุรกิจอยู่แล้ว งานของ FDE จะทำให้คุณรู้สึกเหมือนกำลังขายความฝันด้านเทคโนโลยีของตัวเอง

รายการตรวจสอบตนเอง

คำถาม 7 ข้อ แต่ละข้อสอดคล้องกับสถานการณ์การทำงานจริงของ FDE ถ้าตอบ “ใช่” มากกว่า 5 ข้อ สามารถพิจารณา FDE อย่างจริงจัง ถ้าตอบ “ใช่” น้อยกว่า 3 ข้อ แนะนำให้พิจารณาอย่างรอบคอบ

1. คุณยินดีที่จะย้ายเวลา 50% ทุกวันจากโค้ดไปยังการประชุมลูกค้า การตอบข้อความ และการโทรไหม?

2. เมื่อลูกค้าบอกคุณว่า “อันนี้ใช้ไม่ได้ แต่ฉันก็อธิบายไม่ถูกว่าทำไม” ปฏิกิริยาแรกของคุณคือความอยากรู้อยากเห็น หรือความหงุดหงิด?

3. ไม่มีใครเขียน PRD ให้คุณ คุณสามารถทำงานร่วมกับ Claude Code เพื่อสร้างต้นแบบที่สามารถแสดงให้ลูกค้าดูได้ภายในหนึ่งสัปดาห์ไหม

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

5. เมื่อโมเดลให้คำตอบผิด ปฏิกิริยาแรกของคุณคือการออกแบบระบบสำรอง หรือบ่นว่าโมเดลไม่ดี?

6. คุณยินดีลงนามในสัญญา เขียนรายงาน ดำเนินการรับรองจากลูกค้า และปรึกษากับฝ่ายกฎหมายเกี่ยวกับข้อกำหนดด้านการปฏิบัติตามกฎหมายหรือไม่?

7. คุณสามารถยอมรับการสร้างต้นแบบอย่างรวดเร็วและการล้มเหลวอย่างรวดเร็วได้ไหม

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

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

FDE ไม่ใช่จุดสิ้นสุด ผู้เขียนเชื่อว่า FDE เป็นรูปแบบแรกที่ได้รับชื่อในโครงสร้างงานใหม่ ต่อไปจะมี Forward Deployed PM, Forward Deployed Designer, Forward Deployed Researcher — ตำแหน่งทั้งหมดที่เชื่อมโยงอย่างใกล้ชิดกับบริบทของลูกค้าและต้องสร้างผลิตภัณฑ์ขึ้นในพื้นที่ที่ไม่ชัดเจน จะมีเวอร์ชัน “การติดตั้งล่วงหน้า” ของตัวเอง ชื่อตำแหน่งอาจเปลี่ยนไป แต่ตรรกะพื้นฐานยังเหมือนเดิม: ความสามารถของโมเดลวิ่งนำหน้า รูปแบบผลิตภัณฑ์วิ่งตามทีหลัง และโครงสร้างตำแหน่งถูกแบ่งใหม่ตามกระบวนการทำงาน

ให้แต่ละกลุ่มผู้อ่านสามกลุ่มหนึ่งประโยค

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

สำหรับฝ่ายทรัพยากรบุคคลและพัฒนาองค์กร: ระวัง “ความไม่สอดคล้องระหว่างชื่อและหน้าที่” บริษัทของคุณอาจมี FDE อยู่แล้วหลายราย แต่รหัสตำแหน่งของพวกเขากลับระบุว่า “ผู้เชี่ยวชาญด้านโซลูชัน” “สถาปนิกอุตสาหกรรม” หรือ “วิศวกรแอปพลิเคชัน AI” ให้ระบุพวกเขา จัดหมวดหมู่ใหม่ และสร้างเส้นทางการเติบโตที่สอดคล้องกับงานจริงของพวกเขา ซึ่งมีประสิทธิภาพมากกว่าการรับพนักงานใหม่จากศูนย์

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

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