[ { "number": 1, "chapter": "01 一个价值数十亿美元的设计蓝图", "page_hint": "EPUB 章节", "title": "Harness Engineering", "interview_question": "什么是 Harness Engineering？", "short_answer": "Harness Engineering 是围绕大模型搭建可靠运行系统的工程方法，包括工具、权限、记忆、上下文、安全、协作和评估。模型决定能力上限，harness 决定能力能否稳定交付。", "key_points": [ "Agent 产品不是 API wrapper，而是模型、运行时、工具、状态和治理的组合。", "模型越强，外围系统越要处理边界、失败恢复和用户信任。", "可迁移价值在设计决策，而不是某个版本的具体实现细节。" ], "follow_ups": [ "Harness 和普通应用后端有什么区别？", "为什么 AI 产品不能只拼模型能力？", "你会怎样评估一个 Agent harness 的成熟度？" ], "project_mapping": [ "把求职准备 Agent 拆成工具调用、资料库、任务计划、权限确认、输出评估五层。", "为 AI 编码助手画出模型之外的运行时系统图。" ], "aipm_transfer": "AI PM 要能从“模型功能”上升到“可交付系统”，定义能力边界、控制面和反馈闭环。", "tags": [ "harness-engineering", "agent-architecture", "ai-product" ], "priority": "P0" }, { "number": 2, "chapter": "01 一个价值数十亿美元的设计蓝图", "page_hint": "EPUB 章节", "title": "源码解析看设计决策", "interview_question": "为什么源码解析的价值不在逐行读代码？", "short_answer": "逐行代码会随版本变化失效，真正可复用的是背后的取舍：为什么这样设计工具、权限、上下文、记忆和协作机制。", "key_points": [ "代码是某个时点的实现，设计原则更稳定。", "架构拆解要回答 why，而不是只翻译 what。", "面试表达应讲清楚约束、备选方案和取舍。" ], "follow_ups": [ "如何把开源项目阅读变成产品洞察？", "读源码时你优先看哪些层？", "什么样的实现细节不值得背？" ], "project_mapping": [ "分析一个 AI 工具时先列设计问题：如何搜索、如何授权、如何压缩、如何恢复。", "把竞品拆解沉淀成设计模式库，而不是截图库。" ], "aipm_transfer": "AI PM 做竞品研究时要少停留在功能清单，多拆系统约束和工程答案。", "tags": [ "source-analysis", "design-decision", "competitive-research" ], "priority": "P1" }, { "number": 3, "chapter": "02 架构全景：Harness的骨架", "page_hint": "EPUB 章节", "title": "CLI 不是简单 API Wrapper", "interview_question": "为什么 AI CLI 需要完整运行时系统？", "short_answer": "成熟 AI CLI 要处理终端 UI、文件系统、子进程、工具状态、权限、安全、上下文和并发协作。它更像一个面向开发者任务的运行时，而不是把用户输入转发给模型。", "key_points": [ "用户目标会跨越多轮、多文件、多工具和多种失败状态。", "运行时要追踪任务状态、工具结果、权限判断和中断恢复。", "终端产品也需要复杂 UI 状态管理和可解释的执行轨迹。" ], "follow_ups": [ "Agent 运行时的核心模块有哪些？", "为什么 CLI 产品也需要前端工程思维？", "如何设计可观察的工具执行过程？" ], "project_mapping": [ "为面试资料库 Agent 设计任务面板：读取、拆解、生成、验证、发布各阶段可见。", "把长任务拆成可中断、可恢复、可审计的步骤。" ], "aipm_transfer": "AI PM 要把 Agent 看成任务系统，明确每一步的状态、用户可见性和失败恢复。", "tags": [ "cli-runtime", "agent-runtime", "observability" ], "priority": "P0" }, { "number": 4, "chapter": "02 架构全景：Harness的骨架", "page_hint": "EPUB 章节", "title": "技术选型服务交互形态", "interview_question": "AI 工具选型应该看哪些真实约束？", "short_answer": "技术选型要从交互形态和负载出发：冷启动、文件读写、子进程、并发、UI 状态、分发体积和可维护性都可能比单点性能更重要。", "key_points": [ "命令行工具对冷启动和响应延迟特别敏感。", "复杂终端 UI 可以借鉴组件化状态管理，而不是拼字符串。", "选型不是追热门，而是匹配产品的高频路径。" ], "follow_ups": [ "什么时候性能是产品体验问题？", "为什么终端也可能需要组件化 UI？", "技术选型如何写进 PRD 或方案评审？" ], "project_mapping": [ "为本地 AI 工具定义启动时间、文件扫描、任务并发和日志渲染指标。", "做技术方案时把用户操作频率转成工程优先级。" ], "aipm_transfer": "AI PM 需要把工程指标翻译成体验指标，例如等待感、信任感和可控感。", "tags": [ "tech-stack", "latency", "terminal-ui" ], "priority": "P1" }, { "number": 5, "chapter": "03 System Prompt工程", "page_hint": "EPUB 章节", "title": "System Prompt 是产品说明书", "interview_question": "为什么 system prompt 是 AI 产品的核心资产？", "short_answer": "System prompt 不只是提示词，而是模型运行前读到的产品规则、角色、边界、工具使用规范和交互契约。它决定 AI 如何理解任务、约束自己和调用系统能力。", "key_points": [ "静态部分定义通用行为规范，可以跨请求复用。", "动态部分注入项目配置、环境状态、用户偏好和工具说明。", "prompt 设计要模块化，否则难以维护、测试和演进。" ], "follow_ups": [ "System prompt 和普通 prompt 有什么区别？", "如何测试 system prompt 改动？", "动态上下文注入有什么风险？" ], "project_mapping": [ "为求职 Agent 拆分身份、任务流程、输出格式、工具规则、风险边界五类 prompt。", "建立 prompt 版本和回归测试集。" ], "aipm_transfer": "AI PM 要把 system prompt 当成产品规格的一部分管理，而不是临时文案。", "tags": [ "system-prompt", "prompt-engineering", "product-spec" ], "priority": "P0" }, { "number": 6, "chapter": "03 System Prompt工程", "page_hint": "EPUB 章节", "title": "静态 Prompt 与动态上下文", "interview_question": "静态 prompt 和动态上下文应该怎样分层？", "short_answer": "静态 prompt 放稳定规则，动态上下文放会随用户、项目和环境变化的信息。分层清楚可以降低 token 浪费，也能减少过期信息污染。", "key_points": [ "静态规则适合描述身份、风格、工具协议和安全边界。", "动态信息适合注入当前目录、配置、记忆、git 状态和语言偏好。", "动态上下文要控制顺序、长度、可信来源和冲突解决策略。" ], "follow_ups": [ "为什么动态上下文不能无限塞？", "当 CLAUDE.md 和系统规则冲突怎么办？", "如何避免 prompt 注入？" ], "project_mapping": [ "把用户简历、JD、目标岗位和历史反馈分别作为动态上下文模块。", "对外部文档设置可信等级和最大注入长度。" ], "aipm_transfer": "AI PM 要定义上下文优先级：系统安全 > 用户目标 > 项目配置 > 参考资料。", "tags": [ "dynamic-context", "context-injection", "prompt-architecture" ], "priority": "P0" }, { "number": 7, "chapter": "03 System Prompt工程", "page_hint": "EPUB 章节", "title": "Prompt 可测试性", "interview_question": "如何把 prompt 从玄学变成工程资产？", "short_answer": "Prompt 工程化需要版本、模块、测试集、回归指标和变更记录。每次改动都应能回答影响了哪些任务、修复了什么失败、是否引入副作用。", "key_points": [ "把 prompt 段落拆成可命名模块，避免大段不可维护文本。", "用固定任务集验证格式、边界、工具选择和拒绝策略。", "保留失败样例和变更理由，形成 prompt changelog。" ], "follow_ups": [ "Prompt 如何做 A/B 测试？", "怎样判断 prompt 改动真的变好？", "谁应该拥有 system prompt？" ], "project_mapping": [ "为面试问答生成建立黄金集：行为面、系统设计、AI PM、项目复盘。", "每次 prompt 改动跑采纳率、事实性、格式稳定性检查。" ], "aipm_transfer": "AI PM 应推动 prompt 进入产品研发流程，和代码、数据、评测一起管理。", "tags": [ "prompt-testing", "eval", "change-management" ], "priority": "P0" }, { "number": 8, "chapter": "04 工具系统：4个原语，59个工具", "page_hint": "EPUB 章节", "title": "工具能力原语", "interview_question": "Agent 工具系统可以如何抽象？", "short_answer": "大量具体工具可以归结为少数能力原语：读取、写入、执行和连接。先抽象能力边界，再扩展具体工具，系统会更容易授权、测试和治理。", "key_points": [ "Read 通常低风险，但可能涉及隐私和敏感文件。", "Write 与 Execute 会改变状态，需要更强确认和回滚设计。", "Connect 连接外部系统，涉及数据外传和第三方副作用。" ], "follow_ups": [ "为什么工具分类会影响权限设计？", "一个新工具上线前要检查什么？", "工具粒度应该粗还是细？" ], "project_mapping": [ "把求职 Agent 工具分成资料读取、文档生成、网站发布、外部搜索。", "每类工具定义默认权限、日志、确认和失败恢复。" ], "aipm_transfer": "AI PM 设计工具生态时，先定义原语和风险等级，再谈插件数量。", "tags": [ "tool-system", "capability-primitives", "permissions" ], "priority": "P0" }, { "number": 9, "chapter": "04 工具系统：4个原语，59个工具", "page_hint": "EPUB 章节", "title": "Bash 是万能适配器", "interview_question": "为什么命令行工具对 Agent 很重要？", "short_answer": "Bash 让 Agent 接入人类开发者已有工具链，不必为每种语言和框架重做集成。它强大但高风险，因此必须配套权限、沙箱、审计和超时控制。", "key_points": [ "CLI 工具覆盖构建、测试、搜索、格式化、部署和系统诊断。", "通用适配器降低集成成本，但扩大误操作范围。", "工具输出要被结构化处理，避免模型误读噪声。" ], "follow_ups": [ "为什么 Bash 比专用工具更灵活？", "如何控制命令执行风险？", "工具输出太长时怎么办？" ], "project_mapping": [ "让 Agent 使用 rg、测试命令和部署命令，但对删除、写系统目录和网络发布加强确认。", "建立命令白名单、超时、输出摘要和可重放日志。" ], "aipm_transfer": "AI PM 要理解“强工具 + 强约束”比“弱工具 + 无约束”更能建立生产力和信任。", "tags": [ "bash", "tool-adapter", "sandbox" ], "priority": "P0" }, { "number": 10, "chapter": "04 工具系统：4个原语，59个工具", "page_hint": "EPUB 章节", "title": "工具不是越多越好", "interview_question": "Agent 工具数量增加会带来什么问题？", "short_answer": "工具越多，模型选择成本、权限复杂度、测试矩阵和失败模式都会增加。工具系统要追求清晰语义、低重叠和可观测，而不是堆数量。", "key_points": [ "功能重叠会让模型在工具选择上不稳定。", "每个工具都需要 schema、权限、错误处理、日志和评测。", "工具文档本身会占用上下文窗口。" ], "follow_ups": [ "什么时候应该合并工具？", "如何评估一个工具值得加入？", "工具 schema 设计有哪些原则？" ], "project_mapping": [ "把多个资料解析入口统一成 ingest_document，再由参数控制文件类型。", "统计工具调用成功率、误选率和平均修复轮次。" ], "aipm_transfer": "AI PM 设计工具平台时，应把工具治理当作产品能力，而不只是开放接口。", "tags": [ "tool-governance", "schema", "agent-ux" ], "priority": "P1" }, { "number": 11, "chapter": "05 权限系统：信任是设计出来的", "page_hint": "EPUB 章节", "title": "权限模式与用户信任", "interview_question": "为什么权限系统是 AI Agent 的核心产品设计？", "short_answer": "Agent 越能做事，越需要让用户知道什么会自动执行、什么需要确认、什么永远禁止。权限系统不是限制能力，而是让用户敢把更多任务交给 AI。", "key_points": [ "权限模式要匹配用户风险偏好和任务类型。", "默认安全边界决定新用户是否敢尝试。", "高权限模式必须有日志、撤销、保护列表和中断能力。" ], "follow_ups": [ "Auto 模式为什么需要安全审查？", "如何设计权限升级流程？", "什么操作必须二次确认？" ], "project_mapping": [ "求职 Agent 发布网站、覆盖文档、联网抓取前需要确认。", "对删除、支付、邮件发送、外部发布设置更高权限门槛。" ], "aipm_transfer": "AI PM 要把权限当成信任漏斗：解释越清楚，用户授权越深。", "tags": [ "permission-system", "trust", "agent-safety" ], "priority": "P0" }, { "number": 12, "chapter": "05 权限系统：信任是设计出来的", "page_hint": "EPUB 章节", "title": "分层安全流水线", "interview_question": "为什么安全审查要做成多层流水线？", "short_answer": "多层审查可以先用低成本规则处理明确安全或明确危险的操作，只把模糊场景交给更昂贵的智能判断，从而平衡安全、延迟和成本。", "key_points": [ "第一层适合快速规则和白名单。", "中间层处理路径、工具类型、上下文和保护资源。", "最后一层可用模型或分类器判断复杂意图。" ], "follow_ups": [ "为什么不能每次都调用安全模型？", "规则和模型如何分工？", "安全误杀会带来什么体验问题？" ], "project_mapping": [ "对文件写入先看路径和扩展名，再看是否覆盖重要文件，最后判断用户意图。", "对外部发送操作区分草稿、预览、确认发送。" ], "aipm_transfer": "AI PM 要为安全设计成本预算：哪些风险靠规则，哪些风险靠人审或模型审。", "tags": [ "safety-pipeline", "risk-control", "classifier" ], "priority": "P0" }, { "number": 13, "chapter": "05 权限系统：信任是设计出来的", "page_hint": "EPUB 章节", "title": "Auto 模式的产品悖论", "interview_question": "Auto 模式如何同时做到高效和安全？", "short_answer": "Auto 模式的难点是既减少确认打断，又不能让用户失去控制。关键是把常规低风险操作自动化，把不可逆、高外部性和敏感操作显式拦截。", "key_points": [ "过多确认会让 Agent 失去自动化价值。", "过少确认会让一次事故摧毁用户信任。", "用户需要看到系统为什么放行或阻止。" ], "follow_ups": [ "如何定义低风险操作？", "Auto 模式出错后如何恢复信任？", "日志可见性要做到什么程度？" ], "project_mapping": [ "允许自动读取和生成候选文档，但发布、删除和发送邮件必须确认。", "任务完成后生成操作摘要和变更列表。" ], "aipm_transfer": "AI PM 要把自动化边界设计得像驾驶辅助：能帮你开，但关键时刻可接管。", "tags": [ "auto-mode", "user-control", "safety-ux" ], "priority": "P0" }, { "number": 14, "chapter": "06 记忆系统：只记偏好，不记代码", "page_hint": "EPUB 章节", "title": "记忆只存慢变量", "interview_question": "Agent 长期记忆应该记什么？", "short_answer": "长期记忆适合存用户偏好、工作方式、稳定约束和外部资源指针，不适合存频繁变化的代码细节、临时状态或可重新检索的事实。", "key_points": [ "偏好变化慢，事实变化快。", "记忆越多，过期、冲突和隐私风险越大。", "索引文件应短小，详细内容按需读取。" ], "follow_ups": [ "为什么不把所有项目事实都存进记忆？", "如何处理用户偏好变更？", "记忆系统需要版本和清理吗？" ], "project_mapping": [ "记录用户喜欢的简历风格、目标岗位、输出语言和避雷偏好。", "不要长期记某份 JD 的临时细节，改为保存文件引用。" ], "aipm_transfer": "AI PM 要定义“可持久化的信息类型”，防止记忆从资产变成污染源。", "tags": [ "memory", "preference", "state-management" ], "priority": "P0" }, { "number": 15, "chapter": "06 记忆系统：只记偏好，不记代码", "page_hint": "EPUB 章节", "title": "文件型记忆的工程价值", "interview_question": "为什么简单文件也能做 Agent 记忆？", "short_answer": "文件型记忆可读、可编辑、可审计、易迁移，适合早期和本地 Agent。只要入口、大小、格式和加载策略清楚，不一定需要数据库或向量库。", "key_points": [ "纯文本降低调试成本，用户也能直接检查。", "入口文件控制加载范围，避免把全部记忆塞进上下文。", "复杂存储只有在规模、检索或权限确实需要时才值得引入。" ], "follow_ups": [ "什么时候需要向量记忆？", "文件记忆如何防止混乱？", "用户是否应该能编辑 AI 记忆？" ], "project_mapping": [ "用 MEMORY.md 存个人偏好，用 reference_docs.md 存资料指针。", "为每条记忆记录来源、更新时间和适用范围。" ], "aipm_transfer": "AI PM 不要默认上复杂基础设施，先用可解释、可控的记忆机制验证价值。", "tags": [ "file-memory", "simple-design", "explainability" ], "priority": "P1" }, { "number": 16, "chapter": "06 记忆系统：只记偏好，不记代码", "page_hint": "EPUB 章节", "title": "记忆的隐私与撤销", "interview_question": "长期记忆如何建立用户安全感？", "short_answer": "用户必须知道 AI 记住了什么、为什么记、在哪里改、如何删除。没有可见性和撤销能力的记忆，会从个性化能力变成信任负担。", "key_points": [ "记忆写入应区分自动建议和用户确认。", "敏感信息默认不记，或只记引用不记内容。", "记忆应有查看、编辑、删除和禁用入口。" ], "follow_ups": [ "哪些信息不该被自动记忆？", "如何设计记忆确认体验？", "记忆错误会造成什么后果？" ], "project_mapping": [ "面试工具提示“我可以记住你的目标岗位偏好”，由用户确认。", "提供一页个人记忆管理面板。" ], "aipm_transfer": "AI PM 做个性化时要把记忆治理和用户控制放在同一优先级。", "tags": [ "memory-privacy", "user-control", "personalization" ], "priority": "P0" }, { "number": 17, "chapter": "07 上下文管理：长对话的生存术", "page_hint": "EPUB 章节", "title": "上下文窗口不是无限记忆", "interview_question": "为什么长上下文仍然需要压缩？", "short_answer": "长上下文解决了容量问题的一部分，但成本、延迟、注意力稀释和无关信息干扰仍然存在。压缩是为了保留任务连续性，而不是机械缩短文本。", "key_points": [ "上下文越长，模型越难稳定关注关键约束。", "压缩需要区分目标、决策、文件状态、用户偏好和未完成任务。", "压缩本身也消耗窗口，因此要预留缓冲。" ], "follow_ups": [ "长上下文和 RAG 是否能替代压缩？", "压缩摘要应该包含哪些字段？", "压缩后如何避免丢需求？" ], "project_mapping": [ "求职资料拆解长会话中保留：已处理书目、生成路径、待办、发布状态。", "在多轮项目里设置阶段性摘要和可恢复 checkpoint。" ], "aipm_transfer": "AI PM 要把上下文压缩设计成状态管理，而不是简单摘要功能。", "tags": [ "context-management", "compaction", "long-session" ], "priority": "P0" }, { "number": 18, "chapter": "07 上下文管理：长对话的生存术", "page_hint": "EPUB 章节", "title": "自动压缩与手动压缩", "interview_question": "什么时候应该自动压缩，什么时候让用户手动压缩？", "short_answer": "自动压缩用于接近窗口上限时保护任务不中断；手动压缩用于用户主动整理上下文、切换阶段或降低噪声。两者解决的问题不同。", "key_points": [ "自动压缩要提前触发，避免压缩过程本身没有空间。", "手动压缩应给用户一个“整理当前任务状态”的控制点。", "压缩结果要可查看，必要时可修正。" ], "follow_ups": [ "压缩摘要可以完全相信吗？", "用户如何知道压缩发生了？", "压缩会影响合规审计吗？" ], "project_mapping": [ "在资料库构建时每处理一本书后生成状态摘要。", "在用户说“进入下一阶段”时建议手动压缩。" ], "aipm_transfer": "AI PM 设计长任务体验时，要让用户感到上下文被管理，而不是被悄悄遗忘。", "tags": [ "auto-compact", "manual-compact", "state-summary" ], "priority": "P1" }, { "number": 19, "chapter": "07 上下文管理：长对话的生存术", "page_hint": "EPUB 章节", "title": "压缩摘要的结构化", "interview_question": "好的上下文摘要应该长什么样？", "short_answer": "好的摘要不是散文，而是结构化状态：目标、约束、已完成、未完成、关键决策、文件路径、风险、下一步。这样才能支持可靠恢复。", "key_points": [ "目标和约束要保留原始优先级。", "文件路径、命令、部署地址等可执行信息必须准确。", "未解决问题和失败尝试比漂亮总结更重要。" ], "follow_ups": [ "摘要过短会丢什么？", "摘要过长又有什么问题？", "如何评估压缩质量？" ], "project_mapping": [ "为 Agent 产出 resume.md，记录当前任务状态和验证结果。", "把待办分成 pending、in_progress、blocked、done。" ], "aipm_transfer": "AI PM 可以把压缩摘要当成 Agent 的工作交接协议。", "tags": [ "structured-summary", "handoff", "agent-state" ], "priority": "P0" }, { "number": 20, "chapter": "08 搜索：为什么grep打败了RAG", "page_hint": "EPUB 章节", "title": "先用确定性搜索", "interview_question": "为什么代码搜索不一定需要 RAG？", "short_answer": "代码库里很多问题是精确符号、路径、字符串和调用关系定位，确定性搜索更快、更便宜、更可解释。RAG 适合语义相似，但不是所有检索问题都需要语义搜索。", "key_points": [ "grep/ripgrep 对符号、错误信息、函数名和配置项非常有效。", "向量检索会引入切分、索引、召回和过期问题。", "强模型可以理解确定性搜索结果，不必把检索层做得过重。" ], "follow_ups": [ "什么时候 grep 不够用？", "RAG 的主要工程成本是什么？", "如何选择检索方案？" ], "project_mapping": [ "面试资料库先用文件名、标题、标签和全文关键字检索，再考虑 embedding。", "对代码 Agent 优先提供 rg、glob、read 等确定性工具。" ], "aipm_transfer": "AI PM 要避免 RAG 崇拜，先判断任务是精确查找、语义探索还是混合检索。", "tags": [ "search", "grep", "rag" ], "priority": "P0" }, { "number": 21, "chapter": "08 搜索：为什么grep打败了RAG", "page_hint": "EPUB 章节", "title": "检索方案的取舍矩阵", "interview_question": "如何判断该用关键词搜索、结构化索引还是向量检索？", "short_answer": "选择检索方案看四件事：查询是否精确、语料是否频繁变化、结果是否需要解释、成本和延迟是否敏感。没有一种方案适合所有场景。", "key_points": [ "关键词搜索适合精确词、代码、错误、标题和标签。", "结构化索引适合元数据、关系和权限过滤。", "向量检索适合意图模糊、同义表达和概念探索。" ], "follow_ups": [ "混合检索怎么设计？", "检索结果如何评估？", "为什么语料更新频繁会影响 RAG？" ], "project_mapping": [ "AI 面试库用标签和标题做第一层，语义搜索做第二层召回。", "对每次检索记录命中卡片、用户采纳和失败原因。" ], "aipm_transfer": "AI PM 要把检索当成产品体验：找得准、解释得清、更新得快。", "tags": [ "retrieval", "hybrid-search", "information-architecture" ], "priority": "P0" }, { "number": 22, "chapter": "08 搜索：为什么grep打败了RAG", "page_hint": "EPUB 章节", "title": "简单组件加智能大脑", "interview_question": "为什么外围组件可以保持简单？", "short_answer": "当核心模型足够强时，外围组件可以提供可靠、低成本、可解释的原始能力，让模型负责理解和组合。复杂度集中比处处复杂更容易维护。", "key_points": [ "简单工具更稳定，也更容易评测和调试。", "模型擅长解释搜索结果、规划下一步和跨工具整合。", "过度工程会让错误来源变多，排查更难。" ], "follow_ups": [ "简单设计会不会限制能力？", "什么时候必须引入复杂基础设施？", "如何避免把复杂度转嫁给用户？" ], "project_mapping": [ "用文件系统和 Markdown 先搭建资料库，再按真实瓶颈引入数据库。", "优先做稳定的读写工具和清晰日志。" ], "aipm_transfer": "AI PM 的技术路线应从最小可靠系统开始，而不是一开始堆全套 AI 基建。", "tags": [ "simple-components", "architecture-principle", "maintainability" ], "priority": "P0" }, { "number": 23, "chapter": "09 多Agent架构：像公司一样运转", "page_hint": "EPUB 章节", "title": "多 Agent 是组织设计", "interview_question": "多 Agent 系统为什么像公司？", "short_answer": "多 Agent 不是简单并发，而是角色、任务分解、上下文隔离、协调协议和结果合并。它像组织管理：谁负责规划，谁负责执行，谁负责验收。", "key_points": [ "Leader 负责分解、调度和整合。", "Worker 负责独立子任务，减少互相干扰。", "协作协议要定义输入、输出、失败和中断处理。" ], "follow_ups": [ "什么时候需要多 Agent？", "多 Agent 会带来哪些额外成本？", "如何避免多个 Agent 互相冲突？" ], "project_mapping": [ "资料库构建中让一个 Agent 抽目录，一个 Agent 生成卡片，一个 Agent 做链接检查。", "复杂项目使用规划者、执行者、审阅者三角色。" ], "aipm_transfer": "AI PM 设计多 Agent 时要先设计组织结构，而不是先增加 Agent 数量。", "tags": [ "multi-agent", "organization-design", "coordination" ], "priority": "P0" }, { "number": 24, "chapter": "09 多Agent架构：像公司一样运转", "page_hint": "EPUB 章节", "title": "并发模式的取舍", "interview_question": "Agent 并发应该如何选择隔离级别？", "short_answer": "同进程并发轻量但隔离弱，独立终端或进程隔离更强但成本更高。选择取决于任务风险、资源冲突、可观察性和中断恢复要求。", "key_points": [ "轻量并发适合搜索、分析和互不写入的任务。", "写文件、执行命令或长任务需要更强隔离和日志。", "隔离级别越高，调度和结果合并成本越高。" ], "follow_ups": [ "多 Agent 同时写文件怎么办？", "如何处理中断和取消？", "并发收益如何衡量？" ], "project_mapping": [ "把只读分析并行化，把写入和部署串行化。", "对每个子任务设置工作目录、权限和产出清单。" ], "aipm_transfer": "AI PM 要定义哪些任务可以并行，哪些必须有锁、审批或顺序约束。", "tags": [ "concurrency", "isolation", "agent-runtime" ], "priority": "P1" }, { "number": 25, "chapter": "09 多Agent架构：像公司一样运转", "page_hint": "EPUB 章节", "title": "结果合并与冲突解决", "interview_question": "多 Agent 的难点为什么在合并而不是启动？", "short_answer": "启动多个 Agent 很容易，难的是把分散结论合并成一致、可执行、无冲突的最终结果。没有合并协议，多 Agent 只会制造更多噪声。", "key_points": [ "每个 Agent 的输出应有固定格式和证据。", "冲突需要标注来源、理由和优先级。", "最终整合者要能拒绝低质量子结果。" ], "follow_ups": [ "如何评估子 Agent 的输出质量？", "多个结论冲突时听谁的？", "多 Agent 是否需要审阅者角色？" ], "project_mapping": [ "让卡片生成 Agent 输出 JSON，再由验证 Agent 检查字段和链接。", "最终发布前由一个整合流程生成 README 和索引。" ], "aipm_transfer": "AI PM 要把多 Agent 的交付标准写清楚：不是每个 Agent 忙完就算完成。", "tags": [ "merge", "conflict-resolution", "quality-control" ], "priority": "P0" }, { "number": 26, "chapter": "10 Feature Flags里的未来", "page_hint": "EPUB 章节", "title": "Feature Flags 是产品实验基础设施", "interview_question": "为什么成熟 AI 产品需要 feature flags？", "short_answer": "Feature flags 让团队可以按用户、场景和实验逐步开放能力，降低新模型、新工具、新交互的发布风险，同时支持 A/B 测试和快速回滚。", "key_points": [ "AI 功能不确定性高，灰度比一次性全量更安全。", "Flags 可以区分内部测试、受邀用户、付费层级和实验组。", "本地缓存与远程评估能平衡可用性和控制。" ], "follow_ups": [ "哪些 AI 功能适合灰度？", "Feature flag 和配置有什么区别？", "如何避免 flag 债务？" ], "project_mapping": [ "对自动发布、记忆写入、多 Agent 并发逐步开放。", "为新模型路由做实验分组和回滚开关。" ], "aipm_transfer": "AI PM 要把发布机制作为产品能力，尤其在高风险 Agent 场景里。", "tags": [ "feature-flags", "ab-testing", "release-management" ], "priority": "P0" }, { "number": 27, "chapter": "10 Feature Flags里的未来", "page_hint": "EPUB 章节", "title": "从 Flags 看路线图", "interview_question": "为什么 feature flags 能透露产品未来方向？", "short_answer": "Flags 往往承载未发布能力、实验分组和内部试用入口。分析 flags 可以看到团队正在押注哪些方向，但不能把实验等同于承诺。", "key_points": [ "Flags 体现探索方向，不代表最终上线。", "实验命名能暴露团队关心的增长、协作、安全或平台化问题。", "竞品研究要区分已发布功能、灰度功能和内部验证。" ], "follow_ups": [ "如何从代码和配置推断路线图？", "为什么不能过度解读实验功能？", "PM 如何管理对外承诺？" ], "project_mapping": [ "记录竞品公开变化、灰度迹象和用户反馈，分层判断确定性。", "自家产品 roadmap 中标注探索、验证、计划和承诺。" ], "aipm_transfer": "AI PM 做战略分析时要有证据等级，不把任何内部迹象都当确定未来。", "tags": [ "roadmap", "competitive-analysis", "experimentation" ], "priority": "P1" }, { "number": 28, "chapter": "10 Feature Flags里的未来", "page_hint": "EPUB 章节", "title": "Flag 债务治理", "interview_question": "Feature flags 会带来什么工程债？", "short_answer": "Flags 增加分支、测试组合和认知负担。如果不清理，系统会变成由临时开关拼出的迷宫。", "key_points": [ "每个 flag 都应有 owner、目的、到期条件和清理时间。", "长期存在的 flag 应转为正式配置或产品权限。", "实验结束后要删除无效代码路径。" ], "follow_ups": [ "如何管理 AI 实验开关？", "Flag 太多会怎样影响测试？", "PM 是否应该参与 flag 清理？" ], "project_mapping": [ "为每个 AI 功能灰度建立实验单：假设、指标、开放人群、结束标准。", "月度清理过期实验和废弃入口。" ], "aipm_transfer": "AI PM 要负责实验生命周期，避免把不确定性永久留在代码里。", "tags": [ "flag-debt", "governance", "experimentation" ], "priority": "P1" }, { "number": 29, "chapter": "11 两个Claude Code", "page_hint": "EPUB 章节", "title": "同一代码库服务内外部产品", "interview_question": "为什么同一代码库会分化出内部版和外部版？", "short_answer": "内部版可以承载更高权限、更快实验和组织内专属能力；外部版需要更强安全边界、合规和通用体验。同一代码库分化能复用核心能力，同时控制风险。", "key_points": [ "内部用户有不同信任前提、数据边界和反馈速度。", "外部产品必须面向更广泛环境和误用风险。", "编译时分化可以移除外部不应包含的内部逻辑。" ], "follow_ups": [ "内部工具和外部产品的差异是什么？", "为什么有些能力先在内部验证？", "如何防止内部逻辑泄露到外部包？" ], "project_mapping": [ "先在内部团队试用 Agent 自动化，再开放给外部用户。", "内部版保留诊断日志，外部版强化隐私和最小权限。" ], "aipm_transfer": "AI PM 要区分 dogfooding、beta 和 GA，不同阶段有不同风险控制。", "tags": [ "internal-product", "external-product", "dogfooding" ], "priority": "P0" }, { "number": 30, "chapter": "11 两个Claude Code", "page_hint": "EPUB 章节", "title": "编译时分化与运行时配置", "interview_question": "什么时候用编译时分化，什么时候用运行时配置？", "short_answer": "编译时分化适合彻底移除不应出现在某版本的能力；运行时配置适合根据用户、套餐或实验动态切换。二者解决的安全和灵活性问题不同。", "key_points": [ "编译时常量可让打包器删除不可达分支，降低泄露面。", "运行时配置更灵活，但代码仍在包内。", "安全敏感能力不应只靠前端运行时开关隐藏。" ], "follow_ups": [ "如何选择多版本产品架构？", "Feature flag 能替代权限系统吗？", "内部功能外泄风险如何控制？" ], "project_mapping": [ "企业私有化版和公有云版可在构建阶段分化敏感集成。", "套餐权益用运行时配置，危险工具能力用权限系统和构建边界。" ], "aipm_transfer": "AI PM 需要理解产品分层背后的安全模型，不只写套餐表。", "tags": [ "build-time", "runtime-config", "product-variants" ], "priority": "P1" }, { "number": 31, "chapter": "12 Harness Engineering方法论", "page_hint": "EPUB 章节", "title": "安全是信任基础", "interview_question": "为什么安全不是 Agent 能力的反面？", "short_answer": "安全系统让用户敢把更多权限交给 Agent，因此它不是功能限制，而是自动化深度的前提。没有安全边界，Agent 能力越强，用户越害怕。", "key_points": [ "用户授权深度取决于可解释边界和可恢复机制。", "安全设计应覆盖预防、审查、执行、日志和补救。", "产品应展示安全工作流，而不是隐藏所有判断。" ], "follow_ups": [ "如何把安全做成卖点？", "安全提示过多会不会降低效率？", "Agent 事故后如何修复信任？" ], "project_mapping": [ "对自动改简历、投递、发邮件等高风险动作显示预览和撤销。", "用变更 diff 和操作日志提升可控感。" ], "aipm_transfer": "AI PM 要把安全指标纳入核心体验指标：误放行、误拦截、恢复时间、用户信任。", "tags": [ "trust", "agent-safety", "automation" ], "priority": "P0" }, { "number": 32, "chapter": "12 Harness Engineering方法论", "page_hint": "EPUB 章节", "title": "持久化存慢变量", "interview_question": "为什么持久化应该存变化慢的东西？", "short_answer": "变化慢的信息更适合长期保存，因为它不容易过期，能稳定提升个性化；变化快的信息应实时检索或从源头读取。", "key_points": [ "偏好、角色、风格和长期目标是慢变量。", "代码位置、任务状态、网页内容和临时资料是快变量。", "错误持久化会制造幻觉和过期依赖。" ], "follow_ups": [ "如何判断一个信息是否该记忆？", "记忆和缓存有什么区别？", "过期记忆如何检测？" ], "project_mapping": [ "保存用户求职方向和表达偏好，不保存某个网页临时内容。", "引用文件路径或 URL，而不是复制一堆可能过期事实。" ], "aipm_transfer": "AI PM 做记忆产品时，要先定义信息生命周期。", "tags": [ "persistence", "slow-changing-state", "memory-design" ], "priority": "P0" }, { "number": 33, "chapter": "12 Harness Engineering方法论", "page_hint": "EPUB 章节", "title": "从可演示到可依赖", "interview_question": "AI 产品如何从 demo 变成可依赖工具？", "short_answer": "Demo 证明模型能做，产品要证明系统能稳定做。可依赖工具需要权限、上下文、状态、测试、观测、回滚和明确边界。", "key_points": [ "一次成功样例不能代表可重复交付。", "真实工作流包含脏数据、长任务、中断、冲突和用户变更。", "可靠性来自外围工程，而不只来自更强模型。" ], "follow_ups": [ "AI demo 到 MVP 的差距在哪里？", "怎样定义 Agent 的可靠性？", "哪些能力必须先有护栏再上线？" ], "project_mapping": [ "为书籍拆解流程加入输入校验、产物检查、链接扫描和线上验证。", "把失败路径和人工接管纳入首版需求。" ], "aipm_transfer": "AI PM 要用“可依赖性”评估产品，而不是只看一次演示的惊艳程度。", "tags": [ "reliability", "demo-to-product", "agent-product" ], "priority": "P0" }, { "number": 34, "chapter": "12 Harness Engineering方法论", "page_hint": "EPUB 章节", "title": "Agent 产品评审清单", "interview_question": "评审一个 Agent 产品应该问哪些问题？", "short_answer": "可以按七层评审：目标是否明确、工具是否足够、权限是否可控、上下文是否可恢复、记忆是否治理、评测是否覆盖、发布是否可灰度。", "key_points": [ "目标层：用户任务是否清晰，成功标准是什么。", "能力层：工具、数据、模型和工作流是否匹配任务。", "治理层：权限、安全、日志、记忆、实验和回滚是否设计完整。" ], "follow_ups": [ "如何判断 Agent 是否过度设计？", "PM 评审和技术评审怎么分工？", "哪些问题必须上线前回答？" ], "project_mapping": [ "将 Agent PRD 增加“工具矩阵、权限矩阵、上下文策略、eval 方案”。", "上线前跑黄金任务、危险任务和恢复任务三组测试。" ], "aipm_transfer": "AI PM 可以把这张清单作为所有 Agent 项目的立项模板。", "tags": [ "review-checklist", "prd", "agent-eval" ], "priority": "P0" }, { "number": 35, "chapter": "全书整合", "page_hint": "EPUB 章节", "title": "Claude Code 架构面试讲法", "interview_question": "面试中如何讲 Claude Code 这类 Agent 产品架构？", "short_answer": "先讲它不是聊天壳，而是 Agent runtime；再按 prompt、tools、permissions、memory、context、search、multi-agent、release 分层；最后讲每层的取舍和迁移到自己项目的做法。", "key_points": [ "用一张系统图串起模型和外围 harness。", "每层准备一个 tradeoff：简单 vs 复杂、自动 vs 控制、记忆 vs 过期。", "落到自己的项目，说明你如何把设计原则变成工程约束。" ], "follow_ups": [ "如果让你设计 Claude Code 竞品，你会先做哪三层？", "如何解释 grep 不用 RAG？", "如何设计 Auto 模式权限？" ], "project_mapping": [ "用本地资料库项目说明：文件 ingestion、卡片生成、站点发布、权限和验证。", "准备 2 分钟架构口述和 5 分钟深挖版本。" ], "aipm_transfer": "AI PM 面试里，这本书可用来展示你理解 Agent 产品的系统性，而不是只会说 prompt。", "tags": [ "interview", "architecture-story", "ai-pm" ], "priority": "P0" }, { "number": 36, "chapter": "全书整合", "page_hint": "EPUB 章节", "title": "AI PM 可迁移专题", "interview_question": "这本书最值得 AI PM 二次抽取的专题是什么？", "short_answer": "最值得沉淀的是 Agent 产品的六个专题：system prompt 规格化、工具和权限矩阵、记忆治理、上下文压缩、检索策略、多 Agent 协作和灰度发布。", "key_points": [ "这些专题可以直接变成 PRD 模板和评审 checklist。", "每个专题都连接用户信任、工程可行性和业务交付。", "后续可把每个专题扩展成独立案例库。" ], "follow_ups": [ "哪些专题最适合写进作品集？", "如何把源码书转成产品方法论？", "下一步该补哪些外部资料？" ], "project_mapping": [ "为 llmforaipm 站点增加 Agent 产品专题页，按六个模块组织卡片。", "把书中原则映射到自己的工具链和面试项目。" ], "aipm_transfer": "AI PM 的价值在于把工程蓝图转成产品判断、协作流程和可复用素材。", "tags": [ "ai-pm", "knowledge-base", "agent-playbook" ], "priority": "P0" } ]