企业官网建设流程全解析

1. 从零到一：我用模板重构了 Claude Code 工作流

先说结论：我把日常开发里反复用到的 Claude Code 指令、角色设定、代码规范全部沉淀成了一组模板文件，放在项目仓库的claude-code-templates目录下。这套东西不解决“AI 能不能写代码”的问题，它解决的是“AI 每次写代码的表现能不能稳定在 80 分以上”的问题。

如果你用过 Claude Code 或者其他 AI 编程助手，大概率遇到过下面这些情况：同一个项目，有时候它表现惊艳，有时候又蠢得离谱；换个新成员加入项目，AI 的行为风格完全走样；过两周回来继续开发，它好像失忆了一样。这些问题的根源不是模型本身，而是你没给它一套稳定、可复用的“工作上下文”。模板化的核心价值就在这里——把那些靠“现场打字”才能描述清楚的规则、偏好、边界，提前固化下来，每次启动都自动加载。

这篇内容适合谁？正在用 Claude Code 做实际项目开发的人，团队里想统一 AI 协作规范的技术负责人，还有那些被 AI 的“不稳定发挥”折磨到头疼的个人开发者。我会把模板的目录结构、每个文件的定位、为什么这么拆分、以及我在真实项目里踩过的坑全部讲清楚，你可以直接照着抄。

2. 模板体系的整体设计思路

2.1 为什么模板比“现场对话”可靠

很多人有一个误区，觉得 Claude Code 这类工具就是“你把需求说清楚，它就能干活”。实际用下来你会发现，需求描述只是最表层的东西。AI 真正需要的是三个层面的上下文：领域知识（这个项目是干什么的）、技术规范（代码该怎么写）、协作风格（它该以什么身份、什么节奏配合你）。

现场对话只能覆盖第一层，而且每次都要重新说一遍。模板解决的是第二层和第三层——这些恰恰是最消耗沟通成本的部分。我在实际项目中统计过，没有模板的时候，光是把“代码风格、测试要求、提交规范”这些事讲清楚，每次至少花 10 到 15 分钟。如果团队成员每个人讲一遍，成本直接翻倍。模板化之后，这些内容变成了一次性投入，后续所有会话自动加载，省下来的时间非常可观。

另一个很现实的点是：AI 的行为一致性。同一个模型，你上午给它一段情绪化的长篇大论，下午给它一段冷静的要点式指令，产出的代码风格可能完全不同。模板起到的是一个“稳压器”作用，把变量降到最低。团队合作时这个优势更明显——大家都是同一套规则，AI 生成的东西不会出现“这个人用空格、那个人用 Tab”之类的混乱。

2.2 模板的顶层目录结构

我最终落地的模板仓库结构长这样，你可以先整体看一眼，后面每个文件我都会拆开讲。

claude-code-templates/ ├── README.md ├── templates/ │ ├── system/ │ │ ├── expert-developer.md │ │ ├── code-reviewer.md │ │ └── technical-writer.md │ ├── workflow/ │ │ ├── feature-development.md │ │ ├── bug-fixing.md │ │ └── refactoring.md │ ├── project/ │ │ ├── python-project.md │ │ ├── typescript-project.md │ │ └── docker-workflow.md │ └── snippets/ │ ├── git-commit-template.md │ ├── pr-description-template.md │ └── test-case-template.md ├── config/ │ ├── claude-code-settings.json │ └── memory-rules.md └── scripts/ └── init-template.sh

这个结构不是拍脑袋定的，每个目录对应一类使用场景。system目录放的是“角色模板”，解决 AI 以什么身份工作的问题；workflow目录放的是“流程模板”，解决 AI 在不同任务类型下怎么推进的问题；project目录放的是“项目模板”，解决不同技术栈下的编码规范问题；snippets目录放的是“零碎模板”，解决高频小场景的效率问题。

这套分类方式跟我实际的工作习惯是对齐的：先定身份，再定流程，然后落到具体技术栈，最后处理边角料。如果你是自己个人用，不需要全部照搬，可以只挑其中两类，但目录的拆分逻辑建议保留——它能让后续添加新模板时归类清晰，不会变成一团乱麻。

2.3 模板文件的加载方式

Claude Code 支持通过--file参数加载外部文件，也支持在项目根目录配置.claude文件夹来统一加载。我推荐的做法是双轨并行：通用规则放.claude自动加载，任务专用模板用--file手动按需加载。

自动加载的好处是“无感”。你只要进了项目目录，AI 自动就知道你的代码风格是什么、测试要求是什么、提交规范是什么。手动按需加载的好处是“不污染”。如果所有模板都自动加载，上下文窗口会被大量无用规则塞满，反而影响 AI 对当前任务的理解。拿我自己的项目举例，.claude里只放最核心的体系文件——项目描述、技术栈、编码规范；其他像代码审查、重构建议这类模板，用到了再加载。

这里有一个具体的配置示例，你可以在.claude/settings.json里做基础设置：

{ "permissions": { "allow": [ "Bash", "Read", "Edit", "Write" ], "deny": [] }, "model": "claude-sonnet-4-20250514", "disallowedTools": [] }

权限配置这块我想单独强调一下。默认情况下，Claude Code 能执行的操作范围比较广，但在真实项目里，我遇到过它自作主张跑测试、改配置文件、甚至尝试 git push 的情况。所以我在权限里显式声明了允许的操作，把高风险操作挡在外面。你根据自己的风险评估去做调整，原则就一条：默认最小权限，用到再临时授权。

3. 角色模板：让 AI 进入正确的工作状态

3.1 专家开发者模板

这个模板解决的是 AI 在编码任务中的默认行为。我的经验是，如果你什么都不指定，Claude Code 会倾向于“最短路径完成任务”——写出能跑的代码，但不一定写出好代码。专家模板的核心作用就是抬高这个下限。

我实际使用的expert-developer.md核心内容如下：

# 角色定义 你是一名拥有 15 年经验的资深全栈工程师，先后在大型互联网公司和创业团队工作过。 你擅长： - 编写可维护、可测试、可扩展的代码 - 在动手前先分析需求，识别潜在风险 - 给出多个方案并说明取舍 # 工作原则 1. 动手写代码之前，先复述你对需求的理解，确认后再开始 2. 优先考虑代码的可读性和可维护性，而非炫技 3. 所有公共函数和复杂逻辑必须有文档字符串或注释 4. 当你发现需求本身有问题时，必须提出疑问，不要闷头实现 5. 代码提交前，自查是否有明显的边界条件和异常处理遗漏 # 代码风格 - 遵循项目既有的代码风格，不混合多种风格 - 变量命名要表意清晰，禁止使用 a、b、tmp 这类无意义命名 - 函数长度建议控制在 50 行以内，超过则考虑拆分 - 优先使用标准库，避免引入不必要的第三方依赖

为什么要这样写？关键在于它把“什么是好的行为”显式化了。AI 并不是不知道好代码长什么样，而是它默认状态下不会主动往这个方向努力。你给了它这套规则，它就会在生成代码前多一步“思考”，产出的质量会明显不一样。

3.2 代码审查者模板

代码评审是一个天然适合 AI 的场景，因为审查的核心是找出“问题模式”，这正是大模型擅长的事。但如果没有模板约束，AI 做审查时容易陷入两个极端：要么只揪着风格问题不放，对真正的逻辑缺陷视而不见；要么泛泛而谈，提一堆“考虑优化性能”之类的正确废话。

我的code-reviewer.md分成了四个审查维度，你可以这样组织：

# 审查范围 - 逻辑正确性：边界条件、空值处理、并发安全 - 代码风格：命名、格式、复杂度、重复代码 - 测试覆盖：关键路径是否有测试，测试是否真的有效 - 安全与性能：注入风险、敏感信息泄露、明显的性能瓶颈 # 审查规则 1. 按严重程度分级标记问题：阻断级、建议级、风格级 2. 阻断级问题必须给出具体复现路径或解决建议 3. 每个建议必须附带修改示例，禁止只说“建议优化”不给方案 4. 优先审查逻辑问题，风格问题放到最后 5. 不要为了找问题而找问题，正常代码不需要吹毛求疵

这个模板配合代码审查的实际操作方式是把要审查的代码粘贴进来，然后把这段模板内容放在最前面，Claude 就会自动切换成审查模式。我的体会是，做了这层设定之后，AI 的审查报告可用度会大幅提升，不再是“看起来说了很多，实际没几条能落地”的状态。

3.3 技术文档写作者模板

写文档是另一个高频场景。Claude Code 写文档有个通病：容易写得像“营销软文”，满篇都是“强大、灵活、高效”这类空泛词汇，却说不清楚这个东西到底怎么用。技术写作模板的核心约束就是“务实、精确、可执行”。

我建议在模板中强制使用下面的结构：

# 角色定义 你是一名技术文档工程师，擅长把复杂的技术概念讲清楚。 # 写作规则 1. 所有描述必须基于实际的代码或配置示例，禁止凭空造例子 2. 禁止使用“非常简单”“极其高效”这类主观模糊的描述 3. 每个操作步骤必须包含具体的命令、文件路径或代码片段 4. 先写概览，再写使用步骤，最后写常见问题和注意事项 5. 文档中的每个示例代码都必须经过逻辑验证，确定可以运行

你可能会觉得这些规则“太死板”，但实际用下来效果很好。因为 AI 默认写出来的文档，最大的问题恰恰是不够具体——它总是倾向于用抽象的描述替代具体的操作。模板把这些漏洞全堵死了，文档质量自然就上去了。

4. 工作流模板：不同任务场景的推进方式

4.1 功能开发流程模板

功能开发是 Claude Code 最常用的场景。但很多人直接甩一句“帮我实现一个登录功能”就完事了，结果 AI 给出的代码往往要么过度设计，要么缺东少西。功能开发模板做的事情，就是强制 AI 走完一个标准化的需求分析流程。

我设计的feature-development.md工作流如下：

# 功能开发标准流程 ## 第一步：需求澄清 - 用不超过 200 字复述你对需求的理解 - 列出你认为存在歧义或需要确认的点 - 给出你的实现方案概要（不超过 5 个关键步骤） ## 第二步：方案设计 - 列出可能的技术方案，至少 2 个 - 说明每个方案的优缺点 - 给出推荐方案，说明推荐的理由 ## 第三步：实现 - 按模块拆解实现步骤 - 每完成一个模块，简要总结实现逻辑 - 处理边界条件和异常情况 ## 第四步：自测建议 - 列出需要验证的测试场景（包含正常路径和异常路径） - 说明这些测试场景为什么必要

实际操作中，我会要求 Claude 严格按这个流程推进——第一步没确认清楚，就不准进入第二步。这样做有个额外的好处：你可以在最早的时间点纠正方向，避免 AI 埋头写了半天，结果发现跟你的想法完全不一样。

4.2 Bug 修复流程模板

修 Bug 的时候，AI 最常见的问题是“头痛医头、脚痛医脚”。你给它一个报错信息，它直接给出一个改动方案，但这个改动可能引入了新问题，或者根本没找到根因。Bug 修复模板的设计目标，就是强制 AI 先定位根因再动手。

下面这段是我实际在用的核心逻辑：

# Bug 修复标准流程 ## 第一步：复现与定位 - 先根据报错信息回溯代码路径，定位可能的根因位置 - 排查顺序建议：输入数据 → 逻辑处理 → 外部依赖 → 环境配置 - 不要跳过定位环节直接给出补丁 ## 第二步：根因分析 - 解释为什么会出现这个问题，而不是只描述“哪里出错了” - 区分根因和触发条件：根因是代码缺陷，触发条件是特定输入或环境 ## 第三步：修复 - 给出最小化的修复改动，避免无关重构 - 说明修复为什么有效，以及它影响的代码范围 ## 第四步：回归验证 - 列出需要回归测试的场景 - 特别注意修复是否会影响原有功能

这个模板最核心的就是“最小化改动”这条。我踩过不少坑——让 AI 修一个简单的空指针，结果它顺手把整个函数的逻辑重构了一遍，测试全得重跑。明确的约束能有效避免这类问题。

4.3 代码重构建议模板

重构不是一个“一句话任务”。如果没有约束，Claude 容易给你丢出一大段重构后的完整代码，你却看不出来它到底改了什么、为什么这么改。重构模板的核心是“分步出方案，而不是一次性交作业”。

我在模板里要求的输出格式是这样的：

# 重构建议报告 ## 当前问题 - 列出你发现的具体问题（如：函数过长、重复代码、过度耦合） - 按影响程度排序，标注每个问题的严重等级 ## 重构方案 - 分步骤给出重构建议，每一步说明改什么、为什么改 - 每步都给出改动前后的代码对比示例 - 说明每步重构的风险等级（低、中、高） ## 验证方案 - 说明重构后如何验证行为不变性 - 列出需要重点关注的测试用例

用这个模板，我通常会让 AI 先输出报告，然后我自己决定哪些步骤真正值得执行。很多时候它的建议并不全对——比如有些“重复代码”其实是业务上刻意的隔离，为了改造成本去动它们反而得不偿失。

5. 项目上下文模板：锁定技术栈规则

5.1 Python 项目模板

项目模板是每个团队都应该最先建立的，因为它承载的是这个项目“特有的规则”。不同的技术栈、不同的业务领域，代码规范差异非常大。如果不写进模板，AI 每次只能靠猜。

我的python-project.md内容参考如下：

# 项目技术栈 - Python 3.11 - FastAPI + SQLAlchemy 2.0 - PostgreSQL 15 - Pytest + factory_boy # 代码规范 - 类型标注：所有函数必须包含完整的类型标注，禁止裸 `Any` - 导入规范：标准库 → 第三方库 → 项目内部模块，每组之间空一行 - 数据库操作：禁止在业务逻辑层直接写 SQL，必须通过 Repository 层 - REST API 设计：路径使用复数名词，HTTP 方法语义必须准确 # 测试要求 - 所有视图函数必须有对应的接口测试 - 涉及数据库操作的测试必须包含事务回滚 - 测试数据使用 fixture 管理，禁止在测试内硬编码真实 ID

很多团队觉得“这些规则我们 PR 评审的时候也会说啊，没必要写进模板”。但实际体验完全不一样——PR 评审是事后发现，写进模板是事前预防。AI 第一次生成的代码就符合规范，比事后让人工改要高效得多。

5.2 TypeScript 项目模板

TS 项目跟 Python 项目的关注点差异很大。Python 重点是类型标注和分层，TS 项目的重点则是模块边界、异步处理、状态管理。如果团队用 TS，模板应该聚焦这些领域。

# 项目技术栈 - TypeScript 5.x - Next.js 14 (App Router) - Zustand 状态管理 - TanStack Query 数据请求 # 代码规范 - 禁止在组件内部直接发起 API 请求，必须通过 hooks 封装 - 所有异步函数必须处理错误状态，禁止裸 await 不捕获异常 - 组件 props 使用 `type` 定义，不使用 `interface` - 禁止使用 `any`，特殊情况必须注释说明原因 # 命名约定 - 组件文件：PascalCase，如 `UserProfileCard.tsx` - 辅助函数：camelCase，如 `formatUserData.ts` - 常量：SCREAMING_SNAKE_CASE，如 `MAX_PAGE_SIZE`

对前端项目来说，组件边界和 hooks 封装是最容易失控的地方。把这两条写进模板，AI 生成的前端代码整体可维护性会好非常得多。

5.3 Docker 工作流模板

Docker 相关任务在 Claude Code 里很容易出问题，因为 AI 对“你这个项目的镜像环境”没有感知。它可能建议你在生产镜像里装编译器，或者忽略多阶段构建。项目级的 Docker 模板能把这些东西固定下来。

我常用的配置描述如下：

# 容器化规范 ## 基础镜像 - 生产镜像必须使用多阶段构建，构建阶段用完整镜像，运行阶段用精简镜像 - 优先选择官方镜像，禁止使用来源不明的第三方镜像 ## 环境变量 - 配置统一通过环境变量注入，禁止硬编码在代码或镜像层 - 敏感信息（密码、密钥）禁止写入 Dockerfile，用 Secret 管理 ## 健康检查 - 所有服务必须配置 HEALTHCHECK 指令 - 健康检查接口返回非 200 时，容器应自动重启 ## 体积控制 - 生产镜像体积目标控制在 500MB 以内 - 安装依赖前必须清理缓存和临时文件

Docker 类任务如果你不给规则，AI 生成的 Dockerfile 用倒是能用，但往往不够规范。这类模板的作用不是“教 AI 怎么写 Dockerfile”，而是“告诉它你们公司的 Dockerfile 风格是什么”。

6. 高频场景模板：Git 提交与 PR 描述

6.1 Git 提交信息模板

Git 提交信息是我的模板体系里见效最快、感知最强的一个。原因很简单：提交信息是最容易被 AI 生成、也最容易被团队成员看到的内容。用模板之前，AI 生成的提交信息风格千奇百怪，有的像散文，有的只有一句话。

我用的是 Conventional Commits 规范，模板如下：

# Git 提交信息模板 <type>(<scope>): <subject> <可选 body> <可选 footer> # type 取值： # feat: 新功能 # fix: 修复 Bug # refactor: 重构，不改变外部行为 # docs: 仅文档变更 # test: 新增或修改测试 # chore: 构建、工具链、依赖等杂项变更 # perf: 性能优化 # 示例 feat(user): 添加用户头像上传功能 - 新增头像上传接口，支持 JPG/PNG 格式，单文件最大 5MB - 上传成功后同步更新用户信息缓存 - 增加文件类型和大小校验 Closes #123

这个模板用上去之后，我在 GitHub 上看提交历史的体验会好非常多。一眼扫过去，就知道每个提交干了什么，跟哪个 Issue 关联。

6.2 PR 描述模板

PR 描述比提交信息更复杂一点，它需要包含背景、改动内容、测试情况、影响范围。如果让 AI 自己发挥，它通常会写得很完整但也很冗长，找不到重点。模板的作用是强制它按“决策者想看到的信息结构”来组织。

# PR 描述模板 ## 背景 用 2-3 句话说明为什么需要这个改动，关联的 Issue 或需求编号。 ## 改动内容 分点列出主要改动，每条不超过一句话，说明改了什么、为什么改。 ## 测试计划 列出本次改动涉及的功能点，以及对应的测试方式： - 单元测试：说明覆盖的函数和场景 - 接口测试：说明覆盖的 API 和用例 - 手动验证：说明需要人工确认的交互或流程 ## 影响范围 说明本次改动可能影响的其他模块或功能，需要重点回归的部分。 ## 部署注意事项 如果有数据库迁移、环境变量变更、依赖更新，必须单独列出。

按这个模板生成的 PR 描述，评审人和后来的维护者都能快速抓住重点。这对我自己回看历史 PR 也特别有用——哪怕是半年以后，看 PR 描述就能想起来当时的上下文，不用去翻代码。

6.3 测试用例模板

测试用例模板在团队协作中容易被忽略，但它的价值很大。AI 生成的测试往往倾向于“覆盖快乐路径”，对异常路径和边界条件的覆盖不足。模板能把这点纠正过来。

# 测试用例模板 ## 模块 / 函数描述 - 被测对象：函数名或类名 - 功能说明：一段话说明被测对象的主要行为和业务规则 ## 测试用例列表 ### 用例 1：正常路径 - 输入：具体的测试数据 - 预期输出：具体的断言结果 - 说明：这条用例覆盖了哪些分支逻辑 ### 用例 2：异常路径 - 输入：异常的测试数据（如空值、越界值、格式错误） - 预期输出：期望抛出的异常或错误提示 - 说明：为什么这条输入能触发异常 ### 用例 3：边界条件 - 输入：边界数值（如最大值、最小值、空集合） - 预期输出：具体断言结果 - 说明：边界条件的业务意义 ## 测试数据要求 - 禁止在测试代码中硬编码真实业务数据 - 优先使用 faker 或其他工具生成随机测试数据

有了这个模板，AI 生成的测试不再只是“为了通过而写”，而是真正能发现问题的测试。我个人的习惯是每写一个新模块，就让 AI 按这个模板生成一版测试用例，然后我会手动补充几个它没覆盖到的场景。

7. 模板工程的安装与自动化启动

7.1 初始化脚本设计

模板体系的好处是内容固化，但真正能不能用起来，取决于“用起来是否足够省事”。如果每次都要手动去复制粘贴文件，再分别调用--file参数，那很多人会嫌麻烦直接用回最原始的方式。所以我在模板仓库里加了一个初始化脚本，把安装过程自动化。

我写的脚本长这样（这是实际可用的版本）：

#!/bin/bash # claude-code-templates 初始化脚本 # 用法: ./init-template.sh /path/to/your/project set -e PROJECT_DIR="${1:-.}" SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" echo "初始化 Claude Code 模板到: $PROJECT_DIR" # 1. 创建 .claude 目录 mkdir -p "$PROJECT_DIR/.claude" # 2. 复制核心模板文件 cp "$SCRIPT_DIR/templates/system/expert-developer.md" "$PROJECT_DIR/.claude/" cp "$SCRIPT_DIR/templates/system/code-reviewer.md" "$PROJECT_DIR/.claude/" cp "$SCRIPT_DIR/templates/workflow/feature-development.md" "$PROJECT_DIR/.claude/" cp "$SCRIPT_DIR/templates/workflow/bug-fixing.md" "$PROJECT_DIR/.claude/" # 3. 创建 settings.json cat > "$PROJECT_DIR/.claude/settings.json" << EOF { "permissions": { "allow": ["Bash", "Read", "Edit", "Write"], "deny": [] }, "model": "claude-sonnet-4-20250514", "disallowedTools": [] } EOF # 4. 创建项目记忆文件 cat > "$PROJECT_DIR/.claude/memory.md" << EOF # 项目记忆 > 每次会话开始时，先阅读此文件，了解项目的关键信息。 ## 技术栈 - 请在此处填写项目的主要技术栈 ## 关键约定 - 请在此处填写项目的关键约定（代码风格、测试要求、部署流程等） ## 当前状态 - 请在此处填写当前开发进度和最近完成的事项 EOF echo "模板初始化完成。" echo "下一步：编辑 $PROJECT_DIR/.claude/memory.md 填写项目信息"

这个脚本的核心作用是把“复制文件、创建配置、生成项目记忆”三步合一。你只需要跑一次，就能把整套模板基础打进新项目的目录。

7.2 项目级别的启动方式

除了目录结构，Claude Code 本身也支持项目级的CLAUDE.md文件。这个文件会自动加载，相当于一个“永久记忆”。我的建议是把项目的核心背景和最关键的规则放在CLAUDE.md，其他更细的模板按需加载。

CLAUDE.md的示例结构：

# 项目背景 这个项目是一个面向中小企业的进销存管理系统，包含采购、销售、库存、报表四个核心模块。 当前阶段正在开发销售模块，已完成订单创建和订单列表功能。 # 技术栈 - 前端：React 18 + TypeScript + Vite - 后端：Python FastAPI + PostgreSQL - 部署：Docker Compose，部署服务器为 Ubuntu 22.04 # 关键约定 - 所有日期时间统一使用 ISO 8601 格式，后端存储 UTC，前端展示本地时间 - 所有涉及金额的字段使用 Decimal 类型，禁止使用 float - API 统一返回格式：{ "code": 0, "data": ..., "message": "ok" } # 常用命令 - 启动后端：`cd backend && uvicorn main:app --reload --port 8000` - 运行测试：`cd backend && pytest -v` - 构建前端：`cd frontend && npm run build`

为什么CLAUDE.md和模板文件要分开？因为项目的“稳定信息”和“任务信息”性质不同。技术栈、编码约定这类信息是长期稳定的，应该一直加载；而某个具体任务的执行流程，只在需要时才加载，避免长期占用上下文窗口。这个分离设计，我用下来是最省心的。

7.3 模板更新与版本管理

模板不是写一次就完事，它需要跟着项目的演进持续迭代。我建议把claude-code-templates仓库本身纳入 Git 管理，每次修改模板都留有记录，这样你能清楚看到哪些规则是何时加入的、当时是为了解决什么问题。

更新的节奏我想提醒一下：不要频繁改模板。模板是“稳定约束”，今天加一条、明天改一条，会让 AI 的行为变得难以预测。我的经验是，固定一个更新周期（比如一个月一次），在周期内收集所有“想加进模板的规则”，统一评估后一次性更新。遇到紧急的安全或规范问题，再走快速通道单独改。

8. 实战中的踩坑记录与排查方法

8.1 模板加载方式踩坑

这套模板体系我落地过程中遇到的最大问题，是“自动加载的模板过多，导致 AI 犯糊涂”。最开始我把所有模板都放进了.claude目录，结果每次会话 AI 的行为反而变得很怪——有时候严格执行工作流模板，但忽略了专家角色的原则；有时候又反过来。

原因其实不难理解：多个模板同时加载，等于给了 AI 多套冲突的指令体系。它需要花额外的“注意力”去判断哪个规则优先，结果就是哪个都没执行好。解决方案回到我在前面提到的双轨制：.claude只放一套核心规则，其他模板按需加载。

另一个踩坑是权限配置。早期我为了省事，permissions里全放了allow，没有deny，结果 AI 在调试的时候自己执行了git reset --hard，把本地提交全部打回原形。从那以后我学乖了——高风险操作一律不默认放行，需要用到时再授权。这条教训成本有点高，写出来给大家避坑。

8.2 常见问题速查表

我把实际使用中碰到的高频问题整理成了一张速查表，基本覆盖了模板化方案落地时的主要障碍。

这里我想特别展开“思考变浅”这个问题。因为它不是模板本身的问题，而是模板用过头了出现的问题。当你给了 AI 一套很详细的规则，它会倾向于“按规则办事”，而不是“想清楚再办事”。比如需求本身有歧义，AI 可能直接按字面理解去实现了。所以我的模板里普遍会加一条“先复述理解、确认后再动手”的规则，就是为对冲这个副作用。

8.3 模板维护的三个心得

第一，模板要写“边界”而不是写“做法”。什么叫边界？“不要在业务层直接写 SQL”是边界。什么叫做法？“用这个 Repository 类的这些方法”是做法。边界类规则能约束行为，又不僵化；做法类规则容易过时，还限制 AI 发挥。写模板时多往边界靠。

第二，模板要不断地做减法。每次你发现 AI 表现了某个问题，第一反应可能是“加一条规则进去”。但规则太多，AI 真正能记住并执行的有限。我的做法是每条新规则都优先考虑替换旧规则，而不是单纯追加。

第三，模板的成功标准是“可预测性”。如果你的 AI 现在每次产出都能稳定在 70 分以上，模板就是有效的。反之，如果你还在反复调规则，说明模板体系没搭对方向，而不是缺了什么内容。这一点验证方式也很简单：让两个不同时间点的会话处理同一个任务，对比输出的一致性。

按这套方式把模板体系搭好之后，我自己的日常开发体验变化非常大。以前每次打开 Claude Code 都要花时间表述项目背景、代码规范、任务流程，现在启动即进入正题。AI 的产出质量也从这个任务换一套状态、下个任务又变了一个人，变成了稳定输出、风格统一的“团队标准成员”。这套模板体系最直接的收益是省时间，但更长期的收益是你对 AI 产出的信任——知道它在大多数情况下不会跑偏。模板里的每个文件都还有很大的自定义空间，你完全可以根据自己项目的特征去扩展。我自己后续想做的方向，是把测试用例模板和项目模板做更细的联动，让 AI 在生成代码时自动考虑测试覆盖，这是一个值得继续投入的方向。