简介：这是关于华为集成产品开发项目管理方法论的讲解文档，核心梳理了六步一法框架，面向产品经理、项目经理及研发管理者，特别适合正在推行集成产品开发模式的团队参考。文档以流程为主线，依次说明定义、计划、开发、验证、发布、学习与改善六个阶段的关键任务，并强调每个阶段末尾需通过决策评审作为控制关口，从而保障项目在进入下一环节前达到预定目标。资源包仅含一个PDF格式文件，大小3.01MB，为2008年华为内部交流材料，内容精炼、结构清晰，便于直接通读或作为培训参考资料。目前已有262人学习，说明该主题有实际借鉴价值。读者可获得完整的阶段划分标准、跨部门协作要点和风险控制方法，有助于将华为式项目管理经验应用到自身的研发项目管理与评审机制建设中。

1. 华为IPD项目管理六步一法：一份2008年的内部材料，凭什么到现在还在用

做了这些年项目经理，最怕的不是需求变更，而是流程挂在墙上没人执行。华为这套IPD项目管理六步一法，是华为公司国内项目管理部2008年7月的内部交流材料，核心就一句话：项目拆成定义、计划、开发、验证、发布、学习六个阶段，每个阶段结束设一个决策评审Gate把门。它不讲高深理论，全是能直接映射到日常项目的操作框架——每个阶段做什么、产出什么、卡什么标准，都写得足够具体。适合正在带中大型产品项目、被跨部门协作反复折磨的从业者，也适合刚转项目管理、想一次性把流程框架立起来的新手。这份材料最值钱的不是“六步”，而是那个“一法”：决策评审Gate。把Gate设计好，项目才真正有了刹车和油门。

2. 六步一法方法论拆解：六个阶段的交付物、责任主体与退出标准

2.1 定义阶段在定义什么：市场调研、需求范围与商业目标

定义阶段回答的不只是“做什么”，而是“凭什么做”。六步一法把Define放在第一位，明确要求在动工之前完成三件事：市场调研、竞品分析、需求定义与商业目标确认。放到实际项目里，我一般会让产品经理牵头先写一页纸的商业论证，把目标客户、核心痛点、预期收益和验收口径写清楚，而不是一上来就写几十页需求文档。需求规格书当然要写，但要在商业论证通过之后再展开，否则很容易写出一个市场并不需要的东西。

定义阶段的交付物可以按下面这份清单来核对。重点在于每份交付物都要有明确的验收口径，不能只交付一个“初稿”。我习惯在项目启动会上就把每份交付物的负责人和验收人当场确认，而不是等阶段末才互相推诿。这个动作省不掉，后面所有评审都依赖这些确认记录。

定义阶段还有一个动作特别容易被跳过：需求基线冻结。评审通过之后，需求并不是不能改，而是任何变更都要走变更控制流程，评估影响范围后才能决定是否接受。不冻结基线，后面每一个阶段的计划都建立在流沙上。我见过好几个项目就是因为省了这一步，需求反复变化，导致计划、成本、人员全部被动调整，最后算总账，发现最初省下的半天时间，后面花了三个月去填坑。

2.2 计划阶段：时间表、资源分配、里程碑与风险预案怎么排

计划阶段在六步一法里不等于“排个甘特图”。它要同时输出四类东西：时间表、资源分配、里程碑和风险评估，另外还要把质量标准和验收条件一并定下来。注意，质量标准必须在计划阶段定，而不是验证阶段才谈。很多项目把验收条件拖到测试开始前才讨论，结果测试用例写得像临时凑数，验证阶段漏洞百出，这就是典型的顺序错误。

计划阶段的产出，我一般会用一张评审清单来把关，避免计划会开成“看图说话”：

计划评审通过之后，时间表、资源表和风险表要作为基线冻结，之后的调整必须通过Gate或变更流程来驱动。这样做的本质是让计划拥有“契约”属性，而不是随时可改的一句话。我自己踩过的坑是计划阶段排期太满，完全没有给风险应对预留空间，结果一个关键供应商延迟两周，整个验证阶段被压到只剩一周，验证质量直线下降。后来养成的习惯是每个里程碑之间至少留出10%~15%的缓冲，专门吸收不确定性。

2.3 开发与验证：跨部门协作的技术评审与测试准入准出

开发阶段的重点不是写代码，而是协同。IPD框架下的一个典型特征是跨部门集成，落到六步一法里，就是研发、设计、测试、供应链、市场等角色在同一个计划下推进。我一般会在计划阶段就把每个部门的“项目接口人”确定下来，每个接口人对计划里属于自己部门的活动负责。这样做的好处是过程中出了问题能直接找到人，而不是开会时让部门经理临时抓人。

开发过程里要跑两种评审：一种是阶段性的技术评审，重点看设计文档、接口定义和风险项；另一种是日常的代码审查和模块联调。技术评审在IPD语境里常被称为TR（Technical Review），是保证“中间不烂尾”的关键手段。六步一法里的Gate偏决策性质，也就是常说的DCP（Decision Check Point），两者配合使用：TR埋在产品开发过程里管技术质量，Gate放在阶段边界管业务取舍。

验证阶段要回答一句话：产品是否真的达到了定义阶段设定的验收条件。验证不是简单跑一遍测试，而是几个维度并行：内部测试看功能和性能是否符合规格，用户测试看真实场景下是否可用，第三方认证看是否需要满足行业合规要求。不是所有项目都需要认证，但一旦需要，认证周期往往被严重低估，在计划阶段就提前排队，这是很多项目拿命换来的经验。

验证阶段的退出条件要量化，我通常用两个指标：严重缺陷清零，以及验收测试用例通过率达标。两个条件都满足，才算验证通过，可以进入发布Gate评审。这就是“准入准出”的含义：开发完成的准出是进入验证的准入，验证完成的准出是进入发布的准入。用准出条件管理阶段边界，比靠项目经理催进度可靠得多。

2.4 发布与学习：产品上市不是终点，复盘才是闭环

发布阶段管的是从验证通过到交付客户的全过程：生产、包装、推广、售后支持。这个阶段容易被忽略的是“支持就绪度”——产品上市了，客服团队还没有培训材料，一线反馈渠道没有建立，售后响应机制没有跑通。这些如果等到发布当天才发现，就只能用事故来补课。所以发布Gate里必须有一项：支持团队的培训记录和知识库条目已发布。

学习与改善阶段是六步一法里最容易被跳过的，但恰恰是整套方法论里最有长期价值的一环。项目结束后要做项目回顾，输出经验教训清单和改进项。关键动作是每条改进项必须指定责任人和截止日期，并落到下一个项目计划里。没有落点的复盘，只是PPT上的自我感动。

到这儿，六个阶段就串成了一个闭环：学习阶段的改进项进入下一个项目定义阶段的输入。这也是IPD“持续改进”思想的落地方式——不是靠口号，而是靠流程把上一个项目的教训强制传递到下一个项目。在实际应用中，这套方法论可以根据项目特性裁剪，比如短周期的需求型项目可以把定义和计划合并、验证和发布合并；但“每阶段有Gate、Gate有条件、条件可量化”这三条底线建议保留。华为后续在研发项目管理上也发展出过RDPM等更轻量的思路，但六步一法的骨架逻辑一直在被复用。

最后给一张速览表，把六个阶段的核心任务和退出标准集中在同一张表里。我每次启动新项目都会把它打印出来贴在看板上，它比任何流程图都实用。

3. 把六步落成项目计划：WBS、里程碑与RACI矩阵的可执行配置

方法论拆完了，接下来是把六步一法变成一张能执行的作战地图。我习惯用三件套来做这件事：WBS把阶段拆成工作包，里程碑把工作包挂到日历上，RACI矩阵把每个工作包分到具体的人。三件套上手之后，六步一法才真正从一份PDF变成项目管理的日常语言。

3.1 WBS拆解：把六个阶段拆成可验收的工作包

WBS（Work Breakdown Structure，工作分解结构）是计划阶段最底层的工作。六步一法的六个阶段天然是WBS的一级目录，不需要另起炉灶。二级目录按每个阶段的核心任务展开，三级目录是具体工作包。我平时拆WBS会坚持三条纪律：工作包粒度控制在2~5人天；每个工作包必须有一个明确的交付物；交付物必须有验收标准。没有可验证输出的活动，比如“开会讨论需求”，要改成“输出需求讨论会议纪要”，否则算不上工作包。

一个基于六步一法的WBS结构大致长这样：

• 1.0 定义阶段
  • 1.1 市场调研
    • 1.1.1 竞品分析报告（交付物）
    • 1.1.2 用户访谈纪要（交付物）
  • 1.2 需求定义
    • 1.2.1 需求规格书（交付物）
    • 1.2.2 商业论证报告（交付物）
  • 1.3 立项评审Gate（交付物：Gate自检表）
• 2.0 计划阶段
  • 2.1 项目计划编制（交付物：时间表与资源计划）
  • 2.2 风险评估（交付物：风险登记表）
  • 2.3 计划评审Gate（交付物：计划评审材料）
• 3.0 开发阶段
  • 3.1 系统设计（交付物：设计文档）
  • 3.2 原型开发（交付物：可演示原型）
  • 3.3 内部测试（交付物：测试报告）
• 4.0 验证阶段
  • 4.1 内部测试执行（交付物：缺陷记录）
  • 4.2 用户验收测试（交付物：验收报告）
• 5.0 发布阶段
  • 5.1 生产与包装（交付物：发布物料）
  • 5.2 推广与售后准备（交付物：支持手册）
• 6.0 学习与改善
  • 6.1 项目复盘会（交付物：复盘报告）
  • 6.2 改进项跟踪（交付物：改进项清单）

WBS拆完之后要做两件检查。第一，把底层工作包的交付物全部列出来，看每个交付物支持哪一个Gate的通过条件，确保没有“悬空工作包”——只干活、不支撑任何评审结论的工作包，要么合并，要么砍掉。第二，估算每个工作包的工期和人力，这一步直接与下面的里程碑设置挂钩。不要跳过这一步直接画甘特图，甘特图只是WBS的呈现方式，不是计划本身。

3.2 里程碑设置：倒排排期与缓冲期放在哪里

六步一法的六个阶段，每个阶段末尾的Gate天然就是大里程碑。但只有大里程碑不够用，我一般会在每个阶段内部再设一到两个内部检查点里程碑，用来在阶段过程中暴露问题，而不是等到Gate评审才发觉进度已经失控。内部检查点不需要像Gate那样正式，一张进度核对表就能跑，但它必须和Gate一样有明确的完成标准。

里程碑设置的实操，我用的是倒排法：先定一个业务上不能动的发布日，然后从发布日往回推每个阶段需要多长时间。倒排的时候要注意三点。

第一，每个里程碑挂一个可验证的完成标准，而不是只写日期。比如“功能完成”的标准是“所有功能开发完成且冒烟测试通过”，不是“代码写完了”。没有完成标准的里程碑，评审时就会变成主观判断，Gate也就失去了客观性。

第二，阶段之间要留缓冲。缓冲期比例我一般取10%~15%，但不是均匀撒在每两个阶段之间，而是放在高风险区域后面。从经验看，开发完成到验证开始之间、验证完成到发布之间，是两个最容易出问题的衔接带，缓冲优先放在这两个位置。计划阶段末尾也可以放一小段缓冲，用来预防“计划刚定就过时”。

第三，里程碑一旦定下来，要同步给所有干系人确认。这个动作看起来是仪式性的，实际价值很大：干系人确认过日期，后续延期时就没有“我不知道这个节点”的退路。对于跨部门协作，里程碑承诺比项目计划书更能约束行为。

3.3 RACI矩阵：跨部门协作的分工底线

跨部门协作最常见的翻车方式，不是没人干活，而是每件事都“有人参与、没人负责”。六步一法强调跨部门协作，落到具体工具上，我会用RACI矩阵来兜底。RACI是四种角色的缩写：R（Responsible）是执行人，A（Accountable）是最终负责人，C（Consulted）是需要被咨询的人，I（Informed）是只需要知会的人。

一个典型的六步一法RACI矩阵可以这样画：

用这个矩阵时有几条不成文的规矩。每个任务只能有一个A，两个部门都是A，等于没有人A；这种“双A”出现时，要把其中一个降为R，另一个留作A，或者把任务拆成两个子任务。C和I要分清楚：C是要被征求意见的，I只是通知一声。很多项目把该C的写成I，结果关键干系人到最后阶段才说“我不知道”，这是最常见的协作事故来源。

RACI排完后，还要做一次“全员拉通”——把矩阵发到所有涉及角色手里，请大家逐条确认。这个动作很像需求评审，表面上是确认表格，实际上是让每个人对项目计划产生承诺感。尤其是当团队来自不同部门、平时没有共同工作语言时，RACI就是那个共同语言。不要省略这一步，矩阵做出来没有人认领，等于白做。

4. 决策评审Gate怎么设计：评审材料、通过标准与会议节奏

前面把六步拆开了，这一章专门写那个“一法”：决策评审Gate。为什么单独开一章？因为在实际项目里，六步一法能不能跑起来，不取决于流程图画得多完整，而取决于Gate设计得硬不硬。Gate是整条项目管理链路上的刹车和油门，设计不好，前面所有阶段都会变成橡皮筋。

4.1 Gate评审的本质：把质量卡在入口而不是出口

Gate决策评审的本质，是在每个阶段边界上做一次正式的“准入放行”。它的定位不是“汇报进度”，而是“判定是否可以进入下一阶段”。这两者有本质区别：汇报的结论是“我们干完了”，判定的结论是“我们准备好了，可以进入下一段”。前者是信息同步，后者是质量背书。把汇报当Gate开会，是这条方法论落地时最常见的偏差。

在IPD的完整语境里，评审通常分两类：一类是技术评审（Technical Review，TR），埋在产品开发过程内部，盯设计质量和实现正确性；另一类是决策评审点（Decision Check Point，DCP），放在阶段边界，盯业务价值和资源投入是否继续。六步一法里的“一法”更接近DCP的定位，但实际落地时不能只开DCP不开TR——没有TR把关开发过程中的技术风险，等到阶段末的Gate才发现设计有问题，纠正成本会高出一个数量级。我的习惯是：TR在开发阶段按模块定时开，DCP在每个阶段末尾开，把DCP的评审材料里附上最近一次TR的结论，作为技术维度的输入。

Gate的另一个作用是给项目留“后悔药”。如果阶段末评审发现偏差太大，可以触发两个动作：一是调整计划进入下一阶段，也就是有条件通过；二是重新定义目标或终止项目，及时止损。真正有价值的Gate，是不怕说“No”的Gate，这条后面还会反复提到。

4.2 Gate评审材料：五种文档装进同一个评审包

Gate评审要高效，第一步是材料标准化。我要求项目组每次评审前，把材料整理成一个评审包，固定包含五种文档，并在评审会开始前48小时分发给所有评审人。没有材料不评审，这可以作为项目管理办公室的一条硬规矩。

这里有个细节：下一阶段计划也要放进评审材料，而不是等Gate通过后再补。因为评审会的价值不只是审查过去，更是审查未来——评审人对下一阶段计划提意见，比他们对上一阶段工作提意见更有用。把未来计划排除在评审之外，等于让驾驶员只盯后视镜开车。

提示：评审包发出后，如果评审人在会前没有反馈任何意见，默认视为“无异议”。这个规则可以倒逼评审人提前读材料，而不是会上现翻。

4.3 通过标准：每个Gate挂上量化条件

Gate能不能硬起来，取决于通过标准是否可量化。很多团队设计的Gate通过标准是“基本完成”“总体可行”这种描述，评审人很难凭这句话做出“不通过”的判断。六步一法值得借鉴的地方，就是把“到达预定目标”这件事拆成了可验证的条件。下面是我按六步一法搭建的一套Gate通过标准，可以直接套用到产品类项目上：

这套标准不是死的，不同项目可以调整具体数值，但有一个原则要保持：措辞必须让评审人能够用“是/否”来回答。比如“产品可用”就不合格，要改成“验收测试用例通过率≥95%，且无未关闭的严重缺陷”。“质量不错”不合格，要改成“与定义阶段的性能指标逐项比对，偏差率在±5%以内”。只有通过标准能被证伪，Gate才有存在意义。

4.4 评审会节奏：会前、会中、会后各做什么

Gate评审不是一个会议，而是一个有小周期的工作流。我把每个Gate拆成三段来执行。

会前48小时：发出评审包，评审人独立阅读材料并在评审单上填写预审意见。这一步最大的作用是避免会上从头读PPT，把评审会开成读书会。我还会要求项目组把预审意见中“不通过”的部分提前逐条回应，不能回应的直接挂到会中议题。很多无效评审会就是这么救回来的。

会中：按Gate自检表逐项过，先看偏差，再看交付物，最后讨论下一阶段计划。评审结论只允许三种：Pass（通过）、Conditional Pass（有条件通过）、No Pass（不通过）。有条件通过必须写明整改截止日期和验证人，由指定评审人在整改完成后单独验证关闭。这里容易翻车的点，是把“有条件通过”当成“通过”，整改项没人追，风险顺延到下一个阶段。避免方法是：下个Gate开篇第一项，就是核对上一个Gate的整改关闭情况，未关闭的整改项自动升级为下个Gate的“不通过”项。

会后24小时：发出评审纪要，列明结论、整改项、责任人和验证人。纪要不是为了存档，而是为了给下个Gate提供追溯依据。我在评审材料模板里固定放一张“Gate历史记录”表，把所有Gate的结论和整改状态列在一起，项目走到G5时回头看，整条决策轨迹清清楚楚。

5. 避坑指南：六步一法落地时最常踩的五个坑

方法论本身经得起推敲，翻车基本都是落地姿势的问题。这些年我见过太多项目把六步一法做成流程空转，材料挂在墙上，项目还是原来的活法。这里把最典型的五个坑按“现象—原因—解决”记下来，都是真实项目里反复出现的场景。

5.1 评审会开完等于没开：Gate为什么总说“通过”

现象：Gate评审会开得热热闹闹，结论永远是“通过”，项目进入下一阶段后问题照样集中爆发。评审人不是没有异议，而是觉得“提了也没用，反正最后都是领导拍板”，于是会上集体沉默，散会后私下抱怨。

原因：根子是通过标准太主观。评审材料全是“基本满足”“整体可行”这类定性描述，评审人没法说“不”，因为没有一个客观的尺子来判断“不”的依据。另一个原因是评审结论没有和后续责任绑定——即使说“不通过”，也没有人会因此调整什么。

解决：把每个Gate的通过条件换成可量化的指标，比如G2必须“资源到位率≥90%”，G4必须“严重缺陷清零、验收测试通过率≥95%”。没有数据支撑的评审项，直接标红退回。评审结论要留档，并且把“No Pass”的次数纳入项目复盘。只要连续三次评审都无理由全票通过，项目管理办公室就应该介入，检查是不是评审材料出了问题。

5.2 需求没冻结就冲进开发：变更为什么管不住

现象：定义阶段需求还没谈清楚，管理层一句“先干起来再说”，项目就急急忙忙进入开发。开发过程中需求源源不断进来，设计返工、代码重写、测试用例作废，进度一周一周往后滑，最后改到连最初版本长什么样都记不清了。

原因：大家把定义阶段当成文档流水线，而不是决策关口。需求评审有没有通过、基线有没有冻结，没有人检查；“先干起来”在组织里又是一种政治正确的姿态，谁反对谁像是不积极。

解决：在定义阶段强制设需求冻结点，需求规格书评审通过后，任何变更必须走CCB变更控制流程，评估影响范围后才决定是否接受。项目经理要在项目启动会上拿到明确授权：需求未冻结时，有权拒绝排期。这一步需要高层授信，否则很容易被一句“业务紧急”击穿。同时把“需求基线是否冻结”写进G1和G2的Gate通过条件，没有冻结记录，后面两个Gate都不放行。

5.3 里程碑排得太乐观：计划为什么两周就崩

现象：计划阶段的甘特图画得很漂亮，里程碑一个接一个，看起来无懈可击。结果项目运行两周，发现关键路径上的任务被别的项目抽走人手，一个里程碑还没到就延期了，后面的计划全部连锁后移。

原因：里程碑“拍脑袋”式推导——只按日历倒推，没有校验资源日历和任务依赖关系。更常见的情况是，项目经理为了向上汇报“有冲劲”，主动把日期往前提了两周，完全不考虑并行任务之间的资源冲突。

解决：排里程碑前先跑一遍关键路径，标记出每个里程碑的依赖前置任务，再把资源日历对一遍，做资源冲突检查。发现并行任务抢资源时，要么调整里程碑日期，要么申请增援，二选一，不能靠“到时候再说”。里程碑之间留10%~15%的缓冲，放在验证完成到发布之间这种高危衔接带。这个动作会让计划图看起来不那么“漂亮”，但至少它不会两周就崩。

5.4 验证阶段被挤成“走过场”：缺陷为什么漏到客户现场

现象：验证阶段一开始就发现严重缺陷，但发布日是已经对外公布的死线，于是开会讨论之后“带病发布”。结果产品到了客户现场就出问题，售后团队上门救火，品牌损失比延期发布大得多。

原因：验证阶段被视为“可以挤压的弹性区间”，时间先被开发延期吃掉，再被发布死线压短。更深层的原因是验收条件没在定义阶段定清楚，测试用例没有明确依据，测到哪算哪，缺陷自然漏出去。

解决：在定义阶段就把验收条件写清楚，每个功能点对应一条可测的验收标准；验证阶段的测试用例由这些验收条件直接映射，保证“验收条件逐条可测、测试用例逐条可溯”。Stage门禁上把“严重缺陷清零”作为发布Gate的硬门槛，不达标就不签字。签字权要明确授权给QA负责人，而不是项目经理一个人扛——项目经理往往顶不住业务部门的压力，QA负责人可以。

5.5 复盘会开完没有然后：经验为什么留不到下个项目

现象：项目结束，复盘会开了三个小时，大家聊得挺热闹，输出了一张PPT，上面列了七八条“经验教训”。散会后没人跟进，下个项目该踩的坑一个不少继续踩。再过半年，连当初PPT放哪儿了都找不到。

原因：复盘报告没有落到可跟踪的载体上。没有责任人、没有截止日期、没有验证方式的改进项，本质上等于不存在。另一个原因是复盘被认为是“项目结束后的仪式”，而不是“下一个项目启动前的输入”，所以也没有人会把它当真。

解决：复盘必须输出可跟踪的改进项清单：改进点、负责人、截止日期、验证方式。规范做法是让每一项都挂到后续项目的计划里，作为该项目的约束条件。我在项目归档时检查复盘输出有没有下个项目落点，没有就退回重写。这个动作不复杂，但能让“经验教训”从形容词变成动词——经验只有在被引用时才算是经验，否则只是日记。

6. Obsidian项目管理台账：一个让六步一法持续跑起来的具体技巧

6.1 把六步转成模板：检查项即Gate条件

方法论写得再好，不落到日常工具里就会慢慢失效。我用Obsidian给每个项目建一个归档台账，把六步一法做成可以直接复制的Markdown模板。Obsidian是本地笔记工具，好处是纯文本、不锁格式、可以跨项目搜索，特别适合用来做长期的项目积累。下面这个模板是我现在每个新项目都会先拉一遍的骨架：

# 项目名称：xxx 负责人：xxx 开始日期：xxx 目标：xxx ## 阶段状态总览 - [ ] 定义阶段 - [ ] 商业论证量化通过 - [ ] 需求基线冻结 - [ ] 项目章程签署 - [ ] 计划阶段 - [ ] 里程碑基线（含缓冲） - [ ] 资源到位率≥90% - [ ] 风险应对方案齐备 - [ ] 开发阶段 - [ ] 技术评审TR通过 - [ ] 接口定义冻结 - [ ] 功能完成+冒烟测试通过 - [ ] 验证阶段 - [ ] 严重缺陷清零 - [ ] 验收测试用例通过率≥95% - [ ] 发布阶段 - [ ] 支持就绪 - [ ] 推广物料就绪 - [ ] 学习与改善 - [ ] 复盘报告归档 - [ ] 改进项落实到下个项目 ## Gate日志 - G1 结果：通过 / 日期： / 备注： - G2 结果：有条件通过 / 日期： / 整改截止： - G3 结果：通过 / 日期： / 备注： - G4 结果：通过 / 日期： / 备注： - G5 结果：通过 / 日期： / 备注： - G6 结果：通过 / 日期： / 备注： ## 风险清单 | 风险 | 概率 | 影响 | 应对措施 | 负责人 | 状态 | | ---- | ---- | ---- | ---- | ---- | ---- | ## 复盘关联 [[项目xxx复盘]]

模板里的方括号是Obsidian的复选框语法，每个阶段完成一个检查项就勾一个方框；Gate日志直接对应六步一法里的决策评审，评审结论只写“通过/有条件通过/未通过”，有条件通过就在备注里写上整改截止日期。风险清单用表格维护，每周更新一次，比堆在聊天记录里强得多。

6.2 日常维护节奏：每周十分钟更新台账

台账建好只是开始，真正让方法论跑起来的是维护节奏。我给自己定的规矩是每周五下午花十分钟做三件事：勾掉本周完成的检查项，更新Gate日志里新增的评审结论，把风险清单里的状态列刷新一遍。如果装了Dataview插件，还可以按标签汇总所有项目的阶段状态，一眼看清哪些卡在验证、哪些已经发布。做第一个项目时我懒得维护台账，结果G2评审前要连夜补材料，从那以后每接一个新项目，第一天就在Obsidian里把模板拉起来，把每个Gate的量化退出条件写进检查项，之后每周雷打不动花十分钟更新。六步一法给了项目一张完整的地图，但真正让地图有用的，是每天落笔的那十分钟。希望帮到你。

本文还有配套的精品资源，点击获取