面试官问“你在项目中做过哪些工程化或规范建设”，应该怎样回答？
选一两件自己推动落地的事，按“当时的问题 → 做了什么、为什么这样做 → 怎样推广 → 结果”讲，比如统一代码规范与提交检查、CI 卡点、构建提速、组件库或脚手架。重点讲取舍和推广过程，用数字说明效果，不要只罗列用过的工具名。
本题是回答思路与示例，不对应某个官方规范。示例中的数字只用来演示怎样表达，讲自己的项目时请用真实数据。
简答
面试官问这个，想看的是你能不能发现团队层面的问题，并且推动大家一起改，而不只是自己写好代码。所以不要一口气报出“ESLint、Prettier、husky、CI、Monorepo”一串工具名，工具谁都会配，难的是为什么配、怎样让大家接受。
选一两件你主导或深度参与的事，按四步讲。先说当时的问题，最好有具体现象，比如“代码风格不统一，评审时一半评论在讲格式”“线上出过两次类型错误导致的白屏”。再说你做了什么、为什么这样做，讲出取舍。然后说怎样推广落地，比如先在一个项目试点、写迁移文档、给存量代码留过渡期。最后说结果，用数字或可见的变化说明。
适合讲的题材有：统一代码规范和提交前检查、CI 里加类型检查和测试作为合并卡点、构建或开发服务器提速、抽公共组件库或项目脚手架、建立发布和回滚流程、接入错误监控。
要注意，规范的价值在于能自动执行，并且大家愿意遵守。讲推广时可以说遇到的阻力和你的处理，这比只讲配置更能体现能力。也别把团队的成果全说成自己的，面试官追问细节时会露馅。
一个完整的示例
下面以“统一代码规范和合并检查”为例，演示四步怎样串起来：
问题：我们组有五六个人维护一个 React 后台项目，没有统一的代码规范。评审时很多评论在讨论缩进、引号这类格式问题，真正的逻辑问题反而容易漏。另外项目用 Vite 构建，Vite 只转译 TypeScript、不做类型检查，有一次类型错误被打包上线，导致一个页面白屏。
方案：我做了三件事。第一，加上 Prettier 统一格式，ESLint 只保留找 bug 的规则，不再用它管格式，避免两者冲突。第二，用 husky 加 lint-staged，在提交前只检查改动的文件，几秒就能跑完，大家不会嫌慢。第三，在 CI 里加上
tsc --noEmit类型检查和单元测试，开启分支保护，检查不通过就不能合并。推广：一次性格式化全部代码会和所有人正在开发的分支冲突，所以我选在一次版本发布后、大家分支最少的时候，单独提交一次全量格式化，提前在群里通知。ESLint 新规则先设成警告，跑了两周、清理完存量问题再改成错误。我还写了一页说明，讲怎样配置编辑器自动格式化。
结果：之后评审里关于格式的评论基本没有了，评审更关注逻辑。上线后半年没有再出现类型错误导致的白屏。这套配置后来做成了团队新项目的模板。
这个回答为什么有说服力？问题是具体的，方案里讲了取舍（为什么只检查改动的文件、为什么 ESLint 不管格式），推广过程讲了怎样减少对别人的影响，结果说的是可见的变化。工具本身怎样配合，见《ESLint、Prettier、husky 和 lint-staged 分别做什么？怎样配合？》。
还可以讲哪些事
构建提速是很好讲的题材，因为效果容易量化。比如“开发服务器冷启动从 1 分多钟降到十几秒”，可以讲你怎样定位慢在哪里、试过哪些办法。webpack 的优化手段见《webpack 构建慢、产物大，应该怎样优化？》，迁移构建工具的取舍见《Vite 和 webpack 有什么区别？项目里应该怎样选？》。
协作规范也可以讲。比如约定提交信息格式，Conventional Commits 规定用 feat:、fix: 这类前缀，feat 对应语义化版本的次版本号、fix 对应修订号，带 BREAKING CHANGE 的对应主版本号，所以可以据此自动生成变更日志和版本号。再比如用 GitHub 的 CODEOWNERS 文件给不同目录指定负责人，有人修改这些目录的合并请求会自动请负责人评审，配合分支保护可以要求负责人批准后才能合并。
抽组件库、写脚手架也是常见题材，要讲清楚为什么要抽、怎样决定哪些组件进公共库、怎样做版本管理和升级。
哪些说法会减分
只报工具名不讲原因，比如“我们用了 ESLint、Prettier、husky、commitlint”，面试官听不出你做了什么。
把规范说成一个人定下来、强制大家执行，没有沟通过程，会让面试官担心你的协作方式。
说不出效果，或者效果说得很虚，比如“大大提升了开发效率”。尽量换成具体的数字或现象。
常见追问
有同事不愿意遵守规范，你怎么处理？
先了解原因。很多时候是规范让他不方便，比如提交检查太慢、规则太严、编辑器没配好。能用工具解决的就用工具，比如让格式化在保存时自动完成，他就不用记规则了。规则本身有争议时，拿出来在团队里讨论，按多数意见定下来，写进文档，而不是靠我个人坚持。
这些规范会不会拖慢开发？
会有一点成本，所以要控制。提交前只检查改动的文件，几秒钟就跑完；耗时长的测试和构建放到 CI 里，不阻塞本地提交。和省下的评审时间、减少的线上问题比，这点成本是值得的。如果某项检查大家普遍觉得没用，就该拿掉。