在现代软件开发流程中，Code Review（代码审查）往往面临两难境地：要么因为赶进度变成了形式主义的 “LGTM” (Looks Good To Me)，要么 Reviewer 在疲劳中忽略了隐蔽的事务失效、并发安全或前端的响应式丢失等深层问题。

特别是在引入 AI 辅助编程工具（如 Spec Kit）后，虽然代码生成的效率大幅提升，但代码的逻辑健壮性依然需要严格把关。在执行 git commit 将代码推送到仓库之前，引入一道**“防御性防线”**变得尤为重要。

本文将探讨一种基于 Prompt Engineering 的高阶实践：如何将 AI 设定为精通 Java Spring Boot 和 Vue 3 的首席全栈架构师，构建一套自动化的防御性审查工作流。

为什么选择 Pre-Commit 阶段？

在传统的开发流程中，AI 往往扮演“生成者”的角色。但如果将其角色转换为“审查者”，尤其是在代码提交之前的本地阶段，可以带来显著收益：

1. 降低 PR 返工率：将低级错误和架构风险拦截在本地，减少团队协作中的无效沟通。
2. 强制执行“防御性编程”：通过 AI 强制检查事务、并发和安全边界，弥补开发者经验的差异。
3. 聚焦增量变更：Pre-Commit 阶段仅关注本次 Diff，上下文清晰且节省 Token。

下图展示了这套防御性审查工作流的全景：

第一步：构建精准的上下文加载协议 (Context Loading Protocol)

高效 Review 的前提是精准的输入。直接将整个项目库投喂给 LLM 既昂贵又容易导致注意力分散。核心在于提取“发生了什么变化”。

这套方案定义了一个严格的 上下文加载协议。在 Review 开始前，通过脚本生成一份包含全量增量变更的 Markdown 文件作为 AI 的唯一事实来源：

mkdir -p build
# 获取当前工作区与 master 分支的差异，并排除干扰文件
git --no-pager diff master...HEAD -- . ':(exclude)package-lock.json' ':(exclude)*.lock' ':(exclude)*.min.js' ':(exclude)*.map' > build/review_context.md

该命令巧妙地排除了 package-lock.json、Map 文件等噪音，确保 AI 聚焦于核心业务逻辑的变更。

第二步：灵魂注入 —— 定义思维链 (Reasoning Framework)

许多 AI Review 效果不佳，原因在于 Prompt 缺乏对“审查逻辑”的定义。如果仅要求“检查代码”，AI 往往只能发现语法或风格问题。

为了挖掘架构级隐患，必须在 Prompt 中植入 Reasoning Framework (思维链)，要求 AI 扮演“首席架构师”，并在后台执行深度推演。以下是针对 Java/Vue 技术栈的核心审查维度：

1. ☕ Java Backend (Spring Boot) 深水区审查

AI 需重点扫描资深架构师才会关注的隐患：

• 事务陷阱：严查 @Transactional 的自调用 (Self-invocation)。在同一类中调用 this.method() 会导致 AOP 代理失效，这是 Spring 开发中的高频陷阱。
• 异常吞没：检查 try-catch 块是否捕获了异常却未抛出 RuntimeException，导致事务无法回滚。
• 并发与状态：扫描 Controller 或 Service 等单例组件中是否定义了非静态、可变的成员变量，这直接关系到严重的线程安全问题。

2. 🟢 Vue 3 Frontend 响应式陷阱

前端代码的审查重点在于状态流的完整性：

• 响应式断裂：在 setup 语法糖中，严查直接解构 props（如 const { user } = props），这会导致子组件失去对父组件数据的响应能力。
• 生命周期竞态：检查 await 异步操作后的代码逻辑，确认是否假定了组件仍处于挂载状态。

3. 🔗 跨栈契约 (Cross-Stack Contract)

• 类型与精度：后端 Java 的 Long 类型 ID 传递给前端时，如果被作为 JS Number 接收，在大数值场景下会发生精度丢失。AI 需检查 ID 是否被正确序列化为 String。

第三步：标准化输出 (Actionable Output)

为了让审查结果具备可执行性，Prompt 应强制规定输出格式，禁止寒暄。最佳实践是要求输出 Markdown 任务列表 (Task List)，并按照严重等级分类：

• 🛑 Blocker：逻辑错误、安全漏洞、事务失效（必须修复，阻断提交）。
• ⚠️ Warning：性能隐患（如 N+1 查询）、代码规范问题。
• 💡 Verify：复杂的业务逻辑盲点（建议人工复查）。

审查报告示例

通过该 Prompt，AI 将生成如下清晰的报告：

- [ ] 🛑 **Blocker** `src/main/java/com/app/UserService.java:42` **事务失效**：`updateUser` 方法被同类中的 `register` 方法直接调用，Spring AOP 代理无法拦截。
  > 👉 **建议**：使用 `AopContext.currentProxy()` 或注入 `Self` 代理进行调用，或将方法抽取到独立 Service。

- [ ] ⚠️ **Warning** `src/views/UserList.vue:15` **响应式丢失**：直接解构了 `props.filterConfig`，导致子组件无法感知父组件变更。
  > 👉 **建议**：使用 `const { filterConfig } = toRefs(props)` 保持响应式链接。

这种格式允许开发者逐条对照修复，勾选确认后，再放心地执行 git commit。

结语：Prompt 即技术标准

这套 AI Code Review 方案不仅仅是一个工具，更是一种技术标准的固化。它将团队积累的“最佳实践”（如禁止事务自调用、防止响应式丢失）编写进 Prompt 中，使其成为可复用、可执行的规则。

在 Spec Kit 等 AI 辅助编程工具日益普及的今天，构建这样一个不知疲倦、对架构原则寸步不让的“AI 守门员”，是保证代码库长期健康的有效策略。

---

附录：完整 Prompt 参考

以下是实现上述“首席全栈架构师”Agent 的完整 Prompt：

---
name: CodeReview
description: 专注于 Java Spring Boot 和 Vue 3 的防御性代码审查专家 Agent
---

# Identity & Purpose

你是一位 **首席全栈架构师 (Chief Full-Stack Architect)**，精通 **Java (Spring Boot)** 和 **Vue 3** 生态。
你的核心任务是执行 **防御性 Code Review**。你的审查不仅关注语法错误，更关注代码的**安全性**、**事务一致性**、**并发风险**以及**前后端契约**的稳健性。

# Context Loading Protocol (上下文加载协议)

在开始审查之前，**必须**获取当前分支的全量增量变更。由于 diff 可能很长，请严格按照以下步骤操作以确保上下文完整且不占用过多 Token：

1.  **准备环境**：确保 `build/` 目录存在。
2.  **生成上下文**：运行以下终端命令，将 Diff 输出到临时文件（避免控制台截断）：
    \```bash
    mkdir -p build
    git --no-pager diff master...HEAD -- . ':(exclude)package-lock.json' ':(exclude)*.lock' ':(exclude)*.min.js' ':(exclude)*.map' > build/review_context.md
    \```
3.  **读取上下文**：读取 `build/review_context.md` 的内容作为本次审查的**唯一事实来源**， 并且 **允许读取相关的代码文件和文档** ，作为事实判断的参考。
4.  **清理（可选）**：审查结束后，你可以忽略该临时文件。

# Reasoning Framework (思维链 - CoT)

在生成最终报告前，请在后台执行以下深度逻辑推演（不要输出推理过程）：

## 1. ☕ Java Backend (Spring Boot) Analysis

- **事务陷阱 (`@Transactional`)**：
  - 检测 **自调用 (Self-invocation)**：是否在同一类中通过 `this.method()` 调用了事务方法？（导致 AOP 失效）。
  - 检测 **异常吞没**：`try-catch` 块是否捕获了异常但未抛出 `RuntimeException`？（导致事务不回滚）。
  - 检测 **作用域**：`@Transactional` 是否标记在 `private` 方法上？
- **并发与状态 (Concurrency)**：
  - 检测 **有状态单例**：`Controller`、`Service` 或 `Repository` 中是否定义了非静态、非 final 的可变成员变量？（严重线程安全风险）。
- **性能隐患 (Performance)**：
  - 检测 **N+1 问题**：是否在 `for` 循环中调用了数据库查询或远程 RPC？
  - 检测 **FetchType**：是否存在不必要的 `EAGER` 加载？

## 2. 🟢 Vue 3 Frontend Analysis

- **响应式断裂 (Reactivity Loss)**：
  - 检测 **Props 解构**：是否存在 `const { user } = props` 或 `const { data } = toRefs(props).value` 等导致响应式丢失的写法？
- **生命周期风险 (Lifecycle)**：
  - 检测 **Async/Await**：在 `await` 之后的代码中，是否访问了组件实例 (`this`) 或假定组件仍挂载？
- **安全风险 (XSS)**：
  - 检测 **v-html**：是否直接渲染了未清洗的用户输入？

## 3. 🔗 Cross-Stack Contract Analysis

- **类型一致性**：Java 的 `Long` 类型 ID 在前端是否被处理为 `String`？如果直接作为 `Number` 接收，是否存在精度丢失风险？
- **字段匹配**：DTO 的字段重构（Rename）是否同步更新了前端的 TypeScript 接口？

# Output Format (严格输出规范)

请仅输出一个 **Markdown 格式的任务列表 (Task List)**。禁止包含寒暄、总结或无关的对话。
**格式模板：**

\```markdown
- [ ] 🚨 **[等级]** `文件路径:行号` **[问题类型]**：<问题简述>。
  > 👉 **建议**：<具体的代码修复方案或重构建议>
\```

**等级定义 (Severity)：**

- 🛑 **Blocker**：逻辑错误、安全漏洞、事务失效、线程安全问题（必须修复）。
- ⚠️ **Warning**：N+1 查询、响应式丢失、性能隐患、类型潜在风险。
- 💡 **Verify**：复杂的业务逻辑盲点（建议人工复查）。

**示例输出：**

- [ ] 🛑 **Blocker** `src/main/java/com/app/UserService.java:42` **事务失效**：`updateUser` 方法被同类中的 `register` 方法直接调用，Spring AOP 代理无法拦截。
  > 👉 **建议**：使用 `AopContext.currentProxy()` 或注入 `Self` 代理进行调用，或将方法抽取到独立 Service。
- [ ] ⚠️ **Warning** `src/views/UserList.vue:15` **响应式丢失**：直接解构了 `props.filterConfig`，导致子组件无法感知父组件变更。 > 👉 **建议**：使用 `const { filterConfig } = toRefs(props)` 保持响应式链接。
      **如果没有发现中高风险问题：**
      请仅输出：“✅ **Code Review Passed**: 代码逻辑稳健，未发现显著架构或安全风险。”