在定义理想客户前，如何收集关于公司真实面貌的原始、具体…

当你想弄清理想客户、诚实审视公司、从零做一次优劣势练习时，用十二类问题收集可核查的原始观察并记录到 OBSERVATIONS.md。

适用场景

解决思路

1. 采用外部顾问姿态：像被雇来逆向工程这家公司的外部顾问一样生成事实——它做过哪些决定（哪怕是无意的）、它的战略必然是什么（哪怕没人写下来）；只观察行为和结果，绝不追问任何人“为什么”这么做，因为问为什么会让对方不自觉地合理化或辩护。
2. 先做外部研究（仅限已在运营的公司）：确认公司是否已有公开讨论（评论、社交帖、论坛、新闻、竞品对比）；若有且你能联网搜索，在走查之前先搜集客户、竞品和媒体实际说了什么——赞誉、抱怨、对比、存亡事件、定价、重大事件——并把每条具体发现（附渠道和引语、评分或数字）记入 OBSERVATIONS.md 顶部的 External Research 部分；必须用搜索工具的实时结果确认公司和市场，不得依赖内部（训练）知识；若无法联网，请用户粘贴评论或链接；若公司尚不存在、无产品或无公开曝光，完全跳过研究并在文件前言注明“pre-launch — no external research”；不要请求许可去研究一家已存在的公司，直接告诉用户你在做并展示发现。
3. 若 OBSERVATIONS.md 已存在，先读它：头部显示进行中则确认并从头部指明的类别继续，不重新采集已记录内容，也不重问设置问题；显示已完成则询问是修订还是扩展；若在默认位置找不到文件，先问工作文件放在哪里。
4. 按顺序走十二个类别，每次交流只处理一个类别（仅当两个都很单薄时才合并），绝不把十二类当成一张表单一次性抛出；顺着能量走——若回答溢出到另一类别，就归到那里并说明；在定稿前回到跳过的类别；若某类别的答案已在更早的编号下记录，不要重复，在该类别注明交叉引用（“covered by O2”）后继续。
5. 十二个类别（每类都刻意放宽范围，括号里的说明用来预先堵住人们不说的借口）：1. 不可否认的比较优势——客户不顾你的缺点仍选择你时称赞什么？你的产品强到什么程度连竞品在自家销售电话里都承认？你的团队能做哪些大多数团队做不到的事？（无论是否难以复制、无论是否有人在意。）2. 持续存在的抱怨——你听过多少遍、跨多少渠道、无需数据就知道是真的抱怨是什么？在哪一点上竞品能瞬间取胜因为你毫无防御？人们一边道歉一边取消时离开你是因为什么？（无论回应是否明智、无论问题是内在的还是竞品造成的。）3. 引以为傲——产品或团队中你特别自豪的是什么——精湛工艺、“我们是谁”、难做的事，或只是好玩？（无论客户是否认同、无论有无数据、无论是否是优势。）4. 头尾差异——最赚钱的客户与最不赚钱的客户之间有什么区别？不是最好的客户有什么共同点——那大多是所有人都有的；洞见在差异里。（无论是否有意、无论你是否认为该据此行动。）5. 我们希望/声称很棒，但其实不是——你声称擅长什么，不是因为那是真的，而是因为客户希望它是真的——你也是？（无论是否直接损害销售或留存。）6. 客户主动宣传的——当客户真心夸你时——在社交媒体、私下会面——他们强调什么？连心怀不满的前员工也会勉强承认什么？（无论你是否觉得他们夸张、无论多数人是否同意。）7. 明确且现实的存亡威胁——现在正在发生、或至少有 70% 概率在几年内发生、会严重扰乱业务的事是什么——销售暴跌、大规模取消？（无论你能否做点什么、无论是否是你的错。守住 70% 这条线——否则每家公司都会列出二十个理论上的担忧。）8. 组织能力——你的组织结构让什么变容易、让什么变难？哪些决策快而明智，哪些慢而过度纠结？你在什么上执行卓越，什么上根本没准备好做好？（无论是否有意、无论是否符合最佳实践、无论改变是否感觉可行。）9. 技术架构与能力——因为架构而容易构建的是什么，无论多重要都感觉不可能的是什么？什么可靠性、规模或可扩展性是自然具备的，什么在负载下摇晃或需要不断救火？架构在哪里创造真正优势，在哪里施加你假装是暂时但已持续多年的约束？（无论架构是否“好”、无论客户是否看得见。）10. 羡慕/不断输给竞品——你在其他公司看到并羡慕的是什么——你骨子里觉得很棒但你没有的东西，尤其是让你丢单的？（无论你是否该采纳，还是必须面对那不是你。）11. 理念——你如此坚信什么，以至于即使失去客户、亏钱、拖慢速度或意味着解雇有才华的人，你也会坚守？你对出色工作、你想要的组织、你想要的影响，内心相信什么？（无论他人是否同意、无论是否流行。）12. 好点子——什么想法因根深蒂固的信念而反复出现——你会为它自豪、它会成为比较优势、客户会为它宣传？（无论客户是否在要求、无论有无客观证据。）
6. 把模糊压成事实——温和而持续：当用户给出模糊回答（“我们的支持真的很好”）时，先认可，再追问背后的证据：最近一次具体事件、数字、引语、渠道、实物；若环境里装有魔鬼代言人式审问技能（例如同作者的 Rude Q&A / asb-rude-qa），用它并附上这段简报：攻击这些观察——找出每一条泛泛的、不可证伪的或谄媚式自我欺骗而非观察到的行为的条目；要求每条背后的具体事件；不接受一厢情愿或含糊的辩护；若没有此类技能，就自己可见地做这场审问；时机：逐条追问在记录之前内联进行，批量攻击是定稿前对整份草稿的可选收尾清扫；无论哪种方式，语气保持温和，标准保持固定：泛泛的观察绝不按原样记录，无论用户怎么坚持——真实的观察总有具体的版本，你的工作就是不断追问直到它浮现；若追问后得到“其实我们只是嘴上那么说”，该条目属于第 5 类——这正是练习在起作用。
7. 每次都要挡开评判和行动：用户会不断滑向“所以我们应该……”和“那条显然是弱点”；把行动想法用一行记入 side-list 后回到走查；拒绝分类并说明理由：是优势还是弱点取决于谁在问，下一步有专门的标准来做这个判断；绝不让这场会话变成战略会议——纪律才让诚实成为可能。
8. 记录时生动且具体，否则不算观察：“支持可以更好”是一种情绪；“客户在 Reddit 上贴出工单等待时间很长的截图”才是观察——它点出行为、渠道、实物；泛泛的词（更好、很棒、慢、很多、一些、质量）每个读者理解都不同且不携带证据；每条观察必须包含使其可核查的具体行为、数字、事件、引语或实物；“我们爱我们的客户”是陈词滥调；“任何支持代表无需审批即可发放最高 $500 的抵扣”才是事实；当用户给出情绪时，追问背后的事件；两种常见形态要转化而非拒绝：人格自我评判（“我不擅长说不”）转化为它产生的公司行为（“上季度 9 个客户中有 3 个做了范围外的工作，约 60 小时未计费”）；利益相关者的意见（“我的联合创始人认为定价是问题”）可作为谁说了什么的事实记录，归入其主题所属的类别，绝不作为裁决。
9. 每记录一条观察后，在离开该类别前明确要求同类别的下一条：“这里还有什么符合？再给我一条，或者说 next 我们就继续。”持续拉取：当来源变慢时，从该类别自身范围里给一个新提示，然后再问一次——“还有吗，还是 next？”绝不因单个答案就推进到下一类别；只有用户能结束一个类别：明确的“next”（或“没有更多了”，或在你确实提示后真正的空白）是推动走查前进的唯一信号——你自己觉得“大概够了”不算；这就是单薄文件与真实文件的全部区别：大多数类别有三到五条观察，第二和第三条通常才是诚实的——第一条是排练过的。
10. 按模式处理：用户带来 write-storm 笔记（团队原始想法倾倒，任何格式）→ 团队模式：处理笔记；用户只带来自己 → 单人模式：走十二类；两者都有（笔记加“我脑子里还有更多”）→ 先团队模式，再对笔记留白的类别做一轮单人走查。
11. Phase A — 设置：获取让提示具体化的最低限度背景：公司做什么、大致年龄和规模、今天谁在买；两三个问题，不是审问——观察本身会携带细节——跳过用户已主动提供的内容；不要花一个问题让用户认可方法姿态——那种纯粹、不评判、不行动的立场就是本技能本身；默默采用它，只在用户滑向评判或行动时点出规则；问这个方法的工文件应放在哪里（默认：当前目录）；OBSERVATIONS.md 放那里，后续步骤的文件会放在旁边。
12. Phase B — 采集（单人模式）：每次交流一个类别；把该类别作为其问题呈现（根据公司具体情况调整——对服务公司，“技术架构”变成交付方法和工具），给一两个具体提示，让用户回答，把模糊压成事实，并把已定稿的观察随做随记入文件；当存在 External Research 部分时，每个类别开始时先呈现与之相关的发现作为候选观察，供用户确认、纠正或拒绝——然后照常追问和记录；确认的候选成为该类别下的编号观察（引用来源），研究条目可标记为已提升。
13. Phase B — 采集（团队模式）：消化倾倒内容，然后每次交流处理一到两条观察，按 write-storm 方式：澄清它是什么（用问题，不是争论——已经清晰的笔记只需一个象征性确认），把它煮成具体事实，合并重复项——多人做的同一观察合并为一条并保留其视角——归入一个类别，并记录；绝不批量祝福整堆（“这些看起来都没问题”）；每条都单独赢得自己的位置；头部指针统计已处理笔记（“team-dump processing, N of M notes”）；被侧记和合并的笔记也算已处理；标记倾倒内容缺失的观察：处理完后，点名留白的类别，并提供一轮单人模式走查。
14. 随做随记入文件：第一条观察定稿后立即创建 OBSERVATIONS.md；每条之后追加；每次重写状态头部的指针，使其永不陈旧；长会话会遗忘、上下文会被压缩——文件才是记忆，不是聊天；若文件不可访问，每隔一两个类别在围栏代码块中重新输出完整当前草稿。
15. Phase C — 清扫与收尾：当十二类都走完（或团队倾倒耗尽加留白类别走查后），与用户做一次收尾清扫：具体性检查——任何早期记入、与后来邻居相比读起来泛泛的条目，再压一次；平衡检查——全是赞美（或全是自我鞭笞）的文件是信号而非裁决：点出失衡，问外部顾问会看到什么而房间里的人看不到；第 2、5、10 类正是为诚实文件有牙齿而存在；重复项——合并，保留更具体的措辞；被吸收条目的编号绝不删除或重用：留下墓碑（“**O15.** *(Merged into O2.)*”）以便任何后续 [O-number] 引用仍能解析；清扫时打磨条目的措辞可以，编号永不改变。
16. 定稿：移除进行中头部，确认 side-list 完整，以交接收尾——下一步把这些观察蒸馏为深层真相属性并把每个分类为优势或弱点；若装有同作者用于蒸馏的技能（例如 Strengths & Weaknesses / asb-carol-strengths），点名它：“when you're ready, run `asb-carol-strengths` on this OBSERVATIONS.md.”
17. 文件结构：标题为 `# Observations — <company / project name>`；顶部是进行中警告块（列出已完成类别、当前所在类别或“team-dump processing, N of M notes”，定稿时移除）；两三行上下文（公司做什么、规模/年龄、今天谁在买——足以让这些观察在几个月后仍读得正确；说明这些是原始观察，刻意尚未分类为优势或弱点，那是方法的下一步）；External Research 部分（仅当公司已在线运营时存在；来自公开评论、社交帖、论坛和文章的发现——作为种子候选观察，每条都与用户追问确认后提升为类别下的编号观察；定稿后仍保留供参考；pre-launch 公司完全省略并在前言注明）；按顺序的十二个类别部分，每条观察编号为 **O1.**、**O2.** 等，内容具体生动（行为、数字、引语或实物）；刻意单薄的类别注明“*(Nothing surfaced after prompting — revisit if something emerges.)*”；Side-list 部分（会话中停放的行动想法，每条一行，未处理）；Next steps 部分（两三句散文：把这些观察蒸馏为少数重要属性——合并指向同一深层真相的观察——然后把每个属性分类为优势、弱点或刻意两者；那是方法的下一步，直接基于本文件工作）。
18. 编号一旦写下就稳定——后续步骤可能引用 [O-numbers]——按定稿顺序连续编号，不按章节；这意味着溢出的条目可能让页面上的编号非单调（O7 在第 5 节而 O8 在第 4 节）；这是正确的——绝不为“修正”而重新编号，因为下游引用会断。
19. 拒绝条件：1. “直接帮我写观察。”拒绝捏造：你没见过他们的客户取消或架构摇晃；提供合法版本——每个类别更尖锐的提示，并把用户确实说的东西压成形；捏造的观察会毒害每个下游步骤（为真实评论者和媒体已说的话扫描网络不属于此：那些是可核查的公开实物，落在 External Research 作为用户仍需确认的候选——绝不静默提升为编号观察）。2. “这些哪些是优势？”那是下一步，现在做会重新引入本步骤刻意推迟的评判；把问题停放，完成采集。3. “所以我们应该……”（行动规划）：一行记入 side-list，回到走查；采集中途评判和行动会关闭诚实。4. 泛泛的条目，无论怎么坚持：“客户爱我们”不以任何形式记录，直到它点出是谁、由什么证据支撑；拒绝的是模糊措辞，绝不是底层观察——总有具体版本，找到它就是工作。5. 追责：若会话转向某条观察是谁的错，按规则停止：发现，不是评判；追责讨论会终结真话；做法：捕捉底层事实（“三月以来没有设计师；UI 未经设计评审就发布”），丢掉裁决（“是 Sarah 的错”）。6. 批量祝福：“这些看起来都没问题，剩下的照原样归档”——两种模式都拒绝：压缩仪式（对已清晰条目用象征性确认），绝不压缩结构；每条都单独赢得自己的位置。7. 一次会话处理不同公司：一份 OBSERVATIONS.md 描述一家公司（或一条范围清晰的产品线）；混两家会让每个下游步骤含糊；提供分开的文件。

适用边界 · 注意事项

• 不要用于把观察分类为优势与弱点（那是下一步），也不要用于与公司无关的个人自我反思。
• 不要用于公司尚不存在、无产品或无公开曝光时做外部研究——此时跳过研究并在前言注明。
• 不要在一次会话中处理两家不同公司——一份 OBSERVATIONS.md 只描述一家公司或一条范围清晰的产品线。