1. 从“六边形战士”到“一条边”到底在说什么

“六边形战士”这个词最早来自体育圈，指的是一个运动员在力量、速度、技巧、防守、经验、心理六个维度上都没有短板，雷达图画出来是一个饱满的六边形。后来这个词被泛化到职场和技术圈，用来形容那种什么都会一点、什么都能扛的“超级个体”——既能写前端，又能调后端，还能做运维、写文档、带新人。听起来很美好，但真正做过的人都知道，这种状态有个致命问题：每个维度都只是“够用”，没有一个维度能真正拉开差距。

而“一条边”是另一个极端。它指的是一个人只在一个方向上做到极致的深度，其他维度全部外包或者自动化掉，雷达图上看起来就像一条被拉到极限的边，其他方向几乎缩成了一个点。这个转变的核心驱动力，就是自动化生产工具链的成熟，尤其是以 Codex 类代码生成模型为代表的自动化生产能力。

我接触这套东西大概是在两年前，当时还在用传统的“手写+复制粘贴+搜索引擎”三件套干活。后来逐步把日常的重复性编码、脚手架搭建、测试用例生成、文档初稿这些环节交给自动化流程处理，整个人的工作模式发生了根本性的变化。这篇文章就是把这套实战经验完整拆开，讲清楚自动化生产到底怎么用、用在哪些环节、踩过哪些坑、最后怎么把能力边界重新画一遍。

适合谁来读？如果你是一个独立开发者、小团队的技术负责人、或者任何需要一个人扛多条业务线的“超级个体”，这篇内容应该能帮你省下不少试错时间。如果你只是对自动化生产好奇，想看看别人怎么落地的，也能从中拿到一些可以直接抄的配置和思路。

2. 为什么“六边形”模式在自动化时代反而成了负担

2.1 六边形战士的隐性成本

很多人羡慕“什么都会”的状态，但我在实际项目里发现，维持六边形的代价极高。每多一个维度，就意味着多一套工具链要维护、多一套知识体系要更新、多一批边界情况要处理。举个很具体的例子：我以前同时负责一个项目的前端页面、后端接口、数据库迁移脚本和部署配置。表面上看是“全栈”，实际上每天的时间被切成了碎片——上午调 CSS 兼容性，下午改 SQL 索引，晚上还要处理部署脚本的路径问题。每个环节都只做到 70 分的水平，因为根本没有足够的时间把任何一个环节推到 90 分以上。

更麻烦的是上下文切换成本。心理学上有个概念叫“注意力残留”，说的是当你从任务 A 切换到任务 B 时，大脑里还有一部分资源在想着任务 A。我实测下来，前端和后端之间来回切换，每次至少损失 15 到 20 分钟的深度工作时间。一天切换五六次，基本上两个小时就没了。这两个小时如果集中在一个方向上，足够把一个复杂模块从设计到测试全部走完。

2.2 自动化生产改变了什么

自动化生产工具的核心价值，不是“帮你写代码”这么简单，而是把那些 70 分水平的重复劳动接管掉，让你把精力集中在真正需要 90 分以上深度的环节。我自己的体感是，以前写一个标准的 CRUD 接口，从建表、写实体类、写 DAO、写 Service、写 Controller、写单元测试，大概需要两到三个小时。现在通过自动化流程，这部分时间压缩到了 20 分钟以内，而且生成的代码质量比我手写的更规范，因为模板是固定的，不会因为今天状态不好就漏掉参数校验。

这里的关键认知转变是：六边形战士的“六条边”里，至少有四条是可以被自动化接管或者大幅简化的。真正需要你亲自下场、投入深度思考的，可能只有一条边——也就是你真正的核心竞争力所在。其他边不是不重要，而是不需要你从零开始手搓。

2.3 从“全能”到“一专多能自动化”的思维转换

我刚开始用自动化工具的时候，心里其实是有抵触的。总觉得“自己写的才放心”，或者“生成的东西万一有问题怎么办”。后来强迫自己做了个实验：连续两周，所有重复性代码一律走自动化流程，只在关键逻辑和边界处理上手动介入。结果发现，bug 率反而下降了。原因很简单，自动化流程的模板是经过反复验证的，而人手写的时候会因为疲劳、分心、赶进度而跳过一些检查步骤。

这个实验之后，我彻底转变了思路。现在的模式是：一条边做到极致深度，其他边通过自动化流程维持 80 分以上的水准。这条“极致深度”的边，对我来说是系统架构设计和复杂业务逻辑的抽象能力。其他比如前端页面、数据库优化、部署脚本、文档撰写，全部走自动化或者半自动化流程。这样一来，我的时间分配从“六个方向各 15%”变成了“一个方向 60%，其他五个方向各 8%”。产出质量不降反升，因为那 60% 的深度投入带来的价值，远远超过六个 15% 的浅层覆盖。

3. 自动化生产实战的核心环节拆解

3.1 哪些环节适合交给自动化

不是所有环节都适合自动化。我踩过的最大坑，就是一开始想把所有东西都自动化，结果花在配置自动化流程上的时间比手动做还多。后来总结了一个判断标准：高频、重复、模式固定、容错率高的环节，优先自动化；低频、一次性、需要创造性判断、容错率低的环节，保持手动。

具体来说，我目前自动化覆盖的环节包括：

这张表里的时间节省是保守估计，实际用下来，一个中等规模的项目从零到可运行状态，以前需要三到五天，现在一天之内就能搞定。省下来的时间全部投入到核心业务逻辑的设计和优化上。

3.2 自动化流程的搭建原则

搭建自动化流程有几个原则，是我踩了很多坑之后才想明白的。

第一，模板要版本化。我一开始把模板直接写在脚本里，后来改了一次模板，发现之前生成的项目全部对不上，回滚都回不去。后来把模板单独抽出来，用 Git 管理，每次生成项目时锁定模板版本，问题就解决了。

第二，生成结果要可追溯。自动化生成的东西，必须能追溯到是哪个模板、哪组参数、哪个版本生成的。我在每个生成的文件头部加了一行注释，记录生成时间和模板版本。后来排查问题时，这行注释救了我好几次。

第三，留出手动覆盖的入口。自动化生成的文件，如果后续需要手动修改，必须有一个机制保证下次重新生成时不会覆盖掉手动修改。我的做法是，生成的文件分为“自动区”和“手动区”，自动区每次重新生成时覆盖，手动区只在文件不存在时创建。

第四，先跑通再优化。不要一开始就追求完美的自动化流程。我最初花了两周时间设计一个“完美”的代码生成框架，结果发现实际项目里根本用不上那么复杂的配置。后来改成先用最笨的脚本跑通，再逐步抽象和优化，效率反而高得多。

3.3 核心工具链的选型逻辑

工具选型这块，我的原则是够用就好，不追新。市面上自动化生产的工具很多，但真正能在日常项目里稳定跑起来的，其实就那么几类。

代码生成方面，我用的是基于模板的生成器加上模型辅助生成。模板生成器负责那些结构固定的部分，比如实体类、DAO、基础 Service；模型辅助生成负责那些需要一定理解能力的部分，比如根据业务描述生成测试用例、根据接口定义生成文档初稿。

流程编排方面，我用的是简单的脚本加上任务队列。没有上那些重量级的编排框架，因为我的场景里大部分任务是线性的，不需要复杂的依赖管理。一个 Bash 脚本加上几个 Python 小工具，就能覆盖 90% 的场景。

质量校验方面，我用的是静态检查工具加上自动化测试。生成出来的代码，先过一遍 lint，再跑一遍单元测试，有问题就拦截。这一步非常重要，因为自动化生成的东西如果不校验，很容易出现“看起来能跑但实际有坑”的情况。

提示：工具选型不要追求“一步到位”。我见过太多人花大量时间对比各种工具，最后项目都没开始做。先用最熟悉的工具跑通流程，遇到瓶颈再换，这才是务实的做法。

4. 从零搭建一条自动化生产线的完整过程

4.1 第一步：梳理你的重复劳动清单

在动手搭建之前，先花半天时间，把你日常工作中所有重复性的操作列出来。注意，是所有，不管多小的事情都记下来。我当时的清单大概有三十多项，包括“新建项目时创建目录结构”、“写实体类时重复的 getter/setter”、“每次部署前手动改配置文件里的版本号”等等。

列完之后，给每一项打两个分：频率（每天/每周/每月做几次）和耗时（每次花多少分钟）。然后算一个总分：频率乘以耗时。总分最高的那几项，就是最值得优先自动化的。

我当时的清单里，排名第一的是“根据数据库表结构生成后端代码”，每周大概要做三到四次，每次两小时左右。排名第二的是“写单元测试”，每周两次，每次一个半小时。这两项加起来，每周就能省出将近十个小时。

4.2 第二步：设计最小可行自动化流程

不要一上来就搞大而全的流程。先选一个最简单的环节，用最笨的方式自动化掉，跑通再说。我选的第一个环节是“根据表结构生成实体类”。做法很简单：写一个 Python 脚本，读取数据库的 schema，然后用字符串拼接的方式生成 Java 实体类文件。

这个脚本大概只有一百多行，花了我一个下午写完。但就是这一百多行，把我每周重复劳动里最烦人的一部分干掉了。更重要的是，跑通这个流程之后，我对“自动化到底能做什么”有了具体的体感，后面再扩展其他环节就顺理成章了。

4.3 第三步：逐步扩展和串联

第一个环节跑通之后，我开始把相邻的环节也自动化掉。实体类生成之后，紧接着是 DAO 层和 Service 层的生成。这两层的模板和实体类高度相关，所以复用之前的脚本框架，很快就能扩展出来。

再往后，我把测试用例生成也接了进来。做法是：先根据接口定义生成测试方法的骨架，然后由模型辅助填充具体的测试数据。这一步需要人工审核，因为模型生成的测试数据有时候不符合业务语义，但骨架部分完全自动化，省掉了大量重复的样板代码。

串联的方式很简单：一个主脚本按顺序调用各个子脚本，每个子脚本的输出作为下一个子脚本的输入。中间加一些校验步骤，比如生成完实体类之后，先跑一遍编译，编译不过就中断流程并报错。

4.4 第四步：建立反馈和迭代机制

自动化流程不是搭完就完事了，需要持续迭代。我的做法是，每次手动修改了自动化生成的文件，就回头看看能不能把这个修改反哺到模板里。比如有一次我发现生成的 Service 类里缺少了一个事务注解，手动加上之后，我就把模板更新了，下次生成就自动带上了。

这个反馈循环非常重要。我大概花了三个月时间，才把主要模板打磨到“生成即可用”的程度。前两个月基本上每周都要改模板，第三个月开始频率明显下降。现在大部分项目生成出来之后，只需要改不到 10% 的内容就能直接进入开发阶段。

注意：模板更新之后，一定要在测试项目上先验证一遍，确认没有引入新的问题，再应用到正式项目。我有一次改模板改出了个语法错误，结果连续三个项目生成出来都编译不过，排查了半天才发现是模板的问题。

5. 自动化生产中的常见坑与排查实录

5.1 生成结果不符合预期怎么办

这是最常见的问题。自动化生成的东西，有时候和你想的完全不一样。我的排查思路是分三步走：先看输入，再看模板，最后看生成逻辑。

输入问题最常见。比如数据库表结构里某个字段的类型和实际业务不符，生成出来的代码自然就不对。模板问题次之，通常是模板里的条件判断写错了，导致某些情况下走了错误的分支。生成逻辑问题最少见，但一旦出现就比较麻烦，需要仔细检查脚本里的字符串拼接和循环逻辑。

我遇到过一个很典型的案例：生成的实体类里，某个字段的 getter 方法名不对。排查了半天，发现是数据库字段名里有个下划线，而我的命名转换逻辑没有处理连续下划线的情况。修复方式很简单，在转换逻辑里加一个正则替换就行，但找到这个问题花了我将近一个小时。

5.2 自动化流程中断了怎么恢复

自动化流程跑一半中断，是另一个高频问题。原因可能有很多：网络超时、磁盘空间不足、某个依赖服务挂了、脚本本身有 bug。我的处理原则是：流程要幂等，中断后能重跑。

具体做法是，每个步骤执行完之后，在临时目录里写一个标记文件。重跑的时候，先检查标记文件，已经完成的步骤直接跳过。这样即使中断了，重新执行也只会从断点继续，不会重复劳动。

另外，每个步骤的输出要保留，不要直接覆盖。我一般会保留最近三次的生成结果，万一新生成的有问题，可以快速回滚到之前的版本。

5.3 生成代码的质量如何保证

自动化生成最大的风险，是生成了一堆“看起来能跑但实际有隐患”的代码。我的质量保证体系分三层：

第一层是静态检查。生成完立刻跑 lint 和类型检查，有问题的直接拦截。这一层能拦住大部分语法和类型错误。

第二层是单元测试。生成完的代码自动跑一遍已有的单元测试，确保没有破坏现有功能。这一层能拦住逻辑错误和回归问题。

第三层是人工抽查。每次生成之后，我会随机抽几个文件看一眼，确认生成风格和质量符合预期。这一层主要是防止模板本身出了问题，导致生成结果整体偏离。

三层下来，基本上能保证生成代码的质量在可接受范围内。我统计过，自动化生成的代码在后续开发中需要返工的比例，大概在 5% 到 8% 之间，比我手写代码的返工率还低一些。

5.4 常见问题速查表

6. 能力边界重构之后的工作模式

6.1 时间分配的变化

自动化流程跑顺之后，我的时间分配发生了根本性的变化。以前是“六个方向平均用力”，现在是“一个方向深度投入，其他方向自动化维持”。具体来说，以前每天大概有 60% 的时间花在重复性编码上，20% 花在调试和排查上，只有 20% 花在真正的设计和思考上。现在重复性编码的时间压缩到了 15% 以内，调试时间也降到了 10% 左右，剩下的 75% 全部投入到架构设计、业务抽象、性能优化这些高价值环节。

这个变化带来的直接结果是，我能在同样的时间内，把核心模块的质量做得更深。以前一个项目做完，核心逻辑大概只能做到“能用”的水平，现在能做到“好用”甚至“优雅”的水平。因为时间充裕了，可以反复推敲设计，可以写更完善的测试，可以做更多的边界情况处理。

6.2 核心竞争力的聚焦

自动化接管了那些“70 分就够”的环节之后，我被迫思考一个问题：我真正不可替代的能力是什么？这个问题以前被“什么都会”的表象掩盖了，现在被自动化逼出来了。

我的答案是：复杂业务逻辑的抽象能力和系统架构的设计能力。这两项能力的特点是，它们需要大量的上下文理解和创造性判断，自动化工具目前还很难替代。比如，把一个模糊的业务需求转化成清晰的数据模型和接口定义，这中间需要大量的权衡和取舍，自动化工具只能辅助，不能替代。

聚焦到这一条边上之后，我反而觉得轻松了。以前总担心“这个不会那个不会”，现在想明白了：不会的那些，交给自动化流程就行，我只需要保证核心能力持续精进。

6.3 与自动化流程的协作方式

现在的协作方式是：我负责定义“做什么”和“为什么这么做”，自动化流程负责“怎么做”。具体来说，我先把业务需求拆解成清晰的输入（比如数据库表结构、接口定义、业务规则），然后自动化流程根据这些输入生成代码骨架和基础实现，最后我在骨架上填充核心逻辑和边界处理。

这种协作方式的关键是输入的质量。如果输入定义得模糊，生成出来的东西就是垃圾。我花了很多时间在“如何把需求转化成自动化流程能理解的输入”这件事上。后来发现，最好的方式是用结构化的配置文件来描述需求，比如用 YAML 定义数据模型，用 JSON Schema 定义接口。这样既方便自动化流程解析，也方便人工审核。

6.4 对“超级个体”的重新定义

以前我觉得“超级个体”就是什么都会的人。现在我觉得，真正的超级个体是知道什么该自己做、什么该交给自动化的人。这个判断力本身，就是一种稀缺能力。

我见过一些同行，技术能力很强，但什么都想自己动手，结果项目进度永远卡在细节上。也见过一些同行，过度依赖自动化，生成出来的东西看都不看就上线，结果出了事故。这两种极端都不可取。真正的高手，是在自动化和手动之间找到那个平衡点，让自动化处理 80% 的常规工作，自己专注于 20% 的关键决策。

这个平衡点因人而异，因项目而异。我的经验是，先跑起来，再调整。不要一开始就追求完美平衡，先让自动化流程跑起来，然后在实际使用中逐步调整边界。跑上三个月，你自然就知道哪些环节该自动化、哪些环节该手动。

7. 几个可以直接抄的实操配置

7.1 项目脚手架生成脚本

这是一个最基础的脚手架生成脚本，用 Bash 写的，依赖很少，基本上任何环境都能跑。它的作用是：根据项目名称和类型，创建标准的目录结构，复制对应的模板文件，并替换其中的占位符。

#!/bin/bash # scaffold.sh - 项目脚手架生成脚本 # 用法: ./scaffold.sh <项目名> <项目类型> PROJECT_NAME=$1 PROJECT_TYPE=$2 TEMPLATE_DIR="./templates/${PROJECT_TYPE}" TARGET_DIR="./projects/${PROJECT_NAME}" if [ ! -d "$TEMPLATE_DIR" ]; then echo "错误: 找不到模板目录 $TEMPLATE_DIR" exit 1 fi if [ -d "$TARGET_DIR" ]; then echo "错误: 目标目录 $TARGET_DIR 已存在" exit 1 fi # 复制模板 cp -r "$TEMPLATE_DIR" "$TARGET_DIR" # 替换占位符 find "$TARGET_DIR" -type f -name "*.java" -o -name "*.xml" -o -name "*.yml" | while read file; do sed -i "s/{{PROJECT_NAME}}/${PROJECT_NAME}/g" "$file" done echo "项目 $PROJECT_NAME 创建成功，路径: $TARGET_DIR"

这个脚本的核心逻辑很简单：复制模板，替换占位符。但就是这么一个简单的脚本，把我每次新建项目的时间从半小时压缩到了十秒钟。模板目录里放的是我反复打磨过的标准结构，包括目录布局、基础配置文件、常用的工具类等等。

7.2 数据模型到代码的生成配置

这是一个用 YAML 描述数据模型的示例，以及对应的生成配置。YAML 的好处是结构清晰，人和机器都能读。

# models/user.yaml table_name: user comment: 用户表 columns: - name: id type: bigint primary_key: true auto_increment: true comment: 主键 - name: username type: varchar(64) nullable: false comment: 用户名 - name: email type: varchar(128) nullable: false comment: 邮箱 - name: created_at type: datetime nullable: false default: CURRENT_TIMESTAMP comment: 创建时间

对应的生成配置：

# generator-config.yaml templates: entity: ./templates/entity.java.tpl dao: ./templates/dao.java.tpl service: ./templates/service.java.tpl controller: ./templates/controller.java.tpl test: ./templates/test.java.tpl output: base_dir: ./src/main/java package: com.example.project entity_dir: entity dao_dir: dao service_dir: service controller_dir: controller test_dir: ./src/test/java options: use_lombok: true use_swagger: true generate_tests: true

这个配置的好处是，生成逻辑和模板分离，改模板不影响生成逻辑，改生成逻辑不影响模板。我后来把生成器换了好几个版本，但模板一直没怎么动，因为模板里沉淀的是我对代码风格的理解，这部分是相对稳定的。

7.3 自动化流程的幂等标记实现

这是一个简单的幂等标记实现，用 Python 写的。核心思路是：每个步骤执行前检查标记文件，执行后写入标记文件。

import os import json from datetime import datetime MARKER_DIR = "./.automation_markers" def is_step_done(step_name): """检查某个步骤是否已完成""" marker_file = os.path.join(MARKER_DIR, f"{step_name}.done") return os.path.exists(marker_file) def mark_step_done(step_name, metadata=None): """标记某个步骤已完成""" os.makedirs(MARKER_DIR, exist_ok=True) marker_file = os.path.join(MARKER_DIR, f"{step_name}.done") data = { "step": step_name, "completed_at": datetime.now().isoformat(), "metadata": metadata or {} } with open(marker_file, "w") as f: json.dump(data, f, indent=2) def run_step(step_name, func): """执行一个步骤，自动处理幂等""" if is_step_done(step_name): print(f"步骤 {step_name} 已完成，跳过") return print(f"执行步骤 {step_name}...") result = func() mark_step_done(step_name, {"result": str(result)}) print(f"步骤 {step_name} 完成")

这个实现很简单，但非常实用。我把它用在了所有自动化流程里，中断后重跑再也不会重复劳动了。

7.4 生成代码的质量校验脚本

这是一个质量校验脚本的骨架，用 Python 写的。它会在生成代码之后自动运行，检查代码的基本质量。

import subprocess import sys def run_lint(file_path): """运行静态检查""" result = subprocess.run( ["lint-tool", file_path], capture_output=True, text=True ) return result.returncode == 0, result.stdout def run_tests(test_dir): """运行单元测试""" result = subprocess.run( ["test-runner", test_dir], capture_output=True, text=True ) return result.returncode == 0, result.stdout def validate_generated_code(generated_files, test_dir): """校验生成代码的质量""" errors = [] for file_path in generated_files: ok, output = run_lint(file_path) if not ok: errors.append(f"Lint 失败: {file_path}\n{output}") ok, output = run_tests(test_dir) if not ok: errors.append(f"测试失败:\n{output}") if errors: print("质量校验未通过:") for err in errors: print(err) sys.exit(1) print("质量校验通过")

这个脚本的核心价值在于，它把质量校验变成了自动化流程的一部分，不需要人工记得去跑。我把它接在了生成流程的最后一步，生成完自动校验，不通过就中断，避免有问题的代码流入后续环节。

8. 我在这套流程里踩过的几个真实坑

第一个坑是过度自动化。我一开始想把所有东西都自动化，包括那些一次性的、需要创造性判断的环节。结果花在配置自动化上的时间比手动做还多。后来想明白了，自动化只适用于高频重复的场景，低频创造性的场景手动做反而更快。

第二个坑是模板更新没有版本控制。我改了一次模板，结果之前生成的项目全部对不上，回滚都回不去。后来把模板纳入 Git 管理，每次生成时锁定版本，问题就解决了。

第三个坑是生成结果没有校验。有一次模板里有个小错误，生成出来的代码编译不过，但我没注意，直接提交了，结果 CI 挂了半天才发现。后来加了自动校验步骤，生成完立刻跑 lint 和测试，有问题当场拦截。

第四个坑是幂等没做好。流程中断后重跑，前面的步骤又执行了一遍，浪费了大量时间。后来加了标记文件，重跑时自动跳过已完成的步骤，效率高了很多。

第五个坑是输入质量太差。我一开始用自然语言描述需求，让自动化流程去解析，结果生成出来的东西完全不对。后来改成用结构化的 YAML 和 JSON Schema 描述需求，生成质量立刻上了一个台阶。

这些坑的共同点是：都是因为想走捷径而踩的。自动化本身不复杂，复杂的是如何把自动化和实际工作流结合起来。我的经验是，先跑通最简单的流程，然后在实际使用中逐步优化，不要一开始就追求完美。

9. 后续还可以怎么扩展

这套流程目前覆盖了我日常工作的 70% 左右，还有几个方向可以继续扩展。

第一个方向是更智能的测试数据生成。目前测试数据还是半自动的，需要人工审核。后续可以引入更精细的规则引擎，根据业务语义自动生成符合逻辑的测试数据。

第二个方向是自动化性能分析。生成代码之后，自动跑一遍性能基准测试，如果发现性能退化就告警。这个方向目前还在探索阶段，主要是性能基准的建立比较麻烦。

第三个方向是跨项目的模板共享。目前模板是每个项目独立的，后续可以抽出来做成共享库，不同项目之间复用。这样新项目启动时，可以直接继承之前积累的最佳实践。

第四个方向是与 CI/CD 流程的深度集成。目前自动化生成是在本地跑的，后续可以集成到 CI 流程里，每次提交代码时自动检查生成结果是否与模板一致，不一致就告警。

这些扩展方向不是必须的，取决于你的实际需求。我的建议是，先把核心流程跑顺，再考虑扩展。不要为了扩展而扩展，每个扩展都应该解决一个具体的痛点。

提示：自动化流程的维护成本会随着复杂度上升而增加。我目前的经验是，流程的复杂度控制在“一个人能维护”的范围内最合适。超过这个范围，就需要考虑拆分或者引入更专业的工具了。

10. 最后分享几个小技巧

第一个技巧：给生成的文件加头部注释。我在每个生成的文件头部加了一行注释，记录生成时间、模板版本和输入来源。后来排查问题时，这行注释帮我省了大量时间。

第二个技巧：保留最近三次的生成结果。不要直接覆盖，保留最近三次，万一新生成的有问题，可以快速回滚。

第三个技巧：定期回顾自动化流程的日志。我每周会花十分钟看一眼自动化流程的运行日志，看看有没有异常中断、有没有性能退化。这个习惯帮我提前发现了好几个潜在问题。

第四个技巧：把常用的生成命令做成快捷方式。我在 shell 里配了几个 alias，比如gen-entity、gen-service，敲一个命令就能生成对应的代码。省去了每次输入完整命令的麻烦。

第五个技巧：不要追求 100% 自动化。80% 的自动化加上 20% 的人工审核，比 100% 自动化但没人审核要靠谱得多。自动化是工具，不是目的。最终的目标是让你有更多时间做真正有价值的事情，而不是让你变成一个自动化流程的维护工。