你问我为什么不用 GitHub Copilot Chat，非要选择 DevChat ？
1. 当我集齐了倚天剑和屠龙刀
左手倚天剑，右手屠龙刀。没错，我集齐了 GitHub Copilot、GitHub Copilot Chat 和思码逸 DevChat：
“差生文具多”你是不是想这样说我？
（你想没想我不知道，反正我刚才一个没忍住对自己说了这句话）
要说手撕代码，其实我不擅长。
不过能力不够，可以 AI 来凑。
毕竟武功再高，不如有把菜刀。
在 Copilot Chat 放开注册以前，我有好几次被朋友问到这样一个问题：
等 Copilot Chat 出来了，DevChat 拿什么来竞争？
彼时，我也不知道拿什么来竞争，毕竟我都没有用过 Copilot Chat（他们也没有用过，大家都在 wait list 里静静地等待）。不过我和那几位朋友一样，对 Copilot Chat 有一种莫名的敬畏，毕竟它的爸爸们可是微软、GitHub、OpenAI……
（真是恨爸不李刚，恨爹不双江！在拼爸爸的年代选择拼实力，此中心酸苦楚，何处话凄凉……）
此时，Copilot Chat 也用上了。不试不知道，一试，唉，原来 Copilot Chat 和 DevChat 一样，都处在“社会主义初级阶段”，bug 一抓一大把呀！
嗯，半斤八两，胜负未可分！
当然新产品诞生之初 bug 多，体验不完美，这些都是既在意料之中，又在情理之中的。在这个时候比谁的 UI 好看，比谁的安装丝滑，意义不大。来，升华一下，我们往后看一年。如果往终态看，你会发现 Copilot Chat 和 DevChat 虽然都在做“GPT 辅助编程工具”，但是走的是2条截然不同的路。我想产品定位、设计哲学上的差异才会最终影响谁在一年之后、三年之后或者十年之后最终赢得多数开发者的芳心，问鼎“中原”，坐上“最牛AI智能编程助手”这把交椅。
今天我准备站在用户视角“开个箱”，客观评测下 Copilot Chat 和 DevChat。我会通过一些实例告诉你 Copilot Chat 和 DevChat 能做什么，不能做什么，他们的的差异点在哪里。
2. Copilot Chat 评测 - 传言“得屠龙刀者可号召天下武林”
既然 Copilot Chat 名气大，全体程序员都认识它，那就从 Copilot Chat 开始吧。
2.1 Copilot Chat 的开箱体验
武林至尊，宝刀屠龙；号令天下，莫敢不从。
行文至此，我将本文发给了 Copilot Chat，要求它续写，然后：
尴了大尬。我以为它要秀一波肌肉，轻轻趴在我的耳边说：写文章，人类干不过 AI 的。失业吧，少年！
我都已经想好了用什么姿势去捡我那口被摔碎在地上的饭碗，结果……
这是意料之外的。本想评测下 Copilot Chat 写文章的表现，结果现在满脑子都是这幅动图，挥之不去。
2.2 让 Copilot Chat 解释代码
Copilot Chat 支持解释你选中的一段代码：
撇开交互上是不是丝滑的问题，反正单独解释一个“叶子函数”还是挺好用的。不过假如你的功能实现分散在2个源文件中（Golang 里的常规操作），这时候就有点头疼了，没法一次选中2个文件……
有一种你准备了2页演讲稿准备上台，发言前被告知只能带1页纸的既视感……
2.3 让 Copilot Chat 澄清需求
我们继续试下将一个开发需求丢给 Copilot Chat，看下它的表现：
问题不大，这事 Copilot Chat 能干。
2.4 让 Copilot Chat 生成文档
当 Copilot Chat 告诉我一个 worker pool 需要实现哪些功能后，我想让它写一个 README，于是：
Copilot Chat 倒是可以生成文档，但是生成的文档没法一键复制。如果用光标去选中的话，遇到文档中的“代码块”就会被打断。就算分批次选择非代码段部分，很遗憾，没法复制到原始 Markdown 格式，只能自己重新排版……
这里我丢给 Copilot Chat 的问题是：我想要开发一个 Worker Pool 程序，项目名叫 GoPool，并将其开源到 GitHub。现在我需要你帮我编写一个英文的 README.md，里面需要包含你总结的这些特性。
2.5 让 Copilot Chat 设计接口
接下来我希望 Copilot Chat 能够先给出设计，然后我再给它一些反馈，最后让它根据反馈内容调整设计，给出代码实现：
生成代码的功能倒是没有问题，代码块也可以方便地插入文件，这些功能还是好用。不过它并没有严格根据我的指示先给出设计，而是上来就写了一些具体的实现代码：
或许是我给的 prompt 不够优秀吧。总之，似乎差点意思。另外一点不太符合预期的是我的提问是全中文的，不过响应变成了全英文。
2.6 让 Copilot Chat 生成代码
刚才让 Copilot Chat 设计接口时其实已经看到了它生成代码的功能，不过显然 worker pool 有点小复杂了。不过我猜用它写一些功能明确的小函数应该不在话下：
看起来没问题，寥寥几行就实现了。这类任务显然 Copilot Chat 是擅长的。
2.7 让 Copilot Chat 生成单元测试
直接基于前面的聊天内容让写测试用例：
表现不错，没毛病。这个测试用例的覆盖度还是不错，比我自己手撕 UT 看起来要靠谱得多。
接着我尝试选中一个函数让 Copilot Chat 写测试用例：
额，它居然生成了整个文件的测试用例……
是我理解错了“Generate Tests”这个按钮的功能？它不让我增量写单元测试？
2.8 Copilot Chat 评测总结
Copilot Chat 可以：
- 基于选中的一段代码提问，例如要求解释代码；
- 自动基于打开的文件等为上下文，猜测用户意图，回答各种问题；
- 回答非代码类问题，例如让写文章，让分析软件需求；
Copilot Chat 不可以：
- 灵活管理自定义 Prompt 模板；
- 灵活选择上下文，比如以某2个源文件为上下文然后提问；
3. Copilot 评测 - 屠小龙刀也该拉出来溜溜
GitHub 在大约2年前推出了 Copilot，经过不知道多少个版本的迭代，Copilot 在“智能补全一行代码或者一个函数”这个功能上已经比较成熟了：
3.1 Copilot 是个好工具吗
在编辑器内光标往合适的地方一放，Copilot 就能猜到你可能需要写什么内容，比如：
- 根据注释生成一段代码
- 根据代码生成一行注释
- 编写注释的过程中补全
- 编写代码的过程中补全
我想 Copilot 能提效，有价值，这是毋庸置疑的。技术视角看似乎没理由拒绝 Copilot。
名副其实，Copilot 学习了所有公开的代码库，能够以用户正在编辑的文件和一些相关的或者是最近打开过的文件为“上下文”，借助 GPT 的能力较好地推理出用户接下来需要什么内容。
不过 “人如其名”，不难看出 Copilot 只会老实本分在副驾驶位，做好一个“辅助者”，默默地在你可能需要它的时候尽可能给出一些“编程建议”。可以预见 Copilot 的建议会越来越准，最终或许可以让你“一路 tab 写代码”。
总之，Copilot 是一个能提升开发效率的好工具！屠小龙刀，斩小龙不在话下！
3.2 Copilot 和 Copilot Chat 怎么选
别，可不兴这样提问哈。这就不是一个选择题，大家都是成年人，就不能“既要，又要”吗？
如果非要二选一，Copilot 连 ChatGPT 的对手都不是，更不用谈 Copilot Chat 了。从 Copilot 到 ChatGPT，我们已经看到了 Copilot 能做的是：
一行行补全、一个个函数生成、一个个测试用例补全……
而 ChatGPT 能做的却是：
需求分析、大段代码生成、测试用例一键补全、老代码注释一键补全、辅助 bug 分析、代码重构、双语文档生成、commit message 生成……
总之 Copilot 是个好工具，可以给你提效。不过 Copilot 不是“智能编程助手”的终极武器，你还需要在 Copilot Chat 和 DevChat 之间做一个选择。
4. DevChat 评测 - 倚天不出，谁与争锋
到 DevChat 了。可惜手里已经没有了“DevChat 早期驯化截图”，不然少说也能喷上五百字。
同样是一个年轻的产品，DevChat 里也存在很多的 bug 与不和谐。比如 DevChat 插件调用了一个 Python 的 CLI 程序，所以你在安装了 VS Code 的 DevChat 插件之后，还有一定的概率喜提 DevChat CLI 安装失败，不管是访问 PyPI 源遇到网络问题，还是某个 DevChat 依赖的 Python 依赖包和你的本地环境冲突（属相相冲，五行相克），总之会有各种可能导致你没法丝滑用起来 DevChat。
当然，这些问题都在被逐步解决，比如新版的 DevChat 已经支持自动切换国内的 PyPI 源、自动将 DevChat 安装到独立的虚拟环境、…… 总之各种已知的问题都在被逐步修复。所以如果你前阵子安装 DevChat 失败了，不妨现在又试试。
如果试试又失败了，行，我理解你的怒火，我建议你通过公众号“思码逸智能编程”的菜单栏找到 DevChat 用户群微信二维码，然后扫码进去，接着将错误截图发到群里，艾特群里所有的 DevChat 开发，使劲怼！！！(别说是我教你的)
4.1 DevChat 里的 Context 控制
前面提到 Copilot Chat 里没法基于多段 Context 提问，那么 DevChat 里对 Context 的支持又如何呢：
显然 DevChat 的开发团队认为 Context 应该由用户自己控制。在 DevChat 里你可以选中一段代码或者一个文件，右键 - “Add to DevChat” 将其添加到 Context 列表。没错，这是个列表，你可以添加多段 Context。
相比于 Copilot Chat 里自动将当前打开的文件和最近打开过的一些文件自动添加到 Context 的方式，显然 DevChat 这种 Context 管理模式更加灵活、透明且精准。
在这里 Copilot Chat 和 DevChat 走了两条完全相反的 Context 管理路线：
Copilot Chat：智能选择 Context，让用户只需要简单地用自然语言提问。DevChat：让用户灵活地选择自己的 Context，进而在明确的 Context 之上用自然语言提问，从而获取更加精准的 GPT 响应。
哪种方式好，大家可以有自己的见解。我个人觉得在 GPT 足够智能，成本足够低，会话 token 限制能够远远突破现在的 8k，16k 这种数量级，达到多少 m，多少 g 之后，那么显然 Context 的选择已经不是问题了，将整个项目的源码和文档全部当做 Context，一股脑儿喂给 GPT，然后基于“全量 Context”提问，妙啊！那时候肯定是用户不需要关心 Context 是什么了，工具层面“智能选择 Context”是最佳方案。不过目前 GPT 还没那么智能，token 限制也挺小，算力成本高，所以当下我觉得还是能够灵活、精准地选择“小巧够用”的 Context 更优。何况多余的 Context 会反向影响 GPT 响应的准确度。
4.2 用 DevChat 写代码的体验
DevChat 背后对接的是 GPT，所以代码生成能力本身和 Copilot Chat 应该难分伯仲。不过 UI 操作上比 Copilot Chat 要“更懂开发者”：
如上图，你能发现几个小细节？
- 支持单轮对话的删除和 refill。
GPT 的工作模式下，你的前置对话内容是会影响当前这轮对话的输出的。所以某一轮你没有得到理想的 GPT 回复，这时候重新提问，那么前一轮对话内容很可能既是干扰，又是浪费钱(token)。
有了“删除”和“refill”按钮，你就可以：点击 refill 按钮将旧的“提问内容”填充到消息发送框 -> 点击删除按钮将当前这轮对话删除 -> 修改消息发送框里 refill 进来的内容 -> 再点一下发送按钮，实现单轮的“重新提问”
- GPT 的响应内容支持复制原始 Markdown 格式内容。
这个功能在你要求 GPT 帮你写文档的时候特别有用。前面讲 Copilot Chat 的时候已经提到过了这个场景，这里就不再赘述了。
- GPT 生成的代码块支持“复制、View Diff、插入、替换”四种操作。
这里和 Copilot Chat 基本类似，复制和插入非常好理解。替换的意思是“如果有选中的代码，则替换当前选中的代码块；如果没有，则替换当前打开的文件”。View Diff 的意思是“将 GPT 生成的代码块和当前选中的代码块或者当前打开的文件做 diff”，效果如下：
- 允许用户灵活选择当前对话使用的大模型
截图里看目前 DevChat 允许用户自由选择 GPT-3.5、GPT-3.5-16k 和 GPT-4。多吗？不多。不过不难想到以后会越来越多，可能一年后的 DevChat 会在这里列出几十个，让你能够针对不同的任务选择最合适的大模型。
4.3 用 DevChat 写 Commit Message 的体验
我知道不少的开发者写 commit message 从来只用一个“update”。当你看到代码库里的提交历史是清一色的 update 时不知道你会作何感想，反正我是有点抓狂。
GPT 能用来写 commit message 不？
当然可以，只是需要将代码变更告诉 GPT。啥？你懒得去找命令，生成 diff 内容，然后发给 GPT？没关系，DevChat 预判了你的预判，你只需要在 DevChat 里点击消息框边上的加号，然后点一下 git diff --cached 就能将当前被 git add 添加到暂存区的代码变更告诉 GPT 了：
当然你懒得执行 git add 命令时，也完全可以用 DevChat 加号里那个 git diff HEAD 将当前工作区代码和 HEAD 的代码 diff 内容告诉 GPT。
接着你就可以通过 DevChat 的 commit_message 命令快捷地要求 GPT 生成 commit message 了：
DevChat 会将 GPT 生成的 commit message 很友好地展示给你，你可以选择复制 commit message，手动通过 git 命令实现 commit，也可以直接在 DevChat 视图里点击相应按钮一键完成 commit 动作：
这一套组合拳下来，整体体验还是听丝滑的。不过你要是问我是不是已经完美了？那肯定没有，比如 DevChat 还没有支持在插件内让用户灵活编辑 GPT 生成的 commit message，也没有支持 git commit 的时候添加更多的自定义参数，比如 -s。
最后，来个动图：
4.4 DevChat 的 Prompt 模版自定义功能
不知道大家有没有关注过 Prompt 工程？其实要想让 GPT 输出令人满意的答案，写 Prompt 是有技巧的。Prompt 有2大原则：
- 编写清晰且具体的指令(Write clear and specific instructions)；
- 给模型思考的时间(Give the model time to think)。
我在另外一篇文章《Prompt 指北：如何写好 Prompt，让 GPT 的回答更加精准》里有详细介绍如何通过 Prompt 工程来优化提示词，让 GPT 输出更精准的回答，这里就不重复赘述了。
既然写 Prompt 是有技巧的，那么“智能编程工具”里是否应该提供透明、灵活且支持自定义的 Prompt 模板支持呢？不难猜到 Copilot Chat 里也是有一些内置的 Prompt 模板的，这些模板会被追加到用户的提问内容之前，从而让 GPT 更好地理解用户的意图。不过这些 Prompt 模板用户是没法感知，也不能灵活自定义的。DevChat 在这里同样选择了另外一条路，就是“提供内置的 Prompt 模板，同时支持用户自定义 Prompt 模板”。通过这种机制再次将“Prompt 工程”的能力暴露给用户，让用户能够灵活、精准地控制完整的 Prompt。
如上图所示，DevChat 里内置了一些常用的 workflows。当你在 VS Code 里安装好 DevChat 插件后，DevChat 会在你的家目录下创建一个 .code/workflows 目录，然后在 workflows/sys 目录下存放内置的“prompts 模板”，比如 code/prompt.txt。然后你就可以在 DevChat 里用上 /code 命令来引用你定义在 code/prompt.txt 里的 Prompt 了。更进一步，code 目录下面还可以分语言存放更多的子命令来区分不同语言特定的 Prompt，比如 code/py/prompt.txt 文件中可以存放针对 Python 编程调优过的 Prompt，接着你就能够通过 /code.py 来引用 code/prompt.txt 加上 /code/py/prompt.txt 的内容了。
DevChat 还支持你管理自定义 Prompt，通过如下目录结构：
usr 目录的优先级是最高的，其次是 org，然后是 sys。这三个目录分别表示“用户自定义 Prompt 模板”、“组织自定义 Prompt 模板”和“系统内置 Prompt 模板”。比如上图中我就在“组织维度”定义了 /chat 命令，这个命令的预期是在团队内共享的，比如通过 git repo 的方式分发给大家；而 /blog 放在 usr 目录内，则表示是“我自己独享”的，和别人无关。
总之，通过 DevChat 的“自定义 Workflow”/“自定义命令”/“自定义 Prompt”/“自定义 instruction”（你喜欢叫啥就叫啥吧）功能，你可以灵活的管理自己的“Prompt 模板”，更高效地和 GPT 交互。
4.5 DevChat 评测总结
因为 DevChat 支持对接 GPT-4，所以具体的代码生成能力应该和 Copilot Chat 不相上下。不过 DevChat 提供了内置的 Prompt 模板，所以在具体的 GPT 响应内容和格式等方面会和 Copilot Chat 存在一定区别。
- DevChat 支持更加灵活、精准的 Context 控制；
- DevChat 提供内置的 Prompt 模板，也支持用户灵活修改、新增 Prompt 模板，实现自定义命令；
- DevChat 支持单轮对话的删除和 refill；
- DevChat 支持复制原始 Markdown 格式内容；
- DevChat 支持用户灵活选择每一轮对话所使用的大模型；
- DevChat 支持展示 GPT 生成的代码和当前选中的代码或者当前打开的文件的 diff 视图；
- DevChat 提供内置的快捷生成 Context 命令，比如通过
git diff --cached获取当前暂存区的代码变更，然后通过commit_message命令快捷生成 commit message； - ……
5. 总结
DevChat 和 Copilot Chat 都是挺好用的“智能编程助手”，但是它们走的是两条完全不同的路。
- Copilot Chat 选择的是“降低用户认知负担”，将 Context、Prompt 工程等都尽量隐藏，智能填充，从而让用户只需要用自然语言和 GPT 交互。
- DevChat 选择的让用户自己决定自己的聊天上下文（Context），自己决定自己的 Prompt 模板长啥样，从而将 GPT 的控制粒度更大的暴露给用户，以期用户能够获得更加准确的 GPT 响应。
孰优孰劣，不下定论，大家智者见智吧。
NOTE: DevChat 注册地址是 www.devchat.ai