Hello Dev 是一个面向 AI 辅助开发的多阶段工程框架：用一整套流程 + 两个内置引擎（grill-me / ui-ux-pro-max），把 AI 编程从"能跑就行"变成"交付正确的东西"。
开源地址：GitHub – ywddc-prism/hello-dev-skill: Hello Dev – AI 开发治理技能：范围确认、分阶段审批、风险优先验证、跨会话记忆，让 AI 辅助开发真正交付你想要的东西。 · GitHub 支持平台：WorkBuddy / Claude Code / OpenAI Codex ｜ 协议：MIT
一、先说问题：AI 编程最贵的成本，是返工
几个公开数据，做 AI 编程的人应该都有体感：
- 42%——工程师平均每周花在调试上的时间占比（写代码 9.8 小时，调试 16.9 小时）〔来源：Undo / Coleman Parkes 2026 调研〕
- 66%——开发者最常吐槽的问题：AI 代码"几乎全对，但总有哪里不对"（almost right, but not quite）
- 75%——代码维护任务中，AI 改动破坏原本正常功能的概率〔来源：中山大学 & 阿里巴巴联合研究〕
这些数字指向同一件事：AI 写得很快，但快出来的时间，经常在返工里全还回去。
返工集中在哪两个地方？
再叠加多 Agent 并行时的文件互相覆盖、会话重启后状态丢失、经验无法沉淀……你会发现：AI 编程缺的不是更强的模型，而是一套工程规矩。
这就是 Hello Dev 想解决的问题。
二、Hello Dev 是什么
一句话：给 AI 编程立一套工程规矩。
它的目标不是让 AI"写得更快"，而是确保 AI 构建你真正想要的东西——从需求确认到交付，每一步都可控、可追溯、可回退。
|
传统 AI 编程方式 |
Hello Dev |
|
关注编码速度 |
关注交付正确性 |
|
假设需求是清楚的 |
假设需求需要验证 |
|
开发完了再验证 |
开发之前就验证 |
|
"我写得很快" |
"我构建了正确的东西" |
- 开源协议：MIT（可自由使用、修改、商用）
- 版本：v15.11，已经打磨了 15 个大版本
- 支持平台：WorkBuddy（主推）/ Claude Code / OpenAI Codex
三、核心机制
3.1 多阶段工程流程（主线）
Hello Dev 的核心是一台 15 阶段的状态机：
（full 路径在实现之前会插入 Tool Research、Feature Design、Architecture、Prototype 四个设计阶段）
设计要点：
- 每个阶段有明确的入口条件、出口条件和交付物，不可跳过；
- 审核不过就回退重做（rolled_back）——绝不带病往下走；
- 按改动规模自动选择执行路径：tiny（单文件微改）/ fast / implementation / full（新设计）；
- 所有状态、审批、检查点持久化在 .hello-dev/state.json——会话断了，一句 resume 接着干。
3.2 双引擎：grill-me 与 ui-ux-pro-max（治返工重灾区）
多阶段流程里，返工最狠的两个环节，各配了一个专职引擎：
grill-me｜结构化需求拷问
- 把计划建模成一棵决策树，逐个分支走完；
- 每个问题先给推荐答案，你只需确认或修改；
- 一次只问一个（不是 30 点问卷）；
- 全部分支收敛，才允许动第一行代码。
ui-ux-pro-max｜UI/UX 设计规范
- 设计令牌（Design Tokens）：颜色 / 字体 / 间距标准化；
- 组件规格（Component Specs）：每个组件有明确规格；
- 布局蓝图（Layout Blueprint）：页面结构开发前定义；
- 实现指引（Implementation Notes）：让"设计"到"代码"之间没有缝隙。
3.3 支撑体系
- 波次调度 + 文件冲突检测：多 Agent 并行时按依赖图分波执行；同一波次内 affectedFiles 重叠的任务强制降级串行——不会互相覆盖；
- 四层验证：构建 / 回归 / 行为 / 边界逐层拿证据，"测试全绿"不等于"变更正确"；
- 五层记忆 + 证据链：经验只收已确认的事实，且标注 improved / regressed / no_effect，越用越准；
- 状态持久化：阶段、审批、重试、检查点全部落盘，随时恢复；
- 多平台适配：Host Adapter 层把调度核心与宿主解耦，同一套流程跑在三个平台上。
3.4 顺手上的工程安全（附赠）
框架还内置了两个执行前的风险闸门（PreToolUse hooks）：
- git 闸门：git push –force、git reset –hard 等高风险操作会被拦截，弹窗等你批准；
- 运维闸门：kubectl / systemctl / terraform 等命令按风险分级，只读放行、变更需审批、拿不准默认拦下。
设计原则是八个字：只加严，不放宽——它永远不会"悄悄放宽"某个限制。
3.5 一些工程细节（如果你也做工具链）
- hooks 是纯函数：无文件写入、无网络访问，不拖慢每一次命令调用；
- 失败模式可选：fail-open（默认，闸门自身坏了不锁死仓库）/ fail-closed（严格阻塞）；
- 自带自检体系：17 个测试脚本 + 6 大类自检（语法 / 文档完整性 / 闸门行为 / 状态协议 / 死结构 / 发布一致性），bash scripts/self-check.sh 一键跑。
四、快速开始
WorkBuddy（推荐，开箱即用）
在 WorkBuddy 新会话中输入：
AI 助手会自动完成搜索、下载、安装和验证。
另外，WorkBuddy 专家中心还有配套的交付专家团（1 位主理人 + 14 位专家角色）——把上面这套工程流程变成一支按角色分工的虚拟交付团队，开箱即用。
Claude Code / OpenAI Codex
然后在 CLAUDE.md / CODEX.md 中引用技能即可加载执行契约。
第一个任务
安装完成后，用自然语言描述任务就行：
框架会自动走：需求拷问（grill-me）→ 技术调研 → 功能设计 → 架构 → 原型 → 按波次实现 → 四层验证 → 复核 → 交付，并在关键节点邀请你确认。
五、设计取舍：为什么"慢"反而快
有人问：加这么多流程，不是更慢吗？
我的答案：检查点的本质，是在"修改成本最低"的时刻把问题拦下来。 前面花 1 分钟确认需求，省的是后面 1 小时的返工；测试阶段多问一句"这次改动可能弄坏什么"，省的是生产环境的连夜排障。
这个框架自己就交过学费：它的波次调度算法曾经有两份实现，同一份任务清单算出了两个不同结果（一个 0 波次、一个 2 波次）。后来我们定了一条铁律——"同一个计算，只允许存在一份实现"。不确定的地方，早晚会长出事故。
所以：快而返工等于白干，慢而不返工才是真的快。
六、适合谁
- 认真对待交付质量的独立开发者 / 小团队；
- 用多 Agent 并行开发、被文件冲突坑过的场景；
- 需要"改动可审计、经验可沉淀"的团队；
- 正在用 WorkBuddy / Claude Code / Codex 做实际项目的开发者。
一个定位说明：它不替代你的 AI 编程工具，而是叠在它们之上的一层"工程流程层"。 无论你用哪个宿主，规矩是同一套。
七、结语
Hello Dev 已开源：GitHub – ywddc-prism/hello-dev-skill: Hello Dev – AI 开发治理技能：范围确认、分阶段审批、风险优先验证、跨会话记忆，让 AI 辅助开发真正交付你想要的东西。 · GitHub
如果它对你有帮助，欢迎 star、试用、提 issue。也欢迎在评论区聊聊：你用 AI 编程踩过最深的坑是什么？
用项目里那句话收尾吧——
"慢是慢了点，但用起来不烧心。"
