Shipwright：AI驱动的产品经理操作系统，从提示词到质量系统

1. 项目概述：为产品经理打造的AI驱动操作系统

如果你是一名产品经理，每天的工作流是否经常在文档、会议、即时通讯工具和项目管理软件之间反复横跳？你是否曾希望有一个统一的“操作系统”，能将市场发现、需求撰写、战略规划和发布执行这些离散的任务串联起来，并且每一步都有质量保证？Shipwright正是为了解决这个痛点而生。它不是一个简单的提示词集合，而是一个由46个技能、7个智能体、17个链式工作流和一个决策分析系统构成的完整框架，旨在将AI从“一个聪明的聊天伙伴”升级为“一个遵循严格流程的协作同事”。其核心哲学是“证据优先、决策明确、质量门控”，确保产出的每一份PRD、战略文档或发布计划，都不仅仅是看起来不错，而是经得起推敲、团队可以立即执行的可靠工件。

我最初接触Shipwright时，以为它只是另一个Claude Code的插件库。但深入使用后发现，它的设计理念截然不同。大多数AI工具追求的是“一次生成尽可能多的内容”，而Shipwright追求的是“在正确的流程节点，生成结构正确、证据充分、决策清晰的内容”。这就像从“手工作坊”升级到了“精实生产线”，每个环节都有检查点和标准。对于需要处理高复杂度、高不确定性产品决策的PM来说，这种系统性的约束不是限制，而是解放——它让你能把认知精力集中在真正的战略判断上，而不是反复纠结文档格式或论证逻辑是否严密。

2. 核心设计哲学：从“更好的提示”到“质量系统”

许多团队尝试用AI辅助产品工作时，容易陷入一个误区：不断优化提示词，希望模型能一次性吐出完美的PRD。但结果往往是格式飘忽不定、论据混杂假设、建议模棱两可。Shipwright的创始人EdgeCaser显然洞察到了这一点，因此构建了一套围绕提示词的质量控制系统。这套系统的价值，通过下表可以清晰地与传统“裸奔式”AI提示进行对比：

这种设计带来的最大改变是工作模式的转变。你不再是与一个“黑盒”对话，而是运行一个由智能体担任不同角色（如研究员、策略师、红队评审员）的确定性流程。你的角色从“撰稿人”变成了“主编”和“最终决策者”，智能体负责提供结构化的论据和选项，而你负责做出基于这些高质量输入的战略判断。

3. 核心组件深度解析：技能、工作流与智能体

要真正用好Shipwright，不能只停留在运行几个命令，需要理解其内部三个核心组件是如何协同工作的。这有助于你在遇到问题时进行调试，也能让你更灵活地定制自己的工作流。

3.1 技能：原子化的能力单元

技能是Shipwright的基石，位于skills/目录下。每个技能都是一个独立的Markdown文件，描述了一个具体的、可重复的产品工作方法或框架。例如，skills/discovery/customer-interview-analysis.SKILL.md可能封装了如何从用户访谈记录中提取洞察、归类痛点的标准化流程。

关键特性与使用心得：

• 纯文本、工具无关：技能文件是普通的Markdown，这意味着它们可以被任何能读取文本的AI编码工具（如Cursor、Codex、Gemini CLI）使用。这保证了Shipwright核心方法论的可移植性。
• 结构化输入输出：每个技能都明确定义了输入要求（如“需要用户访谈原始记录”）和输出格式（如“包含痛点矩阵、引用频率统计的洞察报告”）。这种契约关系是工作流能够自动串联的前提。
• 可组合性：一个复杂的工作流（如/discover）背后，可能是由“市场分析”、“竞品格局”、“用户访谈分析”等多个技能按顺序组合而成。你可以像搭积木一样，用现有技能构建自定义流程。
• 实操注意：当你需要扩展Shipwright的能力时，最直接的方式不是修改现有工作流，而是编写新的技能。确保新技能遵循现有的 输出标准 ，并为其设计清晰的通过/失败门控条件，这样才能无缝集成到现有的质量体系中。

3.2 工作流：预设的任务执行链

工作流位于commands/目录，是预先定义好的一系列技能执行序列。你可以通过Claude Code中的斜杠命令（如/write-prd）直接调用。Shipwright内置了17个工作流，覆盖了从发现到发布的完整产品生命周期。

三类核心路径解析：项目README中提到的三条路径，实际上是三个最常用的高阶工作流组合：

1. 新功能路径 (/discover → /write-prd → /tech-handoff): 这是最经典的“从0到1”流程。/discover工作流会调用多个研究技能，生成证据包；/write-prd基于此生成结构化的PRD；/tech-handoff则将PRD转化为技术规格、设计评审要点和用户故事。我的经验是，不要在同一个会话中跑完整个链条。最好在每个阶段结束后，人工审核输出，特别是/discover的证据报告，确保输入质量，这样后续环节的产出才会更可靠。
2. 季度规划路径 (/customer-review → /strategy → /okrs): 这个路径的关键在于“输入信号的梳理”和“战略边界的设定”。/customer-review会汇总近期的客户反馈、支持工单、使用数据；/strategy则基于这些输入，帮助你形成几个清晰的战略押注，并明确“不做哪些事”的淘汰标准；最后/okrs生成与战略押注对齐的OKR草案，并自动进行一致性审计。这里常见的坑是，如果/customer-review输入的信号过于庞杂或矛盾，/strategy的输出可能会变得模糊。建议先人工对客户信号进行初步归类和高低优先级标注，再交给工作流处理。
3. 发布路径 (/strategy → /plan-launch → /sprint): 这个路径侧重于“对齐”和“拆解”。/strategy确保所有相关方对发布的核心价值和定位达成一致；/plan-launch产出包含市场沟通、销售赋能、客户成功准备的完整GTM计划；/sprint则将GTM计划中的行动项转化为开发团队可执行的冲刺任务。一个重要技巧：在运行/plan-launch前，确保你的CLAUDE.md文件中已经更新了最新的产品定位和关键信息，这样生成的营销材料才会准确。

3.3 智能体：执行流程的“角色”

智能体是工作流的执行引擎，位于agents/目录。Shipwright设计了7个智能体：1个协调者（Orchestrator）和6个专家（如研究员、策略师、红队评审员等）。当你运行/shipwright时，协调者智能体会首先介入，分析你的上下文（来自CLAUDE.md）和请求，然后将任务路由给最合适的专家智能体和工作流。

智能体协同机制剖析：这种设计模仿了真实的团队协作。例如，当你运行/challenge对一个PRD进行评审时，协调者不会让生成这个PRD的“策略师”智能体自己评审自己，而是会将任务派给独立的“红队评审员”智能体。这个红队智能体拥有不同的“思维”提示和检查清单，专门负责挑刺和压力测试。这种“对抗性”设计是产出高质量、抗脆弱文档的关键。

与外部工具的连接：智能体不仅可以使用内部技能，还能通过MCP（Model Context Protocol）连接外部工具。例如，研究员智能体可以配置为连接网络搜索工具（如Tavily）、数据库或内部Wiki，以便在运行/discover时自动获取最新的市场数据或内部文档。这部分配置在 工具连接指南 中有详细说明。我的建议是，优先配置一个可靠的网络搜索MCP服务器，这能极大提升/discover和/competitive等工作流输出证据的时效性和准确性。

4. 完整实操指南：从安装到产出第一份PRD

理解了核心组件后，我们来看如何从零开始，使用Shipwright完成一次完整的产品需求定义。我将以最常用的“新功能路径”为例，展示每个步骤的详细操作、可能遇到的问题及解决方案。

4.1 环境准备与安装

首先，你需要一个支持Claude Code的编辑器（如Cursor或VS Code + Claude扩展）。安装Shipwright有三种方式，我强烈推荐选项A（插件安装），因为它最省心，且便于后续更新。

# 选项A：通过Claude插件市场安装（最简单） claude plugin marketplace add EdgeCaser/shipwright claude plugin install shipwright@shipwright

安装完成后，在你的项目根目录打开Claude Code，输入/shipwright-help，如果能看到命令菜单，说明安装成功。

如果插件安装失败或你的环境无法访问插件市场，则采用选项B（脚本安装）：

# 选项B：脚本安装（适合需要手动控制或离线环境） git clone https://github.com/EdgeCaser/shipwright.git # 将 --install 参数后的路径替换为你的项目实际路径 bash shipwright/scripts/sync.sh --install /path/to/your-project/

这个脚本会将Shipwright的所有文件复制到你项目下的.claude/目录中，并生成一个shipwright-sync.sh脚本用于后续更新。务必注意：确保目标路径是你的项目根目录，这样CLAUDE.md上下文文件才能被正确识别。

4.2 配置产品上下文 (CLAUDE.md)

安装完成后，最重要的一步是配置CLAUDE.md文件。这个文件是你的产品“身份证”，它告诉Shipwright智能体你的产品名称、核心用户、关键指标和当前优先级。没有它，Shipwright虽然能工作，但输出会是通用模板，缺乏针对性。

# 从示例文件复制并创建你的CLAUDE.md cp shipwright/examples/CLAUDE.md.example ./CLAUDE.md

然后，用文本编辑器打开CLAUDE.md，填充关键信息。不必追求完美，但越详细越好。以下是一个电商平台的示例片段：

## 产品名称 “购直达” - 一个面向中小商家的SaaS电商建站平台。 ## 核心用户画像 1. 小王（店主型）：25-40岁，有实体店或货源，技术能力弱，希望快速上线网店，核心诉求是简单、省心。 2. 小李（运营型）：22-35岁，可能是个体创业者或小团队运营，熟悉社交媒体，追求营销玩法和转化率，核心诉求是流量和工具。 ## 关键成功指标 (KSMs) - 月活跃商家数 (MAU) - 商家平均GMV - 功能使用率（如促销工具、数据分析面板） - 客户支持满意度 (CSAT) ## 当前战略重点 (Q2) 1. 提升新商家上手成功率（当前仅30%在14天内发布第一个商品）。 2. 增加高价值商家（年GMV超50万）的留存率。 3. 探索“跨境商品一键上架”功能的市场需求。

填写心得：即使你对某些指标（如“高价值商家”的定义）不确定，也可以先写一个假设。Shipwright会在输出中标记这些为“未知项”，这反而能促使你在后续研究中澄清它们。CLAUDE.md是一个动态文档，应随着产品演进不断更新。

4.3 执行发现阶段 (/discover)

假设我们想探索“跨境商品一键上架”这个功能点子。在项目根目录打开Claude Code，输入：

/shipwright 我是“购直达”的PM，我们想探索为中小商家增加“跨境商品一键上架”功能的可能性，请帮我启动发现流程。

协调者智能体会读取你的CLAUDE.md，识别出这是关于“新功能”的探索，并自动路由到/discover工作流。它会开始提问以明确范围，例如：

• “一键上架”具体想解决商家在跨境上架中的哪些痛点？（如：多国海关编码、多语言翻译、国际物流模板）
• 目标商家是已有跨境业务的，还是从未尝试过跨境的新手？
• 是否有初步的竞品参考？

你需要清晰、简洁地回答这些问题，这相当于给AI研究员下达了清晰的调研简报。之后，研究员智能体会开始工作，它可能会：

1. 调用网络搜索技能，查找关于中小商家跨境电商痛点的行业报告、论坛讨论。
2. 调用竞品分析技能，调研现有跨境电商SaaS平台（如Shopify跨境模块、Shoplazza等）的解决方案和定价。
3. 尝试分析你提供的任何内部数据（如客服工单中关于“跨境”的关键词）。

大约几分钟后，你会得到一份发现报告。请务必仔细审查这份报告，重点关注其“证据”部分：每个关于市场规模、用户痛点、竞品功能的陈述是否都附上了来源链接或数据引用？报告末尾的“未知项与证据缺口”是否列出了你关心但未找到答案的问题（如“目标商家愿意为此功能支付多少溢价？”）？这是后续环节的输入基础，其质量直接决定最终PRD的可靠性。

4.4 撰写PRD (/write-prd)

在审核并通过发现报告后，你可以直接在同一会话或新会话中运行：

/write-prd

智能体会自动将上一阶段生成的发现报告作为输入，开始撰写PRD。它会遵循严格的PRD技能模板，产出包含以下核心章节的文档：

• 背景与目标：基于发现报告，阐述为什么要做这个功能。
• 成功指标：定义如何衡量该功能是否成功（如：上线后3个月内，有X%的活跃商家使用该功能，带动跨境GMV增长Y%）。
• 用户故事与场景：描述核心用户（小王、小李）将如何使用此功能。
• 需求详述：功能的具体描述、非功能性需求（如性能、安全性）。
• 附录：涵盖成本估算、风险、开放问题等。

最关键的部分在文档末尾：Shipwright强制添加的“决策框架”、“未知项”和“通过/失败就绪度”。例如，决策框架可能会给出建议：“推荐采用与第三方跨境服务商（如XX）API集成的方案，而非自建全套系统。权衡：更快上市 vs 对服务商依赖。置信度：中高。决策所有者/日期：产品负责人/2024-10-27”。这迫使PM必须做出明确的决策，而不是提交一份充满可能性的文档。

4.5 进行对抗性评审 (/challenge)

在将PRD发送给工程师之前，运行一次红队评审是极其有价值的。输入：

/challenge 以标准深度评审这份PRD，我准备把它发给技术负责人。

/challenge工作流会启动红队智能体，它会像最挑剔的同事或投资人一样，从多个维度攻击你的PRD。输出是一份挑战报告，以表格形式列出被挑战的主张、攻击向量、严重性、脆弱原因和解决建议。

如何解读和应对挑战报告：

• “证据完整性-中等”：通常意味着某个主张（如“商家最大的痛点是报关”）引用的证据不够直接或权威。你需要补充更具体的用户访谈片段或调研数据。
• “结构诚实性-严重”：这是最危险的问题。例如，PRD正文中说“开发成本较低”，但附录里却列出了需要对接多个海关API的复杂工作。这表示文档内部矛盾，必须修正估算或明确范围。
• “决策勇气-中等”：指PRD在关键决策点上含糊其辞（如“可能支持A货币，也可能支持B货币”）。红队会要求你做出明确选择并陈述理由。

报告最后会给出裁决：DEFEND（可辩护，但需修订）、CLEAR（通过）或FAIL（重大缺陷）。对于DEFEND，你应该根据建议逐一修订PRD，然后可以再次运行/challenge，直到获得CLEAR。这个过程虽然严格，但能极大提升文档的严谨度和团队信任度。

4.6 技术交接 (/tech-handoff)

当PRD通过挑战后，运行：

/tech-handoff

这个工作流会将已锁定的PRD转化为工程师需要的材料，通常包括：

• 技术规格草案：将产品需求初步转化为系统设计考量、API变更和数据模型影响。
• 设计评审要点：列出需要与设计师对齐的交互和视觉细节。
• 史诗和用户故事：在Jira、Linear等格式中生成初步的故事卡片。

重要提示：/tech-handoff的输出是优秀的初稿，但绝不能不经讨论直接扔给开发团队。PM必须与技术负责人一起Review这份技术规格，确保对复杂度、工作量的理解一致。将其视为高效启动技术讨论的“催化剂”，而非最终决定。

5. 高阶应用：决策分析系统与质量门控

对于产品经理而言，除了日常的需求开发，还会面临定价、战略方向选择、组织调整等高风险的决策。Shipwright的决策分析系统就是为这类场景设计的。

5.1 运行一次快速模式分析

假设你需要决定是否在下个季度提价15%。你可以在终端运行：

node scripts/shipwright.mjs \ --question "鉴于用户留存率出现软化迹象，我们是否应该在Q3将价格提高15%？" \ --class pricing \ --provider claude

系统会进行以下操作：

1. 场景分类：识别为pricing（定价）类问题。
2. 路由分析：根据场景类别的预定义策略（见下表），决定分析深度。对于pricing，默认进行单次分析。
3. 多智能体协作：可能调用“市场分析师”智能体研究竞品定价和价格弹性，“数据分析师”智能体模拟提价对留存和收入的影响。
4. 生成输出：在benchmarks/results/orchestrated/pricing/下生成一个包含本次运行ID的目录，里面存放着完整的分析过程(orchestration.json)和最终建议(stage-1-fast/)。

不同场景类别的处理策略：

对于governance（如是否重组董事会）和publication（如发布一份重要的白皮书）这类高风险决策，系统会格外谨慎。如果单次分析的置信度低于阈值，它会自动“升级”，要求提供更多证据或建议进行人工复核，而不是给出一个可能错误的自信答案。

5.2 解读决策分析输出

打开stage-1-fast/目录下的输出文件，你会看到类似这样的结构：

{ "recommendation": "暂不建议在Q3全面提价15%。建议对高留存客户群进行小范围（5%）的价格测试，并同步实施针对留存软化用户的增值服务计划。", "confidence": "medium", "reasoning": "分析显示，当前留存软化主要来自中小客户群，他们对价格敏感。盲目提价可能导致该群体流失加速，抵消收入增长。高价值客户群对价格弹性较低，是更好的测试对象。", "uncertainty_payload": { "key_unknowns": ["竞品Q3的定价策略动向", "增值服务对留存率提升的具体量化影响"], "recommended_next_actions": ["启动高价值客户群5%提价A/B测试", "在1个月内完成增值服务MVP并测量早期指标"] }, "decision_frame": { "trade_off": "短期收入增长 vs 中长期客户基础和市场份额风险", "owner": "产品与市场负责人", "review_date": "2024-11-15" } }

这个输出不仅给出了建议，更重要的是，它清晰地标出了“未知项”和“建议的后续行动”。这直接将决策从一个“是否”问题，转变为一个“如何以最低风险获取信息并推进”的行动计划。

5.3 利用质量门控确保产出

Shipwright内置了一套客观的“通过/失败”门控，位于evals/pass-fail.md。这些门控标准是判断任何产出（PRD、战略文档、分析报告）是否“就绪”的检查清单。

例如，一份PRD的通过门控可能包括：

• [ ]PASS：所有用户故事都关联了明确的成功指标。
• [ ]PASS：成本估算与附录中列出的所有依赖项和风险项保持一致。
• [ ]PASS：每个竞争性主张（如“比X产品快50%”）都有可验证的数据来源。
• [ ]FAIL：存在任何标记为“待定”或“TBD”的核心设计决策。

在运行/write-prd或/strategy后，你可以（也应该）手动对照这些门控检查你的文档。更好的做法是，在团队内推广这套标准，将其作为文档评审会的必查项。当“通过门控”成为团队文化的一部分，文档质量和决策效率会显著提升。

6. 常见问题与故障排查实录

在实际使用中，你可能会遇到一些问题。以下是我和社区成员遇到的一些典型情况及其解决方法。

6.1 安装与同步问题

问题1：运行/shipwright命令无反应或报错“Command not found”。

• 原因A：未在正确的项目根目录下运行。Claude Code的插件和技能是项目级别的。
• 解决：确保终端当前路径是你的项目根目录（即包含.claude文件夹和CLAUDE.md文件的目录）。
• 原因B：通过脚本安装时，文件复制不完整或权限问题。
• 解决：检查your-project/.claude/目录下是否存在skills/,agents/,commands/等文件夹。尝试重新运行安装脚本，或使用--verbose参数查看详细过程。

问题2：如何更新Shipwright到最新版本？

• 解决：如果你使用脚本安装(sync.sh)，项目根目录下会有一个shipwright-sync.sh脚本。在拉取最新的Shipwright仓库代码后，回到你的项目目录运行：

  # 交互式更新，会显示变更并询问确认 bash shipwright-sync.sh # 或自动全部更新 bash shipwright-sync.sh --yes

• 注意：更新可能会覆盖你对技能或工作流文件的本地修改。如果修改过核心文件，建议先备份。

6.2 工作流执行中的问题

问题3：/discover工作流运行时间过长或超时。

• 原因：该工作流默认会进行网络搜索以获取最新证据。如果搜索范围过广（如“分析整个电商市场”），容易超时。
• 解决：
  1. 保持请求聚焦：在启动/discover时，提供更具体的问题。例如，将“分析跨境电商市场”改为“分析中小商家在将商品上架到亚马逊和Shopify时，在海关编码和物流方面遇到的前三大痛点”。
  2. 分步进行：先运行/discover进行初步探索，根据其输出的“未知项”，再发起一次更聚焦的探索。
  3. 配置MCP服务器：为研究员智能体配置一个高效的网络搜索MCP服务器（如Tavily），这比依赖Claude的内置浏览功能通常更快、更稳定。

问题4：/challenge给出的批评过于严苛或吹毛求疵。

• 原因：红队智能体的默认设置是“标准深度”，旨在找出所有潜在漏洞。对于早期、探索性的草案，这可能显得过度。
• 解决：
  1. 调整预期：将/challenge视为一个免费的、不知疲倦的“魔鬼代言人”。即使它指出的某些问题在当前阶段不重要，记录下来也有助于未来更全面的思考。
  2. 针对性挑战：你可以在指令中指定范围。例如：/challenge 重点评审这份PRD中的成本估算和风险假设部分。
  3. 忽略与裁决：你作为PM是最终决策者。如果认为某个挑战不相关，可以在修订说明中记录“经评估，此风险在当前阶段可接受”，并说明理由。/challenge的输出是输入，不是命令。

问题5：生成的用户故事或技术规格过于泛泛，缺乏技术深度。

• 原因：/tech-handoff的产出质量高度依赖于输入PRD的详细程度和精确性。如果PRD本身在边界条件和交互细节上描述模糊，AI也难以生成具体的技术任务。
• 解决：
  1. 丰富PRD输入：确保PRD的“需求详述”部分包含了足够的细节，例如：API的预期输入输出、关键业务状态流转、数据字段的约束条件。
  2. 提供技术上下文：在CLAUDE.md中补充你的技术栈信息（如后端语言、主要框架、数据库类型），这能帮助AI生成更贴近实际的技术建议。
  3. 将其作为讨论起点：永远将/tech-handoff的输出视为与技术负责人 Kick-off 会议的议程草案。会上应逐条讨论生成的故事，由工程师补充技术细节和估算。

6.3 决策分析系统问题

问题6：决策分析总是返回“置信度：低”并建议升级，无法给出明确答案。

• 原因：你提出的问题可能过于开放、缺乏边界，或者属于governance/publication类，而系统配置的AI提供商（--provider）只有一个。
• 解决：
  1. 重构问题：将“我们应该进入哪个新市场？”改为“基于我们目前在SMB SaaS领域的优势，进入东南亚市场还是欧洲市场，在接下来18个月内能带来更高的净现值？请主要从市场增长率、竞争格局和我们的渠道能力三方面分析。”
  2. 提供多模型视角：使用多个--provider参数（如--provider claude --provider gpt）。系统会综合多个模型的推理，如果它们结论一致，置信度会提高；如果分歧严重，系统会诚实地指出分歧点，这本身也是宝贵信息。
  3. 接受不确定性：对于真正复杂、信息不足的战略问题，系统给出“不确定”并列出关键未知项，比强行给出一个错误答案更有价值。按照它建议的“后续行动”（如“收集东南亚前三大竞品的市场份额数据”）去执行，填补信息缺口。

6.4 输出格式与风格问题

问题7：希望在其他AI工具（如Cursor、Codex）中使用Shipwright的技能。

• 解决：Shipwright的技能文件是纯Markdown，完全通用。你可以直接在其他工具的对话中引用它们。例如，在Cursor中，你可以输入：“请参考skills/frameworks/working-backwards.SKILL.md中的框架，帮我起草一份产品新闻稿。” 更高级的用法是，利用这些工具的“自定义指令”或“知识库”功能，将整套技能库导入，实现类似Claude Code中的路由效果。

问题8：不想一直使用Shipwright的“决策导向”输出风格，想切换回普通的对话模式。

• 解决：在Claude Code中，输入命令：/output-style default即可切换回默认风格。当你想恢复时，输入：/output-style shipwright。这个设置是会话级的，不影响其他会话。

7. 将Shipwright融入团队工作流

个人使用Shipwright能极大提升效率，但它的真正威力在于融入团队流程。以下是一些实践建议：

1. 建立团队级的“黄金标准”输出库：在团队共享目录或Wiki中，维护一个examples/golden-outputs/文件夹。存放那些经过充分评审、实际被成功执行过的Shipwright产出物（PRD、战略文档、发布计划）。新成员可以将其作为参考模板，统一团队的输出质量基线。

2. 在关键评审节点引入/challenge：将/challenge作为PRD或战略文档进入正式评审前的强制环节。可以指定一位团队成员（或轮流）担任“红队指挥官”，负责运行此命令并汇总挑战报告，作为评审会议的第一项议题。这能将评审焦点从格式纠错转移到实质性的逻辑和证据挑战上。

3. 利用决策分析系统进行预演：在重要的季度规划会或董事会之前，针对几个关键的战略选项，用决策分析系统（配置多个AI提供商）跑一次快速分析。生成的报告（包括推荐、置信度、未知项）可以作为会前阅读材料，让与会者提前进入状态，聚焦讨论信息缺口和权衡点，而不是在会议上才第一次思考基本问题。

4. 定制化技能库：每个团队都有自己独特的工作方法。鼓励团队成员将常用的内部框架（如你们特有的用户调研模板、A/B测试评估清单）编写成新的.SKILL.md文件，提交到团队的Shipwright分支中。久而久之，你们会积累起一套高度定制化、反映团队最佳实践的能力库。

最后一点体会：Shipwright不是一个替代思考的“自动写作机”。它是一个强制你进行结构化、证据化、决策化思考的“外脑”和“质量检查员”。最初使用时会觉得流程繁琐，但习惯之后，你会发现它帮你节省了大量在文档格式、逻辑自洽和反复沟通上的心力。你能更专注在真正属于产品经理的工作上：理解用户、定义价值、做出艰难的取舍。它让AI从一种“新奇玩具”，变成了产品工作流中一个可靠、严肃的组成部分。