用 Claude Code、Skill 和 MCP 重构后台开发全流程

后台开发不是只写代码。从一个需求开始，到最终合入发布，中间通常要跨过很多系统：

• 在 PM 平台（需求管理平台）看需求、补描述、关联任务；
• 在 Git 平台建分支、提交代码、创建 Merge Request（合并请求，MR）；
• 在编辑器里读代码、改代码、跑测试；
• 在 DevOps（开发运维一体化）平台编译、部署、发布；
• 在日志平台查错误、看 trace、定位问题；
• 在 MR 页面处理评审意见，再提交修复。

这些动作本身不一定复杂，但它们不断打断上下文。刚看完需求细节，切到代码里要重新回忆；部署完测试环境去查日志，又要想刚才改了哪些路径；写 MR 描述时，还得从 commit 和 diff 里重新整理变更说明。

Vibe Coding 解决了一部分问题：把需求告诉 AI，让它直接生成代码。它适合快速验证想法，但离生产级后台开发还有距离。生产环境不只关心“代码能不能跑”，还关心需求是否理解准确、变更范围是否可控、提交是否规范、评审是否充分、部署是否安全、线上问题能否追踪。

Agentic Engineering（智能体工程）的思路更适合工程化场景：开发者定义目标、边界、约束和质量标准，AI 作为智能体在结构化流程中完成规划、编码、测试、提交、部署和修复。关键节点仍由人审核，AI 不再是“随便生成代码的聊天框”，而是被放进一套有纪律的开发流水线里。

Vibe Coding 和 Agentic Engineering 的差别

两者都使用大模型，但工作方式完全不同。

可以把 Vibe Coding 理解为“让 AI 写代码”，把 Agentic Engineering 理解为“让 AI 在工程流程里完成任务”。

真正的变化不在于模型多聪明，而在于流程是否能约束模型：先澄清需求，再制定计划，再按任务执行，再自审，再部署验证，再创建 MR，再处理评审意见。AI 的自由度被限制在每个阶段的职责内，开发者只在需要判断的位置介入。

整体架构：Skill、Command 和 MCP

一套可落地的 Agentic Engineering 工具链通常可以拆成三层。

三层之间的关系可以画成这样：

flowchart TB
    User[开发者] --> Claude[Claude Code 终端会话]

    Claude --> Commands[Command 斜杠命令]
    Claude --> Skills[Skill 技能库]

    Commands --> GitWorkflow[git-workflow]
    Commands --> PMDev[pm-dev]
    Commands --> CodeReview[code-review]
    Commands --> DTools[dtools]

    Skills --> PMDev
    Skills --> GitWorkflow
    Skills --> CodeReview
    Skills --> DTools
    Skills --> Galileo[galileo-log-query]
    Skills --> GitContext[git-context]
    Skills --> Wiki[wiki-doc]

    PMDev --> Superpowers[Superpowers 结构化流程]
    Superpowers --> Brainstorming[brainstorming]
    Superpowers --> WritingPlans[writing-plans]
    Superpowers --> ExecutingPlans[executing-plans]

    GitWorkflow --> GitContext

    PMDev --> PMMCP[PM MCP]
    GitWorkflow --> GitMCP[GitPlatform MCP]
    GitContext --> GitMCP
    Galileo --> GalileoMCP[Galileo MCP]
    Wiki --> WikiMCP[InternalWiki / KnowledgeBase MCP]

    PMMCP --> PM[需求管理平台]
    GitMCP --> Git[Git 平台 / MR]
    GalileoMCP --> Logs[日志平台]
    WikiMCP --> Docs[知识库 / Wiki]

这里有几个重要设计点：

1. Command 要薄
   /commit、/create-mr、/review-mr 这类命令不应该塞太多逻辑。它们更像入口，把任务委托给 git-workflow 中的对应模块。这样用户说“帮我提交代码”时，也可以通过上下文触发相同流程。

2. Skill 要可组合
   pm-dev 创建需求和分支后，可以自动衔接 brainstorming；需求澄清完成后，再进入 writing-plans。多个 Skill 组合起来，比在一个大 Skill 里重复实现所有逻辑更容易维护。

3. MCP 对使用者透明
   使用者不需要关心“调用哪个 API 创建 MR”。Skill 通过 MCP 完成外部平台操作，终端里只展示可审核的结果，例如 MR 标题、描述、链接和状态。

4. 结构化流程负责约束 AI
   brainstorming 强制先理解需求；writing-plans 强制先写计划；executing-plans 强制按任务执行；code-review 强制按检查清单审查。流程越清晰，AI 越不容易跳步。

从需求到发布的完整流水线

以一个后台接口小变更为例：

RedeemReward 接口的数据上报逻辑需要调整：无论领取成功还是失败，都要上报结果；上报结构新增 errcode 和 errmsg 字段；新字段来自 git.example.com/org/component/report_data/reportstruct 的 Go module 依赖升级。

这类需求体量适中，既有依赖升级，又有结构体扩展和业务逻辑重构，足够展示完整流程。

整体流水线如下：

flowchart LR
    A[口述需求或提供 PM URL] --> B[创建需求单]
    B --> C[创建开发分支]
    C --> D[需求澄清]
    D --> E[生成实施计划]
    E --> F[按 Task 编码]
    F --> G[自动 Commit]
    G --> H[代码自审]
    H --> I[部署测试环境]
    I --> J[日志验证]
    J --> K[创建 MR]
    K --> L[AI 辅助评审]
    L --> M[修复评审意见]
    M --> N[人工合入与灰度发布]

各阶段的职责可以压缩成一张表：

阶段 1：需求创建与分支初始化

pm-dev 负责把“需求入口”变成“可开发状态”。它支持两种使用方式：

• 提供 PM URL：自动解析需求 ID，拉取需求标题和正文；
• 不提供 PM URL：先进入需求澄清，再通过 PM MCP 自动创建需求单。

没有现成需求单时，可以直接在终端输入：

/pm-dev RedeemReward
接口里的数据上报逻辑变更，无论领取是否成功，都要上报结果
上报数据新增 errcode、errmsg 字段。
新字段需要更新 git.example.com/org/component/report_data/reportstruct 的 go mod 依赖。

pm-dev 检测到当前在 master 分支，并且输入里没有 PM URL，就会要求选择是否创建新需求单。需求澄清完成后，它会调用 PM MCP 创建需求：

pm - stories_create
workspace_id: "12345678"
name: "RedeemReward 上报逻辑变更新增错误码"
description: "RedeemReward 接口的数据上报逻辑变更：无论领取是否成功，都要上报结果..."

✅ 需求单创建成功
- 标题: RedeemReward 上报逻辑变更新增错误码
- 链接: https://pm.example.com/pm_fe/12345678/story/detail/1012345678001958011

随后自动创建开发分支，并把需求内容保存到仓库里：

git checkout -b feature/alice_131900001

Write(docs/pm/131900001.md)  # 保存需求文档

这一阶段的输出不是一段代码，而是一组工程上下文：

口述需求
  → PM 需求单
  → 规范命名的开发分支
  → docs/pm/ 下的需求文档
  → 后续澄清与计划流程

如果已经有 PM 链接，入口更简单：

/pm-dev https://pm.example.com/xxx/story/detail/1012345678001958011

pm-dev 会自动拉取需求详情，并用需求 ID 初始化分支。

ID 转换这类隐性规则要加校验

在很多内部平台里，URL 里的长 ID 和分支命名使用的短 ID 不是同一个字段。PM MCP 如果只支持长 ID，而分支或特性配置需要 short_id，AI 可能会根据已有样本推断两者之间的转换关系。

这种能力很有用，但不能直接把推断结果当作稳定规则写死。更稳妥的做法是：

1. 先根据样本推断；
2. 再通过平台接口或已有需求数据验证；
3. 验证失败时退回人工确认；
4. 把转换逻辑封装在 Skill 内部，避免散落在多个命令中。

AI 可以发现人不容易注意到的模式，但工程系统必须给推断结果加上验证和 fallback。

阶段 2：交互式需求澄清

需求描述只有一句话时，直接写代码风险很高。brainstorming 的职责是让 AI 先读代码，再问问题，最后形成双方确认过的设计方案。

这一阶段通常会做三件事：

flowchart TD
    A[读取需求描述] --> B[探索代码库]
    B --> C[定位接口和现有上报逻辑]
    C --> D[提出关键澄清问题]
    D --> E[给出可选方案]
    E --> F[人工选择方案]
    F --> G[生成设计方案]

对于 RedeemReward 的例子，AI 会先查找接口实现和上报函数：

Explore(探索 RedeemReward 和上报逻辑)
Done (20 tool uses · 93.8k tokens · 56s)

读完代码后，它会提出真正影响实现方式的问题：

新增的 errcode/errmsg 字段是加到现有的 Report_table_001 上，
还是使用新的上报表？

确认复用原有上报表后，AI 可以给出两种方案：

对于“无论成功失败都要上报”的需求，统一上报更合适。它把“保证执行”变成结构性约束，而不是靠每个分支都记得调用一次上报函数。

最终设计方案可以整理为：

1. 数据结构变更
   CardReportParam 新增 ErrCode / ErrMsg 字段。

2. RedeemReward 流程变更
   调整错误处理路径，确保成功和失败都会进入上报逻辑。

3. 依赖变更
   升级 report_data 依赖版本，获取 Report_table_001 的新字段。

4. 变更文件
   - go.mod / go.sum
   - repo/report/card_report.go
   - logic/redeem_reward.go

这个阶段的关键不是“AI 问了几个问题”，而是它把代码现状、需求边界和实现方案对齐了。没有这个对齐，后面的自动编码越快，偏离目标也越快。

阶段 3：制定实施计划

writing-plans 负责把设计方案变成可执行任务。一个合格计划必须具体到文件、函数、字段、验证方式，而不是停留在“修改上报逻辑”这种宽泛描述上。

计划生成前，AI 需要继续深入读代码：

Read:
- repo/report/card_report.go
- logic/redeem_reward.go
- errs 包
- go.mod / go.sum

检查:
- CardReportParam 当前字段
- ReportCard 当前入参和填充逻辑
- RedeemReward 当前错误处理路径
- report_data 当前版本是否包含 errcode/errmsg

生成的实施计划可以拆成 4 个 Task：

计划需要保存到仓库中，例如：

docs/plans/2026-03-03-redeem-reward-report-errcode.md

计划文件本身也应该提交。原因很简单：计划是 AI 后续执行的依据，也是人工审核的第一道关卡。开发者要在这一刻确认三件事：

1. 任务拆分是否合理；
2. 文件路径和函数名是否准确；
3. 验证标准是否覆盖核心风险。

计划阶段不能省。AI 可能漏掉边界情况，也可能误判某个依赖版本的字段。越早发现，修正成本越低。

阶段 4：并行执行开发任务

executing-plans 负责执行计划。常见有两种模式：

对于依赖升级、参数扩展、业务逻辑重构这类任务，可以使用子 Agent 模式：

选择执行方式：Subagent-Driven

执行过程可以表示为：

flowchart TB
    Plan[实施计划] --> T1[Task 1 升级依赖]
    Plan --> T2[Task 2 扩展 CardReportParam]
    Plan --> T3[Task 3 重构 RedeemReward]
    Plan --> T4[Task 4 构建与检查]

    T1 --> R1[Spec Review]
    T2 --> R2[Spec Review]
    T3 --> R3[Spec Review + Code Quality Review]
    T4 --> R4[Build / Vet]

    R1 --> Commit1[Commit 1]
    R2 --> Commit2[Commit 2]
    R3 --> Commit3[Commit 3]
    R4 --> Done[完成]

每个 Task 结束后，AI 会根据 diff 生成规范提交信息。/commit 可以分析 git diff --cached，生成 Conventional Commits 格式的 commit message：

d81eaee chore: upgrade report_data for new errcode/errmsg fields
18a0975 feat: add ErrCode/ErrMsg to CardReportParam and ReportCard
e978e6b feat: report RedeemReward result regardless of success or failure

Conventional Commits 的好处是清晰表达变更类型：

这一阶段的输出应该是多个原子提交，而不是一个巨大的混合 commit。原子提交越清楚，MR 描述、代码评审和回滚都越容易。

最终变更文件通常类似这样：

go.mod / go.sum
  - report_data v1.0.180 → v1.0.182

repo/report/card_report.go
  - CardReportParam 新增 ErrCode / ErrMsg
  - ReportCard 填充 Errcode / Errmsg

logic/redeem_reward.go
  - RedeemReward 成功失败都上报
  - 上报参数携带 errcode / errmsg

阶段 5：代码自审

代码完成后，不要急着提 MR。code-review 可以先对当前分支相对主干的 diff 做一次自审。

输入可以很自然：

审查一下当前分支相对 master 的代码变更

AI 会获取 diff：

git diff master...HEAD

然后按检查清单输出报告。一个适合 Go 后台项目的检查维度可以这样设计：

示例审查结果：

审查报告：
Critical: 0
Major: 0
Minor: 1
Suggestion: 1

M1. [CR-可读性] ChannelID 魔法数字缺少注释
文件: logic/redeem_reward.go:43
问题: ChannelID: 3 缺少含义说明
建议: 添加行内注释或提取为命名常量

S1. [CR-编程规范] Errcode/Errmsg 字段缩进不一致
文件: repo/report/card_report.go:57-58
建议: 使用 gofmt 标准对齐

报告可以保存到：

docs/code-review-report-20260303-153022.md

自审阶段有三个处理方式：

实际开发中，格式、命名、注释、低风险规范类问题最好在自审阶段直接修掉。MR reviewer 的注意力应该花在设计、逻辑和边界条件上，而不是缩进和注释。

阶段 6：编译部署到测试环境

dtools 用来接入 DevOps CLI（命令行工具）和测试环境部署流程。它应该能自动探测以下信息：

• APP
• SERVER
• ENV
• INSTANCE
• 当前用户
• 构建产物路径
• 发布模式

常见探测顺序可以是：

flowchart LR
    A[Makefile] -->|找到配置| D[确认部署参数]
    A -->|缺失| B[go.mod]
    B -->|缺失| C[trpcprotocol 路径]
    C --> D
    D --> E[交叉编译]
    E --> F[dtools 发布]

触发方式：

/dtools

确认参数：

APP=my_app
SERVER=reward_service
ENV=pre
USER=alice

选择发布方式：指定实例发布

Mac 本地编译 Linux 服务时，需要交叉编译：

CGO_ENABLED=0 GOOS=linux GOARCH=amd64 \
go build -v -o .build/reward_service

然后执行发布：

dtools bpatch \
  -env pre \
  -app my_app \
  -server reward_service \
  -bin .build/reward_service \
  -user alice \
  -instances "pre.my_app.reward_service.instance001"

部署自动化不只是少打一条命令。更有价值的是上下文联动：如果 Makefile 里的实例名已经过期，AI 可以调用 dtools node ls 查询当前可用实例，确认后完成发布，并顺手修正仓库里的过期配置。

这种“发现配置漂移并修正”的能力，在后台服务日常维护中很实用。

阶段 7：日志排查与调试

部署完成后，需要验证上报是否符合预期。galileo-log-query 负责接入 Galileo 日志查询平台，可以按以下条件查日志：

• target，例如 BG-PLATFORM.{appid}.{server}；
• namespace；
• 时间范围；
• trace ID；
• 关键词；
• 日志级别；
• 查询语句。

触发方式可以是自然语言：

帮我查一下 pre 环境 reward_service 最近 10 分钟的 error 日志

AI 会自动探测 appid 和 server，然后调用日志查询 API。为了避免把大量日志塞进上下文，默认应该限制结果数量，例如 limit 50，并建议先用 level:error 缩小范围。

一次典型排查输出：

问题定位：
- redeem_reward.go:48 上报时 cfg 为 nil
- 原因：获取配置失败的路径没有正确传入默认值
- 建议修复：cfg == nil 时使用空 config，不能跳过上报

日志排查的价值在于把“日志内容”和“代码上下文”放在同一个会话里。AI 不只是帮忙搜索日志，还能把日志行映射回代码路径和可能的错误分支。

不过，这一阶段通常还不能完全自动化。AI 未必知道如何构造完整业务调用链，也未必有权限触发上下游请求。更稳妥的方式是人工触发测试请求，AI 负责查日志、聚合上下文和分析原因。

如果服务提供内部测试入口，后续可以让 AI 直接发 tRPC 请求触发模拟调用。tRPC 是腾讯开源的一套远程过程调用框架，很多 Go 后台服务会基于它组织接口和通信。

阶段 8：创建 Merge Request

测试通过后，可以用 /create-mr 创建 MR。它属于 Command，但实际工作由 git-workflow 的 push-mr 模块完成。

完整流程如下：

sequenceDiagram
    participant Dev as 开发者
    participant Claude as Claude Code
    participant GitCtx as git-context
    participant PM as PM MCP
    participant Git as GitPlatform MCP

    Dev->>Claude: /create-mr
    Claude->>GitCtx: 解析 project_id、分支、工作区状态
    GitCtx-->>Claude: 项目上下文
    Claude->>PM: 根据分支 short_id 拉取需求标题
    PM-->>Claude: 需求信息
    Claude->>Claude: 分析 commit 和 diff，生成 MR 标题/描述
    Claude-->>Dev: 展示预览
    Dev->>Claude: 确认
    Claude->>Git: push 分支并创建 MR
    Git-->>Claude: 返回 MR 链接和状态

AI 会从分支名提取需求 ID：

feature/alice_131900001 → story ID: 131900001

再通过 PM MCP 获取需求标题，组装源码关键字：

--story=131900001 RedeemReward 上报逻辑变更新增错误码

MR 描述可以自动生成：

--story=131900001 RedeemReward 上报逻辑变更新增错误码

## 变更说明

- 升级 report_data v1.0.180 → v1.0.182，获取 Report_table_001 新增的 errcode/errmsg 字段
- CardReportParam 新增 ErrCode/ErrMsg 字段，ReportCard 填充到上报结构体
- RedeemReward 接口无论领取成功或失败都执行数据上报，传入错误码和错误信息
- 获取配置失败时也上报，cfg 为 nil 时做安全处理

## 影响范围

仅影响 RedeemReward 接口的数据上报逻辑。
其他接口的 ReportCard 调用不受影响，ErrCode/ErrMsg 使用零值。

确认后执行：

git push -u origin feature/alice_131900001

并通过 GitPlatform MCP 创建 MR：

✅ MR 创建成功
- 链接: https://git.example.com/.../reward_service/-/merge_requests/64
- 状态: can_be_merged
- 必要评审人: bob, charlie

自动生成 MR 描述能减少很多重复劳动。更重要的是，它基于 commit 和 diff 生成，通常比手写描述更完整，也不容易漏掉依赖升级和影响范围。

阶段 9：AI 辅助代码评审

/review-mr 用来辅助 reviewer 审查 MR。它不是替代 reviewer，而是做初筛、定位和生成候选评论。

输入 MR 链接：

/review-mr https://git.example.com/org/team/project/backend/reward_service/-/merge_requests/64

工作流程：

flowchart TD
    A[输入 MR URL] --> B[git-context 定位 MR]
    B --> C[拉取 MR 元数据和 diff]
    C --> D[加载 code-review 检查标准]
    D --> E[只审查新增和修改行]
    E --> F[读取源分支文件验证行号]
    F --> G[生成评审意见]
    G --> H[人工审核]
    H --> I[提交行级评论到 GitPlatform]

AI 需要特别注意两件事：

1. 只审查本次变更引入的问题
   如果发现某个函数名不准确，但它在 master 上已经存在，就不应该把它当作当前 MR 的问题。否则 reviewer 会把历史债务都压到当前提交者身上。

2. 提交评论前校验行号
   行级评论最怕定位错行。提交前应使用类似下面的方式读取源分支文件，确认评论位置准确：

git show feature/alice_131900001:logic/redeem_reward.go

示例评审结果：

变更文件：
- repo/report/card_report.go (+4 行)
- logic/redeem_reward.go (+17 -11 行)
- go.mod (+1 -1)
- go.sum (+2 -2)

逻辑评估：
- 无论成功失败都上报，符合需求
- cfg 为 nil 时做了安全处理
- errs.Code(nil) / errs.Msg(nil) 返回 0 / ""，符合框架行为
- 依赖升级合理

发现问题：
M1. repo/report/card_report.go:57-58
Errcode/Errmsg 字段赋值缩进与上方字段不一致

S1. logic/redeem_reward.go:43
ChannelID: 3 是魔法数字，原有注释被删除，建议补回说明

确认后，可以选择提交评论范围：

提交 Minor + Suggestion，共 2 条

GitPlatform MCP 会创建 MR 行级评论：

create_merge_request_note
✅ M1 → repo/report/card_report.go:57
✅ S1 → logic/redeem_reward.go:43

AI 评审有明显价值：它能快速发现格式、边界、资源释放、并发、错误处理这类问题，并附带修复建议。它也有局限：可能误判业务意图，可能把刻意的空实现当成未完成代码，也可能把正确错误处理标成缺少检查。

所以 reviewer 必须逐条审核 AI 给出的意见。靠谱的提交，不靠谱的丢掉。

跨模型审查能减少盲区

一个实用策略是：谁写代码，就尽量让别的模型来审。

同一个模型写的代码再让它自己审，容易延续同样的思维盲区。Claude 写的代码可以让 Codex 或 Gemini 审；Codex 写的代码可以让 Claude 审。不同模型关注点不同，交叉审查更容易发现遗漏。

阶段 10：修复 MR 评审意见

/fix-mr 负责处理未解决评论。它会自动定位当前分支关联的 MR，拉取评论，分析上下文，生成修复方案，确认后修改代码。

流程如下：

sequenceDiagram
    participant Dev as 开发者
    participant Claude as Claude Code
    participant Git as GitPlatform MCP
    participant Repo as 本地仓库

    Dev->>Claude: /fix-mr
    Claude->>Git: 查询当前分支关联 MR
    Git-->>Claude: MR 元数据
    Claude->>Git: 拉取未解决评论
    Git-->>Claude: 评论列表
    Claude->>Repo: 读取对应文件和上下文
    Claude-->>Dev: 展示修复方案
    Dev->>Claude: 确认全部修复
    Claude->>Repo: 修改代码、gofmt、go build
    Claude->>Git: 回复评论并推送修复提交

示例评论：

[1] logic/redeem_reward.go:43
评论内容: [Suggestion] ChannelID 魔法数字 3 缺少注释说明
修复方案: 添加注释 "// 发放场景，3-会员页"

[2] repo/report/card_report.go:59-60
评论内容: [Minor] Errcode/Errmsg 字段赋值缩进不一致
修复方案: 使用 gofmt 标准对齐

确认后自动修改：

- ChannelID: 3,
+ ChannelID: 3, // 发放场景，3-会员页

- Errcode:    cast.ToString(param.ErrCode),
- Errmsg:     param.ErrMsg,
+ Errcode:     cast.ToString(param.ErrCode),
+ Errmsg:      param.ErrMsg,

修复后执行验证：

gofmt -w repo/report/card_report.go logic/redeem_reward.go
go build ./...

再提交：

fix: address CR comments for RedeemReward report changes

- 为 ChannelID 魔法数字 3 补充注释说明
- 修正 Errcode/Errmsg 字段缩进

这一步把“看评论 → 找文件 → 改代码 → 编译 → commit → push → 回复评论”串进同一个终端会话，减少了很多机械操作。

阶段 11：合入与发布

合入主干和线上发布仍应由人工控制。原因很明确：这一步涉及线上风险、灰度策略、回滚预案和业务窗口，不能只根据代码层面的判断自动执行。

推荐边界是：

合入后的 CI/CD（持续集成/持续交付）流水线可以继续自动完成：

flowchart LR
    A[Merge 到主干] --> B[触发 CI]
    B --> C[编译]
    C --> D[构建镜像]
    D --> E[推送镜像仓库]
    E --> F[人工确认灰度]
    F --> G[现网发布]

AI 可以提供发布检查清单、变更摘要和回滚建议，但最终按钮应由人来点。

工具速查表

MCP 服务如何配置进体系

MCP Server 是 Skill 操作外部系统的桥。常见配置如下：

全局配置目录可以按这种结构组织：

~/.claude-internal/
├── CLAUDE.md
├── settings.json
├── commands/
│   ├── commit.md
│   ├── create-mr.md
│   ├── review-mr.md
│   └── fix-mr.md
└── skills/
    ├── pm-dev/
    ├── git-workflow/
    ├── git-context/
    ├── code-review/
    ├── dtools/
    ├── galileo-log-query/
    ├── wiki-doc/
    └── service-analyzer/

各文件的职责建议保持清晰：

权限白名单要收紧。比如 code-review 只需要读 diff、读文件、写报告，不应该拥有部署权限；dtools 可以执行构建和测试环境部署，但不应该直接合入 MR。权限越细，误操作风险越低。

适合和不适合的场景

Agentic Engineering 不是所有开发工作的万能解法。它适合流程清楚、上下文可读取、验证方式明确的任务。

落地时最容易踩的坑

1. 让 AI 跳过计划直接改代码

如果需求还没澄清、计划还没审核，就让 AI 开始改代码，本质上还是 Vibe Coding。代码可能看起来能跑，但变更方向未必正确。

强制流程应该是：

需求 → 澄清 → 计划 → 审核 → 执行 → 验证

2. Skill 写成巨大脚本

一个 Skill 试图处理需求、编码、提交、评审、部署，会很难维护。更好的方式是拆成多个 Skill，并通过 Command 或链式调用编排。

3. MCP 权限过大

AI 能调用外部平台 API，不代表它应该拥有所有权限。创建 MR、写评论、查日志可以开放；合入主干、现网发布、删除资源要非常谨慎。

4. AI 评审意见不经过人工判断

AI 的审查报告只是候选意见，不是结论。每条评论都要判断是否符合业务语义，是否属于本次变更，是否会造成过度修改。

5. 忽略 token 成本

子 Agent 并行、全仓代码探索、日志分析都会消耗大量 token。需要控制上下文范围：

• 先用 grep、文件路径、符号索引缩小范围；
• 日志查询默认限制条数；
• 大型 MR 分文件审查；
• 计划和报告落盘，避免反复让模型重新推理；
• 对常用流程写 Skill，不靠长提示临时拼。

核心工作方式变化

传统后台开发和 Agentic Engineering 的差别，可以概括为执行权的转移。

人的职责并没有消失，而是从“亲自做每个动作”转成“定义目标和把关质量”：

• 需求是否准确；
• 方案是否可行；
• 计划是否覆盖边界；
• 代码是否符合工程约束；
• 部署是否安全；
• 评审意见是否应采纳；
• 是否可以合入和发布。

AI 负责重复性高、规则明确、上下文可读取的执行动作：

• 探索代码；
• 生成计划；
• 修改文件；
• 生成 commit；
• 整理 MR；
• 查询日志；
• 初步审查；
• 修复明确评论。

这就是 Agentic Engineering 的关键：不把 AI 当成不受控的自动机，也不只把它当成代码补全工具，而是把它放进一条可审核、可追踪、可回滚的工程流水线里。