阶段 14 讲义 — 两个综合项目的评审标准
阶段 14 讲义 — 两个综合项目的评审标准
本阶段的定位 阶段 12、13 刻意留下的产品定义与商业化交付，全部在这里收敛。两个综合项目不是"再做一次作业"，是把前十三个阶段的产出组装成一份能证明能力的完整作品。
⭐ 最小产出：综合项目 A、B 二选一完整交付（另一个作为后续迭代）。二选一是认真的——两个都做一半，比一个做透差得多。
一、怎么选：A 还是 B
| A · Agent Harness 产品蓝图（Pi 桌面端下一代） | B · 行业 Agent 产品方案（国际机票订票 Agent 2.0） | |
|---|---|---|
| 对应路线 | 通用 Harness | 行业 Agent |
| 展示的能力 | 阶段 6、7、13 的深度 | 阶段 5、10、11、12 的深度 |
| 素材完备度 | Pi 桌面端有真实开发经历与踩坑 | 国际机票有真实业务、真实工具面、真实数据 |
| 可验证性 | 需要 Demo 才有说服力 | 有业务数据，容易量化 |
| 风险 | 与大厂产品对比时容易显得单薄 | 领域特定，通用性展示不足 |
选择依据：阶段 13 实践 1 的主线结论。主线选了哪条，就先做哪个项目。
如果阶段 13 的结论是"两条都有机会"，那么用这三个问题打破平局：
- 哪个项目我能拿到更多真实数据？（有数据的方案永远比纯设计的方案有说服力）
- 哪个项目我能做出可运行的东西？
- 目标岗位更看重哪一类？
二、通用评审标准：任何一个综合项目都要过的七关
这七条是评审者（也包括未来的面试官）实际会用的判据。
| # | 关卡 | 不合格的样子 | 合格的样子 |
|---|---|---|---|
| 1 | 问题真实 | "AI 能提升效率" | 具体的人、具体的任务、当前怎么做、耗时多少 |
| 2 | 边界清晰 | "支持各种订票需求" | 会做什么、不会做什么、什么要确认，三段式写清 |
| 3 | 有取舍 | 每个方案都说"我们选了最好的" | 说清放弃了什么、为什么、什么条件下会改变选择 |
| 4 | 有证据 | "效果很好" | 评测集 + 数据 + 统计口径 |
| 5 | 有风险 | 只讲美好 | 风险清单 + 缓解措施 + 遗留风险 |
| 6 | 能落地 | 停在架构图 | 排期、依赖、成本、第一个里程碑 |
| 7 | 能被质疑 | 没有可攻击的具体主张 | 主张具体到可以被证伪 |
第 7 条最反直觉，也最重要 一份没有可攻击点的方案，通常是因为它没说什么具体的东西。好的方案敢于写"我们判断 X，如果 Y 出现说明判断错了，届时改做 Z"——这样的表述可以被挑战，也因此可信。
评审时的一个实用技巧：读完之后能不能提出三个尖锐问题。提不出来，多半是内容太虚。
三、综合项目 A 的分项标准
以 Pi Agent 桌面端下一代版本 为对象。
| 交付项 | 及格线 | 优秀线 | 来自哪个阶段 |
|---|---|---|---|
| 市场与用户问题定义 | 说清目标用户与他们现在的做法 | 有真实用户访谈或使用数据 | 阶段 12、13 |
| 产品定位与差异化 | 与 Claude Code / Codex 的对比 | 说清"大厂免费版覆盖不到的那部分"是什么 | 阶段 13 |
| 四层架构图 | 分层清晰 | 每层标注"内置/扩展/外部/不做"及理由 | 阶段 0、6 |
| 能力地图 | 列出模型/工具/Skills/MCP/Memory/Subagent | 每项标注当前状态与差距 | 阶段 5、8、9 |
| 安全与授权矩阵 | 有分级 | 四级 + 确认预算检查 + fail-closed 说明 | 阶段 11 |
| Eval 与可观测性方案 | 有评测集 | 三层评测 + 准入门槛 + 五个可观测性问题的答案 | 阶段 10 |
| 生命周期设计 | 有安装/更新流程 | 含自检清单、回滚表（带数据版本）、诊断包 | 阶段 7 |
| 扩展生态与商业模式 | 有设想 | 开发者体验四问 + 定价模式对照 + 成本试算 | 阶段 13 |
| 高保真原型或可运行 Demo | 有原型 | 能跑，且能演示一次完整的失败与恢复 | 阶段 12 |
A 的最大加分项是"失败演示" 大多数 Demo 都在演示成功路径。能当场演示一次失败并优雅恢复（工具报错 → Agent 调整 → 部分结果交付 → 用户可继续），比演示十个成功案例更能证明你理解 Harness 这一层。
四、综合项目 B 的分项标准
以 国际机票 AI 订票 Agent 2.0 为对象。
| 交付项 | 及格线 | 优秀线 | 来自哪个阶段 |
|---|---|---|---|
| 用户旅程与高价值任务 | 有旅程图 | 用四筛子筛过，且指出工具闭环的缺口在哪 | 阶段 12 |
| 确定性流程 vs 开放 Agent 的边界 | 有划分 | 划分依据是"路径可枚举"，且给出混合方案 | 阶段 4 |
| 业务 MCP 工具重构 | 有清单 | 15 个工具的粒度重审报告 + 两份完整契约 | 阶段 5 |
| Booking Context 与长期记忆 | 有设计 | 四层记忆划分 + 写入门槛 + 冲突处理 SOP | 阶段 3、8 |
| 高风险动作确认机制 | 有确认框 | 授权矩阵 + 五段式交互 + 三种异常处理 | 阶段 11、12 |
| 离线评测集与线上指标 | 有用例 | 30 条四类用例 + 三层评测 + 准入门槛 + 失败分类 | 阶段 10 |
| 交互设计 | 有原型 | 12 状态图 + 部分成功设计 + 失败四段式 | 阶段 12 |
| 商业化与增长 | 有想法 | 成本五项试算 + 三种定价对照 + 护城河自检 | 阶段 13 |
B 的最大加分项是"评测集 + 注入演练" 这两样是别人抄不走、也很难速成的东西。一份 30 条的评测集加一份三轮对照的注入演练报告，直接证明了阶段 10、11 的能力——而这两个阶段恰恰是大多数 Agent 产品经理的空白区。
五、七篇公开作品的定位与判据
路线图列出的七篇公开作品，各有不同的展示目的。选做而不是全做——两到三篇写透，好过七篇都写一半。
| # | 作品 | 展示什么 | 核心素材 | 难度 |
|---|---|---|---|---|
| 1 | 《Agent Harness 产品经理知识地图》 | 体系完整性 | 阶段 0 分层图 + 术语表 | 低 |
| 2 | 《从 Model 到 Harness：Agent 软件栈完整拆解》 | 技术深度 | 阶段 0、6 | 中 |
| 3 | 《四种 Agent Harness 哲学：减法、全插件化、工程完备与上下文经济学》 | 比较判断力 | 阶段 6 九格表 | 中 |
| 4 | 《如何评测一个会使用工具的 Agent》 | 稀缺能力 | 阶段 10 评测集与报告 | 高 |
| 5 | 《Agent 的安全不是弹一个确认框》 | 稀缺能力 | 阶段 11 注入演练报告 | 高 |
| 6 | 《国际机票 Agent 2.0 产品蓝图》 | 端到端能力 | 综合项目 B | 高 |
| 7 | 可公开演示的 Agent Harness Demo | 动手能力 | 综合项目 A | 高 |
优先级建议：先写 4 和 5 理由：它们是稀缺的。写"什么是 Agent""MCP 是什么"的文章满地都是；能拿出真实评测数据和注入对照实验的极少。这两篇的素材你在阶段 10、11 已经产出，写作成本低，差异化最高。
第 3 篇是次优先——本仓的四份 Harness 拆解是稀缺素材，但要注意不能只是复述教程结论，必须加上“作为产品经理，我从中提炼出什么可迁移判断”，并区分源码、实测与推断。
六、防止翻车的四条
| 陷阱 | 表现 | 对策 |
|---|---|---|
| AI 味 | 结构工整、术语齐全、没有一句是自己的判断 | 每一节问自己："这句话我在真实工作里验证过吗" |
| 复述教程 | 把 Pi / dsh / Codex / Claude Code 的结论重新组织一遍 | 每个结论后面加一句“这对我们的方案意味着什么” |
| 只有设计没有证据 | 全是架构图和流程图 | 至少一份有数据的实验报告 |
| 回避不利事实 | 只讲成功 | 主动写"这个项目当初做错了什么、现在会怎么改" |
最后一条是本路线的核心态度 路线图开篇写得很清楚："这些拆解多是借助 AI 完成的，产出不等于掌握。" 同样地，作品集里最有说服力的不是"我做了什么"，而是**"我做完之后，看出了当初哪里做错了"**。
一份诚实指出自己项目缺陷并给出改进方案的复盘，比十份"成功案例"更能证明判断力——因为判断力恰恰只能通过"评价自己的作品"来展示。
七、完成度自检
在宣布"做完了"之前，过一遍这张表：
真正完成的标志 路线图给出的标准是：能把一个陌生 Agent 产品拆成模型层、工具层、上下文层、Runtime、Harness、交互层和治理层，并基于证据提出可落地的改进方案。
检验方式很简单：随便找一个你从没研究过的 Agent 产品，给自己 2 小时，写一份 1500 字的拆解与改进建议。写得出来，这条路线就走完了。
Related Documents
- 阶段 14 实践：作品集交付模板
- 阶段 13 实践：路线选择
- 术语表
- 学习路线