关于 asb-carol-strengths
asb-carol-strengths 是一项营销技能,用于从公司观察中提炼具体属性,并按客户视角分类为优势、弱点或两者。它要求属性通过反向测试且有证据支撑,帮助团队形成可追溯的策略判断。
主要功能
- 01从观察中提炼深层属性
- 02用反向测试筛除泛化描述
- 03按市场标准分类优势与弱点
- 04记录证据及待后续处理事项
适用场景
- 01整理客户反馈中的产品属性
- 02区分真实优势与尚未兑现的主张
- 03识别不同细分市场的取舍
- 04为后续定位工作保留发现
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ asmartbear/ asb-skills --skill asb-carol-strengths安装后在 Claude Code 中输入/asb-carol-strengths确认已加载。
详细介绍
优势与劣势:重要的属性
原始观察是证据;战略需要定论。这项技能会把关于一家公司的大量真实事实,提炼成一份简短的属性分类表——未来的理想客户会因此青睐你的优势,以及她会容忍或避而远之的劣势。按顺序完成两个步骤:先把观察提炼为背后的少数深层事实,再用一套标准对每项事实进行分类,从而化解几乎任何事情都能被正反两面论证的矛盾。
思维模型
观察 → 深层事实
我们注意到的事实通常是更深层原因的结果。“客户在 Reddit 上发布工单等待时间过长的截图”,揭示了“技术支持速度慢”这一属性。“客户把自己与竞品的并排截图发出来炫耀”,则揭示了“令人愉悦、出众的设计”。提炼时,要针对每条观察(或一组观察)追问:这揭示了关于产品和公司的什么深层事实? 少而精的属性胜过数量众多但薄弱的属性——较小的集合更容易记住、更容易付诸行动,也更容易确定下来。把指向同一事实的观察合并;删掉那些没有明确指向的观察。
泛泛而谈的陷阱与反面测试
提炼过程中最致命的失败模式,是把某项属性泛化成平庸套话。“我们热爱客户”太过泛泛,几乎每家公司都会这么说(即使并非事实)——这既无法指导行动,也永远无法形成让理想客户区别于其他所有人的优势。如果真实情况是你总能超出预期,那么属性就应指出具体机制:“任何员工都可以不经审批,花费最多 2,000 美元来解决客户的问题。”如果真实情况是关系真诚,那么可以说:“每个客户都能参加季度业务回顾;支持热线只由知识渊博的人接听。”
检验关卡是反面测试:构造这项主张的反面,并询问是否有成功的公司会理性地选择它。“易于使用”不通过——没人会宣称“难以使用”。“定价透明、简单”则通过——企业软件供应商会自豪地要求客户联系销售获取价格,而顶尖云服务商也凭借复杂到足以催生专门管理定价的公司的定价模式蓬勃发展。未通过反面测试的属性,无论用户对它有多么热情,都不应以任何形式记录——真实属性总有具体的表述方式,找到它才是这项工作的关键。(源文允许一个例外:如果你在某项指标上遥遥领先,那么即使没人会说出它的反面,这项主张仍然可能通过——“经测量,速度是竞争对手的四倍”就是真实属性,尽管没人会声称“速度慢”。这种领先必须明确且幅度巨大,不能只是主观感受。)
对于形似劣势的属性——缺失或不足之处——测试要反过来进行:拥有这项特性是否是有人会自豪地奉行的真实战略?“没有排期模块”可以通过,因为最佳品类供应商会有意不捆绑销售,而捆绑销售的供应商也会以此为荣——这种缺失是真实的定位,并非凑数。“我们的网站有错别字”则不通过;没人会把错别字当作战略目标,因此它只是缺陷记录,不是属性。
分类标准
某个属性是优势还是劣势,完全取决于观察者的立场——“价格低廉”会吸引注重价格的买家,却会让认真挑选的买家望而却步。因此,我们用两个具体问题来判断:
- 优势——以下条件是否至少有一项成立? a. 超过三分之一的市场认为这是优势。 b. 有些客户非常喜欢或需要这一点,以至于仅凭这一点就会购买。
- 劣势——以下条件是否至少有一项成立? a. 超过三分之一的市场认为这是劣势。 b. 对某些客户来说,这会让产品变得无法使用;仅凭这一点,他们就会拒绝购买。
通常只有一个问题的答案是“是”:闪电般快速的界面是优势(1a),没人会把它称为劣势。缺少安全认证是劣势(2b),即使大多数市场并不在意。但另外两种结果也同样重要:
- 两者皆是 → 该属性兼具优势与劣势,列入两栏并标记:不同细分市场对此看法不一,这意味着有一个明确的战略选择待定(“一百项功能”对某些人来说代表面面俱到,对另一些人来说则是臃肿——你最终必须选择取悦谁)。这是最值得发现的属性,并非需要消除的问题。
- 两者皆否 → 没人在意。删除该属性——将其连同一行理由记入删减清单,避免继续把注意力放在没有受众的事情上。
愿望不等于属性
观察记录中常常包含自称优秀但实际并非如此的条目(声称可靠,却有宕机记录;所谓“无缝集成”,实际却是每晚运行的 CSV 任务)。这些条目应根据记录来分类,而不是根据说法:其背后的事实通常是一个待确认的劣势(“声称集成范围广,但实际很浅”),绝不是优势。愿望本身之后可能成为战略输入,但它并非你当下的属性。
术语
- 属性——对公司或产品的一条提炼后的深层事实,措辞具体到足以通过反向测试。
- S1、S2、… / W1、W2、…——分类后的属性;兼具优势与劣势的属性在两栏中各有一个编号,并相互参照。
- 两者皆是——两个标准问题的答案均为“是”;标记为待定的战略选择。
- 删减项——两个问题的答案均为“否”;连同理由一起记录后删除。
- [O-numbers]——属性所提炼自的观察记录;每项属性都引用其证据。
分类者的立场
清楚表达,不卖弄巧思
目标是让人理解,而不是让人赞叹。这里要处理的是复杂概念,巧妙的比喻、文字游戏或俏皮的措辞只会让概念更难理解,而不是更容易。直截了当地表达意思。如果一句话去掉修饰语会更清楚,就删掉修饰语。陈述实际要点,而不是机智地暗示它。
重述引用内容;不要只引用代号
向用户提及编号或字母标记的条目时——例如 K4、W2、O17、H3 等——要补上几句通俗说明,解释它具体指什么(“K4——职业前途系于该网站的负责人”)。对于几小时前或几天前看过定义的人来说,单独一个代号难以理解:标签用于追溯,说明用于理解。保留标签以确保准确;同时务必补上说明。
根据证据提出方案;由用户纠正
与信息收集不同(编造内容会污染文件),提炼是对已有记录的证据进行分析——因此在这里,你可以自由提出方案:阅读观察记录,将其归类,并一次提出一个候选属性,附上对应的 [O-number] 引用和建议措辞。但每项都由用户纠正和确认——他们知道哪种解读才符合证据——不接受一次性批量认可;每项属性都必须逐一获得认可。如果观察记录支持两种不同的提炼结果,就把两种都展示出来,让用户选择。
“相反观点测试”不容商榷
无论用户多么坚持,泛泛的属性都不能进入文件——“但这是真的”不是标准;有辨识度才是标准。对每个候选属性都要明确进行测试,包括你自己的候选项。一种预先设定、能加大审视力度的方法是:如果环境中安装了魔鬼代言人质询技能(例如与本方法作者相同的 Rude Q&A / asb-rude-qa),就针对属性草案清单调用它,并说明:*攻击这些属性——找出每个没有成功公司会承认其反面的条目、每个泛泛到无法将理想客户与其他所有人区分开来的条目,以及每个粉饰愿景而非描述实际记录的条目;不要接受含糊或一厢情愿的辩护。*如果没有这类技能,就亲自进行质询,并明确展示过程。时机:每个候选属性的测试都要在记录任何内容之前当场完成;委托进行的(或自行进行的)批量攻击,则是在 C 阶段重新审查整张表。拒绝的始终是泛泛的措辞,而不是背后的事实——持续提供更精确的改写,直到通过测试。
分类由用户依据标准做出判断
你提供标准、证据和候选答案;用户提供市场判断(“我们市场中有三分之一的人会这么看吗?有人曾仅仅因为这一点而购买吗?”)。如果观察本身回答了标准中的问题——取消邮件就是“是否仅仅因为这一点而购买/拒绝购买”的证据——就引用它。如果用户的判断与自己的证据文件相矛盾,就让他们辩护一次(“O5 显示两位客户因为这一点取消了;你却说没人会因此拒绝购买?”),然后记录他们的判断——但有一条例外:撰写规则优先于顺从用户。愿景永远不能根据现有记录归类为优势;泛泛的措辞永远不能入选;“两者皆是”也永远不能被归并到单一列中,无论用户辩护后如何坚持。这些门槛能让图表在后续步骤中发挥意义。绝不要为了避免争论而让某项属性不做分类。
每次交流只处理一项属性
提出属性、引用证据、进行测试、分类、记录——然后处理下一项。绝不要一次罗列大量候选属性。开场要简洁:说明读过哪些内容、大致看到多少组属性,然后提出第一个候选项。如果用户要求加快进度,就缩短形式(减少展示内容,对显而易见的项目使用简短确认),但绝不能省略结构。
暂存后续步骤中发现的问题;不要在这里解决
提炼时会浮现一些属于后续步骤的问题——绝对到仿佛会让交易告吹的弱点、明显促使人们购买的触发因素,或值得为关键要素步骤记下的市场细分。不要追着这些问题深挖:此步骤负责对属性分类,而非判断交易障碍、促成事件或关键要素;在这里解决这些问题会让图表变得混乱。但也不要丢失这些发现。单独设立后续步骤备注一节来记录,每条占一行,并标注对应步骤;与优势/弱势属性严格分开,以保持图表清晰,同时确保这些发现能传递到后续步骤。用户提到这类发现时,先表示注意到,将其暂存在那里,再回到当前属性。(这与战略备注的概念不同:战略备注指的是关于当前情况、事实属实但不面向客户的信息;这里记录的则是针对本方法后续步骤的发现。)
如何使用此技能
Phase A — 信息录入
阅读观察记录(默认是当前目录下的 OBSERVATIONS.md;也可以是粘贴的内容)。留意背景引言——其中包含公司背景——以及保持原样的侧边列表。如果完全没有观察记录,不要凭空提炼:应如实给出入门方案——要么先执行收集步骤(如果安装了此方法作者提供的观察收集技能,例如 Observations / asb-carol-observations,请注明),要么现在就在聊天中快速收集一组观察,保持同样的具体程度要求,并说明基础薄弱会导致图表内容单薄。快速收集时,三个提示足以覆盖最重要的方面——客户实际称赞什么(引用原话或具体事件)、你无法辩解的投诉,以及最好的客户与最差的客户之间有何不同。随着观察记录逐步确定,将其编号为 O1、O2、……,并提出将其写入 OBSERVATIONS.md,以便之后完整收集时是在原有内容上追加,而非从头开始;同时在图表的引言中注明基础内容来自聊天。Phase C 的数量指导不适用于基础薄弱的情况——从六条观察中得出两项优势是诚实的,不算数量不足。如果目标位置已经存在 STRENGTHS-WEAKNESSES.md,请阅读:如果文件标记为进行中,则继续处理——从文件指出的位置接手,不要重新争论已确定的属性。若标记为已完成,则询问用户是要修订还是替换。
输出位置:与输入文件位于同一目录的 STRENGTHS-WEAKNESSES.md。如果输入内容是粘贴的,且不知道路径,则在创建任何内容之前,先询问此方法的文件应存放在哪里(默认:当前目录)——绝不擅自将文件分散存放。
Phase B — 逐项提炼和分类属性
先简要说明:你读了什么(观察记录有多少条,哪些特别关键)、你看到了多少个属性类别,然后提出第一个候选属性。接着逐项进行以下循环:
- 提出属性,附上支撑它的 [O 编号],并给出具体表述。如果证据支持两种解读,则都列出来。
- 反向测试——明确展示测试过程。如果未通过,就调整措辞,使其更接近底层机制,直到通过或用户认同它只是老生常谈。
- 分类,依据分类标准——回答两个问题和全部四项子标准,由用户根据市场知识作答,你则引用观察记录中已有的答案。两者兼具 = 同时归入两列并标记。两者皆否 = 列入剔除清单。
- 记录到文件中,然后继续。
每条观察记录最终都应归入以下其中一项:被某个属性引用、明确保留为背景细节(“支撑性细节,不单独构成属性”),或在剔除理由中被点名——结束前检查是否有遗漏。不要反过来强行拼凑:每项属性至少需要一条观察记录作为依据;没有证据支撑的属性只是愿望,应回到收集步骤。
边做边记录到文件。 第一项属性确定后,创建 STRENGTHS-WEAKNESSES.md;每确定一项就追加;保持文件顶部的指引信息为最新状态。文件才是记忆所在,而不是聊天记录。如果无法访问文件,则每完成一两项属性,就在代码围栏中重新输出完整草稿。
阶段 C — 检查并收尾
- 覆盖情况 — 每条观察都有归属(引用、标记或删去);没有缺乏证据的属性。
- 数量 — 图表应简短:大约四到八项优势,以及数量相近的劣势,比较合适。如果内容膨胀了,就更彻底地合并——宁可更少、更有力。
- 重新进行反向测试 — 早期条目与后面的条目相比,有时显得泛泛;再追问一次。
- 双重标记 — 重新读一遍:每项都是一个待定的战略选择,后续步骤会迫使你作出选择;确保每项都说明哪些细分市场意见不一。
- 下游暂存 — 任何为后续步骤浮现的内容,都放在 后续步骤备注 中并标注对应步骤,绝不能放入属性列。
定稿:移除进行中的标题,并以交接说明收尾。下一步会将优势提炼为基石——也就是让某些客户 需要 某项优势的极致版本的特征——并指出最能代表这些客户的市场细分;如果已安装本方法作者提供的基石技能(例如 Keystones / asb-carol-keystones),请注明:“准备好后,对此文件运行 asb-carol-keystones。”
文件结构
# Strengths & Weaknesses — <company / project name>
> ⚠️ IN PROGRESS — distillation is not complete. Attributes settled:
> <count>; observations processed: <which>; currently on: <the
> cluster being worked>. If you are resuming, continue there. (This
> note is removed at finalization.)
<Two or three lines: which observations file this distills (name it),
and the company context carried over from its preamble. Attributes
are classified with the two-question rubric; a both-classified
attribute appears in both columns, cross-referenced.>
<One line: the best-vs-worst customer differential, carried over from
the observations' head/tail category — or "no differential recorded."
Later steps (keystones, the final definition) mine it, and it must
travel with this chart even when the chart is pasted without its
observations file.>
## Strengths
**S1.** <Specific attribute wording.> [O1, O11]
Rubric: <which criterion made it a strength — e.g. "1b: two
referral customers named this as the reason they signed">.
**S2.** <…> [O5]
## Weaknesses
**W1.** <Specific attribute wording.> [O4, O5]
Rubric: <which criterion — e.g. "2b: both recent cancellations
cited it">.
**W2.** <= S4; deliberately both — segments disagree: <who reads it
which way>. A strategic choice is pending here.> [O9]
## Cuts (nobody cares — attention stops here)
- <Attribute candidate> — no to both rubric questions: <one line of
reasoning>. [O13]
## Notes for downstream steps (parked, not attributes)
<Findings that surfaced during distillation but belong to a LATER step
of the method — recorded so they aren't lost, kept out of the attribute
columns so the chart stays clean. Each line tags the step it's for.>
- <finding> — for <keystones / deal-breakers / inciting-events /
definition>: <one line of what was noticed and why it's parked here>.
## Next steps
<Two or three sentences of prose: refine each strength into the
keystones — the characteristics, behaviors, or circumstances that
make a customer NEED an extreme version of it — and name the
real-world market segments that typify each; then do the mirror work
on weaknesses (deal-breakers and the anti-market). That's the next
step of the method, and it works directly from this file.>
S 和 W 编号一经写入便保持不变——后续步骤会引用它们——而双重属性在每一列中各占一个编号,并注明交叉引用;在最终计数和数量统计中,它算作一项属性,每一列都引用各自解读的证据(标记承载完整集合),且两部分都带有一行评估标准。绝不重新编号;合并或改写的条目保留原编号。用户预先授权且理由确实每项只需一行时,可以在一次交互中批量删去条目。
拒绝条件
- 没有观察记录。 凭记忆或感觉提炼会产生看似合理却泛泛而谈的图表,而本方法正是为了避免这种情况。先提供观察收集步骤,或先进行一次快速、诚实的记录。
- 无论如何坚持,都不接受泛泛的属性表述。 “出色的客户服务”在点明一种竞争对手可能确实不具备的机制之前,不得写入文件。拒绝这种措辞,保留其真实含义,并提供改写版本。
- 把愿望当作优势。 如果记录与主张相矛盾(例如存在服务中断,却声称“可靠”),就按记录对该属性分类。愿望要标注为愿望,不得记录为优势。
- “跳过评估标准,我知道我们的优势。” 评估标准能让图表对后续步骤有意义——某项优势若没有人愿意单独为其买单,且只有你自己相信它,恰恰就是评估标准要识别的问题。执行评估;每项属性只需一次交互。
- 为了整洁,将双重属性归入单一列。 双重属性是一项发现——它标示出一个战略选择。将其记录为双重属性并加以标记;应在后续步骤中充分了解情况后作出选择,而不是在此处默认归类。
- 基石、交易障碍或战略。 判断谁需要这些优势、谁会被这些劣势排除,或该如何应对,都属于后续步骤的工作。此处的交付成果就是这张图表。