1. 项目概述为产品经理打造的AI驱动操作系统如果你是一名产品经理每天的工作流是否经常在文档、会议、即时通讯工具和项目管理软件之间反复横跳你是否曾希望有一个统一的“操作系统”能将市场发现、需求撰写、战略规划和发布执行这些离散的任务串联起来并且每一步都有质量保证Shipwright正是为了解决这个痛点而生。它不是一个简单的提示词集合而是一个由46个技能、7个智能体、17个链式工作流和一个决策分析系统构成的完整框架旨在将AI从“一个聪明的聊天伙伴”升级为“一个遵循严格流程的协作同事”。其核心哲学是“证据优先、决策明确、质量门控”确保产出的每一份PRD、战略文档或发布计划都不仅仅是看起来不错而是经得起推敲、团队可以立即执行的可靠工件。我最初接触Shipwright时以为它只是另一个Claude Code的插件库。但深入使用后发现它的设计理念截然不同。大多数AI工具追求的是“一次生成尽可能多的内容”而Shipwright追求的是“在正确的流程节点生成结构正确、证据充分、决策清晰的内容”。这就像从“手工作坊”升级到了“精实生产线”每个环节都有检查点和标准。对于需要处理高复杂度、高不确定性产品决策的PM来说这种系统性的约束不是限制而是解放——它让你能把认知精力集中在真正的战略判断上而不是反复纠结文档格式或论证逻辑是否严密。2. 核心设计哲学从“更好的提示”到“质量系统”许多团队尝试用AI辅助产品工作时容易陷入一个误区不断优化提示词希望模型能一次性吐出完美的PRD。但结果往往是格式飘忽不定、论据混杂假设、建议模棱两可。Shipwright的创始人EdgeCaser显然洞察到了这一点因此构建了一套围绕提示词的质量控制系统。这套系统的价值通过下表可以清晰地与传统“裸奔式”AI提示进行对比维度原始AI提示Shipwright系统一致性每次运行的输出格式都可能变化需要人工反复调整。通过强制性的 输出标准 确保所有文档拥有稳定的签名结构如“决策框架”、“未知与证据缺口”、“通过/失败就绪度”三个必选模块。决策质量输出往往是描述性的“可以考虑A或B”缺乏明确的建议和责任人。要求每个产出都必须包含一个决策框架明确给出推荐方案、权衡分析、置信度以及决策所有者和日期。证据纪律事实和假设容易混为一谈模型可能将网络上的观点当作既定事实引用。强制要求所有主张都必须有来源并明确列出“未知项与证据缺口”区分已知事实和待验证假设。就绪度门控依赖人的主观判断“看起来不错”容易遗漏关键漏洞。采用二元的 通过/失败门控 。文档必须通过一系列客观检查点如“所有竞争性主张均已溯源”、“成本估算与附录要求一致”才能被视为“就绪”否则会触发确定的修复流程。对抗性压力测试让同一个模型批判自己刚生成的内容效果有限容易陷入循环论证。提供可选的/challenge工作流由一个独立的“红队”智能体对成品进行压力测试从证据完整性、结构诚实性、决策勇气等维度发起挑战。恢复路径发现问题后需要临时重写或打补丁过程随意。提供确定性的 恢复手册 。当文档在/challenge中失败时系统会明确指出问题类型如“证据完整性-中等”并引导至对应的修复步骤而非从头开始。交付质量高度依赖当次提示词的质量每次交付物水平波动大。通过角色约束和检查点的可重复工作流确保不同PM、不同时间产出的同类文档都能达到一致的、可执行的质量基线。这种设计带来的最大改变是工作模式的转变。你不再是与一个“黑盒”对话而是运行一个由智能体担任不同角色如研究员、策略师、红队评审员的确定性流程。你的角色从“撰稿人”变成了“主编”和“最终决策者”智能体负责提供结构化的论据和选项而你负责做出基于这些高质量输入的战略判断。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中提到的三条路径实际上是三个最常用的高阶工作流组合新功能路径 (/discover → /write-prd → /tech-handoff): 这是最经典的“从0到1”流程。/discover工作流会调用多个研究技能生成证据包/write-prd基于此生成结构化的PRD/tech-handoff则将PRD转化为技术规格、设计评审要点和用户故事。我的经验是不要在同一个会话中跑完整个链条。最好在每个阶段结束后人工审核输出特别是/discover的证据报告确保输入质量这样后续环节的产出才会更可靠。季度规划路径 (/customer-review → /strategy → /okrs): 这个路径的关键在于“输入信号的梳理”和“战略边界的设定”。/customer-review会汇总近期的客户反馈、支持工单、使用数据/strategy则基于这些输入帮助你形成几个清晰的战略押注并明确“不做哪些事”的淘汰标准最后/okrs生成与战略押注对齐的OKR草案并自动进行一致性审计。这里常见的坑是如果/customer-review输入的信号过于庞杂或矛盾/strategy的输出可能会变得模糊。建议先人工对客户信号进行初步归类和高低优先级标注再交给工作流处理。发布路径 (/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的“策略师”智能体自己评审自己而是会将任务派给独立的“红队评审员”智能体。这个红队智能体拥有不同的“思维”提示和检查清单专门负责挑刺和压力测试。这种“对抗性”设计是产出高质量、抗脆弱文档的关键。与外部工具的连接智能体不仅可以使用内部技能还能通过MCPModel 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 shipwrightshipwright安装完成后在你的项目根目录打开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研究员下达了清晰的调研简报。之后研究员智能体会开始工作它可能会调用网络搜索技能查找关于中小商家跨境电商痛点的行业报告、论坛讨论。调用竞品分析技能调研现有跨境电商SaaS平台如Shopify跨境模块、Shoplazza等的解决方案和定价。尝试分析你提供的任何内部数据如客服工单中关于“跨境”的关键词。大约几分钟后你会得到一份发现报告。请务必仔细审查这份报告重点关注其“证据”部分每个关于市场规模、用户痛点、竞品功能的陈述是否都附上了来源链接或数据引用报告末尾的“未知项与证据缺口”是否列出了你关心但未找到答案的问题如“目标商家愿意为此功能支付多少溢价”这是后续环节的输入基础其质量直接决定最终PRD的可靠性。4.4 撰写PRD (/write-prd)在审核并通过发现报告后你可以直接在同一会话或新会话中运行/write-prd智能体会自动将上一阶段生成的发现报告作为输入开始撰写PRD。它会遵循严格的PRD技能模板产出包含以下核心章节的文档背景与目标基于发现报告阐述为什么要做这个功能。成功指标定义如何衡量该功能是否成功如上线后3个月内有X%的活跃商家使用该功能带动跨境GMV增长Y%。用户故事与场景描述核心用户小王、小李将如何使用此功能。需求详述功能的具体描述、非功能性需求如性能、安全性。附录涵盖成本估算、风险、开放问题等。最关键的部分在文档末尾Shipwright强制添加的“决策框架”、“未知项”和“通过/失败就绪度”。例如决策框架可能会给出建议“推荐采用与第三方跨境服务商如XXAPI集成的方案而非自建全套系统。权衡更快上市 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系统会进行以下操作场景分类识别为pricing定价类问题。路由分析根据场景类别的预定义策略见下表决定分析深度。对于pricing默认进行单次分析。多智能体协作可能调用“市场分析师”智能体研究竞品定价和价格弹性“数据分析师”智能体模拟提价对留存和收入的影响。生成输出在benchmarks/results/orchestrated/pricing/下生成一个包含本次运行ID的目录里面存放着完整的分析过程(orchestration.json)和最终建议(stage-1-fast/)。不同场景类别的处理策略场景类别默认路径是否需要跨模型族验证governance(治理)快速分析置信度低时自动升级是publication(对外发布)快速分析置信度低时自动升级是pricing(定价)单次分析否product_strategy(产品战略)单次分析否unclassified(未分类)单次分析否对于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工作流运行时间过长或超时。原因该工作流默认会进行网络搜索以获取最新证据。如果搜索范围过广如“分析整个电商市场”容易超时。解决保持请求聚焦在启动/discover时提供更具体的问题。例如将“分析跨境电商市场”改为“分析中小商家在将商品上架到亚马逊和Shopify时在海关编码和物流方面遇到的前三大痛点”。分步进行先运行/discover进行初步探索根据其输出的“未知项”再发起一次更聚焦的探索。配置MCP服务器为研究员智能体配置一个高效的网络搜索MCP服务器如Tavily这比依赖Claude的内置浏览功能通常更快、更稳定。问题4/challenge给出的批评过于严苛或吹毛求疵。原因红队智能体的默认设置是“标准深度”旨在找出所有潜在漏洞。对于早期、探索性的草案这可能显得过度。解决调整预期将/challenge视为一个免费的、不知疲倦的“魔鬼代言人”。即使它指出的某些问题在当前阶段不重要记录下来也有助于未来更全面的思考。针对性挑战你可以在指令中指定范围。例如/challenge 重点评审这份PRD中的成本估算和风险假设部分。忽略与裁决你作为PM是最终决策者。如果认为某个挑战不相关可以在修订说明中记录“经评估此风险在当前阶段可接受”并说明理由。/challenge的输出是输入不是命令。问题5生成的用户故事或技术规格过于泛泛缺乏技术深度。原因/tech-handoff的产出质量高度依赖于输入PRD的详细程度和精确性。如果PRD本身在边界条件和交互细节上描述模糊AI也难以生成具体的技术任务。解决丰富PRD输入确保PRD的“需求详述”部分包含了足够的细节例如API的预期输入输出、关键业务状态流转、数据字段的约束条件。提供技术上下文在CLAUDE.md中补充你的技术栈信息如后端语言、主要框架、数据库类型这能帮助AI生成更贴近实际的技术建议。将其作为讨论起点永远将/tech-handoff的输出视为与技术负责人 Kick-off 会议的议程草案。会上应逐条讨论生成的故事由工程师补充技术细节和估算。6.3 决策分析系统问题问题6决策分析总是返回“置信度低”并建议升级无法给出明确答案。原因你提出的问题可能过于开放、缺乏边界或者属于governance/publication类而系统配置的AI提供商--provider只有一个。解决重构问题将“我们应该进入哪个新市场”改为“基于我们目前在SMB SaaS领域的优势进入东南亚市场还是欧洲市场在接下来18个月内能带来更高的净现值请主要从市场增长率、竞争格局和我们的渠道能力三方面分析。”提供多模型视角使用多个--provider参数如--provider claude --provider gpt。系统会综合多个模型的推理如果它们结论一致置信度会提高如果分歧严重系统会诚实地指出分歧点这本身也是宝贵信息。接受不确定性对于真正复杂、信息不足的战略问题系统给出“不确定”并列出关键未知项比强行给出一个错误答案更有价值。按照它建议的“后续行动”如“收集东南亚前三大竞品的市场份额数据”去执行填补信息缺口。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从一种“新奇玩具”变成了产品工作流中一个可靠、严肃的组成部分。