使用Agent Harness构建PRD生产流水线产品文档的Rules‑Skills‑Agents很多读者会产生疑问Agent Harness是不是只能用来写代码答案是否定的。Agent Harness本质是一套把团队的成熟标准、工序流程、岗位分工沉淀为可版本管理文件的工程范式编码只是它的其中一个落地场景。从本篇开始我们跳出IDE与代码生成把这套范式迁移到研发团队日常高频的文档产出。第一个场景选择PRD产品需求文档产品、研发同学日常都要写、评审PRD和原有读者群体高度契合。一、AI辅助写PRD的普遍痛点现在大家已经习惯用大模型辅助产出PRD初稿但绝大多数使用方式还是会话内粘贴一大段提示词每次新会话全部要重新复述一遍团队文档规范会遇到这些典型问题每次对话重复交代PRD章节结构、术语、书写约束换会话规范全部丢失。AI经常自作主张膨胀需求范围主动增加本期不在范围内的功能点。产出文档看起来章节齐全但大量描述模糊缺少非功能需求、边界条件、风险评估开发拿到无法直接开工。用户故事格式不统一验收条件缺失前后文档术语打架。写完没有内置自检环节只能完全依赖人工逐字通读排查漏洞。范围、目标和术语还没确认文件已经落盘猜出来的内容变成了正式文档。某一章本期没有内容就被整章删掉评审分不清是「确认没有」还是「写漏了」。产品 PRD 和需求设计文档被写成同一份用户故事里出现表名和接口路径需求设计文档里又没有可验证的验收条件。评审时分不清该由产品确认业务还是由研发确认落地方案。很多人的解法是不断加长提示词但提示词依附单次会话不能纳入Git版本管理团队成员之间无法共享同一套约束。而Harness的思路是把PRD相关的文档契约、原子工序、岗位角色全部沉淀成独立文件不绑定单次聊天窗口。和代码场景做一次类比对照帮助理解概念迁移代码场景 Rules编码规范、接口契约规定代码长什么样。PRD场景 RulesPRD文档规范、术语字典、书写红线规定一份合格PRD必须长什么样。代码场景 Skills生成DO、生成Controller的原子工序。PRD场景 Skills拆解用户故事、检查需求歧义、提取测试要点的原子工序。代码场景 Agents开发Agent、评审Agent岗位角色调度Skills遵守Rules。PRD场景 Agents需求整理Agent、PRD撰稿Agent、PRD评审Agent岗位角色调度文档工序输出并校验PRD初稿。二、非代码场景Harness目录结构参考我们参考Cursor.cursor的设计思想针对文档场景定义一套项目级Harness目录可以提交Git仓库团队共享。目录命名可以为.harness‑prd存放于知识库/产品仓库根目录。.harness‑prd/ ├── PRD_SPEC.md # 【总图】PRD总蓝图文档元信息、全局术语字典、整体章节模板类比代码场景AGENT.mdc ├── rules/ # PRD相关规则契约 │ ├── prd‑structure.md # PRD强制章节、输出格式 │ ├── user‑story.md # 用户故事、验收条件书写规范 │ ├── prd‑redline.md # 写作红线、禁止行为 │ └── prd‑meta.md # 文档版本、编号、作者元数据规范 ├── skills/ # PRD相关原子工序一个Skill一个文件夹 │ ├── sort‑raw‑demand/ │ ├── parse‑user‑story/ │ ├── check‑demand‑ambiguity/ │ ├── gen‑prd‑draft/ │ ├── extract‑checkpoint/ │ └── prd‑self‑review/ └── agents/ # PRD岗位Agent定义 ├── demand‑collate‑agent/ ├── prd‑write‑agent/ └── prd‑review‑agent/区分用户级 / 项目级项目级.harness‑prd整个目录提交Git。存放团队统一PRD模板、规则、工序、角色全团队共用。用户级放在本机个人目录存放个人写作偏好禁止提交Git例如个人习惯的简版PRD模板。三、RulesPRD静态契约规范Rules只定义产出物的标准、禁止项不描述怎么做文档的步骤执行步骤交给Skills。总图PRD_SPEC.md是整套PRD Harness唯一信息源头包含文档编号规则、全局业务术语字典、PRD完整章节大纲所有rules、skills、agents都引用这份总图不要到处硬复制模板。rules/prd‑structure.md 示例片段--- description: PRD文档强制章节结构所有产出PRD必须遵守 alwaysApply: true --- # PRD结构规范 一份完整Feature PRD必须包含如下章节顺序不可随意调整 1. 文档元信息文档编号、版本、状态、作者、干系人、更新日期 2. 需求背景与要解决的问题 3. 目标与成功衡量指标 4. 本期范围内 / 本期不做Out‑of‑Scope 5. 用户角色与用户故事附带可验证验收条件 6. 功能详细说明、交互逻辑 7. 非功能需求性能、权限、埋点、兼容性 8. 依赖、前置条件 9. 风险点与应对方案 10. 附录原型链接、参考资料 禁止随意删减上面任意章节精简版MVP单页PRD可以使用专门的轻量模板。rules/user‑story.md 示例片段--- description: 用户故事与验收条件书写约束 alwaysApply: true --- # 用户故事书写规范 1. 用户故事格式作为【用户角色】我希望【操作】以便【业务价值】。 2. 每一条用户故事必须配套多条**可验证的验收条件**不能模糊描述。 3. 验收条件必须是可以被测试人员验证通过/不通过的语句。 ❌反面示例系统做好权限控制。 ✅正面示例管理员角色可以查看全部数据普通角色仅可见自己创建的数据。 4. 禁止在用户故事里面直接写技术实现方案只描述业务行为。rules/prd‑redline.md 示例片段红线约束--- description: PRD写作红线强制禁止行为 alwaysApply: true --- # PRD写作禁止项 1. 禁止未经确认私自扩大需求范围自动增加“顺便实现”的功能。 2. 禁止使用“相关处理”“合理处理”这类无法验证的模糊描述。 3. 不允许省略【本期不做】章节必须明确划定边界。 4. 不允许把技术实现细节写进业务需求描述。 5. 所有引用外部资源原型、工单、调研必须带上链接不能只口头提及。关键原则Rules只管“一份合格PRD长什么样”不要写“第一步整理需求第二步写用户故事”执行流程属于Skills职责。四、SkillsPRD原子化工序工具箱遵循Harness一贯原则一个Skill只负责一件原子任务不做跨多环节编排编排交给上层Agent。下面选取两个核心Skill给出模板示例。Skill示例一sort‑raw‑demand原始需求整理文件路径.harness‑prd/skills/sort‑raw‑demand/SKILL.md--- name: sort‑raw‑demand description: 将口语化、零散原始输入聊天、会议纪要、零散笔记整理为结构化需求素材池不输出正式PRD。 Use when: 输入是大段非结构化业务描述需要提取出业务目标、用户、痛点不要用来直接生成PRD正文。 --- # sort‑raw‑demand 原始需求整理Skill ## 使用时机 接收来自会议纪要、聊天记录、口述业务描述把零散信息做结构化提取。 ### 禁止场景 不要直接输出完整PRD文档输出仅作为素材不对外评审。 ## 执行步骤 1. 读取总图PRD_SPEC.md读取业务术语字典。 2. 从原始输入提取业务背景、要解决的问题、涉及用户角色、已明确功能点、尚不明确的疑问点。 3. 区分已经明确的信息 / 待确认信息。待确认条目必须明确列出来不自行脑补。 4. 输出结构化素材池文档。 ## 自检清单必须全部检查 1. 没有脑补原始输入不存在的业务需求。 2. 所有不确定点统一放入待确认清单不自行填充答案。 3. 术语与PRD_SPEC.md术语字典保持一致。 ## 退出条件 如果完全没有有效业务输入立刻停止提示用户补充业务描述。Skill示例二prd‑self‑reviewPRD自检审查文件路径.harness‑prd/skills/prd‑self‑review/SKILL.md--- name: prd‑self‑review description: 对已生成PRD初稿做完整性自检输出问题检查清单**不修改PRD原文**。 Use when: PRD初稿完成之后做规范校验。 --- # prd‑self‑review PRD自检审查Skill ## 使用时机 PRD初稿完成执行完整性、规范性检查。 ### 禁止场景 禁止直接改写PRD文档内容仅输出问题清单。 ## 执行步骤 1. 读取PRD全套rules以及PRD_SPEC.md总图。 2. 检查章节完整性判断是否缺失强制章节。 3. 扫描用户故事检查验收条件是否可验证。 4. 扫描文档找出模糊描述语句标记位置。 5. 检查是否存在私自扩大需求范围的新增功能。 6. 检查是否缺少风险、非功能需求。 7. 输出标准化问题清单每条写明位置问题描述修改建议。 ## 自检清单 1. 不得直接修改PRD正文只输出检查报告。 2. 每条问题要定位到对应章节不能笼统评价。 ## 退出条件 输入PRD文档为空则终止执行。其余Skillparse‑user‑story用户故事拆解、check‑demand‑ambiguity需求歧义检查、gen‑prd‑draft生成PRD初稿、extract‑checkpoint从PRD提取测试要点均遵循相同结构元数据、使用时机、执行步骤、自检清单、退出条件。重要Skill内部不做流程串联例如不要在sort‑raw‑demand里面写“整理完素材之后调用生成PRD”串联调度交给Agent。五、AgentsPRD岗位角色编排Agent代表岗位角色负责任务接收、按顺序调度各个Skill设置人工卡点通过allowed_skills白名单控制可以调用哪些Skill实现权限隔离。三个核心Agentdemand‑collate‑agent需求整理Agent。接收原始业务输入输出结构化素材池不产出正式PRD。prd‑write‑agentPRD撰稿Agent。基于已经确认的素材池调用生成初稿相关Skill产出PRD初稿。prd‑review‑agentPRD评审Agent。只做审查输出检查清单禁止调用生成PRD的Skill不能改写文档。Agent模板示例 prd‑write‑agent路径.harness‑prd/agents/prd‑write‑agent/AGENT.md--- name: prd‑write‑agent description: 在已经确认结构化需求素材池的基础上生成PRD初稿没有确认素材不允许生成正式PRD。 allowed_skills: - parse‑user‑story - gen‑prd‑draft disallow_skills: - sort‑raw‑demand - prd‑self‑review apply_rules: 读取项目PRD_SPEC.md总图加载全部prd rules --- # prd‑write‑agent PRD撰稿Agent ## 岗位职责 基于人工确认完毕的需求素材池生成符合团队规范的PRD初稿。 重要前置约束没有经过人工确认的原始口述材料不能直接用来生成正式PRD。 ## 禁止行为 1. 不接收未经整理的零散聊天记录直接生成PRD正式文档必须先经过demand‑collate‑agent输出素材并人工确认。 2. 禁止自行脑补业务补充素材池中不存在的功能点。 3. 不执行PRD评审工作评审交由prd‑review‑agent。 ## 工作流转逻辑 1. 校验输入确认已经存在人工确认完成的结构化需求素材池不存在则终止流程提示先整理并确认需求素材。 2. 调用 parse‑user‑story完成用户故事与验收条件拆解。 3. 调用 gen‑prd‑draft生成完整PRD初稿。 4. 输出PRD初稿完整文档告知用户流转给prd‑review‑agent做审查。 ## 退出条件 1. 缺少人工确认的需求素材池直接停止执行。 2. 关键业务信息缺失停止执行交还用户补充信息。六、完整端到端工作流带人工卡点重点Harness文档流水线不是全自动无人化关键节点保留人的决策人始终掌握业务决策权。产品 PRD 与需求设计文档各走各的技能差别见「写在前面」。下面是两段工序接在一起之后的顺序。输入原始业务信息会议纪要、口述需求、零散笔记唤起demand‑collate‑agent调用sort‑raw‑demand输出结构化需求素材池。人工卡点1人审阅素材池补全缺失信息确认素材这一步AI不能替代业务判断。素材未确认后续流程禁止执行。素材确认完成唤起prd‑write‑agent调度Skill生成PRD初稿。唤起prd‑review‑agent执行自检Skill输出PRD问题检查清单。人工卡点2人根据检查清单修改PRD完成内部评审。输出评审通过、可交付研发的正式PRD文档。研发接手已确认的 PRD使用create-proposal生成需求设计文档。这一步仍然只写 Markdown。人工卡点3人评审需求设计文档。未通过不进入编码技能。用户明确要求实施之后再按文档中的顺序调用建表、模型、服务、接口技能。流转关键约束prd‑review‑agent的skill白名单里面不允许调用生成PRD的Skill只能做审查输出报告保证评审角色不能直接改写文档角色权责隔离。任何Agent都禁止在业务信息缺失时自行脑补业务。create-proposal的允许范围只有需求设计文档。它不调用改源码、执行 DDL 的技能那些技能要等需求设计文档评审通过并且用户明确要求实施。七、落地踩坑清单非代码Harness特有坑坑1把业务决策写进Rules/Skills现象在规则、Skill里面写死业务功能。解决Rules只写文档格式、写作红线业务内容由人输入Harness只管产出物的质量约束不管业务本身做什么。坑2去掉人工卡点追求一键全自动产出PRD现象原始聊天记录直接丢进去一键输出可交付PRD。解决业务判断只能由人完成Harness解决文档规范性不能替代产品做业务取舍。素材确认、PRD评审必须保留人工节点。坑3Skill粒度过大一个Skill包揽从原始聊天到完整PRD全部工作现象单个Skill接收聊天直接输出完整PRD。解决坚持原子化原始素材整理、生成初稿、评审审查拆成独立Skill由Agent串联。坑4总图PRD_SPEC.md不做单一源头模板到处复制现象PRD章节模板同时散落在rules、skill模板、agent描述多处。修改一处其他地方不会同步。解决全部以PRD_SPEC.md总图为唯一源头其他文件引用总图不要复制大段模板副本。坑5评审Agent同时拥有生成文档的能力现象prd‑review‑agent既可以检查问题又可以直接修改PRD。评审与修改角色混淆问题闭环无法被人感知。解决通过allowed_skills白名单严格隔离角色能力评审只输出问题清单修改由人工或者撰稿Agent完成。坑6把整套.harness‑prd个人配置提交到公共仓库现象把个人简版模板、个人偏好的Agent提交项目仓库。解决项目团队共用部分提交Git个人习惯的用户级Harness放在本机用户目录加入gitignore。坑7技能正文另写一套和 Rules 冲突的契约现象方案示例里的成功码、字段名、URL 前缀和仓库接口 Rule 不一致评审和实现各用各的。解决前置规范表点名要读的 Rule。示例只允许出现 Rule 里已经规定的形态。技能不定义第二套契约。坑8范围还没确认就把文件写进仓库现象一句话需求刚进会话技能直接落盘术语和边界都是模型补的。解决工作流第一步写明「确认前不落盘」。背景、边界、术语未确认停止写文件把问题交还用户。坑9没有内容就删掉强制章节现象本期不改库表于是整节数据库变更被删掉。解决强制章节保留。无变更写「无」。缺章视为未完成。坑10样本技能原样复制到另一个仓库现象样本里的输出目录、包名或分层、接口写法被贴进技术栈不同的目标仓库。解决迁移时单列差异表逐项改路径、分层、接口契约和版权约定。差异表没改完不启用这份技能。坑11写方案的技能顺手改了源码或执行了 DDL现象需求设计文档还在评审仓库里已经出现新表或新接口。解决在技能目的里写明只新增这一份 Markdown。落地实现点名下游技能并且必须等用户明确要求实施之后才调用。八、能力边界要客观认清这套PRD Harness体系擅长✅统一团队PRD输出格式、章节结构、用户故事书写规范。✅自动识别文档常见缺陷模糊描述、缺失章节、缺失验收条件。✅将重复的整理、拆解、自检工序沉淀为可复用资产不用每次写长篇提示词。✅团队成员之间共享同一套文档约束消除会话之间输出漂移。✅文档技能写明只产出文档不改源码、不执行 DDL下游工序点名其他技能。✅强制章节缺一不可没有内容时写「无」文件名和目录固定确认之前不落盘。这套体系不擅长也不打算做❌不能替代产品经理做业务判断、做需求取舍、定义业务目标。❌不能凭空从少量碎片化信息脑补完整业务逻辑。❌不能在技能示例里另造一套和 Rules 冲突的接口或库表契约。❌不能把另一个仓库的技能原样复制过来就启用也不能用方案里的代码片段代替已经实施的代码。本质非代码场景Harness也是把团队已经存在的文档标准数字化交付给AI而不是凭空创造产品判断力。九、总结本篇我们完成Agent Harness第一次跨领域迁移从代码开发迁移到PRD产品需求文档。Rules定义PRD文档长什么样强制章节、用户故事格式、写作红线只定标准不写执行步骤。Skills文档生产的原子工序原始需求整理、用户故事拆解、PRD自检审查一个Skill一件事不做大流程编排。Agents岗位角色需求整理Agent、撰稿Agent、评审Agent依靠Skill白名单实现角色权限隔离设置人工业务卡点。记住核心工作流原始素材 → 整理Agent → 人工确认素材 → 撰稿Agent产出初稿 → 评审Agent输出检查清单 → 人工评审修改。再次重申Harness通用思想不要依赖单次会话内的临时提示词把标准、工序、岗位角色沉淀为可Git版本管理的文件体系让AI辅助文档从一次性聊天输出走向标准化流水线。 
长河君 · 2026/10/14 7:31:55 · 阅读 1.2k 使用Agent Harness构建PRD生产流水线：产品文档的Rules‑Skills‑Agents
使用Agent Harness构建PRD生产流水线产品文档的Rules‑Skills‑Agents很多读者会产生疑问Agent Harness是不是只能用来写代码答案是否定的。Agent Harness本质是一套把团队的成熟标准、工序流程、岗位分工沉淀为可版本管理文件的工程范式编码只是它的其中一个落地场景。从本篇开始我们跳出IDE与代码生成把这套范式迁移到研发团队日常高频的文档产出。第一个场景选择PRD产品需求文档产品、研发同学日常都要写、评审PRD和原有读者群体高度契合。一、AI辅助写PRD的普遍痛点现在大家已经习惯用大模型辅助产出PRD初稿但绝大多数使用方式还是会话内粘贴一大段提示词每次新会话全部要重新复述一遍团队文档规范会遇到这些典型问题每次对话重复交代PRD章节结构、术语、书写约束换会话规范全部丢失。AI经常自作主张膨胀需求范围主动增加本期不在范围内的功能点。产出文档看起来章节齐全但大量描述模糊缺少非功能需求、边界条件、风险评估开发拿到无法直接开工。用户故事格式不统一验收条件缺失前后文档术语打架。写完没有内置自检环节只能完全依赖人工逐字通读排查漏洞。范围、目标和术语还没确认文件已经落盘猜出来的内容变成了正式文档。某一章本期没有内容就被整章删掉评审分不清是「确认没有」还是「写漏了」。产品 PRD 和需求设计文档被写成同一份用户故事里出现表名和接口路径需求设计文档里又没有可验证的验收条件。评审时分不清该由产品确认业务还是由研发确认落地方案。很多人的解法是不断加长提示词但提示词依附单次会话不能纳入Git版本管理团队成员之间无法共享同一套约束。而Harness的思路是把PRD相关的文档契约、原子工序、岗位角色全部沉淀成独立文件不绑定单次聊天窗口。和代码场景做一次类比对照帮助理解概念迁移代码场景 Rules编码规范、接口契约规定代码长什么样。PRD场景 RulesPRD文档规范、术语字典、书写红线规定一份合格PRD必须长什么样。代码场景 Skills生成DO、生成Controller的原子工序。PRD场景 Skills拆解用户故事、检查需求歧义、提取测试要点的原子工序。代码场景 Agents开发Agent、评审Agent岗位角色调度Skills遵守Rules。PRD场景 Agents需求整理Agent、PRD撰稿Agent、PRD评审Agent岗位角色调度文档工序输出并校验PRD初稿。二、非代码场景Harness目录结构参考我们参考Cursor.cursor的设计思想针对文档场景定义一套项目级Harness目录可以提交Git仓库团队共享。目录命名可以为.harness‑prd存放于知识库/产品仓库根目录。.harness‑prd/ ├── PRD_SPEC.md # 【总图】PRD总蓝图文档元信息、全局术语字典、整体章节模板类比代码场景AGENT.mdc ├── rules/ # PRD相关规则契约 │ ├── prd‑structure.md # PRD强制章节、输出格式 │ ├── user‑story.md # 用户故事、验收条件书写规范 │ ├── prd‑redline.md # 写作红线、禁止行为 │ └── prd‑meta.md # 文档版本、编号、作者元数据规范 ├── skills/ # PRD相关原子工序一个Skill一个文件夹 │ ├── sort‑raw‑demand/ │ ├── parse‑user‑story/ │ ├── check‑demand‑ambiguity/ │ ├── gen‑prd‑draft/ │ ├── extract‑checkpoint/ │ └── prd‑self‑review/ └── agents/ # PRD岗位Agent定义 ├── demand‑collate‑agent/ ├── prd‑write‑agent/ └── prd‑review‑agent/区分用户级 / 项目级项目级.harness‑prd整个目录提交Git。存放团队统一PRD模板、规则、工序、角色全团队共用。用户级放在本机个人目录存放个人写作偏好禁止提交Git例如个人习惯的简版PRD模板。三、RulesPRD静态契约规范Rules只定义产出物的标准、禁止项不描述怎么做文档的步骤执行步骤交给Skills。总图PRD_SPEC.md是整套PRD Harness唯一信息源头包含文档编号规则、全局业务术语字典、PRD完整章节大纲所有rules、skills、agents都引用这份总图不要到处硬复制模板。rules/prd‑structure.md 示例片段--- description: PRD文档强制章节结构所有产出PRD必须遵守 alwaysApply: true --- # PRD结构规范 一份完整Feature PRD必须包含如下章节顺序不可随意调整 1. 文档元信息文档编号、版本、状态、作者、干系人、更新日期 2. 需求背景与要解决的问题 3. 目标与成功衡量指标 4. 本期范围内 / 本期不做Out‑of‑Scope 5. 用户角色与用户故事附带可验证验收条件 6. 功能详细说明、交互逻辑 7. 非功能需求性能、权限、埋点、兼容性 8. 依赖、前置条件 9. 风险点与应对方案 10. 附录原型链接、参考资料 禁止随意删减上面任意章节精简版MVP单页PRD可以使用专门的轻量模板。rules/user‑story.md 示例片段--- description: 用户故事与验收条件书写约束 alwaysApply: true --- # 用户故事书写规范 1. 用户故事格式作为【用户角色】我希望【操作】以便【业务价值】。 2. 每一条用户故事必须配套多条**可验证的验收条件**不能模糊描述。 3. 验收条件必须是可以被测试人员验证通过/不通过的语句。 ❌反面示例系统做好权限控制。 ✅正面示例管理员角色可以查看全部数据普通角色仅可见自己创建的数据。 4. 禁止在用户故事里面直接写技术实现方案只描述业务行为。rules/prd‑redline.md 示例片段红线约束--- description: PRD写作红线强制禁止行为 alwaysApply: true --- # PRD写作禁止项 1. 禁止未经确认私自扩大需求范围自动增加“顺便实现”的功能。 2. 禁止使用“相关处理”“合理处理”这类无法验证的模糊描述。 3. 不允许省略【本期不做】章节必须明确划定边界。 4. 不允许把技术实现细节写进业务需求描述。 5. 所有引用外部资源原型、工单、调研必须带上链接不能只口头提及。关键原则Rules只管“一份合格PRD长什么样”不要写“第一步整理需求第二步写用户故事”执行流程属于Skills职责。四、SkillsPRD原子化工序工具箱遵循Harness一贯原则一个Skill只负责一件原子任务不做跨多环节编排编排交给上层Agent。下面选取两个核心Skill给出模板示例。Skill示例一sort‑raw‑demand原始需求整理文件路径.harness‑prd/skills/sort‑raw‑demand/SKILL.md--- name: sort‑raw‑demand description: 将口语化、零散原始输入聊天、会议纪要、零散笔记整理为结构化需求素材池不输出正式PRD。 Use when: 输入是大段非结构化业务描述需要提取出业务目标、用户、痛点不要用来直接生成PRD正文。 --- # sort‑raw‑demand 原始需求整理Skill ## 使用时机 接收来自会议纪要、聊天记录、口述业务描述把零散信息做结构化提取。 ### 禁止场景 不要直接输出完整PRD文档输出仅作为素材不对外评审。 ## 执行步骤 1. 读取总图PRD_SPEC.md读取业务术语字典。 2. 从原始输入提取业务背景、要解决的问题、涉及用户角色、已明确功能点、尚不明确的疑问点。 3. 区分已经明确的信息 / 待确认信息。待确认条目必须明确列出来不自行脑补。 4. 输出结构化素材池文档。 ## 自检清单必须全部检查 1. 没有脑补原始输入不存在的业务需求。 2. 所有不确定点统一放入待确认清单不自行填充答案。 3. 术语与PRD_SPEC.md术语字典保持一致。 ## 退出条件 如果完全没有有效业务输入立刻停止提示用户补充业务描述。Skill示例二prd‑self‑reviewPRD自检审查文件路径.harness‑prd/skills/prd‑self‑review/SKILL.md--- name: prd‑self‑review description: 对已生成PRD初稿做完整性自检输出问题检查清单**不修改PRD原文**。 Use when: PRD初稿完成之后做规范校验。 --- # prd‑self‑review PRD自检审查Skill ## 使用时机 PRD初稿完成执行完整性、规范性检查。 ### 禁止场景 禁止直接改写PRD文档内容仅输出问题清单。 ## 执行步骤 1. 读取PRD全套rules以及PRD_SPEC.md总图。 2. 检查章节完整性判断是否缺失强制章节。 3. 扫描用户故事检查验收条件是否可验证。 4. 扫描文档找出模糊描述语句标记位置。 5. 检查是否存在私自扩大需求范围的新增功能。 6. 检查是否缺少风险、非功能需求。 7. 输出标准化问题清单每条写明位置问题描述修改建议。 ## 自检清单 1. 不得直接修改PRD正文只输出检查报告。 2. 每条问题要定位到对应章节不能笼统评价。 ## 退出条件 输入PRD文档为空则终止执行。其余Skillparse‑user‑story用户故事拆解、check‑demand‑ambiguity需求歧义检查、gen‑prd‑draft生成PRD初稿、extract‑checkpoint从PRD提取测试要点均遵循相同结构元数据、使用时机、执行步骤、自检清单、退出条件。重要Skill内部不做流程串联例如不要在sort‑raw‑demand里面写“整理完素材之后调用生成PRD”串联调度交给Agent。五、AgentsPRD岗位角色编排Agent代表岗位角色负责任务接收、按顺序调度各个Skill设置人工卡点通过allowed_skills白名单控制可以调用哪些Skill实现权限隔离。三个核心Agentdemand‑collate‑agent需求整理Agent。接收原始业务输入输出结构化素材池不产出正式PRD。prd‑write‑agentPRD撰稿Agent。基于已经确认的素材池调用生成初稿相关Skill产出PRD初稿。prd‑review‑agentPRD评审Agent。只做审查输出检查清单禁止调用生成PRD的Skill不能改写文档。Agent模板示例 prd‑write‑agent路径.harness‑prd/agents/prd‑write‑agent/AGENT.md--- name: prd‑write‑agent description: 在已经确认结构化需求素材池的基础上生成PRD初稿没有确认素材不允许生成正式PRD。 allowed_skills: - parse‑user‑story - gen‑prd‑draft disallow_skills: - sort‑raw‑demand - prd‑self‑review apply_rules: 读取项目PRD_SPEC.md总图加载全部prd rules --- # prd‑write‑agent PRD撰稿Agent ## 岗位职责 基于人工确认完毕的需求素材池生成符合团队规范的PRD初稿。 重要前置约束没有经过人工确认的原始口述材料不能直接用来生成正式PRD。 ## 禁止行为 1. 不接收未经整理的零散聊天记录直接生成PRD正式文档必须先经过demand‑collate‑agent输出素材并人工确认。 2. 禁止自行脑补业务补充素材池中不存在的功能点。 3. 不执行PRD评审工作评审交由prd‑review‑agent。 ## 工作流转逻辑 1. 校验输入确认已经存在人工确认完成的结构化需求素材池不存在则终止流程提示先整理并确认需求素材。 2. 调用 parse‑user‑story完成用户故事与验收条件拆解。 3. 调用 gen‑prd‑draft生成完整PRD初稿。 4. 输出PRD初稿完整文档告知用户流转给prd‑review‑agent做审查。 ## 退出条件 1. 缺少人工确认的需求素材池直接停止执行。 2. 关键业务信息缺失停止执行交还用户补充信息。六、完整端到端工作流带人工卡点重点Harness文档流水线不是全自动无人化关键节点保留人的决策人始终掌握业务决策权。产品 PRD 与需求设计文档各走各的技能差别见「写在前面」。下面是两段工序接在一起之后的顺序。输入原始业务信息会议纪要、口述需求、零散笔记唤起demand‑collate‑agent调用sort‑raw‑demand输出结构化需求素材池。人工卡点1人审阅素材池补全缺失信息确认素材这一步AI不能替代业务判断。素材未确认后续流程禁止执行。素材确认完成唤起prd‑write‑agent调度Skill生成PRD初稿。唤起prd‑review‑agent执行自检Skill输出PRD问题检查清单。人工卡点2人根据检查清单修改PRD完成内部评审。输出评审通过、可交付研发的正式PRD文档。研发接手已确认的 PRD使用create-proposal生成需求设计文档。这一步仍然只写 Markdown。人工卡点3人评审需求设计文档。未通过不进入编码技能。用户明确要求实施之后再按文档中的顺序调用建表、模型、服务、接口技能。流转关键约束prd‑review‑agent的skill白名单里面不允许调用生成PRD的Skill只能做审查输出报告保证评审角色不能直接改写文档角色权责隔离。任何Agent都禁止在业务信息缺失时自行脑补业务。create-proposal的允许范围只有需求设计文档。它不调用改源码、执行 DDL 的技能那些技能要等需求设计文档评审通过并且用户明确要求实施。七、落地踩坑清单非代码Harness特有坑坑1把业务决策写进Rules/Skills现象在规则、Skill里面写死业务功能。解决Rules只写文档格式、写作红线业务内容由人输入Harness只管产出物的质量约束不管业务本身做什么。坑2去掉人工卡点追求一键全自动产出PRD现象原始聊天记录直接丢进去一键输出可交付PRD。解决业务判断只能由人完成Harness解决文档规范性不能替代产品做业务取舍。素材确认、PRD评审必须保留人工节点。坑3Skill粒度过大一个Skill包揽从原始聊天到完整PRD全部工作现象单个Skill接收聊天直接输出完整PRD。解决坚持原子化原始素材整理、生成初稿、评审审查拆成独立Skill由Agent串联。坑4总图PRD_SPEC.md不做单一源头模板到处复制现象PRD章节模板同时散落在rules、skill模板、agent描述多处。修改一处其他地方不会同步。解决全部以PRD_SPEC.md总图为唯一源头其他文件引用总图不要复制大段模板副本。坑5评审Agent同时拥有生成文档的能力现象prd‑review‑agent既可以检查问题又可以直接修改PRD。评审与修改角色混淆问题闭环无法被人感知。解决通过allowed_skills白名单严格隔离角色能力评审只输出问题清单修改由人工或者撰稿Agent完成。坑6把整套.harness‑prd个人配置提交到公共仓库现象把个人简版模板、个人偏好的Agent提交项目仓库。解决项目团队共用部分提交Git个人习惯的用户级Harness放在本机用户目录加入gitignore。坑7技能正文另写一套和 Rules 冲突的契约现象方案示例里的成功码、字段名、URL 前缀和仓库接口 Rule 不一致评审和实现各用各的。解决前置规范表点名要读的 Rule。示例只允许出现 Rule 里已经规定的形态。技能不定义第二套契约。坑8范围还没确认就把文件写进仓库现象一句话需求刚进会话技能直接落盘术语和边界都是模型补的。解决工作流第一步写明「确认前不落盘」。背景、边界、术语未确认停止写文件把问题交还用户。坑9没有内容就删掉强制章节现象本期不改库表于是整节数据库变更被删掉。解决强制章节保留。无变更写「无」。缺章视为未完成。坑10样本技能原样复制到另一个仓库现象样本里的输出目录、包名或分层、接口写法被贴进技术栈不同的目标仓库。解决迁移时单列差异表逐项改路径、分层、接口契约和版权约定。差异表没改完不启用这份技能。坑11写方案的技能顺手改了源码或执行了 DDL现象需求设计文档还在评审仓库里已经出现新表或新接口。解决在技能目的里写明只新增这一份 Markdown。落地实现点名下游技能并且必须等用户明确要求实施之后才调用。八、能力边界要客观认清这套PRD Harness体系擅长✅统一团队PRD输出格式、章节结构、用户故事书写规范。✅自动识别文档常见缺陷模糊描述、缺失章节、缺失验收条件。✅将重复的整理、拆解、自检工序沉淀为可复用资产不用每次写长篇提示词。✅团队成员之间共享同一套文档约束消除会话之间输出漂移。✅文档技能写明只产出文档不改源码、不执行 DDL下游工序点名其他技能。✅强制章节缺一不可没有内容时写「无」文件名和目录固定确认之前不落盘。这套体系不擅长也不打算做❌不能替代产品经理做业务判断、做需求取舍、定义业务目标。❌不能凭空从少量碎片化信息脑补完整业务逻辑。❌不能在技能示例里另造一套和 Rules 冲突的接口或库表契约。❌不能把另一个仓库的技能原样复制过来就启用也不能用方案里的代码片段代替已经实施的代码。本质非代码场景Harness也是把团队已经存在的文档标准数字化交付给AI而不是凭空创造产品判断力。九、总结本篇我们完成Agent Harness第一次跨领域迁移从代码开发迁移到PRD产品需求文档。Rules定义PRD文档长什么样强制章节、用户故事格式、写作红线只定标准不写执行步骤。Skills文档生产的原子工序原始需求整理、用户故事拆解、PRD自检审查一个Skill一件事不做大流程编排。Agents岗位角色需求整理Agent、撰稿Agent、评审Agent依靠Skill白名单实现角色权限隔离设置人工业务卡点。记住核心工作流原始素材 → 整理Agent → 人工确认素材 → 撰稿Agent产出初稿 → 评审Agent输出检查清单 → 人工评审修改。再次重申Harness通用思想不要依赖单次会话内的临时提示词把标准、工序、岗位角色沉淀为可Git版本管理的文件体系让AI辅助文档从一次性聊天输出走向标准化流水线。