企业官网建设流程全解析

你有没有过这种经历？打开Claude Code，告诉它分析一份CSV反馈数据，按主题分类，统计频率，提取引文。它照做了，结果还不错。但下次你再做同样的事，又得重新说一遍。

说白了，你每次都在教它同样的流程。一次两次还行，做多了真的心累。

Skill这个东西就是来解决这个问题的。

什么是Skill？

Skill其实就是一个文件夹，里面装了一个叫SKILL.md的指令文件。你只需要把工作流程定义一次——输入什么、怎么处理、输出什么格式、质量标准是什么——下次你再说帮我分析反馈，Claude Code 会自动匹配到对应的Skill，直接按流程执行，不用你重新解释。

举个例子：第一次做反馈综合花了45分钟。但你把流程做成Skill之后，第二次只需要10分钟，第三次也是10分钟，第四次还是10分钟。每次省下的时间都是白赚的。

下面给你准备了5个现成的入门Skill，都是产品经理最常用到的场景。

五项必备Skill

每个Skill建好之后，每次调用能帮你省下20到40分钟。

Skill 1：反馈综合器

它能干什么？把客户给你的各种反馈（支持工单、NPS评分、调查数据）整理成有分类、有统计、有引用的报告。

什么时候用？

- 季度末做反馈审查，为路线图规划找方向

- 发布新功能后分析用户反应

- 给各种功能请求排优先级

- 跟老板汇报客户洞察的时候

怎么工作的？你把CSV或文本文件丢给这个Skill，它会自动分类、统计每类问题出现的次数、判断用户情绪，最后生成一份带证据的结构化报告。

SKILL.md 长这样：

--- name: feedback-synthesizer description: 将CSV或文本文件中的客户反馈综合成主题报告，包含频率分析和支持性引述。当用户提及反馈分析、客户洞察、NPS综合或支持工单主题时自动调用。 ---

# 反馈综合Skill ## 目的 分析非结构化的客户反馈，生成结构化主题报告，用于路线图规划和洞察综合。 ## 预期输入 - 包含反馈文本列的CSV文件（支持工单、NPS回复、调查数据） - 反馈项之间以空行分隔的纯文本文件 - 多个需要综合分析的反馈来源 ## 处理流程 1. 读取所有提供的反馈文件 2. 识别重复出现的主题（通常10-15个不同主题） 3. 统计每个主题的出现频率 4. 评估每个主题的情感倾向（正面/负面/中性/混合分布） 5. 提取代表性引述（每个主题3-5条） 6. 根据频率和严重程度语言对主题进行优先级排序 ## 输出格式 生成一份Markdown报告：`feedback/theme-report-[date].md` 结构： - **执行摘要**：按频率排序的前3个主题，按严重程度排序的前3个主题 - **详细主题**：每个主题一个章节，包含： - 主题名称和描述 - 频率计数和百分比 - 情感分布 - 代表性引述 - 建议行动或调查领域 - **交叉模式**：经常同时出现的主题 - **微弱信号**：值得关注的低频主题 ## 质量标准 - 除非被标记为关键，否则主题必须至少在5条反馈中出现 - 引述必须是实际逐字摘录，而非转述 - 频率计数必须准确 - 情感评估基于实际使用的语言，而非假设 - 报告长度控制在6页以内以保证可读性 ## 常见陷阱 - 不要创建过多主题，合并相似概念 - 不要偏向近期反馈，平等分析所有数据 - 没有文本证据时不要推断情感

可以自定义的地方：

- 主题出现多少次才算值得关注（默认5次）

- 用预设的分类还是让AI自动发现主题

- 要不要做情感分析

- 报告要多长

怎么用：直接说"分析 data/q1-2026-feedback.csv 中的反馈并创建一份主题报告"，Claude Code 会自动匹配Skill并执行。

Skill 2：竞争情报扫描器

它能干什么？把你的产品和竞争对手放在一块对比——功能、价格、市场定位。

什么时候用？

- 每季度更新一次竞争格局

- 看自己的产品和对手比缺了什么功能

- 调整定价策略的时候

- 做市场定位研究

怎么工作的？你告诉它对手的名字和要比什么，它会自动研究每个对手，做成对比表格，还会生成文档存档。

SKILL.md 长这样：

--- name: competitive-intel description: 生成结构化的竞争分析，比较产品在功能、定价和定位方面的差异。当用户提及竞争分析、竞争对手比较、市场格局或功能差距分析时自动调用。 ---

# 竞争情报扫描Skill ## 目的 为路线图规划和战略定位创建系统化的竞争分析报告。 ## 预期输入 - 竞争对手名称或URL列表 - 比较维度（功能、定价、定位、目标市场） - 需要更新的现有竞争文档（可选） ## 流程 1. 针对每个竞争对手，收集以下信息： - 核心功能与能力 - 定价模式与层级 - 目标市场与定位 - 相对于我方产品的优势与劣势 2. 创建跨竞争对手的比较矩阵 3. 识别功能差距（对方拥有而我方缺失的功能） 4. 识别差异化机会（我方拥有而对方缺失的功能） 5. 总结战略意义 ## 输出格式 在 `research/competitors/` 中生成Markdown文件： - 每个竞争对手生成 `competitor-[name]-profile.md`（详细档案） - `competitive-matrix-[date].md`（比较表格） - `competitive-summary-[date].md`（战略分析） 比较矩阵格式： - 行：功能类别或评估标准 - 列：竞争对手加上我方产品 - 单元格：✓（具备功能）、✗（缺失功能）、~（部分/有限）或描述文字 ## 质量标准 - 信息必须是最新的（检查来源日期） - 定价必须包含所有层级，而不仅仅是基础价格 - 功能比较必须对等（相同能力，而非仅名称相同） - 避免偏见，准确呈现竞争对手的优势 - 包含可验证的来源 ## 更新频率 每季度运行一次，或在以下情况触发： - 主要竞争对手发布重大产品 - 定价发生变化 - 战略定位需要调整

可以自定义的地方：

- 比什么（功能、价格、目标市场、用户体验）

- 追踪多少个对手

- 多久更新一次

- 输出格式（表格还是文章）

怎么用："更新竞争对手A、竞争对手B和竞争对手C的竞争分析，重点关注定价和企业级功能。"

Skill 3：发布说明生成器

它能干什么？根据Git提交记录和Jira工单，自动写发布说明，而且是用用户能看懂的语言。

什么时候用？

- 每月或每季度发版公告

- 新功能上线后通知用户

- 维护更新日志

- 写客户邮件

怎么工作的？你给个版本号或日期范围，它自动看Git提交记录，挑出跟用户有关的变更，分类整理，然后用产品语言写出来。

SKILL.md长这样：

--- name: release-notes description: 根据Git历史记录和Jira工单生成面向客户的发布说明，使用产品语言风格。当用户提及发布说明、更新日志、版本说明或功能公告时自动调用。 ---

# 发布说明生成器Skill ## 目的 为产品更新和功能发布创建一致且对客户友好的发布说明。 ## 预期输入 - 版本号或标签（例如 "v2.5.0" 或Git标签） - 日期范围（例如 "自上次发布以来的提交" 或 "2026年1月1日至31日"） - 可选的Jira筛选器或工单列表，用于提供额外上下文 ## 流程 1. 读取指定范围内的Git提交记录 2. 识别面向用户的变更（过滤掉内部重构、依赖更新） 3. 对变更进行分类： - **新增**：新功能或新能力 - **变更**：对现有功能的改进 - **修复**：错误修复 - **移除**：已弃用或移除的功能 4. 使用产品语言（而非技术术语）撰写描述 5. 将相关变更分组 6. 按用户影响排序（影响最大的优先） ## 输出格式 生成 `CHANGELOG.md` 条目或 `docs/releases/[version].md`： ## [版本 X.Y.Z] - 年-月-日 ### 新增 - [以用户语言描述的功能] ### 变更 - [改进描述] ### 修复 - [用通俗语言描述的错误修复] ### 移除 - [已弃用的功能，附迁移指南（如有需要）] ## 语言风格与语气 - **面向客户，而非技术性**："批量用户导入现在支持最多1,000个用户"，而非"增加了MAX_IMPORT_SIZE常量" - **以收益为导向**：解释用户现在可以做什么，而不仅仅是改变了什么 - **清晰简洁**：通常每个变更一句话 - **主动语态**："新增仪表盘自定义功能"，而非"仪表盘自定义功能已被添加" ## 质量标准 - 仅包含影响用户体验的变更 - 每个变更无需阅读提交信息即可理解 - 相关变更应分组列出，而非单独列出 - 已移除的功能应注明替代方案或迁移路径 - 版本号和日期必须准确 ## 常见模式 - 内部重构 → 排除，除非影响性能 - 依赖更新 → 排除，除非增加面向用户的能力 - 未发布功能中的错误修复 → 排除（与客户无关） - 破坏性变更 → 明确标出，并附迁移指南

可以自定义的地方：

- 语气风格（正式还是随意）

- 分类方式

- 输出形式（更新日志、邮件还是App内公告）

- 内部版本和对外版本分开

怎么用："根据自 v2.4.0 以来的提交记录，生成版本 2.5.0 的发布说明。"

Skill 4：PRD 审核员

它能干什么？拿着检查清单帮你审PRD文档，看有没有遗漏或前后矛盾的地方。

什么时候用？

- 启动开发前过一遍PRD

- 发给各方确认之前做检查

- 交给开发团队之前再看一眼

- 季度性的PRD质量检查

怎么工作的？你把PRD文件丢给它，它会检查该有的章节是不是都有，内容够不够清楚，有没有模糊的地方，最后给出一份带评分的审计报告。

SKILL.md 长这样：

--- name: prd-auditor description: 审查 PRD 文档的完整性、清晰度和一致性。当用户提及 PRD 审查、需求审计、PRD 检查清单或规格验证时自动调用。 ---

# PRD 审核员Skill ## 目的 在工程启动前系统性地审查 PRD 文档，确保其完整性。 ## 预期输入 - PRD Markdown 文件路径（例如 `docs/prds/feature-name.md`） - 可选的自定义检查清单或评分标准 ## 处理流程 1. 读取 PRD 文档 2. 检查必需章节： - 概述与成功指标 - 用户角色与使用场景 - 功能性与非功能性需求 - 用户体验/工作流程 - 技术方案 - 不涉及范围 - 待定问题 - 成功标准 3. 评估每个章节： - **完整性**：关键细节是否齐全？ - **清晰度**：是否无歧义？ - **具体性**：需求是否可测试/可衡量？ - **一致性**：各章节是否对齐（例如成功指标与需求匹配）？ 4. 标记问题： - 缺失章节 - 模糊或含混的需求 - 标记为"待定"的未解决待定问题 - 不可衡量的成功指标 - 缺少实现细节的技术方案 5. 对 PRD 就绪程度进行总体评分（就绪 / 需完善 / 不完整） ## 输出格式 在 PRD 中或单独文件中生成审计报告评论。 ## 评分方法 **就绪**：所有必需章节齐全且完整，严重问题少于 2 个 **需完善**：必需章节齐全但存在关键缺口（3-5 个严重问题） **不完整**：缺少必需章节或存在 6 个以上严重问题 ## 检查清单自定义 默认检查清单可通过在同一目录下包含 `PRD_CHECKLIST.md` 文件来覆盖，以定义自定义要求。

可以自定义的地方：

- 检查哪些章节（根据你们团队的PRD模板来）

- 评分标准

- 什么算严重问题

怎么用："审计位于 docs/prds/bulk-import.md 的 PRD，并告诉我缺少什么。"

Skill 5：用户故事扩展器

它能干什么？你给一个功能概念，它能结合代码库的实际情况，帮你扩展成完整的用户故事，连验收标准和边界情况都写好。

什么时候用？

- 冲刺规划前准备用户故事

- 把大功能拆成小任务

- 界定功能范围

- 交给开发团队之前

怎么工作的？你告诉它"我想做一个XX功能"以及目标用户是谁，它会去代码库里看看现有的模式和限制，然后按你们团队的格式写出用户故事。

SKILL.md 长这样：

--- name: user-story-expander description: 将功能概念扩展为包含验收标准、技术说明和边界情况的详细用户故事。当用户提及用户故事、故事扩展、验收标准或史诗拆解时自动调用。 ---

# 用户故事扩展器Skill ## 目的 基于代码库上下文和技术约束，为功能生成全面的用户故事。 ## 预期输入 - 功能描述（2-3句话说明要构建什么） - 目标用户角色或用户类型 - 功能必须支持的核心工作流 - 可选：要追加到的现有用户故事文件 ## 处理流程 1. 探索代码库以获取技术上下文： - 与该功能区域相关的现有模式 - 验证规则和约束条件 - 可参考的类似功能 - 潜在的集成点 2. 生成5-8个用户故事，涵盖： - 核心正常路径工作流 - 变体（不同用户类型、场景） - 错误处理和边界情况 - 管理/配置需求（如适用） 3. 每个故事包含： - 用户故事陈述（作为X，我想要Y，以便Z） - 验收标准（具体、可测试） - 技术说明（受影响的文件/模块、要遵循的模式） - 边界情况（边界条件、错误状态） 4. 按用户价值对故事进行优先级排序 ## 输出格式 生成或追加到 `docs/user-stories/[feature-name].md` ## 质量标准 - 故事必须以用户为中心（而非以实现为中心） - 验收标准必须可测试（而非模糊） - 技术说明必须引用代码库中的实际文件 - 边界情况必须基于代码库约束切实可行 - 覆盖率：典型场景的80%（并非每个可能的边界情况） ## 故事格式 使用标准的"作为/我想要/以便"格式，除非团队有自定义模板。

可以自定义的地方：

- 故事格式（如果团队有自定义模板）

- 生成多少条故事

- 技术细节写到多深

- 要不要包含工作量估算

怎么用："将批量用户导入功能扩展为企业管理员角色的用户故事。"

这5个Skill就是你的入门工具包。花一次时间建好，以后每次遇到同样的工作，直接用就完了。

每个Skill都能把原来30到60分钟的手工活，压缩到10分钟内自动搞定，而且输出的质量是稳定的——不会这次写成这样、下次又写成那样。