造物栈如何用状态检查，让 AI 项目不再越做越乱

---

项目不是突然变乱的。

一开始只有最小站点、几篇规划文档和一个 README，每一步都很清楚。但几轮 AI 协作后，正式文章、草稿和备份逐渐混在一起。每次修改看起来都不大，累积起来却让项目边界越来越模糊。哪些文件正在使用、哪些只是上一轮留下的，下一步该做什么，都要翻目录才能回答。

这不是代码的问题，是状态的问题。

---

真正的问题是状态不清楚

代码能运行，不等于项目状态清楚。这是我用 AI 推进项目时反复验证的经验。

过去做两个长期项目时，我养成了一个习惯：每天先看状态检查，再决定下一步。否则很快就不知道项目走到哪了。

文件、任务和验收结果散落后，下一轮 AI 看到的项目可能和你理解的不同：它以为某篇是正式内容，实际只是草稿。新的修改如果建立在错误前提上，后面每一步都要付出额外核对成本。

这种错位不会立刻让项目崩溃，却会让每次决策都建立在”大概对吧”的前提上。

一个脚本的迭代史

开始造物栈之后，我把这个习惯带了过来。

从 Astro 最小站点开始，状态检查脚本就跟着项目一起增长，已经从 v0.1 多次迭代到 v0.7.0。

一开始它只检查基本文件。后来有了两篇正式文章、/posts/、标签系统和 sitemap 自动化，对应检查项才逐步加入。项目每往前一步，脚本就多确认一件事。检查项不是预先设想出来的，而是从真实任务和已经出现的边界问题中长出来的。

它不是启动时写完就搁置的文档，而是随项目更新的清单。

例如，脚本会检查 posts 目录里的 Markdown 文件数量，当前必须是 2。多一个可能是备份误入，少一个可能是文件缺失。重点不是永远把数字固定为 2，而是让数字与当前阶段保持一致。脚本不知道具体问题，却能先指出状态不对，让人及时判断原因。

目前脚本已经覆盖根目录、核心文件、页面、内容目录和稳定备份等接近百项检查，结果只有 OK、MISSING 和具体数量，不需要人工逐个翻目录。

一次备份污染风险带来的提醒

posts 目录曾出现备份文件混入的风险。

网站仍能渲染，不代表这件事无关紧要。状态检查关注的不只是”能不能跑”，还有”边界是否干净”。

正式内容目录只该放正式内容，草稿和备份各有位置。边界一旦模糊，今天看似无害的多余文件，几个月后就可能让人分不清哪个版本才正确，也可能被后续自动流程当成正式内容。

检查把风险直接暴露出来。人不必每天盯着目录，只需在任务完成后运行一次。

人与 AI 的新分工

状态检查也让人与 AI 的分工更清楚。

文件在哪里、数量对不对、目录有没有被破坏，这些事实适合交给机器重复核对。

脚本输出机器可核对的事实，人判断内容质量、方向和是否进入下一阶段。用户不再把时间花在逐个翻文件上，而是集中处理脚本无法替代的决策。

把重复确认交给脚本，把经验判断留给人，这是一种很朴素的协作方式。

它只是仪表盘，不是自动驾驶

它也有明确边界。

状态检查不能替代构建、浏览器验收、人工内容判断和阶段性备份。这些步骤解决的是不同问题，不能因为检查结果全是 OK 就省略。

它只是仪表盘，能显示状态，但不会替你驾驶或修复问题。

它不能防止所有错误，只能持续暴露项目状态。知道边界，才不会对它有不切实际的期待。

把状态清楚变成长期习惯

状态检查最重要的作用，是让”状态清楚”成为一种可以持续的习惯。

项目不一定需要复杂的管理系统，但需要稳定、可重复的核对机制。关键不在脚本有多高级，而在每次任务结束后都能用同一套标准看清项目。

对普通人来说，脚本跑完就能知道当前有什么、缺什么、下一步做什么。剩下的精力，留给真正需要人的判断，也更容易复盘。