喵码

你要解决的问题

「这个需求太简单了，直接写代码吧」——这句话大概是返工的开端。一个工具函数、一次配置改动，看起来没什么风险，实际上藏着一堆没被审视的假设：成功标准是什么？边界在哪里？什么算做完？等代码写完才发现验收标准从没定过，改需求的成本已经翻了倍。

另一个常见问题是 spec 与实现同步推进：需求刚说一半就开始建文件，最后没人说得清哪条功能需求对应哪个测试。

技能的工作方式

这套技能把开发拆成四份递进文档，每一份都要用户明确批准后才能进入下一份，细节逐层增加。

• spec.md：回答「做什么」。包含背景、目标、功能与非功能需求、边界、验收标准。写作时聚焦行为描述而非接口签名，保持语言无关，每条功能需求至少对应一条验收标准。
• plan.md：回答「怎么做」。在这一层定义数据结构与方法签名、模块交互、文件组织和技术决策及其理由。这份文档与具体语言相关。
• task.md：回答「按什么顺序做」。列出文件清单和有序任务，每个任务是一个 2-5 分钟的聚焦工作单元，必须自带验证步骤，并标明依赖关系。
• checklist.md：回答「做对了没」。条目写成「运行 X，期望 Y」，与实现解耦，至少包含一个端到端场景。

四份文档全部通过审批之前，禁止编写任何实现代码，无论项目看起来多简单。需求澄清阶段一次只问一个问题，能用选择题就不用开放题；每份文档逐段呈现，每段确认后再展示下一段。进入开发后按 task.md 执行，每个任务先跑验证再报状态，验证不通过就先修。

适用边界与注意点

文档可以写得短，但必须存在且必须被审批——这是它唯一的硬性要求，也是最容易被跳过的地方。checklist 必须在编码前设计，事后补等于把验收标准建立在已经写好的代码之上，失去了约束意义。

注意几点：spec.md 保持语言无关，方法名和文件路径分别留给 plan.md 和 task.md；遵循 YAGNI，只设计和实现 spec 提到的内容；结论必须来自命令输出，而不是「应该没问题」；被阻塞就停下来问，不要猜。

代价方面，对一次性脚本或纯探索性片段，四段审批可能比重写还慢。判断标准很简单：这段代码两周后还需要改动吗。需要，流程省下的就是返工。