Pollish phi design doc details

docs/design/phi/design.md

@@ -620,12 +620,6 @@ void Scale(const Context& dev_ctx,
 
 > FAQ：
 
->- 为什么需要使用模板参数？为什么不和torch一样，没有模板参数？
-    - 运行时数据类型T和设备Device的选择是在kernel选择时必要的操作，各个框架都是一样的
-    - torch在写法上避免了用模板实现kernel选择，但实际上采用了全局kernel map查找的选择方式，这种方式的开销是比较重的，一个kernel的执行过程中，可能存在多次kernel map的查找
-    - 基本流程如下图：
-        - ![图片](http://bos.bj.bce-internal.sdns.baidu.com/agroup-bos-bj/bj-2aafdb051eaea7120bdf9604eb738029dcd3162a)
-    - 这种方式存在的性能问题已经被torch自身认识到，所以torch也在做算子库重构，但是积重难返，他们重构也并未对此问题从根本上解决，只是减少了一些redispatch的层数，我们不能一味模仿竞品自身都认为有问题的设计
 >- 为什么第一个参数需要是DeviceContext？为什么不能不传？
     - phi kernel要求是纯函数形式，即函数内使用的变量均通过参数传入，或者在函数内部创建，不允许在函数内部使用全局单例，为了适配多样的kernel需求，像DeviceContext这种存储上下文信息的参数是必要的
 >- 为什么需要两个模板参数？
@@ -1697,7 +1691,7 @@ API和Op都是对算子运行行为的概要描述，本质上只是同一段内
 
 推理之前为什么要做**算子增强推全**，就是op的参数太多了，但API的参数很少，这两者本来是介绍一个东西，却差别如此之大，所以需要发动全员，在op的某些参数上标记AsExtra，就声明这个参数可能是多余的。
 
-当然我们演变到如此田地，有一定历史原因：
+当然我们演变成现在这样，有一定历史原因：
 
 1. Op输入输出参数规范限制差，留的口子太大，可以天马行空地写；
 2. 2.0 API对外层Python API的形态做了大范围规整，但是Op层保持不变，是导致目前同一段描述差异变大的一个主要原因。