跳到内容
主题

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

用AI提升开发效率。代码生成、应用构建、调试和测试自动化的实用指南。

84 篇文章

排序文章以找到您需要的内容

AI开发与编程 分类下的文章

无法打开这个应用:Windows 版 Claude Desktop 启动不了——用“修复”解决,会话不会丢

无法打开这个应用:Windows 版 Claude Desktop 启动不了——用“修复”解决,会话不会丢

想打开 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。

API Error: Connection closed mid-response 的原因与对策——Claude Code 回答中途被切断

API Error: Connection closed mid-response 的原因与对策——Claude Code 回答中途被切断

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 的区分,以及「症状与对策已官方文档化,但原因的官方说明尚未给出」的确信度划分。

量化格式指南:GGUF vs GPTQ vs AWQ——该选哪个文件?

量化格式指南:GGUF vs GPTQ vs AWQ——该选哪个文件?

你打开 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/TGI);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 0x80070020:更新后无法启动的解决

Claude Desktop 0x80070020:更新后无法启动的解决

刚更新完 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 能削减多少开发工时?智能体时代的真实数据

AI 能削减多少开发工时?智能体时代的真实数据

"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」无限循环与「Response stalled mid-stream」错误——原因与对策

Claude Code 的「court」无限循环与「Response stalled mid-stream」错误——原因与对策

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 的区分。

API Error: 400 Output blocked by content filtering policy:原因与解决方法(Claude Code)

API Error: 400 Output blocked by content filtering policy:原因与解决方法(Claude Code)

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 的区分,逐一梳理。

个人开发的变现与定价 ― 拿下第一批付费用户的定价实践【2026】

个人开发的变现与定价 ― 拿下第一批付费用户的定价实践【2026】

很多人在个人开发里"东西做出来了,却卡在怎么赚钱、定价多少"。本文从个人开发者的视角实践性地梳理了:变现模式(免费/买断/订阅/免费增值/广告/捐赠)的选法,不看成本或竞品、而以"顾客获得的价值"为起点的基于价值的定价设计,免费→Pro→Business三档方案与年付折扣的标准打法,如何拿下第一批付费用户,以及把API token等AI成本算进去的采算。这是深挖母舰文章「用AI做个人开发路线图」中"养育阶段"的一篇。

用AI一个人做MVP实践指南 ― 收敛到1个功能、最快公开的步骤【2026】

用AI一个人做MVP实践指南 ― 收敛到1个功能、最快公开的步骤【2026】

个人开发做不完的最大原因是"做得太精细"。这个也加那个也加,越做越复杂,最终没公开就消失了。避免它的唯一方法,是把能传达价值的最小产品=MVP收敛到1个功能、以最快速度公开。本文以AI为搭档的个人开发者视角,讲解MVP的正确理解、砍功能的范围判断、用AI最快做出来的两条路(不写代码的氛围编程/用AI编辑器写代码的实战)、如何判定"完成",以及公开出去让1个人用起来的全过程。

用AI做个人开发的完整路线图【2026】——从想法到发布与变现

用AI做个人开发的完整路线图【2026】——从想法到发布与变现

当AI拥有了"写代码的手",一个人也能做出产品推向世界的时代来了。但信息按工序散落各处,容易不知道该从哪儿下手。本文是从想法→设计→实现→发布→变现的全局地图(路线图),把个人开发整理成"确定→做准备→开发→发布→运营"5个阶段,给出每道工序做什么、用哪个工具,需要深入的工序则指向单独指南,是一篇母舰(枢纽)文章。而且用几乎不写代码的🌱入门路线和用AI编辑器写代码的🔧实战路线两条道来引导,沿着适合自己的那条走就能不绕远路地做出能跑的东西。规格驱动、AI应用构建器、Claude Code/Cursor、AI功能集成(API/RAG/网关)、部署、SEO/AEO获客、变现、成本管理,直到一人开发×AI的5个坑,都汇在一页里,并附有通往现有实操指南的入口。

Claude Code 的每周限额真的每 7 天重置吗?调查"提前恢复"现象(2026 年 7 月)

Claude Code 的每周限额真的每 7 天重置吗?调查"提前恢复"现象(2026 年 7 月)

你触及了 Claude Code 的每周 token 限额,但还没到七天额度就完全恢复了——而且不止一次。网上甚至有"隐藏机制"的分析文章,声称每周限额每 72 小时重置一次。这是真的吗?本文把这个现象追溯到一手来源。但 Anthropic 并未记录内部重置机制,且限额一直在变,因此我们明确区分三类信息:可从官方来源确认的事实、多名用户可复现地观测到但 Anthropic 从未回应的现象,以及单一来源、未经证实的推测。核心结论:提前完全恢复在大多数情况下是 Anthropic 不规律的全员重置(@ClaudeDevs 反复宣布过);显示的重置时间也确实不稳定;而流传的"72 小时周期"为单一观测者、未被复现,且被另一处观测(24 小时)所矛盾,因而不能当作事实。凡是不能陈述为事实的,我们都会直说——一份 2026 年 7 月的调查。

什么是 LLM 网关(代理)?一个 API 触达所有提供商——2026 指南

什么是 LLM 网关(代理)?一个 API 触达所有提供商——2026 指南

你基于 OpenAI 把应用搭好,后来想试 Claude、比一比 Gemini——却因为每家提供商的 SDK、格式、错误处理各不相同而白白耗掉数小时。LLM 网关(AI 网关 / LLM 代理)是你塞在应用与各提供商之间的中转层:它对外暴露一个兼容 OpenAI 的 API 以触达所有模型,并接管那些横切性的杂活——回退、成本追踪、虚拟密钥、缓存、限流与可观测性。本指南讲清为什么需要它、网关到底是什么、三种类型(自托管代理 = LiteLLM / 托管 = OpenRouter / SDK = Vercel AI SDK)、如何在 LiteLLM、OpenRouter 和 Vercel AI SDK 之间取舍、只需换端点的最小配置代码,以及它的局限——一跳延迟、网关成为新的故障点、费用(OpenRouter 充值时收 5.5%)、功能损失与隐私。