# 从工程手艺到系统科学：面向智能时代的软件构造方法论

> **Position Paper** | 面壁智能 (OpenBMB) · Loushang 项目组

## Status

Legacy position paper.

本文保留产品愿景、方法科学和治理模型背景。文中的 `loushang-methods`、
`methods/` 和旧 `docs/architecture/` 表述是历史术语，不代表当前包名、
目录布局或实现状态。当前实现边界以 live architecture docs、代码和测试为准。

---

## 摘要

软件开发的演进本质上是一部"构造策略与利用方式"的演进史。从手工作坊式的个人编码，到工业化的敏捷流程，再到当今 AI 辅助的生成式开发，每一次范式跃迁都延伸和重构了前一阶段的构造策略，又演进出新的能力利用方式，从而推动软件系统复杂度的持续跃升。

当前，以大语言模型（LLM）为代表的智能技术正在深刻改变软件构造的底层逻辑。然而，现有实践仍高度依赖个体经验、启发式规则与临时性协调，缺乏对软件构造全生命周期的系统化建模与协同治理。这种"工程手艺"模式在简单场景下尚可运转，但在面对复杂系统、长时演进、多角色协作与可审计交付时，已暴露出根本性瓶颈。

本文认为，面向智能时代的软件构造正逐步迈入**"方法-运行-治理"协同演进**的新阶段。在这一范式下，我们探讨了实现**科学化软件构造**所经历的三个关键系统性转向：

**（1）从经验驱动向方法论牵引的科学化转变**：通过将模糊的最佳实践转化为可度量、可运行、可验证的方法资产，为系统化的精细软件构造奠定理论基础；

**（2）从粗放式任务执行向精细化分级治理转变**：通过构建 **P0–P4 分级构造体系**，根据系统不同演进阶段的需求实现构造策略的精准适配，避免了传统开发中"一刀切"的低效；

**（3）从人工单向驱动向"人-机-方法"协同演进转变**：使智能体从被动的工具使用者转向主动的方法执行者，通过双向驱动与动态适配机制最大化方法对系统能力密度的增益贡献，实现方法质量与系统能力的闭环迭代。

此外，我们还分析了新范式下软件构造在**基础设施（Infra）**与**安全可信**方面面临的挑战。我们希望能够通过构建的科学化和系统化的软件构造体系，推动软件开发从"个人手艺"走向"工程规范"，最终迈向"方法科学"，为智能时代复杂系统的可持续演进开辟新的发展路径。

---

## 1 引言

### 1.1 软件构造的范式演进

纵观软件开发的发展历程，本质上是一部"构造策略与利用方式"的演进史。每一次范式跃迁既延伸和重构了前一阶段的构造策略，又演进出新的能力利用方式，从而推动软件系统复杂度的跃升与涌现。

根据核心构造策略的不同，我们可以将软件开发的演进分为四个阶段：

**（1）手工作坊时代**：最初的软件构造确立了个人技艺驱动的范式，依赖少数专家的直觉、经验与编码习惯。这种直接的能力应用思路，在当前许多初创团队的快速迭代中仍得以延续。

**（2）工程化时代**：软件工程学科开启了流程与方法论驱动的范式，从瀑布模型演进到敏捷开发，软件质量取决于流程规范、工具链成熟度与团队协作效率的提升。在大模型时代，高质量流程的价值通过 DevOps 与持续交付被重新定义，用于精确引导系统的输出行为。

**（3）平台化时代**：进入云原生与微服务时代，软件构造突破了对单一技术栈的完全依赖，进入以平台能力（Platform Capabilities）为驱动的自服务阶段。通过标准化接口与可复用组件，使系统能够深度压缩和内化领域知识，从而带来了跨团队泛化能力与系统涌现。

**（4）智能体时代**：随着进入 AI 驱动时代，软件系统开始利用大语言模型与智能代理进行辅助构造（AI-Augmented Construction），通过持续的交互和优化，实现对输出行为的主动探索和能力强化。这一阶段不仅提升了系统在复杂场景下的构造与适应能力，也为通用智能软件（General Intelligent Software）的演进奠定了基础。

### 1.2 当前瓶颈

当前软件构造性能提升面临可持续发展的问题：传统经验主导的构造范式难以为继，亟需效率更高的构造方法。尽管当前研究已从代码生成、自动化测试、智能重构等方面探索了提升开发效率的途径，但相关工作多围绕具体问题和任务展开，缺乏贯穿软件构造全生命周期的系统化治理体系。

当前软件构造策略与利用方式仍存在诸多问题：

**（1）科学评估体系缺失**：现有方法仍高度依赖个人经验与启发式规则，缺乏对方法内在价值的科学化评估体系，容易受到认知偏差的影响，导致方法对系统能力提升的贡献难以被量化与解释，从而制约了治理效率与系统性能的可控性。

**（2）构造模式粗放**：方法在构造流程中被视为"同质"资源，缺乏依据其对系统不同阶段与能力需求的差异化贡献进行精细划分与调度的机制，制约了方法对系统能力的最大贡献。

**（3）人-机-方法难以协同优化**：当前的构造流程仍处于"人→工具→代码"的单向驱动模式，智能体对方法的反馈是离散且滞后的，缺乏动态、闭环的"人-机-方法"协同优化机制，难以实现系统能力的持续、自主跃迁。

这些问题已成为提升系统能力密度的核心瓶颈，不再是单点优化或局部工程改进所能解决的，而是亟需对方法的价值评估、阶段化供给与持续利用机制进行系统性重构，构建一套更加科学化、规范化的软件构造理论体系。

### 1.3 核心论点

通过对这些问题的分析和探讨，我们认为软件构造策略和利用方式正逐步迈入**方法-运行-治理协同演进**（Method-Runtime-Governance Co-Evolution）阶段。

首先，需要通过科学的方法价值评测将模糊的质量概念转化为可量化的价值指标；然后，基于方法价值密度实现精细化的治理体系，根据系统不同演进阶段的需求实现方法的精准适配；最终，通过智能体与方法的双向反馈实现闭环演进。

在这一范式下，软件构造正经历三个关键的系统性转向：

**（1）从工程经验主导向方法价值牵引的科学化转变。** 核心在于挖掘方法中蕴含的知识、逻辑与推理链条，通过评估单位方法为系统带来的"能力增益"，将方法质量从模糊的工程概念转化为可度量、可优化的科学指标。

**（2）从粗放式规模扩张向精细化分级治理转变。** 强调"因材施教"的治理策略，即根据系统不同演进阶段的实际需求，对方法进行精细化分层与调度。通过构建 **P0–P4 分级治理体系**（P0 原始经验 → P1 过滤知识 → P2 精筛方法 → **P3 可运行方法元** → P4 编排方法体系），实现方法的精准适配。其中 P3 是整个体系的分水岭——方法从"被动消费的知识"跃迁为"主动驱动的资产"，可被智能体直接加载、执行与验证；P4 则将多个 P3 方法元编排为可治理、可演进的方法论。这一分级避免了传统治理中"一刀切"的低效，实现了更严谨的质量控制。

**（3）从人工单向驱动向"人-机-方法"协同演进转变。** 这一转向使智能体自身成为方法生态的内生环节。智能体不再仅仅是方法的消费者，更能通过自身能力的反馈指导方法的筛选、生成与优化。这种"人机共生"的动态适配机制，实现了方法与系统的双向驱动与持续迭代。

---

## 2 软件构造科学

### 2.1 科学方法评估

方法评估的重要性体现在三个方面：

1. **支撑精细化方法治理**：优化高价值方法使用，指导低质量方法改进；
2. **提升资源利用效率**：明确方法对系统能力的贡献，为构造提供科学指导；
3. **驱动人机协同闭环**：支持动态构造优化，实现系统能力持续迭代。

随着智能体辅助开发的发展，方法质量对系统性能的影响愈发显著，传统依赖人工经验或简单规则的评估方法已难以满足需求。方法评估正从"经验可用"向"价值度量"演进，通过量化方法的信息含量、可靠性与多样性，构建科学化、系统化的评估体系，实现先验与后验评估的动态闭环。

当前，方法质量评估主要可以分为**先验（prior）**与**后验（posterior）**两类。值得注意的是，先验与后验的划分是**相对于方法执行**而言的：先验评估在方法运行前完成，后验评估在方法运行后基于实际效果反馈完成。这种划分与 P0–P4 分级体系形成正交关系——每一级方法都可以独立进行先验或后验评估。

#### 2.1.1 先验评估方法体系

先验评估是在系统构造开始前，基于方法的统计特征、结构属性或外部知识，对原始方法进行系统分析和价值预测的过程。

**（1）专家主观评估**

早期，方法的质量主要依靠专家的主观评估。然而，这种方法在实际应用中容易产生认知偏差，难以保证评估的一致性。同时，高昂的人力成本也限制了其在大规模系统上的可扩展性。

**（2）基于特征的统计评估**

针对主观评估的局限性，研究者开始采用基于方法特征的统计方法：

- **方法相似度/重复度**：若方法重复度过高，系统在构造中反复接触相似内容，将导致有效学习信号密度下降。常用的评估方法包括代码克隆检测、语义相似性分析等。
- **方法复杂度**：过高的复杂度往往预示着理解困难、维护成本高。圈复杂度、认知复杂度等指标被广泛用于评估。
- **方法多样性**：方法多样性是确保系统具备通用泛化能力的关键，包括技术栈分布、设计模式覆盖等多个维度。
- **方法时效性**：构造方法与当前技术环境之间的时间偏移会显著影响系统性能，尤其在快速演进的技术领域。

**（3）基于模型的评估**

为实现对方法质量的更细粒度评估，研究者借助大模型的语义表征与知识判别能力：

- **困惑度（Perplexity）**：衡量模型对方法序列的预测困难程度，PPL 越高，方法质量越低。
- **基于 LLM 的质量评分**：利用大型语言模型的零样本或少样本推理能力，通过精心设计的提示对方法在主观质量维度进行量化评分。
- **LLM 辅助标注**：为海量方法生成结构化元数据，支持细粒度的评估与筛选。

#### 2.1.2 后验评估方法体系

后验评估是指在系统构造完成后，通过观察待评估方法对系统在基准测试上性能的实际影响，来反推其内在价值的评估范式。

**（1）全量构造验证**

全量构造验证是最直接的后验评估方式，能够验证方法/方法配比的真实增益。然而，这种策略的计算开销极为庞大，难以支撑细粒度的方法价值归因或高频迭代的评估需求。

**（2）高效验证（Efficient Verification）**

为降低评估成本，研究者提出了非全量/轻量化验证的替代方案：

- **增量验证**：在已有系统基础上进行局部退火（decay）来快速评估方法质量。
- **代理模型验证**：使用小规模代理模型快速验证方法效果。
- **影响函数（Influence Functions）**：分析特定方法样本对模型参数的实际影响量。

#### 2.1.3 方法价值牵引的科学化评估

先验与后验评估方法各有优势，但当前缺乏系统化的理论框架与统一标准。未来的方法评估体系应兼顾效率、可靠性与可解释性，通过"方法价值"衡量方法的内在信息含量，实现先验与后验方法的动态闭环。

未来方法评估的发展可聚焦于以下三个方向：

- **面向方法价值的 Scaling Law 建模**：构建面向方法价值的 Scaling Law，深入推演方法内在价值密度与系统损失函数之间的数学映射。
- **基于方法价值的评价体系**：依托智能体解析能力构建先验质检智能体，结合后验快速验证机制，建立完整的方法价值评价体系。
- **方法价值风洞**：借鉴航空航天领域的"风洞实验"思想，通过构建小规模实验环境或轻量化代理模型，模拟大规模构造过程，快速评估方法价值。

### 2.2 精细化方法分级治理

分级方法治理的核心价值体现在以下三个维度：

1. **重构方法治理逻辑**：确立以价值密度为核心的分级标准，驱动方法治理向精细化、可追溯的方向升级；
2. **方法全生命周期治理**：建立基于 **P0–P4** 的分级体系，实现方法从采集、清洗、筛选与使用各环节的有序衔接与动态优化；
3. **最大化资源利用率**：结合智能治理机制，通过递进式治理突出高价值方法，实现**方法价值密度**的系统化管理与持续提升。

#### 2.2.1 现有方法分级治理体系

现有的方法治理体系可以从两个维度进行归纳：基于系统演进阶段的治理体系和基于方法处理方式的治理体系。

**（1）基于方法形态的治理体系**

- **经验层治理**：面向 P0 原始经验，核心是采集、去重与初步结构化。
- **知识层治理**：面向 P1 过滤知识，核心是格式规范化、质量筛选与版本管理。
- **方法层治理**：面向 P2 精筛方法，核心是主题聚焦、逻辑校验与社区验证。
- **资产层治理**：面向 P3 可运行方法元，核心是执行验证、输入/输出契约固化与自动化测试。
- **体系层治理**：面向 P4 编排方法体系，核心是跨方法编排、依赖管理、版本治理与可信校验。

**（2）基于方法处理方式的治理体系**

- **经验解析（Experience Parsing）**：将异构原始经验（博客、笔记、对话记录）转化为机器可理解的结构化资产。
- **知识过滤（Knowledge Filtering）**：通过低成本的工程化手段剔除噪声，保证知识质量的下限。
- **方法筛选（Method Selection）**：通过模型分类器或社区投票对方法进行质量或维度筛选，从 P1 晋升到 P2。
- **资产合成（Asset Synthesis）**：通过模型生成或人工编排，将 P2 方法升级为可直接执行的 P3 方法元（如 SKILL.md）。
- **体系编排（Methodology Orchestration）**：将多个 P3 方法元编排为完整的 P4 方法体系，定义方法间的依赖、调用顺序与数据传递。
- **执行验证（Execution Validation）**：对 P3/P4 进行实际运行验证，通过后验反馈驱动方法质量的持续改进。

#### 2.2.2 精细化方法分级治理体系

为了突破现有治理体系的局限，必须建立一套以"价值密度"和"可信度"为核心的精细化分级标准。因此，我们提出 **P0–P4 方法分级体系**：

| 级别 | 名称 | 定义 | 治理手段 | 构造用途 |
|------|------|------|---------|---------|
| **P0** | 原始经验（Raw Experience） | 未经任何实质性处理的初始经验，规模庞大，包含大量重复、噪声与无效内容。如散落在各处的博客、个人笔记、会议记录、临时 gist | 采集、解析 | 仅归档，不直接构造 |
| **P1** | 过滤知识（Filtered Knowledge） | 具有规范格式、可读性较强的知识，但语义质量参差不齐，可能包含过时或局部适用的内容。如团队 wiki、初步整理的规范文档、StackOverflow 回答 | 启发式过滤、去重、算子编排 | 大规模基础构造 |
| **P2** | 精筛方法（Selected Method） | 具有高方法价值，主题明确与逻辑连贯的方法。如经过评审的设计模式、内部最佳实践集、稳定的 API 设计指南 | 模型打分、方法标签、社区验证 | 核心模块构造 |
| **P3** | 可运行方法元（Runnable Method Element） | 结构化程度高、可直接驱动执行的方法资产。包含明确的输入/输出、前置/后置条件、执行步骤与验收标准，可被智能体直接消费。如 Loushang 的 **SKILL.md**、可执行的检查清单、自动化工作流模板 | 方法改写、方法合成、人工标注、执行验证 | 关键路径构造 |
| **P4** | 编排方法体系（Organized Methodology） | 经过统一编排与规范化校验的完整方法体系，形成可检索、可组合、可演进的知识图谱。多个 P3 方法元在 P4 层面被编排为领域特定的方法论，支撑跨阶段、跨角色的协同治理。如完整的软件工程方法论、领域驱动设计体系、可运行的组织级规范 | 方法编排、可信校验、版本治理、依赖管理 | 知识库与规范索引 |

**关键洞察：P3 是分水岭。** P0–P2 是"被动消费"的知识——人阅读、理解、再应用；P3 开始是"主动驱动"的资产——智能体可直接加载、执行、验证。P4 则是"体系化编排"——多个 P3 在更高层次上形成可治理的方法生态。

#### 2.2.3 P3：可运行方法元——从"被动知识"到"主动资产"

P3 是整个分级体系中最关键的**分水岭级别**。在 P3 之前（P0–P2），方法本质上仍是"被动消费"的知识——需要人阅读、理解、内化后再应用。从 P3 开始，方法转变为"主动驱动"的资产——可被智能体直接加载、解析、执行与验证。

**P3 方法元的核心特征**：

| 特征 | 说明 | 示例 |
|------|------|------|
| **结构化输入/输出** | 明确定义方法需要什么、产出什么 | `input: ["需求文档", "约束条件"]` / `output: ["架构图", "接口定义"]` |
| **前置/后置条件** | 定义方法执行的前提与完成标准 | `preconditions: ["价值主张已明确"]` / `postconditions: ["整体结构已定义"]` |
| **可执行步骤** | 包含具体的执行指令，可被智能体按序执行 | `steps: [{"step": "识别系统边界", "duration": "5-10m"}]` |
| **角色绑定** | 明确由哪个元角色执行 | `meta-role: DESIGNER` / `role: DESIGNER.architect` |
| **适用性声明** | 声明方法在什么场景下适用、不适用 | `applicability.when: ["需要设计新系统"]` |
| **验收标准** | 定义方法执行成功的可验证条件 | `exit-criteria.must-have: ["结构设计已完成"]` |

**P3 方法元的典型形态——SKILL.md**：

```yaml
# methods/software/task/architect/SKILL.md
type: task
meta-role: DESIGNER
name: 架构设计

input:
  - "需求文档"
  - "约束条件"
output:
  - "架构图"
  - "接口定义"

preconditions:
  - "可行方案已确定"
  - "关键约束已识别"

steps:
  - step: "理解需求"
    description: "分析功能和非功能需求"
  - step: "识别组件"
    description: "识别系统核心组件"
  - step: "定义交互"
    description: "定义组件间接口和交互"
  - step: "验证设计"
    description: "验证架构是否满足需求"

exit-criteria:
  must-have:
    - "结构设计已完成"
    - "关键接口已定义"
  nice-to-have:
    - "详细设计文档"
    - "风险应对策略"

temperature: 0.5
```

**P3 的价值**：

- **对智能体**：可直接解析执行，无需人工翻译
- **对团队**：可复用、可版本化、可审计
- **对组织**：可沉淀为可运行的知识资产，而非静态文档

#### 2.2.4 P4：编排方法体系——从"单点方法"到"系统方法论"

P4 是方法体系的最高级别，它不是单个方法元，而是**多个 P3 方法元在更高层次上的编排与治理**。P4 回答的问题是："如何组织多个方法元，使其协同工作，形成完整的方法论？"

**P4 的核心特征**：

| 特征 | 说明 |
|------|------|
| **方法编排** | 定义 P3 方法元之间的调用顺序、依赖关系与数据传递 |
| **阶段定义** | 将方法元组织为价值流阶段（如 PLAN → EXPLORE → DESIGN → BUILD → VERIFY） |
| **角色映射** | 定义每个阶段由哪个元角色执行，支持变体切换 |
| **治理规则** | 定义方法体系的准入标准、升级路径与废弃策略 |
| **版本管理** | 支持方法体系的版本化演进，保证向后兼容 |

**P4 的典型形态——领域方法论**：

```yaml
# methods/software/methodology/tdd/SKILL.md
type: methodology
name: 测试驱动开发方法论

phases:
  - phase: PLAN
    activities:
      - task: understand-requirements
        role: PLANNER
  - phase: DESIGN
    activities:
      - task: design-interface
        role: DESIGNER
      - task: write-test-first
        role: DESIGNER
  - phase: BUILD
    activities:
      - task: red-green-refactor
        role: DELIVER
  - phase: VERIFY
    activities:
      - task: run-tests
        role: VALIDATOR
      - task: code-review
        role: VALIDATOR

orchestration:
  type: sequential-with-feedback
  rollback-rules:
    - when: "测试失败"
      to: BUILD
    - when: "设计不可行"
      to: DESIGN
```

**P4 与 P3 的关系**：

```
P4 方法体系（如"TDD 方法论"）
  ├── 引用 P3: task/understand-requirements
  ├── 引用 P3: task/design-interface
  ├── 引用 P3: task/write-test-first
  ├── 引用 P3: task/red-green-refactor
  ├── 引用 P3: task/run-tests
  └── 引用 P3: task/code-review

P4 定义的是"如何编排"，P3 定义的是"具体做什么"。
```

#### 2.2.5 渐进式构造策略

通过构建 P0–P4 的精细化分级治理体系，方法治理实现了从"粗放式堆量"向"精细化赋能"的范式转型。该体系支撑了**渐进式构造策略**，使系统能够在不同演进阶段精准匹配质量递增的方法资源：

| 系统演进阶段 | 推荐方法级别 | 理由 |
|-------------|------------|------|
| **原型验证** | P1 + 少量 P2 | 快速试错，不需要严格编排 |
| **MVP 开发** | P2 + P3 | 核心模块用 P3 保证质量，周边用 P2 |
| **生产系统** | P3 + P4 | 关键路径用 P4 方法论，子任务用 P3 |
| **架构治理** | P4 | 需要完整的体系化方法支撑 |
| **知识库建设** | P2 → P3 → P4 | 逐步升级，形成可运行资产 |

**升级路径**：

```
P0 原始经验 →[解析+过滤]→ P1 过滤知识
  →[筛选+验证]→ P2 精筛方法
    →[结构化+契约化]→ P3 可运行方法元
      →[编排+治理]→ P4 编排方法体系
```

每一级升级都需要经过**先验评估**（是否符合本级标准）和**后验验证**（实际运行效果是否达标），形成完整的质量闭环。

### 2.3 人机方法动态协同演进

人机协同演化的核心价值体现在三个维度：

1. **打破静态治理瓶颈**：突破传统"一次性方法配置"的局限，解决系统构造后期方法边际收益递减的问题；
2. **构建动态反馈闭环**：利用系统构造过程中的实时反馈，驱动方法的动态选择、加权与生成；
3. **实现资源精准匹配**：确保方法供给与系统能力发展阶段相适应，最大化方法利用效率与系统能力密度。

#### 2.3.1 协同演化核心机制

人机协同演化通过捕捉系统在构造过程中的动态反馈，实时调整方法供给策略。当前主要通过以下三种机制实现闭环：

**（1）基于模型反馈的方法选择（Model-guided Method Selection）**

系统在构造过程中产生的梯度范数、损失值变化及不确定性评估，是判断方法价值的重要信号。通过分析这些信号，可以精准识别出对当前系统最具信息量或挑战性的方法。

**（2）动态方法采样与再加权（Dynamic Method Sampling and Reweighting）**

为适应系统能力的动态变化，静态的采样配比往往难以维持全阶段的最优性。动态重加权机制主张根据系统在不同子集上的学习收益，实时调整采样频率。

**（3）模型闭环的方法生成与增强（Model-in-the-loop Method Augmentation）**

在协同演化的高级阶段，模型不仅选择方法，更主动参与方法的创造，形成"模型生成—方法训练—系统升级"的正反馈闭环。

#### 2.3.2 "人-机-方法"协同演进

为突破现有局限，未来的方法评估与治理应进一步向"人机孪生"方向演进：

- **系统能力演化的实时监测与诊断**：建立细粒度的构造监控系统，动态追踪系统的学习曲线、遗忘率及在特定基准上的性能边界。
- **基于能力反馈的策略自适应调整**：实现从"静态策略"到"自适应策略"的转变，确保系统在从"通用学习"向"专家能力"进化的过程中，始终获得最适宜的方法"养分"。
- **自动化协同优化框架（Automated Co-optimization）**：设计类似工业控制系统的自动化闭环框架，将系统诊断、方法治理与构造调度有机整合。

---

## 3 其他挑战

### 3.1 基础设施挑战

在迈向"人机方法协同演进"的过程中，底层基础设施面临着从支撑"结构化分析"向支撑"智能内化"的范式转型。

- **异构方法空间的表征与吞吐挑战**：传统大数据处理框架主要针对结构化表格数据设计，难以高效兼容智能时代 PB 级的代码、文档、测试用例、设计图等高维非结构化方法。
- **"模型即算子"带来的异构计算调度挑战**：随着治理逻辑的精细化，方法管线已不再是简单的规则过滤，而是深度集成模型推理的复杂流程，要求基础设施具备 CPU 与 GPU 的深度混合调度能力。
- **工业级治理的可追溯性与可观测性**：面向智能系统的平台必须在工程层面实现全生命周期的可追溯性、可复现性与可观测性，建立"方法指纹"体系。

### 3.2 安全可信挑战

方法不仅是构造智能系统的底层燃料，更是承载知识产权、伦理安全与系统可信的敏感载体。

- **大规模异构方法的合规确权与确源挑战**：在大规模采集与治理过程中，方法源的合法性合规、版权归属以及跨境传输限制构成了首要挑战。
- **系统知识内化过程中隐私泄露与诱导风险的挑战**：系统在深度压缩和内化世界知识的过程中，极易由于构造方法中的敏感信息泄露而引发安全危机。
- **"人机方法协同"闭环中的内生安全与治理失控**：当模型作为算子深度参与方法筛选与生成时，治理流程引入了新的动态风险，模型自身的偏见或对齐漏洞可能在方法管线中被非线性放大。

---

## 4 总结

本文针对高质量自然方法趋于枯竭和系统能力提升边际效益递减的双重挑战，系统分析了当前软件构造体系中存在的科学评估体系缺失、治理模式粗放以及"人-机-方法"单向驱动逻辑滞后等瓶颈。我们认为，面向通用智能软件的方法科学治理正逐步迈入人机方法协同演进的新阶段。

在这一范式下，本文围绕**科学化方法评估、精细化方法分级治理以及人-机-方法协同演进**三个核心维度分别对现有工作进行了梳理，在此基础上总结我们认为的关键研究方向和解决措施。

**（1）科学化方法评估**：通过构建先验指标与后验验证相结合的动态映射机制，将单位方法带来的"能力增益"转化为可度量、可预测的价值指标，为系统化的精细方法治理与人机方法协同演进奠定理论基础。

**（2）精细化方法分级治理**：依托 P0–P4 精细化方法分级体系（P0 原始经验 → P1 过滤知识 → P2 精筛方法 → P3 可运行方法元 → P4 编排方法体系），强调依据系统不同演进阶段的特异性需求进行精准适配。其中 P3 可运行方法元是整个体系的分水岭——从"被动消费的知识"跃迁为"主动驱动的资产"；P4 编排方法体系则将多个 P3 方法元组织为可治理、可演进的方法论。在深度解耦治理挑战的同时，显著提升了单位方法的构造价值密度与资源利用效率。

**（3）人-机-方法协同演进**：打破了智能体仅作为被动消费者的局限，构建了"监测—反馈—优化"的闭环，使智能体反馈成为驱动方法筛选与生成的内生动力，实现了方法质量与系统能力的协同飞跃。

此外，本文还讨论了在大规模异构基础设施建设以及全生命周期方法安全与隐私保护方面面临的挑战。我们认为，未来通用智能软件的突破性增长将不再单纯依赖于参数规模的简单扩张，而更取决于能否构建一套系统化、规范化且具备自适应能力的方法科学治理理论体系。通过推动方法治理能力的提升，加速软件开发从被动的"知识学习"迈向主动的"知识协同"，为最终实现通用智能软件提供核心驱动力。

---

## 附录：Loushang 实践映射

本文的理论框架已在 **Loushang** 项目中得到系统性实践验证：

| 理论概念 | Loushang 实践 |
|---------|--------------|
| P0–P4 分级体系 | `loushang-methods` 的方法元分层 |
| P0 原始经验 | `spikes/` 中的探索性实验记录、`docs/` 中未整理的经验片段 |
| P1 过滤知识 | `docs/architecture/` 中初步整理的架构决策、设计文档 |
| P2 精筛方法 | 经过验证的 `component-interfaces/`、稳定的 `glossary` 与 `types` |
| P3 可运行方法元 | `methods/` 目录下的完整 **SKILL.md**——包含输入/输出、前置/后置条件、执行步骤与验收标准，可被 Agent 直接加载执行 |
| P4 编排方法体系 | `methods/` 中按领域组织的完整方法论（如 `software/task/tdd/SKILL.md` + `software/phase/DESIGN/SKILL.md` 的编排关系） |
| 5+1 元角色 | `PLANNER`/`EXPLORER`/`DESIGNER`/`DELIVER`/`VALIDATOR` + `CONDUCTOR` |
| 先验评估 | 方法元的 `applicability` 声明与适用性检查 |
| 后验验证 | `VERIFY` 阶段的方法论有效性评估与持续改进闭环 |
| 人机协同 | `loushang-agent` 的 Agent Loop 与 `loushang-ai` 的模型能力整合 |
| 状态外置 | `session` 不等于 context window，事件日志与 work product 持久化 |
| 能力治理 | `capability` 作为一等建模对象，独立于具体执行载体 |
| 结构性安全 | 权限授予默认最小化，高风险操作支持独立审批 |

Loushang 的架构分层（`ai` → `agent` → `channel` → `tui` → `methods` → `coding`）正是本文所倡导的"系统科学"在工程层面的具体落地——每一层都有明确的职责边界、稳定的接口契约与可验证的交付物。

---

*版本: Position Paper v1.0 | 2026-05-31*
