从 Chat 到 Code：一名程序员的 Claude 使用进化记录

前记

笔者所在公司不能连接外网，所以只能在外网自己的电脑上使用 Claude Code。之前主要是用 Claude 来写一些简单代码，没有做过项目级的开发，更多是在使用 Claude Web 的 Chat 功能，甚至有些简单代码也是在 Chat 里完成的。

Chat 里也做过不少 PPT 编写、文档操作、方案整理等工作，Claude Code 其实没有深度使用过。

后来发现 Chat 里的会话比较零散，很多会话其实是有关联的——比如根因分析智能体的设计与开发、全链路相关讨论，以及汇报 PPT 制作等等。这些上下文分散割裂，应该按项目来管理才对。

于是系统调研了一下，发现 Claude 产品线中 Chat、Code、Cowork 都有 Project 的定义，我的这些场景该如何选？先说答案：作为一名程序员，比较适合我的是 Code 模式，今天这篇文章就基于这个思考做一个阶段性梳理。

对于很多大佬来说 Claude Code（文章中有时简称 cc）早已熟练上手，本文属于笔者的阶段性使用总结，如有不对的地方，欢迎大佬们批评指正。

一、Claude 产品线介绍

笔者目前接触到的有 Chat、Code、Cowork 三种，其实还有一个 Design，但对笔者来说暂时用不上，主要是做设计相关的工作。本章聊聊这三个产品的区别。

1、三个产品的主要定位和使用场景

Claude Chat

定位是通用对话助手，你问它答，是最熟悉的交互形式。但现在已远不止聊天——可以在对话中直接生成 Excel、PPT、PDF 等成品文件，也能做研究、写报告、分析内容。核心特征是你主导节奏，Claude 响应你的每一步指令。

适合：学生、研究者、内容创作者、分析师，凡是需要"问问题拿答案"的场景。

Claude Code

定位是开发者的自主编码代理。它不只是写代码给你看，而是直接进入你的项目目录，读文件、改文件、跑命令、提交 PR，像一个真实的开发同事在旁边操作。交互节奏是同步的——你下指令，等它执行，看结果，再继续。

适合：开发者的日常编码、调试、重构、代码审查、CI 自动化等工作。

Claude Cowork

定位是知识工作者的桌面任务代理，可以理解为"给不写代码的人用的 Claude Code"。你把任务交给它（拖入文件夹、描述目标），然后可以直接离开，Claude 在后台自主完成多步骤工作——整理文件、提取数据、生成报告、操作应用。交互节奏是异步的，强调委托而非协作。

适合：研究员、分析师、法务、财务、运营等每天和文档、数据、文件打交道的知识工作者。

（附）Claude Design

2026 年 4 月发布的研究预览，聚焦视觉产品和原型设计，是产品线第四个入口，面向设计师群体，笔者暂未深入使用。

2、关于项目（Project）管理的区别

三者对"项目"的理解完全不同：

Claude Chat 的 Project：是一个共享上下文容器。你可以设置自定义指令（System Prompt）、上传知识文件，所有在该项目内的对话都共享这份上下文。适合管理长期话题，但文件和对话存在云端，不涉及本地文件系统。

Claude Code 的 Project：就是你本地的代码仓库目录。项目配置通过 CLAUDE.md 文件管理——放在项目根目录的 CLAUDE.md 就是 Claude 的"项目说明书"，每次会话自动加载，记录代码规范、架构决策、常用命令等。Claude 对这个目录拥有读写执行权限，真正意义上"在项目里工作"。

Claude Cowork 的 Project：是你授权给 Claude 访问的本地文件夹和应用。你指定哪些文件夹可以被读写，Claude 就在这个范围内自主完成任务。没有 Chat 那种"知识库上传"的概念，也没有 Code 那种"代码仓库"的概念，更接近于"工作区授权"。

3、运行环境的区别

核心结论：Chat 在云端对话，Code 在本地代码库执行，Cowork 在本地桌面自主操作。三者的开放权限依次递增，使用前需要根据任务性质和风险偏好来选择。

二、Claude Code 其他使用总结

1、关于记忆

Claude Code 的记忆有三层，各有分工：

核心建议：以 CLAUDE.md 为主，Auto Memory 为辅，文档为底。

其中 CLAUDE.md 是最值得优先投入的。Claude Code 把每个会话自动存到本地 ~/.claude/projects/ 下，每个项目目录对应一个子文件夹，"项目"的边界就是"你在哪个目录启动了 claude"。没有 CLAUDE.md，每次会话 Claude 都要重新认识你的项目，白白消耗上下文。

有一个重要实践：永远在正确的项目根目录下启动会话，否则会话会被归到错的地方，后面找不回来。

如何初始化 CLAUDE.md： 在项目目录里运行 /init，Claude 会分析项目结构自动生成一份 CLAUDE.md 作为起点，再根据实际情况手动补充调整。

全局 vs 项目级： cc 也有一个全局 CLAUDE.md，位于 ~/.claude/CLAUDE.md，适用于所有会话。建议把跨项目通用的偏好（如回复风格、常用工具链）放到全局文件，项目特有的规范（如编码约定、架构决策）放到各项目根目录的 CLAUDE.md 里。

2、关于上下文压缩

由于 Claude 订阅每 5 小时会刷新额度，为了多刷新一次额度，笔者一大早就在昨天的工作项目会话中打了个"早上好"，顺带查了下使用额度，一下就把 5 小时的额度用了 11%，着实吓了一跳。

于是在会话中问了这个问题，Opus 模型的解释是：一个会话如果很久没有使用，历史上下文仍然会被加载，重新打开时会消耗大量 token。

所以有一个重要习惯：长期搁置的会话，重新打开前先用 /compact 压缩一下上下文。或者不相关的任务直接用 /clear 清空开新会话。

上下文压缩说明截图

3、关于 Skills 使用

Skills 是 Claude Code 的可复用工作流，放在 .claude/skills/ 目录下。使用时直接输入 /skill名称 即可调用。

关于全局 Skills 和项目级 Skills： - 项目级 Skills：放在项目目录的 .claude/skills/ 下，只在该项目内生效 - 全局 Skills：放在 ~/.claude/skills/ 下，所有项目都可以使用

对于跨项目通用的工作流（如代码审查、PR 规范检查），建议放到全局；项目特有的业务流程（如特定的发布步骤）放到项目级。

实战案例：md-to-html Skill

笔者在写公众号文章时，有一个固定流程：先用 Markdown 写好正文，再转换成符合微信排版风格的 HTML，最后复制到公众号编辑器发布。这个转换过程如果手工处理非常繁琐，所以笔者用了一个 md-to-html Skill 来自动完成。

这个 Skill 的功能是：把 Markdown 文件转换成带绿色主题样式的微信/博客文章 HTML，标题会自动去掉 emoji 前缀，整体排版符合公众号阅读习惯。

使用方式非常简单，在 Claude Code 会话里直接输入：

/md-to-html 你的文章.md

Claude 就会读取 Markdown 文件，套用预设样式模板，生成一份可以直接粘贴到公众号编辑器的 HTML 文件。省去了手工调样式的麻烦，每次发文章都能保持一致的排版风格。

这也是 Skills 最典型的使用价值：把重复的、有固定规范的工作流封装起来，一个命令搞定。

4、跟踪和恢复同一项目的对话

在项目目录里，常用这几个命令：

• claude --continue（或 -c）：直接接上这个项目的上一次会话
• claude --resume（或 -r）：打开 picker，列出当前目录下的历史会话（带摘要、消息数、git 分支名、时间戳）
• 会话内输入 /resume：不退出当前会话就能切换到同项目的别的会话
• picker 里按 A 可在"仅当前目录"和"所有项目"之间切换，按 B 按当前 git 分支过滤

三、Codex 和 Claude Code 的区别

笔者同时在使用 Codex 客户端，了解了下 Codex 也有 CLI 版本。笔者主要用 Codex 来写 PPT——可以在客户端右侧实时看到 PPT 修改过程，这种可视化效果是我想要的。

同样的订阅等级，感觉 Codex 的订阅额度会比 Claude 更耐用一些，所以也会用 Codex 客户端来写一些简单代码，但没有系统比较过两者的差异。

可以安装一些主流的 PPT 制作 Skills 来使用。公司领导在群里推荐了一个 Skills（ppt-master），是一套从资料到 SVG 页面，再导出为 PPTX 的完整制稿流水线。核心思路：资料输入 → 项目初始化 → 策略设计 → SVG 页面制作 → 质量检查 → 后处理 → 导出 PPTX。

正好有个 PPT 要修改，试用效果还不错。Skills 仓库地址：https://github.com/hugohe3/ppt-master.git，直接把地址给 Codex 让它自行安装就行。

ppt-master 使用效果截图

四、Claude Code 联想到 OpenClaw

笔者前段时间买了台 Mac Mini 来部署 OpenClaw，目前接了 DeepSeek V4 的模型，使用飞书作为通讯通道。

部署之后一直闲置着，主要是还没想到合适的场景。OpenClaw 的版本更新比较频繁，基本几天一个版本，笔者尝试升级了几次，发现升级后运行就不正常了，感觉 OpenClaw 这个 Agent 不够可靠，缺少自我校验的能力。

有人推荐把 Claude Code 结合 OpenClaw 来使用，等有空我会尝试这个组合，不知道大家现在龙虾都养着用来做什么了？

关于两者的关系，有一个分层思路值得参考：

• OpenClaw 的定位：常驻的接入层 + 宿主，解决"让一个 Agent 一直在那儿、随时从任何渠道找到它"的问题。它的核心价值是常驻、接入 15+ 消息平台、有持久记忆和 Skill 生态、跑在自己机器上。
• Claude Code 的定位：真正干活、会自我校验的执行核心。Anthropic 的工程实践里反复强调：长任务 Agent 要在每次会话开始时做端到端验证，而不只是在做完之后——这正好是 OpenClaw 缺的能力。

社区的建议是：让 OpenClaw 当"常驻的躯壳和渠道入口"，让 Claude Code 当"真正干活、会自我校验的执行核心"。

把 OpenClaw 当能独立可靠干活的智能体，期望就错配了；把它当渠道宿主，再外挂一个强 harness，定位才顺。

五、结语

从 Chat 到 Code，是从"对话助手"到"项目成员"的转变。Chat 里的会话是零散的，Code 里的项目是有记忆、有上下文、有连续性的。对于程序员来说，这个转变值得尽早完成。

Claude Code 的上限很高，但也有学习成本。本文只是笔者的阶段性总结，很多能力还没有深度探索——比如 MCP 服务器的接入、Hooks 的自动化配置、多 Agent 并行工作流等。后续用深了再来更新。

如果你也在用 Claude Code，欢迎交流使用心得。