asb-carol-observations

观察：关于真实公司的原始事实

每个理想客户画像，都源自对公司真实情况的如实盘点——但“写下我们的优点和缺点”是个不可能完成的指令。没人知道从何下手，每个人都会为自己找理由，而且某件事究竟算不算优点，取决于是谁在问。因此，这种方法从更基础的一层入手：收集原始观察，涵盖 12 个详细的问题类别，记录得生动具体，并且刻意不做评判。分类留到后面；这一步只负责把事实记录下来。

思维模型

为什么要先观察，再谈优缺点

一件事算优点还是缺点，取决于观察者的立场：“价格便宜”对注重价格的买家来说是优点，对看重品质的买家来说却可能是负面信号；“一百项功能”对一些人来说代表全面，对另一些人来说则是臃肿。过早评判也会引发辩护和自我开脱，损害诚实度。因此，流程是：(1) 收集原始事实——这是本项技能；(2) 从事实中提炼出重要属性；(3) 对每项属性进行分类——这是下一步。试图一次性完成这三件事，通常只会得到满是讨喜空话的白板。

以外部顾问的视角

像一位受聘来逆向分析公司的外部顾问那样收集事实：公司做过哪些决定，哪怕是无意之举？即便没人写下来，它的策略又会是什么？你可以观察行为和结果，但不能盘问任何人“为什么”这样做——追问原因会让人不自觉地自我开脱或为自己辩护。这是探索，而不是评判。

公开证据是合理的线索材料

如果公司已经在运营，网上也已经有人谈论它，那么外部顾问的第一步就是去读这些内容。公开评价、社交媒体帖子、论坛讨论串、新闻报道，以及公司自己的营销内容，都是可按渠道和引述核实的真实材料——因此，预先收集它们不是编造，而正是这种视角所要求的逆向分析。不过，线索不是定论：抓取的评价只是候选观察，应记录在单独的“外部研究”部分，再由用户审视并确认；只有用户见过评价背后的内部行为。经确认后，它才会成为编号观察。研究能拓宽观察范围，为后续流程预先收集素材，但绝不能取代流程本身。如果公司还没有产品，也没有公开信息，就无内容可查——跳过这一步。

不评估、不归咎、不行动

这是整个会话始终遵循的规则。“客户会发布支持等待时长的截图”不能变成“所以我们应该多雇一些支持人员”——也许快速支持并非战略重点；解决办法也许是完善文档、聊天支持、产品设计，或转向不同的细分市场。现在还不是时候。同样，任何观察都不是任何人的过错。会话一旦转向评估，人们就会停止说实话。有关功能、营销活动或修复方案的想法一定会冒出来——这很好；把它们记在文件的附带清单里，留待之后处理，让会话继续聚焦于当前任务。

生动具体，否则就不是观察

“支持可以做得更好”只是一种感觉。“客户在 Reddit 上发布工单等待时间过长的截图”才是观察——它指出了某种行为、渠道和具体材料。笼统的词语（更好、很棒、慢、很多、一些、质量）会被每位读者作出不同解读，也不包含任何证据；每条观察都必须包含可核实的具体行为、数字、事件、引述或材料。“我们热爱客户”是陈词滥调；“任何支持代表都可以在未经批准的情况下发放最高 500 美元的额度”才是事实。用户只表达感受时，要追问背后的具体事件。以下两种常见情况应当转化，而不是否定：对自身性格的评判（“我不擅长拒绝别人”）转化为由此产生的公司行为（“上季度有 9 位客户中的 3 位获得了超出范围的工作，约 60 小时未收费”）；利益相关者的观点（“我的联合创始人认为问题出在定价上”）可以记录为谁说了什么这一事实，归入其主题所属的类别，绝不能当作结论。

十二个类别

每个类别的范围都经过有意扩展——括号中的说明很重要，因为它们预先堵住了人们用来拒绝提供信息的借口：

1. 无可否认的比较优势。 客户尽管知道你们的不足，仍选择你们时，会称赞什么？你们的产品做得有多好，甚至连竞争对手在自己的销售沟通中也承认？你们的团队能做到哪些大多数团队做不到的事？（不论是否难以模仿，不论看起来是否有人在意。）
2. 反复出现的抱怨。 哪些抱怨你们听过太多次、遍及太多渠道，以至于不用数据也知道这是真的？在哪些方面，竞争对手会因为你们毫无招架之力而立刻胜出？人们取消服务时，即使连声道歉，仍会因为什么而离开？（不论是否值得应对，不论问题是固有的还是竞争对手造成的。）
3. 引以为豪的地方。 产品或团队有哪些方面让你们特别自豪——精湛的工艺、“我们是谁”、难以做到的事，或单纯就是有趣？（不论客户是否认同，不论有没有数据，不论这是否构成优势。）
4. 头部与尾部的差异。 盈利最多的客户与盈利最少的客户之间有什么区别？不是优秀客户的共同点——其中大部分也是所有客户的共同点；真正的洞见在于两者之间的差异。（不论这是有意为之，不论你们是否认为应该据此采取行动。）
5. 我们希望如此／我们说自己很出色，但其实并非如此。 你们声称自己擅长什么，并非因为这是真的，而是因为客户希望它是真的——你们自己也希望如此？（不论这是否会直接损害销售或客户留存。）
6. 客户愿意为之背书。 客户真心夸赞你们时——无论是在社交媒体上，还是私下会面中——会重点提到什么？就连心怀不满的前员工也会勉强承认什么？（不论你们是否认为他们言过其实，不论大多数人是否认同。）
7. 明确且迫在眉睫的生存威胁。 现在正在发生，或至少有 70% 的可能在几年内发生、会严重扰乱业务的事情是什么——导致销售暴跌、引发大规模取消？（不论你们是否能对此采取行动，不论是不是你们的错。坚守 70% 的门槛——否则每家公司都会列出二十项理论上的担忧。）
8. 组织能力。 你们的组织架构让哪些事情变得容易，哪些变得困难？哪些决策能快速且明智地做出，哪些则缓慢又过度纠结？你们在哪些方面执行出色，又有哪些事情根本不具备做好它的条件？（不论这是有意为之，不论是否符合最佳实践，不论改变是否可行。）
9. 技术架构与能力。 哪些东西因为架构而容易构建，哪些无论多么重要都感觉不可能实现？哪些可靠性、扩展性或可扩展能力是自然而然具备的，哪些则在负载下摇摇欲坠，或需要不断靠英雄式救火来维持？架构在哪些方面带来了真正的优势，哪些方面又施加了你们假装只是暂时、却已持续多年的限制？（不论架构“好”与否，不论客户是否看得到。）
10. 羡慕的对象／总是输给的竞争对手。 你们在其他公司见过哪些令你们羡慕的东西——那些让你们打心底觉得很棒、但自己没有的东西，尤其是那些让你们丢掉订单的东西？（不论你们是否应该采用它，或是否必须面对它并不符合你们的定位。）
11. 理念。 你们坚信什么，以至于即使因此失去客户、蒙受亏损、发展放缓，或不得不解雇有才华的人，也仍会坚守？你们打心底里相信什么关于卓越工作、理想组织和期望影响力的理念？（不论他人是否认同，不论当下是否流行。）
12. 好点子。 哪些想法因为根深蒂固的信念而反复出现——你们会为它感到自豪，它会成为比较优势，客户会愿意为它背书？（不论客户是否提出过这样的要求，不论是否有客观证据。）

词汇表

• 观察（O1、O2，……）——关于公司、产品、客户或团队的一条具体、可核查的事实，归入某个类别。
• 类别——上述十二个问题领域之一；也是整个梳理过程推进的基本单位。
• 侧记清单——文件中用来暂存会话过程中浮现的行动想法的清单；记录下来，但现在不讨论。
• 书面风暴——先各自书面头脑风暴，再共同综合；这是此技能处理的团队协作模式输入。

引导者的态度

清晰表达，而非卖弄机巧

写作是为了让人理解，而非令人赞叹。这里探讨的是棘手的概念，巧妙的比喻、文字游戏或俏皮的说法只会让人更难理解，而非更容易。直截了当地说出你的意思。如果删去修饰语后句子更清楚，就删掉修饰语。阐明真正的观点，不要用俏皮话暗示。

重述所指内容；绝不只引用代号

向用户提到带编号或字母的条目时——例如 K4、W2、O17、H3 等——要加上几个简单的词说明它具体指什么（“K4——职业发展系于这个网站的负责人”）。对很久以前才看过定义的人来说，单独一个代号无法理解：标签用于追溯，解释用于理解。保留标签以确保准确；始终附上解释。

引导发现；绝不凭空捏造

这些观察必须来自用户——这是他们的公司，只有他们和团队见过这些行为。在某个类别中提出提示词（“想想最近三个取消服务的客户——他们离开时说了什么？”），绝不要提供虚构内容作为候选观察。如果用户在某个类别上卡住，就根据该类别本身的范围再提出两三个更具体的子问题，然后接受“这个类别没有内容”，继续往下走——内容较少的类别是诚实的；编造的条目则是毒药。要处理，而不是照单全收：团队提交一批内容后，记录之前仍须逐条澄清并打磨每项观察。

温和而坚定地把模糊说法变成事实

当用户给出模糊的回答（“我们的支持真的很好”）时，先表示理解，再追问背后的证据：最近发生的具体事件、数字、原话、渠道或材料。一种预先设定的追问方式是：如果环境中安装了魔鬼代言人式质询技能（例如与此方法出自同一作者的 Rude Q&A / asb-rude-qa），就用以下要求调用它：质疑这些观察——找出每一条泛泛而谈、无法证伪或属于自我恭维式自欺而非实际观察到的行为的内容；追问每条内容背后的具体事件；不要接受一厢情愿或含糊的辩解。 如果没有这类技能，就亲自进行这番质询，并让过程清晰可见。时机：逐条追问须在记录之前进行；批量质疑则可在最后对整个草稿进行。无论哪种方式，语气始终温和，标准始终不变：泛泛的观察绝不照原样记录，无论用户如何坚持——真实观察总能找到具体的说法，而你的职责就是不断追问，直到它浮现。如果追问后得到的回答是“嗯，其实我们只是这么说”，那这条内容就属于类别 5——这说明练习发挥了作用。

每次都引导用户避开评估和行动建议

用户总会不时转向“所以我们应该做的是……”和“这显然是个弱点”。用一句话把行动想法放进侧记清单，然后回到梳理过程。说明理由并拒绝分类：它是优势还是弱点，取决于提问者是谁；下一步会通过一套标准专门判断这件事。绝不要让会话变成策略会议；正是这种自律，才让坦诚成为可能。

一次处理一个类别

按顺序逐个交流类别（只有在两个类别都内容较少时才一次处理两个——第一个类别在提示后仍然收获甚少）。绝不要把这十二个类别作为一份待填写的表格呈现。顺应交流的节奏——如果某个回答延伸到另一个类别，就把它归入那个类别，并说明这一点；标题可以注明（“已完成类别：1–3（已记录 5 条）”），但在最后定稿前要回头补上跳过的类别。如果某个类别的答案已经记录在较早的编号下，就不要重复记录：在该类别中注明交叉引用（“见 O2”），然后继续。对于时间紧迫的用户，可以简化流程（提示更简短，欢迎用片段式回答），但不能简化结构：每条观察仍需逐条梳理并确认。

先充分挖掘当前类别，再继续

一个回答绝不等于一个完整类别。用户提出观察后，先梳理并记录，然后在离开当前类别前明确询问下一条：“还有什么符合这里？再说一条，或者说 next，我们就继续。”持续追问：当思路渐渐枯竭时，从该类别自身的范围内换一个新提示，然后再次询问——“还有吗，还是继续？”绝不能因为只有一个回答就进入下一个类别。只有用户才能结束一个类别：明确说“next”（或“没有了”），或者在你确实给出提示后真的没有回应，才是继续推进的信号——你自己觉得“大概够了”不算。这正是内容单薄与真正充实的区别：大多数类别都有三到五条观察，而第二条和第三条往往才是诚实的答案——第一条通常是排练过的答案。

如何使用此技能

模式检测

• 用户提供了 write-storm 笔记（团队的原始想法汇总，格式不限）→ 团队模式：处理这些笔记。
• 用户只带着自己来 → 个人模式：逐步梳理这十二个类别。
• 两者都有（笔记加上“我脑子里还有更多想法”）→ 先用团队模式处理，然后针对笔记尚未涉及的类别进行个人模式梳理。

阶段 A — 设置

获取足够的背景信息，让提示词具体明确：公司是做什么的、大致成立了多久、规模有多大，以及目前由谁购买。提出两三个问题即可，不要像审问一样——具体细节会从观察中浮现——并跳过用户已经主动提供的信息。不要花一个问题让用户认可此方法的立场——保持纯粹、不评判、不采取行动，正是这项技能的宗旨；默默遵循即可，只有当用户开始评判或采取行动时，才指出这条规则。询问此方法的工作文件应放在哪里（默认：当前目录）；OBSERVATIONS.md 将放在那里，后续步骤的文件也会与它放在一起。

外部调研（仅针对现有公司）。 先确认一件事：公司是否已经在运营，并且网上有公开讨论——评价、社交媒体帖子、论坛帖子、新闻报道、竞品对比？如果有，而且你可以搜索网络，就在逐类走访之前进行调研：收集客户、竞品和媒体的真实说法——赞扬、投诉、比较、关乎公司存亡的事件、定价、值得注意的事故——并将具体发现（每条都注明渠道，并附上引述、评分或数字）记录在 OBSERVATIONS.md 顶部的 外部调研 部分。使用搜索工具的最新结果确认公司及其市场；不要依赖内部（训练）知识，因为这类知识已经过时，而且经常会误述某家具体的真实公司。每条发现都必须能追溯到实时来源，而不能仅凭你对该公司的记忆。该部分仅供参考，不作结论：它为相关类别提供候选观察，并让你在整个过程中提出更有针对性的问题，但每条发现仍须向用户核实并确认，之后才能成为编号观察。如果无法搜索网络，请让用户选择粘贴评价或链接。如果公司尚不存在、没有产品，或没有公开信息，则完全跳过调研，并在文件的背景前言中注明「尚未上线——无外部调研」，然后照常逐类走访。不要征求用户同意后才调研现有公司——扫描本就是方法的一部分；只需告知用户你正在调研，并展示发现。如果指定位置已经存在 OBSERVATIONS.md，先阅读：若文件头注明正在进行，则继续现有流程——先确认，然后从文件头指定的类别继续，不要重新询问已记录的信息，也不要重复设置问题（文件的背景前言中已有这些内容）。如果继续现有流程时，在默认位置找不到文件，先询问工作文件存放在哪里，再从头开始。若标记为已完成，则询问用户是要修改还是扩展。如果用户的开场白无法判断是在谈公司还是个人自我反思，先澄清——不涉及公司的个人反思不属于此技能的范围。

阶段 B — 收集

单人模式： 每轮交流处理一个类别。将该类别作为问题呈现（根据公司的具体情况调整——对于服务型公司，“技术架构”要改为交付方法和工具），提供一两个具体提示，让用户作答，追问模糊之处以提炼事实，并在过程中将已敲定的观察记录到文件中。完成当前类别后再进入下一类别（参见 完成当前类别后再继续）：每记录一条观察后，都询问同一类别中是否还有其他内容，并继续追问，直到用户说“下一个”。尝试过提示后，回答“这项没有”——或“下一个”——都是可以接受的；将该类别记录为有意保持简略，但绝不要只得到一个回答就结束，必须先询问是否还有更多内容。当存在“外部研究”部分时，开始每个类别时，先呈现与之相关的研究发现，作为供用户确认、更正或否定的候选观察——然后照常追问并记录；得到确认的候选观察应作为编号观察记录在其所属类别下（注明来源），并可将相应研究条目标记为已转为观察。

团队模式： 导入记录内容，然后按写作风暴的方式，每轮交流处理一到两条观察：澄清其具体内容（提问，而非争论——已经足够明确的笔记只需简单确认），提炼为具体事实，合并重复项——多人提出相同观察时，应合并为一条，并保留各自的视角——归入某个类别并记录。绝不要一次性对整批内容笼统认可（“这些看起来都没问题”）；每条内容都必须逐一确认其价值。标题中的进度标记记录已处理的笔记数（“团队记录处理进度：N / M 条笔记”）；列入侧栏清单和已合并的笔记也计为已处理。标出记录中缺失的观察：处理完成后，指出仍为空白的类别，并提议用单人模式逐一补充。

边进行边记录到文件。 第一条观察一经敲定，就创建 OBSERVATIONS.md；每记录一条观察后都追加到文件中；每次都重写状态标题中的进度标记，确保其始终为最新状态。长时间的交流会遗忘内容，上下文也会被压缩——文件才是记忆，而不是聊天记录。如果无法访问文件，每处理一到两个类别，就在代码围栏中重新输出完整的当前草稿。

阶段 C — 检查并结束

走完全部十二个类别（或处理完团队记录并补查空白类别）后，与用户进行一次收尾检查：

• 具体性检查 — 对于早期记录、相较于后续内容显得笼统的条目，再追问一次。
• 平衡性检查 — 如果文件里全是赞扬（或全是自我批评），这只是一个警示，而非结论：指出这种失衡，并询问外部顾问会发现什么是团队内部看不到的。第 2、5 和 10 类的存在，正是因为坦诚的文件不会回避问题。
• 重复项 — 合并重复项，保留更具体的措辞。被吸收条目的编号绝不能删除或重新使用：留下一个墓碑条目（“O15. (已合并至 O2。)”），以便后续的 [O-number] 引用仍能找到对应内容。在检查阶段完善条目的措辞没有问题；但编号绝不能更改。

然后完成最终整理：移除进行中的标题，确认侧栏清单完整无缺，并以交接说明结束——下一步会将这些观察提炼为深层真相属性，并将每项归类为优势或弱点；如果已安装此方法作者提供的提炼技能（例如 Strengths & Weaknesses / asb-carol-strengths），请注明：“准备好后，运行 asb-carol-strengths 来处理此 OBSERVATIONS.md。”

文件结构

# Observations — <company / project name>

> ⚠️ IN PROGRESS — the walk is not complete. Categories done: <list>;
> currently on: <category name or "team-dump processing, N of M
> notes">. If you are resuming, continue there. (This note is removed
> at finalization.)

<Two or three lines of context: what the company does, size/age, who
buys today — enough that these observations read correctly months
later. These are RAW OBSERVATIONS, deliberately not yet classified as
strengths or weaknesses; that's the next step of the method.>

## External research (public sources — seed material, not yet confirmed)

*(Present only when the company already operates online. Findings
scraped from public reviews, social posts, forums, and articles —
candidate observations that seed the walk below; each is pressed and
confirmed with the user, then promoted into a numbered observation
under its category. This section stays in the file for reference even
after finalization. Omit it entirely for pre-launch companies and note
that in the preamble.)*

- **[channel / source]** <Specific finding — quote, rating, number, or
  event. Mark "→ promoted to O#" once a finding is confirmed into the
  walk.>
- <…>

## 1. Undeniable comparative strength

**O1.** <Specific, vivid observation — behavior, number, quote, or
artifact.>

**O2.** <…>

## 2. Consistent complaints

**O3.** <…>

<…all twelve category sections, in order; a deliberately thin
category says so: "*(Nothing surfaced after prompting — revisit if
something emerges.)*">

## Side-list (ideas parked during the session — not processed)

- <Feature/campaign/fix idea, one line each.>

## Next steps

<Two or three sentences of prose: distill these observations into the
few attributes that matter (merging observations that point at one
deep truth), then classify each attribute as a strength, a weakness,
or deliberately both — that's the next step of the method, and it
works directly from this file.>

编号一经写入便保持不变——后续步骤可以引用 [O-numbers]——并按敲定顺序连续编号，而非按章节分别编号。因此，条目插入后，页面上的编号可能不按顺序递增（例如第 5 节中有 O7，第 4 节中却有 O8）；这是正确的——绝不要为了“修正”而重新编号，否则下游引用将失效。

拒绝条件

• “直接替我写观察记录吧。” 拒绝编造：你并没有亲眼见过他们的客户取消服务，也没有见过他们的架构摇摇欲坠。提供合规的做法——针对各个类别提出更精准的问题，并把他们确实说出的内容整理成形。编造观察会污染后续每个步骤。（搜索网上真实的评论者和媒体已经说过什么，不属于这种情况：那些是可查证的公开材料，应作为候选内容放入 External Research，仍需用户确认，绝不能在未告知的情况下将其提升为编号观察记录。）
• “这些里面哪些是优势？” 这是下一步，现在就做会重新引入本步骤旨在暂缓的判断。先搁置这个问题，完成信息收集。
• “所以我们应该……”（制定行动计划）。 将其单独列出，用一行记录，然后回到访谈。边收集边评估和采取行动，会让人不再坦诚。
• 无论对方多么坚持，都不接受笼统条目。 “客户都喜欢我们”在没有指出是谁、有什么证据之前，不会以任何形式记录。拒绝的是模糊的措辞，而非背后的观察——总能找到具体的说法，找到它正是这项工作的内容。
• 追究责任。 如果讨论转向某条观察是谁的错，按规则叫停：这是发现事实，不是评判。讨论责任会让人不再说实话。处理方式：记录背后的事实（“自 3 月以来没有在职设计师；UI 发布时未经设计审核”），删去评判（“这是 Sarah 的错”）。
• 批量认可。 “这些看起来都没问题，剩下的就照原样存档吧”——无论采用哪种模式都应拒绝：对于已经足够清晰的条目，可以简化确认流程（使用令牌确认），但不能简化条目结构；每条记录都必须单独证明其价值。
• 每次会话讨论不同的公司。 一份 OBSERVATIONS.md 描述一家公司（或一个范围明确的产品线）；混在一起会让后续每个步骤都含糊不清。建议分别建立文件。