“是不是骗局”这个问题我不太想回答。它把一个工程问题变成了道德判断，而工程问题的答案通常在细节里：它在什么任务上有效，在什么任务上无效，代价是多少。
我也不太相信”生产力革命”这种说法。革命这个词要求结果是普遍变好，而我的实际体验是局部变好、局部变差，取决于任务形状。这种结论不好卖，但它更接近我看到的。
我在自己的机器上跑了两小时，接了云端模型，全程在容器里。样本很小，不足以支撑任何普遍结论，但足够让我形成几个判断，也足够让我改掉几个用法。
我先说测试结果
两个任务。
第一个是把下载目录里三百来个文件按项目和时间归档。里面有 PDF、截图、半个改到一半的表格、还有几个名字是乱码的压缩包。它用了不到三分钟，分类基本对，重命名规则也守住了我给的约定。这一步它确实比我自己快，而且快得不是一点。
第二个是在一个 Node 项目里审一个 PR。我在里面埋了一个异步边界导致的泄漏——一个 await 写在了不该写的位置。它扫完 diff，给了一堆关于命名和结构的建议，都没错，但完全没看到那个问题。
我提醒它”这里可能有异步相关的问题”，它开始改。第一次改出一个编译不过的版本，第二次又引入了未定义的变量，第三次开始猜测上下文，每次都在把更长的日志塞回自己的输入。二十分钟后我按了停。
我也试了几个模糊指令，比如”把这个项目收拾一下”。它的反应是列一份计划：整理目录、补 README、统一命名、跑一遍 lint。每一项都合理，合起来是三个小时的工作量，而我要的其实只是把根目录那几个临时文件删掉。模糊指令的代价不是它做错，是它做得太多，而且每一件都要花我的验收时间。
它在有明确成功标准的任务上很强，在需要判断”什么重要”的任务上很弱。这和提示词写得怎么样关系不大。
我不觉得这是模型的智力问题。它没有我的业务上下文——不知道这段代码上次为什么改成这样，不知道哪个调用方不能动，也不知道这个 PR 背后是一次线上事故。这些东西没写在仓库里，也没法写进提示词。
把两个任务放在一起看，差别不在难度，在成功标准能不能被判定。整理文件这件事，结果是可验证的：每个文件落在哪个目录，命名是否符合约定，一眼能看出来。审代码这件事，结果是”发现了一个我没发现的问题”，它的成功标准不在任务描述里，在任务之外。没有这个标准，它就退化成给建议——而给建议这件事，它做得还不错，但那不是我要的。
这两种失败的表现也不一样。整理文件那次如果出错，我会立刻看到某个目录里堆着不该在的东西。审代码那次没找到 bug，界面上一片正常，它给了六条建议，每条都合理。这种”看起来在工作”的失败最危险，因为它不触发任何警报，需要我自己有能力发现它漏了什么。一旦我失去了这个能力，它就成了黑箱。
账单贵在重放，不在调用
第一次看账单时我以为是单价高。后来把每一步的用量拉出来看，才发现不是。
agent 的每一轮都要重新带上系统提示、历史对话、工具输出和文件片段。步数一多，单次调用的输入是滚雪球式的。一个失败的任务往往比一个成功的任务贵好几倍，因为它会重试；失败是最贵的产出。
我的做法有四条：
- 单任务设步数上限，超了直接抛错，不让它”再想想”
- 每个任务单独记一份用量，攒一周看一次
- 在供应商后台设硬性月度上限，这条最有效，因为它不依赖我盯着
- 关掉后台的定时任务，除非我能说清楚谁在看结果
最后一条听起来和成本无关，其实关系最大。我一度挂了一个每小时抓一次行业动态的任务，跑了两周。它花的钱不算多，但我一次都没看过它产出的东西。这类”闲置自动化”最容易被忽略，因为它不报错，只是安静地烧。
记账之后还发现一个规律：涉及浏览器的任务，成本是文件处理类的五到十倍。原因不复杂，截图和多轮导航都在重复付费。所以我把它从”什么都能干”收窄到”只干几件成本可预测的活”。
现在我判断一个任务值不值得交给它，会先估一个数：我手动做要多久，它跑起来大概几步，每步的输入有多长。三个数乘起来，如果成本超过我时薪的一半，我就不交了。这个算法很粗糙，但它挡住了大部分冲动——尤其是那些”看起来能自动化”、实际只是把一次性动作变成持续支出的任务。
降级模型这件事我试过，没成功。想法很合理：简单步骤用小模型，卡住了升级。实际跑起来，小模型在工具调用的格式上反复出错，于是每一轮都升级，最后比一开始就用大模型更贵，还多花了一倍时间。我放弃了自动降级，改成按任务类型硬分配——文件类的固定用小模型，跨文件推理的固定用大的。判断写在配置里，不让它自己决定。
把时间折算成钱，账其实挺难看。整理一次文件省我四十分钟，按我给自己算的时薪，大概一顿饭的钱。但如果加上配置、维护、看日志、写上限的时间，前两周是净亏的。回本要靠复用的次数，而我一周只用两三次。所以这笔账在财务上不成立，成立的部分是别的：我在这两小时里弄清楚了工具调用是怎么回事，上下文是怎么累加的，权限边界该划在哪儿。这些认知可以迁移到别的项目上，那部分钱不好算，但我愿意付。
权限是唯一不能谈的部分
一个能执行命令的东西，风险不在它笨，在它听话。
我遇到的三种情况：第一，它读进来的内容会变成指令。我让它读一批网页并做摘要，其中一页的正文里写着一句”清理缓存目录”，它就把这个动作排进了计划。第二，它修依赖报错时会自己执行安装，装了什么、从哪装的，我事后才从日志看到。第三，它默认会读很多上下文，如果目录没有限制，那份上下文里可能有密钥。
这三件事都不需要模型有恶意。它只是在尽力完成被交代的目标。
我的规矩很笨：容器、只读挂载、不挂 ssh、key 单独申请、禁止自动提交。看起来麻烦，但它的成本是一次性的，而一次误删的成本不是。
具体一点：容器只挂两个目录，一个给它写的草稿区，一个只读的代码区；容器里没有任何 git 凭证，提交由我来做；网络只放行模型 API 的域名，其他出站一律断掉。最后这条最麻烦，我为了让它能装依赖折腾了半小时，后来干脆放弃了——它不需要联网装东西，需要什么我先装好。
我吃过一次亏，幸好代价小。它整理一个工作目录时，把一个叫 tmp_backup 的文件夹判断为临时文件，计划整体删除。那个目录里其实有我一版还没入库的手稿，名字起得确实像垃圾。我在确认弹窗上看到了，所以没执行——但那次之后我把所有”看起来像临时文件”的目录都挪出了工作区。这类事故的根源不是它判断错了，是它只能靠名字判断，而名字是我起的。
这条规矩的代价我得说清楚：它的能力被砍掉一截。不能装依赖，意味着遇到缺包只能等我；不能访问内网，意味着有些任务根本做不了。我接受这个交换，因为我用它的场景本来就不需要这些。
还有一个我慢慢意识到的点：确认机制会疲劳。前几次它要删文件，我认真看；到第二十次，我发现自己已经在无脑点同意。人对重复的确认会脱敏。所以我把高危命令直接禁掉，而不是依靠我保持警惕。不需要我保持警惕的机制，才是我信任的机制。
边界在哪里
我见过不少把它和编辑器里的助手放在一起比的文章，比开箱体验、比价格、比安全。这些维度没错，但结论通常没意义，因为两者解决的问题不同。一个是在编辑器里改代码，一个是操作系统。
真正的区别是错误由谁承担。编辑器里的助手改错了，我在 diff 里看见，不合并就行。系统级的 agent 改错了，可能已经提交了，或者已经删了东西。前者是建议，后者是行动。
我的分工是这样：日常写代码、重构、读别人的仓库，用编辑器里的助手；跨应用的脏活——整理文件、跑一遍十几个网页、把几个仓库的版本对齐——才交给 agent。两者不重叠，也不需要谁替代谁。
有一点值得说：agent 的问题不是能力不够，是不可预测。同一个任务，今天成功，明天可能卡在第三步。这种不确定性对个人折腾无所谓，对生产流程是致命的。所以我从来不让它进任何有人等着结果的环节。
我试过一个看起来很适合它的场景：在 CI 里让它在测试失败时自动修 lint。跑了三天，成功率大概一半，另外一半是”改了一个地方，另一个地方坏了”。更麻烦的是它留下的提交信息很自信——“fix: resolve linting issues”——但改了什么，我得自己看。后来我把这一环去掉了，换成一条明确的失败提示。机器该失败的时候就该失败，让人来修，比让人去审一堆自动提交便宜。
我不认为它是骗局，也不认为它是革命。它是一个权限很大的半成品，而半成品的价值取决于用它的人愿意付多少调试成本。
这个成本我算过：配置、日志、上限、回滚方案，加起来大概两个晚上。只是想省下整理文件的时间，两个晚上换每周二十分钟，不划算。本来就想搞清楚这类系统怎么工作的，那两个晚上很值。
它现在还在我机器上，用的频率比我预期低。我没有卸载它，因为偶尔遇到”要跑十几个网页然后汇总”这种事，它还是比我自己点快。但我也不再期待它能替我做完整件事。
我还在观察一件事：这类工具的瓶颈到底在模型能力，还是在”人愿不愿意信任一个不确定的东西”。如果是前者，明年这个时候它会好很多；如果是后者，那就不是模型变聪明能解决的。我倾向后者，但我希望自己猜错。
这个期待值的调整，大概是我从这两小时里得到的最有用的东西。
评论