夜雨聆风
乱码，样式不对
上面的问题都归咎于一开始没有搭好产品经理AI工作台。
1. 产品上下文配置
Agent 不懂你的业务，就会写出“通用正确、业务无用”的 PRD。
建议在项目目录里维护：
/docs/context/business-background.md # 业务背景user-roles.md # 用户角色current-process.md # 现有流程pain-points.md # 问题与痛点business-rules.md # 业务规则system-landscape.md # 周边系统data-dictionary.md # 核心字段glossary.md # 术语表
这一步相当于给 Agent 建“产品知识库”。
2. 工作方式配置：AGENTS.md
Codex 官方建议使用AGENTS.md给项目提供持久化指导，Codex 会在开始工作前读取这些文件；也可以配置全局规则和项目级规则，越靠近当前目录的规则优先级越高。
你可以在项目根目录放一个：
# AGENTS.md## Role你是资深企业软件产品经理，擅长 ERP、MES、SRM、OA、QMS、审批流、权限模型、接口集成和中后台系统设计。你的任务不是直接堆功能，而是先澄清业务目标、用户角色、流程边界、数据对象、异常场景和验收标准。## Working Principles1.在画原型或写 PRD 前，必须先输出：-背景理解-用户角色-当前问题-目标收益-业务流程-信息架构-核心页面清单-数据对象-规则约束-风险与待确认问题2.不允许直接生成大而全的 PRD。 先生成需求分析，再生成原型说明，最后生成 PRD。3.所有需求必须区分：-业务目标-用户故事-功能需求-非功能需求-数据需求-接口需求-权限需求-异常场景-验收标准4.如果需求不完整，先列出信息缺口，不要脑补关键业务规则。5.输出内容必须适合企业系统落地，避免互联网 C 端产品话术。## Output Standards所有页面设计说明必须包含：-页面目标-入口路径-使用角色-页面布局-字段说明-操作按钮-状态流转-校验规则-权限控制-异常提示-与其他系统的关系所有 PRD 功能点必须包含：-功能描述-用户故事-前置条件-主流程-分支流程-异常流程-字段规则-权限规则-接口依赖-验收标准
这个文件的价值很大。以后你每次让 Agent 处理这个项目，它都会按你的产品方法论来。
3. 阶段门配置：不要让 Agent 跳步骤
很多 AI 写 PRD 的问题是：它会从一句话需求直接生成几十页文档，看起来完整，其实中间全是脑补。
建议配置成 5 个阶段门：
阶段 1：需求理解输出：业务背景、目标、用户、痛点、范围、假设、待确认问题阶段 2：业务建模输出：业务流程、角色权限、状态机、数据对象、规则清单阶段 3：原型规划输出：页面清单、导航结构、核心页面布局、字段与按钮阶段 4：PRD 生成输出：完整功能说明、流程说明、字段说明、权限说明、接口说明、验收标准阶段 5：评审检查输出：遗漏项、冲突项、风险项、可开发性检查、测试用例建议
你可以在 prompt 或 Skill 里强制要求：
除非我明确说“进入下一阶段”，否则不要直接进入原型或 PRD 编写。这样 Agent 就不会越过需求分析，直接写“漂亮废话”。
4. 产品模板配置
把你的常用模板沉淀下来，而不是每次重新提示。
建议维护：
/templates/requirement-analysis-template.mdprototype-spec-template.mdprd-template.mdfield-description-template.mdpermission-matrix-template.mdapi-requirement-template.mdtest-case-template.md
例如 PRD 模板可以固定为：
# PRD 模板## 1. 背景与目标## 2. 需求范围## 3. 用户角色## 4. 业务流程## 5. 功能清单## 6. 页面原型说明## 7. 字段说明## 8. 权限控制## 9. 状态流转## 10. 业务规则## 11. 接口需求## 12. 数据埋点 / 日志## 13. 异常场景## 14. 非功能需求## 15. 验收标准## 16. 待确认问题
Agent 的输出质量，很大程度取决于你给它的模板质量。
5. Skill 配置
Codex 支持用 Agent Skills 扩展特定能力。官方说明里，Skill 可以把说明、资源、脚本封装成可复用工作流；Codex 会根据任务描述显式或隐式调用对应 Skill。
你可以给产品经理配置几类 Skill：
skills/requirement-research/ SKILL.mdenterprise-prd/ SKILL.mdprototype-planning/ SKILL.mdpermission-design/ SKILL.mdworkflow-modeling/ SKILL.mdapi-requirement-analysis/ SKILL.mdprd-review/ SKILL.md
例如enterprise-prd/SKILL.md：
---name: enterprise-prddescription: 当用户需要编写企业系统、中后台系统、ERP/MES/SRM/OA/QMS/CRM 类 PRD 时使用。---# 企业系统 PRD Skill## 目标帮助产品经理生成适合研发、测试、实施、业务方评审的企业系统 PRD。## 工作步骤1.先判断需求是否完整。2.如果不完整，列出待确认问题。3.根据用户角色和业务流程拆解功能。4.输出页面清单。5.输出字段、按钮、状态、权限、接口、异常场景。6.输出验收标准。7.最后输出风险和待确认事项。## 禁止行为-不要直接输出空泛描述。-不要省略异常流程。-不要省略权限控制。-不要忽略接口依赖。-不要把业务规则写成 UI 描述。## 输出格式必须按照以下结构：1.需求理解2.业务流程3.用户角色4.功能清单5.页面说明6.字段说明7.权限设计8.状态流转9.接口需求10.异常场景11.验收标准12.待确认问题
这就是把你的“产品经理经验”封装成 Agent 可复用能力。
6. 工具和环境配置
Codex Cloud 的环境会 checkout 仓库、运行 setup script、设置网络权限，然后 Agent 在循环中编辑代码、运行检查、验证结果；如果仓库里有AGENTS.md，它还会用它来找项目特定的 lint/test 命令。
产品经理场景下，可以不只是代码仓库，而是建立一个“产品工作仓库”：
product-agent-workspace/AGENTS.md/docs/ /context/ /requirements/ /prd/ /prototype/ /review//templates/ prd-template.md prototype-template.md field-template.md permission-template.md/skills/ enterprise-prd/ prototype-planning/ prd-review//scripts/ check-prd-completeness.py generate-field-table.py validate-permission-matrix.py
这样你不是让 Agent 在聊天框里临时发挥，而是让它进入一个有目录、有模板、有规则、有检查脚本的工作环境。
7. 检查机制配置
Harness engineering 里最关键的是反馈回路。也就是：Agent 产出以后，要自动检查有没有遗漏、冲突、不可开发的地方。
可以配置这些检查项：
PRD 完整性检查：- 是否有背景目标？- 是否有用户角色？- 是否有业务流程？- 是否有页面清单？- 是否有字段说明？- 是否有权限规则？- 是否有状态流转？- 是否有异常场景？- 是否有接口需求？- 是否有验收标准？原型可开发性检查：- 每个按钮是否有动作？- 每个字段是否有类型、必填、校验规则？- 每个状态是否有来源和去向？- 每个页面是否有入口？- 每个异常是否有提示语？- 是否考虑空数据、加载中、失败、无权限？业务一致性检查：- 流程和页面是否一致？- 权限和角色是否一致？- 字段和接口是否一致？- 状态和操作按钮是否一致？- 业务目标和功能清单是否一致？
可以让 Agent 每次输出后都追加一段：
请基于《PRD 完整性检查清单》对上面的内容进行自检，并列出：1. 已覆盖项2. 缺失项3. 可能冲突项4. 需要业务方确认的问题5. 建议下一步动作
这比“帮我优化一下 PRD”有效得多。
8. 评审标准配置
你还可以把不同角色的评审视角配置进去。
业务方视角：- 是否解决真实业务问题？- 流程是否符合实际操作？- 是否减少人工沟通成本？研发视角：- 功能边界是否清楚？- 字段规则是否完整？- 接口依赖是否明确？- 状态流转是否可实现？测试视角：- 是否有明确验收标准？- 异常场景是否完整？- 权限组合是否可测试？实施视角：- 是否支持配置化？- 是否考虑多组织、多语言、多时区？- 是否便于培训和推广？管理层视角：- 是否有业务价值？- 是否能量化收益？- 是否有风险和投入产出说明？
这样 Agent 不是只站在“写文档”的角度，而是模拟一个完整项目团队在评审。