# 我会如何给一个个人网站安排3个月开发计划？ URL: https://caijiao.org/posts/144 Source: docs/posts/144.md Description: 第一个月只做骨架和 3 到 5 个完整页面，第二个月把页面密度堆到 50 个左右——10015.io 就是到 50 个工具才开始写文章发社媒，到 64 个才上 Product Hunt。 我给个人项目的排期通常是这样三块： ``` 第 1-4 周 骨架 + 3~5 个完整页面 第 5-8 周 把页面堆到 50 个 第 9-12 周 开渠道，按数据修 ``` 三个月是我给自己定的上限。再长，项目会从"我想做这个"变成"我已经投入太多了"，判断力开始被沉没成本牵着走。 ## 第一个月：把"能部署"做扎实，页面只做五个 这个月不产出任何用户能看见的价值，但没有它，后面每件事都会变慢。 具体清单：域名和 DNS、证书自动续期、一条能一键部署的 CI、真正返回 404 的 404 页、robots.txt、sitemap.xml、一个健康检查端点、错误上报。 页面只做三到五个，但每个都要完整：有独立 URL、能单独兑现自己的标题、有对应的结构化数据、有真实的用法说明。宁可五个都是完整的，也不要十五个半成品。 这个月明确不做的三件事：用户系统、数据库、管理后台。它们在第一个月的收益是零，成本是永久的。 部署形态也要在这个月定死——纯静态还是容器。用 [Docker](/docker/) 的 compose 把服务、挂载卷、健康检查写清楚，后面两个月就不用再碰部署这件事。 ## 第二个月：唯一目标是页面密度 为什么是 50？10015.io 的路线图给了一个很实在的参照：50 个工具之前只做工具，到 50 个才开始写文章发社媒，到 64 个才上 Product Hunt。 ![10015.io 官网首页截图](/images/2026-09/10015.io.png) *10015.io 首页的标语是 All Online Tools in One Box，副文案里写明做站初衷：治书签栏的乱。* 50 这个数字的意义不是"看起来多"，是阈值效应——用户因为某个具体动作搜进来之后，发现这里还有几十个能用的东西，他才会记住这个域名。只有三五个页面时，他看完就走，你把他带来的这一次访问留不下任何东西。 规则只有一条：一个页面对应一个具体动作词，URL 独立，标题里写的是用户要做的那件事，不是类别名。页面之间的区别要落在内容上——不同的输入、不同的输出格式、不同的边界说明——而不是只在标题里换一个名词，正文照抄。 这个月的产出应该能被量化：每天至少完成一个页面，四周下来是二十几个，加上第一个月的五个，接近 30 个。离 50 的阈值还差一截，剩下的可以在第三个月补齐，那时你已经知道自己写得快不快、该不该调整目标。 这个月不要重构。新增页面时如果发现模板不顺手，把问题记下来，第三个月再统一改——中途改模板会让已经上线的页面一起抖动。 ## 第三个月：开渠道，然后按数据修 先把 [Search Console](/google-search-central/02-search-console-setup) 的数据跑起来，看前一个月的基线：多少页面已收录、哪些词有展示、点击率是多少。 按数据分流：完全没展示的页面，多半是词没人搜或者页面内容太薄，补内容或换词；有展示没点击的，改标题和描述，这比重写页面便宜得多；有点击但很快离开的，才是页面本身没兑现标题。 外部渠道也在这个月开。10015.io 在 64 个工具时才去 Product Hunt，不是因为懒——Product Hunt 每天约 668 次发布，被 feature 的比例约 2.8%，一次没上榜是常态。把它当成一次收集反馈的机会，而不是一个月唯一的指望。 这个月可以重构：第二个月积累的重复代码现在看得最清楚，改起来也有具体依据。 ## 时间不够时，砍第二个月，不砍第一个月 如果只有两个月，我的选择是把第二个月的页面目标砍到 25 个，而不是压缩第一个月的骨架。 理由很直接：骨架没做扎实的话，后面每加一个页面都要多花时间——部署要手动、404 要补、结构化数据要重填。这些成本是按页面数线性叠加的，砍掉骨架省下的两周，会在后面翻倍还回来。 反过来说，页面数量少一点只是让渠道晚开一阵，不会让每个页面的成本变高。 如果只有一个月，那就只做骨架加五个页面，然后停在那里看数据。一个月能验证的东西有限，但"有没有人从搜索进来"这件事，五个页面也能看出来。 ## 每月一个版本，最后三天不开发 Cakedesk 2025 年发了 12 个版本，平均每月一次。这个节奏的好处是每次发版都是一个完整的、可回滚的状态，而不是一堆半途改动的堆积。 我会在每个月最后三天停掉新功能，只做三件事：修 bug、补文档、把部署跑一遍。这三天看起来效率低，但它保证了下个月开始时你面对的是一个干净的项目，而不是一个带着五个已知问题的项目。 ## AI 在这三个月里该站在哪 JetBrains 的调研里有个数字：90% 的专业开发者每周至少用一次 AI 编码 agent。它已经是默认工具了，问题只是用在哪个环节。 它能压低的是写样板代码、写页面模板、写测试、写配置文件这些有明确模式的活——正好是第二个月批量生成页面时最耗时的部分。 它替代不了的是：决定做哪 50 个页面、判断哪个词值得覆盖、看完数据之后决定改什么。这三件事错了，AI 生成得再快也只是加速跑错方向。 三个月结束时的验收标准我只看两条：有没有 50 个页面进了索引，有没有至少 10 个陌生人第二次来。两条都没有，问题通常不在执行，在选题——这时候换一个方向，比在原来的方向上继续加功能划算得多。 --- *10015.io 路线图来自其官网 Roadmap 页面；Product Hunt 发布量与 feature 率为公开统计估算。*