企业官网建设流程全解析

我最早接触 Claude Code 的时候，和大部分人一样，直接打开终端、粘贴一段任务描述就开始干活。第一条命令很惊艳，第二条开始发现问题：它对项目的理解总差那么一点意思，输出的代码风格不稳定，同一个需求换个说法，结果完全不一样。后面看了几个做得好的开源项目才发现，问题不在模型，在我的用法——我缺少一套针对自己项目的模板体系。这就是我整理 claude-code-templates 的起点：把平时所有有效的提示词、项目规范、任务流程沉淀成模板，让 Claude Code 不再是“问一句答一句”的对话工具，而是真正熟悉团队规范的协作者。

这套模板适合谁？如果你每天要和 Claude Code 打交道，却不满意它的默认表现；如果你的团队有统一的编码规范，但每次都要花半篇提示词去解释；如果你觉得“下次把提示词存下来再用”这个习惯没有真正落地过——那这份模板库的思路应该能帮到你。文章后面会拆开讲模板怎么设计、目录怎么组织、规则优先级怎么定、遇到上下文膨胀和指令冲突怎么处理，全程用我自己的实际配置做例子。

1. 模板库到底在解决什么问题

先说个最常见的现象。很多人觉得 Claude Code 不够聪明，其实大部分时候是使用方式的问题。默认情况下，它对环境一无所知，对你的团队规范一无所知，对你要交付的标准也一无所知。它只是一个智力很高的通用模型，而不是一个“懂你们项目”的协作者。

1.1 三个被反复追问的问题

我翻了团队和社区里的反馈，发现大家遇到的麻烦高度一致。

第一个是上下文浪费。每次开始新会话都要重新讲一遍“我们是做什么的、代码在哪、输出要什么格式”，讲完这些，真正留给任务的上下文窗口已经不宽裕了。Claude Code 的上下文窗口再大，也经不起每次重复二十行背景说明。这不是模型能力问题，是效率问题。

第二个是输出不稳定。同一个任务，今天让它写一个 Python 函数，它给你写标准库版本；明天同样的需求，它给你引了第三方库，还需要额外安装依赖。不是模型退步了，而是你没有告诉它“本项目只能用标准库”“禁止引入新依赖”这类约束。不要指望模型记住上一会话的内容，每个新会话都是重新开始。

第三个是最隐蔽的：缺少自我检查环节。默认工作流里，Claude Code 写完了就完事，不会主动做代码审查、不会跑测试、不会检查类型标注。人写代码都知道写完之后自测一遍，但模型如果不被明确指示“做完之后要做什么”，它默认就是“做完就停”。

1.2 模板库的核心价值

模板库解决的正是这三个问题。

它把项目的“长期记忆”固化到文件里。团队规范、技术栈约束、目录结构说明、代码风格要求，这些不该每次对话都讲一遍的内容，全部沉淀到模板配置中。Claude Code 启动时自动加载，每次会话自动具备这些上下文。

它让输出变得可预期。既然约束已经被写明，模型每一次回复都会遵循同样的规则，不会出现今天一种风格、明天另一种风格的情况。这个价值的意义在于：稳定输出比超预期输出更珍贵。超预期偶尔有，但不可控；稳定则意味着可审查、可复制、可持续。

它还顺便培养了“完成闭环”的习惯。把“写代码、自查、跑测试、报告结果”做成一整套流程模板，让每一次任务都走完整流程，交付质量自然就稳了。我以前统计过团队的代码返工率，用模板之后下降了接近一半，主要原因就是模型不再漏掉自查环节。

2. 模板库的核心组成与设计逻辑

我的 claude-code-templates 不是单一文件，而是一套分层的文件组合。每个文件解决一个层面的问题，互相之间又有关联。

2.1 CLAUDE.md：项目上下文的锚点

CLAUDE.md 是 Claude Code 最重要的配置文件，每次会话启动时都会自动加载。它是模型理解项目的第一个入口，决定了对项目认知的基本盘。

我在模板里把 CLAUDE.md 拆成五个固定模块：项目定位与核心业务——用三到五句话说明这个项目是干什么的、给谁用、核心场景是什么；技术栈清单——精确到版本，声明语言、框架、关键依赖；目录结构说明——把主干目录的用途讲清楚，避免模型猜错文件位置；运行指令——开发、测试、构建、部署分别用什么命令；代码风格约束——命名规范、注释语言、函数长度偏好、是否允许第三方库。

说一个设计细节：技术栈清单一定要写版本。Claude Code 的知识库有截止日期，你不写版本，它可能默认给你写 Python 2 语法，也可能推荐一个已经废弃的 API。把版本钉死，等于给它画了一个安全边界。

目录结构说明也要写。我发现模型经常犯一个错误：找配置文件的时候，凭直觉去根目录找，但实际项目里可能放在config/子目录，或者按照公司规范必须在deploy/下。你在 CLAUDE.md 里写清楚，它就不会乱翻。

2.2 规则文件：从“可以做”到“应该怎么做”

CLAUDE.md 管“事实”，规则文件管“行为”。

我把规则文件按作用域分成三层：全局规则（.claude/rules/global.md）作用于所有项目，适合放通用原则，比如“禁止写死敏感信息”“所有异步操作必须加超时控制”“错误信息必须包含上下文”；项目规则（.claude/rules/project.md）作用于当前项目，放业务相关的约束，比如“订单模块必须使用事件驱动架构”“与支付相关的所有接口必须幂等”；任务规则（.claude/rules/tasks/*.md）按任务类型分类，比如code-review.md、test-writing.md、refactor.md，每种任务一套独立约束。

三层划分的意义在于控制上下文成本。全局规则每条都重要，但项目规则不能和全局规则平级，否则加载量太大，反而稀释了关键指令的权重。模型对规则文件的加载策略不是“越多的规则越好”，而是“越相关越好”。分层之后，每次会话只加载全局加当前项目相关部分，精确，不浪费。

规则文件的语言要本身写得像指令，而不是像建议。对比一下：

低效写法：“建议在提交代码前先运行测试，以保证不会破坏已有功能。”

高效写法：“所有代码合并前必须运行pytest tests/，若有失败用例，禁止提交。”

区别在于句式。命令式句法明确行为边界，模型不需要自己解读“建议”的强度。我踩过一个坑是早期规则文件用了太多“尽量”“希望”“可以考虑”这类软性词汇，效果非常差。后来做了一次措辞审计，把所有软性词全部换成“必须”“禁止”“不得”，规则执行力肉眼可见地提升。

2.3 技能模板：把经验固化成流程

如果说规则文件是“语法”，技能模板就是“算法”。它告诉模型复杂任务分几步走、每步做到什么程度才算完成。

我维护了一套skills/目录，每个文件描述一种任务类型的完整执行流程。以代码审查模板为例：

第一步，先读全部改动文件，不急着评论，通读完了再开始。第二步，按序检查：功能正确性（逻辑有没有明显漏洞）、安全风险（有没有注入、越权、敏感信息泄露）、性能隐患（有没有明显低效算法或多余查询）、可维护性（命名是否清晰、函数是否过长、职责是否单一）。第三步，按严重程度分三档输出问题清单：阻断性问题（必须修改后才能合并）、建议性问题（不修改也能合并但要写理由）、可选性问题（纯风格偏好）。第四步，对每个问题给出具体修改建议，不是笼统一句“代码可读性不佳”，而是要指出具体哪一行、为什么不佳、建议怎么改。

这套模板看起来简单，但它蕴含了一个核心逻辑：把“好结果”的定义前置。Claude Code 不是不知道什么是好的代码审查，而是不知道“在你的项目语境下，什么算好的代码审查”。模板把这个定义写清楚，它就能照着执行。

技能模板不限制在代码领域。测试用例设计、重构执行计划、Bug 排查流程、数据库迁移方案，我都写了模板。每条模板都踩过实际项目的坑才固化下来，不是凭空设计的。比如“测试用例设计”模板里有一条硬性要求：禁止只写让人能跑过的测试，必须是能测出问题的测试。这条规则来自一次线上事故——当时模型生成的测试全部门绿，但覆盖的全是 happy path，错误分支根本没测到。

3. 从零搭建你的第一套模板

理论讲完了，现在讲实操。这一节我会带你按步骤从零搭一套模板，可以直接照抄，也建议根据你的项目情况修改。

3.1 初始化目录结构

先建目录骨架。在项目根目录下执行：

mkdir -p .claude/rules/tasks mkdir -p .claude/skills touch CLAUDE.md touch .claude/rules/global.md touch .claude/rules/project.md touch .claude/skills/code-review.md touch .claude/skills/test-writing.md

很多教程直接让你创建一个巨大无比的 CLAUDE.md，把所有内容塞进去。我不推荐这样做的原因是：单文件不利于维护，而且 Claude Code 加载需求描述时，长文件的尾部和头部会被同等对待，没有优先级区分。拆开之后，你改规则文件不需要动配置文件，任务模板独立演化，出问题时也容易定位。

初始化完成后，第一件事不是写内容，而是把 CLAUDE.md 先填满项目基础信息。基础信息不填好，后面规则文件写再多也容易跑偏。

3.2 CLAUDE.md 的五个填空模块

按下面这个模板填，基本上覆盖大多数场景：

# 项目识别 - 项目名称：[项目名] - 项目定位：[三句话以内说清楚核心业务] - 主要用户：[谁在用，用于帮助判断交互设计和功能优先级] # 技术栈 - 主语言：[语言] [版本] - 框架：[框架名] [版本] - 关键依赖：[包名] [版本]；[包名] [版本] - 禁止引入：[如果有限制，写具体包名或类别] # 目录结构 - [目录名]：存放[什么]，主要包含[什么] - [目录名]：存放[什么]，规则见[对应文件] - 配置文件位置：[路径] - 构建产物目录：[路径]，禁止提交到版本库 # 常用指令 - 开发启动：[命令] - 测试执行：[命令] - 构建：[命令] - 代码格式化：[命令] # 代码风格 - 命名规范：[描述，例如：变量使用snake_case，常量使用UPPER_SNAKE_CASE] - 注释语言：[中文/英文]。[为什么，例如：团队协作需要，海外同事也能看懂] - 函数长度：[目标值]行以内。 - 第三方库使用：[必须声明理由] / [禁止引入]

每一条都别写废话。CLAUDE.md 的内容质量和信息密度直接影响模型对项目的理解深度。我见过有人把团队历史写进去，整整一个段落介绍项目诞生背景——这个对模型没有用，删掉，它占用的空间不如用来写清楚“订单状态机有哪几种状态”。

3.3 规则文件的措辞规范

规则文件的措辞规则是：一不模糊、二不冗余、三不冲突。

一不模糊，前面说过了，把“建议”改为“必须”。二不冗余，同一个规则不要出现在两个文件里，避免模型处理时产生优先级困惑。我遇到过一种情况：全局规则里写了“禁止使用var声明变量”，项目规则里又写了一遍，只是表述略不同。模型加载后发现两条规则描述有细微差异，不知道该听哪条，最后它选择了自己理解的那个版本，两条都没遵守。解决方法是：全局规则只放普适原则，项目规则只管本项目特有的条目，凡是重复的果断删掉。

三不冲突是规则文件最容易踩的坑。举一个我刚才在整理模板时遇到的实际冲突案例：

全局规则里有一条：“禁止在提交代码中留下调试输出，如console.log、print。”

项目规则里有一条：“防御性编程要求所有外部接口的入口和出口必须有日志记录。”

结果模型每次写业务代码时都陷入两难：写日志可能违反“禁止调试输出”，不写日志又违反“必须有日志记录”。最终它选择了一种折中：写了一行# 此处应有日志的注释代替实际日志——这当然不是我们想要的。

后来我把全局规则改成“禁止在非调试场景中使用console.log/print，日志请统一使用logger对象”，冲突就化解了。所以写规则的时候，每写完一条，想一下这条和已有的规则怎么交互。规则不是越多越好，是越自洽越好。

3.4 任务模板的“最少必要步骤”原则

写任务模板时，要克制。一个任务模板不需要列出十五个步骤，模型执行长流程时会逐渐丢失早期步骤的上下文权重。我推荐三个到五个关键步骤，每步说明目标、检查点、完成标准，宁精勿滥。

以代码审查模板为例，我最终发布的版本是：

# 代码审查任务模板 1. 通读改动：先完整读取所有改动文件，不中途评论。重点理解改动目的与整体影响面。 2. 四维检查：按安全风险、功能正确性、性能隐患、可维护性依次检查文件。 - 安全风险：检查输入校验、权限控制、敏感信息、注入风险 - 功能正确性：检查边界条件、错误处理、逻辑分支完整性 - 性能隐患：检查循环内查询、无谓遍历、大数据量操作 - 可维护性：检查命名、函数长度、职责划分、重复代码 3. 输出分级问题列表。阻断性/建议性/可选性三级，每项必须指明文件与行号，给出具体修改建议。 4. 收尾：总结改动整体质量评价；列出必须修复项。

四个步骤，够了。加更多步骤只会稀释每个步骤的权重。

3.5 用示例驱动模板进化

模板不是一次性写成然后固定不变的。我的做法是：每遇到一次“这次对话效果特别好”或“这次对话结果特别烂”，都回头反推模板哪里没写到位。

效果特别好的时候，去翻 Claude Code 这次是怎么理解项目的，哪部分信息它是从模板里拿到的，哪些行为它有但模板里没写——那就是需要补充的条目。效果特别烂的时候，去分析是模板信息缺失、措辞模糊还是规则冲突。

比如早期模板没有写“禁止引入新依赖”的全局规则。有次让模型实现一个 JSON 解析功能，它引入了pandas——一个为了 JSON 解析塞进来三百兆依赖的方案。后来加了一条通用规则：“新增第三方依赖前必须先询问，并说明理由。”这个规则到现在还在用，非常有效。这就是从失败案例里长出来的模板条目，比凭空设计可靠得多。

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

模板搭好之后，使用过程中会遇到一些典型问题，我也一并整理出来。这些问题我全部实测过，给出的解决方式是我目前验证有效的方案。

4.1 上下文膨胀：模板加载太多反而变笨

症状：模型回复慢，而且有时候会“忘记”用户当前指令，去执行模板里的某个流程。

原因：模板文件太多，或者单文件太长。模型加载时把全部内容塞进上下文，真正和当前任务相关的部分占比不高，导致权重被稀释。

排查：先看目录里有没有重复设计。比如skills/里同时有refactor.md、code-refactoring.md两个内容相似的模板，模型加载时会混淆，甚至叠加执行。

解决：第一，合并同类项，同一类任务只保留一个模板文件；第二，控制 CLAUDE.md 在 80 行以内，规则文件控制在 40 行以内，超出就要做减法；第三，把通用指令从模板里移出去放到全局规则里，比如“写完代码必须自查”这种所有任务通用的行为，不该出现在某个具体任务模板里。

4.2 规则冲突：两条规则打架，模型两头难

症状：模型输出行为诡异，既不完全遵守规则 A，也不完全遵守规则 B，而是选择一种双方都沾一点但都不彻底的方式。

排查：把加载到当前会话的所有规则文件列出来，逐条对照，重点检查：是否有同一个主题的两个不同描述；是否有“禁止 X”和“必须 X”同时存在；是否有硬编码约束和模式化指令矛盾。

解决：规则冲突没有自动化解方案，必须靠人手工抽平。我自己的做法是每月做一次规则快照，用git diff查看规则变更历史，对比过去一个月哪些规则改动后引发了问题，这比每次冲突时临时救火高效得多。

4.3 模板对具体任务失效：任务类型不在模板覆盖范围

症状：模板库已经建好了，但新任务类型出现，现有模板没有覆盖，模型表现回到了没配模板时的水平。

原因：模板是按经验固化的，经验有滞后性。新任务类型出现时，不可能有现成的模板。

解决：把新任务遇到的高质量输出过程翻出来，拆成三个部分——前置信息（它需要知道哪些项目背景）、执行步骤（它做了什么顺序操作）、完成标准（它交付了什么内容）。然后按最小必要步骤原则，把这个过程固化成新模板。我每次遇到新类型任务都会补一个模板，一个月下来模板库从三个增长到了七个，覆盖能力持续完善。

4.4 模板更新后表现没变化

症状：修改了规则文件或模板内容，但下一次会话模型行为没有明显变化。

排查：不需要怀疑模型问题。检查是否正确重启了会话——Claude Code 的配置文件跟很多服务一样，是会话启动时加载的，会话中的修改不会热生效。还有，路径书写是否正确，规则文件是否放到了被识别的位置。

解决：修改后清掉当前会话重开一个新会话，然后输入“请告诉我你加载了哪些配置”，让模型复述一遍它看到的规则。它如果没有把新内容列出来，就是路径放错了；如果列出来了但是执行不到位，就是措辞不够命令化，需要进一步收紧。

4.5 模板过于模板化：输出千篇一律

症状：模板用了很久之后，模型产出的代码、注释、文档都有明显的同质化痕迹，缺少针对具体场景的自适应性。

原因：模板本质上是一组偏置，过度依赖它会让模型的判断空间被压扁。尤其是任务模板，如果步骤太细太死，模型不会根据上下文做灵活调整。

解决：在任务模板里加入“适应性判断”要素。比如代码审查模板第二步里，加一句：“上述四维检查按项目风险等级排序，若本次改动仅涉及样式类文件，优先检查可维护性，其他维度可从简。”这样既保留了模板的骨架，又让模型有时间根据场景做局部调整。

5. 模板的版本管理与团队协作

模板这东西，个人用能提升生产力，团队用就能统一产出标准。但团队场景下，模板的维护复杂度会上一个台阶。

5.1 把模板当作代码管理

CLAUDE.md 和规则文件本质上是配置文件，应该纳入版本控制。我习惯在.claude/目录下建立独立的 Git 历史，或者作为主仓库的一个子模块。这样每次改动都有迹可循，出问题时可以直接git bisect定位是哪次规则调整导致行为变化。

版本管理另外一个好处是：做了失败尝试可以随时回滚。有一次我把全局规则里的“禁止引入新依赖”改成“可提出依赖引入建议，交由用户决策”，结果模型开始频繁建议引入各种新包。不到一下午我就回滚了，改动历史让我能精确回到之前的版本，不用靠记忆重写。

5.2 团队共识的必要性

团队使用模板库最大的坑在于“一个人的规则，另一个人觉得莫名其妙”。每个成员的写作风格、代码偏好、对质量的认知都不一样，所以模板库要在团队内达成共识，不能是单方面的输出。

我的经验是：先跑一个两周的试点期，让每个团队成员把自己遇到的模板问题记录到一份公共文档，试点结束后整理所有反馈，统一进行调整。这个过程是必须的，它能让规则反映集体共识，而不是某一个人的习惯。团队模板的价值不只是“让 Claude Code 更好用”，更是“让大家对好的代码形成一致的定义”。

5.3 模板库的持续演进机制

模板库没有“完结”状态。代码在变、框架在变、团队习惯在变，模板也需要跟着变。

我设置了一个简单机制：每次 Sprint 结束时预留一小段时间，专门审视模板库。看一下这期间 Claude Code 有没有产生明显的高质量或低质量输出，分别复盘原因，然后决定是新增、修改还是删除某个模板条目。这样模板库不会变成一个被供奉起来但没人更新的摆设，它会跟着项目的实际演化节奏一起往前走。

我现阶段用下来最明显的变化是：开新会话时心里有底了——我知道 Claude Code 加载了正确的项目信息、知道它会遵守团队规范、知道它不会写完就停。这让我能把更多精力放在真正的逻辑决策上，而不是重复解释需求。你如果现在刚开始配模板，先别追求一步到位，把你最常用的两个任务做成模板跑起来，用过之后你再回头看效果，会感谢当初动手的自己。