我用 Hermes 成交了第一个 OPC 项目

五一期间，我接到了自己的第一个独立开发项目。对想做OPC（一人公司）的人来说，这件事至少说明：一个人加一套Agent生产系统，确实可以开始做真实生意。

但这篇文章的重点不是讲我怎么接到第一单。真正值得拆的是后半段：我怎么在项目推进到有点失控时，临时搭了一个 Hermes PM Agent，集成了47个skills，让它参与需求挖掘、真实场景还原、报价、合同边界和交付审核。

最大的问题：把链路听成了功能点

我一开始的思路很开发者。客户说要某个功能，我就自然开始拆接口、数据、页面、排期。这个过程并没有错，但它容易漏掉一个更前置的问题：这个功能到底属于哪条真实业务链路？

客户自己也未必能一开始就把真实需求讲清楚。很多时候，客户会先说一个他以为自己需要的功能点，但这个功能点背后可能还有触发条件、使用角色、数据流转、结果确认、异常处理、后续记录等一连串动作。

如果只按功能点报价，很容易低估项目。因为你以为自己接的是一个小模块，实际交付时才发现客户要的是完整闭环。真正的工作量不在“这个功能能不能做”，而在它要接入什么流程、影响哪些系统、最后怎么验收。

合同还没签，所以还有机会调整。如果报价已经锁死，后面发现真实场景比功能点复杂得多，成本就会落到自己身上。

Hermes PM 救的是成交前的判断

Hermes PM 加入后，最大的变化是它不急着生成方案，而是先追问：

• 这个需求从哪个业务动作开始？

• 谁会使用它？使用前后分别发生什么？

• 数据从哪里来，又流向哪里？

• 结果由谁确认？失败或异常时怎么处理？

• 哪些环节依赖客户或第三方提供条件？

• 最终验收看什么？

这些问题把项目从“功能描述”拉回“业务现场”。

开发者很容易关心能不能实现。PM Agent 更关心的是：这个需求是不是已经被定义清楚，边界是不是能写进报价，风险是不是能提前暴露。

第一次接真实项目，最危险的不是不会开发，而是成交前判断不稳。 你以为需求已经清楚，其实只是客户讲了一个入口；你以为工期可以估，其实上下游链路还没展开；你以为报价能发，其实前置条件还没确认。

Hermes PM 的救急价值，就是把这些模糊地带拦在签约前。

SOUL.md：岗位说明书

我不会只写一句“你是资深产品经理”。SOUL.md 更像岗位说明书，写清楚它是谁、负责什么、不负责什么、按什么标准交付。

身份： 我是你的 Hermes 产品经理，负责把客户的模糊需求转成可报价、可签约、可交付的项目方案。

工作原则：

• 先理解，再定义；先还原真实场景，再写方案

• 先追问业务链路，再拆功能模块

• 客户说的话不是最终需求，必须继续追问真实业务背景

职责范围： 需求挖掘、客户沟通问题设计、业务场景澄清、链路闭环检查、PRD和功能需求清单、模块拆解和排期建议、报价单结构和条款说明、合同边界提醒、交付前文档审核。

输出标准：

• 甲方业务方能读懂

• 不暴露内部执行细节（不出现日薪、人天单价等内部定价逻辑）

• 每个模块都有明确范围、交付物和验收口径

• 所有外部依赖都要写成前置条件或开放问题

47个PM skill：让Agent有方法论

SOUL.md 解决“它是谁”，skill 解决“它怎么想”。

我给这个PM Agent配了47个产品经理skill，让它在不同阶段有可调用的方法论：

问题定义类（problem-statement、jobs-to-be-done等）：避免过早接受客户表述，追问“谁在什么场景下用？不做会产生什么损失？”

需求拆解类（user-story、prd-development等）：把模糊需求拆成可验收模块，关键不是写“我要开发什么”，而是写“甲方能得到什么结果”。

优先级和范围类（prioritization-advisor等）：处理范围膨胀，客户沟通里经常出现“顺便”“以后可能”“最好支持”，如果不归类，最后都会变成默认工作量。

商业和报价类（finance-based-pricing-advisor等）：提醒报价应围绕模块、周期、边界和交付价值组织，而不是暴露内部成本结构。

验证和风险类（pol-probe等）：检查外部依赖、开放问题和前置条件。很多风险不是开发阶段才出现，而是需求阶段没有问清楚。

工具链：不只是会聊天

只有SOUL.md和skill还不够。Agent要真正参与生产，必须能处理真实输入、生成真实交付物、并归档到真实工作空间。

我给它接了几类能力：

• 文档读取和生成：python-docx、openpyxl、python-pptx

• 项目和外部信息读取：codebase-inspection、web_extract

• 飞书归档和协作：lark-doc、lark-drive、lark-sheets

交付物分层管理：

固定SOP：从输入到交付

我把流程固定成SOP，覆盖五个阶段：

输入阶段： 客户原始需求文档、我自己的初版理解、现有项目代码库、外部系统API文档、客户补充说明。

分析阶段： 还原真实业务流程→识别功能背后的完整链路→对比客户表述与外部系统能力→标注已有系统中需要改造的部分→拆出可独立验收的模块→列出开放问题和外部依赖。

报价阶段： 每个模块估算工期区间→把外部依赖写成前置条件→把范围外事项写成边界→报价单只呈现模块、内容、周期、价格→内部成本、日薪、buffer不写给甲方。

交付阶段： 生成PRD→生成甲方可读的功能需求清单→生成在线版报价单→生成Excel版报价单→输出条款说明→同步飞书项目文件夹。

审核阶段（document-audit）： 扫描内部执行细节、定价逻辑暴露、未脱敏业务信息、敏感平台关键词、过度技术化表达、过度承诺。

这一层审核，能把Agent产出的内容重新拉回专业交付标准。

写在最后

这次真正的收获，不是“AI帮我写了PRD”，而是我第一次更具体地感受到：OPC不是一个人扮演所有角色，而是一个人把关键岗位搭出来。

开发岗位，我自己能做。但客户对接、需求洞察、报价组织、交付审核、文档归档，如果全靠脑子临时扛，很容易漏。

Hermes 的价值不是替我做老板，也不是替我承担最终决策。它的价值是把一个岗位变成可调用的生产流程。

一个可用的PM Agent，至少要有这几层：

1. profile：固定岗位身份

2. SOUL.md：固定工作原则和边界

3. PM skills：固定思考方法

4. Office/Web/Codebase工具：接入真实材料

5. 飞书工具：归档真实交付物

6. SOP：固定工作流

7. 审核规则：交付前兜底

做到这一步，Agent才不只是陪聊工具，它开始进入生产。

如果你也想做独立开发或OPC，建议先从一个关键岗位开始补——比如PM。把岗位定义清楚，把skill配好，把输入输出接进真实工作流，再让它在每次客户沟通和交付前帮你过一遍。

一个人当然可以开张。但一个人不该什么都靠自己硬扛。