工程化不是堆工具是堆决策《工程化决策树》第 0 篇 · 总纲这不是一份工具清单而是一套判断方法什么场景该做什么为什么以及选错后会付出什么代价。一、工具齐了项目还是失控之前我接手过一个救火项目。团队 8 个人技术栈是 Next.js 14、PostgreSQL、Docker 和 GitHub Actions。配置文件齐README 也很完整只看工具清单很容易判断它“工程化程度不低”。实际情况却是上线三天出现两次 P0。一次数据库迁移增加非空字段旧代码直接报错一次 CI 全绿但前端按钮在真实数据下无法点击。核心业务逻辑塞在 Controller最大的文件约 1200 行改一个字段要动五个文件。全流程只有老张能跑通。他请假一天当天上线就出事。测试覆盖率显示 87%其中相当一部分是 getter/setter 测试关键路径并没有被保护。问题不在于缺 Docker、CI 或测试框架而在于关键判断只存在于老张脑子里迁移要按什么顺序哪些接口不能随意改部署前还要补哪一步。工具负责执行动作却不知道什么时候应该拒绝一次危险变更。人一离开交付质量就掉下来。这是我判断工程化缺口最常用的信号。二、我如何定义工程化我给工程化的定义只有一句话工程化是用流程和系统把依赖个人发挥的环节逐步变成由系统兜底的环节。这里的“系统”不只指软件也包括明确的契约、可执行的规则、交接物和反馈机制。环节依赖个人发挥由系统兜底需求开会口头对齐靠参与者记忆范围、关键决策和验收标准形成契约架构跟随流行方案或资深者拍板根据阶段、瓶颈和团队能力作选择代码只靠评审者发现问题分层约束、静态检查和自动化测试共同拦截测试上线前手动点一遍每次变更自动验证关键路径部署依赖熟练运维执行步骤健康检查、灰度和回滚形成安全网因此衡量一个环节时我不会先问“用了什么工具”而会问换一个人来做结果会不会明显变差出了偏差系统能不能及时发现并阻止如果答案分别是“会”和“不能”这个环节仍然依赖个人。工具再多也只是把不稳定的流程跑得更快。三、五层能力不是五件一次性采购过去 10 年开发和 10 个大型项目和产品是这套框架的个人经验来源不是行业统计样本。我把反复遇到的问题归纳为五层能力。1. 标准化需求工程需求工程先处理“需求只在脑子里”的问题。澄清不确定项后把范围、关键决策和验收标准写下来最后由相关方确认。小项目可能只需要一份短 Spec长期、多人协作的项目才需要把产品、架构和 UI/UX 文档拆开维护。判断标准不是页数而是隔一段时间再看仍能知道当时要做什么、明确不做什么。2. 项目级上下文系统项目级上下文要让不同角色看到同一幅“项目全貌”。功能范围、API 契约、数据模型、页面路由和关键技术决策应该有可追溯的来源来源变更时相关角色都能知道。对人如此对 AI Agent 也一样。没有共享上下文产出差异会被误判成能力差异。3. 角色级编排角色级编排关注职责混杂和交接靠口述的问题。产品、架构、开发、测试和运维可以由不同的人承担也可以由同一个人在不同阶段承担关键是角色边界和交付物清楚。一人团队同样需要编排只是角色按时间切换而不是按人头拆分。4. 可执行的规范约束规范约束要把“写在文档里”推进到“稳定执行”。适合机器判断的规则应交给 lint、测试、构建检查或部署门禁确需绕过时留下显式记录和理由。机器不擅长判断业务取舍所以这层不是取消人工评审而是让评审者把注意力放在机器无法判断的地方。5. 可观测性与反馈可观测性让交付过程和线上状态不再是黑盒。进度、质量、运行健康度与关键决策都需要反馈渠道团队才能在事故之前发现趋势在事故之后还原过程。指标也会失真。覆盖率、构建成功率只是信号必须和关键路径、错误预算、用户影响一起解释。这五层是最终应该补齐的能力地图不是要求所有项目第一天就做到同一深度。它们之间没有固定施工顺序阶段优先补齐暂时保持轻量探索期 / MVP范围契约、基本分层、核心路径测试、可恢复部署完整文档体系、复杂平台和全量指标增长期共享上下文、自动化门禁、稳定发布与故障反馈尚未出现收益的分布式基础设施成熟期跨团队编排、平台能力、全链路可观测性与实际风险无关的形式化流程“最终要有”与“现在就全部建设”是两回事。工程化投入应该跟着风险增长而不是跟着工具热度增长。四、为什么用决策树而不是最佳实践最佳实践常把条件藏起来只留下结论。决策树要求把条件、选择和代价放在一起。以架构为例单体和微服务没有脱离场景的胜负。一个需求仍在验证、协作压力不高的团队往往更需要简单部署和快速反馈当模块出现独立扩缩容瓶颈、多个团队互相阻塞并且平台能力已经具备时拆分才可能收回分布式成本。决策可以写成这样的结构需求和领域边界是否稳定 ├── 否 → 优先保持部署简单让反馈更快 └── 是 ├── 是否出现可定位的性能或协作瓶颈 │ └── 否 → 继续优化现有架构 └── 是 ├── 能否独立部署、监控、回滚并处理一致性 │ ├── 否 → 先补工程能力 │ └── 是 → 只拆能验证收益的边界这棵树没有把人数、代码量或日活写成通用阈值。它们可以作为信号但同样的数字在支付系统、内容站点和内部工具里含义不同。一份可用的工程决策至少应回答四个问题当前要解决的具体问题是什么哪些约束会改变选择选择之后新增了什么成本出现什么信号时需要重新评估决策树不是替你给答案而是防止团队跳过这些问题。五、贯穿系列的几条立场工程化要对准风险MVP 的首要风险通常是需求不成立成熟系统的首要风险可能是一次变更影响大量用户。两者需要的安全网不同。前者也要有 Spec、基本分层和关键路径测试但不必照搬大型组织的全套平台。关键路径优先于漂亮指标救火项目的覆盖率已经达到 87%仍然漏掉了真实数据下无法点击的按钮。覆盖率适合发现空白不能替代风险判断。先保护交易、权限、数据迁移和恢复路径再讨论全局数字。可恢复比“从不出错”更现实部署流程不只负责把版本送上去还要确认它是否健康并在失败时缩短恢复时间。回滚、兼容迁移和数据修复预案往往比继续增加部署动作更重要。AI 也需要边界和反馈AI 可以提高生成速度但不自动拥有项目上下文、验收标准和质量责任。探索期可以放宽约束换取速度进入交付期后需要把同样的需求、测试和评审机制作用在 AI 产出上。系统要降低对英雄的依赖优秀工程师仍然重要。他们更适合设计规则、处理例外和作出高风险决策而不是反复充当人工检查器。好的系统不保证每次都做到最好但能让团队在人员变化和压力增大时结果不至于失控。六、系列导航与使用方式全系列共 9 篇含本篇篇号文章要回答的决策0工程化不是堆工具是堆决策如何从工具清单转向条件、选择与代价1需求先把歧义问清别把返工拖到交付后项目需要多深的需求文档2单体、微服务、Serverless架构要匹配问题三类架构如何匹配项目阶段3Controller 为什么会变胖先拆职责再谈分层业务逻辑应该落在哪里490% 覆盖率不等于没 Bug用风险配置测试组合有限测试投入先保护哪里5能部署不算本事能恢复才算把恢复能力做进发布流程不同风险下如何发布和恢复6同一模型为什么交付结果差这么远探索与交付阶段如何约束 AI7一个人做项目先减少切换再放大产出一个人先自动化什么、保留什么人工判断8工程化的终点是“不需要英雄”如何降低对关键个人的依赖从 0 到 8 顺序阅读适合正在搭建交付体系的团队。已有明确痛点时可以把本篇当索引直接跳到对应章节需求反复变更看第 1 篇架构拖慢迭代看第 2 篇线上恢复困难看第 5 篇AI 产出不稳定看第 6 篇。阅读每篇时不必照抄结论。先写下自己的项目阶段、主要风险和团队能力再沿决策树选择条件变化后回到原来的决策点重新评估。下一篇需求先把歧义问清别把返工拖到交付后《工程化决策树》第 0 篇 · 总纲 · lytao123 工程化不是堆工具，是堆决策
工程化不是堆工具是堆决策《工程化决策树》第 0 篇 · 总纲这不是一份工具清单而是一套判断方法什么场景该做什么为什么以及选错后会付出什么代价。一、工具齐了项目还是失控之前我接手过一个救火项目。团队 8 个人技术栈是 Next.js 14、PostgreSQL、Docker 和 GitHub Actions。配置文件齐README 也很完整只看工具清单很容易判断它“工程化程度不低”。实际情况却是上线三天出现两次 P0。一次数据库迁移增加非空字段旧代码直接报错一次 CI 全绿但前端按钮在真实数据下无法点击。核心业务逻辑塞在 Controller最大的文件约 1200 行改一个字段要动五个文件。全流程只有老张能跑通。他请假一天当天上线就出事。测试覆盖率显示 87%其中相当一部分是 getter/setter 测试关键路径并没有被保护。问题不在于缺 Docker、CI 或测试框架而在于关键判断只存在于老张脑子里迁移要按什么顺序哪些接口不能随意改部署前还要补哪一步。工具负责执行动作却不知道什么时候应该拒绝一次危险变更。人一离开交付质量就掉下来。这是我判断工程化缺口最常用的信号。二、我如何定义工程化我给工程化的定义只有一句话工程化是用流程和系统把依赖个人发挥的环节逐步变成由系统兜底的环节。这里的“系统”不只指软件也包括明确的契约、可执行的规则、交接物和反馈机制。环节依赖个人发挥由系统兜底需求开会口头对齐靠参与者记忆范围、关键决策和验收标准形成契约架构跟随流行方案或资深者拍板根据阶段、瓶颈和团队能力作选择代码只靠评审者发现问题分层约束、静态检查和自动化测试共同拦截测试上线前手动点一遍每次变更自动验证关键路径部署依赖熟练运维执行步骤健康检查、灰度和回滚形成安全网因此衡量一个环节时我不会先问“用了什么工具”而会问换一个人来做结果会不会明显变差出了偏差系统能不能及时发现并阻止如果答案分别是“会”和“不能”这个环节仍然依赖个人。工具再多也只是把不稳定的流程跑得更快。三、五层能力不是五件一次性采购过去 10 年开发和 10 个大型项目和产品是这套框架的个人经验来源不是行业统计样本。我把反复遇到的问题归纳为五层能力。1. 标准化需求工程需求工程先处理“需求只在脑子里”的问题。澄清不确定项后把范围、关键决策和验收标准写下来最后由相关方确认。小项目可能只需要一份短 Spec长期、多人协作的项目才需要把产品、架构和 UI/UX 文档拆开维护。判断标准不是页数而是隔一段时间再看仍能知道当时要做什么、明确不做什么。2. 项目级上下文系统项目级上下文要让不同角色看到同一幅“项目全貌”。功能范围、API 契约、数据模型、页面路由和关键技术决策应该有可追溯的来源来源变更时相关角色都能知道。对人如此对 AI Agent 也一样。没有共享上下文产出差异会被误判成能力差异。3. 角色级编排角色级编排关注职责混杂和交接靠口述的问题。产品、架构、开发、测试和运维可以由不同的人承担也可以由同一个人在不同阶段承担关键是角色边界和交付物清楚。一人团队同样需要编排只是角色按时间切换而不是按人头拆分。4. 可执行的规范约束规范约束要把“写在文档里”推进到“稳定执行”。适合机器判断的规则应交给 lint、测试、构建检查或部署门禁确需绕过时留下显式记录和理由。机器不擅长判断业务取舍所以这层不是取消人工评审而是让评审者把注意力放在机器无法判断的地方。5. 可观测性与反馈可观测性让交付过程和线上状态不再是黑盒。进度、质量、运行健康度与关键决策都需要反馈渠道团队才能在事故之前发现趋势在事故之后还原过程。指标也会失真。覆盖率、构建成功率只是信号必须和关键路径、错误预算、用户影响一起解释。这五层是最终应该补齐的能力地图不是要求所有项目第一天就做到同一深度。它们之间没有固定施工顺序阶段优先补齐暂时保持轻量探索期 / MVP范围契约、基本分层、核心路径测试、可恢复部署完整文档体系、复杂平台和全量指标增长期共享上下文、自动化门禁、稳定发布与故障反馈尚未出现收益的分布式基础设施成熟期跨团队编排、平台能力、全链路可观测性与实际风险无关的形式化流程“最终要有”与“现在就全部建设”是两回事。工程化投入应该跟着风险增长而不是跟着工具热度增长。四、为什么用决策树而不是最佳实践最佳实践常把条件藏起来只留下结论。决策树要求把条件、选择和代价放在一起。以架构为例单体和微服务没有脱离场景的胜负。一个需求仍在验证、协作压力不高的团队往往更需要简单部署和快速反馈当模块出现独立扩缩容瓶颈、多个团队互相阻塞并且平台能力已经具备时拆分才可能收回分布式成本。决策可以写成这样的结构需求和领域边界是否稳定 ├── 否 → 优先保持部署简单让反馈更快 └── 是 ├── 是否出现可定位的性能或协作瓶颈 │ └── 否 → 继续优化现有架构 └── 是 ├── 能否独立部署、监控、回滚并处理一致性 │ ├── 否 → 先补工程能力 │ └── 是 → 只拆能验证收益的边界这棵树没有把人数、代码量或日活写成通用阈值。它们可以作为信号但同样的数字在支付系统、内容站点和内部工具里含义不同。一份可用的工程决策至少应回答四个问题当前要解决的具体问题是什么哪些约束会改变选择选择之后新增了什么成本出现什么信号时需要重新评估决策树不是替你给答案而是防止团队跳过这些问题。五、贯穿系列的几条立场工程化要对准风险MVP 的首要风险通常是需求不成立成熟系统的首要风险可能是一次变更影响大量用户。两者需要的安全网不同。前者也要有 Spec、基本分层和关键路径测试但不必照搬大型组织的全套平台。关键路径优先于漂亮指标救火项目的覆盖率已经达到 87%仍然漏掉了真实数据下无法点击的按钮。覆盖率适合发现空白不能替代风险判断。先保护交易、权限、数据迁移和恢复路径再讨论全局数字。可恢复比“从不出错”更现实部署流程不只负责把版本送上去还要确认它是否健康并在失败时缩短恢复时间。回滚、兼容迁移和数据修复预案往往比继续增加部署动作更重要。AI 也需要边界和反馈AI 可以提高生成速度但不自动拥有项目上下文、验收标准和质量责任。探索期可以放宽约束换取速度进入交付期后需要把同样的需求、测试和评审机制作用在 AI 产出上。系统要降低对英雄的依赖优秀工程师仍然重要。他们更适合设计规则、处理例外和作出高风险决策而不是反复充当人工检查器。好的系统不保证每次都做到最好但能让团队在人员变化和压力增大时结果不至于失控。六、系列导航与使用方式全系列共 9 篇含本篇篇号文章要回答的决策0工程化不是堆工具是堆决策如何从工具清单转向条件、选择与代价1需求先把歧义问清别把返工拖到交付后项目需要多深的需求文档2单体、微服务、Serverless架构要匹配问题三类架构如何匹配项目阶段3Controller 为什么会变胖先拆职责再谈分层业务逻辑应该落在哪里490% 覆盖率不等于没 Bug用风险配置测试组合有限测试投入先保护哪里5能部署不算本事能恢复才算把恢复能力做进发布流程不同风险下如何发布和恢复6同一模型为什么交付结果差这么远探索与交付阶段如何约束 AI7一个人做项目先减少切换再放大产出一个人先自动化什么、保留什么人工判断8工程化的终点是“不需要英雄”如何降低对关键个人的依赖从 0 到 8 顺序阅读适合正在搭建交付体系的团队。已有明确痛点时可以把本篇当索引直接跳到对应章节需求反复变更看第 1 篇架构拖慢迭代看第 2 篇线上恢复困难看第 5 篇AI 产出不稳定看第 6 篇。阅读每篇时不必照抄结论。先写下自己的项目阶段、主要风险和团队能力再沿决策树选择条件变化后回到原来的决策点重新评估。下一篇需求先把歧义问清别把返工拖到交付后《工程化决策树》第 0 篇 · 总纲 · lytao123