AI 助理 Spark

传统 chat 聊天覆盖不到的场景应该是更原始的场景
因为本身我从把“事情的复杂度”，转换成问题这个过程，本身就是一种成本。不然也不会有“学会提问”这本书了。你去研究某个领域，或者某件事情，第一件事就是要分解，找到有哪些需要解决的问题。
程序员觉得chat 聊天很好用的一方面是，程序员遇到的问题，都是很容易分解，且有比较确定的解决结果的，比如使用 x 库，运行哪个函数，使用哪个技术方案

我们回到助理场景下，一开始我设立的需求是，它要成为一个助理，我要假装我请了一个助理，想尽办法去使用

但实际的问题是，我传递信息给助理这个过程，本身就是非常高成本的过程。

对应写代码的例子是：我跟实习生解释这个事情要怎么做，感觉还没解释明白，我自己代码都能写完了。这交给实习生做，做完我还要 review。错了还要让他改。现在使用AI助手的顾虑跟上面的顾虑是一模一样的

所以有几个比较重要的方向：

降低信息传递的成本，第一个是传递介质，可以使用声音就没必要使用文字。第二个是内容的收集，尽可能将最近事情的上下文，汇集好，减少上下文缺失
增加结果的可拓展性，必须假定给你的结果就是不完全够好的，给出自己能修改的空间。只需要做到：自己做比较麻烦，帮我做了也还行，偶尔能闪光，这种程度就很好了
在一些场景下，不要求完全的实时性，你安排实习生干活，也只会定期review 看看这个做的怎么样。
目前软件的 AI 的问题，是生态限定。而且更多情况下，类似只是一个快速输入表单，执行某个API 指令的过程（有点蹭了）。这种局限性既来自产品生态（我总不能引流到其他家的产品），另一方面来自用户需求的多样性，对于产品设计而言，在AI 生态早期，没有人能通用统一的找到最佳实践，或者简单说对于现有产品，AI 的介入是伪需求。

对应的具体的落地事项是：