宝玉（Parody）

Hôm nay khi thử nghiệm Manus, mình đã học được một mẹo gợi ý từ (prompt): khi vẽ tranh, không cần dùng prompt để điều khiển phong cách và bố cục, mà chỉ cần đưa trực tiếp hình tham chiếu. Trong hình tham chiếu còn có sẵn các yếu tố như màu sắc, ví dụ về phông chữ, sợi vân giấy vẽ (giấy Tuyên), rìa mực loang, vết nước, núi xa, con dấu và cả các quy tắc chừa khoảng trống (negative space)...

Như vậy độ ổn định khi tạo ảnh sẽ cao hơn, và prompt gợi ý nội dung cũng có thể rất đơn giản.

Hình 1: Hình tham chiếu

Hình 2 content_prompt:

> Tiêu đề ‘Trà và cuộc sống chậm’, phụ đề ‘Dành chút thời gian, hãy rót cho mình một tách trà’. Thiết kế cần tuân theo phong cách trong hình tham chiếu: yên tĩnh, kín đáo, wabi-sabi (vẻ đẹp mộc mạc); sử dụng phong cách mực thủy mặc cực giản và khoảng trống mực. Nền là vân giấy Tuyên. Chữ phải căn giữa, rõ ràng.

Hình 3 content_prompt:

> Tiêu đề ‘Hạ chậm nhịp sống hằng ngày’. Nội dung: ‘Ấm trà: Trước hết cảm nhận độ ấm của vật dụng’, ‘Ngửi hương: Chú ý mùi hương của lá trà và hơi nước’, ‘Thưởng trà: Uống từng ngụm nhỏ, dừng lại một chút’. Thiết kế cần tuân theo phong cách của trang đầu và hình tham chiếu: yên tĩnh, kín đáo, phong cách mực thủy mặc cực giản; sử dụng một vài yếu tố mực thủy mặc (như núi xa, vết nước của đồ trà, v.v.) điểm xuyết ở vùng khoảng trống. Nền là vân giấy Tuyên. Bố cục chữ cần thể hiện cảm giác phân tầng và khoảng trống.

--- Prompt đầy đủ cho Hình 2 ---

Tạo một slide thuyết trình chuyên nghiệp với nội dung sau:

Tiêu đề ‘Trà và cuộc sống chậm’, phụ đề ‘Dành chút thời gian, hãy rót cho mình một tách trà’. Thiết kế cần tuân theo phong cách trong hình tham chiếu: yên tĩnh, kín đáo, wabi-sabi; sử dụng phong cách mực thủy mặc cực giản và khoảng trống mực; nền là vân giấy Tuyên. Chữ phải căn giữa, rõ ràng.

Hướng dẫn phân cấp & bố cục (Hierarchy & Layout Guidance):
- Bắt đầu bằng yếu tố kể chuyện quan trọng nhất (tiêu đề/chỉ số) và theo sau bằng phần mô tả hỗ trợ trong các mục rõ ràng
- Bất kỳ biểu đồ nào cũng cần phản ánh dữ liệu thực tế được cung cấp trong prompt nội dung và bám sát đúng các nguồn đã mô tả
- Sắp xếp hình ảnh và nội dung sao cho người xem có thể quét từ trái sang phải hoặc từ trên xuống dưới; tránh xếp chồng dọc các biểu đồ/hình ảnh

Định hướng hình ảnh (Visual Direction):
- Chuyên nghiệp và sạch sẽ
- Tuân theo phong cách của hình slide trước (nếu được cung cấp) để đảm bảo tính liên tục

Yêu cầu:
- Bố cục thuyết trình chuyên nghiệp với phân cấp thị giác rõ ràng
- Văn bản phải dễ đọc rõ ràng với độ tương phản phù hợp so với nền
- Bao gồm khu vực tiêu đề và khu vực nội dung khi cần
- Duy trì phong cách nhất quán phù hợp với thuyết trình chuyên nghiệp
- Thiết kế trực quan chất lượng cao, sẵn sàng in ấn
- Tất cả chữ phải sắc nét và dễ đọc
- Giữ toàn bộ nội dung chữ thiết yếu nằm thoải mái trong khung; tránh đặt chữ sát mép
- Cân bằng các yếu tố thị giác với khoảng trắng để slide trông gọn gàng, không bị rối mắt

Hãy để ChatGPT dùng cấm đoán trật tự trung lập hỗn loạn cửu cung đồ để phân loại các nhân vật nổi bật trong giới AI, và vẽ ra cái này cho tôi

Hãy để ChatGPT dùng cấm đoán trật tự trung lập hỗn loạn cửu cung đồ để phân loại các nhân vật nổi bật trong giới AI, và vẽ ra cái này cho tôi

Opus 5.5 giúp bạn tự do thiết kế App Icon

Khi trước với Fable, tôi đã từng thử nhờ Fable thiết kế App Icon cho mình, nhưng kết quả không mấy ấn tượng. Cuối cùng tôi vẫn phải dùng ChatGPT để vẽ, nhưng cách vẽ đó không tạo ra được dạng vector.

Trong vài ngày gần đây, khi dùng Opus 5.5 để làm video, tôi đã có thêm cảm hứng. Nếu Opus 5.5 có thể dùng JavaScript + Canvas để vẽ ra video từng khung hình, thì việc dùng nó với JS + Canvas để vẽ Icon cũng không có gì là không thể.

Thế là tôi thử một lần. Ngay từ bản đầu tiên, hiệu quả đã vượt ngoài mong đợi: đơn giản, đẹp mắt và chất lượng khá tốt. Chỉ với một câu lệnh (prompt):

> Hãy giúp tôi thiết kế lại App Icon cho http://BaoCut.app, đơn giản hơn một chút, màu sắc tươi, thể hiện việc chỉnh sửa video và AI Agent
> Có thể dùng js để vẽ trực tiếp lên canvas

Điểm cần chú ý là “dùng js để vẽ canvas” chứ không phải SVG. SVG không thể có được hiệu ứng draw Canvas tốt như khi dùng JS.

Sau đó cứ như làm việc với bên đối tác: liên tục yêu cầu chỉnh sửa.
Ví dụ, tôi thấy phương án 3 khá ổn, nên nhờ nó dựa trên phương án 3 để điều chỉnh. Sau vài vòng lặp và tinh chỉnh, cuối cùng tôi cũng có được một phương án mà tôi khá hài lòng.

Hãy đề xuất các tập hợp prompt video mã nguồn mở Awesome Opus 5.5 trên GitHub

Opus 5.5 vẫn khá bền, thế mà cũng không dùng hết trước khi phải reset

Opus 5.5 vẫn khá khó dùng, cứ vậy mà không dùng hết trước khi reset

Có người đã làm một bài thử nghiệm AI đối kháng của “StarCraft” (Brood War Bench), cho các mô hình ngôn ngữ lớn đang thống trị hiện nay “đấu với nhau” trong thời gian thực của thể loại chiến lược. Kết quả là trình độ của tất cả các mô hình đều không vượt nổi người mới.

“StarCraft: Brood War” là tựa game chiến lược thời gian thực kinh điển từ năm 1998, đồng thời cũng là người bạn lâu năm của nghiên cứu AI. Năm 2019, AlphaStar của DeepMind đã từng đánh bại các tuyển thủ chuyên nghiệp trong chính trò chơi này. Nhưng đó là AI được huấn luyện chuyên biệt bằng học tăng cường. Lần thử nghiệm này khác: thay vì vậy, nó cho các mô hình đa năng tiếp cận trực tiếp dưới dạng các “tác nhân AI” để thao tác, xem liệu chúng có tự xây căn cứ, sản xuất quân lính, rồi tiến hành chiến đấu được hay không.

Tác giả Ben Swerdlow ban đầu chỉ làm một phiên bản StarCraft “chỉ có thể điều khiển thông qua thao tác của tác nhân”, để mang đi chơi với bạn bè. Không ngờ vài người bạn gần như chưa từng chơi lại tỏ ra khá ổn — họ nói rằng chỉ cần đưa một câu lệnh kiểu “đi tấn công”, rồi tác nhân tự xây dựng một đội lính nhỏ xông thẳng sang. Điều này khiến anh tò mò: nếu để AI hoàn toàn tự chơi thì sẽ đạt đến trình độ nào?

Đáp án là: rất kém, nhưng lại rất thú vị.

Codex Astra xếp hạng số một thắng cả 18 trận. Tuy nhiên, điểm mạnh của nó không phải là giao chiến chính diện, mà là “quấy rối”: phái một người lính công nghiệp đi khai thác (Probe) chạy sang khu căn cứ của đối phương để phá rối. Chiêu này đặc biệt hiệu quả trước các đối thủ AI, vì khi thấy một công nhân đã tới, tác nhân bên kia sẽ mất hàng chục giây để suy nghĩ nên xử lý thế nào, trong khoảng thời gian đó chẳng làm gì cả. Còn ở mảng phát triển kinh tế đàng hoàng và giao tranh quy mô lớn, Codex lại khá yếu: nó thường chỉ tạo một hoặc hai đơn vị rồi ném sang phía đối thủ, thay vì tích đủ quân lực rồi mới xuất kích.

Claude Fable đứng thứ ba, tỉ lệ thắng 83,3%, là mô hình tham dự “giống đang thực sự chơi game” nhất. Nó sẽ ngoan ngoãn phát triển kinh tế, leo thang công nghệ, thậm chí trong một ván đã tạo ra được phi long (Mutalisk), còn ở ván khác lại nghiên cứu tới công nghệ hiệp sĩ thánh đường. Dù đôi lúc nó nghiên cứu cả một đống mà lực lượng lại không theo kịp, ít nhất Fable cũng nghiêm túc hơn bất kỳ ai trong việc “cố gắng hiểu luật chơi”.

Hiệu suất của Grok là tệ nhất. Grok 4.6 trong một trận 43 phút đã tạo ra hơn 11.000 token suy luận, nhưng chỉ phát ra 6 lệnh thao tác, suốt cả trận không tạo ra nổi một đơn vị chiến đấu nào. Về bản chất, nó đang coi chiến lược thời gian thực như trò chơi theo lượt: cứ nghĩ mãi, quên mất phải hành động.

Thử nghiệm này chỉ ra vấn đề cốt lõi: các mô hình ngôn ngữ lớn hiện tại vẫn chưa đủ để dùng trong môi trường thời gian thực đòi hỏi quan sát liên tục, ra quyết định nhanh và phối hợp đa luồng. Dù mô hình tốt nhất cũng vậy, chỉ cần một người mới biết chơi cũng có thể giành chiến thắng ở mọi trận nếu biết cách đánh bài “pháo photon tốc độ” (một chiến thuật fast-attack cơ bản nhất). Nhưng mặt khác, các mô hình này đã có thể hiểu những khái niệm cơ bản như xây dựng, khai thác, tấn công — chỉ là chúng kém xa về nhịp thực thi và điều phối nhiều nhiệm vụ.

Mã nguồn của bài thử nghiệm và nền tảng đối kháng đã được mở. Bất kỳ ai cũng có thể mang tác nhân của riêng mình lên để đấu một ván. Địa chỉ là http://bw.swerdlow.dev.

Anthropic lặng lẽ xây dựng một phòng thí nghiệm sinh học

Theo một báo cáo độc quyền của Reuters, Anthropic đã hoàn tất việc xây dựng một phòng thí nghiệm ướt (wet lab — phòng thí nghiệm vật lý có thể tiến hành các thí nghiệm sinh hóa thực tế) tại Vùng Vịnh San Francisco, chính thức mở rộng “cánh tay” của AI từ phần mềm sang nghiên cứu phát triển thuốc.

Người phụ trách Khoa học đời sống của Anthropic, Eric Kauderer-Abrams, đã xác nhận điều này trong một cuộc phỏng vấn. Ông nói rằng: trong nghiên cứu sinh học, tiêu chuẩn kiểm chứng cuối cùng vẫn là công việc trong phòng thí nghiệm thực sự, không thể chỉ dựa vào mô phỏng bằng máy tính. Một phần thí nghiệm sẽ tự làm, một phần sẽ hợp tác với các đối tác bên ngoài — đây cũng là cách làm giống với đa số công ty công nghệ sinh học.

Chuyện này không phải bốc đồng. Trong vài tháng qua, Anthropic có hàng loạt động thái: chi khoảng 400 triệu USD để mua cổ phần của một startup tên Coefficient Bio nhằm xây dựng các công cụ phục vụ nghiên cứu phát triển thuốc; đưa CEO của Novartis là Vas Narasimhan vào hội đồng quản trị; ra mắt phần mềm mang tên Claude Science; vào tháng 6, công khai tại San Francisco rằng sẽ khởi động các dự án nghiên cứu phát triển thuốc. Trên LinkedIn cũng đang tuyển dụng các vị trí về phụ trách vận hành mua sắm, chuyên gia về đặc trưng hóa protein và axit nucleic; trong bài đăng tuyển dụng, mục tiêu được ghi là “tăng tốc độ tiến bộ trong khoa học sự sống lên một bậc”. Kauderer-Abrams cho biết, khoa học đời sống đã và đang là một trong những hướng đầu tư lớn nhất của Anthropic về nhân lực và nguồn lực.

Anthropic đang nhắm tới những lĩnh vực mà các công ty dược truyền thống cho là “khó có thuốc” (undruggable) — tức các bệnh hiếm bị bỏ qua vì mục tiêu quá khó, hoặc lợi nhuận thương mại không cao. Họ tin rằng AI có thể đẩy nhanh việc phát hiện các kháng thể song đặc hiệu thậm chí tam đặc hiệu — những phân tử phức tạp có thể tấn công đồng thời nhiều mục tiêu. Việc thiết kế các loại thuốc này có độ khó cực cao, nhưng AI lại giỏi trong việc xử lý độ phức tạp đó. CEO Dario Amodei thì cảm nhận điều này rất “đau” tận xương — cha ông qua đời vì một căn bệnh, và phương pháp chữa khỏi chỉ xuất hiện vài năm sau.

Tuy nhiên, hiện tại Anthropic đang vẽ một ranh giới rõ ràng: chỉ làm nghiên cứu tiền lâm sàng, không tiến hành thử nghiệm lâm sàng, và không giành “miếng bánh” với các công ty dược. Đây cũng là để giảm bớt một vấn đề niềm tin mang tính thực tế: những đại công ty dược đang dùng Claude (Genentech, Bristol Myers Squibb và Novo Nordisk đều nằm trong danh sách) sẽ lo ngại rằng Anthropic có thể học được gì từ dữ liệu của họ.

Cần lưu ý các mốc thời gian: mọi chuyện diễn ra vào thời điểm Anthropic chuẩn bị IPO với định giá khoảng 2 nghìn tỷ USD, và cũng đúng lúc tranh cãi về an toàn AI đang nóng lên — chỉ trong hai tuần gần đây, các nhà nghiên cứu của chính Anthropic đã cảnh báo rằng AI có thể dẫn tới sự diệt vong của loài người, đồng thời công ty cũng phát hiện hệ thống của mình có rủi ro bị sử dụng cho việc phát triển vũ khí sinh học. Vừa đạp ga vừa kéo phanh tay — sự căng thẳng đó là bức tranh “thật nhất” về Anthropic lúc này.

Để so sánh, Isomorphic Labs thuộc Google đã làm AI trong phát hiện thuốc được vài năm nay; kế hoạch ban đầu là đến cuối năm 2026 mới bước vào giai đoạn lâm sàng, nhưng trước đó đã từng bị trì hoãn một lần. Thực tế của nghiên cứu phát triển thuốc là như vậy: từ lúc phát hiện một phân tử cho đến khi một loại thuốc được đưa ra thị trường thường phải mất nhiều năm, và phần lớn các thuốc sẽ thất bại trong các thử nghiệm lâm sàng. Tham vọng của Anthropic rất lớn, nhưng con đường còn rất dài.

Tôi hiện đang sử dụng mức độ hiệu quả của ChatGPT Pro ngày càng cao. Chủ yếu là vì tôi thường dùng nó để giúp mình lập kế hoạch/giải pháp kỹ thuật, hiệu quả đặc biệt tốt, và cũng không làm chiếm hạn mức Codex.

Mỗi lần sử dụng, tôi chỉ cần gửi thẳng cho nó địa chỉ GitHub, để nó dựa vào mã nguồn để phân tích, thiết kế và viết ra một tài liệu thiết kế, thậm chí có thể tạo luôn một PR. Sau đó, tôi tải tài liệu thiết kế về máy để Codex hoặc Claude Code thực thi.

Đôi khi tôi còn cho nó thi chạy cùng Fable: với cùng một vấn đề, để Fable và GPT 6 Pro mỗi bên tự thiết kế một giải pháp, rồi lấy cái hay để bổ sung cho nhau.

Lưu ý cần vào phần cài đặt để liên kết tài khoản GitHub của bạn, để nó có thể truy cập kho mã nguồn riêng tư của bạn và gửi/đẩy PR.

Không biết vì sao hạn mức Fable của tôi từ 97% lại chuyển xuống 67% rồi, là sắp hủy bỏ giới hạn 50% à? Hay bị lỗi (bug) rồi?

Mô hình nền tảng Doubao 2.1 Pro ra mắt, bản cập nhật 0915. API đã được triển khai đầy đủ trên Hỏa Sơn Chu. Lần nâng cấp này tập trung vào bốn hướng: giao bài toán qua Agent, viết code đa phương thức, hiểu đa phương thức và tối ưu chi phí suy luận.

Cải tiến ở mảng Agent

Trong các tình huống cần gọi công cụ nhiều vòng, tra cứu tài liệu trên Internet rồi mới đưa ra báo cáo, mô hình đã được tăng cường năng lực truy xuất bằng chứng và kiểm tra tính đúng đắn của dữ liệu, ảo giác giảm rõ rệt. Ví dụ chính thức đưa ra là mảng nghiên cứu đầu tư tài chính: mô hình có thể tự tách nhỏ nhu cầu nghiên cứu, tìm kiếm nguồn dữ liệu rồi mô hình hóa và phân tích lại; bản nháp tạo ra gần với trình độ của một nhà phân tích. Để xác minh một nhận định trong báo cáo tài chính của một công ty xe, mô hình đã điều phối hơn 500 Agent con, truy xuất hơn 1000 trang web và đối chiếu chéo nhiều nguồn như lộ trình hàng hải và ảnh vệ tinh. Năng lực kiểu “không chỉ tin một phía, mà xác minh chéo đa nguồn” này có giá trị trực tiếp khi doanh nghiệp làm thẩm định (due diligence) và lập báo cáo nghiên cứu.

Coding đa phương thức

Thay đổi hữu ích nhất lần này có lẽ là khả năng viết code từ hình ảnh. Giờ đây mô hình có thể trực tiếp đọc hiểu bản thiết kế, bản vẽ kỹ thuật thậm chí cả bản ghi thao tác màn hình, rồi chuyển thông tin thị giác thành mã front-end. Demo chính thức cho thấy một kịch bản: đưa cho mô hình một đoạn video ghi màn hình kèm vài bản phác thảo để nó phát triển trang giao diện di động cho một hệ thống ERP cũ không có tài liệu—mô hình đã “đọc hiểu” 280.000 dòng code Java và khôi phục trực tiếp được trang giao diện di động chạy được.

Trong việc hiểu kho mã nguồn, mô hình đã tự sửa lỗi và chạy test cho game mã nguồn mở Luanti (khoảng 387.000 dòng mã), 83% nhiệm vụ đạt chuẩn có thể gộp vào. Con số này đáng chú ý với các nhà phát triển thường xuyên phải khoanh vùng lỗi trong dự án quy mô lớn và sửa bug xuyên tệp.

Các nâng cấp khác

Ở mảng hiểu đa phương thức, năng lực suy luận bằng video được tăng cường: có thể xác định vị trí bằng chứng trong video và tích hợp thông tin xuyên nhiều khung hình. Với nhận thức hình ảnh, khả năng nhận diện vật thể 3D (chi tiết CAD, các thành phần trong engine game) và phân tích dữ liệu dày đặc gồm hình ảnh + văn bản (bản vẽ kỹ thuật, bảng biểu báo cáo tài chính) đã có cải thiện rõ rệt.

Về chi phí, mức tiêu hao Token cho suy luận hình ảnh và video giảm hơn 30% so với thế hệ trước.

Về sử dụng API, có hai lối vào: gọi Doubao-Seed-2.1-pro-0915 để khóa phiên bản; gọi Doubao-Seed-Evolving sẽ tự theo dõi phiên bản mới nhất, không cần đổi Model ID. Công việc của Doubao và TRAE cũng đã được đồng bộ tích hợp.

Bài viết chính thức: https://mp.weixin.qq.com/s/Fp_mgF6wxMk0bkUVBqOKqA

Kỹ sư của Anthropic giảng một buổi nhập môn về FDE
https://www.youtube.com/watch?v=KwhgfwOSToQ

Kevin Bai hiện đang làm việc trong nhóm Applied AI của Anthropic. Trước đó, anh là thành viên sáng lập của đội FDE tại Rippling, và trước nữa đã có vài năm làm việc tại Palantir. Gần đây, anh đã thực hiện một buổi chia sẻ về FDE 101, giải thích rất rõ vai trò của kỹ sư triển khai tuyến đầu—đáng để tổng kết.

Trước hết nói một con số: Trong các công ty SaaS đã niêm yết, xét theo giá trị hợp đồng trung bình thì Palantir đứng ở mức 4 triệu USD, ServiceNow là 1,2 triệu USD, Workday là 0,6 triệu USD; phần còn lại không công ty nào vượt quá 0,5 triệu USD. Palantir dùng vài nghìn người để đạt mức “giá trị khách hàng trên mỗi hợp đồng” mà người ta phải dùng tới vài chục nghìn người mới làm được. Điểm dựa chính là mô hình FDE.

Vậy FDE đang giải quyết vấn đề gì?

Sản phẩm của Palantir là Foundry—một nền tảng xây dựng ứng dụng, có ngưỡng kỹ thuật rất cao. Nhưng người mua lại là các quản lý không chuyên kỹ thuật trong những ngành như dầu khí, hàng tiêu dùng… Nếu bạn ném một nền tảng công nghệ phức tạp cho một người không biết viết code, rồi trông chờ họ tự hiểu cách sử dụng, thì điều đó là không thực tế.

Vì vậy cách làm của Palantir là: thứ khách hàng mua không phải là một sản phẩm phần mềm, cũng không phải dịch vụ tư vấn, mà là “một kết quả”. Bạn cử kỹ sư đến, đi sâu tìm hiểu bối cảnh kinh doanh của khách hàng, rồi xây dựng “thứ cần thiết” trên nền tảng đó cho họ. Khách hàng quan tâm là trên kệ tăng được bao nhiêu mặt hàng, hiệu suất dây chuyền được cải thiện đến mức nào—họ không quan tâm dữ liệu được tổ chức ra sao, và cũng không nên quan tâm.

FDE khác gì với phát triển thuê ngoài?

Kevin nhấn mạnh một điểm đặc biệt: Nếu kỹ sư của bạn mỗi lần đều phải bắt đầu từ số không để viết code tùy chỉnh cho khách hàng, thì đó không phải FDE—mà là phát triển thuê ngoài. Mô hình FDE chỉ hoạt động được nếu bạn có một nền tảng có thể tái sử dụng. Kỹ sư không “mỗi lần lại chế tạo bánh xe từ đầu”, mà lắp ghép và tùy biến dựa trên năng lực sẵn có của nền tảng. Nếu không có nền tảng, chi phí duy trì sẽ “nuốt” sạch mọi lợi nhuận, và kỹ sư cũng sẽ bỏ đi vì phải bảo trì hàng chục bộ code chẳng liên quan gì với nhau.

Có nên làm FDE không? Chỉ cần trả lời hai câu hỏi.

Thứ nhất, bạn có bắt buộc phải bán một thứ phức tạp về mặt kỹ thuật cho người mua không chuyên kỹ thuật hay không? Nếu khách hàng của bạn bản thân là kỹ sư—ví dụ như bán GitHub hoặc Datadog—thì không cần FDE. Nếu sản phẩm của bạn vốn là dạng “dùng là chạy ngay”, như Slack hoặc Jira, thì cũng không cần. Chỉ khi sản phẩm quá phức tạp và khách hàng lại không hiểu công nghệ thì FDE mới thực sự cần thiết.

Thứ hai, bạn có một nền tảng có thể tái sử dụng không? Hoặc bạn có sẵn sàng đầu tư để xây dựng một nền tảng không? Nếu không có các thành phần nền tảng dùng chung, FDE sẽ không bền vững.

Thay đổi mới trong năm 2026 là gì?

Nhận định của Kevin khá thú vị: cách thức làm ăn trong ngành phần mềm vốn đã thay đổi. AI khiến việc xây dựng phần mềm trở nên cực kỳ dễ dàng, và hầu như mọi nền tảng đều đang tiến tới “Agent hóa”. Điều này đồng nghĩa với việc ngày càng nhiều nền tảng trở nên có thể tùy biến cao. Hệ quả là: càng ngày càng nhiều khách hàng không hiểu rõ sản phẩm của bạn rốt cuộc có thể làm được gì. Trong thời đại Agent, việc “giao sự thành bại của sản phẩm” cho khách hàng tự sờ thử sẽ càng khó đi đến đúng hướng.

Vì thế FDE không còn là một “món chơi” nhỏ chỉ riêng Palantir, mà trở thành một vấn đề mà nhiều công ty phần mềm cần phải nghiêm túc cân nhắc.

Cuối cùng: Loại người nào phù hợp để làm FDE?

Câu trả lời của Kevin rất ngắn gọn: FDE là một vai trò dành cho một kỹ sư phần mềm mà bạn đủ tin để anh ấy có thể trực tiếp đối diện với khách hàng. Năng lực kỹ thuật là “mặt bằng cơ bản”, nhưng bạn còn phải yên tâm cho anh ấy đại diện cho công ty để giao tiếp và làm việc với khách hàng.

Gần đây vibe coding nhiều lắm, nhất là lúc hạn mức sắp reset. Lúc đó họ ném một loạt task cho Agent làm. Có vài task thì hiển thị là đã hoàn thành nên mình không để ý nữa, nhưng hôm sau test mới phát hiện task chưa xong. Quay lại kiểm tra thì mới biết là họ đã mở một worktree nào đó, chứ không sửa trên `main`, nên chẳng có gì được merge cả.

Mình lại nhờ Agent tập trung rà lại. Vẫn còn khá nhiều worktree như vậy, nên nó đã dọn giúp.

Cuối cùng mình bảo nó thêm một quy tắc vào Agents.md: không nói là không được tạo worktree, nhưng không được bỏ sót chỗ đó.

--- Tham khảo prompt duyệt worktree ---

Giúp mình xem những worktree nào chưa đồng bộ vào main, cái nào đã đồng bộ xong thì xóa luôn, cái chưa đồng bộ thì liệt kê: nhánh, tóm tắt nội dung sửa (kèm vài commit gần đây), và session hội thoại tương ứng

--- Tham khảo prompt dọn worktree ---
Giúp mình xem nội dung của những worktree này, xác định cái nào đáng để merge thì merge giúp mình và dọn worktree. Cái chưa chắc thì hỏi lại để mình xác nhận, nhưng phải đưa ra gợi ý rõ ràng cho mình.

--- Tham khảo quy tắc trong AGENTS.md ---

- Không để lại worktree: Các task làm trong worktree, khi hoàn thành phải xóa worktree đó và branch tương ứng. Trước khi xóa, chọn 1 trong 2: merge vào `main`; hoặc nếu không merge thì trước tiên commit các thay đổi chưa commit lên branch đó, gắn tag `archive/<worktree 名>` để lưu trữ, rồi chạy `git worktree remove` + `git branch -D`.

Phiên hội thoại của subagent được điều phối chịu trách nhiệm hoàn tất các worktree mà nó dẫn sinh. Những worktree buộc phải giữ lại (đợi người dùng quyết định, hoặc còn xung đột cần xử lý) thì phải nêu tên đường dẫn và lý do trong phản hồi cuối cùng; không được lặng lẽ để lại.

Cuối cùng cũng nhớ được tên CEO mới của Apple: John Ternus (Trương Thiết Ngưu)
😂
(Nguồn ảnh: Thiên Tài Tiểu Gấu Trúc, bản đầy đủ: https://weibo.com/1563926367/RhqQVsEDA)