9.4 工具边界清单

概念

前面三个知识点都在说 WorkBuddy 要做什么，这个知识点反过来说：WorkBuddy 不做什么。

边界清单的目的是保护人。如果工具的边界没有说清楚，会出现两种坏结果：

• 工具越位 ：该人签的决定被工具自动批了，出了事没人负责。

• 人偷懒 ：明明该人做的事，以「工具不能做」为由推掉了。

边界清单的作用是把「哪些是工具该做的」和「哪些是人该做的」划清楚，让两边各司其职。

用法

把话说在前面，比事后被追问更专业。这 12 周你学会的是「用 WorkBuddy 交付」这一件事——但客户不会只问 WorkBuddy。交付现场迟早有人问你：前后端怎么分工？评测集怎么建？相关方不买账怎么办？这些问题课程不教，不是不重要，是它们跟 WorkBuddy 没关系。下面逐项说清楚：为什么不教，以及工具还能替你分担哪一小段。

提示

为什么非得列这张表？因为「会用 WorkBuddy」和「什么都能交付」是两回事。到了客户那边，答不上来的就老实说「这超出了 WorkBuddy 的能力，得另请工程团队」——第 7 章说「不确定性不向下游传递」，能力边界上是同一个道理：答不了的别装，装出来的交付迟早爆。

下面这份清单按「12 周工作流的四个阶段」组织，每个阶段列出「工具做」和「人做」的分界：

立项期边界

最后一行加粗的意思是：项目到底要不要做、值不值得做，这个决定工具不给意见。工具可以帮你把「这个项目的目标是什么、资源够不够、风险有哪些」梳理清楚，但「做不做」这个判断牵涉到商业策略、政治关系、历史包袱——这些只有人能感知到，工具碰不了。

方案设计期边界

「技术可行性」和「业务可行性」是两回事。技术上数据链路跑通了，不代表业务上这个方案客户能接受——可能客户的业务部门根本不愿意把数据接到这个系统里。这种业务判断工具做不了，只能人做。

开发推进期边界

MVP 能不能上线，牵涉到客户验收标准、上线时机、风险容忍度——这些都是商业决定，不是技术决定。工具可以说「代码测试覆盖率 85%」，但不能说「可以上线」。

项目管理期边界

哪些经验值得复用、哪些教训要记住，这需要人去判断「这个经验是不是只在这个客户身上有效」。工具可以给数据支撑（比如「这个 Skill 被调用了 200 次，平均耗时 3 秒」），但「这个经验要不要推广到其他客户」是人判断的。

• 注意 ：边界清单不是一成不变的。随着工具能力升级（比如未来某个版本加了新的安全审计能力），有些「人做」的事项可以变成「工具做+人审」。但「凡是说错要担责的决定，工具只给依据不替人签字」这条总原则永远不变。

示例

场景：客户问「这个合同有没有法律风险？」

• 工具做：用评审技能逐条标注合同条款的风险点和缺失项，输出一份结构化风险清单。

• 人做：律师拿风险清单做二次判断，结合客户的具体业务背景给出法律意见，签字负责。

• 边界：工具不说「这份合同有/没有法律风险」，只说「第 3 条存在 XX 风险、第 7 条缺失 XX 条款」。

场景：客户问「这个功能该不该做？」

• 工具做：用评审技能分析功能点的依赖关系和实现成本，输出一份结构化分析。

• 人做：项目经理结合客户预算、时间、战略优先级，决定做不做。

• 边界：工具不说「这个功能该做/不该做」，只说「这个功能依赖 XX、成本约 XX、风险约 XX」。

场景：客户问「这个方案对不对？」

• 工具做：用评审技能从流程完整性、PRD 可开发性、数据链路、技术可行性四个维度给结构化意见。

• 人做：教练 + 客户业务负责人共同判断方案是否符合业务实际，签字 Go/No-Go。

• 边界：工具不说「方案对/不对」，只说「流程完整/不完整、PRD 清晰/不清晰」。

三个场景的共同模式：工具做「拆解和分析」，人做「判断和担责」。

• 注意 ：如果你在 12 周的任何一周发现「这个决定是工具自动做的」，立刻检查边界清单。要么是边界没说清楚，要么是有人偷懒把决定甩给了工具。两种情况都要纠正。