这段时间我越来越强烈地感受到一个核心问题：AI Coding 的痛点早已不是 “写不出代码”，而是 “写得太顺了”。
只需抛出一句需求，AI 就能立刻分析、拆解任务、修改代码，甚至顺手补测试、补文档 —— 前几轮用下来，那种 “开发效率被重新定义” 的爽感扑面而来。但只要项目复杂度上来，隐藏的问题会逐一暴露：上下文不稳定、改动边界模糊、大小需求混走一套流程、文档跟不上节奏、多轮协作越往后越失控。
我慢慢意识到，很多时候不是 AI 不够强，而是项目本身没准备好迎接 AI。不少团队已经高频用 AI 写代码，但真正缺的从来不是 “更强的模型”，而是能把 AI 放进 “可控、可维护、可复用” 项目流程的底层规范。
于是我做了「bingo-spec-coding-max-skill」。它不是又一个 prompt 仓库，也不是只能演示的样板工程，而是一套能把已有 / 新项目一站式初始化为「Spec-Driven Development（规格驱动开发）」工作空间的启动套件（bootstrap kit）。本质上，它会把 AGENTS.md、spec / 目录骨架、模板、prompts 和跨平台脚本注入目标仓库，让后续 AI 协作始终围绕「Context → Plan → Spec → Tasks → Code」这条稳定主线推进。
我为什么要做这个工具？补好 AI 协作的 “地基”
很多人第一次看到这个工具，可能会误以为它只是个 prompt 集合，但我真正想解决的，是项目级的协作秩序，而非单次代码生成的效果。
初始化后，目标仓库会具备这些核心能力：
- 项目级的 AGENTS.md（定义 AI / 人类角色边界）
- 单一入口的 spec/INDEX.md（统一协作入口）
- 可复用的模板与 prompt
- 显式的请求分类规则
- 明确的人类审批门禁（Human Gate）
- 自动生成的 spec/SPEC_CONTEXT.md 初稿
当前版本还能自动探测 Java、前端、Python 或混合技术栈仓库，生成运行命令、测试命令、源码根目录、核心模块和工程约束的草稿；对低置信度的推断结果，我也刻意用保守表述，避免把猜测写成既定事实 —— 核心就是先给项目补好 “地基”，再谈 AI 高效协作。
核心痛点：AI 越顺，后期越容易失控
AI Coding 最大的诱惑是 “无阻力”：一句需求就能一路推到编码、测试、文档，全程几乎不用停顿。但真实项目里，这种 “顺滑” 恰恰是失控的源头：
- 这次请求是问题咨询，还是功能开发？
- 该不该先分析，而非直接改代码？
- 改动会不会影响外部契约？
- 只是小调整，还是触到了功能边界？
- 该直接实现，还是先出规格文档？
- 哪一步必须等人工确认？
所以我没有把所有请求塞进统一流程，而是设计了三轴分类体系，让不同场景的请求匹配对应的协作规则：
- Workflow Level: L0 | L1 | L2 | L3
- Change Type: QUESTION | FEATURE | SMALL_CHANGE | BUG_FIX
- Doc Mode: QUESTION_RECORD | FULL_SPEC | CHANGE_RECORD | HOTFIX_RECORD
在启动规划、任务生成或编码前，初始化后的项目会先输出一组判定信息：Requested Level、Final Level、Change Type、Doc Mode、Workflow、Human Gate、Reason、Scope Signals、Escalation Note—— 先明确规则，再推进执行。
关键设计：不是 “越高级越重”，而是按场景调 “摩擦力”
分级不是线性的 “从轻到重”，而是按场景路由到不同工作流。
默认映射规则如下：
- L0 → QUESTION + QUESTION_RECORD
- L1 → FEATURE + FULL_SPEC
- L2 → SMALL_CHANGE/BUG_FIX + CHANGE_RECORD
- L3 → BUG_FIX + HOTFIX_RECORD
我想解决的不是 “要不要写 spec”，而是 “这次请求该写多重、多完整、哪一种形态的 spec”。这里的 “摩擦力”，本质是对协作过程的可控约束：
- 需要落地多详细的文档？
- 要不要走完整的 Plan/Spec/Tasks 流程？
- 人工确认放在哪个节点？
- AI 能推进到哪一步？
- 最后要留存什么类型的记录？
接下来拆解每一级的核心定位，更清晰地理解这种 “场景化摩擦力”：
L0：先澄清分析，别滑进直接实现
L0 对应「QUESTION + QUESTION_RECORD」，核心用于问题澄清、调研分析、方案对比、逻辑解释 —— 先把问题说清楚，而非直接写代码。
它的 “摩擦力” 体现在：
- 分析结果 / 问题记录必须落地为.md 文件；
- 明确记录结论、证据和下一步建议；
- 若后续要进入实现阶段，需先确认分析结果，再重新分类为 L1/L2/L3。
保留 L0 的核心目的，就是避免 “本来只是问问题，最后却顺手改了代码” 的失控场景。
L1：完整 Feature 流程，规格最完整
L1 对应「FEATURE + FULL_SPEC」，是这套规范里最完整的主链路：Context → Plan → Spec → Tasks → Code。
作为正式功能从需求到实现的全流程，L1 会设置关键的人工门禁：Plan、Spec、Tasks 阶段都需等待用户确认，且只有这些文档落地为具体文件后，编码才能启动。
这不是为了拖慢开发，而是正式功能最忌 “边界没清、约束没对齐、任务没拆稳就编码”—— 足够的 “摩擦力”，是为了后续少踩坑。
L2：基于已有 Spec 的低范围变更
L2 是最容易被误读的层级，它对应「SMALL_CHANGE + CHANGE_RECORD」，且有个硬性规则：只有存在可复用的 feature spec 时，请求才能走 L2。
它的核心是 “低摩擦演进”：已有规范兜底，无需重走完整 FULL_SPEC，但仍需写 Change Record，通过受控的任务入口推进 —— 既避免裸改，又不浪费冗余流程。若改动超出 “小范围” 或无可用 spec，需升级回 L1。
L3：聚焦最小安全补丁
L3 也常被误解为 “最复杂的改动”，实则对应「BUG_FIX + HOTFIX_RECORD」，仅用于 “最小安全补丁” 场景。
它的 “摩擦力” 体现在 “最小闭环”：先定位故障范围、输出最小补丁方案、形成 Patch Proposal，经确认后再编码 —— 既保证 hotfix 的效率，又不丢失边界控制。若补丁超出 “最小安全修复” 范畴，需升级到 L2 或 L1。
对已有项目友好：不推倒重来，只平滑接入
真实场景中，大多数团队面对的是跑了很久的存量项目：代码有历史包袱，想尝试 AI 协作，但仓库没有统一入口和规范。
所以这个工具的核心设计之一，是能平滑接入已有仓库，而非要求推倒重来。
最短使用路径非常克制：
- 把 Skill 安装到 $CODEX_HOME/skills/；
- 在 Codex 中打开目标项目根目录；
- 显式触发 $bingo-spec-coding-max-skill；
- 先执行 dry-run 验证效果；
- 确认无误后执行 apply 落地。
常见使用路径分两种：
- 首次初始化：--dry-run → --apply；
- 已初始化项目升级：--dry-run --upgrade → --apply --upgrade。
我想做的从来不是 “只讲理念的方案”，而是能真正落地到现有仓库的初始化入口。
适合谁用？
如果你正处于这些场景，这个工具或许能帮到你：
- 已经高频使用 AI Coding，但开始感受到后期失控；
- 喜欢灵活的 vibe coding，但想兼顾项目可维护性；
- 想让存量项目具备 Spec Coding 能力，而非从零重构；
- 不想把流程搞成 “一刀切” 的重模式，但也不愿完全无规范；
- 希望不同类型的请求（问题咨询 / 功能开发 / 热修复）匹配不同强度的规范；
- 希望团队成员和 AI 都能从统一的上下文开始协作。
它的核心适用场景也很明确：新仓库从第一天落地 Spec 驱动协作、存量仓库补充 AI 可读的 spec 骨架、团队统一 Codex/GPT/Claude 的协作入口、区分高 / 低风险改动的处理流程、在多技术栈仓库自动生成 SPEC_CONTEXT 草稿。
最后
我做「bingo-spec-coding-max-skill」，从来不是为了把开发流程变重，而是想让开发者可以用简单的方式让项目从 vibe coding 过渡到 spec coding，而不增加开发者的心智负担。
如果你认同这种的思路，欢迎试用这个技能，也希望能给项目点个 Star—— 这不仅是对我持续维护的支持，也是对这种协作方式的认同。
🔗 项目地址：github.com/likai457661…
