69 篇文档带有标签「workflow」

用完整流程判断自己当前卡在哪一环，再决定该进入哪个知识方向或覆盖层。

用一条默认学习路径把流程地图、知识方向和覆盖层串起来，避免在产品名之间反复横跳。

把 4 条最常用的 AI coding workflow 写成可直接照着执行的 SOP、输入模板和验收清单。

用复杂度、适用场景和产出物来比较 BMAD、Spec Kit、OpenSpec 与 Superpowers，避免把不同层的问题混成一类。

用开发方式而不是单一工具名来组织 AI 协作，先决定默认入口、控制边界和人机分工。

Bugfix / Refactor / Test 的定位、适合任务和默认人工接管点。

把日常维护任务收成一条最小闭环：先复现、再最小改动、最后回归验证。

为维护型任务选择最顺手的工具组合：终端、IDE 和平台各自承担什么。

用三类任务合同来组织团队级 AI 工作流，避免在同一轮里混合诊断、重构、测试和交付。

通过一个完整维护任务示例，说明 bugfix、补测试和小步重构如何串成最小闭环。

当维护任务开始失去边界时，判断什么时候停下、什么时候切换到更重的工作流。

Bugfix / Refactor / Test 的代表案例，以及最适合搭配的工具或框架。

Bugfix / Refactor / Test 需要的权限边界、验证方式和失败模式。

Bugfix / Refactor / Test 的输入、输出、标准步骤和验收证据。

什么时候优先用 Bugfix / Refactor / Test，什么时候不要用。

Issue / Jira -> Draft PR 的定位、适合任务和默认人工接管点。

把清晰任务从 issue 或 Jira 收口成一条可 review 的 draft PR 交接线。

为平台交接流选择默认工具组合：谁负责任务系统、谁负责仓库执行、谁负责最终 review。

通过一个清晰任务示例，说明 issue 到 draft PR 的交接链如何落地。

当任务系统和 PR 流不再稳定时，判断什么时候停下，什么时候切到其他工作流。

Issue / Jira -> Draft PR 的代表案例，以及最适合搭配的工具或框架。

Issue / Jira -> Draft PR 需要的权限边界、验证方式和失败模式。

Issue / Jira -> Draft PR 的输入、输出、标准步骤和验收证据。

什么时候优先用 Issue / Jira -> Draft PR，什么时候不要用。

Local -> Background -> Cloud 的定位、适合任务和默认人工接管点。

先在本地收敛问题和边界，再把可执行部分交给后台，最后在平台或 PR 系统中收口结果。

为三层 handoff 选择默认工具组合：谁负责本地发现，谁负责后台执行，谁负责平台收口。

通过一个从本地定位问题到后台执行再到 PR 收口的例子，说明三层 handoff 如何连成一线。

当三层 handoff 开始制造噪音时，判断什么时候停下、缩回或改走别的流程。

Local -> Background -> Cloud 的代表案例，以及最适合搭配的工具或框架。

Local -> Background -> Cloud 需要的权限边界、验证方式和失败模式。

Local -> Background -> Cloud 的输入、输出、标准步骤和验收证据。

什么时候优先用 Local -> Background -> Cloud，什么时候不要用。

Parallel Worktrees / Multi-Agent 的定位、适合任务和默认人工接管点。

把长任务拆成低耦合 lane，在独立 worktree 或 agent 会话中并行推进，再由 owner 收口验证。

为并行 lane 选择默认工具组合：谁负责 owner，谁负责执行，谁负责最终审阅。

通过一个跨实现、测试和文档 lane 的例子，说明并行 worktree 如何收口成可 review 交付。

当并行 lane 开始制造冲突和协调噪音时，判断什么时候停下、缩回和换流程。

Parallel Worktrees / Multi-Agent 的代表案例，以及最适合搭配的工具或框架。

Parallel Worktrees / Multi-Agent 需要的权限边界、验证方式和失败模式。

Parallel Worktrees / Multi-Agent 的输入、输出、标准步骤和验收证据。

什么时候优先用 Parallel Worktrees / Multi-Agent，什么时候不要用。

Playbook 继续保留，但从二阶段开始它属于工作流内容形态，用来承载可直接执行的操作手册。

用输入、输出、边界、验证和证据字段把 prompt 从聊天提问升级成可复制的团队任务合同。

用需求、计划、执行、验证、review 和 PR 的显式 handoff，把 AI 开发从聊天式协作升级为标准交付流程。

Spec-First 的定位、适合任务和默认人工接管点。

在开始大一点的实现前，先用 spec 收口范围、阶段和验收，再进入执行。

为 spec-first 工作流选择合适的执行入口、补位工具和 review 收口方式。

通过一个结构性任务示例，说明 spec 如何承接范围、阶段和验证。

当 spec 写得过重或阶段拆得过细时，判断什么时候收缩，什么时候切换工作流。

Spec-First 的代表案例，以及最适合搭配的工具或框架。

Spec-First 需要的权限边界、验证方式和失败模式。

Spec-First 的输入、输出、标准步骤和验收证据。

什么时候优先用 Spec-First，什么时候不要用。

Terminal-First Repo Pairing 的定位、适合任务和默认人工接管点。

把终端、仓库边界和命令验证收成一条默认的 repo pairing 工作流。

为终端主入口工作流选择默认工具组合：谁负责执行，谁负责补平台或长任务。

用一个真实仓库内任务示例，说明终端主入口如何把计划、执行和验证放到一条线里。

当终端主入口开始失去边界时，判断什么时候缩小任务，什么时候切到别的流程。

Terminal-First Repo Pairing 的代表案例，以及最适合搭配的工具或框架。

Terminal-First Repo Pairing 需要的权限边界、验证方式和失败模式。

Terminal-First Repo Pairing 的输入、输出、标准步骤和验收证据。

什么时候优先用 Terminal-First Repo Pairing，什么时候不要用。

AI 技术分享大纲，探讨从"AI 优先"理念到"Harness 工程"实践的演进路径

帮助个人工程师把已经验证有效的 AI coding 方法，逐步迁移为团队可复用的规则与协作方式。

按任务类型定义 bugfix、refactor、test、new feature、research、review/PR 的固定链路，减少每次从零设计流程。

解释什么时候应该用多 Agent，什么时候不该用，以及串行 handoff 与并行拆分各自需要什么前提。

先判断自己当前处在哪个流程阶段，再决定进入哪个知识方向，而不是直接在产品名之间横跳。

旧赛道透镜：保留 prompt、contract 和任务流相关文章的历史入口，但不再承担一级知识骨架职责。