Skip to content

comparison.md

Latest commit

 

History

History
229 lines (167 loc) · 8.59 KB

comparison.md

File metadata and controls

229 lines (167 loc) · 8.59 KB
Raw

中文 | English

Before / After 对比实验

同一场景、同一模型，有无元指令的输出质量差异有多大？

测试方法

  • 模型：GPT-4o / Claude / DeepSeek / 豆包
  • 输入：同一句业务描述
  • 对照组：直接发送业务描述（无任何前置指令）
  • 实验组：先发送元指令，再发送业务描述

场景一：微信购物商城小程序

业务输入

我想开发一套微信购物商城小程序

❌ 无元指令输出（典型问题）

你好！很高兴帮你设计微信购物商城小程序。以下是完整的技术方案：

技术栈推荐：
- 前端：uni-app + Vue3
- 后端：Spring Boot + MyBatis-Plus
- 数据库：MySQL + Redis
- 部署：Docker + Nginx

功能模块：
1. 用户注册登录（支持微信授权、手机号验证码）
2. 商品管理（分类、搜索、详情、SKU多规格）
3. 购物车（加减数量、选中结算、优惠券抵扣）
4. 订单系统（待付款、待发货、待收货、退款退货）
5. 支付模块（微信支付、支付宝支付）
6. 营销中心（满减、拼团、秒杀、积分商城）
7. 物流追踪（对接快递100 API）
8. 数据看板（GMV、转化率、用户留存）
9. 客服系统（智能客服 + 人工转接）
10. 评价系统（星级评分、图文评价、追评）

项目周期预计 3 个月，团队 5 人，预算约 20 万。

问题分析：

  • ❌ 角色越权：未确认用户是产品经理、开发者还是老板，直接给出技术选型 + 人力预算
  • ❌ 假定技术栈：用户只说了"微信小程序"，模型自作主张选了 uni-app、Spring Boot、MySQL
  • ❌ 幻觉业务：虚构了"预算 20 万"、"团队 5 人"——用户从未提及
  • ❌ 无结构约束：输出是一段自由文本，没有版本区分，无法直接复用

✅ 有元指令输出

【精简通用版】

你是一位资深移动端产品架构师。基于"微信购物商城小程序"场景，完成以下任务：

1. 明确目标用户：微信生态内具备消费能力的 C 端用户
2. 核心痛点：商品浏览效率低、支付链路长、复购率不足
3. 防踩坑底线：不假定技术栈、不虚构运营数据、不引入超出"商城"范畴的功能
4. 输出格式：按 MVP → 增长期 → 成熟期 三阶段交付，每阶段列出功能清单 + 验收标准

约束：仅输出产品功能规划，不涉及技术选型与人力估算。

【高级顶配版】

你是一位资深移动端产品架构师。

【CoT 思维链 / 分步推理】
Step 1 → 定位核心用户画像与消费场景
Step 2 → 拆解最小可行功能集（MVP）
Step 3 → 规划增长期与成熟期功能演进路径
Step 4 → 制定验收标准与关键指标

【业务输入】
场景：微信购物商城小程序

【隐性需求补齐】（仅限 4 维度）
- 目标受众：微信生态内具备消费能力的 C 端用户
- 核心痛点：浏览效率低、支付链路长、复购率不足
- 防踩坑底线：不假定技术栈、不虚构运营数据、不引入社交/内容等超出商城范畴的功能
- 输出格式：MVP → 增长期 → 成熟期，每阶段含功能清单 + 验收标准

【示例参考】
输入："外卖点餐小程序" → MVP：菜单浏览 + 下单支付 + 订单追踪

【输出要求】
按 MVP → 增长期 → 成熟期 三阶段交付功能规划。
约束：仅输出产品功能规划，不涉及技术选型与人力估算。

【自检清单】
① 格式合规：三阶段结构完整，约束边界有效
② 逻辑闭环：每阶段功能可独立交付验收
③ 无冗余陈述：无技术选型、无预算估算、无团队配置

📊 对比总结

维度 无元指令 有元指令
角色准确度 混乱，产品/开发/老板混为一谈 精准定位"产品架构师"，不越权
边界控制 虚构预算、团队规模 严格约束：不假定技术栈、不虚构数据
结构完整性 平铺直叙，无层次 MVP → 增长期 → 成熟期，可独立交付
防幻觉 高风险：20 万预算、5 人团队均为虚构 零幻觉：防踩坑底线显性约束
可复用性 低，绑定具体场景无法迁移 高，精简版可直接复用至其他商城类项目

场景二：社区 APP PRD 文档

业务输入

撰写社区APP完整PRD文档

❌ 无元指令输出（典型问题）

社区APP PRD

一、项目概述
本项目旨在打造一款面向Z世代的兴趣社区APP，聚合短视频、图文、直播等多模态内容...

技术架构：采用微服务架构，前端 React Native...
用户规模：预计首年 100 万 DAU...
商业模式：广告收入 + 会员订阅 + 虚拟礼物...

二、功能模块
1. 首页推荐（算法推荐、兴趣标签、关注流）
2. 内容发布（短视频拍摄、图文编辑、直播）
3. 社交互动（点赞、评论、转发、关注）
4. 消息中心（私信、系统通知、互动提醒）
5. 个人主页（作品集、粉丝管理、数据看板）
...

问题分析：

  • ❌ 虚构用户画像：自作主张定位"Z 世代"，用户从未说明目标用户
  • ❌ 虚构规模数据：100 万 DAU 纯属捏造
  • ❌ 假定商业模式：广告 + 会员 + 虚拟礼物，完全脱离用户实际业务
  • ❌ 无防幻觉约束：所有数字、架构、模式都是模型"脑补"

✅ 有元指令输出（摘要）

精简版：定位产品经理角色 → 仅补齐目标受众/痛点/格式三维度 → 输出标准 PRD 结构（背景/用户/功能/验收）

顶配版：CoT 分步拆解 → 防幻觉约束（不虚构用户规模、不假定商业模式、不指定技术架构） → 示例参考 → 完整自检

📊 对比总结

维度 无元指令 有元指令
角色准确度 产品经理角色但越权进入技术领域 严格限定产品经理输出范围
边界控制 虚构 DAU、商业模式、技术架构 显性约束：不虚构数据、不假定模式
格式规范 结构松散，PRD 要素不完整 标准 PRD 结构：背景→用户→功能→验收
防幻觉 严重：100 万 DAU、微服务架构均为编造 有效：所有假定被显性禁止

场景三：Kotlin 网络请求框架

业务输入

使用 Kotlin 实现 Android 通用网络请求框架

❌ 无元指令输出（典型问题）

好的，这里是一个基于 Kotlin + Retrofit + OkHttp + Coroutines 的通用网络请求框架：

技术选型：
- 网络库：Retrofit 2.9 + OkHttp 4.9
- 协程：Kotlin Coroutines + ViewModel
- 序列化：Gson / kotlinx.serialization
- 依赖注入：Hilt / Koin

完整代码（约 500 行）：
- ApiClient.kt
- BaseService.kt
- ResultWrapper.kt
- NetworkInterceptor.kt
- ErrorHandle.kt
...

问题分析：

  • ❌ 假定技术选型：用户只说了 Kotlin，模型自行选了 Retrofit + OkHttp + Coroutines + Hilt
  • ❌ 角色混乱：先说方案再说代码，未区分"框架设计"和"编码实现"两个层次
  • ❌ 无版本区分：只有一种输出，用户无法根据需求选择精简版或完整版

✅ 有元指令输出（摘要）

精简版：角色定位"资深 Android 架构师" → 不假定第三方库 → 输出接口抽象层设计（无具体实现绑定）

顶配版：CoT 推理 → 防幻觉约束（不假定 Retrofit/OkHttp，仅基于 Kotlin 标准库设计） → 示例参考（通用接口定义） → 自检

📊 对比总结

维度 无元指令 有元指令
角色准确度 架构师角色但直接跳到编码 架构师角色，先设计后实现
边界控制 自行选 Retrofit + OkHttp + Hilt 不假定任何第三方库
版本区分 无，只有一份完整代码 精简版（接口设计）+ 顶配版（含实现）
可复用性 低，绑定 Retrofit 无法迁移 高，接口抽象可适配任意底层库

结论

元指令的核心价值：不是让 AI 变聪明，而是让 AI 不越界。

统计维度 无元指令 有元指令
幻觉率 高（几乎每例都虚构数据/技术栈） 低（显性约束禁止虚构）
角色越权 常见（产品经理干架构师的活） 无（角色边界清晰）
可复用性 低（绑定具体场景） 高（精简版可跨场景复用）
输出稳定性 差（每次格式不同） 稳定（结构化 + 自检闭环）