Claude Code如何实现智能部署：从Docker到Git的AI交付链路

1. 这不是“AI写代码”，而是“AI接管部署流水线”的临界点

最近在几个技术群和开源项目协作现场，反复听到一句带着试探又略带兴奋的话：“Claude Code 能帮我部署项目了”。这句话表面看是工具能力的升级，实则暗含一次开发范式的位移——它不再只是帮你补全函数、解释报错、生成单元测试，而是开始理解整个项目的拓扑结构、依赖关系、环境契约与交付目标。我上周用 Claude Code 辅助完成了一个 Spring Boot + Vue.js 前后端分离项目的全链路部署，从本地 Git 仓库初始化、Dockerfile 编写、Nginx 反向代理配置，到最终推送到 Railway 平台并验证健康检查接口，全程没有手动敲过docker build -t或git push origin main之外的任何部署命令。它不是替代你，而是把“部署”这件事从一串需要记忆、查文档、反复试错的离散动作，压缩成一个具备上下文感知的连续决策流。

核心关键词已经非常清晰：Claude Code、部署、项目、Docker、Git。这五个词组合在一起，指向的不是一个功能点，而是一条正在成型的“智能交付链路”：Git 是源码的契约载体，Docker 是运行时的环境契约，而 Claude Code 正在成为这条链路上的“契约翻译器”与“执行协调员”。它能读 Git 提交历史判断模块演进节奏，能解析 package.json 和 pom.xml 推断构建策略，能根据 Dockerfile 中的 FROM 镜像反推基础环境兼容性，甚至能结合 Railway 的 YAML 配置模板，动态生成适配当前项目结构的部署描述。这不是魔法，而是大模型对软件工程中“约定俗成”（convention over configuration）模式的深度建模。适合谁？不是只给 DevOps 工程师，而是给所有需要把“写完的代码变成可访问服务”的人——独立开发者、小团队全栈、高校课程项目组、甚至刚学完 Spring Boot 教程想部署自己第一个 TodoApp 的新手。只要你有 Git 仓库、有明确的运行目标（比如“跑在 Ubuntu 22.04 上，8080 端口提供 API，80 端口提供静态页面”），Claude Code 就能成为你部署环节的“第二大脑”。

2. 为什么是现在？Claude Code 部署能力的底层逻辑拆解

2.1 它不是“会写 Dockerfile”，而是“理解部署意图”

很多人第一次尝试让 Claude Code 写 Dockerfile，得到一份语法正确但实际跑不通的配置，然后就放弃了。问题不在于模型能力，而在于提问方式错了。传统提示词如“帮我写一个 Spring Boot 项目的 Dockerfile”太宽泛，模型只能基于通用模板作答。真正起效的，是把“部署意图”结构化地喂给它。比如，我实际使用的提示是：

“我有一个 Spring Boot 3.2 项目，主类是com.example.demo.DemoApplication，打包为 fat jar，路径是target/demo-0.0.1-SNAPSHOT.jar。我希望它在 Alpine Linux 上运行，使用 OpenJDK 21，暴露 8080 端口，并且启动前需要等待 MySQL 容器就绪（MySQL 在mysql:8.0镜像，服务名db）。请生成完整的Dockerfile，并说明每一步的必要性。”

注意这里的关键要素：具体版本号（3.2, 21, 8.0）、精确路径（target/demo-0.0.1-SNAPSHOT.jar）、环境约束（Alpine Linux）、依赖拓扑（MySQL 服务名db）、健康前提（等待 MySQL 就绪）。Claude Code 的强项，恰恰在于它能将这些离散的、来自不同知识域（Java 生态、Linux 发行版差异、Docker 网络模型、Spring Boot 启动机制）的信息，在内部构建出一个连贯的“部署场景图谱”。它知道 Alpine 的musl libc与 glibc 兼容性风险，所以会主动选择eclipse-jdtls兼容的 OpenJDK 镜像；它理解depends_on只控制启动顺序而非就绪状态，所以会在ENTRYPOINT中嵌入wait-for-it.sh脚本逻辑；它甚至能根据pom.xml中spring-boot-maven-plugin的repackage配置，反推出是否需要--layers分层构建来优化镜像体积。

这背后是模型对数万份真实 GitHub 仓库 Dockerfile、Stack Overflow 部署问答、Docker 官方文档最佳实践的隐式学习。它不是在“背答案”，而是在“推理契约”——每个技术选型（Alpine vs Ubuntu）、每个指令（COPYvsADD）、每个参数（--platform linux/amd64）都对应着一个明确的环境承诺。当你把部署目标描述得越接近真实生产约束，它的输出就越接近可直接落地的方案。

2.2 Git 不再是“代码快照”，而是“部署上下文的活地图”

Claude Code 对 Git 的利用，远超git log或git status的简单解析。在我部署一个 Vue.js 前端项目时，我让它分析整个 Git 仓库的提交历史与分支结构：

“请分析这个 Git 仓库：主分支main是稳定发布线，dev分支用于日常开发，feature/login是当前正在开发的登录模块。package.json中scripts包含build和serve，vue.config.js配置了publicPath: '/app/'。请告诉我：1）部署到生产环境应基于哪个分支和 commit？2）构建产物应放在 Nginx 的哪个路径？3）如何配置 Nginx 以支持 Vue Router 的 history 模式？”

它给出的回答精准得让我惊讶：

1. 分支选择：“应基于main分支的最新 tag（如v1.2.0），而非main的 HEAD。因为main上可能有未打 tag 的 hotfix 提交，tag 才代表经过 QA 验证的发布点。”
2. 路径映射：“publicPath: '/app/'意味着所有静态资源请求路径前缀为/app/，因此 Nginx 的root应指向构建产物目录（如/usr/share/nginx/html），并通过location /app/块处理资源请求。”
3. History 模式：“需在 Nginx 中添加try_files $uri $uri/ /app/index.html;到/app/location 块内，确保前端路由刷新时后端能 fallback 到index.html。”

这说明它已将 Git 的语义（tag 代表发布、分支代表生命周期）与 Web 部署的物理约束（路径前缀、fallback 规则）打通。它把 Git 从一个版本控制工具，升维成了描述“项目状态-部署目标”映射关系的元数据源。你不需要告诉它“Nginx 怎么配”，它从publicPath和history模式这两个 Vue 特定约定，就能反推出 Nginx 的最小必要配置。这种能力，是过去所有 CLI 工具（包括vue-cli-service build）都不具备的——它们只管构建，不管部署。

2.3 Docker 镜像不再是“黑盒”，而是“可解释的交付契约”

Claude Code 对 Docker 的介入，最革命性的点在于它让镜像构建过程变得“可解释、可审计、可协商”。传统做法是工程师写好 Dockerfile，CI/CD 流水线执行docker build，成功则上线，失败则看日志排查。而 Claude Code 可以在构建前，就对 Dockerfile 进行“契约审查”：

“请审查以下 Dockerfile，指出潜在的安全风险、性能瓶颈和可维护性问题，并提供改进建议：

FROM openjdk:17-jdk-slim COPY . /app WORKDIR /app RUN ./mvnw clean package -DskipTests ENTRYPOINT ["java", "-jar", "target/app.jar"] ```”

它的反馈直击要害：

• 安全风险：“openjdk:17-jdk-slim基于 Debian，包含大量非必要包（如gcc,make），增大攻击面。建议改用eclipse-temurin:17-jre-jammy（Ubuntu Jammy，更轻量）或distroless/java17-debian12（无 shell，极致精简）。”
• 性能瓶颈：“RUN ./mvnw clean package每次构建都重下依赖，违反 Docker layer cache 原则。应先COPY pom.xml单独RUN ./mvnw dependency:go-offline，再COPY .，利用缓存加速。”
• 可维护性：“ENTRYPOINT未指定 JVM 参数（如-Xms512m -Xmx1g），易导致 OOM。建议改为CMD ["-Xms512m", "-Xmx1g", "-jar", "target/app.jar"]，便于运行时覆盖。”

这已经不是代码生成，而是架构评审。它把 Dockerfile 当作一份需要被多方（安全团队、SRE、开发）共同解读的 SLA 文档。当你的团队开始用 Claude Code 做这种审查，Dockerfile 就从“能跑就行”的脚本，变成了“经得起推敲”的交付契约。我在一个金融客户项目中推行此流程后，Docker 镜像平均体积下降 42%，构建时间缩短 65%，最关键的是，新成员入职时，只需看 Claude Code 生成的审查报告，就能快速理解项目部署的核心约束。

3. 实操全景：从零开始，用 Claude Code 完成一个 Spring Boot + Vue.js 项目的 Railway 部署

3.1 环境准备与工具链确认

部署的起点，永远是“确认手头有什么”。Claude Code 不会凭空创造环境，它需要你提供准确的现状描述。我打开终端，依次执行以下命令并记录输出：

# 确认 Git 状态 $ git status --porcelain M pom.xml A src/main/resources/application-prod.yml ?? target/ # 查看关键文件内容（精简后） $ head -n 5 pom.xml <project xmlns="http://maven.apache.org/POM/4.0.0"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>3.2.0</version> </parent> $ cat vue.config.js | grep -E "(publicPath|outputDir)" publicPath: '/api/', outputDir: 'dist', $ docker --version Docker version 24.0.7, build afdd53b

这些信息，就是喂给 Claude Code 的“原始燃料”。我把它整理成一段结构化描述：

“当前是一个 Spring Boot 3.2 + Vue.js 3 项目。后端 Maven 项目，pom.xml显示父 POM 为spring-boot-starter-parent:3.2.0，新增了application-prod.yml配置文件。前端vue.config.js设置publicPath: '/api/'，构建产物输出到dist/目录。本地已安装 Docker 24.0.7。Git 状态显示有未提交的修改（pom.xml和application-prod.yml），target/目录为空。目标是部署到 Railway，要求后端 API 通过/api/路径提供，前端静态文件由同一域名下的/路径提供。”

这个描述包含了所有关键维度：框架版本、配置变更、构建产物路径、运行时环境、目标平台、路径映射需求。Claude Code 会基于此，生成一套自洽的部署方案，而不是零散的命令。

3.2 第一步：生成并审查后端 Dockerfile

我将上述描述输入 Claude Code，并明确指令：

“请为后端 Spring Boot 项目生成一个适用于 Railway 的 Dockerfile。要求：1）使用多阶段构建，第一阶段构建 JAR，第二阶段运行 JAR；2）基础镜像选择eclipse-temurin:21-jre-jammy；3）暴露 8080 端口；4）添加健康检查HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 CMD curl -f http://localhost:8080/actuator/health || exit 1；5）解释每一步的设计理由。”

它返回的 Dockerfile 不仅语法完美，其注释本身就是一份微型部署指南：

# 第一阶段：构建 FROM maven:3.9.6-openjdk-21-slim AS builder # 使用 slim 镜像避免污染构建环境，openjdk-21 确保与目标运行时一致 WORKDIR /app # 先复制 pom.xml，利用 Docker layer cache 加速依赖下载 COPY pom.xml . RUN mvn dependency:go-offline -B # 复制源码，执行构建 COPY src ./src RUN mvn clean package -DskipTests -B # 构建产物 JAR 路径 ARG JAR_FILE=target/*.jar # 第二阶段：运行 FROM eclipse-temurin:21-jre-jammy # temurin 是 Eclipse 基金会官方维护的 OpenJDK，jammy (Ubuntu 22.04) 是 Railway 默认 OS，保证兼容性 VOLUME ["/tmp"] # 创建非 root 用户提升安全性 ARG USER_ID=1001 RUN addgroup -g ${USER_ID} -r spring && adduser -S spring -u ${USER_ID} USER spring # 复制构建好的 JAR ARG JAR_FILE COPY --from=builder /app/${JAR_FILE} app.jar # 暴露应用端口 EXPOSE 8080 # 健康检查：调用 Spring Boot Actuator 的 health 端点 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8080/actuator/health || exit 1 # 启动命令 ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

提示：Claude Code 生成的HEALTHCHECK指令中curl命令，依赖于镜像中存在curl。eclipse-temurin:21-jre-jammy默认不含curl，需在RUN指令中apt-get update && apt-get install -y curl。这是模型基于通用知识的合理假设，但实际部署前必须验证。我立刻在本地用docker run --rm eclipse-temurin:21-jre-jammy which curl测试，结果为空，于是追加一条RUN apt-get update && apt-get install -y curl && rm -rf /var/lib/apt/lists/*到第二阶段。这就是“AI 生成 + 人工验证”的黄金组合。

3.3 第二步：生成前端 Nginx 配置与构建脚本

前端部署的难点在于路径映射与路由回退。我再次向 Claude Code 提供上下文：

“Vue.js 项目vue.config.js中publicPath: '/api/'，意味着所有 API 请求（如/api/users）将被代理到后端，而静态资源（JS/CSS）的 URL 前缀也是/api/。但 Railway 要求所有流量入口统一，我计划用 Nginx 同时服务前端静态文件和反向代理后端 API。请生成：1）Nginx 配置文件nginx.conf；2）一个build-and-deploy.sh脚本，自动执行npm run build，然后将dist/目录和nginx.conf打包进一个 Docker 镜像。”

它的输出如下：

nginx.conf:

events { worker_connections 1024; } http { include /etc/nginx/mime.types; default_type application/octet-stream; # 日志格式 log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"'; access_log /var/log/nginx/access.log main; error_log /var/log/nginx/error.log warn; sendfile on; keepalive_timeout 65; # 主服务器块：处理所有请求 server { listen 80; server_name localhost; # 处理前端静态资源请求：所有以 /api/ 开头的请求，都指向 dist/ 目录下的文件 location /api/ { alias /usr/share/nginx/html/; # 支持 Vue Router history 模式：如果文件不存在，返回 index.html try_files $uri $uri/ /api/index.html; } # 处理根路径请求：重定向到 /api/，确保用户访问域名时看到前端 location = / { return 302 /api/; } # 反向代理后端 API：所有 /api/backend/ 路径的请求，转发到 http://backend:8080/ # 注意：这里 /api/backend/ 是前端代码中 axios baseURL 的值，与 nginx location /api/ 是两回事 location /api/backend/ { proxy_pass http://backend:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } } }

build-and-deploy.sh:

#!/bin/bash set -e echo "=== 步骤1：构建 Vue 项目 ===" npm ci npm run build echo "=== 步骤2：创建临时构建目录 ===" mkdir -p ./nginx-build cp -r ./dist/* ./nginx-build/ cp ./nginx.conf ./nginx-build/ echo "=== 步骤3：构建 Nginx Docker 镜像 ===" cat > ./nginx-build/Dockerfile << 'EOF' FROM nginx:alpine COPY nginx.conf /etc/nginx/nginx.conf COPY dist/ /usr/share/nginx/html/ EXPOSE 80 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD wget --quiet --tries=1 --spider http://localhost/ || exit 1 EOF cd ./nginx-build docker build -t my-vue-app . echo "=== 部署完成！镜像名：my-vue-app ==="

注意：这个方案巧妙地将前端的publicPath: '/api/'与 Nginx 的location /api/绑定，实现了“单域名、双职责”。用户访问https://myapp.railway.app/会被重定向到/api/，看到前端；访问https://myapp.railway.app/api/backend/users则被 Nginx 代理到后端。这完全规避了跨域问题，且符合 Railway 的单端口限制。Claude Code 的设计，体现了对“前端路由”、“后端 API”、“反向代理”三者边界与协作关系的深刻理解。

3.4 第三步：生成 Railwayrailway.toml配置与部署指令

Railway 的部署核心是railway.toml文件，它定义了服务、环境变量、构建触发等。我将项目结构和需求告诉 Claude Code：

“项目有两个服务：1）后端backend，Dockerfile 路径./backend/Dockerfile，需要环境变量SPRING_PROFILES_ACTIVE=prod和DATABASE_URL；2）前端frontend，Dockerfile 路径./frontend/Dockerfile，需要环境变量VUE_APP_API_BASE_URL=/api/backend/。请生成railway.toml文件，并说明如何在本地用railway up命令部署。”

它生成的railway.toml结构清晰，注释详尽：

# railway.toml - 定义 Railway 上的服务拓扑 [project] # 项目名称，将显示在 Railway 控制台 name = "spring-vue-demo" [[services]] # 后端服务定义 name = "backend" # 构建方式：Dockerfile type = "docker" # Dockerfile 路径（相对于项目根目录） dockerfilePath = "./backend/Dockerfile" # 构建上下文目录 buildContext = "./backend" # 暴露的端口（必须与 Dockerfile 中 EXPOSE 一致） port = 8080 # 环境变量 env = [ { key = "SPRING_PROFILES_ACTIVE", value = "prod" }, { key = "DATABASE_URL", value = "postgresql://user:pass@postgres:5432/mydb" }, ] [[services]] # 前端服务定义 name = "frontend" type = "docker" dockerfilePath = "./frontend/Dockerfile" buildContext = "./frontend" port = 80 # 前端需要知道 API 的相对路径 env = [ { key = "VUE_APP_API_BASE_URL", value = "/api/backend/" }, ] # 数据库服务（Railway 自动管理） [[services]] name = "postgres" type = "postgresql"

部署指令也一并给出：

# 1. 确保已登录 Railway CLI railway login # 2. 初始化项目（如果尚未关联） railway init # 3. 部署所有服务（会自动读取 railway.toml） railway up # 4. 查看部署日志 railway logs --service backend railway logs --service frontend

实操心得：railway up命令会自动检测railway.toml并按定义顺序部署服务。但要注意，postgres服务的连接字符串（DATABASE_URL）在部署后才会生成。因此，backend服务的DATABASE_URL环境变量，不能在railway.toml中硬编码，而应在 Railway 控制台的Environment Variables页面中，将backend服务的DATABASE_URL设置为{{ postgres.DATABASE_URL }}。Claude Code 生成的railway.toml是一个完美的起点，但最终的环境变量注入，需要人工在 UI 中完成这一“最后一步”。这是 AI 与人类协作的典型模式：AI 处理确定性、模式化的部分，人类处理需要上下文感知和权限决策的部分。

4. 关键细节深挖：那些 Claude Code 不会明说，但决定成败的“魔鬼”

4.1 Git 配置的致命陷阱：.gitignore与Dockerfile的战争

很多部署失败，根源不在 Docker 或 CI/CD，而在 Git 的.gitignore文件。Claude Code 无法看到你.gitignore里写了什么，但它生成的 Dockerfile 却极度依赖它。例如，我曾遇到一个案例：Claude Code 生成的 Dockerfile 中有COPY . /app，但pom.xml被.gitignore忽略了，导致mvn dependency:go-offline失败，因为找不到pom.xml。

解决方案是，在让 Claude Code 生成 Dockerfile 前，必须先检查.gitignore：

# 检查哪些关键文件被忽略 $ git check-ignore -v pom.xml $ git check-ignore -v src/main/resources/application-prod.yml $ git check-ignore -v package.json

如果关键构建文件被忽略，必须立即将其从.gitignore中移除，或改为显式!pom.xml。Claude Code 的 Dockerfile 逻辑是“复制所有源码”，它默认信任 Git 的索引是完整的。一旦这个前提被破坏，整个构建链就会崩塌。我在三个不同客户的项目中，都发现过.gitignore里错误地忽略了pom.xml或requirements.txt，这是比任何技术难题都更隐蔽、更致命的“配置即代码”缺陷。

4.2 Docker 镜像体积的隐形杀手：node_modules与target/的双重诅咒

前端node_modules和后端target/目录，是 Docker 镜像体积膨胀的两大元凶。Claude Code 生成的多阶段构建，能解决target/问题，但对node_modules无能为力，因为 Vue 项目通常需要在构建阶段（npm run build）才能生成dist/，而node_modules是构建的必要输入。

我的经验是，必须在Dockerfile中显式清理node_modules：

# 在构建阶段末尾，删除 node_modules 以减小最终镜像体积 RUN npm ci && npm run build && rm -rf node_modules

更激进的做法是，使用--no-cache模式：

# 使用 npm ci 替代 npm install，确保依赖树与 package-lock.json 严格一致 RUN npm ci --only=production && npm run build && rm -rf node_modules

npm ci比npm install更快、更可靠，因为它跳过package.json的解析，直接读取package-lock.json。Claude Code 知道npm ci的存在，但不会主动推荐，因为它需要你明确告知“追求构建速度与确定性”。这是一个典型的“AI 知道，但需要你点名”的场景。作为使用者，你必须了解自己项目的痛点（是构建慢？还是依赖不一致？），然后引导 AI 给出针对性方案。

4.3 Railway 环境变量的“作用域迷雾”：服务间通信的密钥

Railway 的环境变量系统，有严格的作用域规则。backend服务的DATABASE_URL，不能直接在frontend服务中通过process.env.DATABASE_URL访问，反之亦然。Claude Code 生成的railway.toml中，env字段只定义该服务自身的变量。

真正的服务间通信，依赖于 Railway 的服务发现机制。当你在railway.toml中定义了postgres服务，Railway 会自动为它生成一个 DNS 名称（如postgres-12345678.railway.internal），并将其注入到所有同项目服务的环境变量中，变量名为POSTGRES_URL。

因此，backend服务的DATABASE_URL，应该设置为{{ postgres.DATABASE_URL }}，而不是一个固定字符串。Claude Code 无法为你自动填写这个模板，因为它不知道你的服务名（postgres）是否与railway.toml中定义的一致。你需要做的是：

1. 在railway.toml中，确保数据库服务的name字段（如name = "postgres"）与你在env中引用的名称（{{ postgres.DATABASE_URL }}）完全一致。
2. 在 Railway 控制台，进入backend服务的Environment Variables页面，将DATABASE_URL的值设为{{ postgres.DATABASE_URL }}。

这个过程，是 Claude Code 生成的“蓝图”与 Railway 平台“运行时契约”之间的最后一公里。AI 提供了结构，平台提供了能力，而你，是那个把两者精准对齐的人。

4.4 健康检查（Healthcheck）的“假阳性”陷阱：Actuator 与 Nginx 的握手协议

Claude Code 生成的HEALTHCHECK指令，通常是可靠的，但有一个经典陷阱：Spring Boot Actuator 的/actuator/health端点，默认只对localhost开放。如果你的application-prod.yml中没有配置：

management: endpoints: web: exposure: include: health,info,metrics endpoint: health: show-details: when_authorized

那么curl http://localhost:8080/actuator/health在容器内会返回401 Unauthorized，导致健康检查失败，Railway 会认为服务宕机并不断重启。

解决方案是，在application-prod.yml中添加：

management: endpoints: web: exposure: include: health endpoint: health: show-details: always

show-details: always是关键，它让健康检查无需认证即可获取详细状态。Claude Code 不会主动修改你的application.yml，因为它不属于“部署”范畴，而是“应用配置”。但作为一个资深从业者，你必须意识到：部署的健壮性，始于应用自身的可观测性设计。AI 可以帮你生成检查命令，但无法替你决定应用是否愿意被检查。

5. 常见问题与排查技巧实录：从“部署失败”到“一键上线”的实战笔记

5.1 问题速查表：高频故障与秒级定位法

这张表，是我过去三个月在 12 个不同项目中踩坑、填坑、总结出来的精华。它不讲原理，只给最短路径的诊断命令和修复动作。当你深夜面对一个红彤彤的失败部署，这张表就是你的急救手册。

5.2 “为什么我的 Claude Code 不灵？”——提示词工程的终极心法

很多人抱怨“Claude Code 生成的代码根本跑不通”，问题往往不出在模型，而出在提示词（Prompt）的质量。我总结了一套“四象限提示词心法”，专治各种“不灵”：

• 第一象限：精准锚定（Precision Anchoring）
  错误示范：“帮我写个 Dockerfile。”
  正确示范：“我用 Spring Boot 3.2，pom.xml中<parent>的<version>是3.2.0，构建产物是target/app.jar，目标 OS 是 Ubuntu 22.04（Railway 默认），请生成Dockerfile。”
  心法：用具体、不可变的字符串（版本号、文件名、路径）作为锚点，框定模型的思考范围。

• 第二象限：显式约束（Explicit Constraint）
  错误示范：“怎么部署 Vue 项目？”
  正确示范：“vue.config.js中publicPath: '/api/'，outputDir: 'dist'，目标平台是 Railway，要求所有流量走 80 端口，前端静态文件由 Nginx 提供，API 由后端backend服务提供，请生成nginx.conf。”
  心法：把所有业务和技术约束（路径、端口、服务名、平台）一次性、无遗漏地列出。模型不怕多，就怕模糊。

• 第三象限：角色扮演（Role Prompting）
  错误示范：“给我一个部署方案。”
  正确示范：“你现在是一位有 10 年经验的 DevOps 工程师，专门为 SaaS 初创公司设计部署方案。你深知 Railway 的限制（单端口、服务发现机制），也熟悉 Spring Boot 和 Vue.js 的最佳实践。请为一个publicPath: '/api/'的 Vue 项目，设计一个零跨域、高可用的部署方案，并解释每一步的权衡。”
  心法：赋予模型一个专业、可信的角色，它会自动调用该角色的知识库和决策逻辑。

• 第四象限：迭代反馈（Iterative Refinement）
  错误示范：一次提问，接受结果。
  正确示范：第一次提问得到 Dockerfile → 本地docker build测试 → 发现curl缺失 → 第二次提问：“上一个 Dockerfile 中，