Posts
文章索引
做独立产品时，我会先砍掉模糊，而不是先补完整
很多独立项目不是死在能力不够，而是死在边界越来越糊。比起赶紧补全，先砍掉模糊通常更能保住主线。
现在我的一周，更多花在取舍而不是写代码上
独立开发做到一定阶段后，最消耗精力的往往不再是实现，而是不断决定什么值得推进、什么应该先停。
一个人做发布时，我先给自己补边界，而不是补胆量
独立开发最危险的不是没人催你发，而是你很容易在熟悉系统之后，高估自己对风险的掌控感。
AI 时代，有三类能力我不会外包
我愿意把越来越多执行动作交给 AI，但有三类能力一旦外包，整条产品主线就会慢慢变得不像自己。
好的个人博客，不该像一张过度修饰的简历
博客的可信度，来自持续表达和取舍，而不是把经历包装成一份没有摩擦的展板。
我现在最稳定的一套 AI 写作工作流：选题、成稿、分发三段式
真正稳定的 AI 写作，不靠一次性爆发，而靠把判断、起草和分发拆成不同责任。
用 AI 把文章生产线拆成五个可复用节点
把写作当成一整个请求交给 AI，通常只会得到一篇普通文章；拆成节点，才会得到可复用系统。
一个独立开发者可长期使用的内容自动化架构
内容自动化最怕的不是不够智能，而是维护成本比写作本身还高。
写产品文章时，我更在意句子能不能形成判断
产品文章最怕把信息写全，却没有立场。没有判断的句子，很难真正帮助读者理解产品。
录制工具真正变成工作台，是从它能接住中断开始
我没有继续堆录制按钮，而是先让白板、预览、登录和返回路径留在同一张桌面上。
做教程内容时，AI 最该承担的是结构，不是观点
教程最怕的不是不完整，而是作者把自己的判断也外包给模型。
发布真正卡住时，我才发现绿灯不等于可发布
这次 Cloudflare 发布阻塞不是单点故障，而是提醒我：本地链路全绿，不代表目标平台已经接受。
我如何让 AI 帮我维护一套可搜索的项目知识库
知识库最难的部分不是搜索，而是持续更新；AI 能帮忙，但前提是结构先清楚。
从博客到产品目录：一次站点信息架构重建
当内容和产品都在增长时，博客式归档已经不足以承担整个站点的入口职责。
为什么我现在更愿意用轻量 MDX，而不是先上重型内容栈
内容系统最容易犯的错，是在内容还没跑起来之前，先把基础设施做得过于完整。
公开周报要留下信号，而不是倒出后台噪音
对外周报不是内部日志的轻量版；它应该替读者筛掉噪音，只留下能解释产品变化的信号。
Cloudflare 发布没卡在代码，而是卡在我误判了运行时边界
本地 build 过不代表 Cloudflare 过；真正的发布门槛，是把目标运行时的失败提前拉进 release gate。
导航分类不是自我表达，而是用户决策地图
用户点导航不是来理解你的世界观，而是想更快做出下一步选择。
内容系统别先选工具，先看站点处在哪个阶段
Notion、MDX、CMS 不是信仰选择；真正的问题是当前站点卡在验证、沉淀还是协作规模。
为什么独立产品的首页更该卖判断，不只是卖功能
独立产品的首页如果只堆功能，很难建立信任；真正能拉开差距的是判断。
把一个过重的客户端页面拆成三层之后，项目终于能测了
页面难测，通常不是测试写得不够，而是页面本身已经把太多责任揉在一起。
产品线发糊时，先砍掉抢身份的入口
小产品最危险的不是少一个入口，而是每个入口都想证明自己是主线，最后谁都说不清产品到底是什么。
为发布流程补门禁时，我先锁的是失败类型
发布门禁的价值，不在于让流程更严格，而在于优先挡住那些最昂贵、最常见的失败。
把内容当产品做时，最先要定义的是转化动作
内容增长之前先定义转化动作，能避免写作变成只增长页面数量的自我安慰。
为什么小产品也需要架构总览文档
小产品不写架构总览，短期看像节省时间，长期看通常是在给未来的自己制造盲区。
工具订阅值不值，要看它卡在哪段高频链路
我不再按工具名气决定订阅，而是看它能不能稳定减少录制、剪辑、发布里的高频返工。
用户要新功能时，我先问他想省掉哪段等待
很多需求不是在要更强的系统，而是在提醒你：现有路径让人太慢到达结果。
录制视频模块现在应该被当成产品，而不是默认首页
这次调整不是削弱产品，而是给它一个更正确的位置。