企业官网建设流程全解析

写代码这么多年，我一直对“工具链整合”这件事有种执念。项目一多，仓库一杂，最难受的不是业务逻辑本身，而是每次新起一个项目都要把格式化、lint、提交校验、目录规范、接口联调这些基础设施重新搭一遍，搭完还得跟团队成员解释“为什么这么配”。前阵子我在内部梳理了一套代号为 t3code 的轻量级工程方案，核心就三件事：规范先行、模板固化、流程自动化，目的很简单——让团队的每个新项目从 clone 下来到能顺畅提测，压到 30 分钟以内。

t3code 不是某个框架，也不是什么新语言，它更像是一组经过验证的“工程约定”打包方案。文章里我会把这套东西的思路、关键细节、落地过程，以及我们踩过的坑全部拆开讲。如果你也在维护多个前端/Node.js 项目，或者正被“项目初始化三小时、代码风格吵一天”的问题折磨，这篇内容应该能给你一些可复用的参考。

1. 整体设计与思路拆解：为什么需要一套“工程约定包”

1.1 先搞清楚 t3code 到底解决什么问题

不少团队会把精力放在选框架上：React 还是 Vue、NestJS 还是 Koa、用 TypeScript 还是 JavaScript。但实际协作下来你会发现，真正拖慢效率的往往不是框架选型，而是“同一个仓库里每个人写出来的代码长得完全不像同一个项目”。有人用分号有人不用，有人组件用函数声明有人用箭头函数，有人把接口请求散落在页面里，有人统一收口在 services 目录。

t3code 这名字里 t3 取的是“三层隧道”的意思——底层是编码规范，中间层是项目模板，上层是自动化校验与发布流程。整套方案不绑定具体业务框架，但把绝大多数团队都需要的“公共地基”固化下来。它解决了三个最痛的问题：

• 新项目初始化成本高：每次都要手动配置 ESLint、Prettier、Husky、Commitlint、别名路径、环境变量样例，一遍遍重复劳动。
• 代码风格不统一：人和人之间的习惯差异远比想象中大，没有人愿意花时间在 review 里争论“这里该不该加分号”。
• 流程纪律形同虚设：很多仓库配了 lint-staged，但开发者可以通过--no-verify跳过校验，或者根本不在本地跑测试就 push，CI 挂了才追悔莫及。

1.2 方案选型的取舍：为什么不用现成的 All-in-One CLI

市面上其实已经有像 Create React App、Vue CLI、Nx 这类工具，甚至还有不少团队成员自己攒的脚手架脚本。我之所以没有直接拿来用，而是整理出 t3code 这套体系，主要基于三方面考虑：

第一，CAF（Create App Framework）这类工具的抽象层次太高。它们确实开箱即用，但一旦你需要在生成的项目里做深度定制——比如改 Webpack 配置、接入非标准目录结构、定制多环境部署脚本——就非常难受。要么得eject，要么得写一堆 patch 脚本维护生成物。t3code 的做法是“模板 + 变量注入”，模板本身不隐藏任何构建细节，生成出来的代码就是你能看懂、能改的普通工程。

第二，团队协作需要的是约定，不只是命令。脚手架只能帮你生成代码，但解决不了“为什么目录要这么分”“为什么接口层必须这么写”的问题。t3code 在模板之外配套了一份精简版约定文档，把关键约束写成人话，放在 README 开头。新人进来不用猜，直接照着模板写就能融入节奏。

第三，做技术选型要防“债务外包”。直接依赖重量级 CLI，意味着以后框架升级、配置变更，你都得跟着它的节奏走。t3code 的核心依赖只有五个左右：TypeScript、ESLint、Prettier、Husky、lint-staged，都是领域事实标准，路径依赖很弱，哪天不想用了拆掉也很容易。

1.3 方案的整体架构：三个层次各司其职

拿我们一个典型的中后台前端项目来举例，t3code 的组成大致是这样的：

这套结构有一个隐含的设计原则：规范层要足够严，模板层要足够薄，流程层要足够硬。规范严，代码才统一；模板薄，生成物才不臃肿、不绑架你；流程硬，规则才会被执行而不是沦为摆设。下面每一个环节我都会展开讲清楚。

2. 核心细节解析与实操要点：规范与模板里的门道

2.1 ESLint 规则集：把“风格之争”消灭在提交之前

ESLint 规则集是整个 t3code 里最琐碎、但收益最立竿见影的部分。我们没有自己发明规则，而是站在巨人的肩膀上做减法。基础配置采用eslint-config-airbnb-base作为蓝本，再去掉其中与 Prettier 冲突的格式类规则，最后叠加@typescript-eslint/recommended和eslint-plugin-import的路径校验。

这里有一个关键操作：必须先装eslint-config-prettier并把它放在 extends 数组的最后一位。它不会启用任何新规则，唯一的职责是关掉所有与 Prettier 重复或冲突的 ESLint 规则。很多新手踩坑就是漏了这一步，结果 ESLint 和 Prettier 在“缩进应该用几个空格”上互相打架，保存时自动格式化完，lint 依然报错。

实际配置中的几个核心规则，我当时是这样定的：

// .eslintrc.js 关键摘录 module.exports = { root: true, extends: [ 'airbnb-base', 'plugin:@typescript-eslint/recommended', 'prettier' // 必须放最后，关闭格式类冲突规则 ], rules: { // 允许显式标注返回值类型，大型项目里收益很高 '@typescript-eslint/explicit-function-return-type': 'off', // 强制 import 顺序：内置模块、第三方、内部模块、类型导入 'import/order': ['error', { 'newlines-between': 'always' }], // 禁止 any，如果某些场景必须用，要求显式写注释说明原因 '@typescript-eslint/no-explicit-any': ['error', { fixToUnknown: true }], // 组件/函数参数统一使用接口描述，避免隐式 any '@typescript-eslint/no-unused-vars': ['error', { argsIgnorePattern: '^_' }] } };

no-explicit-any这条规则我们内部吵过一轮。有人觉得业务代码里经常要接第三方不规范的接口返回，禁用 any 会徒增工作量。我的观点是：如果你遇到必须放开约束的场景，应该显式写一个类型别名，并在注释里说明数据来源，而不是随手一个 any 让类型检查形同虚设。这份坚持在后续重构时帮了大忙——我们有一个接口改了字段结构，得益于类型收敛，编译阶段就暴露了所有引用点，而不是上线后靠用户反馈才发现。

2.2 目录结构设计：约定优于配置的“公共骨架”

t3code 的模板层里有一套固定的目录骨架，React 和 Node.js 项目都能套用。顶层结构如下：

src/ ├── api/ # 接口请求层 ├── assets/ # 静态资源 ├── components/ # 通用组件 ├── config/ # 环境配置 ├── hooks/ # 自定义 Hook ├── pages/ # 页面级组件（路由对应） ├── services/ # 业务逻辑层 ├── styles/ # 全局样式 ├── types/ # TypeScript 类型声明 ├── utils/ # 工具函数 └── index.tsx # 应用入口

这个结构最大的特点就是“乱也乱得有限”。它遵循一条最关键的分层约定：页面组件里不允许直接 fetch 数据，必须经过 services 层。举个例子，一个用户列表页，你需要做的不是在那里写axios.get('/api/users')，而是去services/user.ts里定义一个fetchUserList函数，再由它调用api/request.ts里封装好的请求实例。这样一来，接口路径、请求参数、错误处理都集中在一处，后续接口变更只需要改一个文件。

目录约定里还有几个容易忽略的细节：

• pages/下的文件名默认与路由一一对应，省去路由表维护成本，但需要约定“动态路由参数拼文件后缀”，比如user/[id].tsx，团队熟读 Next.js 风格的话零学习成本。
• components/下按业务域建子目录，每个组件自带同名文件夹，内部放index.tsx、style.ts、types.ts，方便以后做代码分割或单元测试。
• utils/只放纯函数，禁止引入 React 和业务 API，保证可测试性。

这套骨架不是一次性拍脑袋定的，而是从我们维护的十来个老项目里抽象出来的“最大公约数”。它的价值在于：新人接手任何一个基于 t3code 的项目，都能在五分钟内找到要找的文件。

2.3 配置模板的三个“必填项”：环境变量、路径别名与构建输出

项目生成之后，有三个配置文件是我要求必须存在且不允许删改的。

第一个是.env.example。很多项目把环境变量直接写在代码里，或者只在本地口头传一份.env。t3code 要求所有环境变量必须先在.env.example里登记，写清楚注释、类型、示例值。新同事 clone 仓库后只需执行cp .env.example .env即可开始开发，也天然防止了把密钥误提交进仓库的问题。我们在.gitignore里显式加上了.env，但保留了.env.example。

第二个是路径别名。我们在模板的tsconfig.json和打包配置里都配好了@/指向src/，这样模块引用写的是@/services/user，而不是一长串../../../services/user。这里的坑在于：TypeScript 配置变了之后，打包器（Vite 或 Webpack）的 resolve.alias 也要同步改，否则编辑器不报错、构建却找不到模块。t3code 模板直接用同一个tsconfig的 paths 作为唯一事实来源，再在构建配置里读取，避免两个地方各写一份导致漂移。

第三个是构建产物目录。统一设为dist/，并在 CI 流程里固定下来。这个看起来不起眼，但部署脚本、Dockerfile、静态资源服务配置全都依赖这个约定。我们有个历史项目用过build/，后来另一个项目用dist/，运维同学每次都要问“这次部署目录是哪个”，非常低效。t3code 里统一下来，整个公司都受益。

3. 实操过程与核心环节实现：从零生成一个 t3code 项目

3.1 准备工作：本地环境与工具链安装

在真正跑模板之前，需要先把工具链准备好。这块我直接给一份经过验证的清单，照着装不会有版本冲突问题：

# Node.js 版本管理器，装 18 或 20 LTS # 建议装 nvm，方便切换多个项目 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash # 安装 Node.js 20 LTS nvm install 20 nvm alias default 20 # 全局安装 pnpm，t3code 模板默认使用 pnpm 作为包管理器 npm install -g pnpm@8 # 验证版本 node -v # v20.x.x pnpm -v # 8.x.x

这里为什么选 pnpm 而不是 npm 或 yarn？主要是磁盘占用和安装速度。我们团队十几个项目共用一套依赖，pnpm 的内容寻址存储让同样的依赖包只保留一份，实测磁盘占用减少了大约 60%，冷安装速度也有明显提升。更关键的是 pnpm 默认的“幽灵依赖”防护能逼着开发者显式声明每个依赖，避免那种“代码里明明用了 lodash 但 package.json 里没有”的经典事故。

3.2 初始化项目：clone 模板并安装依赖

t3code 的模板仓库是个普通 Git 仓库，初始化方式非常朴素：

# 拉取模板仓库，换成本团队自己的模板仓库地址即可 git clone git@github.com:your-org/t3code-template.git my-project cd my-project # 快速清理模板自带的 Git 历史，避免污染新项目 rm -rf .git git init # 安装依赖 pnpm install

对比很多脚手架用create-xxx-app交互式询问、下载模板、生成文件的流程，直接 clone 模板的优点第一是透明——你能在初始化前就完整看到模板的每个文件；第二是可控——团队内部可以像维护普通仓库一样迭代模板本身。用rm -rf .git && git init这步操作，相当于把模板仓库的提交历史剪掉，新项目从第一个 commit 开始就是自己的历史，操作简单且不会有奇怪的历史负担。

有同事问过为什么不用degit这类工具拉取模板，那里其实也能起到同样的作用。degit 会更优雅一些，它会忽略模板仓库的 Git 历史，只下载工作目录文件，你也就不用手动执行rm -rf .git了。不过手工方式同样完全可行，而且少引入一个工具依赖，对新人更友好。

完成之后，一次性把所有依赖锁文件也提交进仓库。这里有个原则：pnpm-lock.yaml必须提交，node_modules必须在.gitignore里。lockfile 保证全团队装的依赖版本完全一致，避免“我本地能跑，你那边报错”的经典推诿。

3.3 修改项目标识与个性化配置

全局搜索模板里预留的占位符t3code-app和@t3code/，把它们替换成你项目的实际名称和 npm scope。这里要特别小心 package.json 里的name字段，它会被 pnpm workspace、构建工具、以及一些运行时的代码分割逻辑引用，如果大小写或格式不规范（比如包含大写字母），发布 npm 包时会直接报错。npm 包名规范是小写字母、数字、连字符，这一点没有商量余地。

同样需要更新的是public/目录下的站点标题、favicon、manifest.json 里的元信息。这些不更新的话，页面 title 会一直是模板自带的 “t3code App”，看起来非常不专业。我在一份分享里专门列过这个清单，团队内部也把它叫“换皮五件套”：

• package.json 的 name/version/description/author
• .env.example 里的应用名和应用 ID
• public/index.html 里的<title>和 meta description
• src/config/app.ts 里的应用名称常量
• README.md 的项目简介与本地启动说明

这些步骤虽然琐碎，但一次性做对能让后续所有环境的识别都清晰。我见过有项目上线半年了，浏览器标签页还挂着隔壁项目的名字，多少有点尴尬。

3.4 启动与验证：检查 ESLint、构建、测试三条链路

依赖装好、配置改完，接下来验证整套链路是否通畅。我习惯按下面这个顺序跑一遍：

# 1. 类型检查 pnpm type-check # 2. 全量 lint（不要只看有没有错，还要看警告项） pnpm lint # 3. 构建生产包 pnpm build # 4. 跑一次测试（模板自带两个冒烟组件测试） pnpm test

如果四步全过，这个项目的工程基础就算是稳了。这里存在一个容易忽略的细节：很多模板的lint脚本只配置了eslint src，没有把配置文件自身纳入检查。这意味着.eslintrc.js、commitlint.config.js这些文件里的错误可能永远不会被发现。t3code 的 lint 命令有两种模式：lint:src检查业务代码，lint:config检查配置文件，CI 里两个都跑，双轨并行。

构建通过后，我第一次会认真看一遍dist/目录下的产物结构。重点确认三个点：入口 HTML 里引用的 JS/CSS 路径带上了哈希文件名、静态资源被正确拷贝、.env里的环境变量被正确注入（比如VITE_APP_API_BASE）。如果这里不对，后面部署到测试环境才发现就晚了，排查成本高得多。

3.5 初始化 Git 仓库并建立提交规范基线

在完成验证之后，我们再初始化 Git 仓库，这一步的顺序很有讲究。如果先git init再安装依赖和构建，中途产生的dist/、临时文件都可能被误加入版本控制；先全部配置好、清理干净，再 init，首次提交的代码就是干净、可复现的工程基线。这也是 t3code 流程里“初始化”步骤专门排在最后的考量之一。

git init git add -A git commit -m "feat: init project from t3code template"

t3code 配备了 Husky 钩子，在你执行 commit 时，会先触发pre-commit里的 lint-staged，只对暂存区的文件做 ESLint 和 Prettier 检查；接着commit-msg钩子会校验提交信息是否符合 Conventional Commits 规范（feat/ fix/ docs/ chore/等前缀）。这样做的好处是：lint 只处理你“即将提交”的代码，而不是整个仓库；提交信息规范则让后续的 changelog 自动生成、代码回溯都变得有迹可循。

这套机制真正厉害的地方在于，它不是靠“请自觉遵守”，而是把纪律写进了 Git 钩子流程。想要绕过当然也有办法（比如--no-verify），但从我们团队的经验看，当校验反馈足够迅速、报错信息足够明确时，大家是愿意遵守的，毕竟多敲几个规范前缀，比在流水线上被红灯拦下来要省心得多。

4. 常见问题与排查技巧实录：t3code 落地中的典型坑

4.1 问题一：本地 lint 全绿，CI 上却报错

这是团队里出现频率最高的问题，根源几乎永远是本地没装依赖或版本不一致。比如本地 node_modules 是两周前装的，ESLint 插件升过版本，规则行为变了，但 lockfile 没有更新。

排查思路很简单，按顺序来：

# 第一步：核对 lockfile 是否与当前分支同步 git status | grep pnpm-lock.yaml # 第二步：删掉 node_modules 重装，这一步能解决九成玄学问题 rm -rf node_modules && pnpm install # 第三步：确认本地 Node 版本与 CI 严格一致 node -v echo "查看 CI 配置文件中的 node-version 字段"

t3code 模板的 CI 配置里特意把 pnpm 版本和 Node 版本都固定住了。如果 CI 用的是pnpm/action-setup@v2且指定了 8.x，本地就不能偷偷用 9.x，否则装出来的依赖树不同，lint 行为就可能漂移。

4.2 问题二：提交了不符合规范的 commit message

有些人用的是 IDE 自带的 Git 面板，提交时弹窗极其简洁，没有显示 Husky 钩子的完整报错，很多人甚至没意识到有钩子存在。然后他们来找我说：怎么 commit 没反应？

这里要把期望摆正：Husky 钩子报错会中断提交，此时这个 commit 是“失败”的，没有真正写入历史。但钩子也会输出解决提示，最有用的信息通常包含“请使用git commit --amend重新提交”或“提交信息应以 feat/ fix 开头”之类的指引。我的建议是让终端窗口稍微留大一点，报错显示不全时别盲操作，先看提示再做下一步。

如果提交已经被推送到远程才发现格式不对，不要慌，分情况处理：

• 还没推远程：直接git commit --amend，改完再推即可。
• 已推远程且是个人分支：用git rebase -i修改对应 commit 的 message，再强推。注意是个人分支才建议强推，团队共享分支请不要这么干，容易把别人的提交搞乱。
• 已合入主干：别折腾历史了，这个提交信息就当作历史遗留问题。重点是从当前这个 commit 开始保持规范，没必要为了“修正”引发更大的协作风险。

4.3 问题三：lint-staged 只检查到了部分文件

lint-staged 的工作机制是“读取暂存区的文件列表，逐个匹配规则”，它本身不关心你在 git 里配置了什么text=auto换行符之类的东西。常见问题是你明明git add了十个文件，却只有三个走了 lint，原因多半是规则里的 glob 写得太窄，比如只匹配了src/**/*.{ts,tsx}，而修改的文件里恰好还有其他目录下的.js或.vue文件。

t3code 的 lint-staged 配置会覆盖主流的源文件类型：

// package.json 中的 lint-staged 配置 { "lint-staged": { "*.{ts,tsx,js,jsx}": ["eslint --fix", "prettier --write"], "*.{json,md,css,scss}": ["prettier --write"] } }

这里有两个经验值得注意。第一，--fix和--write都写上，ESLint 负责修代码质量问题，Prettier 负责统一格式，两者各司其职。第二，如果遇到“暂存区只有一部分文件触发”的困惑，可以手动跑一次npx lint-staged --debug，它会输出匹配逻辑的完整清单，问题一眼就能看出来。

4.4 问题四：环境变量跨端不一致，本地正常、线上白屏

这类问题通常不是 t3code 本身的缺陷，而是环境变量作用域约定不清。举个我们真实遇到的例子：模板里VITE_APP_API_BASE这个变量，在开发环境指向http://localhost:3000/api，生产环境指向线上网关，但有一台构建机的环境变量还残留着开发环境的值，构建时被 Vite 原样打进 bundle，上线后所有人请求都打到了 localhost。

排查这种问题，唯一有效的办法就是让构建产物的“来源”可追溯。t3code 的 CI 配置里有一个专门步骤：在构建成功后，把.env里参与构建的关键变量打印到构建日志中，变量值做脱敏处理后留档。这样一旦线上行为可疑，先对照构建日志确认用的是什么环境变量，而不是靠猜。另外，凡是用import.meta.env或process.env读取的变量，必须在.env.example里有注释说明“该变量是否会被打包进前端产物”——这点非常重要，很多人认不全 Vite 的 env 加载规则，导致密钥被误打包进公开 bundle。t3code 的做法是：带VITE_前缀的变量才可能被打包，其余变量只在构建和 Node 服务端可用，两条路径严格隔离。

4.5 问题五：模板本身升级了，存量项目怎么同步

这是所有模板方案都会遇到的经典难题。头一天你改了模板里的一个公共工具函数，第二天发现已经上线的那几个老项目还在用旧版本，bug 可能已经埋下了。模板维护者面临的永恒矛盾是：新项目要用新模板，老项目不能随便动。

t3code 的做法是“逐模块同步、单项升级”而不是“整体替换”。我们会把模板仓库里的公共模块拆得足够细，比如request.ts、logger.ts、storage.ts都是独立文件，老项目升级时按需拷贝对应文件即可。配合 semver 的版本标签，模板仓库每个 commit 都打 tag，需要升级的团队可以精确比对v1.2.0到v1.3.0之间的 diff，只挑与自己相关的部分合入。

这个思路后来演变成了一个很轻量的内部 CLI 工具，支持按文件路径同步模板内容，但由于维护成本考量，我们还是更推荐“以 copy 为主、以 merge 为辅”的朴素策略。模板不是强约束工具，它是知识沉淀的载体，别把自己绑死在自动同步上。

5. t3code 的扩展空间：向边缘场景与自动化推进

5.1 从 Web 走向全栈：Node.js 服务与 Monorepo 适配

t3code 最初的模板是针对前端中后台项目的，但很快我们发现，团队里同时有成批量的 Node.js 服务（BFF 层、定时任务、内部工具）需要治理。于是模板仓库里扩展了template-node-service分支，保留了核心的 lint/Prettier/commit 规范，但在目录结构上做了调整：

src/ ├── modules/ # 业务模块，每个模块自带 controller/service/dao ├── common/ # 通用中间件、异常处理、日志 ├── config/ # 环境配置读取与校验 ├── database/ # 数据库连接与迁移脚本 ├── app.ts # 应用入口 └── server.ts # HTTP 服务启动

模块化的好处在于，写一个新接口时你可以只关注自己的modules/目录，公共逻辑全部收敛到common/，基本不会出现一个 200 行路由文件里塞满所有业务逻辑的“大泥球”。另外，Node 服务模板里加入了进程守护与优雅退出样板，这在 Node.js 服务上线时几乎是标配，没有的话 pod 滚动更新时内存会无故堆积。

配合 pnpm workspace，t3code 进一步支持了 monorepo 形态。我们有一个后台项目同时管理了管理端、用户端和两个共享包，根目录的pnpm-workspace.yaml划分好 packages 之后，各子包仍各自包含 t3code 的规范配置，只是执行从根目录统一调度。这里要特别注意：如果子包有独立的.eslintrc.js，需要显式声明root: true，否则 ESLint 会向上层目录查找配置，出现极其隐蔽的“配置串扰”问题。

5.2 与我常用的其他工具链整合：AI 时代的新协作范式

要说 t3code 最近最让我兴奋的变化，来自于 AI 编码工具的整合。大模型写代码已经成为每个研发团队不得不面对的新常态。但很多人只看到了效率提升的一侧，没看到另一侧的隐患：AI 生成的代码通常风格稳定，但规则意识极差。它可能生成一个完全可行但不符合项目 lint 规则的组件，甚至把any用得到处都是。

我的做法是让 t3code 成为 AI 编码的“规则护栏”。具体操作是，在项目的AGENTS.md文件里，把项目的目录约定、命名规则、接口请求规范全部写清楚。这样带上下文的大模型自动读取这个文件后，生成的代码已经能自动对齐团队规范。再配上 lint-staged 的强校验，基本能做到“AI 随便写，规则兜底收。”

这个方案运行几个月下来，团队里 AI 生成代码的 lint 通过率从接手初期的不到一半，提升到了九成以上。关键不是模型变聪明了，而是你给模型的上下文足够清晰。如果你正在尝试 AI 辅助编码，建议立刻把团队的规范文档写入AGENTS.md，这比你在对话里反复叮嘱“请遵守项目规范”要有效得多。

5.3 从模板到文化：把工程规范变成团队共识

很多人以为推行一套工程规范最大的阻力来自技术选型，但我这几年的体会是，最大的阻力永远在“人”。有人觉得 lint 规则是束缚，有人觉得提交信息规范是形式主义，有人觉得强制类型标注浪费时间。这些观念如果不解决，任何工具方案都会被绕过。

t3code 在推行时有一个很“软”的做法：我们不是发一个通知让大家“必须遵守”，而是先在两个项目里试点跑了两周，把执行前后的数据摆出来——review 耗时下降了约 40%，CI 红率下降了约 60%，新人上手时间缩短了一半以上。数据摆在面前，大部分人的抵触情绪自然就消退了。剩下的少数执念，也通过“规则可以讨论，但得有替代方案”的方式逐个解决，最终形成共识。

我始终觉得，好的工程规范应该像一个经验丰富的老同事：平时不打扰你，但关键节点总是提醒一句，“这里可能有坑”。t3code 就是我用代码写的那个老同事。

6. 写在后面：给想复刻这套方案的人几点建议

如果你也想在自己的团队推行类似的工程约定，我给三个最实在的建议。

第一，永远从“当前最痛的三个问题”出发，不要追求一步到位。我们最开始只是解决 commit 信息乱，后来才逐步扩展出整套 t3code。你要是第一版就把 ESLint、Prettier、TypeScript、lint-staged、CI、monorepo 全铺上，团队大概率会炸。分阶段、小步快跑，让每个人看到变化带来的正向收益，比任何行政命令都管用。

第二，把模板和文档当成代码一样维护。谁用模板发现了一个问题，不是自己默默改一下就完事，而是要回到模板仓库里更新“修复”并打 tag。模板不是一次性的，它是持续演化的工程资产。配套的那份“约定文档”也要认真写，不要只有工具没有思想，否则换个同事依然会问“为什么这里要这么写”。

第三，尊重团队的“例外需求”。t3code 的定位是“公共约定”，不是“铁律”。某个模块确实需要特殊处理（比如外部 SDK 的 d.ts 不规范导致类型报错），别让规则成为阻碍，该加 ignore 注释就加，该做局部豁免就做。关键在于把豁免理由写清楚，不能悄悄跳过。规则是为效率服务的，不是为了制造审批流程。

说到底，t3code 这套东西不是魔法，它只是“把做过的事情沉淀下来，把重复的工作自动化，把该守的底线交给机器”。如果你手头也有一堆项目在各自为政，不妨试着从一次规范化的提交信息、一套标准化的 lint 配置开始，一步步搭建属于你自己的 t3code。