你明明已经用上了 Claude Code但为什么它写出来的代码还是“很AI”对项目里那些约定俗成的规则视而不见原因多半不是模型不行而是你没给它一套“项目说明书”。我自己维护 claude-code-templates 这套模板体系已经大半年从最开始一个人用到现在带着小团队一起用最大的感受是把配置、项目记忆、自定义命令沉淀成模板仓库才是从“能用”跨到“好用”的那道坎。这篇内容会把整套模板从设计思路、目录结构、核心文件写法到落地踩坑的完整流程摊开来讲。适合三类人刚把 Claude Code 装进终端还在摸索的初学者已经用了一两周但总觉得 AI 不够懂你项目的开发者以及想在团队里统一 AI 编码助手行为规范的技术负责人。1. 模板化到底解决了什么问题1.1 不配置 Claude Code 时实际体验有多随机我刚开始用 Claude Code 的时候态度是“装好就能用了”。结果用了几次就发现效率很不稳定每次在新目录里开一个会话都得把项目背景重新讲一遍比如“我们前端是 React TypeScript接口封装在 src/api后端数据库表结构在 server/migrations 里”。遇到复杂一点的改动AI 甚至会给出完全不符合项目现状的建议比如让我改一个根本不存在的配置文件名。后来我想明白了Claude Code 本质上是一个能跑在终端里的编码助手它的上下文来自两部分一是你当前对话里输入的内容二是它能主动扫描到的项目文件。它并不会“自动理解”你们团队内部约定。代码变量命名偏好、接口返回结构、数据库迁移规范、禁用的依赖版本这些信息你不写下来它每次都是靠猜。更麻烦的是同一个仓库里不同会话之间是互相隔离的这次会话里教会它的东西下次重启终端就全忘了。这种随机感在个人项目里还能忍受最多多解释几句。但放到团队里就变成灾难十个人用出十种效果有人觉得 AI 太啰嗦有人觉得它乱改代码有人干脆因为权限弹窗太多放弃使用。问题不在于 Claude Code 不够强而在于没有人给它一份统一的“工作手册”。1.2 三层模板体系团队、项目、个人claude-code-templates 这套方案的核心是把“背景知识”和“行为规则”按使用范围拆成三层分别落到不同的配置文件里。第一层是团队层。通常放在一个独立的团队共享仓库里内容是全组通用的硬约束比如提交信息格式、禁止在代码里写死密钥、必须为新增接口补充单元测试等等。任何人把项目拉到本地只要执行一次模板拉取命令就能拿到这些公共规则。第二层是项目层。就是跟着业务代码仓库走的 .claude/ 目录里面包含 CLAUDE.md、自定义命令和权限配置。这一层和具体业务强相关记录的是这个仓库独有的技术栈、目录约定、关键架构流程。项目层是模板体系中比重最大的一层也是文章后面要重点展开的部分。第三层是个人层。放在用户主目录下的 ~/.claude/ 里保存的是个人偏好比如你习惯用哪个模型、默认编辑器是什么、要不要开启某个代理功能之类的。个人层的配置不进入项目仓库避免不同开发者的习惯互相污染。三层之间的关系可以理解成一层层叠加个人层提供基础偏好团队层设定公共底线项目层补充业务专属细节。项目目录内的配置优先级最高这也是为什么同一个团队里大家进入同一个仓库后 AI 行为会收敛到“同一套标准”。1.3 真正的收益不是省时间而是确定性很多人一听“模板化”就想到提效觉得是省下了重复描述背景的时间。我用下来的体会是模板化的第一收益不是省时而是让 AI 的输出变得可预期、可审查。打个比方你招了一个能力很强但是完全不了解公司的新人如果入职当天只丢给他两台显示器让他自己看代码他第一周大概率在瞎转但如果给一份写清楚的 SOP他当天就能按规范提 Pull Request虽然细节上可能还需要磨合但大方向不会跑偏。CLAUDE.md 和自定义命令就是给 AI 做的入职培训材料。确定性带来一个额外的好处Code Review 的时候你审查的维度更干净了。AI 生成的代码如果不符合项目规范那是模板没写到位而不是模型能力问题修正模板后同类问题会批量消失。这种“花费一次配置、持续降低摩擦”的杠杆才是模板体系真正值得投入的原因。2. 模板体系的整体设计思路2.1 为什么选择“模板仓库”而不是零散文件一开始我也没想过要建模板仓库就是在项目里随手写个 CLAUDE.md。但等我把自定义命令加到七八个之后开始意识到问题这些文件只存在某个业务仓库里新建仓库时又要重新复制一遍团队其他人想要同步我的配置只能拿着聊天记录里的代码块自己拼。后来我把整套配置抽成了一个独立的模板仓库做法是把 .claude/ 目录放到一个名为 claude-code-templates 的基础仓库里新项目直接复制进去或者用 git subtree 拉取。这样做有三个很直接的好处。第一是版本管理。模板的任何改动都能走 Git Diff、PR Review 的流程哪天改出了一批不合适的命令一键回滚到上一个稳定 tag 就行。第二个好处是持续演进。模板仓库独立于业务仓库不会随着业务迭代被误改规则调整时影响面是可控的不会因为某个业务分支的代码合并把模板文件也搞乱。第三个好处的团队协作价值最大所有人对着同一个模板仓库讨论而不是各自维护一套神秘配置。2.2 一套可复用的模板仓库目录结构下面是我目前维护的模板仓库的实际目录结构不算复杂但足够覆盖大部分技术团队的日常需求。claude-code-templates/ ├─ README.md # 使用说明和快速开始 ├─ projects/ │ └─ claude-code-example/ # 一个可直接参考的示例项目 │ ├─ .claude/ │ │ ├─ CLAUDE.md # 项目记忆与行为准则 │ │ ├─ settings.json # 权限、默认模型、环境变量 │ │ └─ commands/ │ │ ├─ review.md # 代码审查 │ │ ├─ commit.md # 生成提交说明 │ │ ├─ test.md # 运行与补充测试 │ │ ├─ refactor.md # 重构指引 │ │ ├─ docs.md # 生成技术文档 │ │ └─ oncall.md # 排查线上问题 │ └─ ...其他业务文件 └─ CHANGELOG.md # 模板版本变更日志每个文件承担的角色很明确CLAUDE.md 负责“知识”它告诉 AI 这个项目是什么、技术栈是什么、有什么必须遵守的规则settings.json 负责“边界”控制 AI 能执行哪些操作、用什么模型、挂哪些钩子commands/ 目录下的每个 markdown 文件则是一个个“行为触发器”把用户敲下的斜杠命令展开成一段结构化的任务指令。2.3 设计顺序先定规则再写命令最后收紧权限我见过不少朋友的模板写反了顺序一上来先兴致勃勃地写七八个斜杠命令结果命令触发了之后AI 因为不清楚项目背景输出的东西还是不符合团队要求。这里面的逻辑关系是命令文本本质上只是一段“带触发器的临时指令”它必须依赖 CLAUDE.md 里已经建立好的项目全局知识来落地。正确顺序应该分三步。第一步是先把规则写清楚包括项目定位、技术栈、代码规范、禁区清单第二步才是根据“高频重复任务”设计命令比如代码审查、生成提交说明、补测试第三步才是去 settings.json 里收紧权限。先有规则命令才有骨架先有命令你才知道到底哪些工具调用是高频的、哪些操作需要被 ask 而不是 allow。还有一个经验不要把权限设计成一次到位的完美配置。权限规则的收敛是一个动态过程应该在用模板干活的头一两周里持续收集弹窗记录再分批调整。后面我会专门讲这个。3. 核心文件逐层拆解与写法要点3.1 CLAUDE.md给 AI 做入职培训的主文档CLAUDE.md 是整个模板体系里最值得花心思的文件。它会被 Claude Code 在每个会话开始时自动读取作用相当于项目长期记忆。记住一个原则Claude Code 的记忆不是持续的长期记忆而是每次开场时临时加载的内容所以这个文件既是“记忆”也是“指令”写法的优先级和结构直接决定 AI 的执行效果。我总结出来的一个可靠结构是六段式第一段项目定位一句话说清楚这个项目是干什么的。第二段技术栈与目录约定列出主要框架、语言、关键目录以及文件位置。第三段架构与关键流程说明核心链路是怎样的。比如请求从哪里进来、经过哪些层、数据落到哪里。第四段常见任务范式把最高频的几类操作描述成固定步骤。第五段代码规范列出必须遵守的硬性约束。第六段禁止事项明确写出绝对不要做的事。下面是一个精简示例你可以感受一下密度和语气。# CLAUDE.md ## 项目定位 这是一个面向个人用户的待办事项 Web 应用前后端分离。 ## 技术栈与目录约定 - 前端React TypeScript Vite代码在 src/ 目录 - 后端Node.js Fastify PostgreSQL代码在 server/ 目录 - 数据库迁移脚本统一放在 server/migrations/ - 公共类型定义放在 shared/types.ts ## 核心约束 - 所有新增接口必须补充 TypeScript 类型定义禁止出现 any - 修改数据库表结构必须同时提交迁移文件和回滚脚本 - 接口错误信息统一返回结构{ code, message, data } ## 常见任务 - 新增 API 路由在 server/routes/ 下新建文件并在 server/app.ts 注册 - 前端请求接口必须调用 src/api/client.ts 里的封装不要直接拼 fetch ## 禁止事项 - 不要 mock 后端接口除非后端接口尚未定义 - 不要修改 shared/types.ts 里的既有字段需要扩展时新增字段 - 不得在服务端代码中使用 require 引入 ESModule 包写这份文档时最容易犯的错是写得像散文。模型在冗长段落里提取要点是靠注意力权重你越是用长句、形容词、背景故事去描述规则越容易被忽略。正确做法是短句、列表、明确动词。把“尽量使用函数式编程风格”改成“只允许使用函数式编程风格禁止 class 语法”效果会好得多。另一个技巧是排序。Claude Code 读取 CLAUDE.md 的时候靠前的内容天然获得更高的执行优先级。所以我会把最不能妥协的三条硬性约束放在文件前部通用规范往后放。如果你把“禁止提交密钥”这种安全红线写到文件最后AI 越大越长的会话里越容易遗忘它。3.2 commands把高频任务变成一句斜杠commands 目录下的每个文件对应一个斜杠命令格式是在 Markdown 文件顶部加 YAML frontmatter正文就是 AI 拿到这个命令后要执行的任务说明。frontmatter 里必须有 description 字段它决定了这个命令在斜杠菜单里显示的名字所以写得越清晰越好比如“对当前分支的改动执行严格代码审查”而不是“代码 Review”。命令文件支持把用户在斜杠后面输入的参数直接传给 AI我平时用到最多的是 $ARGUMENTS 这种整段参数的形式它会把用户敲完命令后的所有文字都带进去。位置参数在部分版本里也能用看你的 Claude Code 版本支持情况不过对大多数场景来说 $ARGUMENTS 已经够了。看一个实际用过的 review.md 示例。--- description: 执行一次严格的代码审查重点关注正确性和安全问题 --- 你是一名严格的资深代码审查者。审查对象是当前分支相对 main 分支的全部改动如果用户传入了文件列表则缩小到这些文件。 执行步骤 1. 使用 git diff 获取变更内容先确认改动文件清单。 2. 逐文件阅读并重点检查以下几类问题 - 逻辑正确性边界条件、空值处理、并发场景 - 安全隐患注入问题、敏感信息明文、权限校验缺失 - 可维护性命名是否清晰、重复代码、函数是否过长 3. 输出每一项问题时必须带上文件路径 行号 问题说明 修改建议。 4. 最后用 Markdown 表格汇总问题清单按严重程度从高到低排序。 要求 - 没有问题时就明确写“未发现明显问题”不要为了凑建议而硬找问题。 - 如果存在明显性能风险单独增加一节说明。这个命令看起来不复杂设计时的关键决策是“强制输出格式”。如果不加“必须带文件路径和行号”这一条AI 的审查结果会变成泛泛而谈的十条建议看着很有道理但你在具体代码里根本定位不到问题。加上行号约束之后AI 的审查结果从“结论为主的评论”变成了“可以直接派活儿的清单”这是实测里最明显的效果改善。写命令文件还有几条心法。一条命令只做一件事别把“审查加格式化”塞在一起否则 AI 会顾此失彼。命令正文不要重新罗列 CLAUDE.md 里已有的团队规则只需要引用“按 CLAUDE.md 的规范执行”避免规则不一致。命令描述里可以指定严谨程度比如“只提出问题最严重的前五条”限制输出规模防止生成一大篇内容撑爆上下文。3.3 settings.json权限、模型与自动化的边界settings.json 是模板体系里负责“安全边界”的文件也是最容易被新手忽略的。我见过有人完全不配置权限让 Claude Code 裸奔跑在项目里结果 AI 尝试执行 rm 命令的时候弹窗提示人还没看仔细就按了允许。这类事故其实用一个 deny 规则就能避免。一个典型的 settings.json 长这样。{ permissions: { allow: [ Bash(git status:*), Bash(git diff:*), Read(server/routes/**) ], deny: [ Bash(rm -rf:*), Bash(git push --force:*), Edit(package-lock.json) ], ask: [ Bash(npm install:*), Edit(server/migrations/**) ] }, model: 你的默认模型ID, env: { NODE_ENV: development } }permissions 下面有三类规则。allow 是白名单列进去的操作或路径权限会直接放行不弹窗deny 是黑名单列进去的无论如何都不允许执行ask 是中间态每次执行前都会询问用户。三者的优先级关系是 deny 最高其次是 ask最后是 allow。默认情况下未匹配到任何规则的请求会走 ask 弹窗。我建议的启动配置是“宽 ask、窄 allow、明确 deny”。先只 allow 那些绝对安全的低风险操作比如 git status、git diff、读取特定目录把高风险操作明确加入 deny剩下的让 AI 每次询问。这样虽然前期弹窗多一点但你能快速看到 Claude Code 在真实任务里到底想干什么再决定要不要逐步把高频安全操作挪进 allow。permissions 里可以针对文件路径做精细控制比如对 server/migrations 目录走 ask保证数据库变更不是 AI 悄悄完成的。也可以把某个调整频度极低但影响巨大的文件放进 deny比如 package-lock.json避免 AI 在改依赖的时候把锁文件改乱。除了 permissions我还经常用 env 字段注入项目需要的环境变量以及在 hooks 里挂一些自动化钩子。hooks 在这里的意义是对工具调用做前置或后置处理比如在 PreToolUse 阶段拦截某些敏感命令或者在 PostToolUse 阶段自动做格式检查。这个机制稍微复杂但它是把模板从“指导 AI”升级为“约束 AI”的关键一层等你对权限管理得心应手之后值得深入研究。4. 从零搭建一套可用模板的全流程4.1 第一步从项目文档里萃取 CLAUDE.md搭建模板的第一步不要直接坐在编辑器里“盲写”而是先做一个信息盘点。找你们项目仓库里现有的 README、架构设计文档、接口规范、数据库设计文档甚至 CI 配置里暴露出的脚本约束把里面真正影响日常编码的规则挑出来转化成 CLAUDE.md 的条目。我第一次徒手写 CLAUDE.md 的时候一口气写了 200 多行恨不得把整个项目历史都写进去。结果发现 Claude Code 在长文档里反而会“失焦”很多核心规则被淹没在无关描述里。后来我做了个减法把 CLAUDE.md 压到 40 行左右只保留真正每天都会被用到的信息执行效果反而好了很多。这个教训很关键CLAUDE.md 不是项目文档的搬运工它是给 AI 看的“高浓度指令集”写太多等于没写。具体做法是先把项目里所有文档读一遍摘出这些信息技术栈清单、源代码目录结构、构建和测试命令、数据库变更流程、代码风格硬性要求、安全红线。逐条写进 CLAUDE.md然后问自己一个问题如果今天新来一个开发他读完这份 CLAUDE.md 之后能直接动手改代码而不会问蠢问题吗如果哪里存疑就补上如果一段信息只是装饰性的背景就删掉。还有个实用技巧写完初版之后在 Claude Code 会话里直接问它“根据 CLAUDE.md这个项目的技术栈是什么新增一个 API 路由的步骤是什么有哪些禁止事项”它复述得对不对基本能验证文档写得清不清楚。如果它复述出来跟你预期不一致说明对应条目写得有歧义需要改写得更明确。4.2 第二步编排高频命令并逐个验证CLAUDE.md 只是基石命令才是模板的“门面”。这一步的工作量不在于写命令本身而在于选对命令。从你最痛的高频任务开始团队里每天都要做的事就是优先级最高的命令。大多数技术团队前三个命令可以定为代码审查、生成提交信息、补测试。拿生成提交信息举例这个场景看起来简单但写起来也有讲究。--- description: 根据当前暂存区的改动生成符合团队规范的 git commit 信息 --- 阅读 git diff --cached 的暂存内容生成提交信息。 要求 1. 严格遵循团队的 commit 规范feat/fix/refactor/docs/test/chore 作为前缀。 2. 信息控制在 50 个字符以内使用中文描述。 3. 如果暂存区没有内容检查工作区是否有未暂存改动并提示先执行 git add。写完之后最关键的是逐个验证而不是写完就算。验证方法很简单真实跑一遍。切到业务仓库的功能分支执行 /review 命令看它输出的结果是不是你真正在 Code Review 时关心的问题。第一次验证通常会发现命令写得过宽或过窄比如 review 命令在第一次测试时输出了十条通用建议我把“必须结合具体文件行号”加上之后输出才变成可执行的行动项。我习惯给每个命令做一张简单的验证表记录命令名、测试场景、预期结果、实际结果。模板不是说写出来就完美了而是要在真实任务里反复打磨出来的。4.3 第三步权限收敛与面向团队的灰度发布模板在自己项目上跑得顺之后不要急着大范围推给团队。我建议先做一轮权限收敛。方法很简单开一两个开发阶段分支按你日常改代码的真实路径去操作凡是弹窗允许的操作都记录下来。跑完一个完整体验流程后把那些“每次都会用到且毫无风险”的操作批量加入 allow把危险操作明确列入 deny。这轮收敛做完模板的体验才会从“每分钟弹一次窗”变成“大部分时间安静工作”。如果跳过这步就把模板发到团队群同事大概率会因为弹窗太多直接放弃使用你也收不到有效反馈。权限收敛之后是灰度发布。我当时的做法是先在团队里找两个愿意尝鲜且代码基础比较好的同事让他们分别拉取模板先在自己的个人分支上跑一周。一周后回收反馈处理命令冲突、权限缺漏、文档表述不清这类问题。等模板在他们手上稳定了再面向全团队发布。发布也不是一次性覆盖团队模板仓库要打 tag比如 v1.0.0大家拉取后自己 diff 一下再确认是否引入到业务仓库。这样每轮模板升级都是一次显式的代码变更而不是静默发生的玄学。5. 常见问题与排查技巧实录5.1 slash 命令不生效先别急着怀疑 AI经常有人问我“为什么我的 /review 命令敲了没反应”排查步骤其实很固定。第一步看文件位置对不对自定义命令必须放在当前项目目录的 .claude/commands/ 下放错层级 Claude Code 找不到。第二步看文件名和后缀必须是 .md 结尾命名建议全小写加短横线虽然命令名也有一定的容错空间但保持小写能省掉很多大小写踩坑。第三步看 YAML frontmatter 是否合法。description 字段写错或者引号没闭合整个文件都会被忽略。最后一步才是看 AI 表现在会话里敲一个 / 看命令是否出现在列表里如果出现但行为异常那就是正文指令的问题如果根本没出现问题基本出在前面三处。现象先查这里再查那里命令不出现在列表文件是否在 .claude/commands/YAML frontmatter 是否合法命令出现但输出不对命令正文是否引用了过时规则参数是否有传递有的命令用不了文件名大小写是否和其他内置命令重名5.2 规则写了但 AI 不遵守问题多半在结构“CLAUDE.md 里明明写了禁止用 any为什么它还是生成了带 any 的代码”这是被问得最多的问题。先做一个最基础的排查在会话里问 AI“这个项目有什么禁止事项”。如果它连 CLAUDE.md 的存在都不知道说明配置没生效检查文件名和位置如果它能复述出来但执行时违反说明规则在指令层面的约束力不够。约束力不够通常有三种原因。第一规则被写得过于含蓄比如“尽量不用 any”模型会把这种话当作偏好而不是硬性规定改成“禁止出现 any除非在 .eslintrc 的 ignore 清单中显式豁免”效果会好得多。第二规则和其他指令互相冲突比如 CLAUDE.md 要求函数式风格但某个命令文件里又写了面向对象的示例模型在选择时会摇摆。第三上下文被撑爆了当会话很长、讨论内容很多时靠后位置的规则会被稀释。解决方案是把最核心的三条安全红线移到 CLAUDE.md 开头让它们在整个会话里占据更高的注意力权重。5.3 权限弹窗刷屏如何优雅地“放开”权限弹窗刷屏是模板推广期的第一大阻力。但处理它不能靠“干脆 allow 所有 bash 命令”这种偷懒方式那样等于把安全边界完全让渡给 AI。我的做法是分步骤放宽。先用一周时间收集数据每个弹窗出现的时候记录一下操作名、目标路径、你是否点了允许。一周之后做一次归类你会发现弹窗其实集中在少数几类操作上。比如 git 系列操作占了一半以上其中 git status 和 git dff 毫无风险可以加入 allow涉及网络请求的 npm install 虽然是常规操作但每次安装后进行依赖审查更稳妥所以继续保留 ask而 git push 这种影响远程仓库的操作必须 ask绝不 allow。按照这个逻辑去分批放宽既减少了弹窗频率又把高风险路径牢牢握在手里。5.4 配置漂移为什么两台机器上的行为不一样团队里同一套模板却出现了“你的 AI 会这么做我的 AI 会那么做”的情况这叫配置漂移。我遇到过一次很典型的业务仓库里的 .claude/settings.json 规定某个目录只能 Read但某位同事用户目录的 ~/.claude/settings.json 里配置了对该目录的高权限因为用户级配置没有被模板仓库管理他会话里的表现就和别人不一样。统一配置漂移的第一步是把项目相关的所有公共配置都放进模板仓库保证每个业务仓库从同一套源拉取。第二步把个人差异隔离在 .claude/settings.local.json 这类本地配置文件中并且一定要加入 .gitignore。任何涉及个人偏好的配置都不应该进入共享仓库否则团队内会出现互相覆盖的场面。第三步在做配置变更时通过模板仓库的 PR 和 tag 机制来发布每台机器拉取新 tag 后行为才更新到同一版本。6. 模板的长期维护与团队落地经验6.1 命令库要保持“瘦”而不是越堆越多模板跑起来之后最容易被忽略的就是维护。我的话来说命令库是有“熵增”趋势的三个月不管它就会堆积出一批“当时觉得有用、后来再也没用过”的命令。命令数量过多还有一个隐藏问题AI 在收到斜杠命令时也会加载命令文件本身多了之后上下文被无关内容占据响应质量反而下降。我自己的维护节奏是每两周花半小时做一次命令审计用一张简单的表格统计每条命令被真实调用的次数三个月内没有被调用的命令要么删掉要么合并进别的命令。除非某条命令是被你计划中马上要做的某个项目使用否则舍不得删就等于给自己埋坑。CLAUDE.md 也同理如果发现某条规则项目里已经不存在了比如某个目录已经重构掉了坚决删掉不要留着一堆过期信息等 AI 踩坑。6.2 让模板跟着项目架构一起演进模板不是静态文档它和业务代码处于同一生命周期。项目发生重大架构调整的时候比如从单体拆出微服务、引入新的状态管理方案、数据库换库模板里的 CLAUDE.md 和命令都必须同步改。不然就会出现一种尴尬局面AI 根据过时的模板给出非常自信但完全错误的建议比不配置还危险因为它看起来言之凿凿。我建议在项目里加一条隐性流程架构变更的 PR 里必须同步修改模板仓库的对应文件。这一步可以在 Code Review 的 check list 里体现。虽然这种要求没有硬性机制强制但一旦你吃过几次“AI 按过期架构回答”的亏就会自觉把它当成必须项了。6.3 用模板把代码审查标准固化进日常工作最后分享一个把模板真正融入工作流的小经验把代码审查命令和你们团队的 Code Review 标准绑定。很多团队的 Code Review 标准其实只存在于部分老员工脑子里新同学根本不知道怎么审。我把团队 review 时最常提出的几类问题写进 review.mdAI 就成了一个不会遗漏要点的初筛机器人把基础问题先找出来人工审查则聚焦在架构层面和设计取舍上。这样模板就不再只是“生成代码的助手”而成了团队质量基建的一部分。实际上用到这里claude-code-templates 就已经超出了“省时间”的范畴它更像是把团队隐性知识显性化、标准化的一套流程。维护它的过程也是团队对“我们希望 AI 以什么方式工作”达成共识的过程。我现在的维护习惯还是每周打开模板仓库看一眼删掉过时命令补充新踩的坑这个习惯让所有队友的 AI 行为始终收在同一套框架内。值得坚持。