有了 AI Skill 之后，产品经理的代码理解力突然「超标」了
当我们把业务术语、工程地图、代码规范沉淀进一个 Skill，产品经理查代码逻辑、分析数据、迭代功能的方式就彻底变了——用一个 Agent 商业化的真实案例来说明。
书接上回。上一篇聊了怎么用 Vibe Coding 的思路，把浏览器插件、内部系统、数据查询一步步封装成 AI Skill。
但那些更多是「工具层」的改造——把手动操作变成自动化。
这篇想聊一个更深层的变化：当 Skill 沉淀了足够的业务知识后，它改变的不是工具，而是产品经理的工作模式。
具体来说，我手里有一个叫「企业版代码说明」的 Skill。它的作用一句话就能说清：产品经理提问，AI 读代码，把业务逻辑翻译成产品能懂的答案。
但这句话背后藏着一个更大的变化——有了它之后，我作为产品经理，对代码的「理解力」突然超标了。
从「手动翻代码」到「问一句话就懂」
以前的痛苦
作为产品经理，我经常需要确认一些业务逻辑：
- 「企业用户购买会员后，哪些功能是解锁的？」
- 「求职者投递职位时，什么情况会被拦截？」
- 「这个状态字段流转到「已关闭」之后，还会不会触发通知？」
这些问题，代码里都有答案。但问题是：
| 障碍 | 具体表现 |
|---|---|
| 不知道代码在哪 | 几十个工程仓库，不知道该看哪个 |
| 看不懂代码结构 | 注解、网关、服务层、消息消费者……每个都是黑盒 |
| 跟不全调用链 | 一个判断可能跨三四个服务，手动追踪很容易断 |
| 代码和文档对不上 | 文档可能过期了，但代码永远是最新的 |
以前遇到这些问题，要么去问开发（占用别人时间），要么自己硬翻代码（效率极低），要么凭经验猜（经常猜错）。
现在的工作模式
有了「企业版代码说明」之后，流程变成了这样：
我只需要按固定格式提问，AI 就会自动：校验问题完整性 → 同步最新工程地图 → 筛选候选仓库 → git pull 拉最新代码 → 从五个入口追踪调用链 → 输出业务结论 + 代码路径。
整个过程我一行代码都不用看，但拿到的答案比我自己翻代码还准。
三个真实场景
这个 Skill 不是偶尔用用的玩具，它已经渗透进我日常的三个核心场景。
场景一：用户有问题，快速查代码逻辑
这是最基础的用法。运营、客服、销售反馈了一个用户问题，我需要快速确认「代码里到底是怎么实现的」。
比如：
角色：企业端用户 业务模块：简历查看 问题：什么情况下企业用户可以查看求职者的完整简历？
AI 会从网关入口出发，追踪到权益校验服务，再追踪到会员等级判断，最后输出一个表格：
| 条件 | 能否查看完整简历 |
|---|---|
| 普通企业账号，未购买会员 | 仅看脱敏简历 |
| 企业会员，且在有效期 | 可查看完整简历 |
| 企业会员，已过期 | 降级为脱敏简历 |
| 特殊行业白名单 | 无论会员状态均可查看 |
附带的代码追踪路径让我（或开发）可以随时验证这个结论是不是准的。
以前这种问题要找开发聊半小时，现在 3 分钟出答案。
场景二：查 SQL，分析数据
这个场景上一篇聊过——「企业版代码说明」负责「查代码定表」，配合数仓查询 Skill 完成「跑数验数」。
但这里有个容易被忽略的衔接点：为什么 AI 能从业务问题定位到正确的物理表？
因为这个 Skill 会强制下钻到 DAO 层。它不会停在 service 层看到一个 getOrderList() 就猜表名，而是继续追到 Mapper XML 或实体注解，读到真实的库表名。
如果停在 service 层，你拿到的可能是个似是而非的表名。强制下钻到 DAO 层，是数据查询不出错的地基。
场景三：迭代功能
这是我觉得价值最大的场景，也是这篇想重点聊的。
真实案例：做一个 Agent 功能的商业化
需求背景
最近我要做一个 Agent 相关的新功能。功能本身不复杂，但一到商业化阶段就头疼了：
这个 Agent 功能要怎么卖？
它不能凭空定价，得放进现有的商业化体系里。而现有的商业化体系已经跑了很多年，涉及：
- 权益体系 —— 不同会员等级对应不同功能权限
- 售卖套餐 —— 基础版/专业版/旗舰版，每个版本打包了一组权益
- 计费方式 —— 有的按次数，有的按时长，有的按席位
- 叠加规则 —— 买了基础版再买增值包，权限怎么合并
- 过期降级 —— 会员到期后哪些功能保留、哪些降级
我要做的事情是：在尽量不侵入老逻辑的前提下，把新 Agent 功能的权益和售卖接进去。
换以前，这事得这么干
如果是以前，我得：
- 找负责商业化的开发聊一圈，搞清楚权益校验在哪
- 翻 wiki / 设计文档（大概率过期）
- 请开发拉一下相关代码，逐个 service 讲一遍
- 自己画半天调用关系图，可能还画错
- 最后提个方案，评审时被指出「你漏了一个分支」
这套流程走下来，少则两三天，多则一周。而且强依赖别人的时间。
用 Skill + git 是怎么做的
这次我没找人，直接用 Skill 干。
第一步：摸清权益校验的主链路
我提问：
角色：企业端用户 业务模块：会员权益 问题：企业用户的会员权益是怎么校验的？完整链路是什么？
AI 追踪出来一条链路：网关入口 → 权益服务 → 会员等级服务 → 套餐配置中心。每一跳都附了工程名和入口方法，我可以直接去验证。
第二步：摸清售卖套餐的结构
再问：
角色：企业端用户 业务模块：售卖套餐 问题：现有套餐是怎么定义的？一个套餐包含哪些权益？
AI 从套餐配置服务出发，追踪到权益打包逻辑，输出了现有套餐和权益的对应关系表。
第三步：摸清计费和叠加规则
继续问计费方式和叠加规则。几轮下来，我对整个商业化体系有了完整的认知——全部基于代码事实，没有一句猜测。
第四步：评估侵入性
这是关键。我拿着前面摸清楚的链路，让 AI 帮我分析：
如果新增一种 Agent 权益类型，需要改动哪些工程？哪些是新增、哪些是修改、哪些有风险？
AI 基于调用链给出了影响范围：
第五步：方案对比
基于影响范围，我列了三种方案：
| 方案 | 做法 | 侵入性 | 工作量 | 风险 |
|---|---|---|---|---|
| A. 新增权益类型 | 在现有权益枚举里加 Agent，复用校验链路 | 低 | 小 | 低（走老链路） |
| B. 独立售卖模块 | Agent 单独一套权益+计费，不碰老逻辑 | 无 | 大 | 中（两套体系要同步） |
| C. 扩展现有套餐 | 把 Agent 塞进现有套餐包，不新增类型 | 中 | 中 | 中（要改套餐打包逻辑） |
因为前面已经用 Skill 把老链路摸透了，我能清楚地判断：方案 A 侵入性最低，且复用了成熟的权益校验链路，风险可控。
为什么效率高
整个过程中，我做了一件以前做不到的事：在没有开发陪同的情况下，独立完成了商业化逻辑的梳理和方案评估。
| 环节 | 以前 | 现在 |
|---|---|---|
| 摸清权益链路 | 找开发聊 + 翻文档 | AI 追踪代码，3 分钟出链路 |
| 理解售卖结构 | 请开发讲 + 画图 | AI 输出结构表 + 追踪路径 |
| 评估侵入性 | 开发估 + 自己猜 | AI 基于调用链给影响范围 |
| 方案对比 | 凭感觉 | 基于代码事实量化侵入性 |
关键不是省了多少时间，而是我不再依赖别人的时间。 想什么时候查就什么时候查，想查多深就查多深。
这个 Skill 里沉淀了什么
说到这里，可能会问：AI 凭什么能这么准地追踪代码？
答案是：这个 Skill 不是空壳，它沉淀了一整套业务知识基建。 大致分两层：
下面逐个展开说。
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. 使用说明
规定了提问的格式要求：
角色：...
业务模块：...
问题：...
三项缺一不可。如果信息不全，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 拿最新版，知识不再是某个人的私有资产，而是团队的可复用基础设施。
写在最后
有了「企业版代码说明」之后，我的工作模式发生了一个根本性的变化：
以前我是「提需求的人」，需要依赖开发才能理解代码；现在我是「能独立读懂代码的产品经理」，提需求之前自己就能把可行性摸清。
这个变化带来的好处不止是效率：
- 需求质量更高 —— 提需求时已经知道现有逻辑，不会提「和现状冲突」的需求
- 沟通成本更低 —— 和开发评审时，能直接对上代码层面，减少理解偏差
- 方案更务实 —— 能基于代码事实评估侵入性，而不是拍脑袋
而这一切的前提，是愿意把业务知识沉淀下来。
Skill 不是写完就结束的。每次发现工程地图漏了一个模块、术语表少了一个角色、FAQ 没覆盖某个高频问题——都应该回头补进去。
Skill 和人一样，需要持续学习才会越来越强。 区别是，Skill 学过的东西不会忘。
上一篇说：「Vibe Coding 不是让你不学编程，而是改变了学习的方式。」
这篇想补一句：当业务知识被结构化沉淀进 Skill，产品经理和代码之间的那堵墙，就真的被打通了。