1. 项目概述为什么把“写代码”这件事往后挪了一步“我把 AI Coding 的决策移到了写代码之前”——这句话刚在内部技术分享会上说出来就有同事笑着问“代码都不写了那还叫开发吗”其实恰恰相反这一步后撤反而让整个研发节奏更稳、返工更少、协作更顺。我干了十多年全栈开发从最早手写 jQuery JSP到后来 Spring Boot Vue 单页应用再到如今带团队做 AI 辅助研发流程设计踩过最多坑的地方从来不是语法错误而是需求没对齐、接口没共识、边界没定义清楚就急着敲回车。AI Coding 工具越强大这个问题就越危险一个能 3 秒生成 200 行 CRUD 代码的模型如果输入的是模糊的“用户能查订单”它可能生成出带硬编码状态码、漏掉分页参数、连时间格式都用new Date().toString()的“完美垃圾”。所以这个项目的核心不是“用 AI 写更多代码”而是把 AI 的能力锚定在“写代码之前”那个最脆弱、也最有价值的决策点上——也就是需求落地为可执行规格Spec的瞬间。我们不再让工程师对着 PRD 文档拍脑袋翻译成接口字段也不让前端在 mock 数据里猜后端会返回什么更不靠口头约定“这个字段后期加”。我们用一套轻量但闭环的 Spec-Driven 工作流把 AI 变成那个“先画图纸再盖楼”的协同建筑师。关键词里反复出现的OpenSpec就是我们选型落地的底层协议载体而所谓“前后端”在这里不是技术栈划分而是两个角色在同一个 Spec 上的并行施工队——后端负责把 Spec 编译成可运行服务前端负责把 Spec 渲染成可交互界面。你不需要懂 OpenSpec 官网怎么注册、也不用翻教程文档整套流程跑通后一个刚入职的 junior 前端打开 Figma 设计稿旁边自动生成的交互逻辑图就能直接拉取接口定义、生成类型声明、甚至跑通第一个表单提交后端同学在 IDE 里右键点击某个 OpenSpec 文件一键生成 Controller 模板和校验规则连 Swagger UI 都是实时同步的。这不是替代人的流程而是把人从重复解释、反复对齐、手动补漏中解放出来让真正的创造力集中在业务建模、异常路径设计、性能权衡这些机器还干不好的地方。下面我会带你从零还原这套工作流怎么搭、为什么这么搭、哪些环节必须人工把关、哪些地方 AI 能真正提效——不讲概念只说我们每天在用的命令、配置、截图和踩过的坑。2. 整体架构与设计思路Spec 不是文档是可执行契约2.1 为什么拒绝“AI 直接写代码”作为起点很多人一听说 AI Coding第一反应是装个 Copilot然后在 VS Code 里写注释让它补全。这当然有用但局限性极强它依赖已有上下文比如你已经写了PostMapping(/order)它才敢猜你要处理订单它无法跨文件理解语义你写了 DTO但没写 VO它不会主动帮你补转换逻辑它对“隐含约束”完全无感比如“用户只能查自己创建的订单”这种权限逻辑不会出现在接口路径里但必须体现在 Spec 中。我们做过对照实验同样一个“订单列表查询”需求两组人分别用传统方式和本项目流程实现。传统组平均花 4.2 小时完成前后端联调其中 2.7 小时耗在“字段名不一致”“分页参数传错位置”“空值处理方式不同”这类问题上而采用 Spec-First 流程的小组前期多花了 1.8 小时共同编写和评审 OpenSpec 文件但后续编码联调仅用 1.9 小时且一次通过率 100%。关键差异在于Spec 是唯一真相源Single Source of Truth所有代码、文档、测试、Mock 都从中派生而不是反过来靠人去维护一致性。提示Spec 不是 Word 文档或 Confluence 页面。它必须是结构化、可解析、可版本控制的文本文件YAML/JSON否则 AI 无法读取工具链无法自动化。2.2 OpenSpec 为什么成为我们的协议基石网络热词里频繁出现 “openspec 官网”“openspec 使用教程”但实际落地时我们根本没去官网下载 SDK 或看教程视频。原因很简单OpenSpec 本身只是一个开放协议规范类似 OpenAPI 之于 REST它不绑定任何具体实现。我们选择它的核心理由有三个极简语法工程师零学习成本OpenSpec 的 YAML 结构比 OpenAPI 3.0 更扁平。比如定义一个订单查询接口OpenAPI 需要嵌套paths→get→parameters→schema四层而 OpenSpec 直接写endpoint: GET /api/v1/orders summary: 查询用户订单列表 params: - name: page type: integer default: 1 description: 页码从1开始 - name: size type: integer default: 20 description: 每页数量 response: 200: items: id: string status: enum[pending, shipped, delivered] created_at: datetime我让实习生用 15 分钟就学会了写基础 Spec比教他看懂 Swagger 注解快得多。天然支持“业务语义”扩展OpenSpec 允许在任意节点添加x-*扩展字段。我们在response.items.status下加了x-permission: own表示该字段仅对订单创建者可见在params.page下加了x-validation: gt:0告诉代码生成器要加正整数校验。这些不是装饰而是会被下游工具链真实消费的元数据。与现有生态无缝衔接我们不用推翻现有技术栈。后端用 Spring Boot就写个OpenSpecProcessor类监听src/main/specs/目录下的 YAML 文件变化自动触发 Controller 生成前端用 Vue就配个 Vite 插件在vite.config.ts里加一行openSpecPlugin({ specDir: src/specs })它就会把 Spec 编译成 TypeScript 接口定义和组合式 API 函数。Tomcat 部署、Jenkins 构建、若依框架集成——全部不受影响Spec 只是新增了一个源文件目录。2.3 工作流全景图四个核心阶段如何咬合整套流程不是线性瀑布而是带反馈环的螺旋推进。我们把它拆成四个阶段每个阶段都有明确交付物、责任人和自动化卡点阶段触发条件主要动作输出物自动化卡点1. Spec 编写产品 PRD 定稿后产品经理 前后端 Tech Lead 共同编写 OpenSpec YAMLorders.spec.yaml等文件Git 提交时校验 YAML 格式、必填字段、枚举值合法性2. Spec 评审Spec 文件首次提交在 GitHub PR 中发起 frontend backend qa 评论AI 自动生成评审要点PR 评论区中的字段缺失提醒、权限冲突告警、历史相似接口对比GitHub Action 运行spec-linter标红高风险项3. Spec 派生PR 合并到 main 分支自动触发 Jenkins Pipeline生成后端 Controller/DTO、前端 Types/Api、Postman Collection、Swagger UI/src/main/java/com/example/order/OrderController.java/src/types/order.ts/postman/collection.json生成失败则 Pipeline 中断禁止合并4. Spec 验证每日构建后运行基于 Spec 生成的契约测试Contract Test验证实际接口响应是否符合 Spec 定义测试报告 HTML 失败用例截图若失败自动创建 Jira Bug 并关联 Spec 文件路径注意这里没有“AI Coding”按钮也没有“一键生成全栈项目”的噱头。AI 被封装在spec-linter和contract-tester这些后台服务里——它不露面但每一步都在确保 Spec 的严谨性。真正的决策权仍在人手里谁来写 Spec谁来确认x-permission的值谁来判断“订单状态枚举是否要加canceled”——这些必须由领域专家拍板AI 只负责把选择变成可执行、可验证、不可绕过的事实。3. 核心细节解析与实操要点从 Spec 到可运行服务的每一处关键3.1 Spec 编写如何让 AI 成为你的“需求翻译官”很多人以为 Spec 编写就是照抄 PRD这是最大误区。PRD 是给业务看的Spec 是给机器读的。我们总结出三条铁律第一永远用动词开头定义 endpoint❌ 错误示范/api/v1/orders?statuspending这只是 URL没说明行为✅ 正确写法endpoint: GET /api/v1/orderssummary: 查询当前用户待处理订单列表为什么因为 AI 工具需要明确 HTTP 方法和语义动词才能生成正确代码。我们用一个 Python 脚本做了统计团队里 73% 的接口命名混乱根源就是没强制要求summary必须是“动词宾语”结构。第二参数必须区分path/query/body且 body 必须结构化OpenSpec 默认把params当作 query 参数。如果你要传 JSON body必须显式声明endpoint: POST /api/v1/orders params: - name: order_data in: body # 显式声明 schema: customer_id: string items: - sku: string quantity: integer否则 AI 生成器会默认把order_data当作 query 字符串拼接导致后端收不到数据。这个细节我们踩过两次坑第一次是支付回调接口前端传了 JSON body后端 Controller 却用RequestParam去接结果全是 null第二次是搜索接口filters对象被当成字符串传进来后端还得手动JSON.parse()——这些本该在 Spec 阶段就锁死。第三枚举值必须穷举禁止用“等”“其他”模糊表述status: enum[pending, shipped, delivered]是合法的status: enum[pending, shipped, delivered, ...]是非法的spec-linter会直接报错。为什么因为前端生成的 TypeScript 类型是type OrderStatus pending | shipped | delivered如果留个“...”TypeScript 就无法做类型守卫type guardif (status canceled)这种判断会编译报错。我们曾因漏写canceled导致前端在取消订单后页面白屏排查了 3 小时才发现是 Spec 没更新。注意我们禁用了所有“自动生成 Spec”的 AI 功能。不是不能做而是太危险。曾经试过用大模型读 PRD 自动生成 OpenSpec结果它把“用户可按日期筛选”理解成date_range: string而实际需要的是start_date: date和end_date: date两个独立字段。AI 可以辅助补全、检查、翻译但绝不能代替人做业务建模。3.2 Spec 评审让 AI 当你的“资深 QA”传统评审会常陷入“这个字段要不要加”“那个状态码用 400 还是 404”的争论。现在我们把争议点前置到 Spec 层并用 AI 给出客观依据。我们自研了一个spec-reviewerCLI 工具它在 PR 提交时自动运行输出三类关键提示历史相似度分析输入当前 Spec 的endpoint和summary输出发现 3 个历史接口语义高度相似/api/v1/orders/history相似度 87%、/api/v1/users/orders相似度 72%、/api/v1/merchant/orders相似度 65%作用避免重复造轮子。有一次发现新写的“商家订单导出”接口和半年前的/api/v1/merchant/orders/export几乎一样只是改了个字段名立刻决定复用旧接口。权限冲突检测输入Spec 中所有x-permission字段 公司统一权限模型存于内部知识库输出警告response.items.created_at 的 x-permissionown 与权限模型中订单创建时间字段的全局策略all_read冲突请确认是否应限制为仅本人可见作用防止安全漏洞。这个功能帮我们拦截了两次越权风险一次是用户地址字段被设为x-permission: all但实际上地址属于敏感信息另一次是订单金额字段漏写x-permissionAI 默认标记为public而规则要求金额必须x-permission: own。契约兼容性检查输入当前 Spec 上一版已发布 Spec从 Nexus 仓库拉取输出BREAKING CHANGE删除了 response.items.tracking_number 字段前端 v2.3.0 版本依赖此字段请同步升级或提供兼容方案作用保障向后兼容。我们规定任何BREAKING CHANGE必须附带迁移方案如加临时字段、提供重定向接口否则 PR 不得合并。这些提示不是最终结论而是给评审人提供决策依据。我们要求每个 PR 必须有至少 1 条人工评论哪怕只是写“同意”也代表人已看过 AI 的建议并确认。3.3 Spec 派生后端如何从 YAML 生成可运行代码Spring Boot 项目中我们不修改任何原有代码结构只新增两个核心组件组件一OpenSpecProcessor核心生成器它是一个标准的 SpringComponent监听src/main/specs/目录。当检测到 YAML 文件变更自动执行解析 YAML 为 Java 对象用 Jackson 自定义 Deserializer根据endpoint方法生成 Controller 类名如GET /api/v1/orders→OrdersGetController根据params生成RequestParam或RequestBody参数对象根据response生成 DTO 类带 LombokData和Builder注入Autowired private OrderService orderService;并生成调用模板。生成的 Controller 示例RestController RequestMapping(/api/v1) public class OrdersGetController { Autowired private OrderService orderService; GetMapping(/orders) public ResponseEntityPageOrderDto getOrders( RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 20) Integer size) { // TODO: 实现业务逻辑AI 不生成此处 PageOrderDto result orderService.listOrders(page, size); return ResponseEntity.ok(result); } }注意AI 绝不生成业务逻辑TODO部分。它只生成胶水代码boilerplate确保结构正确、类型安全、校验完备。这是红线——一旦越界质量必然失控。组件二OpenSpecValidator运行时校验器它是一个Aspect切面在 Controller 方法执行后自动将返回值与 Spec 中定义的response结构比对字段名是否缺失字段类型是否匹配如created_at是string但返回了long时间戳枚举值是否在允许范围内是否存在 Spec 未定义的额外字段比对失败时自动记录 WARN 日志并返回500 Internal Server Error同时推送告警到企业微信。上线三个月共捕获 17 次“代码与 Spec 不一致”问题其中 12 次是开发者手动修改了 DTO 但忘了更新 Spec3 次是数据库字段变更未同步到接口。3.4 Spec 验证用契约测试守住最后一道防线契约测试Contract Testing不是新概念但结合 OpenSpec 后它变得极其轻量。我们不用 Pact 或 Spring Cloud Contract 那套复杂配置而是用一个 200 行的 Python 脚本contract-tester.py读取src/specs/orders.spec.yaml提取所有endpoint和params构造真实 HTTP 请求自动填充测试账号 token、mock 时间戳等发送请求获取实际响应逐字段比对状态码是否匹配response.200响应体是否为 JSONitems数组长度是否 ≥0每个item.id是否为非空字符串item.status是否在[pending,shipped,delivered]中关键创新点在于测试用例完全由 Spec 自动生成无需人工编写。以前写一个接口的契约测试要 30 分钟现在只要 3 秒——只要 Spec 写对测试就一定覆盖到位。我们把它集成进 Jenkins 的每日构建流程。某天凌晨 2 点contract-tester报告GET /api/v1/orders的response.200.items[].created_at字段返回了null而 Spec 要求必填。运维立刻收到告警登录服务器发现是数据库连接池耗尽导致部分订单创建时间未写入。问题在 5 分钟内定位10 分钟修复——如果没有这层自动验证这个null可能潜伏数周直到前端报“时间显示为 Invalid Date”。4. 实操过程与核心环节实现手把手搭建你的第一条流水线4.1 环境准备5 分钟初始化本地开发环境我们不推荐从零搭建而是提供一个开箱即用的脚手架仓库openspec-starter内部 GitLab 地址非 openspec 官网。克隆后只需三步# 1. 安装依赖Node.js 18Java 17Maven 3.9 npm install mvn clean compile # 2. 启动 Spec 监听服务自动扫描 src/specs/ npm run spec:watch # 3. 启动后端此时已自动生成 Controller mvn spring-boot:runnpm run spec:watch是关键命令它启动一个 Node.js 服务持续监听src/specs/目录。一旦你新建user.spec.yaml并保存它会立即生成src/main/java/com/example/user/UserGetController.java生成src/main/java/com/example/user/dto/UserDto.java重启 Spring Boot 应用通过 DevTools自动打开浏览器访问http://localhost:8080/swagger-ui.html看到新接口已就绪。实操心得不要在src/specs/里放空文件或.DS_Store。我们遇到过一次 CI 构建失败原因是 macOS 生成的隐藏文件被spec-linter当作无效 Spec 解析报错YAML parse error: expected a single document。解决方案是在.gitignore里加**/.DS_Store并在spec:watch脚本中过滤掉非.yaml文件。4.2 编写第一个 Spec订单列表接口实战我们以热搜词中高频出现的“前后端分离项目实战”为场景完整走一遍从 Spec 到联调的过程。Step 1创建src/specs/orders.spec.yaml严格遵循前文三条铁律endpoint: GET /api/v1/orders summary: 查询当前登录用户的所有订单含分页 params: - name: page in: query type: integer default: 1 description: 页码从1开始 x-validation: gt:0 - name: size in: query type: integer default: 20 description: 每页数量 x-validation: between:1,100 response: 200: type: object properties: total: integer data: type: array items: id: string order_no: string status: enum[pending, shipped, delivered, canceled] amount: number created_at: datetime updated_at: datetime x-permission: own # 整个响应体仅限本人查看Step 2提交 PR 并触发 AI 评审Git 提交后GitHub Action 自动运行spec-linter输出✅ VALID: YAML syntax OK ✅ VALID: All required fields present ⚠️ WARNING: enum value canceled not found in historical specs for status — please confirm with product team ✅ VALID: x-validation rules syntactically correct我们立刻在 PR 评论中 产品负责人确认是否要加canceled状态。得到回复“是”后更新 Spec 并重新提交。Step 3生成并实现业务逻辑spec:watch自动创建OrdersGetController.java我们只需在TODO处填写// TODO: 实现业务逻辑 PageOrderDto result orderService.listOrdersByUserId( SecurityContext.getUserId(), // 从 JWT 解析当前用户 PageRequest.of(page - 1, size) // 转换为 JPA 的 Pageable ); return ResponseEntity.ok(result);Step 4前端同步接入前端同学拉取最新代码后运行npm run spec:sync # 从 src/specs/ 生成 types/order.ts 和 api/order.ts生成的api/order.ts包含export const getOrders (params: { page?: number; size?: number }) axios.getApiResponse{ total: number; data: OrderItem[] }(/api/v1/orders, { params });他在 Vue 组件中直接调用script setup import { getOrders } from /api/order; const { data, execute } useAsyncState(getOrders({ page: 1 }), null); execute(); /script无需手动写interface OrderItem无需猜测amount是number还是string一切由 Spec 保证。4.3 Tomcat 部署与 Jenkins 集成如何在生产环境跑起来很多热词提到“tomcat部署前后端分离项目”“windows上用jenkins部署”说明大家关心落地可行性。我们的方案完全兼容Tomcat 部署后端Spring Boot 默认打包为jar但只需在pom.xml中改两行packagingwar/packaging !-- 移除 spring-boot-starter-tomcat -- exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion生成war包后直接丢进 Tomcatwebapps/目录启动即可。OpenSpec 生成的 Controller、DTO 全部正常工作因为它们只是普通 Java 类不依赖嵌入式容器。Jenkins Windows 构建在 Windows Jenkins Agent 上我们配置如下 Pipelinepipeline { agent { label windows } stages { stage(Checkout) { steps { checkout scm } } stage(Validate Spec) { steps { bat npm run spec:validate } // 运行 spec-linter } stage(Build Backend) { steps { bat mvn clean package -DskipTests } } stage(Generate Frontend Types) { steps { bat cd frontend npm run spec:sync } } stage(Deploy to Tomcat) { steps { bat copy target/*.war C:\\Program Files\\Apache Software Foundation\\Tomcat 9.0\\webapps\\ } } } }关键点spec:validate是门禁gate如果 Spec 有误Pipeline 直接失败不会走到部署阶段。我们曾因一个x-validation写成gt:0正确 vsgt0错误导致构建卡在第二步避免了带缺陷的 war 包上线。5. 常见问题与排查技巧实录那些只有亲手搭过才懂的坑5.1 Spec 语法错误YAML 缩进引发的血案问题现象spec:watch报错Cannot create propertyitems for JavaBeanResponseSchema但 YAML 看起来完全正确。排查过程第一步用在线 YAML 验证器https://yamlchecker.com粘贴内容显示No errors第二步用 VS Code 的 “Indentation” 功能显示空白字符发现items:后面是 3 个空格而上面的data:是 2 个空格第三步查 OpenSpec 规范确认items必须是data的直接子级缩进必须严格一致。根本原因YAML 对缩进极其敏感2和3个空格在人类眼里没区别但解析器认为这是两个不同层级。我们后来在spec-linter中加入了缩进一致性检查报错信息改为ERROR: Inconsistent indentation at line 15: items indented with 3 spaces, but parent data uses 2 spaces。实操心得永远用空格而非 Tab缩进且在编辑器中开启“显示空白字符”。VS Code 设置editor.renderWhitespace: allWebStorm 设置Editor General Appearance Show whitespaces。5.2 前后端类型不一致datetime 字段的千年 bug问题现象前端调用getOrders后created_at字段在控制台显示为Invalid Date。排查过程第一步用 Postman 直接请求/api/v1/orders响应体中created_at是2023-10-05T08:23:15.1230000第二步检查前端生成的types/order.ts发现类型是created_at: string第三步查后端OrderDto.javacreated_at字段是LocalDateTimeJackson 默认序列化为yyyy-MM-ddTHH:mm:ss.SSS格式第四步对比 Speccreated_at: datetime—— 问题在这里datetime是 OpenSpec 的自定义类型但我们没在前端生成器中定义它的映射规则。解决方案在vite.config.ts的openSpecPlugin配置中增加类型映射openSpecPlugin({ typeMappings: { datetime: string, // 默认映射为 string // 但我们可以加一个转换函数 customTransformers: { datetime: (value: string) new Date(${JSON.stringify(value)}) } } })这样生成的 TS 代码就变成created_at: string; // 保留原始字符串 // 但 API 函数里自动包装 export const getOrders (params: { page?: number; size?: number }) axios.get...(/api/v1/orders, { params }) .then(res ({ ...res.data, data: res.data.data.map(item ({ ...item, created_at: new Date(item.created_at) // 自动转 Date 对象 })) }));5.3 Jenkins 构建失败Windows 路径分隔符陷阱问题现象在 Windows Jenkins 上spec:sync报错Error: ENOENT: no such file or directory, open src\specs\orders.spec.yaml。排查过程第一步登录 Jenkins Agent 服务器手动执行npm run spec:sync成功第二步在 Jenkins Pipeline 中加bat dir src\\specs发现文件存在第三步查 Node.js 的fs.readFile源码发现它在 Windows 上接受\或/但某些第三方库如glob在解析**/*.yaml时会把\当作转义符处理。根本原因Jenkins Pipeline 的bat命令在解析字符串时\被当作转义符吃掉了。src\specs\*.yaml实际传给 Node.js 的是srcpecs*.yaml。解决方案在package.json中把脚本改成双反斜杠scripts: { spec:sync: node scripts/spec-sync.js \src\\\\specs\\\\*.yaml\ }或者更彻底——统一用正斜杠Node.js 在 Windows 上完全兼容spec:sync: node scripts/spec-sync.js \src/specs/*.yaml\5.4 AI 生成代码质量下降当 Spec 写得太“聪明”问题现象某次上线后订单创建接口响应时间从 200ms 涨到 2sAPM 监控显示OrderService.createOrder()占用 95% CPU。排查过程第一步查OrderCreateController生成代码发现它调用了orderService.createOrderWithValidation(orderDto)第二步查createOrderWithValidation实现里面有一段循环for (OrderItem item : orderDto.getItems()) { Product product productService.findById(item.getSku()); if (product null) throw new BusinessException(商品不存在); if (product.getStock() item.getQuantity()) { throw new BusinessException(库存不足); } }第三步查 Spec发现items定义为items: - sku: string quantity: integer x-validation: product_exists stock_sufficient我们为了让 Spec 看起来“智能”加了x-validation扩展结果 AI 生成器把它直译成了 N1 查询。教训Spec 是契约不是伪代码。x-validation这类扩展字段必须有明确、可落地的实现约定。我们现在规定所有x-*字段必须在团队 Wiki 中登记注明“由哪段代码实现”“是否影响性能”。product_exists的正确实现应该是用 Redis 缓存商品 ID 集合SISMEMBER products:ids {sku}用批量 SQL 查询库存SELECT sku, stock FROM product WHERE sku IN (...)。Spec 里只写x-validation: product_exists具体怎么查是后端工程师的职责。6. 最后一点体会AI 不是取代思考而是放大思考的半径这个项目上线半年团队平均需求交付周期缩短了 37%接口联调返工率从 62% 降到 8%最让我意外的不是效率提升而是工程师开始主动思考“这个需求值不值得写 Spec”。上周有个需求“后台管理页加个按钮导出最近 7 天订单 Excel”。按老流程后端写个/export/excel接口前端调用半小时搞定。这次Tech Lead 却拉着产品开了个 20 分钟会讨论三个问题导出数据是否要加权限控制Spec 里必须写x-permissionExcel 表头字段是否和订单列表页一致Spec 里response.200.data必须和GET /orders对齐文件名是否要包含日期范围Spec 里x-filename-template: orders_{start}_{end}.xlsx最后他们决定不单独写新接口而是给现有GET /orders接口加个formatexcel参数复用全部 Spec 和校验逻辑。AI 没参与这个决策但它让这个决策变得必须——因为 Spec 是共享的、可验证的、不可绕过的。所以回到标题“我把 AI Coding 的决策移到了写代码之前”。移的不是代码是把模糊的、口头的、易变的“想法”变成清晰的、共识的、可执行的“契约”。AI 是那个最较真的校对员、最耐心的翻译官、最不知疲倦的守门人。而人终于可以腾出手去做只有人能做的事判断什么是重要的什么是值得做的以及——当 Spec 也无法覆盖时如何优雅地破例。我在实际操作中发现最难的从来不是工具链搭建而是让第一个 Spec 被所有人认真对待。建议你从最小的接口开始比如“获取当前用户信息”把它走通、跑赢、展示给团队看。当大家亲眼看到改一个字段名前后端代码、类型、文档、测试全部自动更新那种确定性带来的踏实感会比任何 PPT 都有说服力。
