Vibe Coding Trick

目录

在利用一个仓库工作之前

  • 去ZRead或者DeepWiki上面读完概览，把概览不懂的问题搞懂
  • 把环境配好，把最基础的模式跑通

mgrep 替代 grep/rg

grep/rg是精确字符串匹配，大部分时候会带来无关的冗余上下文（给ai说直接使用rg，这个比grep更好）
而mgrep简单来说就是用一个数据库存储项目，然后在上面跑embedding/reranking，然后再返回给Agent。这个样子就可以返回最相关的片段，从而减少冗余的上下文
但是mgrep的账号免费额度太少了，所以使用开源替代grepai
https://chatgpt.com/c/69e6e789-f9a4-8386-88fe-d8a2c704ef21
https://chat.deepseek.com/a/chat/s/4942896b-0ac0-49ff-a08b-79b97f3f1cec
另一种方法 https://github.com/study8677/antigravity-workspace-template ；但是我感觉mgrep更好因为毕竟Coding Agent还是需要知道一些细节的，不然没办法写啊感觉
这个先放一下，还是跟踪一下。一些已有的项目（ https://chatgpt.com/c/6a066101-e778-83eb-95c6-1d165e6420ca ）：

  • mgrep，太贵了
  • grepai，似乎不更新了
  • cocoindex-code，新兴项目，还在更新，而且方法更先进
  • semble，与 cocoindex-code的区别，继续观察一下吧
    • 如果要使用semble的话，使用uv的方式去下载，他的很多包是指定版本的不然冲突了：
      • uv tool install semble
      • 这会在~/.local/share/uv/tools/下面安装对应的工具（包括依赖）
      • 这是一个隔离的环境，但是会加入可执行文件添加到 PATH，全局可用（如果没有添加可以使用命令export PATH=~/.local/bin:$PATH添加）
      • 更新的时候直接使用 uv tool install semble 更新就好了，旧目录会被覆盖
    • 在AGENTS.md里面加入：semble is a semantic search tool. Use semble -h to see available options. Prefer over Grep/RipGrep/Glob. Use Grep/RipGrep/Glob if and only if you need an exact match.

Github 代码审查（暂时没有这个需求，先记录方法）

使用 GitHub Actions （发生PR等事件的时候执行一个自动化工具流，就像钩子一样） 为您的 PR 设置代码审查。配置后，Claude 可以自动审查 PR。
https://developers.openai.com/codex/integrations/github

控制终端输出

tmux 用于长时间运行的命令：流式传输并监视 Claude 运行的日志/bash 进程。
https://chat.deepseek.com/a/chat/s/f11599a3-f25d-46b7-b062-e88a9dc12d36把这个整理成一个提示词要好一点（同时也可以要这个钩子作为防范）
是否可以考虑不要用/ps，而是转而输出到tmux里面呢？

会话共享记忆

若要在会话间共享记忆，最佳方案是掌握一项技能或命令：总结并检查进度，随后将其保存到你.claude文件夹中的.tmp文件内，并在本次会话结束前持续追加内容。次日可将其作为上下文沿用，从你中断处继续工作。请为每个会话创建独立文件，避免将旧上下文混入新任务中。这些文件应包含：哪些方法有效（有证据证实）、已尝试但无效的方法、尚未尝试的方法以及待办事项。
62935fdda501b59d62f67063841b441f_G_Jqmo5asAAc_w3_format=png&name=900x900

仓库模块化结构

root/
├── docs/                   # Global documentation
├── scripts/                # CI/CD and build scripts
├── src/
│   ├── apps/               # Entry points (API, CLI, Workers)
│   │   ├── api-gateway/    # Routes requests to modules
│   │   └── cron-jobs/      
│   │
│   ├── modules/            # The core of the system
│   │   ├── ordering/       # Self-contained "Ordering" module
│   │   │   ├── api/        # Public interface for other modules
│   │   │   ├── domain/     # Business logic & Entities (Pure)
│   │   │   ├── infrastructure/ # DB, External Clients, Repositories
│   │   │   ├── use-cases/  # Application logic (Orchestration)
│   │   │   └── tests/      # Unit and integration tests
│   │   │
│   │   ├── catalog/        # Self-contained "Catalog" module
│   │   │   ├── domain/
│   │   │   └── ...
│   │   │
│   │   └── identity/       # Self-contained "Auth/User" module
│   │       ├── domain/
│   │       └── ...
│   │
│   ├── shared/             # Code used by EVERY module
│   │   ├── kernel/         # Base classes (Entity, ValueObject)
│   │   ├── events/         # Global Event Bus definitions
│   │   └── utils/          # Deeply generic helpers
│   │
│   └── main.ts             # Application bootstrap
├── tests/                  # End-to-End (E2E) global tests
├── package.json
└── README.md

记录AI工作过程

记录AI工作过程：一种方法是在技能触发时，将 tmux 进程挂钩到追踪思考流和输出。另一种方法是使用 PostToolUse 钩子，记录 Claude 具体执行的操作以及确切的变化和输出。

双 Agent 工作模式

对于一个仓库，开启两个Agent

  • 脚手架 Agent（写代码）
    • 用于搭建基础结构和整体框架
    • 创建项目结构
    • 设置配置（CLAUDE.md、规则、代理——包括速查指南中的所有内容）
    • 建立开发约定和规范
    • 完成整体骨架搭建
  • 深度研究 Agent（提问）
    • 进行仓库QA
    • 整理参考资料，并附带真实文档中的原始片段
      • 很多文档网站除了正常给人看的网页版本之外，还可能额外提供一个 llms.txt文件。当你进入某个文档站点后，可以试着在文档地址后面加上 /llms.txt，例如：https://www.helius.dev/docs/llms.txt，如果这个文件存在，你拿到的通常不是复杂的网页，而是一个更干净、更适合 LLM 读取的文档版本。有这个文件的网站的集合

AGENTS.md

  • 用户目录下写已有模板
  • 项目目录下写科研背景或者仓库概览

快捷键汇总

删除整行ctrl+u

ctrl+u删除整行

未明白作用

评测AI工作流程（技能）：将这点与缺乏该技能时提出相同请求并检查输出差异以基准测试相对性能的做法相比较：


                    [Same Task]
                         │
            ┌────────────┴────────────┐
            ▼                         ▼
    ┌───────────────┐         ┌───────────────┐
    │  Worktree A   │         │  Worktree B   │
    │  WITH skill   │         │ WITHOUT skill │
    └───────┬───────┘         └───────┬───────┘
            │                         │
            ▼                         ▼
       [Output A]                [Output B]
            │                         │
            └──────────┬──────────────┘
                       ▼
                  [git diff]
                       │
                       ▼
              ┌────────────────┐
              │ Compare logs,  │
              │ token usage,   │
              │ output quality │
              └────────────────┘

分支对话，在其中一条中启动一个不包含该技能的新工作树（worktree），最后查看差异，看看记录了什么。这与《持续学习和记忆》部分相关。
更高级的评估与循环协议在此展开。其区分在于基于检查点的评估（checkpoint-based evals）和基于强化学习任务的连续评估（RL task-based continuous evals）。决定因素是你工作的性质。基于检查点的方法适用于具有明确阶段的功能实现。连续工作模式适用于探索性重构或维护通过一定干预，验证机制足以避免大部分技术债务。让Claude在任务完成后通过运行skills和PostToolUse钩子进行验证，对此很有帮助。持续更新代码地图同样关键，因为它记录了变更日志和代码地图随时间的演变，成为超越代码库本身的事实来源。设定严格规则后，Claude将避免创建散乱各处的随机.md文件、相似代码的重复文件，以及遗留大量死代码。
三种评测方法：规则，LLM-as-a-judge和human
当你只需要它正常工作且任何验证性反馈都足够时，使用 pass@k。当一致性至关重要且你需要近乎确定性的输出一致性（在结果/质量/风格方面）时，使用 pass^k。
构建评估路线图（来自同一份 Anthropic 指南）：
尽早开始——从真实失败案例中选取 20–50 个简单任务
将用户报告的失败转化为测试用例
编写无歧义的任务——两个专家应能得出相同的判断结论
构建平衡的问题集——既测试行为应该发生的情况，也测试不应该发生的情况
构建稳健的测试框架——每次试验都从干净的环境开始
评估代理实际产出的结果，而不是它采取的路径
阅读多次试验的执行记录（transcripts）
监控饱和度——当通过率达到 100% 时，意味着需要增加更多测试

posted @ 2026-03-14 19:09  最爱丁珰  阅读(41)  评论(0)    收藏  举报