好的约束塑造了软件最好的时代，也塑造了我自己的职业生涯。一些有主见的方法，比如 12-Factor 应用原则或 MVC，为我们提供了构建可靠服务和设计关注点分离的共同语言。这些都是简单的规则，易于陈述，但难以完美遵循。它们催生了整个行业：SaaS、PaaS、云基础设施。这一切都建立在深思熟虑的约束之上，这些约束告诉构建者：这是边界，请在此范围内活动，好事自然会随之而来。我个人在最好的工作中都受益于应用这些约束。
我相信，AI 原生软件也需要自己的约束。以下是我提出的一个。
你的代码库有一个最大尺寸。这不是一个品味问题。这个限制是真实的、可衡量的，而且比你想象的要小。
这个限制：你用来构建和维护产品的 AI 模型上下文窗口的一半。这意味着，你的核心业务逻辑和系统上下文的大小，不应超过你所依赖的 LLM 上下文窗口的一半。
为什么是一半？上下文窗口服务于两个目的。前半部分容纳你的代码。后半部分留给 Agent 进行推理、规划和生成。如果用代码填满整个窗口，就没有留出思考的空间。一半用于理解。一半用于认知。
软件业务中最难的部分从来不是构建功能。
每个有经验的技术创始人 都知道这一点。难的是为足够大的客户群体识别出最小有用的软件，然后团结人们围绕客户获取、客户服务和客户保留这些艰巨的工作。
构建软件曾经很昂贵。工程师的成本很高。这产生了摩擦，催生了迭代开发流程，但也带来了纪律。你必须做出选择：客户最需要什么？什么是最小的值得构建的东西？工程的人力成本让团队保持专注。约束创造了清晰。硅谷最好的公司就是这样成长起来的。
现在，AI Agent 几乎可以构建你要求的任何东西。瓶颈已经消失。纪律也随之消失。
免费的生产导致过度生产。过度生产是 AI 原生公司的默认失败模式。
非技术背景的创始人和投资者需要理解这一点。更多的功能、更多的代码、更多的产品表面积需要维护，不再是进步的标志。它们表明一家公司缺乏高质量的约束，有时，还表明根本性的缺乏清晰度。
没有可扩展的分发和消费的过度生产，会在价值捕获中造成巨大的泄漏。你发布了十个功能。两个驱动了留存。另外八个增加了复杂性，拖慢了那两个重要的功能。每一行代码都变成了伪装成资产的负债。
有经验的构建者知道临界点。代码从服务客户转向服务自身。复杂性成为产品的敌人。团队花费更多时间管理软件，而不是改善客户体验。系统开始感觉笨重，用户开始流失，你的面向客户的团队默默地感到沮丧。
在旧世界里，你花费数年才达到那个临界点。在 AI 原生世界里，你几周内就会达到临界点。Agent 永远不会感到疲倦，永远不会反对，也永远不会说：“这太复杂了，我们应该停下来。”
你怎么知道什么时候该停止？当 AI 可以免费编写无限代码时，什么信号告诉你“够了”？
那就是半窗口规则。
你的核心业务逻辑必须能容纳在维护你代码库的模型上下文窗口的一半之内。用 Token 来衡量你的代码库。将其与半个上下文窗口进行比较。如果超出了，你的 AI 劳动力已经在退化——不是显而易见的，不是戏剧性的，而是悄无声息且持续稳定的。
危险在于：当你越过这条线时，没有什么会明显出错。Agent 不会拒绝。代码看起来是正确的。测试通过了。你报告的 Bug 被修复了。
但是，Agent 现在是在没有完全理解你的系统的情况下运作。Agent 是在根据碎片进行模式匹配，而不是对整个系统进行推理。微妙的回归出现了。逻辑在 Agent 看不到的代码库部分被重复。问题通过添加代码被“解决”，而本应修改现有代码。
你不会立即注意到。速度感觉仍然很高。拉取请求仍然在流动。每次提交都在让下一个提交变得稍微糟糕一点。复合退化对你不利。
当你问“为什么我们的 Agent 一直在兜圈子？”时，你已经深陷问题之中了。
这条规则是披着技术外衣的商业纪律。
当生产成本为零时，简洁性成为你的竞争优势。构建能为客户带来真正价值的最小代码库。每一个不必要的功能，每一个不必要的抽象，每一行投机性的代码，都在消耗你 AI 劳动力的认知预算。最终，这些会吞噬你公司的行动能力。
最好的产品始终是那些完全解决一个真实问题的最简单的产品。违反这一原则的惩罚现在来得更快，并且复合得更厉害。你的 AI Agent 不会像一位沮丧的高级工程师那样反对你。
这个规则随架构扩展。单一产品创业公司：适用于整个代码库。多服务公司：独立适用于每个服务。任何需要作为一个整体来理解的系统部分，都必须能容纳在你的 Agent 推理完整图景的边界之内。
你的产品架构将反映你 Agent 的认知边界，无论你是否为此做规划。刻意为此设计的创始人，将超越那些通过痛苦来学习的创始人。
这不是关于完美。你不会总能保持在界限之下。代码库会增长。功能会添加。复杂性会累积。关键在于追求，而非刻板的遵守。如果你牢记这条规则并靠近边界，你将在构建什么、拆分什么、删除什么方面做出更好的决策。当其它一切都在说“构建更多”时，这个约束为你提供了一个参考点。有时，这意味着重新设计你的子 Agent 架构以适应规则——这与人类团队在成长时划分所有权非常相似。
我渴望在自己的工作中遵循这条规则。不是因为打破规则意味着瞬间失败，而是因为靠近这个约束能帮助我构建出长期有用、可维护且有价值的软件。围绕这个点来构建的创始人会走得更远。那些完全忽视约束的创始人将通过痛苦来学习。
好的约束不能保证成功。它们通过消除最常见的失败方式来增加成功的可能性。12-Factor 应用是一套原则，它不会为你构建你的 SaaS 公司，但如果你遵循它们，你的基础设施在你需要扩展时就能正常运行。半窗口规则的工作方式完全相同。遵循其精神。靠近边界。构建持久、有用的软件业务。
简洁性总是胜利。现在，简洁性胜利得更快。
关于作者：Abhishek Parolkar 是 https://brain.pe 的 CEO，该公司帮助私募股权公司为其自身或特定交易创建数字化 AI 大脑。你可能已经采用了 AI，但 AI 采用你了吗？
