Awesome Spec 规约协作

要解决的问题

模型写代码或跑定时任务时，经常基于“刚才对话里提到过”的隐式记忆推进：范围靠猜、验收标准没写下来、运行窗口和失败处理没人定义。等到多人协作、跨模块改动或不可逆操作真正发生时，才发现没人能独立回答三个问题——做什么、做到什么程度算完成、出问题怎么停。awesome-spec 针对的正是这种口头规约无法留痕、不可审阅、不可验证的缺口。

它如何工作

核心思路是规约优先：在启动复杂任务前，先建立一份共同的 SPEC.md，把目标、边界、约束、决策和验收条件写死，后续的计划拆解、执行和自动化配置都以它为准。同时坚持事实优先——严格区分「已知事实 / 合理推断 / 待确认决策」，不允许把推断伪装成用户已确认。

工作流分六步：

1. 选择规约深度：在完整、轻量、自动化和“不建规约”四条路径中挑一条，不以文档篇幅衡量质量；
2. 建立事实底座：先读仓库、既有 SPEC.md、README 和历史决策，再列出事实、推断与未知项；
3. 澄清关键决策：只问会改变范围、风险或验收的高价值问题，每轮最多 4 题，并给出推荐选项；
4. 起草 SPEC.md：以 assets/SPEC-template.md 为章节基线裁剪，验收项必须带方法、证据和通过标准；
5. 质量闸门：人工核对完整性、一致性、可验证性，可用 scripts/check_spec.py 做只读结构检查；
6. 同步与交接：先向用户同步事实来源、未决项和文件路径，再输出供计划、执行或调度直接引用的交接包。

对自动化任务，还要额外补全「运行契约」：触发频率、时区、执行窗口、幂等性、重试、人工介入和停止条件，而不是只写一句“每天执行一次”。

适用边界

这套流程有明确的克制：单文件拼写修正、纯查询、明确且可逆的单步操作不触发完整规约，避免给简单任务强造冗长文档。反过来，涉及多模块、定时调度、权限变更或外部依赖的任务，即使看起来简单也不能跳过运行边界。另外，“写好 Spec”不等于“已获准执行”——涉及不可逆或对外动作时，关键缺口未补齐前不得动手。