将这些方法应用到你的第一个项目¶

0.1 首批版本的现行应用指南。已被接受的要求保留其各自的条件。本指南解释已被接受的要求；它不接受任何配置，也不增加任何义务。

从一个小任务开始：审查项目的某一部分并提出改进建议。你可以使用编程助手、本地模型或通过 API（应用程序编程接口）调用的服务。这些方法不要求使用特定的 SDK（软件开发工具包）、框架或供应商。

MILPA 帮助你定位规则、来源和决策。ASILO 帮助你界定助手接收哪些数据、可以执行哪些操作。要评估某个项目是否适用 0.1 版本，请查阅全部要求；本流程只是进入方法的入口，并不声明已完整覆盖。

1. 在请求工作之前先说明项目¶

准备一份卡片，写明项目的身份、负责人、目的、范围和受限区域。声明你所使用的配置及其状态。如果它还只是提案，就如实说明：本站的配置各自单独声明其批准状态。

例如，对于一个图书馆目录：“我们想在测试库存中检测重复记录。由负责人审查方案。用户数据、生产数据库以及任何删除操作都不在范围内。”

清单字段请参见 MILPA-R-004；核心的七项功能请参见 MILPA-R-006：清单、面向读者的入口、来源与关联、智能体运行时的指令、索引、决策，以及单独存放的临时材料。具体的名称和目录属于配置。

如果操作依赖某个司法辖区，先参照应用司法辖区配置准备上下文。选择语言或托管国家本身不能确定适用规则。

项目的入口应当让人无需遍历整棵目录树，就能找到索引、适用的规则和决策。记录方法的版本以及你所使用来源的修订版本；已发布的页面或 canon 标签不能取代这种标识。

可以用一段简短的指令向任何助手指明这些路径。完整文本放在一个归属明确的位置；各工具的入口链接到它。把全部规则复制到多个文件中，会产生可能相互分歧的版本。

请参见 MILPA-R-001 和 MILPA-R-007。共享同一个目录或读取同一段文本，既不会自动连通两个系统，也不能证明二者兼容。

在把任务交给模型之前，确定它的目标、所需的来源、被排除的路径、数据的分类、上下文的最大规模及其有效期。同时声明由谁执行、允许哪些操作，以及动作和委派的限制。

在图书馆的例子中，第一个任务可以读取一份合成库存，并返回一份可能重复记录的清单，同时附上指向原始记录的引用。它不需要访问账户、凭据或其他项目。书面写出的预算需要事后核对：工具实际收到了什么。

参考依据见 ASILO-R-003、ASILO-R-004 和 ASILO-R-006。指令用于引导模型；实际生效的权限和限制取决于工具与系统中可验证的控制措施。

上下文与交接指南有助于准备这份预算。

要求每项发现都区分有引用的事实、推断和假设。对照来源审查结果：另一个智能体表示同意，并不能证明其真实性或独立性。

如果方案要进入执行某个动作的阶段，请确定所需的契约和授权。一份重复记录清单可能格式完好，却仍包含不应被删除的记录。对于关键影响，获得授权的人员在确认之前要审查具体对象。最小目录及其条件见 ASILO-R-005。

另请参见 MILPA-R-002、ASILO-R-001 和 ASILO-R-008。控制措施要针对具体的故障进行测试；它们不会因为多数一致就把一个结果变成事实。

打开架构与安全以区分各项控制措施，打开评估与审查以核对适用的故障。

保存决策、已审查的来源、已做的测试以及仍待处理的事项。出现矛盾时，要保留两个来源，直到负责人决定如何解决（MILPA-R-008）。

如果更换助手或供应商，请准备一份交接说明，包含目标、文档与工件的修订版本、当前有效的限制、结果以及下一步待办。这是一种建议的工作技巧：它不会同步各工具的私有记忆，也不会自动授权新的接收方接收这些数据。继续之前，请审查其访问权限和处理条件。关于预算、停止和状态保存，请参见 ASILO-R-007。

使用工件卡片来准备记录，或将你的任务与用例进行比较。先确定限制和你所需的证据，再选择工具，而不是把选工具当作学习这套方法的前提。

仅凭一份 MD 文件或一次站点构建，并不能证明已经应用了这些方法。证据要针对要求、版本和被评估的项目来记录。软件的安装与使用不属于本流程（参见门户的职责）。