AI 辅助开发如何遵守项目规范？

核心回答

让 AI 遵守项目规范，我会同时做好三件事：让规则可读取，让任务范围清楚，让结果可验证。

先把技术栈、目录职责、代码风格、常用命令和关键约束写进仓库中的规范入口，并按模块补充局部规则；开发前让 Agent 阅读相关代码和现成实现，再给出本次目标、改动范围及验收要求。生成后运行适当的格式、类型或测试检查，检查代码差异和业务行为。

团队使用不同 Coding Agent 时，共享同一份规范内容，再按工具实际支持的入口加载，避免各维护一套互相冲突的规则。文档指导模型行为；能自动检查的约束交给现有工具执行，业务取舍和功能正确性仍需审查。

展开说明

1. 把约定写成可定位、可维护的项目知识

规范入口应先回答 Agent 最容易猜错的问题：项目用什么语言和依赖管理方式，各目录负责什么，数据访问、错误处理、日志和接口格式有哪些现成约定，怎样运行与当前改动有关的检查。

规则要具体，例如“接口使用已有统一错误类型”，比“写高质量代码”更可执行。入口保持简短，详细设计、示例和特殊模块规则按路径组织；常规约定持续可见，特定任务流程可以用 Skill 承载，不要求每次把整套文档全部加载。

不同工具支持的文件名、路径范围和加载时机不同。可以把共享规范放在团队选定的文件或文档中，通过工具支持的项目指令入口引用、导入或同步生成；若维护生成副本，就检查它是否与共享源一致。AGENTS.md 能用于多种工具，但仍要核对版本和功能，不能仅因仓库存在这个文件就推断所有成员的 Agent 都读取了它。

2. 让 Agent 结合现有实现理解本次任务

项目规范提供长期约定，本次请求补充业务目标、输入输出、影响范围和验收条件。动手前先定位相关模块、已有方法和同类实现，明确哪些可以复用，避免凭通用经验另建一套架构。

例如给现有列表增加一个字段，可以明确字段已经存在、应放在哪列、是否支持现有排序及显隐，再让 Agent 参考相邻列实现。这样它有足够上下文完成局部修改，不需要为这个需求重新设计数据模型或引入组件库。

跨模块需求则需要说明接口边界和依赖关系，必要时先确定方案。发现规范与实际代码不一致时，应查清当前约定和变更原因，再决定采用或更新哪一处，而不是复制已经过时的示例。

3. 用已有工程检查反馈，检查完成后的代码

格式、类型、依赖方向和接口结构等可验证规则，尽量接入格式化工具、静态检查、结构测试或项目已有 CI。检查失败应提供具体文件、规则和修复方向，Agent 根据结果修改，再运行受影响的检查。

测试通过后还要看差异是否符合需求：有没有改无关文件、破坏现有接口、重复实现已有能力，是否覆盖用户原有改动。功能验收要回到需求，例如新增列是否显示正确、排序是否沿用原逻辑。AI 生成的测试也可能带着同样的错误假设，需要对照业务要求判断覆盖是否有效。

工具和命令的访问权限由执行环境控制。把“不要执行某命令”写在文档里能提醒模型，但真正需要阻止的操作，应在工具权限、受限环境或已有发布流程中落实。

4. 从实际违规持续修正规范，流程与改动相称

如果 Agent 经常调用错测试命令，就核实并更新命令；经常放错模块，就补目录职责和一个正确例子；已有静态规则能发现的问题，优先让检查返回清楚反馈。不要把所有偶发失误都累加成长篇禁令。

小范围文案、样式或已有字段修改，阅读对应规则后直接完成，做针对性验证即可。涉及公共接口、数据迁移、权限或重要状态变化时，再扩大设计和测试范围。规范应帮助团队稳定交付，而不是让每个小需求都承担完整项目的流程成本。

常见追问

只写 CLAUDE.md，其他 Coding Agent 怎么办？

统一规范的内容和维护来源，再通过各工具支持的项目指令入口引用、导入或同步。例如，可以在 CLAUDE.md 中导入共享规范；Copilot 也有仓库级和路径级指令机制。文件名、适用范围和加载方式按团队实际使用的工具确认，并检查共享内容更新后是否生效。

怎么确认规范真的加载了？

检查工具提供的上下文、引用或调试信息，并用一个小任务观察是否采用了对应命令和约定。仅让模型说“我已阅读”证据不够；还应看实际调用和产物。若没有加载，先排查位置、工作目录、适用路径及功能设置。

每个需求都要重新手写一整段提示词吗？

不用。通用规则和项目知识持续维护，本次只补需求特有的信息。让 Agent 按任务读取相关模块和文档，减少重复传递，同时避免它依据不完整上下文猜测实现位置。

规则越多，遵守得越好吗？

不一定。重复、冲突、过期和无关规则会增加选择难度。保留明确、适用且可验证的要求，按模块组织详细规则；用实际失败案例检查规则是否有效，再决定增补或删除。

对应教程

参考资料