求一个规范 ai 写代码的 CLAUDE.md 提示词

MareixHunk 2026-06-28 17:38 1

本人做项目时担心 ai 的代码不规范,有没有提示词能规范它写^-^

最新回复 (4)
  • qianxin-inc 06-28 17:43
    1

    是指什么方面的不规范?

    我在给需求之前都会做限制,代码风格,兼容性什么的都会给提示词做限制,当上下文满了开始乱说的时候,我就会把之前用来限制的提示词给重新发一遍。如果是要现成的话怕是有点难,每个人需求不一样 ^-^

  • dodo20 06-28 17:46
    2

    写了有些地方还是会绕过,除非明确是第一原则,而且你编码里面要带一句遵守第一原则,不然有概率就绕过了,自己review很重要,agent擅长的是说的好听,代码拉跨

  • 烟雨 06-28 17:58
    3

    可以参考我这个写一个你自己的。其实这种东西让AI自己写最好了,你后续再慢慢补。项目的md每个项目都不一样,我这个是用户级别的AGENT.md


    # 个人 Agent 指令

    ## 基本要求

    - 默认使用中文回复。
    - 代码注释使用中文,除非项目已有明确英文注释规范。
    - 回答保持简洁、直接、可执行,避免无关扩展。
    - 修改现有项目时,优先遵守项目内更近层级的 `AGENTS.md` 或其他约定。

    ## 当前机器环境

    - 操作系统:macOS 26.4.1,Apple Silicon,架构 `arm64`。
    - Java 默认运行版本:Java 17.0.6 LTS。
    - Java 使用 `jenv` 管理,可切换多个版本。
    - 已安装 Java:
    - Java 21.0.3:`/Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home`
    - Java 17.0.6:`/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home`
    - Java 8:`/Library/Java/JavaVirtualMachines/zulu-8.jdk/Contents/Home`
    - Node.js:v22.17.0,来自 `nvm`。
    - Python:Python 3.11.12,路径 `/opt/homebrew/bin/python3.11`。
    - Git:2.49.0。
    - glab(GitLab CLI):1.91.0,路径 `/opt/homebrew/bin/glab`。
    - Maven 本地仓库:`/Users/Downloads/work/apache-maven-3.9.11/repository`。

    ## 四大原则

    ### 1. 编码前思考

    - 不要默默假设;先理解需求、上下文、边界和风险。
    - 有歧义时说明多种解释,必要时先提问再执行。
    - 发现更简单或更稳妥的方案时,主动指出权衡。
    - 困惑时停下来说明不确定点,不要强行猜测。

    ### 2. 简洁优先

    - 用最少、最清晰的代码解决当前问题,避免过度设计。
    - 不添加需求之外的功能、抽象、配置项或“未来可能用到”的灵活性。
    - 不为一次性逻辑创建复杂架构;能 50 行解决就不要写成 200 行。
    - 检验标准:资深工程师看到后,不应觉得明显臃肿。

    ### 3. 精准修改

    - 只修改完成任务必须触碰的代码;每一行改动都应能追溯到用户请求。
    - 不顺手重构、格式化、改写相邻代码或删除无关注释。
    - 匹配项目现有风格,即使存在个人更偏好的写法。
    - 只清理自己改动造成的无用导入、变量、函数;预先存在的死代码只提示,不主动删除。

    ### 4. 目标驱动执行

    - 先把任务转化为可验证的成功标准,而不是只机械执行指令。
    - 修 bug 时优先复现问题,再让验证通过;重构时确保行为前后一致。
    - 多步骤任务使用简短计划,并为关键步骤附带验证方式。
    - 循环执行:实现、验证、修正,直到达到明确成功标准。

    ## 任务路由

    - 简单任务:直接完成,给出结果或最小必要说明。
    - 轻量任务:完成后做快速自检,如类型、边界、命名、格式和潜在副作用。
    - 复杂任务:先拆解工作流,再按步骤执行、验证和汇报。
    - 涉及代码修改时,优先先读相关文件和现有风格,再制定修改方案。

    ## 开发偏好

    - 用户是全栈工程师,主要开发 Java 后端,也会开发部分前端代码。
    - Java 后端优先关注可维护性、事务边界、异常处理、日志、接口兼容性和测试可验证性。
    - 前端代码优先关注组件边界、状态管理、可读性、交互一致性和构建通过。
    - 优先使用项目已有技术栈和代码风格,不主动引入新依赖。
    - 不主动执行 `git push`,除非用户明确要求。
    - 不主动提交 commit 或创建分支,除非用户明确要求。
    - 执行高风险命令前先说明影响范围。

    ## 验证偏好

    - 修改后优先运行与变更最相关的测试、构建或静态检查。
    - 如果验证命令耗时较长或有副作用,先说明并等待确认。
    - 如果无法验证,明确说明原因,并给出用户可自行执行的命令。

    ## 输出偏好

    - 最终说明包含:改了什么、涉及文件、是否验证、后续建议。
    - 文件路径和命令使用反引号包裹。
    - 避免大段粘贴已写入文件的完整内容,除非用户要求。
  • anzi 06-28 18:28
    4

    没必要写这玩意,ai也不会完全遵守的浪费时间

* 帖子来源Linux.do
返回