问题思考：以终为始，先把真问题列出来，再去找解法

为什么先讲问题，不先讲工具

技术内容有个通病：从工具出发。出了个新框架就讲新框架，出了个新模型就讲新模型。看的时候很热闹，看完发现——我好像也用不上。

这条线反过来做，以终为始：

先问「现实世界里，谁在什么场景下，卡在什么地方」，把这个问题讲透；再问「今天有什么办法能解」。

顺序反过来之后，一个很有用的性质就出来了：问题的保质期，比解法长得多。

一个小公司的财务每月手工录几百张报销单据——这个痛点 2015 年存在，2026 年还存在，大概率 2030 年也还在。而解它的办法这十年换了三轮：先是 OCR 模板，然后是端到端文档理解模型，现在是多模态模型加 Agent 编排。方法一直在过时，问题一直没变。

所以这条线的产出有两层：

长期资产：一张持续维护的痛点地图，只增补、不作废
短期时效：每个痛点当下的最优解，明确标注「这是 2026 年的答案，会过期」

📍 常驻入口：痛点地图

这条线有一个不随视频更新而消失的固定页面——🧠 痛点地图。

它是一张长期滚动维护的结构化清单，按场景分区（财务与行政、客户服务与沟通、内容与知识管理、部署与运维、学习与协作门槛……），每一条记录一个具体的、可验证的真实卡点。新发现的痛点往里加，已经被很好解决的标记状态，但不删——因为解法失效之后，问题会回来。

视频是这张地图的展开：每期挑一条，讲清楚它为什么难、目前有哪些解法路线、各自的代价是什么。

这条线不做什么

不做工具测评——那是🔬 技术实验线的事，这里只到「有哪几条解法路线」为止
不承诺解法长期有效——每个结论都带时间戳，过期了就更新，不装作没过期
不预设 AI 一定是答案——有些痛点的最优解就是换个流程，或者干脆不用软件

和另外两条线的关系

这条线是另外两条的上游：痛点地图决定了🔬 技术实验去开盒哪些仓库；而反复出现、又始终没有好解法的那些痛点，就是🌱 公共物品线自己动手做组件的理由。

Why Problems Come Before Tools

Tech content has a chronic habit: it starts from the tool. A new framework ships, so we cover the new framework. A new model drops, so we cover the new model. It’s lively to watch and, afterwards, oddly unusable.

This line runs the other direction — start from the end:

First ask “in the real world, who is stuck, in what situation, and at exactly which step?” and explain that thoroughly. Only then ask “what can solve it today?”

Reversing the order buys one very useful property: a problem’s shelf life is far longer than a solution’s.

A small company’s bookkeeper manually enters a few hundred expense receipts every month. That friction existed in 2015, still exists in 2026, and will very likely still exist in 2030. The way to fix it, meanwhile, has been replaced three times in that decade: OCR templates, then end-to-end document-understanding models, now multimodal models with agent orchestration. The methods keep expiring. The problem never moved.

So this line produces two layers:

A long-lived asset: a continuously maintained pain point map — appended to, never voided
A short-lived answer: the current best solution for each pain point, explicitly stamped “this is the 2026 answer, and it will expire”

📍 The Permanent Entry Point: The Pain Point Map

This line has one page that doesn’t scroll away with each new video — the 🧠 Pain Point Map.

It’s a structured, continuously updated list organized by scenario (finance and admin, customer service and communication, content and knowledge management, deployment and operations, learning and collaboration barriers, and so on), where each entry records one concrete, verifiable point of real friction. Newly found pain points get added; well-solved ones get their status marked — but nothing gets deleted, because when a solution stops working, the problem comes back.

The videos are that map, expanded: each episode takes one entry and explains why it’s hard, which solution paths exist today, and what each one costs.

What This Line Does Not Do

No tool reviews — that’s the 🔬 Tech Experiments line’s job; here we stop at “these are the available solution paths”
No promise that a solution lasts — every conclusion carries a timestamp; when it expires we update it rather than pretending it didn’t
No assumption that AI is the answer — for some pain points the best fix is a different process, or no software at all

How It Relates to the Other Two Lines

This line sits upstream of the other two. The pain point map decides which repos 🔬 Tech Experiments tears down; and the pain points that keep recurring without a good answer are exactly why the 🌱 Public Goods line builds components itself.