前端工程 · 技术分享2026

Tech Sharing · 2026

前端 AI 编程实战

ISSUE→AGENTS→CODE→按时下班

分享人 - 欧阳志强

分享人 - 欧阳志强

Agenda

大纲 · 指令和工作流

Commands · 命令

/pm-init

校验 glab cli，保存 GitLab 项目配置。

/pm-spec

issue-explore 拉取相关 issue 和提交。

/pm-plan

make 细化任务，claim 执行任务。

/figma-design-explore

分析 figma design resources，组织代码。

Lifecycle · 一个需求的完整流程

  1. 初始化 — /pm-init 上下文建立
  2. SPEC
    • /pm-spec explore ⇒ 本地 SPEC
    • /pm-spec push ⇒ SPEC issue
    • /pm-spec done ⇒ gate ✓
  3. PLAN
    • /pm-plan make ⇒ 本地 plan
    • figma-design-explore ⇒ 分析设计稿
    • /pm-plan push ⇒ task issues
    • /pm-plan done ⇒ gate ✓
  4. CLAIM — /pm-plan claim ⇒ 分支 + draft MR
agenda

Phase · 初始化

/pm-init · 一次建立上下文

在代码仓库里跑一次，把 pm-coach 的项目配置写进 CLAUDE.md，之后每条指令自动读取。

› /pm-coach:pm-init

核心逻辑 · 八步

  1. 选语言 （zh / en，决定 SPEC、plan 的输出语种）
  2. 校验 glab auth，读仓库 CLAUDE.md 团队约定
  3. 冲突检查 （已有规则与 pm-coach 模型冲突 → 中断并确认）
  4. 确认 code_project 与 spec_project （可不同）
  5. 分配成员角色 （PM / PO / RD 必填）
  6. 确保 Harness 标签集存在 （SPEC、待自测、AI:*）
  7. 写 ## pm-coach config 到 CLAUDE.md
  8. 输出本地化摘要 → 提示 /pm-spec explore

举例 · 写入 CLAUDE.md

## pm-coach config
- language: zh
- code_project: klmobile/web      # 只放源码/MR
- spec_project: klmobile/issue    # 放 SPEC/feature/task
- spec_dir: specs
- plan_dir: plans
- labels: SPEC; AI:In Progress, AI:Done,
         AI:Human Review; 待自测, 待验收…
- roles:
  - @Ouyang — RD, FE
  - @wangkm — PM
  - @manguanghui — BE

幂等 · 改标签/角色/项目随时重跑

init · setup

Phase · SPEC — 1/3

/pm-spec explore · 摸清全貌

委派 agent 把需求的笔记、关联 issue、相关提交全拉回来，写成一份本地 SPEC。不写 GitLab。

› /pm-coach:pm-spec explore 798 # 按 CLAUDE.md 指定的 spec_project 拼接访问

核心逻辑

  1. 解析 feature （iid 或名称模糊匹配）
  2. 分类 links （同项目收集 iid，跨项目记 group/proj#iid）
  3. 委派 issue-explore agent： 读笔记 + 递归关联 issue + 每条 commit 的 diff（glab API，无需 clone）+ 跨项目 commit-mention
  4. 无本地 SPEC → CREATE；有 → diff 后 UPDATE
  5. 写 specs/<iid>-<slug>.md （frontmatter + Explore Summary + SPEC）

幂等 · 重跑只处理新笔记/新提交

举例 · specs/798-nubia-switch.md

---
linked_issues: [798, "extractor/…#1385"]
spec_issue: 817
status: pushed
---
## Explore Summary
### Commits  (跨项目 webcollection)
- bff3eb14 feat: 努比亚换机适配
- e10345a5 feat: 二维码引导分支重构
- 1bfedf64 feat: 文案修改 备份助手
- d330f026 fix: 无线网卡前置检测
- 79597310 fix: 强制 local 方案
### Code changes  (自动读 diff)
bff3eb14: tool-box-dialog.vue (M) …
1bfedf64: qrcode-dialog.vue (M) …
spec · explore

Phase · SPEC — 2/3

/pm-spec push · 发布 SPEC issue

本地 SPEC 为准，按 frontmatter 驱动：没有就建 SPEC issue，有就更新。远端被覆盖。

› /pm-coach:pm-spec push @specs/798-nubia-switch.md

核心逻辑

  1. 读 frontmatter （linked_issues[0] = feature，spec_issue 在不在）
  2. 状态前置：explored-need-push 或 pushed 才允许
  3. 无 spec_issue → CREATE：title SPEC: <feature>、desc=Explore Summary、label SPEC、link feature
  4. 有 → UPDATE：desc diff + 按 milestone find-or-create note
  5. closed-issue guard （SPEC issue 关闭 → 走 successor 流）
  6. 回写 spec_issue + status: pushed

desc=Explore Summary；notes=SPEC 正文，一个 milestone 一条

举例 · SPEC issue #817

# SPEC issue (klmobile/issue #817)
title: SPEC: 【努比亚换机】支持努比亚换机
labels: SPEC
links: relates_to  #798 (feature)

description = ## Explore Summary
  背景 / 目标 / 范围 / 非目标 /
  需求 / Commits / Code changes …

notes[0] = ## SPEC create V1.8.0 798
  ## SPEC
  ### 背景  ### 范围  ### 非目标
  ### 验收标准  ### 待决问题

# 重跑 push → 同 milestone note 原地编辑
# 进入新 milestone → 追加 ## SPEC update …
spec · push

Phase · SPEC — 3/3

/pm-spec done · 确认，第一道 gate

开发确认 SPEC 没问题，把 SPEC 文件状态更新为 user-confirmed-done —— 这是 claim 的前置之一。

› /pm-coach:pm-spec done @specs/798-nubia-switch.md

核心逻辑

  1. 读 frontmatter，status 必须是 pushed （explored-need-push → 叫你先 push；exploring → 重跑 explore）
  2. AskUserQuestion 确认 （SPEC #817 标 done？claim 需要）
  3. flip status: user-confirmed-done，报告 web_url

冻结后想改 → 重跑 explore 解锁

举例 · 文件状态机

# specs/798 的 frontmatter
spec_issue: 817
status: user-confirmed-done   ← done 落点

SPEC 文件状态流转：

exploring→ explored-need-push→ pushed→ user-confirmed-done ✓

PLAN 也有同样一条链，两链都到 ✓ 才能 claim。

spec · done gate

Phase · PLAN — 1/4

/pm-plan make · SPEC → 本地 plan

读取 SPEC，问几个真会影响拆分的问题，生成本地plan文件。（怎么做？怎么review？怎么验证）

› /pm-coach:pm-plan make @specs/798-nubia-switch.md

核心逻辑

  1. 读取 SPEC （Background / Scope / 非目标 / AC / Open questions）
  2. closed guard （feature 关闭 → 停），记 plan_milestone
  3. AskUserQuestion 澄清 Open questions （只问会改变拆分的）
  4. 若 Scope 偏移 → 改本地 SPEC，提示重跑 push
  5. 检测 test_cmd / typecheck_cmd （读 package.json / pyproject 等，落地为可移植命令）
  6. 写 plans/<iid>-<slug>.md （tasks 全 pending，无 iid） → 给人确认

举例 · plans/798-nubia-switch.md

---
feature_issue: 798
spec_issue: 817
plan_milestone: "V1.8.0"
status: explored-need-push
test_cmd: ""      # 无 runner → claim 跳过+报告
typecheck_cmd: ""  # CLAUDE.md 禁 AI 跑 eslint
tasks:
  - { title: 注册 nubia+meizu 功能元数据, status: pending }
  - { title: WIFI_TASK 品牌解析, status: pending }
  - { title: 品牌选择器放出, status: pending }
  - { title: 强制 local + 拦截路由器, … }
  - { title: 无线网卡前置检测, … }
  - { title: 二维码文案 + infoDisplay, … }
---
plan · make

Phase · PLAN — 2/4

explore-design-resources · Figma

如果issue中带有Figma链接：把设计稿拆成Layout/Components/Design Tokens，并映射到项目既有资源。不生成代码。

› /pm-coach:explore-design-resources ↳ https://www.figma.com/design/aB3xK9nU/feature-798-nubia?node-id=12:845

核心逻辑

  1. 从 issue 描述/笔记里抓 Figma 链
  2. get_figma_data 拉节点树
  3. 产出三段：Layout/Components/Design Tokens
  4. 每条映射到 既有组件/token （复用优先）
  5. 只标 genuinely new 的缺口
  6. 写 specs/<iid>-<slug>.design.md （可选深度步）

新组件的代码生成交给项目自有的 figma-to-component 技能，在 claim 时触发

举例 · design.md 骨架

# specs/798-nubia-switch.design.md

## Layout summary
WiFi 引导：单列、二维码居中、
  品牌专属纯文本引导（无图）

## Components
DeviceQrcode      → 既有，加品牌分支
AddWifiForensicDialog → 既有，排除列表移除
icon-nubia / icon-meizu → ⚠ 缺口，需补

## Design tokens
brand.nubia → 复用 meizu 通道
plan · design explore

Phase · PLAN — 3/4

/pm-plan push · 每 task → issue

把 plan 里每个还没 iid 的 task 建成 issue，挂到 feature 上（is_blocked_by），不是挂 SPEC。

› /pm-coach:pm-plan push @plans/798-nubia-switch.md

核心逻辑

  1. 读 plan，status 须 explored-need-push/pushed
  2. closed guard （feature 关闭 → 停）
  3. 对每个 无 iid 的 task：建 issue （desc = title + 一句描述 + 对应 AC）
  4. link feature is_blocked_by task
  5. 回写 iid / web_url / status: pending 到 plan
  6. flip plan status: pushed （已有 iid 的跳过，幂等）

此时不发任何 AI: 标签 —— 那是 claim 的事

举例 · plans/798 push 后

# 6 个 task 全部建成 issue，挂到 #798
tasks:
  - { iid: 818, title: 注册 nubia+meizu 元数据, status: pending }
  - { iid: 819, title: WIFI_TASK 品牌解析, … }
  - { iid: 820, title: 品牌选择器放出, … }
  - { iid: 821, title: 强制 local 方案, … }
  - { iid: 822, title: 无线网卡前置检测, … }
  - { iid: 823, title: 二维码文案+infoDisplay, … }
# feature #798 阻塞树
#798  is_blocked_by  #818–823
plan · push tasks

Phase · PLAN — 4/4

/pm-plan done · 确认第二道 gate

开发确认 plan 没问题，把 plan 文件状态更新为 user-confirmed-done —— SPEC 和 plan 两道 gate 都过，claim 才放行。

› /pm-coach:pm-plan done @plans/798-nubia-switch.md

核心逻辑

  1. 读 plan frontmatter，status 必须是 pushed （explored-need-push → 叫你先 push；exploring → 重跑 make）
  2. AskUserQuestion 确认 （plan 标 done？claim 还要 SPEC 也 done）
  3. 把 plan 文件状态更新为 user-confirmed-done，报告 web_url
  4. SPEC 还没 done → 提醒先跑 /pm-spec done

冻结后想改 → 重跑 make 解锁

explored-need-push→ pushed→ user-confirmed-done ✓

举例 · 双 gate

# plans/798 frontmatter
status: user-confirmed-done

# claim 启动前的 gate 检查
SPEC  (specs/798).status   = user-confirmed-done ✓
PLAN  (plans/798).status   = user-confirmed-done ✓
──────────────────────────────
/pm-plan claim @plans/798  → 放行
两道 gate ∧ SPEC ∧ Plan ⇒ claim 可跑
plan · done gate

Phase · CLAIM — 1/2

/pm-plan claim · 每 task 一闭环

SPEC & PLAN 都确认后：建分支、派 agent 写代码、跑校验，每个检查点都写回 plan。

› /pm-coach:pm-plan claim @plans/798-nubia-switch.md

核心逻辑 · task核心循环

  1. 先检查：task 没有 iid → 停下来，叫你先 push
  2. 清掉旧的 AI:* 标签，标上 AI:In Progress，plan 里也记 in_progress
  3. 建分支 pm/<feature>-<task>-<slug> （已有分支 → checkout 续跑）
  4. 派一个 general-purpose agent：把 task、验收标准、SPEC 上下文都喂给它，让它实现并补测试
  5. 跑 test_cmd / typecheck_cmd （空就跳过并说明，不静默放行）
  6. 每个检查点都写回 plan 的 frontmatter （开始 / 建分支 / 收尾）

中途中断 → 重跑 claim 会接着既有分支跑，不重做

举例 · AI 标签生命周期

AI:In Progress → AI:Done 或 AI:Human Review 
# 798 的 6 个 task 推进（示意）
iid  title                branch              status
818  注册功能元数据        pm/798-818-meta     in_progress
819  WIFI_TASK 品牌解析    pm/798-819-wifi     in_progress
820  品牌选择器放出        pm/798-820-picker   in_progress
821  强制 local 方案       pm/798-821-local    in_progress
822  无线网卡检测          pm/798-822-netsh    in_progress
823  二维码文案            pm/798-823-qrcode   in_progress

人工标签（待自测/待验收）始终留给人，AI 不碰

claim · mechanism

Phase · CLAIM — 2/2

/pm-plan claim · draft MR 或等待开发介入

校验过了 → 开 draft MR、标 AI:Done；卡住了 → 标 AI:Human Review、记下 blocker，跳到下一个 task。

› /pm-coach:pm-plan claim @plans/798-nubia-switch.md

核心逻辑 · 收尾分支

  1. Done：commit + push 分支，开 draft MR （同项目写 Closes #iid；跨项目用全 ref）
  2. 已经有开着的 MR → 复用那个 !id，不重复开
  3. 标 AI:Done，plan 里写 status: done + mr
  4. 卡住了：有歧义、缺决策、或修不了 → 标 AI:Human Review，记下 blocker:
  5. 整个 run 跨 task 继续跑 （一个卡住不停其它）
  6. 想重跑 human_review 的 task：把它的 status 改回 in_progress，再 claim 一次

举例 · MR 与 blocker

# Done 的 draft MR 描述
Source: pm/798-818-meta → main
Draft: true

Closes klmobile/issue#818

注册 androidnubiamachinegtool /
androidmeizumachinegtool 四个条目…

# Blocked 的 plan frontmatter
- iid: 820
  title: 品牌选择器放出
  status: human_review
  branch: pm/798-820-picker
  blocker: nubia logo 资源缺失，
           需设计确认后补 icon-nubia
claim · resolve

Review & Safety

哪些交给 AI，哪些必须人审

✓适合交给 AI

  • 样板 / 脚手架代码
  • 单元测试与用例
  • 纯函数重构、命名优化
  • 注释、文档、i18n 文案
  • 常规 Bug 的定位与修复建议

✗必须人审

  • 核心业务逻辑与状态机
  • 鉴权、支付、权限边界
  • 敏感数据与密钥处理
  • 架构与依赖决策
  • 性能关键路径与并发
review · safety

Golden Formula · 我的黄金公式

我的黄金公式

1

建立上下文

Explore Issue / Commit / File Path

2

多轮询问

一般会用 “Ask me some questions”，但我用 “grill me”

3

Make Plan

建立 plan 文件，todos list 就行，反复确认

4

最后一句

作为 subAgent 在 background 并行(parallel)运行

golden formula

Q & A

展示

end