“用户在 Web 上点了批准，工作流就进入下一阶段。”
这句话读起来没有任何问题，写进项目知识库也不会有人觉得奇怪。可如果对照 DevFlow 的代码，Web 发出的批准命令最终有 11 种可能的结果，其中只有一种叫 applied。下一个读到这句话的人或 Agent，会在“已经点了批准，为什么没有推进”这个问题上白白耽误很久。
这句话是我为本文写的示例，对照的是公开的 DevFlow 代码，并不是某个项目的历史原文。但它很好地说明了我在整理项目知识时最在意的事情：一条知识不只要写得通顺，还要带上它成立的条件、依据的来源，以及什么变化会让它失效。
这篇文章记录我在项目中应用 ISC-Q 整理知识的实践，并借 Palantir Ontology 的概念解释其中的建模思路。先说清楚分工：我是 ISC-Q 的使用者，负责在项目中应用它，整理、精炼和纠偏知识；平台本身并非由我开发。
我在 ISC-Q 里做的事
在企业项目中，我应用 ISC-Q，以项目代码和已有资料为输入开展知识精炼，并亲自参与知识的整理、纠正与纠偏。产出有两类知识：系统知识，承载对系统实现的理解；业务知识，承载对业务领域的理解。在此之上，我还整理了本体、知识图谱，以及图谱之间的关系。目标是为业务理解和后续的 Agent 任务准备一份有结构的项目上下文。ISCQ 实践概览
已有项目里，业务说明、代码实现和过去的分析往往同时存在，而且回答的是不同的问题：业务资料说明期望的规则，代码展示当前真正执行的逻辑，历史分析解释当时为什么这样选择。把它们放进同一个目录，只是完成了收集。整理真正开始于回答三个问题：这条知识描述的是什么，依据来自哪里，什么变化会让它失效。
系统知识与业务知识
两类知识可以互相引用，但不能混写成一份没有来源边界的百科。下面这张表是我整理时的检查清单，是方法上的归纳，不是对平台产物字段的逐项说明：
| 知识视角 | 应当解释的问题 | 整理时要留下的依据 |
|---|---|---|
| 系统知识 | 哪个模块执行这件事？状态怎样变化？接口怎样连接？ | 代码位置、实现版本、输入输出与约束 |
| 业务知识 | 这个概念是什么意思？规则适用于什么对象和条件？ | 规则出处、业务范围、例外与确认状态 |
| 两者之间 | 这条规则由哪里实现？当前实现有没有覆盖它？ | 规则与代码的对应关系，以及尚未解决的差异 |
这种区分最大的作用，是挡住一种很常见的推断：从代码里看到某个行为，就认为业务本来应该如此。代码能证明当前实现怎样运行；当实现和业务要求冲突时，要回到规则的出处，由懂业务的人来判断哪一边需要改。
按这种方式读项目，整理知识本身也成了学习的过程。理解一个术语之后，还要沿着关系找到它影响的对象、适用的规则和在代码里的落点。那些解释不清的关系，往往就是理解还有缺口的地方。
精炼是一串连续的判断
ISC-Q 平台为精炼提供了一套流程：Pilot 先检查所处阶段和前置产物，再交给知识编排器与子技能，按诊断、方向、执行、反馈、收尾五步推进。阶段记录、检查点和任务账本让中断的工作可以接续。这些机制属于平台，我的工作落在流程之中，主要是“执行”里的整理和“反馈”里的纠正与纠偏。
从使用者的角度，这五步对应五个判断：
- 诊断：哪些内容需要补充，哪些需要纠正？
- 方向：这一次要处理的范围是什么，往哪里改？
- 执行：结合代码和资料整理知识，更新内容和关联。
- 反馈：检查这一阶段的产物，纠正偏差。
- 收尾：沉淀确认过的知识，留下阶段记录，让下一次能够接着做。
这套流程给我留下的一个教训是：要按当前任务的产物判断进度，而不是按目录里有没有文件。平台自己就曾修正过这类误判，空目录和历史遗留的文档都可能让一个任务“看起来”已经完成。同样的道理也适用于知识本身：流程走到收尾，并不意味着没确认的结论就可以改写成事实。
用对象、关系和行动来想
Palantir 的 Ontology 给了我一套很好用的词汇。它把对象类型、属性、链接类型和行动类型组织在一起：对象类型定义一个实体或事件，属性描述它的特征，链接类型定义两个对象类型之间的关系，行动类型定义对象可以怎样被修改；一个具体的对象，是某个对象类型的实例。官方核心概念（在新标签页打开来源）
它还把这些要素分成两类：对象、属性、链接属于语义层，描述“世界是什么样”；行动、函数和动态安全控制属于动态层，描述“可以对它做什么、谁可以做”。Ontology 概览（在新标签页打开来源）
对整理知识来说，这个分法的启发很直接。除了问“有哪些资料”，还要问：系统在处理哪些对象，它们怎样关联，人或 Agent 可以对它们做什么，在什么条件下可以做。只画出一张关系图，只完成了语义这一半；图能不能支撑行动，还取决于规则、权限和实际的执行机制。
我借鉴的是这种思考方式。我的 ISC-Q 实践和 Palantir 的产品是两回事：没有任何材料表明这些项目接入了 Foundry，我整理的图谱也不能称为一套完整的 Palantir Ontology 或形式化的 OWL 本体。
一次纠偏示例
回到开头那句话。下面的知识草稿和纠偏结果都是为本文编写的示例，用公开的 DevFlow 代码来演示方法，不是公司项目的历史内容，也不是一次新的运行测试。
草稿写的是：“用户在 Web 上点了批准，工作流就进入下一阶段。”按对象、关系和行动来读，这句话至少混在一起说了三个对象：Web 端的决策命令、Desktop 本地的 Run、以及 Run 当前所在的节点。
ADR 0012（在新标签页打开来源） 规定，Web 只发出带版本条件的决策命令，完整的工作流状态由 Desktop 持有。Desktop 领取命令之后，Gate Command 处理器（在新标签页打开来源）会在本地重新检查一遍：
} else if (localRun.version !== command.expectedRunVersion) {
outcomeCode = 'stale_run'
} else {
const node = localRun.nodes.find((candidate) => candidate.id === command.nodeId)
if (!node || localRun.currentNodeId !== node.id) {
outcomeCode = 'evidence_blocked'
在这之后，它还要核对策略版本、阻塞项集合、与节点类型相符的命令，以及仓库知识的指纹。任何一项对不上，命令都会以 stale_run、stale_policy、blockers_changed 或 evidence_blocked 等结果码（在新标签页打开来源）结束，而不会被应用。Web 端收到 Desktop 的回执，也不会据此更新流程投影；只有之后 Desktop 同步上来的权威摘要，才会推进团队端看到的状态。
所以这一句话应该拆成三条互相关联的知识：
| 条目 | 纠偏后的表达 |
|---|---|
| 业务规则 | 批准只对提交时的 Run 版本、策略版本和阻塞项有效；其中任何一项变了，这条批准就不会生效。 |
| 系统机制 | Web 记录带版本条件的决策命令；Desktop 在本地重新校验，通过后才应用，再同步真实状态。收到回执不等于流程已经推进。 |
| 关系与依据 | Work Request 绑定一个本地 Run，Gate Command 指向预期的 Run 版本和节点。规则对应 ADR 0012，机制对应 Gate Command 处理器及其结果码。 |
改写找回的是原句丢掉的适用条件。以后有人问“点了批准为什么没推进”，可以沿着命令、版本和结果码去查，而不用从一句过度简化的描述开始重新猜系统。这也是本体思路在实践中的用处：先认出这是三个不同的对象，再写清它们之间的关系和行动条件。
知识要跟着任务阶段取用
知识有了结构，进入具体任务时还要再挑选一次。同一份资料，在不同阶段可能是必需的、可选的、还没到产生的时候，或者根本不适用。
DevFlow 有一个真实的例子。阶段上下文投影（在新标签页打开来源）为每个节点的每类输入标出状态：not_applicable、not_yet_expected、optional、required、available 或 missing_required。在 c6f0d20（在新标签页打开来源） 之前，一条全局的阻塞性测试规则会让需求澄清和方案设计阶段也把“已执行的测试证据”列为必需输入，审查提示词还会因为缺少这些要到编码之后才会产生的结果，就认为设计的测试策略有缺口。修复后，这类规则只在编码之后的阶段才要求测试证据：
const requiresTestEvidence = node?.stage !== 'clarify' && node?.stage !== 'design' &&
policy.rules.some((rule) =>
rule.target === 'governance_check' &&
rule.category === 'testing_standard' &&
rule.statusOrSeverity === 'needs_evidence' &&
rule.action === 'block')
提前存在的数据也不会被丢掉，而是作为补充或历史材料保留。这是 DevFlow 自己的实现，不是 ISC-Q 与 DevFlow 已经集成的证明；但它和知识整理回答的是同一个问题：保存下来的知识，要结合当前任务所处的阶段来用。
另一个相关的边界是引用。DevFlow 的检索与引用 ADR（在新标签页打开来源）要求一条引用精确指向文档、片段、内容哈希和快照哈希，只有片段仍然存在于绑定的快照中时才有效；过期、删除、伪造或跨租户的引用都会被拒绝。更重要的是，检索结果和引用始终只是上下文：它们不能满足治理检查，不能批准 Gate，也不能充当测试证据。能检索到、能解释、能据此执行，各自需要不同的条件。
从小处开始
知识库对我的价值，是让项目理解有一个能够检查、能够修改的落点。整理概念时学习业务，连接规则和代码时学习实现，处理冲突时明确哪些判断必须由人来做。Agent 可以帮忙扩大阅读和整理的范围，确认边界、纠正误解、为新的解释找到依据，仍然是人的责任。
如果从零开始，我会选一项具体的业务活动，先整理少量核心对象、它们之间的关系、一条关键规则和它在代码里的实现位置，然后试着用这些知识回答一个真实的问题。回答时暴露出来的缺口，就是下一轮精炼的起点。这是我建议的起步方式，并不是说已经验证过某种最优的知识库结构。
下面保留了 Palantir 官方课程的入口。学习时可以一直带着自己项目里的一个对象、一条关系和一个行动条件，学完再回到项目里核对它们是否描述准确。
材料说明：ISC-Q 部分依据我的应用经历和平台演进复盘，这份复盘本身是二手材料，未对照平台源码重新核实；文中没有公开企业代码、业务样例或内部记录，也没有声称平台研发归属或量化收益。DevFlow 示例核对的是公开提交 b7903c3；Palantir 的概念依据官方文档。课程链接来自官方文档与课程公告（在新标签页打开来源），查证时学习站点限制了自动访问，本文没有把课程正文当作已经读过的依据。