帮我成交第一个 OPC 项目的 Hermes 落地全拆解

来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, OpenClaw, 编程, 大模型
原文链接： https://mp.weixin.qq.com/s/p--PspT8OMYrnRTAzB-ELQ

摘要

上一篇《我用 Hermes 成交了第一个 OPC 项目》发出后，很多读者对这套 Agent 的真实落地细节感兴趣。 所以这篇我把这套方案完整的搭建方式、流程 skills、文档模板都拆解出来。 这套方案也不限于 Hermes Agent。你也可以迁移到 OpenClaw、Claude Code、Codex 里使用，关键是把 PM 岗位拆成固定流程、可调用 skills 和可复用文档模板。 ## 先把 PM Agent 定义成一个岗位 PM Agent 是一个产品经理角色的 Agent，不是通用聊天助手。 它的身份定义很窄： 角色：产品经理 核心职责：需求对接 → 需求清...

核心内容

上一篇《我用 Hermes 成交了第一个 OPC 项目》发出后，很多读者对这套 Agent 的真实落地细节感兴趣。

所以这篇我把这套方案完整的搭建方式、流程 skills、文档模板都拆解出来。

这套方案也不限于 Hermes Agent。你也可以迁移到 OpenClaw、Claude Code、Codex 里使用，关键是把 PM 岗位拆成固定流程、可调用 skills 和可复用文档模板。

先把 PM Agent 定义成一个岗位

PM Agent 是一个产品经理角色的 Agent，不是通用聊天助手。

它的身份定义很窄：

角色：产品经理
核心职责：需求对接 → 需求清单 → 报价 → 合同 → PRD
信仰：先理解，再定义。结构先于细节。优先级是 PM 最重要的决策。
边界：产出到文档为止，不越界写代码。

这个狭窄的边界是关键。如果一个 Agent 同时又是 PM 又是程序员，它会在写需求时忍不住跳到技术方案，反而失去了 PM 视角的独立性。

PM Agent 的工作严格遵循五个环节的顺序推进：

① 需求挖掘与追问
↕ 先拿业务背景，再做 6 维度推演 → 提问 → 闭环
↓
② 功能需求清单输出 ← 甲方确认，范围锁定
↓
③ 报价
↓
④ 合同起草
↓
⑤ PRD ← 合同签完后给开发

每份产出物生成后立即过红线检查，不改完不发出。

每一步都要对应 skill 和产出物

需求挖掘要先拿到业务上下文

这个环节不是一上来就追问客户，更不是把 6 个问题一次性抛出去。

它分两步走。

第一步，先了解业务场景。

先拿到项目背景、现有系统关系、关键数据从哪里来、流向哪里去。这些信息可以来自客户口头描述、已有文档、接口说明、历史系统截图，形式不重要，关键是先有上下文。

没有背景信息就开始追问，看起来很积极，本质上是在瞎问。客户自己也未必知道真实需求，PM Agent 要先把业务链路拼出来，再判断哪里缺口最大。

第二步，再做推演与追问。

拿到基础信息后，Agent 对每一个模糊需求做内部推演，从 6 个维度检查空白点：
维度推演什么Source（来源）这个需求是确认要做的，还是随口说的？谁提的？Flow（流向）完整链路是什么？谁触发、谁处理、谁消费？反方向要不要走通？Failure（失败）什么情况下会坏？断了、超时、异常数据怎么办？Dependency（依赖）依赖哪些外部条件？有没有文档、测试账号、技术支持？Boundary（边界）"做完"怎么定义？哪些明确不属于这个模块？Validation（验收）验收时看什么？怎样算通过？以哪个系统为准？

推演发现空白后，再把空白转成一个问题问客户。一次只问一个维度，客户回答后重新检查所有维度，直到闭环。

推演（内部思考）
↓
发现空白 → 转化为 1 个问题，向客户提问
↓
客户回答 → 更新推演，重新检查所有维度
↓
仍有空白 → 继续追问下一个维度
↓
全部闭环 → 路由到文档对应位置

涉及的 Skill：

• ●discovery-probing — 需求推演与追问循环

• ●client-delivery — 核心工作流 skill，包含交付纪律
  纪律：

• ●先了解业务场景，再推理追问。没有背景信息直接问，就是瞎问。

• ●一次最多问一个维度，不要一次抛 6 个问题。
• ●客户回答后重新检查所有维度，再决定下一个问题。
• ●全部闭环才写入需求清单。未闭环的先放待确认表。
• ●客户不耐烦了就停。客户说"先出方案"时，把未闭环项写进待确认表。
  产出物：

需求梳理笔记（内部，飞书文档）
├── 业务背景与系统关系（来自第一步信息收集）
├── 追问闭环的需求条目（来自推演-提问循环）
├── 数据流向（已确认）
├── 外部依赖清单（影响报价的前置条件）
└── 待确认事项列表（未闭环的维度）

功能需求清单用来锁定范围

这是最关键的环节。 功能需求清单是甲方唯一会确认的需求文档，后续所有报价、合同、开发都锚定它。

涉及的 Skill：

• ●client-delivery — 需求清单纪律模块

写作纪律（PM Agent 的核心训练数据，每次输出前自检）：

❌ 不自创需求 — "这个系统应该有个XX功能"不是需求
❌ 不写条件分支 — "如果A则B否则C"是解释，不是需求
❌ 不暴露技术系统名 — 对甲方说"我的会员"，不说内部或第三方平台名称
❌ 章节不重复 — 同一件事只在一个章节出现
❌ 不写解释 — 解释性背景不放进需求清单，需求清单里只写"做什么"
✅ 每条需求可追溯到甲方原话
✅ 不确定的放待确认表
✅ 只写"做什么"和"不做什么"

产出物模板——《功能需求清单》：

# [项目名称] 功能需求清单

一、系统对接

1.1 [甲方系统A] —— 模块说明
1.1.1 [具体需求项描述]
1.1.2 [具体需求项描述]
1.1.3 [具体需求项描述]
1.2 [甲方系统B]
1.2.1 [具体需求项描述]

二、[用户端名称 / 小程序端]

2.1 [功能模块A]
2.1.1 用户可见的功能描述
2.1.2 交互说明
2.2 [功能模块B]

三、后台管理（如有）

3.1 [管理功能A]
3.1.1 管理员可操作的内容

四、待确认事项

序号	事项	甲方回复	备注
1	权益来源是自有系统还是外部系统？	—	影响系统对接工作量
2	资源状态是否同步到用户端展示？	—	影响开发范围

报价把范围翻译成商务语言

做什么：

• ●基于已确认的需求清单估算工期和价格

• ●原模块价格不动，新增需求单独成行
  涉及的 Skill：

• ●client-delivery — 报价纪律模块

• ●xlsx-manipulation — Excel 生成
  报价纪律：

• ●原有模块价格不动（改价显得不专业）

• ●联调测试不拆成独立收费行（写进模块描述里，如"含全流程联调测试"）
• ●只给总工期范围，不给模块工期分解
• ●不含项只写甲方提过但本期不做的内容——不凭空添加双方从未讨论的排除项

产出物模板——报价单：

# [项目名称] 项目报价单

一、项目概述

一句话说明项目背景和性质。

二、报价明细

功能模块	主要内容	报价（元）
模块A	含全流程联调测试	¥X,XXX
模块B	含全流程联调测试	¥X,XXX
合计	总工期：X-X 个

...(内容截断，完整内容请查看原文)

---

本页由自动化脚本生成，待人工审核补充