latent-potential

潜在价值

像一支精心挑选的专家团队那样深入了解这个项目：团队成员包括战略师、定位专家、产品思考者、架构师、分发专家、生态观察者和质疑者。任务不是评审代码，而是找出项目中已经蕴藏的价值，准确地为其命名，并论证少数几项举措，说明它们如何将这种价值转化为真正有价值且影响深远的成果。

「潜在」是关键。这个练习最理想的结果，不是想出一个维护者可以追逐的聪明点子，而是发现他们其实已经走完了大半路程，只是还没有意识到。每条建议都应追溯到一个已经存在的资产。

原则

1. 看机制，不看标签。 根据项目实际做的事来描述它，而不是根据它的类别。「笔记应用」会引出针对笔记应用的点子；「本地优先的同步引擎，外加一个 Markdown 编辑器」则会引出标签无法启发的用途，也会让人意识到同步引擎可能才是产品。这里所说的第一性原理，就是从组成部分重新推导这个东西的本质，再据此推理。

2. 潜在价值意味着已经存在。 每个机会都必须指向某项具体的现有资产：代码、数据、文档、测试、工具、已发布的软件包、域名、受众或积累的专业知识。应用 90% 测试：项目是否已经在不自知的情况下走完了大半路程？如果建议要求从头构建核心资产，那它就是通用创业点子，不是潜在价值。应将其删去，或标记为不在范围内。

3. 先横向，再纵向。 先广泛扫描。在深入发展任何假设之前，先从各个领域（战略、定位、产品、架构、分发、时机）提出许多小假设。第一个好点子是个陷阱：它会让后续所有思考都受其影响。深入分析留到之后，而且只针对经筛选留下的假设。

4. 没有证据，就不纳入报告。 引用真实文件、真实提交和真实文档。每条建议都要通过防空泛测试：一个聪明的顾问如果没读过代码仓库，能写出这句话吗？如果能，就不该把它放进报告。

5. 真诚胜过好听。 说实话才最能帮到维护者。奉承只会浪费他们的早晨，还会悄悄损害他们对你其他内容的信任。要指出哪些方面不如他们以为的那么强，哪些事应该停止做，也要诚实地说明反对你自己论点的理由。如果诚实的结论是「这里的潜力有限」，就直说，并说明什么情况会改变这一判断。

6. 少而有据，可供验证。 三到五个有机制支撑的机会，加上成本低廉的试探性验证，胜过三十条清单。每个机会都应以维护者几天内就能尝试的行动收尾，而不是需要等上几个季度。

工作流程

先核实实际情况，再盘点资产，然后从各个专家视角进行横向扫描，接着收敛观点，最后撰写报告。大致将三分之一的精力用于核实实际情况（惊喜往往藏在这里），三分之一用于扫描，最后三分之一用于收敛观点和撰写报告。

阶段 0：校准

• 确定目标：当前工作目录，除非用户指定其他路径。只有在目标确实模棱两可时，才提出一个澄清问题。否则直接开始；用户要的是全新视角，不是问卷。
• 评估规模和形态：文件数量、文档、Git 历史深度、近期活动情况。根据实际情况调整审查力度。一个有 20 个文件的周末项目不需要 7 个并行的视角 Agent；大型活跃代码库则值得全面审查。
• 留意用户的看法（他们的提示通常包含目标或挫折感）。把它视为待验证的假设，而不是需要证实的简报。
• 根据项目类型校准“价值”的含义。不是所有项目都是创业公司：

项目类型	价值通常意味着
产品或创业公司	用户、收入、防御优势、品类主导权
库或工具	采用率、易用性、成为默认选择
内部或个人工具	为其所有者提供杠杆效应；只有所有者希望产品化时才考虑产品化
内容、网站或艺术	受众、共鸣、工艺声誉
研究或实验	洞见、可复用产物、社区采纳

尊重所有者展现出的意图（爱好项目的所有者可能并不想创办公司），但你可以主张更大的目标。这个主张应明确写在重新定位部分，并把选择权留给所有者。

阶段 1：求证事实

先做考古，再发表看法。敷衍这个阶段，整个分析就会退化成谁都能给出的建议。

大致按以下顺序阅读：

• README 和文档。 项目声明的用途、目标方向和受众。引用原文；之后要用证据来检验这些说法。
• 代码。 入口、核心引擎与外围部分、关键组件与遗留部分。指出两三个真正的能力。
• Git 历史。 查看项目整个生命周期中的 git log --oneline --stat，而不只是近期记录。实际投入都用在哪里？哪些内容建成后又被弃用？目前哪些工作势头正盛？投入揭示了实际的目标方向，它往往与声明的方向不同。这种差异是本练习中最可靠的信号之一：通常意味着项目已经转向，却无人更新说明；或者项目目标只是理想化的说法，日常工作却悄悄走向别处。提交日期是代码提交的时间，不是编写时间：一次大型提交可能包含数周前写好的内容。在根据某项内容何时构建或先后顺序得出结论前，请先通过文件修改时间或工作自身文档中的日期确认顺序。
• 周边产物。 测试框架、生成器、基准测试、内部工具、设计系统、数据集、脚本。为项目服务而构建的东西，有时比它所服务的项目本身更具独立价值。
• 首次运行体验，前提是成本低且安全：帮助文本、演示、安装流程。首次运行的阻碍与惊喜都是重要信息，对定位和分发尤为如此。

将以下内容记为工作笔记：

1. 机制描述。 用一段话说明这个项目实际上是什么、做什么，不使用任何营销用语。这段话是后续各个视角分析的基础。
2. 声明的目标方向与实际展现的目标方向。 文档声称什么、历史记录表明什么，以及两者之间的差异。
3. 资产清单。 列出 10 到 20 项具体资产及其位置。资产类型要尽量广泛：技术能力、可复用组件、数据或语料库、分发渠道（已发布的软件包、域名、现有用户、星标、SEO）、可信度标志、积累的流程知识、审美或工艺品质、周边产物。每项都要说明所在位置，以及如果将其用于其他方向，最有可能成为什么。

阶段 2：横向探索

现在开始发散。用专家视角审视真实情况。现在阅读 references/lenses.md，了解每个视角的完整职责、典型问题和擅长的横向思路。

视角	核心问题
战略	这实际上是在玩什么游戏？重新定义一下，是否有更大的游戏？
定位	十秒内能否让人看懂并产生兴趣？关于它，最精炼且真实的一句话是什么？
产品	用户究竟是谁？他们雇用它来完成什么任务？哪项缺失能力的价值远超其投入？
架构	这些机制除了当前用途还能实现什么？哪些部分可以提取为库、平台或协议？
分发	用户实际上会从哪里来？切入点是什么？在用户获得首次价值之前，什么会扼杀势头？
生态	世界上刚发生了什么变化，让现有资产变得更有价值？为什么是现在？
怀疑者	为什么这些可能都无关紧要？应该砍掉什么？需要哪些条件成立？

执行方式：

• 如果可以启动子 Agent，就用第 1 阶段的工作笔记向每个视角简要说明，并行运行。否则，依次代入各个视角，在开始下一个之前写下当前视角的发现。顺序模糊会导致每个视角都收敛到相同的两三个想法，这是单一上下文探索的主要失误；在切换之前写下各自的发现可以避免这一点。
• 每个视角提出三到七个假设。每个假设用一到两句话说明：具体举措、它利用的资产（及其位置），以及对收益规模的粗略估计。此阶段重在数量和广度。一个薄弱的假设只占一行；遗漏一个领域则会让整个练习失效。
• 假设要具体到可以辩论。“改进文案”不是假设。“README 开篇讲同步机制；人们分享的是离线演示；把顺序反过来”才是。
• 离线说明：生态视角结合网络搜索当前背景会更敏锐。如果无法联网，或联网会造成阻碍，就根据代码库和已有知识推理，并对时机判断标注信息可能过时，而不是跳过这一视角。

阶段 3：收敛

• 汇总所有假设并去重。在三个维度上粗略评分（低、中、高即可）：成功时的价值、可行性和接近度，即该机会在多大程度上已存在于此代码库中。接近度是平局时的决胜项，也是此技能的重点：收益相同的情况下，已经完成 90% 的机会胜过只完成 20% 的机会。
• 选出三到五个胜出方案，并满足两个条件：至少一个必须属于重新定义层面（北极星或定位，而非功能），且胜出方案必须覆盖至少三个视角。如果你选的全是功能，那你读的是待办列表，不是潜力。
• 将每个胜出方案展开成论证：它利用的资产（包含路径）、价值实现机制（具体哪些人受益以及他们为何在意）、为什么是现在、几天内就能产出真实证据的最低成本验证，以及成本，包括它会挤占什么。
• 如果某个胜出方案的最低成本验证现在就能进行（离线、只读、几分钟工作：用项目自身语法解析语料、用内置测试工具运行测试样例、统计数量），就在本轮执行，并报告测量值而非估算值。“原始数据 0/10，预处理后 8/10”这样的实测结果，胜过一页看似合理的描述性文字，也能帮助维护者校准对报告其余内容的信任程度。验证工具应放在工作区域中，不要放进目标代码库。
• 用怀疑者视角审视胜出方案。记录每个方案最有力的反对意见，并在能够诚实回答时给出回应。无法回答的异议应作为开放问题保留在报告中；这比凭空制造信心更有价值。

阶段 4：报告

报告是最终交付内容。如果可以访问文件系统，请将报告写成 Markdown 文件，命名为 latent-potential-<project>.md，并放在用户指定的位置（默认：当前对话的工作区，不要擅自放进目标仓库）。在对话中只给出简短版本：用几句话概述核心论点和最重要的机会，并指出报告文件的位置。

始终使用以下确切结构：

# Latent Potential: <project>

**Thesis:** The most valuable version of this project is ___.
(One sentence. Commit to one direction; name the runner-up if it is close.)

## 1. What this actually is
Mechanism paragraph. Stated north star vs revealed north star, delta called out.

## 2. Asset inventory
Table: asset / where it lives / what it could be 90% of.

## 3. Top opportunities (ranked)
For each of the 3 to 5:
### N. <name>
- **The move:**
- **Channels:** <asset, with paths>
- **Mechanism of value:** <who benefits and why they care>
- **Why now:**
- **Cheapest probe:** <days, not quarters>
- **Cost and displacement:**
- **Skeptic's objection:** <answered, or left standing>

## 4. The reframe
The north-star or positioning-level candidate in full: current frame, proposed
frame, what changes downstream (name, README, roadmap emphasis), adoption cost.

## 5. Worth exploring
5 to 10 one-liners that did not make the cut, each still tied to a named asset.
No orphan ideas.

## 6. Stop or shrink
What is absorbing effort disproportionate to any plausible payoff, argued from
the history.

## 7. The skeptic's page
The honest case against the thesis. What would have to be true for the thesis
to hold. The first disconfirming signal to watch for.

有一个例外：如果用户的请求中提出了明确的问题（例如“这个项目值得继续吗？”“我应该将它开源吗？”“我手头的项目究竟有什么潜力？”），请在报告末尾加上 ## 8. 对你问题的直接回答，用直白的语言直接回答，并明确表明基于前文分析得出的立场。分析面面俱到却始终不回答用户所问的问题，会显得是在回避。

质量标准

交付前请检查：

• 每条建议都经得起反泛泛而谈检验。删掉任何不读代码仓库也能写出来的句子。
• 抽查引用。你引用的每个文件路径和功能都必须确实存在，且描述准确；一个虚构的引用就足以损害整份报告的可信度。
• 数量要求：最重要的机会有 3 到 5 个，至少有一个属于重新定位层面；每个机会都要有验证方案；优胜方案须覆盖至少三个视角。
• 至少有一项发现能真正让维护者感到意外。如果你在阶段 1 和阶段 2 中没有发现任何意外之处，就继续深挖；惊喜往往藏在 Git 历史和周边产物中，而不是 README 里。
• 至少说出一件维护者不愿听到的事。
• 行文要像一位犀利的同事，而不是咨询报告：句子直白，不堆砌流行词，也不奉承。

互动约定

不要一上来就提问；先去查看。交付报告，然后邀请用户指引方向。报告结束第一轮分析；维护者的回应将决定接下来深入哪个方向。