构建 Mirmer AI：Kiro 如何将单人开发转变为 AI 驱动的协作

Source: Dev.to

挑战：复活 400 年的同行评审

当我着手构建 Mirmer AI 时，我想让这套已有数百年历史的同行评审流程以机器速度运行，并借助 AI 模型来实现。概念很简单，执行却很复杂：

1. 第 1 阶段 – 多个 AI 模型独立响应
2. 第 2 阶段 – 模型匿名互相进行同行评审
3. 第 3 阶段 – 主席模型合成共识

我是一名独立开发者，所以需要组装的技术栈包括：

• 使用异步编排的 FastAPI 后端
• 实时流式的 React 前端
• 支持双模式存储的 PostgreSQL 数据库
• 同步/异步客户端的 Python SDK
• 带浏览器认证的 CLI 工具
• 支付集成（Razorpay）
• Firebase 认证
• 在 Railway 和 Vercel 上部署

这项工作通常需要 2–3 个月，我只有几周时间。

进入 Kiro

Kiro 的优势：不仅是代码生成，更是架构设计

大多数 AI 编码助手只能帮助你编写单个函数。Kiro 帮我 为整个系统制定架构。

1. 引导规则：教会 Kiro 我的代码库

我在 .kiro/steering/ 目录下创建了三份引导文档。

tech.md – 技术栈概览

Backend: FastAPI, Python 3.10+, uv package manager
Frontend: React 18, Vite, Tailwind CSS
Database: PostgreSQL (production), JSON (dev)
Key Pattern: Dual‑mode storage with factory pattern
Critical: Always use "uv run" not "python" directly

structure.md – 项目架构

backend/
  main.py          # API routes
  council.py       # 3‑stage orchestration
  storage.py       # Factory pattern (auto‑selects backend)
  storage_postgres.py  # Production storage
  storage_json.py      # Dev storage
frontend/
  src/components/ # React components
  src/pages/      # Route pages
sdk/
  mirmer/          # Python SDK package

product.md – 业务与功能理由

Core: 3‑stage council process (parallel queries → peer review → synthesis)
Business: Free (10/day), Pro (100/day), Enterprise (unlimited)
Key Feature: Real‑time streaming via SSE

影响 – 引导规则就位后，每次 Kiro 对话都会自动使用正确的约定（例如使用 uv run、从 storage.py 导入、遵循 3‑阶段模式），从而消除了整类架构错误。

2. 规格驱动开发：从想法到实现计划

对于复杂功能，我使用了 Kiro 的规格系统。下面是 Python SDK 的工作流。

第 1 阶段 – 需求 (requirements.md)

我让 Kiro “为 Python SDK 创建一个规格”。它生成了：

• 12 条用户故事及验收标准
• 技术术语词汇表
• 60+ 条符合 EARS 格式的可测试需求

需求示例：

User Story: As a developer, I want to stream council updates in real‑time

Acceptance Criteria:
1. WHEN a developer calls the stream method THEN the system SHALL yield updates as each stage progresses
2. WHEN Stage 1 completes THEN the system SHALL yield an event containing all individual model responses
3. WHEN streaming encounters an error THEN the system SHALL yield an error event with details

第 2 阶段 – 设计 (design.md)

Kiro 生成了：

• 完整的架构及数据流图
• 带方法签名的组件接口
• 20 条用于属性测试的正确性属性
• 错误处理策略
• 测试方案（单元、属性、集成）

正确性属性 示例：

• “对于任何 API 请求，x-user-id 头必须包含 API 密钥”
• “对于任何订阅付款，等级应更新为 pro”
• “对于任何流式请求，事件必须按顺序出现：stage1_start → stage1_complete → stage2_start …”

这些属性被转化为 Hypothesis 属性测试，每个运行 100+ 次迭代。

第 3 阶段 – 任务 (tasks.md)

Kiro 将工作拆分为细粒度的任务单：

- [ ] 1. Set up project structure and packaging
- [ ] 2. Implement core data models
  - [ ] 2.1 Create Pydantic models for all data structures
  - [ ]* 2.2 Write property test for response structure validation
- [ ] 3. Implement synchronous Client class
  - [ ] 3.1 Create Client with initialization and configuration
  - [ ]* 3.2 Write property test for API key security

* 标记可选的测试任务，便于先聚焦核心功能。

结果 – SDK 规格在投产前捕获了三个 bug。任务把原本需要三天完成的功能切分为一小时的块，且保留的规格文件让即使几周后暂停也能无缝恢复上下文。

3. 代理钩子：自我改进的代码库

我定义了六个代理钩子，用来自动化日常开发任务。

API 函数生成器 – 在后端文件编辑时触发

When I write a new API function, Kiro automatically generates:
- FastAPI route decorator
- Pydantic validation schema
- Error‑handling boilerplate
- Example request body

自动文档代码 – 在任意代码文件编辑时触发

Kiro adds docstrings/JSDoc to every function automatically.
No more “I’ll document this later” – it happens in real‑time.

自动生成测试 – 与函数创建同步触发

For each new function, Kiro creates:
- Unit test skeleton
- Property‑based test template (if a correctness property exists)
- Mock data fixtures

依赖更新器 – 在 requirements.txt 变更时运行

Kiro checks for newer package versions, runs the test suite, and creates a pull request if all checks pass.

CI/CD 优化器 – 每次推送后运行

Kiro analyses test coverage, suggests flaky‑test mitigations, and updates the GitHub Actions workflow accordingly.

文档发布器 – 在发布标签时运行

Kiro builds the MkDocs site, uploads it to the hosting provider, and posts a release note with changelog highlights.

这些钩子让代码库成为自我维护的系统，极大地降低了人工开销。

收获

• 引导规则 为 AI 助手提供持久上下文，免去重复说明。
• 规格驱动开发 把高层想法转化为可落地的实现方案，提前捕获缺陷。
• 代理钩子 自动化重复性工作，使单人开发者能够在数周内完成生产级的多 LLM 平台，而非数月。