Gaoti's Knowledge Base

AI Workflow Sharing

Properties1
tagstype/moc, area/ai, topic/method/ai-collab

18分钟阅读

AI Workflow 分享

🎤 照着讲的逐字稿草案:相关私有笔记

关于本场分享

📖 关于本文档

这是一份 AI workflow 方法分享文档,涵盖共同语言、基础方法论与进阶实践。内容按模块组织,不必在一次分享里全部讲完——现场会结合大家的提问和兴趣,选取最相关的部分展开。

  • 分享时长:预留 30 分钟以上 的讲解与讨论时间,重点放在互动,而非赶进度。
  • 分享前先看:Glossary - AI Workflow 术语表(约 3 分钟扫读,避免讨论时术语各说各话)。
  • 如何阅读:用顶部 目录 或下方大纲跳转。
  • 会后自学:未在现场展开的内容,可按角色阅读 按角色深读 章节,或查看文末 附录 中的详细子页面与参考资料。

分享大纲

模块章节参考时长说明
—Glossary(分享前建议先看)约 3 分钟会前或开场先扫术语表
1分享定位约 3 分钟介绍分享背景与目标听众
2开场问题约 5–10 分钟从三个问题切入,欢迎提前思考、现场提问
3核心观点与工作流约 5 分钟贯穿全场的主线框架
4共同语言 — AI Harness 101 (上下文与护栏入门)约 5 分钟跨职能共同语言与 harness 心智模型
5基础篇方法论约 5–10 分钟 / 主题结合大家关心的场景,深入 1–2 个方向
6进阶篇约 5–8 分钟 / 主题面向开发与 QA 的工程实践(按需展开)
7交给 AI 前的 7 个问题约 3 分钟可带走的 checklist,分享中或收尾均可使用
8按角色深读—会后自学导览;现场会做简要指路
9下一步约 2 分钟后续团队实践方向(时间允许时分享)

分享安排说明

⏱ 分享安排说明

本次分享预留 30 分钟以上,内容会根据现场讨论灵活调整,不会要求在一次分享中覆盖以上全部模块。
以下是几种可能的分享路径,供参考:

  • 路径 A(建立共识):定位 → 开场问题 → 核心观点 → 结合讨论深入 1 个方法论主题
  • 路径 B(工程实践):定位 → 核心观点 → 进阶篇(如 Agentic execution (Agent 化执行) / Workflow design (工作流设计))→ 7 个问题 checklist
  • 路径 C(分析方法论):定位 → 开场问题 → 基础篇 1–2 个主题 → 7 个问题 checklist
    未在现场展开的内容,请通过 按角色深读 或 附录 自行阅读。

Glossary:AI Workflow 术语表

📚 分享前建议先看

跨职能讨论前,先扫一遍术语表,避免 harness、guardrail、verification、source of truth 等词各说各话。会中也可随时回来查。
Glossary - AI Workflow 术语表

  • 解决的问题:避免术语阻塞讨论。
  • 适用场景:分享前扫盲、跨职能对齐、会中随时查阅。
  • 输出物:轻量 AI workflow 术语表。

分享定位

📌

  • 不是 FE 技术分享:这是一份关于“如何把 AI 用进日常工作流”的通用方法分享。
  • 核心问题:AI 不是一个单独工具,也不只是写代码助手;它可以参与分析、检索、执行、验证和复盘。
  • 关键判断:AI 输出是否稳定,不只取决于模型,也取决于我们如何设计 workflow、context、guardrail 和 verification。
  • 目标听众:全体同事,角色范围收敛为四类:开发、产品、设计、QA。
  • 文档结构:只分两个 part:基础篇面向四类角色全体;进阶篇主要面向开发和 QA。
  • 阅读方式:先看 Glossary 对齐术语,再用 AI Harness 101 建立心智模型,再按角色跳到对应 workflow。

开场问题

💬

我们讨论什么:这次分享不是工具清单,而是讨论如何让 AI 在真实工作里稳定、可控、可复用。
我们会从以下三个问题开始,也欢迎你提前思考:

  1. Skill 真的有必要吗?你装了多少 skill?其中有多少是真的在日常 workflow 里反复用上的?
  2. 怎么才能约束 AI?不同 Agent 的约束方式是一样的吗?
  3. 不同 Agent 之间是否有通用标准或行业共识?面对每天都在推出/更新的各种标准,我们应该追哪个、忽略哪个、沉淀哪个?
    这些问题可以自然引出后面的核心概念:harness、context hygiene、guardrail、verification、source of truth,以及为什么团队需要先讨论 workflow,而不是先讨论某一个具体工具。

核心观点与工作流

🎯

核心判断:AI 真正有价值的地方,不是“帮我生成一段答案”,而是进入完整工作链路。

收集上下文 → 建立假设 → 查找证据 → 形成判断 → 执行改动或产出 → 验证结果 → 沉淀复用

如果只用 AI 做“回答”或“生成”,很容易得到看似合理但不可靠的结果。更好的方式是把 AI 放进一个有证据、有边界、有验证的 workflow 里。
[!warning] 🧭 分层原则:不是每个任务都跑全流程

这套 AI workflow 更像是按复杂度逐步加码的工具栈,而不是每次都强制走完整流程。

  • 轻量任务:直接给真实对象、明确 scope、跑最小验证即可。
  • 需求模糊:先做需求澄清,问清隐含假设、边界、失败模式和验收标准。
  • 跨模块 / 高风险 / 需要团队共识:再进入 OpenSpec,让 delivery contract 可 review、可 version、可验证。
  • 执行阶段:用 agent 执行纪律保证 plan、最小改动、TDD / debug / review 和 verification 闭环。
  • 影响面不清楚:常规 grep / LSP 不够时,再引入 code graph、KG memory 或跨会话历史上下文。

共同语言 — AI Harness 101 (上下文与护栏入门)

目标:先建立共同语言和通用 AI workflow 心智模型。无论是开发、产品、设计还是 QA,都能用这些方法提升分析、协作和沉淀质量。

基础篇方法论

以下三个方向面向全体同事。分享现场会结合大家的关注点,选取 1–2 个 主题展开;其余内容可会后阅读。

Evidence-first (证据优先)

  • 解决的问题:减少空泛建议,让 AI 先绑定真实证据。
  • 适用场景:debug、PR review、CI failure、线上问题、需求判断。
  • 输出物:evidence 清单。
  • 详细页:Evidence-first

Context building (上下文构建)

  • 解决的问题:让 AI 先画系统地图,再进入判断或执行。
  • 适用场景:不熟悉模块、跨 repo、复杂业务流、历史包袱系统。
  • 输出物:系统地图 / owner boundary。
  • 详细页:Context building

Hypothesis loop (假设循环)

  • 解决的问题:把一次性回答改成可验证的假设循环。
  • 适用场景:复杂 bug、线上异常、性能问题、间歇性失败、数据不一致。
  • 输出物:hypothesis 列表 / 验证动作 / 收敛结论。
  • 详细页:Hypothesis loop

进阶篇

以下内容主要面向 开发与 QA。分享现场会按大家的工作场景,选取最相关的 1–2 个 主题展开。
[!warning] ⚠️

目标:把 AI 从“辅助分析”推进到可执行、可验证、可 review 的工程和 QA workflow。重点关注 spec、验证、PR review、Agentic execution (Agent 化执行) 和质量闭环。
[!warning] 🔎 进阶篇重点讨论的三个边界

这部分可以围绕三个问题展开,而不是按工具逐个介绍:

  • Clarification 边界:grill-me 这类拷问流程,和 Superpowers 的 brainstorm 分别适合什么时候用?
  • Context 边界:Graphify / code graph 这类图谱 skill,如何把代码知识拆成可用的结构,而不是只画一张漂亮的图?
  • Execution 边界:Superpowers 作为 executor,什么时候应该直接执行,什么时候必须先进入 OpenSpec?

Minimum viable change (最小可验证改动)

  • 主要角色:开发、QA。
  • 解决的问题:让 AI 产出最小、可验证、可 review 的改动。
  • 输出物:小 scope change + 验证结果。
  • 详细页:Minimum viable change

AI-assisted review (AI 辅助评审)

  • 主要角色:开发、QA;产品、设计可用于评审。
  • 解决的问题:让 AI 扩大检索面,但由人决定 severity 和优先级。
  • 输出物:review findings / risk list。
  • 详细页:AI-assisted review

Agentic execution (Agent 化执行)

  • 主要角色:开发、QA。
  • 解决的问题:让 AI 把任务推进到可判断结果,而不是只生成 checklist。
  • 输出物:执行结果 / 本地验证 / 远端状态。
  • 详细页:Agentic execution

AI workflow escalation (复杂任务升级路径)

  • 主要角色:开发、QA;产品、设计理解协作入口。
  • 解决的问题:判断任务应该停在澄清、进入 brainstorm、补 context、写 OpenSpec,还是交给 executor。
  • 输出物:从模糊问题到可执行任务的升级路径。
  • 详细页:AI workflow escalation

Knowledge capture (知识沉淀)

  • 主要角色:开发、产品、设计、QA。
  • 解决的问题:把一次性分析沉淀为可检索、可复用的团队资产。
  • 输出物:规则 / checklist / ADR / docs update。
  • 详细页:Knowledge capture

Workflow design (工作流设计)

  • 主要角色:开发、QA;产品、设计理解协作边界。
  • 解决的问题:把个人 AI 用法升级为团队级 workflow 和 spec contract。
  • 输出物:input → execution → [[10 - 项目 Projects/AI Workflow Sharing/Glossary - AI Workflow 术语表#verification|verification]] → archive 工作流。
  • 详细页:Workflow design

交给 AI 前的 7 个问题

✅

怎么用:每次把较复杂任务交给 AI 前,可以先用这 7 个问题收紧上下文和成功标准。
每次使用 AI 做较复杂任务前,可以问:

  1. 真实对象是什么?PR / issue / URL / log / file path 是哪个?
  2. 哪些是事实,哪些是假设?
  3. 当前任务的 owner boundary 是什么?
  4. 成功标准是什么?本地和远端分别怎么验证?
  5. 最小改动面是什么?有没有扩大 scope?
  6. AI 的输出需要人工确认什么?
  7. 这次学到的东西是否值得沉淀到文档?

按角色深读

以下内容供 会后自学。如果你错过了现场分享,或想按自己的角色深入阅读,可以从这里找到推荐入口。

开发

QA

产品

设计

方向跳转地图

按你的角色或当前任务,可以沿以下路径顺序阅读相关主题。
| 链路 | 路径 |
| --- | --- |
| 基础篇入口 | AI Harness 101 → Glossary - AI Workflow 术语表 |
| 基础篇分析链路 | Evidence-first → Context building → Hypothesis loop |
| 开发 / QA 进阶链路 | Minimum viable change → AI-assisted review → 相关私有笔记 → Agentic execution → AI workflow escalation → Workflow design |
| 复杂任务升级路径 | grill-me 澄清问题 → Superpowers brainstorm 比较方案 → Graphify / code graph 拆 context → OpenSpec 固化 contract → Superpowers executor 最小执行 + verification |
| 产品 / 设计常用链路 | Evidence-first → Context building → AI-assisted review → Knowledge capture |

下一步

➡️

分享之后,团队可以沿以下方向继续实践:

  • 收集 3 个 能代表真实 workflow 的案例(不限于工程技术场景)。
  • 每个案例按统一结构整理:任务背景 → AI 如何介入 → 人如何判断 → 如何验证 → 可复用规则。
  • 持续沉淀到文档与团队规范,形成可检索、可复用的 AI workflow 资产。

附录:深度文档与参考资料

补充参考资料

详细子页面

AI Harness 101
Evidence-first
Context building
Hypothesis loop

Minimum viable change
AI-assisted review
Agentic execution
AI workflow escalation
Knowledge capture
Workflow design

此文件夹下有12条笔记。