征服熵：培育信任

# 征服熵增：培育信任 来源：https://kaeruct.github.io/posts/2026/09/06/conquering-entropy-cultivating-trust/ > 属于《征服熵增 (https://kaeruct.github.io/posts/2026/09/05/conquering-entropy-intro/)》系列文章 我对AI生成代码的大部分疑虑都关乎信任。我信任提交这个工单的人吗？我信任提交这个PR的工程师是否理解工单并恰当引导编码智能体进行实现吗？我信任编码智能体的实现方案吗？我信任我们的测试套件能在问题进入生产环境前捕获回退吗？我信任我们的CI/CD流程能正确构建、测试并部署变更吗？我信任我们的可观测性架构能在AI生成代码破坏生产环境时发出警报吗？我信任AI站点可靠性工程师（Site Reliability Engineer）能准确诊断问题并协助缓解吗？我信任GitHub在我们最需要它的时候不会发生故障（https://mrshu.github.io/github-statuses/）吗？ 信任难得却易失。因此我认为在工程团队中培养信任文化至关重要。你必须信任工程师会做正确的事。 ## 强化责任感 我发现清晰传达以下理念很有帮助：“你需要为自己交付的成果负责。如果这破坏了生产环境且你提交了该PR，你就应该负责修复它。” 如果工程师需要对所交付的代码负责，就应当赋予他们使用首选方法产出代码的自主权。即使你并非AI的狂热信徒，也必须承认AI智能体确实能快速生成大量代码。代码仍需生成，而如今的期望是大量生成的成本已变得低廉。为应对此现象，必须允许工程师采取某些措施，确保代码库质量不会下滑。 在一个健康的组织中，工程师应当相互信任，只推送质量合理的代码。我说“合理”，是因为执着于完美、追求永远100%完美的代码并不现实。甚至在编码智能体出现之前，大多数代码就已是充满缺陷的混乱状态！因此交付“足够好”的解决方案是可以理解的。我们常常为了交付速度牺牲质量，并积累一些技术债务。 以下是我发现有助于在这个编码新时代促进工程责任感的实践： ### 编码规范 制定清晰的技术策略：花时间确定对代码库重要的事项，并制定明确的规范。这些规范既适用于人类，也适用于编码智能体。即使人类不阅读规范，他们的编码智能体也会阅读并（大体）遵循。 ### 确定性工具 大量使用确定性工具来确保代码质量。强类型语言、代码分析器、死代码检测、安全扫描、CI/CD等。所有这些工具在编码智能体出现之前就已存在，并在对抗代码腐化方面帮助我们。（敬请期待后续推荐具体工具的文章！） ### 坚持小规模PR 授权工程师拒绝难以审查的PR。如果可能，将此标准制度化，使任何难以审查的PR立即被拒绝。当然，也要为例外情况留出空间。 ### 自主掌控测试 手工编写测试用例。这类似于业务分析师的职责。深入思考功能特性并定义合理的测试场景。在团队内讨论这些内容。编码智能体可以实现测试，但测试应由人类定义。 ### 产品品味 与产品团队协同工作，形成连贯的产品愿景。使用AI很容易头脑发热，实现任何想到的功能。确保只实现真正为用户带来价值的实用功能。 ### 原型开发 编写可丢弃的代码。由于现在代码非常容易生成，这是尝试不同方法的好机会。不要只让编码智能体生成一种方案。例如，尝试三种截然不同的方法，然后选择最适合问题与现有系统的方案。 ### 聚焦成果 对结果保持务实态度。有时代码本身并非成果。成果可能是一份报告，或是一个帮助你完成其他事项的工具。对于这类情况，只要结果有用，代码质量就不是那么重要。