AI提效20讲⑨：碳基员工Plan，硅基员工Doing

作者：蒋云峰 校审：林德燊 排版：习丌

AI是大脑，Agent是器官，网络是神经系统； 米多作为领先的营销数字化整体解决方案提供商，软件系统正在基于AI驱动的多模态交互，加速实现“数据语义对齐、业务合规可控、应用执行闭环”的智能进化。

米多的AI战略分为“AI提效、AI赋能、AI商业化”三个阶段，目前AI提效正在进入深水区，产研侧同学们已经基本掌握了AI提效的基本技能，绝大部分同学已经习惯了“硅基员工Plan，碳基员工Doing”，但在实际应用效果方面，还远远未能达到公司既定的“整体不弱、个体不差、差异不大”要求，究其原因，主要还在于对Plan的重视度和掌控力不足所致。

我们必须清醒的认识到：

AI 不仅把交付变快了，而是把“跑偏”也变快了。
计划不是写文档，是把最贵的错误，提前在纸面上犯掉。
看不见未来几步的人，最后都会被下一步牵着走。

高手和低手的区别在于高水平的稳定性

米多星球系统这最近几月有一个很明显的变化：实现速度越来越快，交付波动也越来越大。

速度变快的原因很简单：AI 能写代码、能补文档、能给方案。交付波动变大的原因也很简单：做得越快，跑偏也越快。

这篇文章不讲大道理，只想把 Plan 讲清楚一件事：在生产环境里，Plan 到底怎么用，才能真的提效——Plan 对人、Plan 对 AI、Plan 对落地执行。

先坦诚一句：这绝非“首创计划”，太阳底下无新事，我们只是在强调计划的重要性；不同的是，这里说的 Plan 不是空泛的“要有规划”，而是能落到协作与交付里的具象计划：边界、验收、回滚、依赖、未知数。

计划能力的高低决定了高手和低手之间的差距，就像画画和下棋一样。低手画画着眼于“细节画漂亮”，高手更在意“比例、透视、构图、光源”，因为这些决定了后面每一笔是否有效。围棋也一样，低手一招一式都很用力，但大概率是在为上一步补漏洞；高手能预判未来几步，每一步都在为后面铺路。

低手偶尔也会有经验之举，高手和低手的区别在于高水平的稳定性。

我们做需求、做研发、做系统，同样是这个道理：
Plan 的价值不是让进度慢下来，而是让每一次出手都更接近最终结果。

再补一句更直白的：Plan 是把不确定性前置，把执行成本后置。

复杂问题最容易陷入“头痛医头脚痛医脚”

在标识中台（IMP）的真实协作里，一个常见链路是：

• 产品侧把需求抛过来（往往还带着一线反馈的情绪）

• 后端看一眼就开始改接口、加字段

• 前端同步实现，联调时发现“理解不一致”

• 技术负责人介入做边界裁决

• 负责人问一句“到底什么时候能用”

在没有 AI 的年代，这条链路的代价是“慢”。在有 AI 的年代，这条链路的代价是“快而乱”：

• AI 把实现成本压得很低，于是“先做再说”更诱人

• 跑偏的速度也被放大，返工从“改几处”变成“推倒一片”

• 更糟的是：对外呈现看起来很忙、代码很多，但离可用越来越远

Plan 要解决的不是“写不写代码”，而是先把方向、边界、验收讲清楚，再用 AI 把执行压到最低成本。

标识中台（IMP）里常见的“复杂问题”不是算法难，而是链路长、依赖多、变量多，例如：

• 客户列表慢：是 SQL、索引、数据量、还是权限过滤导致的？

• 登录偶发失败：是企业微信限流、网关超时、还是 token 续期逻辑？

• 导出超时：是分页策略、序列化、还是存储写入？

如果直接动手，就会变成典型的“哪里漏水补哪里”：

• 慢就加缓存

• 超时就把超时调大

• 报错就 try/catch 吞噬掉

短期看似解决，长期一定积累成“补丁系统”。

Plan 在这里的最低目标只有一个：通过“逻辑归因、结构归母”，把问题从“症状”还原成“结构”。

也就是先写清楚三句话：

• 现象：哪里慢、慢多少、出现频率、影响范围

• 假设：可能的 3-5 个根因（按概率排序）

• 验证：每个假设要看什么指标、怎么复现、怎么回滚

如果这三句话还不够清楚，先别急着“优化”，否则大概率是在做“更快的误伤”。

“你堆我砌”的补丁游戏：为什么会越改越乱

很多 AI 协作流的真实状态是：

• Chat 里一句一句补充

• 代码里一段一段修

• 上下文里一层一层堆

最后的体验像在玩“你堆我砌”：每个人都在加砖，但没人负责地基、结构和承重墙，所有人心中都没有“装着教堂”。

我们的代码仓库里有一段总结得很直白：Chat 模式更像“盲目顺从”，Plan 模式才是“谋定而后动”的中间态。

Chat、Doc、Todo、Plan 四种“协作形态”的真实差别：

• 手写 step把 AI 当脚本引擎，写 1、2、3、4……能跑，但遇到变更非常痛苦；
• Doc 控制把需求、边界写进文档，让 AI 读取后执行；能稳定，但文档维护成本很高；
• Todo List把任务拆小，能推进，但经常缺“为什么”和“验收边界” ；
• Plan在“随口一句话”和“几千字 PRD”之间，先把关键问题想清楚，再执行；

Plan 的关键不是“列更多步骤”，而是把下面四件事补齐：

• 目标：到底要达成什么结果？
• 边界：哪些不做，哪些后做？
• 依赖：谁先谁后，先解决哪些未知数？
• 验收：什么叫完成，如何回滚？

框架上的思考：人类如何稳定地解决复杂问题

计划最容易被误解成“写文档”，但生活里最有效的计划往往很短，例如“搬家”这种复杂问题，不写计划就一定翻车；一个可用的 Plan 通常只有一页：

• 目标：周六晚上能住进去，家里能做饭、能洗澡、网络可用

• 边界：旧家具不搬；不做全屋收纳；先保证床和冰箱

• 依赖：先水电与网络，再床与冰箱，再零碎物品

• 检查点：周五晚上打包完成；周六中午搬运完成；周六下午安装网络与床

• 回滚：如果网络装不上，准备临时热点与应急路由

这套写法搬到研发里几乎不需要改词，只要问题足够复杂，我们自然会走向同一个框架：

1.先对齐目标：做这件事是为了解决什么痛点（动机）

2.再定义边界：不做什么比做什么更重要

3.拆成可执行块：把大问题拆成能一周内验收的小块

4.排依赖与先后：先解决被依赖最多的环节（否则后面全卡死）

5.设验收与回滚：能上线的标准是什么，出了问题怎么退

6.复盘并固化：把这次的经验变成下次的“默认选项”

为了让 Plan 能被复用，我们把它固化成一张“计划卡”，一张“够用就行”的计划卡（对人、对 AI 都通用）；Plan 不需要写成大文档，很多时候记住这 6 个词就够了：

• 目标：交付物长什么样（能演示/能验收）

• 边界：本期不做什么

• 未知数：最可能翻车的 3-5 件事

• 依赖：谁先谁后

• 验收：怎么判定“可用”

• 回滚：出问题怎么退

一句点睛：Plan 不是“先想更多”，而是“先把最贵的返工想清楚”。

Plan 的精髓：上帝视角看“未来的演进”

很多人把 Plan 理解成“先列步骤”，实际上，Plan 最精髓的地方在于：它逼我们站到一个更高的上帝视角，不是看“这一步怎么做”，而是看下一步会怎么变、再下一步会怎么失控。

所以 Plan 不是为了让人更听话，反而是为了让协作更敢“不听话”，它允许（甚至鼓励）大家参与进来进行反问——把歧义、边界争议、隐性假设，当场摊开。

Plan 真正有价值的反问通常只有两类：

• 边界反问：这次不做什么？如果不写清楚，需求会自己长大

• 演进反问：如果上线后一周、一个月，会出现哪三种必然的变化？今天的设计能不能扛住

这就是为什么 Plan 能提效：它不是让执行更快，而是让“未来更可预期”，让返工不再以“推倒重来”的形式出现。

产品侧最常遇到的困境不是“不知道需求”，而是“需求一旦进入研发链路，就会发生变形”。

Plan 对产品最关键的两点：

• 边界要清晰：本期不做什么，否则研发链路一定被拖进无底洞

• 验收要具体：客成部说“好用”不算，必须拆成可验收的标准

后端与前端的协作里，最贵的成本不是写代码，而是：

• 接口字段反复改

• 前端等待后端

• 联调时发现理解偏差

Plan 的做法很简单：把“接口契约 + 验收标准 + 联调检查点”写进计划。
这能直接减少返工。

Plan 对负责人：先把“什么时候可用”变成可交付节奏

负责人最需要的不是“承诺”，而是“里程碑可见”。

Plan 的输出应该天然带里程碑：

• 第 3 天可演示什么

• 第 7 天可上线什么

• 哪些风险会影响节奏

Plan 的价值：把计划变成AI提效“以终为始”的控制器

Plan 模式里，AI 要先做三件事

• Clarify（澄清）：像工程师一样追问关键歧义

• Review（出计划）：输出一份可改的 Markdown 计划（这是最关键的一步）
  

• Build（再执行）：计划确认后再改代码

如果只留一句话，通常这样就够用：
“进入 Plan 模式：先问清楚边界和验收（尤其是不做什么），再给出可执行的实施计划，等确认后再动手。”

两个关键点（决定 Plan 是否真的提效）

• 让 AI 先问问题：不问问题直接写计划，等于把风险藏到执行阶段

• 让计划可编辑：计划不是给 AI 看，是给我们团队对齐用的

Plan 写出来如果不落地，很快就会退化成“又一份文档”。落地只需要三件事：

1）把 Plan 切成“可一两天验收”的小步

大计划不可控，小步才可控。
每一小步都要有：

• 输入（依赖什么、前置完成了什么）

• 输出（能演示/能验收的结果）

• 回滚（做坏了怎么退）

我们米多星球系统最常见的低级失误是“功能做完了才想起联调”。
Plan 里通常两个检查点就够了：

• 中途联调点：接口契约对齐、前端能跑通一条链路

• 上线前验收点：日志、监控、权限、性能、异常场景

插旗点不是口号，它要满足两个条件：

• 能演示：给负责人、业务侧看得懂

• 能复用：下一次类似需求可以直接复刻

AI提效中常用的Plan 检查清单为了避免只讲框架不讲现场，这里用一个BDE系统内常见需求做示例：客户管理加“标签体系”

Step 1：先把“几句话”说清楚（够用就行）

这个需求如果不用 Plan，最容易踩的坑其实就三个：多对多表结构、筛选性能、导出兼容。
所以计划阶段不用写长文档，先把关键点压到几句话：

• 目标：客户列表可按标签筛选，详情可绑定/解绑，运营能看分布

• 边界：本期不做自动推荐/规则引擎/跨系统同步

• 未知数：索引能不能扛住数据量、导出模板如何兼容

• 验收：筛选正确 + 性能达标 + 权限/日志/监控具备 + 可回滚

在 Cursor 里进入 Plan 模式，把上面的“几句话”贴进去，让 AI：

• 先问清楚权限点、导出机制、是否允许标签删除的历史数据处理

• 再输出“会改哪些文件/会加哪些表/会动哪些接口”的清单

这一步的目标不是让 AI 直接写完，而是让我们提前看到两件事：

• 改动边界是否泄洪（有没有把不做的也顺手做了）

• 风险是否漏掉（比如导出兼容、索引缺失、操作日志没记）

• 中途联调点：接口与表结构确定后，先让前端跑通“列表筛选一条链路”，再继续补细节

• 上线前验收点：导出任务跑一轮真实数据量级测试，确认日志、监控、回滚脚本都可用

这就是“Plan 对人 / Plan 对 AI / Plan 对落地”的同一件事：先把未来几步看到，再开始堆细节。

每次开干之前，其实不需要“清单化管理”，只要能在脑子里过一遍这几件事就够了：

• 目标：交付物长什么样

• 边界：本期不做什么

• 依赖：先后顺序是什么

• 验收：怎么判定可用

• 回滚：怎么退回安全状态

• 对标：体验参考的是哪一段

结语：真正的提效不是做得快，而是少走弯路

AI 让实现变得很便宜，但它也把“跑偏的代价”放大了。Plan 的意义就是把“未来几步”提前看见，让每一次出手都更接近交付。

米多公司的星球系统、标识中台（IMP）、BDE系统等EBC软件内，基于“网络协同”和“数据智能”双螺旋引擎的“链路长、依赖多、强协作”场景广泛存在，Plan 不是可选项，而是让 AI 真正提效的前置条件。

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

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

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

系统应用：| | | | | |

数智科普：| | | |

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