【AI翻译】AI-Native 操作系统 (1/3): 原则 - Maxime.ly

本文由AI翻译

来源网址: https://maxime.ly/articles/ai-native-product-os-principles/

Markdown 内容:

想象一下：AI 代理坐在你的组织结构图中，不是作为助手，而是作为实际的开发者。听起来很疯狂？这正是我们在 MadKudu 所做的。以下是我通过艰难的方式学到的 11 条原则，这些原则使我们的生产力提高了 20 倍。

---

让我给你一个真相炸弹：你的 AI 编码助手没有发挥其潜力，因为你把它当作初级开发者而不是系统架构师。

经过数月的反复试验（重点是错误），我发现要让 AI 真正高效，需要彻底重新思考我们如何构建代码、文档和开发实践。不只是调整它们——而是完全重新想象它们。

"AI-Native" 实际上是什么意思？

当我终于明白这一点时，令我震惊的是：在一个 AI-Native 公司中，代理不是协助开发者——他们就是开发者。他们在组织结构图中有自己的位置。他们拥有功能。他们修复错误。他们部署到生产环境。

而关键是：所有能用 AI 完成的事情，必须用 AI 完成。

这意味着如果你当前的流程与 AI 代理完成工作不兼容，猜猜需要改变什么？（提示：不是 AI。）

让我带你了解在 MadKudu 使这一切成为可能的 11 条原则。

单一代码库为王

还记得当每个人都痴迷于微服务并将一切拆分成小型代码库的时候吗？是的，事实证明那是 AI 的克星。

我们花了数月——数月！——试图构建让 AI 能够导航多个代码库的工具。自定义索引、混合搜索、花哨的跨代码库搜索、复杂的上下文管理……没有一个奏效。AI 会不断丢失上下文，对其他代码库中的代码做出假设，或者更糟糕的是，幻想出不存在的应用程序之间的整个数据流。

解决方案痛苦地简单：把一切放在一个代码库中。

我的意思是所有东西：

• 应用程序代码
• 基础设施即代码
• CI/CD 管道
• 文档
• 数据模型
• 数据转换
• 营销网站
• Bob 三年前写的那个随机脚本

基本上，你应该有一个名为 MadKudu 的代码库（可以根据你的公司更改名称；）。

当你的 AI 能够在一个地方看到整个系统时，魔法就发生了。它理解关系，捕捉边缘情况，最重要的是——它实际上可以在没有你监督的情况下完成整个功能。

抵制炒作列车

作为一个技术爱好者，这一点让我很痛苦。你知道上周发布的那个闪亮的新 JavaScript 框架吗？那个有着酷炫标志和承诺 10 倍生产力的框架？

不要使用它。

这是我通过昂贵的方式学到的：AI 只能像它所能访问的训练数据一样好。猜猜什么有最多的训练数据？无聊、成熟、广泛使用的工具。

当我们开始消除自定义工具和闪亮框架，转而使用普通的、无聊的 React + Node + PostgreSQL 时，我们的 AI 成功率飙升。为什么？因为这些工具有：

• 数以千计的 Stack Overflow 答案
• 数百个 GitHub 示例
• 广泛的文档
• 多年最佳实践融入 AI 的训练中

它不性感，但它有效。把前沿技术留给你的副项目。

类型是不可协商的

在看 AI 尝试调试无类型代码后，我可以自信地说，静态类型对于 AI-Native 开发至关重要——除非你喜欢在凌晨 3 点看你的 AI 代理陷入存在危机。

原因如下：AI 代理的工作方式与初级开发者完全一样——他们编写代码，编译，修复错误，重复。错误信息越精确，他们改进得越快。

我们的技术栈现在包括：

• 到处都是 TypeScript（是的，即使是脚本）
• tRPC 用于类型安全的 API
• Drizzle 或 Prisma 用于类型化的数据库查询

通过适当的类型化，我们的 AI 在运行时之前捕获了 90% 的错误。没有它？请不要触发我。

高测试覆盖率

传统智慧认为高测试覆盖率可以防止回归。在 AI-Native 开发中，测试做了一件更关键的事情：它们创建了一个反馈循环，使你的 AI 成倍提高。

想想看——当你编写代码时，你运行测试以查看它是否有效。AI 也做同样的事情，只是它可以在你重构一个函数的时间内运行数百次迭代。

我们的测试策略：

• 每个服务的单元测试（目标是 80%+ 覆盖率）
• 每个用户流程的 E2E 测试
• 在编码开始之前在设计文档中指定的测试

最后一点至关重要。当你给 AI 一个带有明确测试用例的设计文档时，就像给厨师一个带有成品照片的食谱。它确切地知道成功是什么样的。

但真正的关键是：E2E 测试是你对抗 AI 倾向于“前进两步，后退一步”的保险政策。它们确保你的新功能不会破坏三个现有功能。

紧密监控

测试在部署前捕获错误。监控在部署后捕获它们。在 AI-Native 世界中，监控成为你的安全网。

我们使用三层：

1. 详细日志记录：每个重要操作，每个决策点
2. 业务分析：不仅仅是错误，还有实际的用户行为
3. 保障和不变量：应该始终为真的假设

最后一个是金子。我们要求我们的 AI 在代码中添加对基本假设的检查。当这些失败时，我们知道我们遇到了 AI 没有考虑到的边缘情况。将其反馈到你的设计文档中，你的 AI 会变得更聪明。

架构审查

这是一个艰难的事实：AI 还不能设计出好的架构。

我知道，我知道。我们都想相信 AI 可以做一切。但要求当前的 AI 构建一个可扩展的系统就像要求一个小孩设计摩天大楼。他们可能会堆积一些积木，但你不会想住在里面。

在 MadKudu，我们定期进行架构审查。不是代码审查——是架构审查。我们检查：

• 域分离是否干净？
• 抽象是否在正确的层次？
• 当我们将流量增加 10 倍时，这是否会扩展？

当架构稳固时，AI 表现出色。当它不稳固时？即使是简单的功能也会变成不可能的难题。在每次会议后，我们都会抓住机会更新我们的编码指南和架构文档。

保持代码简洁

这听起来可能违反直觉，但代码越少，你的 AI 表现越好。

AI 模型有上下文窗口。用臃肿的代码填满它们，它们就会错过重要的东西。保持代码精简，它们就能看到所有重要的东西。

我们采用了一些规则：

• 不要解释“是什么”的注释（代码应该是自解释的）
• 代码库中没有生成的文档
• 积极重构以消除重复
• 如果没有使用，删除它

额外奖励：更少的代码 = 更少的令牌 = 更低的 AI 成本。你的 CFO 会感谢你。

文档是金子

好吧，这就是事情变得刺激的地方。准备好一个激进的想法了吗？

工程师不应该再写代码。他们应该写文档。

我不是在开玩笑。我们的新工作流程：

1. 工程师编写详细的设计文档
2. 工程师指定测试用例
3. AI 编写代码
4. 工程师审查和完善规范
5. 重复直到完美

结果？令人震惊。我们的开发人员现在发布了更多的功能，因为他们专注于构建什么，而不是如何构建。AI 处理实现细节。

专业提示：你的公共文档成为你的 SEO 金矿。文档良好的功能排名更高，因为它们实际上解释了它们的作用。谁会想到呢？哦，顺便说一句，传统的 SEO 已经死了，但我们在另一篇文章中讨论这个。

预览环境

每个分支——生产、功能或本地——都需要自己的环境。而且它需要快速启动。

为什么？因为当 AI 在编写代码时，你需要立即看到结果。等待 20 分钟进行构建会破坏反馈循环。

我们的设置：

• 每个分支的临时环境
• 使用 Neon 或 Supabase 的分支功能的完整环境（数据 + 代码）。
• 启动时间少于 10 秒
• 完成后自动拆除

一切都在云中发生，立即可访问，完全隔离。

紧密的设计系统

这最初会让开发人员感到沮丧，但对于 AI 成功来说绝对至关重要。

创建一个设计系统——一组固定的组件——AI 只能使用这些组件。没有其他。每个间距、颜色、边框半径都必须集中定义并在各处重用。

为什么这如此重要？因为没有它，你的 AI 会为每个功能创建不同的按钮样式。你的应用程序看起来像是由一群从未见过面的人设计的。

但有了紧密的设计系统？一致性自动发生。此外，较少的自定义 CSS 意味着更少的代码，这意味着更好的 AI 性能。双赢。

严格的编码指南和功能模板

每次 PR 审查都应该触发对你的编码指南的重新评估。AI 做了什么奇怪的事情吗？添加一条规则。它错过了最佳实践吗？记录下来。

但这里有一个真正的秘密武器：严格的功能描述模板。

我们开发了一个模板，迫使开发人员思考：

• 用户故事
• 成功标准
• 测试用例
• 边缘情况
• 性能要求

当你正确填写这个模板时，AI 在第一次尝试时就能 90% 地实现。

底线

这 11 条原则改变了我们在 MadKudu 构建软件的方式。我们的开发人员现在专注于构建什么，而不是如何构建。我们的 AI 代理处理实现，它们比任何人类都更快、更一致地完成。

它完美吗？不。但它比我们旧的工作方式高效 10 倍。

这是我对你的挑战：选择这些原则中的一个并尝试一周。就一个。我保证它会改变你对 AI 辅助开发的看法。

哪个原则与你最有共鸣？你准备好让 AI 代理成为你团队中的实际开发者了吗？还是开发人员只写文档的想法让你想要愤然离职？

开发的未来不是 AI 帮助人类编写代码。而是人类帮助 AI 理解要构建什么。