标准工作流：探索、计划、实现、验证、复盘

案例目标

案例选择“给本站新增一篇随笔”，因为它够小，但不是假练习。它会碰到内容文件、frontmatter、标签、文章列表、RSS、sitemap、构建检查和发布入口，刚好覆盖一次站点改动的完整链路。

任务范围要提前锁住：只新增文章和必要的发布入口验证，不允许顺手改 UI、路由结构、依赖或文章读取逻辑。

• 产物：新增 `src/content/writing/*.mdx` 文章。
• 可见性：文章详情页能打开，文章列表和标签页能看到。
• 发布面：RSS 和 sitemap 不因 frontmatter 或 slug 出错。
• 验证：至少运行 `npm run lint`；涉及路由、MDX 或元数据时运行 `npm run build`。
• 汇报：最后说清改了什么、检查结果、页面验证和剩余风险。

第一步：探索，不改文件

常见错误是第一句就写“帮我写一篇文章”。这会让它直接生成内容，忽略项目约束。更好的开始是让它先读项目规则和内容结构。

请先阅读当前项目中与文章发布相关的规则和代码，不要改文件。

重点看：
1. 项目规则文件（AGENTS.md 或 CLAUDE.md）里关于内容和验证的要求。
2. src/content/writing/ 下已有文章和 _template.mdx。
3. src/lib/writing.ts 如何读取文章。
4. writing、tags、feed.xml、sitemap 这些入口如何依赖文章数据。

读完后说明：新增一篇文章需要满足哪些字段、会影响哪些页面、完成后应该跑哪些检查。

第二步：计划，你批准后再执行

计划阶段要看它是否读到了关键约束：文件路径、frontmatter、发布入口、验证命令。如果计划里出现“重做文章系统”“添加数据库”“改首页布局”，说明它已经跑偏，这时纠正成本最低。

写一篇 AI 文章放到站点里。

先给方案，不要直接写文件：新增一篇随笔，slug 用 start-with-ai-agents，主题是“AI 很重要，但不要只当聊天框，多用 agent 先做一件小事”。计划里要包含：准备新增哪个文件、frontmatter 写哪些字段、正文大纲、会影响哪些页面或生成入口、准备跑哪些验证。只新增文章文件，不改样式和读取逻辑。计划我确认后再执行。

第三步：执行时控制范围

• 看到新增文件后先扫 frontmatter：title、date、description、category、tags 是否完整。
• 正文要有具体建议和可执行小步骤，不要写成抽象宣言。
• 如果它想改共享逻辑，要求说明 bug 证据和影响范围。
• 改动范围之外的文件被动到时，先拒绝再问原因。

首页露出不是本次任务范围。请停止修改首页，只完成文章发布本身。如果你认为首页必须改，请说明不改会造成什么实际 bug，以及最小替代方案。

第四步：验证不是一句“已完成”

内容任务也要验证。新增文章看似只是写文件，但会影响文章列表、标签页、RSS 和 sitemap。最终汇报必须能让你判断站点能不能构建、页面能不能访问、发布入口有没有漏。

请按下面顺序验证这次文章发布：
1. 运行 npm run lint。
2. 如果涉及 MDX、路由、metadata、RSS 或 sitemap，运行 npm run build。
3. 如果本地服务可用，用浏览器检查 /writing、文章详情页、相关 tag 页。
4. 检查 sitemap 是否包含文章路径，RSS 是否能生成。
5. 最后 review diff，确认没有无关改动。

汇报时按“命令结果 / 页面检查 / diff 风险 / 未验证项”四段说明。

第五步：复盘并沉淀

完整流程最重要的收尾不是提交代码，而是复盘：哪些要求以后每次都要重复，哪些检查已经固定，哪些步骤只是本次任务需要。这样一次成功才会变成可复用工作流。

• 留在当前 prompt：本篇文章的主题、语气、长度和具体观点。
• 写进规则文件：frontmatter、slug、分类、发布验证命令。
• 做成命令或 Skill：新增 MDX 后检查列表、标签、RSS、sitemap。
• 放到 PR checklist：命令结果、页面检查、diff 风险、未验证项。
• 不要沉淀：一次性的标题偏好、临时素材、还没验证过的猜测。