从聊天，到任务循环#

传统 AI 编程助手的基本动作是回答：解释代码、补全函数、生成片段、给出建议。

Claude CLI 的基本动作更接近一个循环：

先理解上下文，再采取行动，然后验证结果。

Anthropic 在 “How Claude Code works” 里把这称为 agentic loop：gather context、take action、verify results。这个说法朴素，但抓住了 AI 编程工具真正的分水岭。

一个只会回答的模型，即使很聪明，也仍然停留在“顾问”角色。它可以告诉你哪里可能有 bug，但不会自己打开文件、跑测试、读失败日志、改代码、再跑一次。

而一个运行在终端里的 coding agent，可以接触工程现场：

• 它能读你的项目文件；
• 它能搜索代码；
• 它能运行 build、test、lint、git；
• 它能修改多个文件；
• 它能根据命令输出调整下一步；
• 它能把工作结果留在本地 git 状态里供你审查。

这就不是“模型能力”本身的问题，而是“模型被装进什么样的工作外骨骼里”的问题。

Claude CLI 正是这个外骨骼。

终端为什么重要#

很多非工程背景的人可能会问：既然有 Web 和 IDE，为什么还要 CLI？

因为终端是软件工程里最接近真实执行环境的界面。

代码不是写在聊天窗口里的。代码要经过 package manager、编译器、测试框架、数据库迁移、Docker、CI、git、部署脚本。一个开发者每天真正操作的不是“文件”，而是一组命令、一堆状态和一条不断反馈的工具链。

Claude CLI 的价值，就在于它进入了这条工具链。

你可以在项目目录里直接运行：

1
claude

然后让它解释项目结构、定位入口、修复测试、补文档、整理提交。也可以用非交互方式：

1
cat logs.txt | claude -p "找出异常模式，并说明可能原因"

官方 CLI reference 里列出的能力，已经远远超过普通聊天：claude -c 可以继续最近会话，claude -r 可以恢复指定会话，claude --model 可以指定模型，--permission-mode 可以控制权限模式，--add-dir 可以给额外目录访问权，--mcp-config 可以加载外部工具配置，--output-format json 可以让它进入脚本化流程。

这说明 Claude CLI 不是一个孤立工具，而是一个可以被工程流程编排的接口。

最值得学的不是命令，而是工作法#

Claude CLI 很容易被误用。

最常见的误用，是把它当成一个更强的 Stack Overflow：问一句，复制一段，贴进项目，出错再问。

这当然也能用，但没有发挥它的真正优势。

Claude Code 官方 best practices 反复强调两件事，我觉得非常关键。

第一，给它可验证的目标。

不要只说“优化这段代码”，而要说：

1
修复登录超时后的失败问题。
2
先写一个能复现的测试，再改实现。
3
最后运行相关测试并贴出结果。

这时 agent 才有闭环。它不是写完就停，而是可以用测试结果判断自己是否真的完成。

第二，复杂任务先探索，再计划，再实现。

这对企业项目尤其重要。很多代码库的问题不是“不会写代码”，而是上下文复杂：历史包袱、隐含约定、脆弱依赖、没人敢动的老模块。让 AI 一上来就改，反而容易制造新问题。

更稳的方式是：

1
先阅读 src/auth 和相关测试，理解现有登录流程。
2
不要改文件。
3
总结现在的会话管理逻辑，并给出修改计划。

等计划清楚，再让它实现。

这也是为什么 Claude CLI 的 permission mode 很重要。默认模式适合谨慎工作；plan mode 适合只研究不动手；accept edits 或 auto mode 适合你已经信任方向、希望减少打断的时候。权限模式不是一个小功能，而是人机协作的边界管理。

CLAUDE.md、Skills、MCP：真正的可复用价值#

我认为 Claude CLI 最容易被低估的地方，是它的可配置性。

单次对话里的聪明，不等于团队能力。

团队真正需要的是：规则能沉淀，工作流能复用，外部系统能接入。

Claude Code 里的 CLAUDE.md 就是第一层沉淀。你可以把项目构建命令、代码风格、测试习惯、架构约束、PR 规则放进去。每次进入项目，Claude 都能读到这些上下文。

但 CLAUDE.md 不应该写成百科全书。官方也提醒，过长的上下文会稀释真正重要的指令。我的经验是：只写“如果不写，Claude 就容易犯错”的内容。能从代码里看出来的，不要写；会频繁变化的，不要写；教程式长篇解释，不要写。

第二层是 Skills。

Skills 适合封装可重复的工作流，比如“做一次安全 review”“按公司模板写 release note”“把某类客户访谈转成需求文档”。它的意义不是让 Claude 更像一个大杂烩，而是让能力按需加载。用的时候读完整说明，不用的时候只占很小的发现成本。

第三层是 MCP。

MCP 把 Claude CLI 从本地代码库连接到外部世界：GitHub、Slack、Jira、Google Drive、数据库、内部 API。对企业来说，这可能比单纯写代码更重要。因为企业流程里的真问题，往往不在一个 repo 里，而散落在工单、文档、会议纪要、运行日志和审批系统之间。

当 CLI、Skills、MCP 合在一起，Claude 就不只是一个“写代码的助手”，而更像一个可编排的企业工程代理。

它会改变软件工程的组织方式#

Claude CLI 这类工具的影响，不只是提高程序员效率。

更深的变化，是它在重新定义一个“开发任务”应该由谁来完成。

过去，一个任务往往要拆成很多人的动作：产品写需求，开发看文档，工程师改代码，测试跑用例，DevOps 看部署，项目经理汇总进度。每个人通过工具链传递信息。

现在，一个 coding agent 可以跨过一部分界面，直接在工程现场完成连续动作：

• 读需求；
• 查代码；
• 生成计划；
• 修改实现；
• 补测试；
• 跑验证；
• 写提交说明；
• 生成 PR 描述。

这不会让工程师消失。

相反，它会把工程师从“逐行操作的人”推向“定义任务、设置约束、审查证据、判断取舍的人”。

低价值的重复操作会被压缩，高价值的工程判断会更重要。

这和企业软件的变化是一致的。AI Agent 不只是替代某个岗位的一小段劳动，而是在重写流程的最小单位。以前流程围绕人和界面组织；以后流程可能围绕 agent、权限、工具和验证信号组织。

Claude CLI 是这个变化在软件开发领域的一个清晰样本。

也不要神化它#

但我也不想把它写成神话。

Claude CLI 仍然会犯错。它可能误解需求，可能过度修改，可能在上下文太满时忘记早期约束，可能把一个简单问题复杂化，也可能在缺少验证信号时自信地停在半成品状态。

所以用好它，需要几个朴素纪律：

• 开工前给范围；
• 复杂任务先 plan；
• 明确什么算完成；
• 给它测试、build、截图、日志这类可验证信号；
• 让它展示证据，而不是只说“完成了”；
• 对 git、部署、生产数据库、外部 API 这类动作保持人工审查；
• 把长期规则写进 CLAUDE.md，把重复工作流做成 Skills。

真正危险的不是 AI 太强，而是人把“看似顺滑的自动化”误当成“无需判断的自动化”。

我的判断#

Claude CLI 的意义可以用一句话概括：

它把 AI 从“回答问题的窗口”，推进到了“执行工程任务的终端代理”。

这一步很重要。

因为终端不是一个 UI 偏好，而是工程世界的操作界面。谁进入终端，谁就进入了软件生产的真实链路。

未来的软件团队，可能不会简单地问：“我们要不要用 Claude CLI？”

更准确的问题会是：

我们有哪些工作，已经可以被描述成一个清楚的目标、一个受控的权限边界、一个可运行的验证信号，然后交给 agent 去完成？

能回答这个问题的团队，会比只讨论“哪个模型更强”的团队走得更快。

参考#

• Claude Code Overview
• Claude Code Quickstart
• How Claude Code works
• CLI reference
• Best practices for Claude Code