When the Boss Says “Let AI Do It”, Here’s the 7‑Stage SOP That Proves It’s Not a One‑Liner

In many legacy systems, managers often demand that AI solve any problem with a single sentence, assuming AI can instantly deliver flawless code. The reality is that AI is a powerful execution engine that needs a well‑defined, stable environment to operate reliably.

P0 – Requirement Clarification

The vague request “change scheduling rules across three fronts” must first be turned into a structured specification. The process starts with a brainstorming prompt to the AI:

我有一个需求，请先不要写代码。
使用 brainstorming 模式，对以下需求做结构化澄清：
[粘贴原始需求]

请输出：
1. 你的当前理解（3 句话内）
2. 本次做什么 / 不做什么
3. 受影响的系统清单（前端/后端/DB/第三方）
4. 你认为最关键的 3 个未决问题
5. 验收标准草稿

The AI returns a list such as:

Current understanding: new scheduling rules affect backend logic and frontend fields.

Do not recalculate prices or compensate historical orders.

Affected systems: vv-education-service, admin-web, student-app.

Open questions: data‑compatibility strategy, minimum app version, coexistence period for old and new rules.

Explicitly recording “what not to do” prevents scope creep when AI later rewrites code.

Step 2: Human answers the open questions, then asks AI to generate a full specification document (template shown in the source). This document is the only human‑review checkpoint before any code is produced.

Step 3: Create a persistent AI‑execution environment by adding an AGENTS.md (or CLAUDE.md) file at the repository root that lists project structure, start commands, test commands, and forbidden actions (e.g., editing .env, modifying domain interfaces without explicit tasks).

P1 – Impact‑Area Research

Instead of a single engineer guessing the impact, the main Agent dispatches parallel sub‑agents, each tasked with a bounded analysis (e.g., backend API impact). A sample sub‑agent prompt is:

你是后端影响面分析 Agent。只调研，不修改代码。
目标：分析"[需求名]"对后端接口的影响。
输出：
1. 相关 Controller / API 列表
2. 请求 DTO 和返回 VO 的当前字段
3. 关键 Service 调用链（精确到方法名）
4. 数据库表和字段
5. 当前逻辑摘要
6. 本次可能修改点
7. 兼容性风险（历史数据、老客户端）
8. 需要向产品或研发确认的问题

禁止：
- 不要改代码
- 不要提出无关重构
- 不要假设 PRD 未说明的业务规则

After all six agents finish, the main Agent aggregates the results into an impact‑matrix, listing each service, affected modules, change magnitude, compatibility risk, and pending questions.

P2 – Interaction Design & Architecture

The biggest deviation from traditional flow is that design now starts with UI prototypes, then derives backend contracts. The AI first generates interaction drafts, then produces two or more architecture alternatives, each containing:

File and service changes (exact filenames)

Database migration drafts

Legacy‑data default strategies

Compatibility plan for older app versions

Rollback procedure

Testing effort estimate

Risk level (high/medium/low)

A mandatory human decision point (P2 end) selects the final architecture, ensuring business judgment overrides AI‑only reasoning.

P3 – Task Planning

Each task is written to be completed within 30–90 minutes and fully self‑contained. An example task format:

## Task 3：接口返回字段兼容
目标：GET /api/courses/{id} 接口新增 scheduleRule 字段，保持旧字段不破坏。
修改文件：
- CourseController.java
- CourseDetailVO.java
- CourseService.java（仅添加字段映射）
前置条件：Task 2 必须已合并
实现步骤（TDD）：
1. 在 CourseControllerTest.java 写失败测试：assert response.body().scheduleRule != null
2. 运行测试，确认因字段缺失而失败
3. 在 CourseDetailVO 增加 scheduleRule 字段
4. 在 CourseService 增加字段映射逻辑
5. 运行定向测试：mvn test -Dtest=CourseControllerTest
6. 运行全量回归：mvn test
7. 自查 diff，确认没有超出范围的改动
提交说明：feat(course-api): add scheduleRule field to course detail response
风险：历史数据 scheduleRule 为 null，需确认前端是否处理 null 展示

Tasks are split across services using Git worktrees to avoid workspace conflicts.

P4 – Implementation & Debugging

Implementation agents follow a strict TDD workflow:

Write a failing test.

Run the test and capture the failure.

Write the minimal code to make the test pass.

Run the targeted test.

Run the full regression suite.

Output a diff summary and test results.

Forbidden actions include expanding the change scope, unrelated refactoring, or altering test expectations to hide failures. Systematic debugging is enforced by a matrix that records real commands and outcomes, preventing “guess‑work” fixes.

P5 – Verification

Every task ends with a verification matrix that logs actual commands and results, for example:

## 验证结果（Task 3：接口返回字段兼容）
### 后端
- 单元测试：`mvn test -Dtest=ScheduleRuleServiceTest` 结果：通过 42/42 ✅
- 接口测试：`mvn test -Dtest=CourseControllerTest` 结果：通过 18/18 ✅
- 全量测试：`mvn test` 结果：通过 523/523 ✅
- 构建：`mvn clean package` 结果：成功，无警告 ✅
### 前端
- 单元测试：`pnpm test` 结果：通过 31/31 ✅
- 类型检查：`pnpm typecheck` 结果：0 错误 ✅
- 构建：`pnpm build` 结果：成功 ✅
### 联调场景验证
- 创建新规则课程 → scheduleRule 字段返回正确值 ✅
- 查询历史课程 → scheduleRule 默认值 LEGACY，前端正常展示 ✅
- 老版本 App 请求 → 无未知字段崩溃 ✅
- 权限不足 → 403 正确返回 ✅
- 异常参数 → 400 参数校验错误 ✅
### ❌ 未验证
- 线上支付回调联调：缺少沙箱配置 → 已记录为后续任务前置条件

Unverified items must be recorded and addressed before the task is considered complete.

P6 – Delivery

Large multi‑service changes are split into small PRs, each described with a template covering background, change summary, affected services, API changes, compatibility notes, test results, release steps, and rollback plan. AI can also auto‑generate release notes, rollback SQL, post‑release monitoring checklists, and test scripts.

Metrics & Measurement

Instead of counting lines of AI‑generated code, teams should track DORA metrics:

Change lead time – shorter is better.

Deployment frequency – higher is better.

Change failure rate – lower is better.

MTTR – shorter is better.

AI‑specific process metrics include:

Requirement‑clarification time (shorter indicates clearer specs).

Effective issues found by AI review.

Average PR review cycles.

Number of production defects.

DORA warns against turning these metrics into rigid KPIs, which can lead to gaming the system rather than genuine quality improvement.

Conclusion

The SOP shows that a single “let AI do it” sentence can trigger a comprehensive, auditable pipeline, but the pipeline itself requires infrastructure, structured specs, parallel research, design, planning, TDD, systematic debugging, dual‑review, verification, and disciplined delivery. Human judgment remains essential for business decisions and final acceptance.