source_parser-能读正文吗我试了成了

最近在折腾一个新流程，核心就一件事：source_parser 能不能读到正文块。这事儿听起来小，但它是内容自动化的第一道门槛。读不到正文，后面所有的处理都是空转。说实话，我之前在这上面栽过跟头，parser 把元数据当正文输出，结果下游处理全乱了。所以这次我格外谨慎。

为什么测这个

做内容自动化的时候，source_parser 是第一个要过的关。它负责从源文件里把正文提取出来，交给下游处理。如果它 reads 不对，整个链条就断了。我之前遇到过 parser 把标题当正文的情况，头疼得很。所以这次新建源文之后，我决定先本地跑一轮 generate，看看结果。不为别的，就为求个心安。

之前踩过的坑

说起来都是泪。去年有个项目，我嫌本地测试麻烦，直接推到 staging 环境跑。结果 source_parser 把 YAML 里的 description 字段当正文输出了，用户看到的全是元数据，真正的正文没发出去。那次损失了不少流量，虽然最后回滚了，但教训深刻。所以这次我老老实实先本地跑，一行命令的事，何苦呢。

怎么测的

场景很简单：我在项目的 test 目录下新建了一个 test.md 文件。内容不用多，就一行：“今天天气不错，适合测试。” 关键是模拟真实场景，所以我在文件头加了简单的 YAML frontmatter，标题、日期都填了。然后我在终端里 cd 到项目根目录，跑 hugo generate 命令。过程不复杂，就是等它跑完。大概两三秒吧，终端输出了一堆处理信息，我没细看，直接去看结果了。

结果怎么样

跑完之后，我去 .state/artifacts 目录看结果。一进去就看到了 xhs 的 json 文件。文件名挺直白，就是基于源文件名生成的，叫 test_xhs.json 之类的。我打开一看，里面是个简单的 JSON 对象，有一个 content 字段，装的就是我放进去的那行正文，一字不差。另外还有 metadata 字段，存的是标题、日期这些元数据，和正文是分开的。心里一沉，成了。这说明 source_parser 确实读到了正文块，没有跑偏，也没有把元数据混进来。

跑通就是成功。但这只是第一步，后面还有解析、清洗、分发一堆环节。每一步都都得测，不能因为这一步通了就放松。讲真，自动化流程最怕的就是某个环节静默失败，表面看没事，实际数据已经歪了。我打算下一步测 parser 对多段落、markdown 格式的兼容性，据说容易出问题。

你呢？你最近在测什么流程？有没有遇到 parser 不读正文的坑？或者有什么自动化工具推荐？

📌 发布建议

发布前确认 frontmatter 里 draft 为 false，避免文章被当作草稿。可以在文章开头加一句简短摘要，提升 SEO。

[去AI味儿残留提示] 最后（人工终审）

🎯 标题候选

• source_parser 能读正文吗？我试了，成了
• 一次 source_parser 测试：跑通就是成功
• 测试新流程，.state/artifacts 里出现了 xhs 的 json