AI 业务地图

★ 一天动线 · DAILY FLOW / 怎么按时间走 — 8 条 flow 是 what (做啥), 这一栏是 when (按啥顺序)

早晨 /resume 起手 → 中间按今日类型分流走 1-N 条 flow → 段落 /wrap-up 收工. 中间任意时刻 /task-pause · /task-block · /task-resume. 最关键 2 条命令: /resume + /wrap-up

早晨 · OPEN

/resume 起手

大脑加载 · 拉 runtime

中间 · BRANCH

分流 · 走 1-N 条 flow

按今日类型 (下方 4 类速查)

段落 · CLOSE

/wrap-up 收工

沉淀对话 · 顺延明日

打开电脑第一句, 大脑就 ready. 替你拉齐三处实时数据 (禅道 active bug · GitLab open MR · 飞书任务排期) + 读两份历史 (CLAUDE.md · 上次 session log · 今日 Daily Note 顺延 todo). 不切窗口, 不 recap 自己 — 一句话全有了.

看完 /resume 输出, 今天主线已经清楚. 修 bug / 搞新功能 / 重构优化 / 学习文档 — 4 类各走各的 flow. 中途插事 / 等同事 / 切别的项目? /task-pause · /task-block · /task-resume 兜底, 不丢上下文.

一段工作完, 一句话沉淀. 扫对话 ingest (/note → Wiki / 飞书) · 压会话日志 (/compress) · 学到的写 CLAUDE.md (/preserve, 下次 /resume 自动读到) · 未完 todo 顺延明天. 第二天起手不用 recap.

分流 · BUG · 不计工时

修 bug · per-bug 节奏

周一同事一口气甩 5 条禅道 bug 那种 — 禅道侧立刻 resolve 让产品看到进度, MR 攒一波统一提.

/bug start →
/commit → /bug resolve ↩
(per-bug 循环 N 次)
→ /ship-to test · QA
→ /ship-to release

分流 · FEAT · 计工时

新功能

brainstorm 出来 → 进了排期 → 写代码. 跟 bug 不同, 这是项目工作量, 必须计工时.

/task-start →
改 → /commit →
/ship-to test · QA →
/ship-to release →
/task-end

分流 · OPT · 计工时

重构 / 优化

首屏从 1.8s 想打到 1.2s, bundle 想砍 50KB — 这种带数字目标的活. MR 模板会逼你写基准数据 (before / after).

/task-start →
改 → /commit →
/ship-to test · QA
(含基准数据) →
/ship-to release → /task-end

分流 · CHORE · 不计工时

学习 / 文档 / chore

升 vite / 改 CI / 跑 demo / 写文档 — 不进项目效能系统. 学习走 /study (个人路线打卡, 不算项目交付).

改 → /commit →
/ship-to test · QA →
/ship-to release
学习: /study 打卡 (单独流)

关键认知 · 8 条 flow 回答 "做啥" (what), 这条动线回答 "按啥顺序做" (when). /resume 跟 /wrap-up 是 所有 flow 的统一 nav — 不属于任何单条 flow, 但是体系跑得起来的骨架.

② 工作流 · WORKFLOWS / 真实链路 (8 条)

③ 团队 AI 提效· 3 条 · 业务 + 进入日常开发

FLOW · 01 bug 修复闭环团队 AI 提效 SELF · 自用中 USES

飞书任务

trigger

/resume runtime

active bugs + open MRs

/bug start

git_path 命中 · 当前 branch 默认

改代码

在 worktree 隔离

/commit

commitlint + AI 署名

/bug resolve

禅道 6 段 · 不 push

/ship-to

本地 merge → test/release

release → main MR

release manager · 上线

brainstormingusing-git-worktrees

systematic-debuggingtest-driven-development

verification-before-completion

verification

requesting-code-review

finishing-a-dev-branch

FLOW · 02 新功能开发团队 AI 提效 SELF · 自用中 USES

口语需求

"加一个 X"

brainstorm + plan

挖清楚 / 列切片清单

/new-feature

FSD 切片 + plop 生成

写代码

/vue-component + /unit-test

/commit

verify + 推进 prompt

/ship-to

本地 merge → test/release

release → main MR

release manager · 上线

brainstormingwriting-plans

dispatching-paralleltest-driven-development

verification

requesting-code-review

finishing-a-dev-branch

FLOW · 07 MR review 双向团队 AI 提效 SELF · 自用中 USES

收 review

reviewer 评论

decide

改 / 讨论 / push back

─ ◆ ─

双向 (收/给)

/mr review

审别人 diff

写评论

findings + 建议

闭环

discussion

receiving-code-review

systematic-debugging

requesting-code-review

② 内部 AI 工具· 5 条 · 知识库 · workflow · Skill hub · MCP 管理

FLOW · 03 知识沉淀 (LLM-Wiki) 内部 AI 工具 SELF · 自用中 USES

Source

对话 / 会议 / MR / URL

/ingest

拆解到 5-15 wiki 页

≥3 同主题积累

触发蒸馏

/distill → Topic

蒸馏成 Pattern / ADR

visibility=team

flag 触发广播

/promote

→ 飞书部门库

writing-plansdispatching-parallel

verification

FLOW · 04 博客发布内部 AI 工具 SELF · 自用中 USES

创意

想写的话题

写草稿

Wiki/Posts/Drafts/

visibility=public

flag 触发发布

/publish

推到 quartz repo

GitHub Pages CI

jekyll/quartz build

已上线

cassandracat.github.io

brainstormingwriting-plans

verification

systematic-debugging

FLOW · 05 会话生命周期内部 AI 工具 SELF · 自用中 USES

/resume

CLAUDE.md + 飞书 + runtime

工作过程

编码 / 调试 / 沉淀

/preserve

technique → CLAUDE.md

/wrap-up

verify · ingest · 明日待办

/compact

压缩上下文

verification-before-completion

FLOW · 06 任务工时回填内部 AI 工具 SELF · 自用中 USES

飞书排期表

任务 trigger

/task-start

worktree 计时

工作

pause / resume / block

/task-end

耗时 + 成本

/workhour-sync

同步工时表

工时统计表

月度对账

FLOW · 08 学习打卡 /study 内部 AI 工具 SELF · 自用中 USES

/study

三线: AI · CG · Algo

今日清单

每线 1 题

完成打卡

进度更新

/ingest 学到的

非琐碎才录

Wiki/Topics/Learning/

知识沉淀

writing-plans

★ META · 横切方法论

Superpowers 方法论层

14 个 skill 横切 所有 8 条业务 flow。Hover sp 看哪条 flow 用它。

using-superpowers元 skill — 教 agent 怎么用 sp 集起新 conversation 时

brainstorming挖到用户真实意图, 不直接动手模糊需求 / 创造性前

writing-plans把多步任务写成可执行 plan≥3 步任务前

using-git-worktreesgit worktree 隔离, 多任务并行不打架执行前 / 需工作区隔离

executing-plans按 plan 顺序执行 + review checkpoint按 plan 照走

subagent-driven-developmentplan 后派子 agent 执行, 主 agent 审查执行变体 (子 agent)

dispatching-parallel-agents派多个子 agent 并行处理独立任务执行变体 (并行 ≥2)

test-driven-development先写测试再写实现写实现代码前

systematic-debugging系统化定位根因, 不瞎改代码bug / 测试挂时

verification-before-completion跑命令拿绿灯证据再宣告完成宣告完成前

requesting-code-review按规范写 MR description / test plan提 MR 时

receiving-code-review技术理性回 review, 不假装同意 / 不盲改收 review 时

finishing-a-dev-branch清本地 branch + worktree, 不留废 branchbranch merge 后

writing-skills创建 / 编辑 / 验证 skill, 含部署元 / 创建 / 改 skill

★ 反哺路径 · FEEDBACK LOOPS / 02 自用 → 03 团队提效桥梁

8 条自用 flow 完成时自动判定是否值得沉淀. 命中 → wiki 标 feedback_type → /promote 推飞书. "没自用过的没资格让别人用" — 反哺让自用经验流向团队. 3 条已 wired up / 1 条 PLAN

FB · A bug 修复 → 团队踩坑录 SELF · wired up /bug resolve Step 2.3 自动判定 6 信号; 命中→沉淀到 Solutions

/bug resolve

Step 2.3 触发

/ingest bug <id>

拆禅道 bug + 截图到 wiki

Wiki/Solutions/<slug>

visibility=team + feedback_type=bug-solution

/promote

lark-cli base +record-create

飞书解决方案库

Bitable · 同事按问题搜

FB · C MR review finding → 团队 review 准则 SELF · wired up /mr review #6 自动判定 5 信号; 复发模式 / P0-P1 finding 命中→沉淀到 Patterns

/mr review #6

review 完触发

/ingest mr

拆 finding (现象/根因/推荐写法)

Wiki/Topics/Patterns/

review-pattern · 含 code snippet

/promote

[Review Pattern] 前缀

飞书解决方案库

Bitable · 团队 review checklist

FB · D 学习产出 → 团队学习库 SELF · wired up /study done Step 7 自动判定 5 信号; 跑通 / 避坑 / 跨概念命中→沉淀

/study done

Step 7 触发

/ingest learning

拆 insight 到 Topics/Learning

Wiki/Topics/Learning/

feedback_type=learning

/promote

wiki dir 路径

飞书部门「技术方案」

wiki dir · 同事可订阅

FB · B IM @ 我 → 团队 FAQ (待实施) PLAN · 未做需 lark-event 监听 @ → 你回答完自动建议 ingest FAQ; 工程量大, 后期做

lark-event 监听 @

未做

自动建议 /ingest faq

未做

Wiki/Topics/Patterns/

未做

/promote

未做

飞书部门 FAQ 库

未做

★ 自我演进机制 · SELF-HEALING / 文件 schema 自动审计 + 修复 (跟反哺机制对偶: 反哺向外推团队, 演进向内修自己)

工具体系建好不等于稳定 — 长期会漂移. 自审 + 自修机制按 5 步循环 (Trigger / Detect / Decide / Apply / Learn) 跑, 6 子系统按各自 detect 难度独立演进. 详见 §漂移和成熟度三段

脚本

集成点

ADR

5/6

子系统 STAGE 2

5 步循环 → TRIGGER ━ DETECT ━ DECIDE ━ APPLY ━ LEARN ↩

↓ 每个子系统按 5 步具体实现 (点击展开看)

LLM-Wiki schema

STAGE 2 / 3

frontmatter / index / 反哺 schema 自动检 + 修 — 22 页补 38%→100%

TRIGGERlint 月度 (≥30 天) · resume Step 6.5.7 (晨间) · ingest Step 8 · wrap-up Phase 5 · 月初 day1 起 baseline

DETECT3 脚本: wiki-fix-frontmatter (5 字段) · wiki-index-coverage (页外漂移) · wiki-feedback-trace (反哺 4 路径连通)

DECIDE单 LLM 严格 verify, 0 误报 (替代双 agent cross-verify)

APPLYfrontmatter --apply 全自动补; index 半自动 (人决归属哪个 section)

LEARN0005 ADR 强制召回 (lint Step 0 必读 0004+0005); 实测后回写量化指标

Skill 引用 (33 个)

STAGE 2 / 3

死链 / deprecated / cross-step 编号错位 — 53 finding 过滤后 0 真问题

TRIGGER跟 lint 同步, 月度跑 cc-stack-coverage.py --only=skill

DETECTcc-stack-coverage.py: 死链 (/X 引但 X 不存) · deprecated 引用 · cross-step (/B step 6 但 B 没) · orphan

DECIDE单 LLM verify; 加 IGNORE list (built-in 命令 / 模板占位符) 后 53→0 真问题

APPLY死链改 link/删; deprecated 替换; step 编号同步; 已修 study Step 3.7-3.8 / bug 加 close confirm

LEARNIGNORE list 累积; 元学习: 脚本 ~95% 误报 vs agent ~30% — 互补

MCP 暴露 / 接入

STAGE 2 / 3

dist-src 同步 + 死工具 surface — zentao 12 工具 5 接入 4 高级

TRIGGER跟 lint 同步; 改 src 后 npm run verify 报 dist-stale

DETECTcc-stack-coverage.py --only=mcp: dist-src 同步 · skill 调的 mcp__X__Y 是否真暴露 · MCP 暴露但没用的 dead tool

DECIDE单 LLM verify; self-written 白名单只检 zentao

APPLYdist-stale npm run build (自动 stamp src mtime); 错引用改 tool 名; 死工具记 README 高级用法

LEARNzentao README 高级用法节累积 (4 INFO → 显式说明); 写 build-stamp.mjs / verify-build.mjs 兜底

Cross-stack (skill→wiki)

STAGE 2 / 3

skill 引用 wiki 页是否真存在 — 1 真死链已修

TRIGGER跟 lint 同步

DETECTcc-stack-coverage.py --only=cross: skill 文档里 [[Topics/X]] [[Solutions/Y]] 引用的 wiki 页存不存在

DECIDELLM verify; 模板占位符 (X/Y/<x>) 加 IGNORE 后只剩真问题

APPLY改 link 到正确页 / 建占位页 / 改成短引用让 obsidian 自动 resolve

LEARN这次修 promote.md → Personal-Workflow → 改指 [[0001 反哺章节]]

Memory 一致性

STAGE 1.5 / 3

死链能扫, 语义矛盾要 LLM — 半人工

TRIGGER跟 lint 同步

DETECTcc-stack-coverage.py --only=memory: 6 memory 文件引用的 ADR / wiki 页 / skill 是否还存在

DECIDEdeterministic 部分 (死链) 自动通过; 语义矛盾要 LLM 判断 + 用户决

APPLY死链自动; 语义矛盾人工修 (改 memory 删过期信息)

LEARN沿用其他子系统的 0005 ADR 召回机制

Workflow 真实使用率

STAGE 0 / 3 · PLAN

需 telemetry, 等 01 MVP — 没数据 → detect 不了 → 演进不了

TRIGGER❌ 没 telemetry 触发不了

DETECT❌ 看不见用户实际怎么跑哪条 flow / 哪步用户老跳 / 哪 skill 错率高

DECIDE❌ N/A (没数据可决)

APPLY❌ N/A

LEARN❌ N/A · 解锁条件: 01 MVP (模型网关 + per-user/per-skill/per-flow 看板) 跑通

关键洞察 · 演进进度不取决于工具好坏, 取决于这一层有没有 telemetry. 文件层静态可扫所以快, workflow 层缺数据所以停在第一段 — 这正是 01 MVP 不可选的根本理由.

★ ROADMAP · 智能化演进 5 层级 / 跟自我演进对偶: 演进 = 现状; ROADMAP = 未来要往哪去 (Hermes / Claude Code Skills 启发)

自我演进做的是 文件 schema 一致性 (L1, 静态可扫易实现). 真正的"AI 越用越懂"还要 4 层: skill 自优化 · workflow 自适应 · tools/systems 自愈 · 团队 collective learning. 全部依赖 执行 telemetry. 1/5 已实施 ✓ · 4/5 PLAN · 共同瓶颈: 01 MVP 看板上线

智能化层级

1/5

已实施 (L1)

PLAN 待做

共同 BLOCKER

Schema / 文件一致性

✓ STAGE 2

vault frontmatter / index / 反哺 schema / 引用链 — 5 脚本扫, 已 wired

演进对象vault 文件 / index.md / wikilink 引用 / 反哺路径 schema / cross-stack 引用

机制5 脚本: wiki-fix-frontmatter / wiki-fix-related-format / wiki-index-coverage / wiki-feedback-trace / cc-stack-coverage / wiki-detect-html-leak. 时间+阈值+事件三类触发. 强制 ADR 召回.

关联六要素memorystate 文件层是 memory/state 的物理基础, 一致性出问题就漂移

Skill 智能演进

★ PLAN

~75 skill 自身的提示词 / 步骤 / tool 调用逻辑 — 写完就死, 不会自己改

演进对象每个 skill 的 description / Step 序列 / 工具调用顺序 / fallback 策略

机制 (Hermes / Claude Skills 启发)Post-Mortem: 任务完后 AI 自动分析"为啥成 / 败" → Self-Optimization: 读自己 skill + 失败 log 自动改提示词 / 调步骤 → 知识共享: 通用 pattern 贡献回 superpowers

关联六要素intentworkflowmemory 改 intent 识别 / 改步骤 / 沉淀技巧

Workflow 自适应

★ PLAN

8 业务 flow + 4 反哺 path 真实跑通率 / 卡点 — 现在所有 flow 都是死的链路

演进对象flow 路径 / 节点顺序 / 卡点处理 / 跨 skill 接口契约

机制路径学习 (跑多了的 flow 加快, 死步骤 surface 删) · 卡点自动 retry / 跳过 · 跨 skill 接口漂移 detect (例 /B 改了 step 编号, /A 引用还在自动报)

关联六要素workflowstate flow 编排自适应 + 状态续跑

Tools / Systems 自愈

远期

MCP 调用 / 模型路由 / 外部 API 变化 — 现在都写死

演进对象MCP tool 调用 (zentao/gitlab/lark) / LLM 模型选择 / 外部 API schema

机制模型路由优化 (按任务类型选 Opus/Sonnet/Haiku, 看 token cost vs 任务复杂度) · API drift adapt (zentao 升级 API 自动迁移) · 异常自愈 (tool fail 自动 retry / 替代 / 降级)

关联六要素toolssystems 工具调用 + 外部系统两层都自愈

团队层智能化

更远期

反哺判定 / 推广策略 / 跨人 collective learning — 现在反哺是规则触发

演进对象反哺 6 信号 trigger / 推广节奏 / 跨人共识形成

机制从规则 trigger → 学习用户决策模式 (用户每次 "跳过" 就降权) · 推广策略学习 (谁在用 / 谁卡 / 为什么 → 调整推法) · 跨人 collective learning (一人发现的 pattern 自动 surface 给其他人)

关联六要素intentmemorysystems 学习用户意图 + 团队级 memory + 推团队系统

关键洞察 · L1 我们做了, 因为静态可扫. L2-L5 全卡 telemetry — 没数据 = 看不见 = 改不动. 整套智能化演进的瓶颈不是工程难度, 是 01 MVP 早一天上线 = 早一天有 telemetry = 早一天能动 L2. 这是 01 不是可选项的根本理由 (跟反哺机制对偶: 反哺把产出推团队 / ROADMAP 把工具体系拉向 AI 越用越懂).