企业官网建设流程全解析

1. 为什么我劝你给Claude Code做一套模板

坦白说，刚接触Claude Code的时候，我的用法跟大部分人一样——想改什么直接打字，让AI猜我的意图。一开始感觉还行，毕竟模型理解力摆在那，但用了一周之后，我明显发现一个问题：每一次对话都是“从零开始”。我反复解释项目背景、代码规范、输出格式，AI还是会在不重要的地方跑偏。真正让我下定决心整理一套templates的，是有一次让它重构一个模块，它把命名规范全改了，我花了一下午收拾残局。

这个项目的核心思考其实很简单：与其每次都花20分钟把上下文讲清楚，不如把常用任务做成固定模板，让Claude Code一上来就知道“你是谁、项目是什么、你想要什么格式、你坚决不要什么”。很多人把Claude Code当成一个对话机器人，但它的真实定位是一个可编程的工程助理。你给它输入什么样的规范化指令，它就回馈给你什么样的稳定输出。

在整理这套模板之前，我先想清楚了一个问题：什么样的任务值得做成模板？答案是高频、重复、有明确验收标准的三类事。比如代码审查、需求分析、重构拆解、接口文档生成，这些任务每个开发者每周都会做，而且判断结果好坏的标准其实八九不离十。把这些固定成模板，等于把“怎么跟AI协作”这件事沉淀成了团队资产，谁来了都能直接用。

这套东西适合谁？我认为最适合两类人：一类是团队里负责推AI编程落地的技术负责人，另一类是自己想提升日常开发效率的独立开发者。前者的痛点是团队成员的Prompt水平参差不齐，后者则纯粹是受够了重复劳动。无论哪一类，看完这篇文章，你至少能搭出一套属于自己的模板体系。

1.1 没有模板的时候到底哪里难受

先说最直观的痛点——上下文浪费。Claude Code的对话窗口不是无限长的，每轮对话都要消耗context。如果你在每条指令里都重复项目背景，等于把宝贵的上下文空间浪费在“自我介绍”上。我实测过，一个中等规模的前端项目，你把背景讲清楚大概需要600~800个token，而这部分每次对话都要重新付一遍。一天下来，光重复描述项目就烧掉了几万token，效率极其低下。

第二个痛点是输出格式不稳定。同一个需求，上午让它写接口文档，它给你一个结构；下午再让它写，又变成另一个结构。看起来好像没什么大问题，但当你需要把AI输出直接贴进Wiki、或者接进下游工具的时候，格式不一致就非常折腾人。我有一次让它生成一批API文档，前五个接口的字段说明风格跟后五个完全不一样，整理起来比手写还累。

第三个痛点是AI的“自由发挥”。没有约束的时候，Claude Code会在一些你完全没想到的方向上加戏。比如让你修一个bug，它顺便帮你“优化”了旁边的代码；让你写测试用例，它自作主张重构了被测函数。这种自由度在日常闲聊里是加分项，但在工程任务里就是灾难。模板的作用就是给AI一个明确的边界，告诉它哪些地方不许碰。

1.2 模板到底解决的是哪一类问题

从根上讲，Claude Code的模板解决的是“隐性知识显性化”的问题。你在一个项目里待了三个月，哪些目录不能动、哪些命名规范要遵守、哪些模块有历史包袱，这些你门儿清，但AI不知道。如果你不说，它就按自己的通用理解来。这就像新来的实习生，能力很强，但对你们组的地雷一无所知，你不管他，他准踩。

模板把经验固化下来，本质上是给你的项目写了一份“AI入职手册”。它不只是一个Prompt技巧，而是一套约束机制。当你的模板里明确写了“不要修改src/utils下的文件”“测试统一用Vitest不用Jest”“输出格式要包含背景、方案、风险”的时候，AI的行为就会被这些规则约束住，产出的质量下限被大幅抬高。

还有一类问题是模板能解决的，那就是跨人协作的一致性。你自己写Prompt有自己的习惯，同事也有同事的习惯，每个人跟AI协作的风格都不一样。这会导致一个很尴尬的场面：同一份代码，你让AI审查和同事让AI审查，拿到的报告风格完全不同，根本没法横向对比。把模板统一之后，所有人拿到的是同一套标准，AI的输出自然就对齐了，评审效率能提升一大截。

1.3 它和普通Prompt的区别

很多人觉得模板就是“长一点的Prompt”，这个理解对了一半。普通Prompt是一次性的、针对单次任务的指令；模板是结构化的、可复用的、带变量插槽的任务框架。打个比方，Prompt是点外卖的时候跟商家说“少放辣”，模板是你提前定制好的“营养餐计划”——每天吃什么、热量多少、过敏原是什么，全部固定好了，下单只是选个日期的事情。

从技术实现上看，模板通常包含几个固定模块：任务目标、输入参数、约束条件、输出格式、验收标准。这些模块每个都有自己的作用，任务目标让AI知道要做什么，输入参数提供具体材料，约束条件划定边界，输出格式确定交付物长什么样，验收标准让AI自查。这五个要素组合起来，才能算一个完整的模板，否则就是一个普通的指令。

我见过很多人写模板，写来写去就一句话：“你是一个资深前端工程师，请帮我审查代码。”这不行，这等于没写。模板的价值恰恰在于后面的约束和标准，AI知道自己是资深工程师没有用，它得知道你说的资深意味着什么、审查要按什么维度来、报告给谁看、用什么语气。这些都是模板要回答的问题。

2. 模板体系的整体设计：先分类再动手

决定做模板之后，我第一反应是打开一个空白文件开始写内容，但写到一半就卡住了——我不知道该写哪些模板、每个模板该覆盖什么场景。后来我强迫自己先做设计，把所有使用场景画了一遍，分好类再动手，效率一下子高了很多。这个顺序很重要，很多人做模板失败，不是因为写得不好，而是因为没有体系。

我把高频场景先分成两大维度：一个是任务的类型，另一个是模板的作用层级。任务类型决定了模板的内容方向，作用层级决定了它应该放在哪里、对谁生效。这两个维度交叉起来，就是你的模板体系全景图。

2.1 按任务类型划分：日常开发四大类

拿我自己的实际工作来说，日常开发里的任务可以归成四类。第一类是分析类任务，比如需求分析、技术方案设计、代码影响面评估，这类任务的特点是输入信息量大、需要权衡取舍，输出物通常是文档或方案说明。第二类是实施类任务，比如写功能代码、修bug、写单元测试，这类任务的特点是目标明确、产出物是代码，重点在于约束编码风格和项目规范。

第三类是审查类任务，比如Code Review、依赖安全检查、性能瓶颈分析，特点是需要带着批判性视角去看已有代码，输出物是问题清单和修改建议。第四类是文档类任务，比如接口文档生成、README编写、Changelog整理，特点是格式要求强、受众明确，输出物要被下游工具或其他人直接使用。这四类任务的逻辑完全不同，绝对不能共用一个模板。

拿审查类举个例子。让它做Code Review的时候，我会在模板里明确要求“只报告问题，不要直接给修复代码”“按严重程度排序”“每个问题标注涉及文件与行号”。但如果这个模板拿去生成接口文档，那就完全驴唇不对马嘴了。所以先分类、再写内容，这是模板体系设计的第一步。

2.2 模板的三层结构：全局、项目、任务

除了按任务类型横切，模板还要按作用层级纵切。我实际用下来，一套完整的模板体系应该有上中下三层。最上面一层是全局模板，也就是所有项目都可以通用的那一批，比如代码审查模板、提交信息规范模板、通用重构模板，这些不依赖具体业务，放到任何项目里都能跑。第二层是项目级配置，通常写在项目根目录的CLAUDE.md里，内容是项目特有信息，比如技术栈、目录结构、命名规范、禁改区域。

第三层是任务级的动态模板，这一层要跟具体的任务输入结合起来，通常会留出变量插槽，在执行的时候填入代码文件、需求描述、日志报错之类的东西。三层的关系是：全局模板提供通用方法论，项目配置提供业务上下文，任务模板承载具体执行细节。三者配合，AI才能既有常识又有领域知识，还能处理当下的具体问题。

这里我想强调一点：很多人把“模板”理解成一套静态的Prompt，这是不够的。真正好用的模板体系一定是动态的——全局、项目、任务三个层面相互叠加，AI在回答问题的时候会同时参考三层信息，这样它既不会问出“这个项目是用什么语言写的”这种蠢问题，也不会把通用规范套在不适用它的场景里。

2.3 设计模板的几条原则

设计模板的时候，我踩过不少坑，也总结出几条原则。第一条是单模板聚焦一个任务，不要追求一个大而全的模板覆盖所有场景。一个模板里塞了需求分析、编码实现、测试验证三个任务，AI的注意力一定会被稀释，最后每个任务都完成得差强人意。宁可多建几个模板，也不要贪多。

第二条是每个约束都要有明确的理由。模板里写“不要用any”不能只写结论，最好带上“因为项目开启了strict模式，any会引发类型安全问题”这种原因说明。AI不是靠执行命令活的，它是靠理解逻辑活的。你把理由讲清楚，它才能在你没覆盖到的地方做出符合你意图的判断，这叫举一反三。

第三条是输出格式必须显式定义。如果你需要AI返回一个JSON，你就要在模板里写出JSON的字段结构，甚至附上一个例子。如果你需要它返回一个表格，你就要把列定义好。很多人说AI输出不稳定，其实多半是因为你的指令里对输出格式的定义不够具体。格式不是品味问题，是可执行性的关键。

3. 核心模板实操：从搭骨架到填血肉

说完了设计思路，接下来进入最实在的部分：几个可以直接拿去用的模板。我不搞花哨的，这几个都是我日常工作里高频使用、并且验证过稳定性的模板。你可以直接拷贝，按自己项目的情况改一改就能用。

3.1 基础任务模板：需求分析

需求分析是我用得最多的场景，因为它每天都会出现。无论是产品丢过来一个需求，还是自己发现代码里有个设计缺陷，都需要先分析清楚再动手。没有模板的时候，让Claude Code分析需求，它通常会给你一大堆“正确的废话”，比如“需要提升用户体验”之类，一点落不了地。后来我写了这个模板，情况就好了很多。

模板结构大致是这样：开头让AI扮演技术方案设计师，给它一段需求描述，然后要求它按“背景与目标、功能拆解、技术影响范围、风险与备选方案、工作量预估”五个部分来输出。每部分都有字数限制和内容提示，避免它写得像散文。比如技术影响范围这一节，我明确要求“列出涉及的前后端模块、数据表、接口清单，不要泛泛而谈”。

使用的时候，我会把需求原文填到变量槽里，再把相关的代码目录路径附上。实测下来，这个模板最大的好处是输出结论可以直接贴到技术评审文档里，只需要微调几个措辞就行。以前我自己写一份需求分析至少要40分钟，现在AI先出草稿，我补充修正，10分钟就能搞定。

提示：需求分析模板里一定要加一句“如果需求描述不完整，用提问的方式补充信息后再开始分析”。我加了这个约束之后，AI不会再对着一个残缺的需求硬编一套方案，而是会先反问，这个行为更接近一个真正的方案设计师。

3.2 代码审查模板

代码审查模板可能是投入产出比最高的一个。因为Code Review本身就是一个“找茬”任务，AI天然擅长找问题，但如果没有约束，它会把问题和不问题一起说出来，报告又臭又长。我的模板里做了几件事：第一，限定审查范围，让它只关注我标注的代码文件和变更行段；第二，指定审查维度，包括正确性、性能、可维护性、安全性、测试覆盖五个维度。

第三，我要求它按“严重程度”给问题分级：阻断级、主要级、次要级、建议级。阻断级问题会先列出“变更可能导致线上故障”的原因，建议级则归类到“可后续优化”。这样分级之后，我review的时候就能直接按优先级处理，不用在自己心里再排一遍。第四，我加了一个很关键的约束：不要提供修复代码。

很多人不理解为什么要禁止AI给修复代码。我的理由是，审查报告的价值在于暴露问题，一旦AI给了修复代码，它自己审查自己的代码，就很容易自卖自夸。而且给修复代码会让报告篇幅膨胀，干扰你的注意力。真需要修复建议的，单独再开一轮对话专门讨论，那个场景用另一个模板来处理。

3.3 重构任务模板

重构是风险最高的任务类型，没有模板的时候，AI很容易在各种细节里放飞自我。我的重构模板重点解决三个问题：控制范围、保留行为、渐进提交。控制范围就是明确列出“允许改动目录”和“禁止触碰目录”，防止AI顺手把无关代码也重构了。保留行为是要求任何重构都不能改变现有输入输出的行为预期，尤其是对外接口签名。

渐进提交这一条比较有意思。我在模板里让AI把重构分成多个可独立验证的步骤，每个步骤都生成一个单独的diff说明，而不是一次性给出一个几百行的超大改动。这样我每一步都可以运行测试验证，出问题能精确定位到是哪一步引入的。这个思路借鉴了“小步重构”的工程实践，Claude Code执行起来完全没压力。

使用重构模板的时候，我通常还会搭配一个额外的指令：重构完成之后，让它自己对比重构前后的测试时长和代码行数变化，输出一个简短的总结报告。这样做的好处是，即使AI的重构从逻辑上是成功的，你也能评估这次重构是否真的值得——如果复杂度没降、行数没减，那这次重构的收益就要打个问号。

3.4 模板中的CLAUDE.md配置

前面说到的都是任务级模板，但所有的任务级模板都要依赖项目上下文才能发挥效果。项目上下文的载体是CLAUDE.md文件。这个文件放在项目根目录，Claude Code会在每次会话开始的时候自动读取，作为全局上下文的一部分。我强烈建议每个项目都维护一个CLAUDE.md，它是你模板体系的地基。

CLAUDE.md里写什么？我自己的模板里包含这几块：项目简介、技术栈清单、代码结构地图、命名规范、测试要求、禁止操作清单。代码结构地图是最有用的部分，我会把关键目录和它们的职责写清楚，比如“src/api存放接口调用层，不允许在组件里直接发请求”，这样AI写代码的时候就会自觉按你的架构设计走。

写CLAUDE.md最大的坑是“写得太抽象”。比如“请写出优雅的代码”这种话一点用都没有，AI不知道你的“优雅”是函数瘦身还是命名精炼。正确的做法是给具体示例，比如在命名规范里写道“状态管理相关变量用is/has前缀，如isLoading、hasError”，AI才能真正照着执行。CLAUDE.md不是愿景文档，是操作手册，一定要具体到能执行。

4. 让模板“活”起来：动态变量的用法与调优

如果模板只是固定不变的文本，那它本质上跟一份文档没什么区别。真正让模板强大起来的，是它支持动态变量。你可以把模板理解为一个函数，变量是入参，Claude Code在你填入变量之后生成对应的输出。这样同一套模板，可以应对无数种具体场景，不需要为每个任务单独写Prompt。

4.1 变量替换与上下文裁剪

我在模板里最常用的变量有几个：任务描述、目标文件路径、相关代码目录、禁止事项、输出格式要求。使用时直接把实际内容填进去，AI会先解析这些变量，再结合CLAUDE.md里的项目上下文，给出一个贴合当前场景的回答。比如代码审查模板里，我会在变量槽填上“本次变更涉及：src/components/UserCard.tsx, src/hooks/useUser.ts”，AI就能精准定位代码，而不是把整个项目扫一遍。

另一个细节是上下文裁剪。模板本身会占用一定的token，如果项目上下文又很长，叠加起来可能让每次调用的token开销变大。我的做法是，在任务模板里加一个“精简模式”的说明：如果项目上下文超过预设阈值，优先遵循CLAUDE.md中的高优先级规则，忽略一些次要的格式化偏好。这样能保证在上下文紧张的时候，核心约束仍然生效。

变量替换还有一个隐藏好处：方便做自动化。你可以写一个脚本，把模板中的变量用命令行参数替换，然后直接调用Claude Code的CLI模式跑批处理。我有一次需要批量审查20个PR，就是写了个shell脚本循环调用模板，每个PR生成一份审查报告，省下来的时间非常可观。

4.2 模板与CLAUDE.md的配合

模板和CLAUDE.md的配合关系，可以理解成“全局变量”和“局部变量”的关系。CLAUDE.md是全项目通用的，里面写的是所有任务都要遵守的大规则；任务模板是某个具体场景下临时生效的局部规则，里面可能会有比CLAUDE.md更细的要求，甚至在某些点上覆盖掉CLAUDE.md的默认设置。

举个例子，项目的CLAUDE.md里写着“所有代码必须有单元测试”，但在用一个“紧急热修复”模板的时候，这个规则就不太现实。我的热修复模板里会显式声明“当前场景跳过单元测试要求，但要补充手动验证步骤描述”，这个声明相当于局部覆盖了全局规则。这个机制非常灵活，前提是你自己要想清楚什么规则是全局底线、什么规则可以按场景放宽。

实际写的时候，我建议在CLAUDE.md和任务模板里同时给规则标上优先级。比如CLAUDE.md里写“【P0】禁止修改数据库表结构”，任务模板里写“本次任务允许新增索引，不允许删除字段”，两条规则一起出现时，AI能分清轻重，不会因为局部模板而违反全局底线。

4.3 模板的版本管理

模板不是一次写好的，它需要跟着项目和实践持续迭代。我自己的模板库已经改了三版，每一版都是因为实际使用中发现新问题才改的。所以模板也要做版本管理，我推荐直接把模板放在Git仓库里管理，每次修改都走commit记录，改了什么一目了然。

具体的做法是，在项目仓库里建一个.claude/templates目录，把模板文件按类型命名，比如review.md、refactor.md、analysis.md。每次改动后更新模板内部的版本号，并且在CLAUDE.md里注明“模板版本参见.claude/templates/VERSION”。这样团队多人协作时，不会出现“你用的模板怎么跟我用的不一样”的混乱。

我还有一个习惯：在模板的最后加一段“变更日志”，记录每次改了什么、为什么改。一开始觉得没什么必要，但有一次我改了一个约束条件之后，发现AI的输出质量反而下降了，回溯变更日志很快就定位到了问题。没有日志的话，你可能根本想不起来三周前那次修改的动机，排查起来等于盲人摸象。

5. 实战中踩过的坑：模板失效的常见原因

模板做了不等于就好用。我自己的模板体系前前后后调整了很多次，中间遇到过不少问题。这些坑如果你没踩过，光看文档是发现不了的，我希望你直接避开。

5.1 AI不按模板走，怎么办

最常见的问题是，模板写了，AI不执行。分析下来，原因无非三种：第一种，模板与CLAUDE.md存在冲突，AI在矛盾指令面前往往会选择“更加通用”的那条执行，而不是你的模板；第二种，模板内指令优先级不明确，AI分不清哪条是强约束、哪条是参考建议；第三种，模板本身的指令跟模型偏好差距太大，比如单次让它处理太多任务，它的执行力就会下降。

我的解决办法，首先是给指令分级。用“【必须】【推荐】【可选】”三个级别标注所有规则，模型对这种显式分级的响应准确率明显更高。其次是减少冲突，每次新增模板前先全局搜一下CLAUDE.md，看有没有跟新模板矛盾的内容，一旦发现及时调整。最后是给模板“瘦身”，如果单个模板超过600字，执行效果就会打折，我把每类任务拆成多个小模板，执行稳定度明显回升。

还有一个容易被忽视的点：模板中的指令顺序会影响执行优先级。AI对靠前指令的执行意愿通常高于靠后指令。所以模板的第一句话非常关键，我会把“本次任务的核心目标”放在最前面，并且用一句话说清楚。如果你的模板第一段是背景介绍，那AI很可能把整段背景也都当成“要做的事”，输出方向就会跑偏。

5.2 模板写得太厚，反而更慢

第一次给项目搭模板的时候，我很有激情，恨不得把所有的开发规范、代码风格、架构设计全写进去。结果CLAUDE.md加上模板文件，总字数超过了3000字。实际用下来的感受是：AI每次回答都变得很慢，而且有时候它会“选择性强调”一些并不重要的规则，把输出节奏带偏。后来我才意识到，模板不是写论文，不是越全越好。

上下文窗口是有限的，Claude Code的注意力资源也是有限的。你塞给它的规则越多，重要规则在注意力里占据的比例不升反降。这就像一个什么都管的领导，最后下属反而不知道哪件事是眼前最重要的。我现在建议的总量控制是：CLAUDE.md控制在800字以内，单个任务模板控制在400字左右。如果必须写更多，就拆成多个较小的模板。

另外，模板里的描述不要太抽象，抽象描述会占字数但起不到约束作用。比如要写“关注代码质量”，不如写“检查是否存在命名不达意的变量或函数”，后者的约束力更强。每一条模板文字都要以“AI能据此作出不同行为”为标准来审查，如果一条规则加进去之后AI的行为跟没加之前完全一样，那这条规则就是噪音，应该删掉。

5.3 从“能用”到“好用”的三个优化点

模板做到“能用”很容易，但做到“好用”需要一些细节打磨。第一个优化点是在模板里放一个“输出示例”。人看着示例觉得多余，但对AI来说，示例是最有效的格式约束，它会在生成长内容时自动参考示例的排版和行文风格。我在每个模板的末尾都会附一小段示例输出，效果比任何“请用markdown格式输出”的指令都好。

第二个优化点是加入“自查清单”。我的模板里经常会有这样一段话：“输出前请对照以下清单检查：1. 是否包含明确结论；2. 是否遗漏风险项；3. 格式是否符合要求”。实测下来，加了自查清单之后，AI输出的完整度提升不少，尤其是漏项情况大幅减少。这个技巧背后的原理是“引导推理”，让AI在生成完毕后主动反向验证一遍自己的输出。

第三个优化点是利用“否定式约束”划红线。与其写十条“应该怎么做”，不如写三到五条“绝对不要怎么做”。比如“绝对不要跳过测试”“绝对不要修改未在本次任务中提到的不相关代码”，这种否定式指令比肯定式指令更有约束力，因为它的边界感更强，AI执行起来几乎不需要再理解判断。我所有的核心模板里，至少会保留三条否定式红线，它的存在感比一堆“应该”强很多。

6. 最后再分享一点经验

这套模板体系我从搭建到现在用了几个月，最大的收获不是省了多少时间，而是它让我重新思考了“人跟AI协作”这件事。以前我把Claude Code当成一个搜索引擎用，有问题就问，问完就走，每次对话都是孤立的。有了模板之后，我开始把它当成一个团队成员来看——你给它提供清晰的上下文和验收标准，它给你交付稳定的成果，这个过程跟管理一个初级工程师已经非常相似了。

如果你刚接触Claude Code，我的建议是从一个小场景开始，别一次性铺开。先挑一个你每周至少做三次的任务，比如代码审查，写出第一个模板，用两周时间观察效果、迭代一版。等这个模板稳定之后，再复制这个方法论到其他场景。这套路径虽然不是最快的，但每一步都是扎实的，不会让你一上来就被复杂的模板体系劝退。

最后再分享一个小技巧：给每个模板都起一个“动词+对象”的名字，比如“审查代码”“拆解需求”“重构模块”。这样你在调用的时候，脑子里会形成一个清晰的“动作感”，命令的意图也更聚焦。不要用“CodeReviewTemplateV3”这种毫无灵魂的名字，它没法帮助你形成“正在指挥AI干活”的意识。工具是为流程服务的，流程清晰了，工具自然就好用了。