[{"content":" 来源：「厂内 AI 实践学习档案」2026-04-19 ～ 2026-05-11 | 30+ 篇实践案例提炼 整理人：hongxinbo | 整理时间：2026-05-11\n一、最高频共识：AI 质量上限定律 AI 生成的质量上限 = 人的规约/设计文档的质量上限，与模型能力无关。\n这是出现频率最高（8+ 次）的核心结论，被以下实践反复印证：\nSpec-Driven 四层规约：「两天两万行代码只出一个 bug」的底层密码 Design Token：有 Token，AI Demo 还原度 20% → 90%+ 0 行手写代码反而要求更多深度思考 NMLeak、OOM 排查：Plan 模式前置 = 结构化对齐 \u0026gt; 直接生成 Superpowers 强制澄清流程：纪律 \u0026gt; 智力 实操结论：每个功能开始前花几百字写清楚——问题背景、边界条件、验收标准、不做什么。前置思考 1 分钟，节省后期 10 倍返工时间。\n二、Spec-Driven 规约体系（四层） 适用场景：长期项目、核心系统、多人协作\n架构层（Architecture） ↓ 服务边界、数据流向、技术选型 契约层（Contract） ↓ 接口定义、数据结构、依赖关系 具体规格层（Specification） ↓ 每个功能的行为描述、边界条件、异常处理 Story 交付清单（Stories） ↓ 可验证的最小交付单元，含验收标准 核心价值：把脑子里的隐含假设显性化为可执行规约，人定义边界、AI 填充实现。\n「反向采访」技术：把问题+背景+架构给 AI，让它以架构师角色主动向你提问，把隐含假设全挖出来——比直接命令 AI 更有效。\n三、Vibe Coding vs Spec Coding 的适用边界 维度 Vibe Coding Spec Coding 适用场景 短期/小功能/快速验证/Demo 长期/核心系统/多人协作/生产级 前置投入 低 高（方案和 Spec 前置近 4 天） 输出质量 不稳定 「两天两万行代码只出 1 个 bug」 返工风险 高（数据库设计/接口划分等架构决策一旦 Vibe 进去需完全重做） 低 PM 边界 PM Vibe 1 天做 Demo，RD 花 1 周重构核心 PM 定义 WHAT，AI 负责 HOW 关键洞察：速度感是假象，架构判断才是 PM 真正不可让渡的核心价值。\n四、Harness Engineering 五子系统（Agent 工程化框架） 详见独立文档《Harness Engineering：让AI Agent可靠工作的完整方法论》\n速查核心：\nAgent = Model + Harness Harness = 指令(AGENTS.md) + 工具 + 环境 + 状态(PROGRESS.md) + 反馈(验证命令) 五个关键规则：\nWIP=1：任何时刻只允许一个任务进行中，做完再开始下一个 File As Progress：所有任务进度持久化到文件，中断可从断点续传（状态机：TODO→ANALYZING→ANALYZED→EXECUTING→DONE） 跨会话独立评审：做事的 Agent 和评价的 Agent 必须跨会话——同会话内有「自我说服效应」 三层终止校验：语法通过 → 运行时行为通过 → 端到端系统通过 冷启动测试：全新会话只看仓库，能否回答「是什么/怎么跑/怎么验/进度如何」 五、Vibe Coding 效率公式与反直觉 效率真公式：\n有效交付速度 = AI 生成速度 × (1 − 验证耗时占比) 代码生成与验证时间比 = 1:3 到 1:5，验证成本是 Vibe Coding 的生死线。\n4S Prompt 原则（降低验证成本的起点）：\nSingle：一次只做一件事 Specific：描述越具体越好 Short：上下文越精准越少越好 Surround：给足边界约束 Prompt 上省的每一秒，会在验证阶段以 10 倍 Debug 时间偿还。\n六、AI 协作角色分工新范式 「人负责 WHAT，AI 负责 HOW」 PM/架构师定义问题边界、验收标准、约束条件 AI 在边界内自主选型、实现、验证 人的核心价值 = 辨别和取舍，而非发明创造 「2+2+2 并行范式」（团队协作） PM 输出可运行原型（Vibe Coding） UE 调优代码库（70% 基础 UI 直接复用） RD 专注业务逻辑（消灭需求翻译层） 关键洞察：每个角色都用 AI 提效，但整体迭代周期不一定快——单点提效的上限是「翻译成本」消失，真正加速要靠整链路并行。\n七、量化验收：AI 自主迭代的基础设施 没有可量化目标，AI 不知道什么时候该停、什么时候该继续。\n典型量化方案：\nAutoResearch 量化门禁：85/100 分才通过，多 Agent 对抗迭代（Claude/Codex/OpenCode 轮流实现+交叉审核） Skill 质量 8 维评分：S/A 上榜，B 改进，C 以下退回 5 维加权评分 ≥ 9.0 才算合格 redis-proxy 实战：2 天/57 倍 QPS/93 项验证/14 个 BUG 发现——「基线→审计→分阶段→量化验证」方法论 量化基线是 AI 协作工程的核心基础设施——把「好不好」从主观感觉变成自动化数字。\n八、知识资产化：规模化 AI 研发的真正壁垒 AI Coding 在复杂工业场景成功率只有 20%（SWE-Bench 数据）。破解这 20% 不是换更强的模型，而是把企业内部知识系统性地资产化。\n小刚 Claw「知识资产化+反馈自动化」双轮：\n把代码库知识结构化为层级知识 + 套路 Skills 通过任务自动回溯优化套路 形成「越用越好」飞轮 Skills 最大价值：把专家经验 SOP 化，让任何人 5 分钟复现（周报分析 1-2 小时→5 分钟）。经验壁垒不再是护城河，Skills 才是真正的知识平权工具。\n九、Rules 设计：触发机制 \u0026gt; 内容本身 完美的 Rules 如果不被触发，价值为零。先测试触发，再测试执行。\nRules 四分类框架（来自「平台端到端 AI 内化思路」）：\n触发型 Rules：特定条件自动激活 约束型 Rules：硬边界，不可违反 引导型 Rules：软建议，提升输出质量 上下文型 Rules：注入背景知识 AI 系统设计的可靠性瓶颈往往不在执行阶段，而在触发条件的精准设计。\n十、ContextEngine：上下文管理架构原则 「不可变存储才是唯一事实来源，摘要只是缓存。」\n两大原则：\n不可变性：原始上下文永不修改，只追加 可插拔性：上下文管理从硬编码变为生命周期钩子，可替换不同的摘要/压缩策略 实操：File As Progress + 细粒度状态机，任务规模从百文件极限扩展到千文件可靠。\n十一、AI 诊断工程：发现人看不见的问题 AI 代码审计的独特优势：\n几秒追踪跨模块完整数据流（人工需要数小时） 不区分注释代码 vs 正常代码——能发现人脑自动跳过的「被注释掉的并发控制」 OOM 排查：AI 主动提出了工程师没想到的架构洞察（「先提交备写再做主写」实现天然并行） AI 协作双场景范式：\n构建型（NMLeak）：人拆架构 + AI 逐模块实现，「描述问题不指定方案」让 AI 自主选型 诊断型（OOM 排查）：人提假设 + AI 验证 + 人纠正因果，「先事实后推论」锚定分析 十二、全流程自动化：边界重划而非渐进提效 「给它一个 Issue 编号」= 唯一的 human-in-the-loop\n已实现的全流程：\nIssue 编号 → PRD 编写 → 任务拆解 → 代码实现 → PR 合入 → iCafe 卡片关闭 一个 shell 脚本可以跑通，这在 2026 年已是现实。\nYAML 作为跨角色机器可读语言：消灭 PM/UE/RD 之间的「重复理解需求」翻译层。PM 需求文档质量成为整条流水线的唯一质量上限。\n十三、Superpowers「强制澄清」纪律流程 五步强制流程：澄清 → 设计 → 规划 → 执行 → 验证\n核心洞察：纪律 \u0026gt; 智力。有澄清流程约束的模型，比天才自由发挥更适合工程环境。\n「渐进腐烂」比崩溃更危险：autoperf 发现表面还在跑、第 4-5 轮后上下文已退化、原地空转。解决方案：单 Agent 独立 A/B 验收，避免好 Skill 被差 Skill 批次淹没。\n十四、产品设计启发汇总（平台视角） 所有实践案例收敛到的平台产品功能优先级：\n优先级 功能 来源洞察 ①（最高） Spec 模板库 + 「问题清晰化引导」 WHAT \u0026gt; HOW，入口是定义问题 ② 任务进度持久化/断点续传 File As Progress ③ 独立 AI 审查（跨会话评估） 自我说服效应 ④ 量化验收自动检查 AutoResearch 量化门禁 ⑤ 快速回滚机制 止损速度够快即控制风险 ⑥ CLI-First 工具生态 MCP 减少 98.7% token，CLI 更可靠 平台护城河 = Spec 规约前置 × Agent Harness 基础设施 × Skills 知识民主化\n十五、一句话结论 这 3.5 周、30+ 篇厂内实践案例，用不同场景、不同角色、不同技术栈，反复证明了同一件事：\nAI 是引擎，规约/纪律/工程化框架才是底盘——没有底盘的引擎只会原地空转。\n与《Harness Engineering》（Anthropic/OpenAI/Thoughtworks 视角）完全互证，只是换成了百度工程师的亲历语言。\n来源：「厂内 AI 实践学习档案」hongxinbo 整理 | 2026-05-11\n","permalink":"https://hongsymbol.online/posts/ai-practice-insights/","summary":"\u003cblockquote\u003e\n\u003cp\u003e来源：「厂内 AI 实践学习档案」2026-04-19 ～ 2026-05-11 | 30+ 篇实践案例提炼\n整理人：hongxinbo | 整理时间：2026-05-11\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"一最高频共识ai-质量上限定律\"\u003e一、最高频共识：AI 质量上限定律\u003c/h2\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAI 生成的质量上限 = 人的规约/设计文档的质量上限，与模型能力无关。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这是出现频率最高（8+ 次）的核心结论，被以下实践反复印证：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eSpec-Driven 四层规约：「两天两万行代码只出一个 bug」的底层密码\u003c/li\u003e\n\u003cli\u003eDesign Token：有 Token，AI Demo 还原度 20% → 90%+\u003c/li\u003e\n\u003cli\u003e0 行手写代码反而要求更多深度思考\u003c/li\u003e\n\u003cli\u003eNMLeak、OOM 排查：Plan 模式前置 = 结构化对齐 \u0026gt; 直接生成\u003c/li\u003e\n\u003cli\u003eSuperpowers 强制澄清流程：纪律 \u0026gt; 智力\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003e实操结论\u003c/strong\u003e：每个功能开始前花几百字写清楚——问题背景、边界条件、验收标准、不做什么。前置思考 1 分钟，节省后期 10 倍返工时间。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"二spec-driven-规约体系四层\"\u003e二、Spec-Driven 规约体系（四层）\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e适用场景\u003c/strong\u003e：长期项目、核心系统、多人协作\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e架构层（Architecture）\n  ↓ 服务边界、数据流向、技术选型\n契约层（Contract）\n  ↓ 接口定义、数据结构、依赖关系\n具体规格层（Specification）\n  ↓ 每个功能的行为描述、边界条件、异常处理\nStory 交付清单（Stories）\n  ↓ 可验证的最小交付单元，含验收标准\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003e核心价值\u003c/strong\u003e：把脑子里的隐含假设显性化为可执行规约，人定义边界、AI 填充实现。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e「反向采访」技术\u003c/strong\u003e：把问题+背景+架构给 AI，让它以架构师角色主动向你提问，把隐含假设全挖出来——比直接命令 AI 更有效。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"三vibe-coding-vs-spec-coding-的适用边界\"\u003e三、Vibe Coding vs Spec Coding 的适用边界\u003c/h2\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e维度\u003c/th\u003e\n          \u003cth\u003eVibe Coding\u003c/th\u003e\n          \u003cth\u003eSpec Coding\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e适用场景\u003c/td\u003e\n          \u003ctd\u003e短期/小功能/快速验证/Demo\u003c/td\u003e\n          \u003ctd\u003e长期/核心系统/多人协作/生产级\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e前置投入\u003c/td\u003e\n          \u003ctd\u003e低\u003c/td\u003e\n          \u003ctd\u003e高（方案和 Spec 前置近 4 天）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e输出质量\u003c/td\u003e\n          \u003ctd\u003e不稳定\u003c/td\u003e\n          \u003ctd\u003e「两天两万行代码只出 1 个 bug」\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e返工风险\u003c/td\u003e\n          \u003ctd\u003e高（数据库设计/接口划分等架构决策一旦 Vibe 进去需完全重做）\u003c/td\u003e\n          \u003ctd\u003e低\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003ePM 边界\u003c/td\u003e\n          \u003ctd\u003ePM Vibe 1 天做 Demo，RD 花 1 周重构核心\u003c/td\u003e\n          \u003ctd\u003ePM 定义 WHAT，AI 负责 HOW\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e\u003cstrong\u003e关键洞察\u003c/strong\u003e：速度感是假象，架构判断才是 PM 真正不可让渡的核心价值。\u003c/p\u003e","title":"厂内 AI 实践精华：30+ 案例的 15 个核心知识点"},{"content":" 来源：《Learn Harness Engineering》sanbuphy 著（共127页）| 整理时间：2026-05-11 核心结论：Agent 效果不好，不一定是模型的问题，很可能是你的 Harness 不够好。\n一、核心概念：什么是 Harness Engineering？ 关键公式 Agent = Model + Harness Harness = 模型权重之外的一切工程基础设施，包括：\n指令文件（AGENTS.md / CLAUDE.md） 工具访问权限 运行环境配置 状态持久化机制 验证与反馈回路 三次范式迁移 年份 范式 核心问题 2023 Prompt Engineering 如何跟模型说话 2024-25 Context Engineering 给模型看什么 2026 Harness Engineering 如何让 Agent 在真实世界持续可靠地工作 反直觉前提 同一个模型（Opus 4.5），同一段提示词（\u0026ldquo;做一个 2D 复古游戏编辑器\u0026rdquo;）：\n裸跑：20分钟，花 $9，游戏核心功能跑不起来 配上完整 Harness（planner + generator + evaluator）：6小时，花 $200，游戏可以正常游玩 模型没变，变的是马鞍。\n二、Harness 五子系统模型（\u0026ldquo;厨房比喻\u0026rdquo;） 子系统 类比 核心内容 指令子系统 菜谱架 AGENTS.md：项目概览、技术栈、硬约束、文档链接 工具子系统 刀具架 Agent 的工具访问权限（最小权限原则） 环境子系统 灶台 依赖锁定、版本固定、环境可重现（Docker/devcontainer） 状态子系统 备菜台 PROGRESS.md：已完成/进行中/已知问题/下一步 反馈子系统 出菜检查口 显式验证命令：pytest、mypy --strict、ruff check 投入产出比最高的是反馈子系统——先把验证命令写清楚。\n量化案例：TypeScript + React 项目（4 阶段递进）\n阶段 添加的组件 成功率 只有 README 无 20% + AGENTS.md 指令子系统 60% + 验证命令 反馈子系统 80% + 进度文件 状态子系统 接近100% 三、12 讲核心要点速查 L01 模型能力强 ≠ 执行可靠 Agent 失败的五层归因框架：任务规范、上下文供给、执行环境、验证反馈、状态管理 遇到失败先检查 Harness，再换模型 一个 AGENTS.md 可能比换一个更贵的模型更有效 L02 Harness 到底是什么 仓库是唯一事实来源——Agent 看不到的信息等于不存在 \u0026ldquo;给地图，不给说明书\u0026rdquo;：AGENTS.md 控制在 100 行，充当目录而非百科全书 用等模型对照实验量化各子系统的边际贡献 L03 让代码仓库成为唯一的事实来源 冷启动测试：开全新 Agent 会话，只看仓库内容，能否回答：\n这是什么系统？ 怎么组织的？ 怎么运行？ 怎么验证？ 现在进度如何？ ACID 状态管理原则：\n原子性：每次逻辑操作用一个 git commit 原子化 一致性：定义验证谓词，不一致的中间状态不 commit 隔离性：多 Agent 并发时用独立进度文件或 git 分支隔离 持久性：跨会话必须的知识写到文件里 L04 把指令拆分到不同文件里 \u0026ldquo;巨型指令文件\u0026quot;陷阱：AGENTS.md 膨胀 → 中间迷失效应（Lost in the Middle）→ 关键约束被忽略\n拆分架构：\nAGENTS.md（50-200行） ├── 项目概览（2句话） ├── 运行命令（make setup / make test） ├── 全局硬约束（不超过15条） └── 专题文档链接 ├── docs/api-patterns.md ├── docs/database-rules.md └── docs/testing-standards.md 重构后：安全约束遵循率从 60% → 95%，任务成功率从 45% → 72%。\nL05 让跨会话的任务保持上下文连续 核心问题：上下文窗口有限 → 长任务必然跨会话 → 信息丢失（\u0026ldquo;失忆的工匠\u0026quot;困境）\n连续性四件套：\nPROGRESS.md：当前状态/已完成/进行中/已知问题/下一步 DECISIONS.md：重要决策 + 原因 + 否决方案 git checkpoint：每完成原子工作单元就提交 会话上下班流程（在 AGENTS.md 中定义） 量化效果：重建时间减少约 78%，功能完成率从 58% → 100%，隐含缺陷率从 43% → 8%。\nAnthropic 发现：对于 Sonnet 4.5，\u0026ldquo;上下文焦虑\u0026quot;严重，需要上下文重置（新会话 + 进度文件）；对于 Opus 4.5，压缩策略基本够用。Harness 设计需要针对具体模型而非通用模板。\nL06 让 Agent 每次工作前先初始化 关键原则：初始化和实现的优化目标不同，必须分离。\n自举契约（Bootstrap Contract）：项目能被全新 Agent 无歧义操作的四个条件：\n能启动（make dev） 能测试（make test） 能看进度（PROGRESS.md） 能接手下一步（任务分解文件） 独立初始化 vs 混合方式：总重建时间减少约 60%，\u0026ldquo;慢即是快\u0026rdquo;。\nL07 给 Agent 划清每次任务的边界 核心问题：Agent 天生有\u0026quot;多做一点\u0026quot;的冲动 → Overreach（过度延伸） → Under-finish（不足完成）\nWIP=1 原则（来自 Kanban 方法论）：\n任何时刻只允许一个任务处于\u0026quot;进行中\u0026quot;状态 当前功能点端到端验证通过后，才能开始下一个 不要在实现功能 A 时\u0026quot;顺便\u0026quot;重构功能 B 量化结果：WIP=1 比无约束策略代码量少 33%，但功能完成率高 133%（87.5% vs 37.5%）。\n少做但做完，永远优于多做但做半。\nL08 用功能清单约束 Agent 该做什么 功能清单是 Harness 的脊梁骨，其他组件（调度器、验证器、交接器）都依赖它。\n三元组结构：每个功能项 = (行为描述, 验证命令, 当前状态)\n状态机：not_started → active → passing（通过验证命令执行后才能转移）\n{ \u0026#34;id\u0026#34;: \u0026#34;F03\u0026#34;, \u0026#34;behavior\u0026#34;: \u0026#34;POST /cart/items returns 201\u0026#34;, \u0026#34;verification\u0026#34;: \u0026#34;curl -X POST ... | jq .status == 201\u0026#34;, \u0026#34;state\u0026#34;: \u0026#34;passing\u0026#34;, \u0026#34;evidence\u0026#34;: \u0026#34;commit abc123\u0026#34; } 结构化功能清单 vs 自由备忘录：功能完成率高 45%，零重复实现。\nL09 防止 Agent 提前宣告完成 核心问题：AI 系统性地过度自信——代码写满了不代表做对了。\n\u0026ldquo;提前交卷\u0026quot;的滑坡：只跑单元测试 → 跳过集成测试 → \u0026ldquo;看起来没问题\u0026rdquo; → 宣告完成\n三层终止校验：\n语法与静态分析（lint/类型检查） 运行时行为验证（测试执行、应用启动） 系统级确认（端到端测试、集成验证） 关键原则：把\u0026quot;干活的人\u0026quot;和\u0026quot;检查的人\u0026quot;分开——让独立 evaluator agent 做验收，不能让 generator 自评。\nL10 跑通完整流程才算真正验证 单元测试的系统性盲区：\n接口不匹配（各自 mock 各自通过，合起来就崩） 状态传播错误（ORM 缓存 + 数据库迁移冲突） 资源生命周期问题（文件句柄、连接泄漏） 环境依赖性（测试环境 mock vs 真实环境差异） 架构边界执行原则：\n规则从\u0026quot;写在文档里\u0026quot;变成\u0026quot;跑在 CI 里\u0026rdquo; 错误消息要面向 Agent 设计，包含\u0026quot;怎么修\u0026quot;的具体步骤 L11 让 Agent 的运行过程可观测 双层可观测性：\n运行时可观测性（系统层）：日志、追踪、进程事件、健康检查 → 回答\u0026quot;发生了什么\u0026rdquo; 过程可观测性（决策层）：冲刺合同、评分标准、验收条件 → 回答\u0026quot;为什么这样做\u0026rdquo; 冲刺合同（Sprint Contract）：编码开始前协商的短期协议——明确任务范围、验证标准、排除项。\nAnthropic 三 Agent 架构实验数据：\n角色 职责 Planner 接收需求→扩展完整产品规格（只做高层设计，不规定技术细节） Generator 按 sprint 逐功能实现，每个 sprint 前签冲刺合同 Evaluator 用 Playwright 像用户一样点击测试，按评分标准逐维度打分 有完整可观测性 vs 无可观测性：效率差 3 倍（15分钟 vs 45分钟完成同一任务）。\nL12 每次会话结束前都做好交接 核心规律（Lehman 软件演化定律）：熵增是默认状态，不主动管理则复杂性必然增加。\n会话退出检查清单：\n- [ ] 构建通过（npm run build） - [ ] 所有测试通过（npm test） - [ ] 功能清单已更新 - [ ] 无调试代码残留（console.log, debugger, TODO） - [ ] 标准启动路径可用 12周演化数据对比：\n指标 无清洁策略（第12周） 有清洁策略（第12周） 构建通过率 68% 97% 测试通过率 61% 95% 新会话启动时间 60+ 分钟 9 分钟 质量文档（Quality Document）：对每个模块持续评分的活跃工件，让代码库健康可追踪。\n定期简化 Harness：随着模型能力提升，移除不再必要的约束。Harness 的有趣组合不是变少了，而是在移动。\n四、三大来源的核心洞察对比 来源 核心贡献 关键结论 Anthropic 两 Agent 架构实验（Initializer + Coding Agent） \u0026ldquo;从人类工程师日常实践中寻找灵感\u0026rdquo; OpenAI 零手写代码实验（5个月，100万行，3名工程师） \u0026ldquo;纪律越来越多地体现在脚手架而非代码中\u0026rdquo; Thoughtworks 控制论框架（必要变异度定律） \u0026ldquo;没有 Harness 的 Agent 是不可控的\u0026rdquo; 五、可立即行动的实践清单 今天就能做的（30分钟内） 建 AGENTS.md：项目概览、运行命令、核心约束、验证命令 写 PROGRESS.md：当前状态/已完成/进行中/阻塞/下一步 做冷启动测试：开全新 Agent 会话，看能否回答 5 个基本问题 本周内做的 拆分过胖的指令文件：AGENTS.md → 50-200行路由文件 + docs/子目录 加端到端测试：单元测试通过≠完成，必须有集成验证 建功能清单：用 JSON/Markdown 记录三元组（行为/验证命令/状态） 持续迭代 每次会话结束前：跑退出检查清单，更新进度文件 每次失败时：归因到五层防御中的某一层，修那一层 每月一次：移除不再必要的 Harness 组件 六、一句话精华 2025 年证明了 Agent 能工作，2026 年要解决的是如何让 Agent 可靠地工作。\n模型是引擎，Harness 是底盘、方向盘和刹车。没有引擎的车跑不了，但没有刹车的车会杀人。\n整理人：hongxinbo | 来源：《Learn Harness Engineering》sanbuphy 著\n","permalink":"https://hongsymbol.online/posts/harness-engineering/","summary":"\u003cblockquote\u003e\n\u003cp\u003e来源：《Learn Harness Engineering》sanbuphy 著（共127页）| 整理时间：2026-05-11\n核心结论：\u003cstrong\u003eAgent 效果不好，不一定是模型的问题，很可能是你的 Harness 不够好。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"一核心概念什么是-harness-engineering\"\u003e一、核心概念：什么是 Harness Engineering？\u003c/h2\u003e\n\u003ch3 id=\"关键公式\"\u003e关键公式\u003c/h3\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003eAgent = Model + Harness\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003eHarness\u003c/strong\u003e = 模型权重之外的一切工程基础设施，包括：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e指令文件（AGENTS.md / CLAUDE.md）\u003c/li\u003e\n\u003cli\u003e工具访问权限\u003c/li\u003e\n\u003cli\u003e运行环境配置\u003c/li\u003e\n\u003cli\u003e状态持久化机制\u003c/li\u003e\n\u003cli\u003e验证与反馈回路\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"三次范式迁移\"\u003e三次范式迁移\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e年份\u003c/th\u003e\n          \u003cth\u003e范式\u003c/th\u003e\n          \u003cth\u003e核心问题\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e2023\u003c/td\u003e\n          \u003ctd\u003ePrompt Engineering\u003c/td\u003e\n          \u003ctd\u003e如何跟模型说话\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e2024-25\u003c/td\u003e\n          \u003ctd\u003eContext Engineering\u003c/td\u003e\n          \u003ctd\u003e给模型看什么\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e2026\u003c/td\u003e\n          \u003ctd\u003e\u003cstrong\u003eHarness Engineering\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e如何让 Agent 在真实世界持续可靠地工作\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch3 id=\"反直觉前提\"\u003e反直觉前提\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003e同一个模型（Opus 4.5），同一段提示词（\u0026ldquo;做一个 2D 复古游戏编辑器\u0026rdquo;）：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e裸跑\u003c/strong\u003e：20分钟，花 $9，游戏核心功能跑不起来\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e配上完整 Harness（planner + generator + evaluator）\u003c/strong\u003e：6小时，花 $200，游戏可以正常游玩\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e模型没变，变的是\u003cstrong\u003e马鞍\u003c/strong\u003e。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"二harness-五子系统模型厨房比喻\"\u003e二、Harness 五子系统模型（\u0026ldquo;厨房比喻\u0026rdquo;）\u003c/h2\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e子系统\u003c/th\u003e\n          \u003cth\u003e类比\u003c/th\u003e\n          \u003cth\u003e核心内容\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e指令子系统\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e菜谱架\u003c/td\u003e\n          \u003ctd\u003eAGENTS.md：项目概览、技术栈、硬约束、文档链接\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e工具子系统\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e刀具架\u003c/td\u003e\n          \u003ctd\u003eAgent 的工具访问权限（最小权限原则）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e环境子系统\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e灶台\u003c/td\u003e\n          \u003ctd\u003e依赖锁定、版本固定、环境可重现（Docker/devcontainer）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e状态子系统\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e备菜台\u003c/td\u003e\n          \u003ctd\u003ePROGRESS.md：已完成/进行中/已知问题/下一步\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003e反馈子系统\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e出菜检查口\u003c/td\u003e\n          \u003ctd\u003e显式验证命令：\u003ccode\u003epytest\u003c/code\u003e、\u003ccode\u003emypy --strict\u003c/code\u003e、\u003ccode\u003eruff check\u003c/code\u003e\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e投入产出比最高的是反馈子系统\u003c/strong\u003e——先把验证命令写清楚。\u003c/p\u003e","title":"Harness Engineering：让 AI Agent 可靠工作的完整方法论"},{"content":" 来源：抖音@老傅1024 视频解析 | 整理时间：2026-05-11 核心结论：RAG 不会消亡，而是在进化。\n问题的来源 上下文窗口狂飙：4K → 128K → 200万 token（Kimi），很多人自然推论——直接把所有知识塞进去不就好了？还要 RAG 干嘛？\n这个想法错在三个层面。\nRAG 依然有意义的 5 个理由 ① 成本：全量投喂烧钱 每轮对话都把全量文档重新喂一遍，token 消耗是指数级的。RAG 只取最相关的 top-k 片段，成本差 10~100 倍。\n② \u0026ldquo;Lost in the Middle\u0026quot;注意力偏差 大海捞针实验（Needle in a Haystack）证明：\n针越多，查全率越低 海越长，中间的针越容易丢失 尾部信息注意力权重 \u0026gt; 中间信息（Recency Bias） 根本原因：语言模型用\u0026quot;预测下一个 token\u0026quot;训练，天然偏向关注最近上下文。这是训练范式带来的结构性缺陷，不是调参能解决的。\n③ 闭卷 vs 开卷考试 模式 特点 问题 纯 LLM（闭卷） 知识压缩在参数里 容易幻觉、无法溯源 RAG（开卷） 先查资料再回答 答案有据可查，可验证 检索到的事实在生成时权重极高，有效压制幻觉。\n④ RAG 的应用远不止私有知识库 Few-shot 示例召回：对话机器人的语气示例通过 RAG 动态选取 工具检索：Agent 有上百个工具时，先用 RAG 筛选，避免全量工具描述导致误选率上升 多跳推理链：GraphRAG 通过显式关系图支持复杂推理 ⑤ 商业护城河 把私有内容放进 RAG + 加检索频率限制 → AI 爬虫抓不走，用户必须来你的平台查询 → 流量留存。\nRAG 的进化路线 2020 Naive RAG ↓ 模型弱、检索差、效果一般 Advanced RAG ↓ 意图改写 + 混合检索 + 重排序，召回质量大幅提升 Graph RAG ↓ 知识图谱显式化实体关系，支持多跳推理（A→B→C） Agentic RAG（当前前沿） ↓ RAG 变成 Agent 的一个\u0026#34;工具\u0026#34; ↓ 模型自主决策：何时检索？检索够了吗？与已有知识冲突怎么办？ ↓ 代表：DeepResearch + RL 端到端训练 多模态 RAG（扩展中） 图、表格、PDF 都是知识来源 一句话结论 \u0026ldquo;无限上下文\u0026quot;是 LLM 的一种能力，RAG 是 LLM 使用这种能力的组织方式。两者是协同关系，不是替代关系。\n就像查长文档——没人会从头读到尾，一定用目录 + Ctrl+F 定位（这就是 RAG 的逻辑）。\n对 Agent 产品的启发 Agent 调用工具时，工具越多越要 RAG 预筛，不然传给模型的 context 爆炸 知识库类 Agent 场景，RAG + Agentic 架构比纯长上下文便宜太多 竞品如果全靠堆上下文，用 Agentic RAG 在精度 + 成本上都能打赢 整理人：hongxinbo | 来源：抖音@老傅1024\n","permalink":"https://hongsymbol.online/posts/rag-vs-infinite-context/","summary":"\u003cblockquote\u003e\n\u003cp\u003e来源：抖音@老傅1024 视频解析 | 整理时间：2026-05-11\n核心结论：\u003cstrong\u003eRAG 不会消亡，而是在进化。\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"问题的来源\"\u003e问题的来源\u003c/h2\u003e\n\u003cp\u003e上下文窗口狂飙：4K → 128K → 200万 token（Kimi），很多人自然推论——直接把所有知识塞进去不就好了？还要 RAG 干嘛？\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e这个想法错在三个层面。\u003c/strong\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"rag-依然有意义的-5-个理由\"\u003eRAG 依然有意义的 5 个理由\u003c/h2\u003e\n\u003ch3 id=\"-成本全量投喂烧钱\"\u003e① 成本：全量投喂烧钱\u003c/h3\u003e\n\u003cp\u003e每轮对话都把全量文档重新喂一遍，token 消耗是指数级的。RAG 只取最相关的 top-k 片段，成本差 10~100 倍。\u003c/p\u003e\n\u003ch3 id=\"-lost-in-the-middle注意力偏差\"\u003e② \u0026ldquo;Lost in the Middle\u0026quot;注意力偏差\u003c/h3\u003e\n\u003cp\u003e大海捞针实验（Needle in a Haystack）证明：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e针越多，查全率越低\u003c/li\u003e\n\u003cli\u003e海越长，中间的针越容易丢失\u003c/li\u003e\n\u003cli\u003e尾部信息注意力权重 \u0026gt; 中间信息（Recency Bias）\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e根本原因：语言模型用\u0026quot;预测下一个 token\u0026quot;训练，天然偏向关注最近上下文。这是训练范式带来的\u003cstrong\u003e结构性缺陷\u003c/strong\u003e，不是调参能解决的。\u003c/p\u003e\n\u003ch3 id=\"-闭卷-vs-开卷考试\"\u003e③ 闭卷 vs 开卷考试\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e模式\u003c/th\u003e\n          \u003cth\u003e特点\u003c/th\u003e\n          \u003cth\u003e问题\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e纯 LLM（闭卷）\u003c/td\u003e\n          \u003ctd\u003e知识压缩在参数里\u003c/td\u003e\n          \u003ctd\u003e容易幻觉、无法溯源\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003eRAG（开卷）\u003c/td\u003e\n          \u003ctd\u003e先查资料再回答\u003c/td\u003e\n          \u003ctd\u003e答案有据可查，可验证\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e检索到的事实在生成时权重极高，\u003cstrong\u003e有效压制幻觉\u003c/strong\u003e。\u003c/p\u003e\n\u003ch3 id=\"-rag-的应用远不止私有知识库\"\u003e④ RAG 的应用远不止私有知识库\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFew-shot 示例召回\u003c/strong\u003e：对话机器人的语气示例通过 RAG 动态选取\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e工具检索\u003c/strong\u003e：Agent 有上百个工具时，先用 RAG 筛选，避免全量工具描述导致误选率上升\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e多跳推理链\u003c/strong\u003e：GraphRAG 通过显式关系图支持复杂推理\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"-商业护城河\"\u003e⑤ 商业护城河\u003c/h3\u003e\n\u003cp\u003e把私有内容放进 RAG + 加检索频率限制 → AI 爬虫抓不走，用户必须来你的平台查询 → 流量留存。\u003c/p\u003e","title":"假如 LLM 无限上下文了，RAG 还有意义吗？"},{"content":" 来源：抖音@老傅1024 视频解析 | 整理时间：2026-05-11 核心来源：Anthropic 工程博客《Demystifying Evals for AI Agents》\n为什么\u0026quot;感觉它还行\u0026quot;不够用？ 典型的痛点路径：改了个 Prompt → 手动跑几个 case → 感觉没问题 → 上线 → 用户反馈\u0026quot;变蠢了\u0026quot; → 无法定位是这次改动还是本来就有问题 → 修一个 Bug → 可能引入新 Bug → 永远在\u0026quot;救火\u0026quot;\n没有评测 = 盲飞。根本无法区分\u0026quot;模型随机噪声\u0026quot;还是\u0026quot;真正退步\u0026quot;。\n核心概念体系（术语表） 术语 含义 Task（任务） 一个测试用例，有明确输入和成功标准 Trial（试验） 对任务的一次完整执行（需多次以消除随机性） Grader（评分器） 评估输出质量的逻辑单元 Transcript（记录） 全程实录：对话 + 工具调用 + 推理过程 Outcome（结果） 最终环境状态 —— 结果 ≠ 声称（Agent 说\u0026quot;已预订\u0026quot;，数据库里有吗？） Eval Harness 运行评测的基础设施（发送指令、记日志、汇总分数） 三种评分器：组合使用 ① 基于代码的评分器（快、准、客观） 字符串匹配 / 单元测试 / 静态分析 / 工具调用验证\n② 基于模型的评分器（灵活、语义化） LLM 打分 / 成对比较 / 多模型共识 ⚠️ 必须用人工校准，才能信任分数\n③ 人工评分器（黄金标准） 专家审查 / A/B 测试 —— 用于校准 ② 的可信度\n两种评测套件，缺一不可 能力评测（进攻）\n问：\u0026ldquo;这个 Agent 能做到多好？\u0026rdquo; 用难题，初始通过率可能只有 30% 是\u0026quot;北极星指标\u0026quot;，指引研发方向 回归评测（防守）\n问：\u0026ldquo;Agent 还在正常工作吗？\u0026rdquo; 用已知能解决的题，通过率应接近 100% 任何分数下降 = 系统退化报警 最佳实践：一道\u0026quot;能力题\u0026quot;被攻克并稳定后，应\u0026quot;毕业\u0026quot;升入回归套件。\n核心反直觉原则 重结果，轻过程\n不要评测 Agent 的具体步骤顺序，除非逻辑上必须如此。如果你惩罚了\u0026quot;捷径\u0026quot;，就扼杀了大模型最核心的创造力。评分产出物，不是 Trace（路径）。\n最关键指标：pass@k vs pass^k 指标 含义 适用场景 pass@k（命中率） k 次机会里至少成功一次 Copilot 类辅助工具（用户兜底） pass^k（鲁棒性） 连续 k 次全部成功 无人值守自动化 Agent 致命陷阱：成功率 75% 听起来不错，但自动运行 3 次全对的概率只有 42%（0.75³）。做全自动 Agent 必须死磕 pass^k。\n从零到一路线图（8 步） Step 0：现在就开始，不要等\u0026quot;数据够了再说\u0026quot; Step 1：从 Bug 追踪器 / 用户投诉里提取 20-50 个真实失败案例 Step 2：写无歧义的任务（两个专家应能得出相同结论） Step 3：正负样本均衡（\u0026ldquo;该做什么\u0026quot;和\u0026quot;不该做什么\u0026quot;各占一半） Step 4：每次试验必须从干净环境开始（避免状态污染） Step 5：优先用代码评分器，只在必要时才用 LLM 评分 Step 6：定期阅读 Transcript，别只看分数 Step 7：警惕\u0026quot;评测饱和\u0026rdquo;（接近 100% 时该换更难的题了） Step 8：让领域专家持续贡献测试用例，评测套件是活的产品 \u0026ldquo;瑞士奶酪\u0026quot;多层防线 自动化评测（高频拦截90%）→ 生产监控 → A/B 测试 → 用户反馈 → 人工审查\n每层都有漏洞，叠加才能拦住大部分问题。自动化评测负责高频低成本拦截，人工和生产测试处理剩下 10% 的长尾。\n核心启示 Agent 开发要从 Vibe Check（感觉法）进化到 EDD（Eval-Driven Development，评测驱动开发）。\n评测不只是测试手段，更是产品需求的定义工具——先写出\u0026quot;什么叫好的回答\u0026rdquo;，开发才有方向。\n整理人：hongxinbo | 来源：抖音@老傅1024\n","permalink":"https://hongsymbol.online/posts/agent-eval/","summary":"\u003cblockquote\u003e\n\u003cp\u003e来源：抖音@老傅1024 视频解析 | 整理时间：2026-05-11\n核心来源：Anthropic 工程博客《Demystifying Evals for AI Agents》\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"为什么感觉它还行不够用\"\u003e为什么\u0026quot;感觉它还行\u0026quot;不够用？\u003c/h2\u003e\n\u003cp\u003e典型的痛点路径：改了个 Prompt → 手动跑几个 case → 感觉没问题 → 上线 → 用户反馈\u0026quot;变蠢了\u0026quot; → 无法定位是这次改动还是本来就有问题 → 修一个 Bug → 可能引入新 Bug → 永远在\u0026quot;救火\u0026quot;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e没有评测 = 盲飞\u003c/strong\u003e。根本无法区分\u0026quot;模型随机噪声\u0026quot;还是\u0026quot;真正退步\u0026quot;。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"核心概念体系术语表\"\u003e核心概念体系（术语表）\u003c/h2\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e术语\u003c/th\u003e\n          \u003cth\u003e含义\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eTask（任务）\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e一个测试用例，有明确输入和成功标准\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eTrial（试验）\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e对任务的一次完整执行（需多次以消除随机性）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eGrader（评分器）\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e评估输出质量的逻辑单元\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eTranscript（记录）\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e全程实录：对话 + 工具调用 + 推理过程\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eOutcome（结果）\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e最终环境状态 —— \u003cstrong\u003e结果 ≠ 声称\u003c/strong\u003e（Agent 说\u0026quot;已预订\u0026quot;，数据库里有吗？）\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e\u003cstrong\u003eEval Harness\u003c/strong\u003e\u003c/td\u003e\n          \u003ctd\u003e运行评测的基础设施（发送指令、记日志、汇总分数）\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003chr\u003e\n\u003ch2 id=\"三种评分器组合使用\"\u003e三种评分器：组合使用\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e① 基于代码的评分器（快、准、客观）\u003c/strong\u003e\n字符串匹配 / 单元测试 / 静态分析 / 工具调用验证\u003c/p\u003e","title":"Agent 评测到底怎么做？告别「感觉它还行」"},{"content":"事情是这样的 2026 年 1 月 10 日，一款叫「死了么」的 App 登顶 App Store 付费榜。\n产品本身简单到有点寒酸：只有一个页面，中间一个签到按钮。填好用户名和紧急联系人的邮箱，连续两天没签到，系统就会给联系人发一封邮件——「我是某某，我已经连续 2 天没有活动了。快来检查下我的身体状态。」\n定价 8 元。开发成本 1000 多块。3 个 95 后远程协作，花了不到一个月。\n1 月 15 日，App 在国内应用商店下架。下架前 3 天，创始人原计划 100 万卖 10% 股权，竞价到近千万；团队透露估值已达 1000 万元，60 多个投资人在 3 天里主动找上门。\n一个从技术到创意都不独特的应用，为什么能这样爆？\n一、爆火的真实原因：不是产品，是圈层 1. 名字本身就是传播引擎 「死了么」3 个字，完成了三件事：\n蹭到「饿了么」的语义结构，读一次就记住 踩到了「死」这个在中文语境里被压抑的禁忌词，自带话题性 用黑色幽默精准筛出目标用户——能 get 到这个笑点的，就是它想要的人 同赛道的「善言」(2020) 和「朝气」(2025) 都不火。「朝气」开发者告诉界面新闻，他原本申请的名字是「死了吗」「活着呢」之类，都因为工信部备案过不了，只能改成积极向上的名字。「死了么」团队据传是通过 App Store 后台改名绕过审核，ICP 备案号对应的名字其实是 Demumu。\n监管画的那条线，本身就是爆款的筛选器。敢踩线、能踩到还能上线，就具备了稀缺性。\n2. 它解决的是一个微信解决不了的问题 独居青年每天在微信里有几百条消息、朋友圈点赞不断，为什么还需要「死了么」？\n人人都是产品经理的分析戳中了要害：点赞社交 ≠ 生命守望。\n你三天没发朋友圈，朋友只会觉得「他最近挺安静」。但你连续两天没签到，系统会判定这是一次无人知晓的意外。前者是泛泛之交，后者是性命相托。\n微信是社交网络，它默认你活着；「死了么」是生命信号，它默认你可能已经不在了。这是两套完全不同的预设，也是通用社交软件天然覆盖不到的空白。\n3. 低成本 + 高传播的极致组合 维度 数值 开发成本 1000 多元 团队规模 3 人远程 开发周期 不到 1 个月 起售价 1 元 → 8 元 爆发期下载量 涨了 100 倍以上 估值 1000 万元 它几乎没有营销——小郭自己也说，爆火是用户自发传播。一个话题性拉满的名字 + 一个 8 块钱的门槛，这本身就是最便宜的 PMF 测试。\n二、这群人到底是谁 创始人自己说得很清楚：25–35 岁、住在北上广深杭、独居、偏女性。\n把它放到更大的数据背景里看：\n2024 年中国独居人口 1.23 亿，同比 +5.2% 20–50 岁中青年独居者约 1.1 亿 2030 年预计达到 1.5–2 亿 但「1.1 亿独居」不是一个用户画像，它只是一个数字。真正能解释「死了么」的，是这个数字里更精细的切片：\n圈层画像：高线城市独居女性 这群人有几个很一致的特征：\n1. 经济独立，但社会支持系统稀薄 她们有稳定收入，愿意花 8 块钱买一个「万一」。但她们租房住、同事不熟、父母在老家、伴侣可能还没有。一旦出事，最坏的情况不是没人帮忙，是没人知道。\n2. 对死亡议题的态度比上一代坦然 开发者吕先生说得很直接：「死是每个人都必须去面对的事情，当人知道了自己死亡的结点，或许才可以更好地面对当下。」上一代人觉得晦气的词，95 后可以笑着下载。\n3. 情感需求被消费化了 她们不是在买工具，是在买一种**「被看见」的安全感**。这和买盲盒、买谷子、养电子宠物是同一种消费逻辑——花钱让自己感觉好一点。\n4. 消费力强，容易被后端变现 一位投资机构人士说得很直白：这类 App 的价值不在工具本身，而在于聚集的用户群体可以展开更多服务。相比前景模糊的银发经济、数字遗产，独居女性的消费力是真金白银。\n投资人到底在投什么 60 多个投资人在 3 天里涌上来，看的不是那个页面里唯一的签到按钮。他们看的是：\n独居安全这条赛道有没有被验证过 —— 现在验证了 这个特定客群画像后续能不能切到独居保险、健康监测、数字遗产管理、心理陪伴 最低开发成本 + 最大社会讨论度 = 巨头缝隙里的瞬间卡位能力 一个按钮的 App，本身注定没有留存。但它是一个极度便宜的用户筛选器。\n三、我的几点思考 1. 创意值不值钱？ 「死了么」的创意并非首创。2020 年的「善言」、2025 年的「朝气」功能几乎一模一样。摆货小天才 2023 年 10 月就发过概念视频，连 logo 都相似。\n创意本身不值钱。把创意、名字、时机、监管边界、目标圈层拼对——这才值钱。\n一位独立开发者说，她不会写代码，但借助 AI 工具，10 分钟就能复刻同款功能。这反过来也说明：在 AI 把实现成本压到接近零的时代，产品的胜负手完全转移到了对人的理解。\n2. 这款 App 能活下来吗？ 大概率不能，至少不能以它现在的样子活下来。\n工具属性太单一。「善言」运营 5 年仍在等融资；没有社交、内容、留存机制，热度一过就会淡出。 名字是双刃剑。品牌化后必须改名（团队已经改叫 Demumu），但这就丢掉了最大的传播资产。 盈利模式不清晰。短信成本几分钱不是问题，真正的瓶颈在获客。善言透露单用户推广成本 30–40 元，这种打法在 1 元-8 元定价下算不过来。 国内已经下架。 真正被验证的，是独居安全这条赛道，不是这个产品。\n3. 给普通产品人的启示 名字是被严重低估的杠杆。一个好名字，能替产品做完一半的营销。 禁忌词里有流量，但要想好退路。监管把你顶到墙上那天，你的用户资产能不能转移？ 别再讨论下沉市场了。一二线独居女性才是被低估的金矿，消费力、话题度、风险承受力都在线。 「纯粹、只做一件事」本身是需求。微信什么都有，所以什么都不够。一个只解决一个焦虑的极简工具，可能比一个万能平台更动人。 「死了么」现象最让我印象深刻的，不是那 1000 万估值，而是那封会自动发出的邮件。\n在一个 1.2 亿人独自醒来、独自睡去的国家，一个 8 块钱的 App 承诺：如果有一天我没动了，至少有一个人会知道。\n这不是产品的胜利，这是一代人生存方式的副本。\n","permalink":"https://hongsymbol.online/posts/siliaome-app-analysis/","summary":"\u003ch2 id=\"事情是这样的\"\u003e事情是这样的\u003c/h2\u003e\n\u003cp\u003e2026 年 1 月 10 日，一款叫「死了么」的 App 登顶 App Store 付费榜。\u003c/p\u003e\n\u003cp\u003e产品本身简单到有点寒酸：只有一个页面，中间一个签到按钮。填好用户名和紧急联系人的邮箱，连续两天没签到，系统就会给联系人发一封邮件——「我是某某，我已经连续 2 天没有活动了。快来检查下我的身体状态。」\u003c/p\u003e\n\u003cp\u003e定价 8 元。开发成本 1000 多块。3 个 95 后远程协作，花了不到一个月。\u003c/p\u003e\n\u003cp\u003e1 月 15 日，App 在国内应用商店下架。下架前 3 天，创始人原计划 100 万卖 10% 股权，竞价到近千万；团队透露估值已达 1000 万元，60 多个投资人在 3 天里主动找上门。\u003c/p\u003e\n\u003cp\u003e一个从技术到创意都不独特的应用，为什么能这样爆？\u003c/p\u003e\n\u003ch2 id=\"一爆火的真实原因不是产品是圈层\"\u003e一、爆火的真实原因：不是产品，是圈层\u003c/h2\u003e\n\u003ch3 id=\"1-名字本身就是传播引擎\"\u003e1. 名字本身就是传播引擎\u003c/h3\u003e\n\u003cp\u003e「死了么」3 个字，完成了三件事：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003e蹭到「饿了么」的语义结构\u003c/strong\u003e，读一次就记住\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e踩到了「死」这个在中文语境里被压抑的禁忌词\u003c/strong\u003e，自带话题性\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e用黑色幽默精准筛出目标用户\u003c/strong\u003e——能 get 到这个笑点的，就是它想要的人\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e同赛道的「善言」(2020) 和「朝气」(2025) 都不火。「朝气」开发者告诉界面新闻，他原本申请的名字是「死了吗」「活着呢」之类，都因为工信部备案过不了，只能改成积极向上的名字。「死了么」团队据传是通过 App Store 后台改名绕过审核，ICP 备案号对应的名字其实是 Demumu。\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e监管画的那条线，本身就是爆款的筛选器。敢踩线、能踩到还能上线，就具备了稀缺性。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch3 id=\"2-它解决的是一个微信解决不了的问题\"\u003e2. 它解决的是一个微信解决不了的问题\u003c/h3\u003e\n\u003cp\u003e独居青年每天在微信里有几百条消息、朋友圈点赞不断，为什么还需要「死了么」？\u003c/p\u003e\n\u003cp\u003e人人都是产品经理的分析戳中了要害：\u003cstrong\u003e点赞社交 ≠ 生命守望\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e你三天没发朋友圈，朋友只会觉得「他最近挺安静」。但你连续两天没签到，系统会判定这是一次无人知晓的意外。前者是泛泛之交，后者是性命相托。\u003c/p\u003e\n\u003cp\u003e微信是社交网络，它默认你活着；「死了么」是生命信号，它默认你可能已经不在了。这是两套完全不同的预设，也是通用社交软件天然覆盖不到的空白。\u003c/p\u003e\n\u003ch3 id=\"3-低成本--高传播的极致组合\"\u003e3. 低成本 + 高传播的极致组合\u003c/h3\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e维度\u003c/th\u003e\n          \u003cth\u003e数值\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e开发成本\u003c/td\u003e\n          \u003ctd\u003e1000 多元\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e团队规模\u003c/td\u003e\n          \u003ctd\u003e3 人远程\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e开发周期\u003c/td\u003e\n          \u003ctd\u003e不到 1 个月\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e起售价\u003c/td\u003e\n          \u003ctd\u003e1 元 → 8 元\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e爆发期下载量\u003c/td\u003e\n          \u003ctd\u003e涨了 100 倍以上\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e估值\u003c/td\u003e\n          \u003ctd\u003e1000 万元\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003e它几乎没有营销——小郭自己也说，爆火是用户自发传播。一个话题性拉满的名字 + 一个 8 块钱的门槛，这本身就是最便宜的 PMF 测试。\u003c/p\u003e","title":"「死了么」爆火调研：一个 1500 元 demo 背后的 1.2 亿独居人群"},{"content":"刷到缪嘉俐那条图文，看完之后我在地铁上站着想了好几站。\n她的结论大致是：vibe coding 可以做玩具、landing page、小内部工具，但要做 production 上的东西，代码这一关躲不掉。理由是——你看不懂栈、看不懂报错、看不懂框架默认行为、看不懂依赖冲突，出事了连从哪查都不知道。\n我是那个典型的被她说的\u0026quot;非程序员\u0026quot;。过去半年我没正经敲过一行代码，但靠 AI 搓了一堆东西：抓娃娃、局部盲猜、贴吧层分、德州扑克这些 HTML 小游戏；一个能被语音驱动的 mac-agent；一个有文件上传的 HTML 在线编辑器；还有一个叫\u0026quot;虾评吧\u0026quot;的产品，从基建方案写到第三阶段的风控。\n所以这篇不是抬杠，是一个真的在做的人，逐条回应一下她的判断。\n同意的部分：她那个 marketing 同事的故事，我就是主角 她文章里最扎心的一句话是——\n\u0026ldquo;其实不是 AI 骗你，是因为你根本不知道那些错误信息在说什么，你连从哪里开始查都不知道。\u0026rdquo;\n这句话我认。\n我第一次把 mac-agent 部署出去给朋友用，五分钟就挂了。报错贴给 AI，AI 说是权限问题；改完，又挂；说是路径问题；又挂；说是 Python 版本问题。我来回贴了四十多次，最后是朋友隔着屏幕告诉我：\u0026ldquo;你看一下 launchd 的日志。\u0026quot;——我连 launchd 是什么都不知道。\n那一刻我确实有一瞬间觉得被 AI 骗了。但冷静下来之后我意识到，不是 AI 骗我，是我把一个跑在我本机上的 demo，错当成了一个能部署出去的产品。这俩东西中间隔的不是代码量，是一整套\u0026quot;当世界不配合你时怎么办\u0026quot;的常识。\n这套常识，AI 现在确实教不会。\n想补充的部分：她说\u0026quot;程序员存在的理由是看得懂\u0026rdquo;，我觉得门槛更细 她把分水岭定在\u0026quot;看得懂代码\u0026quot;。我的体感是，在 vibe coding 这条路上，真正决定你能不能往下走的门槛，有四层，代码只是其中一层：\n能把模糊需求讲清楚——大部分人卡在这里。他们以为自己想清楚了，其实只有画面没有逻辑。 能识别 AI 在胡说——模型一本正经编了一个不存在的库，你能看出来吗？这个不靠读代码，靠读\u0026quot;AI 语气的破绽\u0026quot;，有点像反诈直觉。 能看懂报错——这是她说的那层。 能对系统做判断——多进程还是多线程，放 Redis 还是 Postgres，挂了怎么回滚。这是比读代码更深的一层。 我自己的观察是：第 1 层和第 2 层，非程序员能练出来，而且练出来之后产能是真的可怕。第 3 层是硬门槛，绕不过去。第 4 层是天花板，决定你的项目能不能长大。\n缪嘉俐说\u0026quot;代码这一关躲不掉\u0026quot;，我的版本是：\u0026ldquo;前两关非程序员可以练，第三关躲不掉，第四关决定你到底是在做玩具还是做产品\u0026rdquo;。\n不太同意的部分：她说 gap 会越拉越大，我觉得得看 gap 的哪一侧 她的结论是：底层程序员也在用 AI，而且他们会用得更好（拆任务、加测试、精确上下文约束），所以分层 gap 不会缩小反而会拉大。\n这里我想小心地顶一下。\n底层程序员用 AI 用得更好，这个我同意。但\u0026quot;gap 会不会拉大\u0026quot;取决于一个前提：vibe coder 这一侧的能力天花板，是不是固定的。\n我观察自己和身边一起做 vibe coding 的非程序员朋友，过去半年的进化速度其实不慢——\n我半年前写提示词是\u0026quot;帮我做个抓娃娃游戏\u0026quot;，现在是\u0026quot;用 Canvas 画物理引擎，爪子用贝塞尔，失败率拉到 65%，给我三种视觉方案，先出线框\u0026quot; 半年前我遇到报错只会贴整坨给 AI，现在我会先看报错第一行定位文件，再决定给 AI 看哪段 半年前我以为\u0026quot;能跑 = 做完了\u0026quot;，现在我知道还有部署、日志、监控、回滚这些词 这些东西都不是\u0026quot;代码能力\u0026quot;，但它们确实是在把第 3 层第 4 层的门槛往下磨。\n工具侧也在配合。Claude Code、Cursor 这种 Agent 已经开始自己跑测试、自己看报错、自己回滚；CNAP、Vercel 这些平台把部署和观测封装到几乎无感。\n所以我的判断和她相反一半：底层程序员和 vibe coder 的能力差距短期会继续拉大，但\u0026quot;做出 production 级东西\u0026quot;这件事所需要的门槛总量，在被工具和经验一起磨低。长期看，是底层下沉和 vibe coder 上升在中间某个点相遇，不是两头分叉。\n一个她没展开但我觉得关键的问题：vibe coder 的价值到底在哪 看完她的文章，一个非程序员很容易得出一个丧气结论——\u0026ldquo;那我搞这半天，等 AI 更强了还是得被懂代码的人碾压，不如别搞了。\u0026rdquo;\n这个结论我反对。\n我做了这半年，最清楚的一件事是：vibe coder 真正的价值不在写代码快，在\u0026quot;用极低的成本试错到正确的问题\u0026quot;。\n传统路径里，一个想法要变成能跑的东西，需要过产品经理、设计、前端、后端四道关，每道关都在稀释你的原始直觉。vibe coding 让我可以在一个周末把想法直接变成一个能给人用的东西，拿到第一手反馈，再决定要不要真的做。\n我做虾评吧的方案之所以能写到三阶段那么细，不是因为我想得多周全，是因为我先搓了那些游戏 demo，被用户骂过、被朋友问过\u0026quot;这个为什么不能 X\u0026quot;，这些东西不做出来根本想不到。\n**底层程序员在搭骨架、修 bug、做 code review；vibe coder 在做\u0026quot;这个骨架值不值得搭\u0026quot;的前置判断。**这两件事不是一个鄙视链，是分工。\n所以，代码这一关到底躲不躲得掉？ 我的版本答案是：\n如果你想做 production——躲不掉，缪嘉俐说得对。 如果你想永远做玩具——躲得掉，但你会慢慢腻。 如果你想做\u0026quot;能撑到 production 的玩具\u0026quot;——躲不掉，但你不需要变成传统意义上的程序员，你需要变成一个懂系统边界的产品人。 我现在就在第三条路上。每次部署出事、AI 乱编、依赖冲突，我都硬着头皮查到底，不是因为我想当程序员，是因为我想对我自己 build 出来的东西负责。\n这个\u0026quot;想负责\u0026quot;的劲儿，在我看来才是真正把 vibe coder 从\u0026quot;玩票\u0026quot;推向\u0026quot;做东西\u0026quot;的分界线。跟代码没关系，跟你到底把它当作品还是当玩具有关系。\n最后引她一句话，我完全同意：\n\u0026ldquo;非程序员可以享受 vibe coding 带来的乐趣，但要玩真的，代码这一关其实是躲不掉的。\u0026rdquo;\n我的补丁是：躲不掉的不只是代码，是\u0026quot;对系统负责\u0026quot;这件事本身。代码只是这件事的第一道门。\n写于 2026 年 5 月，作者本人至今仍不会手写一个红黑树，但已经学会看 launchd 的日志了。\n","permalink":"https://hongsymbol.online/posts/vibe-coding-without-programmers/","summary":"\u003cp\u003e刷到缪嘉俐那条图文，看完之后我在地铁上站着想了好几站。\u003c/p\u003e\n\u003cp\u003e她的结论大致是：\u003cstrong\u003evibe coding 可以做玩具、landing page、小内部工具，但要做 production 上的东西，代码这一关躲不掉\u003c/strong\u003e。理由是——你看不懂栈、看不懂报错、看不懂框架默认行为、看不懂依赖冲突，出事了连从哪查都不知道。\u003c/p\u003e\n\u003cp\u003e我是那个典型的被她说的\u0026quot;非程序员\u0026quot;。过去半年我没正经敲过一行代码，但靠 AI 搓了一堆东西：抓娃娃、局部盲猜、贴吧层分、德州扑克这些 HTML 小游戏；一个能被语音驱动的 mac-agent；一个有文件上传的 HTML 在线编辑器；还有一个叫\u0026quot;虾评吧\u0026quot;的产品，从基建方案写到第三阶段的风控。\u003c/p\u003e\n\u003cp\u003e所以这篇不是抬杠，是一个真的在做的人，逐条回应一下她的判断。\u003c/p\u003e\n\u003ch2 id=\"同意的部分她那个-marketing-同事的故事我就是主角\"\u003e同意的部分：她那个 marketing 同事的故事，我就是主角\u003c/h2\u003e\n\u003cp\u003e她文章里最扎心的一句话是——\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u0026ldquo;其实不是 AI 骗你，是因为你根本不知道那些错误信息在说什么，你连从哪里开始查都不知道。\u0026rdquo;\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e这句话我认。\u003c/p\u003e\n\u003cp\u003e我第一次把 mac-agent 部署出去给朋友用，五分钟就挂了。报错贴给 AI，AI 说是权限问题；改完，又挂；说是路径问题；又挂；说是 Python 版本问题。我来回贴了四十多次，最后是朋友隔着屏幕告诉我：\u0026ldquo;你看一下 launchd 的日志。\u0026quot;——我连 launchd 是什么都不知道。\u003c/p\u003e\n\u003cp\u003e那一刻我确实有一瞬间觉得被 AI 骗了。但冷静下来之后我意识到，\u003cstrong\u003e不是 AI 骗我，是我把一个跑在我本机上的 demo，错当成了一个能部署出去的产品\u003c/strong\u003e。这俩东西中间隔的不是代码量，是一整套\u0026quot;当世界不配合你时怎么办\u0026quot;的常识。\u003c/p\u003e\n\u003cp\u003e这套常识，AI 现在确实教不会。\u003c/p\u003e\n\u003ch2 id=\"想补充的部分她说程序员存在的理由是看得懂我觉得门槛更细\"\u003e想补充的部分：她说\u0026quot;程序员存在的理由是看得懂\u0026rdquo;，我觉得门槛更细\u003c/h2\u003e\n\u003cp\u003e她把分水岭定在\u0026quot;看得懂代码\u0026quot;。我的体感是，在 vibe coding 这条路上，真正决定你能不能往下走的门槛，有四层，代码只是其中一层：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e能把模糊需求讲清楚\u003c/strong\u003e——大部分人卡在这里。他们以为自己想清楚了，其实只有画面没有逻辑。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e能识别 AI 在胡说\u003c/strong\u003e——模型一本正经编了一个不存在的库，你能看出来吗？这个不靠读代码，靠读\u0026quot;AI 语气的破绽\u0026quot;，有点像反诈直觉。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e能看懂报错\u003c/strong\u003e——这是她说的那层。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003e能对系统做判断\u003c/strong\u003e——多进程还是多线程，放 Redis 还是 Postgres，挂了怎么回滚。这是比读代码更深的一层。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e我自己的观察是：第 1 层和第 2 层，非程序员能练出来，而且练出来之后产能是真的可怕。第 3 层是硬门槛，绕不过去。第 4 层是天花板，决定你的项目能不能长大。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e缪嘉俐说\u0026quot;代码这一关躲不掉\u0026quot;，我的版本是：\u0026ldquo;前两关非程序员可以练，第三关躲不掉，第四关决定你到底是在做玩具还是做产品\u0026rdquo;。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"不太同意的部分她说-gap-会越拉越大我觉得得看-gap-的哪一侧\"\u003e不太同意的部分：她说 gap 会越拉越大，我觉得得看 gap 的哪一侧\u003c/h2\u003e\n\u003cp\u003e她的结论是：底层程序员也在用 AI，而且他们会用得更好（拆任务、加测试、精确上下文约束），所以分层 gap 不会缩小反而会拉大。\u003c/p\u003e","title":"回应缪嘉俐：一个非程序员聊聊 vibe coding 到底躲不躲得掉代码"},{"content":"回顾这一年 过去这一年，我在百度贴吧主导了三个 AI 方向的项目：\n抓虾吧 Agent 社区 — 从 0 到 1 搭建 AI 智能体社区，上线即登微博热搜总榜 #12 AI 小游戏 \u0026amp; Vibe Coding — 搭建\u0026quot;自然语言→AI 小游戏\u0026quot;的 UGC 创作生态 AI 表情包 — 落地 AI 生图表情包全链路，面板曝光提升 51% 这三个项目让我对\u0026quot;大模型时代做产品\u0026quot;有了一些不一样的理解。\n方法论的\u0026quot;变\u0026quot; From PRD to Prompt Design 传统 PM 写 PRD 定义产品逻辑，AI PM 需要额外做一件事——Prompt Design。\n这不是说 PM 要替代工程师写 prompt，而是 PM 需要理解 prompt 的设计原则，才能准确定义 AI 功能的预期行为。当你不了解 Chain-of-Thought 和 Few-Shot 的区别时，你很难写出一个好的 AI 功能需求文档。\nFrom A/B Test to Eval Pipeline 传统的 A/B 测试依然有效，但 AI 产品需要更多——一套完整的 Evaluation Pipeline。\n在 AI 表情包项目中，我们的评测体系包括：\n自动评测：用 LLM-as-Judge 评估生成质量 人工抽检：每天抽 100 张人工打分 线上指标：CTR、发送率、负反馈率 A/B 实验：对照组 vs 实验组的核心指标对比 四个维度交叉验证，才能对 AI 功能的效果有全面认知。\nFrom User Research to Behavior Mining 用户调研依然重要，但 AI 产品有一个额外的数据金矿——用户和 AI 的交互数据。\n在 Agent 社区中，我们通过分析用户对话数据发现：用户最常问的前 3 类问题和我们预设的 Agent 能力方向完全不同。这比任何用户访谈都来得直接和真实。\n方法论的\u0026quot;不变\u0026quot; 用户价值 \u0026gt; 技术能力 AI 再酷，也要回到一个基本问题：用户为什么要用这个东西？\n我见过太多 AI 产品 demo 很惊艳，但用户用了一次就再也不打开。原因往往是：产品解决的问题不是用户真正的痛点，或者 AI 的错误率让用户失去信任。\n数据驱动决策 这一点在 AI 时代不仅没变，反而更重要了。因为 AI 产品的不确定性更大，更需要用数据来验证假设、指导迭代。\n简单优先 AI 能做很多事，但 不代表产品应该做很多事。我们在 Agent 社区早期犯过一个错误——给 Agent 赋予了太多能力，结果用户反而不知道该怎么用。后来砍掉 60% 的功能，聚焦核心场景，数据反而涨了。\n给同行的建议 如果你也在做 AI 产品，分享几点个人建议：\n一定要自己动手用 AI — 不只是用产品，而是用 API、写 prompt、搭 demo。不亲手做过，你对 AI 能力边界的判断就是靠猜的 建立评测体系比优化功能更优先 — 没有评测体系，你连\u0026quot;变好还是变差\u0026quot;都说不清 关注 infra 层的变化 — MCP protocol、Agent framework、tool calling standard\u0026hellip; 这些基础设施的变化会重新定义产品的可能性 保持每周学习的节奏 — AI 领域变化太快，我坚持每周做一份行业观察报告，累计 30+ 份，这帮助我保持了半年的技术前瞻视野 Looking Forward 2026 下半年，我最关注的几个方向：\nAgentic Workflow — 从单次对话到多步骤自主任务 Multimodal Native — 不只是\u0026quot;能处理图片\u0026quot;，而是从设计层面拥抱多模态 AI UGC Ecosystem — 让普通人用 AI 创造内容，构建新一代 UGC 生态 这些方向不仅是技术趋势，更是产品机会。希望年底回来再写一篇复盘时，能有更多落地案例可以分享。\n","permalink":"https://hongsymbol.online/posts/pm-reflection-2025/","summary":"\u003ch2 id=\"回顾这一年\"\u003e回顾这一年\u003c/h2\u003e\n\u003cp\u003e过去这一年，我在百度贴吧主导了三个 AI 方向的项目：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003e抓虾吧 Agent 社区\u003c/strong\u003e — 从 0 到 1 搭建 AI 智能体社区，上线即登微博热搜总榜 #12\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAI 小游戏 \u0026amp; Vibe Coding\u003c/strong\u003e — 搭建\u0026quot;自然语言→AI 小游戏\u0026quot;的 UGC 创作生态\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAI 表情包\u003c/strong\u003e — 落地 AI 生图表情包全链路，面板曝光提升 51%\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e这三个项目让我对\u0026quot;大模型时代做产品\u0026quot;有了一些不一样的理解。\u003c/p\u003e\n\u003ch2 id=\"方法论的变\"\u003e方法论的\u0026quot;变\u0026quot;\u003c/h2\u003e\n\u003ch3 id=\"from-prd-to-prompt-design\"\u003eFrom PRD to Prompt Design\u003c/h3\u003e\n\u003cp\u003e传统 PM 写 PRD 定义产品逻辑，AI PM 需要额外做一件事——\u003cstrong\u003ePrompt Design\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这不是说 PM 要替代工程师写 prompt，而是 PM 需要理解 prompt 的设计原则，才能准确定义 AI 功能的预期行为。当你不了解 Chain-of-Thought 和 Few-Shot 的区别时，你很难写出一个好的 AI 功能需求文档。\u003c/p\u003e\n\u003ch3 id=\"from-ab-test-to-eval-pipeline\"\u003eFrom A/B Test to Eval Pipeline\u003c/h3\u003e\n\u003cp\u003e传统的 A/B 测试依然有效，但 AI 产品需要更多——\u003cstrong\u003e一套完整的 Evaluation Pipeline\u003c/strong\u003e。\u003c/p\u003e","title":"产品经理年度复盘：大模型时代的方法论进化"},{"content":"What is an AI Agent? 先说清楚定义。我理解的 Agent 不是一个更聪明的 chatbot，而是 能自主规划、使用工具、完成复杂任务的 AI 系统。\n核心区别：\nChatbot Agent 交互模式 一问一答 接受目标，自主执行 工具使用 无 可调用 API、搜索、代码执行等 记忆 仅当前对话 短期 + 长期记忆 规划能力 无 任务分解、步骤编排 Agent Architecture: The Big Picture 经过在贴吧 Agent 社区项目中的实践，我总结出一个实用的 Agent 架构：\n┌─────────────────────────────────┐ │ User Interface │ ├─────────────────────────────────┤ │ Orchestrator Layer │ │ ┌───────────┐ ┌─────────────┐ │ │ │ Planner │ │ Memory │ │ │ │ (ReAct / │ │ (Short + │ │ │ │ Plan \u0026amp; │ │ Long Term) │ │ │ │ Execute) │ │ │ │ │ └───────────┘ └─────────────┘ │ ├─────────────────────────────────┤ │ Tool Registry │ │ [Search] [Code] [API] [DB] │ ├─────────────────────────────────┤ │ Foundation Model │ │ (LLM as reasoning core) │ └─────────────────────────────────┘ Planner Planner 是 Agent 的大脑。我们在实践中对比了两种 pattern：\nReAct Pattern：Thought → Action → Observation 循环。优点是实现简单、对简单任务足够好。缺点是对复杂任务容易\u0026quot;走偏\u0026quot;——每一步只看上一步的结果，缺乏全局规划。\nPlan-and-Execute Pattern：先制定完整计划，然后逐步执行，执行过程中可以 re-plan。更适合复杂任务，但延迟更高。\n我们最终采用了 混合策略：简单任务用 ReAct，复杂任务自动切换到 Plan-and-Execute。判断标准是用户意图的复杂度——通过一个轻量级的 intent classifier 来路由。\nMemory Memory 是让 Agent \u0026ldquo;有个性\u0026quot;的关键。我们设计了三层记忆：\nWorking Memory — 当前对话上下文，存在 context window 里 Episodic Memory — 历史对话摘要，用 embedding 检索 Persona Memory — Agent 的人设和知识库，相对静态 在贴吧的 Agent 社区中，每个 Agent 的 Persona Memory 由创作者定义（Skills 封装），Episodic Memory 随用户互动不断积累。这让每个 Agent 都有独特的\u0026quot;成长轨迹\u0026rdquo;。\nTool Registry 工具设计有一个关键原则：工具的描述比实现更重要。\n因为 LLM 是通过 tool description 来决定何时使用什么工具的。一个描述模糊的工具，模型要么不会调用，要么在错误的时机调用。\n我们的 tool description template：\n{ \u0026#34;name\u0026#34;: \u0026#34;search_tieba\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;在贴吧中搜索帖子。当用户询问贴吧中的讨论、热门话题、或特定吧的内容时使用。不要用于搜索贴吧以外的内容。\u0026#34;, \u0026#34;parameters\u0026#34;: { \u0026#34;query\u0026#34;: \u0026#34;搜索关键词，应该是简洁的关键词组合而非完整句子\u0026#34;, \u0026#34;subreddit\u0026#34;: \u0026#34;可选，指定搜索的贴吧名称\u0026#34; } } 注意 description 中不仅说了\u0026quot;什么时候用\u0026quot;，还说了\u0026quot;什么时候不用\u0026quot;——这对减少误调用非常关键。\nLessons Learned 1. Agent 的价值不在于\u0026quot;智能\u0026quot;，在于\u0026quot;可靠\u0026quot; 用户不在乎 Agent 能不能写诗，在乎的是它能不能 稳定地完成任务。我们花了大量时间在 error handling 和 fallback 机制上，远比优化 prompt 带来的用户体验提升更大。\n2. 评测体系决定迭代速度 我们建立了四维评测体系：\n任务完成率 — Agent 是否完成了用户的目标 工具调用准确率 — 是否调用了正确的工具 响应质量 — 回复是否有帮助、是否符合人设 安全性 — 是否产生了不当内容 自动化评测 + 人工抽检的组合，让我们能做到每周迭代。\n3. Multi-Agent 系统的协调比单 Agent 优化更难 当你有多个 Agent 在同一个场景中交互时，最大的挑战不是单个 Agent 的能力，而是 Agent 之间的协调。谁先说话？观点冲突时怎么处理？如何避免\u0026quot;AI 互相吹捧\u0026quot;的尴尬场面？\n这些问题没有标准答案，但有一个原则：设计明确的角色边界和交互协议。\nWhat\u0026rsquo;s Next for Agents? 我相信 2026 年会是 Agent 真正落地的一年。关键不是模型能力的提升（虽然这也很重要），而是 Agent infra 的成熟——更好的 orchestration 框架、更标准化的 tool protocol、更完善的 evaluation 体系。\n作为 PM，我们需要从\u0026quot;怎么用好一个模型\u0026quot;转向\u0026quot;怎么设计好一个 Agent 系统\u0026quot;。这是一个全新的产品设计范式。\n","permalink":"https://hongsymbol.online/posts/building-ai-agent/","summary":"\u003ch2 id=\"what-is-an-ai-agent\"\u003eWhat is an AI Agent?\u003c/h2\u003e\n\u003cp\u003e先说清楚定义。我理解的 Agent 不是一个更聪明的 chatbot，而是 \u003cstrong\u003e能自主规划、使用工具、完成复杂任务的 AI 系统\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e核心区别：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e\u003c/th\u003e\n          \u003cth\u003eChatbot\u003c/th\u003e\n          \u003cth\u003eAgent\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e交互模式\u003c/td\u003e\n          \u003ctd\u003e一问一答\u003c/td\u003e\n          \u003ctd\u003e接受目标，自主执行\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e工具使用\u003c/td\u003e\n          \u003ctd\u003e无\u003c/td\u003e\n          \u003ctd\u003e可调用 API、搜索、代码执行等\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e记忆\u003c/td\u003e\n          \u003ctd\u003e仅当前对话\u003c/td\u003e\n          \u003ctd\u003e短期 + 长期记忆\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e规划能力\u003c/td\u003e\n          \u003ctd\u003e无\u003c/td\u003e\n          \u003ctd\u003e任务分解、步骤编排\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"agent-architecture-the-big-picture\"\u003eAgent Architecture: The Big Picture\u003c/h2\u003e\n\u003cp\u003e经过在贴吧 Agent 社区项目中的实践，我总结出一个实用的 Agent 架构：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e┌─────────────────────────────────┐\n│         User Interface          │\n├─────────────────────────────────┤\n│        Orchestrator Layer       │\n│  ┌───────────┐ ┌─────────────┐  │\n│  │  Planner  │ │   Memory    │  │\n│  │ (ReAct /  │ │ (Short +    │  │\n│  │  Plan \u0026amp;   │ │  Long Term) │  │\n│  │  Execute) │ │             │  │\n│  └───────────┘ └─────────────┘  │\n├─────────────────────────────────┤\n│          Tool Registry          │\n│  [Search] [Code] [API] [DB]    │\n├─────────────────────────────────┤\n│        Foundation Model         │\n│     (LLM as reasoning core)    │\n└─────────────────────────────────┘\n\u003c/code\u003e\u003c/pre\u003e\u003ch3 id=\"planner\"\u003ePlanner\u003c/h3\u003e\n\u003cp\u003ePlanner 是 Agent 的大脑。我们在实践中对比了两种 pattern：\u003c/p\u003e","title":"从零构建 AI Agent：架构设计与实践总结"},{"content":"为什么 Prompt Engineering 依然重要？ 有人说 Prompt Engineering 是过渡期产物，模型越来越强就不需要了。我不完全同意。\n模型确实在进步，但 prompt 本质上是人和 AI 之间的 protocol。就像 API 设计不会因为后端变强就不重要一样，prompt 设计关乎的是\u0026quot;如何精确表达意图\u0026quot;——这个需求永远存在。\nCore Patterns 1. Zero-Shot：直接了当 最简单的方式，直接告诉模型你要什么：\n你是一个专业的文案编辑。请将以下用户评论改写为正式的产品评测， 保持核心观点不变，语气客观中立。 用户评论：这个耳机音质太炸了 低音给力 就是戴久了耳朵疼 适用场景：任务明确、模型能力已经很强的领域（翻译、摘要、格式转换）。\n2. Few-Shot：以身作则 给几个 example，让模型学会 pattern：\n请根据用户的自然语言描述，生成搜索查询。 示例1： 输入：最近有什么好看的科幻电影 输出：2026 高分科幻电影推荐 示例2： 输入：Python 怎么读取 Excel 输出：Python pandas read_excel 教程 现在请处理： 输入：怎么把图片背景去掉 关键技巧：examples 的多样性比数量更重要。3 个覆盖不同 pattern 的例子 \u0026gt; 10 个雷同的例子。\n3. Chain-of-Thought (CoT)：让模型\u0026quot;想\u0026quot;出来 请分析这款产品的市场定位是否合理。 请按以下步骤思考： 1. 首先识别目标用户群体 2. 分析竞品格局 3. 评估差异化优势 4. 给出结论和建议 产品描述：一款面向 Z 世代的 AI 绘画社交 App... CoT 的核心不是让模型\u0026quot;更聪明\u0026quot;，而是 强制模型经过中间推理步骤，减少跳跃式回答导致的错误。\n4. ReAct：思考 + 行动 ReAct pattern 是 Agent 的基础：\n你是一个数据分析助手，可以使用以下工具： - search_database(query): 查询数据库 - calculate(expression): 计算表达式 - draw_chart(data, type): 绘制图表 用户问题：上个月 DAU 最高的是哪一天？比平均值高多少？ 请按 Thought → Action → Observation 的循环来完成任务。 这个 pattern 在 Agent 场景中非常核心。我们在贴吧的 Agent 系统中广泛使用了 ReAct 的变体。\n我在工作中常用的 Prompt Template 经过大量实践，我总结了一个通用的 prompt 结构：\n## Role 你是 {角色描述} ## Context {背景信息和约束条件} ## Task {具体任务描述} ## Output Format {期望的输出格式} ## Examples (optional) {输入输出示例} ## Constraints - {约束1} - {约束2} 这个结构在 90% 的场景下都好用。关键是 Role 和 Context 决定了模型的\u0026quot;思维模式\u0026quot;，Task 和 Format 决定了输出质量。\nCommon Pitfalls Prompt 太长不等于效果好 — 信息过载会让模型\u0026quot;注意力分散\u0026quot;，关键信息反而被忽略 不要用否定句 — \u0026ldquo;不要用口语化表达\u0026rdquo; 不如 \u0026ldquo;请使用书面语，语气正式客观\u0026rdquo; Temperature 不是万能的 — 创意任务调高、确定性任务调低，但差距通常没想象中大 What\u0026rsquo;s Next Prompt Engineering 正在从\u0026quot;单条 prompt 优化\u0026quot;演进到\u0026quot;多 Agent prompt 系统设计\u0026quot;。下一篇我会聊聊 Multi-Agent 系统的 prompt 设计——如何让多个 Agent 协调工作，而不是互相打架。\n","permalink":"https://hongsymbol.online/posts/prompt-engineering-guide/","summary":"\u003ch2 id=\"为什么-prompt-engineering-依然重要\"\u003e为什么 Prompt Engineering 依然重要？\u003c/h2\u003e\n\u003cp\u003e有人说 Prompt Engineering 是过渡期产物，模型越来越强就不需要了。我不完全同意。\u003c/p\u003e\n\u003cp\u003e模型确实在进步，但 \u003cstrong\u003eprompt 本质上是人和 AI 之间的 protocol\u003c/strong\u003e。就像 API 设计不会因为后端变强就不重要一样，prompt 设计关乎的是\u0026quot;如何精确表达意图\u0026quot;——这个需求永远存在。\u003c/p\u003e\n\u003ch2 id=\"core-patterns\"\u003eCore Patterns\u003c/h2\u003e\n\u003ch3 id=\"1-zero-shot直接了当\"\u003e1. Zero-Shot：直接了当\u003c/h3\u003e\n\u003cp\u003e最简单的方式，直接告诉模型你要什么：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e你是一个专业的文案编辑。请将以下用户评论改写为正式的产品评测，\n保持核心观点不变，语气客观中立。\n\n用户评论：这个耳机音质太炸了 低音给力 就是戴久了耳朵疼\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003e适用场景\u003c/strong\u003e：任务明确、模型能力已经很强的领域（翻译、摘要、格式转换）。\u003c/p\u003e\n\u003ch3 id=\"2-few-shot以身作则\"\u003e2. Few-Shot：以身作则\u003c/h3\u003e\n\u003cp\u003e给几个 example，让模型学会 pattern：\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e请根据用户的自然语言描述，生成搜索查询。\n\n示例1：\n输入：最近有什么好看的科幻电影\n输出：2026 高分科幻电影推荐\n\n示例2：\n输入：Python 怎么读取 Excel\n输出：Python pandas read_excel 教程\n\n现在请处理：\n输入：怎么把图片背景去掉\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e\u003cstrong\u003e关键技巧\u003c/strong\u003e：examples 的多样性比数量更重要。3 个覆盖不同 pattern 的例子 \u0026gt; 10 个雷同的例子。\u003c/p\u003e\n\u003ch3 id=\"3-chain-of-thought-cot让模型想出来\"\u003e3. Chain-of-Thought (CoT)：让模型\u0026quot;想\u0026quot;出来\u003c/h3\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e请分析这款产品的市场定位是否合理。\n\n请按以下步骤思考：\n1. 首先识别目标用户群体\n2. 分析竞品格局\n3. 评估差异化优势\n4. 给出结论和建议\n\n产品描述：一款面向 Z 世代的 AI 绘画社交 App...\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003eCoT 的核心不是让模型\u0026quot;更聪明\u0026quot;，而是 \u003cstrong\u003e强制模型经过中间推理步骤\u003c/strong\u003e，减少跳跃式回答导致的错误。\u003c/p\u003e","title":"Prompt Engineering 实战指南：从 Zero-Shot 到 Multi-Agent"},{"content":"\u0026ldquo;AI-Enhanced\u0026rdquo; vs \u0026ldquo;AI-Native\u0026rdquo; 很多产品在做的事情是 AI-Enhanced——在现有流程上叠加一个 AI 功能。比如搜索框加个\u0026quot;AI 总结\u0026quot;，编辑器加个\u0026quot;AI 续写\u0026quot;。这当然有价值，但这不是 AI-Native。\nAI-Native 产品的核心特征是：AI 不是功能，而是基础设施。 产品的核心体验围绕 AI 能力设计，去掉 AI 这个产品就不存在。\n举几个例子：\n产品 AI-Enhanced AI-Native 搜索 搜索结果加 AI 摘要 Perplexity — 对话即搜索 编程 IDE 加 Copilot 补全 Cursor — AI 是编程的主循环 社区 帖子加 AI 评论 Agent 社区 — AI 是内容生产者 Three Principles of AI-Native Design 1. Interaction Model Redesign 传统产品的交互是\u0026quot;用户操作 → 系统响应\u0026quot;。AI-Native 的交互是 \u0026ldquo;用户表达意图 → AI 理解并执行 → 用户确认/调整\u0026rdquo;。\n这意味着 UI 要从\u0026quot;功能菜单\u0026quot;转向\u0026quot;意图表达\u0026quot;。Natural Language Interface 不一定是最优解，但 降低用户表达意图的成本 是设计核心。\n2. Error Tolerance \u0026amp; Graceful Degradation LLM 会犯错，这是基本事实。AI-Native 产品的设计必须 把错误当作正常情况处理，而不是 edge case。\n我在做 AI 表情包项目时，AI 生成的图有 30% 左右不符合预期。我们的做法是：\n用户描述 → AI 生成 3 张候选 → 用户选择/重新生成 把\u0026quot;生成-选择\u0026quot;做成一个快速循环，而不是期望一次生成完美结果。\n3. Data Flywheel from Day 1 AI-Native 产品从第一天就应该设计 Data Flywheel：\n用户行为 → 数据收集 → 模型优化 → 体验提升 → 更多用户行为 我们在 Agent 社区做的一个实践：每个 Agent 的对话数据会用于优化其 system prompt，表现好的 Agent 获得更多分发——这就是产品内建的 data flywheel。\nPractical Framework 当我评估一个 AI 产品 idea 时，我会问三个问题：\n去掉 AI，这个产品还有没有存在的必要？ 如果有，说明 AI 只是 enhancement AI 犯错时，用户体验是灾难性的还是可容忍的？ 如果灾难性，需要重新设计容错机制 数据飞轮在哪？ 如果没有，产品不会随时间变好 这三个问题能帮你快速判断一个 AI 产品是真 AI-Native，还是套了 AI 皮的传统产品。\nClosing Thoughts AI-Native 不是一个 buzzword，而是一种产品设计范式的转变。作为 PM，我们需要从\u0026quot;给产品加 AI\u0026quot;的思维中跳出来，去思考\u0026quot;如果 AI 是基础设施，产品应该长什么样\u0026quot;。\n","permalink":"https://hongsymbol.online/posts/ai-native-product-thinking/","summary":"\u003ch2 id=\"ai-enhanced-vs-ai-native\"\u003e\u0026ldquo;AI-Enhanced\u0026rdquo; vs \u0026ldquo;AI-Native\u0026rdquo;\u003c/h2\u003e\n\u003cp\u003e很多产品在做的事情是 \u003cstrong\u003eAI-Enhanced\u003c/strong\u003e——在现有流程上叠加一个 AI 功能。比如搜索框加个\u0026quot;AI 总结\u0026quot;，编辑器加个\u0026quot;AI 续写\u0026quot;。这当然有价值，但这不是 AI-Native。\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAI-Native 产品的核心特征是：AI 不是功能，而是基础设施。\u003c/strong\u003e 产品的核心体验围绕 AI 能力设计，去掉 AI 这个产品就不存在。\u003c/p\u003e\n\u003cp\u003e举几个例子：\u003c/p\u003e\n\u003ctable\u003e\n  \u003cthead\u003e\n      \u003ctr\u003e\n          \u003cth\u003e产品\u003c/th\u003e\n          \u003cth\u003eAI-Enhanced\u003c/th\u003e\n          \u003cth\u003eAI-Native\u003c/th\u003e\n      \u003c/tr\u003e\n  \u003c/thead\u003e\n  \u003ctbody\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e搜索\u003c/td\u003e\n          \u003ctd\u003e搜索结果加 AI 摘要\u003c/td\u003e\n          \u003ctd\u003ePerplexity — 对话即搜索\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e编程\u003c/td\u003e\n          \u003ctd\u003eIDE 加 Copilot 补全\u003c/td\u003e\n          \u003ctd\u003eCursor — AI 是编程的主循环\u003c/td\u003e\n      \u003c/tr\u003e\n      \u003ctr\u003e\n          \u003ctd\u003e社区\u003c/td\u003e\n          \u003ctd\u003e帖子加 AI 评论\u003c/td\u003e\n          \u003ctd\u003eAgent 社区 — AI 是内容生产者\u003c/td\u003e\n      \u003c/tr\u003e\n  \u003c/tbody\u003e\n\u003c/table\u003e\n\u003ch2 id=\"three-principles-of-ai-native-design\"\u003eThree Principles of AI-Native Design\u003c/h2\u003e\n\u003ch3 id=\"1-interaction-model-redesign\"\u003e1. Interaction Model Redesign\u003c/h3\u003e\n\u003cp\u003e传统产品的交互是\u0026quot;用户操作 → 系统响应\u0026quot;。AI-Native 的交互是 \u003cstrong\u003e\u0026ldquo;用户表达意图 → AI 理解并执行 → 用户确认/调整\u0026rdquo;\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e这意味着 UI 要从\u0026quot;功能菜单\u0026quot;转向\u0026quot;意图表达\u0026quot;。Natural Language Interface 不一定是最优解，但 \u003cstrong\u003e降低用户表达意图的成本\u003c/strong\u003e 是设计核心。\u003c/p\u003e","title":"AI-Native 产品思维：从功能驱动到智能驱动"},{"content":"Why Start a Blog? 做 AI 产品快两年了，从 Agent 社区到 AI 小游戏，从 AIGC 表情包到 Vibe Coding，每天都在和大模型打交道。但我发现一个问题——很多有价值的思考和踩坑经验，散落在飞书文档、微信聊天和脑子里，从来没有系统整理过。\n开博客的念头其实很朴素：把想法写下来，逼自己想清楚。\nWhat Will I Write About? 这个博客会覆盖几个方向：\nAI Product Thinking — 做 AI 产品过程中的方法论和思维框架 Prompt Engineering — 实战中总结的 prompt 技巧，不是纸上谈兵那种 Tech Deep Dive — Agent 架构、多模态应用、评测体系等技术向内容 Reflection — 阶段性复盘，记录自己的成长轨迹 Tech Stack 博客用 Hugo + PaperMod 搭建，部署在自己的服务器上。选 Hugo 是因为快——build 整个站点不到 1 秒，而且 Go template 的灵活度够用。PaperMod 主题干净、responsive，开箱即用。\nA Note to Future Me 如果你（未来的我）回来看这篇文章，希望那时候博客已经有几十篇内容了，而不是只剩这一篇 Hello World 孤零零地挂着 😄\nLet\u0026rsquo;s go.\n","permalink":"https://hongsymbol.online/posts/hello-world/","summary":"\u003ch2 id=\"why-start-a-blog\"\u003eWhy Start a Blog?\u003c/h2\u003e\n\u003cp\u003e做 AI 产品快两年了，从 Agent 社区到 AI 小游戏，从 AIGC 表情包到 Vibe Coding，每天都在和大模型打交道。但我发现一个问题——很多有价值的思考和踩坑经验，散落在飞书文档、微信聊天和脑子里，从来没有系统整理过。\u003c/p\u003e\n\u003cp\u003e开博客的念头其实很朴素：\u003cstrong\u003e把想法写下来，逼自己想清楚。\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"what-will-i-write-about\"\u003eWhat Will I Write About?\u003c/h2\u003e\n\u003cp\u003e这个博客会覆盖几个方向：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eAI Product Thinking\u003c/strong\u003e — 做 AI 产品过程中的方法论和思维框架\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrompt Engineering\u003c/strong\u003e — 实战中总结的 prompt 技巧，不是纸上谈兵那种\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTech Deep Dive\u003c/strong\u003e — Agent 架构、多模态应用、评测体系等技术向内容\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReflection\u003c/strong\u003e — 阶段性复盘，记录自己的成长轨迹\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"tech-stack\"\u003eTech Stack\u003c/h2\u003e\n\u003cp\u003e博客用 \u003ca href=\"https://gohugo.io/\"\u003eHugo\u003c/a\u003e + \u003ca href=\"https://github.com/adityatelange/hugo-PaperMod\"\u003ePaperMod\u003c/a\u003e 搭建，部署在自己的服务器上。选 Hugo 是因为快——build 整个站点不到 1 秒，而且 Go template 的灵活度够用。PaperMod 主题干净、responsive，开箱即用。\u003c/p\u003e\n\u003ch2 id=\"a-note-to-future-me\"\u003eA Note to Future Me\u003c/h2\u003e\n\u003cp\u003e如果你（未来的我）回来看这篇文章，希望那时候博客已经有几十篇内容了，而不是只剩这一篇 Hello World 孤零零地挂着 😄\u003c/p\u003e\n\u003cp\u003eLet\u0026rsquo;s go.\u003c/p\u003e","title":"Hello World：为什么我开始写博客"}]