我用 Hermes 成交了第一个 OPC 项目
我用 Hermes 成交了第一个 OPC 项目
来源类型： 微信公众号文章
日期： 2026-06-02
标签： AI, OpenClaw, 编程
原文链接： https://mp.weixin.qq.com/s/CxAYGJbYpeC0QbSQtNmd8Q
摘要
我真的开张了。 五一期间，我接到了自己的第一个独立开发项目。对想做 OPC（一人创业公司）的人来说，这件事至少说明：一个人加一套 Agent 生产系统，确实可以开始做真实生意。 但这篇文章的重点，不是讲我怎么接到第一单。 真正值得拆的是后半段：我怎么在项目推进到有点失控时，临时搭了一个 Hermes PM Agent，集成了47个skills，让它参与需求挖掘、真实场景还原、报价、合同边界和交付审核。 这次经历不可谓不坎坷。 Hermes 是和客户对接到后期才加入的。前面需求改了好几版，PRD 和报价也反复调整。越往后聊，我越发现自己前期理解得太“功能化”了：客户说的是一个功能点，但...
核心内容
我真的开张了。
五一期间，我接到了自己的第一个独立开发项目。对想做 OPC（一人创业公司）的人来说，这件事至少说明：一个人加一套 Agent 生产系统，确实可以开始做真实生意。
但这篇文章的重点，不是讲我怎么接到第一单。
真正值得拆的是后半段：我怎么在项目推进到有点失控时，临时搭了一个 Hermes PM Agent，集成了47个skills，让它参与需求挖掘、真实场景还原、报价、合同边界和交付审核。
这次经历不可谓不坎坷。
Hermes 是和客户对接到后期才加入的。前面需求改了好几版，PRD 和报价也反复调整。越往后聊，我越发现自己前期理解得太“功能化”了：客户说的是一个功能点，但真正要解决的，可能是一整条业务链路。
这时我才赶忙“雇佣”了这位产品经理来救急。
我会分享这套 PM Agent 是怎么搭的、怎么工作，以及它为什么能在真实项目里帮我把风险拦下来。故事是这样的：
最大的问题是把链路听成了功能点
我一开始的思路很开发者。
客户说要某个功能，我就自然开始拆接口、数据、页面、排期。这个过程并没有错，但它容易漏掉一个更前置的问题：这个功能到底属于哪条真实业务链路？
客户自己也未必能一开始就把真实需求讲清楚。
很多时候，客户会先说一个他以为自己需要的功能点。但这个功能点背后，可能还有触发条件、使用角色、数据流转、结果确认、异常处理、后续记录等一连串动作。
如果只按功能点报价，很容易低估项目。
因为你以为自己接的是一个小模块，实际交付时才发现客户要的是完整闭环。真正的工作量，不在“这个功能能不能做”，而在它要接入什么流程、影响哪些系统、最后怎么验收。
我这次后怕的点就在这里。
合同还没签，所以还有机会调整。如果报价已经锁死，后面发现真实场景比功能点复杂得多，成本就会落到自己身上。
所以后面搭 Hermes PM，不是为了让它帮我写一版更漂亮的 PRD。
我要它帮我做的是：从客户说出的功能点，追到真实场景；从真实场景，追到完整链路；再把链路拆成能报价、能签约、能验收的项目范围。
Hermes PM 救的是成交前的判断
Hermes PM 加入后，最大的变化是它不急着生成方案。
它会先追问：
这个需求从哪个业务动作开始？
谁会使用它？
使用前后分别发生什么？
数据从哪里来，又流向哪里？
结果由谁确认？
失败或异常时怎么处理？
哪些环节依赖客户或第三方提供条件？
最终验收看什么？
这些问题把项目从“功能描述”拉回“业务现场”。
开发者很容易关心能不能实现。PM Agent 更关心的是：这个需求是不是已经被定义清楚，边界是不是能写进报价，风险是不是能提前暴露。
这正是我当时需要的。
第一次接真实项目，最危险的不是不会开发，而是成交前判断不稳。你以为需求已经清楚，其实只是客户讲了一个入口；你以为工期可以估，其实上下游链路还没展开；你以为报价能发，其实前置条件还没确认。
Hermes PM 的救急价值，就是把这些模糊地带拦在签约前。
我搭建的是一个独立职责的 PM Agent
这次不是写一个 prompt，让 Hermes 临时扮演产品经理。
我搭建的是一个独立职责的 PM Agent。
它的职责链是：
客户需求输入
↓
需求挖掘
↓
真实业务场景还原
↓
链路闭环检查
↓
PRD / 功能需求清单
↓
排期与报价
↓
合同边界提醒
↓
交付前审核
它不写代码，也不替我做最终商业决策。
它负责在我做决定前，把没想清楚的地方圈出来：哪些需求还只是功能点，哪些链路没有闭环，哪些外部依赖需要客户确认，哪些范围必须写进报价和合同。
我希望它稳定完成几件事：
把客户口头功能点拆成真实业务场景
把单点功能追问成完整链路
把模糊需求拆成可验收模块
把外部依赖写成前置条件
把范围边界写进报价和合同
把 AI 生成内容里的不当措辞拦下来
这就是它参与生产的方式。
SOUL.md 要写成岗位说明书
PM Agent 的第一层，是 SOUL.md。
我不会只写一句“你是资深产品经理”。SOUL.md 更像岗位说明书，要写清楚它是谁、负责什么、不负责什么、按什么标准交付。
身份可以这样写：
你是我的 Hermes 产品经理，负责把客户的模糊需求转成可报价、可签约、可交付的项目方案。
你不是程序员，不负责写代码。
你的重点是客户沟通、需求洞察、真实场景追问、链路闭环、范围边界、报价结构和交付审核。
工作原则：
先理解，再定义。
先还原真实场景，再写方案。
先追问业务链路，再拆功能模块。
结构先于细节。
优先级决策大于功能堆砌。
报价是对齐项目范围，不是解释内部成本。
客户说的话不是最终需求，必须继续追问真实业务背景。
职责范围：
你负责：
- 需求挖掘
- 客户沟通问题设计
- 业务场景澄清
- 链路闭环检查
- PRD 和功能需求清单
- 模块拆解和排期建议
- 报价单结构和条款说明
- 合同边界提醒
- 交付前文档审核
你不负责：
- 写业务代码
- 替我承诺最终报价
- 替我判断客户预算上限
- 替我催客户确认
- 在甲方文档里暴露内部定价逻辑
输出标准：
所有给甲方看的内容必须：
- 甲方业务方能读懂
- 不暴露内部执行细节
- 不出现日薪、人天单价、buffer 等内部定价逻辑
- 每个模块都有明确范围、交付物和验收口径
- 所有外部依赖都要写成前置条件或开放问题
- 涉及真实业务、平台、客户信息时必须脱敏
SOUL.md 的作用，是让 Agent 稳定站在岗位上工作，而不是每次靠临场提示发挥。
47 个 PM skill 让它有方法论
SOUL.md 解决“它是谁”。
skill 解决“它怎么想”。
我给这个 PM Agent 配了 47 个产品经理 skill，让它在不同阶段有可调用的方法论。
问题定义类：
problem-statement
problem-framing-canvas
jobs-to-be-done
context-engineering-advisor
这类 skill 用来避免过早接受客户表述。客户说“做一个功能”，它会继续追问：谁在什么场景下用？现在流程怎么跑？不做会产生什么损失？客户说的是问题，还是他自己想出来的方案？
需求拆解类：
user-story
user-story-mapping
epic-breakdown-advisor
user-story-splitting
prd-development
这类 skill 用来把模糊需求拆成可验收模块。关键不是写“我要开发什么”，而是写“甲方能得到什么结果”。
优先级和范围类：
prioritization-advisor
opportunity-solution-tree
feature-investment-advisor
roadmap-planning
这类 skill 用来处理范围膨胀。客户沟通里经常出现“顺便”“以后可能”“最好支持”。这些话如果不归类，最后都会变成默认工作量。
商业和报价类：
finance-based-pricing-adviso
...(内容截断，完整内容请查看原文)
本页由自动化脚本生成，待人工审核补充