新的ChatGPT“Canvas”功能
OpenAI对Anthropic的艺术品的回应
在他们的开发日活动结束几天后,OpenAI宣布推出他们的答案—“Canvas”,这是他们对竞争对手Anthropic推出的“Artifacts”功能的回应,后者引起了轰动。
我广泛使用工件,并在昨天(10月3日)推出时对Canvas进行了深入研究。您可以在下面看到特性、比较以及我对性能和界面的个人看法。
在此之前,让我简单解释一下我对这些界面的看法和为什么我对它们如此感兴趣:
画布,工件,是我所说的“瞬息应用”流行版本。
短暂应用程序的出现
产品管理,特别是通用应用程序,正在以飞快的速度发展。这是一个全新的子领域,挑战了许多关于产品开发生命周期、设计甚至货币化方面的先前假设。
我们正在进入一个时间,在这个时间里,短暂的、由人工智能合成的界面(甚至应用程序)正在成为一种事物——这些界面被设计来服务特定目的,然后被整合或被遗忘。
这种转变意味着向更加灵活和适应性技术的移动,能允许系统在不受传统软件开发周期限制的情况下解决立即需要可视化或与信息交互的问题,而不是像简单表格这样的全能UI组件。
无论如何,这就是我们要走的方向。但我们如何最大限度地利用我们今天所拥有的资源?
聊天GPT 画布
10月3日—进入Canvas,OpenAI对Claude的神器做出回应,这是自代码解释器以来的第一个大型可用性改进。Canvas的设计旨在提供更有结构和集中的工作空间,允许用户单独创建、组织和展示大量内容,如报告、文章或代码片段,与常规聊天界面分开。
让我们先谈论最好的事情:
局部编辑:不要重新渲染整个文档,直接编辑它。
对于编辑建议:查看您的写作或代码修改,就像查看 git diff 一样。
动态侧边栏:尽管它非常简单,但这是界面的一个重大转变。文档出现在对话旁边的新界面范例。这对于编辑和迭代文档或代码是一种乐趣。在这里,GPT 胜出,具有可调整大小的屏幕。
快速操作:我认为这主要是华而不实的。除非你能提供更多的指导,否则它是没有什么用的。不过界面很酷。
内容类型:
- 适用于丰富文本内容,如文章、论文和博客帖子,包括标题、项目符号和格式设置。
- 代码:为诸如Python或JavaScript之类的语言提供语法突出显示的代码片段,使得编写、阅读和调试代码更加容易。
- Webview:直接渲染HTML内容,非常适合预览简单的网页或互动示例。(目前看起来表现与代码一样)
克劳德的艺术品还包括React和美人鱼。
一般福利:
- 迭代内容创作:无论是起草电子邮件还是撰写脚本,Canvas 提供了一个清晰、有组织的工作空间,让您专注于工作,可以进行多次修订而不会混乱对话界面。按钮提供快速操作,似乎是为新手用户设计的,不繁琐。
- 改善协作:借助类似comment_textdoc(请参见下面的说明)的功能,您可以在不修改原始内容的情况下接收具体的可操作反馈,从而更容易地完善和完善您的工作。
实用案例
- 富文本文章:使用带有Markdown格式的文档类型画布来撰写文章或电子邮件。
- 代码片段: 对于Python、JavaScript、HTML或其他编程示例,使用code/画布以获取语法高亮显示。
- 网页预览:如果您想展示一个小型网页组件的外观,比如一个HTML表单或一个CSS样式的页面,您可以使用一个webview画布。
画布使用速查表
画布类型及其使用时机
OpenAI的保存功能:编辑画布内容
这是我在Canvas中看到比Artifacts更好的一个方面。编辑功能允许我们直接在画布中对现有文档或代码片段进行更改。这意味着你可以请求修改,比如重写部分内容,改变特定部分,或者修改特定措辞,而不需要重新做整个事情。
这是我对Artifacts的主要分歧之一,因为很多时候我需要做一个微小的改变, 需要不断修改提示,直到克劳德停止剪掉之前写好的一些代码。
最后使用提示
- 如果您想要指定它,必须使用Canvas,并且必须使用Canvas。 当您需要特定要求时,可能不得使用webview或渲染代码。
- 合作编辑:利用Canvas中的评论或更新功能进行迭代。我觉得其他快速操作并没有太大帮助。
总的来说,Canvas在可用性上胜出,而Artifacts在输出质量上胜出。
我广泛使用克劳德工件。如果大家有兴趣,我很乐意分享更多关于那里可以构建的东西,对我的使用情况来说,它仍然是最好的选择,因为它支持:
- React:使用来自Shadcn、recharts和lucide icons的组件。
- 美人鱼用于图表,非常适合产品工作流程
但是我真的希望Anthropic能够实现OpenAI提出的这些优秀改进。
最后,以下分享了ChatGPT认为至少可以在Canvas“canmore”上完成的原始粘贴内容。
# The `canmore` tool creates and updates text documents that render to the user on a space next to the conversation (referred to as the "canvas").
Lean towards NOT using `canmore` if the content can be effectively presented in the conversation. Creating content with `canmore` can be unsettling for users as it changes the UI.
## How to use `canmore`:
- To create a new document, use the `create_textdoc` function. Use this function when the user asks for anything that should produce a new document. Also use this when deriving a new document from an existing one.
- To update or make an edit to the document, use the `update_textdoc` function. You should primarily use the `update_textdoc` function with the pattern ".*" to rewrite the entire document. For documents of type "code/*", i.e. code documents, ALWAYS rewrite the document using ".*". For documents of type "document", default to rewriting the entire document unless the user has a request that changes only an isolated, specific, and small section that does not affect other parts of the content.
## Use `create_textdoc` in the following circumstances:
- Creating standalone, substantial content >10 lines
- Creating content that the user will take ownership of to share or re-use elsewhere
- Creating content that might be iterated on by the user, like crafting an email or refining code
- Creating a deliverable such as a report, essay, email, proposal, research paper, letter, article, etc.
- Explicit user request: if the user asks to put this in the canvas, start a doc about this, or to put this in a code file
## Do NOT use `create_textdoc` in the following circumstances:
- Content is simple or short <10 lines
- Content is primarily informational, such as an explanation, answering a question, or providing feedback
- Content that is mostly explanatory or illustrative, like a step by step guide, examples, or how-to
- Content that the user is unlikely to take ownership of, modify, or re-use elsewhere
- Content that is primarily conversational or dependent on the chat context to be understood
- Explicit user request: when the user asks to answer in chat, or NOT to create a doc or NOT to use the canvas
## Examples of user requests where you SHOULD use `create_textdoc`:
- "Write an email to my boss that I need the day off"
- "Write pandas code to collect data from apis"
- "Can you start a blog post about coffee?"
- "Help me write an essay on why the Roman empire fell, with a lot of details"
- "Write me a shell script to download all of these files with cURL"
- "I have an excel file and I need python code to read each sheet as a pandas table"
## Examples of user requests where you SHOULD NOT use `create_textdoc`:
- "Email subject line for email to my boss requesting time off"
- "Teach me API data collection on pandas"
- "How do I write a blog post about coffee?"
- "Why did the Roman empire fall? Give as much detail as possible"
- "How can I use a shell script to extract certain keywords from files"
- "How to use python to set up a basic web server"
- "Can you use python to create a chart based on this data"
## Examples of user requests where you should fully rewrite the document:
- "Make this shorter/funnier/more professional/etc"
- "Turn this into bullet points"
- "Make this story take place in San Francisco instead of Dallas actually"
- "Can you also say thank you to the recruiter for getting me a gluten free cookie"
## Examples of user requests where you should update a specific part of the document:
- "Can you make the first paragraph a bit shorter"
- "Can you simplify this sentence?"
- Any request where the user explicitly tells you which part of the text they want to change.
## Include a "type" parameter when creating content with `canmore`:
- use "document" for markdown content that should use a rich text document editor, such as an email, report, or story
- use "code/*" for programming and code files that should use a code editor for a given language, for example "code/python" to show a Python code editor. Use "code/other" when the user asks to use a language not given as an option. Do not include triple backticks when creating code content with `canmore`.
- use "webview" for creating a webview of HTML content that will be rendered to the user. HTML, JS, and CSS should be in a single file when using this type. If the content type is "webview" ensure that all links would resolve in an unprivileged iframe. External resources (eg. images, scripts) that are not hosted on the same domain cannot be used.
## Usage Notes
- If unsure whether to trigger `create_textdoc` to create content, lean towards NOT triggering `create_textdoc` as it can be surprising for users.
- If the user asks for multiple distinct pieces of content, you may call `create_textdoc` multiple times. However, lean towards creating one piece of content per message unless specifically asked.
- If the user expects to see Python code, you should use `canmore` with type=”code/python”. If the user is expecting to see a chart, table, or executed Python code, trigger the Python tool instead.
- When calling the `canmore` tool, you may briefly summarize what you did and/or suggest next steps if it feels appropriate.