构建得好

一次演示只能证明某样东西能跑通一次。构建得好，意味着它能持续运行：面对真实数据、承受真实负载、真正有人参与其中，而且不需要靠任何人时刻提醒自己要小心。

这与写更多代码无关。让一个构建变得扎实的，大多是你在动手写任何代码之前就做出的设计选择：用哪些部件组装它、在哪个环节由人批准、哪些工作交给平台自身的能力而不是自定义代码完成，以及哪些东西绝不能离开该构建自己的配置。

八项原则，一句话概括每一项

可溯源性（Provenance）——答案中的每一个数字都能追溯到它的出处，否则答案就会直接说明数据中没有这项信息。
确定性（Determinism）——由 AI 来判断适用哪一条规则；规则本身以数据形式存在，人可以编辑；运算始终以同样、可靠的方式完成。
模块化（Modularity）——构建由多个部件组装而成，每个部件只做一件事、有明确的契约，而不是一大团纠缠不清的自定义逻辑。
无领域内核（Domain-free cores）——可复用的逻辑不带客户名称、不带具体业务细节；凡是特定于某一家公司的内容，都以配置的形式传入。
人的治理（Human governance）——一个真实的决定是一项被记录下来的事实——谁决定的、决定了什么、什么时候决定的——而不是在聊天窗口里随手打出的一句“好的”。
原生优先（Native-first）——先用平台已经提供的能力，再考虑写自定义代码；构建中的任何部分都不应保存登录凭证。
可运维性（Operability）——构建可以被重置、被测试、被独立核查，而不只是由构建者自己运行过一次。
安全与主权（Security and sovereignty）——凭证、密钥和敏感数据都留在配置中，绝不进入构建自身的逻辑。

页面	内容
八项原则详解	每项原则的完整说明：它的含义、做得好是什么样子、常见的出错方式，以及你该向自己的构建提出哪些问题。
用例形态	业务用例反复出现的九种形态，以及每一种通常由哪些部件组装而成。
人工批准	一个人如何从带有“批准”和“拒绝”按钮的邮件做出决定，并在页面上确认——以及为什么聊天回复不算是一项决定。
原生优先	为什么要先用平台自身的能力、再考虑写代码，以及这样做能带来什么好处。
文档模型	如何选择让“文档模块”（DocIQ）从文档中提取什么内容：优先采用默认模型，其次扩展它，最后才考虑自己编写。
反模式	反复出现的构建错误、每一种的代价，以及对应的修复方法。
审查清单	同样的八项原则审查，做成一份清单，供你在交付前对照自己的构建逐项核查。

这些都不需要死记硬背。找到与你眼前这个决定相匹配的页面，用它提供的问题来检视，然后继续前进。