很多法律人接触AI，都是从网页版开始的。打开ChatGPT、豆包或者DeepSeek，输入一个问题，AI在对话框里给出回答。这样现在看来很基本的操作，当时就已经让人感觉很神奇了。还记得2022年ChatGPT刚发布的时候，看着AI在那里一本正经地并非完全胡说八道，我的感觉可以类比OpenAI联合创始人奥特曼回忆一次GPT-5内部测试时所说的 “sat back in my chair”。
至于后来知道同一款产品还有桌面应用，通常也只会把它理解为网页版搬到了电脑桌面上。毕竟从互联网时代过来，各大厂商都知道，增强用户黏性的一个办法，就是让产品通过独立应用进入电脑或者手机。这倒也是常规操作。
至于CLI和IDE，在此之前我基本没听过。它们长期出现在程序员的工作环境里，普通用户既没有使用需要，也很难主动研究。主要是研究也研究不明白。我草草尝试了一下Claude Code，也就是Claude的CLI版本。安装是安装上了，也跑通了，但是确实用得不顺手。有没有大佬告诉我，时至今日，在通用Agent使用场景里，CLI比桌面端高端在哪儿？
现如今我最常用的入口已经是桌面应用，具体来说是Codex（虽然现在合并进了ChatGPT桌面端）。大部分需要持续推进、读取本地文件和直接形成修改结果的工作，我都会先交给Codex。网页版更多是补充：Codex额度不够，或者任务只需要讨论、问答和检索，不需要直接操作本地文件时，我才会转到ChatGPT网页端。
从实际工作方式看，同样是向AI提出要求，但这些入口背后的工作方式并不一样。在网页端，我通常把问题和材料交给AI，再根据回答继续追问；到了Codex，AI已经进入我指定的本地工作目录，能够读取项目里的文章、Skill和规则文件，并直接形成修改结果。重点就是这个“直接形成修改结果”，效率提高了不是一点两点。
移动端、CLI和IDE又分别扩展了不同的使用场景。移动端让对话和任务可以离开电脑继续进行；CLI通过终端与AI交互；IDE则把AI放进一个包含文件、编辑、终端和版本管理的项目环境中。
这里把它们统称为“入口”，采用的是使用者视角。它们在概念上并不完全同级，但都会影响AI能够接触哪些材料、调用什么工具，以及把任务做到哪一步。再加上具体产品的订阅和额度分配方式，完成同一项任务需要消耗的额度和成本也会不同。如果决定让AI成为生产力工具，最基本的比价和“杀鸡焉用牛刀”的思维是要有的。
Codex才是我现在最常用的AI入口
我接触AI虽然是从网页版开始的，现在做得最多的已经是把一项任务交给Codex，让它直接在本地工作目录里推进。
以这组科技专栏文章为例，项目目录里不只有一篇文章，还包括前三篇终稿、当前工作稿、写作规则和候选规则池。Codex可以读取这些文件，按照已经确认的规则修改当前文章，再把结果直接写回原来的位置。
这和AI在网页端返回一段修改建议，最大的差别就是结果落在哪里。后者还需要我复制出来，再找到正确文件粘贴进去；Codex修改完成以后，我打开的已经是改过的文件，可以直接检查前后差异，继续提出意见。
除了修改文章，我现在大量的资料整理、长期项目维护、文件检查和需要运行命令的任务，也都先交给Codex。只要一项工作需要反复读取多个文件，或者最终结果本来就应该形成在本地目录里，我通常不会再从网页版开始。
桌面Agent接触的材料和工具更多，权限范围也随之扩大。目录有没有选对、修改了哪些文件、结果能不能检查，出现问题以后能不能恢复，都比在聊天框里问一个问题更重要。模型能力再强，如果一开始进入了错误的目录，后面的执行效率越高，造成的麻烦反而可能越大。
之前介绍过，一个Agent产品好不好用，不只取决于自身架构，也取决于作为底座的LLM。
架构本身的确很有价值。我最直观的体会是在和团队一起开发LawBuddy的时候。当时我已经在使用Codex，所以也会把一些同类任务放在两个产品中进行对比测试。我发现，在当时的测试环境里，确实存在部分事项，典型的例如公开网页的抓取和内容提取，LawBuddy可以做到，但是Codex做不到。于是我专门请教了一下技术人员，对方告诉我，这和两个产品配置的网页工具及Agent架构有关。我们参考的Claude Code架构本身提供WebSearch和WebFetch一类工具，而我当时使用的Codex环境没有达到想要的效果。这至少说明，产品之间的能力差异不能全部归因于底层LLM，工具配置和Agent架构同样会直接影响结果。
再说说LLM。有的人为了省钱，不去官方渠道订阅，而是通过来源不明的第三方中转站调用GPT或者Claude模型。这就涉及“你这Token保熟吗”以及“你这Token纯吗”之类的问题。这里所谓“纯不纯”主要指中转站到底有没有调用它所宣称的模型，有没有压缩上下文或者调整参数，输入的文件又会被怎样处理。
实话说，国际领先的模型用多了以后，真的不太想再使用更便宜的低价模型，甚至产生了一种Token洁癖。我甚至不愿意用低价模型修改我的文件。
但是，还是回到成本与收益的问题。Codex不够用时，我也会换一个桌面Agent，例如QoderWork和Google Antigravity进行补充。
QoderWork是阿里旗下的一款桌面Agent。说实话，它已经成为我在Codex没额度时的替补主力。使用下来总体效果还不错，但我也算不上深度使用，就不过多发表意见。就我目前的体验而言，QoderWork使用门槛比较低，额度或者说积分给得也比较大方，常用工具基本配得比较齐。可以一试。
Google Antigravity我目前用下来，只能说拉完了。对谷歌的产品我一直寄予厚望，毕竟谷歌有那么多产品和数据，但是Antigravity在我日常使用的很多任务上，确实没有达到预期。最近又上线了Gemini 3.5 Flash，但至少在我的实际使用中，效果还是不太满意。
不过，Antigravity有一个点我要特别提出，就是把Markdown文档转成Word的能力。在我目前测试过的任务里，它转得又快又准，额度消耗还少。单就Markdown转Word这项任务来说，相比我目前使用Codex的效果，确实可以说遥遥领先。
网页版是额度和信息检索上的补充入口
网页版当然仍然重要。打开浏览器就能提问、上传文件和联网检索，不需要先整理项目目录，也不需要开放本地文件权限。只是对我来说，它现在更多承担补位工作。
这里首先有一个很现实的原因：额度。
按我目前使用ChatGPT的实际情况，普通Chat额度对我来说非常充裕，日常使用几乎感受不到限制；Codex额度却经常被我用到见底。即便我已经尽量把Codex额度留给需要处理本地文件的任务，按照目前的使用强度，还是经常不够。
这时，一些不需要直接修改本地文件的任务，我就会转到ChatGPT网页端。比如讨论一个问题、查询公开资料、修改一小段文字，或者使用已经配置好的合同审查GPT。网页端给出回答以后，我自己判断和处理即可，没有必要继续消耗更稀缺的Agent额度。
这里真正需要比较的，是我在不同入口中实际使用的功能和额度。网页版也可以运行Agent，桌面应用也可以只是聊天。对我有实际意义的是：这次任务究竟需不需要AI进入本地目录，并直接形成修改结果。
如果需要检索的国内信息比较多，我还会使用豆包、元宝、千问和DeepSeek。在我的实际使用中，它们主要用于国内信息检索和结果对照。
有些问题我也会同时交给多个AI检索和推理，再比较它们给出的结果。几个AI说法一致，不代表事实就一定正确（偷懒的话也可以认为大差不差），但不同模型给出的来源、思路和分歧，可以帮助我发现哪些地方还需要回到原始资料继续核验。
所以，网页版对我来说并没有退出工作流，只是从最初的主要入口变成了额度不足时的补充，也是国内信息检索和多模型交叉对照的入口。
移动端更适合记录、接续和查看
移动端和网页版的基本交互方式很接近，打开应用以后同样可以对话、上传材料和查看历史记录。它真正有价值的地方，是让我离开电脑以后还可以继续使用AI。
想到一个文章选题，可以先用语音或者文字记下来；临时收到一份可以上传的材料，可以先交给AI提取重点；离开电脑以后，也可以继续查看已有对话，补充一些临时想到的要求。
但持续比较多个文件、审查大量修改差异、维护长期目录或者处理复杂排版，仍然更适合在电脑上完成。
所以，我不会要求移动端完整替代电脑。它能够随时记录、接续和查看，已经足够有价值。现在越来越多Agent产品开始提供移动端，或者支持通过其他方式在手机上接续任务。
即便没有移动端，也可以通过通讯工具桥接的方式实现远程操作。例如，通过我已经配置好的桥接，手机上的钉钉可以向本地QoderWork发送任务，飞书也可以远程控制本地Codex。
CLI不应该成为法律人使用AI的门槛
CLI是Command Line Interface的缩写，通常译作命令行界面。简单来说，就是在终端里输入命令或者任务，再由程序返回结果。
Codex和Claude Code最初都以终端入口为主，桌面端或者其他图形界面出现得更晚。毕竟，这些AI工具一开始主要面向的还是程序员。对于已经习惯终端的程序员来说，CLI可以直接从当前目录启动任务，也容易与Git、文件搜索、脚本和其他命令组合起来，很多操作还可以被记录、复制和重复执行。
这些确实是CLI的优势，但现在不少桌面Agent已经能够自己搜索文件、运行命令和检查结果，用户不需要亲自敲出每一条命令，图形界面也会更加友好。
我一开始尝试Claude Code时，安装是安装上了，也跑通了，但确实用得不顺手。除了要知道自己在哪个目录、命令会影响哪些文件，还可能遇到环境配置和权限问题。对一个不熟悉终端的法律人来说，这些都是额外的学习成本。
如果CLI能够明显提高效率，当然可以学；如果桌面Agent已经能够完成同样的任务，也没有必要为了显得专业，强迫自己从命令行开始。对我来说，现阶段已经完全放弃CLI入口。
IDE提供的是长期项目视角
IDE是Integrated Development Environment的缩写，通常译作集成开发环境。传统IDE把项目目录、文件编辑、终端、调试和版本管理放在同一个界面里，AI进入以后，又增加了对话、局部修改、代码补全和Agent执行等能力。
IDE听起来像程序员专属工具，因为它最初就是围绕软件开发形成的。但“项目”并不一定只有代码。
文章、公众号排版规则、Skill、网页、脚本和Git版本记录，也可以共同组成一个需要长期维护的项目。文件之间存在关联，需要持续修改，还要不断查看前后差异时，项目视角就会产生价值。
不过，现在的桌面Agent也在提供类似的项目视角。使用Codex时，我同样可以把整个工作目录交给它，再检查它读了什么、改了什么。IDE不再是AI进入长期项目的唯一方式，只是它把文件编辑、版本差异和终端等工具更集中地放在一个界面里。
关于这类工具，我最开始只尝试过用VS Code作为项目入口，但它的操作方式和我这样的非程序员用户的使用习惯相差还是很远，所以我早就不用了。
选择入口，也是在分配任务、额度和权限
我现在不会给这些入口排出简单的高低顺序。一个入口能够接触更多文件、调用更多工具，不代表它天然更适合当前任务。
我目前的实际分工是：Codex承担大多数需要进入本地目录、持续推进和直接形成结果的工作；QoderWork在Codex额度不足或者任务较轻时补充；Google Antigravity主要处理Markdown转Word等特定任务；ChatGPT网页端承担不需要直接修改本地文件的问答和分析；豆包、元宝、千问和DeepSeek用于国内信息检索和多模型交叉对照；移动端负责记录、接续和查看；CLI和IDE目前已经不在我的日常入口中。
决定一项任务放在哪里，我会先看它最终需要什么结果。如果只是得到一个回答，网页端通常已经够用；如果需要直接修改本地文件，就交给桌面Agent；任务形成长期项目以后，还要考虑版本管理和项目环境。与此同时，还要看哪个产品有可用额度，是否值得为这项任务消耗更稀缺的Agent资源。
一个入口能够接触的文件和工具越多，通常意味着AI可以更深入地参与实际工作，也意味着用户交出的材料和权限更多。生产力工具是否划算，最终还是要看它多完成的那部分工作，值不值得付出额外额度、学习成本和管理成本。
四篇文章先把关于AI的这些基础概念讲到这里。本来想直接进入AI应用分享阶段，但思来想去，我觉得既然决定把AI当成生产力工具，还是有必要先把这些基本概念弄清楚。了解它能做什么、不能做什么，是决定把多少任务和权限交给它的前提。
接下来，科技专栏也该从概念回到实际应用了。这些工具到底能不能改善法律工作和个人生活，最终还是要放进真实任务里检验。AI可以辅助工作，更可以管理生活。