Appearance
Module 7: AI产品经理的Harness落地指南
你的目标：在公司推进工具提效、需求流程提效，年终有实际成果汇报。
7.0 行业趋势：对PM的冲击（来自SF湾区一线观察）
"Builder"角色的崛起
UI设计师、UX研究员、产品负责人、开发者之间的界限正在坍塌。一个新角色正在涌现：Builder —— 端到端拥有问题，用Agent弥补自己缺乏的技能。
- PM不会前端 → 但能用Agent交付一个可工作的UI变更
- 设计师 → 推的是代码而非仅仅是Mockup
- 创始人 → 在团队介入前已原型化完整功能
现在重要的不是你的职位头衔，而是你能否判断输出：这个diff该不该进产品？它正确吗？它与其他部分一致吗？
瓶颈从实现转向产品战略
当实现变便宜时，糟糕的战略变得更贵：
- 慢速实现曾经吸收弱决策（因为来不及做完所有事）
- 快速实现移除了这个缓冲
- 团队现在可以比以前更快地交付低质量战略
结果：产品质量现在更多取决于优先级纪律，而非实现速度。
PM人数问题
15个工程师配3个产品人员已经足够，甚至可能太多。旧的1PM对5-7工程师的比例假设PM是业务意图和技术执行之间的翻译层。当Agent消除了大部分翻译成本后，PM的价值完全向上游转移。
7.0b Evals取代PRD：AI产品经理的新核心技能
传统PM的核心产出是PRD（产品需求文档）。但在AI产品中，PRD无法定义"好"——因为AI输出是概率性的，无法用确定性规格说明。
"Evals are the new PRD." —— Hamel Husain
从PRD到Eval的翻译
| PRD元素 | Eval等价物 |
|---|---|
| 用户故事 | 测试用例（Data） |
| 验收标准 | 评分函数（Scores） |
| 功能规格 | 任务定义（Task） |
| 上线标准 | 最低分数阈值 |
| 版本迭代 | Eval分数趋势 |
一个Eval的三要素
Eval = Data + Task + Scores
Data: 代表性输入样本（来自真实用户场景）
Task: Agent需要完成的具体操作
Scores: 自动评分函数（精确度、完整度、安全性、延迟...）Eval成熟度四阶段
| 阶段 | 描述 | PM动作 |
|---|---|---|
| Vibe Check | 手动看几个输出，"感觉还行" | 记录你的直觉判断标准 |
| Structured Eval | 50+测试用例 + 自动评分 | 将直觉转化为评分函数 |
| CI Eval | 每次Harness变更自动跑Eval | 集成到CI/CD流水线 |
| Continuous Eval | 生产流量持续采样评测 | 建立告警 + 反馈闭环 |
PM的每周Eval节奏
周一：检查上周Eval分数趋势，标记退化
周中：从客户反馈中提取新测试用例，扩充Eval数据集
周五：用最新Eval结果决定下周优先级距离原则： PM的价值在于缩短"用户真正要什么"和"工程指标测什么"之间的距离。Eval就是这座桥——PM定义评测标准，工程优化达标方案。
7.0c Anthropic的AI产品管理方法论（来自Cat Wu）
Anthropic产品负责人Cat Wu的核心论点：当模型能力指数级进化时，传统的长期路线图是浪费。
四个实战原则
| 原则 | 含义 | 实操 |
|---|---|---|
| 快速实验 > 长期规划 | 6个月后模型能力完全不同，现在的限制可能不存在 | 2周冲刺验证 → Demo → 决定是否继续 |
| Side Quest文化 | 鼓励团队成员在主线之外探索新想法 | 每个Sprint留10-20%时间做Side Quest |
| Demo和Eval > 文档 | 原型+评测比产品文档更有说服力 | PM也要能写Eval、跑Demo |
| 用新模型重访旧功能 | 之前因模型限制放弃的功能，新模型可能轻松解决 | 每次模型升级后，重新测试被搁置的需求 |
角色模糊化
在AI-native团队中：
- 工程师做产品决策（因为他们最先看到模型能做什么）
- PM写Eval和原型（不再只写文档）
- 设计师推代码（不再只推Mockup）
"做简单有效的事"（Do the simple thing that works）： 不要为模型的当前限制写复杂workaround。如果一个功能现在模型做不好，等下一个模型版本再试，而不是堆积技术债。
7.0d 吴恩达的速度方法论
Andrew Ng在2026年"Building Faster with AI"演讲中的核心观点，对PM有直接影响：
三个关键判断
具体的想法买来速度： 越具体的需求描述，AI执行越快。模糊的"加个导出功能" vs 具体的"在SBOM列表工具栏右侧添加CSV导出按钮，调用现有export_json模式"——后者让Agent快10倍。
代码不再是珍贵资产： AI能快速生成代码意味着：抛弃和重写的成本大幅降低。PM不要害怕"浪费"之前写的代码，迅速迭代才是正确策略。
PM就是新瓶颈： 工程师速度提升10倍后，PM的需求供给速度成为限制因素。Ng的观察：最好的团队配比已经接近 1 PM : 0.5 工程师（而非传统的1:5-7）。
快速反馈策略组合
| 策略 | 用途 |
|---|---|
| 内部试用（Dogfooding） | 团队先用自己的产品 |
| A/B测试 | 用数据而非直觉决策 |
| 快速原型 | 48小时内出可交互Demo |
| Eval驱动迭代 | 用分数而非感觉判断改进 |
Ng的警告： 如果你不了解AI技术能做什么，你就无法做出正确的架构决策。PM必须具备"对AI可行性的直觉"，这比以往任何时候都重要。
7.1 PM角色转变与OPC
📐 查看Graphviz源码 (07-pm-opc-workflow.dot)
dot
// 见 dots/07-pm-opc-workflow.dot7.2 PM工作的变与不变
收缩的工作
- 详细的ticket翻译
- 作为沟通桥梁的Backlog梳理
- 实现级别的跟进
增长的工作
- 市场理解和客户信号综合
- 在更快工程吞吐量下的优先级管理
- 决定不做什么 （这比以前更重要10倍）
核心判断
实际问题不是"模型能做这个吗？"而是"这里一个静默错误的成本是多少，检测它的成本有多低？"
7.3 落地30天Playbook
Week 1-2: 试水
- 选一个Harness（Windsurf/Cursor/Claude Code），不要选多个
- 添加最小指令文件（AGENTS.md）
- 要求所有Agent PR必须过CI + 自动Review
- 设置单次会话成本告警
Week 3-4: 建规则
- 回顾2周内所有被revert/返工/拒绝的Agent PR
- 从实际失败模式中建立guardrails，不是假设的
- 每周一起Review Agent合并的PR
- 从真实失败中更新流程
持续迭代的节奏
| 频率 | 动作 |
|---|---|
| 每周 | Review Agent导致的回归；将top1重复错误转为规则；检查Issue是否够清晰 |
| 每月 | 重新分级自主性层次；删除死规则和过时指令；审计功能速度vs影响 |
| 每季 | 重新评估工具栈/权限模型/成本结构/PM配比 |
7.4 自主性分级
不是所有PR需要同等审查。从全面审查开始，只在有证据时下调：
| 级别 | 描述 | 示例 |
|---|---|---|
| Tier 1 | 全自主 | 格式化、简单文档更新 |
| Tier 2 | CI验证 + 抽查 | 标准CRUD、测试用例 |
| Tier 3 | 必须人工Review | 核心业务逻辑、API变更 |
| Tier 4 | 多人Review | 安全相关、支付、数据迁移 |
7.5 关键度量指标（年终汇报用）
| 指标 | 含义 | 怎么量 |
|---|---|---|
| Lead Time | 从Issue到合并PR的时间 | Jira/GitHub时间戳 |
| Agent自主率 | 无人干预完成的任务比例 | 标记Agent PR |
| 重开/回滚率 | Agent修改的回滚比例 | Git log分析 |
| 浪费工作率 | 30天内被revert或未使用的功能 | 追踪合并后状态 |
| Issue清晰度 | Agent无需澄清就能执行的比例 | 对话轮次统计 |
| 月度Agent API成本 | 每工程师的Agent成本 | API账单 |
| 客户信号→交付周期 | 从客户反馈到功能上线 | 端到端追踪 |
7.6 公司内部推广话术
给你的老板/同事解释Harness Engineering：
"我们不是在用AI替代开发者。我们是在建设一个结构化的环境，让AI在这个环境中能够可靠地产出高质量代码。就像工厂流水线——不是工人不重要，而是流水线让工人的产出更稳定、更可预测。
Harness的核心是用确定性包裹概率性——通过上下文管理、架构约束和反馈闭环，确保AI不会跑偏。OpenAI自己就用这种方法让Agent写了100万行代码，LangChain用同样的模型通过改善Harness把性能提升了25%。"
7.7 🔬 Lab 7: 制定你的落地计划
任务：
- 写一份1页的"Harness Engineering 30天试点计划"
- 选择一个公司内部的痛点场景
- 设计完整的七层架构
- 定义成功指标
- 准备一个5分钟的演示方案