我有两个解决同一问题的项目。我把它们合并并在一天内发布到 npm

请提供您希望翻译的正文内容，我才能为您进行简体中文翻译。

管理跨 AI 编码工具的上下文规则

问题:
每个 AI 编码工具都有自己定义上下文规则的方式。

• Claude Code → CLAUDE.md
• Cursor → .cursor/rules
• Gemini CLI → GEMINI.md

当你使用多个工具时，同样的内容会出现在三个不同的位置，格式略有差异，你会不断地面对同步问题。

两个平行的尝试

两者都在尝试解决 相同 的问题，但一个 代码太多，另一个 文档太多。

文档陷阱

我最终为一个尚未存在的 CLI 创建了五个 markdown 文件：

• VISION_GENERAL.md
• ARCHITECTURE.md
• ROADMAP.md
• DECISIONS.md
• CLI_SPEC.md

这些文档看起来很有成效，但它们只是推迟编写第一行代码的一种方式。

教训： 如果你无法用一个段落解释这个项目，问题在于缺乏清晰度，而不是缺少文档。

前进的路径选择

我保留了一个项目——CLI——原因有三：

1. 结构性问题： 编辑器之间重复的规则不会消失；每个编辑器都需要自己的格式。
2. 互补性： CLI 与原生编辑器功能协同工作，而 Web 应用则与之竞争。
3. 即时验证： 如果 CLI 在真实项目中可用，你就知道它有效。Web 应用需要经过用户引导和留存后才能判断。

Web 应用的基础设施（MCP、Supabase、版本控制）可以成为未来的“专业版”层级，但目前的重点是一个可工作、可安装的工具。

我把文档精简为两个核心文件：

• CLI_SPEC.md – 实现合同（规范）。
• DECISIONS.md – 决策日志。

其他所有文件均已删除。

使用 Claude Code 构建 CLI

Sprint 1 – 核心（上午）

1. 脚手架 – 让 Claude Code 生成：

   • package.json
   • tsconfig.json
   • 基于 commander 的 CLI，带有存根命令

   结果： 几分钟内完成。

2. 实现 devw init – 检测项目，运行交互式提示，创建 .dwf/ 文件夹结构。

3. 实现 devw compile – 产品的核心：

   • 解析 YAML 规则文件。
   • 三个 桥接器（Claude、Cursor、Gemini）各自翻译为原生格式。
   • 生成相应的上下文文件。

4. 实现 devw doctor – 验证一切是否就绪。

Sprint 2 – 模块（中午）

添加了 预制模块系统：

• devw add typescript-strict – 将严格的 TypeScript 规则注入 YAML。
• 注册表、安装器以及 6 个内容模块。
• 命令：add、remove、list。
• 测试： 通过 17 项。

Sprint 3 – 发布（下午）

• 添加了 README、npm 发布配置以及 GitHub Actions CI。
• 集成 changesets 实现自动化发布。
• 自用测试： 在其自身仓库上运行 dev‑workflows。

自用测试中发现的 Bug

这三个 Bug 仅通过实际使用才能暴露，单靠测试是发现不到的。

日终结果

• 已发布 在 npm (dev‑workflows)。
• 命令（6）: init, compile, doctor, add, remove, list。
• 桥接（3）: Claude Code, Cursor, Gemini CLI。
• 预设规则块（6）: TypeScript, React, Next.js, Tailwind, testing, Supabase。
• 测试: 通过 54+。
• 持续集成（CI）: GitHub Actions。
• 发布: 通过 changesets 自动化。

快速使用

# Initialise a project
npx dev-workflows init

# Add a rule block (e.g., strict TypeScript)
npx dev-workflows add typescript-strict

# Generate the context files for each editor
npx dev-workflows compile

一次在 YAML 中定义规则 → 为每个编辑器编译。
更改规则后，重新运行 compile。如果有问题，devw doctor 会告诉你。

Reflections

• Documentation before code can be procrastination in disguise. → 文档先于代码 可能是伪装的拖延。
• A concise spec is enough for AI to implement a functional product. → 一个 简洁的规格说明 足以让 AI 实现一个可用的产品。
• Dogfooding uncovers issues that tests never anticipate. → 自用 能发现测试永远无法预料的问题。
• Ship first, polish later. Hard‑coded values, basic prompts, and a simple block system are fine as long as the tool is usable. Publishing early is the fastest way to validate the idea. → 先发布，后打磨。 只要工具可用，硬编码的值、基本的提示和简单的块系统都可以。提前发布是验证想法的最快方式。

What’s Next?

• More bridges – Windsurf、Copilot 和其他使用上下文文件的编辑器。
• Remote block registry – 社区贡献的规则块。
• Watch mode – 在 .dwf/ 更改时自动重新编译。
• Custom scopes – 超出五个内置类别的分类。
• Pro webapp – 用于管理规则的可视化 UI（未来层级）。

dev‑workflows 目前已达到 v0.1 – 功能完整，已在我自己的项目中使用，并准备接受社区反馈。

Dev‑Workflows

一个 面向团队的界面，用于管理 AI 编码工具，支持版本控制和同步。
如果你使用多个 AI 编码工具，并且厌倦了在它们之间维护重复的规则，试试看：

npx dev-workflows init

软件包

• npm:
• GitHub:
• 许可证: MIT

如果你发现了 bug 或有想法，请提交 issue。该项目正在公开构建。

要求: Node.js ≥ 22.