01 人性化方向
知道原因、方向和界限。
一种负责任的人类视角定义了作品为什么应该存在、它必须为谁服务、什么不能妥协以及结果是否仍然符合初衷。人类无需预先设计每个解决方案即可纠正漂移。
- 目的和预期效果
- 持久的原则和界限
- 优先事项和相应的选择
- 最终接受或重定向
人工智能可以从中推理出一个方向，而无需简化为任务执行。
一个人的方向。
多重责任。
Flaey 通过赋予人工智能真正的工程责任并保持验证、交付和学习明确，将明确的人类目的转化为工作软件。
一种方法，而不是一种规定的设置。
本地项目和组织规模的系统不需要相同的工具、控制或基础设施。他们确实需要同样清晰地了解谁拥有方向、谁设计和建造、结果如何受到挑战、结果如何实现使用以及经验如何改变接下来发生的事情。
保持责任稳定。扩大保障措施规模。
当软件变得更大或更重要时，Flaey不会成为不同的方法。责任模型保持不变。当可能的伤害、敏感性或不可逆转性增加时，孤立、独立、证据、批准和恢复就会变得更强。
组织规模不是风险模型。后果是。
一个人的方向。 多重责任。
02 人工智能工程
负责完整的路线。
人工智能检查当前的现实，解释方向并拥有贯穿产品、架构、用户体验、数据、实施和运营结果的连贯路径。它产生一个完整的结果，而不是支离破碎的片段或需要其他人完成的建议。
- 现实和背景检查
- 产品、架构和用户体验设计
- 实施与修正
- 验证和操作设计
围绕预期结果形成的连贯的、可测试的候选软件。
03 验证
挑战足够独立构建的风险。
生成的代码和绿色自动化本身并不能证明。验证根据目的、原则、当前现实、失败行为和用户结果对候选人进行测试。软件越重要，独立性和证据就应该越强。
- 技术和功能检查
- 对假设和遗漏的严格审查
- 针对特定风险的故障测试
- 哪些内容已通过、哪些内容未通过的证据
拒绝、修改或晋升候选人的合理决定。
04 发货
将准确接受的结果投入实际使用。
交付使开发结果可见，将预览与正式验收分开，仅发布实际批准的内容。它确认正在运行的内容并保持相应的恢复路径。
- 可见的开发或预览结果
- 受控推广和发布
- 确认活动结果
- 回滚、恢复或补偿
可追溯到被接受的候选人的工作软件。
05 学习
让真正的交付改善下一个。
使用实际行为、失败和纠正来改进产品及其开发方式。大多数体验仍然是本地的。只有有证据支持的可重复使用的经验教训才应成为持久的原则、保障措施或公众知识。
- 产后观察
- 将事件与结构教训分开
- 基于证据的改进
- 删除过时的规则和流程
一个更好的下一个开发周期，而无需积累官僚主义。
这些轨道围绕一个结果协同工作。
该方法是递归的，而不是严格的工具序列。拒绝将结果归还给必须改进它的责任。
- 方向 人类定义目的、界限和预期效果。
- 理解 人工智能检查当前的产品和实施现实。
- 工程 人工智能设计并构建完整的结果。
- 挑战 验证试图反驳完整性和安全性。
- 使用 交付促进了已接受的结果并确认正在运行的内容。
- 学习 当证据证明其合理性时，观察到的现实可以改进产品或方法。
从本地工具到相应的软件。
Flaey 不需要每个项目都有企业机械，并且不允许简单的设置隐藏严重的风险。根据结果、敏感性、可逆性和操作依赖性来选择控制。
保持直接。
一个人和一个有能力的人工智能环境可能涵盖多个轨道。当后果有限时，预览、集中测试、单独审查和可恢复的发布可能就足够了。
强化界限。
当故障影响许多人、受监管的数据或关键操作时，相同的轨道可以使用单独的身份、环境、策略、正式证据、独立接受和更强的恢复。
添加保证是因为结果需要它，而不是因为传统流程需要它。
责任比工具更长久。
该方法可以在本地运行，或者通过Cloudflare、AWS、Azure、Google Cloud或其他合适的环境运行。人工智能模型、存储库和交付工具也可能发生变化。当替代者能够履行相同的职责而不削弱所需的边界时，它就是合适的。
如果明天每个现有供应商都发生变化，该方法仍然有意义吗？
方法来源于实践。
Pagayo 是应用和扩展此责任模型的地方。其当前的开发实践和Pagayo Development Cloud展示了一种日益完善的实现。它们是证据和学习来源，而不是必需的堆栈。
看看Pagayo如何应用该方法从责任开始，而不是基础设施。
首先明确人类指导、人工智能工程、验证、交付和学习。然后仅选择实际软件所需的工具和保护措施。