“Đầu vào là rác, đầu ra là báu vật”: Nhà thiết kế trưởng của Anthropic nói về triết lý sản phẩm Cowork và sự thật đằng sau việc ra mắt trong vòng 10 ngày
Tuyển chọn TechFlowTuyển chọn TechFlow
“Đầu vào là rác, đầu ra là báu vật”: Nhà thiết kế trưởng của Anthropic nói về triết lý sản phẩm Cowork và sự thật đằng sau việc ra mắt trong vòng 10 ngày
Mặc dù Claude Code đã có thể xử lý rất tốt các tác vụ liên quan đến mã nguồn, nhưng mục tiêu của chúng tôi là bao phủ toàn bộ các tình huống công việc tri thức.
Chuyên sâu báo cáo Web3Tổng hợp & Dịch thuật: TechFlow
Khách mời: Jenny Wen, Trưởng bộ phận Thiết kế của Cowork
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 bộ phận Thiết kế của Cowork (40 phút) | Jenny Wen
Ngày phát hành: 29 tháng 3 năm 2026
Tóm tắt các điểm chính
Jenny là Trưởng bộ phận Thiết kế của Cowork. Bà đã dẫn dắt tôi đi sâu vào cách vận hành nội bộ của Anthropic, bao gồm cách bà 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 gần như tung ra tính năng mới mỗi ngày — việc quan sát cách họ làm việc khiến tôi vô cùng kinh ngạc.
Tóm tắt những quan điểm nổi bật
Về cách làm việc hàng ngày
- Hầu hết thời gian tôi dành ra là để đưa sản phẩm ra thị trường. Tuy nhiên, tôi cảm thấy điều này có thể khác biệt so với một hoặc hai năm trước — một phần lớn công việc hiện nay chính là hợp tác linh hoạt (jam) với các kỹ sư, nhân viên sản phẩm và những người khác theo cách khá phi chính thức. Thông thường, chúng tôi cùng xem một bản mẫu (prototype), sau đó chỉ ra và suy ngẫm về cách nó có thể phát triển tiếp.
Về triết lý sử dụng “đầu vào rác rưởi – đầu ra quý giá”
- Điều khiến tôi ấn tượng nhất ở Cowork chính là khả năng tổ chức thông tin của nó. Tôi thích gọi đây là nguyên tắc “đầu vào rác rưởi – đầu ra quý giá”. Nó có thể thu thập thông tin từ nhiều nguồn khác nhau, nhanh chóng xác định các điểm mấu chốt, chắt lọc nội dung có giá trị và chuyển hóa thành những kết quả thực tiễn, mang lại hiệu suất cao.
Về sự khác biệt giữa Cowork và Claude Code
- Ngoại trừ các công việc lập trình chi tiết cho môi trường sản xuất (production code), hiện nay tôi sử dụng Cowork cho gần như mọi việc. Trong những tình huống yêu cầu tập trung vào các chi tiết mã cụ thể, tôi vẫn dùng Claude Code. Nhưng đối với giao tiếp và cộng tác hằng ngày, tôi hoàn toàn phụ thuộc vào Cowork.
Về câu chuyện ra đời của Cowork
- Câu nói “họ chỉ mất 10 ngày để xây dựng xong” thực chất được trích ra từ một cuộc phỏng vấn hoặc bài báo truyền thông nào đó. Còn thực tế thì hướng phát triển Cowork đã bắt đầu được chúng tôi lên ý tưởng ngay từ khi tôi gia nhập Anthropic cách đây một năm — chúng tôi liên tục suy ngẫm về cách tạo ra một “người bạn đồng hành tư duy” (thinking partner) hỗ trợ tất cả những người lao động tri thức phổ quát.
- Mặc dù Claude Code đã xử lý rất tốt các tác vụ liên quan đến mã nguồn, mục tiêu của chúng tôi là bao phủ toàn bộ các tình huống công việc tri thức. Theo tôi, thách thức thực sự nằm ở chỗ: Làm thế nào để hiện thực hóa ý 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?
Về sự tiến hóa của quy trình thiết kế
- Tôi vẫn sử dụng Figma. Nhưng hiện nay chúng tôi ít khi viết tài liệu đặc tả (spec document), và nếu có thì cũng thường không quá chi tiết. Chúng tôi vẫn thực hiện việc xếp hạng ưu tiên — tài liệu này vẫn tồn tại, nhưng thường chỉ gồm vài gạch đầu dòng, chứ không phải những bảng biểu được thiết kế cầu kỳ, quá mức.
Về lập kế hoạch và tầm nhìn
- Lĩnh vực công nghệ mà chúng ta đang hoạt động thay đổi cực kỳ nhanh chóng, các mô hình mới liên tục xuất hiện và tốc độ cập nhật ngày càng tăng. Vì vậy, đối với chúng tôi, việc xây dựng một tầm nhìn dài một năm đã là điều không thực tế, chứ chưa nói tới tầm nhìn hai đến năm năm — bởi vì còn quá nhiều yếu tố chưa biết.
Về tương lai của nhà thiết kế
- Nếu bạn cảm thấy mặt đất dưới chân mình đang chuyển dịch, thì đó là vì nó thực sự đang thay đổi. Chúng ta buộc phải thừa nhận điều này, học cách thích nghi, đồng thời cũng cần cởi mở để xem xét lại cách làm việc hiện tại của mình.
- Mỗi khi tôi cảm thấy nghề nghiệp của mình bị thử thách, tôi đều cảm thấy lo lắng — ví dụ như “Trời ơi, công việc của tôi đang thay đổi mạnh mẽ, người ta có thể sẽ không còn đánh giá cao vai trò của tôi như trước nữa.” Nhưng trong những khoảnh khắ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 biến đổi khổng lồ từ lâu, nhưng họ không chỉ thích nghi với những thay đổi ấy, mà còn đón nhận thử thách với lòng can đảm và khiêm tốn tuyệt vời, cuối cùng đạt được hiệu suất và chất lượng công việc cao hơn 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 tôi rất kính trọng có thể làm được, thì chắc chắn tôi cũng sẽ làm được. Họ là tấm gương giúp tôi thích nghi với sự thay đổi.
Mở đầu
Peter Yang: Xin chào mọi người! Hôm nay tôi vô cùng hào hứng được chào đón Jenny — Trưởng bộ phận Thiết kế của Anthropic. Jenny sẽ trình bày cách bà sử dụng Claude Cowork và Claude Code để thiết kế và phát hành sản phẩm, đồng thời chia sẻ những câu chuyện nội bộ về Cowork, và có thể cả những bước phát triển tiếp theo của sản phẩm.
Jenny, một ngày điển hình trong công việc của bạn thường diễn ra như thế nào? Những nhiệm vụ nào chiếm phần lớn thời gian của bạn?
Jenny:
Tôi không chắc có tồn tại khái niệm “một ngày điển hình” hay không, nhưng phần lớn thời gian tôi dành ra là để đưa sản phẩm ra thị trường. Tuy nhiên, tôi cảm thấy điều này có thể khác biệt so với một hoặc hai năm trước — một phần lớn công việc hiện nay chính là hợp tác linh hoạt (jam) với các kỹ sư, nhân viên sản phẩm và những người khác theo cách khá phi chính thức. Thông thường, chúng tôi cùng xem một bản mẫu (prototype), sau đó chỉ ra và suy ngẫm về cách nó có thể phát triển tiếp. Đôi khi chúng tôi chỉ thảo luận về cách thể hiện chức năng; đôi khi chính tôi tự thực hiện một số việc. Tôi nghĩ vẫn còn khá nhiều thời gian dành cho việc thiết kế, tạo prototype… nhưng hiện nay cách làm thiết kế lại cảm giác rất thoáng và linh hoạt.
Peter Yang: Nói chung là bạn dùng Claude để tạo ra hàng loạt prototype, rồi cùng các kỹ sư jam, đưa ra phản hồi và dùng prompt để yêu cầu AI cải tiến chúng, đúng không?
Jenny:
Thực tế thì chúng thậm chí còn chưa phải prototype — mà là những bản mẫu đang chạy thực tế bên trong hệ thống nội bộ của chúng tôi hoặc trên các phiên bản Claude/Cowork. Tôi thường dành thời gian sử dụng tính năng này, đẩy mạnh tính năng này, kiểm tra khả năng của nó và hình thành quan điểm cá nhân; bước lặp tiếp theo thường là tôi ngồi xuống cùng kỹ sư và nói: “Này, đây là suy nghĩ của tôi. Đây là những điểm tôi cho rằng nên thay đổi.” Tôi vẫn thấy rằng việc lặp lại, mài giũa và hoàn thiện trong các công cụ thiết kế vẫn cực kỳ quan trọng. Vì vậy, phần việc này vẫn chưa biến mất — chỉ là do tôi đang xử lý nhiều dự án cùng lúc nên cảm thấy cách làm việc thoải mái, phi chính thức hơn sẽ hiệu quả hơn.
Peter Yang: Tôi luôn cảm thấy đây là phần tôi thích nhất khi làm quản lý sản phẩm hoặc nhà thiết kế — đó là đưa nhà thiết kế và kỹ sư lại gần nhau, cùng nhau quan sát và lặp lại sản phẩm. Vậy hiện nay các bạn ít khi làm các tài liệu lập kế hoạch như tài liệu đặc tả, file Figma… nữa sao? Hay là các bạn trực tiếp lặp lại prototype ngay trong mã nguồn?
Jenny:
Tôi vẫn dùng Figma. Nhưng hiện nay chúng tôi ít khi viết tài liệu đặc tả, và nếu có thì cũng thường không quá chi tiết. Đúng vậy. Chúng tôi vẫn thực hiện việc xếp hạng ưu tiên — tài liệu này vẫn tồn tại. Thực tế, điều này rất hữu ích khi chúng tôi gửi cho đội An ninh hoặc Pháp chế, để họ hiểu rõ nội dung sẽ được phát hành, nhưng thường chỉ gồm vài gạch đầu dòng — chứ không phải những bảng biểu được thiết kế cầu kỳ, quá mức. Tôi nghĩ file Figma của chúng tôi cũng vậy.
Thực hành trực tiếp với Cowork
Peter Yang: Bạn có thể trình diễn cách bạn sử dụng các sản phẩm này, hoặc giải thích rõ bạn dùng từng sản phẩm vào việc gì không?
Jenny:
Chắc chắn rồi. Tôi sẽ chia sẻ cách tôi sử dụng Cowork. Thực ra tôi có một bí mật nhỏ: ngoại trừ các công việc lập trình chi tiết cho môi trường sản xuất (production code), hiện nay tôi dùng Cowork cho gần như mọi việc. Trong những tình huống yêu cầu tập trung vào các chi tiết mã cụ thể, tôi vẫn dùng Claude Code. Nhưng đối với giao tiếp và cộng tác hằng ngày, tôi hoàn toàn phụ thuộc vào Cowork.
Tôi ấn tượng nhất ở Cowork chính là khả năng tổ chức thông tin của nó. Tôi thích gọi đây là nguyên tắc “đầu vào rác rưởi – đầu ra quý giá”. Nó có thể thu thập thông tin từ nhiều nguồn khác nhau, nhanh chóng xác định các điểm mấu chốt, chắt lọc nội dung có giá trị và chuyển hóa thành những kết quả thực tiễn, mang lại hiệu suất cao.
Ví dụ, hiện tôi đã kết nối một thư mục chứa các bản ghi phỏng vấn người dùng. Đội Cowork của chúng tôi rất coi trọng mối liên hệ chặt chẽ với người dùng — đây cũng là một trong những yếu tố then chốt giúp chúng tôi đạt được thành công nhất định. Chúng tôi tiến hành nghiên cứu trải nghiệm người dùng (UXR) truyền thống bằng cách trò chuyện trực tiếp với người dùng; đồng thời cũng tự dùng sản phẩm nội bộ — ví dụ như chúng tôi có một kênh Slack chuyên biệt để thu thập phản hồi. Ngoài ra, chúng tôi còn theo dõi các cuộc thảo luận trên mạng xã hội và lắng nghe ý kiến từ những người dùng nhiệt thành. Chính nhờ việc luôn duy trì mối liên hệ chặt chẽ với người dùng và khả năng lặp lại sản phẩm nhanh chóng, chúng tôi mới có thể không ngừng cải tiến và đạt được thành quả như hôm nay.
Vì vậy, điều tôi cần làm bây giờ là nói với Claude: “Này, tôi có thư mục phỏng vấn này”, nhưng đồng thời cũng yêu cầu Claude tìm hiểu trên mạng xã hội, Reddit và các đánh giá khách hàng về Cowork khác để cho tôi biết những nhận định sâu sắc nhất là gì. Việc này có thể mất một chút thời gian vì nó thực sự phải xử lý rất nhiều dữ liệu và tiến hành xử lý. Tuy nhiên, nó có thể thực hiện một số việc — ví dụ như đôi khi tạo ra các tác tử con (sub-agents) để xử lý song song, hoặc dành thời gian tìm kiếm trên mạng.
Peter Yang: Trong công việc thực tế của bạn, các bạn có loại báo cáo nhận định tuần định kỳ không? Tức là tự động tổng hợp toàn bộ nội dung rồi gửi cho bạn và cả đội?
Jenny:
Thực tế, hiện nay chúng tôi hoàn toàn có thể làm điều đó trực tiếp qua Cowork. Tôi nghĩ các nhà nghiên cứu của chúng tôi có một phiên bản như vậy để gửi đi; ngoài ra còn có một phiên bản khác được ping trực tiếp cho chúng tôi trên Slack. Chúng tôi cũng trực tiếp lắng nghe các kênh Slack nội bộ — chúng tôi rất phụ thuộc vào nội bộ và những người dùng mạnh nhất để nhận phản hồi tiên phong, bởi vì những người trong nội bộ thực sự sẵn sàng nói thật với bạn, họ thường đẩy tính năng đến giới hạn xa nhất và cũng dễ theo dõi nhất.
Peter Yang: Tôi nghĩ đây mới đúng là điều nên xảy ra, và tôi cảm thấy ở hầu hết các công ty, các đội nhóm thường quá tách rời nhau — nhưng Anthropic lại hoàn toàn không như vậy.
Jenny:
Tôi nghĩ đây cũng là một phần quan trọng tạo nên thành công của Claude Code — đó là lắng nghe người dùng ở tuyến đầu. Và đây cũng là điều chúng tôi làm rất nhiều khi sử dụng Figma — tức là thử nghiệm nội bộ (dogfooding) trên diện rộng. Bởi vì đặc biệt trong các khía cạnh thiết kế tương tác và mài giũa chi tiết, những người trong nội bộ thực sự sẽ chạm vào từng chi tiết nhỏ, trong khi người dùng bên ngoài thường đưa ra phản hồi mang tính “nó có phù hợp với quy trình người dùng của họ không?” — nên họ mang lại một cấp độ phản hồi hoàn toàn khác biệt.
Phân chia ranh giới người dùng giữa Cowork và Claude Code
Peter Yang: Tôi biết các chuyên viên tiếp thị và quản lý sản phẩm của Anthropic hiện nay hầu như đều đang dùng Claude Code để làm việc, đặc biệt là kể từ khi Cowork trở nên khả dụng nội bộ. Bạn nhìn nhận thế nào về các tình huống sử dụng khác nhau? Hay mọi người đang 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 áp dụng trong một số tình huống tiên phong vốn trước đây chỉ được thử nghiệm bởi những người dùng đầu tiên của Claude Code. Các bạn còn nhớ khi chúng tôi mới bắt đầu phát triển Cowork, đội bán hàng nội bộ là nguồn thông tin chính của chúng tôi. Trong số họ có vài người là người dùng sâu của Claude Code, sử dụng công cụ này để tạo danh sách khách hàng tiềm năng, viết kịch bản điện thoại… Khi lần đầu tiên tôi thấy những ví dụ sử dụng này, tôi thực sự rất kinh ngạc, vì ngay cả tôi cũng chưa từng nghĩ Claude Code có thể thực hiện được những công việc như vậy. Hiện nay, những người dùng này gần như đã chuyển hoàn toàn sang Cowork, thậm chí đồng nghiệp của họ cũng bắt đầu sử dụng Cowork thường xuyên hơn.
Chính vì hiện nay Cowork có một giao diện người dùng (UI) đẹp mắt, nên tôi cho rằng đây chính là điều kiện tiên quyết mà nó thực sự cần. Một phần nguyên nhân khác là nó rất gần gũi với các công việc khác mà họ đang làm — họ vốn đã dùng chức năng chat, và từ ứng dụng máy tính để bàn này họ cũng có thể tiếp tục dùng Claude Code, nên tôi cho rằng điều này phù hợp hơn với luồng công việc hiện tại của họ so với việc phải mở terminal.
Quy trình đầy đủ: Từ nhận định đến sản phẩm khả thi
Jenny:
Ở đây có bảy chủ đề khác nhau, và mỗi tuần lại thay đổi — tôi cơ bản có thể trực tiếp bảo nó: “Hãy giúp tôi tạo tài liệu X này”, và tài liệu đó đã tự động tồn tại trong một thư mục trên máy tính của tôi. Tôi thậm chí còn có thể khởi chạy hai tác vụ song song. Ví dụ, tôi có thể nói: “Những nhận định này thậ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 thực tế?” Sau đó tôi có thể song song thực hiện việc khác — “Dựa trên tài liệu nhận định mà bạn vừa giúp tôi tạo, hãy chuyển nội dung này thành một bài thuyết trình mà tôi có thể chia sẻ với đội trong buổi kickoff tuần này.”
Nhưng cuối cùng, tôi có thể bắt đầu quy trình thiết kế ngay từ đây — nó sẽ cung cấp cho tôi nhiều lựa chọn tính năng khác nhau. Từ đó, tôi thậm chí còn có thể yêu cầu Claude giúp tôi tạo một số wireframe cho các tính năng này. Nó có thể đưa ra rất nhiều lựa chọn khác nhau, tôi có thể mang chúng vào Figma để thực sự tinh chỉnh, hoặc đưa vào Claude Code để sử dụng các thành phần thực tế từ hệ thống thiết kế của chúng tôi, từ đó tạo ra sản phẩm thực tế và bắt đầu phát triển.
Ngoài ra, tôi còn có thể biến cả hai tác vụ này thành tác vụ định kỳ. Vì vậy, tôi có thể yêu cầu nó thiết lập lịch tự động thực hiện tác vụ này mỗi thứ Hai lúc 10 giờ sáng. Như vậy, mỗi thứ Hai lúc 10 giờ sáng tôi sẽ bắt đầu công việc với bài thuyết trình này và ba hoặc bốn ý tưởng sản phẩm khác để kickoff tuần làm việc. Nó đã nén chu kỳ lặp lại từ phản hồi đến sản phẩm khả thi hoặc ý tưởng có thể trình bày cho đội nhóm một cách cực kỳ ngắn gọn, giúp chúng tôi lặp lại sản phẩm nhanh hơn và cải thiện sản phẩm nhanh hơn.
Peter Yang: Mọi thứ đều xoay quanh việc lặp lại, mọi thứ đều xoay quanh việc lặp lại. Hiện nay tôi cũng trở nên lười biếng hơn — tôi luôn để AI làm bản đầu tiên, rồi 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 toàn bộ những nhận định này thành một thứ gì đó như thứ tự ưu tiên tính năng từ con số không, thì hiện nay việc này mất nhiều thời gian hơn trước rất nhiều.
Tôi cũng làm như vậy. Ví dụ, bạn gửi cho tôi bản ghi chú podcast này, tôi có một thư mục ghi chú cá nhân chứa nội dung các cuộc họp 1:1, những ý tưởng linh tinh… rồi tôi trực tiếp nói: “Hãy đọc các ghi chú cá nhân của tôi và giúp tôi suy nghĩ về các điểm chính trong bài phát biểu podcast này, đồng thời giúp tôi xác định xem tôi muốn nói gì ở đây.” Dĩ nhiên tôi sẽ không đọc y nguyên từng chữ, nhưng nó thực sự giúp tôi mở mang tư duy và phát triển suy nghĩ của mình, thay vì bị mắc kẹt.
Kỹ năng (Skills) và cơ sở tri thức cá nhân
Peter Yang: Bạn thường dùng những kỹ năng (skills) nào? Hay bạn có kỹ năng riêng dành riêng cho việc tạo tài liệu và bài thuyết trình không?
Jenny:
Bên trong công ty chúng tôi có một số kỹ năng chuyên dùng để tạo tài liệu và bài thuyết trình, bởi vì chúng giúp chúng tôi duy trì tính nhất quán về thương hiệu. Thực tế tôi không có thư viện kỹ năng cá nhân — phần lớn thời gian tôi mượn các kỹ năng nội bộ đã có và áp dụng chúng vào các mục đích khác nhau.
Peter Yang: Ví dụ như tôi có một kỹ năng viết (writing skill), nó sẽ nhắc AI tránh dùng những từ ngữ sáo rỗng do AI sinh ra (AI slop).
Jenny:
Nhưng thực tế tôi phát hiện rằng, hiện nay chỉ cần dùng thư mục file của Cowork — tôi đặt tất cả các ghi chú cá nhân vào đó — cách nó hiểu về tôi thông qua các thư mục này đã rất hữu ích. Thậm chí tôi cảm thấy mình ngày càng ít cần đến memory và skills hơn, bởi vì nó đã có một cơ sở tri thức về tôi. Dĩ nhiên tôi vẫn cho rằng skills có những tình huống áp dụng riêng, nhưng trong các tình huống sử dụng hiện tại của tôi, nhu cầu cá nhân về chúng không còn lớn lắm.
Peter Yang: Có phải vì nó tự động cập nhật memory mỗi ngày dựa trên cuộc trò chuyện của bạn không?
Jenny:
Đúng vậy, nó cơ bản là một memory do chính tôi duy trì, bởi vì tôi liên tục ghi chú vào đó.
Các điểm cộng tác trong đội nhóm
Peter Yang: Vậy trong toàn bộ quy trình, bạn thường đưa đội nhóm vào lúc nào? Hay là bạn lặp lại cùng AI, sau đó lặp lại cùng đội nhóm, cứ thế luân phiên? Cụ thể là như thế nào?
Jenny:
Tôi muốn nói rõ rằng những thứ như phỏng vấn UXR thực tế — tôi không tự làm việc này — mà thường do quản lý sản phẩm, nhà nghiên cứu trong đội hoặc người khác trong đội đảm nhiệm. Sau đó, thông qua những kết quả này, bạn trực tiếp chia sẻ các sản phẩm (artifacts), kéo mọi người vào và thực tế những thứ này sẽ trở thành cơ sở vận hành của đội nhóm.
Đội nhóm của chúng tôi ít nhất là khá theo hướng bottom-up và dân chủ, nên cách vận hành của chúng tôi là: chúng tôi chia sẻ các nhận định và mục tiêu với mọi người, sau đó mỗi người sẽ tự tạo prototype, thử nghiệm các ý tưởng — những ý tưởng này đến từ mọi phía. Không phải là nhà thiết kế (tức tôi) phải nghĩ ra tất cả các phương án, mà là “Này, đây là các nhận định. Đây là mục tiêu chúng ta cần đạt được trong tháng này — chúng ta cùng nhau làm thế nào để đạt được điều đó?”
Tôi nghĩ rằng ngay cả khi có công cụ này, chúng ta vẫn sẽ không giao toàn bộ mọi thứ cho Claude để thực hiện. Chúng ta vẫn phụ thuộc rất nhiều vào chính mình để đưa ra nhiều đánh giá quan trọng, cũng như khả năng quản lý và quyết định thực sự xây dựng cái gì và làm cái gì.
Peter Yang: Khi mọi người thảo luận trên mạng về gu thẩm mỹ và khả năng đánh giá, tôi cho rằng cách rèn luyện những khả năng này chính là liên tục thu thập phản hồi sản phẩm từ cả nội bộ và bên ngoài. Trong quá trình này, bạn sẽ dần hình thành một trực giác giúp bạn nhận ra những điểm sai sót và cần sửa chữa. Bởi vì bạn liên tục lắng nghe và xử lý các phản hồi này, nên dần dần bạn sẽ phát triển được khả năng đánh giá nhạy bén đối với vấn đề.
Jenny:
Về thiết kế, một tính năng của Claude là khả năng tạo ra các bản phác thảo dạng wireframe và đưa ra nhiều lựa chọn thiết kế khác nhau. Là một nhà thiết kế, tôi rất thích cách làm này. Ngay cả khi độ chi tiết của các bản phác thảo này không cao, nhưng chúng giúp tôi trực quan hóa các khả năng khác nhau mà không phải hoàn toàn phụ thuộc vào trí tưởng tượng của mình. Cách làm này giúp tôi nhanh chóng xác định hướng thiết kế tiếp theo.
Vì vậy, tôi cho rằng việc để Claude trực tiếp tạo ra những lựa chọn sơ bộ này có thể giúp tôi tiết kiệm rất nhiều thời gian và công sức so với việc tự vẽ tay. Từ những lựa chọn này, tôi sẽ chọn một hướng và bắt đầu lặp lại ở quy mô nhỏ. Tiếp theo, tôi có thể dùng mã nguồn để xây dựng một prototype sơ bộ theo hướng đã chọn, rồi tiếp tục tối ưu và hoàn thiện thiết kế dựa trên nền tảng đó.
Câu chuyện thực sự đằng sau sự ra đời của Cowork
Peter Yang: Hãy cùng nói về cách Cowork ra đời. Bên ngoài có rất nhiều câu chuyện về việc nó được xây dựng chỉ trong 10 ngày, nhưng thực tế trước đó đã có rất nhiều vòng lặp rồi đúng không?
Jenny:
Câu nói “họ chỉ mất 10 ngày để xây dựng xong” thực chất được trích ra từ một cuộc phỏng vấn hoặc bài báo truyền thông nào đó, và mọi người cứ xoay quanh điểm này để thảo luận. Còn thực tế thì hướng phát triển Cowork đã bắt đầu được chúng tôi lên ý tưởng ngay từ khi tôi gia nhập Anthropic cách đây một năm — chúng tôi liên tục suy ngẫm về cách tạo ra một “người bạn đồng hành tư duy” (thinking partner) hỗ trợ tất cả những người lao động tri thức phổ quát. Mặc dù Claude Code đã xử lý rất tốt các tác vụ liên quan đến mã nguồn, mục tiêu của chúng tôi là bao phủ toàn bộ các tình huống công việc tri thức. Theo tôi, thách thức thực sự nằm ở chỗ: Làm thế nào để hiện thực hóa ý 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?
Trong năm qua, chúng tôi đã thử nghiệm rất nhiều prototype khác nhau, trong đó một số ý tưởng thậm chí còn hoành tráng hơn mục tiêu hiện 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 framework tác tử AI khác nhau, nhưng một số thử nghiệm này đã không thành công. Cuối cùng, chúng tôi mới dần xác định được hướng đi hiện tại. Chúng tôi không chỉ tham khảo các prototype do đội phòng thí nghiệm phát triển, mà còn nghiên cứu các prototype do chính đội sản phẩm của chúng tôi xây dựng. Cuối cùng, thời điểm và khả năng thực thi trở thành yếu tố then chốt — giống như tia chớp vừa vặn đánh trúng mục tiêu.
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 rất nhanh chóng — từ “chúng ta nên phát hành rồi” đến “sản phẩm đã lên sóng”, chỉ mất đúng 10 ngày. Điều này chủ yếu là vì trong kỳ nghỉ của Claude Code, chúng tôi nhận ra tiềm năng của nó. Trong kỳ nghỉ, nhiều người cuối cùng cũng có thời gian để thử nghiệm Claude Code, thậm chí cả những người dùng phi kỹ thuật cũng bắt đầu sử dụng nó — ví dụ 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 framework tác tử của Claude Code bắt đầu thể hiện mức độ phù hợp ban đầu giữa sản phẩm và thị trường (product-market fit) ngay cả với người dùng phi kỹ thuật. Thực tế, lúc đó bên trong công ty chúng tôi đã có một prototype khả dụng, ban đầu dự kiến phát hành muộn hơn một chút, nhưng những phản hồi này khiến chúng tôi nhận ra “bây giờ chính là thời điểm hoàn hảo”. Vì vậy, chúng tôi quyết định nắm bắt cơ hội này, và cuối cùng có được khoảng thời gian 10 ngày điên cuồng đó.
Peter Yang: Nếu tôi hiểu đúng, thì trong năm qua các bạn đã chia sẻ rất nhiều prototype trên kênh Slack nội bộ, thu thập phản hồi dồi dào và cuối cùng xác định được một prototype khả thi. Sau đó, vì nhận ra nhu cầu thị trường đối với nó, các bạn đã nhanh chóng thực hiện một đợt tăng tốc (sprint) để đưa sản phẩm ra thị trường.
Jenny:
Đúng vậy, đại khái là như vậy. Ban đầu chúng tôi dự định ra mắt sau vài tuần nữa, nhưng lúc đó chúng tôi cảm thấy “bây giờ chính là thời điểm hoàn hảo”. Điều này thúc đẩy chúng tôi thu hẹp phạm vi sản phẩm trong bối cảnh thời gian eo hẹp để đạt được mức độ khả thi thực tế hơn, đồng thời dồn toàn lực và nguồn lực để hoàn thành việc phát hành.
Giai đoạn lặp lại thiết kế ban đầu: Từ công cụ quy trình (workflow) đến giao diện chat tối giản
Peter Yang: Bạn có thể chia sẻ một số kinh nghiệm về các vòng lặp đầu tiên, hoặc trình diễn một số nội dung đang trong giai đoạn phát triển không?
Jenny:
Chắc chắn rồi. Tôi đặc biệt đã tổng hợp một số ảnh chụp màn hình đầu tiên để minh họa tư duy thiết kế và quá trình lặp lại của chúng tôi lúc bấy giờ.
Đầu năm nay, chúng tôi có một prototype sơ khai — đây là sản phẩm hợp tác giữa tôi và một nhà thiết kế khác. Lúc đó, chúng tôi cố gắng thiết kế công cụ này theo hướng định hướng tác vụ (task-oriented) hoặc định hướng quy trình (workflow-oriented). Bởi vì chúng tôi rất lo ngại người dùng có thể không hiểu rõ: khi sử dụng một sản phẩm như Cowork, họ có thể hoàn thành những tác vụ cụ thể nào, hoặc đạt được những kết quả rõ ràng nào — ví dụ như tạo một bảng điều khiển (dashboard), hoặc tích hợp dữ liệu từ nhiều nguồn khác nhau. Vì vậy, lúc đó chúng tôi thiết kế giao diện người dùng rất có cấu trúc, gần như một công cụ quy trình — ví dụ như “thêm những nội dung này, đây là đầu vào (inputs), đây là đầu ra (outputs)”. Còn chức năng chat bị đẩy xuống vị trí thứ yếu.
Nhưng cảm giác phải thực hiện quá nhiều bước để hoàn thành, trong thời đại năm 2025 này, tại sao chúng ta vẫn phải làm phức tạp như vậy? Để Claude xử lý những việc này trực tiếp chẳng phải đơn giản hơn sao?
Đây là một 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 tư duy, làm cho nó đơn giản hơn — giống như một ô chat (chat box). Chúng tôi thử nghiệm cách dẫn dắt người dùng đạt được các mục tiêu cụ thể hơn thông qua giao diện này — ví dụ như phân tích hoặc tạo tài liệu. Chúng tôi cũng thiết kế một prototype chức năng — người dùng nhấp vào sẽ thấy các tùy chọn khác nhau, mỗi tùy chọn đều có nút điều chỉnh — ví dụ như độ dài tài liệu, hoặc chọn loại tài liệu như bản ghi nhớ hay bài thuyết trình — nhưng thiết kế này cuối cùng khiến người dùng cảm thấy quá phức tạp và áp lực.
Vì vậy, trong nhiều lần khám phá và thử nghiệm, chúng tôi liên tục nỗ lực tìm kiếm một điểm cân bằng: chúng ta nên xác định rõ ràng các tình huống sử dụng, hay giữ giao diện tự do như một ô chat?
Cuối cùng, phiên bản chúng tôi phát hành vài tuần trước đây chính là hình dáng hiện tại. Trước đây chúng tôi từng thử nghiệm một trải nghiệm người dùng gần giống “chế độ hướng dẫn” (wizard-like), người dùng nhấp vào sẽ thấy các gợi ý như “tạo một tài liệu, độ dài từ ba đến năm trang”…
Lúc đó, chúng tôi còn bổ sung rất nhiều yếu tố vào giao diện nhằm khiến nó trông khác biệt so với ô chat thông thường. Nhưng sau đó phát hiện ra thiết kế này khiến giao diện trở nên quá phức tạp, các yếu tố thị giác tranh giành quá mạnh. Vì vậy, chúng tôi quyết định đơn giản hóa thiết kế, loại bỏ phần lớn các yếu tố không cần thiết.
Giờ đây, bạn thấy giao diện người dùng đã được đơn giản hóa đáng kể. Chúng tôi đã loại bỏ thanh bên (sidebars) nặng nề, khiến nó gần giống hơn với ô chat truyền thống, nhưng có một số thay đổi ở trang chủ để nó trông giống hơn một “danh sách việc cần làm” (to-do list) mà tôi và Claude cùng chia sẻ, thay vì một công cụ chat đầ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 tử (agent), cho phép kéo thả các tác vụ để quản lý quy trình làm việc.
Jenny:
Có thể trong tương lai sẽ có khả năng như vậy. Nhưng tôi muốn nhấn mạnh rằng, giao diện người dùng (UI) cách đây khoảng bốn đến năm tuần còn hoàn toàn khác biệt — chúng tôi liên tục học hỏi, khám phá đâu là thiết kế hiệu quả nhất, đâu là thiết kế kém hiệu quả hơn, đồng thời nỗ lực tìm ra cách tốt nhất để trình bày công nghệ này cho người dùng.
Sự khác biệt trong định vị giữa Cowork và Claude Code
Peter Yang: Trong quá trình sử dụng Claude Code, tôi thường chia sẻ một số phản hồi trên Twitter. Nó tích hợp rất nhiều lệnh dấu gạch chéo (slash commands), đòi hỏi người dùng từng bước học cách sử dụng. Trải nghiệm này giống như “săn kho báu” (treasure hunt) khi mua sắm tại Costco — bạn luôn không biết mình sẽ khám phá ra tính năng mới nào.
Nhưng đối với người mới, cách này không thực sự thân thiện. Nó giống như một trò chơi — bạn càng sử dụng lâu, bạn càng quen thuộc và thành thạo hơn. Tôi cảm thấy Cowork có thể đang cố gắng khám phá vùng trung gian giữa công cụ chat thông thường và Claude Code. Nó không ẩn giấu tất cả các tính năng, đồng thời vẫn có thể dẫn dắt người dùng sử dụng hiệu quả hơn theo một cách nào đó.
Jenny:
Đúng vậy. Cowork vẫn hỗ trợ các lệnh dấu gạch chéo (slash commands), nhưng chúng không phải là phương thức tương tác chính. Cá nhân tôi cảm thấy Cowork ít nhất là một công cụ dành cho các chuyên gia. Chúng tôi quan sát thấy nhiều người dùng đã sử dụng nó theo cách rất chuyên sâu, và cộng đồng đã xuất hiện một số người dùng cấp cao. 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 — ví dụ như tự tạo kỹ năng (skills), chia sẻ với đội nhóm, hoặc sử dụng các lệnh viết tắt (shorthand commands).
Tuy nhiên, mục tiêu của chúng tôi là khiến những tính năng này trở thành phương thức tương tác phụ, chứ không phải 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 biết tất cả các lệnh, họ vẫn có thể sử dụng Cowork một cách dễ dàng. Chúng tôi mong muốn người dùng tương tác với Claude một cách tự nhiên và trực quan, chứ không phải phải ghi nhớ một loạt lệnh mới có thể thực hiện thao tác.
Quy trình lập kế hoạch và tầm nhìn
Peter Yang: Quy trình lập kế hoạch của Anthropic như thế nào? Các bạn có thực hiện lập kế hoạch hàng năm và đặt mục tiêu không? Hay các bạn chủ yếu dựa vào việc phát triển prototype và không ngừng thử nghiệm?
Jenny:
Cách lập kế hoạch của chúng tôi thay đổi mỗi lần. Trong đội của tôi, chúng tôi thực hiện kế hoạch theo tháng. Chúng tôi có một bảng tính, ít nhất trong phần Cowork, liệt kê tối đa khoảng 12 nhiệm vụ — đây đều là các 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: “Liệu chúng ta vẫn đang đi đúng hướng?” Chúng tôi cũng thực hiện một số kế hoạch quý hoặc nửa năm, thường do một người chịu trách nhiệm chỉ ra: “Tôi cho rằng chúng ta nên phát triển theo hướng này, đây là những điều chúng ta cần lưu ý.” Nhưng những kế hoạch này không nghiêm ngặt đến mức bắt buộc phải thực hiện các dự án cụ thể. Chủ yếu là để cung cấp một định hướng tổng thể cho đội nhóm, nên khá linh hoạt.
Peter Yang: Khá linh hoạt, đúng không? Thú vị là tôi nhận thấy các công ty đổi mới nhất thường ít thực hiện lập kế hoạch hàng năm, mà thay vào đó là không ngừng lặp lại và học hỏi từ người dùng. Trong sự nghiệp của bạn, bạn đã từng làm một bản trình bày tầm nhìn North Star nào chưa? Bạn có thấy chúng hữu ích không?
Jenny:
Tôi đã từng làm, năm ngoái tôi đã thực hiện một bản trình bày tầm nhìn North Star. Tôi cho rằng tầm nhìn thực sự có giá trị — chúng chỉ rõ định hướng cho đội nhóm và giúp chúng ta giữ được sự rõ ràng trong các công việc sắp tới. Tuy nhiên, do lĩnh vực công nghệ mà chúng ta đang hoạt động thay đổi cực kỳ nhanh chóng, các mô hình mới liên tục xuất hiện và tốc độ cập nhật ngày càng tăng. Vì vậy, đối với chúng tôi, việc xây dựng một tầm nhìn dài một năm đã là điều không thực tế, chứ chưa nói tới tầm nhìn hai đến năm năm — bởi vì còn quá nhiều yếu tố chưa biết.
Tuy nhiên, vai trò thực sự của tầm nhìn là dẫn dắt mọi người hướng về cùng một mục tiêu, đặc biệt trong môi trường mà mỗi người đều có thể tự do xây dựng các dự án khác nhau. Vì vậy, hiện nay tôi cho rằng tầm nhìn nên có độ dài tối đa từ ba đến sáu tháng, và có thể được trình bày dưới dạng tài liệu. Tôi cảm thấy tầm nhìn sẽ có ảnh hưởng mạnh hơn khi được trực quan hóa. Đây cũng chính là giá trị to lớn của thiết kế — khả năng tích hợp các yếu tố khác nhau để kể một câu chuyện mạch lạc trong một khoảng thời gian nhất định. Tất nhiên, tầm nhìn cũng có thể là một prototype, chứ không chỉ là một bản trình bày tĩnh. Nó có thể giúp chúng ta điều phối công việc giữa các đội nhóm, đặc biệt khi chúng ta có năm đội đang xử lý các dự án rất giống nhau hoặc thậm chí có thể xung đột. Thiết kế có thể đóng vai trò tuyển chọn (curating) để giúp những ý tưởng này thống nhất và chỉ ra cho chúng ta một con đường dẫn đến trải nghiệm người dùng lý tưởng, thay vì một trải nghiệm rời rạc.
Peter Yang: Vậy các bạn có tổ chức đánh giá bởi quản lý sản phẩm hoặc các bên liên quan không? Những buổi đánh giá này là chính thức, hay họ cũng tham gia vào quá trình thiết kế prototype?
Jenny:
Chúng tôi thực sự có tổ chức các buổi đá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 phải trải qua đánh giá. Các buổi đánh giá của chúng tôi chủ yếu tập trung vào những dự án lớn và có mức độ ưu tiên cao. Mục đích của đánh giá không phải để tốn nhiều thời gian chuẩn bị, mà là để nâng cao tính hiển thị của dự án và nhận phản hồi. Nếu là những dự án quan trọng ảnh hưởng đến toàn công ty và có sự tham gia của nhiều đội nhóm, chúng tôi sẽ tổ chức các buổi đánh giá này.
Lời khuyên dành cho nhà thiết kế: Làm thế nào để tìm được vị trí của mình trong kỷ nguyên AI
Peter Yang: Vậy, đối với những nhà thiết kế cảm thấy môi trường nghề nghiệp của mình đang thay đổi nhanh chóng, bạn có lời khuyên nào không? Họ có nên bắt đầu học cách gửi pull request (PR) không? Hay nhà thiết kế nên tiếp cận theo cách khác để thích nghi?
Jenny:
Nếu bạn cảm thấy mặt đất dưới chân mình đang chuyển dịch, thì đó là vì nó thực sự đang thay đổi. Chúng ta buộc phải thừa nhận điều này, học cách thích nghi, đồng thời cũng cần cởi mở để xem xét lại cách làm việc hiện tại của mình. Tôi cảm thấy sự thay đổi hiện nay ảnh hưởng đặc biệt lớn đến nhà thiết kế, đặc biệt vì chúng ta đang ở trong làn sóng thứ hai của cuộc cách mạng này. Một số vai trò nghề nghiệp khác đã trải qua sự chuyển đổi tương tự, và giờ đến lượt chúng ta. Đồng thời, các công cụ thiết kế của chúng ta cũng không ngừng tiến hóa.
Mỗi khi tôi cảm thấy nghề nghiệp của mình bị thử thách, tôi đều cảm thấy lo lắng — ví dụ như “Trời ơi, công việc của tôi đang thay đổi mạnh mẽ, người ta có thể sẽ không còn đánh giá cao vai trò của tôi như trước nữa.” Nhưng trong những khoảnh khắ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 biến đổi khổng lồ từ lâu, nhưng họ không chỉ thích nghi với những thay đổi ấy, mà còn đón nhận thử thách với lòng can đảm và khiêm tốn tuyệt vời, cuối cùng đạt được hiệu suất và chất lượng công việc cao hơn 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 tôi rất kính trọng có thể làm được, thì chắc chắn tôi cũng sẽ làm được. Họ là tấm gương giúp tôi thích nghi với sự thay đổi.
Peter Yang: Ở một khía cạnh nào đó, những thay đổi này giúp nhà thiết kế thoát khỏi rất nhiều công việc lặp đi lặp lại nhàm chán — ví dụ như không còn phải mất thời gian căn chỉnh các khung hình nữa, đúng không? Như vậy bạn có thể tập trung nhiều hơn vào các suy luận ở cấp độ cao hơn và công việc sáng tạo.
Jenny:
Đúng vậy, hoặc nói cách khác, những thay đổi này giúp chúng ta hoàn thành nhiều việc hơn. Ví dụ, khi tôi thấy các đồng nghiệp kỹ sư của mình hiện nay có thể hoàn thành một tính năng đầy đủ chỉ trong vài ngày — trong khi trước đây có thể mất vài tuần — tôi thực sự cảm thấy vô cùng kinh ngạc. Vì vậy, đúng vậy, những thay đổi này cũng mở ra nhiều khả năng hơn.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
深潮TechFlow
