通义千问写阿里中台风格PRD提示词完整教程与高效实战技巧

写中台PRD最怕什么？最怕写到最后成了单点业务需求，完全没法复用，更别提沉淀成原子能力了。这篇文章直接给一套可用的提示词框架，配合大模型生成，能确保输出内容符合阿里中台规范——业务域清晰、能力复用明确、接口契约严谨。

核心思路是：提前把角色定义死，把输入条件锁死，把输出格式框死。这样大模型就不会跑偏。

明确中台定位与约束条件

提示词开头就得把身份定死了。你是一名阿里系中台产品经理，当前负责建设【用户中心】能力域，所有输出必须遵循《阿里中台产品设计规范V3.2》。不接受“提升体验”“优化流程”这类模糊表述，每项需求必须对应可沉淀、可编排、可计量的原子能力。

输入里必须带齐三项硬性信息：【业务域名称】、【能力归属中台，比如用户中心/交易中心/履约中心】、【调用方系统列表，比如淘特APP、1688商家后台】。少一个都不行——没有这三项，生成内容自动判定为前台PRD，不予输出。

结构化输出：按中台PRD六要素驱动

要求大模型严格按照以下六要素顺序组织内容，跳过任何非必需章节。

第一，能力摘要。一句话定义该能力的中台价值。举个例子：“提供跨业务域的实名认证状态统一查询与刷新能力，支撑淘系、飞猪、高德等12个业务方实时校验用户实名有效性。”——这话说出来，就知道不是单点需求了。

第二，能力契约。列出输入参数（字段名、类型、是否必填、示例值），输出结构（JSON Schema格式，含code/msg/data三级嵌套），以及错误码表（code、含义、触发条件、建议动作）。注意：错误码必须包含BUSINESS_REJECTED（业务拒绝）、THROTTLE_LIMIT（限流触发）、CACHE_MISSED（缓存穿透）这三类标准码，这是中台统一约定的底线。

第三，能力边界。必须明确写出三条“不支持”的场景。比如“不支持对已注销用户的证件信息做反向查询”“不支持返回公安部原始核验流水号”“不支持按地域维度聚合统计认证通过率”。说得越清楚，对接方越不会踩坑。

第四，调用关系图。用文字描述上下游依赖，格式为“上游→本能力→下游”。例如：“实人认证网关→实名状态查询服务→订单创建服务、营销发券服务、客服工单系统”。上下游清晰，编排才靠谱。

第五，变更影响范围。列出本次迭代需同步升级的SDK版本号、需更新的OpenAPI文档路径、需通知的对接负责人邮箱列表（格式：姓名@alibaba-inc.com）。这块最容易漏，很多问题都出在这里。

第六，埋点清单。每个埋点必须含事件ID（如UC_AUTH_STATUS_QUERY_SUCCESS）、触发时机（比如“HTTP 200且data.status=‘VERIFIED’时”）、上报字段（包括user_id、biz_scene、response_time_ms、cache_hit_flag）。埋点不是为了看数据，是为了让能力可计量。

禁用词与替换规则

光有正向指令还不够，得更防着大模型自己发挥。给一套替换规则，能避免大量无用输出。

第一套是全局替换指令：禁止出现“用户想”“客户希望”“我们认为”这类主观表述，全部转为客观能力声明。比如“用户希望快速看到认证结果”要改成“能力需保证P95响应时长≤300ms，缓存命中率≥99.2%”。

第二套是术语映射表：把“功能”换成“能力”，把“页面”换成“前端接入点”，把“数据表”换成“领域实体”，把“管理员”换成“租户运营人员”，把“权限”换成“租户级能力授权策略”。一字之差，体现的是一种思维方式。

第三套是否定式校验：在提示词末尾追加一句——若生成内容中间出现“个性化”“定制化”“专属”“独立部署”“免开发”等任何一词，立即终止输出并返回错误提示。这些词违反中台“统一供给、配置驱动”的根本原则，出现一次，整篇重来。

这套框架用下来，大模型产出的PRD至少在结构上不会跑偏，剩下的就是细节打磨了。