Biên soạn và dịch bởi: TechFlow TechFlow
Khách mời: Jenny Wen, Trưởng bộ phận Thiết kế tại Cowork
Người dẫn chương trình: Peter Yang
Nguồn podcast: Peter Yang
Tựa gốc: Hướng dẫn sử dụng Claude Cowork từ Trưởng nhóm thiết kế của Cowork (40 phút) | Jenny Wen
Ngày phát sóng: 29 tháng 3 năm 2026
Tóm tắt các điểm chính
Jenny là trưởng nhóm thiết kế tại Cowork. Cô ấy đã cho tôi tìm hiểu sâu về cách thức hoạt động bên trong của Anthropic, bao gồm cả cách cô ấy sử dụng Cowork để thiết kế và phát triển sản phẩm, cũng như câu chuyện thực sự đằng sau sự ra đời của Cowork. Anthropic phát hành các tính năng mới gần như mỗi ngày, và việc chứng kiến cách chúng hoạt động thực sự rất ấn tượng.
Tóm tắt quan điểm chính
Về phương pháp làm việc hàng ngày
- Hầu hết công việc của tôi liên quan đến việc đưa sản phẩm ra thị trường. Nhưng tôi nghĩ nó có thể trông hơi khác so với một hoặc hai năm trước. Một phần lớn trong đó thực chất là làm việc nhóm (hợp tác ngẫu hứng) với các kỹ sư, quản lý sản phẩm, v.v. theo cách không chính thức. Thông thường, chúng tôi sẽ cùng nhau xem xét một nguyên mẫu, sau đó chỉ ra và suy nghĩ về cách nó có thể phát triển.
Triết lý "đầu tư vào rác, đầu tư vào kho báu"
- Điều tôi thấy ấn tượng nhất ở Cowork là khả năng tổ chức thông tin của nó. Tôi thích gọi đó là "đầu vào rác, đầu ra kho báu". Nó có thể thu thập thông tin từ nhiều nguồn khác nhau, nhanh chóng xác định trong đó điểm chính, trích xuất nội dung có giá trị và biến chúng thành kết quả hiệu quả.
Sự khác biệt giữa Cowork và Claude Code
- Ngoài những công việc viết mã sản phẩm rất chi tiết, giờ đây tôi sử dụng Cowork cho hầu hết mọi thứ. Nếu cần tập trung vào một số chi tiết mã nhất định, tôi vẫn sẽ dùng Claude Code. Nhưng đối với việc giao tiếp và cộng tác hàng ngày, giờ đây tôi hoàn toàn dựa vào Cowork.
Câu chuyện về sự ra đời của Cowork
- Câu nói "họ hoàn thành nó trong 10 ngày" thực chất được trích từ lần cuộc phỏng vấn hoặc bản tin truyền thông. Nhưng sự thật là, chúng tôi đã bắt đầu hình thành ý tưởng về mô hình Cowork khi tôi gia nhập Anthropic cách đây một năm. Chúng tôi đã suy nghĩ về cách tạo ra một "đối tác tư duy" có thể hỗ trợ tất cả những người lao động có kiến thức chuyên môn.
- Mặc dù Claude Code đã xử lý khá tốt nhiệm vụ liên quan đến lập trình, mục tiêu của chúng tôi là bao quát tất cả các kịch bản công việc dựa trên tri thức. Tôi nghĩ thách thức thực sự nằm ở chỗ: làm thế nào để thực hiện ý tưởng này? Kiến trúc nào là phù hợp nhất? Trải nghiệm người dùng (UX) nào là đúng đắn?
Sự phát triển của quy trình thiết kế
- Tôi vẫn sẽ dùng Figma. Nhưng giờ chúng ta không còn lập tài liệu đặc tả thường xuyên nữa, và chúng thường cũng không chi tiết như trước. Chúng ta vẫn sẽ lập sắp xếp, và nó vẫn sẽ tồn tại dưới dạng tài liệu, nhưng thường chỉ là một vài gạch đầu dòng, chứ không phải là một bảng biểu được thiết kế quá cầu kỳ.
Về kế hoạch và viễn cảnh mong đợi
- Lĩnh vực công nghệ mà chúng ta đang hoạt động đang thay đổi cực kỳ nhanh chóng, với các mô hình mới liên tục xuất hiện và được cập nhật với tốc độ ngày càng tăng. Do đó, việc xây dựng viễn cảnh mong đợi một năm là không thực tế, chứ chưa nói đến viễn cảnh mong đợi hai đến năm năm, bởi vì có quá nhiều điều chưa biết.
Tương lai của các nhà thiết kế
- Nếu bạn cảm thấy mặt đất dưới chân mình đang rung chuyển, đó là vì nó thực sự đang thay đổi. Chúng ta phải thừa nhận điều này và học cách thích nghi, đồng thời xem xét lại các phương pháp làm việc hiện tại của mình với một tư duy cởi mở.
- Mỗi khi cảm thấy gặp khó khăn trong sự nghiệp, tôi lại nghĩ đến các đồng nghiệp kỹ sư của mình. Công việc của họ đã trải qua những thay đổi to lớn, nhưng họ không chỉ thích nghi với những thay đổi đó mà còn đón nhận thử thách với lòng dũng cảm và sự khiêm tốn tuyệt vời, cuối cùng đạt được kết quả hiệu quả và xuất sắc hơn. Họ là nguồn cảm hứng của tôi – tôi tự nhủ rằng nếu những đồng nghiệp mà tôi vô cùng kính trọng có thể làm được, thì tôi cũng có thể. Họ là hình mẫu của tôi về khả năng thích ứng với sự thay đổi.
Khai mạc
Peter Yang: Chào mọi người, tôi rất vui mừng chào đón Jenny, Trưởng nhóm Thiết kế tại Anthropic. Jenny sẽ giới thiệu cho chúng ta cách cô ấy sử dụng Claude Cowork và Claude Code để thiết kế và ra mắt sản phẩm, chia sẻ những câu chuyện hậu trường về Cowork, và có thể cả những bước tiếp theo trong quá trình phát triển sản phẩm của cô ấy.
Jenny, một ngày làm việc điển hình của bạn diễn ra như thế nào? Nhiệm vụ nào chiếm phần lớn thời gian của bạn?
Jenny:
Tôi không biết liệu có một ngày làm việc điển hình nào không, nhưng phần lớn công việc của tôi liên quan đến việc đưa sản phẩm ra thị trường. Tuy nhiên, tôi cảm thấy nó có thể khác so với một hoặc hai năm trước. Một phần lớn trong đó thực chất là làm việc nhóm (hợp tác ngẫu hứng) với các kỹ sư và những người làm sản phẩm theo cách ít trang trọng hơn. Thông thường, chúng tôi cùng nhau xem xét một nguyên mẫu, sau đó chỉ ra và suy nghĩ về cách nó có thể được cải tiến. Đôi khi chỉ là thảo luận về hiệu suất của các tính năng, và đôi khi tôi tự mình triển khai mọi thứ. Tôi nghĩ rằng tôi vẫn dành nhiều thời gian cho việc thiết kế và tạo nguyên mẫu, nhưng cách thức làm việc thiết kế bây giờ cảm thấy thoải mái hơn nhiều.
Peter Yang: Về cơ bản, bạn sẽ tạo ra một loạt nguyên mẫu bằng cách sử dụng một công cụ như Claude, sau đó cho các kỹ sư xem thử, đưa ra phản hồi cho họ, và sau đó sử dụng các gợi ý để cho AI cải thiện chúng, đúng không?
Jenny:
Trên thực tế, đây thường không chỉ là nguyên mẫu, mà là các nguyên mẫu hoạt động đã được xây dựng nội bộ và đang chạy trên các môi trường Claude hoặc Cowork. Tôi thường dành thời gian sử dụng tính năng đó, thử nghiệm, xem nó có thể làm được gì, hình thành ý kiến, và lần lặp tiếp theo thường là tôi ngồi xuống với một kỹ sư và nói, "Này, đây là những gì tôi nghĩ. Đây là những chỗ tôi cảm thấy cần thay đổi." Tôi cảm thấy vẫn còn thời gian để lặp lại, tinh chỉnh và hoàn thiện trong các công cụ thiết kế, điều đó vẫn rất, rất quan trọng. Vì vậy, phần đó vẫn chưa biến mất. Chỉ là vì tôi đang xử lý nhiều dự án cùng lúc, nên tôi cảm thấy việc thực hiện nó một cách rất tùy ý, rất không chính thức sẽ hiệu quả hơn.
Peter Yang: Tôi nghĩ đó luôn là phần tôi thích nhất khi làm quản lý sản phẩm hoặc thiết kế – việc kết nối các nhà thiết kế và kỹ sư lại với nhau và cùng nhau chứng kiến sản phẩm được cải tiến. Vậy, các bạn không còn tạo ra những tài liệu đặc tả hoặc file Figma nữa à? Hay các bạn chỉ trực tiếp chỉnh sửa nguyên mẫu trong mã nguồn?
Jenny:
Tôi vẫn dùng Figma. Nhưng giờ chúng tôi không làm tài liệu đặc tả thường xuyên nữa, và chúng thường không chi tiết như trước. Đúng vậy. Chúng tôi vẫn sắp xếp, và nó vẫn tồn tại dưới dạng tài liệu. Điều này thực sự hữu ích khi chúng tôi chuyển giao cho đội ngũ bảo mật hoặc pháp lý để họ hiểu về bản phát hành, nhưng thường thì nó chỉ là một vài gạch đầu dòng. Không phải là một bảng biểu được thiết kế quá cầu kỳ. Tôi nghĩ các tệp Figma của chúng tôi cũng vậy.
Buổi trình diễn thực tế về không gian làm việc chung
Peter Yang: Anh/Chị có thể cho chúng tôi xem cách anh/chị sử dụng những sản phẩm này, hoặc anh/chị dùng từng sản phẩm để làm gì được không?
Jenny:
Tất nhiên rồi! Để tôi kể cho bạn nghe cách tôi sử dụng Cowork. Thực ra, tôi có một bí mật nhỏ: ngoài những công việc viết mã sản phẩm rất chi tiết, giờ đây tôi sử dụng Cowork cho hầu hết mọi thứ. Nếu cần tập trung vào một số chi tiết mã nhất định, tôi vẫn sẽ dùng Claude Code. Nhưng đối với việc giao tiếp và cộng tác hàng ngày, giờ đây tôi hoàn toàn dựa vào Cowork.
Điều tôi thấy ấn tượng nhất ở Cowork là khả năng tổ chức thông tin của nó. Tôi thích gọi đó là "đầu vào rác, đầu ra kho báu". Nó có thể thu thập thông tin từ nhiều nguồn khác nhau, nhanh chóng xác định trong đó điểm chính, trích xuất nội dung có giá trị và biến chúng thành kết quả hiệu quả.
Ví dụ, tôi đã kết nối đến một thư mục chứa bản ghi phỏng vấn người dùng. Đội ngũ Cowork của chúng tôi rất chú trọng đến việc giữ liên lạc chặt chẽ với người dùng, đây là một trong những chìa khóa thành công của chúng tôi. Chúng tôi tương tác trực tiếp với người dùng thông qua nghiên cứu trải nghiệm người dùng (UXR) truyền thống, cũng như các phương pháp nội bộ, chẳng hạn như kênh Slack chuyên dụng để thu thập phản hồi. Hơn nữa, chúng tôi theo dõi các cuộc thảo luận trên mạng xã hội và lắng nghe ý kiến của những người dùng nhiệt tình. Chính nhờ duy trì liên lạc chặt chẽ với người dùng và khả năng nhanh chóng cải tiến sản phẩm mà chúng tôi đã có thể liên tục nâng cao và đạt được thành công như hiện nay.
Vậy nên bây giờ tôi sẽ nói với Claude: Này, tôi có thư mục phỏng vấn này, nhưng tôi cũng sẽ nhờ Claude xem xét mạng xã hội, Reddit và các đánh giá khác của khách hàng Cowork rồi cho tôi biết những thông tin quan trọng nhất là gì. Việc này có thể mất chút thời gian vì nó thực sự phải xử lý và thao tác với dữ liệu lớn như vậy. Nhưng nó sẽ thực hiện những việc như đôi khi tạo ra các tác nhân phụ để xử lý song song và dành thời gian tìm kiếm trực tuyến.
Peter Yang: Trong công việc thực tế của anh, anh có nhận được báo cáo tóm tắt hàng tuần hoặc những thứ tương tự không? Ví dụ như một hệ thống tự động tổng hợp tất cả nội dung và gửi cho anh và đội ngũ?
Jenny:
Thực ra, chúng ta hoàn toàn có thể xây dựng nó trực tiếp bằng Cowork ngay bây giờ. Tôi nghĩ một trong những nhà nghiên cứu của chúng tôi sẽ phát hành nó, và một người khác sẽ thông báo phiên bản của chúng tôi trên Slack. Chúng tôi cũng trực tiếp lắng nghe kênh Slack nội bộ. Chúng tôi dựa rất nhiều vào phản hồi từ người dùng nội bộ và người dùng cấp cao vì nhân viên nội bộ thực sự sẵn lòng trung thực với bạn; họ có xu hướng khai thác tối đa các tính năng và dễ dàng được theo dõi nhất.
Peter Yang: Tôi nghĩ đây là cách mọi việc nên diễn ra, và tôi cảm thấy đội ngũ trong hầu hết các công ty đều quá thiếu sự kết nối, nhưng Anthropic thì hoàn toàn không như vậy.
Jenny:
Tôi nghĩ đây cũng là một phần quan trọng trong thành công của Claude Code—lắng nghe người dùng trực tiếp. Và đây là điều chúng tôi đã làm lượng lớn ở Figma, lượng lớn hoạt động tự trải nghiệm nội bộ. Bởi vì đặc biệt khi nói đến thiết kế tương tác và tinh chỉnh, nhân viên nội bộ thực sự xem xét kỹ lưỡng các chi tiết, trong khi người dùng bên ngoài thường cung cấp phản hồi về việc liệu nó có phù hợp với quy trình sử dụng của họ hay không. Vì vậy, nó cung cấp một mức độ phản hồi hoàn toàn khác.
Ranh giới người dùng giữa không gian làm việc chung và Claude Code
Peter Yang: Tôi biết rằng các quản lý tiếp thị và sản phẩm của Anthropic hiện đang sử dụng phần lớn Claude Code, đặc biệt là sau khi nó được cung cấp nội bộ tại Cowork. Anh/chị ứng xử các trường hợp sử dụng khác nhau? Hay mọi người sử dụng Cowork và Claude Code như thế nào?
Jenny:
Chúng tôi nhận thấy phạm vi ứng dụng tổng thể của Cowork đang dần mở rộng và bắt đầu được sử dụng trong các tình huống tương tự như những gì mà những người dùng đầu tiên của Claude Code đã khám phá trước đây. Tôi nhớ khi chúng tôi bắt đầu phát triển Cowork, đội ngũ bán hàng nội bộ là nguồn thông tin chính của chúng tôi. Một số người trong số họ là những người sử dụng Claude Code độ sâu, dùng nó để tạo danh sách khách hàng tiềm năng, viết kịch bản gọi điện, v.v. Khi lần thấy những trường hợp sử dụng này, tôi khá ngạc nhiên vì tôi thậm chí chưa từng tưởng tượng rằng Claude Code có thể được sử dụng để thực hiện nhiệm vụ này. Giờ đây, hầu hết những người dùng này đã chuyển sang sử dụng Cowork, và thậm chí cả các đồng nghiệp của họ cũng bắt đầu sử dụng nó thường xuyên.
Lý do tôi cho rằng nó thực sự cần thiết là vì giao diện người dùng của nó rất đẹp. Và một phần lý do nữa là nó rất gần với những công việc khác mà họ đang làm—họ đã sử dụng chức năng trò chuyện rồi, và họ có thể tiếp tục sử dụng Claude Code từ ứng dụng máy tính để bàn này, vì vậy tôi nghĩ nó phù hợp với quy trình làm việc hiện tại của họ hơn là mở dòng lệnh.
Toàn bộ quy trình từ ý tưởng đến sản phẩm có thể thực thi được
Jenny:
Có bảy chủ đề khác nhau, và mỗi tuần một chủ đề khác nhau. Về cơ bản, tôi chỉ cần nói: "Hãy tạo tài liệu X này cho tôi," và nó sẽ tự động được lưu vào một thư mục trên máy tính của tôi. Tôi cũng có thể bắt đầu hai nhiệm vụ song song cùng một lúc. Ví dụ, tôi có thể nói: "Những thông tin chi tiết này rất tuyệt, nhưng dựa trên chúng, tôi nên xây dựng những tính năng sản phẩm nào?" Sau đó, tôi có thể làm một việc khác song song—dựa trên tài liệu thông tin chi tiết mà bạn vừa tạo cho tôi, biến nó thành một bài thuyết trình mà tôi có thể chia sẻ với đội ngũ tại buổi họp khởi động tuần này.
Nhưng cuối cùng, tôi có thể bắt đầu quá trình thiết kế từ đây — nó cung cấp cho tôi nhiều tùy chọn chức năng khác nhau. Từ đó, tôi thậm chí có thể nhờ Claude tạo một số bản phác thảo giao diện cho các chức năng này. Nó có thể cung cấp cho tôi rất nhiều tùy chọn khác nhau, mà tôi có thể chuyển sang Figma để tinh chỉnh, hoặc sang Claude Code để biến chúng thành sản phẩm thực tế với các thành phần hệ thống thiết kế thực tế của chúng tôi, và sau đó bắt đầu từ đó.
Một việc khác tôi có thể làm là biến cả hai việc này thành nhiệm vụ theo lịch trình. Vì vậy, tôi có thể sẽ lên lịch cho nhiệm vụ này chạy tự động vào mỗi sáng thứ Hai lúc 10 giờ. Bằng cách đó, tôi sẽ bắt đầu làm việc mỗi sáng thứ Hai lúc 10 giờ với bài thuyết trình này và ba hoặc bốn ý tưởng sản phẩm khác nhau để khởi đầu tuần. Điều này giúp rút ngắn chu kỳ lặp lại từ phản hồi đến việc tạo ra một sản phẩm hữu hình hoặc một ý tưởng mà đội ngũ có thể thấy một cách nhanh chóng, giúp chúng ta cải tiến sản phẩm nhanh hơn và làm cho nó tốt hơn rất nhanh.
Peter Yang: Mọi thứ đều xoay quanh việc lặp đi lặp lại. Giờ tôi đã trở nên lười biếng; tôi luôn để AI làm phiên bản đầu tiên, rồi sau đó tôi mới phản hồi.
Jenny:
Đúng vậy. Vì vậy, nếu bạn thực sự muốn tôi sắp xếp những hiểu biết này theo một thứ tự ưu tiên chức năng nào đó từ đầu, thì bây giờ sẽ mất nhiều thời gian hơn trước.
Đó chính xác là cách tôi làm. Ví dụ, với ghi chú podcast mà bạn gửi cho tôi, tôi có một thư mục ghi chú cá nhân chứa nội dung cuộc họp 1:1, những suy nghĩ ngẫu nhiên, v.v. Sau đó, tôi chỉ đơn giản nói: "Hãy đọc ghi chú cá nhân của tôi, giúp tôi nghĩ ra những điểm chính cho podcast này, và giúp tôi nghĩ ra những gì tôi muốn nói ở đây." Tất nhiên, tôi sẽ không đọc từng chữ một, nhưng nó thực sự giúp tôi mở rộng tư duy và giúp tôi phát triển quá trình suy nghĩ của mình, thay vì bị bế tắc.
Kỹ năng và kiến thức cá nhân
Peter Yang: Bạn sử dụng những kỹ năng gì? Hay bạn có kỹ năng cá nhân nào để tạo ra những tài liệu và slide này?
Jenny:
Chúng tôi có một số kỹ năng nội bộ chuyên biệt để tạo tài liệu và bài thuyết trình, vì điều này giúp chúng tôi duy trì tính nhất quán thương hiệu. Thực tế thì tôi không có thư viện kỹ năng cá nhân; hầu hết thời gian tôi mượn các kỹ năng nội bộ hiện có và sử dụng chúng cho các mục đích khác nhau.
Peter Yang: Ví dụ, tôi có một kỹ năng viết hướng dẫn AI không sử dụng những từ ngữ cẩu thả do AI tạo ra.
Jenny:
Nhưng tôi nhận thấy rằng việc sử dụng các thư mục của Cowork—nơi tôi lưu trữ tất cả các ghi chú cá nhân và những thứ tương tự—để hiểu về tôi đã vô cùng hữu ích. Thực tế, tôi cảm thấy ngày càng ít cần đến bộ nhớ và kỹ năng, vì nó đã có sẵn một cơ sở dữ liệu về tôi. Tất nhiên, tôi vẫn cho rằng kỹ năng vẫn có vai trò của nó, nhưng với trường hợp sử dụng hiện tại của tôi, cá nhân tôi cảm thấy nhu cầu đó không còn mạnh mẽ như trước nữa.
Peter Yang: Có phải vì nó tự động cập nhật bộ nhớ dựa trên các cuộc trò chuyện hàng ngày của bạn không?
Jenny:
Đúng vậy, về cơ bản đó là một dạng ký ức mà tôi tự lưu giữ vì tôi luôn ghi chép vào đó.
Nút cộng tác đội ngũ
Peter Yang: Vậy khi nào anh đưa đội ngũ vào cuộc trong toàn bộ quá trình? Hay anh luân phiên giữa việc làm việc với AI và làm việc với đội ngũ, hay anh làm theo cách nào?
Jenny:
Ý tôi là, những việc như phỏng vấn UXR thực tế là những việc tôi sẽ không tự mình làm—đó sẽ là việc của quản lý sản phẩm, một nhà nghiên cứu trong đội ngũ, hoặc ai đó khác trong đội ngũ. Sau đó, thông qua việc này, bạn trực tiếp chia sẻ các tài liệu, đưa chúng vào, và điều đó thực sự trở thành nền tảng cho hoạt động của đội ngũ.
Đội ngũ của chúng tôi hoạt động theo mô hình từ dưới lên và rất dân chủ, vì vậy cách chúng tôi làm việc là chia sẻ những hiểu biết và mục tiêu với mọi người, sau đó mọi người cùng nhau tạo mẫu thử nghiệm và kiểm tra mọi thứ, với các ý tưởng đến từ mọi hướng. Không phải là tôi, với tư cách là nhà thiết kế, phải đưa ra tất cả các giải pháp; mà giống như, "Này, đây là một vài hiểu biết. Đây là những gì chúng ta cần đạt được trong tháng này, làm thế nào chúng ta có thể cùng nhau làm việc để đạt được điều đó?"
Dù vậy, tôi không nghĩ chúng ta sẽ đơn giản giao phó mọi việc cho Claude. Chúng ta vẫn sẽ phải tự mình đưa ra nhiều phán đoán , quản lý và quyết định nên xây dựng cái gì và làm gì.
Peter Yang: Khi mọi người bàn luận về gu thẩm mỹ và khả năng đánh giá trên mạng, tôi nghĩ phương pháp để trau dồi những khả năng này thực chất là thông qua việc liên tục thu thập lượng lớn phản hồi về sản phẩm từ cả nguồn nội bộ và bên ngoài. Trong quá trình này, bạn dần dần phát triển trực giác cho phép bạn phát hiện ra những điểm sai sót và cần khắc phục. Bởi vì bạn lắng nghe và xử lý những phản hồi này mỗi ngày, theo thời gian bạn sẽ phát triển được khả năng đánh giá sắc bén về các vấn đề.
Jenny:
Về thiết kế, một trong những tính năng của Claude là khả năng tạo ra các bản phác thảo dạng khung sườn và cung cấp nhiều tùy chọn thiết kế. Là một nhà thiết kế, tôi thực sự đánh giá cao cách tiếp cận này. Mặc dù các bản phác thảo này không quá chi tiết, nhưng chúng cho phép tôi hình dung trực quan các khả năng khác nhau mà không cần hoàn toàn dựa vào trí tưởng tượng của mình. Điều này giúp tôi quyết định hướng thiết kế tiếp theo nhanh hơn.
Do đó, tôi cho rằng việc để Claude trực tiếp tạo ra các phương án ban đầu này có thể giúp tôi tiết kiệm thời gian và công sức tạo ra thảo thủ công. Từ những phương án này, tôi sẽ chọn một hướng và bắt đầu các bước lặp nhỏ. Tiếp theo, tôi có thể sử dụng mã lập trình để tạo ra một nguyên mẫu sơ bộ theo hướng này, và sau đó tiếp tục tối ưu hóa và hoàn thiện thiết kế dựa trên đó.
Câu chuyện có thật về sự ra đời của Cowork
Peter Yang: Chúng ta hãy cùng nói về quá trình hình thành của Cowork. Có rất nhiều câu chuyện kể rằng nó được xây dựng chỉ trong 10 ngày, nhưng chắc hẳn đã có rất nhiều phiên bản chỉnh sửa trước đó, đúng không?
Jenny:
Câu nói "họ hoàn thành nó trong 10 ngày" thực chất bắt nguồn từ lần cuộc phỏng vấn hoặc bản tin truyền thông, và cuộc thảo luận đã xoay quanh điểm này kể từ đó. Tuy nhiên, sự thật là chúng tôi đã bắt đầu hình thành ý tưởng về mô hình Cowork từ một năm trước khi tôi gia nhập Anthropic. Chúng tôi đã suy nghĩ về cách tạo ra một "đối tác tư duy" có thể hỗ trợ tất cả những người lao động tri thức nói chung. Mặc dù Claude Code đã xử lý khá tốt nhiệm vụ liên quan đến lập trình, mục tiêu của chúng tôi là bao quát tất cả các kịch bản công việc tri thức. Tôi nghĩ thách thức thực sự nằm ở chỗ: làm thế nào để thực hiện ý tưởng này? Kiến trúc nào là phù hợp nhất? Loại trải nghiệm người dùng (UX) nào là đúng đắn?
Trong năm qua, chúng tôi đã thử nghiệm nhiều thiết kế nguyên mẫu khác nhau, một trong đó thậm chí còn tham vọng hơn cả mục tiêu hiện tại của chúng tôi. Chúng tôi cũng đã tiến hành nhiều thử nghiệm kỹ thuật, kiểm tra các khung phần mềm tác nhân AI khác nhau, nhưng một số nỗ lực trong đó đã không thành công. Cuối cùng, chúng tôi dần dần đi theo hướng hiện tại. Chúng tôi tham khảo không chỉ các nguyên mẫu do đội ngũ nghiên cứu phát triển mà còn cả những nguyên mẫu do đội ngũ sản phẩm xây dựng. Cuối cùng, thời điểm và khả năng thực hiện trở nên vô cùng quan trọng, giống như tia sét đánh trúng mục tiêu một cách chính xác.
Khi chúng tôi quyết định phát hành sản phẩm này, toàn bộ quá trình diễn ra cực kỳ nhanh chóng—từ lúc "chúng ta nên phát hành nó" đến lúc "sản phẩm ra mắt" chỉ mất 10 ngày. Điều này chủ yếu là vì chúng tôi đã nhận thấy tiềm năng của nó trong kỳ nghỉ lễ Claude Code. Trong kỳ nghỉ lễ, nhiều người cuối cùng đã có thời gian để dùng thử Claude Code, và thậm chí một số người dùng không chuyên về kỹ thuật cũng bắt đầu sử dụng nó, chẳng hạn như phân tích bản ghi podcast hoặc thực hiện phân tích dữ liệu phức tạp. Chúng tôi nhận thấy rằng khung tác nhân của Claude Code cũng bắt đầu cho thấy sự phù hợp sớm giữa sản phẩm và thị trường đối với người dùng không chuyên về kỹ thuật. Trên thực tế, chúng tôi đã có một nguyên mẫu hoạt động nội bộ, và ban đầu chúng tôi dự định phát hành nó muộn hơn một chút, nhưng phản hồi này đã khiến chúng tôi nhận ra rằng "bây giờ là thời điểm tốt nhất". Vì vậy, chúng tôi quyết định nắm bắt cơ hội, dẫn đến 10 ngày điên cuồng đó.
Peter Yang: Nếu tôi hiểu đúng, trong năm qua, anh đã chia sẻ nhiều bản mẫu trên Slack nội bộ, thu thập lượng lớn phản hồi và cuối cùng đã xác định được một bản mẫu khả thi. Sau đó, nhận thấy nhu cầu thị trường, anh đã nhanh chóng triển khai sản phẩm.
Jenny:
Vâng, đại khái là như vậy. Ban đầu chúng tôi dự định ra mắt vài tuần sau đó, nhưng lúc đó chúng tôi cảm thấy "bây giờ là thời điểm tốt nhất". Điều này cũng thúc đẩy chúng tôi thu hẹp phạm vi sản phẩm xuống mức thực tế và khả thi hơn trong điều kiện thời gian eo hẹp, và dồn toàn bộ năng lượng và nguồn lực vào đó, cuối cùng đã ra mắt thành công.
Các giai đoạn thiết kế ban đầu: Từ công cụ quản lý quy trình làm việc đến ứng dụng trò chuyện tối giản
Peter Yang: Anh có thể chia sẻ một vài kinh nghiệm về các phiên bản ban đầu, hoặc cho xem một số thứ đang được phát triển không?
Jenny:
Tất nhiên rồi! Tôi đã tổng hợp một số ảnh chụp màn hình ban đầu để minh họa tư duy thiết kế và quy trình lặp lại của chúng tôi vào thời điểm đó.
Đầu năm nay, chúng tôi đã có một bản mẫu thử nghiệm ban đầu, do tôi và một nhà thiết kế khác cùng thực hiện. Vào thời điểm đó, chúng tôi cố gắng làm cho công cụ này hướng đến nhiệm vụ hoặc quy trình làm việc hơn. Chúng tôi lo ngại liệu người dùng có hiểu được việc sử dụng một sản phẩm như Cowork có cho phép họ hoàn thành nhiệm vụ cụ thể hoặc đạt được các kết quả nhất định hay không, chẳng hạn như tạo bảng điều khiển hoặc tích hợp dữ liệu từ các nguồn khác nhau. Do đó, chúng tôi đã thiết kế giao diện người dùng rất có cấu trúc, gần giống như một công cụ quy trình làm việc — ví dụ: "Thêm nội dung này, đây là đầu vào, đây là đầu ra." Chức năng trò chuyện được xếp vào vai trò lần.
Nhưng có vẻ như có quá nhiều bước liên quan. Năm 2025 rồi, tại sao lại làm cho mọi thứ phức tạp đến vậy? Sao không để Claude lo liệu luôn?
Đây là một trong những hướng thiết kế ban đầu của chúng tôi, nhưng sau đó chúng tôi quyết định thay đổi cách tiếp cận và làm cho nó đơn giản hơn, giống như một hộp thoại trò chuyện . Chúng tôi đã cố gắng hướng dẫn người dùng đạt được các mục tiêu cụ thể hơn theo cách này, chẳng hạn như phân tích hoặc tạo tài liệu. Chúng tôi cũng đã thiết kế một nguyên mẫu chức năng—sau khi người dùng nhấn, họ sẽ thấy nhiều tùy chọn khác nhau, mỗi tùy chọn đều có các nút để điều chỉnh, chẳng hạn như độ dài tài liệu, hoặc chọn loại tài liệu, chẳng hạn như bản ghi nhớ hoặc bài thuyết trình, nhưng thiết kế này cuối cùng lại quá phức tạp và khó sử dụng đối với người dùng.
Vì vậy, thông qua lần lần tìm tòi và thử nghiệm, chúng tôi đã cố gắng tìm ra sự cân bằng: liệu chúng ta nên xác định rõ hơn các trường hợp sử dụng, hay nên duy trì hình thức tự do như một hộp trò chuyện?
Tóm lại, phiên bản mà chúng tôi phát hành vài tuần trước trông như thế này. Chúng tôi đã thử nghiệm trải nghiệm người dùng gần giống như một "trình hướng dẫn", trong đó người dùng sẽ thấy các lời nhắc sau khi nhấn, chẳng hạn như "Tạo tài liệu, dài từ ba đến năm trang", v.v.
Ban đầu, chúng tôi đã thêm rất nhiều yếu tố vào giao diện, với hy vọng làm cho nó trông khác biệt so với hộp chat thông thường. Tuy nhiên, sau đó chúng tôi nhận thấy thiết kế này làm cho giao diện trở nên quá phức tạp, với quá nhiều yếu tố trực quan cạnh tranh nhau. Vì vậy, chúng tôi quyết định đơn giản hóa thiết kế và loại bỏ hầu hết các yếu tố không cần thiết.
Giao diện người dùng mà bạn thấy hiện tại đã được đơn giản hóa rất nhiều. Chúng tôi đã loại bỏ các thanh bên cồng kềnh, làm cho nó gần giống với một hộp trò chuyện truyền thống hơn, nhưng chúng tôi đã thực hiện một số thay đổi đối với trang chủ để làm cho nó trông giống như một "danh sách việc cần làm" được chia sẻ giữa Claude và tôi, thay vì một công cụ trò chuyện đầy những gợi ý và hướng dẫn phức tạp.
Peter Yang: Có lẽ trong tương lai nó có thể hỗ trợ nhiều tác nhân, cho phép người dùng kéo và thả nhiệm vụ để quản lý quy trình làm việc.
Jenny:
Có lẽ khả năng đó sẽ tồn tại trong tương lai. Nhưng tôi muốn nhấn mạnh rằng thiết kế giao diện người dùng hoàn toàn khác so với khoảng bốn hoặc năm tuần trước. Chúng tôi liên tục học hỏi và khám phá xem loại thiết kế nào hoạt động tốt nhất và loại thiết kế nào không hiệu quả, đồng thời nỗ lực tìm ra cách tốt nhất để giới thiệu công nghệ này đến người dùng.
Sự khác biệt giữa Cowork và Claude Code
Peter Yang: Khi sử dụng Claude Code, tôi thường chia sẻ phản hồi trên Twitter. Nó có rất nhiều lệnh gạch chéo tích hợp sẵn, người dùng cần học dần dần. Trải nghiệm này hơi giống như một cuộc "săn tìm kho báu" khi mua sắm ở Costco; bạn không bao giờ biết mình sẽ khám phá ra những tính năng mới nào.
Tuy nhiên, cách tiếp cận này không thân thiện lắm với người mới bắt đầu. Nó giống như một trò chơi; bạn sẽ dần làm quen và thành thạo nó khi sử dụng nhiều hơn. Tôi cảm thấy Cowork có thể đang cố gắng tìm ra điểm cân bằng giữa các công cụ trò chuyện thông thường và Claude Code. Nó không che giấu tất cả các tính năng, nhưng lại hướng dẫn người dùng theo một cách nào đó để sử dụng tốt hơn.
Jenny:
Đúng vậy. Cowork vẫn hỗ trợ các lệnh gạch chéo, nhưng chúng không phải là phương thức tương tác chính. Cá nhân tôi nghĩ Cowork ít nhất là một công cụ hướng đến các chuyên gia. Chúng tôi nhận thấy nhiều người dùng đã sử dụng nó ở mức độ rất cao, và một số người dùng cao cấp đã xuất hiện trong cộng đồng. Những người dùng này thường sẵn sàng dành thời gian để học các tính năng phức tạp hơn, chẳng hạn như tạo kỹ năng của riêng họ, chia sẻ chúng với đội ngũ hoặc sử dụng các lệnh viết tắt.
Tuy nhiên, mục tiêu của chúng tôi là biến những tính năng này thành các phương thức tương tác lần, chứ không phải là nội dung học tập bắt buộc. Nói cách khác , ngay cả khi người dùng không hiểu hết tất cả các lệnh, họ vẫn có thể dễ dàng sử dụng Cowork. Chúng tôi muốn sự tương tác của người dùng với Claude diễn ra tự nhiên và trực quan, thay vì yêu cầu họ phải ghi nhớ sê-ri các lệnh để hoàn thành các thao tác.
Quy trình lập kế hoạch và viễn cảnh mong đợi
Peter Yang: Quy trình lập kế hoạch của Anthropic như thế nào? Các bạn có tiến hành lập kế hoạch và đặt mục tiêu hàng năm không? Hay các bạn dựa nhiều hơn vào việc tạo mẫu thử nghiệm và thử nghiệm liên tục?
Jenny:
Cách lập kế hoạch của chúng tôi thay đổi lần. Trong đội ngũ của tôi, chúng tôi lập kế hoạch hàng tháng. Chúng tôi có một bảng tính với ít nhất một phần Cowork liệt kê khoảng 12 nhiệm vụ, là những nhiệm vụ ưu tiên cao nhất (P0). Mỗi nhiệm vụ đều có một người chịu trách nhiệm trực tiếp (DRI), và chúng tôi kiểm tra hàng tuần để xem liệu chúng tôi có còn đi đúng hướng hay không. Chúng tôi cũng lập kế hoạch hàng quý hoặc nửa năm, thường với một người chịu trách nhiệm chỉ ra: "Tôi cho rằng chúng ta nên đi theo hướng này, và đây là những điều chúng ta cần tập trung vào." Nhưng những kế hoạch này không quá cứng nhắc đến mức phải thực hiện các dự án cụ thể. Chúng chủ yếu là cung cấp định hướng tổng thể cho đội ngũ, vì vậy chúng tương đối linh hoạt.
Peter Yang: Khá linh hoạt, phải không? Điều thú vị là, tôi nhận thấy rằng các công ty sáng tạo nhất thường ít lập kế hoạch hàng năm hơn và tập trung nhiều hơn vào công việc lặp đi lặp lại và học hỏi từ người dùng. Anh/chị đã từng làm điều gì tương tự như bộ công cụ viễn cảnh mong đợi North Star trong sự nghiệp của mình chưa? Anh/chị thấy chúng có hữu ích không?
Jenny:
Tôi đã làm điều đó; tôi đã tạo ra một bộ tài liệu định hướng viễn cảnh mong đợi " Ngôi sao Bắc cực" vào năm ngoái. Tôi cho rằng viễn cảnh mong đợi có giá trị của nó; chúng hướng dẫn đội ngũ và giúp chúng ta giữ vững tinh thần trong công việc sắp tới. Tuy nhiên, vì lĩnh vực công nghệ mà chúng ta đang hoạt động thay đổi rất nhanh chóng, với các mô hình mới liên tục xuất hiện và được cập nhật với tốc độ ngày càng tăng, nên việc phát triển viễn cảnh mong đợi một năm là không thực tế, chứ chưa nói đến viễn cảnh mong đợi hai đến năm năm, do số lượng những điều chưa biết là quá lớn.
Tuy nhiên, sức mạnh thực sự của viễn cảnh mong đợi nằm ở việc hướng dẫn mọi người cùng đi theo một mục tiêu, đặc biệt là trong hoàn cảnh mà mọi người đều được tự do xây dựng các dự án khác nhau. Do đó, tôi cho rằng rằng viễn cảnh mong đợi nên có thời hạn tối đa từ ba đến sáu tháng và được trình bày dưới dạng văn bản. Tôi cảm thấy viễn cảnh mong đợi sẽ có tác động mạnh mẽ hơn khi được trực quan hóa. Đây cũng là nơi giá trị to lớn của thiết kế nằm ở khả năng tích hợp các yếu tố khác nhau và kể một câu chuyện mạch lạc trong một khoảng thời gian cụ thể. Tất nhiên, viễn cảnh mong đợi cũng có thể là một nguyên mẫu, chứ không chỉ là một bản trình bày tĩnh. Nó có thể giúp chúng ta phối hợp công việc giữa đội ngũ, đặc biệt khi chúng ta có năm đội ngũ đang làm việc trên các dự án rất giống nhau hoặc có khả năng xung đột. Thiết kế có thể giúp các ý tưởng này được sắp xếp hợp lý thông qua việc chọn lọc và chỉ cho chúng ta con đường dẫn đến trải nghiệm người dùng lý tưởng, thay vì trải nghiệm rời rạc.
Peter Yang: Vậy, các bạn có đánh giá hiệu suất của quản lý sản phẩm, hay đánh giá hiệu suất của các nhân viên liên quan không? Những đánh giá này có mang tính hình thức hay họ cũng tham gia vào quá trình tạo mẫu thử nghiệm?
Jenny:
Chúng tôi có quy trình đánh giá, nhưng không giống như một số công ty tôi từng làm việc, nơi mọi tính năng đều cần được đánh giá, các đánh giá của chúng tôi chủ yếu dành cho các dự án lớn hơn, có mức độ ưu tiên cao hơn. Mục đích của các đánh giá này không phải là để lượng lớn thời gian chuẩn bị, mà là để tăng tính minh bạch của dự án và thu thập phản hồi. Chúng tôi tiến hành các đánh giá này cho các dự án quan trọng trên toàn công ty, liên quan đến nhiều đội ngũ.
Lời khuyên dành cho các nhà thiết kế: Làm thế nào để tìm được chỗ đứng trong kỷ nguyên AI
Peter Yang: Vậy, anh có lời khuyên nào dành cho những nhà thiết kế cảm thấy hoàn cảnh làm việc của họ đang thay đổi nhanh chóng? Họ có nên bắt đầu học cách gửi yêu cầu kéo mã (pull request - PR) không? Hay các nhà thiết kế nên áp dụng những cách tiếp cận khác để thích nghi?
Jenny:
Nếu bạn cảm thấy mặt đất dưới chân mình đang rung chuyển, đó là vì nó thực sự đang thay đổi. Chúng ta phải thừa nhận điều này và học cách thích nghi, đồng thời xem xét lại những cách làm việc hiện tại của mình với một tư duy cởi mở. Tôi nghĩ những thay đổi này đặc biệt có tác động lớn đến các nhà thiết kế, nhất là khi chúng ta đang ở trong làn sóng chuyển đổi thứ hai. Nhân vật chuyên nghiệp khác đã trải qua những quá trình chuyển đổi tương tự, và giờ đến lượt chúng ta. Trong khi đó, các công cụ thiết kế của chúng ta cũng không ngừng phát triển.
Mỗi khi cảm thấy sự nghiệp của mình gặp thách thức, tôi lại thấy một nỗi bất an khó tả, kiểu như: "Trời ơi, công việc của mình thay đổi nhiều quá, có lẽ mọi người sẽ không còn coi trọng nó như trước nữa." Nhưng những lúc như vậy, tôi lại nghĩ đến các đồng nghiệp kỹ sư của mình. Công việc của họ đã trải qua những thay đổi to lớn, nhưng họ không chỉ thích nghi với những thay đổi đó mà còn đón nhận thử thách với lòng dũng cảm và sự khiêm tốn tuyệt vời, cuối cùng đạt được kết quả hiệu quả và xuất sắc hơn. Họ là nguồn cảm hứng của tôi – tôi tự nhủ rằng nếu những đồng nghiệp mà tôi vô cùng kính trọng có thể làm được, thì tôi cũng có thể. Họ là hình mẫu của tôi về khả năng thích ứng với sự thay đổi.
Peter Yang: Ở một mức độ nào đó, những thay đổi này đã giải phóng các nhà thiết kế khỏi rất nhiều công việc lặp đi lặp lại tẻ nhạt, chẳng hạn như không phải dành thời gian điều chỉnh các khung phần mềm khác nhau, đúng không? Điều này cho phép bạn dành nhiều năng lượng hơn cho tư duy cấp cao và công việc sáng tạo.
Jenny:
Đúng vậy, hay nói đúng hơn, những thay đổi này đã giúp chúng ta hoàn thành được nhiều việc hơn. Ví dụ, tôi thực sự ấn tượng khi thấy các đồng nghiệp kỹ sư của mình giờ đây có thể hoàn thành một tính năng đầy đủ chỉ trong vài ngày, trong khi trước đây phải mất đến vài tuần. Vì vậy, đúng là sự thay đổi này cũng mang lại nhiều khả năng hơn.
