五一期间，我接到了自己的第一个独立开发项目。对想做 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。
它的职责链是：
它不写代码，也不替我做最终商业决策。
它负责在我做决定前，把没想清楚的地方圈出来：哪些需求还只是功能点，哪些链路没有闭环，哪些外部依赖需要客户确认，哪些范围必须写进报价和合同。
我希望它稳定完成几件事：
这就是它参与生产的方式。
SOUL.md 要写成岗位说明书
PM Agent 的第一层，是 SOUL.md。
我不会只写一句“你是资深产品经理”。SOUL.md 更像岗位说明书，要写清楚它是谁、负责什么、不负责什么、按什么标准交付。
身份可以这样写：
工作原则：
职责范围：
输出标准：
SOUL.md 的作用，是让 Agent 稳定站在岗位上工作，而不是每次靠临场提示发挥。
47 个 PM skill 让它有方法论
SOUL.md 解决“它是谁”。
skill 解决“它怎么想”。
我给这个 PM Agent 配了 47 个产品经理 skill，让它在不同阶段有可调用的方法论。
问题定义类：
这类 skill 用来避免过早接受客户表述。客户说“做一个功能”，它会继续追问：谁在什么场景下用？现在流程怎么跑？不做会产生什么损失？客户说的是问题，还是他自己想出来的方案？
需求拆解类：
这类 skill 用来把模糊需求拆成可验收模块。关键不是写“我要开发什么”，而是写“甲方能得到什么结果”。
优先级和范围类：
这类 skill 用来处理范围膨胀。客户沟通里经常出现“顺便”“以后可能”“最好支持”。这些话如果不归类，最后都会变成默认工作量。
商业和报价类：
这类 skill 不直接替我定价，但会提醒我：报价应该围绕模块、周期、边界和交付价值组织，而不是暴露内部成本结构。
验证和风险类：
这类 skill 用来检查外部依赖、开放问题和前置条件。很多风险不是开发阶段才出现，而是需求阶段没有问清楚。
这套 skill 的价值，是让 Agent 按产品经理的方法反过来审我的判断。
它还需要真实工具，不然只是会聊天
只有 SOUL.md 和 skill，还不够。
Agent 要真正参与生产，必须能处理真实输入，生成真实交付物，并归档到真实工作空间。
我给它接了几类能力。
文档读取和生成：
项目和外部信息读取：
飞书归档和协作：
这一步决定了 Agent 是不是生产工具。
我需要的不是聊天记录里一堆建议，而是一个项目文件夹：PRD、功能需求清单、报价单、条款说明、审核记录，各自放在该放的位置。
交付结构可以是这样：
重点不是“用了飞书”，而是交付物分层。
甲方看的文档，要业务化、边界清楚、少技术细节。内部看的文档，可以保留实现信息、风险判断和决策依据。
我的固定工作流
后面我把流程固定成 SOP。
输入阶段：
分析阶段：
报价阶段：
交付阶段：
审核阶段：
这套流程的价值，是把“凭感觉接项目”改成“按岗位流程推进项目”。
document-audit 主要审 AI 生成内容
document-audit 这一步，我更看重的是审 AI 生成内容。
AI 生成内容容易出现几个问题：写得太满、解释太多、把内部判断写进外部文档，或者为了“说清楚”而带出不该出现的业务细节。
所以交付前必须扫一遍。
我会重点检查这些内容：
它不是帮我检查“我有没有犯低级错误”。
更准确地说，它是在帮我控制 AI 生成内容的外溢风险。
AI 很擅长补全，但商业交付里有些东西不能补全。真实业务、客户信息、平台名称、内部估价逻辑，宁可少写，也不要在对外文档里写错。
这一层审核，能把 Agent 产出的内容重新拉回专业交付标准。
最后补上的不是写作能力
这套 PM Agent 最后补上的，是四种生产能力。
客户对接能力。
它会帮我把客户口头描述拆回真实业务场景，而不是直接接受一句“做一个功能”。
需求洞察能力。
它会沿着角色、流程、系统、依赖、验收标准继续追问，直到需求能被报价和签约。
链路闭环能力。
它会判断客户要的到底是一个孤立功能，还是一整条从触发、执行、确认到后续处理的业务链路。
交付审核能力。
它会在文档发出前拦住不专业、未脱敏、过度承诺或容易引发误解的内容。
这些能力比“多写几行代码”更关键。
代码写慢一点，还可以补。合同签错、范围报错、边界没写清楚，后面补起来就很贵。
一个人开张，不等于一个人硬扛
这次真正的收获，不是“AI 帮我写了 PRD”。
而是我第一次更具体地感受到：OPC 不是一个人扮演所有角色，而是一个人把关键岗位搭出来。
开发岗位，我自己能做。
但客户对接、需求洞察、报价组织、交付审核、文档归档，如果全靠脑子临时扛，很容易漏。
Hermes 的价值，不是替我做老板，也不是替我承担最终决策。
它的价值是把一个岗位变成可调用的生产流程。
一个可用的 PM Agent，至少要有这几层：
做到这一步，Agent 才不只是陪聊工具。
它开始进入生产。
如果你也想做独立开发或 OPC，我建议先从一个关键岗位开始补，比如 PM。
把岗位定义清楚，把 skill 配好，把输入输出接进真实工作流，再让它在每次客户沟通和交付前帮你过一遍。
一个人当然可以开张。
但一个人不该什么都靠自己硬扛。