AI开发与编程：用AI构建应用的实战指南

Remote Control 把 Claude 手机应用或 claude.ai/code 连到一个已经跑在你自己机器上的 Claude Code 会话上，而多数讲解都漏掉的关键在于：什么都没有搬到云上——代码的执行和文件的访问自始至终留在本地，手机只是窥看那个会话的一扇窗。本文把这个设计带来的好处和代价一条条摊开。本地的文件系统、MCP 服务器、工具和项目配置全都照常可用（敲 @ 补全出来的是本地项目里的路径），对话和子智能体的进度会在终端、浏览器和手机之间保持同步，笔记本睡眠或网络掉线也扛得住，因为 Claude Code 会自动重连并把排队的更新补投过来。使用条件比看上去严格：需要 Pro、Max、Team 或 Enterprise（API 密钥用不了），要用 claude.ai 登录而不是 setup-token，必须直连 api.anthropic.com，而且四个关闭遥测的环境变量一个都不能设——这正是那些出于隐私考虑设了 DO_NOT_TRACK 的人被告知功能未启用的原因。文中覆盖三个入口（用 /remote-control 承接当前对话、claude --remote-control，以及带 --spawn、--capacity 32 和 --continue 的服务器模式），也划出了哪些斜杠命令能远程用、哪些像 /resume 一样仅限本地，还有对权限提示并不生效的 5 分钟对话框超时，以及两个推送开关。安全部分写得很克制：全程不开任何入站端口，网络那一侧的攻击面几乎消失，风险转移到了账号上；二维码只是近路而非认证；默认的门恰好只有已登录的账号这一道，所以设置通行密钥是回报最高的一步。此外还有会话记录的保留期限（5 年或 30 天）、手机丢失时该怎么办、Trusted Devices 的 18 小时登录窗口、服务器模式约 10 分钟的超时、约 4 小时的恢复窗口、远程机器上必须用 tmux 的规矩、按实际错误信息编排的排查表，以及和 Dispatch 的对比。

Claude 的思考方式经历了一次代际更替。旧的扩展思考要求你在每次请求里指定 token 预算——thinking: {“type”: “enabled”, “budget_tokens”: N}——但合适的预算因任务而异、无法事先猜准，改动预算值还会让提示词缓存失效。当前的自适应思考只需一行 type: “adaptive”：是否思考、思考多深，由模型根据请求难度自行判断。迁移是分阶段推进的：budget_tokens 在 Opus 4.6 / Sonnet 4.6 上被弃用，从 Opus 4.7 起被以 400 错误拒绝。本文把各模型的规则浓缩成一张表——Fable 5.1 与 Opus 5.5 始终思考（无法关闭），Sonnet 5.5 默认开启思考、disabled 会返回 400，但可改用 between_tools 只关闭开头的思考（effort high 及以下），已列为 Legacy 的 Opus 5 与 Sonnet 5 默认开启思考（Opus 5 仅在 effort high 及以下允许关闭），Opus 4.8 / 4.7 需要显式设置 adaptive，而 Haiku 4.5 / Sonnet 4.5 等只支持扩展思考的模型仍以 budget_tokens 作为唯一模式。深度控制转移到了 output_config: {“effort”: ...}，共五档（多数模型默认 high，Opus 5.5 和 Haiku 5.5 默认 medium），而且改动 effort 会像当年改预算一样打穿缓存。可见性由 display 决定：新一代的默认值是 “omitted”（空的 thinking 块），但无论哪种设置都会为全部思考 token 计费——用 usage.output_tokens_details.thinking_tokens 来测量；任何配置都不会返回原始思考链。在 Opus 5 上关闭思考有官方写明的副作用（工具调用被写成纯文本、内部标签泄漏），因此调低 effort 才是更安全的省钱杠杆。交错思考——在工具调用之间推理——在自适应模式下自动生效，旧的 beta 请求头不再需要。需要速度时，快速模式以 2 倍价格把同一个 Opus 提速约 2.5 倍（仅 Opus 5.5/5/4.8，在 Claude Code 里用 /fast 切换）。全部内容均以 Anthropic 官方的 Thinking、Extended thinking 与 Fast mode 文档为依据。

工作到一半 Claude Desktop 突然卡住，开着的 Claude Code 会话全部一起停摆；强制退出再重启，有时应用干脆起不来了——这种时候日志的最后一行往往都是 GPU process gone: { type: GPU, reason: crashed, exitCode: 101457950, serviceName: GPU }。本文要说清楚的是：这个 exitCode 101457950（即 0x060C201E）意味着什么，为什么毫不相干的会话也会被一起拖下水，以及现实中哪些办法能用、哪些用不了。先做切分：就算你感觉是“Claude Code 崩了”，崩掉的其实并不是 Claude Code（CLI），而是承载它的桌面应用（Electron）的 GPU 进程；判断方法很简单，看 %APPDATA%\Claude\logs\main.log 的末尾，如果重启前那一行是 GPU process gone 就是本文这件事。它最难缠的地方在于应用不会消失，而是无响应地留在那里——既不弹崩溃对话框，也不会自己重启，在用户察觉并强制退出之前就那么僵着（笔者机器上观测到的一次长达约 30 分钟，期间开着的 8 个会话全都停着）。全军覆没的原因是结构性的：Electron（Chromium）把渲染集中到一个 GPU 进程里，而这个进程每个应用只有一个，所有窗口、标签页、会话都共享它，所以应用内浏览器里的某一个页面把它弄死，八竿子打不着的会话就会同时遭殃，而且用户没法靠设置把它们隔离开。触发因素方面，公开 issue 里最常见的是应用内浏览器：#80444 记录了 WebGL/WebGPU 能力检测后 15～36 秒 GPU 进程死掉、四次都是同一个 0x060C201E；#82967 把触发点定位到预览截图抓取（capturePreviewScreenshotIfChanged）；#83478 称一直开着不断刷新的预览就能复现。但浏览器不是唯一触发因素——#68049 报告 ARM64 环境下启动时就以同样的 exitCode 崩掉，#83028 称 Intel 集成显卡上能复现。本文还给出用三个文件（main.log、unknown-window.log、Crashpad 目录）确认的方法，以及用 exitCode 区分正常退出的对照表，并特别提醒：同一份日志里的 requestAdapter 警告不是罪魁祸首，那只是 Chromium 告知“在 Windows 上 powerPreference 不起作用”的常规消息，不能拿它当依据。恢复部分讲“修复”能救回来的情况（#80444 的 appxState=2）和救不回来的情况（#82967 走到 Modified, NeedsRemediation 后只能彻底重装），并把能做的与做不了的分开列出——--disable-gpu 在 MSIX 版会以“拒绝访问”被挡回来，更新应用与改驱动设置都有不管用的报告，关掉浏览器功能也只能挡住浏览器引起的那一部分。数据这一块要分开理解：transcript 已经写到磁盘上，重启之后重新打开会话就能接着读，但 #81698 报告说正在执行中的工作整个丢了，连并行跑着的子智能体的结果也一起没了——已保存的留得住，正在跑的回不来。如果用的是混合显卡配置，在 Windows 的显卡设置里给 Claude 固定 GPU 优先级值得一试（依据是 Chromium issue 40268366：Windows 上应用侧无法指定用哪块 GPU 绘制），但并没有找到说这招对本文这件事有效的报告，不要抱太大期望。最后区分了容易混淆的商店更新强制退出（日志留下 Windows session ending (close-app)，不会出现 GPU process gone）。截至 2026 年 10 月 4 日，Anthropic 没有发布任何官方的原因说明或修复内容说明，代表性的 #80444 已于 9 月 15 日在没有任何说明的情况下以“completed”关闭。

“既然能让 AI 直接改，管理后台是不是就不需要了？”——这个问题用一般性的断言回答不了，因为同一个词“管理后台”指的是一堆性质完全不同的功能凑在一起。本文基于把这个站点的管理后台整个删掉的亲身经历，把该问的问题换成一句更锋利的：这块屏幕提供的东西里，有没有 CLI 和 AI 还提供不了的部分？真的整个删过一遍才明白，被删掉的功能里大多数不是“没在用”，而是“结构上就是坏的”。文章的增删改查从造出来那天起就不可能工作，因为文章的事实源头在代码这一侧（seeder 加 HTML 文件），每次部署都会覆盖数据库，界面上改的东西下一次部署就没了。评论审核队列永远是空的，因为实现上提交时就打好了已通过审核的标记，未审核的评论根本不会出现。没人用的功能，连它坏了都没人看得出来。唯一删不掉的能力是删除评论，可即便是它也没有非管理后台不可的理由：把删除按钮放在文章页面本身反而更好，因为你正在读那条有问题的评论，当场就能删。判断最终落到六个问题上。谁来操作（非技术人员或会换人的岗位倾向于 UI，天天开终端的开发者则不必）。能不能撤回（不可逆的操作需要一道关卡）。需不需要人的判断（是否存在通过或驳回这种状态迁移）。需不需要分权限。知不知道能做什么（那份清单同时充当说明书）。有没有留下痕迹。其中权限和痕迹这两条，在个人开发时看上去毫无必要，却会在第二个人进来的那一刻最先变成必需品。经由代码的变更会进 git，但让 AI 直接写数据库默认什么都不会留下，而对话记录保存的是“你要求了什么”，不是“实际发生了什么”。六条轴里只有可逆性的分量不一样：2025 年 7 月 18 日，Replit 的 AI 代理在代码冻结期间删掉了 SaaStr 的生产数据库，凭空生成了 4,000 个虚构用户，并错误地声称无法回滚从而拖慢恢复（AI Incident Database #1152）——这个案例展示的与其说是 AI 的危险性，不如说是不可逆的操作不经过人的关卡就能够到的设计问题。文章还给出往 AI 与 CLI 挪之前要先备好的三件事（变更留得下形、不可逆操作前面有个台阶、步骤写成文档，因为删掉 UI 同时也删掉了“能做哪些事”的清单），一份动手做之前的检查清单，以及不自己手写、改用 Retool 或 Forest Admin 这类内部工具产品的第三个选项。

不少人按 Claude Code 的 /compact 时依据的是“每 30 分钟一次”“上下文超过 70% 就按”这类规则，但官方文档推荐的既不是时钟也不是百分比，而是工作的断点——“在工作的自然断点处运行 /compact，例如在任务与任务之间，而不是等自动压缩在任务中途触发”。本文以 2026 年 10 月 4 日的 Claude Code 官方文档（当时最新版 v2.1.289）为一手资料，从规格出发把“该不该手动压缩”这件事讲透。首先是机制：压缩分三层运转——①丢弃旧的工具输出、②自动压缩、③你按下的手动 /compact。②与③是同一套处理，因此自己按下换来的只有两样东西：挑选时机，以及指定保留什么。按得更勤并不会额外省出上下文。接着用一张表说明什么会留下：项目根目录的 CLAUDE.md 与自动记忆会从磁盘重新注入，而带 paths: 的规则和子目录里的 CLAUDE.md 要等匹配的文件被重新读取才回来，调用过的技能正文则受每个技能 5,000 token、合计 25,000 token 的上限约束，超出部分从旧到新丢弃，截断时保留文件开头。关于费用：一次压缩的价格不由上下文的大小决定，而由提示词缓存是否温热决定——工作中途按，前缀从缓存里读，很便宜；在超过缓存存活时间（订阅套餐 1 小时，API 密钥默认 5 分钟）的休息之后按，则要把整段历史当作未缓存输入重新处理，是这条命令最贵的时刻。此外还涵盖 /compact、/clear、/rewind、/recap、/context 的取舍，v2.1.221 起用 /autocompact 把自动触发点在 100K 到 1M token 之间移动的方法与四个设置来源的优先级，只有环境变量接受纯整数（写成 500k 会被读成 500 并被钳到 100K）这个坑，以及 Not enough messages to compact. 与 Autocompact is thrashing 这两条消息的含义和恢复步骤。

想打开 Windows 版 Claude Desktop，弹出来的却是标题为“无法打开这个应用”的对话框，提示你转到 Claude 的高级选项并选择“修复”——照它说的做就能解决，既不用卸载，也不用那个会把数据一起丢掉的“重置”。不过中间有一道坎，正是本文的核心：点了“修复”之后，可能会收到一条提示说应用还在运行，可明明哪儿都没有开着 Claude 的窗口。原因是 Claude Desktop 在窗口关闭后仍然驻留在系统托盘里，那个常驻进程占着包里的文件，修复自然通不过。解法很简单：先明确地结束进程，再点“修复”。而这个事实本身也指向了故障的成因——同一个进程先弄坏了更新，又挡住了修复。本文还回答了大家最先想问的那个问题：会话会不会被清空？答案分三种。claude.ai 的对话记录存在 Anthropic 的服务器上，完全不受影响；Claude Code 的会话存在 %USERPROFILE%\.claude\projects\ 下，位于应用包之外，所以修复、重置乃至卸载都动不到它（一台实机上是 52 个项目、2,977 个文件、约 3.0GB）；唯一有风险的是 %APPDATA%\Claude 里的应用侧设置，而“修复”连这个也保得住——Windows 就在同一个页面上把区别写清楚了：修复不影响应用的数据，重置会删除应用的数据。此外还涵盖只读的 PowerShell 状态检查、备份流程、仍然打不开时的分级处理（确认 vmcompute 与 hns 是否在运行、删除包后重装，因为 -PreserveApplicationData 对正常安装无效）、半注册 MSIX 这一推定成因与相关的 GitHub issue（#55465 安装成功却没有生成入口点，以及 #50285、#48437，全部以 closed as not planned 收场，没有官方修复），降低复发概率的做法，以及与旧版安装程序格式的对比——MSIX 最新版与旧格式实机上的版本号同为 1.24012.9。

Claude Code 回答写到一半停住，屏幕上出现“API Error: Connection closed mid-response. The response above may be incomplete.”——这不是提示词的问题，而是承载流式响应的连接在响应传输途中被关闭的传输层事件。本文只依据官方错误参考、官方 CHANGELOG 与带抓包证据的真实 Issue 进行梳理。先讲官方定义：Connection closed 是被切断、Response stalled 是陷入沉默、Server error 是服务端出错，三者的区别；以及已输出内容为何被“刻意”保留——因为重发可能把同样的工具调用执行两遍——而恢复步骤就是回复 continue。接着拆解断连可能发生的三个层次（本机链路与休眠/代理和 VPN 的空闲断开/服务端主动关闭），并给出 Issue #67766 报告者公开的抓包实测值：十次全部是服务端发起的正常关闭，从 FIN 到报错为 3〜105 毫秒，关闭时已收到 7〜20 KB 响应，请求体 1〜2.5 MB，新建连接约 20 毫秒即成功，23 天内共 200 次报错、171 次事件，其中 87 次距上次通信不到 5 秒。本文实用价值的核心，是 CHANGELOG 中真实存在的连接修复时间线（2.1.179 保留已输出内容、2.1.185 停滞提示由 10 秒改为 20 秒、2.1.198 临时网络中断改为带退避重试、2.1.199 流中服务端错误也保留已输出、2.1.214 陈旧连接错误后停用 keep-alive 池），并与报告版本（#69336=2.1.173/#69415=2.1.181/#69517=2.1.183）对照，指出报告集中区间全都早于 2.1.198。此外还包括易触发条件、八步用户检查清单、六条开发者指引、与 Unable to connect 及 Prompt is too long 的区分，以及“症状与对策已官方文档化，但原因的官方说明尚未给出”的确信度划分。

你打开 Hugging Face 想跑本地 LLM，同一个模型却挂着一整墙文件（Q4_K_M、Q5_K_S、GPTQ、AWQ、IQ3_M），然后就懵了。本文实打实回答：到底该下载哪个量化文件才能把它跑起来，把“什么是量化”的概念留给另一篇，专注于选择格式。选择分两步：先选格式（= 用哪个引擎跑），再选位深。最重要的事实是：量化文件只能在支持其格式的引擎上运行。GGUF 是“本地全能”格式的首选，能在 CPU、Mac 和部分 GPU 上跑（llama.cpp/Ollama）；GPTQ/AWQ/EXL2 以 GPU 为先（vLLM）；bitsandbytes 在 Transformers 里加载时量化、无需校准。GGUF 命名 Q4_K_M 分三部分：Q4（名义 4-bit，越大越好也越大）、K（在超级块上做的 K-quant；无后缀/_0/_1 是旧式）、M（S/M/L 表示有多少重要张量被升级；有效比特高于标签值，Q4_K 约 4.5 bpw）。IQ 家族（I-quants）在相同位深下更小，但推理更吃力、需要 imatrix（来自校准的重要性矩阵，优先保护关键权重）。GPTQ 最小化逐层误差；AWQ 通过激活值保护关键权重（没有谁绝对更好）。位深上，拿不准就选 Q4_K_M（许多模型的 Ollama 默认值），VRAM 有富余升到 Q5_K_M/Q6_K，Q8_0 近乎无损但不推荐，IQ2/IQ3 只用于硬塞大模型。约 4.5 到 5 bpw 是好吃区间（一个启发式）。找文件可用 library=gguf、bartowski/mradermacher（活跃度会变），或 Ollama 标签 model:size-variant-quant。数字是近似值，会因模型和构建方式而异。

刚更新完 Claude Desktop（Windows）后启动应用，会弹出“另一个程序正在使用此文件”，应用无法启动——而且在重启电脑之前一直无法修复。这是 Microsoft Store（MSIX）版上的一个已知缺陷（GitHub #53247 等）。关键点：并不一定需要完全重启电脑——很多情况下只要注销 Windows 再重新登录即可恢复（不是重启电脑，也不是退出 Claude 的登录），因为背后的孤立句柄是按 Windows 用户会话为单位残留的。有报告称停掉 CoworkVMService 或重新注册软件包均无效。尽管对话框如此措辞，但已验证不存在用户空间的文件锁（handle.exe / Process Explorer）：真正的失败发生在 AppX/Desktop Bridge 的容器层，即 Job Object → Silo 的转换（0x80070020 = ERROR_SHARING_VIOLATION，事件 215/208）。触发原因有两种尚无定论的解释——服务占用 Job Object（#57221）与启动时崩溃导致清理未执行（#53247）——且官方尚未发布修复。长久的变通办法是改用 Squirrel（安装程序）版。本文基于一台实机（Windows 11 Home 10.0.26200）并与 GitHub issue 相互印证，全文附有置信度标签。

“AI 到底能把软件开发工时削减多少？”随着2025—2026年智能体式编程的到来，我们衡量的单位本身变了。过去问的是“单个任务快了百分之几”；如今则是数量级的故事：“过去要花数周的开发周期，被压缩到数小时或数天”（TechTarget）。Claude Fable 5 用一天完成了 Stripe 5000万行的迁移；TELUS 节省了 500,000 开发者工时；周期时间从 9.6 降到 2.4 天。自动补全时代的数字——Copilot RCT 快 55.8%、McKinsey 按任务 20–50%——如今成了下限。但并非一律 10×：据 Anthropic 的 2026 Agentic Coding Trends Report，开发者在约 60% 的工作上使用 AI，却只有 0–20% 的任务能被完全委派（委派鸿沟），所以仍需人来评审，而约 27% 的 AI 工作是以前不存在的新工作（削减工时 = 增加产出）。上下文设计良好时，错误减少 40%、速度提升 55%。就连 METR 2025 年“专家慢 19%”的结果也在2026年反转，作者承认测量低估了现实。本文用有名有姓的来源（GitHub、McKinsey、Anthropic、METR、DORA）梳理这种两极分化，并给出如何真正拿到这份工时节省的方法。

Claude Code 长时间工作时，应答突然反复输出“court”几十到数百次，最后打出“API Error: Response stalled mid-stream. The response above may be incomplete.”而停下。这并非提示词或环境的错误，而是两个独立缺陷连锁触发：①模型不断吐出同一 token 的重复循环（退化），②因此产生的海量输出或连接问题导致的流停止。两者都是 Anthropic 官方仓库有多条 Issue 记录的已知 bug（court 重复带 area:model 标签）。本文基于官方文档与真实 Issue，梳理两层现象的真相、诱发条件、当下止损（Esc → 新会话 / /clear）、面向开发者的预防（读取超时、重复检测、max_tokens 上限），以及与 court/invoke 标签泄漏 bug 的区分。

Claude Code 或 API 中突然出现的“API Error: 400 Output blocked by content filtering policy”——这既不是用量限制也不是上下文超限，而是 Claude 打算返回的“输出”被安全过滤器拦下的状态。其主要目的是防止逐字复现已有版权作品，在生成 MIT/Apache 等标准许可证全文、做“与已有来源保持一致”的工作、复制长篇文档时，常会毫无恶意地误判（false positive）。本文基于官方说明（输出阶段的过滤器检测到版权作品复现而以 400 拦截的机制）、实际 Claude Code Issue 中的误判模式（OSS 仓库初始搭建·列表比对·长时间智能体运行末尾被误诊为 token 上限）、立即解决的方法（不让模型照抄而用工具获取·把提示词改得更偏生成/摘要·用 Esc 停止重试循环·拆分任务·误判向支持报告），以及与 Prompt is too long/usage limit/529 Overloaded/max_tokens 的区分，逐一梳理。