← 返回
未分类

devauto-flaw

一站式 AI 辅助开发全流程 Skill。7+1 阶段流水线:需求深挖→场景建模→风险建模→工程规划→质量门控执行→世界模型枚举测试→全局审查→知识沉淀。内置 4-Gate 质量门控、逻辑链监督、鲁棒性衡量、Karpathy 编程原则、Wiki 知识闭环。零外部依赖,下载即用。
一站式 AI 辅助开发全流程 Skill。7+1 阶段流水线:需求深挖→场景建模→风险建模→工程规划→质量门控执行→世界模型枚举测试→全局审查→知识沉淀。内置 4-Gate 质量门控、逻辑链监督、鲁棒性衡量、Karpathy 编程原则、Wiki 知识闭环。零外部依赖,下载即用。
user_a465771f
未分类 community v1.2.1 3 版本 100000 Key: 无需
★ 0
Stars
📥 81
下载
💾 0
安装
3
版本
#latest

概述

Dev-Flow — 智能开发全流程

> 从需求到交付,从经验到知识,自动学习、持续进化。

启动方式

/dev-flow/dev-flow "<项目描述>"


核心原则(Karpathy 编程哲学)

  1. Agency > Intelligence — 快速动手 > 完美规划,先跑起来再优化
  2. 可验证性 — 每个改动必须有验证手段,无证据不声明完成
  3. 简单优先 — 三行重复代码好过过早抽象
  4. 增量开发 — 每次只聚焦一个明确改动
  5. 可读性 > 聪明 — 注释只解释 WHY
  6. 实用主义交付 — 最简可用版本 > 完美未完成架构
  7. 逻辑链完整性 — 需求→决策→任务→验证,偏离即纠偏
  8. 鲁棒性优先 — 不仅跑通 happy path,更要扛住异常

项目分档(自动选择,可手动覆盖)

启动时根据项目描述自动选择档位,用户可覆盖:

档位适用场景执行的 Phase跳过的
-------------------------------------
轻量Bug 修复、单文件改动、配置调整、简单脚本1→3→5跳过 2/4/5.5/6/7 精简
标准新功能、API 开发、组件开发、量化策略1→2→3→4→5→7跳过 5.5,Phase 6 精简
完整Web 应用、管理系统、小程序、多模块系统全部 7+1 阶段

自动判断规则:

  • 提到"修"、"改"、"调" → 倾向轻量
  • 提到"新增"、"开发"、"实现" → 倾向标准
  • 提到"系统"、"平台"、"全栈" → 倾向完整

7+1 阶段流程概览

Phase 1: 需求深挖 ──→ Phase 2: 场景建模 ──→ Phase 3: 风险建模 ──→ Phase 4: 工程规划
                                                                │
                                                                ▼
Phase 7: 知识沉淀 ←── Phase 6: 全局审查 ←── Phase 5.5: 枚举测试 ←── Phase 5: 质量门控执行

> Phase 2 是锚点——脱离场景的代码毫无价值。

> Phase 5.5 是终极验证——场景建模再完美,真实操作走不通就是失败。


Phase 1: 需求深挖

用户说"需求确认"之前,禁止写任何代码、建任何文件。

执行步骤

  1. 知识库预检 — 读取 C:\Users\ASUS\.claude\llm-wiki全局\wiki\index.md,检查相关领域历史经验
  2. 项目上下文扫描 — 检查文件结构、git log、CLAUDE.md
  3. 逐层追问(每次只问一个):
    • "你要解决什么问题?"
    • "为什么现有方案不行?"
    • "成功标准是什么?(可验证的)"
    • "哪些边界不能碰?"
    • "明确不要什么?"
  4. 提出 2-3 种方案(附 trade-off 分析)
  5. 输出需求摘要
## 需求摘要
- 核心问题:[一句话]
- 成功标准:[可验证的条件]
- 约束条件:[不能做什么]
- 明确不做:[排除范围]
- 推荐方案:[方案名]
- 相关 wiki 经验:[如有]

## 风险分级
🔴 核心(80%精力):...
🟡 重要(15%精力):...
🟢 边缘(5%精力):...
  1. 用户确认 — 等用户说"需求确认"

项目分档确认

在需求确认后,告知用户建议的档位(轻量/标准/完整),用户可覆盖。


Phase 2: 场景建模

脱离场景的代码毫无价值。此 Phase 不可跳过(标准档和完整档)。

详细模板:读取 templates/phase2-scenario.md

核心产出:

  1. 人物画像(谁在用、什么环境、什么技术水平)
  2. 场景清单(触发条件→操作流程→期望结果→异常路径)
  3. 场景优先级(🔴 P0 / 🟡 P1 / 🟢 P2)
  4. 环境约束(网络/设备/时间/并发)
  5. War Room 推演(🔴 P0 场景桌面推演)
  6. DDD 领域建模(复杂业务时启用)

后续 Phase 的回溯规则:

  • 技术选型(Phase 3)→ 回溯场景优先级
  • 功能实现(Phase 5)→ 回溯用户操作流程
  • 枚举测试(Phase 5.5)→ 将每个场景展开为测试矩阵

Phase 3: 风险建模

执行步骤:

  1. 架构概览 — 数据模型、核心接口、关键依赖
  2. 风险矩阵
| 风险点 | 概率 | 影响范围 | 级别 | 预防措施 |
|--------|------|----------|------|----------|
| [具体风险] | 高/中/低 | 🔴/🟡/🟢 | ... | ... |
  1. 渔船堵洞检测 — 每个 🔴 改动的影响链分析
  2. 逻辑链路图 — 每条需求的完整链路:意图→决策→任务→验证→场景
### 链路 N: [需求点]
意图: [用户真正想要什么]
  → 决策: [基于什么判断选择这个方案]
    → 任务: [Phase 4 中对应的任务编号]
      → 验证: [什么证据能证明链完整]
        → 场景: [Phase 2 中哪个场景覆盖了这条链]

Phase 4: 工程规划

执行步骤:

  1. 任务拆分 — 🔴 核心前置,每个任务 2-5 分钟粒度
  2. 每个任务包含:精确文件路径 + 完整代码 + 验收标准 + 复杂度(1-10)
  3. 依赖关系 — blockedBy 标注
  4. 输出到 docs/dev-flow-plan.md
  5. 计划自检 — 需求覆盖 + 占位符扫描 + 类型一致性
  6. 用户确认计划

计划文档禁令

禁止出现:TBD、TODO、"类似 Task N"、"Add appropriate error handling"、只描述不给代码的步骤。

复杂度分级策略

复杂度策略
--------------
1-3直接执行 + Gate 验证
4-6分步执行 + 每步验证 + Devil's Advocate
7+拆分子任务 + 并行执行 + 多轮审查

Phase 5: 质量门控执行

执行模式

标准档/完整档:Team 模式(3 智能体)

详细协议:读取 templates/phase5-team.md

轻量档:单智能体快速执行 + 自我审查

Team 模式概览

Orchestrator(调度)→ Executor(执行)→ Supervisor(监督)
  • Orchestrator 按 🔴→🟡→🟢 分配任务
  • Executor 精确实现,不自由发挥
  • Supervisor 对照逻辑链审查,检测偏离

4-Gate 质量门

每个任务完成后按顺序通过:

Gate检查内容
----------------
1 正确性逻辑匹配需求、边界处理、无 off-by-one
2 质量无 debug 残留、无死代码、函数<50行、文件<300行
3 安全无注入/XSS/认证绕过/敏感信息泄露
4 一致性命名/模式/风格与代码库一致

验证铁律

无证据不声明完成。"应该没问题" = 撒谎。

声明必须有不够的
----------------------
测试通过测试命令输出:0 failures"应该通过"
Bug 修复原始症状测试:通过改了代码、假设修好了

Devil's Advocate(每步完成后)

  1. 核心问题检查 — 这真的解决了核心需求吗?
  2. 渔船堵洞 — 是否引入新问题?影响其他 🔴 功能?
  3. 精力分配 — 是否在 🟢 上花了超过 10 分钟?
  4. 历史经验 — wiki 中有类似踩坑记录吗?是否重复犯错?
  5. 过度工程 — 是否超出当前需求?(YAGNI)
  6. 场景贴合 — 回溯 Phase 2,真实操作能走通吗?
  7. 鲁棒性挑刺 — null/空/超大值/并发/外部故障会怎样?

鲁棒性评分(🔴 核心任务必须)

详细评分卡:读取 templates/robustness.md

6 维度(1-5 分):输入容错 / 异常恢复 / 边界条件 / 降级能力 / 数据一致 / 可诊断

  • 🔴 任务 ≥ 24/30(每项 ≥ 4)
  • 🟡 任务 ≥ 18/30(每项 ≥ 3)

Phase 5.5: 世界模型枚举测试(仅完整档)

详细架构:读取 templates/phase5-ate.md

6 组件全自动循环:Planner → Driver → Observer → Diagnostician → Healer → Evolver

降级方案(根据实际条件):

等级模式适用条件
----------------------
L3全自动 ATE有 agent-browser、前后端可启动
L2半自动无 agent-browser,Claude 手动操作+日志
L1手动测试清单脚本/工具/量化策略等非 Web 项目
L0跳过极简改动,由 Devil's Advocate 替代

非 Web 项目测试策略

项目类型测试方式
--------------------
量化策略(D4)回测枚举:不同市场状态(牛市/熊市/震荡/闪崩)×不同参数组合
通信算法(D3)仿真验证:不同 SNR/信道模型/负载条件
AI 工具(D5)输入变体:边界输入/异常格式/大规模输入
脚本工具参数边界:空输入/超大输入/非法字符/并发执行

Phase 6: 全局审查

完整档执行全部检查;标准档执行 1+2+4;轻量档跳过。

  1. 枚举测试审查(完整档)— 确认 Phase 5.5 P0 通过率 100%
  2. 需求覆盖检查 — 逐条对照 Phase 1
  3. 场景覆盖检查(引用 Phase 5.5 报告,不重复执行)
  4. 集成验证 — 各模块正确集成
  5. 鲁棒性全局评估(完整档)— 读取 templates/robustness.md 评分汇总
  6. 精简审查 — 删除过度工程
  7. 提交和交付

Phase 7: 知识沉淀 + 自演化

知识沉淀

Wiki 知识库配置:读取 templates/wiki-config.md

项目完成后自动执行:

  1. 开发回顾
    • 哪些判断对了?为什么?
    • 哪些判断错了?为什么?
    • 踩了什么坑?怎么解决的?
  1. 写入 wiki(三级演化):
    • 🟢 无冲突 → 自动写入,事后通知用户
    • 🟡 有冲突 → 暂停,报告冲突,等用户决定
    • 🔴 无专业内容 → 跳过
  1. 输出知识摘要给用户确认

自演化检测

检查本次开发是否遇到了 dev-flow 无法覆盖 的情况:

## 自演化检测

本次开发中遇到的流程缺口:
1. [缺口描述]
   → 建议:[安装新 Skill / 修改 dev-flow 规则]
   → 命令:npx skills find "<关键词>"

经验晋升流水线(源自 Self-Improving Agent)

单次踩坑(对话中捕获)
    ↓ 复现 2+ 次
反复出现的模式
    ↓ Recurrence-Count ≥ 3 或用户明确要求
写入 wiki 页面(带置信度评分)
    ↓ 跨 2+ 项目验证
晋升为 CLAUDE.md 规则
    ↓ 广泛适用 + 用户确认
提取为独立 Skill

模板引用索引

模板文件加载时机内容
--------------------------
templates/phase2-scenario.mdPhase 2 开始时场景建模完整模板
templates/phase5-team.mdPhase 5 开始时Team 模式详细协议
templates/phase5-ate.mdPhase 5.5 开始时自治测试引擎架构
templates/robustness.mdPhase 5 评分时鲁棒性评分卡
templates/wiki-config.mdPhase 7 开始时Wiki 配置参考

环境适配

SSL 代理环境

$env:NODE_TLS_REJECT_UNAUTHORIZED="0"

项目级 CLAUDE.md

Phase 1 自动读取并纳入约束条件。


版本历史

  • v2.0.0 — SKILL.md 瘦身(1712→~500 行),模板拆分,项目分档(轻量/标准/完整),Wiki 路径修正为 D1-D6,ATE 降级方案,非 Web 测试策略,经验晋升流水线
  • v1.3.0 — 世界模型枚举测试 + 自治测试引擎
  • v1.2.0 — 逻辑链监督 + 鲁棒性衡量 + Team 模式
  • v1.1.0 — Phase 2 场景建模 + DDD
  • v1.0.0 — 初始版本

版本历史

共 3 个版本

  • v1.2.1 项核心改进: 1. SKILL.md 从 1712 行瘦身至 355 行(-79%),详细内容拆分到 5 个按需加载的模板文件,每次调用 token 成本降低 78% 2. 新增项目分档:轻量(bug 修复)/标准(新功能)/完整(全栈系统),自动选择执行深度,简单任务不再跑全流程 3. ATE 降级方案:从"全自动无限迭代"的过度承诺改为 L0-L3 四级降级,新增量化/通信/AI 等非 Web 项目的测试策略 4. Wiki 路径修正:硬编码用户实际的 D1-D6 六域知识库路径,消除与已有 wiki 的冲突 5. 经验晋升流水线:踩坑→复现→wiki→CLAUDE.md→Skill,结构化的知识升级路径 当前
    2026-05-21 15:51 安全 安全
  • v1.2.0 逻辑链监督系统(v1.2.0 核心新增): 1. 逻辑链构建 — Phase 1 确认需求后,将每条需求拆解为 4 层链路:意图→决策→任务→验证,并关联 Phase 2 场景。无法回溯到"意图"的任务标记为无根任务。 2. Team 模式 3 智能体 — Phase 5 默认启用: - Orchestrator(调度者):分配任务、综合反馈、向用户报告 - Executor(执行者):精确实现任务,不自由发挥 - Supervisor(逻辑链守卫):独立于执行者,对照逻辑链审查每步产出,检测 4 种偏离(过度实现/欠实现/逻辑跳跃/无根任务) 3. 监督反馈机制 — 4 级判定:✅完整 / ⚠️轻微偏离(自动修正) / 🔴严重偏离(暂停报告用户) / 💔链路断裂(回退重评估) 4. 单智能体降级 — Team 不可用时,同一智能体显式切换角色完成自我审查 鲁棒性衡量原则: - 6 维度评分卡:输入容错、异常恢复、边界条件、降级能力、数据一致性、可诊断性(1-5 分,满分 30) - 通过线:🔴 核心任务 ≥ 24/30,🟡 重要任务 ≥ 18/30 - 7 条铁律:不信任外部输入 / fail fast fail loud / 优雅降级 > 硬崩溃 > 静默错误 / 幂等优先 / 超时必设 / 兜底永远有 / 可观测性不是可选的 - Phase 6 新增鲁棒性全局评估步骤
    2026-05-20 17:35 安全 安全
  • v1.0.0 Initial release
    2026-05-20 15:23 安全

安全检测

腾讯云安全 (Keen)

安全,无风险
查看报告

腾讯云安全 (Sanbu)

安全,无风险
查看报告

🔗 相关推荐

dev-programming

Github

steipete
使用 `gh` CLI 与 GitHub 交互,通过 `gh issue`、`gh pr`、`gh run` 和 `gh api` 管理议题、PR、CI 运行及高级查询。
★ 689 📥 332,668
dev-programming

YouTube

byungkyu
使用托管OAuth集成YouTube Data API,支持搜索视频、管理播放列表、获取频道数据及评论互动,适用于用户需要时使用此技能。
★ 142 📥 42,392
dev-programming

Docker Essentials

arnarsson
核心 Docker 命令和工作流程,包括容器管理、镜像操作和调试。
★ 40 📥 32,856