Claude Code 最后 30% 怎么收尾：过了 70% 墙别再加提示词

Claude Code 常把项目推到约 70% 可用，剩下是决策与品味而非生成。本文给出 FIXES.md 扫描、核心路径分诊、新会话评审与「信任但核实」的收尾流程。

Claude Code 最后 30% 怎么收尾：过了 70% 墙别再加提示词

社区把现象叫 70% 墙：Claude Code 一夜拉起 MVP 之后，Bug、缺口、半对 UI 同时冒出来，越修越长，项目滑进「未完成坟场」。Valerie 在 2026-07 的短文点破本质——前 70% 是生成，后 30% 是决策；解法不是更长的 prompt，而是你接手做取舍。

为什么会卡在 70%

模型擅长「按描述建造」。墙出现在描述耗尽处：什么叫完成、砍什么、陌生人能不能走通主路径。这些是产品感觉与判断，没法被「再聪明一点的模型」自动消掉。Claude 把你更快送到墙边；墙后本来就是人的工作。

具体表现通常有三类，别混为一谈：

类型 典型症状 该谁拍板
功能缺口 按钮点了没反应、接口 404 你决定修还是砍
品味问题 间距乱、文案生硬、配色不统一 你定标准，模型执行
架构债务 重复代码、缺测试、命名混乱 你决定「现在修」还是「发版后迭代」

若你还在用 Plan Mode 堆功能，先分清「规划生成」与「收尾决策」：规划见 Claude Code Plan Mode 什么时候用。Plan Mode 适合问边界；收尾阶段再开 Plan，往往变成「再加十个功能」的借口。

国内开发者常见额外压力：Relay 按量计费、Max 订阅有周限额。卡在 70% 还连续「再修一下」，配额烧在脏上下文上，比功能本身更伤——见 Claude Code 配额烧太快怎么办。

收尾四步（可直接照做）

1. 一次扫描，禁止边扫边修

全程走查，把问题记进单一 FIXES.md（或 Issue 列表）。扫描期间零修复。边发现边修会让列表永远没有尽头——你永远看不见终点线。

推荐 FIXES.md 模板，三列就够：

| 路径/页面 | 复现步骤 | 阻断核心路径？ |
|---|---|---|
| /login | 空密码提交无提示 | 是 |
| 设置页 | 头像上传后刷新丢失 | 否 |

扫描顺序建议固定：注册/登录 → 主功能一次完整操作 → 退出/再次进入。别从设置页边角开始，容易把「阻断项」漏到列表底部。

2. 残忍分诊

只问一句：它是否阻断核心路径（新用户必须端到端完成的那一件事）？否 → 线下列出，允许带着已知问题发版。没人会先注意到你在意的第十二个边角。

分诊时可画一条「演示脚本」——你能在五分钟内口头讲给陌生人听、且对方能跟着点完的路径。凡是不在这条线上的，默认 P2 及以下。典型可砍项：深色模式、多语言、导出 PDF、管理后台的次要筛选项。

3. 新会话、零上下文当评审

另开一个 Claude 会话，明确角色：

你是评审，不是作者。只走核心路径，列出会坏的点。不要改代码。

建造会话对自己的假设是盲的；新鲜会话不是。评审会话里只给：演示脚本、FIXES.md、必要时的入口 URL 或启动命令。别粘贴整仓代码——评审要的是「用户视角」，不是「作者辩护」。

若用 CodePass 等 Relay，评审会话可换更便宜的模型档位，建造用强模型、评审用中等模型，成本更可控。

4. 信任但核实

它说文件写了 → 你打开看。它说测试过了 → 你本地跑。从 70% 起你在调试的是信念，不只是代码。

核实清单（发版前至少过一遍）：

  • git diff 里有没有意外改动的配置文件
  • 核心路径手动点一遍（含移动端宽度，若面向国内用户常需测微信内置浏览器）
  • 环境变量是否仍指向本地 mock 而非生产
  • 日志里有没有硬编码的测试密钥

这和「约束 vibe coding」同一精神：生成要快，验收要狠——见 如何约束 vibe coding。

一张表：生成期 vs 收尾期

生成期（~70%） 收尾期（~30%）
主问题 能不能做出来 该不该留、好不好用
Claude 角色 建造者 评审助手 / 列表整理
你的角色 提需求 拍板、砍需求、走主路径
会话策略 可长对话 常新开「评审会话」
成功标准 功能存在 核心路径可演示
典型耗时 几小时到一夜 往往比生成期更长，但应可控
配额策略 可开 YOLO 提速 关自动写，点名修高优项

反模式：用更多 Agent 循环硬闯墙

  • 同一会话里连续「再修一下」二十轮 → 上下文脏、配额烧、假设叠加
  • 不写 FIXES.md 只靠聊天记忆 → 问题重复出现
  • 追求「零已知问题」再上线 → 坟场项目标准死法
  • 把品味问题交给模型投票 → 得到平均解，失去产品棱角
  • 评审与建造混在同一会话 → 模型开始「自证没问题」，列表变短假象
  • 国内网络不稳时反复重试同一条失败命令 → 每次重试都占上下文，先查代理/超时再让 Agent 跑

国内开发者实操注意

  • Relay 环境：收尾阶段减少 read 整仓；只 @ 相关文件，和 上下文窗口管理 一致。
  • 时区与协作：FIXES.md 提交到 Git，比截图发群更可追溯；海外协作者也能按同一列表分诊。
  • 备案/合规产品：核心路径若含用户数据，收尾时单独列「数据出境/存储」项，别指望模型自动合规。

常见问题

换更强模型能越过 70% 墙吗？

能把「可描述的缺口」再多补一点，但「什么叫够好」仍要人定。别指望单靠升杯过墙。Opus 能修好更多 Bug，不会替你决定要不要做第十二个设置项。

FIXES.md 要写多细？

细到「路径 + 复现 + 是否阻断核心路径」三列即可。别写成小说。若复现需特定账号，写测试账号规则，别写生产密码。

收尾还要不要开 YOLO/自动改文件？

扫描与分诊阶段关自动写；只在你点名的高优先级项上开短会话修复，修完立刻跑核心路径回归。一项修完就 commit，方便回滚。

核心路径只有一条吗？

小产品通常一条「aha 时刻」路径就够。B 端可能两条（管理员 vs 普通用户），但每条都要能五分钟内演示完，否则说明范围还没收拢。

评审会话发现新问题，要全部修吗？

新问题写回 FIXES.md 再分诊一轮。别在评审会话里当场开修——又会滑回建造模式。

参考资料