全栈认证前做了几次全栈模拟，我把所有踩过的坑固化进了流程

前面几篇聊的是 Agent 的工具链；这一篇换个角度，看怎么把 Claude Code 的 Skills、Hooks 和 MCP 固化成一套可复用的开发流程。

最近国内一些大厂搞了一些全栈工程师认证，在此我们不去评价这种管理考核方式，只是站在如何更好的学习与认证全栈的角度下思考问题，以下是我在这次认证过程中的一些思考和实践：

备考全栈技术考试的时候，我给自己定了一个策略：正式认证前，完整模拟至少三次。

技术栈是 Spring Boot + React + Docker，时限 4 小时，要求一键部署、有测试、有安全处理。

第一次模拟，中文乱码排查了将近 40 分钟，部署阶段镜像拉取超时，Docker 容器没跑起来，最终没交完。

第二次，并发处理漏了，库存超卖，E2E 测试全红。

第三次，前端先动了手，后端接口还没设计好，返工浪费了一个小时。

每一次失败复盘，我都意识到：问题不是技术不够好，而是没有一套可以复用的流程。全链路 UTF-8 配置、加速镜像源、BCrypt 密码加密、乐观锁处理并发……这些"老手才知道"的经验，在紧张状态下靠记忆，一定会漏。

于是我做了一件事：把经验编码为流程，而不是记在脑子里。

这篇文章记录的，就是这套流程的设计思路。

---

一、问题的本质：依赖记忆，就会在紧张时失效

几轮模拟下来，我总结出了四个反复出现的痛点：

痛点	描述
记忆不可靠	全链路编码、BCrypt、乐观锁、XSS 过滤……紧张时这些"老手才知道"的经验容易漏
质量不一致	状态好的时候做得完整，状态差的时候缺测试、缺安全处理
流程不标准	先写代码还是先画设计？模块怎么拆？没有固定流程容易走弯路
上下文丢失	与 AI 协作时，中途切换话题后早期定的要求就忘了

核心洞察是：这些问题都不是"技术问题"，而是"流程问题" 。

无论考题是"商城内购系统"还是"会议室预订"，底层的开发流程是相通的：

理解题目 → 分析需求 → 拆分模块 → 设计前后端 → 搭建项目 → 开发模块 → 部署验证 → 测试 → 交付

把这个流程编码为 10 个标准化的 Phase，每个 Phase 固化一个环节的最佳实践、检查清单和输出模板，就是这套系统的核心思路。

---

二、技能体系的整体架构

整个系统由三个层次组成：

┌─────────────────────────────────────────────────┐
│              调度器 (fullstack-workflow)           │
│  负责：进度检测、Phase 编排、卡点控制、Git 提交提醒    │
└────────────────────┬────────────────────────────┘
                     │ 调度
     ┌───────────────┼───────────────┐
     ▼               ▼               ▼
┌─────────┐    ┌─────────┐    ┌─────────┐
│ Phase 1 │    │ Phase 2 │    │ Phase N │   ← 子技能
│ 边界分析 │    │ 需求分析 │    │ 交付准备 │
└─────────┘    └─────────┘    └─────────┘
     │               │               │
     ▼               ▼               ▼
┌─────────────────────────────────────────────┐
│              文档产物 (doc/*.md)              │
│  边界分析 → 需求文档 → 模块设计 → 接口设计 → ...  │
└─────────────────────────────────────────────┘

调度器 不写代码，只负责判断"现在该做什么"。通过检测 doc/ 目录中已存在的文档来判断当前进度，用户只需说"下一步"，调度器自动执行当前 Phase。

子技能（Phase 1-10） 每个 Phase 是独立的技能文件，包含角色定位、输入输出、执行步骤和强制检查清单。

文档产物 每个 Phase 的产出是标准化的 Markdown 文档，作为下游 Phase 的输入，形成完整的文档链。

10 个 Phase 总览

Phase	名称	核心产出
1	边界分析	doc/边界分析.md
2	需求分析	doc/系统需求分析.md + 前后端需求 + E2E 测试规格
3	模块拆分	doc/前端模块设计.md + doc/后端模块设计.md
4	前端设计	doc/前端页面设计.md（含 Stitch 提示词）
5	后端设计	doc/接口设计.md + doc/数据库设计.md
6	项目搭建	docker-compose.yml + 目录结构 + 配置文件
7	模块开发	功能代码 + 单元测试 + 接口文档
8	部署验证	部署成功状态
9	自动化测试	doc/测试报告.md
10	交付准备	README.md + doc/交付清单.md + 前端截图

---

三、关键设计决策：每一条都是模拟踩过的坑

光说"分了 10 个 Phase"没什么说服力。以下几个具体的设计决策，才是真正从模拟中磨出来的。

决策 1：Phase 1 把"隐式要求"显式化

第一次模拟漏掉并发处理，不是不懂乐观锁，而是题目里没有明写"需要处理并发" ——"同一时段不允许重叠"、"库存"这类词，需要有人提醒你它背后意味着什么。

Phase 1 的核心任务就是把隐式要求显式化：

题目中的信号词	识别出的需求	技术方案
"同一时段"、"唯一"、"库存"	并发安全（一票否决）	乐观锁 + 分布式锁
"docker-compose"、"一键启动"	环境可复现（一票否决）	Docker + docker-compose
"校验"、"检测"	后端校验（一票否决）	Spring Validation
"密码"、"账号"	密码安全（一票否决）	BCrypt 加密

"一票否决" 是关键概念：这些项如果遗漏，整个交付直接不合格，不是扣分，是归零。

决策 2：文档链让每个 Phase "只关注自己需要的信息"

模拟中发现一个规律：用 AI 协作时，前面定好的要求，开发到后面 AI 就"忘了"。

根本原因是上下文窗口有限，早期信息被挤出去了。

解决方式是：不让 AI 去"记"，而是让每个 Phase 重新读文档。

Phase 1 产出 → doc/边界分析.md
                    ↓ Phase 7 开发时重新读取，而不是依赖"AI 还记得"
Phase 7 读取 → doc/边界分析.md + doc/接口设计.md + doc/模块开发计划.md

文档是状态，技能是无状态的处理器。每个 Phase 只关注自己需要的那几份文档，上下文永远是干净的。

决策 3：Phase 6 强制骨架先行，禁止提前写业务代码

第三次模拟的教训：前端先动了手，后端接口还没设计好，最后接口一改，前端大面积返工。

Phase 6 有一条强制规则：只创建目录结构和配置文件，禁止写任何业务代码。

这一阶段结束时，docker compose up -d 必须能跑通，哪怕后端什么都没实现，容器得是健康的。

包含的配置项：

• docker-compose.yml（MySQL、Redis、后端、前端，含健康检查）
• 全链路 UTF-8 编码配置（JVM → Servlet → Jackson → MyBatis → MySQL → Nginx，每一层都要配，漏一层就乱码）
• 加速镜像源配置（Maven 仓库、NPM 加速源）
• .gitignore、环境变量模板、前端 Tailwind 主题

决策 4：E2E 测试规格在需求阶段就定义

很多人开发完了再写测试，验证的往往是"代码能跑通"，而不是"业务需求是否满足"。

在 Phase 2 需求分析阶段，就同步生成 doc/E2E测试用例规格.md，包含用户旅程、边界条件、并发场景。Phase 9 自动化测试时直接用这份文档作为基准——验证的是"最初的需求"，不是"最终写出来的代码"。

决策 5：质量门禁是硬卡点，不是建议

每个模块开发完成后，必须运行质量门禁脚本：

bash scripts/quality-gate.sh

# 执行输出：
✅ ESLint: PASS
✅ Prettier: PASS
✅ TypeScript 类型检查: PASS
✅ 后端测试（含 ArchUnit）: PASS
━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ QUALITY GATE PASSED (4/4)

4 项检查必须全部通过才能提交 Git。任何一项失败，代码禁止提交。这不是"建议跑一下"，是代码能不能进仓库的硬门禁。

---

四、层次化卡点：哪些地方自动推进，哪些地方必须停

这套系统里有个细节设计：不是所有 Phase 完成后都停下来等人确认。

Phase 范围	卡点类型	原因
P1–P6（搭建阶段）	自动继续	这些步骤是固定的，没有歧义
P2 需求分析后	强制人工审查	需求理解偏了，后面全白做
P7 后端全部完成后	强制人工审查	前端依赖后端接口，接口要先确认
P8–P10	强制人工审查	最终交付阶段，每步都要人确认

不重要的决策自动化，关键节点必须人工确认——这是在效率和质量把控之间的平衡。

---

五、运行时基础设施：Hook 与 MCP

技能系统不是孤立运行的。在 Claude Code 环境下，Hook 和 MCP 共同构成了技能的运行时基础设施。

Hook：防止流程偏离

项目 .claude/settings.json 配置了 PostToolUse Hook，在每次调用后端开发技能时自动注入强制提醒：

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Skill",
        "hooks": [
          {
            "type": "command",
            "command": "当检测到 fullstack-phase7-backend 技能被调用时，注入 SDD 提醒"
          }
        ]
      }
    ]
  }
}

注入内容：

"SDD 强制提醒：1) 小步单模块提交 — 每个模块完成后立即单独 git commit，禁止批量提交多个模块！2) 必须使用 OpenSpec SDD 开发流程 — 每次必须执行 propose → apply → archive，禁止跳过！"

即使没有人工监督，流程也不会偏离。

MCP 工具链

MCP 服务器	能力	用在哪里
stitch	AI 驱动的 UI 设计稿生成	Phase 4 前端设计
playwright	浏览器自动化、E2E 测试、截图	Phase 9 测试、Phase 10 截图
filesystem	文件系统读写	全流程

Phase 10 交付准备时，Playwright 会用测试账号登录后逐页自动截图——不是手动截的，避免"忘了截图"或"截图不全"的问题。

---

六、实际交付数据

以"商城内购系统"模拟为例：

维度	数据
文档产物	20+ 个 Markdown 文档
后端模块	7 个（Common、Auth、User、Activity、Order、Payment、Admin）
前端模块	7 个（认证、首页、详情、订单、个人中心、管理后台等）
数据库表	7 张（含索引、外键、乐观锁 version 字段、种子数据）
API 接口	20+ 个 RESTful 接口
E2E 测试用例	30+ 个（含用户旅程、边界条件、并发场景）
质量门禁	ESLint + Prettier + TypeScript + ArchUnit + 后端测试全通过

安全覆盖方面，通过 Phase 1 一票否决项和 Phase 7 安全必检清单，每个模块都覆盖了：

• 认证：JWT Token + BCrypt 密码加密 + 登录失败锁定
• XSS：输入过滤 + 输出转义
• CSRF：JWT 放在 Header 而非 Cookie
• SQL 注入：MyBatis-Plus 预编译语句
• 越权访问：操作前校验资源归属
• 并发安全：UPDATE ... WHERE stock >= ? AND version = ?

---

七、这件事让我对"备考"这件事有了新的理解

做完这套系统，我对备考这件事的理解变了。

以前的备考逻辑是：多做题，多练技术，考场上靠发挥。

但全栈考试的问题是，需要你同时记住的东西太多了，任何一层遗漏都可能让整个项目挂掉。靠发挥，等于把成功率交给了运气。

更有效的备考逻辑是：把解题流程练到自动化，考场上按流程走就行。

这和高考备考的本质是一样的——不同的是，以前磨炼的是对知识的掌握，现在磨炼的是对流程的设计和对 AI 工具的驾驭能力。

流程是可以设计的，可以迭代的，可以复用的。 "经验"一旦被编码进流程，就不再只存在于某次模拟的记忆里，而是变成了每次都能调用的资产。

---

这套 Phase 技能体系完整开源在 GitHub，感兴趣可以搜索 shuhui-sh/OpenSource 找到，欢迎在评论区交流你在全栈开发或 AI 协作开发中踩过的坑。

本文收录于《Ai实践》专栏

专栏地址：juejin.cn/column/7611…

系列文章

• Claude Code 7 个隐藏能力
• MCP 协议
• CLI：AI Agent 的手
• 全栈认证前做了几次全栈模拟（本篇·分支）

回到主线，下一篇是 AI 逆向实战：看看 Claude Code 拿着这些工具，能不能自己把 APK 崩溃查清楚。