企业官网建设流程全解析

knowledge-work-plugins 的 create-an-asset 技能拆解：从交易上下文到客户级销售物料的自动化生成方案

【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins

本指南以 create-an-asset 技能定义 为绝对主体，完整还原其在 knowledge-work-plugins 开源仓库 sales 插件中的设计与实现：如何通过“客户、受众、目标、格式”四维上下文收集，配合自适应调研、内容生成、视觉设计与交付迭代，最终产出自包含的 HTML 销售物料（交互式落地页、演示 Deck、一页纸、工作流演示）。读完本文，你将掌握该技能从 Phase 0 到 Phase 7 的完整执行链路、四类物料的内部结构规范、设计令牌与组件样式体系，以及如何将其接入 sales 插件的 MCP 连接器生态（详见 sales/CONNECTORS.md）。

一、技能定位：sales 插件里的“物料生产车间”

在 knowledge-work-plugins 仓库中，sales 插件 覆盖了客户研究、通话准备、渠道外联、管线评审、竞品情报等完整销售工作流。其中create-an-asset是唯一一个面向“客户可见交付物”的技能：它的触发词是/create-an-asset或/create-an-asset [CompanyName]，当用户说出“create an asset”“build a demo”“make a landing page”“mock up a workflow”等意图时自动激活（见 SKILL.md 的 Triggers 小节）。

与同一插件中的其他技能形成互补：competitive-intelligence技能在生成“针对具体交易的对比页”时也会引用create-an-asset作为下游动作（见 competitive-intelligence/SKILL.md），说明该技能被设计为销售流程中“产出最终交付物”的一环。

安装该技能随 sales 插件分发，两种方式：

# 方式一：直接添加 sales 插件（sales/README.md 的安装方式） claude plugins add knowledge-work-plugins/sales # 方式二：从插件市场安装（根 README.md 的方式） claude plugin marketplace add anthropics/knowledge-work-plugins claude plugin install sales@knowledge-work-plugins

安装后技能自动生效：Claude 在相关场景下自动调用其知识，无需手动加载。技能本身是纯 Markdown 指令文件，无代码、无构建步骤——这正是整个 knowledge-work-plugins 仓库“file-based plugin”的设计哲学（见 根 README.md）。

二、核心输入模型：Prospect / Audience / Purpose / Format 四维上下文

技能的开篇明确了它收集的四类上下文，这是整个生成流程的输入骨架（SKILL.md Overview）：

这四个维度并不是一次性收集完，而是被拆解到 Phase 0 的六个步骤中逐步获取，并伴随一套“必填/选填”校验，保证信息最小可用集（MVP）完整。

三、Phase 0：上下文检测与输入收集

3.1 卖家上下文检测（Step 0.1）

技能先从用户的邮箱域名推断其所在公司：

1. 从用户邮箱提取域名；
2. 执行搜索"[domain]" company products services site:linkedin.com OR site:crunchbase.com；
3. 根据公司类型分支处理：

收集结果以 YAML 结构存储（SKILL.md Step 0.1）：

seller: company: "[Company Name]" product: "[Product/Service]" value_props: - "[Key value prop 1]" - "[Key value prop 2]" - "[Key value prop 3]" differentiators: - "[Differentiator 1]" - "[Differentiator 2]" pricing_model: "[If publicly known]"

该上下文会持久化到知识库供后续会话复用；再次调用时先确认：“I have your seller context from last time — still selling [Product] at [Company]?”这保证了同一销售人员的跨会话一致性，避免每次重新交代卖点。

3.2 客户上下文（Step 0.2）

交易阶段的可选项：Intro / First meeting、Discovery、Evaluation / Technical review、POC / Pilot、Negotiation、Close。交易阶段会直接影响后续 Phase 2 的结构选择——例如 POC 阶段的资产应突出“范围、成功标准、时间线”，而 Close 阶段的资产应突出“价值总结、定价、条款”。

3.3 受众上下文（Step 0.3）

受众类型四选一：Executive（C-suite、VP）、Technical（架构师、工程师、开发者）、Operations（运维、IT、采购）、Mixed / Cross-functional。

“Primary concern”五选一：ROI / Business impact、Technical depth / Architecture、Strategic alignment、Risk mitigation / Security、Implementation / Timeline。

受众和关注点决定了内容叙事的主次顺序（见第四节“受众调整”），这是技能“以客户为中心”的落地机制。

3.4 目的上下文（Step 0.4）

Goal 选项：Intro / First impression、Discovery follow-up、Technical deep-dive、Executive alignment / Business case、POC proposal、Deal close。同时必须明确 Desired action——查看者看完后应当做什么。后者将直接映射到最终物料中的 CTA（行动召唤）。

3.5 格式选择（Step 0.5）

3.6 工作流演示的专项输入（Step 0.6）

当选择“Workflow / Architecture demo”时，技能先尝试从用户描述中自行解析：涉及的系统与组件、描述的数据流、人工交互点、示例场景；解析出缺口后再定向补问（SKILL.md Step 0.6）：

这一“先解析、后补问”的策略与技能 Phase 1 的“自适应调研”一脉相承——能少问就少问，只在信息缺口处提问。

四、Phase 1：自适应调研（Adaptive Research）

技能根据上下文丰富度决定调研深度（SKILL.md Phase 1）：

任何情况下都要做的基础调研：

1. 客户基本面："[Company]" annual report investor presentation 2025 2026，提取营收、员工数、关键指标、战略重点；
2. 领导层："[Company]" CEO CTO CIO 2025，提取姓名、职位、近期关于战略/技术的引述；
3. 品牌色："[Company]" brand guidelines或从官网提取主色、辅色、强调色。

Moderate/Sparse 时追加：

4. 行业背景（趋势、挑战、普遍痛点）；
5. 技术栈（现有方案、潜在集成点）；
6. 竞争背景（切换信号、现有方案）。

已上传转录稿时追加：

7. 对话分析：提取已陈述的痛点、决策标准、异议、时间线；识别可引用的关键原话（使用他们的原话）；记录特定术语、缩写、内部项目名。

这里的核心原则是：调研服务于“定制感”。后文 Phase 3 的内容模板会反复引用这些调研产物（客户指标、原话、行业趋势）。

五、Phase 2：结构决策（Structure Decision）

5.1 交互式落地页：按 Purpose 选结构

同一份落地页，不同的交易阶段采用不同的推荐栏目组合（SKILL.md）：

受众调整原则：Executive 受众先讲商业影响与 ROI；Technical 受众先讲架构、安全、集成深度；Operations 受众先讲工作流影响、变更管理、支持；Mixed 受众用标签页（tabs）平衡战略与战术两个深度层级——这正是落地页多标签结构的设计初衷。

5.2 Deck 风格

与落地页栏目一致，但排版为线性幻灯片：

1. Title slide（客户 + 卖家 Logo，伙伴关系框架） 2. Agenda 3-N. 每个栏目一页（密集栏目 2-3 页） N+1. 总结 / 关键 takeaways N+2. 下一步 / CTA N+3. 附录（可选——详细规格、定价等）

幻灯片原则：每页一个核心信息、视觉优先于文字、使用客户自身的指标和语言、包含演讲者备注（speaker notes）。

5.3 一页纸

单页滚动布局，结构固定为 HERO → 三大要点 → 证明点 → CTA（原文给出了完整的 ASCII 线框示意图，见 SKILL.md）：

┌─────────────────────────────────────┐ │ HERO: "[Prospect Goal] with [Product]" │ ├─────────────────────────────────────┤ │ KEY POINT 1 │ KEY POINT 2 │ KEY POINT 3 │ │ [Icon + 2-3 │ [Icon + 2-3 │ [Icon + 2-3 │ │ sentences] │ sentences] │ sentences] │ ├─────────────────────────────────────┤ │ PROOF POINT: [Metric, quote, or case study] │ ├─────────────────────────────────────┤ │ CTA: [Clear next action] │ [Contact info] │ └─────────────────────────────────────┘

5.4 工作流 / 架构演示：按复杂度分档

标准元素共 7 项：标题栏（[Scenario Name] — Powered by [Seller Product]）、组件节点、动画流转箭头、步骤侧栏（通俗语言解释当前步骤）、控制条（Play / Pause / Step Forward / Step Back / Reset）、决策点标注、每步的数据预览（示例载荷或转换结果）。

六、Phase 3：内容生成

6.1 通用原则

所有内容必须：引用用户输入或转录稿中的具体痛点；使用客户的语言（他们的术语、他们陈述的优先事项）；显式地把卖家产品映射到客户需求；在可获得时给出证明点（案例、指标、引述）；做到“定制感而非模板感”。

6.2 栏目模板（Section Templates）

技能为每个栏目给出了可复制的生成模板，这里按原文完整列出核心几项：

Hero / Intro

Headline: "[Prospect's Goal] with [Seller's Product]" Subhead: 关联他们已陈述的优先事项或头号行业挑战 Metrics: 3-4 条客户关键事实（证明我们做了功课）

Their Priorities（Discovery follow-up 时）

引用对话中的具体痛点： - 尽量使用他们的原话 - 展示我们倾听并理解了 - 把每一条与我们的帮助方式建立连接

Solution Mapping（痛点 → 方案映射）

针对每个痛点： ├── 挑战（用他们的话说） ├── [Product] 如何应对 ├── 证明点或示例 └── 结果 / 收益

Use Cases / Demos

3-5 个相关用例： ├── 视觉 mockup 或交互式演示 ├── 商业影响（尽可能量化） ├── "How it works" — 3-4 步总结 └── 与其行业/角色的相关性

ROI / Business Case（交互式计算器）

输入（来自调研、贴合客户业务）： │ ├── 用户/开发者数量 │ ├── 当前成本或耗时 │ └── 预期改进百分比 输出： │ ├── 年度价值 / 节省 │ ├── 解决方案成本 │ ├── 净 ROI │ └── 回本周期 └── 假设必须明确列出（且可编辑）

Why Us / Differentiators

├── 相对他们可能考虑的替代方案的差异化 ├── 信任、安全、合规定位 ├── 支持与伙伴关系模式 └── 客户证明点（Logo、引述、案例）

Next Steps / CTA

├── 与 Purpose (c) 对齐的清晰动作 ├── 具体的下一步（而非含糊的 "let's chat"） ├── 联系方式 ├── 建议时间线 └── 他们行动后会发生的后续

6.3 工作流演示的内容定义（YAML Schema）

工作流演示的核心资产是组件定义与流程步骤的结构化描述，原文提供了可直接复用的 YAML 模板：

组件定义（SKILL.md）：

component: id: "snowflake" label: "Snowflake Data Warehouse" type: "database" # database | api | ai | middleware | human | document | output icon: "database" description: "Financial performance data" brand_color: "#29B5E8"

组件类型共 7 种：human（发起或接收的人）、document（PDF、合同、文件）、ai（AI/ML 模型、智能体）、database（数据存储、仓库）、api（API、服务）、middleware（集成平台、MCP 服务器）、output（仪表盘、报告、通知）。

流程步骤定义（SKILL.md）：

step: number: 1 from: "human" to: "claude" action: "Initiates performance review" description: "Sarah, a Brand Analyst at [Prospect], kicks off the quarterly review..." data_example: "Review request: Nike brand, Q4 2025" duration: "~1 second" value_note: "No manual data gathering required"

注意duration与value_note字段：前者让观众感知每个步骤的速度，后者在每个步骤标注“价值点”，把技术流转翻译成业务价值——这是工作流演示“既技术又打动高管”的关键设计。

场景叙事：技能要求写一段清晰具体的 walkthrough。原文的示例是完整的 5 步叙事（Human Trigger → Contract Analysis → Data Query → Results & Synthesis → Insight Delivery），其中展示了一个关键技巧：在结果综合步骤使用 ✓/⚠️ 标记呈现“实际值 vs 义务值”的对比，如“Revenue $52.3M ✓ (exceeded by $2.3M) / Margin 11.2% ⚠️ (0.8% below threshold)”，并让 AI 代理给出可执行建议（“Review promotional spend allocation...”）。这种“演示 + 洞察”的写法让 POC 场景不流于炫技，而是直接指向业务结论。

七、Phase 4：视觉设计（Visual Design）

7.1 色彩系统：CSS 变量令牌

技能规定了一套以客户品牌色为主色、深色主题为基调的 CSS 变量体系（SKILL.md）：

:root { /* === Prospect Brand (Primary) === */ --brand-primary: #[extracted from research]; --brand-secondary: #[extracted]; --brand-primary-rgb: [r, g, b]; /* For rgba() usage */ /* === Dark Theme Base === */ --bg-primary: #0a0d14; --bg-elevated: #0f131c; --bg-surface: #161b28; --bg-hover: #1e2536; /* === Text === */ --text-primary: #ffffff; --text-secondary: rgba(255, 255, 255, 0.7); --text-muted: rgba(255, 255, 255, 0.5); /* === Accent === */ --accent: var(--brand-primary); --accent-hover: var(--brand-secondary); --accent-glow: rgba(var(--brand-primary-rgb), 0.3); /* === Status === */ --success: #10b981; --warning: #f59e0b; --error: #ef4444; }

这套令牌的设计要点：把“客户品牌色”抽象为唯一输入（--brand-primary/--brand-secondary），其余全部派生自它——后续迭代时只需换两个变量即可整体换肤（对应 Phase 7 的 “Use our brand instead” 迭代）。--brand-primary-rgb单独存 RGB 分量是为了支持rgba()半透明用法（如光晕--accent-glow）。

7.2 字体排印

主字体'Inter', -apple-system, BlinkMacSystemFont, sans-serif；层级：h1 2.5rem/700、h2 1.75rem/600、h3 1.25rem/600、body 1rem/400/1.6、small 0.875rem/500。

7.3 视觉元素规范

• 卡片：背景var(--bg-surface)、1px 白 10% 边框、12px 圆角、柔和分层阴影、悬停轻微抬升 + 边框辉光；
• 按钮：主按钮var(--accent)背景 + 白字；次按钮透明 + accent 边框；悬停提亮 + 轻微缩放；
• 动画：过渡 200-300ms ease、标签切换 fade+slide、悬停平滑、加载用细微 pulse 或骨架屏。

7.4 工作流演示专属样式

组件节点、流转箭头、画布的样式规范原文均给出了可直接落地的 CSS（SKILL.md Phase 4 后半段），关键设计包括：

• .node.active使用--accent-glow光晕 + accent 边框标记当前激活节点；
• .node.human用暖色#f59e0b边框区分“人”节点，与 AI/数据库节点形成视觉语义区分；
• .node.ai使用从 surface 到 elevated 的渐变背景；
• .arrow.active使用stroke-dasharray: 8 4+flowDash 1s linear infinite动画实现数据流动画，激活前为静默的 muted 灰色箭头；
• 画布使用 radial-gradient 暗色背景 + 内嵌 SVG 网格图案，overflow: auto支持缩放漫游。

八、Phase 5：必做的澄清问题（REQUIRED）

技能特别强调：在构建任何资产前，必须先问澄清问题，以对齐预期、避免返工。流程分四步：

Step 5.1 先总结理解——向用户展示你打算构建什么：

"Here's what I'm planning to build: **Asset**: [Format] for [Prospect Company] **Audience**: [Audience type] — specifically [roles if known] **Goal**: [Purpose] → driving toward [desired action] **Key themes**: [2-3 main points to emphasize] [工作流演示时追加:] **Components**: [List of systems] **Flow**: [Step 1] → [Step 2] → [Step 3] → ...

Step 5.2 通用问题（所有格式）：

Step 5.3 格式专项问题——例如落地页问“哪些栏目对这个受众最重要？”“要不要 ROI 计算器？”；Deck 问“演示时长？现场讲还是会后留档？”；一页纸问“最重要的单一信息是什么？打印还是数字？”；工作流演示问“组件/流程确认”“展示真实示例数据还是抽象？”“点击逐步浏览还是自动播放？”

Step 5.4 确认并继续——用户答复后回复 “Got it. I have what I need. Building your [format] now...”，仍不清楚则再补一问。问题轮次上限为 2 轮，仍含糊就做合理选择并注明：“I went with X — easy to adjust if you prefer Y.”——这是把“无限追问”约束为“可交付优先”的关键工程化设计。

九、Phase 6：构建与交付（Build & Deliver）

9.1 构建步骤

1. 按 Phase 2 生成结构；
2. 按 Phase 3 创建内容；
3. 按 Phase 4 应用视觉设计；
4. 确保所有交互元素可用；
5. 测试响应式（如适用）。

9.2 输出格式规范

所有格式统一输出为自包含 HTML 文件：

• 所有 CSS 内联或在<style>标签内；
• 所有 JS 内联或在<script>标签内；
• 无外部依赖（Google Fonts 除外）；
• 单文件便于共享。

文件命名规范：[ProspectName]-[format]-[date].html，示例：CentricBrands-workflow-demo-2026-01-28.html。

这一“零外部依赖单文件”设计是整套交付策略的基础：它可以被静态托管、被直接邮件发送（离线可用）、被 iframe 嵌入，几乎不存在部署摩擦——对应 sales/README.md 中“Standalone + Supercharged”的理念，即脱离任何集成也能完成端到端交付。

9.3 交付消息模板

技能规定交付时必须附带结构化消息，包含：资产摘要（格式、受众、目的、栏目/步骤数）、部署选项（Netlify/Vercel/GitHub Pages/AWS S3 等静态托管、密码保护、直接发送文件、iframe 嵌入）、以及定制选项清单（改色、增删栏目、精炼文案、改流程、加交互、导出 PDF/静态图）。

十、Phase 7：迭代支持

交付后技能准备响应常见迭代请求（SKILL.md Phase 7）：

默认规则：初始构建默认使用客户品牌色，但卖家可在首版后切换到自有品牌或中性调色板。这与 Phase 0 的卖家上下文持久化、Phase 4 的令牌化色彩体系三者联动，使“换肤”成为 O(1) 操作。

十一、交付前质量清单（Quality Checklist）

技能要求交付前逐项核验四组检查项（SKILL.md）：

• 内容：客户公司名拼写全篇一致；领导层姓名为最新；痛点准确反映输入/转录稿；卖家产品描述准确；无占位文本残留；证明点准确且有来源；
• 视觉：品牌色应用正确；文本对比度可读；动画平滑不分散；移动端响应式；深色主题观感精致；
• 功能：标签/栏目正常加载；交互元素可用（计算器、演示）；工作流步骤动画正常；导航直观；CTA 清晰可点；
• 专业度：语气匹配受众；详细度匹配目的；无错别字语法错误；有定制感而非模板感。

这组清单既是交付前的自检工具，也是 Agent 在生成过程中保持质量约束的“验收标准”，与仓库中其他技能（如account-research、competitive-intelligence）追求的可验证、可审计工作流一脉相承。

十二、完整示例与附录资源

12.1 三个端到端示例

示例 1：高管落地页——客户 Acme Corp（制造业）、受众 C-suite、目的为 discovery 后的高管对齐。输出为多标签页：Strategic Fit | Business Impact | ROI Calculator | Security & Trust | Next Steps，其中 Strategic Fit 标签引用发现通话中的客户陈述优先事项，并列出制造业相关客户案例。

示例 2：技术工作流演示——客户 Centric Brands、受众 IT 架构师、目的 POC 提案、组件为 Claude / Workato DataGenie / Snowflake / PDF 合同。输出为 5 节点交互画布（Human → Claude → PDF Contracts → Workato → Snowflake，结果回流至 Human），配套逐步讲解与示例数据，控制条为 Play / Pause / Step / Reset。

示例 3：销售一页纸——客户 TechStart Inc、受众 VP Engineering、目的首会后留档。结构：Hero（“Accelerate TechStart's Product Velocity”）→ 三个要点（开发者生产力 / 代码质量 / 上市时间）→ 证明点（“Similar companies saw 40% faster releases”）→ CTA（“Schedule technical deep-dive”）。

12.2 附录一：组件图标映射

12.3 附录二：品牌色兜底方案

当无法提取客户品牌色时，按行业使用兜底调色板（SKILL.md）：Technology#2563eb/#7c3aed、Finance#0f172a/#3b82f6、Healthcare#0891b2/#06b6d4、Manufacturing#ea580c/#f97316、Retail#db2777/#ec4899、Energy#16a34a/#22c55e、Default#3b82f6/#8b5cf6。结合 Phase 1 的“品牌色优先从官网/指南提取”，这一附录确保了弱调研场景下仍有专业的视觉下限。

十三、配套使用：技能与连接器的协同

create-an-asset 与 sales 插件的连接器生态协同工作（sales/CONNECTORS.md）：CRM 连接器（HubSpot、Close 等）提供管线数据与联系人记录；会话情报（Fireflies、Gong）提供转录稿——这正是 Phase 1 中“Rich context”与“对话分析”的数据来源；数据富化（Clay、ZoomInfo）支撑客户研究；而工作流演示中提到的 MCP Server 本身即属于middleware组件类型。整个插件遵循“工具无关”设计——工作流用~~CRM之类的类别占位符描述，任何同类别 MCP 服务器均可接入，因此该技能不绑定任何具体 SaaS 产品。

配套的 QUICKREF.md 提供了速查入口（三种调用方式、四维输入速览、格式选择器、常用迭代话术），适合放在日常会话中做快速参考；README.md 则面向使用者提供快速上手、FAQ 与最佳实践提示（提供丰富上下文、上传转录稿、具体化受众、自由迭代）。

结语

从 Phase 0 的上下文检测到 Phase 7 的迭代支持，create-an-asset 呈现了一条完整的“销售物料自动化生产线”：四维输入模型保证信息完备，自适应调研控制成本，按目的/受众分化的结构决策保证相关性，YAML 化的组件与步骤定义让工作流演示可编程、可复用，令牌化 CSS 设计系统把换肤成本降到最低，而两轮澄清 + 质量清单则守住“定制感”的底线。对希望在自己团队中复刻这套流程的开发者而言，SKILL.md 本身就是一份可直接迁移的规格说明书——它不依赖任何私有服务，任何一个销售团队都能把它改造成自己的“物料车间”。

【免费下载链接】knowledge-work-pluginsOpen source repository of plugins primarily intended for knowledge workers to use in Claude Cowork项目地址: https://gitcode.com/GitHub_Trending/kn/knowledge-work-plugins