vibecoding之工程化控制

工程化控制

一、vinbcoding

1.使用git版本控制

开始 coding 前先检查 Git，没初始化就 git init，并创建基础 .gitignore。开发过程中在关键节点主动提醒我提交存档点；提交前先简要说明本次保存内容。提交信息用 init/feat/fix/refactor/docs/chore。不要做高风险 Git 操作

2.Memory记忆管理

记忆又分为项目级别与用户级别，分别对应跨项目与非跨项目记忆

3.rewind命令回退

/diff可以查看到本次代码修改动了哪些地方

/rewind(或空输入框下连按两次 Esc),会弹出一个菜单,列出这次会话中你发过的每条消息/对应的检查点

改动的是对话聊天级别的会话历史，更加精细一些，回退到当时输入提示词完成的时候

4.git远程仓库设置

我现在这个项目要推送到远程仓库。请先检查当前 Git 状态、当前分支、提交情况和远程仓库配置；如果本地还没初始化 Git，就先初始化；如果还没提交，就先提醒我建立一个清晰的存档点再推送；如果还没配置 remote，就提醒我提供远程仓库地址并帮我配置。确认无误后，再把当前分支推送到远程仓库。

推送前先简要告诉我：这次要推送什么、推送到哪个分支、有没有未提交内容或潜在问题。不要擅自 force push、不要改写历史、不要把敏感文件或不该上传的内容推送上去。若推送失败，先说明原因，再继续处理。

5.readme文件生成

请为当前项目生成一个清晰、简洁、可直接使用的 README.md。内容优先包括：项目简介、功能说明、安装方式、运行方式、目录结构、使用示例，以及后续可补充的说明。如果项目当前信息还不完整，就先基于现有代码和结构生成一个合理版本，不要写空话，不要堆模板废话，内容尽量贴合项目实际。

6.git创建分支

我现在要基于当前项目开一个新的 Git 分支来处理一个独立任务。请先检查当前 Git 状态和当前分支，确认工作区是否干净；如果有未提交内容，先提醒我是否需要先提交一个存档点。然后根据当前任务内容创建一个命名清晰的新分支，并切换到这个分支上开始开发

分支名尽量简洁明确，最好能体现任务用途，比如 feature/xxx、fix/xxx、refactor/xxx。不要擅自删除分支，不要改写历史；创建分支前先告诉我将基于哪个分支创建、分支名称是什么、为什么这样命名

/code-review这个用作代码审查，审查未提交或者修改的东西

7.git合并远程分支

我当前分支上的修改已经完成，现在需要提交并合并回主分支。请先检查当前 Git 状态、当前分支、未提交内容和提交情况；如果还没提交，就先帮我整理一个清晰的提交信息并完成提交。然后切回目标分支（如 main 或 master），执行合并当前分支的操作。

合并前先告诉我：当前分支名、要合并到哪个分支、这次主要改动是什么、是否存在冲突风险。不要擅自 force push、不要改写历史、不要删除分支；如果合并冲突或失败，先说明原因，再继续处理。

8.创建skill

我现在要创建一个全局可复用的 skill，功能是：<你在这里写清楚功能>。请根据这个功能，整理出这个 skill 的适用场景、触发条件、输入输出、执行流程和边界限制，再按规范生成 skill 目录和必要文件，至少包含 `SKILL.md`。不要把它写成当前项目专用说明，不要生成无关文档，不要写空泛模板内容，要保证后续在别的项目里也能复用。

二、Agent工程

1.创建Agent

1.1、单元测试agent

创建技能

我现在要创建一个全局可复用的skill，功能是：为不同项目编写、补充、整理和执行单元测试。请基于这个功能，先明确这个 skill 的适用场景、触发条件、支持范围、输入输出、执行流程和边界限制，再按规范生成 skill 目录和必要文件，至少包含 `SKILL.md`。这个 skill 要重点解决单元测试相关工作，例如：为现有代码补测试、为新功能配套测试、检查测试缺口、整理测试结构、执行测试并反馈结果。

要求：
- 这是全局 skill，不要写成只服务当前项目
- 内容要写清楚什么时候触发这个 skill、它应该怎么工作、有哪些限制
- 优先强调测试质量、覆盖关键逻辑、避免无意义测试、避免过度依赖脆弱实现细节
- 如果不同技术栈测试方式不同，要让 skill 能根据项目现有技术栈自动贴合
- 不要生成无关文档，不要堆空话，不要只写空模板

创建agent

在 .claude/agents/ 目录下创建一个 unit-test-writer subagent（项目级）：

- name: unit-test-writer
- description: 写清楚触发场景，当我提到"写测试"、"补测试"、"单测挂了"等需求时主动使用；并说明可调用 [你的技能名1]、[你的技能名2] 等技能
- tools: Read, Write, Edit, Bash, Grep, Glob
- 系统提示词要求它：先看项目现有测试框架和风格再写，覆盖正常路径/边界值/异常输入，用 mock 隔离外部依赖，写完用 Bash 跑一遍确认通过，失败时判断是测试错了还是代码有 bug；在合适场景下主动调用 [你的技能名1]、[你的技能名2]，最后简短总结结果

创建前检查是否已有同名 agent，也检查一下 .claude/skills/ 里这些技能是否存在，创建后告诉我怎么调用它。

1.2、质量工程师agent

创建技能

• 注释检查技能

  在 .claude/skills/ 目录下创建一个 comment-checker 技能（SKILL.md）：
  
  - 技能名：comment-checker
  - description: 说明用途和触发场景——用于检查代码注释质量，当我提到"检查注释"、"注释质量"、"代码可读性"等需求时使用
  - 技能内容要求包含以下检查维度：
    1. 注释覆盖率：本次改动是否相比之前减少了注释（尤其是复杂逻辑、公共方法、非直观代码处删除了原有注释）
    2. 注释与代码是否匹配：注释描述的行为和实际代码逻辑是否一致，有没有"代码改了注释没改"的情况
    3. 可读性：注释是否让没有背景知识的新手也能看懂，避免只写"做了什么"而不写"为什么这么做"
    4. 术语规范：专业名词、缩写是否统一、准确，避免生造词或和项目里其他地方叫法不一致
  - 输出要求：按文件列出问题，每条问题说明具体位置、问题类型（缺失/不匹配/晦涩/术语不一致）和修改建议，最后给一个简短总体评价
  
  创建前检查 .claude/skills/ 下是否已有同名技能，创建后告诉我怎么在对话或 subagent 里调用它。

• 安全审计技能

  在 .claude/skills/ 目录下创建一个 security-auditor 技能（SKILL.md）：
  
  - 技能名：security-auditor
  - description: 说明用途和触发场景——用于代码安全审计，当我提到"安全审计"、"代码安全检查"、"有没有安全隐患"等需求时使用
  - 技能内容要求包含以下检查维度：
    1. 敏感信息泄露：硬编码的密钥/密码/Token/AK-SK、数据库连接串、内部 IP/域名、注释里遗留的敏感信息
    2. 注入类风险：SQL 注入（拼接 SQL、未使用预编译/参数化查询）、命令注入、模板注入（SSTI）、LDAP/XPath 注入等
    3. 反序列化与输入校验：不可信数据反序列化、文件上传校验缺失、路径穿越、SSRF 风险点
    4. 鉴权与权限：越权访问、鉴权逻辑缺失或可绕过、默认弱口令、CORS 配置过于宽松
    5. 配置文件审查：生产配置是否误提交敏感信息、调试模式/Debug 是否在生产环境开启、依赖版本是否存在已知 CVE
    6. 加密与传输：弱加密算法（如 MD5/DES 用于密码）、明文传输敏感数据、随机数生成是否使用了不安全的伪随机源
    7. 其他隐患：日志中打印敏感信息、异常信息暴露堆栈/内部结构给外部
  - 输出要求：按文件/位置列出问题，每条说明风险类型、危害等级（高/中/低）、具体代码位置和修复建议，最后给一个总体风险评级和优先修复顺序
  
  创建前检查 .claude/skills/ 下是否已有同名技能，创建后告诉我怎么在对话或 subagent 里调用它。

创建agent

在 .claude/agents/ 目录下创建一个 code-quality-reviewer subagent（项目级）：

- name: code-quality-reviewer
- description: 写清楚触发场景，当我提到"代码审查"、"检查注释"、"安全审计"、"代码有没有问题"等需求时主动使用
- tools: Read, Grep, Glob（只读分析，不需要写权限）
- 系统提示词要求它：
  1. 调用时先明确本次审查范围（改动的文件/目录）
  2. 依次调用 comment-checker 技能检查注释质量，调用 security-auditor 技能检查安全隐患
  3. 汇总两个技能的输出，按文件列出问题，标注问题来源（注释/安全）、严重程度、具体位置和修改建议
  4. 最后给一个总体结论：是否可以合入，若不能则列出必须先修复的高优先级问题

创建前检查 .claude/skills/ 下 comment-checker 和 security-auditor 是否都存在，也检查 .claude/agents/ 下是否已有同名 agent。创建后告诉我怎么调用它。

2.hook工程

在 .claude/hooks/ 下创建一个 git commit 审查门禁的 hook 方案，配合已有的 code-quality-reviewer subagent：

1. PreToolUse hook，matcher 为 Bash，if 条件匹配 "Bash(git commit *)"：
   - 检查项目根目录下是否存在标记文件（如 .claude/.review-passed，内容记录本次通过审查的 staged diff 的 hash）
   - 用 git diff --cached 计算当前暂存区的 hash，和标记文件里记录的 hash 对比
   - 如果标记文件不存在，或者 hash 不一致（说明代码在审查后又改动过）：exit 2，并在 stderr 提示"请先让 code-quality-reviewer 子代理审查本次改动，通过后再提交"，阻止这次 commit
   - 如果标记文件存在且 hash 一致：exit 0，放行

2. PostToolUse hook，matcher 为 Bash，if 条件匹配 "Bash(git commit *)"，且上一步工具执行成功：
   - 提交成功后，删除标记文件（.claude/.review-passed），确保下一次改动必须重新走一遍审查流程，不会用旧的通行证蒙混过关

3. 同时更新 code-quality-reviewer 这个 subagent 的系统提示词，让它在审查通过后，主动执行：
   - 计算当前 git diff --cached 的 hash
   - 把 hash 写入 .claude/.review-passed 作为通行证
   - 只有 comment-checker 和 security-auditor 两个技能都没有高优先级问题时才生成这个标记文件；有问题就不生成，并列出必须先修复的项

请在 .claude/settings.json（项目级，可提交到 git）里写好这两个 hook 配置，脚本可以放在 .claude/hooks/ 目录下，用 bash + jq 解析 hook 收到的 JSON。写完后告诉我怎么测试这个流程（比如故意改一行代码不经过审查直接 commit，验证会被拦截）

三、总结