先把话撂这儿一份三十页、面面俱到的方案文档八成活不过第三天就被写它的人自己推翻了。我更信另一条路——先拆出一个能跑起来的最小闭环再往上长。我做的雷达鸭 App需求规划就是走的这套流程一个收录中国一人公司真实赚钱案例的应用华为应用市场和微信小程序都能搜到。它的第一版功能清单不是坐在那儿想出来的是被一道道确认门逼出来的。这套流程被我固化成了一个 skill叫 tri-plan。它对应 tri-intent 意图体系里的 I13 规划拆解——用户说「拆解这个项目的开发任务」「制定三个月学习计划」「设计系统架构方案」都会落到这条线上。大方案的问题不在长在于它假装自己是对的我见过太多这样的开局需求一句话方案先写八千字。架构图画得漂亮风险表列了十二行看着特别专业。然后第二天用户补一句「哦对了我们的数据是从第三方拉的没有写权限」前面那八千字里有一半直接作废。问题出在哪出在方案的长度和它的正确性没有一毛钱关系。写得越长沉没成本越高越舍不得推翻到头来就变成硬着头皮往下走。我个人特别烦这种局面——明知道方向偏了但因为文档已经写到第七章只好装作没看见。tri-plan 里有一条铁律我把它写死在了执行契约的第一条没有明确的目标与验收标准就没有任务拆解——目标含糊时拆得越细越偏离。这句话是我拿返工换来的。有一次我给一个内部工具做规划目标写的是「提升团队协作效率」我照着这个拆了 40 条任务拆得工工整整。评审的时候被问了一句「怎么算提升了」我答不上来。那 40 条里活下来的不到 10 条。如果让我重来我会在动笔拆解之前就把这句话摁死。三道门把大方案切成三个最小闭环tri-plan 的链路长这样plan-brief.md → 门①规划方向确认 → plan.md → 门②规划审计 → task-checklist.md → 门③交付前确认 → 交付刚设计的时候我自己都觉得这三道门有点形式主义一个规划而已至于分三次确认吗跑了几轮才明白这三道门本质上就是三个最小闭环每一道门都产出一个能被独立审查、能被单独推翻的东西推翻的代价被控制在一小段内而不是整份方案。门①的产物是plan-brief.md规划纲要。它只干一件事把目标、范围、约束、验收标准的骨架、里程碑草案摆出来让用户看一眼方向对不对。这个文件很短短到用户愿意认真读完——这点比什么都重要。方向错了扔掉重写的成本就是这一页纸。目标校准用的是 SMART 五维我做成了一张表每一维必须有校准结果和达标判定# plan-brief.md § 一、规划目标SMART 校准goal_statement:两周内上线 App 首页的案例卡片流支持按行业筛选首屏渲染在 1.5s 内smart:specific:question:目标是否无歧义他人可一致复述result:首页卡片流 行业筛选 首屏性能三项范围明确pass:truemeasurable:question:如何判断达成result:首屏 1.5s 内可交互筛选后列表刷新无白屏pass:trueachievable:question:资源与约束是否支撑result:UniCloud 现有接口可复用无需新增服务端开发pass:truerelevant:question:是否与交付预期对齐result:对齐快照「交付预期可执行任务清单」pass:truetime_bound:question:何时完成result:里程碑 M1 第 7 天M2 第 14 天pass:true只要有任何一维pass: false流程就卡在门①不许往下走。这个卡点救过我不止一次。门②才产出plan.md那份真正意义上的「完整规划」WBS 分解、依赖图、里程碑、风险登记、逐任务验收标准九个章节。注意顺序——它是在方向已经被确认之后才写的所以这八千字不会白写。这就是我说的「先拆最小闭环反而更稳」不是不写大方案是把大方案往后放等它站在一个被验证过的地基上再写。WBS 不是把任务写得越细越好拆解这一步我踩过的坑是把颗粒度当成 KPI。任务拆到「打开 IDE」这种级别看着很勤奋实际没人能执行。tri-plan 里定了四条分解原则我觉得最有用的是前两条可独立执行叶子任务不依赖同层任务的中间产物和粒度适中工作量能预估太大继续拆太小合并。另外两条是 100% 覆盖同层 MECE无遗漏无重叠和验收可判。依赖标注用四个符号→完成-开始⇒开始-开始⇐完成-完成⇢外部依赖。别小看这几个箭头标清楚之后能直接做无环校验——依赖图里出现环就说明拆解方式有问题得回去重构而不是硬着头皮往下排期。我第一次跑无环校验的时候真检出过一个环A 任务的验收需要 B 的产物B 的前置又写了 A两边都觉得对方先来。门③的产物是task-checklist.md最终交付物。每个任务条目六个字段一个都不能少## 阶段 2卡片流实现 **【阶段依赖】** 前置阶段 1完成-开始 →| 本阶段阶段 2 ### 任务 2.1实现案例卡片组件 - **编号**2.1 - **描述**基于 UniCloud 返回的案例数据结构实现卡片组件含封面图、标题、行业标签、月收入区间四个字段的展示 - **验收标准**传入 mock 数据可正常渲染字段缺失时显示占位符不报错单卡片渲染耗时 16ms - **依赖标注**1.3 → 完成-开始数据结构定稿后方可开工 - **建议执行 skill**tri-coding - **完成状态**- [ ] ### 任务 2.2接入行业筛选 - **编号**2.2 - **描述**顶部行业标签栏点击后按 industry 字段过滤列表 - **验收标准**切换标签列表正确过滤无匹配结果显示空态切换过程无白屏 - **依赖标注**2.1 → 完成-开始 - **建议执行 skill**tri-coding - **完成状态**- [ ]这里有个容易误解的地方我在 skill 里特意写了注释说明那个复选框指的是规划交付确认不是任务本身执行完了。规划归规划执行归执行tri-plan 只出方案不写代码不执行操作——真要动手任务里标的建议执行 skill会把它交给 tri-coding 或者 tri-action。门③交付之前还有两个必问项要不要调其它 skill 协同有没有要补充的约束或素材。这两问看着啰嗦但它是交付前那次成本最低的纠偏机会。用户如果这时候甩出一句「对了这个项目得兼容微信小程序」改任务清单还来得及等 tri-coding 已经写了三天代码再说那就是另一个故事了。一个我犹豫了很久的硬性设计tri-plan 支持单独安装但激活的时候会先检测上游 tri-intent 在不在。检测结果只有两态能找到快照或者能找到 tri-intent 目录走标准的快照模式两个都没有直接阻断提示先去装 tri-intent。没有降级模式。这个决定我反复改过好几次中间有一版是允许降级的——找不到快照就自己临时问几句凑出目标。跑下来发现降级模式产出的规划质量掉得厉害因为它拿到的目标是我自己脑补的不是经过意图识别和澄清对齐过的。规划这活儿输入质量决定一切输入含糊输出必歪与其给一个看着能用实则跑偏的结果不如干脆卡住。快照里真正被读走的字段其实不多L2 核心意图必须是 I13D1 任务领域决定用哪套专业语境D3 交互轮次决定是单轮交付还是长程迭代D4 输出期望决定给方案还是给清单再加上任务要点和交付预期。六个字段撑起整条规划链路。那什么时候还是得先写大方案不抬杠确实有。需要对外立项、走预算审批的场景对方要的就是那份厚文档你给一页纸的纲要人家不认。还有强合规领域——医疗、金融那类方案不完整根本进不了评审。这两种情况下大方案是交付物本身不是过程产物性质完全不一样。即便如此我依然会先在内部走一遍门①。方向确认的成本是一页纸太便宜了没理由跳过。另一个例外是需求极度确定的重复性工作。第五次做同类型的数据迁移闭着眼睛都知道要分几步这时候纲要确认门就是纯粹的额外开销直接出清单就行。tri-plan 允许这么干前提是你真的确定而不是自我感觉确定。收个尾规划这事的难点从来不是「写得不够全」而是「在错的方向上写得太全」。三道门存在的意义就是让每一次推翻的代价小到你愿意承认自己错了。下次接到一个模糊需求别急着开新文档写第一章。先问一句这个目标别人能不能一字不差地复述出来答不上来那就还不到拆解的时候。关于我老三十来年软件开发经验软件设计师、人工智能应用工程师主要做鸿蒙 ArkTS 北向开发和 Web 前端。平时折腾 AI 自动化这块攒到点东西就在 CSDN 上写写。本文遵循 MIT 协议转载请注明出处。安装请根据 https://skillhub.cn/install/skillhub.md安装 tri-plan。