企业官网建设流程全解析

1. 从聊天到干活：Claude Code到底把提示词工程变成了什么

先说结论：Claude Code不是又一个能聊天的AI窗口，它是一个跑在终端里的编程agent，能自己读文件、改代码、跑命令、提交commit，甚至起多个子agent并行干活。这意味着提示词工程的核心，从“怎么让模型回答得对”，变成了“怎么让agent把事情做得对、做得稳、不跑偏”。

很多人在Claude Code上栽跟头，根本原因就是还在用聊天窗口的思维写提示词。聊天窗口里你问一句它答一句，答错了你纠正一句就行；但在Claude Code里，你给它一个任务，它会在没有你盯着的情况下连续操作几十步，中间任何一步理解错了，后面全部白干。所以提示词工程的重心，必须从“单次问答的措辞优化”转移到“目标定义、边界约束、信息供给和反馈闭环”上。

我自己用下来的感受是：同样的任务，提示词写得好不好，效率能差出三到五倍。写得差的，agent会在错误的方向上一路狂奔，等你发现时已经改了十几个文件；写得好的，它自己会拆解任务、先看结构再动手、改完自测、跑完给你一份清晰的变更说明。这两者的差距，不在模型，而在提示词工程。

这里要特别强调一个词：上下文工程。现在的提示词工程已经不是单纯研究“怎么写这句话”，而是研究“模型在什么上下文里工作、你给它看什么、让它先看什么后看什么、哪些信息不该给它看”。Claude Code这种agent工具，把上下文工程从理论变成了日常操作——你控制它读哪些文件、先读哪个文件、把什么规则写进它的长期记忆，这些操作比“提示词措辞”本身更影响最终结果。

这套东西适合谁？适合所有在用或打算用Claude Code做实际开发的人，不管你是独立开发者、技术负责人，还是被团队推着尝试AI编程的普通后端。读完你至少能回答三个问题：CLAUDE.md到底该怎么写？任务描述怎么说agent才听得懂？为什么别人的agent不跑偏而你的总在瞎折腾？

1.1 Claude Code的工作方式，决定了提示词怎么写

Claude Code和普通AI编程助手的最大区别，在于它是自主行动的。你给它一个目标，它会自己规划步骤，然后一步步读写文件、执行命令。这个过程中它会频繁暂停征求你的意见，比如要执行危险操作时、要改你没提过的文件时、或者它自己拿不准时。

这种模式带来一个直接影响：提示词不再是一条“指令”，而是一份“任务委托书”。你要像把活交给一个不太熟但能力很强的外包工程师一样，把背景、目标、约束、验收标准、需要避免的事情写清楚，然后才放手让它干。指望一句话就让agent完成复杂任务，基本都会翻车。

另一个关键点是，Claude Code有多个“记忆层”：系统级配置、项目级配置、会话内上下文。这些记忆层决定了它“看问题的视角”。你在系统级里写了“永远不要用console.log调试”，它所有项目都会遵守；你在项目级里写了“本项目的API错误码统一用SnakeCase”，它就只在当前项目里遵守。这种分层机制，就是提示词工程在Claude Code里最具体、最值得下功夫的地方。

1.2 提示词工程的四个关键转变

第一，从“描述答案”变成“描述目标”。普通提示词工程教你说清楚“帮我写一个冒泡排序”，而Claude Code提示词工程要求你说清楚“这个模块需要排序功能，输入是数组，输出是排序后的新数组，不要修改原数组，性能要求是n log n，写在utils/sort.ts里，带上单元测试”。后者不是在描述答案，而是在描述任务的目标、约束和验收标准。

第二，从“措辞优化”变成“上下文管理”。以前调提示词，纠结的是“这句换种说法模型是不是更懂”；现在要操心的是“agent当前看到了哪些文件、有没有被误导、该让它先看README还是先看源码”。这是从提示词工程到上下文工程的跃迁。

第三，从“单轮对话”变成“迭代闭环”。聊天里答错了重新问一次就行，agent场景里要设计反馈机制：让agent自己跑测试、自己检查diff、自己把结果汇报给你。提示词里如果没有“做完了先自测再汇报”这类要求，agent做完就停，你根本不知道它做成什么样。

第四，从“追求全面”变成“控制范围”。一个常见的反面案例是：提示词里写了一大堆“你要注意代码质量、要遵循最佳实践、要处理好边界情况”，结果agent为了满足这条模糊要求，把原本20行的函数重构成了150行的抽象工厂。提示词工程在agent场景下的第一原则是：明确告诉它边界在哪里，而不是告诉它“你要优秀”。

1.3 Claude Code提示词的四层结构

我建议把提示词拆成四个层面，每次写任务时都从这四个维度过一遍：

• 身份与视角：让agent站在什么角色上工作，比如“你是一名熟悉本项目的资深后端工程师”“你要用接手遗留代码的维护者视角看问题”。
• 背景信息：任务相关的前因后果、涉及的文件、已知约束，比如“这个函数目前被三个模块调用，改名需要同步修改这些调用方”。
• 执行路径：明确的操作顺序或操作约束，比如“先读config目录下的文件，再动手改代码”“这个任务不需要修改README”。
• 验收标准：怎么算做完，跑什么测试、检查什么输出、达到什么指标，比如“改完后npm test必须全绿，且diff里不能出现未说明的格式化改动”。

这四层不一定每次都要写全，但写全的时候，agent的表现会稳定很多。尤其是验收标准这一层，很多人会省略，结果agent交回来一个“它觉得做完但根本没验证”的结果。在编程agent里，没有验收标准的任务，和没有测试的代码一样不可靠。

2. CLAUDE.md：给agent写的项目说明书

Claude Code有一个特别重要的机制：CLAUDE.md文件。它会随每次会话自动加载，相当于agent在进入你的项目时，先读了一遍你给它写的说明书。这是提示词工程在Claude Code里最核心的落点，比任何单次提示词都重要。

我见过太多人完全不用CLAUDE.md，每次让agent干活都要重新交代项目背景、技术栈、目录结构、代码规范。这等于每次雇一个外包，都要从头给他讲一遍项目是干什么的。而CLAUDE.md的价值，恰恰是把这些“每次都要重复的说明”固化下来，让agent一进项目就门儿清。

2.1 三层记忆结构

Claude Code的记忆是分层的，从全局到项目逐级叠加：

• 用户级：~/.claude/CLAUDE.md，适用于你所有的项目，适合写你个人的全局偏好，比如“代码里禁止出现TODO注释”“所有新文件必须有测试”。
• 项目级：./CLAUDE.md，当前项目根目录下的说明书，适合写项目特有的信息，比如技术栈、目录结构、启动命令、架构约定。
• 会话级：通过@文件路径手动引入的文件内容，或者你当前对话中临时强调的信息，适合一次性任务的上下文补充。

分层的好处是每层只写该层的事，避免互相污染。如果把你个人的编码偏好和项目规范混在一起，换项目时agent就会把上一个项目的习惯带过来。

需要说明的是，项目级CLAUDE.md不只是能放在根目录，在子目录里也可以有。你可以在./src/api/CLAUDE.md里写这个子模块的专门约定，agent在处理该目录下的文件时会优先参考这一层的内容。这是很多团队做微服务或多模块项目时的关键配置。

2.2 怎么写CLAUDE.md才真有用

写CLAUDE.md有一个核心原则：声明式大于命令式。与其写“请你遵守项目规范”，不如直接写出规范本身；与其写“你要注意性能”，不如写出具体的性能指标。agent对具体信息的理解能力远强于抽象要求。

下面是一个我实际用下来效果不错的项目级CLAUDE.md结构，供参考：

# 项目概览 - 这是一个面向小程序商城的后端服务，使用Node.js + TypeScript。 - 核心模块：用户、订单、支付、商品、优惠券、运单。 # 技术栈与版本 - Node.js 20.x，pnpm 作为包管理器。 - Express 4.x + TypeScript 5.x，DB层用Prisma。 - 测试框架：Vitest，运行命令：pnpm test。 - Lint：ESLint + Prettier，配置在根目录 .eslintrc.cjs。 # 目录结构 - src/routes：路由层，只做参数校验和响应编排。 - src/services：业务逻辑层，禁止在services里出现SQL。 - src/repositories：数据访问层，负责所有数据库查询。 - src/types：全局类型定义。 - 禁止在services层出现req/res对象，禁止在routes层直接操作DB。 # 编码规范 - 所有错误码使用字符串常量，定义在src/constants/errors.ts。 - 函数命名用动词开头，布尔变量用is/has/can开头。 - 禁止使用any，禁止非空断言。 - 时间统一用UTC时间戳（number类型）存储，展示时再转时区。 - API响应统一格式：{ code, data, message }，code为0表示成功。 # 命令 - 启动本地服务：pnpm dev - 跑测试：pnpm test - 生成Prisma客户端：pnpm prisma:generate - 数据库迁移：pnpm prisma:migrate # 注意事项 - 本项目是单体仓库，改包依赖前先问一下项目负责人。 - 订单模块的数据一致性要求最高，任何涉及订单状态变更的逻辑必须写事务。 - 支付回调接口有幂等要求，实现时必须校验requestId是否已处理。

这个文件看起来朴素，但每句话都在给agent划定行为边界。比如“禁止在services里出现SQL”这句话，就省去了agent写出一堆面条式代码然后被打回重做的来回；而明确的测试命令，让agent自测时不需要猜该用什么命令。

写CLAUDE.md还有一个补充技巧：放一小段“已知坑”区域，专门记录项目里容易踩的坑。比如“修改validateOrderStatus时注意，全局搜索过的调用方有7处，其中订单详情页的调用预期是返回字符串而不是数字”。这种信息agent从代码里看不出来，但写出来后就能避免它在一个已知的雷区上踩爆。

2.3 配置自定义命令，把重复操作变成一条斜杠命令

Claude Code支持Slash Commands，可以把你反复使用的提示词模板固化下来。这个功能属于提示词工程的高级用法，但收益非常直接。拿我自己的例子，我配置了一个/code-review命令，每次让它做代码审查时，只需要输入这条命令，它就会按我预设的流程执行。

配置文件在~/.claude/commands/或项目.claude/commands/目录下，每个命令是一个Markdown文件，文件名即命令名。比如review.md：

对当前分支的最近变更做一次代码审查。 流程： 1. 先运行 git diff HEAD~1 看变更内容。 2. 检查变更是否符合项目CLAUDE.md中定义的编码规范。 3. 重点审查：逻辑正确性、边界条件、类型安全、并发问题、安全风险。 4. 对每个问题给出严重级别（critical / major / minor / nit）。 5. 最后输出总和评价，并给出优先级最高的3个修改建议。 约束： - 只在发现问题时指出文件路径和行号。 - 不要修改代码，只输出审查意见。 - 如果规范冲突，以项目CLAUDE.md为准。

这样你每次敲/review，agent就知道要干什么、按什么顺序干、输出什么格式。它不只省了打字，更重要的是把“高效的执行流程”固定下来，不依赖你每次临场组织语言的状态。

同样道理，你可以做/fix-lint、/write-test、/explain等命令。个人经验：把流程性、重复性、标准化的任务全部命令化，每次交互即时可用，这也是提示词工程在实战中最容易见效的一步。

3. 实战：两个拿得出手的提示词工程案例

理论说了一堆，真正检验提示词工程的还是实战。这里分享两个我最近实打实跑过的案例，一个是老项目重构，一个是新功能开发。两个案例都走完了从写提示词、执行、到调试和验收的完整闭环。

3.1 场景一：把一个老Node.js服务重构到TypeScript

项目背景：一个用JavaScript写的内部服务，逻辑很杂，大概有三千多行，没有测试，接口文档也不全。目标是迁移到TypeScript，但不能改变对外接口行为。

我写的提示词大致是这样的：

项目背景：这个服务是内部报表服务，当前是JavaScript，没有测试覆盖。 目标：将 src/ 下所有 .js 文件迁移为 .ts，保持所有对外接口的入参和响应格式完全不变。 约束： - 先完整读一遍所有源文件再动手。 - 不要改动业务逻辑，只做类型标注和ESM导入导出改写。 - 遇到类型无法推导的地方，用最小侵入的方式处理，优先用interface描述结构，不要用any。 - 当前没有测试，迁移完成后，为每个模块补一个冒烟测试，验证核心函数能正常执行。 - 不要碰 src/legacy 目录下的代码，那些是下个迭代才处理的内容。 验收标准： - 所有 .ts 文件能通过 tsc --noEmit 检查。 - 运行 pnpm test 全部通过。 - git diff 里不能出现对业务逻辑的修改。 - 完成后输出一份迁移说明，列出每个文件的改动要点和潜在风险。 如果过程中有任何判断不了的地方，停下来问我，不要自行决定。

这次任务执行得相当顺。agent先自己读了所有源文件，然后按依赖顺序逐个迁移。中途它停下来问了我一次，是关于一个混杂了多种业务判断的函数是否算“业务逻辑”，我确认可以只做类型标注后它继续跑完。最后检查diff时，确实没有出现业务逻辑变化，测试也补上了。

这里最值得学习的不是提示词写得长，而是边界画得清楚：“不要碰legacy目录”“不能出现业务逻辑修改”“判断不了就停下来问”。这三条约束直接决定了这次重构不会跑偏。尤其是“停下来问我”这条，很多人不敢写，或者忘了写，结果agent自己脑补了一个业务决策，后面就全乱了。

3.2 场景二：新增一个带数据库迁移的功能

第二个案例是给一个用户管理模块新增“导出用户列表为CSV”的功能，需要建新表存导出记录，还要考虑大数据量下的内存占用。

我用的提示词结构比第一个更偏“步骤式”：

需求：用户管理模块新增“导出用户列表为CSV”的操作，并把每次导出记录到 user_export_logs 表。 背景信息： - 用户表约50万行，导出不允许全量加载到内存。 - 现有代码在 src/modules/user 下，路由在 user.routes.ts，服务在 user.service.ts，DB访问在 user.repository.ts。 - DB使用Prisma，已有 migration 流程。 执行步骤： 1. 先读 src/modules/user 下的所有文件，了解现有结构。 2. 设计CSV导出的实现方式，建议用流式查询+分批写入文件。 3. 创建 user_export_logs 表并生成migration。 4. 实现导出服务，约束：每批读5000行，写入临时文件后输出下载地址。 5. 为导出接口加上权限校验。 6. 写单元测试覆盖：正常导出、无权限访问、表记录落库三个场景。 验收标准： - pnpm prisma:status 显示无未执行迁移。 - pnpm test 全绿。 - 导出10万行数据时，内存占用控制在200MB以内。 - 完成后输出summary：迁移文件内容、新增接口的参数和返回结构、测试列表、性能测试结果。 约束： - 不要改动已有接口的返回结构。 - CSV文件不要直接放在public目录，用专门的storage路径。

这个任务里，我实际上是把大半的“方案设计”自己做完了——流式查询、分批写入、建表记录。agent的工作就是按我的指令把设计落地。有人可能会说“这都没让AI发挥什么”，但从工程效率角度看，这恰恰是对的：你想让agent输出稳定结果，就应该给它明确的“为什么”和“怎么做”的边界，而不是让它天马行空。实践中，指导精确的提示词，得到的结果更可控、更贴近预期。

执行过程中agent直接创建了Prisma迁移文件，流式查询用的是Prisma的cursor分页，导出文件写到storage/tmp下，并且自动加了定时清理逻辑。测试部分写了六个测试用例，比我要的三个还多。最终内存占用实测在150MB左右，符合验收线。

3.3 一个可以直接抄的任务描述模板

综合上面两个案例，我归纳一个通用的任务描述模板，你在用Claude Code提交任务时可以直接套：

【项目背景】用一到三句话说明这个项目/模块是什么，当前状态如何。 【任务目标】一句话说明你要它实现什么，最终交付物是什么。 【关键约束】列出必须遵守的规则，比如不许改哪些文件、不许用什么技术方案、必须用什么方式实现。 【执行建议】可选。如果你对实现路径有倾向，可以写明步骤；如果希望agent自己设计方案，这里可以留空。 【验收标准】明确写清楚“怎么做算完成”：跑什么命令、达到什么指标、交付什么文档。 【风险底线】明确写清楚“哪些情况下停下来问我”，比如涉及公共模块改动、需要新增依赖、需要改数据库表结构、发现原有逻辑有潜在缺陷等。

这个模板对大多数开发任务都适用。我特别想强调“风险底线”这一项。没有这个，agent会替你拍板做很多不应该它决定的事——比如擅自给所有方法加日志、擅自格式化整个目录、擅自升级依赖版本。有了这一条，它在犹豫时会来问你，这比它“聪明地自作主张”安全得多。

4. 上下文工程：提示词工程的下一站

搜索引擎查资料时，输入框里写什么固然重要，但你搜到的第一页内容是什么同样重要。模型工作时，你要它“做什么”重要，你给它的“工作环境信息”更重要。Claude Code这类工具，恰好把后者变成了一个可以精细控制、可优化的维度，这就是上下文工程。

4.1 上下文不是越多越好

很多人误以为给模型的信息越多越好，这是一个大坑。Claude Code的上下文窗口是有限的，你塞的内容越多，真正有用的信息占比就越低，模型还容易被无关信息干扰判断。上下文工程的第一课，是要学会做减法。

举个例子：你有一次让agent修一个登录报错，提示词里顺手从README里复制了十几页部署文档。agent不得不消化这些无关信息后再开始调试，这既不经济，又可能被文档里“生产环境走Nginx”这类信息带偏思路，真的去检查Nginx配置。正确做法是：只告诉它登录报错发生在哪个环境、哪个接口、错误日志是什么。其余内容等它需要时再自己去看。

在Claude Code里，控制上下文最直接的手段，就是控制让它加载的文件。我自己的习惯是：开启一次具体任务的会话前，先让它读结构的文件（README、CLAUDE.md、目录列表），再读和任务直接相关的模块。不相关的文件，要么不引入，要么用@选择性引入。上下文窗口有限，每一分都要花在刀刃上。

4.2 会话级上下文管理：让agent看它该看的

上下文工程里，最常被忽视的是“看文件的顺序”。同样一堆文件，先看结构和先看细节，agent的理解深度完全不同。我用Claude Code执行多文件任务时，一般按下面这个顺序投喂信息：

• 第一波：CLAUDE.md（项目规则）、目录树、README。目的是让它建立全局心智模型。
• 第二波：和任务直接相关的模块源码、接口定义、类型定义。目的是让它了解现状。
• 第三波：任务要参考的格式范例，比如已有的类似实现、历史提交记录。目的是让它的输出风格贴合项目。
• 第四波：运行时信息，比如报错输出、测试日志。这些只在调试阶段引入，不让它提前跑到细节里。

这个顺序不是拍脑袋定的。第一波信息决定了agent对项目的“世界观”，如果先看了某一段具体代码，它很容易把局部规则误当全局规则，导致后续处理出现偏差。

还有一个技巧是合理使用/clear。会话过长了，前面塞满了无关讨论，上下文里都是垃圾，就别硬用了。清掉上下文重新开始，用CLAUDE.md和必要文件重新构建上下文。这比在混乱的旧会话里继续追加话题要高效得多。

/compact命令也可以用来提炼上下文：它会压缩之前的对话摘要并继续会话，但实际体验下来，它更适合“讨论过但还没动手”的场景。如果已经动手改了一堆文件，建议还是用/clear趁早重开。另外注意，重开会话只是清当前对话记录，不会清掉Claude Code在磁盘上已做的文件修改，所以不用担心丢进度。

4.3 用上下文工程控制成本和稳定性

Claude Code的使用是有token成本的，上下文越多，成本越高。从成本角度看，上下文工程的意义更大：同样一个任务，有的会话能烧掉几百万token，有的几十万token就搞定了，差异主要来自你让它看了多少不必要的内容。

我见过最夸张的用法：有人让Claude Code“读一下整个项目然后给我重构建议”，结果它把整个node_modules都扫了一遍，然后又跑偏到无关目录里去了。后来我给建议顺手设了显式路径，问题就再没出现过。管理上下文不是技术活，是克制活。

一个更细的成本控制方法是：把大任务切成小会话。比如“重构一个模块”不要一口气在一个会话里做完，而是分“读代码出方案”“改代码”“补测试”“整体review”四个阶段，每个阶段独立会话，只加载该阶段需要的上下文。这样既能保持上下文干净，又能避免单次token消耗失控。

5. 踩坑实录：Claude Code提示词常见问题排查

最后这部分是经验之谈。我在Claude Code上踩过的坑、见过别人踩过的坑，整理成了一份速查表。

5.1 常见问题速查表

这张表里最常出现的，是agent“做得太多”和agent“做得太少”两个极端。做得太多，是约束没画清；做得太少，是验收标准没定好。这两种问题都能通过更好的提示词解决，不必归咎于模型。

5.2 影响最大的三个教训

第一个教训：不要用“你是一个资深专家”这种空泛的角色设定，除非配上具体行为标准。我早期喜欢在提示词开头加“你是经验丰富的全栈工程师”，结果agent真的开始“资深”了，一会儿搞设计模式、一会儿加抽象层，把一个简单任务做出了一堆复杂度。后来我把这句话换成“你是本项目的新维护者，目标是保持现有架构风格，最小改动完成任务”，效果立刻好了很多。角色设定的作用不是哄模型，而是给它一个行为框架。

第二个教训：agent的“自主性”必须用提示词明确压制或释放。Claude Code默认是偏向自主行动的，只要没被禁止，它就会自己决定改哪些文件、用什么方案。如果你希望它每一步都给你确认，就要明确写“每次修改文件前先列出计划，等我确认后再执行”。我之前有一次让它“优化一下数据库查询”，它自作主张把整个repository层重写了，最后我花了两个小时来回审diff。从那以后，涉及面广的任务我必写“先出方案”。

第三个教训：所有AI生成的代码都必须走人工review。这不是不信任模型，而是工程底线。Claude Code直出的代码，编译通过不代表逻辑正确；逻辑正确不代表符合项目约束；符合约束不代表没有安全隐患。我有个合作者特别信任agent，跑完测试就合入主干，结果没过几天线上出了事故，原因是agent在处理时间边界时用了本地时间而不是UTC，而项目规范里明确写了UTC。如果当时review的人多看一眼diff，这个事故完全可以避免。提示词工程做得再好，也不能替代人的判断。

我个人的体会是，Claude Code的提示词工程，本质上是在训练自己“把任务想清楚再交代出去”的习惯。你写得越清楚，agent干得越靠谱；你偷懒少写一句边界，它就还你一份需要返工的结果。最后再分享一个实用小技巧：项目CLAUDE.md不是一次写好的，而是跟着迭代长出来的——每踩一次坑，就把对应的教训补进去，让它成为项目的“活文档”和“避坑手册”。用上一两个月后，你会明显感觉到agent在这个项目里的表现和其他项目不在一个档次。