大多数知识工具最后都干成了一件事：把你不知道的东西，编成看起来知道的样子。
这句话是我做这个东西的理由。
笔记软件、知识库、第二大脑------它们大多有一个共同的默认行为：你留一个空，它想帮你填上。 智能补全、AI 摘要、自动标签、推荐关联，每一个都在把空格填满。
填满之后，那份文档看起来更完整了。但你已经不知道哪些是你真的知道的，哪些是它替你编的。
所以我给自己定了一条规矩，而且它是这个项目的立项根基，不是一条功能取舍：
不知道就留空。不代填。
先说清楚它是给谁的
这套框架面向的是开发者，不是最终用户。
它是一份结构规格加一个校验器。要用它的人得愿意碰 YAML、会用 git diff、看得懂"R7 报 ERROR"是什么意思。基于它做出来的产品才是给普通人的 ------普通人不需要知道有六层，也不该看见 filled_by 这种字段。
换句话说：这个仓库解决的是"怎么把知识结构做对"，不是"怎么让普通人记笔记"。 后者是产品的事，得有人基于这套结构去做。而要把那个产品做好，绕不开先把结构定死------这个结构目前还没有一个公开、可讨论的版本。
所以下面这些东西，是写给准备动手做的人看的。如果你只是想找个记笔记的工具，这个仓库现在帮不上你。
留空这件事，光靠自觉守不住
问题来了：我说"不代填"，凭什么保证？我自己也做不到靠自觉。
所以我把这条规矩做成了机器能查的规则，而且是双重拦截：
| 拦截点 | 手段 |
|---|---|
| 校验器 | 规则 R7：filled_by 写了"模型"的文件里，如果出现 evidence_status: 已验证，直接报 ERROR，文案点明「疑似模型代填」 |
| 文档 | 任何填充器------人、模型、脚本------都必须如实写 filled_by。模型填的写 模型(vX) |
反过来还有一条 R8：如果某个节点声明自己 未填充，那它里面不能有任何内容。
没有 R8 的话，未填充 就变成了"填了但不署名"的合法通道，上面那句"填了就得留痕"也就只剩一句自觉。
这个仓库里所有示例的 filled_by 都是 模型(示例数据)，evidence_status 一律是 未验证。 包括我自己的演示数据。因为那确实是我（用模型）编的。
它具体长什么样
一个节点 = 一个 .md 文件：YAML front matter + 可选正文。可 git diff、可用任何文本编辑器打开、可手工改。
节点挂在两个索引上，这是我做的一个取舍：
title是概念索引 ------ 回答"这东西叫什么"
cues是情境索引 ------ 回答"我现在处在哪种处境"
我认为情境索引才是真正的入口。 因为需要知识的人，通常不知道那个概念叫什么；他只知道自己的症状。专家靠"认局"触发知识，不靠概念树。
所以这个工具问的不是"你要查什么概念"，而是"你现在处在什么处境"。
配套是一个只读校验器 ：只报告，不写文件、不修复、不排序。它只回答"结构自不自洽"，不回答"这条知识对不对" 。
零运行时依赖：Python 3.9+ 和 PyYAML。没有数据库、没有图库、没有 RDF、没有常驻进程。
如果你看到这里觉得"这就是一堆 YAML 加一个校验脚本"------基本是对的。 代码层面它确实很薄（validator/validate.py 27,907 字节）。我认为值得看的是那四条规矩，以及它们怎么被做成会报错的检查，而不只是文档里的一句话。
可以现在就验，数字都是真的
我不想说"它很好用"------那是没法验的话。我说能验的：
bash
git clone https://github.com/aic-123/Scaffold.git
cd Scaffold
pip install -r requirements.txt
python validator/validate.py --self-test # 校验器自检，退出码 0
python validator/validate.py ./samples # 23 节点，ERROR 0 / WARN 3，退出码 0
python validator/validate.py ./samples-broken # 10 节点，ERROR 8 / WARN 1，退出码 1
python validator/validate.py ./samples --todo # 待填清单，23 节点里 21 个有待填项，退出码 0那 3 个 WARN 不是坏数据------它们是 3 个 cues: [] 的节点 ，也就是三个没有情境索引的节点。那正是这个工具要展示的东西本身：缺口被摆出来了，而不是被填上了。
samples/ 是形状示范 （结构完整，干净通过，退出码 0）；samples-broken/ 是规则靶子 （R1--R8 全部命中，退出码 1）。靶子目录里放了 10 个文件------R3（成环）需要两个节点，R4 有两种违反方式，所以报告是 9 条（8 ERROR + 1 WARN）。故意分开，是因为第一条命令应该是绿灯------想看清校验器的火力再看第二个，不必让"上手"和"报错"挤在同一条命令里。
还有一份 --todo 视图，它不报"哪里坏了"，只列 "还欠什么" ：cues 为空、source.ref 为空、notes 标了"待填"的节点。它不给答案，只列缺口，而且退出码恒为 0------因为缺口不是错误。
这两件事是一体的：空值合法，但空值必须可见。 一个说不出出处的案例照样是合法节点，它只是不能被当成依据。这跟"写坏了"是两回事。
我不确定的地方（这部分比上面重要）
- 未验证：这套结构在真实、大量、有分歧的知识上到底够不够用。 我至今没有在真实场景里跑过它
- 未覆盖：检索、内容库、版本迁移、多语言、权限、并发、验证方对接
- 至今 0 个使用者。 这是我第一次把它发出来，没有 star，没有 issue，没有任何人依赖过它。所以上面那些设计理由，都还是我一个人的判断
- 两个示例领域（路由器重启、室友的泡面）完全虚构，是我编的形状。请当形状看，不要当知识看
我要的不是 star
我不缺一句"这个想法不错"。我想知道的是：这套约束在什么场景下会不成立。
具体一点，我最想知道三件事：
- 你试着往这个结构里放一条你自己真的知道的东西，会不会发现某个字段根本没法填、或者两个字段在打架？------如果有，那是我的结构错了，不是你的知识不对
- "不代填"这条规矩，在你的使用里会不会很快就守不住？ 比如你让 AI 帮你填了一批，然后发现自己已经分不清哪些是你写的了
- 如果你要基于这套结构做一个面向普通人的工具------六层里哪一层会成为你的阻碍？哪些字段你会直接藏起来不给用户看？这个问题对我最有用，因为我下一步就是去做那个产品
反例比赞同有用得多。哪怕是"我试了五分钟，觉得没意义"这种反馈，也告诉我一件事：首值时间太长了。
最后
这个项目里我唯一敢说"做对了"的，是它的诚实度：
- 它算出了自己帮不了的部分 （那个
--todo清单会告诉你 21 个节点还欠着东西）
- 它的示例数据自己承认是模型编的
- 它的 README 里有一节叫「它不是什么」，而且我把那一节标得比"它是什么"更醒目
这是一个结构规格的可行性 demo，不是一个可用产品。 它证明的只有一件事：这套约束能不能落成能跑的代码。
Apache-2.0。层可以扔，四条硬规矩不能扔：
- 不代填内容------不知道就留空
filled_by如实标注
evidence_status不接受自声明
- 权威度、来源可信度、机构名望，不进任何排序逻辑
第 4 条最容易被当成一句空话，但它是这四条里我立场最硬的一条。因为一旦排序里混进了权威度，这个工具就会变成权威的放大器------那它服务的就是"你必须依赖某个具体专家"这件事，而不是相反。
如果这个结构里有一层是多余的、有一个字段是填不出来的、有一条规则会逼你为了过校验去改自己的文件------请开个 issue 骂我。那正是我想要的东西。
提前说清楚两件事，免得你白写：
- 按 CONTRIBUTING.md，加规则的门槛比加字段高 。规则约束所有人，还会让人为了过校验回头改自己的文件，所以新增规则需要我明确认账。有些 issue 我可能不改，但我会说清为什么不改------如果你只是想指出它不成立，那不需要我同意，那本身就是我要的反馈
- 上游不收真实领域内容。 收录谁、不收录谁，本身就是一次权威背书，跟上面第 4 条相冲。你的领域知识请放自己的 fork 里