1. 项目概述与核心价值

如果你最近在深度使用 Claude、Cursor 或者 GitHub Copilot 这类 AI 编程助手，大概率经历过一种“甜蜜的烦恼”：AI 助手确实很聪明，能快速生成代码，但它也像一个精力过于旺盛、缺乏管束的实习生。它可能一天之内给你重复安装了 14 个 VS Code 扩展，创建了 6 个永远不会清理的 Docker 容器，然后你的磁盘空间就从 12GB 可用直接掉到了 0KB。更糟糕的是，磁盘满了之后，整个开发环境会以一种极不优雅的方式崩溃——VS Code、终端、Docker 甚至数据库服务可能同时挂掉，让你半天的工作进度瞬间归零。

ForgeCraft 就是为了解决这个问题而生的。它不是一个运行时框架，而是一个“质量契约”生成器。你可以把它理解为你和 AI 助手之间的一份“开发规范合同”。它的核心目标很明确： 让 AI 助手在保持高效构建的同时，遵循一套清晰、可执行、可验证的工程标准，从而避免“烧毁房子”式的开发混乱。 简单来说，它把资深工程师的架构直觉、代码洁癖和项目治理经验，编码成一套 AI 能理解和执行的规则，注入到你的项目中。

我最初接触 ForgeCraft 是因为团队里不同成员使用不同 AI 工具（有人用 Claude，有人用 Cursor），导致项目风格、测试策略甚至目录结构都开始出现“方言化”的苗头。ForgeCraft 提供了一个统一的、基于“生成式规范”模型的解决方案。它通过分析你的项目，自动生成针对 Claude、Cursor、GitHub Copilot、Windsurf、Cline、Aider 等主流 AI 助手的定制化指令文件，确保无论谁、用什么工具，都在同一个质量框架下协作。

1.1 核心价值：从“提示词工程”到“规范即代码”

传统的 AI 助手协作模式，严重依赖工程师个人的“提示词工程”水平。你需要写很长的 CLAUDE.md 或者 .cursor/rules 文件，试图告诉 AI 你的项目结构、编码规范、测试要求等等。这带来几个问题：

1. 不一致性 ：每个项目、每个工程师的提示词文件都不同，质量参差不齐。
2. 维护成本高 ：随着项目演进，你需要手动更新这些冗长的文档，很容易遗漏。
3. 难以度量 ：你无法量化 AI 助手到底在多大程度上遵守了你的规范，只能凭感觉。

ForgeCraft 将这种模式升级为“规范即代码”。它定义了一个包含 7 个属性的 “生成式规范”模型 。这 7 个属性不是模糊的“感觉”，而是可以量化的、得分为 0-2 分的具体指标。运行 npx forgecraft-mcp verify . ，你会得到一个清晰的计分板：

| Property        | Score | Evidence                                        |
|-----------------|-------|-------------------------------------------------|
| Self-Describing | ✅ 2/2 | CLAUDE.md — 352 non-empty lines                |
| Bounded         | ✅ 2/2 | No direct DB calls in route files              |
| Verifiable      | ✅ 2/2 | 64 test files — 87% coverage                   |
| Defended        | ✅ 2/2 | Pre-commit hook + lint config present           |
| Auditable       | ✅ 2/2 | 11 ADRs in docs/adrs/ + Status.md              |
| Composable      | ✅ 2/2 | Service layer + repository layer detected       |
| Executable      | ✅ 2/2 | Tests passed + CI pipeline configured           |

这个总分 14 分的模型，让你能一眼看出项目的质量短板在哪里。比如“Bounded”（有界性）得分低，说明业务逻辑泄露到了路由层；“Auditable”（可审计性）得分低，说明架构决策没有记录。这种基于证据的度量，比任何“代码感觉”都更有说服力。

1.2 它解决了谁的痛点？

ForgeCraft 主要服务于三类开发者：

1. AI 辅助开发的团队负责人 ：你需要确保团队在引入 AI 后，代码质量不下滑，架构不腐化。ForgeCraft 提供了一套可强制执行、可审计的团队标准。
2. 全栈或独立开发者 ：你希望 AI 助手能像一个靠谱的结对编程伙伴，而不是一个需要你时刻盯着、收拾烂摊子的“熊孩子”。ForgeCraft 能帮你建立个人或小团队的高效、整洁的开发工作流。
3. 从零启动新项目的工程师 ：你不想在项目初期花费大量时间搭建规范、写冗长的 AI 指令。ForgeCraft 能基于你的技术栈（通过标签系统识别），在几秒钟内生成一套生产就绪的工程化脚手架。

它的使用门槛很低，一个命令 npx forgecraft-mcp setup . 就能开始。但它带来的价值，尤其是在项目规模扩大和团队协作场景下，是指数级增长的。接下来，我会深入拆解它的核心设计、实操细节以及我踩过的一些坑。

2. 核心设计：生成式规范与质量门禁

ForgeCraft 的底层逻辑建立在两个核心概念上： 生成式规范模型 和 质量门禁 。理解这两点，你就能明白它为什么能有效约束 AI 助手的行为。

2.1 生成式规范模型详解

这个模型包含 7 个属性，每个属性都对应一个可验证的工程实践。它不是 ForgeCraft 发明的，而是基于软件工程经典原则，为 AI 生成代码这一特定场景做的具象化。

1. 自描述性

• 检查什么 ：代码库能否在不依赖你的口头解释下，向 AI 助手（或新成员）清晰地说明自身？核心证据是存在一个详尽、非空的 CLAUDE.md （或同类）指令文件。
• 实操要点 ：ForgeCraft 生成的指令文件不是模板套话。它会根据你的项目标签（如 API , WEB-REACT ）注入具体的、可操作的规则。例如，对于一个 API 项目，它会明确要求“所有路由处理器必须返回标准化的响应 DTO，错误必须使用项目定义的 AppError 类抛出”。

2. 有界性

• 检查什么 ：代码的层次边界是否清晰？业务逻辑是否泄露到了不该在的地方？最典型的反例就是在 Express.js 的路由文件里直接写数据库查询。
• 实操要点 ：ForgeCraft 会通过静态分析（简单的模式匹配）来检测这类“层违规”。它会指导 AI 助手遵循“控制器-服务-仓储”的分层模式。对于检测到的违规，它会提供具体的修复工作流（如“将数据库调用移至服务层”）。

3. 可验证性

• 检查什么 ：代码是否有测试，并且这些测试是否在一个真实的运行时环境中通过？它不只检查测试文件是否存在，还会尝试运行 npm test 或 pytest 来获取真实的测试通过率和覆盖率。
• 我的经验 ：这里有个细节需要注意。ForgeCraft 在 verify 阶段会 实际运行测试 。如果你的测试套件需要复杂的环境（如特定的数据库），可能会失败。建议在项目早期就配置好一个能在 CI 环境中独立运行的测试套件，或者使用 jest --testPathPattern 来隔离运行核心单元测试。

4. 防御性

• 检查什么 ：是否有自动化机制在糟糕的代码进入仓库之前就将其拦截？核心证据是预提交钩子（pre-commit hooks）和代码检查配置的存在与生效。
• 实操要点 ：ForgeCraft 会自动在 .claude/hooks/ 目录下生成可执行的钩子脚本。例如，一个检查硬编码密钥的钩子。你需要手动将这些钩子链接到 Git 的钩子目录（ ln -s .claude/hooks/* .git/hooks/ ），或者使用类似 Husky 的工具来管理。

5. 可审计性

• 检查什么 ：每一个重要的架构决策是否都被记录在案，并且易于查找？这通过 docs/adrs/ （架构决策记录）目录和 Status.md （项目状态跟踪）文件来体现。
• 我的经验 ：ADRs 是项目宝贵的知识资产。ForgeCraft 提供了 generate_adr 命令，能帮你用标准格式快速创建 ADR。关键在于养成习惯：每当 AI 助手（或你自己）做出一个非显而易见的选择时（比如“为什么用事件溯源而不是 CRUD？”），就立刻生成一条 ADR。这能极大减少未来的技术债务争论。

6. 可组合性

• 检查什么 ：核心业务逻辑是否与外部依赖（如数据库、第三方 API）解耦？你是否能在不触及领域逻辑的情况下更换数据库？
• 实操要点 ：这通过检查是否存在清晰的“端口与适配器”（六边形架构）模式来实现。ForgeCraft 会寻找 repository 层或 adapter 层的目录结构，并确保 service 层只依赖于抽象接口。

7. 可执行性

• 检查什么 ：项目是否处于一个“可运行”的状态？是否有 CI/CD 流水线的配置证据，并且最近一次构建是成功的？
• 实操要点 ：它会检查 package.json 中的 scripts 是否包含 start 、 build 、 test 等标准命令，并会查找 .github/workflows 或 .gitlab-ci.yml 等 CI 配置文件。即使项目初期没有 CI，确保 npm run build 和 npm start 能正常工作也能拿到这部分分数。

这 7 个属性共同构成了一个完整的质量闭环。它从“文档与理解”（自描述、可审计）开始，到“设计与实现”（有界、可组合），再到“验证与交付”（可验证、防御、可执行）。ForgeCraft 将这个理论模型转化为了一个可以运行、可以打分的 CLI 工具。

2.2 质量门禁：将规范嵌入开发流程

规范模型是静态的“体检表”，而质量门禁则是动态的“检查站”。ForgeCraft 的质量门禁是一系列结构化的、通过/失败式的检查点，由你的 AI 助手在开发流程的关键时刻自动执行。

门禁不是简单的代码检查。一个典型的门禁包含三个要素：

1. 条件 ：何时触发检查？（例如：提交前、发布前、部署后）
2. 证据 ：如何证明通过了检查？（例如：单元测试通过率 > 90%，安全扫描无高危漏洞）
3. 人工审查标志 ：某些关键门禁（如安全审计）是否必须由人工确认？

ForgeCraft 将门禁按发布阶段组织，避免了在项目初期就执行不切实际的严格检查：

阶段	示例门禁
开发阶段	单元测试通过 · 代码检查通过 · 无层违规 · 无硬编码密钥
预发布加固阶段	变异测试覆盖率 ≥80% · 动态应用安全测试扫描 · 2倍峰值负载测试 · 混沌测试
发布候选阶段	OWASP Top 10 渗透测试 · 完整的变异测试审计 · 兼容性矩阵验证 · 无障碍访问检查
部署阶段	金丝雀发布配置已验证 · 冒烟测试通过 · 可观测性配置确认
部署后阶段	合成监控探针已上线 · 30分钟错误窗口监控 · 事故应急预案已审阅

我的实操心得 ：不要试图一次性启用所有门禁。ForgeCraft 的智慧在于它的阶段性。在项目早期，我只启用“开发阶段”的门禁。当项目趋于稳定，准备第一次对外发布时，我再通过 npx forgecraft-mcp add-hook pre-release-hardening . 来添加“预发布加固”阶段的门禁。这种渐进式的方式，既保证了质量，又不会在初期带来过重的负担。

注意 ：门禁的检查逻辑通常以脚本形式存在于 .claude/hooks/ 目录下。你需要确保这些脚本在你的开发环境中能够正确执行（例如，安装了必要的 CLI 工具）。如果某个门禁检查失败，AI 助手会收到明确的指令，并参考 WORKFLOWS.md 中对应的修复流程进行操作。

3. 实操流程：从零搭建一个受控的 AI 协作项目

理论讲完了，我们动手实操。假设我们要创建一个新的 TypeScript API 服务项目，并让 Claude 和 Cursor 在 ForgeCraft 的规范下协助我们开发。

3.1 初始化与项目分析

首先，创建一个新目录并初始化一个简单的 Node.js 项目骨架。

mkdir my-ai-backed-api && cd my-ai-backed-api
npm init -y
npm install typescript ts-node @types/node express --save-dev
# 创建一个最简单的入口文件，让 ForgeCraft 有东西可分析
echo "console.log('Hello ForgeCraft');" > index.ts

接下来，运行 ForgeCraft 的初始化命令。这是最关键的一步。

npx forgecraft-mcp setup .

这个命令背后发生了很多事情：

1. 分析阶段 ：ForgeCraft 会扫描你的目录结构、 package.json 、现有代码文件，试图理解你的项目类型。对于我们的空项目，它主要依据 package.json 里的 express 依赖，推断出这是一个 API 项目。
2. 校准阶段 ：如果你在支持 MCP 的 AI 助手（如 Claude Desktop）中运行此命令，助手会介入，让你确认或调整它推断出的项目标签。在纯 CLI 模式下，它会直接使用推断结果。
3. 生成阶段 ：根据确定的标签（如 [UNIVERSAL, API] ）和默认的 recommended 层级，ForgeCraft 开始从它的模板库中选取并组合代码块，生成一系列文件。

生成的核心文件包括 ：

• forgecraft.yaml : 项目配置文件，存储了标签、层级等元数据。
• CLAUDE.md : 给 Claude 使用的、极其详细的工程规范指令文件。
• .cursor/rules/ 目录：包含给 Cursor AI 使用的规则文件。
• .github/copilot-instructions.md : 给 GitHub Copilot 的指令。
• Status.md : 项目状态跟踪文件，用于记录当前工作焦点、下一步行动等，保证 AI 会话间的连续性。
• docs/ 目录：包含 PRD.md （产品需求文档骨架）、 TechSpec.md （技术规格文档骨架）以及 adrs/ （架构决策记录）目录，其中已经创建了 ADR-000-use-forgecraft.md 。
• .claude/hooks/ 目录：预置的质量门禁钩子脚本。
• src/shared/ 目录：一些通用的启动器代码，如配置加载器、自定义错误类、日志工具。

第一次运行 verify ： 生成完成后，立即运行验证命令，看看我们的“空白画布”能得多少分。

npx forgecraft-mcp verify .

输出可能会显示一个中等分数（比如 6/14）。扣分项可能包括： Status.md 未更新（可审计性）、测试不存在（可验证性）、CI 配置缺失（可执行性）。这完全正常，它为我们指明了初始的努力方向。

3.2 与 AI 助手协同开发

现在，打开你的 AI 助手（比如 Claude Desktop），确保它已经加载了当前项目。由于我们生成了 CLAUDE.md ，Claude 在回答任何关于本项目的问题时，都会优先参考这份长达数百行的详细规范。

你可以尝试给 AI 一个简单的任务：

“在 src/ 目录下，遵循项目规范，创建一个简单的用户管理模块。需要包含用户模型、仓储层、服务层和 RESTful 控制器。同时为服务层编写单元测试。”

观察 AI 的行为。一个未经训练的 AI 可能会直接把数据库查询写在控制器里。但在 ForgeCraft 生成的指令约束下，AI 会：

1. 首先检查 CLAUDE.md 中关于“有界性”和“可组合性”的规则。
2. 遵循“端口与适配器”模式，创建 src/domain/User.ts （实体）、 src/application/services/UserService.ts （服务）、 src/infrastructure/repositories/UserRepository.ts （仓储）和 src/api/controllers/UserController.ts （控制器）。
3. 在创建控制器时，它会注入服务层，而不是直接调用仓储。
4. 在编写 UserService 的测试时，它会查看指令中关于“测试金字塔”和“测试替身”的部分，可能会使用 Jest 的 mock 功能来隔离仓储依赖。

开发流程中的关键节点 ：

• 提交代码前 ：AI 会尝试运行 .claude/hooks/pre-commit 中定义的检查（如代码风格、运行测试）。如果失败，它会根据 WORKFLOWS.md 中的指引尝试修复。
• 架构决策时 ：当你或 AI 决定采用一种新技术或模式（比如“我们是否用 Redis 做缓存？”），你应该运行 npx forgecraft-mcp generate_adr . --title "引入 Redis 作为缓存层" ... 来记录这个决策。这个 ADR 会成为项目知识库的一部分，未来 AI 或其他成员都能查阅。
• 项目范围变更时 ：如果你中途决定给项目添加一个 React 前端，你需要运行 npx forgecraft-mcp refresh . 。ForgeCraft 会重新分析项目，发现新增的 react 依赖，并提示你是否添加 WEB-REACT 标签。确认后，它会重新生成指令文件，将前端开发的最佳实践（如组件设计、状态管理、性能预算）也融入其中。

3.3 配置详解与定制化

ForgeCraft 的强大之处在于它的可配置性。 forgecraft.yaml 是控制这一切的核心。

# forgecraft.yaml 示例
projectName: my-ai-backed-api
tags: [UNIVERSAL, API, FINTECH]  # 手动添加了 FINTECH 标签
tier: recommended  # 核心层，推荐层，可选层
outputTargets: [claude, cursor]  # 只为 Claude 和 Cursor 生成指令
compact: true  # 生成精简版指令，节省 Token

# 排除某些你可能还不需要的复杂模式
exclude:
  - cqrs-event-patterns
  - saga-pattern

# 覆盖默认变量
variables:
  coverage_minimum: 85  # 将测试覆盖率要求从默认的 90% 降至 85%
  max_file_length: 300  # 单个文件最大行数限制
  api_version_prefix: '/v1'  # 定义 API 版本前缀，指令中会引用此变量

标签系统深度解析 ： ForgeCraft 的 24 个标签是其智能化的核心。每个标签都关联着一套具体的、领域相关的规则块。例如：

• FINTECH 标签会加入关于金融精度（使用 decimal.js 而非 number ）、双重记账原则、合规性检查的规则。
• HEALTHCARE 标签会强制加入 HIPAA 相关规则，如 PHI（受保护健康信息）处理、加密审计日志等。
• GAME 标签会引入游戏循环、实体组件系统模式以及针对 Phaser/PixiJS/Three.js 的性能优化建议。

你可以通过 npx forgecraft-mcp list tags 查看所有标签，通过 npx forgecraft-mcp classify . 让工具分析现有代码并推荐标签。

层级选择策略 ：

• core ：仅包含代码风格、基础测试和提交规范。适用于原型或极其简单的项目。
• recommended （默认）：在 core 基础上，增加架构模式、CI/CD、整洁代码和部署规范。适用于绝大多数生产项目。
• optional ：在 recommended 基础上，增加领域驱动设计、CQRS、事件溯源等高级模式。仅适用于有复杂领域逻辑且团队经验丰富的项目。

我的建议是， 始终从 recommended 开始 。它提供的架构约束（如分层）能从一开始就避免项目结构腐化，成本几乎为零。

4. 高级技巧、常见问题与避坑指南

在实际使用 ForgeCraft 几个月后，我积累了一些在官方文档中未必会明确写出的经验和需要警惕的“坑”。

4.1 开发环境治理：不仅仅是规则

ForgeCraft 在指令文件中内置了强大的“开发环境卫生”规则，这是防止文章开头提到的“磁盘爆满”问题的关键。这些规则非常具体：

• VS Code 扩展 ：在安装任何扩展前，AI 必须执行 code --list-extensions | grep -i <name> 检查是否已安装。同一天内不允许重复下载同一扩展。
• Docker 容器 ：创建容器前必须检查是否存在同名容器 ( docker ps -a --filter name=<service> )。优先使用 docker-compose up （重用）而非 docker run （总是新建）。日志总量限制在 500MB。 docker system prune -f 被记录为定期维护步骤，而非紧急清理命令。
• Python 虚拟环境 ：一个项目根目录只允许一个 .venv 。如果 Python 主次版本匹配，则复用。除非是独立的可安装包，否则禁止在子目录创建 venv。
• 磁盘空间守卫 ：如果工作区（排除 node_modules , .venv , dist 等已知构建产物）体积增长超过 2GB，AI 必须发出警告并停止操作。

我的心得 ：这些规则的有效性，高度依赖于 AI 助手对指令的遵循程度。Claude 和 Cursor 对此类结构化指令的遵循性很好。但 Copilot 等更“轻量”的助手，可能不会完整解析这么长的规则。因此， 定期运行 npx forgecraft-mcp audit . 进行审计至关重要 。审计报告会明确指出哪些规则被违反。

4.2 MCP 哨兵：用与不用的艺术

ForgeCraft 提供了一个可选的 MCP 服务器（哨兵）。它的设计非常巧妙： 它只暴露一个工具，这个工具只做一件事——读取 forgecraft.yaml 、 CLAUDE.md 和 .claude/hooks ，然后根据项目当前状态，推荐一个正确的 CLI 命令。

# 添加哨兵到 Claude Desktop
claude mcp add forgecraft -- npx -y forgecraft-mcp

为什么要用这个极简的哨兵？ 因为每个在 MCP 中声明的工具，无论是否被调用，都会在每次对话时被模型读取，消耗 Token。一个完整的工具套件可能消耗 1500+ Token，而这个单功能哨兵只消耗约 200 Token。这完美践行了其自身倡导的“有界性”原则。

我的工作流建议 ：

1. 在项目初始化或需要重大调整时，添加哨兵。让 AI 助手运行 setup 、 refresh 或 audit 。
2. 一旦指令文件生成完毕， 立即移除哨兵 ( claude mcp remove forgecraft )。在常规编码阶段，你并不需要 AI 来调用 ForgeCraft 命令。
3. 当项目发生较大变化，或者你需要进行质量审计时，再临时加回来。

这样既能享受 AI 辅助配置的便利，又能将绝大部分 Token 预算留给实际的编码任务。

4.3 处理遗留项目（棕地整合）

将 ForgeCraft 引入一个已有大量代码的遗留项目，需要一些策略。

1. 渐进式整合 ：不要一开始就追求满分。运行 npx forgecraft-mcp setup . 后，先接受一个较低的初始分数。ForgeCraft 的 convert 命令可以生成一个分阶段的迁移计划。
2. 重点突破 ：使用 npx forgecraft-mcp audit . 找出最严重的问题。通常是 hardcoded_credential （硬编码凭证）和 layer_violation （层违规）。按照 WORKFLOWS.md 中的指引，优先修复这些安全问题和高层架构问题。
3. 利用 exclude 配置 ：如果项目暂时无法达到某些高级模式（如完整的 DDD），可以在 forgecraft.yaml 的 exclude 列表中暂时排除相关规则块，避免 AI 产生不切实际的建议。
4. “外科手术”式刷新 ：使用 npx forgecraft-mcp refresh . --apply 时，ForgeCraft 会尝试合并你的更改。但对于复杂的遗留代码，建议先使用 --dry-run 预览更改，并手动审查差异，特别是对现有 CLAUDE.md 的修改。

4.4 常见问题与解决方案

Q1: 运行 npx forgecraft-mcp verify . 时测试失败，导致可验证性得分为 0。

• 原因 ： verify 命令会实际运行测试命令。如果你的测试需要外部服务（如数据库），而本地没有启动，就会失败。
• 解决 ：
  • 方案A（推荐） ：配置一个可以在内存中或使用测试双倍（如 SQLite）运行的独立测试套件。确保 npm test 或 pytest 命令在隔离环境下能成功。
  • 方案B ：暂时调整 ForgeCraft 的检查逻辑。但这需要修改模板，不推荐新手操作。
  • 方案C ：接受这个扣分，但通过其他属性（如完善的测试文件存在）来体现你对质量的关注。 verify 是诊断工具，不是绝对标准。

Q2: 生成的 CLAUDE.md 文件太长，导致 AI 助手上下文窗口被占满。

• 原因 ：默认的 recommended 层级包含了大量内容。
• 解决 ：
  • 在 forgecraft.yaml 中设置 compact: true ，可以缩减 20-40% 的篇幅。
  • 将 tier 设置为 core ，仅保留最基础的规则。
  • 在 exclude 列表中移除你确定不需要的标签对应的规则块。
  • 手动编辑 CLAUDE.md ，删除或简化你认为过于冗长的部分。但要注意，这会影响后续 refresh 命令的自动合并。

Q3: 团队中有人不用 AI 助手，ForgeCraft 是否还有价值？

• 绝对有 。即使抛开 AI 部分，ForgeCraft 生成的也是一套极其优秀的、立即可用的工程规范、项目脚手架和自动化脚本集合。 docs/ 目录下的文档模板、预提交钩子、清晰的目录结构，对任何团队都是宝贵的资产。它统一了项目的“宪法”，无论贡献者是人还是 AI。

Q4: 如何贡献新的质量门禁或模板？

• ForgeCraft 的模板和门禁库是开源的，采用 YAML 格式，贡献门槛很低。
• 如果你想为 GAME 标签添加一个“确保每帧渲染时间低于 16ms”的性能门禁，你只需要在对应的 templates/game/hooks.yaml 中添加一个新的钩子定义，然后提交 PR。
• 模板结构清晰，在 templates/universal/ 下有完整示例。你的贡献会被列入 CONTRIBUTORS.md 。

Q5: 与已有的 ESLint/Prettier/Husky 配置冲突怎么办？

• ForgeCraft 生成的钩子和规则旨在 补充 而非替换现有工具。例如，它生成的预提交钩子可能会调用你已有的 npm run lint 和 npm run test 脚本。
• 如果发生冲突（比如同时有两个 .prettierrc 文件），ForgeCraft 在 setup 或 refresh 时会提示你。你可以选择手动合并配置，或者决定以哪一个为准。通常，我会选择保留团队原有的核心配置，让 ForgeCraft 补充那些 AI 协作特有的规则（如开发环境卫生）。

ForgeCraft 代表了一种新的范式：不是让人去适应 AI，也不是让 AI 野蛮生长，而是建立一套人机共同遵守的、可度量的高质量工程契约。它可能不是银弹，但对于任何严肃考虑在团队中规模化、可持续地使用 AI 编程助手的组织来说，它是一个不可或缺的基础设施。从今天起，让你的 AI 助手在一个不会“烧毁房子”的坚固框架内，尽情发挥它的创造力。