使用Agent Harness构建PRD生产流水线：产品文档的Rules‑Skills‑Agents

很多读者会产生疑问：Agent Harness是不是只能用来写代码？

答案是否定的。
Agent Harness本质是一套把团队的成熟标准、工序流程、岗位分工沉淀为可版本管理文件的工程范式，编码只是它的其中一个落地场景。

从本篇开始，我们跳出IDE与代码生成，把这套范式迁移到研发团队日常高频的文档产出。第一个场景选择PRD产品需求文档，产品、研发同学日常都要写、评审PRD，和原有读者群体高度契合。

一、AI辅助写PRD的普遍痛点

现在大家已经习惯用大模型辅助产出PRD初稿，但绝大多数使用方式还是会话内粘贴一大段提示词，每次新会话全部要重新复述一遍团队文档规范，会遇到这些典型问题：

1. 每次对话重复交代PRD章节结构、术语、书写约束，换会话规范全部丢失。
2. AI经常自作主张膨胀需求范围，主动增加本期不在范围内的功能点。
3. 产出文档看起来章节齐全，但大量描述模糊，缺少非功能需求、边界条件、风险评估，开发拿到无法直接开工。
4. 用户故事格式不统一，验收条件缺失，前后文档术语打架。
5. 写完没有内置自检环节，只能完全依赖人工逐字通读排查漏洞。
6. 范围、目标和术语还没确认，文件已经落盘，猜出来的内容变成了正式文档。
7. 某一章本期没有内容，就被整章删掉，评审分不清是「确认没有」还是「写漏了」。
8. 产品 PRD 和需求设计文档被写成同一份：用户故事里出现表名和接口路径，需求设计文档里又没有可验证的验收条件。评审时分不清该由产品确认业务，还是由研发确认落地方案。

很多人的解法是不断加长提示词，但提示词依附单次会话，不能纳入Git版本管理，团队成员之间无法共享同一套约束。

而Harness的思路，是把PRD相关的文档契约、原子工序、岗位角色，全部沉淀成独立文件，不绑定单次聊天窗口。

和代码场景做一次类比对照，帮助理解概念迁移：

• 代码场景 Rules：编码规范、接口契约，规定代码长什么样。

• PRD场景 Rules：PRD文档规范、术语字典、书写红线，规定一份合格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/

区分用户级 / 项目级

1. 项目级：.harness‑prd 整个目录，提交Git。存放团队统一PRD模板、规则、工序、角色，全团队共用。
2. 用户级：放在本机个人目录，存放个人写作偏好，禁止提交Git，例如个人习惯的简版PRD模板。

三、Rules：PRD静态契约规范

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职责。

四、Skills：PRD原子化工序工具箱

遵循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‑review PRD自检审查

文件路径：.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文档为空，则终止执行。

其余Skill：parse‑user‑story（用户故事拆解）、check‑demand‑ambiguity（需求歧义检查）、gen‑prd‑draft（生成PRD初稿）、extract‑checkpoint（从PRD提取测试要点），均遵循相同结构：元数据、使用时机、执行步骤、自检清单、退出条件。

重要：Skill内部不做流程串联，例如不要在sort‑raw‑demand里面写“整理完素材之后调用生成PRD”，串联调度交给Agent。

五、Agents：PRD岗位角色编排

Agent代表岗位角色，负责任务接收、按顺序调度各个Skill，设置人工卡点；通过allowed_skills白名单控制可以调用哪些Skill，实现权限隔离。

三个核心Agent：

1. demand‑collate‑agent：需求整理Agent。接收原始业务输入，输出结构化素材池，不产出正式PRD。
2. prd‑write‑agent：PRD撰稿Agent。基于已经确认的素材池，调用生成初稿相关Skill，产出PRD初稿。
3. prd‑review‑agent：PRD评审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 与需求设计文档各走各的技能，差别见「写在前面」。下面是两段工序接在一起之后的顺序。

1. 输入：原始业务信息（会议纪要、口述需求、零散笔记）
2. 唤起 demand‑collate‑agent，调用sort‑raw‑demand，输出结构化需求素材池。
3. 🚩人工卡点1：人审阅素材池，补全缺失信息，确认素材，这一步AI不能替代业务判断。素材未确认，后续流程禁止执行。
4. 素材确认完成，唤起prd‑write‑agent，调度Skill生成PRD初稿。
5. 唤起prd‑review‑agent，执行自检Skill，输出PRD问题检查清单。
6. 🚩人工卡点2：人根据检查清单修改PRD，完成内部评审。
7. 输出评审通过、可交付研发的正式PRD文档。
8. 研发接手已确认的 PRD，使用 create-proposal 生成需求设计文档。这一步仍然只写 Markdown。
9. 🚩人工卡点3：人评审需求设计文档。未通过，不进入编码技能。
10. 用户明确要求实施之后，再按文档中的顺序调用建表、模型、服务、接口技能。

流转关键约束

• prd‑review‑agent 的skill白名单里面，不允许调用生成PRD的Skill，只能做审查输出报告，保证评审角色不能直接改写文档，角色权责隔离。
• 任何Agent都禁止在业务信息缺失时自行脑补业务。
• create-proposal 的允许范围只有需求设计文档。它不调用改源码、执行 DDL 的技能；那些技能要等需求设计文档评审通过，并且用户明确要求实施。

七、落地踩坑清单（非代码Harness特有坑）

坑1：把业务决策写进Rules/Skills

现象：在规则、Skill里面写死业务功能。
解决：Rules只写文档格式、写作红线；业务内容由人输入，Harness只管产出物的质量约束，不管业务本身做什么。

坑2：去掉人工卡点，追求一键全自动产出PRD

现象：原始聊天记录直接丢进去，一键输出可交付PRD。
解决：业务判断只能由人完成；Harness解决文档规范性，不能替代产品做业务取舍。素材确认、PRD评审，必须保留人工节点。

坑3：Skill粒度过大，一个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辅助文档从一次性聊天输出，走向标准化流水线。