把复杂工作拆解为语义清晰、边界明确、可以执行、可以验证的最小任务单元，再通过规则、证据和任务依赖关系重新组合成完整成果。
化繁为简 · 受控语义 · AI 可执行任务 · 证据工程 · FDE 方法论
一、核心结论
复杂工作不应直接交给 AI 以一个模糊的大任务来处理。应先把它分解成可定义、可执行、可验证的任务，再由 AI 根据明确的规则和证据协助完成，最后依照任务之间的关系组合成完整成果。
核心原则：真正的简化，不是单纯减少文字或步骤，而是减少每个表达单元所承载的模糊语义，让复杂性显性化、结构化、可管理、可验证。
复杂工作 → 语义澄清 → 任务分解 → AI / 人协作执行 → 证据验证 → 成果组合
| 定义清楚 | 任务目标、输入、边界和完成条件明确，不要求执行者猜测关键含义。 |
| 执行可控 | 规定执行规则、工具、权限、异常处理与人类介入条件。 |
| 结果可证 | 重要结论有来源、有验证、有记录；不能仅凭 AI 自我声明判定完成。 |
二、问题的本质：复杂性常被模糊语言隐藏
复杂项目通常不是一个单一问题，而是由信息采集、概念理解、业务判断、技术决策、实际执行、风险控制和验收等多类任务组成。高手能够处理这些任务之间的关系；工程化的目标，是把其中可重复的知识和判断方法沉淀下来。
长句示例
当客户提交的资料符合完整性标准，且系统验证通过，同时授权人员完成审核后，系统才可以将资料标记为正式生效；任意一项条件不成立时，不得执行生效操作。
拆解为可检查的规则
- B：资料完整性检查通过。
- C：系统验证通过。
- D：授权人员审核通过。
- 只有 B、C、D 同时成立，才允许资料生效。
- 任何必要条件不成立，均不得执行生效操作。
注意：拆解不能改变原意。原文中的条件、例外、否定、顺序、权限和因果关系都必须保留；必要时还要补充待确认事项，而不是由 AI 自行猜测。
三、受控语义分解法（CSD）
“受控语义分解法”（Controlled Semantic Decomposition，CSD）是本文提出的内部方法论名称，并非既有国际标准。它可以与 ASD-STE100、Basic English、结构化需求工程和证据工程结合，但不等同于其中任何一种。
七条基本规则
- 1. 一个句子，一个主要命题 —— 把多条件、多例外的长句拆开，避免在同一句中隐藏多个判断。
- 2. 一个概念，一个稳定定义 —— 同一术语在同一项目中保持一致；相关概念不可随意互换。
- 3. 条件必须明确 —— 将“适当”“基本完成”“尽可能”等影响执行的模糊词转为可判断标准。
- 4. 事实、假设、结论分开 —— 明确哪些信息来自证据，哪些只是推测，哪些仍待客户确认。
- 5. 明确否定与例外 —— 区分“如果 A，则 B”与“只有 A，才允许 B”等不同逻辑。
- 6. 结论必须有成立条件 —— 重要状态不能只由模型宣布，必须满足预先定义的条件。
- 7. 进行语义保真检查 —— 确认拆解后没有遗漏条件、改变原意或添加未经授权的要求。
受控语言的目标
- 词汇层：明确关键术语在当前任务中的含义。
- 句子层：减少歧义和未明说的条件。
- 逻辑层：明确命题之间的依赖、先后和限制关系。
- 验证层：检查输出是否符合规则，并有证据支持。
重要边界：不应把“简单语言”误解为“只允许少量词汇”。专业术语在必要时仍应保留，但必须有定义。目标是控制语义自由度，而不是无条件减少词数。
四、AI 可执行最小任务单元
建议将核心任务单元暂称为 AI-Executable Atomic Task（AEAT，AI 可执行最小任务单元）。这是本文提出的设计概念，不是既有国际标准。
定义：一个具有明确目标、输入、执行规则、输出、验证条件和异常处理方式，并可由 AI 独立完成或在人类监督下完成的最小工作单元。
任务规格模板
案例：客户文件的来源初步核查
| 字段 | 定义 |
|---|---|
| 任务 ID | DATA-001 |
| 目标 | 检查文件是否具备足够的来源信息，以支持后续溯源核查。 |
| 输入 | 文件、提供者信息、取得时间、可用的系统记录。 |
| 执行规则 | 检查来源、生成方式、处理历史及相关佐证。 |
| 输出 | 结构化核查报告；逐项列出发现、依据和未解决问题。 |
| 验证条件 | 每项判断均能追溯到文件位置或其他证据。 |
| 异常处理 | 关键资料缺失时标记“待确认”，不得自行推定。 |
| 边界 | 来源信息检查通过，不等于已经证明该文件是真正的原始数据。 |
何时停止拆解？
- 可定义：任务目标与边界清楚，不需要猜测关键含义。
- 可验证：能够依据规则和证据判断任务是否合格。
- 可控错：失败时可以定位问题、限制影响并进入明确的处理流程。
当任务满足这三个条件时，通常不必继续拆分。过度拆解会增加任务调度、沟通和维护成本。
任务设计原则：可定义、可执行、可验证、可追溯、可控错。
五、标准工作链路
- 获取原始表达
- 提取命题
- 标记歧义与缺口
- 澄清并定义概念
- 形成结构化规格
- 分配任务执行
- 验证证据
- 组合成果
每个环节的关键输出
| 阶段 | 关键输出 | 常见错误 |
|---|---|---|
| 原始表达 | 原文、来源、时间、提出者 | 只保留摘要，丢失原始上下文 |
| 命题提取 | 对象、动作、条件、限制、结果 | 遗漏否定、例外或时序 |
| 歧义识别 | 歧义清单、未知项、冲突项 | AI 将未知信息当成事实补全 |
| 语义澄清 | 术语表、客户确认记录 | 不同角色对同一术语理解不同 |
| 结构化规格 | 需求 ID、规则、验收条件 | 描述清楚但无法测试 |
| 任务执行 | 执行记录、输出、状态 | 越权执行或跳过前置条件 |
| 验证证据 | 测试结果、来源、时间戳、批准记录 | 把模型自述当成真实执行证据 |
| 成果组合 | 完整报告、需求追踪矩阵 | 章节冲突、遗漏或引用过期 |
六、在 FDE 工程中的应用
1. 将专家能力转化为可复用资产
| 专业知识 | 沉淀为知识库、术语表、规则库、方法论和案例库。 |
| 专业判断 | 部分转化为决策树、检查表、澄清问题、风险规则和人工审核节点。 |
| 实际执行 | 由 AI 与工具协助完成文档处理、代码生成、测试、记录和报告等工作。 |
目标不是宣称 AI 可以完全取代专家，而是让专家的方法不必每次都依赖专家亲自处理所有细节。高风险、歧义大或影响范围不明的任务，仍应升级给有权限的人类判断。
2. 任务状态必须有明确定义
| 状态 | 含义 | 不能误认为 |
|---|---|---|
| 需求已定义 | 范围、规则和待确认项已记录。 | 不代表已实施。 |
| 任务已执行 | 执行动作已经发生，并有记录。 | 不代表结果正确。 |
| 技术验证通过 | 指定测试满足通过标准。 | 不代表客户已验收。 |
| 客户已验收 | 客户按约定标准确认接受，并留下记录。 | 不自动证明所有运行条件长期有效。 |
| 项目完成 | 满足项目约定的全部完成条件，并有相应证据。 | 不能仅由 AI 自行宣告。 |
FDE 完成原则：交付 ≠ 完成。真正完成应满足约定的客户确认、客户环境中的运行要求，以及可重放的验证证据。具体项目应在启动时定义各项条件及例外。
3. 将模糊需求变成可执行任务
客户说：“系统要自动处理资料，但不能影响现有业务，遇到特殊情况时最好通知我们。”
| 需求 ID | REQ-001 |
| 目标 | 系统自动处理符合条件的资料。 |
| 处理范围 | 待客户确认。 |
| 禁止事项 | 不得破坏已确认的现有业务功能。 |
| “特殊情况”的定义 | 待客户确认。 |
| 通知对象 | 待客户确认。 |
| 通知渠道与时限 | 待客户确认。 |
| 验收条件 | 待定义。 |
| 当前状态 | 待澄清；不得将未确认内容直接转成实施要求。 |
这份结构化表示将已知内容与未知内容分开，能驱动 AI 按照缺口逐项提问，而不是用猜测填补需求。
七、超长需求分析报告的治理方式
对于十万字级别的需求分析报告，不应把“整份报告一次生成、一次输入模型”作为默认工作方式。应以结构化需求记录为核心，分任务生成，再进行一致性检查和最终组装。
项目需求分析 ├── 01 项目背景与目标 ├── 02 现有业务流程 ├── 03 现有系统与数据分析 ├── 04 用户与权限分析 ├── 05 功能需求 │ ├── 05.01 功能模块 A │ ├── 05.02 功能模块 B │ └── 05.03 功能模块 C ├── 06 业务规则 ├── 07 非功能需求 ├── 08 接口与系统集成 ├── 09 风险与异常处理 └── 10 验收标准
推荐治理机制
- 每项需求拥有唯一 ID、版本、来源、状态和责任人。
- 每个章节作为独立任务生成、保存、验证和修订。
- 章节引用正式需求记录，不要在多个章节中各自重新定义同一概念。
- 保存章节之间的依赖关系、冲突记录和变更影响。
- 最终组装时检查缺章、重复、矛盾、失效引用和未解决事项。
- 保留原始客户表达与确认记录，确保需求结论可追溯。
关键提醒：拆分文件可以缓解单次上下文和输出长度限制，但不能自动解决跨章节的一致性。中央脑库应优先检索当前任务真正需要的需求、规则、案例和证据，而不是每次装载整份长报告。
八、RebornClaw FDE 平台架构建议
系统 A：任务工程系统
- 任务分解与依赖
- 工作流与状态机
- 优先级与并行调度
- 异常回退与重试
系统 B：AI 能力系统
- Agent 与工具路由
- 知识库与规则检索
- 受控 Prompt 与输出格式
- 人工审核与权限控制
系统 C：证据与验证系统
- 输入与输出留痕
- 验证规则与测试记录
- 来源、版本与时间戳
- 验收和重放证据
三套系统之间的关系
任务工程系统决定“做什么、先做什么、何时停止”；AI 能力系统负责“使用什么知识和工具来做”；证据与验证系统负责“是否做对、凭什么认为做对”。三者共同形成可管理的工程闭环。
建议的核心数据对象
| 对象 | 关键字段示例 | 用途 |
|---|---|---|
| Concept / 术语 | concept_id、名称、定义、边界、版本 | 保持语义一致 |
| Requirement / 需求 | requirement_id、原始来源、规范表述、状态、版本 | 需求追踪与变更控制 |
| Task / 任务 | task_id、输入、规则、输出、依赖、状态 | 任务调度与执行 |
| Evidence / 证据 | evidence_id、来源、时间、内容摘要、关联任务 | 支持结论和审计追踪 |
| Validation / 验证 | validation_id、规则、结果、执行者、证据引用 | 判定结果是否合格 |
| Decision / 决策 | decision_id、结论、依据、批准者、时间 | 记录重要人工或系统决策 |
九、质量指标与验证实验
“拆得更细”并不自动等于“推理更好”。建议用可重复的实验来验证：改善究竟来自句式简化、固定定义、结构化表示，还是验证规则。
建议实验组
| 组别 | 方法 | 验证目的 |
|---|---|---|
| A | 原始自然语言直接输入 | 建立基准表现 |
| B | 只改写为简单句 | 测量句式简化的独立效果 |
| C | 简单句 + 固定概念定义 | 测量概念稳定性的效果 |
| D | 简单句 + 定义 + 结构化表示 + 验证规则 | 测量完整方法的效果 |
可增加消融实验，例如只加结构化表示、只加验证规则，避免把所有改善都归因于“简单语言”。固定模型版本、任务难度、可用信息和评分标准；使用独立测试集，并对不同任务和重复运行进行统计。
核心评价指标
| 任务正确率 | 最终输出是否符合事先定义的正确答案或验收标准。 |
| 语义保真率 | 拆解或改写是否遗漏、扭曲原始要求，或添加未经授权的要求。 |
| 概念一致性 | 同一术语在不同步骤、章节和 Agent 之间是否保持同义同界。 |
| 条件遵循率 | 是否正确处理必要条件、否定、例外和先后关系。 |
| 无依据结论率 | 缺乏证据时，模型是否仍给出确定性结论。 |
| 可验证性 | 第三方能否根据记录、规则和证据重现判定过程。 |
建议的第一批测试任务
- 识别需求中的模糊词和缺失条件。
- 区分原始数据、加工数据和无法判定的数据。
- 检测相互矛盾或重复的需求。
- 依据证据判断任务是否满足完成标准。
- 将超长需求拆分成可追踪的结构化条目。
- 检查拆解结果是否保留原始语义、限制和例外。
十、风险与方法边界
| 风险 | 表现 | 控制方法 |
|---|---|---|
| 过度拆解 | 任务过多，调度和维护成本上升。 | 采用“可定义、可验证、可控错”作为停止条件。 |
| 语义丢失 | 拆解后遗漏例外、条件或隐含约束。 | 进行语义保真检查，并保留原文与来源。 |
| 错误形式化 | 把不确定的客户表述过早固化成规则。 | 明确标记“待澄清”，由授权人员确认。 |
| 错误累积 | 上游任务错误传递到下游。 | 设置关键检查点、失败隔离、回滚和重新验证。 |
| 虚假确定性 | 结构化输出看起来精确，实际依据不足。 | 要求来源、证据和置信状态；必要时拒绝下结论。 |
| 权限越界 | AI 自行执行高风险操作或扩大处置范围。 | 设置权限边界、人工批准和“停—报—等—记”流程。 |
| 跨模块不一致 | 不同章节或 Agent 使用不同定义。 | 共用中央术语表、需求 ID、版本和正式记录。 |
安全底线：对不可逆、高风险、权限敏感或影响范围不明的操作，不能仅凭任务拆解或模型输出就自动执行。必须设置授权、止损、报告、等待批准和记录机制。
十一、建议的落地路线图
阶段 1：建立最小标准
- 定义任务单元模板、术语定义模板和证据模板。
- 选取 10–20 个高频 FDE 任务，编写标准任务规格。
- 明确每个任务的输入、输出、验收条件和人工介入点。
阶段 2：建立可执行工作流
- 将任务模板接入 FDE 平台。
- 建立任务状态、依赖关系、失败回退和重试规则。
- 将 AI 输出限制为可校验的结构化格式，并保存运行记录。
阶段 3：接入中央知识与证据库
- 为术语、需求、任务、证据和验证记录建立稳定 ID。
- 让 Agent 按当前任务检索必要知识，而不是依赖整份长报告。
- 建立来源追踪、版本控制、变更影响分析和审计记录。
阶段 4：开展对照实验与持续改进
- 比较原始自然语言、简单句、固定定义和完整结构化方法。
- 统计错误类型、返工率、人工介入率、完成时间和证据完整率。
- 将真实项目中的失败案例回流为测试用例和方法论更新。
首个试点建议：从“需求澄清与需求条目结构化”或“资料来源初步核查”开始。它们高频、边界相对清楚，也容易建立可客观评分的验收标准。
十二、执行检查清单
在发布任务规格或让 AI 开始执行之前，逐项检查：
- 任务目标是否只有一个明确的主要结果？
- 关键术语是否已有稳定定义？
- 输入资料及其来源是否明确？
- 已知事实、假设、未知项和结论是否分开？
- 必要条件、禁止事项、例外和先后关系是否明确？
- 输出格式是否可供机器检查或下游任务使用？
- 验收条件是否可以客观判断？
- 关键结论是否要求证据支持？
- 失败、冲突、超时和信息不足时该怎么处理？
- 是否明确哪些动作需要人工批准？
- 拆解后是否保留原始语义，没有擅自新增要求？
- 任务的版本、状态、来源和依赖是否可以追踪？
最终原则：复杂性不应被模糊语言掩盖，而应被拆解、定义、结构化、验证和追踪。AI 的价值不只是生成答案，而是在明确边界内协助完成可验证的工作。