企业官网建设流程全解析

1. 项目起源与整体定位

1.1 为什么我会做一套模板而不是继续“裸奔”用 AI 编程

如果你用过 Claude Code，大概率经历过这种感觉：明明是个很火的 AI 编程工具，但真要拿它干活，总觉得差点意思。单条命令扔进去，它能给你一顿猛操作，可一旦项目复杂起来，涉及多模块、多轮次、多人协作，整个使用体验就变得像开一辆没调过悬挂的车——能跑，但颠得难受。

我最初也是这么用的。直接在终端里敲 claude，然后一句“帮我看看这个 issue”，它就开始噼里啪啦改代码。改得倒是挺快，可问题在于：每次对话都是全新的上下文，它记不住我们项目的代码规范、测试习惯、部署流程，更不知道我这个团队的习惯性操作是什么。同样的需求，今天这么说它能理解，明天换个说法它就懵了。

后来我慢慢意识到，Claude Code 这种工具，真正的潜力不在于“随机应变”，而在于“有章法地用”。它支持系统提示词、支持 CLAUDE.md 配置、支持 slash commands 自定义命令，这几个功能叠加起来，就给了我们“设计模式”级别的空间。与其每次临时想指令、临时拼上下文，不如把团队的经验、流程、技巧沉淀成一套模板。于是就有了这个项目：一套拿来就能用的 Claude Code 模板集。

1.2 这套模板解决的核心痛点

先说结论：claude-code-templates 本质上是“把你的团队协作经验转化成 AI 能读懂的结构化指令”。它不是一个单一的配置文件，而是一个组合包，里面包含系统提示词模板、命令模板、工作流模板、代码评审模板等等。

你可以把 Claude Code 想象成一个天资很高但经验为零的“实习生”。你给它看公司制度、项目文档、代码风格指南，它就能干得又快又好；你什么都不给它，它就凭自己的训练数据瞎猜，结果就是看起来答得很顺，实则处处踩坑。

我见过太多人抱怨“AI 写代码不可用”，实际上很多时候不是模型不行，而是“输入方式”有问题。你没告诉它你们项目的技术栈约束，它当然会给你写出一个全新框架的代码；你没给它看历史失败案例，它当然会重蹈覆辙。模板的作用，就是把这些“潜规则”摆到明面上。

适合什么人来参考这套模板？如果你是独立开发者，想系统化使用 AI 编程助手；或者你是技术团队负责人，希望让 AI 工具在小组内发挥稳定作用；再或者你只是好奇“别人是怎么组织提示词的”——这套模板对你都会很有价值。

2. 模板库设计与功能拆解

2.1 整体架构：模板不是单个文件，而是分层的组合

最开始做模板的时候，我也犯过“一个大文件全装进去”的错误。把所有要求、规范、案例塞进一个系统提示词里，结果 Claude 经常顾此失彼，处理长上下文时甚至开始遗忘早期指令。

后来我参考了软件工程里的“分离关注点”思路，把模板拆成四层：

第一层是基础系统提示词，对应 CLAUDE.md 文件的全局约束部分，用来定义“AI 在这个项目中扮演什么角色、必须遵守哪些底线”；

第二层是项目上下文模板，用来描述代码库结构、技术栈、架构决策、编码规范等，这部分通常挂接在项目的 CLAUDE.md 里，或者通过 @ 引用方式注入；

第三层是命令模板，也就是自定义的 slash commands，针对重复性高、规则明确的场景（比如“帮我写测试”“帮我 review 代码”“帮我补注释”）预制好指令序列；

第四层是工作流模板，面向跨会话、跨模块的复杂任务，比如“实现一个完整的新功能”，它会定义先做什么、后做什么、每一步的检查标准是什么。

这样拆分之后，每个模板的职责都比较单一，Claude 也更容易“进入状态”。而且对使用者来说，你可以只取其中某一层，不需要全盘照搬。

2.2 核心功能模块详解

第一个核心模块是代码生成模板。这个模板针对最常见的“写代码”场景进行了细化。它不是简单地说“帮我写个登录功能”，而是会引导 Claude 先理解现有代码的风格、确认用户的技术栈约束、梳理功能边界，然后再动手敲代码。

第二个核心模块是代码评审模板。这个我觉得是团队协作中最有价值的模块。模板内置了一系列检查项，比如安全性检查、性能隐患、边界条件、命名规范、测试覆盖度等等。Claude 在评审时会按照这个清单逐项排查，而不是泛泛而谈“我觉得这里可以优化一下”。

第三个核心模块是重构模板。老代码怎么动刀而不伤筋动骨？模板里封装了“先看调用关系、再定重构方案、然后小步提交、最后跑测试验证”的完整流程。我实测下来，这个模板确实能在很大程度上避免 AI 一上来就大改特改然后弄出一堆回归 bug 的情况。

第四个模块是测试生成模板，它比较讲究“测试意图先行”。AI 会先列出一组测试场景清单，列出它打算覆盖的分支，在等待用户确认之后，才真正生成测试代码。

除了上述四个模块，模板库里还有一些轻量级工具模板，比如 commit message 生成、文档补全、Changelog 整理等。这些小工具表面上看起来不起眼，但在日常使用中频次极高，省下来的时间相当可观。

2.3 为什么选择 slash commands 作为入口

这套模板的核心入口我设计成了 slash commands 而不是直接要求用户写一大段自然语言。选择 slash commands 的考量很实际：一方面，命令可以被精确定义，不会因为措辞差异导致行为漂移；另一方面，团队内可以沉淀一套统一的“操作语言”，新成员上手时只要看到命令列表，就能知道 AI 能做什么、不能做什么。

比如我们团队约定 /implement 表示“按规范实现一个功能”，/review 表示“按规范评审当前变更”，这就避免了同事之间互相问“你那条指令是怎么写的”。时间一长，这些命令就成了团队内部的“标准操作手册”。而且 slash commands 是支持参数传递的，可以在触发时传入路径、文件名、描述等变量，非常灵活。

3. 核心模板的代码级拆解

3.1 基础配置文件的写法与参数解释

说是“模板库”，说到底还是要落到具体的配置文件上。Claude Code 的自定义命令放在.claude/commands/目录下，每个命令对应一个.md文件，文件名就是命令名。比如你创建一个.claude/commands/implement.md，那在 Claude Code 里输入/implement就能触发它。

一个基础的命令模板骨架长这样：

--- description: 按团队规范实现一个功能需求 argument-hint: 功能描述或 Issue 链接 --- 请实现用户提出的功能需求。 在动手写代码前，先按照以下步骤执行： 1. 阅读项目中 CLAUDE.md，确认技术栈和编码规范； 2. 检查相关模块目录下的现有代码，理解代码组织方式； 3. 列出你的实现方案，包括涉及文件、数据流、接口变更，等待我确认； 4. 确认后再实现代码，保持代码风格与现有代码一致； 5. 实现完成后，运行相关测试，确保没有破坏已有功能。 注意事项： - 不要擅自引入新的第三方依赖； - 不要修改与该功能无关的代码； - 异步逻辑记得处理错误分支和竞态条件。

别看这个模板结构简单，里面每个细节都是有讲究的。frontmatter 里的 description 字段会在命令列表里展示成一句话说明，这要求写得足够精准，否则团队里其他人根本看不出这个命令是干嘛的。argument-hint 则是提示用户需要传入什么参数，比如功能描述、Issue 链接等。

正文部分我刻意把“先列方案，等确认，再动手”写成了硬性步骤。这一步极其重要——让 AI 先理解、再动手，能避免大量返工。很多人抱怨 AI 写代码跑偏，根本原因就是跳过了这一步。

3.2 全局配置 CLAUDE.md 的关键段落

除了命令模板，全局配置文件 CLAUDE.md 也非常关键。这个文件放在项目根目录，Claude Code 启动时会自动加载，相当于一个永久的“团队背景说明”。

我最常建议别人在 CLAUDE.md 里写这几类内容：

代码风格约束。不用写得太抽象，直接给正反例。比如“字符串统一使用单引号，除了 HTML 属性内部”“回调风格的代码不要出现在新增代码里，一律使用 async/await”。AI 模型对具体示例的理解远好过抽象描述。

技术栈边界。明确写出“这个项目使用 TypeScript + React，不要引入 Vue 或者 Angular 代码”。这种约束听起来多余，但实测中经常有 AI 不自觉地混入别的框架写法。

禁止事项清单。把历史上踩过的坑直接写进禁止清单。比如“不要在 redux store 里保存 DOM 元素”“不要为了单元测试做不必要的依赖注入抽象”。这类清单是团队血泪经验的沉淀，价值远超任何开源库。

架构说明。不用画模块图，用文字描述清楚数据流向和模块职责就行。注意这里要写“当前实际是怎样的”，不要写“未来规划是怎样的”，AI 需要的是准确指导而非理想愿景。

3.3 代码评审模板的实现思路

代码评审模板是我用得最多、也是团队价值感最强的一个模板。它的实现思路围绕“结构化检查清单”展开。清单里的检查项一定要具体，不能写“检查代码质量”这种空话。

这是我评审模板中的一段核心内容：

请对当前变更进行代码评审，按以下维度逐项检查： 1. 安全性：用户输入是否正确校验？是否存在路径遍历、注入、反序列化风险？ 2. 并发安全：共享状态是否有竞态条件？异步操作是否有超时与取消机制？ 3. 错误处理：异常路径是否会产生未处理 Promise rejection？错误信息是否包含足够的排查上下文？ 4. 性能：是否有循环内执行 I/O、重复计算、无必要的组件重渲染？ 5. 兼容性：是否破坏已有 API 兼容性？API 改动是否同步更新了文档？ 6. 测试：新增代码是否有测试覆盖？测试是否断言了关键行为而不仅仅是实现细节？ 每个维度先给出结论（通过/关注/严重），再给出具体位置和修改建议。

实操下来，Claude 能很好地执行这些检查。特别是“先给结论，再给位置和建议”这个输出格式要求，能大幅降低理解成本，评审结果可以直接贴在 PR 里使用。

3.4 功能实现模板的完整流程

功能实现模板的目标是降低“大型任务”的失控风险。以前直接让 AI 实现一个功能模块，它经常一头扎进代码里，写完才发现实现思路与项目现有模式不符。

所以我在模板中设计了阶段控制的逻辑：

第一阶段是需求澄清。AI 需要用自己的话复述需求和验收标准，发现歧义就立刻提出来，而不是自行假设。这个阶段能挡掉大量因需求理解偏差导致的返工。

第二阶段是方案评审。AI 必须读代码、画数据流图（文字版的）、列文件变更列表，然后停下来等用户确认。这一步很像真实开发中的设计评审，效果很好。

第三阶段是实现。只有在确认通过后才进入编码环节。编码过程中，每个文件变更都要附带“为什么这样设计”的说明，这样即使写得有问题，也容易定位决策是否符合预期。

第四阶段是自测与交付。AI 自行执行相关测试、检查 lint、总结变更点。最终输出“变更摘要 + 测试结果 + 潜在的后续风险”，这个输出可以直接作为 PR 描述使用。

这套流程跑下来，给我的感觉是，AI 的行为模式变得更像一个“资深工程师在带新人”，而不是一个“只求响应速度的代码生成器”。

4. 让模板效果更上一层楼的实战经验

4.1 上下文管理的核心要点

CLAUDE.md 文件不能写得太大。我曾见过有人把整本团队 wiki 塞进去，结果上下文窗口被撑爆，Claude 反而开始忽略关键指令。精简的办法是控制文件只包含“高频必要信息”和“强约束信息”，低频的背景知识用“按需引用”的方式挂到子文档里。

系统提示中其实有一个机制，就是当信息过多时，模型会优先关注开头和结尾的内容。所以重要指令的摆放位置有讲究：最核心的约束放开头，最新的临时要求放末尾，中间部分留给参照性质的信息。如果你的 CLAUDE.md 里有“不做什么”的清单，建议放靠前的位置。

我在模板里还专门做了一个实践建议：把历史失败案例写进单独的历史教训文件，然后在关键命令模板里通过 “@教训文件” 的方式按需引入。这样既能保证全局文件精简，又能保证需要时信息可用。

4.2 模板迭代中的调试思路

模板不是写一次就完事的。我在维护这套模板库的过程中，逐渐形成了一个比较有效的迭代回路：观察失败案例、总结失败原因、修改模板约束、验证效果。

具体来说，如果某个命令运行结果又偏离预期，不要急着骂模型，先去复盘它是哪一步走偏的。是需求理解错了？还是实现方案有偏差？还是输出格式不符合要求？针对走偏的环节，在对应模板里增加一条更明确的约束。通常加一次就能明显改善，因为模板的明确约束对模型行为的矫正效果还是很强的。

另外我建议给命令模板加上版本号或最后修改日期，团队协作时这一点特别有用。因为别人使用时如果发现效果异常，可以对比是不是用了旧版本缓存，避免无谓的争论。

4.3 参数调优与模型选择的建议

Claude Code 支持不同模型档位的选择。模板能保证使用体验的下限，但模型档位选择会影响上限。日常小任务，比如生成单文件、写测试用例，用标准档位足够了，响应速度快，体验也顺畅。复杂重构、跨模块设计评审这类需要深度推理的任务，建议临时切到更强的推理档位。

另外一个小技巧是“主模型与快速模型”的组合策略。简单分工：主模型负责规划和生成，快速模型负责执行检查、跑命令解析之类的辅助工作。这个策略实际上是参考了真实开发中“资深工程师做方案，助手做执行”的思路，应用到工具配置里效率提升非常明显。

4.4 团队落地时怎么避免变成“摆设”

模板做出来不用，等于没做。团队落地最大的阻力不是工具不好用，而是习惯转移的成本。我在团队里推广这套模板时用了两个比较有效的手段。

第一个手段是包装成“团队基建”而不是“额外负担”。我花半小时做了一个快速演示：用旧方式做一次代码评审，再用模板做一次代码评审，对比两者的差异和用时。人看到实际收益，自然愿意用。

第二个手段是给每个模板配备“什么时候不该用”的说明。比如代码评审模板适用于 PR 阶段，但阻塞性 Defect 排查就不适合用它，因为那是调试场景，需要的是逐层推理，而非结构化评审。这类说明能让团队成员建立更准确的工具使用预期，不会因为一次选了不合适的模板就对整套方案失去信心。

5. 高频问题与排查记录

5.1 命令不生效的原因与定位方法

有段时间我遇到命令乱触发的情况，明明在 CLAUDE.md 中定义好的命令，Claude 却在一段对话里莫名调用。排查之后发现是自己把命令名写得太通用，撞了模型内置的默认意图。比如你定义个/help或者/clear就很容易和自带行为冲突。

解决办法是命令名加上业务前缀，效果比想象中好。团队内部习惯用/feat-xxx或/review-strict这样带上下文的命名。不要小看这一点，命令命中准确率的提升有明显的感知度。

如果碰到命令完全没有被识别，首先检查文件路径和文件名，Claude Code 的命令文件扩展名必须是 .md，位置必须在 .claude/commands/。其次检查 frontmatter 格式，YAML 解析失败会导致整个命令静默失效。一个取巧的检查方式是看斜杠命令的提示列表里是否还能看到该命令的 description 字段。

5.2 模板结果跑偏的常见场景

最常发生的跑偏场景是两个：擅自定义和过度实现。

“擅自定义”表现为用户没说要引入某框架，AI 却偷偷引入了某库。这个问题根因在于上下文里缺少“禁止引入新依赖”的强约束，或者约束写法太软。事后补救不如事前写死，命令模板里最好直接写明禁止事项。

“过度实现”表现为用户让改一个函数，AI 却重构了整条调用链。这类问题的根源是“任务边界”描述不清，模型的泛化能力强，容易把改动范围扩展到隐含的相关区域。解决方案是在模板中强制加入“只修改与本次需求直接相关的文件，不准顺带重构”，并且要求输出变更文件列表供用户确认。

5.3 上下文消耗过大的缓解措施

Claude Code 的上下文窗口有限，一些复杂命令会一次性吞掉太多 token。模板设计如果不留意这一点，几轮交互之后能力就会断崖式下降。

缓解方案有几条：一是命令模板尽量做到“别把背景全部塞进来”，多使用按需引用的方式；二是让 AI 在中间过程中保持输出简洁，不要每次对话都长篇大论；三是对于超大代码库，要求 AI 先做代码地图摘要再执行修改，不要一口气把所有文件都读一遍。

5.4 踩坑总结与细节优化

模板维护过程中我踩了很多坑，最深刻的体会是：模板的表述越抽象，效果就越不稳定。比如“注意代码质量”这种话等于没说。换成“不要在这份代码里使用 any 类型”“新增文件必须带上单元测试”，模型的表现立刻不一样。这就是模型与编译器的区别——编译器理解的是语法，模型理解的是意图，任何含糊意图最终都会被它用“自己的常识”填补。

另一个经验是关于文件引入路径的写法。在模板中使用相对路径引用附件或文档时，建议基于项目根目录写完整相对路径，避免歧义。命令模板和 CLAUDE.md 之间的相对关系容易造成混乱，直接写根路径最稳。

还有一点值得留意：每个命令模板的骨架要“步骤化”。所谓步骤化，就是明确告诉模型“第一步做什么、第二步做什么”。缺少步骤化指令时，模型倾向于把所有动作一股脑做完，结果难以控制。有了步骤边界，中间环节出了问题，还能从“哪一步开始偏离”排查起。

6. 从模板到系统：把 Claude Code 用成“团队基础设施”

维护这套模板一年多，我越来越觉得，Claude Code 这种东西的真正价值不是替代工程师，而是放大工程师。而放大的前提，是你要有足够好的“操作框架”。

一个人闷头写代码时，及时把团队规范抽象成模板，效率提升明显；几个人协作时，共用一套模板更是降低了沟通成本，因为所有人和 AI 对话的方式都标准化了，新人也能很快熟悉。模板锁定的不只是 AI 的输出质量，实际上也锁定了团队做事的流程和底线。

我理解有人会说“不就是写写提示词吗”，但实际做下来我发现，把提示词写成体系之后，项目的形态就变了——AI 从一个“随叫随到的编码工具”，变成了一个“懂行规、守边界、可预期的协作者”。要达到这个状态，关键不在于模型本身，而在于你怎么给它搭台子。

这套模板对我来说，接下来还会继续迭代。我已经在考虑增加按行业场景区分的模板包，比如前端项目、后端服务、数据管道各自有各自的最佳实践模板。这项工作没有终点，因为工具在变、团队在磨合，但方向是对的：把不可控的对话变成可控的流程，把个人的经验变成团队的基础设施。