[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fmBJ9pjpac0B9bTCsE5n7zvOgPVBUoA0h337FaQYCZCY":3,"$fKinFyj4rDP3viM0Q084kYY3wo64froYc4EjvOEeVzUQ":24},{"success":4,"data":5},true,{"id":6,"slug":7,"title":8,"summary":9,"category":10,"series":11,"created_at":12,"updated_at":12,"view_count":13,"author":14,"sources":16,"content":23},"academy-growth-intent","one-keyword-one-page-or-many-pages","一个关键词该做一个页面还是多个页面？先看用户是不是在做同一件事","页面数量不该由关键词数量决定。近义词可能属于同一搜索意图，同一个词也可能包含不同任务。拆页之前，先比较结果页和用户最终想得到的东西。","growth","增长实验室","2026-09-10T00:00:00.000Z",0,{"username":15},"小概率编辑部",[17,20],{"label":18,"url":19},"Google Search Central：Canonicalization","https:\u002F\u002Fdevelopers.google.com\u002Fsearch\u002Fdocs\u002Fcrawling-indexing\u002Fcanonicalization",{"label":21,"url":22},"Google Search Central：SEO Starter Guide","https:\u002F\u002Fdevelopers.google.com\u002Fsearch\u002Fdocs\u002Ffundamentals\u002Fseo-starter-guide","关键词工具很容易给你一张几百行的表。真正难的不是把每一行变成 URL，而是决定哪些词应该共用一个页面。\n\n这个判断做错，站点通常会走向两个极端：所有词都塞进首页，什么都讲不清；或者每个近义词建一页，页面之间只换几个标题。\n\n## 先比较“用户最终想得到什么”\n\n例如“image compressor”和“compress image online”大概率指向同一个任务：上传图片、压缩、下载。\n\n“how image compression works”虽然共享词根，任务却不同：用户更可能想理解原理。\n\n所以第一层不是比较字面相似度，而是写出每个查询的完成状态。如果用户在两个查询下都希望得到同一个结果，优先考虑一个页面。\n\n## 再看搜索结果是不是把它们当成同一个市场\n\n手工搜索几个核心变体，比较前十结果。如果大部分 URL 高度重合，说明搜索系统和市场通常把它们视为接近的意图。一个强页面覆盖它们往往更自然。\n\n如果结果构成明显不同——一个全是工具，一个全是教程；一个偏企业采购，一个偏免费个人使用——就有拆页理由。\n\n这不是机械公式，但比“词不同就建页”可靠。\n\n## 页面拆分必须有真实内容差异\n\n准备新建第二个页面前，问一个苛刻问题：去掉标题以后，两页正文和核心功能还能明显不同吗？\n\n如果不能，很可能只是 doorway page。\n\nGoogle 对 canonical 的说明指出，重复或非常相似页面会被聚类并选择代表页面。即使手工标了 canonical，最终选择仍是搜索系统综合判断。与其制造一堆让系统帮你去重的页面，不如一开始就让信息架构清楚。\n\n## 同一个主题可以有多个页面，但任务必须不同\n\n一个产品可以有工具页、方法页、定价页和案例页，它们围绕同一主题，却分别解决使用、理解、购买和信任问题。\n\n长尾词也一样。“invoice template for freelancers”如果真的需要自由职业者特有字段、税务提醒和使用场景，可以有专页；如果只是把主页面标题加一句 for freelancers，就没有独立交付。\n\n## URL 架构也要跟着意图，而不是跟着词表\n\n一级页面应该对应稳定主题，不要今天为了一个长尾词建三层目录，明天又因为关键词变化迁移。\n\n分类页如果只是把筛选参数全部开放给搜索引擎，会产生大量近似 URL。电商和目录站尤其要控制无限组合。\n\n把候选关键词放进表格，只比较四列：用户任务、理想页面类型、现有 SERP 重合度、你能提供的独立价值。四列高度一致就合并；任务或交付明显不同才拆分。\n\n页面规划的目标不是“覆盖更多关键词”，而是让每个重要需求都能落到一个最自然的入口。",{"success":4,"data":25,"meta":456},[26,43,58,75,93,112,129,145,161,175,190,203,216,230,242,253,268,281,294,311,325,337,342,356,368,385,401,413,430,443],{"id":27,"slug":28,"title":29,"summary":30,"category":31,"series":32,"featured":4,"created_at":12,"updated_at":12,"view_count":13,"author":33,"sources":34,"content":42},"academy-story-tally-pivot","tally-from-travel-startup-to-form-builder","Tally：一次受挫的旅游创业，最后做成了表单工具","Tally 并不是从一份“表单市场分析”开始的。两位创始人先做旅游业务，疫情后失去客户，才转向一个他们自己嫌贵、嫌难用的老品类。","stories","独立开发故事",{"username":15},[35,38],{"label":36,"url":37},"Tally 创始团队：How we ended up building the simplest way to create forms","https:\u002F\u002Fblog.tally.so\u002Fhow-we-quit-our-jobs-to-work-on-our-startup-lost-half-of-our-clients-decided-to-pivot-and-ended-up-building-a-no-code-tool\u002F",{"label":39,"url":40,"note":41},"Tally：How we grew Tally to $4M ARR, fully bootstrapped","https:\u002F\u002Fblog.tally.so\u002Fhow-we-grew-tally-to-4m-arr-fully-bootstrapped\u002F","收入与用户数据来自 Tally 自己披露，未经独立审计。","Tally 今天看起来像一个很顺的故事：表单是刚需，产品足够简单，免费版足够大方，再用 Pro 和 Business 收费。但它真正的起点并不是“我们发现了表单市场的巨大机会”。\n\n## 先做错一个项目\n\n2019 年底，Marie Martens 和 Filip Minev 做的是 Hotspot，一个连接酒店与旅行创作者的业务。2020 年初，两人把更多时间押进去，随后疫情直接打断旅行行业。Tally 创始团队后来在自己的博客里回忆，到 2020 年 7 月，他们已经失去大约一半客户。\n\n这段经历很重要，因为它把“转型”从创业故事里的漂亮词，变成了一个很现实的问题：原来的行业什么时候恢复没人知道，手上的客户还在减少，继续等也是一种选择，但成本每天都在发生。\n\n他们没有立刻追逐当时最热门的新概念，而是回到自己反复遇到的小问题：Google Forms 能用，但体验朴素；Typeform 一类产品好用，但对于早期团队和个人来说容易很快碰到付费墙。表单不是新市场，甚至可以说拥挤得不像机会。\n\n## 一个老品类，换一个明确取舍\n\nTally 的切口不是“功能更多”，而是“像写文档一样做表单”。它把编辑器做得接近 Notion 的输入体验，同时把大量能力放进免费层。早期 MVP 甚至很简陋。Tally 团队自己回忆，最初版本只能插入问题，连发布表单都还不完整。\n\n这和常见的 MVP 误区正好相反。很多人会觉得，进入成熟市场必须一开始就补齐竞品功能，否则没有资格上线。Tally 先验证的是更窄的问题：有人会不会喜欢这种编辑方式？愿不愿意继续用？哪些功能真的会被要求？\n\n他们在 2020 年把 MVP 给朋友、Indie Hackers、创业者社区和 Slack 用户看，持续收反馈。到 2021 年 Product Hunt 正式发布时，产品已经不是“一个周末的 Demo”，但仍然围绕同一个取舍：简单、快、免费层足够有用。\n\n## 真正拉开差距的是长期坚持同一个约束\n\n几年以后，Tally 没有把自己扩成“表单 + CRM + 日历 + 数据库”的大套件。创始团队在 2025 年复盘时仍然把“只把一件事做好”列为核心原则。按照 Tally 自己 2025 年 10 月的披露，公司已经达到约 400 万美元 ARR；2026 年初，他们又公开写到团队约 10 人、用户超过 100 万。这里的财务数字属于公司自报，不应当当作审计口径，但它至少说明这条路线不是短期实验。\n\n更值得注意的是它的增长结构。大量用户先免费创建表单，表单本身又会被更多人看到；一部分用户为了去品牌、团队协作、数据留存等需求升级。免费层不是单纯“送功能”，而是产品分发的一部分。\n\n## 这个故事真正能抄的是什么\n\n不是“去做一个表单工具”。表单市场今天比 2020 年更拥挤，照着 Tally 复制 UI 并不会复制它的结果。\n\n更可复用的是四个判断。\n\n第一，创业受挫后，不一定要寻找一个全新的宏大方向。你已经长期使用、长期抱怨的旧工具，反而可能更接近真实需求。\n\n第二，成熟市场并不等于没有机会。问题是你能不能明确说出：现有产品对哪一类人不够好，你准备做出什么取舍。\n\n第三，MVP 不需要证明“我能造出完整产品”，只需要证明最关键的体验假设有人在乎。\n\n第四，小团队的优势不是功能数量，而是能长期拒绝不重要的东西。Tally 后来的规模变大了，但它最早的竞争力仍然能追溯到那个很窄的判断：做表单这件事，不该这么笨重。",{"id":44,"slug":45,"title":46,"summary":47,"category":31,"series":32,"created_at":12,"updated_at":12,"view_count":13,"author":48,"sources":49,"content":57},"academy-story-photopea","photopea-ten-years-from-psd-viewer","Photopea：从“能不能在浏览器打开 PSD”开始的十多年","Photopea 没有先做“网页版 Photoshop”。它最早只是一个 PSD 文件查看实验，功能一项项长出来，六年后才真正让创作者不必去找工作。",{"username":15},[50,53],{"label":51,"url":52},"Siesta Labs：The Independent Path of Ivan Kutskir, Founder of Photopea","https:\u002F\u002Fsiesta-labs.com\u002Fblog\u002Ffrom-passion-project-to-global-tool-the-independent-path-of-ivan-kutskir-founder-of-photopea",{"label":54,"url":55,"note":56},"Indie Hackers \u002F Ivan Kutskir：Photopea founder story","https:\u002F\u002Fwww.indiehackers.com\u002Fpost\u002Fthe-story-of-a-unicorn-solo-founder-making-500-000-arr-4c3070f0f0","文中的收入数字来自创始人自述，未经独立审计。","Photopea 最容易被讲成一种传奇：一个人，在浏览器里做出了接近专业桌面软件体验的图片编辑器。但如果只盯着“一个人做 Photoshop”这件事，会错过这个项目更有价值的部分——它一开始根本不是 Photoshop。\n\n## 最初只是想读懂一个文件\n\nIvan Kutskir 在大学期间做过很多小项目。他熟悉 Photoshop，也对浏览器技术感兴趣。2012 年，他尝试解决一个很具体的技术问题：能不能在网页里解析 PSD 文件？最早的版本更像 PSD 查看器，用户能打开文件、看到图层，再把内容导出。\n\n这不是一个完整商业计划，也没有“全功能在线图像编辑平台”的路线图。Ivan 后来的回忆很直接：前几年他并没有打算做完整编辑器，只是在已有东西上不断加功能。\n\n这种生长方式和现在常见的 AI 建站节奏很不一样。现在一个人很容易在几天内搭出首页、登录、支付、后台，看起来“产品齐了”。Photopea 的早期路径几乎相反：外壳并不重要，最难的核心能力先一点点变强。\n\n## 2016 年，才真正押上全职时间\n\nPhotopea 从 2012 年开始只是爱好项目。Ivan 2016 年毕业时才遇到真正的选择：去找一份正常的软件工作，还是拿积蓄继续做它。\n\n他选择了后者，而且生活方式并不浪漫。根据他后来的采访，他当时和几个人合租，尽量压低开支，希望把“必须去找工作”的日期往后推。Photopea 那时已经有持续增长的用户，但并没有给他稳定收入。\n\n2017 年他开始用广告变现。Ivan 在采访里回忆，早期广告收入大约每月 500 美元。这个数字的意义不在于高，而在于它第一次改变了项目的生存条件：只要成本足够低，一个原本需要靠存款维持的项目，可以继续活下去。\n\n之后 Photopea 的用户和收入继续增长。Ivan 多次公开过自己的收入数据，但这些都属于创始人自报，不应包装成审计事实。比数字更确定的是商业结构：大量编辑工作发生在用户浏览器本地，产品长期保持免费可用，广告是主要变现方式，Premium 和授权等形成补充。\n\n## 十多年里，他没有把“独立”理解成拒绝用户\n\nPhotopea 很多功能来自用户提出的问题。Ivan 维护 Twitter、GitHub、Reddit 等社区入口，自己处理邮件和 bug。后来他也尝试找人协作，但在 2025 年的采访里，他坦言自己仍然更享受亲自解决问题，而不是给别人拆任务。\n\n这并不意味着“一个人永远最好”。Photopea 恰好建立在一个非常特殊的个人能力上：创作者长期积累图形处理、文件格式和浏览器实现经验，代码又高度集中。换一个需要销售、客服、线下交付的业务，照抄这种组织方式很可能失败。\n\n## Photopea 对独立开发者最有价值的提醒\n\n第一，不要把“项目最初形态”想得太大。一个文件解析器可以慢慢长成编辑器；一个真正困难、真正被使用的核心能力，比十个外围页面更值钱。\n\n第二，时间本身可以成为壁垒。Photopea 很难复制，不是因为别人不知道它有哪些按钮，而是大量兼容性和图形能力是十多年累积出来的。\n\n第三，低成本结构会改变你能坚持多久。如果一个项目每个月必须烧掉高额云成本和广告费，它没有 Photopea 那样的试错时间。\n\n第四，别把“独立开发”误解成“快速做很多项目”。Ivan 的案例恰好是另一条路：一个项目做很多年，慢慢把一个看起来很小的技术实验做深。它不适合所有人，但足够提醒我们——做得久，本身也可能是一种产品策略。",{"id":59,"slug":60,"title":61,"summary":62,"category":31,"series":32,"created_at":12,"updated_at":12,"view_count":13,"author":63,"sources":64,"content":74},"academy-story-simple-analytics","simple-analytics-from-annoyance-to-product","Simple Analytics：不想再装 GA，怎么变成一个产品","Adriaan van Rossum 做客户网站时反复安装 Google Analytics，却越来越不喜欢这种数据收集方式。产品机会不是调查出来的，而是从自己的职业摩擦里长出来的。",{"username":15},[65,68,71],{"label":66,"url":67},"Simple Analytics 官方 About","https:\u002F\u002Fwww.simpleanalytics.com\u002Fabout",{"label":69,"url":70},"Simple Analytics：Founder Story","https:\u002F\u002Fwww.simpleanalytics.com\u002Fpress\u002Ffounder-story",{"label":72,"url":73},"Simple Analytics：Why Simple Analytics is my first successful project","https:\u002F\u002Fwww.simpleanalytics.com\u002Fblog\u002Fwhy-simple-analytics-is-my-first-successful-project","很多需求发现方法都要求你去“找用户痛点”。Simple Analytics 的起点更普通：创始人 Adriaan van Rossum 当自由职业开发者时，给客户做网站，经常要重复安装 Google Analytics。他知道这些脚本会采集访问数据，这件事越来越让他不舒服。\n\n他后来在采访里回忆，自己甚至只是和女朋友抱怨这件事，对方反问：既然你总喜欢自己做东西，为什么不做一个你愿意安装的分析工具？\n\n## 先解决自己明确知道的问题\n\nAdriaan 没有先设计一个“Google Analytics 替代平台”。早期版本非常窄：一个轻量脚本，一个简单后台，显示页面浏览、来源等最基本数据，不追踪个人，也不依赖复杂用户画像。\n\n这个方向之所以值得看，不是因为“隐私赛道很大”，而是创始人同时拥有三种信息。\n\n他是实际使用者，知道安装和查看数据的工作流；他是开发者，知道一个更轻的版本技术上可行；他又对现有方案有明确价值判断——不是“功能不好”，而是“不想用这种方式得到数据”。\n\n这比泛泛地说“用户觉得 GA 太复杂”具体得多。\n\n## 第一批用户来自一次真实发布\n\nAdriaan 在 2018 年把 Simple Analytics 发到 Hacker News。根据他自己的回忆，产品在首页获得了很长时间曝光，也带来了第一批客户。此前他做过不少项目，但自己把 Simple Analytics 称为第一个真正成功的项目，其中一个变化就是：这次他没有只做完、给朋友看看、然后等 SEO 慢慢来，而是明确地把产品发布到有目标用户的社区。\n\n这里有个容易被忽略的差别：发布不是“做营销素材”，而是把产品拿到一个会迅速给出反馈的场景。有人愿意点击不够，有人愿意付钱才让他更确信这个价值主张成立。\n\n早期现金流仍然不宽裕。他继续做一部分自由职业，用短期服务收入换取更多时间做产品。这个组合对独立开发者很现实：不是非得在“全职创业”和“完全不做”之间二选一。\n\n## 隐私不是一句品牌口号，而是产品约束\n\nSimple Analytics 后来的产品和商业模式一直围绕这个约束：不使用 cookies，不收集个人数据，尽量减少脚本体积，同时用订阅收费。官方 About 页面目前仍把独立、自筹资金、隐私优先列为核心原则。\n\n这种定位有代价。它主动放弃了一部分依赖细粒度用户追踪的分析能力，也不适合所有增长团队。但正因为放弃了一些东西，产品才有清晰边界。\n\n更有意思的是，Simple Analytics 后来在免费策略上也做过实验。团队曾讨论免费计划能不能扩大增长，之后又根据自己的转化和收入表现调整。这说明“价值观明确”不等于商业策略一成不变；真正不变的是它不愿靠个人追踪来换增长。\n\n## 从这个故事里能学到什么\n\n需求未必来自陌生人的访谈。你每天重复做的工作、每次都觉得别扭但又不得不用的工具，本身就是一份需求清单。\n\n不过“我讨厌这个工具”还不够。要继续问三句：别人是否也有同样的不满？你准备牺牲什么来换取更好的体验？这个差异是否足以让人迁移和付费？\n\nSimple Analytics 的答案很明确：目标用户愿意用更少的追踪能力，换更轻、更简单、更尊重隐私的分析；团队再用付费订阅而不是广告数据来维持业务。\n\n这类机会往往不是发明新品类，而是把一个你不认同的默认做法拿掉，再看看剩下的东西能不能独立成为产品。",{"id":76,"slug":77,"title":78,"summary":79,"category":31,"series":32,"created_at":12,"updated_at":12,"view_count":13,"author":80,"sources":81,"content":92},"academy-story-buttondown","buttondown-side-project-to-full-time-business","Buttondown：先给自己做一个顺手的工具，再慢慢把它变成生意","Justin Duke 没有因为“邮件工具很多”就放弃。他只是觉得现有产品太重，先做了自己愿意用的版本，几年后才从业余项目变成全职公司。",{"username":15},[82,85,88],{"label":83,"url":84},"Buttondown 官方：For creators","https:\u002F\u002Fbuttondown.com\u002Ffeatures\u002Ffor\u002Fcreators",{"label":86,"url":87},"Medialyte：Justin Duke built Buttondown for himself","https:\u002F\u002Fmedialyter.substack.com\u002Fp\u002Fjustin-duke-built-buttondown-for",{"label":89,"url":90,"note":91},"Starter Story：Justin Duke \u002F Buttondown","https:\u002F\u002Fwww.starterstory.com\u002Fstories\u002Fbuttondown","收入数字为创始人采访时披露，文章不将其视为审计数据。","Buttondown 所在的市场一点也不空。Mailchimp、ConvertKit、Substack，再加上一长串邮件营销和 newsletter 工具，任何一份“竞品数量”表格都可能让人得出结论：别做了。\n\nJustin Duke 还是做了。原因没有那么宏大。他自己写 newsletter，觉得当时可选工具要么偏企业营销、功能太重，要么希望接管整个内容发布体系。他想要的是另一种东西：在自己的网站放一个订阅表单，写信，发出去，别让工具本身占太多注意力。\n\n## 最开始的用户就是自己\n\nJustin 在采访里说过一句很能解释 Buttondown 的起点：他并没有预判到 newsletter 会成为某个大趋势，只是想做一个自己更愿意用的工具。\n\n这类“scratch your own itch”很容易被浪漫化。自己需要并不代表市场需要。Buttondown 真正跨过那道线，是朋友、陌生用户开始使用，而且有人愿意为它付费。Justin 曾提到，早期付费用户里甚至有美国威斯康星州的图书馆系统，用它发送新书更新。这和典型“科技创业用户画像”完全不同，却恰好证明一个小而清楚的产品可以被不同人理解。\n\n## 很长时间，它只是下班后的项目\n\nButtondown 不是两个月冲出来然后融资扩张。Justin 当时有全职工程工作，先长期把它当业余项目维护。公开采访显示，他在 Stripe 工作期间持续做 Buttondown，等业务规模足以支撑自己以后，才离开全职岗位。\n\n这条路径降低了一个关键风险：产品不用在发布后的几个月里立刻证明自己能养活创始人。代价则是增长更慢，晚上和周末会被占用，而且你必须对维护工作有耐心。\n\nJustin 对这种选择一直很明确。他并不想走融资、快速扩团队、追求退出的传统创业路径。Buttondown 官方到今天仍然强调自己是独立、自筹资金的公司，并把真人支持、可迁移的数据、相对克制的产品设计当作卖点。\n\n## “功能少”只有在取舍清楚时才成立\n\nButtondown 不是永远拒绝功能。它后来加入自动化、付费订阅、分群、评论、调查等能力，团队也已经不再是一个人。但它的产品结构仍然尽量把复杂能力放在用户需要时再出现。\n\n这和“为了做 MVP 少做几个页面”不是一回事。真正的克制来自对主任务的理解：用户来这里是为了维护订阅者并发送邮件，不是为了操作一个庞大的营销软件。\n\n它的当前定价也体现这种思路：很小的列表可以免费使用，额外能力按模块增加费用。定价方式当然会继续变化，但逻辑很稳定——尽量让基础发送这件事简单，把更复杂的业务能力放到需要它的人身上。\n\n## 拥挤市场里，机会经常藏在“我不想成为谁”\n\nButtondown 最有价值的地方，不是证明“newsletter 还能做”。而是说明竞品分析不能只数产品数量。\n\n如果一个市场里所有主流产品都在向同一个方向变重，就可能留下另一群用户：他们并不想要完整平台，只想要其中一个核心任务被处理得干净一点。\n\n当然，做“小而美”也有硬约束。邮件不是纯前端玩具，发送信誉、退订、垃圾邮件、域名认证、合规、投递率都需要长期维护。真正的门槛并不是界面做得简洁，而是你愿不愿意把这些看不见的麻烦接过来。\n\nJustin 做了很多年。这个时间尺度比“周末做一个 SaaS”更接近 Buttondown 的真实故事。",{"id":94,"slug":95,"title":96,"summary":97,"category":31,"series":32,"created_at":12,"updated_at":12,"view_count":13,"author":98,"sources":99,"content":111},"academy-story-plausible","plausible-324-days-and-one-blog-post","Plausible：324 天才到 400 美元 MRR，后来发生了什么","Plausible 的早期增长并不快。创始团队公开复盘过：从第一个付费用户到 400 美元 MRR 用了 324 天，而真正的转折来自一篇击中用户立场的文章。",{"username":15},[100,104,107],{"label":101,"url":102,"note":103},"Plausible：How we bootstrapped our Google Analytics alternative to $500k ARR","https:\u002F\u002Fplausible.io\u002Fblog\u002Fbootstrapping-saas","收入数据由 Plausible 自己披露。",{"label":105,"url":106},"Plausible 官方 About","https:\u002F\u002Fplausible.io\u002Fabout",{"label":108,"url":109,"note":110},"Plausible：How we built a $1M ARR open source SaaS","https:\u002F\u002Fplausible.io\u002Fblog\u002Fopen-source-saas","收入与客户数据为公司自报。","如果只看成熟后的 Plausible，很容易把它想成“踩中隐私趋势，所以自然增长”。创始团队自己写过的早期数据并不支持这种轻松叙事。\n\nPlausible 在 2019 年有了第一个付费用户，但从那时到月经常性收入 400 美元，用了 324 天。对于独立开发者来说，这个时间比“发布当天冲榜”更值得记住，因为很多真实产品的前几个月就是没有戏剧性。\n\n## 慢，并不代表什么都没发生\n\nPlausible 最初由 Uku Taht 开始开发，目标是做一个简单、轻量、隐私友好的 Google Analytics 替代品。2020 年 Marko Saric 加入，负责营销和沟通。两个人没有融资，也没有大规模投广告。\n\n早期产品面对一个很现实的难题：Google Analytics 免费、功能强、市场教育几乎已经完成。只说“我们也能看 PV”没有说服力。Plausible 需要把差异变成一个用户真正愿意站队的理由。\n\n这个理由后来越来越清楚：少收数据、不依赖 cookies、界面简单、脚本轻，同时接受“它不会提供 GA 那么多追踪能力”这个取舍。\n\n## 一篇文章带来的不是 SEO 小技巧，而是立场共振\n\n2020 年 4 月，Plausible 发布《Why you should stop using Google Analytics on your website》。团队后来公开复盘，这篇文章登上 Hacker News 后，几天内吸引了超过 5 万阅读，并在一周带来 166 个新试用；在此之前，他们 15 个月的网站总独立访客约 2.73 万。\n\n这个反差很大，但如果把它总结成“去 Hacker News 发文章”就学错了。\n\n真正有用的是内容与产品主张完全一致。文章不是泛泛讲“分析工具怎么选”，而是直接挑战目标用户正在使用的默认方案，再解释为什么团队选择另一套做法。读者即便不同意，也能立刻理解 Plausible 为什么存在。\n\n很多产品内容的问题就在这里：文章有流量，却和产品没有关系。Plausible 的那篇文章反而是产品定位本身的延伸。\n\n## 开源也没有自动带来生意\n\nPlausible 是开源产品。用户可以自己部署，官方则提供托管订阅。开源让代码、技术选择和产品方向更透明，也降低了一部分信任门槛，但“代码公开”不会自动产生收入。托管版仍然必须提供足够省事的体验，才能让用户愿意付钱而不是自己维护。\n\n2022 年，Plausible 官方披露 ARR 达到 100 万美元、团队仍然很小。今天它已经比最初复杂得多，但公司继续强调独立、自筹资金和隐私优先。这里同样应当区分事实层级：这些财务数字来自公司自己的公开记录，不是第三方审计报告。\n\n## 对独立开发者更重要的是前 324 天\n\n成功案例最容易删除掉等待期。Plausible 把等待期写了出来。\n\n这给了三个更现实的判断。\n\n第一，几个月增长慢，不足以单独证明产品错误。你要看的是用户是否持续使用、有没有人愿意付钱、定位是否越来越清楚，而不是只看发布当天。\n\n第二，内容增长不是“写很多”。一篇和产品立场强绑定、能进入目标用户讨论场的文章，可能比几十篇泛 SEO 内容更有价值。\n\n第三，差异化必须允许你放弃一部分市场。Plausible 不会满足所有分析需求，正因为它接受这个边界，隐私和简单才不是一句广告词。\n\n如果一个产品需要解释十分钟用户才知道它为什么存在，先别急着做内容矩阵。Plausible 的转折提醒人：有时候你真正缺的不是流量，而是一句足够明确、足够值得讨论的产品主张。",{"id":113,"slug":114,"title":115,"summary":116,"category":117,"series":118,"featured":4,"created_at":12,"updated_at":12,"view_count":13,"author":119,"sources":120,"content":128},"academy-business-carrd","carrd-small-product-low-price-business","Carrd：一个功能不多的建站工具，为什么低价反而是生意的一部分","Carrd 没有和 Wix、Squarespace 比谁功能更多，而是把产品压到“一页网站”这个范围。低价不是促销动作，而是和产品复杂度、获客方式、用户预期一起设计的。","business","小生意拆解",{"username":15},[121,124],{"label":122,"url":123},"HackerNoon：Founder Interviews — AJ of Carrd","https:\u002F\u002Fhackernoon.com\u002Ffounder-interviews-aj-of-carrd-175736bedaf6",{"label":125,"url":126,"note":127},"SaaS Club：Carrd founder AJ — side project to profitable SaaS","https:\u002F\u002Fsaasclub.io\u002Fpodcast\u002Fcarrd-founder-aj-side-project-to-profitable-saas\u002F","节目中的收入与历史定价来自创始人采访，不代表 Carrd 当前价格。","Carrd 的产品定义很容易被低估：做响应式的一页网站。和完整建站平台相比，它少了大量能力，也没有试图把电商、博客、CMS、团队协作全塞进来。\n\n如果只从功能表看，这像是“做少了”。从生意角度看，恰恰因为范围被压得很窄，Carrd 才能采用一套大型建站平台不容易照搬的组合：更低的价格、更短的学习路径、更快的首次成功，以及很大一部分依靠口碑和产品本身完成的获客。\n\n## 它没有正面挑战 Wix\n\n创始人 AJ 在早期采访里说得很清楚：他知道 Wix、Squarespace 已经存在，所以没有打算做另一个全能建站平台。他选择一页网站，是因为这个范围既符合自己的前端和模板经验，也足够解决大量真实场景——个人主页、活动页、链接页、简单 Landing Page。\n\n这是一种典型的小生意切法：不是找一个“没人做”的市场，而是在大市场里找到一个可以单独成立的任务。\n\n用户真正要完成的是“我今天需要一个能发出去的页面”，而不是“我需要拥有一套网站基础设施”。当任务这么窄，产品可以删掉很多东西。\n\n## 历史上的低价，和产品边界互相支撑\n\nCarrd 早期以很低的年费提供 Pro。公开访谈中曾出现每年 9 美元、19 美元一类历史价格。今天的具体方案会变化，所以不能拿旧数字当现价，但它的定价思路值得拆。\n\n低价 SaaS 最大的问题不是“赚得少”，而是你是否有能力用足够低的成本服务用户。如果一个 20 美元年费产品需要销售演示、人工 onboarding、频繁客服、复杂数据库和昂贵 AI 推理，它几乎注定难做。\n\nCarrd 的产品结构恰好相反：用户自己搭页面，编辑器相对标准化，网站发布高度自动化，大量新用户来自别人看到 Carrd 页面、模板作品、创作者分享。产品范围越清楚，服务成本越有机会被压低；服务成本越低，低价才不是自杀。\n\n## 真正的护城河不是“便宜”\n\n任何竞争者都可以临时降价，所以低价本身不是壁垒。\n\nCarrd 更难复制的是一整套一致性：一页网站这个定位足够清楚；创建过程足够快；模板降低空白页压力；免费使用帮助用户先完成作品；Pro 再解锁自定义域名、表单等更接近正式使用的能力。\n\n这种结构让收费点靠近“我已经做完，准备认真使用”的时刻，而不是一进门就逼用户为还没体验到的价值买单。\n\n## 这门生意最难的地方\n\n第一，低客单价意味着你不能依赖昂贵获客。广告一旦太贵，回本周期会把模式拖垮。\n\n第二，用户生成网站会带来滥用、存储、域名、审核和稳定性问题。AJ 也在访谈里提到，产品规模变大后，独立维护会出现新的运营压力。\n\n第三，“简单”不是少做 UI。真正困难的是不断判断哪些功能不应该进入产品，否则价格、支持成本和体验都会慢慢向大型平台靠拢。\n\n## 今天还能不能做这种生意\n\n可以，但不能把结论理解成“再做一个 Carrd”。\n\n更值得找的是类似结构：一个大软件里存在某个高频、边界清楚、可以独立完成的任务；用户希望十分钟解决，而不是学习一套平台；交付高度自动化；使用结果本身可能带来传播。\n\n满足这些条件后，低价甚至一次性收费才有讨论空间。\n\n先决定产品要替用户省掉什么，再谈价格。Carrd 的便宜之所以成立，是因为它先把“不做什么”想明白了。",{"id":130,"slug":131,"title":132,"summary":133,"category":117,"series":118,"created_at":12,"updated_at":12,"view_count":13,"author":134,"sources":135,"content":144},"academy-business-tally-free","tally-generous-free-plan-as-distribution","Tally：把 99% 功能放进免费版，为什么不一定是在亏钱","Tally 的免费层不是传统“阉割版试用”。大量功能和提交量免费，真正收费的是品牌、团队和企业控制能力。关键不是大方，而是免费用户会帮助产品继续分发。",{"username":15},[136,139,142],{"label":137,"url":138},"Tally 官方：Plans & pricing","https:\u002F\u002Ftally.so\u002Fhelp\u002Fplans-and-pricing",{"label":140,"url":141},"Tally 官方 Pricing","https:\u002F\u002Ftally.so\u002Fpricing",{"label":39,"url":40,"note":143},"收入、用户与转化相关数字来自 Tally 自己披露。","“免费给太多，用户就不会付钱”是 SaaS 定价里很常见的直觉。Tally 选择了相反方向。\n\n它长期公开强调，绝大部分功能可以免费使用，表单和提交也给得非常宽松。付费版主要卖的是去品牌、自定义域名、团队协作，以及更强的数据留存、邮箱验证等企业能力。\n\n这不是慈善策略。Tally 是自筹资金公司，官方明确说订阅费就是业务收入来源。要理解它为什么敢把免费层做大，需要先看表单产品特殊的分发结构。\n\n## 一个免费用户，会把产品展示给更多人\n\n普通后台工具的使用过程是私密的。你用一个数据库客户端，别人不会看到。\n\n表单不同。一个人创建表单以后，会把链接发给几十、几百甚至更多填写者。免费版如果保留 Tally 品牌，就等于每一个活跃创建者都在帮产品制造新的曝光入口。\n\n这就是为什么“免费用户成本”不能只看服务器账单。还要看他是否带来分发。\n\nTally 官方在增长复盘里把这条循环写得很直白：免费产品降低尝试门槛，用户创建更多表单，表单上的品牌继续让新的人看到产品，其中一部分再成为创建者或付费用户。\n\n## 免费层解决完整任务，付费层解决更严肃的场景\n\n很多 freemium 产品的问题是：免费版只够玩，不够完成工作。用户体验到的不是价值，而是限制。\n\nTally 的设计更接近另一种逻辑：个人和小团队可以真的把表单跑起来；当表单变成正式业务资产，用户才开始在意品牌、自定义域名、多人协作、数据控制、企业治理。\n\n这类收费点有一个共同特点：它们通常和“业务成熟度”一起增长。\n\n一个刚验证需求的人可能不在乎 Tally Logo；一家正式对外收集客户资料的团队更在乎。一个人做问卷不需要团队权限；公司开始协作以后需要。大量免费能力因此不一定直接吃掉付费需求。\n\n## 这套模式为什么不能乱抄\n\n第一，免费用户的边际成本必须可控。Tally 有 Fair Use Policy，并不是无限承诺任何极端用量。高文件存储、大规模邮件、超高提交量都会产生真实基础设施成本。\n\n第二，产品需要自然分发。如果你的免费用户不会把任何东西分享出去，免费层就主要是一项获客成本，而不是增长循环。\n\n第三，付费需求必须真实存在。如果所谓 Pro 只是把免费版故意锁住的基础功能解开，用户会感到被勒索；如果 Pro 能对应更专业、更商业化的场景，升级理由才稳定。\n\n第四，免费策略需要足够长的现金跑道。一个高推理成本的 AI 产品照搬“99% 免费”，可能几天就把账烧穿。\n\n## 判断自己的产品能不能这么做\n\n可以画一张非常简单的表。\n\n免费用户每月真实成本是多少？他会不会让其他人看到产品？免费状态下能不能完成一个完整任务？什么变化会让他自然需要付费？这些付费能力是不是只有重度用户才会在意？\n\n如果四个问题都有好答案，大方的免费层可能是一种分发设计。\n\n如果免费用户成本很高、没有传播、付费点又只是人为限制，那就不是 Tally 模式，只是在补贴使用。\n\n“免费多少”没有标准答案。Tally 值得研究的不是那个 99%，而是它把免费、传播和付费场景连成了同一条产品路径。",{"id":146,"slug":147,"title":148,"summary":149,"category":117,"series":118,"created_at":12,"updated_at":12,"view_count":13,"author":150,"sources":151,"content":160},"academy-business-photopea","photopea-free-tool-ad-supported-economics","Photopea：免费浏览器工具靠广告赚钱，真正成立的条件是什么","广告模式不是“有流量就能赚钱”。Photopea 的特殊之处在于重计算主要发生在用户设备、使用时长长、免费价值完整，才让广告和 Premium 有机会共同成立。",{"username":15},[152,154,157],{"label":153,"url":52},"Siesta Labs：Ivan Kutskir \u002F Photopea interview",{"label":155,"url":55,"note":156},"Indie Hackers：Photopea founder story","历史收入数字为创始人公开自述。",{"label":158,"url":159},"Photopea","https:\u002F\u002Fwww.photopea.com\u002F","很多免费工具站会把商业模式写成一句话：流量起来以后放广告。\n\n这句话遗漏了最难的部分。大多数工具的用户停留时间短、回访低、服务器成本还不低，广告收入可能根本覆盖不了计算、存储和带宽。Photopea 能长期走广告路线，是因为它的产品结构非常特殊。\n\n## 用户不是来“查一下”，而是来工作\n\nPhotopea 是完整度很高的浏览器图片编辑器。一个用户可能在页面里停留几十分钟甚至更久，反复操作、打开文件、导出结果。和单位换算、临时二维码这类一次几十秒的工具相比，广告可以获得更多展示机会。\n\n更关键的是，编辑工作大量发生在浏览器本地。用户自己的设备承担了相当部分计算。Photopea 当然仍然有网站、服务和开发成本，但它不是每一次滤镜、每一个图层动作都要调用昂贵云端计算。\n\n这会直接改变免费产品的经济模型。\n\n## 广告没有把核心功能切碎\n\nPhotopea 的免费用户能完成真正的图片编辑任务。Premium 的价值之一是去广告以及获得额外体验，但产品并不是“免费只能打开，付费才能保存”这种强硬切割。\n\n这让免费版本身有传播能力。用户不需要先判断订阅值不值，就可以直接开始工作。产品解决的问题又足够普遍：临时没有 Photoshop、设备不能安装软件、需要打开 PSD、需要在 Chromebook 或共享电脑上处理文件，都可能成为入口。\n\n创始人 Ivan Kutskir 多次公开说过广告是主要收入来源，并在不同年份分享过收入数据。具体数字都是创始人自报，而且随年份变化，不适合作为今天的确定财务结论。更可靠的事实是：Photopea 从 2017 年开始商业化广告，并长期维持免费主产品。\n\n## 广告模式最容易被误判的三个成本\n\n第一个是流量质量。页面访问量很大，不等于广告价值高。地区、用户时长、广告位、屏蔽率都会影响收入。\n\n第二个是基础设施。若你的“免费工具”每次使用都要调用大模型、生成视频或处理巨型文件，单次成本可能远高于广告带来的收入。Photopea 的浏览器计算优势很难直接复制到云端 AI 产品。\n\n第三个是产品体验。广告位太激进会破坏工具本身，最终压低留存。广告不是页面空位变现，而是用一部分注意力换收入。\n\n## 什么样的免费工具更有机会采用广告\n\n至少需要观察四件事。\n\n用户一次会停留多久？一个月会回来几次？主要计算发生在谁的机器上？如果没有付费墙，免费用户是否仍然会主动推荐？\n\n使用时长长、回访稳定、边际成本低的工具，比“进来一次就走”的工具更适合广告。再加上 Premium 去广告、企业授权、API 等补充收入，会比单一广告更稳。\n\n## 不要从广告开始设计产品\n\nPhotopea 最早几年根本没有广告收入。它先把 PSD 解析、图形编辑和兼容性做深，用户增长以后才开始商业化。\n\n这说明顺序很重要：先证明一个免费工具值得长期使用，再选择适合它的变现方式。\n\n如果一个页面留不住人，增加广告不会把它变成生意；如果一个工具每次使用都在替用户解决高价值任务，广告只是众多收费方式中的一种。\n\nPhotopea 真正值得抄的不是广告位，而是那张成本结构图：价值主要来自本地软件能力，用户使用时间长，免费版本完整，服务器边际成本相对可控。没有这些前提，“免费 + 广告”只是愿望。",{"id":162,"slug":163,"title":164,"summary":165,"category":117,"series":118,"created_at":12,"updated_at":12,"view_count":13,"author":166,"sources":167,"content":174},"academy-business-plausible-open-source","plausible-open-source-hosted-saas-business","Plausible：代码都开源了，为什么用户还愿意按月付费","开源并不会自动毁掉 SaaS 收费。Plausible 把“你可以自己部署”和“我们替你稳定托管”同时摆在桌面上，卖的不是代码访问权，而是省事、持续维护与产品信任。",{"username":15},[168,170,173],{"label":108,"url":109,"note":169},"收入和客户数来自 Plausible 自己披露。",{"label":171,"url":172},"Plausible 官方订阅方案文档","https:\u002F\u002Fplausible.io\u002Fdocs\u002Fsubscription-plans",{"label":105,"url":106},"“如果代码开源，别人自己部署不就行了？”这是开源 SaaS 最直观的疑问。\n\nPlausible 正好提供了一个清楚的反例。它的核心代码可以公开查看和自托管，官方同时经营托管版订阅。用户买的不是“允许使用这段代码”的许可证，而是把安装、升级、监控、备份、性能、可用性和持续维护交给团队。\n\n## 自托管免费，为什么不是付费版的敌人\n\n因为“技术上能部署”和“我愿意长期维护”是两件事。\n\n一个开发者当然可以自己拉代码、准备数据库、配置域名和备份。但对一家只想看网站流量的公司，这些工作没有直接商业价值。每次升级、故障排查和数据迁移都是额外负担。\n\n托管 SaaS 把这部分麻烦打包成服务。对用户来说，比较的不是“软件价格 vs 0”，而是“订阅费用 vs 自己承担运维成本”。\n\n这也是大量开源商业产品常见的收费基础：开源降低试用和信任门槛，托管把维护工作商品化。\n\n## Plausible 还多了一层：开源和品牌主张是一致的\n\nPlausible 卖的是隐私友好的网站分析。用户天然会问：你到底收什么数据？有没有隐藏追踪？开源让技术实现可以被检查，至少比完全黑盒更容易建立信任。\n\n这并不意味着“开源 = 自动可信”。用户仍然需要判断官方运行的托管服务实际如何处理数据。但产品定位、代码透明和公开经营方式彼此支持，比把开源只当获客噱头更有力量。\n\n## 收费并不是固定一口价\n\nPlausible 当前托管版根据页面浏览量和功能层级收费，提供 Starter、Growth、Business、Enterprise 等方案，并允许月付或年付。它没有永久免费托管计划，而是提供无信用卡的试用期。\n\n这个选择和 Tally 的大免费层明显不同。原因并不神秘：分析产品每个网站都会持续产生数据存储和处理成本，免费用户不是零成本。不同业务的成本结构，会直接影响 freemium 是否合理。\n\n## 开源 SaaS 仍然有四个难题\n\n第一，官方托管必须比自部署明显省事。如果安装已经简单到几乎零维护，用户付费动力会变弱。\n\n第二，开源项目容易出现第三方托管和分叉。你的品牌、服务质量、升级速度和社区关系必须提供额外价值。\n\n第三，不能把开源当作“不用做销售和增长”。Plausible 早期真正的增长转折来自内容、Hacker News、口碑和明确定位，不是把仓库公开以后用户自动出现。\n\n第四，许可证选择会影响别人能怎样使用代码。不同许可证的商业限制差异很大，不能从 Plausible 的结果反推“任何项目都应该开源”。\n\n## 哪些项目值得考虑这种模式\n\n比较适合的是：开发者或技术团队愿意自托管；软件长期运行需要运维；用户对透明度和可控性在意；官方托管能显著减少麻烦。\n\n数据库工具、监控、分析、自动化、内部工具平台都可能满足这些条件。\n\n如果产品本身只是一个静态页面生成器，自托管几乎没有持续成本，那开源托管模式就未必有足够付费空间。\n\nPlausible 的核心启发很朴素：不要问“代码值多少钱”，要问“用户愿意花多少钱，少管这些代码”。",{"id":176,"slug":177,"title":178,"summary":179,"category":117,"series":118,"created_at":12,"updated_at":12,"view_count":13,"author":180,"sources":181,"content":189},"academy-business-buttondown","buttondown-small-saas-pricing-and-service","Buttondown：小团队做邮件 SaaS，为什么还要提供真人服务","邮件工具的表面功能很容易复制，真正麻烦的是投递、迁移、域名、数据和长期支持。Buttondown 把克制的产品、按需付费和人工服务组合在一起。",{"username":15},[182,185,186],{"label":183,"url":184},"Buttondown 官方 Pricing","https:\u002F\u002Fbuttondown.com\u002Fpricing",{"label":83,"url":84},{"label":187,"url":188},"Buttondown Customer Stories","https:\u002F\u002Fwww.buttondown.com\u002Ftestimonials","邮件 SaaS 很适合拿来说明一个误区：界面简单，不代表业务简单。\n\n从用户侧看，Buttondown 的核心动作只有几个——导入订阅者、写邮件、预览、发送。真正让创作者愿意长期付钱的，却有大量东西不会出现在首页截图里：邮件能不能送达，域名认证有没有配置好，退订是否正确，列表迁移是否丢数据，付费订阅有没有出错，遇到问题有没有人处理。\n\n## 小产品也可以把服务当作差异化\n\nButtondown 官方一直强调独立、小团队和真人支持。它甚至公开承诺帮助用户迁移 newsletter。\n\n这在“大规模 SaaS 必须尽量消灭人工”思路里看起来不够高效，但对于小团队，它反而可能是定位的一部分。\n\n如果用户数量没有大到需要几百人的支持中心，而每个客户的生命周期价值足够覆盖一部分人工服务，那么创始人直接回答问题可以成为竞争优势。大型平台的客服流程很难为了一个小客户临时修改产品，小团队可以。\n\n当然，这只有在规模可控时成立。支持量一旦超过团队能力，“服务好”会直接变成创始人的时间债务。\n\n## 当前定价体现的是“基础简单，复杂按需”\n\nButtondown 目前对很小的订阅者列表提供免费使用，基础能力包含编辑器、自定义发送域名、公开归档等。标签分群、付费订阅、调查、分析、自动化、白标、团队等功能则以附加能力或更高层级收费。\n\n另一个细节是按活跃订阅者而不是所有历史联系人计费。它试图让账单更接近用户实际使用。\n\n这类模块化定价的好处是，小用户不需要为一整套企业功能买单；复杂用户则可以按需求叠加。坏处也很明显：价格解释会比一个固定套餐更复杂，用户可能需要计算自己到底会付多少。\n\n## 邮件 SaaS 的真正成本在哪里\n\n第一是基础设施。邮件发送量增长后，服务商成本会上升。\n\n第二是投递信誉。用户的内容质量、退信、投诉都会影响邮件生态，这是持续运营问题，不是把 Send 按钮接上 API 就结束。\n\n第三是迁移成本。newsletter 往往积累多年订阅数据，用户不愿轻易换工具。新产品想抢客户，就得让迁移足够安全。\n\n第四是信任。订阅者列表可能是创作者最重要的资产之一，数据可导出、隐私策略、故障响应都比华丽功能重要。\n\n## 为什么它不是“做得简单就能赚钱”的例子\n\nButtondown 的简单是表层结果，背后接走了大量麻烦。\n\n一个值得付费的小工具通常都这样：用户看到的步骤更少，是因为产品承担的责任更多，而不是因为问题本身简单。\n\n所以拆一个 SaaS 时，不要只看页面功能。把用户原本要自己处理的麻烦列出来，再看产品替他接走了多少。Buttondown 接走的是发送基础设施、投递细节、列表管理和一部分迁移风险。\n\n真正的小生意价值，往往藏在那些用户不想学、也不想每天管的事情里。",{"id":191,"slug":192,"title":193,"summary":194,"category":195,"series":196,"created_at":12,"updated_at":12,"view_count":13,"author":197,"sources":198,"content":202},"academy-opportunity-crowded-market","crowded-market-can-still-be-an-opportunity","市场已经很拥挤了，还值不值得做？先看所有产品是不是都在往同一边走","竞品多不等于机会消失。Tally 和 Buttondown 都进入了成熟老市场，它们找到的不是“没人做”，而是主流产品不断变重后留下的一群用户。","opportunities","机会雷达",{"username":15},[199,201],{"label":200,"url":37},"Tally：How we ended up building the simplest way to create forms",{"label":86,"url":87},"看到一个市场已经有十几个产品，最容易做的动作是关掉页面：太卷了。\n\n但“竞品数量”本身是个很粗的指标。真正值得看的，是这些产品是不是正在向同一个方向演化。如果大家都在做更多功能、服务更大的团队、提高客单价，就可能在另一边留下一个被忽略的需求：有人只想把一件事做完，不想买整个平台。\n\n## Tally 和 Buttondown 都不是新品类\n\nTally 做表单时，Google Forms、Typeform、Jotform 等产品早就存在。Buttondown 做 newsletter 时，邮件营销更是一个成熟到不能再成熟的市场。\n\n两边创始人的抱怨却很像：现有工具能完成任务，但越来越重，价格结构或产品逻辑并不适合自己这类用户。\n\nTally 把表单编辑做得像写文档，大量能力免费；Buttondown 则尽量把发送 newsletter 这件事从完整营销套件里拆出来。\n\n它们不是靠“新功能没人有”进入市场，而是靠“我不想要这么多东西”。\n\n## 判断拥挤市场，别只做竞品功能表\n\n功能表往往会把你带到错误方向：A 有 30 个功能，B 有 26 个，所以我要做到 35 个。\n\n更有用的办法是给竞品画趋势。\n\n过去三年，它们主要新增了什么？目标用户从个人变成团队了吗？价格在上升吗？导航越来越复杂吗？销售流程是不是从自助购买变成预约 Demo？哪些功能被放进更贵的套餐？\n\n如果这些变化都指向“大客户、更多功能、更高价格”，就要去找另一侧的人：谁只需要核心任务？谁在抱怨迁移成本、学习成本和价格？\n\n## 机会通常来自一个明确的“不”\n\n一个小产品很难用资源打赢成熟公司，但可以拒绝它们不得不接受的复杂度。\n\n例如：不做 CRM，只做 newsletter；不做完整网站，只做一页站；不追踪个人，只给聚合分析；不做 100 个表单模板，先把编辑体验做到足够顺。\n\n这个“不”必须对应一群真实用户，而不是创始人自己的审美。\n\n验证方式很直接：去竞品评论、Reddit、论坛、帮助中心和价格页里找重复抱怨。用户有没有明确说“我只想要 X，却被迫买 Y”？有没有人因为某次产品升级变复杂而寻找替代品？有没有大量教程专门教人绕过某个麻烦？\n\n重复出现的绕路，往往比一条“希望新增功能”更接近机会。\n\n## 什么时候拥挤就真的是坏消息\n\n如果所有产品都已经很便宜、很简单、迁移成本低，而且核心功能几乎没有差异，小团队再进去可能只剩价格战。\n\n如果用户选择主要靠品牌采购、渠道关系、合规认证或大规模数据，而你的优势只是 UI 更漂亮，也很难成立。\n\n还有一种情况更常见：你发现一个小众抱怨，但用户并不愿意换工具。痛点存在，不代表迁移意愿存在。\n\n## 一个实用的筛选问题\n\n研究成熟市场时，问一句：\n\n“如果我只能比现有产品少做一半，我会删掉什么；删掉以后，哪一类用户反而更喜欢？”\n\n如果答不出来，说明你只是想做一个功能更少的复制品。\n\n如果能明确回答，而且那群用户正在增长、愿意迁移、愿意付钱，拥挤反而是好事——市场教育已经有人做完，你只需要证明另一种取舍也能成立。",{"id":204,"slug":205,"title":206,"summary":207,"category":195,"series":196,"created_at":12,"updated_at":12,"view_count":13,"author":208,"sources":209,"content":215},"academy-opportunity-privacy","privacy-regulation-can-create-product-opportunities","隐私和规则变化，怎么从“合规成本”变成新的产品机会","Plausible 和 Simple Analytics 都不是因为分析软件消失了才出现，而是用户开始对追踪方式产生新的要求。规则变化会增加成本，也会重写用户的购买标准。",{"username":15},[210,211,212],{"label":105,"url":106},{"label":66,"url":67},{"label":213,"url":214},"ICO：Cookies and similar technologies","https:\u002F\u002Fico.org.uk\u002Ffor-organisations\u002Fdirect-marketing-and-privacy-and-electronic-communications\u002Fguide-to-pecr\u002Fcookies-and-similar-technologies\u002F","规则变化经常被创业者当作一张待办清单：加 Cookie Banner、更新 Privacy Policy、找律师。\n\n换一个角度看，规则会改变用户购买软件时在意的东西。一旦原来的默认方案变得更麻烦、更有风险，市场里就可能出现新的产品位置。\n\n隐私分析工具就是很典型的例子。\n\n## 用户需求不是“我要 GDPR”，而是“我不想再处理这些麻烦”\n\nPlausible 和 Simple Analytics 都把“不追踪个人、尽量不用 cookies、减少数据收集”作为产品核心。它们不是单纯卖合规文件，而是重新设计分析能力：少拿一些数据，换更轻的实现、更简单的后台，以及更容易解释的数据处理方式。\n\n英国 ICO 对非必要 cookies 的要求很明确：要告诉用户在做什么，并在适用情况下获得有效同意；严格必要的技术存在例外。具体法律义务需要根据地区和业务判断，但对产品经理来说，已经足够看到一个变化——每多一个追踪工具，企业就多一份识别、披露、管理和维护责任。\n\n所以有一部分客户愿意为“少一点能力、少一点麻烦”付钱。\n\n## 法规型机会有三个层次\n\n第一层是直接合规工具，例如 consent management、数据请求处理、审计记录。\n\n第二层是“更容易合规”的替代产品，例如隐私分析、欧盟托管表单、数据留存控制。它们解决原任务，但改变默认的数据处理方式。\n\n第三层更有意思：当公司为了合规重新梳理流程，会暴露很多原先被手工掩盖的问题。谁有权限、数据在哪、多久删除、供应商有哪些、用户怎么提出删除请求——每一个都可能形成工作流产品。\n\n## 但不要把“有法规”误判成“有市场”\n\n法规制造的是约束，不会自动制造付费意愿。\n\n如果大平台已经免费把合规能力做好，小工具可能没有空间。如果客户的购买决策必须经过大型审计、保险和长期合同，一个人做的 SaaS 也可能根本进不去。\n\n更要避免一种危险做法：靠恐吓营销，把复杂法律问题说成“用了我们的工具就一定合规”。软件只能处理其中一部分技术和流程，法律责任不会因为买了一个插件自动消失。\n\n## 怎么找这类机会\n\n不要先搜“2026 合规创业风口”。先看规则让谁增加了重复工作。\n\n运营人员是不是在手工登记用户删除请求？开发者是不是每接一个第三方 SDK 都要重新维护数据清单？小公司是不是知道需要隐私说明，却不知道自己实际收了哪些数据？某个平台是不是突然要求开发者填写更严格的隐私字段？\n\n这些工作如果频繁、容易出错、可以被结构化，就比“做一个 GDPR AI 助手”更具体。\n\n## 最值得留意的是购买标准变化\n\n一个市场真正发生变化，往往不是新品类突然出现，而是旧产品的评分标准变了。\n\n过去用户选分析工具可能主要看功能；后来一部分客户开始同时看 cookies、数据位置、留存、供应商和透明度。Plausible、Simple Analytics 就是在新的评分标准里获得了位置。\n\n机会雷达要找的不是热词，而是这种变化：以前不重要的条件，什么时候开始足以影响购买。",{"id":217,"slug":218,"title":219,"summary":220,"category":195,"series":196,"created_at":12,"updated_at":12,"view_count":13,"author":221,"sources":222,"content":229},"academy-opportunity-platform","platform-marketplaces-for-small-products","Chrome 扩展、Shopify App：为什么平台生态适合做小产品","平台生态替开发者解决了一部分分发和身份问题：用户已经在那里、安装路径已经存在、需求也更具体。但平台同时拥有规则、审核和抽成权。",{"username":15},[223,226],{"label":224,"url":225},"Chrome Web Store 官方文档","https:\u002F\u002Fdeveloper.chrome.com\u002Fdocs\u002Fwebstore",{"label":227,"url":228},"Shopify App Store requirements","https:\u002F\u002Fshopify.dev\u002Fdocs\u002Fapps\u002Flaunch\u002Fshopify-app-store\u002Fapp-store-requirements","独立开发最难的经常不是写代码，而是“做出来以后谁会看到”。\n\n平台生态提供了一种不同的起点。Chrome 用户会主动去扩展商店找能力，Shopify 商家会在 App Store 找经营工具。你不需要从零教育用户“浏览器扩展是什么”或“商店插件怎么安装”，平台已经把一部分分发、支付或授权流程做成基础设施。\n\n这也是为什么平台生态里常见很小但能收费的产品。\n\n## 需求边界天然更窄\n\n一个 Shopify App 通常围绕商家的某个流程：库存、订单、营销、评价、物流、数据同步。Chrome 扩展则常常只改一个浏览器动作：保存、整理、输入、阅读、截图、自动填写。\n\n这种约束对小团队是好事。\n\n如果你从“做一个营销平台”开始，范围会迅速失控；如果从“帮助 Shopify 商家解决一个明确的订单流程”开始，用户、数据和工作场景都更具体。\n\n平台 API 也会告诉你什么能做、什么不能做，反而逼着产品边界清楚。\n\n## 分发并不是免费流量\n\n进入商店不等于有人安装。\n\nChrome Web Store 官方文档专门要求开发者准备 Listing、隐私字段、截图、描述并通过审核；Shopify 对功能、安全、计费、隐私、API 使用和商店信息有详细要求。平台会提供搜索和浏览入口，但排名、评价、转化仍然要靠产品本身。\n\n真正省掉的是“用户为什么敢安装陌生软件”的一部分信任成本，以及标准化安装流程。\n\n## 平台机会通常藏在工作流缝隙里\n\n最值得找的不是“平台现在最火的类目”，而是用户每天从平台复制数据出去、再贴回来的地方。\n\n例如，商家从 Shopify 导出 CSV 再去处理；浏览器用户每次都要把网页内容复制进另一种工具；某个后台没有批量操作，大家靠脚本补；某种报告平台能生成，但格式不适合真正交付。\n\n这些动作如果频繁发生，插件或 App 就有可能直接嵌进原工作流。\n\n## 平台依赖也是最大的风险\n\n做平台生意，必须接受自己不是规则制定者。\n\nAPI 会废弃，审核标准会改，权限可能收紧，计费要求会调整，商店算法也不会为你的收入负责。Shopify 当前就明确要求公共 App 使用其规定的计费和平台能力；Chrome 扩展需要遵守单一用途、隐私和商店政策。\n\n所以这类生意不能只问“开发成本低不低”，还要问：如果平台明天改一个权限，我的核心价值还在吗？能不能导出用户数据？有没有站外品牌和客户关系？\n\n## 适合独立开发者的原因\n\n平台生态把市场缩小了，也把上下文补全了。\n\n你知道用户已经使用某个平台，知道他大概在做什么，也能从评论、论坛、现有插件评分里看到具体抱怨。相比“给所有企业做 AI 助手”，问题容易验证得多。\n\n真正值得做的通常不是最大类目，而是一个被大 App 忽略的小步骤：付费用户不需要很多，只要问题足够具体、价值足够直接。\n\n先去看用户怎么绕路，再决定写什么插件。",{"id":231,"slug":232,"title":233,"summary":234,"category":195,"series":196,"featured":4,"created_at":12,"updated_at":12,"view_count":13,"author":235,"sources":236,"content":241},"academy-opportunity-search-demand","from-search-query-to-product-opportunity","从搜索词反推产品：别先想功能，先看用户已经在主动找什么","搜索不是只用来做 SEO。一个人把问题打进 Google 时，已经表达了主动需求。关键词真正有价值的地方，是帮助你区分“有人讨论”和“有人正在找解决方案”。",{"username":15},[237,238],{"label":21,"url":22},{"label":239,"url":240},"Google Search Console：Performance report","https:\u002F\u002Fsupport.google.com\u002Fwebmasters\u002Fanswer\u002F7576553?hl=en-GB","很多人把关键词研究放在产品上线以后：网站做好了，接下来找些词做 SEO。\n\n顺序也可以反过来。搜索词本身就是需求研究材料，尤其适合工具、计算器、转换器、模板、查询器、生成器这类目标明确的产品。\n\n用户愿意打开搜索框并描述问题，至少说明他正在主动寻找答案。这个信号通常比“看到帖子顺手点个赞”更接近行动。\n\n## 先区分信息需求和任务需求\n\n“how does mortgage work” 和 “mortgage calculator” 都有人搜，但产品机会完全不同。\n\n前者主要想理解知识，内容可能是最合适的交付；后者已经在表达一个动作，希望输入数字得到结果。\n\n同样，“what is favicon” 更像知识，“favicon generator” 更像工具；“how to resize image” 可能既能用教程满足，也可能说明用户需要一个无需安装的软件。\n\n找产品机会时，优先留意那些带动作、对象和输出的查询：convert、calculate、generate、check、compare、download、remove、compress、track、template 等只是英文里的常见形式，中文也有“计算、生成、查询、转换、检测、模板”。\n\n## 搜索量不是商业价值\n\n一个月搜索很多次，不代表值得做。\n\n要继续看三个东西。\n\n第一，结果页现在是谁在满足需求。如果 Google 自己直接给出答案，独立网站空间可能很小；如果前几名都是专门工具，说明用户愿意离开搜索页完成任务。\n\n第二，用户完成任务以后有没有更深需求。一次性算完就走的工具适合广告或引流，未必适合订阅。\n\n第三，需求和付费之间有多远。“免费在线压缩图片”可能流量巨大，但用户未必愿意按月付；“团队批量处理品牌素材”用户少得多，却可能更接近商业购买。\n\n## 用关键词发现“需求簇”，不要追单个词\n\n单个关键词很容易误导。\n\n更有效的是把相近表达放在一起，看它们是不是指向同一个任务。例如用户围绕“i ching online \u002F three coin method \u002F changing lines”搜索时，背后可能有起卦、方法学习、结果理解几种不同任务；它们不应该机械地被塞进一个页面，也不能因为近义就复制十个页面。\n\nGoogle 自己的搜索文档也强调：SEO 的核心是帮助搜索引擎理解内容，同时让真正寻找这些内容的人找到你。关键词是用户语言，不是页面数量指标。\n\n## 一个从词到产品的最小流程\n\n先收集具体查询，不要急着算分。\n\n把每个词写成一句用户任务：“他想在五分钟内得到什么？”然后看现有结果能不能顺利完成。再检查：有没有重复抱怨、明显付费产品、论坛讨论、替代方案搜索。\n\n如果一个任务有持续搜索、结果页存在专门产品、用户仍然抱怨现有方案，而且你能用更低成本或不同取舍解决，才值得进产品验证。\n\n## 搜索真正提供的是“主动性”\n\n关键词研究最有价值的不是一张 Volume 表，而是它让你看到用户已经在用自己的语言描述问题。\n\n对于没有受众、没有自媒体流量的独立开发者，这很重要。你不需要先拥有十万粉丝，市场每天已经有人公开说自己在找什么。\n\n接下来要做的不是把所有词变成 SEO 页面，而是挑出其中真正像任务的需求，看看能不能变成一个小而完整的产品。",{"id":243,"slug":244,"title":245,"summary":246,"category":195,"series":196,"created_at":12,"updated_at":12,"view_count":13,"author":247,"sources":248,"content":252},"academy-opportunity-ai-workflow","ai-opportunity-start-from-verifiable-workflow","找 AI 产品机会，先找“重复而且能验收”的工作，不要先找聊天框","AI 很容易把任何产品都变成一个输入框。更扎实的机会通常来自一条已经存在的工作流：步骤重复、判断耗时、结果还能被检查。",{"username":15},[249],{"label":250,"url":251},"BacklinkOS：公开生产工作流与职责边界","https:\u002F\u002Fgithub.com\u002Fpyxm1618\u002FBacklinkOS","AI 产品最容易出现一种倒置：先决定“我要做 AI”，再去找一个场景套上输入框。\n\n结果通常是用户说一句话，模型返回一段看起来不错的文字。Demo 很快，真正使用时却很难回答三个问题：结果对不对？错了怎么办？为什么用户下周还要再来？\n\n换一个寻找机会的方法：先找一条已经有人反复做的工作流。\n\n## 什么叫“重复而且能验收”\n\n重复，是这件事每周、每天甚至每个项目都会发生，不是偶尔灵感来了才做。\n\n能验收，是输出存在某种可检查标准。可以是链接是否真的上线、数据是否匹配、页面是否返回 200、合同是否缺字段、表格是否写入、测试是否通过。\n\n这两点组合起来，比“AI 帮我想一想”更适合做产品。\n\n因为 AI 可以承担其中模糊、耗时的判断，但最终状态仍然能由程序、人工或外部事实核验。\n\n## 一个真实例子：外链工作流\n\n以公开的 BacklinkOS 项目为例，它没有把需求写成“AI 自动做 SEO”。真实流程被拆成候选发现、平台事实维护、项目 Backlog、现场验证、浏览器执行、结果回写。\n\n其中有些步骤适合模型做语义判断，有些必须由浏览器真实打开页面，有些必须用确定性规则去重，有些状态只有提交以后才能知道。\n\n这种拆法比一个万能 Agent 更像产品，因为每一步都有输入、输出和失败状态。\n\n更重要的是，系统明确保留 UNKNOWN，而不是让模型为了“完成任务”编一个答案。这个设计思想可以迁移到很多 AI 工具。\n\n## 去哪里找这样的工作\n\n看人们的 Excel、复制粘贴、浏览器标签页和 SOP。\n\n一项工作如果需要在五个网站之间搬数据，再按规则判断，最后写进表格，就是候选；如果客服每天都要读相似邮件、查订单、套规则、再给出处理建议，也是候选；如果研究人员重复搜索、摘录、去重、分类，再输出清单，也有机会。\n\n先别问模型能不能做。先把人工流程画出来。\n\n## AI 最适合夹在确定性步骤之间\n\n一个可靠的 AI 产品往往不是“全程 AI”。\n\n例如抓取页面可以用确定性代码；理解页面属于什么类型可以交给模型；真正提交表单要由浏览器执行；提交是否成功要重新读取页面或后台状态；最终记录要写入数据库。\n\n模型在这里负责那些过去很难写死规则的环节，而不是负责宣布“任务成功”。\n\n## 这种机会为什么更容易收费\n\n因为用户已经在为这条工作付时间。\n\n你不需要先教育他“AI 很厉害”，只要证明原来两个小时的流程能缩到二十分钟，并且结果可追踪。他购买的是时间和稳定性，不是模型名称。\n\n收费也更容易和工作量绑定：每个项目、每次运行、每个处理对象、每月额度，都比“无限聊天”更接近价值单位。\n\n## 最后一条筛选标准\n\n如果去掉 AI 两个字，你还能清楚描述这个产品替用户完成什么工作吗？\n\n如果不能，机会大概率还没找到。\n\n如果能，而且流程重复、结果可验收、错误可恢复，再考虑模型放在哪一步。这样的 AI 产品可能没那么像魔法，但更接近一门可以长期经营的小生意。",{"id":254,"slug":255,"title":256,"summary":257,"category":258,"series":259,"created_at":12,"updated_at":12,"view_count":13,"author":260,"sources":261,"content":267},"academy-build-auth","does-your-mvp-need-login","MVP 第一版到底要不要做登录？先看它是不是核心任务的前提","登录很容易被当成“正式产品标配”，但它会带来账户、邮件、密码恢复、数据删除和安全责任。第一版要不要做，应该从核心任务是否需要身份连续性判断。","build","从 0 到 1",{"username":15},[262,264],{"label":263,"url":141},"Tally Pricing：无需注册也可开始创建表单",{"label":265,"url":266},"Quick I Ching：公开版产品边界","https:\u002F\u002Fgithub.com\u002Fpyxm1618\u002Fquickiching","新产品最常见的一组页面是：首页、注册、登录、忘记密码、个人中心。它们让产品看起来完整，却不一定让用户更快完成核心任务。\n\n要不要做登录，不该从“别人都有”判断，而要先问：用户第一次获得价值，必须知道他是谁吗？\n\n## 身份连续性有用，才值得付出账户成本\n\n需要登录的典型场景很清楚：用户要跨设备保存长期数据；多人协作需要区分权限；购买记录、订阅、积分要绑定主体；敏感信息不能只靠一条公开链接访问；业务必须知道谁创建、修改或删除了某项内容。\n\n如果这些条件一个都没有，登录可能只是额外摩擦。例如一个计算器、转换器、临时生成器，用户的核心任务是“输入 → 得到结果”。强制注册不会提高结果质量，只会把第一次成功推迟。\n\nQuick I Ching 的公开 SEO V1 就采用了这种边界：免费起卦不依赖生产登录、数据库、支付和 AI 凭据，完成记录可以由用户主动保存到浏览器本地。未来商业版如果需要云端历史、付费次数和个性化，再启用账户体系。这个例子不是通用答案，但它说明身份可以晚于核心任务出现。\n\n## 登录真正带来的工作远比两个输入框多\n\n一旦有账户，就要决定注册方式、邮箱验证、忘记密码、会话过期、第三方 OAuth、账号合并、注销、数据删除、封禁、异常登录和隐私说明。\n\n如果再和支付绑定，还要处理更麻烦的问题：账户删了以后，订单、退款和财务记录怎么办？这些记录是否可以一起删除，要根据业务和适用规则判断，不能简单把用户主记录清掉就结束。\n\n所以登录不是 UI 功能，而是一套身份基础设施。\n\n## 第一版其实有三种选择\n\n第一种完全匿名。适合一次性任务，不要求跨设备连续性。\n\n第二种“先用后登录”。用户先完成核心动作，在保存、同步、分享或付费时再创建账户。很多工具更适合这种路径，因为用户先知道产品值不值。\n\n第三种一开始登录。适合数据天然私密、多人协作、企业权限或账户本身就是产品的一部分。\n\n关键不是哪个更高级，而是登录出现的时机是否和用户价值一致。\n\n## 一个简单的判断表\n\n上线前逐项回答：不登录，用户能不能完整体验最核心价值？数据必须跨设备保存吗？有没有多人权限？有没有必须绑定身份的付费权益？匿名使用会不会造成明显滥用或安全风险？\n\n如果前几项大多是否，最后一项也可控，第一版通常有理由不做强制登录。\n\nMVP 的任务是验证核心价值。登录如果不是价值的一部分，也应该接受同一个问题：它现在不做，会不会让验证结果失真？不会，就可以晚一点。",{"id":269,"slug":270,"title":271,"summary":272,"category":258,"series":259,"featured":4,"created_at":12,"updated_at":12,"view_count":13,"author":273,"sources":274,"content":280},"academy-build-ai-spec","write-verifiable-ai-coding-task","让 AI 写代码之前，先把任务写成一份能验收的施工单","“帮我把支付做好”不是开发任务。AI Coding 更稳定的前提，是把现状、边界、业务规则、禁止事项和验收条件写清，让模型知道什么叫完成。",{"username":15},[275,278],{"label":276,"url":277},"creat-web：公开 README 与发布门禁","https:\u002F\u002Fgithub.com\u002Fpyxm1618\u002Fcreat-web",{"label":279,"url":266},"Quick I Ching：公开产品边界与验证命令","AI 写代码速度很快，所以很多失败也发生得很快。\n\n最典型的任务是：“把支付功能完善一下”“全面优化 SEO”“把登录修好”。人类开发者看到这种任务也需要追问，模型却很可能直接开始改。最后代码不少，真正的业务规则反而被它顺手改掉。\n\n解决办法不是研究一句更神的 Prompt，而是把开发任务写成能验收的施工单。\n\n## 第一部分先写现状，不要让模型自己猜\n\n至少说明仓库、技术栈、生产环境、相关模块现在做到哪里。更重要的是告诉它哪些事实已经成立。\n\n例如：“收费模式是次数包，不是订阅”“只有任务真正生成成功才扣次数”“失败必须释放冻结额度”。这些不是实现建议，而是业务规则。模型不能因为某个支付 SDK 更适合订阅，就顺便把产品改成订阅。\n\n如果有已经上线的模块、不能移动的目录、历史方案但尚未接入的代码，也要明确写出来。复杂仓库里，“存在”不等于“正在使用”。\n\n## 第二部分写边界：这次不做什么\n\n这是 AI Coding 特别需要的一段。人类工程师通常会凭经验判断不要顺便重构整个系统，模型却容易把“发现问题”理解成“应该一起解决”。因此可以直接写：不重新设计产品；不改商业规则；不扩大到移动端；不做无关性能优化；不要顺手更换框架。\n\n边界越明确，任务越容易收口。\n\n## 第三部分把模糊目标改成可观察状态\n\n“支付正常”无法验收。可以拆成：创建订单成功；重复请求不会创建两笔订单；支付成功事件重复投递不会重复发权益；生成失败不消费次数；退款以后权益变化有确定结果；生产回调签名被验证。\n\n每一条最好都能通过测试、数据库状态、接口响应或真实页面验证。\n\ncreat-web 这类模板项目会保留 typecheck、unit、integration、contract、security、SEO、commerce、E2E 等不同门禁。一次构建成功只能证明代码能被打包，不能证明业务链路成立。\n\n## 第四部分告诉 AI 证据优先级\n\n遇到文档、代码、生产状态互相矛盾时，模型需要知道信谁。已经锁定的业务规则优先；当前真实代码和数据库状态其次；历史设计文档只能提供背景；注释和 README 如果与运行事实冲突，需要先核实而不是盲从。\n\n外部 API 也一样。支付、认证、框架能力会更新，涉及版本和当前行为时，应先看对应官方文档，而不是依赖模型记忆。\n\n## 第五部分写清楚停止条件\n\n很多任务失败不是修不好，而是没有停止条件。例如：“只修下面已经确认的 5 项；全部测试通过后停止，不继续做全面审计。”这会显著降低无限找 bug、无限扩范围的风险。\n\n一份可执行任务至少有六块：背景和现状、目标、不可改变的业务规则、本轮范围、禁止范围、验收清单。涉及生产时，再增加部署、回滚和真实验证要求。\n\nAI Coding 的瓶颈正在从“代码写不出来”变成“到底应该写什么、什么叫正确”。把施工单写清楚，就是把最贵的判断留在人手里，把大量实现工作交给机器。",{"id":282,"slug":283,"title":284,"summary":285,"category":258,"series":259,"created_at":12,"updated_at":12,"view_count":13,"author":286,"sources":287,"content":293},"academy-build-verification","build-passed-is-not-production-ready","Build 通过不等于能上线：小产品至少要过哪几层验收","构建成功只证明依赖和代码能产出部署包。登录、支付、数据库迁移、权限和真实浏览器流程仍可能全部有问题。验收应该一层层缩小“不确定”。",{"username":15},[288,291],{"label":289,"url":290},"OWASP Application Security Verification Standard","https:\u002F\u002Fowasp.org\u002Fwww-project-application-security-verification-standard\u002F",{"label":292,"url":277},"creat-web：公开验证流水线","“已经能 build 了”是开发里最容易制造错觉的一句话。\n\n构建通过通常说明：依赖能安装、语法和打包链路没有阻断性错误、框架能够产出部署产物。它不保证用户能登录，不保证付款以后权益真的到账，也不保证管理员看不到别人的数据。\n\n产品上线前，需要把不同风险拆成不同验收层。\n\n## 第一层：静态检查\n\n类型检查、Lint、编译和依赖安装属于这一层。它们便宜、速度快，应该尽早跑。\n\n静态检查很擅长发现类型不一致、无效导入、明显语法问题，却看不到业务语义。例如一个退款接口把金额乘错 100 倍，只要类型还是 number，TypeScript 不会替你报警。\n\n## 第二层：确定性业务测试\n\n把重要规则做成单元或集成测试。例如积分只能扣一次、匿名用户不能读私有记录、过期订单不能再发货、同一个 webhook 重放不会重复加权益。这些规则越接近钱和权限，越不应该只靠人“点过一次”。\n\n测试的价值不只是上线前。三个月以后改另一处代码时，它能告诉你旧规则有没有被破坏。\n\n## 第三层：真实依赖链路\n\nMock 能证明自己的代码按预想调用了一个接口，但不能证明第三方真的接受。\n\n认证回调 URL、支付 webhook、邮件域名、数据库权限、对象存储 CORS、生产环境变量，很多问题只有接到真实或官方 sandbox 才暴露。支付至少要跑 provider 测试环境，OAuth 要走一次完整回调，数据库迁移要在空库和已有数据路径都检查。\n\n## 第四层：浏览器中的完整任务\n\n接口都正确，页面仍可能坏。按钮被遮住、移动端弹窗超出屏幕、登录以后重定向错、付款成功页面读到旧状态、表单校验和后端规则不一致，都属于真实用户路径的问题。\n\n至少把核心链路从用户入口走到最终结果，按风险覆盖未登录、已登录、失败和重试分支。\n\n## 第五层：安全和权限\n\nOWASP ASVS 把 Web 应用安全拆成身份、会话、访问控制、输入、API、数据保护等系统性要求。小产品没必要机械追求大型金融系统的全部等级，但“规模小”不是跳过权限边界的理由。\n\n最基本的问题包括：服务端是否重新验证身份；用户能否改 URL 读到别人的对象；敏感接口是否依赖浏览器传来的角色；密钥有没有进入客户端包；预览环境会不会被搜索引擎收录。\n\n## 第六层：生产环境冒烟\n\n部署成功以后再做一次最小验证：打开真实域名、确认 HTTPS 和重定向、检查首页与核心接口、跑一条不会破坏真实数据的用户路径、观察日志和错误监控。\n\n验收不是测试越多越好。页面文案错一个字可以上线后改；重复扣款、越权读取和数据迁移错误必须在前面拦住。\n\n把风险分层以后，“能上线”不再是一个模糊感觉，而是一串证据。Build 只是第一张。",{"id":295,"slug":296,"title":297,"summary":298,"category":258,"series":259,"created_at":12,"updated_at":12,"view_count":13,"author":299,"sources":300,"content":310},"academy-build-domain","domain-dns-ssl-deployment-explained","域名、DNS、SSL、部署是什么关系？上线时别把四件事混在一起","域名是名字，DNS 决定名字指向哪里，部署平台真正运行代码，TLS\u002FSSL 负责 HTTPS 身份和加密。四层任何一层错了，用户都可能只看到“网站打不开”。",{"username":15},[301,304,307],{"label":302,"url":303},"Cloudflare Learning Center：What is DNS?","https:\u002F\u002Fwww.cloudflare.com\u002Flearning\u002Fdns\u002Fwhat-is-dns\u002F",{"label":305,"url":306},"Vercel：Adding & Configuring a Custom Domain","https:\u002F\u002Fvercel.com\u002Fdocs\u002Fdomains\u002Fworking-with-domains\u002Fadd-a-domain",{"label":308,"url":309},"Cloudflare：What is an SSL certificate?","https:\u002F\u002Fwww.cloudflare.com\u002Flearning\u002Fssl\u002Fwhat-is-an-ssl-certificate\u002F","第一次上线网站时，最容易把“域名接好了”理解成“网站已经部署好了”。其实用户在浏览器输入一个网址以后，中间至少经过四层：域名、DNS、部署服务和 HTTPS 证书。\n\n把它们拆开，排错会简单很多。\n\n## 域名：你买的是一个可管理的名字\n\n例如 example.com。注册商负责登记你对这个名字的使用权和管理入口，但注册商并不会自动运行你的代码。\n\n域名到期、注册信息或 Nameserver 配置属于这一层。\n\n## DNS：告诉全世界这个名字应该去哪里\n\nDNS 可以理解成互联网的名称解析系统。A 记录把域名指向 IPv4 地址，AAAA 指向 IPv6，CNAME 常用来把一个名字别名到另一个主机名；不同平台还会用 TXT 做域名验证。\n\n你可以在一家注册商买域名，把 DNS 托管给 Cloudflare，再把记录指向 Vercel。这三个角色完全可以是三家公司。\n\n所以“我在 Vercel 加了域名，但打不开”时，要先确认 DNS 是否真的指到了 Vercel 要求的位置，而不是重复部署代码。\n\n## 部署：代码到底在哪里运行\n\nVercel、Cloudflare Pages、自建服务器等负责真正托管构建产物或运行应用。\n\n以 Vercel 为例，项目部署以后会先有平台域名。绑定自定义域名只是给这份部署增加一个新的访问入口。Vercel 官方流程也是先把域名加入项目，再根据提示配置 DNS；如果 Nameserver 不由 Vercel 管理，就需要在外部 DNS 服务商处增加它要求的记录。\n\n部署失败和 DNS 失败是两类问题。前者可能是构建、环境变量、运行时错误；后者通常是解析记录、传播或域名配置。\n\n## TLS\u002FSSL：为什么浏览器愿意显示 HTTPS\n\nHTTPS 不只是“地址栏有把锁”。证书帮助客户端验证正在连接的域名身份，并参与建立加密连接。\n\n现代托管平台通常会在域名解析正确后自动签发和续期证书；Cloudflare 作为代理时又多了一层浏览器到 Cloudflare、Cloudflare 到源站的连接配置。\n\n这也是为什么错误的代理或 SSL 模式可能造成重定向循环、证书错误：两端都在根据自己理解强制 HTTPS。\n\n## 排错时按顺序看\n\n第一，域名有没有过期，Nameserver 当前是谁。\n\n第二，用 DNS 查询确认 A、CNAME、TXT 是否是预期值，而不是只看控制台“已保存”。\n\n第三，查看部署平台的项目状态和平台预览域名是否能打开。如果平台域名也坏，先修部署。\n\n第四，DNS 正确以后看平台是否已确认域名并签发证书。\n\n第五，再检查 www 与裸域、HTTP 与 HTTPS 的重定向是否只有一套明确规则。\n\n记住这张关系图就够：注册商让你拥有域名；DNS 告诉别人去哪；部署平台在那里运行网站；TLS 让这个连接以 HTTPS 安全建立。网站打不开时先判断是哪一层，再动手。",{"id":312,"slug":313,"title":314,"summary":315,"category":258,"series":259,"created_at":12,"updated_at":12,"view_count":13,"author":316,"sources":317,"content":324},"academy-build-payment","payment-integration-is-state-machine","第一次接支付，最难的不是付款按钮，而是重复请求、回调和状态","支付会遇到超时、重试、异步回调和重复事件。真正可靠的系统必须做到同一个业务动作不会被执行两次，并且不能把“用户跳回成功页”当成到账事实。",{"username":15},[318,321],{"label":319,"url":320},"Stripe：Idempotent requests","https:\u002F\u002Fdocs.stripe.com\u002Fapi\u002Fidempotent_requests",{"label":322,"url":323},"Stripe：Receive events in your webhook endpoint","https:\u002F\u002Fdocs.stripe.com\u002Fwebhooks","支付 Demo 很容易做：点一个按钮，跳到收银台，付款完成，再回到成功页面。\n\n真正上线以后，麻烦从网络不稳定那一刻开始。用户点了付款，浏览器超时，于是又点一次；服务器请求支付平台成功了，但响应在路上断掉，于是代码重试；支付已经完成，webhook 过几秒才到；平台发现 webhook 没及时返回，又重新投递。\n\n如果系统把每一次请求都当成新动作，结果可能是重复订单、重复扣款、重复发积分。\n\n## 第一个概念：幂等\n\nStripe 官方 API 明确支持 idempotency key，用来安全重试创建或更新请求。相同 key 的后续请求会返回第一次请求的结果，从而避免因为网络重试再次执行同一操作。\n\n但支付系统不能把幂等完全外包给支付平台。自己的数据库也要有业务唯一性：一个 checkout session、一个支付事件、一个订单发货动作，应该有稳定 ID 和唯一约束或事务保护。\n\n否则 webhook 收到两次，平台没重复扣款，你仍然可能给用户发两次权益。\n\n## 第二个概念：异步事实\n\n用户从支付平台跳回成功页，只说明浏览器走到了这个 URL，不代表系统应该立刻把订单改成 paid。\n\n成功页参数可以被手工构造，浏览器也可能在支付最终状态还没同步时先回来。更可靠的做法是：支付平台的签名事件或服务端查询成为付款事实来源，本地订单根据经过验证的事实更新。页面只读取当前订单状态并展示。\n\nStripe 的 webhook 文档也把支付确认、争议、周期性付款等列为典型异步事件，并要求服务端验证签名。\n\n## 第三个概念：回调会重复\n\nWebhook handler 要假设同一事件可能重新送达。\n\n先记录 provider event id 是否处理过，再在事务内做状态变更和权益发放。处理成功后快速返回 2xx；复杂工作可以进入持久化任务队列，而不是让 webhook 请求一直等模型生成、发邮件或做大计算。\n\n如果任务失败，要有可重试状态，而不是“接口报 500，下次看运气”。\n\n## 第四个概念：付款和交付是两个状态\n\n卖一个 PDF，支付成功后可以立即生成下载权限；卖 AI 解读，付款成功以后还要调用模型并产出结果；卖次数包，则付款成功是增加余额，真正使用时再消费。\n\n这几个动作不能混成一个 paid 状态。至少要区分订单支付、权益和具体交付任务。这样生成失败时，才能明确是退款、重试还是释放预留次数，而不是靠人工猜用户现在到底欠没欠一次服务。\n\n## 上线前至少做五个破坏性测试\n\n连续点两次购买；创建订单响应超时后重试；同一个成功 webhook 重放两次；付款成功但交付任务失败；用户不经过收银台直接打开成功页。\n\n再根据业务加入退款、取消订阅、支付失败等分支。\n\n支付系统可靠的标准不是“正常付款一次成功”，而是异常发生时钱和权益仍然对得上。按钮只是入口，真正的支付产品是一台状态机。",{"id":326,"slug":327,"title":328,"summary":329,"category":10,"series":11,"featured":4,"created_at":12,"updated_at":12,"view_count":13,"author":330,"sources":331,"content":336},"academy-growth-seo","what-seo-is-actually-doing","SEO 到底在做什么：让一个真实需求落到一个最合适的页面","SEO 最容易被做成关键词密度和批量发文。更稳定的起点是把搜索词还原成用户任务，再让站点结构、页面内容和技术信号共同说明“这个页面解决什么”。",{"username":15},[332,333],{"label":21,"url":22},{"label":334,"url":335},"Google Search Central：Spam policies","https:\u002F\u002Fdevelopers.google.com\u002Fsearch\u002Fdocs\u002Fessentials\u002Fspam-policies","SEO 很容易被做成一套动作：找词、把词塞进标题、写几千字、买几条外链、等排名。\n\n问题是，搜索引擎真正要解决的并不是“哪个页面最努力做 SEO”，而是“哪个结果最适合当前这次搜索”。所以独立开发者做 SEO，第一步不是内容生产，而是需求映射。\n\n## 先把关键词翻译成人话\n\n用户搜“png to webp”，通常不是想读一篇图片格式历史。他希望上传文件并得到转换结果。\n\n用户搜“what is webp”，则更可能在找解释。两个词都包含 webp，页面形态却完全不同。前者应该优先让工具完成任务，后者适合文章或文档。\n\n关键词研究真正要回答的是：这个人现在要完成什么？\n\n## 一个需求，一个主要页面\n\n很多新站看到十个近义词，就做十个几乎一样的页面。这样做的麻烦不只是文案重复，还会让你自己无法说明这些页面有什么不同。\n\nGoogle 的 canonical 文档解释过，系统会对重复或高度相似页面做聚类并选择代表性 URL。站长可以给出 canonical 等信号，但搜索引擎仍会根据页面判断代表版本。\n\n更合理的做法是先聚类意图。用户任务相同，就让一个强页面覆盖自然变体；任务明显不同，再拆页面。\n\n## SEO 页面首先必须是产品或内容\n\n工具页应该真的能用，比较页应该真的比较，教程应该让用户做完某件事。\n\n如果页面存在的唯一理由是承载一个关键词，通常会出现大量空话：先解释定义，再列优点，再放 FAQ，最后引导注册，却迟迟不给用户要的结果。\n\nGoogle 当前垃圾内容政策反对关键词堆砌、规模化低价值内容和以操纵排名为主要目的的行为。对独立开发者更实用的理解是：别为了覆盖词表制造页面库存。\n\n## 技术 SEO 是让正确内容能被正常理解\n\n内容对了，还要确保搜索引擎能访问。页面应该返回正确 HTTP 状态；重要内容不能被误设 noindex；站内链接要能到达；canonical、sitemap、重定向和多语言关系不能互相打架；移动端和真实用户体验也不能坏。\n\n这些工作不直接创造需求，只是防止已有价值因为技术错误丢失。\n\n## 最后才是竞争\n\n同一个需求已经有很多好页面时，你仍然要回答：为什么用户应该点你？\n\n可能是工具更快、数据更新、解释更清楚、无需注册、免费层更合理、某个地区更适配，也可能是你拥有别人没有的一手数据。如果没有任何更好的地方，只靠“文章更长”通常不够。\n\n每个准备做的页面只写五项：目标用户任务、主要搜索表达、页面类型、用户完成任务后的结果、与现有结果相比的理由。五项说不清，就先别写正文。\n\nSEO 不是把搜索引擎当漏洞，而是把已经存在的搜索需求接到一个明确、可访问、值得留下的页面上。",{"id":6,"slug":7,"title":8,"summary":9,"category":10,"series":11,"created_at":12,"updated_at":12,"view_count":13,"author":338,"sources":339,"content":23},{"username":15},[340,341],{"label":18,"url":19},{"label":21,"url":22},{"id":343,"slug":344,"title":345,"summary":346,"category":10,"series":11,"created_at":12,"updated_at":12,"view_count":13,"author":347,"sources":348,"content":355},"academy-growth-indexing","why-google-cannot-find-new-site","新网站上线后 Google 为什么搜不到？按抓取、索引、排名三层排查","“搜不到”可能是 Google 还没发现页面、发现但没有索引，或者已经索引却排得太后。三个问题的排查方法完全不同，先用 Search Console 判断处在哪一层。",{"username":15},[349,350,353],{"label":21,"url":22},{"label":351,"url":352},"Google Search Console：URL Inspection","https:\u002F\u002Fsupport.google.com\u002Fwebmasters\u002Fanswer\u002F9012289",{"label":239,"url":354},"https:\u002F\u002Fsupport.google.com\u002Fwebmasters\u002Fanswer\u002F7576553","新域名上线两天，搜索品牌名没有结果，很容易得出结论：SEO 有问题。\n\n先别改标题。Google“搜不到”至少可能是三个完全不同的问题：没抓到、没索引、排不上来。\n\n## 第一层：Google 知不知道这个 URL\n\n新站没有外链、没有提交 sitemap、内部链接又弱，搜索引擎可能还没发现某些页面。\n\n先在 Search Console 用 URL Inspection 检查具体 URL，而不是不停用搜索命令猜。再确认 sitemap 已提交，重要页面从首页或其他可抓取页面有普通链接能到达。\n\nGoogle 官方也提醒，新页面被发现和抓取需要时间，并不存在“提交以后立刻收录”的保证。\n\n## 第二层：抓到了，为什么没进索引\n\n页面可能被 noindex、robots 配置、错误状态码、重定向或 canonical 影响。\n\n预览环境最常见的问题之一，是上线时忘了移除原本为 staging 准备的 noindex。另一个常见问题是多个版本同时存在：HTTP、HTTPS、www、裸域、参数页互相竞争，canonical 又指向错误地址。\n\n还有一种情况不是技术故障：Google 抓到了页面，但认为它和站内其他内容重复、价值不足或不适合作为代表 URL，因此暂时不索引。\n\n这时候继续提交十遍没有意义，要检查页面本身。\n\n## 第三层：已经索引，只是没有排名\n\nSearch Console Performance 报告如果已经出现 impressions，说明页面至少在某些查询里被展示过。用户肉眼搜不到，可能只是位置太后。\n\n这时问题从“收录”变成“竞争力”。目标词是不是和页面意图一致？前面的结果是不是更专业、更有权威、更直接完成任务？你的站点是不是一个完全没有历史的新域名？内部链接是否让重要页面显得孤立？\n\n这些都不是改 sitemap 能解决的。\n\n## 不要把品牌词和通用词混在一起判断\n\n一个刚上线的网站，品牌名如果足够独特，通常比高竞争通用词更容易出现。\n\n如果品牌词都长期没有，优先检查发现和索引；如果品牌词能搜到，核心行业词排不到，更可能是内容、竞争和站点信号问题。\n\n## 新站上线后的最小动作\n\n确认生产域名只有一个 canonical 版本；所有正式页面返回正确状态；预览环境 noindex；robots 没误拦；sitemap 只包含希望索引的 canonical URL；重要页面有站内链接；Search Console 验证并提交 sitemap；用 URL Inspection 抽查首页和核心页。\n\n然后给搜索系统时间。\n\n抓取解决“能不能看到”；索引解决“愿不愿意收”；排名解决“为什么是你”。先定位，再动手。",{"id":357,"slug":358,"title":359,"summary":360,"category":10,"series":11,"created_at":12,"updated_at":12,"view_count":13,"author":361,"sources":362,"content":367},"academy-growth-backlinks","what-backlinks-are-worth-building","外链有没有用？先把“真实推荐”“可提交入口”和垃圾链接分开","链接能帮助用户和搜索引擎发现站点，也可能形成推荐信号，但不是所有外链都等价。批量自动制造链接、付费传递排名权重和低质目录，反而属于 Google 明确列出的风险行为。",{"username":15},[363,365],{"label":364,"url":335},"Google Search Central：Spam policies \u002F Link spam",{"label":366,"url":251},"BacklinkOS：公开外链发现与执行工作流","“外链有用吗”这个问题太大，因为一条媒体文章里的自然引用、一个产品目录提交、一个付费软文链接和一万条自动论坛签名，技术上都叫 backlink，价值和风险却完全不同。\n\n独立开发者更需要先分类。\n\n## 第一类：别人真的因为内容或产品提到你\n\n用户写测评、开发者在文档里引用你的工具、媒体报道、合作伙伴正常链接，这类链接首先是推荐和分发。\n\n它可能直接带来访问，也帮助搜索引擎发现页面。最重要的是，它存在的理由不是“给你做 SEO”，而是对方内容需要这个链接。\n\n这类最难批量制造，也往往最值得长期追求。\n\n## 第二类：产品和公司本来就该出现的入口\n\n例如与你产品类型匹配的目录、应用商店、开源列表、行业数据库、合作生态页面。\n\n这类入口的价值常常不止排名：有人真的在那里找工具，能带来 referral traffic、品牌曝光和第一批用户。\n\n但目录也有质量差异。Google 当前垃圾链接政策明确把“低质量目录或书签站链接”列为 link spam 示例之一，所以“能提交”从来不是足够标准。\n\n要看平台本身有没有真实用户、页面会不会被索引、是否与你的产品相关、提交内容是不是正常产品资料。\n\n## 第三类：为了排名而制造的链接\n\n买卖传递排名权重的链接、过度交换、自动程序批量创建链接、到论坛用关键词签名刷链接，都在 Google 的 link spam 示例里。\n\n广告和赞助链接并不是不能存在，但官方要求这类关系适当标记，例如 sponsored 或 nofollow，不要伪装成自然编辑推荐来传递排名信号。\n\n所以“买外链能不能涨排名”不是一个安全的长期增长策略问题，而是你愿意承担多大的算法与人工处罚风险。\n\n## 外链工作本身也应该像运营，不是撒网\n\n公开的 BacklinkOS 工作流把候选发现、平台事实、项目适配、实际提交和最终上线状态分开，正是因为“找到一个域名”不等于“获得一个有效链接”。\n\n真正执行时要知道入口是否还活着、是否允许你的项目类型、是否需要登录、最终页面有没有上线、链接属性是什么。\n\n这比买一个“1000 backlinks”套餐麻烦得多，但更接近事实。\n\n## 新站应该先做哪一种\n\n先完成那些本来就合理的身份和产品入口：公司或作者资料、GitHub、真正相关的产品目录、平台生态、合作伙伴页面。\n\n同时做值得被引用的资产：工具、原创数据、模板、研究、清楚的教程。没有任何可引用内容，外链工作会永远变成人工求链接。\n\n判断一条外链值不值得做，可以问三个问题：如果 Google 明天完全不计算链接权重，这个入口还有没有真实用户价值？它和我的产品是否真的相关？为了得到它，我是否需要做自己不愿公开承认的操作？\n\n外链不是数字收藏。它最好先是一条真实的互联网关系，然后才可能成为搜索信号。",{"id":369,"slug":370,"title":371,"summary":372,"category":10,"series":11,"created_at":12,"updated_at":12,"view_count":13,"author":373,"sources":374,"content":384},"academy-growth-launch","product-hunt-reddit-launch-is-not-lottery","Product Hunt、Reddit 冷启动：别把发布日当流量抽奖","发布平台可以带来第一批真实用户，但“扔个链接等爆”通常没用。Product Hunt 重视完整 Launch 页面和社区互动；Reddit 对自我推广和垃圾行为有明确规则。",{"username":15},[375,378,381],{"label":376,"url":377},"Product Hunt：How to launch on Product Hunt","https:\u002F\u002Fwww.producthunt.com\u002Flaunch",{"label":379,"url":380},"Product Hunt：Prepare for launch","https:\u002F\u002Fhelp.producthunt.com\u002Fen\u002Farticles\u002F479557-how-to-prepare-for-your-launch",{"label":382,"url":383},"Reddit Help：Spam","https:\u002F\u002Fsupport.reddithelp.com\u002Fhc\u002Fen-us\u002Farticles\u002F360043504051-Spam","冷启动最诱人的想象是：产品做完，发到 Product Hunt 或 Reddit，一夜之间来几千用户。\n\n这事偶尔发生，但不能拿它当增长计划。发布平台真正稳定的价值，是把一个已经能工作的产品放进目标人群面前，快速得到第一批点击、问题、反对意见和付费信号。\n\n## Product Hunt 的准备发生在发布前\n\nProduct Hunt 官方 Launch 指南要求准备清晰的 tagline、描述、媒体素材、maker 信息等，并鼓励创作者在发布当天真实参与讨论。\n\n这些要求看起来像运营细节，本质上逼你回答几个产品问题：一句话到底怎么解释？截图能不能让人理解核心价值？用户点进去以后能不能马上体验？\n\n如果这些还说不清，提前一周找人点赞并不会救产品。\n\n## 不要把排名当成唯一结果\n\n发布当天的票数和榜单会受时间、受众、品类和社区反应影响。即使没有冲到第一，只要带来几十个真正目标用户，也可能足够发现重要问题。\n\n应该提前定义更接近业务的指标：多少人进入产品、多少人完成核心动作、留下什么问题、有没有人愿意注册或付款、哪些描述让人误解。\n\n榜单是曝光结果，不是产品验证本身。\n\n## Reddit 更不是一个“可以发链接的流量池”\n\nReddit 的 Spam 政策会处理重复、无关、欺骗性和操纵性的推广行为。不同 subreddit 还有自己的自我推广规则。\n\n真正有效的做法通常更慢：先成为正常参与者，理解社区在讨论什么；产品只有在确实解决当前问题时才出现；帖子本身提供完整信息，而不是“我做了个工具，大家看看”。\n\n如果一个产品只能靠隐藏身份、批量发帖或伪装推荐获得点击，这种渠道很难长期维护。\n\n## 发布内容要和社区的工作对上\n\nProduct Hunt 用户愿意发现新产品，所以可以直接展示产品。Reddit 用户通常是为某个主题讨论而来，帖子应该围绕那个问题展开。Hacker News 更看重技术、创业和经验讨论。一份内容不能原封不动复制到所有平台。\n\n渠道不是流量 API，每个社区都有自己的使用习惯。\n\n## 发布后的 48 小时更重要\n\n记录所有重复出现的问题。三个人在同一步卡住，就应该回产品看；反复有人问“和 X 有什么区别”，说明定位还没讲清；有人愿意用却不愿意付费，要分清是价值不够还是收费点太早。\n\n发布前写下假设：谁会最感兴趣、他们会在哪一步感到价值、最可能反对什么、希望发生哪个转化。发布以后对照事实。\n\n这样即使流量不大，仍然能得到一轮有效学习。冷启动不是寻找一个神奇入口，而是把产品一次次送到真正可能需要它的人面前。",{"id":386,"slug":387,"title":388,"summary":389,"category":390,"series":391,"featured":4,"created_at":12,"updated_at":12,"view_count":13,"author":392,"sources":393,"content":400},"academy-operations-privacy","write-privacy-policy-from-real-data-flow","隐私政策别从模板开始：先把网站到底收了什么数据画出来","隐私政策不是页脚装饰。注册、分析、支付、日志和 AI 服务会把数据交给不同系统。先做真实数据清单，才知道应该向用户说明什么。","operations","经营手册",{"username":15},[394,397],{"label":395,"url":396},"ICO：How to write a privacy notice and what goes in it","https:\u002F\u002Fico.org.uk\u002Ffor-organisations\u002Fadvice-for-small-organisations\u002Fprivacy-notices-and-cookies\u002Fhow-to-write-a-privacy-notice-and-what-goes-in-it\u002F",{"label":398,"url":399},"ICO：What privacy information should we provide?","https:\u002F\u002Fico.org.uk\u002Ffor-organisations\u002Fuk-gdpr-guidance-and-resources\u002Findividual-rights\u002Fthe-right-to-be-informed\u002Fwhat-privacy-information-should-we-provide\u002F","很多独立网站的 Privacy Policy 来自同一个流程：找同行网站，复制一份，替换公司名和邮箱。\n\n这恰好把顺序做反了。隐私说明应该描述你的真实数据处理，而不是让产品去适配一份模板。不同地区法律要求不同，正式合规问题需要结合运营主体和目标市场确认；但产品层面有一件事可以先做，而且几乎不会错：把数据流画出来。\n\n## 从用户第一次打开网站开始列\n\n浏览首页时有没有 analytics？有没有错误监控？服务端日志记录 IP 吗？有没有 Cookie、本地存储或设备标识？\n\n注册时收什么：邮箱、手机号、Google 账号资料、头像？使用产品时又产生什么：输入内容、文件、历史记录、聊天、生成结果？这些数据是否会发给 OpenAI、Anthropic 或其他模型供应商？\n\n付款时哪些信息由你保存，哪些只由支付服务商处理？退款记录保留多久？\n\n把每个节点写成“数据 → 为什么需要 → 存在哪里 → 传给谁 → 留多久”。这张表比任何隐私模板更重要。\n\n## 第三方服务不能只写一句“可能使用合作伙伴”\n\nICO 面向英国组织的指导要求在适用情况下说明个人数据的接收方或接收方类别、处理目的、保留期或判断标准等信息。\n\n独立开发者最容易漏掉的是供应商事实。你可能没有主动“卖用户数据”，但仍然把数据交给了邮件服务、数据库托管、支付、分析、错误监控和 AI API。用户真正需要知道的是这些系统在流程里做什么，而不是一句抽象的“可信第三方”。\n\n供应商变化以后，隐私说明也应该跟着更新。\n\n## AI 产品尤其要把“输入去了哪里”说清楚\n\n用户在文本框里输入的信息可能比注册邮箱敏感得多。\n\n如果内容会被发送给第三方模型进行推理，要弄清供应商条款、数据保留和训练设置，再写进自己的数据说明。不能一边把完整对话发给外部 API，一边在政策里笼统写“您的数据仅保存在本平台”。\n\n## 不要写自己做不到的承诺\n\n“我们绝不会保留任何数据”“所有信息立即删除”“采用最高级别安全措施”听起来让人放心，但如果日志保存 30 天、备份按周期覆盖、支付记录因为合法原因需要保存，这些话反而制造风险。\n\n写可验证的事实：保存哪些类别、目的是什么、通常保留多久、用户怎样联系你行使权利。\n\n## 把隐私复核放进发布流程\n\n对照代码和后台逐项核对 analytics、cookie、数据库表、对象存储、日志、邮件、支付、AI Provider、客服工具。然后再检查政策里有没有对应描述。\n\n如果删除一个第三方 SDK，政策可以删掉；如果新增 GA4、Clarity 或新的模型服务，发布前就应该触发隐私复核。\n\n把 Privacy Policy 当成数据架构的公开版本，会比复制别人的法律长文可靠得多。",{"id":402,"slug":403,"title":404,"summary":405,"category":390,"series":391,"created_at":12,"updated_at":12,"view_count":13,"author":406,"sources":407,"content":412},"academy-operations-cookie","cookie-consent-not-every-cookie-needs-same-treatment","Cookie Banner 不是越大越合规：先分清哪些存储真的需要同意","登录会话、安全和购物篮等严格必要技术，与广告追踪、行为分析不是一回事。先做 cookie inventory，再决定哪些能直接设置、哪些必须等用户选择。",{"username":15},[408,409],{"label":213,"url":214},{"label":410,"url":411},"ICO：What are the exceptions?","https:\u002F\u002Fico.org.uk\u002Ffor-organisations\u002Fdirect-marketing-and-privacy-and-electronic-communications\u002Fguidance-on-the-use-of-storage-and-access-technologies\u002Fwhat-are-the-exceptions\u002F","有的网站一打开就弹出半屏 Banner，只有一个巨大的“Accept all”；有的网站什么都不提示，却同时加载好几个广告和分析脚本。\n\nCookie 合规不应该从设计弹窗开始，而应该从“浏览器里到底写了什么”开始。下面以英国 ICO 的公开指导说明产品思路，具体地区要求可能不同。\n\n## 先做一次 cookie inventory\n\n打开生产站，用浏览器 DevTools 检查 Cookies、Local Storage、第三方网络请求。再把所有 SDK 列出来：认证、分析、客服、广告、A\u002FB 测试、支付、嵌入视频。\n\n对每一项写清用途、供应商、持续时间、是否在用户操作前就创建。很多团队做到这里才发现，所谓“我们只用了一个统计工具”其实顺带加载了几种存储和第三方请求。\n\n## “严格必要”要从用户请求的服务判断\n\nICO 当前指导解释得很具体：严格必要指没有这项存储或访问，就无法提供用户主动请求的服务。\n\n购物篮里记住用户刚放进去的商品、为在线服务提供必要安全的会话 Cookie、负载均衡等可能符合例外；广告 Cookie 不能因为“广告收入对我们很重要”就变成严格必要。\n\n这个区别很关键，因为非必要 cookie 在适用规则下需要用户作出有效选择。\n\n## 同意不能发生在脚本已经跑完以后\n\n如果分析或广告脚本需要同意，就要把技术加载顺序和 consent 状态连起来。\n\n用户还没选择时，不应该先创建非必要 cookie，再用 Banner 告诉他“继续浏览即同意”。ICO 对有效 consent 的描述要求清楚、具体、知情并有明确积极动作；非必要 cookie 不能在用户同意前就先设置。\n\n所以 Cookie Banner 不是一段文案，而是一项运行时功能。\n\n## 拒绝以后要真的拒绝\n\nUI 上有“Reject”，但 GA、Clarity 或广告脚本已经在页面初始化时加载，是最常见的伪实现。\n\n更合理的是默认只加载严格必要能力；用户同意某类用途以后再初始化对应 Provider；撤回同意时更新状态，并尽可能停止后续非必要处理。\n\n如果产品根本不需要非必要 cookie，最简单的 Banner 往往是不做复杂追踪。\n\n## 第三方嵌入也要检查\n\nYouTube、地图、聊天组件、社交嵌入可能在页面加载时向第三方发请求。不要只搜代码里有没有写 cookie。\n\n一个完整 inventory 应该从真实浏览器网络行为出发。\n\n新增一个增长工具时，把 cookie\u002Fprivacy review 放进发布清单。Cookie 管理真正要解决的是：用户选择能不能控制实际数据行为。弹窗长什么样是第二步。",{"id":414,"slug":415,"title":416,"summary":417,"category":390,"series":391,"created_at":12,"updated_at":12,"view_count":13,"author":418,"sources":419,"content":429},"academy-operations-terms","terms-of-service-should-match-real-business","为什么不能照抄同行的 Terms：你的收费和退款规则不一样","服务条款是交易规则，不是免责声明仓库。产品卖什么、什么时候交付、怎么续费、怎样取消、什么情况下退款，都应该和代码及购买页面一致。",{"username":15},[420,423,426],{"label":421,"url":422},"UK CMA：Writing a fair contract for customers","https:\u002F\u002Fwww.gov.uk\u002Fguidance\u002Fwriting-a-fair-contract-for-customers",{"label":424,"url":425},"GOV.UK：Online and distance selling","https:\u002F\u002Fwww.gov.uk\u002Fonline-and-distance-selling-for-businesses\u002Fonline-selling",{"label":427,"url":428},"UK CMA：Selling goods and services — consumer law","https:\u002F\u002Fwww.gov.uk\u002Fguidance\u002Fselling-products-and-services-complying-with-consumer-protection-law","服务条款最危险的复制方式，是从一个看起来专业的大公司网站整页搬过来。\n\n那家公司可能卖年费订阅，你卖一次性下载；它支持某种退款窗口，你的数字内容交付规则不同；它在美国经营，你在英国或中国；它可以随时停掉企业 API，你甚至没有 API。\n\n复制以后，文案看起来正式，真实交易规则却完全对不上。\n\n不同市场的消费者保护要求会不同，正式法律文件应根据运营主体和目标地区确认。产品团队先要做的是把商业事实写准确。\n\n## 条款应该从购买流程反推\n\n先把一个用户从定价页走到离开的全过程列出来。\n\n他买的是所有权、使用权还是一段期限内的服务？价格含税吗？自动续费吗？什么时候扣下一期？取消是立即失效还是到周期末？退款规则是什么？服务失败怎么办？账号被关闭以后已购买权益怎样处理？\n\n这些问题必须先在产品和后台有答案，条款才能写。\n\n## “我们可以随时做任何事”不是好条款\n\n英国 CMA 2026 年更新的公平合同指导强调消费者条款要公平、透明。把所有风险都单方面甩给用户，并不会因为写进 Terms 就自动有效。\n\n对小产品来说，更实际的做法是少写虚张声势的免责，多写用户真正需要预判的事情：服务范围、价格、续费、取消、退款、可接受使用、账户处理、知识产权、联系方式。\n\n能用普通语言说明，就不要故意堆法律腔。\n\n## 页面和条款必须说同一件事\n\n定价页写“一次性买断”，Terms 却从模板留下“subscription renews automatically”，这是非常低级但常见的错误。\n\n退款页写 7 天，支付弹窗写“不退款”，客服又按另一套规则处理，同样会制造纠纷。\n\n所以 Terms 不应该由一个孤立文档维护。收费模型、产品配置、退款政策、账户生命周期发生变化时，要有发布清单提醒同步检查法律页面。\n\n## 数字服务尤其要把交付说清楚\n\nGOV.UK 面向在线销售的指导要求经营者提供商品、服务或数字内容的描述、总价或计算方式、合同期限及滚动合同结束条件等信息。\n\n这提醒独立开发者：不要只写按钮上的月费。用户需要知道买到什么、多久一次、怎样结束。\n\nAI 服务还要说明更特殊的边界：结果是否保证准确？专业领域有什么限制？未成功生成时怎么处理次数或费用？这些规则如果影响购买决定，应该在购买前就能找到，而不是出问题后才拿 Terms 解释。\n\n维护一张“商业事实表”：运营主体、产品、价格、计费方式、交付时点、自动续费、取消、退款、数据删除、客服邮箱、主要第三方。Privacy、Terms、Refund、Pricing 和代码都从这组事实核对。\n\n条款最重要的品质不是长，而是和你真的怎么做生意一致。",{"id":431,"slug":432,"title":433,"summary":434,"category":390,"series":391,"created_at":12,"updated_at":12,"view_count":13,"author":435,"sources":436,"content":442},"academy-operations-erasure","account-deletion-is-not-delete-user-row","删除账号不是删一行 users：数据、订单和备份怎么办","账号、内容、日志、支付、发票、客服和备份往往分散在不同系统。删除功能要先建立数据地图，并区分可以立即擦除的个人数据与有合法保留理由的记录。",{"username":15},[437,440],{"label":438,"url":439},"ICO：Right to erasure","https:\u002F\u002Fico.org.uk\u002Ffor-organisations\u002Fuk-gdpr-guidance-and-resources\u002Findividual-rights\u002Findividual-rights\u002Fright-to-erasure\u002F",{"label":441,"url":396},"ICO：How to write a privacy notice","产品里加一个“Delete account”按钮很简单，真正执行删除通常不简单。\n\n一个用户可能同时存在于认证 Provider、profiles 表、项目表、对象存储、邮件列表、分析系统、客服工单和支付记录里。只删除 users 主表，既可能留下大量孤儿个人数据，也可能把订单外键弄坏。\n\n## 先区分账号身份和业务记录\n\n认证账户负责登录，用户创建的内容属于业务数据，付款和退款又属于财务事实。三类数据生命周期未必相同。\n\n例如用户要求删除个人资料和公开内容时，某些支付或税务记录可能仍需要因为法律、会计或争议处理理由保留。具体保留义务取决于地区和业务，不能用一条通用规则处理。\n\nICO 对英国数据保护的说明也明确指出，删除权并不是绝对权利；在某些法律义务、法律请求等情况下可能存在例外。\n\n## 数据地图决定删除范围\n\n实现按钮前，把与 user_id、email、phone、provider subject 相关的存储全部找出来。\n\n每一项标记：立即删除、匿名化、按保留期继续保存、需要第三方同步删除、进入备份淘汰周期。\n\n如果用户上传了文件，还要检查对象存储；如果内容发给过第三方 AI 或邮件服务，确认供应商侧可执行什么删除动作，而不是只清自己的数据库。\n\n## 备份是最容易忘记的一层\n\nICO 的 erasure 指导专门讨论了 backup。有效删除请求可能需要覆盖备份环境，但技术上未必能立刻从每个不可变备份里抽出单个用户删除。\n\n一种常见处理是让数据在备份保留周期后被覆盖，并确保这段时间处于 beyond use 状态，不再被正常业务使用。实际做法仍应结合你的备份机制和适用规则。\n\n关键是隐私说明不要承诺“点击后所有副本瞬间消失”，如果系统根本做不到。\n\n## 删除任务需要可恢复\n\n跨多个 Provider 删除很容易半成功。数据库删了，邮件服务 API 超时；对象存储成功，认证 Provider 失败。若按钮请求本身承担全部工作，用户看到一个 500，却不知道已经删到哪里。\n\n更稳的设计是创建持久化 deletion job，记录每个阶段状态，失败可重试；在任务完成后再关闭登录能力或按设计冻结账户，避免删除过程中继续产生新数据。\n\n## 匿名化有时比硬删除更适合历史记录\n\n例如订单必须保留，但没必要一直关联用户昵称和头像，可以移除非必要个人字段，保留订单编号、金额、时间等必要事实。\n\n匿名化必须是真的无法再合理识别个人，而不是把 email 换成 hash 就宣称完全匿名。\n\n如果你无法回答“一个用户的数据到底在哪里”，说明隐私政策、备份和供应商管理也很可能不清楚。账号删除不是一条 SQL，而是一套数据生命周期。",{"id":444,"slug":445,"title":446,"summary":447,"category":390,"series":391,"created_at":12,"updated_at":12,"view_count":13,"author":448,"sources":449,"content":455},"academy-operations-subscription","subscription-is-a-state-machine-not-a-boolean","订阅不是一个 isPro：续费失败、取消和恢复都会让状态变复杂","订阅系统如果只存“是否会员”，很快会遇到现实：用户已取消但本周期仍有效、扣款失败进入宽限期、恢复订阅、退款和 Provider 回调重复。",{"username":15},[450,453],{"label":451,"url":452},"Stripe：Subscriptions overview","https:\u002F\u002Fdocs.stripe.com\u002Fbilling\u002Fsubscriptions\u002Foverview",{"label":454,"url":323},"Stripe：Webhooks","第一次做订阅，数据库里很容易出现一个字段：is_pro。\n\n付款成功就设成 true，用户取消就改成 false。这个模型在 Demo 里够用，接到真实账单以后很快会崩。\n\n因为“取消”本身就有至少两种含义：立即终止，或本周期结束后不再续费。第二种情况下，用户已经点了取消，但权益还应该继续到 paid-through date。\n\n## 订阅至少同时存在几个事实\n\nProvider 有自己的 subscription id 和状态；本地有当前套餐；有当前计费周期开始和结束；有是否计划在周期末取消；还有实际权益什么时候失效。\n\n这些事实相关，但不是同一个字段。\n\nStripe 的订阅文档本身就有 trialing、active、past_due、canceled 等生命周期状态。支付失败以后还可能根据重试和业务策略继续一段时间，而不是瞬间踢出产品。\n\n## Webhook 才能补齐异步变化\n\n用户可能不在你的网站里取消，而是在支付 Provider 的客户门户操作；续费失败发生在凌晨；银行几小时后更新支付结果。\n\n这些都不会经过你的“取消按钮”。本地状态必须能够根据签名 webhook 或服务端同步更新。\n\n同一个 webhook 还可能被重试，因此订阅状态更新也需要幂等，不能每收到一次 invoice.paid 就重复发一份月度权益。\n\n## 取消和恢复要定义清楚\n\n如果用户选择“周期末取消”，本地可以记录 cancel_at_period_end，但当前权益仍然 active。用户第二天后悔，又点恢复，则需要撤销未来取消计划，而不是新建第二个订阅。\n\n如果用户已经进入真正 canceled 的终态，再回来购买，才可能是新订阅。\n\n这就是为什么一个 isPro 无法表达生命周期。\n\n## 续费失败需要业务策略\n\n支付失败以后立刻停服务最简单，但不一定合理；给三天或七天宽限又会增加状态复杂度。\n\n无论选哪种，都要把规则写死：宽限从哪个时间开始，重复失败会不会不断延长，成功补款以后怎样恢复，最终什么时候关闭权益。\n\n这些规则应该由本地持久化，而不是临时根据“当前时间 - webhook 时间”猜。\n\n## 退款也不是简单反转\n\n一个用户已经使用了半个月、消费了附带积分，再发生部分退款，权益如何变化需要产品政策。Provider 只知道退多少钱，不知道你的功能应该撤掉多少。\n\n不要让财务事件直接修改一个布尔值，要经过业务规则层。\n\n订阅上线前至少画出：创建、试用、激活、续费成功、续费失败、宽限、周期末取消、恢复、立即取消、退款、终止。再给每条箭头写触发来源：用户操作、后台操作、Provider webhook、定时任务。\n\n订阅的难点从来不是“每月扣一次钱”，而是用户和支付系统都可能在任何一天改变下一步。",{"total":457,"page":458,"pageSize":459},30,1,100]