一篇文章，交代到五件事

标题就是主张，或主张里那组对立。观点句可以当标题。判断在正文开头几段内出现：现场卡住之后，不要第一句复读标题。

好：技术会换，私有评测集不会换、Mac mini 是企业内部最快的数字员工载体、把写博客做成一个 skill。不好：聊聊 Astro（太空）、构建期做完：Astro 内容集合、自托管字体与 OG（像 commit）、先带着 Agent 干完一次（待办命令）。

正文小标题用这篇自己的话起，比如「为什么沙箱不是工位」，比统一的「观点」「实操」更好扫。短文可以一个小标题都没有。

这篇到底在主张什么。开头几段内说出来。先写卡住的现场，再亮判断。不要从背景、定义或「随着……」写起，也不要把判断整句贴成第一句。

读完开头几段，别人要能用一句话转述你的主张。转述不出来，就是还没想清楚。

最好有一件已经发生过的事：谁、在哪、做了什么、结果怎样。用你自己的仓库、上线、翻车或一次真实选择。

没有真事，就在开头承认还没有现场。不要编「某公司曾经」。数字和原话必须找得到出处。

观点文写你为什么这么看；方法文写别人可以怎么复用。取舍表、删除项、可复用的规则都放在这里。

这篇真正在争的那个词，要给定义、对照近义词。

读者合上文章能做点什么。轻重看类型：实操文这是主体，编号步骤、每步看得见结果；观点文一两段就够，写这个判断下次怎么用；调研文写下次遇到同类问题先查什么。

「大家可以思考一下」不算。

写清这个判断在什么情况下不成立，或者最常见的误读是什么。放在结尾最自然，放在论证中间也可以。

文末不必再堆一份「延伸阅读」，页面底下已经有相关文章。

产品能力、价格、政策、别人的原话，要能点回出处。本仓库里做过的取舍，例子本身就是证据，不必硬凑文献。

每条参考写清：标题、链接、查阅日期、支撑了哪一句。正文没点名的，不要出现在这个列表里。这是唯一固定的结构：有参考时，它必须是全文最后一个小标题。

先在 GitHub Issue 里定选题：判断、论证图、找来的素材（支持的、修正的、反对的都要有）。人在评论里改选题，Agent 改 Issue。这里不写正文。

选题先过一轮 eval，只看主张站不站得住：判断说得清、能被反驳、回应了最强的反方、比旧文有新东西。过了、人确认了，才开 PR 写正文。

正文在 PR 里写和改：人逐句评论，Agent 在分支上改。文章再过一轮完整的 eval：按内容类型（概念、实操、调研）逐条检查，核出处、查有没有编造的数字。正文每改一次都要重评，过了才能合并上线。Agent 不准直接推线上。

同一个 PR 要把文章收进 wiki：一篇来源摘要，加上它碰到的概念。