translate

用途

Translate Your Expertise Into a Product 是一个面向领域专家（如律师、医生、承包商、会计等）的技能，目标是把他们多年积累的专业知识，转化为 AI 编程工具可以直接构建的软件需求。它不是教用户如何写代码，而是帮助用户用 AI 能理解的语言，从“我知道这个问题存在”走到“这就是软件需要做的事”。

核心理念

你不需要学会像开发者一样思考，只需要把痛点描述清楚，AI 负责剩下的部分。
从业 20 年后，日常工作流程往往已经很高效。机会不在你的常规流程里，而在你已经学会忍受的痛点里。
最好的 SaaS 产品不自动化一切，而是消除那个让专业人士说“我最讨厌这一步”的环节。
你的领域专业知识本身就是产品规格。难的不是构建，而是知道该构建什么——而你已经知道。
如果你无法在 30 秒内向陌生人解释清楚它为什么痛苦，这个痛点就不够尖锐，不足以支撑一门生意。

主要能力与步骤

第 1 步：找到值得为之构建的痛点

不要罗列整个工作流程，直奔痛点。用五个问题各写一句话：你一直拖延或害怕做、即使做过几百次的任务是什么；什么任务耗时远超其产生的价值；什么让你每月至少一次想到“一定有更好的办法”；你看到行业新人被什么难住、而工具可以解决；你愿意每月付 100 美元来永远不必再做的事是什么。

随后对每项痛点评估：发生频率（每天、每周、每月）、同行业有多少人也有同样痛点、现有工具是否解决及有何问题、软件是否真能解决还是需要人的判断、目前的替代做法每周花多少小时/每月花多少美元/每季度出多少错。

按“频率 × 痛苦强度 × 市场规模 × 可构建性”排序，判断哪个是最强的 SaaS 机会。文档提醒：“我这行每个人都需要”通常意味着你找不到具体的人；要能说出一个真实姓名、真实有该痛点的同行，否则继续寻找。

文档给出判断痛点是否配得上 SaaS 的信号表：频率上每周或更高为强、每年一次为弱；谁会遇到上全行业为强、只有自己为弱；当前方案上手工/表格/破损工具为强、已有好工具为弱；付费意愿上“我现在就愿意付”为强、“那倒是不错”为弱；可构建性上“数据进、决策出”为强、需要深度人为判断为弱。若只有你一个人有该痛点、已有知名好工具、痛点不频繁、或每一步本质上都需要人为判断，则应尽早放弃这个想法。

第 2 步：描述问题，而不是解决方案

领域专家最常犯的错误是直接跳到“我想要一个能做 X 的应用”。应先描述问题，让解决方案自然浮现。示例中，坏的做法是“我想要一个有文档管理系统、自动归档和客户门户的平台”；好的做法是“每次我完成一笔房地产交易，都要花 3 小时从 6 个不同的相关方那里追文件、确认都签了字、再上传到县记录系统。一半时候会缺东西，还得去追人”。后者能让 AI 工具明确知道该构建什么，前者只是一份可能根本解决不了实际问题的功能清单。

该步骤要求向 AI 提供：谁有这个痛点（职业、角色、经验水平）、痛苦的步骤是什么（逐步描述，只写痛苦部分）、多久发生一次、每次花多久、哪里会出问题（具体失败模式和挫败点）、他们现在怎么做（现有工具、表格、手工流程、替代办法）、什么叫“做好了”（他们如何知道任务成功完成）。并在此基础上让 AI 描述用户会经历的工作流，而非功能列表：打开应用看到什么、点击什么、哪些自动完成、哪些需要用户输入。

第 3 步：区分“我需要这个”与“市场需要这个”

你是专家，但也只是一个人，你的偏好不等于市场。文档列出专家的盲点：以为“我会用上每个功能”（你其实是高级用户，多数人只需要你打算构建的 20%）；以为“必须处理边缘情况 X”（你见过 X 是因为你做过 5000 次，多数用户没有）；以为“现有工具都很糟”（它们对 80% 的人可能够用，只是你的标准更高）；以为“我完全知道它该长什么样”（你了解的是自己的工作流，同行做法可能不同）。相应做法是先做那 20%、先上线不含 X 的版本、验证他人是否同样不满、在锁定规格前先与 10 位同行交流。

第 4 步：把痛点变成规格

在写完整规格前先回答：本周就有人愿意付费的最小版本是什么？不是等平台建成后，不是等 v2。有没有一个工作流、一个界面、一个结果本身就足够有价值？如果答不上来，说明范围太大，继续削减。

该步骤要求让 AI 产出一份可交给 Claude Code、Lovable、Replit 等 AI 编程工具的功能规格，包含：一句话说明应用做什么；谁使用（角色、频率、设备）；顺利路径（一切正常时用户的 3-5 步）；出错情形（2-3 个边缘情况及应用应如何处理）；V1 不做什么（明确列出暂不构建的功能）；什么叫“完成”；最窄切入点（完整产品出现之前，本周就有人愿付费的最小功能）。规格要简单到能在 2-4 周内构建，超出就削减范围。之后可交给 plan 技能生成完整可构建规格，或直接交给 AI 编程工具。

第 5 步：用同行验证，而不是朋友

构建前确认你的痛点是共有的。你在这里有不对等的优势——你已认识行业内 50 多人。可让 AI 帮助撰写一份 3 个问题的调查问卷，用于向同行验证 SaaS 想法。问卷要求：不描述你的解决方案（避免引导性）；询问他们当前的流程与痛点；揭示付费意愿；填写时间不超过 2 分钟。文档还建议参考 validate 技能获取完整验证框架与烟雾测试。

适用场景

适用于在某一专业领域有多年经验、想把自己的知识做成软件产品、但不确定该构建什么的独立创业者或领域专家。适合在动手写代码前梳理产品方向、筛选想法、编写规格和做需求验证。

常见错误

构建自己个人想要的所有功能；描述解决方案而非问题；假设自己的工作流是通用的；从罕见的边缘情况开始；把自己的整个日常工作流都画出来；坚持要处理某个冷门场景。文档给出的对应做法分别是：先构建 80% 用户都需要的 20%；“我在 X 上花 3 小时”胜过“我想要一个能做 Y 的应用”；先与 10 位同行交流；先上线顺利路径，边缘情况留到 v2；直奔痛点，常规流程本就高效；你见过那个场景是因为你做过 5000 次，新用户没有。

限制

资料未提供该技能的具体收费、价格、平台支持范围或实际使用效果数据。

技能介绍

用途