差别不在会不会输出 Markdown，而在事实从哪来、文档按什么粒度长出来。普通生成器通常直接读文件或让模型自己逛仓，调用链和模块边界很容易变成看起来完整的散文。这里先要求编译数据库，分析模式会区分完整和部分，叶子默认落在信道根下一层，父级只能读直接子文档，综合文档如果大段复制子文档正文会被质量门禁拒绝。问答还多了引用校验，没有对上本轮证据就不展示。所以它更像编译器辅助的知识平台，而不是一次 prompt 出一篇介绍。个人有没有从零设计这套边界，待确认。

因为它的确定性建立在编译数据库、翻译单元和 Clang 游标遍历上，这套工具链对 C 和 C++ 最完整。Python 或 JavaScript 没有同等意义的编译命令数据库，硬套会失去“确定调用”这个承诺。领域规则里也能看到物理信道、参考信号这些基带概念，说明它的观察对象是这类仓，但模块树本身按目录生长，不是把 PDSCH 写死成唯一仓库类型。如果面试官问我有没有做过其他语言适配，我如实说当前仓库没有，那是扩展方向，不是已经完成的能力。

附件路径会引入“模型或 Agent 去仓库外读文件”的授权问题，也更容易和认证文件、数据根目录搅在一起。现在的做法是平台先在任务目录写好有界上下文，再把全文从标准输入喂给一次运行，工作目录保持在被分析源码仓。这样 Agent 需要源码时看的是用户已经注册的仓，需要任务说明时看的是标准输入，不需要额外的外部目录授权。并发叶子任务还会给各自一份临时配置，避免抢同一个配置文件。这个选择牺牲了一点“让模型自己探索”的灵活性，换来的是写作过程可审计。

适配器并不假设可执行文件一定叫同一个通用名字，配置里可以指向参数兼容的企业启动器。它要的是能接受运行子命令、模型参数和 Agent 参数，然后在源码仓目录里跑起来。找不到可执行文件会立刻报错并指出要安装或改路径，而不是静默跳过文档生成。超时、非零退出码和空输出都会变成明确的平台错误，日志分开存标准输出和标准错误，方便现场排障。我没有企业现场的失败率数据，只能讲故障是暴露给用户看的，不是吞掉后假装成功。

仓库校验现在要求根目录存在 CMake 清单，所以不是任意目录丢进去就能完整跑。这是有意收窄：没有编译数据库，后面的编译器事实承诺就不成立。如果现场只有部分子仓能独立配置，代码里也考虑了后备路径，但会明确告诉用户已经切到部分分析。面试时我会把这说成已知限制，而不是“支持所有构建系统”。若要扩展到其他构建工具，需要先能导出等价的编译命令列表，而不是让模型猜 include 路径。

完整数据库来自 CMake 导出，带有每个文件真实的包含路径、宏和标准。后备路径是在配置失败后扫描源码拼出来的，能让流程继续，但不能保证翻译单元按项目原意被解析。因此后续分析模式会落到部分，词法补充可以给包含和未解析调用，却不能把它们升级成编译器确认的调用链。进度事件里会写明降级原因，避免工作台看起来像“已经完整分析”。我不会把后备模式说成和完整模式同等可靠，这正好是项目要避免的虚假确定。

因为静态游标能看到的是一次调用表达式，不一定能唯一解析到运行时目标。目标可能来自表、回调注册，或条件编译后的另一条路径。项目把无法唯一解析的调用留成候选关系，默认确定路径和检索扩展都不会把它当成已经发生的调用。领域规则也只有在多项编译器证据同时满足时才确认分类。这样做会漏掉一些真实的间接调用，但这比画出一条漂亮却无法打开源码位置的假链路更安全。如果面试官继续问我怎么补，我会说那是运行时追踪或人工确认的事，不是当前分析器该悄悄完成的事。

我不会说“证明了百分之百没有”。我能指的是几道闸：任务上下文里写明编译器证据、源码证据、推断和无法确认的使用规则；候选调用只能进待确认段落；输出校验看章节是否齐全，综合文档还检查有没有把子文档正文机械拼接上去；问答阶段再校验引用是不是本轮证据。这些是过程约束，不是最终正确率。若要量化，应该抽一批生成文档，人工标“确定 / 推断 / 编造”比例，仓库里还没有这份评测，所以我只讲机制。

算父级自己的直接源码，不当成又一个叶子。否则会出现“目录既是汇总节点又被自己文件拖成叶子”的混乱。知识构建会给每个文件找所属目录，信道根直接拥有的文件留在父级，子目录才形成叶子。规划父级任务时，这些文件和子文档摘录一起进上下文，但父级的章节契约更强调任务、故障和模块路由，而不是把入口文件再写成另一份工程说明书。面试时我可以用 PDSCH 根目录的入口文件当例子，先画树再讲归属，比空讲概念清楚。

生产环境更推荐反复指定信道根，让框架自动把每个根的直接子目录当叶子。只有目录真的不规则，才用叶子路径覆盖，而且不能和信道根参数同时用，避免两套边界互相打架。这是配置层的互斥，不是运行时猜。代价是使用者必须理解自己的仓长什么样，框架不会仅凭名字盲目切分。默认名字集合里虽然有一批常见信道名，但那只是未显式配置时的辅助，正式环境仍应以显式信道根为准。

写作适配器给每个任务一份临时配置文件，指向各自的上下文，而不是大家抢同一个文件名。文档 Agent 默认禁止工具，工作目录是源码仓，真正写 Markdown 的是平台自己。所以并发抢的是外部模型额度和本机 CPU，不是抢平台数据库里的密钥——平台根本不存密钥。任务中心还有另一层限制：模型类任务默认单车道，同一仓库也不能同时跑两个写入任务。叶子并发是生成流水线内部的模块级并行，和平台任务车道要分开讲，否则面试官会以为整站可以无限并行打模型。

因为它的子文档是各顶层模块和架构页，必须等这些导航材料先存在，才能做仓库首读入口。规划器把仓库架构和首页放在层级任务后面，流水线也没有把它们丢进叶子线程池。首页的上下文预算里，子文档占比非常高，源码占比很低，这就是在逼模型做路由而不是再写一遍实现。如果并行写首页，最常见的失败不是慢，而是导航链接指向还不存在的篇目，或为了凑字数复制叶子。质量门禁对综合文档的反复制检查，就是在防这件事。

因为上层文档的职责是路由：告诉 Agent 或工程师下一步该进哪一篇，而不是再造一本合订本。如果允许大段复制，生成会变快、看起来也更“全”，但会破坏分层，检索时同一段话出现在三层文档里，引用会失去指向。实现上会给综合文档补子文档导航，并在校验里检查是否机械拼接。模型如果复制，就走一次修复，修复提示会要求精简且章节齐全。这是产品决策，不是文风偏好。我讲的时候会主动说：上层短、下层深，阅读方向和生成方向是反的。

校验会失败，不会把半成品写成当前 Wiki。流水线先尝试从标准输出里挑最后一份结构完整的稿，因为有的模型会在一次运行里吐出多段逐渐完整的结果。如果挑完仍缺节、或围栏没闭合、或看起来像报错文本，就带上失败原因再跑一次，要求只输出最终正文。第二次还失败，任务失败，断点不会把这篇标成完成。用户可以看该任务的标准输出和标准错误定位是模型跑飞还是契约过严。我没有统计过修复成功率，只能讲有一次自动修复，不是无限重试。

源文件或叶子变化，要重生成受影响叶子和所有父级。公共头变化会按反向包含扩大范围。CMake、编译数据库或模块边界变了，分析本身就不可复用，必须完整分析。只改向量配置，则只重建向量索引。集合成员或成员当前快照变了，重建集合关系和集合 Wiki。没有 Git 时用内容哈希比。面试时我会强调：断点复用看的是“同一版事实”，不是“同一个文件夹还在”。如果我说不清哈希比的是哪些字段，就承认要对照增量规则文档，不现场编一套规则。

任务中心在启动时会把排队中和运行中的任务标成中断，并留下进度事件。它不会假装这些任务还在另一个已经消失的线程里跑。对仓库 Wiki 生成，用户可以从断点继续或重试；继续仍走新建快照那条路。同一仓库在仍有写入任务排队或运行时，不能再开第二个写入任务，避免两个生成互相覆盖当前快照指针。这是本机单用户平台的保守并发，不是分布式调度。我不会把它讲成高可用集群，它就是防把本机数据根写坏。

无限重试会在额度、超时和坏上下文上打转，最后可能用更空的套话凑过章节名。一次修复的意义是处理“结构差一点、内容还在同一批证据上”的情况，而不是让模型自己发明缺失事实。修复提示明确要求不增删二级章节、控制篇幅、只输出正文。如果证据本身不够，正确结果应是章节还在、里面写无法确定，而不是编出调用链来过门禁。所以门禁和证据规则是配套的：一个管结构，一个管真实性声明。重试次数是产品上的刹车，不是技术做不到循环。

一级标题后的导航卡由框架确定性补齐，不把这件事交给模型自由发挥。上层文档还要自动补下钻到直接子文档的链接。这样即使用户换模型，导航结构仍稳定，Wiki 页面和导出 ZIP 才能按层级走。模型负责在契约章节里解释本层任务和证据，不负责发明一套新目录。我讲设计时会把“确定性框架 + 受限模型写作”说成同一原则在输出阶段的落点，和前面的分析模式分层是一个思路。

融合解决的是“多路都召回到了，怎么合成一个序”，它并不理解编译器事实比词法更硬。如果只融合，一段写得很像的人工笔记可能压过精确符号定义。所以在融合分之上，对查询里识别出的标识符命中、编译器确定性、人工确认知识再做确定性加分。这是规则，不是又一个模型。加分幅度写得很小，意图是打破平局，而不是让某一路垄断。是否调过这些系数，仓库没有实验记录，我不会编一套“调参提升了多少”。

确定关系数量在大仓里可以非常多，每条边都做嵌入会重复消耗 CPU 和内存，而边的检索价值主要在扩展而不在语义近似。设计是让图块进全文和关系扩展，候选边和已拒绝边默认不进仓库索引，免得“可能调用”被搜成事实。这和图谱可视化是一致的：候选边可以显示，但不进默认确定路径。代价是语义上像的间接关系可能召不回，需要用户换精确符号或先看图。这是容量和诚实性一起做的选择。

因为用户第二问常常换了符号或模块，旧证据可能已经偏了；把长对话原文续进去，看起来像多轮，其实是在用过期摘录写作。短摘要只保留问题方向，真正的事实仍从当前索引来。这会多花一次检索和一次模型调用，但引用编号始终对应本轮附件，校验才有意义。如果沿用上一轮编号，修复逻辑会和过期证据缠在一起。我把它讲成“会话是短的，证据是新的”，和文档生成里“父级只读直接子文档”是同一类限制上下文的思路。

是会显得严，但这是本机知识工具该有的失败模式。把一段无法核对的答案显示出来，工程师可能顺着错误调用去改代码，代价更高。失败文案会说明是无效引用或没引用可用证据，并拦住展示。排障时还可以看该轮的上下文文件和修复日志。如果现场经常失败，更该查索引是否建好、模型是否遵守指令，而不是把校验关掉。我不会说这套体验已经很好，只能说失败是显式的、可定位的。

核心节点用综合分数找“应该先读的入口符号”，分数考虑连接度、中心性、跨社区跨度和领域权重，它是阅读入口，不是正确性证明。惊喜链接从已确认关系里筛跨模块或跨社区、名字还不像的边，用来发现目录结构之外的隐性耦合。两个视图都限制在局部子图，避免中大型仓一次渲染全部符号。前端默认先按模块或社区聚合，再下钻。如果没有测量过“工程师找到入口的时间是否缩短”，我就说这是导航设计，不作效率承诺。

会持续提示部分分析。词法调用仍在，状态是候选，不能看起来像完整调用链。构建目标和翻译单元如果来自不完整的编译数据库，覆盖率统计也会偏弱。工作台如果把这些边画成实线确定调用，就违背契约，所以规范要求编译器、构建和源码显式关系才是实线，词法和模型结果是虚线并标明候选。我讲图的时候会先说警告条，再说能点开的证据检查器，强调一条逻辑边可以对应多个源码位置，但画布上只聚合成一条边。

不会。删除的是注册记录，可选再清平台产物和索引。源码仓路径只是被引用，平台承诺不复制、不合并、不编辑源仓。同步到代码仓是另一条显式用户动作，而且只更新自己清单里的文件；目标目录已有但没有清单时会拒绝覆盖，避免把别人的文档冲掉。面试时我把“只读源仓”和“显式同步”分开，避免听起来像框架会随便在项目里铺文件。有没有在真实项目里执行过同步，待补。

现场常常有多个相关仓，工程师想跨仓搜接口、看候选关系，但不想也不该把源码拷到一处。集合只保存成员关系和集合级 Wiki、索引，源码仍在各自注册路径。跨仓确定关系要求签名和头文件对得上，名字像只能当候选。合成大仓会破坏各自构建系统和权限边界，也会让删除集合变成删除代码的风险操作。这个模型和“多仓 monorepo”不是一回事，我不会用 monorepo 去套。

即使路径合法，一次把整份大文件读进工作台也会拖垮浏览器，也增加误把整文件贴进对话的风险。接口会夹紧起止行，并给单次读取一个上限。这不是加密，是操作面收敛。和图谱默认局部加载是同一原则：先给能看完的一块，再让用户下钻。如果面试官问缓存投毒或符号链接追出仓外，我需要看解析和父目录检查是否覆盖链接情况，不能在没核对的情况下打包票。当前我能确认的是 resolve 之后做父目录包含判断。

目标环境是 Windows 离线机，运行时再依赖容器、外部图库或在线下载模型，现场会直接挂。属性图和任务状态放在本地 SQLite，向量用本机 ONNX 加本地索引文件，模型缓存只能由准备步骤放进数据根。前端构建产物打进 Python 包，生产机不必再装 Node。这是交付约束倒逼的架构，不是“SQLite 一定比专业图数据库强”。换到超大仓时，单机索引和内存会成为瓶颈，这是已知风险，需要用真实仓测量，不能用架构形容词代替。

稳妥版是“基于源码精读，能讲清本地 C/C++ 知识平台如何把静态分析、分层 Wiki 和带引用问答串起来”。进取版只有在我能拿出提交、设计和验证记录时才升级成“负责其中某条链路的设计与实现”，并且仍要写清协作边界。进取版绝不能自动加上用户量、时延下降或“全公司采用”。目标岗位如果是 AI 应用，我突出有界上下文、引用闭环和密钥隔离；如果是后端，我突出任务车道、快照和路径沙箱；如果是编译器或基础工具，我突出分析模式和确定/候选分离。岗位变了，强调的支柱变，事实不变。

第一句是有没有真实指标，答案是没有公开测量，只有结构和单测。第二句是个人到底写了哪些模块，答案是待确认，不能用“我”把全仓领走。第三句是部分分析时还敢不敢说“我们提取了完整调用图”，答案是不敢，必须降级。能守住这三句，前面那些机制才像工程，不像包装。建议我先对着导学把主链路画出来，再用这个面经练追问；讲顺之后，再决定要不要把确认过的职责交给经历改写，做成简历条目。

因为失败模式不同，重做成本也不同。生成依赖外部模型和章节契约，最贵也最容易中断；索引依赖切块和可选向量运行时；图谱依赖分析产物和社区计算。拆开后，只改嵌入配置不必重写 Wiki，图分析失败也不必把叶子文档作废。任务中心用不同车道也是这个原因：模型任务和 CPU 任务互不堵死。代价是用户要理解工作台里有多颗按钮，所以完整生成入口会把分析、叶子、父级、入库串起来，选择性维护才暴露细粒度。产品上是“一条主路径，若干补做路径”。

文档说得很清楚，选择性维护只是按文档类型或模块重跑同一套流水线，不是第二套生成器。界面默认收起，就是怕用户以为存在另一套更快但不讲证据的捷径。规划器支持按类型和模块过滤，所以可以只重做某几个叶子再汇聚父级。它仍然走同一份上下文、同一份校验和同一份断点规则。我如果把它讲成“两套系统”，面试官再看源码会对上失败。正确说法是同一引擎的过滤入口。

三维总览用来建立仓库级直觉，二维工作台用来做能核对证据的分析。规范写明三维是可选概览，默认仍限制局部子图，避免中大型仓一次渲染全部符号。如果只有三维，面试和排障时点不开源码位置；如果只有二维大表，用户不容易先抓住社区和桥接点。两者共用同一份确定/候选关系，不允许三维把候选边画成更“真”的效果。我没有用户研究数据，只把这讲成显示层分工。

导出是把当前有效快照按层级打成 Markdown 或压缩包，离开平台也能读。同步到代码仓是显式把当前快照写进注册仓里的平台目录，并且只更新清单管理的文件，不删除目录里其他人工文档。没有清单还已经有内容时拒绝覆盖。前者是带走，后者是回写，回写默认关闭在“自动行为”之外。这和“平台不擅自改源仓”的承诺一致。有没有项目强制要求文档必须进仓，待补。

其他项目如果是业务 Agent 或中转站，强调的是调度、协议和产品功能；这个项目强调的是“事实从编译器来、模型只在有界上下文里写作”。重复的词可能都有检索、文档、Agent，但机制不同。写简历时每个项目只留两到三个支柱，这个项目我会留证据分层、分层编排、引用闭环，把密钥隔离放到追问里，避免所有项目都写“安全”和“RAG”。没有确认的职责一律不写进对外 bullet。若两个项目真用了同一套检索，就只在一个项目展开，另一个改写为业务结果。

缺三类。第一类是个人边界：哪些模块是我改的，要有提交或评审记录。第二类是一次真实仓跑通记录：分析模式、生成篇数、校验失败、断点续跑是否发生过。第三类是抽查：引用能否打开、父级有没有抄叶子、部分分析有没有被误写成完整调用图。有了这三类，才能把“待测”变成有条件的结果句。没有之前，面经只适合练表达，不适合直接变成已确认成果。这也是我建议先讲、再改简历的原因。