03-提示词技巧与实战场景演练
提示词技巧与实战场景演练
本文是 Claude Code AI 辅助编程系列的第 3 篇，讲解高效提示词的编写原则、常见提示词模式模板，以及从 CRUD 开发、Bug 修复到 PRD 生成、原型设计的完整实战案例。
第四章：高效提示词（Prompt）编写技巧
4.1 提示词基本原则
好的提示词决定了 AI 输出的质量。记住四个核心原则：
原则一：清晰具体——明确说出你要什么
AI 不会"猜"你的意思，你说得越具体，它做得越准确。
| 模糊（差） | 具体（好） |
|---|---|
| 帮我写个接口 | 帮我在 OSAPI/Controllers 下创建 InventoryCheckController，包含创建盘点单和查询盘点单两个接口 |
| 改一下这个 Bug | 调用 /api/PurchaseOrder/Create 时返回 500 错误，错误信息是"Object reference not set"，请帮我排查并修复 |
| 建个表 | 请设计一个商品盘点单表 goods_inventory_check，需要包含盘点单号、仓库ID、盘点状态、盘点时间等字段，遵循 CLAUDE.md 的数据库规范 |
原则二：提供上下文——告诉 AI 背景信息
AI 对你的业务背景了解有限，关键上下文需要你主动提供。
# 差：缺乏上下文
帮我写一个库存扣减的方法
# 好：提供充分上下文
帮我在 OSDAL/InventoryBatchDAL.cs 中新增一个批次扣减方法，
业务规则：
1. 按 FIFO（先进先出）顺序扣减批次库存
2. 如果库存不足且允许负库存，则创建 batch_type=1 的负库存批次
3. 每次扣减需要记录库存流水到 goods_inventory_transactions 表
参考现有的 SalesDeductionBLL 中的扣减逻辑。
常用上下文类型：
- 参考文件：
参考 OSBLL/PurchaseOrderBLL.cs 的代码风格 - 业务规则：
金额保留4位小数，状态字段100=正常、101=禁用 - 错误信息：直接粘贴完整的报错堆栈
- 数据示例：
入参示例：{"skuCode": "SKU001", "quantity": 10}
原则三：分步骤描述——复杂任务拆解为小步骤
不要一次丢给 AI 一个巨大的需求，拆成可管理的步骤效果更好。
# 差：一次性大需求
帮我实现完整的商品盘点功能，包括创建盘点单、录入盘点结果、
审批、盘盈盘亏处理、库存调整，全部代码都要写。
# 好：分步执行
第一步：先帮我设计商品盘点单的数据库表结构
（等 AI 完成后）
第二步：创建 OSModel 中的请求和响应模型
（等 AI 完成后）
第三步：实现 DAL 层的数据访问方法
（等 AI 完成后）
第四步：实现 BLL 层的业务逻辑
...
分步的好处：
- 每一步都可以检查确认，发现问题及时纠正
- 不会因为一步出错导致后面全部返工
- AI 在每一步都有更聚焦的上下文，输出质量更高
原则四：指定输出格式——明确期望的输出形式
# 差：不指定格式
帮我分析一下这段代码的问题
# 好：指定输出格式
请审查 OSDAL/InboundOrderDAL.cs 的代码，按以下格式输出：
1. 问题等级（严重/中等/建议）
2. 问题位置（文件名:行号）
3. 问题描述
4. 修复建议
4.2 常见提示词模式
以下是我们项目中最常用的提示词模板，可以直接套用。
4.2.1 代码生成类
新增完整模块：
请为"商品盘点"模块生成完整的分层代码，参考采购单模块（PurchaseOrder）的代码结构：
1. OSAPI/Controllers/InventoryCheckController.cs - API控制器
2. OSBLL/InventoryCheckBLL.cs - 业务逻辑层
3. OSDAL/InventoryCheckDAL.cs - 数据访问层
4. OSInterface/IInventoryCheckBLL.cs - BLL接口
5. OSInterface/IInventoryCheckDAL.cs - DAL接口
6. OSModel/Requests/InventoryCheckRequest.cs - 请求模型
7. OSModel/Response/InventoryCheckResponse.cs - 响应模型
业务功能：
- 创建盘点单（含盘点明细）
- 查询盘点单列表（支持分页、按仓库/状态筛选）
- 查询盘点单详情
- 提交盘点结果
遵循 CLAUDE.md 中的所有代码规范。
在现有文件中新增方法：
请在 OSBLL/GoodsInventoryStockBLL.cs 中新增一个方法：
方法名：GetLowStockWarnings
功能：查询所有低于安全库存的商品
入参：warehouseId（仓库ID，可选）
返回：List<LowStockWarningResponse>，包含商品名称、SKU、当前库存、安全库存、缺口数量
参考同文件中已有方法的代码风格。
根据产品文档生成代码：
请阅读 doc/产品文档/商品盘点/商品盘点功能PRD.md，
然后根据 PRD 中的业务流程和规则，生成 DAL 层的数据访问代码。
所有 SQL 字段名请先通过 MCP 查询表结构确认。
4.2.2 Bug 修复类
有明确报错信息：
调用 POST /OS/OSOilService/InboundOrder/Create 接口时返回 500 错误。
报错堆栈：
System.NullReferenceException: Object reference not set to an instance of an object.
at OSBLL.InboundOrderBLL.CreateOrder(CreateInboundOrderRequest request) in InboundOrderBLL.cs:line 156
at OSAPI.Controllers.InboundOrderController.Create(CreateInboundOrderRequest request) in InboundOrderController.cs:line 42
入参：
{
"warehouseId": "WH001",
"items": [{"skuCode": "SKU001", "quantity": 10}]
}
请帮我排查原因并修复。
现象描述但无报错：
入库单审批通过后，库存没有增加。
正常流程应该是：审批通过 → MQ回调 → 生成批次 → 增加库存。
请帮我排查是哪个环节出了问题。
可以从 CallbackBLL 的审批回调处理方法开始排查。
间歇性问题：
商品列表查询接口偶尔返回空数据，大部分情况正常。
怀疑是并发导致的问题。
请帮我检查 GoodsBaseInfoDAL 中的查询方法是否有线程安全问题。
4.2.3 代码审查类
安全审查：
请审查 OSDAL 目录下所有 DAL 文件，重点检查：
1. 是否存在 SQL 拼接（应该用参数化查询）
2. 是否有未验证的用户输入直接拼入 SQL
3. 是否有敏感信息硬编码
找到问题后列出文件名、行号和修复建议。
性能审查：
请审查 OSDAL/InboundOrderDAL.cs 的性能：
1. 是否存在 N+1 查询问题
2. 查询条件是否命中索引（可通过 MCP 查看表索引）
3. 是否有不必要的全表扫描
4. 大数据量场景下是否有性能风险
规范审查：
请检查 OSBLL/InventoryCheckBLL.cs 是否符合项目规范：
1. 模型类是否放在 OSModel 中（不允许在 BLL 定义内部类）
2. 是否使用了 dynamic 类型（禁止使用）
3. 操作日志是否复用了已有数据库连接
4. 状态字段是否使用了标准状态码（100/101）
4.2.4 数据库设计类
新建表：
请根据以下业务需求设计数据库表结构：
业务：商品盘点单管理
需要两张表：
1. 盘点单主表：盘点单号、仓库ID、盘点类型（全盘/抽盘）、盘点状态、
创建人、创建时间、审批状态
2. 盘点单明细表：关联盘点单、SKU编码、系统库存数量、实际盘点数量、
盘盈盘亏数量、差异原因
遵循 CLAUDE.md 数据库规范：
- utf8mb4 字符集
- 无外键约束
- 状态字段用 INT（100=正常）
- 金额 DECIMAL(15,4)、数量 DECIMAL(12,4)
请输出完整的 CREATE TABLE SQL 语句。
修改表结构：
请先通过 MCP 查看 goods_inventory_stock 表的当前结构，
然后为该表新增以下字段：
- safety_stock DECIMAL(12,4) 安全库存数量
- warning_enabled TINYINT(1) 是否启用预警 默认0
输出 ALTER TABLE 语句。
4.2.5 重构类
请重构 OSDAL/InboundOrderDAL.cs 中的 CreateInboundOrder 方法（约200行）：
1. 当前问题：方法过长，混合了参数校验、业务逻辑、数据库操作
2. 重构目标：拆分为多个职责单一的私有方法
3. 约束：不改变外部调用接口，不改变业务逻辑
4. 请先阅读代码并告诉我重构方案，确认后再动手修改
4.2.6 文档与 Skill 调用类
# 调用产品经理 Skill 写 PRD
/erp-product-manager
请为"商品报损/报溢"功能编写 PRD，业务背景：
仓库盘点后发现实际库存与系统库存不一致，需要通过报损/报溢单调整库存。
# 调用架构师 Skill 做技术分析
/technical-architect
请根据 doc/产品文档/商品盘点/商品盘点功能PRD.md 生成技术分析文档。
# 调用流水线 Skill 自动开发
/dev-pipeline-orchestrator
请根据 doc/开发文档/商品盘点/商品盘点开发任务拆解.md 执行完整开发流水线。
4.3 反面示例与改进
对比 1：模糊 vs 精确
❌ 模糊提示词：
"帮我写个查询接口"
✅ 精确提示词：
"请在 InventoryCheckController 中新增一个查询盘点单列表的接口：
- 路由：GET /OS/OSOilService/InventoryCheck/List
- 入参：warehouseId(可选)、status(可选)、pageIndex、pageSize
- 返回：分页的盘点单列表，包含单号、仓库名、状态、创建时间
- 参考 PurchaseOrderController 中 GetList 方法的实现风格"
为什么差别大：模糊的提示词让 AI 需要自己猜测接口名称、参数、返回格式、放在哪个文件，猜对的概率很低。精确的提示词把这些都确定了，AI 只需要专注写实现逻辑。
对比 2：缺乏上下文 vs 充分上下文
❌ 缺乏上下文：
"库存扣减有 Bug，帮我修"
✅ 充分上下文：
"销售扣减接口 /api/SalesDeduction/Deduct 存在问题：
当商品是散件类型（goods_type=2）时，扣减数量没有按最小单位换算。
例如：散装大米以'克'为最小单位，用户传入 quantity=1（千克），
应该自动换算为 1000 克再扣减，但目前直接用 1 去扣减了。
请检查 SalesDeductionBLL 中的扣减方法，
可能需要调用 UnitConversionBLL 做单位换算。"
为什么差别大：第一种 AI 需要先花大量时间搜索代码理解业务，可能还找错了方向。第二种直接定位到了问题根因、涉及的文件和可能的修复方向，AI 可以快速精准修复。
对比 3：一次性大需求 vs 分步拆解
❌ 一次性大需求：
"帮我实现完整的商品盘点功能，从建表到接口到测试全部搞定"
✅ 分步拆解：
第1轮："请先设计商品盘点相关的数据库表结构，输出 SQL"
→ 检查确认表结构没问题
第2轮："表结构OK，请生成 OSModel 中的实体类和请求/响应模型"
→ 检查确认模型类没问题
第3轮："模型OK，请实现 DAL 层的 CRUD 方法，SQL 字段名通过 MCP 确认"
→ 检查确认 DAL 没问题
第4轮："DAL OK，请实现 BLL 层的业务逻辑"
→ 检查确认 BLL 没问题
第5轮："BLL OK，请实现 Controller 层的 API 接口"
→ 最终检查
为什么差别大：一次性需求如果中间某个环节出错（比如表结构设计有误），后面的代码全部要返工。分步执行每一步都有检查点，能及时纠偏，最终质量反而更高。
对比 4：不指定参考 vs 指定参考模块
❌ 不指定参考：
"帮我写一个采购退货的 BLL"
✅ 指定参考模块：
"帮我写一个采购退货的 BLL（PurchaseReturnBLL），
参考 PurchaseOrderBLL 的代码结构和编码风格：
- 审批流程集成方式参考 PurchaseOrderBLL 的 SubmitForApproval 方法
- 操作日志记录方式参考 PurchaseOrderBLL 的 CreateOrder 方法
- 状态管理参考 PurchaseOrderBLL 中的审批状态码体系"
为什么差别大：指定参考模块后，AI 会先阅读参考代码，生成的代码与项目已有代码风格一致，审批集成方式也是复用已有模式而不是自己发明一套。
4.4 提示词进阶技巧
4.4.1 让 AI 先分析再动手
对于复杂任务，先让 AI 说方案，你确认后再执行，避免直接写出不符合预期的代码：
请先阅读 InboundOrderBLL.cs 和 InboundOrderDAL.cs 的代码，
然后告诉我：
1. 入库审批通过后的完整处理流程是什么
2. 涉及哪些表的数据变更
3. 如果我要加一个"部分入库"功能，需要改哪些地方
先分析，不要改代码，等我确认后再动手。
4.4.2 利用 CLAUDE.md 减少重复说明
很多规范已经写在 CLAUDE.md 里了，提示词中不需要重复，只需引用：
# 不需要这样重复写：
"请建表，字符集用 utf8mb4，排序规则 utf8mb4_0900_ai_ci，不要加外键，
状态字段用 INT 类型，金额用 DECIMAL(15,4)..."
# 只需要这样引用：
"请按 CLAUDE.md 的数据库规范建表"
4.4.3 多轮迭代优化
不要期望一次就得到完美结果，通过多轮对话逐步完善：
第1轮："帮我实现批次扣减方法"
第2轮："这个方法没有处理负库存的情况，请加上负库存逻辑"
第3轮："负库存逻辑OK，但是缺少操作日志记录，请补上"
第4轮："整体逻辑完成了，请帮我检查一下有没有遗漏的边界条件"
4.4.4 善用"请先读一下"
让 AI 先读代码再做判断，而不是凭空回答：
# 差：AI 只能猜
"InboundOrderDAL 的 CreateOrder 方法有什么问题？"
# 好：AI 先读后答
"请先阅读 OSDAL/InboundOrderDAL.cs 的 CreateOrder 方法，
然后告诉我这个方法有什么潜在的性能问题。"
4.4.5 给 AI 设定检查清单
让 AI 在完成任务后自查：
请生成盘点单 DAL 代码，完成后按以下清单自查：
□ SQL 字段名是否通过 MCP 验证
□ 是否使用参数化查询（禁止 SQL 拼接）
□ 是否记录了操作日志（使用 OperationLogHelper，复用连接）
□ 模型类是否放在 OSModel 中
□ 是否有 dynamic 类型（禁止使用）
□ 金额字段是否为 DECIMAL(15,4)
第五章：实战场景演练
5.1 场景一：新增 CRUD 接口
- 从需求描述到完整代码生成
- Controller → BLL → DAL → Model 全链路
- 遵循项目分层架构规范
5.2 场景二：数据库表设计与建表
- 业务需求分析
- 表结构设计（遵循字段规范）
- SQL 脚本生成
- 通过 MCP 验证表结构
5.3 场景三：Bug 定位与修复
- 提供错误信息让 AI 分析
- 引导 AI 阅读相关代码
- 逐步排查与修复
- 验证修复结果
5.4 场景四：编写单元测试
- 指定目标方法生成测试
- Mock 依赖项
- 边界条件覆盖
5.5 场景五：代码重构
- 识别代码异味
- 制定重构计划（Plan 模式）
- 分步执行重构
- 回归测试验证
5.6 场景六：产品文档与技术文档生成
- 使用
/erp-product-manager技能生成 PRD - 使用
/technical-architect技能生成技术方案 - 文档驱动开发流程
5.7 实操案例：零编程基础快速生成 PRD 文档
本节面向不会编程的产品人员或业务人员，演示如何通过自然语言对话，让 AI 帮你产出一份专业的产品需求文档（PRD）。全程不需要写一行代码。
5.7.1 案例背景
假设你是一名业务人员，接到了一个新需求：
加油站便利店需要一个商品调价功能，站长可以根据市场行情调整商品售价，调价前需要区域经理审批，审批通过后自动更新商品价格。
你需要把这个需求转化为一份正式的 PRD 文档。
5.7.2 第一步：用大白话描述需求
不需要任何专业术语，像和同事聊天一样把需求说出来：
/erp-product-manager
我需要做一个商品调价功能，大概是这样的：
1. 站长发现可乐批发价涨了，需要调整零售价
2. 站长在系统里提交调价申请，选择要调价的商品，填写新价格
3. 这个申请需要区域经理审批
4. 区域经理同意了，商品价格就自动变成新的
5. 如果区域经理不同意，就打回来，站长可以修改后重新提交
6. 要能看到这个商品历史上所有调过的价格记录
帮我写一份正式的产品需求文档
要点：调用
/erp-product-manager技能会自动激活 AI 的 ERP 产品经理角色，它会按照标准的 PRD 框架来组织你的需求，补充你没想到的细节。
5.7.3 第二步：AI 产出初稿，你来审核
AI 会生成一份包含以下结构的 PRD 文档：
文档通常包含：
├── 1. 文档信息（版本、日期、作者）
├── 2. 项目概述
│ ├── 项目背景
│ ├── 项目目标
│ └── 术语定义
├── 3. 需求范围
│ ├── 功能清单
│ └── 非功能需求
├── 4. 业务流程
│ ├── 主流程（Mermaid 流程图）
│ ├── 异常流程
│ └── 状态流转图
├── 5. 功能详细设计
│ ├── 调价申请
│ ├── 审批流程
│ └── 价格历史查询
├── 6. 数据设计
│ ├── 表结构建议
│ └── 字段说明
└── 7. 验收标准
审核重点——你需要检查以下内容：
□ 业务流程是否符合实际？（审批层级对不对？）
□ 有没有遗漏的场景？（比如：批量调价？调价生效时间？）
□ 状态流转是否完整？（草稿→待审批→已通过→已驳回→已撤销）
□ 术语定义是否准确？（你们公司内部的叫法对不对？）
5.7.4 第三步：针对性地补充和修改
审核后发现有遗漏或不满意的地方，继续用大白话修改：
文档基本可以，但需要改几个地方：
1. 审批不只是区域经理，还需要看金额：
- 单次调价涉及金额 < 500 元，区域经理直接审批
- 单次调价涉及金额 >= 500 元，区域经理审批后还需要大区总监审批
2. 增加一个"批量调价"功能，站长可以一次选多个商品统一调整
3. 调价不能立即生效，需要选择一个"生效日期"，到了那天凌晨自动切换价格
4. 补充一下：调价幅度超过 30% 时需要特别标红提醒审批人
请根据这些修改更新 PRD 文档
修改可以反复进行，直到你满意为止。每次只需要说哪里不对、想加什么，AI 会自动更新整个文档保持一致性。
5.7.5 第四步：产出最终文档
当 PRD 内容确认后，让 AI 保存为文件：
PRD 内容确认没问题了，请保存到 doc/PRD/商品调价功能PRD.md
后续衍生——一份 PRD 可以继续驱动：
# 生成技术分析文档
/technical-architect
请根据 doc/PRD/商品调价功能PRD.md 生成技术分析文档
# 生成开发任务拆解
/dev-task-breakdown
请根据技术分析文档生成开发任务拆解
给非技术人员的建议：你只需要负责到 PRD 这一步。PRD 写好后交给开发团队，他们会用后续的 Skill 继续驱动开发。你的核心价值在于把业务需求说清楚，AI 帮你把它结构化。
5.8 实操案例：从 PRD 生成静态原型页面
拿到 PRD 后，通常需要做 UI 原型让团队评审。传统做法是用 Axure、Figma 等工具手画，效率较低。现在可以让 AI 直接生成可交互的 HTML 静态原型页面。
核心要求：必须摆脱"AI 味"。 AI 默认生成的页面往往带有浓重的"AI 审美"——大面积渐变紫色、圆角卡片堆砌、无意义的装饰图标。这种页面一眼就能看出是 AI 生成的，用于正式评审显得不专业。本案例重点讲解如何通过提示词约束，产出干净、专业、像真正产品经理手画的原型。
5.8.1 为什么要生成 HTML 原型而不是用设计工具？
| 对比 | 传统设计工具（Axure/Figma） | AI 生成 HTML 原型 |
|---|---|---|
| 学习成本 | 需要学习工具使用 | 不需要，用自然语言描述 |
| 制作速度 | 一个页面需要数小时 | 几分钟生成多个页面 |
| 交互能力 | 需要手动配置交互 | 可以生成带交互逻辑的页面 |
| 修改成本 | 需要手动调整布局 | 一句话修改，AI 自动调整 |
| 适合场景 | 精细视觉设计 | 快速验证功能布局和流程 |
5.8.2 关键原则：消除"AI 紫色味"
AI 默认生成页面的典型特征（需要避免）：
❌ AI 味的典型特征：
- 大面积紫色/蓝紫色渐变背景
- 过度使用圆角卡片和阴影
- 无意义的渐变色按钮
- 空洞的 Hero Section（大标题 + 副标题 + 行动按钮）
- 过多的装饰性图标和插图
- 过度使用 flexbox 居中布局，所有元素都居中
- 配色方案千篇一律（紫→蓝渐变）
- 字体过大、间距过宽，信息密度极低
消除 AI 味的核心提示词策略：
样式约束（务必在提示词中明确声明）：
- 使用纯白底 + 浅灰边框的朴素设计风格
- 主色调使用 #1890ff（蚂蚁蓝）或 #409eff（Element 蓝），禁止使用紫色
- 按钮使用纯色实心，不要渐变
- 表格使用标准的带边框表格，不要卡片式布局
- 参考 Ant Design / Element UI 的管理后台风格
- 信息密度要高，不要大面积留白
- 不要添加任何装饰性插图或图标
- 字号正文 14px，标题 16-20px，不要超大字体
5.8.3 完整实操：生成商品调价原型
第一步：用一段话描述你想要的页面
请根据 doc/PRD/商品调价功能PRD.md 生成一套 HTML 静态原型页面。
页面清单：
1. 调价申请列表页（查看所有调价记录）
2. 新建调价申请页（选择商品、填写新价格）
3. 调价审批页（审批人查看调价详情并审批）
4. 调价历史查询页（查看某商品的历史价格变动）
样式要求（非常重要，严格遵守）：
- 参考 Ant Design Pro 管理后台风格，不要自创设计风格
- 纯白背景，不要任何渐变
- 主色 #1890ff，辅色 #52c41a（成功）/#f5222d（失败/拒绝）/#faad14（警告）
- 按钮使用纯色，不要渐变和阴影
- 表格使用 bordered 样式，带斑马纹
- 表单使用标准的 label + input 横向排列
- 左侧固定菜单栏 + 顶部面包屑导航 + 右侧内容区的标准后台布局
- 不要添加任何装饰性图片、插画或 SVG 图标
- 字号：正文 14px，表头 14px 加粗，页面标题 20px
- 整体信息密度要高，一屏内展示尽可能多的信息
- 不要使用紫色，不要使用渐变色
技术要求：
- 使用纯 HTML + CSS，不依赖任何框架
- 所有页面放在一个 HTML 文件中，通过 Tab 切换
- 表格数据使用静态模拟数据填充（5-8 条记录）
- 按钮和链接要有 hover 效果
- 表单要有基本的布局，不需要实际提交功能
请保存到 doc/prototype/price-adjustment.html
第二步：打开浏览器预览，逐页审核
生成后直接在浏览器中打开 HTML 文件预览。审核要点：
□ 整体布局是否像正规的管理后台？（不是营销落地页的风格）
□ 有没有紫色或渐变？（发现了立刻要求去掉）
□ 表格列是否合理？（字段是否齐全、列宽是否合适）
□ 表单字段是否和 PRD 一致？（有没有遗漏或多余的字段）
□ 状态标签颜色是否合理？（待审批-蓝色、已通过-绿色、已驳回-红色）
□ 信息密度是否够高？（不能半屏空白只有几个大卡片）
第三步：针对性修改
预览后发现问题，用自然语言描述修改需求：
原型整体不错，修改以下几个地方：
1. 列表页的表格增加两列："调价幅度"和"提交人"
2. "调价幅度"列如果超过 30% 显示红色字体
3. 新建页面的商品选择改成搜索下拉框的样子，不要普通的 select
4. 审批页面增加"审批意见"文本框和"审批记录"时间线
5. 顶部面包屑下面加一行统计栏：待我审批 X 单 | 本月已审批 X 单 | 已驳回 X 单
6. 所有金额显示统一保留 2 位小数，右对齐
反复修改直到满意，最终产出的原型可以直接用于团队评审会。
5.8.4 避坑指南：常见的 AI 原型问题
| 问题 | 表现 | 解决提示词 |
|---|---|---|
| 紫色渐变又出来了 | 背景或按钮莫名出现紫色 | "再次强调：禁止使用任何紫色(purple/violet)色值，全局搜索并替换" |
| 布局太像落地页 | 大 Banner + 三列卡片 + CTA 按钮 | "这是管理后台不是营销页面，使用左侧菜单+右侧内容的后台布局" |
| 信息密度太低 | 大面积空白，一屏只有几条数据 | "表格每页至少显示 10 行数据，减少不必要的间距和 padding" |
| 字体太大 | 标题 32px+，正文 18px+ | "正文 14px，标题最大不超过 20px，参考 Ant Design 的字号规范" |
| 按钮太花哨 | 渐变色 + 大圆角 + 光效 | "按钮使用纯色实心 4px 圆角，不要渐变、阴影和动画" |
| 配色不统一 | 每个页面用不同的颜色体系 | "所有页面统一配色：主色 #1890ff，成功 #52c41a，危险 #f5222d" |
| 响应式干扰 | 移动端适配代码干扰布局 | "这是桌面端后台系统，固定宽度 1200px 居中，不需要响应式" |
5.8.5 进阶：指定参考页面风格
如果你有一个已经做好的页面，可以让 AI 参考它的风格生成新页面，这是消除 AI 味最有效的方法：
请参考项目中已有的商品列表页面风格（OSAPI 前端的商品管理页面），
生成调价功能的原型页面，确保：
- 菜单结构、表格样式、按钮风格完全一致
- 颜色、字号、间距和已有页面保持统一
- 就像是同一个开发者写出来的页面
如果没有现成的页面参考，也可以指定一个知名的 UI 框架作为标杆：
# 指定 Ant Design 风格
样式完全参考 Ant Design Pro 的管理后台模板，
包括配色、表格、表单、按钮、标签等所有组件的视觉风格。
# 指定 Element UI 风格
样式完全参考 Element UI Admin 后台模板，
包括配色（主色 #409eff）、表格、表单等组件。
5.8.6 模板提示词：一键生成专业原型
以下是经过多次调优的"万能模板提示词"，可以直接复制使用，只需替换业务相关的内容：
请生成 [功能名称] 的 HTML 静态原型页面。
== 页面清单 ==
1. [列表页]：展示 [数据] 的列表，支持搜索、筛选、分页
2. [详情/表单页]：[创建/编辑] [数据] 的表单
3. [其他页面]：[页面用途说明]
== 样式规范（必须严格遵守）==
- 布局：左侧 200px 固定菜单栏 + 顶部面包屑 + 右侧内容区
- 框架风格：Ant Design Pro 管理后台
- 主色：#1890ff | 成功：#52c41a | 危险：#f5222d | 警告：#faad14
- 背景：纯白 #fff，页面背景 #f0f2f5
- 表格：bordered 带斑马纹，表头 #fafafa 背景
- 按钮：纯色实心 4px 圆角，不要渐变和阴影
- 字号：正文 14px，表头 14px bold，页标题 20px
- 信息密度：一屏尽量多展示信息，避免大面积留白
- 禁止：紫色、渐变色、装饰插画、超大字体、营销落地页风格
== 技术要求 ==
- 纯 HTML + CSS，单文件，Tab 切换页面
- 模拟数据 5-8 条
- 保存到 [文件路径]
总结：非技术人员使用 AI 的两个核心能力
- 说清楚需求 → AI 帮你结构化为 PRD（用
/erp-product-manager）- 说清楚长什么样 → AI 帮你生成可预览的原型页面（用样式约束提示词）
全程不需要写一行代码，但需要你有足够的业务判断力来审核 AI 的产出。AI 是工具，你才是产品的灵魂。
5.9 非技术人员快速上手：两个 Skill 从需求到原型
本节提供两个开箱即用的 Skill 模板，让完全不会编程的业务人员也能独立完成"需求描述 → PRD 文档 → 原型页面"的完整闭环。
你只需要两步：
第一步 第二步
┌────────────────┐ ┌────────────────┐
│ /prd-writer │ ──→ PRD ──→ │/prototype-ui- │ ──→ HTML 原型
│ 说清楚你要什么 │ .md 文档 │ designer │ 浏览器打开
│ （大白话描述需求）│ │（自动读 PRD 生成）│
└────────────────┘ └────────────────┘
5.9.1 Skill 1：通用 PRD 生成器（prd-writer）
注意：本项目已有
/erp-product-manager技能专门针对 ERP 进销存场景生成 PRD。如果你的需求是进销存相关的，优先使用/erp-product-manager，它内置了系统的 17 个业务模块知识和审批规范。下面这个
prd-writer是一个通用模板，适用于任何业务系统、任何行业，你可以根据自己的项目创建这个 Skill。
Skill 文件路径：.claude/skills/prd-writer/SKILL.md
如何复用到其他项目：
这是一个完全通用的 Skill，不依赖任何特定项目结构。如果你想在其他项目中使用它，只需在那个项目的根目录下创建 .claude/skills/prd-writer/SKILL.md 文件，并将下面的内容完整复制进去即可。
完整 Skill 内容（可直接复制创建）：
---
name: prd-writer
description: 通用PRD文档生成器，面向非技术人员。用大白话描述需求，自动产出结构化的产品需求文档。使用场景：需求整理、PRD编写、功能规划。
allowed-tools: Read, Write, Edit, Glob, Grep
---
# PRD Writer - 通用产品需求文档生成器
## 角色定义
你是一位经验丰富的产品经理助手，专门帮助非技术背景的用户将口语化的
业务需求转化为结构清晰、内容完整的产品需求文档（PRD）。
你的用户可能是：业务经理、运营人员、项目负责人、创业者——他们清楚业务
需要什么，但不擅长写技术文档。你的职责就是帮他们把"想法"变成"文档"。
**核心原则**：
- 用户说大白话，你产出专业文档
- 用户没提到的细节，你主动补充并询问确认
- 不写代码、不做技术设计，只专注于"做什么"而非"怎么做"
## 工作流程
### 第一步：需求倾听与澄清
收到用户的需求描述后，先分析以下要素，缺失的要主动追问：
| 要素 | 问题 | 示例 |
|------|------|------|
| 谁用 | 这个功能是谁在用？ | 站长、区域经理、仓库管理员 |
| 做什么 | 核心要做的事情是什么？ | 提交调价申请、审批入库单 |
| 为什么 | 解决什么问题？现在怎么做的？ | 现在用 Excel 手工记录，容易出错 |
| 怎么流转 | 需要谁审批？有没有流程？ | 站长提交 → 经理审批 → 自动生效 |
| 看什么 | 需要查看哪些数据？ | 历史调价记录、库存变动明细 |
| 特殊规则 | 有没有特殊的业务限制？ | 调价幅度不能超过 50% |
**如果用户描述太简略，请友好追问，例如**：
"你提到需要一个调价功能，我再确认几个细节：
1. 调价需要审批吗？几级审批？
2. 调价是立即生效还是可以指定生效日期？
3. 需要记录调价历史吗？
4. 有没有批量调价的需求？"
### 第二步：生成 PRD 文档
按照以下标准模板输出文档：
# [功能名称] 产品需求文档（PRD）
## 1. 文档概述
| 项目 | 内容 |
|------|------|
| 文档版本 | v1.0 |
| 创建日期 | YYYY-MM-DD |
| 需求来源 | [提出人/部门] |
## 2. 背景与目标
### 2.1 业务背景
[为什么要做这个功能？当前的痛点是什么？]
### 2.2 项目目标
[做完之后要达到什么效果？]
## 3. 用户角色
| 角色 | 说明 | 核心操作 |
|------|------|---------|
| 角色1 | 描述 | 能做什么 |
| 角色2 | 描述 | 能做什么 |
## 4. 功能清单
| 编号 | 功能名称 | 优先级 | 说明 |
|------|---------|--------|------|
| F-01 | xxx | P0(必须有) | xxx |
| F-02 | xxx | P1(应该有) | xxx |
| F-03 | xxx | P2(最好有) | xxx |
## 5. 业务流程
### 5.1 主流程
[用 Mermaid 流程图展示]
### 5.2 异常流程
[审批拒绝、数据异常等情况的处理]
## 6. 页面清单与字段说明
### 6.1 [页面1名称]（如：列表页）
- 页面用途：[一句话说明]
- 筛选条件：[可搜索/筛选的字段]
- 列表字段：
| 字段名 | 说明 | 示例值 |
|--------|------|--------|
| 单据编号 | 系统自动生成 | TJ-20250115-001 |
| 状态 | 当前流程状态 | 草稿/审批中/已通过 |
- 操作按钮：[新建/编辑/删除/提交审批/...]
### 6.2 [页面2名称]（如：新建/编辑页）
- 页面用途：[一句话说明]
- 表单字段：
| 字段名 | 类型 | 必填 | 说明 |
|--------|------|------|------|
| 商品名称 | 搜索下拉 | 是 | 选择要调价的商品 |
| 新价格 | 数字输入 | 是 | 调整后的价格 |
## 7. 状态流转
### 7.1 状态定义
| 状态 | 说明 | 可执行操作 |
|------|------|-----------|
| 草稿 | 初始状态 | 编辑、提交、删除 |
| 审批中 | 等待审批 | 审批通过、拒绝 |
| 已通过 | 审批完成 | 无 |
| 已拒绝 | 被驳回 | 修改重新提交 |
### 7.2 状态流转图
[Mermaid 状态图]
## 8. 业务规则
[列出所有业务限制和计算规则]
## 9. 验收标准
[功能做完后如何验证是否正确]
### 第三步：交互确认
文档生成后，主动询问用户：
- "请检查以上内容，有没有遗漏或不准确的地方？"
- "业务流程是否符合实际操作？"
- "还需要补充其他功能或规则吗？"
用户反馈后立即更新文档，直到用户确认无误。
## 输出规范
- 文档格式：Markdown
- 图表工具：Mermaid（流程图、状态图）
- 保存位置：由用户指定，默认 doc/PRD/
- 语言风格：专业但不晦涩，非技术人员能看懂
使用方法——直接这样对 AI 说即可：
/prd-writer
我需要一个员工请假审批的功能：
- 员工提交请假申请，填写请假类型、开始时间、结束时间、原因
- 请假 3 天以内部门经理直接审批
- 请假超过 3 天需要部门经理审批后，再交给人事总监审批
- 审批通过了就扣年假额度，不够扣的提示
- 要能看到自己的请假记录和剩余假期
帮我写成正式的 PRD 文档
AI 会自动按照 Skill 中定义的模板，帮你产出一份包含背景、流程图、页面字段、状态流转、业务规则、验收标准的完整 PRD。
5.9.2 Skill 2：前端原型设计师（prototype-ui-designer）
这个 Skill 已在项目中创建，文件位于 .claude/skills/prototype-ui-designer/SKILL.md。
它的核心能力是：读取 PRD 文档，自动生成 Ant Design Pro 风格的 HTML 原型页面，内置了严格的"去 AI 味"规范。
使用方法：
/prototype-ui-designer
请根据 doc/PRD/员工请假审批PRD.md 生成 HTML 原型页面。
包含：请假申请列表、新建请假申请、审批页面、我的假期余额。
保存到 doc/prototype/leave-approval.html
生成后直接在浏览器中双击打开 HTML 文件即可预览。
5.9.3 两步完整工作流演示
以下用一个完整案例演示从零开始的全流程：
场景：公司需要一个"会议室预约"系统
第一步：生成 PRD（3-5 分钟）
/prd-writer
我要做一个会议室预约系统，需求如下：
公司有 10 个会议室，大小不同（小型4人、中型8人、大型20人）。
员工可以在系统里预约会议室，选日期、时间段、会议室。
同一个会议室同一时间只能被一个人预约，不能冲突。
预约后可以取消，但开会前 30 分钟内不能取消。
管理员可以看到所有会议室的预约情况，也可以强制释放。
最好有个日历视图，一眼能看到哪天哪个会议室被约了。
帮我写 PRD，保存到 doc/PRD/会议室预约PRD.md
AI 产出 PRD → 你审核并反馈修改 → 确认定稿
第二步：生成原型页面（2-3 分钟）
/prototype-ui-designer
请根据 doc/PRD/会议室预约PRD.md 生成原型页面。
包含以下页面：
1. 会议室列表（管理员视角，展示所有会议室信息）
2. 预约日历视图（按周/日展示各会议室占用情况）
3. 新建预约（选择会议室、日期、时间段、填写会议主题）
4. 我的预约（个人预约记录列表，可取消）
5. 预约管理（管理员视角，所有预约记录，可强制释放）
保存到 doc/prototype/meeting-room.html
AI 产出 HTML → 浏览器打开预览 → 反馈修改 → 定稿
最终交付物：
doc/
├── PRD/
│ └── 会议室预约PRD.md ← 第一步产出
└── prototype/
└── meeting-room.html ← 第二步产出（浏览器直接打开）
这两个文件可以直接提交给开发团队或拿去做评审汇报，全程不需要写一行代码。
5.9.4 给非技术人员的使用建议
你擅长的事（AI 替代不了）：
- 理解业务痛点——为什么要做这个功能
- 梳理业务流程——实际工作中事情是怎么流转的
- 判断优先级——哪些功能是必须的，哪些可以先不做
- 审核输出质量——AI 写的对不对、全不全、有没有遗漏
AI 擅长的事（让 AI 帮你做）：
- 把零散的需求组织成标准文档结构
- 补充你没想到的异常场景和边界条件
- 画流程图、状态流转图
- 生成可预览的原型页面
常见问题：
| 问题 | 解决方法 |
|---|---|
| 不知道怎么描述需求 | 就像和同事聊天一样说，AI 会主动追问细节 |
| PRD 里有不懂的术语 | 直接问 AI："状态流转是什么意思？" |
| 原型页面又出现紫色了 | 追加一句："去掉所有紫色，严格使用蓝色主题" |
| 想修改原型某个细节 | 直接说"把表格第三列改成下拉筛选" |
| 需求变了想重新生成 | 直接说新的需求，AI 会自动更新 PRD 和原型 |
| 不知道需求全不全 | 让 AI 检查："帮我看看这份 PRD 还有什么遗漏" |
核心理念：你只需要说清楚要什么，AI 帮你写成文档、画成页面。编程能力不是门槛，业务理解力才是。
系列文章导航
浙公网安备 33010602011771号