文档教程提示工程人工智能【免费下载链接】context-engineering-introContext engineering is the new vibe coding - its the way to actually make AI coding assistants work. Claude Code is the best for this so thats what this repo is centered around, but you can apply this strategy with any AI coding assistant!项目地址https://gitcode.com/gh_mirrors/co/context-engineering-intro点击查看免费下载导读本文讲解本仓库validation/目录下 Ultimate Validate Command 的完整方法论——如何让 Claude Code 深度分析你的代码库、发现真实用户工作流并自动生成一份覆盖 linting、类型检查、风格检查、单元测试与端到端测试的.claude/commands/validate.md。读完本文你将掌握以用户旅程为核心的 E2E 验证设计思路并用一条/validate命令获得对生产环境可用性的完整信心。从验证命令到验证哲学在 Context Engineering上下文工程的体系里AI 编码助手能否交付可用的代码很大程度上取决于项目是否把验证作为一等公民写进上下文。本仓库根目录 README.md 明确指出Context Engineering 的核心价值之一就是Self-Correcting自纠正通过 validation loops验证循环让 AI 修复自己的错误。而validation/ultimate_validate_command.md正是把这一理念工具化的产物——它本身是一个给 Claude Code 执行的命令定义目标是分析代码库生成一个不放过任何角落的验证命令。配套的 validation/README.md 给出了两条命令的使用方式# 1. 生成你的专属验证命令自动写入 .claude/commands/validate.md /ultimate_validate_command # 2. 运行完整验证linting、类型检查、风格检查、单元测试、全面 E2E 测试 /validate其核心哲学用一句话概括If/validatepasses, your app works.当验证命令通过时应用就应该可以上线——不是部分功能可用而是像真实用户一样在生产的完整路径上运行无误。第 1 步发现真实用户工作流Step 0原文档强调在分析工具链之前先理解用户真正在做什么。这是整个方法论中最容易被忽视、却最关键的一步因为你的 E2E 测试应该镜像文档中的真实工作流而不是只测内部 API。具体要做三件事阅读工作流文档README.md—— 查找 Usage、Quickstart、Examples 章节CLAUDE.md/AGENTS.md或类似文件 —— 查找工作流模式docs/目录 —— 用户指南、教程。识别外部集成应用使用了哪些 CLI检查 Dockerfile 中安装的工具调用哪些外部 APITelegram、Slack、GitHub 等交互哪些服务。从文档中提取完整用户旅程寻找类似 Fix Issue (GitHub): 或 User does X → then Y → then Z 的示例每个工作流都成为一个 E2E 测试场景。以本仓库为例use-cases/agent-factory-with-subagents/README.md描述了 AI Agent Factory 的完整工作流——用户提出需求 → 澄清问题 → 子代理并行开发 → 实现 → 验证 → 交付。这样的流程文档就是 E2E 场景的天然来源验证命令应该能模拟从请求一个 Agent 到收到带测试和文档的完整 Agent的整条路径而不只是断言某个函数返回正确。第 2 步深度代码库分析Step 1在动笔生成validate.md之前Claude Code 需要回答三个问题项目里已有哪些验证工具应用本身在做什么目前是怎么测的盘点已有的验证工具原文档给出的排查清单非常实用类别查找目标Linting 配置.eslintrc*、.pylintrc、ruff.toml类型检查tsconfig.json、mypy.ini风格/格式化.prettierrc*、black、.editorconfig单元测试jest.config.*、pytest.ini、测试目录包管理器脚本package.jsonscripts、Makefile、pyproject.tomltools以本仓库的mcp-server子项目为例可以找到tsconfig.json、vitest.config.js、package.json、tests/目录含unit/、fixtures/、mocks/——验证命令就应当把这些真实存在的工具与测试组织成对应阶段。理解应用本身前端路由、页面、组件、用户流后端API 端点、认证、数据库操作数据库Schema、迁移、模型基础设施Docker 服务、依赖。摸清当前测试方式已有测试文件与模式CI/CD 工作流.github/workflows/等package.json或脚本中的测试命令。第 3 步生成 validate.md 的五阶段结构Step 2原文档规定生成的.claude/commands/validate.md应包含以下阶段且只包含代码库中真实存在的阶段Phase 1Linting运行项目实际的 linter 命令如npm run lint、ruff check。Phase 2Type Checking运行项目实际的类型检查命令如tsc --noEmit、mypy .。Phase 3Style Checking运行项目实际的格式化检查命令如prettier --check、black --check。Phase 4Unit Testing运行项目实际的测试命令如npm test、pytest。Phase 5End-to-End Testing要求创造性且全面这是整个方法的灵魂所在。原文档定义了E2E 测试的三个层级层层递进内部 API你自然会测的层面适配器端点正常工作数据库查询成功命令能够执行。外部集成你必须测的层面CLI 操作GitHub CLI 创建 issue/PR 等平台 API发送 Telegram 消息、发布 Slack 消息应用依赖的任何外部服务。完整用户旅程给你100% 信心的层面从头到尾走完文档中的工作流示例用户让机器人修复 GitHub issue → 机器人克隆仓库 → 修改代码 → 创建 PR → 在 issue 下评论像真实用户在生产环境中使用应用那样去测试。好与坏的 E2E 测试对比原文档给出了非常直观的例子❌Bad测试/clone命令把数据存进了数据库✅Good克隆仓库 → 加载命令 → 执行命令 → 验证 git commit 已创建✅Great创建 GitHub issue → 机器人收到 webhook → 分析 issue → 创建 PR → 在 issue 下评论并附上 PR 链接。E2E 的实操要点使用 Docker 获得隔离、可复现的测试环境按需创建测试数据/仓库/issue在外部系统中验证结果GitHub、数据库、文件系统测试结束后清理环境。仓库里的活样板example-validate.md 与真实验证报告原文档配套的 validation/example-validate.md 提供了一个React FastAPI PostgreSQL 应用的完整生成示例展示了五阶段结构落地后的真实样貌## Phase 1: Linting !cd frontend npm run lint !cd backend ruff check src/ ## Phase 2: Type Checking !cd frontend npx tsc --noEmit !cd backend mypy src/ ## Phase 3: Style Checking !cd frontend npm run format:check !cd backend black --check src/ ## Phase 4: Unit Testing !cd frontend npm test -- --coverage !cd backend pytest tests/unit -v --covsrc而 Phase 5 展示了三层级 E2E的实际操作方式## Phase 5: End-to-End Testing ### Setup !docker-compose up -d !timeout 60 bash -c until curl -f http://localhost:8000/health; do sleep 2; done ### Frontend E2E (Playwright) !cd frontend npx playwright test ### Backend E2E (API Database) !curl -X POST http://localhost:8000/api/auth/register -d {email:testtest.com,password:Test123!} !TOKEN$(curl -X POST http://localhost:8000/api/auth/login -d {email:testtest.com,password:Test123!} | jq -r .token) !curl http://localhost:8000/api/items -H Authorization: Bearer $TOKEN !curl -X POST http://localhost:8000/api/items -H Authorization: Bearer $TOKEN -d {name:Test} ### Verify database !docker exec postgres psql -U user -d db -c SELECT COUNT(*) FROM users; !docker exec postgres psql -U user -d db -c SELECT * FROM items WHERE nameTest; ### Test error handling !curl -w %{http_code} http://localhost:8000/api/items/invalid-id # Should be 404 !curl -w %{http_code} http://localhost:8000/api/admin -H Authorization: Bearer $TOKEN # Should be 403 ### Cleanup !docker-compose down -v注意几个值得借鉴的细节Setup 阶段等待健康检查就绪timeoutuntil curl -f错误路径也要验证404、403 的预期状态码以注释形式固化直接查询数据库核对数据一致性最后docker-compose down -v清理环境。这套模式完整呼应了原文档三层级 E2E的设计。真实产物验证报告长什么样原文档说/validate通过后应彻底到手动测试完全多余仓库里恰好有一份真实样例可以印证——use-cases/agent-factory-with-subagents/agents/rag_agent/tests/VALIDATION_REPORT.md是 Validator 子代理对语义搜索 Agent 生成的验证报告其结构本身就是一次全面验证的范本需求合规矩阵REQ-001 到 REQ-008逐条给出证据如相似度阈值 0.7、查询长度 ≤1000 字符、结果上限 50 条组件级覆盖率表Agent Core 98%、Search Tools 97%、Dependencies 96%、CLI 94%、Integration 95%、Requirements 100%安全评估无硬编码凭证、参数化查询防 SQL 注入、输入消毒性能基准响应时间目标 3-5s、自动选型准确率 80%部署就绪清单环境变量、PGVector、依赖安装、连接池。这份报告的测试基建同样值得关注。tests/conftest.py展示了 Pydantic AI 的测试模式如何支撑创造性且全面的验证用TestModel快速迭代、用FunctionModel模拟受控的搜索行为、用AsyncMock隔离数据库与 OpenAI 客户端等外部依赖。而tests/test_agent.py则覆盖了初始化配置、空查询、超长查询、工具注册等边界与失败场景——这正是原文档要求的每个错误情况都应被验证的落地形态。关键原则不验证完所有东西就不停手原文档用一句强有力的话定义了这个命令的职责Your job is to create a validation command that leaves NO STONE UNTURNED.你的任务是创建一个不放过任何角落的验证命令。展开来说文档中的每一个用户工作流都应被端到端测试每一个外部集成都应被实际调用GitHub CLI、API 等每一个 API 端点都应被请求每一个错误场景都应被验证数据库完整性应被确认验证应彻底到手动测试完全多余。如果/validate通过用户就应对应用在生产环境中的正确运行有 100% 的信心。不要满足于部分覆盖——要让它全面、有创造力、完整。这条原则在本仓库的上下文工程实践中是自洽的根 CLAUDE.md 明确要求Always create Pytest unit tests for new features且测试需覆盖 expected use、edge case、failure case 三类——验证命令正是把这类规则从约定升级为可执行的门禁。输出物与适用边界命令最终将生成的验证命令写入.claude/commands/validate.md要求它可执行、务实、并给代码库以完整信心。请注意两个适用前提该方法是给Claude Code 这类支持自定义斜杠命令的 AI 编码助手设计的生成后的/validate依赖项目实际拥有的工具链lint、类型检查、格式化、测试框架因此五阶段中不存在的阶段应被省略E2E 的强度取决于项目文档对工作流的描述质量——文档越清晰地记录用户旅程验证命令就越能像真实用户那样测试应用。小结Ultimate Validate Command 不是一条普通的测试命令而是一套把生产信心工程化的方法论先读文档理解真实用户旅程再盘点工具链与架构最后生成一条从静态检查到完整 E2E 的一体化验证命令。配合仓库中的 example-validate.md 实例与rag_agent的 VALIDATION_REPORT.md 真实产物你可以立刻在自己的项目里复刻这套一条命令验证一切的工作流。赞分享文档教程提示工程人工智能【免费下载链接】context-engineering-introContext engineering is the new vibe coding - its the way to actually make AI coding assistants work. Claude Code is the best for this so thats what this repo is centered around, but you can apply this strategy with any AI coding assistant!项目地址https://gitcode.com/gh_mirrors/co/context-engineering-intro点击查看免费下载相关推荐Context Engineering 的终极验证命令用 /ultimate_validate_command 与 /validate 打造一键式全栈验证工作流Context Engineering 的终极验证命令用 /ultimate_validate_command 与 /validate 打造一键式全栈验证工作文档教程提示工程人工智能Husky终极指南5分钟打造前端代码质量守护体系 在现代前端开发中 代码质量保障 已成为项目成功的关键因素。Husky作为Git hooks的现代化解决方案能够帮助团队在提交代码前自动执行代码检查、测试和格开发工具版本控制PraisonAI Sandbox 端到端验证指南用一条命令与 pytest 守护 Agent 代码执行后端的可靠性PraisonAI Sandbox 端到端验证指南用一条命令与 pytest 守护 Agent 代码执行后端的可靠性 本文围绕 praisonai sandb人工智能AI AgentAgent 框架多智能体工作流自动化RAGMCP 服务创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考