在公司里”做 AI”这件事，我观察下来大体是 polebug 在 talk 里讲的三类方向：AI 基建 / 内部工具 / 团队提效。三类决定了你每天面对什么问题、写什么代码、跟谁打交道。
但只看三类是不够的——往上看是抽象框架（“我在解决什么类别的问题”），往下还有 Agent 的六大能力底座（“这些方案靠什么基础能力做到”）。中间夹着的不是一堆孤立工具列表，而是真实工作流链路——每条流串联多少个 skill / 调多少个 MCP / 触发哪些 superpowers 方法论。
我把这三层做成了一张可交互的大地图，每条工作流是一条独立横向链路，节点之间用流动 dash 连起来。
👉 打开交互地图 →
地图四层结构：
- ① 顶部 · 三方向 每类的简短定位 + 包含哪几条 flow
- ② 中间 · 8 条工作流 每条是横向链路（节点 dot + dashed flowing path），不再是孤立卡片：
- 团队 AI 提效 (3 条) bug 修复闭环 / 新功能开发 / MR review 双向
- 内部 AI 工具 (5 条) 知识沉淀 LLM-Wiki / 博客发布 / 会话生命周期 / 任务工时回填 / 学习打卡
/study
- ③ 底部 · Agent 六要素 Intent / Workflow / Tools / State / Memory / Systems，每条 flow 行末用 6-chip 标”用了哪些”
- ★ 右侧横切 · Superpowers 方法论层 sticky 垂直链路，14 个方法论 skill（brainstorming / writing-plans / TDD / verification / systematic-debugging / code-review …）横切所有 8 条业务 flow。每条 flow 上的关键节点用紫色 ticker 标 trigger 点
每条 flow 用一个 signature 色染色（bug 修复=金 / 知识沉淀=紫 / 会话=蓝 / MR review=粉 / 学习=橙 …），signature 色就是该 flow 主用的六要素之一。
Hover 任一三方向 chip / 六要素 chip / superpowers 节点，不引用该项的 flow 整条 dim 0.16——一眼看出哪些流用了它、哪些没。Light / Dark 两套主题右上角切换。
我自己在哪
这张地图的中间层全是我自己的实践——所以可以直接用三类方向给自己定位。
我目前实际在做的是 02——给自己手上的几个工程项目搭 AI 工具链：做内部 MCP server、设计 skill 模板、把日常常做的事封装成可复用工作流。整套工具体系在往”自用顺手”的方向打磨。
03 是我的目标方向——地图里 ❶ bug 修复 / ❷ 新功能开发 / ❼ MR review 已经按”团队 AI 提效”归类（终点定位），但每条 flow 行末都标了 🟡 SELF · 自用中——8 条全部都是这个状态。意思是这些工具我自己每天在用，但还没推给同事：没到坐下来蹲一线开发的工作流、写贴着他们具体痛点的 skill、量数据迭代、推他们用的阶段。现在更像是”先把工具体系搭起来”的前置投入：等手上的 skill / MCP / 工作流自己用得顺，知道哪些套路真有效、哪些是自嗨之后，再考虑怎么落到团队层面。没自用过的东西，没资格让别人用。
不过自用工具堆起来之后，反哺路径自动出现了——bug resolve 完判定值得沉淀的就 ingest → wiki → promote 到飞书；MR review 命中复发模式就沉淀成团队 review 准则；学习产出推到部门技术方案库。这些反哺通路在地图上以 4 条 FB flow 单列出来（A/C/D 已 wired up，B IM @ → FAQ 还在 PLAN，等 lark-event 长连）。等反哺有真实流量，就是 SELF → TEAM 状态切换的那天。
关于 01：之前不打算做，现在踩进来了
最早写这篇时我说”01 我不打算做”——理由是业务规模没到需要单独基建的程度，加上我对纯后端基础设施兴趣不大。
后来想清楚一件事：当 02/03 的工具堆到一定密度之后，没有一个统一的网关 + 用量看板，根本量不出”这套东西到底有没有用”。模型调用散在各 skill 里、token 花在哪不知道、谁用得多谁用得少看不见、出了问题追不到调用链。这时候 01 不是”通用 AI 基建”那种合规 / SLA / 大规模的 01——是给一个团队搭 AI 基建：模型网关 + 用量统计 + 后续的 Skill / MCP / Plugin 管理后台。它在气质上其实更像 02/03 的延伸（贴着业务做），不是教科书意义的 01。
技术路线决定走 A 路径（找开源改改），候选在 LiteLLM / one-api / Helicone / Langfuse 里挑。MVP 目标只有两件：模型网关跑通 + 用量看板能看见每个人 / 每个 skill / 每个 flow 的 token 消耗。Skill / MCP / Plugin 管理后台后置，等 MVP 跑稳再做。
所以三类划分本身没错——成长方向、学习路径都不一样。但实际推进时这三类会互相要对方的东西：02/03 工具用多了会反过来要 01 的可观测能力、01 量出来的数据会反向校准 02/03 哪些工具值得继续投入、03 反哺路径需要 02 的 wiki 当中转站。三类是分类标签，不是站队选项。
三类的成长方向不一样
跨类的人很少。三类的成长方向完全不同：
- 01 往技术深度走（性能 / 稳定性 / 大规模）
- 02 往产品感走（什么功能值得做 / 不值得做）
- 03 往业务理解 + 影响力走（怎么让别人变得更好）
学习路径也不同：
- 01 该学 LLM Inference 优化、Token 计费精算、API Gateway 设计、合规
- 02 该学 RAG 工程化、agent 框架对比、产品调研、用户访谈
- 03 该学业务领域知识、prompt engineering 落地经验、跟人协作的功夫
如果你正打算往 AI 方向转，先别问”该学什么”——这个问题在你定位完之前没法答。先问”我想成为这三类里的哪一类”。简历重点、技能积累、人脉网，分歧从这里开始。
如果还在企业里没动过手，可以先做一个低成本验证：
- 想做 01 → 业余给团队搭一个简单的模型网关代理（哪怕只是 nginx + rate limit）
- 想做 02 → 给公司挑一个内部场景做一个最小知识库问答（哪怕只能回答一个 FAQ）
- 想做 03 → 找一个具体同事，蹲他工作流半天，给他写一个能直接用的 skill
哪条做下来你最不嫌烦，那就是你的方向。
关于”漂移”和成熟度三段
跟着这套框架自己搭工具的人，迟早会撞上一个反直觉现象：工具体系搭起来不等于稳定。Skill 写完一个礼拜没人维护就开始漂移——两个 skill 功能重叠、wiki schema 跟实际页脱钩（38% 的页缺 frontmatter 这种事是真的会发生）、自写 MCP 暴露了 13 个 tool 但 skill 里只接了 5 个。建好 ≠ 永远稳。
我自己做过两次自我审计（按反哺机制端到端 / skill 重复 / wiki schema 漂移 / MCP 死工具 / cross-stack 引用一致性 等角度），写了一组检测脚本+ADR+强制召回机制，把”演进”从手工跑成了半自动。在这件事上我总结出一个比较清晰的三段成熟度模型：
- 第一段：运行——工具体系能跑起来。Skill 写完了，MCP 接好了，反哺路径连通了。能用，但还在依赖人主动触发。
- 第二段：自我演进——能审计自己 + 修复自己。能发现”哪里漂移了”、“哪些功能重复了”、“哪些工具建了没人用”。这一段需要人触发 + 人 review + 人 verify——尤其是 agent 自动跑出来的 audit 报告，~30% 是误报；脚本跑出来的更狠，95% 误报（脚本严格但不智能，agent 智能但不严格，互补不替代）。盲改会修出新坑，必须逐条 verify。
- 第三段：自动化——审计和修复本身都不再需要人。pre-commit hook 拒绝缺 frontmatter 的提交、lint 自动按周跑发飞书 IM、Dataview 自动统计 schema 完整性、孤儿页定期 surface。演进的成本下降到接近零，体系才真正活着。
把整套地图按子系统拆开看，演进进度严重不均匀：
| 子系统 | 当前阶段 | 为什么 |
|---|---|---|
| Wiki schema / 反哺路径 / Skill 引用 / MCP 接入 / Cross-stack | 第二段 ✓ | 都是文件 / schema 层，静态可扫，写脚本就能 detect |
| Memory 一致性 | 第二段过半 | 引用死链能扫，但语义矛盾要 LLM 判断 |
| Workflow 真实使用率 | 第一段 | 没 telemetry，看不见用户实际怎么跑哪条 flow——detect 不了就演进不了 |
最后这条是关键发现：演进进度不取决于工具体系本身做得多好，取决于这个层有没有可观测性。文件 / schema 层一开始就有完美 telemetry（静态可扫），所以演进起来轻松；workflow 层缺数据就只能停在第一段。这反过来印证了 Agent 六要素那篇 提到的 telemetry——telemetry 不只是 debug 用，是演进必需。
我现在的状态：5/6 个子系统在第二段稳住（脚本化 detect + 强制召回 + 时间/阈值/事件三类触发都接上），剩下 workflow 这一个等模型网关 + 用量看板（也就是文章前面说的”01 MVP”）跑通后才有 telemetry，才能演进。这就是为什么我之前说”01 我不打算做”是错的——没有 01 的 telemetry，03 的 workflow 永远在第一段。
一个反直觉的结论：能演化的工具集才活着。一开始我以为工作流的成熟度看”功能多不多 / 链路全不全”，做久了发现这是错的——功能多但漂移没人管的体系会迅速腐烂。真正决定能不能用三年五年的，是演化机制本身的成熟度，而它取决于每一层有没有可观测性。这一层在地图上看不到（地图画的是当前结构，不是演化能力），但读者跟着这套思路搭自己工具的时候，请在 day 1 就给两件事留位置：(1) 周期 audit + 漂移检测脚本；(2) 每一层都要有 telemetry——哪怕最粗的（跑了哪个 skill / 调了哪个 MCP / 用了多少 token / 谁在用）。没 telemetry 那一层，第三段永远到不了。
三类划分的框架来自 polebug 的 talk《保持思考｜等待｜斋戒——从后端开发到 AI 方向的学习经历和工作转变》。Agent 六要素的拆分参考了 LLM Agent 工程的常见教程。这篇是把两套框架放进我自己的工程视角下做了一次穿透。