个人博客建站，需求清单应该写到什么程度
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /5b8dbf34f67c.html
📄
个人博客建站，需求清单应该写到什么程度
需求清单写到“能据此判断做没做完、能不能验收”的程度就够了。对已有页面的个人博客来说，不必写成产品需求文档，但每条需求至少要包含三样东西：要改哪个页面或模块、改完后的可见结果、以及你用什么标准判断它合格。如果一条需求只能靠“感觉更好看”“再优化一下”来验收，说明它还没写到位。
准备阶段：先把需求分成四类
在原有博客上改进时，最容易把需求写成一大段愿望。建议先分成四类，每类写到不同颗粒度：
- 结构类：导航、栏目、文章页与列表页的关系。写到“哪个链接指向哪里、点击后看到什么”即可。
- 内容类：文章排版、标题层级、代码块、图片说明。写到“正文里出现哪些元素、各自怎么显示”。
- 性能类：首屏加载、图片体积、脚本数量。写到“改哪个文件或哪类资源、目标是什么量级”。
- 维护类：备份、更新、失效链接检查。写到“多久做一次、做完记录在哪里”。
判断颗粒度是否合适，可以用一个简单测试：把这条需求交给一个不熟悉你博客的人，他能否在不追问的情况下知道要动哪里、改成什么样。如果必须追问，就继续补细节；如果已经细到指定每一行代码的颜色值，对个人博客来说通常就过度了。
实施阶段：最关键的一步是给每条需求加验收条件
这是整份清单里最值得花时间的地方。需求本身描述“做什么”，验收条件描述“怎么算完成”。没有验收条件，改进就会变成反复返工。
一个可执行的写法是“动作 + 对象 + 可观察结果”。例如，假设你发现文章页在手机上代码块会横向溢出，可以这样写：
需求：文章页代码块在宽度小于 480px 时不出横向滚动条。验收：用浏览器开发者工具把视口调到 375px，代码块内容自动换行或内部滚动，页面整体不出现横向滚动。
这里要区分“可能原因”和“已经定位的原因”。上面这条只描述现象和目标，不预设一定是 CSS 的 overflow 写错，也可能是代码块容器宽度被固定值撑开。先写清验收标准，再去定位原因，顺序反了就容易改错地方。
验收条件要尽量可复现：写明在哪个页面、什么设备宽度或浏览器、看到什么算通过。避免写“加载更快”“看起来更舒服”这类无法判断的表述。如果确实想改视觉，就把它拆成可判断的点，比如“标题与正文间距在桌面端不小于 16px”。
验证阶段：用清单逐条对照，而不是凭印象
改完之后，拿原始需求清单逐条打勾。建议按下面的检查项走一遍：
- 每条需求是否都有对应的验收条件，且条件里包含具体的页面和判断方式。
- 改动是否只影响了目标页面，其他页面的导航、样式有没有被连带改坏。
- 在桌面端和手机宽度下各看一次，重点看图片、代码块、表格是否溢出。
- 随机点开三到五篇文章，确认标题层级、段落间距、链接颜色一致。
- 如果改了链接结构，检查旧链接是否还能打开，或者是否做了跳转。
验证时不要只盯着改过的地方。个人博客页面少，连带影响反而容易发现。如果某条需求验收不通过，先记录现象，再决定是继续改还是把这条降级为“暂不处理”，不要在现场临时扩大范围。
维护阶段：清单要能复用，而不是用完就扔
需求清单的价值不止于这一次改进。把已经验收通过的条目整理成一份固定检查表，下次改版时直接复用，可以省掉重新想标准的时间。维护类需求尤其适合这样处理，比如每月检查一次失效链接、每次发文后确认图片是否压缩、每次改主题前先备份。
对于历史遗留的入口或旧功能，不要凭记忆判断它现在还能不能用。可以这样核查：在博客里实际点开那个入口，看它指向的页面是否存在、是否返回正常内容；如果依赖某个外部服务，去该服务的官方说明页确认当前状态。没有核实之前，清单里只写“待确认”，不要写成“已经可用”。
下一步，挑出你当前最想改的一个页面，按“动作 + 对象 + 可观察结果”写三条需求，每条都补上验收条件，然后只改这三条。做完一轮，你就知道自己的清单颗粒度该停在什么程度了。
