我现在很少读完长文章了，但这套“新需求四步法”我愿意抄作业
你有没有这种状态：
- 长文章懒得看完，直接丢给 Agent 摘要
- 新需求来了，直接对模型说“我想让它能 XX”
- 然后模型哐哐一顿输出，跑起来发现：不对、全不对
这篇给你一套更“人类”的节奏。
目标很明确：新需求来了，你能更快落地，少返工，少熬夜 😮💨
我把它拆成三块：
- 一套固定的「新需求四步法」（第 4 步是灵魂）
- 三个常见大坑，怎么躲
- Claude + Codex 组合拳：让第二个模型当你的“盲区扫描器”
你要准备的文件结构（照着建就行）
在项目里放一个 docs/ 目录。别搞复杂，先用这三个文件撑起流程：
docs/spec.md：需求规格说明docs/prompt_plan.md：拆解后的可执行 prompt 清单docs/todo.md：跨会话待办，防止你第二天忘光
你会发现：写对文档，比让模型多写 300 行代码更值钱。
新需求四步法：每来一个需求就固定跑一遍
1）用一张表，把“模糊需求”压缩成可讨论的句子
别急着打开编辑器。
拿 10 分钟填一个小表格，逼自己把每个场景写成“一行人话”。写不出来的，就说明需求还在飘。
你可以直接复制这个模板：
| 场景 | 谁在用 | 现在的痛点（一句话） | 期望结果（一句话） | 不做也行的部分 |
|------|--------|----------------------|-------------------|----------------|
| A | | | | |
| B | | | | |
判断你写得够不够硬：
- 痛点能不能落到具体动作？（比如“要点 6 次才能完成”）
- 期望结果能不能验收？（比如“3 步内完成，并给出失败原因”）
写不清？很好。留到下一步让模型把你“拷问”出来。
2）Brainstorm → 产出 docs/spec.md（这一步最值）
打开 Claude Code 的 Plan Mode（Shift + Tab 或 /plan）。
把你刚才的表格丢进去，让它做一件事：不停追问你。
你要的不是它“聪明地猜”，你要的是它把这些东西问清楚：
- 功能边界：什么算做到了？什么坚决不做？
- 输入输出：输入长什么样？输出要给用户什么？
- 错误处理：失败怎么提示？要不要重试？
- 性能上限：一次处理多少？超了怎么办？
你会明显感觉到：这一步做扎实了，后面写代码像开挂。
docs/spec.md 可以长一点，没关系，它就是用来把不确定性写死。
3）Plan → 拆成可执行的 prompt 序列，写进 docs/prompt_plan.md
别让模型“一次性把全部做完”。一次性做完的代价通常是：一次性返工 😅
让模型把 spec.md 拆成 5~10 个可独立实现、可独立测试 的小步子。
每一步都要配：
- 目标
- 涉及文件
- 验收方式（怎么确认做对了）
- 一段可直接复制执行的 prompt
示例结构：
## Step 3 - 实现 Provider 层的统一接口
- 目标：统一不同模型的调用方式，屏蔽差异
- 文件：src/providers/*
- 验收：新增 2 个 provider 的单测通过，README 示例可运行
- Prompt：
"""
你现在要在现有代码里加入 Provider 抽象层...
"""
顺手维护 docs/todo.md：把跨会话的坑写进去。
比如：
- [ ] 某个边界 case 还没想清楚，明天补
- [ ] 某个重构要等功能稳定再做
4）把每条需求映射到架构层：一句话决定“改哪里”
这一步是核心。
很多人返工，不是因为代码写得烂，是因为改错了地方。
给你一套“落点判断句式”。每条需求都用一句话拍板：
- 强隐私 → 去强化本地记忆模块（不要让数据到处飞）
- 多模型接入 → 落到 Provider 层（别把逻辑散在业务代码里）
- 稳定性 / 不要半夜炸 → 测试 + 定时任务（别迷信“跑通一次”）
- 新能力（新工具、新动作） → 写
SKILL.md或做一个 MCP server（最常见落点） - 只是规则约束 → 改
CLAUDE.md，别写代码（真的，别手痒）
你会发现：这一步做对了，代码库干净很多。
三个大坑：踩一次就够了
坑 1：把别家的项目整套搬过来
典型事故：
- 看到别人的项目很完整
- 想把它的依赖、模块、目录结构一股脑塞进来
- 然后跨版本冲突、依赖爆炸，一个晚上没了
更稳的做法是三层判断：
- 思想级：理解思路，然后用你的项目语言重写
- 模块级：只拿独立模块（可单独测试、边界清晰）
- 文件级：极少数情况原样复用
整套搬运的性价比极低，别折磨自己。
坑 2：CLAUDE.md 写太啰嗦
规则写到 300 行以上，常见后果：
- 挤占上下文
- 模型遵循度下降
- 你越写越累，它越不听
处理方式：
- 规则尽量结构化、短句化
- 命名规范、格式化交给 linter
一句话送你：别让 LLM 干 linter 的活。
坑 3：跳过 spec，直接让 AI 写代码
你对模型说：“我想让它能 XX”。
模型会自动脑补一整套世界观，然后写出一堆“看起来很对”的代码。
跑起来不像你要的？你还得反复解释、反复推倒。
更好的解法：
- 把需求表写出来
- 让模型反复追问
- spec 里把边界写死
这一步省的不是时间，是心态。
Claude + Codex 配合：把“训练分布差异”变成免费 QA
你不需要纠结哪个模型更聪明。
关键是：让两个训练背景不同的模型互相找茬。
做法很实用：把 Codex 注册成 Claude Code 的 MCP server，让 Claude 在不离开会话的情况下调用 Codex 做 review。
配置（3 步）
- 安装并登录 Codex CLI
- 在 Claude Code 里运行：
claude mcp add codex -- codex mcp
- 重启 Claude Code 会话
搞定。
实战用法 1：Spec Review（超推荐）
把这段话丢给 Claude：
用 codex review 一下 docs/spec.md 和 docs/prompt_plan.md。
重点看：需求歧义、边界情况、跟现有架构的冲突。
把修改建议逐条评估：
- 同意的直接改
- 不同意的告诉我理由
最后把需要我拍板的点列出来。
你会得到一种很舒服的体验：
- Codex 提建议
- Claude 逐条 challenge
- 你只负责最后裁判
全程不切终端。
实战用法 2：双模型拆任务，对照找漏洞
同一份 spec.md：
- 让 Claude 拆一版
- 让 Codex 也拆一版
- 对照两份计划：哪里不一致，哪里就是风险点
这招特别适合：
- 涉及数据迁移
- 涉及边界条件
- 改动会影响主流程的需求
一份你可以直接照抄的执行清单 ✅
每来一个需求，照着做：
- [ ] 填需求表（10 分钟，压成一句话）
- [ ] Plan Mode 把问题问清，写
docs/spec.md - [ ] 拆成 5~10 步，写
docs/prompt_plan.md - [ ] 每条需求用一句话映射架构层（决定改哪里）
- [ ] 接入 Codex 做 spec / plan review，抓盲区
- [ ] 开写代码（这时候写才顺）
你会得到什么变化？
- 需求更清楚：模型不靠猜，你也不靠“感觉差不多”
- 改动更集中：该改规则就改规则，该做能力就做 MCP/Skill
- 返工更少：因为边界和验收在写代码前就定了
如果你愿意，我也能按你现在的项目类型（Web / CLI / Agent / MCP 工具）给你一份可直接用的 spec.md 模板和 prompt_plan.md 模板，让你复制就开跑。🙂
