企业官网建设流程全解析

先把话撂这儿：一份三十页、面面俱到的方案文档，八成活不过第三天，就被写它的人自己推翻了。我更信另一条路——先拆出一个能跑起来的最小闭环，再往上长。我做的雷达鸭 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 核心意图必须是 I13，D1 任务领域决定用哪套专业语境，D3 交互轮次决定是单轮交付还是长程迭代，D4 输出期望决定给方案还是给清单，再加上任务要点和交付预期。六个字段，撑起整条规划链路。

那什么时候还是得先写大方案

不抬杠，确实有。

需要对外立项、走预算审批的场景，对方要的就是那份厚文档，你给一页纸的纲要人家不认。还有强合规领域——医疗、金融那类，方案不完整根本进不了评审。这两种情况下大方案是交付物本身，不是过程产物，性质完全不一样。

即便如此，我依然会先在内部走一遍门①。方向确认的成本是一页纸，太便宜了，没理由跳过。

另一个例外是需求极度确定的重复性工作。第五次做同类型的数据迁移，闭着眼睛都知道要分几步，这时候纲要确认门就是纯粹的额外开销，直接出清单就行。tri-plan 允许这么干，前提是你真的确定，而不是自我感觉确定。

收个尾

规划这事的难点从来不是「写得不够全」，而是「在错的方向上写得太全」。三道门存在的意义，就是让每一次推翻的代价小到你愿意承认自己错了。

下次接到一个模糊需求，别急着开新文档写第一章。先问一句：这个目标，别人能不能一字不差地复述出来？答不上来，那就还不到拆解的时候。

关于我

老三，十来年软件开发经验，软件设计师、人工智能应用工程师，主要做鸿蒙 ArkTS 北向开发和 Web 前端。平时折腾 AI 自动化这块，攒到点东西就在 CSDN 上写写。

本文遵循 MIT 协议，转载请注明出处。

安装

请根据 https://skillhub.cn/install/skillhub.md，安装 tri-plan。