企业官网建设流程全解析

作为一个几乎整天泡在终端里的人，我以前的工作状态是三个窗口来回切：编辑器里改代码、终端里跑命令、浏览器里查文档。等我把Claude Code接进终端之后，这套习惯彻底变了——你可以在命令行里直接用自然语言驱动它，让它读你项目的文件、改代码、跑测试、甚至直接提交git。它不是网页对话框的简单搬家，因为它能真正访问你机器上的文件系统。如果你也受够了复制粘贴上下文，这篇速查手册应该正好对路。我会把高频指令、快捷键和三个完整的实战工作流串起来讲，全是可以直接抄作业的内容。

1. 为什么说“终端里的助手”和“网页里的对话”是两种东西

1.1 网页版对话摸不到你的代码

网页版AI对话再方便，本质上也只是一问一答。当你让它帮你改代码时，你需要手动把文件内容粘过去，改完再把结果粘回来。项目一大，这种复制粘贴的成本就高得离谱，而且模型看不到你的目录结构、依赖关系、测试结果，给出的答案经常停留在“看起来对”的层面。

Claude Code这类终端工具解决的是“接触面”的问题。它运行在你本地，能直接执行bash命令、读写文件、查看git状态。你可以指着某个目录说“看看这里”，它就真的去看；你让它跑测试，它就真的去跑，然后把输出带回来。这个能力听起来简单，实际用起来是质变——相当于你的终端里多了一个能接管完整开发链路的助手，而不仅仅是聊天框里的文本生成器。

1.2 终端助手打开的新操作面

终端交互和网页对话还有一个隐蔽但关键的区别：上下文是活的。在网页里，每次新对话都是从零开始；在终端里，它天然贴近你的项目，能感知你当前的分支、最近的改动、报错日志，而且对话历史可以延续。

举一个我自己很常用的例子：接到一个线上问题反馈，我会直接启动会话，让它先读日志、看代码，然后描述问题现象，让它沿着调用链去查。整个过程不用复制任何一个文件名，因为它在项目根目录里，路径都是相对的。它还会在发现问题后主动提出修复方案，而不是等我一条一条喂信息。

1.3 什么样的场景可以考虑在终端里跑

不是所有人都需要它。我个人的判断是：如果你日常工作是写脚本、写后端接口、维护旧项目、做代码审查，或者经常要处理“读日志、改代码、跑测试”这种循环，那终端版AI助手几乎是刚需。如果你只偶尔改几行前端样式，或者主要用AI做翻译和文案，那网页版就够用了，没必要多搭建一套环境。

成本和自由度也要考虑。终端助手会消耗token，而且你在项目里的操作它都能看到，敏感信息要谨慎。关于权限和安全，我放到后面专门讲。

2. 启动之前的准备：安装、认证与第一个会话

2.1 安装、登录与第一次启动

安装过程不复杂：用你习惯的包管理器全局安装官方发布的命令行工具即可。装完在终端里输入启动命令，第一次会进入登录流程，按提示完成账号授权就算注册好了。这一步卡的通常是网络，属于老生常谈，我不展开。

启动后默认是交互模式，你会看到一个输入提示符。此时可以直接打字，也可以输入斜杠命令。整个界面保持终端极简风格，不会弹浏览器窗口，信息密度比我见过的任何IDE插件都要高。

注意：默认启动会读取当前目录作为项目根目录。不要在盘符根目录、系统目录这些地方直接跑，否则它扫描文件时会糊你一脸无关上下文。建议任何会话都在明确的项目目录里启动。

2.2 启动后的第一件事：初始化CLAUDE.md

大部分人的第一个误区是上来就丢一句“帮我写个登录模块”，然后期待它像一个无所不知的老同事。问题在于，它对你的项目一无所知，没有架构背景，没有技术栈上下文，没有约束条件，结果就是空泛的套话代码。

正确做法是用/init命令生成项目记忆文件。执行之后，它会扫描当前项目的目录结构、配置文件、README，然后在项目根目录生成一个CLAUDE.md。这个文件相当于你写给这个助手的“项目入职手册”：里面记录了这个项目是什么、目录怎么组织、代码规范是什么、常用命令是什么。每次启动新会话时，它都会自动读取这个文件。

更进阶的用法是手动编辑CLAUDE.md，把你自己团队才会知道的潜规则写进去。比如“本项目的DTO不能直接暴露给controller”“测试必须用某个固定的mock方式”“别动某个目录，那是自动生成的”。这些规矩写不写，直接决定了AI改代码时是“顺手”还是“帮倒忙”。

2.3 第一个提示词应该怎么组织

我建议第一次尝试不要让它写代码，先让它“探索”：

请先阅读项目的README和目录结构，理解这个项目的技术栈和模块划分，然后简要告诉我你理解了什么。

这么做有两个好处：一是让它在动手改任何东西之前建立背景知识；二是你可以在它描述完理解之后，趁早纠正偏差。它如果理解错了，你后面让它改代码，每一句都是建立在错误前提上的。说是“探索”，其实是给整个会话打地基。

首次提示词里尽量包含四件事：项目目标、技术栈、约束条件、你要它产出的东西。别怕啰嗦，前两句话越具体，后面返工越少。

3. 高频斜杠指令拆解：一张表格看懂九成功能

Claude Code的大部分工具调用都沉淀成了斜杠命令。我先给一张速查表，再挑几个容易用出花样的详细说。

3.1 会话与上下文：/clear、/compact、/resume

/clear最容易理解：清空当前对话，就像打开一个新会话。任务从A切换到B时，我一般先clear，避免前一个任务的“思想钢印”影响后续判断。特别是前端改完样式又去调后端接口，如果上下文里还残留一堆CSS讨论，模型在回答后端问题时容易串味。

/compact的情况是：界面提示上下文接近上限，但你不想丢掉前面讨论的思路。它会压缩历史对话，把关键信息提炼成摘要，腾出空间。这里有个我踩过的坑：压缩之后，前面聊过的某些细节会被丢掉，所以如果正在讨论一个重要方案，我会先用/export把对话导出保存，再compact。

/resume用于恢复之前的会话。终端重启、临时离开、电脑休眠，都会让会话中断。直接敲/resume选择历史会话即可，配合--continue参数还能直接续上最近一次。

3.2 把文件喂进上下文：/add、/drop、/context

/add是我用得最频繁的命令。它的逻辑是“把指定路径文件加入AI的可见范围”。排查日志时，我会先/add logs/error.log，它读完再对症下药；改接口时，我会/add src/controllers/auth.ts，让它把目标文件完整读一遍再动手。

配合/context可以随时确认它到底看到了什么。这里有一个常见误区：很多人以为只要在提示词里提到文件名，AI就会自己打开文件。其实不一定，很多时候它只是“听说过”这个文件，并没有真正读过内容。/context可以看到哪些文件被真实加载，如果发现核心文件没在里面，立刻/add。

/drop则相反，用来做减法。上下文里的无关文件太多会稀释注意力，模型容易被不相关的噪声干扰。判断标准很简单：如果这个文件跟当前任务没有直接关系，就不要留在上下文里。

3.3 状态感知与成本控制：/status、/model、/cost

我承认，让终端助手改代码最让人不安的就是“会不会改着改着钱没了”。/cost能直接看本次会话累计消耗，心里不踏实就敲一下，比什么都管用。

/model可以调整会话用的模型版本。不同档位的模型，推理力和价格差别不小。我的习惯是：复杂架构设计、重构、调试疑难问题时切高配；写简单脚本、补注释、整理格式时用标准档就行。

/status是一把万能钥匙。当你觉得它反应变慢、行为怪异、答非所问时，先看/status：上下文占用可能是满的、运行模式可能是受限的、文件权限可能漏了。它像汽车的故障灯，第一时间告诉你“哪里在报警”。

3.4 改错之后的后悔药：/rewind与/review

/rewind是我心里的“后悔药”按钮。它会把最新一轮操作回退，包括AI做过的文件修改。如果看完改动觉得方向错了，不要一个个文件手动改回去，直接/rewind回到改动前状态。我之前有一次让它重构一个工具函数，结果它把依赖关系全改了，跑测试一片红。一条/rewind下去，干净回到起点，比自己git reset精准得多。

/review是在提交之前让AI给自己挑刺。它会基于当前工作区的改动，做一轮代码审查，输出问题清单。这个命令的价值在于它经常会说出“人不容易注意到”的问题，比如异常处理缺失、边界条件漏洞、敏感信息硬编码。我现在的习惯是：任何正式提交，进/review看一眼。

3.5 项目记忆怎么持久化：/init、/memory

/init前面已经提过，它生成项目级的CLAUDE.md。/memory则管理的是跨项目的长期记忆——记录你个人偏好的东西，比如“我习惯单引号、两空格缩进”“提交信息用中文”“不要给工具函数加不必要的抽象”等等。

太多人忽略这一步，导致每次新开会话都得重新教一遍同样的规矩。花十分钟把偏好写进记忆，之后所有新会话都自动生效。这个投入产出比非常高，甚至比多写几个单元测试还划算。

4. 终端快捷键与编辑器联动方案

4.1 高频快捷键速查

在终端里跑Claude Code，交互大部分靠键盘。下面这些快捷键我一天要按几十次：

最值得适应的是Ctrl+C的“打断”语义：AI生成大段代码时，如果你已经看出方向不对，别等它写完，直接打断然后给一句修正指令。这比等代码生成完再回退省得多。很多人还习惯性的想用鼠标选中终端里的代码去复制，但在这种交互模式下，Tab键直接“接收”建议才是最顺的操作。

4.2 编辑器集成的选择

Claude Code不是固定在某个IDE里的插件，它就是一个终端程序，所以理论上任何能跑终端的编辑器都能配合。

我用下来最顺的组合，是在VS Code的集成终端里直接跑。好处是编辑器左侧的文件树和终端同屏，AI改完文件，我立刻能从diff面板看到变化，不需要切窗口。如果你更习惯独立终端，比如系统自带的Terminal窗口，反而能避免编辑器快捷键和终端快捷键互相抢，比如在某个编辑器里Ctrl+C可能被复制操作占用。

提示：如果你在主流的代码编辑器里用，记得留一个独立的终端标签页专门跑Claude Code，不要和编译、lint的终端混用。命令输出来回穿插，你会分不清哪段是AI的行为、哪段是自己的操作。

5. 三个实战工作流：把命令组合成习惯

命令只有组合起来才有意义。我挑三个高频场景，完整走一遍流程。

5.1 新项目启动：从空目录到可运行骨架

真实经历：我想写一个用于内部服务的告警通知小工具。一开始我不会直接在网页对话框里面聊，而是：

mkdir alert-tool && cd alert-tool

然后启动Claude Code，第一句话：

我想做一个告警通知服务，输入是各系统推送的webhook消息，输出是按规则转发到不同群组的通知。语言用某个脚本语言，存储用轻量级数据库，先不要写代码，帮我确认一下技术选型和目录结构。

它给出的建议是：消息队列独立性、配置分离、路由规则表。我确认后，第二步让它：

请初始化项目结构，生成CLAUDE.md，说明这个项目的用途、约束和测试命令。

这一步之后，项目的骨架和记忆文件都有了。接下来才是真正的开发对话：

按照刚才确认的结构，实现消息接收接口和路由匹配模块。每完成一个模块，运行一次测试。

整个过程中，我只需要在每个阶段性完成后看一眼它的产出，再用/status确认当前状态。这个项目从空目录到第一版可运行，前后约四十分钟，其中大部分时间是它在跑测试，我在旁边看diff。

5.2 线上Bug排查：把日志丢给AI当侦探

遇到生产环境报错，最怕的不是修，是猜。我会先开一个会话，把日志文件加进上下文：

claude /add logs/api-error-20250715.log

然后说：

这个日志里记录了一次接口超时，请先分析日志，找出发生超时的代码路径，告诉我你的定位思路，先不要修改任何文件。

注意后面那句“先不要修改”不是客套，是纪律。它读完日志，会结合项目代码给出排查路径。如果它说“应该在xx文件xx行附近”，我会加一句“请打开这个文件验证一下”，它会自动读取并在/context里可以看到目标文件已经被加载。

确认根因后，让它给修复方案，改完立刻跑单测。如果改完发现引入了新问题，一条/rewind退回上一个状态，重新调整思路。这个流程比我自己翻日志省太多时间了——以前光是把日志和代码对应上就得花小半天。

5.3 提交前审查：让AI读diff而不是你读

提交前审查是我用下来性价比最高的工作流。核心思路：用非交互模式，把git diff直接交给AI分析。

假设我改完一批代码，暂存了准备提交。建立一个shell脚本函数：

review() { git diff "$@" | claude -p "请审查以下git diff，按文件分组输出：1. 安全问题 2. 性能问题 3. 逻辑边界问题 4. 风格问题。如果没有问题就写'未发现明显问题'。" }

然后在终端里运行：

review --cached

它会分析全部差异，输出结构化的审查意见。这个用法最大的好处是：AI看到的是真实的改动差异，而不是泛泛的“请帮我review代码”这种空话。配合交互模式下的/review，我能在提交前发现不少自己漏掉的问题。

5.4 把工作流固化进日常

上面那些工作流，不能每次都手动敲一遍。我的做法是把它们固化在shell配置里。

比如我给自己配了一个“快速开始项目”函数，输入项目描述和目录名，自动创建目录、启动Claude Code并注入初始化提示词。再比如“本地检查”函数，自动跑lint、格式化、测试，然后把结果喂给Claude Code，让它分析失败原因。

quickstart() { mkdir -p "$1" && cd "$1" && claude "我要开发一个$2 项目，技术栈$3，请先完成目录结构设计与CLAUDE.md初始化，再逐步搭建核心功能。" }

工作流固化之后，你不需要每次回忆“该按什么顺序敲命令”，因为工具已经帮你记住了。

6. 上下文、权限与安全：容易被忽略的进阶点

6.1 上下文窗口就是你的工作台

我用下来最大的心得：上下文窗口的管理水平，直接决定了会话质量。Claude Code的上下文是有限的，塞满了无关文件、历史讨论，它会变得越来越“迟钝”。

最好的管理习惯是：一个会话只处理一个主题。做功能A的时候，明确告诉它只改A相关的文件；功能A完成、验证、提交，然后/clear开新会话做功能B。有些懒人图省事，一个会话从早上挂到晚上，功能A、B、C混在一起聊，最后它连你刚才说的版本号都记混了。

我通常在每轮大任务之间看一眼/cost和/context，这两条命令会告诉你两件事：这个会话花了多少钱、当前它心里装着多少东西。超出了合理范围，就果断/export备份，然后/clear重开。

6.2 权限模式怎么配才既顺畅又不失控

Claude Code在操作文件、执行命令之前，默认都会征求你的同意。这很安全，但弹窗多了也确实打断节奏。

我的建议是分场景配置：

• 写代码阶段：把文件编辑权限设为自动接受，因为它改完你还要看diff，自动接受不会造成不可逆伤害。
• 执行命令阶段：保持每次询问。尤其是不熟悉的命令，它跑一个rm -rf之类的高危操作之前，你必须有机会拒绝。
• 纯读代码场景：直接开放所有只读权限，日志随便看、文件随便读，不会出乱子。

如果需要更极端的“只动嘴不动手”，可以进入plan模式。在这种模式下，它不会实际修改文件，而是先给出方案和改动清单，你确认后再切换回正常模式执行。对大型重构，我建议先在plan模式里把方案聊透，再实际操作。

6.3 我踩过的几个坑，以及现在的规避习惯

第一个坑：没写CLAUDE.md就急着让它干活。结果它新会话里完全不记得你项目的目录约定，把代码放错了位置，测试也找不到。现在任何新项目，第一件事就是/init，先立规矩再干活。

第二个坑：让AI在没有任何版本保障的前提下大规模重构。AI改起代码来下手很重，我试过一次让它重构一个几十行的函数，结果它顺带改了依赖它的所有调用点，还把测试文件也动了。现在我的习惯是：让它动手之前，先确认git工作区是干净的，或者明确告诉它“每改完一个阶段，先让我看diff”。

第三个坑：忽略非交互模式输出的格式化问题。用脚本调用claude -p时，默认输出可能带上终端样式字符，导致日志解析错乱。批量处理场景，我会显式指定纯文本输出格式，再配合JSON格式做结构化解析，这样pipeline才稳定。

第四个坑：把数据隐私当不存在。终端助手能看到你项目里的代码、日志、配置，有些文件可能是敏感信息。不要往公共项目或心怀侥幸的目录里塞密钥，权限配置也要收敛。AI助手好用，但你永远是第一责任人。

写在最后

我实际操作几次之后最大的感受是：Claude Code把“和AI结对编程”这件事的门槛拉低到了“会开终端”就行，但天花板拉得很高——它好用到什么程度，取决于你会不会管理上下文、会不会配置权限、会不会把命令组合成工作流。刚开始用的时候，别急着改造整个开发流程，先从“让AI帮你读日志”“让AI帮你审查diff”这两个小场景练手，跑顺了再过渡到让它独立改代码。等你习惯了在终端里和它对话，再回到网页版聊天框，会很怀念这种“它真的动过你代码”的感觉。记得定期git commit，那是你最后一道安全网。