---
title: 有了 AI Skill 之后，产品经理的代码理解力突然「超标」了
slug: product-manager-code-reading-with-ai-skill
description: 当我们把业务术语、工程地图、代码规范沉淀进一个 Skill，产品经理查代码逻辑、分析数据、迭代功能的方式就彻底变了——用一个 Agent 商业化的真实案例来说明。
date: 2026-08-01
published_at: 2026-08-01 10:00
category: Notes
tags:
  - Vibe Coding
  - 产品思考
  - 工作流
draft: false
featured: true
hidden: false
archived: false
---

> 书接上回。上一篇聊了怎么用 Vibe Coding 的思路，把浏览器插件、内部系统、数据查询一步步封装成 AI Skill。
>
> 但那些更多是「工具层」的改造——把手动操作变成自动化。
>
> 这篇想聊一个更深层的变化：**当 Skill 沉淀了足够的业务知识后，它改变的不是工具，而是产品经理的工作模式。**

具体来说，我手里有一个叫「企业版代码说明」的 Skill。它的作用一句话就能说清：**产品经理提问，AI 读代码，把业务逻辑翻译成产品能懂的答案。**

但这句话背后藏着一个更大的变化——有了它之后，我作为产品经理，对代码的「理解力」突然超标了。

## 从「手动翻代码」到「问一句话就懂」

### 以前的痛苦

作为产品经理，我经常需要确认一些业务逻辑：

- 「企业用户购买会员后，哪些功能是解锁的？」
- 「求职者投递职位时，什么情况会被拦截？」
- 「这个状态字段流转到「已关闭」之后，还会不会触发通知？」

这些问题，**代码里都有答案**。但问题是：

| 障碍 | 具体表现 |
| ---- | -------- |
| 不知道代码在哪 | 几十个工程仓库，不知道该看哪个 |
| 看不懂代码结构 | 注解、网关、服务层、消息消费者……每个都是黑盒 |
| 跟不全调用链 | 一个判断可能跨三四个服务，手动追踪很容易断 |
| 代码和文档对不上 | 文档可能过期了，但代码永远是最新的 |

以前遇到这些问题，要么去问开发（占用别人时间），要么自己硬翻代码（效率极低），要么凭经验猜（经常猜错）。

### 现在的工作模式

有了「企业版代码说明」之后，流程变成了这样：

```d2
direction: right

pm: {
  label: "产品经理提问"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
}

skill: {
  label: "企业版代码说明"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 8
}

answer: {
  label: "业务结论 + 代码路径"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.border-radius: 8
  style.stroke-width: 3
}

pm -> skill: "角色+模块+问题"
skill -> answer: "校验→拉码→追踪"
```

我只需要按固定格式提问，AI 就会自动：校验问题完整性 → 同步最新工程地图 → 筛选候选仓库 → `git pull` 拉最新代码 → 从五个入口追踪调用链 → 输出业务结论 + 代码路径。

**整个过程我一行代码都不用看，但拿到的答案比我自己翻代码还准。**

## 三个真实场景

这个 Skill 不是偶尔用用的玩具，它已经渗透进我日常的三个核心场景。

### 场景一：用户有问题，快速查代码逻辑

这是最基础的用法。运营、客服、销售反馈了一个用户问题，我需要快速确认「代码里到底是怎么实现的」。

比如：

> 角色：企业端用户
> 业务模块：简历查看
> 问题：什么情况下企业用户可以查看求职者的完整简历？

AI 会从网关入口出发，追踪到权益校验服务，再追踪到会员等级判断，最后输出一个表格：

| 条件 | 能否查看完整简历 |
| ---- | --------------- |
| 普通企业账号，未购买会员 | 仅看脱敏简历 |
| 企业会员，且在有效期 | 可查看完整简历 |
| 企业会员，已过期 | 降级为脱敏简历 |
| 特殊行业白名单 | 无论会员状态均可查看 |

附带的代码追踪路径让我（或开发）可以随时验证这个结论是不是准的。

**以前这种问题要找开发聊半小时，现在 3 分钟出答案。**

### 场景二：查 SQL，分析数据

这个场景上一篇聊过——「企业版代码说明」负责「查代码定表」，配合数仓查询 Skill 完成「跑数验数」。

但这里有个容易被忽略的衔接点：**为什么 AI 能从业务问题定位到正确的物理表？**

因为这个 Skill 会强制下钻到 DAO 层。它不会停在 service 层看到一个 `getOrderList()` 就猜表名，而是继续追到 Mapper XML 或实体注解，读到真实的库表名。

```d2
direction: right

question: {
  label: "业务问题"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
}

service: {
  label: "Service 层\n业务判断"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
}

dao: {
  label: "DAO 层\n真实表名+字段"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.stroke-width: 3
  style.border-radius: 8
}

sql: {
  label: "数仓→SQL"
  style.fill: "#1e1e2e"
  style.stroke: "#F38BA8"
  style.border-radius: 8
}

question -> service -> dao -> sql

service -.-> dao: {
  label: "强制下钻"
  style.stroke: "#F38BA8"
}
```

如果停在 service 层，你拿到的可能是个似是而非的表名。**强制下钻到 DAO 层，是数据查询不出错的地基。**

### 场景三：迭代功能

这是我觉得**价值最大**的场景，也是这篇想重点聊的。

## 真实案例：做一个 Agent 功能的商业化

### 需求背景

最近我要做一个 Agent 相关的新功能。功能本身不复杂，但一到商业化阶段就头疼了：

**这个 Agent 功能要怎么卖？**

它不能凭空定价，得放进现有的商业化体系里。而现有的商业化体系已经跑了很多年，涉及：

- **权益体系** —— 不同会员等级对应不同功能权限
- **售卖套餐** —— 基础版/专业版/旗舰版，每个版本打包了一组权益
- **计费方式** —— 有的按次数，有的按时长，有的按席位
- **叠加规则** —— 买了基础版再买增值包，权限怎么合并
- **过期降级** —— 会员到期后哪些功能保留、哪些降级

我要做的事情是：**在尽量不侵入老逻辑的前提下，把新 Agent 功能的权益和售卖接进去。**

### 换以前，这事得这么干

如果是以前，我得：

1. 找负责商业化的开发聊一圈，搞清楚权益校验在哪
2. 翻 wiki / 设计文档（大概率过期）
3. 请开发拉一下相关代码，逐个 service 讲一遍
4. 自己画半天调用关系图，可能还画错
5. 最后提个方案，评审时被指出「你漏了一个分支」

**这套流程走下来，少则两三天，多则一周。而且强依赖别人的时间。**

### 用 Skill + git 是怎么做的

这次我没找人，直接用 Skill 干。

**第一步：摸清权益校验的主链路**

我提问：

> 角色：企业端用户
> 业务模块：会员权益
> 问题：企业用户的会员权益是怎么校验的？完整链路是什么？

AI 追踪出来一条链路：网关入口 → 权益服务 → 会员等级服务 → 套餐配置中心。每一跳都附了工程名和入口方法，我可以直接去验证。

**第二步：摸清售卖套餐的结构**

再问：

> 角色：企业端用户
> 业务模块：售卖套餐
> 问题：现有套餐是怎么定义的？一个套餐包含哪些权益？

AI 从套餐配置服务出发，追踪到权益打包逻辑，输出了现有套餐和权益的对应关系表。

**第三步：摸清计费和叠加规则**

继续问计费方式和叠加规则。几轮下来，我对整个商业化体系有了完整的认知——**全部基于代码事实，没有一句猜测。**

**第四步：评估侵入性**

这是关键。我拿着前面摸清楚的链路，让 AI 帮我分析：

> 如果新增一种 Agent 权益类型，需要改动哪些工程？哪些是新增、哪些是修改、哪些有风险？

AI 基于调用链给出了影响范围：

```d2
direction: down

new_right: {
  label: "新增 Agent 权益"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
  style.stroke-width: 2
}

entitlement: {
  label: "权益服务\n注册新枚举"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 8
}

package: {
  label: "套餐配置\n加入套餐包"
  style.fill: "#1e1e2e"
  style.stroke: "#F9E2AF"
  style.border-radius: 8
}

gateway: {
  label: "Agent 网关\n权益拦截"
  style.fill: "#1e1e2e"
  style.stroke: "#CBA6F7"
  style.border-radius: 8
}

new_right -> entitlement -> package
new_right -> gateway
```

**第五步：方案对比**

基于影响范围，我列了三种方案：

| 方案 | 做法 | 侵入性 | 工作量 | 风险 |
| ---- | ---- | ------ | ------ | ---- |
| A. 新增权益类型 | 在现有权益枚举里加 Agent，复用校验链路 | 低 | 小 | 低（走老链路） |
| B. 独立售卖模块 | Agent 单独一套权益+计费，不碰老逻辑 | 无 | 大 | 中（两套体系要同步） |
| C. 扩展现有套餐 | 把 Agent 塞进现有套餐包，不新增类型 | 中 | 中 | 中（要改套餐打包逻辑） |

因为前面已经用 Skill 把老链路摸透了，我能清楚地判断：**方案 A 侵入性最低，且复用了成熟的权益校验链路，风险可控。**

### 为什么效率高

整个过程中，我做了一件以前做不到的事：**在没有开发陪同的情况下，独立完成了商业化逻辑的梳理和方案评估。**

| 环节 | 以前 | 现在 |
| ---- | ---- | ---- |
| 摸清权益链路 | 找开发聊 + 翻文档 | AI 追踪代码，3 分钟出链路 |
| 理解售卖结构 | 请开发讲 + 画图 | AI 输出结构表 + 追踪路径 |
| 评估侵入性 | 开发估 + 自己猜 | AI 基于调用链给影响范围 |
| 方案对比 | 凭感觉 | 基于代码事实量化侵入性 |

**关键不是省了多少时间，而是我不再依赖别人的时间。** 想什么时候查就什么时候查，想查多深就查多深。

## 这个 Skill 里沉淀了什么

说到这里，可能会问：AI 凭什么能这么准地追踪代码？

答案是：**这个 Skill 不是空壳，它沉淀了一整套业务知识基建。** 大致分两层：

```d2
direction: down

skill: {
  label: "企业版代码说明 Skill"
  style.fill: "#1e1e2e"
  style.stroke: "#CBA6F7"
  style.border-radius: 8
  style.stroke-width: 3
}

base: {
  label: "基础层：术语表 · 工程地图 · 使用说明 · 代码规范"
  style.fill: "#1e1e2e"
  style.stroke: "#89B4FA"
  style.border-radius: 8
}

ext: {
  label: "扩展层：权限矩阵 · 枚举字典 · 调用关系图 · FAQ 索引"
  style.fill: "#1e1e2e"
  style.stroke: "#A6E3A1"
  style.border-radius: 8
}

skill -> base
skill -> ext
```

下面逐个展开说。

### 1. 术语表

这是最基础也最重要的沉淀。公司内部有大量「黑话」，外部 AI 完全看不懂：

| 术语 | 归一化 | 说明 |
| ---- | ------ | ---- |
| 企业版 | B | 企业端用户 |
| 服务商 | H | 中介端用户 |
| 求职者 | C | 求职端用户 |
| 企业高级会员 | B | 企业端付费会员 |
| 认证服务商 | H | 服务商认证用户 |

有了这张表，AI 才能把用户口语化的提问归一化成代码里的角色标识，精准定位到对应的工程。

**没有术语表，AI 连「这是哪个端的用户」都分不清。**

### 2. 工程地图

这是整个 Skill 的「导航系统」。一个 YAML 文件，记录了：

- 每个工程仓库的 git 地址
- 它属于哪个角色（B / H / C）
- 它的终端形态（PC / H5 / 小程序 / APP / 服务端）
- 它包含哪些业务模块和功能

提问时，AI 先同步这个地图仓库（`git pull` 拿最新版），再根据角色 + 终端 + 模块筛选候选工程。**这就像给 AI 装了一个公司代码库的 GPS。**

没有它，AI 只能在几十个仓库里盲目搜索，既慢又不准。

### 3. 使用说明

规定了提问的格式要求：

```text
角色：...
业务模块：...
问题：...
```

三项缺一不可。如果信息不全，AI 会拒绝执行，要求补充。

这个设计看起来「死板」，但非常必要——**模糊的问题只会得到模糊的答案。** 强制结构化提问，逼着提问者想清楚自己到底想问什么。

### 4. 代码规范

记录了工程代码的结构约定，比如：

- 网关入口用 `@GatewayApi` 注解
- 服务接口用 `@Service` 注解
- 消息消费者在 `support/consumer/` 目录
- 定时任务继承基础调度类
- 包名 `com.xxx.{业务域}.*` 对应 `{业务域}-platform` 工程

这些规范让 AI 知道**该去哪里找入口**，而不是满仓库乱搜。相当于给 AI 发了一份「代码地图图例」。

### 5. 角色权限矩阵（补充）

这是我建议补充的一块——**不是 Skill 原有的，但加上之后效果显著。**

一张表记录：哪个角色能做什么、不能做什么。

| 功能 | B 端 | H 端 | C 端 |
| ---- | ---- | ---- | ---- |
| 查看简历 | 会员可查 | 授权可查 | 仅自己 |
| 发布职位 | 可发布 | 代发 | 不可 |
| 投递职位 | 不可 | 不可 | 可 |

有了这张矩阵，AI 在回答业务问题时能快速校验「这个角色到底有没有这个权限」，而不用每次都追踪一遍权限链路。

### 6. 枚举字典（补充）

业务代码里大量用到状态码和枚举值，但它们的含义散落在各个工程的常量类里。建一个集中字典：

| 枚举 | 值 | 含义 | 所在工程 |
| ---- | -- | ---- | -------- |
| 订单状态 | 0 | 待支付 | 订单服务 |
| 订单状态 | 1 | 已支付 | 订单服务 |
| 会员等级 | 10 | 普通 | 会员服务 |
| 会员等级 | 20 | 高级 | 会员服务 |

**这个字典对「查 SQL 分析数据」场景特别重要**——上一篇提到的「枚举验数」就是靠它对齐的。

### 7. 跨服务调用关系图（补充）

记录核心服务之间的 RPC 依赖关系。哪个服务调哪个服务、调的是什么接口、传的是什么参数。

有了这张图，AI 在追踪调用链时能快速判断「下一个该去哪个工程找」，而不是靠包名猜。

特别是那些容易断链的地方——比如某个布尔值是远程返回的，AI 知道该去哪个服务追它的业务含义，而不是把它当结论直接输出。

### 8. 常见问题 FAQ 索引（补充）

把团队高频问的问题和它们的代码位置记录下来：

- 「会员过期后权益怎么降级？」→ 权益服务.降级方法()
- 「投递拦截规则有哪些？」→ 投递服务.拦截校验()
- 「套餐叠加后权限怎么合并？」→ 套餐服务.合并方法()

**这相当于一个「热门导航」**，高频问题直接命中，不用每次走完整追踪流程。

## 这些沉淀的本质

回头看这 8 块内容，它们其实在做同一件事：

> **把散落在人脑里、文档里、代码注释里的业务知识，结构化地搬进 AI 能读取的文件里。**

以前这些知识只在开发脑子里——开发在，知识在；开发离职了，知识就断了。

现在它们被固化成文件，AI 每次执行都先 `git pull` 拿最新版，**知识不再是某个人的私有资产，而是团队的可复用基础设施。**

## 写在最后

有了「企业版代码说明」之后，我的工作模式发生了一个根本性的变化：

**以前我是「提需求的人」，需要依赖开发才能理解代码；现在我是「能独立读懂代码的产品经理」，提需求之前自己就能把可行性摸清。**

这个变化带来的好处不止是效率：

1. **需求质量更高** —— 提需求时已经知道现有逻辑，不会提「和现状冲突」的需求
2. **沟通成本更低** —— 和开发评审时，能直接对上代码层面，减少理解偏差
3. **方案更务实** —— 能基于代码事实评估侵入性，而不是拍脑袋

而这一切的前提，是**愿意把业务知识沉淀下来**。

Skill 不是写完就结束的。每次发现工程地图漏了一个模块、术语表少了一个角色、FAQ 没覆盖某个高频问题——都应该回头补进去。

**Skill 和人一样，需要持续学习才会越来越强。** 区别是，Skill 学过的东西不会忘。

---

> 上一篇说：「Vibe Coding 不是让你不学编程，而是改变了学习的方式。」
>
> 这篇想补一句：**当业务知识被结构化沉淀进 Skill，产品经理和代码之间的那堵墙，就真的被打通了。**