AI提效20讲⑥：除掉未知数法则 (魄力和能力之间选一个平衡点)

作者：AI提效项目组组长 蒋云峰 校审：林德燊 排版：习丌

什么是未知数？
想象你要开车去一个陌生的城市。路况不清楚是"未知数"，车的故障是"未知数"，油够不够也是"未知数"。一两个未知数，你还能应付；但如果连目的地在哪都不确定，车是否能发动都不知道，油箱是满是空也看不见——这就是"未知数爆炸"，你根本不敢出发。

项目中的未知数更可怕：因为它们藏在迷雾里，你看不见、摸不着，只能凭感觉。有经验的架构师能闻到"不对劲的味道"，但说不清哪里不对；乐观的项目经理觉得"应该没问题"，结果开发到一半全面崩盘。

本章核心目标：教你如何在迷雾中寻找可控的光——不是消除所有未知数（那不可能），而是把未知变成已知，把不可控变成可控，把盲目冲锋变成有序推进。

核心框架速览：

关联章节：第四章（旧城改造思想）、第十章（计划在前实现在后）

引言：PDA项目的启示第一幕：被叫去论证的"简单"项目（不知道自己不知道）

2025七月，我正在忙其他事情。

余经理跑过来："我们在开会讨论PDA项目，你是AI负责人，过来听一下，帮我们论证一下可行性。"

我推门进会议室时，他们已经讨论得差不多了。

余经理见我进来，简单介绍："我们要启动PDA移动端项目，把Android原生转成UniApp，打算两个月搞定。大家没觉得有什么问题，叫你过来是想听听你的意见，AI能帮上忙不？"

团队成员一言不发，像是已经达成了共识。

当时我对这个时间估算有疑虑，但看团队已达成共识，便询问了转换原因和业务复杂度。

余经理解释：选择UniApp主要是跨平台特性，一次开发多端运行，且团队对此技术栈较熟悉。业务逻辑评估为中等复杂度，类似现有订单系统。

会议结束，项目已立项，要求我进行可行性分析。

初步认知：这是一个技术栈转换项目，两个月交付应该可行。

第二幕：可行性报告的"意外"（知道自己不知道）

按照他们的要求，我花了两天时间，深入分析了Android项目代码库。

打开代码库的那一刻，我愣住了：

我意识到：这不是一个简单的技术栈转换，这是一个深水坑。

8月4日，我发布了《Android原生项目转UniApp可行性分析报告》。

报告结论：

• 640个Java文件
• 22个业务模块
• C++原生库（native-lib.cpp）
• SQLCipher加密数据库（40个实体、44个DAO）
• 系统级权限（需要原生插件）

评估结果

• 最乐观估计：10-12个月（996工作制，经验丰富团队）
• 现实估计：14-18个月（正常工作强度，混合经验团队）
• 最悲观估计：20-24个月（遇到技术难点，人员流动）
• AI辅助开发：7-9个月（即使有AI提效40-50%）

报告发布到项目组后，余经理的反馈是：报告分析详细，但考虑到AI提效40-50%，加上SQLite有现成插件，两个月交付应该可行。

认知差距显现：我们对未知数的风险评估存在明显差异。

更关键的信息是：余经理计划独自完成整个项目。

对比分析：

• 项目难度：与总后台项目相当，甚至更高

• 资源配置：总后台项目有产品经理、测试、多名开发协同

• PDA项目：单人作战，缺乏强有力的支撑体系

风险判断：如果不调整资源配置和时间预期，项目失败概率极高。

我在项目组群里直接说：不要带着问题上路，这样会给夹生饭找借口。解决了问题上路，让自己别无选择。

我对这个项目评估的夹生饭可能性大于60%。这个PDA被我评估的是浑水，就像是，原子弹是好东西，但是没有大的能量很难炸出个效果。

然后，我在群里发了一张未知数分析图——把项目中所有潜在的问题都用红绿白三色标记出来。

第三幕：技术评审会的"摊牌"（让所有人知道不知道）

临时组局小会议

我在Figma中重新画了那张图——左右两个分支，用红色、白色、绿色标记每个节点。

余经理看了一眼："这什么意思？"

我说："通过分析后，未知数会变成红绿白三色：红色是必须要敲定的未知数（大未知数，必须解决），绿色是可以忽略的未知数（已了解，不需要担心），白色是可以携带的未知数（中未知数，可以在开发过程中解决）。你看，我们从两个核心未知数出发，识别出了7个红色节点。"

我继续说："左侧分支（AI开发的熟练程度）识别出3个红色节点：AI开发能力、迁移方案、产品方案。

右侧分支（对于后台技术的理解程度）识别出4个红色节点：后台技术理解、旧版安卓兼容性、SQLite学习曲线、UniApp不确定性。

总共7个红色节点（必须要敲定的未知数）。"

我 ：从这7个红色节点来看，按照我的经验判断，成功率不到5%。

余经理："那你建议怎么办？"

我直接说出了我的担忧和建议："余经理，你需要找到帮手，或者推手。不然我尽100%全力协助你AI方面的，你也很难不成为一个夹生饭。这不是我愿不愿意的问题，是没办法不愿意的问题。"

"这个项目的难度和总后台差不多，甚至略胜一筹。但总后台有欧经理、张经理做推手，有林开发做左右护驾。你这个项目，像是个流浪的孩子，没有强大的支撑。"

"我的建议是：不要一个人全部搞定。你需要：

• 多拉几个人头，组建一个真正的团队
• 产品经理必须能和你老大一起支持你，提供强有力的支撑

• 不然，即使有AI提效，这个项目也很难成功"

余经理沉默了一会儿，点了点头。

转折点：从"不知道不知道"到"知道不知道"

这三次接触，是一个认知升级的过程：

第一次接触（被叫去论证）：项目组已经决定，所有人都是"不知道自己不知道"→ 他们觉得项目简单，两个月搞定，叫我去只是论证可行性

第二次接触（报告反馈）：我变成了"知道自己不知道"→ 发现640个Java文件、C++库、加密数据库，但他们的认知还是"两个月够了"

第三次接触（评审会）：让所有人都"知道自己不知道"→ 用红绿白三色分析图，把迷雾中的未知数，一个一个点亮，最终让他们也看清了现实

这就是"除掉未知数法则"的第一步：在迷雾中点亮灯，让所有人看见未知数。不是为了吓唬人，而是为了找到可控的路。

接下来，让我详细展开那张"红绿白三色分析图"是怎么画出来的，以及它如何帮助我们从7个红色节点（必须要敲定的未知数）中找到出路。

未知数的本质：黑暗中的坑与光
1.1 什么是未知数

定义：项目中无法在启动前完全确认的因素，包括技术难点、业务复杂度、资源可用性、外部依赖等。

未知数的层级分类（通过分析后，从白色变成红绿白）：

判断逻辑公式：

说明：同一领域可拆分为不同层级的未知数，不同子项可能归属不同颜色。例如"SQLite技术"是白色（可在开发中学习），但"SQLite迁移方案"若未确定则是红色（影响项目成败）。

红色节点（必须要敲定的未知数，影响项目成败）：

• 核心能力未知（如：AI开发的熟练程度、对后台技术的理解程度）

• 核心方案未确定（如：迁移方案、产品方案、功能范围）

• 核心技术栈不熟悉（如：新版兼容性技术UniApp的不确定性）

• 关键技术掌握程度未知（如：SQLite学习曲线、旧版安卓系统兼容性）

⚪白色节点（可以携带的未知数，影响项目效率）：

• 个人能力提升需要时间（如：个人提升、学习程度）

• 方案细节待完善（如：方案缺失、状态管理方案待定）

• 规范要求待确定（如：样式要求、UI规范待定）

• 风险可在开发中处理（如：数据丢失风险）

绿色节点（可以忽略的未知数，已了解清楚）

• 业务逻辑已熟悉（如：权限结构，阿波熟悉）

• 现状已了解（如：公司级对于迁移的东西不熟练，已了解现状）

• 风险已识别（如：迁移不稳定性，已知道哪些迁移可能产生问题）

• 技术需求已明确（如：流畅度要求、系统调度、连扫模式、微距、打包流程）

实际案例：PDA项目的真实未知数梳理

在第一次技术评审会议后，我做了一件事：把所有能想到的问题都列出来，并用颜色标记风险等级。

关键理解：通过深入分析后，未知数会变成红绿白三色：

• ⚪白色（可以携带的未知数）：中未知数，可以在开发过程中解决，不影响项目成败

• 绿色（可以忽略的未知数）：已了解清楚，不需要担心，可以忽略

• 红色（必须要敲定的未知数）：大未知数，影响项目成败，必须在上路前解决

第一步：列出所有问题

我在Figma中画了两条线：

左侧分支：AI开发的熟练程度

从AI开发能力这个核心未知数出发，逐步暴露出更多问题。

右侧分支：对于后台技术的理解程度

从对后台技术理解的未知数出发，展开技术转换的所有不确定性。

第二步：统计风险等级

我在Figma图的下方区域写下统计结果：

第三步：得出结论

当我看到这个统计结果时，内心更不安了：总共7个红色节点（必须要敲定的未知数），其中左侧分支3个，右侧分支4个。

按照我的经验判断：

项目评估结论：7个红色节点同时存在，这已经不是"看运气"或"必然失败"的程度，而是自杀式项目。即使AI能提升40-50%效率，也无法弥补如此多的未知数带来的风险。

第四步：向项目组反馈

我把这张分析图发在群里，配合可行性报告，向项目组说明："你们看这7个红色节点，如果现在就启动，会发生什么？

我给你们演推一遍：

• 第1-2周：阿波说需求文档还没完成，业务规则不清楚，开发停滞
• 第3-4周：余经理开始转换Java代码，发现C++库不知道怎么处理，卡住
• 第5-6周：数据库迁移，40个实体的加密方案需要重新设计，又卡住
• 第7-8周：系统权限实现不了，需要开发原生插件，但没人会写
• 结果：两个月过去，一行可用代码都没有，项目进度为零"

我翻到可行性报告的最后一页："这份报告分析得很清楚，传统方式14-18个月，AI辅助也要7-9个月。两个月是不可能的。"

潘经理问："那你建议怎么办？"

我说：

"方案A（强烈推荐）：必须消灭未知数后再前进，集合优势力量打赢歼灭战

核心原则：

1. 必须先消灭未知数：7个红色节点必须全部变成绿色或白色，才能开始开发
2. 团队配置：需要一个专职产品经理、一个适配的测试、一个开发者打辅助
3. 遵循插旗法规则：保证有计划有步骤的运行

每周执行节奏：

• 周一：定计划（明确本周要消灭的未知数和验证目标）
• 周三：矫偏差（检查进度，发现问题立即调整）
• 周五：报visual（展示本周成果，无论成功还是失败都要在周报体现）

严格纪律：

• 如果本周出现了问题，本周就算作废，下周重新开始

• 每周都要看得到进度，失败还是成功都要看到进度，我会在周报体现出来

• 测试需要覆盖全面，秉持着做少测多原则

效果：从7个红色节点全部消除后，成功率可从<=5%提升到50%+

方案B（备选）：先做MVP核心功能

• 只做核心扫描功能，不做全量转换

• 用2个月证明技术可行性

• 再决定是否继续

方案C（强烈反对）：按原计划两个月交付

• 成功率<5%

• 浪费团队时间，损害团队信心"

核心法则（红色节点数量判断）：

统计依据：基于我们团队过去12个项目的实战数据（2024年1月-2025年1月），以及后台项目、总后台项目、PDA项目的对比样本分析：

• 1个红色节点（必须要敲定的未知数）：可控风险，可以上路（成功率70-80%）

• 样本：后台项目初期（1个核心技术栈未知），按期交付

• 2个红色节点：看运气，慎重决策（成功率40-50%）

• 样本：总后台项目（2个核心方案未确定），延期1个月交付

• 3-4个红色节点：成功概率极低，建议重新规划（成功率15-25%）

• 样本：某客户系统（3个红色节点），延期3个月并缩减功能

• 5-6个红色节点：必然失败，必须调整策略（成功率<10%）

• 样本：某ERP项目（5个红色节点），最终转型为MVP方案

• 7个及以上红色节点：自杀式项目，立即停止（成功率<5%）

• 样本：PDA项目初期评估（7个红色节点），经1个月消除后降至2个

注意：白色节点（可以携带的未知数）不影响这个判断，它们可以在开发过程中解决。只有红色节点（必须要敲定的未知数）才决定项目成败。

1.3 真实案例的核心启示

这张红绿白三色分析图教会我们什么？

第一：直面问题是解决问题的第一步

很多项目失败不是因为问题太难，而是因为不敢承认有问题。余经理的态度是"应该不难，边做边调整"，但实际上有7个红色节点在等着我们。可行性报告早就分析过，传统方式14-18个月，AI辅助也要7-9个月。如果不列出来，不分析，两个月交付就是自欺欺人。

第二：在有限的时间内解决问题

项目不能无限期准备，必须在有限时间内做决策。用红绿白三色分析，快速识别出7个红色节点，通过1个月的技术验证和业务调研，可以消除至少4-5个红色节点，从"自杀式项目"降到"高风险但可控"。

第三：系统化方法比经验判断更可靠

如果只凭直觉，余经理的直觉是"可以快速交付"，我的直觉是"不安，但说不清为什么"。但用了系统化方法，通过红绿白三色分析清晰识别出7个红色节点，结合可行性报告量化评估风险，做出明确的决策建议，用数据说话，而不是拍脑袋决策。

这就是"除掉未知数法则"的价值：把模糊的不安，变成清晰的分析；把经验判断，变成系统方法；把赌博式决策，变成可控的风险管理。

接下来，我会详细讲解如何系统化地消除未知数。

除未知数法则：四大核心策略

看清未知数只是第一步，关键是如何除掉它们。PDA项目教会我四个策略：

2.1 策略一：规避绕开法（能避就避）

核心原则：有些未知数，不是用来解决的，而是用来规避的。

PDA项目的规避案例：

未知数：C++原生库如何转换？

我们面临三个选择：

1. JavaScript重写（工作量巨大，风险未知）

2. 开发原生插件（团队不会写，学习成本未知）

3. 云端API替代（规避掉C++，让后端处理）

最终选择：规避！

把C++的加密算法放到云端，前端只负责调用API。这样：

• 不需要转换C++代码

• 不需要学习原生插件开发

• 安全性更高（加密逻辑在服务端）

未知数：PDA设备系统版本兼容性问题

余经理的自传

开发过程中，遇到了一台PDA设备，系统控件版本极低，死活装不了新版PDA应用，折腾了好几天：

• 尝试各种降级方案（风险未知，可能影响其他设备）

• 研究系统底层兼容（时间成本巨大）

• 专门为这台设备定制版本（维护成本高）

最终选择：规避！

制定最低系统版本标准，不支持的设备直接告知用户升级或更换设备。这样：

• 不需要为每台老旧设备定制兼容方案

• 不需要投入时间研究底层兼容性

• 清晰的标准让团队和用户都有明确预期

• 把"适配所有设备"的未知数，变成"支持标准设备"的已知数

规避的本质：不是解决问题，而是换一条没有这个问题的路。

如何判断能否规避：

• 这个功能是否必须在客户端实现？

• 是否有现成的云端服务可以替代？

• 规避后是否会产生更大的问题？

规避法的适用场景：
✅ 技术栈不熟悉，但有替代方案
✅ 工作量巨大，但收益不明显
✅ 风险不可控，但可以换条路

❌ 核心业务逻辑，无法规避
❌ 规避后会产生更大问题
❌ 已经投入大量成本

策略一公式总结：

PDA项目案例：如何在1个月内消除4-5个红色节点

初始未知数清单（回顾前文分析）：

• 产品方案（需求文档未完成）— 红色节点（必须要敲定）

• 迁移方案（旧数据如何迁移）— 红色节点（必须要敲定）

• 业务规则（历史数据处理）— 红色节点（必须要敲定）

• Android代码转换量（640个Java文件，22个模块）— 红色节点（必须要敲定）

• C++原生库转换方案— 红色节点（必须要敲定）

• SQLCipher数据库迁移（40个实体、44个DAO）— 红色节点（必须要敲定）

• 系统级权限实现— 红色节点（必须要敲定）

消除行动（1个月时间）：

第1-2周：业务层未知数消除

• 第1-3天：产品经理完成需求文档，明确核心功能范围
• 第4-7天：与业务方阿波 张经理深入访谈，确认PDA核心流程和权限规则
• 第8-10天：制定数据迁移方案，确认历史数据处理规则

• ✅成果：消除3个业务侧红色节点（从红色变成绿色或白色）

第3-4周：技术层未知数消除

• 第11-14天：C++代码分析，确定JavaScript重写可行性，或选择云端API方案
• 第15-18天：SQLite数据库迁移技术验证，完成Demo测试
• 第19-22天：系统级权限方案确定，评估原生插件开发成本
• 第23-25天：评估640个Java文件转换量，制定分批转换计划

• ✅成果：消除2-3个技术侧红色节点（核心技术方案明确，从红色变成绿色或白色）

结果：消除了4-5个红色节点（3业务+1-2技术核心方案），项目从"自杀式"（7个红色节点）降到"高风险但可控"（2-3个红色节点）。

2.2 策略二：拉线法（找到那根最容易拉的线）

核心原则：未知数像一团乱麻，关键是找到那根最容易拉出来的线头。

什么是"线头"？

想象你面前有一团毛线球，乱成一团。你想解开它，该怎么办？

• ❌ 错误做法：随便抓一根线就拉，结果越拉越紧

• ✅ 正确做法：先找到不被其他线压着的那根，轻轻一拉就出来了

未知数也是一样：有的未知数被其他未知数"压着"（被依赖），有的未知数"压着"其他未知数（被依赖）。

PDA项目的线头分析：

我在Figma中画出7个红色节点（必须要敲定的未知数）的依赖关系：

发现：

• 产品需求文档：被最多依赖，必须最先解决（最难的"线"）

• C++、SQLite、权限：互不依赖，可以并行验证（最容易的"线头"）

策略：

1. 先拉线头：C++、SQLite、权限三个技术方案，分3步骤并行验证
2. 再解压线：产品需求文档，阿波集中精力完成
3. 最后顺势解开：数据模型设计，在前面两步完成后水到渠成

为什么这样有效？

• 心理优势：快速解决3个技术方案，信心爆棚
• 时间节约：并行验证，1周就能消除3个未知数
• 风险降低：即使产品文档还没完成，技术可行性已经验证了

交叉线头法的核心：

不要硬啃最难的问题，先找那些"不被依赖"的线头，快速拉出来，给团队建立信心，然后再集中火力攻克被依赖最多的核心问题。

如何找线头？

画一张依赖关系图，问自己：

• 哪些未知数不被其他未知数依赖？（线头）

• 哪些未知数被最多未知数依赖？（压线）

• 线头能不能并行处理？（同时拉）

策略二公式总结：

2.3 策略三：共轭控制法（配对协调，互为补偿）

核心原则：当系统中存在两个相互作用、相互制约的要素时，通过共轭（conjugate）关系让两者协同工作、互为补偿，找到平衡点。

什么是共轭控制？

共轭控制不是"把大问题拆成小问题"的分治思维，而是对偶控制思维。

它处理的是这样的场景：

• 魄力 vs 能力（有魄力但能力不足，有能力但魄力不够）

• 速度 vs 质量（追求速度可能牺牲质量，追求质量可能影响速度）

• AI提效 vs 人工把控（AI能快速生成，但需要人工验证质量）

• 技术可行性 vs 业务需求（技术方案可行，但必须满足业务需求）

共轭关系的本质：

两个要素相互制约，但又相互依赖。不能只强化一方，必须找到两者的平衡点，让它们协同工作、互为补偿。

PDA项目的共轭控制案例一：魄力与能力的平衡

场景：余经理一个人要搞定PDA项目，两个月交付。

共轭关系识别：

• 魄力：敢接项目，有信心两个月搞定
• 能力：对Android系统理解不足，对UniApp不熟悉，SQLite需要学习

问题：魄力太强，能力不足，两者失衡。

共轭控制策略：

1. 降低魄力要求：从"两个月交付"调整为"先做技术验证，再决定交付时间"
2. 提升能力支撑：增加团队成员（产品经理、测试、辅助开发），提供资源支持
3. 建立平衡机制：每周检查点，如果能力跟不上，立即调整魄力目标

结果：

• ✅ 魄力与能力达到平衡：不再盲目承诺两个月，而是基于能力评估制定合理计划

• ✅ 项目从"自杀式"（魄力>能力）变成"高风险但可控"（魄力≈能力）

背景：40个实体、44个DAO，从Android SQLCipher迁移到UniApp SQLite，完全不知道从哪开始。

共轭关系识别：

• AI提效：AI能快速生成代码，批量处理40个表
• 人工把控：需要人工验证质量，确保设计规范正确，业务逻辑准确

问题：如果只用AI，可能生成错误代码；如果只用人工，效率太低。

共轭控制策略：建立人工与AI的协同机制，让两者互为补偿。

第一步：人工建立锚点（人工把控优先）

余经理先自己写了一个商品表的SQLite建表语句，包含了基本的字段：商品ID、名称、价格、库存、创建时间和更新时间。这个表很简单，但它是第一个锚点——让团队知道SQLite在UniApp中怎么用，建立了"知道怎么做"的信心。

为什么先人工？

• 人工建立锚点，确保第一个表的质量可控

• 为后续AI生成提供参考标准

• 建立对SQLite的信心

第二步：AI优化提升（AI提效发挥作用）

余经理把这个表丢给AI，让AI优化。他告诉AI：这是一个商品表，需要增加索引提升查询性能，增加字段约束保证数据完整性，参考SQLite最佳实践，考虑后续扩展性。

AI返回优化后的版本，主要改进包括：

• 增加了商品编码字段，并设置唯一约束

• 增加了商品状态字段（上架、下架）

• 为价格和库存字段增加了非负约束（价格、库存不能为负）

• 规范了时间字段格式，使用SQLite的datetime函数自动填充

• 为关键查询字段创建了索引（商品编码、状态、创建时间）

共轭关系体现：

• 人工把控：人工提供第一个表作为锚点，确保基础正确
• AI提效：AI基于人工锚点优化，发现遗漏、建立规范
• 互为补偿：人工的"质量把控"补偿了AI的"可能遗漏"，AI的"快速优化"补偿了人工的"效率不足"

第三步：形成规范，批量生成（共轭协同）

有了商品表的优化版本，余经理让AI参考这个设计模式，继续生成订单表。他告诉AI：参考上面的商品表设计，帮我设计订单表，要参考商品表的设计风格（索引、约束、时间字段），订单需要关联商品（外键关系），订单有状态流转（待支付、已支付、已发货、已完成），订单有金额字段，需要保证数据完整性。

AI基于商品表的设计模式，生成了订单表，包含了订单号（唯一约束）、关联商品ID（外键关系）、数量（必须大于0）、金额（不能为负）、状态（待支付、已支付、已发货、已完成）、创建时间和更新时间，并为订单号、商品ID、状态、创建时间等关键字段创建了索引。

第四步：建立设计规范，批量生成（共轭平衡）

有了商品表和订单表的成功经验，余经理总结出设计规范：

• 主键统一使用自增整数类型

• 时间字段统一使用文本类型配合SQLite的datetime函数

• 数值字段必须加约束（如价格、库存不能为负）

• 关键查询字段必须建索引（如编码、状态、时间）

• 关联关系使用外键约束

• 字段统一加非空约束和默认值

然后，余经理让AI参考这个规范，批量生成剩余的38个表。他告诉AI：参考商品表和订单表的设计规范，帮我设计剩余的38个表，要严格按照已建立的设计规范，每个表都要有索引、约束、时间字段，关联关系要明确外键，生成完整的建表语句和索引语句。

共轭控制的平衡机制：

结果：

• 40个表的设计，从"完全不知道"变成"有规范可循"

• 每个表都遵循统一的设计规范（索引、约束、时间字段）

• AI生成的代码质量高，减少了人工错误

• 从第一个表到40个表，只用了3天（人工1天+AI优化1天+批量生成1天）

• 共轭平衡：人工把控质量，AI提升效率，两者协同工作、互为补偿

这个案例的核心价值：

1. 共轭配对：识别出"AI提效"和"人工把控"这对共轭关系
2. 协调机制：人工建立锚点→AI优化提升→形成规范→批量生成
3. 平衡控制：人工把控质量，AI提升效率，两者互为补偿
4. 协同效果：从"40个表不知道怎么写"到"3天全部搞定"，且质量可控

场景：C++原生库如何转换？

共轭关系识别：

• 技术可行性：可以用JavaScript重写，可以开发原生插件，可以用云端API替代
• 业务需求：必须保证安全性，必须保证性能，必须满足业务逻辑

问题：如果只考虑技术可行性，可能忽略业务需求；如果只考虑业务需求，可能技术实现不了。

共轭控制策略：

1. 技术预研：验证JavaScript重写、原生插件、云端API三种方案的可行性
2. 业务评估：评估三种方案对业务需求（安全性、性能、业务逻辑）的影响
3. 找到平衡点：选择云端API方案，既满足技术可行性（规避C++转换），又满足业务需求（安全性更高，性能可接受）

共轭关系体现：

• 技术可行性：云端API方案技术可行，规避了C++转换的未知数
• 业务需求：加密逻辑在服务端，安全性更高，满足业务需求
• 互为补偿：技术方案规避了风险，业务需求得到了更好满足

结果：

• ✅ 技术可行性与业务需求达到平衡

• ✅ 既规避了C++转换的未知数，又提升了安全性

共轭控制的核心步骤：

1. 识别共轭关系：找到两个相互制约、相互依赖的要素（如魄力vs能力、AI提效vs人工把控）
2. 评估失衡状态：判断当前两个要素是否失衡（如魄力太强、能力不足）
3. 建立协调机制：设计让两者协同工作的机制（如人工建立锚点→AI优化提升）
4. 找到平衡点：通过实践找到两者的最佳平衡点（如人工把控质量，AI提升效率）
5. 持续调整：根据实际情况持续调整，保持平衡（如每周检查点，及时纠偏）

共轭控制的威力：

• 不是消除矛盾：而是让矛盾双方协同工作
• 不是单方强化：而是找到平衡点，让两者互为补偿
• 不是静态平衡：而是动态调整，持续优化

共轭控制 vs 分治思维的区别：

策略三公式总结：

2.4 策略四：最小MVP验证法（用最小代价试错）

核心原则：先找出自己不知道的未知问题，让自己知道；再找出最难攻克的问题，集中火力解决。

MVP法则的三个层次

第一层：识别未知

• 不知道自己不知道的（最危险）

• 知道自己不知道的（可管理）

• 不知道自己知道的（待激活）

• 知道自己知道的（已掌握）

第二层：找出最难点

• 在所有未知问题中，识别最难攻克的

• 优先解决最难问题（降低最大风险）

• 简单问题可在开发过程中解决

第三层：八边形四面环绕

什么是八边形四面环绕：

• 上下文分析：问题的前因后果

• 边界确认：问题的范围界定

• 依赖关系：问题的关联要素

• 解决方案：多角度的解决思路

• 资源需求：需要哪些资源支持

• 风险评估：可能的失败场景

• 应急预案：失败后的补救措施

• 寻求帮助：何时需要外部支持

场景：开发在线支付功能（从未做过）

MVP验证步骤：

第1步：快速原型（1天）

第2步：识别最难点（半天）

第3步：八边形分析订单同步问题

第4步：集中解决（2天）

• 实现异步队列机制

• 完成定时对账功能

• 建立人工补救流程

第5步：完善其他（1天）

• 异常处理

• 用户体验优化

• 日志完善

总结：通过MVP法则，将未知的盲目开发，变成4.5天的有序开发，且风险可控。

策略四公式总结：

四大策略整体总结：

回顾PDA项目，我们用这四个策略，把7个红色节点降到了2-3个：

四大策略公式：

综合结果：项目成功率从<5%提升到40-50%，团队信心从迷茫变成有方向。

常见误区与避坑指南
3.1 误区一：想要完全消除所有未知数

错误观念：必须把所有问题都搞清楚才能开始。

问题：

• 陷入"分析瘫痪"，永远无法启动

• 过度准备导致错过时机窗口

• 团队士气被漫长的准备期消耗

正确做法：

• 只消除大未知数和关键中未知数

• 小未知数可以在开发过程中解决

• 设置准备期上限（如不超过项目周期的20%）

错误观念：我很厉害，多几个未知数没问题。

问题：

• 低估了问题的复杂度

• 高估了自己的能力

• 出现问题时手忙脚乱

正确做法：

• 客观评估能力（使用评估表）

• 参考历史项目经验

• 设置风险阈值，严格执行

错误观念：只要敢拼，就能成功。

问题：

• 把项目成功寄托在运气上

• 魄力不能替代能力

• 失败后影响团队信心

正确做法：

• 魄力要建立在能力基础上

• 激进策略必须有应急预案

• 阶段性检查点及时纠偏

错误观念：大问题只能硬刚，或者只能拆成小问题逐个击破。

问题：

• 没有看到问题中的共轭关系（两个相互制约的要素）

• 只考虑单方强化，没有找到平衡点

• 整体攻克难度大、周期长，或者拆解后失去整体视角

正确做法：

• 识别共轭关系：找到两个相互制约、相互依赖的要素（如魄力vs能力、AI提效vs人工把控）

• 建立协调机制：设计让两者协同工作的机制（如人工建立锚点→AI优化提升）

• 找到平衡点：通过实践找到两者的最佳平衡点，让矛盾双方互为补偿

• 持续调整：根据实际情况持续调整，保持动态平衡

总结：从"荔枝使"看除未知数的智慧

一骑红尘妃子笑，无人知是荔枝来

历史启示：

唐玄宗为保鲜荔枝设立驿站的做法，本质就是除掉未知数的典范：

• 每三十里设驿站 → 除掉"距离未知"

• 每站备好快马 → 除掉"换马未知"

• 规定停留时间 → 除掉"时间未知"

• 沿途设置路标 → 除掉"路况未知"

结果："一骑红尘妃子笑，无人知是荔枝来"——让不可控变成可控。

项目中的"荔枝使"

PDA项目的本质，就是一次"运荔枝"：

❌第一批荔枝使的做法（自杀式）：

• 不做可行性分析 + 不做技术预研 + 不做需求调研 + 直接两个月交付

• 结果：项目必然失败，团队信心崩溃

✅第二批荔枝使的做法（系统化除未知数）：

• 用四大策略（规避绕开、交叉线头、共轭控制、最小MVP）

• 把7个红色节点降到2-3个

• 结果：项目成功率从<5%提升到40-50%

不是消除所有未知数（那不可能，唐朝也不可能让所有路都修成高速公路）

而是：

1. 把致命的未知数，变成可控的已知（设驿站）
2. 把不可预测的风险，变成可预测的困难（规定时间）
3. 把盲目的冲锋，变成有序的推进（路标指引）

核心法则回顾：规避绕开、交叉线头、共轭控制、最小MVP——四大策略协同工作，把未知数从致命变成可控。

实战落地指南

项目启动前必做事项：

核心原则：

关键启示：

第一批荔枝使是英雄，但也是牺牲品。
第二批荔枝使才是赢家，因为他们学会了除掉未知数。

除掉未知数法则：不是让你不出发，而是让你在出发前，把迷雾中的坑先填上，把黑暗中的灯先点亮。

点击下方关键字，查看原创热文

行业案例：| | | | | | |

业务场景：| | | | | | | | | | |

系统应用：| | | | | |

数智科普：| | | |

米多是国内领先的营销数字化整体解决方案提供商，为企业提供顶层设计（营销数字化蓝图/架构/体系等）、系统规划（一物一码/智能营销/渠道管理）及运营落地（扫码发红包/一元换购/五码合一等）提供服务，用数字化驱动业务增长。