I do not read social posts as truth

I read them as pressure marks. A frustrated post about an AI coding tool may exaggerate the failure, but the shape of the complaint still matters. Was the model wrong? Was the diff impossible to review? Did the tool touch too many files? Did the user lose the thread of what changed? Those are different product problems, even if the surface emotion is the same.

The mistake is to treat every hot take as market research. The better move is to collect the verb, not the slogan. "It hallucinated" is less useful than "it changed three unrelated files and I could not see why."

Patterns that keep coming back

• People want speed, but they complain about review cost. The tool saves five minutes, then creates twenty minutes of suspicion.
• People enjoy magic demos, but they adopt boring controls. Approvals, diffs, scopes, undo, and logs are not glamorous, but they lower anxiety.
• People say they want agents, then ask for smaller surfaces. The actual desire is often not autonomy; it is delegation without losing authorship.

The interesting replies are not applause

A useful thread often lives in the replies, where people add missing constraints: "this breaks in monorepos", "legal will never allow that", "works for toy apps but not migrations", "the hard part is context, not generation." These replies are product material because they explain why the obvious solution is not enough.

My read: if a topic only produces applause, it is too shallow. If it produces objections from people who still want the outcome, it may be worth studying.

Turning chatter into a product note

I try to rewrite social noise into three columns: repeated pain, existing workaround, missing trust step. For example, "AI code review is annoying" is vague. "Developers want machine help finding risky diffs, but they still need the reasoning tied to exact lines" is closer to a product note.

This is also why I do not want a research page to be a list of trends. A trend is only useful after it becomes a question someone can test.

我不把社群貼文當真理

我把它當壓力痕跡。一篇罵 AI coding tool 的貼文可能很誇張，但抱怨的形狀仍然重要。是模型答錯？是 diff 很難 review？是工具碰了太多檔案？還是使用者看不懂到底改了什麼？這些是不同的產品問題，只是表面情緒很像。

錯誤做法是把每個 hot take 都當市場研究。比較有用的做法，是記動詞，不是記口號。「它 hallucinate」不如「它改了三個無關檔案，而我看不出原因」。

反覆回來的幾種摩擦

• 大家想要速度，但真正抱怨的是 review 成本。工具省了五分鐘，卻多了二十分鐘的不信任。
• 大家喜歡魔法 demo，但真正採用的是無聊控制：批准、diff、scope、undo、log。這些不性感，但能降低焦慮。
• 大家嘴上說想要 agent，實際上常常要求更小的操作面。真正想要的不是完全自治，而是不失去作者權的 delegation。

有用的回覆通常不是掌聲

一串討論最有價值的地方，常常在留言裡：有人補一句「monorepo 會壞」、有人說「法務不可能讓這樣跑」、有人說「demo app 可以，migration 不行」、有人說「難的是 context，不是生成」。這些回覆才是產品素材，因為它們解釋了為什麼直覺解法不夠。

我的判斷是：如果一個話題只有掌聲，它通常太淺；如果它引來一堆反對，但反對的人仍然想要那個結果，那才值得研究。

把吵雜訊號改寫成產品筆記

我會把社群雜訊改寫成三欄：重複痛點、現有土法、缺的信任步驟。例如「AI code review 很煩」太空泛；「開發者想讓機器先找 risky diff，但理由必須綁到具體行數」就比較像產品筆記。

這也是為什麼研究頁不該只是趨勢清單。趨勢只有在變成可測的問題時，才真的有用。