第 2 章：Cline 规则
在大多数开发环境中，你的代码库并非孤立存在。它连接到数据库，与外部 API 集成，遵循特定的安全协议，并遵守与团队共同演进的编码标准。这些连接和约定构成了经验丰富的团队成员本能地遵循的隐形框架。
Cline 规则提供了一种使这个隐形框架显性化的方法。它们是一个指定的区域，你可以在其中记录指导 Cline 在你的代码库上工作的原则、实践和约束。
将 Cline 规则视为你团队的制度知识，以自主代理可以理解和遵循的方式编纂而成。
规则与要求
需要记住的一个重要区别是规则和要求之间的差异。Cline 规则侧重于代码应该如何编写以及系统应该如何修改——即管理实现的技术标准和实践。
业务要求、功能规范和项目目标属于另一个称为 Cline Docs 的单独区域。这种分离有助于保持清晰度，区分 Cline 应该做什么（要求）与它应该如何做（规则）。
将 Cline 作为新团队成员入职
确定哪些内容属于 Cline 规则的最佳方法是思考你在新开发人员入职第一周会告诉他们什么。他们需要了解什么才能提高效率并避免常见陷阱？
常见的类别包括反映团队软件设计理念的编码原则。如果你优先考虑可读性而不是巧妙性，或者倾向于组合而不是继承，那么这些原则应该被记录下来。
安全实践通常包含关键但不明显的G要求。也许所有数据库查询都必须使用参数化语句，或者 API 密钥必须存储在特定的环境变量中。这些内容并非总是通过阅读代码就能显而易见的。
文档指南有助于保持代码库的一致性。有些团队喜欢大量的内联注释，而另一些团队则偏爱全面的 README 文件和最少的代码注释。
编码风格涵盖了从命名约定到文件组织的所有内容。虽然 linter 可以捕获其中一些问题，但许多风格选择更细微且依赖于上下文。
当 Cline 需要修改数据结构时，数据库 schema 规则变得至关重要。了解哪些表可以更改，哪些需要迁移脚本，以及如何维护关系可以防止代价高昂的错误。
外部系统集成需要特别关注。如果你的应用程序连接到第三方 API、支付处理器或内部微服务，Cline 需要了解正确的协议、错误处理模式和速率限制注意事项。
质量问题
正如编写不佳的提示会导致次优结果一样，模糊或相互冲突的 Cline 规则也会造成不一致的体验。最常见的问题是含糊不清的语言，留下过多的解释空间。
考虑规则
“在可能的情况下优化代码。”
尽管意图良好，但此指南没有提供何时进行优化的具体标准。“在可能的情况下”可能意味着从“只要你看到机会”到“仅当性能至关重要时”的任何事情。结果是不可预测的行为——有时 Cline 会花费大量精力优化不需要优化的代码，而有时它会错过真正的性能瓶颈。
一个更有效的版本可能是
“当单元测试执行时间超过 100 毫秒时优化代码。”
这提供了一个清晰、可衡量的阈值，消除了歧义。
同样地，
“使用适当的编码技术”
听起来很合理，但在你的上下文中没有提供关于“适当”意味着什么的指导。它指的是设计模式、错误处理，还是其他完全不同的东西？
更好的方法是
“在设计类时使用 SOLID 原则”或“为所有外部 API 调用实现优雅的错误处理。”
冲突问题
另一个常见问题是当不同的规则相互矛盾时。
想象两条 Cline 规则
“类名使用 CamelCase（驼峰命名法）” - 编码原则文档
“类名使用 snake_case（蛇形命名法）。” - 编码风格指南
这些相互冲突的指令造成了一种不可能的情况，即遵循一条规则意味着违反另一条规则。
解决方案涉及创建一个规则层次结构，使其相互补充而不是相互竞争。你可以建立一个普遍原则，如“类名使用 CamelCase”，同时添加特定于语言的例外情况：“对于 Python 代码，类名使用 snake_case。”
这种方法允许你在每种语言中保持一致性，同时承认不同的技术有不同的约定。关键是使层次结构明确，以便 Cline 知道在特定情况下哪个规则优先。
活文档
随着你对 Cline 的使用扩展和系统的发展，你的 Cline 规则也应该随之演进。要求会改变，新技术会被采用，团队偏好也会随着时间推移而转变。将 Cline 规则视为静态文档会导致你的实际实践与 Cline 遵循的规则之间产生偏差。
定期审查和更新可确保 Cline 的行为与团队当前的标保持一致。当你采用新框架、更新安全实践或更改部署流程时，相应的 Cline 规则也应同步更新。
这种维护工作在一致性和可靠性方面带来了回报。维护良好的规则有助于 Cline 做出符合团队当前想法的决策，从而减少纠正和修改的需要。
实际实施
有效的 Cline 规则具有几个共同特征。它们足够具体以提供清晰的指导，但又足够灵活以适应不同的情况。它们组织逻辑清晰，易于查找相关信息。最重要的是，它们反映了团队的实际做法，而不是理想中的愿景。
首先记录最关键的规则——那些防止安全漏洞、保持系统稳定性或确保代码质量的规则。随着你对 Cline 的经验增加，你可以添加更细致的指南，捕捉团队处理常见问题的首选方法。
目标不是创建一本涵盖所有可能情景的详尽手册。相反，重点关注对代码质量、系统可靠性和团队效率影响最大的规则。
配置得当时，Cline 规则将 Cline 从一个有能力的通用编码助手转变为一个了解你的上下文、遵循你的标准并做出符合你实践的决策的团队成员。在创建和维护这些规则方面的投入，通过在编码任务中提供更一致、更可预测和更有价值的帮助而得到回报。
准备好创建你自己的 Cline 规则了吗？首先确定团队遵循的最重要的标准和实践，然后使用具体、可操作的语言记录它们。
