SCAFFOLD — 由人和人工智能助手共同完成的软件项目¶

SCAFFOLD 是一套已获批准的方法论，用于管理由人和人工智能助手共同构建的软件项目：一个人搭配一个助手、一个团队搭配多个助手，或者多个由人员与智能体组成的小组。它覆盖整个项目，从立项（无论是从零开始，还是从项目当前所处的阶段开始）直到交付与复盘：项目章程、已规划的工作、节奏、小组、写入区、批次与交接、分支、环境、部署和发布版本。

它回答一些实际问题：要构建什么、由谁决定；每项任务由谁完成；每条路径由谁修改；任务如何与其变更和发布版本关联；某项内容如何进入生产环境、如何回滚；以及从中学到了什么。

已接受版本：SCAFFOLD 0.2 — 2026-10-16。 接受决定列明 36 项要求：按引用保留 0.1 的 31 项，另加 R-033 至 R-037。R-017 在两个版本之外，仍待决定。 ASILO 0.1 和 MILPA 0.1 保留其文本与权威。

SCAFFOLD 0.2 不增加新原则。每项要求说明依据；新增卡片形式化影响、运行与基础设施、迁移、结构及远程连接。西班牙文为规范性文本，翻译供参考。

脚手架的类比¶

脚手架在施工期间托住建造者，施工完成后拆除。它标明从哪里上下、每个施工队负责哪一段，以及下一班的材料放在何处。建成的建筑并不依赖脚手架。

搭起脚手架之前，先有施工委托；如果建筑已经存在，还要对已建成部分进行现状盘点。在软件中，项目章程就是委托；现状盘点记录已有的内容；小组是由人和智能体组成的团队；写入区说明每个小组负责哪一段；交接说明为下一班留下材料；批次说明正在做哪项工作以及何时完成；交付到生产环境相当于竣工验收，由人来授权。依据 SCAFFOLD-R-011，这些内容都不会随被部署的系统一起发布。类比用于解释，并不能证明某项控制确实有效。

范围与边界¶

ASILO 界定数据、权限和影响。当助手作为可访问工具或数据的智能体行事时，须保留 ASILO-R-004 规定的身份与范围。SCAFFOLD 组织使用一个或多个人工智能助手的构建工作；每项控制保留其自身条件。使用人工智能但不构建软件，不属于 SCAFFOLD 的范围。
它不取代 ASILO-R-005 规定的对关键影响的人工审查，也不取代 MILPA-R-002 规定的事实与假设的区分；它是使用这些要求。
它不取代 Scrum、Kanban 或任务管理工具：它规定记录什么、由谁决定；节奏与工具由各团队自行选择（工作与节奏）。
它不承诺降低消耗、减少错误或杜绝冲突。它使事务有序且可见；任何关于节省或稳定性的说法都需要度量。

与其他方法的关系¶

方法	问题	SCAFFOLD 从中采用什么
MILPA	我们知道什么、从何而来、由谁负责？	项目清单、受限区域、带契约和版本的关联、事实与假设的区分。
ASILO	人工智能系统能做什么，如何验证？	每个智能体的范围、每项任务的上下文预算、数据与密钥、对关键影响的审查。
SCAFFOLD	如何与人和助手一起规划、构建并交付软件？	新增项目章程与现状盘点、已规划的工作与节奏、小组、写入区、交接、批次、分支、环境、发布版本、部署排除以及复合项目。

管理司法辖区相关变更¶

添加或更新本地化内容时，将其作为项目工作管理：范围、工作项、受影响的契约、验收标准、检查及集成。变更保留到已交付版本及相关回滚计划的可追溯性。这些是 R-006、R-010、R-021、R-023 和 R-025 的应用示例，保留各自条件；不为 SCAFFOLD 0.1 增加要求或原则。

共用司法辖区指南为三种方法保留一份矩阵和示例。交付区域性变更解释版本、测试和制品。验收工作不代替方法论上接受配置、法律审查或操作授权。

方法的组成部分¶

组成部分	是什么	可行的检查
项目章程	目标、范围、负责人、关键影响与成功标准，带有版本。	在第一个功能批次之前已存在，且其变更有记录在案的决定。
工作项	已规划的工作，带有标识符、验收标准、负责人和状态。	每个功能或修复批次都引用一个工作项，且未经人工验收不得视为完成。
小组	由人、智能体或二者混合组成的团队，设有人类负责人、区域和配置。	每个智能体都有范围、预算和监督者。
写入区	助手可修改的路径；按轮流规则共用的路径；任何助手都不得修改的受限路径。	超出区域的变更在确认前被标出。
交接说明	目标、引用、现行限制、结果、事实与假设、决定以及下一步行动；带有状态。	谁接手了它、接手后是否有变化、是否已过期、依赖于哪些其他说明。
工作批次	一项功能、一次修复、一次重构或一次调研，带有负责人、区域、助手、时间区间和结果。	批次不得先于其所依赖的批次关闭，也不得在仍有待办说明时关闭。
启动上下文	助手首先阅读的、现行有效的工件简短清单。	所引用的内容存在且现行有效。
分支与合并请求	每个批次一个短生命周期分支；引用该工作及其检查的合并请求。	主分支受到保护，且“工作—变更—发布版本”的可追溯性在两个方向上都有效。
环境与发布版本	已声明的环境；按指纹晋级的同一制品；带标签和说明的发布版本。	带授权与回滚计划的部署记录。
复合根目录	通过各仓库的清单和契约来协调多个仓库的目录。	在根目录下读取的是清单、契约、地图和说明而非代码，且已声明的继承不会被当作已生效的继承。

stateDiagram-v2
  accTitle: SCAFFOLD：交接说明与工作批次的状态
  accDescr: 两个状态机：交接说明从开放（abierta）开始，接收方接手后变为已接手（tomada），工作完成后变为已关闭（cerrada）；等待另一份说明时处于阻塞（bloqueada_por），那份说明关闭后回到开放；可从开放或已接手状态附原因取消（cancelada），被退回时也会取消。工作批次从开放（abierto）开始，最终变为已关闭（cerrado），即结果已写明且没有待办事项，或附原因变为已废弃（descartado）。
  direction LR
  state "交接说明" as nota {
    state "abierta（开放）" as abierta
    state "tomada（已接手）" as tomada
    state "bloqueada_por（阻塞）" as bloqueada_por
    state "cerrada（已关闭）" as cerrada
    state "cancelada（已取消）" as cancelada
    [*] --> abierta
    abierta --> tomada: 接收方接手
    abierta --> bloqueada_por: 等待另一份说明
    bloqueada_por --> abierta: 另一份已关闭
    tomada --> cerrada: 工作完成
    abierta --> cancelada: 附原因
    tomada --> cancelada: 附原因或被退回
  }
  state "工作批次" as lote {
    state "abierto（开放）" as abierto
    state "cerrado（已关闭）" as cerrado
    state "descartado（已废弃）" as descartado
    [*] --> abierto
    abierto --> cerrado: 结果已写明且无待办
    abierto --> descartado: 附原因
  }

SVG（可缩放矢量图形）图示：SCAFFOLD：交接说明与批次的状态 · 可编辑的 Mermaid 源文件。

在 SCAFFOLD 0.1 中，说明创建时为“打开”状态，只有接收方才能接手它。已接手的说明不得再编辑：如果目标变化，则带理由取消该说明并另开一份。接收方可以连同理由将其退回给发出者，两份说明保持互相关联。批次以“关闭”（写明结果）或“放弃”（写明理由）结束。关闭并不表示批准或接受其内容：它只记录工作已经结束。

一个简短的示例¶

一个虚构的团队与两个助手一起开发一个网店。第一个助手在 src/ 中写入；第二个在 tests/ 中写入。文件 README.md 为共用，策略文件夹为受限。团队开启一个功能类批次：“将订单导出为 CSV（逗号分隔值）”，负责人为 Ana。第一个助手完成代码，并向第二个助手留下一份交接说明，写明改动了什么以及未检查什么。第二个助手接手说明、编写测试并关闭说明，Ana 带着结果关闭该批次。如果第二个助手发现订单契约不接受新增字段，它本应退回该说明，而不是强行改动。

项目周期¶

时刻	决定什么	页面
启动	目标、范围、负责人；若已有工作，则进行现状盘点。	项目周期
规划	做哪些工作、按什么顺序、何时就绪、何时完成。	工作与节奏
组织	哪个小组做什么、具备什么产能。	小组
构建	区域、批次与交接。	本页与要求
合并与交付	分支、合并请求、环境、部署和发布版本。	分支、环境与发布版本
运营与学习	指标、事件与改进。	项目周期

模板以虚构示例展示各种格式。

分阶段应用¶

阶段	可审查的产出
编写项目章程或现状盘点	带版本的项目章程；若项目已存在，则有现状盘点。
记录工作	含工作项、完成定义和节奏的工作清单。
声明区域	区域文件，按路径列明归属，并列出共用和受限路径。
用说明传递工作	带状态并链接到批次的说明。
记录批次	每个工作单元一个批次，附结果和成本，或标注“未知”。
保持同步	契约、架构地图和代码，带有版本和检查。
整理分支与交付	分支模型、已声明的环境、部署记录和发布版本。
分离被部署的内容	针对已构建制品检查过的排除清单。
协调多个仓库	根目录的声明及按清单读取。

这些阶段不是成熟度等级，也不是必须遵循的顺序。每个团队只采用自己需要的部分（分部分采用）。

接下来阅读：项目周期、0.1 版本的要求和词汇表。

一个人搭配一个助手同样适用 SCAFFOLD¶

一个人委托人工智能助手修复一个函数。他声明允许的路径，开启一个修复批次，为该任务准备上下文，并在合并之前记录结果和检查。他兼任所有角色：章程一段话就够，工作清单一个文件就够。他无需创建其他智能体就能应用该方法。在批次内更换助手时，必须有交接说明；当出现负责人之间的协调以及批次之间的依赖时，相应的要求才适用。

ASILO 按其要求界定数据、权限和影响；MILPA 保留来源与权威。SCAFFOLD 组织构建的方式。请参阅人工智能范围。

工程与制品证据¶

工程配置提案与制品验证指南：技术中立的应用、标准、证据及限制；不增加普遍要求。