Nếu bạn hỏi sản phẩm AI nào có mức tăng trưởng đáng chú ý nhất vào năm 2026, thì "Codex" chắc chắn đứng đầu danh sách.
Kể từ tháng 1 năm nay, số người dùng hoạt động hàng tuần của sản phẩm này đã tăng hơn 5 lần, đường cong tăng trưởng rất dốc. Hiện tại, quy mô người dùng hoạt động hàng tuần của nó đã đạt 5 triệu. Trong đó, tốc độ tiếp nhận Codex của những người lao động tri thức (không phải nhà phát triển) nhanh hơn gấp 3 lần so với nhóm nhà phát triển.
Đáng chú ý, những đường cong tăng trưởng dốc này có một chất xúc tác quan trọng — việc phát hành ứng dụng dành cho máy tính để bàn vào tháng 2. Phiên bản dành cho máy tính để bàn này cung cấp giao diện sử dụng chuyên dụng, tối ưu hóa, giảm đáng kể rào cản sử dụng, dẫn đến sự bùng nổ về lượng tải xuống và tiếp nhận Codex.
Đằng sau đường cong tăng trưởng dốc này, người thúc đẩy sự thay đổi hình thái sản phẩm là một vai trò tương đối ít được thảo luận công khai hơn — Andrew Ambrosino, Trưởng nhóm ứng dụng dành cho máy tính để bàn của Codex.
Là người trực tiếp chịu trách nhiệm về sự tiến hóa của sản phẩm phía máy tính để bàn Codex, anh ấy đồng thời đứng giữa hai thế giới đang nhanh chóng chồng lấn lên nhau: một bên là chuỗi công cụ dành cho nhà phát triển lấy "viết mã" làm trọng tâm, bên kia là cổng vào làm việc AI thông dụng đang mở rộng nhanh chóng đến hầu hết mọi bối cảnh công việc tri thức. Từ nhịp độ phát hành sản phẩm đến sự thay đổi hành vi người dùng, cho đến việc nội bộ đội ngũ định nghĩa lại ranh giới giữa "thiết kế", "kỹ thuật" và "sản phẩm", những gì anh ấy nhìn thấy thường gần với bản chất của sự thay đổi này hơn là chính dữ liệu tăng trưởng.
Cuộc phỏng vấn tiếp theo đây, chính là từ góc nhìn của anh ấy, để phân tích Codex đã thay đổi điều gì, tại sao lại hợp nhất với ChatGPT, và hướng lặp lại tương lai của nó sẽ như thế nào.
Liên kết video: https://www.youtube.com/watch?v=P3KDebPTUrw
Chúng tôi đã tổng hợp một phần nội dung cuộc phỏng vấn, chi tiết nội dung vui lòng tham khảo video gốc.
Việc triển khai trở nên rẻ hơn,
vậy cái gì trở nên đắt hơn?
Vài năm trước, logic phát triển sản phẩm là như thế này: triển khai rất đắt. Vì vậy, trước khi bắt tay viết mã, bạn phải làm rất nhiều công việc giảm thiểu rủi ro trước — viết tài liệu, nghiên cứu, làm nguyên mẫu, mục đích là để thiết kế rẻ hơn. Chính vì bản thân chi phí triển khai cao, bạn phải sắp xếp mọi thứ rõ ràng ngay từ đầu.
Nhưng bây giờ giả định này đã hoàn toàn đảo ngược. Tại OpenAI, tình hình đã trở thành như thế này: cung cấp cho mọi người một lượng lớn token, ai cũng có ý tưởng hay, vì vậy ai cũng đang tạo ra thứ gì đó. Kết quả là, một tính năng cần làm, có thể có 90 đội ngũ khác nhau cùng lúc khám phá 90 cách triển khai khác nhau.
Điều này có nghĩa là triển khai không còn là phần đắt đỏ nữa. Vậy cái gì trở nên đắt hơn? Andrew thẳng thắn nói: là gu thẩm mỹ. Cụ thể hơn, là quá trình giám tuyển. Khi bạn đối mặt với 90 thử nghiệm khác nhau này, bạn cần có con mắt để đánh giá: những thứ nào làm tốt? Những thứ này nên được tích hợp vào các tính năng khác như thế nào? Nên đóng khung thứ này như thế nào? Nút chuyển đổi này nên có mấy cấp độ? Bản thân những quyết định này mới là nơi đắt đỏ nhất, cần suy nghĩ nhất hiện nay.
Gu thẩm mỹ thực sự là gì?
Từ "gu thẩm mỹ" này ở thung lũng Silicon đã bị nói nhàm. Nhưng đối với Andrew ở đây, nó có ý nghĩa rất cụ thể.
Có một câu chuyện vui thế này, người phụ trách sản phẩm của Linear từng nói có người nhấn mạnh quá mức phần thẩm mỹ của gu thẩm mỹ, rồi lấy Paul Graham làm ví dụ — Paul Graham rõ ràng là có gu thẩm mỹ tốt, nhưng anh ấy mặc quần yếm. Điều này chứng tỏ gu thẩm mỹ xa hơn vẻ bề ngoài. Andrew liệt kê nội hàm của gu thẩm mỹ: có khía cạnh thẩm mỹ, nhưng đó chỉ là một phần; có khía cạnh tư duy hệ thống, tức là thứ này hòa nhập vào toàn bộ hệ thống như thế nào; có khía cạnh cảm giác về phương hướng, đây là một phần của chủ đề gì; có khía cạnh về cách thức trình bày. Tất nhiên còn có một số khía cạnh chi tiết, chẳng hạn như hoạt ảnh tương tác này có phù hợp với ý nghĩa ngữ nghĩa mà nó muốn truyền đạt hay không — nó có quá nhanh không, không phù hợp để thể hiện khái niệm này.
Nhưng câu hỏi về gu thẩm mỹ thực sự cốt lõi là như thế này: nếu chúng ta có thể xây dựng bất cứ thứ gì, vậy chúng ta muốn gì? Đây là cái gì? Làm thế nào chúng ta đến được đó? Đây mới là những câu hỏi về gu thẩm mỹ thực sự.
Nó không chỉ là về việc lựa chọn làm gì. Cũng là về cách thể hiện thông tin, cách đạt được mục tiêu, sử dụng phương tiện gì. Gu thẩm mỹ là nơi bộ não con người vẫn còn giá trị nhất trong thời đại mới này.
Tại sao AI đến nay vẫn chưa làm tốt thiết kế?
Đây là một nghịch lý thú vị: Codex đã rất mạnh mẽ trong việc viết mã, nhưng khi dùng nó để tạo ra thiết kế, chất lượng đầu ra thường tầm thường. Ít khi có thể nói "wow, nó hoàn toàn xử lý được".
Andrew cho rằng đằng sau điều này có mấy lớp nguyên nhân. Đầu tiên là nguyên nhân thực tế. Thiết kế khó đánh giá hơn phần mềm, bởi vì gu thẩm mỹ của con người đánh giá thiết kế tốt xấu chính là một phần của cơ chế phản hồi. Điều này khiến việc huấn luyện mô hình trở nên khó khăn — không giống như mã, bạn khó có thể đo lường bằng tiêu chuẩn khách quan (mã có biên dịch được không? Chức năng có hoạt động bình thường không?). Thứ hai, từ góc độ đầu tư nghiên cứu, phòng thí nghiệm trước nay đã đầu tư nhiều nguồn lực nhất để nâng cao những khả năng có thể thúc đẩy chính nghiên cứu AI. Trong thời kỳ đầu của mô hình viết mã, rõ ràng việc viết đúng mã sẽ thúc đẩy nghiên cứu. Nhưng khả năng thiết kế tốt hay không, tác dụng thúc đẩy nghiên cứu AI không trực tiếp như vậy.
Vấn đề sâu hơn liên quan đến sự phức tạp của bản thân công việc thiết kế. Trong thiết kế có một khía cạnh văn hóa — cái gì được coi là "thiết kế tốt" do văn hóa quyết định. Năm ngoái tất cả các trang web mới đều sao chép thiết kế của Linear, đó là thiết kế tốt thực sự, có gu thẩm mỹ. Nhưng nếu một mô hình mỗi lần đầu ra đều giống Linear, đó không phải là tiến bộ, mà là thất bại. Thiết kế cần tính mới lạ, trong khi kỹ thuật phần mềm thì ngược lại, bạn hầu như luôn muốn mã tuân theo các mẫu đã biết.
Vấn đề khó giải quyết nhất nằm ở lớp trừu tượng. Khi mã điều khiển thiết kế trực quan, giữa hai bên tồn tại sự tương tác sâu sắc. Ví dụ, một thứ ở góc trên bên trái nên chia sẻ cùng một sự trừu tượng trong kho mã với một nơi nào đó bên dưới. Điều này không chỉ là nói mô hình cần trở thành nhà thiết kế giỏi hơn, mà là mô hình cần hiểu những mối quan hệ cấu trúc sâu hơn này — nếu ngày mai công ty tái tạo thương hiệu, cách làm nông cạn là cập nhật lần lượt 263 thành phần, nhưng hiểu biết sâu sắc phải là: hai thứ trông khác nhau này về mặt ngữ nghĩa là giống nhau, chúng đều là danh sách, đều có kiểu dáng giống nhau, đều truyền tải cùng một mẫu tương tác. Sự hiểu biết ở lớp trừu tượng này, hiện tại đối với AI vẫn còn rất xa vời.
Tại sao Codex không thể phát hành sớm hơn?
Đây là một quan sát rất sâu sắc: thành công của sản phẩm không chỉ phụ thuộc vào bản thân thiết kế, mà còn phụ thuộc vào thời điểm năng lực của mô hình.
Andrew rất chắc chắn, nếu ứng dụng Codex được ra mắt vào tháng 11 năm ngoái, nó sẽ thất bại hoàn toàn trên thị trường. Còn nếu cùng một hình thái sản phẩm đó được ra mắt vào tháng 2, lại thu được thành công lớn. Biến số duy nhất là sự tiến bộ về năng lực mô hình trong vài tháng giữa này. Nói cách khác, thiết kế tương tác, giao diện người dùng, toàn bộ khái niệm của sản phẩm đều không thay đổi, nhưng sự cải thiện về mức độ thông minh của mô hình đã hoàn toàn thay đổi kết quả.
Điều này hé lộ một sự thật sâu sắc: trong thời đại AI, việc sản phẩm có dễ dùng hay không, có giá trị hay không, không phải do UI hay thiết kế tương tác đơn thuần quyết định, mà là do "mô hình có thể làm được gì tại thời điểm này" quyết định. Cùng một ý tưởng, dùng mô hình cũ để triển khai có thể vô dụng, nhưng dùng mô hình mới thì có thể thú vị tuyệt vời.
Điều này cũng thay đổi cách lập kế hoạch sản phẩm. Andrew đã từng thấy sự chuyển đổi này ở công ty trước đây: không còn là "chúng tôi lên kế hoạch làm gì trong cả năm", mà trở thành "chúng tôi tin rằng mô hình có thể làm gì tại thời điểm nào, hãy liệt kê tất cả những thứ quan tâm, làm nguyên mẫu cho tất cả chúng, sau đó quyết định cái nào có thể làm ngay bây giờ, những cái khác tạm thời để đó chờ đợi, đợi đến khi mô hình có bước nhảy vọt mới, rồi dùng mô hình đã nâng cấp thử nghiệm những ý tưởng trước đó bị bỏ lại". Bởi vì tiền đề của việc toàn bộ tính năng có dễ dùng hay không, không phải là hình thái thiết kế, mà là mô hình có đủ thông minh hay không.
Ranh giới giữa Kỹ sư, Nhà thiết kế, PM đã biến mất chưa?
Lenny đề cập, nhìn vào lý lịch của Andrew, kỹ sư, nhà thiết kế, giám đốc sản phẩm, doanh nhân anh ấy đều đã làm, bây giờ quản lý toàn bộ ứng dụng máy tính để bàn, liền hỏi đội thiết kế có thuộc anh ấy quản lý không. Andrew cười nói "tùy từng tuần" — mối quan hệ báo cáo luôn thay đổi, nhưng đội ngũ luôn ngồi gần nhau, làm việc chặt chẽ, đan xen lẫn nhau.
Andrew nói, bên ngoài đã thảo luận về "sự sụp đổ vai trò", nói rằng sau này sẽ không còn phân chia vai trò nữa, đội của họ chưa đến mức đó, nhưng sự chồng lấn giữa các vai trò quả thực rõ ràng hơn so với các bộ phận khác trong công ty, thậm chí toàn ngành — một phần lý do là Codex vốn là sản phẩm kỹ thuật hướng đến kỹ sư, nhà thiết kế trong đội có thể nói ngôn ngữ của kỹ sư, giám đốc sản phẩm cũng có thể viết mã, ví dụ như một giám đốc sản phẩm khác Alexander có bằng thạc sĩ khoa học máy tính, còn bản thân Andrew thì không.
Anh ấy cho rằng, bây giờ cách nói chính xác hơn là: một người không còn được định nghĩa bởi ranh giới "thiết kế kết thúc ở đâu, kỹ thuật bắt đầu từ đâu", mà là bởi anh ấy trung bình dành thời gian làm gì — điều này cũng liên quan đến cách làm việc của đội, bởi vì toàn bộ ứng dụng được vận hành dựa trên việc nội bộ "tự ăn thức ăn của chính mình", mọi người đều muốn cố gắng hoàn thành công việc trong ứng dụng, ngay cả khi tạm thời nó chưa phải là công cụ tốt nhất để làm việc đó, như vậy nó mới có thể dần dần trở thành công cụ tốt nhất. Hai người cũng thuận tiện nói về nguồn gốc của danh hiệu "member of technical staff", Andrew cho rằng sớm nhất có thể là Xerox bắt đầu gọi như vậy, ngày nay trong các công ty nghiên cứu thúc đẩy đã trở thành một truyền thống.
Lenny truy hỏi, điều này có nghĩa là tương lai mọi người sẽ trở thành "người xây dựng" không phân chức năng, các phân loại kỹ năng PM, thiết kế, kỹ thuật này còn tồn tại không. Thái độ của Andrew rất rõ ràng: anh ấy không đồng tình với việc xóa bỏ hoàn toàn sự phân chia vai trò. Anh ấy đã thấy không ít công ty hô hào "hủy bỏ vị trí sản phẩm, mọi người đều là người xây dựng", kết quả là những thực tiễn tốt nhất tích lũy qua nhiều năm, kinh nghiệm thử sai của chuyên ngành sản phẩm này, chỉ vì suy nghĩ "tôi cũng có thể viết mã" mà bị coi là vô dụng vứt bỏ. "Đây không phải là địa bàn của bạn" loại cảm giác ranh giới chia cắt kiểu vạch đất giành nhau này biến mất, anh ấy hoan nghênh, nhưng mỗi chuyên ngành vẫn có ngưỡng kỹ năng riêng — không phải ai dùng Excel, là có thể đến bộ phận tài chính thay thế.
Anh ấy cũng đề cập, bây giờ thay đổi vai trò quả thực dễ hơn trước, vì năng lực không còn gắn chết với "có thông thạo một công cụ cụ thể hay không": bản thân anh ấy từng lâu dài cảm thấy không nên làm kỹ sư, vì không thích nghiên cứu sâu ngôn ngữ assembly, học thuộc cú pháp TypeScript, mà ngưỡng "thông thạo một công cụ cụ thể mới là làm tốt" này đang bị phá vỡ. Tuy nhiên anh ấy cũng nhắc nhở, xu hướng này hiện đang bị thổi phồng quá mức ở bên ngoài.
Phương thức phát triển hỗ trợ AI tiên tiến nhất hiện nay
Lenny kéo chủ đề trở lại một tầng: từ viết mã hoàn toàn thủ công, đến AI có thể viết 100% mã, rồi bây giờ "viết mã" đã trở thành "hướng dẫn AI" — đánh giá một người viết bao nhiêu mã, gần như đã trở thành "bạn đã sửa hướng cho AI mấy lần". Anh ấy hỏi, cách làm tiên tiến nhất hiện nay có phải là "loop" (vòng lặp phát triển tự chủ) không? Những đội AI đi đầu nhất, bây giờ cụ thể vận hành như thế nào?
Andrew đề cập, một vấn đề bản chất là, câu hỏi "bao nhiêu phần trăm mã là do AI viết" bản thân nó đã không quan trọng nữa, bởi vì theo tiêu chuẩn năm ngoái, bây giờ gần như 100% mã đều do AI viết; thực sự nên hỏi là, những mã này là viết ra "có giám sát", hay là "không giám sát", đây là hai việc hoàn toàn khác nhau. Anh ấy nói mình vui thấy loại tiêu chuẩn đánh giá này liên tục được làm mới, bởi vì điều này chính xác chứng tỏ sản phẩm đang tiến về phía trước. Đội đã làm nhiều thăm dò về hướng "phát triển phần mềm tự chủ", cũng bao gồm nhiều thử nghiệm liên quan đến "kỹ thuật khai thác" (harness engineering), ví dụ như hình dung để mô hình tự chạy một lượt vào ban đêm, dọn dẹp kho mã một lần theo kiểu "thu gom rác".
Anh ấy cũng thừa nhận, hiện tại tất cả các mô hình đều có một nhược điểm chung — có xu hướng làm cho mã càng sửa càng phức tạp. Anh ấy nửa đùa nửa thật nói, nếu đội nghiên cứu công ty nào đang nghe, hy vọng có thể luyện khả năng "xóa mã" của mô hình tốt hơn một chút. Đây cũng là vấn đề thực tế gặp phải khi giao phát triển hoàn toàn cho lái tự động, cả hai đầu con người và kho mã đều như vậy: làm thế nào dạy mô hình phán đoán nên làm tính năng nào, nên bỏ qua cái nào, cái nào nên hợp nhất phân loại lại; làm thế nào dạy mô hình xây dựng cấu trúc trừu tượng chính xác. Những khả năng này đang trở nên tốt hơn, nhưng anh ấy cho rằng hiện tại vẫn chưa thể đạt đến mức độ "thiết lập một vòng lặp để nó tự cải thiện sản phẩm, đồng thời theo dõi Twitter, Slack, email", nhưng đội ngũ luôn nỗ lực theo hướng này.
Lenny truy hỏi, liệu có ngày nào đó, đội ngũ đơn giản trực tiếp đặt cho AI một mục tiêu cuối cùng như "chiến thắng" hay "kiếm cho tôi một trăm triệu đô la" là xong. Andrew cười nói mình không dám nói chắc, sẽ không dễ dàng khẳng định "sẽ không bao giờ" hoặc "chắc chắn sẽ".
Tại sao nhất định phải hợp nhất Codex và ChatGPT?
Tương lai của Codex sẽ đi về đâu?
Codex ban đầu là công cụ dòng lệnh, sau đó mới làm thành ứng dụng độc lập, định vị ban đầu rất rõ ràng: một "công cụ dành cho nhà phát triển" — không phải IDE, có thể xem mã, nhưng không cho phép chỉnh sửa mã.
Trước khi ứng dụng chính thức phát hành ra bên ngoài, đội ngũ đã thử nghiệm một lượt nội bộ tại OpenAI (tháng 1-2). Trong bối cảnh kỹ thuật và nghiên cứu, phản hồi rất rõ ràng, rất tích cực. Nhưng đội đồng thời phát hiện, thị trường, quan hệ công chúng, tài chính, pháp lý và hầu như tất cả các bộ phận khác cũng đang sử dụng ứng dụng này — mặc dù trải nghiệm của nó không thân thiện với những người này, trong giao diện toàn là mã và quyền truy cập dòng lệnh, hoàn toàn không phải trải nghiệm được thiết kế cho họ.
Đội ngũ ban đầu đối phó bằng cách chuyển năng lực của Codex sang giao diện sản phẩm khác, ví dụ như ứng dụng máy tính để bàn ChatGPT và trình duyệt Atlas, làm thành công cụ làm việc tri thức thông dụng hơn. Nhưng kết quả là không ai muốn rời khỏi ứng dụng Codex để dùng những ứng dụng được "chuyên biệt" tạo ra đó. Điều này khiến đội nhận ra: ranh giới giữa công cụ dành cho nhà phát triển và công cụ tri thức thông dụng đang sụp đổ, Codex và ChatGPT giống như các cổng vào khác nhau của cùng một năng lực hơn là hai loại sản phẩm độc lập.
Kết luận của đội là: bộ sản phẩm này nên làm thành một nền tảng đủ thông dụng, có thể mở rộng, có thể đồng thời tiếp nhận các bối cảnh sâu như tài chính, pháp lý, khoa học. Thách thức thực sự chỉ nằm ở "làm thế nào để nó đủ thông dụng" — đây cũng là câu trả lời của đội cho câu hỏi "Codex rốt cuộc là công cụ dành cho nhà phát triển, hay đơn giản chính là ChatGPT".
Người dẫn chương trình Lenny từ đó chỉ ra: Codex đã làm tốt hơn, thú vị hơn chính ứng dụng ChatGPT, người dùng đều chạy sang dùng nó, vì vậy hợp nhất là hướng đi tất yếu, có thể tránh nhận thức hỗn loạn.
Andrew cười đáp lại nói, có người gọi hướng này là "siêu ứng dụng" (super app), anh ấy khá hối hận khi đó có người nói ra từ này, bởi vì từ đó trở đi, mỗi ngày anh ấy đều bị cách nói này bao vây.
Lenny truy hỏi: trước tiên không gọi nó là "siêu ứng dụng", nhưng ý tưởng cốt lõi có phải là "người dùng đến một nơi, là có thể hoàn thành tất cả mọi việc" không? Hay là, việc này hiện tại vẫn chưa có kết luận?
Câu trả lời Andrew đưa ra, là khái niệm "home base" (căn cứ chính): đây nên là một "sân nhà" tốt, một nơi người dùng có thể theo dõi tất cả công việc cần làm của mình trên các giao diện sản phẩm khác nhau. Một số việc, người dùng có thể hoàn toàn hoàn thành bên trong ứng dụng; những việc khác, ứng dụng thì chịu trách nhiệm gọi, mở ứng dụng khác để hoàn thành — ví dụ, ứng dụng có thể kết nối với Excel, bên trong ứng dụng thực sự cũng tích hợp một trình soạn thảo bảng tính, nhưng đối với người cần làm mô hình tài chính phức tạp cho vòng gọi vốn hàng chục tỷ đô la tại OpenAI, trình soạn thảo tích hợp này có thể còn xa mới đủ. Vì vậy ứng dụng sẽ trực tiếp trò chuyện với phần mở rộng Microsoft Excel trên máy tính để bàn của người dùng, đợi việc xong, người dùng có thể trực tiếp tắt Excel.
Cũng tức là, việc này xưa nay không phải là "chúng tôi vẽ một khung trên màn hình, tất cả mọi việc đều phải xảy ra trong khung này", mà là — thứ này nên trở thành một "ngôi nhà" của người dùng: bạn bắt đầu công việc ở đây, kết thúc công việc ở đây, tự động hóa công việc, cần dùng công cụ gì, nó sẽ đi gọi công cợ đó.
Để minh họa điều này, Andrew kể một câu chuyện cụ thể. Khi ứng dụng Codex mới phát hành, đội đã quay một loạt video quảng cáo, việc cắt những video này rơi vào tay nhiếp ảnh gia nội bộ. Kết quả, nhiếp ảnh gia đã dùng Codex cắt xong toàn bộ những video này — đây là một trong những khoảnh khắc đội thực sự nhận ra "trời ơi, mọi người thực sự đang dùng thứ này làm việc kiểu này".
Nhiếp ảnh gia nghĩ đến việc dùng Codex cắt video, hoàn toàn là do tò mò, chỉ muốn xem Codex rốt cuộc có làm được việc này không. Bản thân Codex hoàn toàn không phải là một trình chỉnh sửa video, trong giao diện cũng không có bất kỳ UI liên quan đến cắt nào, nhưng nó có thể hiểu nhiếp ảnh gia đang dùng Premiere Pro, và có thể thông qua việc trực tiếp chỉnh sửa các tệp kỹ thuật đằng sau, hỗ trợ hiển thị nội dung màn hình của Premiere Pro, hoàn thành một phần thao tác cắt — chỉ là như vậy vẫn chưa thể đáp ứng tất cả nhu cầu. Vì vậy, việc Codex làm tiếp theo, là tự viết cho mình một phần mở rộng có thể cài vào Premiere Pro, sau đó thông qua phần mở rộng này "trò chuyện" với Premiere Pro — "này, phần mở rộng Premiere Pro, có thể giúp tôi sửa điểm đánh dấu này không." Đội lần đầu tiên nhìn thấy quá trình này thực sự xảy ra, đều cảm thấy việc này thật không thể tin nổi.
Từ đó, Andrew tổng kết ra một mô hình: trên thế giới đã tồn tại một lượng lớn công cụ chuyên nghiệp đạt đến mức hoàn hảo trong lĩnh vực riêng của chúng, Codex — bây giờ phải thêm ChatGPT — muốn đồng thời làm hai việc.
Việc thứ nhất, là làm thế nào để hợp tác liền mạch với những công cụ mà người dùng đang sử dụng: đội không cần tạo lại một trình chỉnh sửa video tốt hơn, mà là để Codex và ChatGPT học cách sử dụng công cụ có sẵn — có thể tương tác với nó, bàn giao công việc cho nó, điều này thường thông qua connectors (bộ kết nối), computer use (khả năng sử dụng máy tính), hoặc giống như trường hợp Premiere Pro này, thông qua phần mở rộng để thực hiện.
Việc thứ hai, thì là loại hình dung mà Dan Shipper từng đề cập: người dùng trong tay đã có một đống ứng dụng web có thể nhấp để sử dụng, nhưng hy vọng có thể mở những ứng dụng này trực tiếp trong Codex, để Codex thay họ làm nhiều việc hơn một chút trong đó. Hai mô hình này, gần như đối xứng với nhau, đội hiện đang đồng thời đẩy mạnh cả hai tuyến này.
Bài viết này từ tài khoản công chúng WeChat “机器之心” (ID: almosthuman2014), tác giả: 机器之心
