agentic-opc-workflow

name	agentic-opc-workflow
description	把 OPC 创作者的模糊目标整理成可交给 Agent 执行的上下文包、任务卡、验收标准和人类判断门。 触发词：Agent 工作流 / Agentic / 让 Agent 做 / 上下文包 / 任务卡 / 验收标准 / 一人公司工作流 / 7 天验证

Agentic OPC Workflow — 让 Agent 可执行，但不替你判断

Agentic 的核心不是“多弄几个 Agent”。

真正有用的是：把目标、上下文、任务边界、输出格式、验收标准和人类判断门组织清楚。这样 Agent 才能放大你，而不是把你带跑。

什么时候用

用户想把一个 OPC 项目、验证计划、内容流程、调研流程、产品推进流程交给 Agent 协作时使用。

工作流程

Step 1 · 明确任务类型

判断用户要的是：调研、用户访谈、原型验证、内容生产、销售线索、复盘，还是决策压测。

如果上下文不足，先用 AskUserQuestion 问 1 个最关键问题，不要一次问一串。优先问：

这个 Agent 最容易在哪一步替你做了不该做的判断？

Step 2 · 建上下文交接包

按 @references/agent-context-handoff.md 把背景、目标、约束、材料、反例、验收标准写清楚。

Step 3 · 拆任务卡

每个 Agent / 每个任务都要有：角色、输入、动作、输出、验收标准、禁止事项。

Step 4 · 放人类判断门

按 @references/human-gates.md 设置关键检查点：Agent 到哪一步必须停下来等人确认。

Step 5 · 设计 OPC 验证闭环

用 @references/opc-validation-loop.md 把流程落到 72 小时 / 7 天 / 14 天验证动作上。

输出格式

## Agentic 工作流目标
{这套工作流要帮用户放大什么能力}

## Context Pack
{给 Agent 的完整上下文}

## Agent Task Cards
### Agent 1：{角色}
- 输入：
- 动作：
- 输出：
- 验收标准：
- 禁止事项：

## Human Gates
| 节点 | 为什么必须人工判断 | 检查问题 |
|---|---|---|

## 7 天验证路线
- Day 1-2：
- Day 3-4：
- Day 5-7：

## 停止线
{N 天内 X 指标没达到 Y，就暂停/转向/缩小范围}

规矩

• 不要设计大而全自动化。OPC 要小、快、可验。
• 不要让 Agent 直接替用户做对外承诺。
• 每个 Agent 任务必须有验收标准。
• 每条工作流必须有停止线。
• 需要补上下文时只问 1 个问题；问完先产出一个可执行版本，不要把用户拖进长访谈。