企业官网建设流程全解析

1. 智能体的工作边界：为什么Claude Code和聊天窗口是两种东西

我用Claude Code大概有半年了。刚开始那阵子，它就是我的“高级聊天框”——我把代码粘进去，让它找bug、写函数，再把结果粘回来。直到有一个周末，我试着让它自己去修复一个测试失败，它在终端里自己跑了测试、改了代码、又跑一遍，最后给我看diff的时候，我才意识到这东西和ChatGPT完全是两个物种。

Claude Code这类AI编程智能体，最核心的差别在于：它不只是“生成文本”，而是在一个真实的工作环境里有执行权限。它可以读取文件、修改代码、执行shell命令、运行测试、甚至提交git。也就是说，它在终端里拥有一个“可操作的沙盒”，而不是一个只能输出文字的聊天框。这个边界决定了你所有的高阶用法都建立在一个认知上：你不再是把需求翻译成代码的人，你是在调度一个能自己动手的“外包工程师”。

这个“外包工程师”的心智模型非常关键。你雇外包工程师，不会把整个仓库一骨脑丢给他然后等结果，你会给需求文档、给范围边界、给验收标准、给禁止事项。你对Claude Code做的事情也一样：写CLAUDE.md给它当“入职手册”，用自定义命令给它搭“标准作业流程”，用权限配置给它画“禁区红线”。

很多人用不好AI编程，根源就是没有切换这个心智模型。他们以为自己在“和AI聊天”，实际上应该是在“管理一个远程工程师”。聊天式的对话产生的输出是随机的、松散的；而管理式的交互产生的输出是有约束的、可复现的。这个区别，是后面所有高级技巧的出发点。

1.1 从“被动的问答”到“主动的调度”

普通聊天AI的使用方式是：你提问，它回答。这带来两个问题：一是你仍然需要自己把回答搬到项目里，搬运过程中上下文就断了；二是AI对项目的理解始终隔着屏幕，它对“这个项目现在到底处于什么状态”没有感知。

Claude Code改变了这个关系。举个最简单的例子：你让它“修复登录接口的400报错”，它不会直接给你一段代码让你自己去替换，而是会先看一下路由定义、再看一眼处理函数、查一下参数校验逻辑、定位到具体哪一行返回了400，然后动手改，改完跑一下相关测试。整个过程里，你只给了初始指令，剩下全是它自己完成的。

这种从“被动的问答”到“主动的调度”的转变，带来一个直接结果：你的工作重心从“写代码”变成了“定义问题和验收结果”。你花时间想清楚“什么算修复完成”，比花时间想清楚“怎么修”更值钱。这也是为什么我后来花了很多精力去打磨那些提示词和配置——因为调度质量直接取决于你定义目标的清晰程度。

1.2 它能做什么，不能做什么

如果给Claude Code的能力边界画一张表，大概是这样的：

它不能做什么？最重要的两点：第一，它对项目“全貌”的理解是碎片化的，每次读取文件都是重新拼图；第二，它没有持久记忆，跨会话后需要靠CLAUDE.md和文档来重建上下文。理解这两条限制，你就知道为什么上下文管理能力，比提示词技巧更决定实际效果。

2. 把CLAUDE.md当成软件的入职手册来写

说到Claude Code真正拉开差距的地方，CLAUDE.md绝对排第一。这个文件是给AI看的“项目说明书”，每次启动时它都会被加载进上下文，相当于智能体的“工作记忆起点”。

我见过很多人完全不写这个文件，每次会话都靠对话里临时交代项目背景；也有人写了一堆“你是全能的编程助手”这种废话。这两种都等于没写。CLAUDE.md不是给AI打鸡血的，它是一份可执行的工程规范，目的是一开始就让AI知道：项目是什么结构、代码按什么风格写、测试怎么跑、哪些事情绝对不许做。

2.1 三个层级的规范文件

Claude Code会依次读取不同层级的CLAUDE.md，你可以利用这个分层机制做配置。

• 用户级：存放在用户目录下，适用于你所有的项目。适合放个人偏好，比如“永远不要修改package-lock.json”“提交信息用英文”等。这层相当于你个人的通用职业习惯。
• 项目级：存放在项目根目录，这是最核心的配置。适合放项目的技术栈、目录结构、测试命令、代码风格、部署注意点等。
• 目录级：可以放在子目录里，适合针对特定模块的补充规范。比如在src/api目录下放一份，说明“所有接口必须带版本前缀”之类的局部约束。

层级越高，越接近个人习惯；层级越低，越贴近模块细节。这样做的好处是，你不需要在项目根目录那个文件里堆一大堆局部逻辑，每个文件只保留该层最该说的东西。

2.2 我最推荐写进去的五类内容

我在项目级的CLAUDE.md里，通常固定写这五块内容：

第一，项目结构与目录职责。直接告诉AI哪些目录放什么。比如“业务逻辑在src/services，接口定义在src/controllers，测试文件和源码同目录”。AI少了一堆“探索性”的路径猜测，少走很多弯路。

第二，常用的开发命令。写清楚“测试用npm test，单测单个文件用npm test -- path，构建用npm run build”。每次都要AI自己从package.json里猜命令，既浪费tokens又容易猜错。

第三，代码风格约束。不需要写“请写出优雅的代码”这种空话，而是具体的规则：“ES模块优先，禁止require”；“错误处理统一用Result对象，禁止裸throw”；“所有时间字段统一ISO8601格式”。这些规则越具体，AI产出越可控。

第四，绝对禁止事项。这是最容易被忽略但最该写的。比如“禁止格式化整个文件”“禁止升级依赖版本”“禁止修改数据库迁移脚本”。没有这些红线，AI会在你不注意的时候“好心办坏事”。

第五，当前已知问题与注意事项。比如“后端用了自定义的鉴权中间件，新加的接口如果没加白名单会被拦截”，这种项目经验，对AI来说比任何编码规范都值钱，因为这是从测试和线上错误里总结出来的隐性知识。

2.3 一个可直接改用的示例

下面是我在某内部项目里实际写过的CLAUDE.md片段，你可以参考格式改写成自己项目的版本：

# 项目：某内部报表服务 ## 技术栈 - Node.js 22 + TypeScript，使用ES模块 - 框架：Fastify - 数据库：PostgreSQL，通过Prisma访问 ## 常用命令 - 安装依赖：npm install - 单元测试：npm test（对应 vitest） - 单测单个文件：npx vitest run src/xxx.test.ts - 类型检查：npm run typecheck - 启动本地服务：npm run dev（端口3100） ## 目录约定 - src/routes：定义所有HTTP路由 - src/handlers：业务处理逻辑，禁止在routes里写业务 - src/lib：通用工具函数 - prisma：数据库schema和迁移文件 ## 代码风格 - 必须使用TypeScript，禁止any - 时间字段统一new Date()，输出时格式化为ISO字符串 - 日志使用项目的logger实例，禁止console.log - HTTP接口返回结构统一为 { code, data, message } ## 禁止事项 - 禁止直接修改 prisma/migrations 下的历史文件 - 禁止升级package.json中依赖的major版本 - 禁止删除routes下已注册的路由，若有改动需同步更新文档 ## 已知注意点 - 服务启动时会执行 healthcheck 路由，改动该路由会影响部署探活 - Prisma的client需要在修改schema后重新生成，命令：npx prisma generate

写完这份文件之后，你会在实际使用中不断“喂”它——每次AI踩了一个坑，你就把对应的规则补进去。这样CLAUDE.md会随着项目一起进化，AI的表现也会越来越贴合这个项目的具体情况。

提示：CLAUDE.md不需要写很长，它是给AI看的“快速启动文档”，不是给团队看的wiki。能放在代码注释和文档里的，不要重复堆进去。原则是让AI花最少的时间搞清楚“默认行为”是什么。

3. 上下文窗口的消耗逻辑与长任务记忆规划

第二个让很多人卡住的点，是上下文管理。Claude Code的上下文窗口是有限的，但你处理一个真实项目，往往要读十几甚至几十个文件，来回执行和查看输出。如果不会规划上下文，会话一长，AI就会“健忘”：忘了最初的约束、开始自作主张、甚至开始编造不存在的函数。

我自己早期栽过一个大跟头。某次在一个重构任务里，我连续两个多小时和它不断交互，改了十几个文件。到后半程它突然开始“发挥创造力”，把一些此前说好不动的公共函数顺手“优化”了。我后来复盘，原因就是上下文被各种中间过程填满了，最初的约束条件被挤出了有效窗口，它只能靠残缺的记忆续写，结果就是跑偏。

3.1 上下文消耗的三大元凶

围绕这个问题，我总结出三个最主要的上下文消耗源：

第一，让AI“开卷”全文而不是“按图索骥”。比如你让我看某个文件，如果你直接说“打开src/handler.ts分析一下”，它会读入整个文件；如果你说“用grep查一下handler.ts里所有包含‘status’的地方，并显示行号”，它只用很小的代价就完成了同样的目标。多数情况下你不需要整个文件的内容，你只需要文件里的某几个片段。

第二，依赖对话里的来回问答来传信息。每轮对话都在消耗上下文，问题越长、回复越长，占用越多。很多信息其实可以一次性通过CLAUDE.md或临时指令给足，不需要通过十几轮“追问-回答”的方式传递。

第三，让小修改必须“大动干戈”。比如只改一个函数参数名，AI却把整个文件的diff都打出来给你看。效率高的时候，你可以用命令行的/compact或auto-compact功能把历史摘要化，但这个动作本身也会丢失细节。所以治本的方法，是控制每一步的输入输出体量。

3.2 先探测再动手的工作习惯

我现在用这套“先探测再动手”的流程，上下文消耗比之前少了一大半：

1. 先小范围侦查：让它用ls、grep、find这些轻量命令了解目录结构和关键符号，而不是“打开整个项目”。
2. 只读必要的片段：基于侦查结果，只需要精确到文件、行号、函数名再去读取。
3. 动手前先输出计划：让它先给出将要修改的文件列表、每个文件的改动点、预计影响范围，你确认后再开始改。这既能防止方向跑偏，也能把“探索性试错”压缩到最小。
4. 一个大任务拆成多个子会话：每个子会话只针对一个独立模块，做完将结论沉淀到文档，再关掉开下一个。这样每个会话的上下文都能保持干净和完整。

3.3 长任务会话里的“里程碑存档”

如果确实需要一个长会话来串一个跨模块的任务，我最常用的方法是“里程碑存档”：每完成一个阶段，就要求AI把该阶段的改动和原因汇总，并写到一个独立文档里。这个文档既是项目资产，也是后续会话的“已用上下文备份”。即使会话最终因为长度问题被压缩了，你仍然可以从存档里恢复关键信息。

这里有个细节：存档不要只写“改了什么”，还要写“为什么这么改”。因为上下文丢失后，AI看到代码diff可能无法理解设计意图，而“为什么”才是让它在后续修改中保持一致性的关键。我甚至会把“曾经否决过的方案”也记进去，避免它绕半天又绕回已经被否掉的路上。

4. 把重复劳动交给自动化：hooks与自定义命令的实战组合

上下文管理管的是“每次会话里的效率”，而hooks和自定义命令管的则是“跨会话的稳定性”。这两个功能是我用了几个月之后，觉得最被低估的能力。

先说hooks。它允许在特定事件触发时自动执行脚本或者截停操作。比如PreToolUse可以在AI准备执行危险命令前自动拦截；PostToolUse可以在每次工具调用结束后做一次自定义检查。对于编程智能体来说，hooks就像给“外包工程师”配了一个项目管理软件，他每次动手前自动跑一遍合规检查。

再说自定义命令。你可以把高频操作封装成“快捷指令”，比如一个/review命令专门做代码审查，一个/test命令专门跑测试并汇报覆盖率。这样一来，每次和AI对话时不用反复敲一整段提示词，而是直接“触发标准流程”。

4.1 一个真实的hooks配置场景

我曾经在处理一个遗留服务的时候，遇到过AI顺手把生产数据库连接字符串写到注释里的情况。它本来是好意，想“方便测试”，但这对安全来说是事故级别的错误。后来我写了一个PreToolUse hook，拦截任何涉及写入包含生产环境关键词文件的工具调用：

#!/bin/bash # 脚本逻辑：如果检测到本次要写入的内容包含生产环境敏感词，则截停 if [[ "$CLAUDE_TOOL_NAME" == "Write" || "$CLAUDE_TOOL_NAME" == "Edit" ]]; then if echo "$CLAUDE_TOOL_RESPONSE" | grep -qiE "prod.*(host|password|secret)" ; then echo "检测到疑似生产环境敏感信息写入，已拦截。请改用环境变量引用。" exit 2 fi fi exit 0

exit 2会直接终止AI这次操作，让用户介入确认。这不是什么复杂的脚本，但它在所有会话里都自动生效，相当于给AI装了一条“安全红线自动刹车”。和一个随时盯梢的配置比起来，靠每次对话里提醒AI“别泄露密码”要可靠得多。

4.2 自定义命令帮AI固定标准流程

另一个高效做法是自定义命令。我建了一个/refactor命令，专门用来做涉及面较广的重构流程：

你是资深代码重构顾问。以下是本项目已知的结构规范，先阅读CLAUDE.md确认约束。 在开始重构前，你必须先完成以下四步： 1. 列出待重构模块的依赖关系 2. 指出重构后可能受影响的调用方 3. 给出具体重构步骤（每步必须可单独验证） 4. 先只改第一步并运行相关测试，等确认后再继续

这样之后每次要重构，我只需要输入/refactor 把order模块的createOrder函数拆出来，AI就会按照设定好的四步来执行，拆完后每一步都测试，而不是一次性把所有逻辑改完然后祈祷不出错。这种“把个人最佳实践固化成指令”的做法，长期来看带来的效率提升是非常可观的。

4.3 让AI跑完整的测试循环

还有一个我高度推荐的工作流，是用Claude Code做“测试循环”。过程是：你写一个失败测试，然后让AI“实现这个测试直到它通过”。这比让它“帮我写完这个功能”效果要好。

原因有两个：第一，测试本身就定义了验收标准，AI不会在功能边界上自由发挥；第二，测试结果是一个明确的信号，每跑一次都告诉你现在的状态是成功还是失败，而不是靠它“觉得完成了”来交差。

我现在日常开发里，很大一部分新功能都是这样完成的：先花10分钟把测试写清楚，然后让Claude Code去“补实现”，自己则在旁边看着它循环、查错、修正。它卡住了我会加入提示，但真正“写业务代码”这件事，很多时候已经不需要我亲自动手了。

5. 一个后端服务重构案例：把零散技巧串成一个完整工作流

技巧讲了一大堆，但不串起来用过一遍，你很难真正体会到这些工具配合起来是什么样子。下面我用自己的一个实际项目来完整走一遍流程，说明从接到需求到最终合入，我是怎么规划这次重构的。

5.1 项目背景与目标设定

背景是一个内部的订单导出服务，代码是两年前从另一个系统里搬过来的，历史包袱很重。重构的目标是把其中的数据导出逻辑拆成独立模块，原来那个近千行的处理函数要拆成粒度合适的单元，并且替换掉里面全部被弃用的日期处理API。迁移前后接口签名保持不变，同时同步迁移相关的测试用例。

一开始我没有直接开工，而是先做“目标定义”。这次重构的验收标准很明确：310个测试用例全部通过，原有接口返回结构不变，日志格式不变。然后我把这几条写成一个方案文档，放到项目根目录，并且作为开启工作会话的前提。这个动作看起来多余，但在后面AI跑偏的时候，它就是我拉回方向的锚点。

5.2 从侦查到动工的第一天

第一天，我没有让AI直接开始改代码，而是先做结构侦查。我让它列出整个src目录的依赖关系、找出哪些模块引用了那个千行函数、把测试文件的相关用例列出来生成摘要。这个过程用的是轻量命令，消耗很小，但产出的“依赖关系图”让后续所有工作都有了一个地图。

接着我让它基于侦查结果输出一份重构图，说明计划把函数拆成哪几个文件、每个文件暴露什么函数、原有引用点如何做适配。我审视了一遍，把其中一处明显会导致循环依赖的拆法否掉，换了方案，才点头让它动工。

5.3 用子会话逐块消化重构

整个重构我拆成了四个子会话，每个会话只处理函数里的一块逻辑，目标是让那一块逻辑及其对应的测试先稳定下来，然后把结果归档到“重构进度文档”。每次新开会话时，我都会把这个进度文档附上，让它在下一块工作时不会丢失上一块的设计意图。

这种“一模块一归档一新会话”的方式，比试图在同一个会话里连续做完全部重构要稳得多。上下文不会膨胀，AI对当前模块的注意力更集中，且即使某一步出错，也不会把前面已稳定的模块整体污染。

5.4 测试循环作为兜底验证

在重构过程中，我不是等着全部改完才跑测试，而是要求AI在每完成一个子任务之后就运行对应模块的测试。某一次它把一个原先公共的工具函数改成内部私有函数，结果相关测试立刻报红。它尝试自行修复，改了几个版本还是失败，于是把问题抛给我。

我一看就知道原因：那个函数被另一个还没重构的模块直接引用了，在重构计划里它理应被迁移，但彼时刚好跨了两个子会话，新会话的AI不知道这个依赖还没处理完。这正是“进度文档”发挥作用的时刻。我把信息补进文档，让它先做适配层，再继续拆解。过程中测出来了两个隐藏的过期API调用，都是通过测试循环“逼”出来的。

5.5 最终合入前的收尾检查

重构完成后，我没有马上结束整个工作流，而是做了一个收尾检查。让AI检查是否有遗留下的死代码，是否所有的新函数都有了对应的单测，以及git diff里有没有夹带与本次目标无关的改动。检查结果里果然是有一个日期格式化辅助函数被顺带改了格式，虽然不影响功能，但会让评审的人困惑。我让AI撤销那处改动，保持diff干净之后才提交。

整个项目耗时大约一个工作日，改动涉及11个文件：新增5个模块文件、删除1个旧文件、改写4个业务文件、更新1个测试文件。期间通过hooks拦截的疑似敏感信息写入发生过一次，自定义命令则让重构流程始终保持“先计划、后执行、每步可验证”的节奏。

这个案例并不是什么火箭科技，它的价值在于：当这些高级技巧被有序地组合成一个工作流时，你面对“可能需要一整天”的大任务，实际需要动手的时间会大幅下降。

6. 权限边界与风险控制：让智能体放手干活但不失控

越往后用，你越会发现真正决定长期体验的不是“AI够不够聪明”，而是“你敢不敢放手让它干”。权限控制做的差的人，要么被AI各种误操作折磨得不敢用；要么反成了一个“盯屏幕的复读机”，完全发挥不出智能体的价值。

6.1 从最小权限开始

这个原则和做系统设计是一样的：一开始只给最小必要权限，按需逐步放大。Claude Code里有命令白名单/黑名单的配置方式。我个人的用法是，在项目初期阶段把危险命令直接加入黑名单，比如在生产环境数据库相关的操作、包管理器的全局安装、文件系统的批量删除。等到项目规范成熟、CLAUDE.md约束也稳定了，再按需放宽一部分。

下面是一个权限配置的示例片段，作用是允许常规git操作和构建命令，但拦截package安装和数据库相关操作：

{ "permissions": { "allow": [ "Git:Commit", "Git:Diff", "Git:Status", "npm run build", "npm test", "npx vitest" ], "deny": [ "rm -rf *", "npm install -g *", "psql *", "DROP TABLE *", "git push" ], "ask": [ "Bash(npm install *)", "Bash(curl *)", "Bash(wget *)" ] } }

可以看到，凡是影响范围大的操作（比如push、全局安装、数据库写操作）要么被deny要么需要人工确认，而常见的开发循环类命令则直接放行。这样既保留了AI的自主执行能力，又把破坏范围限制在可控区域内。

6.2 账号和密钥的保护原则

AI在工作时是有可能把密钥、连接串、Token写进代码或日志里的，这是我看过最多的一个安全风险。我的原则很简单：一切密钥都不进入AI的对话上下文。具体做法是项目里用.env文件管理本地环境变量，代码里只用process.env读取；AI需要看环境变量结构时，往份.env.example给它看，而不是 .env 本身。

配合上一节提到的hooks拦截，双管齐下之后，密钥泄露这类风险基本可以被封死。如果你操作的是更高敏感度的环境，还可以进一步考虑不让AI访问某些目录或文件，这些都可以在权限配置层面直接限制。

6.3 什么时候该打断它，什么时候该信任它

最后聊一点比较难从文档里学到的经验：对AI产出的信任度管理。我发现自己刚开始会陷入两个极端——要么完全不信任它的改动，每个diff都要逐字看，这样效率甚至比纯人写还低；要么在高重复性的机械改动里完全放手，结果偶尔放进来一两个逻辑错误在评审阶段才发现。

我的经验法则是：对“明确目标的机械重构”（如统一格式化、批量替换API调用、补齐测试用例），信任度可以放高一些；对“涉及业务逻辑判断的改动”（如某些边界条件的处理、错误处理策略、性能取舍），一定要让AI先说明理由再审视。当AI的行为和方案文档冲突时，不是去现场解释“你误解了”，而是先暂停，更新CLAUDE.md或进度文档之后，再让它继续。因为问题往往不在它的“理解能力”，而在你的“定义清晰度”。

好的工具用法最终都会沉淀到文件里：CLAUDE.md、hooks脚本、自定义命令、权限配置。这些文件本身，就是你长期使用AI编码沉淀下来的“个人工作流资产”。我现在的习惯是每完成一个阶段项目，就会回顾一下当前这套配置，把这次踩的坑补成规则，把重复劳动提炼成命令，然后这套资产在下个项目里继续为我工作。

我用了一阵子之后最大的体会是：Claude Code真正改变的不是“写代码这双手”，而是“决策这双脚”。你不必再亲自走到代码的每一寸土地上去考察、修整，你要做的是画好地图、定好禁区、设定验收标准，然后让那个能自己走路的智能体去干活。它走偏了，你拉回来；它走顺了，你就把下一块地图画给它。这种协作模式，是我目前遇到过最适合实际项目开发的AI编程方式。

如果你现在正准备把它接入你的主力项目，我的建议是：先别急着上那些花哨配置，第一步，花半小时把CLAUDE.md写好，把测试命令和禁止事项列清楚；第二步，建一个包含“计划-执行-测试”三段式流程的自定义命令；第三步，加一个拦截危险操作的hook。这三件事做完，你就能感受到它和“高级聊天框”的区别了。