hongmaple0820 枫林工作流 (FengLin Workflow)
🍁 快而不乱，简而有章
融合 Compound Engineering 的结构化与 Agent Coding 的敏捷性 适合：个人开发者、小团队、快速迭代项目
📑 目录
🎯 核心理念
"快而不乱，简而有章"
| 保留 ✅ | 去除 ❌ |
|---|---|
| 结构化的思维方式 | 繁琐的文档要求 |
| 快速迭代的能力 | 过度的审查流程 |
| 按需的质量把控 | 一刀切的标准 |
| 自动化的知识沉淀 | 人工的整理负担 |
三大原则：
- 复杂度驱动 — 小项目简单处理，大项目认真对待
- 按需审查 — 安全/性能/架构关键点才审查
- 自动化沉淀 — 知识记录自动化，不增加人工负担
🔄 工作流概览
┌─────────────┐ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 1.理解 │ → │ 2.规划 │ → │ 3.执行 │ → │ 4.沉淀 │
│ Understand │ │ Plan │ │ Build │ │ Compound │
└─────────────┘ └─────────────┘ └─────────────┘ └─────────────┘
5分钟 10分钟 按需执行 自动执行
| 阶段 | 时间 | 关键产出 | 决策点 |
|---|---|---|---|
| 理解 | 5分钟 | 需求摘要、复杂度评估 | 项目分级（简单/中等/复杂） |
| 规划 | 10分钟 | 执行方案 | 规划深度选择 |
| 执行 | 按需 | 可工作的代码 | 质量审查触发 |
| 沉淀 | 自动 | 经验教训、可复用方案 | 定期整理 |
📋 阶段详解
阶段1：理解
目标： 快速理解需求，判断是否值得深入
执行者： 小熊-统筹
流程：
- 用户描述需求
- 提出 3-5 个澄清问题（一次性，不反复追问）
- 快速判断项目复杂度
复杂度分级：
| 级别 | 时间 | 处理方式 | 规划要求 |
|---|---|---|---|
| 🟢 简单 | < 2小时 | 跳过详细规划，直接执行 | 口头确认 |
| 🟡 中等 | 2小时-2天 | 简要规划，口头确认 | 简要文档 |
| 🔴 复杂 | > 2天 | 详细规划，书面确认 | 详细文档 |
输出：
- 需求摘要（1-2句话）
- 复杂度评估（简单/中等/复杂）
- 下一步建议
阶段2：规划
目标： 制定执行方案，根据复杂度决定规划深度
执行者： 小熊-统筹 + 相关 Agent
🟢 简单项目 — 口头规划
"这是一个简单的功能，我计划：
1. 修改 xxx 文件
2. 添加 yyy 功能
3. 测试验证
预计 30 分钟完成，可以吗？"
🟡 中等项目 — 简要规划
保存在 memory/daily/YYYY-MM-DD.md：
## 项目：xxx
- 目标：一句话描述
- 步骤：
1. xxx
2. xxx
3. xxx
- 预计：x 小时
- 风险：xxx
🔴 复杂项目 — 详细规划
保存在 docs/plans/YYYY-MM-DD-<feature>.md：
# 项目规划：xxx
## 目标与范围
- 目标：一句话描述
- 范围：包含/不包含
## 技术方案
- 选项A：xxx（推荐）
- 选项B：xxx
## 执行步骤
1. xxx
2. xxx
## 验收标准
- [ ] 标准1
- [ ] 标准2
## 预计时间
- 总时间：x 天
- 里程碑：xxx
规划原则：
- 能用口头不用书面
- 能用简要不用详细
- 规划时间 < 10% 项目时间
阶段3：执行
目标： 高效完成开发，按需引入审查
执行者： 小熊-代码 + 子 Agent
标准执行流程
1. 环境准备
├─ 检查当前分支
├─ 确认依赖状态
└─ 准备开发环境
2. 编码实现
├─ 小熊-代码主责
└─ 复杂模块 spawn 子 Agent
3. 质量把关（按需）
├─ 安全相关 → security-sentinel
├─ 性能关键 → performance-oracle
├─ 架构重要 → architecture-strategist
└─ 常规项目 → 自我审查
4. 测试验证
├─ 基本功能测试
└─ 边界情况检查
审查触发条件
| 条件 | 是否审查 | 审查 Agent |
|---|---|---|
| 涉及用户数据/支付 | ✅ 必须 | security-sentinel |
| 性能关键路径 | ✅ 推荐 | performance-oracle |
| 架构重大变更 | ✅ 推荐 | architecture-strategist |
| 常规 CRUD | ❌ 跳过 | - |
| Bug 修复 | ❌ 跳过 | - |
| 配置调整 | ❌ 跳过 | - |
阶段4：沉淀
目标： 自动记录经验教训，不增加人工负担
执行者： 小熊-统筹（自动化）
自动化记录
每次项目完成后自动追加到 memory/daily/YYYY-MM-DD.md：
## 项目总结：xxx
- 时间：x 小时
- 结果：✅ 成功 / ⚠️ 部分成功 / ❌ 失败
- 关键决策：xxx
- 遇到的问题：xxx
- 解决方案：xxx
- 可复用：xxx
定期整理（每周/每月）
从 daily 提取有价值的内容，整理到：
memory/core/lessons.md— 经验教训memory/projects/<name>/— 项目档案skills/— 可复用的技能
原则：
- 记录自动化，不增加负担
- 定期整理，而非每次整理
- 只记有价值的内容
📁 项目规范
代码规范
命名规范
| 类型 | 规范 | 示例 |
|---|---|---|
| 变量/函数 | camelCase | getUserInfo, userList |
| 常量 | UPPER_SNAKE_CASE | MAX_RETRY_COUNT |
| 类/组件 | PascalCase | UserService, LoginForm |
| 文件/目录 | kebab-case | user-service.ts, api-clients/ |
代码风格
- 简洁优先：避免过度设计
- 自解释：代码即文档，注释说明"为什么"
- 单一职责：函数只做一件事
- 错误处理：显式处理错误，不静默吞掉
提交前检查
# 运行测试
npm test
# 检查类型（TypeScript）
npm run type-check
# 检查代码风格
npm run lint
Git规范
分支策略
main/master # 生产分支，保护
↓
develop # 开发分支（可选）
↓
feature/xxx # 功能分支
bugfix/xxx # 修复分支
hotfix/xxx # 紧急修复
提交信息规范
<type>: <subject>
<body>（可选）
<footer>（可选）
类型：
feat: 新功能fix: 修复docs: 文档style: 格式（不影响代码）refactor: 重构test: 测试chore: 构建/工具
示例：
git commit -m "feat: add user login with JWT"
git commit -m "fix: resolve memory leak in event handler"
git commit -m "docs: update API documentation"
提交频率
- 小步快跑：完成一个逻辑单元就提交
- 避免大提交：一次提交 < 200 行变更
- 保持可工作：每次提交后代码可运行
🤖 Agent分工
核心Agent
| Agent | 职责 | 触发条件 |
|---|---|---|
| 小熊-统筹 | 任务分配、进度跟踪、决策支持 | 所有项目入口 |
| 小熊-代码 | 编码实现、调试优化 | 代码类任务 |
| 小熊-运营 | 文档整理、内容创作 | 写作类任务 |
| 小熊-研究 | 技术调研、方案对比 | 研究类任务 |
可选审查Agent
| Agent | 用途 | 触发条件 |
|---|---|---|
| security-sentinel | 安全审计 | 涉及敏感数据/支付 |
| performance-oracle | 性能优化 | 性能关键路径 |
| architecture-strategist | 架构决策 | 架构重大变更 |
任务路由
用户输入
↓
小熊-统筹判断任务类型
↓
├─ 代码类 → 小熊-代码
├─ 写作类 → 小熊-运营
├─ 研究类 → 小熊-研究
└─ 决策类 → 小熊-统筹（可能调用其他Agent）
↓
执行任务
↓
按需审查
↓
返回结果
🚀 快速开始
5分钟上手
1. 判断项目复杂度
用户：帮我加一个用户登录功能
小熊-统筹：
"这是一个中等复杂度的功能，涉及用户认证。
预计 2 小时，可以吗？"
2. 选择规划深度
- 简单：口头确认 → 直接执行
- 中等：简要文档 → 执行
- 复杂：详细规划 → 确认 → 执行
3. 执行并审查
小熊-代码执行
↓
security-sentinel 审查（自动，涉及安全时）
↓
完成
4. 自动沉淀
项目完成后自动记录到 memory/daily/YYYY-MM-DD.md
常用命令
# 查看今日工作记录
cat memory/daily/$(date +%Y-%m-%d).md
# 创建项目规划
touch docs/plans/$(date +%Y-%m-%d)-feature.md
# 查看项目档案
ls memory/projects/
项目结构模板
project/
├── README.md # 项目简介
├── docs/
│ ├── plans/ # 复杂项目规划
│ └── solutions/ # 问题解决方案
├── memory/
│ └── daily/ # 每日工作记录
└── src/ # 源代码
❓ 常见问题
Q: 什么时候需要详细规划？
A: 符合以下任一条件：
- 预计时间 > 2天
- 涉及多个系统/模块
- 技术方案不确定
- 风险较高
Q: 审查Agent什么时候调用？
A: 按需调用，不强制：
- 涉及用户数据/支付 → security-sentinel
- 性能关键路径 → performance-oracle
- 架构重大变更 → architecture-strategist
- 其他情况 → 自我审查即可
Q: 知识沉淀怎么做？
A: 自动化处理：
- 每次项目完成自动记录到 daily
- 每周/每月定期整理到 lessons 和 projects
- 有价值的方案提炼为 skills
Q: 工作流适合什么项目？
适合：
- ✅ 个人开发者
- ✅ 小团队
- ✅ 快速迭代项目
- ✅ 原型开发
不适合：
- ❌ 大型企业项目（需要更严格流程）
- ❌ 安全关键系统（需要完整审查）
- ❌ 强合规要求项目（需要完整文档）
📚 相关文档
- QUICKSTART.md — 5分钟快速开始指南
- AGENT-GUIDE.md — Agent分工协作指南
- examples/ — 项目案例
记住：流程是工具，不是目的。选择适合你的，而不是最复杂的。 🐻