devauto-flaw_开发编程 skill-PHP中文网

devauto-flaw

Polar Sponsor

爱发电赞助

.NET 9.0

立即下载

一站式 AI 辅助开发全流程 Skill。7+1 阶段流水线：需求深挖→场景建模→风险建模→工程规划→质量门控执行→世界模型枚举测试→全局审查→知识沉淀。内置 4-Gate 质量门控、逻辑链监督、鲁棒性衡量、Karpathy 编程原则、Wiki 知识闭环。零外部依赖，下载即用。

Dev-Flow — 智能开发全流程

功能概述

Dev-Flow — 智能开发全流程是一项面向实际任务的技能，主要用于从需求到交付，从经验到知识，自动学习、持续进化；/dev-flow 或 /dev-flow "<项目描述>"；

核心要点

核心原则（Karpathy 编程哲学）；
Agency > Intelligence — 快速动手 > 完美规划，先跑起来再优化；
可验证性 — 每个改动必须有验证手段，无证据不声明完成；

使用与执行

简单优先 — 三行重复代码好过过早抽象；增量开发 —。它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。从功能定位来看，该技能强调把分散的操作要求整理成清晰、可复用的处理流程，使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数，再依据技能说明逐步执行；

结果检查与注意事项

若输入条件不完整，应先补齐信息或采用保守配置，避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期，并对异常提示、缺失字段和边界情况进行处理；涉及批量任务时，还应保存进度，避免中断后重复操作。该技能适合用于一次性任务，也可以接入自动化工作流，与其他技能或上层代理配合完成更完整的业务链路；在组合使用时，应明确每一步的输入输出关系，并避免不同步骤之间出现参数冲突。

Dev-Flow — 智能开发全流程

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

启动方式

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

核心原则（Karpathy 编程哲学）

Agency > Intelligence — 快速动手 > 完美规划，先跑起来再优化
可验证性 — 每个改动必须有验证手段，无证据不声明完成
简单优先 — 三行重复代码好过过早抽象
增量开发 — 每次只聚焦一个明确改动
可读性 > 聪明 — 注释只解释 WHY
实用主义交付 — 最简可用版本 > 完美未完成架构
逻辑链完整性 — 需求→决策→任务→验证，偏离即纠偏
鲁棒性优先 — 不仅跑通 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: 需求深挖

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

执行步骤

知识库预检 — 读取 C:UsersASUS.claudellm-wiki全局wikiindex.md，检查相关领域历史经验
项目上下文扫描 — 检查文件结构、git log、CLAUDE.md
逐层追问（每次只问一个）：
- "你要解决什么问题？"
- "为什么现有方案不行？"
- "成功标准是什么？（可验证的）"
- "哪些边界不能碰？"
- "明确不要什么？"
提出 2-3 种方案（附 trade-off 分析）
输出需求摘要：

## 需求摘要
- 核心问题：[一句话]
- 成功标准：[可验证的条件]
- 约束条件：[不能做什么]
- 明确不做：[排除范围]
- 推荐方案：[方案名]
- 相关 wiki 经验：[如有]

## 风险分级
🔴 核心（80%精力）：...
🟡 重要（15%精力）：...
🟢 边缘（5%精力）：...

用户确认 — 等用户说"需求确认"

项目分档确认

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

Phase 2: 场景建模

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

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

核心产出：

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

后续 Phase 的回溯规则：

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

Phase 3: 风险建模

执行步骤：

架构概览 — 数据模型、核心接口、关键依赖
风险矩阵：

| 风险点 | 概率 | 影响范围 | 级别 | 预防措施 |
|--------|------|----------|------|----------|
| [具体风险] | 高/中/低 | 🔴/🟡/🟢 | ... | ... |

渔船堵洞检测 — 每个 🔴 改动的影响链分析
逻辑链路图 — 每条需求的完整链路：意图→决策→任务→验证→场景

### 链路 N: [需求点]
意图: [用户真正想要什么]
  → 决策: [基于什么判断选择这个方案]
    → 任务: [Phase 4 中对应的任务编号]
      → 验证: [什么证据能证明链完整]
        → 场景: [Phase 2 中哪个场景覆盖了这条链]

Phase 4: 工程规划

执行步骤：

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

计划文档禁令

禁止出现：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（每步完成后）

核心问题检查 — 这真的解决了核心需求吗？
渔船堵洞 — 是否引入新问题？影响其他 🔴 功能？
精力分配 — 是否在 🟢 上花了超过 10 分钟？
历史经验 — wiki 中有类似踩坑记录吗？是否重复犯错？
过度工程 — 是否超出当前需求？（YAGNI）
场景贴合 — 回溯 Phase 2，真实操作能走通吗？
鲁棒性挑刺 — 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；轻量档跳过。

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

Phase 7: 知识沉淀 + 自演化

知识沉淀

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

项目完成后自动执行：

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

自演化检测

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

## 自演化检测

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

经验晋升流水线（源自 Self-Improving Agent）

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

模板引用索引

模板文件	加载时机	内容
`templates/phase2-scenario.md`	Phase 2 开始时	场景建模完整模板
`templates/phase5-team.md`	Phase 5 开始时	Team 模式详细协议
`templates/phase5-ate.md`	Phase 5.5 开始时	自治测试引擎架构
`templates/robustness.md`	Phase 5 评分时	鲁棒性评分卡
`templates/wiki-config.md`	Phase 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 — 初始版本