企业官网建设流程全解析

现在打开终端，我每天敲的第一个命令往往不是git status，而是claude。Claude Code 这款跑在终端里的 AI 编程助手，已经快成为我开发工作流里的默认配置。它不是网页里聊两句、生成一段代码让你自己贴回去的那种玩具，而是一个真正能读你项目、改你文件、执行命令的 Agent 工具。这篇内容不是官方文档的复读，而是我把一个完整功能从需求拆解到落地验证全流程走了一遍之后，整理出来的实战记录，适合正在观望、还没决定要不要上手的开发者，也适合已经装好但整天只会让它"写个排序算法"、完全没有把效率用出来的朋友。

先说结论：如果只把 Claude Code 当成一个"能打字的 ChatGPT"，那你大概率感受不到它的价值，甚至会觉得权限弹窗很烦。只有把它嵌进你的日常工作流，让它参与读代码、改代码、跑测试、过 review 这套完整流程，你才会发现这个工具真正厉害的地方在于"它在你的项目里"，而不是"它什么都会"。

1. 为什么我最终把 Claude Code 留在工作流里

1.1 Claude Code 到底是什么，和网页聊天式 AI 有什么区别

很多第一次接触的人会问：这不就是命令行版的聊天机器人吗？不是。聊天式 AI 是"咨询顾问"，你描述问题，它给你一段建议或代码，然后你自己去改、去跑、去试错，来回切换的成本全在你身上。Claude Code 更像是"一个有权限动手的协作者"，它直接运行在你的项目目录里，可以读你的源代码、搜索关键词、编辑文件、执行测试命令，甚至帮你操作 Git。

这个区别决定了完全不同的工作方式。网页 AI 的交互单元是"一个问题 + 一段回答"，而 Claude Code 的交互单元是"一个任务 + 一系列操作"。比如你让它"把订单列表接口加上按状态筛选的参数"，它不会只给你一段代码就完事，它会先去读你的接口文件，理解现有的参数校验逻辑，然后修改代码，再跑一遍相关测试确认没有破坏别的功能。整个过程你可以观察它的每一步操作，中途叫停、纠正方向、审查 diff。

还有一个细节：它的一切操作都发生在你的终端里，所以你不需要把代码复制到网页上，这对很多公司尤其是对代码保密要求比较高的团队来说，本身就解决了一个大问题。

1.2 它解决了我工作里哪几个真实痛点

第一个痛点是上下文切换太碎。以前写一个功能，我至少要同时开着编辑器、终端、浏览器，在代码、报错、文档之间来回横跳，经常一上午过去发现没写几行。现在我会把"读懂这段存量代码""帮我找这个函数在哪定义""这个报错可能是什么原因"这些事直接丢给 Claude Code，它在终端里就能完成，我不用切窗口。

第二个痛点是机械重复劳动。起新文件、写模板、补测试用例、整理 TODO、生成 changelog，这些事不复杂但非常耗时间，而且做得多了容易出错。把这些事情交出去之后，我可以把注意力放在真正需要判断力的地方，比如模块怎么拆分、接口怎么设计、边界条件怎么处理。

第三个痛点是理解存量代码。接手一个别人写的模块时，最花时间的不是写新代码，而是搞懂旧代码为什么这么写。Claude Code 可以在一分钟内扫完整个目录结构，然后给我一份"这个模块的职责、依赖关系、数据流向"的说明，相当于一个熟悉项目的老同事给我做了个快速 onboarding。

1.3 哪些场景适合，哪些场景别硬扛

我用下来的体感是，这几类场景最值得用它：原型验证、重构、补测试、阅读存量代码、写一次性脚本、生成 commit message。这几类工作的共同特点是"过程性动作多、结果可被快速验证"，非常适合交给 Agent 去执行。

反过来，有些场景我不建议把它当主力。比如线上事故正在发生时，你需要的是冷静的人工判断和快速止损，这时候让 AI 东查西改反而添乱。再比如涉及核心安全模块的代码审查，AI 可以辅助找问题，但最终拍板必须是人，而且要保留完整的人工复核记录。工具是放大器，你的判断力才是底盘，这一点我后面还会反复提到。

2. 上手之前必须搞懂的几个核心概念

2.1 终端里的 Agent 模式和会话机制

Claude Code 不是每次运行都从零开始的。它在本地维护会话记录，当你运行claude进入一个新会话，或者用claude --resume恢复之前的会话时，它能记得上下文里发生过的对话和操作。这一点很重要，因为开发一个功能往往不是一次交互就完成的，中间你可能要关终端去开会、或者切到别的项目，回来之后--resume能让你接着上次的进度继续，而不是重新解释一遍需求。

会话里还支持/clear和/compact。/clear会清空当前上下文，适合一个任务彻底结束的时候用；/compact则会把前面的长对话压缩成摘要，释放上下文空间，但同时保留关键信息。开发到一半发现它开始"忘记"前面说过的话时，我会先/compact而不是重新开一个会话，因为重开会话意味着它要重新读项目、重新理解需求，反而更慢。

2.2 权限模型：你允许什么，它才能动什么

这是新手最容易忽略、也最容易误解的部分。Claude Code 默认并不会随便动你的文件系统，每当你让它执行可能产生副作用的操作——比如写文件、执行命令、修改 Git 状态——终端里都会弹出权限确认。你可以选择允许一次、允许所有、或者拒绝。

我强烈建议第一次使用的人不要图省事直接"允许所有"。更稳妥的做法是先拒绝，观察它打算执行什么操作、操作用在哪个文件上，确认没问题再放行。用几天习惯了之后，你可以把一些低风险目录比如测试目录、临时脚本目录加入预授权列表，减少弹窗打断，但涉及关键目录和危险命令（比如rm、git reset --hard）时，我仍然会保留手动确认。这跟给新同事开通服务器权限是一个道理：最小权限原则永远是对的。

2.3 CLAUDE.md 是给 Agent 看的项目说明书

Claude Code 会读取项目根目录下的CLAUDE.md文件，把它当作项目的长期记忆。你可以把它理解成一份"给 AI 同事的入职文档"，而不只是给人类看的 README。它和 README 的最大区别是：README 主要面向人类读者，说明项目怎么用；CLAUDE.md面向 AI 工作者，需要写清楚项目怎么构建、怎么测试、代码风格是什么、目录职责是什么、有哪些禁区。

我项目里的CLAUDE.md一般包含这些内容：

• 技术栈和版本：语言版本、框架、包管理器
• 常用命令：怎么安装依赖、怎么跑测试、怎么启动本地服务
• 目录结构：每个关键目录的职责说明
• 编码约定：命名风格、错误处理方式、禁止使用的模式
• 禁区：比如"不要修改 migrations 目录"、"不要把密钥写进任何文件"

写一次配置，后续每次会话都能省下大量解释成本。这非常像给团队里的新人写 onboarding 文档，写得越具体，协作越顺畅。

2.4 它能用的工具集

Claude Code 能操作的能力大致分几类：读文件、搜索代码、编辑文件、执行终端命令、调用外部工具。你不需要记住全部工具名，但需要了解这个能力边界，因为当你分配任务时，你是在给一个"具备工具的人"派活，而不是给一个"只会说话的模型"出题。

比较有用的一个点是：当你希望它先调查再动手时，可以直接命令它"先读这些文件、不要修改代码"。它会照做，并且把分析结果给你看，相当于你让它执行了一个只读任务。当你希望它改完一个文件停下来让你确认时，也可以明说"每改完一个文件，先输出 diff，等我确认再继续"。它在这种细粒度控制上做得比我想象中好，前提是你要主动表达。

3. 环境准备与初始化配置

3.1 安装与认证

安装方式官方文档写得很清楚，常见的是通过 npm 全局安装官方 CLI 包，或者使用官方提供的原生安装器，具体方式以你操作系统的官方说明为准。安装完成后，在项目终端里输入claude，就会进入初始化流程。

认证环节有两个主要路径：登录订阅账号，或者配置 API 密钥相关的环境变量。具体用哪个取决于你的付费方式和额度来源，建议刚上手时先走订阅账号的登录流程，因为它对额度消耗的感知更直观。我之前有段时间同时开着网页端和终端端，结果额度消耗速度超出预期，后来才学乖——终端会话也是要消耗上下文的，不是免费的无限劳动力。

3.2 项目级配置与权限预授权

初始化完成之后，我建议做三件事：第一，在项目根目录创建CLAUDE.md；第二，按目录设置权限预授权；第三，调整它操作时的"谨慎程度"。

权限预授权是减少弹窗的关键。如果你的项目有明确的tests/、scripts/这类低风险目录，可以把它们加入预授权，这样它改测试代码时不再打断你。但我会刻意保留对根目录配置文件和锁文件的确认，因为你不想它某天顺手改乱了.gitignore或者package.json的依赖版本。

CLAUDE.md的写法有讲究，我自己的模板大致长这样：

# 项目记忆 ## 技术栈 - Python 3.11 / FastAPI / PostgreSQL - 前端使用 React 18 + Vite ## 常用命令 - 安装依赖: pip install -r requirements.txt - 启动服务: uvicorn app.main:app --reload - 跑单元测试: pytest tests/ ## 目录职责 - app/api/ -> 接口路由，只处理请求参数和响应 - app/services/ -> 业务逻辑，禁止在 route 里写复杂逻辑 - app/models/ -> 数据模型 ## 编码约定 - 新接口必须包含请求参数校验 - 错误信息统一用中文，且必须包含足够上下文 ## 禁区 - 不要修改 migrations 目录 - 不要把任何密钥硬编码到代码里 - 改动接口前先检查是否有调用方依赖旧字段

这份文件写得好不好，直接决定了它后续给你干活的质量。我遇到过很多朋友反馈"Claude Code 经常理解错我的项目"，点开他们的项目一看，根本没有CLAUDE.md，它的所有认知都是每次会话临时读代码拼凑出来的，自然不稳定。

3.3 常用命令速览

这里整理一份我在日常工作中使用频率最高的命令清单：

这份清单不需要一开始全记住，先掌握claude、--resume、CLAUDE.md这三个，就能覆盖大部分场景。剩下的等你用多了自然会发现"原来还可以这样"。

4. 全流程实战：把一个小功能从需求推到落地验证

4.1 场景设定与预期管理

我用一个虚构案例来演示完整流程。场景是某内部管理系统，目前订单列表只能全量展示，产品希望增加"按状态筛选 + 导出当前筛选结果为 CSV"的功能。这个任务包含接口参数扩展、前端筛选交互、导出文件实现三个子任务，非常适合作为实战演示。

在开始之前我要先明确预期管理：它不是一次到位的神器。我的经验是，越是复杂的任务，越要拆成小步骤一步一步推进。每完成一个阶段就停下来人工确认，再去下一个阶段。表面上看起来多花了几轮交互，但总时间反而最短，因为它不会带着跑偏的理解改一堆代码最后全部推翻重来。

4.2 第一步：让 Claude Code 先"读懂"项目再动手

进入项目目录，运行claude之后，我不急着提需求，而是先说一句话：

"先不要改任何代码。请先阅读项目 README、package.json、app 目录下的路由入口，然后给我一份你对这个项目的理解，包括技术栈、目录结构、订单模块相关的文件位置。"

这一步非常关键。几乎所有翻车的案例，都是因为用户一上来就提需求，而 AI 对项目的理解是残缺的，它只能"猜"着改，最后改错地方。先让它输出理解，本质上是在校准认知。我拿到它的理解报告后，快速核对一遍，如果有偏差立刻纠正，比如告诉它"订单接口不在 app/api/order.py，而在 app/routers/trade.py"。

校准完认知，才进入真正需求阶段。

4.3 第二步：把需求拆解成可执行的子任务

确认它理解了项目结构之后，我会这样描述需求：

"订单列表接口需要增加一个状态筛选参数，状态取值范围是 pending、paid、refunded。同时增加一个导出入口，导出内容为当前筛选条件下的订单字段列表，CSV 格式。要求改动尽量小、不涉及现有前端联调变更，并且给出你的任务拆解步骤。"

它会输出一个任务列表，类似于：

1. 阅读现有订单查询逻辑，确认筛选条件如何拼装
2. 修改接口函数增加status参数，并在查询条件中过滤
3. 补充参数校验逻辑，非法状态返回 400
4. 实现 CSV 导出函数，处理中文字段名编码问题
5. 补充或更新测试用例
6. 运行测试确认无回归

看到这个列表，我会明确告诉它："按顺序执行，每完成一步、输出这一步的 diff 和说明，等我确认后再继续下一步。"这一步是防止它一口气改太多、最后难以 review 的关键手段。

4.4 第三步：核心实现与人工 checkpoint

在接下来的执行过程中，我实际上做的就是一个"项目经理"的工作：看它每步的 diff，确认方向没有跑偏，有问题及时纠正。

举个例子，它在实现 CSV 导出时，最初方案是直接把中文字段名写入文件。我提醒它："内部系统导出给财务用，字段名保留英文标识，加一行表头映射说明即可。"它立刻调整了方案，而且没有抱怨、没有推卸责任，这个体验真的是传统开发流程里没有的。

真正有价值的时刻出现在它修改查询逻辑时。它发现现有代码里status字段在数据库中的存储值是大写枚举，和接口定义的参数不符。它主动停下来问我："是保持接口接收小写、内部转换，还是统一成大写？"这说明它真的读了代码、发现了潜在问题。我选择了接口接收小写、内部转换的方案，因为外部调用方已经习惯小写参数。这个问题的发现让我挺意外，也让我意识到只要给它足够的上下文和明确的检查要求，它确实能承担一部分"代码审查"的工作。

经过来回三轮确认，最终改动涉及两个后端文件、一个前端文件、一个测试文件，整体 diff 控制在合理范围内。从启动到功能可用，大约用了二十分钟，其中人工确认占了大部分时间，真正需要我动手写代码的时间几乎为零。

4.5 调试时的高效提问方式

项目里不可能每次都一帆风顺。开发到中途，测试用例跑挂了一次，报错信息指向数据库查询超时。这个时候提问方式就非常关键。

低效的提问是："查订单怎么超时了？帮我看看。"这个问题里没有位置、没有堆栈、没有任何上下文。AI 只能猜，猜的效率自然低。

我习惯的做法是三步走。第一步，粘贴完整报错信息；第二步，给出触发场景；第三步，要求它"先复现、再解释、最后动手改"。

我实际上的提问是：

"测试用例 test_order_fiter 执行时报错：Connection pool timeout after 5 seconds。这个用例会连续发起 10 个查询请求。请先检查连接池配置是不是有问题，再解释超时原因，先不要改，给出你的分析。"

它分析后发现是测试用例没有复用已有的连接、每个请求都新建连接导致连接池耗尽，问题不在产品代码而是测试代码的写法。这个判断非常准确，而且因为它先分析再动手，避免了误改配置。调试的关键不在于 AI 有多聪明，而在于你给它多少有效信息、要求它按什么顺序执行。

4.6 补测试与跑通验证

功能开发完成后，我会要求它"列出当前功能涉及的测试覆盖情况，补上缺失的用例，然后完整跑一遍测试套件，输出结果"。它会先读现有测试文件，理解风格，再补用例。这一步我观察到它特别擅长复刻现有测试风格，而不是另起炉灶写一套风格迥异的测试。

补完用例之后，完整的测试套件跑通了，我还会额外加一个要求："把测试结果贴出来，并说明哪些用例是新增的、覆盖了什么场景。"这样不仅验证功能，也完成了可追溯的记录。后面如果要写合入描述，直接抄这些说明就行。

5. 代码审查与重构的正确打开方式

5.1 用 AI 做 code review 的三层策略

我现在养成一个习惯：每次准备提交代码前，先让 Claude Code 对当前工作区改动做一轮 review，然后再人工复核。这一步可以在会话里直接说："请对当前 git diff 做一次代码审查，按逻辑错误、边界条件、安全问题、代码风格四类输出发现的问题。"

第一层是它自动读 diff，输出问题列表。这里面最好用的是"逻辑错误"这一类，因为 AI 对于"这个分支条件覆盖不完整""这个字段可能为空但没有判空"这类问题很敏感，而且不会因为面子问题放过明显错误。

第二层是它作为"对抗方"去思考："如果你是测试人员，专门想破坏这个功能，你会从哪里入手？"这种思维反转能找出不少正常开发视角遗漏的边界条件。比如之前我让它查一个文件上传接口，它问"如果上传文件名包含路径分隔符会怎样"，一查发现确实存在路径拼接隐患。

第三层才是人工复核。AI 的 review 再全面，也不能替代人对业务的理解和最终责任。我一般会在它输出的 warnings 里优先看高等级问题，确认修复方案，低等级问题批量处理。

5.2 重构场景下的约束表达

重构是 Claude Code 非常擅长、但约束条件必须写清楚的场景。核心原则是"外部行为不能变，内部结构随便改"。我通常会这样下指令：

"将 app/services/order_service.py 中的 handle_order_状态机逻辑抽成独立的模块。要求：不改变任何接口签名和返回值；保持现有日志格式不变；重构完成后完整跑一遍测试套件确认无回归。"

这样表述的好处是给它明确了"什么不能动"，它就能大胆地在"能动的部分"上做文章。我见过最难用的用法是只说"帮我重构一下这个文件"，这不仅会导致它过度发挥——改完所有代码风格全变了，还会让 review 成本飙升。

重构过程中，我更推荐"渐进式重构"，一次只抽一个模块。不要让它一口气把整个服务拆成十个文件，那样你会收到一个完全陌生的代码库，review 时脑袋都是蒙的。一次让它动一个职责，改完测试通过，再动下一个，虽然多几次往返，但每一步都可控、可回滚。

5.3 和 Git 工作流的配合

Claude Code 与 Git 的配合是很多人的隐藏痛点。它默认可以执行 Git 命令，比如查看状态、生成 diff、甚至提交，但这些操作都需要权限确认。我的使用习惯是：它负责"读"，我负责"写"。也就是说它帮我分析git diff、生成 commit message，但实际的git add和git commit由我手动执行。这样即便它理解错了，也不会污染提交历史。

还有一个特别实用的场景是提交前检查。我会让它扫一遍当前的 diff，专门找有没有遗留的调试输出、临时注释、硬编码密钥、调试用的死代码。这个检查在人工 review 里经常被忘记，AI 反而能稳定执行。

此外，我还发现它可以帮我把一次提交拆成多个逻辑独立的 commit。比如我改了接口、前端页面、测试三个部分，让它按变更逻辑生成三个 commit message 和对应文件清单，我再复核后按清单提交。这个流程肉眼可见地提升了提交历史的整洁度。

6. 常见问题与排查技巧实录

6.1 上下文不记得前面的内容怎么办

使用时间长一点之后，你大概率会遇到"它开始忘记前面说过的话"的情况。典型表现是：你半小时前明确告诉过它"不要动 migrations 目录"，但它后来又开始讨论 migrations 里的内容。

这不是它故意的，是上下文窗口被长对话撑满了。解决方案我按优先级排列：第一优先是/compact，压缩当前对话；第二优先是--resume恢复旧会话而不是重新问一遍；第三优先才是在CLAUDE.md里把那些"绝对不能改"的约束写死。如果你频繁遇到这个问题，更根本的解决方式是拆分任务，一个会话专注一个功能，不要什么都塞在一起。

6.2 权限确认太频繁怎么优化

刚开始用的时候，每个操作都要确认，体验确实很打断节奏。但我还是不建议直接全部放权。我自己的平衡方案是：把确定安全的目录加入预授权，比如tests/、scripts/、docs/；把关键文件保留确认，比如package.json、pyproject.toml、migrations/；对于危险命令如rm -rf、git reset --hard永远要求确认。

如果你发现某个操作频繁触发确认，但实际每次都放行，也可以考虑把这条命令或这个文件加入允许列表，关键是你要理解放权意味着什么。权限不是挡路的，是保险带。

6.3 它改了不该改的文件怎么回滚

这种情况一旦发生，先别慌。它改的每个文件都在工作区里留下足迹，你可以立刻说"停止当前所有操作"，然后切换到终端查看git status和git diff，确认哪些改动不是你想要的。对于误改的文件，用git checkout -- <file>恢复即可。

恢复之后要做两件事。第一，向它说明误操作的范围，问它是否理解原因；第二，在CLAUDE.md或当前会话里补充限制条件，避免再犯。最让我头疼的一次是它改了一个.env.example文件，虽然只是示例文件，但说明它没有严格遵守"不要动环境相关文件"的约束。自那以后我把"环境相关文件一律只读，除非单独确认"写进了项目的CLAUDE.md。

6.4 结果不稳定、时好时坏怎么办

AI 生成结果本身带有一定随机性，同样的问题换个问法可能得到不同答案。这不是 bug，是模型采样机制决定的。要让结果更稳定，我有几个实用习惯：第一，在提问时加上"先给出你的理解和执行计划，不要马上动手"，先对齐再执行；第二，关键要求用否定句式强调，比如"不要修改接口签名""不要动现有日志格式"，否定式约束往往比肯定式更有力；第三，对于复杂任务，明确要求它分步骤执行，每步确认后再继续。

如果多次尝试仍然不稳定，优先检查是不是上下文太长导致的注意力稀释。/compact之后重新提问，往往马上稳定下来。最后再提一点，不同模型的回答风格差异很大，如果你用 API 密钥接入其他模型，会遇到行为差别更明显的情况，这时候更要强调"先给计划再动手"的交互模式。

6.5 常见问题速查表

7. 日常提效的一些小习惯

7.1 把常用操作沉淀成斜杠命令

Claude Code 支持自定义斜杠命令，你可以把常用的操作模式存下来。比如我配置了一个checkdiff命令，内容大致是"请审查当前 git diff，按逻辑错误、边界条件、安全问题、代码风格四类输出，所有输出用中文"。之后我每次要 review 代码，只需要输入/checkdiff。

这有点像把一位老师傅的检查清单固化下来，每次自动执行，不会因为状态不好而漏掉某个检查项。沉淀命令的过程本身也是在整理自己的工作方法，你会越来越清楚哪些操作是高频、可模板化的。

7.2 维护一份"长寿"的 CLAUDE.md

我给每个长期项目都维护一份CLAUDE.md，而且会和项目一起演进。每当项目新增模块、换框架、改命令时，我会顺手更新这个文件。它就像项目的"活字典"，Claude Code 每次会话都靠它快速进入状态。

关于CLAUDE.md的更新，我还有一个私人技巧：在文件末尾加一个"常见需求约定"段落，把经常被反复交代的要求写进去。比如"导出功能必须加 UTF-8 BOM，否则 Excel 打开中文会乱码"，这种细节靠每次对话临时交代很容易忘，写进配置之后它每次都会自动带上，省心很多。

7.3 我自己的"AI 使用规范"

用得越久，我越觉得给它定规则比教它技能更重要。我的CLAUDE.md里固定维护几条红线：

• 禁止把密钥、token 写进任何文件
• 读取.env文件后禁止把内容输出到对话里
• 修改数据库相关文件前必须给出影响分析
• 每次需要人工确认的动作，必须明确提示"需要确认"

这四条规则让我在使用时非常安心，也大幅减少了事故率。放开手脚让它干活的底气，恰恰来自于这些严格的边界。工具越是强大，使用者越要清楚什么不能让它碰。

7.4 最后分享一个真实的小经验

如果让我只保留一条建议给所有刚开始用 Claude Code 的人，我会说：永远不要让它"一口气完成整个大功能"。把大功能拆成阶段、每阶段小步快跑、每步都过目，体验会完全不同。有一次我图省事，让它同时改十个文件、加缓存、加权限逻辑、再优化查询，结果 diff 铺开八百多行，review 改到怀疑人生。从那以后我再也不偷这种懒了。

另外一个小技巧是：善用"反问"。当你不确定它理解得对不对时，不要直接问"你懂了吗"，它大概率会说懂了。要让它用一句话复述你的需求，或者让它先列出它准备执行的步骤，从它的复述里你能立刻判断出有没有跑偏。这个技巧成本极低、收益极高，强烈建议试一试。