鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
9
3
11

Claude Code 全攻略：命令大全 + 实战工作流（建议收藏）

兮动人
兮动人
2026-04-08 00:19
阅读 3371
兮动人
2026-04-08 00:19
阅读 3371

在这里插入图片描述

1. Claude 常用命令

  • 查看版本：
▼
bash
复制代码
claude --version

在这里插入图片描述

  • 启动交互界面（当前目录）：
▼
bash
复制代码
claude
  • 指定目录启动：
▼
bash
复制代码
claude /path/to/project
  • 升级到最新版本
▼
bash
复制代码
claude update

2. Claude Code 界面说明

  • 左下：模式指示器 Default / Accept Edits / Plan Mode，Shift+Tab 切换模式

1、Default（默认模式） — 每次编辑文件或执行命令都需要你确认 2、Auto-Accept（自动接受模式） — 文件修改自动执行，无需逐一确认（但 shell 命令仍需确认） 3、Plan（计划模式） — 只读模式，Claude 只分析和规划，不做任何修改，等你审核计划后再执行 Skill-gallery、

  • Claude Code 底部状态栏显示的不同状态

在这里插入图片描述

1、默认模式 在这里插入图片描述 2、自动接受模式 在这里插入图片描述 3、计划模式 在这里插入图片描述

  • 对话中：工具调用 Claude 读文件、写文件、执行命令的详情嵌入在对话流中

  • 中间：对话输入框 自然语言输入需求，支持Markdown，可拖拽文件/图片

  • 底部：快捷键提示 Ctrl+C 中断· Ctrl+B 后台· ESC 返回/取消

  • 输入 ? ，显示一些快捷键 在这里插入图片描述

3. Claude 常用指令速查

  • Claude Code 指令 / 快捷键参考
指令 / 快捷键作用典型场景
/compact压缩对话上下文，保留核心摘要对话过长 token 超限时
/clear清空所有对话历史，全新开始切换到完全不同的任务时
claude -c启动时恢复上一次对话次日继续昨天未完成的工作
Ctrl+B将当前任务挂到后台运行让 AI 后台编译，前台讨论下一步
ESC×2 (/rewind)回退或总结（回滚 AI 操作）AI 改错了代码，快速撤销
↓ / /tasks管理后台任务（查看/停止）检查后台编译/测试是否完成
Ctrl+T显示/隐藏任务列表面板查看 Claude 创建的任务进度
Alt+V粘贴图像（Windows）截图粘贴给 Claude 分析 UI/报错
/memory打开并编辑 CLAUDE.md修改项目规则或个人偏好
/init自动生成 CLAUDE.md 初稿新项目首次接入 Claude Code
/hooks配置工具钩子（自动化触发）写文件后自动 prettier 格式化
\+Enter输入框内换行（不发送消息）输入多行代码或多段需求描述时
Shift+Tab循环切换三种工作模式从 Plan Mode 切到 Accept Edits 执行
  • claude code 读取图片信息处理机制

在这里插入图片描述

4. Claude Code 的命令行输入

  • Claude Code 是 Anthropic 推出的终端 AI 编码助手，在交互界面中通过 斜杠命令（Slash Commands）来控制 AI 助手的行为和上下文，合理使用斜杠命令，配合自然语言输入更加顺利完成开发操作。

在这里插入图片描述

Calude Code 执行初始化命令

  • 在使用Claude Code的时候，一般都会首先添加工作目录。这里一般通过一个斜杠： /来表示输入指令。这里输入如下指令选定工作目录
▼
bash
复制代码
/add-dir <你的工作目录>
  • 在创建工作目录后，使用初始化工具对该目录下的项目进行初始化分析，生成一份CLAUDE.md文档。这个文档的作用是建立上下文，让Claude Code理解当前项目的目标和结构、设置代码风格和一些规则、设置Claude Code的角色。可以在进行初始化之后通过自然语言输入让其修改该初始化说明文档，进而实现所需的设定

在一个已完成的项目下，通过 /init完成项目分析的初始化

4.1 /init – 初始化项目记忆指南

  • 定义与语法： /init 无参数。运行此命令会扫描当前项目代码库，在项目根目录生成一个 CLAUDE.md 文件，作为该项目的知识指南。CLAUDE.md 通常包含项目结构摘要、主要模块说明、依赖列表等内容。
  • 使用场景： 建议首次在新项目中使用 Claude Code时立即执行 /init。这样Claude会自动了解项目的大概结构和背景，相当于给Claude这个AI同事一本项目手册。/init 生成的 CLAUDE.md 可由Claude根据代码自动提取要点，你也可以在Claude的帮助下完善它——比如询问 “请列出项目架构的关键部分写入 CLAUDE.md” 等。完成后，将 CLAUDE.md 保存（甚至提交进仓库共享给团队）。之后每次在该项目目录启动Claude Code，它都会首先读取 CLAUDE.md，拥有持久的项目信息。
▼
bash
复制代码
/init

在这里插入图片描述

4.2 /help – 查看命令列表

▼
bash
复制代码
/help

在这里插入图片描述

4.3 /clear – 清除对话历史

▼
bash
复制代码
/clear

  • 定义与语法： /clear 无参数。用于清除当前会话的对话历史，使 Claude 忘记之前的所有对话内容。执行后，相当于开启一个新会话，但不会退出 Claude Code 界面。

  • 使用场景： 当对话持续很久、上下文累积过多时，可以使用 /clear 来重置上下文窗口，保持思路清晰。例如在完成一个独立任务后，开始新任务前执行 /clear，Claude 将从空上下文开始理解你的下一指令。这在任务切换时非常有用，可以避免旧话题干扰新需求。此外，当Claude的回答出现偏离正轨或上下文混乱时，/clear 可以一键“重启”对话。

4.4 /compact – 压缩对话内容

▼
bash
复制代码
/compact

  • 定义与语法： /compact [instructions] 可选附加“指令”参数。此命令会将当前对话历史总结压缩，并以该摘要作为新对话的开场上下文。可选的 instructions 参数允许你指定压缩时的侧重点，例如 /compact "保留尚未解决的问题" 会让 Claude 在总结时侧重未解决问题部分。

  • 使用场景： 当会话长度接近模型上下文长度上限时，/compact 是延续长对话的救星。Claude 会将已有对话自动总结为更短的内容，从而释放大量上下文令牌供后续交流使用。这类似于有个 AI 秘书在会议途中帮你记录会议纪要，确保你们不会因为对话太长而“忘记”前情。不过，与 /clear 不同，/compact 保留了上下文的精华——在新会话中Claude仍可以参考之前对话的摘要继续讨论。

4.5 /memory – 编辑会话记忆文件

▼
bash
复制代码
/memory

  • 定义与语法： /memory 无参数。用于直接打开并编辑当前项目的持久记忆文件 CLAUDE.md（或用户级别的全局记忆文件），方便查看和修改 Claude 的“长期记忆”。你也可以通过这个命令向 CLAUDE.md 添加或移除内容。

  • 使用场景： CLAUDE.md 是 Claude Code 用于初始化上下文的指南文件，通常包含项目简介、架构要点、代码惯例等。通过 /memory 命令，你可以随时更新该文件的内容：比如在初始化项目后发现 CLAUDE.md 漏掉了一些关键业务术语解释，可以输入 /memory 打开文件，在其中添加术语解释列表并保存。保存退出后，可以 /clear 然后开始新会话，Claude 将自动参照更新后的 CLAUDE.md 来回答问题，减少对术语的误解。

  • 一般选择当前项目记忆

在这里插入图片描述

在这里插入图片描述

在这里插入图片描述

简单理解就是： Project memory = 这个项目的专属规则/偏好 User memory = 你个人的全局习惯/偏好，跨项目通用 Auto-memory = 让 Claude 自己决定什么值得记，自动写入，不用你手动管

举几个典型场景：

  1. Project memory（项目记忆） ./CLAUDE.md

适合写跟这个项目强绑定的内容

  • "这是一个 React + TypeScript 项目，使用 pnpm"
  • "不要修改 src/legacy/ 目录下的任何文件"
  • "测试命令是 pnpm test，构建是 pnpm build"
  • "API 接口统一放在 src/api/，不要分散"
  1. User memory（用户记忆） ~/.claude/CLAUDE.md

适合写跟你个人习惯相关、所有项目通用的内容

  • "回复一律用中文"
  • "代码注释保持简洁，不要废话"
  • "提交信息用英文，格式 feat: xxx"
  • "不要主动帮我重构我没提到的代码"
  1. Auto-memory（自动记忆）

Claude 自己判断什么重要，自动写入，比如你在对话中说了：

  • "我们公司规定所有接口要加错误边界处理"——Claude 自动记下来
  • "这个项目不用写单元测试"——自动记下来，下次不再建议你写测试

总结就是：项目记忆管"这个项目怎么做"，用户记忆管"我这个人怎么工作"，自动记忆省去你手动整理的麻烦。

4.6 /status – 会话状态检查

▼
bash
复制代码
/status

在这里插入图片描述

  • 定义与语法： /status 无参数。显示当前 Claude Code 会话和系统状态，包括工作目录、登录账户、所用模型、加载的项目记忆等。这是一条只读命令，不会更改任何设置。

  • 使用场景： 当你需要确认当前环境时（例如切换目录后不确定Claude是否跟随了新项目，或刚切换模型后想验证当前模型名），/status 可以立刻给出答案。它也是排查问题的起点：如果Claude行为异常，先看一下 /status 是否仍指向正确的路径和模型，是否有正确加载 CLAUDE.md 等。

4.7 /cost – 令牌与费用统计

▼
bash
复制代码
/cost

在这里插入图片描述

  • 定义与语法： /cost 无参数。用于显示当前会话的令牌使用量统计，包括提示和回答分别用了多少 token，以及预估的 API 消耗费用。这对掌控 Claude Code 的使用成本非常有帮助。

  • 使用场景： 如果你使用按量计费的API密钥或免费额度，随时关注对话的 token 消耗情况是个好习惯。执行 /cost 可以让你了解目前这场对话累计用了多少 token，并据此估算花费。在长时间编程会话或密集代码生成功能中，偶尔检查 /cost 有助于及时止损：发现token飙升可以选择提问更具体、压缩上下文等节约开销。另外，当你打算结束当天工作时，可以用 /cost 获取会话用量总结，核对是否在预算之内。

4.8 /config – 查看或修改配置

▼
bash
复制代码
/config

在这里插入图片描述

  • 定义与语法： /config 可交互式查看和修改 Claude Code 配置参数。执行命令会显示配置菜单，你可以根据提示修改设置，例如启用/禁用自动压缩、设置主题、切换编辑模式等。部分配置也支持通过子命令直接设置，比如 /config set autocompact off 等。

  • 使用场景： Claude Code 提供许多可定制选项，通过 /config 你可以根据个人习惯进行调整。例如：Autocompact（自动压缩）默认开启以防止上下文溢出，通常建议保持开启；待办事项（to-do）功能可以让Claude Code在长任务中列步骤，你可在配置中启用/停用；verbose输出用于调试，可通过 /config 打开，当需要看Claude内部推理步骤时很有用（对应快捷键 Ctrl+R 切换verbose模式）；还有主题配色、通知方式（如终端铃声提醒Claude完成思考）、编辑模式等。总之，/config 是你的个性化Claude控制面板。

4.9 /model – 切换AI模型版本

▼
bash
复制代码
/model

  • 定义与语法： /model [model_name]。不带参数时通常会显示当前使用的模型，并提示可选模型列表；指定参数则可切换Claude所用的AI模型。Claude Code 常用的模型代号包括 Sonnet（较快、上下文较短）和 Opus（较慢但能力更强、上下文长度更大）等，或具体版本如 claude-4-100k 等。

  • 使用场景： 根据任务需要选择合适的模型，能在速度和质量间取得平衡。默认情况下Claude Code启动用的是较快的模型。当你需要更深入的分析、更大的上下文或更高准确度时，可以通过 /model opus 切换到能力更强的模型。例如复杂架构设计讨论、批量代码重构等场景，Opus模型（类似GPT-4之于GPT-3.5的角色）会表现更佳。而在简单问答或需要快速响应的场景下，继续使用Sonnet模型更高效。/model 让你动态调整AI助手的大脑，以匹配任务要求。

在这里插入图片描述

模型选项

选项含义
1. Default当前默认模型是 qwen3-max-2026-01-23
2. Sonnet (1M context)均衡型，性价比高，适合日常编码
3. Opus (1M context)最强模型，适合复杂架构/难题，但最慢最贵
4. Haiku最快最便宜，适合简单问答/快速任务

价格 $3/$15 per Mtok = 输入 $3 / 输出 $15（每百万 token）

底部两个设置

项目含义
◐ Medium effort思考力度，← → 可调节，分 low / medium / high，越高越慢越费 token
/fast快速模式，仅 Opus 可用，关闭深度思考，速度更快

一般怎么选：

  • 日常写代码 → Sonnet
  • 复杂重构/架构设计 → Opus（配合 Plan Mode 效果最好）
  • 简单问题/快速查询 → Haiku

4.10 /doctor – 环境健康检查

▼
bash
复制代码
/doctor

  • 定义与语法： /doctor 无参数。执行后Claude Code会检查当前安装环境的健康状态，验证所需依赖和权限是否正确配置，并报告潜在问题。

  • 使用场景： 当Claude Code行为异常（比如无法读取文件、工具调用总是失败等），/doctor 是排查问题的第一步。它会自动检查：Anthropic API连通性、已登录账户有效性、必需的依赖（git、GitHub CLI、ripgrep等）是否安装、Claude Code所需的文件权限是否授予等等。检查完后会输出一份报告，指出哪些项目通过，哪些存在问题。例如 “✘ 未检测到 GitHub CLI，请安装以使用 PR 功能” 或 “当前Anthropic API凭据无效” 等。有了这些信息，你可以据此修复环境，然后重试之前的操作。

在这里插入图片描述

5. Claude Code 进阶实战指南

5.1 核心理念

Claude Code 的真正价值不在于某个单一功能，而在于将命令、模型、记忆、模式串联成流。开发者负责方向和判断，Claude 负责执行和细节。

5.2 一套完整的开发工作流

以"接手新项目并开发新功能"为例，展示如何从头到尾组合使用各项能力。

第一步：初始化项目认知

进入项目目录后，第一件事不是写代码，而是让 Claude 先"读懂"项目。

▼
bash
复制代码
/init

自动扫描代码库，生成 CLAUDE.md 初稿，包含技术栈、目录结构、常用命令等基础信息。生成后用 /memory 打开，补充人工经验：

▼
bash
复制代码
- 不要修改 src/legacy/ 目录
- 提交信息格式：feat: / fix: / chore:
- 测试命令：pnpm test

这份记忆会在之后每次对话自动加载，省去反复交代背景的成本。

第二步：理解代码结构（Plan Mode）

熟悉陌生代码库，Plan Mode 是最安全的方式——只读不改，专注理解。

▼
bash
复制代码
Shift+Tab × 2  →  进入 Plan Mode

然后自然语言提问：

▼
bash
复制代码
分析 src/auth/ 模块的整体架构，梳理用户登录的完整调用链

Claude 会遍历相关文件、整理逻辑、输出结构图和说明，全程不碰任何代码。遇到复杂架构时，切换到 Opus 模型，思考更深：

▼
bash
复制代码
/model  →  选择 Opus

第三步：规划新功能（Plan Mode + Opus）

理解现有代码后，继续在 Plan Mode 里规划新功能，不要急着切换到执行模式。

▼
bash
复制代码
我需要给登录模块加上 OAuth 支持，请分析现有代码结构，
制定一个改动最小、风险最低的实现方案

Claude 输出计划后，用 Ctrl+G 直接打开计划文件编辑，删掉不需要的步骤、补充业务约束，比对话描述修改精准得多。

💡 这一步不要省。花 10 分钟确认计划，能避免后面返工 1 小时。

第四步：分模块执行（Auto-Accept + 后台任务）

计划确认后，切换到 Auto-Accept 模式开始执行：

▼
bash
复制代码
Shift+Tab × 1  →  进入 Auto-Accept 模式

对于耗时操作（跑测试、编译），挂到后台：

▼
bash
复制代码
Ctrl+B  →  后台执行
Ctrl+T  →  查看任务进度

前台继续和 Claude 讨论下一个模块，互不干扰。

每完成一个独立模块，及时 /clear，避免上下文污染下一个任务：

▼
bash
复制代码
/clear

对话变长但还没到切换模块的时机，用 /compact 压缩而非清空：

▼
bash
复制代码
/compact "保留 OAuth 登录相关的讨论和决策"

第五步：性能分析与优化

功能开发完成后，切回 Plan Mode，让 Claude 做一轮审视：

▼
bash
复制代码
Shift+Tab × 2  →  Plan Mode
分析刚才新增的代码，找出潜在的性能问题和安全隐患，不要修改，只给报告

确认问题后，再切换到执行模式针对性优化。这样比"边写边优化"更清晰，也不容易引入新问题。

第六步：收尾与记忆沉淀

开发完成后，用 /memory 把这次积累的项目经验写进 CLAUDE.md：

▼
bash
复制代码
- OAuth 相关逻辑统一在 src/auth/oauth/ 下
- 新增第三方登录时参考 GoogleOAuthProvider 的实现模式

下一个功能开发、或者团队其他人接手时，这些经验直接生效。

5.3 模式与模型的选用原则

阶段模式模型
读代码 / 规划Plan ModeOpus
日常编码DefaultSonnet
重复性修改Auto-AcceptSonnet / Haiku
快速问答DefaultHaiku

5.4 一句话总结

Plan Mode 想清楚 → Auto-Accept 执行 → /compact 或 /clear 管理上下文 → /memory 沉淀经验

把这条主线跑顺，Claude Code 才算真正用起来了。

欢迎关注我的公众号【兮动人】，每天分享一些技术文章和实战经验。

image.png

OpenClaw
Claude
Java
后端
AI
9
11
分享
操作
评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题

目录

🔥 热门文章
1
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
430
2
DeepSeek 全新模型发布，性价比最高的一集！
390
3
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
380
4
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
5
又一个国产版 Codex 神器，也来卷办公了！
330
6
day3-如何写出一个高质量的 Skill（组内分享） 高质量 Skill 不是“一个调得很顺的巨型 Prompt”，而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”，再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子，但方法是通用的。 --- 一、先想清楚：Skill 到底是什么 一个 Skill 至少包含四部分： 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做，每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办，而不是硬编一个看似合理的结果 高质量 Skill 的共同点：职责单一、接口清晰、规则可定位、输出可验证。 反例：把几十条经验全塞进一个主 Prompt，改一条规则要重调整个 Prompt，评估时也不知道是哪条规则退化。 --- 二、核心方法：先建评估，再写 Skill 不要先写转换器再补测试。正确顺序是： 1. 定义输出契约：什么算合法、什么算合格； 2. 建金标准集：一小批人工认可“可放行”的样本； 3. 先写评估 Skill：让它在金标准集上跑出基线； 4. 再迭代生成 Skill：每次修改跑同一套评估，无退化且目标维度提升才算正向。 这就是评估驱动开发：评估是 Skill 的单元测试，金标准集是回归锚点。 --- 三、评估 Skill：三层门禁，逐层递进 前一层不过，后一层不跑。每层留可追溯证据。 第 1 层：确定性硬门禁 用解析器、Schema、校验器完成，不消耗模型成本。 · 输出可解析； · 必填字段齐全，类型/枚举合法； · 引用目标存在，无悬空引用、无不可达节点； · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层：语义断言 用脚本 + 结构遍历检查“逻辑对不对”，仍然保持确定性。 通用检查项： · 覆盖率：源材料里的关键步骤、分支、条件，输出里是否都有对应？ · 完整性：每个判断节点是否都有明确出口？有没有死胡同？ · 可达性：每条路径是否都能到达预期终点？有没有无出口循环？ · 顺序与依赖：有先后依赖的操作，是否保留了顺序？有没有被拍平成无序列表？ 例子：故障诊断转换中，检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层：LLM-as-Judge 只处理解析器表达不了的维度：忠实度、完整性、可执行性。 但 Judge 会漂移，不能单独放行，必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换模型必须用金标准集重新校准。 通用 Judge 维度： 维度 问什么 忠实度 输出是否忠实源材料意图？有没有自行发明内容？ 完整性 关键步骤、条件、证据是否保留？隐式知识有没有被压成空话？ 收敛性 输出是否仍指向原目标，而不是发散？ 可执行性 下游不依赖源材料能否直接使用？ --- 四、金标准集：回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子，扩到 15～30 份，覆盖失败模式而非随机抽样： · 完整正例：典型流程； · 边界/异常分支：异常路径、循环、前置失败回退； · 已知易错模式：实际踩过的坑； · 留出集：不参与调优，只用于最终验收，防过拟合。 金标准不需要完美，只需要当前标准下认可可放行。 回归指标：关键路径用 pass^k（k 次全过），稳定性用 pass@k。 --- 五、工程约束：让批量产出可重放 · 幂等：同输入 + 同 Skill 版本 + 同规则 → 输出一致，否则无法判断变好是 Skill 改了还是随机波动； · 隔离不阻断：单份失败进隔离队列，记录失败层和原因，不阻塞其余； · 版本绑定：规则、rubric、金标准集进 Git；每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”； · 抽样人工复核：Judge 临界样本 + 易错模式，人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅，写清：输入约定、输出契约、分步流程、硬规则、降级策略； · 经验规则放 references/ 或 rules/，按失败模式分类，不要全塞进主 Prompt； · 不确定时标 needs_review: true，不要硬编看似合理的结果； · 迭代由评估报告驱动：报告告诉你哪层挂了、哪类失败模式，你改对应规则文件，而不是漫无目的调 Prompt。 --- 七、落地顺序（不要反过来） 1. 固化输出契约：Schema + 结构约束； 2. 建金标准集：从已认可的 + 最易出错的样本开始； 3. 先写评估 Skill：跑出基线报告； 4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向； 5. 批量运行 + 隔离回放：失败进队列，结束后人工抽检； 6. 评估 Skill 自身版本化：换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。 3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。 先让评估体系站稳，再让生成器迭代。这样交付的不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。
310
7
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
8
什么是LLM
300
9
我的第一个出海产品！7 天 2 万
290
10
WorkBuddy 本地 API 桥 + dsh 插件：把你的 WorkBuddy 额度，变成手边随手可用的模型
290