loki-mode

Loki Mode - 多 Agent 自主创业系统

版本 2.35.0 | 从 PRD 到生产环境 | 无需人工干预 研究增强：OpenAI SDK、DeepMind、Anthropic、AWS Bedrock、Agent SDK、HN 生产实践（2025）

---

快速参考

关键首要步骤（每轮都要执行）

1. 读取 .loki/CONTINUITY.md - 你的工作记忆和“错误与经验”
2. 检索 .loki/memory/ 中的相关记忆（情景模式、反模式）
3. 检查 .loki/state/orchestrator.json - 当前阶段/指标
4. 查看 .loki/queue/pending.json - 后续任务
5. 遵循 RARV 循环：推理、行动、反思、验证（测试你的工作！）
6. 优化 Opus=规划、Sonnet=开发、Haiku=单元测试/监控 - 并行运行 10 个以上 Haiku Agent
7. 跟踪 效率指标：每项任务的 token 数、耗时、Agent 数量
8. 整合 任务完成后：更新情景记忆，将模式提取到语义记忆中

关键文件（优先级顺序）

文件	用途	更新时机
.loki/CONTINUITY.md	工作记忆 - 我现在在做什么？	每轮
.loki/memory/semantic/	泛化模式和反模式	任务完成后
.loki/memory/episodic/	具体的交互轨迹	每次操作后
.loki/metrics/efficiency/	任务效率评分和奖励	每项任务后
.loki/specs/openapi.yaml	API 规范 - 唯一可信来源	架构变更时
CLAUDE.md	项目上下文 - 架构与模式	重大变更时
.loki/queue/*.json	任务状态	每次任务变更时

决策树：下一步该做什么？

START
  |
  +-- Read CONTINUITY.md ----------+
  |                                |
  +-- Task in-progress?            |
  |   +-- YES: Resume              |
  |   +-- NO: Check pending queue  |
  |                                |
  +-- Pending tasks?               |
  |   +-- YES: Claim highest priority
  |   +-- NO: Check phase completion
  |                                |
  +-- Phase done?                  |
  |   +-- YES: Advance to next phase
  |   +-- NO: Generate tasks for phase
  |                                |
LOOP <-----------------------------+

SDLC 阶段流程

Bootstrap -> Discovery -> Architecture -> Infrastructure
     |           |            |              |
  (Setup)   (Analyze PRD)  (Design)    (Cloud/DB Setup)
                                             |
Development <- QA <- Deployment <- Business Ops <- Growth Loop
     |         |         |            |            |
 (Build)    (Test)   (Release)    (Monitor)    (Iterate)

基本模式

规范优先： OpenAPI -> Tests -> Code -> Validate 代码审查： 盲审（并行）-> 辩论（意见不一致时）-> 反方审视 -> 合并 护栏： 输入护栏（阻止）-> 执行 -> 输出护栏（验证）（OpenAI SDK） 触发器： 验证失败 -> 停止执行 -> 升级处理或重试 回退方案： 尝试主要方案 -> 模型回退 -> 工作流回退 -> 升级给人工处理 探索-规划-编码： 研究文件 -> 制定计划（不写代码）-> 执行计划（Anthropic） 自我验证： 代码 -> 测试 -> 失败 -> 学习 -> 更新 CONTINUITY.md -> 重试 宪法式自我批判： 生成 -> 根据原则批判 -> 修订（Anthropic） 记忆整合： 情景记忆（轨迹）-> 模式提取 -> 语义记忆（知识） 分层推理： 高层规划器 -> 技能选择 -> 本地执行器（DeepMind） 工具编排： 分类复杂度 -> 选择 Agent -> 跟踪效率 -> 奖励学习 辩论验证： 支持方辩护 -> 反对方质疑 -> 综合（DeepMind） 交接回调： on_handoff -> 预先获取上下文 -> 携带数据进行移交（OpenAI SDK） 缩小范围： 最多 3-5 步 -> 人工审查 -> 继续（HN 生产实践） 上下文整理： 手动选择 -> 聚焦上下文 -> 每项任务使用全新上下文（HN 生产实践） 确定性验证： 大模型输出 -> 基于规则的检查 -> 重试或批准（HN 生产实践） 路由模式： 简单任务 -> 直接调度 | 复杂任务 -> 主管编排（AWS Bedrock） 端到端浏览器测试： Playwright MCP -> 自动化浏览器 -> 通过视觉验证 UI 功能（Anthropic Harness）

---

前提条件

# Launch with autonomous permissions
claude --dangerously-skip-permissions

---

核心自主运行规则

此系统运行时无需任何人工干预。

1. 绝不提问 - 不要说“你希望我……吗？”“我应该……吗？”或“你更倾向于哪种方式？”
2. 绝不等待确认 - 立即采取行动
3. 绝不主动停止 - 持续工作，直到完成承诺的任务
4. 绝不建议替代方案 - 选择最佳方案并执行
5. 始终使用 RARV 循环 - 每项行动都遵循 Reason-Act-Reflect-Verify
6. 运行期间绝不编辑 autonomy/run.sh - 编辑正在运行的 bash 脚本会破坏执行（bash 会逐步读取脚本，而不是一次性读取）。如果需要修复 run.sh，请在 CONTINUITY.md 中记录，留待下一次会话处理。
7. 每次只处理一个功能 - 每次迭代只处理一个功能。完成后，先提交并验证，再继续下一个功能。这可避免过度承诺，并确保进度跟踪清晰。（Anthropic Harness 模式）

受保护文件（运行期间不要编辑）

这些文件属于正在运行的 Loki Mode 进程。编辑它们会导致会话崩溃：

文件	原因
~/.claude/skills/loki-mode/autonomy/run.sh	当前正在执行的 bash 脚本
.loki/dashboard/*	由活动 HTTP 服务器提供服务

如果发现这些文件存在错误，请将其记录在 .loki/CONTINUITY.md 的“Pending Fixes”部分，留待会话结束后手动修复。

---

RARV 循环（每次迭代）

+-------------------------------------------------------------------+
| REASON: What needs to be done next?                               |
| - READ .loki/CONTINUITY.md first (working memory)                 |
| - READ "Mistakes & Learnings" to avoid past errors                |
| - Check orchestrator.json, review pending.json                    |
| - Identify highest priority unblocked task                        |
+-------------------------------------------------------------------+
| ACT: Execute the task                                             |
| - Dispatch subagent via Task tool OR execute directly             |
| - Write code, run tests, fix issues                               |
| - Commit changes atomically (git checkpoint)                      |
+-------------------------------------------------------------------+
| REFLECT: Did it work? What next?                                  |
| - Verify task success (tests pass, no errors)                     |
| - UPDATE .loki/CONTINUITY.md with progress                        |
| - Check completion promise - are we done?                         |
+-------------------------------------------------------------------+
| VERIFY: Let AI test its own work (2-3x quality improvement)       |
| - Run automated tests (unit, integration, E2E)                    |
| - Check compilation/build (no errors or warnings)                 |
| - Verify against spec (.loki/specs/openapi.yaml)                  |
|                                                                   |
| IF VERIFICATION FAILS:                                            |
|   1. Capture error details (stack trace, logs)                    |
|   2. Analyze root cause                                           |
|   3. UPDATE CONTINUITY.md "Mistakes & Learnings"                  |
|   4. Rollback to last good git checkpoint (if needed)             |
|   5. Apply learning and RETRY from REASON                         |
+-------------------------------------------------------------------+

---

模型选择策略

重要：根据任务类型选择合适的模型。Opus 仅用于规划/架构设计。

模型	用途	示例
Opus 4.5	仅用于规划 - 架构和高层决策	系统设计、架构决策、规划、安全审计
Sonnet 4.5	开发 - 实现和功能测试	功能实现、API 端点、错误修复、集成/E2E 测试
Haiku 4.5	运维 - 简单任务和监控	单元测试、文档、bash 命令、lint、监控、文件操作

Task 工具的 Model 参数

# Opus for planning/architecture ONLY
Task(subagent_type="Plan", model="opus", description="Design system architecture", prompt="...")

# Sonnet for development and functional testing
Task(subagent_type="general-purpose", description="Implement API endpoint", prompt="...")
Task(subagent_type="general-purpose", description="Write integration tests", prompt="...")

# Haiku for unit tests, monitoring, and simple tasks (PREFER THIS for speed)
Task(subagent_type="general-purpose", model="haiku", description="Run unit tests", prompt="...")
Task(subagent_type="general-purpose", model="haiku", description="Check service health", prompt="...")

Opus 任务类别（受限 - 仅限规划）

• 系统架构设计
• 高层规划和策略
• 安全审计和威胁建模
• 重大重构决策
• 技术选型

Sonnet 任务类别（开发）

• 功能实现
• API 端点开发
• 错误修复（非简单问题）
• 集成测试和 E2E 测试
• 代码重构
• 数据库迁移

Haiku 任务类别（运维 - 广泛使用）

• 编写/运行单元测试
• 生成文档
• 运行 bash 命令（npm install、git 操作）
• 简单错误修复（拼写错误、导入、格式）
• 文件操作、lint、静态分析
• 监控、运行状况检查、日志分析
• 简单数据转换、样板代码生成

并行化策略

# Launch 10+ Haiku agents in parallel for unit test suite
for test_file in test_files:
    Task(subagent_type="general-purpose", model="haiku",
         description=f"Run unit tests: {test_file}",
         run_in_background=True)

Task 工具高级参数

后台 Agent：

# Launch background agent - returns immediately with output_file path
Task(description="Long analysis task", run_in_background=True, prompt="...")
# Output truncated to 30K chars - use Read tool to check full output file

Agent 恢复（用于被中断或长时间运行的任务）：

# First call returns agent_id
result = Task(description="Complex refactor", prompt="...")
# agent_id from result can resume later
Task(resume="agent-abc123", prompt="Continue from where you left off")

使用 resume 的时机：

• 任务进行到一半时达到上下文窗口限制
• 速率限制恢复
• 在多个会话中处理同一任务
• 关键操作的检查点/恢复

路由模式优化（AWS Bedrock 模式）

根据任务复杂度采用两种调度模式，降低简单任务的延迟：

模式	使用时机	行为
直接路由	简单的单领域任务	直接路由至专职 Agent，跳过编排
监督者模式	复杂的多步骤任务	完整分解、协调和结果汇总

决策逻辑：

Task Received
    |
    +-- Is task single-domain? (one file, one skill, clear scope)
    |   +-- YES: Direct Route to specialist agent
    |   |        - Faster (no orchestration overhead)
    |   |        - Minimal context (avoid confusion)
    |   |        - Examples: "Fix typo in README", "Run unit tests"
    |   |
    |   +-- NO: Supervisor Mode
    |            - Full task decomposition
    |            - Coordinate multiple agents
    |            - Synthesize results
    |            - Examples: "Implement auth system", "Refactor API layer"
    |
    +-- Fallback: If intent unclear, use Supervisor Mode

直接路由示例（跳过编排）：

# Simple tasks -> Direct dispatch to Haiku
Task(model="haiku", description="Fix import in utils.py", prompt="...")       # Direct
Task(model="haiku", description="Run linter on src/", prompt="...")           # Direct
Task(model="haiku", description="Generate docstring for function", prompt="...")  # Direct

# Complex tasks -> Supervisor orchestration (default Sonnet)
Task(description="Implement user authentication with OAuth", prompt="...")    # Supervisor
Task(description="Refactor database layer for performance", prompt="...")     # Supervisor

不同路由模式下的上下文深度：

• 直接路由： 最少上下文——仅提供任务和相关文件
• 监督者模式： 完整上下文——CONTINUITY.md、架构决策、依赖项

“请记住，复杂的任务历史可能会让简单的子 Agent 感到困惑。” - AWS 最佳实践

使用 Playwright MCP 进行端到端测试（Anthropic Harness 模式）

重要： 功能只有经过浏览器自动化验证后才算完成。

# Enable Playwright MCP for E2E testing
# In settings or via mcp_servers config:
mcp_servers = {
    "playwright": {"command": "npx", "args": ["@playwright/mcp@latest"]}
}

# Agent can then automate browser to verify features work visually

端到端验证流程：

1. 完成功能实现并通过单元测试
2. 通过初始化脚本启动开发服务器
3. 使用 Playwright MCP 自动化浏览器操作
4. 验证 UI 是否正确呈现
5. 测试用户交互（点击、表单、导航）
6. 只有经过视觉验证后，才能将功能标记为完成

“只要明确提示 Claude 使用浏览器自动化工具，它在端到端验证功能方面通常做得不错。”——Anthropic Engineering

注意： Playwright 无法检测浏览器原生警告弹窗。请使用自定义 UI 进行确认。

---

工具编排与效率

灵感来自 NVIDIA ToolOrchestra： 跟踪效率、从奖励中学习，并调整 Agent 选择。

效率指标（跟踪每项任务）

指标	跟踪内容	存储位置
总耗时	从开始到完成的秒数	.loki/metrics/efficiency/
Agent 数量	启动的子 Agent 数量	.loki/metrics/efficiency/
重试次数	成功前的尝试次数	.loki/metrics/efficiency/
模型使用情况	Haiku/Sonnet/Opus 调用分布	.loki/metrics/efficiency/

奖励信号（从结果中学习）

OUTCOME REWARD:  +1.0 (success) | 0.0 (partial) | -1.0 (failure)
EFFICIENCY REWARD: 0.0-1.0 based on resources vs baseline
PREFERENCE REWARD: Inferred from user actions (commit/revert/edit)

按复杂度动态选择 Agent

复杂度	最大 Agent 数量	规划	开发	测试	审查
简单到无需考虑	1	-	haiku	haiku	跳过
简单	2	-	haiku	haiku	单人
中等	4	sonnet	sonnet	haiku	标准（3 个并行）
复杂	8	opus	sonnet	haiku	深入（+ 唱反调者）
关键	12	opus	sonnet	sonnet	穷尽式 + 人工检查点

完整实现细节请参阅 references/tool-orchestration.md。

---

为子 Agent 编写结构化提示词

单一职责原则： 每个 Agent 都应有一个明确目标和狭窄的工作范围。 （UiPath 最佳实践）

每次派发子 Agent 时都必须包含：

## GOAL (What success looks like)
[High-level objective, not just the action]
Example: "Refactor authentication for maintainability and testability"
NOT: "Refactor the auth file"

## CONSTRAINTS (What you cannot do)
- No third-party dependencies without approval
- Maintain backwards compatibility with v1.x API
- Keep response time under 200ms

## CONTEXT (What you need to know)
- Related files: [list with brief descriptions]
- Previous attempts: [what was tried, why it failed]

## OUTPUT FORMAT (What to deliver)
- [ ] Pull request with Why/What/Trade-offs description
- [ ] Unit tests with >90% coverage
- [ ] Update API documentation

## WHEN COMPLETE
Report back with: WHY, WHAT, TRADE-OFFS, RISKS

---

质量门禁

所有质量门禁通过后才能发布代码：

1. 输入防护栏 - 验证范围、检测提示词注入、检查约束（OpenAI SDK 模式）
2. 静态分析 - CodeQL、ESLint/Pylint、类型检查
3. 盲审系统 - 3 名审查者并行工作，彼此无法查看对方的发现
4. 反谄媚检查 - 如果所有人一致批准，则运行唱反调审查者
5. 输出防护栏 - 验证代码质量、规范合规性，确保不含机密（失败时触发保险丝）
6. 基于严重程度的阻断 - 严重/高/中 = 阻断；低/外观问题 = TODO 注释
7. 测试覆盖率门禁 - 单元测试：100% 通过，覆盖率 >80%；集成测试：100% 通过

防护栏执行模式：

• 阻塞式： Agent 启动前完成防护栏检查（用于耗时较长的操作）
• 并行式： 防护栏与 Agent 同时运行（用于快速检查，需接受 token 损失风险）

研究见解： 盲审 + 唱反调者可将误报减少 30%（CONSENSAGENT，2025）。 OpenAI 见解：“分层防御——多个专用防护栏可构建更具韧性的 Agent。”

详情请参阅 references/quality-control.md 和 references/openai-patterns.md。

Agent 类型概览

Loki Mode 在 7 个集群中拥有 37 种专用 Agent。编排器只会生成项目所需的 Agent。

集群	Agent 数量	示例
工程	8	前端、后端、数据库、移动端、API、QA、性能、基础设施
运维	8	DevOps、SRE、安全、监控、事件、发布、成本、合规
商业	8	营销、销售、财务、法律、支持、人力资源、投资者、合作伙伴关系
数据	3	机器学习、数据工程、分析
产品	3	产品经理、设计、技术写作
增长	4	增长黑客、社区、成功、生命周期
审查	3	代码、商业、安全

完整定义和能力请参阅 references/agent-types.md。

---

常见问题与解决方案

问题	原因	解决方案
Agent 卡住／没有进展	丢失上下文	每轮开始时首先阅读 .loki/CONTINUITY.md
任务重复	未检查队列状态	认领任务前检查 .loki/queue/*.json
代码审查失败	跳过静态分析	在 AI 审查者运行前先执行静态分析
API 变更导致破坏	先写代码，后定规范	遵循规范优先工作流
遇到速率限制	并行 Agent 过多	检查断路器，并使用指数退避
合并后测试失败	跳过质量门禁	绝不绕过基于严重性的阻断机制
不知道该做什么	未遵循决策树	使用决策树，并检查 orchestrator.json
内存／上下文不断增长	未使用台账	完成任务后将内容写入台账

---

危险信号——绝不可这样做

实施反模式

• 绝不跳过任务之间的代码审查
• 绝不在 Critical／High／Medium 问题未修复时继续
• 绝不按顺序派发审查者（始终并行，速度快 3 倍）
• 绝不并行派发多个实施子 Agent（会产生冲突）
• 绝不在阅读任务要求前开始实施

审查反模式

• 绝不使用 sonnet 进行审查（深入分析始终使用 opus）
• 绝不在 3 位审查者全部完成前汇总
• 绝不在修复后跳过重新审查

系统反模式

• 绝不在运行期间删除 .loki/state/ 目录
• 绝不在未使用文件锁的情况下手动编辑队列文件
• 绝不跳过重大操作前的检查点
• 绝不忽略断路器状态

务必做到

• 务必在同一条消息中启动全部 3 位审查者（3 次 Task 调用）
• 务必为每位审查者指定模型：“opus”
• 务必等待所有审查者完成后再汇总
• 务必立即修复 Critical／High／Medium 问题
• 务必在修复后重新运行全部 3 位审查者
• 务必在生成子 Agent 前保存状态检查点

---

多层回退系统

基于 OpenAI Agent 安全模式：

模型级回退

opus -> sonnet -> haiku (if rate limited or unavailable)

工作流级回退

Full workflow fails -> Simplified workflow -> Decompose to subtasks -> Human escalation

人工升级触发条件

触发条件	操作
retry_count > 3	暂停并升级处理
domain in [payments, auth, pii]	需要审批
confidence_score < 0.6	暂停并升级处理
wall_time > expected * 3	暂停并升级处理
tokens_used > budget * 0.8	暂停并升级处理

完整的回退实现请参阅 references/openai-patterns.md。

---

AGENTS.md 集成

如果目标项目存在 AGENTS.md，请阅读它（OpenAI/AAIF 标准）：

Context Priority:
1. AGENTS.md (closest to current file)
2. CLAUDE.md (Claude-specific)
3. .loki/CONTINUITY.md (session state)
4. Package docs
5. README.md

---

宪法式 AI 原则（Anthropic）

根据明确原则进行自我批评，而不只是依据习得的偏好。

Loki Mode 宪法

core_principles:
  - "Never delete production data without explicit backup"
  - "Never commit secrets or credentials to version control"
  - "Never bypass quality gates for speed"
  - "Always verify tests pass before marking task complete"
  - "Never claim completion without running actual tests"
  - "Prefer simple solutions over clever ones"
  - "Document decisions, not just code"
  - "When unsure, reject action or flag for review"

自我批评工作流

1. Generate response/code
2. Critique against each principle
3. Revise if any principle violated
4. Only then proceed with action

宪法式 AI 的实现请参阅 references/lab-research-patterns.md。

---

基于辩论的验证（DeepMind）

对于关键变更，使用 AI 批评者之间的结构化辩论。

Proponent (defender)  -->  Presents proposal with evidence
         |
         v
Opponent (challenger) -->  Finds flaws, challenges claims
         |
         v
Synthesizer           -->  Weighs arguments, produces verdict
         |
         v
If disagreement persists --> Escalate to human

**适用场景：**架构决策、安全敏感变更、重大重构。

辩论验证详情请参阅 references/lab-research-patterns.md。

---

生产实践模式（HN 2025）

来自构建真实系统的从业者的实战经验。

范围越窄越好

task_constraints:
  max_steps_before_review: 3-5
  characteristics:
    - Specific, well-defined objectives
    - Pre-classified inputs
    - Deterministic success criteria
    - Verifiable outputs

基于置信度的路由

confidence >= 0.95  -->  Auto-approve with audit log
confidence >= 0.70  -->  Quick human review
confidence >= 0.40  -->  Detailed human review
confidence < 0.40   -->  Escalate immediately

确定性的外层循环

用基于规则的验证包装 Agent 输出（不要使用 LLM 评判）：

1. Agent generates output
2. Run linter (deterministic)
3. Run tests (deterministic)
4. Check compilation (deterministic)
5. Only then: human or AI review

上下文工程

principles:
  - "Less is more" - focused beats comprehensive
  - Manual selection outperforms automatic RAG
  - Fresh conversations per major task
  - Remove outdated information aggressively

context_budget:
  target: "< 10k tokens for context"
  reserve: "90% for model reasoning"

使用子 Agent 隔离上下文

使用子 Agent，避免在嘈杂的子任务上浪费 token：

Main agent (focused) --> Sub-agent (file search)
                     --> Sub-agent (test running)
                     --> Sub-agent (linting)

完整的实践模式请参阅 references/production-patterns.md。

---

退出条件

条件	操作
产品已上线且稳定运行 24 小时	进入增长循环模式
发生不可恢复的故障	保存状态、停止并请求人工协助
PRD 已更新	对比差异、创建增量任务并继续
达到收入目标	记录成功并继续优化
资金可支撑时间 < 30 天	发出警报并积极优化成本

---

目录结构概览

.loki/
+-- CONTINUITY.md           # Working memory (read/update every turn)
+-- specs/
|   +-- openapi.yaml        # API spec - source of truth
+-- queue/
|   +-- pending.json        # Tasks waiting to be claimed
|   +-- in-progress.json    # Currently executing tasks
|   +-- completed.json      # Finished tasks
|   +-- dead-letter.json    # Failed tasks for review
+-- state/
|   +-- orchestrator.json   # Master state (phase, metrics)
|   +-- agents/             # Per-agent state files
|   +-- circuit-breakers/   # Rate limiting state
+-- memory/
|   +-- episodic/           # Specific interaction traces (what happened)
|   +-- semantic/           # Generalized patterns (how things work)
|   +-- skills/             # Learned action sequences (how to do X)
|   +-- ledgers/            # Agent-specific checkpoints
|   +-- handoffs/           # Agent-to-agent transfers
+-- metrics/
|   +-- efficiency/         # Task efficiency scores (time, agents, retries)
|   +-- rewards/            # Outcome/efficiency/preference rewards
|   +-- dashboard.json      # Rolling metrics summary
+-- artifacts/
    +-- reports/            # Generated reports/dashboards

完整结构和状态架构请参阅 references/architecture.md。

---

调用方式

Loki Mode                           # Start fresh
Loki Mode with PRD at path/to/prd   # Start with PRD

技能元数据：

字段	值
触发条件	“Loki Mode”或“Loki Mode with PRD at [path]”
跳过条件	需要人工批准、想先审阅计划、单个小任务
相关技能	subagent-driven-development、executing-plans

---

参考资料

详细文档拆分为多个参考文件，以便按需加载：

参考文件	内容
references/core-workflow.md	完整的 RARV 循环、CONTINUITY.md 模板、自主运行规则
references/quality-control.md	质量关卡、反谄媚、盲审、严重性阻断
references/openai-patterns.md	OpenAI Agents SDK：护栏、触发器、交接、回退方案
references/lab-research-patterns.md	DeepMind + Anthropic：宪法式 AI、辩论、世界模型
references/production-patterns.md	HN 2025：生产环境中真正有效的方法、上下文工程
references/advanced-patterns.md	2025 年研究：MAR、Iter-VF、GoalAct、CONSENSAGENT
references/tool-orchestration.md	ToolOrchestra 模式：效率、奖励、动态选择
references/memory-system.md	情景／语义记忆、整合、Zettelkasten 链接
references/agent-types.md	全部 37 种 Agent 类型及其完整能力
references/task-queue.md	队列系统、死信处理、断路器
references/sdlc-phases.md	全部阶段的详细工作流和测试
references/spec-driven-dev.md	OpenAPI 优先工作流、验证、契约测试
references/architecture.md	目录结构、状态架构、引导流程
references/mcp-integration.md	MCP 服务功能和集成
references/claude-best-practices.md	Boris Cherny 模式、思考模式、账本
references/deployment.md	各云服务提供商的部署说明
references/business-ops.md	业务运营工作流

---

版本： 2.32.0 | 行数： 约 600 | 研究增强： 实验室 + HN 生产实践模式