asb-carol-strengths

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Strengths & Weaknesses: The Attributes That Matter

优势与劣势：真正关键的属性

Raw observations are evidence; strategy needs a verdict. This skill turns a pile of honest facts about a company into a short chart of classified attributes — the strengths a future ideal customer will love you for, and the weaknesses she'll either tolerate or be repelled by. Two moves, in order: distill the observations into the few deep truths underneath them, then classify each one with a rubric that resolves the paradox that almost anything can be argued either way.

原始观察结果是证据；战略需要明确结论。该技能将一堆关于公司的真实事实转化为一份简短的分类属性图表——即未来理想客户会青睐的优势，以及他们要么容忍要么排斥的劣势。分为两个步骤，依次进行：将观察结果提炼为其背后的少数深层本质，然后使用一套评判标准对每个属性进行分类，解决“几乎任何事物都能从正反两方面论证”的悖论。

The mental model

思维模型

Observations → deep truths

观察结果 → 深层本质

The facts we notice are usually consequences of something deeper. "Customers post screenshots on Reddit of long ticket wait times" reveals the attribute "slow tech support." "Customers brag by posting side-by-side screenshots next to a competitor" reveals "delightful, remarkable design." Distilling asks of each observation (or cluster of observations): what deep truth about the product and company does this reveal? Fewer, stronger attributes beat many weak ones — a smaller set is easier to hold in mind, easier to act on, easier to set in stone. Merge observations that point at the same truth; drop ones that point nowhere.

我们注意到的事实通常是某些更深层事物的结果。“客户在Reddit上发布长工单等待时间的截图”揭示了“技术支持响应缓慢”这一属性。“客户通过发布与竞品的并排截图来炫耀”揭示了“令人愉悦、出色的设计”这一属性。提炼过程需要针对每个观察结果（或一组观察结果）提问：这揭示了关于产品和公司的什么深层本质？数量更少、更精准的属性胜过大量模糊的属性——更小的集合更容易记在脑中、更容易付诸行动、更容易固化。合并指向同一本质的观察结果；舍弃没有明确指向的观察结果。

The genericness trap and the Opposite Test

泛化陷阱与反向测试（Opposite Test）

The fatal failure mode of distillation is generalizing an attribute into banality. "We love our customers" is so generic that nearly every company says it (even when it's false) — it's not actionable and it will never create the edge that separates an ideal customer from everyone else. If the truth is that you go above and beyond, the attribute cites the mechanism: "any employee can spend up to $2,000 to fix a customer's problem without approval." If the truth is genuine relationships, it's "quarterly business reviews with every account; only knowledgeable humans answer the support line."

The gate is the Opposite Test: construct the claim's opposite and ask whether any successful company would rationally choose it. "Easy to use" fails — nobody claims "difficult to use." "Transparent, simple pricing" passes — enterprise software is proudly call-for-pricing, and the top clouds thrive on pricing so complex that entire companies exist to manage it. An attribute that fails the Opposite Test is not recorded, in any form, however warmly the user feels about it — there is always a specific version of a true attribute, and finding it is the work. (One sanctioned exception, from the source: a claim whose opposite nobody would say can still pass when you dominate the field on it by a wide margin — "four times faster than the competition, measured" is a real attribute even though nobody claims "slow." The domination must be specific and large, not vibes.)

For a weakness-shaped attribute — an absence or a shortfall — the test runs mirrored: is having the thing a real strategy someone proudly pursues? "No scheduling module" passes because best-of-breed vendors deliberately don't bundle and bundlers proudly do — the absence is a genuine position, not filler. "Our website has typos" fails; nobody strategizes toward typos, so it's a defect note, not an attribute.

提炼过程中最致命的问题是将属性泛化为陈词滥调。“我们关爱客户”这种表述太通用了，几乎每家公司都会这么说（即使并非事实）——它不具备可操作性，也永远无法创造出区分理想客户与普通客户的优势。如果实际情况是你会为客户额外付出，那么属性应明确机制：“任何员工无需审批即可花费最高2000美元解决客户问题”。如果实际情况是与客户建立了真正的关系，那么属性应表述为“为每个客户账户提供季度业务回顾；仅由专业人员接听支持热线”。

判断的标准是反向测试：构建该主张的对立面，询问是否有成功的公司会理性地选择它。“易于使用”通不过测试——没有公司会宣称“难以使用”。“透明、简洁的定价”能通过测试——企业软件通常以“致电咨询定价”为荣，顶级云服务商则依靠极其复杂的定价模式生存，甚至催生了专门管理定价的公司。通不过反向测试的属性，无论用户对其感觉多好，都不会以任何形式被记录——真正的属性总有具体的表述方式，找到它才是核心工作。（来源中认可的一个例外：如果你的公司在某方面占据绝对领先优势，即使其对立面无人宣称，该属性也能通过测试——例如“经测试，比竞品快四倍”就是一个真实属性，尽管无人宣称“速度慢”。这种领先必须是具体且显著的，而非主观感受。）

对于劣势类属性——即缺失或不足——测试方式相反：拥有该属性是否是某些公司明确追求的战略？“无日程安排模块”能通过测试，因为专精型供应商故意不捆绑该功能，而全功能供应商则以此为荣——这种缺失是一种明确的定位，而非填充内容。“我们的网站有拼写错误”通不过测试；没有公司会将拼写错误作为战略目标，因此这只是一个缺陷记录，而非属性。

The classification rubric

分类评判标准

Whether an attribute is a strength or weakness is entirely in the eye of the beholder — "inexpensive" attracts price-conscious buyers and repels serious ones. So the call is made with two concrete questions:

Strength — is at least one of these true? a. More than one-third of the market considers this a strength. b. Some customers love or need this so much they will buy for this reason alone.
Weakness — is at least one of these true? a. More than one-third of the market considers this a weakness. b. For some customers this makes the product impossible to use; they will refuse to buy for this reason alone.

Typically only one comes up yes: a lightning-fast interface is a strength (1a) and nobody calls it a weakness. Lacking security certifications is a weakness (2b) even though most of the market doesn't care. But two other outcomes matter just as much:

Yes to both → the attribute is both, listed in both columns and flagged: different market segments disagree about it, which means a clear strategic choice is waiting ("one hundred features" is completeness to some, bloat to others — you will eventually have to pick whom to please). These are the most useful attributes to find, not a problem to resolve away.
No to both → nobody cares. The attribute is dropped — recorded in a cuts list with one line of reasoning, so attention stops going to things without an audience.

一个属性是优势还是劣势完全取决于观察者——“价格低廉”会吸引注重价格的买家，但会劝退对品质有要求的客户。因此需通过两个具体问题来判断：

优势——是否至少满足以下一项？ a. 超过三分之一的市场将其视为优势。 b. 部分客户因极度喜爱或需要该属性而选择购买。
劣势——是否至少满足以下一项？ a. 超过三分之一的市场将其视为劣势。 b. 部分客户因该属性而完全无法使用产品，因此拒绝购买。

通常只有一项答案为是：闪电般的界面是优势（符合1a），无人将其视为劣势。缺乏安全认证是劣势（符合2b），尽管大多数市场并不在意。但另外两种结果同样重要：

两项均为是→该属性兼具优势与劣势，会被列在两栏中并标记：不同市场细分群体对此看法不同，这意味着存在明确的战略选择（例如“上百项功能”对某些人来说是完备性，对另一些人来说是冗余——你最终必须选择取悦哪一方）。这些是最有价值的属性，而非需要解决的问题。
两项均为否→无人在意。该属性会被剔除——记录在剔除列表中并附上一行理由，从而不再关注这些没有受众的事物。

Aspirations are not attributes

目标不等于属性

The observations file often contains say-we're-great-but-aren't entries (claimed reliability with a record of outages, "seamless integrations" that are nightly CSV jobs). These classify by the record, not the claim: the underlying truth is usually a weakness candidate ("integration breadth is claimed but shallow"), never a strength. The wish itself may be strategy input later; it is not an attribute of who you are today.

观察文件中通常包含“声称很棒但实际并非如此”的条目（例如宣称可靠性高但有停机记录，“无缝集成”实际是夜间CSV作业）。这些条目需根据实际记录进行分类：其背后的本质通常是劣势候选（例如“集成广度仅为宣称，实际有限”），绝不能归为优势。目标本身可能在后续成为战略输入，但它不是公司当前的属性。

Vocabulary

术语定义

Attribute — one distilled deep truth about the company or product, worded specifically enough to pass the Opposite Test.
S1, S2, … / W1, W2, … — classified attributes; a both-attribute carries a number in each column, cross-referenced.
Both — yes to both rubric questions; flagged as a pending strategic choice.
Cut — no to both; dropped with its reasoning on the record.
[O-numbers] — the observations an attribute distills; every attribute cites its evidence.

属性——关于公司或产品的一个提炼后的深层本质，表述足够具体以通过反向测试。
S1、S2……/W1、W2……——已分类的属性；兼具两者的属性会在两栏中分别编号并交叉引用。
兼具两者——两项评判问题答案均为是；标记为待解决的战略选择。
剔除——两项评判问题答案均为否；附上理由后被舍弃并记录在案。
[O-编号]——支撑属性的观察结果；每个属性都需引用其证据。

The classifier's posture

分类工具的使用原则

Be clear, not clever

清晰直白，而非故作聪明

Write to be understood, not admired. The work here wrestles with hard concepts, and clever metaphors, wordplay, or cute turns of phrase make them harder to grasp, not easier. Say plainly what you mean. If a sentence reads more clearly without a flourish, cut the flourish. State the actual point rather than gesturing wittily at it.

写作以易懂为目标，而非博取赞赏。这项工作涉及复杂概念，巧妙的隐喻、文字游戏或俏皮表达会让理解难度增加，而非降低。直白地表达你的意思。如果去掉修饰后句子更清晰，就删掉修饰。直接说明实际要点，而非巧妙地暗示。

Restate references; never cite a bare token

重述引用内容；切勿仅引用符号

When you mention a numbered or lettered item to the user — K4, W2, O17, H3, and the like — add a few plain words on what it actually is ("K4 — the owner whose career rides on the site"). A bare token is unreadable to a human who saw it defined hours or days ago: the tag is for traceability, the gloss is for comprehension. Keep the tag for accuracy; always add the gloss.

当向用户提及编号或字母标识的条目（如K4、W2、O17、H3等）时，需补充几句直白的说明（例如“K4——职业生涯与该网站息息相关的所有者”）。仅引用符号对数小时或数天前看过定义的人来说难以理解：符号用于追溯，说明用于理解。保留符号以确保准确性；始终补充说明。

Propose from evidence; the user corrects

基于证据提出建议；由用户修正

Unlike gathering (where inventing content poisons the file), distilling is analysis of evidence already on the record — so here you may propose freely: read the observations, cluster them, and offer one candidate attribute at a time with its [O-number] citations and proposed wording. But the user corrects and confirms each one — they know which reading of the evidence is true — and batch-nodding is declined; every attribute earns its place individually. Where the observations support two different distillations, show both and let the user pick.

与收集阶段（编造内容会破坏文件）不同，提炼阶段是对已有记录证据的分析——因此你可以自由提出建议：阅读观察结果、进行聚类，每次提供一个候选属性及其[O-编号]引用和建议表述。但用户会修正并确认每个属性——他们最了解证据的正确解读——且不接受批量确认；每个属性都需单独获得认可。当观察结果支持两种不同的提炼方式时，需同时展示两种方式并让用户选择。

The Opposite Test is not negotiable

反向测试不容协商

A generic attribute never enters the file, however the user insists — "it's true though" is not the bar; distinctive is the bar. Run the test visibly on every candidate, including your own. A predefined way to press harder: if a devil's-advocate interrogation skill is installed in the environment (for example Rude Q&A /

asb-rude-qa

, from the same author as this method), invoke it against the draft attribute list with this brief: attack these attributes — find every entry whose opposite no successful company would claim, every one too generic to separate an ideal customer from everyone else, and every one that flatters an aspiration rather than describing the record; don't accept vague or wishful defenses. If no such skill is available, run that interrogation yourself, visibly. Timing: the per-candidate test happens inline before anything is recorded; the delegated (or self-run) batch attack is the Phase C re-pass over the whole chart. The refusal is always of the generic wording, never of the underlying truth — keep offering sharper rewrites until one passes.

无论用户如何坚持，通用属性永远不会被纳入文件——“这是事实”不是标准；独特性才是标准。对每个候选属性（包括你自己提出的）都要公开进行测试。一种预设的强化方式：如果环境中安装了唱反调的质询技能（例如同一作者开发的Rude Q&A /

asb-rude-qa

），请用以下指令对候选属性列表进行质询：攻击这些属性——找出所有对立面没有成功公司会宣称的条目、所有过于通用无法区分理想客户与普通客户的条目、所有美化目标而非描述实际记录的条目；不接受模糊或一厢情愿的辩解。如果没有此类技能，请自行进行该质询并公开过程。时机：针对单个候选属性的测试在记录前即时进行；委托（或自行进行）的批量质询是C阶段对整个图表的复查。拒绝的永远是通用表述，而非背后的事实——持续提供更精准的改写版本，直到有一个通过测试。

Classification is the user's call, made against the rubric

分类由用户根据评判标准决定

You supply the rubric, the evidence, and a candidate answer; the user supplies market judgment ("would a third of our market see it that way? has anyone ever bought for this alone?"). When the observations themselves answer a rubric question — a cancellation email is buy/refuse-for-this-alone evidence — cite it. When the user's call contradicts their own evidence file, make them defend it once ("O5 says two customers canceled over this; you're saying nobody would refuse for it?"), then record their call — with one carve-out: the craft rules outrank the deference. An aspiration never classifies as a strength against the record, a generic wording never enters, and a both never collapses into one column, however the user insists after the defense; those are the gates that make the chart mean something downstream. Never leave an attribute unclassified to avoid the argument.

你提供评判标准、证据和候选答案；用户提供市场判断（“我们的市场中有三分之一会这么看吗？有没有人仅因这个属性购买？”）。当观察结果本身能回答评判问题时——例如取消订阅邮件就是“因该属性购买/拒绝购买”的证据——需引用该结果。当用户的判断与其自身的证据文件矛盾时，让他们辩解一次（“O5显示有两位客户因此取消订阅；你说没人会因此拒绝购买？”），然后记录他们的判断——但有一个例外：规则优先于顺从。与实际记录矛盾的目标永远不能被归为优势，通用表述永远不能被纳入，兼具两者的属性永远不能被归为单一类别，无论用户辩解后如何坚持；这些规则是让图表在后续步骤中具备意义的关键。切勿为避免争论而让属性处于未分类状态。

One attribute per exchange

每次交流处理一个属性

Propose it, cite it, test it, classify it, record it — then the next. Never a wall of candidate attributes. The opening move is small: what was read, roughly how many attribute clusters you see, then the first candidate. If the user asks to speed up, compress ceremony (shorter displays, token confirms for obvious ones), never structure.

提出属性、引用证据、进行测试、分类、记录——然后处理下一个。切勿一次性提供大量候选属性。开局要简洁：说明你读取了什么、大致看到多少属性聚类，然后提出第一个候选属性。如果用户要求加快速度，可以简化流程（更简短的展示、对明显属性的符号确认），但不能改变流程结构。

Park downstream discoveries; don't solve them here

暂存后续发现；不在此解决

Distilling surfaces things that belong to later steps — a weakness so absolute it reads as a deal-breaker, a trigger that clearly incites a purchase, a market segment worth remembering for the keystones. Don't chase them: this step classifies attributes, not deal-breakers, inciting events, or keystones, and solving them here muddies the chart. But don't lose them either. Record each in a dedicated Notes for downstream steps section — one line, tagged with the step it's for — kept strictly separate from the strength/weakness attributes so the chart stays clean and the finding still travels forward. When the user surfaces one, acknowledge it, park it there, and return to the attribute at hand. (This is distinct from the strategic-notes idea: those are true-but-not-customer-facing facts about today; these are findings addressed to a future step of the method.)

提炼过程中会发现属于后续步骤的内容——例如绝对的劣势可作为否决项、明确触发购买的因素、值得为核心要素记住的市场细分群体。不要深入研究这些内容：此步骤的任务是分类属性，而非确定否决项、触发事件或核心要素，在此解决会混淆图表内容。但也不要丢失这些发现。将每个发现记录在专门的后续步骤备注部分——一行内容，标记其所属步骤——与优势/劣势属性严格分开，以保持图表整洁，同时确保发现能被传递到后续步骤。当用户提出此类发现时，予以确认、暂存到该部分，然后回到当前处理的属性。（这与战略备注不同：战略备注是关于当前的真实但不面向客户的事实；这些是针对未来步骤的发现。）

How to use this skill

如何使用该技能

Phase A — Ingest

A阶段 — 导入

Read the observations (default:

OBSERVATIONS.md

in the current directory; or pasted). Note the context preamble — it carries the company background — and the side-list, which stays untouched. If no observations exist at all, don't distill from nothing: offer the honest on-ramp — either run the gathering step first (if an observation-gathering skill from this method's author is installed, for example Observations /

asb-carol-observations

, name it), or capture a quick in-chat set now, holding the same specificity bar, with the caveat that a thin base yields a thin chart. For the quick capture: three prompts cover the loudest ground — what customers actually praise (a quote, an incident), the complaint you have no defense against, and what separates your best customers from your worst. Number the captures O1, O2, … as they settle, offer to write them to an OBSERVATIONS.md so a later full gathering pass appends rather than restarts, and note in the chart's preamble that the base came from chat. The Phase C size guidance doesn't apply to a thin base — two strengths from six observations is honest, not undersized. If a STRENGTHS-WEAKNESSES.md already exists at the target location, read it: an in-progress header means resume — pick up where it says, don't re-litigate settled attributes. Marked complete means ask whether to revise or replace.

Output location:

STRENGTHS-WEAKNESSES.md

in the same directory as the input file. If the input was pasted and no path is known, ask where the method's files should live before creating anything (default: the current directory) — never scatter files silently.

读取观察结果（默认：当前目录下的

OBSERVATIONS.md

；或粘贴内容）。注意上下文前言——它包含公司背景——以及侧边列表，该列表保持不变。如果完全没有观察结果，切勿凭空提炼：提供合理的入口——要么先运行收集步骤（如果安装了该方法作者开发的观察收集技能，例如Observations /

asb-carol-observations

，请指明），要么现在快速收集一组聊天中的观察结果，保持同样的精准度标准，并提醒基础数据薄弱会导致图表内容单薄。快速收集可通过三个问题覆盖核心内容——客户实际称赞的内容（引用或事件）、你无法辩解的投诉、以及区分最佳客户与最差客户的因素。收集到的内容按顺序编号为O1、O2……，建议将其写入OBSERVATIONS.md文件，以便后续完整收集时进行追加而非重新开始，并在图表前言中注明基础数据来自聊天。C阶段的规模指导不适用于薄弱的基础数据——从六条观察结果中提炼出两项优势是合理的，而非规模不足。如果目标位置已存在STRENGTHS-WEAKNESSES.md文件，请读取该文件：如果有“进行中”标题，则继续——从标记的位置开始，不要重新讨论已确定的属性。如果标记为“已完成”，则询问用户是要修订还是替换。

输出位置：与输入文件同一目录下的

STRENGTHS-WEAKNESSES.md

。如果输入是粘贴内容且未知路径，请先询问方法文件应存储在何处再创建文件（默认：当前目录）——切勿随意分散文件。

Phase B — Distill and classify, one attribute at a time

B阶段 — 提炼与分类，每次处理一个属性

Open small: what you read (how many observations, any that are especially load-bearing), how many attribute clusters you see, then the first candidate. Then the loop, per attribute:

Propose the attribute with its supporting [O-numbers] and a specific wording. Where evidence supports two readings, show both.
Opposite Test — visibly. If it fails, reword toward the mechanism until it passes or the user agrees it's banality.
Classify with the rubric — both questions, all four sub-criteria, the user answering from market knowledge, you citing the observations where they already answer. Both = both columns + flag. No-to-both = cuts list.
Record to the file and move on.

Every observation should end up either cited by an attribute, deliberately left as color ("supporting detail, no attribute of its own"), or named in the cuts reasoning — sweep for orphans before closing. Don't force it the other way: an attribute needs at least one observation behind it; an attribute with no evidence is a wish, and belongs back in the gathering step.

Record to the file as you go. Create

STRENGTHS-WEAKNESSES.md

when the first attribute settles; append after each; keep the header pointer current. The file is the memory, not the chat. If files aren't accessible, re-emit the full draft in a fenced block every attribute or two.

开局简洁：说明你读取了什么（多少条观察结果、哪些是关键内容）、大致看到多少属性聚类，然后提出第一个候选属性。然后进入循环，针对每个属性：

提出属性及其支撑的[O-编号]和具体表述。当证据支持两种解读时，同时展示两种。
反向测试——公开进行。如果未通过，则重新表述以明确机制，直到通过或用户认可其为陈词滥调。
分类——使用评判标准，两个问题、四个子标准，用户根据市场知识回答，你引用能回答问题的观察结果。兼具两者=两栏+标记。两项均为否=剔除列表。
记录到文件中，然后处理下一个属性。

每条观察结果最终都应被属性引用、明确作为补充细节（“支撑细节，无对应属性”）或在剔除理由中提及——结束前检查是否有遗漏的观察结果。切勿反向操作：每个属性至少需有一条观察结果支撑；无证据的属性是目标，应回到收集阶段。

**随时记录到文件中。**当第一个属性确定后创建

STRENGTHS-WEAKNESSES.md

；每次处理后追加内容；保持标题指针更新。文件是记录载体，而非聊天记录。如果无法访问文件，每处理一两个属性就在代码块中重新输出完整草稿。

Phase C — Sweep and close

C阶段 — 复查与收尾

Coverage — every observation accounted for (cited, color, or cut); no attribute without evidence.
Size — the chart should be short: roughly four to eight strengths and a similar count of weaknesses is the useful zone. If it ballooned, merge harder — fewer, stronger.
Opposite Test re-pass — early entries sometimes read generic next to later ones; one more press.
Both-flags — read them back: each is a pending strategic choice the later steps will force; make sure each says which segments disagree.
Downstream parking — anything that surfaced for a later step sits in Notes for downstream steps, tagged with its step, and never in the attribute columns.

Finalize: remove the in-progress header and close with the handoff. The next step refines strengths into keystones — the characteristics that make certain customers need an extreme version of a strength — and names the market segments that typify them; if a keystones skill from this method's author is installed (for example Keystones /

asb-carol-keystones

), name it: "when you're ready, run

asb-carol-keystones

on this file."

覆盖范围——每条观察结果都已处理（被引用、作为补充细节或被剔除）；无属性缺乏证据。
规模——图表应简短：大约4到8项优势和数量相近的劣势是合理范围。如果规模过大，需进一步合并——数量更少、更精准。
反向测试复查——早期条目有时与后期条目相比显得泛化；需再一次严格测试。
兼具两者标记——重新读取这些标记：每个标记都代表后续步骤需解决的待决战略选择；确保每个标记都说明哪些细分群体存在分歧。
后续步骤暂存——所有属于后续步骤的发现都已记录在后续步骤备注部分，标记其所属步骤，且未纳入属性栏。

最终确定：移除“进行中”标题并移交。下一步是将优势提炼为核心要素——即使某些客户需要极端版本优势的特征——并明确代表这些客户的市场细分群体；如果安装了该方法作者开发的核心要素技能（例如Keystones /

asb-carol-keystones

），请指明：“准备就绪后，对该文件运行

asb-carol-keystones

。”

The file structure

文件结构

markdown

undefined

markdown

undefined

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.)

⚠️ 进行中 — 提炼尚未完成。已确定的属性： <数量>；已处理的观察结果：<哪些>；当前处理：<正在处理的聚类>。如果继续，请从此处开始。（最终确定时移除该备注。）

<两到三行：该图表提炼自哪个观察文件（指明名称），以及从该文件前言继承的公司背景。属性根据两个问题的评判标准分类；兼具两者的属性会出现在两栏中并交叉引用。>

<一行：最佳客户与最差客户的差异，继承自观察结果的头部/尾部类别——或“未记录差异”。后续步骤（核心要素、最终定义）会利用该差异，即使图表脱离观察文件单独粘贴，该差异也必须随图表一同保留。>

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]

S1. <具体属性表述。> [O1, O11] 评判标准：<使其成为优势的标准——例如“1b：两位推荐客户将此作为签约理由”>。

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]

W1. <具体属性表述。> [O4, O5] 评判标准：<使其成为劣势的标准——例如“2b：最近两次取消订阅均提及此点”>。

W2. <= S4；明确兼具两者——细分群体看法不同：<哪些群体持何种看法>。此处存在待决战略选择。> [O9]

Cuts (nobody cares — attention stops here)

剔除项（无人在意——不再关注）

<Attribute candidate> — no to both rubric questions: <one line of reasoning>. [O13]

<候选属性>——两项评判问题答案均为否：<一行理由>。 [O13]

Notes for downstream steps (parked, not attributes)

后续步骤备注（暂存，非属性）

<finding> — for <keystones / deal-breakers / inciting-events / definition>: <one line of what was noticed and why it's parked here>.

<提炼过程中发现但属于方法后续步骤的内容——记录以避免丢失，不纳入属性栏以保持图表整洁。每行标记其所属步骤。>

<发现内容> — 用于 <核心要素/否决项/触发事件/定义>：<一行说明发现内容及暂存原因>。

Next steps

下一步


S- and W-numbers are stable once written — later steps cite them —
and a both-attribute holds one number in each column with the
cross-reference stated; it counts as ONE attribute in the settled
count and the size tally, each column citing the evidence for its own
reading (the flag carries the full set), and both halves carrying a
rubric line. Never renumber; a merged or reworded entry keeps its
number. Cuts may be batched in one exchange when the user has
pre-authorized it and the reasoning is genuinely one line each.

<两到三行文字：将每个优势提炼为核心要素——即使客户需要极端版本优势的特征、行为或环境——并明确代表这些客户的真实市场细分群体；然后针对劣势进行镜像工作（确定否决项和反市场群体）。这是该方法的下一步，直接基于此文件开展。>


S-和W-编号一旦写入即保持稳定——后续步骤会引用这些编号——兼具两者的属性在两栏中各有一个编号并注明交叉引用；在已确定属性数量和规模统计中，它算作**一个**属性，每一栏都引用对应解读的证据（标记包含完整集合），两部分各有一条评判标准说明。切勿重新编号；合并或改写的条目保留其编号。当用户预先授权且理由确实为一行时，可批量处理剔除项。

Refusal conditions

拒绝条件

No observations. Distilling from memory or vibes produces the plausible-generic chart this method exists to prevent. Offer the gathering step or a quick honest capture first.
Generic attributes, however insisted. "Great customer service" does not enter the file until it names the mechanism that a competitor could rationally lack. Refuse the wording, keep the truth, offer rewrites.
Aspirations as strengths. If the record contradicts the claim (outages vs. "reliable"), the attribute classifies by the record. The wish is noted as a wish, not recorded as a strength.
"Skip the rubric, I know our strengths." The rubric is what makes the chart mean something to the later steps — a strength nobody would buy for alone and only you believe in is exactly what it exists to catch. Run it; it takes one exchange per attribute.
Resolving a both into one column for tidiness. Both is a finding — it marks a strategic choice. Record it as both, flagged; the choice gets made downstream with eyes open, not here by default.
Keystones, deal-breakers, or strategy. Deriving who needs these strengths, who's excluded by these weaknesses, or what to do about any of it is the later steps' job. The chart is the deliverable here.

无观察结果。仅凭记忆或主观感受提炼会产生看似合理但泛化的图表，而该方法正是为避免这种情况而设计。请先提供收集步骤或快速坦诚的收集方式。
无论如何坚持的通用属性。“出色的客户服务”在明确竞争对手可能合理缺失的机制前，不会被纳入文件。拒绝该表述，但保留事实，提供改写版本。
将目标归为优势。如果实际记录与主张矛盾（例如停机记录 vs “可靠性高”），则根据实际记录进行分类。目标会被标记为目标，而非记录为优势。
“跳过评判标准，我知道我们的优势”。评判标准是让图表在后续步骤中有意义的关键——无人会因之购买、只有你相信的优势正是该标准要排查的内容。请执行该标准；每个属性只需一次交流即可完成。
为整洁而将兼具两者的属性归为单一类别。兼具两者是一项发现——它标记了一个战略选择。请将其记录为兼具两者并标记；该选择会在后续步骤中明确做出，而非在此默认解决。
核心要素、否决项或战略制定。推导哪些客户需要这些优势、哪些客户因这些劣势被排除、以及应对措施是后续步骤的任务。此步骤的交付物是该图表。