企业官网建设流程全解析

去年年底开始重度使用 Claude Code 之后，我养成了一个习惯：每次动手写代码之前，先想清楚要给模型喂什么。因为踩过的坑太多了——同一段代码，上午让它审查是一套输出，下午再跑一遍又是另一套，差别大到你以为换了个模型。问题的根源不在于模型不稳定，而在于我们给它的指令和上下文每次都不太一样。后来我花了很长时间整理了一套 claude-code-templates 模板仓库，把常用的代码审查、测试生成、缺陷定位、重构建议这些任务全部固化成模板，配合 CLAUDE.md 项目记忆文件一起用，效果直线上升。这篇文章就把整套模板体系从头到尾拆一遍，讲清楚每类模板的设计逻辑、具体怎么用，以及我在落地过程中踩过的坑和总结的排查思路。

这套内容适合三类人：刚接触 Claude Code、不知道从哪下手的新手；想在团队里统一 AI 编码规范的技术负责人；以及想把日常重复性工作模板化、节省沟通成本的效率型开发者。无论你是用终端直接敲对话，还是想把它集成到自己的开发流程里，这篇分享都能给到可以直接抄作业的方案。

1. 为什么要做一套 Claude Code 模板

1.1 从"每次重写提示词"到"一套模板走天下"

先说一个很常见的场景。你想让 Claude Code 帮你做一次代码审查，于是你敲了一句"帮我看看这段代码有什么问题"。它会给出一堆泛泛而谈的意见，什么"建议增加注释""可能存在边界问题"，既没有具体行号，也没给出可操作的修复方案。你不得不再补一句"请具体指出问题行，并给出修改后的代码"，它才开始认真起来。这个过程就是典型的"调教"成本。

一次两次还能忍受，但每天要开好几次对话，每个任务都要重复解释背景、约束、输出格式，浪费的时间和上下文窗口都非常可惜。我最初的想法很简单：把每次对话里那些"稳定不变的部分"抽出来，存成模板。比如代码审查的质量维度、输出格式、标题规范，这些内容是通用的，跟具体项目无关。需要的时候直接把模板拿出来，再往里面填入项目相关的具体上下文，一次搞定。

这就是 claude-code-templates 的起点。它不是某个单一文件，而是一整套按场景分类的模板池，包括场景提示词、项目配置、工作流定义和辅助脚本。使用之后，我最大的感受是：Claude Code 的输出稳定性明显提升，不再像每次碰运气，而是像跟一个熟悉项目规范的老同事协作。

1.2 模板池的整体设计：按使用场景分类

在设计模板仓库时，我没有把所有提示词塞进一个大文件，而是按使用场景拆成四个维度，这样既能单独调用，也能组合使用。

第一类叫场景模板，解决"某个具体任务怎么做"的问题。包括代码审查、测试用例生成、缺陷定位、性能分析、重构建议等。这类模板的核心是定义角色、任务边界和输出格式，让模型一上来就进入状态，而不是靠你在对话里一点点挤牙膏。第二类是项目配置模板，主要是 CLAUDE.md 文件。它负责描述项目本身的"反常识信息"：用什么技术栈、有哪些历史包袱、代码规范是什么、哪些操作是禁区。这类模板跟具体任务无关，但会深刻影响所有任务的质量。

第三类是工作流模板，解决"一串任务怎么组织"的问题。比如从需求到提交的完整流程，或者从 bug 报告到修复验证的流程。这类模板往往包含多个步骤，每一步之间还有依赖关系，需要模型在完成一步之后再继续下一步。第四类是角色模板，定义 AI 以什么身份回答问题。同一个模型，设定为"资深前端工程师"和设定为"刚入职的实习生"，输出内容的专业度差异非常大。

这里我放一张对比表格，演示同一个代码审查任务在"没有模板"和"使用模板"两种情况下的输出差异：

这种差距的根源在于，模板把"模型需要知道的所有背景信息"提前塞给了它，省去了它靠猜测补齐上下文的环节，输出自然更稳定。

2. 模板体系的核心设计细节

2.1 CLAUDE.md：项目记忆的载体

Claude Code 原生支持在项目根目录放置一个 CLAUDE.md 文件，每次启动会话时它会自动读取这个文件，相当于给模型一份"项目入职手册"。很多人的 CLAUDE.md 写得很随意，只放一行项目介绍，那基本发挥不了作用。我的习惯是，至少包含四块内容：项目简介、常用命令、代码约定、禁区清单。

一个比较典型的结构长这样：

# 项目：用户中心服务 ## 技术栈 - Go 1.22 + Gin + PostgreSQL + Redis - 前端：Vue 3 + Vite ## 常用命令 - 启动本地服务：go run ./cmd/server - 运行所有测试：go test ./... - 生成数据库迁移：make migrate name=<migration_name> ## 代码约定 - 接口返回统一结构：{ code, message, data } - 数据库操作只允许放在 repository 层 - 新增第三方依赖前先问是否必要 - 所有对外接口必须写单元测试 ## 禁区 - 不要修改公共依赖版本，除非有明确升级理由 - 不要绕过 context 做超时控制 - 不要在生产代码中使用 fmt.Println 做日志

这份文件写得好不好，直接决定模型在项目内的表现。我见过不少团队把 CLAUDE.md 写成十几页的需求文档，结果模型每次对话都要消耗大量上下文去解析这份文档，后续对话反而变得迟钝。正确的做法是精简、高信息密度，只写那些"从代码里看不出来但影响判断"的信息。代码里已经写得很清楚的东西，比如项目的整体架构，不需要重复。真正有用的是那些隐含的"潜规则"。

2.2 Prompt 模板的骨架：目标、约束、上下文、输出格式

我的场景模板基本都遵循同一个骨架，我把这个骨架总结成四个部分：目标、约束、上下文、输出格式。可能听起来简单，但实际执行时很多人会漏掉其中一两项。

目标是整个模板的"北极星"，定义了这个任务到底要解决什么问题。约束是边界条件，告诉模型哪些事情不能做、哪些情况要优先考虑。上下文是背景信息，可能是代码 diff、目录结构、日志片段，也可以是指向某个文件的路径。输出格式则是最后产出物的表达方式，可以是表格、代码片段、JSON，或者带行号的问题列表。

四个部分里，输出格式最容易被忽略，但它恰恰是决定输出质量的关键。我见过很多团队抱怨"AI 给的方案没法直接用"，真正的原因不是方案不对，而是格式太发散：有时是长段落，有时是列表，有时中途又变成代码块。如果你明确要求"每个问题必须包含文件路径、行号、严重级别、问题描述、修复建议，且修复建议必须给出可运行的代码片段"，输出的可用性会高非常多。

下面是我用的一个代码审查模板的简化版：

你是一名严格的 Go 后端代码评审者，有 10 年以上生产环境维护经验。 ### 目标 审查下面提供的代码 diff，找出会导致 bug、性能问题或可维护性隐患的点。 ### 约束 - 只输出真实存在的问题，禁止吹捧和寒暄。 - 不重复已经在 CLAUDE.md 中列明的项目约定。 - 严重级别必须客观：线上故障算"阻塞"，性能隐患算"主要"，可读性建议算"次要"。 - 每个问题必须精确到文件与行号，不给行号视为无效。 ### 上下文 - 项目约定见根目录 CLAUDE.md。 - 当前 diff：<在此处粘贴 diff> ### 输出格式 | 文件 | 行号 | 严重级别 | 问题描述 | 修复建议 |

这套模板的核心在于约束那一栏的"不给行号视为无效"——这句话看似生硬，但它非常有效地逼着模型去精确读代码，而不是凭印象给建议。我在实际使用中明显感觉到，加上这句话之后，审查结果的准确性比原来高了不止一个档次。

2.3 变量与占位符的工程化设计

模板不可能永远不变化，尤其是同一份代码审查模板，在不同项目里要多位评审者参与，在不同分支上审查范围也不一样。为了做到"结构不变、内容可变"，我在模板里引入了占位符机制。

占位符的语法我统一使用双花括号加变量名，比如 {{target_branch}}、{{review_scope}}、{{max_diff_size}}。理由很简单：双花括号在 Markdown 和代码块里出现频率极低，不容易跟真实内容混淆。如果你用单个花括号或者百分号，可能会在包含 Shell 脚本、Go 模板的代码片段里产生误匹配，那会让模板在复制粘贴时发生灾难性的替换错误。

占位符的值通常由人填写，但也可以用脚本批量替换。我写了一个简单的 Bash 脚本，在进入新项目时一键替换模板里的通用占位符：

#!/usr/bin/env bash # apply.sh - 将模板中的占位符替换为当前项目信息 PROJECT_NAME="${1:?用法: ./apply.sh <project_name>}" TARGET_DIR="${2:-./claude-code-templates}" for f in "$TARGET_DIR"/prompts/*.md; do sed -i "s/{{project_name}}/$PROJECT_NAME/g" "$f" sed -i "s/{{today}}/$(date +%Y-%m-%d)/g" "$f" done echo "模板替换完成，请检查 prompts/ 目录下的文件。"

这个脚本本身很简单，但它在团队协作里的价值很大。负责人统一维护模板，其他人只是拉下来跑一下脚本就能得到带项目信息的副本，避免了每个人手工复制粘贴时改漏或者改错的情况。占位符设计的另一个原则是：数量不要太多。我见过一个模板里塞了十几个占位符，光填变量就要花五分钟，那就违背了模板提高效率的初衷。一般每个模板的占位符控制在三个以内，让填写的成本足够低。

3. 实操：从零搭建并调用模板仓库

3.1 仓库目录结构与每个文件的作用

一个可落地的模板仓库，建议目录结构如下：

claude-code-templates/ ├── CLAUDE.md ├── prompts/ │ ├── code-review.md │ ├── test-generation.md │ ├── debugging.md │ ├── refactoring.md │ └── architecture-design.md ├── workflows/ │ ├── feature-development.md │ └── bugfix-process.md ├── roles/ │ ├── backend-expert.md │ └── frontend-expert.md └── scripts/ ├── apply.sh └── list.sh

我这里解释一下每个文件的作用。CLAUDE.md 是仓库根级的项目记忆文件，它描述的是"这个模板仓库本身"的内容，包括模板目录结构、使用说明、维护规范。prompts/ 目录放的是单次任务模板，也就是上面讲过的场景模板。workflows/ 目录放的是多步骤流程模板，适合从零开始执行一个完整的开发任务，比如"从需求分析到代码提交"。roles/ 目录放角色设定，它通常不作为独立模板直接使用，而是作为基础身份，让其他模板在开头引用。scripts/ 目录放辅助脚本，用于批量替换占位符、列出可用模板等。

为什么要把目录分得这么细？因为不同任务对上下文的粒度要求不同。代码审查可能只需要 prompt 本身加 diff 内容就够了，但要跑一个 bug 修复流程，你需要把 CLAUDE.md、角色设定、流程步骤全部串起来。目录分开之后，你能按需组合，而不是把整个仓库一股脑塞给模型。

3.2 手把手编写一个可复用的 code review 模板

我们带着完整的思路来写一个可直接上手的模板，下面是完整示例，也是我当前仓库里 code-review.md 的核心部分：

# Code Review 模板 ## 角色设定 你是一名资深后端工程师，长期维护高并发生产系统，对代码质量要求极其苛刻。 ## 任务指令 请按照下面的流程审查我提供的代码 diff： 1. 先加载根目录 CLAUDE.md，记住其中的项目规范。 2. 按文件顺序逐个审查 diff，不要遗漏文件。 3. 对每个文件给出审查意见，意见必须包含行号。 ## 审查维度 - 正确性：是否存在路径错误、并发问题、边界条件疏漏。 - 性能：是否存在不必要的循环、高频锁、无效 IO。 - 可维护性：命名是否清晰、函数是否过长、是否有重复代码。 - 安全性：是否存在注入、越权、敏感信息泄露风险。 ## 严重级别定义 - 阻塞：必须修复后才能合并，否则线上一定会出事。 - 主要：长期存在会出问题，建议本次迭代修复。 - 次要：可读性建议，不阻塞合并。 ## 输出格式 输出必须严格按 Markdown 表格展示： | 文件 | 行号 | 严重级别 | 问题描述 | 修复建议 |

写这个模板时我做了三个比较合理的设计决策。第一，角色设定只保留一句话，且给出"极其苛刻"这个形容词，避免模型在角色扮演上花太多篇幅，同时树立严格倾向。第二，流程步骤从"加载 CLAUDE.md"开始，确保项目规范被纳入考虑。第三，严重级别做了语义定义，让模型在判断"阻塞"和"主要"时有具体标准，而不是随意打标签。

生成完毕之后，在 Claude Code 里的调用方式非常直接：直接粘贴这个模板，后面紧跟你的 diff 内容即可。我的习惯是在模板和 diff 之间用"以下内容是需要审查的 diff："作为分隔行，让模型清晰感知到边界的切换。

3.3 通过斜杠命令与 CLAUDE.md 组合调用

如果每次都把模板全文粘贴进来，时间久了还是觉得繁琐。有个更好的方式：直接把模板内容写入 CLAUDE.md，让模型通过记忆读取。在 CLAUDE.md 里增加一段：

## 标准评审流程 当用户要求执行代码审查时，按 `prompts/code-review.md` 中的模板执行。模板的完整内容可在仓库对应文件中找到。

然后调用时只需要输入一句"帮我审查当前分支的 diff"，模型就会自动去 templates 仓库里找到 code-review.md 的模板内容并执行。这种方式能显著减少对话轮次，但前提是模型能够在上下文里访问到模板仓库。如果你使用的是 Claude Code 的普通模式，可以通过加载文件路径来实现；如果你有自定义命令行工具，也可以在启动时把模板目录加入加载列表。我在实际使用中，一般是把模板内容直接粘贴到会话里，这样最稳，不容易出现模型找不到文件的情况。

另外一个组合技巧是：把角色模板和场景模板叠加。比如先粘贴一份 backend-expert.md，让它确认自己的资深后端身份，然后再粘贴一份 code-review.md，给它具体的任务指令。两个模板叠加后，上下文里既有身份认知，又有任务目标，输出质量会比单独用一个模板更稳定。

4. 让模板真正落地的五个实战技巧

光有模板文件还不够，真正让模板发挥效力的是一些使用细节。这节分享五个我在实际使用中验证过的小技巧。

第一个技巧是给模板增加严格程度开关。代码审查模板里可以放一个变量 {{strict_mode}}，取值 ON 或 OFF。设置为 ON 时，模板强调"宁可错报，不可漏报"；设置为 OFF 时，强调"只报告高置信度问题"。这样同一套模板既能用于日常快速自查，也能用于提交前的严格把关。我通常会在合并代码前开启严格模式，平时开发时切到普通模式。

第二个技巧是用固定输出格式驱动模型按照表格来输出，这比让人去脑补那些"所谓规范"要可靠得多。你可能会觉得，把格式固定在模板里是不是太死板了？不是。Claude Code 的优势在于它能执行复杂任务，但执行复杂任务的前提是每一步的产出都结构清晰。拿一个开发任务来说，如果模型从需求分析、代码编写、测试验证到提交信息都按固定结构输出，最终产物质量一定比自由发挥高出一大截。

第三个技巧是控制单次任务边界。模板里要明确"本次任务只做审查，不修改代码"或"本次任务只写测试壳，不做业务实现"。我在模板仓库里专门为这个设计了一行约束说明。如果不设边界，模型经常会自作主张改写你的代码，有时候改得你莫名其妙。加上边界之后，它的专注度明显提升。

第四个技巧是使用增量上下文。很多人审查大项目时习惯把整个代码仓库塞进一次会话，结果上下文窗口爆掉，后续任务全部混乱。我的做法是：先让它读取基础规范，再让它逐个文件看 diff，每次只给当前文件相关的代码片段。这样模型不需要一次性消化大量内容，输出质量和稳定性会好很多。

第五个技巧是把模板纳入版本管理。很多团队用模板只是单机维护，换台电脑或者新成员加入就没人用了。我把模板仓库当作普通代码仓库管理，每次改进都提交 PR 和 review。甚至可以连模板的变更记录都写入 CLAUDE.md，这样模型在使用模板时能感知到模板版本演进，不会用过时的旧版逻辑。

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

5.1 高频异常现象速查表

实际操作中难免会遇到一些诡异的现象。我把它们整理成一张速查表，方便快速定位：

5.2 几个值得注意的排查案例

先说模板被忽略的情况。有一次我反复确认模板内容没有问题，但输出始终不按照模板要求来，排查了很久发现，根目录和子目录有一个同名 CLAUDE.md 文件，模型优先加载了子目录里一个旧的、内容极少的版本。解决办法很简单，规定全仓库只允许根目录存在 CLAUDE.md，子目录不再放同名文件。从那以后我把这条约定写进了规范文档。

另外一次踩坑是模板做了大量重复换行和空行，导致模型把空行误读为"输出要分段"，我本来要求按表格输出，结果它分成了一大堆小段落。后来我意识到，模板在工程上也是代码，格式本身会潜移默化影响输出风格。建议模板尽量紧凑，用明确的 Markdown 结构标记语义，而不是靠空行暗示。

还有一个容易忽略的因素：模型的记忆长度有限。有些模板里引用的项目规范太多，占用了大量上下文窗口，后面用户又输入了一大段 diff，这时模型会把最早期的模板指令从上下文里"挤掉"。这也是为什么我一直强调模板要精简。如果项目规范实在很多，可以考虑拆分成多个独立文件，按需引用，而不是把所有规范一次性塞进一个文档。

如果你把一个模板放了很多次，模型会开始混乱，觉得你要它执行的任务反复出现。建议把每个模板在会话中只出现一次，后续通过"按之前的流程继续"来推进，而不是反复粘贴同一个模板。实测下来，这种方式既省 token，又稳定。

最后说一点经验。模板不是一蹴而就的东西，它需要随项目演进不断维护。我每隔几周就会翻一遍模板仓库，删掉那些实际使用中发现没用的约束，补充从新问题里提炼出来的规则。让模板保持"精炼"而非"臃肿"，是它长期能起作用的前提。如果你手里已经积累了不少 Claude Code 的使用心得，不妨也从今天开始把你的提示词沉淀成一个模板仓库，长期坚持下来，你会发现 AI 编程的效率和稳定性都能上一个台阶。