# 派单消息样例 · PL → ai-agent-dev

| 字段 | 内容 |
|---|---|
| 派单时间 | 2026-05-16 周四 10:32 |
| Sender | product-lead |
| Receiver | ai-agent-dev |
| Task ID | postcard-feature #3 |
| 上游 | PRD v1.0（[00-prd.md](./00-prd.md)）/ ADR-001（[01-adr-model-selection.md](./01-adr-model-selection.md)）|
| 下游 | progress/ai-agent-dev.md（[03-progress.md](./03-progress.md)）|
| Hook 校验 | `validate-task-schema.sh` 6 段齐全 ✓ |
| deck 集成 | spec §14.1 slide 31（图 D2 派单 6 段 schema 彩色标注） |

## 真实 SendMessage（6 段 schema）

```
SendMessage({
  to: "ai-agent-dev",
  summary: "接 task #3：三步链路实现",
  message: "
@ai-agent-dev 接 task #3：旅游明信片三步链路实现

【① 目标 Why】
实现旅游明信片三步流水线，让用户上传照片 + 一句话 → 30s 出完整明信片
（200 字文案 + 1024×1024 卡片图）

【② AC · 5 条必守】
AC1: 单次生成时延 ≤ 30s（P95）
AC2: Vision 主体识别准确率 ≥ 85%（5 道盲测）
AC3: 文案与照片相关性人工评分 ≥ 4/5（业务方 + qa 各 3 人盲评）
AC4: 文生图风格与关键词色调 hash 相似度 ≥ 0.75
AC5: 单次成本 ≤ ¥0.30（实测 ¥0.21，留 ¥0.09 安全余量）

【③ 依赖】
前置已就绪：
- ml-engineer 出 ADR-001（全豆包 2.0 栈选型完成，commit abc1234）
- backend-dev 提供 API contract（POST /postcards，定义 Pydantic schema）
后置触发：
- 链路完成后通知 qa-engineer 准备 E2E 测试题（5 道盲测）
- code-reviewer 在 #3 PR 提交后启动 review + SIT Audit

【④ 产物路径】
代码：
  backend/app/agents/postcard.py        # 三步链路主入口
  backend/app/agents/postcard_prompts/  # prompt 版本管理目录
    ├── v1_vision.md
    ├── v1_llm.md
    └── v1_imagegen.md
配置：
  backend/app/config/llm_routing.py     # Pro → Lite → Mini fallback 链

进度报告：
  progress/ai-agent-dev.md              # 自报 SIT 证据 + AC 自验
测试：
  backend/tests/unit/test_postcard_*.py # Unit
  backend/tests/sit/test_postcard_e2e.py # SIT（dev 自跑）

【⑤ 预算】
Time: 2 天（含 Unit + SIT，不含 code review 等待）
Token: 200k / sprint（cache hit ≥ 60%）
Cost: ¥0.30 / 张（AC5 必守，5 道盲测 30 次 cost ≤ ¥10）

【⑥ Skills 必走】
- agf-wiring-multi-llm-sdk         # 多 LLM SDK 接入（OpenAI 兼容 adapter）
- superpowers:test-driven-development # 先写 Unit test 再写 prompt
- agf-running-sit-tests            # SIT 自跑 + 证据落 progress/

【⚠ Plan Mode 触发点】
按 .claude/agents/ai-agent-dev.md，以下变更必先进 Plan Mode：
- 切换 LLM 模型（豆包 → 别家）
- prompt 重构（如三步合二步）
- 引入新外部工具调用
若触发，先 SendMessage PL 拿授权再动手
"
})
```

## 6 段对应 deck 图 D2 的彩色标注

| 段 | 颜色（D2 图中）| 在派单消息中的标识 |
|---|---|---|
| ① 目标 | coral 红 | `【① 目标 Why】` |
| ② AC | gold 黄 | `【② AC · 5 条必守】` |
| ③ 依赖 | green 绿 | `【③ 依赖】` |
| ④ 产物路径 | navy 深蓝 | `【④ 产物路径】` |
| ⑤ 预算 | gold 黄 | `【⑤ 预算】` |
| ⑥ Skills | coral 红 | `【⑥ Skills 必走】` |

## Hook 校验细节（validate-task-schema.sh）

派单前 hook 自动校验 6 段都有 → 缺一段 exit 1 阻断：

```bash
# 模拟漏 ④ 产物路径段的违规派单
$ SendMessage(...含 ①②③⑤⑥ 但缺 ④)
[PreToolUse:validate-task-schema] ❌ Missing section ④ 产物路径
[PreToolUse:validate-task-schema] exit 1
SendMessage aborted. Add missing section and retry.
```

PL 补齐 ④ 段后重发 → hook pass → 派单送达。

## 设计取舍：6 段为什么必须齐全

| 段 | 缺了的后果 |
|---|---|
| ① 目标 | dev 不知道 why → 跑偏（"做了对方不要的"）|
| ② AC | dev 不知道"什么算做完" → 自定义验收（reviewer 拒收）|
| ③ 依赖 | dev 不知道前置完成度 → 卡住 / 跑空 |
| ④ 产物路径 | reviewer 不知道哪里看 → 漏审 |
| ⑤ 预算 | cost 失控 → 业务方拒签 |
| ⑥ Skills | 漏走 hook 强制路径 → 失败回路 |

**核心**：6 段是"上下游契约"，不是表面要求。PL 派单慢 5 min 远胜 dev 跑偏 2 小时。
