简介：好的异星工厂 Mod 尊重工厂
Factorio modding 通常从一个实用的想法开始：添加一个项目、调整一个配方、引入一个实体、创建一条提高生活质量的捷径或构建一个新的生产机制。困难的部分是使该更改适合已经包含数千个实体、特定游戏版本、其他模组，有时还包含多人服务器的工厂。
一个可靠的模组需要的不仅仅是一个有用的概念。它需要正确的元数据、可解析的原型、明确的数据阶段或运行时责任、受控的 Lua 逻辑、迁移和保存注意事项、性能意识以及类似于真实工厂的测试。 AI可以加速规划和审查；它不能证明生成的原型或事件处理程序是正确的。本指南涵盖了合法的 Factorio modding 并展示了 EasyClaw 在哪些方面可以帮助本地项目围绕实施和测试开展工作。
什么是异星工厂模组？
Factorio modding 是使用异星工厂支持的 mod 结构、数据阶段原型定义、Lua 运行时脚本、设置、资产和批准的 mod 分发工作流程合法创建自定义内容和游戏更改。 Mod 可以添加配方、物品、技术、实体、UI 功能、场景和自动化系统，具体取决于当前的游戏版本和 modding API。
它不是关于在服务器上作弊、绕过平台规则、修改可执行文件、提取未经授权的内容或在未经同意的情况下对多人游戏玩家强制安装模组。负责任的模组会识别其游戏版本、依赖项、兼容性限制、设置、迁移和多人游戏期望。
| 层 | 目的 | 常见风险 |
|---|---|---|
| Metadata | Mod identity, version, dependencies | Wrong version or missing dependency |
| Data stage | Define or modify prototypes | Bad prototype reference or late-stage conflict |
| Control stage | Runtime Lua behavior and events | Expensive event handler or invalid state |
| Settings | Player or map configuration | Undocumented behavior changes |
| Testing | Load, factory, save, and multiplayer checks | Testing only a fresh, empty map |
💡 Key idea: 当异星工厂 mod 在工厂和 mod 列表中表现出可预测的行为时，它就已经准备好了，而不仅仅是在加载一次时。
Factorio Modding Basics：原型、Data 阶段、控制脚本和事件
Prototypes describe game content
物品、配方、实体、技术和许多其他游戏对象都由原型表示。从可以实现预期玩家效果的最小数据驱动更改开始。使用当前的原型参考并检查现有的兼容定义，而不是复制过时的示例。
Data stages define content before the game runs
Data 阶段脚本创建或调整原型。舞台很重要，因为其他模组可以添加或更改相同的内容。说明您的 mod 期望存在什么、它会更改什么以及在可选依赖项不可用时它应该如何表现。
Control scripts manage runtime behavior
运行时 Lua 逻辑对支持的游戏事件和持久 mod 状态做出反应。保持处理程序的范围狭窄，避免频繁事件中不必要的工作，并定义如何创建、更新、迁移和重置状态。在大工厂里，性能就是游戏质量。
Settings 和迁移是面向玩家的合约
如果某个设置改变了行为，请对其进行解释。如果更新更改了存储状态，请规划并测试其迁移路径。永远不要假设每个玩家在更新后都会开始一张新地图。
如何在编写 Lua 之前规划异星工厂 Mod
从玩家承诺开始：“这个模组增加了一项可配置的后勤改进，而无需更改不相关的配方。”然后定义目标游戏版本、必需和可选的依赖项、受影响的原型、运行时行为、设置、性能约束、多人期望、保存行为和验收测试。
在编辑文件之前使用小型实施合同：
GOAL: add one bounded feature for the supported Factorio version
INPUTS: target prototypes, settings, dependencies, test-save requirements
CHANGE: add only required data definitions and scoped runtime logic
DO NOT: overwrite unrelated prototypes or test on the only factory save
VERIFY: prototypes resolve, mod loads, event behavior is correct, log is reviewed,
clean test and documented compatibility test pass
OUTPUT: change summary, test evidence, performance questions, known limits这是一个规划工具，而不是可粘贴的 Lua。当前的 API 和阶段行为必须在您支持的游戏版本和工具链中进行验证。
Factorio Modding Debugging：日志、状态和受控 Mod 列表
当一个mod失败时，首先隔离类别。元数据有效吗？数据阶段原型参考失败了吗？运行时事件处理程序是否抛出异常？加载较旧的保存后持久状态是否丢失？该问题是否仅在另一个模组、特定设置或大型工厂中出现？阅读最早的有意义的日志消息并重新创建仍然显示问题的最小设置。
单独测试你的 mod，然后使用声明的依赖项，然后使用你支持的 mod 组合。将复制的保存用于迁移敏感的工作。记录异星工厂版本、模组版本、加载顺序、设置、地图状态、预期行为、实际行为以及相关日志输出。对于运行时逻辑，包括性能观察，而不是假设某个功能是安全的，因为它在小型测试环境中工作。
Using AI 用于异星工厂改装而不会失去控制
AI 可以将功能请求转化为原型和事件计划、解释 Lua 模块、识别迁移和性能问题、组织日志证据并起草兼容性矩阵。它对于在影响大量保存之前使隐式假设可见特别有用。
AI 对于当前原型字段、Lua API、事件行为或特定于版本的更改也可能是错误的。要求它陈述假设，将其建议与当前异星工厂文档进行比较，并在受控世界中测试每个结果。生成的代码是草稿，而不是性能或多人安全性的证明。
| 任务 | 有用的人工智能贡献 | 创作者责任 |
|---|---|---|
| Feature plan | Clarify content, state, settings, and tests | Choose maintainable scope |
| Data 评论 | Map prototypes and dependency questions | Verify current stage behavior |
| Lua 评论 | Explain flow and potential state 问题 | 测试事件和性能 |
| Conflict triage | Organize likely causes | Reproduce with actual mod lists |
| Release notes | Summarize changes and known limits | Publish only tested claims |
EasyClaw 如何帮助异星工厂改装工作
当异星工厂功能分布在元数据、数据阶段文件、运行时 Lua、设置、更改日志注释、日志和测试保存指令时，EasyClaw 非常有用。作为桌面本机代理，它可以围绕这些本地材料执行批准的工作：检查选定的文件夹、库存原型和脚本，收集最新的日志证据，创建预检报告，并在返回报告之前验证所请求的测试文档是否存在。
从本地文件构建原型、运行时和测试图
向 EasyClaw 发出有界请求：“阅读本简介和选定的 mod 文件夹。识别元数据、原型定义、运行时模块、设置、依赖项、迁移风险和测试。不要编辑源代码。”使用本地文件和文档技能，它可以根据您的项目创建可审阅的地图，而不是通用教程。您可以在实施之前审查文件、找到假设并解决需要解决的问题。
Prepare a safe preflight 用于真实工厂测试
在启动游戏之前，请 EasyClaw 比较所选的项目文件、版本说明、声明的依赖项、最新日志摘录和测试清单。它可以准备一份注明日期的报告，标记丢失的输入，并提醒您使用干净的世界或复制的保存。这种本地证据收集工作是特工节省时间的地方，而不是声称它可以验证 mod 本身。
Turn test evidence into the next smallest change
测试完成后，给EasyClaw日志摘录、截图、mod列表、设置、复现步骤。它可以区分已确认的缺陷、可能的冲突、迁移问题、性能观察和推迟的想法。结果是有针对性的修订计划和更新的测试记录，而不是盲目的多文件重写。
保持源代码、保存和发布均处于批准状态
明确说明允许的操作：读取文件、创建带日期的备份、更新报告或起草发行说明。还要说明需要确认的内容：覆盖源、删除保存、更改模组设置、发布或触摸游戏文件。然后，EasyClaw 充当安全项目工作的执行层，同时您保留对代码、游戏内测试和发布的控制。
💡 EasyClaw’s role: 使项目检查、预检、证据收集和测试文档可重复。它不会取代异星工厂 mod 工具，也不会在没有受控测试的情况下证明运行时性能和兼容性。
Example：异星工厂功能从简介到工厂测试
想象一下，一位创建者添加了一项可配置的物流功能。他们要求 EasyClaw 读取简要和选定的项目文件，然后生成原型、设置、运行时状态、依赖项和测试条件的映射。在创建者编辑任何内容之前，代理会标记未解答的迁移和性能问题。
计划批准后，EasyClaw 创建允许的日期备份和测试报告模板。创建者进行最小的支持数据或 Lua 更改，运行一个干净的世界，然后测试复制的已建立工厂（如果该功能声称保存兼容性）。创建者分享日志和观察结果； EasyClaw 将它们分为通过的检查、缺陷、冲突和最小的下一步操作。
| 阶段 | 创作者行动 | EasyClaw 工作 | 确认 |
|---|---|---|---|
| Define | Set player value and constraints | Creates a feature brief | Is scope bounded? |
| Inspect | Select project files | Maps prototypes, code, and dependencies | Are assumptions visible? |
| Preflight | Approve local actions | Creates backup and test report | Are safe inputs ready? |
| 测试 | Run controlled factory tests | Organizes logs and evidence | Does behavior and performance match claims? |
| Iterate | Approve the next revision | Creates a focused follow-up report | Is change evidence-based? |
Factorio Modding Checklist Before Sharing
- 该模组有针对性的玩家目的和目标异星工厂版本。
- Metadata、依赖项、可选集成和设置均已记录。
- 原型更改仅限于受支持版本的范围和当前版本。
- 运行时 Lua 有意定义状态、事件处理和迁移行为。
- 在进行后续的多文件工作之前，您有一个过时的备份。
- 该模组在干净的测试环境中运行并声明了兼容性设置。
- 保存和迁移声明仅在副本上进行测试。
- 性能和多人游戏声明基于受控证据。
- Release notes 解释更改、设置、依赖性和已知限制。
常问问题
结论：更好的异星工厂改装来自可测量的迭代
当每个原型、运行时处理程序、设置和依赖项都有明确的存在理由和受控的测试路径时，Factorio modding 效果最佳。 Lua和数据阶段是工具；持久的规则是管理状态、性能、日志、保存以及围绕它们的兼容性。
EasyClaw 可以执行已批准的桌面任务，连接 mod 文件、预检报告、测试证据和发行说明。它不会取代官方模组工作流程或将未经测试的处理程序转变为安全模组。它为创建者提供了一种实用的方法，可以在工厂依赖每个修订之前检查、测试和记录每个修订。