一位从业者公开了一套名为“4层执行架构”的方法论。这套系统的核心设计目标，是尽可能消除大语言模型在代码执行过程中的模糊判断，将“理解我的意图”这一需求，前置到执行开始前的设计阶段。

该系统由四层纯Markdown文件构成，不依赖任何特定框架、运行时环境或供应商锁定机制。其最核心的规则在于：判断行为仅被允许在唯一的一层中、通过唯一的一种机制进行。在其他所有层级中，歧义无法被表达——它要么根据磁盘上已存在的数据自行消解，要么系统停止运行并主动向人类提问。

打开网易新闻 查看精彩图片

该架构明确区分了两个关键概念：“条件”与“判断”。条件是指根据已经写入文件或状态的数据进行分支，例如判断一个状态字段是否为“已完成”。而判断则是指基于解释、模糊性或者个人偏好进行分支。在这套系统中，每一个“判断”最终都经由一个人类决定来消解，其实现机制为“ASK”指令，该指令会阻断执行流程，直到人类给出答复。条件被允许在上两层中合法使用，而判断仅被允许在其中的一层。

架构的层级间具有严格的单向调用规则：每一层只能调用其下方的层，没有任何一层能够向上调用。设计者指出，这种分层虽然与前沿LLM平台上的“工具/技能/代理”等词汇存在概念重叠，但并非一一对应。行业术语的边界往往是模糊的，而这些层级则泾渭分明。问题的关键在于，行业通用词汇不会告诉你机械性指令在哪里结束、判断在哪里开始。一个平台的“技能”文件，可能会在一系列名义上的机械性指令中，悄然包含一个需要判断的选项，比如“选择用户到底想要X还是Y”，而这种模糊性在这套新架构中是不被允许的。

从业者表示，借助这套架构，人力资源与LLM在数天内就于一个名为“paragraf”的代码库中完成了超过20个工作项。这些任务包括创建新的UI包、修复缺陷、提升测试覆盖率以及API清理，并且每一个项目都经历了规划、实现、测试验证和归档的完整流程。架构使用者在一个典型的工作项中所需做的贡献，仅是两个决策，因为其他上百个决策在系统设计之初就已一次性完成。