前沿｜AI 为什么还困在输入框里？

我们已经习惯了这样用 AI：先把背景整理好，写清目标、格式和限制，点发送，等它回答。结果不对，再补一句；它理解偏了，再换一种问法。

模型越来越聪明，用户却仍然要像填写任务单一样，把需求尽量写完整。

JoinIn AI 联合创始人 Ted Johnson 在演讲中用了一个计算机史比喻：The Prompt Is Still a Punch Card。如果换成中文工作场景，更直观的理解是：今天很多 prompt（提示词/输入请求）仍像一张需要用户自己填完的任务单。人负责整理意图、补齐材料、说明规则，AI 收到以后才开始工作。

文字输入当然有用。它精确、可修改、方便留档，也适合代码、文档和复杂约束。Ted 讨论的重点不在于取消输入框。更实际的问题是：当 AI 已经能理解语言、声音、文件和上下文，为什么大量准备工作还留给用户？

这关系到 AI 产品能不能从“会回答问题”走进实际工作。

输入渠道、表达空间和协作方式，是三个不同层面。模型能力提升后，产品容易卡在第三层。

输入框没有过时，过时的是“你先说完整”

Ted 用三个层面解释 AI 交互：channel、expression 和 protocol。直接翻译容易显得抽象，放进日常产品里，可以理解为输入渠道、表达空间和协作方式。

输入渠道回答的是：信息从哪里进入系统？键盘、麦克风、屏幕共享、摄像头和文件上传，都是不同入口。

表达空间回答的是：用户可以说出多少东西？菜单只能提供有限选项，命令行要求准确语法，自然语言则允许用户直接描述目标、顾虑和例外。

协作方式回答的是：人和 AI 怎么把一件事推进下去？谁先说，什么时候追问，缺少什么信息，哪些动作需要确认，结果不对时由谁修复。

这三层的发展并不同步。

AI 已经可以接收文字、声音、图片和文件，用户也能用自然语言表达复杂意图。可不少产品仍沿用同一种协作方式：用户先把需求说完整，模型回答；回答不对，用户再重新组织一次。

输入框本身没有问题。问题在于，产品把“说完整”的责任几乎全留给了人。

用户一直在替系统补材料

一次看似简单的提问，背后往往还有三份额外工作。

第一份是补背景。用户要回忆哪些信息重要，找到相关文件，解释团队约定，还要提醒 AI 哪些内容不能碰。模型能处理很长的上下文，不代表产品知道此刻该调用哪一段。

第二份是改写需求。人脑里的目标可能是一种感觉、一个业务问题，或者一段正在进行的讨论。为了让 AI 接住，用户需要把它改写成条理清楚的文字，再补上输出格式和判断标准。

第三份是负责返工。结果偏了，用户要判断哪里错了：是背景不够、目标含糊、约束冲突，还是模型根本做不到。之后还要决定怎样补问。

这些动作常被归入“prompt 能力”，仿佛只要用户再会提问一点，产品就没问题了。

会写 prompt 的确能改善结果。但从产品视角看，如果普通用户必须先学会如何给 AI 写任务书，系统仍有一部分工作没有做完。

输入框模式等待用户交代完整；过程协作模式会主动接住上下文、缺口和确认节点。

好的 AI，要在过程中接住工作

Ted 在演讲里举了一个会议场景。

几个人正在讨论费用审批：先做费用审批，访问权限以后再处理；超过 5000 美元需要二次审批；讨论到一半，阈值又改成 10000 美元。

常见的 AI 会议工具会转写、总结，等会议结束后给出纪要。Ted 描述的系统要更进一步：它跟随讨论，识别谁在说话，发现规则发生变化，在合适的时候确认阈值，并把结论写回任务。

用户不需要停下来另开一个输入框，再写一句“请把审批阈值改成 10000 美元”。AI 已经在工作发生的现场，也知道这句话与当前规则有关。

这种产品并不是更能聊天。它要处理四件更难的事：

• 看见当前任务的上下文；
• 判断什么时候需要澄清；
• 分清一句话是对同事说的，还是在要求 AI 行动；
• 碰到权限、金额和客户权益时，先让人确认。

这比生成一段更流畅的回答难，因为系统必须理解工作是怎样一步步推进的。

语音不等于更自然

把文字输入换成语音，看起来像一种升级，但它只能解决“怎么说”的问题。

如果 AI 不理解现场，语音反而更容易添乱。有人在会议里说“让小王进来一下”，系统可能误以为自己要执行某个动作；有人说“就按刚才那个方案”，AI 也未必知道“那个”指的是哪一版。

自然的交互，不只取决于声音像不像人。它还需要系统理解指代、说话对象、任务状态和介入时机。

有时候 AI 应该追问，有时候应该给建议，有时候只需要把结论记录下来。还有一些时候，它应该保持安静。

所以，语音只是新的输入渠道。产品是否更好用，还要看它能不能参与工作过程，同时守住边界。

上下文、时机、澄清和权限，决定 AI 能不能进入真实流程。

对产品团队来说，界面决定能力怎么落地

过去讨论 AI 产品，团队通常先问模型：推理能力怎么样？上下文够不够长？调用成本能不能降？

这些问题依然重要。但同一个模型放进不同的界面，用户感受到的能力会差很多。

一种产品要求用户复制材料、整理背景、改格式、反复说明；另一种产品能识别当前任务，主动找到相关信息，缺内容时再追问，最后把结果写回原来的系统。

两者调用的模型可能相同，工作体验却完全不同。

这对企业 AI Owner 尤其重要。很多公司已经上线知识库问答、制度问答和客服助手，业务部门仍觉得 AI 没有进入流程。原因不一定是回答不够聪明，也可能是 AI 仍站在流程外：它看不见当前任务，拿不到权限状态，无法把结果写回业务系统，也不知道哪个节点需要人确认。

用户最后还是要围着 AI 做准备工作。

产品团队可以换一种检查方法：先别只列模型功能，列一遍用户为了得到结果额外做了什么。

先看背景。系统能否自动带入反复出现的材料？

需求含糊时，别让 AI 直接猜，它应该先追问。

再看回写。结果能否在确认后进入原系统，省掉复制粘贴？

最后是风控。高风险操作必须留下确认、审计和回滚入口。

减少这些动作，往往比再加一个“智能生成”按钮更能改善体验。

输入框还会在，但不该包办一切

开发者、分析师、研究者和内容创作者仍会大量使用文字输入。它适合精确控制，也方便复用和检查。

变化会发生在其他环节。

会议、客服、销售跟进、代码审查和数据分析的关键信息，常常散落在对话、文件、历史动作和系统状态里。用户很难一次把所有内容写进 prompt，也没有必要每次都从头交代。

未来的 AI 产品需要多几种工作方式：在任务开始前自动准备相关背景，在执行中识别信息缺口，在关键节点请求确认，在结束后记录结果。输入框仍然保留，但不再承担全部协作工作。

结尾

过去，人为了使用软件学会了命令、菜单、表单和 prompt。

AI 给了产品团队一个反向设计的机会：让系统多理解一点人的工作方式。

Ted Johnson 提出的历史类比，放到今天的中文工作场景里，可以落成一个很具体的问题：用户是不是还在反复替 AI 补背景、写要求、收拾返工？

如果答案是，那产品还有继续改进的空间。

AI 进入工作，不靠输入框变得更花哨。它要接住上下文，知道何时追问，理解哪些动作需要确认，也接受有些时候保持沉默。

做到这些，AI 才不只是一个等人下指令的窗口，而会成为工作流程的一部分。

参考资料

1. Ted Johnson / JoinIn AI, 2026, The Prompt Is Still a Punch Card.

2. JoinIn AI, official website and product information.

3. OpenAI, Realtime API product information.

4. NVIDIA Research, Persona-style realtime conversation research demo referenced in the talk.