AI代码一致性：一个模式，633个服务

AI代码一致性来自构建一个主模式并让AI去复制它——绝不让它两次发明新方法。一个真实的平台在规模上证明了这一点：633个服务，每一个都是同一个305行基础代码的完全相同的副本，每一个都由AI构建。重复，而非新奇，才是超能力。

如果你不懂技术，这可能是AI辅助构建中最反直觉的一课。我们从小被训练成认为创造力是最有价值的部分。在软件中恰恰相反：最有价值的代码库，是最无聊的那些。下面是这个故事，把概念提升到代码之上来讲。

差点犯下的错误

2025年1月。FIKR Space的数据库设计完毕——964张表，从第一天起就是多租户。现在它需要服务。大量的服务。

AI构建了第一个。它能用。很好。AI构建第二个——却用了不同的模式。不同的错误处理，不同的数据库查询方式。第三个服务？又是另一种模式。

到此为止。因为这条轨迹的数学很残酷：这样继续下去，做到第100个服务时，你就有100种不同的模式。每个bug要用100种不同的方式修复。重构变得不可能。一致性成了奢望。

这不是AI在捣乱。让AI从零构建东西，它会生成一个完全合理的、互联网平均水平的方案——而且每次都是一个不同的完全合理的方案。AI是出色的即兴发挥者，而即兴发挥恰恰是代码库无法承受的。放任不管，你就会滑入氛围编程陷阱。

服务到底是什么（无需代码）

为非技术读者做个快速翻译。服务是介于你的数据库和界面之间的那一层。当用户点击“保存”时，服务会检查他们是否有权限、把数据写入正确的位置、记录是谁操作的，然后回报——成功，或一条有用的错误信息。

如果数据库是产品的地基，界面是它的脸面，那么服务就是神经系统：每个信号都要经过它们。产品的每个功能都需要一个服务——这就是为什么一个严肃的平台最终需要数百个。而且每个服务都必须回答同样的五个问题：这个用户被允许这样做吗？这是哪位客户的数据？出错时会发生什么？这个操作应该被记录吗？输入安全吗？

五个问题，数百个服务。这种重复要么是你最大的风险，要么是你最大的资产——取决于一个决定。

AI代码一致性：主模式这一招

这个决定是：停止构建服务，先构建模式。一个基础——305行代码——一次性回答全部五个问题。错误处理。多租户过滤，让每位客户只能看到自己的数据。权限检查。审计日志。输入清理。每一个来之不易的答案，只编码一次。

然后，在交给AI的每份功能蓝图里写入一条规则：每个服务都继承这个基础。没有例外。（这些蓝图就是PRP——具体做法见PRP方法。）

从那一刻起，AI不再即兴发挥，开始复制。要一个新服务，它就复制那个经过验证的骨架，填入具体内容，并免费继承每一项安全属性。第一个服务大约用了2小时——正确构建基础所需的时间。之后的632个，每个只用15–30分钟。放眼整个平台，相比每个都从零构建，大约节省了800小时。

本书The Solopreneur RevolutionLuis Gonçalves 讲述如何在不辞职的情况下用 AI 打造独立创业者事业。获取本书 →

一处改动，633处更新

复利的回报在后面才到来。当审计日志被加入基础代码时，全部633个服务立刻都有了。当错误信息为安全而被清理时，全部633个服务都有了。当查询处理得到改进时，全部633个服务都有了。一处改动，633处更新，零手动编辑。

这提示了一个检验你的架构是否奏效的简单测试。称之为规模测试：如果你能给基础代码添加一项能力，并且每个服务都立刻继承它，你就成功了。如果你得手动更新633个文件，你就失败了。这个测试在6个服务时和633个服务时同样适用——唯一的区别是，发现答案太晚会有多痛。

为什么重复是超能力

“无聊即美”这一论点背后的数字：

看看最小/最大那一行。最简单的服务是87行；最复杂的处理了整个投资交易工作流，达2,214行。工作天差地别——骨架完全相同。复杂度会变；模式永远不变。

要带走的概念是：AI是完美的复制者。无论你把什么交给它做参考，它都会忠实而不知疲倦地复现——这意味着杠杆完全在于你让什么东西值得被复制。把一个模式做对一次，AI就会毫无倦意、毫无自负、毫不偷懒地把它复制数百次。一开始什么都没做对，AI则会乐此不疲地复制混乱。同样的逻辑驱动着生产级提示词剖析：把AI指向你现有最好的作品，让它去复制。

创造力属于你的产品、你的定位、你的报价。你的代码库应该是你拥有的最没有创意的东西。

12 周企业职业生涯从来都不是计划申请加入 Solopreneur Accelerator。立即申请 →

常见问题

通俗地说，服务层是什么？

它是你产品的中间层：位于数据库（数据所在）和界面（用户所见）之间的代码。每个有意义的操作——保存、获取、删除、检查权限——都要流经服务。这就是为什么那里的一致性比任何地方都更重要。

我需要633个服务吗？

不需要——那个数字反映的是一个大型多产品平台。但这个原则从你的第五个服务起就适用。“每次都用不同模式”的陷阱从第二个服务就开始了，而修复不一致的成本会随着你添加的每个服务增长。先构建基础，再构建大量服务。

如何让AI每次都遵循我的模式？

两步。第一，把基础创建为你产品里的一个真实文件，而不是你脑子里的想法。第二，在每份功能蓝图中用“没有例外”的规则明确引用它。AI遵循示例远比遵循描述更好——让AI参考文件的具体做法见生产级提示词剖析。

如果我跳过主模式会怎样？

做到第十个服务时，你会有十种不同的模式：十种错误处理风格、十种安全做法、十种与数据库对话的方式。每个修复都得为每个服务重新摸索，而一次像样的清理最终意味着重写你大部分的产品。这是氛围编程陷阱的结构化版本——现在进展飞快，日后连本带利地偿还。