第 15 章：技术负责人能力：方案评审、交付和团队协作
本章定位
本章从个人技术产出转向方案 owner。它的目标不是讲管理理论，而是说明如何用技术判断推动交付、证明价值，并让团队依赖你的判断。
必须掌握清单
必须掌握
能把模糊需求拆成可交付、可验证的工作。
相关答案： 先明确目标用户、问题、成功指标和不做什么，再识别依赖与风险，把方案拆成可独立验收的纵向切片。每项工作要有输入、输出、负责人和完成标准，而不是只列技术动作。
具体例子： “优化聊天体验”拆成首 token 延迟基线、流式渲染合批、断线恢复和监控四个交付项，每项都定义目标指标与演示场景。
能写一份驱动决策的技术方案。
相关答案： 技术方案应说明背景、约束、候选方案、选择依据、接口与数据流、风险、验证和回滚，让评审者能做取舍。文档重点是关键决策及证据，不是堆砌所有实现细节。
具体例子： 是否引入微前端的方案对比团队独立性、发布频率、运行时成本和迁移路线，最终说明选择或暂不选择的条件，并给出试点和退出标准。
能进行有效的 Code Review。
相关答案： Review 首先检查行为是否符合需求、边界与失败路径是否正确、安全和兼容性是否受影响，再看测试、可读性和维护成本。意见要说明风险和建议，区分必须修改与可选优化。
具体例子： 审查文件上传时优先确认大小限制、类型校验、取消清理和服务端授权，而不是只讨论变量命名；高风险问题附复现路径和建议测试。
能区分技术债和真正影响业务的缺陷。
相关答案： 缺陷是当前行为不符合已承诺结果并造成用户或业务影响；技术债是过去为速度做出的设计取舍，使未来变更成本或风险上升。二者都应按影响、发生概率和修复成本排序，不能用“债务”包装个人重构偏好。
具体例子： 支付按钮重复扣款是必须立即处理的缺陷；支付模块缺少抽象但当前稳定属于技术债，应在新增渠道前结合预计返工成本安排治理。
能用指标证明前端工作价值。
相关答案： 指标要建立“技术变化—用户体验—业务结果”的因果链，同时记录改动前基线、目标、分群和观测窗口。不能只报告代码量、组件数量或单次实验中的相关性。
具体例子： 将结算页 INP P75 从 420ms 降到 180ms 后，结合 A/B 实验观察表单放弃率和转化率变化；工程平台则跟踪构建时间、发布失败率与交付周期。
原理讲解
技术负责人的核心不是亲自写所有代码，而是把不确定性变成可执行方案。需求到达时先识别目标、范围、风险、验证方式和回滚条件，再进入实现。
技术方案要写清问题、方案、替代方案、风险和验证标准。Code Review 关注行为变化、失败路径、所有权和可维护性，而不是只挑命名。
事故复盘不是找责任人，而是记录时间线、影响、根因、触发条件和预防措施。最后要用指标说明结果，例如上线后性能、错误率、交付周期或业务转化。
代码示例或模板
## 背景
当前 AI 聊天页在工具执行期间没有清晰的 pending、成功、失败和取消状态。
## 方案
引入工具状态机，将 Tool Call 映射到消息节点，并通过外部 store 暴露快照。
## 风险
- 工具失败可能让会话卡在等待状态。
- 用户快速取消可能触发重复清理。
## 验证
- fixture 回放四类工具状态。
- 监控断线重连和取消次数。这是技术方案的最小模板，真实方案还要补充排期、负责人和回滚策略。
AI Agent 概念对照
- Agent 项目 owner 对应系统责任。
- 工具风险对应技术方案中的风险项。
- Session Trace 对应事故复盘证据。
- 指标和 ROI 对应项目价值证明。
面试追问
1. 一个复杂需求到达时，你会先做什么？
查看深度解析
标准回答： 先澄清用户问题、业务目标、成功指标、截止时间和明确不做的范围，再画现状流程和依赖，识别最高风险假设。之后用最小纵向方案验证风险，而不是立即拆技术任务。
原理展开： 复杂需求的主要成本是不确定性；负责人先减少决策风险，再确定架构、里程碑、owner 和验收。
工程示例： “做 AI 客服”先锁定一个高频工单场景、人工兜底和正确率目标，PoC 验证知识检索与权限，再扩展完整后台。
常见误区： 收到需求直接估工期和选框架，或把所有未知都留到开发后期。
继续追问： 产品方也不知道成功指标怎么办？
回答方向： 提出可观测代理指标和失败标准，短周期试点收集基线；把暂定假设写入方案并约定复盘时间。
2. 如何在时间紧张时选择保留质量和删除范围？
查看深度解析
标准回答： 保留正确性、安全、数据完整性、可回滚和关键路径测试这些质量底线；删除次要场景、视觉精修、自动化程度和一次性覆盖范围。用风险和用户价值排序，不把范围压力转化成隐性质量债。
原理展开： 质量不是所有细节都做到满分，而是关键不变量可守住。删范围要同步更新验收、文档与后续计划，不能静默省略失败处理。
工程示例： 首版只支持只读搜索和人工确认，保留权限、审计和监控；延期自动写入、批量操作和高级动画。
常见误区： 通过不写测试、不做鉴权或跳过迁移回滚“赶进度”，上线风险反而不可控。
继续追问： 如果业务坚持全部范围呢？
回答方向： 用选项呈现时间、范围、风险三角及具体后果，要求决策人明确接受；不可突破的安全合规底线仍不作为交易项。
3. 一个事故复盘应该记录什么？
查看深度解析
标准回答： 记录影响范围和时长、用户与业务损失、发现方式、统一时间线、直接触发因素、系统性根因、处置与恢复、哪些防线有效或失效，以及有 owner 和期限的改进项。
原理展开： 复盘目标是改进系统而非寻找替罪者；根因通常包含技术、流程和组织条件。每个行动项应可验证并按风险排序。
工程示例： 发布后白屏不仅记录某行代码错误，还分析为何类型检查、灰度、监控和回滚均未及时阻断，并为每层分配措施。
常见误区： 把“开发不小心”当根因，或列出十几条无人负责的“加强意识”。
继续追问： 如何判断改进项真的完成？
回答方向： 定义验收证据，如故障演练、告警时延、自动阻断测试和回滚时间；后续复盘关闭而非只看任务状态。
4. 你如何证明自己不是普通开发，而是某个模块的 owner？
查看深度解析
标准回答： owner 不只交付代码，还能说明模块目标、用户、架构和风险，建立指标与质量机制，主动协调上下游，在故障和演进中做取舍，并让团队其他人也能稳定维护。
原理展开： 所有权表现为持续结果和决策责任，不等于所有代码都自己写或成为知识瓶颈；要有文档、路线图、SLO、复盘和人才备份。
工程示例： 负责流式运行时的人建立 TTFT/断线指标、统一取消协议、迁移计划和 on-call 手册，把重连故障率降低并让两位同事可独立排障。
常见误区： 用提交量、加班或“只有我懂”证明 owner；这反而说明可维护性和授权失败。
继续追问： 面试中如何量化 owner 价值？
回答方向： 用背景—决策—协作—指标—复盘讲一个完整案例，同时说明代价、未选择方案和团队能力提升。
实践任务
为教育或企业服务 AI Agent 项目写一份技术方案和复盘模板，包含目标、方案、风险、验证和失败处理。
验收标准
- 方案能直接拆成可执行任务。
- 风险项有对应验证方式。
- 复盘模板能形成可跟踪的改进项。