1. 摘要
我利用 TRAE SOLO 客户端 + 自研产品经理技能包，彻底改造了日常需求分析流程。从客户一句话需求开始，TRAE SOLO 能自动辅助判断需求真伪、输出可行性方案、生成完整 PRD 乃至高保真原型，将原本 2-3 天的前期分析工作压缩到 1 小时内，且方案质量远超个人凭经验产出的水平。
2. 背景
我是一名医疗信息化领域的产品经理，日常需要对接医院客户（尤其是临床护理科室）的各类需求。典型的痛点是：客户往往只说“我想要一个 XX 功能”，但背后真实需求模糊、真伪难辨；手动做需求拆解、方案设计、PRD 编写极其耗时，且容易遗漏边界条件。我希望借助 TRAE SOLO 的 AI 能力，建立一套可复用的需求分析自动化流水线。
3. 实践过程
（1）任务拆解：从原始需求到可交付方案
我将一个完整的需求分析任务拆解为 6 个强制顺序执行 的步骤，并固化到 TRAE SOLO 的 Prompt 规则中：
- 第一步：需求预处理 – 提取客户原始描述中的核心动作、场景、角色。
- 第二步：需求分类判断 – 判断属于真需求、伪需求还是问题型需求。
- 第三步：针对性分析 – 真需求则追问细节与边界；伪需求则给出拒绝理由或替代方案。
- 第四步：信息完整性判断 – 若信息不足，输出引导性问题让客户补充；若充分则进入下一步。
- 第五步：生成解决方案 – 基于完整信息输出技术可行的产品方案。
- 第六步：输出 PRD 与原型 – 自动生成规范的需求文档和可交互原型代码。
（2）使用 TRAE SOLO 的哪些能力
- 内置技能库：我在 TRAE SOLO 中预置了
Product-Manager-Skills共 48 个产品经理常用技能，覆盖用户研究、需求管理、产品规划、业务财务四大类。 - 自研组合技能：开发了一套名为「需求深度分析→方案编写」的链式技能，能根据步骤自动调用不同子技能（如
problem-statement、opportunity-solution-tree、prd-development）。 - 规则引擎：通过系统 Prompt 强制模型遵循工作流顺序和输出格式检查清单，防止跳步或敷衍输出。
- 代码生成：利用 TRAE SOLO 的 HTML/CSS/JS 生成能力，将 PRD 中的页面逻辑自动转化为可交互的原型。
核心技能示例（部分）：
jobs-to-be-done– 深度分析用户真正要完成的“任务”user-story-mapping– 将需求映射为用户活动步骤prd-development– 按行业标准生成 PRDprioritization-advisor– 评估需求优先级与 ROItam-sam-som-calculator– 快速估算功能市场规模（用于伪需求反驳）
（3）关键 Prompt / 操作过程
我设计了一个系统级 Prompt，强制 TRAE SOLO 扮演“临床护理高级产品经理”，并遵守严格的工作流。以下为核心 Prompt 片段：
# 角色定义
你是临床护理高级产品经理,专注于医疗信息化领域,拥有深厚的医疗专业知识、护理流程理解能力以及信息系统设计经验。
# ⚠️ 最高优先级规则
## 规则1: 严格遵守工作流程顺序
**禁止跳过任何步骤!** 工作流程必须按以下顺序依次执行:
首次用户输入 → 第一步预处理 → 第二步分类判断 → 第三步针对性分析 → 第四步信息完整性判断 → 输出引导或总结
用户补充信息 → 第四步信息完整性判断 → 根据判断结果输出
用户确认 → 第六步生成方案
## 规则2: 输出前必须完成的检查清单
每次输出前,必须确认:
- [ ] 第一步:需求预处理已完成
- [ ] 第二步:需求分类判断已完成
- [ ] 第三步:针对性分析已完成
- [ ] 第四步:信息完整性判断已完成
- [ ] 输出格式正确
## 规则3: 输出格式强制要求
...
实际对话示例（客户原始需求：“护士站想要一个患者概览功能”）：
- 我输入该需求 → TRAE SOLO 自动输出预处理结果、分类为“真需求（但信息不完整）”，并输出 5 个引导问题（如“大屏主要供哪个班次护士使用？”“需要展示哪些患者维度？”）。
- 我逐条回答后 → TRAE SOLO 判断信息完整，输出可行性方案（技术选型、数据流向、页面布局建议）。
- 我确认方案 → TRAE SOLO 调用
prd-development技能生成完整 PRD，并自动生成一个可交互的patient_profile.html原型。
（4）踩过的坑
-
坑 1：模型总想跳过预处理步骤
一开始没有强制检查清单，模型有时会直接输出方案而忽略需求真伪判断。解决方式：在系统 Prompt 中加入“输出前必须逐项打勾”的规则，并用示例输出格式锁死顺序。 -
坑 2：技能调用冲突
我的 48 个技能中有部分功能重叠（例如user-story和user-story-mapping都包含故事编写）。TRAE SOLO 有时会同时调用两者导致输出冗余。解决方式：在自研组合技能中显式指定“仅当步骤为‘生成方案’时调用prd-development，其他步骤不调用任何文档类技能”。 -
坑 3：原型生成过于通用
模型默认生成的 HTML 样式偏向通用后台，不符合医疗产品的视觉规范。解决方式：在 Prompt 中加入“生成原型时，使用深海绿绿/白色医疗风格，圆角卡片，适配 1920*1080 分辨率，并包含夜间模式开关”。
4. 成果展示
本次实践产出了一个可直接在浏览器中运行的患者画像（Patient Profile）原型页面，用于展示护士站大屏的核心视图。该原型包含：
- 患者基本信息栏（姓名、年龄、床号、风险标识）
- 生命体征趋势图（模拟 ECharts 数据）
- 护理任务清单（待办/已完成）
- 快捷操作按钮（录入体征、发送消息）
页面截图描述（因平台限制，仅展示关键区域）：
顶部为患者切换标签，左侧患者头像与关键指标，右侧为动态时间轴；整体风格符合临床护理系统简洁、高对比、低误操作风险的要求。
文件路径：file:///D:/solo coder PM/zhhl_Project/patient_profile.html
使用效果：
该原型从客户提出“想要患者概览大屏”到最终 HTML 文件生成，总共耗时 45 分钟，其中人工输入和确认仅占 10 分钟，其余由 TRAE SOLO 自动完成。护士长看到原型后直接确认了需求，后续未发生需求返工。相比之前手动画原型 + 写 PRD 至少 2 天的周期，效率提升约 95%。
