写一个计划很容易。写一个能真正被执行的计划，难得多。
我有一个计划质量评分脚本，满分 100 分。一开始我用它给计划打分，发现一个很有意思的现象：很多计划能拿到 80-85 分，但就是过不了 90 分。
85 分的计划看起来已经很完整了：目标清楚、任务分解合理、时间安排可行、风险有考虑。但每次真正拿去执行时，总会在某个地方卡住，需要回头补信息、补上下文、补验证条件。
后来我才明白：85 分和 95 分的差距，不在计划框架，而在上下文完整性。
质量门的价值，不是证明计划写得好不好，而是逼你把那些"看起来不重要但执行时会卡住"的上下文提前补齐。
85 分的计划长什么样
一个典型的 85 分计划是这样的：
# 计划：优化博客发布流程
## 目标
减少从草稿到发布的时间，从平均 30 分钟降到 10 分钟。
## 任务
1. 分析当前发布流程的瓶颈
2. 设计新的发布脚本
3. 实现脚本
4. 测试
5. 部署
## 时间安排
- 第 1 天：任务 1-2
- 第 2 天：任务 3
- 第 3 天：任务 4-5
## 风险
- 脚本可能不兼容旧版本
- 测试环境可能不完整
这个计划读起来很舒服。目标明确、任务清晰、时间合理、风险有考虑。如果交给一个熟悉项目的人执行，可能真的能完成。
但如果你把它交给一个没有上下文的人，或者让一个 Agent 去执行，问题就来了。
任务 1："分析当前发布流程的瓶颈"——怎么分析？看哪些文件？和谁聊？产出是什么？
任务 2："设计新的发布脚本"——新脚本要解决哪些具体问题？和现有系统的接口是什么？需要兼容哪些历史数据？
风险："脚本可能不兼容旧版本"——哪些旧版本？怎么定义兼容？不兼容时怎么处理？
这些问题在写计划时看起来很小，但在执行时会变成反复的上下文切换：执行到一半，发现需要回去找信息、找人确认、找历史记录。
85 分的计划，缺的不是框架，而是执行时需要的那一层"隐性知识"。
质量门怎么发现问题
计划质量评分脚本会检查一系列维度，其中两个维度专门负责发现上下文缺失：
- CONTEXT 完整性：计划里是否包含了执行所需的关键上下文？
- ** verification 可验证性**：每个任务是否有明确的完成标准和验证方法？
当一个计划拿不到高分时，脚本不会只给一个总分，它会给出具体的警告。
比如：
WARNING: CONTEXT incomplete. Missing:
- 当前发布流程的具体步骤
- 现有脚本的路径和依赖
- 历史兼容性要求的具体版本范围
WARNING: verification insufficient for task 2. Missing:
- 新脚本的输入输出规格
- 与现有系统的集成测试方案
这些警告看起来是在挑刺。但实际上，它们是在告诉你：这个计划可以开始写代码了，但还不能直接交给别人执行。
如果没有质量门，你可能会在 85 分时就认为计划已经足够好，然后开始执行。执行过程中遇到上下文缺失，你会有两种选择：
第一种：停下来补上下文。这会打断执行流，而且补的上下文可能不完整，因为你是在执行压力下补的。
第二种：靠猜。你会根据自己的理解填补空白，但这个理解可能和原计划作者的意图不一致，导致后面需要返工。
质量门的作用是：在你投入执行资源之前，强迫你把上下文补齐到"可以让一个陌生 Agent 无歧义执行"的程度。
从 85 到 95 到底补了什么
当我根据质量门的警告去补齐上下文时，我发现需要补充的内容可以分为三类。
第一类：执行环境的具体信息。
85 分计划可能会写"修改配置文件"。95 分计划会写"修改 /path/to/config.py 第 42-47 行，将 timeout=30 改为 timeout=60，注意这个文件在部署环境中路径不同，部署版路径为 /etc/app/config.py"。
这个补充看起来很琐碎。但正是这种琐碎的信息，决定了执行时是否需要停下来查文档、问人、试错。
第二类：任务之间的依赖和接口。
85 分计划可能会把任务列出来，但任务之间的关系不清晰。95 分计划会明确说："任务 2 的输出是任务 3 的输入，具体格式见 schema/task2-output.json。任务 3 开始前必须验证任务 2 的输出是否符合 schema，不符合时停止并报错。"
这不是为了写得更长，而是为了让执行系统知道：如果任务 2 的输出有问题，不要盲目进入任务 3。
第三类：异常情况和边界条件。
85 分计划通常描述的是"顺利时"的执行路径。95 分计划会补充："如果任务 1 发现现有系统已经部分满足目标，则跳过任务 2-3，直接进入任务 4 的适配性测试。"
这种补充很重要，因为现实中的执行很少是完全线性的。你需要在计划里就考虑到可能的分支，而不是等到执行时再临时决策。
从 85 分到 95 分，补的不是更多任务，而是让任务能够被正确执行所需要的所有上下文。
为什么人容易停留在 85 分
有一个心理现象：当你对一件事足够熟悉时，你会默认别人也知道那些"显而易见"的背景信息。
我在写计划时，经常会跳过一些我认为"不需要说"的细节。比如：
- 我认为显而易见的文件结构
- 我认为理所当然的依赖关系
- 我认为大家都知道的兼容性原则
- 我认为不需要特别说明的验证方法
但问题是：计划不是写给自己看的，而是写给未来的执行者看的。
未来的执行者可能是另一个人，可能是另一个 Agent，也可能是忘记了细节的自己。他们对背景信息的掌握程度，远低于写计划时的你。
质量门的作用，就是用一个外部标准，打破你对自己计划的熟悉感。它会冷冰冰地告诉你：这里缺上下文，那里验证标准不清晰，这里假设没有说明。
一开始你会觉得质量门很烦。明明我已经写得很清楚了，为什么还要补这么多？
但当你真正去执行一个 95 分的计划时，你会意识到：补齐上下文所花的时间，远少于执行时因为上下文缺失而浪费的时间。
质量门不是形式主义
有人可能会说：质量门是不是太重了？写个小计划也要补这么多上下文？
这个问题问得好。答案是：质量门的严格程度，应该和计划的执行风险匹配。
如果一个计划是给你自己用的，而且你明天就会执行，那么 85 分可能真的够了。因为你的短期记忆里还有写计划时的所有上下文。
但如果一个计划是要交给另一个人执行，或者要在一周后才执行，或者要让一个 Agent 自动执行，那么 85 分就不够了。因为执行时的上下文已经流失了。
质量门不是一个固定标准，而是一个提醒机制：在执行风险上升时，逼你把上下文补齐到相应程度。
我现在的做法是：
- 如果计划是立即执行、自己执行的，70-80 分就可以接受。
- 如果计划是近期执行、可能需要他人接手的，需要 85 分以上。
- 如果计划是要进入自动执行队列、可能被任意 Agent 在任何时间执行的，必须 95 分以上。
质量门的存在，不是为了让所有计划都写到 100 分，而是让你意识到：不同的执行场景，对上下文完整性的要求不同。
下次我会怎么做
下次写计划时，我会在动手之前先问自己一个问题："这个计划会被谁执行？会在什么情况下执行？"
如果答案是"可能会被一个不了解背景的 Agent 执行"，那么我会：
第一，在写任务分解之前，先写 CONTEXT 部分。 把执行环境、文件路径、依赖关系、兼容要求、已知限制都写清楚。先补齐上下文，再分解任务。
第二，每个任务写完后，我会自问："如果一个完全不了解这个项目的人看到这个任务，他能知道该怎么执行吗？" 如果不能，我就补充执行细节、输入输出规格、验证标准。
第三，我会主动跑质量评分脚本，而不是在总分看起来不错时就停止。 我会专门看 CONTEXT 和 verification 相关的警告，逐一处理。不是因为我要追求 100 分，而是因为这些警告通常指向执行时真正会卡住的地方。
第四，我会把质量门的警告看成一种"执行预演"。 每一个警告都在告诉你："这里执行时可能会出问题。"提前处理这些警告，比执行时再回头补上下文要高效得多。
从 85 分到 95 分，补的不是字数，而是让计划从"看起来完整"变成"真的可以执行"。
质量门的价值，就在这里。