claude-coding-skilllisted

# 代码生成方法论 这份规则描述的是模型在实际生成代码时所遵循的真实决策过程。它覆盖从读取现有代码到输出新代码的完整链路，包括模式识别机制、一致性维护规则、以及多文件改动的顺序控制。理解并遵循这些规则是保证生成代码能够无缝融入现有代码库的基础。 --- ## 一、写代码之前：读懂现有模式 ### 1.1 模式优先于知识 模型拥有大量关于各种编程语言、框架和设计模式的通用知识。但在一个具体的代码库中，这些通用知识必须让位于代码库已经建立的具体模式。 原因是：每个代码库都是在通用知识的基础上做了大量具体选择的结果，这些选择包括命名风格、目录结构、错误处理方式、日志格式、数据访问方式、组件通信方式等。如果模型用通用知识覆盖代码库的具体选择，产出的代码会在风格上与已有代码格格不入，增加维护成本。 ```mermaid flowchart TD A[接收代码生成任务] --> B[识别相关的现有代码] B --> C[提取已有模式] C --> C1[命名约定] C --> C2[文件和目录结构] C --> C3[错误处理方式] C --> C4[数据访问模式] C --> C5[导入和依赖组织方式] C1 & C2 & C3 & C4 & C5 --> D[建立代码库模式模型] D --> E[在模式约束下生成新代码] ``` ### 1.2 需要读取的内容 在生成新代码之前，需要阅读以下内容： 与任务直接相关的现有文件，理解它的结构、依赖和模式。同类型的其他文件（比如如果要写一个新的 API 控制器，读一个已有的控制器），理解这个类型的文件在这个代码库里是怎么写的。被新代码依赖的文件（工具函数、基础类、配置等），理解它们的接口和使用方式。会依赖新代码的文件（如果能确定的话），理解它们期望的接口形式。 ### 1.3 读代码时需要提取的信息 读现有代码不是简单地浏览，而是主动提取以下信息： 函数和变量的命名模式（驼峰还是下划线，动词在前还是名词在前，缩写还是全拼）。错误处理的统一方式（抛出异常还是返回错误对象，错误日志的格式，用户可见的错误消息的形式）。异步处理的方式（async/await 还是 Promise 链，回调还是 Observable）。数据获取和状态更新的模式（在哪里发请求，数据如何在组件或模块间传递）。测试的覆盖方式（有没有测试，测试文件在哪里，测试的粒度是什么）。 --- ## 二、生成代码的核心原则 ### 2.1 最小改动原则 每次代码改动应该只包含为了完成任务必须做的最小集合。不要在完成任务的同时顺手重构代码，不要改变与任务无关的格式或命名，不要删除看起来没用但没有完全确认的代码。 这个原则的理由是：每一行额外的改动都是引入新 Bug 的机会，都是在代码审查中需要额外解释的内容，都是版本历史中的噪声。如果发现了需要重构的问题，单独提出来而不是顺手做掉。 ```mermaid flowchart TD A[需要实现某个功能] --> B[确定最小的实现集合] B --> C{是否发现了可以顺手改进的地方} C -- 是 --> D[记录下来单独处理] C -- 否 --> E[只做最小集合的改动] D --> E E --> F[验证改动完成了任务] F --> G[检查改动是否引入了意外的副作用] ``` ### 2.2 一致性维护 新生成的代码必须在多个维度